16:00:48 <Ebeneezer_Smooge> #startmeeting ELN SIG 2022-03-25
16:00:48 <zodbot> Meeting started Fri Mar 25 16:00:48 2022 UTC.
16:00:48 <zodbot> This meeting is logged and archived in a public location.
16:00:48 <zodbot> The chair is Ebeneezer_Smooge. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:48 <zodbot> The meeting name has been set to 'eln_sig_2022-03-25'
16:00:54 <Ebeneezer_Smooge> #meetingname eln
16:00:54 <zodbot> The meeting name has been set to 'eln'
16:00:59 <Ebeneezer_Smooge> #topic Init Process
16:01:03 <Ebeneezer_Smooge> #chair sgallagh
16:01:03 <zodbot> Current chairs: Ebeneezer_Smooge sgallagh
16:01:09 <sgallagh> hmm?
16:01:18 <Ebeneezer_Smooge> you had a space at the beginning of startmeeting
16:01:24 <Ebeneezer_Smooge> so zodbot skipped it
16:01:50 <Ebeneezer_Smooge> you are chair now so can take over
16:01:56 <sgallagh> Ah
16:01:59 <sgallagh> Thanks
16:02:04 <sgallagh> .hi
16:02:05 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:02:09 <tdawson> Hi, I'm here, regardless of who is chair.
16:02:19 <Ebeneezer_Smooge> dcavalca, jforbes are here but before the meeting started
16:02:51 <jforbes> .hello2
16:02:52 <zodbot> jforbes: jforbes 'Justin Forbes' <jforbes@redhat.com>
16:03:04 <michel> .hello salimma
16:03:05 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
16:03:29 <sgallagh> Trying, but zodbot seems to be ignoring me still
16:03:30 <michel> Oh we need to startmeeting first
16:03:43 <sgallagh> It was done.
16:03:45 <michel> If hi and hello doesn't work I think zodbot is dead?
16:03:59 <Ebeneezer_Smooge> what did you try sgallagh ?
16:04:03 <dcavalca> .hi
16:04:04 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
16:04:07 <sgallagh> #chair Michel Alexandre Salim
16:04:07 <zodbot> Current chairs: Alexandre Ebeneezer_Smooge Michel Salim sgallagh
16:04:49 <sgallagh> OK, who rewrote zodbot to run on Internet Explorer 6?
16:04:58 <Ebeneezer_Smooge> #chair salimma
16:04:58 <zodbot> Current chairs: Alexandre Ebeneezer_Smooge Michel Salim salimma sgallagh
16:05:01 <michel> <insert random delay>
16:05:13 <michel> [insert random delay]
16:05:47 <Ebeneezer_Smooge> #unchair Alexandre
16:05:47 <zodbot> Current chairs: Ebeneezer_Smooge Michel Salim salimma sgallagh
16:05:49 <sgallagh> OK, let's just move along and hope that zodbot eventually revives.
16:05:53 <Ebeneezer_Smooge> #unchair Michel
16:05:53 <zodbot> Current chairs: Ebeneezer_Smooge Salim salimma sgallagh
16:05:57 <Ebeneezer_Smooge> #unchair Salim
16:05:57 <zodbot> Current chairs: Ebeneezer_Smooge salimma sgallagh
16:06:09 <Ebeneezer_Smooge> Oh are you on matrix?
16:06:19 <sgallagh> I saw jforbes  and dcavalca. Anyone else?
16:06:23 <sgallagh> #chair tdawson
16:06:23 <zodbot> Current chairs: Ebeneezer_Smooge salimma sgallagh tdawson
16:06:23 <Ebeneezer_Smooge> I am seeing zodbot say things here
16:06:53 <Ebeneezer_Smooge> zodbot> Current chairs: Ebeneezer_Smooge salimma sgallagh tdawson
16:06:59 <tdawson> Yep, me too, zotbot is alive and well here.
16:07:13 <sgallagh> .hi
16:07:16 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:07:30 <tdawson> That worked, just incase you didn't see it.
16:07:47 <sgallagh> I am on matrix
16:07:57 <Ebeneezer_Smooge> yeah.. I am expecting the bridge is blocking zod
16:08:21 <sgallagh> I see its messages when everyone else types things...
16:08:24 <sgallagh> .hello sgallagh
16:08:24 <michel> (I'm on Michel not salimma at the moment, AFK, but that's ok)
16:08:24 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:08:30 <sgallagh> And just then.
16:08:50 <sgallagh> #topic ELN-Extras
16:09:19 <sgallagh> Good news! We now have the ability to get packages built for ELN-Extras!
16:09:26 <tdawson> Ya!!
16:09:30 <dcavalca> yay
16:09:38 <sgallagh> In order to add packages to the list, you need to create a workload entry in the Content Resolver.
16:09:49 <sgallagh> #link https://tiny.distro.builders/view-workloads--view-eln-extras.html
16:10:09 <Ebeneezer_Smooge> so git clone and make a PR
16:10:14 <michel> Awesome!
16:10:38 <dcavalca> excellent, thanks for setting this up
16:10:55 <sgallagh> That will calculate the necessary dependencies and, once the change is merged, within 15 minutes the ELN rebuild tool will start watching for them.
16:10:56 <tdawson> Instructions for adding workloads is here - https://docs.fedoraproject.org/en-US/eln/extras/
16:11:08 <michel> sgallagh++
16:11:24 <dcavalca> sgallagh++
16:11:24 <zodbot> dcavalca: Karma for sgallagh changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:12:32 <sgallagh> There's still more work to be done, however.
16:13:13 <sgallagh> Right now, this will result in all ELN-Extras packages being composed into the Everything repository, but we really want to get it separated out into its own Variant in the ELN hierarchy, similar to BaseOS and AppStream.
16:13:49 <sgallagh> A necessary prerequisite for that is getting the BaseOS/AppStream/CRB definitions updated. Right now they're months out of date and not in sync with CentOS Stream 9.
16:13:57 <sgallagh> That's my task for this afternoon.
16:14:44 <sgallagh> After that, I think we want to write a tool to generate the appropriate split based on the hinting that Content Resolver provides for us.
16:14:57 <sgallagh> I'm not sure how difficult that's going to be, but I'm going to put my best people on the job.
16:15:16 <sgallagh> Or whoever's free/
16:15:52 <tdawson> :)
16:16:13 <michel> Those are the best people
16:16:16 <Ebeneezer_Smooge> Top people
16:16:21 * tdawson wonders if he gets the call if he would be considered "my best people" or "happens to be free"
16:16:56 <sgallagh> tdawson: A mystery for the ages!
16:17:02 <tdawson> :)
16:17:28 <sgallagh> I think that's all I have on this topic for now, unless folks have questions?
16:17:33 <sgallagh> Oh, actually
16:17:35 <sgallagh> One more thing
16:17:57 <sgallagh> We've talked in the past about how ELN-Extras is going to be the "feeder team" for EPEL N+1.
16:18:13 <sgallagh> I'd like for someone to put together a contribution guide that makes that relationship clear.
16:18:56 <sgallagh> Or at least extend https://docs.fedoraproject.org/en-US/eln/extras/ with that in mind.
16:19:01 <michel> I think I promised to do something a few weeks ago that I can't remember now
16:19:13 <michel> But yeah i can try
16:19:23 * michel adding a to-do so he doesn't forget
16:19:27 <tdawson> Couldn't that just be added to https://docs.fedoraproject.org/en-US/eln/extras/  ?
16:19:39 <tdawson> Or do you want it someplace else?
16:19:49 <michel> Might make sense to cross link to the epel guide too right
16:19:52 <sgallagh> tdawson: Read the backlog again :)
16:19:59 <sgallagh> Yes, I think that would be helpful.
16:20:26 <tdawson> Ha! ... sorry
16:20:30 <sgallagh> All good.
16:20:48 <sgallagh> <teasing>I guess that solves the mystery!</teasing>
16:20:54 <Ebeneezer_Smooge> something like Things in extras are meant for preview purposes only. They are not a promise that they will be in EPEL-N+1, but a guide to what is needed to make that possible.
16:21:27 <sgallagh> We previously stated that EPEL N+1 would fork from ELN-Extras at the appropriate time.
16:21:35 <jkonecny[m]> sorry for coming late, great work on the ELN extras!
16:21:38 <michel> Or, on the epel side, "if you want to make it easier to branch, add the leaf packages you care about to eln extras"
16:21:41 <sgallagh> So it IS actually a promise that it will be in EPEL N+1, unless it's retired beforehand.
16:22:36 <michel> Ideally we only add leaf packages directly, right? Right now it's hard to tell if something is in epel because it's a leaf or a dependency of something else
16:22:51 <sgallagh> Content Resolver actually answers that.
16:23:01 <michel> (plus packages that are dependencies of out-of-repo packages of course)
16:23:14 <sgallagh> You list only the packages you actually want and it shows you which ones you may need to also support or find someone to support.
16:23:38 <michel> Yup! So the guide should say "just add the leaf, CR will resolve everything"
16:23:43 <sgallagh> Yes
16:24:02 <sgallagh> Though maybe choose more explicit terminology than "leaf".
16:24:09 <michel> True
16:24:28 <sgallagh> Especially since it doesn't really work for, e.g. Django.
16:25:23 <sgallagh> #action Michel Alexandre Salim to update the ELN-Extras documentation
16:25:33 <sgallagh> michel++
16:25:33 <zodbot> sgallagh: Karma for salimma changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:25:38 <sgallagh> salimma++
16:25:47 <sgallagh> Wasn't sure which one would work there.
16:26:07 <sgallagh> OK, that's all I had on this. Now on to the not-at-all-controversial topic.
16:26:15 <sgallagh> #topic State of 32-bit x86
16:26:43 <michel> That's already not in stream and epel, right
16:26:43 <sgallagh> #link https://github.com/fedora-eln/eln/issues/80
16:27:53 <jkonecny[m]> how is the situation of 32bit packages on RHEL, now?
16:27:55 <tdawson> Not in epel, but yes in stream
16:27:59 <sgallagh> It's not COMPOSED in CentOS Stream 9 and EPEL 9, but we still build them
16:28:02 <tdawson> stream 9
16:28:04 <sgallagh> Oh, is it in Stream?
16:28:36 <tdawson> Just did a   dnf list "*i686*"   and there are quite a few
16:28:42 <michel> If it's in stream I suppose keep building them
16:28:55 <sgallagh> Right, in any case we still build for that arch, but we don't do an installable compose for that arch.
16:29:01 <tdawson> But do we want to remove them for RHEL 10 ?
16:29:07 <sgallagh> We only mean to ship the 32-bit multilib packages
16:29:31 <jforbes> it does seem that we could drop quite a bit
16:29:35 <sgallagh> The specific concern right now is with golang, which has abandoned the architecture and is causing problems.
16:30:02 <sgallagh> But I wanted to raise the question of whether we see value in keeping the architecture around at all
16:30:15 <jforbes> Fedora is looking to drop several i686 packages. so that helps some
16:30:43 <jforbes> I do see value in keeping it around for multilib though. If RHEL is going to support it at all, it will help work out toolchain issues along the way
16:30:53 <sgallagh> Yeah, true.
16:30:55 <michel> We can potentially go further than the rest of Fedora, right? Identify which 32 bit packages we actually want, use CR to find its dependencies, and Allowlist them so the rest automatically don't get built for i686
16:31:42 <michel> But if golang specifically drops i686, the Fedora specs will have to be patched to exclude arch it anyway and ELN will get the fix for free, right?
16:32:33 <sgallagh> "it's complicated"
16:32:53 <sgallagh> The `%golang_arches` macro is different on Fedora and Fedora ELN/RHEL
16:33:19 <sgallagh> So the specs won't need patching since they all just use `BuildArch: %golang_arches`
16:33:52 <michel> Ah yeah, like for Rust
16:34:12 <sgallagh> The particular bug in ELN's case is with `redhat-rpm-config` which fails on `Requires: golang-srpm-macros` on the i686 arch
16:34:37 <sgallagh> I think what I'm hearing in this meeting though is that we prefer to keep the i686 builds working, so we should patch around the macro issue.
16:35:01 <jkonecny[m]> how hard it would be to patch the macro? Any idea?
16:35:04 <Ebeneezer_Smooge> so what happens if we drop i686?
16:35:28 <michel> jkonecny[m]: Won't be hard, it will be similar to what I had to do for neovim.spec
16:35:43 <sgallagh> jkonecny: Not too bad, I don't think.
16:35:43 <michel> Ugly, but doable
16:35:49 <sgallagh> But it was worth identifying whether we cared at all.
16:36:12 <sgallagh> https://github.com/fedora-eln/eln/issues/80#issuecomment-1004965448 has some ideas
16:36:48 <jkonecny[m]> seems to me that we don't know for sure that the RHEL will or not have the multilib support, if that is true than I think ELN should keep that to be prepare until it's decided
16:37:01 <sgallagh> jkonecny: +1
16:37:05 <michel> %if 0%{?fedora} %bcond_without golang-srpm-macros %else %ifnarch %{ix86} ...
16:37:43 <sgallagh> Except it's a noarch package and those macros are resolved at build-time.
16:37:46 <sgallagh> So that won't work.
16:38:08 <sgallagh> We don't have to solve the technical questions here. We just need to decide if they're worth solving.
16:38:09 <michel> sgallagh: Ah
16:38:11 <sgallagh> It sounds like they are.
16:38:25 <michel> Downgrade it to recommends?
16:38:34 <sgallagh> I suggested that, it doesn't work :)
16:38:37 <michel> But yeah sorry for bikeshedding
16:38:54 <michel> Hard to multitask when afk and babysitting 😅
16:39:00 <sgallagh> No worries.
16:39:10 <Ebeneezer_Smooge> I am for killing i686
16:39:15 <sgallagh> Does anyone want to make a pitch for...
16:39:23 <sgallagh> Right on cue, Ebeneezer_Smooge
16:39:36 <jforbes> haha
16:39:54 <Ebeneezer_Smooge> I believe that has been my platform since 2014?
16:40:01 <michel> I prefer killing it too tbh
16:40:28 <sgallagh> Ebeneezer_Smooge: Oh, I absolutely want to make i686 walk the plank.
16:40:28 <michel> But people who know the rhel customers' needs more should probably decide that
16:40:35 <sgallagh> But the question is whether we should do so in ELN, now.
16:40:35 <Ebeneezer_Smooge> I expect that for the cases of wine and other tools that need it, they will do better with an artisinal container
16:40:41 * michel been running all his 32bit use cases in Flatpak anyway
16:40:45 <jkonecny[m]> I'm for keeping it until RHEL will decide and then decide
16:40:49 <tdawson> As much as I am for killing it, I think jkonecny[m] has a very good point that we need to see what RHEL has planned for RHEL 10.
16:40:52 <jforbes> It has been my platform since 2003, but I think it is going to invite a world of hurt if RHEL next plans to support multilib still and there are major toolchain issues
16:40:55 <jkonecny[m]> or better than reflect the decision
16:41:02 <sgallagh> I think jkonecny 's point is probably best.
16:41:03 <michel> Yeah, let rhel decide
16:41:38 <sgallagh> TBH, there's probably some bank out there somewhere with a mission-critical app build for i686 that they cannot replace.
16:41:50 <sgallagh> s/build/built/
16:41:56 <Ebeneezer_Smooge> yes there are.. they also run those on EL5 boxes
16:42:00 <jkonecny[m]> my personal preference would be also to kill it but I'm not convinced that it's the good solution for ELN
16:42:14 <sgallagh> OK, I'm calling this a consensus then.
16:42:21 <jforbes> sgallagh: Nah, those 32bit apps the banks are running on OS/2
16:42:31 <sgallagh> #agreed ELN will continue to build 32-bit x86 until and unless RHEL ceases.
16:42:50 <Ebeneezer_Smooge> I would like to say "We intend to remove 32 bit support on ELN, we will see how it breaks or doesn't break things and work from that point.'
16:42:52 <sgallagh> #topic Open Floor
16:43:11 <sgallagh> Ebeneezer_Smooge: I don't want to have to re-bootstrap it to turn it back on.
16:43:23 <Ebeneezer_Smooge> RHEL is probably not going to tell you it dropped 32 bit support until after the EL is out.
16:43:48 <sgallagh> Ebeneezer_Smooge: If it goes away in CentOS Stream, that will be a good indicator
16:43:59 <Ebeneezer_Smooge> but that will be after EL10
16:44:02 <sgallagh> If not, we'll carry it a bit longer in ELN. No big deal
16:44:27 <sgallagh> Any other topics? Suggestions, critiques?
16:44:39 <jforbes> things might get much easier as people start disabling i686 packages in fedora
16:44:47 <jforbes> nothing else from me
16:45:13 <Ebeneezer_Smooge> not from me.
16:45:17 <tdawson> Nothing from me
16:45:23 <michel> Nothing here
16:45:33 <jkonecny[m]> nothing here
16:46:15 <sgallagh> Alright
16:46:18 <sgallagh> Thank you everyone for coming.
16:46:29 <Ebeneezer_Smooge> remember no space before the #
16:46:29 <sgallagh> #endmeeting