Meeting started at 2024-09-04 16:32:54 UTC

The Meeting name is 'fedora_coreos_meeting'

!hi aaradhak

Aashish Radhakrishnan (aaradhak)

!hi

Timothée Ravier (siosm) - he / him / his

!hi gursewak

Gursewak Singh (gursewak)

!hi

Michael Armijo (marmijo)

!hi

Jean-Baptiste Trystram (jbtrystram) - he / him / his

!hi

Dusty Mabe (dustymabe) - he / him / his

!hi jasonbrooks

Jason Brooks (jasonbrooks) - he / him / his

!hi

None (jlebon)

i'll wait another minute and get started :)

I'll need to drop at some point to pick up kids from school

!hi ravanelli

Renata Ravanelli (ravanelli)

There were no actions items from the last meeting, so let's go into the topics

Jonathan Lebon: added the meeting label on this

ohh it was discussed last week but the label was not removed

I don't think there were new development, let's move on

well, same thing for the second scheduled topic, so we have no topics today !

we still need to talk about it

jbtrystram: in that case: reminder to add the `meeting` label to tickets you think warrant group discussion

jbtrystram: in that case: reminder to all to add the `meeting` label to tickets you think warrant group discussion

we also have https://github.com/coreos/fedora-coreos-tracker/issues/1708

(the meeting action does not picks up late-tag tickets)

any takers to implement adding the `lspci` owning package? https://github.com/coreos/fedora-coreos-tracker/issues/1778

(the meeting action does not pick up late-tag tickets)

dustymabe: yeah sorry i realized very late it was my turn to host the meeting so i did not really prep

The previous agreement was to add this package in FCOS but no-one actually did it

jbtrystram: :) - I was mostly just throwing that out there for Open Floor to see if anyone wanted to pick up implementing it (should be pretty easy)

I have a friend interested to get started to contribute on FCOS so i'm happy to mentor him through that if there is no takers

sounds like a good plan

cool, voluntered ! :D

yeah, would like to discuss https://github.com/coreos/fedora-coreos-tracker/issues/1708

who want to introduce it ?

there's a new feature in Ignition: using the CEX card on s390x when doing LUKS

CEX is basically cryptography hardware

it requires zkey, which is currently in s390utils-base

so the plan is to split that into a subpackage ?

i don't actually expect anyone interested in running FCOS with this, but for testing purposes, currently the written tests only work on RHCOS because of this

jbtrystram: that'd be the ideal, but the maintainer didn't answer the ping there, and in the past hasn't been very responsive unfortunately

worth trying a different medium perhaps. though also, this is s390x so i'm more ok if it e.g. pulls in Perl there personally

I was going to say that, but that does not help us down the line

ehh. I'd really prefer not - python is one thing, perl is another

are the countme stats reporting the architecture ?

jbtrystram: yes.

and yes. basically no one uses it, which could be argument for us just not building it

ppc64le & s390x are single digit

totally fine to keep trying to reach the maintainer. but if that fails/there's no agreement, i don't think we should block on it

I feel like this is an IBM problem TBH

(but it helps us catch issues early for downstream builds)

IBM wants CEX, IBM maintains that package

agree, we should pu pressure there

agree, we should put pressure there

of course we could just include perl in our s390x artifacts, but then s390x really starts to become it's own thing very much unlike the rest of our architectures (things are mostly uniform right now)

end of topic for me

same - going to go grab kids from school 👋

travier: do you want to take on the action on trying to contact the maintainer ?

I asked Madhu to do it in the ticket

nice

Any other topics to discuss ?

We should talk about again https://github.com/coreos/fedora-coreos-tracker/issues/1771

We should talk about https://github.com/coreos/fedora-coreos-tracker/issues/1771 again

this isn't correct AFAIK. the maintainer works at red hatter (so yes... IBM, but i don't think what you meant :) )

AFAIK, we don't have any update test for bootup so does not show up a test failure yet: https://github.com/coreos/fedora-coreos-tracker/issues/1788

I'm pushing fixes for bootupd updates in the selinux policy in https://github.com/coreos/bootupd/issues/694

and asking for freeze exceptions for F41: https://bugzilla.redhat.com/show_bug.cgi?id=2309742

but that won't help us here as it won't give us access to unlabeled files

so we need a fix / workaround for this one for F41 or we will have issues the next time we need to do a bootloader update

We're also pushing for always on bootloader updates in https://github.com/coreos/bootupd/pull/716

but that does not work yet with RAID setups in FCOS

So it's more of a status update as we have to be careful otherwise this might become an urgency the next time we need to update the bootloader

One option until we get this sorted out is to turn back the domain in permissive mode, not at the upstream level, but just for us

travier: we did this already in https://github.com/coreos/fedora-coreos-config/commit/40e9f23bb9322b97f6593cb3569b3d951aa7619f

travier: we did that option already in https://github.com/coreos/fedora-coreos-config/commit/40e9f23bb9322b97f6593cb3569b3d951aa7619f

great, I had missed that

ok, it's less of a concern then

but yeah, clearly we need to fix the labels. i think it's already on the radar but not sure yet who's picking it up

let's move on

dustymabe was looking at it

We agreed to have a chat about that with dusty tomorrow :)

do we have any other topics folks want to discuss ?

this isn't correct AFAIK. the maintainer is a red hatter (so yes... IBM, but i don't think what you meant :) )

ok for me

yeah. we wanted to get our pipelines back green without a ton of overrides or denylist entries.. will try to unfurl all the selinux denials over time with the maintainer

Should we communicate this change somewhere or wait so the story is more fleshed out ?

I have a small topic : we recently started publishing build tags for our bootable container images. Which allow people to properly consume them and revert back if needed. However zincati does not support that, so it exists but can't be supported in that state.

It's on my list to bring that discussion back to the table :)

Unfortunately, once we start advertising our container images, we will get users, and then that means that we'll double the amount of things to look at until we move things to containers

jbtrystram: this is part of the much larger discussion of "layering + updates"

so I'm more for a "one step at a time" approach

which, we had put on pause for a bit but we need to resume as part of the "roadmap to bootable containers"

jbtrystram: i vaguely recall you were interested in that part of the story? (zincati and layering) or am i misremembering?

I am ! That's why i want to bring that story out of the limbo it's been for a year

jbtrystram: maybe let's set up a meeting to chat :)

But okay, let's not brag about the container until this is more fleshed out

But okay, let's not brag about the containers tags until this is more fleshed out

Ideally, we start bragging about them once we are ready to transition everybody to them

composefs is one part, zincati support another, the tags were another bit as well

we kind of derived into open floor. Anything for open floor?

(we're almost at time)

(we're <del>almost</del> at time)

nothing on my side!

time for some food

thanks for attending everyone !

I'm closing here