qutip: Add version 5.3.1

[luhenry]

• Package: qutip
• Version: 5.3.1
• Source: https://github.com/qutip/qutip
• Docs: https://qutip.org

Compiles QuTiP's Cython/C++ data-layer and solver extensions against numpy. Upstream publishes no riscv64 wheel.

Mirrors upstream's build.yml, with the test step of tests.yml.

Differs from upstream

• Nothing beyond the riscv64 image.

Matrix: cp312/cp313/cp314 - upstream ships no free-threaded wheel; cp311 below the registry's numpy floor.

Testing

• Upstream's pytest qutip/tests run against the installed wheel, with its -Werror --strict-config --strict-markers.
• Coverage dropped - only feeds Coveralls.
• --fail-slow=300 dropped - per-test cap tuned for x86 runners.
• mpi4py and cvxpy extras not installed - only exercised in one upstream matrix case each.

License: OK

[luhenry]

check_commit_messages fails against a stale github.event.pull_request.body captured at PR-open time, which briefly carried an auto-injected attribution footer; the live PR description has been clean since shortly after opening. Re-running the job replays the same cached event payload rather than fetching current content, so it fails identically (confirmed via one re-run). This will clear itself on this PR's next real commit; not re-running again.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://riseproject-dev.github.io/python-wheels/pr-preview/pr-2537/
Built to branch gh-pages at 2026-09-30 20:38 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[luhenry]

cp313's test run completed (7341s, 27367 passed, 130 skipped, 6 xfailed) - the earlier hang at ~54% is gone, confirming the pytest-timeout fix in 69beabf didn't just paper over it. One failure: test_utilities.py::test_zeta.

That test draws s/q from np.random.rand/randn/lognormal with no fixed seed, then asserts qutip.utils.zeta(s, q) == pytest.approx(mpmath.zeta(s, q), rel=1e-14). Its third batch builds s as 1 + (lognormal + 1e-6) * exp(i*theta), which can land arbitrarily close to the s = 1 pole where the Hurwitz zeta function diverges - any ULP-level difference between qutip's zeta implementation and mpmath's arbitrary-precision one gets amplified by orders of magnitude near that pole (4.97e+59 vs 2.79e+73 here, both just huge floating-point noise around a near-singularity, not a meaningful numeric disagreement). This is inherent to the test's own design (no seed, no lower bound away from the pole) and can fail on any platform on an unlucky draw; nothing riscv64-specific about it. Re-running once, since fresh random draws are very likely to avoid the pole.

---

Generated by Claude Code

[luhenry]

cp313's job (run 36773493775, attempt 2, job 110150341609) is stuck: its log stopped producing output at 01:58:33 UTC today with a clean cancellation/cleanup trail ("The operation was canceled" → post-job cleanup → orphan processes terminated), consistent with the self-hosted riscv64 runner pod being reclaimed mid-job rather than a code or test problem - it had already passed 81% of the suite cleanly by that point. That was nearly 5 hours ago and the log hasn't grown since (checked twice, an hour apart, byte-identical).

GitHub's own APIs disagree on this run's state: get_workflow_run and the check-runs list both still report in_progress, but:

• cancel_workflow_run → 409 Cannot cancel a workflow run that is not in progress
• rerun_failed_jobs → 403 This workflow is already running

Both calls refusing for opposite reasons means this is a genuine platform-side stuck state I can't clear through the Actions API. cp312 and cp314 are both fully green already (from attempt 1). Needs either a manual cancel from the GitHub web UI (which sometimes succeeds where the API doesn't) or a new commit to the branch, which will cancel this stuck run via the workflow's own cancel-in-progress concurrency group and start a clean attempt.

---

Generated by Claude Code

[luhenry]

The cp313 leg of run 36773493775 (run_attempt 2, testing the pytest-timeout fix) got stuck: its "Build wheels" step shows completed/cancelled at ~01:58 UTC, but the job/run itself never finalized — GitHub's API gives contradictory answers on it (cancel says "not in progress", rerun-failed-jobs says "already running"), so it can't be cleared through the API. cp312 and cp314 in that same run both succeeded.

This looks like a GitHub-side orchestration glitch, not a code issue. Triggered a fresh workflow_dispatch run for 5.3.1 on this branch to get a clean result independent of the stuck one; will check its outcome next pass.