* Julien Puydt <julien.pu...@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 tolerateddoes 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
signature.asc
Description: PGP signature
