Re: Bug#984063: itk libtiff test issues (Was: Bug#984063)
On Sat, Dec 11, 2021 at 04:02:09PM +0100, Étienne Mollier wrote: > Hi there, > > About the build error I caught with itk4 on , this > looks to be caused by a gcc bug in the headers files [1], > causing failures to build source code including 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
Re: Bug#984063: [Debian-med-packaging] Bug#984063: Please lets coordinate itk4/itk5 issues (Was: Bug#984063)
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
Packages in non-free can be autobuilt
Looking at the cluster3 discussion, just a reminder that many packages in non-free can be autobuilt just like packages in main: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable This is also already happening for Debian Med packages: https://tracker.debian.org/pkg/vienna-rna https://buildd.debian.org/status/package.php?p=vienna-rna cu Adrian
Re: ismrmrd FTBFS on armhf
On Sun, Dec 17, 2017 at 04:49:48PM +, Ghislain Vaillant wrote: > Le 17/12/17 à 15:40, Adrian Bunk a écrit : >... > > Unaligned floating point access on armhf is expected to fail, > > and that's exactly what happens here: > > unknown location(0): fatal error: in > > "AcquisitionsTest/test_acquisition_header": memory access violation at > > address: 0xbecd3b6a: invalid address alignment > > > > Running the test in gdb confirms that this is floating point code. > > > > sparc is generally unhappy with unaligned access: > > unknown location(0): fatal error: in > > "AcquisitionsTest/test_acquisition_header": memory access violation at > > address: 0x7feffb7c936: invalid address alignment > > > > Note that even on architectures where unaligned access is permitted > > it can be slower than aligned access. > > So, what would be the right course of action moving forward? Removing the > package for both armhf and sparc64? It was already removed there ages ago, the only question is whether this is worth fixing. The root cause is that these structs seem to have been defined by people without much knowledge about C alignment. arm64 is more forgiving, the only affected release architecture is armhf. The armel packages could be used through multiarch on all armhf hardware if someone really needs them. IMHO the most reasonable action forward would be to do nothing, and leave this bug open to document that the armhf FTBFS is expected. > Ghis cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: ismrmrd FTBFS on armhf
On Sun, Dec 17, 2017 at 02:33:03PM +, Ghislain Vaillant wrote: > ISMRMRD uses a non-portable instruction (#pragma pack) which modifies the > memory alignment of its data structures. It seems neither armhf nor sparc64 > supports it, hence the failure of the test suite for both architectures. #pragma pack is supported everywhere, and this pragma is the cause of the FTBFS. > I am not sure what the best course of action is. Either leaving things as is > assuming a future rebuild with a newer compiler could improve it, disabling > the tests or even dropping the packages for the failing architectures. > > Opinions welcome. With #pragma pack you are forcing the compiler to do the wrong thing, the only thing a newer compiler could possibly improve would be to error on such code. Unaligned floating point access on armhf is expected to fail, and that's exactly what happens here: unknown location(0): fatal error: in "AcquisitionsTest/test_acquisition_header": memory access violation at address: 0xbecd3b6a: invalid address alignment Running the test in gdb confirms that this is floating point code. sparc is generally unhappy with unaligned access: unknown location(0): fatal error: in "AcquisitionsTest/test_acquisition_header": memory access violation at address: 0x7feffb7c936: invalid address alignment Note that even on architectures where unaligned access is permitted it can be slower than aligned access. > Ghis cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
