20:02:44 <gotmax> #startmeeting EPEL (2022-07-20)
20:02:44 <zodbot> Meeting started Wed Jul 20 20:02:44 2022 UTC.
20:02:44 <zodbot> This meeting is logged and archived in a public location.
20:02:44 <zodbot> The chair is gotmax. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:02:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:02:44 <zodbot> The meeting name has been set to 'epel_(2022-07-20)'
20:02:51 <gotmax> Second time's the charm
20:02:54 <gotmax> #meetingname epel
20:02:54 <zodbot> The meeting name has been set to 'epel'
20:02:59 <nirik> hurray. :) morning everyone
20:03:24 <gotmax> #chair nirik davide rsc pgreco rcallicotte dherrera gotmax[m]
20:03:24 <zodbot> Current chairs: davide dherrera gotmax gotmax[m] nirik pgreco rcallicotte rsc
20:03:24 <rcallicotte> howdy!
20:03:26 <salimma> .hi
20:03:26 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:03:29 <davide> .hello dcavalca
20:03:30 <zodbot> davide: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:03:38 <smooge> hrllo
20:03:39 <gotmax> #chair salimma
20:03:39 <zodbot> Current chairs: davide dherrera gotmax gotmax[m] nirik pgreco rcallicotte rsc salimma
20:03:44 <gotmax> #chair smooge
20:03:44 <zodbot> Current chairs: davide dherrera gotmax gotmax[m] nirik pgreco rcallicotte rsc salimma smooge
20:03:46 <gotmax> Hi smooge
20:03:54 <carlwgeorge> .hi
20:03:55 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:03:56 <salimma> hi all
20:04:00 <gotmax> #chair carlwgeorge
20:04:00 <zodbot> Current chairs: carlwgeorge davide dherrera gotmax gotmax[m] nirik pgreco rcallicotte rsc salimma smooge
20:04:17 * gotmax doesn't know if he's supposed to chair everyone, but whatever...
20:04:42 <gotmax> Let's wait a minute or two for more people to show up and then get started
20:05:49 <carlwgeorge> i think originally we would chair just the official committee members, but i couldn't even tell you anymore who is or isn't that
20:06:05 <gotmax> Fair enough
20:06:16 <gotmax> #topc EPEL Issues
20:06:20 <gotmax> https://pagure.io/epel/issues?tags=meeting&status=Open
20:06:31 <gotmax> I didn't see anything pertinent here
20:06:47 <salimma> I have updated my PR per discussion last week
20:06:55 <gotmax> Oh, you did
20:07:03 <salimma> https://pagure.io/epel/pull-request/182
20:07:05 <gotmax> Like earlier today?
20:07:09 <salimma> didn't get round to it until this morning, sorry. yeah
20:07:29 <gotmax> No worries. I checked earlier and didn't see it
20:07:33 <salimma> there's a new section discussing notification for packages pulled into RHEL, covering both scenarios
20:07:41 * gotmax reads
20:07:51 <gotmax> Not sure if we want to vote sync or async
20:08:57 <gotmax> What is the reference a bug part?
20:09:03 <gotmax> All retirements need a bug now?
20:09:09 <gotmax> Or is that just a suggestion?
20:10:12 <smooge> I am against this: `If a majority of those present at the EPEL meeting concur, the package can be retired.`
20:10:44 <smooge> I would only be for that if someone is  willing to take it over during that meeting.
20:10:46 <salimma> "reference a bug" is for retiring a non-conflicting package due to a security vulnerability
20:11:19 <gotmax> I would suggest making it clear that those things are example/suggestions
20:11:38 <gotmax> Sometimes people take policies very literally and then complain about how it's too strict
20:11:38 <salimma> smooge: hmm... but this is for retiring a package that has serious issues, right? if someone wants to take it over, it won't have to be retired
20:12:03 <salimma> gotmax: sure, I can mark everything as SHOULD if that helps
20:12:16 <smooge> salimma, and if for some reason the people in the meeting say 'you have to keep it in' then the package is no longer volunteered
20:12:19 <gotmax> (See the recent confusion about the stalled requests policy on devel@)
20:12:41 <gotmax> smooge: Agreed
20:13:05 <davide> yeah, I'd say if folks object to the package being retired, and nobody wants to take it on, they get to volunteer
20:13:14 <salimma> ah! yeah
20:13:26 <gotmax> At least my understanding is that we're trying to require retirements  to be announced, not make it so much harder to retire packages
20:13:31 <salimma> I can clarify it. so basically give the steering committee a heads up, but the purpose is to give someone a chance to take it over
20:13:50 <salimma> I can skip that part too, if that's considered too onerous
20:13:55 <smooge> there are multiple reasons why a person can no longer handle a package. It could be that it has a bunch of security or doesnt work because RHEL rebased a bunch of stuff or 'I no longer work on anything RHEL related and just compile stuff on my mac'
20:14:46 <smooge> as much as I would like to be able to keep packages in no matter what.. that takes 'dedicated' time and if a volunteer doesnt have it.. they don't have it
20:14:48 <gotmax> I would hope that the steering committee members read the ML and see the announcement there
20:14:51 <davide> so, there's probably two realistic cases here
20:14:54 <salimma> right. but apart from 'this is broken (security or feature)' orphaning seems the way forward rather than retiring, right?
20:15:12 <davide> one is a maintainer that doesn't have time/inclination/whatever to keep dealing with a package, and then they can ask for someone else to take it over
20:15:18 <salimma> another thing we haven't seriously discussed is... how does orphaning 'only' in EPEL works
20:15:18 <davide> the other is a package that is just irremediably cursed
20:15:35 <davide> say, something with crazy security issues that can't be realistically brought up to date or kept up to date
20:15:39 <gotmax> davide: We discussed the orphaning issue briefly
20:15:53 <gotmax> It doesn't really work in the same way it does in Fedora
20:16:02 <smooge> i haven't seen orphaning work well in EPEL so my experiences are clouding my judgement
20:16:42 * davide isn't sure how orphaning for EPEL works either in practice
20:16:56 <carlwgeorge> you can retire just epel branches
20:17:18 <gotmax> It doesn't work on a per-branch basis and you can't automatically take just the EPEL branches if the EPEL assignee is set to orphan
20:17:18 <smooge> I get confused on what one can and can't do
20:17:23 <carlwgeorge> orphan specifically means removing yourself from the entire distgit repo (giving it to the "orphan" user)
20:17:24 <davide> that's for retiring, but there's no equivalent of "click the orphan button and let someone else take it over" for epel
20:17:35 <salimma> right, we can just retire epel, but there's nothing like the Fedora 'let it go, if nobody picks it up then it gets auto-retired eventually'
20:17:54 <salimma> and the way ACL is set up we can't really do that
20:18:06 <gotmax> Yes
20:18:11 <davide> I feel like we're getting closer to needing a stronger "ownership" concept for branches in dist-git
20:18:17 <carlwgeorge> my point was just that orphan isn't the right word as that means the entire package
20:18:19 <davide> where ownership is definitely the wrong word
20:18:26 <gotmax> I believe that used to exist in pkgdb, but that's before my time
20:18:30 <gotmax> in Fedora
20:18:40 <carlwgeorge> yeah pkgdb had branch "owners"
20:18:47 <davide> this also ties into the confusion with the EPEL bugzilla assignee thing I'm seeing fairly consistently
20:19:01 <gotmax> davide: Can you elaborate?
20:19:01 <nirik> we dropped 'owners' a long time ago
20:19:05 <carlwgeorge> part of the rationale to not re-implement that in pagure was that fedora and epel maintainers should work closer together
20:19:18 <salimma> carlwgeorge: yeah. I guess I don't really want to have that feature for epel branches, but just saying we don't have any option less harsh than retirement for packages that are 'still working, but maintainer has no time to keep it going'
20:19:33 <davide> in my experience the BZ assignee for EPEL is often assigned to someone who happened to care about EPEL a long time ago, but doesn't necessarily now
20:19:39 <davide> that or it's assigned to the main packager
20:19:45 <gotmax> I see
20:19:50 <salimma> the problem is only the main admin can change the EPEL bz assignee
20:19:56 <gotmax> Yeah, exactly
20:19:58 <davide> ^^ yes, this
20:19:58 <salimma> I think even other admins can't
20:20:02 <smooge> nope
20:20:05 <salimma> so the info gets super stale
20:20:07 <gotmax> We discussed this on devel@ a little while ago
20:20:42 <smooge> I feel many times that the entire system is built around a world of tools and roles which sort of existed 10 years ago but do not now
20:21:15 <nirik> we can change things... ;)
20:21:38 <gotmax> Reminder that we've spent 15 minutes on this topic :)
20:21:38 <smooge> or the problem is that 'we can change things' :)
20:21:40 <nirik> if it makes sense and we think it will help
20:22:39 <salimma> so on my part, I can rework based on the input here, and we can move on for now
20:22:39 <gotmax> I'm not sure if we want to vote on this if salimma still has changes to make, but perhaps we want to bring the orphaning subtopic to the ML?
20:22:58 <salimma> yeah, let's discuss that part there
20:23:03 <carlwgeorge> agreed
20:23:06 <gotmax> Who wants to introduce it?
20:23:17 <smooge> salimma, here are my comments on the PR. 1. Please line wrap consistently so I don't have to find the scroll bar to finish sentences :). 2. we probably need better wording for orphaning and retiring
20:23:49 <gotmax> I think other groups try to keep to sembr in their docs
20:24:19 <gotmax> Last call before I move on
20:24:30 <salimma> smooge: you don't use Emacs? ;)
20:24:42 <smooge> I was reading the PR in the web
20:24:42 <salimma> let me see how other docs are written and stick to it
20:25:17 <gotmax> #action salimma to update the package retirement policy PR
20:25:36 <gotmax> #info We'll have a larger discussion about orphaning EPEL branches and what that means on the ML
20:25:45 <gotmax> #topic Old Business
20:25:51 <smooge> move on.. I am just terminally grumpy today
20:26:21 <gotmax> That was kind of old business, but speak up if I'm missing anything
20:27:35 <gotmax> #topic EPEL-7
20:27:40 <gotmax> #info epel7 will be retired on 2024-06-30 in line with the end of the rhel7 maintenance 2 phase
20:27:51 <gotmax> Anything for EPEL 7?
20:27:59 <gotmax> This topic tends to be pretty quiet...
20:28:33 <carlwgeorge> like epel7 itself
20:28:37 <nirik> 🦗s
20:28:51 <rcallicotte> lols
20:28:58 <gotmax> carlwgeorge: Exactly
20:29:07 <gotmax> #topic EPEL-8
20:29:11 <gotmax> #info epel8-next will be retired on 2024-05-31 in line with the c8s eol (end of rhel8 full support phase)
20:29:28 * gotmax has something, but he'll be a good chair and let everyone else go first
20:29:33 <carlwgeorge> epel8 is getting a boost1.78 package soon
20:30:04 <carlwgeorge> there was a review request for it, and i helped them out and clarified that scenarios qualifies for an exception
20:30:16 <gotmax> You want to #link it?
20:30:22 <carlwgeorge> stock el8 only has boost 1.66 and that's a blocker for some apps
20:30:26 <carlwgeorge> yeah lemme find it
20:30:48 <carlwgeorge> #info boost1.78 coming to epel8
20:30:55 <gotmax> So this is an upwards compat package?
20:31:02 <carlwgeorge> #link https://src.fedoraproject.org/rpms/boost1.78
20:31:13 <carlwgeorge> #link https://bugzilla.redhat.com/show_bug.cgi?id=1828059
20:31:30 <carlwgeorge> yes, parallel installable (supposedly, i haven't checked myself)
20:31:50 <gotmax> Yeah, that was going to be my next question
20:31:50 <carlwgeorge> same person has done boost148 and boost169 previously
20:32:23 <gotmax> Got it
20:32:52 <gotmax> Anyone else have anything?
20:33:40 <gotmax> Alright, here's my thing:
20:33:45 <gotmax> #link https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/47
20:33:53 <gotmax> #link https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/3PR5IW57DGZGQDAX5DNZLM7HSY6RGQ2R/
20:34:02 <carlwgeorge> oh was this what you were asking me about yesterday?
20:34:05 <gotmax> Yeah
20:34:11 * nirik is fine pushing that now
20:34:22 * gotmax already pushed it by accident
20:34:23 <carlwgeorge> sorry for not getting back to you on that, got busy
20:34:28 <gotmax> Don't worry :)
20:35:08 <carlwgeorge> in general for python stuff, if miro gave you a thumbs up then i blindly agree
20:35:09 <gotmax> Usually when I'm stupid and try to push to "origin" instead of my fork, I get denied, but now I'm a provenpackager, so...
20:35:20 <gotmax> carlwgeorge: Fair enough
20:35:50 <gotmax> There's also ~23 packages that need to be rebuilt
20:36:20 <gotmax> I figured it would be a good idea to mention that here
20:36:23 <salimma> gotmax: yeah, provenpackager is overly strong. I thought about making it so you can force-push but must pass a special flag
20:36:41 <salimma> because ... sometimes in pagure you mark a package as not accepting direct push, and provenpackager trumps that
20:36:50 <carlwgeorge> weird, the pr says 0 commits now
20:37:10 <gotmax> Yeah, because I accidentally pushed it already, so it's up to date
20:37:20 <carlwgeorge> yeah i know why, it's just weird to see
20:37:28 <nirik> yeah, thats happened before.
20:37:32 <nirik> no great biggie.
20:37:42 <carlwgeorge> also in this case github would show it as merged if the commits are in the target branch
20:37:43 <gotmax> It was my first day of being a PP none the less :(
20:38:01 <gotmax> But thanks
20:39:11 <carlwgeorge> so yeah lets build that and get it into epel-testing
20:39:19 <gotmax> Ack
20:39:25 <gotmax> And the rebuild?
20:40:49 * gotmax kicks off the epel-rpm-macros build
20:41:11 <nirik> we should... but who would like to do that? ;)
20:41:20 <gotmax> I can I guess
20:41:26 <smooge> well how do we do it? bump and rebuild via releng script?
20:41:31 <carlwgeorge> proven packagers have the power to make mistakes, and clean them up :P
20:41:54 <gotmax> At least, the broken generator wasn't my mistake. But I am cleaning it up :)
20:42:09 <carlwgeorge> yes not trying to specifically place blame
20:42:28 <gotmax> smooge: I have a script that I use for the go rebuilds
20:42:29 <nirik> yeah, do them in a side tag?
20:42:35 <gotmax> Yes
20:42:46 <gotmax> If releng wants to do it, be my guest :)
20:43:10 <nirik> speaking as the only releng person left around thats not on pto... no thanks, you can. ;)
20:43:17 <smooge> I don't think releng wants to do it
20:43:22 <gotmax> I didn't think so
20:43:33 <smooge> i was talking about the prebuilt scripts which releng has
20:43:46 <gotmax> #action gotmax to rebuild the packages affected by the broken python dep generator
20:43:46 <smooge> but if you have a set already too that works
20:44:10 <carlwgeorge> yeah if it's manual work, gotmax and other pp's (i can help) can split up the ~23 packages
20:44:17 <carlwgeorge> but an automated script would be better if it works
20:44:33 <gotmax> I think releng's is for rebuilding the whole distro, but I admittedly haven't really looked at it
20:44:39 <carlwgeorge> ahh
20:45:00 <gotmax> carlwgeorge: It shouldn't be to difficult, but I'll let you know
20:45:29 <nirik> there's another script I have that the java-sig was using thats pretty nice
20:45:39 <gotmax> I usually do it with "fedpkg build --background" so I don't hog resources which makes it take a bit longer, but not too much manually work
20:45:46 <gotmax> nirik: Feel free to send it to me :)
20:45:57 <nirik> it looks at a pr, builds that package with it in copr, figures out what deps on it, builds alll those in copr
20:46:07 <gotmax> This is mine: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/build2.sh
20:46:11 <nirik> more usefull for pre-work than the actual build.
20:46:19 <gotmax> It does some special things to handle merging from stable branches
20:46:47 <gotmax> That's all I have for that topic
20:47:03 <gotmax> I started writing the email about module retirements, and then I noticed something weird:
20:47:12 <gotmax> There's a good amount of default modules that are already retired
20:47:29 <gotmax> But they're still the default in RHEL, so we're building against them
20:48:08 <gotmax> Does anyone know more about this?
20:48:15 <nirik> yeah, because rhel never ever removes anything. ;(
20:48:53 <gotmax> I guess. Still seems like it should be changed, but I guess that's not our call
20:49:10 * gotmax overuses the phrase "I guess"
20:49:17 <smooge> so it is a mess
20:49:30 <gotmax> I'd like to move on, as we're running low on time
20:49:38 <gotmax> Speak now or forever hold your peace
20:49:40 <gotmax> or piece
20:49:45 <gotmax> I don't know which one it actually is
20:49:49 <smooge> peace
20:50:03 <smooge> as in peace and quiet
20:50:08 <gotmax> I see
20:50:35 <gotmax> Alright
20:50:39 <gotmax> #topic EPEL-9
20:50:56 <gotmax> I guess you'll have to at least hold your peace until open floor
20:51:07 <carlwgeorge> #info epel9 has hit a milestone of 3k source packages
20:51:17 <rcallicotte> saweet!
20:51:27 <gotmax> 🎉
20:51:53 <pgreco> gotmax: I haven't done anything with the packages I mentioned last week, :( I should quit my job so I have time for epel stuff... :D
20:51:56 <smooge> congrats
20:52:11 <gotmax> pgreco: Which packages again?
20:52:12 <carlwgeorge> exact number is 3083.  for reference epel8 is currenlty 4539.
20:52:32 <pgreco> bwm-ng and autossh
20:52:35 <rcallicotte> wow.
20:52:41 <carlwgeorge> i'm hoping that epel9 can surpass epel8 this year
20:52:50 <pgreco> one branched but never pushed, the other never branched (but bugzilla filed)
20:52:54 <gotmax> Ah
20:53:03 <carlwgeorge> and the big dog of course is epel7 at 7268 source packages
20:53:13 <gotmax> pgreco: Didn't we just say to file a stalled EPEL request ticket?
20:53:30 <pgreco> gotmax; yeah, never got to it...
20:53:33 <carlwgeorge> oh that reminds me, i dropped the ball on rewording the epel stalled policy to account for a maintainer disappearing part way through
20:53:36 <smooge> gotmax, I think pgreco also alluded to that they didn't have time
20:53:57 <gotmax> You're right. Should've read that more closely :).
20:54:08 <carlwgeorge> i had two days of jury duty since the last meeting and it's thrown everything off
20:55:11 <gotmax> Yay for democracy
20:55:23 <gotmax> Anyways...
20:55:31 <gotmax> #topic General Issues / Open Floor
20:55:41 <gotmax> The floor is open. Be careful not to fall in.
20:55:54 <davide> I have a couple of things on the EPEL Packagers SIG front
20:55:55 * gotmax shamelessly steals nirik's joke
20:55:56 * nirik teaters on the edge
20:56:00 <rcallicotte> #link https://pagure.io/epel/pull-request/189
20:56:13 <rcallicotte> ahh. davide was first
20:56:22 <davide> I spent some time last week filing stalled requests for bugs attached to the tracker
20:56:29 <davide> so most should be taken care of now
20:56:34 <gotmax> davide++
20:56:34 <zodbot> gotmax: Karma for dcavalca changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:56:43 <davide> I also got cross-binutils and cross-gcc branched and built for epel8 and epel9
20:56:49 <gotmax> Oh yay! It's finally working...
20:57:01 <davide> had to make a minor fix for cross-gcc and tried upstreaming it to rawhide, but Pagure isn't cooperating
20:57:09 <smooge> gotmax, for open floor. There is a general problem with many of the modules in EL8 being 'retired' but what we and everyone else default to when installing
20:57:09 <davide> https://src.fedoraproject.org/rpms/cross-gcc/diff/rawhide..epel8 isn't letting me make a PR, it just shows a diff
20:57:16 <smooge> I do not know if there is a solution
20:57:26 <davide> that's all I had
20:57:32 <gotmax> Yeah, sorry for moving past that before. I think it still is worthy of discussion
20:57:34 <smooge> but it is a known mess
20:57:42 <gotmax> Known by who?
20:57:46 <gotmax> (besides us)
20:57:53 <gotmax> *it is still
20:58:48 <smooge> I don't know exactly who knows.. I just bring it up and people say 'yes its known.'
20:59:04 <gotmax> Not sure what we can do about that
20:59:09 <smooge> nothing really
20:59:16 <carlwgeorge> pagure seems to kinda be in limbo
20:59:22 <nirik> I fear fixes would be in grobisplitter, and that code is...
20:59:41 <gotmax> Even if we wanted to tempt fate and try to mess around with grobisplitter, we can't really depend on things in other modules
21:00:49 <gotmax> Does someone want to ask internally or file a support case or something?
21:00:49 <smooge> well the issue is that it is a constant game of catchup. if we were to make grobisplitter know to use only THESE modules right now because htye are in support... then 2 weeks later its changed
21:00:51 <nirik> not sure what you mean?
21:01:49 <smooge> me or gotmax?
21:03:09 <carlwgeorge> i believe time is up
21:03:10 <gotmax> rcallicotte: Re your PR, I'm not really fluent in asciidoc. What does it actually do?
21:03:17 <gotmax> Yeah, I know
21:03:22 <nirik> well, perhaps I don't fully understand the problem... an example might help. but we could move to the lsit of #epel channel
21:03:32 <gotmax> I was going to let people finish, but I guess I should keep the time
21:03:36 <carlwgeorge> for rcallicotte's thing, i like it
21:03:41 <rcallicotte> all it does is draw the eye to the required bugzilla info
21:04:01 <rcallicotte> makes it easier to see for humans
21:04:15 <gotmax> Got it
21:04:31 <carlwgeorge> if no one is opposed i'll merge it
21:04:34 <davide> lgtm
21:04:35 <gotmax> I guess I'll end this at :06 to at least not go too far over
21:04:41 <rcallicotte> cool
21:05:00 <gotmax> (That's :36 if anyone here is in India)
21:06:36 <gotmax> #endmeeting