Bug#1056392: suitesparse breaks the octave autopkgtest on 32bit

[Sébastien Villemot]

Hi Adrian,

Le mercredi 22 novembre 2023 à 09:43 +0200, Adrian Bunk a écrit :
> Source: suitesparse
> Version: 1:7.3.1+dfsg-2
> Tags: ftbfs
> 
> https://tracker.debian.org/pkg/suitesparse
> 
> Issues preventing migration:
> ∙ ∙ autopkgtest for octave/8.4.0-1: amd64: Pass, arm64: Pass, armel: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass
> 
> 
> ...
> 254s   libinterp/corefcn/qr.cc-tst ....................................fatal: caught signal Segmentation fault -- stopping myself...

I think the problem is the following:
– suitesparse 1:7.3.1+dfsg-2 (in unstable) exhibits a SONAME bump
compared to the version in testing: it ships libcholmod5 instead of
libcholmod4
– libumfpack6, which is also produced by src:suitesparse, depends on
libcholmod
– when running the autopkgtest above, the octave binary from testing is
used: that binary is linked directly against libcholmod4 and
libumfpack6
– but since libumfpack6 that is used for the autopkgtest comes from the
suitesparse in unstable, it is linked against libcholmod5
– hence in the same binary, both libcholmod4 and libcholmod5 are used
– most likely, the crash comes from an opaque pointer structure that is
passed from one version of libcholmod to the other, and whose structure
is ABI-incompatible (there is indeed such a structure whose ABI changed
only on 32-bit archs from libcholmod4 to libcholmod5).

Note that I’m just speculating here, because I did not investigate the
crash.

However I’m positively sure that the crash is transient and will
disappear once the suitesparse transition is over. Because the octave
testsuite is also exercised at build time, and it did not crash on 32-
bit archs when binNMUing octave 8.4.0-1+b1 against suitesparse
1:7.3.1+dfsg-2.

So I agree that this is a problem for partial upgrades. But I don’t
really know how to add a Breaks relationship that prevents the problem.
Because adding something like "Breaks: octave (<< 8.4.0-1+b1)" is
fragile: the binNMU number may theoretically differ across
architectures; and such a version number may not even make sense for
our derivatives.

Any advice is welcome.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20231122/246aa90f/attachment-0001.sig>