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