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
signature.asc
Description: This is a digitally signed message part
