Add riscv64 (linux_riscv64) wheel to PyPI releases

[gounthar]

Add linux_riscv64 wheel to PyPI releases

Summary

pip install cryptography on riscv64 Linux currently requires building from source (~8 min on a 1.6 GHz RISC-V SoC). Adding linux_riscv64 to the wheel build matrix would give riscv64 users a prebuilt wheel.

Evidence

Tested wheel	cryptography-46.0.5-cp313-abi3-linux_riscv64.whl
Hardware	BananaPi F3 (SpacemiT K1, rv64imafdcv, 8 cores @ 1.6 GHz, 16 GB RAM)
Python	3.13 (CPython)
Build system	custom (ghcr.io/pyca containers + Rust)
Build time	~8 min (native, on hardware)

The wheel imports and passes basic smoke tests on riscv64 Linux.

Suggested CI change

Workflow: .github/workflows/wheel-builder.yml

This is a multi-step change requiring infrastructure work:

1. Build a cryptography-manylinux_2_28:riscv64 container in pyca/infra
2. Cross-build static OpenSSL for riscv64 in pyca/infra
3. Add a MANYLINUX entry to wheel-builder.yml:

- NAME: manylinux_2_28_riscv64
  CONTAINER: cryptography-manylinux_2_28:riscv64
  RUNNER: ubuntu-latest

4. Add QEMU setup for the riscv64 runner

Note: This cannot be a simple one-line change. The infrastructure in pyca/infra must be updated first.

Ecosystem context

• manylinux_2_28_riscv64 images are available on quay.io/pypa/ (landed in pypa/manylinux, 2025)
• cibuildwheel 3.x supports riscv64 via QEMU emulation
• auditwheel supports riscv64 platform tags
• maturin-action supports riscv64gc-unknown-linux-gnu cross-compilation
• Packages already shipping riscv64 wheels on PyPI: aiohttp, yarl, regex, markupsafe, charset-normalizer, rpds-py, multidict, propcache, watchfiles, rignore, setproctitle
• RISC-V hardware is shipping: SiFive HiFive, SpacemiT K1/K3, Sophgo SG2044 (64-core)

Our temporary index

While upstream support is pending, we maintain a PEP 503 index with 50+ riscv64 wheels for the Python ML/AI stack, built natively on RISC-V hardware.

Tracking repo: https://github.com/gounthar/riscv64-python-wheels

[alex]

Please see https://cryptography.io/en/latest/faq/#will-you-upload-wheels-for-my-non-x86-non-arm64-cpu-architecture which documents our requirements to add support for a new architecture:

tl;dr; we need CI runners that can run tests on every PR with acceptable performance and stability.

[gounthar]

Thanks @alex for the pointer. That makes sense — reliability and performance of CI runners is key.

Two options that could help:

1. We have two BananaPi F3 boards (SpacemiT K1, 8 cores @ 1.6 GHz, 16 GB RAM, rv64imafdcv) already running as GitHub Actions self-hosted runners. We could register them for cryptography CI if that's useful.

2. The Cloud-V initiative provides cloud-based RISC-V CI infrastructure. They offer hosted RISC-V runners that could provide the stability and availability requirements you need without depending on individual hardware.

Would either of those work for your CI needs, or is there a specific runner setup / performance threshold you'd need to see first?

[alex]

In terms of performance/reliability, the minimums are roughly:

• A bare minimum of 3 concurrent jobs. (In practice I think even would probably be too low, but anything less isn't worth considering.)
• Able to run our tests jobs in <10 minutes.
• Runners need to run in stateless, ephemeral environments. So self hosted Github Actions runners can work well, but they need appropriate isolation.
• High availability, at least 2 9s.

[gounthar]

Thanks @alex for the concrete requirements.

3+ concurrent, <10 min, ephemeral, 99%+ availability; understood. For reference, our native build of cryptography on the F3 boards takes about 8 minutes, so the <10 min threshold is within reach on current hardware.

Another service that might help beyond the Cloud-V option I mentioned earlier: riscvrunners.com : a self-service RISC-V CI SaaS with a free emulated tier (3,000 min/month) and paid native hardware tiers. Might be quicker to evaluate since it's self-service.

Happy to help with evaluation if either path looks promising.

[alex]

We're an OSS project with no external funding, so a commercial RISC-V service is of limited use for us -- we rely on free services for our CI.

[reaperhulk]

To add to Alex's requirements: we have no interest in having to manage infrastructure or secondary CI systems, so it's effectively a requirement that someone else operate an ephemeral runner setup on the target architecture as a GitHub integration that we can use and provide it free of charge. An example of an org that has successfully done this is IBM with ppc64le: https://github.com/IBM/actionspz

[eshattow]

RISE RISC-V Runners work reliably and are professionally maintained, and are a no-monetary-cost community resource for the purpose of increasing software ecosystem adoption w/re RISC-V.

For example why I recommend this is e.g. Rust language project uses the RISE RISC-V Runner for building host tools, and I've had positive experiences with those runners with my effort to ready Home Assistant for RISC-V architectural decision record proposal. The second-generation RISC-V hardware that they manage is comparable to qemu on the GitHub runners which is to say "not quick". This project's GitHub account would need to configure access with the marketplace add-on and enable it for the repository so that the runner will pick up the task: https://riseproject-dev.github.io/riscv-runner/

Otherwise it drops in just set the os to 'ubuntu-24.04-riscv' for that job in the matrix and there's nothing else notable other than it being comparatively slow to the GitHub Actions official runners.

I'm in favor of any upstream dependency publishing wheels for RISC-V architecture riscv64

[reaperhulk]

We're aware of the RISE runners and have had folks trying to help integrate that on some of our other repositories (pyca/infra#754). However, performance is important and the RISC-V hardware available to us is not capable of meeting our requirements at this time.

[eshattow]

It must be very costly then if CI/CD time is high priority, where to donate?

[alex]

Donations to us cannot solve the problem of RISCV being insufficiently slow -- unless someone has a high performance RISCV chip that I'm not aware of.