Fedora Account System
Red Hat Associate
Red Hat Customer
$ gpg2 --list-public-keys > gpg2: symbol lookup error: gpg2: undefined symbol: gpgrt_set_confdir, > version GPG_ERROR_1.0 $ rpm -q gnupg2 libgpg-error > gnupg2-2.2.27-2.fc34.x86_64 > libgpg-error-1.37-1.fc33.x86_64 + https://dev.gnupg.org/T4859 -> ---------------- diff --git a/gnupg2.spec b/gnupg2.spec index a582cda..072862f 100644 --- a/gnupg2.spec +++ b/gnupg2.spec @@ -41,7 +41,7 @@ BuildRequires: docbook-utils BuildRequires: gettext BuildRequires: libassuan-devel >= 2.1.0 BuildRequires: libgcrypt-devel >= 1.7.0 -BuildRequires: libgpg-error-devel >= 1.31 +BuildRequires: libgpg-error-devel >= 1.38 BuildRequires: libksba-devel >= 1.3.0 BuildRequires: openldap-devel BuildRequires: libusb-devel @@ -55,7 +55,7 @@ BuildRequires: fuse BuildRequires: make Requires: libgcrypt >= 1.7.0 -Requires: libgpg-error >= 1.31 +Requires: libgpg-error >= 1.38 Recommends: pinentry ---------------- Luckily, this seems to have no effect on GPG verifications by RPM, otherwise this situation would semi-brick the installation. Anyway, a critical package such as this would rather receive more prudent care -- simple smoke test should have discovered this problem. (Even better, upstream could introduce more progressive SONAME versioning, perhaps -- last time this bump was in order per "blame": https://src.fedoraproject.org/rpms/gnupg2/c/7dd8e5a1166041cf84f7dec877c7a184d6d53795 ) Thanks!
I'd really blame upstream here - this should be catched already at the build time if done properly upstream. Either they should properly bump SONAME versioning - i.e., add newly added symbols to new versions and not the GPG_ERROR_1.0. Or they should at least fail the build when the gpg-error in the build root does not have a proper version.
> simple smoke test should have discovered this problem My bad, only if combined with some kind of "retrograde, boundary-constrained dependency downgrade matrix-like combinator", which is apparently the hard part here. Though Fedora was working on something this general, but again, it is a really hard problem, sadly.
We run the tests on updated systems. Unfortunately, the "libgpg-error-1.39-1" was updated just two months ago and we never had 1.38 which was out for quite a longer. Having normal symbol versioning would be great. I will try to keep an eye on the API in the future and apply your fix for now.
sigh ... looks like something changed in the build system and I am no longer able to build the gnupg2 package with on s390x as the build fails there. I will try to investigate later. https://koji.fedoraproject.org/koji/taskinfo?taskID=62220845 Checking that we can add subkeys... > () (- - -) (default default never) (rsa sign auth encr seconds=600) (rsa auth,encr 2) (rsa sign 2038-01-01) (rsa sign 20380101T115500) (rsa sign 2d) (rsa1024 sign 2w) (rsa2048 encr 2m) (rsa4096 sign,auth 2y) ("/builddir/build/BUILD/gnupg-2.2.27/g10/gpg" --no-permission-warning --always-trust --quick-add-key "C0E2945C131F3D65DBCE8B031EC5E7B1A792A6C1" rsa4096 sign,auth "2y") failed: gpg: signing failed: Bad passphrase gpg: make_keysig_packet failed for backsig: Bad passphrase gpg: Key generation failed: Bad passphrase gpg: Key not changed so no update needed. 0: tests.scm:122: (throw (string-append (stringify what) " failed") (:stderr result)) 1: quick-key-manipulation.scm:134: (call-check `(,@gpg --quick-add-key ,fpr ,@args)) 2: #<CLOSURE> 3: tests.scm:78: (apply proc args) 4: #<CLOSURE> 5: init.scm:230: (apply proc cars) FAIL: tests/openpgp/quick-key-manipulation.scm
This was fixed with gnupg2-2.2.27-3 update in Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-5a0b29f9a5