https://buildd.debian.org/status/fetch.php?pkg=ismrmrd&arch=armhf&ver=1.3.3-1&stamp=1480195858&raw=0

...
make -f tests/CMakeFiles/check.dir/build.make tests/CMakeFiles/check.dir/build
make[4]: Entering directory '/«PKGBUILDDIR»/obj-arm-linux-gnueabihf'
cd /«PKGBUILDDIR»/obj-arm-linux-gnueabihf/tests && ./test_ismrmrd
Running 25 test cases...
Entering test module "ISMRMRD Unit Tests"
/«PKGBUILDDIR»/tests/test_acquisitions.cpp(7): Entering test suite "AcquisitionsTest"
/«PKGBUILDDIR»/tests/test_acquisitions.cpp(11): Entering test case "test_acquisition_header"
unknown location(0): fatal error: in "AcquisitionsTest/test_acquisition_header": memory access violation at address: 0xbecd3b6a: invalid address alignment
/«PKGBUILDDIR»/tests/test_acquisitions.cpp(130): last checkpoint
Test is aborted
/«PKGBUILDDIR»/tests/test_acquisitions.cpp(11): Leaving test case "test_acquisition_header"; testing time: 8619us
Test is aborted
/«PKGBUILDDIR»/tests/test_acquisitions.cpp(7): Leaving test suite "AcquisitionsTest"; testing time: 8703us
Test is aborted
Leaving test module "ISMRMRD Unit Tests"; testing time: 8795us

*** 1 failure is detected in the test module "ISMRMRD Unit Tests"
tests/CMakeFiles/check.dir/build.make:60: recipe for target 'tests/CMakeFiles/check' failed
make[4]: *** [tests/CMakeFiles/check] Error 201

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.

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.

Ghis

#pragma pack is supported everywhere,
and this pragma is the cause of the FTBFS.

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.

cu
Adrian

Le 17/12/17 à 15:40, Adrian Bunk a écrit :

Ack.

Ack.

So, what would be the right course of action moving forward? Removing
the package for both armhf and sparc64?

Ghis

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.

cu
Adrian

control: tags -1 + wontfix

Hello,

Bug #863168 in ismrmrd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/med-team/ismrmrd/-/commit/c24406d85e9b6ab9c9c30ed689405cd758dea0c7

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/863168

We believe that the bug you reported is fixed in the latest version of
ismrmrd, 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 863168@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Tille <tille@debian.org> (supplier of updated ismrmrd 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)
Format: 1.8
Date: Sat, 21 Feb 2026 18:24:53 +0100
Source: ismrmrd
Binary: ismrmrd-schema ismrmrd-tools ismrmrd-tools-dbgsym libismrmrd-dev libismrmrd-doc libismrmrd1.15 libismrmrd1.15-dbgsym
Architecture: source all amd64
Version: 1.15.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
Changed-By: Andreas Tille <tille@debian.org>
Description:
 ismrmrd-schema - schema for ISMRMRD
 ismrmrd-tools - command-line tools for ISMRMRD
 libismrmrd-dev - development files for ISMRMRD
 libismrmrd-doc - documentation for ISMRMRD
 libismrmrd1.15 - ISMRM Raw Data format (ISMRMRD)
