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