21:00:16 <tdawson> #startmeeting EPEL (2023-02-15)
21:00:16 <zodbot> Meeting started Wed Feb 15 21:00:16 2023 UTC.
21:00:16 <zodbot> This meeting is logged and archived in a public location.
21:00:16 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
21:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:16 <zodbot> The meeting name has been set to 'epel_(2023-02-15)'
21:00:18 <tdawson> #meetingname epel
21:00:18 <zodbot> The meeting name has been set to 'epel'
21:00:19 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge
21:00:19 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson
21:00:21 <tdawson> #topic aloha
21:00:30 <ssmoogen> sort of here.
21:00:32 <rsc> .hello robert
21:00:33 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
21:00:44 <dherrera> .hi
21:00:45 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
21:00:46 <tdawson> Hello rsc and ssmoogen
21:00:49 <tdawson> Hi dherrera
21:01:08 <carlwgeorge> .hi
21:01:10 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
21:01:18 <jcpunk> .hi
21:01:19 <zodbot> jcpunk: jcpunk 'Pat Riehecky' <riehecky@fnal.gov>
21:01:27 <yselkowitz[m]> .hello yselkowitz
21:01:30 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
21:01:38 <tdawson> Hi carlwgeorge and jcpunk
21:01:43 <tdawson> Hello yselkowitz[m]
21:01:58 <pgreco> .hi
21:01:59 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
21:02:00 <tdawson> jcpunk: Always good to see you.  Are you here for a particular reason or just lurking?
21:02:05 <tdawson> Hi pgreco
21:02:06 <jcpunk> just lurking
21:02:23 <tdawson> jcpunk: Welcome and lurk away.
21:02:28 <salimma> .hi
21:02:28 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
21:02:31 <salimma> jcpunk: long time no see!
21:02:36 <tdawson> Hi salimma
21:02:37 <jcpunk> indeed!
21:03:01 <nirik> morning
21:03:25 <tdawson> Morning nirik
21:03:54 <davide> .hello dcavalca
21:03:55 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
21:03:57 <carlwgeorge> nirik: thanks btw for all these merges you're doing for me
21:04:10 <tdawson> Hello davide
21:04:54 <dminer> Hello!
21:05:02 <tdawson> Hello dminer
21:05:25 <tdawson> dminer: I haven't seen you for a while either.  Anything specific you wanted to talk about, or just visiting?
21:05:33 <tdawson> #topic End Of Life (EOL)
21:05:34 <tdawson> RHEL 7 will go EOL on 2024-06-30
21:05:36 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
21:05:37 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
21:05:50 <dminer> Just visiting! Trying to stay up on things
21:05:56 <tdawson> Sounds good.
21:06:01 <nirik> carlwgeorge: thanks for all the PRs!
21:06:02 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
21:06:03 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
21:06:29 <tdawson> We have two issues marked with "meeting" today.  I'd like to start with the older one.
21:06:37 <tdawson> .epel 198
21:06:38 <zodbot> tdawson: Issue #198: Drop modularity from EPEL-8. Do not enable modularity for EPEL-9 - epel - Pagure.io - https://pagure.io/epel/issue/198
21:07:09 <tdawson> The time has come, modularity leaves EPEL today
21:07:20 <tdawson> Or ... possibly "has left"
21:07:21 <davide> party time!
21:07:29 <jcpunk> <3
21:07:33 <pgreco> something good had to happen today!
21:07:39 <nirik> the modularity has left the building.
21:07:53 <salimma> 🎊
21:08:15 <dminer> Niiice
21:08:15 <salimma> sorry not sorry for spamming Matrix users :0
21:08:32 <tdawson> At the end of the issue a few of us were debating on what to do with the epel-release repo stuff.
21:08:42 <ssmoogen> thank you for your service modularity. good night
21:09:21 <carlwgeorge> a valiant effort by ssmoogen and others, but definitely time to say goodbye
21:09:28 <tdawson> ssmoogen and/or nirik   ... has it already been archived?
21:09:58 <nirik> I've not done so.
21:10:06 <nirik> A releng ticket would be best I think
21:10:49 <tdawson> Anyone up for creating that real quick?
21:11:00 <carlwgeorge> epel-related releng work?  sounds like a job for dherrera  :P
21:11:21 <tdawson> archiving as well as removing tags and targets, if I'm thinking correctly.
21:12:02 <ssmoogen> correct. and playing with mbs
21:12:09 <dherrera> I can open the ticket for starters
21:12:31 <tdawson> dherrera: Thank you
21:14:17 <tdawson> About the config in epel-release.  Per the discussion in the issue it sounds like we should leave it in, disabled.  But some thought we should have a stronger wording than just "DEPRECATED"
21:14:54 <salimma> "HES_DEAD_JIM"
21:15:00 <tdawson> *laughs*
21:15:07 <dherrera> "RETIRED"?
21:15:21 <nirik> I don't think stronger will really get any more people to stop using it if they were going to anyhow.
21:15:28 <davide> EXTERMINATED
21:16:08 <tdawson> nirik: Although I agree with you, but in my mind "DEPRECATED" sounds like it still might get some support.
21:16:18 <carlwgeorge> what nirik said
21:16:27 <pgreco> if we remove it from the epel-release, if people have modified it, it will be left as .rpmsave
21:16:28 <tdawson> I do like RETIRED ... that sounds rather final
21:16:29 <salimma> +1 for retired
21:16:35 <pgreco> otherwiese it would fully disappear
21:16:43 <salimma> this is just for clarity so people don't wonder what happened to it right?
21:16:43 <nirik> we could do "EOL" or "END_OF_LIFE"
21:16:43 <davide> yeah, in all seriousness, I think retired is fine
21:16:56 <tdawson> salimma: Correct.
21:16:56 <nirik> sure, retired is fine. I don't care.
21:17:09 <salimma> we have a meeting room called DONT_USE_OR_YOULL_BE_FIRED
21:17:15 <carlwgeorge> is it worth doing another build of epel-release just to change the word from deprecated to retired?
21:17:18 <pgreco> I'd like to see it fully removed, but I'll take retired
21:17:38 <tdawson> carlwgeorge: Possibly not.  But maybe change it, so next time we have a release it goes out.
21:17:56 <carlwgeorge> that works
21:17:58 <salimma> yeah, I think letting it go out with the next change is fine
21:18:02 <pgreco> doesn't drive a release, should be included in the next release
21:18:29 <carlwgeorge> i can make that change
21:18:38 <tdawson> carlwgeorge: Thank you
21:19:04 <tdawson> I was going to send out an email to epel-announce right after this meeting.
21:19:19 <carlwgeorge> #action carlwgeorge will change DEPRECATED to RETIRED in epel8-modular configs, but no build just for this
21:20:33 <tdawson> #action dherrera will create a releng ticket for archiving, removing tags and targets, and removing epel modules from mbs
21:21:00 <tdawson> #action tdawson will send out an email to epel-announce announcing the final retirement of epel8 modules.
21:21:16 <tdawson> Anything else that needs to be done?
21:22:07 <ssmoogen> not from me.
21:22:26 <nirik> not that I can think of off hand
21:22:34 <tdawson> Maybe a memorial service ... but for now, I think we can move on.
21:22:50 <tdawson> .epel 220
21:22:51 <zodbot> tdawson: Issue #220: Membership request - epel - Pagure.io - https://pagure.io/epel/issue/220
21:23:24 <tdawson> This is for dminer requesting to be a member of the epel-packagers-sig
21:23:43 <dminer> Oh hey, that's me!
21:23:54 <tdawson> He is replacing Eighth_Doctor at datto and will be taking the datto specific packages.
21:24:15 <tdawson> Hi dminer :)  welcome
21:24:24 <Eighth_Doctor> Hi Dalton M :D
21:24:32 <dminer> 👋
21:24:39 <dminer> thank you!
21:25:10 <tdawson> Since I dno't know him, I'm going to refrane from voting, but it sounds like others here do.
21:25:37 <carlwgeorge> are there a lot of datto specific packages that already have the epel-packagers-sig as a maintainer?
21:25:38 <davide> I have met Dalton and can confirm he is human
21:25:49 <tdawson> *laughs*
21:26:05 <salimma> I have also met Dalton and am happy to vote in favor
21:26:10 <dminer> davide: Oh good, the disguise worked
21:26:26 <salimma> sssshh
21:26:32 <carlwgeorge> i have virtually met dalton, and can confirm he's human from the shoulders up
21:26:49 <carlwgeorge> he might have a lizard tail, but we shouldn't hold that against him
21:26:57 <Eighth_Doctor> lol
21:27:01 <ssmoogen> never held it against me
21:27:39 <Eighth_Doctor> carlwgeorge: every package I added to EPEL 9 in the initial 100 packages was for datto
21:27:49 <Eighth_Doctor> they all have epel-packagers-sig as commit, collab, or admin level
21:28:34 <Eighth_Doctor> one of the things I tasked Dalton M to do is to turn that list into an ELN workload so it can be tracked for the next EPEL branching event
21:28:54 <tdawson> Sounds like a good reason to be on the epel-packagers-sig
21:29:03 <carlwgeorge> ok that's what i was getting at, was adding him to the sig saving any work versus adding him individually to the packages
21:29:13 <carlwgeorge> the logic checks out
21:29:24 <Eighth_Doctor> (In case people forgot, I helped seed EPEL from this set of packages: https://build.opensuse.org/project/show/home:Pharaoh_Atem:CS9EPELDev)
21:29:57 <Eighth_Doctor> (thank goodness I didn't delete the project yet 😆)
21:30:28 <tdawson> I have only seen positive votes for this, and several people have verified that he is human.  I believe this is passed.
21:31:03 <tdawson> Does anyone want to update the epel-packagers-sig members, as well as the ticket?
21:31:15 <pgreco> I don't have enough knowledge to vote, but I think we do have enough +1s, right?
21:31:28 <Eighth_Doctor> well there's at least +1 from me
21:31:35 <nirik> sure, I can.
21:31:38 <Eighth_Doctor> I can verify he was human last time I saw him
21:31:38 <tdawson> pgreco: Correct.  We have at least 3 +1's.
21:31:46 <tdawson> nirik: Thank you
21:31:50 <ssmoogen> +1 from me
21:31:51 <pgreco> Eighth_Doctor: you might be a bit biased, but I'll take it ;)
21:32:15 <tdawson> pgreco: The biggest thing is that he has no negative votes.
21:32:43 <nirik> done. Should I close the ticket? or you got it tdawson
21:32:56 <tdawson> nirik: If you are there, feel free to close it.
21:33:29 <tdawson> Congratulation dminer
21:33:51 <tdawson> I'm going to move on cuz the next thing might take a while.
21:33:54 <tdawson> #topic Old Business
21:33:59 <nirik> done
21:34:21 <tdawson> EPEL 10 proposal - https://discussion.fedoraproject.org/t/epel-10-proposal/44304
21:34:47 <tdawson> I'm going to timebox this to just 20 minutes at most.
21:35:20 <dminer> tdawson: Great, thanks all 😃
21:36:15 <carlwgeorge> there hasn't been much activity on the thread, other than a few comments about $release_major/$release_minor (which i don't think will be feasible)
21:36:24 <nirik> I thought we agreed in principal? is there more to review?
21:36:26 <tdawson> I believe we left off last week in  a bit of limbo over whether we should move forward with this new way and start giving serious discussion o ver the details, or whether we should continue as we did.
21:37:23 <Eighth_Doctor> in principle, I somewhat like the idea
21:37:25 * davide is strongly in favor of the EPEL 10 proposal
21:37:35 <carlwgeorge> Eighth_Doctor had concerns that he said he'd add to the thread, but said he's been busy
21:37:39 <Eighth_Doctor> I'm concerned about how users expectations will change by having minor branches
21:37:45 <tdawson> Most of us that were here agreed, but ssmoogen an pgreco were not here, and Eighth_Doctor was still on the fence ... and sounds like Eighth_Doctor is now on this side of the fence.
21:38:00 <nirik> I think it will be more work and confusing at first, but we will end up in a better place if we can get everything setup right.
21:38:15 <Eighth_Doctor> and I still don't like the disttag setup you want to go with :P
21:38:30 <Eighth_Doctor> but the biggest issue I have is that minor versions have "special" lifecycles in RHEL
21:38:31 <jcpunk> how will you know when "10.2" changes are landing in Stream 10?
21:38:47 <pgreco> I have my doubts about thow I'd handle this process, but nothing really strong enough to get in the way
21:38:49 <Eighth_Doctor> and we've historically been able to dodge dealing with that by not supporting minor versions at all
21:39:08 <pgreco> and tbf, it will be closer to fedora release process, 1 branch every 6 months
21:39:09 <Eighth_Doctor> this workflow change essentially switches us to caring about minor versions as a first-class thing
21:39:22 <Eighth_Doctor> it'll be off by one month, but essentially yes
21:39:24 <carlwgeorge> jcpunk: cpe members can find out internally, and while we're not allowed to widely advertise it, we just have to make sure we do a snapshot prior to that cutover
21:39:38 <jcpunk> Ok, so long as there is a way
21:39:50 <Eighth_Doctor> I personally don't like that not being widely known
21:39:51 <jcpunk> If it was "troll the repo for changes" it would never be sustanable
21:39:59 <carlwgeorge> yeah, internal rhel milestones
21:40:11 <carlwgeorge> Eighth_Doctor: it was good enough for the epel9 launch snapshot work we did
21:40:12 <jcpunk> Eighth_Doctor: +1
21:40:32 <carlwgeorge> i can't do anything about rhel folks being sensitive about schedule details, as much as i wish i could
21:40:44 <Eighth_Doctor> it's only good enough for rhel GA because of the nature of that event
21:40:47 <Eighth_Doctor> but the ongoing basis is chaotic when packages shift from epel to rhel
21:40:49 <ssmoogen> i don't have a problem with the general. I also haven't put much thought in it. consider me a 0
21:41:15 <tdawson> Eighth_Doctor jcpunk The conversation has come up internally, and from what I've heard, nobody has been against us letting people know.  I hope that maybe if we have this new way of doing things, we can make it official that we will let the public know when we change over.
21:41:17 <carlwgeorge> functionally it's no different, as ga is just .0
21:41:18 <Eighth_Doctor> and coordinating fixes between rhel and epel is very painful now, and moving to minor branching makes it worse
21:41:49 <Eighth_Doctor> I've personally been screwed over by this the entirety of last year
21:42:06 <carlwgeorge> tdawson: i can tell you separately the folks that are explicitly against it
21:42:22 <bstinson> i can expand on the guardrails if you'd like
21:42:29 <Eighth_Doctor> it's why we got no KDE Plasma upgrades out for EPEL 9
21:42:30 <ssmoogen> i think that the overall changes in velocity for EL-X in minors is making them a first class citizen. Having the desktop and other applications change major versions means we are stuck with more work
21:42:31 <tdawson> carlwgeorge: bummer ... ok, I'll talk with you offline.
21:42:34 <Eighth_Doctor> until hopefully this cycle
21:43:07 * Eighth_Doctor is crossing his fingers that we can finally upgrade Plasma with RHEL 9.2
21:43:24 <davide> "coordinating fixes between rhel and epel is very painful now, and moving to minor branching makes it worse" -- can you elaborate on how/why it gets worse?
21:43:41 <Eighth_Doctor> it's worse because now we have multiple potentially maintained codestreams based on their lifecycles
21:43:42 <carlwgeorge> Eighth_Doctor: we all agree it's painful now, and the idea is it would be less painful in this new model
21:43:58 <Eighth_Doctor> for example, 9.0, 9.2, 9.4, etc. are EUS minor versions
21:44:09 <carlwgeorge> this proposal does not include supporting eus versions
21:44:26 <davide> I've definitely noticed the pain with things like asterisk where a bunch of deps have to be kept in sync with whatever is going on in RHEL at minor release cutover
21:44:39 <carlwgeorge> if this goes well, maybe we end up there eventually, but it's not in scope for now
21:44:45 <salimma> seems to me with the new proposal, 'build for epel10 which tracks Stream, then rebuild for the latest minor version' is strictly better than the status quo
21:44:45 <davide> but I'd expect that to actually improve with this, as we'd be able to just track Stream
21:44:50 <salimma> if you don't care about the older minor release, there's nothing more to do?
21:44:54 <carlwgeorge> salimma++
21:44:54 <zodbot> carlwgeorge: Karma for salimma changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
21:44:56 <Eighth_Doctor> Michel Alexandre Salim 🎩: sure, but that doesn't necessarily require us to have minor version branches
21:45:01 <salimma> and no need to worry about 'should I branch for next or wait'
21:45:02 <pgreco> carlwgeorge: it does not include supporting them, but it makes it easier
21:45:23 <salimma> e.g. Rust updates were delayed because people feel maintaining a -next branch that's short lived is too annoying
21:45:39 <carlwgeorge> pgreco: right, as they'll have more reliable archive repos to point at
21:46:00 <carlwgeorge> my point was we're not going to have active distgit branches for eus versions, they'll be retired
21:46:05 <ssmoogen> the main problem I can see is similar to the problem we had with playground. People will see minor branches and commit to them after we have stopped building from them
21:46:29 <ssmoogen> or they will do something in one and wonder why its not showing up in the other
21:46:31 <davide> can we mark them as retired in dist-git once we've stopped building from them?
21:46:39 <carlwgeorge> ssmoogen: not if we mass retire them like eol fedora branches
21:46:59 <ssmoogen> carlwgeorge: if they show up in `fedpkg switch-branch` they will still happen
21:47:16 <nirik> "you have pushed to epel 10.2 after that minor release is no longer supported, commit to 10 for stream or 10.3 for 10.3"
21:47:23 <carlwgeorge> but if they're retired they won't be able to push to the remote
21:47:40 <salimma> right, users will discover when they try to push
21:47:43 <salimma> s/users/packagers
21:47:48 <tdawson> Very similar to Fedora
21:47:50 <carlwgeorge> all of this is the same as what happens now if i commit to an f35 branch and try to push it
21:48:00 <tdawson> yep
21:48:12 <carlwgeorge> making this work more like fedora maintenance is the theme here
21:48:24 <nirik> I think we recently improved that message, we can make it better for epel too if desired.
21:49:22 <davide> yes, the more EPEL behaves like Fedora the easier for people to contribute (hopefully)
21:50:09 <ssmoogen> carlwgeorge: I am not against it.. I just still feel burned by modularity and playground and ...
21:50:23 <salimma> we're close to the time limit by the way
21:50:28 <tdawson> It's sounds like this week we have an approval to move forward with this proposal for epel 10, is that correct?   (move forward in general, details can change)
21:50:31 <nirik> I wonder... should the base thing be 'steam-10' instead of just '10' ?
21:50:34 <tdawson> salimma: Yep, thanks for that.
21:50:45 <tdawson> nirik: That is one of the "details"
21:51:07 <ssmoogen> yep
21:51:28 <ssmoogen> I have to head out.
21:51:34 <tdawson> ssmoogen: Thanks for being here.
21:51:39 <pgreco> my summary is this, I get the appeal, I'm a bit scared about the details, but I'm willing to give this a try for 10, count me +1
21:51:43 <ssmoogen> thanks carlwgeorge for doing the work and tdawson for running th em meeting
21:51:54 <tdawson> I'm going to change this to open floor, while I type up the info
21:52:01 <tdawson> #topic General Issues / Open Floor
21:52:10 <tdawson> Anything for Open Floor?
21:52:16 <davide> I have a thing for open floor
21:52:35 <davide> so I recently packaged https://src.fedoraproject.org/rpms/magicmirror in Fedora, and wanted to branch it for EPEL 9
21:52:45 <davide> this thing is a nodejs package
21:52:53 <davide> and it turns out nodejs in EPEL 9 is... interesting
21:52:58 <davide> https://kojipkgs.fedoraproject.org//work/tasks/5015/97425015/root.log
21:53:17 <davide> DEBUG util.py:443:  Error:
21:53:17 <davide> DEBUG util.py:443:   Problem: conflicting requests
21:53:17 <davide> DEBUG util.py:443:    - package nodejs-devel-1:18.10.0-3.module+el9.1.0+16866+0fab0697.x86_64 is filtered out by modular filtering
21:53:17 <davide> DEBUG util.py:443:    - package nodejs-devel-1:18.12.1-1.module+el9.1.0.z+17326+318294bb.x86_64 is filtered out by modular filtering
21:53:21 <tdawson> #info carlwgeorge's proposal for epel 10 has been approved to move forward in general.  Details can/will change, but we will move forward to the goal.
21:53:40 <nirik> good times. Thanks modules.
21:53:43 <davide> I hadn't realized this was a module, and I'm not really sure how to move forward here
21:53:53 <nirik> likely it was updated and we have both the old and new one around.
21:53:54 <davide> also looking this up on koji, it seems like there's a demodularized build too?
21:54:09 <salimma> the koji demodularized build is from grobisplitter right?
21:54:11 <davide> https://kojihub.stream.centos.org/koji/packageinfo?packageID=1363
21:54:15 <salimma> a.k.a. it came from the module
21:54:26 <tdawson> Do we have gobbisplitter running on epel9 ?
21:54:40 <salimma> oh woops. we don't because we assume there's no modules huh
21:54:43 <nirik> no.
21:54:59 <nirik> grobbisplitter is 8 only I think...
21:55:47 * salimma has one really quick thing once we're done with this, just in case he missed bringing this up
21:55:47 <nirik> I think in this case we should remove the old version and the new one should work?
21:55:54 <nirik> or...
21:56:21 <jcpunk> I've lingering worries about how viable it is to maintain python-pandas in EPEL9 with the jinja2 requirements for current development not being RHEL9 compatible: https://bugzilla.redhat.com/show_bug.cgi?id=2032550
21:56:24 <nirik> set module_hotfixes = 1 for epel9
21:56:26 <salimma> so.. if we have two 'ursine' RPMs, version resolution works fine, but if we have two modular RPMs things don't work as well?
21:57:17 <nirik> yeah, I think we should set hotfixes=1.
21:57:26 <davide> can we do that in koji?
21:57:41 <nirik> yes. I can if you can test it?
21:57:52 <carlwgeorge> shouldn't your build just resolve to the non-modular nodejs-devel without doing anything special?
21:58:01 <davide> yeah sure, happy to submit a test build
21:58:08 <davide> carlwgeorge: that would have been my expectation too, yes
21:58:14 <davide> oh wait
21:58:28 <davide> is the non-modular nodejs-devel actually shipped?
21:58:41 <davide> I wonder if what's going on is that it's actually unshipped, so it's picking up the modular one instead
21:58:47 <nirik> I don't think there's a non modular one shipped.
21:58:53 <carlwgeorge> well shit
21:59:01 <nirik> there is 1 modular one and 2 versions of that package in the module.
21:59:02 <tdawson> Ya ... I'm not seeing it. :(
21:59:12 <carlwgeorge> yeah this should go to a request to ship nodejs-devel in crb
21:59:13 <davide> I suppose I could ask it to be added to CRB
21:59:24 <tdawson> Yep
21:59:33 <tdawson> salimma: What did you want to bring up?
21:59:39 <salimma> ah
21:59:40 <carlwgeorge> easy justification, nodejs-devel is shipped in nodejs:18 module, do the same for the non-modular
21:59:55 <salimma> can I go ahead with updating libkdumpfile/drgn? I meant to file a meeting issue about it but forgot
22:00:13 * nirik set hotfixes=1... let me know if folks disagree and want me to not set it.
22:00:53 <salimma> also as an addendum: if a single maintainer maintains the related packages and there's no other dependents -- does it make sense to wait a week? (either way it's fine by me, I just want to avoid too much unnecessary notifications)
22:01:01 <carlwgeorge> nirik: i think hotfixes=1 will screw things up and make dnf always resolve to the modular content, i.e. nodes from the nodejs:18 module instead of the non-modular nodejs at version 16
22:01:25 <carlwgeorge> salimma: context?  is it an incompat update or something?
22:01:44 <nirik> ok, I can set it back for now.
22:01:44 <salimma> carlwgeorge: soname bump but the only user of libkdumpfile is drgn which I also maintain
22:02:00 <salimma> and drgn works fine with either, it just needs to be rebuilt
22:02:05 <tdawson> salimma: I thought we talked about it?  But if carlwgeorge doesn't remember ...maybe it was sometime he wasn't here.
22:02:17 <carlwgeorge> i am also forgetful sometimes
22:02:24 <davide> filed https://bugzilla.redhat.com/show_bug.cgi?id=2170215 to get this added to CRB
22:02:24 <salimma> let me find a link
22:02:32 <salimma> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/5DCGRHG5COBSCZXMECIFWEBDYAEMMRNZ/
22:02:38 <salimma> yeah Carl is not in the thread
22:02:38 <carlwgeorge> even if there is only one dep, it should still follow the incompat process
22:02:49 <salimma> only tdawson and Conan Kudo
22:03:08 <salimma> carlwgeorge: fair enough. right, so... any objection, since it's been a week?
22:03:10 <carlwgeorge> things outside epel may depend on that soname and need rebuilds too
22:03:14 <salimma> IIRC policy says we need to agree to it
22:03:30 <salimma> carlwgeorge: ah good point. RPM Fusion and friends (and any user)
22:03:37 <Eighth_Doctor> I agree to it
22:03:41 <salimma> tldr the current version is actually broken on non-x86_64
22:03:46 <Eighth_Doctor> just need to announce it
22:03:50 <salimma> like, actually buggy :)
22:04:21 <carlwgeorge> yeah file the issue now and we can add the vote to it, the time period of a week is for list discussion which you did already
22:04:32 <salimma> aha, gotcha
22:04:51 <carlwgeorge> i'm +1, you've got the plan to rebuild everything affected and ship them together
22:05:06 <salimma> we're out of time so I'll file the issue and post the link there
22:05:14 <salimma> or wait a sec and I'll file it
22:05:18 <tdawson> jcpunk: Just so you know, I saw your bug.  And it's something I have to deal with in KDE all the time.  See if there is some way that you can use the lower versions.  Or bundling is also an option (that I don't really like to do)
22:05:27 <carlwgeorge> just announce it per policy and the rest of the steps, like no-auto push to stable on the update
22:05:50 <tdawson> I'm also +1 on it incase it wasn't clear on the email.
22:05:54 <salimma> filed https://pagure.io/epel/issue/222
22:06:06 <carlwgeorge> i had one more open floor thing, i'm making python-jsonschema-epel to provide python-jsonschema+format that i need for some stuff https://pagure.io/releng/fedora-scm-requests/issue/51152
22:06:55 <carlwgeorge> just as an fyi in case anyone else needs it too
22:07:35 <pgreco> tdawson: +1 on 222
22:07:36 <tdawson> carlwgeorge: Don't you need to have a comment that just says "valid" ?
22:07:56 <carlwgeorge> yes, from one of the folks mentioned in the comment there i think
22:08:05 <carlwgeorge> such as nirik
22:08:21 <tdawson> salimma: I've only seen +1's on your proposal, I'm calling it passed.  I'll write that in the issue.
22:08:31 * carlwgeorge waves at nirik forrest gump style
22:08:34 <tdawson> Thank you for the good discussion everyone.  Sorry about letting this go over time.
22:08:35 <salimma> thanks all
22:08:38 <salimma> sorry for not filing this earlier
22:08:48 <tdawson> Talk to you next week, if not sooner.
22:09:01 <tdawson> #endmeeting