Epic: upstream riscv64 wheel support to all 33 packages

[gounthar]

Epic: Upstream riscv64 wheel support to PyPI

Track the status of upstream issues and PRs requesting linux_riscv64 wheel support across all packages in our wheel factory.

Goal: Every package in our PEP 503 index should eventually have native riscv64 wheels published on PyPI by the upstream maintainers, eliminating the need for our community index.

Coordination: Working with RISE wheel_builder team (@justeph, @threexc from BayLibre) and Ludovic Henry (@luhenry, RISE TSC Co-Chair) to avoid duplicating effort. RISE provides native riscv64 GitHub Actions runners via https://github.com/apps/rise-risc-v-runners.

Status legend

Stage	Meaning
Issue Filed	Upstream issue created requesting riscv64 support
PR Submitted	Pull request with CI changes submitted upstream
Merged	PR merged into upstream
On PyPI	riscv64 wheel available on PyPI
Deferred	Closed our PR in favor of BayLibre/RISE PR

---

Already supported upstream (no action needed)

• aio-libs/multidict — riscv64 added to CI 2026-02-06 (#1293); v6.7.1 (2026-01-26) predates this; next release will include wheels
• aio-libs/propcache — riscv64 in odd-arches qemu matrix since 2025
• samuelcolvin/watchfiles — riscv64gc-unknown-linux-gnu in maturin-action matrix
• patrick91/rignore — riscv64gc-unknown-linux-gnu in maturin-action matrix
• dvarrazzo/py-setproctitle — riscv64 in build-cross-wheel job matrix
• pydantic/pydantic-core — riscv64 merged in pydantic/pydantic#12723 (Feb 2026), next release

On PyPI (riscv64 wheels shipping)

• chardet (chardet/chardet) — PR #348 merged 2026-03-22; first wheels in v7.3.0 (2026-03-24), still shipping in v7.6.0
• fastar (DoctorJohn/fastar) — PR #58 merged; first wheels in v0.9.0 (2026-03-20), 11 wheels in v0.12.0
• rapidfuzz (rapidfuzz/RapidFuzz) — PR #474 + #475 merged; 14 wheels in v3.14.5 (manylinux_2_39 + musllinux_1_2, cp310–cp314t)
• jiter (pydantic/jiter) — PR #237 merged 2026-03-18; wheels since v0.14.0 (2026-04-10)
• blake3 (oconnor663/blake3-py) — PR #103 merged 2026-04-02; 8 wheels in v1.0.9 (2026-06-22)
• tree-sitter (tree-sitter/py-tree-sitter) — PR #443 merged 2026-03-26; 5 wheels in v0.26.0 (2026-06-30)
• pyzmq (zeromq/pyzmq) — PR #2164 merged 2026-03-17; abi3 wheel in v27.2.0 (2026-08-20)
• greenlet (python-greenlet/greenlet) — our PR #501 closed, maintainer implemented it directly; wheels since v3.4.0

Merged upstream (awaiting PyPI release)

• sqlalchemy (sqlalchemy/sqlalchemy) — PR #13183 merged (2026-03-18, same day!)

Tier 1 — cibuildwheel projects

• numpy (numpy/numpy) — issue · PR #30995 updated to RISE native runners (3.5 min build vs 38 min QEMU) · RISE fork green
• pillow (python-pillow/Pillow) — issue · PR #9463 — libavif libaom RVV bug; Cloud-V suggested
• scikit-learn (scikit-learn/scikit-learn) — PR #33580 — native build SUCCESS on F3; RISE native runners
• sentencepiece (google/sentencepiece) — issue · PR #1196 — CLA signed
• zstandard (indygreg/python-zstandard) — issue · PR googleapis/python-crc32c#289
• llama-cpp-python (abetlen/llama-cpp-python) — issue · PR #2139
• google-crc32c (googleapis/python-crc32c) — issue googleapis/google-cloud-python#16517 · PR googleapis/python-crc32c#337
• fonttools (fonttools/fonttools) — PR #4069 — native build SUCCESS on F3
• tomli (hukkin/tomli) — PR googleapis/python-crc32c#284 — native build SUCCESS on F3

Tier 2 — Rust/maturin projects

Upstream dependency: Rust riscv64gc-unknown-musllinux Tier 2 promotion (with host tools) is pending at rust-lang/compiler-team#982. Once accepted, official Rust Docker images for riscv64 will land via docker-rust#272, unblocking cffi, tiktoken, hf-xet, blake3, cryptography, bcrypt, pynacl.

• cffi (python-cffi/cffi) — PR googleapis/python-crc32c#234 with RISE native runners (builds on @justeph's #227)
• tiktoken (openai/tiktoken) — issue · PR #506
• hf-xet (huggingface/xet-core) — issue · PR #704 — native test: 703/706 pass; RISE fork testing
• orjson (ijl/orjson) — issues & PRs disabled, cannot contribute
• cryptography (pyca/cryptography) — pyca/infra #748 · infra PR #749 riscv64 Docker images; requires RISE native runners; Ludovic enabling runners for pyca org
• bcrypt (pyca/bcrypt) — PR #1177 updated to RISE native runners; RISE fork green
• pynacl (pyca/pynacl) — depends on pyca/infra #749; native build SUCCESS on F3

Tier 3 — Smaller C/Rust extensions

• pyyaml (yaml/pyyaml) — issue · PR #926
• httptools (MagicStack/httptools) — PR googleapis/python-crc32c#137
• msgspec (jcrist/msgspec) — issue · PR #987
• openai-harmony (openai/harmony) — PR googleapis/python-crc32c#104
• textual-speedups (willmcgugan/textual-speedups) — PR googleapis/python-crc32c#6

Deferred to BayLibre/RISE

• tokenizers — closed our #1963, defer to @threexc #1951
• safetensors — closed our #724, defer to @threexc #708
• frozenlist — closed our #745, defer to @justeph #741
• uvloop — closed our #733, defer to @AdrianBunk #711

Deferred to Community

Packages being handled by other contributors — tracking to avoid duplication.

• pycares (saghul/pycares) — @eshattow issue #308 · PR #309
• zeroconf (python-zeroconf/python-zeroconf) — issue #1665 · PR #1666
• dbus-fast (Bluetooth-Devices/dbus-fast) — @eshattow issue #619 · PR #620

Tier 4 — Large/complex build systems

• torch (pytorch/pytorch) — pre-existing issue
• grpcio (grpc/grpc) — pre-existing issue — RISE fork has internal riscv64 workflow

---

Progress (2026-08-24)

• 8 packages now shipping riscv64 wheels on PyPI: chardet, fastar, rapidfuzz, jiter, blake3, tree-sitter, pyzmq, greenlet
• Also live on PyPI via the already-supported / deferred tracks: propcache, watchfiles, rignore, pydantic-core, tokenizers, safetensors, zeroconf, dbus-fast
• sqlalchemy PR #13183 merged 2026-03-18, but 2.0.52 (2026-08-11) still has no riscv64 wheel. Worth a look.
• multidict 6.7.1 (2026-01-26) still predates the riscv64 CI change; waiting on the next release
• 25+ PRs open across the remaining tiers
• 4 PRs deferred to BayLibre/RISE to avoid duplicates
• RISE collaboration with Ludovic Henry, native riscv64 runners
• RISE fork PRs validated: numpy (green), xet-core (703/706 pass), bcrypt (green)
• pyca ecosystem (cryptography+bcrypt+pynacl) unblocking via infra PR + RISE runners
• cffi PR #234 with native RISE runners (builds on @justeph's #227)
• Native F3 builds verified for 20+ packages
• actions/setup-python riscv64 fallback PR #1289
• Non-Python merges: Docker CLI, wit-bindgen (released v0.54.0), wasm-tools, wkg

Resources

• PEP 503 index: https://gounthar.github.io/riscv64-python-wheels/simple/
• Wheel repo: https://github.com/gounthar/riscv64-python-wheels
• RISE wheel builder: https://riseproject.gitlab.io/python/wheel_builder/
• RISE runners: https://github.com/apps/rise-risc-v-runners
• RISE Slack: https://riseprojecttalk.slack.com/archives/C065XKBEXNF
• All wheels built natively on BananaPi F3 (SpacemiT K1, rv64imafdcv, 8 cores @ 1.6 GHz, 16 GB RAM)

[justeph]

Hi @gounthar , I don't know if you are aware, but the RISE project has already started this kind of work 2 years ago. @threexc and I have been both working with them to assist them on this. Project is called wheel_builder see https://riseproject.gitlab.io/python/wheel_builder/. We currently support around 70 packages. We try to build and tests them by mirroring exactly how upstream does and publish them on our registry.
I see that some packages are common to your list and our list of packages to upstream :) See https://gitlab.com/riseproject/python/wheel_builder/-/milestones/7#tab-issues. We are already engaged with @threexc in several upstream discussions in several projects. For example I see a conflicting PR on tokenizers: @threexc already opened one last month see huggingface/tokenizers#1963 vs huggingface/tokenizers#1951. I bet there might be others. Would you be interested to share work force on this?

