20:00:26 <tdawson> #startmeeting EPEL (2022-03-30)
20:00:26 <zodbot> Meeting started Wed Mar 30 20:00:26 2022 UTC.
20:00:26 <zodbot> This meeting is logged and archived in a public location.
20:00:26 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:26 <zodbot> The meeting name has been set to 'epel_(2022-03-30)'
20:00:26 <tdawson> #meetingname epel
20:00:26 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca
20:00:26 <tdawson> #topic aloha
20:00:26 <zodbot> The meeting name has been set to 'epel'
20:00:26 <zodbot> Current chairs: carlwgeorge dcavalca nirik pgreco salimma tdawson
20:00:37 <rcallicotte> .hi
20:00:37 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:00:39 <dcavalca> .hi
20:00:41 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:00:45 <dherrera> .hi
20:00:47 <zodbot> dherrera: dherrera 'None' <dherrera@redhat.com>
20:00:57 <pgreco> .hi
20:00:58 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:01:01 <carlwgeorge> .hi
20:01:02 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:01:10 <nirik> morning
20:01:28 <tdawson> Hi rcallicotte dcavalca dherrera pgreco carlwgeorge nirik
20:01:37 <rsc> .hello robert
20:01:37 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:01:41 <tdawson> Hmm ... that seemed so impersonal
20:01:45 <tdawson> Hi Ya'll :)
20:01:46 <rcallicotte> howdy howdy
20:01:49 <rcallicotte> hehe
20:01:52 <tdawson> Hi rsc
20:02:20 <Ebeneezer_Smooge> hello
20:02:42 <tdawson> Hi Ebeneezer_Smooge
20:04:03 <nb> .hi
20:04:04 <zodbot> nb: nb 'Nick Bebout' <nick@bebout.net>
20:04:25 <salimma> .hi
20:04:26 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:04:36 <tdawson> Hi salimma
20:05:06 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:06 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:24 <tdawson> We have two things marked for meeting this time.
20:05:34 <tdawson> The first is the EPEL CVE's
20:05:40 <tdawson> .epel 159
20:05:42 <zodbot> tdawson: Issue #159: Follow up on EPEL CVEs - epel - Pagure.io - https://pagure.io/epel/issue/159
20:06:17 <salimma> I wrote a draft for a vulnerability management policy, per our discussion last week. apologies for only finishing it 1 hr ago
20:06:25 <tdawson> Do we want to talk about this this week?  Or wait a week while we get a chance to read the draft?
20:07:15 * nirik hasn't read it
20:07:32 <tdawson> salimma: Are you ok waiting a week?  That way we can digest what you wrote, and get questions and answers ready.
20:07:56 <salimma> yup
20:07:57 <salimma> not urgent
20:08:09 <tdawson> OK, then let's move on to the next one, dealing with module content
20:08:15 <tdawson> .epel 135
20:08:26 <zodbot> tdawson: Issue #135: Modular content for EPEL9 - epel - Pagure.io - https://pagure.io/epel/issue/135
20:09:01 <tdawson> carlwgeorge: You had sent out an email to the people who build modules on epel8 ... did you want to report on that?
20:09:08 <Ebeneezer_Smooge> please wait a week
20:09:19 <Ebeneezer_Smooge> oh dang.. didn't scroll
20:09:23 <tdawson> :)
20:09:24 <carlwgeorge> sure, i can describe the responses so far
20:09:51 <carlwgeorge> so i emailed all the epel8 module maintainers and asked them four questions
20:10:14 <carlwgeorge> are you intentionally building your epel8 module (it happens automatically with platform: [])
20:10:27 <Ebeneezer_Smooge> what were you smoking? why were you smoking it? will you share what you are smoking? and dude.. I forgot the fourth
20:10:37 <carlwgeorge> have your users asked for the epel8 module
20:10:48 <carlwgeorge> have your users asked for an epel9 module
20:10:58 <carlwgeorge> do you intend to do the module in epel9 if/when possible
20:11:16 <carlwgeorge> most maintainers have answered no to all four
20:11:46 <carlwgeorge> the 389 maintainer who started issue 135 of course said yes to all
20:12:21 <carlwgeorge> the dwm maintainer said he's actually considering retiring the module in fedora and epel
20:13:00 <Ebeneezer_Smooge> and there was the zabbix ticket
20:13:13 <carlwgeorge> the nextcloud and zabbix maintainers said yes to epel9, but because they want to, not because users are asking for it
20:14:18 <carlwgeorge> responses to the email are still trickling in, so i'd like to give it another week and then summarize in the issue.  but it's about as i expected, low interest.  i'm not opposed to doing it, but i've got a bunch of other stuff that is higher priority, as i image most do.
20:14:39 <tdawson> Waiting another week for a decision is ok with me.
20:15:05 <tdawson> If / when we do it, who is the person that we would task to do it?
20:15:37 <carlwgeorge> i don't even think we'd need to task someone with it right away, just based on the low interest
20:15:47 <nirik> I'm for telling all the folks who wanted this to use compat packages... ;)
20:16:01 <carlwgeorge> i'm also fine with that
20:16:17 <carlwgeorge> or telling the people who want it to send in the the pull requests to do the work
20:16:18 <nirik> (which isn't quite the same as it lacks discovery)
20:17:10 <tdawson> So it's really just a matter of doing some pull requests, and when they get merged and the ansible scripts run, then it happens?
20:17:31 <Ebeneezer_Smooge> ok so who wants to send a F37 request that Fedora Engineering drop modules all together?
20:17:36 <carlwgeorge> i believe so, of course it will be extra work for releng
20:17:53 <nirik> there's more work than that.
20:18:00 <nirik> things like koji tag setup needs a koji admin...
20:18:02 <Ebeneezer_Smooge> I believe there is a lot more work than that
20:18:12 <tdawson> Understood that it's extra work.  I was just meaning that it's not something that nirik is the only person who can do it.
20:18:15 <nirik> getting mbs working will probibly require upstream
20:18:37 <nirik> Ebeneezer_Smooge: I'm tempted. ;)
20:18:42 <carlwgeorge> basically it needs someone to volunteer to drive and organize the work, coordinating with releng as needed
20:19:11 <Ebeneezer_Smooge> it needs work in MBS PDC (i think) some koji stuff and then testing and integration
20:19:33 <carlwgeorge> i think mboddu has some notes about setting up epel8 modular that would be a good guide
20:20:08 <carlwgeorge> i don't think the steering committee necessarily needs to say yes or no on this.  kind of a "you want it, come drive the work" situation.  if no one volunteers, it doesn't happen.
20:20:23 <tdawson> Ooohh ... I like that idea.
20:20:25 <nirik> I'm not sure I agree, but ok.
20:20:31 <Ebeneezer_Smooge> it is more than 'drive the work'
20:20:52 <Ebeneezer_Smooge> because I know a couple of the people who will assume that just means bugging the shit out of nirik and mboddu until it happens
20:21:24 <tdawson> That made me laugh ... because it's true.
20:21:25 <carlwgeorge> well of course it should be more than just nagging releng
20:21:29 <salimma> I have a question related to that - will need to find the link but that can follow later I guess
20:21:35 <nirik> I'm more concerned with the "it's working now! hurray. buh bye!" and we have to maintain it forever...
20:21:41 <Ebeneezer_Smooge> yep
20:21:54 <nirik> but thats not different than many things. ;)
20:21:55 <salimma> is EPEL 8 modular working then? I have had requests for epel8 branches that Remi close because he claims epel8 modular does not work
20:22:10 <Ebeneezer_Smooge> it doens't work the way Remi expects it to
20:22:12 <nirik> salimma: depends on what you mean by working
20:22:19 <nirik> you can build modules just fine.
20:22:30 <nirik> as long as you don't buildrequire any other rhel modules.
20:22:32 <carlwgeorge> i'm thinking about how i drove epel9.  pull requesting what i could, relying on releng for what i lacked permission for, and in general being aware of the next step at every point.
20:22:33 <Ebeneezer_Smooge> basically you have to build everything you need in said module and can't depend on any other module
20:22:53 * mboddu read the second mention first and it kinda scared me ;)
20:23:06 <nirik> remi wants to build against specific php modules, but that is not possible currently
20:23:18 <carlwgeorge> i also won't lose any sleep if releng just wants to say no outright
20:23:49 <salimma> https://pagure.io/epel/issue/75
20:23:51 <salimma> which was remi's answer to https://bugzilla.redhat.com/show_bug.cgi?id=2043260
20:24:01 <salimma> nirik: ah ok
20:24:40 <carlwgeorge> salimma: he's wrong in that bz, it's possible, it just has to be built against the default php module, which is no longer maintained
20:24:55 <mboddu> carlwgeorge: I am more than happy to help as long as someone driving it like you did for epel9
20:25:00 <Ebeneezer_Smooge> as far as I can tell, the only way modules are going to work as expected in 'EPEL' is only in EPEL-next and only if using the CentOS Build System
20:25:22 <salimma> I guess the question then is why is PHP 7.2 the default module stream. eh, should I ask that in the Stream office hour?
20:25:24 <nirik> it needs mbs to be aware of/use external modules.
20:25:35 <carlwgeorge> is it even epel if it's not built in fedora's koji?
20:25:40 <salimma> IIRC in #75 someone suggested following up with a Stream bug but remi didn't do that
20:25:52 <Ebeneezer_Smooge> salimma, it is the default because it was shipped that way in 8.0 and modularity doesn't allow changes of that
20:25:58 <salimma> well.. remi has his own repo because he said it can't be done in epel8 (the same packages are in epel9)
20:26:13 <salimma> ugh. so.. I hope someone in RH is maintaining PHP 7.2 then
20:26:22 <Ebeneezer_Smooge> nope past its lifetime
20:26:59 <tdawson> So ... before we go down the module rabbit hole ... we said we'd leave this till next week ... anyone mind if I move on?
20:27:07 <carlwgeorge> works for me
20:27:15 <tdawson> #topic Old Business
20:27:15 * Ebeneezer_Smooge feels like he is doing shots of everclear mixed with tequila on this thread
20:27:44 * salimma has a bottle of local whiskey he can crack open
20:27:50 <mboddu> It is not that hard to add modular support to epel9 like the one we have for epel8, but its really really hard (border impossible) to have it work like the way that people want
20:27:58 <tdawson> I have the "Depending on HA or outside packages" listed under old business ... didn't we finish that last week?
20:28:38 <tdawson> Or was that postponed until this week due to ... emails sent right before the meeting.
20:29:18 <Ebeneezer_Smooge> moving from everclear cut with tequila to everclear cut with old-granddad
20:29:25 <Ebeneezer_Smooge> it was postponed
20:31:24 <Ebeneezer_Smooge> my take is that these channels were not available when setting up EPEL-8 and they aren't available to all users. As such, I think adding them now will break various people in ways we can't easily advertise
20:31:28 <tdawson> Sorry for the pause, had to re-read the email
20:31:47 <tdawson> Yep, from what I read of the thread, you are correct
20:32:15 <salimma> ah. because we already have package collisions between HA and EPEL?
20:32:23 <salimma> we can make any new policy apply to EPEL 9 or EPEL 10 only
20:32:32 <Ebeneezer_Smooge> collisions and package dependencies
20:32:35 <tdawson> Everyone ok with that?  We don't add HA or any of the other channels
20:33:04 * nirik is ok with it I guess
20:33:24 <Ebeneezer_Smooge> if we did add them, then I would say we need to first rebuild any/all packages which depend on it with an README.WHYISTHISBORKED added
20:33:28 <carlwgeorge> the specific problem is epel packages depending on ha packages
20:33:53 <Ebeneezer_Smooge> then let those updates last 4 weeks, then add the HA and remove the packages which duplicate
20:36:00 <tdawson> it's quite ... too quite ...
20:36:13 <tdawson> Sorry, checking what is also in resiliant storage
20:36:13 <carlwgeorge> sorry was temporarily mobile picking up my kids from the bus stop
20:36:34 <carlwgeorge> i don't think we should add ha/rs to the epel base target
20:36:41 <tdawson> So, are we proposing we add HA as a base in EPEL9 and possibly 10?
20:37:05 <tdawson> I personally am with carlwgeorge, I'd rather we didn't.
20:37:10 <carlwgeorge> i do think we should forbid requires on ha/rs packages, but allow recommends
20:37:50 <salimma> I'm not really keen on adding HA either, just suggesting that as a middle ground - so if nobody feels strongly for it, we shouldn't
20:37:56 <rsc> Turning run-time requires into recommends?
20:38:06 <carlwgeorge> rsc: no
20:38:13 <salimma> recommend sounds fine if the package does something without the recommended package
20:38:37 <carlwgeorge> the example that spurred this topic was drbd-pacemaker requiring pacemaker (from ha)
20:38:39 <rsc> Well, I would like to have the drbd-pacemaker package in EPEL 9 in the end (even it depends on HA)
20:39:11 <carlwgeorge> so what i'm suggesting is that either 1) it be retired or 2) someone adds pacemaker to epel9
20:39:32 <carlwgeorge> unless it actually is an optional dependency, in which case switch it to recommends
20:39:56 <salimma> yeah, that sounds wrong to be a 'recommend'
20:39:57 <rsc> drbd-pacemaker is an extension to pacemaker, thus...
20:40:10 <tdawson> My opinion ... I'm still a ways away from getting "Will-It-Install" to open bugz and have any way of enforcing it.  There is literally 1 package that has this problem.  I'm for just dropping this and saying "it's your problem"
20:40:25 <salimma> we can't ask RH to add drbd-pacemaker to HA, I guess?
20:40:39 <tdawson> Not dropping the package, just let the package maintainer know that they need to document something or other.
20:40:39 <carlwgeorge> if we like, i can open a docs pr with my proposed phrasing, and we can continue the discussion there
20:40:46 <rsc> Red Hat refuses to do anything that's related to DRBD - at least that's my impression from a customer perspective.
20:41:45 <tdawson> carlwgeorge: That sounds like a good idea, discuss it in the pull request.
20:41:48 <carlwgeorge> this issue isn't specific to drbd, it's a policy question.  do we allow epel packages to require things that are in optional (sometimes extra cost) rhel channels.
20:42:12 <rsc> These channels are included with the dev subscription, IIRC.
20:42:23 <carlwgeorge> rsc: only ha, not rs
20:42:26 <tdawson> carlwgeorge: But, it IS specific to drbd ... like I said, it's the one one with this problem.  I've checked.
20:42:27 <salimma> how about requiring EPEL SC exceptions for this? seems rare enough
20:42:46 <salimma> but yeah we can fine-tune this in the PR
20:42:54 <carlwgeorge> and ha isn't included in the cheapest entry level paid rhel sub either, so dev sub actually has more content than that
20:43:24 <carlwgeorge> salimma: yeah i had the same thought on list, allowing requires by approved exception
20:43:43 <tdawson> I'm ok with that
20:44:02 <tdawson> I should be able to put an exception list in the Will-It-Install
20:44:21 <salimma> carlwgeorge: kind of makes sense, letting devs play with everything and then requiring more money when it's productionized
20:45:16 <carlwgeorge> tdawson: i think we're done on this topic for now
20:45:27 <tdawson> So ... are we ok with carlwgeorge writting up a pull request?
20:45:40 <tdawson> Yep, I wanted to move on to  last weeks discussion.
20:45:45 <tdawson> Changing the "Stalled Package" time
20:46:17 <salimma> change topic? :)
20:46:20 <Ebeneezer_Smooge> ok I think we are running time
20:46:25 <Ebeneezer_Smooge> ok I think we are running out of time
20:46:48 <tdawson> #topic slowing down the stalled request process
20:46:49 <carlwgeorge> i did better, i sent the email the day before rather than same day
20:46:59 <tdawson> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/FBTH7FGVYFVBFJX6QKAPLC6FCV66OY6D/
20:47:00 <carlwgeorge> still not great, and i'm fine punting a week on it
20:47:08 <carlwgeorge> give more time for list responses
20:47:24 * nirik is still pondering on this one.
20:47:35 <tdawson> I have to say, I am too.
20:47:40 <tdawson> Pondering I think
20:47:42 <carlwgeorge> oh i guess i'm wrong, it was 3 minutes after midnight when i sent it
20:48:24 <tdawson> pgreco had to leave, but he had a possible Proposal D - Basically Proposal C, but with an extra week at the end.
20:48:54 <tdawson> carlwgeorge: Are you ok letting us ponder this another week?
20:49:01 <salimma> yeah, maybe do what mattdm did for the Discourse reorg and follow up with a revamped set of proposals?
20:49:18 <nirik> I wonder if we couldn't automate this somehow to make it more consistent and less... personal seeming.
20:49:40 <dcavalca> that's an interesting idea
20:49:49 <salimma> but in the meantime we can slow down on our end. the easiest is probably to just wait two weeks instead of one
20:50:10 <dcavalca> we could have a tool to submit a request, that would take care of filing the bz and commenting as needed if there's no response
20:50:11 <tdawson> But ... but ... I want my package ... now!  :)
20:50:46 <dcavalca> I like proposal C fwiw, but no objections to pondering for another week
20:50:54 <salimma> dcavalca: that's on the todo list for ebranch :) but ideally some parts of it are implemented server side
20:51:01 <carlwgeorge> yeah i don't care too much for specifics really, just want the overall process to take slightly longer than 2 weeks
20:51:20 <carlwgeorge> tdawson: of course, waiting another week is fine
20:51:27 <salimma> IDK if the people who complain will be happy with an even more impersonal automation though, my itch to scratch was more 'I forgot which packages I asked for' so in practice I've almost never nagged after just a week
20:51:37 <tdawson> carlwgeorge: OK, then I'm going to move on, and we can let this progress in the email.
20:51:40 <carlwgeorge> we'll never make everyone happy
20:51:52 <tdawson> Yep
20:51:55 <nirik> well, I'd like it if bug subjects were the same and had the package name in them...
20:52:07 <salimma> C means needinfo on first approach?
20:52:15 <nirik> and the pings were 'Hey maintainer, here's what we are asking you to do, or let us do..." instead of "ping?"
20:52:19 <salimma> needsinfo on 2nd sounds less nagging
20:52:28 <tdawson> OK, I'm going to lump all three releases into one.
20:52:35 <nirik> needinfo is pretty aggressive IMHO.
20:52:35 <dcavalca> I'm find with needinfo on either first or second
20:52:38 <dcavalca> * fine
20:52:43 <salimma> anyone knows how to do a server side template?
20:52:48 <tdawson> #topic EPEL 7 / 8 / 9
20:52:54 <tdawson> CentOS 7 will go EOL on 30 June, 2024
20:52:57 <salimma> yeah, I think I'm for C but with needinfo on the second, not first
20:52:58 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:53:14 <salimma> EPEL9: found out the hard way luajit is in c9s but not pushed out
20:53:39 <carlwgeorge> related to the cve stuff, but for the epel8 topic, the imagemagick maintainer has a side tag for an soname bump https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CY7W5INN46INTBEGNXTAJVWWIPBWIJD2/
20:53:48 <salimma> ow_bug.cgi?id=2069528
20:53:50 <salimma> ugh
20:53:57 <salimma> https://bugzilla.redhat.com/show_bug.cgi?id=2069528
20:54:42 <carlwgeorge> it seems to me the maintainer didn't follow the incompat update policy, just sent one email saying "it's happening"
20:55:27 <tdawson> carlwgeorge: Well, he sorta adapted it.  He said it's happening, but if I read right, wants people to tell him if there is a problem.
20:55:57 <carlwgeorge> salimma: why not branch luajit for epel9?
20:56:19 <carlwgeorge> if none of the subpackages are shipped (appears to be the case), it's eligible
20:56:25 <tdawson> salimma: There are *alot* of packages that way.  Just because there is an rpm branch doesn't mean it's in RHEL9.
20:56:28 <salimma> carlwgeorge: ah, good to know
20:56:47 <salimma> yeah, asn wasn't sure so I thought i'll also request for it in CRB
20:56:51 <carlwgeorge> tdawson: i don't really like people picking and choosing which parts of the policy to follow
20:56:54 <tdawson> In fact, I'm removing one right now.
20:56:59 <salimma> I can reopen and say 'let's branch in epel9 and retire if it makes it to crb'
20:57:12 <tdawson> carlwgeorge: True, but it's better than not warning at all.
20:57:23 <salimma> tdawson: yeah, though this one seems active and not one of those "I forgot to retire"
20:57:41 <carlwgeorge> i'll probably reply to that thread and inform the maintainer of the policy and the expected timelines
20:57:50 <salimma> I will reopen the bz for requesting the branch and reference carlwgeorge from the IRC log :)
20:58:07 <carlwgeorge> fwiw i don't want to block it as it's to fix cves, but we have a policy that should be followed since it's an soname bump
20:58:29 <salimma> related to the policy - I linked the incompatible upgrade policy from the vuln management draft, so hopefully it gets more eyeball in the future
20:58:31 <tdawson> salimma: Oh ... your right, it's in c9s-pending ... huh ...
20:58:42 <salimma> yeah, IIRC skipping on the timeline requires discussing it here
20:59:00 <salimma> tdawson: but per Carl, if it's not in any released repo it is still fine, right?
20:59:02 <salimma> (juggling two convo is hard)
20:59:16 <tdawson> salimma: Correct.
21:00:01 <carlwgeorge> reminder, fedpkg and fedscm-admin check the c9s compose metadata to permit epel9 branch requests
21:00:34 <carlwgeorge> if there were a luajit subpackage in the compose, fedpkg should yell at you when you try to request the branch
21:00:37 <salimma> oh, so I can just do that check even though I'm not the maintainer, right
21:00:51 <carlwgeorge> i'm not sure which check comes first, tbh
21:00:58 <salimma> I wish there's a dry run
21:01:12 <carlwgeorge> check out the code and send a pr to add it :D
21:01:21 <salimma> yeah, I mgiht
21:01:35 <tdawson> Seems like that's something that's possible
21:01:39 <tdawson> And now I see the time.
21:01:46 <tdawson> #topic General Issues / Open Floor
21:01:54 <tdawson> Anything before I close the meeting?
21:02:27 <carlwgeorge> good here
21:02:52 <tdawson> Thank ya'll for coming.  Thank thank you for all the work you do for EPEL, it's community and it's users.
21:03:05 <tdawson> I'll talk to ya'll next week, if not sooner.
21:03:12 <tdawson> #endmeeting