Meeting started at 2025-10-23 17:01:38 UTC

The Meeting name is 'F43 Final Go/No-Go meeting'

!hi

Aoife Moloney (amoloney)

!hi

Paul Whalen (pwhalen)

!hi there

!hi

Sorry, but Fedora Accounts user 'there' does not exist

Adam Williamson (adamwill) - he / him / his

morning

!hi

Lukáš Růžička (lruzicka)

FYI, I have another meeting in an hour (with networking to work on our timeout issue).

well we better make this a quick go then today :p

!hi

Derek Enz (derekenz)

or a quick something

The purpose is to say Thank you Aoife and we will miss you

1. Release candidate compose is available

4. Fedora CoreOS and IoT are ready

3. Test matrices are fully completed

2. No remaining blocker bugs

yes!

that is the secret 5th way Stephen J Smoogen :)

So, without further ado - RC

I see we had 1.5 earlier, is this still the correct one?

we have two! exceeding requirements by 100%

possibly!

we have 1.5 and 1.6. the difference is that 1.6 has a fix (I hope) for https://bugzilla.redhat.com/show_bug.cgi?id=2405872 . but it came quite late

we are such overachievers.

(by which i mean '7 hours ago')

Well done everyone, hopefully its not in vain :D

Which one will we proceed with to verify for release readiness?

1.6

I guess

ack

well, i would say we can consider both, depending on the next bit of the meeting

Ack ack

hiiii!

so let's look at the proposed blockers

:passes reins while wagon is rolling:

i poked into this one somewhat in https://bugzilla.redhat.com/show_bug.cgi?id=2405239#c3

Although the newer one is the same as the old one with a verified fix, so why not stick to that?

at least as I understand the issue, i'm fairly sure it is not practically speaking a problem. mbedtls is only on the blocking images because librist requires it, librist is the only thing that uses it. librist, AFAICT, only uses AES. and the vulnerabilty is described as only affecting RSA.

Lukáš Růžička because it's not in either of the RCs so if we make this a blocker we have to slip.

oh wait

i misread you

Yeah, -1 blocker, +1 FE I guess.

Lukáš Růžička well, we'll get to that in a bit, i'll explain then

I meant the French fix. Sorry, my connection is laggy due to wind.

Lukáš Růžička you're using RFC 2549 and it's blowing your pigeons off course?

!hi

Jeremy Linton (jlinton)

Lukáš Růžička you're using RFC 1149 and it's blowing your pigeons off course?

Lukáš Růžička are you still +1 on this?

Kamil said that this is not an important security risk, so I guess I am not.

ok, so we're at -4. any other votes?

-1

proposed !agreed 2405239 - RejectedBlocker (Final) - this is rejected as our evaluation is that nothing in Workstation or KDE actually uses the vulnerable RSA code, thus there is no practical "security bugs of 'important' or higher impact" that cannot be resolved with an update

ack

ack

any more acks

you can have mine if it counts :)

ack

ack

all acks are ackcepted!

Peter Robinson are you around?

so this one got a bit complex, because there's a few moving parts. my best understanding is that the crash occurs pretty much always, but in most cases does not appear to have any practical consequences. (it looks to me like a crash during shutdown after g-i-s is done). pbrobinson suggested the crash might somehow be the reason his pinebook pro doesn't reach a desktop, but there's no obvious causative mechanism there, and he hasn't yet provided logs in the separate bug I created - https://bugzilla.redhat.com/show_bug.cgi?id=2405144

also i realize now my attempt to propose that as a blocker failed. sigh. doing it now

hey, I actually have a o6 now...

the crash itself doesn't appear to be hw dependent

i think i saw it in the vm installs i did for other reasons yesterday

but I don't *think* anyone has yet demonstrated a consequence of the crash beyond 'it shows up in logs if you go looking for it'

No body, no murder.

correct me if i'm wrong

yeah, I have not seen any here, but haven't looked. Things all appear to work.

you'll only find this in the journal or maybe if you run abrt and look at system (rather than user) crashes

and i think it only happens once, after g-i-s runs on first boot after intsall

again, if i'm wrong, yell :D

You're not wrong (as far as I know), but can we yell anyway?

sure!

i have a void here you can yell into if you like

😱

that's what the abyss is for

so, -1 Blocker here from me.

-1 FB

