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 > Cheers, > Emilio cu Adrian
