Skip to main content

Bringing RISC-V to conda-forge

· 6 min read
Isuru Fernando
Isuru Fernando
Member of conda-forge/core
Axel Obermeier
Axel Obermeier
Member of conda-forge/core

conda-forge now has an early, working linux-riscv64 platform. If you have access to a riscv64 machine (or an emulator), you can already try it out:

curl -L -O https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-riscv64.sh
bash Miniforge3-Linux-riscv64.sh
conda install python

That last command actually solves and installs today, giving you a native linux-riscv64 Python built entirely on conda-forge infrastructure.

How this got started​

Interest in RISC-V support has come up on and off for a while, but it started moving in earnest after outreach on Zulip and a presentation from the OpenKylin community at the core call on 2025-11-12. conda-forge/core was generally supportive, and the OpenKylin folks committed real, full-time engineering effort (Tianxiang Bian, Jiankang Li and Ruian Zhan, later joined by Chenguang Ding and Zhuoheng Li) to help push the platform through. All of this is being tracked in conda-forge.github.io#1744, which is a good read if you want the blow-by-blow.

Two decisions were made early on:

  • A conda-forge/help-riscv64 team was formed so there'd be people responding quickly to CI failures on this new platform, the same pattern we use for every new platform.
  • Rather than chase the newer RVA23 profile from day one, we're building for the more conservative rv64gc baseline, the same one Ubuntu 24.04 targets. RVA23 is a superset, so this is not a fork of the ABI, just starting from a safer, more broadly compatible point and upgrading later once there's a need.

Bootstrapping, again, via cross-compilation​

Every time conda-forge has added a new platform — osx-arm64 in 2020, win-arm64 more recently — we've followed the same recipe: cross-compile from an existing platform until the new platform can build its own compilers and build tools, and only then start building everything else natively (or migrate to native CI, in win-arm64's case). RISC-V is no exception.

The toolchain work happened in the usual feedstocks:

With those in place, the classic bootstrapping sequence played out: build a cross-compiler on linux-64 targeting riscv64, use it to build a cross-native compiler, then use QEMU emulation (via qemu-execve-feedstock, which needed a docker-images update to bring in a newer QEMU) to test the handful of packages needed to get micromamba and conda/mamba/rattler-build/pixi/python themselves building. rust_linux-riscv64 is still being finished off.

Once that base was solid, we opened up the full supportlinuxriscv64platform migration, seeded from the explicit package list in conda-forge-pinning-feedstock and driven by the regro bot the same way every other platform migration is. python-feedstock#896 landing was the big unlock — it broke through the largest cluster of blocked dependents. As of today there are already north of 500 distinct packages built for linux-riscv64 on the conda-forge channel, and the list keeps growing every day.

Miniforge​

miniforge#899 added linux-riscv64 support to Miniforge alongside a bump to conda 26.7.2 and mamba 2.9.0, and it shipped in the 26.7.2-0 release, which includes a Miniforge3-Linux-riscv64.sh installer. That's the installer used at the top of this post, and conda install python on a bare linux-riscv64 container really does work with it today.

What's next: native CI runners​

All of the above still happens on linux-64 machines, cross-compiling. That has always been a bootstrapping phase, not the destination — the same as it was for osx-arm64 and win-arm64. Once we have a self-sufficient native toolchain (native GCC built on riscv64, not just cross-built for it) and enough of the base stack to run our build agents, the plan is to move linux-riscv64 CI onto real native hardware instead of cross-compiling everything from linux-64. We recently merged two of the remaining essential components for this, the native docker images and conda-forge-ci-setup.

For the actual agents on which to execute runs, we have two promising offers on the table:

  • RISE, a Linux Foundation project focused on the RISC-V software ecosystem, runs a free-to-use pool of RISC-V GitHub Actions runners already used by projects like llama.cpp, PyTorch, and CNCF, with newer RVA23 hardware on the way.
  • The OpenKylin community has offered an OpenStack-based riscv64 build cluster of their own.

Neither is wired into conda-forge's CI yet — conda-forge's build matrix for linux runs on Github Actions (see the CI build services docs), so there's real integration work ahead to plug native riscv64 runners into that pipeline, whichever provider(s) we end up using. That work will start in earnest once the native compiler toolchain is further along, and help is very welcome, whether that's runner integration, feedstock fixes, or just watching CI on the migration status page and pinging conda-forge/help-riscv64 when something breaks.

Huge thanks to everyone who's pushed this forward so far: the OpenKylin team (Tianxiang Bian, Jiankang Li, Ruian Zhan, Chenguang Ding, Zhuoheng Li), for initial toolchain bring-up, Ludovic Henry and velonica0 for debugging and fixing many, many feedstock PRs, RISE and OpenKylin for the compiler/runner work and offering native hardware, conda-forge/core and the individual conda-forge feedstock maintainers including Peter Williams and Pavel Zwerschke who reviewed and fixed the flood of feedstock PRs this migration produced.