Hi,
On 13/07/2026 15:50, Adrian Bunk wrote:
Control: reassign -1 dh-python
Control: forcemerge 1141379 -1
Control: affects 1141379 src:vtk9 python3-vtk9
On Sun, Jul 12, 2026 at 10:57:12AM +0200, Emilio Pozuelo Monfort wrote:
Source: vtk9
Version: 9.5.2+dfsg4-5
Severity: serious
Hi,
During the python3.14 as default python3 interpreter transition, vtk9 has
been binNMU'ed, resulting in the package building
libvtkWrappingPythonCore3.14-9.5.so.1. However that can cause rdeps to fail,
as demonstrated in one autopkgtest [1]:
332s ERROR: TestFemApp (unittest.loader._FailedTest.TestFemApp)
332s ----------------------------------------------------------------------
332s ImportError: Failed to import test module: TestFemApp
332s Traceback (most recent call last):
332s File "/usr/lib/python3.13/unittest/loader.py", line 137, in
loadTestsFromName
332s module = __import__(module_name)
332s File "/usr/share/freecad/Mod/Fem/TestFemApp.py", line 33, in <module>
332s from femtest.app.test_mesh import TestMeshCommon as FemTest07
332s File "/usr/share/freecad/Mod/Fem/femtest/app/test_mesh.py", line 33, in
<module>
332s import Fem
332s ImportError: libvtkWrappingPythonCore3.13-9.5.so.1: cannot open shared
object file: No such file or directory
One possible easy solution would be to build vtk9 against all supported python3
versions,
thus during the transition libvtk9 would have both 3.13 and 3.14 builds, and it
would
be dropped once the older version is no longer "supported" (i.e. included in
python3-all).
Another option would be to have some dependencies, e.g. through a
Provides: libvtkwrapping-python3.XX and corresponding deps in rdeps.
The better solution is for dh_python3 to emit dependencies
python3 (>= 3.14~), python3 (<< 3.15)
I'm merging this with the existing bug for that, there is no point in
working around this issue in a gazillion packages.
I was aware of the existing dh-python bug, but decided to file this as a
separate issue as I don't think the situation is the same. I agree that a more
general solution would be better. I'm not sure that your proposal suits all
cases (including this one). For a python module package, your proposal is fine.
However for a library package that links against libpython, not so much. See
e.g. libfontforge4 or libmailutils9t64. I don't think those should depend on
python3. Breaks or Conflicts could be another option to ensure proper upgrades,
but that may cause upgrade issues and unintended package removals?
freecad-python3 has the same issue (though it might not be tested by an
autopkgtest:
Depends: ..., libpython3.14 (>= 3.14.1),...
Without the autopkgtest blocking due to this issue in vtk9 freecad would
have already migrated, resulting in freecad-python3 segfaulting in testing.
That looks like a different case (i.e. python module or app) than vtk9, covered
by the previous dh-python bug, where I agree a tighter python3 dependency could
be useful.
Cheers,
Emilio
