22:01:54 <tdawson> #startmeeting EPEL (2021-02-12)
22:01:54 <zodbot> Meeting started Fri Feb 12 22:01:54 2021 UTC.
22:01:54 <zodbot> This meeting is logged and archived in a public location.
22:01:54 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
22:01:54 <zodbot> The meeting name has been set to 'epel_(2021-02-12)'
22:01:55 <tdawson> #meetingname epel
22:01:55 <zodbot> The meeting name has been set to 'epel'
22:01:57 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel_slm
22:01:57 <zodbot> Current chairs: bstinson carlwgeorge michel_slm nirik pgreco tdawson
22:01:58 <tdawson> #topic aloha
22:02:00 <michel_slm> .hello salimma
22:02:00 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
22:02:12 <tdawson> Hi michel_slm
22:02:25 <pgreco> hi everybody
22:02:35 * nirik waves
22:02:36 <michel_slm> https://open.spotify.com/track/4K58jo44RGM8RrtzT8PvRw?si=tv-XfcE8QvKXNOUpciFH0Q
22:02:40 <tdawson> Hi pgreco
22:02:47 <tdawson> Hi nirik
22:03:10 * King_InuYasha waves
22:03:10 <michel_slm> hello all!
22:03:12 <King_InuYasha> .hello ngompa
22:03:13 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
22:03:16 <tdawson> Hi King_InuYasha
22:03:45 <carlwgeorge> howdy everyone
22:03:53 <smooge> hello
22:04:00 <tdawson> Hi carlwgeorge
22:04:02 <tdawson> Hi smooge
22:04:17 <tdawson> Wow, we have a full house today.
22:05:03 <tdawson> #topic Old Business
22:05:14 <tdawson> Let's start with the EPEL Packaging SIG
22:05:24 <tdawson> michel_slm: How are things going with the SIG?
22:05:44 * tdawson notes that he still hasn't worked on his template yet.
22:05:54 <michel_slm> #info salimma did a PR to allow collaborators to request branches https://pagure.io/fedscm-admin/pull-request/61
22:06:25 <michel_slm> I don't have full Pagure API access, but in some playing around with IPython it does the right thing, and tests all pass
22:07:08 <michel_slm> not sure who to thank on the Pagure side, because someone did write a new API endpoint that this consumes (didn't have time to git blame yet)
22:07:50 <nirik> thanks for working on this michel_slm
22:08:00 <carlwgeorge> yeah this is good stuff
22:08:47 <michel_slm> np! EL9 branching is nigh and I want to get this smoothly working before then
22:09:01 <tdawson> michel_slm: Definatly, thank you for this.
22:09:54 <tdawson> Does this mean that we can now give people access to just "epel" and/or "epelX" instead of "everything"
22:10:41 <michel_slm> tdawson: once it's live, yes!
22:10:54 <michel_slm> well, epel* ideally
22:10:57 <michel_slm> it does globbing
22:11:02 <tdawson> That's what I was hoping.  Ya!!
22:11:16 <tdawson> michel_slm++
22:11:16 <zodbot> tdawson: Karma for salimma changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
22:11:25 <pgreco> michel_slm++
22:11:25 <zodbot> pgreco: Karma for salimma changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
22:11:26 <King_InuYasha> sweet
22:11:27 <michel_slm> also thanks to King_InuYasha who insisted on not giving epel-packagers-sig commit access on his python-pystemd :D
22:11:41 <King_InuYasha> haha
22:11:56 <King_InuYasha> I'm glad my wariness led to good solution :)
22:12:32 <michel_slm> yeah. we filed the issue months before but that prodded me into "hmm, let's just do it ourselves"
22:12:39 <michel_slm> nothing else from me
22:12:49 <carlwgeorge> alright thanos :D
22:13:01 <tdawson> michel_slm: Thanks again, that was a wonderful thing to report.
22:13:14 <smooge> so I have something for the sig but it can come under NB
22:13:33 <King_InuYasha> same here
22:13:46 <tdawson> smooge: OK, you'll be first for new business ... and King_InuYasha, you get second.
22:13:48 <michel_slm> carlwgeorge: do I get to "disappear" half the bugs now that I'm thanos? :D
22:14:06 <tdawson> Moving on to epel-next ... carlwgeorge how is that coming along?
22:14:24 <tdawson> Ha!
22:14:36 <carlwgeorge> still focused on fedpkg changes, went ahead and put my WIP up https://pagure.io/fedpkg/pull-request/429
22:15:09 <carlwgeorge> needs a bit more before it's ready, and i also need to get with smooge about generating the json file with cs8 packages
22:16:45 <carlwgeorge> so progress (although not as much as i wanted, per the usual)
22:16:53 <michel_slm> \o/
22:16:58 <carlwgeorge> day job keeping me busy as always
22:17:08 <tdawson> Some progress is better than no progress.
22:17:25 <michel_slm> would be nice for Pagure to have an explicit draft-vs-published mode for PRs
22:17:47 <carlwgeorge> a WIP prefix is pretty well understood, right?  should i add a comment not to merge yet?
22:17:51 <michel_slm> that looks quite good, what's missing from this?
22:17:59 <michel_slm> nah, I think it's fine
22:18:15 <pgreco> gitlabl blocks merging on PRs prefixed by WIP or Draft
22:18:20 <carlwgeorge> i'll probably concurrently work on the epel8-next mock root to remove that TODO
22:18:33 <pgreco> which I think is nice
22:18:36 <carlwgeorge> and i need to work in the stuff for checking said json file like epel does for rhel rpms
22:19:51 <carlwgeorge> actually that mock root won't make sense until epel8-next exists, so i'll kick that can down the road
22:20:45 <carlwgeorge> that's it for epel next, we can move on
22:20:59 <nirik> https://pagure.io/pagure/issue/4426
22:21:07 <nirik> (rfe for not ready to merge for pagure)
22:21:34 <tdawson> OK, next on old business was documentation changes - wiki to Fedora style
22:21:51 <carlwgeorge> that's me, no progress to report
22:22:03 <tdawson> carlwgeorge: sounds good
22:22:17 <tdawson> Next was getting ready for RHEL9
22:22:18 <carlwgeorge> if anyone wants to dig into that one, be my guest, otherwise it's fine in my personal backlog
22:22:29 <michel_slm> can we start by putting a filler page up?
22:22:43 <michel_slm> I can convert the packagers SIG page but need to know where it should go :)
22:23:05 <tdawson> That's a good point.  It would allow us to do things once page at a time.
22:23:11 <smooge> so the epel on pagure has a git
22:23:32 <smooge> https://pagure.io/epel/
22:24:01 <carlwgeorge> i'm thinking a new top level page here https://docs.fedoraproject.org/en-US/docs/
22:24:03 <smooge> https://pagure.io/epel/blob/master/f/docs was my first attempt before I ran out of goto juice
22:24:17 <smooge> well that is where it goes eventually but you need a place where they eat it from
22:24:33 <carlwgeorge> or we can to a subpage of the fedora guidelines like https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
22:24:47 * nirik did the last wiki page revamp so many years ago... I thought the structure was good then (I'm sure it's decayed some)
22:25:21 <michel_slm> seems like we need both - for the SIG etc. maybe a new docs repo under pagure.io/epel, but for packaging guidelines putting it in the existing repo makes sense?
22:25:27 <nirik> I had a main page, then branching off that was 'for users' 'for maintainers' etc... so packaging was a subpage off maintainers, etc.
22:25:34 <smooge> so michel_slm carlwgeorge I would suggest putting the asciidoc or html or whatever code in the git repo
22:25:50 <smooge> then it can be fed into the docs when they want it
22:25:55 <carlwgeorge> seems the separate repo would only be needed if we made it a top level doc
22:26:04 <michel_slm> oh shoot, pagure.io/epel is a repo and not a group
22:26:06 <carlwgeorge> if it's a subpage it would go into https://pagure.io/packaging-committee
22:26:13 <tdawson> I think EPEL is more than packaging guidelines, I'd rather it have it's own area, a https://docs.fedoraproject.org/en-US/epel/  (which doesn't exist)
22:26:30 <nirik> in the past the packaging comittee has wanted epel to handle epel specific packaging rules.
22:26:39 <michel_slm> have a docs/ folder in the git repo?
22:26:49 <nirik> and yes, there's much more than that... how to enable, packaging process, etc
22:26:51 <carlwgeorge> well the original context of this was moving epel-specific guidelines to the fedora guidelines
22:27:18 <nirik> I thought it was moving all our stuff off the wiki. ;) But perhaps that was my mistake
22:27:25 <michel_slm> https://pagure.io/epel/tree/master
22:27:34 <michel_slm> huh, bstinson, Jim Perrin and ... who's Avij
22:27:36 <carlwgeorge> i have no problem with that, but i'd like to take a smaller bite to start with
22:27:41 <carlwgeorge> just the guidelines
22:27:56 <pgreco> michel_slm: Avij is a former member here
22:27:57 <carlwgeorge> i.e. put in the fedora guidelines the ways epel diverges
22:28:00 <michel_slm> nirik: I was under that impression too, so maybe... we can split and carve up the wiki
22:28:02 <pgreco> emeritus still
22:28:32 <nirik> carlwgeorge: well, if the packaging comitte is ok having those in their space, great!
22:28:37 <michel_slm> re: EPEL gets to decide EPEL policy, I guess if we document that in the packaging-committee repo we should explicitly state that so people don't get confused
22:29:10 <michel_slm> might make more sense for packaging committee to have a stub page that points to our docs?
22:29:13 <tdawson> One downside of having it in the packaging-committee area is any change has to not only get approved by us, but also by them
22:29:56 <tdawson> But I agree, we at least need a stub, or some page, that points to the EPEL pages, if we decide to have it in our area.
22:32:28 <tdawson> I assume everyone is looking at all the various documentation about documentation.
22:33:07 <smooge> in the past the packaing committee people did not want ANYTHING EPEL related in their stuff.
22:33:32 <smooge> however times change and people want to work on that .. I am ok with it
22:33:36 <tdawson> Does anyone want to take on figuring out what it takes to get us a base docs directory - https://docs.fedoraproject.org/en-US/epel/   ?
22:34:06 <smooge> well from the past, we need to have a base GIT repo they will point to
22:34:29 <carlwgeorge> there already is a stub link in the sidebar of the fedora packaging guidelines
22:34:30 <tdawson> Which, I believe we have ... although it might be in the wrong format.
22:34:51 <michel_slm> tdawson: I can start getting to the point where we can build documentation locally from our git repo
22:35:03 <smooge> it is in the wrong format. i was playing chase the format (rst first, then somehting else then md)
22:35:14 <carlwgeorge> i brought it up at the fpc meeting, everyone was fine with it
22:35:21 <smooge> carlwgeorge, cool
22:35:38 <michel_slm> probably worth doing regardless of where the packaging guidelines will live, since we still need other docs too
22:35:57 <tdawson> michel_slm: Yep
22:36:13 <carlwgeorge> most fedora packaging guidelines apply to fedora, and then we just have a relatively small list of exceptions
22:36:22 <tdawson> michel_slm: If you can take that, that would be great.  We can then work on the wiki pages, one page at a time.
22:36:43 <carlwgeorge> and those exceptions are time-bound, i.e. this guideline doesn't work on el7 because of too old of rpm version
22:36:56 <michel_slm> alrighty. that sounds more fun than deep-diving into Anaconda
22:37:30 <carlwgeorge> i have to run in a few minutes, can i squeeze in my new business first?
22:37:33 <tdawson> carlwgeorge: Yep.  I think it's ok to have it in either, but just one.  So if it's in the packaging guidelines place, we can have a stub in the EPEL area, or vice versa.
22:37:39 <tdawson> carlwgeorge: Sure thing.
22:38:28 <carlwgeorge> tdawson: you mentioned the rhel checklist for adding packages.  does that include filing a bugzilla to notify the epel maintainer?
22:39:11 <carlwgeorge> i just built tracer for cs8 today, meaning it will likely be in rhel 8.4.  it's in epel8 already.  the nvr happens to work out, but only if the epel maintainer doesn't bump the release again before it hits rhel.
22:39:15 <tdawson> carlwgeorge: No, they do not file a bugzilla, only contact them via email.
22:39:50 <carlwgeorge> here's the rhel addition bug (private) if you want to poke and prod https://bugzilla.redhat.com/show_bug.cgi?id=1913235
22:40:01 <smooge> that was because of the GREAT WALL OF DISINFORMATION. Now that Stream is a thing, I think we could file bugz when this happens
22:40:04 <tdawson> carlwgeorge: If you want, I could ask them to file a bugzilla.  I think it's a good idea, because then we could use it to track packages needing to be taken out.
22:40:09 <carlwgeorge> do you think that process can be changed from email to bugzilla?
22:40:09 <pgreco> carlwgeorge: did you bulid it just as a BR for something else or as a real release rpm?
22:40:26 <carlwgeorge> new rpm
22:40:39 <pgreco> ack
22:40:43 <nirik> bugzilla would definitely be better than email
22:40:57 <nirik> and perhaps we could have a tracker and have them all block that.
22:41:01 <carlwgeorge> tdawson: yes please
22:41:07 <tdawson> carlwgeorge: I'll ask them.  They were concerned about not getting to the right people, and I think a bugzilla would be best.  We'lll see if they agree.
22:41:29 <carlwgeorge> if a maintainer is not getting notified of their bugzillas, we have bigger issues
22:41:42 <tdawson> carlwgeorge: OK, I've written it down.  I'll contact them and ask.
22:41:49 <tdawson> carlwgeorge: Anything else before you go?
22:41:53 <michel_slm> for the current mechanism (via email) do they email $<pkg>-maintainers@fp.o or just $<pkg>-owner@ ?
22:42:09 <tdawson> $<pkg>-owner@
22:42:20 <michel_slm> ah. that could be a problem
22:42:26 <tdawson> Ya
22:42:26 <carlwgeorge> nope.  i'll catch up on the backlog later.  see yall!
22:42:31 <nirik> those are the same. ;)
22:42:40 <michel_slm> wait, those are? ah ok
22:42:51 <tdawson> Thus, if they do open a bug, and do it consistently so we can search for them, it will be much better.
22:42:54 <nirik> but still... emails get lost, maintainers change, bugs would persist, but emails are gone
22:43:17 <tdawson> michel_slm: OK, actually it's not $<pkg>-owner@ ... they do a search for the EPEL package maintainer, and send directly to them.
22:43:35 <michel_slm> ouch, so yeah that's worse
22:44:03 <tdawson> Yep ... it's better than nothing, and they at least have a step in for that, so hopefully they are open to suggestions.
22:44:04 <michel_slm> (thinking of packages where the people doing the work are not necessarily the ones officially marked as POC)
22:44:41 <tdawson> It's getting late in the meeting, and smooge and King_InuYasha both had new business, so I'm going to skip all the way to them.
22:45:08 <tdawson> smooge: The floor is yours, unless King_InuYasha beats you to it.
22:45:11 <smooge> so there was a thread on the list about what was needed to get an EPEL release
22:46:03 <nirik> yeah, if we require epel to be 'self maintaing' or not I guess.
22:46:19 <smooge> the package list in the past was get fedpkg into the release. The python maintainers would like us not to do that anymore since they do not wish to maintain EPEL packages. I was thinking these packages would be something the EPEL sig needs to 'own'
22:46:47 <tdawson> smooge: I agree.
22:46:49 <smooge> I forced fork them for EL8 and caused some problems because of that
22:47:28 <nirik> we could just start epel9-next without it...
22:47:42 <nirik> and/or epel9
22:48:20 <michel_slm> epel-packagers-sig can own it I guess?
22:48:36 <smooge> personally if I didn't have a fedpkg I could use on CentOS, I would not have packaged for EPEL.
22:49:19 <tdawson> We could.  But I think fedpkg, along with it's dependencies, is something that the SIG aught to try for.  Find the list of build/run dependencies, and ask each of the maintainers if they wouldn't mind if the SIG co-maintained with them.
22:49:31 <nirik> I think its something important to have, but perhaps not at launch... as many people will be on the previous release then?
22:49:42 <nirik> tdawson: +1
22:50:20 <michel_slm> agreed, as long as it's on epel8 it's probably fine if it's not initially on epel9
22:50:26 <pgreco> is there any breaking changes in rpm for 9? something that 8 wouldn't understand?
22:50:40 <pgreco> like happened in 7/8 with suggests/recommends
22:50:41 <michel_slm> err... where's this discussed? I can't find it on epel-devel and devel
22:50:54 <michel_slm> pgreco: the IMA signatures would have be a breaker but that's postponed
22:51:19 <tdawson> michel_slm: It's on the thread "Proposal: EPEL9 timeline"
22:51:21 <nirik> the sqlite change? but thats not directly affecting the rpms...
22:51:46 <michel_slm> tdawson: thanks
22:51:52 <pgreco> I'm mostly thinking about specfiles
22:51:54 <nirik> otherwise I can't think of anything, but there could be something
22:52:45 <pgreco> you need to go through certain hurdles to build a local srpm for c8 if you're using c7
22:52:46 <tdawson> If nobody beats me to it, I'll take on getting the list of packages needed for fedpkg ... I think it would be easiest to send it via email, possibly on that thread, or start a new thread.
22:53:04 <smooge> that was all from me
22:53:11 <michel_slm> go King_InuYasha
22:53:22 <tdawson> King_InuYasha: you are up
22:53:26 <smooge> I can look at it this weekend
22:54:08 <King_InuYasha> yeah
22:54:27 <King_InuYasha> so I wanted to ask if anyone could help with bringing poetry to epel8?
22:55:07 <King_InuYasha> I'm trying to package up the fedora-aaa stack, which requires poetry for *everything*
22:55:07 <tdawson> smooge is good with puns, are they good enough?
22:56:02 <smooge> ... is killing his laptop with a giant graphviz
22:56:09 <nirik> King_InuYasha: might ask on the epel-devel list? I assume the fedora maintainer doesn't want to?
22:56:31 * nirik started to try and making a 'oh pointy birds' rhyme with epel, but decided not to.
22:56:32 <pgreco> King_InuYasha: I've been having some complicated weeks, but I could help track down the BRs
22:56:37 <King_InuYasha> yeah, mhroncok doesn't want to
22:56:38 <michel_slm> King_InuYasha: I tried looking at it for EPEL8 (for FedoraReview) and ... it's really difficult. I think because the RPM version is too old
22:56:47 <pgreco> many things missing?
22:57:13 <michel_slm> either poetry or some other dependencies. they explicitly need the new automatic BRs added in F33
22:57:31 <michel_slm> I think I documented this in the issue I filed for getting FedoraReview in epel, one sec
22:57:32 <King_InuYasha> well, I'm working on writing macros that don't require dynamic BRs
22:57:37 <nirik> ansible uses it for tests/docs in 2.10 too. ;(
22:58:30 <michel_slm> so I failed to update that bug, but this was my initial stab https://pagure.io/epel/issue/108
22:59:23 <michel_slm> I think pyproject is what won't be in epel8: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/143
23:00:38 <tdawson> Regarding this specific rpm ... for epel8 the person could take out the %generate_buildrequires and just hard code those into the spec file.
23:00:59 <tdawson> I know it takes longer, but that's what we used to do in the good old days of last week.
23:02:12 <tdawson> Looks like our time is up.
23:02:21 <michel_slm> I think any spec we want to target for epel8 will have to not use pyproject
23:02:25 <King_InuYasha> yes
23:02:31 <King_InuYasha> I'm working on %poetry_* macros
23:02:43 <michel_slm> so yeah, doable, a bit more work, and we'll have to diverge from rawhide
23:02:44 <tdawson> Thank you everyone for being here this week.  It's been a great discussion on all the various things.
23:02:49 <michel_slm> thanks tdawson !
23:02:58 <tdawson> We'll talk to you next week, if not sooner.
23:03:04 <pgreco> thanks, see you next week!!
23:03:09 <tdawson> #endmeeting