20:00:41 <tdawson> #startmeeting EPEL (2021-10-06) 20:00:41 <zodbot> Meeting started Wed Oct 6 20:00:41 2021 UTC. 20:00:41 <zodbot> This meeting is logged and archived in a public location. 20:00:41 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 20:00:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:41 <zodbot> The meeting name has been set to 'epel_(2021-10-06)' 20:00:41 <tdawson> #meetingname epel 20:00:41 <zodbot> The meeting name has been set to 'epel' 20:00:42 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca 20:00:42 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson 20:00:42 <tdawson> #topic aloha 20:00:51 <rsc> .hello robert 20:00:51 <nirik> ahoy and morning 20:00:53 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de> 20:01:09 <dcavalca> .hi 20:01:10 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com> 20:01:13 <tdawson> Hi rsc 20:01:19 <tdawson> Hi nirik 20:01:28 <tdawson> Hi dcavalca 20:01:37 <smooge> hello 20:02:27 <tdawson> Hi smooge 20:04:05 <carlwgeorge> .hi 20:04:06 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com> 20:04:19 <tdawson> Hi carlwgeorge 20:04:29 <tdawson> I just realized that I never asked ... did we have a meeting last week? 20:04:36 <dcavalca> tdawson: we did not 20:04:57 <tdawson> OK, then that makes it easy for me to know if anything needs to go on the agenda. :) 20:05:11 <tdawson> #topic Old Business 20:05:30 <tdawson> Let's start with epel9-next. carlwgeorge nirik any updates ? 20:05:52 <smooge> it is on the mirrors 20:06:05 <carlwgeorge> it == empty repodata 20:06:08 <nirik> well, an empty repo for it 20:06:20 <tdawson> Well ... cool anyway, even if it's empty. 20:06:26 <carlwgeorge> got a few pull requests merged for small pieces, right now waiting on another one for fedpkg so we can request branches 20:06:30 <smooge> yes.. but that is much much much further in the journey than I got with epel-8 for a while 20:06:33 <carlwgeorge> https://pagure.io/fedpkg/pull-request/453 20:07:11 <tdawson> What happens right now if we request branches? 20:07:23 <carlwgeorge> i think fedpkg will decline it 20:07:25 <carlwgeorge> i can verify 20:07:34 <carlwgeorge> after that's merged, i can proceed with epel-release and epel-rpm-macros. do we know yet if the latter needs any macros to start with? 20:08:18 <nirik> we also still need to add it to bodhi or updates won't go anywhere. ;) 20:08:30 <carlwgeorge> "Could not execute request_branch: The connection to infrastructure.fedoraproject.org failed while trying to determine if this is a valid EPEL package. The status code was: 404" 20:08:51 <smooge> yeah that sounds right. 20:09:19 <carlwgeorge> so that means that both fedpkg and fedscm-admin validate a package is valid for epel 20:09:57 <carlwgeorge> nirik: yeah adding it to bodhi is next on the list, i think we can do it now but mboddu wanted to wait till we actually had epel-release done 20:10:31 <nirik> also we are in freeze... 20:11:51 <tdawson> Don't quite understand why mboddu wanted to wait until epel-release is done ... but freeze ... yep 20:12:45 <carlwgeorge> there was also tdawson's suggestion of not using the c9s buildroot 20:13:10 <carlwgeorge> personally i'm fine either way, we would just have to do-over the external repo for the build target 20:13:31 <tdawson> carlwgeorge Correct ... but as soon as I heard grobisplitter ... I was feeling like it was best to leave it as it is for the time being. 20:13:40 <nirik> is there a released c9s set of repos already? 20:14:08 <carlwgeorge> http://mirror.stream.centos.org/9-stream/ 20:14:16 <nirik> oh yeah. ok. 20:14:29 <nirik> but yeah, grobisplitter... so it would be more like 8... 20:15:00 <tdawson> Eventually, ya. 20:15:26 <carlwgeorge> there are no modules in the buildroot, but if we switched to the published repos for consistency with epel9 (built against published rhel8) i think we'd still have to grobisplit to not have module metadata errors 20:16:29 <tdawson> If I remember, grobisplitter was a delay on epel8, which was why I was thinking of staying with buildroot for a little bit, get things settled in. 20:16:40 <nirik> I'd say lets stick to the buildroot until/unless we have a reason to switch? 20:17:02 <carlwgeorge> i think the delay was grobisplitter didn't exist yet, to be fair 20:17:11 <nirik> and when rhel9 comes out (or before) we can test if we need grobisplitter. If we could stop using it that would be a win. 20:17:32 <carlwgeorge> but like i said, i'm fine either way 20:18:07 <nirik> me too, but I think it's better to try and do without grobisplitter in hopes of someday retiring it and having one less part to blow up. 20:18:39 <carlwgeorge> works for me 20:19:15 <tdawson> nirik So try to do the normal way (AppStream, BaseOS, CRB) from the start? Without grobisplitter? 20:19:31 * mboddu reading back 20:19:48 <nirik> yeah. Might work. Might not. 20:19:58 <smooge> nirik, I will amend my script which mirrors 8 and 8-stream to add in 9-stream 20:20:00 <carlwgeorge> i believe koji will barf on that 20:20:15 <carlwgeorge> i could be wrong 20:20:17 <smooge> unless carlwgeorge has done it already 20:20:50 <tdawson> mboddu: I believe we were wondering on your reasoning on not wanting to update bodhi for epel9-next until we have epel-release done. 20:20:53 <mboddu> carlwgeorge, tdawson : I wanted to wait for creating bodhi release until we have the fedpkg fixed, not the epel-release, I dont want to people to see epel9 next release in bodhi and start requesting branches which fail 20:20:56 <carlwgeorge> nope, nirik set up a mirror of the c9s buildroot, and we configured the build target to use that 20:21:19 <carlwgeorge> mboddu: ah, i mixed those up, my mistake 20:21:22 <tdawson> mboddu: Ah, ok. That makes sense. 20:21:24 <smooge> ah ok 20:21:45 <mboddu> No problem :) 20:21:54 <smooge> grobisplitter may work for EL9 since the default packages are not modules 20:21:57 * mboddu now checks why this meeting is not on his calendar 20:22:03 <smooge> having no grobisplitter may work for EL9 since the default packages are not modules 20:22:07 <smooge> geez smooge 20:22:08 <nirik> I'm not sure if it will or not, we do set the 'module-fixes' or whatever it is to rpm to tell it to upgrade module rpms to newere... but I don't know if the metadata will break anyhow. 20:22:31 <nirik> module_hotfixes 20:22:45 <nirik> Set this to True to disable module RPM filtering and make all RPMs from the reposiā 20:22:45 <nirik> tory available. The default is False. This allows user to create a repository with 20:22:45 <nirik> cherry-picked hotfixes that are included in a package set on a modular system. 20:23:28 <tdawson> carlwgeorge nirik Since we are frozen right now anyway ... maybe now would be a good time to see if we can work without grobisplitter ... or if it doesn't, if grobisplitter will "just work" 20:23:41 <smooge> yeah we may not want that for el9 since it would lead to having the non-default modules also show up 20:24:15 <nirik> yeah, it all depends on how dnf does it... will take some playing around and trying things I am pretty sure. 20:25:35 <smooge> and I am wrong.. it looks like they don't have non-modular packages as defaults 20:26:06 <carlwgeorge> last i checked container-tools was the only module, but more modules are planned to be added later (non-default streams) 20:26:21 <carlwgeorge> i also saw some chatter about making the default container-tools non-modular as well 20:26:51 <smooge> well its clear I have no idea what is going on so should stop trying to be "helpful" 20:26:57 <mboddu> (I have to leave in few min, I didn't see this meeting in my calendar and planned something else, if you guys want me for anything else, please let me know now or else I will respond when I get back) 20:26:58 <tdawson> :) 20:27:19 <tdawson> mboddu: Thanks for clearing things up about bodhi 20:27:44 <carlwgeorge> i'm considering hacking my local fedpkg to allow me to request epel-release just to move forward with that 20:28:25 <tdawson> carlwgeorge It's a good idea. Get the basic packages started. 20:29:11 <mboddu> carlwgeorge: I can process the tickets 20:29:28 <mboddu> But when you request them, please make sure to ping me 20:29:53 <carlwgeorge> sure thing 20:30:01 <tdawson> nirik and carlwgeorge it sounds like we have at least enough of a plan to try some things with what we build epel9-next from ... or do we need more disucssion on that? 20:31:01 <carlwgeorge> i thought we said to stick with the buildroot for now? 20:31:28 <tdawson> carlwgeorge I'm fine with that too, it will prevent a delay. 20:31:59 <carlwgeorge> and when we go to set up epel9 with rhel9 content, i'm fine attempting it without grobisplitter, and seeing if that works 20:32:30 <tdawson> Sounds good. 20:33:01 <tdawson> So if we're going to use the buildroot, then I'll start working on a "make sure the packages are in the repos" 20:33:19 <tdawson> Although, the hardest part of that will be figuring out a name. 20:33:38 <tdawson> Are we ready to move on? 20:34:07 <carlwgeorge> one more related thing: what do yall think about trying to stand up epel9 against rhel9 beta? 20:34:32 * nirik isn't sure thats a good idea... hum... 20:34:52 <tdawson> Only if we mark the packages beta somehow. 20:35:00 <mboddu> More than that, are we allowed to? Legally? 20:35:50 <carlwgeorge> tdawson: mark like change the dist tag, or just call it beta in an announcement? 20:35:53 <nirik> I guess it might be somewhat useful 20:35:55 <mboddu> I would rather suggest the rhel 9 beta users to enable epel9 next repo 20:36:03 <carlwgeorge> mboddu: i'm not sure how it wouldn't be legal 20:36:20 <tdawson> carlwgeorge Change the dist-tag, so it's very clear. 20:36:22 <nirik> I'm sure they would hit some things that wouldn't work from epel9-next... 20:36:46 <carlwgeorge> yup, beta is like 9.-1, and c9s has already moved on to 9.0 content 20:36:48 <mboddu> carlwgeorge: I am not sure, epel is always setup post rhel ga. I am not aware of any legality in there 20:37:12 <mboddu> carlwgeorge, nirik : yes, but I am guessing at least 98% of the packages will still work 20:37:49 <carlwgeorge> anyways, just an idea i had, it may be a moot point depending on how it takes to finish epel9-next 20:37:56 <tdawson> :) 20:38:18 <tdawson> OK, moving on to the next item on "old business" ... openssl3 in epel8 20:38:28 <smooge> the major problem with building against the beta was broken packages. CS9 has a better path to getting a fixed package versus spending 8 weeks to finally be told we fixed it in final out in 3 months 20:38:29 <nirik> I think it could be useful, but also would be a lot of work... at least if we had a different dist tag we would have to make sure to rebuild everything at GA... 20:39:00 <smooge> the content between 6,7, and 8 beta and final were big 20:39:01 <tdawson> I opened a bug asking RHEL if they would put openssl3 in RHEL8, they said "no" - https://bugzilla.redhat.com/show_bug.cgi?id=2007031 20:39:10 <smooge> the content differences between 6,7, and 8 beta and final were big 20:39:34 <rsc> Yes, but there was no Stream transparency at that time. 20:40:17 <smooge> I was thinking that we can see it in stream, and we are doing the work in stream so we aren't learning a lot from beta we won't learn from stream 20:41:15 * mboddu has to go, catch you all later 20:41:22 <tdawson> By mboddu 20:41:47 <tdawson> dcavalca: Were you the one that was going to try to do openssl3 ? 20:41:53 <carlwgeorge> that's fair enough, i was thinking of it from the aspect of a trial run for the ga rebuild, but i guess it wouldn't really help much with epel9-next going (other than identifying missing -devel packages) 20:42:12 <dcavalca> tdawson: yes, though I haven't had actual time to work on it beyond a quick PoC 20:42:53 <dcavalca> if someone else wants to take it on / help out that is of course appreciated 20:43:34 * tdawson looks to see if anyone steps forward. 20:44:28 <tdawson> dcavalca: Anyway, it sounds like if you do want to do it, you won't be conflicting with anything RHEL has planned. 20:44:49 <dcavalca> sounds good 20:45:18 <carlwgeorge> i'm not a fan of anyone doing it solo without help from the fedora openssl maintainers 20:45:37 <dcavalca> carlwgeorge: oh yeah I fully agree there, this needs the maintainers onboard 20:45:48 <dcavalca> which is why I wanted to have the time to actually work on it when I start engaging them 20:46:00 <carlwgeorge> sahana's comment in https://bugzilla.redhat.com/show_bug.cgi?id=2007031 doesn't give me confidence to that end 20:46:03 <rsc> carlwgeorge: really? For openssl11 this works pretty well without the Fedora OpenSSL maintainers so far... 20:46:39 <dcavalca> rsc: so, the problem with openssl3 is that the specfile needs major work 20:46:44 <carlwgeorge> rsc: are you volunteering to do openssl3 for epel8? 20:46:51 <dcavalca> so if we do end up forking it, keeping it in sync with Fedora will be painful 20:47:03 <rsc> carlwgeorge: at latest when I need it myself, yes. 20:47:16 <dcavalca> but otoh, if we did it with conditionals in the rawhide branch that would require a major rework, which needs the maintainers onboard 20:47:41 <dcavalca> I also need to followup with systemd and see when they're planning their transition 20:47:48 <carlwgeorge> rsc: i stand by what i said, you should at a minimum add the fedora openssl maintainers to the openssl11 package 20:48:01 <carlwgeorge> (after discussing it with them) 20:48:29 <rsc> carlwgeorge: why? I don't see the benefit, because openssl11 for EPEL 7 is based on RHEL 8, it's just copy & paste of patches. 20:48:54 <rsc> The diff is quite small (https://bugzilla.redhat.com/attachment.cgi?id=1653653&action=diff) 20:49:34 <carlwgeorge> because we should work together. they'll likely have useful input and be able to help with things that may be missed by a simple copy/paste. 20:50:06 <dcavalca> also because openssl is a nasty package with a large blast radius, so the more eyeballs the better :) 20:50:12 <carlwgeorge> ^that 20:50:39 <carlwgeorge> "i can do this by myself" is not a good stance to take on this 20:51:25 <rsc> Well, the amount of interest regarding OpenSSL 1.1.x was about zero once it came to do work. 20:51:37 <tdawson> And ... moving on ... last old business, macros in epel7 ... pgreco has made some progress, still working on a pull request. 20:52:17 <tdawson> Sorry ... we're getting low on time and I had that sentance on my screen for a bit. :) 20:52:49 <tdawson> #topic EPEL-7 20:53:03 <tdawson> Anything, other than the macros, that came up for epel7 ? 20:53:36 <smooge> nope 20:53:39 <tdawson> #topic EPEL-8 20:54:01 <tdawson> Anything, other than openssl3, that came up for epel8 ? 20:54:53 <tdawson> #topic EPEL-Packaging-SIG 20:55:11 <dcavalca> once we're ready to take packages in for epel9-next, I think I have a candidate: https://bugzilla.redhat.com/show_bug.cgi?id=2011531 20:57:26 <tdawson> Sorry for the long pause ... interesting read :) 20:58:00 <tdawson> Anything else for the Packaging SIG? 20:58:14 <tdawson> #topic General Issues / Open Floor 20:58:23 <dcavalca> Eighth_Doctor: filed a bunch of tickets for missing stuff in CRB that we need to build EPEL packages 20:58:34 <tdawson> Just saw the time. Anything for the Open Floor. 20:58:42 <smooge> not fo rme 20:58:50 <tdawson> dcavalca: Yep. Getting them in now is a good thing. 20:59:10 <smooge> I hope you all have better luck this time 20:59:23 <dcavalca> the only other thing we were working on was https://bugzilla.redhat.com/show_bug.cgi?id=2009581 to unblock hyperscale kernel builds 20:59:35 <dcavalca> which I've added to the packages sig tracker 21:00:52 <tdawson> That one at least has some good conversation on it. Most of my requests a simply silent and wait two weeks. 21:01:04 <tdawson> Looks like our time is up. 21:01:20 <tdawson> Thank you everyone for coming, and having a good discussion 21:01:27 <smooge> thanks all 21:01:28 <nirik> thanks for running things tdawson! 21:01:29 <smooge> night 21:01:32 <dcavalca> thanks tdawson 21:01:34 <tdawson> Talk to you next week. 21:01:34 <smooge> thanks tdawson 21:01:43 <tdawson> #endmeeting