Debian Bug report logs - #984063
insighttoolkit4: ftbfs with GCC-11

Display info messages

Message #5 received at maintonly@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: maintonly@bugs.debian.org

Subject: insighttoolkit4: ftbfs with GCC-11

Date: Wed, 03 Mar 2021 16:13:31 +0000

Package: src:insighttoolkit4
Version: 4.13.3withdata-dfsg1-4
Severity: normal
Tags: sid bookworm
User: debian-gcc@lists.debian.org
Usertags: ftbfs-gcc-11

[This bug is not targeted to the upcoming bullseye release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/insighttoolkit4_4.13.3withdata-dfsg1-4_unstable_gcc11.log
The last lines of the build log are at the end of this report.

To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++ 

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-11/porting_to.html

GCC 11 defaults to the GNU++17 standard.  If your package installs
header files in /usr/include, please don't work around C++17 issues
by choosing a lower C++ standard for the package build, but fix these
issues to build with the C++17 standard.

[...]
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/vnl_vector.h:556:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
  556 | VCL_TEMPLATE_EXPORT template <class T> VNL_TEMPLATE_EXPORT std::istream& operator>>(std::istream &, vnl_vector<T>      &);
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/vnl_vector_ref.h:26:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
   26 | VCL_TEMPLATE_EXPORT template <class T>
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/vnl_matrix.h:56:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
   56 | VCL_TEMPLATE_EXPORT template <class T> class vnl_vector;
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/vnl_matrix.h:57:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
   57 | VCL_TEMPLATE_EXPORT template <class T> class vnl_matrix;
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/vnl_vector_fixed.h:43:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
   43 | VCL_TEMPLATE_EXPORT template <class T, unsigned int n> class vnl_vector_fixed;
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/vnl_vector_fixed.h:44:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
   44 | VCL_TEMPLATE_EXPORT template <class T, unsigned int num_rows, unsigned int num_cols> class vnl_matrix_fixed;
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/vnl_matrix_fixed.h:42:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
   42 | VCL_TEMPLATE_EXPORT template <class T, unsigned int num_rows, unsigned int num_cols> class vnl_matrix_fixed;
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/vnl_diag_matrix.h:40:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
   40 | VCL_TEMPLATE_EXPORT template <class T>
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/algo/vnl_svd.h:63:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
   63 | VCL_TEMPLATE_EXPORT template <class T>
      | ^~~~~~~~~~~~~~~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:114:30: warning: keyword ‘export’ is deprecated, and is ignored
  114 | # define VCL_TEMPLATE_EXPORT export
      |                              ^~~~~~
/<<PKGBUILDDIR>>/Modules/ThirdParty/VNL/src/vxl/core/vnl/algo/vnl_svd.h:206:1: note: in expansion of macro ‘VCL_TEMPLATE_EXPORT’
  206 | VCL_TEMPLATE_EXPORT template <class T>
      | ^~~~~~~~~~~~~~~~~~~
[ 53%] Linking CXX executable ../../../../bin/ITKLevelSetsv4TestDriver
cd /<<PKGBUILDDIR>>/BUILD/Modules/Segmentation/LevelSetsv4/test && /usr/bin/cmake -E cmake_link_script CMakeFiles/ITKLevelSetsv4TestDriver.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/nifti -g1  -Wall -Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -funit-at-a-time -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual -Wstrict-null-sentinel  -fuse-ld=gold -Wl,-z,relro  -rdynamic -fPIE -pie CMakeFiles/ITKLevelSetsv4TestDriver.dir/ITKLevelSetsv4TestDriver.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetDenseImageTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkWhitakerSparseLevelSetImageTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkShiSparseLevelSetImageTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkMalcolmSparseLevelSetImageTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkBinaryImageToWhitakerSparseLevelSetAdaptorTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkBinaryImageToMalcolmSparseLevelSetAdaptorTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkBinaryImageToShiSparseLevelSetAdaptorTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationChanAndVeseExternalTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationChanAndVeseInternalTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationCurvatureTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationLaplacianTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationPropagationTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationBinaryMaskTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationOverlapPenaltyTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationRegionTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationTermBaseTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEquationTermContainerTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetDomainPartitionBaseTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetDomainPartitionImageTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetDomainPartitionImageWithKdTreeTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetDomainMapImageFilterTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkDenseLevelSetContainerTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSparseLevelSetContainerTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSingleLevelSetDenseImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSingleLevelSetDenseAdvectionImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSingleLevelSetWhitakerImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSingleLevelSetMalcolmImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSingleLevelSetShiImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSingleLevelSetWhitakerImage2DWithCurvatureTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSingleLevelSetWhitakerImage2DWithLaplacianTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkSingleLevelSetWhitakerImage2DWithPropagationTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkTwoLevelSetDenseImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkTwoLevelSetWhitakerImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkTwoLevelSetMalcolmImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkTwoLevelSetShiImage2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkMultiLevelSetDenseImageTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkMultiLevelSetChanAndVeseInternalTermTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkMultiLevelSetEvolutionTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkMultiLevelSetDenseImageSubset2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkMultiLevelSetWhitakerImageSubset2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkMultiLevelSetShiImageSubset2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkMultiLevelSetMalcolmImageSubset2DTest.cxx.o CMakeFiles/ITKLevelSetsv4TestDriver.dir/itkLevelSetEvolutionNumberOfIterationsStoppingCriterionTest.cxx.o -o ../../../../bin/ITKLevelSetsv4TestDriver  ../../../../lib/libITKQuadEdgeMesh-4.13.so.1 ../../../../lib/libITKLabelMap-4.13.so.1 ../../../../lib/libITKStatistics-4.13.so.1 ../../../../lib/libITKSpatialObjects-4.13.so.1 ../../../../lib/libITKPath-4.13.so.1 /usr/lib/x86_64-linux-gnu/libdouble-conversion.so.3.1 /usr/lib/x86_64-linux-gnu/libdouble-conversion.so.3.1 ../../../../lib/libITKIOBMP-4.13.so.1 ../../../../lib/libITKIOGDCM-4.13.so.1 ../../../../lib/libITKIOGIPL-4.13.so.1 ../../../../lib/libITKIOJPEG-4.13.so.1 ../../../../lib/libITKIOMeta-4.13.so.1 ../../../../lib/libITKIONIFTI-4.13.so.1 ../../../../lib/libITKIONRRD-4.13.so.1 ../../../../lib/libITKIOPNG-4.13.so.1 ../../../../lib/libITKIOTIFF-4.13.so.1 ../../../../lib/libITKIOVTK-4.13.so.1 ../../../../lib/libITKMesh-4.13.so.1 ../../../../lib/libitkNetlibSlatec-4.13.so.1 /usr/lib/x86_64-linux-gnu/libgdcmMSFF.so.3.0.8 /usr/lib/x86_64-linux-gnu/libgdcmDICT.so.3.0.8 /usr/lib/x86_64-linux-gnu/libgdcmIOD.so.3.0.8 /usr/lib/x86_64-linux-gnu/libgdcmDSED.so.3.0.8 /usr/lib/x86_64-linux-gnu/libgdcmCommon.so.3.0.8 ../../../../lib/libITKMetaIO-4.13.so.1 ../../../../lib/libITKTransform-4.13.so.1 -lz ../../../../lib/libITKIOImageBase-4.13.so.1 ../../../../lib/libITKCommon-4.13.so.1 ../../../../lib/libitksys-4.13.so.1 ../../../../lib/libITKVNLInstantiation-4.13.so.1 ../../../../lib/libitkvnl_algo-4.13.so.1 ../../../../lib/libitkvnl-4.13.so.1 ../../../../lib/libitkv3p_netlib-4.13.so.1 ../../../../lib/libitknetlib-4.13.so.1 ../../../../lib/libitkvcl-4.13.so.1 -lm -lpthread -lm -ldl -Wl,-rpath-link,/<<PKGBUILDDIR>>/BUILD/lib 
make[3]: Leaving directory '/<<PKGBUILDDIR>>/BUILD'
[ 53%] Built target ITKLevelSetsv4TestDriver
make[2]: Leaving directory '/<<PKGBUILDDIR>>/BUILD'
make[1]: *** [Makefile:185: all] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>/BUILD'
dh_auto_build: error: cd BUILD && make -j4 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:84: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Message #18 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Jose Luis Rivero <jrivero@openrobotics.org>

To: 984063@bugs.debian.org

Date: Sat, 6 Nov 2021 01:33:29 +0100

[Message part 1 (text/plain, inline)]

Hello! Gazebo maintainer here, affected by this RC bug. Looking into
upstream repository there is a potential commit that can be used to patch
this problem until new versions land in Debian:

https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359a8fdb55304124823a3a8c9

Let me know if you need more help or assistance.
Thanks!

[Message part 2 (text/html, inline)]

Message #23 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: Jose Luis Rivero <jrivero@openrobotics.org>, 984063@bugs.debian.org, Debian Med Project List <debian-med@lists.debian.org>

Cc: "Steve M. Robbins" <smr@debian.org>, 995829@bugs.debian.org, Ghislain Vaillant <ghisvail@gmail.com>

Subject: Please lets coordinate itk4/itk5 issues (Was: Bug#984063)

Date: Mon, 8 Nov 2021 08:09:43 +0100

Hi,

this mail from Jose 

Am Sat, Nov 06, 2021 at 01:33:29AM +0100 schrieb Jose Luis Rivero:
> Hello! Gazebo maintainer here, affected by this RC bug. Looking into
> upstream repository there is a potential commit that can be used to patch
> this problem until new versions land in Debian:
> 
> https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359a8fdb55304124823a3a8c9

caused me having a look into the Git repository of insighttoolkit4[1].
It is missing the NMU 4.13.3withdata-dfsg1-4.1 by Andreas Beckmann and
there are now the first commits done by Steve for insighttoolkit5
version 5.2.1 which was ITPed by Ghislain[2].

I think we need to discuss whether

  1. We want to simply replace insighttoolkit4 (which makes the
     usage of the existing repository[1] sensible - but please inject
     the NMU changes at least in d/changelog

  2. We should start ITK5 in a new repository and maintain both
     versions at least for some time in parallel until all packages
     that currently use ITK4 are migrated.

In any case people who are interested in ITK should coordinate their
work and talk to each other which I'd like to kindly invite you to
do here on the Debian Med mailing list (any other channel is fine for
sure).

> Let me know if you need more help or assistance.

Every assistance is welcome.  BTW, I tried to apply the mentioned patch
to insighttoolkit4  4.13.3withdata-dfsg1-4.1  but it does not apply.  I
did not investigated why since I think some things should be clarified
first.

Kind regards

      Andreas.

[1] https://salsa.debian.org/med-team/insighttoolkit
[2] https://bugs.debian.org/995829

-- 
http://fam-tille.de

Message #28 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Steven Robbins <steve@sumost.ca>

To: Jose Luis Rivero <jrivero@openrobotics.org>, 984063@bugs.debian.org, Debian Med Project List <debian-med@lists.debian.org>, 995829@bugs.debian.org

Cc: Ghislain Vaillant <ghisvail@gmail.com>

Subject: Re: Please lets coordinate itk4/itk5 issues (Was: Bug#984063)

Date: Mon, 08 Nov 2021 07:15:03 -0600

[Message part 1 (text/plain, inline)]

On Monday, November 8, 2021 1:09:43 A.M. CST Andreas Tille wrote:
> Hi,
> 
> this mail from Jose
> 
> Am Sat, Nov 06, 2021 at 01:33:29AM +0100 schrieb Jose Luis Rivero:
> > Hello! Gazebo maintainer here, affected by this RC bug. Looking into
> > upstream repository there is a potential commit that can be used to patch
> > this problem until new versions land in Debian:
> > 
> > https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359
> > a8fdb55304124823a3a8c9

Are you saying this will allow ITKv4 to be built with current gcc?  At 
present, ITK is about to be removed from testing tomorrow because it won't 
build.

> caused me having a look into the Git repository of insighttoolkit4[1].
> It is missing the NMU 4.13.3withdata-dfsg1-4.1 by Andreas Beckmann and
> there are now the first commits done by Steve for insighttoolkit5
> version 5.2.1 which was ITPed by Ghislain[2].

Yep, I've already uploaded ITK 5 to Debian.
https://ftp-master.debian.org/new/insighttoolkit5_5.2.1-1.html

> I think we need to discuss whether
> 
>   1. We want to simply replace insighttoolkit4 (which makes the
>      usage of the existing repository[1] sensible - but please inject
>      the NMU changes at least in d/changelog

Yes.  This is what I've communicated already 2-3 times on the list -- going 
back a year -- and in Ghislain's ITP.

https://lists.debian.org/debian-med/2020/11/msg00212.html
https://lists.debian.org/debian-med/2021/10/msg00149.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995829#10


>   2. We should start ITK5 in a new repository and maintain both
>      versions at least for some time in parallel until all packages
>      that currently use ITK4 are migrated.

If we can get ITK4 to build with current compilers, my suggestion would be to 
make a v4 branch in the current repository.  On the other hand, it's kind of 
11th hour here.  I'm much more focused on replacing v4 with v5 -- which, to be 
fair is already more than two years old.  ITK v4 is no longer supported 
upstream.
 
> In any case people who are interested in ITK should coordinate their
> work and talk to each other which I'd like to kindly invite you to
> do here on the Debian Med mailing list (any other channel is fine for
> sure).

Yes, I've always used debian-med for communications.  Additional hands are 
always welcomed.

-Steve

[signature.asc (application/pgp-signature, inline)]

Message #33 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Étienne Mollier <emollier@emlwks999.eu>

To: Steven Robbins <steve@sumost.ca>, 984063@bugs.debian.org

Cc: Jose Luis Rivero <jrivero@openrobotics.org>, Debian Med Project List <debian-med@lists.debian.org>, 995829@bugs.debian.org, Ghislain Vaillant <ghisvail@gmail.com>

Subject: Re: [Debian-med-packaging] Bug#984063: Please lets coordinate itk4/itk5 issues (Was: Bug#984063)

Date: Mon, 8 Nov 2021 23:37:50 +0100

[Message part 1 (text/plain, inline)]

Hi all,

Steven Robbins, on 2021-11-08:
> On Monday, November 8, 2021 1:09:43 A.M. CST Andreas Tille wrote:
>> Am Sat, Nov 06, 2021 at 01:33:29AM +0100 schrieb Jose Luis Rivero:
>>> Hello! Gazebo maintainer here, affected by this RC bug. Looking into
>>> upstream repository there is a potential commit that can be used to patch
>>> this problem until new versions land in Debian:
>>> 
>>> https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359
>>> a8fdb55304124823a3a8c9

Thanks Jose for the pointer!  I took the liberty to take
inspiration from this commit and came up with the patch in
attachment applying to ITKv4 in Debian.  This solves the build
failure, but the test suite then seems to choke on two TIFF
related functions:

	1128/2926 Testing: itkTIFFImageIOPlannarConfig2
	1128/2926 Test: itkTIFFImageIOPlannarConfig2
	Command: "/<<PKGBUILDDIR>>/BUILD/bin/ITKIOTIFFTestDriver" "--compare-MD5"
		"/<<PKGBUILDDIR>>/BUILD/Testing/Temporary/itkTIFFImageIOPlannarConfig2.tif"
		"91975481ba66709c8f3ccb538af5cd2a" "itkTIFFImageIOTest"
		"/<<PKGBUILDDIR>>/BUILD/ExternalData/Modules/IO/TIFF/test/Input/ps-separated.tif"
		"/<<PKGBUILDDIR>>/BUILD/Testing/Temporary/itkTIFFImageIOPlannarConfig2.tif" "2" "1"
	Directory: /<<PKGBUILDDIR>>/BUILD/Modules/IO/TIFF/test
	"itkTIFFImageIOPlannarConfig2" start time: Nov 06 23:13 UTC
	Output:
	----------------------------------------------------------
	Trying reader->Update()
	<end of output>
	Test time =   0.03 sec
	----------------------------------------------------------
	Test Failed.
	"itkTIFFImageIOPlannarConfig2" end time: Nov 06 23:13 UTC
	"itkTIFFImageIOPlannarConfig2" time elapsed: 00:00:00
	----------------------------------------------------------
	[…]
	1130/2926 Testing: itkTIFFImageIOInfoTest2
	1130/2926 Test: itkTIFFImageIOInfoTest2
	Command: "/<<PKGBUILDDIR>>/BUILD/bin/ITKIOTIFFTestDriver" "itkTIFFImageIOInfoTest"
		"/<<PKGBUILDDIR>>/BUILD/ExternalData/Modules/IO/TIFF/test/Input/ps-separated.tif"
	Directory: /<<PKGBUILDDIR>>/BUILD/Modules/IO/TIFF/test
	"itkTIFFImageIOInfoTest2" start time: Nov 06 23:13 UTC
	Output:
	----------------------------------------------------------
	<end of output>
	Test time =   0.04 sec
	----------------------------------------------------------
	Test Fail Reason:
	Required regular expression not found. Regex=[2014:09:24 14:16:01
	]
	"itkTIFFImageIOInfoTest2" end time: Nov 06 23:13 UTC
	"itkTIFFImageIOInfoTest2" time elapsed: 00:00:00
	----------------------------------------------------------
	[…]
	The following tests FAILED:
	        1128 - itkTIFFImageIOPlannarConfig2 (SEGFAULT)
	        1130 - itkTIFFImageIOInfoTest2 (SEGFAULT)

If I lookup my kernel output with dmesg, then I see the process
ITKIOTIFFTestDriver:

	[3904521.677802] ITKIOTIFFTestDr[3973924]: segfault at 0 ip 00007f8f2a1468b5 sp 00007ffc74945dd0 error 6 in libtiff.so.5.7.0[7f8f2a142000+47000]
	[3904521.677813] Code: 48 8b 00 f3 0f 10 03 f3 0f 11 00 e9 70 ee ff ff 41 8b 16 83 fa 2f 77 58 89 d0 83 c2 08 49 03 46 10 41 89 16 48 8b 00 48
		8b 13 <48> 89 10 e9 4e ee ff ff 48 8d 0d 0c 3a 04 00 ba 9a 04 00 00 48 8d
	[3904521.706743] ITKIOTIFFTestDr[3973948]: segfault at 0 ip 00007f7eb8d9a8b5 sp 00007fff3196c920 error 6 in libtiff.so.5.7.0[7f7eb8d96000+47000]
	[3904521.706755] Code: 48 8b 00 f3 0f 10 03 f3 0f 11 00 e9 70 ee ff ff 41 8b 16 83 fa 2f 77 58 89 d0 83 c2 08 49 03 46 10 41 89 16 48 8b 00 48
		8b 13 <48> 89 10 e9 4e ee ff ff 48 8d 0d 0c 3a 04 00 ba 9a 04 00 00 48 8d

I haven't pushed investigations further for the moment.  This
possibly appeared with tiff 4.3.0, and probably got fixed in
ITKv5 as well.

>> caused me having a look into the Git repository of insighttoolkit4[1].
>> It is missing the NMU 4.13.3withdata-dfsg1-4.1 by Andreas Beckmann and
>> there are now the first commits done by Steve for insighttoolkit5
>> version 5.2.1 which was ITPed by Ghislain[2].
> 
> Yep, I've already uploaded ITK 5 to Debian.
> https://ftp-master.debian.org/new/insighttoolkit5_5.2.1-1.html

Thank you Steve for your trying to move ITKv5 forwards in
Debian!  :)  I guess the missing entries can be put back after
the package is out of NEW?

> If we can get ITK4 to build with current compilers, my suggestion would be to 
> make a v4 branch in the current repository.  On the other hand, it's kind of 
> 11th hour here.  I'm much more focused on replacing v4 with v5 -- which, to be 
> fair is already more than two years old.  ITK v4 is no longer supported 
> upstream.

Given the current layout, I'm considering the following
d/gbp.conf if names are okay, namimg things is hard.  The
disabled pristine-tar is because of the way the multiple
tarballs of the source are combined:

	[DEFAULT]
	debian-branch = itk-4.y
	upstream-branch = upstream-itk-4.y
	pristine-tar = False

While trying to keep insighttoolkit4 available in bookworm would
be nice for our users, this also involves maintaining two years
of backporting fixes brought to v5 into v4.  It's quite possible
we hit several other brick walls before bookworm around 2023, so
I agree priority should be to migrate to v5.

>> In any case people who are interested in ITK should coordinate their
>> work and talk to each other which I'd like to kindly invite you to
>> do here on the Debian Med mailing list (any other channel is fine for
>> sure).
> 
> Yes, I've always used debian-med for communications.  Additional hands are 
> always welcomed.

Sorry I didn't ping on this topic earlier, I probably should
have done so when looking up the build failure on Saturday.

In hope this helps,
Kind Regards,
-- 
Étienne Mollier <emollier@emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.

[gcc11.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #38 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Étienne Mollier <emollier@emlwks999.eu>

To: Steven Robbins <steve@sumost.ca>, 984063@bugs.debian.org

Cc: Jose Luis Rivero <jrivero@openrobotics.org>, Debian Med Project List <debian-med@lists.debian.org>, 995829@bugs.debian.org, Ghislain Vaillant <ghisvail@gmail.com>

Subject: Re: [Debian-med-packaging] Bug#984063: Please lets coordinate itk4/itk5 issues (Was: Bug#984063)

Date: Tue, 9 Nov 2021 23:34:13 +0100

[Message part 1 (text/plain, inline)]

Étienne Mollier, on 2021-11-08:
> I haven't pushed investigations further for the moment.  This
> possibly appeared with tiff 4.3.0, and probably got fixed in
> ITKv5 as well.

Or not, the embedded copy is still libtiff 4.0.3 in ITKv5
instead of the version 4.3.0.  Maybe something went wrong with
our system tiff library, or the way it is called needs change;
it's probably worth pinging upstream.

> Steven Robbins, on 2021-11-08:
>> On Monday, November 8, 2021 1:09:43 A.M. CST Andreas Tille wrote:
>>> caused me having a look into the Git repository of insighttoolkit4[1].
>>> It is missing the NMU 4.13.3withdata-dfsg1-4.1 by Andreas Beckmann and
>>> there are now the first commits done by Steve for insighttoolkit5
>>> version 5.2.1 which was ITPed by Ghislain[2].

Acknowledged the NMU from the ITKv4 branch below:
> 	[DEFAULT]
> 	debian-branch = itk-4.y
> 	upstream-branch = upstream-itk-4.y
> 	pristine-tar = False

Layout pushed to the repository [1], to avoid stalling potential
other efforts.  This should ease steps for other contributors
used to build with `gbp buildpackage`, although other functions
are not quite available, such as import-orig; but that should
not be needed on that particular branch since this version 4 is
end of life.

[1]: https://salsa.debian.org/med-team/insighttoolkit/

In hope this helps,
Kind Regards,
-- 
Étienne Mollier <emollier@emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.

[signature.asc (application/pgp-signature, inline)]

Message #43 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Étienne Mollier <emollier@emlwks999.eu>, 984063@bugs.debian.org

Cc: Steven Robbins <steve@sumost.ca>, Jose Luis Rivero <jrivero@openrobotics.org>, Debian Med Project List <debian-med@lists.debian.org>, Ghislain Vaillant <ghisvail@gmail.com>, 984284@bugs.debian.org

Subject: Re: Bug#984063: [Debian-med-packaging] Bug#984063: Please lets coordinate itk4/itk5 issues (Was: Bug#984063)

Date: Thu, 9 Dec 2021 19:09:21 +0200

On Tue, Nov 09, 2021 at 11:34:13PM +0100, Étienne Mollier wrote:
> Étienne Mollier, on 2021-11-08:
> > I haven't pushed investigations further for the moment.  This
> > possibly appeared with tiff 4.3.0, and probably got fixed in
> > ITKv5 as well.
> 
> Or not, the embedded copy is still libtiff 4.0.3 in ITKv5
> instead of the version 4.3.0.  Maybe something went wrong with
> our system tiff library, or the way it is called needs change;
> it's probably worth pinging upstream.
>...

ITKv5 appears to build, how was it fixed there?

The other problem is #984284, which seems to require a rename
of the libinsighttoolkit4.13 package.

> In hope this helps,
> Kind Regards,

cu
Adrian

Message #48 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Étienne Mollier <emollier@emlwks999.eu>

To: Adrian Bunk <bunk@debian.org>

Cc: 984063@bugs.debian.org, Steven Robbins <steve@sumost.ca>, Jose Luis Rivero <jrivero@openrobotics.org>, Debian Med Project List <debian-med@lists.debian.org>, Ghislain Vaillant <ghisvail@gmail.com>, 984284@bugs.debian.org

Subject: Re: Bug#984063: itk libtiff test issues (Was: Bug#984063)

Date: Sat, 11 Dec 2021 10:02:02 +0100

[Message part 1 (text/plain, inline)]

Hi Adrian,

Adrian Bunk, on 2021-12-09:
> On Tue, Nov 09, 2021 at 11:34:13PM +0100, Étienne Mollier wrote:
> > Étienne Mollier, on 2021-11-08:
> > > I haven't pushed investigations further for the moment.  This
> > > possibly appeared with tiff 4.3.0, and probably got fixed in
> > > ITKv5 as well.
> > 
> > Or not, the embedded copy is still libtiff 4.0.3 in ITKv5
> > instead of the version 4.3.0.  Maybe something went wrong with
> > our system tiff library, or the way it is called needs change;
> > it's probably worth pinging upstream.
> >...
> 
> ITKv5 appears to build, how was it fixed there?

If I append -DITK_USE_SYSTEM_TIFF:BOOL=ON, I see the same
segmentation faults already witnessed in itk4, so guess the
tiff 4.0.3 embedded works these issues around:

	1129: Test command:
		/<<PKGBUILDDIR>>/BUILD/bin/ITKIOTIFFTestDriver "--compare-MD5" "/<<PKGBUILDDIR>>/BUILD/Testing/Temporary/itkTIFFImageIOPlannarConfig2.tif" "91975481ba66709c8f3ccb538af5cd2a" "itkTIFFImageIOTest" "/<<PKGBUILDDIR>>/BUILD/ExternalData/Modules/IO/TIFF/test/Input/ps-separated.tif" "/<<PKGBUILDDIR>>/BUILD/Testing/Temporary/itkTIFFImageIOPlannarConfig2.tif" "2" "1"
	1129: Test timeout computed to be: 1500
	1129: Trying reader->Update()
	1129/2826 Testing: itkTIFFImageIOPlannarConfig2
	1129/2826 Test: itkTIFFImageIOPlannarConfig2

	1132: Test command:
		/<<PKGBUILDDIR>>/BUILD/bin/ITKIOTIFFTestDriver "itkTIFFImageIOInfoTest" "/<<PKGBUILDDIR>>/BUILD/ExternalData/Modules/IO/TIFF/test/Input/ps-separated.tif"
	1132: Test timeout computed to be: 1500
	1132/2826 Testing: itkTIFFImageIOInfoTest2
	1132/2826 Test: itkTIFFImageIOInfoTest2

There are also additionnal failures.  I suspect these are new
checks from itk5 to properly support large tiff images, greater
in size than 4GiB:

	1148: Test command: /<<PKGBUILDDIR>>/BUILD/bin/ITKIOTIFFTestDriver "itkLargeTIFFImageWriteReadTest" "/<<PKGBUILDDIR>>/BUILD/Testing/Temporary/LargeImage02.tif" "40000L"
	1148: Test timeout computed to be: 1500
	1148: Trying to allocate an image of size 3051 MiB 
	1148: Initializing pixel values
	1148: Trying to write the image to disk
	1148: Trying writer->Update()
	1148: 
	1148: itk::ExceptionObject (0x55906ce88950)
	1148: Location: "void itk::TIFFImageIO::InternalWrite(const void*)" 
	1148: File: ./Modules/IO/TIFF/src/itkTIFFImageIO.cxx
	1148: Line: 622
	1148: Description: ITK ERROR: TIFFImageIO(0x55906ce89950): Size of image exceeds the limit of libtiff.
	1148: 
	1148: 
	1148:   In ./Modules/IO/TIFF/test/itkLargeTIFFImageWriteReadTest.cxx, line 104
	2825/2826 Test #1148: itkLargeTIFFImageWriteReadTest2 ........................................................................***Failed    2.85 sec

	1149: Test command: /<<PKGBUILDDIR>>/BUILD/bin/ITKIOTIFFTestDriver "itkLargeTIFFImageWriteReadTest" "/<<PKGBUILDDIR>>/BUILD/Testing/Temporary/LargeImage03.tif" "50000L"
	1149: Test timeout computed to be: 1500
	1149: Trying to allocate an image of size 4768 MiB 
	1149: Initializing pixel values
	1149: Trying to write the image to disk
	1149: Trying writer->Update()
	1149: 
	1149: itk::ExceptionObject (0x56036aeef950)
	1149: Location: "void itk::TIFFImageIO::InternalWrite(const void*)" 
	1149: File: ./Modules/IO/TIFF/src/itkTIFFImageIO.cxx
	1149: Line: 622
	1149: Description: ITK ERROR: TIFFImageIO(0x56036aef0950): Size of image exceeds the limit of libtiff.
	1149: 
	1149: 
	1149:   In ./Modules/IO/TIFF/test/itkLargeTIFFImageWriteReadTest.cxx, line 104
	2826/2826 Test #1149: itkLargeTIFFImageWriteReadTest3 ........................................................................***Failed    4.93 sec

	1150: Test command: /<<PKGBUILDDIR>>/BUILD/bin/ITKIOTIFFTestDriver "itkLargeTIFFImageWriteReadTest" "/<<PKGBUILDDIR>>/BUILD/Testing/Temporary/LargeImage04.tif" "70000L"
	1150: Test timeout computed to be: 1500
	1150: Trying to allocate an image of size 9346 MiB 
	1150: Initializing pixel values
	1150: Trying to write the image to disk
	1150: Trying writer->Update()
	1150: 
	1150: itk::ExceptionObject (0x563af54b4950)
	1150: Location: "void itk::TIFFImageIO::InternalWrite(const void*)" 
	1150: File: ./Modules/IO/TIFF/src/itkTIFFImageIO.cxx
	1150: Line: 622
	1150: Description: ITK ERROR: TIFFImageIO(0x563af54b5950): Size of image exceeds the limit of libtiff.
	1150: 
	1150: 
	1150:   In ./Modules/IO/TIFF/test/itkLargeTIFFImageWriteReadTest.cxx, line 104
	2040/2826 Test #1150: itkLargeTIFFImageWriteReadTest4 ........................................................................***Failed   10.33 sec

The embedded copy of libtiff is excluded from itk4 .dsc.  I
would prefer not putting it back, given the trail of security
issues behind tiff.

I considered pushing a change yesterday to disable those tests
on insighttoolkit4, not to hide dust under the carpet, but to
give a chance to reverse dependencies to make it to testing in a
decent enough shape hopefuly.  However I caught a build issue in
the meantime:

	[  3%] Generating /<<PKGBUILDDIR>>/BUILD/ExternalData/Modules/Filtering/Deconvolution/test/Baseline/itkWienerDeconvolutionImageFilterIrregularKernelTest.nrrd
	usr/bin/cmake -Drelative_top=/<<PKGBUILDDIR>>/BUILD -Dfile=/<<PKGBUILDDIR>>/BUILD/ExternalData/Modules/Filtering/Deconvolution/test/Baseline/itkWienerDeconvolutionImageFilterIrregularKernelTest.nrrd -Dname=/<<PKGBUILDDIR>>/Modules/Filtering/Deconvolution/test/Baseline/itkWienerDeconvolutionImageFilterIrregularKernelTest.nrrd -Dexts=.md5+.sha512 -DExternalData_ACTION=fetch -DExternalData_CONFIG=/<<PKGBUILDDIR>>/BUILD/ITKData_config.cmake -P /<<PKGBUILDDIR>>/CMake/ExternalData.cmake
	-- Found object: "/<<PKGBUILDDIR>>/data/.ExternalData/MD5/58a1c99268c5f29b8b1ad1ae68529205"
	In file included from /<<PKGBUILDDIR>>/BUILD/Wrapping/ITKCommonBase.cxx:12:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkImage.h:28:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkNeighborhoodAccessorFunctor.h:21:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkImageBoundaryCondition.h:22:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkNeighborhood.h:24:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkSliceIterator.h:23:
	/usr/include/c++/11/valarray:1215:5: error: exception specification in declaration does not match previous declaration
	    begin(valarray<_Tp>& __va) noexcept
	    ^
	/usr/include/c++/11/bits/range_access.h:107:31: note: previous declaration is here
	  template<typename _Tp> _Tp* begin(valarray<_Tp>&);
	                              ^
	In file included from /<<PKGBUILDDIR>>/BUILD/Wrapping/ITKCommonBase.cxx:12:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkImage.h:28:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkNeighborhoodAccessorFunctor.h:21:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkImageBoundaryCondition.h:22:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkNeighborhood.h:24:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkSliceIterator.h:23:
	/usr/include/c++/11/valarray:1226:5: error: exception specification in declaration does not match previous declaration
	    begin(const valarray<_Tp>& __va) noexcept
	    ^
	/usr/include/c++/11/bits/range_access.h:108:37: note: previous declaration is here
	  template<typename _Tp> const _Tp* begin(const valarray<_Tp>&);
	                                    ^
	In file included from /<<PKGBUILDDIR>>/BUILD/Wrapping/ITKCommonBase.cxx:12:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkImage.h:28:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkNeighborhoodAccessorFunctor.h:21:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkImageBoundaryCondition.h:22:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkNeighborhood.h:24:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkSliceIterator.h:23:
	/usr/include/c++/11/valarray:1237:5: error: exception specification in declaration does not match previous declaration
	    end(valarray<_Tp>& __va) noexcept
	    ^
	/usr/include/c++/11/bits/range_access.h:109:31: note: previous declaration is here
	  template<typename _Tp> _Tp* end(valarray<_Tp>&);
	                              ^
	In file included from /<<PKGBUILDDIR>>/BUILD/Wrapping/ITKCommonBase.cxx:12:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkImage.h:28:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkNeighborhoodAccessorFunctor.h:21:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkImageBoundaryCondition.h:22:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkNeighborhood.h:24:
	In file included from /<<PKGBUILDDIR>>/Modules/Core/Common/include/itkSliceIterator.h:23:
	/usr/include/c++/11/valarray:1253:5: error: exception specification in declaration does not match previous declaration
	    end(const valarray<_Tp>& __va) noexcept
	    ^
	/usr/include/c++/11/bits/range_access.h:110:37: note: previous declaration is here
	  template<typename _Tp> const _Tp* end(const valarray<_Tp>&);

I'm a bit dry about the root cause right now.

> The other problem is #984284, which seems to require a rename
> of the libinsighttoolkit4.13 package.

I attempted to build otb against itk5, but it's not ready for
the version bump yet apparently.  What rename did you have in
mind for the libinsighttoolkit4.13 package exactly?

Thanks for jumping in,  :)
-- 
Étienne Mollier <emollier@emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.

[signature.asc (application/pgp-signature, inline)]

Message #53 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Steven Robbins <steve@sumost.ca>

To: Adrian Bunk <bunk@debian.org>, Étienne Mollier <emollier@emlwks999.eu>

Cc: 984063@bugs.debian.org, Jose Luis Rivero <jrivero@openrobotics.org>, Debian Med Project List <debian-med@lists.debian.org>, Ghislain Vaillant <ghisvail@gmail.com>, 984284@bugs.debian.org

Subject: Re: Bug#984063: itk libtiff test issues (Was: Bug#984063)

Date: Sat, 11 Dec 2021 04:13:14 -0600

[Message part 1 (text/plain, inline)]

On Saturday, December 11, 2021 3:02:02 A.M. CST Étienne Mollier wrote:

> I considered pushing a change yesterday to disable those tests
> on insighttoolkit4, 

Let's please agree to NEVER do that.


> not to hide dust under the carpet, but to
> give a chance to reverse dependencies to make it to testing in a
> decent enough shape hopefuly.  

I appreciate the sentiment, but medical & scientific software -- probably the 
only consumers of ITK -- is generally the sort that you never want to 
knowingly ship with failed tests.  

-Steve

[signature.asc (application/pgp-signature, inline)]

Message #58 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Étienne Mollier <emollier@emlwks999.eu>

To: Steven Robbins <steve@sumost.ca>

Cc: Adrian Bunk <bunk@debian.org>, 984063@bugs.debian.org, Jose Luis Rivero <jrivero@openrobotics.org>, Debian Med Project List <debian-med@lists.debian.org>, Ghislain Vaillant <ghisvail@gmail.com>, 984284@bugs.debian.org

Subject: Re: Bug#984063: itk libtiff test issues (Was: Bug#984063)

Date: Sat, 11 Dec 2021 16:02:09 +0100

[Message part 1 (text/plain, inline)]

Hi there,

About the build error I caught with itk4 on <valarray>, this
looks to be caused by a gcc bug in the headers files [1],
causing failures to build source code including <valarray> with
clang, compiler which is in use through castxml, which in turn
is used for constructing the wrapper ITKCommonBase.  itk5 dsc is
not affected as wrappers are not built anymore on its side, so
disabling wrappers for itk4 too might be a viable option while
#1000398 is being worked on (to at least reproduce the tiff test
failures).  The build error may otherwise solve by itself with
an upcoming gcc version.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000398


From Steven Robbins:
> On Saturday, December 11, 2021 3:02:02 A.M. CST Étienne Mollier wrote:
> > I considered pushing a change yesterday to disable those tests
> > on insighttoolkit4,
> 
> Let's please agree to NEVER do that.

So be it.  I agree and deleted my ugly workaround before it
makes it downstream.

Kind Regards,
-- 
Étienne Mollier <emollier@emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.

[signature.asc (application/pgp-signature, inline)]

Message #63 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Étienne Mollier <emollier@emlwks999.eu>

Cc: Steven Robbins <steve@sumost.ca>, 984063@bugs.debian.org, Jose Luis Rivero <jrivero@openrobotics.org>, Debian Med Project List <debian-med@lists.debian.org>, Ghislain Vaillant <ghisvail@gmail.com>, 984284@bugs.debian.org

Subject: Re: Bug#984063: itk libtiff test issues (Was: Bug#984063)

Date: Mon, 10 Jan 2022 17:25:59 +0200

On Sat, Dec 11, 2021 at 04:02:09PM +0100, Étienne Mollier wrote:
> Hi there,
> 
> About the build error I caught with itk4 on <valarray>, this
> looks to be caused by a gcc bug in the headers files [1],
> causing failures to build source code including <valarray> with
> clang, compiler which is in use through castxml, which in turn
> is used for constructing the wrapper ITKCommonBase.  itk5 dsc is
> not affected as wrappers are not built anymore on its side, so
> disabling wrappers for itk4 too might be a viable option while
> #1000398 is being worked on (to at least reproduce the tiff test
> failures).  The build error may otherwise solve by itself with
> an upcoming gcc version.
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000398
>...

This bug has been fixed in the meantime.

> Kind Regards,

cu
Adrian

Message #68 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: 984063-done@bugs.debian.org

Cc: Étienne Mollier <emollier@emlwks999.eu>, Steven Robbins <steve@sumost.ca>, 984063@bugs.debian.org, Jose Luis Rivero <jrivero@openrobotics.org>, Debian Med Project List <debian-med@lists.debian.org>, Ghislain Vaillant <ghisvail@gmail.com>, 984284@bugs.debian.org

Subject: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

Date: Mon, 10 Jan 2022 16:58:42 +0100

Am Mon, Jan 10, 2022 at 05:25:59PM +0200 schrieb Adrian Bunk:
> On Sat, Dec 11, 2021 at 04:02:09PM +0100, Étienne Mollier wrote:
> > Hi there,
> > 
> > About the build error I caught with itk4 on <valarray>, this
> > looks to be caused by a gcc bug in the headers files [1],
> > causing failures to build source code including <valarray> with
> > clang, compiler which is in use through castxml, which in turn
> > is used for constructing the wrapper ITKCommonBase.  itk5 dsc is
> > not affected as wrappers are not built anymore on its side, so
> > disabling wrappers for itk4 too might be a viable option while
> > #1000398 is being worked on (to at least reproduce the tiff test
> > failures).  The build error may otherwise solve by itself with
> > an upcoming gcc version.
> > 
> > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000398
> >...
> 
> This bug has been fixed in the meantime.
> 
> > Kind Regards,
> 
> cu
> Adrian
> 
> 

-- 
http://fam-tille.de

Message #80 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: 984063@bugs.debian.org

Subject: Re: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

Date: Sat, 15 Jan 2022 18:45:11 +0100

reopen -1

On Mon, 10 Jan 2022 16:58:42 +0100 Andreas Tille wrote:
> Am Mon, Jan 10, 2022 at 05:25:59PM +0200 schrieb Adrian Bunk:
> > On Sat, Dec 11, 2021 at 04:02:09PM +0100, Étienne Mollier wrote:
> > > About the build error I caught with itk4 on <valarray>, this
> > > looks to be caused by a gcc bug in the headers files [1],
> > > causing failures to build source code including <valarray> with
> > > clang, compiler which is in use through castxml, which in turn
> > > is used for constructing the wrapper ITKCommonBase.  itk5 dsc is
> > > not affected as wrappers are not built anymore on its side, so
> > > disabling wrappers for itk4 too might be a viable option while
> > > #1000398 is being worked on (to at least reproduce the tiff test
> > > failures).  The build error may otherwise solve by itself with
> > > an upcoming gcc version.
> > > 
> > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000398
> > >...
> > 
> > This bug has been fixed in the meantime.

