<@kashyapc:fedora.im>
16:00:24
!startmeeting riscv-sig
<@meetbot:fedora.im>
16:00:26
Meeting started at 2026-02-03 16:00:24 UTC
<@meetbot:fedora.im>
16:00:26
The Meeting name is 'riscv-sig'
<@kashyapc:fedora.im>
16:01:00
!hi
<@zodbot:fedora.im>
16:01:01
Kashyap Chamarthy (kashyapc)
<@kashyapc:fedora.im>
16:01:26
Alright, who is around for the RISC-V meeting today
<@rwmj:matrix.org>
16:02:11
!hi
<@zodbot:fedora.im>
16:02:14
FAS Richard W.M. Jones (rjones)
<@nhanlon:beeper.com>
16:02:47
!hi
<@zodbot:fedora.im>
16:02:49
Neil Hanlon (neil) - he / him / his
<@kashyapc:fedora.im>
16:04:17
What topics have we got today? I have a couple on my mind (as a follow-up from FOSDEM)
<@davidlt:matrix.org>
16:04:39
!Hi
<@kashyapc:fedora.im>
16:04:55
I think you have a typo :)
<@davidlt:matrix.org>
16:05:12
!hi
<@zodbot:fedora.im>
16:05:15
David Abdurachmanov (davidlt)
<@davidlt:matrix.org>
16:05:41
Thinking about the topics.
<@kashyapc:fedora.im>
16:05:45
Okay, let's get started.
<@jmontleon:fedora.im>
16:05:59
!hi
<@kashyapc:fedora.im>
16:06:00
!topic F43 / F44 status
<@zodbot:fedora.im>
16:06:01
Jason Montleon (jmontleon) - he / him / his
<@davidlt:matrix.org>
16:06:14
Well, we have continues to do bumps for debugedit and a few major items are left (kernel, llvm, etc.) based on existing list.
<@kashyapc:fedora.im>
16:06:58
Okay, I guess this list can be queried via Koji, for the interested folks?
<@davidlt:matrix.org>
16:07:01
I flushed all diff between two Koji instances for f43-updates. We can investigate the logs to see what's interesting there.
<@davidlt:matrix.org>
16:07:35
Something like: `koji -p riscv list-builds --quiet --state FAILED --after=$(date -u -d '-2 days' +%s) | awk '{ print $1 }' | xargs -n1 -t -P4 koji -p riscv download-logs --nvr`
<@kashyapc:fedora.im>
16:07:36
What logs do you mean? :)
<@davidlt:matrix.org>
16:08:03
There is one package that failed with debugedit, but so far I don't see what caused that.
<@kashyapc:fedora.im>
16:08:49
I see, we can follow this up on the main channel. Thanks for the query.
<@davidlt:matrix.org>
16:08:50
In general my silly script says the delta is ~900, out of which 60 or so are probably Fedora-* disk images. A large number of these are disabled for riscv64.
<@davidlt:matrix.org>
16:09:12
I did enable a few: libunicode, libkrun, etc. that should work on riscv64 now.
<@davidlt:matrix.org>
16:09:32
So in general the diff is at record low for F43 as-is.
<@kashyapc:fedora.im>
16:09:46
Nice!
<@kashyapc:fedora.im>
16:10:07
!info The diff between F43 and the primary koji is at a "record low" :)
<@davidlt:matrix.org>
16:10:09
Mark also posted a patch to improve find-debuginfo to use elflint to figure out what gets damanged. Not enabled by default.
<@kashyapc:fedora.im>
16:10:30
What logs do you mean :)
<@kashyapc:fedora.im>
16:11:13
I think you're referring to this: https://sourceware.org/bugzilla/show_bug.cgi?id=33827
<@davidlt:matrix.org>
16:11:39
Correct.
<@kashyapc:fedora.im>
16:11:55
Great. Okay, anything else on this? Or shall we move to the next one?
<@abologna:matrix.org>
16:13:03
!hi
<@zodbot:fedora.im>
16:13:08
None (abologna)
<@davidlt:matrix.org>
16:13:26
Someone asked today for us to upload container images to registry once we have newer images.
<@kashyapc:fedora.im>
16:13:27
Welcome, None
<@kashyapc:fedora.im>
16:13:40
F43?
<@davidlt:matrix.org>
16:14:08
Yeah. They are using for bootstrap, but building their own containers right now.
<@kashyapc:fedora.im>
16:14:46
I lost track of the registry URL; do we ever publish Fedora RISC-V images to a public registry?
<@abologna:matrix.org>
16:14:53
uploading the images should be fine, IIRC a location was identified
<@abologna:matrix.org>
16:15:06
keeping them up to date over time, now that's a different thing
<@abologna:matrix.org>
16:15:12
maybe we don't really need to do that
<@davidlt:matrix.org>
16:15:17
Yes, https://quay.io/organization/fedora-testing
<@abologna:matrix.org>
16:15:22
people will just have to `dnf update` after pulling
<@kashyapc:fedora.im>
16:15:24
Found it: https://quay.io/repository/fedora-testing/fedora-riscv
<@abologna:matrix.org>
16:15:34
which they would want to do anyway
<@davidlt:matrix.org>
16:15:37
Cooking a new image is easy. Might as well be a few lines + cron.
<@davidlt:matrix.org>
16:16:12
Anyways, just something to remember to do at least once 😄
<@kashyapc:fedora.im>
16:16:34
Okay. You mean generate the image and upload the above registry? Right now it's empty. It also
<@kashyapc:fedora.im>
16:17:00
I now recall, this also came up in the RISE "distro integration" call a month ago. I just pointed to this URL.
<@davidlt:matrix.org>
16:17:27
At some point we should go back to see what we can do about Pungi Compose. nirik got some VM Hosts running with Fedora 43, but we never added required VMs.
<@kashyapc:fedora.im>
16:17:33
!info David is cooking a new container image and it will likely be published to the Quay registry: https://quay.io/repository/fedora-testing/fedora-riscv
<@kashyapc:fedora.im>
16:17:47
!info David is cooking a new F43 container image and it will likely be published to the Quay registry: https://quay.io/repository/fedora-testing/fedora-riscv
<@davidlt:matrix.org>
16:18:02
Note, we do have OCI tarballs today (in Koji), we just never marked anything GA due to corrupted DWARF.
<@kashyapc:fedora.im>
16:18:26
Okay, noted.
<@kashyapc:fedora.im>
16:19:17
!info The RISC-V Koji has OCI tarballs today, but haven't marked them as "GA" due to the DWARF corruption bug during F43 (now resolved)
<@kashyapc:fedora.im>
16:19:24
Okay, anything more here?
<@davidlt:matrix.org>
16:19:26
Otherwise Fedora 44 is branching soon, which is a good indication to start cooking F44 too.
<@kashyapc:fedora.im>
16:19:48
Oh, right; today is F44 branching, or was it yesterday?
<@davidlt:matrix.org>
16:20:01
I don't recall, but there was an email yesterday about it.
<@kashyapc:fedora.im>
16:20:02
Today
<@davidlt:matrix.org>
16:20:20
Yeah, it's today.
<@kashyapc:fedora.im>
16:20:51
!info F44 is branching from Rawhide today
<@davidlt:matrix.org>
16:21:10
I am still rebuilding llvm and need to look at the kernel.
<@davidlt:matrix.org>
16:21:38
Jason Montleon: is working on unified kernel for the other boards (that don't use generic kernel). Do we want to use that? v6.19.X I think.
<@kashyapc:fedora.im>
16:22:14
Right, the framework laptop stuff, IIRC
<@davidlt:matrix.org>
16:22:25
It will be 2-4 weeks before v6.19 officially lands in F43. The release date is this weekend.
<@kashyapc:fedora.im>
16:22:58
Yep. Jason Montleon Have anything to report on the unified kernel bits?
<@jmontleon:fedora.im>
16:24:03
<@jmontleon:fedora.im>
16:24:03
It works as it did when I tested RC2. We tested a build on jupiter with rc7. rc8 is cooking now in copr.
<@jmontleon:fedora.im>
16:24:03
I have no strong preference. We could use it for F43, or keep the status quo for F43 and use it for F44.
<@davidlt:matrix.org>
16:25:37
I am fine keeping things as-is (spacemit and p550 repos) and landing it initial in F44, and maybe F43 later on.
<@jmontleon:fedora.im>
16:25:47
We could do just two images. The one with the stock kernel, and one with the extra. fml13v01 will boot with the extra, so they can switch if they want the better graphical support from the vendor kernel.
<@jmontleon:fedora.im>
16:25:47
fml13v03 is the only headache as it doesn't boot with either, so if we want to make a special one for that with the vendor kernel that'd be the only one that really needs it outside of everything else the other two support.
<@jmontleon:fedora.im>
16:25:47
<@kashyapc:fedora.im>
16:26:05
Whatever is the easiest for _you_, since you're doing the work ;-) Just make the decision as you see fit :)
<@abologna:matrix.org>
16:26:12
that sounds good to me too
<@abologna:matrix.org>
16:26:28
I mean keeping things as-is for F43
<@abologna:matrix.org>
16:26:43
and look into switching to the unified kernel for F44
<@jmontleon:fedora.im>
16:27:18
that seems sane; then we just set up the f44-unified buildroot or whatever come F44
<@abologna:matrix.org>
16:27:27
yup
<@davidlt:matrix.org>
16:27:30
We can backport those kernels to F43 later on. We have been looking at some potential failure due to v6.6 kernel on P550 boards.
<@jmontleon:fedora.im>
16:27:49
and spacemit vendor kernel for that matter
<@jmontleon:fedora.im>
16:28:09
the fuzz tests in libkcapi failing on 6.18.8 spacemit
<@abologna:matrix.org>
16:28:12
I am personally aggressively uninterested in backporting features to older releases :)
<@davidlt:matrix.org>
16:28:17
Yeah. Note, this is not a major impact. Landing a few (max) builds on something with newer kernel seems to solve it.
<@davidlt:matrix.org>
16:28:51
Well, technically it's not "backporting". F43 will get this kernel version withing a few weeks.
<@davidlt:matrix.org>
16:29:22
(and we starting to hit some issues with older LTS kernels)
<@jmontleon:fedora.im>
16:29:23
yes. and it will be brainless to send a kernel build; either way. I don't mind sending it if we have a builroot to build it in
<@jmontleon:fedora.im>
16:29:33
I'll do it in copr at the least
<@jmontleon:fedora.im>
16:30:27
And for F44 I imagine i'll stop maintaining and pointing people at my people.whatever repos and just point to copr
<@davidlt:matrix.org>
16:30:37
So let's keep things as-is (structure wise). Go with unified kernel in F44, and then discuss in a couple of meeting (or more) about bringing it in F43.
<@davidlt:matrix.org>
16:31:13
I keep forgetting that we also have COPR working with QEMU : smi
<@davidlt:matrix.org>
16:31:24
😄
<@davidlt:matrix.org>
16:32:00
kernel, llvm, etc. should get a large core count machines, but that doesn't work yet, I think. Jason Montleon probably know more as he is already using it.
<@kashyapc:fedora.im>
16:32:06
So, to summarize: what's the kernel version again we're sticking to F43: 6.18?
<@davidlt:matrix.org>
16:32:22
Jason Montleon do you remember to which FAS group we connect COPR stuff?
<@kashyapc:fedora.im>
16:32:33
And for F44, 6.19 ... something?
<@davidlt:matrix.org>
16:32:33
v6.18 initially.
<@kashyapc:fedora.im>
16:32:47
https://copr.fedorainfracloud.org/groups/g/forge-riscv-members/coprs/
<@kashyapc:fedora.im>
16:33:02
davidlt: Is the above is what you're looking for?
<@davidlt:matrix.org>
16:33:34
Yes
<@kashyapc:fedora.im>
16:33:38
Okay, v6.18 initially for F44, then switch to v6.19
<@kashyapc:fedora.im>
16:34:05
!info Kernel status: stick to v6.18 for F44,and then swithc to v6.19. Jason continues to test/build unified kernels
<@davidlt:matrix.org>
16:35:11
We also should mention and kashyapc delivered a great talk at FOSDEM about Fedora RISCV. Video is now available to download. Send all the cookies to kashyapc 😉
<@davidlt:matrix.org>
16:36:04
The details about the talk is here: https://fosdem.org/2026/schedule/event/SQGLW7-fedora-on-riscv/
<@kashyapc:fedora.im>
16:37:11
Heh, thank you to everyone for the great help in reviews. David also was present on Matrix and answered questions :)
<@davidlt:matrix.org>
16:37:31
Yes, I did.
<@kashyapc:fedora.im>
16:37:34
!info FOSDEM talk on the state of RISC-V on Fedora (video and slides are up): https://fosdem.org/2026/schedule/event/SQGLW7-fedora-on-riscv/
<@kashyapc:fedora.im>
16:37:48
Changing topic:
<@kashyapc:fedora.im>
16:37:55
!topic Follow ups from FOSDEM
<@davidlt:matrix.org>
16:37:57
IIRC (from the camera feed) kashyapc and Marcin helped with RISC-V room management too!
<@kashyapc:fedora.im>
16:39:01
Ah, you mean the Matrix channel management? Sure,I missed it. I was buried in the in-room logistics. It was tiring as hell to be locked in a windows-less room :D Next time, I'll ask Björn to apply for a better room :)
<@kashyapc:fedora.im>
16:40:06
One of the questions I got was on the "when" to switch to RVA23 baseline. I know we discussed it extensively on the channel and elsewhere. I'm losing track of all the variables/details.
<@davidlt:matrix.org>
16:40:06
The physical room.
<@davidlt:matrix.org>
16:40:45
I don't think there is a plan, but at least I have my opinion (which is not set in stone).
<@kashyapc:fedora.im>
16:40:55
No, physical room was Björn, Anders Roxell, and myself from Linaro
<@davidlt:matrix.org>
16:41:26
A simple summary of my opinion is that I don't want to export RVA64GC -> RVA23 "issue" to the main Koji and FESCo.
<@kashyapc:fedora.im>
16:41:28
Right, you gave some of it in the email review of my slides. Is it okay if I start working with that in an Etherpad and then take it from there?
<@jmontleon:fedora.im>
16:42:16
davidlt: forge-riscv-members
<@kashyapc:fedora.im>
16:42:19
Sure, I understand. A couple of long-time Fedora maintainers also suggested in the hallway: let's "rip the band-aid" by switching to RVA23 at the earliest possible
<@jmontleon:fedora.im>
16:42:31
Our coprs are at https://copr.fedorainfracloud.org/groups/g/forge-riscv-members/coprs/
<@kashyapc:fedora.im>
16:42:39
No, physical room was Björn, Anders Roxell from Linaro, and myself.
<@kashyapc:fedora.im>
16:42:46
Yeah, already pointed above :)
<@davidlt:matrix.org>
16:42:48
We can, but I don't think we have full control on all elements here. For example, what if RH buys non-RVA23 hardware for DC. In that case the choice is obvious. I doubt that will happen.
<@kashyapc:fedora.im>
16:43:05
Okay, for this meeting purpose, this summary is good enough
<@kashyapc:fedora.im>
16:43:53
Yeah, I know what you mean. I don't think that decision is set in stone yet. As near as I know, I can check again.
<@davidlt:matrix.org>
16:44:42
I really doubt RH would be willing to buy rackable servers that aren't RVA23 / Server Compliant 😄
<@kashyapc:fedora.im>
16:44:46
!info RVA23: it's a loaded topic, but for now David suggests to not export the RVA64GC -> RVA23 "issue" to the main Koji and FESCo
<@davidlt:matrix.org>
16:45:48
Reminder that we aren't changing ABI. The idea of ABI with better vector handling basically is dead for now. It's unlikely that distributions will pick it up.
<@davidlt:matrix.org>
16:46:22
That means you should be able to mix RV64GC + RVA23 binaries, and thus easy to switch the baseline. Not everything needs to switch at the same time.
<@kashyapc:fedora.im>
16:46:29
That's my understanding too. FWIW, on the Fedora side, I filed this ticket to track it:
<@kashyapc:fedora.im>
16:46:29
<@kashyapc:fedora.im>
16:46:29
- https://forge.fedoraproject.org/riscv/planning/issues/6 ([Tracker] RISC-V builders in Fedora datacenter)
<@kashyapc:fedora.im>
16:46:29
- https://forge.fedoraproject.org/riscv/planning/issues/7 ( Make a few RISC-V test machines available for package maintainers)
<@rwmj:matrix.org>
16:46:46
does anyone know what x86 did when vectors were added?
<@davidlt:matrix.org>
16:47:39
You can.
<@kashyapc:fedora.im>
16:48:06
I don't know myself. We can figure it out by asking, I guess :)
<@kashyapc:fedora.im>
16:49:45
Richard Jones: On the topic of vectors: at the RISC-V Summit, Paul Walmsley (current RISC-V subsystem maintainer in the kernel) asked if anyone did a systematic analysis of vector stuff. E.g.:
<@davidlt:matrix.org>
16:50:15
I a did a quick Gemini round. This might not had been as big problem on x86_64 land.
<@kashyapc:fedora.im>
16:50:35
Extract each SRPM, unpack, and scan it to see whether it contains x86 or ARM SIMD code, but not RISC-V vector code. Then log all that stuff into a file, and then analyze/take it from there.
<@kashyapc:fedora.im>
16:50:59
- https://forge.fedoraproject.org/riscv/planning/issues/7 (Make a few RISC-V test machines available for package maintainers)
<@kashyapc:fedora.im>
16:50:59
That's my understanding too. FWIW, on the Fedora side, I filed this ticket to track it:
<@kashyapc:fedora.im>
16:50:59
<@kashyapc:fedora.im>
16:50:59
- https://forge.fedoraproject.org/riscv/planning/issues/6 (\[Tracker\] RISC-V builders in Fedora datacenter)
<@davidlt:matrix.org>
16:51:32
Gemini reminded me that SSE, AVX, AVX512 registers are basically extensions.
<@kashyapc:fedora.im>
16:51:35
(Time check: 9 min to go)
<@davidlt:matrix.org>
16:52:57
Anyways, there is no new ABI here. We continue to use the stack, and in high-performance code you can switch to register passing with attributes and pragmas.
<@kashyapc:fedora.im>
16:53:12
Right; we can dig into the details on the channel :)
<@kashyapc:fedora.im>
16:53:22
Right; we can dig into the details on the main channel :)
<@kashyapc:fedora.im>
16:53:36
Shall we switch topics? I have one last
<@davidlt:matrix.org>
16:53:51
Go ahead. I am out of topics.
<@kashyapc:fedora.im>
16:54:27
!topic Fedora "community initiative" for RISC-V: https://docs.fedoraproject.org/en-US/project/initiatives/
<@kashyapc:fedora.im>
16:54:47
Matthew Miller suggested a few weeks to file a "community initiative" sooner than later.
<@kashyapc:fedora.im>
16:55:08
The rationale is it is better to start the discussion sooner than later.
<@kashyapc:fedora.im>
16:55:40
To propose a Community Initiative to the Council ... discuss on the #council tag on Fedora Discussion. Next, if well-received, file a ticket. Of course, people need to be ready to do the actual work required — a Community Initiative without passionate bottom-liners will not get far.
<@kashyapc:fedora.im>
16:55:40
The process is this:
<@kashyapc:fedora.im>
16:55:40
```
<@kashyapc:fedora.im>
16:55:40
```
<@davidlt:matrix.org>
16:55:51
So basically this is 1-3 Fedora cycles (up to 18 months) process for larger changes.
<@kashyapc:fedora.im>
16:56:04
```
<@kashyapc:fedora.im>
16:56:04
```
<@kashyapc:fedora.im>
16:56:04
To propose a Community Initiative to the Council ... discuss on the #council tag on Fedora Discussion. Next, if well-received, file a ticket [...]
<@kashyapc:fedora.im>
16:56:04
The process is this:
<@kashyapc:fedora.im>
16:56:04
<@davidlt:matrix.org>
16:56:13
I assume it's a suggestion to start a process of getting riscv64 into Fedora.
<@kashyapc:fedora.im>
16:56:28
Yes, exactly.
<@davidlt:matrix.org>
16:56:43
short term, mid term, long term tasks.
<@kashyapc:fedora.im>
16:57:16
Let's hash out the text in an Etherpad (https://etherpad.opendev.org/p/riscv-fedora-community-initiative) and then take it from there. What do people think?
<@davidlt:matrix.org>
16:58:11
I think, we have been doing it already without having a "formal initiative". Koji, FAS integration, COPR, etc.
<@kashyapc:fedora.im>
16:58:34
Right, this is just some process. I want to keep it light and not get lost in a morass of "process".
<@kashyapc:fedora.im>
16:59:10
The process outlined in the above doc is not set in stone. We will adapt it for our reality.
<@kashyapc:fedora.im>
16:59:25
!agreed A Fedora "community initiative" for RISC-V: we're going to hash out the details with the RISC-V SIG and file a discussion ticket
<@kashyapc:fedora.im>
16:59:36
I hope the above is a fair agreeement? :)
<@kashyapc:fedora.im>
16:59:43
I hope the above is a fair agreement? :)
<@kashyapc:fedora.im>
17:00:02
One minute to go.
<@davidlt:matrix.org>
17:00:13
👍️
<@kashyapc:fedora.im>
17:00:28
Alright. Time is up. We'll continue the chat in the main room.
<@kashyapc:fedora.im>
17:00:33
Thanks everyone for showing up!
<@kashyapc:fedora.im>
17:00:46
!endmeeting