20:00:54 <tdawson> #startmeeting EPEL (2023-08-23)
20:00:54 <zodbot> Meeting started Wed Aug 23 20:00:54 2023 UTC.
20:00:54 <zodbot> This meeting is logged and archived in a public location.
20:00:54 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:54 <zodbot> The meeting name has been set to 'epel_(2023-08-23)'
20:00:56 <tdawson> #meetingname epel
20:00:56 <zodbot> The meeting name has been set to 'epel'
20:00:57 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
20:00:57 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
20:00:59 <tdawson> #topic aloha
20:01:00 <rsc> .hello robert
20:01:01 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:01:01 <nirik> morning all
20:01:03 <neil> .hi
20:01:04 <dcavalca> .hi
20:01:04 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:01:06 <pgreco> dcavalca: let me know if you need a server ;)
20:01:07 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <davide@cavalca.name>
20:01:09 <neil> hey all
20:01:11 <pgreco> .hi
20:01:12 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:01:31 <tdawson> Hello rsc
20:01:35 <neil> damn pgreco already selling that server I gave you last week?! :P
20:01:39 <tdawson> Morning nirik
20:01:42 <dcavalca> ahah thanks pgreco, I have far too many of those already :)
20:01:44 <carlwgeorge> .hi
20:01:47 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:01:53 <tdawson> Hi neil dcavalca and pgreco
20:01:57 <tdawson> Hi carlwgeorge
20:02:05 <pgreco> neil: always looking for ways to make money :D
20:02:50 <neil> you know, i can't fault you for that
20:03:17 <michel-slm> hello hello!
20:03:21 <michel-slm> .hello salimma
20:03:24 <zodbot> michel-slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:03:24 <neil> hey tdawson, carlwgeorge, rsc, dcavalca. hope your collective weeks are going well
20:03:27 <neil> hey michel-slm :)
20:03:31 * gotmax lurks
20:03:33 <gotmax> .hello gotmax23
20:03:34 <zodbot> gotmax: gotmax23 'Maxwell G' <maxwell@gtmx.me>
20:03:41 * neil waves
20:04:00 <michel-slm> the bridge is broken again today huh
20:04:02 <dcavalca> no longer covid positive, so going quite well so far
20:04:17 <neil> michel-slm: bridge is down indefinitely aiui
20:04:20 <tdawson> Hello michel-slm and gotmax
20:04:38 <neil> michel-slm: https://libera.chat/news/temporarily-disabling-the-matrix-bridge
20:04:43 <gotmax> It was nice meeting some of y'all at Flock :)
20:04:46 <nirik> it's down until they fix it. ;( (likely not at least for a few more weeks probibly)
20:05:13 <neil> gotmax: back at ya! glad you're recovering from the 'vid (same to you, dcavalca)
20:05:20 <nirik> Yeah, always great to put faces to the names. :)
20:05:29 <gotmax> https://floss.social/@maxgot/110940566071334193
20:05:31 <dherrera> .hi
20:05:32 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:05:37 <tdawson> #topic End Of Life (EOL)
20:05:39 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:05:40 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:05:42 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:05:43 <tdawson> Hi dherrera
20:06:21 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:06:22 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:06:24 <nirik> gotmax: I also asked out ems contacts for an update. ;(
20:07:04 <gotmax> I guess "Please stay tuned" is pretty much what they said three weeks ago, but at least they're still working on it
20:07:37 * neil tunes harder
20:07:48 <gotmax> I don't see anything new in pagure.io/epel, but maybe I'm missing something
20:08:03 <tdawson> We don't have any items marked as "meeting" ... so we'll move onto old-business, since I think most everything is in there.
20:08:13 <gotmax> 👍
20:08:23 <tdawson> #topic Old Business
20:08:44 <tdawson> Let's start with the  (hopefully) quicker item ... carlwgeorge's request for an update.
20:09:04 <carlwgeorge> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CDNDAKTIAQTFTNDHOIHKQJ4B2LAV5ZSS/
20:09:29 <carlwgeorge> no replies on list or directly to me about it, so i'm predicting a lazy consensus
20:09:52 <tdawson> My question was answered last week, so I'm good.
20:09:58 <gotmax> I remember agreeing with this when I first read it, but I didn't remember to respond
20:10:10 <gotmax> RHEL is going to keep updating golang AFAIK, so we may need to do this again
20:10:11 <tdawson> Anyone have any questions for carlwgeorge before we vote?
20:10:22 <neil> not I
20:10:34 <gotmax> Upstream projects tend to only support the latest two or three at a time
20:11:15 <gotmax> And that quic-go library is annoying, because it uses internal stuff and is closely tied to go versions
20:11:20 <carlwgeorge> indeed
20:11:29 <gotmax> So... I'm +1
20:11:36 <pgreco> In my mind, CVE fixing always wins against compatibility, specially if they are on the "milder" side as carl said
20:11:37 <tdawson> All in favor of carlwgeorge's proposal give a +1
20:11:44 <pgreco> so +1
20:11:46 <neil> +1
20:11:49 <nirik> +1
20:11:53 <gotmax> +1
20:11:53 <carlwgeorge> i've gotten away with minor changes to the bundled quic-go before to get rawhide builds working, but it's delicate and doesn't like too much change
20:11:58 <michel-slm> +1
20:12:46 <tdawson> #info:  carlwgeorge's request to upgrade caddy in epel passed - 8 in favor 0 opposed
20:12:52 <carlwgeorge> wheee
20:13:00 <carlwgeorge> will build and push to testing today
20:13:02 <tdawson> carlwgeorge: I assumed you gave it a +1 :)
20:13:08 <carlwgeorge> +1
20:13:22 <dcavalca> +1
20:13:35 <rcallicotte_> .hi
20:13:36 <zodbot> rcallicotte_: Sorry, but user 'rcallicotte_' does not exist
20:13:43 <dherrera> +1
20:13:51 <rcallicotte_> :(
20:13:58 <neil> hi rcallicotte_
20:14:01 <tdawson> Hi rcallicotte_
20:14:03 <neil> sorry to hear that you don't exist :(
20:14:14 <tdawson> #undo
20:14:14 <zodbot> Removing item from minutes: INFO by tdawson at 20:12:46 : :  carlwgeorge's request to upgrade caddy in epel passed - 8 in favor 0 opposed
20:14:22 * rcallicotte_ waves
20:14:22 <tdawson> #info:  carlwgeorge's request to upgrade caddy in epel passed - 10 in favor 0 opposed
20:14:51 <carlwgeorge> the other caddy old business thing was retiring it from epel7
20:15:13 <carlwgeorge> no vote needed but just an extra heads up, i'll be sending the announce email and doing the retirement today
20:15:14 <carlwgeorge> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/JZRLEWOCX5QX3XZ7INLUZIB7LPAMDUZC/
20:15:30 <tdawson> Thanks for the heads up.
20:15:33 * nirik nods
20:15:34 <pgreco> has it been updated since the last archival?
20:16:00 <pgreco> just for those who might want to download the last fully signed version from the repo
20:16:22 <carlwgeorge> the broken build got untagged and i verified that the repos have the older working build now
20:17:44 <pgreco> ack
20:18:08 <tdawson> Moving on to the next Old Business
20:18:16 <tdawson> .epel 240
20:18:17 <zodbot> tdawson: Issue #240: Formalizing the EPEL Steering Committee member process - epel - Pagure.io - https://pagure.io/epel/issue/240
20:19:38 <nirik> I did some pondering on this... whats the issue we are trying to solve? I guess to fix the docs as we move them to the docs site? or know how to join/leave?
20:19:43 <tdawson> Last week most people agreed that having 7 people on the committee seemed right.  But there was discussion on it being lifetime (as long as the person wanted) vs yearly or bi-yearly, or some amount of time.
20:19:44 <carlwgeorge> iirc we left this off with some amount of general agreement, and uncertainty on the finer details
20:21:13 <tdawson> carlwgeorge: I don't know if we had general agreement, but it was leaning toward having elections of some sort (meaning having some amount of time)
20:21:42 <dcavalca> I like a setup that asks members to reaffirm they still want to serve every ~period
20:22:01 <gotmax> I think that's reasonable
20:22:03 <dcavalca> but would also be fine with formal elections if that's what we reach consensus on
20:22:11 <carlwgeorge> i could be misremembering but i didn't remember anyone being outright opposed to elections and term limits
20:22:24 <nirik> I mean, whats not working now? :) why don't we just keep it like now?
20:23:01 <neil> you're not wrong there, carlwgeorge -- though there were a few who expressed wanting more time to consider
20:23:03 <pgreco> I'm ok with what it is now, without the formalities, just consensus
20:23:05 <tdawson> carlwgeorge: Nobody was outright opposed, but at least two were ... like nirik said, not really wanting to change.
20:23:44 <pgreco> but using my case again, I've been mostly out, and resigning seems permanent, and that's not nice
20:23:53 <pgreco> more like period or LOA or something
20:23:54 <jonathanspw> .hi
20:23:56 <michel-slm> I missed last week's meeting, but my 2 cents is I'm OK with either elections (preferably 2 year terms, not one year, with staggering) or with just reaffirming, or even the status quo
20:24:01 <tdawson> Hi jonathanspw
20:24:08 <jonathanspw> zodbot mia?
20:24:12 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
20:24:19 <jonathanspw> ahh hello zodbot
20:24:24 <rcallicotte_> hey you exist!!
20:24:33 <nirik> he was off in the matrix... oh wait, no...
20:24:34 <neil> That was the core of the conversation pgreco, w.r.t., consensus-based decisions vs voting, and weighing the merits of voting versus the fuzzy approach EPEL has been taking
20:24:41 <jonathanspw> sorry, give me half a second to catch up.  stupid calendar didn't poke me like it should've
20:24:55 <carlwgeorge> i didn't file the issue but i support the direction because the current fuzzy voting stuff is unsettling to me
20:25:21 <carlwgeorge> it's not common for our votes to be contentious, but it does happen and not having clear rules around it is messy
20:25:33 <dcavalca> I would recommend someone to put together a formal proposal and add it to the ticket
20:25:43 <tdawson> Personally, I like the fuzzy voting ... it gives the feeling of inclusion whether you are on the committee or not.
20:25:44 <dcavalca> and we can vote on that the next meeting after we had time to review/discuss there?
20:26:00 <carlwgeorge> formal proposal == docs pull request to formalize the wording?
20:26:20 <nirik> I think adding a bunch of process is a lot of work... but if everyone wants to...
20:26:23 <gotmax> On the Ansible Community Steering Committee, we allow anyone in the community to vote +1/-1 and count the SC and community votes separately
20:26:35 <dcavalca> not necessarily, just something concrete one can decide whether they want to support or not
20:26:44 <tdawson> gotmax: Oh, I like that.
20:26:48 <gotmax> Our members serve indefinitely until they step down or are removed through one of our processes
20:26:52 * dcavalca feels these kind of conversations aren't super productive in the abstract
20:27:10 <carlwgeorge> mirroring fesco makes the most sense to me.  only member votes counts, but everyone can speak their support or objections.
20:27:14 <gotmax> We don't have elections. People who are active/come to meeting can be offered a seat.
20:27:40 <tdawson> carlwgeorge: Nope ... fesco is waayyy to formal for me.
20:27:48 <jonathanspw> gotmax: what's the formal process look like for that?  are there criteria at which point someone is listed/gets a seat or what?
20:27:49 <michel-slm> gotmax: is that written down somewhere? so whoever writes our proposal can reference that as one of the options
20:27:57 <michel-slm> of course there's the question of how we vote among the options too :)
20:27:59 <neil> maybe the EPEL packagers SIG is a good way to limit the scope but still provide concrete rules and a path towards membership
20:28:13 * neil should probably ask to join that at some point
20:28:32 * rcallicotte_ thinks the same
20:28:38 <nirik> thats an interesting idea.
20:28:56 <jonathanspw> indeed.  keeps the whole thing less formal and plenty inclusive to anyone who contributes
20:28:58 <gotmax> jonathanspw: michel-slm: https://docs.ansible.com/ansible/latest/community/steering/steering_index.html is our documentation, but I never read through it thoroughly ;)
20:29:02 * nirik notes he removed himself from that group, so I wouldn't get a vote in that model, but thats not a show stopper. ;)
20:29:04 <tdawson> I guess since I wrote up the issue, I can write the pull request ... that will allow us to refine it and vote on it.
20:29:27 <neil> it would prevent a situation where someone tries to 'stack' the committee in its current form, whereby someone could have 50 people join and support their awful idea or whatever, but still not be closed off or as formal
20:29:29 <michel-slm> gotmax++
20:29:44 <carlwgeorge> neil: that's the exact situation i worry about
20:30:23 <nirik> another idea around consensus is to require consensus, and if there is still not full consensus, don't approve the thing (status quo).
20:30:23 <neil> though I also would note that that situation seems.. unlikely, it is still a good idea to have something written down as "insurance"
20:30:27 <dcavalca> yeah, if we're concerned about procedural abuse having specific rules is useful
20:30:54 <carlwgeorge> the only current remedy would be someone formally on the committee declaring it "contentiousness", which would throw out all non-committee votes, which likely wouldn't be received well
20:30:57 <dcavalca> does Fedora have any kind of project-wide guidelines on this stuff?
20:31:08 <dcavalca> like, this can't be the first SIG where the issue came up
20:31:18 <gotmax> How does the FPC handle this?
20:31:22 <nirik> not really. SIGs can organize however they like.
20:31:30 <gotmax> I think they have formal membership but no elections?
20:31:34 <rcallicotte_> interesting.
20:31:35 <nirik> FPC has specific seats/membership.
20:31:41 <carlwgeorge> nirik: consensus voting is unappealing to me because a single person can block anything and stop progress that everyone else favors
20:31:50 <neil> I feel as though (probably) it wouldn't be received well in any case, and, honestly if someone feels they had to do that to EPEL there are probably _bigger_ problems at play
20:32:02 <nirik> sure, thats a concern...
20:32:29 <nirik> I like leveraging the epel-packagers-sig... people doing actual work deciding things. ;)
20:33:30 <gotmax> I'm in favor of keeping the two groups separate
20:33:48 <gotmax> That group is supposed to be a way to ease maintenance not make decisions for EPEL as a whole
20:33:48 <carlwgeorge> i agree with gotmax, best not to conflate the purposes
20:33:53 <dcavalca> so fwiw, over on the CentOS side in Hyperscale we mostly operate on consensus, but we do have a process for formal votes in case that cannot be reached (and also a process for chair elections)
20:34:07 <carlwgeorge> with proper elections the people doing the work have an advantage to get chosen anyways
20:34:09 <dcavalca> that has worked well for us so far, but I can't say we had many actually controversial things come up there
20:35:07 <dcavalca> and to be clear by consensus I mean the "does anybody object?" approach, not the formal consensus voting protocol thing
20:35:08 <tdawson> I'm going to timebox this for just 5 more minutes.
20:35:41 <nirik> perhaps someone could write up some options in the ticket? see where most people are leaning (before doing a pr or anything)
20:35:52 <dcavalca> ^^ yes please
20:35:58 <tdawson> But I do like the ideas that are coming and will try to put them in the pull request
20:36:14 <dcavalca> having written down alternatives coming from people that feel strongly about them would be valuable
20:36:17 <neil> gotmax: to clarify, I meant that it would be similar to your example of the ansible community, just that only epel-packagers-sig would be able to vote on things (as opposed to anyone with an (irc|matrix) client). that would be in addition to EPSCO who wouldn't really change except to have their votes counted differently than epel-packagers-sig.
20:36:17 <neil> IDK--maybe that's too much formality
20:36:20 <dcavalca> so folks can compare them and make up their mind
20:36:39 <nirik> dcavalca: +1
20:36:45 <neil> dcavalca: +1
20:36:46 <tdawson> OK ... I could put that stuff in the ticket instead of a pull request.
20:36:55 <pgreco> +1
20:37:24 <gotmax> neil: I get it, but I still don't think decision making should be based on the packagers-sig. It was purposely set up separately from the steering committee.
20:37:53 <dcavalca> do we have an epel-sig FAS group separate from the packagers one?
20:37:55 <nirik> yeah, perhaps not...
20:38:13 <tdawson> So, things to put in are A) How long to serve   B) How they are selected and C) Voting in general  ... is that correct?
20:38:47 <neil> gotmax: understood
20:38:50 <carlwgeorge> sounds about right to me
20:38:54 <dcavalca> s/voting/decision making/ (of which voting is a part if we decide to go with voting)
20:38:58 <dcavalca> but yeah, +1
20:39:31 <nirik> https://paste.centos.org/view/0b118f69
20:39:49 <neil> epel-cabal is the obvious choice
20:39:54 <tdawson> OK, I'll get those three things onto the issue. .... and the timebox has ended.
20:39:55 <nirik> for voting see the recent fesco ticket on that... it gets... complicated.
20:40:01 <dcavalca> <3 epel-cabal
20:40:05 <tdawson> Is there any other Old Business before we move on to Open Floor?
20:40:25 <nirik> I have no memory of that group... but I am in it! :) along with pgreco...
20:40:28 * michel-slm has a couple of related items for open floor
20:40:34 <nirik> and tdawson
20:40:36 <michel-slm> and would love to join any cabal he can :D
20:40:39 * dcavalca also has an item for open floor
20:40:50 <neil> michel-slm: same
20:41:03 <neil> i'm always up for cabals and/or cults
20:41:03 <tdawson> #topic General Issues / Open Floor
20:41:05 <neil> preference for both
20:41:14 <carlwgeorge> personally i like wranglers better than cabal, but that's probably just my texan-ness showing
20:41:14 <michel-slm> Cult of the Dead Penguin
20:41:24 <tdawson> michel-slm: I think you are first for Open Floor
20:41:26 <rcallicotte_> lol
20:41:38 <neil> CuDL would be a better acronym IMO but.. yes :)
20:41:42 <michel-slm> alrighty. it's related to carl's old business -- I am trying to decide on the fate of two packages. let's do one first
20:42:14 <jonathanspw> carlwgeorge: epel-cowboys
20:42:14 <michel-slm> python-django -- for EPEL it's a very old version (2.x IIRC). should we just announce it's going to be retired and point people to python-django3 and (when it's ready) python-django4.2 ?
20:44:28 <michel-slm> the second is zeek https://github.com/zeek/zeek/wiki/Release-Cadence#types-of-releases
20:44:50 <nirik> +1 to announce/retire and point to newer/supported one on django
20:45:03 <michel-slm> the original maintainer is no longer around, and it's now.. on an unmaintained version. this is the upstream policy - https://github.com/zeek/zeek/wiki/Release-Cadence#types-of-releases
20:45:09 <jonathanspw> +1 on django as well
20:45:30 <carlwgeorge> such is the nature of epel packages with volunteer maintenance
20:45:50 <neil> +1 for django
20:45:51 <michel-slm> what I'm thinking of is using the Fedora branches to track the feature releases (x.y.z) and announce on epel-devel that the current release (4.x) will get an incompatible upgrade soon to the latest LTS (6.0.x)
20:46:01 <dherrera> sure, I agree on django
20:46:13 <neil> I like the idea with zeek. happy to help with that, too
20:46:20 <neil> I'm friendly with the Zeek folks..
20:46:30 <dcavalca> neil: help with that one would definitely be appreciated
20:47:04 <michel-slm> neil: nice, yes please
20:47:22 <michel-slm> upstream has problems with their OBS builds for c8 (and have not touched c9) so once we update our package we should give them a hand
20:47:44 <michel-slm> and hopefully also upstream changes to their cmake setup so it's easier for us to browbeat it back to compliance :)
20:47:50 <neil> :D
20:47:54 <michel-slm> that's all I have, who's next?
20:48:12 <dcavalca> I can go
20:48:30 <dcavalca> you might remember from ~1yr ago discussions about getting a qemu build in EPEL
20:48:37 <dcavalca> https://bugzilla.redhat.com/show_bug.cgi?id=1995353 for context
20:48:51 <dcavalca> I'm now picking this back up due to renewed interest from folks at work
20:48:57 <tdawson> Cool
20:49:02 <neil> awesome :)
20:49:04 <dcavalca> the good news is that the situation in el9 is _much_ better
20:49:12 <neil> awesome-er
20:49:16 <dcavalca> there is one remaining hard blocker, which is https://bugzilla.redhat.com/show_bug.cgi?id=2232798
20:49:29 <dcavalca> and a few missing optional deps, such as https://bugzilla.redhat.com/show_bug.cgi?id=2232766
20:49:59 <dcavalca> my plan is to do this in Hyperscale first to validate things, and then eventually get a subset of that as an EPEL build
20:50:12 <dcavalca> https://git.centos.org/fork/dcavalca/rpms/qemu/commits/c9s-sig-hyperscale is the WIP branch I have at the moment
20:50:27 <nirik> cool.
20:50:31 <dcavalca> the hard issue I haven't resolved yet is package name conflicts
20:50:41 <dcavalca> as both qemu and qemu-kvm provide things like qemu-img
20:51:06 <dcavalca> the "best" way to solve that would be for qemu-kvm to namespace these (so do qemu-kvm-img), but that seems... unlikely tbh
20:51:16 <dcavalca> which is why I haven't even filed a ticket for it yet
20:51:24 <nirik> could do the epel side as qemu-epel...
20:51:36 <nirik> but thats not great. ;(
20:51:41 <dcavalca> nirik: yeah, that's one option
20:51:59 <nirik> or just avoid building those things and depend on qemu-kvm for them?
20:52:25 <carlwgeorge> namespacing the provides seems like a reasonable request to me, and worse they can say is no
20:52:35 <dcavalca> that would probably work for EPEL iff we keep the EPEL 9 and el9 versions in sync
20:52:56 <dcavalca> carlwgeorge: the reason I feel this would be tricky is because a bunch of other packages pull this in (e.g. libvirt) so it would snowball quite a bit
20:53:11 <dcavalca> this isn't a provides, it's an actual package
20:53:20 <dcavalca> i.e. qemu-kvm does `%package -n qemu-img` :(
20:53:32 <neil> and has ripple effects into other projects like RDO, I suspect
20:53:37 <carlwgeorge> ahh, so provide a subpackage, not a `Provides:`
20:54:01 <carlwgeorge> yeah changing packages names does seem unlikely
20:54:02 <nirik> I think best would just be not building those/providing them in the epel version...
20:54:15 <dcavalca> the scope on my end is going to be mostly around qemu libvirt and libguestfs, as that's what we use at Meta, but I expect this would have impact beyond that
20:55:10 <dcavalca> nirik: yeah, if that can be made to work it's likely the least painful option, at least for now
20:55:48 <nirik> There may likely be more than just qemu-img. ;( But yeah...
20:56:02 <dcavalca> I'm going to try and get a Hyperscale build out sometime soon so we can use that as a starting point
20:56:44 <carlwgeorge> dang, qemu in fedora has a lot of subpackages
20:56:48 <tdawson> Not to cut this short, cuz I'm all for this.  But didn't someone else say they had something for Open Floor?
20:57:24 <neil> don't think so - it w as just dcavalca and michel-slm's two items
20:57:44 <neil> i.e., django2, zeek, and qemu
20:57:50 <michel-slm> neil said same but I think not in this context
20:58:03 <dcavalca> oh and as part of this I also made this abomination: https://src.fedoraproject.org/rpms/edk2-epel/commits/epel9
20:58:08 <michel-slm> so... we're done? I'll announce the Django and Zeek plans on the mailing list
20:58:10 <tdawson> Ah ... ok.  Then, continue.  Ya.  I thought neil was the one who had an item.
20:58:15 <neil> ah, yes. that was me. sorry!
20:58:26 <dcavalca> if someone can bribe whoever maintains edk2 in RHEL to include those missing subpackages in el10 that would be appreciated
20:58:52 <dcavalca> the delta for the package in el9 is too great, so unless it gets rebased it's not really worth considering there
20:59:19 <dcavalca> that's all I had :)
20:59:29 <neil> since i've been called on.. i have working epel branches for `nebula` - going to reach out to the fedora maintainer and see if they'd add me as a comaintainer for EPEL
20:59:47 <jonathanspw> neil i was going to work on that one soon :p
21:00:16 <neil> :D well.. it's a vendor tarball one for now - but if you want to tag team the EPEL 9 golang dependencies, we could start that project
21:00:21 <neil> it's about 300 long so far
21:00:27 <dcavalca> neil: `ebranch issues` is quite handy for these
21:00:29 <jonathanspw> yeah tarball is the only way for now.  dep list is huge
21:00:43 <neil> https://rpa.st/MRHA
21:01:27 <rcallicotte_> oh is that all??!! wowsers
21:01:27 <dcavalca> FYI the golang-x-* packages are cursed
21:01:30 <neil> dcavalca: gotta pick which ones and only do a few a week :P
21:01:41 <dcavalca> they have circular dependencies between them and are generally a pain
21:01:55 <neil> if I attack them, i'll only attack EPEL 9
21:01:59 <dcavalca> and I already have tickets for a few of those in that list like yaml
21:02:07 <neil> i did see a few of yours that overlapped, yeah
21:02:12 <neil> some testing/mocking libs, too
21:02:15 <michel-slm> dcavalca: I think neil is already using ebranch :) ... oh, yeah ebranch issues is nice for filing branch requests in a consistent way
21:02:24 <dcavalca> waiting for two more deps to get sorted out so I can import that stack (I was trying to branch protolock)
21:02:30 <carlwgeorge> i for one am ready for fedora to adopt an official bundling preference for golang and rust, similar to nodejs
21:02:37 <neil> michel-slm yep, dcavalca reminded me about it last week
21:02:41 <tdawson> Yep, me too.
21:02:44 <neil> carlwgeorge++
21:02:57 <neil> michel-slm++
21:02:59 <neil> (for ebranch)
21:03:00 <tdawson> Oh ... I just saw the time.
21:03:07 <dcavalca> I have opinions on this subject but we're already out of time, so probably best for another venue :)
21:03:09 <neil> time flies when we're having fun
21:03:13 <tdawson> Yep
21:03:28 <michel-slm> not sure what happened to zodbot and karma, haven't seen anything processed
21:03:37 <michel-slm> or does it have to use FAS usernames? oh well
21:03:38 <tdawson> Thank you all for the work you have been doing for EPEL and it's communitee.  It's always great to continue to work with you all.
21:03:43 <michel-slm> thanks all!
21:03:48 <pgreco> thanks all!, bye!
21:03:50 <tdawson> Talk to you next week, if not sooner.
21:03:53 <neil> Thank you tdawson, all!
21:03:57 <tdawson> #endmeeting