Path for 'riscv64' inclusion in primary Koji #23
kashyapc
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
There is an important distinction that inclusion of
riscv64into main Koji is a part of the larger task of makingriscv64a Primary Architecture. We should first focus on the work required to move from the secondary Koji (https://riscv-koji.fedoraproject.org/) to primary Koji (https://koji.fedoraproject.org/).Today packagers can make scratch builds in https://riscv-koji.fedoraproject.org/. The eventual goal is for packagers to be able to submit regular Fedora builds for RISC-V, just like they do for
x86andaarch64.This ticket is based on these in-progress requirements for RISC-V as a primary arch.
(Cc: @abologna, @davidlt, @jmontleon, @hrw, @rjones)
Rough requirements for moving to primary Koji
Not all these requirements are "absolute" and may get adjusted based on reality and genuine trade-offs that we may need to make. (The numbering below doesn't imply priority order.)
Rack server-grade RVA23 hardware in the Fedora data center.
"Server-grade" here means performant hardware that will not cause unreasonable wait time for package maintainers. We can figure out what is "unreasonable" as a community, and as more RVA23 hardware shows up. (Refer to related discussion on "tentative build-time cap" for GCC.)
Currently, all the Fedora RISC-V Koji builder hardware is community-provided and is hosted in people's homes. The above mentioned server-grade RVA23 hardware should satisfy all essential requirements of Fedora Infrastructure. We already discussed this informally with @kevin from Fedora Infrastructure back in June 2025. I'll summarize the notes in a separate comment below.
Tracker: Add server-grade RISC-V builders in Fedora data center
Provide access to RISC-V hardware to some package maintainers.
Allow Fedora package maintainers to test/debug/build their software on RISC-V hardware. Initially, this can't be unfettered access to everyone, but more targeted.
Tracker: Make a few RISC-V test machines available for package maintainers
A Fedora kernel / OS that can run on the Fedora builders
The said Fedora kernel should not carry non-upstream patches, modulo any sensible exceptions. Flesh out the details with the Fedora primary kernel maintainers. Today, @jmontleon maintains the Fedora RISC-V omni kernel that can boot across several boards.
Benchmark Fedora package build times on RISC-V hardware
As of this writing (12 June 2026), we have some meaningful improvements on RVA23 hardware that is available today. Details of Fedora build benchmarks here: Fedora build benchmarks on SpacemiT K3 (RVA23 hardware). That said, even this is not quite enough for inclusion to main Koji, we will need another generational leap in hardware.
Other considerations:
Fedora OpenQA: The first ticket I filed almost 9 months ago was about integrating
riscv64into OpenQA. While this is very much on our mind, it should be a non-blocking requirement for inclusion in primary Koji.Fedora datacenter rough needs
This is based on a previous informal discussion with @kevin (please correct / amend, if need be):
Negotiable:
NB: The datacenter managers themselves might have additional requirements on top of the above requirements.
Please ensure the new Koji builders have at least 300GiB of storage each. This is similar to x86_64 builders.
I didn't see storage requirements being mentioned anywhere.
The storage capacity should depend based on
maxjobssettings (the number of parallel builds one can do). We are currently runningmaxjobs=1(one job per board). I checked a few machines, and we mainly use 1TB NVMe, and it goes up to 2TB NVMe. I doubt we will have a highermaxjobssetting thus storage shouldn't be a problem unless it's ridiculously expensive.