21:00:10 <tdawson> #startmeeting EPEL (2022-12-07)
21:00:10 <zodbot> Meeting started Wed Dec  7 21:00:10 2022 UTC.
21:00:10 <zodbot> This meeting is logged and archived in a public location.
21:00:10 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
21:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:10 <zodbot> The meeting name has been set to 'epel_(2022-12-07)'
21:00:12 <tdawson> #meetingname epel
21:00:12 <zodbot> The meeting name has been set to 'epel'
21:00:13 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge
21:00:13 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson
21:00:15 <tdawson> #topic aloha
21:00:15 <pgreco> .hi
21:00:16 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
21:00:23 <nirik> morning
21:00:26 <tdawson> Hi pgreco
21:00:30 <tdawson> Morning nirik
21:00:31 <dherrera> .hi
21:00:32 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
21:00:36 <tdawson> Hi dherrera
21:01:05 <rsc> .hello robert
21:01:08 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
21:01:29 <davide> .hello dcavalca
21:01:32 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
21:01:34 <yselkowitz[m]> .hello yselkowitz
21:01:35 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
21:01:47 <tdawson> Hello rsc and davide and yselkowitz[m]
21:02:24 <carlwgeorge> .hi
21:02:25 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
21:02:53 <tdawson> yselkowitz[m]: Good to have you here.  Is there anything specific you wanted to bring up?
21:02:57 <tdawson> Hi carlwgeorge
21:03:36 <yselkowitz[m]> not really, and I'll have to drop before bottom of the hour
21:03:43 <smooge> here
21:03:58 <tdawson> yselkowitz[m]: That's fine.  You are always welcome.
21:04:05 <tdawson> Hi smooge
21:05:07 <tdawson> #topic End Of Life (EOL)
21:05:08 <tdawson> RHEL 7 will go EOL on 2024-06-30
21:05:10 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
21:05:11 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
21:05:51 <tdawson> It was brought up today on a different channel, that we don't have anyplace that says what our EOL dates are.
21:06:10 <tdawson> I don't think that's big deal, but I could have sworn we did.
21:06:13 <yselkowitz[m]> really?
21:06:52 <davide> aren't these on the website under the download page?
21:06:55 <davide> the centos website I mean
21:07:26 <carlwgeorge> we might have an faq
21:07:34 <tdawson> But, our EPEL site doesn't point to either the CentOS, or the RHEL EOL pages.
21:07:43 <carlwgeorge> and if we don't that might be the best place for it, seeing as we just follow the distro eol
21:08:10 <tdawson> Anyway, don't want to go too much into it ... but if someone wanted to update the docs to either have the dates, or point to the RHEL / CentOS EOL pages, that would be good.
21:08:38 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
21:08:39 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
21:08:53 <tdawson> We do have one issue today
21:09:01 <tdawson> .epel 210
21:09:02 <zodbot> tdawson: Issue #210: Proposal to retire findbugs-bcel from EPEL 7 - epel - Pagure.io - https://pagure.io/epel/issue/210
21:09:35 <tdawson> This issue is really two fold ... the first is to vote if it's ok for them to retire the package.
21:10:21 <nirik> sure
21:10:23 <tdawson> The second is to ask, why did we write the policy so that if a person feels like it, they can retire a package.  But if it's for a security reason, it has to be approved.
21:10:32 <michel-slm> .hi
21:10:33 <zodbot> michel-slm: Sorry, but user 'michel-slm' does not exist
21:10:37 <michel-slm> .hello salimma
21:10:37 <zodbot> michel-slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
21:10:44 <tdawson> Hi michel-slm
21:10:45 <michel-slm> sorry I'm late! got sidetracked by something else
21:11:06 <gotmax[m]> If we're going to have a longer discussion about the second part that should be a separate issue IMO
21:11:13 <tdawson> So, first up.  Let's vote on approving it to be removed.
21:11:32 <gotmax[m]> It gets confusing when another issue brings up a policy question and then we also use it to discuss the policy question
21:11:38 <michel-slm> I thought the security thing was mostly about providing incompatible upgrades (but I guess we tacked on 'you can also retire')
21:11:38 <nirik> I think the oirg intent was to just have people announce retirements. approval doesn't seem like it's really something we can do.
21:12:02 <carlwgeorge> what nirik said
21:12:26 <gotmax[m]> Yeah, approval is needed for incompatible updates, but it shouldn't be needed for retiring a package
21:12:28 <carlwgeorge> we've been explicit in the past that volunteer maintainers can retire stuff in EPEL at will
21:12:41 <gotmax[m]> and we have a separate procedure/policy for that
21:13:02 <carlwgeorge> the retirement is more for anyone to speak up and say "I'll take it over"
21:13:11 <carlwgeorge> *retirement announcement
21:13:18 * Eighth_Doctor waves
21:13:21 <Eighth_Doctor> .hello ngompa
21:13:22 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
21:13:25 <michel-slm> right. the announcement is more important for EPEL since we don't have Fedora's 'two week orphan' auto-retirement
21:13:37 <smooge> I don't remember every wanting people to get approval. I am guessing this is something that got pulled in from an earlier policy
21:13:41 <nirik> well, and to let folks know its going away
21:14:10 <smooge> the earlier policy was that if you needed to do updates which broke API/etc you should go get approval. It never was followed
21:14:12 <tdawson> It's sounding like everyone thus far is in agreement.  Are we ok if I get rid of the "approval" part, and merge "security removals" into the other section?
21:14:32 <nirik> +1
21:14:33 <smooge> ok it might have been followed once or twice..
21:14:35 <smooge> +1
21:14:56 <tdawson> Sounds good.  I'll do a pull request and send it out for ya'll to look at.
21:15:11 <carlwgeorge> I for one would really like to have some teeth behind the policy to help enforce it
21:15:33 <pgreco> +1
21:15:52 <smooge> teeth?
21:16:30 <nirik> carlwgeorge: which policy? the incompatiable packages one?
21:16:35 <carlwgeorge> some kind of retribution.  making mistakes is understandable, but at some point repeat offenders should have packager permissions pulled imo.
21:16:59 <carlwgeorge> nirik: yeah, or rather skipping it and shipping breaking updates with no announcement or coordination
21:17:01 <gotmax[m]> Meh
21:17:14 <smooge> carlwgeorge, that has never 'flown' in Fedora
21:17:16 <michel-slm> +1
21:17:34 <nirik> I think education should be tried first...
21:17:39 <carlwgeorge> i would also like it for breaking fedora updates policy
21:17:49 <carlwgeorge> i realize this may not be a popular opinion
21:17:49 <nirik> I suspect many doing it don't know any better
21:18:03 <dherrera> +1
21:18:04 <michel-slm> rather than punishment (though full disclosure, mea culpa, I've done this recnetly too...)
21:18:13 <Eighth_Doctor> it's one thing to not know better, but after being taught and still doing it is another
21:18:26 <michel-slm> rather than that, maybe having tooling to block incompatible updates from being pushed should be tried first?
21:18:31 <michel-slm> and education, definitely
21:18:49 <Eighth_Doctor> when I joined Fedora 15 years ago, we did have a policy around this, where sponsors have the right to yank the sponsee's packager powers if they do badly with them
21:19:01 <smooge> personally I think that sort of discussion usually ends up with FESCO having to become a prosecution, and the Council being a court.
21:19:02 <tdawson> michel-slm: And your hands got slapped rather well I think :)
21:19:07 <Eighth_Doctor> that's why old-FAS logged who sponsored people
21:19:12 <michel-slm> with FAS3 I can't even see woh I sponsored :)
21:19:21 <Eighth_Doctor> unfortunately, someone forgot to migrate that feature :(
21:19:25 <michel-slm> tdawson: oh yes, and I fully deserveit
21:19:29 <smooge> Eighth_Doctor, and after it got abused by some people over personal issues versus real ones it was decided not to keep
21:19:37 <gotmax[m]> smooge: Yeah. In the case of very blatant and continued violations that the person in question makes no effort to resolve, FESCo maybe should be involved, but otherwise meh
21:19:38 <Eighth_Doctor> https://github.com/fedora-infra/noggin/issues/626
21:20:15 * nirik thinks this is going off on a hypothetical tangent
21:20:27 <smooge> anyway, this is outside of EPEL. I encourage people to bring it up with a group that actually has some teeth
21:20:27 <tdawson> Yep
21:20:53 <gotmax[m]> Conan Kudo: isn't there still some mention about sponsor's removing sponsee's privs in some doc?
21:21:04 <Eighth_Doctor> yes
21:21:05 <tdawson> That was our only issue marked with meeting ... moving on.
21:21:18 <tdawson> #topic Old Business
21:21:20 <tdawson> EPEL 10 proposal
21:21:22 <tdawson> https://discussion.fedoraproject.org/t/epel-10-proposal/44304
21:21:23 <gotmax[m]> There's https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#revoking
21:21:25 <gotmax[m]> Anyways...
21:22:10 <tdawson> carlwgeorge: I see that the converstion has dropped ... what are the next steps, and how do you think people are feeling about it?
21:22:12 <Eighth_Doctor> I have specific issues with the proposal
21:22:23 <Eighth_Doctor> I just haven't had a chance to write up a post to clearly articulate my thoughts
21:22:40 <nirik> I dont think theres too much hurry
21:22:50 <tdawson> Well, that answers part of my question :)
21:22:53 <carlwgeorge> I'm fine leaving it alone for now to allow for more comments
21:22:54 <Eighth_Doctor> Carl probably knows what they are, but I still want to get that written down :)
21:23:22 <dherrera> we can still wait :)
21:23:29 <tdawson> I'm good with waiting.
21:23:37 <Eighth_Doctor> awesome, thanks
21:24:10 <tdawson> Though ... that means the meeting will be rather short :)
21:24:27 * michel-slm could do with a short meeting
21:24:29 <tdawson> I don't have any other Old Business marked.
21:24:37 <tdawson> #topic General Issues / Open Floor
21:24:39 <gotmax[m]> There's https://access.redhat.com/errata/RHSA-2020:0754
21:24:42 <gotmax[m]> Oops
21:24:51 <gotmax[m]> No idea what that is...
21:24:53 <gotmax[m]> https://pagure.io/epel/issue/212
21:25:27 <gotmax[m]> That was a link from the ticket
21:25:36 <Eighth_Doctor> I think this is jonathanspw asking to rebase novnc?
21:25:47 <Eighth_Doctor> from my perspective, I'm fine with this
21:25:52 <nirik> I'm fine with this based on info from the ticket
21:25:54 <tdawson> Oh ... ya, that should have had the meeting flag.
21:26:11 <tdawson> gotmax[m]: Thanks for seeing this.
21:26:19 <gotmax[m]> Me too
21:26:26 <carlwgeorge> agreed, seems legit, but needs a week on the mailing list for comment I think by policy
21:26:56 <jonathanspw> indeed it's me Eighth_Doctor
21:27:44 <tdawson> Yep, it needs a week for talking ... but it's really nice to see people following policy.
21:27:55 <smooge> thank you jonathanspw
21:28:36 <carlwgeorge> this made me realize the policy for this sort of thing is different between fedora and epel
21:28:47 <jonathanspw> I was actually confused on policy at first and opened a fesco ticket lol
21:29:05 <jonathanspw> but carlwgeorge and fesco quickly got the right docs to me
21:29:14 <carlwgeorge> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#security-fixes
21:29:45 <michel-slm> huh yes
21:29:59 <nirik> see long thread on devel list
21:30:05 <carlwgeorge> granted epel and fedora policy don't have to be identical
21:30:53 <tdawson> Yep, this is one place they differ, but I have to say, that they are "similar" ... They need FESCO approval, EPEL's need Steering Commitee approval.
21:31:35 <tdawson> Anyway, I've got it marked with "meeting", so we'll be sure to give it a vote next week.
21:31:51 <tdawson> anything else on Open Floor?
21:31:55 <smooge> yep
21:31:59 <rsc> Yes, I've two things
21:32:05 <carlwgeorge> right but i don't see a notification or mailing list request for comment period on the fedora side.  should we propose that for fedora or drop one or the other for our side?
21:32:17 <smooge> anyone want to package/maintain gscan2pdf  for EPEL9?
21:32:29 <smooge> it came up in alma so passing it on here.
21:32:30 <smooge> that was all
21:32:34 <tdawson> smooge: What language is it in?
21:32:59 <rsc> Perl
21:33:02 <michel-slm> we reckon EPEL users are more conservative when it comes to updates, and that's why we asked for a comment period right?
21:33:19 <rsc> (https://src.fedoraproject.org/rpms/gscan2pdf/blob/rawhide/f/gscan2pdf.spec)
21:33:31 <tdawson> carlwgeorge: It sorta surprises me that Fedora doesn't have a comment period.
21:33:57 <smooge> ... oh this is going to need a cop
21:34:00 <tdawson> I'm not against perl, but I do try to avoid them.
21:34:07 <michel-slm> smooge: I can check how many missing dependencies there are to even see if it's viable
21:34:12 <michel-slm> do we have an open ticket for it?
21:34:17 <michel-slm> bugzilla issue I mean
21:34:34 <smooge> there is a bugzilla 2151714.
21:34:49 <jonathanspw> generally i'd offer to maintain a package especially if requested by someone on the alma side but perl..meh.
21:35:03 <carlwgeorge> like i was saying, epel can diverge, but i think it's worth considering bring the processes closer together, whether that means adding stuff on the fedora side or dropping something from the epel side
21:35:22 <michel-slm> I'll add a list of the missing deps once I finsih computing them, but... if it's a lot I won't volunteer :)
21:35:28 <smooge> don't worry it only needs 96 perl modules
21:35:34 <tdawson> carlwgeorge: I'm ok with that, but on this case, I think they should add that step.
21:35:34 <yselkowitz[m]> are the gtk perl bindings in epel yet?
21:35:40 <michel-slm> smooge: 96 direct modules, who knows how many recursive
21:35:49 <michel-slm> tdawson: yeah, agreed
21:35:58 <smooge> so you start with F32, and you keep building...
21:36:25 <smooge> i think it will require some sort of copr build monster
21:36:36 <smooge> anyway.. i did my good deep for Krampus
21:36:40 <tdawson> :)
21:36:51 <tdawson> rsc: You said you had two things?
21:36:57 <rsc> Right, but likely small
21:37:06 <nirik> carlwgeorge: I don't think anyone in the fedora side follows that policy really... thus the thread about updating the updates policy to more reflect what people do/or enforce it somehow
21:37:29 <rsc> First is: I've some something-epel packages, where something-devel landed in RHEL 9.1. What's the best way to deprecate the something-epel packages *properly*?
21:37:33 <carlwgeorge> i'll have to catch up on that thread
21:38:03 <tdawson> rsc: I always do a "fedpkg retire 'This package is now in RHEL'"
21:38:21 <michel-slm> note that there was a bug that means the package did not get pulled from the repos
21:38:43 <michel-slm> (that Fabio reported a few weeks ago... um, not sure if that's fixed yet). but yeah fedpkg retire should be it
21:38:47 <tdawson> rsc: Essentially, follow the https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_package_in_rhel
21:39:07 <rsc> tdawson: good. Maybe that should be mentioned or linked on the page how to create the -epel packages
21:39:13 <smooge> rsc, or is that one of those.. there are other parts of the rpm which aren't in rhel
21:39:43 <rsc> smooge: it's some of those packages which only exist, because -devel was not in CRB (but is now).
21:39:53 <tdawson> rsc: Oh, that's a good point ... let me write that down.
21:41:14 <tdawson> rsc: What was the second thing?
21:41:29 <rsc> Second is: I'm trying to get scribus into EPEL 9 before RHEL 9.2 (https://bugzilla.redhat.com/show_bug.cgi?id=2144650), which will require another 6 something-epel packages, because -devel is missing in CRB of RHEL 9.1 (just Stream) - is that "fine", given it's "a lot" of new something-epel packages going to be retired with RHEL 9.2?
21:41:58 <michel-slm> rsc: can you get it in epel-next first?
21:42:00 <rsc> I only had one or another -epel package so far, not 6 at once.
21:42:16 <rsc> michel-slm: I could - but why?
21:42:29 <michel-slm> but request the epel9 branches too preemptively so you don't need to wait when 9.2 lands
21:42:47 <michel-slm> oh, just so you can skip creating an -epel package only to retire it
21:43:01 <michel-slm> if you need these available on alma/rocky/rhel then I guess there's no choice but to do the -epel ones
21:43:15 <rsc> Latter applies. So answered :)
21:43:37 <rsc> Thanks!
21:45:11 <michel-slm> all quiet... I have one thing: remember to submit CFP for CentOS Connect FOSDEM if you're interested in speaking
21:45:27 <michel-slm> you can attend / present virtually if you can't make it to Brussels
21:45:28 <tdawson> My opinion.  6 -epel packages is alot, but not overly excessive.  If you are willing to keep them up to date and retire them when the time comes, I think you could go for it.
21:45:52 <yselkowitz[m]> has there been a sweep for anything that needs to be removed, or -epel only that need to be updated, as a result of 8.7 and 9.1?
21:46:20 <rsc> tdawson: yes, I'll take care about that (like I will do with the others, thus question #1 before)
21:46:20 <carlwgeorge> i cleaned up a couple of 9.1 additions, but there might be more
21:46:37 <pgreco> michel-slm: if all goes well, I'll be there in person
21:46:52 <jonathanspw> i'm hoping to make it there in person as well
21:47:21 <michel-slm> argh, I'll miss meeting y'all (visa snafus)
21:47:39 <carlwgeorge> this is actually another cool thing i realized about the epel10 proposal.  currently we just ignore duplication between epel and stream until the thing lands in rhel then we do the epel retirement.  with the new model we could retire on the epel10 branch, and then it's automatically missing from the next minor version repo.
21:48:02 <michel-slm> yup! we retire in epel10 as soon as it hit CRB for stream
21:48:17 <tdawson> michel-slm: I didn't know we could do the presentation virtually.  I'll take a look.
21:48:18 <michel-slm> s/CRB for stream/stream repos
21:48:34 <michel-slm> tdawson: um, at least I hope we can, I know we can attend virtually. we should check with Shaun
21:49:26 <tdawson> Anything else for Open Floor?
21:49:31 <cottsay> .hi
21:49:32 <zodbot> cottsay: cottsay 'Scott Logan' <logans@cottsay.net>
21:49:39 <cottsay> I was hoping to get some clear guidance on what to do about pybind11 in EPEL 8
21:49:44 <cottsay> It disappeared without warning a few days ago, probably because python39-pybind11-devel showed up in CRB
21:49:50 <cottsay> Am I correct that the only path forward is creation of a separate EPEL-only 'python36-pybind11' package? Who can/should address that?
21:49:56 <cottsay> .bug 2151596
21:49:58 <zodbot> cottsay: 2151596 – We can no longer install pybind11-devel from EPEL or Powertools on CentOS Stream 8 - https://bugzilla.redhat.com/2151596
21:50:36 <carlwgeorge> i still don't know how this one happened.  it's not retired, but the build got untagged.
21:50:37 <tdawson> I didn't know that python39-pybind11-devel showed up in CRB ... ugg
21:50:39 <nirik> I looked at that a little. I couldn't see why it was retired.
21:51:11 <carlwgeorge> it's not retired in dist-git to be clear
21:51:14 <carlwgeorge> is it blocked in koji?
21:51:23 <smooge> so the only place I could see it causing issues is the part cottsay found where its src.rpm is in CS9
21:51:53 <smooge> so it something was done to block/check/remove those conflicts from CS9->EPEL9 that would have caused it
21:52:05 <carlwgeorge> but it's in a non-default module stream, python39-devel:3.9, which i think we allow to conflict with epel
21:52:19 <smooge> carlwgeorge, some of our tools don't know about modules
21:52:31 <smooge> its like they were never really meant to work in Fedora
21:52:51 <smooge> ... tries to ease out towards the door on that one
21:52:56 <carlwgeorge> lol
21:53:04 <nirik> carlwgeorge: yes
21:53:08 <nirik> so... I think it's pdc
21:53:13 <tdawson> OK, I just double checked, it is not in CRB be default.  You have to manually enable the module.
21:53:19 <nirik> it was marked to eol on 2022-12-01
21:53:46 <tdawson> What?  You can mark a package to EOL?
21:53:49 <smooge> yeah
21:54:22 <smooge> its like this tool was meant for a completely different operating system and then left to rot.. {has hat on and putting raincoat on}
21:55:13 <nirik> https://pdc.fedoraproject.org/rest_api/v1/component-branches/?name=epel8&global_component=pybind11
21:55:49 <nirik> so, IMHO, file a releng ticket, we can unblock it...
21:56:03 <nirik> and it can be either rebuilt or the old one retagged in
21:56:10 <michel-slm> smooge: surprisingly looks like gscan2pdf only needs 20 packages total
21:56:25 <smooge> hmmm I wonder what other packages may have been killed like that
21:56:36 <michel-slm> commented on the bug
21:56:45 <carlwgeorge> if unblocked manually, would pdc block it again?
21:56:46 <nirik> well, normally they are set to past the eol on the release...
21:56:50 <cottsay> nikrik: I didn't think it could be in EPEL any more because it shares the same source package name as the Python 3.9 one in CRB.
21:56:58 <nirik> carlwgeorge: until pdc is fixed / changed, yes.
21:56:59 <tdawson> So ... smooge is faster than me at typing ... how many has this happened to, and how many are going to disappear like that.
21:57:15 <cottsay> *nirik, sorry
21:57:52 <nirik> cottsay: that might be the case also, but if it was, someone would have noted it... not just automatically retired it. There's no automated process that checks that
21:58:17 <carlwgeorge> in this one case, since the srpm doesn't actually follow the naming guidelines, we could just avoid all this if someone wants to add a python-pybind11 package
21:58:19 <nirik> so take a look at say, xfce4-terminal...
21:58:21 <nirik> https://pdc.fedoraproject.org/rest_api/v1/component-branches/?name=epel8&global_component=xfce4-terminal
21:58:33 <nirik> eol is "2029-05-31"
21:58:46 <smooge> so I wonder if it would be better to 'fix' the package properly and make it spit out python36-pybind11
21:59:08 <smooge> but anyway fixing pdc is probably easier..
21:59:11 <smooge> probably
21:59:49 <carlwgeorge> to follow rhel naming it should be python3- prefix for the 3.6 package
22:00:29 <carlwgeorge> i think we need to loop in the fedora/epel maintainer.  seems the bug is on the rhel/centos product, so they might not be aware yet.
22:00:50 <nirik> +1
22:00:57 <tdawson> Oh, I just noticed the time ... cottsay and nirik ... do we have a plan for what to do?
22:02:01 <cottsay> I think further discussion with the maintainer sounds like a good idea, and it sounds like filing a releng ticket to unblock and rebuild/retag it is worth a shot.
22:02:01 <tdawson> Well, if we need to, we can follow up on #epel.
22:02:13 * carlwgeorge nods
22:02:28 <cottsay> Thanks!
22:02:29 <tdawson> Thank you all for comming this week and for the good discussions.
22:02:44 <tdawson> And than you all for your work and support of EPEL.
22:02:48 <tdawson> Talk to you next week.
22:03:02 <tdawson> #endmeeting