insighttoolkit4 still FTBFS with GCC 11:

 error: ISO C++17 does not allow dynamic exception specifications

The same error as in the original buildlog.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Message #85 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 984063@bugs.debian.org

Cc: smr@debian.org

Subject: Re: Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

Date: Sat, 15 Jan 2022 20:11:34 +0100

Am Sat, Jan 15, 2022 at 06:45:11PM +0100 schrieb Sebastiaan Couwenberg:
> reopen -1
> 
> On Mon, 10 Jan 2022 16:58:42 +0100 Andreas Tille wrote:
> > > > This bug has been fixed in the meantime.
> 
> insighttoolkit4 still FTBFS with GCC 11:
> 
>  error: ISO C++17 does not allow dynamic exception specifications
> 
> The same error as in the original buildlog.

Insighttoolkit4 will be removed from Debian.  We are now building
insighttoolkit5 and do not support insighttoolkit4 any more.

Kind regards

      Andreas.

-- 
http://fam-tille.de

Message #90 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Andreas Tille <andreas@an3as.eu>, 984063@bugs.debian.org

Cc: smr@debian.org

Subject: Re: Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

Date: Sat, 15 Jan 2022 20:30:26 +0100

On 1/15/22 20:11, Andreas Tille wrote:
> Am Sat, Jan 15, 2022 at 06:45:11PM +0100 schrieb Sebastiaan Couwenberg:
>> On Mon, 10 Jan 2022 16:58:42 +0100 Andreas Tille wrote:
>>>>> This bug has been fixed in the meantime.
>>
>> insighttoolkit4 still FTBFS with GCC 11:
>>
>>   error: ISO C++17 does not allow dynamic exception specifications
>>
>> The same error as in the original buildlog.
> 
> Insighttoolkit4 will be removed from Debian.  We are now building
> insighttoolkit5 and do not support insighttoolkit4 any more.

