20:00:52 <tdawson> #startmeeting EPEL (2023-09-27)
20:00:52 <zodbot> Meeting started Wed Sep 27 20:00:52 2023 UTC.
20:00:52 <zodbot> This meeting is logged and archived in a public location.
20:00:52 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:52 <zodbot> The meeting name has been set to 'epel_(2023-09-27)'
20:00:53 <tdawson> #meetingname epel
20:00:53 <zodbot> The meeting name has been set to 'epel'
20:00:55 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
20:00:55 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
20:00:56 <tdawson> #topic aloha
20:01:00 <smooge> hello
20:01:02 <yselkowitz> .hi
20:01:03 <neil> .hi
20:01:04 <dcavalca> .hi
20:01:04 <zodbot> yselkowitz: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
20:01:06 <michel-slm> .hello salimma
20:01:06 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:01:07 <rsc> .hello robert
20:01:07 <carlwgeorge> .hi
20:01:09 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <davide@cavalca.name>
20:01:12 <zodbot> michel-slm: salimma 'Michel Lind' <michel@michel-slm.name>
20:01:15 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:01:18 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:01:21 <nirik> morning
20:02:26 <rcallicotte> .hi
20:02:27 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:05:07 <tdawson> Hello smooge and rsc
20:05:15 <tdawson> Hi carlwgeorge and rcallicotte
20:05:19 <tdawson> Morning nirik
20:05:29 * rcallicotte waves hello
20:05:44 <tdawson> Hi neil, yselkowitz and dcavalca
20:06:16 <tdawson> hello michel-slm
20:06:21 <tdawson> #chair michel-slm
20:06:21 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 michel-slm nirik pgreco salimma smooge tdawson
20:06:36 <smooge> time to get this party started
20:06:48 <tdawson> #topic End Of Life (EOL)
20:06:50 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:06:51 <tdawson> https://endoflife.date/rhel
20:06:53 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:06:54 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:06:56 <tdawson> https://endoflife.date/centos-stream
20:07:04 <tdawson> Yep ... I'm a bit slow today.
20:07:14 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:07:15 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:08:20 <tdawson> Let's start with the older issue
20:08:24 <tdawson> .epel 247
20:08:24 <zodbot> tdawson: Issue #247: Revisting conflicts policy for EPEL compat packages - epel - Pagure.io - https://pagure.io/epel/issue/247
20:09:09 <carlwgeorge> in case anyone missed it, i opened a discourse thread for it
20:09:40 <tdawson> https://discussion.fedoraproject.org/t/revisting-conflicts-policy-for-epel-compat-packages/90605
20:09:56 <carlwgeorge> so far it seems the feedback is supportive as long as we limit the scope to compat devel packages
20:10:07 <carlwgeorge> which is of course the express intent
20:10:26 <dcavalca> yeah that seems reasonable
20:10:31 <tdawson> I think the only negative is nirik, in stating that we will need to reword some portions of the EPEL documentation.
20:10:41 <tdawson> Wich, also is reasonable.
20:11:02 <tdawson> /Wich/Which/
20:11:55 <nirik> I didn't think I was all that negative. ;)
20:11:57 <smooge> Witch?
20:12:12 <neil> spooky rpm season
20:12:17 <carlwgeorge> it's not halloween month yet
20:12:40 * neil hands carlwgeorge a PSL
20:12:48 <tdawson> nirik: Correct ... it wasn't negative ... it was ... constructive?  something we need to remember.
20:12:48 <rcallicotte> lol
20:12:49 <nirik> merry christmas!
20:13:20 <carlwgeorge> the other day my kid was viscerally offended that walmart had christmas stuff out on display already
20:14:00 <neil> lol
20:14:02 <michel-slm> before Halloween!
20:14:04 <rcallicotte> oh yeah I saw christmas trees at costco
20:14:21 <Son_Goku> .hello ngompa
20:14:22 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:14:27 <tdawson> Hello Son_Goku
20:14:47 <carlwgeorge> right now the overall guidelines don't mention conflicts, it's later down in the policy page https://docs.fedoraproject.org/en-US/epel/epel-policy/#policy_for_conflicting_packages
20:15:49 <carlwgeorge> we might want to convert the "conflicts in compat packages" section into another bullet point under "policy for conflicting packages" just to make it harder to miss
20:16:05 * nirik notes at least in the past implicit conflicts were worse than explicit ones.
20:16:11 <carlwgeorge> and of course change the wording about allowing it only for compat devel packages
20:16:43 <tdawson> Ya ... I think we might also need to clarify what a "conflict" is ... as  co-maintainer, I evidently had a different interpretation than the maintainer of a package.
20:16:43 <carlwgeorge> i believe implicit conflicts are covered under the general fedora packaging guidelines, which we follow unless noted otherwise
20:17:12 <carlwgeorge> implicit conflict = files that conflict, explicit conflict = `Conflicts:` in the spec file
20:17:29 <carlwgeorge> yup, found it https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_implicit_conflicts
20:17:37 <tdawson> Sorry ... but being a native english speaker, I'm not sure I know what is "implicit" and "excli. ..... Ha!  ... you answered my question before I could type it.
20:17:49 * nirik nods.
20:18:06 <carlwgeorge> we can of course be very specific in the actual guideline phrasing
20:18:15 <neil> what about illicit packages?
20:18:23 <Son_Goku> the difference between a failed and blocked transaction
20:18:25 <nirik> implicit also at least used to mean that all your packages would be downloaded and it would only barf when doing the test transaction.
20:18:33 <Son_Goku> still does
20:18:38 <rcallicotte> those are also covered in the fedora guidelines
20:18:40 <nirik> yeah, which is pretty horrible
20:18:45 <nirik> yep.
20:19:24 * Son_Goku remembers when we didn't do test transactions
20:20:01 <carlwgeorge> so i guess the question is do we want to leave this open for discussion longer, or move forward with drafting the guideline changes for a vote?
20:20:58 <tdawson> Can we do two levels of voting?  One for the general concept ... and then for the wording / pull request ?
20:21:26 * neil likes the idea, from what he's read
20:21:31 <carlwgeorge> sure
20:22:35 <smooge> I think we are ready to move forward with drafting myself
20:22:36 <tdawson> Cuz, like neil, I like the idea ... but I'd also like a bit clearer wording in the whole conflict area.
20:23:05 <smooge> words hard.
20:23:09 <tdawson> Yep
20:23:49 <nirik> word
20:23:52 <carlwgeorge> is anyone opposed to the idea as a whole?
20:25:01 <tdawson> I think the silense says nobody is opposed.  Shall we do a formal vote then?
20:25:59 <tdawson> Everyone who is in favor of allowing Conflicts on compat -devel packages as stated in carlwgeorge's proposal.  Give a +1
20:26:13 <tdawson> +1
20:26:16 <rcallicotte> +1
20:26:41 <nirik> +1
20:26:46 <dcavalca> +1
20:26:55 <smooge> oh who can vote these days
20:27:29 <michel-slm> +1
20:27:29 <smooge> emeritus vote +1
20:27:32 <tdawson> smooge: Only committee members can officially vote, but I'll put the community votes on the info
20:28:15 <Son_Goku> +1
20:28:39 <Son_Goku> (I assume we've worked out RH support wouldn't freak out over it)
20:29:21 <smooge> tdawson: understood. I will run at the next election (this was everyone's first warning)
20:29:46 <tdawson> #info allowing Conflicts on compat -devel packages as stated in carlwgeorge's proposal passed  Committe: 7 For, 0 against,  Community: 2 For, 0 against.
20:29:59 <michel-slm> unanimity!
20:30:34 <carlwgeorge> i'll draft up the revised wording and hopefully have it ready for the final vote next week
20:30:49 <tdawson> carlwgeorge: Thank you
20:31:19 <tdawson> Moving onto the next issue
20:31:36 <tdawson> .epel 249
20:31:37 <zodbot> tdawson: Issue #249: EPEL packager unwilling to follow policy - epel - Pagure.io - https://pagure.io/epel/issue/249
20:32:41 <tdawson> Although I do disagree with carlwgeorge on this on the details, it is an interesting subject.
20:32:55 <dcavalca> do we have an equivalent to fedora-obsoletes for epel?
20:33:28 <dcavalca> meaning, a way to ensure that a retired package actually goes away from the installed systems, rather than just sitting around forever stuck?
20:33:34 <nirik> we don't...
20:33:48 <michel-slm> that's a good idea
20:33:52 <michel-slm> esp since retirement is buggy at times
20:34:07 <carlwgeorge> is that a subpackage of something in fedora?  i can't seem to find it.
20:34:14 <dcavalca> (this is the "solving the actual problem" part of this; the policy question still stands of course)
20:34:33 <nirik> on the one hand, it's nice to make sure no one is still using unsupported/possibly insecure things. On the other hand, removing things people may choose to want to use is not great.
20:34:51 <nirik> the way fedora uses it doesn't map fully to epel.
20:34:58 <dcavalca> carlwgeorge: http://src.fedoraproject.org/rpms/fedora-obsolete-packages
20:35:01 <yselkowitz> is gcc-toolset-N usable in epel7?
20:35:17 <smooge> yselkowitz: for the ones they released for epel7
20:35:28 <dcavalca> yselkowitz: I've used it before on el8, it should work for el7 too if it's actually available
20:35:35 <carlwgeorge> ah, i was search for obsoletes (plural)
20:35:39 <carlwgeorge> *searching
20:35:39 <dcavalca> from memory, el7 also had the devtoolset stuff?
20:35:50 <dcavalca> I definitely remember using that internally to get packages built before
20:35:50 <smooge> yselkowitz: dcavalca it has some
20:36:18 <smooge> they stopped building it for el7 and focused on el8
20:36:38 <Son_Goku> fedora-obsolete-packages was inspired by mageia's task-obsolete
20:36:41 <smooge> so if the compiler needed is newer than .. (need to login to batcave to see and I can't from here)
20:36:46 <Son_Goku> and honestly, I think we should have one in EPEL too
20:36:51 <carlwgeorge> obsoleting the package may be overkill.  personally i'd be happy with the empty package just going away.  that can even be accomplished by removing the %files section instead of retiring the whole thing.
20:37:03 <neil> my note: looking at that individuals' bodhi profile makes me tend to agree with carlwgeorge, but I also lean towards tdawson's approach w.r.t. handling
20:37:20 <Son_Goku> neil: unfortunately... yes, I noticed that too
20:37:34 <carlwgeorge> holy crap
20:37:43 <neil> lol i thought you _knew_ carlwgeorge
20:37:49 <Son_Goku> that's why I put that message in the ticket carlwgeorge
20:38:00 <smooge> so the reason we have not done an obsolete package in the past is for what nirik and others have said. A lot of users want to keep a specific version of something even if it is dead/bad/etc.
20:38:03 <carlwgeorge> i guess i've been lucky in my lack of previous interactions
20:38:52 <tdawson> Just so people know, this is marked as a 9.8 critical by NIST ... - https://nvd.nist.gov/vuln/detail/CVE-2022-4170
20:39:07 <nirik> The fedora package is mostly for dist upgrades I thought... which, we don't do?
20:39:27 <neil> as an urxvt user, I support abandoning this particular one, whatever it means
20:39:31 <carlwgeorge> i totally agree that something should have been done.  but keeping the package and stripping all the files out clearly isn't it.
20:39:42 <neil> carlwgeorge++
20:39:42 <zodbot> neil: Karma for carlwgeorge changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
20:39:56 <carlwgeorge> that's not "fixing the cve" by any stretch of the imagination
20:40:01 <dcavalca> smooge: that makes sense, but I suppose we'd only use this for the nuclear option (i.e. packages with massive security issues that can't otherwise be fixed and prove to be a liability)
20:40:02 <michel-slm> oh, it's *this* packager
20:40:07 <Son_Goku> yup
20:40:13 <dcavalca> that bodhi feed is... something
20:40:33 <Son_Goku> I am kind of tempted to refer this to FESCo
20:41:09 <carlwgeorge> i've left bodhi comments on updates like this before to attempt to gently remind packagers that we have an updates policy and an incompat process.  this is the first time a maintainer has pushed back on that.
20:41:15 * smooge decides to not look at whatever automobile accident level bodhi feed everyone is looking at
20:41:24 <Son_Goku> smooge: you're better off for it
20:41:37 <Son_Goku> (it's the packager's bodhi comments feed)
20:41:38 <michel-slm> smooge: it's as bad as if a Tesla on autopilot collide with a Waymo
20:41:40 <rcallicotte> you dont know what you're missing smooge
20:41:53 <michel-slm> there's a feed for Bodhi comments? whoa
20:41:56 <smooge> and I don't want to know
20:42:06 <neil> another thing I will note is that the individual is supposedly Ex-RH, so, that probably has _something_ to do with the overall response, if I had to guess (and I do)--though I don't presume to know the reason of their split with RH.
20:42:06 <carlwgeorge> tdawson: i'm curious what you meant by "disagree" earlier
20:42:28 <neil> basing purely on context, honestly.
20:42:49 <tdawson> carlwgeorge: Well, you said that everyone would agree to remove the package, I happen to agree with the empty package like he did.
20:43:33 <tdawson> I think removing the package would leave people with a severely remote explitable service running on their machine.
20:43:42 <carlwgeorge> i did not say everyone would agree to remove the package.  i said:  "I suspect we would have recommended retiring the package outright rather than shipping an empty package"
20:43:50 <michel-slm> an empty package seems reasonable if it comes with say a README
20:44:00 <Son_Goku> or even a %post message
20:44:11 <tdawson> True
20:44:17 <Son_Goku> (though those are... not great for a lot of reasons, it's better than nothing)
20:44:43 <dcavalca> so, the end state we want here is for this thing not to be on end user systems
20:44:43 <Son_Goku> but this is one of those cases where an epel-obsolete-packages package would be useful
20:44:44 <rcallicotte> automation scripts will blow right past those %post messages
20:45:01 <tdawson> Son_Goku: I agree there.
20:45:01 <dcavalca> looks like we have limited options here: either an empty package, or the obsoletes approach
20:45:25 <carlwgeorge> or removing the %files section to not ship an empty package
20:45:33 <nirik> the empty package is easier to work around if you had to...
20:45:34 <michel-slm> but yeah... hmm, the way this packager does it... existing users still won't get upgraded right
20:45:39 <Son_Goku> yup
20:45:51 <michel-slm> the terminfo-only package does not obsolete the removed subpackages
20:46:13 <carlwgeorge> i'll note that the finer points of how to do this upgrade path are exactly the things that should have happened with an incompat upgrade request
20:46:17 <michel-slm> so this is not any better than retiring in any way. in fact the terminfo only package won't ever upgrade anyone who already has rxvt-unicode installed
20:46:26 <michel-slm> carlwgeorge: oh agreed
20:46:28 <Son_Goku> carlwgeorge: yes, I agree
20:46:33 * nirik nods
20:46:35 <Son_Goku> also this is epel7, which makes things more complicated because yum :/
20:46:58 <rcallicotte> s/yum/yuck/
20:47:01 * neil nods
20:47:04 <neil> about all things
20:48:09 <carlwgeorge> it's painful to make a fuss about this, but if we don't enforce policies then there is no point in having them
20:48:13 <Son_Goku> right
20:48:18 <dcavalca> agreed
20:48:22 <Son_Goku> and this actually exposes a hole in our processes anyway
20:48:37 <Son_Goku> we never thought about having to rip a package out because of the vulnerabilities
20:48:48 <michel-slm> I guess it's a good thing it's happening on a relatively minor package
20:48:56 * nirik notes that yum / epel7 wouldn't work with the fedora-obsoletes-packages setup FWIW
20:48:57 <michel-slm> so we can sort out how to address this without too much controversy
20:49:09 <Son_Goku> nirik: it kind of can, but not quite as nicely, yeah
20:49:26 <nirik> I'm not sure I see how. It depends on libsolv.
20:49:31 <neil> Son_Goku: or, if something is so critical and cannot be fixed in a determinate amount of time, so the drastic action is to just pretend it's dead
20:49:33 <Son_Goku> task-obsolete worked fine with yum/urpmi, it's just bonkers because the dep resolve algorithm is slower and stupider
20:49:42 <smooge> Son_Goku: I don't think that is correct. We have had this come up with EL6 packages in the past. It was sort of left to the packager to deal with
20:50:26 <Son_Goku> there are other quirks, yes, but it's not like it hasn't been done before... it's just annoying because yum handles obsoletes in a weird way
20:50:30 <nirik> it comes down to philosophy... should we remove things to 'help' our users when we think thats best, or should we not and let them figure their own thing out
20:50:35 <smooge> because too many people have custom needs which forcing removal or some other 'fix' broke working systems (like payroll)
20:50:58 <dcavalca> I agree with the general sentiment, but in this specific case removing the package seems pretty clear cut to me
20:51:06 <michel-slm> if we have such an obsolete package I think it should be optional
20:51:19 <nirik> I bet you 1 american dollar that someone out there has seen this update and pinned their package to the previous version because they "need" this package and can't have it removed. ;)
20:51:21 <Son_Goku> it's one of those things where we need case-by-case evaluation to add to epel-obsolete-packages
20:51:23 <michel-slm> e.g. "hey this is best practice but if it does not work for you, remove this but caveat emptor"
20:51:43 <nirik> michel-slm: the way the fedora one works it's never installed, it just exists in the repo and obsoletes things.
20:51:48 <michel-slm> I remember having to bump and rebuild some packages to have higher NEVRAs precisely because we need them (long story) on some Fedora systems so I can sympathize
20:51:55 <Son_Goku> it's a self-destructing package :)
20:51:58 <michel-slm> nirik: oh true
20:52:00 <carlwgeorge> does anyone actually want to take a stab at restoring the files by building with a devtoolset?  i would guess it's possible, but i'm not familiar with the software and don't use it.
20:52:03 <Son_Goku> it's a handy libsolv feature
20:52:05 <dcavalca> yeah, as I said before, this should be the nuclear option
20:52:07 <michel-slm> yeah ... that's why I had to do that workaround
20:52:12 <nirik> kaboom()
20:52:19 <michel-slm> ok, so... how about for EPEL we provide a normal package
20:52:30 <michel-slm> so.. it's completely optional but recommended
20:52:38 <Son_Goku> well, all the feature does is make it so it doesn't get installed
20:52:38 <smooge> yum doesn't handle that
20:52:45 <Son_Goku> and yes, that
20:52:56 <smooge> we are talking about EL7 here
20:52:58 <Son_Goku> there's mcfancy in libsolv :)
20:53:07 <carlwgeorge> would it be less trouble to just have epel-release obsolete rxvt-unicode?
20:53:09 <michel-slm> can't we make this package obsolete the packages... wait, EL7's RPM does not do normal obsoletes?
20:53:12 <nirik> recommended? like Recommends ? or you mean our docs say you should install if it you want?
20:53:12 <neil> so, we'll add dnf to el7. no problem. /s
20:53:19 <Son_Goku> michel-slm: not rpm, yum doesn't
20:53:20 <michel-slm> if we make epel-release obsolete it, it's not optional then, right?
20:53:24 <Son_Goku> neil: dnf is already there :P
20:53:35 <neil> Son_Goku: i know , but we can go further!
20:53:37 <tdawson> carlwgeorge: I was looking at that ... building with the devtoolset ... but I'm not finding it on RHEL 7 ...
20:53:39 <Son_Goku> michel-slm: you don't want to go through spelunking through yum's solver algorithm
20:53:39 <neil> Obseletes: dnf-4
20:53:47 <michel-slm> what I have in mind is epel-release suggest / recommend (I suggest suggest for EL9 and below and recommend for EL10) epel-obsolete-package
20:53:55 <michel-slm> and epel-obsolete-package obsolete things like rxvt-unicode
20:54:17 <Son_Goku> we also could just fix it with devtoolset, no?
20:54:20 <nirik> that would get pulled in on any update tho right? unless you passed / set that you don't want that
20:54:21 <michel-slm> so... people can still opt out if they really want to, while with the fedora one they have no choice (I guess they can excludepkg= it from the yum repo definition?)
20:54:24 <Son_Goku> that's what carlwgeorge suggested?
20:54:29 <smooge> ok I think we are having two different conversations (3 if we include devtoolset)
20:54:44 <tdawson> :)  Yes.... yes we are.
20:54:44 <smooge> 1. how to make devtool gcc work in EL7
20:54:48 <neil> that's not enough conversations, i think
20:54:56 <smooge> 2. How to fix this in newer releases like EL9 and EL10
20:55:00 <nirik> you can't opt out of the fedora one without disabling the repo its in I don't think.
20:55:02 <smooge> 3. How to fix this in EL7
20:55:04 <neil> we can almost still understand one another
20:55:04 <Son_Goku> well there's the convo of obsoleting yum with dnf on epel7 for the lulz
20:55:25 <Son_Goku> so there's convo 4
20:55:27 <tdawson> smooge: 4. What to do with people who say they aren't going to follow the policies.
20:55:33 <smooge> Son_Goku: no the dnf in el7 was too old if I remember
20:55:38 <neil> you can always count on me to deliver little value and fewer laughs, but.. i try
20:55:45 <Son_Goku> smooge: :(
20:56:09 <carlwgeorge> i see other epel7 spec files that buildrequire devtoolsets, but i don't see them in a yum search in a rhel7 container
20:56:23 <carlwgeorge> does anyone happen to know if those exist in an optional channel that we have enabled in the epel7 buildroot?
20:56:39 <nirik> it's optional
20:56:40 <nirik> yes
20:56:42 <Son_Goku> they are in the SCL channel
20:56:46 <smooge> I think for EL7 we are not able to do much and in fact while I think that 'hack' should have been announced etc, it is what I would probably have done to make sure the package wasn't available for remote exploints
20:56:50 <Son_Goku> they are imported into the koji buildroot
20:56:51 <nirik> which tool does this need?
20:57:10 <Son_Goku> I believe chromium shows how to use it?
20:57:15 <smooge> it needs a specfic version of gcc
20:57:22 <smooge> I don't know which one
20:57:42 <carlwgeorge> nirik: optional like not enabled by default, or the literal rhel-7-server-optional-rpms repo?
20:57:49 <Son_Goku> carlwgeorge: the latter
20:57:58 <Son_Goku> it's in the software collections repo
20:58:07 <carlwgeorge> Warning: No matches found for: devtoolset
20:58:20 <Son_Goku> look for rhscl, I think?
20:58:28 <nirik> rhel 7 devtools
20:59:42 <tdawson> carlwgeorge:  yapet.spec
20:59:51 <Son_Goku> carlwgeorge: "rhel-server-rhscl-7-rpms" repo
20:59:52 <rcallicotte> yeah I think its in sclo
21:00:11 <rcallicotte> rhscl rather
21:00:27 <tdawson> So ... looking at the time... I think it's time to wrap up these 4 to 6 conversations. :)
21:00:40 <carlwgeorge> side note, that should be mentioned in the channels we build epel against here https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy
21:00:40 <neil> for posterity, the changelog message for the urxvt change reads: "Newer versions of libptytty don't build on epel7, and on epel I only care about the terminfo file anyway.  If you wish for this to be packaged fully again, we either need 9.30 + libptytty patched to build, or a fix for". so -- it seems it's not directly even about rxvt-unicode. 🤔
21:00:43 <nirik> ah, so yeah...
21:00:46 <nirik> it's rhscl
21:01:49 <nirik> 9.3.1 is the latest gcc there.
21:01:57 <Son_Goku> that should work
21:02:06 <nirik> oh no, 12.2
21:02:10 <Son_Goku> oh even better
21:02:14 <nirik> devtoolset-12
21:02:17 <Son_Goku> sweet
21:02:26 <neil> i also want to point out that the maintainer of the package is no longer the person responding in bodhi.
21:02:29 <smooge> ah ok that was newer than I thought they had
21:02:29 <neil> so
21:02:36 <neil> maybe we can just ask the new maintainer
21:02:42 <carlwgeorge> it gets into a "is the juice worth the squeeze" debate, but it seems like the tools are there if someone wants to try to tackle it to avoid the more difficult options
21:03:08 <Son_Goku> it also helps with providing alternatives when stuff like this happens
21:03:13 <tdawson> neil: Ya ... I was noticing that .... the person responding stopped maintaining the package right after this update.
21:03:25 <carlwgeorge> i still see them listed as a maintainer
21:03:27 <Son_Goku> they're still listed as co-maintainer
21:03:42 <tdawson> But they haven't done any updates ... they used to do all the updates.
21:03:47 <dcavalca> so, independent of this specific case, we should  IMO clarify our policy for what to do if someone is uncooperative
21:04:05 <carlwgeorge> we should follow fedora imo https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#revoking
21:04:08 <Son_Goku> and this case can be used for us to flesh out information people can use for dealing with stuff like this
21:04:09 <neil> dcavalca++
21:04:09 <zodbot> neil: Karma for dcavalca changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
21:04:15 <neil> Son_Goku++
21:04:15 <zodbot> neil: Karma for ngompa changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
21:04:20 <neil> everyone gets karma
21:04:21 <Son_Goku> eyyy
21:04:27 <tdawson> :)
21:04:52 <dcavalca> carlwgeorge: do we track who sponsored whom somewhere?
21:05:02 <Son_Goku> 😩
21:05:04 <tdawson> OK ... this has been some good discussions ... but it's time to wrap it up.  Ya'll don't have to stop the conversations ... but you can't have them here.
21:05:05 <Son_Goku> we used to
21:05:14 <neil> thanks tdawson!
21:05:18 <dcavalca> oh right we're over time
21:05:22 <carlwgeorge> see yall in #epel
21:05:25 <neil> time flies when you're havin' fun
21:05:29 <carlwgeorge> or we can hop over to matrix
21:05:32 <Son_Goku> :D
21:05:41 * Son_Goku scoots right on over
21:05:42 <tdawson> Thank you all for your discussions, and your passion for making EPEL the best it can be.
21:05:43 <dcavalca> matrix ftw
21:05:57 <tdawson> #endmeeting