Meeting started at 2026-04-21 16:00:20 UTC

The Meeting name is 'ELN SIG 21 Apr '26'

The Meeting Name is now eln

!hi

Davide Cavalca: Davide Cavalca (dcavalca) - he / him / his

!hi

Michel Lind ☘ UTC+1: Michel Lind (salimma) - he / him / his

!hi

Conan Kudo 🥴: Neal Gompa (ngompa) - he / him / his

!hi

Neil Hanlon: Neil Hanlon (neil) - he / him / his

ok, let's get started

!hi

Troy Dawson: Troy Dawson (tdawson)

I was thinking to touch on bootc, hyperscale, fedora-release, and microarches

anyone have something in particular they want to cover today?

that sounds good, I do have a hyperscale/eln extras small update for the end

ok, I don't see jligon here yet, so we'll hold off on bootc

currently there are two different PRs to reorganize fedora-release to make it more RHEL-like for ELN, but with the presets being split out into their own package, I wonder if it doesn't make more sense to just have a completely separate fedora-eln-release package, and rip all the eln support out of fedora-release

I would rather we do that

that would simplify fedora-release by removing all the conditionals which are there only because of eln

that has the added advantage of a direct upstream for centos-stream-release

and it makes me hate fedora-release slightly less as a package

I agree ... and both of you keep saying what I was going to say ....

with the presets split out, how much ongoing maintenance work would that involve?

hopefully not too much

just bumping so ID data and adapting to new systemd requirements for os-release and dnf settings

just bumping version ID data and adapting to new systemd requirements for os-release and dnf settings

though maybe we should move the fedora dnf config snippet somewhere else since it would equally apply to fedora, generic, and eln release

what dnf config snippet?

https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/20-fedora-defaults.conf ?

yup

where would that go? redhat-systemd-presets seems odd only because of the name. fedora-repos perhaps?

probably fedora-repos, yes

interestingly though, centos-stream-repos is a subpackage of centos-stream-release

that may not make sense for eln to do, but in terms of this dnf snippet, it's not necessarily out of place in -release either

yes, I wanted it split, but there were... annoyances about it

so it's a subpackage as a compromise

Well, CentOS Stream doesn't have any variations ... so there is only one repo file needed.

ok, so sounds like we have a consensus to create fedora-eln-release and go from there

it was subpackaged so that internal deployments can replace it without breaking too many things

Though, I have to admit, for the risc-v stuff ... it means I have to keep updating my variation ... so I could see it making sense to have centos-stream-repo be it's own package.

https://gitlab.com/CentOS/archives/git.centos.org/rpms/centos-release/-/commit/26a0d73cedb9a2bfbcc38459344111fea231c577

I did the split, so I know why it's there :P

the actual discussion for that patch is gone though, alas

anything else on this?

not from me

this would be relevant to ELN as well, but I haven't heard much about it since the proposal. it sounds like there are still parts of the stack which need enhancement before this is feasible though.

anyone know more about this?

I'm pretty sure that proposal will not pass fwiw

rebuilding *everything* as both x86_64-v1 and x86-64-v3 seems very wasteful

Conan Kudo 🥴 you first brought this up wrt ELN, anything to add here?

the people driving this change have a significant desire to do the work for it

my only real desire is to get RHEL to use the proper architecture labels, I don't care about anything else

if this goes back to "dnf dynamically pick the best packages to install" but packagers can opt their packages in, instead of all being rebuilt I could vote in favor

there's no way to do that currently in Koji

otherwise probably that would make sense

Plague supported it, as does OBS, ABF, and others

but Koji does not

but yeah. I think it's too late for this current x86_64_v3 but the next time RH ever does a bump - maybe for other architectures - I'd like microarchitectures to be properly used

would konflux support it? *ducks*

there will never be another bump

but in order for that to happen, all the tooling needs to support it

x86_64-v4 is dead

the rpm stack supports it thanks to the openSUSE guys who did it for openSUSE

yeah, that's why I said other architectures

if we want to experiment I guess RISC V is the ideal candidate

it's very fast moving, so we get more chances of getting it right, and it's not a primary arch yet

move fast and... fix things?

well, on the flip side, it has basically zero capacity

it can't even keep up with rawhide

they _just_ started building 44

yeah which is why it should only be implemented on a package-per-package basis

technically sure, Konflux does because Konflux doesn't do anything... you ship tekton thingies in your git repo to do stuff

it's just not scalable, that's all

tbh if this change proposal doesn't happen in some form, then I'm not sure that it will happen at all

and tbh, x86_64 is pretty much the only arch where such experimentation can happen because we have a lot of capacity there

so whether or not all of fedora is built for baseline and v3, if some way to allow the change proposal to go forward even in limited capacity can be found, then we would benefit from it

something to keep in mind

and since Microsoft is supporting that change, they probably would be able to donate compute resources

that change is Fyra+Azure driven

I only acted as a shepherd, but they wanted it and discussed it at SCaLE

what's their motivation?

Fyra is launching a cloud and they want x86_64-v3 fedora/ultramarine

Azure wants to rebase Azure Linux more or less on Fedora and they need x86_64-v3 for performance

Makes sense

there was some nebulous plans of forking the whole distribution for this, they were guided in this direction

so I'd rather it not fail for that reason

there was some nebulous plans of forking the whole distribution for this, they were guided in this direction instead

well, in that case, I guess you'll want to find a way for it to succeed in some form, and that would pave the way for ELN and future RHEL to benefit

then ELN should probably say they want it then

given the alma v2 rebuild, I could see an argument for eln as well

yes

one of the end goals is that it gives us somewhere to upstream alma's variant arch work

which is alma's interest in this

almalinux already figured out what's needed but it's hard to upstream when it's not usable in fedora

yet I haven't heard so much as a peep from them?

they do their stuff quietly

they contributed fixes for mock just a few weeks ago

the rpm, libsolv, and dnf patches are not upstreamable because it reverses the order from what upstream rpm expects

in the interest of time, I'm going to cut this short, but let's keep an eye on this

Michel Lind ☘ UTC+1 ?

??

yeah. sorry, double booked every second half of this meeting as usual

you did say "for the end" :-D

I now have almost all the required tooling for exporting our internal package inventory, which was missing before, so while I can't work on the remaining pieces this week, we should be able to keep the Meta ELN extras workload up to date more easily in teh future

gah, problem with taking this while in a meeting room is the MBP keyboard is horrid

the keyboard cover I use makes it slightly more tolerable

you might want to consider one for yours

Michel Lind ☘ UTC+1 speaking of which: https://github.com/minimization/content-resolver-input/pull/1588

already did that from week 1 with this laptop :P

yeah that lgtm

I haven't implemented reverse update (incorporating changes from content resolver to the internal inventory) because that way lies dragons :P

any conflicts next week?

It's good for me

Nothing from me

ok, thank you all for your work and input, see you in channel or here next week