21:00:41 #startmeeting EPEL (2022-12-21) 21:00:41 Meeting started Wed Dec 21 21:00:41 2022 UTC. 21:00:41 This meeting is logged and archived in a public location. 21:00:41 The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 21:00:41 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:41 The meeting name has been set to 'epel_(2022-12-21)' 21:00:43 #meetingname epel 21:00:43 The meeting name has been set to 'epel' 21:00:44 #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge 21:00:45 Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson 21:00:46 #topic aloha 21:00:48 .hi 21:00:49 salimma: salimma 'Michel Alexandre Salim' 21:00:50 * smooge is here to hand over the nuclear football back to President Dawson. 21:00:54 .hi 21:00:56 dherrera: dherrera 'Diego Herrera' 21:01:01 .hi 21:01:02 pgreco: pgreco 'Pablo Sebastian Greco' 21:01:12 .hi 21:01:13 carlwgeorge: carlwgeorge 'Carl George' 21:01:21 Hi salimma, smoog, pgreco and carlwgeorge 21:02:03 * tdawson takes the nuclear football and looks anxiously at it. 21:03:01 tdawson: I was at CERN today and your name came up, not gonna say in what context :D 21:03:02 * salimma thinks it's a trap 21:03:21 itsatrap.gif 21:03:28 thanks for spending your late evening with us pgreco 21:03:50 same to you salimma, i hear you are in a similar timezone 21:04:45 That's right ... this is really late for Europe. 21:05:11 #topic End Of Life (EOL) 21:05:11 Well it was sundown hours ago 21:05:12 RHEL 7 will go EOL on 2024-06-30 21:05:14 CentOS Stream 8 goes EOL in 2024-05-31 21:05:14 only if you adapt to the timezone... 21:05:15 CentOS Stream 9 goes EOL in 2027-05-31 21:05:22 oh no, I came back on Monday 21:05:24 so I'm just jet lagged 21:05:26 That's it folks ... thanks for comming ... talk to you next week ... 21:05:45 Oh wait ... I think there is a couple of things on the agenda ... 21:05:57 * smooge sits down again 21:06:18 #topic EPEL Issues https://pagure.io/epel/issues 21:06:19 https://pagure.io/epel/issues?tags=meeting&status=Open 21:06:37 i think the oldest one (#212) is settled and can be untagged 21:07:07 Thanks ... I was just about to ask about that one. 21:07:35 not sure if we normally leave those open until the underlying thing is resolved or just close after voting 21:07:52 #link https://pagure.io/epel/issue/212 21:08:35 .hello robert 21:08:36 rsc: robert 'Robert Scheck' 21:08:45 Hello rsc 21:09:18 I *think* we close it at this point. 21:09:35 I think so, the decision is made, now it's up to the maintainer 21:09:39 .epel 212 21:09:40 smooge: Issue #212: 'novnc' major version/breaking update in EPEL7 - epel - Pagure.io - https://pagure.io/epel/issue/212 21:09:56 They've properly annoucned it, we've done the vote. It might take some time before it get's built and released. 21:10:01 close it 21:11:24 Now for the second easiest ticket ... 21:11:32 .epel 215 21:11:33 tdawson: Issue #215: remove singularity obsoletes from apptainer - epel - Pagure.io - https://pagure.io/epel/issue/215 21:12:05 seems clear cut in this one that having the obsoletes is allowed by policy, as the package was a rename 21:12:13 Yep 21:13:01 Any negative votes about putting the obsoletes in? 21:13:48 the obsoletes is already there, so it's a no-op unless we want to recommend moving the obsoletes to the apptainer-suid subpackage 21:14:24 I agree ... and it looks like they are planning on moving the obsoletes to the apptainer-suid package anyway. 21:14:47 I am going to mark this as passed unless anyone objects. 21:15:09 I think it's ok 21:15:10 this would be option 3 from my list of all possible outcomes 21:15:23 :) Yep 21:16:42 And now for the nuclear football 21:16:51 .epel 214 21:16:52 tdawson: Issue #214: remove singularity provides from apptainer - epel - Pagure.io - https://pagure.io/epel/issue/214 21:17:03 i think this may be easier than we expected for the immediate question of removing the provides, as we have 3 +1s in the issue from committee members 21:17:10 yeah 21:17:31 I think even the maintainer now thinks adding the Provides to the -suid subpackage is better 21:17:45 https://src.fedoraproject.org/rpms/apptainer/pull-request/2 21:17:58 as I noted I'd like to see a SC vote on that because of the compatibility issues surfaced so far - when it's ready 21:18:13 that pr confused me, as it's basically a duplicate of my original pr with the changelog entry changed to give him credit for the changes 21:18:48 carlwgeorge: yeap, that was my take 21:19:06 for the future question of re-adding the provides (whether to apptainer or apptainer-suid), i'm strongly opposed to doing something different in fedora and epel 21:19:23 reminder that the apptainer maintainer agreed to remove the provides outright in fedora, but was asking for epel to diverge 21:19:37 yeah, that part really concerned me in the original proposal 21:19:50 that the maintainer doesn't care following guidelines for Fedora but wants to do their own thing for EPEL 21:20:12 if anything, in EPEL the need to maintain compatibility is stronger, not weaker 21:20:25 agreed 21:20:38 there is no justification to diverge from fedora 21:21:18 agreed 21:21:26 for the future question of adding the provides back, i think it should be the same decision for fedora and epel, and we can punt that to fesco 21:21:33 I always try to keep all my branches the same, with minimal conditionals... 21:22:21 If you diverge from fedora, is because you want to make it compatible, not because you want to make it different, I don't think that is acceptable 21:22:23 I agree with keeping Fedora and EPEL together, but that really isn't the debate at this time. 21:23:29 At this point, they have agreed to take the Provides out at this time. Because current configurations clearly are not compatible enough with singularity. 21:24:01 So, at this point, I think we're all in agreement that this is good. 21:24:03 should we also give the guidance about keeping fedora and epel the same, and deferring to fesco for appeals to add the provides back later? 21:24:42 Well, the pull request is for rawhide, so I assume they are doing the same for Fedora and EPEL 21:25:37 The big question I have is, do we want to discuss what "Compatable enough" is? Or do we kick that footfall to a future meeting? 21:26:28 Going from past experience.. discussions like that are better saved after holidays 21:26:31 i made my pr to rawhide as i was advocating for the same thing in both fedora and epel 21:26:39 family gatherings are going to be tough enough 21:27:03 smooge: I thought that's Thanksgiving :P 21:27:04 but yeah 21:27:19 let's keep this light 21:27:23 I agree with salimma's comment about reviting this, possibly with a new ticket. And possibly even getting Fedora/FesCO's comments on what consitutes "Compatible enough". 21:27:37 if we're going to recommend doing the same thing in fedora and epel, we don't even need to have the "compatible enough" discussion 21:28:11 the only reason this was an epel ticket was because he wanted to diverge 21:28:28 carlwgeorge: Yep ... hense bringing the Fedora people in, whichever are the correct ones. 21:29:38 any other votes before we close out the issue? 21:29:57 i vote we close out the issue 21:30:00 lol 21:30:03 So, are we in agreement that the current pull request - https://src.fedoraproject.org/rpms/apptainer/pull-request/2 works? 21:30:07 yeah 21:30:16 why not https://src.fedoraproject.org/rpms/apptainer/pull-request/1? 21:30:39 i'm not seeing a difference other than the changelog 21:31:01 it seems he opened it to do the same thing but keeping the provides, then commented out the provides, so they're effectively the same at this point i think 21:31:29 * carlwgeorge looks closer to see if he missed anything 21:31:32 yeah, I prefer accepting the original PR. though... we can't really dictate which one to merge, can we 21:31:49 generally even if I need to rework someone's PR I still give them credit, so... this stinks a bit 21:32:51 oh the runtime one is different 21:32:57 Carl removes the Obsoletes, this one keeps the obsoletes in 21:33:01 sif-runtime? 21:33:37 on singularity-runtime 21:33:57 and the maintainer also adds more blurb in the Summary stating this package 'is formerly known as Singularity'. that part is fine I guess 21:34:00 oh, that one didn't move did it 21:34:04 fixed 21:34:09 see https://src.fedoraproject.org/rpms/apptainer/pull-request/2#_1__28 21:34:31 There is also wording differences in some of the comments. 21:34:32 while Carl's remove that Obsoletes: https://src.fedoraproject.org/rpms/apptainer/pull-request/1#_1__28 21:35:04 singularity-runtime obsoletes (an old thing unrelated to this discussion) restored to it's original spot 21:36:13 Honestly, I don't care which. 21:36:59 i'm happy to merge this and https://src.fedoraproject.org/rpms/singularity-ce/pull-request/1 and push them out in the same bodhi update, or another proven packager can merge them 21:37:12 ideally they'll go out at the same time so the sif-runtime conflicts works as intended 21:37:56 carlwgeorge: Considering the package maintainer has been having this disucssion with us ... I think it would be best if they did the merges and builds. 21:38:24 yeah, I think give them a sidetag but ask that they don't push the Bodhi update, but we handle that part 21:38:30 they just can't submit a bodhi update that includes both as they're not maintainers of each others' packages 21:38:45 right. one of us can do that 21:38:57 they don't build against each other so i don't think the side tag is necessary 21:39:17 Wow ... this discussion just changed to something completely different fast 21:39:35 i agree with tdawson on this... and I am not following where things are going 21:39:36 sorry about that, we can put a pin in this and pick it up in #epel after the meeting 21:39:55 No ... what are we suddenly talking about? 21:40:16 coordinating the merging and release of two pull requests 21:40:21 Why? 21:40:52 to make sure we're not favoring one singularity implementation over another? 21:40:57 but yeah no need for a side tag 21:41:04 so the changes to conflict on sif-runtime happen at the same time. it's not part of the ticket discussion, and my apologizes for going down the rabbit hole. 21:41:45 Does this really mater? 21:42:41 so the package properly conflict with each other, yes. but we can move on for the meeting. 21:42:58 Is someone planning on doing a mass update as soon as these hit? I'm not really seeing a problem ... but ya ... moving on. 21:43:35 #topic Old Business 21:44:07 This last thing was supposed to happen at last weeks meeting. I just wanted more than one LGTM before I merged this ... 21:44:15 Tweaks to retirement policy documentation 21:44:17 https://pagure.io/epel/pull-request/213 21:44:20 ah sorry 21:44:28 Not a problem. 21:44:52 My finger keeps hovering over the merge button on it, but I never push it. 21:45:16 LGTM 21:45:23 push it 21:45:24 Thanks 21:45:34 doooo it anakin 21:46:04 And done ... 21:46:37 Good.. you have taken your first step 21:46:48 sorry wrong meeting 21:47:03 * tdawson starts breathing in his facemask. 21:47:15 I think that's all the old business ... 21:47:22 #topic General Issues / Open Floor 21:47:30 so i had one thing.. 21:47:38 Sure 21:47:57 i have been working on better counting of older epel systems before 8 21:48:07 so EPEL-7 (durh). 21:48:08 Ooohhh 21:48:52 the best method would be to add something to epel-release which mimic'd countme :). But because that might also be the worst method.. I have been coming up with something else 21:49:15 .hi 21:49:16 jonathanspw: jonathanspw 'Jonathan Wright' 21:49:30 Hi jonathanspw 21:49:52 Sorry I'm late :) 21:50:41 the current counting method just says 'if your ip has asked for an epel-7 repodata, we count you once per day'. That gives a number around 3.2 million per day. 21:51:16 Not a problem ... smooge was just telling us how the dark side can get us better epel 7 numbers. 21:51:17 However I went trawling through the data and realized that over 50% of all EPEL-7 requests per day come from around 30k ips out of the 3.2 million 21:51:42 company IPs? 21:52:00 Firewall of China? 21:52:02 doing some rough guessing math, it comes out that we are undercounting by 10 21:52:31 no the top 4 are google, microsoft, and amazon 21:52:40 So ... it should be 32 million? 21:52:44 yeah 21:52:48 wow 21:53:01 ah, likely cloud instances then 21:53:23 wait, how does the math work? (still jetlagged) 21:54:17 so a lot of systems have a cron script which updates mirror data every hour. That means that a lot of ips would show up around 24 times per day per 1 system 21:55:11 so I did a very simple ceiling(number_per_ip/24) and saw the number was around 10 times larger 21:55:37 if I were to assume that every hit was a differnt system.. then the count of 3.2 million would need to be increased by about 24 :) 21:55:44 sorry 240 21:55:53 ah 21:56:20 that's a lot of instances 21:56:42 because there are about 750 million requests to the proxies per day 21:56:47 what's the downside of trying to replicate how countme works? 21:56:49 for epel-7 21:57:27 countme is built into libdnf 21:57:37 ah 21:57:46 right, so I guess without deploying something to replace it client side, you can't do that 21:57:48 1) it would need to have epel-release add a cron job which once per week did a wget/curl request that said basically what countme does' 21:57:57 re-implementing it outside of libdnf as a cron job sounds like a bad idea 21:58:14 2. it would also be adding something outside of what may have been initially in any security review of allowing epel at said sites 21:58:20 way too easy to duplicate the cron job to manipulate the numbers 21:58:49 carlwgeorge, as if any distribution would do that 21:58:57 with the regular countme numbers 21:59:33 phew, and look at the time! 21:59:34 honestly I am not worried about manipulating the numbers as much as the 2nd. 21:59:50 Yep, that worries me more 22:00:06 anyway.. that was all. I am working on it and hope to have better numbers next quarter 22:00:08 right before the buzzer, i wanted to highlight one more simple thing here in the open floor 22:00:15 i retired a bunch of epel packages that were in rhel at newer versions, so straightforward retirements with no announcement 22:00:23 and two more that i did announce as it resulted in a few subpackages going away, but they were -doc and -test subpackages that nothing required 22:00:39 I saw that. 22:00:46 And thank you for doing that. 22:00:52 full list for those curious https://paste.centos.org/view/e6a1c631 22:00:56 yeap, cleanup is good 22:01:12 well, that includes tesseract-tessdata which i didn't do, the maintainer did after i pointed out the policy 22:02:12 I just have one extra comment that was discussing with salimma before the meeting. I picked up proxychains-ng because it was orphaned in fedora. if anybody wants to share it, please ping me 22:02:32 ah yeah that 22:02:51 right now pgreco and I are both admins, we're happy to add anyone 22:03:08 for both fedora and epel 22:03:24 looks like the previous admin retired everything / became inactive otherwise, since there's no new bug that'd trigger the orphaning 22:03:54 Oh, and I have one extra thing, though I think everyone already knows it. I hearby declare by my new dark side powers that we will have no meeting next week. 22:04:03 Nooooooooo 22:04:13 excellent 22:04:33 no work, no epel 22:04:34 Yessss ... give in to the holiday side ... 22:04:44 next week is full of nothing, looks good! 22:05:08 Anything else? Cuz we've gone a little over. 22:05:43 hope everyone has a good holiday break, see y'all next year 22:05:50 merry crimmus all! 22:05:57 Thank you all for a wonderful year full of EPEL. I'll talk to you next year. 22:06:06 May Krampus visit you all and all a good night 22:06:11 see ya next year 22:06:15 sorrry wrong one 22:06:16 happy Festivus 22:06:25 #endmeeting