zstandard riscv64 support

[threexc]

PR submitted upstream: indygreg/python-zstandard#289

RISE build: #161

[gounthar]

Noting a gap here rather than opening a second issue, since the development guide asks for dropped musl builds to be tracked.

The workflow in #161 builds manylinux only. Upstream builds both, and quay.io/pypa/musllinux_1_2_riscv64 does exist (tagged as recently as 2026-07-25), so the image is not the blocker. I simply have not tried a musllinux riscv64 build of zstandard yet, so I would rather not add jobs to that PR that nobody has seen pass.

Two things I would expect to run into when I do. Upstream sets CIBW_BUILD_FRONTEND to plain build rather than build[uv] for their musllinux cross builds, with the comment "uv not present on musllinux cross-compiled images", so the same is likely needed for riscv64. And zstandard's dev dependency group pulls cffi for the test run, which would have to build from source in a musl container unless there is a musllinux riscv64 wheel for it somewhere.

Happy to add it as a follow-up PR once the manylinux side is merged and I have had a chance to actually run it. If someone has already tried musllinux riscv64 for anything in this repo and hit a wall, I would rather hear about it before spending runner time.

Separately, for the tracker: the upstream PR (indygreg/python-zstandard#289) has been reworked to build on native riscv64 runners rather than QEMU, as discussed in #161.

[threexc]

Noting a gap here rather than opening a second issue, since the development guide asks for dropped musl builds to be tracked.

The workflow in #161 builds manylinux only. Upstream builds both, and quay.io/pypa/musllinux_1_2_riscv64 does exist (tagged as recently as 2026-07-25), so the image is not the blocker. I simply have not tried a musllinux riscv64 build of zstandard yet, so I would rather not add jobs to that PR that nobody has seen pass.

Two things I would expect to run into when I do. Upstream sets CIBW_BUILD_FRONTEND to plain build rather than build[uv] for their musllinux cross builds, with the comment "uv not present on musllinux cross-compiled images", so the same is likely needed for riscv64. And zstandard's dev dependency group pulls cffi for the test run, which would have to build from source in a musl container unless there is a musllinux riscv64 wheel for it somewhere.

Happy to add it as a follow-up PR once the manylinux side is merged and I have had a chance to actually run it. If someone has already tried musllinux riscv64 for anything in this repo and hit a wall, I would rather hear about it before spending runner time.

Separately, for the tracker: the upstream PR (indygreg/python-zstandard#289) has been reworked to build on native riscv64 runners rather than QEMU, as discussed in #161.

I'm fine with another PR to experiment on musllinux, but I wouldn't invest more than a few trigger cycles into the testing for now.

The existing PR has been squashed and merged (with some commit message edits to remove outdated info from the initial workflow versions), and I've triggered a build for zstandard 0.25.0 from main: https://github.com/riseproject-dev/python-wheels/actions/runs/30921384944

Thanks for your efforts @gounthar !

[gounthar]

Thanks for merging, and for kicking off the 0.25.0 build. Confirmed the wheels made it into the index:

zstandard-0.25.0-cp312-cp312-manylinux_2_34_riscv64.manylinux_2_39_riscv64.whl
zstandard-0.25.0-cp313-cp313-manylinux_2_34_riscv64.manylinux_2_39_riscv64.whl
zstandard-0.25.0-cp314-cp314-manylinux_2_34_riscv64.manylinux_2_39_riscv64.whl
zstandard-0.25.0-cp314-cp314t-manylinux_2_34_riscv64.manylinux_2_39_riscv64.whl

Noted on the musllinux budget. I'll keep it to a couple of trigger cycles: one run to see whether the musllinux_1_2_riscv64 image builds the extension at all, and if cffi turns into a from-source build inside the container I'll stop there and write down what happened rather than grinding at it. If it goes green quickly I'll open the follow-up PR, otherwise I'll leave a note here so the next person doesn't start from zero.

Upstream #289 is still open, so I'll leave this issue where it is for now.