20:01:00 <tdawson> #startmeeting EPEL (2021-06-30)
20:01:00 <zodbot> Meeting started Wed Jun 30 20:01:00 2021 UTC.
20:01:00 <zodbot> This meeting is logged and archived in a public location.
20:01:00 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:00 <zodbot> The meeting name has been set to 'epel_(2021-06-30)'
20:01:01 <tdawson> #meetingname epel
20:01:01 <zodbot> The meeting name has been set to 'epel'
20:01:01 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca
20:01:01 <tdawson> #topic aloha
20:01:01 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson
20:01:01 <pgreco> hey ;)
20:01:11 <nirik> morning
20:01:24 <tdawson> Hi michel pgreco and nirik
20:01:37 <dcavalca> .hi
20:01:37 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:01:45 <michel> .hello salimma
20:01:46 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:01:54 * carlwgeorge tips cowboy hat
20:01:57 <michel-slm> test. looks like Matrix->IRC is slow
20:01:59 <tdawson> Hi dcavalca
20:02:09 <michel-slm> IRC->Matrix is faster
20:02:14 <tdawson> Hi carlwgeorge
20:02:53 <tdawson> michel-slm: I've already said Hi to you as michel :)
20:03:35 <michel-slm> tdawson: haha, yeah. hi tdawson carlwgeorge dcavalca
20:05:32 <tdawson> #topic Old Business
20:05:40 <tdawson> Let's start with the SIG
20:06:06 <michel-slm> I've updated the wiki a bit in https://fedoraproject.org/wiki/EPEL/Packagers
20:06:19 <michel-slm> it now points to the guidelines for escalating stalled requests
20:07:06 <tdawson> And it looks like you updated the part that says we're still working on collaborators requesting branches.
20:07:11 <tdawson> Looks good.
20:07:28 <michel-slm> yep, updated that to indicate collaborator access now works. and on a topic straddling packagers + epel-next -- nextcloud-client is now built and is in testing
20:07:54 <tdawson> Cool
20:08:44 <tdawson> On a similar straddling topic, as I create <package>-epel packages for missing devel, I'm making sure to add the sig as co-maintainers.
20:08:45 <michel-slm> one thing that came up in my nextcloud-client request is... the primary maintainer wasn't sure what epel-packagers-sig is, and why they should get collaborator access, and how. trying to think of a boilerplate text that I will put in my tool for automating branch request, but we might also need some screenshots showing how to navigate the ACL page
20:09:23 <tdawson> That's a good idea.
20:09:25 <michel-slm> on the topic of missing -devel... (this can go later when we get to epel8)
20:09:29 <nirik> also might be nice to send to devel-announce to just raise awareness?
20:09:43 <michel-slm> missing packages are now exposed in CBS, are they not exposed to the EPEL builders yet?
20:09:53 <dcavalca> yeah that's a good call, I had the same issue with swtpm and a few other packages where the maintainer wasn't familiar with the flow
20:10:00 <michel-slm> nirik: agreed. I'll need someone to release the post I guess?
20:10:08 <nirik> michel-slm: I can do that.
20:10:21 <tdawson> michel-slm: missing packages are still missing, until they are in CBS.
20:10:25 <nirik> well, depends... which scheme are you refering to about missing devel packages?
20:10:31 <michel-slm> nirik++ I'll draft something up and file a ticket first so people can take a look
20:10:48 <michel-slm> let me dig up that infra ticket
20:10:57 <nirik> there have been so many
20:11:19 <dcavalca> tdawson: https://lists.centos.org/pipermail/centos-devel/2021-June/077081.html
20:11:28 <dcavalca> and https://lists.centos.org/pipermail/centos-devel/2021-June/077084.html
20:12:21 <tdawson> That is for the CentOS SIG's, not the EPEL buildroots.
20:12:25 <nirik> so epel8-next should build against stream and have them via that. epel8 has them via the centos 'Devel' repo only.
20:12:31 <carlwgeorge> i've been contemplating doing the same for epel8-next.  we can't do it for epel8 because the rhel8 buildroot isn't public.  i have two concerns:
20:12:40 <dcavalca> tdawson: correct, this is just for CBS
20:12:43 <carlwgeorge> 1. inconsistency between epel8 and epel8-next
20:12:49 <michel-slm> ah... got it.
20:13:03 <carlwgeorge> 2. losing access to flattened modular content that isn't in the buildroot
20:13:14 * michel-slm grumbling about how Matrix encrypted search is ... not working
20:13:19 * nirik is really really starting to think we should just do the 'make a epel package and build the devel part' because it does not depend on others and it's very easy to see whats going on.
20:13:41 <tdawson> nirik That is exactly what I'm doing
20:13:45 <carlwgeorge> 2 is only a theoretical problem
20:13:59 <tdawson> In addition to opening a bugzilla requesting the package be put in CRB.
20:14:07 <nirik> tdawson: ok.
20:14:35 <tdawson> When we get to that part of the meeting I was going to propose that.
20:14:44 <michel-slm> when EL9 comes out... epel9-next will be fine, but would epel9 builders have access to the unshipped packages?
20:14:50 <dcavalca> nirik: how does that work in practice? do we need to file review requests for new foo-epel packages?
20:15:02 <carlwgeorge> dcavalca: nope, they're exempt
20:15:10 <dcavalca> oh nice
20:15:16 <dcavalca> ok, that makes it more practical for sure then
20:15:20 <carlwgeorge> third bullet https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
20:15:23 <tdawson> I should have gotten an email written up before the meeting, I just ran out of time.
20:15:35 <nirik> epel9 would build against released rhel9... so no, it wouldn't have any unshipped packages
20:16:40 <michel-slm> ah. so... ideally we do get a proper fix then, though -epel packages are probably fine as a workaround for now
20:17:22 <nirik> the main problem with the epel versions is that they need to be kept in sync with the rhel versions...
20:17:31 <nirik> other than that they should work just dandy
20:17:37 <tdawson> Summary of my proposal:  Two steps.  1 - create a <package>-epel package that only has the missing sub-packages.   2 - open a bugzilla requesting the missing package be put in CRB.
20:18:11 <tdawson> Correct, which is why I think if people make <package>-epel packages, they should add the SIG as a co-maintainer
20:18:12 <michel-slm> tdawson: one problem ... once they get in CRB, how do we remember to retire the -epel package?
20:18:39 <dcavalca> conversely, if the bugzilla gets summarily closed, this does mean we need to maintain the -epel package forever
20:18:42 <michel-slm> when it comes to duplicate packages, I know we talked about automating the process to find and retire them from epel. can we make sure it also cope with -epel packages?
20:18:44 <tdawson> michel-slm: That's a good problem :)  ... and it shouldn't be too hard to check.
20:18:50 <dcavalca> which is probably fine, but something to keep in mind
20:18:51 <carlwgeorge> michel-slm: by the maintainer paying attention to the bug they filed
20:18:53 <tdawson> dcavalca: Yes
20:19:16 <nirik> this sounds like it needs a detailed process page. ;)
20:19:25 <tdawson> Thus far, this week I've opened 3 bugzilla's requesting packages be put in CRB, and all three of them have had a yes.
20:19:40 <tdawson> nirik Ya, that's why I want to send an email.
20:19:48 * nirik nods
20:20:15 <tdawson> In fact, two of those three bugzilla's, the maintainers had previously asked to have their packages put in CRB, and were surprised that the policy had changed, so they were glad to put them in.
20:20:16 <dcavalca> https://bugzilla.redhat.com/show_bug.cgi?id=1955820 was less lucky
20:20:38 <dcavalca> same for https://bugzilla.redhat.com/show_bug.cgi?id=1868430
20:21:04 <michel-slm> a bit of a segue but this is part of the reason we ideally have something like 'eln-extras'. so we have a set of dependencies we know to ask RH to include in CRB :)
20:21:24 <michel-slm> is it going to be called CRB in C9? instead of powertools? the name being synced is nice
20:21:46 * nirik doesn't think the names will change
20:21:51 * dcavalca still wonders how did they end up picking CRB as the name for this in the first place...
20:22:03 <carlwgeorge> dcavalca: personally i'd reopen the libteam-devel one, that response seems just like they don't understand it's a request to ship it
20:22:37 <carlwgeorge> saying "we don't ship it" is just restating the problem, and isn't the same as "we won't ship it"
20:22:41 <dcavalca> yeah, lemme try that and link a reference
20:22:44 <nirik> dcavalca: well, "code ready builder" is sort of marketing, but also sort of 'you can build your stuff from it, but we don't support it'
20:22:53 <tdawson> dcavalca: Also, when you open the bug, make sure you say what EPEL package it is for.   Not a CentOS SIG package.
20:22:56 <michel-slm> maybe having a template for requesting this and a tracker bug will be useful?
20:23:07 <carlwgeorge> michel-slm: yes, aligning on crb
20:23:18 <tdawson> I don't want to shout it, but yes, EPEL is getting a higher priority on these CRB bugs.
20:23:21 <michel-slm> so the assignee can see related bugs and get a broader context
20:23:24 <dcavalca> tdawson: oh yeah, I'll track that down
20:23:36 <dcavalca> tbh both of these were a while ago and we'd kinda moved on, I just remembered now
20:23:40 <carlwgeorge> centos choose powertools for 8 because they were told they couldn't use "codeready-builder", but apparently using just the acronym crb is ok for 9
20:23:46 <michel-slm> carlwgeorge: aha, I thought I saw a mention of crb in the cs9 context
20:24:01 <michel-slm> lol, so crb is fine but codeready-builder is not ;). ah trademarks
20:24:08 <nirik> thats... silly, but whatever.
20:24:15 <tdawson> Ya, if these are old, try re-opening them.  This change in policy is only about 6 months old.
20:24:51 <tdawson> I'll send out an email with more details.
20:25:14 <tdawson> Looks like I sorta de-railed the SIG part of the meeting, any other SIG specific things?
20:26:11 <carlwgeorge> i don't like josh's answer in the libuser-devel one.  he seems to be under the impression the stream buildroot being public will fix the problem for epel, and it doesn't.
20:26:49 <michel-slm> I also derailed it ... so no, nothing else. I have something I want to bring up for epel-next after carlwgeorge is done
20:27:55 <pgreco> I don't think anybody that's not an actual epel packager understands this problem
20:28:03 <tdawson> carlwgeorge: I agree with you ... but I'm still moving on to the next subject of the meeting.
20:28:10 <dcavalca> carlwgeorge: I've reopened https://bugzilla.redhat.com/show_bug.cgi?id=1955820
20:28:25 <tdawson> epel-next ... what's next :)
20:28:53 <michel-slm> carlwgeorge: we need a diagram showing the flow somewhere, because... I labored under that false impression too
20:29:21 <carlwgeorge> well epel8-next is live.  i added more items to https://fedoraproject.org/wiki/EPEL_Next#FAQ based on twitter comments, but nothing else from me on the topic.  would love to hear how it's working for people.
20:29:39 <tdawson> I love epel8-next
20:29:58 <michel-slm> working fine for me for nextcloud-client. note: I don't use KDE so haven't tried the KDE rebuild
20:30:07 <carlwgeorge> some people still whined about it not being called epel-stream :P
20:30:31 <nirik> 💖
20:30:40 <michel-slm> one problem is... the combination of CS8 + EPEL-next + *ahem* some third party repo is not that great at the moment. should we reach out to said third party repo and encourage them to do their own epel8-next?
20:30:40 <tdawson> carlwgeorge: In the past two days I've gotten multiple requests for a timeline of epel9-next.  I don't want to rush you, but do you have even a rough idea of when that can/will start getting worked on?
20:31:19 <michel-slm> tdawson++ I'm also interested, I'll start testing cs9+epel9-next as soon as the former is signed and the latter is available
20:31:19 <nirik> michel-slm: someone can sure...
20:31:42 <carlwgeorge> nothing stopping us at this point, other than deciding how we set up epel9 (which should at least be partially set up i think as part of epel9-next standup)
20:31:57 * michel-slm will reach out to that third party repo (unofficially)
20:32:35 <dcavalca> yeah, c9s not being signed is kinda blocking everything for us at the moment
20:32:47 <dcavalca> but happy to start testing epel9-next too as soon as that's resolved
20:33:02 <carlwgeorge> i'm happy to set up a pow-wow with nirik and any other releng folks to come up with the plan
20:33:13 <nirik> sure
20:33:34 <carlwgeorge> i think epel9-next is the right place to try out using the stream buildroot as the epel buildroot
20:34:01 <tdawson> That sounds like the easiest / best place to try it out.
20:34:09 <carlwgeorge> if it works as expected there, i'd have more confidence in switching epel8-next to a similar set up
20:34:28 <carlwgeorge> but i'm not interested in changing up epel8-next until epel9-next is up and running
20:34:44 <dcavalca> seems reasonable
20:35:00 <tdawson> Yep
20:35:32 <tdawson> Anything else -next related?
20:35:50 <michel-slm> this will buy us time until epel9 is needed, I guess, to sort out the -devel issue
20:35:57 <carlwgeorge> nothing from me
20:36:56 <tdawson> I didn't see any changes to the badges and logo's ... do we want to discuss that this week?
20:37:35 <tdawson> I'll take that as a no. :)
20:37:40 <carlwgeorge> i don't know what's next there, maybe we're waiting on mo to weigh in
20:37:53 <tdawson> I don't know either.
20:38:49 <tdawson> I'm leaning toward the e in the bubble ... maybe if I make that into an SVG that would help them decide.
20:39:14 <tdawson> I'm just a little busy this week so I don't see me being able to do that for a bit.
20:39:54 <tdawson> #topic EPEL-7
20:39:55 <carlwgeorge> i don't love the repeat of the e, as it would read left to right as eepel
20:40:10 <carlwgeorge> but i don't have a better suggestion for what would go in the bubble
20:40:39 <tdawson> Well, the fedora logo is technically an f in the bubble, and people don't read ffedora
20:41:02 <carlwgeorge> yeah true, good point.  but it is a different f, so maybe we could do some kinda of differently styled e
20:41:27 <tdawson> good point ... let me get it into svg format (so it scales) and see what we can do.
20:42:00 <tdawson> Anything for epel7 ?
20:42:21 <carlwgeorge> i pushed that fluidsynth update
20:42:22 <tdawson> Although I saw a couple of epel7 questions go by, I think all of them were resolved weren't they?
20:42:45 * michel-slm notes "Extra Extra" is also kind of catchy so no problem there :)
20:43:14 <pgreco> michel-slm: you need to be of a certain age to understand that, but ok ;)
20:43:27 <tdawson> Yep, to both carlwgeorge and michel-slm
20:43:45 <tdawson> #topic EPEL-8
20:44:00 <tdawson> Anything for epel8 ... other than missing packages
20:44:14 <tdawson> And yes, I have it on my list of things to do to send an email with my proposal
20:44:18 <carlwgeorge> i added python3-docker to epel8 if anyone needs it
20:44:40 <michel-slm> pgreco: I just outed myself as being old again, haven't I
20:45:00 <tdawson> That's right ... they totally pulled docker from RHEL8
20:45:26 <tdawson> Ha! ... if you are having kids, and not grandkids ... you're still a young'un
20:46:10 * tdawson notes that I don't have grandkids
20:46:26 <tdawson> #topic General Issues / Open Floor
20:47:00 <tdawson> I do have one new thing, EPEL Policy for Orphan and Retired Packages ...
20:47:07 <tdawson> .epel 113
20:47:13 <zodbot> tdawson: An error has occurred and has been logged. Please contact this bot's administrator for more information.
20:47:17 <tdawson> :)
20:47:24 <tdawson> https://pagure.io/epel/pull-request/113
20:47:41 <tdawson> Ohh ... that's a pull request, not an issue ... no wonder it didn't work.
20:48:14 <nirik> yeah, just moving it under epel...
20:48:36 <tdawson> Before I, or someone else, merged it, I just wanted to make sure everyone was ok with it.
20:49:01 <nirik> +1 here...
20:49:12 <tdawson> So, technically it's still the same, just we're actually saying "we're doing what they do"
20:49:16 <nirik> but of course we still need to move most of our docs right?
20:49:21 <tdawson> +1 from me too
20:49:32 <tdawson> Yep, still need to move the docs.
20:49:36 <dcavalca> +1
20:49:36 <pgreco> yeah, all good
20:49:43 <pgreco> +1 to be formal
20:50:39 <michel-slm> we... use rst rather than adoc?
20:50:42 <michel-slm> but +1 on content
20:51:07 <nirik> the epel docs in pagure.io use rst...
20:51:20 <nirik> if we someday move docs to docs.fedoraproject.org it's adoc I think.
20:51:28 <nirik> and then we have a bunch of things in the wiki
20:52:15 <tdawson> #info Officially adopting Fedora's policy for Ophaned and Retired Packages as stated in https://pagure.io/epel/pull-request/113 :   6(+) 0(-)
20:52:41 <carlwgeorge> i commented on the pr, but +1 from me too
20:53:49 <tdawson> Awsome ... let's merge it, and if it needs to be cleaned up, or added to a different page when we do our migration, we can do that.
20:54:16 <tdawson> Anything else for Open Floor?
20:54:39 <dcavalca> michel-slm and I have some fun rust packaging stuff to take care of
20:54:51 <dcavalca> do folks have objections to vendoring rust dependencies in epel8?
20:54:58 <dcavalca> or is there a saner way to deal with it?
20:55:07 <michel-slm> oh yeah, Rust
20:55:17 <tdawson> Personally ... I prefer vendoring
20:55:22 <michel-slm> if there's no objection we'll start with a package that we maintain anyway
20:55:23 <carlwgeorge> vendoring is the only sane way to do rust or golang stuff in epel
20:55:33 <nirik> sadly true
20:55:33 <dcavalca> specifically, we'd love to get https://bodhi.fedoraproject.org/updates/FEDORA-2021-beb9227946 in EPEL, but as you can see the dep stack is insane
20:56:01 <dcavalca> is there an example we can follow for this?
20:56:27 <tdawson> Are there any RHEL 8/9 rust packages that we can use as an example?
20:56:55 <tdawson> I know that Fedora rust prefferes all the small packages, but RHEL does bundling.
20:57:33 <michel-slm> tdawson: we're wondering if anyone knows of an example too
20:57:34 * nirik doesn't know any example off hand
20:58:00 <michel-slm> IIRC it came up in a mailing list somewhere, with a Rust maintainer complaining that there were changes some RH engineers made for EL
20:58:36 <tdawson> Ya, it's one of the places RHEL and Fedora butt heads together
20:58:43 <nirik> stratisd ?
20:59:19 <dcavalca> thanks nirik, I think that works
20:59:28 <tdawson> Yaaa ... That was one
20:59:35 <nirik> not sure, just a total guess. ;)
20:59:56 <dcavalca> we'll try doing the same for below and if that goes alright we can put it up as an epel example
21:00:44 <tdawson> Yep, stratisd has a vendor.tar.gz source
21:00:58 <tdawson> Huh ... it would have been nice if they'd put how they made the source. :(
21:01:08 <michel-slm> ideally there's some tooling around this so we at least know vendor.tar.gz is generated in a sane way
21:01:14 <michel-slm> tdawson: yeah :p
21:01:27 <michel-slm> well, we can do that part for below, at least
21:01:46 <tdawson> Looks like our time is up
21:01:55 <dcavalca> I've requested the epel8 branch now, we'll keep you posted: https://pagure.io/releng/fedora-scm-requests/issue/35416
21:02:04 <michel-slm> dcavalca: thoughts on having the script be available in a repo, and list it as a SOURCE so people can repro?
21:02:10 <tdawson> Thank you everyone for being here, and for the good discussion we had, as well as all the work ya'll have done during the past week.
21:02:14 <michel-slm> tdawson++ thanks for chairing as usual
21:02:17 <dcavalca> michel-slm: yeah, we should do that
21:02:18 <tdawson> I'll talk to you next week.
21:02:19 <dcavalca> thanks tdawson
21:02:24 <michel-slm> happy long weekend everyone
21:02:29 <dcavalca> yay
21:02:34 <tdawson> #endmeeting