20:00:31 #startmeeting EPEL (2022-06-08) 20:00:31 Meeting started Wed Jun 8 20:00:31 2022 UTC. 20:00:31 This meeting is logged and archived in a public location. 20:00:31 The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 20:00:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:31 The meeting name has been set to 'epel_(2022-06-08)' 20:00:31 #meetingname epel 20:00:31 The meeting name has been set to 'epel' 20:00:31 #chair nirik tdawson pgreco carlwgeorge salimma dcavalca 20:00:31 #topic aloha 20:00:31 Current chairs: carlwgeorge dcavalca nirik pgreco salimma tdawson 20:00:43 .hi 20:00:44 pgreco: pgreco 'Pablo Sebastian Greco' 20:00:45 .hi 20:00:47 salimma: salimma 'Michel Alexandre Salim' 20:00:47 hello all! 20:00:47 morning 20:01:00 hello 20:01:13 Hi pgreco 20:01:18 Hi salimma 20:01:25 Hi nirik 20:01:30 Hi smooge 20:01:39 .hi 20:01:39 dherrera: dherrera 'Diego Herrera' 20:01:45 Hi dherrera 20:03:56 .hellomynameis gotmax23 20:03:57 gotmax[m]: gotmax23 'Maxwell G' 20:04:03 Has anyone seen carlwgeorge today? 20:04:08 Hi gotmax 20:04:24 Hi tdawson! 20:04:26 I think he might not come 20:04:32 oh wow, never saw the hellomynameis form before 20:04:42 .misc help hello 20:04:42 gotmax[m]: (hello ) -- Alias for "hellomynameis $1". 20:04:53 `.hello` is an alias 20:05:13 ah right, I mean I just never saw anyone using it before 20:05:18 tdawson: I think he's on pto? 20:05:25 Ah, ok. 20:05:27 #topic EPEL Issues https://pagure.io/epel/issues 20:05:27 https://pagure.io/epel/issues?tags=meeting&status=Open 20:05:51 We have two things marked as a meeting ... let's start with the (hopefully) quick one 20:06:05 .epel 181 20:06:06 tdawson: Issue #181: Update pam_radius to v2.0 - epel - Pagure.io - https://pagure.io/epel/issue/181 20:06:42 yeah, I agree with what you said there tdawson. :) 20:07:15 We're ok with me just saying "Go ahead" and closing it? 20:07:23 yeah, looks fine 20:07:32 same here 20:07:37 yeah 20:07:44 +1 20:07:47 Sounds good ... I'll do that after the meeting. 20:07:57 .epel 39 20:07:58 tdawson: Issue #39: End of lifing CEPH in EL7 and process improvement - epel - Pagure.io - https://pagure.io/epel/issue/39 20:08:10 This is actually about the retirement proceedure. 20:08:11 I put up two PRs this morning (sorry for the late notice) 20:08:34 one to write the doc page and also add it to the navigation bar and the main policy and incompatible upgrade pages 20:08:49 the other one to note in the fedora retirement docs that for EPEL there might be additional constraints, and link to the new page 20:08:50 * nirik hasn't had a chance to read them yet 20:09:51 So, I read it, and the only concern I have is that it doesn't mention retiring a package because the maintainer no longer has time. 20:09:57 I like the steps outlined for end-of-lifing a package. I know its extra work but it can help explain why something is going away or not getting updated 20:10:06 Which, hopefully would fall into the "orphan" proceedure. 20:10:22 sorry I was looking at the ticket not salimma's message 20:10:23 tdawson: good point. in that case, do we recommend retiring, or just orphaning? 20:10:58 I would recommend orphaning ... but I've been looking at Fedora's steps, and they just don't work for EPEL. 20:10:59 that should be orphaning yes 20:10:59 orphaning seems fine iff we have a procedure for auto-retiring orphaned packages like Fedora I guess? 20:11:07 I would recommend retiring. Usually a package to come in is going to need major updates and reviews 20:11:35 Has anyone, who isn't the Main Owner of a package, tried to set the epel part to "Orphan" ? 20:11:36 so it is going to need work anyway to be taken over by someone 20:11:56 orphan is supposed to mean: "I can no longer take care of this, but perhaps someone else can" and retired is supposed to be 'I can no longer take care of this and no one else should either for XYZ reasons" 20:12:04 I ran into a bug a long time ago when I tried to orphan a package 20:12:20 I think the bug is fixed but it didn't orphan per branch... 20:12:21 yeah. ideally orphan+auto retire, but given it's harder to pick up a package in epel, and we don't have auto-retirement yet... maybe retire? 20:12:48 Oh, hi all. 20:12:53 Hi rsc 20:13:15 retiring and unreitring is anoying to releng... :( Of course there's no way to know if something will be unretired. 20:14:36 So ... I guess the question is, what are the next steps? 20:14:47 I would say we need to test that someone can orphan for an EPEL branch and not affect other branches. Then go with documenting that 20:14:59 perhaps we should decide a 'ideal' work flow and then see what needs to happen to get to that? 20:15:05 smooge: That sounds good. 20:15:11 nirik That also sounds good. 20:15:26 I think they can only set the assignee to 'orphan' on epel branches.. nothing more. 20:15:28 The issue is there's no automated way to pick up an orphaned EPEL branch 20:15:32 Unlike Fedora 20:15:34 are we ok with the PRs as is, and we can revise once we know what to do with 'packager does not have time' use case? 20:15:45 And you can't currently orphan individual EPEL branches 20:15:47 Maxwell (@gotmax) (He/Him): agreed 20:16:03 * nirik has still not read the pr, so I'd prefer to vote next week, but do as you all like. 20:16:10 For example, with ansible we're retiring epel7 but keeping epel8 and epel9. 20:16:28 on the flip side of the coin, getting access to EPEL branches if maintainer is unresponsive is also a pain, but we can discuss that later 20:16:32 I've only skimmed it as well, not gone in depth. I'm for waiting a week 20:17:02 we can vote next week anyway, to give people the chance to read. happy to follow up in the PRs themselves for now 20:17:03 +1 to final review and vote next week 20:17:09 +1 20:17:21 +1 20:17:45 +1 (I don't think my vote actually counts, though) 20:17:50 +1 20:17:50 +1 20:17:51 And if someone can try orphaning just epel ... see if they actually can, that would be good to know. 20:17:51 you showed up 20:18:13 Maxwell (@gotmax) (He/Him): I commented similarly the first time I voted :P 20:18:16 gotmax Yep ... you showed up. We care how you feel. 20:18:47 Thanks 20:19:04 OK, we'll leave that marked as "meeting" and bring it up next week. 20:19:27 #topic Old Business 20:19:42 I only have one thing from Old Business. 20:20:00 Do we want to talk about the epel-release thing now? 20:20:14 I was going to ask that :) 20:20:27 Will-It-Install has/had a bug, in that it was not checking all the -next packages. That has been fixed. 20:21:10 That's right ... I think that falls under "Old Business". 20:21:46 #link https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/YZPRZBVOGIOOUKZ55RHLNBRZMJJRKTNJ/#YZPRZBVOGIOOUKZ55RHLNBRZMJJRKTNJ 20:22:04 Basically, we're deciding whether the epel-release package should enable the CRB/Powertools repo 20:22:10 Ya. I proburbly should have marked the issue as "meeting" 20:22:15 I replied there a few mins ago, but basically, if DNF has a way to let you ship overrides to repo configs, that would neatly solve the issue 20:22:56 I started out thinking it was natual to do this, but now I think we shouldn't. 20:23:08 I think at this point, there are various ways we CAN do it. But the real question is SHOULD we do it. 20:23:21 I am in the "We should not do this in the default package" camp 20:23:28 hoping to work on that for DNF 5, the DNF maintainers seem responsive when this was brought up 20:23:30 if we 'should' I think it should be opt in 20:23:38 tdawson: Yup 20:23:48 yeah. like have epel-release-recommended or something that doesn't get pulled in by default 20:24:10 and that package would only have the script or the override 20:24:18 depending on the version, right? 20:24:27 Conan Kudo: We're talking about the epel-release CRB thing if you want to chime in :) 20:24:31 I'm ok having it be a seperate package. 20:24:35 * Eighth_Doctor waves 20:24:42 Hi Eighth_Doctor 20:24:42 .hello ngompa 20:24:43 Eighth_Doctor: ngompa 'Neal Gompa' 20:24:49 Hi Neal 20:24:52 I'm fine with it being a subpackage that the main package recommends 20:24:53 right now it will have to be a script. once we have the ability to override, then override is cleaner 20:25:02 yeah, separate package seems like the best "opt-in" 20:25:44 to be clear, this problem is largely caused by us being forbidden to do the right thing in CentOS Stream 20:25:56 A separate package wouldn't work with the current installation instructions 20:25:57 which is inherited by all CS/RHEL rebuilds 20:26:04 I mean a recommends 20:26:06 because we install from the URL 20:26:15 CentOS and rebuilds don't 20:26:23 True 20:26:27 installing from URL will still pull in dependencies, I think 20:26:35 We could change the installation instructions to use --repofrompath 20:26:38 if we recommend it, it would always get pulled in by default no? 20:26:56 yes any update will pull it in 20:27:00 gotmax Correct, but we could change the installation instructions. 20:27:04 the install instructions can be easily changed anyway 20:27:04 And update will 20:27:04 it needs to be a reverse required 20:27:07 *an 20:27:29 it needs to be opt-out rather than opt-in, IMO 20:27:29 right, so we shouldn't do that. At least I don't think we should. 20:27:36 it would only be effectively opt-in for RHEL 20:27:48 epel-release-fixescrb requires epel-release and we say that if you want to have a full experience out of the box, you install epel-release-fixescrb 20:27:58 well, it'd get eventually opt-out 20:28:46 smooge: yeah, that's nicer as it allows people to choose without forcing the behavior 20:29:29 s/fixescrb/usescrb/ or /turnsoncrb/ or /messeswithyoursubs/ 20:29:58 epel-secret-enable-everything-you-need 20:30:51 epel-enable-with-crb-not-supported-by-run-for-runtime-please-make-sure-you-want-this 20:30:58 I know it's not ideal for everyone's use case ... but it's sounding like we are heavily leaning towards the "seperate sub-package" 20:31:23 I think sub-package is the easiest opt-in 20:31:23 I think that would make the situation clearer 20:31:24 nirik Ha!! I know a couple R.H. people who would love that name. :) 20:31:53 at work we use the term 'clowntown' for this :) 20:32:25 OK, I'll write something up in the email ... and do a change to my pull request. 20:32:48 Thank you all for your input and discussion. 20:33:06 #topic EPEL-7 20:33:06 CentOS 7 will go EOL on 2024-06-30 20:33:13 * Eighth_Doctor sighs 20:34:06 Eighth_Doctor: I know, it's not totally what you want 20:34:12 when does ansible leave EPEL-7 ? 20:34:44 "We could change the installation..." <- dnf install --repofrompath='epel,https://dl.fedoraproject.org/pub/epel/8/Everything/$basearch' --repo=epel --nogpgcheck epel-release 20:34:56 This would pull in deps 20:35:05 nice and ugly. ;( 20:35:13 Yup 20:35:35 smooge: soon I guess. It's already EOLed by upstream... 20:35:38 well even uglier.. $basearch isn't defined 20:35:49 Maxwell (@gotmax) (He/Him): ooh, I see. because the other package is *also* in this repo you don't have enabled yet 20:35:51 good point 20:36:01 that was the only item I saw which was EL7 related 20:36:33 It would be nice if someone could read my containerd retirement email before I send it to epel-announce, but we can do that in #epel later. 20:37:45 nirik Did you already send an email to epel-announce with the retirement yet? 20:38:01 tdawson: The ansible one? 20:38:16 what about a two step? 20:38:37 keep the current install with && dnf -y install epel-letmedoeverythingforyou 20:38:40 Ya ... I was searching for it and couldn't find it. Sometimes I don't have good search stuff and get too much hits. 20:38:53 tdawson: https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/7RATG567ZHEY2TPJILDUNEKC23P25CZB/ 20:38:54 He did 20:39:12 several times. 20:39:31 so I think we can retire anytime... 20:39:33 Oh ... I thought that was just for epel-devel. OK, my bad. 20:39:37 Yep 20:39:52 Yeah, nobody can say we didn't announce it enough :) 20:40:29 Anything else for epel7? 20:40:53 Not from me 20:41:04 #topic EPEL-8 20:41:04 CentOS Stream 8 goes EOL in 2024-05-31 20:41:35 Other than the crb repo, I didn't see anything for epel8 this week ... did others? 20:41:44 I have an epel-rpm-macros PR 20:42:08 We don't really need to discuss that here 20:42:14 I just wanted to remind the maintainers 20:42:59 Basically, it backports some Fedora macros to make it easier to build packages for python38 and python39. 20:43:17 nice 20:43:47 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/44 20:43:51 cool.. 20:43:56 For those that want to look at it. 20:44:15 Thanks for linking it 20:44:41 I'll let people comment offline on that. Anything else for epel8 ? 20:45:27 I finally pushed ansible last week and got some bug reports that I addressed. 20:46:07 Thank you for that. 20:46:24 One of them requires the RHEL ansible-core maintainers to fix a bug, which probably won't happen in a timely manner :(. 20:46:33 Well, for both the rpm-macros, as well as your work on ansible. 20:46:44 I'm going to move on ... 20:46:46 #topic EPEL-9 20:46:48 +1 20:47:26 Anything for epel9? 20:47:32 Nothing from me 20:47:44 carlwgeorge usually has some numbers ... smooge do you have any numbers this week? 20:47:59 as of last week there were 14592 total systems countme 20:48:28 That's up by 4000 isn't it? 20:48:29 most were probably CI/containers with numbers for system of any 'length' to be calculated later 20:48:47 This week we have 6018 (+155) packages, from 2730 (+58) source packages 20:49:06 well apples oranges.. count=1 says 14592 count=2+ is a lot smaller 20:49:33 dherrera: Cool ... we're starting to close in on epel8 20:49:34 but partially because EL9 hasn';t been out long enough for many systems to move to count=2+ 20:50:28 smooge: But ... as they say ... give it time. :) 20:50:41 Other than numbers, anything for epel9? 20:50:59 I was excited that xfce is finally in -testing. 20:51:30 one thing to note - our Stalled EPEL Request policy, that we use mostly for 9, seems to ... result in inconsistent access being granted 20:51:55 #topic General Issues / Open Floor 20:52:08 e.g. you ask for EPEL Packagers SIG + the requester's FAS to be added, and you can get either the SIG only, the packager only, or both, granted, either collaborator access or sometimes even admin access 20:52:12 Sorry ... although ... this does fit into "General Issues" :) 20:52:25 oh yeah, it's fine in General Issues 20:52:31 huh... thats odd, given that one person have been processing all those. 20:53:10 I think it depends on if it goes the full time, or if one of the package maintainers (or co-maintainers) do the adding. 20:53:32 Is it possible that the packager stepped in and added you after you created the ticket but before releng acted on it? 20:53:40 I've found that when the package maintainers does it, they tend to just add me, not the group. 20:53:47 we can probibly look given examples... 20:54:06 some maintainers may be unaware of 'collaborator' access. 20:54:17 for getting admin access, I think it's the packager. one sec, I'm trying to find the issue that's the last I see. foolishly closed the ticket 20:54:21 the tab I mean 20:54:42 Ctrl+Shift+T 20:54:42 https://pagure.io/releng/issue/10806 20:55:43 It looks like you have collaborator on gnulib 20:55:49 maybe the template can be made more explicit (e.g. use bullet points for the list of people/group we want to be granted access) 20:55:57 yeah, I got granted collaborator, but epel-packagers-sig wasn't 20:56:08 Ah 20:56:18 https://src.fedoraproject.org/rpms/gnulib 20:56:59 feel free to reopen it and ask that the sig be added. 20:57:34 Ya, maybe a bit of a re-write on the template, list who to add in seperate bullets or something. 20:57:52 Although, yes, what nirik said. 20:57:57 I was debating whether to do that or do a bulk request for all the packages missing epel-packagers-sig. but yeah 20:58:46 We're running out of time, anything else before we close? 20:59:37 Thank you all for the good discussions. And especially, thank you for all your work on epel. 20:59:47 Talk to you next week, if not sooner. 20:59:52 Thanks, tdawson! 20:59:56 thanks tdawson! 21:00:01 #endmeeting