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