Good to know.

OTB won't support ITK5 for quite a while, though:

 https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/528

Removing itk4 will be difficult with rdeps still depending on it.

There is no RM bug for insighttoolkit4 yet, when you file one feel free 
to file one for otb as well and have it block the one for itk4, but 
please CC pkg-grass-devel@lists.alioth.debian.org when you do.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Message #95 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>

Cc: 984063@bugs.debian.org, smr@debian.org, pkg-grass-devel@lists.alioth.debian.org

Subject: Re: Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

Date: Sat, 15 Jan 2022 21:45:49 +0100

Hi Bas,

Am Sat, Jan 15, 2022 at 08:30:26PM +0100 schrieb Sebastiaan Couwenberg:
> > Insighttoolkit4 will be removed from Debian.  We are now building
> > insighttoolkit5 and do not support insighttoolkit4 any more.
> 
> Good to know.
> 
> OTB won't support ITK5 for quite a while, though:
> 
>  https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/528
> 
> Removing itk4 will be difficult with rdeps still depending on it.
> 
> There is no RM bug for insighttoolkit4 yet,

Steve simply bumped the version right in d/changelog[1]

> when you file one feel free to
> file one for otb as well and have it block the one for itk4, but please CC
> pkg-grass-devel@lists.alioth.debian.org when you do.

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?

