Meeting started at 2024-09-16 16:00:03 UTC

The Meeting name is 'F41-blocker-review'

!hi

František Zatloukal (frantisekz)

!hi

Derek Enz (derekenz)

!hi

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

!hi

Brandon Nielsen (nielsenb)

!hi

Jan Kuparinen (copperi)

!hi

David Duncan (davdunc) - he / him / his

!hi

Peter Boy (pboy)

!hi

Sumantro Mukherjee (sumantrom) - he / him / his

hi hi hi everyone, how's it going

Pretty good for a Monday

Brandon Nielsen: hah, yeah

alrighty

new improved meetbot boilerplate time (aka it's all coming at once again, so gird your loins)

Why are we here?

wohooo

who wants to secretarialize?

I happily would :)

!hi

Samyak Jain (jnsamyak) - he / him / his

alrighty

without further ado, let's get going with:

so we rejected this for beta as the criterion for firmware RAID is specifically for Final

sure does look like a +1 for Final, though

Yuppie, looks +1 to me

!hi

Neal Gompa (ngompa) - he / him / his

hi conan

yep yep, +1 for Final

+1 for Final

proposed !agreed 2311936 - AcceptedBlocker (Final) - this is accepted as a clear violation of Final criterion "The installer must be able to detect and install to firmware RAID storage devices"

Seems that we should be doing a build 🙂

yup!

ack

ack

ack

ack

ack

ack

so it's pretty clear now that this only affects the testing path (it doesn't affect real crashes)

but kparal proposes it on the basis that it restricts testing coverage (we can't test crash reporting on demand)

but kparal proposes it on the basis that it restricts testing coverage (we can't test crash reporting on demand unless we have a convenient 'real' crash to use)

So we're seeing real crashes being reported?

Brandon Nielsen: yeah

I think in this case it's pretty crucial that the test path works. We won't be able to fix it with an update.

and we've identified the bug and it is specific to something on the test path (it uses `exec()`)

I think that makes sense

and once all real crashes are fixed in anaconda, how do we check whether it works with the Final RC?

+1 FinalBlocker

We would be also happy to have this working

yeah, i'm fine with the rationale

+1 Spinal Blocker

it think it was appropriate that it didn't block beta because we *did* have a 'real' crash there so we knew reporting worked

+1 FinalBlocker

but we can't guarantee that for final

+1

no spinal blockers, please!

Also it could fail on any other path, it's just unpredictable

just for Final

jkonecny: the upstream references someone found seem pretty clear it's to do with using `exec`, don't they?

or did i read that wrong?

anyhoo

we have enough +1s

yep, +1

proposed !agreed 2311907 - AcceptedBlocker (Final) - this is accepted under "Bug hinders execution of required Final test plans or dramatically reduces test coverage" at https://fedoraproject.org/wiki/Fedora_41_Final_Release_Criteria#Final_Blocker_Bugs . this bug prevents us from reliably testing whether crash reporting works, which is an important and release-blocking function

ack

ack

ack

ack

ack

ack

I wasn't aware of newest update, so yes it looks like that

Anyway this is not the only place where it could fail

ack

so the justification here is a bit short: "Virtualization agent failure in default installation in a QEMU virtual machine"

is anyone up to date on this one and can unpack it a bit?

I noticed there's a failed service showing when booting F41 in a VM. Maybe it's related to the criterion that services must not fail in general?

ha, if it's that service

is that the one kamil? or some other service?

travier: are you around?

qemu-guest-agent.service

fails on boot in a default install

...in a VM, i guess. is the concern purely the failing service, or is the functionality the service provides important? i'm not sure what the generic qemu guest agent service actually does.

but, lemme check, but we afaik have a criterion than no service can fail, no?

https://fedoraproject.org/wiki/Fedora_40_Final_Release_Criteria#System_services

https://fedoraproject.org/wiki/Fedora_41_Final_Release_Criteria#System_services

"All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present."

not sure whether it fails on bare metal

Dangit, too slow

it imo doesn't matter if it fails on bare

yeah, this would be a conditional violation with the condition being "only in a qemu VM"

(assuming that's the case, of course)

if we want to take it on that basis i'd be fine with that

I think we can take it on that basis. :)

we block on QEMU+KVM, so I think we should

we also ship the guest agent on our blocking cloud image

👋

hi travier

yeah, it fails only in QEMU VMs

can you unpack the blocker justification for this a bit? is it simply the failed service breaking the 'no failed services' criterion? or is the functionality of the service important?

that's what I was thinking Conan Kudo

It's a default service used for various things in VMs: injecting keys, doing network manipulation, running commands

some cloud might rely on it

IIRC the service is required for proper quiescing for snapshots and such from QEMU too

some clouds might rely on it

ok, thanks

!hi

Fábio Ribeiro (farribeiro) - he / him / his

+1 blocker per cited criterion

+1

FinalBlocker +1

+1 Blocker

+1

+1

+1

+1

proposed !agreed 2258100 - AcceptedBlocker (Final) - this is accepted as a violation of Final criterion "All system services present after installation with one of the release-blocking package sets must start properly" on qemu VMs (including cloud instances). we note the affected service provides pretty important functionality for scripted deployment of VMs

Ack

ack

ack

ack

ack

ack

Am I understanding correctly, WPA2 enterprise doesn't work?

well, it sounds like it's a bit more narrow than that

How narrow? I'm only just learning I can get a TPM involved in my wifi authentication which is exciting.

i don't honestly know enough about enterprise wifi security to know

however, the proposer of this bug is called Williamson so it gets an automatic +1 from me

but srsly - i think i'd be inclined to punt and ask someone to explain it to me like I'm 5

Blood binds.

That should be a criteria, or at least a footnote

yeah... reading through it, I'd probably prefer punting...

we can afford to do that, plenty of time till final

If you'd cut my head off, I would not know. Punt.

proposed !agreed 2307226 - punt (delay decision) - we agreed to ask for clarification on the seriousness of this issue, as it doesn't seem apparent unless you're an enterprise networking expert

ack

ack

ack

ack

ack

ok, let's take a quick spin through:

thanks kamil

guess there's not much more to say on this one, we'll just wait for the fix

hum, i think we intended to consider this resolved by documenting it, didn't we?

i guess we need to do that

I can volunteer.

thanks

is it tagged commonbugs?

no. i've fixed that.

I am not sure, but we intended it.

oh, we did not?

it didn't have the tag, yeah

i guess we're just waiting on zdenek here

it's a bit early to start pinging him but i'll keep an eye on it

any other business, folks?

not on my side

nothing from me

alrighty, thanks for coming, everyone

see you next week, same bat time, same bat channel