20:00:47 <tdawson> #startmeeting EPEL (2021-05-12)
20:00:47 <zodbot> Meeting started Wed May 12 20:00:47 2021 UTC.
20:00:47 <zodbot> This meeting is logged and archived in a public location.
20:00:47 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:47 <zodbot> The meeting name has been set to 'epel_(2021-05-12)'
20:00:48 <tdawson> #meetingname epel
20:00:48 <zodbot> The meeting name has been set to 'epel'
20:00:50 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel_slm
20:00:50 <zodbot> Current chairs: bstinson carlwgeorge michel_slm nirik pgreco tdawson
20:00:51 <tdawson> #topic aloha
20:00:57 <cyberpear> .hi
20:00:58 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
20:01:16 <pgreco> hello everybody, buenas tardes ;)
20:01:30 <tdawson> Hi cyberpear
20:01:36 <michel_slm> .hi salimma
20:01:37 <zodbot> michel_slm: Sorry, but you don't exist
20:01:38 * pgreco is too tired today to think in English and falls back to Spanis :D
20:01:42 <pgreco> Spanish
20:01:44 <tdawson> Hi pgreco
20:01:45 <michel_slm> .hello salimma
20:01:46 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:01:49 <tdawson> Hi michel_slm
20:02:01 <michel_slm> dcavalca is at the CentOS board meeting and won't be able to show up
20:02:06 <tdawson> pgreco: You might be too tired for Spahish as well
20:02:21 <pgreco> yeap, that sounds about right
20:02:47 <tdawson> I didn't know this was the same time as the CentOS board meeting ...
20:02:56 <michel_slm> only once a month though!
20:03:02 <tdawson> Ah, ok.
20:05:04 <tdawson> Hmm ... I was hoping nirik and carlwgeorge would show up
20:05:14 <carlwgeorge> i'm here
20:05:14 * Eighth_Doctor waves
20:05:18 <Eighth_Doctor> .hello ngompa
20:05:18 <tdawson> Hi Eighth_Doctor
20:05:18 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:05:29 <tdawson> #topic Old Business
20:05:30 <tdawson> EPEL-Packaging-SIG
20:05:42 <michel_slm> so.. funny anecdote
20:05:44 <michel_slm> https://bugzilla.redhat.com/show_bug.cgi?id=1872446
20:06:09 <nirik> morning
20:06:09 <michel_slm> I filed this, then forgot to follow up, and... someone who is not in the ACL for the package took it, tried to branch, and failed
20:06:34 <michel_slm> looking forward to having a better flow at least documented, if not automated, once we fix Bodhi to allow collaborators to push updates :)
20:06:35 <tdawson> Ha
20:06:45 <tdawson> Hi nirik
20:07:15 <nirik> hope you all are having a less crazy week than I. ;)
20:07:20 <tdawson> It looks like we have a Bodhi update scheduled, that should help
20:07:36 <nirik> yes, tomorrow morning
20:07:42 <tdawson> Ua!!!
20:07:47 <tdawson> Ya!!!
20:08:21 <tdawson> My typing skills seem to resemble pgreco's today
20:08:36 <michel_slm> woo!
20:08:55 * michel_slm on his least favorite keyboard so his typing would be wonky too
20:10:04 * nirik is reminded of spinal tap... to paraphrase: "are all these your keyboards?"
20:10:26 <tdawson> michel_slm: Even though someone else tried to branch it, it shouldn't be affecting your being able to branch, correct?
20:10:47 <michel_slm> tdawson: it shouldn't, once I'm added to the ACL
20:11:23 <michel_slm> but it got blocked because he owned the bug, and the only maintainer for the package was only familiar with the old pre-Pagure flow, where you can ask to be added to the ACL in the web UI
20:11:51 <michel_slm> I pointed him to the URL he'd need to use to add me, since... there's no way to request in the tool nwo
20:12:05 <michel_slm> should that be something we add? we're sticking to Pagure for a while, right?
20:12:06 <tdawson> Ah ... I have to admit, the web UI was rather nice.   Although it's not too bad nowdays.
20:12:36 <nirik> I hope so, but who knows.
20:13:09 <tdawson> Well, better to get it documented with the current way, than have the old way still in the documentation.
20:13:25 <michel_slm> yeah
20:14:01 <michel_slm> anyway, nothing much from my side. will be prepping for my Dojo talk later today :)
20:14:17 <michel_slm> I have something for epel-next later
20:14:24 <tdawson> Oh, that's right.  Good louck with your Dojo talk.
20:14:38 <michel_slm> thanks!
20:14:39 <tdawson> Well, if that's all for the SIG, then epel-next is ... next. :)
20:14:53 <carlwgeorge> haha
20:15:05 <Eighth_Doctor> :)
20:15:07 <tdawson> epel-next ... carlwgeorge Anything to report?
20:15:52 <carlwgeorge> still waiting on prs with fedpkg and bodhi/backend ansible roles
20:16:10 <carlwgeorge> `bodhi releases list` shows epel-8n now, but it isn't showing up in the web ui and i don't know why
20:16:19 <nirik> we need to make sure to create repos for the ansible change before it can go in
20:16:43 <nirik> might just need a restart?
20:16:48 <tdawson> I haven't tried yet, but can we make branches with the current fedpkg ?
20:16:57 <carlwgeorge> and i think we're also waiting on the robosignatory playbook to get run in production so it knows which key to sign with
20:18:44 <nirik> carlwgeorge: perhaps we could schedule another block of time to move things forward? early next week perhaps?
20:18:51 <carlwgeorge> yes please
20:20:05 <michel_slm> so speaking of epel-next - Qt in Stream just got updated, and now I'm seeing package conflicts with EPEL Qt packages (like nextcloud-client)
20:20:31 <pgreco> I think that's the first update I guess
20:20:31 <tdawson> I was thinking about the dnf repo file ... and where things will be.  Will this be epel8-next, epel-8-next, epel-next-8 ?
20:20:46 <Eighth_Doctor> epel8-next I would assume, no?
20:20:46 <michel_slm> since c8 will be EOL soon... do we mass branch everything in epel8 to epel8-next?
20:20:46 <pgreco> though I'm not sure if 8.4 will drop before that
20:21:17 <tdawson> michel_slm: Yep, working on it ... though Stream still has the older 5.12, so it doesn't break things.
20:21:26 <pgreco> michel_slm: no, the baseline is still rhel8 for this
20:21:40 <pgreco> so the EOL of c8 doesn't affect this
20:21:51 <michel_slm> tdawson: yeah, it just warns if you dnf upgrade :)
20:21:52 <Eighth_Doctor> EPEL is built on RHEL
20:21:54 <cyberpear> I assume epel8-next will inherit from epel8? (and thing only need to be built in el8-n if there's some new dep in c8s?)
20:21:57 <carlwgeorge> for the repo file, the id should just be epel-next
20:22:06 <nirik> cyberpear: yeah, thats the idea
20:22:10 <tdawson> michel_slm: What does c8 being EOL have to do with branching everyghing into epel8-next ?
20:22:16 <michel_slm> epel-next, with releasever = 8?
20:22:24 <Eighth_Doctor> yeah
20:22:26 <Eighth_Doctor> that would work
20:22:30 <cyberpear> perhaps epel8-next branches should be created only on demand?
20:22:37 <carlwgeorge> i don't plan to mass put anything into epel8-next.  the whole idea was to make it available for maintainers, but not force anything on them
20:22:38 <nirik> epel-next will only have things that are needed to adjust against not yet released rhel...
20:22:46 <tdawson> carlwgeorge: Ah, that makes sense.
20:22:50 <carlwgeorge> what cyberpear, branches on demand
20:22:52 <nirik> so it will grow and shrink over time
20:22:54 <carlwgeorge> *said
20:22:57 <michel_slm> tdawson: ah. well, our users who are not RHEL users will have a degraded experience if EPEL maintainers have to explicitly opt in again for -next
20:23:28 <Eighth_Doctor> Michel Alexandre Salim: why would we mass branch?
20:23:40 <Eighth_Doctor> it's not like these breakages are common and universal
20:23:47 <cyberpear> michel_slm: since epel-next will inherit from epel, what's the issue?
20:24:01 <tdawson> michel_slm: That still isn't making sense.  But, as was just said, epel-next will require epel to be enabled.
20:24:11 <carlwgeorge> michel_slm: the idea is to have a epel-next-release supplement centos-stream-release, so that it gets installed by default on centos stream
20:24:11 <nirik> well, by inherit, meaning you will also have epel enabled.
20:24:15 <michel_slm> Conan Kudo: if the process of creating a branch is easy enough, then we can branch on demand
20:24:27 <Eighth_Doctor> it's not different than creating a fedora branch
20:24:47 <carlwgeorge> epel is opt in, epel-playground is opt in, epel-next will be opt in
20:24:54 <Eighth_Doctor> though I personally won't create git branches for this, and would instead just push to epel8 and tell it to build to el8next
20:25:03 <michel_slm> I guess my concern is if it'll be like going from epel7 -> epel8 where we scramble to get packages branched.
20:25:19 <Eighth_Doctor> nah
20:25:23 <tdawson> It shouldn't be.
20:25:26 <Eighth_Doctor> epel-next is per distro release
20:25:43 <michel_slm> Conan Kudo: once we get good coverage of maintainers that care about EPEL, it's that simple, yeah. before... there'll probably be some pain
20:25:48 <carlwgeorge> with 9 that should be better because we intend to have epel9-next available long before rhel 9 ships
20:25:56 <nirik> well, it's always going to be more reactive than proactive... unless we could get something in Stream to detect/auto-branch these things somehow
20:26:08 <Eighth_Doctor> we don't want to sign people up for packages automatically
20:26:22 <Eighth_Doctor> unlike Fedora, CentOS/RHEL is a long commitment
20:26:40 <michel_slm> would we allow -next only packages?
20:27:06 <michel_slm> e.g. at some point, I could imagine I want to only maintain some packages in -next (because I use Stream and only want to support a package for 5 years) and never have it in the base epel
20:27:19 <nirik> I suppose...
20:27:33 <michel_slm> then yeah, we should treat it as entirely separate and opt-in, that makes sense
20:27:45 <cyberpear> carlwgeorge++ good to have epel extensions opt-in, but maybe epel-next-release should `Supplements: (epel-release if centos-release-stream)` so Stream users get it by default?
20:27:45 <zodbot> cyberpear: Karma for carlwgeorge changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:27:53 <nirik> I'd hope those would be rare/non existant... but meh
20:28:25 <michel_slm> there's always the option of orphaning once there's no matching CS release :)
20:28:58 <tdawson> michel_slm: Doesn't really seem like a nice thing to do
20:29:53 <carlwgeorge> michel_slm: epel maintainers aren't required to maintain an epel package for the full rhel lifecycle.  they can be retired at any time.
20:29:56 <Eighth_Doctor> I would really rather not make life miserable for the people who already have to deal with crap from a lot of people
20:30:06 <tdawson> But, if nobody in regular EPEL requests it in 5 years, it don't really mind.
20:30:34 <carlwgeorge> a -next only package would be possible but it would be a jerk move to rhel users and users of other rebuilds
20:30:35 <michel_slm> tdawson: I mean, the maintainer dropping a release they cannot support because they don't have such systems, that's normal expectation, right?
20:30:46 <michel_slm> as carlwgeorge said
20:30:46 <carlwgeorge> or at least, some might interpret it that way
20:31:00 <nirik> someone could drop a package for any reason at all. ;)
20:31:29 <michel_slm> right, we're not running Hotel California
20:31:41 <carlwgeorge> we follow fedora process for orphaning, where you announce it on relevant lists.  when i've done that before someone always spoke up and said "yeah i'll take it".
20:31:43 <michel_slm> (with apologies to non-Eagle fans)
20:31:55 <nirik> thats another good thing the epel-sig could do...
20:32:12 <nirik> take on things that get orphaned for whatever reason (if desired/etc)
20:32:38 <carlwgeorge> there could absolutely be a case where a package is -next only initially, for example if it requires the latest golang to build
20:32:43 <michel_slm> could be, yeah. I guess it has to be understood as a best effort thing
20:32:53 <carlwgeorge> but it should be branched for main epel once the needed package is in rhel
20:33:04 <michel_slm> carlwgeorge: yeah, that makes sense
20:33:44 <carlwgeorge> and really once all the needed (build)requirements are in rhel, a package should only exist in epel, not in next anymore
20:34:00 <Eighth_Doctor> I think the fundamental misunderstanding here is that EPEL is not for CS8/CS9
20:34:06 <carlwgeorge> epel8 is already ~99% compatible with cs8
20:34:08 <Eighth_Doctor> it's for all EL8/EL9 systems
20:34:11 <tdawson> Yep.  Honestly, I don't have problem with someone dropping support after 5 years, it's more of it not showing up in regular EPEL.  But, like I said, if nobody notices or requests it in EPEL for 5 years, then I don't think anyone really will care if it goes.
20:34:37 <Eighth_Doctor> epel-next is mainly for dealing with breakages ahead of the next RHEL point release
20:34:38 <michel_slm> Conan Kudo: right. which is why I'm asking about someone potentially only caring about epel-next
20:34:46 <Eighth_Doctor> treating it as more than that is probably asking for pain
20:35:24 <michel_slm> or, at least, caring only for the first 5 years and then dropping the package. just raising that possibility
20:35:37 <carlwgeorge> that's already possible without next
20:35:40 <michel_slm> (but this is nothing new)
20:35:40 <tdawson> Totally fine with that.
20:35:52 <Eighth_Doctor> you can do that today
20:36:09 <Eighth_Doctor> just orphan it when you're done with it and it'll get reaped or taken over
20:36:18 <tdawson> carlwgeorge: epel-release question.   Are you working on it for epel-next, or would you want me or someone else to work on it?
20:36:39 <carlwgeorge> basically packages should be put in epel by default.  and optionally built in epel-next also if there is currently a relevant library difference between rhel8 and cs8.
20:37:04 <carlwgeorge> i haven't started it yet, but i'm happy either way.  i can do it and you can review, or vice versa.
20:37:18 <michel_slm> carlwgeorge: and once that build goes to EPEL, should we untag it from epel-next?
20:37:28 <Eighth_Doctor> Michel Alexandre Salim: they'll have different disttag
20:37:46 <carlwgeorge> i believe what we discussed previously was an optional subpackage with the repo enabled by default (once installed), that supplements centos-stream-release
20:37:46 <michel_slm> ok, once that update is also built for epel, do we need to retire the one in epel-next?
20:37:59 <tdawson> carlwgeorge: correct
20:38:11 <michel_slm> (wondering how we'll clean up since it's an overlay repo)
20:38:24 <carlwgeorge> michel_slm: retire is probably unnecessary, keep the branch around in case another library bump happens
20:38:33 <carlwgeorge> llvm gets bumped every point release it seems
20:38:47 <michel_slm> yup, keeping the branch makes sense. I'm wondering about the old builds though
20:38:53 <tdawson> I'm working on qt5 (and all of KDE) and realized even after I build them, I don't have a dnf repo file.
20:39:29 <carlwgeorge> if maintainers do a release bump when they first build for epel8-next, then merge that to epel8 branch, the upgrade path will be fine
20:39:52 <carlwgeorge> the old builds won't matter as long as the upgrade path is correct
20:41:17 <michel_slm> yeah. might make it nicer for mirrors if they don't have unnecessary packages in epel-next
20:41:24 <nirik> we may someday want to nuke things that are newer in epel...
20:41:27 <michel_slm> but we can deal with that once that becomes an issue
20:41:32 * nirik nods
20:41:33 <Eighth_Doctor> presuming that the disttag is `.el8~next`, what carlwgeorge says is correct
20:41:52 <Eighth_Doctor> if it is `.el8.next` or something else, then that would not be true
20:42:04 <cyberpear> will epel-next be its own git branch, or will it be more like ELN, rebuilt against a different buildroot from the same package commits?
20:42:04 <carlwgeorge> using ~next would require the maintainer bump the release when they branch for next
20:42:32 <carlwgeorge> it's set up currently for .next, which means the maintainer can bump the release either when they build for next, or when they rebuild for main
20:42:34 <michel_slm> my undestanding is it's a new branch, right, that's why we said it's going to be opt-in?
20:42:43 <carlwgeorge> yes, it's own branch
20:43:37 <carlwgeorge> i'm ok with changing the disttag from .el8.next to .el8~next, but we'll have to make guidelines that require a release bump when it's first built for next
20:43:56 * nirik hates that ~'s don't match well on clicks
20:44:23 <carlwgeorge> that and ~ and ^ give issues to older kojis when rebuilt
20:44:36 <tdawson> carlwgeorge: I think the release bump is sorta natural a "Rebuild for newer foo"
20:44:51 <carlwgeorge> it is, yes
20:45:00 <tdawson> But yes, documenting it is best.
20:45:32 * cyberpear wonders who uses older kojis?
20:45:44 <michel_slm> what's our ideal flow? if say the release is N in epel8, we bump it for epel-next to N+1, the matching epel build will be N+1 too?
20:45:50 <michel_slm> or we want to require bumping again
20:46:01 <nirik> I think just merge and build
20:46:18 <carlwgeorge> cyberpear: cbs until recently
20:46:20 <michel_slm> CentOS' cbs is probably a bit older
20:46:22 <michel_slm> ah
20:46:48 <Eighth_Doctor> CBS was fixed this week
20:46:48 <tdawson> I thing the flow is bump into next, then just merge and build into regular EPEL.
20:46:55 <Eighth_Doctor> yeah
20:47:03 <cyberpear> there's also the potential problem of Stream moving to X.Y+2 before X.Y+1 RHEL is out the door, but hopefully that doesn't hurt anything
20:47:04 <Eighth_Doctor> so we should use `.el8~next` for that flow
20:47:23 <Eighth_Doctor> cyberpear: thankfully the content doesn't move _that_ fast
20:47:43 <carlwgeorge> examples https://paste.centos.org/view/raw/7feae8a2
20:47:45 <cyberpear> (IIRC, curretly c8s is 8.5 whereas 8.4 isn't out the door yet)
20:47:48 <Eighth_Doctor> iirc, EL8.5 content started landing only a couple of weeks before EL8.4 freeze
20:48:13 <carlwgeorge> yes, there is about a month where cs8 is +.2
20:48:59 <carlwgeorge> hopefully keeping old packages around is enough of a salve during that month
20:49:16 <carlwgeorge> plus i'm guessing that most people don't update more often than monthly anyways
20:50:14 <michel_slm> those who update more often are probably on Stream :)
20:50:15 <tdawson> carlwgeorge: So, the end question, can I start branching and building on epel-next yet?  Will that work?
20:50:40 <carlwgeorge> i missed one example in that paste, it would also be fine for the release to get bumped every time all the way up to -3
20:50:42 <michel_slm> tdawson: would be happy to test your Qt5 packages once there's a way to do so
20:51:02 <carlwgeorge> tdawson: needs https://pagure.io/fedpkg/pull-request/429 first
20:52:06 <tdawson> carlwgeorge: Ah ... that's the one that nobody that cares can actually merge. :(
20:52:48 <Eighth_Doctor> push comes to shove, we can ship it as a patchset in fedpkg in Fedora and EPEL
20:52:50 <michel_slm> Nirik can't merge?
20:53:13 <Eighth_Doctor> nirik has admin rights on it, he can merge it
20:53:15 <nirik> I can, but I am not a fedpkg maintainer anymore really.
20:53:28 <nirik> I don't want to jump in and annoy people doing the work
20:53:33 <tdawson> I just noticed the time, we can continue to talk about -next, but I wanted to ask if there was anything important that anyone wanted to bring up this week?
20:54:27 <nirik> it looks like it's pretty close... I will add my +1...
20:55:24 <carlwgeorge> on open floor i just wanted to bring up the soname bumps that were mentioned on epel-devel
20:55:48 <tdawson> #topic General Issues / Open Floor
20:55:53 <tdawson> carlwgeorge: go for it
20:56:06 <carlwgeorge> those threads happened because i nagged the responsible maintainers into doing it.  if they had followed the incompat process one of the items would have been discussion here.
20:56:18 <carlwgeorge> fluidsynth and fmt
20:56:33 <tdawson> Was it the same maintainer for both?
20:56:36 <carlwgeorge> nothing for us to approve as they already did it and apologized
20:56:43 <carlwgeorge> no different maintainers
20:56:56 <nirik> it happens, we should thank them for admiting it and hopefully doing better
20:57:01 <carlwgeorge> i did rebuilds for all the epel affected stuff
20:57:28 <nirik> are those packages using the preferred files section for sonames?
20:57:55 <carlwgeorge> yes, in both cases it was merges from fedora branches it appears
20:58:18 <carlwgeorge> so they changed the files section to match the  new soname without noticing
20:58:54 <nirik> well, they would have known changing it in fedora... but yeah
20:59:09 <michel_slm> They might be epel only maintainers though?
20:59:37 <carlwgeorge> i believe it was done in fedora in rawhide, propagated normally into a release, and then was blindly merged back to epel
20:59:38 <michel_slm> I guess ideally we block updates that introduce soname breakages
21:00:20 <tdawson> michel_slm: Yep ... I think at some point, we want to get gating implemented in bodhi that checks dependencies.
21:00:33 <carlwgeorge> the threads should have the bugzillas linked if anyone wants to dig into the exact history
21:00:53 <tdawson> That's a bit down the road though, and will require side-tags in epel (if we don't already have it)
21:00:58 <nirik> well, there are cases where you kind of have to... :( but it could be announced/done in a sidetag with all dependent packages, etc
21:01:09 <nirik> we do. ;) should work fine
21:01:09 <michel_slm> I think we have side tags now
21:01:18 <carlwgeorge> one of them was merged to f32 also, and some of my rebuilds there failed
21:01:29 <michel_slm> Ouch
21:01:35 <tdawson> Ya, releasing KDE with gating, and no side-tags would be an terrible mess.
21:01:41 <Eighth_Doctor> so f32 is screwed :/
21:01:44 <carlwgeorge> f32 fluidsynth https://bugzilla.redhat.com/show_bug.cgi?id=1953438
21:01:49 <Eighth_Doctor> because it EOLs in less than two weeks
21:02:05 <carlwgeorge> karma this quickly https://bodhi.fedoraproject.org/updates/FEDORA-2021-0cf0581961
21:02:24 <carlwgeorge> the ones that failed to rebuild, well they're screwed unless someone figures out the build quickly
21:02:53 <Eighth_Doctor> done
21:03:00 <nirik> and I was going to mention the package that never goes away... libvu-devel.
21:03:03 <nirik> https://pagure.io/releng/issue/10111
21:03:16 <michel_slm> Yeah...
21:03:28 <tdawson> Looks like we are a bit over time.  Thank you everyone for being here and for the good discussion.
21:03:35 <michel_slm> Ran across this trying to build neovim I think
21:03:40 <michel_slm> Thanks tdawson
21:03:50 <carlwgeorge> libuv-devel is fixed now i thought
21:03:54 <tdawson> Talk to ya'll next week, unless sooner.
21:03:57 <Eighth_Doctor> except in s390x
21:04:03 <michel_slm> see y'all in Dojo
21:04:11 <Eighth_Doctor> oh right
21:04:12 <tdawson> #endmeeting