Meeting started at 2026-08-24 15:59:59 UTC

The Meeting name is 'F45-blocker-review'

hi hi folks, who's around for f45 blocker review fun?

!hi

Ephraim Kaov: Ephraim Kaov (ephmo) - he / him / his

!hi

Jaroslav Groman: Jaroslav Groman (jgroman)

!hi

Derek Enz: Derek Enz (derekenz)

!hi

!hi

Jocelyn Gould (UTC-4): Jocelyn Gould (korora) - she / her / hers

!hi

Petr Sklenar: Petr Sklenar (psklenar)

hi hi everyone

!hi

thanks for coming out

it's boilerplate time!

Why are we here?

who wants to secretarialize?

I will

thanks

ok, let's get started with:

...that went well

oh dear, I forgot to process before the meeting. oh well, that should make this fast

that's a pretty comprehensive vote, anyone want to argue for -1?

ok

proposed !agreed 2519654 - AcceptedBlocker (Beta) - this is accepted as a clear violation of all "complete an installation" criteria, e.g. "The installer must be able to complete an installation to a single disk using automatic partitioning. "

proposed !agreed 2519654 - AcceptedBlocker (Beta) - this is accepted as a clear violation of all "complete an installation" criteria, e.g. "The installer must be able to complete an installation to a single disk using automatic partitioning."

proposed !agreed 2519654 - AcceptedBlocker (Beta) - this is accepted as a clear violation of all "complete an installation" criteria for the release-blocking IoT installer, e.g. "The installer must be able to complete an installation to a single disk using automatic partitioning."

ack

ack

ack

Ack

i'm also -1 on this, it's a clear bug and I've reproduced it, but it doesn't block beta by criteria, and that feels correct

for Final we have https://fedoraproject.org/wiki/Fedora_45_Final_Release_Criteria#User_switching and it's a judgment call whether it violates that

I would like to know also, what the intention is. Because somehow it could make sense on some occassions

i don't think the current behavior makes any sense

the *inhibition* potentially makes sense

but the user trying to shut down should be correctly informed of why they can't, which is not the case. instead they're told they can shut down, but it just doesn't work

well, if someone has an unsaved document, maybe that's a good reason not to restart?

I agree that this could be presented better

Yes, but should be some feedback for user

anyone want to argue +1 for beta?

i kinda feel like not deciding for final now, as it's an awkward subjective call and hopefully it'll be fixed before we have to worry about it

I think that should be a Final release blocker

I agree... non-blocking for Beta... blocking for Final release

Punt or -1 BB

-1 BB. +1 Final

proposed !agreed 2501857 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this is rejected for Beta as it does not violate the Beta criteria, the user switching criterion is for Final. It's accepted for Final as a conditional violation of "User switching must work using the mechanisms offered (if any) by all release-blocking desktops in their default configuration" - we consider not correctly informing user A of an inhibitor relating to user B as a sufficient violation of the "must work" requirement

proposed !agreed 2501857 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this is rejected for Beta as it does not violate the Beta criteria, the user switching criterion is for Final. It's accepted for Final as a conditional violation of "User switching must work using the mechanisms offered (if any) by all release-blocking desktops in their default configuration" - we consider not correctly informing user A of an inhibitor relating to user B to be a sufficient violation of the "must work" requirement

(there are three +1s for final, soo...)

ack

ack

Ack

ack

this is another straightforward one, anyone see anything we missed?

i'm +1

+1 from me too

no, we do not want to have a broken conosle

+1

I did note that this doesn’t seem to affect the Server KVM install, but I’m still +1 to it being a blocker

proposed !agreed 2484542 - AcceptedBlocker (Beta) - this is accepted as a violation of "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system" for the ARM minimal disk image (which is release-blocking and relies on console initial-setup to provide said mechanism)

ack

Ack

Jocelyn Gould (UTC-4) interactive installs are less obviously affected as you can create user/root password during install. it's primarily an issue for disk image deployments

Jocelyn Gould (UTC-4) anaconda-driven installs are less obviously affected as you can create user/root password during install. it's primarily an issue for disk image deployments