Kind regards

       Andreas.


[1] https://salsa.debian.org/med-team/insighttoolkit/-/blob/master/debian/changelog 

-- 
http://fam-tille.de

Message #100 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Andreas Tille <andreas@an3as.eu>

Cc: 984063@bugs.debian.org, smr@debian.org

Subject: Re: Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

Date: Sun, 16 Jan 2022 07:07:01 +0100

On 1/15/22 21:45, Andreas Tille wrote:
> Hi Bas,
> 
> Am Sat, Jan 15, 2022 at 08:30:26PM +0100 schrieb Sebastiaan Couwenberg:
>>> Insighttoolkit4 will be removed from Debian.  We are now building
>>> insighttoolkit5 and do not support insighttoolkit4 any more.
>>
>> Good to know.
>>
>> OTB won't support ITK5 for quite a while, though:
>>
>>   https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/528
>>
>> Removing itk4 will be difficult with rdeps still depending on it.
>>
>> There is no RM bug for insighttoolkit4 yet,
> 
> Steve simply bumped the version right in d/changelog[1]

How does the insighttoolkit5 package in unstable cause the removal of 
insighttoolkit4?

>> when you file one feel free to
>> file one for otb as well and have it block the one for itk4, but please CC
>> pkg-grass-devel@lists.alioth.debian.org when you do.
> 
> 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.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Message #105 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>

