20:00:37 <tdawson> #startmeeting EPEL (2021-06-23)
20:00:37 <zodbot> Meeting started Wed Jun 23 20:00:37 2021 UTC.
20:00:37 <zodbot> This meeting is logged and archived in a public location.
20:00:37 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:37 <zodbot> The meeting name has been set to 'epel_(2021-06-23)'
20:00:38 <tdawson> #meetingname epel
20:00:38 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca
20:00:38 <tdawson> #topic aloha
20:00:38 <zodbot> The meeting name has been set to 'epel'
20:00:38 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson
20:00:48 <rsc> .hello robert
20:00:49 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:00:51 <dcavalca> .hi
20:00:53 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:01:06 <carlwgeorge> howdy everyone
20:01:06 <tdawson> Hi rsc
20:01:11 <nirik> morning
20:01:18 <tdawson> Hi dcavalca
20:01:21 <tdawson> Hi carlwgeorge
20:01:25 <tdawson> Hi nirik
20:01:35 <pgreco> hello
20:01:55 <tdawson> Hi pgreco
20:02:45 <michel> .hello salimma
20:02:46 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:03:04 <tdawson> Hi michel
20:03:41 <tdawson> Hmm ... we have most everyone who usually shows up.  Should I get started a minute or two early?
20:04:18 <tdawson> #topic Old Business
20:04:26 <tdawson> EPEL-Packaging-SIG
20:05:12 <tdawson> I have a question about the SIG, and I seem to remember we mentioned it.  But, is there a reason why we don't have it as a group?
20:05:34 <dcavalca> I think we do?
20:05:44 <nirik> I thought it was... yeah
20:05:54 <michel> tdawson: as a FAS group?
20:06:00 <michel> we do
20:06:05 <tdawson> Hmm ... I don't see it here - https://pagure.io/groups
20:06:09 <nirik> https://src.fedoraproject.org/group/epel-packagers-sig
20:06:22 <nirik> pagure.io is the 'other' pagure. ;)
20:06:45 <tdawson> *sigh*
20:07:05 <nirik> they are two different instances... so seperate groups, etc.
20:07:24 <michel> should we be in the pagure.io as well? or is there no need
20:07:28 <tdawson> Yep ... sorry
20:07:50 <tdawson> I don't really see the need, but I think I'm going to update the wiki to point to the correct place.
20:08:36 <tdawson> OK, besides my looking in the wrong place, any other SIG things to talk about?
20:08:38 <michel> on the automated tool I brought up last week -- haven't had time to work on it. trying to wrap up my projects at work for the half (though good news: after this I don't have to deal with anything not Fedora/CentOS/upstream anymore)
20:09:40 <dcavalca> I need to get xcompmgr unretired and built for epel because some chromium things we build at fb depend on it...
20:09:43 <tdawson> Let's hope your project wrap up soon.
20:10:30 <michel> given it's Jun 23, yup :) just dotting the is and crossing the 't's
20:10:53 <michel> dcavalca: that should just need a re-review right? (and ugh Chromium)
20:11:07 <michel> oh wait, and a fesco ticket to unblock the package
20:11:15 <dcavalca> yeah, though the upstream looks pretty dead
20:11:26 <dcavalca> hopefully it still builds
20:11:46 <michel> dead-er than other X11 bits? or as dead
20:12:00 <dcavalca> probably about the same lol
20:12:38 <michel> probably not too bad then
20:12:51 <tdawson> I know you both know, but I'll just reitterate it.  If you are reviving a dead package, be prepared if CVE's come up.
20:13:19 <tdawson> Anything else before we move to -next ?
20:13:34 <dcavalca> tdawson: yup, that's also why I wasn't enthusiastic about it
20:13:51 <tdawson> :)
20:14:01 <tdawson> OK, moving on to epel8-next
20:14:17 <tdawson> carlwgeorge: Any news or updates?
20:15:12 <carlwgeorge> no change from last week.  i haven't gotten any feedback about epel8-next working or not working, but i do know tdawson is doing some builds so i guess i would have heard if it was fundamentally broken.
20:15:16 <tdawson> I know for me, it's working pretty good.  I've been stress testing bodhi
20:15:44 <michel> I need to check if nextcloud-client is built for it or not
20:15:51 <tdawson> bodhi doesn't like it when you give it more than 100 packages in an update, but it does them. :)
20:15:59 <carlwgeorge> we did notice one edge thing, overrides for epel8 don't apply to epel8-next, but there is no clean way to do the tag inheritance to solve that.  it's a pretty edge case regardless, so not worth addressing.
20:16:12 <michel> speaking of epel-next, any idea how we can make src.fedoraproject.org aware of it?
20:16:23 <carlwgeorge> as far as i'm concerned, i'm ready to hit "push to stable" whenever
20:16:29 <michel> it shows the Fedora, EPEL and ELN builds associated with a package but not next
20:16:48 <tdawson> carlwgeorge: I was thinking about that, and I don't think epel8-overrides should be in epel8-next
20:17:01 <michel> that's a no - https://bugzilla.redhat.com/show_bug.cgi?id=1972910 -- I'll ping it today
20:17:30 <tdawson> The reasoning is thus.  Let's say you have a package that has to be in -next, and you need to do some update, like a security update, but it has to be different in both epel8 and epel8-next, and it needs an override.
20:17:35 <michel> do we have overrides for epel-next? is it worth having?
20:18:19 <nirik> michel: likely just needs adjusting in pagure-dist-git... file issue here: https://pagure.io/pagure-dist-git
20:18:31 <carlwgeorge> michel: yes there is an override
20:18:31 <tdawson> I know that's alot of if's  ... but I was just thinking of it while I was compiling kde ... it's going to take a while, and they have to have overrided, and if I was trying to do epel8 builds at the same time with overrides, things would be a mess.
20:20:05 <carlwgeorge> yeah there are cases where it would make sense but also cases it would be incorrect, so it's unsolvable as far as i'm concerned
20:20:19 <tdawson> Yep
20:21:01 <tdawson> For me, epel8-next is working, the whole pipeline from branching, building, updating, and consuming.
20:21:25 <carlwgeorge> so should i push https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-159d68a2ef to stable or give it more time?
20:21:41 <michel> #info https://pagure.io/pagure-dist-git/issue/140 filed to request `epel8-next` to be shown on src.fedoraproject.org
20:21:41 <tdawson> I'm ok with it.
20:22:10 <michel> yeah, I'd say push
20:22:12 <tdawson> carlwgeorge: Do you want a vote on it?  Make it official?
20:22:31 <carlwgeorge> sure why not
20:22:32 <carlwgeorge> +1
20:22:37 <tdawson> +1
20:22:39 <michel> +1
20:22:47 <nirik> -1... just kidding. +1
20:22:47 <dcavalca> +1
20:23:00 <carlwgeorge> lol nirik
20:23:54 <pgreco> sorry, +1
20:24:10 <tdawson> #info epel8-next is ready for stable release: Voting 6(+) 0(-)
20:24:18 <pgreco> I'm dealing with some dumpster fires here ;)
20:24:33 <carlwgeorge> i'll work up an email to epel-announce
20:24:49 <tdawson> carlwgeorge: Thanks.
20:25:21 <tdawson> Anything else for -next before we move on?
20:25:56 <carlwgeorge> i don't think so
20:26:27 <tdawson> I'm going to lump the old businesses in one:  documentation, badges and logos.
20:26:36 <tdawson> I didn't see any progress on any of them.
20:26:50 <tdawson> I'm going to re-ping Petr, see if he's less busy now.
20:27:24 <tdawson> Did anyone see any progress on badges and/or logos?
20:28:01 <carlwgeorge> what do yall think of this suggestion https://pagure.io/design/issue/770#comment-740116
20:28:16 <carlwgeorge> use an ant in the "bubble"
20:28:40 <tdawson> As much as I like it, I think it might be confusing to most people.
20:28:55 <michel> yeah, not sure what the ant would signify here
20:29:03 <carlwgeorge> i initially liked it but i'm starting to worry about the association with "bugs"
20:29:11 <dcavalca> eh, I do love the "corporate drone" badge, but yeah, I suspect most people will thing bugs
20:29:12 <tdawson> I think your suggestion looks the best - https://pagure.io/design/issue/770#comment-737519
20:29:19 <carlwgeorge> michel: several epel badges use ants
20:29:39 <carlwgeorge> https://badges.fedoraproject.org/badge/corporate-drone
20:30:20 <michel> I keep forgetting that's an ant :p
20:31:51 <tdawson> So, sounds like we want to say no to the last one, with the ant in the bubble
20:32:29 <tdawson> I like the idea of the logo being something simple, like carlwgeorge's, and then we get something funner for the mascot.
20:33:24 <michel> something that signifies the 'extra' part would be nice, but I don't have an idea just yet. failing that, the Centaur
20:33:51 <tdawson> Yep
20:34:09 <tdawson> I'm going to move on, cuz I have a couple of things for openfloor.
20:34:19 <tdawson> #topic EPEL-7
20:34:40 <tdawson> Anything for EPEL7
20:35:04 <carlwgeorge> sometime this week i want to take a look at forced retirements in epel7, like i did last week for epel8
20:35:22 <carlwgeorge> hopefully i don't run into any other cases similar to lmdb-devel
20:35:26 <tdawson> :)
20:35:40 <tdawson> Yep, but it needs to be done.
20:35:55 <michel> theoretical question (because we prefer using 8 at work) -- if there's a package with a CVE in c7 that won't be fixed upstream, can someone add it to EPEL?
20:36:04 <tdawson> At some point, in my grand wish list, these are automatically tagged.
20:36:07 <carlwgeorge> i don't think rhel7 has the unshipped -devel problem, at least not at the same scale as rhel8
20:36:24 <tdawson> True
20:36:33 <carlwgeorge> michel: by policy no
20:37:21 <carlwgeorge> if a package is marked as deprecated in rhel, it can be added to epel (see golang in epel7)
20:37:38 <carlwgeorge> but if it's just a declined cve, nope
20:38:16 <michel> ack
20:38:42 <tdawson> #topic EPEL-8
20:39:11 <tdawson> Sorry, didn't mean to rush ... were we done with 7?
20:39:47 <michel> I think so
20:39:49 <carlwgeorge> yeah
20:40:03 <tdawson> For 8, I did want to talk about missing devel packages.
20:40:42 <tdawson> I'm going to assume ya'll read me email on my proposal ... if you haven't, I can summarize.
20:41:04 <carlwgeorge> summary is nice for the meeting log anyways
20:41:11 <tdawson> Good point
20:41:17 * carlwgeorge did actually read the thread this time
20:42:04 <tdawson> The proposal is to grab the missing packages from the CentOS koji, directly, and build our own "devel" repo that epel8/epel8-next would use.
20:42:41 <tdawson> This would require a list of known missing packages, along with what source rpm builds them.
20:43:33 <tdawson> The idea world this would be automated, and it would know when the corresponding source rpm was updated, then grab the missing packages then.
20:43:59 <pgreco> what about el8_X packages that won't be built in koji?
20:44:31 <dcavalca> this seems a... roundabout way to solve this issue, but sure
20:44:38 <michel> somewhere, there's a list of which -devel packages to not publish, right?
20:44:46 <michel> is there any way to just reuse it?
20:44:48 <dcavalca> assuming it can be automated within reason, it should be fine
20:45:09 <dcavalca> I assume somewhere in pungi?
20:45:37 <carlwgeorge> not exactly
20:45:39 <nirik> something would need to be written... I don't know of anything that does this.
20:45:39 <tdawson> That's a very good point (el8_X).  carlwgeorge I think you would know.  Will stream have packages in koji that have the el8_X dist tag?
20:46:21 <dcavalca> fetching packages from koji is fairly trivial, we do that for hyperscale as part of our CI
20:46:24 <tdawson> Yes, something would have to be written.  Which is my question, should we even entertain this way of doing things?
20:46:26 <carlwgeorge> dcavalca: you can look at the pungi configs as a starting point, but it's not a simple list
20:46:31 <dcavalca> the tricky bit is probably getting the list in the first place
20:46:32 <carlwgeorge> tdawson: yes
20:47:10 <tdawson> carlwgeorge: Cool.   Then that relieves that concern I had.
20:47:35 <carlwgeorge> what was the concern?
20:48:01 <tdawson> I think we wouldn't have to have them ALL.  It could be a list that get's added to as people have problems.
20:48:20 * nirik ponders.
20:48:21 <rsc> dcavalca: why should it be tricky to get the list? Rocky should know which packages they recently needed to hide?
20:48:36 <pgreco> if everything that ends up in rhel was previously built in koji, this looks great
20:48:36 <carlwgeorge> that was the initial idea with centos-devel until rhel bu mostly shut it down
20:48:52 <nirik> so, we are just downloading them and making a repo? with just the -devel package?
20:49:13 <tdawson> carlwgeorge: Oh, my concern that there might be some epel8 packages that we wouldn't see in Stream because they were released in between.
20:49:24 <carlwgeorge> rsc: take a look at the pungi configs and you'll see what we mean
20:49:37 <dcavalca> rsc: let me rephrase -- I think it'd be great if the list were easily available, but I don't believe it currently is
20:50:16 <tdawson> Let's say somewhere between RHEL 8.5 and 8.6 package foo-1.2.el8_5 is released.  Would we see that in CentOS Stream as el8_5 or as something else?
20:50:53 <pgreco> that was my worry, I'm expectin that at that point, stream would have foo-1.2-2.el8
20:50:57 <carlwgeorge> the way cl8 packages (including el8_x ones) work now is we build then in koji, and tag them to either just cl8 or both cl8 and cs8, depending on whether or not cs8 already has a newer nvr
20:51:27 <pgreco> so we're bound to have an incomplete set
20:51:35 <carlwgeorge> it depends on whether or not a higher nvr was already created in the 8.6.0 compose
20:51:56 <tdawson> carlwgeorge: But it's built?  whether or not there is a newer version?
20:52:15 <carlwgeorge> yes
20:52:26 <nirik> this repo will also need the regular package too... and we will have to be carefull about the priority we set it in koji.
20:52:30 <carlwgeorge> well, until december
20:52:30 <tdawson> If we're just reaching into koji, not a repo, we just need it to be built.  So, cool, it should work.
20:52:41 <carlwgeorge> i see the problem now
20:52:54 <tdawson> nirik Why will the repo need the regular package too?
20:53:05 <nirik> koji operates on source packages.
20:53:35 <carlwgeorge> after december, if rhel releases foo-1-2.el8_5, and stream has moved on to foo-1-3.el8, foo-1-2.el8_5 would never be built
20:53:38 <nirik> if there is a foo in rhel/base repos, it will use all the packages that has and ignore libfoo in another repo thats from the same src.rpm
20:53:47 <pgreco> carlwgeorge: exactly
20:54:01 <tdawson> carlwgeorge: Ouch ... ok, that will not work as well. :(
20:54:12 <nirik> so all of the things need to be in the same place.
20:54:46 <tdawson> nirik That's why I was saying we create our own repo, pull packages directly from kojihub https://kojihub.stream.rdu2.redhat.com/kojifiles/packages/libuser/0.63/2.el9/x86_64/libuser-devel-0.63-2.el9.x86_64.rpm
20:55:51 <nirik> yes, but then if there is a libuser in base rhel, it will see that and use it, and then when it looks for libuser-devel it will see that one and say 'nope, I already got libuser from that other repo, ignore'
20:56:08 <dcavalca> tdawson: yeah, we could have a batch job to fetch all the -devel packages then run createrepo
20:56:17 <carlwgeorge> my thinking is the most correct way to fix this is to get rhel to make it's buildroot available to fedora's koji
20:56:21 <tdawson> nirik Oh ... it does that.
20:56:31 <tdawson> carlwgeorge: I agree with you there.
20:56:36 <dcavalca> carlwgeorge: no objection there
20:57:13 <carlwgeorge> i can't say whether or not that would be more or less work than creating an epel-devel repo
20:57:23 <michel> is that likely? I take it the separate -devel repo is a stop gap / workaround for the buildroot not being exposed
20:57:38 <carlwgeorge> i'm not sure that anyone has asked for that specifically
20:57:38 <nirik> carlwgeorge: it was discussed long ago and disgarded, but you can ask again.
20:57:43 <carlwgeorge> ah
20:57:52 <tdawson> I think the biggest problem is the el8_X issue.  Followed by nirik's.
20:58:16 <carlwgeorge> fwiw it's not specific to el8_x packages
20:59:06 <nirik> I think the 'make a epel- version of the package that just ships the devel part' is easier.
20:59:07 <tdawson> carlwgeorge: I'll take your proposal back to the people who suggested this proposal.  See if maybe they can give us access ... *sigh* but I don't really have hope they'll give us access.
20:59:32 <carlwgeorge> you could have the same thing if rhel ships foo-1-5.el8 but stream goes from foo-1-4.el8 to -6.el8
20:59:34 <tdawson> nirik Yep ... carlwgeorge showed me how to make an <package>-epel package, and I got it done in a day.
21:00:16 <carlwgeorge> yeah doing one-off foo-epel packages is the path of least resistance, but only solves it one package at a time
21:00:25 <tdawson> Looks like our time is up ... was there anything else that people wanted to bring up?
21:01:15 <tdawson> Thank you all for coming this week, and for the good discussions.
21:01:23 <tdawson> Talk to you all next week.
21:01:26 <michel> thanks tdawson!
21:01:31 <dcavalca> thanks tdawson
21:01:31 <tdawson> #endmeeting