Meeting started at 2025-09-25 19:00:38 UTC

The Meeting name is 'ELN SIG 25 Sept '25'

!hi

The Meeting Name is now eln

!hi

Troy Dawson (tdawson)

Sorry, I got ahead of myself.

well it's :05 and just you and me

but I was out for a few days and apparently missed some things, so we could use this slot anyway

Yep

you had to revert your change?

Ya. It never completed a run.

It either failed with a traceback, or what looked like OOM

!hi

Neal Gompa (ngompa) - he / him / his

so what's the next step?

It would complete on my testing machine, but it had about 8x the memory.

Well, I'm still looking at the traceback, I must be missing some check in there somewhere.

But I'm more concerned about the memory.

I'm wondering about looking into building totally independent views (c10s) on a different machine.

But I'd like to keep the configuration (content-resolver-input) the same

My mind was thinking a command line option for the base_view ... but I'd be open to other things.

well there are some files which define the views in the first place

yeah I guess it would have to be some command line option to enable only certain labels and ignore the rest?

I think that would be the easiest.

If we did that, it would allow us to keep doing c10s for longer, even if c11s is around.

e.g. `--labels=eln,eln-extras` where `all` is the default if unspecified

Yep, something like that.

For right now though, I've been letting my Content Resolver brain relax a bit and work on images.

nice segue

toolbox images, status?

Very close. We don't have the right labels for them to upload to the toolbox (well, they would, but they asked if we really wanted the toolbox marked "AppStream")

"marked" how so?

I've got a pull request almost done that will fix it, and put it in a more appropriate directory.

Evidently, if we don't have a "subvarient", it get's it's name, and suvariant name from the kiwi variant.

we don't currently use `subvariant`, do we?

No, which is probrubly why it was conflicting with the Container_Base

So they both has Varient name, and subvarient name, as BaseOS / BaseOS

so your PR will just add `subvariant`s then?

No, it will move them both to the directory "Containers"

Similar to this

https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/compose/Container/

So their varient names will be "Container" and Base and Toolbox will have their own subvarient names.

based on the response to your ticket, that will also require adjusting the source of quay.io/fedora/eln?

Oh ... possibly ... I'll have to mention that in the ticket. Good catch.

and RHEL and CS don't have to do this because we're using kiwi and they're not?

Correct

But I didn't know what the subvarient label was for until now.

not really, they do too

subvariants are an important pungi thing

but RHEL doesn't _make_ that many different images that are potentially collisions

and I suppose *all* the images, AWS, Azure, etc.

that allows it to avoid some of the issues

the reason we set subvariants in Fedora is to avoid pungi clobbering them

well they do have base images and toolboxes

I just looked at the RHEL and CS pungi configes. Most of them have subvarients set.

yeah they are supposed to be there

not setting subvariants causes problems

but they still use BaseOS as the variant

in which case I think ELN should do the same, it sounds like subvariant is enough to avoid collisions

So, leave them in BaseOS, like RHEL/CS does. But make sure they both have a sub-varient?

that's what RHEL and CS seem to do

we should follow

IIRC doesn't the main variant being BaseOS mean AppStream and CRB are unavailable for images?

that obviously won't work for most images

no there's another flag to add repos

Correct.

`'repos': ['AppStream', 'CRB'],`

The main thing this does is put the images in the BaseOS images directory.

which is where they've been for as long as I remember in CS and RHEL

as I said, moving toolbox to AppStream wasn't necessarily the "right" way to handle this

Yep. Since we've had the BaseOS/Appstream split (RHEL8)

tbh it doesn't matter so do whatever

Yep, Although I have the file edited, I haven't commited anything, and it's a simple change to put them all under BaseOS, with subvariants.

So, in short, we're close for the toolbox image. Hopefully this is the last step.

Personally, I wouldn't put any of the images in there, and have it toplevel separate from the repo directories

but I am not sure Pungi supports that

that's not the RHEL convention though

moving along though because I want to discuss this too

altimages

So, just before this meeting I looked and saw that anaconda was built, with the -live in ELN update.

Until that happened, I was only half-heartedly working on that, because I had no way of locally testing.

But with that, I can now test my changes.

that leads us to https://github.com/rhinstaller/anaconda/pull/6646 from Conan Kudo

tbh we need another way to handle this

Ya, I saw that, but I figured I'd just put slitherer into the file list, and not worry about that for now.

anaconda needs changes to allow another way to set this

it was always kind of bad that the only way to set it is with profiles

