feat: add riscv64 to Linux wheel build matrix

[gounthar]

Summary

Add riscv64 to the Linux wheel matrix, built and tested on real riscv64 hardware rather than under emulation.

Changes

• Six include entries (cp310 through cp314t) for manylinux_2_39. riscv64 has no manylinux2014 and no musllinux, and the excludes rule manylinux_2_28 out below 3.14, so include entries fit better than a fourth image value on the main matrix.
• runs-on sends riscv64 jobs to ubuntu-24.04-riscv.
• CIBW_MANYLINUX_RISCV64_IMAGE, alongside the other per-arch image variables.

Nothing else changes. Same uvx -p 3.13 cibuildwheel@4.1.0 invocation, same [tool.cibuildwheel] config, no QEMU step, and the rest of the matrix is untouched. python-build-standalone publishes riscv64 CPython for 3.10 through 3.15, so uvx -p 3.13 resolves on those runners without special-casing.

About the runner, and what you will see on this PR

ubuntu-24.04-riscv is the label for the RISE RISC-V runners, free managed GitHub Actions runners on bare-metal RISC-V hardware. They are opt-in per repository: someone with admin rights installs the RISE RISC-V Runners app.

Until that happens, the six riscv64 jobs on this PR will sit queued and never start. That is worth knowing before you look at the checks and wonder what is stuck. The other jobs are unaffected.

Why this changed since the first version

The earlier version of this PR ran riscv64 through QEMU, which works but is slow and tests the wheels on an emulator rather than on the hardware people will run them on. Reviewers on the RISE side pointed out that native is both faster and better evidence, so this is the reworked version. If you would rather not take on a runner dependency, I can go back to the QEMU form and it will build without any setup on your end.

Evidence

• riscv64 wheels for 0.23.0, built natively on a BananaPi F3 (SpacemiT K1) and smoke tested: https://github.com/gounthar/riscv64-python-wheels/releases/tag/v2026.03.07-cp313
• RISE is preparing riscv64 zstandard wheels from this same cibuildwheel configuration in zstandard: build wheels for riscv64 riseproject-dev/python-wheels#161, so the build path here is the one under review there too.

Context

• manylinux_2_39_riscv64 is published by pypa/manylinux.
• Several packages already ship riscv64 wheels: aiohttp, yarl, multidict, propcache.
• zstandard is a common transitive dependency, so with no wheel it gets compiled from source on every install, which is what Add riscv64 (linux_riscv64) wheel to PyPI releases #288 and the comment on this PR from @eshattow describe.

Ref: #288

[gounthar]

Updated docker/setup-qemu-action from v3 to v4 (pinned SHA ce360397).

[eshattow]

I've just encountered this issue when uv pip install poetry and zstandard is slowing me down, I wait for it to compile.

[gounthar]

Yeah, that's exactly the problem, no wheel means compiling zstd from source on every install. Just pushed a fix: the PR was referencing manylinux_2_28_riscv64, which doesn't exist in quay.io/pypa. Switched to manylinux_2_39_riscv64.

[gounthar]

Reworked this on top of current main. It is one commit now, and it builds riscv64 on native hardware instead of QEMU.

The old version was four commits against a base from March, including a setup-qemu-action bump that has since landed here on its own, so a rebase would have been mostly noise. Resetting to main and redoing it made for a smaller diff: six include entries, one runs-on branch, one image variable, and no QEMU step at all.

One thing to flag before you look at the checks. The riscv64 jobs target ubuntu-24.04-riscv, which only resolves once the RISE RISC-V Runners app is installed on the repository, so until then those six jobs will queue and never start. I have described it in the PR body rather than leaving you to guess at stuck checks. It is free for open source and the rest of the matrix is untouched, but it is a dependency on someone else's infrastructure, and if you would rather not take that on I am happy to put the QEMU version back.

Thanks for your patience with this one, and sorry for the churn.

[eshattow]

Separately we should propose to bump the manylinux (2.3.9+) and musllinux (1.2.5+) versions #330, dropping unsupported versions from CI/CD. That should allow to build with less CI complexity. I don't like that this PR series adds complexity to avoid 10+ years old build base in CI.