22:02:09 <tdawson> #startmeeting EPEL (2020-12-18)
22:02:09 <zodbot> Meeting started Fri Dec 18 22:02:09 2020 UTC.
22:02:09 <zodbot> This meeting is logged and archived in a public location.
22:02:09 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
22:02:09 <zodbot> The meeting name has been set to 'epel_(2020-12-18)'
22:02:11 <tdawson> #meetingname epel
22:02:11 <zodbot> The meeting name has been set to 'epel'
22:02:12 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel_slm
22:02:12 <zodbot> Current chairs: bstinson carlwgeorge michel_slm nirik pgreco tdawson
22:02:14 <tdawson> #topic aloha
22:02:18 <michel_slm> .hello salimma
22:02:19 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
22:02:26 <tdawson> Hi michel_slm
22:02:42 * cyberpear listens in again
22:02:43 <michel_slm> hi tdawson !
22:02:49 * King_InuYasha waves
22:02:50 <tdawson> Hi cyberpear
22:02:51 <King_InuYasha> .hello ngompa
22:02:52 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
22:02:55 <tdawson> Hi King_InuYasha
22:03:06 * carlwgeorge waves
22:03:12 <tdawson> Hi carlwgeorge
22:04:37 <pgreco> hello!
22:05:17 <tdawson> Hi pgreco
22:05:39 <tdawson> Quite alot for potentially the last meeting of a crazy year.
22:05:49 <tdawson> #topic Old Business
22:05:50 <tdawson> EPEL-Packaging-SIG
22:06:12 * King_InuYasha sighs
22:07:02 <tdawson> michel_slm: What do we have left to do on the EPEL-Packaging-SIG now that the documentation is done?
22:07:17 <michel_slm> one sec, cat's attacking my keyboard
22:07:36 <tdawson> Gotta hate that.
22:07:43 <michel_slm> he's so cute I can't get mad
22:08:04 * michel_slm 's cat likes to massage his back with keyboard keys
22:08:06 <pgreco> I'm sure the cat has less typos than hughesjr :)
22:08:22 <tdawson> Do you need me to do epel8-next first?
22:08:25 <michel_slm> lol. I think we can link the Packaging page to the main EPEL wiki and announce it
22:08:30 <michel_slm> nah, I chased the cat out
22:08:53 <michel_slm> also we can take a look at the queue of requests and see what might make sense for the SIG to own
22:09:22 <michel_slm> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&f1=delta_ts&list_id=11543139&o1=greaterthan&order=Last%20Changed&product=Fedora&product=Fedora%20EPEL&query_format=advanced&short_desc=epel&short_desc_type=allwordssubstr&v1=-1w
22:10:10 <michel_slm> (maybe I'll just post this to the epel-devel list on a periodic basis rather than doing it during the meeting)
22:10:57 <michel_slm> one question for now though - if we want to be able to get the SIG added to a package without triggering the nonresponsive maintainer process, where should we file this?
22:11:05 <michel_slm> fesco maybe?
22:12:34 <tdawson> Sorry, was looking at the list
22:12:36 <King_InuYasha> that's usually fesco approval and then releng does the thing
22:14:09 <michel_slm> ok, I'll get that started then. was hoping to get the ability for collaborators to branch a package first but that seems to be taking a long time
22:14:32 <tdawson> I just noticed that that list is for just the past week.  I bet if we go back several weeks, we would be able to invoke the "unresponsive maintainer" and just take them.
22:14:43 <michel_slm> in general people have been added as committers when they want to maintain for EPEL only, so most maintainers are probably ok with it
22:14:54 <tdawson> Yep
22:14:58 <michel_slm> tdawson: yeah, I can change that to be > 2 weeks for now
22:15:21 <michel_slm> eventually we want to do 1 week (at least for the packages we care about) since the goal is to speed up the process
22:15:35 <tdawson> Ya, I'm betting that most maintainers would add the sig if we asked.
22:15:43 <pgreco> as a backup
22:16:06 <michel_slm> ok, I think that's it for me on this topic. I'll also use epel tickets for proposed documentation changes now that it's live
22:16:14 <michel_slm> pgreco: ?
22:16:33 <pgreco> michel_slm: as a backup for them, in case they don't respond in time I meant
22:16:39 <michel_slm> ah, yes
22:16:58 <pgreco> if the sig is added, we need to try to maintain the order for those who keep all their branches in sync
22:17:14 <pgreco> we need to be respectful of that
22:17:49 <michel_slm> as in, not push changes to the Fedora branches without a PR first?
22:18:41 <pgreco> that, or as in not push changes that would make the branches diverge
22:18:58 <pgreco> like what happened with the packages.cfg
22:19:10 <michel_slm> yeah.
22:19:22 <pgreco> which had the side effect that every time the maintainer merged to epel8, it had a merge commit
22:19:38 <pgreco> instead of a fast forward, like I like to keep in my branches
22:19:45 <michel_slm> I'll propose a code of conduct for packager SIG members to reassure maintainers we won't do this
22:19:46 * nirik arrives late
22:19:59 <tdawson> Yep, that made epel8 unpopular among several.
22:20:02 <tdawson> Hi nirik
22:20:14 <pgreco> michel_slm: that we'll try to be mindful of it ;)
22:20:24 <pgreco> reassure is a strong word
22:21:08 <michel_slm> yeah
22:21:09 <tdawson> Although I think most maintainers who do all branches at once, probrubly don't want/need the sig as a backup.  They usually have it under control.
22:21:32 * pgreco nods
22:21:36 <michel_slm> yup, it would be like the Python SIG - if you think you need help maintaining the package, add us
22:22:09 <michel_slm> it's the existence of maintainers that ignore EPEL requests that this is meant to help with
22:22:54 <tdawson> OK, I'm going to move on.
22:23:14 <tdawson> epel8-next - carlwgeorge do you have a status for us?
22:23:23 <carlwgeorge> no news on the epel next front, still waiting on staging bodhi permissions.  i fear any further work is going to get pushed back till after shutdown.
22:23:34 <tdawson> carlwgeorge: And no, I didn't get an rpm made that has that feature.
22:24:10 <carlwgeorge> i think King_InuYasha may be able to help here, i can get with him after the meeting.  we can test that out while other stuff is blocked.
22:24:52 * King_InuYasha nods
22:25:00 <tdawson> Has anyone in this group seen the rpm Requires feature/option that basically is like a runtime if statement "if package X is installed, then I require package Y, otherwise don't worry about Y"
22:25:51 <carlwgeorge> i.e. in epel-release, if centos-stream-release is installed, require epel-next-release
22:26:02 <michel_slm> yup
22:26:20 <michel_slm> I think I saw it in either redhat-rpm-config or python-rpm-macros
22:26:22 <tdawson> I saw that recently, was all excited ... and now I can't remember which package I saw it on ... so I have no example.
22:26:23 <carlwgeorge> i've heard of such things but i'm not familiar with the implementation, or if el8's rpm is new enough
22:26:49 <tdawson> Hmmm ... I've looked at both of those recently ... I'll look there.
22:26:51 <nirik> should be easy enough to do... although...
22:26:58 <pgreco> I seem to remember some (if gcc require annobin) or something like that in spec files
22:27:03 <King_InuYasha> tdawson: yes, I've used it plenty
22:27:14 <King_InuYasha> rpm 4.14 in el8 has it
22:27:15 <michel_slm> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/redhat-rpm-config.spec#_118
22:27:28 <tdawson> YES!! ... thank you
22:27:29 <michel_slm> pgreco has good memory
22:27:56 <pgreco> hehe
22:28:00 * King_InuYasha was one of those folks who pushed for those features in the first place upstream, so he remembers when they became a thing...
22:28:19 <King_InuYasha> shame that we don't have %elif though
22:28:29 <pgreco> yeah, they are really useful
22:28:41 <pgreco> maybe for fedora 144 we'll have %elif
22:28:47 <tdawson> :)
22:28:47 <King_InuYasha> nah, we have it in Fedora 33 now
22:28:57 <King_InuYasha> it's a new feature in rpm 4.16 :)
22:29:40 <pgreco> nice, it should be backported to 4.14, so we can use it in epel
22:29:52 <King_InuYasha> sorry rpm 4.15
22:30:00 <King_InuYasha> so we've got it since Fedora 31
22:30:13 <carlwgeorge> pgreco: sounds like a good contrib idea for centos stream
22:30:15 <King_InuYasha> yeah, I want it backported to rpm 4.14 in el8
22:30:15 * carlwgeorge ducks
22:30:38 <pgreco> carlwgeorge: you're a big guy, you don't need to duck from me :D
22:30:51 <nirik> although... this might run afoul of guidelines...
22:31:16 <nirik> "All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories."
22:32:03 <nirik> but this is clearly a good exception... so perhaps I should just not have brought it up. ;)
22:32:08 <King_InuYasha> that's a rather annoying rule, actually
22:32:51 <nirik> I mean as epel we can just add it to our exceptions to guidelines... we already have some
22:32:57 <King_InuYasha> right
22:33:09 * King_InuYasha thinks that rule is a little too harsh even for Fedora
22:33:28 <michel_slm> any example of where it doesn't work for Fedora? curious
22:33:37 <michel_slm> I guess for weak dependencies that's a bit harsh
22:33:39 <tdawson> Correct, because there are plenty of weak dependencies that aren't in RHEL
22:34:35 <nirik> I think it was designed to avoid fedora adding stuff depending on rpmfusion say... which kind of is an implicit endorsement of the name rpmfusion uses.
22:34:40 <pgreco> well, a weak dependency, that doesn't trigger an error if missing, it is satisfied (though I could argue it both ways)
22:35:50 <michel_slm> weak dependencies can be done both ways though, so I guess rpmfusion can always add it on their side
22:35:54 <nirik> anyhow, thats a sidetrack. I think this aproach is a good one. :)
22:35:57 <michel_slm> "this package enhances Fedora package foo"
22:36:04 <carlwgeorge> That's a good point, we could use recommends for the epel-next-release dependency
22:36:35 <tdawson> carlwgeorge: The recommends would need to be on centos-stream-release though
22:36:36 <nirik> or require it if epel-release is installed?
22:37:00 <carlwgeorge> if centos-stream-release, epel-release recommends epel-next-release
22:37:05 * cyberpear not a fan of bool deps
22:37:26 <michel_slm> recommends is strong enough, yeah. at least for now. I wonder if anyone is working on the ability to not install it, like apt has
22:37:44 <King_InuYasha> --setopt=install_weak_deps=False?
22:37:53 <michel_slm> oh huh
22:38:02 <michel_slm> if that's a thing our weak dependency guide is wrong
22:38:09 <carlwgeorge> such an obtuse flag, we need a shorter version
22:38:14 <pgreco> King_InuYasha: that's normally part of my kickstarts :)
22:38:15 <King_InuYasha> I've been begging for years
22:38:30 <michel_slm> https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
22:38:39 <michel_slm> King_InuYasha: want to document that workaround?
22:38:49 <King_InuYasha> --install-weak-deps or --no-install-weak-deps would be better
22:38:49 <michel_slm> this is plain wrong: "Future versions of dnf might also allow to switch weak deps off on the command line.)"
22:38:58 * King_InuYasha facepalms
22:39:06 <michel_slm> agreed, but not being exposed as a separate option != doesn't exist
22:39:06 <King_InuYasha> we've had the ability to turn it off since the beginning
22:39:41 <King_InuYasha> the reason --excludeWeakDeps exists in kickstarts is because kkofler and I wrote that change to pykickstart :)
22:39:55 <tdawson> Anyway ... getting back from Fedora to EPEL ... carlwgeorge now that I have the right command, I'll get you the rpm right after the meeting.
22:40:18 <cyberpear> King_InuYasha++ for kickstart work
22:40:53 <tdawson> carlwgeorge: Anything else before we move on?
22:40:53 <carlwgeorge> if i understand the syntax right it should be `Recommends: (epel-next-release if centos-stream-release)`, added to epel-release
22:41:10 <tdawson> carlwgeorge: correct
22:41:13 * michel_slm will submit PR to update the Weak Dependencies doc
22:41:18 <carlwgeorge> nope, that's it from me
22:41:26 <carlwgeorge> thanks michel_slm
22:42:00 <tdawson> OK, up next is missing -devel packages
22:42:27 <tdawson> Actually, I think this one sorta fixed itself ... but I wanted to bring it up incase anyone had any comments.
22:43:06 * pgreco needs to read that thread again
22:43:07 <tdawson> I mean fixed itself, because the email thread sorta worked out, commands, spec file and all, how to do it.
22:43:51 <nirik> needs a doc?
22:43:51 <tdawson> I was thinking of gathering that up and getting it into the EPEL wiki.
22:44:01 <tdawson> Ha ... ya beat me. :)
22:44:03 * nirik wasn't sure from the list thread what in the end worked or was made to work
22:44:57 <tdawson> Since I have three packages that never made it into CentOS Devel ... I can take one or two and work through the steps, making sure things work.
22:45:07 <cyberpear> (btw, it's called centos-release-stream unless it's being renamed)
22:46:02 <tdawson> cyberpear: Thanks ... seems like an odd ordering of the name ... but ... if that's what it is.
22:46:48 <cyberpear> there's lots of centos-release-<sig> packages, too
22:47:26 <tdawson> Hopefully I can get that done before the next meeting, and we can see if the -devel instructions are usable.
22:48:19 <tdawson> Anything else about missing -devel packages?
22:49:01 <tdawson> #topic EPEL-7
22:49:32 <tdawson> I don't have anything for EPEL-7 ... does anyone else?
22:49:38 <King_InuYasha> nope
22:49:50 <tdawson> #topic EPEL-8
22:50:12 <King_InuYasha> whoo boy
22:50:27 <tdawson> :)
22:50:46 <King_InuYasha> I don't know what we're going to do about EPEL 8
22:51:02 <nirik> what do we need to do?
22:51:27 <carlwgeorge> cyberpear: it was renamed, but the old one is still what's in the linux repos for the conversion
22:51:31 <King_InuYasha> well, at least by the end of next year, we need to transaction all mock configs off centos-8
22:52:02 <nirik> yeah, but it's not clear to what... I think we will need to wait 6months or so and see what happens.
22:52:10 <King_InuYasha> yeah
22:52:15 <King_InuYasha> the options right now aren't great
22:52:19 <tdawson> True ... but I figure that gives us six months to look at what develops, and then 3 to 4 months to implement.
22:52:40 <tdawson> Ya'll type too fast. :)
22:54:17 <King_InuYasha> besides that, I got nothing
22:54:40 <tdawson> Me either, or at least nothing we haven't already covered.
22:54:47 <tdawson> #topic General Issues / Open Floor
22:54:58 <michel_slm> we'll just have epel-8-next / epel-next-8 and archive epel8 next year, right?
22:55:17 <tdawson> :)
22:55:26 <nirik> ha. no.
22:55:49 <tdawson> I don't know about everyone else, but I'm not going to be around the next two fridays.
22:56:06 <King_InuYasha> same
22:56:16 <michel_slm> I'm OK to skip until January
22:56:17 <pgreco> I hadn't even considered that the meetings were happening
22:56:17 <tdawson> Is everyone ok with not having a meeting for two weeks, so the next will be Jan. 8, 2021
22:56:23 <michel_slm> Jan 8?
22:56:24 <michel_slm> yup
22:56:26 * nirik will be as much as he is today, which is to say... only if I happen to be at the keyboard. ;)
22:56:27 <King_InuYasha> sounds good
22:56:34 <nirik> yep
22:56:46 <tdawson> passed ... no meetings until Jan. 8.
22:56:50 <pgreco> omg, I can't believe I'm saying happy new year
22:57:11 <michel_slm> can't be worse than 2020
22:57:14 <michel_slm> :D
22:57:30 <michel_slm> Happy New Year to everyone I don't see until then!
22:57:44 <cyberpear> can we add a symlink for epel6 on archive?
22:58:04 <cyberpear> I've always done yum install dl.fpo/pub/epel/epel-release-latest-6.noarch.rpm
22:58:49 <cyberpear> I'd assume I could do the same w/ dl.fpo/pub/archive/epel, but it is not symlinked there... (I'll never remember that it's version 6 release 18 or whaever)
22:58:51 <nirik> cyberpear: it's eol?
22:58:57 <cyberpear> it is, but it's still useful
22:59:15 <cyberpear> you'd be surprised how many were still using el5 this year
22:59:16 <tdawson> I was talking to someone yesterday and said something along the lines of "The year is finally over" ... but then we both quickly said "Nope ... 2020 isn't dead until it's dead.  Something else can pop up in two weeks."
22:59:52 <nirik> well, the way we are setting the link will mean that one has to be done totally seperately...
22:59:54 <King_InuYasha> I mean, I was saying that last week
23:00:11 <nirik> I guess we could, but seems a lot of work for something that is end of life and we don't want to advertize anymore
23:00:13 <King_InuYasha> and then 2020 smacked me in the face with an awful reminder that, yes, 2020 is not over yet
23:00:50 <King_InuYasha> cyberpear: if we did that, then people would keep using it
23:00:51 <pgreco> well, last week was an apt way to end the year
23:00:56 <cyberpear> at least I asked... if it's too much effort, don't worry about it
23:00:57 <nirik> cyberpear: can't you just hard code it? it's not ever going to change
23:01:11 <King_InuYasha> pgreco: ugh
23:01:18 <cyberpear> on CentOS 6, it's in extras... on RHEL 6, I always need the URL
23:01:57 <nirik> https://dl.fedoraproject.org/pub/archive/epel/6/x86_64/Packages/e/epel-release-6-8.noarch.rpm
23:02:06 <pgreco> is there an EUS for rhel6?
23:02:12 <cyberpear> yeah... thankfully it is linked 2 directories up
23:02:14 <tdawson> Thank you everyone for not only coming this week, but coming all the times pasts.  It hasn't always been easy but we've kept EPEL stable, relavent and what people wanted.
23:02:16 <cyberpear> ELS, for 3.5 more years
23:02:19 <carlwgeorge> I think Evolution said it best, it's not truly stable till it's eol, no more of those pesky updates
23:02:29 <tdawson> :)
23:02:32 <nirik> ha
23:02:43 <pgreco> hehehe, he's not wrong there
23:02:47 <tdawson> I'll talk to ya'll next year.
23:02:52 <pgreco> see ya!
23:02:55 <tdawson> #endmeeting