On Fri 24 Sep 2021 05:15:25 PM EDT, Torrance, Douglas <dtorrance@piedmont.edu> wrote:
On Fri 24 Sep 2021 04:40:29 PM EDT, Paul Gevers <elbrus@debian.org> wrote:Hi Torrance, On 24-09-2021 22:30, Torrance, Douglas wrote:I had noticed this as well. My guess is that it has something to do with the transition of ntl. libntl43 is in testing, and libntl44 recently appeared in unstable. The unstable autopkgtests, using only libntl44, run without issue, e.g., [1], but the testing autopkgtests, which use both, have these segfaults. We even see both soname versions appearing in the stacktrace:But as the transition isn't finished yet, we'd keep both versions of libntl in testing. So, what's loading the old one?Possibly flint and/or singular? Both are dependencies of Macaulay2 which also link against libntl, and both have also already gone through binNMU's for libntl44 in unstable.
I'm pretty certain this is the issue. macaulay2 depends on both libsingular4m1 and libflint-2.8.0, which in turn depend on libntl43 (in testing) and libntl44 (in sid after recent binNMU's). Once libntl44 and these two binNMU's migrate, then I think the tests should work again like they do in sid. There's a problem though -- this macaulay2 autopkgtest regression is now preventing ntl from migrating to testing! [1] This seems like a chicken and egg situation -- we need it to migrate for the tests to pass, but we need the tests to pass for it to migrate... Is there a good solution for this? One very hacky idea would be to upload a new macaulay2 package with a very basic autopkgtest that's guaranteed to pass for the time being until everything migrates. Is there a better solution? Cc'ing the Debian Science list for suggestions. Thanks! Doug [1] https://qa.debian.org/excuses.php?package=ntl
Attachment:
signature.asc
Description: PGP signature