<@carlwgeorge:matrix.org>
18:00:59
!startmeeting EPEL (2024-12-04)
<@meetbot:fedora.im>
18:01:02
Meeting started at 2024-12-04 18:00:59 UTC
<@meetbot:fedora.im>
18:01:02
The Meeting name is 'EPEL (2024-12-04)'
<@rcallicotte:fedora.im>
18:01:10
!hi
<@zodbot:fedora.im>
18:01:15
Robby Callicotte (rcallicotte) - he / him / his
<@dherrera:fedora.im>
18:01:20
!hi
<@jonathanspw:fedora.im>
18:01:21
!hi
<@zodbot:fedora.im>
18:01:22
Diego Herrera (dherrera) - he / him / his
<@zodbot:fedora.im>
18:01:23
Jonathan Wright (jonathanspw)
<@conan_kudo:matrix.org>
18:01:29
!hi
<@zodbot:fedora.im>
18:01:32
Neal Gompa (ngompa) - he / him / his
<@nhanlon:beeper.com>
18:01:48
!hi
<@zodbot:fedora.im>
18:01:49
Neil Hanlon (neil) - he / him / his
<@carlwgeorge:matrix.org>
18:01:51
!topic howdy
<@carlwgeorge:matrix.org>
18:02:11
welcome everybody
<@carlwgeorge:matrix.org>
18:04:08
!meetingname EPEL Steering Committee
<@meetbot:fedora.im>
18:04:09
The Meeting Name is now EPEL Steering Committee
<@carlwgeorge:matrix.org>
18:04:23
!topic EPEL Issues
<@carlwgeorge:matrix.org>
18:04:45
!link https://pagure.io/epel/issues?tags=meeting&status=Open
<@carlwgeorge:matrix.org>
18:05:35
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
<@carlwgeorge:matrix.org>
18:06:22
nothing jumps out at me from the overall issue list, so moving on
<@carlwgeorge:matrix.org>
18:06:48
!topic EPEL 10
<@carlwgeorge:matrix.org>
18:07:04
!epel 300
<@zodbot:fedora.im>
18:07:07
● **Assignee:** carlwgeorge
<@zodbot:fedora.im>
18:07:07
● **Last Updated:** 13 hours ago
<@zodbot:fedora.im>
18:07:07
● **Opened:** a month ago by carlwgeorge
<@zodbot:fedora.im>
18:07:07
**epel #300** (https://pagure.io/epel/issue/300):**EPEL 10 launch**
<@zodbot:fedora.im>
18:07:07
<@jrichardson:matrix.org>
18:07:19
!hi
<@zodbot:fedora.im>
18:07:24
James Richardson (jrichardson)
<@jrichardson:matrix.org>
18:07:30
Sorry I'm late
<@carlwgeorge:matrix.org>
18:07:50
i added a new page to the docs to cover all the active branches, including how epel 10 branches will work
<@carlwgeorge:matrix.org>
18:07:57
!link https://docs.fedoraproject.org/en-US/epel/branches/
<@carlwgeorge:matrix.org>
18:08:45
we also have c10 instructions on the getting started page now, thanks to James Richardson
<@carlwgeorge:matrix.org>
18:08:48
!link https://docs.fedoraproject.org/en-US/epel/getting-started/#_el10
<@carlwgeorge:matrix.org>
18:09:35
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
<@rcallicotte:fedora.im>
18:11:31
sweet
<@carlwgeorge:matrix.org>
18:11:40
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.
<@nirik:matrix.scrye.com>
18:12:15
morning.
<@carlwgeorge:matrix.org>
18:12:23
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
<@nirik:matrix.scrye.com>
18:12:26
somehow I still had this as an hour later.
<@carlwgeorge:matrix.org>
18:13:36
the other epel10 thing going on is releasever_minor not being set, which i brought up last meeting
<@carlwgeorge:matrix.org>
18:13:48
!link https://issues.redhat.com/browse/RHEL-68034
<@carlwgeorge:matrix.org>
18:15:16
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.
<@carlwgeorge:matrix.org>
18:16:27
i think that's all i had for epel10 stuff, anyone have any questions before we move on to the next topic?
<@carlwgeorge:matrix.org>
18:18:18
guess it's gonna be a quick meeting today
<@dherrera:fedora.im>
18:18:27
yup
<@carlwgeorge:matrix.org>
18:19:03
!topic Old Business
<@carlwgeorge:matrix.org>
18:19:29
i had one thing to bring up here, let me find the link
<@carlwgeorge:matrix.org>
18:20:00
!link https://issues.redhat.com/browse/OSCI-3778
<@carlwgeorge:matrix.org>
18:21:01
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
<@carlwgeorge:matrix.org>
18:22:09
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)
<@carlwgeorge:matrix.org>
18:23:03
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
<@carlwgeorge:matrix.org>
18:23:30
`dnf -q --enablerepo epel,epel-testing repoclosure --newest --check epel-testing`
<@nirik:matrix.scrye.com>
18:23:53
note that composes should run one each compose too.
<@carlwgeorge:matrix.org>
18:24:08
is that logged somewhere that is easy to get to?
<@nirik:matrix.scrye.com>
18:24:43
hum, looking, perhaps I am wrong
<@carlwgeorge:matrix.org>
18:25:00
https://kojipkgs.fedoraproject.org/compose/updates/epel10.0-testing/logs/x86_64/repoclosure-Everything.x86_64.log
<@carlwgeorge:matrix.org>
18:25:19
seems to not account for deps in the main os, which makes it fairly useless
<@nirik:matrix.scrye.com>
18:25:20
ah, it's per arch
<@nirik:matrix.scrye.com>
18:25:20
yeah
<@nirik:matrix.scrye.com>
18:25:43
yeah. probibly could be fixed to do so.
<@carlwgeorge:matrix.org>
18:26:51
free project idea for anyone that wants to dig in on that one 😀
<@carlwgeorge:matrix.org>
18:27:53
speaking of the repoclosure, it helped catch a thing i'll bring up in open floor
<@carlwgeorge:matrix.org>
18:28:03
anyone else have old biz before we move on?
<@carlwgeorge:matrix.org>
18:30:31
!topic Open Floor
<@jonathanspw:fedora.im>
18:30:50
I have something
<@carlwgeorge:matrix.org>
18:31:02
let me do this ansible thing quick
<@carlwgeorge:matrix.org>
18:31:06
it will be faster
<@carlwgeorge:matrix.org>
18:31:23
!link https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f19fd5f7e0
<@carlwgeorge:matrix.org>
18:31:47
repoclosure identified that this had a problem, but it wasn't immediately obvious because it installed fine
<@carlwgeorge:matrix.org>
18:32:06
turns out the /usr/bin/ansible-test command moved to it's own subpackage that isn't currently being shipped
<@carlwgeorge:matrix.org>
18:32:14
!link https://issues.redhat.com/browse/RHEL-69915
<@carlwgeorge:matrix.org>
18:32:53
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
<@nirik:matrix.scrye.com>
18:33:18
I bet they don't want to add it. ;)
<@carlwgeorge:matrix.org>
18:33:29
nah they do, thankfully
<@jrichardson:matrix.org>
18:33:30
Is the possible resolution that the subpackage gets shipped?
<@nirik:matrix.scrye.com>
18:33:39
ok, surprising
<@carlwgeorge:matrix.org>
18:33:41
yes, exactly that
<@jrichardson:matrix.org>
18:33:46
ah, yeah
<@carlwgeorge:matrix.org>
18:33:52
ansible-test is already shipped in centos/rhel 9
<@carlwgeorge:matrix.org>
18:34:09
the intent was to do the same in 10, someone just missed a step somewhere
<@carlwgeorge:matrix.org>
18:34:54
ok, fyi done, you're up Jonathan Wright
<@jonathanspw:fedora.im>
18:35:36
I know SUSE does similar, calling it EPEL which causes confusion, but they're modifying packages and we have no plans to do that.
<@jonathanspw:fedora.im>
18:35:36
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?
<@jonathanspw:fedora.im>
18:35:36
<@nirik:matrix.scrye.com>
18:36:37
so the packages would be the exact same ENVR/dist? or is there some way to tell v3 epel packages from v2 alma ones?
<@jonathanspw:fedora.im>
18:36:53
the tags will be x86_64_v2
<@jonathanspw:fedora.im>
18:37:09
all of alma 10 v2 rebuild will follow this.
<@jonathanspw:fedora.im>
18:37:39
I think. Actually let me double check that.
<@jonathanspw:fedora.im>
18:37:42
We went back and forth on that a lot.
<@nirik:matrix.scrye.com>
18:38:01
yeah... just wanted to know if there is going to be confusion around which one people have
<@jonathanspw:fedora.im>
18:38:06
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/
<@carlwgeorge:matrix.org>
18:38:32
i agree with nirik, this is going to confuse a lot of people
<@jonathanspw:fedora.im>
18:38:43
So it will be easy to tell apart the alma/v2 epel packages from normal epel I suppose if that's your point
<@carlwgeorge:matrix.org>
18:39:21
i don't think an average user will have an easy time telling them apart, especially when it comes to where to file bugs
<@jonathanspw:fedora.im>
18:40:06
aside from compilation issues bugs *should* match up. that's kind of the point.
<@jonathanspw:fedora.im>
18:40:21
So yeah there will be some confusion and overlap with bug reporting I'm sure, but it should be relevant on both sides
<@carlwgeorge:matrix.org>
18:40:32
that's a load bearing _should_
<@jonathanspw:fedora.im>
18:41:03
def
<@nirik:matrix.scrye.com>
18:41:37
what would the naming be for the epel-release? (it's noarch so it wouldn't have x86_64_v2 right)?
<@conan_kudo:matrix.org>
18:42:40
it should not matter
<@jonathanspw:fedora.im>
18:42:58
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.
<@carlwgeorge:matrix.org>
18:42:58
except it will be an identical nvr to the real epel-release
<@jonathanspw:fedora.im>
18:43:09
Trying to find the right mix between clarity and user experience here
<@jonathanspw:fedora.im>
18:43:22
I guess we could arch it? What do you think Conan Kudo ?
<@conan_kudo:matrix.org>
18:43:29
what would be the point?
<@conan_kudo:matrix.org>
18:43:41
it's just a pile of data files
<@jonathanspw:fedora.im>
18:43:52
just for naming clarity underneath it all. wouldn't break the intended functionality but would make clear it's the v2 package/alma epel
<@carlwgeorge:matrix.org>
18:43:56
_different_ data files, pointing to _different_ repos
<@conan_kudo:matrix.org>
18:44:19
epel-release-almaalt, I guess
<@jonathanspw:fedora.im>
18:44:32
as long as it provides epel-release yeah that would be fine too
<@conan_kudo:matrix.org>
18:44:39
no way we wouldn't
<@jonathanspw:fedora.im>
18:44:49
just so `rpm -qa |grep epel-release` will grab it either way, then you immediately know which it is.
<@conan_kudo:matrix.org>
18:44:49
it doesn't make sense to break expectations like that
<@carlwgeorge:matrix.org>
18:44:51
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
<@nirik:matrix.scrye.com>
18:45:11
yeah, a epel-release-alma-v2 could help avoid confusion...
<@carlwgeorge:matrix.org>
18:45:24
or just don't call it epel
<@nirik:matrix.scrye.com>
18:45:42
sure, and provide epel-release so scripting, etc would still work
<@conan_kudo:matrix.org>
18:45:52
all the packages are sourced from fedora dist-git, so it's still epel
<@nirik:matrix.scrye.com>
18:46:06
but this epel-release is not epel-release
<@carlwgeorge:matrix.org>
18:46:18
it's not epel, just like oracle's epel isn't really epel
<@jonathanspw:fedora.im>
18:46:38
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.
<@carlwgeorge:matrix.org>
18:47:46
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.
<@conan_kudo:matrix.org>
18:48:06
the difference between oracle's epel and alma's epel is that oracle forks every package
<@conan_kudo:matrix.org>
18:48:15
that's not what's happening here
<@jonathanspw:fedora.im>
18:48:18
Whoops I said suse earlier talking about an epel rebuild...I meant oracle. just so that's clear.
<@carlwgeorge:matrix.org>
18:48:18
yet
<@jonathanspw:fedora.im>
18:49:08
I didn't bring it up but I imagine EPEL wouldn't want to officially maintain a v2 build huh?
<@nhanlon:beeper.com>
18:49:14
APEL (Additional Packages for Enterprise Linux) ? Bonus that it can be pronounced "Apple" :P
<@jonathanspw:fedora.im>
18:49:31
There are so many reasons why it wouldn't work really, but should at least mention that idea.
<@jonathanspw:fedora.im>
18:49:43
as if "EPEL" vs "apple" isn't confusing enough in pronunciation
<@nhanlon:beeper.com>
18:49:49
:D
<@carlwgeorge:matrix.org>
18:49:57
"alma extras"
<@conan_kudo:matrix.org>
18:50:07
we already have extras
<@conan_kudo:matrix.org>
18:50:10
in alma
<@jonathanspw:fedora.im>
18:50:22
I think the biggest crux is `dnf install epel-release` needs to work for UX.
<@jonathanspw:fedora.im>
18:50:40
So even if we call it something else, if installing it that way via dnf works, people will still think it's "just epel"
<@carlwgeorge:matrix.org>
18:50:45
is there any reason the epel x86_64_v2 rebuilds can't just be put in the the existing extras repo?
<@carlwgeorge:matrix.org>
18:51:00
they're extra packages, sourced from the real epel, but they aren't epel
<@jonathanspw:fedora.im>
18:51:03
That's......a lot of packages
<@conan_kudo:matrix.org>
18:51:05
because extras serves the same purpose in centos that it does in alma
<@conan_kudo:matrix.org>
18:51:17
it's a collection of packages to activate other repos
<@conan_kudo:matrix.org>
18:51:30
because extras serves the same purpose in alma that it does in centos
<@carlwgeorge:matrix.org>
18:51:40
that's what it's been whittled down to, but it's not exclusive to that, hence the name
<@conan_kudo:matrix.org>
18:51:48
it is also on by default
<@conan_kudo:matrix.org>
18:51:59
we'd have to switch it off if we put epel _content_ in there
<@carlwgeorge:matrix.org>
18:52:00
it definitely had more things than just release packages back in centos 7
<@jonathanspw:fedora.im>
18:52:03
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.
<@carlwgeorge:matrix.org>
18:52:15
i'm glad you brought up synergy
<@conan_kudo:matrix.org>
18:52:17
I'd rather not put it there either
<@jonathanspw:fedora.im>
18:52:24
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.
<@carlwgeorge:matrix.org>
18:52:30
<@carlwgeorge:matrix.org>
18:52:30
you mentioned this
<@carlwgeorge:matrix.org>
18:52:30
> if there are any fixes will be PRd up to EPEL repos
<@jonathanspw:fedora.im>
18:52:50
fixes being specific to getting it to compile only....where no issues are expected.
<@jonathanspw:fedora.im>
18:53:00
for actual bug/package fixes it will be directing to real, upstream epel.
<@carlwgeorge:matrix.org>
18:53:05
when synergy launched it was mentioned as a staging ground for epel. do we have any examples of that happening?
<@jonathanspw:fedora.im>
18:53:43
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".
<@jonathanspw:fedora.im>
18:54:15
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.
<@jonathanspw:fedora.im>
18:54:25
But that's all kind of unrelated to the topic at hand
<@carlwgeorge:matrix.org>
18:54:49
it's related because of the statement about sending fixes to compile on v2 back to epel sources
<@jonathanspw:fedora.im>
18:55:20
you're conflating two different trains of thought.
<@jonathanspw:fedora.im>
18:55:55
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.
<@carlwgeorge:matrix.org>
18:55:55
i'm skeptical that fixes would actually get sent back to epel sources, instead of being patched in a fork
<@jonathanspw:fedora.im>
18:56:01
It's not talking about bugs withint he package, etc.
<@jonathanspw:fedora.im>
18:56:38
There's 0 desire to fork the packages. That's more work for no good reason.
<@carlwgeorge:matrix.org>
18:56:50
that fact that so few synergy packages have been actively migrated to epel is why i have this concern
<@jonathanspw:fedora.im>
18:57:01
You're still comparing apples and oranges
<@jonathanspw:fedora.im>
18:57:16
also for the sake of argument, there's hardly anything in synergy if we're being honest.
<@jonathanspw:fedora.im>
18:57:44
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
<@jonathanspw:fedora.im>
18:57:58
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
<@jonathanspw:fedora.im>
18:58:54
We're about out of time
<@carlwgeorge:matrix.org>
18:59:46
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.
<@carlwgeorge:matrix.org>
19:00:03
last call for open floor before we wrap up
<@jonathanspw:fedora.im>
19:00:22
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.
<@jonathanspw:fedora.im>
19:00:38
Naming concerns duely noted.
<@carlwgeorge:matrix.org>
19:01:24
thanks everyone for attending, see y'all next week
<@nhanlon:beeper.com>
19:01:30
Thanks for running the meeting Carl
<@dherrera:fedora.im>
19:01:42
Thx carl :)
<@nhanlon:beeper.com>
19:01:43
!cookie give Carl George
<@zodbot:fedora.im>
19:01:44
**Usage:** !cookie give <username>
<@jrichardson:matrix.org>
19:01:44
Thanks Carl George Goodnight everyone
<@carlwgeorge:matrix.org>
19:01:49
!endmeeting