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