Cc: 984063@bugs.debian.org, smr@debian.org

Subject: Re: Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

Date: Sun, 16 Jan 2022 07:13:21 +0100

Am Sun, Jan 16, 2022 at 07:07:01AM +0100 schrieb Sebastiaan Couwenberg:
> On 1/15/22 21:45, Andreas Tille wrote:
> > > There is no RM bug for insighttoolkit4 yet,
> > 
> > Steve simply bumped the version right in d/changelog[1]
> 
> How does the insighttoolkit5 package in unstable cause the removal of
> insighttoolkit4?

It does not.  However, from simply using the same repository you can
draw the conclusion that there is no intention to maintain two different
versions.  Well, for sure we could use another branch - but Steve in
some mail on Debian Med list stated he has no intention to maintain
more than one version.
 
> > 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).

Kind regards

       Andreas.

-- 
http://fam-tille.de

Message #110 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Étienne Mollier <emollier@emlwks999.eu>

To: Andreas Tille <andreas@fam-tille.de>, 984063@bugs.debian.org

Cc: Sebastiaan Couwenberg <sebastic@xs4all.nl>, smr@debian.org

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

Date: Sun, 16 Jan 2022 11:51:43 +0100

[Message part 1 (text/plain, inline)]

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@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

[signature.asc (application/pgp-signature, inline)]

