20:01:21 <tdawson> #startmeeting EPEL (2023-07-12)
20:01:21 <zodbot> Meeting started Wed Jul 12 20:01:21 2023 UTC.
20:01:21 <zodbot> This meeting is logged and archived in a public location.
20:01:21 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:01:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:21 <zodbot> The meeting name has been set to 'epel_(2023-07-12)'
20:01:22 <tdawson> #meetingname epel
20:01:22 <zodbot> The meeting name has been set to 'epel'
20:01:24 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
20:01:24 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
20:01:25 <tdawson> #topic aloha
20:01:26 <rsc> .hello robert
20:01:27 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:01:34 <rcallicotte> .hi
20:01:34 <dherrera> .hi
20:01:35 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:01:38 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:01:50 <carlwgeorge> .hi
20:01:51 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:02:00 <tdawson> Hello rsc
20:02:00 <rcallicotte> hi tdawson
20:02:10 <tdawson> Hi rcallicotte dherrera and carlwgeorge
20:02:18 <salimma> .hi
20:02:19 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:02:23 <tdawson> Hi salimma
20:02:34 <nirik> morning
20:02:39 <gotmax> .hello gotmax23
20:02:40 <zodbot> gotmax: gotmax23 'Maxwell G' <maxwell@gtmx.me>
20:02:56 <tdawson> Morning nirik
20:02:59 <tdawson> Hello gotmax
20:03:17 <gotmax> Hi tdawson!
20:04:45 <tdawson> #topic End Of Life (EOL)
20:04:46 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:04:48 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:04:49 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:05:21 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:22 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:50 <tdawson> For the first time in a while, we don't have any issues with meeting marked on them.
20:06:32 <tdawson> #topic Old Business
20:06:50 <tdawson> Does anyone want to bring up any of our Old Business?
20:07:27 <carlwgeorge> i had one thing
20:07:37 <tdawson> carlwgeorge: Go for it.
20:08:09 <carlwgeorge> https://pagure.io/packaging-committee/issue/1283
20:08:22 <carlwgeorge> this started as an epel committee issue, and we deferred to fpc
20:09:06 <carlwgeorge> things have changed and now rhel is planning to ship gpsd-minimal, which will have file conflicts with gpsd in epel8 and epel9
20:09:35 <nirik> ;(
20:09:57 <carlwgeorge> this is just a heads up in case anyone was planning on building against gpsd-devel/gpsd-libs
20:10:38 <carlwgeorge> if someone wants to ship a gpsd-epel package to provide the things missing from the future rhel package, things can go about as usual.  if no one wants to do that, a few epel packages will be affected.
20:10:51 <carlwgeorge> plasma-workspace-geolocation and collectd-gps
20:11:44 <carlwgeorge> those are subpackages of other stuff, so perhaps the best solution is to disable them on epel builds.  i've already reached out to a few of the relevant maintainers.
20:12:06 <tdawson> I'll probrubly take that on for my plasma package ... though I'll wait until it makes it into RHEL ... if it does.
20:12:07 <nirik> yeah, we can just drop the collectd subpackage...
20:13:14 <tdawson> carlwgeorge: Thanks for the heads up.
20:13:33 <carlwgeorge> because the srpm name won't be the same, i doubt we'll get the normal retirement bug, so we should keep it in mind for 8.9 and 9.3 (i think)
20:14:08 <carlwgeorge> that's all i had on the topic, we can move on
20:14:20 <tdawson> Any other Old Business?
20:14:43 <tdawson> Or even old business if you don't want it so formal.
20:15:01 <nirik> ye olde business?
20:15:12 <salimma> Django is super close to landing in epel9
20:15:25 <tdawson> Ya!!
20:15:32 <salimma> the epel8 build now works fine, but that's missing some optional dependencies, which unfortunately ... include caching :(
20:16:01 <salimma> I just requested stalled package access to the two missing deps, and a PR for the third one that we have access but need a tiny patch
20:16:39 <salimma> then we can move on to django 4. would it make sense to just call it python-django-lts to indicate we won't be upgrading to non-LTS versions like Fedora does?
20:16:46 <salimma> the python-django3 bug for those who want to keep track https://bugzilla.redhat.com/show_bug.cgi?id=2033064
20:18:05 <tdawson> I don't know enough about django release cycle to make a educated recommendation.
20:18:35 <tdawson> But, why not call it python-django4 ?
20:18:44 <salimma> there's a nice chart here https://www.djangoproject.com/download/
20:19:03 <salimma> oh good point. looks like they won't be doing any more minor release
20:19:06 <salimma> so django4 is fine
20:19:22 <salimma> or django4.2 to be more explicit?
20:19:36 <nirik> yeah 'lts' in a package name isn't great...
20:20:12 <nirik> 4.2 seems good IMHO
20:20:24 <salimma> explicit better than implicit :)
20:20:29 <salimma> ok, nothing else from me
20:21:17 <tdawson> I'm going to move it on to Ye Business Which Be New
20:21:30 <tdawson> hmmm ... that sounded better in my head.
20:21:39 <tdawson> #topic General Issues / Open Floor
20:22:12 <tdawson> Does anyone have anything for the Open Floor?
20:22:53 <salimma> anyone interested in ebranch getting support for filing stalled EPEL requests?
20:23:04 <salimma> I've had to file a couple recently and it's a pain to do by hand :)
20:23:20 <neil> salimma: I would
20:23:22 <neil> also hi
20:23:22 <neil> .hi
20:23:23 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:23:38 <tdawson> Hi neil
20:23:44 <salimma> ack, let me bump it up my list. and hi neil
20:23:56 <salimma> I'm not looking forward to filing these by hand for django4.2 :)
20:24:32 <carlwgeorge> i had one minor thing for open floor when salimma is done
20:24:43 <salimma> go ahead
20:25:56 <carlwgeorge> i know some folks have complained that packaging for epel is too difficult with actual rhel.  i took a look and it was easier than i thought.  i updated the mock documentation, which was originally written before simple content access (sca) was a thing.
20:25:59 <carlwgeorge> https://rpm-software-management.github.io/mock/Feature-rhelchroots
20:26:55 <neil> obligatory 'subman bad' because someone else will say it ;) But, really, thank you for that, carlwgeorge!
20:27:01 <carlwgeorge> tldr, you can subscribe your workstation (fedora or whatever, anything with subscription-manager available) with one command, then mock rhel chroots just work(tm)
20:27:13 <carlwgeorge> sure thing
20:27:31 <tdawson> I do like that you show how to disable the subman plugin.
20:27:43 <tdawson> It still works with it disabled?
20:27:52 <carlwgeorge> yeah that part is optional, but dnf needs all the help it can get to be faster
20:28:06 <neil> carlwgeorge++
20:28:12 <salimma> that's useful, thanks
20:28:22 <gotmax> I've been using this on my Fedora machine and it works decently well
20:28:30 <carlwgeorge> on a related note, with a subscribed fedora system, ubi containers started with podman also get real rhel repos automatically
20:28:31 <tdawson> I believe that's most people's gripe about submanager, that it checks every single time.
20:28:38 <salimma> is it... possible to get subscription manager to support containers?
20:28:42 * nirik wonders if this all works with dnf5... I hope so?
20:29:03 <gotmax> I have a fedrq container image running UBI and an alias that makes it really easy to query RHEL  9 repos
20:29:11 <gotmax> Still, I don't like how much telemetry it send
20:29:15 <carlwgeorge> i haven't seen a subman dnf5 plugin yet, but i think it's a safe bet that they have to make that before fedora 40 / cs10 / rhel10
20:29:28 <salimma> my use case is: primary machine is mostly managed by work configuration management, then I have a Fedora packaging container I fully manage, and run mock inside it
20:29:36 <salimma> gotmax: too soon :)
20:30:30 <carlwgeorge> salimma: you might have missed it but i did point out that a subscribed host will get rhel repos inside ubi containers automatically
20:30:55 <carlwgeorge> but reading your second message i think you might have mean subscribing inside the container, which i don't think works
20:31:02 <salimma> carlwgeorge: right, but I can't install subscription manager inside the fedora container ... exactly
20:31:03 <carlwgeorge> *meant
20:31:33 <salimma> I guess if I have to I can subscribe my Fedora machine, and do epel packaging from an ubi container that has mock installed
20:31:34 <carlwgeorge> someone on mastodon pointed out that it works even better on silverblue, with no host dnf
20:31:56 <dherrera> can you even run mock inside a container? I think I failed last time I tried
20:32:26 <neil> you can, w/o nspawn
20:32:27 <carlwgeorge> mock has a simple chroot mode that i think it can fall back to when run inside a container, but you might have to configure it to do it smoothly
20:32:30 <gotmax> I think it works if you use a --privileged container and use chroot mode instead of nspawn mode with mock
20:32:35 <neil> that too, gotmax
20:32:35 <gotmax> Yeah
20:32:54 <dherrera> oh, that makes sense :)
20:33:17 <dherrera> got too used to doing userspace containers with podman xD
20:33:48 <carlwgeorge> i just had an idea to suggest to the subman team, add a flag to register to preemptively disable the host dnf plugin, something like `subscription-manager register --no-dnf-plugin`
20:34:30 <gotmax> That would be nice
20:35:03 <gotmax> I have another topic
20:35:05 <carlwgeorge> i'll have to ask around to figure out how to suggest that, looks like issues are disabled on their github
20:35:06 <salimma> dherrera: I forgot what I had to change to fix it but yes
20:35:16 <carlwgeorge> gotmax: i'm done, go ahead
20:35:20 <gotmax> carlwgeorge: You could try Fedora Bugzilla
20:35:23 <salimma> REVIEW_NO_MOCKGROUP_CHECK
20:36:00 <gotmax> Are we going to support the SUSE and Oracle RHEL forks?
20:36:10 <rcallicotte> oh boy
20:36:24 <tdawson> We (EPEL) already do support Oracle Linux
20:36:26 <jonathanspw> that's a loaded question
20:36:30 <carlwgeorge> i don't think anyone can answer that until we see what those look like
20:36:39 <jonathanspw> tdawson: in its current state OEL is a clone not a fork.
20:36:47 <carlwgeorge> one of them (i forget which) said they were going to hard fork but also stay rhel compatible
20:37:00 <carlwgeorge> which seems contradictory to me
20:37:06 <nirik> whatever that means
20:37:34 <tdawson> Well ... Amazon Linux was a fork of RHEL for a time, and it was somewhat compatible.
20:37:39 <salimma> jonathanspw: oh, I thought they added their own Unbreakable Kernel
20:37:40 <carlwgeorge> i suspect we'll end up in a situation like we were with amazon linux 1 and 2, where they sorta try to stay compatible with rhel and thus epel, but if any issues arise we punt
20:37:57 <nirik> I hope not, that was a bad time(tm)
20:37:58 <jonathanspw> salimma: yeah they have that a few other minor things but it's just a glorified clone
20:38:04 <carlwgeorge> jonathanspw: not a clone, the default to a different kernel and also add additional patches
20:38:08 <carlwgeorge> *they
20:38:11 <salimma> fair enough, I guess the extra stuff are all optional
20:38:25 <rcallicotte> they need to just contribute to stream....
20:38:38 <carlwgeorge> oracle's extra stuff is not all optional, just the kernel
20:38:40 <salimma> CentOS Stream Oracle SIG
20:38:43 <nirik> the different kernel I thought was completely optional... you can also run the cloned one
20:39:12 <tdawson> In short, I think if they ask for something reasonable ... I can't think of anything at the moment ... maybe a tweek to the crb script ... I have no problem with that.
20:39:23 <nirik> one of the amazon versons actually built a completely different python stack. Very anoying to try and support.
20:39:23 <carlwgeorge> yes they have the uek and the non-default rhck, but there are other packages with divergences
20:39:45 <rsc> But these are optional.
20:39:54 <carlwgeorge> glibc is optional?  lol
20:40:15 <jonathanspw> it seems like not support clones/forks/whatever would seriously limit the use of EPEL if it's limited to only stream/RHEL
20:40:24 <nirik> anyhow, yeah, I think we can try and accomodate them, but if it gets too hard we reserve the right to stop. (just IMHO)
20:40:29 <rsc> You can Oracle run as a complete RHEL clone.
20:40:33 <carlwgeorge> nirik++
20:41:03 <gotmax> I think that's reasonable
20:41:11 <AleksandraFedoro> The point of being clone/fork/whatever is to be compatible so that you don't need separately support everything in EPEL
20:41:39 <tdawson> Exactly.
20:41:54 <jonathanspw> is it possible to mockbuild packages against rhel without doing licensing mess?
20:41:55 <gotmax> I also have an ansible thing
20:41:56 <carlwgeorge> personally for my packages if i get a bug from one of these future forks my first response is going to be to ask them to reproduce it on rhel
20:42:10 <carlwgeorge> which is the same way i've handled bugs reported for epel packages on al1/al2 in the past
20:42:10 <AleksandraFedoro> So there should be some sort of middle ground so that people try to be compatible to EPEL, not EPEL trying to be compatible with everyone
20:42:26 <jonathanspw> carlwgeorge: in users eyes that's just going to be a put-off and further reduce the use of epel
20:42:26 <rcallicotte> I agree ^^
20:42:45 <nirik> jonathanspw: you can scratch build in fedora koji? :)
20:42:54 <jonathanspw> yeah if you want to wait 10x as long for builds ;)
20:43:33 <carlwgeorge> that's a gross exaggeration (usually)
20:43:38 <jonathanspw> i purpose built my latest home/office workstations so i could mockbuild as fast as possible and get things done
20:43:50 <tdawson> jonathanspw: There is also COPR ... but if time is the thing ... it's slower than local also.
20:43:53 <jonathanspw> yeah 10x is an exaggeration but 2-3x slower is not
20:44:52 <salimma> koji scratch builds with ppc64 excluded are quite fast normally :)
20:44:54 <carlwgeorge> for epel10, folks can just do their build in the leading branch against cs10, then fire and forget for the minor version branch(s).  i often do the same thing with rawhide vs released fedora branches.
20:45:03 <salimma> and mimics local builds where... you don't have a ppc box anyway
20:45:12 <carlwgeorge> *fire and forget koji builds
20:46:06 <jonathanspw> So there's no real solution to mockbuild rhel? :(
20:46:18 <carlwgeorge> sure their is https://rpm-software-management.github.io/mock/Feature-rhelchroots
20:46:31 <carlwgeorge> i think you may have joined late and not seen that part of the discussion
20:47:17 <nirik> you mean ppc64le... ppc64 is happily gone. ;)
20:47:18 <jonathanspw> oh i just missed that being mentioned earlier
20:47:43 <carlwgeorge> you still have to subscribe the host, but it's easier than i expected and after that mock works automatically
20:47:59 <jonathanspw> possible to host a copy of rhel repo locally?
20:48:19 <jonathanspw> no clue if rhel's repos are fast or not but fedoras are painfully slow.  local-hosting them saves me a lot of time on builds
20:48:45 <nirik> I think there's some access article about syncing...
20:48:48 <rsc> Technically, it's possible to host a local copy of RHEL, legally I don't know.
20:49:05 <carlwgeorge> jonathanspw: Eighth_Doctor has a thing for that
20:49:16 <jonathanspw> I guess the point I'm making...my workflow at least is hugely impacted by this mess :(
20:49:40 <tdawson> Before it get's to late, gotmax had another item to bring up
20:50:04 <nirik> https://access.redhat.com/solutions/23016 ? (but not sure if thats the right one)
20:50:19 <jonathanspw> nirik++
20:50:19 <zodbot> jonathanspw: Karma for kevin changed to 28 (for the release cycle f38):  https://badges.fedoraproject.org/tags/cookie/any
20:50:27 <gotmax> tdawson: Yes, I do
20:50:38 <tdawson> gotmax: go for it.
20:50:46 <gotmax> I just wanted to call attention to https://bugzilla.redhat.com/show_bug.cgi?id=2221820
20:51:15 <gotmax> It looks like they're downgrading ansible-core in CentOS Stream 9 and changing it back to python3.9 (it was using python3.11 before)
20:51:44 * nirik sighs.
20:52:04 <salimma> oh no... why
20:52:05 <gotmax> and then it'll stay at that version for the rest of RHEL 9 instead of being updated every minor release like it had been
20:52:16 <salimma> presumably something was found to break
20:52:21 <gotmax> I tried to convince them not to but probably going to happen anyways
20:52:22 <rcallicotte> what?
20:52:28 <gotmax> They explain it in the issue
20:52:46 <salimma> yeah, sorry. just noticed
20:52:48 <nirik> well, not just steam 9 right? it's also current rhel9
20:52:49 <salimma> to support RHEL 7
20:52:50 <gotmax> It's about supporting RHEL 7 hosts and Python versions in RHEL
20:53:29 <gotmax> In CentOS Stream 9, they'll probably have to Epoch and downgrade
20:53:37 <gotmax> The new version wasn't pushed out to RHEL 9
20:53:41 <carlwgeorge> i can get behind the idea of locking to a python version for the rest of the el9 lifecycle, but ideally that would be on the one it's currently on, not downgrading
20:53:52 <tdawson> RHEL 9.2 is at ansible-core 2.14.2
20:53:55 <nirik> oh, odd, I see it on a rhel9 host here, perhaps I missed something.
20:54:38 <gotmax> This type of thing makes me question claims that CentOS Stream is a production distribution, but...
20:54:41 <nirik> # rpm -q ansible-core --requires | grep python3
20:54:41 <nirik> /usr/bin/python3.11
20:54:44 <nirik> ansible-core-2.14.2-4.el9.x86_64
20:55:11 <salimma> since RHEL/CS does not support upgrading between major versions... will that epoch be dropped for CS 10 I wonder
20:55:19 <carlwgeorge> so it has already happened in rhel9?
20:55:25 <carlwgeorge> the py3.11 part
20:55:30 <nirik> I thought so
20:55:32 <salimma> if so, Alma will have to do something to support it in their upgrader tool. if not... ugh epoch forever
20:55:53 <carlwgeorge> so if this change means centos stream isn't a productions distro, then rhel isn't either
20:55:58 <gotmax> Yes, RHEL 9's ansible-core uses python3.11
20:56:14 <gotmax> They're downgrading the python3.11 version in RHEL 9, but the version of ansible-core itself it not being downgraded
20:57:18 <gotmax> [gotmax@ftop2] ~ >>> fedrq9 pkgs ansible-core -S -F nevrr
20:57:18 <gotmax> ansible-core-2.14.2-5.el9_2.x86_64 rhel-9-for-x86_64-appstream-rpms
20:57:18 <gotmax> [gotmax@ftop2] ~ >>> fedrq pkgs -b c9s ansible-core -S -F nevrr
20:57:18 <gotmax> ansible-core-2.15.0-1.el9.x86_64 fedrq-centos-stream-appstream
20:57:23 <nirik> the current version uses 3.11 and they are going to change it to use 3.9... right? which... is a super hassle for people who rebuilt stuff to work with 3.11 for modules.
20:57:43 <gotmax> Right
20:57:50 <nirik> and yeah, downgrade stream to 2.14.x again.
20:57:53 <nirik> what a mess
20:57:59 <gotmax> Yeah...
20:58:15 <gotmax> Also, RHEL 8 will not do this, so it'll eventually end up two versions ahead of RHEL 9
20:58:17 <rcallicotte> seems like they should not do that?
20:58:36 <nirik> anyhow, I guess there's not much for us to do here but adjust? and tell people not to branch stuff for 3.11 if they just are trying to support control host modules.
20:58:47 <gotmax> nirik: Exactly :)
20:59:30 * nirik already did rebuild several for fedora-infra. ;( Oh well, easy come easy go.
20:59:42 <tdawson> gotmax: Thanks for bringing that to our attention.
20:59:56 <gotmax> On a related note, I'm giving a talk about Ansible packaging in Fedora and EPEL at Flock
21:00:08 <gotmax> Hope to see some of you at the talk and at Flock in general
21:00:16 <rcallicotte> cool
21:00:23 <nirik> 👍
21:00:27 <tdawson> Looks like our time is up.  Thank you all for the good discussions and for your work on EPEL and it's community.
21:00:30 <carlwgeorge> yeah it will be good to meet  you irl
21:00:46 <tdawson> gotmax: Cool ... I'll be at flock too.  It will be good to see you IRL
21:00:54 <gotmax> :)
21:00:56 <tdawson> oh ... and I need to close the meeting.
21:01:05 <tdawson> #endmeeting