20:00:03 <carlwgeorge> #startmeeting EPEL (2023-10-11)
20:00:03 <zodbot> Meeting started Wed Oct 11 20:00:03 2023 UTC.
20:00:03 <zodbot> This meeting is logged and archived in a public location.
20:00:03 <zodbot> The chair is carlwgeorge. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:03 <zodbot> The meeting name has been set to 'epel_(2023-10-11)'
20:00:11 <carlwgeorge> #meetingname epel
20:00:11 <zodbot> The meeting name has been set to 'epel'
20:00:16 <rsc> .hello robert
20:00:17 <carlwgeorge> #chair carlwgeorge nirik pgreco dcavalca ngompa michel-slm
20:00:17 <zodbot> Current chairs: carlwgeorge dcavalca michel-slm ngompa nirik pgreco
20:00:20 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:00:22 <carlwgeorge> #topic howdy
20:00:28 <rcallicotte> .hi
20:00:29 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:00:30 <rsc> Oh, too early.
20:00:31 <rsc> .hello robert
20:00:32 <pgreco> .hi
20:00:32 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:00:35 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:01:07 <nirik> morning
20:01:08 <neil> .hi
20:01:10 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:01:13 <neil> morning nirik
20:01:21 * nirik is sort of here, but also looking at packet loss issues.
20:01:26 <carlwgeorge> howdy everybody
20:01:37 <rcallicotte> yo!!
20:02:05 <michel-slm> .hello salimma
20:02:06 <zodbot> michel-slm: salimma 'Michel Lind' <michel@michel-slm.name>
20:02:20 <michel-slm> oh, Carl's the boss today!
20:02:32 <neil> remember to keep him in line
20:03:14 <smooge> hello
20:04:01 <dherrera> .hi
20:04:02 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:05:19 <carlwgeorge> #topic End Of Life (EOL) dates
20:05:25 <carlwgeorge> #info RHEL 7 and EPEL 7 will go EOL on 2024-06-30
20:05:30 <carlwgeorge> #link https://endoflife.date/rhel
20:05:36 <carlwgeorge> #info CentOS Stream 8 and EPEL 8 Next goes EOL in 2024-05-31
20:05:41 <carlwgeorge> #link https://endoflife.date/centos-stream
20:06:09 <carlwgeorge> #topic EPEL Issues
20:06:14 <carlwgeorge> #link https://pagure.io/epel/issues?tags=meeting&status=Open
20:06:39 <carlwgeorge> the only tagged issue is an old one i re-tagged to bring back up
20:06:46 <carlwgeorge> .epel 203
20:06:47 <zodbot> carlwgeorge: Issue #203: making epel branch creation less painful - epel - Pagure.io - https://pagure.io/epel/issue/203
20:06:53 <Son_Goku> .hello ngompa
20:06:56 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:07:01 <jonathanspw> .hello from the other side
20:07:02 <zodbot> jonathanspw: Sorry, but user 'from the other side' does not exist
20:07:06 <jonathanspw> oh sorry
20:07:07 <jonathanspw> .hi
20:07:08 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
20:07:16 <neil> lol
20:07:31 <smooge> you know it would have been easier if they had put the end date for 7 and 8-stream on the same day
20:07:49 <rcallicotte> where's the fun in that?
20:07:50 <rcallicotte> lol
20:07:54 <carlwgeorge> i brought this one up at the most recent office hours, but for those that missed it, the situation has changed because branch requests process pretty fast now
20:08:33 <carlwgeorge> cpe folks created a toddler to auto-process the scm requests
20:08:51 <neil> a... toddler?
20:09:01 <neil> child labor is illegal, carlwgeorge...
20:09:13 <smooge> not if they are computers
20:09:31 <jonathanspw> the auto branching process has been working great for me.  had an issue the first week or two of it, reported it, that got fixed, and no issues since then in probably 40-50 branchings
20:09:44 <carlwgeorge> one these toddlers https://pagure.io/fedora-infra/toddlers
20:09:54 <carlwgeorge> *one of
20:10:12 <neil> oh nice, TIL
20:10:16 <michel-slm> the name is apt given how many times I've seen them made a mess ;)
20:10:20 <neil> :P
20:11:06 <carlwgeorge> so unless someone objects, i think we should close this issue as wontfix
20:11:35 <neil> +1 from me
20:11:36 <nirik> +1 to close
20:11:40 <carlwgeorge> ideally an objection would come with volunteering to implement the auto-branching.  i just don't think it's worth the effort anymore.
20:12:07 <rcallicotte> +1 to close
20:12:13 <Son_Goku> the main thing we need to worry about now is all the CRB stuff
20:12:33 <Son_Goku> but autobranching (without ELN stuff) is effectively a non-need now
20:12:34 <carlwgeorge> and dependencies with non-responsive maintainers
20:12:46 <jonathanspw> +1
20:14:37 <pgreco> +1
20:14:43 <michel-slm> +1
20:14:48 <carlwgeorge> alright I'll close this after the meeting.  anyone got any other tickets they forgot to tag or otherwise want to bring up?
20:15:02 <smooge> not from me
20:15:51 <smooge> oh i had a side question.. I am starting a package review for something in rawhide which will go with EPEL-9 if accepted etc. OK for me to use SPDX tags in the EPEL branch?
20:16:22 <smooge> wit that is open-floor..
20:16:26 <smooge> wait til then
20:16:27 <carlwgeorge> smooge: yup, you can use spdx tags in any branch
20:16:56 <carlwgeorge> before open floor, lets do old business
20:16:58 <carlwgeorge> #topic Old Business
20:17:47 <carlwgeorge> i sadly didn't make any progress this week on the prs i owe y'all, one for the voting and one for the compat conflicts policy.  will try to change that soon.
20:18:02 <smooge> so how about repotags (there my old business joke of the day)
20:18:20 <carlwgeorge> lol
20:18:27 <carlwgeorge> deep cut
20:19:29 <carlwgeorge> you should try to dig up an old email thread of that argument for those that are unfamiliar
20:19:49 <neil> storytime is my favorite part of EPEL steering
20:21:08 <carlwgeorge> iirc when epel first started there were some folks that adamantly argued to have an additional suffix on the release to identify the packages as coming from epel, similar to what remirepo does
20:21:47 <carlwgeorge> oh we've got an faq for it https://docs.fedoraproject.org/en-US/epel/epel-faq/#why_doesnt_epel_use_repotags
20:22:00 <michel-slm> so... the same way CentOS SIGs do it then, I guess?
20:22:16 <carlwgeorge> basically
20:22:39 <neil> lol
20:22:50 * neil goes and opens a new issue to track this
20:23:00 <carlwgeorge> any other old business before we move on?
20:24:09 <smooge> basically part of the reason was that all the other repo-forges had tags to say which one it was like .dag.el9.i686.rpm and such
20:24:48 <neil> no old business from me
20:24:56 <smooge> so debugging issues was usually down to rpm -qa and 'you crossed the streams'.
20:25:03 <neil> the.. centos streams?
20:25:10 <carlwgeorge> i think the best counter-argument was that it's useless duplication of the vendor tag
20:25:19 <smooge> the part on Fedora part was we were using plague to build things and getting it do that off tag was not happening
20:25:20 * michel-slm nods
20:25:27 <rcallicotte> oh dear. yeah I see that
20:25:46 <michel-slm> for me wearing my Hyperscale hats, it's useful for us because we have several different repos, but if vendor : repo is 1:1 it's duplicated
20:25:57 <carlwgeorge> that's fair
20:26:09 <michel-slm> next, history lesson on why we use .fc in Fedora ;)
20:26:13 <neil> no one told me we get hats!
20:26:17 <michel-slm> just kidding
20:26:21 <michel-slm> neil: but not red ones
20:26:25 * nirik wonders if that thing that listed packages by keys is still around
20:26:38 <michel-slm> ooh what keys?
20:26:39 <smooge> telling someone to do a rpm -qa --qf='%{NAME} %{VENDOR}\n' or some such thing to get a quick list of vendors on irc or email was usually more trouble than it was worth.
20:26:41 <smooge> anyway
20:26:59 <neil> i agree. vendor should be set to a guid
20:27:01 <nirik> the keys the packages are signed by
20:27:03 <carlwgeorge> nirik: keychecker, and yes, i co-maintain it
20:27:03 <smooge> nirik: i may have a copy somewhere on one of my backup drives
20:27:12 <carlwgeorge> i ported it to python3 a while back
20:27:13 <nirik> keychecker, yes thats it
20:27:19 <smooge> oh something more than a bash script
20:28:15 <carlwgeorge> based on our rabbit holing, i'm gonna go ahead with open floor
20:28:19 <carlwgeorge> #topic Open Floor
20:28:25 <michel-slm> nirik: oh that sounds nice
20:28:54 * michel-slm adds keychecker to his Ansible playbook
20:29:01 <nirik> it's much better than looking at a dist tag. ;) Anyone can make a el9 package, not everyone can sign it.
20:29:05 <carlwgeorge> michel-slm: https://github.com/jds2001/keychecker, packaged in fedora and all epel branches as keychecker
20:29:38 <carlwgeorge> nirik: funny you say that, i ran into that problem with ius
20:29:45 * nirik nods
20:30:29 <carlwgeorge> for those that don't know, ius is a 3rd party repo i used to work on for rackspace.  i got tickets a few time for packages that put `.ius` in their release that ius did not build (and had never built).
20:30:39 <neil> for the open floor, i suggest covering it, lest someone fall :)
20:30:48 <michel-slm> yeah -- this helps as a sanity check as well, sometimes I install packages from Bodhi before they get signed - normally in mock - and I can check if any leak
20:31:31 <carlwgeorge> i find it useful to find unsigned packages i installed that were supposed to be temporary, that i then distrosync
20:31:53 <michel-slm> carlwgeorge: nods
20:32:05 <michel-slm> lol I just found some of those :)
20:32:55 <carlwgeorge> smooge: were you squared away on your spdx question, or did you have any follow up questions?
20:33:07 <michel-slm> speaking of spdx I do have a question after smooge is done
20:33:33 * Son_Goku just noticed that the linked epel doc mentions up2date and shuddered
20:33:35 <smooge> squared away.. I am not sure if the string I came up with makes sense for the package but that is for me, the reviewer and God
20:34:09 <smooge> License:        (LGPL-2.0-or-later AND Apache-2.0) AND (LGPL-2.1-or-later AND (GPL-2.0-only OR BSD-2-Clause))
20:34:27 <smooge> Son_Goku: el6 is still used a lot
20:34:34 * carlwgeorge directs Son_Goku to the "edit this page" button ;)
20:34:53 <smooge> i will just put it back until I get rid of my el6 box
20:35:11 * smooge has been banned from editing wikis and docs
20:35:33 <carlwgeorge> i mean you can't reinstall that box with el7 until it's truly stable, i.e. no more updates
20:36:17 <michel-slm> stable == dead
20:36:41 <carlwgeorge> iirc parenthesis around conjunctive (AND) parts are pointless and can be removed
20:38:17 <carlwgeorge> Son_Goku: was it you i was talking about that with, and you found a legal list post about it?
20:38:25 <Son_Goku> yes
20:38:32 <Son_Goku> I think so?
20:38:43 <Son_Goku> I remember answering something about this before
20:39:16 <carlwgeorge> https://docs.fedoraproject.org/en-US/legal/license-field/#_combined_disjunctive_and_conjunctive_license_expressions kinda hints at it, by only saying to use parenthesis with OR
20:39:25 <carlwgeorge> but it doesn't outright say not to use parenthesis with AND
20:39:32 <smooge> my main reason was that only parts of the system are under each of those licesnes
20:40:08 <michel-slm> I mean, if you just hoover up the different license from each file and put them together, I think just parenthesizing is fine as it makes it easier to verify everything is included?
20:40:36 <michel-slm> the only thing I do if I feel like it is to reorder the licenses within each parens e.g. I don't have (Apache-2.0 OR MIT) AND (MIT OR Apache-2.0)
20:40:43 <neil> quick, someone write a grammar for SPDX
20:41:03 <Son_Goku> I use perens because otherwise it's impossible to parse
20:41:23 <Son_Goku> and I've talked to legal folks about it before and it's considered desirable
20:41:28 <nirik> I thought he was only involved in debian? ;)
20:41:29 * nirik runs
20:41:31 <Son_Goku> but all the docs are kind of a mess from the shuffle
20:41:38 <Son_Goku> lol
20:41:42 <neil> parantheses only clarify the logic, IMHO
20:41:43 <michel-slm> nirik: ha
20:41:45 <smooge> I went with what licensecheck and scancode-toolkit said they were to be
20:41:53 <michel-slm> how many way can we misspell parentheses ;)
20:42:13 <neil> a parenthetical amount
20:42:14 <michel-slm> ok, write a grammar for SPDX and call it perentheses
20:42:29 <michel-slm> perentheses-gremmer
20:42:33 <neil> 😂
20:42:35 <neil> michel-slm++
20:42:35 <zodbot> neil: Karma for salimma changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
20:42:39 <michel-slm> woo
20:42:40 <neil> michel-slm++
20:42:41 <neil> take two
20:42:49 <smooge> snew package sname
20:42:52 <michel-slm> that doesn't work, one per grantor per release
20:42:55 <smooge> michel-slm++
20:42:55 <zodbot> smooge: Karma for salimma changed to 2 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
20:42:58 <carlwgeorge> i had one thing for open floor
20:42:59 <michel-slm> anyway speaking of licenses
20:43:08 <carlwgeorge> #link https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/VIP6GZFVNFRC2MZUB6OUEDF2SSW4BBVI/
20:43:08 <michel-slm> oh, carlwgeorge do you want to go first?
20:43:14 <carlwgeorge> sure
20:43:19 <carlwgeorge> mine is quick
20:43:47 <carlwgeorge> if no one  has objects i'm just gonna retire it
20:43:51 <carlwgeorge> *objections
20:43:59 <neil> +1 from me on that
20:44:07 <michel-slm> which package, for the minutes?
20:44:10 <smooge> i object on the general grounds that no one objected
20:44:20 * michel-slm curses that weechat makes it hard to open long links
20:44:28 <smooge> yeah.. same here
20:44:31 <carlwgeorge> #info retire orphaned klee package from epel9
20:44:33 <michel-slm> oh, klee
20:44:45 <michel-slm> yeah, +1
20:44:58 <michel-slm> question though - should we add this scenario to the doc
20:45:22 <carlwgeorge> in theory, if someone wanted to adopt it, they could package a compat llvm14 and keep it going.  but i don't think anyone is volunteering for that.
20:45:47 <smooge> i think if it needs that, please put it out of its misery
20:46:04 <carlwgeorge> i agree michel-slm, but not sure how or where
20:46:29 <carlwgeorge> the retirement page seems solely focused on something staying in fedora but getting an epel branch retired
20:46:33 <michel-slm> same, haven't looked. probably something we can just keep in mind if we ever touch that policy again
20:46:48 <carlwgeorge> this package was orphaned outright, and the fedora branches just aged out
20:47:06 <michel-slm> it seems a part of 'maintainer no longer has time or desire'
20:47:14 <michel-slm> or a separate one altogether
20:47:41 <carlwgeorge> for fedora the policy is that such packages are maintained collectively by the rest of the package maintainers for the remainder of the stable fedora lifecycles that it is in
20:47:45 <michel-slm> yeah, I think "Package is already retired in Fedora and the reason applied to EPEL" would cover it?
20:48:00 <carlwgeorge> obviously that is more feasible for fedora branches than epel branches
20:48:05 <michel-slm> package already retired in Fedora /and aged out/
20:48:31 <michel-slm> I guess that's not enough reason though, if the package actually still works on EL. hmm
20:49:19 <carlwgeorge> it only works on rhel-ish distros that keep old packages, and then it blocks you from upgrading llvm-libs
20:49:21 <michel-slm> maybe we just need an FTI policy matching Fedora
20:49:26 <carlwgeorge> *in this case
20:49:27 <michel-slm> if the package FTIs for long enough we should retire it
20:49:43 <michel-slm> oh... right. in this case because older llvm-libs are kept around, the package is actually installable
20:49:50 <michel-slm> it would be FTBFS though right?
20:50:02 <michel-slm> so an FTBFS policy would cover it.
20:50:05 <carlwgeorge> but not installable at the same time with something else that links against llvm 15
20:50:08 <carlwgeorge> it's messy
20:51:17 <carlwgeorge> for now i'm happy to just retire this one and deal with making a policy if we notice it happening again
20:51:19 <michel-slm> 9 mins to go, and this seems like we should discuss it further later if we want to (or don't have to if it's rare)
20:51:21 <michel-slm> yeah
20:51:28 <michel-slm> ok, license question -- what's up with this? https://bugzilla.redhat.com/show_bug.cgi?id=2031918
20:51:35 <michel-slm> and the related commit https://gitlab.com/redhat/centos-stream/rpms/LibRaw/-/commit/0b99ca1ba4b13bed4f8aea5accff001f3b3654c5
20:52:02 <michel-slm> TL;DR rpminspect (used to) claim CDDL is not an accepted license, so it's removed from CS' LibRaw (but not Fedora's)
20:52:12 <michel-slm> https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ <-- Fedora allows CDDL
20:52:39 <michel-slm> just noticed because we have LibRaw-epel in EPEL to ship missing -devel subpackages
20:53:07 <carlwgeorge> isn't cddl the license zfs uses that is infamous for being gpl-incompatible (at least in many people's opinions)
20:53:35 <nirik> yes
20:54:30 <michel-slm> so... since the license is "BSD and (CDDL or LGPL)" .. some user might want to link this against a CDDL app, and it would have been fine right
20:54:38 <carlwgeorge> i wasn't aware that rhel diverged from fedora on this
20:54:47 <carlwgeorge> this is a lawyer question i think
20:55:09 <michel-slm> yeah, is there a list of approved licenses for use in RHEL/CS? (just wondering, as it might be useful to know)
20:55:28 <Son_Goku> it is supposed to be identical to fedora
20:55:38 <carlwgeorge> i've only ever heard it being the same as fedora
20:55:42 <Son_Goku> that was affirmed to me when I was working on the SPDX changes
20:55:54 <carlwgeorge> i suggest bringing it up on the legal list https://docs.fedoraproject.org/en-US/legal/
20:56:10 <michel-slm> maybe it's a buggy rpminspect from 2021 and then the package was never brought back in sync
20:56:25 <michel-slm> but yeah I'll ask legal, thanks. if the lawyers say it should be ok we should file a Jira issue
20:56:26 <Son_Goku> I suspect it's blocked to prevent people from asking about OpenZFS
20:56:35 <michel-slm> lol
20:57:31 <carlwgeorge> anything else before we wrap up?
20:57:44 <smooge> hit the button frank
20:59:16 <carlwgeorge> thanks y'all for coming, and thanks for everything y'all do for epel
20:59:24 <carlwgeorge> #endmeeting