For you information, @threexc and I submitted a talk about our work on wheel_builder and our upstream work to help various project on this, for the RISC-V Summit Europe that will take place in Bologna from Monday 8th to Thursday 11th June, 2026. In any case, we will both attend.

[gounthar]

@justeph Thanks for reaching out; this is exactly the coordination we need!

I wasn't aware of the specific upstream PRs from @threexc when I opened mine. I've just checked and found overlaps on:

• tokenizers: my #1963 vs @threexc's #1951
• safetensors: my #724 vs @threexc's #708
• frozenlist: my #745 vs yours #741
• uvloop: my #733 vs AdrianBunk's #711

I'll close my duplicates and defer to the existing PRs on those. No point duplicating effort!

I'm already in contact with Ludovic Henry (@luhenry); we're collaborating on RISE native runners for projects that reject QEMU (pyca ecosystem, numpy). I've also joined the RISE Slack. Happy to coordinate there going forward.

For reference, here's what I've been focused on that might not overlap with your list:

• pyca infra (cryptography/bcrypt/pynacl Docker images): feat: add riscv64 Docker images for cryptography ecosystem pyca/infra#749
• RISE runner CI plumbing: actions/setup-python riscv64 fallback, cibuildwheel workarounds
• Non-Python: Docker CLI, wit-bindgen, wasm-tools, wkg, Jenkins, aomedia/aom

