Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python3-scipy: update to 1.12.0. #48317

Closed
wants to merge 2 commits into from
Closed

Conversation

tornaria
Copy link
Contributor

Testing the changes

  • I tested the changes in this PR: briefly

I enabled tests for scipy let's see if CI can manage or we have to disable in CI (we only run "not slow" tests for -Q).

Updated sagemath since it needs a patch for scipy 1.12 (sagemath/sage#37123). Took the chance to apply a few minor fixes that didn't justify an update on their own.

@ahesford I'll be done with testing in a couple days at most, in principle everything looks good.

BTW: I run scipy tests with export SCIPY_XSLOW=1 and -m xslow which gave me one failure:

FAILED scipy/sparse/linalg/tests/test_onenormest.py::TestOnenormest::test_onenormest_table_6_t_1
====== 1 failed, 321 passed, 40 skipped, 15 xfailed in 9042.78s (2:30:42) ======

Running check normally gave me:

== 45224 passed, 2467 skipped, 149 xfailed, 12 xpassed in 3836.63s (1:03:56) ===

(with -m "not slow") and

== 59100 passed, 2501 skipped, 259 xfailed, 14 xpassed in 5444.99s (1:30:44) ===

@tornaria tornaria changed the title https://github.com/tornaria/void-packages/pull/new/scipy python3-scipy: update to 1.12.0. Jan 22, 2024
@tornaria
Copy link
Contributor Author

Seems ok, scipy passed check in all arches.

Failure in i686 is one sagemath test, seems transient and completely unrelated to scipy, a timeout in:

...
sage: R.<x> = PolynomialRing(GF(65537), implementation="FLINT") ## line 701 ##
sage: f = R.random_element(9973) * R.random_element(10007) ## line 702 ##
sage: alarm(0.5); f.factor() ## line 703 ##

Most probably the signal got lost, I've seen this in the past. The test looks stupid but I think it's there to make sure f.factor() can be interrupted (say, by hitting ctrl-C, if that signal gets lots one can hit ctrl-C again ofc).

Running the scipy testsuite in CI seems ok, in our three arches with check:

== 45225 passed, 2466 skipped, 147 xfailed, 14 xpassed in 1619.82s (0:26:59) ===
== 44982 passed, 2334 skipped, 550 xfailed, 14 xpassed in 1765.55s (0:29:25) ===
== 45224 passed, 2467 skipped, 147 xfailed, 14 xpassed in 1395.96s (0:23:15) ===

It's weird it takes 26 minutes in CI, 36 minutes in my 8 core desktop, and 1 hour (walltime!) in my 36 core workstation, it seems some tests are scaled by the number of cores.

See: sagemath/sage#37123

Also apply a few minor fixes.
@tornaria
Copy link
Contributor Author

I re-pushed because I forgot to git add one patch in sagemath (minor issue that only triggers when sagemath is built with one version of cython and then cython changes version so CI will never see it).

We'll get a chance to see if the i686 failure is indeed transient as I think.

If CI passes this is ok to merge on my side (take your time, no hurry here @ahesford).

@ahesford ahesford closed this in 26bdd8b Jan 23, 2024
@tornaria tornaria deleted the scipy branch January 24, 2024 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant