20:02:09 <carlwgeorge> #startmeeting EPEL (2022-07-06)
20:02:09 <zodbot> Meeting started Wed Jul  6 20:02:09 2022 UTC.
20:02:09 <zodbot> This meeting is logged and archived in a public location.
20:02:09 <zodbot> The chair is carlwgeorge. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:02:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:02:09 <zodbot> The meeting name has been set to 'epel_(2022-07-06)'
20:02:24 <rcallicotte> .hi
20:02:25 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:02:27 <carlwgeorge> #meetingname epel
20:02:27 <zodbot> The meeting name has been set to 'epel'
20:02:38 <carlwgeorge> #chair carlwgeorge rcallicotte
20:02:38 <zodbot> Current chairs: carlwgeorge rcallicotte
20:02:53 <carlwgeorge> #topic howdy
20:03:10 <gotmax[m]> .hello gotmax23
20:03:11 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
20:03:15 <gotmax[m]> Hi everyone!
20:03:16 <davide> .hello dcavalca
20:03:17 <zodbot> davide: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:03:46 <carlwgeorge> #chair gotmax[m] davide
20:03:46 <zodbot> Current chairs: carlwgeorge davide gotmax[m] rcallicotte
20:05:12 <carlwgeorge> looks like light attendance today, but we can get started anyways
20:05:21 <carlwgeorge> #topic EPEL issues
20:05:34 <carlwgeorge> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:55 <nirik> morning
20:06:03 <carlwgeorge> #chair nirik
20:06:03 <zodbot> Current chairs: carlwgeorge davide gotmax[m] nirik rcallicotte
20:06:19 <carlwgeorge> i only see one issue tagged for the meeting
20:06:20 <carlwgeorge> https://pagure.io/epel/issue/39
20:06:47 <pgreco> Hey guys, I'm traveling for work, I pinged troy but he's not here either...
20:06:51 <carlwgeorge> but it was tagged a month ago, and it looks like there are pull requests in progress
20:07:01 <gotmax[m]> Yeah
20:07:13 <gotmax[m]> Not sure if we want to talk about it without Michel Alexandre Salim 🎩
20:07:19 <carlwgeorge> pgreco: yeah troy is at a mechanic at the moment, he mentioned to me he wasn't sure when he'd be back
20:07:31 <carlwgeorge> gotmax[m]: agreed, we can punt it to next week
20:07:48 <carlwgeorge> i believe michel is on vacation this week
20:08:01 <gotmax[m]> I thought they were moving?
20:08:22 <carlwgeorge> oh i don't know details, i just meant vacation in the "not at work" sense
20:08:24 <gotmax[m]> I have some general EPEL stuff that I'll save for open floor
20:08:38 <gotmax[m]> I see
20:08:42 <carlwgeorge> any other issues in the tracker people want to bring up in this topic?
20:09:53 <gotmax[m]> Nothing sticks out to me
20:09:57 <carlwgeorge> #topic Old Business
20:10:08 <carlwgeorge> https://pagure.io/epel/pull-request/184
20:10:29 <carlwgeorge> that one has been going on a bit, there were a few minor nits to sort and then i think it's ready to merge
20:10:48 <carlwgeorge> i tried to push to troy's fork but pagure doesn't seem to allow that like github does
20:11:18 <gotmax[m]> I believe src.fp.o allows PPs to push to anyone's forks, but that's not applicable
20:11:22 <gotmax[m]> here
20:12:07 <nirik> it's a pref I think
20:12:44 <nirik> or not. not sure.
20:12:52 <carlwgeorge> github lets you do it per pull requests, it's a check box, something like "allow maintainers of destination branch to push to your fork branch"
20:13:17 <carlwgeorge> oh well, off topic here regardless.  troy can handle it whenever he gets back.  anything else for old business?
20:13:46 <gotmax[m]> My epel-rpm-macros PR?
20:14:20 <carlwgeorge> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/44
20:14:41 <nirik> I can mege/build it...
20:14:55 <carlwgeorge> i see you address the python2 thing miro brought up, thanks
20:15:04 <gotmax[m]> Yeah
20:15:09 <nirik> I think it's ready to go, no?
20:15:14 <gotmax[m]> That will unbreak the buildroot
20:15:15 <carlwgeorge> lgtm
20:15:24 <gotmax[m]> Yeah, I addressed all of the feedback
20:15:33 <rcallicotte> cool
20:16:23 <carlwgeorge> thanks for handling the merge/build nirik
20:17:39 <gotmax[m]> 🎉
20:17:51 <carlwgeorge> #topic EPEL-7
20:18:19 <carlwgeorge> #info epel7 will be retired on 2024-06-30 in line with the end of the rhel7 maintenance 2 phase
20:20:42 <carlwgeorge> anything else for epel7?
20:20:52 <gotmax[m]> Not from me
20:21:29 <carlwgeorge> #topic EPEL-8
20:21:38 <carlwgeorge> #info epel8-next will be retired on 2024-05-31 in line with the c8s eol (end of rhel8 full support phase)
20:22:19 <gotmax[m]> Not sure how much there is to discuss about it here, but the EPEL 8 Next buildroot has been completely broken for several days due to c8s pushing out a broken python27 module.
20:22:27 <gotmax[m]> Meaning that it's impossible to build anything
20:23:03 <gotmax[m]> My epel-rpm-macros PR had a temporary fix for that
20:23:04 <carlwgeorge> i was able to rebuild the python27 module to fix it, it should be composed and pushed out today i think
20:23:19 <gotmax[m]> Thanks for that!
20:23:26 <carlwgeorge> sure, sorry it's taking so long
20:23:50 <gotmax[m]> This whole CentOS Stream 8 is not really upstream of RHEL thing is kind of annoying
20:23:56 <carlwgeorge> some of the processes changed since i switched focus from centos to epel so i'm not fully up to speed on all the push processes
20:24:10 <gotmax[m]> Makes sense
20:24:13 <carlwgeorge> you have no idea (well you have some idea but yes it's worse than you can imagine)
20:24:31 <gotmax[m]> Yeah
20:24:32 <carlwgeorge> in the team we called it building the distro "inside out"
20:24:51 <gotmax[m]> At least from my outsider experience, there's often problems with things syncing over from the RHEL nightly compose.
20:24:58 <gotmax[m]> And CVEs that don't get fixed for months
20:25:05 <carlwgeorge> the goal is at some point this year for rhel maintainers to take over their c8s builds
20:25:12 <gotmax[m]> And the RHEL maintainers have no visibility into the process
20:25:14 <carlwgeorge> and build c8s in the same koji as c9s
20:25:19 <gotmax[m]> That would be great
20:25:29 <carlwgeorge> it's majorly work in progress
20:25:48 <carlwgeorge> not epel8 per say, but related question, do yall think we should keep doing these info things for the repo retirements this far out?
20:25:50 <gotmax[m]> I assume this has to do with CentOS Stream 8 being introduced after RHEL 8 was released?
20:26:08 <gotmax[m]> I don't mind it
20:26:11 <carlwgeorge> yes
20:26:18 <gotmax[m]> I think it's helpful to have in the back of your mind
20:26:30 <nirik> yeah, I think it's a nice reminder
20:26:39 <carlwgeorge> it's not a lot of trouble but this far out feels odd to me
20:26:42 <nirik> until one day... it's 'yikes! oh no!'
20:27:00 <carlwgeorge> also alert fatigue in a way
20:27:41 <davide> yeah I personally tend to tune these out, but I don't mind having them if folks find them useful
20:28:03 <carlwgeorge> yeah tuning it out is what i want to avoid
20:28:24 <nirik> I think of them as more info... shrug.
20:28:43 <carlwgeorge> i'll bounce it off troy later and see what he thinks
20:28:54 <carlwgeorge> maybe switch to do it once a month rather than every meeting
20:29:07 <gotmax[m]> That could be a good compromise
20:29:16 <carlwgeorge> anything else for epel8?
20:29:22 <gotmax[m]> Maybe more frequently when the release is closer to its EOL?
20:29:25 <gotmax[m]> Yes
20:29:32 <gotmax[m]> How do we want to handle appstreams that aren't supported for the whole 10 years?
20:29:33 <carlwgeorge> for sure
20:29:58 <carlwgeorge> nothing epel can do about them, they exist in rhel but get no further updates
20:30:06 <gotmax[m]> e.g. python38, python39, python27, ansible-core that has major version bumps
20:30:14 <gotmax[m]> Will we retire packages that depend on them?
20:30:57 <carlwgeorge> i would think no, but i don't have a strong opinion on it
20:31:01 <nirik> can we actually tell they are getting no more updates?
20:31:11 <carlwgeorge> we don't automatically retire other software that's eol
20:31:22 <gotmax[m]> They have published EOL dates
20:31:34 <nirik> in the module data?
20:31:53 <carlwgeorge> no in https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
20:32:13 <gotmax[m]> Thanks for the link. I was trying to find that
20:32:30 <gotmax[m]> python27 will be retired in Jun 2024
20:32:40 <carlwgeorge> firefox bookmark keywords are great
20:32:50 <nirik> yeah, I was looking too. ;)
20:32:53 <gotmax[m]> And 87 source packages in EPEL depend on it
20:33:08 <gotmax[m]> I was searching through my history and was typing appstream instead of application stream
20:33:44 <nirik> not sure if it's good to retire them or not.. perhaps this would be a good topic for epel-devel ?
20:33:54 <gotmax[m]> The thing is, even though they're retired in RHEL, they're still kept in the repos
20:34:08 <gotmax[m]> I'm not sure if retired is the term that RH uses, but whatever
20:34:12 <carlwgeorge> yeah i think this one should be opened up for wider comment
20:34:12 <nirik> yeah, they never remove things... which is... sometimes a pain
20:34:31 <carlwgeorge> gotmax[m]: it is, on that page "retirement date" column
20:35:07 <carlwgeorge> gotmax[m]: can you start an epel-devel thread on that?
20:35:10 <gotmax[m]> I think they sometimes remove things that actively cause problems (e.g. an ansible-core release that had an incorrect Obsoletes and broke things)
20:35:23 <gotmax[m]> Yeah
20:35:58 <nirik> they didn't want to remove the old ansible in extras when that was retired. ;(
20:36:19 <gotmax[m]> #action gotmax[m] to start an epel-devel thread about EPEL and appstream retirements
20:36:41 <gotmax[m]> ansible 2.9.27 is still supported to some degree
20:36:43 <gotmax[m]> I think
20:37:29 <nirik> well, not upstream, but perhaps in some rhel channel sure.
20:37:44 <gotmax[m]> Yeah, a separate channel
20:38:04 <carlwgeorge> retired != supported
20:38:21 <gotmax[m]> #info RHEL 8.7 will have a major release bump of ansible-core (2.12.x > 2.13.x) and switch from being built against python38 to python39.
20:38:59 <carlwgeorge> that sounds weird.  what i mean is that just because it's retired doesn't mean it's unsupported (i.e. they'll still take support cases for it)
20:39:11 <gotmax[m]> Yeah, but I don't think it's technically retired
20:39:42 <gotmax[m]> The ansible-core bump will mean that we'll have to update ansible from 5.x.x to 6.x.x.
20:40:35 <nirik> and all the folks adding python38 versions of things will need to do it again for python39 things. ;(
20:40:48 <rcallicotte> joy
20:40:53 <gotmax[m]> Yeah, that's why I `#info'd` it
20:41:06 <carlwgeorge> does the move from 5 to 6 have a lot of backwards incompat things?
20:41:22 <gotmax[m]> Not too much, I don't think
20:41:42 <carlwgeorge> can't avoid it of course, but how compatible it is should dictate how loudly we message it
20:43:04 <carlwgeorge> while we're still on 8 i'll add the action thing for nirik offering to build the epel-rpm-macros thing
20:43:20 <gotmax[m]> Some of the incompatibilities that are listed in ansible's changelog are related to ansible-core things (the changelog is unified) and some are about dropping support for ansible 2.9.27 or older python versions.
20:43:54 <gotmax[m]> They tend to be pretty conservative about marking things as minor changes, so some of the "major changes" aren't really that major.
20:44:49 <carlwgeorge> #action nirik will merge and build https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/44
20:45:09 <carlwgeorge> we need to wrap up so we have time for open floor, so...
20:45:10 <nirik> it's already done
20:45:15 <gotmax[m]> Looks like he already did :)
20:45:26 <carlwgeorge> #topic EPEL-9
20:48:17 <tdawson> .hi tdawson
20:48:18 <zodbot> tdawson: tdawson 'None' <tdawson@redhat.com>
20:48:32 * gotmax[m] waves
20:48:32 <smooge> hello sorry for being late
20:48:50 <carlwgeorge> #chair tdawson smooge
20:48:50 <zodbot> Current chairs: carlwgeorge davide gotmax[m] nirik rcallicotte smooge tdawson
20:48:51 <tdawson> Hi gotmax[m] smooge
20:48:59 <carlwgeorge> #topic General Issues / Open Floor
20:49:07 <smooge> i talked with carlwgeorge about what would be needed to jumpstart go in EPEL
20:49:11 <rcallicotte> hi tdawson
20:49:26 <smooge> I think we have a plan which we will need to engage releng on
20:49:41 <smooge> but i need to talk with nirik and write it up first
20:49:44 <gotmax[m]> What is releng doing?
20:50:02 <nirik> as little as possible. ;) er, I mean... not sure.
20:51:04 <tdawson> Are you planning on doing the whole golang-*devel package route?  Or a bundled route?  Or something else?
20:51:36 <gotmax[m]> I feel like y'all have been bothered enough about go stuff with my infra tickets about the src.fp.o dashboard :p
20:51:53 <tdawson> Or, should I not ask that because we don't have enough time in the meeting?
20:52:08 <gotmax[m]> I wouldn't mind discussing
20:52:19 <gotmax[m]> The go-sig is also having a conversation about how we want to handle this
20:52:39 <smooge> I was going to do a the approrpiate name for a 'side-tag' where I get releng to tag in some needed F36 packages, I then build the EPEL9 ones i need and then untag the F36 out of the sidetag and then merge the tag into EPEL-9
20:52:57 <smooge> or at least that is hair-brained idea
20:53:08 <gotmax[m]> Because everything is unbundled, there's a lot of packages, some of which are not in good shape, and we want to make sure we're not stretching ourselves too thin.
20:53:21 <tdawson> It's an idea ... it could work.
20:53:46 <smooge> my main goal will be a small set of end items I 'need' for various work. android-tools, hugo and possibly a couple others
20:53:51 <gotmax[m]> smooge: I would prefer if we just added the appropriate bootstrap logic (some of which is already there) and build things from scratch.
20:54:11 <smooge> the problem is that I can't figure out how to get the various tools to bootstrap
20:54:16 * davide would like to get golang-github-facebookincubator-go2chef into EPEL at some point too
20:54:22 * nirik notes you can do all this without releng... make a side-tag, tag what you need in and out
20:54:38 <smooge> nirik, I didn't know if I could tag in Fedora X into an EPEL side-tag
20:54:53 <smooge> that used to be something needing releng special powers
20:55:02 <smooge> but used to be is from when I was a lad
20:55:06 <nirik> you can tag any build into side tags if you are the side tag owner
20:55:14 <smooge> ah ok
20:55:23 <tdawson> That is good to know.
20:55:30 <smooge> well then you are correct 'releng is going to do as little as possible'
20:55:36 <rcallicotte> this would allow the deps to be used in your builds?
20:55:40 <gotmax[m]> I was about to say that same thing word for word, tdawson :)
20:55:46 <rcallicotte> the cross-tag idea
20:56:18 <smooge> so my plan would be bootstrap the packages for one set of builds, then rebuild the packages using the bootstrapped ones to lose the deps
20:56:23 <nirik> yes, each side tag has it's own buildroot... inheriting from what it is a side tag of + what builds are in it
20:56:25 <gotmax[m]> Another idea would be to just tag the library packages in from rawhide and not build them for epel at all
20:56:41 <gotmax[m]> That's what the rust sig used to do, but I don't think it went very well
20:56:46 <gotmax[m]> They did it from rawhide > stable Fedoras
20:56:51 <nirik> yeah, rust used to do that, but it gets confusing
20:57:00 <gotmax[m]> (All libraries are noarch)
20:57:01 <smooge> i would prefer to avoid confusion
20:57:32 <smooge> my main issue is that a set of packages call binaries in other packages which need to be built using the binaries from the first set of packages
20:57:42 <smooge> and not in the test area
20:57:46 <gotmax[m]> I think it's better to discuss this in more length in the go-sig meeting
20:57:58 <smooge> yeah..
20:58:04 <smooge> anyway that was all I had for EPEL
20:58:07 <gotmax[m]> smooge: Like what?
20:59:06 <smooge> it was the golang-x-tools needing golang-barflung-tools needing golang-x-tools and my 'I am not a golang developer but I am cribbing from their notes' looked like it was instead of libraries binary calls
20:59:40 <smooge> if that sentence makes sense, you have had as little sleep as I have
21:00:03 <smooge> anyway.. I will look at it in the go-sig meeting and work with them on what is needed/wanted/
21:00:14 <carlwgeorge> doing the lord's work
21:00:14 <gotmax[m]> +1
21:00:16 <smooge> I just need to find the meeting and see if I can make it
21:00:40 <gotmax[m]> The next one is Monday the 18th
21:00:42 <gotmax[m]> At 18:00 UTC
21:00:51 <carlwgeorge> well we're out of time, any last minute things that can't wait till next week?
21:00:57 <gotmax[m]> That's 2:00 p.m eastern
21:00:57 <tdawson> smooge  gotmax[m]  Thanks for your go work.  That's a tought bunch of dependencies to unravel.
21:01:09 <tdawson> Nothing from me
21:01:10 <carlwgeorge> thar be dragons
21:01:20 <gotmax[m]> I wanted to talk about the EPEL branch requests procedures, but that can wait
21:01:40 <gotmax[m]> carlwgeorge: Very much so
21:01:46 <carlwgeorge> thanks everyone for coming, and all your work in fedora and epel.  have a good week.
21:01:52 <carlwgeorge> #endmeeting