21:00:15 <tdawson> #startmeeting EPEL (2022-02-09) 21:00:15 <zodbot> Meeting started Wed Feb 9 21:00:15 2022 UTC. 21:00:15 <zodbot> This meeting is logged and archived in a public location. 21:00:15 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 21:00:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:15 <zodbot> The meeting name has been set to 'epel_(2022-02-09)' 21:00:15 <tdawson> #meetingname epel 21:00:15 <zodbot> The meeting name has been set to 'epel' 21:00:15 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca 21:00:15 <tdawson> #topic aloha 21:00:15 <zodbot> Current chairs: carlwgeorge dcavalca nirik pgreco salimma tdawson 21:00:24 <salimma> .hi 21:00:27 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name> 21:00:27 <dherrera> .hi 21:00:28 * nirik waves 21:00:30 <zodbot> dherrera: dherrera 'None' <dherrera@redhat.com> 21:00:33 <nirik> morning 21:00:34 <pgreco> .hi 21:00:35 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar> 21:00:37 <tdawson> Hi salimma 21:00:43 <tdawson> Hi dherrera 21:00:49 <salimma> hi Diego Herrera - welcome 21:00:54 <tdawson> Hi nirik 21:00:57 <salimma> hi all 21:01:04 <tdawson> Hi pgreco 21:01:11 <pgreco> salimma: that sounds more efficient.... 21:01:21 <carlwgeorge> .hi 21:01:22 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com> 21:01:32 <tdawson> Hi carlwgeorge 21:01:58 <salimma> pgreco: haha, otherwise it's O(n^2) 21:02:38 <pgreco> yeah, nobody wants that.... 21:02:56 * salimma sadly has a conflict at 1:30 but will try to keep an eye on this while at that meeting 21:03:19 <tdawson> salimma: Anything you want us to bring up at the first? 21:04:02 <salimma> - the limited arch policy that Conan Kudo had a ticket for, which was queued up for last week's aborted meeting 21:04:15 <Eighth_Doctor> yes please 21:04:19 <tdawson> Good news is ... that's the first thing on the agenda :) 21:04:27 <salimma> and also, we have a branch request Davide is going to file for busybox, and it depends on libselinux-static which is built but not pushed 21:04:45 <salimma> (oh, we need uclibc too but there should not be a problem there) 21:05:01 * salimma wearing his Meta hat for the 'we' just now 21:05:08 <tdawson> #topic EPEL Issues 21:05:08 <tdawson> https://pagure.io/epel/issues 21:05:08 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open 21:05:15 <salimma> Davide's at the CentOS board meeting and sends his regrets 21:05:26 <tdawson> There is only one issue marked with meeting ... 21:05:37 <tdawson> .epel 152 21:05:38 <zodbot> tdawson: Issue #152: Revisiting policy for limited arch packages - epel - Pagure.io - https://pagure.io/epel/issue/152 21:06:16 <tdawson> I'm going to assume that everyone has already read this. 21:06:21 <salimma> TL;DR this policy seems very similar to the policies we've been discussing for -epel vs -extras for subpackages that are in Fedora but not Stream 21:06:22 * nirik hopes we can make these less confusing and anoying 21:06:47 <salimma> so it should probably be merged, but this has a weird 'you can't do this for EPEL 8' that doesn't really go into details as to the /why/ except 'it caused issues' 21:07:09 <salimma> my guess is it's because the source package was not renamed, but someone probably knows better 21:07:21 <nirik> few people followed the policy... and we had no idea how many packages like this there were/are... 21:08:12 <salimma> yeah, agreed 21:08:49 <salimma> related to that, Matthew Almond (who's working on RPM COW, if the name sounds familiar) thinks -extras is confusing (and clashes with some subpackages) so he thinks it should all just be -epel, which seems fair enough 21:08:51 <carlwgeorge> personally i think we'd be fine to leave this not allowed, and use excludearch/exclusivearch as needed in epel packages when their deps in rhel are not shipped on all arches 21:09:21 <salimma> I think the package Neal has in mind is LibRaw which is needed by ImageMagick? Conan Kudo should probably chime in 21:09:27 <carlwgeorge> seeing the per arch numbers, i don't think the extra effort and confusion is worth it 21:09:32 <salimma> what's the wider impact in this case? 21:09:38 <nirik> are rhel folks open to the idea of adding these back (like the missing devel ones), or thats a no way? 21:09:44 <Eighth_Doctor> well, there are desktops that require it 21:09:45 <salimma> if it blocks, say, Django or something big, that seems problematic 21:10:05 <Eighth_Doctor> e.g. I believe someone tried to build Xfce or MATE and LibRaw missing was a problem there too 21:10:21 <salimma> if it's only x86_64 and aarch64 I'd be OK with just exclusivearch the dependents, but aarch64 is also missing 21:10:26 <Eighth_Doctor> as it is now, not being able to build ImageMagick also means I can't get php-libvirt built 21:10:29 <salimma> and that's likely to be more popular over time 21:11:29 <salimma> so: if we just have a single policy covering limited arch / subpackages built but not pushed / subpackages turned off, that should be less confusing, not more, right? 21:11:35 <carlwgeorge> context from the centos dojo state of epel slides, aarch64 is 1.4% of epel usage 21:11:41 * salimma 's confusion tends to be deciding which is which 21:11:48 <nirik> The tricky part is not overriding the rhel packages... 21:12:16 <salimma> nirik: true. but that's already the case for the extra iptables / systemd packages 21:12:17 <nirik> and keeping them in sync with changes 21:12:17 <Eighth_Doctor> I don't know if someone has asked recently about LibRaw 21:12:24 <tdawson> For libRaw, is it just the missing -devel package (meaning libRaw is there, but the -devel package is missing)? If so, that is probrubly a legitimate bug. 21:12:24 <Eighth_Doctor> but there was an ask shortly after CS9 launched 21:12:31 <Eighth_Doctor> tdawson: it's the whole thing 21:12:40 <salimma> tdawson: no, libraw is built for all arches but published only for x86-64 21:12:48 <tdawson> OK, if it's completely missing, then it's usually deliberate. 21:13:11 <Eighth_Doctor> https://bugzilla.redhat.com/show_bug.cgi?id=2012272 21:13:17 <Eighth_Doctor> this is the BZ about it 21:13:33 <Eighth_Doctor> ah actually it looks like only the -devel is unshipped 21:13:38 <Eighth_Doctor> the main package is shipped 21:13:39 <salimma> yep, for c9s the reply is 'see c8s' and for c8s it's that 'aarch64 is only limited preview' 21:13:41 <tdawson> Packages like this would affect KDE Plasma Desktop, except we have a webengine_arches ... which nicely fits 21:13:46 <nirik> so, if we have a LibRaw-epel it would be used to build all our epel packages and likely override the rhel x86_64 version for users too (unless we played with release or weighting or something) 21:13:59 <salimma> Eighth_Doctor: ah, so we can use the existing policy to get that out then 21:14:02 <Eighth_Doctor> yeah 21:14:15 <Eighth_Doctor> so I can change it to just -devel subpackage shipped 21:14:20 <Eighth_Doctor> in the -epel subpackage 21:14:25 <Eighth_Doctor> err LibRaw-epel package 21:14:31 <salimma> so libraw-epel should just have excludearch: x86_64 and we're good, right? 21:14:32 <Eighth_Doctor> (words are hard today...) 21:14:40 <Eighth_Doctor> yeah 21:14:44 <nirik> well, no. 21:14:49 <salimma> in general, the same admonition applies anyway. 'don't override what's in c8s/c9s' 21:14:54 <tdawson> Here is an example of wheere this happened with llvm https://bugzilla.redhat.com/show_bug.cgi?id=2035398 21:15:01 <Eighth_Doctor> we need to drop the non-devel subpackages 21:15:03 <salimma> nirik: ah, what am I missing? 21:15:21 <salimma> Conan Kudo: yes, but that's what I mean. do a devel only, but also excludearch x86_64 21:15:27 <salimma> sorry if I wasn't clear 21:15:39 <Eighth_Doctor> yeah that we can do 21:15:46 <carlwgeorge> we could go fully explicit and have it be named libraw-limitedarch 21:15:47 <nirik> is all this pain really worth it? 21:16:04 <salimma> happy to punt the limited arch question until later, if we don't need it for the libraw case 21:16:15 <nirik> salimma: might work I guess... I am not sure if koji will do what you expect there... 21:16:25 <Eighth_Doctor> we already do this now 21:16:28 <Eighth_Doctor> for a ton of other packages 21:16:44 <salimma> yeah, only the excludearch part is untested but I don't see why it shouldn't work 21:17:00 <tdawson> Note: It does work 21:17:10 <Eighth_Doctor> but if we want to ask RHEL again to reconsider about LibRaw-devel, we could 21:17:15 <nirik> whats another package we do this for? 21:17:27 <tdawson> llvm-epel 21:17:37 <tdawson> Which ... I just remembered I need to retire. 21:18:17 <nirik> huh, not finding it. 21:19:21 <tdawson> Ohh ... that's right, they fixed the missing -devel before I made the package 21:19:34 <tdawson> But I was pretty sure I'd tried it. 21:19:42 <dherrera> there is python-pip-epel, does that apply? 21:19:46 <tdawson> At least building the package. 21:19:49 <nirik> I know the missing devel case, just wondering if we have a missing arch case in a recent rhel... 21:20:14 <nirik> but we never kept track of them and they are named the same, so blah. ;( 21:20:19 <salimma> we thought libraw was one, but turns out it's a 'missing -devel in some arches' case so we're probably OK :) 21:20:39 <salimma> yeah, I'm personally ok with just calling them all -epel 21:21:17 <pgreco> -epel makes it really clear on everybody... 21:21:51 <salimma> is there anything we can decide now? so we can move on :) 21:22:00 * nirik is fine with -epel for missing devel. Missing arch I think we need to do some testing, because excludearch may not let you build in koji for the excluded arch 21:22:32 <salimma> Conan Kudo: want to test this with libraw? 21:22:39 <Eighth_Doctor> sure 21:22:45 <salimma> not building on the excluded arch seems like what we want anyway 21:22:49 <Eighth_Doctor> I'll update it accordingly 21:22:56 <salimma> and if the package name is separate, it shouldn't break anything 21:23:05 <tdawson> So, if it IS possible, we would call these missing arch packages -epel ? 21:23:31 <salimma> yeah, I'm in favor of just -epel (including for what we now consider calling -extras, now that Matthew pointed out those can be confusing) 21:23:33 <nirik> salimma: you don't wnat to ship your epel packages on that arch? 21:23:59 <salimma> nirik: we want to make libraw-epel exclude x86_64, since libraw-devel x86_64 is in c9s 21:24:08 <salimma> so we only want to ship on the missing arches 21:24:50 <nirik> sure, but koji operates on source packages. not binary ones... and I am not sure how it will react here with the external repo. It may well say 'oh, I get that from epel, it's excluded, no package found' or it might work. I don't recall all the rules there. 21:25:31 <salimma> ah. but... Stream Koji != Fedora/EPEL Koji, so... what could break? 21:25:36 <tdawson> I have a question regarding making everything -epel. Let's say a package has a missing -devel, so we have foo-epel, but then someone also want's to add some sub-packages to that. Would we do both in the same foo-epel ? Currently we would do two foo-epel and foo-extras 21:25:37 <nirik> or perhaps more likely it will say 'checksum is wrong on this x86_64 devel package' because it's already imported it from cs9 21:25:41 <salimma> and this is a new source package (libraw-epel) 21:25:58 <salimma> that's why we want to stop libraw-epel from building at all on x86_64 - to avoid this confusion 21:26:18 <salimma> tdawson: yeah, I think merging it makes sense 21:26:41 <salimma> I'm also ok with foo-epel-extras, but.. if we can avoid people having to make that distinction it makes the policy less confusing 21:26:54 <tdawson> I do too, just wanted to clarify. 21:26:54 <nirik> well, we are already heading down the confusion path... but we can try it and see what breaks. 21:27:12 <tdawson> Having everything be -epel, would make the documentation easier for me. 21:27:26 <salimma> so we have -epel, with three different but overlapping usecases 21:27:39 <tdawson> Sounds like it. 21:27:47 <salimma> and we can state at the very top that the overriding principle is you don't clash with the Stream packages, non matter what you do 21:27:50 <nirik> sure. at least we can find em 21:28:47 <xavierb> just a note, LibRaw-devel is shipped for x86_64 and ppc64le too : https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/blob/main/comps-centos-stream-9.xml.in#L3186, What is missing is aarch64 and s390x 21:28:49 <salimma> does this mean we stop banning limited arch on epel 8? or we want to not touch that and make the combined policy epel 9 and above only 21:28:52 <tdawson> And while we are at it, documenting it I mean, we merge (or just remove) the Limited Arch Packages part of the policy ? 21:29:01 <salimma> xavierb: ah, thanks 21:29:27 <salimma> tdawson: merging and have one policy would make sense. I didn't even know the limited arch policy existed until this surfaced 21:29:31 <Eighth_Doctor> wait, if it's shipped for POWER, why the heck is it not shipped for the rest?! 21:29:38 <nirik> I'd like to fly a test package and confirm everything before we change any policy. 21:29:45 <salimma> someone has a business reason for ppc I bet 21:29:52 <tdawson> Eighth_Doctor: Because x86_64 and Power are considered "desktop" arches. 21:29:55 <salimma> yeah, I think Neal signed up for that 21:30:04 <Eighth_Doctor> yeah I have a package review already open 21:30:04 <salimma> wait... Power is but aarch is not. interesting 21:30:08 <salimma> how the world have changed :) 21:30:10 <Eighth_Doctor> I'm updating things accordingly 21:30:21 <Eighth_Doctor> Michel Alexandre Salim 🎩: there are probably customers using Talos workstations :) 21:30:29 * nirik orders a s390x laptop. 21:30:36 * salimma off to his next meeting but will lurk 21:30:38 <pgreco> I have an aarch64 desktop 21:30:44 * Eighth_Doctor wonders where nirik will put it 21:30:47 <pgreco> that's not a raspberry pi 21:30:53 <salimma> nirik: let me know if you find one :p. we've been trying to find a virtualized s390x and couldn't 21:30:57 <nirik> will need a aircraft carrier. ;) 21:30:59 <tdawson> Don't ask me ... I didn't make the policy ... but when I asked the same thing for epel8, that's what I was told ... and it looks like it's the same for RHEL9. 21:31:21 <salimma> nirik: I'm looking for an aircraft carrier too :) 21:31:49 <nirik> :) anyhow, should we move on? or was this the only thing on the slate? 21:32:03 <salimma> I think that's it, after that it's the normal epel7/8/9 roll call 21:32:20 <salimma> my other thing is for epel8 and epel9 21:32:41 <tdawson> I'll write up the documentation (which will be easier this time) and send a draft pull request on this issue 21:32:44 <tdawson> And ... moving on. 21:33:05 <tdawson> salimma: Since you need to go, why don't you bring up your item. 21:33:18 <tdawson> #topic EPEL-8 21:33:35 <tdawson> I know it's out of order, but at least salimma will be in the right topic. 21:33:42 <salimma> so yeah, I'll do this once for both epel8 and epel9 21:34:09 <salimma> we (meta) needs busybox and uclibc for $dayjob, Davide will file branch requests, but busybox needs libselinux-static which is not published 21:34:32 <salimma> so we'll probably put up a libselinux-epel and file a bug asking for it to be shipped 21:34:46 <salimma> any idea why it's not, by the way? just the typical 'we don't want to support it' or another reason 21:35:27 <Eighth_Doctor> statically linking libselinux can cause problems when they backport new selinux functionality 21:35:48 <Eighth_Doctor> while the public interfaces have been stable forever, the underlying implementation is certainly not 21:36:33 <Eighth_Doctor> static libraries generally turn into supportability messes 21:36:58 <tdawson> From what I can see, it is the "we don't want to support it", and ya, as Eighth_Doctor said, static libraries are harder to support. 21:37:48 <salimma> ok, so we should go ahead with doing an -epel then, since the chance of getting the -static shipped is lower (we should ask for that anyway) 21:37:55 <Eighth_Doctor> yeah 21:38:08 <Eighth_Doctor> though does your use-case require statically linked libselinux? 21:38:19 <tdawson> salimma: Ask for it anyways, but that might be one where they have a real reason they dont' want it. 21:39:06 <tdawson> Are we ready to move on? 21:39:20 <salimma> yes, thanks 21:39:26 <tdawson> #topic Old Business 21:40:02 <pgreco> I filed 2 PRs for the systemd macros 21:40:14 <Eighth_Doctor> I saw them 21:40:19 <Eighth_Doctor> I'm planning on looking at that later this week 21:40:32 <tdawson> Cool 21:40:35 <pgreco> great, hopefully I didn't forget about anything, thanks! 21:41:03 <tdawson> That's great progress. 21:41:43 <tdawson> pgreco: anything else ? 21:41:51 <pgreco> nope 21:42:11 <tdawson> Unless I missed stuff, that's all I have for Old Business 21:42:19 <tdawson> #topic EPEL-7 21:43:03 <tdawson> Did anyone see anything that needed to be done for epel7 ? 21:43:37 <tdawson> I know the nodejs jump has tripped a couple of people up 21:44:16 <pgreco> varnish 21:44:26 <tdawson> That's it ... varnish. 21:44:49 <nirik> sadly I fear incompatible upgrade is the best ption... 21:44:56 <nirik> option. if I could type 21:45:05 <pgreco> yeah, we've been down this road before 21:45:20 <tdawson> Yep, I agree. 21:45:36 <pgreco> I think tdawson's answer in the mailing list is appropriate 21:46:57 <tdawson> Should we tell them we would approve it? They didn't reply back. 21:47:11 <pgreco> I think so 21:47:20 <nirik> yeah, just have them follow the process. 21:47:38 <tdawson> OK 21:47:50 <tdawson> Anything else for EPEL7 ? 21:48:16 <tdawson> #topic EPEL-9 21:48:32 <tdawson> If you had something for EPEL8, feel free to jump in here too. 21:48:47 <carlwgeorge> new packages abound 21:49:17 <pgreco> I filed an issue for a missing dep (torsocks) and seems to have been built and pushed, so I'm happy 21:49:28 <tdawson> Cool :) 21:49:32 <tdawson> For both 21:50:03 <carlwgeorge> i just built syncthing for epel9 if anyone uses that, should hit testing tomorrow 21:50:24 <tdawson> #topic EPEL-Packaging-SIG 21:50:26 <rcallicotte> cool 21:50:38 <tdawson> anything for the packaging-sig, that we haven't covered yet? 21:51:01 <nirik> I wonder... 21:51:07 <salimma> ebranch is presented at dojo, and I have a COPR and PyPI for it 21:51:16 <tdawson> Hi rcallicotte ... didn't see you there. 21:51:26 <nirik> is anyone from the sig keeping track of bugs and new versions and such? or it's all just as it comes in people are doing things? 21:51:53 <salimma> I do check my dashboard, yeah 21:51:57 <salimma> I think Davide too 21:52:15 <rcallicotte> hey tdawson: been firefighting at $dayjob, I'm in lurker mode unfortunately 21:52:45 <tdawson> nirik I have a list of my requests, but I haven't checked to see the others in the packaging-sig 21:52:47 <nirik> cool. 21:52:57 <tdawson> rcallicotte: Well, good to see you, even in lurker mode. 21:53:50 <tdawson> Anything else for packaging-sig ? 21:54:22 <tdawson> #topic General Issues / Open Floor 21:55:02 <tdawson> Tomorrow carlwgeorge and I will be giving a presentation to the Fedora Council on EPEL. 21:55:41 <tdawson> It's only supposed to be 10-15 minutes, so we had to trim and prioritize the best of the last year. 21:56:14 <salimma> ooh, it's on fedocal right? 21:56:29 <tdawson> https://fedoraproject.org/wiki/Council/Video_Meetings 21:57:21 <tdawson> I don't know if it's on the fedora calendar, but I assume so. 21:57:52 <salimma> will try to make it 21:58:22 <nirik> cool 21:58:26 <tdawson> Anything else for General Issues ? 21:58:27 <nirik> break a leg. ;) 21:58:48 * tdawson hobbles in with a cast ... "Will do" 21:58:54 <rcallicotte> hehe 21:59:04 <tdawson> Looks like we can end on time today. 21:59:17 <pgreco> with a few seconds to spare... 21:59:21 <tdawson> Thank you all for everything you do for EPEL and the community. You all are great. 21:59:29 <tdawson> Talk to you next week, if not sooner. 21:59:39 <tdawson> #endmeeting