21:00:28 #startmeeting EPEL (2023-02-22) 21:00:28 Meeting started Wed Feb 22 21:00:28 2023 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_(2023-02-22)' 21:00:29 #meetingname epel 21:00:29 The meeting name has been set to 'epel' 21:00:31 #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge 21:00:31 Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson 21:00:32 #topic aloha 21:00:33 .hello robert 21:00:34 #topic End Of Life (EOL) 21:00:34 rsc: robert 'Robert Scheck' 21:00:35 RHEL 7 will go EOL on 2024-06-30 21:00:37 CentOS Stream 8 goes EOL in 2024-05-31 21:00:37 hello 21:00:38 CentOS Stream 9 goes EOL in 2027-05-31 21:00:50 .hi 21:00:51 carlwgeorge: carlwgeorge 'Carl George' 21:00:58 Hello rsc and ssmoogen 21:01:02 Hi carlwgeorge 21:01:37 morning 21:01:38 .hi 21:01:39 dherrera: dherrera 'Diego Herrera' 21:01:49 Morning nirik 21:01:50 .hello dcavalca 21:01:51 davide: dcavalca 'Davide Cavalca' 21:01:55 Hi dherrera 21:02:08 Hello davide 21:02:12 .hi 21:02:13 salimma: salimma 'Michel Alexandre Salim' 21:02:19 Hi salimma 21:03:02 Oh ... I just realized I pasted the EOL topic right after aloha ... oh well 21:03:26 .hello yselkowitz 21:03:27 yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' 21:03:37 I believe Aloha means both hello and goodbye ... so it fits. 21:03:42 Hello yselkowitz[m] 21:04:24 Hawaiian is very efficient that way :) 21:04:26 Hi! 21:04:34 Hi dminer 21:04:39 hi all 21:05:10 #topic EPEL Issues https://pagure.io/epel/issues 21:05:12 https://pagure.io/epel/issues?tags=meeting&status=Open 21:05:33 The observant might notice we dont' have any issues marked with meeting. 21:05:42 21:06:03 This is either going to be a quick meeting, or we'll finally get to all those little things that people haven't had time to bring up in the Open Floor. 21:06:05 void* seems relevant, that means we can talk about anything right 21:06:17 #topic Old Business 21:06:45 Basically ... but I figured I'd bring up Old Business, just incase someone wants to bring up old Business, otherwise we'll have the whole time for Open Floor 21:07:16 I don't have any Old Business in my notes ... does anyone have any old business that I forgot about? 21:07:25 I've something (hopefully small) for the open floor, so let's go for old business first? 21:07:31 i've got an open floor thing when the time comes 21:07:40 same 21:07:49 OK, let's go for open Floor 21:07:56 #topic General Issues / Open Floor 21:08:10 rsc: Looks like you were first 21:08:40 According to https://bugzilla.redhat.com/show_bug.cgi?id=2090958, elinks is a buildroot-only package in RHEL 9 - with no package outside. Does this still prevent EPEL 9 branching? 21:09:05 I know buildroot-stuff needs workarounds for missing -devel, but the whole package in buildroot-only as well? 21:09:06 If that is true, it shouldn't 21:09:14 as long as no subpackages are shipped, then it shouldn't 21:09:40 https://git.centos.org/rpms/elinks/branches - nothing? 21:10:15 rsc: that's not always the best to go off of, sometimes buildroot only things miss getting exported 21:10:44 And https://gitlab.com/redhat/centos-stream/rpms/elinks/-/blob/c9s/elinks.spec doesn't show any subpackage. 21:10:47 other than debug* stuff, elinks is the only subpackage, and it's not shipped. so yes an epel9 branch request should go through. 21:11:25 Okay, then I'll link the meeting log in the RHBZ - and would be fine :) 21:11:37 rsc: Sounds good. 21:11:40 Thanks & next? :) 21:11:49 i can post a comment to those folks telling you it can't go into epel, i've got something i can copy/paste 21:11:58 i've had to fight this battle before 21:12:06 carlwgeorge: ah, welcome! 21:12:21 carlwgeorge: You were next on the Open Floor list. 21:12:24 just got to find one of the bzs i said it in before 21:12:45 You know you are on the wrong side when you get a form letter reply. :) 21:12:57 carlwgeorge: Or do you want davide to go while you find that bugzilla? 21:13:11 nah i'll do that after the meeting 21:13:20 ok, then your turn 21:13:32 my item is something we've been discussing withing the cpe epel team, which is a docs overhaul. our current docs have a lot of info but the organization is pretty bad. 21:13:58 first step is coming up with an outline. i've got a preview of that here https://carlwgeorge.fedorapeople.org/epel-docs/epel/ 21:14:57 it's expected that the sidebar links don't work, as the content isn't converted over yet. just wanted to give folks a heads up in case they want to get involved once it comes to bringing more people in. 21:14:59 improving docs is a great thing to do! 21:14:59 Is the navigation supposed to be broken? 21:15:00 indeed! 21:15:39 carlwgeorge: What is meant by "Workflow" ? Will that be new content, or is there a section(s) that will go in there? 21:15:47 FWIW, when I overhauled the wiki docs a long time ago (epel7 days) I tried to setup things into use cases... ie, have all the maintainer stuff in one flow, users in another, etc... and I tried to do away with the faq, but people kept bringing it back. ;( 21:16:14 yes that will be new content, mainly since epel10 will be different and we'll need something to reference for folks learning the difference 21:16:34 carlwgeorge: OK. Good idea. 21:16:46 I think it's important to make the 'I just want to use epel' case front and center and have the 'I want to contibute to epel' be for those that want it... 21:17:13 that's the idea with the contributor guide section 21:17:29 Yes, but the first page needs a "I just want to use epel" button 21:17:51 Right now, there is just a "Want to help?" button (which is great, but doesn't help users) 21:18:21 Actually, there isn't even a "Want to help button" ... that is actually "What to help with Fedora Docs" 21:18:22 I'd personally put the first 3 things on top level and stuff all the rest under a 'contribute to epel' or something, but thats just me. Any docs improvements are welcome. 21:18:23 to reiterate, this is far from the final version, i just threw some basics on the front page. it can absolutely link to the setup page. 21:18:29 tdawson: oh...right. 21:18:49 nirik: I've also never been a huge fan of FAQs. They often get disorganized, are hard to search for, get repetitive, and/or don't answer the questions people want. 21:18:51 .hello ngompa 21:18:52 Eighth_Doctor: ngompa 'Neal Gompa' 21:18:53 👋 21:18:57 * gotmax23 waves 21:19:02 Hello Eighth_Doctor 21:19:09 Hi gotmax23 21:19:16 Eighth_Doctor: howdy! 21:19:19 .hi 21:19:21 gotmax23: gotmax23 'Maxwell G' 21:19:22 yeah, answers should be in the sections for the thing you want to do. ;) 21:19:23 KILL THE FAQ 21:19:26 hey Conan Kudo 21:19:32 exactly 21:19:36 FQAs what you should have instead :P 21:19:38 carlwgeorge: How can we help / give feedback to the layout ? 21:20:19 probably 1on1 after the meeting, this mix of comments is hard to follow 21:20:39 I am going to say 'publish it now' and fix it from feedback 21:21:18 I say that because my attempts to update the docs ended up with 'feedback paralysis' before I hit publish 21:21:35 Can you start a thread on the ML once you're ready for more feedback? It'd be great to hear from other developers and users who aren't part of the EPEL SIG "bubble" 21:21:54 Although I like ssmoogen's advise, we still have to go through and figure out which stuff goes where. Most will be fairly simple, but moving all the FAQ stuff will take a while. 21:22:10 As for the layout, I think the Package Request process should be higher up in the nav and highlighted better 21:22:18 how about discussions? :D 21:22:36 * gotmax23 does not like those much 21:24:08 carlwgeorge: You've got some initial feedback, and I can help go through with you after the meeting if you need. Anything else? 21:24:20 nope, we can move on 21:24:33 carlwgeorge: Thank you very much for getting the ball rolling on that. 21:24:39 davide: I believe you were next. 21:24:45 yeah, thanks Carl 21:25:13 so, I mentioned the last time that I needed nodejs-devel, and filed https://bugzilla.redhat.com/show_bug.cgi?id=2170215 to get it added to CRB 21:25:27 in the meantime, I've put together a nodejs-epel to make this available as a stopgap 21:25:40 I'd appreciate some eyeballs as this stuff is pretty nasty 21:25:49 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4dfc0570b8 and https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2023-43eabb3ad6 21:26:10 I attached the diff from the c9s spec to Davide's in the bugzilla, so it's easier to eyeball... because yeah, hairy stuff 21:26:18 I had to use epel9-next here because the %dist for nodejs is different in RHEL 9.1 vs CentOS Stream 9 21:26:31 i.e. el9_1 vs el9 21:26:45 that's all I had :) 21:27:57 davide: OK. Thank you for doing that. I'm sortof surprised others haven't hit this yet. 21:28:36 so was I, guess I'm the first one to try and branch a nodejs thing for epel9 ? 21:28:39 lucky me :) 21:28:44 As far as I saw, those were the only people who said they had something for Open Floor. anyone else have anything they want to bring up? 21:28:47 :) 21:28:52 nodejs stuff is not exactly fun to package so people avoid it I think 21:29:15 oh i had two minor tangents from my docs thing that i just remembered 21:29:29 carlwgeorge: Go for it. 21:29:30 I can provide a short ansible update if people are interested. 21:29:36 no decision needed, just food for thought 21:29:45 I have a minor thing after that too. 21:29:45 I have something to bring up after this too 21:29:45 I also have a somewhat docs related tangent :) 21:30:59 first one, epel docs sources are in pagure. other parts of the docs are in gitlab, with a few in github. i actually couldn't find other sections of the docs that use pagure. at some point do we want to consolidate and migrate these to gitlab as well? 21:31:31 Packaging Guidelines are in EPEL 21:31:32 it's not urgent and we don't have to migrate as far as i'm aware, but gitlab does have better review tools for prs 21:31:59 ah of course i forgot that big one 21:32:06 s/EPEL/Pagure/ 21:32:08 Ooops 21:32:10 I don't care, will do whatever people want... of course just staying where we are is less work, so I would slightly favor that 21:32:46 I have a slight preference for GitLab just for better notifications, but... no strong preference either way 21:32:58 something to stew on 21:33:36 the other thing, we debated before about calling epel a sig. while setting up the outline i noticed this page, and i think we would kinda fit under "Initiatives & Special Interest Teams" https://docs.fedoraproject.org/en-US/engineering/ 21:33:47 I don't think it's worth moving away from Pagure unless it starts causing us actual problems 21:33:59 I know there's issues with it, but I think it works well for our purposes 21:34:35 well those issues are actual problems, like posting comments fails if you haven't reloaded the page recently 21:34:40 sure, although I see some things under there call themselves SIGs too. :) clear as mud 21:34:49 carlwgeorge: why not "Core Teams" as "Fedora Package Maintainers" are? 21:34:54 on my new front page i used the term "ongoing initiative", does everyone at least not hate that? 21:35:03 carlwgeorge: that should be fixed now. There was a problem with the eventservice 21:35:27 I don't really remember the beginning of the discussion. Why did people object to calling ourselves a SIG again? 21:35:41 confusion between the epel sig and epel packagers sig 21:35:52 gotmax23: Mainly because we have a SIG within a SIG, and it get's complicated. 21:36:08 epel is special 21:36:36 i think initiative is broad (vague?) enough to work for us 21:37:08 SIG and SIG prime 21:37:19 carlwgeorge: Oh, I like the term initiative ... but as you said at the beginning, just stuff to think about for now. 21:37:25 coffee klatch? :) Iniative is fine. 21:37:26 again, not something we need an answer on right now. i can create a tracking issue or discussion thread if we want to have a longer term discussion on it. 21:37:33 There's the python-sig and python-packagers-sig. One is people generally interested in Python and Fedora and the other is proven Python packagers who co-maintain the python stack. 21:37:49 that's a recent pivot iirc 21:37:51 I don't like initiative 21:38:18 carlwgeorge: They've been wanting to change this for years but were stuck on releng issues 21:38:49 i think they'll start to have the same confusion issues we did, when the reference the sig which one they're talking about 21:39:11 anyways that's all my open floor things, i believe others had some more stuff 21:39:20 Anyway, before this takes too much time ... let's leave this for something to think about, and gotmax23 had a short update on ansible 21:39:23 EPEL is a subproject of Fedora 21:39:35 it's the only remnant left of Fedora Extras :) 21:39:41 I'm ok with subproject too 21:39:41 I feel initiative does not encompass everything we do. Initiatives are usually temporary and very focused and scoped. We're more of a subproject. 21:39:44 yeah... heads up, Rust packaging just got revamped in Fedora, and Fabio flagged there's work to do to get that into EPEL 9 21:40:16 (nobody bring up Fedora Legacy... 👻) 21:40:35 anyway. can we get on with the other items 21:40:36 partly to do with deprecating old RPM macros (probably not insurmountable), partly because the new tool uses python 3.11 features so we... uh, might need to build a py 3.11 stack in epel9 like we have 3.8 for epel8? 21:40:47 . I discussed it with him a bit. It can be built for the alt python3.11 stack once 9.2 comes out. 21:40:59 s/.// 21:41:02 yeah we're getting py3.11 on RHEL 9.2 21:41:09 sweet, so yeah let's cross our fingers nothing needs it before then 21:41:14 so epel-next first and then epel? 21:41:31 https://gitlab.com/redhat/centos-stream/rpms/python3.11 21:41:33 yeah, probably good to start building this in epel-next, we don't have to wait 21:42:04 yeah, it could be incubated in epel9-next, but I thought y'all decided to avoid epel9-next due to too many branches to maintain? 21:42:13 I think Fabio preferred not to 21:42:19 you can be evil and use epel9 and use fedpkg to target epel9-next anyway 21:42:22 but in this case getting the tooling ready in epel9-next is warranted 21:42:53 in the past the issue was: if a rust package needs the new rust compiler, do we wait until a minor release or put it in -next 21:42:53 (don't do that, we don't have tooling to migrate builds from next to regular) 21:42:55 I'm a little confused, are we talking about rust or ansible, or both? 21:43:15 Rust I thought... are we talking about Ansible too? 21:43:15 Now we're talking about Rust :) 21:43:16 cargo2rpm is written in Python 21:43:17 rust2rpm too 21:43:22 thank god for that 21:43:45 oh sorry, I missed tdawson inviting the Ansible topic 21:43:46 I'm done, go ahead gotmax23 21:44:49 Every RHEL 8 and 9 minor release, RHEL updates ansible-core to the next major version. we do corresponding major version bumps of ansible each release. 21:45:44 In addition, they're building ansible for a different Python stack. 3.9-> 3.11 21:46:08 Ahh ... so the python3.11 is related ... ok. 21:46:49 convergence :) 21:46:56 It's been a bit difficult to sync with RHEL and Stream, but I'm kind of getting the hang of it 21:47:47 I relaxed the version constraints which helps somewhat, but we can't do anything preemptive when they change the Python versions, because it needs to be installed to a different location. 21:48:20 * nirik nods sadly. 21:49:12 I don't know why they keep changing the Python versions. In RHEL 8, it started at 3.8, then it moved to 3.9, and now it's moving to 3.11. 21:49:12 Sounds like both you and salimma are hitting the same python issues. 21:49:24 ansible-core is only Supported in RHEL for linux-system-roles and another specific usecase which doesn't depend on this, but it sure makes our work hard. 21:49:31 RHEL 8 started at 3.6 I think 21:49:41 Yeah. I'm happy to help with the rust stuff 21:49:48 and then 3.8. 9 starts at 3.9 21:49:49 Michel Alexandre Salim 🎩: Yes, but ansible-core was never packaged for 3.6. 21:49:52 yeah, hard to keep track 21:49:58 oh, right, 3.6 was probably too old 21:50:04 correct 21:50:25 back when ansible was the engine package. ;) 21:50:30 the older ansible (pre-core) was I think? one of me colleague noticed a dependency not available for 38 but I forgot which 21:50:41 I worked to set up the macros in EPEL 8 so we could build for alternative Python stacks easily 21:51:05 gotmax23: Thank you for that. 21:51:09 nice 21:51:27 FYI I've been using the draft guidelines for using alternative stacks and it's been working great 21:51:46 Yeah, https://fedoraproject.org/wiki/EPEL/Python3X 21:51:47 should we get that promoted? 21:51:47 * nirik has another meeting at the top of the hour will have to drop then. 21:51:47 For RHEL 9, you can use this with the pyproject macros also 21:51:48 to official guidelines I mean 21:52:18 gotmax23: Anything else? Cuz I know nirik had something for Open Floor? 21:52:18 they are out of sync with how Python alt-stacks are packaged now 21:52:23 Potentially. But it would have to be specific to EPEL. They Python maintainers don't want to maintain full alt stacks in Fedora. 21:53:04 well, in the most recent conversation I had with them about it, they don't see a lot of upside for Fedora 21:53:10 could we pause and have nirik cover the item he needed to say? 21:53:20 Since nirik needs to go right on time, let's pin the python stuff, and come back to it when he's done. 21:53:27 nirik: Go for it. 21:53:27 Yeah, go ahead :) 21:53:55 Nothing important. I was just going to mention https://pagure.io/releng/issue/11291 (cobbler for epel8). If anyone knows any reason we shouldn't just branch it... 21:54:31 i don't know of any 21:54:31 cobbler is in a default module i think 21:54:37 checking 21:54:42 I think it was built in some super early stream days... but it's not at all shipped anymore. 21:55:32 ah, koan and python3-koan are built from the cobbler srpm 21:55:36 anyhow, that was it, you could comment in the ticket if you like. :) 21:55:47 sure 21:56:10 parts of cobbler client tooling are in the spacewalk module 21:56:11 errr rhn client tools module 21:56:14 thanks 21:56:15 but we could treat it as an exception, given that the rhn client tools module is dead in RHEL 21:56:27 source? 21:56:31 we used to do that for ansible before the whole ansible-core thing happened 21:56:58 ansible was in a different Ansible Engine channel 21:57:04 I love that cobbler src.rpm uses fedorahosted as it's upstream url. ;) 21:57:27 ansible was in ansible-engine, then rhel-extras, then not in rhel-extras... 21:57:31 Eighth_Doctor: right, but i'd like to see a deprecation notice, not tribal knowledge 21:58:08 * Eighth_Doctor grumbles that the lifecycle documents require redhat login to view now 21:58:14 no, rhel-extras first, then ansible-engine 21:58:24 so, on my RHEL 8 machine, I cannot find any mention of cobbler, not even in modules. 21:58:48 look for koan 21:58:54 kickstart-over-a-network 21:59:05 yeah, I guess it was some other channel than just ansible-engine, but it was in some other channel before rhel-extras I seem to recall 21:59:50 anyway.. nirik has to go and we need to put comments in the ticket 22:00:11 I also have to jump 22:00:15 * nirik waves, thanks everyone 22:00:19 OK, sorry, I got distracted 22:00:37 Thank you all for comming 22:00:42 thanks all 22:00:49 I did find it in koan, but it definatly isn't a default module. 22:01:03 I need to shutup myself now. :) 22:01:12 `rhn-tools 1.0 [d]` 22:01:50 ugg ... yep 22:02:12 OK, trying to close us out. Put comments in the issue. 22:02:16 Talk to you next week. 22:02:18 well this is fun 22:02:26 rhn-tools has no info on the lifecycle page at all 22:02:29 https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle 22:03:03 I'll bring it up next week in old businness. 22:03:07 #endmeeting