This is not a real fix to the underlying problem: it just gives GPGME
upstream a window of time to deal with 75-year expiration dates.  If
and signature or certification is created with a 75-year expiration
date in 2031, that signature will not be parsed correctly by GPGME on
these platforms.

Hopefully upstream can fix this before 2031, but they seem resistant
to fixing it upstream.

Perhaps by 2031 they will have changed their opinion and resolved the
issue, or nothing will depend on this software any more.

 (Thanks, Multiarch hinter!)

Helmut Grohne authored Mar 09, 2020 and Daniel Kahn Gillmor committed Mar 09, 2020

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Upstream has explicitly declared that they will not fix this problem,
see https://dev.gnupg.org/T4766

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Note that this may re-open #912898, but is necessary, because python
3.8 uses _sysconfigdata__${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}
instead of _sysconfigdata_m_${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}

We don't ship python2 packages any more.

Fixes lintian: out-of-date-standards-version
See https://lintian.debian.org/tags/out-of-date-standards-version.html for more details.

The only reverse dependency in debian for python-gpg is an older
version of dput.  Newer versions of dput use python3 anyway, and
python 2 is going away.

This also makes the build simpler and quicker, and makes any flakiness
in the test suite less likely to be triggered.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Update to upstream version '1.13.1'
with Debian dir 2cc976ef399899f395aaf6f0b634eaf961f2dbe4

* configure.ac: Bump LT versions to c=C33/A22/R1 cpp=C16/A10/R0
qt=C10/A3/R4.

Signed-off-by: Werner Koch <wk@gnupg.org>