zstandard riscv64 support #163

Activity

1. threexc

   added this to the upstream milestone on Jul 15, 2026
2. threexc

   added the

   Task

   issue type on Jul 15, 2026
3. threexc

   added this to Python Wheels - riseproject-dev/python-wheelson Jul 15, 2026
4. threexc

   added

   upstream

   waiting for maintainerSupport submitted upstream, but not mergedSupport submitted upstream, but not merged

   rise build

   on Jul 15, 2026
5. github-project-automation

   moved this to Todo in Python Wheels - riseproject-dev/python-wheelson Jul 15, 2026
6. luhenry

   added

   wheel

   and removed

   rise build

   upstream

   on Jul 21, 2026
7. gounthar

   added a commit that references this issue on Jul 28, 2026

   zstandard: rebuild workflow from upstream wheel.yml

   ...

   a7baa9b
8. gounthar commented on Jul 28, 2026

   

   gounthar

   on Jul 28, 2026

   Collaborator

   More actions

   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.
9. threexc

   added a commit that references this issue on Aug 4, 2026

   zstandard: build wheels for riscv64 (#161)

   ...

   ab7ef30
10. threexc commented on Aug 4, 2026

    

    threexc

    on Aug 4, 2026

    Last edited by threexc

    CollaboratorAuthor

    More actions

    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 !
11. gounthar commented on Aug 4, 2026

    

    gounthar

    on Aug 4, 2026

    Collaborator

    More actions

    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.