21:01:17 <tdawson> #startmeeting EPEL (2022-01-05) 21:01:17 <zodbot> Meeting started Wed Jan 5 21:01:17 2022 UTC. 21:01:17 <zodbot> This meeting is logged and archived in a public location. 21:01:17 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 21:01:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:01:17 <zodbot> The meeting name has been set to 'epel_(2022-01-05)' 21:01:17 <tdawson> #meetingname epel 21:01:17 <zodbot> The meeting name has been set to 'epel' 21:01:17 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca 21:01:17 <tdawson> #topic aloha 21:01:17 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson 21:01:24 <salimma> .hi 21:01:25 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name> 21:01:28 <rcallicotte> .hi 21:01:28 <carlwgeorge> .hi 21:01:28 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org> 21:01:31 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com> 21:01:32 <rsc> .hello robert 21:01:34 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de> 21:01:36 <tdawson> Hi salimma 21:01:40 <tdawson> Hi carlwgeorge 21:01:46 <tdawson> Hi rcallicotte 21:02:00 <tdawson> Hi SSmoogen 21:02:03 * rcallicotte waves 21:02:10 <tdawson> Hi rsc 21:02:50 <tdawson> I'm assuming everyone had good holidays, cuz ya'll are here bright and early. 21:04:18 <SSmoogen> or we are very tired of sitting waiting for a meeting 21:04:34 <tdawson> :) 21:05:09 <tdawson> #topic EPEL Issues 21:05:10 <salimma> I do miss meetings after a while :) for a few weeks I only get to talk to my wife, my babbling baby and two cats 21:05:17 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open 21:06:01 <tdawson> If people don't mind, let's start with the one I think we've already finished - Migrating the EPEL Mock config from CentOS Linux to RHEL or AlmaLinux? 21:06:11 <tdawson> .epel 133 21:06:12 <zodbot> tdawson: Issue #133: Migrating the EPEL Mock config from CentOS Linux to RHEL or AlmaLinux? - epel - Pagure.io - https://pagure.io/epel/issue/133 21:06:44 <tdawson> Didn't this discussion get finished over on the mock pull request? 21:07:04 <tdawson> https://github.com/rpm-software-management/mock/pull/817 21:08:11 <carlwgeorge> it's merged and tagged and in testing in bodhi 21:08:22 <tdawson> So, are we ok closing this then? 21:08:53 <tdawson> I didn't want to just close it, because we'd had a large discussion about it. I thought I'd ask first. 21:09:03 <SSmoogen> i am ok with it 21:09:26 <carlwgeorge> there is negative karma on the updates, looks like some more work needed in rpkg, but from the epel issue perspective it's "resolved" 21:09:48 <carlwgeorge> i.e. we've given our recommendation and the rest is implementation details that are out of our hands 21:10:06 <tdawson> Sounds good. Let's closet that then. 21:10:25 <tdawson> /closet/close/ 21:11:11 <tdawson> .epel 139 21:11:12 <zodbot> tdawson: Issue #139: Permission to delete epel9-next branches if they are reachable from he epel9 branch - epel - Pagure.io - https://pagure.io/epel/issue/139 21:12:07 <tdawson> This confused me at first, but in the end, it basically means people can request to have the epel9-next branch removed if they wish. 21:12:52 <carlwgeorge> miro is awesome, but to be clear "The branches were created where the instructions were different" isn't accurate, the branches were created when there were no instructions 21:12:58 <tdawson> I guess it is the policy, that once something is created, it can never be removed. But some people requested epel9-next branches but they think they will never want them. 21:13:15 <SSmoogen> they aren't removed if a build was made against them 21:13:21 <salimma> it doesn't matter if the branches are around, right? as long as the NEVRA in epel9 is higher 21:13:40 <SSmoogen> if no build was made against them then they get removed by releng but they will want to make sure it is ok with us 21:13:41 <salimma> I forgot which package, but I did come across one that was built for epel9-next but not epel9 21:13:42 <rcallicotte> salimma: thats what I thought 21:13:54 <carlwgeorge> SSmoogen: should be fine as long as the commit is in another branch, right? 21:13:56 <salimma> I'm +1 on allowing empty branches to be removed 21:14:09 <rcallicotte> same 21:14:22 <SSmoogen> carlwgeorge, I don't know myself.. I am parroting here :) 21:14:30 <salimma> will make it easier to keep track of which packages need to be rebuilt for Stream, once RHEL9 is GA 21:14:33 <SSmoogen> pieces of eight, pieces of eight 21:15:19 <tdawson> I'm +1 for this as well. 21:15:24 <carlwgeorge> koji builds reference commits not branches, thus i'm +1 on "can be deleted if commits exist in epel9 branch" 21:15:47 <tdawson> I personally will not be requesting my branches be removed, but that's because I know at some point I'll be requesting them again. 21:15:56 <salimma> carlwgeorge: TIL 21:16:06 <carlwgeorge> removing them doesn't block them from being created again, right? 21:16:11 <tdawson> Correct 21:16:20 <salimma> yeah, same. esp since branch requests need a human-triggered batch process right now 21:16:33 <salimma> (and that flaky test if the branch is allowed) 21:16:42 <carlwgeorge> seems like permission granted, kick it over to releng now 21:17:04 <SSmoogen> +1 21:17:08 <tdawson> Sounds good. 21:17:35 <tdawson> Look unanimous 21:17:47 <tdawson> OK, moving on ... 21:17:57 <tdawson> .epel 134 21:17:58 <zodbot> tdawson: Issue #134: Policy for missing subpackages - epel - Pagure.io - https://pagure.io/epel/issue/134 21:18:21 <tdawson> I know we had a long discussion on this, but I honestly don't remember what the final outcome was, if there was one. 21:19:07 <carlwgeorge> i propose we take tdawson's last comment on the issue as policy 21:19:11 <salimma> oh, mea culpa 21:19:19 <salimma> I meant to write up a porposal and share it, but I didn't get round to it 21:20:13 <salimma> but yes, I agree that policy-wise, we use tdawson's 21:20:14 <rsc> Fun, so gcc-epel was wrong. 21:20:26 <rcallicotte> +1 for tdawson policy 21:20:31 <salimma> so .. I'll rename iptables-epel to iptables-extras too, to be consistent 21:21:04 <salimma> I like being able to scan the list of '-epel' packages and use that to nudge the RHEL people to release those packages 21:21:42 <carlwgeorge> i'm also fine with it being a SHOULD policy, not a MUST, to not force people to rename packages 21:22:02 <tdawson> Agreed 21:22:05 <salimma> yeah, make it a SHOULD, though I'll personally rename mine just because 21:22:09 <rsc> +1 for SHOULD rather MUST 21:22:49 <tdawson> If we make my last comment a SHOULD policy, is there anyone against this? 21:22:57 <SSmoogen> or a MUST for all new packages? 21:23:09 <SSmoogen> grandma the rest in 21:23:16 <tdawson> Ahh ... good idea. 21:23:50 <tdawson> I like that better. Then we don't have to go back and possibly break things. 21:23:56 <carlwgeorge> what SSmoogen said 21:24:32 <salimma> nice 21:24:43 <tdawson> And it's the beginning of the new year, so we can draw the line in the sand right here. 21:24:45 <carlwgeorge> I believe that's how things work in general for fedora guidelines, even MUST items 21:24:51 <salimma> so new packages MUST be called -extras, old packages SHOULD be renamed 21:25:06 <SSmoogen> s/SHOULD/COULD/ 21:25:25 <SSmoogen> s/COULD/MIGHT IN A COLD DAY AND I HAVE A LOT OF FREE TIME/ 21:26:39 <SSmoogen> I think rsc has enough on their plate to even want to deal with a SHOULD 21:27:33 <salimma> true. let's not use SHOULD and maybe say "may be renamed if the maintainer wishes" 21:28:10 <rcallicotte> "at the maintainer's discretion"? 21:28:14 <SSmoogen> +21 21:28:26 <salimma> rcallicotte: +1 21:29:08 <tdawson> Is this our official vote? I'm +1 with rcallicotte 's wording. 21:29:15 <rsc> rcallicotte: +1 21:30:14 <salimma> I think so, yeah 21:31:45 <tdawson> OK ... I'll get that written up and in a documentation pull request. 21:32:00 <tdawson> We can tweak the wording in there. 21:32:33 <tdawson> That was the last of the EPEL Issues. 21:32:58 <SSmoogen> cool 21:33:16 <rcallicotte> nice 21:33:56 <tdawson> I'm going to go through the rest of the other topics, feel free to bring something up out of order if you want. 21:34:02 <tdawson> #topic EPEL-7 21:34:46 <SSmoogen> nothing from me 21:35:04 <tdawson> #topic EPEL-8 21:35:37 <tdawson> The only thing I have is that I found some epel8 package requests while I was requesting epel9 ones. But, nothing really to bring up here. 21:35:38 <SSmoogen> CentOS 8 reached its last package push on 2021-12-31 . It will be removed from mirrors on 2022-01-31 21:35:46 <SSmoogen> #info CentOS 8 reached its last package push on 2021-12-31 . It will be removed from mirrors on 2022-01-31 21:35:54 <tdawson> Oooohhh 21:36:00 <tdawson> Much better than what I had :) 21:36:35 <SSmoogen> #info choose a way to do your epel builds with the new mock once it passes testing 21:36:36 <carlwgeorge> queue the next round of abuse from disgruntled users 21:36:46 <rcallicotte> oh boy 21:36:56 <salimma> oh, one thing for centos 8 21:37:33 <salimma> if you want to use a sidetag as an additional repo ... that's not possible with mock, is it, unless you use rhelepel8 ? 21:38:34 <SSmoogen> I would think it would work for any of the ones.. if it worked with CentOS 21:39:10 <tdawson> I don't do "side-tags", but I do a local repo that I update with each build. I didn't even know it was an option with mock. 21:39:47 <carlwgeorge> should be doable with, side-tags have a koji repo and mock configs can have arbitrary repos added to them 21:39:54 <SSmoogen> mock --chain --localrepo=/my/homedir/repos 21:40:03 * Eighth_Doctor waves 21:40:17 <salimma> tdawson: it works with Fedora just fine 21:40:18 * tdawson hurries and writes that down. 21:40:46 <salimma> with epel8, the problem is that since the side tag builds against RHEL 8, sometimes the exact NEVRA is not available using cs8 as the base 21:40:50 <SSmoogen> tdawson, it is the replacement for the venerable mockchain which I used to test my rebuilds of EPEL-8 21:41:06 <tdawson> Cool 21:41:09 <salimma> oh, mock --chain sounds awesome 21:41:15 <carlwgeorge> when i'm in that situation i usually just make a temp copr project 21:41:37 <tdawson> Hi Eighth_Doctor 21:41:45 <Eighth_Doctor> I'm the weirdo that does things quite differently :) 21:42:19 <tdawson> Anything else epel8 related? 21:43:37 <tdawson> #topic EPEL-9 21:44:17 <tdawson> Looks like we are getting more and more packages in epel9 21:44:28 <carlwgeorge> i've got some numbers 21:44:28 <tdawson> https://bodhi.fedoraproject.org/releases/EPEL-9 shows 771 updates 21:44:50 <tdawson> Oop ... I'll be quite and let you go. 21:45:01 <salimma> I have some branch requests that have not been actioned in a while, so I'll proceed with the stalled requests this week 21:45:06 <carlwgeorge> for epel9 we have 2452 rpms in the repo, across 1082 koji builds and 631 bodhi updates (that have hit stable) 21:45:57 <Eighth_Doctor> I've got a fair number of stalled requests too, I think 21:46:00 <carlwgeorge> yeah i've also got a doc of various prospective epel9 packages in various states, missing deps, stalled process, upstream work, etc. 21:46:05 <tdawson> Very nice 21:46:19 <SSmoogen> I have some numbers also for number of systems deployed 21:46:37 <SSmoogen> it is 2 weeks old.. data for last week will show up tomorrow 21:47:01 <tdawson> new enough for me. :) 21:47:27 <SSmoogen> for CentOS Stream 9, there are 1961 systems which have been deployed for longer than a week and out of those, 224 have deployed EPEL-9 21:48:28 <tdawson> Very nice. 21:48:57 <SSmoogen> there are larger 0-1 week numbers but those could also be containers and such 21:49:20 <tdawson> I'm betting the deployed to epel ratio goes up as people start moving out of the testing phase. 21:49:55 <salimma> this is tangentially related, but do we know who builds the images for vagrantcloud ? 21:49:56 <carlwgeorge> it just occurred to me, with c9s in mirrormanager giving us countme metrics, we can finally get some good stats about the ratio of systems with epel enabled 21:50:15 <salimma> right now if you want to use cs9 with libvirt, looks like you'll have to use the unofficial box from Alma 21:51:17 <salimma> countme is amazing 21:51:41 <SSmoogen> numbers for epel-next-9 and epel-9 are nearly 1:1 21:51:57 <tdawson> Ha!! 21:51:58 <salimma> makes sense, the setup instructions do say enable both 21:52:18 <carlwgeorge> and the recommends 21:52:35 <SSmoogen> currently it looks like we have a 1:10 ratio for EPEL-9 to CS9 21:52:56 <carlwgeorge> that's much lower than i expected, but it is early days 21:53:33 <carlwgeorge> my guess is that will end up around 75% usage by 9.1 21:54:28 <tdawson> As much as I love numbers, anything else epel9 related before we move to the Open Floor? 21:54:35 <SSmoogen> nope 21:54:48 <carlwgeorge> good here 21:54:51 <tdawson> #topic General Issues / Open Floor 21:55:48 <salimma> my package branching tool is getting closer to being dogfoodable, I'll have a talk about it in Dojo 21:55:59 <salimma> so I'll soon be asking y'all what features to prioritize 21:56:08 <tdawson> salimma: awesome 21:56:59 <tdawson> Does it do dependencies? 21:57:22 <tdawson> Even if it's manual, being able to tell it, this depends on that, depends on that, would be nice. 21:58:08 <salimma> tdawson: yes it does 21:58:13 <tdawson> Cool 21:58:14 <salimma> well, as in, I'm writing that part today 21:58:38 <salimma> what will be tricky is I want it to do recursive deps, and also keep track of the packages you're tracking in a local state file 21:59:16 <salimma> e.g. pkg A has missing deps: B (bz# 100, opened on date1), C (bz# 200, opened on date2) 21:59:24 <tdawson> That sounds very useful. 21:59:30 <salimma> then you can batch-file the releng request for stalled ones 21:59:45 <salimma> yeah, I just wish I had time to finish this before we opened up EPEL9. but oh well. 22:00:19 <tdawson> It is what it is 22:00:27 <tdawson> And with that, it looks like our time is up. 22:00:42 <tdawson> Thank you all for the good dicussions, and for all your work on EPEL. 22:00:53 <tdawson> I'll talk to ya'll next week, if not sooner. 22:01:07 <tdawson> #endmeeting