Hi,
due the increased interest in RISC-V in Fedora I took the opportunity to take a closer look and tried running some of the scripts we used for the arm/ppc/s390 secondary koji instances. After little hacking on the koji-compare.py (port to python3, deal with no f33-updates tag) I have produced https://fedora.danny.cz/riscv/f33-riscv.log comparing http://fedora.riscv.rocks with primary koji.
Here are few comments
local = fedora.riscv.rocks, remote = Fedora koji
high number of local-only is caused due the inclusion of packages blocked in primary koji, sync-blocked-primary.py should clean it up (likely needs porting to python3, it hasn’t run for maybe 5 years )
there are 168 locally(?) patched package (riscv64 string in the release tag), are those all built from the local dist-git?
for reference, the total number of packages in F-33 is 23396
The difference was ~2K packages, where ~1K is actually missing packages in our Fedora/RISCV Koji instance. The rest is older, newer, removed or unknown.
The current status should be way worse.
If the Release: contains .X.riscv64 pattern it means there are some changes that are not in upstream Fedora dist-git. If this pattern is detecting scripts avoid rebuilding the package (needs a human to look at it). Some of these changes should go into dist-git as-is, some are temporary hacks that should just go away and probably never see dist-git and some might be too terrible to even consider being part of upstream dist-git as-is.
Because we cannot reuse NVRs we also have .rvreX (RISC-V rebuild) pattern in Release: field. This just means the package was rebuilt (i.e. bumped) with no additional changes. This gives us a new NVR.
Note that %check is enabled for the last 2 or 3 years now thus tests are running and passing here.
IIRC (based on Koji reports) we did 7-6K builds (successful ones) a week, but that could be pushed towards 10K builds if you invest yourself a lot.
Jumping from the current F33 to F36 (Rawhide) most likely would be 2 to 4 highly intensive weeks.
I am not really a fan of “total number of package in Fedora”. This number is constantly changing, not all packages are available for all architectures thus total package for riscv64 in Fedora is unknown. For example, valgrind doesn’t support riscv64 and no one is working on that. Which leads to the worst thing: you cannot build 0ad
@sharkcz@davidlt do you have any up to date status on Fedora support for riscv? I was checking the Debian support and looks like they have achieved over 90% of support. Do we know where Fedora is?
I have been catching up of Fedora 37 for a number of weeks. The difference between upstream (the official Koji) and downstream is probably somewhere about ~1000 packages. Note that there are <700 packages that don’t build in Fedora 37 in general, and I do notice a lot of generic issues in the failed build logs.
The focus now shift towards generating F37 disk image and then moving Koji to a new server (already booted).
Once we are in a new Koji we will incl. F38/Rawhide efforts.
One side note, Fedora 37 is purely compiled on hardware and no QEMU was used!
that’s good news @davidlt! What could be done to ensure Fedora has a reliable set of resources for Risc-V? BTW, I’m a Technical Program Manager at Linux Foundation/RISC-V International.
Nothing really changed in recent years. Short answer is hardware. In particularly we need standards based server-grade hardware with traditional BMC (plug-and-play deployment). Don’t get we wrong, we also need developer and user hardware that would be based on the same standards. You are not gonna get those bug reports if users are using the software. There are very few folks that run RISC-V desktop systems. We just got psABI ratified, RISC-V profiles should follow soonish. Other specs are still a year or more away.
Simply put standards based server-grade hardware helps us to build Linux disitributions, but without users that’s not a healthy ecosystem. I want those bug reports
I am interested in this too. I teach computer science, and we hope to migrate some low-level programming courses to RISC-V. I presently maintain a simulated RISC-V Fedora host that runs in QEMU.
The host I maintain is based on the pre-built images that are available at Index of /pub/alt/risc-v/repo/virt-builder-images/images. These are out-of-date, but I have not yet found another pre-built image that is as convenient to get running in QEMU.
David, I can help with the bug reports. I am also a Fedora packager, so I hope to help with more as things move forward. One thing I noted was that the Fedora documentation could use some updates and other work:
There is already new Fedora 37 riscv64 disk images in the Koji system (fedora.riscv.rocks). Actually one SiFive HiFive Unmatched board is already running it and connected to Koji Hub. So far it’s looks good enough. It also survived initial tests with stress-ng. There was about ~50 packages that needed updates. That’s almost done. Right now I am trying to update LLVM/Clang (and potentially Rust) before attempting to provide new disk images via virt-builder repo. This most likely to happen next week.
I plan to create more accounts in fedora.riscv.rocks after we do the migration to a new Koji server in AWS. Sadly we are counting the last GBs in our fast NVMe /mn/koji storage. This is what blocks us from going crazy again. I am spending time fixing small things in existing Koji setup, reviewing fedora-infra ansible files, and testing various new settings, etc. before I start moving everything out to a new server. Once the initial Fedora 37 is available in virt-builder the migration will start. Until that finishes no fixes will be possible.
I highly advice joining Fedora RISC-V Matrix channel ( #riscv:fedoraproject.org ). There is also a bridge to #fedora-riscv channel on Libera.Chat. These channels also contain rapid updates on what’s cooking.
We are almost back at producing latest Fedora for RISC-V (riscv64)
)