Jocelyn Gould (UTC-4) anaconda-driven installs are less obviously affected as you can create user/root password during anaconda (either interactively or via kickstart). it's primarily an issue for disk image deployments

ack

I was referring to the qcow2 images, which use console initial-setup

huh. that's odd, then

sorry to barge in, but is this the complete blocker list or is there another resource?

https://forge.fedoraproject.org/quality/blocker-review/issues

🇵🇱 | Nik Nikovsky [unreachable on 26/8/26] https://qa.fedoraproject.org/blockerbugs is the canonical list

I see, thanks

so the issue here is basically that the update notification does appear *initially*, but if you reboot without installing them, you aren't notified again

is that right Derek Enz ?

Correct

Conan Kudo 😌 does that sound intended?

that doesn't _sound_ intentional

I don't think this should be a blocker

but it also doesn't sound unintentional

Isn't there a timer that would hold showing the notification for some time?

like... I don't know if we'd _want_ to do nagging popups

but it's also not a very high priority notification (unless you're running fedora in a secure env)

but it's also not a very high priority notification (unless you're running fedora in a secure env and have no idea how dnf works)

mmm I kind of agree... if you ignore notifications for updates and you don't bother to check updates or use dnf-automatic or something... that's on you.

I think I read documentation saying it should show as along as Discover has updates waiting

never heard of that, I'll check it out.

If I remember right, Workstation tells you again after a reboot if you opted not to install the updates. And then it doesn’t tell you again.

Maybe I read misread KDE docs

Maybe I misread KDE docs

I am ready to cast my vote right now, do I do it here or on the forge ticket?

I could be wrong, But I want to say that is how I remember it on my workstation installs… (which I should probably update one because I rarely log into it, it just kinda… sits there quietly)

i don't know the behavior in a ton of detail, the openqa tests only really test a very basic 'first time after clean install' scenario

Even in F44 rightnow KDE has a little notifier saying I have updates

If you miss the update notification you can find it in notification history, but I'm not sure if persist after reboot

depends if the history is cleaned (maybe, guessing)

i guess for this one i'd be interested in whether the notification shows up again if *more* updates appear...and maybe scenarios like 'initial update set has no security updates, new set has one'...

I think before we determine this to be a blocker, we should determine what the expected ehaviour is

(iirc kde has different notifications for 'regular' and 'critical' updates)

also, is it a good idea to add the forge ticket link alongside the bugzilla bug ID on blockerbugs?

but on the whole if we had to decide now i'd be a slight -1

might be a good punt for details though

every entry has both

I’m voting punt.

the forgejo link is the one in the farthest right-hand column

mb

yes

I am voting -1 on this ticket

-1, it does not seem that important for the general public

punt sounds good. I think you should get notified again if there are new updates.

should we vote on the actual ticket page as well?

no, if the vote happens here, no need to vote in the ticket

I see

proposed !agreed 2502678 - punt (delay decision) - we have some questions for upstream about whether this behavior is intended and, if so, exactly what would trigger the display of a new notification, before we decide whether this constitutes a blocker

ack

ack

ack

ack

ack

Aclk

Ack

niknikovsky gave a cookie to korora. They now have 14 cookies, 4 of which were obtained in the Fedora 44 release cycle

ack

ACK

ok, let's go on to:

Beta freeze is coming up soonish, so probably good to process these

4 to go

"non-blocking image doesn't build" is a classic FE, so i'd be +1 on the description

my question is: "can this be reproduced from a clean env?"

if yes, then =1

if yes, then +1

sure, it's affecting the official image build, per comments

+1 from me

+1 then ig

+1

+1

+1

+1

proposed !agreed 2517903 - AcceptedFreezeException (Beta) - this is accepted as it completely prevents the compose of a non-blocking image, which obviously can't be acceptably resolved with a post-release update

ack

ack

ack

ack

ack

Ack

ACK

acl

niknikovsky gave a cookie to lruzicka. They now have 49 cookies, 3 of which were obtained in the Fedora 44 release cycle

