20:01:15 <tdawson> #startmeeting EPEL (2022-09-28)
20:01:15 <zodbot> Meeting started Wed Sep 28 20:01:15 2022 UTC.
20:01:15 <zodbot> This meeting is logged and archived in a public location.
20:01:15 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:01:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:15 <zodbot> The meeting name has been set to 'epel_(2022-09-28)'
20:01:16 <tdawson> #meetingname epel
20:01:16 <zodbot> The meeting name has been set to 'epel'
20:01:17 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge
20:01:17 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson
20:01:19 <tdawson> #topic aloha
20:01:27 <carlwgeorge> .hi
20:01:28 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:01:41 <salimma> .hi
20:01:41 <davide> .hello dcavalca
20:01:41 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:01:44 <zodbot> davide: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:01:45 <gotmax[m]> .hello gotmax23
20:01:50 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
20:01:59 <rcallicotte> .hi
20:02:00 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:02:01 <salimma> for a second I thought my Matrix client was misbehaving. because my other messaging app does this sometimes :P
20:02:11 <tdawson> Hi carlwgeorge salimma davide gotmax[m] and rcallicotte
20:02:22 <gotmax[m]> Hi tdawson
20:02:42 <tdawson> Sorry for that.
20:02:48 <dherrera> .hi
20:02:49 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:02:50 <nirik> morning
20:03:08 <tdawson> Today has been alot of "why isn't it happening, I'm clearly looking at this window, not that window."
20:03:28 <tdawson> Hi dherrera and good morning nirik
20:03:38 <rcallicotte> it happens
20:03:45 <smooge> jello
20:03:56 <tdawson> pudding
20:04:01 <salimma> tdawson: hug
20:04:11 <tdawson> Thanks salimma
20:04:14 <salimma> could be worse. you could have been pasting your password
20:04:23 <tdawson> Ha! ... yep
20:04:26 <salimma> happened to me once, thank goodness I never reuse passwords
20:04:32 * gotmax[m] shudders
20:04:38 <smooge> 123456letmein
20:04:40 <salimma> smooge: wait, you guys do jellos too?
20:04:42 <rcallicotte> haha
20:05:00 <carlwgeorge> **********
20:05:18 <tdawson> carlwgeorge: Wait ... you have the same password as me?
20:05:28 <rcallicotte> heh
20:05:39 <tdawson> #topic End Of Life (EOL)
20:05:41 <tdawson> RHEL 7 will go EOL on 2024-06-30
20:05:42 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:05:43 <rsc> .hello robert
20:05:43 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
20:05:43 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:05:50 <tdawson> Hi rsc
20:06:03 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:06:04 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:06:21 <gotmax[m]> I know someone who would just add an extra exclamation mark to their old password every 30 days when IT made them change it
20:06:41 <salimma> gotmax[m]: after a year that's 12 !s
20:06:45 <tdawson> .epel 198
20:06:46 <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
20:06:48 <rcallicotte> haha
20:06:50 <carlwgeorge> forced password rotation policies will do that
20:07:19 <tdawson> We already discussed and voted on the modularity stuff ... is there more that we need to talk about this week?
20:07:26 * orionp is sad that modularity has failed
20:07:35 <tdawson> Hi orionp
20:07:50 <gotmax[m]> I saw the epel-release PR. Can someone remind what the purpose of that is again?
20:07:51 * rcallicotte waves at orionp
20:08:29 <carlwgeorge> make the modular repos optional in the short term, similar to fedora-repos-modular
20:09:04 * nirik thinks thats a waste of time, but if you all want to then I suppose so
20:09:06 <carlwgeorge> it also means new installs from the epel-release url won't get the modular repos
20:09:12 <gotmax[m]> So how will that work for existing users?
20:09:32 <tdawson> Just so people know, this is the pull request being talked about - https://src.fedoraproject.org/rpms/epel-release/pull-request/25
20:09:40 <nirik> if they haven't modified them, the modular repos will disappear on upgrades...
20:10:30 <carlwgeorge> upgrade path will give them epel-modular-release unless they've disabled weak deps.  then at some point mirrormanager can point them to the archive of it instead of mirrors.
20:11:21 <salimma> at some point we want to stop recommending epel-modular-release, right? or will we continue to recommend them until c8 EOL
20:11:44 <salimma> (if we want to eventually stop, probably make sure the transition is long enough to not catch anyone by surprise)
20:11:49 <carlwgeorge> i suspect yes, but that can come later
20:11:51 <gotmax[m]> Another option is to not add any Recommends and add `Obsoletes: epel-release < last-n-v-r+1`
20:11:56 <gotmax[m]> So existing users will keep both packages
20:12:03 <gotmax[m]> But it won't get pulled in for new users
20:12:12 <gotmax[m]> Add that obsoletes to both subpackages
20:12:42 <carlwgeorge> thought about that, but for it to work properly that means epel-release has to also obsolete epel-release, which is confusing
20:13:06 * nirik thinks we should just set them to 0 and then later remove them... avoiding all this churn. ;)
20:13:11 <carlwgeorge> see https://src.fedoraproject.org/rpms/fedora-repos/blob/f36/f/fedora-repos.spec#_13
20:14:14 <gotmax[m]> carlwgeorge: Well we can always add a specfile comment. I think that's better than continuing to pull in deprecated content.
20:14:40 <tdawson> I like nirik's idea.  Start with setting them at 0.  Then if someone really wants them on, they will turn them on, which changes the config file.
20:14:42 <gotmax[m]> nirik's idea is also workable. Those files are `%config(noreplace)` so they'll remain enabled for existing users but not new ones.
20:15:47 <gotmax[m]> That's probably better if we're just going to remove those definitions later anyways.
20:17:05 <tdawson> Things got quiet
20:17:20 <tdawson> Is everyone thinking about what would happen if we set it to 0 ?
20:17:45 <salimma> I'm personally ok with having it disabled, and flip it on if people complain
20:18:04 <salimma> after all, people who complain about modules being deprecated don't seem to realize it doesn't even work, so they probably don't even use them
20:18:26 <carlwgeorge> people will complain no matter what, that shouldn't be reason to reverse course
20:18:36 <davide> agreed
20:18:53 <gotmax[m]> People kind some way to complain about everything that anyone does anywhere
20:19:02 <salimma> I wonder if someone will find this quote and accuse us of being 'just like GNOME developers' :P
20:19:04 <gotmax[m]> s/kind/find/
20:19:05 <carlwgeorge> i'm ok with the logic that since we plan to eol the repos that creating a subpackage isn't necessary
20:19:07 <rcallicotte> yes they do
20:19:28 <carlwgeorge> it was just the most obvious approach that i initially thought of
20:19:37 <tdawson> carlwgeorge: It was a good thought though.
20:19:50 <smooge> personally I am for whatever is the least work.
20:19:54 <gotmax[m]> It's nice that it aligns with Fedora, but if we're removing it anyways...
20:19:56 <nirik> yeah, if we were keeping them more I think it would be worth it... but as it is...
20:20:03 <carlwgeorge> i can rework the pr to set the modular repos to 0, instead of making a subpackage
20:20:17 <nirik> and do we want to set a 'we are removing these' date
20:20:18 <nirik> ?
20:20:20 <tdawson> carlwgeorge: I think that would be good.
20:20:40 <tdawson> Oh ... ya ... we never did set a date last week did we.
20:21:02 <gotmax[m]> We could also change the repo name as part of this PR
20:21:08 <smooge> I said we would start on it after Oct 15th mainly because I expected F37 to be out then and any fires in releng this causing be able to get focus
20:21:13 <gotmax[m]> Adding `[DEPRECATED]` to the beginning or something
20:22:30 <tdawson> Is November 1st a good goal ... something we can start spreading the word about?
20:23:09 <tdawson> Or ... even better would be say it's going away on October 31st.
20:23:12 <salimma> beginning of month is probably easier to remember, yeah
20:23:15 <salimma> or end
20:23:20 <salimma> ooh. Halloween
20:23:31 <salimma> I like it. then Nov 1 is All Saints' Day since we're clean of this mess
20:23:33 <nirik> avoiding holidays is hard...
20:23:55 <carlwgeorge> i'm major -1 to changing the repoid, people get real mad about that, way more mad than they would setting it to disabled
20:24:29 <carlwgeorge> many people have automation that disables/enables the repo based on the repoid, and changing the repoid invalidates that
20:24:29 <gotmax[m]> I'm not talking about the repoid. I'm talking about the repo name.
20:24:35 <salimma> yeah, people who might have automated repoid names might get surprised
20:24:40 <salimma> ah, jinks
20:24:58 <gotmax[m]> `--disablerepo=epel-modular` or whatever would still work exactly the same.
20:25:13 <carlwgeorge> my mistake, i misunderstood based on the square brackets in the deprecated suggestion
20:25:39 <gotmax[m]> Ah, I see how might've been confusing
20:25:49 <nirik> I have a feeling most people won't see it or care, but I suppose it could help someone
20:26:18 <carlwgeorge> so enabled=0 and the word deprecated in the repo name field, anything else?
20:26:25 <smooge> yes
20:26:30 <smooge> sorry agreed
20:26:33 <tdawson> Most people won't see it (because we'll be setting it to 0 at the same time) but those that do turn it on, will see it.
20:26:48 <tdawson> +1
20:27:18 <gotmax[m]> Right, I forgot about the `%config(noreplace)` thing I myself brought up a couple minutes ago :(
20:28:09 <gotmax[m]> Is the idea to merge this PR on Nov 1 or now?
20:28:24 <tdawson> Are we ok with October 31st being the date we turn it off?  Or at least say we're going to turn it off?
20:28:50 <salimma> do we anticipate any other changes to epel-release between now and then?
20:28:51 <tdawson> I have a good headline for a blog "EPEL 8 Modules gets the axe on Halloween"
20:29:00 <salimma> I guess we can merge now, push an update but land it on oct 31
20:29:14 <salimma> but if we might need additional releases before then, better wait
20:29:30 <nirik> I think we should do it now... and push another one removing the modular repos entirely on the sunset date?
20:29:36 <smooge> yes
20:29:45 <smooge> sorry I agree with nirik
20:29:57 <tdawson> +1 to nirik
20:30:00 <salimma> tdawson: we can give Larabel a heads-up to make sure that headline comes up :)
20:30:36 <gotmax[m]> I worry about setting it to disabled=0 now without an announcement. It'll break deployments.
20:30:49 <gotmax[m]> Or am I misunderstanding what's being proposed?
20:30:58 <tdawson> Well, we have at least 7 days.
20:31:12 <carlwgeorge> I'd like to have the enabled=0 in the testing repos when we announce
20:31:27 <carlwgeorge> with auto push disbanded
20:31:27 <tdawson> I was hoping to start getting the word out that we're officially doing this.
20:31:46 <nirik> I think we need two announcements... 1) we are doing this and they are now disabled by default and 2) we did it and they are removed entirely
20:32:50 <carlwgeorge> maybe an in-between announcement for the disabling update landing in stable
20:32:52 <salimma> yeah, putting it in testing then announce is nice
20:32:59 <salimma> then land it after a few days
20:32:59 <tdawson> And to be honest, halloween doesn't have to be the day we do the final chop off, it's just when we say we'll do it ... I don't think people will care (or notice) if we're a few days / weeks late.
20:33:17 <nirik> carlwgeorge: +1
20:33:18 <salimma> then the Phoronix headline will be 'epel modular repo undead'
20:33:21 <salimma> which is ok too :)
20:33:25 <salimma> +1 to carlwgeorge
20:33:27 <tdawson> *laughs*
20:33:53 <gotmax[m]> I think there needs to be at least a week or two before we set enabled=0
20:33:59 <gotmax[m]> But of course announce it now
20:34:18 <tdawson> Anything else on this before we move to the next topic?
20:34:48 <tdawson> .epel 199
20:34:51 <zodbot> tdawson: Issue #199: ensure EPEL bugzilla assignees point to valid packagers - epel - Pagure.io - https://pagure.io/epel/issue/199
20:35:07 <salimma> Davide Cavalca: this got skipped last week
20:35:12 <tdawson> davide: We've been waiting for you to come back from vacation for this.
20:35:31 <davide> thanks
20:35:48 <davide> this has come up a few times when branching packages, the latest one was https://bugzilla.redhat.com/show_bug.cgi?id=2121833
20:35:59 <davide> where the assignee was confused by getting the bug in the first place
20:36:18 <gotmax[m]> I think this needs to be a general Fedora thing
20:37:03 <salimma> related: some Fedora maintainers consistently reply 'I don't want to maintain this in EPEL but be my guest', I wish that can be automated somehow
20:37:08 <gotmax[m]> This type of problem is not unique to EPEL (although it may be more common there)
20:37:56 <davide> yeah, agreed
20:37:58 <nirik> I think this case was one of the ones fixed not long ago.
20:38:11 <nirik> but I might be wrong.
20:38:29 <nirik> salimma: we used to long ago just have a wiki page for that. :(
20:38:34 <gotmax[m]> Just throwing this out there:
20:38:35 <gotmax[m]> We could have some way to mass add epel-packagers-sig to packages
20:38:49 <salimma> gotmax[m]: ooh
20:39:09 <gotmax[m]> It could be a maintainer says they want this and it could be automatic for all there packages
20:39:15 <gotmax[m]> Or we just suggest people do that
20:39:17 * nirik worries that the epel-packager-sig is just branching/building and not maintaining. Hopefully thats an unfounded worry
20:39:18 <gotmax[m]> s/there/their
20:39:32 <tdawson> Well, isn't this more of an issue of the bugzilla isn't set right?
20:40:00 <gotmax[m]> Yeah, I'm not a huge fan of setting any SIG as the assignee for anything
20:40:14 <davide> nirik: tbh I think it very much depends on the package; for some random fringe python dep that only gets branched because something else needs it, yeah, it's not gonna get a ton of attention most likely
20:40:25 <salimma> yeah, bugzilla assignee vs having the SIG get access is different, though related
20:40:27 <tdawson> Or is that what you are talking about gotmax[m] ... if there is a package that has the epel-packagers-sig set, automatically set them as the bugzilla
20:40:41 <davide> I don't think we can do that automatically
20:40:56 <davide> I had packages where the maintainer wanted to maintain in EPEL, but was fine adding the SIG for the extra help
20:40:58 <salimma> a lot of these bugs are about us asking to branch, right? since otherwise even provenpackagers can't do anything
20:41:10 <tdawson> Well, even manually.  Get a list of the packages, and make sure they are the EPEL bugzilla owners.
20:41:41 <tdawson> davide: Ahh ... ya.  I've had a few of those too.
20:42:03 <gotmax[m]> My idea was to add epel-packagers-sig as a contributor preemptively
20:42:19 <salimma> so de facto, epel-packagers-sig act like provenpackager on fedora
20:42:33 <salimma> if you're a member you can branch and build on EPEL
20:42:49 <gotmax[m]> For packages/packagers that opt in
20:42:51 <salimma> that will remove a lot of friction, but... might be controversial
20:42:56 * nirik isn't sure about that... can ponder on it.
20:43:22 <nirik> I also need to run... will read up the rest of the meeting when I get back online.
20:43:39 <gotmax[m]> We wouldn't impose it, but as long as a maintainer opts in and the EPEL maintainer communicates, it might just work
20:44:08 <tdawson> I'm not seeing the point in this.   If the maintainer opts in, then they usually have already added us.
20:44:16 <salimma> how do you imagine the opting in work gotmax (He/Him) ?
20:44:16 <davide> I can kinda see this pairing well with ELN Extras too
20:44:52 <davide> so you'd get an opt in and a starting point for the N+1 release as well
20:45:00 <salimma> tdawson: one difference is gotmax is imagining you opt in once for all your packages
20:45:00 <davide> maybe even branch automatically at that point
20:45:15 <tdawson> Ahh ... ok.
20:45:19 <salimma> I just filed a lot of bug requests for the public-inbox Perl dependencies. most of them go to the same RH employee :)
20:45:20 <davide> I don't think we can make this global, it won't work for everyone
20:45:26 <davide> though it might for some people
20:45:44 <gotmax[m]> We could provide a script for packagers to run to mass add it to their packages, just suggest that maintainer do it for new packages, or:
20:45:47 <salimma> so this would save a lot of hassle both on my end (filing) and on his end (going to the different settings menus). at least with my script he has a link to click
20:45:54 <tdawson> So like the fedora rubygem-sig could add epel-packagers-sig to all the rubygems, then I wouldn't have to ask for each one of them.
20:46:28 <salimma> behold: https://bugzilla.redhat.com/buglist.cgi?bug_id=2121592&bug_id_type=anddependson&format=tvp&list_id=12949793
20:46:47 <salimma> gotmax[m]: yeah, and if that script let you use wildcard or list several packages on the same line
20:46:50 <gotmax[m]> We could work it into the scm-requests process. So we'd have some way for packagers to opt in, and then the create repo script would just add the ACL on their new packages
20:46:54 <gotmax[m]> But I'm very iffy about that
20:47:09 <gotmax[m]> I'm kind of throwing out ideas and seeing what sticks :D
20:47:19 <gotmax[m]> salimma: Exactly
20:48:02 <salimma> I think it's orthogonal (maybe open a different issue for that) but I like it
20:48:12 <salimma> it will reduce the issues thrown up by #199 anyway
20:48:19 <gotmax[m]> Or just look up all of the packages that the user is main admin on
20:48:30 <gotmax[m]> the script could do that
20:48:34 <salimma> but apart from requesting access, another problem with #199 is that means nobody is looking at these bugs
20:48:34 <tdawson> Not to discount this discussion, but the original issue was about setting bugzilla users.
20:48:54 <salimma> ^
20:49:00 <tdawson> *laughs* And somehow it got back to it while I was typing. :)
20:49:44 * gotmax[m] is very good at veering off topic. Sorry
20:50:06 <tdawson> Not a problem.
20:50:43 <tdawson> Does anyone have a script that will be able to check for those things in the ticket?
20:51:32 <tdawson> (Orphaned in EPEL, not Fedora; A person without ACL is set as bugzilla contact; and others)
20:51:48 <davide> I know there's an API to pull the BZ contact from pagure, I've used it before
20:52:10 <davide> the orphaned part I suppose we could check whether it's assigned to orphan?
20:52:31 <tdawson> I've got a way to pull all the people with ACL's on a package.
20:52:39 <davide> I know there's an API to add to the ACL but not sure if the querying side of it is exposed
20:52:42 <davide> oh great
20:53:33 <tdawson> wget https://src.fedoraproject.org/extras/pagure_bz.json
20:53:39 <tdawson> Short script. :)
20:54:18 <tdawson> Our time is getting close to an end ... how about we put some of these different idea's and script in the issue.
20:54:58 <gotmax[m]> I already put some initial data in the ticket
20:55:34 <tdawson> gotmax[m]: True, but it would be nice if you put the script that you used to generate that in there as well.
20:56:12 <tdawson> #topic General Issues / Open Floor
20:56:22 <gotmax[m]> It was mostly some messy Jupyter Notebook stuff, but I could probably make it an actual script
20:56:40 <tdawson> gotmax[m]: Ah ... ok.  That does get messy.
20:56:57 <salimma> gotmax (He/Him): speaking of which, have you tried ipython on EL9? :D
20:56:59 <tdawson> Is there anything else that people want to bring up before we close?
20:57:06 <carlwgeorge> small note, i backported some cve fixes to dropbear in epel7 and epel8.  if anyone is familiar with dropbear do please test and give karma.
20:57:30 <davide> I've made good progress with asterisk, all needed BRs are now taken care of except corosync
20:57:44 <davide> and the maintainer is working on that one in https://bugzilla.redhat.com/show_bug.cgi?id=2121777
20:58:06 <tdawson> Cool ... to both.
20:58:13 <gotmax[m]> The c8s python39 issue seems to have been fixed, FWIW
20:58:15 <salimma> the public-inbox for epel9 I mentioned before, and also, if anyone is using rlwrap, I just fixed an upstream issue and will push out a bugfix
20:58:39 <salimma> Davide Cavalca: how is your experience requesting two branches in the same issue? I sometimes got the maintainer confused that way
20:58:49 <tdawson> And Cool to both of those as well. :)
20:58:50 <salimma> (or if they are non-leaf and they have dependencies)
20:58:50 <davide> it's been working ok so far
20:59:04 <salimma> oh, openssl3 had a bunch of CVEs so I've rebased it to the c9s release
20:59:18 <salimma> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3bebee4625
20:59:37 <salimma> ^ please upvote (and if anyone is using it and want to help keep it updated they'd be very welcome)
21:00:02 <salimma> it's super low maintenance, apart from resolving the changelog clashes I had to make a tiny change to a new scriptlet that parses the spec itself
21:00:09 <salimma> crazy scriptlet
21:00:16 <dherrera> oh, forgot to mention on the modular topic, but I noticed that there was no mention on updating the epel documentation (there is some modular stuff there)
21:00:22 <tdawson> Thanks for keeping on top of that salimma
21:00:26 <dherrera> I can work on a PR for that
21:00:45 <tdawson> dherrera: Thanks for noticing that.
21:00:49 <gotmax[m]> That would be great
21:01:15 <tdawson> Thank you everyone for the good discussions.  And that you for your work on EPEL.  You all are great.
21:01:21 <tdawson> Talk to you next week, if not sooner.
21:01:23 <carlwgeorge> yeah announcing with a docs pr we can link to and update in the testing repos would be ideal
21:01:32 <davide> thanks tdawson
21:01:35 <gotmax[m]> You are great too :)
21:01:36 <tdawson> #endmeeting