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