Bug#986527: sagemath: FTBFS: /<<PKGBUILDDIR>>/sage/src/bin/sage: line 549: exec: cython: not found

[Jochen Sprickerhof]

* Julien Puydt <julien.puydt at gmail.com> [2021-05-18 17:47]:
>Upstream manages to ship version with no error because they ship
>hundreds of deps to an exact version for which they fitted the
>testsuite to pass. We ship those deps as separate packages, because
>they're actually not sagemath-specific [look at the list, it's pretty
>telling : https://people.debian.org/~thansen/debian-sage-status.html ],
>so we might not have the exact same version, and that's enough to
>trigger artificial failures.
>
>I don't think we'll ever hit zero. At least not while their testsuite
>framework is so... so like it is.
>
>If we keep it with an allowed error rate, we detect the package is
>*really* broken before shipping ; if we don't, we detect it is broken
>after shipping, because it hurts the users and they complain.

I totally understand your point but please keep in mind that we need to 
be able to rebuild packages in Debian as well. If we rebuild a package 
and it FTBFS, we can't publish security updates, for example.
Also if the tests depend on so many external dependencies, changing one 
of them could render sagemath FTBFS due to hitting the test limit. Would 
you then simply bump the limit?

>Sagemath is definitely not bug-free, the Debian package for it isn't
>bug-free either, but it is working and useful to users, and this
>(bringing useful software to users) is what Debian is about.

Totally agreed here, I would like to see sagemath in stable as well.

>If I look at the title of this bug, I think "Oh, just patch
>src/bin/sage so it calls cython3 and not cython" (see my message #20),
>but if you look at the exchange, then it's not clear at all what the
>problem actually is.
>
>The buildd logs (
>https://buildd.debian.org/status/package.php?p=sagemath&suite=bullseye
>), John Cross (message #10), myself (message #25) and the triggered RB
>rebuild (message #30) all conclude the package doesn't FTBFS.
>
>I would like to fix the problem, but at that point, I have no clue what
>it really is about...

I think there are a number of problems:
- Tests not being executed due to the open file limit ("Killing test" in 
   the log). If you want to use the tests as an indicator if the build 
   works, you should make sure the all tests are executed, otherwise 200 
   tolerated failures is arbitrary.
- I found a number of segfaults in the tests, like:
   sage -t --long --random-seed=0 src/sage/interfaces/singular.py  # Killed due to segmentation fault
- Looking at the amd64 log of the buildd:
   Error: 202 tests failed, up to 200 failures are tolerated
   Yes: 202 tests failed, up to 400 failures are tolerated for rerun
   Success: 192 tests failed, up to 200 failures are tolerated
   does that mean we ran the test twice and it passed the second time 
   cause there where 10 failures less? Can we be sure that this always 
   succeeds? 192 is really close to 200.
- I still see cython: not found in the logs, so there are definitely 
   tests broken due to that. Maybe it makes sense to define tests which 
   are allowed to break and other which should succeed?

I am honestly not sure what the best way forward would be but I think 
just downgrading the bug priority is not helping. On the other hand 
given the current freeze policy and what will be the policy in stable, 
what would be your actions if sagemath FTBFS there? Would you say at 
some point it is unfit for a stable release or would you retry the build 
and ignore the errors? Maybe it would make sense to ignore the tests 
results for the version in stable?

Cheers Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20210518/74ab56ac/attachment.sig>