Would love to attend the RISC-V Summit Europe talk in Bologna! Let's definitely share workforce: more hands, faster riscv64 ecosystem.

[justeph]

Interesting, we are also in contact with @luhenry indirectly!

I also found a conflicting PR for pyyaml (mine #909, yours #926 and one from @ffgan I missed before mine #877). I didn't dig too much yet on all others..

For reference, here's what I've been focused on that might not overlap with your list:

pyca infra (cryptography/bcrypt/pynacl Docker images): https://github.com/pyca/infra/pull/749
RISE runner CI plumbing: actions/setup-python riscv64 fallback, cibuildwheel workarounds
Non-Python: Docker CLI, wit-bindgen, wasm-tools, wkg, Jenkins, aomedia/aom

• cryptography and pynacl are on our list, but tagged as complex and were not our top priority, so feel free to handle this :)

• about rise runner: I was testing them few weeks ago, but didn't have time to switch back on it. So I would be happy if you can do this also :). FYI, I engaged discussion about native runners with argon2-cffi-bindings maintainer:
  ci: add riscv64 manylinux/musllinux wheels hynek/argon2-cffi-bindings#105. Looks like he might be interested! Maybe you can reach him out?

• Non-Python: we currently focus on python only, so feel free to continue on this one :)

[justeph]

We also have an internal bi-weekly meeting. Next one is scheduled on Monday, 23rd March. Would you be interested to join us? So maybe we can sync together?

[threexc]

I'm also working on video_reader-rs - for now, on my own fork until I figure some changes out.

It's a replacement for decord, which IIRC is in the dependency chain for pytorch. The upstream project depends on pyav-ffmpeg to build its wheels, which I recently got a PR to add riscv64 support into (but no new release with a riscv64 wheel has been published yet).

In the meantime, I'm trying to fix up the pipeline so it builds for x86_64 and arm64. That way, once pyav-ffmpeg publishes a riscv64 wheel, we can get video_reader-rs building with it too.

[gounthar]

@threexc Thanks for the heads up on video_reader-rs; good to know you're working on the pyav-ffmpeg chain. I'll avoid that area.

Also just closed our harmony PR googleapis/python-crc32c#104 in favor of your googleapis/python-crc32c#98. Found another overlap; updating the epic to reflect all the deferred PRs.

[eshattow]

Proposal to promote rust riscv64gc-unknown-musllinux from Tier 2 (no host tools) to Tier 2 (with host tools) is tracked at rust-lang/compiler-team#982 and pending none objections to that proposal then on acceptance I'll send a PR to update the docker-rust repo rust-lang/docker-rust#272 and build images for that. Doing so should unblock a few potential wheels promotions to build and publish for riscv64 when depending on there being official rust docker images for the build.

wheels (some already mentioned) on my list for readying Home Assistant:

AlexxIT/go2rtc#2236

Built pillow==12.2.0
Building grpcio==1.80.0
Building grpcio==1.80.0
Building grpcio==1.80.0
Built grpcio==1.80.0
Built orjson==3.11.8
Built pynacl==1.6.2
Built cryptography==47.0.0

Built pycares==5.0.1 saghul/pycares#308
Built zeroconf==0.148.0 python-zeroconf/python-zeroconf#1665
Built dbus-fast==4.0.4 Bluetooth-Devices/dbus-fast#619

Prepared 8 packages in 141m 46s
Installed 101 packages in 918ms

grpcio is very noticeably the bulk of build duration

[gounthar]

