Control: found 953800 1.13.1-6 If checky2106 will always fail on 32-bit systems, that's a clear indication that GnuPG will fail on those systems when it encounters objects that have a timestamp that lands about 86 years out from now. For example, an OpenPGP certificate with a 100-year expiration date issued any time in the last 14 years. Or an OpenPGP certificate with a 75-year expiration date issued 11 years from now.
The test should *not* obviously fail on 32-bit systems, but it is a combination of bugs that upstream declines to fix: https://dev.gnupg.org/T4766 https://dev.gnupg.org/T4826 I honestly don't know how to resolve this issue correctly, given upstream's refusal to acknowledge it as a problem worth fixing. To the extent that software on debian depends on these systems going forward while OpenPGP is in use, and they may encounter signatures or certificates with expiration dates later than 2106, our users *will* run into this problem, well before 2106 itself rolls around. i'm working on an update to the gpgme1.0 debian packaging that will permit the package to skip this particular autopkgtest if it is failing on 32-bit platforms as long as a certificate or signature created "today" with an expiration date of 75 years is handled correctly. This is a reprieve of 11 years. Hopefully by then either upstream will have resolved the problem, or either GPGME or platforms with a 32-bit unsigned long will no longer be relevant to Debian. On Fri 2020-03-13 17:42:05 +0100, Gianfranco Costamagna wrote: > also, taking this patch would be so appreciated. > + - debian/patches/0006-PIC-and-shared.patch: Libs are -fPIC and -shared. This is an entirely different matter, and seems related to https://bugs.debian.org/870383 -- it would probably be better dealt with over there or on a new bug report. Has this change been recommended upstream? Why should debian or ubuntu carry it separately? > + - Add in libgpgme-dev a libgpgme-pthread.so pointing to libgpgme.so, this > + will fix the build failures of kf5-kdepim-apps-libs when built against > + this gpgme package. This is also a separate issue, and should probably be dealt with separately. Are you sure this isn't a bug in kf5-kdepim-apps-libs, and not gpgme? where does kf5-kdepim-apps-libs get the idea that it should be looking for libgpgme-pthread.so instead of libgpgme.so during build? --dkg
signature.asc
Description: PGP signature
