[Debian-med-packaging] Bug#984063: Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

[Étienne Mollier]

Hello,

Andreas Tille, on 2022-01-16:
> Am Sun, Jan 16, 2022 at 07:07:01AM +0100 schrieb Sebastiaan Couwenberg:
> > On 1/15/22 21:45, Andreas Tille wrote:
> > > IMHO it would be sad to loose OTB.  When I once started looking at the
> > > packaging upstream was quite responsive.  Did you discussed the issue?
> > 
> > I did, see the comments in the MR linked above. OTB 9 should support ITK5,
> > but is not expected until the end of the year.
> 
> Thanks for the information.  I'm absolutely not in a hurry to file RM
> requests for insighttoolkit4 and I think it is not sensible to remove
> OTB just to reinject it later and waiting in new for a couple of months.
> So we can simply leave the situation as is if you ask me.  In case you
> might stumble upon a patch for insighttoolkit4 to build with recent gcc
> and there are good reasons to keep this and current otb in testing I'd
> volunteer to upload a fix for insighttoolkit4 (which I would not touch
> personally otherwise).

Specifically about the gcc-11 ftbfs, there is a patch [1] on an
alternate branch itk-4.y on Salsa [2].  There is however a test
failure affecting the handling of tiff file format [3]; it looks
present since introduction of tiff 4.3.0 or so.  

[1]: https://salsa.debian.org/med-team/insighttoolkit/-/blob/itk-4.y/debian/patches/gcc11.patch
[2]: https://salsa.debian.org/med-team/insighttoolkit/-/tree/itk-4.y
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984063#33

At some point I tried investigating how to reproduce the tiff
test failure with minimum requirements, to determine whether the
problem comes from the way itk4 calls the library, or if the
library itself is at fault, but I must admit I didn't manage to
get very far on that front given the intricaties of the test
system.

At this point, we don't have the cycles to maintain an itk4
legacy library for more Debian releases.  However, in case itk4
were really needed, an option which does not involve sacrificing
some test results could be to reinject the embedded code copy of
tiff 4.0.3 in itk4, and adjust d/rules to not use the operating
system tiff library.  This could work.  The drawback is that it
makes it problematic to maintain security wise, when issues must
be corrected in the tiff library, but I don't see other simple
options.

Anyways, in hope this clarifies the situation,
Kind Regards,
-- 
Étienne Mollier <emollier at emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.
On air: Camel - Lady Fantasy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20220116/a1d1d01c/attachment-0001.sig>