The Rust Tier 2 promotion at compiler-team/issues/982 is the missing piece for most of Tier 2 here. Once that lands and docker-rust ships official riscv64 images, cffi / tiktoken / blake3 / cryptography / pynacl all unblock in one shot. Added a note about it as a dependency in the Tier 2 section above.

Added pycares, zeroconf, and dbus-fast to a new "Deferred to Community" section so we don't open duplicate PRs.

141m for grpcio matches what we saw on the F3. The build works, it's just slow. Upstream has grpc/grpc#41591 open and RISE has an internal riscv64 workflow running -- I'll keep watching that rather than opening a parallel PR.

On go2rtc: PR #2236 looks clean. Happy to run it on a RISE riscv64 runner (ubuntu-24.04-riscv) and post results there if it would help move the review along.

[eshattow]

@gounthar writes:

The Rust Tier 2 promotion at compiler-team/issues/982 is the missing piece for most of Tier 2 here. Once that lands and docker-rust ships official riscv64 images, cffi / tiktoken / blake3 / cryptography / pynacl all unblock in one shot. Added a note about it as a dependency in the Tier 2 section above.

An issue and accompanying pull-request with the changes implementing the proposal will need to be submitted to rust-lang/rust referencing the (when-completed) proposal 982. I welcome and appreciate if you want to get involved with that to submit the implementation issue and pull request ahead of when I would have time to do so myself.

Added pycares, zeroconf, and dbus-fast to a new "Deferred to Community" section so we don't open duplicate PRs.

The pycares author approved changes and all checks are passing.

I do not understand what is needing to be changed in zeroconf and dbus-fast workflows so that external PR contributions can pass the checks. The riscv64 build and publish changes are approved and so it is remaining this unrelated workflow problem. If you are experienced with GitHub Actions and wish to make suggestions improving their workflow I am sure it would be appreciated by the author (workflows are similar and I think the same contributing author is involved for both projects).

141m for grpcio matches what we saw on the F3. The build works, it's just slow. Upstream has grpc/grpc#41591 open and RISE has an internal riscv64 workflow running -- I'll keep watching that rather than opening a parallel PR.

On go2rtc: PR #2236 looks clean. Happy to run it on a RISE riscv64 runner (ubuntu-24.04-riscv) and post results there if it would help move the review along.

Go language supports riscv64 outputs and does everything cross-compiled, and so the addition of riscv64 build output to any CI/CD workflow is not complicated. We wait on the go2rtc author to reply.

[gounthar]

On the Rust Tier 2 proposal: I'll follow compiler-team#982. Once it's approved and someone needs to file the implementation issue and PR against rust-lang/rust, I'd be glad to help. It would unblock most of the maturin packages at once.

For zeroconf (#1666) and dbus-fast (#620): I think I can see what's causing the release job failures, though I'm not 100% sure I have the full picture.

In zeroconf, the job condition reads:

if: ${{ github.repository_owner }} == "python-zeroconf"

The ${{ }} interpolates the value into a string before the comparison runs, so GHA ends up evaluating a non-empty string rather than a boolean. Non-empty strings are truthy, so the condition always passes. The job runs on every PR, then fails because the release environment needs write access that PRs don't have.

Changing it to:

if: github.repository_owner == 'python-zeroconf' && github.event_name != 'pull_request'

should fix that.

In dbus-fast the release job has no if at all, so the same thing happens. Adding if: github.event_name != 'pull_request' to that job should be enough.

If bdraco just wants to merge past the failing check, that's probably fine too since the riscv64 changes themselves look correct. But if it's useful, I can send a small PR to each repo to fix the condition.

[eshattow]

Oh and I forgot to mention cython/cython which just now closed WONTFIX cython/cython#7646

[gounthar]

Thanks for the heads up on cython/cython#7646. The maintainers' reasoning makes sense: Cython already ships a py3-none-any.whl that works on riscv64, and download counts for riscv64 are still low enough that compiled wheels aren't a priority. For this epic, Cython is a build-time dependency for other packages, so the pure Python wheel is enough for CI builds. I'll leave it off the tracking list.

[eshattow]

multidict riscv64 wheels not found in releases and not published to PyPI for the current version 6.7.1

aio-libs/multidict — riscv64 in odd-arches qemu matrix since 2025

[gounthar]

Good catch. PR #1293 adding riscv64 to the CI merged on 2026-02-06, but v6.7.1 shipped on 2026-01-26, 11 days earlier. No release since. The next multidict release should include riscv64 wheels via QEMU.

Fixing the epic too: 'since 2025' was wrong (it was February 2026), and v6.7.1 predates the riscv64 CI addition.

[eshattow]

rust-lang/compiler-tools MCP 982 is accepted and the tracking issue rust-lang/rust#156191 is generated. You may self-assign by responding to that tracking issue with @rustbot claim