Bug#1094895: camitk: FTBFS with ITK 5.4

[Steve M. Robbins]

Source: camitk
Version:
Severity: normal
Tags: ftbfs

ITK upstream has released v5.4 and I'd like to upload to Debian soon.
At present, ITK 5.4 is available in experimental.

I have done a test-rebuild locally of camitk, which failed one test:


The following tests FAILED:
188 - component-itkimage-level3-19 (Failed) component-
itkimage
Errors while running CTest




-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (700, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[Étienne Mollier]

Hi Emmanuel,

For information, the insighttoolkit 5.4 transition is ongoing,
and apparently it causes a regression in camitk.

Post by Steve M. Robbins
At present, ITK 5.4 is available in experimental.
188 - component-itkimage-level3-19 (Failed) component-
itkimage
Errors while running CTest

As far as I can see, the detail of the test error looks like:

188: Starting the camitk default application...
188: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-sbuild'
188: Failed to create /sbuild-nonexistent for shader cache (Permission denied)---disabling.
188: Failed to create /sbuild-nonexistent for shader cache (Permission denied)---disabling.
188: [OK]
188: Loading extension: /build/reproducible-path/camitk-5.2.0/camitk-build/lib/x86_64-linux-gnu/camitk-5.2/components/libitkimage.so...
188: Loaded extension: ItkImages Component (Manage any file type supported by itk and not by vtk in <b>CamiTK</b>.<br/>For
more info about image data format: <a href="http://www.dclunie.com/medical-image-faq/html">http://www.dclunie.com/medical-image-faq/html</a><br/><ul><li>hdr
is the Analyse header file format</li><li>spr is the Stimulate header file format</li><li>gipl is the Guys Image Processing Lab
Format</li><li>pic is the Bio-Rad file format, used by confocal micropscopes like MRC 1024 and MRC 600</li><li>LSM is a line of
confocal laser scanning microscopes produced by the Zeiss company</li><li>Nrrd is the "Nearly Raw Raster
Data"</li><li>NIfTI-1 (.nii) is adapted from the widely used ANALYZE 7.5 file format. For more info about image data format:
<a href="http://nifti.nimh.nih.gov/nifti-1/">http://nifti.nimh.nih.gov/nifti-1/</a> </li></ul>). Managed extension:hdr, spr, gipl, pic, lsm, nrrd,
hdr.gz, nii, nii.gz, img, img.gz
188: [OK]
188: Opening component: LittleEndianZ.hdr...
188: [OK]
188: Saving component to: LittleEndianZ.hdr...
188: [OK]
188: Closing component: LittleEndianZ.hdr...
188: [OK]
188: -- Comparing file "/build/reproducible-path/camitk-5.2.0/camitk-build/share/camitk-5.2/testdata/LittleEndianZ.hdr" to
"/build/reproducible-path/camitk-5.2.0/camitk-build/Testing/Temporary/component-itkimage-level3-19/LittleEndianZ.hdr"...
188: -- [FAIL]
188: CMake Error at /build/reproducible-path/camitk-5.2.0/sdk/cmake/modules/macros/camitk/test/CamiTKTestCompareFile.cmake:47 (message):
188: component-itkimage-level3-19:
188: /build/reproducible-path/camitk-5.2.0/camitk-build/Testing/Temporary/component-itkimage-level3-19/LittleEndianZ.hdr
188: does not match
188: /build/reproducible-path/camitk-5.2.0/camitk-build/share/camitk-5.2/testdata/LittleEndianZ.hdr

The faulty header looks like:

# xxd < /build/reproducible-path/camitk-5.2.0/camitk-build/Testing/Temporary/component-itkimage-level3-19/LittleEndianZ.hdr
00000000: 5c01 0000 0000 0000 0000 0000 0000 0000 \...............
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 7200 0300 0600 0600 0800 ......r.........
00000030: 0100 0100 0100 0100 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0400 1000 0000 0000 803f ...............?
00000050: 0000 803f 0000 803f 0000 803f 0000 0000 ...?...?...?....
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 803f 0000 0000 0000 000a 0000 0000 ...?............
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0100 0100 ................
00000100: 0000 0000 0000 0000 0000 803f 0000 0080 ...........?....
00000110: 0000 0080 0000 0000 0000 80bf 0000 0000 ................
00000120: 0000 0000 0000 0080 0000 0000 0000 80bf ................
00000130: 0000 0000 0000 0080 0000 0000 0000 0000 ................
00000140: 0000 803f 0000 0000 0000 0000 0000 0000 ...?............
00000150: 0000 0000 0000 0000 6e69 3100 0000 0000 ........ni1.....

To be compared to reference data:

$ xxd < ./camitk/imaging/components/itkimage/testdata/LittleEndianZ.hdr
00000000: 5c01 0000 0000 0000 0000 0000 0000 0000 \...............
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 7200 0300 0600 0600 0800 ......r.........
00000030: 0100 0100 0100 0100 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0400 1000 0000 0000 803f ...............?
00000050: 0000 803f 0000 803f 0000 803f 0000 0000 ...?...?...?....
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 803f 0000 0000 0000 0002 0000 0000 ...?............
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0100 0100 ................
00000100: 0000 0000 0000 0000 0000 803f 0000 0080 ...........?....
00000110: 0000 0080 0000 0000 0000 80bf 0000 0000 ................
00000120: 0000 0000 0000 0080 0000 0000 0000 80bf ................
00000130: 0000 0000 0000 0080 0000 0000 0000 0000 ................
00000140: 0000 803f 0000 0000 0000 0000 0000 0000 ...?............
00000150: 0000 0000 0000 0000 6e69 3100 0000 0000 ........ni1.....

The difference is around offset 0x70:

v
00000070: 0000 803f 0000 0000 0000 000a 0000 0000 ...?............
|
00000070: 0000 803f 0000 0000 0000 0002 0000 0000 ...?............
^

I'm afraid that I am not competent to dig deeper into resolving
the issue properly. I don't believe this is a big deal given
the coverage of the test suite, but I prefer asking first.
Please could you have a look?

Have a nice day, :)

[Étienne Mollier]

Hi Emmanuel,

Thank you very much for your detailed bug report.
I am currently adding a patch (simply disabling this specific test), that
should be hopefully pushed today on salsa.
As the test compare input data with output data, a update in the source code
of the I/O library generates a small output change.
This should not affect the overall quality of the software. The test will be
back in the next upstream release.
Thanks again for your time and help!

Thanks in return for the fixes, I have pushed your changes to
the archive to close the present bug.

Have a nice day, :)