Message #115 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: Étienne Mollier <emollier@emlwks999.eu>

Cc: 984063@bugs.debian.org, Sebastiaan Couwenberg <sebastic@xs4all.nl>, smr@debian.org

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

Date: Sun, 16 Jan 2022 14:30:38 +0100

Am Sun, Jan 16, 2022 at 11:51:43AM +0100 schrieb Étienne Mollier:
> 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,

... or alternatively drop that specific test,

> 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.

I think the roadmap that ITK4 will be deleted as soon as possible
is clear.  However, if it might serve as an intermediate means
to support some remaining dependencies temporarily I think it
is OK to do some tricks that would not be acceptable as long
term means.

Kind regards
       Andreas.


-- 
http://fam-tille.de

Message #120 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: Étienne Mollier <emollier@emlwks999.eu>

Cc: 984063@bugs.debian.org, Sebastiaan Couwenberg <sebastic@xs4all.nl>, smr@debian.org

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

Date: Sat, 22 Jan 2022 19:20:51 +0100

Thanks a lot!

Am Sat, Jan 22, 2022 at 07:15:25PM +0100 schrieb Étienne Mollier:
> Hi Andreas,
> 
> Andreas Tille, on 2022-01-16:
> > I think the roadmap that ITK4 will be deleted as soon as possible
> > is clear.  However, if it might serve as an intermediate means
> > to support some remaining dependencies temporarily I think it
> > is OK to do some tricks that would not be acceptable as long
> > term means.
> 
> I have been working on a rewrap of insighttoolkit4 to include
> the embedded tiff library, and with all the previous patching to
> address the initial issue described in this bug, the build went
> through.  The package should be in shape for upload tomorrow.
> 
> Have a nice day,  :)
> -- 
> Étienne Mollier <emollier@emlwks999.eu>
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/6, please excuse my verbosity.
> On air: Lemur Voice - Solilocide



