20:01:06 <tdawson> #startmeeting EPEL (2021-04-07)
20:01:06 <zodbot> Meeting started Wed Apr  7 20:01:06 2021 UTC.
20:01:06 <zodbot> This meeting is logged and archived in a public location.
20:01:06 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:06 <zodbot> The meeting name has been set to 'epel_(2021-04-07)'
20:01:08 <tdawson> #meetingname epel
20:01:08 <zodbot> The meeting name has been set to 'epel'
20:01:09 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel_slm
20:01:09 <zodbot> Current chairs: bstinson carlwgeorge michel_slm nirik pgreco tdawson
20:01:10 <tdawson> #topic aloha
20:01:16 <pgreco> hello!
20:01:19 <nirik> morning
20:01:20 <smooge> hello fellow computer algorithms
20:01:20 <cyberpear> o/
20:01:33 <tdawson> Hi pgreco
20:01:35 <dcavalca> .hi
20:01:35 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:01:35 <tdawson> Hi nirik
20:01:46 <tdawson> Hi smooge
20:01:52 <tdawson> Hi cyberpear
20:01:57 <tdawson> Hi dcavalca
20:02:05 <michel_slm> .hello salimma
20:02:06 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:02:19 <tdawson> Hi michel_slm
20:03:58 <tdawson> hmmm ... I wonder if carlwgeorge is going to be able to make it.
20:04:17 <carlwgeorge> i'm here
20:04:24 <tdawson> Hi carlwgeorge
20:04:57 <tdawson> #topic Old Business
20:05:06 <tdawson> Let's start with the EPEL Packaging SIG
20:05:44 <tdawson> Do we know if the code has been deployed yet?
20:06:46 <nirik> what part were we waiting for? fedscm-admin?
20:06:57 <nirik> or bodhi?
20:07:12 <michel_slm> bodhi, I think. fedscm-admin already allows collaborators to request branches
20:07:42 * michel_slm can't wait for that bodhi update, hopefully the code for gating non-installable updates is part of that release too
20:07:49 <dcavalca> yeah bodhi to allow collaborators to submit updates
20:07:50 <nirik> not yet on bodhi, but ryanlerch is stepping up to do a release soon.
20:08:08 <nirik> not sure if we will want to land it before f34, but perhaps...
20:08:41 <pgreco> I have a question that "may" be related to this before we move on to something else
20:09:13 <tdawson> pgreco: Sure thing, what's the question?
20:09:40 <pgreco> a few days ago I needed a package, IIRC it was something to relay USB devices over ip
20:09:59 <pgreco> the package builds pretty much without issues in epel
20:10:16 <pgreco> but it can't really be used, since the module is not enabled in RHEL
20:10:37 <michel_slm> pgreco: kernel module?
20:10:43 <pgreco> but if I build my own kernels, or use any of the CentOS additional kernels, it is there
20:10:51 <pgreco> michel_slm: yes, kernel, sorry
20:11:02 <michel_slm> if we can package that kernel module as an akmod that would be a nice solution
20:11:16 <pgreco> that was the second question hehe
20:11:35 <pgreco> the first one was if we have anything against me building that package, even though it doesn't work ootb
20:12:01 <tdawson> That's a good question.  My personal opinion is yes.
20:12:08 <michel_slm> curious what others think, I think it's fine
20:12:32 <tdawson> I am still maintaining the mongodb support packages, even though we don't have mongodb anywhere available.
20:12:42 <michel_slm> I maintain psi-notify including in EPEL, and ... technically it requires a newer kernel than the one in EL, but it turns out the PSI module it needs is included in EL but gated behind passing psi=1
20:12:58 <dcavalca> if the package installs and isn't outright harmful, I don't see a major issue
20:13:12 <nirik> I think the package would be fine.
20:13:19 <pgreco> perfect, that was my thought too
20:13:20 <michel_slm> "is the package usable" is a should in the review checklist
20:13:22 <nirik> kmods/akmods/dkmmods... no
20:13:26 <carlwgeorge> it sounds like your package would ideally have a requirement on a kernel module, and if that kernel module isn't resolvable in the distro or epel it's not allowed
20:13:41 <carlwgeorge> not even as a recommends
20:14:30 <pgreco> carlwgeorge: the package installs, because it doesn't do such a check
20:14:53 <nirik> does it log some kind of 'sorry, you need to insert module foo' message when you run it?
20:15:01 <pgreco> nirik: I may ask elrepo people to build the kmod if we reach that point
20:15:03 <michel_slm> huh, do we declare what kernel modules are available? (since we can't depend on a file - first because that's expensive and discouraged, and second because the module path will change per version)
20:15:16 <nirik> pgreco: yeah, they would be more up to doing that I bet...
20:15:24 <michel_slm> `rpm -q --provides kernel` seems to suggest we don't, but that's not a bad idea to start doing
20:15:30 <dcavalca> we could use virtual provides/requires I guess?
20:15:31 <nirik> it's a mess
20:15:54 <carlwgeorge> imo it hinges on if the kernel module is a hard requirement or not
20:16:15 <michel_slm> I guess you can say `%if %{?rhel} Requires: kmod-foo %end`
20:16:15 <pgreco> carlwgeorge: to work, yes, to install, no
20:16:26 <carlwgeorge> leaving out the spec file requirement just to follow the rules seems wrong
20:17:21 <michel_slm> can EPEL not ship akmods? (never tried so I don't know)
20:17:38 <nirik> having a requires in that case is probibly bad, because someone might self compile and their self compiled thing won't have the requirement
20:17:45 <carlwgeorge> "Requires MUST be used if the dependency is required for the software to function correctly." https://docs.fedoraproject.org/en-US/packaging-guidelines/#_dependency_types
20:17:49 <nirik> michel_slm: it cannot. No kmods in fedora or epel
20:18:08 <michel_slm> ah. hmm, a bit unfortunate
20:18:19 <michel_slm> but if there's a SIG for alternate CentOS kernels that can probably go there
20:18:20 <carlwgeorge> so if the software doesn't work without the kernel module, by the guidelines i think it's a no
20:18:47 <pgreco> carlwgeorge: a part of the tool doesn't, other parts do
20:18:52 <nirik> carlwgeorge: I think requires there is package requires no? not functionality requires.
20:19:21 <nirik> in any case perhaps copr would be a better place? it could package the akmod there...
20:19:23 <carlwgeorge> the guidelines explicitly say "software to function correctly"
20:19:28 <michel_slm> pgreco: so... sounds like you need to skip shipping the non-working part in epel
20:20:12 <pgreco> then it is a no, because that's the part I need
20:20:13 <michel_slm> nirik++ oh yeah, COPR does support EL8
20:20:18 <carlwgeorge> pgreco: if other parts work without the kmod, then i guess it meets the definition of "diminished capacity"
20:20:45 <tdawson> Ya, I'm thinking maybe copr is the correct place
20:20:54 <carlwgeorge> but you still can't put a recommends or suggests on a package that's not in rhel or epel, so a good warning would be really desired
20:21:19 <pgreco> I wouldn't put a dep on a kmod, because it may not be the real use case
20:21:26 * nirik nods
20:21:56 <pgreco> depending on a kernel module, that may or may not be, depending on the kernel that is being used is the real question
20:22:04 <pgreco> but from the guidelines, it looks like a no
20:23:21 <tdawson> So ... are we good here?
20:23:31 <pgreco> yeap, no, but yes ;)
20:23:35 <tdawson> :)
20:23:39 <carlwgeorge> i think the best solution would be reverse weak dep in the kmod, i.e. foo is the tool, kmod-foo supplements foo
20:24:15 <carlwgeorge> then if you have both packages available in your configured repos, installing foo brings them both in
20:24:17 <nirik> only if people who build their own kernels make rpms of them and the dep is there
20:24:39 <nirik> but yeah, if you provide both I guess
20:24:41 <tdawson> Relating to the sig, I only remembered that I had volunteered to create a page with a list of packages we are working on, which I didn't do
20:24:44 <michel_slm> right, but pgreco is one of those people who build kernels
20:25:02 <tdawson> But I'm wondering if I need to do that because we sorta have that here - https://src.fedoraproject.org/group/epel-packagers-sig
20:25:12 <michel_slm> tdawson: the tracker we're supposed to block the packages we care about is in the wiki, so maybe that's enough
20:25:59 <michel_slm> it does have some packages we haven't added the epel-packagers-sig to, partly because at the time the collaborator access wasn't enough (still not enough to push updates, I've had to use my provenpackager privilege a couple of times)
20:26:16 <nirik> I thought this was a wishlist? perhaps not?
20:26:37 <tdawson> michel_slm: Which page was that?
20:26:46 <michel_slm> the query for stale reviews is a wishlist, the tracking bug is the ones we decided we want
20:26:47 <michel_slm> one sec
20:27:05 <michel_slm> last sentence in https://fedoraproject.org/wiki/EPEL/Packagers#Workflow
20:27:19 <michel_slm> https://bugzilla.redhat.com/show_bug.cgi?id=EPELPackagersSIG <-- that's the tracker bug
20:27:56 <tdawson> Ah, ok.  I was on the right page, reading the wrong thing.
20:28:07 <michel_slm> dcavalca: should we add strongswan to that tracker? we both got commit access now, but not admin so we need to remember to get epel-packagers-sig added at some point
20:28:10 <nirik> sure, so thats a passive flow... did we want to have anything more active where we ask some maintainer(s) about packages they maintain? or just let it ramp up natually?
20:28:19 <dcavalca> michel_slm: I was just thinking the same
20:28:53 <michel_slm> nirik: I think we plan to have a template for requesting access at some point.
20:29:01 <michel_slm> do we want to start working on that or wait for the Bodhi update?
20:29:12 <nirik> might be nice to have everything landed first
20:29:42 <tdawson> Ya, I was thinking of waiting till the bodhi update it out.  It frustrates people when you have directions they can't use yet.
20:29:57 <dcavalca> I'd say once everything's landed let's setup a template, and then advertise that this is a thing
20:29:58 <michel_slm> +1
20:30:07 <nirik> sounds good
20:30:22 <michel_slm> anyone knows what the blocker is, and if we can volunteer to help?
20:31:00 <nirik> for bodhi?
20:31:15 <michel_slm> yup, for bodhi
20:31:45 <nirik> as noted: we now have someone who is collecting things up to do a release. That should hopefully happen in the next week or so... then we need to test in staging... then we need to decide if we can land it during f34 freeze or if it needs to be after.
20:32:10 <michel_slm> oh nice!
20:32:21 <nirik> so, no I think we are set on people, we may want testing tho...
20:32:30 <nirik> once its available in stg
20:33:25 <michel_slm> yeah. where will this be announced? devel, or test?
20:33:53 <tdawson> Is there an epel-test mailling list?
20:34:16 <nirik> infrastructure list for sure...
20:34:22 <nirik> tdawson: nope
20:34:34 <michel_slm> hm. epel-devel, I guess, but presumably other changes might be of interest to the wider Fedora community too
20:34:34 <nirik> we could also ask for testing on epel-devl
20:34:42 <nirik> or devel. sure
20:35:06 <nirik> One problem is that staging isn't as complete as prod... so might not be able to test end to end there.
20:36:14 <tdawson> So, to move things on, are we done with SIG stuff?
20:36:33 <michel_slm> yeah. wow, 36 past
20:37:00 <tdawson> OK, on to epel-next ... carlwgeorge do you have a status report on that?
20:39:08 <tdawson> I saw that carlwgeorge's pull request was being worked on.  There were a few comments that he fixed.
20:39:20 <tdawson> But I don't think I've seen a merge yet.
20:39:28 <tdawson> This is for fedpkg
20:40:18 <smooge> i have not seen anything move on it
20:40:32 <tdawson> Outside of fedpkg, does anyone know how close we are to having things ready?  Do we have repo's and various other infrastructure stuff setup?
20:41:26 <tdawson> Let's move back to this when carlwgeorge returns.
20:41:28 <carlwgeorge> the fedpkg maintainer added one commit of the pr to the package, and it's already in -testing
20:41:35 <nirik> I think we are mirroring c8s now.
20:41:55 <tdawson> cool
20:41:58 <nirik> we still need to create tags/targets/addtobodhi/etc
20:42:05 <carlwgeorge> yup, mirroring is already done.  next step is to set up tags and the build target in koji
20:42:36 <carlwgeorge> i need either nirik or mboddu to do that i believe, when they are available
20:43:19 <nirik> perhaps next week, if people would stop filing new tickets. :)
20:44:01 <tdawson> It's looking close.  I'm excited for it.
20:44:02 <pgreco> nirik, if you find an option to do that, let me know, it will come handy at work :)
20:44:08 <carlwgeorge> is that the trick, file a ticket? :P
20:44:10 <smooge> I found it
20:44:49 <smooge> sorry wrong chan
20:45:16 <pgreco> smooge: thought you had found the option to stop people from filing tickets to your name, I wanted in on that ;)
20:46:21 <tdawson> Anyone mind if I move on to the next old business, EPEL Fails-To-Install
20:46:35 <nirik> please drive thru...
20:47:13 <tdawson> So, I actually made some pretty good progress on the code, possibly even having it work.  But I don't really have a way of testing.
20:47:26 <michel_slm> test-in-production :)
20:47:28 <tdawson> https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
20:47:45 <carlwgeorge> doitlive.gif
20:47:51 <tdawson> OK, that's not my code, that's what I've been modifying.
20:48:56 <tdawson> I'm ok with trying it live, I actually have everything  in seperate files, so I'm not touching the original code.  But I have no idea how that script get's fired off.
20:49:22 <carlwgeorge> igor said releng has to run it periodically i believe
20:49:56 <nirik> I'd say get it working then we can figure a place to run it...
20:49:57 <tdawson> OK, so do pull request, get new files merged, and have them run it and give me the output?
20:50:32 <nirik> well, the goal is to have it file bugs no?
20:50:55 <tdawson> True, but I'd be totally surprised if it worked correctly the first time. :)
20:51:11 <michel_slm> if we want to be 100% safe I guess we can run the old script for Fedora and the new script only for EPEL? (i.e. keep two copies for now)
20:51:12 <nirik> you can point it to partner-bugzilla.redhat.com...
20:51:20 <nirik> (which sends no email)
20:52:36 <tdawson> OK, well, we're running short on time, just so ya'll know, I've made what I think is pretty good progress on it.
20:52:44 <smooge> congrats
20:53:15 <tdawson> Since we're short on time, I'll lump all the rest of the agenda into one...
20:53:35 <tdawson> #topic EPEL7/8 / general issues / open floor
20:54:08 <tdawson> Any EPEL7 or 8 issues?
20:54:15 * nirik doesn't have any
20:55:21 <tdawson> Hmm ... maybe I was being too hasty moving on :)
20:55:54 <michel_slm> I guess pgreco's topic was sort of EPEL8
20:56:01 <tdawson> True
20:56:11 <pgreco> michel_slm: I thought it as sig because the package already exists in fedora
20:56:24 <pgreco> so I was thinking about picking it up as part of the sig
20:57:02 <pgreco> but yeah, it could have been here...
20:57:19 <tdawson> Well, then nothing like having a few extra minutes in the day.
20:57:36 <tdawson> Thank you all for coming this week.  It was some good discussion.
20:57:46 <tdawson> I'll talk to everyone next week.
20:57:49 <pgreco> Thanks everybody!!
20:57:50 <pgreco> bye bye
20:57:54 <carlwgeorge> there is a thread on epel-devel about python3.9
20:58:09 <carlwgeorge> take a look and reply if you're interested
20:58:18 <carlwgeorge> *python3.9 for epel7
20:58:24 <smooge> yeah good luck with that
20:58:38 <carlwgeorge> well i'm not gonna do it :D
20:58:38 <tdawson> :)
20:59:12 <tdawson> Ya, I have no problems with someone doing it, as long as (as you already said in the email) it doesn't conflict with the RHEL7 pythons
20:59:19 * nirik nods
20:59:48 <smooge> i expect that it will be the usual 'aren't you going to do that for us?'
20:59:52 <tdawson> But it's not something I've had anyone ask me for, so ... ya, I'm not planning on doing it.
21:00:27 <tdawson> You want me to work on python3.9 ... ohhh ... look at the time. :)
21:00:36 <tdawson> #endmeeting