20:00:09 <tdawson> #startmeeting EPEL (2023-05-10)
20:00:09 <zodbot> Meeting started Wed May 10 20:00:09 2023 UTC.
20:00:09 <zodbot> This meeting is logged and archived in a public location.
20:00:09 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:09 <zodbot> The meeting name has been set to 'epel_(2023-05-10)'
20:00:10 <tdawson> #meetingname epel
20:00:10 <zodbot> The meeting name has been set to 'epel'
20:00:12 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
20:00:12 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
20:00:13 <tdawson> #topic aloha
20:00:28 <neil> .hi
20:00:31 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:00:35 <carlwgeorge> .hi
20:00:36 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:00:42 <tdawson> Hi neil and carlwgeorge
20:01:10 <nirik> morning
20:01:39 <tdawson> Morning nirik
20:01:56 <rsc> .hello robert
20:01:57 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:02:11 <gotmax> I think I'll do the meeting from IRC today, as the Matrix bridge is not working today
20:02:19 <tdawson> Hellp rsc
20:02:26 <gotmax> We had a lot of problems during the Ansible Community SC meeting today
20:02:35 <tdawson> Hi gotmax (the non-matrix gotmax)
20:02:46 <gotmax> Hi tdawson!
20:03:11 <tdawson> rsc: Sorry ... I'm not crying out for help, but bad fingering of hello.
20:03:17 <nirik> They had a bridge outage scheduled, but I guess there were/are problems after that
20:03:18 <nirik> https://fosstodon.org/@matrix@mastodon.matrix.org/110339452125063744
20:03:55 <gotmax> I think right now the problem is that matrix.org is overloaded
20:04:06 <gotmax> anyways...
20:04:37 <nirik> could be. ;(
20:04:37 <carlwgeorge> personally i'm not a fan of the bridging, i think we should either go all in on matrix or keep everything on irc, not this split brain like setup
20:04:58 <gotmax> I like being able to switch between the two :)
20:05:21 <carlwgeorge> the matrix 2.0 stuff presented at fosdem looked pretty nice, once it's done it will be a big speed and usability improvement
20:05:43 <tdawson> #topic End Of Life (EOL)
20:05:44 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:05:46 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:05:47 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:06:18 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:06:20 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:06:55 <tdawson> Let's start off with 226
20:06:58 <tdawson> .epel 226
20:06:59 <zodbot> tdawson: Issue #226: Incompatible update in apptainer-suid-1.1.8 - epel - Pagure.io - https://pagure.io/epel/issue/226
20:08:21 <gotmax> I'm kind of getting tired of reading through these long threads about apptainer and singularity packaging policy violations, so I'm out of the loop here...
20:08:47 <nirik> yeah, ditto. I haven't had time to dig too deep.
20:09:00 <tdawson> I think we need to break this one up into two pieces.  epel7 by it'self, and then epel8 and 9
20:09:13 <carlwgeorge> agreed
20:09:25 <carlwgeorge> i stand by my initial recommendations per branch in https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/6QHTAOQ6HWLAV3ZOWDBPXMXGMM7KSW4P/
20:10:38 <tdawson> So the CVE for epel7 ended up being high.  So does that mean you are for it for epel7?
20:10:44 <nirik> one thing thats not clear to me on 8/9 is... how incompatible things are? what would users have to do if it was updated?
20:10:49 <tdawson> Meaning it's ok to have the incompatible upgrade?
20:11:02 <carlwgeorge> tdawson: yes, it seems appropriate for epel7
20:11:33 <tdawson> I agree, to me, it seems that for epel7, it is entire appropriate for the update.
20:11:55 <tdawson> nirik: That's why I wanted to seperate the two parts.  Cuz the epel7 one is easier.
20:12:35 <carlwgeorge> for those that are still out of the loop, my tldr is that there is a cve that applies to apptainer in epel7, but the maintainer wants to use it to justify an incompat update in all three branches to keep them in sync
20:13:11 <nirik> yeah, epel7 seems +1 to me...
20:13:13 <carlwgeorge> if anyone in the loop feels that isn't a fair summary by all means say so
20:13:49 <smooge> hello
20:13:54 <carlwgeorge> epel7 vote time?
20:14:02 <tdawson> Hello smooge
20:14:05 <nirik> the others aren't affected by the security issue, but keeping them in sync/the same seems to provide some advantages... but I am unclear on what that really means? do users have to change a config? does it just break until they change something?
20:15:00 <carlwgeorge> it breaks a specific functionality unless manual config changes are made
20:15:15 <smooge> i am ok with the epel7 update.
20:15:28 <tdawson> smooge: We're doing seperate votes on the apptainer thing.  One for epel7, then we'll do one for epel8 and 9.
20:15:36 <carlwgeorge> i can't speak to how popular that functionality is, the singularity-ce maintainer thought it was important enough to raise a red flag so i'm guessing they see it quite often
20:15:58 <smooge> tdawson: sorry I thought the el7 vote was going
20:16:12 <tdawson> smooge: It was actually, I just wasn't sure if you were up to speed.
20:16:39 <tdawson> OK, if I'm counting right, it's +4 for 0 against, and one obstain.
20:17:01 <smooge> i like obstain.. your honor I obstain
20:18:27 <tdawson> #info For the epel7 portion of issue #226.  4 votes to allow the upgrade, 0 votes to not allow the upgrade, 1 obstain.  The issue for epel7 passed.
20:21:00 <tdawson> For the epel 8 and 9 stuff ... I feel that we should let it have their update, but with a warning.  That they try to work things so that they do not have anymore incompatible upgrades.  Otherwise, I don't think EPEL is really the right fit for them.
20:21:31 <tdawson> Sorry, that was supposed to be "EPEL is not the right fit for the package"
20:21:36 <smooge> I am in agreement with that
20:22:02 <smooge> we have given similar 1 time things to other packages in the past.. some have worked out and others had to go elsewhere
20:22:36 <nirik> I'd like to thank the maintainer for bringing this up actually... I suspect there's more incompatible updates that people just do without much noticing them...
20:22:44 <nirik> but anyhow, that seems fine to me.
20:23:01 <smooge> yes there have been several
20:23:22 <neil> this one is also a bit different in that the incompatible change only applies for some subset of the installations (i.e., those with apptainer-suid installed as well are only the ones affected by this (to my understanding) )
20:24:07 <carlwgeorge> i'm skeptical of allowing this with a warning because the maintainer already did an unannounced incompat update and got warnings, so we're on at least round two
20:24:38 <carlwgeorge> neil: epel policy doesn't really differentiate on "affects some subset"
20:24:58 <neil> carlwgeorge: i recognize that, but maybe it should?
20:25:48 <carlwgeorge> similar to the "how to short circuit the process" topic, that's a worthwhile discussion but not what we're talking about here
20:27:01 <nirik> well, I think that should weigh into an exception/approval being granted or not...
20:27:35 <tdawson> nirik: Is that shorthand for "do a vote"?
20:27:55 <tdawson> Or "Give our opinion"?
20:28:53 <carlwgeorge> almost every incompatible update would fall under "well as long as you don't use this subset of functionality, it's compatible"
20:29:27 <dherrera_> hmmm... but if we aproved epel7, wouldn't that imply that epel7 version would end up higher than 8 and 9 if we don't approve the incompatible upgrade? that's not a problem... right?
20:29:37 <nirik> tdawson: was replying to neil there... ie, we should take as many of the factors as we know into consideration when deciding.
20:30:24 <nirik> We havent in the past cared about upgrade path between major versions. That was pre LEEAP or whatever it's called tho... I would hope it uses distro-sync...
20:30:26 <carlwgeorge> dherrera_: no, the maintainer could do a conditional in the spec file to patch the default config on el8/el9 but not el7, and ship that as a new release everywhere
20:31:03 <neil> if the patched config leaves users in a vulnerable state by default, I think that's the wrong play, personally
20:31:11 <carlwgeorge> or even better, patch the source also to change the default when the config isn't set to account for unmerged .rpmnew configs
20:31:39 <carlwgeorge> neil: it wouldn't
20:32:01 <neil> carlwgeorge: that wasn't clear to me from my reading the threads, thank you
20:33:01 <tdawson> neil: We asked him specifically, and he said no they wouldn't be vulnerable.  But then went one for about 6 more paragraphs.
20:33:15 <carlwgeorge> the maintainer is saying that because future exploits that may not be patched are possible, we should allow the incompat update in epel8/9 preemptively
20:33:36 <carlwgeorge> assuming i understood him correctly
20:34:04 <smooge> that was my understanding. I would put this as a 'old version is no longer being patched. only new version is being updated by upstream.'
20:34:35 <carlwgeorge> i don't think that's the case here at all
20:35:20 <carlwgeorge> this breaking change isn't being done in a new major version and the old version is unmaintained, it was done in a minor (micro?) version and the same version is being shipped across all branches
20:36:08 <carlwgeorge> yes micro, 1.1.7 to 1.1.8 is a breaking change (for some subset of users, could be few or most) with the upstream defaults
20:36:50 <tdawson> carlwgeorge: I believe I understand your reasoning behind your not wanting to pass it, but it isn't really swaying me beyond what I said at the first.
20:38:07 <carlwgeorge> i'm not necessarily trying to sway anyone, just stating my understanding of the situation to explain my firm -1 stance
20:38:18 <carlwgeorge> others can of course vote how they see fit
20:38:22 <tdawson> Yep, and I understand.
20:38:59 <smooge> ok I understand carl's reasoning but am still +1
20:39:21 <tdawson> I don't feel like the last one was a "this is your final chance" warning.  It was a more of "hey, these things are complicated" type warning.  But this time I feel like we should be clear that this is a "Do this again, and we'll pull your package" warning.
20:39:27 <carlwgeorge> i definitely agree with what you said earlier about if this is a regular thing (which we already have two examples of in the last 8 months) that epel may not be a good fit for them, and they'd be better off doing a copr
20:40:03 <carlwgeorge> i'll also point out these incompat updates are being done in fedora stable branches, another policy violation
20:40:45 <tdawson> Yep, but we have no say on those ... well, at least I don't.  I'm not any of the Fedora stuff.
20:40:58 <tdawson> typing is hard today.
20:41:28 <carlwgeorge> i'm not even sure what accountability exists for repeated violations of fedora updates policy
20:41:47 <tdawson> Our time is going by ... are we ready for a vote?
20:41:57 <smooge> in 12+ years, I don't think I have every seen any accountability toward fedora violations
20:42:33 <tdawson> smooge: License violations I think get pulled pretty quick don't they?  ... but I digress.
20:43:56 <carlwgeorge> are you tallying up from the backlog or do you want us to restate our votes?
20:43:57 <tdawson> Who is in favor of allowing the update for epel8 and 9, with a warning?
20:44:08 <gotmax> +0
20:44:16 <tdawson> I'd like a fresh vote incase someone swayed one way or the other.
20:44:21 <tdawson> +1
20:44:29 <carlwgeorge> -1
20:44:58 <smooge> +1
20:45:20 <smooge> nirik-libera: may have gotten kicked off for some reason
20:45:47 <tdawson> Hmm ... I'd really like his vote, as it is, it's pretty close.
20:46:01 <tdawson> dherrera: how about you?
20:46:06 <dherrera_> +1
20:46:42 <nirik-libera> I'm on the matrix side, but the bridge is hosed... +1
20:46:47 <gotmax> Conan Kudo voted -1 but it got lost to the bridge
20:46:58 <tdawson> gotmax: OK, thank you.
20:47:00 <gotmax> > this is not the first violation, but the second instead
20:47:05 <gotmax> > and insofar as handling such issues in Fedora, they've been done before, just privately
20:47:12 <gotmax> > we've had such complaints come up to fesco
20:47:30 <gotmax> nirik-libera voted +1
20:48:00 <tdawson> OK, if I'm counting right we  have 4 approve, 2 against, 1 obstain.
20:48:12 * Eighth_Doctor waves
20:48:12 <Eighth_Doctor> .hello ngompa
20:48:12 <Eighth_Doctor> -1
20:48:12 <Eighth_Doctor> this is not the first violation, but the second instead
20:48:12 <Eighth_Doctor> and insofar as handling such issues in Fedora, they've been done before, just privately
20:48:12 <Eighth_Doctor> we've had such complaints come up to fesco
20:48:15 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:48:29 <tdawson> Ha ... something just got flushed through.
20:48:39 <tdawson> Hi Eighth_Doctor
20:48:52 <tdawson> We got your vote.
20:49:58 <tdawson> #info Vote on whether we should allow the update for epel 8 and 9 with a stern warning:  4 for, 2 against, 1 obstain.   Passed
20:50:06 <smooge> I will go on the record that this is my last +1 on this. 3 strikes and out.
20:50:54 <tdawson> Yep.  I think I'll do the writeup on the issue, and I will express that.  I feel the same.
20:50:58 <carlwgeorge> since this passed, do people think we should update the incompat policy to say that hypothetical future security vulnerabilities are valid justification?
20:51:42 <tdawson> "hypothetical future security" is just that hypothetical.
20:52:31 <gotmax> I don't understand "hypothetical future security vulnerability"
20:52:35 <tdawson> To me that means that the coders should look at their code and figure it out.
20:52:51 <tdawson> Anyway, we're getting close, I'd like to move one.
20:52:52 <tdawson> on
20:53:00 <tdawson> #topic Old Business
20:53:33 <tdawson> I just wanted to remind everyone that next week we will be talking about the EPEL 10 dist-tag proposal.
20:53:42 <tdawson> It should be a much funner discussion than this one.
20:53:57 <neil> #link https://discussion.fedoraproject.org/t/epel-10-bikeshedding-dist-tag/80510 if anyone needs it
20:54:03 <carlwgeorge> to explain what i meant since it confused folks, this passed to allow an incompatible update in epel8/9 despite there not being a vulnerability that applies to epel8/9.  justification was vulnerabilities could happen in the future and this helps mitigate them.
20:54:04 <tdawson> Thank you.
20:54:31 <gotmax> 👍
20:55:02 <tdawson> And with that, I'm goign to move to open floor, incase anyone had anything new (or old) to bring up.
20:55:08 <tdawson> #topic General Issues / Open Floor
20:55:15 <neil> i see what you're getting at carlwgeorge, and agree it's a "slippery slope" (i'll ban myself later) to allow anything to pass for any reason. i think the other convo about policy w.r.t. security vulnerabilities will drive that discussion more
20:55:36 <smooge> my justification was that whenever we have older stuff in EPEL8/9 versus EPEL7 it causes nothing but a string of complaints, headaches and pushes to fix some customer.
20:56:08 <dherrera_> my reasoning was the same as smooge honestly
20:56:10 <carlwgeorge> that's not the maintainer's justification, and also not the case here
20:56:35 <tdawson> Just incase anyone wasn't aware ... RHEL 9.2 was released yesterday  ... let the recompiles commense. :)
20:56:37 <gotmax> #info ansible has been updated to 7.2.0 in EPEL 9. See https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/2MAGEGNYTGIPQLMYDJHNS2E5MQ5P35XD/#2MAGEGNYTGIPQLMYDJHNS2E5MQ5P35XD. The same update will happen in EPEL 8 once RHEL 8.8 is released.
20:57:12 <tdawson> gotmax: Thanks for doing that, and for your very well worded email.
20:57:24 <gotmax> Thanks :)
20:57:26 <neil> gotmax++ - i was testing it today, working great
20:57:26 <zodbot> neil: Karma for gotmax23 changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:57:37 <neil> i will add karma to the bodhi update soon
20:57:55 <gotmax> thanks!
20:58:44 <tdawson> Anybody have anything else?
20:59:14 <smooge> just thank you for running the meeting
20:59:44 <tdawson> Thank you all for coming.  And thank you all for the good discussion.  I really like that we can have different views and still have a good discussion.
21:00:04 <tdawson> I'll talk to ya'll next week, if not sooner.
21:00:15 <tdawson> #endmeeting