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