21:00:22 <tdawson> #startmeeting EPEL (2021-12-08)
21:00:22 <zodbot> Meeting started Wed Dec  8 21:00:22 2021 UTC.
21:00:22 <zodbot> This meeting is logged and archived in a public location.
21:00:22 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
21:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:22 <zodbot> The meeting name has been set to 'epel_(2021-12-08)'
21:00:22 <tdawson> #meetingname epel
21:00:22 <zodbot> The meeting name has been set to 'epel'
21:00:22 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca
21:00:22 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson
21:00:22 <tdawson> #topic aloha
21:00:38 <rcallicotte> .hi
21:00:39 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
21:00:41 <nirik> morning
21:00:56 <rsc> .hello robert
21:00:57 <SSmoogen[m]> hello
21:00:57 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
21:00:59 <tdawson> Hi rcallicotte
21:01:00 <rcallicotte> gmorning nirik
21:01:02 <tdawson> Hi nirik
21:01:05 <tdawson> Hi rsc
21:01:13 <tdawson> Hi SSmoogen[m]
21:01:27 <salimma> .hi
21:01:28 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
21:01:43 <tdawson> Hi salimma
21:01:50 <carlwgeorge> .hi
21:01:51 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
21:03:04 <tdawson> Hi carlwgeorge
21:04:21 <SSmoogen[m]> I have preliminary numbers for usage of EPEL-9
21:04:35 <tdawson> Already?
21:04:42 * rcallicotte perks up
21:05:11 <SSmoogen[m]> up til 2021-12-05
21:05:37 <tdawson> Why don't we start with that, then move onto the issues.
21:05:43 <carlwgeorge> neat
21:05:58 <SSmoogen[m]> tomorrow weekly countme numbers of 2021-11-29 -> 2021-12-05 will be final but prelim
21:05:59 <tdawson> #topic Preliminary EPEL9 numbers
21:06:59 <SSmoogen[m]> as of the week of 2021-11-22 there were 2944 CentOS 9 systems, and 20 EPEL-next-9 systems
21:06:59 <salimma> wow that's fast
21:07:48 <tdawson> Cool
21:07:51 <nirik> impresive
21:07:55 <rcallicotte> neat
21:07:59 <SSmoogen[m]> I think for the week of 2021-11-29->2021-12-05 there will be about 3200 C9 systems, 20 EPEL-next-9 and 100 EPEL-9 systems
21:08:15 <SSmoogen[m]> things will be easier to see and with the announcements.
21:08:28 <salimma> the epel-next is interesting as... it should be empty right
21:08:31 <SSmoogen[m]> One thing I can see is that most of the C9 systems are not using EPEL-next but only EPEL
21:08:46 <salimma> maybe people who will stick to CS9 and just didn't want to reconfigure later
21:08:51 <carlwgeorge> which is fine, it's not a hard requirement, just a recommends
21:09:12 <carlwgeorge> once we push an update for epel-release most of those will get epel-next-release pulled in from that recommends
21:09:28 <SSmoogen[m]> we should also have a rough percentage usage of EPEL going forward with CS9 users.
21:09:30 <tdawson> salimma: No, all cs9 systems would have the epel9-next repo enabled, but they should now be using the epel9 repo as well.
21:09:45 <SSmoogen[m]> currently it is 7%
21:10:09 <tdawson> Oh, that's right, is a recommends, so they don't have to use it.
21:10:15 <carlwgeorge> epel-next-release requires epel-release, so all of those 20 are in are also in the other group assuming they didn't write their own repo files
21:10:57 <SSmoogen[m]> ok anyway that is all I have. I am looking at getting this automated so that the numbers will be available via data-analysis.fedoraproject.org in the future
21:11:15 <SSmoogen[m]> END_OF_LINE
21:11:18 <salimma> speaking of which, when would EPEL branches show up in src.fedoraproject.org/rpms ?
21:11:28 <salimma> e.g. src.fedoraproject.org/rpms/systemd-extras
21:11:48 <salimma> s/epel/epel9 and epel9-next
21:11:49 <tdawson> Well, the problem I had with my CS9 system was that the epel-release that's in epel-next is the older version.  So if you started out with epel9-next enabled, you don't ever get the updated epel-release, which has the regular epel repo in it.
21:12:38 <carlwgeorge> more early numbers, we already have 501 packages in epel9 testing (255 builds, 157 bodhi updates)
21:12:48 <rcallicotte> nice
21:12:50 <salimma> tdawson: in this particular case we should probably push it in epel9-next too
21:12:58 <salimma> hoping this is an isolated incident?
21:12:59 <nirik> salimma: I think we need to add it to the thing mdapi uses. needs some investigation.
21:13:06 <salimma> 501 packages, that's ... wow
21:13:33 <tdawson> And that isn't all me, I've only got 90 packages at the moment.
21:13:38 <salimma> nirik: thanks. should I file an issue or is that one already?
21:13:57 <carlwgeorge> rsc is responsible for like 40-something % of them
21:14:02 <rsc> :)
21:14:16 <tdawson> You rock rsc :)
21:14:21 <salimma> rsc++
21:14:21 <zodbot> salimma: Karma for robert changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
21:14:46 <nirik> salimma: I can file one when I figure out where the config needs changing. ;)
21:14:58 <rsc> Is the lack of the epel9 branch at src.fedoraproject.org/rpms/systemd-extras a bug? Because there is a epel9 branch.
21:15:01 <salimma> thanks nirik
21:15:02 <nirik> also, all the epel9 branches have backed up fedoraproject emails. :)
21:15:20 <salimma> rsc: yeah that's what I was asking nirik, epel9 is just not being shown in pagure now
21:15:25 <nirik> rsc: there is a branch, look, it shows it
21:15:29 <salimma> well, in the build summary. you can navigate to the branch
21:15:41 <rcallicotte> not in the summary page tho
21:15:44 <carlwgeorge> ohh, that wasn't clear to me at first either
21:15:45 <rsc> nirik: no, not at the summary?
21:15:46 <nirik> you are talking about the summary thing on the front right?
21:15:55 <rcallicotte> yes
21:16:00 * nirik nods.
21:16:17 <nirik> it's cosmetic, but we can/should get it fixed.
21:16:53 <rsc> Btw, for systemd-extras/epel9, we've a nasty hack (https://src.fedoraproject.org/rpms/systemd-extras/blob/epel9/f/9000-Start-after-dbus.socket-rather-SELinux-inotify-watch.patch), because systemd and SELinux seem to play with their forces?
21:17:13 <carlwgeorge> also the stats i gave were just things already in testing, looks like we have 22 more pending in bodhi
21:17:37 <tdawson> We have quite a few issues to get through today, so I'm going to move on.
21:17:45 <tdawson> #topic EPEL Issues
21:17:45 <tdawson> https://pagure.io/epel/issues
21:18:04 <tdawson> I'm going to start from what I hope to be quickest, to longest in discussion time.
21:18:19 <carlwgeorge> here are the ones tagged "meeting" https://pagure.io/epel/issues?tags=meeting&status=Open
21:18:22 <tdawson> .epel 135
21:18:23 <zodbot> tdawson: Issue #135: Modular content for EPEL9 - epel - Pagure.io - https://pagure.io/epel/issue/135
21:18:48 <tdawson> Cool, thanks for the link.
21:19:06 <carlwgeorge> i'm not opposed to that one but i do think the priority should reflect the demand, which is just this one person so far
21:19:19 <carlwgeorge> i.e. we can get around to it once more people show interest
21:19:20 <nirik> and it will have all the limitations that epel8 modules have
21:19:24 <carlwgeorge> yup
21:20:03 <tdawson> The good thing about epel9 vs epel8 modules is we don't have all those default modules to deal with ... but I guess ya, we have the same problem that people can't use the RHEL modules.
21:20:12 <tdawson> I guess we should put that in the issue.
21:21:19 <tdawson> So, I also think the priority should fit the demand, but should we open a releng ticket on it, and just say that it's currently a lower priority?
21:21:49 <SSmoogen[m]> we don't currently have the same problem.. once php/perl/python? get modules later we will have the same problem with building from RHEL
21:22:39 <nirik> SSmoogen[m]: my understanding is that 9 isn't using modules for any default things... they are normal packages? or you mean newer streams? or ?
21:23:11 <tdawson> I think he means that at some point there will be modules in RHEL9.
21:23:12 <carlwgeorge> small related note, i noticed an idm module show up in c9s, but it's empty.  bstinson tells me that a few of those may show up if the maintainers want them, but they're just for compatibility, the default versions will stay non-modular.
21:23:23 <nirik> FYI, filed https://pagure.io/fedora-infrastructure/issue/10412 on the mdapi thing. I think it can be changed in the config in ansible, but not 100% sure what some of those values should be there.
21:23:32 <carlwgeorge> yes, we expect future minor releases of rhel to add non-default module streams
21:23:42 <SSmoogen[m]> newer streams. they will be putting in newer versions of say php/perl/python via modules. we will not be able to build against them
21:24:05 <carlwgeorge> correct
21:24:24 <SSmoogen[m]> so if remi wants to make a newer set of PHP via the updated PHP he will not be able to unless someone builds a set of PHP in our MBS which he could rely on
21:24:40 <SSmoogen[m]> epel-php
21:25:01 <SSmoogen[m]> which could solve the epel-8 issue now I think of it
21:25:01 <nirik> right.
21:25:01 <carlwgeorge> but remi and anyone else can add whatever they want that depends on the default non-modular php (and he already is fwiw)
21:25:27 <SSmoogen[m]> anyway.. EOL
21:25:36 <nirik> I'm kinda of wondering if we couldn't just not do modules for 9, but I guess some people still want them
21:25:56 <carlwgeorge> i would also be fine not doing epel9 modular
21:26:31 <tdawson> For those that use them, they are great.  But the demand isn't as high as originally thought.
21:26:54 <tdawson> So, just say in the ticket that it's still a lower priority?
21:26:57 <carlwgeorge> i say we just leave 135 open through the new year and reevaluate in january
21:27:14 <tdawson> I'm good with that.  I'm going to take the meeting flag off it then.
21:27:17 <salimma> yeah, easier to gauge the need once people start moving away from C8 in earnest
21:27:29 <rcallicotte> agreed
21:28:05 <carlwgeorge> i also think with a new major version every 3 years the need for modules is reduced
21:28:34 <tdawson> Moving on, since these first two were supposed to be short.
21:28:41 <tdawson> .epel 136
21:28:42 <zodbot> tdawson: Issue #136: Is EPEL Playground dead? - epel - Pagure.io - https://pagure.io/epel/issue/136
21:29:28 <carlwgeorge> i think this is in the same boat as modular, we need to gauge the interest
21:29:43 <nirik> yeah, I fear its pretty dead now...
21:29:47 <carlwgeorge> and again i'm personally fine if the interest is low to just get rid of it
21:30:03 <tdawson> I'm ok getting rid of it, it's just that will be some work for someone.
21:30:26 <tdawson> But, leaving it as it is, well, we need to rewrite the documentation, which is also work.
21:30:32 <carlwgeorge> hmmm, on second look this issue isn't asking about epel9 playground, it's asking if the epel8 playground configs should stay in mock
21:30:36 <nirik> yeah, I think with all the other stuff going on (next, eln, etc) it's just never seemed too useful to folks
21:31:04 <carlwgeorge> i think most people that want a yolo repo just use copr
21:31:19 <nirik> yeah
21:31:41 <tdawson> I can do the documentation saying that it's dead, and then we can do the work when people get time.
21:31:53 <SSmoogen[m]> I am ok with it being dead. it was an experiment to try and deal with people who had kept packages in epel-testing all the time so they could update as the package changede
21:31:58 <salimma> speaking of COPR does that support E9 yet?
21:32:06 <carlwgeorge> yup
21:32:29 <carlwgeorge> well, it has c9s chroots, not epel9 ones yet
21:32:42 <SSmoogen[m]> I am also a-ok with it being 'this is dead, please use COPR'
21:33:27 <nirik> I'm a bit sad about it, but ok with retiring it.
21:33:31 <themayor> hello all, sorry to be late, had a conflict
21:33:47 <tdawson> Ya, it was a good idea, but just didn't work out.
21:34:14 * carlwgeorge waves at jack
21:34:37 <tdawson> I'm willing to write-up the documentation declaring it dead.  Do we all agree it's dead?
21:34:49 <carlwgeorge> how many packages are currently in it?
21:35:09 <salimma> we should definitely not create it for 9, at least
21:35:30 <SSmoogen[m]> nirik: you will be able to point out that we actually killed a product which wasn't being used on your 'what did I do that we havent' done in Fedora much'
21:35:43 <tdawson> There are about 270 packages in playground
21:36:06 <tdawson> Oh ... and I own 60 of them
21:36:11 <SSmoogen[m]> bump and rebuild them all for epel-next and call it a day :P
21:36:40 <nirik> probibly need to announce it and give people time and then untag/block them all and turn off the compose
21:36:46 <tdawson> Ahh ... no.  I thought I got rid of all of mine ... I want mind just dropped.
21:37:19 <tdawson> Yep, sounds good.  I'll write up an annoucement ... does 2 months sound like enough time?  First week in February?
21:37:29 <SSmoogen[m]> yep
21:37:31 <carlwgeorge> +1
21:37:56 <carlwgeorge> i wonder if anyone is going to shout that the actually want it to stay
21:37:58 <nirik> sure
21:38:22 <tdawson> Someone might, we'll see.
21:38:43 <tdawson> OK, I think we're done with that, and I have notes on what I'm doing, so ... moving on to the ones that probrubly have more discussion
21:38:47 <carlwgeorge> maybe before we announce it's going away, ask on the list if anyone actually is still using it
21:39:01 <carlwgeorge> at least have something to point to
21:39:11 <SSmoogen[m]> probably need to figure out when the last build in it was
21:39:29 <tdawson> Will do ... both of those, good ideas.
21:39:51 <tdawson> .epel 134
21:39:52 <zodbot> tdawson: Issue #134: Policy for missing subpackages - epel - Pagure.io - https://pagure.io/epel/issue/134
21:40:20 <salimma> so on the issue carlwgeorge proposed standardizing on -epel for new packages, and requiring review
21:40:29 <tdawson> This started as a discussion on #epel I think, and moved to an issue.
21:40:54 <salimma> since even the "easy" case involves some spec mangling anyway. but we should probably document this better in any case
21:40:56 * nirik finds issues poor for discussion, list or meetings better. ;)
21:41:31 <tdawson> nirik Yep, which is why it was also marked as meeting :)
21:42:02 <carlwgeorge> issues are good for summaries to catch people up on things
21:42:18 <nirik> issues are good for actual actions.
21:42:24 <nirik> anyhow.
21:43:00 <salimma> yeah, wanted to discuss here but at least put together our thoughts on the issue so we didn't forget, since it's almost a week ago
21:43:08 <tdawson> For me, it's easier to put my thoughts down in email, or an issue, which is what I did - https://pagure.io/epel/issue/134#comment-767745
21:43:10 <nirik> I kind of like the idea of splitting them by name like that... gives you a good indication of what the package is for
21:43:50 <salimma> nirik: so use both -epel and -extras for different things?
21:43:59 <carlwgeorge> the way the review exception is currently written, both scenarios qualify (as long as the extra subpackage is already in fedora)
21:44:11 <salimma> I guess then the question is, is -epel only for packages built but not shipped, or also for packages conditionally disabled
21:44:11 <nirik> There are or have been other cases of wanting to build something rhel disabled than devel subpackages...
21:44:22 <salimma> yup
21:44:43 <nirik> salimma: seperate things... so you can say 'thats -epel, so it must be building something that was disabled in rhel'
21:45:12 <carlwgeorge> i actually think having to explain the difference between -epel and -extras isn't worth the trouble
21:45:16 <nirik> but perhaps we are making it too complex.
21:45:32 <salimma> yeah, it feels a bit like splitting hair
21:45:46 <SSmoogen[m]> just make it all -epel
21:46:03 <nirik> if we want just one, I'd suggest -epel... since -next could be something else, but -epel makes it clear it's built in epel
21:46:04 <SSmoogen[m]> sometimes it might be -extras-epel but -epel
21:46:20 <salimma> e.g. iptables-epel ships legacy subpackages (that rhel disables with conditionals), systemd-extras shipped networkd and timesyncd that RH excised completely from the spec. those are not very different
21:46:25 <SSmoogen[m]> repotags in packagenames
21:46:46 <salimma> yeah, I move we use -epel consistently and then document how to do the three cases and put them up in docs (and take it out of the FAQ)
21:46:59 <carlwgeorge> salimma: but networkd and timesyncd are still in fedora, right?
21:47:01 <salimma> if this sounds good I volunteer to draft this for the next meeting
21:47:02 <nirik> gnome-backgrounds-extras is in / shipped by rhel in 8.
21:47:13 <salimma> carlwgeorge: yup, just like iptables-legacy is also still in Fedora
21:47:40 <salimma> yeah, -extras is already used for other things so -epel is clearer as Smooge suggested
21:47:40 <carlwgeorge> nirik: hmm, yeah that could get confusing
21:49:09 <nirik> hopefully rhel would never ship something -epel. ;)
21:50:17 <salimma> I wonder if we need a keyword reservation system ;)
21:51:18 <tdawson> If everyone else is for the single -epel name, I'm ok with it.  Sorry for being so quiet.
21:52:16 <rsc> But what happens, in the systemd case, if EPEL enables systemd-foo, which is not in Fedora?
21:52:53 <rsc> And especially systemd-extras does not rely on the same version like RHEL.
21:52:53 <tdawson> rsc: Well then, having -epel is even MORE appropriate :)
21:53:27 <rsc> systemd-extras' version is more like Fedora than RHEL (currently 249)
21:53:47 <carlwgeorge> that would kinda invalidate the exception it qualified for originally (but i've already said i'm ok ditching the exception)
21:54:07 <rsc> Don't get me wrong, I care less about -extras or -epel, my -extras results from php-extras in a time where -epel didn't exist.
21:54:27 * carlwgeorge notes that remi has already submitted php-extras to epel9
21:54:57 <carlwgeorge> how about a should (not must) guideline to use -epel?
21:55:13 <nirik> fine with me.
21:55:59 <salimma> yeah, I don't think we want to enforce people can't use extras
21:56:10 <tdawson> I'm good with that too.
21:56:11 <salimma> let's start by nudging people to use -epel first
21:56:19 <rsc> What would be the terms/conditions for -epel, then?
21:57:11 <SSmoogen[m]> buy one, get the source code for free
21:57:15 <rsc> Packages that need a different SRPM name, due to otherwise SRPM overlaps with BaseOS?
21:57:51 <nirik> yes, thats the underlying issue. you can't use the same packagename/src.rpm
21:57:57 <salimma> packages that ship additional subpackages regardless of whether they're compiled but not shipped or not compiled at all
21:58:03 * rsc tries to figure out, if systemd-extras needs a re-review as systemd-epel ;-)
21:58:10 <salimma> otherwise, we still enforce that you can't replace a RHEL package in EPEL
21:58:53 <salimma> rsc: I tend towards letting existing packages be, no point rereviewing just for this, though we probably want to stick to -epel for new packages
21:59:13 <rsc> salimma: Would -epel be independent of the version?
21:59:39 <salimma> it should still be tied to the RHEL version I think
21:59:40 <rsc> Or would -epel need to match the version of BaseOS?
21:59:45 <salimma> yeah
21:59:48 <salimma> the latter
22:00:07 <carlwgeorge> these kinds of questions make me feel even strong about ditching the review exception
22:00:15 <salimma> iptables-epel is basically just like systemd-extras, so... at least match upstreamname-%{version}, preferably lock on %{release} as well
22:00:34 <rsc> salimma: no, systemd-extras is tracking Fedora, not RHEL for versions.
22:00:36 <salimma> oh yeah, doing both openssl3 and iptables-epel definitely make me feel these should be reviewed
22:00:43 <salimma> rsc: ah, interesting
22:01:19 <rsc> salimma: I don't see myself able to backport security fixes for whatever crazy issues after 5 years code difference, once yet-another-rewrite in systemd-networkd happened (or so).
22:01:23 <salimma> uh, and you can mix and match (run newer networkd on top of older systemd)?
22:01:28 <salimma> I think we can say "does not conflict / can be used together with $pkg in $baseos" then
22:01:36 <salimma> rsc: agreed
22:01:36 <rsc> salimma: if you use systemd-extras on EL8 - yes.
22:01:41 <tdawson> We're running out of time ... actually we've run out of time ...
22:01:47 <salimma> oh shoot
22:01:51 <salimma> sorry tdawson
22:02:01 <salimma> anyway, I'll draft something and post it for the next meeting
22:02:02 <tdawson> Not to much of a problem.
22:02:07 <salimma> thanks for the inputs everyone
22:02:11 <tdawson> I'm just not sure what the final solution was
22:02:32 <carlwgeorge> revisit next week?
22:02:40 <nirik> yeah, more discussion sounds like
22:02:42 <SSmoogen[m]> revisit and publish next week
22:02:47 <tdawson> Sounds good.
22:02:50 <salimma> I'm not 100% sure yet but yeah, revisit with some draft doc so we have something more concrete
22:02:51 <SSmoogen[m]> please send an email of what you write up
22:03:01 <salimma> SSmoogen: will do
22:03:06 <carlwgeorge> i say that but fyi i'll be far afk next week
22:03:09 <tdawson> Talking about next week, I won't be here.  Probrubly no internet access at all during next wedensday.
22:03:32 <salimma> tdawson: that sounds fun, enjoy
22:03:33 * SSmoogen[m] remembers he doesn't run this anymore and gives the gavel and rulebook to the appropriate people
22:03:37 * nirik will also not be here next week, or several after.
22:03:46 <tdawson> Does anyone want to host the meeting next week?  Or should we just cancel it?
22:03:51 <tdawson> I'm ok canceling it.
22:03:52 <salimma> uh, should we take a break until the new year?
22:03:58 <salimma> I think Davide will also be away
22:04:06 <SSmoogen[m]> will be here and declares he will take over the entire... ah man
22:04:12 <rsc> Dec 22th is to close to the holidays?
22:04:16 <salimma> I'm here though
22:04:30 <tdawson> I'll be here in two weeks Dec 22nd ... but I also don't expect others to be.
22:04:47 * nirik will not be here for the next 3 wed's....
22:05:23 <tdawson> Pick things up at the new year?  If we need to discuss, do it on IRC and/or email?
22:05:40 <SSmoogen[m]> I would say do as much via email
22:05:45 <salimma> yeah
22:05:50 <tdawson> Ya, good point.
22:05:53 <SSmoogen[m]> use the ticket to +1 / -1 final approval. announce on th enext meeting
22:05:53 <carlwgeorge> works for me
22:06:00 <nirik> +1
22:06:37 <tdawson> Well then.  It's been a good meeting, and great year.
22:06:52 <tdawson> I'll talk to ya'll next year.
22:07:17 <tdawson> #endmeeting