-- 
http://fam-tille.de

Message #125 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Étienne Mollier <emollier@emlwks999.eu>

To: Andreas Tille <andreas@fam-tille.de>

Cc: 984063@bugs.debian.org, Sebastiaan Couwenberg <sebastic@xs4all.nl>, smr@debian.org

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

Date: Sat, 22 Jan 2022 19:15:25 +0100

[Message part 1 (text/plain, inline)]

Hi Andreas,

Andreas Tille, on 2022-01-16:
> I think the roadmap that ITK4 will be deleted as soon as possible
> is clear.  However, if it might serve as an intermediate means
> to support some remaining dependencies temporarily I think it
> is OK to do some tricks that would not be acceptable as long
> term means.

I have been working on a rewrap of insighttoolkit4 to include
the embedded tiff library, and with all the previous patching to
address the initial issue described in this bug, the build went
through.  The package should be in shape for upload tomorrow.

Have a nice day,  :)
-- 
Étienne Mollier <emollier@emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/6, please excuse my verbosity.
On air: Lemur Voice - Solilocide

[signature.asc (application/pgp-signature, inline)]

Message #130 received at 984063-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 984063-close@bugs.debian.org

Subject: Bug#984063: fixed in insighttoolkit4 4.13.3withdata-dfsg2-1

Date: Sat, 22 Jan 2022 23:04:05 +0000

Source: insighttoolkit4
Source-Version: 4.13.3withdata-dfsg2-1
Done: Étienne Mollier <emollier@debian.org>

