20:00:11 <tdawson> #startmeeting EPEL (2023-05-31)
20:00:11 <zodbot> Meeting started Wed May 31 20:00:11 2023 UTC.
20:00:11 <zodbot> This meeting is logged and archived in a public location.
20:00:11 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:11 <zodbot> The meeting name has been set to 'epel_(2023-05-31)'
20:00:12 <tdawson> #meetingname epel
20:00:12 <zodbot> The meeting name has been set to 'epel'
20:00:14 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
20:00:14 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
20:00:15 <tdawson> #topic aloha
20:00:16 <rsc> .hello robert
20:00:18 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:00:21 <jonathanspw> .hi
20:00:21 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
20:00:22 <tdawson> Hello rsc
20:00:25 <tdawson> Hi jonathanspw
20:00:29 <jonathanspw> howdy tdawson
20:00:32 <dherrera> .hi
20:00:33 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:00:41 <tdawson> Hi dherrera
20:01:06 <carlwgeorge> .hi
20:01:07 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:01:22 <tdawson> Hi carlwgeorge
20:01:24 <nirik> morning
20:01:42 <tdawson> Morning nirik
20:02:08 <davide> .hello dcavalca
20:02:09 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
20:02:21 <tdawson> Hello davide
20:03:19 <tdawson> michel said he wouldn't be here until about 20 after, if he's lucky
20:05:03 <tdawson> #topic End Of Life (EOL)
20:05:04 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:05:05 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:05:07 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:05:16 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:18 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:35 <tdawson> Looks like we have two open issues currently.
20:05:54 <tdawson> .epel 227
20:05:55 <zodbot> tdawson: Issue #227: Modify incompatible upgrades policy to have fast-track for security updates - epel - Pagure.io - https://pagure.io/epel/issue/227
20:06:16 <tdawson> I just barely got my pull request made a couple hours ago
20:06:19 <rcallicotte> .hi
20:06:20 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:06:25 <tdawson> So I don't expect us to talk about it this week.
20:06:28 <tdawson> Hi rcallicotte
20:06:40 * rcallicotte waves
20:07:05 <tdawson> But, for next week, here is the link - https://pagure.io/epel/pull-request/231
20:07:16 <smooge> hello
20:07:20 <tdawson> Hello smooge
20:07:58 <tdawson> Feel free to disagree with what I wrote, reword things, whatever.  It's a first pass at things.  And who knows, maybe everyone will agree with it, that would be good too.
20:08:20 <tdawson> #info Pull request with first draft of policy change - https://pagure.io/epel/pull-request/231
20:08:46 <tdawson> Any questions before I move on?
20:09:25 <smooge> nope looks good for next week
20:09:36 <tdawson> .epel 230
20:09:37 <zodbot> tdawson: Issue #230: old epel7/8 updates in testing - epel - Pagure.io - https://pagure.io/epel/issue/230
20:09:37 <carlwgeorge> i've got thoughts but i'll leave them as pr comments
20:10:05 <davide> this seems generally ok to me
20:10:09 <tdawson> This is concerning old updates in testing ... nirik would you like to elaborate?
20:10:15 <nirik> This was mentioned on the devel list, so I thought I would bring it up here.
20:10:33 <nirik> there are about 150 epel7/8 updates filed before this year.
20:10:40 <nirik> still in testing
20:11:16 <nirik> many of them just don't have 'stable by time' set... so they just sit in testing. Others have some -1's on them that prevented them from going stable, that may or may not already be fixed/dealt with
20:11:23 <tdawson> I know a year or two ago I did a cleanup ... maybe I wasn't very good at removing them, or your search is better than mine was.
20:11:41 <nirik> these may be from after the last cleanup
20:11:59 <nirik> anyhow, do we want to do anything about it? perhaps we don't?
20:12:08 <carlwgeorge> hard to prescribe anything as a blanket answer, seems more like a tedious case by case is needed
20:12:23 <tdawson> Most of them are for epel7 ... so that would clean things up. :)
20:12:40 <nirik> well, we could spam them all with a comment asking maintainers to push to stable or unpush?
20:12:47 <carlwgeorge> we also don't have to handle them all at once, so we could start with the oldest and work our way forward as people have time
20:13:01 <nirik> sure, those are all valid options too.
20:13:40 <nirik> I guess we could also start a thread on the list?
20:14:04 <nirik> or discourse
20:14:06 <carlwgeorge> yeah with a cc to all the <pkg>-maintainer@fpo.org emails
20:14:07 <tdawson> I seem to remember spamming all the ones I looked at last time ... so if any of them have my previous ping ... I think those would be good candidates for being taken down.
20:14:45 <carlwgeorge> if we do a mass comment it should probably include clear instructions of what happens next, i.e. reply/resolve by $date or this will be unpushed
20:15:16 <Eighth_Doctor> .hello ngompa
20:15:17 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:15:22 <tdawson> Hello Eighth_Doctor
20:15:37 <Eighth_Doctor> just got done with dinner :)
20:15:51 * Eighth_Doctor is still in Germany one last day, will be flying home tomorrow
20:16:10 <nirik> or... perhaps a longer term way to deal with this is to adjust bodhi... have some max time in testing or something.
20:16:15 <nirik> hey Conan Kudo
20:16:32 <tdawson> nirik: If that is possible, that would be nice.
20:16:55 <Eighth_Doctor> we should not allow updates to hang around in testing no longer than a month
20:17:03 <michel> .hello salimma
20:17:05 <Eighth_Doctor> if nobody says anything and they're still around, push them to stable
20:17:06 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:17:09 <nirik> well, it's all software, so it's possible... but of course someone would need to implement it.
20:17:21 <tdawson> I don't want to be too strict, a month is waaayyyyy too short.  But a year is very long.
20:17:25 * michel still not here. At daycare but kid is still eating so I don't want to barge in 😅
20:17:35 <Eighth_Doctor> tdawson: well our default is 1 week
20:17:36 <smooge> i would go with 6 months
20:17:41 <Eighth_Doctor> so 4x that is overkill IMO
20:18:06 <Eighth_Doctor> six months is right in the margin of broken
20:18:17 <Eighth_Doctor> because of RHEL minor version rebases
20:18:18 <smooge> Eighth_Doctor: you really don't spend a lot of time with Enterprise people :).. it takes a month to get the paperwork filled to just look at a package for an update
20:18:21 <tdawson> Eighth_Doctor: If you are waiting for a dependency you didn't know about until things hit testing ... it often takes more than a month to get that dependency.
20:18:29 <carlwgeorge> i agree with smooge, 6 months sounds like a good max.  there are use cases where it makes sense to leave packages in testing for an extended period of time.
20:18:37 <nirik> there might be cases where you want things to stay in testing for a while to get more feedback, but yeah, after a point it's not helping anyone to keep it from stable
20:18:44 <yselkowitz[m]> 3-4 months?
20:18:48 <smooge> and yes I know you spend a lot of time with enterprise :)
20:18:52 <Eighth_Doctor> I don't see a good reason to let it sit for six months
20:19:01 <tdawson> Eighth_Doctor: What about my reason?
20:19:17 <tdawson> Well ... ok ... six months is a long time, I would unpush way before that.
20:19:34 <Eighth_Doctor> tdawson: between buildroot overrides and side tags, nobody should use that as a valid reason anymore
20:19:38 <nirik> The oldest one is 7 years old. ;)
20:19:47 <yselkowitz[m]> yikes
20:19:55 <Eighth_Doctor> god in heaven
20:20:05 <tdawson> Eighth_Doctor: REALLY???  how many KDE issues have I had where I had no idea we have a new dependency until it hits -testing.
20:20:07 <nirik> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a5199f34b3
20:20:33 <Eighth_Doctor> tdawson: that's because EPEL lacks the install checks Fedora has
20:20:37 <smooge> oh I think that one is 'stuck' for reasons.
20:20:39 <Eighth_Doctor> we really need that fixed
20:20:47 <tdawson> Eighth_Doctor: And ... we're talking about EPEL, not Fedora.
20:21:03 <Eighth_Doctor> tdawson: yes, but the infrastructure is already there, just not used for EPEL
20:21:14 <carlwgeorge> regardless of these details, cleaning up what we have now probably shouldn't wait for a new bodhi feature
20:21:20 <nirik> anyhow, we don't have to decide anything today... I just wanted to bring it up. If folks think of concrete proposals we can discuss and see if we want to decide on some
20:21:34 <carlwgeorge> thanks for bringing it up nirik
20:21:34 <Eighth_Doctor> the existing backlog should be cleared out somehow, of course
20:21:40 <Eighth_Doctor> either via pushing or unpushing or something
20:21:56 <Eighth_Doctor> but we also should look to reduce the reasons updates hang around in EPEL testing forever
20:22:01 <tdawson> Yep ... there are plenty over a year old that I think we all agree is way too long.
20:22:12 <tdawson> Totally agree with that.
20:22:35 <Eighth_Doctor> we should also "port over" checks from Fedora to EPEL because EPEL updates are unexpectedly broken at just the wrong time
20:22:42 <Eighth_Doctor> there's no reason we should be in such a state
20:23:09 <carlwgeorge> just spitballing for the bodhi feature approach...if the maintainer doesn't check stable by time, send nag emails once a month for everything older than a month
20:23:18 <carlwgeorge> rather than setting a hard limit to unpush
20:23:34 <Eighth_Doctor> at the minimum, that would probably be useful
20:23:46 <Eighth_Doctor> though wouldn't the bodhi UI show those when you visit them too?
20:23:46 <nirik> yeah, that could be useful indeed.
20:23:55 <tdawson> I agree
20:24:07 <Eighth_Doctor> like unless you just have piles of updates, it's hard to miss
20:24:52 <nirik> Not sure, I don't usually have piles...
20:24:53 <carlwgeorge> i'm not sure if these are publicly viewable, but the osci has open rfes for running rpminspect and install checks on epel updates, see https://issues.redhat.com/browse/OSCI-3777 and https://issues.redhat.com/browse/OSCI-3778
20:25:11 <carlwgeorge> *the osci team
20:25:44 <tdawson> I've had one or two that slipped by because something turned off the auto-karma and I didn't notice until I was logged into bodhi ... so I wouldn't mind if one of mine hit two weeks and I got a nag email.
20:25:51 <Eighth_Doctor> they are not publicly viewable, carlwgeorge
20:26:17 <Eighth_Doctor> I can't view them from my personal RHJira/JBJira account
20:26:21 <neil> .hi
20:26:22 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:26:26 <tdawson> Hi neil
20:27:27 <Eighth_Doctor> tdawson: that's fair, I've had that happen too
20:27:38 <neil> heya tdawson
20:27:49 <tdawson> We got a little sidetracked, but in a good way.  Let me summarize if I can.
20:28:54 <tdawson> For the current large batch of old packages in testing.  We'll (members of the committee that have some time) start going through them a batch at a time.  Possible sending an initial nag email to them all.
20:29:15 <tdawson> For the future, we want to look at something in bodhi that will automatically send nag emails at some interval.
20:29:48 <nirik> when we go thru them... what do we do? just add a comment? karma?
20:29:55 <tdawson> Also for the future, look into getting better (any) testing when packages start going to bodhi, similar to Fedora.
20:30:35 <carlwgeorge> it probably wouldn't be nice for multiple of us to contact a maintainer simultaneously
20:30:43 <tdawson> true
20:31:06 <tdawson> Well, I'm going to grab the old ones in epel7 that aren't installable, and just unpush those.
20:31:23 <tdawson> There is about 10 of those.
20:32:03 <carlwgeorge> hey one i commented on when i saw nirik's issue followed up and hit push https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4829075fa
20:32:58 <tdawson> Nice ... although you had already commented on that one. :)
20:33:16 <carlwgeorge> yeah i was the one that stopped it from going to stable automatically with a -1
20:33:31 <neil> carlwgeorge++
20:33:31 <zodbot> neil: Karma for carlwgeorge changed to 1 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:33:34 <neil> the hero we need
20:33:38 <nirik> well, I guess if you already see a comment, don't add another
20:34:08 <dherrera> I wouldn't mind digging thorough those and ping their maintainers
20:34:44 <neil> maybe group them by maintainer so that, as carlwgeorge mentioned, maintainers don't get annoyed
20:35:00 <tdawson> dherrera: Go for it.  I guess just take nirik's advise and if you already see a comment (that isn't old) skip to the next one.
20:35:35 <carlwgeorge> dherrera++
20:35:35 <zodbot> carlwgeorge: Karma for dherrera changed to 1 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:35:48 <dherrera> sure! i'll go for that!
20:35:48 <Eighth_Doctor> Diego H (he/him)++
20:35:59 <Eighth_Doctor> dherrera++
20:35:59 <zodbot> Eighth_Doctor: Karma for dherrera changed to 2 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:36:00 <nirik> yeah, just don't comment on ones that are already recently commented on. ;)
20:36:27 <tdawson> OK, I'm going to say we've spent enough time on this one for now and move on.
20:36:42 <tdawson> #topic Old Business
20:37:17 <tdawson> Is there any one business anyone wants to bring up?
20:37:23 <smooge> isn't a 7 year old EPEL-7 update old business?
20:37:32 <tdawson> Although I have several subjects in my list .... *laughs*
20:37:33 <smooge> i think we can move to new business
20:38:17 <tdawson> all of my old business subjects are marked to skip unless someone wants to bring them up.
20:38:23 <neil> 🥁
20:38:36 <smooge> thank you thank you
20:39:32 <tdawson> And ... with that we'll move to new business. :)
20:39:40 <tdawson> #topic General Issues / Open Floor
20:39:52 <Eighth_Doctor> I've got a thing for this :)
20:40:04 <tdawson> Eighth_Doctor: Go for it
20:40:06 <Eighth_Doctor> It looks like OpenH264 for EPEL 9 is nearly ready: https://pagure.io/releng/issue/11422
20:40:33 <tdawson> ooohhh ... nice
20:40:52 <nirik> yeah, a bit more to do, but well on it's way
20:41:06 <Eighth_Doctor> the ODCS compose has been synced to Cisco already: https://codecs.fedoraproject.org/openh264/epel9/
20:41:24 <tdawson> Will that just show up in the epel release?  Or do we need to have that odd repo like Fedora has?
20:41:36 <Eighth_Doctor> (also, I met the Cisco guy at the openSUSE Conference this past weekend... hopefully we can make this process less painful going forward)
20:41:43 <Eighth_Doctor> tdawson: we will need an additional repo file
20:41:47 <tdawson> OK
20:41:54 <nirik> we need to add it to epel-release/add the repo and make sure it's right in mirrormanager.
20:42:05 <Eighth_Doctor> yup
20:42:15 <carlwgeorge> can we ship it as an optional subpackage?  it won't be applicable for many server environments.
20:42:16 <Eighth_Doctor> once that's all done, I will branch obs-studio to EPEL 9
20:42:21 <Eighth_Doctor> no
20:42:23 <Eighth_Doctor> please don't
20:42:31 <Eighth_Doctor> it will be necessary for headless ffmpeg to be useful
20:42:47 <Eighth_Doctor> for transcoding and server video coding workloads
20:43:35 <Eighth_Doctor> and RPM Fusion will hard-depend on it for their ffmpeg build once we have the repo file made available
20:43:37 <tdawson> When I said "odd repo" it wasn't really a bad thing, it just looks different than the rest.  It's always very fast.
20:44:06 <nirik> yes, it has to be the same odd repo like fedora has.
20:44:09 <Eighth_Doctor> they've already done this for Fedora and will do it for EPEL 9 too
20:44:22 <nirik> because we cant distribute the rpms. cisco has to.
20:44:59 <nirik> but it should work fine I would think just like in fedora.
20:45:16 <Eighth_Doctor> yup
20:45:38 <Eighth_Doctor> once we have this in place, multimedia enablement will be largely complete for RHEL 9 platforms
20:45:40 <tdawson> Sometimes I don't think cisco gets enough kudo's in the open source enviroment.  I really appreaciate them doing this.
20:46:02 <Eighth_Doctor> they're at least trying to solve a real pain point
20:46:32 <tdawson> Yep
20:46:34 <neil> yeah. i have other issues with Cisco.. but this is definitely tilts the scales back a bit
20:46:46 <Eighth_Doctor> webex still ain't great :P
20:46:46 <neil> and thank you Eighth_Doctor for your work on multimedia enablement in rhel9
20:46:49 <neil> Eighth_Doctor++
20:46:49 <zodbot> neil: Karma for ngompa changed to 5 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:46:53 <tdawson> Eighth_Doctor: And thank you (and whoever else) has been work on this.
20:47:06 <tdawson> Ha ... neil beat me to it. :)
20:47:16 <Eighth_Doctor> but we should thank the webex folks for making this happen
20:47:23 <Eighth_Doctor> it's their group that created openh264, iirc
20:48:31 <tdawson> I've got another subject if nobody else has one.
20:49:10 <smooge> go for it
20:49:32 <tdawson> It's what to do with packages that aren't a good fit for epel ... things like gpsd, neovim, and others.
20:49:42 <tdawson> .epel 232
20:49:43 <zodbot> tdawson: Issue #232: Incompatible upgrade policy: how to handle packages like neovim? - epel - Pagure.io - https://pagure.io/epel/issue/232
20:50:02 <tdawson> It's not that their license is bad, it's just that they always have breaking upgrades.
20:50:11 <smooge> I hear snaps are all the rage
20:50:21 <Eighth_Doctor> 🪦
20:50:34 <tdawson> Well, flatpaks could be a solutions, and COPR is another.
20:50:54 <smooge> going from various ways to try and deal with fast software over the years. I think flatpaks and COPR are a better solution
20:51:03 <Eighth_Doctor> I wish we had the ABI checks in bodhi for EPEL like we do for Fedora...
20:51:05 <nirik> playground was supposed to be a solution. RIP.
20:51:11 <tdawson> I was thinking more of the COPR solution ... would it be possible to make an epel package, that simply enable the COPR repo for that packages.
20:51:22 <smooge> not easily
20:51:38 <tdawson> You think it would make more of a mess than a solution?
20:51:41 <Eighth_Doctor> technically we can do whatever we want there
20:51:44 <smooge> more of a mess
20:51:59 <tdawson> ok
20:52:05 <Eighth_Doctor> but yeah, I think it would invite Loki upon us all
20:52:05 <smooge> uhm no. we can do whatever the COPR developers want to do
20:52:22 <davide> copr is messy because it involves adding more repos
20:52:31 <davide> the more repos you have, the slower dnf gets
20:52:37 <tdawson> true
20:52:49 <nirik> We could also grant exceptions for such packages, but then users might be somewhat confused...
20:52:53 <carlwgeorge> wait are we talking about the cisco repo again?  :P
20:52:56 <smooge> the alternative would have been modules but I do not like to speak of the dead
20:53:02 <tdawson> *laughs*]
20:53:04 <Eighth_Doctor> lol
20:53:05 <tdawson> *laughs*
20:53:13 <Eighth_Doctor> rip in peppers indeed
20:53:38 <Eighth_Doctor> I think granting exceptions is a reasonable course
20:53:50 <nirik> Fedora does that for some packages.
20:53:53 <Eighth_Doctor> right
20:53:57 <tdawson> true
20:54:01 <Eighth_Doctor> and EPEL already has one for the entire KDE software collection
20:54:06 <tdawson> I just worry how long the list would be.
20:54:13 <carlwgeorge> do things more like fedora, yup that sounds good to me
20:54:25 <smooge> it would be very long to the point where people wanting slow would say EPEL is broken.
20:54:34 <Eighth_Doctor> I think we make things unnecessarily hard on ourselves by trying to pretend we can be RHELish
20:54:40 <tdawson> True for KDE, but we also try to not cause breakages when there are updates.
20:54:42 <nirik> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions
20:54:43 <smooge> I say this from pushing that through in the past
20:55:14 <smooge> we did the playground stuff because of the complaints from [redacted]
20:55:33 <Eighth_Doctor> our list in Fedora isn't even that long
20:55:38 <smooge> over having things which were constantly broken for [redacted] in EPEL
20:55:56 <Eighth_Doctor> I would be happy to have a constraint that no EPEL exception can exist unless there's an equivalent Fedora one
20:57:06 <Eighth_Doctor> essentially making exceptions global to the project rather than just to a subproject
20:57:08 <nirik> well, there might be some epel only thing thta needs one...
20:57:10 <tdawson> Have them go through the Fedora process first ... makes our lives easier. :)
20:57:24 <Eighth_Doctor> nirik: can you think of one?
20:57:25 <nirik> (but I don't have any example, so...)
20:57:36 <Eighth_Doctor> yeah, I couldn't think of any
20:57:42 <nirik> nope... just theoretical. ;)
20:57:46 <Eighth_Doctor> if one comes up, we could revisit the rule
20:58:00 <Eighth_Doctor> but I think it's reasonable that if something has an exception in Fedora, it applies to EPEL too
20:58:17 <tdawson> Well, we don't need to have a solution today, just keep it in the back of your minds.  michel wanted to discuss it at some point ... and it's been nagging at me.
20:58:40 <nirik> sure
20:58:47 <tdawson> Anything else before we close this week?
20:59:19 <smooge> understood. I am not against going to 'if Fedroa has an exception, it applies to EPEL' I just know that we had better make it very clear in our documentation and be ready for calls
20:59:23 <smooge> not from me
20:59:29 <tdawson> Oh, there will be a "State of EPEL" presentation at the F38 release party
20:59:48 <smooge> cool. have fun
20:59:48 <rsc> tdawson: will it be streamed?
20:59:50 <tdawson> Shouldn't be anyting new for people here, except for new stats.
20:59:51 <Eighth_Doctor> we have a release party?
20:59:55 <tdawson> rsc: Yep
21:00:07 <rsc> tdawson: do you know where it will be streamed?
21:00:20 <tdawson> I don't currently have a link ...
21:00:23 <davide> https://fedoramagazine.org/youre-invited-to-the-fedora-linux-38-release-party/
21:00:29 <davide> it's on hopin
21:00:59 <tdawson> https://fedoraproject.org/wiki/Fedora_Linux_38_Release_Party_Schedule
21:01:05 <rsc> Ah, the official release party.
21:01:18 <tdawson> And there's the scedule, it will be on Friday, later in the day.
21:01:30 * neil hopes he can join
21:01:53 <tdawson> Thanks for the good discussions today.  I'll talk to ya'll next week, if not sooner.
21:02:00 <neil> peace!
21:02:06 <tdawson> #endmeeting