2026-03-16 16:01:48 <@adamwill:fedora.im> !startmeeting F44-blocker-review
2026-03-16 16:01:49 <@meetbot:fedora.im> Meeting started at 2026-03-16 16:01:48 UTC
2026-03-16 16:01:49 <@meetbot:fedora.im> The Meeting name is 'F44-blocker-review'
2026-03-16 16:01:52 <@adamwill:fedora.im> !topic Roll Call
2026-03-16 16:01:58 <@adamwill:fedora.im> hi hi folks, who's around for blocker fun?
2026-03-16 16:02:13 <@nielsenb:fedora.im> !hi
2026-03-16 16:02:13 <@zodbot:fedora.im> Brandon Nielsen (nielsenb)
2026-03-16 16:02:20 <@jgroman:fedora.im> !hi
2026-03-16 16:02:23 <@psklenar:fedora.im> !hi
2026-03-16 16:02:24 <@derekenz:fedora.im> !hi
2026-03-16 16:02:25 <@zodbot:fedora.im> Jaroslav Groman (jgroman)
2026-03-16 16:02:28 <@zodbot:fedora.im> Petr Sklenar (psklenar)
2026-03-16 16:02:28 <@zodbot:fedora.im> Derek Enz (derekenz)
2026-03-16 16:02:38 <@osama-albahrani:matrix.org> !hi
2026-03-16 16:02:41 <@zodbot:fedora.im> Osama Albahrani (osalbahr)
2026-03-16 16:02:58 <@nhanlon:beeper.com> !hi
2026-03-16 16:03:00 <@zodbot:fedora.im> Neil Hanlon (neil) - he / him / his
2026-03-16 16:03:02 <@kparal:matrix.org> !hi
2026-03-16 16:03:07 <@zodbot:fedora.im> Kamil Páral (kparal) - he / him / his
2026-03-16 16:04:00 <@lruzicka:fedora.im> "hi
2026-03-16 16:04:03 <@lruzicka:fedora.im> !hi
2026-03-16 16:04:04 <@zodbot:fedora.im> Lukáš Růžička (lruzicka)
2026-03-16 16:04:08 <@conan_kudo:matrix.org> !hi
2026-03-16 16:04:16 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2026-03-16 16:05:08 <@decathorpe:fedora.im> !hi
2026-03-16 16:05:09 <@zodbot:fedora.im> Fabio Valentini (decathorpe) - he / him / his
2026-03-16 16:05:24 <@sgallagh:fedora.im> !hi
2026-03-16 16:05:27 <@zodbot:fedora.im> Stephen Gallagher (sgallagh) - he / him / his
2026-03-16 16:05:48 <@ngompa:fedora.im> !hi
2026-03-16 16:05:49 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2026-03-16 16:06:50 <@adamwill:fedora.im> hi hi hi
2026-03-16 16:06:59 <@adamwill:fedora.im> let's do everyone's favorite thing, boilerplate
2026-03-16 16:07:04 <@adamwill:fedora.im> !info We'll be following the process outlined at:
2026-03-16 16:07:04 <@adamwill:fedora.im> Why are we here?
2026-03-16 16:07:04 <@adamwill:fedora.im> !info The bugs up for review today are available at:
2026-03-16 16:07:04 <@adamwill:fedora.im> !topic Introduction
2026-03-16 16:07:04 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria
2026-03-16 16:07:04 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
2026-03-16 16:07:04 <@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-03-16 16:07:04 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Fedora_44_Beta_Release_Criteria
2026-03-16 16:07:04 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Basic_Release_Criteria
2026-03-16 16:07:04 <@adamwill:fedora.im> !info The criteria for release blocking bugs can be found at:
2026-03-16 16:07:04 <@adamwill:fedora.im> !link http://qa.fedoraproject.org/blockerbugs/current
2026-03-16 16:07:18 <@adamwill:fedora.im> !info for Final, we have:
2026-03-16 16:07:19 <@adamwill:fedora.im> !info 4 Accepted Blockers
2026-03-16 16:07:19 <@adamwill:fedora.im> !info 3 Proposed Blockers
2026-03-16 16:07:22 <@supakeen:fedora.im> !hi
2026-03-16 16:07:23 <@zodbot:fedora.im> Simon de Vlieger (supakeen) - he / him / his
2026-03-16 16:07:24 <@adamwill:fedora.im> !info 3 Accepted Freeze Exceptions
2026-03-16 16:07:24 <@adamwill:fedora.im> !info 1 Proposed Freeze Exceptions
2026-03-16 16:07:31 <@adamwill:fedora.im> who wants to secretarialize?
2026-03-16 16:07:36 <@lruzicka:fedora.im> I will do it
2026-03-16 16:07:43 <@zodbot:fedora.im> neil gave a cookie to lruzicka. They now have 44 cookies, 7 of which were obtained in the Fedora 43 release cycle
2026-03-16 16:08:22 <@adamwill:fedora.im> thanks lukas
2026-03-16 16:08:23 <@zodbot:fedora.im> supakeen gave a cookie to lruzicka. They now have 45 cookies, 8 of which were obtained in the Fedora 43 release cycle
2026-03-16 16:08:28 <@adamwill:fedora.im> !info Lukáš Růžička will secretarialize
2026-03-16 16:08:28 <@lruzicka:fedora.im> no problem
2026-03-16 16:08:38 <@adamwill:fedora.im> let's get started with:
2026-03-16 16:08:42 <@adamwill:fedora.im> !topic proposed Final blockers
2026-03-16 16:08:48 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2444824
2026-03-16 16:08:48 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+1,0,-1) (+asciiwolf, -nielsenb)
2026-03-16 16:08:48 <@adamwill:fedora.im> !info Proposed Blocker, pipewire, POST
2026-03-16 16:08:48 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2071
2026-03-16 16:08:48 <@adamwill:fedora.im> !topic (2444824) GNOME Remote Desktop (RDP remote login) connects but shows a blank white screen and disconnects shortly afterwards (Fedora 44).
2026-03-16 16:09:00 <@adamwill:fedora.im> so i have been digging into this a lot with upstream and we found...at least three bugs so far?
2026-03-16 16:09:18 <@adamwill:fedora.im> one in particular in pipewire seems to cause *most* of the failures, though.
2026-03-16 16:10:39 <@adamwill:fedora.im> i don't really have enough data to know how bad it is for the RDP case, i focused on the remote desktop case as it's a faster test cycle
2026-03-16 16:11:53 <@nielsenb:fedora.im> So is this a failure of using F44 as a RDP host only, or is it also an issue with using Workstation's built in client to connect to non-Fedora hosts?
2026-03-16 16:12:24 <@adamwill:fedora.im> ah, hmm, good point, the pipewire issue I *believe* is on the host end
2026-03-16 16:12:48 <@lruzicka:fedora.im> I have not tested anything else than two Fedora systems: host and client, both F44
2026-03-16 16:13:04 <@adamwill:fedora.im> but...that's how you're meant to use RDP installs, at least
2026-03-16 16:13:10 <@adamwill:fedora.im> the system being installed on is the server
2026-03-16 16:13:50 <@adamwill:fedora.im> i think this is worth an FE for the remote desktop case at least; i'd say we're a bit short on info for blocker
2026-03-16 16:14:05 <@kparal:matrix.org> the issue is that our criteria block on anaconda installation, but not on client
2026-03-16 16:14:13 <@kparal:matrix.org> so if it works with a different client, it's OK
2026-03-16 16:15:42 <@nielsenb:fedora.im> I agree that a FE feels warranted if nothing else
2026-03-16 16:16:08 <@osama-albahrani:matrix.org> FE as in Final Exception?
2026-03-16 16:16:17 <@supakeen:fedora.im> Freeze Exception
2026-03-16 16:16:18 <@derekenz:fedora.im> Agree
2026-03-16 16:16:31 <@supakeen:fedora.im> It means an update is allowed to land during the freeze period (in this case, the final freeze period) if it resolves the bug.
2026-03-16 16:16:53 <@adamwill:fedora.im> i think i'd say +1 FE, punt again on blocker, and hopefully we'll get a pipewire update in and we can say it's good enough by next week
2026-03-16 16:17:09 <@adamwill:fedora.im> i can try and find time to do some 'test cannon' runs on the RDP install scenario
2026-03-16 16:17:18 <@osama-albahrani:matrix.org> The linked pipewire issue has been closed https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/5162
2026-03-16 16:17:19 <@psklenar:fedora.im> about remote desktop, I tried two f44 where I enabled desktop sharing at both which works for me, but when I stop client I could see different issue with gnome-connections: https://gitlab.gnome.org/GNOME/gnome-connections/-/issues/203
2026-03-16 16:17:21 <@supakeen:fedora.im> +1 FE, punt for blocker; there's still a bunch of stuff ongoing in the upstream issues. Let's see how clear it is next week.
2026-03-16 16:17:45 <@adamwill:fedora.im> yes, but we need it downstream. i did a build for rawhide but not f44 yet, was waiting for package manager
2026-03-16 16:17:51 <@adamwill:fedora.im> he says there will likely be a new release soon
2026-03-16 16:19:07 <@osama-albahrani:matrix.org> FE +1
2026-03-16 16:19:18 <@nielsenb:fedora.im> FinalFE +1
2026-03-16 16:19:47 <@jgroman:fedora.im> FE +1
2026-03-16 16:19:52 <@psklenar:fedora.im> FE +1
2026-03-16 16:19:53 <@derekenz:fedora.im> FinalFE +1
2026-03-16 16:20:05 <@kparal:matrix.org> adamw: how often does the bug happen, do you have an idea?
2026-03-16 16:20:20 <@adamwill:fedora.im> the pipewire one seems to be > 50% of the time *for remote desktop*
2026-03-16 16:20:26 <@kparal:matrix.org> if frequent enough, we can just test anaconda + freerdp, if it works, it's not a blocker
2026-03-16 16:20:26 <@adamwill:fedora.im> rdp installs definitely don't seem to have issues as often
2026-03-16 16:20:45 <@kparal:matrix.org> ☹️
2026-03-16 16:21:06 <@adamwill:fedora.im> only 2 failures on x86_64 actually...https://openqa.fedoraproject.org/tests/4442769#next_previous
2026-03-16 16:21:13 <@osama-albahrani:matrix.org> love me a [heisenbug](https://en.wikipedia.org/wiki/Heisenbug)
2026-03-16 16:21:18 <@ngompa:fedora.im> do we have screensharing criteria? because this looks like it would affect that
2026-03-16 16:21:18 <@adamwill:fedora.im> and 1 on aarch64
2026-03-16 16:21:45 <@lruzicka:fedora.im> I don't think we have (from the top of my mind)
2026-03-16 16:21:52 <@adamwill:fedora.im> meanwhile remote desktop looks like https://openqa.fedoraproject.org/tests/4439128#next_previous
2026-03-16 16:22:04 <@adamwill:fedora.im> no, we don't iirc, we added this test case at desktop team's request, not as a criteria thing
2026-03-16 16:22:23 <@ngompa:fedora.im> I see... I think this is something I'll bring up on the test@ list too
2026-03-16 16:22:31 <@kparal:matrix.org> no
2026-03-16 16:22:34 <@osama-albahrani:matrix.org> 4 out of 10 is oof
2026-03-16 16:22:53 <@osama-albahrani:matrix.org> it looks worse if I display 25
2026-03-16 16:22:57 <@ngompa:fedora.im> we definitely want to add criteria for this because it's a weird gap given... well, all of us rely on it 😓
2026-03-16 16:23:01 <@ngompa:fedora.im> we definitely want to add criteria for this because it's a weird gap given... well, all of us rely on it 😅
2026-03-16 16:23:07 <@adamwill:fedora.im> we do? i never use it. :D
2026-03-16 16:23:28 <@adamwill:fedora.im> oh, screen sharing as in meetings?
2026-03-16 16:23:31 <@ngompa:fedora.im> yes
2026-03-16 16:23:34 <@ngompa:fedora.im> it's the same codepath
2026-03-16 16:23:37 <@adamwill:fedora.im> i haven't actually seen this affect that
2026-03-16 16:23:50 <@adamwill:fedora.im> i think there's more session sync stuff going on with remote desktop (at least the way we're testing it)
2026-03-16 16:23:56 <@ngompa:fedora.im> the main difference is mutter spawning a virtual screen vs attaching a real one
2026-03-16 16:23:59 <@adamwill:fedora.im> we test remoting into a system that's at GDM then logging on
2026-03-16 16:24:00 <@lruzicka:fedora.im> This is not screen sharing, though. This is remote connection, afaik.
2026-03-16 16:24:21 <@ngompa:fedora.im> from the pipewire side, there isn't _that_ much different, but yes there are other bits that are different
2026-03-16 16:24:29 <@adamwill:fedora.im> anyway
2026-03-16 16:24:37 <@adamwill:fedora.im> do we wanna -1 blocker or punt?
2026-03-16 16:24:54 <@derekenz:fedora.im> Hmmm
2026-03-16 16:24:55 <@nielsenb:fedora.im> I think a punt is probably more appropriate
2026-03-16 16:25:14 <@adamwill:fedora.im> looking at the data i maybe feel more -1y
2026-03-16 16:25:15 <@nielsenb:fedora.im> If we were right up against it, I would -1 blocker
2026-03-16 16:25:17 <@adamwill:fedora.im> just because there's so few failures
2026-03-16 16:25:21 <@adamwill:fedora.im> (on the blocker case)
2026-03-16 16:25:38 <@adamwill:fedora.im> at last week's meeting i was interested to see how this week went, but it looks like it's basically all passes, the failures are rare
2026-03-16 16:25:40 <@lruzicka:fedora.im> We do not have a criterion for this specifically, so I could live with -1 and if this also appears in installations, then we will have a reason to block
2026-03-16 16:25:49 <@adamwill:fedora.im> we have a criterion for RDP installs. that's the blocking case
2026-03-16 16:26:02 <@lruzicka:fedora.im> But, they do not fail that much, do they?
2026-03-16 16:26:09 <@ngompa:fedora.im> I'm leaning more toward +1 because it affects rdp installs
2026-03-16 16:26:09 <@adamwill:fedora.im> i wonder if installs are hitting one of the rarer cases i still see in my shotgun tests after the pipewire fix, that might explain it
2026-03-16 16:26:24 <@kparal:matrix.org> the issue with race conditions is that you never know how often they happen for people. Some users might be blocked by anaconda never starting via rdp.
2026-03-16 16:26:39 <@adamwill:fedora.im> well, i guess we can punt since people are leaning different ways, and i can try to do some shotgun tests
2026-03-16 16:26:58 <@kparal:matrix.org> I guess -1 is OK at this point, or punt.
2026-03-16 16:27:01 <@adamwill:fedora.im> i wonder if installs are hitting one of the rarer cases i still see in my shotgun tests after the pipewire fix, rather than hitting the pipewire thing, that might explain it
2026-03-16 16:27:13 <@osama-albahrani:matrix.org> punt is a good idea
2026-03-16 16:27:51 <@derekenz:fedora.im> Agree Adam, Punt
2026-03-16 16:28:01 <@kparal:matrix.org> if the current pipewire fix doesn't help, could you run openqa cannon with freerdp, Adam?
2026-03-16 16:28:30 <@kparal:matrix.org> so that we have better idea whether a different client fixes the issue
2026-03-16 16:28:33 <@adamwill:fedora.im> proposed !agreed 2444824 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - this is accepted as a freeze exception issue as the GNOME remote desktop case is definitely heavily broken and we want that fixed for release if possible. Blocker status decision is delayed as the blocker case (RDP install) seems to fail much less often, but we want to investigate more thoroughly before deciding
2026-03-16 16:28:38 <@lruzicka:fedora.im> ack
2026-03-16 16:28:42 <@adamwill:fedora.im> it should be possible, i'll see
2026-03-16 16:28:43 <@derekenz:fedora.im> ack
2026-03-16 16:28:47 <@jgroman:fedora.im> ack
2026-03-16 16:28:57 <@nielsenb:fedora.im> ack
2026-03-16 16:29:15 <@supakeen:fedora.im> ack
2026-03-16 16:29:16 <@adamwill:fedora.im> !agreed 2444824 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - this is accepted as a freeze exception issue as the GNOME remote desktop case is definitely heavily broken and we want that fixed for release if possible. Blocker status decision is delayed as the blocker case (RDP install) seems to fail much less often, but we want to investigate more thoroughly before deciding
2026-03-16 16:29:26 <@adamwill:fedora.im> !topic (2444046) Incorrect KDE application launcher icon when user configures dark mode during initial setup
2026-03-16 16:29:26 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2444046
2026-03-16 16:29:26 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2076
2026-03-16 16:29:26 <@adamwill:fedora.im> !info Proposed Blocker, plasma-setup, NEW
2026-03-16 16:29:26 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+4,0,-2) (+derekenz, +asciiwolf, +nielsenb, +psklenar, -kparal, -adamwill)
2026-03-16 16:29:44 <@adamwill:fedora.im> so this had an early surge of support but then me and kparal showed up to spoil the party :P
2026-03-16 16:30:00 <@adamwill:fedora.im> i don't think we really have a criterion for this and it just doesn't feel really blocker-y
2026-03-16 16:30:47 <@nielsenb:fedora.im> "If doing a graphical install, check obvious places where release artwork and identification may be found, e.g. the About pane in GNOME Settings."
2026-03-16 16:30:47 <@lruzicka:fedora.im> I would say that if the launcher works, then it does not feel blockery to me
2026-03-16 16:30:54 <@sgallagh:fedora.im> I'd give this an FE, but definitely not a blocker.
2026-03-16 16:30:54 <@sgallagh:fedora.im> +1 FE, -1 FB
2026-03-16 16:31:02 <@derekenz:fedora.im> https://fedoraproject.org/wiki/QA:Testcase_base_artwork_release_identification
2026-03-16 16:31:04 <@nielsenb:fedora.im> From the test case cited in the criteria
2026-03-16 16:31:22 <@adamwill:fedora.im> that's about *release* identification
2026-03-16 16:31:25 <@adamwill:fedora.im> not *product* identification
2026-03-16 16:31:45 <@nielsenb:fedora.im> But, what is "release artwork" in GNOME Settings if not the Fedora logo...?
2026-03-16 16:31:48 <@ngompa:fedora.im> but it is release artwork 😅
2026-03-16 16:31:53 <@ngompa:fedora.im> that's why I proposed it as a blocker
2026-03-16 16:31:54 <@adamwill:fedora.im> the background.
2026-03-16 16:32:06 <@adamwill:fedora.im> (also this is a KDE bug not GNOME)
2026-03-16 16:32:12 <@ngompa:fedora.im> otherwise I don't know how our branding gets captured in criteria
2026-03-16 16:32:17 <@nielsenb:fedora.im> I know, but Gnome is the example
2026-03-16 16:32:29 <@adamwill:fedora.im> that's even what the criterion says: "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops"
2026-03-16 16:32:59 <@ngompa:fedora.im> I guess this is something where we need updated criteria too
2026-03-16 16:33:06 <@adamwill:fedora.im> branding is only weakly captured in the criteria, actually. i'd say this is sort of intentional because it's not...really...disastrous if we don't have a fedora logo on the button.
2026-03-16 16:33:11 <@ngompa:fedora.im> because fedora logos missing where they should be present is significant
2026-03-16 16:33:13 <@nielsenb:fedora.im> If artwork is only the background, the term artwork shouldn't be used
2026-03-16 16:33:15 <@adamwill:fedora.im> (or the GDM fedora logo is missing or whaetver)
2026-03-16 16:33:29 <@adamwill:fedora.im> i mean, significant, sure. block the release? ehhh.,
2026-03-16 16:33:54 <@sgallagh:fedora.im> I think it's a judgment call: if it was ALL branding, definitely a blocker.
2026-03-16 16:34:00 <@adamwill:fedora.im> there used to be more release-specific 'artwork' i think, when we wrote the criterion. i'm not sure if there's more besides the background now
2026-03-16 16:34:04 <@nielsenb:fedora.im> And I agree personally it isn't significant to me, but the criteria as I interpreted it is pretty clear, but apparently not
2026-03-16 16:34:10 <@sgallagh:fedora.im> One or two places gets missed by accident? Fix it in an update.
2026-03-16 16:34:27 <@ngompa:fedora.im> tbh, if it wasn't a toggle that users could just do during firstboot, I'd be more onboard with downgrading it
2026-03-16 16:34:37 <@ngompa:fedora.im> because an update can't fix it
2026-03-16 16:34:44 <@sgallagh:fedora.im> I mean, if we were accidentally branding as RHEL or something, that would be an issue too, I suppose.
2026-03-16 16:34:59 <@derekenz:fedora.im> Yeah its easy to switch on during initial setup
2026-03-16 16:35:19 <@kparal:matrix.org> people argued that we were blocking on bugs in little apps like calendar or contacts, saying that they are not significant enough. And now they want to block on button having a different icon.
2026-03-16 16:35:38 <@kparal:matrix.org> the button is OK in a default state, moreover
2026-03-16 16:35:43 <@nielsenb:fedora.im> I only want to block because, as far as I'm concerned, the criteria is very clear
2026-03-16 16:35:48 <@supakeen:fedora.im> The most important button :)
2026-03-16 16:35:54 <@ngompa:fedora.im> it's a mandatory flow app with a toggle that users are directly able to select
2026-03-16 16:35:58 <@nielsenb:fedora.im> But if we want to say "artwork" is only the background, then fine
2026-03-16 16:36:01 <@kparal:matrix.org> there's a very niche use case where it loses the branding
2026-03-16 16:36:30 <@nielsenb:fedora.im> A "very nice case" exposed as a toggle during initial setup, on a page where it's the only toggle
2026-03-16 16:36:31 <@lruzicka:fedora.im> How difficult is it to fix?
2026-03-16 16:36:38 <@derekenz:fedora.im> Yeah guess I miss understood
2026-03-16 16:36:39 <@kparal:matrix.org> Brandon Nielsen: The criteria **is** very clear: https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Artwork
2026-03-16 16:36:40 <@nielsenb:fedora.im> A "very niche case" exposed as a toggle during initial setup, on a page where it's the only toggle
2026-03-16 16:36:54 <@sgallagh:fedora.im> It's been a while. Do I get to play the "Would we block on this at Go/No-Go?" card?
2026-03-16 16:36:57 <@derekenz:fedora.im> Yeah guess I mis understood
2026-03-16 16:37:16 <@kparal:matrix.org> well actually the second sentence spoils the clarify 🙂 
2026-03-16 16:37:17 <@nielsenb:fedora.im> "The proposed final Fedora artwork must be included and"
2026-03-16 16:37:21 <@kparal:matrix.org> well actually the second sentence spoils the clarity 🙂 
2026-03-16 16:37:22 <@ngompa:fedora.im> I don't know yet, I think we need to do some upstream poking on it to figure it out.
2026-03-16 16:37:31 <@nielsenb:fedora.im> background is after an "and", which opens it to interpretation
2026-03-16 16:37:50 <@adamwill:fedora.im> the thing is, that criterion is specifically about the dynamic artwork that changes from release to release
2026-03-16 16:37:53 <@ngompa:fedora.im> I would hope it's not complicated to fix, but I don't even know why it doesn't get set.
2026-03-16 16:37:54 <@adamwill:fedora.im> it's not about constant things like the fedora logo
2026-03-16 16:38:12 <@adamwill:fedora.im> that's why these criteria and test cases all say "release" artwork
2026-03-16 16:38:19 <@adamwill:fedora.im> not "fedora" artwork or whatever
2026-03-16 16:38:44 <@sgallagh:fedora.im> If we want criteria specific to this, it would be "branding" artwork, no?
2026-03-16 16:38:54 <@adamwill:fedora.im> we kinda assume that all our eternal logos and stuff are there. the criterion was written when we had a lot of trouble with the dynamic stuff not showing up in time or us not changing all the 50 things you used to need to change to get it to show up on every desktop
2026-03-16 16:39:00 <@adamwill:fedora.im> yes, something like that
2026-03-16 16:39:16 <@nielsenb:fedora.im> I think the criteria should be updated with that distinction if that's really how we want it interpreted.
2026-03-16 16:39:33 <@ngompa:fedora.im> and if we do that, we do need branding criteria too
2026-03-16 16:39:37 <@adamwill:fedora.im> we can clarify it more. we could probably just make it specific to backgrounds now, but i'd have to check with design team if i'm missing anything
2026-03-16 16:39:38 <@supakeen:fedora.im> Ok well; then based on all the above I'm -1 blocker and +1 finalfe even though it *is* weird.
2026-03-16 16:39:48 <@supakeen:fedora.im> Ok well; then based on all the above I'm -1 blocker and +1 finalfe even though it _is_ weird and we definitely should probably have some branding crits.
2026-03-16 16:39:48 <@adamwill:fedora.im> -1 blocker / +1 FE, still
2026-03-16 16:40:04 <@adamwill:fedora.im> i'm fine if someone wants to propose branding criteria but honestly i would not want to block on this anyway, it's too minor
2026-03-16 16:40:06 <@lruzicka:fedora.im> -1 blocker, +1 fe
2026-03-16 16:40:13 <@adamwill:fedora.im> it doesn't pass the 'last blocker at go/no-go' smell test
2026-03-16 16:40:20 <@ngompa:fedora.im> +1 FB / +1 FE because it's exposed to users by default
2026-03-16 16:40:31 <@derekenz:fedora.im> FinalBlocker 0
2026-03-16 16:40:40 <@derekenz:fedora.im> FE +1
2026-03-16 16:40:42 <@nielsenb:fedora.im> I agree it doesn't pass the go/no-go test for me
2026-03-16 16:40:49 <@nielsenb:fedora.im> FinalFE +1
2026-03-16 16:40:50 <@lruzicka:fedora.im> Could be also explained in common bugs if we feel like people should know about it.
2026-03-16 16:41:05 <@lruzicka:fedora.im> If it is not fixed by the release date.
2026-03-16 16:41:21 <@sgallagh:fedora.im> -1 FB / +1 FE (as above)
2026-03-16 16:41:40 <@kparal:matrix.org> I think that nobody will care, honestly
2026-03-16 16:41:42 <@adamwill:fedora.im> Petr Sklenar sorry, are you around? did you want to keep your +1 ?
2026-03-16 16:41:51 <@kparal:matrix.org> even from those "affected users"
2026-03-16 16:42:00 <@kparal:matrix.org> except Neal, of course, but he knows the workaround already
2026-03-16 16:42:01 <@jgroman:fedora.im> -1 FB / +1 FE from me as well
2026-03-16 16:42:11 <@adamwill:fedora.im> i think we're at +2 / -5 but it's a bit of a flood
2026-03-16 16:42:17 <@nielsenb:fedora.im> Then why have the criteria...
2026-03-16 16:42:29 <@adamwill:fedora.im> people care a lot about backgrounds. oh god do they care
2026-03-16 16:42:34 <@adamwill:fedora.im> kicker icons...not so sure
2026-03-16 16:42:43 <@adamwill:fedora.im> (hence the criteria we have now)
2026-03-16 16:43:06 <@adamwill:fedora.im> i mean, i expect some people will notice, but i don't think it'd cause a disaster if we released this way
2026-03-16 16:43:34 <@adamwill:fedora.im> well, we easily have votes for +1
2026-03-16 16:43:47 <@adamwill:fedora.im> well, we easily have votes for +1 FE
2026-03-16 16:43:51 <@adamwill:fedora.im> well, we easily have votes for FE
2026-03-16 16:43:52 <@lruzicka:fedora.im> If Neal Gompa (Fedora) or Brandon Nielsen want a criterion, feel free to propose one. I just beg you to be quite specific in what you want to check, because otherwise it will be a nightmare to look for.
2026-03-16 16:43:54 <@adamwill:fedora.im> conan is worried because he doesn't actually know why it's broken or how to fix it yet
2026-03-16 16:44:44 <@kashyapc:fedora.im> (Reading up, FWIW, I agree that it feels unreasonable to have it as a "final blocker".  I'm also a non-KDE user, I have to admit)
2026-03-16 16:45:10 <@lruzicka:fedora.im> Jaroslav Groman: is a KDE user. How do you see that?
2026-03-16 16:45:14 <@ngompa:fedora.im> yeah if I knew I'd have fixed it by now :D
2026-03-16 16:45:19 <@adamwill:fedora.im> well, for GNOME i'm imagining how i'd feel if we lost the 'fedora' overlay on the background, or the fedora logo on GDM, and it also makes me feel 'meh'
2026-03-16 16:45:28 <@adamwill:fedora.im> (especially if only when you make a non-default choice during initial setup)
2026-03-16 16:45:37 <@nielsenb:fedora.im> I feel like the test case is already very specific, but based on the apparently common interpretation, it's not, so already a bit of a nightmare...
2026-03-16 16:45:55 <@nielsenb:fedora.im> Agreed
2026-03-16 16:46:00 <@ngompa:fedora.im> I would also be in the boat of "we should fix this for final release presentation"
2026-03-16 16:46:36 <@adamwill:fedora.im> i think we *did* have a proposed blocker for one of those before actually, and i don't remember how we voted. but i think that was broken in all cases, not just dark mode
2026-03-16 16:46:38 <@ngompa:fedora.im> and that one is in the case that it's default and hard to fix post-install
2026-03-16 16:46:51 <@jgroman:fedora.im> Lukáš Růžička: Umm, in fact this exact thing happened on my atomic spin some time ago and I just ignored it.
2026-03-16 16:48:04 <@adamwill:fedora.im> i suppose i should also mention on this topic that occasionally the desktop_login test fails on KDE because, after several logins / logouts / reboots, we see the wrong kicker logo. :P i have never had time to look into it in detail though (whether it's always at the same point that it goes wrong, or anything like that). it's just on my list of weird blips
2026-03-16 16:48:11 <@sgallagh:fedora.im> adamw: I remember that one, and we actually did rule it a blocker, but it *was* contentious and I think it had come down to the FPL caring deeply about it
2026-03-16 16:48:30 <@ngompa:fedora.im> (which is still the case btw)
2026-03-16 16:48:45 <@adamwill:fedora.im> any FPLs in the house? Jef Spaleta mattdm
2026-03-16 16:49:14 <@ngompa:fedora.im> fwiw, I'm _fine_ with accepting it as an FE if that's what everyone wants to go with
2026-03-16 16:49:34 <@ngompa:fedora.im> I just personally don't like branding breakages for our editions
2026-03-16 16:49:48 <@ngompa:fedora.im> especially when an update can't fix it for a user's system
2026-03-16 16:50:16 <@sgallagh:fedora.im> It can't fix the installer, but why couldn't it fix an installed system?
2026-03-16 16:50:24 <@adamwill:fedora.im> user configs are templated
2026-03-16 16:50:29 <@ngompa:fedora.im> yup
2026-03-16 16:50:34 <@ngompa:fedora.im> once the config is initialized, that's it
2026-03-16 16:50:37 <@adamwill:fedora.im> and we don't touch user configs on update by policy
2026-03-16 16:50:52 <@ngompa:fedora.im> there is no straightforward way to do in KDE Plasma by design, either
2026-03-16 16:50:54 <@derekenz:fedora.im> Agree
2026-03-16 16:51:11 <@sgallagh:fedora.im> OK, I didn't catch that earlier. It doesn't change my vote, but it's definitely less black-and-white than I thought.
2026-03-16 16:51:13 <@adamwill:fedora.im> Plasma 6.7 Change Proposal: Adopt Gsettings
2026-03-16 16:51:15 <@adamwill:fedora.im> *ducks*
2026-03-16 16:51:18 <@ngompa:fedora.im> oh god no
2026-03-16 16:51:34 <@ngompa:fedora.im> the dconf gsettings monstrosity is terrible in gnome
2026-03-16 16:52:20 <@adamwill:fedora.im> so, hum. we have the votes to reject this, but it's pretty tight, i usually prefer a clearer consensus. but if we punt it's not clear what we're punting *for*, except maybe a wider range of folks at go/no-go
2026-03-16 16:52:38 <@nielsenb:fedora.im> I'm *fine* with it going down in flames
2026-03-16 16:53:12 <@kashyapc:fedora.im> IMHO, it's not worth it to spend this much time chewing on this.
2026-03-16 16:53:12 <@nielsenb:fedora.im> Nobody reads my blog anyway, so the late night angry post will go unnoticed
2026-03-16 16:53:33 <@kashyapc:fedora.im> There's a clear workaround and it is a simple GUI "blemish"
2026-03-16 16:53:38 <@adamwill:fedora.im> ok, for the sake of simplicity let's reject it. we *can* always re-propose it if strong feelings emerge
2026-03-16 16:53:49 <@ngompa:fedora.im> we could accept it as an FE though?
2026-03-16 16:53:49 <@lruzicka:fedora.im> +1
2026-03-16 16:53:52 <@ngompa:fedora.im> that has the votes
2026-03-16 16:53:59 <@adamwill:fedora.im> oh yeah for sure, that's nailed on
2026-03-16 16:54:35 <@kparal:matrix.org> Neal Gompa (Fedora): the two votes are separate, we can reject a blocker and accept a freeze exception, yes
2026-03-16 16:55:58 <@adamwill:fedora.im> proposed !agreed 2444046 - RejectedBlocker (Final) AcceptedFreezeException (Final) - there are differing opinions on this, but we noted that the existing criteria were written for 'artwork' that changes per-release and were not meant to cover permanent branding issues. there's some support for adding branding criteria, but the narrow consensus was this is probably a minor enough issue that it shouldn't constitute a blocker even if we do write branding criteria. we're open to re-considering this if a broad swell of folks who weren't present at the meeting are concerned
2026-03-16 16:56:15 <@lruzicka:fedora.im> ack
2026-03-16 16:56:16 <@derekenz:fedora.im> ack
2026-03-16 16:56:17 <@jgroman:fedora.im> ack
2026-03-16 16:56:24 <@adamwill:fedora.im> proposed !agreed 2444046 - RejectedBlocker (Final) AcceptedFreezeException (Final) - there are differing opinions on this, but we noted that the existing criteria were written for 'artwork' that changes per-release and were not meant to cover permanent branding issues. there's some support for adding branding criteria, but the narrow consensus was this is probably a minor enough issue that it shouldn't constitute a blocker even if we do write branding criteria. we're open to re-considering this if a broad swell of folks who weren't present at the meeting are concerned. It's accepted as an FE as a visible issue in a blocking desktop that can't be fully resolved with an update
2026-03-16 16:56:27 <@supakeen:fedora.im> ack
2026-03-16 16:56:28 <@adamwill:fedora.im> sorry, edited to add FE justification
2026-03-16 16:56:49 <@supakeen:fedora.im> s/fully// i guess but not enough for a nack :)
2026-03-16 16:57:00 <@adamwill:fedora.im> true
2026-03-16 16:57:06 <@adamwill:fedora.im> proposed !agreed 2444046 - RejectedBlocker (Final) AcceptedFreezeException (Final) - there are differing opinions on this, but we noted that the existing criteria were written for 'artwork' that changes per-release and were not meant to cover permanent branding issues. there's some support for adding branding criteria, but the narrow consensus was this is probably a minor enough issue that it shouldn't constitute a blocker even if we do write branding criteria. we're open to re-considering this if a broad swell of folks who weren't present at the meeting are concerned. It's accepted as an FE as a visible issue in a blocking desktop that can't be resolved with an update
2026-03-16 16:57:07 <@adamwill:fedora.im> edited
2026-03-16 16:57:09 <@nielsenb:fedora.im> ack
2026-03-16 16:57:15 <@kparal:matrix.org> ack
2026-03-16 16:57:36 <@ngompa:fedora.im> ack
2026-03-16 16:57:38 <@kashyapc:fedora.im> Ack
2026-03-16 16:58:09 <@kparal:matrix.org> it can be resolved that an updated system will display it correctly
2026-03-16 16:58:24 <@kparal:matrix.org> but not for a non-updated one
2026-03-16 16:58:35 <@adamwill:fedora.im> no
2026-03-16 16:58:37 <@ngompa:fedora.im> it is not possible to fix on update
2026-03-16 16:58:37 <@kparal:matrix.org> so it sounds fine to me
2026-03-16 16:58:46 <@ngompa:fedora.im> it is not possible to fix on update for installed systems
2026-03-16 16:58:48 <@adamwill:fedora.im> that's what we were talking about. if you install and hit this bug, you're stuck with it unless you manually correc the config
2026-03-16 16:59:09 <@adamwill:fedora.im> because your user config file was created with this incorrect setting in it at install time, and updates cannot fix that
2026-03-16 16:59:34 <@adamwill:fedora.im> an update could fix it so that any user accounts created *later* aren't affected, but the user account created at install time on a fresh install could only be fixed manually
2026-03-16 17:00:06 <@adamwill:fedora.im> Neal Gompa (Fedora) that definitely *is* the bug, right? user config file being written wrong?
2026-03-16 17:00:37 <@ngompa:fedora.im> basically, yes
2026-03-16 17:00:43 <@kparal:matrix.org> well it's all software, so possibly "it's too difficult to fix" rather than "can't be"
2026-03-16 17:00:50 <@ngompa:fedora.im> the configuration script for the look and feel that sets this doesn't fire
2026-03-16 17:01:02 <@ngompa:fedora.im> so it gets the internal one instead of the fedora one
2026-03-16 17:01:14 <@adamwill:fedora.im> Kamil Páral well, it's "by policy we cannot fix it as fedora packages are not allowed to touch user configuration files"
2026-03-16 17:01:30 <@adamwill:fedora.im> anyway...kashyap is right, let's move on
2026-03-16 17:01:35 <@adamwill:fedora.im> if you want this revoted just repropose it :D
2026-03-16 17:01:42 <@adamwill:fedora.im> !agreed 2444046 - RejectedBlocker (Final) AcceptedFreezeException (Final) - there are differing opinions on this, but we noted that the existing criteria were written for 'artwork' that changes per-release and were not meant to cover permanent branding issues. there's some support for adding branding criteria, but the narrow consensus was this is probably a minor enough issue that it shouldn't constitute a blocker even if we do write branding criteria. we're open to re-considering this if a broad swell of folks who weren't present at the meeting are concerned. It's accepted as an FE as a visible issue in a blocking desktop that can't be resolved with an update
2026-03-16 17:01:52 <@kparal:matrix.org> hmm, that surely isn't applied during migrations
2026-03-16 17:02:13 <@adamwill:fedora.im> the *upstream software* can touch user files of course
2026-03-16 17:02:17 <@adamwill:fedora.im> but *fedora packages* cannot
2026-03-16 17:02:34 <@adamwill:fedora.im> and i don't think we could convince plasma upstream to merge some code to fix a downstream bug in fedora branding by messing with user config files...
2026-03-16 17:02:38 <@supakeen:fedora.im> sneaky upstreams
2026-03-16 17:02:49 <@kparal:matrix.org> let's jump to the next one
2026-03-16 17:02:54 <@adamwill:fedora.im> !info Ticket vote: FinalFreezeException (+4,0,-0) (+asciiwolf, +nielsenb, +derekenz, +adamwill)
2026-03-16 17:02:54 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2391723
2026-03-16 17:02:54 <@adamwill:fedora.im> !topic (2391723) `shim-ia32` missing since `shim-15.8-4`
2026-03-16 17:02:54 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2075
2026-03-16 17:02:54 <@adamwill:fedora.im> !info Proposed Blocker, shim, NEW
2026-03-16 17:02:54 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +derekenz)
2026-03-16 17:03:00 <@supakeen:fedora.im> ok so this one is fun
2026-03-16 17:03:11 <@adamwill:fedora.im> it's essentially a subjective hardware support determination
2026-03-16 17:03:14 <@supakeen:fedora.im> it has been fixed in kiwi, lorax, and image-builder
2026-03-16 17:03:14 <@kashyapc:fedora.im> Yeah; I just read up on it ... it looks like an accidental mistake?
2026-03-16 17:03:27 <@ngompa:fedora.im> everything should be fixed by this point, no?
2026-03-16 17:03:29 <@adamwill:fedora.im> no, peter removed it intentionally because we figured nobody uses these weirdass systems any more
2026-03-16 17:03:37 <@adamwill:fedora.im> but then people who use these weirdass systems showed up and complained. :D
2026-03-16 17:03:56 <@ngompa:fedora.im> hey, I wrote code specifically to support these weird-ass systems in kiwi :D
2026-03-16 17:03:56 <@supakeen:fedora.im> so it gets funny there Neal Gompa (Fedora), there's a sidechat in the ticket about fedora bootc deliverables and disk images
2026-03-16 17:04:02 <@kashyapc:fedora.im> I see Hans de Goede replied saying there are users enough to use 32-bit UEFI on x86_64. 
2026-03-16 17:04:09 <@adamwill:fedora.im> the lorax update isn't stable yet
2026-03-16 17:04:14 <@adamwill:fedora.im> and there's some discussion about image builder at the bottom
2026-03-16 17:04:18 <@kparal:matrix.org> according to Hans, this affects quite a lot of hardware. And now that we don't have any blocking hardware list for IoT/ARM, the question is, whether we consider that hardware blocking or not
2026-03-16 17:04:18 <@supakeen:fedora.im> and the image-builder update is also not stable yet
2026-03-16 17:04:26 <@supakeen:fedora.im> (i updated it in the blockerbug discussion)
2026-03-16 17:04:29 <@adamwill:fedora.im> this isn't about arm
2026-03-16 17:04:32 <@adamwill:fedora.im> ot
2026-03-16 17:04:43 <@adamwill:fedora.im> it's about weird x86 systems which have x86_64 CPUs but 32-bit UEFI firmwares
2026-03-16 17:04:49 <@adamwill:fedora.im> like that wacky tablet i had years ago
2026-03-16 17:05:02 <@ngompa:fedora.im> and early Intel Macs and HP computers
2026-03-16 17:05:03 <@nielsenb:fedora.im> Some Apple hardware too I think
2026-03-16 17:05:11 <@supakeen:fedora.im> around 2010-2013 there were a lot of tablets, nuc's, intel macs, and other devices that run 32-bit EFI but a 64-bit CPU.
2026-03-16 17:05:13 <@supakeen:fedora.im> anyhow
2026-03-16 17:05:25 <@adamwill:fedora.im> i feel like 'a lot' is kinda overselling it. there were *some*
2026-03-16 17:05:28 <@supakeen:fedora.im> all relevant updates for *ISOs* will have landed before final freeze starts
2026-03-16 17:05:43 <@supakeen:fedora.im> and i don't think we ever supported this for disk images?
2026-03-16 17:05:48 <@ngompa:fedora.im> it's supported there
2026-03-16 17:05:59 <@ngompa:fedora.im> we just don't _normally_ make x86 disk images
2026-03-16 17:06:11 <@ngompa:fedora.im> but the kiwi definitions have it to support OEM Fedora preloads
2026-03-16 17:06:28 <@ngompa:fedora.im> and mass deploys :)
2026-03-16 17:06:31 <@supakeen:fedora.im> right, and image-builder doesn't produce *any* x86 disk images in the composes at the moment
2026-03-16 17:06:32 <@kashyapc:fedora.im> It's hard to say this is a "final blocker".  If I remind myself of Fedora's mission, it's not about supporting "wacky systems" indefinitely :D
2026-03-16 17:06:34 <@adamwill:fedora.im> well, for blocker we only care about release blocking images
2026-03-16 17:06:57 <@ngompa:fedora.im> so then just the ISO-based images
2026-03-16 17:07:02 <@ngompa:fedora.im> all the kiwi stuff should be good now
2026-03-16 17:07:10 <@ngompa:fedora.im> that leaves the install ISOs
2026-03-16 17:07:13 <@ngompa:fedora.im> and the atomic ISOs
2026-03-16 17:07:25 <@supakeen:fedora.im> both are produced with lorax for f44 which has a pending update for this
2026-03-16 17:07:38 <@supakeen:fedora.im> and for the iot ISO there's a pending update for image-builder
2026-03-16 17:07:41 <@adamwill:fedora.im> what is image builder building atm? I can never remember
2026-03-16 17:07:43 <@adamwill:fedora.im> iot. okay.
2026-03-16 17:08:14 <@ngompa:fedora.im> it pretty much is whatever contributors have and can use to do fedora things :)
2026-03-16 17:08:20 <@adamwill:fedora.im> when you say 'pending update', you mean package update? or update to the remote deployment? are we using the remote image builder setup still or are we using local in koji now?
2026-03-16 17:08:29 <@ngompa:fedora.im> we're in local koji ib now
2026-03-16 17:08:36 <@adamwill:fedora.im> it's https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues?
2026-03-16 17:08:39 <@ngompa:fedora.im> so a package update included in a compose is all that's need
2026-03-16 17:08:41 <@ngompa:fedora.im> so a package update included in a compose is all that's needed
2026-03-16 17:08:48 <@adamwill:fedora.im> ok, cool.
2026-03-16 17:08:56 <@supakeen:fedora.im> https://bodhi.fedoraproject.org/updates/FEDORA-2026-94622507b1 is the specific update
2026-03-16 17:09:13 <@adamwill:fedora.im> so basically we need https://bodhi.fedoraproject.org/updates/FEDORA-2026-94622507b1 and https://bodhi.fedoraproject.org/updates/FEDORA-2026-ea1a86a8eb ?
2026-03-16 17:09:24 <@adamwill:fedora.im> i'll edit both updates and mark them as associated with the bug
2026-03-16 17:09:27 <@supakeen:fedora.im> yep
2026-03-16 17:09:51 <@supakeen:fedora.im> since both would land before finalfreeze starts; what do we do in regards to voting?
2026-03-16 17:10:18 <@adamwill:fedora.im> we still vote, because they could get a -1
2026-03-16 17:10:27 <@adamwill:fedora.im> an update hasn't landed till it's *landed*
2026-03-16 17:10:31 <@supakeen:fedora.im> ack
2026-03-16 17:10:57 <@adamwill:fedora.im> i'm kinda 0 on this one, honestly. no strong opinion.
2026-03-16 17:11:07 <@kashyapc:fedora.im> "In general, exceptional or unusual cases are unlikely to be considered release blockers, even if the relevant release criterion is not carefully phrased to indicate this"
2026-03-16 17:11:11 <@adamwill:fedora.im> there is some hardware, yeah. is it enough to constitute a blocker under the FAQ entry? meh.
2026-03-16 17:11:40 <@ngompa:fedora.im> the difference here is that it prevents even booting the media
2026-03-16 17:11:47 <@ngompa:fedora.im> to me, that meets the bar
2026-03-16 17:11:56 <@adamwill:fedora.im> in this case i'd say factor 1 is 'there's some!', factor 2 is 'hard to workaround', factor 3 is 'we think we know how to fix it
2026-03-16 17:12:01 <@adamwill:fedora.im> in this case i'd say factor 1 is 'there's some!', factor 2 is 'hard to workaround', factor 3 is 'we think we know how to fix it'
2026-03-16 17:12:43 <@supakeen:fedora.im> +1 FinalFE, +1 FinalBlocker from me; we don't do respins and we'd ship ISOs unusable on a chunk of devices (we can argue the size of the chunk).
2026-03-16 17:13:13 <@adamwill:fedora.im> btw, i think we shipped f43 this way?
2026-03-16 17:13:25 <@supakeen:fedora.im> Only for the IoT ISO.
2026-03-16 17:13:28 <@ngompa:fedora.im> no, it was present in f43
2026-03-16 17:13:46 <@adamwill:fedora.im> ah, yeah, i see 15.8-3.
2026-03-16 17:13:58 <@supakeen:fedora.im> Which was an oversight, when Neal told me I fixed it and then shim-ia32 disappeared and the PR got closed and then I re-opened it again recently when I was reminded by the activity on the BZ :)
2026-03-16 17:14:17 <@adamwill:fedora.im> so we have +2 I think? simon  and neal? did I miss any votes?
2026-03-16 17:14:25 <@nielsenb:fedora.im> Can't fix this in post, and it ticks the factor 3 "we know how to fix it"
2026-03-16 17:14:29 <@adamwill:fedora.im> oh, and brandon and derek in the ticket
2026-03-16 17:14:30 <@adamwill:fedora.im> so +4
2026-03-16 17:14:31 <@nielsenb:fedora.im> FinalBlocker +1
2026-03-16 17:14:34 <@kashyapc:fedora.im> I didn't notice this bit. I have no idea the prevalent this use-case is. Since the work is already done, it looks easy to pull in.  I'm neutral here
2026-03-16 17:14:47 <@adamwill:fedora.im> i'm definitely +1 FE
2026-03-16 17:15:05 <@ngompa:fedora.im> +1 FB / +1 FE
2026-03-16 17:15:37 <@kparal:matrix.org> +1 FE from me
2026-03-16 17:15:45 <@kashyapc:fedora.im> Yeah, +1 FEh ere too; but  +0FB.
2026-03-16 17:15:55 <@kashyapc:fedora.im> Yeah, +1 FE here too; but  +0FB.
2026-03-16 17:16:52 <@adamwill:fedora.im> proposed !agreed 2391723 - AcceptedBlocker (Final) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" in the case of x86_64 systems with 32-bit UEFI firmwares. our subjective decision was that this is a significant enough class of systems to constitute a release blocking bug
2026-03-16 17:16:59 <@derekenz:fedora.im> ack
2026-03-16 17:17:03 <@adamwill:fedora.im> hmm, one thing i worry about is this sort of sets a precedent that if this gets broken in future we have to block on it
2026-03-16 17:17:04 <@jgroman:fedora.im> ack
2026-03-16 17:17:23 <@supakeen:fedora.im> adamw: or need re-evaluation at that point in time
2026-03-16 17:17:29 <@kashyapc:fedora.im> Yeah, the "precedent" thing is a good point!  Then later someone can get back with, "what about _that_ one!"
2026-03-16 17:17:44 <@kashyapc:fedora.im> Yeah, the "precedent" thing is a good point. Then later someone can get back with "what about _that_ one!"
2026-03-16 17:17:58 <@adamwill:fedora.im> let me do some acceptance text judo
2026-03-16 17:18:03 <@adamwill:fedora.im> this is highly advanced stuff kids, don't try it at home
2026-03-16 17:18:05 <@supakeen:fedora.im> (most of) these devices are from the 2010-2013 era; give it a few more years and we might consider them 'definitely past due'? idk
2026-03-16 17:18:39 <@kashyapc:fedora.im> It is all about "criteria vibes"
2026-03-16 17:19:12 <@adamwill:fedora.im> proposed !agreed 2391723 - AcceptedBlocker (Final) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" in the case of x86_64 systems with 32-bit UEFI firmwares. our subjective decision was that this is a significant enough class of systems to constitute a release blocking bug. Note we accept this only in the context of 'making an effort to support such systems', as the fix is relatively straightforward. We don't necessarily intend to establish a precedent that any kind of bug in this unusual path becomes a blocker; one that required more work by the developers may not reach the bar.
2026-03-16 17:19:22 <@adamwill:fedora.im> i've edited the text to try and forestall the precedent
2026-03-16 17:19:41 <@supakeen:fedora.im> ack thanks for that
2026-03-16 17:19:59 <@lruzicka:fedora.im> ack
2026-03-16 17:20:31 <@kparal:matrix.org> ack
2026-03-16 17:21:14 <@adamwill:fedora.im> !agreed 2391723 - AcceptedBlocker (Final) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" in the case of x86_64 systems with 32-bit UEFI firmwares. our subjective decision was that this is a significant enough class of systems to constitute a release blocking bug. Note we accept this only in the context of 'making an effort to support such systems', as the fix is relatively straightforward. We don't necessarily intend to establish a precedent that any kind of bug in this unusual path becomes a blocker; one that required more work by the developers may not reach the bar.
2026-03-16 17:21:22 <@adamwill:fedora.im> ok, that's all the proposed blockers
2026-03-16 17:21:25 <@adamwill:fedora.im> let's move on to:
2026-03-16 17:21:30 <@adamwill:fedora.im> !topic Proposed Final freeze exceptions
2026-03-16 17:21:36 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2064
2026-03-16 17:21:36 <@adamwill:fedora.im> !info Ticket vote: FinalFreezeException (+2,0,-0) (+asciiwolf, +nielsenb)
2026-03-16 17:21:36 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+2,0,-1) (+nielsenb, +derekenz, -kparal)
2026-03-16 17:21:36 <@adamwill:fedora.im> !info Proposed Freeze Exceptions, dnf5, POST
2026-03-16 17:21:36 <@adamwill:fedora.im> !topic (2443774) dnf cli segmentation faults during transaction when locale is set to C or POSIX
2026-03-16 17:21:36 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2443774
2026-03-16 17:22:14 <@kashyapc:fedora.im> This is good judo for sure! -  "Note we accept this only in the context of 'making an effort to support such systems', as the fix is relatively straightforward." 
2026-03-16 17:22:54 <@supakeen:fedora.im> So this DNF one is a pretty easy FE from me. It really shouldn't do that but it's also really easy to work around.
2026-03-16 17:22:57 <@adamwill:fedora.im> i guess i'm ok with an FE for a safe fix, since there's a catch-22 here ("my system can't update! how can I fix it?" "oh just install...this...upd-ah.")
2026-03-16 17:23:20 <@supakeen:fedora.im> `LANG=... dnf` ;)
2026-03-16 17:23:24 <@adamwill:fedora.im> true.
2026-03-16 17:23:24 <@kparal:matrix.org> +1 FE
2026-03-16 17:23:28 <@derekenz:fedora.im> FinalFE +1
2026-03-16 17:23:30 <@lruzicka:fedora.im> +1 FE
2026-03-16 17:23:34 <@adamwill:fedora.im> wouldn't want to pull in major dnf surgery close to release, though.
2026-03-16 17:24:21 <@adamwill:fedora.im> proposed !agreed 2443774 - AcceptedFreezeException (Final) - this is accepted as an FE issue as it could affect folks on first update and require a workaround, but we will evaluate any proposed fix during freeze for its risk of affecting more important paths and only take a sufficiently safe fix.
2026-03-16 17:24:37 <@lruzicka:fedora.im> ack
2026-03-16 17:24:44 <@jgroman:fedora.im> ack
2026-03-16 17:24:53 <@derekenz:fedora.im> ack
2026-03-16 17:24:59 <@nielsenb:fedora.im> ack
2026-03-16 17:25:27 <@adamwill:fedora.im> !agreed 2443774 - AcceptedFreezeException (Final) - this is accepted as an FE issue as it could affect folks on first update and require a workaround, but we will evaluate any proposed fix during freeze for its risk of affecting more important paths and only take a sufficiently safe fix.
2026-03-16 17:25:51 <@adamwill:fedora.im> ok, that's the only proposed FE, so let's do a quick review of:
2026-03-16 17:25:56 <@adamwill:fedora.im> !topic Accepted Final blocker review
2026-03-16 17:26:07 <@adamwill:fedora.im> !info remember, we are just checking in on status here, not re-voting unless it's necessary for some reason
2026-03-16 17:26:56 <@adamwill:fedora.im> !info three of the blockers are network installer image sizes. I did a quick investigation and didn't find any low-hanging fruit to target - https://bugzilla.redhat.com/show_bug.cgi?id=2431863#c9 . I will propose bumping the size limits soon
2026-03-16 17:27:43 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2359799
2026-03-16 17:27:43 <@adamwill:fedora.im> !info Accepted Blocker, mesa, NEW
2026-03-16 17:27:43 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/2074
2026-03-16 17:27:43 <@adamwill:fedora.im> !topic (2359799) Inital-setup: VK_ERROR_DEVICE_LOST using nvidia hardware
2026-03-16 17:27:59 <@adamwill:fedora.im> i don't think we've got anywhere with this. we need to try and get someone actually figuring out what's wrong and how to fix it
2026-03-16 17:28:50 <@ngompa:fedora.im> can we poke the nouveau folks at RH to look at it?
2026-03-16 17:31:29 <@ngompa:fedora.im> there are a small pile of things that I suspect have the same or similar origin
2026-03-16 17:31:36 <@ngompa:fedora.im> there are a small pile of bugs that I suspect have the same or similar origin
2026-03-16 17:32:36 <@adamwill:fedora.im> i can try
2026-03-16 17:32:53 <@adamwill:fedora.im> !info this awaiting further investigation, we need to find a developer who can look into it
2026-03-16 17:33:05 <@adamwill:fedora.im> !topic Open floor
2026-03-16 17:33:08 <@adamwill:fedora.im> any other business, folks?
2026-03-16 17:33:18 <@nielsenb:fedora.im> Not from me
2026-03-16 17:34:05 <@ngompa:fedora.im> nothing from me either
2026-03-16 17:34:16 <@derekenz:fedora.im> Nothing here
2026-03-16 17:34:30 <@jgroman:fedora.im> Nope
2026-03-16 17:34:34 <@lruzicka:fedora.im> Nussing from me
2026-03-16 17:34:43 <@adamwill:fedora.im> thanks for coming, folks
2026-03-16 17:34:55 <@adamwill:fedora.im> !endmeeting