We believe that the bug you reported is fixed in the latest version of
insighttoolkit4, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 984063@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Étienne Mollier <emollier@debian.org> (supplier of updated insighttoolkit4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sat, 22 Jan 2022 22:13:09 +0100
Source: insighttoolkit4
Architecture: source
Version: 4.13.3withdata-dfsg2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
Changed-By: Étienne Mollier <emollier@debian.org>
Closes: 984063
Changes:
 insighttoolkit4 (4.13.3withdata-dfsg2-1) unstable; urgency=medium
 .
   [ Andreas Tille ]
   * Team upload.
   * Add NOTICE file to docs
 .
   [ Étienne Mollier ]
   * Add d/gbp.conf to handle the legacy ITK4 in a separate VCS branches.
   * Add gcc11.patch, fixing ftbfs.  (Closes: #984063)
   * Rewrapped the package to include the embedded TIFF source.
   * d/rules: use embedded TIFF to address test failures with later versions.
     Embedding is considered a lesser harm as reverse dependencies and users
     should be migrating to ITK5 from now on.  (See: #984063)
   * Standards-Version: 4.6.0 (routine-update)
   * Rewrapped control file (cme fix dpkg)
   * Remove trailing whitespace in debian/copyright (routine-update)
   * Rules-Requires-Root: no (routine-update)
   * Replace spaces in short license names with dashes.
   * d/control: add myself to uploaders.
Checksums-Sha1:
 9290f0b7c5281540faadf4ce3f4ba8087eef4643 2710 insighttoolkit4_4.13.3withdata-dfsg2-1.dsc
 b06b4998e017c29cf5107874a51fd80882c2ab7a 300917558 insighttoolkit4_4.13.3withdata-dfsg2.orig.tar.gz
 37389d1c6209ba8d65c12bd9532afff91bfdeda1 28456 insighttoolkit4_4.13.3withdata-dfsg2-1.debian.tar.xz
 dc9804bac8ef2826a072772386fbbbbb608b6fdf 11612 insighttoolkit4_4.13.3withdata-dfsg2-1_amd64.buildinfo
Checksums-Sha256:
 8cb80c2816f34c0c9f41ca35a60b1837cf289833d06e80778593490677cab538 2710 insighttoolkit4_4.13.3withdata-dfsg2-1.dsc
 b4a1647c0402c93e111171be7457e4df756992b3438cea1abaeeadd4f50fb9da 300917558 insighttoolkit4_4.13.3withdata-dfsg2.orig.tar.gz
 81c4d73ae6cba3884569f1fa2f23526ae174e13baf21619522b7d59fa04c8858 28456 insighttoolkit4_4.13.3withdata-dfsg2-1.debian.tar.xz
 5030b2948ca182670fe14c0dcecfda1e7e992499780b76b3f3e89b2ff8417ae7 11612 insighttoolkit4_4.13.3withdata-dfsg2-1_amd64.buildinfo
Files:
 7bb5ce1ea137b8dd9825272c8fca05fe 2710 science optional insighttoolkit4_4.13.3withdata-dfsg2-1.dsc
 97b360992f59739434531485b03f7ec8 300917558 science optional insighttoolkit4_4.13.3withdata-dfsg2.orig.tar.gz
 ceccf0dd41acfe4368cde86fbff05d17 28456 science optional insighttoolkit4_4.13.3withdata-dfsg2-1.debian.tar.xz
 3b303c05e98a4500b118e9825bb533c0 11612 science optional insighttoolkit4_4.13.3withdata-dfsg2-1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJIBAEBCgAyFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmHsiPcUHGVtb2xsaWVy
QGRlYmlhbi5vcmcACgkQeTz2fo8NEdp3HxAAiLO9zW1QvpI9CcjH6DlS14gNywr/
8AcBCTmL36pMuUR/+OpscMdn9tZrqcm7cN6i2gSNjnxmlOpRqMZjt6RUWGao1eSV
OTXXYrBpddnhnbzUQM5UZvazQqfsZGh0/+gnnLfEEtj2JuBDI+yCl8N78+iJjoAP
KMx2kVvqKW8Ab5/tlLjv8O17yK7PmuICZiSixgbz4VIi2SkSG36V41TTZTflu7FE
sJPvQNFLfuFO+j5xGCSuZY15zMNOuY2zfaJJxH7hSd4hL7iPAVu6DenvX4rKZczL
080gOZlg+QkLlO8ysnSKqH8/RlghfQ70iNmZmjZZKGT+GEZmK0oov+luKVWFMNgK
kq5O0eHqepUB6TmIrgLwoajkyNzHM2ngbG2SDFFcvFqJZSMHnX/tK639Xl55vTxt
LgAGSr11OVypK9aWVWBa95hJfvBh8VTPkIeqP528N35dnTBjqxG+/gFV0tD3DftJ
EWMBkYQQIP+CrALzJDev9MJD04cECI7SlVMH+d1PAHZTgoW3GVAiw7Xch+oNqAip
ug/KeiaAjrS10WoXwmWR2+SlT7Ya2RWu+sUD5ybUp2IJFsiFxFDs1aX5P6SVAFwP
PIjxFxqtgfqIRvoKk+/lyglG/856pLjd2NegG1hTHI7TXetUDnp9xvlIaB9A7yEq
XNeoxE+MUfZoi7o=
=Sxu5
-----END PGP SIGNATURE-----

Message #135 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Steven Robbins <steve@sumost.ca>

To: Étienne Mollier <emollier@emlwks999.eu>

Cc: 984063@bugs.debian.org

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

Date: Sun, 23 Jan 2022 14:48:10 -0600

[Message part 1 (text/plain, inline)]

On Saturday, January 22, 2022 12:15:25 P.M. CST Étienne Mollier wrote:
> Hi Andreas,
> 
> Andreas Tille, on 2022-01-16:
> > I think the roadmap that ITK4 will be deleted as soon as possible
> > is clear.  However, if it might serve as an intermediate means
> > to support some remaining dependencies temporarily I think it
> > is OK to do some tricks that would not be acceptable as long
> > term means.
> 
> I have been working on a rewrap of insighttoolkit4 to include
> the embedded tiff library, and with all the previous patching to
> address the initial issue described in this bug, the build went
> through.  The package should be in shape for upload tomorrow.

Neat!   I'm  sure that those using ITK 4 will appreciate your work.

As far as the existing Salsa repository is concerned: I would encourage you to 
consider using a v4 branch to maintain it.  If you prefer to do something 
else, that is also fine with me.  Just want to be clear that I haven't any 
objection to keeping v4 and v5 in a single repository.

-Steve

[signature.asc (application/pgp-signature, inline)]

Message #140 received at 984063@bugs.debian.org (full text, mbox, reply):

From: Étienne Mollier <emollier@emlwks999.eu>

To: Steven Robbins <steve@sumost.ca>

Cc: 984063@bugs.debian.org

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

Date: Mon, 24 Jan 2022 17:59:28 +0100

[Message part 1 (text/plain, inline)]

Hi Steve,

Steven Robbins, on 2022-01-23:
> Neat!   I'm  sure that those using ITK 4 will appreciate your work.

Will see how long it lasts, no sure that will be possible all
the way up to bookworm, but at least it will buy some time for
the porting work of reverse dependencies to ITK5.

> As far as the existing Salsa repository is concerned: I would encourage you to 
> consider using a v4 branch to maintain it.  If you prefer to do something 
> else, that is also fine with me.  Just want to be clear that I haven't any 
> objection to keeping v4 and v5 in a single repository.

Thanks, there are two branches (upstream-itk-4.y and itk-4.y) on
the Salsa repository [1], backed by a debian/gbp.conf so gbp use
is mostly fine (at least to build packages; import requires some
manual work, but there ought to be no further ITK4 versions so
that shouldn't be too problematic).  The only minor issue for
the moment is I'm not sure how to point vcswatch in the package
tracker [2] to the specific branch.

[1]: https://salsa.debian.org/med-team/insighttoolkit/-/tree/itk-4.y
[2]: https://tracker.debian.org/pkg/insighttoolkit4

Have a nice day,  :)
-- 
Étienne Mollier <emollier@emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: Luca Di Gennaro - The 2nd Coming

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.