epel
LOGS
20:00:33 <tdawson> #startmeeting EPEL (2022-04-27)
20:00:33 <zodbot> Meeting started Wed Apr 27 20:00:33 2022 UTC.
20:00:33 <zodbot> This meeting is logged and archived in a public location.
20:00:33 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:33 <zodbot> The meeting name has been set to 'epel_(2022-04-27)'
20:00:33 <tdawson> #meetingname epel
20:00:33 <zodbot> The meeting name has been set to 'epel'
20:00:33 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca
20:00:33 <tdawson> #topic aloha
20:00:33 <zodbot> Current chairs: carlwgeorge dcavalca nirik pgreco salimma tdawson
20:00:48 <nirik> morning
20:00:56 <SSmoogen> ghekki
20:01:01 <tdawson> Hi nirik
20:01:02 <dherrera> hi
20:01:03 <SSmoogen> or hello
20:01:05 <davide> .hi
20:01:06 <zodbot> davide: Sorry, but user 'davide' does not exist
20:01:09 <SSmoogen> if my fingers could type
20:01:16 <tdawson> Hi SSmoogen ... in whichever language you prefer
20:01:23 <tdawson> Hi davide
20:01:31 <tdawson> Hi dherrera
20:02:22 <carlwgeorge> .hi
20:02:23 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:02:38 <tdawson> Hi carlwgeorge
20:03:05 <rsc> .hello robert
20:03:06 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:03:13 <tdawson> Hi rsc
20:03:32 <tdawson> Just so people know, pgreco let me know he will not be able to be here.
20:04:43 <salimma> .hi
20:04:44 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:04:54 <tdawson> Hi salimma
20:05:11 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:11 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:22 <tdawson> .epel 159
20:05:23 <zodbot> tdawson: Issue #159: Follow up on EPEL CVEs - epel - Pagure.io - https://pagure.io/epel/issue/159
20:05:49 <tdawson> salimma: Did you have any progress or things you wanted to talk about?
20:05:52 <salimma> we have that documentation PR to discuss, I suppose
20:06:26 <tdawson> https://pagure.io/epel/pull-request/167
20:06:49 <salimma> going off will-it is probably a good idea too
20:07:28 <tdawson> The only problem with Will-It is that it doesn't look at priorities.
20:07:42 <salimma> true
20:08:08 <nirik> (yet?)
20:08:09 <salimma> any idea what the bugs not assigned to packages are?
20:08:12 <tdawson> For those that haven't looked at the last comment.  Last week I got will-it to do *all* the bugs, and make a page just for CVE's
20:08:22 <salimma> are those the CVE trackers that normally get filed, and somehow never got closed?
20:08:44 <tdawson> https://tdawson.fedorapeople.org/epel/willit/epel7/status-bugz-cve.html  https://tdawson.fedorapeople.org/epel/willit/epel8/status-bugz-cve.html
20:09:05 <tdawson> salimma: I've been looking through those, and I believe they are packages that once were in epel7 but no longer are.
20:09:37 <tdawson> https://tdawson.fedorapeople.org/epel/willit/epel7/status-bugz-no-source.html
20:09:38 <salimma> ah, ok
20:09:41 <SSmoogen> or never were :)
20:09:59 <tdawson> It's possilble they never were, correct
20:10:28 <tdawson> I've been going through that  last page closing several.
20:10:42 <salimma> oh those
20:10:54 <salimma> yeah, I took a look at them last time, a lot of them are actually branch requests
20:11:16 <tdawson> I haven't closed any of the requests for new packages in epel7 (cuz who knows, maybe someone will) ... but I've been closing the real bugs.
20:11:20 <salimma> but branch requests for epel 7 are likely not going to happen by this point, if the maintainer has been ignoring them for a while
20:12:17 <tdawson> It's actually rather nice closing the bugs.  Easier than figuring out real bugs.
20:12:23 <salimma> yeah :)
20:13:05 <tdawson> I'm hoping when the ImageMagick for epel8 get's updated, that the numbers drop quite a bit, at least for epel8.
20:13:16 <salimma> so - apart from the docs PR, I have nothing at the moment. it basically formalizes what we're now doing monthly - so if we do that I might look into automating the reports
20:13:42 <tdawson> Sounds good.   I'll mark my notes to visit this in a month.
20:14:17 <tdawson> That's the only issue, so moving on to old business.
20:14:22 <tdawson> #topic Old Business
20:15:29 <tdawson> As I guess I've already said, I updated Will-It to show all the epel bugs.  and on the pages that list all the packages, it shows what packages have bugs, and if there are any CVE's
20:15:43 <tdawson> https://tdawson.fedorapeople.org/epel/willit/epel8/index-packages.html
20:15:55 <tdawson> https://tdawson.fedorapeople.org/epel/willit/epel8/packages/ImageMagick.html
20:16:28 <salimma> would having a per-maintainer view be useful? (though I guess bugzilla and the packaging dashboard already does that)
20:16:42 <Eighth_Doctor> .hello ngompa
20:16:43 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:16:53 <tdawson> The vast majority of packages don't have bugs.  It's mainly a few that have large numbers.
20:16:58 <salimma> super cool - I suppose automatically filing FTI bugs will be next?
20:16:59 <tdawson> Hi Eighth_Doctor
20:18:03 <tdawson> salimma: bug tracking, or some type of history, needs to be next.  Otherwise I'm worried I'll keep opening bugs for the same package over and over.
20:18:25 <tdawson> But ya.  It's moving that way.
20:18:46 <salimma> yeah. release-monitoring does some matching so there's only one 'X version Y is available" update request that keeps getting updated
20:19:54 <tdawson> Other old business from last week.  EPEL 7 Testing Cleanup
20:20:31 <tdawson> I did get the full list, and I also sent an email.
20:20:55 <tdawson> But then the qt5 update happened and I ran out of spare time.
20:21:33 <tdawson> So, I haven't made any more progress other than what people saw in the email.
20:22:02 <tdawson> As far as I know, that's all the Old Business.
20:22:13 <tdawson> #topic EPEL-7
20:22:13 <tdawson> CentOS 7 will go EOL on 2024-06-30
20:22:34 <tdawson> Any epel7 things we want to bring up?
20:24:09 <SSmoogen> nope move along
20:24:54 <tdawson> #topic EPEL-8
20:24:54 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:25:40 <carlwgeorge> oh there was one epel7 thing, the puppet maintainer is planning on retiring that package
20:25:52 <SSmoogen> yay!
20:25:52 <tdawson> I guess there is/was the qt5 update that went to CentOS STream 8.  But I've already sent an email about that.
20:25:57 <carlwgeorge> it came up on fedora-devel
20:26:06 <tdawson> carlwgeorge: Did he send an email to epel-devel?
20:26:16 <carlwgeorge> i asked him to, still waiting on it
20:26:18 <tdawson> Oh ... he's retiring puppet from everywhere?
20:26:22 <carlwgeorge> just epel7
20:26:31 <tdawson> Ahh ... ok.
20:26:45 <carlwgeorge> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WTKLTKSNHAP3GFLGUGA7T7W2VVVVXDQO/#RXEPUMN2UUI7GPTVD5XWA5ZWMO23FEI2
20:26:49 <salimma> the qt5 update - all the affected packages are probably already branched in epel8-next right?
20:26:50 <SSmoogen> I would expect 8 also.. the ruby requirements are going up
20:26:56 <salimma> since we had a previous qt5 update to deal with too
20:27:16 <tdawson> salimma: Correct.  That isn't/wasn't the problem.
20:27:38 <tdawson> There were a few out of order builds, and the python2 module was ... messed up.
20:28:24 <tdawson> Johnny has been good on getting things fixed, but the python2 module we won't know if that is fixed for another day.
20:28:46 <salimma> ah, thanks. behind on my mailing list reading this week
20:29:37 <tdawson> In my email, I didn't put the part in about the out of order builds, just that things wouldn't be ready until next week.
20:29:59 <tdawson> That also gives me some extra time for testing incase I missed anything.
20:30:40 <tdawson> Anything else for epel8?
20:31:20 <tdawson> #topic EPEL-9
20:32:25 <tdawson> Incase you didn't read my email, I'm updating all of KDE in epel9-next.  Getting ready for RHEL 9.1
20:32:56 <tdawson> Which sounds wierd considering RHEL 9.0 isn't released ... but ... it's a new world.
20:33:43 <tdawson> Anything else epel9 related?
20:33:50 <SSmoogen> AlmaLinux 9 beta was released and is showing up in count stats
20:34:02 <SSmoogen> not many.. but it is showing up
20:35:01 <tdawson> We're cruzing right along here ...
20:35:08 <tdawson> #topic General Issues / Open Floor
20:35:14 <SSmoogen> about 4300 total EPEL-9 which have lived over 2 weeks
20:35:51 <tdawson> For fun, I did some koji list-history and figured out how many new packages we added each day for epel7, epel8, epel9.
20:36:17 <tdawson> I tried doing some graphs and found out that my skills are weak.
20:36:33 <SSmoogen> well its going to be a graph with a lot of 0's :)
20:36:52 <tdawson> Ha!   Yes, yes it was ... except that it wasn't
20:37:16 <tdawson> I forgot to put in the empty days ... so everything was all squished together.
20:37:35 <tdawson> And then I ran out of time.
20:37:43 <SSmoogen> thats like my graph where I plotted everything with the date 1970-01-01
20:37:52 <tdawson> Ha! :)
20:38:30 <carlwgeorge> for the open floor, i was thinking about the epel7 puppet retirement.  currently packages can be retired from epel at anytime.  common sense dictates sending an email to epel-announce, especially for notable/popular packages.  should we require this step?
20:38:49 <carlwgeorge> or even just document it as a strong suggestion, i.e. SHOULD
20:38:56 <salimma> epel-announce or epel-devel? since the former is moderated
20:39:02 <carlwgeorge> yes
20:39:10 <salimma> yeah, I think retirement should be treated similarly to incompatible upgrades
20:39:20 <davide> +1 for SHOULD, but I'd be ok with making it required if that's the consensus
20:39:24 <salimma> not identically, but... recommending announcing makes sense
20:39:27 * nirik is ok with SHOULD
20:39:29 <tdawson> carlwgeorge: I think so.
20:39:32 <carlwgeorge> current "policy" https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#what_can_be_retired
20:39:37 <salimma> yeah, let's start with should
20:39:50 <SSmoogen> I would say SHOULD and/or put in some toddler which can do it automagically
20:40:31 <carlwgeorge> i'm thinking such a suggestion should live on this page with the other retirement info, so not actually our docs
20:40:33 <salimma> huh, so all this time when people make orphan/retire announcements it's just a convention and never documented
20:40:42 <tdawson> I think epel-announce should be the place to send it.
20:40:55 <SSmoogen> email report for 2020-04-27: N packages were added to EPEL-7 <fill in list> N packages were updated to EPEL-7 <fill in list> N packages were retired with prejudice from EPEL-7 <fill in list>
20:41:19 <tdawson> carlwgeorge: oh, good idea about the location, or actually both.
20:41:36 <carlwgeorge> i'll probably bring this up with the packaging committee as well, perhaps they'll want to do the same for rawhide retirements (or perhaps not)
20:41:49 <carlwgeorge> tdawson: my concern about both is it getting out of sync if anything changes
20:41:58 <carlwgeorge> maybe make one a reference to the other
20:42:28 <salimma> SSmoogen: that definitely can be automated, though are we thinking about announcing *before* retiring or after?
20:42:44 <tdawson> SSmoogen: Make that a weekly/monthly report, and have all the epel repo's in it, and I like it alot.
20:42:45 <salimma> pre-retirement should probably go to -devel
20:42:45 <nirik> it's hard to enforce this kind of thing...
20:43:09 <davide> I think a human courtesy announcement of "I plan to retire X, holler if you have concerns" would be good
20:43:11 <salimma> yeah, so automating a status report like SSmoogen suggested is the only way to make this always work
20:43:12 <carlwgeorge> nirik: so is getting people to follow the incompat process
20:43:20 <nirik> sure...
20:43:21 <salimma> right, the courtesy announcement can be a SHOULD
20:43:28 <salimma> because we know we can't enforce it
20:43:29 <davide> automating "these packages were retired last week" would be useful regardless
20:43:32 <carlwgeorge> but "why didn't you do this" is easier when it's documented
20:43:58 <SSmoogen> davide, the issue with 'scream' is that people always complain that you CANT REMOVE MY PACKAGE
20:44:17 <salimma> then they can own the package ;)
20:44:26 <davide> that's when the maintainer politely suggests they take it over
20:44:36 <SSmoogen> usually the people complaining aren't packagers
20:44:40 <davide> it's about the same that happens in Fedora when Miro posts his orphaned packages report
20:44:53 <carlwgeorge> which is what is going to happen for nirik when he retires ansible in epel7 and suddenly people have opinions but were silent before
20:45:28 * nirik nods
20:45:31 <davide> I mean, it's great if people have opinions, and we should totally make sure the "I care about X how to I become a packager" is well documented, but at the end of the day if nobody wants to do the work it won't happen
20:46:15 <salimma> yeah. sometimes a "this will go away because nobody want to step in" is the nudge that finally woke someone to say "ok I'll take it"
20:46:16 <davide> fwiw I've seen many instances on fedora-devel of people saying "I care about X but can't help now" and someone else stepping up
20:46:20 <salimma> going through this at work right now :)
20:46:43 <salimma> yeah, the reaction to Miro's orphan report seems mostly positive, people just grabbing packages
20:46:43 <davide> it also provides a decent entry point for people that may want to become more involved in the project but don't know how
20:47:35 <SSmoogen> anyway, I am not against "SHOULD/MUST" post this is getting orphaned. I am just wanting to make sure we don't shame people anymore to keep packages which can't be maintained
20:48:02 <SSmoogen> because I have dealt with more than a few packagers who never wanted to deal with EPEL after the first time because of that
20:48:20 <tdawson> Fair enough
20:48:43 <SSmoogen> You broke my CI and you are a complete @$%#@%# for doing so is much more common reaction than I would like
20:48:52 <salimma> sigh :(
20:49:04 <salimma> is this ... worse for EL than for Fedora?
20:49:13 <salimma> as in, is the community make-up even in -devel different
20:49:14 <davide> That's a great point, yeah we should absolutely make it clear that's not tolerated
20:49:34 <SSmoogen> yes because we have tens of millions of users of EPEL and Fedora has hundreds of thousands
20:49:50 <carlwgeorge> unfortunately for the people who are willing to help but aren't packagers yet, soon to be orphaned packages are often a bad place to start
20:49:59 <davide> yeah, I've also found that people will occasionally not realize that EPEL packagers are volunteers
20:50:26 <nirik> for retiring packages, there's often some big reason, it's more than 'just needs a maintainer'
20:50:37 <carlwgeorge> exactly
20:50:48 <SSmoogen> anyway.. I siderailed this meeting from ending early
20:50:51 <nirik> like 'no longer supports python2' or 'has a big pile of security problems and upstream is dead' or ...
20:50:56 <salimma> carlwgeorge: yeah, comaintaining an active package is much easier than taking over a package that's being dropped
20:51:21 <tdawson> SSmoogen: Nope, I believe it was carlwgeorge that sidelined it. :)  But it was a real concern, both carlwgeorge and yours.
20:51:50 <carlwgeorge> hey that's what open floor is for :)
20:51:55 <tdawson> Yep
20:51:58 <SSmoogen> I have dealt with more than one person who required an EPEL package to remain, wanted to become a packager to keep it, and had never used a compiler before.
20:52:20 <SSmoogen> they just figured they could put their name to it and keep it in
20:52:34 <tdawson> carlwgeorge: It sounds like you have an idea for wording and where to put the changes.  Are you ok getting a pull request or two written up?
20:52:50 <carlwgeorge> yessir
20:53:00 <tdawson> carlwgeorge: Thanks
20:53:27 <carlwgeorge> thanks everyone for the feedback on that, i'll start with SHOULD
20:54:08 * SSmoogen goes to look for the RFC for alternate words to SHOULD/MUST
20:54:48 <SSmoogen> https://www.rfc-editor.org/rfc/rfc6919.html
20:55:09 <tdawson> We are getting close to the end of the meeting.  Anything new for Open Floor?
20:55:23 <carlwgeorge> > "MUST (BUT WE KNOW YOU WON'T)"
20:55:29 <carlwgeorge> literal lol
20:55:38 <salimma> TIL RC6919
20:55:57 <tdawson> :)  *laughs*  Yep ... let's put that on everything
20:56:13 * salimma looked at date - but of course
20:56:42 <SSmoogen> woops said this in the wrong channel
20:57:01 <SSmoogen> nothing other than I learned that people use yum install /usr/bin/mailq
20:57:11 <SSmoogen> which pulls in the EPEL esmtp
20:57:19 <SSmoogen> because esmtp comes before exim comes before postfix comes before sendmail
20:57:42 <tdawson> Of course ... that's how you install things :)
20:57:45 <SSmoogen> if you do /usr/sbin/sendmail you also may get that installed too
20:58:04 <SSmoogen> someone was wondering why esmtp was the default mail agent on one of their systems
20:58:21 <tdawson> That's one of the things we had to work around for Content Resolver.
20:58:35 <SSmoogen> actually I wonder if doing `dnf install *sendmail` would do that also
20:59:41 <tdawson> I'm going to close it here ... let that be an exercise for the week.
20:59:54 <salimma> alphabetical ordering :p
21:00:01 <tdawson> Thank you all for coming this week, and thank you for the good discussions.
21:00:07 <salimma> thanks tdawson
21:00:13 <tdawson> I'll talk to ya'll next week if not sooner.
21:00:22 <tdawson> #endmeeting