Closes: 863168 1128127
Changes:
 ismrmrd (1.15.0-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream version
     Closes: #1128127
   * Standards-Version: 4.7.3
   * Build-Depends: architecture-is-64-bit
     Closes: #863168
   * Drop use of autotools-dev debhelper.
   * Bump SONAME due to new upstream version
Checksums-Sha1:
 0ef415df5c5efc0ed4970475368084a6b25363f3 2466 ismrmrd_1.15.0-1.dsc
 d3236cf2dab8cc1824d5d75730974ff7bab02c72 179466 ismrmrd_1.15.0.orig.tar.gz
 452a1265b5e9f8244bd8015414215ff40e0f7476 9268 ismrmrd_1.15.0-1.debian.tar.xz
 884bd5b11da1d214a73006fa23f21b9118fa6eff 6952 ismrmrd-schema_1.15.0-1_all.deb
 6b90c0a235a64cf2314342ca8126a11b51e6cfcc 1871568 ismrmrd-tools-dbgsym_1.15.0-1_amd64.deb
 ca7082dd84a054e6d41faa17d436f455cb1a3944 108860 ismrmrd-tools_1.15.0-1_amd64.deb
 430a66a597b69842d6facd6e6ffbf17e1cafcc40 11411 ismrmrd_1.15.0-1_amd64.buildinfo
 b0b0f8bfdebcb0a9c39fd38bac94eef6254155c2 127376 libismrmrd-dev_1.15.0-1_amd64.deb
 296b06c77d0aa96a20801974dc340d2752ca624e 206752 libismrmrd-doc_1.15.0-1_all.deb
 b4d5e6b2f4bbc1068df94cfb36ef25f352a57a26 955976 libismrmrd1.15-dbgsym_1.15.0-1_amd64.deb
 1144416cdb44c2cf26bb6ede191066c742de03b6 110664 libismrmrd1.15_1.15.0-1_amd64.deb
Checksums-Sha256:
 4a3f3b1d37f3f7d82e6ea2b08d96ed1d69957d1e02634180fceff358d31394ac 2466 ismrmrd_1.15.0-1.dsc
 7fb79a978920b30e55637c613776a219e4e56ae4b3890e809cbc37399255eb92 179466 ismrmrd_1.15.0.orig.tar.gz
 5f3f78bb5100e17093e7922490a84990fd344a5c3dc6052e358f123788c33f30 9268 ismrmrd_1.15.0-1.debian.tar.xz
 36e5d82c8879a2a093c552a016d5110563e4716d40104d0975f29d62600cc167 6952 ismrmrd-schema_1.15.0-1_all.deb
 a4cf3c083db1cb3e770e2594a8ee41fd37ee54da11f68868b4846410062b5ecd 1871568 ismrmrd-tools-dbgsym_1.15.0-1_amd64.deb
 ebd253464188624ff9411bbd303a839ead962c14bdd439b15989266254688f20 108860 ismrmrd-tools_1.15.0-1_amd64.deb
 776516ccfc6fe6ba7b43a171a3659b56f5cc3f12cd4d1d5f39b3f3c61b07a60c 11411 ismrmrd_1.15.0-1_amd64.buildinfo
 d035eb7a6d3407043596e9520749b45128348a900092c1b25fb2dd535420b2ab 127376 libismrmrd-dev_1.15.0-1_amd64.deb
 812922a1b1294768555e268273cb7b7ea72a714fd80cf85dd3e011ca72648813 206752 libismrmrd-doc_1.15.0-1_all.deb
 d4548107bc1557e5b13d3f34f9cbb61875b3bd3d441926cd0e3c16310832af0d 955976 libismrmrd1.15-dbgsym_1.15.0-1_amd64.deb
 444443403117a9b06cbeeec1c65d45a0f5156e08fccd7ddecdf62bf3702714f6 110664 libismrmrd1.15_1.15.0-1_amd64.deb
Files:
 91f169008111b5998c8408852fc18ff3 2466 science optional ismrmrd_1.15.0-1.dsc
 c70a98beae85bc8ba98fd6d4677b97a4 179466 science optional ismrmrd_1.15.0.orig.tar.gz
 2fc9d03815900018387d4c32587ec2eb 9268 science optional ismrmrd_1.15.0-1.debian.tar.xz
 01622956d0c832d1c7ebe860503eb2d5 6952 misc optional ismrmrd-schema_1.15.0-1_all.deb
 a7ea5073e250e76dfd3a831b6c1429f5 1871568 debug optional ismrmrd-tools-dbgsym_1.15.0-1_amd64.deb
 8b80829a335db110612792e085a3bce5 108860 utils optional ismrmrd-tools_1.15.0-1_amd64.deb
 dc55066c1a7fb45ab21ecd986c4b045c 11411 science optional ismrmrd_1.15.0-1_amd64.buildinfo
 79cf82a4811a8f173817fbae2b6fd809 127376 libdevel optional libismrmrd-dev_1.15.0-1_amd64.deb
 46299cc0645223136bcd8408c3c6727c 206752 doc optional libismrmrd-doc_1.15.0-1_all.deb
 9cdd485937ec7ecea162104cd169e722 955976 debug optional libismrmrd1.15-dbgsym_1.15.0-1_amd64.deb
 896668d56038c186e9c328543ac164cd 110664 libs optional libismrmrd1.15_1.15.0-1_amd64.deb
-----BEGIN PGP SIGNATURE-----

iQJFBAEBCgAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmmZ7F0RHHRpbGxlQGRl
Ymlhbi5vcmcACgkQV4oElNHGRtFwuw/+LcsL4q0TsAuLiqmIpx3Pv4qwQ7gPqxvq
FFEh2/cjmi3EzE/mQ/8Sv6Bzq6JpHZbcbFuINyz/GVnWsjAM9LDa1Ibp5jVFcw/Z
AVUX6vAkvboKkekvX610EPIEM3JykSDRxoRhu2jT5GnKqcDok/6ZUStv/KZRyBfi
z1KcwdSC/rcpmfJA1lRj2lnTdmE+0LWl3praFCxWEUKmkRv389SPp7o3EjBVuKmU
1ta+n+xi10gTVzm/vD4iKVfYzmGvGUk1ePtjXNfS2p69y5HuNIIRfBHagwjN70nq
KXl7CEXJEU7vcD0h1cP5PqR1v4e9Tv9WT3ggPa+xYX3XYOl6pAd7QXiYa4h5Msbj
6+hf1a0000AFa1x6Kdk65QF7N70OI1nbC+AGHSdJON5xNA9bVJU9jEEYqT0BvXhY
Fk4Yy9fa3SQS70YxuwCPRP2FMgOFQNlh2Petp1C/T9Dz4N5294UOJX22fqm7uXSB
QKtPYUCVTeW6XdMnizKK9/GmXqNXqYSc5QoqVeVVR12BPIyc/fYX0e+jmYGG5Myr
oxRRrJfN1o7eQzeOh9fGwNbRIiTOrpv2pf5HoY4P8CERAIl03njxGsOSaxXeQHBs
NARamImkvbLw7xALvQI3kIh8s4Bb1u1t9bcEoa+uG8fyVsoajNRNKRyHpOS9R+7U
8sHx9F1vq6o=
=p5yh
-----END PGP SIGNATURE-----

 >  Build-Depends:
 >   cmake,
 >   debhelper-compat (= 13),
 > + architecture-is-64-bit,

@tille This is wrong:
- the package builds fine on i386 and multiple other 32-bit architectures
- this is an unaligned access problem, which expectedly also fails on sparc64

Hi Adrian,

Am Sat, Feb 21, 2026 at 05:49:25PM +0000 schrieb Adrian Bunk (@bunk):

I think this is sensible anyway since we are moving away in the scientific
packages from 32bit support.

Hmmm, this is probably a good reason to reopen the bug ... at least if
it is present in the new upstream version which just hit the new queue.

Thanks a lot for watching me closely
   Andreas.

 >  Build-Depends:
 >   cmake,
 >   debhelper-compat (= 13),
 > + architecture-is-64-bit,

This can be problematic, since half the world transitively depends on some packages like opencv, and then you might end up hard-coding architecture lists in other places to workaround the missing packages.

I'm not saying that non-trivial 32-bit breakage is usually worth fixing (or that upstream should be asked to fix it), but when it isn't broken (like here on i386) then keeping it should be the default option.

I'm not particularly watching you, but the BTS sent me as submitter an email for the commit.

Hi Adrian,

Am Sat, Feb 21, 2026 at 06:14:06PM +0000 schrieb Adrian Bunk (@bunk):

OK, do you think reopening bug #863168 and reverting this change is the
best solution?

Just joking, sorry for missing some smiley or so.  Honestly its
relieving to know that there is a second pair of eyeballs.

Kind regards
   Andreas.

Revert Build-Depends: architecture-is-64-bit