- Package:
- src:dh-python
- Source:
- src:dh-python
- Submitter:
- Gianfranco Costamagna
- Date:
- 2026-03-09 22:31:02 UTC
- Severity:
- normal
- Tags:
Hello, I found new dh-python to be installing a lot of build time stuff into the binary, making it collide between packages. I see this on Ubuntu, but rebuilding Debian packages is making the new binaries bigger too See e.g. https://launchpadlibrarian.net/847341639/buildlog_ubuntu-resolute-amd64.python-x3dh_1.2.0-2build1_BUILDING.txt.gz drwxr-xr-x root/root 0 2026-02-12 07:14 ./usr/lib/python3/dist-packages/ drwxr-xr-x root/root 0 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/ drwxr-xr-x root/root 0 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/ drwxr-xr-x root/root 0 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/docs/ -rw-r--r-- root/root 4339 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/docs/conf.py drwxr-xr-x root/root 0 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/ -rw-r--r-- root/root 577 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/__init__.py -rw-r--r-- root/root 21248 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/base_state.py -rw-r--r-- root/root 1424 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/crypto_provider.py -rw-r--r-- root/root 1400 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/crypto_provider_cryptography.py -rw-r--r-- root/root 5535 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/identity_key_pair.py -rw-r--r-- root/root 5574 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/migrations.py -rw-r--r-- root/root 2242 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/models.py -rw-r--r-- root/root 343 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/pre_key_pair.py -rw-r--r-- root/root 0 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/py.typed -rw-r--r-- root/root 2591 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/signed_pre_key_pair.py -rw-r--r-- root/root 12358 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/state.py -rw-r--r-- root/root 2342 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/types.py -rw-r--r-- root/root 51 2026-02-12 07:14 ./usr/lib/python3/dist-packages/build/lib/x3dh/version.py I'm debugging further G.
After debugging some more, I found even an old dh-python to show the problem, and I see this:
(sorry, clicked enter by mistake) creating build/bdist.linux-x86_64/wheel/x3dh-1.2.0.dist-info/WHEEL creating '/python-x3dh/python-x3dh/.pybuild/cpython3_3.13_x3dh/.tmp-e5i3go96/x3dh-1.2.0-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it adding 'build/lib/docs/conf.py' adding 'build/lib/x3dh/__init__.py' adding 'build/lib/x3dh/base_state.py' adding 'build/lib/x3dh/crypto_provider.py' adding 'build/lib/x3dh/crypto_provider_cryptography.py' adding 'build/lib/x3dh/identity_key_pair.py' adding 'build/lib/x3dh/migrations.py' adding 'build/lib/x3dh/models.py' adding 'build/lib/x3dh/pre_key_pair.py' adding 'build/lib/x3dh/py.typed' adding 'build/lib/x3dh/signed_pre_key_pair.py' adding 'build/lib/x3dh/state.py' adding 'build/lib/x3dh/types.py' adding 'build/lib/x3dh/version.py' adding 'docs/conf.py' Some wheel regression? G.
I checked python-agate, and the sid version is already affected https://buildd.debian.org/status/fetch.php?pkg=python-agate&arch=all&ver=1.14.1-1&stamp=1769830154&raw=0 Still not sure about the root cause G.
Hi Gianfranco (2026.02.12_20:31:57_+0000) There are a number of affected packages in sid, but I think there is more than one cause: python3-agate - 1.14.1-1 migrated to pybuild-plugin-pyproject uses: tool.setuptools.packages.find with exclude python3-aioraven - NEW python3-azure - Appears between 2025-11-18 20:16:40 and 2025-12-02 17:37:24 - In azure-ai-agentserver-agentframework which uses tool.setuptools.packages.find with exclude both before and after python3-django-pipeline - Appears between 2025-10-23 14:47:02 and 2026-01-18 14:58:54 uses: tool.setuptools.packages.find with exclude python3-geoalchemy2 - Appears between 2024-10-17 05:43:36 and 2025-02-16 15:37:51 still using old setup.py workflow python3-pyunitsystem - Always present uses: tool.setuptools.packages.find with where=. python3-pyvlx - Appears between 2026-01-27 01:02:57 and 2026-02-12 13:29:42 which migrates from setup.py to pyproject.toml uses: tool.setuptools.packages.find with exclude python3-readme-renderer - Appears between 2025-09-26 09:12:44 and 2025-12-31 15:30:10 uses: tool.setuptools.packages.find with exclude python3-sqlalchemy-i18n - Appears between 2021-11-08 10:34:13 and 2024-11-14 06:43:22 python3-tqdm - Appears between 2025-11-30 19:04:18 and 2026-02-02 05:13:59 uses: tool.setuptools.packages.find with exclude python3-zwave-js-server-python - Appears between 2025-08-09 06:52:07 and 2026-01-17 14:29:57 uses: tool.setuptools.packages.find with exclude Some of these ahve been around for years, but many appear when we started to support Python 3.13 and Python 3.14. I played around with pyunitsystem and confirmed that it's the double-build that's triggering this. The most likely cause is https://github.com/pypa/setuptools/issues/2688 We have a built-in exclude for "build" in setuptools, but not "build.*" I suspect the best solution here is for us to implement #1124699 Stefano
I add python-oldmemo, python-newmemo too... Il giorno giovedì 12 febbraio 2026 alle ore 22:59:13 CET, Stefano Rivera <stefanor@debian.org> ha scritto: Hi Gianfranco (2026.02.12_20:31:57_+0000) There are a number of affected packages in sid, but I think there is more than one cause: python3-agate - 1.14.1-1 migrated to pybuild-plugin-pyproject uses: tool.setuptools.packages.find with exclude python3-aioraven - NEW python3-azure - Appears between 2025-11-18 20:16:40 and 2025-12-02 17:37:24 - In azure-ai-agentserver-agentframework which uses tool.setuptools.packages.find with exclude both before and after python3-django-pipeline - Appears between 2025-10-23 14:47:02 and 2026-01-18 14:58:54 uses: tool.setuptools.packages.find with exclude python3-geoalchemy2 - Appears between 2024-10-17 05:43:36 and 2025-02-16 15:37:51 still using old setup.py workflow python3-pyunitsystem - Always present uses: tool.setuptools.packages.find with where=. python3-pyvlx - Appears between 2026-01-27 01:02:57 and 2026-02-12 13:29:42 which migrates from setup.py to pyproject.toml uses: tool.setuptools.packages.find with exclude python3-readme-renderer - Appears between 2025-09-26 09:12:44 and 2025-12-31 15:30:10 uses: tool.setuptools.packages.find with exclude python3-sqlalchemy-i18n - Appears between 2021-11-08 10:34:13 and 2024-11-14 06:43:22 python3-tqdm - Appears between 2025-11-30 19:04:18 and 2026-02-02 05:13:59 uses: tool.setuptools.packages.find with exclude python3-zwave-js-server-python - Appears between 2025-08-09 06:52:07 and 2026-01-17 14:29:57 uses: tool.setuptools.packages.find with exclude Some of these ahve been around for years, but many appear when we started to support Python 3.13 and Python 3.14. I played around with pyunitsystem and confirmed that it's the double-build that's triggering this. The most likely cause is https://github.com/pypa/setuptools/issues/2688 We have a built-in exclude for "build" in setuptools, but not "build.*" I suspect the best solution here is for us to implement #1124699 Stefano
Hello, I have been working on cocotb package [1] for 2 years, it used to build on Debian unstable until recently, when Inattempted to build it again it failed to build. Upstream author noticed in my build log some weird paths being created for example: creating build/temp.linux-x86_64-cpython-313/cocotb/libs/libgpilog/cocotb/libs/libpygpilog/cocotb/libs/libcocotbutils/cocotb/libs/libembed/cocotb/libs/libgpi/cocotb/libs/libcocotb/cocotb/simulator/cocotb/libs/libcocotbvpi_icarus/cocotb/libs/libcocotbvpi_modelsim/cocotb/libs/libcocotbvhpi_modelsim/cocotb/libs/libcocotbfli_modelsim/cocotb/libs/libcocotbvpi_ghdl/cocotb/libs/libcocotbvpi_ius/cocotb/libs/libcocotbvhpi_ius/src/cocotb/share/lib/vhpi I suspected dh-python/pybuild being the culprit, so I tried building on Debian unstable with older (from Debian snapshot) versions of dh-python & pybuild-plugin-*, and indeed it built succesafully with dh-pyyhon/pybuild < 6.20252021, the build fails starting from dh-pyyhon/pybuild 6.20252021 I have also tried disabling python 3.14 build (setting X-Python3-Version: << 3.14 in d/control) as suggested by someone to me on #debian-python, but that didn't fix the build either. I have attached both build logs: cocotb_2.0.1-1_amd64.build.fail: using recent dh-python/pybuild cocotb_2.0.1-1_amd64.build-success: using dh-python/pybuild 6.20251204.1 [1] https://salsa.debian.org/electronics-team/cocotb
Hello, Resending because I sent the wrong failing build log last time.. I have been working on cocotb package [1] for 2 years, it used to build on Debian unstable until recently, when Inattempted to build it again it failed to build. Upstream author noticed in my build log some weird paths being created for example: creating build/temp.linux-x86_64-cpython-313/cocotb/libs/libgpilog/cocotb/libs/libpygpilog/cocotb/libs/libcocotbutils/cocotb/libs/libembed/cocotb/libs/libgpi/cocotb/libs/libcocotb/cocotb/simulator/cocotb/libs/libcocotbvpi_icarus/cocotb/libs/libcocotbvpi_modelsim/cocotb/libs/libcocotbvhpi_modelsim/cocotb/libs/libcocotbfli_modelsim/cocotb/libs/libcocotbvpi_ghdl/cocotb/libs/libcocotbvpi_ius/cocotb/libs/libcocotbvhpi_ius/src/cocotb/share/lib/vhpi I suspected dh-python/pybuild being the culprit, so I tried building on Debian unstable with older (from Debian snapshot) versions of dh-python & pybuild-plugin-*, and indeed it built succesafully with dh-pyyhon/pybuild < 6.20252021, the build fails starting from dh-pyyhon/pybuild 6.20252021 I have also tried disabling python 3.14 build (setting X-Python3-Version: << 3.14 in d/control) as suggested by someone to me on #debian-python, but that didn't fix the build either. I have attached both build logs: cocotb_2.0.1-1_amd64.build.fail: using recent dh-python/pybuild cocotb_2.0.1-1_amd64.build-success: using dh-python/pybuild 6.20251204.1 [1] https://salsa.debian.org/electronics-team/cocotb
Hello, I found thatvthe root cause for cocotb build failure is this commit in dh-python: commit m760c357fad5c0472a2a0c1570f13991c327712e4 build setuptools extensions in parallel as per `DEB_BUILD_OPTIONS=parallel=N` So I worked around it by disabling parallel jobs during build for cocotb
---end quoted text--- Some issue with this is as follows: the only way that I was able to disable parallel build was to set DEB_BUILD_OPTIONS=parallel=1 in debian/rules, yet this gives me a lintian warning that I should set DEB_BUILD_MAINT_OPTIONS, yet when I did that, dh-python won't respect that variable. Also dh-python doesn't respect if I do: dh --no-parallel
Hello, Bug #1127763 in dh-python reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/tools/dh-python/-/commit/17b30689472ab489e4d7662b7e3e3e154020b08d ------------------------------------------------------------------------ Fix for detection of parallel build option Get the parallel build option from pybuild.pm, instead of re-implementing the detection logic in Python, then pass its value as an `--parallel` argument to pybuild This fix makes pybuild get the parallel build setting either from `DEB_BUILD_(MAINT)_OPTIONS` or the `--(no-)parallel` argument passed to `dh` Closes: #1127763 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1127763
Please try setting DEB_BUILD_OPTIONS=parallel=1 in debian/rules for the packages that fail to build,and report back whether this fixes the issue. Thanks.
Please try setting DEB_BUILD_OPTIONS=parallel=1 in debian/rules for the packages that fail to build,and report back whether this fixes the issue. Thanks.
Hi أحمد (2026.03.02_11:57:41_-0400) All the other packages I analyzed earlier in this bug were due to the way they were using the setuptools finder, not any parallel-related bugs. I'm going to upload dh-python with this fix, but without closing this bug. Your issue in cocotb was not the issue other packages in this bug were facing. Stefano
---end quoted text--- Thanks