<@nirik:matrix.scrye.com>
16:00:03
!startmeeting riscv-sig
<@meetbot:fedora.im>
16:00:05
Meeting started at 2024-11-12 16:00:03 UTC
<@meetbot:fedora.im>
16:00:05
The Meeting name is 'riscv-sig'
<@nirik:matrix.scrye.com>
16:00:08
!meetingname riscv-sig
<@meetbot:fedora.im>
16:00:09
The Meeting Name is now riscv-sig
<@nirik:matrix.scrye.com>
16:00:14
!info agenda doc: https://hackmd.io/SPrxvhU0Sv2l5Ox7zqg01A
<@rwmj:matrix.org>
16:00:16
agenda: https://hackmd.io/SPrxvhU0Sv2l5Ox7zqg01A
<@nirik:matrix.scrye.com>
16:00:19
!topic introductions
<@nirik:matrix.scrye.com>
16:00:24
hey everyone.
<@davidlt:matrix.org>
16:00:32
Hey 👋
<@rwmj:matrix.org>
16:00:33
hello
<@abologna:matrix.org>
16:00:42
hey there :)
<@nhanlon:beeper.com>
16:00:59
!hi
<@zodbot:fedora.im>
16:01:00
Neil Hanlon (neil) - he / him / his
<@nhanlon:beeper.com>
16:01:08
good morning folks :) glad to have everyone in one place!
<@nirik:matrix.scrye.com>
16:01:14
I'm here, but will probibly have to step away for a few at the bottom of the hour...
<@jonathanspw:fedora.im>
16:01:18
!hi
<@zodbot:fedora.im>
16:01:19
Jonathan Wright (jonathanspw)
<@davidlt:matrix.org>
16:01:42
!hi
<@zodbot:fedora.im>
16:01:44
David Abdurachmanov (davidlt)
<@abologna:matrix.org>
16:01:55
I've never attended one of these text-based SIG meetings so please bear with me :)
<@nirik:matrix.scrye.com>
16:02:13
Perhaps we want to have everyone give a quick oneliner on who they are...
<@nirik:matrix.scrye.com>
16:02:31
I'm Kevin Fenzi, I work at Red Hat on Fedora infrastructure and releng stuff.
<@wmat:matrix.org>
16:02:39
greetings, long time lurker, first time attendee.
<@rwmj:matrix.org>
16:02:50
Richard Jones, been packaging for Fedora for a good while, and have worked on RISC-V packaging
<@jonathanspw:fedora.im>
16:03:19
Jonathan Wright. I'm a Fedora packager/sponsor and I'm the infra lead at AlmaLinux where we are actively bootstrapping almalinux kitten 10 for risc using much of Fedora's work in the space.
<@abologna:matrix.org>
16:04:00
Andrea Bolognani, also working for Red Hat. I've been involved with the Fedora RISC-V effort mostly in the context of reducing the delta with regular Fedora. for that purpose I've created https://abologna.gitlab.io/fedora-riscv-tracker/
<@jefro:matrix.org>
16:04:29
HI all - Jefro here, I work in the Red Hat OSPO, centos board, and RISC-V board
<@jmontleon:fedora.im>
16:04:31
Jason Montleon, work at Red Hat on Migration Engineering team and Fedora packager for a handful of packages.
<@davidlt:matrix.org>
16:04:37
Sure. Long-term Fedora/RISCV contributor (since 2016). Working on Fedora/RISCV infrastructure, images (disk & container), porting, etc. Used to work for SiFive, now at Rivos Inc.
<@rwmj:matrix.org>
16:04:50
Jason, what's "migration engineering"?
<@khanicov:matrix.org>
16:05:16
Hello, Kristina Hanicova, I work part-time at RH and have Andrea as my buddy, working on the same thing rn
<@nhanlon:beeper.com>
16:05:36
Rocky intends to be supporting RV in version 10--we have a fairly complete test candidate built off VF2 given by RVI, (minus some rebuilds due to c10s changes).
<@nhanlon:beeper.com>
16:05:36
I'm Neil Hanlon. I work at CIQ; Infrastructure of Rocky Linux project (one of the founders, board member). Have been helping out with this fedora effort for a little over a year now (I think).
<@nhanlon:beeper.com>
16:05:36
<@nhanlon:beeper.com>
16:06:19
Rocky intends to be supporting RV in version 10--we have a fairly complete test candidate built off VF2 given by RVI, (minus some rebuilds due to c10s changes).
<@nhanlon:beeper.com>
16:06:19
I'm Neil Hanlon. I work at CIQ; Infrastructure lead for Rocky Linux project (one of the founders, board member). Have been helping out with this fedora effort for a little over a year now (I think).
<@nhanlon:beeper.com>
16:06:19
<@conan_kudo:matrix.org>
16:07:08
!hi
<@zodbot:fedora.im>
16:07:09
Neal Gompa (ngompa) - he / him / his
<@jmontleon:fedora.im>
16:07:11
These days for example working on MTA https://developers.redhat.com/products/mta/overview , in the past MTC (and to a certain extent still) https://docs.openshift.com/container-platform/4.17/migration_toolkit_for_containers/about-mtc.html. MTV (virtual machines) also falls under that though I did not personally work on it.
<@nirik:matrix.scrye.com>
16:07:16
excellent. lots of folks. ;) Thanks everyone for attending. I whipped up a quick agenda doc, but we don't have to follow it if we want to do other topics... but first perhaps a bit of administravia: should we try and meet weekly? every other week? as desired? regular meetings I think would be good...
<@rwmj:matrix.org>
16:07:22
Neil Hanlon: are you intending to change the arch/ABI baseline for rocky 10?
<@conan_kudo:matrix.org>
16:07:35
Hey, I'm Neal. I do stuff. I'd like Fedora KDE to be the first to support RISC-V.
<@nhanlon:beeper.com>
16:07:50
negative; it's an AltArch SIG effort
<@nhanlon:beeper.com>
16:08:16
(if c10s were to change... that's a different story ;) )
<@abologna:matrix.org>
16:08:21
nirik: I vote for every other week to reduce the meeting fatigue
<@conan_kudo:matrix.org>
16:08:27
My "day job" is as a consultant for Velocity Limitless. :)
<@davidlt:matrix.org>
16:08:29
nirik: I would go with regular meeting. I would image that initial move towards a new Koji infra will raise a lot more questions to everyone.
<@jonathanspw:fedora.im>
16:08:30
+1
<@jefro:matrix.org>
16:08:32
nirik: I vote for every other week
<@rwmj:matrix.org>
16:08:35
yes every other week
<@nhanlon:beeper.com>
16:08:37
I am good with biweekly.
<@abologna:matrix.org>
16:08:38
but yes to making it a regular thing
<@wmat:matrix.org>
16:08:47
every other week vote as well
<@nirik:matrix.scrye.com>
16:08:58
ok, every other week seems to win. ;)
<@conan_kudo:matrix.org>
16:09:13
Whatever the cadence, it needs to be regular.
<@nhanlon:beeper.com>
16:09:16
but I wanted the _other_ every other week...
<@nirik:matrix.scrye.com>
16:09:40
!topic Current Status
<@nirik:matrix.scrye.com>
16:10:04
So, where are we now? perhaps davidlt could give a quick summary?
<@davidlt:matrix.org>
16:11:33
We have disk and container images for F40, and some of our builders are using. The most available and popular board VF2 is supported. Full U-Boot + UEFI + GRUB2 + BLS boot stack available (not upstreamed) [block or/and WIP]. F41 is ready (or almost ready for disk image creation). Didn't standard F42 efforts yet.
<@nirik:matrix.scrye.com>
16:12:30
!link https://abologna.gitlab.io/fedora-riscv-tracker/
<@nirik:matrix.scrye.com>
16:12:31
too
<@nirik:matrix.scrye.com>
16:13:15
ok, anything more we want to discuss with current status/setup? or move on to next plans?
<@davidlt:matrix.org>
16:13:30
I think, future priorities will depend on how/when we plan to boot the new infra.
<@abologna:matrix.org>
16:14:09
I'll just point out that some of the packages listed in the tracker are probably relatively low-hanging fruits
<@abologna:matrix.org>
16:14:22
and they just need someone to take the existing patches and upstream them
<@abologna:matrix.org>
16:14:26
me and Kristina are working on that
<@davidlt:matrix.org>
16:14:54
Some of the PRs/MRs are made, but had no review or were rejected by the maintainer too.
<@abologna:matrix.org>
16:14:55
however, a small number of them require potentially significant upstream work
<@abologna:matrix.org>
16:15:35
the goal is to get the numbers way down by F42, but realistically I expect that a dozen or so packages will still require downstream changes
<@davidlt:matrix.org>
16:15:43
Like shim or/and GRUB2 being a multi-year saga by now.
<@nirik:matrix.scrye.com>
16:15:59
or audit or pesign...
<@davidlt:matrix.org>
16:16:15
True, there will more on this list (e.g. libffi).
<@abologna:matrix.org>
16:16:39
so whatever we plan when it comes to pushing riscv64 closer to a primary architecture will need to involve a git overlay of some kind for a while longer
<@rwmj:matrix.org>
16:17:20
libffi is unfortunately a bit of a lost cause, we may need to just take the patch downstream (in the overlay git, sigh)
<@rwmj:matrix.org>
16:18:04
the alternative is to raise the dispute to fesco level, but I don't really want to go there
<@jonathanspw:fedora.im>
16:18:22
grpc needs some updating in fedora/rawhide to fix its issues. it's quite behind in fedora.
<@rwmj:matrix.org>
16:18:48
Jonathan Wright: is there a fedora PR for that? I can do this kind of thing
<@jonathanspw:fedora.im>
16:18:50
Looks like Neil Hanlon owns the package
<@davidlt:matrix.org>
16:18:53
Or remove the symlink hack, but it could be expensive. I never attempted to experiment it's removal because it would require quite some time and compute cost. Not a one day project.
<@jonathanspw:fedora.im>
16:19:15
there's a bunch of PRs to update grpc but none go far enough. The fixes for riscv aren't tagged yet on the grpc side unfortunately
<@nhanlon:beeper.com>
16:19:26
it's a bit complex, but I'd be happy to work with anyone on it. I inherited it from music -- have it slated to work on end of this month
<@jonathanspw:fedora.im>
16:19:32
but they're int he master branch and once grpc is updated we could do a PR with a patch for the risc issues.
<@davidlt:matrix.org>
16:19:35
Yes, we discussed grpc and something else related to it being quite outdated and causing segfaults on riscv64.
<@jonathanspw:fedora.im>
16:19:50
yeah, can confirm the patches in master branch upstream fix it
<@jonathanspw:fedora.im>
16:19:53
yeah, can confirm the patches in master branch upstream fix grpc
<@abologna:matrix.org>
16:19:58
we need to keep pushing on the upstream side where necessary
<@davidlt:matrix.org>
16:20:50
Yeah, Fedora grpc is outdated. IIRC it's related to protobuf 3 compatibility. Anyways, it's probably off topic (or a long-term topic category thing).
<@abologna:matrix.org>
16:21:03
hopefully most of it should be in the past though? I expect that only a handful of packages really still need upstream work
<@davidlt:matrix.org>
16:21:06
Not directly a riscv64 thing, but affects us the most probably.
<@nirik:matrix.scrye.com>
16:21:11
the protobuf saga is a long and painfull one. ;(
<@nirik:matrix.scrye.com>
16:21:49
Anyhow, shall we move on to short term plans?
<@davidlt:matrix.org>
16:21:55
Sure.
<@nirik:matrix.scrye.com>
16:22:23
!topic Short term plans
<@nirik:matrix.scrye.com>
16:23:36
So, my understanding on things is that we want to move to a 'secondary' koji/setup but still using remote builders (since enterprise hw is still not really available). Then once hw is available, add that, then finally look at promotion into primary fedora.
<@nirik:matrix.scrye.com>
16:23:59
I have hardware ready for the secondary hub/db/etc... I haven't yet set it up because of fires, but I can very soon.
<@nirik:matrix.scrye.com>
16:24:11
But we need to determine some things about that
<@davidlt:matrix.org>
16:24:22
Correct. There are no hardware available that would meet Red Hat requirements for deployment (today).
<@nirik:matrix.scrye.com>
16:24:38
The git overlay and how it would work in this setup
<@jefro:matrix.org>
16:24:49
I can offer no details, but I can hint that hardware should be available over the next few months
<@nirik:matrix.scrye.com>
16:25:05
what we import or not from existing hub/db/packages
<@nirik:matrix.scrye.com>
16:25:13
policy on builders, etc.
<@davidlt:matrix.org>
16:25:27
I looked at Packit setup. I think, something like that would work. Packit is a user, and it could have a group of folks that could create forks there.
<@nirik:matrix.scrye.com>
16:26:02
thats an interesting idea...
<@abologna:matrix.org>
16:26:23
could we perhaps host the overlay as branches on forks in pagure? keep things as close as possible to the end goal setup
<@davidlt:matrix.org>
16:26:36
https://src.fedoraproject.org/user/packit/groups
<@nirik:matrix.scrye.com>
16:26:46
it would likely need adjustments as you can't do official builds from a fork in primary... but we could perhaps adjust it to allow packit forks in this secondary
<@davidlt:matrix.org>
16:27:14
This way we don't need to user personal forks and things are under a single user (with multiple folks having access to it).
<@abologna:matrix.org>
16:28:02
the idea sounds good when you describe it like that, but I'm concerned that it involves adding another software component into the mix
<@davidlt:matrix.org>
16:28:06
Yeah, you would need to add a line for SCM to allow specific /fork/<our_user>/* pattern (or something).
<@abologna:matrix.org>
16:28:10
doesn't packit have its own processes and stuff?
<@conan_kudo:matrix.org>
16:28:12
please don't do any of that
<@conan_kudo:matrix.org>
16:28:21
this will create a couple of problems
<@timaeos:matrix.nexaeos.io>
16:28:21
just to clarify, is this waiting on RVA23 profile hardware?
<@davidlt:matrix.org>
16:28:32
I am talking about Packit user in Pagure, not anything else.
<@conan_kudo:matrix.org>
16:28:34
first, it's a nightmare for tracking what is going on and what's getting built
<@jonathanspw:fedora.im>
16:28:38
I think it's more or less just reasonably powerful, rack-mountable hardware
<@jonathanspw:fedora.im>
16:28:57
tenstorrent has some big stuff in the works from what I hear but not expected until like q3/4 2025
<@nirik:matrix.scrye.com>
16:28:58
timaeos: no, it's waiting on hardware that is rack mountable, has mgmt interfaces, etc... ie, datacenter quality. oh, and is fast enough.
<@abologna:matrix.org>
16:29:05
with remote power control and console access
<@conan_kudo:matrix.org>
16:29:06
second, if everything is running through packit without user interaction, then you risk appearing inactive and your packages orphaned
<@conan_kudo:matrix.org>
16:29:24
we've already had a couple of packagers go the full packit route and lose their privileges and have all their packages orphaned
<@nirik:matrix.scrye.com>
16:29:35
uh, that seems weird.
<@conan_kudo:matrix.org>
16:29:47
that's how linux-system-roles got orphaned over the summer :)
<@davidlt:matrix.org>
16:30:02
Again, I am not talking about Packit usage. I just saying that Packit has a user under pagure. All forks are under a single location.
<@nirik:matrix.scrye.com>
16:30:08
the inactive process files a ticket for you... you have to not answer that after many months of reminders.
<@abologna:matrix.org>
16:30:10
does pagure support creating groups for group-maintained packages?
<@conan_kudo:matrix.org>
16:30:20
yes
<@nirik:matrix.scrye.com>
16:30:21
yes
<@conan_kudo:matrix.org>
16:30:23
that's how sigs work
<@abologna:matrix.org>
16:30:28
so can we just do that? :)
<@davidlt:matrix.org>
16:30:43
Exactly, we can have our own Packit-like user and assign a group (riscv) to it.
<@jonathanspw:fedora.im>
16:30:46
p550 is the first thing meeting that spec that I know of that's in prod. I think I will have some arriving in about a month then I can confirm how feature-rich the BMC is.
<@nirik:matrix.scrye.com>
16:30:55
I don't think so... because we are not maintaining those packages as a rsicv-sig...
<@conan_kudo:matrix.org>
16:30:56
and indeed they did that since they completely ignored fedora while packit churned away
<@abologna:matrix.org>
16:31:29
mmm
<@davidlt:matrix.org>
16:31:54
Jonathan Wright: P550 is not fast enough (and it's quite old). SOPHGO is probably out of the picture too (maybe) after what they potentially did with TSMC.
<@jonathanspw:fedora.im>
16:32:09
I know it's slow, just throwing out that it has bmc
<@abologna:matrix.org>
16:32:24
is this a technical thing or a policy one? could it be allowed even if it's not how things have been done up until now?
<@conan_kudo:matrix.org>
16:32:31
we're going to have to accept that we're not getting fast or good hardware
<@conan_kudo:matrix.org>
16:32:44
especially not datacenter class hardware, since none of it exists
<@davidlt:matrix.org>
16:32:45
Jonathan Wright: not that kind of BMC 😄 It's non-standard FreeRTOS thing, which doesn't work as a standard datacenter thing.
<@nirik:matrix.scrye.com>
16:32:55
so, another idea is that we make a pagure repo for the overlay and track things there? but then it will be confusing to have that + src/fp/o with pr's, etc.
<@jonathanspw:fedora.im>
16:32:57
aha. i haven't played with it yet :p
<@conan_kudo:matrix.org>
16:33:30
why aren't we merging things into fedora packages?
<@davidlt:matrix.org>
16:33:35
nirik: https://src.fedoraproject.org/user/packit/groups we do forks under our account.
<@nirik:matrix.scrye.com>
16:33:39
Definitely we want to try and make the overlay as small as possible.
<@rwmj:matrix.org>
16:33:43
Conan Kudo: we should be as much as possible
<@abologna:matrix.org>
16:33:44
we are, but it's taking time
<@nirik:matrix.scrye.com>
16:33:57
and also some packages are... difficult.
<@rwmj:matrix.org>
16:34:05
if there are specific PRs which are not being merged fast enough, let me know
<@conan_kudo:matrix.org>
16:34:10
likewise
<@abologna:matrix.org>
16:34:27
and as I mentioned earlier a small number of packages will probably need riscv-specific changes that are not acceptable for regular Fedora for a while still
<@conan_kudo:matrix.org>
16:34:41
there are only three packages that we can't reasonably do anything about: shim, grub2, and kernel
<@conan_kudo:matrix.org>
16:34:52
everything else, there's not really an excuse for upstreaming into fedora packaging
<@abologna:matrix.org>
16:35:28
sometimes upstream work is still needed (audit, strace)
<@nhanlon:beeper.com>
16:35:44
I think the idea is to also not go scorched earth on packagers to get rvi into fedora when it's still a moving duck
<@davidlt:matrix.org>
16:35:50
kernel is almost done. We need another MR for kernel-ark and it's done.
<@rwmj:matrix.org>
16:36:42
davidlt: is isaiah helping / do you want me to ask him to help?
<@davidlt:matrix.org>
16:36:59
We cooked RC6+ a few days ago, thus we have the diff we need to upstream to kernel-ark.
<@conan_kudo:matrix.org>
16:37:02
as long as we have no hardware, no builders, and no integration in the main koji, we can wait
<@nhanlon:beeper.com>
16:37:14
thanks for getting this going!
<@conan_kudo:matrix.org>
16:37:22
once two out of three changes, then then we need to be more aggressive
<@davidlt:matrix.org>
16:37:29
Note we will not have Rust working because RISCV maintainer didn't want to allow Rust + GCC combination. Rust is only for Clang built kernels.
<@conan_kudo:matrix.org>
16:37:57
point me to the conversation, and I'll go figure that out
<@conan_kudo:matrix.org>
16:38:18
I talk to R4L enough anyway because of Fedora Asahi work
<@davidlt:matrix.org>
16:38:22
Conan Kudo: In summary we cannot get RH folks to review/merge changes to shim, etc.
<@conan_kudo:matrix.org>
16:38:50
okay, that's Richard Jones and abologna's world :)
<@rwmj:matrix.org>
16:39:02
yeah I'm not going to go near shim
<@conan_kudo:matrix.org>
16:39:03
if Red Hatters are the blocker, those two can fix it
<@davidlt:matrix.org>
16:39:27
Conan Kudo: that's not that easy, otherwise it would have been done quite some time ago.
<@abologna:matrix.org>
16:39:28
I'll bring it up again internally, but I honestly just lost track of it and I thought we were closer to being done than we apparently are
<@conan_kudo:matrix.org>
16:39:54
most of the time it's because it slips out of focus
<@conan_kudo:matrix.org>
16:40:08
I could not count the number of times things got fixed simply by reminding people about it
<@davidlt:matrix.org>
16:40:23
Conan Kudo: the original PR was made in 2021.
<@conan_kudo:matrix.org>
16:40:50
yeah, and, were people regularly knocking doors about it? I doubt it
<@conan_kudo:matrix.org>
16:40:59
in 2021 hardly anyone really prioritized RISC-V in Fedora
<@abologna:matrix.org>
16:41:14
anyway the point is that we need to keep pushing on all fronts but also be realistic about things
<@abologna:matrix.org>
16:41:39
let's ping people, but also accept the fact that we're going to keep the overlay around for a while longer
<@conan_kudo:matrix.org>
16:41:48
push comes to shove, we can ship an alternative shim package for riscv disconnected from the main one
<@conan_kudo:matrix.org>
16:41:51
for just riscv
<@davidlt:matrix.org>
16:42:04
shim is arch specific package 😉
<@conan_kudo:matrix.org>
16:42:16
I know, that makes it easier Twinkle Pardeshi
<@jmontleon:fedora.im>
16:42:17
That's more or less what we have now; it doesn't bare much resemblance
<@conan_kudo:matrix.org>
16:42:20
I know, that makes it easier 😉
<@davidlt:matrix.org>
16:42:23
It's `shim-unsigned-riscv64`
<@abologna:matrix.org>
16:42:46
I would not consider an overlay at all acceptable if we were discussing bringing riscv64 as a primary architecture, but we're not remotely there yet anyway
<@nhanlon:beeper.com>
16:42:47
Agreed abologna -- we're talking about short term stuff now, and I think we've agreed we'll need the overlay for the time being, but that once we're into primary fedora koji, that won't be acceptable.
<@jmontleon:fedora.im>
16:43:05
That's more or less what we have now; it doesn't bear much resemblance
<@nhanlon:beeper.com>
16:43:07
that was to your previous message.. but it works to the one you just sent, so.. :)
<@conan_kudo:matrix.org>
16:43:08
once we're using the main koji hub it won't be acceptable
<@davidlt:matrix.org>
16:43:12
We are not discussing primary architecture today, secondary only.
<@conan_kudo:matrix.org>
16:43:35
sure, but we're still using the main koji hub, so same rules apply
<@conan_kudo:matrix.org>
16:43:51
ppc64le and s390x are secondary arches and aren't allowed to have overlays either
<@davidlt:matrix.org>
16:44:00
We will not be using the same hub.
<@conan_kudo:matrix.org>
16:44:19
okay, now I'm confused
<@davidlt:matrix.org>
16:44:21
We have a new server set that nirik already started to configure some time ago.
<@conan_kudo:matrix.org>
16:44:25
then why do we care about datacenter class hardware?
<@davidlt:matrix.org>
16:44:39
It will be like an old ARM Koji Hub some years ago.
<@nhanlon:beeper.com>
16:44:50
do we think we can make at least a !info about our git-overlay plan?
<@abologna:matrix.org>
16:44:50
I think we're not necessarily discussing short term plans at this point ;)
<@conan_kudo:matrix.org>
16:44:55
the old arm kojihub was a shadow koji
<@conan_kudo:matrix.org>
16:45:02
still didn't allow overlays
<@rwmj:matrix.org>
16:45:09
I've got about 10-15 mins before have to join another meeting
<@abologna:matrix.org>
16:45:15
same
<@jonathanspw:fedora.im>
16:45:15
same
<@davidlt:matrix.org>
16:45:20
Yes, but it was a separate Koji Hub.
<@conan_kudo:matrix.org>
16:45:20
same
<@nhanlon:beeper.com>
16:45:30
I'd like to get to nirik's other points..
<@nhanlon:beeper.com>
16:45:30
> policy on builders, etc.
<@nhanlon:beeper.com>
16:45:30
> what we import or not from existing hub/db/packages
<@nhanlon:beeper.com>
16:45:30
<@rwmj:matrix.org>
16:46:02
Neil Hanlon: everything from fedora.riscv.rocks as a first approximation?
<@davidlt:matrix.org>
16:46:06
Back to overlay. We cannot get rid of it that easily (or in quick time). We need time (weeks to months) to get rid of it. Some things might linger and require deeper involvement to resolve.
<@davidlt:matrix.org>
16:46:26
No, we don't need anything below F40, I think.
<@abologna:matrix.org>
16:46:39
below F41 really
<@rwmj:matrix.org>
16:46:41
oh yes indeed, everything except out of support stuff
<@davidlt:matrix.org>
16:46:53
If we manage to get F41 sooner than later we could forget about F40 too. Depends if space is a concern for nirik
<@rwmj:matrix.org>
16:47:01
I wonder if there are still F<40 packages being consumed because they haven't been rebuilt?
<@abologna:matrix.org>
16:47:19
Richard Jones yes
<@nirik:matrix.scrye.com>
16:47:26
reading up
<@davidlt:matrix.org>
16:47:27
There are some packages that failed to rebuild.
<@abologna:matrix.org>
16:47:47
they are marked with a âš in the tracker
<@nhanlon:beeper.com>
16:47:50
proposed !info A git overlay is needed for some time as it is not feasible to migrate from due to the dynamic nature of the upstream riscv work in many instances. Long term, this overlay will be removed as a prerequisite to becoming part of the main Fedora koji
<@davidlt:matrix.org>
16:47:57
But as long as they are tagged it's not a problem.
<@nirik:matrix.scrye.com>
16:48:13
yes, this plan is a seperate koji instance... we care about datacenter hardware for down the road, not now.
<@nhanlon:beeper.com>
16:48:17
I guess i should add something about pack-it?
<@nhanlon:beeper.com>
16:48:21
I guess i should add something about packit?
<@rwmj:matrix.org>
16:48:23
so they're tagged into f40 even though the package NVR might be .fc19?
<@rwmj:matrix.org>
16:48:28
.fc39 ...
<@davidlt:matrix.org>
16:48:30
Pagure + Special user (see Packit) + a group folks that can create forks there as overlay.
<@davidlt:matrix.org>
16:48:37
Yes.
<@abologna:matrix.org>
16:48:39
hopefully not `.fc19` lol
<@davidlt:matrix.org>
16:48:49
Koji tag has no connected to %dist value.
<@davidlt:matrix.org>
16:48:57
Koji tag has no connection to %dist value.
<@nirik:matrix.scrye.com>
16:49:22
I think we should talk to packit folks and see if this is possible or not... and I'd like to think about it more if it would work
<@nirik:matrix.scrye.com>
16:49:52
so yeah, I'd prefer just 41+, but I guess we can see where we are when we have things ready?
<@davidlt:matrix.org>
16:49:57
nirik: I am not talking about Packit usage at all. Just about the fact that Packit has a user in pagure, and we could have one too.
<@nirik:matrix.scrye.com>
16:50:23
oh, ok, you confused me then.
<@nhanlon:beeper.com>
16:50:33
(me too, but i understand now)
<@davidlt:matrix.org>
16:50:54
Thus our overlay are forks under that user: https://src.fedoraproject.org/user/packit/forks
<@nirik:matrix.scrye.com>
16:51:14
so yeah, you are just proposing a user where all the overlay forks are... .
<@davidlt:matrix.org>
16:51:18
We create a group for this user (riscv) and assign folks that are allowed to touch and create forks.
<@davidlt:matrix.org>
16:51:35
Add this /fork/user/rpms/* pattern in SCM.
<@davidlt:matrix.org>
16:51:46
This way we control who has access to it, and thus avoid anyone making more.
<@nirik:matrix.scrye.com>
16:52:18
I don't know off hand that it would work this way with groups... groups are used for acl for packages where the group is admin...
<@davidlt:matrix.org>
16:52:35
OpenSBI is not usptreamed. This one would be not a fork of course, but we could keep it for now under the same user.
<@davidlt:matrix.org>
16:52:59
So we cannot manage permissions for a group?
<@nirik:matrix.scrye.com>
16:53:24
I don't know off hand. it's not the way we are using them, but there might be something. I would have to investigate.
<@abologna:matrix.org>
16:53:49
if we could make that work, it would be ideal
<@abologna:matrix.org>
16:54:04
it would have the advantage that we could start moving off gitea right now
<@nirik:matrix.scrye.com>
16:54:13
I think forks are a per user thing and not a per group thing...
<@abologna:matrix.org>
16:54:17
that'd make contributing easier
<@rwmj:matrix.org>
16:54:53
< 5mins
<@nirik:matrix.scrye.com>
16:55:03
I'll ponder on it/look more
<@nhanlon:beeper.com>
16:55:03
proposed !action nirik to look into whether we can use groups in the way described above to grant permissions for members of a group to fork rpms.
<@nhanlon:beeper.com>
16:55:03
proposed !info A git overlay is needed for some time as it is not feasible to migrate from due to the dynamic nature of the upstream riscv work in many instances. This overlay will be removed before it can be part of the main Fedora koji, but will take time and nontrivial effort.
<@nhanlon:beeper.com>
16:55:03
<@nhanlon:beeper.com>
16:55:03
and
<@nhanlon:beeper.com>
16:55:03
<@nhanlon:beeper.com>
16:55:03
proposed !info To manage the overlays, one option is to utilize a user and group (riscv)--similar to the `packit` user on src.fp.o. This group would grant SIG members access to fork into the riscv-user namespace--if possible.
<@nhanlon:beeper.com>
16:55:03
<@nhanlon:beeper.com>
16:55:03
and
<@nhanlon:beeper.com>
16:55:03
<@davidlt:matrix.org>
16:55:07
Most if not all overlay changes are by me and Jason Montleon today.
<@nirik:matrix.scrye.com>
16:55:07
!topic Open Floor
<@nirik:matrix.scrye.com>
16:55:32
Neil Hanlon: +1 to those....
<@nirik:matrix.scrye.com>
16:56:19
Anyone have any further thoughts?
<@nirik:matrix.scrye.com>
16:56:55
oh, I have one: in 2 weeks, it's the 26th. Thats part of thanksgiving week in the US and I will not be here. ;)
<@nhanlon:beeper.com>
16:57:05
(hearing no dissent on my proposals...)
<@nhanlon:beeper.com>
16:57:07
!info A git overlay is needed for some time as it is not feasible to migrate from due to the dynamic nature of the upstream riscv work in many instances. This overlay will be removed before it can be part of the main Fedora koji, but will take time and nontrivial effort.
<@nhanlon:beeper.com>
16:57:13
!info To manage the overlays, one option is to utilize a user and group (riscv)--similar to the packit user on src.fp.o. This group would grant SIG members access to fork into the riscv-user namespace--if possible.
<@abologna:matrix.org>
16:57:13
that nirik is really awesome for driving this :)
<@nhanlon:beeper.com>
16:57:22
!action nirik to look into whether we can use groups in the way described above to grant permissions for members of a group to fork rpms.
<@nirik:matrix.scrye.com>
16:57:45
I wish i had more time to be more involved. ;(
<@aeperezt:matrix.org>
16:57:51
Hi! not an expert on risc-v willing to learn more and collaborate in any way I can, so if needed or have a task I can help with let me know.
<@nhanlon:beeper.com>
16:57:55
Good note about Thanksgiving. I guess I wasn't joking about the _other_ other week...
<@nirik:matrix.scrye.com>
16:58:01
So, should we meet on the 26th? or meet instead next week? or push it out to nov?
<@abologna:matrix.org>
16:58:02
maybe we can have the next meeting in 3 weeks then?
<@abologna:matrix.org>
16:58:18
we're getting into holidays territory anyway
<@nhanlon:beeper.com>
16:58:26
Alejandro Perez Thank you for being here! If you haven't joined #riscv:fedoraproject.org , please do!
<@abologna:matrix.org>
16:58:43
so it wouldn't be unreasonable IMO to take it easy and pick up the pace with 2025
<@aeperezt:matrix.org>
16:58:55
Neil Hanlon: will do, thanks
<@nhanlon:beeper.com>
16:59:06
I'm good w/ 3 weeks on December 3rd, personally
<@davidlt:matrix.org>
16:59:13
nirik: when do you want us to move to a new Koji?
<@nirik:matrix.scrye.com>
16:59:15
Fine with me...
<@abologna:matrix.org>
16:59:19
that sounds good to me too
<@nhanlon:beeper.com>
16:59:35
we're only gonna get 2 meetings in December anyways, so
<@nirik:matrix.scrye.com>
16:59:38
ok, thanks everyone for coming, and see you all in #riscv:fedoraproject.org for more discussions!
<@nirik:matrix.scrye.com>
16:59:51
davidlt: not sure. I need to set things up first....
<@nirik:matrix.scrye.com>
17:00:15
ok, we are out of time...
<@nirik:matrix.scrye.com>
17:00:17
!endmeeting