2026-04-06 16:00:48 <@adamwill:fedora.im> !startmeeting F44-blocker-review
2026-04-06 16:00:49 <@meetbot:fedora.im> Meeting started at 2026-04-06 16:00:48 UTC
2026-04-06 16:00:49 <@meetbot:fedora.im> The Meeting name is 'F44-blocker-review'
2026-04-06 16:00:51 <@adamwill:fedora.im> !topic Roll Call
2026-04-06 16:01:33 <@nielsenb:fedora.im> !hi
2026-04-06 16:01:34 <@zodbot:fedora.im> Brandon Nielsen (nielsenb)
2026-04-06 16:02:10 <@adamwill:fedora.im> hi brandon
2026-04-06 16:02:17 <@adamwill:fedora.im> it's a holiday today, so...let's see how many folks turn out
2026-04-06 16:02:29 <@nielsenb:fedora.im> I had my ham yesterday
2026-04-06 16:02:44 <@ngompa:fedora.im> !hi
2026-04-06 16:02:44 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2026-04-06 16:02:51 <@korora:fedora.im> !hi
2026-04-06 16:02:52 <@zodbot:fedora.im> Jocelyn Gould (korora) - she / her / hers
2026-04-06 16:03:11 <@derekenz:fedora.im> !hi
2026-04-06 16:03:12 <@zodbot:fedora.im> Derek Enz (derekenz)
2026-04-06 16:03:28 <@aggraxis:fedora.im> !hi
2026-04-06 16:03:29 <@zodbot:fedora.im> Paul Maconi (aggraxis) - he / him / his
2026-04-06 16:05:53 <@adamwill:fedora.im> hi everyone, thanks for coming out
2026-04-06 16:06:23 <@adamwill:fedora.im> if you ever want to stage a revolution and kick RH out of Fedora, do it on Easter
2026-04-06 16:06:24 <@adamwill:fedora.im> :P
2026-04-06 16:06:36 <@adamwill:fedora.im> let's have some boilerplate!
2026-04-06 16:06:44 <@adamwill:fedora.im> Why are we here?
2026-04-06 16:06:44 <@adamwill:fedora.im> !topic Introduction
2026-04-06 16:06:44 <@adamwill:fedora.im> !info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
2026-04-06 16:06:44 <@adamwill:fedora.im> !info The criteria for release blocking bugs can be found at:
2026-04-06 16:06:44 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Basic_Release_Criteria
2026-04-06 16:06:44 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Fedora_44_Beta_Release_Criteria
2026-04-06 16:06:44 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria
2026-04-06 16:06:44 <@adamwill:fedora.im> !link http://qa.fedoraproject.org/blockerbugs/current
2026-04-06 16:06:44 <@adamwill:fedora.im> !info The bugs up for review today are available at:
2026-04-06 16:06:44 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
2026-04-06 16:06:44 <@adamwill:fedora.im> !info We'll be following the process outlined at:
2026-04-06 16:06:47 <@adamwill:fedora.im> !info for Final, we have:
2026-04-06 16:07:05 <@adamwill:fedora.im> !info 4 Proposed Blockers
2026-04-06 16:07:05 <@adamwill:fedora.im> !info 5 Accepted Blockers
2026-04-06 16:07:08 <@adamwill:fedora.im> !info 5 Accepted Freeze Exceptions
2026-04-06 16:07:08 <@adamwill:fedora.im> !info 3 Proposed Freeze Exceptions
2026-04-06 16:07:16 <@adamwill:fedora.im> anyone want to secretarialize?
2026-04-06 16:07:24 <@adamwill:fedora.im> (that is, recording the results of the meeting into bugzilla)
2026-04-06 16:07:59 <@adamwill:fedora.im> if not, i'll do it
2026-04-06 16:08:41 <@nielsenb:fedora.im> When I tried I couldn't set the whiteboard entries on tickets, so I'm a bad candidate
2026-04-06 16:08:54 <@adamwill:fedora.im> ah, right
2026-04-06 16:09:00 <@adamwill:fedora.im> !info adamw will secretarialize
2026-04-06 16:09:10 <@adamwill:fedora.im> let's get started with:
2026-04-06 16:09:14 <@adamwill:fedora.im> !topic Proposed Final blockers
2026-04-06 16:09:22 <@adamwill:fedora.im> !topic (2454156) No update notification in main Notifications view
2026-04-06 16:09:22 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+3,0,-0) (+asciiwolf, +derekenz, +nielsenb)
2026-04-06 16:09:22 <@adamwill:fedora.im> !info Proposed Blocker, plasma-desktop, NEW
2026-04-06 16:09:22 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2091
2026-04-06 16:09:22 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2454156
2026-04-06 16:09:40 <@adamwill:fedora.im> so this has +3 but i left it on the list because there's important info missing that was only on Matrix, sorry
2026-04-06 16:10:02 <@adamwill:fedora.im> Derek Enz tried to reproduce manually and could not, he sees notifications
2026-04-06 16:10:09 <@nielsenb:fedora.im> I have an install going right now
2026-04-06 16:10:30 <@adamwill:fedora.im> it's possible this is somehow weirdly triggered by openQA's attempts to make sure an update is available, or something
2026-04-06 16:10:32 <@derekenz:fedora.im> I was for build 20260402
2026-04-06 16:10:38 <@derekenz:fedora.im> It*
2026-04-06 16:10:43 <@adamwill:fedora.im> i also am running a manual test, just got to the desktop
2026-04-06 16:11:17 <@adamwill:fedora.im> ok, got the circular icon and the transient notification
2026-04-06 16:11:46 <@adamwill:fedora.im> and there's a vibrating bell and the other notification. so yeah, it works fine. i dunno why it's failing in openQA. odd
2026-04-06 16:12:05 <@adamwill:fedora.im> i'll update the bug report and ticket. for me that makes this a -1, it's apparently a weird openQA thing i'll have to debug
2026-04-06 16:13:02 <@nielsenb:fedora.im> Agreed, if it's working for people (my at hand test system is sloooow, so I don't have a personal result yet), I'm FinalBlocker -1
2026-04-06 16:13:51 <@derekenz:fedora.im> FinalBlocker -1
2026-04-06 16:13:57 <@adamwill:fedora.im> since i proposed it, i've unproposed it, that's easier
2026-04-06 16:14:07 <@nielsenb:fedora.im> Haha
2026-04-06 16:14:12 <@adamwill:fedora.im> !info this has been unproposed based on manual testing which did not reproduce the bug and saw all the expected notifications
2026-04-06 16:14:20 <@nielsenb:fedora.im> Didn't realize that was an option, I had one I would have unproposed awhile ago.
2026-04-06 16:15:52 <@adamwill:fedora.im> yeah, it's not exactly written down anywhere but I always figure the proposer has a right to unpropose. just make sure to note the reason in a comment or whatever so if anyone disagrees they can repropose :D
2026-04-06 16:16:16 <@adamwill:fedora.im> hmm, so...i think i'm gonna do something fancy here
2026-04-06 16:16:27 <@adamwill:fedora.im> !topic (2448283) Selecting a non-ASCII capable keyboard layout should automatically also select US English as a second layout AND (2453216) plasma-setup Keyboard Layout page pre-selection is broken - always shows English (US) if that is the system language, otherwise shows nothing
2026-04-06 16:16:35 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2078
2026-04-06 16:16:35 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2448283
2026-04-06 16:16:39 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2453216
2026-04-06 16:16:39 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2087
2026-04-06 16:16:46 <@adamwill:fedora.im> !info Proposed Blockers, plasma-setup, NEW
2026-04-06 16:17:02 <@adamwill:fedora.im> !info Ticket vote 2448283: FinalBlocker (+0,0,-1) (-nielsenb)
2026-04-06 16:17:13 <@adamwill:fedora.im> !info Ticket vote 2453216: FinalBlocker (+4,0,-0) (+asciiwolf, +geraldosimiao, +derekenz, +nielsenb)
2026-04-06 16:17:30 <@adamwill:fedora.im> i figure we should take these together as they kind of have a combined impact, despite being separate bugs
2026-04-06 16:17:36 <@adamwill:fedora.im> it feels hard to discuss them individually
2026-04-06 16:19:02 <@adamwill:fedora.im> the combined effect of the two is that installing KDE if your locale and keyboard layout are not US English feels a bit weird and is especially dangerous if you use a 'switched layout' config where you set up US English *and* a native layout - Russian is the most prominent case but there are others
2026-04-06 16:19:57 <@adamwill:fedora.im> in those cases, the installer does the right thing when you pick your language, it sets the correct layout config. then you boot the installed system and reach plasma-setup. the first page shows your language, correctly. the Keyboard Layout page shows nothing at all as selected.
2026-04-06 16:20:19 <@adamwill:fedora.im> also, during plasma-setup, layout switching doesn't work, which might cause you to conclude it's not configured, if you try it out.
2026-04-06 16:20:45 <@adamwill:fedora.im> if you leave the page showing nothing selected and proceed, things work correctly. when you reach the desktop you'll have both layouts configured.
2026-04-06 16:21:32 <@adamwill:fedora.im> if you see the 'nothing selected' page and decide to pick something, though, you picked wrong. if you pick English (US) it's not a disaster; you get *just* English (US) as the final layout, and can always add your native layout in the control center
2026-04-06 16:22:06 <@adamwill:fedora.im> if you pick Russian (or whatever your native layout is), you're now stuck in that layout and likely cannot create a user account successfully. unless you go back to this page (I think that's possible? didn't test) and pick US English
2026-04-06 16:22:30 <@adamwill:fedora.im> on the whole, it's a pretty bad experience.
2026-04-06 16:23:35 <@adamwill:fedora.im> note that since the last meeting, Workstation has been more or less 'fixed' because Michael Catanzaro made g-i-s skip both pages, on the basis that the installer handles it. in fact the Workstation installer doesn't really 'handle' it, it gives you a link to the Control Center where you can do it manually, but if you do that, it does work, and persist through to the installed system.
2026-04-06 16:24:18 <@adamwill:fedora.im> do we have other KDE folks around? Conan Kudo Steve Cossette (Farchord) ?
2026-04-06 16:24:40 <@ngompa:fedora.im> I'm here
2026-04-06 16:25:10 <@ngompa:fedora.im> I _really_ don't want to do the solution Michael Catanzaro went with because it basically breaks the OEM flow.
2026-04-06 16:25:49 <@ngompa:fedora.im> I am surprised he even considered it acceptable since Fedora Workstation is _currently_ preloaded on Lenovo, Slimbook, and Novacustom PCs.
2026-04-06 16:27:24 <@ngompa:fedora.im> The whole point of shipping Plasma Setup is to make every install operate like an OEM install.
2026-04-06 16:28:25 <@ngompa:fedora.im> We want to make these blockers? Then we'll have to do so and talk to Merritt about fixing them.
2026-04-06 16:29:33 <@adamwill:fedora.im> well, that's the question in the meeting. :D do we block on this?
2026-04-06 16:29:55 <@adamwill:fedora.im> https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Keyboard_layout_configuration is the related criterion
2026-04-06 16:30:06 <@adamwill:fedora.im> (note I snuck "in the installer" in there this week because it wasn't there but obviously it should have been)
2026-04-06 16:30:22 <@nielsenb:fedora.im> We block on one, the other, or both of them, yes. :D
2026-04-06 16:30:35 <@adamwill:fedora.im> sigh. i just realized i should've filed a*nother* bug which is actually the clearest technical blocker here
2026-04-06 16:30:45 <@nielsenb:fedora.im> All three then.
2026-04-06 16:30:47 <@adamwill:fedora.im> "layout switching doesn't work during plasma-setup itself"
2026-04-06 16:31:03 <@adamwill:fedora.im> that clearly violates the criterion, but is actually the least serious bug because you rarely would actually want to *do* that
2026-04-06 16:31:09 <@nielsenb:fedora.im> Configuring wifi doesn't seem to work in plasma-setup either, but I'm still testing....
2026-04-06 16:31:54 <@mcatanzaro:gnome.org> gnome-initial-setup does not have an OEM mode. (It should, but it does not.) It only has existing user mode (where we assume the user just created their user account) and new user mode (which the user _never_ sees). I agree we should create an OEM mode and do language and keyboard layout there, but that's new work. Maybe I will have time for it soon....
2026-04-06 16:32:04 <@adamwill:fedora.im> of these two...i guess the combination of the both produces a subjective blocker where the user is very likely to make a reasonable choice which would cause a violation of "When logging in via the default login manager for a release-blocking desktop" and "After logging in to a release-blocking desktop"
2026-04-06 16:32:32 <@adamwill:fedora.im> Michael Catanzaro um, the mode we see on a standard Workstation install is "new user mode" is it not?
2026-04-06 16:32:38 <@adamwill:fedora.im> since we don't create a user account in the installer.
2026-04-06 16:33:03 <@derekenz:fedora.im> Only seen that with the Rpi tests so far. There is a BZ report.
2026-04-06 16:33:07 <@mcatanzaro:gnome.org> Yes. My comment is backwards. I will edit it.
2026-04-06 16:33:10 <@adamwill:fedora.im> heh
2026-04-06 16:33:23 <@mcatanzaro:gnome.org> FWIW, anything wrong with keyboard layout is so exceptionally annoying that it should almost always be a blocker IMO....
2026-04-06 16:34:08 <@mcatanzaro:gnome.org> gnome-initial-setup does not have an OEM mode. (It should, but it does not.) It only has new user mode (where we create the new user account) and an inaccessible existing user mode (which has been disabled for years, but assumes that the user just created their user account in anaconda). I agree we should create an OEM mode and do language and keyboard layout there, but that's new work. Maybe I will have time for it soon....
2026-04-06 16:34:11 <@ngompa:fedora.im> I don't disagree either. Language and input are critical foundations for interacting with the computer.
2026-04-06 16:35:03 <@mcatanzaro:gnome.org> The question I would have if adding OEM mode to gnome-initial-setup is: how to detect whether or not to use it.
2026-04-06 16:35:20 <@ngompa:fedora.im> The "new user mode" is effectively our OEM mode. That's how the OEMs are treating it today.
2026-04-06 16:35:28 <@sgallagh:fedora.im> Alternately, we just mandate that everyone must use Fedora in Esperanto with the Dvorak keyboard. Then we probably won't ever have to vote on another blocker!
2026-04-06 16:35:38 <@ngompa:fedora.im> 🤣
2026-04-06 16:36:42 <@mcatanzaro:gnome.org> (Continuing the possibly-unhelpful tangent: I don't want to show language and keyboard layout in new user mode, because my goal is to avoid redundancy. The user is assumed to have already selected those....)
2026-04-06 16:36:46 <@adamwill:fedora.im> i mean, that's a nice stance in theory, in practice we shipped lives for years that did not handle this stuff at all and nobody rebelled, so i find it hard to know where to stand
2026-04-06 16:37:17 <@nielsenb:fedora.im> But to some degree we should want to improve, no?
2026-04-06 16:37:20 <@adamwill:fedora.im> we're trying harder to have the live images do this stuff now. in the past we basically acted as if the criteria applied only to traditional installers as that was the only path that actually handled it
2026-04-06 16:37:33 <@nielsenb:fedora.im> Especially in first impression touch points.
2026-04-06 16:37:46 <@adamwill:fedora.im> can we ignore the gnome tangent and focus on kde?
2026-04-06 16:38:09 <@adamwill:fedora.im> for practical purposes, afaict, we do not have any blockers here in gnome (even japanese somehow magically works, which i was worried about)
2026-04-06 16:39:25 <@ngompa:fedora.im> I don't really want to disable the pages in Plasma Setup. My entire motivation for KDE OOBE is because I am working on OEM arrangements for Fedora KDE. I'm fine with them being blockers and trying to prioritize getting some kind of fix into Plasma Setup.
2026-04-06 16:40:36 <@adamwill:fedora.im> i do think fixing it in the next couple of days is unrealistic
2026-04-06 16:41:00 <@adamwill:fedora.im> because a 'fix' really has to be a 'complete redesign of this page's UI', because it's based on a false assumption: that you always pick exactly one keyboard layout
2026-04-06 16:41:30 <@ngompa:fedora.im> maybe... at least for the one about secondary layouts maybe Merritt can add a bodge to just always add us as a secondary layout for non-Latin scripts?
2026-04-06 16:41:37 <@ngompa:fedora.im> maybe... at least for the one about secondary layouts maybe Merritt can add a bodge to just always add `us` as a secondary layout for non-Latin scripts?
2026-04-06 16:41:38 <@sgallagh:fedora.im> On the other hand, it's Neal, so that's like, Tuesday for him
2026-04-06 16:41:43 <@adamwill:fedora.im> (ok maybe for a quick bodge you could redefine it as 'input configuration' or something and treat selecting 'russian' as meaning 'select english (us) and russian'...meh)
2026-04-06 16:42:31 <@adamwill:fedora.im> on the whole i'd lean towards accepting too. but with an eye to a 'will take too long to fix' waiver
2026-04-06 16:42:48 <@ngompa:fedora.im> at least then it's auto-accepted for F45
2026-04-06 16:42:49 <@sgallagh:fedora.im> Yeah, that's the suggestion I was about to make: it sounds like we all more or less agree it's a blocker
2026-04-06 16:42:52 <@ahmedalmeleh:matrix.org> !hi sorry I am bit late
2026-04-06 16:42:54 <@zodbot:fedora.im> Sorry, I can only look up one username at a time
2026-04-06 16:42:56 <@sgallagh:fedora.im> We're just trying to argue ourselves out of it
2026-04-06 16:43:17 <@ahmedalmeleh:matrix.org> !hi
2026-04-06 16:43:19 <@zodbot:fedora.im> Ahmed Almeleh (ahmedalmeleh) - he / him / his
2026-04-06 16:43:19 <@adamwill:fedora.im> i'd say we mark both as accepted with a note saying basically 'we need KDE folks to make this experience better, once they think they've made it better we'll take another look and re-evaluate"
2026-04-06 16:44:55 <@sgallagh:fedora.im> adamw: Isn't that basically the implied state when we mark "incorrect behavior" as a blocker?
2026-04-06 16:46:06 <@adamwill:fedora.im> proposed !agreed 2448283 and 2453216 - AcceptedBlocker (Final) - these are accepted as blockers on the basis that we find their combined effect makes it very likely users who expect to use a "switched input" configuration will pick their layout on the Keyboard Layout page, with results that violate the criterion keyboard layout criterion and make completing the setup process impossible unless they then make another choice. We expect plasma-setup folks to consider the overall expected flow here and make improvements, then we will re-evaluate whether any blocker effects remain
2026-04-06 16:46:19 <@derekenz:fedora.im> ack
2026-04-06 16:46:32 <@adamwill:fedora.im> Stephen Gallagher yeah, but it's more about having both bugs as blockers - perhaps one bug might technically not be 'fixed' but we decide we've reached a state which is shippable
2026-04-06 16:46:41 <@ngompa:fedora.im> ack
2026-04-06 16:46:45 <@nielsenb:fedora.im> ack
2026-04-06 16:46:51 <@sgallagh:fedora.im> ack
2026-04-06 16:46:54 <@sgallagh:fedora.im> Good enough for me
2026-04-06 16:47:03 <@ahmedalmeleh:matrix.org> ack
2026-04-06 16:47:38 <@adamwill:fedora.im> btw, for non-switched layouts things are better - the 'it shows nothing pre-selected' bug remains, but things will be fine whether you leave it that way and proceed, or pick your desired layout. the 'switched' layout case is definitely the worst
2026-04-06 16:48:31 <@ahmedalmeleh:matrix.org> I don't actually use fed kde myself 
2026-04-06 16:48:55 <@adamwill:fedora.im> !agreed 2448283 and 2453216 - AcceptedBlocker (Final) - these are accepted as blockers on the basis that we find their combined effect makes it very likely users who expect to use a "switched input" configuration will pick their layout on the Keyboard Layout page, with results that violate the criterion keyboard layout criterion and make completing the setup process impossible unless they then make another choice. We expect plasma-setup folks to consider the overall expected flow here and make improvements, then we will re-evaluate whether any blocker effects remain
2026-04-06 16:49:17 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2453005
2026-04-06 16:49:17 <@adamwill:fedora.im> !info Proposed Blocker, systemd, NEW
2026-04-06 16:49:17 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2086
2026-04-06 16:49:17 <@adamwill:fedora.im> !topic (2453005) systemd-oomd.service is not enabled on some systems
2026-04-06 16:49:17 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
2026-04-06 16:49:38 <@adamwill:fedora.im> it kinda seems like this is narrowing down to 'maybe it's not enabled if you installed some rawhide snapshot from a few months ago'
2026-04-06 16:49:42 <@adamwill:fedora.im> which doesn't really feel blockery
2026-04-06 16:49:52 <@sgallagh:fedora.im> I'm not sure that's accurate
2026-04-06 16:50:02 <@sgallagh:fedora.im> I think it may actually depend on package set being installed.
2026-04-06 16:50:30 <@ngompa:fedora.im> yeah and that's the wild part
2026-04-06 16:50:36 <@ngompa:fedora.im> that doesn't make sense and it's happening anyway
2026-04-06 16:50:36 <@adamwill:fedora.im> that would also not be blocker-y, unless a default package set is affected
2026-04-06 16:50:56 <@adamwill:fedora.im> one non-obvious effect of different package sets can be different install ordering, which can cause all kinds of stuff due to scriptlet ordering
2026-04-06 16:51:33 <@ngompa:fedora.im> my actual guess here is that these are all netinstalls
2026-04-06 16:51:47 <@sgallagh:fedora.im> The good news is that resolving this is literally a one-liner in the presets
2026-04-06 16:52:18 <@ngompa:fedora.im> systemd-oomd has been enabled in the presets for a while now
2026-04-06 16:52:21 <@sgallagh:fedora.im> So I'm definitely in favor of an FE at least
2026-04-06 16:52:34 <@sgallagh:fedora.im> Neal Gompa (Fedora): See the explanation in https://src.fedoraproject.org/rpms/fedora-release/pull-request/409 
2026-04-06 16:52:42 <@ngompa:fedora.im> ah yes
2026-04-06 16:52:45 <@ngompa:fedora.im> I forgot about that
2026-04-06 16:52:50 <@sgallagh:fedora.im> It's systemd-oomd.service vs .socket
2026-04-06 16:52:56 <@ngompa:fedora.im> that needs to be PR'd into redhat-systemd-presets too
2026-04-06 16:53:03 <@sgallagh:fedora.im> It's there already
2026-04-06 16:53:11 <@sgallagh:fedora.im> I just haven't had a chance to merge and build them yet today
2026-04-06 16:53:30 <@sgallagh:fedora.im> (I was preparing to do so when I realized this meeting had started)
2026-04-06 16:53:35 <@adamwill:fedora.im> does a one-liner in the presets fix upgrades of affected systems?
2026-04-06 16:53:45 <@ngompa:fedora.im> no, a scriptlet will be required
2026-04-06 16:54:04 <@ahmedalmeleh:matrix.org> So was it only an issue in the rare rawhide snapshot cases?
2026-04-06 16:54:26 <@sgallagh:fedora.im> Ahmed Almeleh: That part is still unclear.
2026-04-06 16:55:20 <@sgallagh:fedora.im> adamw: Yeah, I think Neal is right. We'd need to add a one-time force enable of the preset.
2026-04-06 16:55:32 <@sgallagh:fedora.im> Which isn't something everyone will love, if they've manually disabled it for any reason
2026-04-06 16:55:36 <@adamwill:fedora.im> that seems awkward, especially for something that some people don't like
2026-04-06 16:55:39 <@adamwill:fedora.im> ..yes exactly
2026-04-06 16:55:39 <@ngompa:fedora.im> we can check if systemd-oomd.service is enabled and then enable the socket
2026-04-06 16:55:43 <@adamwill:fedora.im> can we tell whether someone manually disabled it?
2026-04-06 16:56:16 <@ngompa:fedora.im> `systemctl is-enabled systemd-oomd.service`
2026-04-06 16:56:24 <@ngompa:fedora.im> `systemctl --quiet is-enabled systemd-oomd.service`
2026-04-06 16:56:26 <@sgallagh:fedora.im> I don't think we can disambiguate "manually disabled" from "never enabled by preset"
2026-04-06 16:56:33 <@adamwill:fedora.im> fun
2026-04-06 16:57:02 <@adamwill:fedora.im> i'm fine with an FE to fix the preset issue, sure. trying to fix this with a scriptlet feels sketchy. but i guess we're not supposed to take that into account when discussing blocker status
2026-04-06 16:57:26 <@adamwill:fedora.im> so my totally unbiased opinion is we should -1 it cos it doesn't always happen. ;)
2026-04-06 16:57:30 <@ngompa:fedora.im> I've had to do stuff like that before with triggers for system upgrades
2026-04-06 16:57:38 <@ngompa:fedora.im> to fix weirdness
2026-04-06 16:57:39 <@sgallagh:fedora.im> Neal Gompa (Fedora): `is-enabled` doesn't know if it's disabled by choice or by omission
2026-04-06 16:57:47 <@adamwill:fedora.im> yes but clearly you managed to sneak it in without me noticing
2026-04-06 16:58:02 <@ngompa:fedora.im> pffft
2026-04-06 16:58:20 <@ngompa:fedora.im> but also we can just stop the bleeding at least
2026-04-06 16:58:25 <@ngompa:fedora.im> and figure out what to do later
2026-04-06 16:59:04 <@sgallagh:fedora.im> Honestly, I think we're better off with just Common Bugs on the possibility that oomd might not be enabled in some cases we haven't narrowed down yet.
2026-04-06 16:59:07 <@sgallagh:fedora.im> And just fixing the preset
2026-04-06 16:59:23 <@adamwill:fedora.im> yeah
2026-04-06 16:59:29 <@adamwill:fedora.im> -1 blocker, +1 fe for preset fix
2026-04-06 16:59:30 <@adamwill:fedora.im> other votes?
2026-04-06 16:59:44 <@sgallagh:fedora.im> -1 blocker, +1 FE
2026-04-06 16:59:57 <@derekenz:fedora.im> Blocker -1, FE +1
2026-04-06 17:00:05 <@sgallagh:fedora.im> Actually, I'll revise that.
2026-04-06 17:00:17 <@sgallagh:fedora.im> The expected installed state of the system is to have oomd enabled.
2026-04-06 17:00:19 <@nielsenb:fedora.im> FinalFE +1
2026-04-06 17:00:22 <@ahmedalmeleh:matrix.org> I agree -1 blocker +1fe
2026-04-06 17:00:23 <@nielsenb:fedora.im> FinalBlocker -1
2026-04-06 17:00:26 <@sgallagh:fedora.im> So I think it's +1 blocker
2026-04-06 17:00:39 <@ngompa:fedora.im> -1 FB +1 FE
2026-04-06 17:00:41 <@ahmedalmeleh:matrix.org> I agree -1 blocker  +1fe
2026-04-06 17:00:42 <@sgallagh:fedora.im> The upgrade situation could be waived as  "too hard/too late"
2026-04-06 17:00:52 <@ngompa:fedora.im> oh fair
2026-04-06 17:00:52 <@adamwill:fedora.im> Stephen Gallagher but this doesn't *always* happen
2026-04-06 17:00:59 <@adamwill:fedora.im> the criterion is:
2026-04-06 17:01:16 <@adamwill:fedora.im> "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed."
2026-04-06 17:01:57 <@ngompa:fedora.im> +1 FB +1 FE
2026-04-06 17:02:07 <@adamwill:fedora.im> unless systemd-oomd is consistently disabled when you follow those implied steps (install a release-blocking f42/f43 edition, update it, upgrade it to f44), this becomes a subjective decision per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? , i'd say
2026-04-06 17:02:14 <@ngompa:fedora.im> simply because both the netinstall and upgrade cases are incoherently affected without the correct preset
2026-04-06 17:02:40 <@adamwill:fedora.im> we *can* also punt it (implicitly to go/no-go on thursday)
2026-04-06 17:02:43 <@ngompa:fedora.im> theoretically the socket enable will take effect when the preset changes with system upgrade
2026-04-06 17:02:47 <@sgallagh:fedora.im> As long as it gets the FE, I'm going to make sure it's fixed, but I still feel like "blocker" feels more correct.
2026-04-06 17:03:18 <@ngompa:fedora.im> afaik fedora-release is one of the first packages in the upgrade transaction
2026-04-06 17:03:23 <@ahmedalmeleh:matrix.org> Its one of those tricky ones where it's not obvious 
2026-04-06 17:03:25 <@ngompa:fedora.im> it's at least usually before systemd
2026-04-06 17:03:45 <@derekenz:fedora.im> If it can be fixed in time, sounds good to me
2026-04-06 17:04:02 <@ngompa:fedora.im> and in F45+ we can fix this by making systemd require `distribution-systemd-presets`
2026-04-06 17:04:10 <@ngompa:fedora.im> and in F45+ we can fix the ordering by making systemd require `distribution-systemd-presets`
2026-04-06 17:04:14 <@sgallagh:fedora.im> Derek Enz: I'm going to land the fix and build it in a few minutes. I just need to make a minor tweak to the MR that zbyszek sent
2026-04-06 17:04:29 <@adamwill:fedora.im> if we take "this fails on upgrade from <some existing install> to f44" as a blocker, we cannot fix it with just a known preset change, iaui
2026-04-06 17:04:34 <@adamwill:fedora.im> if we take "this fails on upgrade from <some existing install> to f44" as a blocker, we cannot fix it with just a known preset change, aiui
2026-04-06 17:05:14 <@sgallagh:fedora.im> adamw: No, but as I said above, I think I'd be okay with the "too late/too hard" waive at Go/No-Go
2026-04-06 17:06:09 <@adamwill:fedora.im> hmm
2026-04-06 17:06:12 <@adamwill:fedora.im> there's also Zbigniew's note
2026-04-06 17:06:13 <@adamwill:fedora.im> has Requires=systemd-oomd.socket, so when it is started, the socket will be started
2026-04-06 17:06:13 <@adamwill:fedora.im> "This ultimately doesn't matter much, because systemd-oomd.service
2026-04-06 17:06:13 <@adamwill:fedora.im> too. The socket is used by user managers, which run later anyway."
2026-04-06 17:06:24 <@adamwill:fedora.im> does that mean oomd effectively *works* either way?
2026-04-06 17:07:43 <@ngompa:fedora.im> No.
2026-04-06 17:07:43 <@sgallagh:fedora.im> I think so, yeah
2026-04-06 17:07:49 <@ngompa:fedora.im> It doesn't.
2026-04-06 17:07:53 <@sgallagh:fedora.im> No?
2026-04-06 17:08:06 <@ngompa:fedora.im> The bug report asserts the practical effect is that oomd doesn't start
2026-04-06 17:08:10 <@adamwill:fedora.im> also, zbigniew says his fix is for the socket, but the bug report claims the service is disabled (but the output in the first comment is actually about the socket)?
2026-04-06 17:08:31 <@adamwill:fedora.im> in the initial report, step 2 is "systemctl status systemd-oomd.service"
2026-04-06 17:08:42 <@adamwill:fedora.im> but the pasted output is about "systemd-oomd.socket"
2026-04-06 17:09:32 <@sgallagh:fedora.im> Right... so we don't actually know if the service is running
2026-04-06 17:09:56 <@adamwill:fedora.im> oh, the screenshot shows the service output
2026-04-06 17:09:59 <@adamwill:fedora.im> https://bugzilla-attachments.redhat.com/attachment.cgi?id=2135609
2026-04-06 17:10:52 <@adamwill:fedora.im> so. um. i don't see how zbigniew's PR is gonna fix the service being disabled?
2026-04-06 17:10:53 <@sgallagh:fedora.im> OK, so that says the preset is disabled, but it's triggered by the socker.
2026-04-06 17:10:57 <@sgallagh:fedora.im> Which is also not enabled.
2026-04-06 17:11:00 <@sgallagh:fedora.im> OK, so that says the preset is disabled, but it's triggered by the socket.
2026-04-06 17:12:09 <@adamwill:fedora.im> also, hmm, going back to the criteria. the criteria say you must be able to upgrade, which you are. they also say "The upgraded system must meet all release criteria", which is presumably the clause we're using here
2026-04-06 17:12:33 <@sgallagh:fedora.im> But there's no criterion that OOM handling must use oomd, I guess.
2026-04-06 17:12:47 <@adamwill:fedora.im> i'm trying to find an applicable criterion at all actually
2026-04-06 17:12:58 <@adamwill:fedora.im> we have a criterion saying that enabled services must start successfully
2026-04-06 17:12:59 <@nielsenb:fedora.im> That's what I was wondering
2026-04-06 17:13:06 <@adamwill:fedora.im> but i don't see one saying that services intended to be enabled must be enabled
2026-04-06 17:13:12 <@adamwill:fedora.im> and we don't have anything specific about oom
2026-04-06 17:13:12 <@nielsenb:fedora.im> Don't you still get an OOM killer, just maybe not the one you wanted.
2026-04-06 17:13:18 <@adamwill:fedora.im> the kernel one
2026-04-06 17:13:26 <@ngompa:fedora.im> which is undesirable
2026-04-06 17:13:34 <@nielsenb:fedora.im> And the service just technically becomes not-enabled...
2026-04-06 17:13:46 <@nielsenb:fedora.im> It's definitely not the desired behavior, but I'm not sure it's blockery
2026-04-06 17:13:48 <@adamwill:fedora.im> i've got a list of undesirable stuff as long as my arm but none of it blocks the release ;)
2026-04-06 17:14:34 <@nielsenb:fedora.im> Nobody expects the kernel OOM killer
2026-04-06 17:14:43 <@adamwill:fedora.im> neal proposed this under "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." , but i'm not buying it, tbh
2026-04-06 17:14:53 <@ngompa:fedora.im> the practical effect doesn't really matter... whether it's an FE or a blocker, it's getting fixed today
2026-04-06 17:14:57 <@adamwill:fedora.im> all the present system services *do* start properly
2026-04-06 17:15:03 <@nielsenb:fedora.im> Yeah, it starts
2026-04-06 17:15:07 <@sgallagh:fedora.im> I am disappointed to discover that there's no "spanish inquisition" emoji
2026-04-06 17:15:23 <@nielsenb:fedora.im> Same, my day is ruined
2026-04-06 17:15:32 <@adamwill:fedora.im> well, no, we can fix the bug we think there is in the presets. we know this won't change anything for installed systems, and we don't know if it'll actually fix the observed bug
2026-04-06 17:16:40 <@sgallagh:fedora.im> Yeah, the more I look at this initial report, the more certain I am that it's probably ONLY an issue on upgrades, and only in unlikely situations
2026-04-06 17:16:49 <@adamwill:fedora.im> anyhow, yeah, after doing the criterion work, i'm -1 blocker on this. i don't think it violates any. i guess I can be +1 FE for the preset fix as it seems harmless
2026-04-06 17:16:54 <@sgallagh:fedora.im> I just have no idea how this happened
2026-04-06 17:17:15 <@jlinton:fedora.im> I've seen a similar thing but for just generic networking services in the past, I always assumed it was someone tweaking the namingi//location of the service files. 
2026-04-06 17:17:18 <@sgallagh:fedora.im> Agreed, -1 blocker. (Sorry for waffling repeatedly)
2026-04-06 17:17:35 <@derekenz:fedora.im> FB -1 FE +1
2026-04-06 17:18:26 <@ngompa:fedora.im> FB -1 FE +1
2026-04-06 17:18:34 <@nielsenb:fedora.im> FinalBlocker -1
2026-04-06 17:18:36 <@nielsenb:fedora.im> FinalFE +1
2026-04-06 17:19:01 <@ahmedalmeleh:matrix.org> FB -1 FE+1
2026-04-06 17:19:24 <@ahmedalmeleh:matrix.org> FB -1 FE +1
2026-04-06 17:20:23 <@adamwill:fedora.im> proposed !agreed 2453005 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as it does not violate any criteria. The upgrade criterion requires that upgrade work and the upgraded system meet other criteria. The service criterion says "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". This doesn't violate that - it's about a service *not being enabled* (i.e. "present"), not an enabled ("present") one *failing to start*. the absent service doesn't cause any significant functional issues that would violate any other criteria. It's accepted as an FE so we can put the obvious preset fix into F44 in case it helps avoid the problem in future
2026-04-06 17:20:29 <@derekenz:fedora.im> ack
2026-04-06 17:20:35 <@adamwill:fedora.im> you did not just read that wohle thing. ;)
2026-04-06 17:20:50 <@nielsenb:fedora.im> ack
2026-04-06 17:21:00 <@aggraxis:fedora.im> ack
2026-04-06 17:21:24 <@adamwill:fedora.im> !agreed 2453005 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as it does not violate any criteria. The upgrade criterion requires that upgrade work and the upgraded system meet other criteria. The service criterion says "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". This doesn't violate that - it's about a service not being enabled (i.e. "present"), not an enabled ("present") one failing to start. the absent service doesn't cause any significant functional issues that would violate any other criteria. It's accepted as an FE so we can put the obvious preset fix into F44 in case it helps avoid the problem in future
2026-04-06 17:22:10 <@adamwill:fedora.im> it'd be an interesting corner case if upgrading actually disabled a formerly-enabled service, but it kinda doesn't look like that's actually the case in this bug
2026-04-06 17:22:21 <@adamwill:fedora.im> anyhoo, moving on - a new proposed blocker has appeared
2026-04-06 17:22:33 <@adamwill:fedora.im> !info Proposed Blocker, plasma-setup, NEW
2026-04-06 17:22:33 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2455469
2026-04-06 17:22:33 <@adamwill:fedora.im> !topic (2455469) Configuring WifI network via Network pane appears to not work
2026-04-06 17:22:33 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2094
2026-04-06 17:22:47 <@korora:fedora.im> ack
2026-04-06 17:22:57 <@korora:fedora.im> I was late
2026-04-06 17:23:47 <@nielsenb:fedora.im> This bug feels like there's two wifi configuration flows fighting one another, and neither works
2026-04-06 17:23:51 <@ahmedalmeleh:matrix.org> Ack me too slow read
2026-04-06 17:24:52 <@sgallagh:fedora.im> Conan Kudo: Have you seen this one?
2026-04-06 17:24:56 <@derekenz:fedora.im> VM or bare metal?
2026-04-06 17:25:01 <@nielsenb:fedora.im> Bare metal
2026-04-06 17:25:06 <@nielsenb:fedora.im> Fairly legacy BIOS machine
2026-04-06 17:25:17 <@sgallagh:fedora.im> Brandon Nielsen: This is happening post install or in the Live environment?
2026-04-06 17:25:25 <@ngompa:fedora.im> I haven't, but Derek Enz did on an RPi 4 with the ARM disk image: https://bugs.kde.org/show_bug.cgi?id=514841
2026-04-06 17:25:41 <@nielsenb:fedora.im> Post install
2026-04-06 17:25:53 <@derekenz:fedora.im> Yeah the Rpi bare metal tests can confirm
2026-04-06 17:25:56 <@nielsenb:fedora.im> Config in the live environment seems to work like I would expect.
2026-04-06 17:26:19 <@derekenz:fedora.im> I have a BZ report with KDE
2026-04-06 17:27:00 <@nielsenb:fedora.im> Do you get 3 different dialogs to enter your password? Or do you just see the config not saved?
2026-04-06 17:27:01 <@ahmedalmeleh:matrix.org> Is this replicated in uefi system?
2026-04-06 17:27:05 <@ngompa:fedora.im> there seems to be something weird about NetworkManager 1.56
2026-04-06 17:27:51 <@derekenz:fedora.im> What happens is I can select the wifi enter pass, but it asks to enter pass again and connects
2026-04-06 17:28:14 <@derekenz:fedora.im> After reboot the connection is lost
2026-04-06 17:28:25 <@nielsenb:fedora.im> I get the same enter password dialog twice (first one disappears when I unfocus the password box)
2026-04-06 17:28:34 <@nielsenb:fedora.im> Then a 3rd, different, dialog appears
2026-04-06 17:28:37 <@derekenz:fedora.im> But I can re connect with no problems
2026-04-06 17:28:51 <@nielsenb:fedora.im> Then, after all of that, signing into the system has no network connection anyway
2026-04-06 17:28:58 <@nielsenb:fedora.im> Configuring it after signing it works fine
2026-04-06 17:29:23 <@nielsenb:fedora.im> I  haven't tried rebooting without configuring after signing in
2026-04-06 17:29:24 <@derekenz:fedora.im> Yes seems to be a plasma setup thing
2026-04-06 17:29:44 <@ngompa:fedora.im> what's happening is that despite creating a global connection with plasma-setup, NM is apparently saying it can only be accessed by the plasma-setup user
2026-04-06 17:29:59 <@ngompa:fedora.im> which is obviously not the regular user post configuration
2026-04-06 17:30:56 <@ngompa:fedora.im> afaik we reuse plasma-nm code here
2026-04-06 17:32:26 <@ngompa:fedora.im> upstream KDE on KDE Linux can't reproduce it on NM 1.54, and since we didn't ship Plasma Setup in F43 GA (since it didn't exist yet in a usable state) we don't have an F43 vs F44 comparison
2026-04-06 17:32:37 <@ngompa:fedora.im> but the only variation I can observe is the NM version
2026-04-06 17:32:54 <@adamwill:fedora.im> did you check for selinux avcs?
2026-04-06 17:33:54 <@nielsenb:fedora.im> I would, but the system decided to go to sleep and apparently can't wake up
2026-04-06 17:34:14 <@adamwill:fedora.im> who even wrote this crap?!
2026-04-06 17:34:21 <@adamwill:fedora.im> let's all go buy a Mac
2026-04-06 17:35:26 <@nielsenb:fedora.im> VTs are still alive
2026-04-06 17:35:36 <@nielsenb:fedora.im> Don't  think I see any SELinux shenanigans
2026-04-06 17:35:53 <@adamwill:fedora.im> journalctl -b | grep -i avc should be enough
2026-04-06 17:37:00 <@nielsenb:fedora.im> Yeah, nothing for that
2026-04-06 17:37:36 <@ngompa:fedora.im> Brandon Nielsen: could you check what the contents of the global nmconnection files are?
2026-04-06 17:37:50 <@adamwill:fedora.im> has anyone else tried this yet?
2026-04-06 17:37:55 <@ngompa:fedora.im> plasma-setup writes them out as global connections, so it'd be good to see if they got written with an access restriction
2026-04-06 17:38:08 <@adamwill:fedora.im> if it's reproducible, i guess it does meet the criteria so i'd have to be +1 blocker
2026-04-06 17:38:18 <@nielsenb:fedora.im> Where would those be written?
2026-04-06 17:38:32 <@ngompa:fedora.im> `/etc/NetworkManager/system-connections`
2026-04-06 17:38:50 <@nielsenb:fedora.im> Ah, capitol N, gets me every time
2026-04-06 17:38:51 <@nielsenb:fedora.im> Derp
2026-04-06 17:39:02 <@adamwill:fedora.im> NM is too cool to be confined to lower case
2026-04-06 17:39:15 <@ngompa:fedora.im> breaks past the lowercase :)
2026-04-06 17:39:24 <@ngompa:fedora.im> into UpperCase!
2026-04-06 17:39:28 <@nielsenb:fedora.im> Anything special I'm looking for?
2026-04-06 17:39:34 <@nielsenb:fedora.im> It gets created, settings seem reasonable
2026-04-06 17:39:54 <@nielsenb:fedora.im> permissions=user:plasma-setup::
2026-04-06 17:39:59 <@ngompa:fedora.im> yep that's the problem
2026-04-06 17:40:00 <@nielsenb:fedora.im> Which feels "sus", as the kids say
2026-04-06 17:40:07 <@ngompa:fedora.im> if you delete that line, your connection would work as normal
2026-04-06 17:40:14 <@ngompa:fedora.im> but it shouldn't be getting created that way in the first place
2026-04-06 17:40:23 <@ngompa:fedora.im> and it wasn't in older NM versions apparently
2026-04-06 17:40:35 <@derekenz:fedora.im> I think I did confirm that with Merritt
2026-04-06 17:40:53 <@adamwill:fedora.im> other votes?
2026-04-06 17:40:56 <@ngompa:fedora.im> yeah I think we can now say this is the same bug
2026-04-06 17:40:59 <@ngompa:fedora.im> so +1 FB
2026-04-06 17:41:06 <@derekenz:fedora.im> FB +1
2026-04-06 17:41:11 <@nielsenb:fedora.im> FinalBlocker +1
2026-04-06 17:41:53 <@ahmedalmeleh:matrix.org> FB+1
2026-04-06 17:44:23 <@adamwill:fedora.im> proposed !agreed 2455469 - AcceptedBlocker (Final) - this is accepted as a violation of Final criterion "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test" on KDE (successfully setting up a wifi connection certainly seems within the realms of 'basic functionality')
2026-04-06 17:44:27 <@ngompa:fedora.im> ack
2026-04-06 17:44:32 <@derekenz:fedora.im> ack
2026-04-06 17:44:38 <@nielsenb:fedora.im> ack
2026-04-06 17:44:54 <@adamwill:fedora.im> !agreed 2455469 - AcceptedBlocker (Final) - this is accepted as a violation of Final criterion "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test" on KDE (successfully setting up a wifi connection certainly seems within the realms of 'basic functionality')
2026-04-06 17:45:27 <@adamwill:fedora.im> !info that's all the proposed blockers, let's move on to:
2026-04-06 17:45:32 <@adamwill:fedora.im> !topic Proposed Freeze Exceptions
2026-04-06 17:45:40 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2090
2026-04-06 17:45:40 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2438126
2026-04-06 17:45:40 <@adamwill:fedora.im> !topic (2438126) CVE-2026-25727 fido-device-onboard: time affected by a stack exhaustion denial of service attack [fedora-43]
2026-04-06 17:45:40 <@adamwill:fedora.im> !info Proposed Freeze Exceptions, fido-device-onboard, ON_QA
2026-04-06 17:45:40 <@adamwill:fedora.im> !info Ticket vote: FinalFreezeException (+2,0,-0) (+nielsenb, +derekenz)
2026-04-06 17:47:43 <@adamwill:fedora.im> ok, sure, +1 FE
2026-04-06 17:47:47 <@adamwill:fedora.im> it's in IoT by default
2026-04-06 17:48:13 <@ngompa:fedora.im> +1 FE
2026-04-06 17:49:22 <@adamwill:fedora.im> proposed !agreed 2438126 - AcceptedFreezeException (Final) - this involves two CVEs in a package included in IoT by default. It's not a blocker as they're Moderate not Important or higher, but still good to pull in the fixes
2026-04-06 17:49:35 <@derekenz:fedora.im> ack
2026-04-06 17:49:47 <@nielsenb:fedora.im> ack
2026-04-06 17:50:30 <@korora:fedora.im> Ack
2026-04-06 17:50:36 <@adamwill:fedora.im> !agreed 2438126 - AcceptedFreezeException (Final) - this involves two CVEs in a package included in IoT by default. It's not a blocker as they're Moderate not Important or higher, but still good to pull in the fixes
2026-04-06 17:50:46 <@adamwill:fedora.im> !info Ticket vote: FinalFreezeException (+1,0,-0) (+nielsenb)
2026-04-06 17:50:46 <@adamwill:fedora.im> !topic (2437415) F44FailsToInstall: gala, gala-devel
2026-04-06 17:50:46 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2437415
2026-04-06 17:50:46 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2092
2026-04-06 17:50:46 <@adamwill:fedora.im> !info Proposed Freeze Exceptions, gala, ON_QA
2026-04-06 17:51:00 <@ahmedalmeleh:matrix.org> ack
2026-04-06 17:52:16 <@adamwill:fedora.im> +1, we generally give FEs to fix FTIs (it's nice to have a clean release repo, and also it helps with upgrades during freeze)
2026-04-06 17:52:37 <@derekenz:fedora.im> FE +1
2026-04-06 17:52:42 <@ngompa:fedora.im> FE +1
2026-04-06 17:52:46 <@ahmedalmeleh:matrix.org> FE+1
2026-04-06 17:53:05 <@ahmedalmeleh:matrix.org> We shall go the gala 
2026-04-06 17:53:27 <@nielsenb:fedora.im> And we shall feel pretty and make of the merry
2026-04-06 17:54:31 <@adamwill:fedora.im> proposed !agreed 2437415 - AcceptedFreezeException (Final) - this is accepted as usual for FTI fixes, it's nice to have clean release repos and it helps with upgrades during freeze
2026-04-06 17:54:32 <@sgallagh:fedora.im> FE +1
2026-04-06 17:54:49 <@derekenz:fedora.im> ack
2026-04-06 17:54:53 <@nielsenb:fedora.im> ack
2026-04-06 17:56:05 <@ngompa:fedora.im> ack
2026-04-06 17:56:09 <@ahmedalmeleh:matrix.org> ack easy read
2026-04-06 17:56:10 <@sgallagh:fedora.im> ack
2026-04-06 17:56:16 <@adamwill:fedora.im> !agreed 2437415 - AcceptedFreezeException (Final) - this is accepted as usual for FTI fixes, it's nice to have clean release repos and it helps with upgrades during freeze
2026-04-06 17:56:25 <@adamwill:fedora.im> !info Ticket vote: FinalFreezeException (+3,0,-0) (+zbyszek, +nielsenb, +derekenz)
2026-04-06 17:56:25 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2093
2026-04-06 17:56:25 <@adamwill:fedora.im> !info Proposed Freeze Exceptions, rust-add-determinism, ON_QA
2026-04-06 17:56:25 <@adamwill:fedora.im> !topic (2454664) FTBFS due to rlimit bump
2026-04-06 17:56:25 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2454664
2026-04-06 17:57:19 <@nielsenb:fedora.im> I'm only +1 because it sounds like this was intended and missed
2026-04-06 17:57:38 <@adamwill:fedora.im> i don't really see an FE justification here
2026-04-06 17:57:38 <@derekenz:fedora.im> yeah
2026-04-06 17:57:39 <@nielsenb:fedora.im> And Koji apparently would need this?
2026-04-06 17:57:45 <@nielsenb:fedora.im> Everyone else could pull it as an update
2026-04-06 17:58:05 <@adamwill:fedora.im> not totally sure what "Given we need this on every Koji build" means exactly
2026-04-06 17:59:29 <@nhanlon:beeper.com> !hi
2026-04-06 17:59:30 <@zodbot:fedora.im> Neil Hanlon (neil) - he / him / his
2026-04-06 17:59:30 <@sgallagh:fedora.im> I don't see any reason this needs to be in the stable repo
2026-04-06 17:59:40 <@ahmedalmeleh:matrix.org> it implies that koji needs it?
2026-04-06 18:00:25 <@nhanlon:beeper.com> Yeah -- it is run post build to strip nondeterminism
2026-04-06 18:00:38 <@adamwill:fedora.im> okay. but the current package installs and works, so...there's no problem.
2026-04-06 18:00:49 <@adamwill:fedora.im> okay. but the current package installs and works, so...there's no problem. (right?)
2026-04-06 18:00:52 <@nielsenb:fedora.im> Would koji not pull it in as an update?
2026-04-06 18:01:13 <@adamwill:fedora.im> Michel Lind ☘ UTC+1 🐰 around?
2026-04-06 18:01:56 <@nhanlon:beeper.com> zbyszek might also have context. i'm not sure why _this_ update needs to be in
2026-04-06 18:03:15 <@derekenz:fedora.im> hmm yeah was just going along with what he said
2026-04-06 18:04:46 <@adamwill:fedora.im> i'm a tentative -1, if we can't get more info now
2026-04-06 18:05:52 <@nielsenb:fedora.im> I would be willing to change my vote
2026-04-06 18:06:02 <@derekenz:fedora.im> Same here
2026-04-06 18:06:33 <@sgallagh:fedora.im> I'm -1
2026-04-06 18:06:43 <@nielsenb:fedora.im> FinalFE -1
2026-04-06 18:06:49 <@derekenz:fedora.im> FE -1
2026-04-06 18:07:01 <@ahmedalmeleh:matrix.org> FE-1
2026-04-06 18:08:21 <@adamwill:fedora.im> proposed !agreed 2454664 - RejectedFreezeException (Final) - there's no clear explanation why this merits an exception to the freeze. "Just in case we need it for some other reason" isn't sufficient justification; if said "other reason" emerges, that itself can be proposed as an FE and used to justify pulling this package in
2026-04-06 18:08:36 <@derekenz:fedora.im> ack
2026-04-06 18:08:54 <@nielsenb:fedora.im> ack
2026-04-06 18:08:56 <@aggraxis:fedora.im> ack
2026-04-06 18:09:10 <@adamwill:fedora.im> !agreed 2454664 - RejectedFreezeException (Final) - there's no clear explanation why this merits an exception to the freeze. "Just in case we need it for some other reason" isn't sufficient justification; if said "other reason" emerges, that itself can be proposed as an FE and used to justify pulling this package in
2026-04-06 18:09:28 <@adamwill:fedora.im> !info ok, that's all the proposals, let's quickly check in on:
2026-04-06 18:09:38 <@adamwill:fedora.im> !topic Accepted blocker review
2026-04-06 18:09:53 <@adamwill:fedora.im> !info skipping ON_QA and VERIFIED bugs
2026-04-06 18:10:02 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2074
2026-04-06 18:10:02 <@adamwill:fedora.im> !info Accepted Blocker, mesa, NEW
2026-04-06 18:10:02 <@adamwill:fedora.im> !topic (2359799) Inital-setup: VK_ERROR_DEVICE_LOST using nvidia hardware
2026-04-06 18:10:02 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2359799
2026-04-06 18:10:12 <@adamwill:fedora.im> oh, hi, michel, just too late 😅
2026-04-06 18:10:44 <@salimma:fedora.im> [@decathorpe:fedora.im](https://matrix.to/#/@decathorpe:fedora.im) suggested FE ing this but if nobody thinks it's necessary then we'll deal with it
2026-04-06 18:10:44 <@salimma:fedora.im> 
2026-04-06 18:10:44 <@salimma:fedora.im> It's a public holiday so sorry, I'm AFK
2026-04-06 18:11:09 <@salimma:fedora.im> Probably why not many Europeans are here today fwiw
2026-04-06 18:12:40 <@adamwill:fedora.im> it's a holiday more or less everywhere, but blocker review waits for no bunny
2026-04-06 18:12:55 <@salimma:fedora.im> Not for Americans I hear
2026-04-06 18:13:00 <@adamwill:fedora.im> it is here
2026-04-06 18:13:04 <@ahmedalmeleh:matrix.org> im from England 
2026-04-06 18:13:21 <@adamwill:fedora.im> anyhoooos
2026-04-06 18:13:24 <@salimma:fedora.im> And now my comment looks weird after Adam edited 😅
2026-04-06 18:13:30 <@adamwill:fedora.im> it still works :D
2026-04-06 18:13:59 <@adamwill:fedora.im> anyhoos, on the mesa bug: not getting too far. the latest interesting thing is that nobody seems to have outright confirmed it on f44 yet
2026-04-06 18:14:27 <@adamwill:fedora.im> i might send out a call for testing for this one (though it's a bit awkward as you do need to run an install on hardware)
2026-04-06 18:14:41 <@ahmedalmeleh:matrix.org> nvidia we have come a long way, i see so no vms 
2026-04-06 18:16:48 <@adamwill:fedora.im> yeah, unfortunately
2026-04-06 18:18:51 <@adamwill:fedora.im> !info still waiting for more info / debugging on this, but we have at least one report from someone affected on f43 who was not affected on f44, which is good
2026-04-06 18:19:00 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2448365
2026-04-06 18:19:00 <@adamwill:fedora.im> !info Accepted Blocker, uboot-tools, ASSIGNED
2026-04-06 18:19:00 <@adamwill:fedora.im> !topic (2448365) rpi4 fails to boot from usb drive after upgrade to RC3
2026-04-06 18:19:00 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2079
2026-04-06 18:19:24 <@supakeen:fedora.im> !hi
2026-04-06 18:19:25 <@zodbot:fedora.im> Simon de Vlieger (supakeen) - he / him / his
2026-04-06 18:19:35 <@supakeen:fedora.im> Paul and I both confirmed the above bug; Peter is looking into it.
2026-04-06 18:19:55 <@supakeen:fedora.im> (on rc5)
2026-04-06 18:20:40 <@adamwill:fedora.im> thanks
2026-04-06 18:22:14 <@adamwill:fedora.im> !info this bug is solidly confirmed, we are waiting on peter with the fix
2026-04-06 18:22:22 <@adamwill:fedora.im> !topic Open floor
2026-04-06 18:22:26 <@adamwill:fedora.im> that's all I got, folks - anything else?
2026-04-06 18:23:04 <@derekenz:fedora.im> Nothing here
2026-04-06 18:23:17 <@nielsenb:fedora.im> Not from me
2026-04-06 18:23:58 <@ahmedalmeleh:matrix.org> Nope but I remember helping qa in 2021
2026-04-06 18:24:11 <@ahmedalmeleh:matrix.org> Good to be back
2026-04-06 18:24:21 <@adamwill:fedora.im> thanks for coming out
2026-04-06 18:25:19 <@adamwill:fedora.im> ...and same to everyone
2026-04-06 18:25:26 <@adamwill:fedora.im> see you on thursday for go/no-go (probably)
2026-04-06 18:25:27 <@adamwill:fedora.im> !endmeeting