<@tdawson:fedora.im>
18:00:14
!startmeeting EPEL (2025-03-19)
<@meetbot:fedora.im>
18:00:15
Meeting started at 2025-03-19 18:00:14 UTC
<@meetbot:fedora.im>
18:00:15
The Meeting name is 'EPEL (2025-03-19)'
<@tdawson:fedora.im>
18:00:20
!topic aloha
<@tdawson:fedora.im>
18:00:20
!meetingname epel
<@meetbot:fedora.im>
18:00:21
The Meeting Name is now epel
<@dherrera:fedora.im>
18:00:31
!hi
<@zodbot:fedora.im>
18:00:33
Diego Herrera (dherrera) - he / him / his
<@davide:cavalca.name>
18:00:39
!hi
<@zodbot:fedora.im>
18:00:42
Davide Cavalca (dcavalca) - he / him / his
<@nhanlon:beeper.com>
18:01:02
!hi
<@zodbot:fedora.im>
18:01:04
Neil Hanlon (neil) - he / him / his
<@carlwgeorge:fedora.im>
18:01:19
!hi
<@zodbot:fedora.im>
18:01:20
Carl George (carlwgeorge) - he / him / his
<@tdawson:fedora.im>
18:01:43
Hi Diego Herrera , Davide Cavalca , Neil Hanlon , and Carl George
<@salimma:fedora.im>
18:01:52
!hi
<@zodbot:fedora.im>
18:01:54
Michel Lind (salimma) - he / him / his
<@nhanlon:beeper.com>
18:01:55
hiya Troy, everyone
<@tdawson:fedora.im>
18:03:03
Hi Michel Lind UTC-6
<@rcallicotte:fedora.im>
18:04:38
!hi
<@zodbot:fedora.im>
18:04:39
Robby Callicotte (rcallicotte) - he / him / his
<@tdawson:fedora.im>
18:04:51
Hi Robby Callicotte
<@tdawson:fedora.im>
18:05:50
!link https://pagure.io/epel/issues?tags=meeting&status=Open
<@tdawson:fedora.im>
18:05:50
!topic EPEL Issues https://pagure.io/epel/issues
<@tdawson:fedora.im>
18:06:33
We have on open issue this week, and I think it's going to take alot of discussion, I wish more were here this week.
<@tdawson:fedora.im>
18:06:41
!epel 324
<@zodbot:fedora.im>
18:06:43
**epel #324** (https://pagure.io/epel/issue/324):**EPEL 10 minor version upgrade path**
<@zodbot:fedora.im>
18:06:43
● **Assignee:** carlwgeorge
<@zodbot:fedora.im>
18:06:43
● **Last Updated:** Never
<@zodbot:fedora.im>
18:06:43
● **Opened:** 11 hours ago by carlwgeorge
<@zodbot:fedora.im>
18:06:43
<@tdawson:fedora.im>
18:08:03
Carl George: I think this is going to be mainly you ... I have a few questions, but I'll let you start.
<@smooge:fedora.im>
18:08:19
hello
<@carlwgeorge:fedora.im>
18:08:22
sure, i hope most folks had a chance to read over this issue when i posted it in the channel this morning
<@tdawson:fedora.im>
18:08:37
Hello Stephen J Smoogen
<@nirik:matrix.scrye.com>
18:08:38
morning
<@tdawson:fedora.im>
18:08:46
Morning nirik
<@tdawson:fedora.im>
18:08:51
you both came just in time.
<@carlwgeorge:fedora.im>
18:08:54
i'll summarize it a bit just to get the convo going
<@conan_kudo:matrix.org>
18:09:02
!hi
<@zodbot:fedora.im>
18:09:10
Neal Gompa (ngompa) - he / him / his
<@carlwgeorge:fedora.im>
18:09:14
a few people have raised concerns about rhel users upgrading between minor versions
<@carlwgeorge:fedora.im>
18:09:54
a user on 10.0 upgrading to 10.1 will see rhel 10.1 packages and epel 10.0 packages during the upgrade, and only after redhat-release is updated will they see epel 10.1 packages
<@carlwgeorge:fedora.im>
18:10:53
in a manual scenario it's easy (yet still annoying) to workaround by running a two step upgrade like `dnf -y upgrade redhat-release && dnf -y upgrade`, but the bigger question is how it affects dnf-automattic
<@salimma:fedora.im>
18:11:19
uh... I've never used RHEL this way but shouldn't upgrade also upgrade redhat-release?
<@salimma:fedora.im>
18:11:28
oh, I see. only the next transaction will pull in epel packages
<@nirik:matrix.scrye.com>
18:11:38
humm,....
<@carlwgeorge:fedora.im>
18:11:38
it will, but at the start of the transaction releasever_minor will still be 0
<@salimma:fedora.im>
18:11:41
this is the sort of thing fedora solves by having an upgrade plugin, right?
<@salimma:fedora.im>
18:11:52
another way is you can override --releasever when upgrading
<@nirik:matrix.scrye.com>
18:12:07
what libdnf5 does 10 have?
<@carlwgeorge:fedora.im>
18:12:09
fedora doesn't have minor versions, but yes the releasever flag solves this too
<@carlwgeorge:fedora.im>
18:12:27
el10 is dnf/libdnf, not dnf5/libdnf5
<@nirik:matrix.scrye.com>
18:12:53
oh, right, boom. there goes that idea in flames... thats right
<@nirik:matrix.scrye.com>
18:13:14
libdnf5 has a 'action' plugin that we could use to handle this.
<@carlwgeorge:fedora.im>
18:13:46
as i was going over this last night i couldn't help but think the concern might be overblow. is anyone well versed in dnf-automattic? can it be configured to upgrade what it can and try again for the rest on the next run?
<@tdawson:fedora.im>
18:13:49
Using the --release flag, is just another variation on the manual problem. Manually, there are various things you can do, but when you switch to scripts and automation, that's where the problems come in.
<@smooge:fedora.im>
18:14:03
personally.. there is only really so much we can do beyond documenting the edge case
<@salimma:fedora.im>
18:14:21
true, I mean in fedora the updates plugin let you do operations that need to be done manually that a mere 'dnf --releasever=... upgrade' does not solve
<@salimma:fedora.im>
18:15:03
having to run 'dnf upgrade' twice is no big deal either tbh. I guess the issue is if the transactions fail unless you know what you're doing. but then ... yeah either upgrade redhat-release first or upgrade with --release=... should be documented
<@nirik:matrix.scrye.com>
18:15:08
dnf-automatic has a number of knobs. If you set it to apply updates it does... if the transaction fails, it just emails you or whatever.
<@carlwgeorge:fedora.im>
18:15:27
yeah if we think this is closer to edge case than the norm (it may well be) then i'm fine just having a docs page to walk through the manual fixes
<@smooge:fedora.im>
18:15:29
i mean I have still a thing where even minor RHEL updates I do a `dnf update redhat-release; dnf update rpm; rpm --rebuilddb; dnf update dnf; dnf update`
<@nirik:matrix.scrye.com>
18:15:30
it would not run twice (unless someone configured it to). But it would run the next update the next interval
<@carlwgeorge:fedora.im>
18:16:01
could the `best` setting help here? i need to re-read how that one works
<@smooge:fedora.im>
18:16:01
because I know there are edge cases which can happen.. doesn't mean its a sane thing to expect everyone to do
<@salimma:fedora.im>
18:16:12
rebuilddb! :O
<@nirik:matrix.scrye.com>
18:16:57
no, I don't think best will help any. The new epel-release with the new repos is not even in the transaction
<@carlwgeorge:fedora.im>
18:17:18
i meant from the "upgrade what you can, try the rest again later" angle
<@carlwgeorge:fedora.im>
18:17:47
epel-release wouldn't change in the transaction, that would stay constant and just evaluate to different metalinks based on redhat-release
<@nirik:matrix.scrye.com>
18:17:59
well, normally it will just update things that aren't broken. if you pass best it will try and upgrade things that could be broken.
<@carlwgeorge:fedora.im>
18:18:14
oh, maybe it does what i'm describing by default then
<@nirik:matrix.scrye.com>
18:18:32
right, but due to minor change after the redhat-release updates, the thing that epel-release points to changes and it has a new repo to evaluate.
<@nirik:matrix.scrye.com>
18:18:38
yeah, it should
<@carlwgeorge:fedora.im>
18:18:45
i'm used to manual dnf runs that just abort if it encounters a problem, leaving you to `--exclude` broken stuff
<@tdawson:fedora.im>
18:19:06
There is also "--skip-broken"
<@nirik:matrix.scrye.com>
18:19:24
and --allowerasing (upgrade everything and just remove packages that are broken)
<@carlwgeorge:fedora.im>
18:19:29
ok, so action item for myself is to confirm the behavior of dnf-automattic to gauge how serious the problem is
<@smooge:fedora.im>
18:19:51
might as well have --nodeps --force
<@nirik:matrix.scrye.com>
18:19:54
best is true by default in rhel9. Not sure if it is in 10
<@nirik:matrix.scrye.com>
18:20:22
(this was a big doom a while back because they wanted that in fedora too)
<@carlwgeorge:fedora.im>
18:20:23
it is, so maybe we'd need to override it to `best=false`
<@carlwgeorge:fedora.im>
18:20:59
if dnf-automattic can be made to cooperate, i'm inclined to leave the current set up in place for 10, and reevaluate for 11
<@carlwgeorge:fedora.im>
18:21:47
if we do decide it's important enough to resolve this now for 10, we have a few knobs with the mirror directories and mirrormanager repo redirects we can play with
<@carlwgeorge:fedora.im>
18:22:41
my experience as a sysadmin was "not many" with most doing scheduled maintenance windows, but Jonathan Wright tells me his experience is the opposite with most doing automattic
<@nirik:matrix.scrye.com>
18:22:48
FWIW, we use in fedora-infra... but we have it only applying security marked updates. So, on minor upgrades it never applies those...
<@carlwgeorge:fedora.im>
18:23:56
hmm, i wonder how security only works when there is a security fix available in both 10.0 and 10.1
<@nirik:matrix.scrye.com>
18:24:29
I think it applies it (unless it has broken deps, then it doesn't and errors)
<@salimma:fedora.im>
18:24:45
are core RHEL updates marked if they are security btw? I know EPEL updates are
<@carlwgeorge:fedora.im>
18:24:59
definitely
<@smooge:fedora.im>
18:25:08
its what people pay us for
<@tdawson:fedora.im>
18:26:01
So Carl, I had a question on your proposal, incase we want to go that route. You said to have repo names mapped to the full numbers epel/10.0 epel/10.1 ... does that mean that there wouldn't be a epel/10 ?
<@carlwgeorge:fedora.im>
18:26:57
we could do it either way, with a real epel/10 directory or an epel-10 redirect that points to a real epel/10.1 directory
<@nirik:matrix.scrye.com>
18:27:44
Related to this all, some people testing 10.1 stuff can't get any epel currently. Probibly we should add a redirect in there for them?
<@tdawson:fedora.im>
18:27:51
Wasn't the original plan to have a epel/10 directory, with epel/10.1 point to that? (for the state we are currently in)
<@carlwgeorge:fedora.im>
18:28:48
the very first plan was symlinks (10 → 10.1) until i learned that mirrormanager ignores those
<@carlwgeorge:fedora.im>
18:29:03
repo redirects give us a useful standin for symlinks
<@tdawson:fedora.im>
18:29:45
What about both? Does that confuse mirror-manager?
<@carlwgeorge:fedora.im>
18:29:55
right, if we ride out the current structure, an epel-10.1 → epel-10 redirect would be appropriate
<@carlwgeorge:fedora.im>
18:30:35
mm just outright ignores symlinks, and it manages the redirects itself. we would want to do both for the commented out baseurl.
<@carlwgeorge:fedora.im>
18:31:46
a nice side effect of this would be the mock devs really want "floating targets" to simplify mock config maintenance
<@carlwgeorge:fedora.im>
18:32:41
i do want to clarify that i don't think we necessary need to figure this out before the rhel 10 launch, changing this up later should be feasible as long as we ship the updated epel-release to all active minor versions
<@rcallicotte:fedora.im>
18:33:27
One more thing... we will likely need to update the koji hub config policy for epel10.1 right?
<@carlwgeorge:fedora.im>
18:33:31
curl 'https://mirrors.fedoraproject.org/metalink?protocol=https&arch=x86_64&repo=epel-10m'
<@carlwgeorge:fedora.im>
18:33:31
i did set up an example redirect if people want to see how that works, asking for epel-10m will give you 10.0 links
<@carlwgeorge:fedora.im>
18:33:31
```
<@carlwgeorge:fedora.im>
18:33:31
```
<@carlwgeorge:fedora.im>
18:33:31
<@carlwgeorge:fedora.im>
18:34:12
that would be unrelated, the koji tags all already include the minor versions. it is something we included in the mass branching sop.
<@carlwgeorge:fedora.im>
18:35:03
well i've taken up half the meeting with this so i think we can put a pin in this for now. definitely comment on that issue if you think of more questions, i'll get to testing dnf-automattic to confirm its behavior.
<@tdawson:fedora.im>
18:35:12
Oh .... I was thinking the 'm' was a standin for some number, but you are talking about an actual 'm'
<@tdawson:fedora.im>
18:35:20
Now it makes more sense.
<@carlwgeorge:fedora.im>
18:35:37
m might not be the best string, now that i think of it it could be confused for modular
<@dherrera:fedora.im>
18:36:00
it's more like mark, or minor, or just m
<@dherrera:fedora.im>
18:36:22
I think it's better for it not to have a meaning
<@dherrera:fedora.im>
18:36:25
so meaningless
<@carlwgeorge:fedora.im>
18:36:34
the bodhi identifier for epel 8 modular was EPEL-8M
<@tdawson:fedora.im>
18:36:37
It does make sense ... my mind was just filling it in with a number .... but you are right, since this doesn't have to be decided this week, let's timebox this for another time.
<@nirik:matrix.scrye.com>
18:36:52
yeah, the m there is a bit unfortunate...
<@dherrera:fedora.im>
18:37:19
it's mainly cos we need something to diferentiate
<@carlwgeorge:fedora.im>
18:37:22
could be an r, or a v, or whatever, just some string to differentiate "10 for centos" vs "10 for rhel"
<@nirik:matrix.scrye.com>
18:38:02
☃️!
<@tdawson:fedora.im>
18:38:24
So ... we've talked alot about EPEL 10, let's move on to the next topic
<@tdawson:fedora.im>
18:38:29
!topic EPEL 10
<@nhanlon:beeper.com>
18:38:31
μ !
<@tdawson:fedora.im>
18:38:32
Ha!!
<@tdawson:fedora.im>
18:39:11
Does anyone have anything for EPEL 10?
<@tdawson:fedora.im>
18:39:26
Are we far enough along that we should take this off the agenda?
<@carlwgeorge:fedora.im>
18:39:39
i can do a quick update on https://pagure.io/epel/issue/313
<@tdawson:fedora.im>
18:39:49
Go for it
<@carlwgeorge:fedora.im>
18:39:56
!epel 313
<@zodbot:fedora.im>
18:39:58
● **Assignee:** carlwgeorge
<@zodbot:fedora.im>
18:39:58
**epel #313** (https://pagure.io/epel/issue/313):**EPEL 10 dnf variables problems**
<@zodbot:fedora.im>
18:39:58
<@zodbot:fedora.im>
18:39:58
● **Opened:** a month ago by carlwgeorge
<@zodbot:fedora.im>
18:39:58
● **Last Updated:** a day ago
<@carlwgeorge:fedora.im>
18:41:02
the dnf and libdnf changes have been merged, so now we have releasever_minor set correctly, and packagekit works with epel
<@carlwgeorge:fedora.im>
18:41:18
i'll note the build nvrs in the issue and close it out
<@tdawson:fedora.im>
18:42:26
Very cool, thank you for all the work you've done on that.
<@tdawson:fedora.im>
18:42:41
Anything else on that? Or anything else for epel10?
<@tdawson:fedora.im>
18:43:40
Looking at the time, I'll move along.
<@tdawson:fedora.im>
18:44:22
!topic Old Business
<@tdawson:fedora.im>
18:45:19
Any old business?
<@carlwgeorge:fedora.im>
18:45:45
epel-packagers-sig perhaps?
<@tdawson:fedora.im>
18:46:04
Ohh ... that's some good old business.
<@carlwgeorge:fedora.im>
18:46:27
!link https://discussion.fedoraproject.org/t/deprecating-the-epel-packagers-sig/137923
<@carlwgeorge:fedora.im>
18:47:21
we've left that one a big in limbo, i've asked folks to not add the sig to more packages until we reach a conclusion. how are folks feeling about deprecating it? i know i've at least seen a mkdocs sig form, but not sure about others.
<@carlwgeorge:fedora.im>
18:48:21
we've left that one a bit in limbo, i've asked folks to not add the sig to more packages until we reach a conclusion. how are folks feeling about deprecating it? i know i've at least seen a mkdocs sig form, but not sure about others.
<@tdawson:fedora.im>
18:49:10
I'm still for it, and I'm still willing to take any packages that have me already as one of the admins/co-admins
<@tdawson:fedora.im>
18:49:38
I'm still for it, and I'm still willing to take any packages that already has me as one of the admins/co-admins
<@salimma:fedora.im>
18:50:02
I'm ok deprecating it
<@carlwgeorge:fedora.im>
18:50:08
the arguments against i've seen so far were mostly that it will slow things down building new packages, but i've seen enough "build and forget" behavior that i'm ok with that trade-off
<@salimma:fedora.im>
18:50:37
I've not had time to work on ebranch recently but once I cut a new release that one will take out epel packagers sig by default (instead letting you nominate other groups to own the package)
<@salimma:fedora.im>
18:50:59
speaking of taht... Carl George should I make it check that the FAS is a member of the nominated group? so people can't just force groups to own a change they want
<@davide:cavalca.name>
18:51:02
Could/should we have a simpler process for creating small scoped sigs as a way to group packages?
<@salimma:fedora.im>
18:51:27
yeah I certainly don't feel comfortable having especially non-SIG members just expecting us to carry even more packages. no please
<@salimma:fedora.im>
18:52:00
yeah, I think making SIG creation easier would help. the docs need improving e.g. I think mailing lists are no longer needed *except* for the one we need to get bugzilla emails
<@davide:cavalca.name>
18:52:03
There's quite a few groups of related packages that could benefit from the organization, even if initially the "sig" would just be one or two people
<@davide:cavalca.name>
18:52:19
The immediate example I have is the beancount stack I have on review
<@salimma:fedora.im>
18:52:28
and also SIGs that are too ambitious tend to implode, witness how we don't really have a Java SIG anymore
<@davide:cavalca.name>
18:52:35
Which is about a dozen of interrelated python packages
<@davide:cavalca.name>
18:52:52
I don't expect others to maintain this but it would still be nice to be able to group them
<@carlwgeorge:fedora.im>
18:52:57
time for a vote?
<@salimma:fedora.im>
18:52:59
(it was a PITA when I tried to bring in the Java packages that are needed for Google's golang packages - to the point we'll just give up for epel10 likely)
<@nirik:matrix.scrye.com>
18:53:09
If it's a small number of packages, wouldn't it work out to just coordinate between comaintainers?
<@salimma:fedora.im>
18:53:17
Proposal: EPEL Packagers SIG is deprecated. We will update docs and tooling that still reference it
<@nirik:matrix.scrye.com>
18:53:40
but yeah, more targeted and with regular communication/diving up work has a much better chance than 'everything'
<@tdawson:fedora.im>
18:53:52
I'm no longer in the sig, but +1 from me.
<@salimma:fedora.im>
18:53:56
nirik: the problem is that it tends to be packages we only discover further down the line - and even in groups that have SIGs like GNOME you end up with some packages where the SIG is never even added
<@davide:cavalca.name>
18:54:09
It's less that and more having a system in place that would make it straightforward to add comantianers and immediately see what one is signing up for. Among other things.
<@nirik:matrix.scrye.com>
18:54:18
does that include removing it from all packages that currently are in it?
<@salimma:fedora.im>
18:54:26
so... SIGs don't solve everything, but not having a SIG, plus having provenpackager papering over things, means we discover issues with maintainers when we try to branch a package
<@davide:cavalca.name>
18:54:40
I'm ok with this in principle but I think we need to quantify what it means in practice
<@salimma:fedora.im>
18:54:45
nirik: I think Carl's earlier proposal is this is deprecated, and we'll migrate packages to smaller SIGs
<@salimma:fedora.im>
18:54:51
so... keep it but stop piling on tech debt
<@nirik:matrix.scrye.com>
18:54:53
perhaps we can make that story much better on forgejo
<@carlwgeorge:fedora.im>
18:55:33
i'm ok with a vote just to make it official that it's deprecated and not allowed to be added to anymore packages, then we can figure out removal later
<@carlwgeorge:fedora.im>
18:56:13
would deleting the group remove it from all the packages it's on? or do we need to remove it first before it can be deleted?
<@salimma:fedora.im>
18:56:20
ok... vote time then
<@salimma:fedora.im>
18:56:30
nirik: might know what happens if we delete a group
<@nirik:matrix.scrye.com>
18:57:07
you would need to remove everyone from it first... and in general we don't delete groups, just remove everyone from them/packages from them
<@nirik:matrix.scrye.com>
18:57:20
otherwise, it should be possible, but would require direct database tweaking
<@carlwgeorge:fedora.im>
18:57:29
ahh, that's right, i still see defunct groups in fas
<@tdawson:fedora.im>
18:59:00
We're getting close on time. Let's have a quick vote that it's depricated, and we can start on the removal later (as carl said)
<@tdawson:fedora.im>
18:59:16
+1 - depreciate it
<@carlwgeorge:fedora.im>
18:59:17
+1 from me
<@davide:cavalca.name>
18:59:40
+1
<@nirik:matrix.scrye.com>
19:00:00
sure, +1
<@tdawson:fedora.im>
19:00:46
I think 4 is enough for a majority, are we good with that?
<@tdawson:fedora.im>
19:01:55
I don't want to rush anything, but I haven't heard anyone with a valid argument against, so I'm glad to move this along.
<@tdawson:fedora.im>
19:02:05
!agree - EPEL Packagers SIG is depricated - take down will not be all at once, but systematic - 4(+1) 0(-1) 3 not voted/absent
<@tdawson:fedora.im>
19:02:52
!agreed - EPEL Packagers SIG is depricated - take down will not be all at once, but systematic - 4(+1) 0(-1) 3 not voted/absent
<@tdawson:fedora.im>
19:03:00
There we go. :)
<@carlwgeorge:fedora.im>
19:03:00
Michel Lind UTC-6: since you started this sig, would you like to be the one to update the docs to label it deprecated?
<@salimma:fedora.im>
19:03:18
yup, will do
<@salimma:fedora.im>
19:03:35
I think I finally have time to do docs over the next week, this has been dangling for long enough
<@tdawson:fedora.im>
19:03:52
Thank you.
<@tdawson:fedora.im>
19:04:20
And, our time is up. Thank you all for the very good discussions we've had this week. And thank you for all you do for EPEL and it's community.
<@tdawson:fedora.im>
19:04:34
I'll talk to ya'll next week, if not sooner.
<@tdawson:fedora.im>
19:04:59
!endmeeting