2024-12-04 18:00:59 <@carlwgeorge:matrix.org> !startmeeting EPEL (2024-12-04)
2024-12-04 18:01:02 <@meetbot:fedora.im> Meeting started at 2024-12-04 18:00:59 UTC
2024-12-04 18:01:02 <@meetbot:fedora.im> The Meeting name is 'EPEL (2024-12-04)'
2024-12-04 18:01:10 <@rcallicotte:fedora.im> !hi
2024-12-04 18:01:15 <@zodbot:fedora.im> Robby Callicotte (rcallicotte) - he / him / his
2024-12-04 18:01:20 <@dherrera:fedora.im> !hi
2024-12-04 18:01:21 <@jonathanspw:fedora.im> !hi
2024-12-04 18:01:22 <@zodbot:fedora.im> Diego Herrera (dherrera) - he / him / his
2024-12-04 18:01:23 <@zodbot:fedora.im> Jonathan Wright (jonathanspw)
2024-12-04 18:01:29 <@conan_kudo:matrix.org> !hi
2024-12-04 18:01:32 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2024-12-04 18:01:48 <@nhanlon:beeper.com> !hi
2024-12-04 18:01:49 <@zodbot:fedora.im> Neil Hanlon (neil) - he / him / his
2024-12-04 18:01:51 <@carlwgeorge:matrix.org> !topic howdy
2024-12-04 18:02:11 <@carlwgeorge:matrix.org> welcome everybody
2024-12-04 18:04:08 <@carlwgeorge:matrix.org> !meetingname EPEL Steering Committee
2024-12-04 18:04:09 <@meetbot:fedora.im> The Meeting Name is now EPEL Steering Committee
2024-12-04 18:04:23 <@carlwgeorge:matrix.org> !topic EPEL Issues
2024-12-04 18:04:45 <@carlwgeorge:matrix.org> !link https://pagure.io/epel/issues?tags=meeting&status=Open
2024-12-04 18:05:35 <@carlwgeorge:matrix.org> our only open issue is the epel 10 launch, so unless anyone has other open issues they forgot to tag for the meeting, we can move on to that topic
2024-12-04 18:06:22 <@carlwgeorge:matrix.org> nothing jumps out at me from the overall issue list, so moving on
2024-12-04 18:06:48 <@carlwgeorge:matrix.org> !topic EPEL 10
2024-12-04 18:07:04 <@carlwgeorge:matrix.org> !epel 300
2024-12-04 18:07:07 <@zodbot:fedora.im> ● **Assignee:** carlwgeorge
2024-12-04 18:07:07 <@zodbot:fedora.im> ● **Last Updated:** 13 hours ago
2024-12-04 18:07:07 <@zodbot:fedora.im> ● **Opened:** a month ago by carlwgeorge
2024-12-04 18:07:07 <@zodbot:fedora.im> **epel #300** (https://pagure.io/epel/issue/300):**EPEL 10 launch**
2024-12-04 18:07:07 <@zodbot:fedora.im> 
2024-12-04 18:07:19 <@jrichardson:matrix.org> !hi
2024-12-04 18:07:24 <@zodbot:fedora.im> James Richardson (jrichardson)
2024-12-04 18:07:30 <@jrichardson:matrix.org> Sorry I'm late
2024-12-04 18:07:50 <@carlwgeorge:matrix.org> i added a new page to the docs to cover all the active branches, including how epel 10 branches will work
2024-12-04 18:07:57 <@carlwgeorge:matrix.org> !link https://docs.fedoraproject.org/en-US/epel/branches/
2024-12-04 18:08:45 <@carlwgeorge:matrix.org> we also have c10 instructions on the getting started page now, thanks to James Richardson 
2024-12-04 18:08:48 <@carlwgeorge:matrix.org> !link https://docs.fedoraproject.org/en-US/epel/getting-started/#_el10
2024-12-04 18:09:35 <@carlwgeorge:matrix.org> the last item from our checklist is the actual announcement, which i've been in the process of writing and plan to wrap up today
2024-12-04 18:11:31 <@rcallicotte:fedora.im> sweet
2024-12-04 18:11:40 <@carlwgeorge:matrix.org> i'd still like to do the announcement on the same day as centos 10, but when i met to talk with shaun, brian, adam, and troy on monday, they weren't ready yet.  the main blocker is the new website, and they're also trying to get secureboot working before launch.  they may defer the later and launch without it, but everyone feels getting the new website out before launch is a hard blocker.
2024-12-04 18:12:15 <@nirik:matrix.scrye.com> morning.
2024-12-04 18:12:23 <@carlwgeorge:matrix.org> if anyone wants to get involved in getting that across the finish line, check out the conversations in #centos-docs:fedora.im and #centos-promo:fedora.im 
2024-12-04 18:12:26 <@nirik:matrix.scrye.com> somehow I still had this as an hour later.
2024-12-04 18:13:36 <@carlwgeorge:matrix.org> the other epel10 thing going on is releasever_minor not being set, which i brought up last meeting
2024-12-04 18:13:48 <@carlwgeorge:matrix.org> !link https://issues.redhat.com/browse/RHEL-68034
2024-12-04 18:15:16 <@carlwgeorge:matrix.org> there was a build that implemented the proposed fix, but it got reverted once someone complained about their script needing to change to accomodate it.  discussion is still ongoing, and i'm hopeful.  we've got a bit of time before it become a real problem.
2024-12-04 18:16:27 <@carlwgeorge:matrix.org> i think that's all i had for epel10 stuff, anyone have any questions before we move on to the next topic?
2024-12-04 18:18:18 <@carlwgeorge:matrix.org> guess it's gonna be a quick meeting today
2024-12-04 18:18:27 <@dherrera:fedora.im> yup
2024-12-04 18:19:03 <@carlwgeorge:matrix.org> !topic Old Business
2024-12-04 18:19:29 <@carlwgeorge:matrix.org> i had one thing to bring up here, let me find the link
2024-12-04 18:20:00 <@carlwgeorge:matrix.org> !link https://issues.redhat.com/browse/OSCI-3778
2024-12-04 18:21:01 <@carlwgeorge:matrix.org> no new comments on this issue, but as a result of an internal email thread this is getting attention and the team involved started setting various agile fields, which i think is an indication they are formally planning work for this
2024-12-04 18:22:09 <@carlwgeorge:matrix.org> based on that email thread i don't expect the rhel in public testing farm problem is solved yet, and the initial implementation will only be epel10 installability tests against centos10, but it will be a start and better than nothing (which is what we have currently)
2024-12-04 18:23:03 <@carlwgeorge:matrix.org> in the meantime, i've just gotten into a habit of running repoclosure on the testing repo every could of days to try to catch what i can manually
2024-12-04 18:23:30 <@carlwgeorge:matrix.org> `dnf -q --enablerepo epel,epel-testing repoclosure --newest --check epel-testing`
2024-12-04 18:23:53 <@nirik:matrix.scrye.com> note that composes should run one each compose too.
2024-12-04 18:24:08 <@carlwgeorge:matrix.org> is that logged somewhere that is easy to get to?
2024-12-04 18:24:43 <@nirik:matrix.scrye.com> hum, looking, perhaps I am wrong
2024-12-04 18:25:00 <@carlwgeorge:matrix.org> https://kojipkgs.fedoraproject.org/compose/updates/epel10.0-testing/logs/x86_64/repoclosure-Everything.x86_64.log
2024-12-04 18:25:19 <@carlwgeorge:matrix.org> seems to not account for deps in the main os, which makes it fairly useless
2024-12-04 18:25:20 <@nirik:matrix.scrye.com> ah, it's per arch
2024-12-04 18:25:20 <@nirik:matrix.scrye.com> yeah
2024-12-04 18:25:43 <@nirik:matrix.scrye.com> yeah. probibly could be fixed to do so.
2024-12-04 18:26:51 <@carlwgeorge:matrix.org> free project idea for anyone that wants to dig in on that one 😀
2024-12-04 18:27:53 <@carlwgeorge:matrix.org> speaking of the repoclosure, it helped catch a thing i'll bring up in open floor
2024-12-04 18:28:03 <@carlwgeorge:matrix.org> anyone else have old biz before we move on?
2024-12-04 18:30:31 <@carlwgeorge:matrix.org> !topic Open Floor
2024-12-04 18:30:50 <@jonathanspw:fedora.im> I have something
2024-12-04 18:31:02 <@carlwgeorge:matrix.org> let me do this ansible thing quick
2024-12-04 18:31:06 <@carlwgeorge:matrix.org> it will be faster
2024-12-04 18:31:23 <@carlwgeorge:matrix.org> !link https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f19fd5f7e0
2024-12-04 18:31:47 <@carlwgeorge:matrix.org> repoclosure identified that this had a problem, but it wasn't immediately obvious because it installed fine
2024-12-04 18:32:06 <@carlwgeorge:matrix.org> turns out the /usr/bin/ansible-test command moved to it's own subpackage that isn't currently being shipped
2024-12-04 18:32:14 <@carlwgeorge:matrix.org> !link https://issues.redhat.com/browse/RHEL-69915
2024-12-04 18:32:53 <@carlwgeorge:matrix.org> hopefully will be resolved soon and the update can move to stable, but subscribe to that issue if you want to be kept in the loop
2024-12-04 18:33:18 <@nirik:matrix.scrye.com> I bet they don't want to add it. ;)
2024-12-04 18:33:29 <@carlwgeorge:matrix.org> nah they do, thankfully
2024-12-04 18:33:30 <@jrichardson:matrix.org> Is the possible resolution that the subpackage gets shipped? 
2024-12-04 18:33:39 <@nirik:matrix.scrye.com> ok, surprising
2024-12-04 18:33:41 <@carlwgeorge:matrix.org> yes, exactly that
2024-12-04 18:33:46 <@jrichardson:matrix.org> ah, yeah
2024-12-04 18:33:52 <@carlwgeorge:matrix.org> ansible-test is already shipped in centos/rhel 9
2024-12-04 18:34:09 <@carlwgeorge:matrix.org> the intent was to do the same in 10, someone just missed a step somewhere
2024-12-04 18:34:54 <@carlwgeorge:matrix.org> ok, fyi done, you're up Jonathan Wright 
2024-12-04 18:35:36 <@jonathanspw:fedora.im> I know SUSE does similar, calling it EPEL which causes confusion, but they're modifying packages and we have no plans to do that.
2024-12-04 18:35:36 <@jonathanspw:fedora.im> For Alma 10 we're going to maintain an x86_64_v2 build.  EPEL will be following v3, like RHEL, so we plan to potentially maintain an EPEL rebuild for v2.  This will likely still use epel-release for the install, it will just point to alma infra and the packages will be signed with our keys.  We expect no issues with packages due to v2 vs v3, but if there are any fixes will be PRd up to EPEL repos.  Does anyone have any thoughts, concerns, or feedback on this?
2024-12-04 18:35:36 <@jonathanspw:fedora.im> 
2024-12-04 18:36:37 <@nirik:matrix.scrye.com> so the packages would be the exact same ENVR/dist? or is there some way to tell v3 epel packages from v2 alma ones?
2024-12-04 18:36:53 <@jonathanspw:fedora.im> the tags will be x86_64_v2
2024-12-04 18:37:09 <@jonathanspw:fedora.im> all of alma 10 v2 rebuild will follow this.
2024-12-04 18:37:39 <@jonathanspw:fedora.im> I think.  Actually let me double check that.
2024-12-04 18:37:42 <@jonathanspw:fedora.im> We went back and forth on that a lot.
2024-12-04 18:38:01 <@nirik:matrix.scrye.com> yeah... just wanted to know if there is going to be confusion around which one people have
2024-12-04 18:38:06 <@jonathanspw:fedora.im> Yes, the _v2 suffix will be used for all v2 packages.  ex: https://repo.almalinux.org/almalinux-kitten/10-kitten/BaseOS/x86_64_v2/os/Packages/
2024-12-04 18:38:32 <@carlwgeorge:matrix.org> i agree with nirik, this is going to confuse a lot of people
2024-12-04 18:38:43 <@jonathanspw:fedora.im> So it will be easy to tell apart the alma/v2 epel packages from normal epel I suppose if that's your point
2024-12-04 18:39:21 <@carlwgeorge:matrix.org> i don't think an average user will have an easy time telling them apart, especially when it comes to where to file bugs
2024-12-04 18:40:06 <@jonathanspw:fedora.im> aside from compilation issues bugs *should* match up.  that's kind of the point.
2024-12-04 18:40:21 <@jonathanspw:fedora.im> So yeah there will be some confusion and overlap with bug reporting I'm sure, but it should be relevant on both sides
2024-12-04 18:40:32 <@carlwgeorge:matrix.org> that's a load bearing _should_
2024-12-04 18:41:03 <@jonathanspw:fedora.im> def
2024-12-04 18:41:37 <@nirik:matrix.scrye.com> what would the naming be for the epel-release? (it's noarch so it wouldn't have x86_64_v2 right)?
2024-12-04 18:42:40 <@conan_kudo:matrix.org> it should not matter
2024-12-04 18:42:58 <@jonathanspw:fedora.im> It would still be noarch within the v2 repo.  The point is for `dnf install epel-release` to still work normally within the v2 build because that's what people know.
2024-12-04 18:42:58 <@carlwgeorge:matrix.org> except it will be an identical nvr to the real epel-release
2024-12-04 18:43:09 <@jonathanspw:fedora.im> Trying to find the right mix between clarity and user experience here
2024-12-04 18:43:22 <@jonathanspw:fedora.im> I guess we could arch it?  What do you think Conan Kudo ?
2024-12-04 18:43:29 <@conan_kudo:matrix.org> what would be the point?
2024-12-04 18:43:41 <@conan_kudo:matrix.org> it's just a pile of data files
2024-12-04 18:43:52 <@jonathanspw:fedora.im> just for naming clarity underneath it all.  wouldn't break the intended functionality but would make clear it's the v2 package/alma epel
2024-12-04 18:43:56 <@carlwgeorge:matrix.org> _different_ data files, pointing to _different_ repos
2024-12-04 18:44:19 <@conan_kudo:matrix.org> epel-release-almaalt, I guess
2024-12-04 18:44:32 <@jonathanspw:fedora.im> as long as it provides epel-release yeah that would be fine too
2024-12-04 18:44:39 <@conan_kudo:matrix.org> no way we wouldn't
2024-12-04 18:44:49 <@jonathanspw:fedora.im> just so `rpm -qa |grep epel-release` will grab it either way, then you immediately know which it is.
2024-12-04 18:44:49 <@conan_kudo:matrix.org> it doesn't make sense to break expectations like that
2024-12-04 18:44:51 <@carlwgeorge:matrix.org> it was never considered a problem for the epel-release rebuild shipped in downstreams when the repo files were the same, but this is something else
2024-12-04 18:45:11 <@nirik:matrix.scrye.com> yeah, a epel-release-alma-v2 could help avoid confusion...
2024-12-04 18:45:24 <@carlwgeorge:matrix.org> or just don't call it epel
2024-12-04 18:45:42 <@nirik:matrix.scrye.com> sure, and provide epel-release so scripting, etc would still work
2024-12-04 18:45:52 <@conan_kudo:matrix.org> all the packages are sourced from fedora dist-git, so it's still epel
2024-12-04 18:46:06 <@nirik:matrix.scrye.com> but this epel-release is not epel-release
2024-12-04 18:46:18 <@carlwgeorge:matrix.org> it's not epel, just like oracle's epel isn't really epel
2024-12-04 18:46:38 <@jonathanspw:fedora.im> I don't see any problem with using a different name like epel-release-almav2 or something that just provides epel-release.  That provides a point of clarification without breaking UX.
2024-12-04 18:47:46 <@carlwgeorge:matrix.org> and just like oracle's epel, despite good intentions i don't see a way this doesn't end in confusion and frustration.  rebuilds will likely lag behind, new packages will be missed in one and not the other, fixes will be applied in one and not the other, and so on.
2024-12-04 18:48:06 <@conan_kudo:matrix.org> the difference between oracle's epel and alma's epel is that oracle forks every package
2024-12-04 18:48:15 <@conan_kudo:matrix.org> that's not what's happening here
2024-12-04 18:48:18 <@jonathanspw:fedora.im> Whoops I said suse earlier talking about an epel rebuild...I meant oracle.  just so that's clear.
2024-12-04 18:48:18 <@carlwgeorge:matrix.org> yet
2024-12-04 18:49:08 <@jonathanspw:fedora.im> I didn't bring it up but I imagine EPEL wouldn't want to officially maintain a v2 build huh?
2024-12-04 18:49:14 <@nhanlon:beeper.com> APEL (Additional Packages for Enterprise Linux) ? Bonus that it can be pronounced "Apple" :P 
2024-12-04 18:49:31 <@jonathanspw:fedora.im> There are so many reasons why it wouldn't work really, but should at least mention that idea.
2024-12-04 18:49:43 <@jonathanspw:fedora.im> as if "EPEL" vs "apple" isn't confusing enough in pronunciation
2024-12-04 18:49:49 <@nhanlon:beeper.com> :D
2024-12-04 18:49:57 <@carlwgeorge:matrix.org> "alma extras"
2024-12-04 18:50:07 <@conan_kudo:matrix.org> we already have extras
2024-12-04 18:50:10 <@conan_kudo:matrix.org> in alma
2024-12-04 18:50:22 <@jonathanspw:fedora.im> I think the biggest crux is `dnf install epel-release` needs to work for UX.
2024-12-04 18:50:40 <@jonathanspw:fedora.im> So even if we call it something else, if installing it that way via dnf works, people will still think it's "just epel"
2024-12-04 18:50:45 <@carlwgeorge:matrix.org> is there any reason the epel x86_64_v2 rebuilds can't just be put in the the existing extras repo?
2024-12-04 18:51:00 <@carlwgeorge:matrix.org> they're extra packages, sourced from the real epel, but they aren't epel
2024-12-04 18:51:03 <@jonathanspw:fedora.im> That's......a lot of packages
2024-12-04 18:51:05 <@conan_kudo:matrix.org> because extras serves the same purpose in centos that it does in alma
2024-12-04 18:51:17 <@conan_kudo:matrix.org> it's a collection of packages to activate other repos
2024-12-04 18:51:30 <@conan_kudo:matrix.org> because extras serves the same purpose in alma that it does in centos
2024-12-04 18:51:40 <@carlwgeorge:matrix.org> that's what it's been whittled down to, but it's not exclusive to that, hence the name
2024-12-04 18:51:48 <@conan_kudo:matrix.org> it is also on by default
2024-12-04 18:51:59 <@conan_kudo:matrix.org> we'd have to switch it off if we put epel _content_ in there
2024-12-04 18:52:00 <@carlwgeorge:matrix.org> it definitely had more things than just release packages back in centos 7
2024-12-04 18:52:03 <@jonathanspw:fedora.im> I mean we do have a repo we could put them in for alma 10, synergy...but i'm not sure we want to do that for multiple reasons.
2024-12-04 18:52:15 <@carlwgeorge:matrix.org> i'm glad you brought up synergy
2024-12-04 18:52:17 <@conan_kudo:matrix.org> I'd rather not put it there either
2024-12-04 18:52:24 <@jonathanspw:fedora.im> I can't speak for all of our technical steering committee but it's probably best to just assume we'd not want to do that.
2024-12-04 18:52:30 <@carlwgeorge:matrix.org> 
2024-12-04 18:52:30 <@carlwgeorge:matrix.org> you mentioned this
2024-12-04 18:52:30 <@carlwgeorge:matrix.org> > if there are any fixes will be PRd up to EPEL repos
2024-12-04 18:52:50 <@jonathanspw:fedora.im> fixes being specific to getting it to compile only....where no issues are expected.
2024-12-04 18:53:00 <@jonathanspw:fedora.im> for actual bug/package fixes it will be directing to real, upstream epel.
2024-12-04 18:53:05 <@carlwgeorge:matrix.org> when synergy launched it was mentioned as a staging ground for epel.  do we have any examples of that happening?
2024-12-04 18:53:43 <@jonathanspw:fedora.im> That's not and never was the intent.  It's not a staging ground for EPEL, just a "we'd prefer things in EPEL, and will remove from synergy if they're added to EPEL".
2024-12-04 18:54:15 <@jonathanspw:fedora.im> There are 2-3 minor cases of it happening so far.  I'd have to dig back in logs.  We have an automated monitor for when packages appear in epel and synergy.
2024-12-04 18:54:25 <@jonathanspw:fedora.im> But that's all kind of unrelated to the topic at hand
2024-12-04 18:54:49 <@carlwgeorge:matrix.org> it's related because of the statement about sending fixes to compile on v2 back to epel sources
2024-12-04 18:55:20 <@jonathanspw:fedora.im> you're conflating two different trains of thought.
2024-12-04 18:55:55 <@jonathanspw:fedora.im> the "send fixes via PRs" in this case ONLY means things that we discover in our rebuild pipeline that won't build due to the minor change of x86_64 spec, and we'd simply PR a fix upstream to let it build fine on v2 and v3.
2024-12-04 18:55:55 <@carlwgeorge:matrix.org> i'm skeptical that fixes would actually get sent back to epel sources, instead of being patched in a fork
2024-12-04 18:56:01 <@jonathanspw:fedora.im> It's not talking about bugs withint he package, etc.
2024-12-04 18:56:38 <@jonathanspw:fedora.im> There's 0 desire to fork the packages.  That's more work for no good reason.
2024-12-04 18:56:50 <@carlwgeorge:matrix.org> that fact that so few synergy packages have been actively migrated to epel is why i have this concern
2024-12-04 18:57:01 <@jonathanspw:fedora.im> You're still comparing apples and oranges
2024-12-04 18:57:16 <@jonathanspw:fedora.im> also for the sake of argument, there's hardly anything in synergy if we're being honest.
2024-12-04 18:57:44 <@jonathanspw:fedora.im> and that's because when ideas come up for it, we just take them straight to EPEL from the get-go instead of building them in synergy at all
2024-12-04 18:57:58 <@jonathanspw:fedora.im> and that's because when ideas come up for it, we just take them straight to EPEL from the get-go in most cases instead of building them in synergy at all
2024-12-04 18:58:54 <@jonathanspw:fedora.im> We're about out of time
2024-12-04 18:59:46 <@carlwgeorge:matrix.org> i've voiced my concerns, and my recommendation that it be called something other than epel.  keep us posted on what the eventual decision is.
2024-12-04 19:00:03 <@carlwgeorge:matrix.org> last call for open floor before we wrap up
2024-12-04 19:00:22 <@jonathanspw:fedora.im> Thanks for the feedback.  alesco hasn't decided one way or another on if we're doing this or not yet (though I suspect we will, in the end).  I'll keep everyone informed of the details if/when we do it.
2024-12-04 19:00:38 <@jonathanspw:fedora.im> Naming concerns duely noted.
2024-12-04 19:01:24 <@carlwgeorge:matrix.org> thanks everyone for attending, see y'all next week
2024-12-04 19:01:30 <@nhanlon:beeper.com> Thanks for running the meeting Carl
2024-12-04 19:01:42 <@dherrera:fedora.im> Thx carl :)
2024-12-04 19:01:43 <@nhanlon:beeper.com> !cookie give Carl George 
2024-12-04 19:01:44 <@zodbot:fedora.im> **Usage:** !cookie give <username>
2024-12-04 19:01:44 <@jrichardson:matrix.org> Thanks Carl George Goodnight everyone
2024-12-04 19:01:49 <@carlwgeorge:matrix.org> !endmeeting