<@tdawson:fedora.im>
18:00:22
!startmeeting EPEL (2025-11-05)
<@meetbot:fedora.im>
18:00:23
Meeting started at 2025-11-05 18:00:22 UTC
<@meetbot:fedora.im>
18:00:24
The Meeting name is 'EPEL (2025-11-05)'
<@tdawson:fedora.im>
18:00:30
!topic aloha
<@tdawson:fedora.im>
18:00:30
!meetingname epel
<@meetbot:fedora.im>
18:00:32
The Meeting Name is now epel
<@carlwgeorge:fedora.im>
18:00:32
!hi
<@zodbot:fedora.im>
18:00:33
Carl George (carlwgeorge) - he / him / his
<@dherrera:fedora.im>
18:00:39
!hi
<@zodbot:fedora.im>
18:00:40
Diego Herrera (dherrera) - he / him / his
<@tdawson:fedora.im>
18:00:44
Hi Carl George and Diego Herrera
<@davide:cavalca.name>
18:02:36
!hi
<@zodbot:fedora.im>
18:02:38
Davide Cavalca (dcavalca) - he / him / his
<@tdawson:fedora.im>
18:02:49
Hi Davide Cavalca
<@nirik:matrix.scrye.com>
18:02:56
morning
<@tdawson:fedora.im>
18:03:33
Morning nirik
<@tdawson:fedora.im>
18:05:03
A bit light today, but we have enough for any voting items.
<@tdawson:fedora.im>
18:05:10
!link https://pagure.io/epel/issues?tags=meeting&status=Open
<@tdawson:fedora.im>
18:05:10
!topic EPEL Issues https://pagure.io/epel/issues
<@tdawson:fedora.im>
18:05:10
!link https://pagure.io/epel/pull-requests?status=Open&tags=meeting
<@tdawson:fedora.im>
18:05:40
Let's start with the hopefully quick one.
<@tdawson:fedora.im>
18:05:52
!epel 354
<@zodbot:fedora.im>
18:05:53
● **Last Updated:** 6 days ago
<@zodbot:fedora.im>
18:05:53
● **Assignee:** Not Assigned
<@zodbot:fedora.im>
18:05:53
● **Opened:** a week ago by tflink
<@zodbot:fedora.im>
18:05:53
<@zodbot:fedora.im>
18:05:53
**epel #354** (https://pagure.io/epel/issue/354):**Proposal: Allow Controlled Backwards-Incompatible Updates for ROCm in EPEL10**
<@tdawson:fedora.im>
18:06:20
We talked about this last time and nobody had anything against it, but it hadn't been a week.
<@tdawson:fedora.im>
18:06:59
Two people already gave their +1 in the ticket ... and that's great because those are the two that are missing today.
<@neil:fedora.im>
18:07:16
o/ heya folks
<@tdawson:fedora.im>
18:07:28
Hey Neil Hanlon
<@carlwgeorge:fedora.im>
18:07:53
one thing that occurred to me is we really haven't heard much about how incompatible those updates are. does rocm do semantic versioning, or are the major versions more compatible than they let on?
<@tdawson:fedora.im>
18:07:53
Does anyone have anything they want to comment about this ticket before we vote on it?
<@nirik:matrix.scrye.com>
18:08:26
I'm +1 in general...
<@carlwgeorge:fedora.im>
18:09:02
tflink: can you shed any light on that?
<@conan_kudo:matrix.org>
18:09:21
!hi
<@zodbot:fedora.im>
18:09:24
Neal Gompa (ngompa) - he / him / his
<@tdawson:fedora.im>
18:09:29
Seems I'm having Matric connection issues ..so if I'm a bit slow today, I apologize.
<@tdawson:fedora.im>
18:09:48
Hi Conan Kudo 🤧
<@tflink:fedora.im>
18:09:50
some of the upgrades coming up are going to be pretty incompatible, there are some large changes coming
<@conan_kudo:matrix.org>
18:09:50
already Robby Callicotte and I gave +1 in the ticket
<@carlwgeorge:fedora.im>
18:10:35
what does "pretty incompatible" look like? will other packages need to get rebuilt against a new library soname? config file changes? something else?
<@tflink:fedora.im>
18:10:38
not sure how you want to quantify it but IIRC, the 6.4 -> 7.x upgrade itself is not terribly backwards compatible and that's what we're looking to do first
<@conan_kudo:matrix.org>
18:11:02
do we even have reverse dependencies in epel yet for rocm?
<@tflink:fedora.im>
18:11:15
at a minimum, anything depending on rocm should be rebuilt
<@carlwgeorge:fedora.im>
18:12:27
i see nothing yet depends on librocm-core.so, are there other ones i should look for?
<@tflink:fedora.im>
18:12:39
rocm-core is a weird case
<@carlwgeorge:fedora.im>
18:13:34
the main thing is enumerating this so we can make sure rocm-packagers-sig has all the access they need to do coordinated rebuilds
<@tflink:fedora.im>
18:13:51
libhsa-runtime64.so is a better library to look at
<@carlwgeorge:fedora.im>
18:14:27
looks like everything that requires that has rocm in the name, so relatively self-contained i guess
<@carlwgeorge:fedora.im>
18:14:48
by that i mean either subpackages or related packages the sig has access to
<@tflink:fedora.im>
18:15:00
I don't know how many of the rocm-using packages are in EPEL ATM
<@tflink:fedora.im>
18:15:34
blender, pytorch and llama.cpp are examples in Fedora
<@davide:cavalca.name>
18:15:42
My matrix server seems to have crapped out. Catching up on the log now.
<@tflink:fedora.im>
18:16:06
we effectively have the ability to rebuild pytorch and llama.cpp, we have a good relationship with the blender folks and that hasn't been a problem
<@davide:cavalca.name>
18:16:39
No objection from me, and +1 to what Carl said.
<@carlwgeorge:fedora.im>
18:16:47
sorry if i'm getting too much in the weeds, just thinking ahead to what this looks like in the future. it doesn't really change my opinion on this.
<@carlwgeorge:fedora.im>
18:17:31
i guess it does shape what the delay looks like between rawhide getting the latest major version and epel10 getting the same. in the email thread that was referenced as "Once 7.0 seems stable enough", but that is kinda vague...
<@tflink:fedora.im>
18:17:37
no worries, I'm happy to answer questions. especially in the name of avoiding pain in the future
<@tdawson:fedora.im>
18:18:41
Does anyone else have any questions for tflink ?
<@tflink:fedora.im>
18:18:44
the delay will depend on the magnitude of changes and what the other effects are. I don't know if we can quantify that with any certainty right now
<@carlwgeorge:fedora.im>
18:20:01
* epel10 gets new major version
<@carlwgeorge:fedora.im>
18:20:01
i.e. wait to put it into epel until it's at least in fedora branched to give it time to bake
<@carlwgeorge:fedora.im>
18:20:01
<@carlwgeorge:fedora.im>
18:20:01
* new epel10 branches with new major version
<@carlwgeorge:fedora.im>
18:20:01
* new fedora branches with new major version
<@carlwgeorge:fedora.im>
18:20:01
* rawhide gets new major version
<@carlwgeorge:fedora.im>
18:20:01
<@carlwgeorge:fedora.im>
18:20:01
how about this timeline:
<@tflink:fedora.im>
18:20:22
at a minimum, that's our plan
<@tflink:fedora.im>
18:20:50
we have some internal testing that is shaping up, the longer term plan is to wait until the internal SQA folks are happy before letting builds out of a side tag
<@carlwgeorge:fedora.im>
18:21:27
basically i'd like to avoid the appearance of epel10 getting too far ahead of stable fedora
<@carlwgeorge:fedora.im>
18:22:06
this timing could of course be revisited in the future if necessary
<@salimma:fedora.im>
18:22:12
!hi
<@zodbot:fedora.im>
18:22:14
Michel Lind (salimma) - he / him / his
<@tdawson:fedora.im>
18:22:36
Hi Michel Lind UTC
<@tflink:fedora.im>
18:22:37
so you'd like to add the restriction that epel10 doesn't have a higher version than the latest released fedora?
<@carlwgeorge:fedora.im>
18:23:11
i was thinking branched fedora, but essentially yeah
<@salimma:fedora.im>
18:23:26
why not rawhide? since epel10 targets stream
<@carlwgeorge:fedora.im>
18:23:50
i can live with 2 months of epel10 being ahead stable fedora if the same update is pending in fedora branched
<@carlwgeorge:fedora.im>
18:24:15
not sure i follow, rawhide would still get the update first
<@salimma:fedora.im>
18:24:23
oh, branched but not released yet... ok that makes sense
<@salimma:fedora.im>
18:24:35
no, I meant why not just say once it's in rawhide you can do it in epel
<@conan_kudo:matrix.org>
18:24:41
I think it probably makes sense that epel10 head and rawhide should at least match
<@conan_kudo:matrix.org>
18:25:00
I'm not sure it's strictly necessary to require waiting for it to show up in a branch
<@salimma:fedora.im>
18:25:02
if Fedora is branched already I think saying epel has to be behind is fine, but if it's like right now it seems a bit restrictive?
<@salimma:fedora.im>
18:25:11
there are a few months after a release is cut where there is no branched pre-release
<@carlwgeorge:fedora.im>
18:25:24
because then they could essentially happen at the same time, one after the other
<@carlwgeorge:fedora.im>
18:25:53
without that restriction then epel10 (consumed by centos) can be ~8 months ahead of stable fedora, and i don't like that
<@conan_kudo:matrix.org>
18:26:03
that already happens sometimes
<@tflink:fedora.im>
18:26:07
I'd prefer not to have exact restrictions like that in case we'd miss an EPEL minor release just because fedora hadn't been branched yet
<@conan_kudo:matrix.org>
18:26:33
admittedly not with epel usually... usually that's with the c10s branch and rawhide being in sync
<@tflink:fedora.im>
18:26:46
if it'd be possible to add some form of testing requirements, that would be better in my mind
<@carlwgeorge:fedora.im>
18:26:58
we can build in a buffer by allowing epel branched to do a major version update if the corresponding rhel hasn't been released yet
<@tflink:fedora.im>
18:27:08
but EPEL will never move faster than rawhide does - rawhide is the first distro that we update when a new ROCm release happens
<@conan_kudo:matrix.org>
18:27:12
tflink: are there tmt tests in the rocm stack yet?
<@nirik:matrix.scrye.com>
18:27:38
I don't know that we want to do a major upgrade in branched after beta, etc...
<@tflink:fedora.im>
18:27:54
not enough of them. it's on my todo list but until there is appropriate HW in Fedora CI, it has been a lower priority
<@tdawson:fedora.im>
18:27:55
I'm going to timebox this in 3 minutes.
<@nirik:matrix.scrye.com>
18:28:33
I think just saying land in rawhide first and be mindful about enough testing before pushing to branched/epel... I don't think we need to mircomanage it do we?
<@conan_kudo:matrix.org>
18:28:41
from my point of view, I trust that tflink is going to be responsible enough around the rocm stack that I'm fine with a rawhide == epel10 thing for the stack
<@conan_kudo:matrix.org>
18:28:59
hell, this is the most descriptive proposal we've ever gotten for an exception
<@conan_kudo:matrix.org>
18:29:11
it's clearly well thought out, and they're being extremely responsible
<@carlwgeorge:fedora.im>
18:29:27
it's not about trust, i'd just rather have a specific guideline for this for clarity
<@conan_kudo:matrix.org>
18:29:37
I mean, it's a _bit_ about trust
<@conan_kudo:matrix.org>
18:29:50
the character of the packagers matters when it comes to doing stuff like this
<@carlwgeorge:fedora.im>
18:29:59
especially with a sig involved where the membership can fluctuate
<@conan_kudo:matrix.org>
18:30:05
the main concern to me is reverse dependency tracking
<@conan_kudo:matrix.org>
18:30:18
I'd like to see some kind of codified process for that
<@conan_kudo:matrix.org>
18:30:23
beyond that, I have no issues
<@rcallicotte:fedora.im>
18:30:28
!hi
<@zodbot:fedora.im>
18:30:30
Robby Callicotte (rcallicotte) - he / him / his
<@tdawson:fedora.im>
18:30:33
OK, I'm timeboxing this. I don't think this discussion is changing anyone's minds.
<@tdawson:fedora.im>
18:30:37
Hi Robby Callicotte
<@carlwgeorge:fedora.im>
18:30:56
with the timeboxing are we just agreeing to defer the final vote a week?
<@tdawson:fedora.im>
18:31:06
Time for a vote. +1 the proposal passes, -1 it doesn't, 0 - neutral.
<@tdawson:fedora.im>
18:31:32
No, because you said this discussion wasn't changing your mind, you were just going into the weeds, and I agree with that statement.
<@carlwgeorge:fedora.im>
18:32:14
i'm overall for this but i would like the restriction of epel10 won't get ahead of fedora branched
<@conan_kudo:matrix.org>
18:32:15
+1 from me
<@rcallicotte:fedora.im>
18:32:23
+1
<@conan_kudo:matrix.org>
18:32:25
+1 from me (without carl's restriction)
<@tdawson:fedora.im>
18:32:33
+1 from me, as proposed, without any change.
<@nirik:matrix.scrye.com>
18:32:41
+1
<@davide:cavalca.name>
18:33:18
+1, I think this is likely fine, and we can always add restrictions down the road if things go south
<@dherrera:fedora.im>
18:34:23
Carl George: I agree that we could add a policy for these kinds of deployments in EPEL for the general case, but this is a request for an exception, so even if this passes, we can just take it into account for such policy
<@tdawson:fedora.im>
18:35:03
Carl George: You can give it a -1 for how it is proposed, but there isn't an EPEL policy stating that something can't be in rawhide and EPEL, and I feel that you are just adding extra burdon to someone who is trying to do the right thing.
<@conan_kudo:matrix.org>
18:35:26
tflink: I would generally like to see your group write up an SOP and maybe some scripts for reverse dependency tracking and rebuilding for your stack
<@conan_kudo:matrix.org>
18:35:42
I'm not making it a blocker for this exception but I think you're going to want to do this anyway
<@carlwgeorge:fedora.im>
18:36:00
your feeling is incorrect. i'm happy to see someone doing the right thing, but the details matter.
<@conan_kudo:matrix.org>
18:36:04
after all, the success case is that this is used by a bunch of things
<@tflink:fedora.im>
18:36:13
Sorry. My Internet chose a great time to die
<@conan_kudo:matrix.org>
18:36:42
and since our buildsystem can't do that kind of stuff for us, I'd like to see your sig have that stuff hammered out so we have greater confidence over the long term
<@carlwgeorge:fedora.im>
18:37:46
as a compromise, can we just approve the incompat update to version 7 in the epel10 branch, then vote on the long term policy in the future?
<@conan_kudo:matrix.org>
18:39:29
we could tentatively hold it based on how the upgrade to 7 goes
<@conan_kudo:matrix.org>
18:39:44
as in, the performance of this determines whether it goes into effect or not
<@carlwgeorge:fedora.im>
18:40:23
i like that, but i have no doubt it will go smooth enough to approve the long term plan. how it goes will shape those details of the long term plan.
<@conan_kudo:matrix.org>
18:40:37
I admit I'd like to see how it goes at least once and see a SOP written to link to the exception
<@conan_kudo:matrix.org>
18:41:14
back in the day, a SOP used to be required for these kinds of permanent exceptions
<@conan_kudo:matrix.org>
18:41:28
KDE even has one for its updates
<@conan_kudo:matrix.org>
18:42:08
(the KDE SOP is now encoded in scripts, but it used to be a document)
<@tflink:fedora.im>
18:43:52
if that's the direction you want to go, I'd appreciate some specific feedback about what is wanted. I've seen at least 3 different things
<@tflink:fedora.im>
18:44:07
some of which shouldn't be a problem, one might
<@conan_kudo:matrix.org>
18:44:57
* a lifecycle document
<@conan_kudo:matrix.org>
18:44:57
* update process document and/or scripts
<@conan_kudo:matrix.org>
18:44:57
from my side, I'd like to see three things:
<@conan_kudo:matrix.org>
18:44:57
<@conan_kudo:matrix.org>
18:44:57
* a documented method of tracking reverse dependencies
<@conan_kudo:matrix.org>
18:47:14
kde-update-scripts is our SOP
<@conan_kudo:matrix.org>
18:47:45
and we have a page on the KDE SIG wiki space: https://fedoraproject.org/wiki/SIGs/KDE/Update_policy
<@tdawson:fedora.im>
18:48:11
The SIG does, yes. KDE itself still releases plasma, gears and apps at different release cycles though ...
<@conan_kudo:matrix.org>
18:48:29
and we even have an EPEL policy: https://fedoraproject.org/wiki/SIGs/KDE/EPEL
<@farchord:fedora.im>
18:48:35
I'd say worry about the things you can change lol
<@tdawson:fedora.im>
18:48:49
Anyway, so ... I feel like we have a fillibuster. Let's close this up.
<@carlwgeorge:fedora.im>
18:48:56
can we just vote on the one time rocm 7 update in epel10 for now?
<@carlwgeorge:fedora.im>
18:49:22
that will unblock work while the long term plan is sorted out
<@tdawson:fedora.im>
18:49:52
I'm good with that ... but next week please say something during the week and don't wait until the meeting.
<@tdawson:fedora.im>
18:50:48
All in favor of the ROCM 7 update, but not the permanent exception. +1 for -1 against.
<@carlwgeorge:fedora.im>
18:50:53
+1
<@tdawson:fedora.im>
18:50:58
+1
<@rcallicotte:fedora.im>
18:51:09
+1
<@nirik:matrix.scrye.com>
18:51:42
+1 to both, but sure.
<@tflink:fedora.im>
18:51:49
to be clear, you mean one update to rocm7 (probably 7.1 or 7.2 at this point) and not through the rocm7 lifecycle, right?
<@conan_kudo:matrix.org>
18:52:08
+1 to both
<@carlwgeorge:fedora.im>
18:52:19
if 7.1 or 7.2 are generally compatible with 7.0, then no approval is needed
<@carlwgeorge:fedora.im>
18:52:48
if they're like new major versions and not semantic at all, then it's more complicated
<@davide:cavalca.name>
18:53:18
+1
<@tflink:fedora.im>
18:53:55
they _should_ be generally compatible but I'm not sure it matters a ton. rocm8 may arrive before the next epel branch, anyways
<@tflink:fedora.im>
18:54:13
either way, we'll keep the lines of communication open. we're not trying to work around anything
<@tdawson:fedora.im>
18:54:29
!agreed Proposal: Allow Incompatible Updates 7 for ROCm in EPEL10 passed +1(6) -1(0) 0 (1) - 1 person missing
<@carlwgeorge:fedora.im>
18:54:32
we appreciate the work you've already put into this
<@conan_kudo:matrix.org>
18:54:56
having the procedures worked out will make things easier for a permanent exception later
<@tflink:fedora.im>
18:55:22
ok, thanks for the feedback and taking the time to deal with this
<@carlwgeorge:fedora.im>
18:55:41
thanks for being available to answer questions
<@tdawson:fedora.im>
18:56:12
Robby Callicotte: Did you have an update on your pull request for issue/351 ? It's ok if you don't, but I wanted to give you time if you did.
<@rcallicotte:fedora.im>
18:56:37
no update yet. sorry
<@tdawson:fedora.im>
18:56:44
Not a problem.
<@tdawson:fedora.im>
18:56:51
!topic General Issues / Open Floor
<@tdawson:fedora.im>
18:57:08
We've got a couple minutes left, does anyone have anything for Open Floor?
<@tdawson:fedora.im>
18:58:25
I'll take that as a no ... or that Matrix is glitching again :) ... either wait it looks like we are out of time.
<@rcallicotte:fedora.im>
18:58:49
It looks like diego was typing?
<@dherrera:fedora.im>
18:59:01
yea, something short
<@tdawson:fedora.im>
18:59:06
Diego Herrera: Go for it.
<@dherrera:fedora.im>
18:59:34
Just wanted to mention that the docs migration into forgejo is still in progress :)
<@tdawson:fedora.im>
19:00:19
Cool. And thank you for doing that ... well you, and anyone else helping.
<@dherrera:fedora.im>
19:00:39
there are some hicups in regard to migrating the PRs, but it's a work in progress ;)
<@dherrera:fedora.im>
19:00:47
but that's it for now
<@tdawson:fedora.im>
19:01:01
Thank you for letting us know.
<@tdawson:fedora.im>
19:01:44
Now we really are out of time. Thank you all for the good discussions. And thank you to all the visitors as well.
<@tdawson:fedora.im>
19:02:04
I appreciate all that you all do for EPEL and it's community.
<@tdawson:fedora.im>
19:02:12
I'll talk to you next week, if not sooner.
<@rcallicotte:fedora.im>
19:02:16
Bye Troy
<@tdawson:fedora.im>
19:02:37
!endmeeting