20:00:35 <tdawson> #startmeeting EPEL (2021-04-21)
20:00:35 <zodbot> Meeting started Wed Apr 21 20:00:35 2021 UTC.
20:00:35 <zodbot> This meeting is logged and archived in a public location.
20:00:35 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:35 <zodbot> The meeting name has been set to 'epel_(2021-04-21)'
20:00:36 <tdawson> #meetingname epel
20:00:36 <zodbot> The meeting name has been set to 'epel'
20:00:38 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel_slm
20:00:38 <zodbot> Current chairs: bstinson carlwgeorge michel_slm nirik pgreco tdawson
20:00:39 <tdawson> #topic aloha
20:00:58 <dcavalca> .hi
20:00:59 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:01:00 <michel_slm> .hello salimma
20:01:01 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:01:08 <tdawson> Hi dcavalca
20:01:11 <tdawson> Hi michel_slm
20:01:22 <pgreco> hello!
20:01:28 <tdawson> Hi pgreco
20:01:52 * michel_slm already did his baby duty waiting in the car while mom got vaccinated
20:02:10 <pgreco> nice, productive day!
20:04:03 <smooge> hello
20:04:08 <tdawson> Hi smooge
20:04:28 <tdawson> I know nirik isn't going to be here, but I hope carlwgeorge makes it
20:05:21 <carlwgeorge> sorry running late
20:05:23 <carlwgeorge> i'm here
20:05:34 <tdawson> Hi carlwgeorge
20:05:39 <tdawson> Not a problem, glad you made it.
20:05:49 <tdawson> #topic Old Business
20:05:50 <tdawson> EPEL-Packaging-SIG
20:06:16 <tdawson> michel_slm and/or dcavalca what is the statis of the SIG this week?
20:06:40 <tdawson> Although I think last week it was noted that the bodhi change wasn't going to happen until after freeze
20:06:50 <michel_slm> yeah, I think we're pretty much blocked on that
20:06:59 <dcavalca> yup
20:07:08 <tdawson> So, one more week of being blocked ... ok
20:07:18 <tdawson> Anything else?
20:07:20 <dcavalca> only update on my side is that the releng ticket for softhsm got sorted out, but I'm still waiting for the maintainer to actually follow up
20:07:22 <michel_slm> Fedora 34 go/no go delayed until Friday, hopefully that means whatever critical fix would be in by then
20:08:16 <tdawson> dcavalca: Are you/we waiting for him to add a contributor?   (sorry for my spelling)
20:08:26 <dcavalca> tdawson: yep
20:08:33 <dcavalca> https://bugzilla.redhat.com/show_bug.cgi?id=1942748
20:10:16 <michel_slm> so, once we can add the SIG as collaborator and actually do all the workflow needed (branch, build, push updates)... I wonder if we can get an easier way to get the SIG added assuming the maintainer does not respond
20:10:26 <dcavalca> oh I should add this one to the tracker bug
20:10:43 <michel_slm> without having to do a non-responsive maintainer path. maybe we can get that discussion started while waiting for the bodhi update?
20:11:31 <tdawson> Well, it hasn't been a week since they found out about the branch, but it would have been nice if they'd replied one way or another about actually building and maintaining the package.
20:12:20 <dcavalca> yeah it'd be useful to have a flow to just add the SIG as a collaborator if the maintainer says they're ok with it
20:12:37 <michel_slm> yeah, I had in mind a 1 week cutoff -- have a standard template for requesting epel branches, and default to adding the sig after a week of non-response
20:13:25 <dcavalca> I like that, but can we actually do it?
20:13:33 <tdawson> A week seems a bit fast, I still like the one week, then notification, then another week.
20:13:39 <michel_slm> (or if the maintainer stays silent. the non-responsive path is cumbersome and a bit hostile - first opening a non-responsive bug that blocks the branch request, then emailing devel@ asking if anyone knows where the maintainer is .. takes too many weeks as well)
20:13:59 <dcavalca> yeah I definitely don't want to use the non responsive process here
20:14:19 <michel_slm> yeah, 1+1 is still ok if it at least does not require all these steps. as to how we can do it... um, can we file an infra ticket and ask an admin to do that, just as a proof of concept?
20:14:30 <dcavalca> I bet the vast majority of non responses here fall into "I didn't see the ticket" or "I don't really care about epel, whatever"
20:14:46 <michel_slm> right. esp if we don't get access to the main branches
20:14:56 <tdawson> Ya, but we also don't want to alienate people if they are just on vacation for a week.
20:15:14 <dcavalca> yeah, agreed
20:15:38 <dcavalca> (aside: is there a way for a packager to flag they're "on vacation" or whatever?)
20:15:42 <michel_slm> with something like this, what I have in mind is, say epel9 (or epel-9-next) comes along, and we discover package A and 20 dependencies are missing
20:16:01 <michel_slm> we should be able to script the process, and in 2 weeks get all the branches
20:16:26 <tdawson> Yep, I agree with that.  Either via the maintainer or the sig.
20:16:29 <michel_slm> dcavalca: the official doc I find seems to suggest adding yourself to the vacation calendar, but... the lookup can't be automated
20:16:40 <dcavalca> TIL there's a vacation calendar
20:16:51 <michel_slm> would that be a reasonable feature request for noggin?
20:17:25 <dcavalca> I think so, yeah
20:17:28 <michel_slm> https://fedoraproject.org/wiki/Vacation
20:18:04 <tdawson> Wow ... I had no idea there was a calendar like that.
20:18:09 <michel_slm> great,a looks like we don't have any documentation anymore apart from the calendar itself
20:18:23 <michel_slm> https://apps.fedoraproject.org/calendar/list/vacation/ just says "Mark when you're going to be away so we can all pick up the slack"
20:19:18 <pgreco> wow, I'm not only surprised that it exists, it surprises me more that it's being used
20:19:40 <michel_slm> yeah, I'm trying to dig through the history to find if at some point we had more documentation
20:19:41 <tdawson> That was my second thought.
20:19:48 <michel_slm> I'm pretty sure it was not that obscure before
20:20:22 <smooge> I think 99% of the people don't remember it exists
20:20:49 <michel_slm> yeah, might be worth discussing this... any idea where?
20:20:57 <michel_slm> devel@ I guess
20:21:03 <tdawson> I knew about the calendar, for meetings.
20:21:41 <michel_slm> man, I'm showing my age here
20:21:41 <dcavalca> yeah I'd say devel@
20:22:52 <tdawson> Anything else before we move on?
20:23:51 <michel_slm> I move we hear about epel next :)
20:24:01 * carlwgeorge hides
20:24:12 * michel_slm just reimaged his laptop with Stream so he is extra interested
20:24:35 <tdawson> carlwgeorge do you have an update on epel8-next?
20:24:47 <tdawson> If I remember, last week it was the same as the SIG, waiting for freeze to end.
20:25:06 <carlwgeorge> yup, no change in status
20:26:02 <tdawson> Well ... that was quick. :)
20:26:34 <tdawson> Moving on to the EPEL Fails-To-Install
20:27:07 <tdawson> I've got tracker bugs created for that, for EPEL8, but other than that, no progress this past week.
20:27:37 <tdawson> #topic EPEL-7
20:27:50 <tdawson> Anything for EPEL7
20:28:04 <pgreco> I saw a message about nginx for epel7 today
20:28:09 <pgreco> trying to find it
20:28:17 <tdawson> Yep
20:29:13 <tdawson> I think the person has legitimate reason to do an update vs backport ... and I for one think nginx is something that needs to be kept on top of
20:29:34 <pgreco> yeah, other than the scary "upgrade" and the linking against updated libraries, there's nothing wrong there
20:30:19 <tdawson> I noticed that my web server is running just that, nginx from EPEL7, so I'll be testing it whenever they get it in -testing.
20:31:04 <pgreco> looks like there's nothing more to do than keeping an eye on it
20:31:11 <tdawson> Yep
20:31:12 <pgreco> at least for now
20:31:29 <tdawson> Anything else for EPEL7 ?
20:32:11 <tdawson> #topic EPEL-8
20:32:37 <tdawson> Anything for EPEL8?
20:33:35 <tdawson> Hmm ... I guess nobody is going to mention the modules in the room, and for good reason.
20:33:56 <dcavalca> tdawson: I actually do have a modules related question, but I was going to leave it for open floor
20:34:13 <tdawson> Then let's save it for that.
20:34:20 <tdawson> Anything non-module for EPEL8?
20:34:52 <tdawson> #topic General Issues / Open Floor
20:35:21 <tdawson> dcavalca, I think you are first, what was your question/comment?
20:35:34 <dcavalca> so, I'm looking at the "sanest" way to build llvm 12 / clang 12 for c8s
20:35:45 <dcavalca> c8s provides llvm 11 in the llvm-toolset module
20:35:59 <dcavalca> originally, my plan was to do a non-modular build in the hyperscale SIG
20:36:18 <dcavalca> however, ngompa mentioned that we might be able to do this in EPEL as another module stream
20:36:26 <dcavalca> there's some details in https://pagure.io/centos-sig-hyperscale/sig/issue/46
20:36:44 <dcavalca> and I wanted to check with y'all on the best course of action before I start doing things
20:37:24 <tdawson> I think it would be a good thing to have it as a module in EPEL8
20:37:27 <michel_slm> oh yeah, epel does support modules
20:37:48 <dcavalca> so, practically speaking, how would I go about doing this?
20:37:51 <tdawson> It does support them, the problem is that we can't utilize the non-default RHEL8 modules.
20:37:58 <michel_slm> if there are packages that depend on llvm 11 ... how would having the llvm 12 module activated impact them?
20:38:21 <dcavalca> michel_slm: that's a great question, I suspect if something depends on clang the binary, it'll be fine
20:38:23 <tdawson> You wouldn't be able to have both the llvm11 module, and your llvm12 module enabled at the same time.
20:38:26 <michel_slm> will they break, and if so, do we have to carry updated versions compiled against llvm/clang 12 in epel too?
20:38:35 <dcavalca> if it depends on some llvm libraries, they would likely need a rebuild
20:39:08 <michel_slm> right. so... the worry will be if there are some of these that depend on llvm libraries that are in EL itself (not EPEL)
20:39:36 <dcavalca> https://git.centos.org/rpms/llvm/tree/c8s-stream-rhel8 is the llvm in c8s
20:39:39 <michel_slm> since... we're forbidden to carry them in EPEL, so... uh, at that point we might have to do the whole thing in Hyperscale. we should probably check if anything depends on LLVM?
20:40:02 <dcavalca> so, as I understand it, it's shipped as a module default stream
20:40:09 <dcavalca> which I think makes it ineligile for epel?
20:40:27 <carlwgeorge> correct, unless you name the packages differently and use different paths
20:40:37 <tdawson> Hmm ... yep, from what I see, you both are correct
20:40:58 <tdawson> The biggest problem I see is what would happen to those packages that were built against the original llvm
20:41:30 <carlwgeorge> i will point out that llvm has been updated to a new major version in every rhel8 minor release, from 7 all the way to 11
20:41:51 <tdawson> Ha!
20:42:10 <michel_slm> oh!
20:42:19 <dcavalca> carlwgeorge: oh, that is most interesting
20:42:23 <smooge> how else do you compile firefox/rust every other week?
20:42:25 <michel_slm> so filing a bug asking for llvm 12 would help? or it will happen anyway
20:42:48 <michel_slm> I guess Red Hat has to upgrade llvm, since otherwise... upstream doesn't do bugfixes and backporting them could be ... tedious
20:43:03 * michel_slm inherited LLVM from Bryan O'Sullivan at some point
20:43:16 <michel_slm> he's now a director and doesn't code :p
20:44:19 <dcavalca> carlwgeorge: any idea how to divine whether we might actually get llvm 12 in c8s, and ideally a rough cut timeframe?
20:44:33 <carlwgeorge> llvm is a "rolling application stream" lifecycle https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle
20:44:45 <carlwgeorge> i'm looking through bugzillas now to see if it's on the roadmap
20:44:48 <tdawson> So ... if the trend continues, ya, it sounds like ... just wait a few months until RHEL 8.5 starts getting into stream.
20:45:09 <carlwgeorge> stream is already building 8.5 content, but 8.5 is still on llvm 11 so far
20:45:33 <dcavalca> yeah; we still might need to do a SIG build, as I know our LLVM people really want a few patches that didn't make the cut for 12 in
20:45:34 <carlwgeorge> michel_slm: opening a bugzilla to ask for it is probably the right first step
20:45:47 <dcavalca> but having it in c8s proper will make life a lot easier
20:45:50 <dcavalca> thanks carlwgeorge
20:47:01 * dcavalca just noticed "Red Hat Enterprise Linux 9" is now a product on BZ :)
20:47:38 <tdawson> Yep, it's been there for a while.
20:48:33 <tdawson> When there is something there for 10, then you'll not 9 is about to be released :)
20:49:40 <tdawson> Anything else for open floor?
20:50:09 <dcavalca> carlwgeorge: https://bugzilla.redhat.com/show_bug.cgi?id=1952248
20:50:47 <carlwgeorge> perfect, thanks
20:50:49 <michel_slm> I propose a bet on if the platform for RH Summit is nicer this year compared to last year
20:50:58 <carlwgeorge> these teams need to get used to discussing things in public bugs
20:51:05 <tdawson> *laughs*
20:51:17 <carlwgeorge> it would be hard to be worse
20:51:42 <tdawson> From what I heard, yes, this years Summit should have a better platform
20:51:50 <dcavalca> I don't think I managed to see a single thing last year
20:52:00 <tdawson> but I haven't seen it, so ... I currently can't judge.
20:52:09 <dcavalca> it was about as terrible as the platform LF had used for some events
20:52:21 <dcavalca> hopefully this round will be better :)
20:52:30 <michel_slm> LF is a 501(c)4 right?
20:52:41 <dcavalca> no idea actually
20:53:02 <michel_slm> oh, huh, a (c)6 https://en.wikipedia.org/wiki/Linux_Foundation
20:53:19 <michel_slm> so yeah very commercial :p
20:53:35 <michel_slm> if we're done I want to borrow pgreco for a few minutes :)
20:53:51 <tdawson> I think we're done, unless anyone has anything else?
20:53:52 * pgreco wonders....
20:54:06 <dcavalca> works for me
20:54:10 <pgreco> michel_slm: here or PM?
20:54:40 <tdawson> Thank you everyone for coming ... We'll talk next week, when hopefully we closer to the end of the freeze and have more to talk about.
20:54:54 <tdawson> #endmeeting