21:00:28 #startmeeting EPEL (2021-12-01) 21:00:28 Meeting started Wed Dec 1 21:00:28 2021 UTC. 21:00:28 This meeting is logged and archived in a public location. 21:00:28 The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 21:00:28 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:28 The meeting name has been set to 'epel_(2021-12-01)' 21:00:28 #meetingname epel 21:00:28 The meeting name has been set to 'epel' 21:00:28 #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca 21:00:28 #topic aloha 21:00:28 Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson 21:00:46 .hi 21:00:47 .hi 21:00:47 carlwgeorge: carlwgeorge 'Carl George' 21:00:50 pgreco: pgreco 'Pablo Sebastian Greco' 21:00:51 .hi 21:00:53 dcavalca: dcavalca 'Davide Cavalca' 21:00:53 Hi carlwgeorge 21:00:57 Hi pgreco 21:01:02 .hi 21:01:03 salimma: salimma 'Michel Alexandre Salim' 21:01:05 Hi dcavalca 21:01:07 .hi 21:01:08 cyberpear: cyberpear 'James Cassell' 21:01:11 Hi salimma 21:01:18 Hi cyberpear 21:02:29 It's good to see zotbot is acting correctly today. 21:03:05 I gave up and nabbed my FAS nick on Libera before someone took it, so now zodbot is happy with me too 21:03:38 :) 21:04:05 .hi 21:04:06 rcallicotte: rcallicotte 'Robby Callicotte' 21:04:17 I exist now!! 21:04:36 Hi rcallicotte 21:04:37 hello 21:04:54 hello all 21:04:59 Hi SSmoogen[m] 21:05:55 So, nirik said he was going to be a bit late, so I'm not going to start with mock stuff / old business 21:06:12 And looking at the issues marked for the meeting, that also is only the mock stuff. 21:06:44 Oh, but we do have the macros in old business 21:06:53 yeah 21:06:56 pgreco: Have you been able to make any progress on the macros? 21:07:08 I've managed to get something done (in the last hour) 21:07:17 at least, there's movement 21:07:24 Ya! :) 21:07:37 -rw-r--r--. 1 pgreco mock 23864 dic 1 18:05 epel-rpm-macros-8-26.noarch.rpm 21:07:37 -rw-r--r--. 1 pgreco mock 26984 dic 1 18:05 epel-rpm-macros-8-26.src.rpm 21:07:37 -rw-r--r--. 1 pgreco mock 13196 dic 1 18:05 epel-rpm-macros-systemd-8-26.noarch.rpm 21:08:35 I've been swamped at work, but hopefully I'll be able to finish it 21:08:54 if someone really needs this and just wants to take this off my hands, just ping me 21:08:54 Cool 21:09:28 * tdawson looks around, seeing if anyone volunteers 21:09:33 * tdawson doesn't see anyone. 21:09:52 thought so :P 21:09:57 :) 21:11:27 As far as the "willit" stuff goes, I haven't done anything in the past couple weeks. But hopefully I'll be able to get some of the features in that people have asked for before the end of the year. 21:12:03 #topic EPEL-7 21:12:21 tdawson: looking forward to using 'willit' to detect packages that need rebuilding 21:13:11 willitburn 21:13:18 willitblend 21:13:18 *laughs* 21:13:47 Sounds like there aren't any EPEL7 things 21:13:47 https://i.pinimg.com/originals/26/b2/50/26b250a738ea4abc7a5af4d42ad93af0.jpg 21:14:02 #topic EPEL-8 21:14:07 I don't have anything myself.. EL7 is still going bonkers 21:14:20 EL7 growth 21:14:33 I know the mock thing technically is epel8, but nirik isn't here yet, so I'm going to keep that for later still. 21:14:40 SSmoogen[m]: Still? 21:14:46 do we have clear comms we can point people to to encourage them to migrate to EL8 or newer? 21:14:57 asking for a friend 21:15:06 yeah.. I am guessing it will still go up until Amazon2022 is out further 21:15:33 And then Fedora's numbers are going to start climbing ... maybe. 21:15:37 I thought AL ships its own EPEL? 21:15:56 I thought that was oracle? 21:16:01 Michel Alexandre Salim: the majority of user usage for EPEL7 is amazon2 systems. whether they have their own EPEL or not.. the boxes are using ours 21:16:02 oh yeah 21:16:12 Ya, it's oracle that does 21:16:14 I'm still seeing folks internally on the IT side claim they *need* el7 because of vendor support issues 21:16:14 wow, given AL is not an exact EL clone their users must not have a great experience 21:16:20 so, yeah, getting rid of that will be fun 21:16:28 dcavalca: yeah that's what I meant by 'a friend' 21:16:44 yeah, al2 systems routinely have issues installing epel7 packages 21:16:52 EL7 is still growing outside of Amazon growth.. lots of people are finally moving their EL5 and EL6 systems to it 21:17:09 oh boy 21:17:21 I with RHEL9 was out, so they could just skip all the way to that ... 21:17:39 And talking about that, sounds like there isn't any epel8 (non-mock) stuff ... soo 21:17:45 #topic EPEL-9 21:17:45 el7 is great, the older it gets the fewer of those pesky updates it gets /s 21:17:52 :) 21:18:03 Beta and Stream are available! 😜 21:18:06 it's insane that people don't just skip from 6 to 8 21:18:07 nah.. EL people are late majority/laggard/labrae pit part of the technology adoption curve 21:18:08 carlwgeorge How is the epel9 stuff going :) 21:18:14 esp since in-place upgrades are not supported anyway 21:18:37 oh yeah, I have a package I want to build for epel9 so would be happy to be a guinea pig 21:18:53 well we picked plan c last week, i filed https://pagure.io/releng/issue/10402, then we had the holiday and then i had pto. 21:19:03 * nirik arrives, reads up 21:19:06 they usually have large amounts of software/data which takes forever to port forward so going to EL7 was probably started before EL8 came out 21:19:31 i'm going to hit up mboddu after this to see if we can finish the koji part, then add the release in bodhi 21:19:34 carlwgeorge True, but I see this - https://koji.fedoraproject.org/koji/buildtargetinfo?targetID=21587 21:19:41 carlwgeorge: ooh looks like bhujji just finished that today (2 hrs ago0 21:19:43 carlwgeorge: I think he did it already 21:20:18 nice 21:20:28 :) 21:20:32 well the target is there, but it's not using the c9s external repo yet 21:21:02 either way we'll get that buttoned up soon and i'll write the launch announcement 21:21:04 It's using "rhel9-base" ... which I don't know what that means. 21:21:23 yeah, I think it is. 21:21:39 ugh, should I cancel my build then 21:21:39 points to https://infrastructure.fedoraproject.org/repo/centos/centos-9-stream/$arch/ 21:21:41 i think it's an external repo with an empty directory of where we plan to eventually sync rhel9 content to 21:21:49 ah ok 21:22:36 it should be pointed to stream 21:22:45 or rather it looks to be pointed to stream. ;) 21:22:50 oh nevermind, it looks like it was reconfigured to point to the same dir as the c9s external repo, cool 21:23:12 anways, progress 21:23:14 I had a question: is the announcement going to have the info developers need? or should we _also_ send something to devel-announce/epel-announce... 21:23:32 I mean in the sense of 'you can request branches now, etc' 21:23:35 yes, yes, and yes 21:24:00 Is `fedpkg` in EPEL-9 or will developers want to use F35 to do their work? 21:24:05 Hi everyone, sorry I’m a bit late 21:24:19 Hi themayor 21:24:22 SSmoogen[m]: IMO we should strive to support both workflows 21:24:41 SSmoogen: I'm hoping fedpkg and fedora-review can make it to epel9 21:24:45 SSmoogen[m]: nothing is in epel9 yet, and i don't think we're going to block on getting fedpkg available. the fedpkg maintainer can add it there whenever they are ready and have all the deps available. 21:25:05 tried getting the latter to EPEL8 but there's too many dependencies that require newer RPM for Python macro magic 21:25:18 I stepped out for a moment, but https://pagure.io/releng/issue/10402#comment-765363 is my explanation about rhel9-base external repo 21:25:25 I should be back in 5 min 21:26:20 scratch build is failing in an interesting way https://koji.fedoraproject.org/koji/taskinfo?taskID=79485853 21:26:22 ok so a while ago, the python maintainers weren't interested in having the needed dependencies in EPEL unless others were going to take them over. 21:26:47 bhujji: looks like it's not retrieving sources from the lookaside cache correctly? the source is there (fedpkg new-sources is a no-op) 21:27:31 i think we need to tag fedpkg-minimal over to epel9-build as well, like we did for epel9-next-build 21:27:45 yes 21:28:00 either way, those are details to sort later, we can move on for the meeting 21:28:01 it needs fedpkg-minimal to run 'fedpkg sources' 21:28:06 Yep, let's move on. 21:28:30 Now that nirik is here, and I think we're done with epel9 ... let's move back to the mock stuff. 21:28:35 anyway, I was only wanting to make sure the instructions covered how people would need to do package work until such time as it is ready 21:28:55 #topic Mock Config Stuff - https://pagure.io/epel/issue/133 21:29:03 I think this is two issues. 1) suggestion to mock developers what to do and 2) suggestion to fedpkg developers what to do. 21:29:08 SSmoogen[m]: i'll keep that in mind for the announcement, thanks 21:29:57 I do think fedpkg should get some way to set it's default. 21:30:53 agreed 21:30:55 IMHO, for 1) we should not have 'epel' as a target there, it's an add on repo, it should just be a disabled repo you can enable with any of the configs for compatible el distros. 21:31:26 for fedpkg yeah, having a way to set it and a error telling you to set it seems reasonable to me too 21:32:22 nice idea about the repo, but what does the UI look like in that method? 21:33:02 edit the mock template to enable epel, then build for the el flavor of your choice 21:33:11 My opinion, even though I was the first to state it, getting rid of the default epel config just feels wrong. It feels like taking your ball and going home. 21:33:19 that sounds like a pain 21:33:21 yeah. possibly replace the epel.cfg files with a readme telling you about that? 21:34:09 So, please state again why you do not want Alma or Rocky as the default? 21:34:22 i think if we keep the generic epel8 it should use rhel8, with abundant comments about how to reconfigure it to use a rhel clone if the user doesn't want to set the sub 21:34:29 I'd say detect the distro being used to build and make EPEL target the same. Question remains about when running on Fedora. 21:34:40 can we ship both epel8 (rhel8-based) and epel8-alma or something? 21:34:58 We already do 21:35:03 salimma: mock already ships alma+epel-8 configs 21:35:06 anything but rhel as a default is fine 21:35:10 There is already an alma, and a rhelepel 21:35:39 IMHO having those as default is misleading, since epel doesn't build against them. Additionally it will be playing favorites amoung community projects. 21:35:52 3 options (rhel/alma/rocky) and a default that works ootb with a changeable symlink 21:36:02 tdawson: for me, picking a clone implies way too much endorsement, and i have serious concerns about fans of the clone that isn't picked being hostile about the decision 21:36:14 or a txt explaining how to choose 21:36:34 True, but we always have picked a clone. Back in 2008 we picked one. 21:36:39 ah, my mock-core-configs does have alma, but epel is still hardcoded to use centos-8 21:36:52 also picking either alma or rocky loses us an arch (ppc64le), which is bad even if it's not very common 21:37:04 there are currently:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7d333ef599ae7a8037a81779577227bfbb6c398d) 21:37:13 and the hardcoded epel-8 ones 21:37:17 carlwgeorge: that is solved by a mail asking opinions 21:37:18 agreed with pgreco, epel-rhel, epel-alma, epel-rocky with a fake epel8 config that throws an error telling you how to choose is probably nice 21:37:19 I think the changable symlink idea is sensible. 21:37:32 tdawson: i don't think making that mistake previously is sufficient cause to keep making it 21:37:47 wrt ppc64le, both ar working on including it 21:37:56 SSmoogen: ah, I was searching wrong, thanks 21:38:09 ftr, this can be done easily: 'ln -s /etc/mock/alma+epel-8-x86_64.cfg ~/.config/mock/epel-8-x86_64.cfg' 21:38:09 pgreco: i don't see how a small sample mail poll would solve that problem at all 21:38:24 I dont' think breaking everyone's epel config is a good solution ... altough I do like pgreco's solution ... if it's possible. 21:38:26 we would want to ask for almalinux-epel-8- rockylinux-epel-8- and a redone epel.cfg which says 'we don't know what you want to do so please choose.' 21:38:38 you don't endorse, we don endorse, the poll chose the default 21:39:09 I really prefer choosing alma or rocky as a default, so it works ootb 21:39:26 but no default is "negotiable" 21:39:37 and regardless of the poll results people who weren't aware of the poll (the vast majority) will feel slighted and will claim red hat is conspiring against them 21:39:56 praiskup: i didn't know that would work. if it does... solution solved 21:40:01 bring Sokel and themayor, flip a coin, you have a default 21:40:13 and we have a config that works 21:40:25 i know it may seem i'm being paranoid about this, but i've already observed this kind of behavior 21:40:28 Considering how many people still dont' know that CentOS Linux 8 is going away ... I believe 99% of the people won't even notice the change from CentOS to Alma/Rocky 21:40:32 regarding the ppc64 build, yes we’re working on it. I believe we will have beta by next week 21:41:02 themayor: even better, the first one to have ppc64le is the new default 21:41:10 * nirik sighs. 21:41:12 Ha! 21:41:30 yeah tbh, if one of the clones ships ppc64le and the other doesn't, that makes the decision easier 21:41:50 * mboddu is here, sorry for the delay 21:41:56 i'll also point out that choosing rhel gains us an arch, rather than losing an arch (even if temporarily) 21:41:57 I am just tired of the drama. 21:42:23 * nirik really prefers "you need to set a default" by default, and make epel just an add on to all the compatible el distros configs. 21:42:37 * carlwgeorge agrees with nirik 21:42:44 We’ll also hopefully have s390 before long. It’s just a lot harder to bootstrap off fedora 21:43:06 as I said the last time, IMO having no default is better than having RHEL as the default, as RHEL is functionally broken for most users 21:43:26 at least with no default it's obvious since the beginning that one needs to choose 21:43:32 exactly 21:43:36 yes 21:43:37 Let's say we do the "you need to set a default" route. How easy / hard would that to setup and/or script ? 21:43:41 to nitpick: thats ppc64le and s390x. ;) ppc64 is the old big endian one no one really supports and s390 is the old 32bit one... 21:44:11 praiskup: ^ to tdawsons question there? :) 21:44:15 i don't see a difference between "choose a default" or "set up your rhel sub or choose a clone" 21:44:26 I was thinking about https://paste.centos.org/view/raw/45abe297 21:44:31 (automated variant) 21:44:35 it doesn't have to be the same default for different arches, no? 21:44:52 e.g. set alma to be the default for most arches, and rhel for s390x 21:45:11 (most people running mock locally will only try x86_64 anyway, and maaaybe aarch64) 21:45:13 I still think that RHEL is better, and Red Hat should make consuming RHEL easy for Fedora users 21:45:26 * carlwgeorge nods in agreement 21:45:27 praiskup: +100 :) 21:45:50 praiskup: That looks good. Is that a patched mock? Or just something you wrote up? 21:45:54 praiskup: that will be ideal, so as long as users have other targets they can use, that's probably better than bikeshedding indefinitely 21:45:57 salimma, yes, it can be different for different arches 21:46:23 tdawson, that pastebin is just a doc text file 21:46:57 I wonder... with that, would fedpkg local just hit that with mock? and we could have people just configure at the mock level? or do you think we should have fedpkg do something else? 21:47:35 dunno, I would expect that interactive terminal is attached ...? thus mock would be able to ask 21:47:50 Well, no matter what the decision, I think being able to set the fedpkg default on my own, or a group of machines, is a good thing to have. 21:48:25 "configurable" fedpkg default woudl be a new thing, the default in fedpkg is hard-coded 21:48:30 oh, absolutely, for me the default is just so that it works ootb 21:48:52 ideally fedpkg would just work if such a symlink is already set up for mock 21:49:31 yes, if epel-8-x86_64 symlink exists, and fedpkg hard-coded default is epel-8-x86_64, then it would work 21:49:34 * cyberpear wonders if fedpkg be rebased onto rpkg? I see the latter no longer uses python-rpkg at all. (or some other meeting would be better) 21:50:51 i like the `ERROR: epel-8-x86_64 configuration doesn't exist` + helpful suggestions UX, that seems like a really reasonable path forward 21:51:36 So ... if we removed the default, it would be possible for alma-release, redhat-release, rocky-release to create those symlinks, wouldn't it? It would just be a trigger on the mock package. 21:52:05 yup 21:52:12 yes 21:52:16 * nirik nods 21:52:25 so they could default it on their variant... 21:52:30 And if we patched mock to do what praiskup suggests, that would account for Fedora, and all the other variants. 21:53:02 Ha ... I just called Fedora a varient ... I was meaning things like OpenSuse and such. 21:54:06 Huh ... did we just agree on this? 21:54:13 as close as we're gonna 21:54:32 pgreco: What are your thoughts? Does that seem reasonable? 21:55:29 I think so 21:56:46 I also like this plan, it provides clarity and gives users a way forward 21:56:59 Hmm ... one thing is that it will be sorta hard to get all those "releases" fixed quickly ... I'm thinking we might put the trigger for the links in mock, and have them trigger on rocky-release, alma-release and so forth. 21:57:29 I think it is reasonable since we still need to write up the instructions for say a Fedora developer to make RHEL work as it needs to have certs in /etc/pki/entitlement 21:57:52 SSmoogen[m]: those are written up on the mock wiki already 21:57:56 tdawson: if we send an email to the list, we can ping the right people 21:58:17 themayor is already here, I can ping the rocky side 21:58:35 OK, I think I can get an email written up ... as well as add this to the issue. 21:58:46 It seems like a sane way to do it 21:58:57 clones also don't have to do anything other than suggest to their people to use `{clone}+epel-8-*` configs 21:59:13 As much as I would like to see Alma be the default, I think this a good way forward for everyone 21:59:21 setting up a triggered symlink is a nice to have but not critical 21:59:22 Yep 21:59:48 when there will be *-release default, mock will not be able to ask that questions 22:00:20 honestly i'd still prefer every get used to using `{base}+epel-8-*` configs, and have the `epel-8-*` instructions be there just for legacy compat 22:00:38 yeah, logically that makes more sense. 22:01:04 carlwgeorge Although I agree with that, the fedpkg problem is the biggest problem to me ... and we know how long it takes to get anything through fedpkg. 22:01:31 praiskup: good point. a clone shipping that symlink would equate to them taking that choice away from their users, even though i imagine most wouldn't care. 22:01:47 yes, that... 22:01:47 tdawson: fedpkg doesn't need any changes in this scenario 22:02:31 fedpkg mockbuild already uses `epel-8-*`, which would result in the choices output once mock has it 22:02:52 * praiskup nods 22:03:48 Looks like our time is up. I'll write things up on the issue first. After I have that, please comment and we can start sending out emails. 22:04:25 sounds good. 22:04:40 thanks tdawson! 22:04:49 Thanks everyone for coming and contributing to the discussion. We'll talk next week if not sooner. 22:04:52 good meeting y'all, till next time 22:04:58 see ya!!!! 22:04:59 #endmeeting