FS#54271 - [gnupg] pacman-key populate depends of libusb
Attached to Project:
Arch Linux
Opened by Oscar Garcia (ogarcia) - Friday, 02 June 2017, 11:31 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 06 June 2017, 22:04 GMT
Opened by Oscar Garcia (ogarcia) - Friday, 02 June 2017, 11:31 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 06 June 2017, 22:04 GMT
|
Details
I'm trying make a very minimal Arch Linux container for
Docker project [1] and when exec the `pacman-key --populate
archlinux` command it fails because the internal command
lsign-key returns an error code 2 associated to scdaemon.
Specifically the error is: gpg: error getting version from 'scdaemon': No SmartCard daemon Steps to reproduce (as root): TMPDIR=$(mktemp -d) pacstrap -C /usr/share/devtools/pacman-extra.conf -c -d -G -M $TMPDIR diffutils gettext grep gzip pacman procps-ng psmisc sed tar util-linux which arch-chroot $TMPDIR locale-gen arch-chroot $TMPDIR pacman-key --init arch-chroot $TMPDIR pacman-key --populate archlinux At this point fails the sign process. You can launch one lsign-key by hand to see issue: arch-chroot $TMPDIR gpg --homedir /etc/pacman.d/gnupg --no-permission-warning --command-fd 0 --batch --lsign-key 684148BB25B49E986A4944C55184252D824B18E8 pub rsa3072/5184252D824B18E8 [...] gpg: error getting version from 'scdaemon': No SmartCard daemon "Thomas [..] Take note that command works, but returns an error code 2 instead a 0. If you lauch scdaemon by hand can see the base issue: # /usr/lib/gnupg/scdaemon /usr/lib/gnupg/scdaemon: error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directory [1]: https://github.com/pierres/archlinux-docker |
This task depends upon
Closed by Gaetan Bisson (vesath)
Tuesday, 06 June 2017, 22:04 GMT
Reason for closing: Fixed
Additional comments about closing: gnupg-2.1.21-2 in [testing]
Tuesday, 06 June 2017, 22:04 GMT
Reason for closing: Fixed
Additional comments about closing: gnupg-2.1.21-2 in [testing]
Optional Deps : libldap: gpg2keys_ldap
libusb-compat: scdaemon
tl;dr fix is in master, but not in the stable branch yet (as of this comment), commits a8dd96826f84 and fbb2259d22e6 can be used to fix things if desired
@meta/allan: pacman-key --populate currently fails without libusb. In reality, for almost everyone on Arch that command needs to succeed. Claiming "this is not a bug" because gnupg (not even pacman!) has a nondescript optdep might or might not be "technically correct", idk, but it certainly isn't helpful... y_u_do_dis.jpg
2. No need for all this drama.
3. Would everyone be happy if I made libusb-compat a hard dependency for the time being?
Yes, for <=2.1.20 and probably >=2.1.22. In 2.1.21, some commands that don't need a smartcard return error 2 if the smartcard daemon cannot be used, see OP (i.e. lsign-key).
> 2. No need for all this drama.
No drama or hard feelings towards anyone intended. I was just trying to set the record straight: IMHO, OP was a good bug report that shouldn't have been dismissed so easily on some technicality. I guess I should have used some emoticons to soften the mild criticism further. :-D ;-) :-P
> 3. Would everyone be happy if I made libusb-compat a hard dependency for the time being?
libusb as hard dep would fix OP's issue, but doesn't work if scdaemon is unavailable for some other reason, e.g. the "disable-scdaemon" scenario described in the upstream bug (which is how I came across this bug btw). Consider using the one simple patch from commit a8dd96826f84 [0] (mentioned above) for a better fix. Debian does this too (because they don't install scdaemon by default).
[0] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=patch;h=a8dd96826f8484c0ae93c954035b95c2a75c80f2