Patchbot failure metaticket

[mderickx]

The goal of this metaticket is to make it easy to see if there is already a ticket for failures of some patchbots. If a patchbot failure is not on the list, please make ticket with blocker priority for it, if it does not yet exist and add it here together with a list of the affected files!

8.1.beta8

#23933 OpenBLAS randomly crashes / deadlocks 2 - ​arando

sage -t --long src/sage/matrix/matrix_integer_dense.pyx

#23391 Test timeout in FFPACK::CharPoly? (related #21579) - ​multscher

src/sage/graphs/matchpoly.pyx

Only occurs once in a hundred times or so, so one needs to do:

for i in `seq 0 1000` ; do sage -t --long src/sage/graphs/matchpoly.pyx ; done

#21828 At least on OpenSuSE: Crash in SubgraphSearch? of empty graph

src/sage/combinat/posets/poset_examples.py
src/sage/combinat/posets/posets.py

8.1.beta7

#23962 Doctest failure in src/sage/schemes/elliptic_curves/sha_tate.py ​arando

sage -t --long src/sage/schemes/elliptic_curves/sha_tate.py

#23879 Various doctest failures if cbc is installed

sage -t --long src/sage/combinat/designs/orthogonal_arrays_build_recursive.py  # Killed due to segmentation fault
sage -t --long src/sage/graphs/digraph.py  # Bad exit: 127
sage -t --long src/sage/graphs/generic_graph.py  # Killed due to abort
sage -t --long src/sage/graphs/graph_coloring.py  # Killed due to abort
sage -t --long src/sage/graphs/graph.py  # Killed due to abort
sage -t --long src/sage/libs/gap/assigned_names.py  # 1 doctest failed
sage -t --long src/sage/numerical/backends/gurobi_backend.pyx  # Killed due to abort
sage -t --long src/sage/graphs/graph_decompositions/vertex_separation.pyx  # Timed out

[jdemeyer]

I think we can remove the fixed issues, otherwise this will get long very fast.

[mderickx]

I agree, but I prefer we just remove them depending on the beta version in which things were fixed. And just keep the things from the most recent beta and the previous one here. Since that info might still be usefull.

[mderickx]

p.s. Jeroen what do you think about the priority of reproducible but random failing doctests? Say it fails about once in x times where x is some number.

I have the feeling that failing (but not silently producing incorrect answers) one out of three tests should definitely still be blocker priority, and failing (but not silently) once in every 10⁶ times does not deserve to be a blocker anymore. What would be a reasonable guideline for a cutoff? Once in a hundred?

Of course creating a stopgap for something that silently produces the wrong answer deserves to be a blocker no matter how rare.

This question is relevant to #23933, #23391.