19:59:47 <tdawson> #startmeeting EPEL (2023-07-05)
19:59:47 <zodbot> Meeting started Wed Jul  5 19:59:47 2023 UTC.
19:59:47 <zodbot> This meeting is logged and archived in a public location.
19:59:47 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:59:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:59:47 <zodbot> The meeting name has been set to 'epel_(2023-07-05)'
19:59:48 <tdawson> #meetingname epel
19:59:48 <zodbot> The meeting name has been set to 'epel'
19:59:50 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
19:59:50 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
19:59:51 <tdawson> #topic aloha
19:59:59 <rcallicotte> .hi
20:00:02 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:00:12 <tdawson> Hi rcallicotte
20:00:21 <davide> .hello dcavalca
20:00:23 <jonathanspw> .hi
20:00:23 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
20:00:26 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
20:00:31 <tdawson> Hello davide
20:00:33 <tdawson> Hi jonathanspw
20:00:40 <michel-slm> .hello salimma
20:00:43 <zodbot> michel-slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:00:45 <nirik> morning
20:00:49 <dherrera> .hi
20:00:51 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:01:20 <tdawson> Morning nirik
20:01:22 <tdawson> Hi dherrera
20:01:34 <neil> o/
20:01:35 <neil> .hi
20:01:37 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:01:51 <carlwgeorge> .hi
20:01:53 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:01:55 <smooge> hello
20:02:18 <tdawson> Hi neil and carlwgeorge
20:02:21 <tdawson> Hello smooge
20:04:01 <Eighth_Doctor> .hello ngompa
20:04:03 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:04:17 <tdawson> Hello Eighth_Doctor
20:04:57 <tdawson> #topic End Of Life (EOL)
20:04:59 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:05:00 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:05:02 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:05:14 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:15 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:43 <tdawson> Looks like we have three issues this week, let's go oldest to latest
20:05:56 <tdawson> .epel 230
20:05:57 <zodbot> tdawson: Issue #230: old epel7/8 updates in testing - epel - Pagure.io - https://pagure.io/epel/issue/230
20:06:17 <tdawson> dherrera: Do you have a status update for us this week?
20:06:51 <dherrera> I can talk about this one :) I opened a ticket to retire the listed packages and that it's already processed
20:06:52 <smooge> they just updated the ticket
20:07:36 <tdawson> Oh cool.
20:08:00 <tdawson> So, it's done, very nice.
20:08:04 <dherrera> since we updated the policy, we can still just report the rest of the stale updates, but besides that, I think that it's enough as it is
20:08:56 <tdawson> Thank you very much for all your work on this.
20:09:03 <carlwgeorge> very nice
20:09:07 <carlwgeorge> dherrera++
20:09:25 <neil> great work, thank you dherrera
20:09:30 <smooge> dherrera++
20:09:32 <tdawson> dherrera++
20:09:34 <neil> dherrera++
20:09:34 <zodbot> neil: Karma for dherrera changed to 5 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:10:02 <tdawson> Well, at least someone was able to add to his cookie count. :)
20:10:17 <tdawson> dherrera: Anything else before we move on?
20:10:34 <nirik> dherrera++
20:10:34 <zodbot> nirik: Karma for dherrera changed to 6 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:10:48 <dherrera> not from me at least :)
20:11:09 <tdawson> Anything from anyone else?
20:11:50 <tdawson> .epel 236
20:11:51 <zodbot> tdawson: Issue #236: update rocksdb to newer version in el8 and el9 - epel - Pagure.io - https://pagure.io/epel/issue/236
20:12:10 <tdawson> We talked about this last week, and wanted to know more from the person filing it.
20:12:42 <carlwgeorge> doesn't seem like a very clear answer in the issue
20:13:03 <davide> fwiw I help maintain rocksdb in EPEL and was the one suggesting filing this issue
20:13:04 <Eighth_Doctor> I don't think there's a problem letting it get upgraded
20:13:24 <davide> I'm personally fine with updating it but wanted to get it on the record (and see if we needed to clarify anything policy-wise)
20:13:55 <carlwgeorge> we could have it follow the incompat process announcements for good measure, just in case out of an abundance of caution
20:14:20 <nirik> I'm still confused as to what the incompatibilities are? is it abi? api? need to dump/restore dbs?
20:14:43 <carlwgeorge> those would be the details i'm hoping would be gathered for said announcements
20:14:45 <tdawson> I guess my biggest question is the last one I put.  If you update rocksdb to a new version.  Do you have to regernatere and/or convert their database.
20:15:28 <Eighth_Doctor> from what I could tell, RocksDB uses a versioned data format
20:15:38 <nirik> there's a upgrade guide... which ends at version 5. ;)
20:15:45 <tdawson> :)
20:16:02 <davide> yeah it's supposed to be backwards and forwards compatible for the most part
20:16:31 <Eighth_Doctor> that was what I gathered too
20:16:43 <Eighth_Doctor> I'm reasonably okay with not invoking the incompat process here
20:17:04 <tdawson> If that's the case, then I'm ok.
20:17:52 <nirik> oh, thats the wrong repo I was looking at...
20:17:56 <tdawson> In short, if an end user and/or package maintainer doesn't notice anything when it's updated, to me it sounds fine.
20:18:20 <nirik> https://github.com/facebook/rocksdb/wiki/RocksDB-Compatibility-Between-Different-Releases
20:19:09 <Eighth_Doctor> their statements are hell of a lot stronger than most other projects with such compat guarantees
20:19:16 <Eighth_Doctor> even glibc's guarantee isn't this strong
20:19:50 <nirik> yeah, looks pretty strong to me too.
20:20:27 <michel-slm> and the issue is to update them in both supported releases, so that's great. updating el9 but not el8 might cause issues with newly created databases
20:20:30 <smooge> so this decision looks rock solid then
20:20:42 <Eighth_Doctor> they treat back/forward compat issues (if no incompat features are used) as a bug and apparently test it regularly
20:20:48 <tdawson> *laughs*
20:21:01 <Eighth_Doctor> rock solid indeed :)
20:21:29 <smooge> so do we need to bring this to a vote? I think everyone has made their sediments clear
20:21:37 <Eighth_Doctor> lol
20:21:56 <Eighth_Doctor> nah, I think we've crystallized it
20:21:59 <tdawson> Let's vote, so it's official.
20:22:09 <tdawson> Oh ... the puns
20:22:11 <Eighth_Doctor> or vote, sure
20:22:13 <smooge> +1 to polish this off
20:22:27 <carlwgeorge> without specific incompatibilities i don't think we need a vote
20:22:34 <nirik> rock on. +1
20:22:34 <michel-slm> +1
20:22:38 <jonathanspw> abstain
20:22:39 <carlwgeorge> it would fall back to maintainer discretion i think
20:22:43 <dherrera> +1 looks rock solid
20:22:46 <tdawson> +1
20:22:47 <nirik> That too
20:22:50 <Eighth_Doctor> granite that we have a solid permissionless case +1
20:23:14 <carlwgeorge> hol up
20:23:16 <tdawson> carlwgeorge: Although that is true, but since the maintainer was asking for our opinion, I figure it's best we give one.
20:23:21 <carlwgeorge> there is an soname involved
20:23:29 <carlwgeorge> librocksdb.so.6.26
20:24:00 <Eighth_Doctor> blech
20:24:12 * Eighth_Doctor wishes the library was in a subpackage
20:24:30 <Eighth_Doctor> I would have noticed it if it was
20:24:44 <Eighth_Doctor> anyway, so we do need to give an incompat grant because of the soname
20:24:45 <carlwgeorge> doesn't seem anything in epel8 or epel9 requires it, but in theory a 3rd party could have built against it
20:24:45 <neil> good catch carlwgeorge. also whyyy
20:25:02 <Eighth_Doctor> but it looks like with rocksdb 8 has major version soname instead of major minor
20:25:09 <Eighth_Doctor> so it's less bad after this rebase
20:25:28 <tdawson> I've checked epel8 and epel9 to make sure nothing relies on it also.
20:25:37 <carlwgeorge> to be clear i'm not opposed to this happening, just with the soname change it needs to be an incompat process
20:26:02 <Eighth_Doctor> we could request an incompat upgrade announcement and be done with it
20:26:05 <nirik> sure, ok.
20:26:10 <carlwgeorge> that way if some third party complains that they were building against it we can point to a mailing list post
20:27:25 <carlwgeorge> Eighth_Doctor: on noticing, it was the -devel package that gave it away for me
20:27:36 <Eighth_Doctor> ah
20:27:46 <Eighth_Doctor> I zero in on -libs or libfoo packages
20:27:52 <Eighth_Doctor> but yeah -devel makes sense
20:29:32 <smooge> ok +1 to incompat process and be done
20:30:34 <Eighth_Doctor> we done marbling on this now?
20:30:52 <dherrera> sure, incompat seems reasonable
20:31:03 <michel-slm> same here
20:31:30 <tdawson> I'm ok with them following the incompatable process.
20:32:02 <Eighth_Doctor> so to chalk it up: 1) we're okay with this, provided 2) they follow the incompat process whenever a soname bump occurs, otherwise 3) permission not required given the database stability and compatibility guarantees
20:32:45 <michel-slm> +1
20:32:45 <carlwgeorge> that sounds like a perfect reply to the issue
20:32:58 <tdawson> Eighth_Doctor: Does 3 mean - if the soname doesn't change, they can do an update without doing the process?
20:33:09 <Eighth_Doctor> yes
20:33:19 <tdawson> Then  yep, +1 from me.
20:33:55 <nirik> +1
20:34:00 <dherrera> +1
20:34:06 <carlwgeorge> +1
20:34:23 <davide> +1
20:34:58 <tdawson> Looks like 7 for, no against.   Who wants to do the writeup?
20:35:27 <carlwgeorge> if i do it i'm just gonna take Eighth_Doctor's comment and add the link to the incompat process
20:35:45 <tdawson> carlwgeorge: I'm fine with that.
20:35:46 <carlwgeorge> which i'm happy to do, so sure i'll do it
20:35:51 <Eighth_Doctor> fine with me
20:36:04 <carlwgeorge> unless Eighth_Doctor wants to just write it directly
20:36:11 <Eighth_Doctor> I can do that
20:36:20 <Eighth_Doctor> just need a link for the incompat process
20:36:25 <carlwgeorge> no need for plagiarism
20:36:37 <carlwgeorge> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
20:37:22 <michel-slm> with that done and dusted, I need to run early, see you all later
20:37:40 <tdawson> #info .236 - Voted 7 for, 0 against - We're ok with this if they follow the incompat process when there is a soname bump.  If there is not a soname bump, they can do a regular update.
20:37:53 <tdawson> By michel-slm
20:38:26 <tdawson> Do we want to do the next issue, or push it off a week or two?
20:38:42 <smooge> what is the next issue?
20:38:48 <tdawson> epel .238
20:38:56 <tdawson> .epel 238
20:38:57 <zodbot> tdawson: Issue #238: EPEL 7 EOL - could/should we extend it? - epel - Pagure.io - https://pagure.io/epel/issue/238
20:39:07 <smooge> well I have said my piece on that.
20:39:39 <tdawson> And I appreciate it too.
20:39:53 <Eighth_Doctor> have we ever extended EPEL for ELS?
20:39:55 <tdawson> I was sorta hoping someone would say "No, we can't do it."
20:39:56 <smooge> no
20:39:59 <davide> is someone volunteering to do the actual work needed to keep epel7 alive?
20:40:05 <smooge> I think we can't do it
20:40:16 <Eighth_Doctor> and is ELS even available to RHEL Developer sub? I know EUS is, I'm not sure if ELS is...
20:40:21 <smooge> no
20:40:28 <carlwgeorge> my preference would be not to
20:40:34 <Eighth_Doctor> then the answer is "no"
20:40:49 <Eighth_Doctor> if there's no community path here, then there's no point in the question, we're not doing it
20:40:55 <carlwgeorge> that said, if a lot of maintainers are like "yes i want this" then i would be open to reconsidering
20:41:08 <tdawson> I brought the ticket up, so that a year or two from now, we could point to the ticket and tell people "we investigated it, here is our report and answer"
20:41:10 <carlwgeorge> just leaving the branches active with no activity doesn't help anyone
20:41:17 <nirik> yeah, I don't think I have any desire to do this.
20:41:29 <Eighth_Doctor> I don't think I would be open to this at all given the current situation of how ELS works
20:41:40 <Eighth_Doctor> and frankly, I'd rather people moved to newer RHEL versions
20:41:47 <carlwgeorge> if you're using els, you already screwed up with planning
20:41:48 <neil> Eighth_Doctor++
20:41:55 <neil> carlwgeorge++
20:41:55 <tdawson> :)
20:41:56 <smooge> I have tried to do this in the past due to 'consumer demand'. It is fairly impossible to do
20:42:03 <Eighth_Doctor> carlwgeorge++
20:42:03 <zodbot> Eighth_Doctor: Karma for carlwgeorge changed to 3 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:42:23 <neil> If someone wants to pay me--personally--to update EL7 EPEL packages for them. I'll gladly make them give me bags of gold.
20:42:33 <smooge> that was the problem.
20:42:34 <Eighth_Doctor> same
20:42:51 <Eighth_Doctor> give me bags of gold and I'll run my own infra to do it
20:43:11 <Eighth_Doctor> it's not like I couldn't, but ELS support provides no community benefit
20:43:12 <smooge> no gold. no silver. no copper. just 'why isn't it fixed already!'
20:43:26 <tdawson> So, it sounds like "Can we"  The answer is "not with our current infrastructure.  It would require some work"   and "Should we" it's sounding like a pretty unanoumous "No"
20:43:26 <Eighth_Doctor> then no EPEL-ELS
20:43:29 <carlwgeorge> tdawson: fwiw i'm happy you brought it up so we can have a decision to point to
20:43:35 <Eighth_Doctor> I'd do soup nazi in here, but it doesn't translate well
20:43:51 <davide> IMO this is less of an infrastructure issue and more of a manpower one (though infra is definitely a concern too)
20:44:00 <carlwgeorge> yeah i don't know what the infra problem would be
20:44:02 <smooge> davide: no it is an infrastructure issue also
20:44:13 <carlwgeorge> i guess disk space?
20:44:25 <neil> smooge's point in the ticket is this can leak el7 els updates
20:44:34 <neil> or otherwise make it impossible to build w/ mock, locally
20:44:43 <Eighth_Doctor> yup
20:44:44 <davide> oh I see
20:44:45 <smooge> 3 items: 1. Fedora Infra getting access to ELS bits. 2. mock losing ability to do older chroots over ime.
20:44:47 <neil> (correct me if I'm wrong, smooge)
20:44:53 <davide> yeah then I don't see this being feasible at all
20:44:54 <Eighth_Doctor> remember that if RHEL Dev Sub doesn't have it, nobody can do anything
20:45:18 <smooge> 3. we need to maintain other tooling to keep el7 in bodhi and other items
20:45:20 <Eighth_Doctor> I'm not willing to entertain anything the community can't access for free
20:45:30 * nirik will just say again that he has no desire to do this.
20:45:53 <Eighth_Doctor> separately from my complete lack of desire to reward people for poor planning for no money
20:46:03 <Eighth_Doctor> there's just no technical feasibility for it
20:46:30 <davide> yeah, with my packager hat on -- I have no interest in maintaining epel7 branches beyond the eol
20:46:45 <carlwgeorge> epel7 "alive" with no activity isn't functionally different from the epel7 archive
20:46:50 <smooge> so what is the proposal to vote on
20:47:04 <Eighth_Doctor> I barely have interest in epel7 now
20:47:08 <carlwgeorge> same
20:47:08 <tdawson> *laughs*
20:47:13 <jonathanspw> same
20:47:31 <Eighth_Doctor> we got, what, 11 months till RHEL 7 main lifecycle ends?
20:47:43 <jonathanspw> ~yep
20:48:09 <Eighth_Doctor> and EPEL 8 is going to be in a weird situation come next year
20:48:12 <gotmax> I'm also -1 to ELS. There will be difficulties with building locally, and I don't want to support epel7 branches any longer.
20:48:14 <smooge> proposal: The EPEL Steering Committee does not see maintaining EPEL-7 after the end of usual updates possible or desirable by its packagers
20:48:24 <Eighth_Doctor> smooge: +1
20:48:25 <jonathanspw> +1
20:48:25 <gotmax> +1
20:48:33 <neil> +1 (if I can)
20:48:40 <nirik> +1
20:48:41 <smooge> you showed up, you can vote
20:48:46 <tdawson> +1
20:48:48 <dherrera> +1
20:49:06 <neil> smooge: thanks. i will try and remember that heh
20:49:08 <smooge> carlwgeorge:
20:49:09 <carlwgeorge> +1
20:49:29 <smooge> tdawson: call the vote
20:49:30 <carlwgeorge> neil: our voting rules are...fuzzy
20:49:57 <davide> +1
20:50:12 <tdawson> #info 9 votes for, 0 votes against : The EPEL Steering Committee does not see maintaining EPEL-7 after the end of usual updates possible or desirable by its packagers
20:50:56 <smooge> see tdawson we got through that without too much problems :)
20:51:00 <tdawson> Thanks all, I'll put that in the issue and close it.
20:51:03 <tdawson> Yep.
20:51:16 <tdawson> #topic Old Business
20:51:37 <tdawson> Did anyone want to bring up any Old Business?
20:51:57 <carlwgeorge> surely that's enough serious talk for one meeting :P
20:52:07 <smooge> I am all out of jokes
20:52:20 <tdawson> *laughs* ... Yep, that's sorta how I feel. :)
20:52:29 <tdawson> #topic General Issues / Open Floor
20:52:33 <Eighth_Doctor> it's a clean slate now
20:53:04 <davide> I have an easy one: just wanted to double check that https://bugzilla.redhat.com/show_bug.cgi?id=2218681 is fine for inclusion in EPEL
20:53:12 <davide> as it was retired in c9s afaict
20:53:43 <Eighth_Doctor> yeah, should be gravy
20:53:54 <Eighth_Doctor> we have other packages in EPEL as a consequence of that
20:53:56 <smooge> should be ok.
20:54:00 <Eighth_Doctor> of similar conditions, I mean
20:54:11 <Eighth_Doctor> like asciidoctor
20:54:13 <davide> thanks
20:54:23 <davide> on a slightly more complicated note, https://bugzilla.redhat.com/show_bug.cgi?id=2121845 ended up a bit of a rollercoaster
20:54:36 <tdawson> Just double checked, yep it's fine ... for the first one.
20:55:34 <carlwgeorge> yeah on the second i was excited when it was merged, just to later be disappointed
20:55:36 <smooge> crap I need to head out early. hope you all have a good week
20:55:41 <carlwgeorge> later smooge
20:55:44 <Eighth_Doctor> that one hurt
20:55:52 <tdawson> smooge: Bye, thanks for the discussions.
20:56:00 <Eighth_Doctor> because I was guiding jonathanspw on contributing to CentOS Stream
20:56:13 <Eighth_Doctor> having your first contribution yoinked sucks
20:56:17 <carlwgeorge> i'll admit i don't fully understand the "it's in ha" justification to not have this
20:56:30 <jonathanspw> davide: yoink yoink
20:56:35 <carlwgeorge> if it's a runtime thing then maybe appstream works better?
20:56:50 <Eighth_Doctor> is the main library in AppStream or HA?
20:56:51 <carlwgeorge> being in appstream would satisfy ha and epel
20:57:08 <jonathanspw> should i redo the MR with appstream?
20:57:16 <carlwgeorge> i would talk to josh about it first
20:57:19 <Eighth_Doctor> no
20:57:22 <Eighth_Doctor> hold up
20:57:27 <Eighth_Doctor> libqb is in AppStream
20:57:32 <jonathanspw> not -devel
20:57:33 <Eighth_Doctor> what the heck?
20:57:40 <Eighth_Doctor> I'm confused now
20:57:48 <carlwgeorge> this was an unshipped devel thing
20:58:00 <Eighth_Doctor> yes, I know
20:58:01 <gotmax> libqb is in appstream, but the devel subpackage is in HA
20:58:09 <carlwgeorge> well, not shipped in crb but apparently in ha, which i don't get
20:58:14 <Eighth_Doctor> but if libqb is in AppStream, then I don't understand restricting the devel package to HA
20:58:30 <nirik> 🔄
20:58:35 <jonathanspw> well there's also libqb-devel provided by libqb-epel
20:58:37 <Eighth_Doctor> I think this warrants a discussion with the RHEL people, because this is confusing me
20:58:49 <Eighth_Doctor> yes that was the workaround
20:59:17 <tdawson> Ya ... what is the point of putting a -devel package in HA ... that makes my head hurt.
20:59:19 <carlwgeorge> jonathanspw: perhaps reply to the bug and ask for more clarification, and suggest appstream instead and see what josh says
20:59:31 <jonathanspw> 👍
20:59:41 <carlwgeorge> a second no leaves us in the same place we are now, so no harm in asking
21:00:08 <tdawson> Looks like our time is up.  It's been a good meeting.
21:00:18 <Eighth_Doctor> yup
21:00:32 <tdawson> Thank ya'll for being here, and the very good discussions today.  We actually got three issues taken care of.  I'm impressed.
21:00:47 <tdawson> Talk to you next week.
21:00:47 <carlwgeorge> like a fossil impression?
21:00:59 <carlwgeorge> sorry had to get in my own rock joke before we closed
21:01:03 <tdawson> ohh ... the puns ... the puns ...
21:01:14 <tdawson> #endmeeting