python3-gpg 2.0.0-3 only ships a shared object for python 3.14.  version
2.0.0-2 shipped a shared object for both python 3.13 and 3.14.

This causes the test python3-gpg test suite to fail on platforms where
"py3versions -s" returns anything other than python3.14.  This means it
breaks the CI on the risc64 platform, which in turn is preventing the
package's migration to testing.

It seems possible that when python3.13 is removed from testing, the
migration will become possible again.

That said, the source differences between 2.0.0-2 and 2.0.0-3 do not
indicate anything that would make the package build against fewer
versions of python.

I'm not enough of a python packaging guru to know what changes in the
underlying infrastructure might have caused this regression, but i do
note that lintian complains quite a bit about the "outdated" nature of
the python module packaging code, including these warnings:

I: gpgmepy source: missing-prerequisite-for-pyproject-backend setuptools.build_meta (does not satisfy python3-setuptools:any, pybuild-plugin-pyproject:any) [pyproject.toml:63]
I: python3-gpg: package-installs-legacy-python-egg-info [usr/lib/python3/dist-packages/gpg-2.0.0.egg-info/PKG-INFO]
I: python3-gpg: package-installs-legacy-python-egg-info [usr/lib/python3/dist-packages/gpg-2.0.0.egg-info/]
I: python3-gpg: package-installs-legacy-python-egg-info [usr/lib/python3/dist-packages/gpg-2.0.0.egg-info/dependency_links.txt]
I: python3-gpg: package-installs-legacy-python-egg-info [usr/lib/python3/dist-packages/gpg-2.0.0.egg-info/top_level.txt]

It looks like upstream already migrated to pyproject, so maybe the first
step here is to switch to the pyproject backend for debhelper and see
whether the standard debian packaging infrastructure ends up doing the
right thing.

At any rate, this issue has caused gpgmepy to be marked for autoremoval
from testing (as well as any other package that depends on python3-gpg.

python3-defaults 3.14.7-2 removed 3.13 as a supported version, and i
think the riscv64 port was built against python3-all-dev from that
version.  now that 3.14.7-3 has migrated to testing, i asked the CI
system to re-run the riscv64 tests.

They've now passed, so the gpgmepy migration should be able to proceed.
So i'm closing this bug, as it appears it was just a transient failure
due to different versions of python3-all-dev (in unstable at build time)
and python3-all (in testing at CI migration time).

python3-defaults 3.14.7-2 removed 3.13 as a supported version, and i
think the riscv64 port was built against python3-all-dev from that
version.  now that 3.14.7-3 has migrated to testing, i asked the CI
system to re-run the riscv64 tests.

They've now passed, so the gpgmepy migration should be able to proceed.
So i'm closing this bug, as it appears it was just a transient failure
due to different versions of python3-all-dev (in unstable at build time)
and python3-all (in testing at CI migration time).