20:00:17 <tdawson> #startmeeting EPEL (2021-10-27)
20:00:17 <zodbot> Meeting started Wed Oct 27 20:00:17 2021 UTC.
20:00:17 <zodbot> This meeting is logged and archived in a public location.
20:00:17 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:17 <zodbot> The meeting name has been set to 'epel_(2021-10-27)'
20:00:17 <tdawson> #meetingname epel
20:00:17 <zodbot> The meeting name has been set to 'epel'
20:00:17 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca
20:00:17 <tdawson> #topic aloha
20:00:17 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson
20:00:29 <nirik> morning
20:00:34 <carlwgeorge> .hi
20:00:35 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:00:36 <tdawson> Hi nirik
20:00:41 <tdawson> Hi carlwgeorge
20:00:51 <pgreco> hello!
20:00:52 <dcavalca> .hi
20:00:52 <pgreco> .hi
20:00:52 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:00:55 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:00:56 <tdawson> Hi pgreco
20:01:03 <tdawson> Hi dcavalca
20:01:50 <SSmoogen[m]> hello
20:01:58 <tdawson> Hi SSmoogen[m]
20:04:26 <tdawson> I think this is everyone ... and it's close enough to 5 minutes ...
20:04:33 <tdawson> #topic Old Business
20:05:17 <tdawson> I've created a EPEL-9 topic ... and I'm going to ask for the epel9-next stuff during that time ... if that's ok.
20:05:25 <carlwgeorge> 👍
20:05:32 <SSmoogen[m]> none?
20:06:00 <tdawson> Nine ... not Nein
20:06:42 <tdawson> So, for my Fails to Install, I've semi-automated it, so it get's updated daily - https://tdawson.fedorapeople.org/epel/willit/status-overall.html
20:07:01 <tdawson> But beyond that I haven't done much.
20:07:32 <tdawson> pgreco: Were you able to get some testing done for your macros ?
20:07:54 <pgreco> yes, bkircher tested some packages
20:07:59 <tdawson> Ya!!
20:08:10 <tdawson> Did they work?
20:08:18 <pgreco> and they seem to work, but the question now is wrt Provides:
20:08:31 <pgreco> because these macros come from systemd-rpm-macros (or something)
20:08:38 <pgreco> which doesn't exist in el7
20:08:45 <tdawson> Oh ... I remember seeing that.
20:09:01 <pgreco> and I don't like the idea of doing such Provides in epel-srpm-macros
20:09:29 <pgreco> epel8 might be easier because I could do a "Supplements: systemd-rpm-macros" and it should work
20:09:43 <carlwgeorge> the actual macros are in the systemd package, so i think the best solution would be an empty systemd-rpm-macros package that requires systemd
20:10:17 <pgreco> the rhel8 you mean?
20:10:31 <carlwgeorge> no, in epel7
20:11:03 <pgreco> if we provide all the macros from systemd, adding Provides:systemd-rpm-macros to epel-rpm-macros should work
20:11:06 <carlwgeorge> in rhel8, systemd has the macros and also provides systemd-rpm-macros
20:11:26 <pgreco> rhel8 with a supplements, should be ok, do you agree?
20:11:50 <carlwgeorge> i don't think epel-rpm-macros should provide systemd-rpm-macros, because it doesn't have those macros
20:12:17 <pgreco> let's split the discussion :P
20:12:26 <pgreco> starting with 8 which seems easier
20:12:44 <pgreco> Supplements solves the issues, yeay or nay?
20:12:47 <SSmoogen[m]> carlwgeorge: he is saying if he adds all those macros in 7 to add provide systemd-rpm-macros.
20:13:36 <pgreco> exactly, not only these ones, all the other systemd macros that might be needed
20:13:45 <carlwgeorge> that still wouldn't be ideal because most of the macros are defined in /usr/lib/rpm/macros.d/macros.systemd, owned by systemd
20:14:32 <tdawson> If we have "Supplements" ... does that mean that it doesn't automatically pull in systemd each time epel-rpm-macros get's pulled in, correct?
20:14:41 <carlwgeorge> i'm not sure if supplements is the answer in 8
20:15:10 <tdawson> I don't like the idea of pulling in systemd each time epel-rpm-macros get's installed, cuz that is every rpm build, that adds alot of overhead.
20:15:10 <pgreco> supplements in an extra supbackage would be automatically pulled if systemd-rpm-macros is installed
20:15:16 <carlwgeorge> is there an issue or list thread that overview the problem that i can read to get more familiar with the problem to be solved?
20:15:43 <pgreco> not really, this all came up from a discussion in #epel, adding some macros that are in fedora
20:15:47 <pgreco> but not in 7/8
20:16:24 <carlwgeorge> my suggestion, lets start an issue in https://pagure.io/epel/issues, and describe the overall problem and potential solutions
20:17:17 <tdawson> I'm not sure Supplemental is correct either, because that means each time systemd (on 8) is installed (which is on every machine) then epel-rpm-macros is installed.
20:17:32 <carlwgeorge> is this the same as https://pagure.io/epel/issue/77
20:18:11 <pgreco> yes, looks like the same thing
20:19:35 <pgreco> ok, to summarize, the macros themselves work, we're dealing with the packaging/delivery
20:19:53 <carlwgeorge> as tdawson said, the proposed solution would pull systemd into every buildroot, which is not ideal, but it would work
20:19:59 <tdawson> Yep
20:20:22 <pgreco> yeah, not a fan of that
20:20:54 <tdawson> I hate to suggest a separate package (maybe sub-package) actually called supplemental-system-macros ... but I'm still suggesting it. :)
20:21:15 <pgreco> looks like the "less bad" option
20:21:24 <carlwgeorge> are there additional systemd related macros that are not part of el7 systemd we're trying to deliver?
20:21:33 <pgreco> but that still requires conditionals in packages pulling the macros
20:21:59 * nirik wonders how many packages this affects really.
20:22:00 <pgreco> carlwgeorge: not in my case, but there may be some
20:22:48 <carlwgeorge> i'm still not seeing a drawback to just creating and epel7-only systemd-rpm-macros package that requires systemd, not leaving epel-rpm-macros along
20:23:10 <carlwgeorge> s/not/and/, s/along/alone/
20:23:45 <pgreco> with the macros for sysusers we're trying to add, that would be fine
20:24:13 <pgreco> subpackage that provides systemd-rpm-macros pullying systemd and delivering the "extras" seems ok for 7
20:24:14 <carlwgeorge> yes additional macros could be defined in that epel7-only package
20:24:33 <pgreco> that works for me
20:24:50 <pgreco> so what seemed to be easier for 8 is actually harder
20:25:12 <pgreco> because we'd be forcing to pull systemd into the buildroot
20:25:43 <tdawson> Well, if we are creating a new package, what if we still go with my supplemental-systemd-macros package name, but on epel7 it Provides systemd-rpm-macros
20:26:04 <carlwgeorge> on 8 any package that buildrequires systemd-rpm-macros is actually pulling in systemd anyways
20:26:24 <tdawson> Correct
20:26:34 <pgreco> but the problem is that systemd-rpm-macros is systemd
20:26:49 <carlwgeorge> right, we can't have systemd-rpm-macros in epel8
20:26:54 * nirik would find both confusing. :(
20:27:22 <nirik> supplemental-systemd-macros really provides systemd-rpm-macros? vs systemd-rpm-macros are in epel?
20:27:33 <carlwgeorge> how about an epel-rpm-macros-systemd subpackage of epel-rpm-macros, in both epel7 and epel8.  on epel7 it provides systemd-rpm-macros.  on epel8 it supplements systemd.
20:27:48 <tdawson> Oh, I like that.
20:28:01 <pgreco> I think that's the best I've heard so far
20:28:04 <carlwgeorge> i wouldn't want to use supplemental in the subpackage name because of confusion with supplements
20:29:11 * nirik is trying to parse how that solves the rhel8 part.
20:29:20 <carlwgeorge> i can comment with that proposed idea on that 2yr old issue, and perhaps even send prs
20:30:00 <nirik> I'm not sure it will...
20:30:26 <pgreco> carlwgeorge, I'm working on the actual macros, I'll point you to my branch if you want to pick it up from there
20:30:53 <pgreco> or I can implement your idea, we can discuss offline if you want
20:31:05 <carlwgeorge> nirik: an epel8 package would buildrequire systemd-rpm-macros.  that's provided by systemd from rhel8.  an epel-rpm-macros-systemd package that supplments systemd would get installed in the epel8 chroot.
20:31:37 <tdawson> I'm going to timebox this discussion ... bring it to email, on the issue or back to the #epel channel
20:31:38 <nirik> that would work in everywhere except koji
20:31:43 <carlwgeorge> unless chroots are set up with install_weak_deps=0
20:31:53 <nirik> koji passes: yes that
20:32:12 <nirik> config_opts['dnf_common_opts'] = ['--setopt=install_weak_deps=0']
20:32:28 <tdawson> ugg ... then yep, supplements wouldn't work.
20:32:44 <tdawson> Let's move this to email or the issue
20:32:48 <carlwgeorge> i'll revive that issue with a summary of what we talked about and move on
20:32:48 <pgreco> yeah
20:32:59 <bkircher> I'm also willing to do work since I asked about the macro in the first place :)
20:33:10 <tdawson> I have one last, short old business
20:33:39 <tdawson> bugzilla's for RHEL packages replacing EPEL packages has been completely implemented, including adding the bugs to a bug tracker.
20:33:49 <nirik> nice!
20:34:00 <tdawson> https://bugzilla.redhat.com/show_bug.cgi?id=1998160
20:34:24 <tdawson> So, if we see RHEL create a package that is already in RHEL, it should show up there.
20:34:26 <pgreco> bkircher: look at the problem you created!! :P
20:34:41 <tdawson> If it doesn't, let me know and I'll re-open the internal issue.
20:34:50 <carlwgeorge> tdawson: that reminds me, i've got a few 8.5 ones that i can add there
20:35:07 <tdawson> Yep, good idea.
20:35:32 <tdawson> And, moving on ...
20:35:34 <tdawson> #topic EPEL-7
20:35:54 <tdawson> Beyond the macros stuff we were just discussing, is there any epel7 things to bring up?
20:36:50 <tdawson> I'll take that as a no ...
20:36:57 <tdawson> #topic EPEL-8
20:37:26 <tdawson> Anything for epel8, other than the macros we were discussing before?
20:37:39 <carlwgeorge> oh real quick i did have an epel7 thing
20:37:51 <tdawson> Sure thing
20:38:02 <carlwgeorge> python2-qpid-proton was removed from the epel7 qpid-proton spec file, and two packages are now uninstallable
20:38:13 <carlwgeorge> https://bugzilla.redhat.com/show_bug.cgi?id=2013863 and https://bugzilla.redhat.com/show_bug.cgi?id=2013864
20:38:42 <carlwgeorge> after two weeks with no response from the maintainers, i'm leaning towards just retiring them myself via provenpackager
20:39:06 <carlwgeorge> anyone think i should wait longer?
20:39:10 <nirik> +1 (although we could orphan them, but then we need to implement a orphan cleanup policy. ;)
20:39:52 <carlwgeorge> i don't think orphan would be appropriate, they still work in fedora i think
20:39:53 <tdawson> Actually, I think an orphan policy is good to start looking at
20:40:13 <SSmoogen[m]> do we orphan per branch or package completely?
20:40:25 <carlwgeorge> orphan is per package as far as i know
20:40:27 <nirik> it's per branch...
20:40:41 <nirik> you can orphan something just in some...
20:41:02 <carlwgeorge> you can retire a branch, but orphan is per package
20:41:06 <nirik> at least as far as I recall.
20:41:38 <nirik> it might be epel/fedora only I guess...
20:41:54 <nirik> because you could set epel owner to orphan
20:42:03 <carlwgeorge> in distgit the orphan button doesn't let you pick the branches, it's all or nothing
20:42:04 <nirik> anyhow, this is probibly just a sidetrack
20:42:12 <tdawson> carlwgeorge Give both packages another ping ... just to make sure ... with my "Will It Install" program, we need to figure out the proceedure of what to do with packages that don't install.
20:42:22 <nirik> right, but you can not use that and set epel branches to orphan as the owner.
20:43:01 <carlwgeorge> oh, looks like qtools is already orphaned, that one will be easy
20:43:12 <tdawson> Yep
20:43:19 <carlwgeorge> i'll ping the other one
20:43:24 <tdawson> ok
20:44:06 <tdawson> I'll write up an email with some type of proposal ... cuz I don't totally know what to do when my program starts filing bugz.
20:45:01 <tdawson> Moving on to next topic ...
20:45:09 <tdawson> #topic EPEL-9
20:45:26 <tdawson> How are things looking for epel9-next ?
20:46:16 <carlwgeorge> i've got the epel9 key into distribution-gpg-keys, and epel9-next configs into mock-core-configs
20:46:34 <tdawson> Nice
20:46:37 <nirik> the z15 s390x move hopefully will happen shortly after f35 release.
20:46:41 <pgreco> work call, need to drop....
20:47:23 <SSmoogen[m]> suuuure
20:47:37 <tdawson> And ... with the f35 delays ... I've lost track ... when do we expect that?
20:48:47 <carlwgeorge> 1-3 weeks perhaps?
20:48:48 <bkircher> in 5 days
20:48:54 <bkircher> Nov 2
20:49:09 <bkircher> the F35 release I mean
20:49:25 <tdawson> Oh ... so not too bad
20:50:01 <nirik> well, we don't know
20:50:08 <tdawson> So, hopefully it will start sometime next week ... and then ... take a couple weeks we think?
20:50:10 <nirik> go/no-go is tomorrow for a release next week
20:50:34 <bkircher> ah, correct
20:50:36 <nirik> so we could possibly do it late next week yeah
20:51:19 <nirik> and actually I might have come up with a way to do it next week anyhow... since we have 2 lpars and turns out we can move them one at a time...
20:51:37 <carlwgeorge> my goal is to have epel9-next ready by dec 1st
20:52:26 <tdawson> Sounds good.
20:52:36 <tdawson> And if it gets done faster ... even better.
20:53:38 <tdawson> nirik carlwgeorge Any help either of you need?
20:53:53 <nirik> don't think so?
20:54:26 <tdawson> Cool, then I'll leave that in your capable hands.
20:54:43 <tdawson> #topic EPEL-Packaging-SIG
20:55:01 <tdawson> dcavalca: Anything new on the packaging SIG?
20:55:07 <dcavalca> I have a couple of things
20:55:43 <dcavalca> https://bugzilla.redhat.com/show_bug.cgi?id=2004762 and https://bugzilla.redhat.com/show_bug.cgi?id=2009831 are things we'll need in CRB to unblock epel9 packages
20:56:08 <dcavalca> the first one in particular will block qemu, which bkircher is working on for epel8 right now
20:56:51 <dcavalca> I've also made some progress getting a few rust things packaged properly for epel8
20:57:05 <dcavalca> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e713d25c47 is resctl-demo and resctl-bench
20:57:19 <dcavalca> and I'm just waiting for a scratch build to end to push an update for below in epel8
20:57:40 <dcavalca> this last one in particular might be interesting, as I found a (horrifying) way to patch transitive dependencies when vendoring
20:57:41 <tdawson> dcavalca: I know the appstream package is being worked on.
20:57:46 <dcavalca> which might come in handy for other packages too
20:58:24 <tdawson> I was pinged about the appstream thing today, and they are working through the procedure.
20:58:33 <dcavalca> good to hear
20:59:30 <tdawson> Ohh ... the transitive dependencies ... do I want to know the horrifying way to patch them, or should I continue to shut my eyes whenever rust packaging comes up ?
20:59:52 <carlwgeorge> the iscsi-devel one seems to be trending in the right direction in the private comments
21:00:15 <dcavalca> tdawson: https://paste.centos.org/view/320c6733
21:00:23 <dcavalca> line 277 explains how this works
21:00:34 <dcavalca> thanks carlwgeorge
21:01:03 <tdawson> You are correct ... horrifying ... and just in time for halloween. :)
21:01:23 <dcavalca> I figured you'd like this :)
21:01:29 <carlwgeorge> uggh, rust is such a pain in the ass
21:01:46 <tdawson> Looks like our time is up ... anything else?
21:01:55 <dcavalca> that's all I had
21:02:00 <nirik> BTW, below is cool. ;)
21:02:15 <tdawson> dcavalca: Thanks for your work on that.
21:02:25 <tdawson> #topic General Issues / Open Floor
21:02:42 <tdawson> Our time is up, but is there anything that really needed to be brought up.
21:02:53 <dcavalca> thanks nirik, glad to hear you like it
21:03:03 <nirik> thanks for packaging it. :)
21:03:47 <tdawson> Thanks everyone for coming and having a good discussion.  And thank ya'll for all your EPEL work.
21:04:00 <tdawson> Talk to you next week, if not sooner.
21:04:06 <tdawson> #endmeeting