20:00:09 <tdawson> #startmeeting EPEL (2022-06-01)
20:00:09 <zodbot> Meeting started Wed Jun  1 20:00:09 2022 UTC.
20:00:09 <zodbot> This meeting is logged and archived in a public location.
20:00:09 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:09 <zodbot> The meeting name has been set to 'epel_(2022-06-01)'
20:00:09 <tdawson> #meetingname epel
20:00:09 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca
20:00:09 <tdawson> #topic aloha
20:00:09 <zodbot> The meeting name has been set to 'epel'
20:00:09 <zodbot> Current chairs: carlwgeorge dcavalca nirik pgreco salimma tdawson
20:00:14 <rsc> .hello robert
20:00:15 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:00:28 <nirik> good morning everyone. How are you all this fine day?
20:00:31 <carlwgeorge> .hi
20:00:32 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:00:43 <pgreco> .hi
20:00:43 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:00:44 <tdawson> Hi rsc
20:00:53 <rcallicotte> .hi
20:00:54 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:00:55 <tdawson> Hi nirik.  I'm doing wonderful
20:01:00 <tdawson> Hi carlwgeorge
20:01:04 <tdawson> Hi pgreco
20:01:24 <tdawson> Hi rcallicotte
20:01:33 <smooge> hello all
20:01:36 <dherrera> .hi
20:01:38 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:01:53 <tdawson> Hi dherrera
20:01:58 <tdawson> Hi smooge
20:03:17 <nirik> glad to hear it.
20:03:58 <salimma> .hi
20:03:59 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:04:06 <tdawson> Hi salimma
20:05:11 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:11 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:40 <tdawson> There are actually two issues marked formeeting this week.  I'll start with what I think will be the quickest.
20:05:51 <tdawson> .epel 175
20:05:52 <zodbot> tdawson: Issue #175: [main] Doc issue in file modules/ROOT/pages/epel-help.adoc - epel - Pagure.io - https://pagure.io/epel/issue/175
20:06:27 <tdawson> Summary:  There is currently a "Marketing" section in our help section.  Are people ok if I get rid of that for now?
20:06:48 <nirik> I think it would be absoluetely wonderfull if we had some folks working on marketing. :) However, I don't think we currently do...
20:07:11 <tdawson> I totally agree, with both of those points.
20:07:56 <nirik> so yeah, drop for now... do we have any kind of general 'help wanted' page?
20:08:13 <tdawson> Yes.  Which is what this section was on.
20:08:28 <nirik> https://docs.fedoraproject.org/en-US/epel/#how_can_i_contribute I guess.. yeah
20:08:30 <tdawson> https://docs.fedoraproject.org/en-US/epel/epel-help/
20:08:57 <carlwgeorge> was there ever a page on the wiki or was it a broken link there too?
20:09:18 <tdawson> There might have been.
20:09:57 <carlwgeorge> https://fedoraproject.org/wiki/Archive:EPEL_Marketing
20:10:18 <tdawson> Yep ... so it looks like it was archived a while ago, but the other section was never removed.
20:11:30 <tdawson> I could just fix the pages link if people want ... although at this point, that means get rid of the link.
20:11:57 <tdawson> And we can hope that someone will come help with marketing.
20:12:23 <salimma> maybe do a PR and flag it to... Sumantro does marketing, right?
20:13:14 <JosephGayoso[m]> Hello from the fledgling marketing effort! I think it makes sense to remove this note in your documentation especially since it seems like something with marketing is just starting out, but would it be helpful to spin up a separate discussion so the marketing team can learn how to better support you guys?
20:13:30 <nirik> fedora doesn't really have any active marketing group that I know of either.
20:13:38 <nirik> ah ha. ;) welcome JosephGayoso[m]
20:13:52 <rcallicotte> Hello
20:14:25 <JosephGayoso[m]> Hi, sorry I just poked my head and saw marketing was mentioned, haha.
20:14:55 <tdawson> JosephGayoso[m]: That is fine.  And I'd be glad to start a conversation with ya'll.   Would you be the person to contact?
20:16:11 <JosephGayoso[m]> Me or x3mboy I guess. I'll make a ticket on our end as well to follow up with you. :)
20:16:24 <tdawson> Very cool.  Thank you.
20:16:27 <tdawson> https://docs.fedoraproject.org/en-US/marketing/
20:16:38 <tdawson> Just so people know where to look.
20:17:57 <tdawson> Well that discussion took a turn I didn't expect.  But I think that's great.
20:18:11 <tdawson> JosephGayoso[m]: We'll get ahold of you both after this meeting.
20:19:22 <tdawson> I'll write this up on the issue, and we can move on.
20:19:45 <gotmax[m]> tdawson: Joseph Gayoso thumbs upped you on Matrix. I don't think it passes to IRC...
20:19:50 <gotmax[m]> Also hi everyone :)
20:19:55 <tdawson> Ah ... ok.
20:19:59 <tdawson> Hi gotmax
20:20:31 <tdawson> The next issue I flagged sounds strange as a subject ...
20:20:47 <tdawson> .epel 39
20:20:49 <zodbot> tdawson: Issue #39: End of lifing CEPH in EL7 and process improvement - epel - Pagure.io - https://pagure.io/epel/issue/39
20:21:30 <tdawson> Summary: We need a "How to retire a package from EPEL" page
20:22:20 <gotmax[m]> We have https://docs.fedoraproject.org/en-US/epel/epel-policy/#policy_for_orphan_and_retired_packages
20:22:24 <nirik> note... the fedora docs have epel info in them
20:22:31 <gotmax[m]> but it could be more specific
20:22:32 <nirik> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/
20:22:51 <nirik> if we want to move those to our docs we should put a pointer there.
20:23:11 <carlwgeorge> if only modularity wasn't awful, this seems like it would be a good fit for it
20:23:11 <tdawson> I know we talked about this last week, and I was thinking of creating an issue for it, but then I noticed that this really old issue would do.
20:23:40 <tdawson> Well, there is also an old issue that asks about how to retire old modules.
20:23:41 <nirik> carlwgeorge: hum?
20:23:50 <gotmax[m]> carlwgeorge: Also, I think that waa about el7
20:24:01 <gotmax[m]> * carlwgeorge: Also, I think that iasue was about el7
20:24:02 <tdawson> .epel 50
20:24:03 <zodbot> tdawson: Issue #50: [RFE] An EoL Policy for EPEL8 modules - epel - Pagure.io - https://pagure.io/epel/issue/50
20:24:28 <carlwgeorge> nirik: "Without the ability to provide packages for multiple release trains theres no sane way to allow the end user to stay on a specific release train until they are ready to upgrade"
20:24:31 <nirik> to my understanding you just need to set the eol date and they stop being composed.
20:24:33 <carlwgeorge> from the issue
20:24:51 <nirik> oh right, you mean the reason they wanted to retire...
20:25:01 <gotmax[m]> * carlwgeorge: Also, I think that issue was about el7
20:25:02 <carlwgeorge> also no modularity in epel7, but even if this was for epel8 i wouldn't be able to recommend modules
20:25:08 * salimma has a to-do for drafting changes to the retirement process that he didn't get to
20:25:41 <nirik> note that you can do forward/backward compat packages.... :)
20:26:26 <tdawson> salimma: Yep, I was going to bring that up right after I brought up the issue, but then we've already started our running. :)
20:27:00 <tdawson> Maybe just expand the section we have above, with epel specific stuff.
20:27:49 <salimma> ack
20:28:01 <gotmax[m]> tdawson: You mean the section in the epel docs or the main Fedora one?
20:28:06 <salimma> sorting out a house move so it's a bit hectic right now
20:28:20 <nirik> I think the fedora doc covers things pretty well...
20:29:23 <tdawson> It covers the concept of orphaning and retiring, but you can't orphan EPEL packages like you do Fedora packages.
20:29:48 <tdawson> Fedora has a nice button, and then everything flows along.  But you can't do that for EPEL.
20:29:48 <gotmax[m]> Weren't we adding a requirement to announce it first?
20:30:29 <nirik> right, because no one is running those things... perhaps we should?
20:31:39 <tdawson> Yep, I think for retiring we were adding an "announcement" phase.
20:32:32 <tdawson> But for orphaning ... you can't give an epel package to orphan, unless it is an epel-only package.
20:33:02 <gotmax[m]> Correct
20:33:37 <nirik> but you can set an override for it tho... perhaps that is the same intention?
20:33:55 <nirik> (ie, epel bugs get assigned/reassigned to orphan)
20:34:27 <gotmax[m]> Wouldn't the primary maintainer still get CC'd?
20:35:03 <salimma> they'll be cc:ed but not assigned, right?
20:35:11 <salimma> which is probably better
20:35:16 <gotmax[m]> I think so
20:35:24 <tdawson> Huh ... reading through the Fedora documentation for retiring a package, I'm surprised there isn't a single thing about notifying people that you are removing the package.
20:35:46 <tdawson> As long as you do it in Rawhide, you can remove it.
20:35:54 <gotmax[m]> Well you can only remove it in Rawhide or branched
20:36:12 <gotmax[m]> So people would likely notice when updating
20:36:37 <tdawson> Yep.
20:37:11 <tdawson> It's just that orphaning has so much noise, that I thought something that bypasses orphaning would have some type of noise.
20:37:12 <smooge> I think it is more that packages regularly leave EPEL but rarely leave Fedora ever.. instead you get someone with 4500 other packages to keep it in for one more release
20:37:18 <gotmax[m]> And as far as I know there's no epel fedora-obsolete-packages (or whatever it's called) equivalent
20:38:07 <tdawson> For epel9 I ran into two packages still in epel that were orphaned in Fedora.
20:38:44 <gotmax[m]> Yeah, I've noticed that for epel7
20:38:51 <salimma> tdawson: recent orphans I guess?
20:38:52 <nirik> There's stuff being retired all the time... for various valid reasons... upstream dead+security issue, dependent package gone, renamed something else
20:39:24 <tdawson> salimma: Ya.  And they were orphaned because the packager got a different job so had no reason to maintain them.
20:39:45 <nirik> the fedora-obsoletes-packages package depends on some crazy dnf mojo... I doubt it would work on 7 or 8... possibly on 9
20:40:29 <tdawson> anyway ... salimma Are you still up for taking a first stab at this?  And that could just be adding a line about notifying epel
20:41:56 <tdawson> salimma: If you can get an email and/or pull request made, that would be great.
20:42:11 <gotmax[m]> nirik: You're talking about this?
20:42:11 <gotmax[m]> ```
20:42:11 <gotmax[m]> # This package won't be installed, but will obsolete other packages
20:42:11 <gotmax[m]> Provides: libsolv-self-destruct-pkg()
20:42:11 <gotmax[m]> ```
20:42:43 <salimma> tdawson: I'm still up for that, yes
20:42:49 <salimma> sorry for the delay!
20:42:54 <tdawson> salimma: awesome.  Thank you.
20:43:08 <nirik> yes
20:43:19 <tdawson> I'm going to move on so we can get to the rest of the stuff we usually cover.
20:43:28 <gotmax[m]> tdawson: +1
20:43:37 <tdawson> #topic EPEL-7
20:43:37 <tdawson> CentOS 7 will go EOL on 2024-06-30
20:43:37 <nirik> gotmax[m]: it makes it so it doesn't need to be installed or in the transaction even, just in the repo.
20:43:49 <tdawson> Did we have any epel7 stuff this week?
20:44:42 <gotmax[m]> Quick update:
20:44:43 <gotmax[m]> I got in touch with the containerd maintainer. I'm planning to retire it in EPEL 7.
20:45:23 <gotmax[m]> Is there a certain time I should wait after announcing it before retiring?
20:45:26 <tdawson> gotmax That is good.  I'm glad the maintainer finally replied.
20:46:08 <carlwgeorge> we probably have a standard warning period for that, but i don't have strong opinions about the duration
20:46:35 <tdawson> gotmax That's usually up to you.  If it's urgent, soon.  But if not, at least a week.
20:46:54 <tdawson> If it's going to affect alot of things, longer.
20:47:15 <gotmax[m]> It has 5 CVEs and no dependents AFAIK
20:47:27 <gotmax[m]> So I'll do the shorter end most likely
20:47:33 <tdawson> sounds good.
20:47:38 <tdawson> I'm going to move on, for times sake.
20:47:43 <tdawson> #topic EPEL-8
20:47:43 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:48:02 <tdawson> I know we had some gobbisplitter issues this week.
20:48:15 <tdawson> Anyone want to report on how that is?
20:48:19 <smooge> Outstanding issue with packages not being seen for various modules should be fixed
20:48:20 <gotmax[m]> I believe smooge fixed them completely.
20:48:40 <tdawson> Yay!!!
20:48:50 <tdawson> smooge++
20:48:52 <carlwgeorge> nice
20:48:56 <smooge> It was due to the fact that grobisplitter was copying in a lot of copies of the same RPM in different modules but the timestamp on each module was different
20:48:57 <nirik> thanks smooge !
20:49:03 <gotmax[m]> Also, I pushed ansible to epel8{,next}.
20:49:19 <tdawson> gotmax Ya!!  Thank you for that.
20:49:20 <gotmax[m]> * pushed ansible 5 to epel8{,next}.
20:49:20 <smooge> We tried moving to a newer grobisplitter which is in the modularity toolkit but it broke other things
20:49:25 <nirik> I also untagged ansible-packaging from epel8-next... because it was breaking the buildroot.
20:49:48 <smooge> So I moved back to the one which was in ansible from 2020.
20:49:59 <gotmax[m]> nirik: Hmm
20:50:12 <gotmax[m]> What happened?
20:50:22 <smooge> currently what happens is that grobisplitter runs on all modules, and then a find . -type f -print | xargs touch -r timestamp_file is rn
20:50:36 <gotmax[m]> Was there an old version in there that didn't have ansible-srpm-macros?
20:51:08 <nirik> gotmax[m]: epel8-next had ansible-packaging-1-3.el8.next, but was inheriting the new epel-srpm-macros from epel8... which needs the split out ansible-srpm-macros thats in a newer ansible-packager. Untagging the next one let it inherit the newer one from epel8 and all is well again.
20:51:11 <nirik> yes
20:51:17 <smooge> eof on grobisplitter issue
20:51:40 <tdawson> smooge: Thank you very much for tracking that down and working on it.
20:51:42 <nirik> smooge: is there advantage to moving to the new grobisplitter? or just for being in sync with upstream?
20:51:45 <gotmax[m]> nirik: Thanks for fixing that
20:52:10 <gotmax[m]> I thought it would be fine, because the new epel8 package had a higher nevr.
20:52:21 <gotmax[m]> So I didn't rebuild in next
20:52:48 <smooge> the new version is in the modules sig github so supposedly maintained by them. However its code needs work and I did not have time to fix it
20:53:22 <tdawson> Due to time, moving on ... but thank you smooge, gotmax, and nirik
20:53:27 <tdawson> #topic EPEL-9
20:53:27 <tdawson> #topic General Issues / Open Floor
20:53:29 <smooge> nirik, at the moment I would say that it is mainly a matter of 'who is going to maintain this code going forward in the case that with modules in 9.1 it is needed for EPEL then'
20:53:40 <carlwgeorge> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/45
20:53:49 <carlwgeorge> i'm ready to merge this if no one has objections
20:53:52 <nirik> gotmax[m]: it won't inherit if there's any package in that tag. it will use that one.
20:54:00 <smooge> and I was able to segue into EPEL-9 by accident
20:54:01 <tdawson> Wow ... epel9 went by fast. :)
20:54:33 <nirik> carlwgeorge: looks fine to me.
20:54:35 <tdawson> carlwgeorge: Looks Good.  +1
20:54:39 <gotmax[m]> nirik: So whats the proper way to handle it? Ask someone to untag it first.
20:54:44 <gotmax[m]> * So whats the proper way to handle it? Ask someone to untag it first?
20:54:55 <smooge> numbers for EPEL-9 usage will be updated tomorrow in the countme statistics.. we have not gotten far enough after RHEL9 launch to get any growth
20:54:58 <gotmax[m]> * So what's the proper way to handle it? Ask someone to untag it first?
20:55:46 <nirik> gotmax[m]: I think with next we set it so it didn't need any special perms...
20:55:49 <tdawson> smooge: Ahh ... I was hoping to hear your epel9 numbers ... I guess I'll have to wait a week.
20:56:24 <gotmax[m]> nirik: Ack
20:56:36 <tdawson> Love it ... three conversations at once.  And all understandable. :)
20:57:09 <gotmax[m]> tdawson: Trying to efficiently use the time :)
20:57:24 <smooge> tdawson, as of 2022-05-16, there were 5923 CS9 boxes using EPEL out of 16804 potential ones. There were 73 AlmaLinux and 654 RHEL9
20:58:30 <smooge> (there are slightly higher counts of less than 1 week alive but it is not clear how many of those are CI workloads yet)
20:58:32 <tdawson> smooge: Oooh ... cool.  And 05-16 was just a couple of days after RHEL 9 GA launch.
20:58:53 <smooge> Ah sorry it is the week of 2022-05-16 -> 2022-05-22
20:59:08 <smooge> tomorrow will be 2022-05-23-> 2022-05-29
20:59:15 <tdawson> Ah, ok.
20:59:21 <tdawson> Still very good.
20:59:48 <tdawson> Looks like our time is up.
21:00:07 <smooge> yep
21:00:08 <tdawson> Thank you all for comming and the good discussions.  And thank you all for your help on EPEL.
21:00:13 <smooge> thanks tdawson
21:00:20 <tdawson> Talk to you next week, if not sooner.
21:00:25 <tdawson> #endmeeting