On Wed, Oct 22, 2025 at 10:25:36AM +0200, Emilio Pozuelo Monfort wrote:
On 20/10/2025 18:39, Dominique Belhachemi wrote:
Can you take a look at the autopkgtests regressions? [1]. camitk probably needs
to be removed from testing, but I don't know about the rest.
Please remove them from testing.
Also, python3-vtk-dicom was rebuilt, but the test framework is still
using the older version
python3-vtk-dicom (0.8.17-1+b1) instead of
python3-vtk-dicom (0.8.17-1+b2).
Does python3-vtk-dicom (and maybe other python3-vtk9 rdeps) need a stricter
dependency? From its autopkgtest log:
48s Testing with python3.13:
48s Traceback (most recent call last):
48s File "<string>", line 1, in <module>
48s import vtkdicom; print(vtkdicom)
48s ^^^^^^^^^^^^^^^
48s File "/usr/lib/python3/dist-packages/vtkdicom/__init__.py", line 2,
in <module>
48s from .vtkDICOM import *
48s ImportError: Initialization failed for vtkDICOM, not compatible with
vtkmodules.vtkCommonCore
If the vtk python module is changing some kind of ABI, then there should be
appropriate dependencies on the rdeps so they enforce a compatible version.
See for example python3-numpy with python3-numpy.*-abi.*
This is the old problem that the release team wants smooth transitions,
but using different so-versions of a library in a binary is usually
not safe.
And no, symbol versions won't solve that in all cases.
https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtk-dicom/65358838/log.gz
47s Setting up libvtk9.5:amd64 (9.5.2+dfsg2-1) ...
47s Setting up libvtk9.3:amd64 (9.3.0+dfsg1-7) ...
The proper fix would be:
Package: libvtk9.5
Breaks: libvtk9.3