20:00:21 #startmeeting EPEL (2023-09-20) 20:00:21 Meeting started Wed Sep 20 20:00:21 2023 UTC. 20:00:21 This meeting is logged and archived in a public location. 20:00:21 The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 20:00:21 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:22 The meeting name has been set to 'epel_(2023-09-20)' 20:00:23 #meetingname epel 20:00:23 The meeting name has been set to 'epel' 20:00:24 #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge 20:00:24 Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson 20:00:26 #topic aloha 20:00:31 .hi 20:00:32 rcallicotte: rcallicotte 'Robby Callicotte' 20:00:33 .hi 20:00:35 pgreco_: Sorry, but user 'pgreco_' does not exist 20:00:42 .hi 20:00:43 dherrera: dherrera 'Diego Herrera' 20:00:50 .hi 20:00:51 pgreco: pgreco 'Pablo Sebastian Greco' 20:00:58 Hi rcallicotte pgreco and dherrera 20:01:01 morning 20:01:06 .hello salimma 20:01:07 michel-slm: salimma 'Michel Lind' 20:01:15 Morning nirik 20:01:24 Hello michel-slm 20:01:28 * michel-slm stuck on a throttled charger at a Walmart 20:01:35 #chair michel-slm 20:01:35 Current chairs: carlwgeorge dcavalca dherrera gotmax23 michel-slm nirik pgreco salimma smooge tdawson 20:02:24 .hi 20:02:25 carlwgeorge: carlwgeorge 'Carl George' 20:02:43 Hi carlwgeorge 20:05:24 #topic End Of Life (EOL) 20:05:25 RHEL 7 / epel-7 will go EOL on 2024-06-30 20:05:27 https://endoflife.date/rhel 20:05:28 CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31 20:05:30 CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31 20:05:31 https://endoflife.date/centos-stream 20:05:50 #topic EPEL Issues https://pagure.io/epel/issues 20:05:51 https://pagure.io/epel/issues?tags=meeting&status=Open 20:06:20 Let's start with the oldest one first. 20:06:25 .epel 245 20:06:26 tdawson: Issue #245: Revisiting our package request template - epel - Pagure.io - https://pagure.io/epel/issue/245 20:06:59 michel-slm: Did you have more that you wanted to discuss on this? Or did we just not get the meeting tag taken off? 20:07:04 Some other work got in the way so I haven't written up the proposed changes, sorry 20:07:20 Not a problem. 20:07:23 I think I planned to skip this meeting and have the PR up 20:07:37 But yeah take the tag off and I will readd it when ready 20:07:40 .hello ngompa 20:07:41 Son_Goku: ngompa 'Neal Gompa' 20:07:43 Sounds good. 20:07:48 Hello Son_Goku 20:08:04 I'm out walking about, but I'm still here too 20:08:06 Then that takes us to the new issue ... although we mentioned it last week 20:08:16 .epel 247 20:08:17 tdawson: Issue #247: Revisting conflicts policy for EPEL compat packages - epel - Pagure.io - https://pagure.io/epel/issue/247 20:08:54 carlwgeorge: Did you want to take us through this one? 20:09:16 i think there was some confusion last week that i was pressing for an immediate answer, but just to be crystal clear, this is something we can (and probably should) have open for discussion for a bit 20:09:43 i'm happy to create a fedora discussion thread about it if folks would like to see that 20:09:53 carlwgeorge: you confirmed that my "provides/obsoletes" theory doesn't work, right? 20:09:54 It does mean the 'epel doesn't conflict with rhel at all' message would change a bit... :) 20:10:13 pgreco: for what? 20:10:16 pgreco: this is a separate thing 20:10:39 but yes i did confirm that modular filtering applies to virtual provides as well 20:10:48 carlwgeorge: ok, got mixed up 20:10:58 no worries, i brought them up back to back 20:12:06 My understanding is that our no-conflicts policy is the main reason Red Hat support doesn't immediately de-support RHEL systems with EPEL enabled and used 20:12:23 So I'm hesitant to change that 20:12:50 we're not changing the policy per se, we're carving out an exception that mirrors what fedora and rhel already do within their own package sets 20:13:19 Son_Goku: That's a good point. If the discussion leans towards us updating the policy, it would be good to get an official call from RHEL support. 20:13:31 Does RHEL do this with devel packages already? I didn't think they did... 20:13:48 making a compat package exception is not going to change red hat support's outlook on epel, and i'd be happy to have that discussion with anyone who thinks their policy needs to change. 20:14:13 That's my primary concern tbh 20:14:25 it's not hard for me to point at customer feedback about how important epel is and talk them out of it 20:14:53 we already grant exceptions for things like deprecated packages, and rhel support didn't throw a fit about that 20:14:53 I believe the RHEL compat packages do not have -devel packages ... but it's something I can look up. 20:15:10 My secondary one is tracking those to prevent them carrying around forever into future EPEL branches 20:15:24 Should that be explicitly declared an aim for EPEL? That whatever we do should be acceptable for RHEL customers 20:16:28 No, it doesn't matter what is acceptable to RHEL customers ... it's more Red Hat policy that I'm concerned about. 20:16:44 Right 20:16:53 Ah. I mean 'that RHEL customers can use without losing support' 20:17:52 simple example, in rhel 8 pipewire-devel and pipewire0.2-devel have conflicting paths 20:18:59 actually scratch that, looks like pipewire-devel did some relocation magic 20:21:02 ok an accurate example, bind9.16-devel conflicts with bind-devel 20:22:09 Most things using pkgconfig, cmake, or some config tool thingy are straightforward to relocate. It's the rest that isn't. 20:22:21 not the exact same, but mysql-devel conflicts with mariadb-devel 20:23:15 i disagree about pkgconfig stuff being straightforward to relocate. if it were then fedora would do it more often instead of having conflicting compat devel packages. 20:23:16 * nirik wonders if we already have some epel devel packages implicitly conflicting with rhel packages. 20:23:49 nirik: Nope ... I already checked on that. 20:24:32 seems like people still have plenty of thoughts on this, so i'll make a discussion thread and people can write up feedback there 20:24:40 I think it's a very good point. If RHEL itself has conflicting -devel packages, I see no problem with epel having them. 20:24:53 carlwgeorge: Good idea. 20:25:11 are there things that would right away want to use this? or we don't know? 20:25:39 there was one i was looking at last week but i don't recall the name offhand 20:26:15 libgit2_1.6 20:26:38 Jack conflicts with PipeWire today 20:26:48 * michel-slm need to hit the road in a couple of minutes. See everyone next week 20:26:56 The development package, I mean 20:27:01 Bye michel-slm 20:28:11 Since carlwgeorge is going to send out an email for discussion there, I'm going to time-box this discussion on this issue and move on. 20:28:31 Thank you carlwgeorge for bringing this up and I look forward to the email. 20:28:54 i said discussion (discourse) thread, but i can send an email also for wider visibility 20:29:14 carlwgeorge: Ahh ... ok, either way. 20:29:32 i like how fedora changes are being done, with a devel quasi-announcement email redirecting people to a discussion thread 20:30:10 I was about to ask that. I have a hard time finding things in discourse. Once I've found them I'm ok. 20:30:47 #topic Old Business 20:31:49 I wanted to point everyone to the new EPEL Steering Committee page pull request - https://pagure.io/epel/pull-request/246 20:32:39 carlwgeorge is the only one who has given a comment ... and although I'm fine merging it, I wanted to make sure someone doesn't have any major problems with it. 20:33:15 I haven't had a chance to review it yet 20:33:19 I'll look at it later this week 20:33:41 I dug through emails and epel meeting minutes to find the dates, but it's possible I got some wrong. 20:33:43 it's basically what was on the wiki, with some missing pieces filled in 20:33:50 +1 20:34:39 nirik is the longest serving member... holy wow :) 20:34:50 Yep, over 13 years. 20:34:55 og 20:36:01 just skimmed over it and it looks good, except for inconsistencies in spaces inside () for usernames 20:36:37 Anyway, there isn't a rush here ... I'll get the spaces fixed up ... now that you said that it will drive me nuts to leave them. 20:36:58 can't unsee 20:36:59 OCD FTW :D 20:37:03 I'm old! :) 20:37:26 haha yeah now I cant unsee them either 20:38:05 Is there any other Old Business that anyone wants to bring up? 20:38:24 * tdawson notes that smooge isn't here to give an Old Business joke ... :( 20:39:39 #topic General Issues / Open Floor 20:39:50 Does anyone have anything for the Open Floor ? 20:40:36 i got access to python-cbor2 so python-falcon will be in epel9 shortly. i think that was a blocker for mailman3. 20:40:48 Very nice 20:41:02 just a reminder that the EPEL survey is still up and running :) https://fedoraproject.limequery.com/epelsurvey2023 20:41:03 hurray! 20:41:59 carlwgeorge: nice :D 20:42:17 Thank you dherrera, not just for the reminder, but for getting the survey setup and advertised. 20:43:08 I have to say that getting the marketing team help on this was a great boost for this ^^ 20:43:23 got a sneak peak at some of the early responses. lots of 4 and 5 happiness scores (out of 5). 20:43:37 nice 20:44:11 cool 20:44:16 still get a few jokers that take the survey putting no for everything, then leave the free text comment "i use " 20:45:11 Anything else before we close the meeting? 20:45:40 one that made me lol (in a frustrated way) was a comment about epel making rhel change their policy on unshipped -devel packages 20:45:54 *laughs* 20:46:01 lol 20:46:18 alas, the relationship doesn't *quite* work that way :P 20:46:27 one can dream 20:46:44 there's a lot we could do to make it less painful, but at the end of the day, we have no say over RHEL 20:46:47 how does the saying go, "dream in one hand..." 20:47:09 or maybe it's "wish in one hand..." 20:47:18 the process we had during the beginning of EPEL bringup that allowed us to get stuff in quickly was really great 20:47:31 *EPEL 9 20:47:40 but also, one thing we didn't have then that we could have next time is ELN data 20:48:24 automatically creating epel10 branches based on eln workloads is a great idea that needs someone to dig into how the implementation would work 20:48:35 well, that's not quite what I meant 20:48:42 Oh, I remembered something I was going to ask ... I'm noticing IRC traffic is fairly low vs matrix. How many of here are NOT on the matrix channel? 20:48:46 I mean that we would actually know what the dep graph looks like 20:49:04 so we can get requests to RHEL early 20:49:21 I believe what Son_Goku meant was that RHEL would be able to see, before they start makeing CRB, what -devel packages we are going to need for EPEL. 20:49:24 I jumped on to matrix this week because the bridge is broken 20:49:25 tdawson: 🦗s? 20:49:29 tdawson: yes! 20:49:34 exactly 20:49:57 and after the branching point, we can also get comprehensive understanding of the graph split too 20:50:02 ah, i see 20:50:25 I "cheated" a lot during EPEL 9 bring up by using OBS to quickly graph out what was needed, but we should be able to do that entirely within our infra 20:50:25 that sounds a lot more like something on individual maintainers, rather than something we can do holistically for all of epel 20:50:48 not discouraging it of course, giving maintainers more data to do their thing is always good 20:50:50 it's something that I feel the content analyzer for ELN can be used for 20:51:26 we should be encouraging folks who expect to continue shipping stuff in future EPEL versions to get tracked in ELN 20:51:32 nirik: ... I know I'm old, but is that emoji a fish? 20:51:44 supposed to be a cricket. 20:51:57 Ahhh ... ok. 20:51:57 (ie, saying no one answered your question in the affermative) 20:52:49 I'm like rcallicotte ... when the bridge was broken I finally got neochat updated and installed ... and really liking being on Matrix. 20:53:02 well, it helped that I tracked down and fixed neochat :) 20:53:10 :) Yes it did 20:53:11 having it broken was annoying since I use it for my alts 20:53:21 Son_Goku +1 20:53:33 I love using neochat. Very nice 20:53:39 it's nice innit? 20:53:51 Yep 20:53:54 I use hexchat, maybe that is why I don't like IRC that much? 20:53:55 I think I have my user created, don't use it very much 20:54:14 if you prefer a more IRC-like experience, I also fixed quaternion 20:54:19 pidgin/znc for irc, elements(web) for matrix 20:54:20 * nirik tried neochat, but the lack of font / size options is a non starter for me. 20:54:22 and I believe tdawson brought it into EPEL 9 too 20:54:24 would anyone that's familiar with eln extras like to volunteer to send a call to action to discourse/list about putting epel workloads into eln extras, and the benefits it would provide? 20:54:32 nheko is currently what I use 20:54:44 nirik: too much gloss for me :P 20:55:09 not sure what you mean there... perhaps I have customized that away... 20:55:17 quite possible 20:55:36 carlwgeorge: I think the main folks who've done eln-extras stuff would be tdawson, myself, davide, and michel-slm 20:55:39 so one of us can take it 20:55:58 I would need to familiarize myself with it again, but I _could_ do it 20:56:14 yeah not necessarily trying to volunteer someone else, i'm just not the strongest with eln things 20:56:29 I have a grand total of two workloads in there :P 20:56:43 though I think technically one of them is owned by tdawson :P 20:56:52 That's what I was wondering about. 20:57:05 i suspect a well written informative call to action will motivate at least a few folks. there are probably a few who would love to have that graph you were talking about. 20:57:14 yeah, graphs are cool 20:57:24 We're going to have to totall redo the KDE one due to plasma 6 20:57:27 yup 20:57:32 that's going to be... fun 20:58:25 (it actually shouldn't be that bad) 20:58:51 Once the final cutover (when F40 branches) is done, and we dont' have the wild dependency swings, it will be much easier to create the graphs. 20:59:01 now that epel branch requests are really fast, is it still worth the effort to try to automatically create epel branches for eln extras workloads? 20:59:26 * nirik had something he was going to bring up... oops. and we are almost out of time. 20:59:38 carlwgeorge: I don't know 20:59:50 I think ELN is still a good signal of "intent-to-ship" 20:59:58 i love that `fedpkg request-branch epel9` gets me a branch in like <30 seconds now 21:00:03 nirik: If you can mention it before I close ... we can bring it up next week. 21:00:12 carlwgeorge: I know ... it's great. 21:00:35 Well, just wanted to note the last few comments in: 21:00:37 https://pagure.io/releng/issue/11540 21:00:41 Son_Goku: sure, i'm just specifically talking about putting in work to create those branches in advance like we talked about previously 21:00:43 Looks like our time is up everyone ... thank you all for being here and the good disucssions. And thank you for the work you do for EPEL and it's community. 21:00:52 basically epel9-next isn't ideal... but I don't know how we can or if we should fix it. ;) 21:00:56 I know I say that same thank you each week, but I really mean it, . 21:01:40 #endmeeting