<@yselkowitz:fedora.im>
17:01:51
!startmeeting ELN SIG 24 Feb '26
<@meetbot:fedora.im>
17:01:52
Meeting started at 2026-02-24 17:01:51 UTC
<@meetbot:fedora.im>
17:01:52
The Meeting name is 'ELN SIG 24 Feb '26'
<@yselkowitz:fedora.im>
17:01:56
!meetingname eln
<@meetbot:fedora.im>
17:01:57
The Meeting Name is now eln
<@yselkowitz:fedora.im>
17:02:02
!topic Init process
<@sgallagh:fedora.im>
17:02:05
!hi
<@zodbot:fedora.im>
17:02:05
Stephen Gallagher (sgallagh) - he / him / his
<@jligon:matrix.org>
17:03:09
!hi
<@zodbot:fedora.im>
17:03:12
No Fedora Accounts users have the @jligon:matrix.org Matrix Account defined
<@elguero:fedora.im>
17:03:55
!hi
<@zodbot:fedora.im>
17:03:57
Michael Young (elguero)
<@jligon:matrix.org>
17:04:00
well then I need to do that!
<@yselkowitz:fedora.im>
17:04:31
hello Stephen Gallagher jligon Michael L. Young
<@yselkowitz:fedora.im>
17:04:58
let's get started, hopefully more people will come
<@yselkowitz:fedora.im>
17:05:16
!topic bootc images
<@yselkowitz:fedora.im>
17:05:19
!link https://github.com/fedora-eln/eln/issues/214
<@yselkowitz:fedora.im>
17:05:42
jligon anything to discuss here?
<@jligon:matrix.org>
17:06:16
I made a pr for the bootc team
<@jligon:matrix.org>
17:06:24
no one has reviewed it yet
<@yselkowitz:fedora.im>
17:06:30
link?
<@jligon:matrix.org>
17:06:50
not sure if its even right or what to do next, but I'm patient and tenacious
<@yselkowitz:fedora.im>
17:07:09
link?
<@jligon:matrix.org>
17:08:06
https://gitlab.com/fedora/bootc/base-images/-/merge_requests/377
<@jligon:matrix.org>
17:08:21
should have added it to the GitHub issue as well, sorry
<@jligon:matrix.org>
17:08:50
!hi
<@zodbot:fedora.im>
17:08:52
No Fedora Accounts users have the @jligon:matrix.org Matrix Account defined
<@jligon:matrix.org>
17:09:08
grrr
<@yselkowitz:fedora.im>
17:09:08
yes if you could please
<@salimma:fedora.im>
17:09:16
!hi
<@zodbot:fedora.im>
17:09:17
Michel Lind (salimma) - he / him / his
<@sgallagh:fedora.im>
17:09:28
jligon: It may take time to sync
<@salimma:fedora.im>
17:09:33
sorry, got sidetracked (I'm here until half past)
<@yselkowitz:fedora.im>
17:10:05
thanks jligon for the PR, I'll try to take a look at it later
<@jligon:matrix.org>
17:10:27
tyvm!
<@yselkowitz:fedora.im>
17:10:28
!link https://gitlab.com/fedora/bootc/base-images/-/merge_requests/377
<@yselkowitz:fedora.im>
17:10:40
!info draft PR posted, needs review
<@yselkowitz:fedora.im>
17:10:49
anything else on that?
<@jligon:matrix.org>
17:11:19
I don't think so, just waiting
<@yselkowitz:fedora.im>
17:11:49
ok we'll follow up in the PR and ticket, thanks for getting the ball rolling
<@yselkowitz:fedora.im>
17:12:06
Michel Lind UTC welcome, anything in particular you wanted to raise today?
<@jligon:matrix.org>
17:12:12
thanks for considering it!
<@salimma:fedora.im>
17:12:56
nothing much, just trying to keep up with what's going on
<@salimma:fedora.im>
17:13:18
I will have some PRs updating our workload soon but that's probably next week
<@yselkowitz:fedora.im>
17:13:28
sounds good
<@yselkowitz:fedora.im>
17:14:02
!topic ELN Hyperscale
<@yselkowitz:fedora.im>
17:14:08
!link https://github.com/fedora-eln/eln/issues/446
<@yselkowitz:fedora.im>
17:14:35
this was raised by Conan Kudo last week, and we've had some discussion in the ticket
<@salimma:fedora.im>
17:14:36
ah good timing :)
<@conan_kudo:matrix.org>
17:14:53
!hi
<@zodbot:fedora.im>
17:14:57
Neal Gompa (ngompa) - he / him / his
<@yselkowitz:fedora.im>
17:15:07
this seems doable, a few technical things we need to work out on our end
<@salimma:fedora.im>
17:16:00
yeah, if the modules are not shipped anyway as long as this does not block builds hopefully it's accepted?
<@yselkowitz:fedora.im>
17:16:50
so they've added btrfs_fs.ko (sp?) to kernel-modules-internal only for x86_64
<@yselkowitz:fedora.im>
17:17:02
if they were to do the same for aarch64, would that suffice?
<@conan_kudo:matrix.org>
17:17:05
btrfs.ko, but yes
<@conan_kudo:matrix.org>
17:17:16
for now, yes
<@salimma:fedora.im>
17:17:21
for hyperscale aarch64 is enough, yes
<@conan_kudo:matrix.org>
17:17:31
but I think we're also interested in riscv64 too
<@salimma:fedora.im>
17:17:32
kmod SIG might want more :P
<@yselkowitz:fedora.im>
17:17:34
hyperscale is just x86_64 and aarch64 right?
<@conan_kudo:matrix.org>
17:17:49
for EL11 we may add riscv64
<@yselkowitz:fedora.im>
17:17:54
riscv64 is a whole different discussion
<@conan_kudo:matrix.org>
17:18:06
yes, but the configs exist in ARK :)
<@yselkowitz:fedora.im>
17:18:16
wrt ELN I'm not sure we can do much about that right now, since they're not tracking rawhide
<@conan_kudo:matrix.org>
17:18:21
but at least for the moment, yes adding aarch64 works
<@conan_kudo:matrix.org>
17:18:57
the general ask for all arches is because Hyperscale also helps out with the kmods SIG btrfs support
<@conan_kudo:matrix.org>
17:19:02
and they ship to all EL arches
<@conan_kudo:matrix.org>
17:19:14
but as a first step x86_64 and aarch64 works
<@yselkowitz:fedora.im>
17:19:37
I have no say over ARK but that seems like a reasonable ask you could handle with an MR?
<@conan_kudo:matrix.org>
17:19:40
(Kmods SIG takes the code from CentOS/RHEL kernel, hence why it is of interest)
<@conan_kudo:matrix.org>
17:19:50
yup
<@conan_kudo:matrix.org>
17:20:14
I think Davide Cavalca was going to file a ticket about that this week
<@yselkowitz:fedora.im>
17:21:06
so this is another question I have here, there are other centos SIGs with sometimes overlapping packagesets, is there a way to avoid having dozens of ELN configurations to cover all of these?
<@conan_kudo:matrix.org>
17:21:10
he's much better at this sort of thing than I am :)
<@conan_kudo:matrix.org>
17:21:41
Yes. Alt Images, Hyperscale, Virt, and Kmods have overlapping package and image sets
<@salimma:fedora.im>
17:22:09
can we just have a script that combines all the packages listed in several sets?
<@conan_kudo:matrix.org>
17:22:16
generally speaking, we can rationalize them
<@salimma:fedora.im>
17:22:37
or once more than one workload adds something then we move it to a common set
<@conan_kudo:matrix.org>
17:22:40
from the ELN context, Hyperscale is generally a superset of what everyone else does
<@conan_kudo:matrix.org>
17:23:03
in terms of packaging and functionality
<@yselkowitz:fedora.im>
17:23:26
but not entirely, e.g. virt-power
<@conan_kudo:matrix.org>
17:23:31
yeah
<@conan_kudo:matrix.org>
17:24:39
the non-overlapping parts of Virt SIG probably require some finesse here, a lot of it is shadow of either the Xen folks (which is... complicated) or oVirt/OKD Virt folks, which should get a workload itself anyway to track that
<@conan_kudo:matrix.org>
17:25:17
if we manage to make the Hyperscale case work out, I'll probably start directly advocating for other SIGs to engage with ELN directly
<@conan_kudo:matrix.org>
17:25:22
and we can go from there
<@yselkowitz:fedora.im>
17:26:10
and they each have their own macros and build configs?
<@conan_kudo:matrix.org>
17:27:49
I think most of them don't actually
<@yselkowitz:fedora.im>
17:28:03
what I'm trying to get at is getting a picture of where this leads us and how many variants we end up with
<@conan_kudo:matrix.org>
17:28:04
aside from disttag stuff
<@conan_kudo:matrix.org>
17:28:12
and vendor macro
<@conan_kudo:matrix.org>
17:29:05
I think that in practice there won't be too many of them. Partly because a lot of CentOS SIGs are shadows of Red Hat product teams, which means they are operating as if they layer on base CentOS, and partly because not many people know how to _do_ stuff like what we do in Hyperscale.
<@davide:cavalca.name>
17:29:43
!hi
<@zodbot:fedora.im>
17:29:44
Davide Cavalca (dcavalca) - he / him / his
<@yselkowitz:fedora.im>
17:29:53
ok, like NFV which just has openvswitch/ovn which we can just add to Extras?
<@conan_kudo:matrix.org>
17:30:00
yeah
<@davide:cavalca.name>
17:30:07
Sorry I'm late, omw to an appointment
<@yselkowitz:fedora.im>
17:30:13
np welcome
<@conan_kudo:matrix.org>
17:30:26
the most sophisticated SIGs are Hyperscale and Kmods, and that's because both do kernel things
<@conan_kudo:matrix.org>
17:30:51
I guess there's also automotive, but I'm not sure they're really interested in anything of this sort
<@yselkowitz:fedora.im>
17:31:03
but if btrfs.ko is in kernel-modules-internal, then there doesn't need to be an ELN HS kernel build?
<@conan_kudo:matrix.org>
17:31:33
yeah no need for that
<@conan_kudo:matrix.org>
17:31:47
because my hyperscale kernel is just ark for rhel + a few configs
<@yselkowitz:fedora.im>
17:32:00
and what does kmods add?
<@conan_kudo:matrix.org>
17:32:23
they pull out sources from the rhel kernel and build disabled bits as modules
<@conan_kudo:matrix.org>
17:32:39
they also build the fedora kernel for rhel
<@conan_kudo:matrix.org>
17:32:42
as an alternative
<@yselkowitz:fedora.im>
17:33:18
fedora kernel as in the rawhide kernel with fedora config?
<@conan_kudo:matrix.org>
17:33:30
yes
<@conan_kudo:matrix.org>
17:33:49
it might make sense to track some of the userspace components they build for that as a workload, but I don't think building fedora kernels for rhel is particularly necessary
<@conan_kudo:matrix.org>
17:33:57
it might make sense to track some of the userspace components they build for that as a workload, but I don't think building fedora kernels for rhel is particularly necessary in ELN
<@conan_kudo:matrix.org>
17:34:02
since that's the same as rawhide
<@yselkowitz:fedora.im>
17:35:09
yeah, any case where it's just "we're building the latest thing which is newer than rhel" doesn't really apply to ELN
<@conan_kudo:matrix.org>
17:35:16
yup
<@yselkowitz:fedora.im>
17:35:24
just track it in a workload but nothing special wrt builds
<@conan_kudo:matrix.org>
17:35:46
yup
<@yselkowitz:fedora.im>
17:35:49
ok, this gives me a better idea of the whole picture
<@conan_kudo:matrix.org>
17:35:58
the userspace stuff isn't that much either: https://cbs.centos.org/koji/packages?tagID=3143
<@conan_kudo:matrix.org>
17:36:11
most of these are things we already track
<@conan_kudo:matrix.org>
17:36:17
the only one we don't is virtualbox-guest-additions
<@yselkowitz:fedora.im>
17:37:02
we'll need a bit of time to make this work on our end, but we'll need Hyperscale SIG (you guys) to work on upstreaming your conditionalized changes to rawhide
<@conan_kudo:matrix.org>
17:37:49
easy enough to do, I'm just waiting for the approval of the concept and that it's something we'll be able to do
<@yselkowitz:fedora.im>
17:40:18
I believe this is doable, makes sense, and fits within the mission of ELN, just need to work out the details
<@yselkowitz:fedora.im>
17:40:28
are there any objections or concerns?
<@yselkowitz:fedora.im>
17:40:52
we don't really have a formal approval process 🤷
<@conan_kudo:matrix.org>
17:41:14
I think the only bit is making sure the CKI people would accept such a change in the ARK rhel configs
<@conan_kudo:matrix.org>
17:41:40
other than that, if you already know how to pull this off and are able to enable it, I can get started on upstreaming conditionals
<@yselkowitz:fedora.im>
17:42:10
if it's going into -modules-internal, I don't see why they would object, particularly given that x86_64 is now in, I think the case for aarch64 at least makes sense
<@conan_kudo:matrix.org>
17:42:51
for the Hyperscale compose, that package will need to be shipped instead of filtered out
<@conan_kudo:matrix.org>
17:42:58
but otherwise yeah I think it's workable
<@yselkowitz:fedora.im>
17:43:23
the alternative is using `%centos_hs` conditionals like you will for the userspace changes and building kernel separately, they really can't reasonably object to that, but I'd prefer to avoid it if possible
<@yselkowitz:fedora.im>
17:43:33
yeah the compose side of that we'll have to figure out
<@yselkowitz:fedora.im>
17:44:07
but those are implementation details
<@yselkowitz:fedora.im>
17:44:29
and there is lots of those to figure out still, but it all seems doable
<@conan_kudo:matrix.org>
17:45:14
then I guess I'll start upstreaming our conditionals
<@yselkowitz:fedora.im>
17:45:35
sounds good, let's make a subtask ticket for tracking those
<@conan_kudo:matrix.org>
17:45:54
sure, mind creating that and assigning it to me?
<@yselkowitz:fedora.im>
17:46:06
sure np
<@yselkowitz:fedora.im>
17:46:31
it's getting late and a bunch of people here have fesco after this, so let's move on
<@yselkowitz:fedora.im>
17:46:40
!topic meeting goals
<@yselkowitz:fedora.im>
17:46:44
!link https://github.com/fedora-eln/eln/issues/440
<@yselkowitz:fedora.im>
17:47:26
in the interest of time, if anybody has any other big ideas or things they want to see here, please comment there or create a new ticket
<@yselkowitz:fedora.im>
17:48:14
some of the other ideas that came out of last week have tickets now, but we'll have to discuss them at another time
<@yselkowitz:fedora.im>
17:48:27
!topic Next meeting
<@yselkowitz:fedora.im>
17:49:06
I have a conflict next week, either I'll find someone to cover or cancel, will follow up in the channel
<@yselkowitz:fedora.im>
17:49:30
!topic Open floor
<@yselkowitz:fedora.im>
17:49:55
anything else to discuss today?
<@elguero:fedora.im>
17:50:42
Sounds good. Nothing on my part. Thank you!
<@jligon:matrix.org>
17:50:59
nothing here
<@conan_kudo:matrix.org>
17:52:31
I won't be here next week
<@conan_kudo:matrix.org>
17:52:36
I'm going to be at SCaLE
<@conan_kudo:matrix.org>
17:52:41
as will Davide Cavalca
<@yselkowitz:fedora.im>
17:53:23
that's three of us out, maybe we should just cancel next week then?
<@elguero:fedora.im>
17:54:18
Nice! Conan Kudo Davide Cavalca See you at SCaLE. I don't leave until Wed but that is fine if we want to skip.
<@conan_kudo:matrix.org>
17:55:08
I think technically neither does Davide but I thought his travel overlapped with something else
<@conan_kudo:matrix.org>
17:55:16
so it's just kind of bunched up
<@conan_kudo:matrix.org>
17:55:27
I'm traveling to Pasadena on Sunday
<@yselkowitz:fedora.im>
17:56:26
!info Skipping next week, next meeting will be Tuesday 10 March
<@yselkowitz:fedora.im>
17:56:52
thanks all, let's keep the discussions going in channel and in tickets, thanks for coming today
<@yselkowitz:fedora.im>
17:56:56
!endmeeting