On Mon, Jul 13, 2026 at 06:32:02PM +0200, Emilio Pozuelo Monfort wrote: > Hi,
Hi Emilio, > 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, fair point that Breaks: python3 (<< 3.14~), python3 (>= 3.15~) might be better than my suggestion. > but that may cause upgrade issues and unintended package removals? I'd be more worried about upgrade issues cause by maintainer scripts (e.g. postinst) calling programs that are non-functional during an upgrade. > > 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. freecad-python3 -> libfreecad-python3 -> libnglib-6.2t64 -> libpython3.13 > Cheers, > Emilio cu Adrian
