22:00:37 <tdawson> #startmeeting EPEL (2021-01-08)
22:00:37 <zodbot> Meeting started Fri Jan  8 22:00:37 2021 UTC.
22:00:37 <zodbot> This meeting is logged and archived in a public location.
22:00:37 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
22:00:37 <zodbot> The meeting name has been set to 'epel_(2021-01-08)'
22:00:38 <tdawson> #meetingname epel
22:00:38 <zodbot> The meeting name has been set to 'epel'
22:00:40 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel_slm
22:00:40 <zodbot> Current chairs: bstinson carlwgeorge michel_slm nirik pgreco tdawson
22:00:41 <tdawson> #topic aloha
22:00:47 <michel_slm> .hello salimma
22:00:48 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
22:00:50 <cyberpear> o/
22:01:05 <pgreco> hey!, we're back
22:01:29 <tdawson> Hi michel_slm
22:01:31 <tdawson> Hi cyberpear
22:01:33 <tdawson> Hi pgreco
22:01:37 <tdawson> Indeed, we are back.
22:02:15 * King_InuYasha waves
22:02:17 <carlwgeorge> howdy yall
22:02:18 <King_InuYasha> .hello ngompa
22:02:19 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
22:02:45 <tdawson> Hi King_InuYasha
22:02:47 <tdawson> Hi carlwgeorge
22:02:50 <King_InuYasha> hey y'all
22:02:54 <King_InuYasha> yo tdawson :)
22:03:07 <michel_slm> hi all! need to run in around 10 mins so I'll need to do a braindump soon :)
22:03:18 <carlwgeorge> go go go
22:03:54 <tdawson> Sounds good ... and I think nirik, if he makes it, will be late.
22:04:05 <tdawson> #topic Old Business
22:04:06 <pgreco> carlwgeorge: suddenly I got the music of Inspector Gadget in my head... :P
22:04:06 <michel_slm> #info https://fedoraproject.org/wiki/EPEL/Packagers#Workflow is updated with a tracker bug and a fixed query that also has the bug age set to 2 weeks
22:04:43 <michel_slm> also, I'll start doing the non-responsive maintainer process today for one of the bugs in the tracker, it's been requested for almost 2 months
22:05:14 <michel_slm> #info we should consider if this should be integrated with the Packagers SIG: https://fedoraproject.org/wiki/Archive:EPEL/AskForFedoraPackageInEPEL
22:05:17 <michel_slm> looks like it's archived
22:05:54 <michel_slm> pgreco: the one with the flying helicopter hat?
22:06:20 <pgreco> michel_slm: that's the best of all
22:06:21 <michel_slm> that's my update. happy to answer questions for the next few mins
22:07:26 <tdawson> Thanks for the update, I'm happy to see this progress.
22:07:52 <tdawson> That's the first I've seen that old AskForFedoraPackageInEPEL ... so I'm still trying to digest it.
22:07:58 <pgreco> michel_slm: the non-responsive maintainer, has been responsive on fedora branches?
22:08:19 <michel_slm> pgreco: I need to check
22:08:39 <michel_slm> uh, my checkout of the fedora_active_user script is on a different laptop
22:08:47 <King_InuYasha> man, that page is so old it's written like a MoinMoin wiki page
22:08:52 <pgreco> don't know if it makes any difference for this process, but I'd like to know
22:09:06 <michel_slm> yeah, I'll follow up after this
22:09:19 <michel_slm> I think we can salvage the wordings of the template, better than starting from scratch
22:09:38 <michel_slm> just plug the packagers SIG to the language, which will hopefully help getting faster responses
22:10:12 <michel_slm> tdawson: I'm not sure how I ended up finding it either. I actually didn't notice it was archived at first
22:10:38 <tdawson> I like our "create a bugzilla" versus the older "send and email", for tracking reasons, ... but some of the language is nice
22:11:09 <tdawson> michel_slm: I don't have any questions that should hold you here if you need to go.
22:11:17 <michel_slm> agreed, I like doing things in the open in a way that's trackable. email sounds nicer for following up
22:11:20 <pgreco> with 4 minutes to spare
22:11:21 <tdawson> Thank you very much for the update.
22:11:32 <michel_slm> yay! thanks, see you all next week or sooner
22:12:11 <tdawson> Next up is epel8-next ... carlwgeorge do you have a status for us?
22:13:10 <carlwgeorge> no change.  i was hoping nirik would be here so i could nag him about it.  waiting on staging bodhi permissions to finish implementing the staging proof of concept.
22:13:47 <carlwgeorge> once that's done, and we see what other small pieces are missing, the rest of the implementation should move quickly.
22:14:11 <carlwgeorge> funny, epel next has suddenly gotten lots more attention for some odd reason...
22:14:40 <tdawson> It has, and yet the IRC channel and email is fairly quiet
22:14:51 <tdawson> That's not a complaint, I like it quiet. :)
22:15:20 <carlwgeorge> it's a testament to the fact that current epel8 is 99% compatible with cs8
22:15:46 <tdawson> carlwgeorge: Thanks for the report, and your work on epel8-next.  I'm very glad we had/have this already working before the news came out.
22:16:03 <tdawson> /working/in progress/
22:16:15 <tdawson> I didn't mean to imply it was already working ... sorry about that.
22:16:30 <carlwgeorge> i did find three new incompatible packages the other because poppler got an soname bump.  turns out the rhel maintainer actually broke acg and is now having to request it get downgraded from level 2 to 4.
22:16:44 <tdawson> Ouch
22:17:37 <carlwgeorge> the same people that pushed back against epel next are very interested in finding these acg2 breakages and holding people accountable, which is a pretty good outcome even if we still need epel next for acg4 stuff
22:18:18 <tdawson> :)
22:18:28 <carlwgeorge> anyways, we can move on
22:18:36 <tdawson> OK, moving on ..
22:19:16 <tdawson> I have "missing -devel packages" ... but I thought we'd already finished that.  Anything we need to discuss or should I take that off the agenda?
22:19:55 * tdawson takes it off the agenda and moves on.
22:20:04 <tdawson> #topic EPEL-7
22:20:18 <carlwgeorge> i got a thing
22:20:32 <tdawson> carlwgeorge: Yep, something python related I belive, go for it.
22:20:53 <carlwgeorge> still working on a mailing list proposal for it, but i'd like to formalize guidance to use python3 prefixes instead of python36 prefixes
22:21:04 <carlwgeorge> right now we have a mix, and it's confusing
22:21:26 <tdawson> Yep it is.
22:21:28 * King_InuYasha shrugs
22:21:36 <carlwgeorge> i sent a few prs to rename subpackages, and miro pushed back slightly that he likes the python36 prefix to tell what comes from epel
22:21:39 <King_InuYasha> if it's python3- everything needs to have python36- provides
22:21:54 <carlwgeorge> python_provides macro does that, along with obsoletes
22:21:55 <King_InuYasha> because that's an assumption that people have had for a while now
22:22:34 <carlwgeorge> basically everything is already in place to support either approach thanks to miro's forsight
22:23:00 <carlwgeorge> my stance is that there are better and more reliable methods to determine a package comes from epel rather than the name prefix
22:23:17 <carlwgeorge> repoquery, keychecker, rpm -qi, etc.
22:24:19 <carlwgeorge> just wanted to make yall aware i'll be sending an email to the list soon to gather feedback, then we can vote at the next meeting (or some future meeting)
22:24:24 <tdawson> One thing python3x does for us is make sure everything is recompiled on the proper release ... but, now that I say that ... is that really necessary.
22:24:44 <King_InuYasha> not really
22:24:57 <King_InuYasha> we need it for EPEL 8, but not EPEL 7
22:25:04 <carlwgeorge> only if you think python3 will be rebased in rhel7's lifetime
22:25:35 <carlwgeorge> which seems implausible
22:25:44 <King_InuYasha> it's not going to happen
22:26:05 <tdawson> Well, my opinion isn't strong either way, so I'll wait for your email and comment there.
22:26:08 <King_InuYasha> there's 3 years left on the clock, and RHEL 7 only *barely* wound up getting py36 in the base
22:26:25 <carlwgeorge> hehe, yeah i'm aware, hence calling it implausible
22:26:29 <King_InuYasha> carlwgeorge: however, we will need a way to do python3Y packages for EPEL 8 for alternate Python versions
22:27:02 <carlwgeorge> we're on the epel7 topic :P
22:27:13 <King_InuYasha> then I'll wait :D
22:27:19 <tdawson> Ha!!
22:27:33 <tdawson> ok ... anything else here before we move to EPEL8?
22:28:09 <tdawson> #topic EPEL-8
22:28:42 <carlwgeorge> King_InuYasha: say your piece about python, then i got another thing about new packages showing up in cs8
22:29:16 <King_InuYasha> right, uhh
22:29:32 <King_InuYasha> well, with RHEL 8, we have parallel-installable streams of Python 3.Y versions
22:30:24 <King_InuYasha> the default "python3-" is the python3.6 variant, but there's python3.8 also
22:30:32 <King_InuYasha> and I expect more versions to come in the future
22:30:54 <King_InuYasha> and unlike most AppStreams, they're parallel-installable, so it's reasonable that someone would want to build for multiple flavors
22:30:59 <carlwgeorge> i expect that in el8 3 will always be 3.6 due to platform-python
22:31:04 <King_InuYasha> yep
22:31:25 <King_InuYasha> but we'll probably want to be able to do python3.8-foo and python3.10-foo and whatever
22:31:39 <carlwgeorge> and i don't see a problem with python3-x spec files generating python38-x subpackages
22:32:16 <tdawson> Hmm ... but our current EPEL7 way of "current" and "next" (or whatever they are) only handles two varients, it can't handle 3 or more.
22:32:20 <King_InuYasha> I don't either, but I don't think anyone has managed to figure out _how_ that works?
22:32:22 <pgreco> but shouldn't those be part of modules?
22:32:22 <carlwgeorge> and considering the headaches we've had changing macro definitions in el7 related to that stuff, i'd prefer just explicit python38 prefixes
22:32:41 <pgreco> I mean, epel additions to python3* modules
22:32:52 <carlwgeorge> pgreco: python36 and python38 are default modules, so packages depending on them don't have to be
22:33:04 * King_InuYasha really wishes we had subpackage generators...
22:33:25 <pgreco> 38 is default too? didn't know that
22:33:47 <King_InuYasha> yep
22:34:01 <King_InuYasha> in modularity terms, each python stream is unique and default
22:34:03 <carlwgeorge> yes.  ask miro sometime about his thoughts that he was required to put python in modules but make different version parallel installable.
22:34:17 <King_InuYasha> much facepalm
22:34:30 <King_InuYasha> (or headdesk, take your pick)
22:34:40 <pgreco> carlwgeorge: I remember miro's talk in devconf, I can imagine that...
22:34:48 <carlwgeorge> hehe
22:35:51 <carlwgeorge> i'm gonna have to duck out in about 10 minutes, so let's move on to the last thing i wanted to mention
22:36:01 <carlwgeorge> still epel8 topic
22:36:17 <tdawson> carlwgeorge: Go for it.
22:37:12 <carlwgeorge> i noticed a new package fstrm get added to 8.4, and now it's built in cs8.  obviously i'm in a position to notice this stuff pretty early.  should we consider modifying epel policy to prohibit packages conflicting with cs?
22:37:36 <carlwgeorge> for now for fstrm i added a bug to not forget it, asking the maintainer to retire it with 8.4 ga release https://bugzilla.redhat.com/show_bug.cgi?id=1914422
22:38:06 <carlwgeorge> so i'm asking should that be retired then, or now
22:38:24 <tdawson> My opinion, then, not now.
22:38:42 <carlwgeorge> i could argue for it either way tbh
22:38:47 <King_InuYasha> we could probably start maintaining trackers for upcoming RHEL releases
22:39:01 <King_InuYasha> so that we can retire it in a timely fashion
22:39:27 <tdawson> It could be up to 6 months (though it usually isn't) before a new package get's released.  That could be very frustrating if you were a user and couldn't get the package that used to be in EPEL for several months.
22:39:29 <King_InuYasha> and we should be able to autogenerate those tickets too, since it's all semi-public now through centos stream
22:39:30 <bstinson> 2 thoughts about that, we need to make sure that we look at the RHEL package addition process (pulling in an EPEL package is one part of the runbook that mentions that you should carefully coordinate the NVRs)
22:39:46 <carlwgeorge> tangent off this, i'm finally going to submit my provenpackager request so i can start doing retirements for stuff i raised bugs for with the 8.3 release
22:39:48 <bstinson> 2nd is, we should probably wait to retire at point-release time
22:40:50 <carlwgeorge> 1) history shows rhel maintainers don't always do that
22:41:33 <carlwgeorge> 2) counter argument, someone using cs8+epel8 could have cs8 packages replaced by epel8 packages, which is directly against the spirit of epel policy
22:42:03 <bstinson> that's why it needs to be looked at, and featured more prominently in the package addition process (this is already happening because of all the things that need to happen with Stream)
22:42:41 <King_InuYasha> too bad we can't use repo priorities for this
22:43:12 <King_InuYasha> because that would de-prefer epel to all other repos
22:43:49 <King_InuYasha> vendor preferences would fix this, but those don't exist yet in DNF in CentOS Stream 8, afaik?
22:44:05 <King_InuYasha> at least, the APIs needed for a vendor preference plugin...
22:44:50 <carlwgeorge> i get tdawson's point about it being painful for using getting an epel package taken away for 6 months
22:45:13 <carlwgeorge> but that doesn't lessen the impact of the counter point i brought up.  both are bad.
22:45:22 <tdawson> Correct
22:45:41 <King_InuYasha> if (lib)dnf is new enough, we could whip up something simple to make dnf auto-prefer base repo packages over epel ones, and forcibly hide epel ones in that scenario
22:45:51 <tdawson> I like bstinson's comments that we (Red Hat) need to start getting the package maintainers to think about EPEL NVR's.
22:46:12 <bstinson> the thing is, they're supposed to already
22:46:18 <King_InuYasha> they don't
22:46:27 * King_InuYasha grumbles
22:46:40 <bstinson> with Stream we have some time to catch that as a packaging bug before a RHEL release
22:48:22 <pgreco> bstinson: I did some filing of the "lower" rhel nvr, I never got a response from thel maintainers
22:48:31 <tdawson> True ... so ... maybe something might happen ... but I think maybe talking to the internal CI/gating team ... getting them to maybe setup some "does it conflict with EPEL' test.
22:48:58 <bstinson> ^also a good check
22:49:28 * michel_slm back
22:50:33 <tdawson> Quick ... michel_slm is back ... be very quiet and maybe he won't see us ...
22:50:36 <tdawson> :)
22:51:03 <tdawson> Sorry, we got to the point of .... where do we go from here
22:51:38 <michel_slm> I'm catching up on the cs8+epel but my cat is hogging my keyboard
22:51:56 <pgreco> both options are bad, I'd rather let stream take the heat and leave the package in until point release
22:52:51 <pgreco> because if we get to coordinate with the developers, it might not even be a problem, given the right nvr
22:53:04 <michel_slm> would freezing the epel package but not removing once it's in stream work?
22:53:14 <tdawson> I'm feeling that I agree with pgreco ... I think this will happen once or twice, and someone is finally going to put some type of EPEL checking in the RHEL new package workflow.
22:53:32 <King_InuYasha> michel_slm: no, because stuff in stream is no guarantee of it coming into a point release
22:53:42 <michel_slm> ah true
22:53:42 <King_InuYasha> cf cmake module
22:53:48 <pgreco> also, there may be CVEs
22:53:56 <King_InuYasha> right
22:55:33 <pgreco> carlwgeorge: question about these packages, do we know if the additions to stream are going to be "released"? or if they are just another case of screen?
22:56:10 <pgreco> packages might just be added as BRs
22:57:12 <michel_slm> having a way to have the BR packages be available in epel or another repo (with no guarantee) would be nice
22:57:18 <carlwgeorge> to be fair the cmake module wasn't added to cs8, we tapped the brakes on that one
22:58:04 <King_InuYasha> yes, but that's because it was caught early enough :)
22:58:24 <michel_slm> \\\
22:58:26 <carlwgeorge> as far as build root only stuff, I check that before filing bugs to retire
22:59:08 <tdawson> We're coming to the end of our meeting.  I'll certainly bring this up next week, but do ya'll think we should continue this dicussion via email, or just wait till next week and continue then?
22:59:43 <carlwgeorge> next meeting is fine by me
23:00:05 <tdawson> OK, sounds good.
23:00:09 <pgreco> I prefer interactive too
23:00:14 <King_InuYasha> likewise
23:00:40 <tdawson> Thanks everyone for being here.  Thanks for the good discussions, work, reports, and helping make EPEL better all the time.
23:00:48 <pgreco> thanks, see you!!!
23:00:48 <tdawson> Talk to you next week, if not sooner.
23:00:53 <pgreco> thanks tdawson
23:00:57 <King_InuYasha> thanks tdawson
23:01:01 <michel_slm> Thanks tdawson
23:01:01 <tdawson> #endmeeting