20:00:15 <tdawson> #startmeeting EPEL (2022-04-13)
20:00:15 <zodbot> Meeting started Wed Apr 13 20:00:15 2022 UTC.
20:00:15 <zodbot> This meeting is logged and archived in a public location.
20:00:15 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:15 <zodbot> The meeting name has been set to 'epel_(2022-04-13)'
20:00:16 <tdawson> #meetingname epel
20:00:16 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca
20:00:16 <tdawson> #topic aloha
20:00:16 <zodbot> The meeting name has been set to 'epel'
20:00:16 <zodbot> Current chairs: carlwgeorge dcavalca nirik pgreco salimma tdawson
20:00:20 <rsc> .hello robert
20:00:21 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:00:21 <carlwgeorge> .hi
20:00:22 <pgreco> .hi
20:00:25 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:00:28 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:00:46 <tdawson> Hi SSmoogen
20:00:49 <tdawson> Hi rsc
20:00:52 <tdawson> Hi carlwgeorge
20:00:57 <tdawson> Hi pgreco
20:01:48 <pgreco> hey, I'm back physically, mentally not so much
20:02:07 <tdawson> Well, it's always good to have you physically here.
20:03:25 <salimma> .hi
20:03:26 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:03:32 <tdawson> Hi salimma
20:03:39 <salimma> howdy all
20:04:40 <SSmoogen> hello-p
20:05:05 <nirik> morning
20:05:09 <tdawson> SSmoogen: I already said hi to you
20:05:10 <tdawson> :)
20:05:17 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:17 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:38 <tdawson> The only thing there is the CVE's, and we still have a couple weeks before that comes around ...
20:05:52 <tdawson> #topic Old Business
20:06:10 <tdawson> ImageMagic CVE's -
20:06:10 <tdawson> - we got 82 reported on bugzilla
20:06:10 <tdawson> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=ImageMagick&list_id=12543908&product=Fedora%20EPEL&query_format=advanced
20:06:48 <tdawson> Oh ... I forgot to get the email link, does anyone have that handy?
20:06:48 <salimma> whew, that's a lot
20:06:59 <nirik> it's often that way with it. ;(
20:07:51 <SSmoogen> its magick if it doesn't have CVE's
20:08:19 <tdawson> *laughs*
20:08:24 <nirik> I did an update to it in fedora years ago and it was 100's of cves
20:09:01 <nirik> anyhow, I guess we should let it update.
20:09:12 <carlwgeorge> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CY7W5INN46INTBEGNXTAJVWWIPBWIJD2/
20:09:22 <SSmoogen> honestly it is a package that I would say should have the policy that if there is an update it MUST be done in EPEL no matter what the rebuilds needed
20:09:25 <tdawson> Thanks carlwgeorge
20:09:39 <carlwgeorge> actually, let me do it right for the minutes
20:09:46 <carlwgeorge> #link https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CY7W5INN46INTBEGNXTAJVWWIPBWIJD2/
20:10:28 <salimma> should this be documented? I agree that having a list of packages where we recommend 'always stick to the RH version' would be useful
20:10:45 <tdawson> Oh ... no wonder I couldn't find it, I was in the wrong archives.
20:11:02 <nirik> this work should be done in a side tag.
20:11:26 <carlwgeorge> the maintainer set one up, but didn't go through the normal incompat upgrade process
20:11:48 <nirik> ah, ok.
20:12:03 <tdawson> They've been waiting for us.
20:13:01 <tdawson> Well, they sent the email, carlwgeorge told them to stop. let us know what cve's there were and wait until they heard from us.  But they didn't give the CVE's until last friday.
20:13:17 <tdawson> Anyway, I'm +1 for letting them proceed.
20:13:27 <carlwgeorge> i'm fine with waiving the full week due to the number of cves
20:13:41 <salimma> yeah, same
20:13:52 <carlwgeorge> i just want people to start following the process, mainly the epel-announce emails
20:13:53 <SSmoogen> +1
20:14:12 <nirik> +1, hopefully everything can be rebuit nicely.
20:15:02 <tdawson> What do we mean "waiving the full week"?  it's been on the email list for over two weeks.
20:15:26 <carlwgeorge> thankfully i only see 4 packages that buildrequire it
20:15:55 <salimma> slightly OT, epel-announce is moderated right? who has access to approve posts
20:16:26 <carlwgeorge> tdawson: the way the policy is written, it should be open for discussion with the list of cves for a week on epel-devel
20:16:48 <tdawson> carlwgeorge: Ahh ... ok.  It hasn't been a week since they gave the CVE's.
20:17:07 <carlwgeorge> yeah that's the part i'm talking about waiving
20:17:20 * nirik does
20:17:26 <tdawson> OK.  I'm fine with that.
20:17:50 <carlwgeorge> no one else raised concerns in the two weeks it was mentioned on the list, despite the lack of cve details
20:17:58 <SSmoogen> I am all for waiving it. Most imagemagick CVE's end up in the 8-9 category
20:18:20 <SSmoogen> I didn't raise concerns for that reason.
20:18:41 <SSmoogen> I probably should have said 'Please for the sake of the children.. do it'
20:18:47 <tdawson> Yep.  imagemagick is on the top 10 packages I don't want to ever maintain.
20:19:17 <tdawson> Do we have any negative votes?
20:19:41 <pgreco> I'm a bit out of the loop, so I'll defer to you guys
20:20:36 <carlwgeorge> if the maintainer does the builds in a side tag, how do they follow the steps related to bodhi updates?
20:21:02 <nirik> which steps?
20:21:14 <carlwgeorge> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
20:21:24 <carlwgeorge> steps 5, 6, and 7
20:21:28 <tdawson> #info Incompatable Upgrade of ImageMagick passed;  For: 5  Against: 0 Non-Vote: 1
20:21:45 <nirik> yes, they should do that...
20:21:48 <tdawson> I think step 6 was written back when we had 2 weeks bodhi time for epel
20:21:59 <carlwgeorge> yeah it was
20:22:01 <nirik> yeah, true
20:22:11 <tdawson> But I agree that they shouldn't "karma it out"
20:22:46 <carlwgeorge> what i'm asking is, with side tags aren't the builds merged without bodhi updates?  i'm not really familiar with how side tags work in practice.
20:23:08 <salimma> no, you cut an update as normal but select a side tag as the source
20:23:10 <tdawson> No, the side-tags all get put onto one update ... don't they?
20:23:10 <carlwgeorge> or is that just merging into the buildroot, and the bodhi updates are a separate thing to get them into the repos?
20:23:24 <nirik> no
20:23:32 <salimma> what's "fun" is that you can have two side tags with overlapping packages and not get warned, while with individual package updates the updates will get merged
20:23:36 <nirik> it makes an update with all of them
20:23:58 <salimma> sidetags are separate repos, when you cut an update all the packages get queued up like a normal multi-package update
20:24:05 <salimma> but without having to use buildroot override
20:24:08 <nirik> do all work/builds in side tag, make update from side tag (will contain all builds), etc
20:24:41 <carlwgeorge> ok so there's no conflict with side tags and the steps related to bodhi, good
20:24:53 <nirik> salimma: sometimes they will get merged, it depends. ;( There's a bunch of corner cases.
20:25:31 <nirik> like if the existing update is in a push and locked. Or the existing update has foo and bar in it and you are only adding an update for foo.
20:25:37 <salimma> yeah... there's a split second warning saying there's a conflicting update, that I wish require more confirmation before proceeding
20:25:38 <carlwgeorge> i understood side tags from the build system perspective, but not with what came next to publish
20:25:52 <tdawson> Are we ok moving on?
20:25:57 <carlwgeorge> yup
20:26:14 <carlwgeorge> tdawson are you going to reply on list with approval or should i?
20:26:20 <salimma> but anyway, that's a digression. yeah, we're good
20:26:23 <nirik> IMHO bodhi should reject new updates when there's an update for that package already in progress... but shrug.
20:26:28 <tdawson> So, all the other old business got approved last week, but I just want to note that the documentation still haven't been update.
20:26:33 <nirik> yeah, sorry to digress.
20:26:48 <tdawson> carlwgeorge: You can do it, as long as you don't take your usuall email time. :)
20:27:12 <carlwgeorge> hehe, will reply today
20:27:23 <tdawson> carlwgeorge: OK, sounds good.  Then I'll let you do it.
20:28:01 <tdawson> That's all I have for old business ... amazing enough.
20:28:13 <tdawson> #topic EPEL-7
20:28:13 <tdawson> CentOS 7 will go EOL on 2024-06-30
20:28:55 <nirik> oh, I have one epel7 thing:
20:28:57 <tdawson> carlwgeorge: is the hwinfo thing resolve for epel7?
20:29:22 <tdawson> nirik Go for it
20:29:49 <carlwgeorge> tdawson: yes
20:30:03 <tdawson> carlwgeorge: awesome.  Thank you
20:30:11 <nirik> ansible (the 2.9.x 'classic' version) goes EOL in may 2022. I'll retire the epel7 (and epel8) ones after that...
20:30:32 <nirik> ( see https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html )
20:30:52 <tdawson> #info ansible (the 2.9.x 'classic' version) goes EOL in may 2022.  nirik will retire the epel7 (and epel8) ones after that
20:31:03 <tdawson> #link https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html
20:32:19 <tdawson> nirik I seem to remember you sending an email about that ... but I'm not seeing it in my epel list.  Was I imaging things or can I just not find it.
20:33:03 <nirik> I thought I did a while back too... but I can send another.
20:33:16 * nirik adds to todo list
20:33:57 <tdawson> Well, I couldn't find the ImageMagick mail either ... so it's possible you did and I just can't find it.
20:34:04 <tdawson> Anything else for EPEL7?
20:34:40 <tdawson> #topic EPEL-8
20:34:41 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:34:50 <nirik> (same ansible note)
20:35:07 * SSmoogen plays sad trombon
20:35:08 <salimma> I'm wondering if anyone has context about why openldap-servers is not shipped
20:35:11 <nirik> although at least el8 will get ansible-core in 8.6
20:35:41 <SSmoogen> salimma, 1) there was a replacement 2) it was a support headache because it wasn't the primary tool people focused on
20:35:42 <salimma> in c8s it's built but the -servers subpackage is not shipped, in c9s it's turned into a conditional (defaulting off) and someone has openldap-epel
20:35:58 <salimma> SSmoogen: gotcha, thanks
20:36:25 <salimma> wait, what's the replacement? maybe I could nudge work people to switch to it
20:36:30 <SSmoogen> 389DS
20:36:42 <tdawson> Ohh ... that's what that is.
20:36:46 <SSmoogen> and if you are going to say that isn't a replacement
20:36:48 <salimma> ah of course
20:37:02 <salimma> yeah, Red Hat acquired that project right? been a while
20:37:11 <SSmoogen> 2003?
20:37:11 <nirik> so very long ago
20:37:23 <tdawson> My mind keeps thinking 389DS is a fancy nintendo handheld.
20:37:37 <SSmoogen> I keep thinking of it as an offbrand 386-DX
20:37:42 <carlwgeorge> salimma: https://bugzilla.redhat.com/show_bug.cgi?id=2030665
20:37:47 <salimma> haha
20:37:57 <salimma> huh, I wonder where the source is on Fedora - https://src.fedoraproject.org/modules/389-ds/tree/master is dead
20:38:02 <salimma> but yeah, moving on
20:38:14 <tdawson> #topic EPEL-9
20:38:20 <SSmoogen> like those franken chips they would sell in magazines that said 'put this CPU in your board and you will have a 386 on your 286 motherboard'
20:38:49 <salimma> oh https://src.fedoraproject.org/rpms/389-ds-base
20:39:05 <salimma> SSmoogen: that's probably the 387 DX (and 487 DX) :)
20:39:45 <tdawson> Anything for epel9?
20:39:53 <carlwgeorge> speaking of 389, that is one of the module maintainers that wants epel9 modules.  but looking at the epel8 modules, the three current streams have basically identical packages in them.
20:40:34 <salimma> seems like you wouldn't want to maintain multiple versions of 389ds anyway
20:40:57 <carlwgeorge> their streams are stable, next, and testing
20:41:28 <salimma> IIRC a similar package came up last week and we reckon COPR is a good fit?
20:41:58 <carlwgeorge> i think that was my suggestion, for the same topic (using modularity to offer testing packages)
20:42:26 * salimma just quoted Carl back to himself
20:42:35 <tdawson> :)
20:42:47 <tdawson> Sounds like we don't have any epel9 ...
20:42:58 <tdawson> #topic General Issues / Open Floor
20:43:23 <carlwgeorge> i missed these during old business..
20:43:36 <carlwgeorge> #link https://pagure.io/epel/pull-request/168
20:43:48 <carlwgeorge> #link https://pagure.io/epel/pull-request/169
20:44:23 <tdawson> Huh ... I wonder why I didn't see the stalled request pull request.
20:44:35 <carlwgeorge> we voted last week on 169 (it passed), just looking for approval and merging of the pr
20:44:45 <nirik> 168 seems good to me.
20:45:17 <nirik> 169 seems fine.
20:45:31 <salimma> +1 to both
20:45:34 <tdawson> 169 looks good, and it's seems so simiple I shouldn't need to verify it ....
20:45:36 <nirik> Are we going to have a exception request for drbd-whatever?
20:45:41 <salimma> about to do the needinfo ping for https://bugzilla.redhat.com/show_bug.cgi?id=2067485 as a matter of fact
20:45:41 <dherrera> I'm ok with both (hi)
20:46:12 <carlwgeorge> nirik: once the policy is merged i plan to reach out to the drbd maintainer and ask them what they want to do
20:46:30 <nirik> sounds good.
20:46:31 <tdawson> carlwgeorge: Both seem good.
20:46:34 <nirik> hi dherrera
20:47:15 <carlwgeorge> i usually avoid merging my own prs but if these look good i'll merge them now
20:47:30 <salimma> I can hit merge for you if that makes you feel better :)
20:47:35 <carlwgeorge> already doing it
20:48:40 <tdawson> carlwgeorge: Thanks for getting those written up.
20:48:41 <carlwgeorge> we did the formal vote on the stalled one, do we want to do a vote on the dependecies one?
20:49:07 <tdawson> I thought we already did
20:49:33 <tdawson> Last week I thought we all said that if you make the one change that nirik said, then everyone liked it.
20:49:42 <carlwgeorge> works for me
20:49:48 <salimma> it looks like basically what we agreed on, but if it helps, +1
20:50:02 <tdawson> +1
20:50:31 <carlwgeorge> if we # info it, i'll link that for posterity
20:52:12 <tdawson> #info https://pagure.io/epel/pull-request/168 is approved.   It was approved last week, on the condition that one change was made.  That change was made, and it has been approved again this week.  For: 5  Against: 0
20:52:24 <carlwgeorge> thanks tdawson
20:52:57 <tdawson> I forgot to put 2 non-votes ... but, that's ok.
20:53:23 <pgreco> my +1 was gonna be late ;)
20:53:33 <tdawson> Ahh ... there it is. :)
20:53:40 <carlwgeorge> thanks SSmoogen for being the bearer of bad news and saying no in the epel9 modular request issue
20:53:53 <SSmoogen> no problem
20:54:09 <carlwgeorge> which reminds me, i still owe yall a summary of the email responses from the module maintainers in the issue, just for transparency
20:54:43 <carlwgeorge> how open do we want to leave that door for the future?  i know we said we want people to step up and maintain it, but they would basically have to be in releng to do that, right?
20:55:16 * carlwgeorge is not arguing in favor of it, just want to be prepared if asked
20:56:37 <nirik> I guess...
20:57:20 <tdawson> Anything else?   We might actually end on time this week.
20:58:33 <tdawson> Well, thank you all for comming, and the good discussion this week.  And thank ya'll for all your work in the EPEL community.
20:58:41 <tdawson> Talk to ya next week.
20:58:48 <tdawson> #endmeeting