Possibly use falkon ? 😄

lol

regardless, for anaconda-liveinst for EPEL, I will force the default to switch

it will hard-depend on slitherer too

But doesn't that bring slitherer (and qt6-qtwebengine) into the GNOME live image?

sure, but we already preload the Qt6 stack on GNOME for other reasons

Quite possibly.

this is not something I am concerned about

the bottom line is that we will short-to-medium term need to be able to build RHEL-like images with anaconda-webui w/o slitherer (or any other EPEL/Extras packages) *and* also CS AltImage-like images with anaconda-live and slitherer (at least for KDE Live)

Might be worth discussing in the workstation wg at least

!hi

Davide Cavalca (dcavalca) - he / him / his

/me just boarded a plane

slitherer was excluded from Fedora Workstation because it was easier to avoid in that case

well using slitherer for the CS GNOME Live images is a different discussion, tbh doesn't make much sense to me

since RHEL uses firefox it makes sense to have somewhere it is used in upstream fedora

using QtWebEngine in a GNOME image

(my posts landed out of order 🤷

well, since Red Hat doesn't make live images period, it's not really a point to worry about... as long as it's not used on netinstall and install dvds for RHEL, it's fine

and I was assured that even if slitherer is set in the profile, if it's not in the image, it will fallback to firefox

they don't make Live images but the plan is to use Web UI for the non-live installer images in RHEL 11, and hence ELN before that

possibly during the F44 cycle

I wonder if ladybug will be ready by then.

ladybug?

sure, and if it works the way the anaconda devs told me, just simply omitting slitherer will do what's expected

sorry, ladybird - https://github.com/LadybirdBrowser/ladybird

why would we use ladybird over qtwebengine?

I don't see us supporting that in RHEL??

the latter at least has a security maintenance team with Qt upstream

Just lighterweight ... maybe ... it's not ready for production ... so who knows if it will still be lightweight.

Anyway, back on the ticket. Now that anaconda-live is built for ELN, I should make some very good progress on that ticket.

let's put it this way: the RHEL non-Live installer image will presumably use firefox, the GNOME Live AltImage could use firefox or something based on webkitgtk, and the KDE Live image could use slitherer or falkon, what's the best way to handle those permutations?

I expect it to be done by next week, if not by the end of this week.

For KDE Live, the question is what browser will be installed when you do an install? Will it be firefox, falkon, both?

Personally, if we can do it, I'd like the KDE Live ELN to be an experiment to see how easy/hard it is to switch to a different browser for the install.

well if firefox is absent and slitherer is present, will the latter be used without the config setting?

and what happens if falkon is present?

So if it's just a parameter I can change during the config.sh script of kiwi, I'd really like trying a different browser for the install.

as it is right now? we need fedora-release-eln to be re-expanded to all the different variants that mainline fedora has

no, it will be broken

it only works the other way

how does CS AltImages handle this then? c-s-release doesn't have variants

well, we don't have a new enough anaconda yet

Yep, it's using the old CS10 anaconda.

but for centos alt images, anaconda-liveinst will be adjusted

that will flip the defaults accordingly

that's what I will do for EL11

Oh ... for 11 ... ok, I was wondering about that.

for ELN, we have this awkward problem that it's hard to represent community needs because despite being a Fedora project, it isn't operating like one

I don't know how we're going to reconcile how difficult it is to include our CentOS work in ELN

the mechanics may need to be a bit different given that we're not building anaconda-liveinst separate from anaconda, but there must be a way to make this work

given the time, we'll need to take this back to the ticket though

this would be easier if anaconda's config system was layered properly

the configs are in /etc and not in /usr

so I can't just ship an override config in /etc to set this

let's follow up in ticket, as we're almost out of time here

and because it's all dependent on os-release values, it means complicating fedora-release even more, which I really don't want to do

I won't be around next week due to a holiday, but what about the rest of you?

I'll be traveling again

I'll be gone the week after next

I'll be here

I'll be gone in two weeks as well.

I thought you said three weeks from now?

So, still have it next week? With me running the meeting? Or drop it next week?

Yes, I'll be gone three weeks from now also.

next week I'll be here I think

but the meeting is only useful to run if we think we'll make progress

if there's no progress to be had, we can skip it

well since the topic at hand most involves you two and you'll both be around, let's schedule it for Troy to run, and this will be the main topic?

and then cancel two weeks from now?

I'm good with that.

I should have some Live images by next weeks meeting.

Yeah that works

we're over time but anything else urgent?

Nothing from me