20:00:16 <tdawson> #startmeeting EPEL (2023-05-24)
20:00:17 <zodbot> Meeting started Wed May 24 20:00:16 2023 UTC.
20:00:17 <zodbot> This meeting is logged and archived in a public location.
20:00:17 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:17 <zodbot> The meeting name has been set to 'epel_(2023-05-24)'
20:00:18 <tdawson> #meetingname epel
20:00:18 <zodbot> The meeting name has been set to 'epel'
20:00:19 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
20:00:19 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
20:00:21 <tdawson> #topic aloha
20:00:34 <jonathanspw> .hi
20:00:35 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
20:00:36 <rsc> .hello robert
20:00:38 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:00:47 <tdawson> Hi jonathanspw
20:00:51 <tdawson> Hello rsc
20:00:52 <jonathanspw> howdy tdawson
20:01:00 <neil> .hi
20:01:00 <nirik> morning.
20:01:00 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:01:03 <neil> heya folks
20:01:04 <dherrera> .hi
20:01:05 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:01:13 <tdawson> Hi neil and dherrera
20:01:17 <tdawson> Morning nirik
20:01:44 <yselkowitz[m]> .hello yselkowitz
20:01:45 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
20:01:54 <tdawson> Hello yselkowitz[m]
20:03:09 <tdawson> I wonder how many people are at the RH Summit, thus not at this meeting.
20:03:48 <tdawson> Looking at how many are already here, probrubly not many, but I do know of a couple.
20:03:53 * neil locks his doors just in case
20:04:42 <rsc> I'm not at the Red Hat Summit, but at another conference which didn't require travelling ;-)
20:05:02 <tdawson> #topic End Of Life (EOL)
20:05:04 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:05:05 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:05:07 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:05:12 <neil> oh yeah, isn't ISC this week, rsc?
20:05:25 <tdawson> rsc: Those are always nice.  But they don't happen to me very often.
20:05:59 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:06:00 <rsc> neil: could be. I'm at RIPE 86, which is fully hybrid.
20:06:01 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:06:10 <neil> oh, right, that :D
20:06:25 <neil> I don't get emails from them anymore since I don't have an LIR lol
20:07:05 <tdawson> There is one issue there marked for a meeting.
20:07:16 <tdawson> .epel 227
20:07:17 <zodbot> tdawson: Issue #227: Modify incompatible upgrades policy to have fast-track for security updates - epel - Pagure.io - https://pagure.io/epel/issue/227
20:09:00 <nirik> I think thats ok... but I'm easy going. ;)
20:09:06 <tdawson> I'm of two minds on this.  On the one hand, I think we should come up with a "short-circut" for critical security updates, like remote root.  But I disagree with his second premise of doing it for high security issues.
20:09:40 <rsc> Why is gathering karma, even for a high security issue, not an option?
20:10:11 <jonathanspw> His proposal for how to bypass normal policy is way too lose IMO.
20:10:16 <jonathanspw> *loose
20:10:54 <jonathanspw> rsc karma isn't really related.  It's not about pushing it into prod repos it's about doing incompatible upgrades.
20:11:04 <tdawson> rsc: That's a good point .. it states that it has to stay a week despite karma.
20:11:35 <nirik> it's about pushing something out to testing quickly
20:11:43 <nirik> at least thats how I read it.
20:11:50 <neil> i read it the same way
20:12:09 <nirik> instead of discussing before submitting anything.
20:12:11 <DrDaveD> It still has to stay two weeks and be approved by the steering committee before going to prod.  The short-circuit is only about getting it into testing
20:12:17 <nirik> karma rules should still apply
20:12:26 * nirik nods
20:12:29 <tdawson> Ooohhh ... ok, I was reading it wrong.  You are correct.  If there is a high security issue, it would be nice to have it in testing so we can see what's happening.
20:12:31 <jonathanspw> Oh I misread.  Now I see the "testing" part.  Line break made me miss it.
20:12:38 <jonathanspw> Yeah seems sane to push to testing like this.
20:13:39 <neil> It makes sense to me. That way the first EPEL steering meeting after the ticket can be a lot more actionable, and save some time
20:13:53 <tdawson> Yep
20:14:08 <neil> instead of just a yes/no, it can be discussion of the technical/security details
20:14:10 <tdawson> And if people who are affected want to apply it, they can, just by enabling -testing.
20:14:30 <nirik> yep
20:14:39 <rsc> If the update contains breaking changes...it won't make the user anyway happy out of the box, no?
20:14:44 <nirik> also gives more data about if it works/breaks anything
20:14:59 <neil> if it breaks, the user should add negative karma ;)
20:15:19 <rsc> s/breaking/incompatible/
20:15:38 <tdawson> What neil said ... as well as give feedback what breaks.
20:16:13 <rsc> Yes, but the person looks for a shortcut for "incompatible upgrades".
20:16:58 <rsc> Thus I lack to see the benefit of any shortcut, because "incompatible upgrade" usually needs attention by admin. This attention could be also --enablerepo=epel-testing.
20:17:24 <tdawson> rsc: The shortcut referenced here is for getting something into -testing for a high/critical update.  Not for short-cutting the whole discussion.
20:18:12 <rsc> tdawson: thanks, I lost the detail in the last sentence.
20:18:55 <rsc> But how does Fedora handle this? I mean EPEL is "just" add-on packages for EL.
20:18:56 <tdawson> I think this needs a pull request that has a re-write.  Is everyone ok waiting a week while I write one up, and then we can discuss it next week?
20:19:15 <tdawson> rsc: That'
20:19:42 <tdawson> Sorry, hit enter.   That's a good question.  carl usually knows all the details of Fedora's package policies, but he's not here this week.
20:20:04 <neil> more of a reason to wait a week, probably. makes sense to review a proposed change, I think
20:21:00 <rsc> Yes, makes sense to me. Personally, I'm also not aware of an "emergency push" or similar at Fedora.
20:21:05 <tdawson> Ya.  It's usually easier to pull apart and re-arange a pull request than start fresh without one.  Plus ... this isn't a rush.  It can wait a week.
20:21:48 <tdawson> I don't think Fedora has as stringent an update policy as EPEL does.
20:21:49 <nirik> yeah, fedora updates also have to get karma, etc.
20:22:02 <DrDaveD> rawhide gets immediate approval
20:22:31 <tdawson> Well ya, rawhide does, but what about the stable ones?
20:22:55 <jonathanspw> rawhide is by definition a development branch
20:23:15 <nirik> yes, there's a policy:
20:23:30 <nirik> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
20:23:57 <nirik> and an exception process for stable releases (which almost no one uses)
20:24:47 <DrDaveD> Yes they get karma and all that.  But it's difficult to find an incompatible updates policy for Fedora.  Does someone see it?  Google only leads to the EPEL policy.
20:25:58 <DrDaveD> The above says that it should not cause "breakage" but does not say what to do if it has to
20:25:59 <nirik> yes, see above?
20:26:00 <davide> searching for fedora updates policy returns that link as the first result for me
20:26:04 <davide> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
20:26:41 <tdawson> Hi DrDaveD and davide ... sorry I was slow with the Hi.
20:27:00 <davide> all good, I'm multitasking right now so I was late too :)
20:27:42 <DrDaveD> Oh, it says "When a proposed update contains an ABI or API change: notify a week in advance both the devel list and maintainers directly (using the packagename-maintainers@fedoraproject.org alias) whose packages depend on yours to rebuild or offer to do these rebuilds for them."
20:27:52 <tdawson> Anyway, I'll get a pull request written this week, and we can disect it next week ... even possibly approve it if everyone likes it.
20:28:09 <nirik> thats for rawhide yes
20:28:59 <tdawson> Anything else before we move on?
20:29:22 <nirik> stable releases is further down
20:29:23 <nirik> "avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. "
20:30:15 <tdawson> Yep, although there is also a rather large list of pre-approved exceptions, such as the Kernel and KDE.
20:30:54 <tdawson> #topic Old Business
20:32:10 <tdawson> I don't have any Old Business other than a reminder to think about epel10 pointing users are the right repos - https://discussion.fedoraproject.org/t/epel-10-bikeshedding-pointing-users-at-the-right-repo/80551
20:32:27 <tdawson> Other than that, does anyone have any old business?
20:33:23 <tdawson> #topic General Issues / Open Floor
20:33:41 <tdawson> Does anyone have any issues for Open Floor.
20:34:36 <michel> .hello salimma
20:34:37 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:34:48 <tdawson> Hello michel
20:35:36 <tdawson> I guess one think I have is to remind people to look at packages that don't install after the RHEL updates.  And if any of them are yours, give them some love.
20:36:03 <tdawson> https://tdawson.fedorapeople.org/epel/willit/epel9/status-wont-install.html
20:36:04 <michel> does the week notification for rawhide work in practice? I've seen too many updates without /any/ notification
20:36:12 <tdawson> https://tdawson.fedorapeople.org/epel/willit/epel8/status-wont-install.html
20:37:12 <tdawson> And I do realize that a few of those are my packages that I'm worknig on ... which is why I thought I'd bring it up.
20:37:33 <michel> oh, fun, python-hypothesis is on that list. I'll take a look
20:37:59 <michel> and will try and clean up the Rust ones too
20:38:10 <nirik> I see people notifying all the time... but yes, there's times they just push something, but usually it will get untagged and they will get yelled at.
20:38:33 <michel> question for tdawson -- how much work would it be to get either FTI bugs filed like Fedora, or an email sent out?
20:40:11 * nirik really wonders if we couldn't just extend the fedora one to do epel too, but I didn't write it, so I don't know off hand
20:40:15 <tdawson> michel: That's a good question.  I don't think it would take too much now that we have dates on them.
20:40:53 <tdawson> nirik: I tried that first, and it really didn't fit
20:41:20 <tdawson> Plus, I think my original pull requsts is still sitting there after a year with no comments on it.
20:41:24 <nirik> huh, ok. :(
20:41:34 <tdawson> possibly two years ... it's been a while.
20:41:42 <nirik> what was it against? sounds like no one is watching. ;(
20:42:17 <tdawson> I'd have to dig it up ... I honestly don't remember.
20:42:29 <nirik> yeah, no worries, just curious.
20:42:34 * nirik hopes it wasn't him. :)
20:43:39 <gotmax23> what was exactly the issue with the Fedora one? doesn't it just use the libsolv python bindings to resolve the repo's packages?
20:44:49 <tdawson> I believe it was something to do with no access to the core packages at the time.
20:44:55 <gotmax23> Looks like the PR is https://pagure.io/releng/pull-request/10104?
20:45:21 <nirik> ha, so it was me. ;)
20:45:30 <nirik> oh, closed
20:46:49 <tdawson> Oh ... and I closed it because half the packages that weren't installing were RHEL packages. :)
20:47:16 <nirik> so yeah, the fedora one runs on a releng machine and could see it... but of course it would be hard to develop outside that.
20:47:20 <nirik> if you want to try again I could get you access to some machine to develop from?
20:47:39 <gotmax23> The repository metadata is public
20:47:47 <tdawson> That's a good idea ... and I'm betting we could filter out the RHEL packages.
20:47:50 <gotmax23> Does the script actually need to download packages?
20:48:24 <nirik> yeah, it shouldn't. it just uses the solver/repodata
20:48:31 <gotmax23> right
20:49:03 <nirik> The buildroot is public, but not the rhel repodata right?
20:49:29 <gotmax23> I think all of the repodata is public
20:49:35 <michel> the RHEL package not accessible issue is a pain point when trying to use side tags in local mock builds too
20:49:46 <gotmax23> yeah, it really is...
20:49:57 <michel> though I guess I could get around it by configuring the side tags and Alma repos?
20:49:57 <gotmax23> it seems that's an intractable problem :(
20:50:38 <neil> michel: that's what I do, personally (albeit with rocky0
20:50:54 <neil> it's not perfect, but "close enough"
20:51:01 <nirik> yeah, I don't think the rhel repodata is public... but I could be missing something.
20:51:32 <tdawson> Sorry for the pause, I was reading through the code ...
20:52:03 <gotmax23> $ fedrq pkgs -r @koji:epel9-build git -F line:nevra,repoid,vendor
20:52:03 <gotmax23> git-2.39.3-1.el9_2.x86_64 : https:__kojipkgs.fedoraproject.org_repos_epel9-build_latest__basearch : Red Hat, Inc.
20:52:03 <gotmax23> It is
20:52:05 <tdawson> I'll see if I can find some time to look at both, but I don't think it will be this week.
20:52:08 <gotmax23> But if you try to download that package, you get a 403
20:52:34 <nirik> thats the buildroot
20:52:45 <nirik> so, no multilib, and mashed together right?
20:52:54 <gotmax23> Right
20:53:21 <nirik> I mean, the rhel packages and their metadata are there, but it's not 100% the same.
20:53:33 <michel> not entirely intractable forever - once we are in EL10 territory, we'll basically build for Stream by default right :)
20:53:40 <nirik> anyhow, thats a sidetrack.
20:54:04 <gotmax23> Yeah, we can probably move on
20:54:46 <tdawson> Well, we're on Open Floor ... does anyone have anything else EPEL related?
20:56:13 <tdawson> Looks like we'll end a bit early.
20:56:35 <tdawson> Thank you all for the good discussions, and for all your work and efforts for EPEL and it's community.
20:56:47 <tdawson> I'll talk to you all next week, if not sooner.
20:57:06 <tdawson> #endmeeting