19:59:58 <tdawson> #startmeeting EPEL (2023-06-07)
19:59:58 <zodbot> Meeting started Wed Jun  7 19:59:58 2023 UTC.
19:59:58 <zodbot> This meeting is logged and archived in a public location.
19:59:58 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:59:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:59:58 <zodbot> The meeting name has been set to 'epel_(2023-06-07)'
20:00:00 <tdawson> #meetingname epel
20:00:00 <zodbot> The meeting name has been set to 'epel'
20:00:01 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
20:00:01 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
20:00:03 <tdawson> #topic aloha
20:00:07 <smooge> hello
20:00:07 <carlwgeorge> .hi
20:00:08 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:00:21 <dherrera> .hi
20:00:22 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:00:27 <smooge> .hi
20:00:28 <zodbot> smooge: smooge 'Stephen Smoogen' <smooge@redhat.com>
20:00:50 <tdawson> Hello smooge
20:00:55 <tdawson> Hi carlwgeorge and dherrera
20:02:45 <nirik> morning
20:02:50 <tdawson> Morning nirik
20:04:21 <tdawson> Hmm ... a little light today ... is the matric / irc bridge working?
20:04:54 <dherrera> at the very least i'm on matrix rn
20:05:02 <nirik> ¯\_(ツ)_/¯ who can say
20:05:05 <dherrera> seems fine
20:05:13 <tdawson> #topic End Of Life (EOL)
20:05:15 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:05:16 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:05:18 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:05:36 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:37 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:42 <smooge> for all matrix users please read the front page of 'https://libera.chat/' as the bridge is limited usage
20:05:44 <jonathanspw> .hi
20:05:45 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
20:06:00 <michel-slm> .hello salimma
20:06:01 <zodbot> michel-slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:06:24 <michel-slm> Sporadic, need to pick up our kid from daycare soon
20:06:36 <tdawson> Hello michel-slm
20:06:43 <rsc> .hello robert
20:06:44 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:06:47 <davide> I'm around but still at lunch
20:07:07 <tdawson> So, we have several items for the meeting this week ... I'm going to try to do the ones I think are short first.
20:07:20 <tdawson> .epel 230
20:07:21 <zodbot> tdawson: Issue #230: old epel7/8 updates in testing - epel - Pagure.io - https://pagure.io/epel/issue/230
20:07:54 <tdawson> dherrera: You've made good progress on this ... anything you wanted to say and/or ask ?
20:08:18 <dherrera> I've been going through this slowly, I first queried the APIs and found that there are many updates that are related to obsolete projects
20:08:35 <carlwgeorge> obsolete as in dead upstream?
20:08:38 <dherrera> there are also some that are related to retired projects that are not orphaned
20:08:42 <nirik> I think unpushing/revoking all the orphaned ones makes sense. we shouldn't push orphaned packages out to stable.
20:08:46 <dherrera> *obsolete -> orphaned
20:08:51 * carlwgeorge nods
20:09:03 <carlwgeorge> i agree with nirik
20:09:15 <tdawson> I do too
20:10:54 <dherrera> the list of orphaned ones are on the ticket, the rest i'm going through them 1 by 1, i've seen that some correspond to incompatible upgrades, so i'm sugesting to follow the process instead of waiting for kudos as the policy establishes, but since they have been stalled in there for years, IDK if we will get any answer
20:11:24 <Eighth_Doctor> .hello ngompa
20:11:25 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:11:43 <tdawson> Hello Eighth_Doctor
20:11:52 <nirik> if everyone is ok unpushing all those listed ones, I can do that at some point...
20:12:43 <carlwgeorge> dewit.gif
20:13:01 <tdawson> if listed = "orphaned packages that dherrera listed in the ticket" then yep, sounds good to me.
20:13:01 <dherrera> 👍️
20:13:08 <carlwgeorge> dherrera++
20:13:13 <carlwgeorge> thanks for working on this
20:13:22 <smooge> dherrera thanks
20:13:22 <tdawson> dherrera++
20:13:22 <zodbot> tdawson: Karma for dherrera changed to 3 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:13:26 <nirik> yeah, thanks much!
20:13:27 <smooge> dherrera++
20:13:27 <zodbot> smooge: Karma for dherrera changed to 4 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:13:30 <Eighth_Doctor> dherrera++
20:13:46 <rcallicotte> .hi
20:13:47 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:13:54 <tdawson> Anything else before we move to the next issue?
20:13:59 <dherrera> question, should I list the retired packages ones that are not orphaned?
20:14:00 <tdawson> Hi rcallicotte and rsc
20:14:56 <dherrera> I've found a couple of those, but if they are more I might just filter them out
20:15:38 <tdawson> Ya ... if the package is retired, getting those unpushed would be good too.
20:15:55 <nirik> +1
20:17:04 <dherrera> ok, just an example of one so we are on the same page https://src.fedoraproject.org/rpms/cherokee
20:17:17 <dherrera> thats all from me on this topic for today
20:18:05 <tdawson> Thank you very much
20:18:24 <tdawson> I think the next one that hopefully will be short is
20:18:33 <tdawson> .epel 233
20:18:34 <zodbot> tdawson: Issue #233: Drop reference to modules in recommendation re multiple versions - epel - Pagure.io - https://pagure.io/epel/issue/233
20:19:11 <tdawson> In short, our SCL page says to use modules.
20:19:30 <nirik> so basically remove the mention of modules there?
20:19:37 <carlwgeorge> i agree with your comment there, the right answer it following fedora's multiple guidelines
20:20:29 <tdawson> I was hopeing that someone could/would do a first draft of a re-write of the page.
20:20:32 <smooge> i for one would like to see us go back to SCL's
20:20:38 <nirik> yeah, but we might also mention the -epel path?
20:20:39 * smooge will see himself out
20:21:12 <carlwgeorge> smooge: scl only looks "good" compared to modularity
20:21:31 <tdawson> I have to say, I do like the gcc-toolset way of using SCL's.  It works fairly well.
20:22:06 <tdawson> But, I also feel the way I have in the ticket, we should follow what Fedora is doing.
20:22:13 <neil> .hello
20:22:13 <zodbot> neil: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
20:22:19 <neil> .hi
20:22:20 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:22:34 <tdawson> If someone wants to get SCL's moving again, then work with Fedora, and we can follow their lead.
20:22:34 <neil> apologies for tardiness, busy week
20:22:36 <smooge> i am just saying two methods walked into the Thunderdome, and one of them is still standing
20:22:39 <tdawson> Hi neil
20:22:47 <tdawson> *laughs*
20:23:11 <carlwgeorge> barely standing, i believe gcc-toolset is the only one still going
20:23:30 <nirik> but scl's arent really standing. ;)
20:23:34 <nirik> yeah, that.
20:23:50 <nirik> I think the new/current way is just compat packages (which of course has it's own issues)
20:24:03 <tdawson> Yep, and if you look at gcc-toolset, you'll notice they don't even use scl ... it's just scl-ish
20:24:16 <carlwgeorge> this is a great precursor to what i think is the next topic
20:24:43 <tdawson> Anyway, does anyone want to do the first draft of a page re-write?
20:25:00 <tdawson> I'll do it if nobody else wants to, just want to give others a chance.
20:25:25 <carlwgeorge> if it's not pressing, i can incorporate it into the big docs overhaul.  if we want to clarify the existing stuff sooner, someone else should probably jump on it
20:26:03 <tdawson> I'd prefer it get done before the big doc overhaul ... and I'm not against doing it.
20:26:08 <tdawson> I'll take it then.
20:26:12 <carlwgeorge> that'll work
20:26:30 <tdawson> OK, moving onto something that might take longer ...
20:26:53 <tdawson> .epel 227
20:26:54 <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:27:18 <carlwgeorge> welp i guessed wrong
20:27:32 <tdawson> For the most part, most people have liked my draft
20:27:46 <tdawson> https://pagure.io/epel/pull-request/231
20:27:54 <tdawson> #link https://pagure.io/epel/pull-request/231
20:28:19 <nirik> one thing that occurred to me... what about critical non security updates? :)
20:28:27 <tdawson> I do like carls re-wording, and I'm going to implement that.
20:28:40 <tdawson> nirik: Can you give an example?
20:28:44 <nirik> ie, say a program has a bug that causes data loss. It's not a security issue (really)...
20:29:33 <Eighth_Doctor> well severity isn't linked to type of update in bodhi
20:29:45 <Eighth_Doctor> so I guess a high severity bugfix update is possible
20:29:45 <nirik> but then it comes down to a judgement call...
20:29:55 <nirik> right.
20:30:07 <carlwgeorge> fwiw we can always grant exceptions past this policy, this is just the baseline really
20:30:16 <tdawson> Yep
20:30:27 <nirik> yeah. agreed. I just thought I would bring that up since it occured to me.
20:31:05 <carlwgeorge> like i would feel comfortable in nirik's data loss example to tell the maintainer to go ahead and build without waiting for a week of discussion or waiting for a meeting
20:32:02 <nirik> sure, or we could even vote on exceptions out of meeting if it was time critical.
20:32:04 <tdawson> carlwgeorge's second comment is asking if things should just be for critical issues only, and not high severity.
20:32:14 <tdawson> Correct
20:32:21 <carlwgeorge> troy asked me to show up with the definition of high
20:32:47 <carlwgeorge> red hat's rating system doesn't actually have high, it has low/moderate/important/critical
20:32:49 <carlwgeorge> https://access.redhat.com/security/updates/classification/
20:33:11 <carlwgeorge> nvd has high and it's based on a number scale (the cvss rating)
20:33:12 <nirik> and as we have seen sometimes it takes a little while to rate.
20:33:15 <carlwgeorge> https://nvd.nist.gov/vuln-metrics/cvss
20:33:49 <carlwgeorge> red hat will also issue a cvss rating, that is usually similar but not necessarily identical to the nvd one
20:33:54 <rcallicotte> so under Redhat... Important = High... ish
20:34:09 <carlwgeorge> that's my take, yes
20:34:19 <carlwgeorge> red hat's cvss rating and it's overall rating are not directly linked, but of course the former influences the later
20:34:26 * nirik thniks this is getting overcomplex. ;)
20:34:56 <carlwgeorge> example, here is a thunderbird update that scored 8.8 under both nvd cvss and rh cvss.  but rh rated it as critical.  https://access.redhat.com/security/cve/CVE-2022-1802
20:35:09 <carlwgeorge> under nvd it was only high
20:35:45 <carlwgeorge> my suggestion for the policy is that if either red hat or nvd rate the vulnerability as critical, the maintainer can do the bypass.  but not important/high.
20:36:52 <nirik> seems fine to me. I really don't expect this would be used all that often...
20:37:20 <DrDaveD> What about the idea of getting permission from one steering committee member.
20:38:12 <carlwgeorge> if we word it as critical only from rh or nvd, then permission wouldn't be needed for those
20:38:44 <carlwgeorge> and if it's not critical, then it can wait till the next meeting and doesn't need single committee member permission either
20:38:54 <tdawson> carlwgeorge: Correct ... but I was wondering about putting something in that covers niriks idea.
20:39:46 <tdawson> I also don't like the idea of "single committee members permission"
20:40:25 <Eighth_Doctor> I think if we just document the case then it should be fine
20:40:27 <Eighth_Doctor> we don't need to make this hard
20:40:27 <Eighth_Doctor> this is all about permissionless cases
20:40:37 <Eighth_Doctor> if we find someone abusing this, then we can deal with it then
20:40:51 <Eighth_Doctor> but I'd rather just simplify people's lives ehre
20:40:51 <Eighth_Doctor> *here
20:42:43 <carlwgeorge> tdawson: compromise, we make the progress we can here on just the bypass for critical security stuff.  leave the data loss scenario for a separate proposal.
20:42:57 <carlwgeorge> (once someone can find a good way to put it into words)
20:43:13 <tdawson> carlwgeorge: I'm good with that.
20:44:07 <tdawson> I'll make the changes to this pull request with what everyones agree to.   And I'll probrubly do a second pull request with what I have in my head.
20:44:53 <tdawson> Anything else before we move on?
20:45:39 <tdawson> OK, moving on
20:45:45 <tdawson> .epel 228
20:45:48 <zodbot> tdawson: Issue #228: Recommended way to follow new upstream releases in EPEL - epel - Pagure.io - https://pagure.io/epel/issue/228
20:45:58 <carlwgeorge> i can speak to this one
20:46:47 <carlwgeorge> there is another bz besides the linked review, but sadly it's private because it started as a rhel bug and has mentions of customers in it so we can't make it public
20:48:03 <carlwgeorge> the gpsd software bumps library soname regularly.  it's not clear if this is actually due to breaking changes or not, as the upstream commits have no additional details past "bumping soname".
20:49:03 <carlwgeorge> epel9 has 3.23, but the maintainer wants to ship 3.25.  he wanted to ship it as gpsd-latest, and myself and others discouraged that because the guidelines discourage it.
20:49:28 <nirik> perhaps copr is a better fit here?
20:49:32 <Eighth_Doctor> ugh, why are those guidelines still there?
20:49:42 <tdawson> In what way is it discouraged?
20:49:45 <carlwgeorge> it's been suggested to ship gpsd3.25 (the fedora multiple naming pattern), or ship gpsd3.23 as a compat package and then update gpsd to 3.25
20:49:50 <Eighth_Doctor> the -latest/-stable guidelines were written before we made versioned packaging guidelines
20:50:00 <carlwgeorge> https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
20:50:01 <Eighth_Doctor> can we maybe ask FPC to drop them?
20:50:12 <carlwgeorge> "Please also note that strings such as "-latest" can often become misleading over time if the package (in all active Fedora releases) is not kept updated with the latest upstream version."
20:50:32 <carlwgeorge> nirik: that has also been recommended to the maintainer
20:50:51 <Eighth_Doctor> we have only one active -latest package now: https://koji.fedoraproject.org/koji/packageinfo?packageID=30333
20:51:14 <carlwgeorge> the maintainer doesn't want to do gpsd3.23/gpsd3.25 because he explicitly wants to break abi again and again
20:51:15 <Eighth_Doctor> this package genuinely makes no sense to me, since xe-guest-utilities is retired
20:51:26 <davide> I personally prefer having versioned packages for the older version
20:51:32 <davide> and keep the unversioned one tracking the latest
20:51:34 <carlwgeorge> davide: same
20:52:04 <Eighth_Doctor> likewise
20:52:07 <carlwgeorge> the maintainer's suggestion was to just exclude devel files so he could break abi.  i said that's not normal and advised asking fpc if it's allowed.
20:52:07 <dherrera> Yeas
20:52:21 <davide> why is this shipped in EPEL in the first place? meaning, do other packages actually consume the library, or is it just its own binary?
20:52:24 <carlwgeorge> instead he filed a fesco issue, which was closed in favor of an epsco issue
20:52:32 <Eighth_Doctor> Davide Cavalca: KDE Plasma depends on it
20:52:43 <carlwgeorge> hehe, it's a c library, a python library, a daemon, and multiple client tools
20:52:54 <davide> lovely
20:53:16 <carlwgeorge> the maintainer only cares about the client tools, which need the python library, which need the c library.  so it's all interconnected.
20:53:18 <davide> excluding devel files doesn't seem acceptable, and doesn't actually solve the issue as you're still breaking ABI
20:53:24 <carlwgeorge> exactly
20:53:52 <carlwgeorge> i predict this will be the fpc answer as well, once the issue gets filed there.  i'm hoping that our guidance can be "ask fpc".
20:53:59 <tdawson> carlwgeorge: So I feel that saying doing -latest is "discouraged" ... but the example is for someone who isn't keeping it up to date.  But what if they do keep it up to date.
20:54:07 <tdawson> I personal think doing -latest is a good thing.
20:54:19 <Eighth_Doctor> tdawson: what would be the point vs an unversioned package name?
20:54:44 <nirik> I suppose to more indicate that the package was updating rapidly?
20:54:47 <tdawson> Oh, I'd like an unversioned package name, but we specifically say we can't do that.
20:55:02 <carlwgeorge> i do not think that a package named "-latest" should just be blanket allowed to make breaking changes
20:55:17 <tdawson> carlwgeorge: That is exactly what -latest should be allowed to do.
20:55:30 <nirik> gpsd-frequenty-incompatible
20:55:41 <tdawson> That is why you would use -latest ... so people know not to use it if they don't want breaking changes.
20:55:58 <carlwgeorge> or to be more specific, i do not think packages should be allowed to ignore updates policies just based on special naming
20:56:15 <nirik> but 'latest' doesn't really convey that... at least to me.
20:56:17 <dherrera> Ir that's the case, why not use cope instead?
20:56:28 <dherrera> *copr
20:56:29 <Eighth_Doctor> I don't really think it's necessary either
20:56:33 <carlwgeorge> so far, the maintainer has not commented on the advice to use copr instead
20:56:42 <Eighth_Doctor> because again... those guidelines predate our versioned packaging guidelines
20:56:50 <carlwgeorge> i think what we found is someone who actually wishes we kept epel-playground
20:57:04 <carlwgeorge> and our guidance shutting that down was "use copr instead"
20:57:05 <Eighth_Doctor> 🤦
20:57:18 * nirik nods
20:58:50 <carlwgeorge> like i mentioned, i'm perfectly happy punting this to fpc and following the guidance from them
20:59:17 <tdawson> Yep, but it sounds like they passed it back to us when they opened a ticket about it.
20:59:22 <carlwgeorge> no, that was fesco
20:59:36 <tdawson> Ah, ok.
21:00:03 <nirik> we could ask explicitly in the ticket about copr?
21:00:05 <tdawson> Oh ... in that case, yes, I misunderstood.
21:00:09 <carlwgeorge> full disclosure, i'm also on fpc, but it's not like i can just make a unilateral call there
21:00:20 <carlwgeorge> nirik: i have, multiple times, in that private bz
21:00:26 <nirik> or... if this is needed for kde, does it need to be in epel for that?
21:00:29 <carlwgeorge> but yes, in this ticket too
21:00:33 <nirik> ah, bummer.
21:00:39 <carlwgeorge> *we should in this ticket too
21:00:57 <carlwgeorge> it's not for kde, it's for telco usage
21:01:24 <tdawson> nirik: Although there is a package in kde that relies on gpsd, the updating it request has nothing to do with KDE.
21:01:53 <tdawson> Thus it doesn't fall under the KDE exemption umbrella
21:02:27 <nirik> ok.
21:02:34 <carlwgeorge> i had an idea for a compromise that maybe we could break up the main package, so we could ship mutiple versioned library packages, and keep the client tools (what the maintainer actually wants) on the latest version (which ideally wouldn't have incompatible changes at the cli level)
21:02:41 <carlwgeorge> but i'm not sure if it's possible
21:03:04 <carlwgeorge> will need more research
21:03:11 <tdawson> carlwgeorge: To be honest, that's what I thought they were going to do / we doing ... until I looked at their spec file.
21:03:12 <Eighth_Doctor> well, if you mutate the sources to link the library statically to itself, then don't ship the bindings or anything else, it's doable
21:03:28 <Eighth_Doctor> I did something similar for python-hawkey for EPEL 7 many years ago :)
21:03:41 <carlwgeorge> Eighth_Doctor: the cli tools are python and import the python lib, how would you make those static?
21:03:45 <tdawson> Oh shoot, I just saw the time.
21:03:57 <Eighth_Doctor> carlwgeorge: oh crap, I thought it was in C :(
21:04:08 <carlwgeorge> well it's c too lol
21:04:09 <tdawson> I looks like I'm the only one that likes that -latest idea ... and I'm fine with that.  I just thought I'd share my view on it.
21:04:18 <carlwgeorge> ack
21:04:19 <Eighth_Doctor> ugh, I would have to think about it... it is possible though
21:04:45 <carlwgeorge> anyone opposed to an answer of "ask fpc" and then going from there?
21:04:57 <Eighth_Doctor> not me
21:05:02 <dherrera> go for it
21:05:06 <tdawson> carlwgeorge: I'm good with that.  Also also add something about using copr.
21:05:22 <carlwgeorge> yeah, repeated in public :)
21:05:38 <carlwgeorge> should i mention epel-playground?
21:05:43 <tdawson> carlwgeorge: no
21:05:53 * carlwgeorge nods
21:06:10 <tdawson> Thank you all for comming this week, and for the good discussions.
21:06:27 <tdawson> We'll talk to ya'll next week, if not sooner.
21:06:45 <tdawson> #endmeeting