[Debian-med-packaging] Bug#1029178: vtk-dicom: autopkgtest failure

Adrian Bunk bunk at debian.org
Thu Jan 19 06:49:00 GMT 2023


On Wed, Jan 18, 2023 at 11:29:35PM +0100, Sebastian Ramacher wrote:
> Source: vtk-dicom
> Version: 0.8.14-3
> Severity: serious
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtk-dicom/30492694/log.gz
> 
> autopkgtest [23:14:01]: test autodep8-python3: set -e ; for py in $(py3versions -d 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import vtkdicom; print(vtkdicom)" ; done
> autopkgtest [23:14:01]: test autodep8-python3: [-----------------------
> Testing with python3.10:
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "/usr/lib/python3/dist-packages/vtkdicom/__init__.py", line 1, in <module>
>     from .vtkDICOM import *
> ModuleNotFoundError: No module named 'vtkdicom.vtkDICOM'

I don't see how this is the fault of the package,
or something the package could easily address.[1]

The package builds a Python C extension against the default Python3 
version only.

The autopkgtest tests this extension against the default Python3 version.

With python3/unstable the autopkgtest is passing:
https://ci.debian.net/packages/v/vtk-dicom/

Testing against a different python3 default fails for obvious reasons.

> Cheers

cu
Adrian

[1] Building a Python C extension against multiple Python3 versions is 
    easy for packages that build nothing else, but usually hard (and 
    rarely done) for packages that build Python bindings for a C/C++
    library as part of their normal build process.



More information about the Debian-med-packaging mailing list