Meeting started at 2026-07-21 16:01:33 UTC

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

The Meeting Name is now eln

!hi

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

!hi

Simon de Vlieger: Simon de Vlieger (supakeen) - he / him / his

!hi

Stephen Gallagher: Stephen Gallagher (sgallagh) - he / him / his

one sec, need to catch up

[Michel Lind ☘ UTC+1](https://matrix.to/#/@salimma:fedora.im) any news on retsnoop for ppc64le?

I need to prod the dev to get it fixed. is it a problem to just keep it excluded?

or does RHEL really care about ppc64 these days

ppc64 no, ppc64le yes, but this is a Meta package, so you tell me

!hi

just trying to avoid it fall through the cracks

jligon: Jeff Ligon (jligon)

sorry, I mean ppc64le

Meta only cares about x86_64 and aarch64 so truth be told it would be *really* hard to get anyone to fix ppc64le issues (or s390x)

!hi

Troy Dawson: Troy Dawson (tdawson)

I filed that issue because excludearches are supposed to be tracked

yes they are

so no real update iow

I'm sure upstream would appreciate a PR fixing the issue, but it'd be... kind of hard to do without an actual ppc64le box

nope

I don't expect to have any, realistically

there are supposed to be dev boxes available for ibm arches

Michel Lind ☘ UTC+1: Do you need a physical box or would a VM suffice?

VM would suffice

well, *I* don't need it, that's the problem. the upstream dev would need it and he's not a Fedora packager

the skill set requires to debug this is not... something I want to learn just for one package

if we can offer access to non-packagers I can see if the developer is interested

ok, caught up. if the issue was mostly in libbpf and that is fixed, then I can try reenabling

so you'll try again and ping the maintainer if not?

I'll probably put up a PR upstream to rebase to a newer libbpf that includes the fix, yes

if the latest version is not already fixed, since the last update is from quite a while ago

sounds good, thanks

It's me! I'll do a an update.

I configured (pretty badly) the first artifact in the pungi configs for ELN, which is the QCOW2. It built succesfully (after causing @yselkowitz:fedora.im some work, sorry for that). The version was wrong but is probably going to go right in tonight's compose.

it's fixed already

Perfect.

Anyhow; I'll continue over the next few days to enable more artifacts is the plan. The next batch will be the hyperscalers.

There's also some related topics, but I'd like to bring them up at the end of the meeting as they're not strictly about `image-builder` but more about 'how do we handle change requests' :)

as for the change in size, you said it was mostly firmware?

Yea it is, that's exactly what I wanted to bring up at the end :)

it's relevant here

Ack so right now we build ELN with all the hysterical raisins from RHEL-10. There are some things that people want to see changed both from the RHEL side, from the ELN side, and likely from the `image-builder` side as well.

"Hysterical raisins"?

Historical reasons.

Ah

lol

Basically bad past decisions that had to stay for compatibility.

Anyhow, the question that needs to be asked is how do we handle such a change. For example I agree that we should drop all this firmware in guest images.

But the virt-cloud team that owns these artifacts in RHEL might disagree (I doubt they will in this case).

The same goes that the virt-cloud team would like to see changes to the disk layout of cloud images in RHEL-11 (and thus ELN) that the ELN sig might not want.

For example, I have a request on my desk to change the default partition layout for all hyperscalers to be LVM-based for the on-premise builds.

ELN is the place for trying things which may change in the next RHEL, so generally we're going to want to do things that are wanted for the next RHEL, and drop things that aren't wanted in the next RHEL, but there are of course exceptions

As yselkowitz says, if they want to change the default partition layout, doing it in ELN *first* should be the expected process

why would we not want LVM-based partioning?

I don't know, I know for example CentOS turns it off for the Azure images; it's not /currently/ in ELN images even though the RHEL hyperscaler images offer both LVM *and* non-LVM.

@sgallagh:fedora.im Yes, my question is what is the expected process. Do these teams file an issue in the ELN bug tracker and I pick it up from there?

Or do they file issues with me directly and I let the ELN channel know, etc.

yeah we haven't kept up with all the image variants that have been added in RHEL 10

what's happening now with rhel image changes, they're going directly to you?

We do them directly for RHEL, but certain teams 'own' certain artifacts thus any request goes through them.

So the hyperscalers are all virt-cloud; the installers mostly go through us, `bootc` is anyone's party.

In RHEL-9 we also had edge, but not anymore.

What I want to ensure is that no one gets surprised, no one feels like they're not involved, and hopefully to share as much as possible between ELN -> CentOS -> RHEL with little divergence.

theoretically there should be an eln ticket for any changes, but if people are filing tickets with you and you're wondering if the change should also be applied to eln as well, then feel free to tag me on an existing issue and I can chime in, or bring it back to the group as needed

Anyhow this is a huge subject, how about for now any change I'm plotting/asked to make I file an issue in the ELN bug tracker and it can be discussed at meetings?

Ok yea that sounds good.

I have a meeting with virt-cloud on friday to get their exact requirements, so I'll file some tickets after that.

sounds good

anything else on this topic?

No.

great, thanks for all the work on this

[jligon](https://matrix.to/#/@jligon:matrix.org) do you want to make any updates?

Got my tenant merged right before this meeting

Pushed cverna to follow up with konflux team about a better spa for community

Sla

🛁

It's probably also OK to reach out to jcapitao for konflux-related bits. He's been doing a lot for CoreOS.

And will be running the compose and base images Mrs this afternoon after I get back from talking to my therapist

that bad, huh?

He is pto

Always

These are ELN base images for `bootc` right, is there a plan after all the machinery works to publish 'more'?

more such as...?

composefs native images, sealed images, derived images, that sort of stuff.

I want to do more bootc in centos-stream, but need to finish eln first

there are some other konflux-related priorities that we need to get done first before we're ready to consider more

+

Those would be great targets for me [Simon de Vlieger](https://matrix.to/#/@supakeen:fedora.im), but want to get consensus here first of course

Sean got unblocked yesterday on rpm stuff

could we get a ticket on what 'more' is possible, with the understanding it will probably be a while?

Unrelated but related

oh nice

It sounds good to have a ticket, for example the `image-builder` team has recently launched derived RHEL bootc images for all the clouds that should be able to fit onto CentOS/ELN directly as well.

Can you give me that action [yselkowitz](https://matrix.to/#/@yselkowitz:fedora.im)

So progressing

great, hope things keep moving

40+ packages from ELN were F45FTBFS, several have already been fixed

any conflicts next week?

I expect to be around

(how much longer before that will be just ET, who knows...?)

alright, seeing no further discussion, I'll go ahead and close. thank you all and see you in channel or back here next week