On 2026-09-02 Daniel Kahn Gillmor <[email protected]> wrote:
> Source: gpgmepy
> Version: 2.0.0-3
> Severity: important
> 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.
Hello Daniel,
I an very very far from beineg a python packaging guru baut afaict we are
doing what python policy requires, we build for all support python
version ("py3versions -s"). This changed as the part of the 3.14
transition.
> 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.
[...]
I am not sure whether this is ready for use, the currently used build system
uses ./configure to generate setup.py from setup.py.in and runs it via
automake.
cu Andreas