I noted in ticket that its still in 1.6RC

right, i just wanna confirm it shows up in an x86_64 VM install too (and also causes no obvious consequences0

right, i just wanna confirm it shows up in an x86_64 VM install too (and also causes no obvious consequences)

That said FB 0

i think we're at +2 / -8, then

I remain -1 for a Final Blocker and I'm honestly leaning towards -1 Freeze Exception as well (in the event we respin)

Frankly, the systematic failures are more concerning IMHO than the actual failure at this point. The inability for the default installed user to see the failure, and the length of time.

Frankly, the systematic failures are more concerning IMHO than the actual failure at this point. The inability for the default installed user to see the failure, and the length of time its been there.

yeah, would be nice to make that better, but it's not something we should block release on if it's not causing actual issues...

so yeah, i just literally watched this happen, it is the instance from g-i-s, it crashes after you've already reached the desktop of the created user, can't see that it has any practical consequence

it's just a teardown failure

Such behaviour can be easily fixed with a regular update, I think. No need to block on this if it does not harm anybody, or we do not have any logs, or we do not have any fix.

Maybe, without a clear diagnosis I wouldn't go that far it could be something nefarious for all we know at this point.

Maybe, without a clear diagnosis I wouldn't go that far it could be something nefarious, and systemd is just timing out an killing it, for all we know at this point.

proposed !agreed 2402621 - RejectedBlocker (Final) - this is rejected on the basis it does not violate any criteria and does not seem to have any significant practical consequences. pbrobinson's pinebook pro failure is currently tracked separately, will come up later in the meeting

Ack

ack

ack

ok, so this is the pbrobinson pinebook pro failure i split out of the previous bug to try and provide clarity

unfortunately he has not provided any info or logs yet

per https://forum.pine64.org/forumdisplay.php?fid=114 , pinebook is not exactly a hive of buzzing activity, and none of it refers to fedora on page 1

Punt (which is effectively a -1 for the purposes of this specific meeting?

Punt (which is effectively a -1 for the purposes of this specific meeting)?

We do need more info

there are some references to pinebook on discussion.fp.o. not a whole lot. mostly old.

https://discussion.fedoraproject.org/search?q=pinebook

i don't think we can legitimately punt at this meeting

Ok with a Punt

there does ultimately have to be a decision one way or the other before we make a go/no-go decision

punt is only valid when we have somewhere to punt *to* that happens before this meeting

Nevermind

since we made arm hw coverage a subjective thing in this cycle, and i am sick of this whole forest-of-SBCs mess, i am voting -1

!hi

Christopher Boni (boniboyblue)

nirik all we know for now is 'peter said he tried an install on a pinebook and it didn't get to a desktop'

I'm -1 as well.

yeah, -1 blocker here. :( Sad if that particualr hardware is broken, but...

Yeah agreed Adam

https://bugzilla.redhat.com/show_bug.cgi?id=2402621#c22 is literally all the info we're working with

adamw: Fine, based on what we know *right now*, I'm -1 to block on it.

!hi

No Fedora Accounts users have the @Lihis:matrix.org Matrix Account defined

!hi

Tomi Lähteenmäki (lihis)

proposed !agreed 2405144 - RejectedBlocker (Final) - this is rejected as a blocker on the basis that the report is lacking sufficient details to make an evaluation, and now ARM hardware coverage is handled as a subjective evaluation, our subjective evaluation is that we're not sufficiently worried about the Pinebook Pro to hold up the release while we wait for details to show up

how's that

Ack

ack

ack

ack

ack, though it seems like we could have stopped at "the report is lacking sufficient details" :)

well...i was thinking, if this bug was 'raspberry pi 4' we might be more inclined to want to block the release and wait...or test live...or whatever

the significance of the platform does play into it for me

right

so wanted to encapsulate that

I also want to bring up this bug, though it's technically an accepted blocker, in the 'proposals' block, because we accepted it very quickly in order to do rc-1.6

-1 FB

For the last one, +1 FB

the significance here is that if we accept this as a blocker, we can only ship 1.6 or slip

we cannot ship 1.5

I was +1 blocker to it, still am unless something new came up

yeah this seems sufficiently blocker-y to me

if we reject this as a blocker, we could ship 1.5

Lukáš Růžička: Could you be more specific? I can't tell what you were voting on each time

i am still +1, though. i just wanted to make sure nobody can criticize us for hasty blocker decisions

So, the this French one, I am seeing as +1 FB. The previous was -1 FB

Still +1

It is raining and windy :D

btw, if anyone didn't read the whole bug, this actually affects far more than french. it will affect more keyboard layouts than it *won't* affect.

I'll go FB +1 - might as well since we've already fixed in 1.6

I am calling it French, because it is reported against French. It was happening on German and Czech, too.

proposed !agreed 2405872 - AcceptedBlocker (Final) - provisional accepted blocker status is confirmed by wider vote

ack

ack

ack

adamw:For the record, what is the criterion in violation

ack

adamw:For the record, what is the criterion in violation?

Sorry, just found it in the BZ now

yeah, we have an explicit criterion for this

https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Keyboard_layout_configuration

FinalBlocker +1

ok, so let's also start the 'accepted blocker checkin' portion of the meeting with this one

the fix i did here is a bit dumb and depends on a couple of assumptions, but it *should* be good

i tested at least several random and popular layouts seem to work, and i also tested it seems to behave correctly on the encryption screen and i didn't break workstation afaik

There were also some other success reports in the bug.

it's definitely not what we want as a long-term fix but I *think* it should be good enough for f43 kde. it basically just does the same 'xkb specifier -> converted kbd filename' transformation we do in https://src.fedoraproject.org/rpms/kbd/blob/rawhide/f/kbd.spec#_140 when we're *creating* the converted xkb layouts for kbd

it won't work if you pick a non-ASCII capable layout with a variant, because we don't keep those converted layouts. but if you pick one of those you've got bigger problems, and we can't solve everything for f43, practically

No need to. We have already confirmed it today.

we have grander plans for f44 and later, but those changes turned out to be clearly not ready to go in f43 yet (we had a very optimistic plan to stuff them in over the weekend but it didn't work out)

checking in on this one as it's ON_QA, but I think the data from the bug (thanks Petr) indicates we've probably done as much as we practically can on this one

anyone have concerns?

image sizes are much more reasonable with the latest dracut AFAICT

ok

...and i think that concludes the blocker portion

exciting!

with the decisions made, all blockers are addressed in RC-1.6, but not in RC-1.5.

I have one possibly-contentious point to raise.

(New topic)

Can I info that @adam?

O

nope

before Stephen Gallagher blows this up

let's wait for stephen to blow it up first :D

unless it's not on the blocker topic?

I'd like to raise the fact that we have a KDE major release currently headed to stable the moment we declare "Go", which effectively would invalidate all the KDE testing. Are we collectively okay with this?

which update are you referring to?

6.5.0

specifically, what bodhi update?

One moment

https://bodhi.fedoraproject.org/updates/FEDORA-2025-ceb91cc9d5

~250 packages on a major feature upgrade

I know that KDE has a blanket approval for releasing mid-maintenance stream for Fedora, but having it as a 0day makes me a little hesitant.

Stephen Gallagher that update is in rc-1.5 and rc-1.6

see https://pagure.io/releng/issue/13013#comment-990354 and https://pagure.io/releng/issue/13013#comment-990502

Oh, I must have missed that.

it had an FE - https://bugzilla.redhat.com/show_bug.cgi?id=2403248

OK, that makes me a lot more comfortable.

Sorry for the noise.

Hurray!

we also put gnome 49.1 in

And no worries, better to have asked and be sure than let it go unsaid and it be something that was accidentally overlooked

with the blockers addressed, we will head to the next part of the festivities

coverage is surprisingly good for a candidate that came out like 8 hours ago

Can we confirm that sufficient test coverage is in place for RC-1.6?

thanks a lot to everyone who tested

the only significant thing we're missing is the workstation desktop tests on aarch64 - https://fedoraproject.org/wiki/Test_Results:Fedora_43_RC_1.6_Desktop#Release-blocking_desktops:_aarch64

I just filed a bug for a really annoying issue I encountered in ptyxis 49, not sure if it's "bad enough" though ...

we did have those done for RC-1.4, but that had gnome 49, not 49.1

so ideally we'd have them redone. but, since 49.0 was fine and 49.1 is fine on x86_64, it's *probably* okay...

Jeremy Linton did you get time to do a bit of smoke testing at least of workstation in rc-1.5 or rc-1.6 ?

i filled it out, maybe I didn't hit submit

link?

hehe

oh hah

TL;DR: haunted terminals ... https://bugzilla.redhat.com/show_bug.cgi?id=2406072

Thematically appropriate for Halloween!

easy fix: only have one terminal window

I wish

Weird, one of these days I will learn to use a computer I guess.

Mostly was a copy of the "tested with rc 1.4" but I did boot and fill out a few of the gnome ones for 1.6

Fabio Valentini: Silly question: are they invisible or maybe just resized to 0x0? Does the fullscreen keyboard shortcut reveal them?

good question. the Alt-Tab / Alt-^ switcher shows them, but with blank window previews.

Jeremy Linton if you can re-do the wiki changes it'd be great

https://fedoraproject.org/wiki/Test_Results:Fedora_43_RC_1.6_Desktop#Release-blocking_desktops:_aarch64

so they appear as *listed* but it doesn't look as if they can get focus, so no fullscreen keyboard shortcut

Now i'm confused because it shows that I filled it out there.

huh

Do you want me to set the topic to reflect that theres a few live, last-minute testing happening?

it's definitely not showing it here

sure

Ok, I filled out the wrong column, user error

ahhh

i did wonder about that, heh

I filled out all the x86 ones

so i should move all your x86_64 results to aarch64?

it looks like that :D

Jeremy Linton you said desktop notifications is failed with bug reference 1222418 - i think that's a typo?

in fact you referenced that bug in error_checks and printing, sorry

ah, it makes sense for printing but not error checks?

ok, i moved all your results across

think i got it right

so i'd say coverage looks pretty good now!

do we want to consider fabio's bug?

i think i'd go -1 on it if we were voting, honestly

basic terminal functionality is ok, the bug is annoying but can be fixed with an update

yeah that's fine, just wanted to mention it

I sent a screenshot in a thread, it looks hilarious though

Oh, I just moved them too.

Weird I didn't get any conflicts.

mediawiki doesn't do conflicts. it just goes ahead and writes whatever you sent

so i guess we can move on?

So are we happy with what we've got on RC-1.6, testing wise now?

I am happy :D

Yes, something is not quite right with the markup+results, but yes, the bug is on the wrong line, probably because of a slight markup error

no, you literally referenced the bug twice

in https://fedoraproject.org/w/index.php?title=Test_Results:Fedora_43_RC_1.6_Desktop&diff=prev&oldid=755214

Aoife Moloney i would say yes

As Tester-Extroardinaire, Im inclined to take Adam at his word and status this part and move on to part 4

Yes, but the rendering is not 'fail' either, i'm tweaking it.

IoT is ready

dustymabe: how goes Fedora CoreOS?

Is it ready?

Yep!

Some day I will change this script to ask 'Is it secret? Is it safe?'

(I have a very short, quick announcement to make at the end of the meeting if there is time)

❗️

Justin Wheeler: yeah we have an open floor for the last few mins once voting and status is done

FESCo?

go. 🏎️

Go

Releng?

also go

QA?

go

Go

🎆

🥳

🎉

and we're releasing RC-1.6, just to be clear.

Ack, will make sure thats in the release announcement email 🫡

Ok, go for it nirik , the damage is now done anyway

So my small note was that 1.6 has no UKI image... it failed compose... not a blocker, but just to note.

everything else is in the 1.6 compose?

I believe Justin Wheeler also had something to bring up?

Fabio Valentini: yep.

If the real business is done 🙂

does the no-UKI image note need to go to the release day coordination room? Is that something we need to note on a website/release note?

yes, and I will note it there. ;)

thank you muchly :)

go for it Justin Wheeler !

Link spam 🫣

Sorry for that.

That's all!

Yay F43! 🥳

Ack, thanks for sharing! :)

Are there any other topics folks want to bring up?

Not from me.

Maybe that link too, because we definitely don't have too many places in Fedora to have the same conversation 😛

Jef Spaleta: will be at the helm for F44 Beta and Final meetings, fyi, and I will see you all for F45

with nothing else, Ill close it out and thank you again everyne for your tireless efforts releasing F43!

ON TIME 🎉

all the best Aoife Moloney! 💓

The early is always just a bonus target ;-)

O captain, my captain! See you after a while Aoife 🙂

thanks all, cya in a few months!