i approve of the "cookies for misspellings" policy

do you mind if we start writing HTTP 200 instead of ack as well? /j

if you do that you get a cookie

korora gave a cookie to niknikovsky. They now have 13 cookies, 7 of which were obtained in the Fedora 44 release cycle

welp, this has +4 already, anyone want to be -1?

I think this is a justified blocker (he says without any prior coding knowledge)

+1 if we have to vote

the remaining FEs are in a similiar situation

it's not a blocker unless it affects a blocking image, which would be IoT but that's affected by the other thing

Then punt and see if it affects a blocking image.

the remaining FEs are in a similiar situation (as in have overwhelming + votes)

well, we can accept it as an FE

we're in FEs here, not blockers

oh, yeah. +1 FE

propose the agree then

+1 FE

+1 FE

proposed !agreed 2521241 - AcceptedFreezeException (Beta) - this is accepted as it's obviously a major installer issue that can't be remedied with an update. For now we only know for sure it affects non-blocking images, we will consider it as a blocker if it turns out to affect IoT

HTTP 200

ack

adamwill gave a cookie to niknikovsky. They now have 14 cookies, 8 of which were obtained in the Fedora 44 release cycle

Ack

ACK

this also has enough votes and is one we have every cycle

I'd say same verdict as last ticket

+1 FE

+1 FE

+1 FE

proposed !agreed 2492124 - AcceptedFreezeException (Beta) - this is a recurring FE, we always approve this in order to get the best/latest obsoletions we can before release

HTTP 200

Ack

ack

ack

ACK

ack

same as previous ticket

+1 FE?

+1 FE

hmm

the nit I have with this is that the freeze date is also the 100% complete deadline for Changes

i.e. Changes are supposed to be done *before* the freeze

oh, ok, this was covered in the Change and FESCo approved it, so i guess it's ok

> Aug 25: Fedora f45 Beta Freeze

> Aug 25: Begin building LLVM 23.1.0 in Rawhide and 45 side-tags.

> Oct 06: Fedora f45 Final Freeze

+1 then

+1

proposed !agreed 2506941 - AcceptedFreezeException (Beta) - this was effectively requested by FESCo since the Change specifically states "Our plan is to push 23.1.0 into Fedora 45 during the Beta Freeze with a Beta Freeze exception" and FESCo approved it, so we respect that

ack

HTTP 200

+1

Ack

ack

niknikovsky gave a cookie to ngompa. They now have 216 cookies, 12 of which were obtained in the Fedora 44 release cycle

ACK

let's take a quick look at:

there's been a lot of work on this one, it seems pretty complicated, but the various teams are still banging away at it

i'll remind them of the schedule

unless I missed a part of the meeting (which I probably have) we still have the proposed beta blockers to discuss?

we did them first

ah

so only the already accepted blockers remain?

yeah, this is the last bit

Conan Kudo 😌 are we anywhere with this?

need to ask nicofee again

seems like an upstream thing, doesn't it?

or Jan Grulich

it is

so I guess we are stuck waiting for qt to respond

there's also a new Qt landing today/tomorrow-ish

I would support +1FE for this one. I need to go away for an hour or so, I'll do the secretary afterwards.

this is the last thing and it's accepted as si

this is the last thing and it's accepted as is

so idk if voting on this makes sense (not my decision tho)

there's nothing to vote on

yeah

yeah, the point with these is to check progress and try to move things along if they appear to be stuck

I propose an info that we are waiting on a response from qt

and that conan will ask someone from there

as a reminder

works for me

I think the only thing left is https://bugzilla.redhat.com/show_bug.cgi?id=2448283

that's an accepted Final blocker, we don't usually go over those in the Beta blocker meeting

I see, in that case there is nothing left I think

(that one might actually need a re-check, stuff has changed a lot there)

any other business, folks?

(vaguely blocker/FE/f45 beta-release-related business, that is, not *anything at all*)

why is there a hole in the floor /j

nothing from me

All good here Adam

Nothing here.

nothing from me

I think we are safe to end this meeting

thanks, yes