2024-11-12 16:00:03 <@nirik:matrix.scrye.com> !startmeeting riscv-sig
2024-11-12 16:00:05 <@meetbot:fedora.im> Meeting started at 2024-11-12 16:00:03 UTC
2024-11-12 16:00:05 <@meetbot:fedora.im> The Meeting name is 'riscv-sig'
2024-11-12 16:00:08 <@nirik:matrix.scrye.com> !meetingname riscv-sig
2024-11-12 16:00:09 <@meetbot:fedora.im> The Meeting Name is now riscv-sig
2024-11-12 16:00:14 <@nirik:matrix.scrye.com> !info agenda doc: https://hackmd.io/SPrxvhU0Sv2l5Ox7zqg01A
2024-11-12 16:00:16 <@rwmj:matrix.org> agenda: https://hackmd.io/SPrxvhU0Sv2l5Ox7zqg01A
2024-11-12 16:00:19 <@nirik:matrix.scrye.com> !topic introductions
2024-11-12 16:00:24 <@nirik:matrix.scrye.com> hey everyone.
2024-11-12 16:00:32 <@davidlt:matrix.org> Hey 👋
2024-11-12 16:00:33 <@rwmj:matrix.org> hello
2024-11-12 16:00:42 <@abologna:matrix.org> hey there :)
2024-11-12 16:00:59 <@nhanlon:beeper.com> !hi
2024-11-12 16:01:00 <@zodbot:fedora.im> Neil Hanlon (neil) - he / him / his
2024-11-12 16:01:08 <@nhanlon:beeper.com> good morning folks :) glad to have everyone in one place! 
2024-11-12 16:01:14 <@nirik:matrix.scrye.com> I'm here, but will probibly have to step away for a few at the bottom of the hour...
2024-11-12 16:01:18 <@jonathanspw:fedora.im> !hi
2024-11-12 16:01:19 <@zodbot:fedora.im> Jonathan Wright (jonathanspw)
2024-11-12 16:01:42 <@davidlt:matrix.org> !hi
2024-11-12 16:01:44 <@zodbot:fedora.im> David Abdurachmanov (davidlt)
2024-11-12 16:01:55 <@abologna:matrix.org> I've never attended one of these text-based SIG meetings so please bear with me :)
2024-11-12 16:02:13 <@nirik:matrix.scrye.com> Perhaps we want to have everyone give a quick oneliner on who they are...
2024-11-12 16:02:31 <@nirik:matrix.scrye.com> I'm Kevin Fenzi, I work at Red Hat on Fedora infrastructure and releng stuff.
2024-11-12 16:02:39 <@wmat:matrix.org> greetings, long time lurker, first time attendee. 
2024-11-12 16:02:50 <@rwmj:matrix.org> Richard Jones, been packaging for Fedora for a good while, and have worked on RISC-V packaging
2024-11-12 16:03:19 <@jonathanspw:fedora.im> 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.
2024-11-12 16:04:00 <@abologna:matrix.org> 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/
2024-11-12 16:04:29 <@jefro:matrix.org> HI all - Jefro here, I work in the Red Hat OSPO, centos board, and RISC-V board
2024-11-12 16:04:31 <@jmontleon:fedora.im> Jason Montleon, work at Red Hat on Migration Engineering team and Fedora packager for a handful of packages.
2024-11-12 16:04:37 <@davidlt:matrix.org> 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.
2024-11-12 16:04:50 <@rwmj:matrix.org> Jason, what's "migration engineering"?
2024-11-12 16:05:16 <@khanicov:matrix.org> Hello, Kristina Hanicova, I work part-time at RH and have Andrea as my buddy, working on the same thing rn
2024-11-12 16:05:36 <@nhanlon:beeper.com> 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).
2024-11-12 16:05:36 <@nhanlon:beeper.com> 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). 
2024-11-12 16:05:36 <@nhanlon:beeper.com> 
2024-11-12 16:06:19 <@nhanlon:beeper.com> 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).
2024-11-12 16:06:19 <@nhanlon:beeper.com> 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). 
2024-11-12 16:06:19 <@nhanlon:beeper.com> 
2024-11-12 16:07:08 <@conan_kudo:matrix.org> !hi
2024-11-12 16:07:09 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2024-11-12 16:07:11 <@jmontleon:fedora.im> 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.
2024-11-12 16:07:16 <@nirik:matrix.scrye.com> 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...
2024-11-12 16:07:22 <@rwmj:matrix.org> Neil Hanlon: are you intending to change the arch/ABI baseline for rocky 10?
2024-11-12 16:07:35 <@conan_kudo:matrix.org> Hey, I'm Neal. I do stuff. I'd like Fedora KDE to be the first to support RISC-V.
2024-11-12 16:07:50 <@nhanlon:beeper.com> negative; it's an AltArch SIG effort
2024-11-12 16:08:16 <@nhanlon:beeper.com> (if c10s were to change... that's a different story ;) )
2024-11-12 16:08:21 <@abologna:matrix.org> nirik: I vote for every other week to reduce the meeting fatigue
2024-11-12 16:08:27 <@conan_kudo:matrix.org> My "day job" is as a consultant for Velocity Limitless. :)
2024-11-12 16:08:29 <@davidlt:matrix.org> 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.
2024-11-12 16:08:30 <@jonathanspw:fedora.im> +1
2024-11-12 16:08:32 <@jefro:matrix.org> nirik: I vote for every other week
2024-11-12 16:08:35 <@rwmj:matrix.org> yes every other week
2024-11-12 16:08:37 <@nhanlon:beeper.com> I am good with biweekly.
2024-11-12 16:08:38 <@abologna:matrix.org> but yes to making it a regular thing
2024-11-12 16:08:47 <@wmat:matrix.org> every other week vote as well
2024-11-12 16:08:58 <@nirik:matrix.scrye.com> ok, every other week seems to win. ;)
2024-11-12 16:09:13 <@conan_kudo:matrix.org> Whatever the cadence, it needs to be regular.
2024-11-12 16:09:16 <@nhanlon:beeper.com> but I wanted the _other_ every other week...
2024-11-12 16:09:40 <@nirik:matrix.scrye.com> !topic Current Status
2024-11-12 16:10:04 <@nirik:matrix.scrye.com> So, where are we now? perhaps davidlt could give a quick summary?
2024-11-12 16:11:33 <@davidlt:matrix.org> 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.
2024-11-12 16:12:30 <@nirik:matrix.scrye.com> !link https://abologna.gitlab.io/fedora-riscv-tracker/
2024-11-12 16:12:31 <@nirik:matrix.scrye.com> too
2024-11-12 16:13:15 <@nirik:matrix.scrye.com> ok, anything more we want to discuss with current status/setup? or move on to next plans?
2024-11-12 16:13:30 <@davidlt:matrix.org> I think, future priorities will depend on how/when we plan to boot the new infra.
2024-11-12 16:14:09 <@abologna:matrix.org> I'll just point out that some of the packages listed in the tracker are probably relatively low-hanging fruits
2024-11-12 16:14:22 <@abologna:matrix.org> and they just need someone to take the existing patches and upstream them
2024-11-12 16:14:26 <@abologna:matrix.org> me and Kristina are working on that
2024-11-12 16:14:54 <@davidlt:matrix.org> Some of the PRs/MRs are made, but had no review or were rejected by the maintainer too.
2024-11-12 16:14:55 <@abologna:matrix.org> however, a small number of them require potentially significant upstream work
2024-11-12 16:15:35 <@abologna:matrix.org> 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
2024-11-12 16:15:43 <@davidlt:matrix.org> Like shim or/and GRUB2 being a multi-year saga by now.
2024-11-12 16:15:59 <@nirik:matrix.scrye.com> or audit or pesign...
2024-11-12 16:16:15 <@davidlt:matrix.org> True, there will more on this list (e.g. libffi).
2024-11-12 16:16:39 <@abologna:matrix.org> 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
2024-11-12 16:17:20 <@rwmj:matrix.org> libffi is unfortunately a bit of a lost cause, we may need to just take the patch downstream (in the overlay git, sigh)
2024-11-12 16:18:04 <@rwmj:matrix.org> the alternative is to raise the dispute to fesco level, but I don't really want to go there
2024-11-12 16:18:22 <@jonathanspw:fedora.im> grpc needs some updating in fedora/rawhide to fix its issues.  it's quite behind in fedora.
2024-11-12 16:18:48 <@rwmj:matrix.org> Jonathan Wright: is there a fedora PR for that? I can do this kind of thing
2024-11-12 16:18:50 <@jonathanspw:fedora.im> Looks like Neil Hanlon owns the package
2024-11-12 16:18:53 <@davidlt:matrix.org> 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.
2024-11-12 16:19:15 <@jonathanspw:fedora.im> 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
2024-11-12 16:19:26 <@nhanlon:beeper.com> 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
2024-11-12 16:19:32 <@jonathanspw:fedora.im> but they're int he master branch and once grpc is updated we could do a PR with a patch for the risc issues.
2024-11-12 16:19:35 <@davidlt:matrix.org> Yes, we discussed grpc and something else related to it being quite outdated and causing segfaults on riscv64.
2024-11-12 16:19:50 <@jonathanspw:fedora.im> yeah, can confirm the patches in master branch upstream fix it
2024-11-12 16:19:53 <@jonathanspw:fedora.im> yeah, can confirm the patches in master branch upstream fix grpc
2024-11-12 16:19:58 <@abologna:matrix.org> we need to keep pushing on the upstream side where necessary
2024-11-12 16:20:50 <@davidlt:matrix.org> 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).
2024-11-12 16:21:03 <@abologna:matrix.org> hopefully most of it should be in the past though? I expect that only a handful of packages really still need upstream work
2024-11-12 16:21:06 <@davidlt:matrix.org> Not directly a riscv64 thing, but affects us the most probably.
2024-11-12 16:21:11 <@nirik:matrix.scrye.com> the protobuf saga is a long and painfull one. ;(
2024-11-12 16:21:49 <@nirik:matrix.scrye.com> Anyhow, shall we move on to short term plans?
2024-11-12 16:21:55 <@davidlt:matrix.org> Sure.
2024-11-12 16:22:23 <@nirik:matrix.scrye.com> !topic Short term plans
2024-11-12 16:23:36 <@nirik:matrix.scrye.com> 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.
2024-11-12 16:23:59 <@nirik:matrix.scrye.com> 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.
2024-11-12 16:24:11 <@nirik:matrix.scrye.com> But we need to determine some things about that
2024-11-12 16:24:22 <@davidlt:matrix.org> Correct. There are no hardware available that would meet Red Hat requirements for deployment (today).
2024-11-12 16:24:38 <@nirik:matrix.scrye.com> The git overlay and how it would work in this setup
2024-11-12 16:24:49 <@jefro:matrix.org> I can offer no details, but I can hint that hardware should be available over the next few months
2024-11-12 16:25:05 <@nirik:matrix.scrye.com> what we import or not from existing hub/db/packages
2024-11-12 16:25:13 <@nirik:matrix.scrye.com> policy on builders, etc.
2024-11-12 16:25:27 <@davidlt:matrix.org> 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. 
2024-11-12 16:26:02 <@nirik:matrix.scrye.com> thats an interesting idea...
2024-11-12 16:26:23 <@abologna:matrix.org> could we perhaps host the overlay as branches on forks in pagure? keep things as close as possible to the end goal setup
2024-11-12 16:26:36 <@davidlt:matrix.org> https://src.fedoraproject.org/user/packit/groups
2024-11-12 16:26:46 <@nirik:matrix.scrye.com> 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
2024-11-12 16:27:14 <@davidlt:matrix.org> This way we don't need to user personal forks and things are under a single user (with multiple folks having access to it).
2024-11-12 16:28:02 <@abologna:matrix.org> the idea sounds good when you describe it like that, but I'm concerned that it involves adding another software component into the mix
2024-11-12 16:28:06 <@davidlt:matrix.org> Yeah, you would need to add a line for SCM to allow specific /fork/<our_user>/* pattern (or something).
2024-11-12 16:28:10 <@abologna:matrix.org> doesn't packit have its own processes and stuff?
2024-11-12 16:28:12 <@conan_kudo:matrix.org> please don't do any of that
2024-11-12 16:28:21 <@conan_kudo:matrix.org> this will create a couple of problems
2024-11-12 16:28:21 <@timaeos:matrix.nexaeos.io> just to clarify, is this waiting on RVA23 profile hardware?
2024-11-12 16:28:32 <@davidlt:matrix.org> I am talking about Packit user in Pagure, not anything else.
2024-11-12 16:28:34 <@conan_kudo:matrix.org> first, it's a nightmare for tracking what is going on and what's getting built
2024-11-12 16:28:38 <@jonathanspw:fedora.im> I think it's more or less just reasonably powerful, rack-mountable hardware
2024-11-12 16:28:57 <@jonathanspw:fedora.im> tenstorrent has some big stuff in the works from what I hear but not expected until like q3/4 2025
2024-11-12 16:28:58 <@nirik:matrix.scrye.com> timaeos: no, it's waiting on hardware that is rack mountable, has mgmt interfaces, etc... ie, datacenter quality. oh, and is fast enough.
2024-11-12 16:29:05 <@abologna:matrix.org> with remote power control and console access
2024-11-12 16:29:06 <@conan_kudo:matrix.org> second, if everything is running through packit without user interaction, then you risk appearing inactive and your packages orphaned
2024-11-12 16:29:24 <@conan_kudo:matrix.org> we've already had a couple of packagers go the full packit route and lose their privileges and have all their packages orphaned
2024-11-12 16:29:35 <@nirik:matrix.scrye.com> uh, that seems weird.
2024-11-12 16:29:47 <@conan_kudo:matrix.org> that's how linux-system-roles got orphaned over the summer :)
2024-11-12 16:30:02 <@davidlt:matrix.org> 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.
2024-11-12 16:30:08 <@nirik:matrix.scrye.com> the inactive process files a ticket for you... you have to not answer that after many months of reminders.
2024-11-12 16:30:10 <@abologna:matrix.org> does pagure support creating groups for group-maintained packages?
2024-11-12 16:30:20 <@conan_kudo:matrix.org> yes
2024-11-12 16:30:21 <@nirik:matrix.scrye.com> yes
2024-11-12 16:30:23 <@conan_kudo:matrix.org> that's how sigs work
2024-11-12 16:30:28 <@abologna:matrix.org> so can we just do that? :)
2024-11-12 16:30:43 <@davidlt:matrix.org> Exactly, we can have our own Packit-like user and assign a group (riscv) to it.
2024-11-12 16:30:46 <@jonathanspw:fedora.im> 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.
2024-11-12 16:30:55 <@nirik:matrix.scrye.com> I don't think so... because we are not maintaining those packages as a rsicv-sig...
2024-11-12 16:30:56 <@conan_kudo:matrix.org> and indeed they did that since they completely ignored fedora while packit churned away
2024-11-12 16:31:29 <@abologna:matrix.org> mmm
2024-11-12 16:31:54 <@davidlt:matrix.org> 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.
2024-11-12 16:32:09 <@jonathanspw:fedora.im> I know it's slow, just throwing out that it has bmc
2024-11-12 16:32:24 <@abologna:matrix.org> 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?
2024-11-12 16:32:31 <@conan_kudo:matrix.org> we're going to have to accept that we're not getting fast or good hardware
2024-11-12 16:32:44 <@conan_kudo:matrix.org> especially not datacenter class hardware, since none of it exists
2024-11-12 16:32:45 <@davidlt:matrix.org> Jonathan Wright: not that kind of BMC 😄 It's non-standard FreeRTOS thing, which doesn't work as a standard datacenter thing.
2024-11-12 16:32:55 <@nirik:matrix.scrye.com> 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.
2024-11-12 16:32:57 <@jonathanspw:fedora.im> aha.  i haven't played with it yet :p
2024-11-12 16:33:30 <@conan_kudo:matrix.org> why aren't we merging things into fedora packages?
2024-11-12 16:33:35 <@davidlt:matrix.org> nirik: https://src.fedoraproject.org/user/packit/groups we do forks under our account.
2024-11-12 16:33:39 <@nirik:matrix.scrye.com> Definitely we want to try and make the overlay as small as possible.
2024-11-12 16:33:43 <@rwmj:matrix.org> Conan Kudo: we should be as much as possible
2024-11-12 16:33:44 <@abologna:matrix.org> we are, but it's taking time
2024-11-12 16:33:57 <@nirik:matrix.scrye.com> and also some packages are... difficult.
2024-11-12 16:34:05 <@rwmj:matrix.org> if there are specific PRs which are not being merged fast enough, let me know
2024-11-12 16:34:10 <@conan_kudo:matrix.org> likewise
2024-11-12 16:34:27 <@abologna:matrix.org> 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
2024-11-12 16:34:41 <@conan_kudo:matrix.org> there are only three packages that we can't reasonably do anything about: shim, grub2, and kernel
2024-11-12 16:34:52 <@conan_kudo:matrix.org> everything else, there's not really an excuse for upstreaming into fedora packaging
2024-11-12 16:35:28 <@abologna:matrix.org> sometimes upstream work is still needed (audit, strace)
2024-11-12 16:35:44 <@nhanlon:beeper.com> 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
2024-11-12 16:35:50 <@davidlt:matrix.org> kernel is almost done. We need another MR for kernel-ark and it's done.
2024-11-12 16:36:42 <@rwmj:matrix.org> davidlt: is isaiah helping / do you want me to ask him to help?
2024-11-12 16:36:59 <@davidlt:matrix.org> We cooked RC6+ a few days ago, thus we have the diff we need to upstream to kernel-ark.
2024-11-12 16:37:02 <@conan_kudo:matrix.org> as long as we have no hardware, no builders, and no integration in the main koji, we can wait
2024-11-12 16:37:14 <@nhanlon:beeper.com> thanks for getting this going!
2024-11-12 16:37:22 <@conan_kudo:matrix.org> once two out of three changes, then then we need to be more aggressive
2024-11-12 16:37:29 <@davidlt:matrix.org> 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.
2024-11-12 16:37:57 <@conan_kudo:matrix.org> point me to the conversation, and I'll go figure that out
2024-11-12 16:38:18 <@conan_kudo:matrix.org> I talk to R4L enough anyway because of Fedora Asahi work
2024-11-12 16:38:22 <@davidlt:matrix.org> Conan Kudo: In summary we cannot get RH folks to review/merge changes to shim, etc.
2024-11-12 16:38:50 <@conan_kudo:matrix.org> okay, that's Richard Jones and abologna's world :)
2024-11-12 16:39:02 <@rwmj:matrix.org> yeah I'm not going to go near shim
2024-11-12 16:39:03 <@conan_kudo:matrix.org> if Red Hatters are the blocker, those two can fix it
2024-11-12 16:39:27 <@davidlt:matrix.org> Conan Kudo: that's not that easy, otherwise it would have been done quite some time ago.
2024-11-12 16:39:28 <@abologna:matrix.org> 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
2024-11-12 16:39:54 <@conan_kudo:matrix.org> most of the time it's because it slips out of focus
2024-11-12 16:40:08 <@conan_kudo:matrix.org> I could not count the number of times things got fixed simply by reminding people about it
2024-11-12 16:40:23 <@davidlt:matrix.org> Conan Kudo: the original PR was made in 2021.
2024-11-12 16:40:50 <@conan_kudo:matrix.org> yeah, and, were people regularly knocking doors about it? I doubt it
2024-11-12 16:40:59 <@conan_kudo:matrix.org> in 2021 hardly anyone really prioritized RISC-V in Fedora
2024-11-12 16:41:14 <@abologna:matrix.org> anyway the point is that we need to keep pushing on all fronts but also be realistic about things
2024-11-12 16:41:39 <@abologna:matrix.org> let's ping people, but also accept the fact that we're going to keep the overlay around for a while longer
2024-11-12 16:41:48 <@conan_kudo:matrix.org> push comes to shove, we can ship an alternative shim package for riscv disconnected from the main one
2024-11-12 16:41:51 <@conan_kudo:matrix.org> for just riscv
2024-11-12 16:42:04 <@davidlt:matrix.org> shim is arch specific package 😉
2024-11-12 16:42:16 <@conan_kudo:matrix.org> I know, that makes it easier Twinkle Pardeshi 
2024-11-12 16:42:17 <@jmontleon:fedora.im> That's more or less what we have now; it doesn't bare much resemblance
2024-11-12 16:42:20 <@conan_kudo:matrix.org> I know, that makes it easier 😉
2024-11-12 16:42:23 <@davidlt:matrix.org> It's `shim-unsigned-riscv64`
2024-11-12 16:42:46 <@abologna:matrix.org> 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
2024-11-12 16:42:47 <@nhanlon:beeper.com> 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.
2024-11-12 16:43:05 <@jmontleon:fedora.im> That's more or less what we have now; it doesn't bear much resemblance
2024-11-12 16:43:07 <@nhanlon:beeper.com> that was to your previous message.. but it works to the one you just sent, so.. :) 
2024-11-12 16:43:08 <@conan_kudo:matrix.org> once we're using the main koji hub it won't be acceptable
2024-11-12 16:43:12 <@davidlt:matrix.org> We are not discussing primary architecture today, secondary only.
2024-11-12 16:43:35 <@conan_kudo:matrix.org> sure, but we're still using the main koji hub, so same rules apply
2024-11-12 16:43:51 <@conan_kudo:matrix.org> ppc64le and s390x are secondary arches and aren't allowed to have overlays either
2024-11-12 16:44:00 <@davidlt:matrix.org> We will not be using the same hub.
2024-11-12 16:44:19 <@conan_kudo:matrix.org> okay, now I'm confused
2024-11-12 16:44:21 <@davidlt:matrix.org> We have a new server set that nirik already started to configure some time ago.
2024-11-12 16:44:25 <@conan_kudo:matrix.org> then why do we care about datacenter class hardware?
2024-11-12 16:44:39 <@davidlt:matrix.org> It will be like an old ARM Koji Hub some years ago.
2024-11-12 16:44:50 <@nhanlon:beeper.com> do we think we can make at least a !info about our git-overlay plan?
2024-11-12 16:44:50 <@abologna:matrix.org> I think we're not necessarily discussing short term plans at this point ;)
2024-11-12 16:44:55 <@conan_kudo:matrix.org> the old arm kojihub was a shadow koji
2024-11-12 16:45:02 <@conan_kudo:matrix.org> still didn't allow overlays
2024-11-12 16:45:09 <@rwmj:matrix.org> I've got about 10-15 mins before have to join another meeting
2024-11-12 16:45:15 <@abologna:matrix.org> same
2024-11-12 16:45:15 <@jonathanspw:fedora.im> same
2024-11-12 16:45:20 <@davidlt:matrix.org> Yes, but it was a separate Koji Hub.
2024-11-12 16:45:20 <@conan_kudo:matrix.org> same
2024-11-12 16:45:30 <@nhanlon:beeper.com> I'd like to get to nirik's other points.. 
2024-11-12 16:45:30 <@nhanlon:beeper.com> > policy on builders, etc.
2024-11-12 16:45:30 <@nhanlon:beeper.com> > what we import or not from existing hub/db/packages
2024-11-12 16:45:30 <@nhanlon:beeper.com> 
2024-11-12 16:46:02 <@rwmj:matrix.org> Neil Hanlon: everything from fedora.riscv.rocks as a first approximation?
2024-11-12 16:46:06 <@davidlt:matrix.org> 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.
2024-11-12 16:46:26 <@davidlt:matrix.org> No, we don't need anything below F40, I think.
2024-11-12 16:46:39 <@abologna:matrix.org> below F41 really
2024-11-12 16:46:41 <@rwmj:matrix.org> oh yes indeed, everything except out of support stuff
2024-11-12 16:46:53 <@davidlt:matrix.org> If we manage to get F41 sooner than later we could forget about F40 too. Depends if space is a concern for nirik 
2024-11-12 16:47:01 <@rwmj:matrix.org> I wonder if there are still F<40 packages being consumed because they haven't been rebuilt?
2024-11-12 16:47:19 <@abologna:matrix.org> Richard Jones yes
2024-11-12 16:47:26 <@nirik:matrix.scrye.com> reading up
2024-11-12 16:47:27 <@davidlt:matrix.org> There are some packages that failed to rebuild.
2024-11-12 16:47:47 <@abologna:matrix.org> they are marked with a ⚠ in the tracker
2024-11-12 16:47:50 <@nhanlon:beeper.com> 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
2024-11-12 16:47:57 <@davidlt:matrix.org> But as long as they are tagged it's not a problem.
2024-11-12 16:48:13 <@nirik:matrix.scrye.com> yes, this plan is a seperate koji instance... we care about datacenter hardware for down the road, not now.
2024-11-12 16:48:17 <@nhanlon:beeper.com> I guess i should add something about pack-it? 
2024-11-12 16:48:21 <@nhanlon:beeper.com> I guess i should add something about packit? 
2024-11-12 16:48:23 <@rwmj:matrix.org> so they're tagged into f40 even though the package NVR might be .fc19?
2024-11-12 16:48:28 <@rwmj:matrix.org> .fc39 ...
2024-11-12 16:48:30 <@davidlt:matrix.org> Pagure + Special user (see Packit) + a group folks that can create forks there as overlay.
2024-11-12 16:48:37 <@davidlt:matrix.org> Yes.
2024-11-12 16:48:39 <@abologna:matrix.org> hopefully not `.fc19` lol
2024-11-12 16:48:49 <@davidlt:matrix.org> Koji tag has no connected to %dist value.
2024-11-12 16:48:57 <@davidlt:matrix.org> Koji tag has no connection to %dist value.
2024-11-12 16:49:22 <@nirik:matrix.scrye.com> 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
2024-11-12 16:49:52 <@nirik:matrix.scrye.com> so yeah, I'd prefer just 41+, but I guess we can see where we are when we have things ready?
2024-11-12 16:49:57 <@davidlt:matrix.org> 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.
2024-11-12 16:50:23 <@nirik:matrix.scrye.com> oh, ok, you confused me then.
2024-11-12 16:50:33 <@nhanlon:beeper.com> (me too, but i understand now)
2024-11-12 16:50:54 <@davidlt:matrix.org> Thus our overlay are forks under that user: https://src.fedoraproject.org/user/packit/forks
2024-11-12 16:51:14 <@nirik:matrix.scrye.com> so yeah, you are just proposing a user where all the overlay forks are... .
2024-11-12 16:51:18 <@davidlt:matrix.org> We create a group for this user (riscv) and assign folks that are allowed to touch and create forks.
2024-11-12 16:51:35 <@davidlt:matrix.org> Add this /fork/user/rpms/* pattern in SCM.
2024-11-12 16:51:46 <@davidlt:matrix.org> This way we control who has access to it, and thus avoid anyone making more.
2024-11-12 16:52:18 <@nirik:matrix.scrye.com> 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...
2024-11-12 16:52:35 <@davidlt:matrix.org> OpenSBI is not usptreamed. This one would be not a fork of course, but we could keep it for now under the same user.
2024-11-12 16:52:59 <@davidlt:matrix.org> So we cannot manage permissions for a group?
2024-11-12 16:53:24 <@nirik:matrix.scrye.com> 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.
2024-11-12 16:53:49 <@abologna:matrix.org> if we could make that work, it would be ideal
2024-11-12 16:54:04 <@abologna:matrix.org> it would have the advantage that we could start moving off gitea right now
2024-11-12 16:54:13 <@nirik:matrix.scrye.com> I think forks are a per user thing and not a per group thing...
2024-11-12 16:54:17 <@abologna:matrix.org> that'd make contributing easier
2024-11-12 16:54:53 <@rwmj:matrix.org> < 5mins
2024-11-12 16:55:03 <@nirik:matrix.scrye.com> I'll ponder on it/look more
2024-11-12 16:55:03 <@nhanlon:beeper.com> 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.
2024-11-12 16:55:03 <@nhanlon:beeper.com> 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.
2024-11-12 16:55:03 <@nhanlon:beeper.com> 
2024-11-12 16:55:03 <@nhanlon:beeper.com> and
2024-11-12 16:55:03 <@nhanlon:beeper.com> 
2024-11-12 16:55:03 <@nhanlon:beeper.com> 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.
2024-11-12 16:55:03 <@nhanlon:beeper.com> 
2024-11-12 16:55:03 <@nhanlon:beeper.com> and
2024-11-12 16:55:03 <@nhanlon:beeper.com> 
2024-11-12 16:55:07 <@davidlt:matrix.org> Most if not all overlay changes are by me and Jason Montleon today.
2024-11-12 16:55:07 <@nirik:matrix.scrye.com> !topic Open Floor
2024-11-12 16:55:32 <@nirik:matrix.scrye.com> Neil Hanlon: +1 to those....
2024-11-12 16:56:19 <@nirik:matrix.scrye.com> Anyone have any further thoughts?
2024-11-12 16:56:55 <@nirik:matrix.scrye.com> 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. ;)
2024-11-12 16:57:05 <@nhanlon:beeper.com> (hearing no dissent on my proposals...)
2024-11-12 16:57:07 <@nhanlon:beeper.com> !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.
2024-11-12 16:57:13 <@nhanlon:beeper.com> !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.
2024-11-12 16:57:13 <@abologna:matrix.org> that nirik is really awesome for driving this :)
2024-11-12 16:57:22 <@nhanlon:beeper.com> !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.
2024-11-12 16:57:45 <@nirik:matrix.scrye.com> I wish i had more time to be more involved. ;(
2024-11-12 16:57:51 <@aeperezt:matrix.org> 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.
2024-11-12 16:57:55 <@nhanlon:beeper.com> Good note about Thanksgiving. I guess I wasn't joking about the _other_ other week...
2024-11-12 16:58:01 <@nirik:matrix.scrye.com> So, should we meet on the 26th? or meet instead next week? or push it out to nov?
2024-11-12 16:58:02 <@abologna:matrix.org> maybe we can have the next meeting in 3 weeks then?
2024-11-12 16:58:18 <@abologna:matrix.org> we're getting into holidays territory anyway
2024-11-12 16:58:26 <@nhanlon:beeper.com> Alejandro Perez Thank you for being here! If you haven't joined #riscv:fedoraproject.org , please do! 
2024-11-12 16:58:43 <@abologna:matrix.org> so it wouldn't be unreasonable IMO to take it easy and pick up the pace with 2025
2024-11-12 16:58:55 <@aeperezt:matrix.org> Neil Hanlon: will do, thanks
2024-11-12 16:59:06 <@nhanlon:beeper.com> I'm good w/ 3 weeks on December 3rd, personally
2024-11-12 16:59:13 <@davidlt:matrix.org> nirik: when do you want us to move to a new Koji?
2024-11-12 16:59:15 <@nirik:matrix.scrye.com> Fine with me...
2024-11-12 16:59:19 <@abologna:matrix.org> that sounds good to me too
2024-11-12 16:59:35 <@nhanlon:beeper.com> we're only gonna get 2 meetings in December anyways, so
2024-11-12 16:59:38 <@nirik:matrix.scrye.com> ok, thanks everyone for coming, and see you all in #riscv:fedoraproject.org for more discussions!
2024-11-12 16:59:51 <@nirik:matrix.scrye.com> davidlt: not sure. I need to set things up first....
2024-11-12 17:00:15 <@nirik:matrix.scrye.com> ok, we are out of time...
2024-11-12 17:00:17 <@nirik:matrix.scrye.com> !endmeeting