<@adamwill:fedora.im>
16:02:10
!startmeeting F42-blocker-review
<@meetbot:fedora.im>
16:02:11
Meeting started at 2025-03-24 16:02:10 UTC
<@meetbot:fedora.im>
16:02:12
The Meeting name is 'F42-blocker-review'
<@derekenz:fedora.im>
16:02:13
sorry lol
<@adamwill:fedora.im>
16:02:14
i should edit the sop
<@adamwill:fedora.im>
16:02:17
!topic Roll Call
<@adamwill:fedora.im>
16:02:22
everyone say hi again!
<@boniboyblue:fedora.im>
16:02:29
!hi
<@zodbot:fedora.im>
16:02:30
Christopher Boni (boniboyblue)
<@nhanlon:beeper.com>
16:02:33
!hi
<@derekenz:fedora.im>
16:02:33
!hi
<@nielsenb:fedora.im>
16:02:33
!hi
<@zodbot:fedora.im>
16:02:34
Neil Hanlon (neil) - he / him / his
<@zodbot:fedora.im>
16:02:34
Derek Enz (derekenz)
<@zodbot:fedora.im>
16:02:34
Brandon Nielsen (nielsenb)
<@adamwill:fedora.im>
16:04:20
hi hi hi
<@adamwill:fedora.im>
16:04:35
how's everybody doing
<@conan_kudo:matrix.org>
16:04:47
!hi
<@zodbot:fedora.im>
16:04:50
Neal Gompa (ngompa) - he / him / his
<@lruzicka:matrix.org>
16:05:05
We are fine, refined and fined.
<@derekenz:fedora.im>
16:05:06
Fine thanks
<@nhanlon:beeper.com>
16:05:09
doing alright, how about you Adam?
<@adamwill:fedora.im>
16:05:21
oh, the usual
<@kparal:matrix.org>
16:06:26
is blockerbugs completely down?
<@adamwill:fedora.im>
16:06:47
it was working five minutes ago
<@kparal:matrix.org>
16:06:48
ah, seems to work now
<@nielsenb:fedora.im>
16:06:56
Loads for me
<@adamwill:fedora.im>
16:07:07
alrighty, let's get going with some exciting boilerplate!
<@adamwill:fedora.im>
16:07:16
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
16:07:16
!link https://fedoraproject.org/wiki/Basic_Release_Criteria
<@adamwill:fedora.im>
16:07:16
!link https://fedoraproject.org/wiki/Fedora_42_Beta_Release_Criteria
<@adamwill:fedora.im>
16:07:16
!link https://fedoraproject.org/wiki/Fedora_42_Final_Release_Criteria
<@adamwill:fedora.im>
16:07:16
!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:16
Why are we here?
<@adamwill:fedora.im>
16:07:16
!link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
<@adamwill:fedora.im>
16:07:16
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
16:07:16
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
16:07:16
!topic Introduction
<@adamwill:fedora.im>
16:07:16
!link http://qa.fedoraproject.org/blockerbugs/current
<@adamwill:fedora.im>
16:07:29
!info for Final, we have:
<@adamwill:fedora.im>
16:07:30
!info 3 Proposed Blockers
<@adamwill:fedora.im>
16:07:30
!info 7 Accepted Blockers
<@adamwill:fedora.im>
16:07:35
!info 2 Accepted Freeze Exceptions
<@adamwill:fedora.im>
16:07:35
!info 1 Proposed Freeze Exceptions
<@adamwill:fedora.im>
16:07:42
who wants to secretarialize?
<@kparal:matrix.org>
16:08:42
do I see Lukas Brabec waiving his hand?
<@kparal:matrix.org>
16:09:22
I don't think I'm able to do it today after the meeting, btw
<@adamwill:fedora.im>
16:09:23
that's funny, i see that too!
<@lruzicka:matrix.org>
16:10:13
I can do try doing it. I do not see any hands of Lukas Brabec here.
<@lruzicka:matrix.org>
16:10:23
I can try doing it. I do not see any hands of Lukas Brabec here.
<@adamwill:fedora.im>
16:10:52
i'll do it if kamil and lukas aren't around
<@adamwill:fedora.im>
16:11:07
!info adamw will secretarialize
<@adamwill:fedora.im>
16:11:15
let's get started with:
<@adamwill:fedora.im>
16:11:30
!topic Proposed Final blockers
<@adamwill:fedora.im>
16:11:38
!info Ticket vote: FinalBlocker (+0,0,-1) (-lruzicka)
<@adamwill:fedora.im>
16:11:38
!topic (2353002) biosboot required even on MBR disks, not just GPT, but can't be created
<@adamwill:fedora.im>
16:11:38
!link https://bugzilla.redhat.com/show_bug.cgi?id=2353002
<@adamwill:fedora.im>
16:11:38
!link https://pagure.io/fedora-qa/blocker-review/issue/1804
<@adamwill:fedora.im>
16:11:38
!info Proposed Blocker, anaconda-webui, NEW
<@adamwill:fedora.im>
16:11:38
!info Ticket vote: FinalFreezeException (+0,1,-2) (geraldosimiao, -nielsenb, -derekenz)
<@kparal:matrix.org>
16:13:10
read at least https://bugzilla.redhat.com/show_bug.cgi?id=2353002#c21
<@kparal:matrix.org>
16:13:23
we're exploring new grounds here, with webui violating some criteria with our approval 🙂
<@kparal:matrix.org>
16:13:46
I'm not sure which one will be more visible, whether missing bootloader selection or MBR-related issues
<@conan_kudo:matrix.org>
16:13:48
since it's part of a blocking desktop, it counts for finalblocker for me
<@conan_kudo:matrix.org>
16:14:02
webui bugs can't be bypassed when workstation is shipping it
<@conan_kudo:matrix.org>
16:14:09
+1 FinalBlocker
<@adamwill:fedora.im>
16:14:44
yeah, if webui does not want to deal with mbr disks, it should at least do this consistently (not offer options that don't work)
<@kparal:matrix.org>
16:14:50
well, as I wrote, our job is to make sure included features work and are not missing by accident. But if feature is missing intentionally, it's not really QA job. The question is about communication and user expectations
<@kparal:matrix.org>
16:15:18
from what I tested, this is not broken in any way - it won't people's data. But the error message is quite cryptic for most people.
<@lruzicka:matrix.org>
16:15:52
I have found out that one can also use Workstation ISO to workaround this as I am describing in the discussion in BlockerBugs.
<@kparal:matrix.org>
16:16:04
also note that this is not just related to windows dual boot. That's just once common use case where this will be encountered.
<@kparal:matrix.org>
16:16:35
But any old Fedora install will suffer the same issue - can't be reinstalled, can't be manually mounted
<@adamwill:fedora.im>
16:16:36
yeah, there are many ways you might have an MBR disk
<@adamwill:fedora.im>
16:16:52
if you've been reusing the same disk layout since some older fedora (I think before 37?) for instance
<@nielsenb:fedora.im>
16:17:15
Do we have a dual boot criteria for anything but Windows and MacOS?
<@kparal:matrix.org>
16:17:29
I believe that we should comment on this behaviour to let people know and we should perhaps revisit in the future, if Anaconda GTK goes away and there will be no way to perform this.
<@kparal:matrix.org>
16:17:29
Lukas has an interesting workaround:
<@kparal:matrix.org>
16:17:29
> This can be workarounded by using Anaconda GTK, it is also possible to remove the anaconda-webui package from the Live image before running Anaconda, so the system can still be reinstalled with Fedora 42 no matter which ISO one uses.
<@kparal:matrix.org>
16:17:29
<@kparal:matrix.org>
16:17:29
However, I'd probably advise against this, because we haven't tested this approach *at all*.
<@lruzicka:matrix.org>
16:18:18
We don't afaik.
<@lruzicka:matrix.org>
16:18:37
I tested it. It works.
<@lbrabec:matrix.org>
16:18:55
Sorry I'm late, but sure, I can do it again
<@kparal:matrix.org>
16:19:05
that's nice, but it hasn't been *extensively* tested
<@zodbot:fedora.im>
16:19:23
kparal has already given cookies to lbrabec during the F41 timeframe
<@lruzicka:matrix.org>
16:19:36
Well, the method to switch to GTK by erasing that package has been advised to me by mkolman
<@adamwill:fedora.im>
16:19:49
!info in a late substitution, lbrabec will secretarialize
<@lruzicka:matrix.org>
16:20:27
So, I think this is how it is supposed to work :D
<@adamwill:fedora.im>
16:20:34
i'd be relatively confident in that 'workaround'
<@kparal:matrix.org>
16:20:50
all in all, I think this is -1 blocker from me, if Anaconda really intends to release it this way. However, I'd really like to see the error message clearer (as a user, what can I do about it?)
<@adamwill:fedora.im>
16:20:53
since it really just gives you the same setup you'd have on any other live image
<@adamwill:fedora.im>
16:21:01
but, i'm not sure it's really sufficient for this
<@adamwill:fedora.im>
16:21:21
it seems like a long road from "the installer is giving my cryptic errors about BIOS boot partitions, wtf?" to "aha, i should uninstall anaconda-webui!"
<@kparal:matrix.org>
16:21:26
the problem is that this is a universal error which means "don't forget to create this partition", but with MBR, you can't
<@conan_kudo:matrix.org>
16:22:00
I don't think this is a viable choice given that we're literally offering a "reinstall fedora" option
<@adamwill:fedora.im>
16:22:05
yeah, i would really prefer to see the paths that don't work greyed out with a 'can't do this coz MBR' message, or just hidden
<@conan_kudo:matrix.org>
16:22:13
(that is, not making it a blocker)
<@lruzicka:matrix.org>
16:22:21
Therefore I suggest documenting it in CommonBugs. Also, we should know if Anaconda plans to do something about it and if not, we should probably make sure people convert their installations.
<@lruzicka:matrix.org>
16:23:00
Well, you cannot reinstall what ceased to be compatible.
<@adamwill:fedora.im>
16:23:02
i think personally i'd vote +1 with a note that this can be resolved by improving the UX, we don't require MBR support to be implemented
<@adamwill:fedora.im>
16:23:18
common issues is fine but not everyone reads it
<@kparal:matrix.org>
16:23:27
Conan Kudo: "reinstall fedora" isn't required to work, it's new and we don't have any criteria for it
<@conan_kudo:matrix.org>
16:23:36
sigh
<@adamwill:fedora.im>
16:23:38
if anaconda think that even fixing the UX isn't practical we can re-discuss or talk about waiving it
<@kparal:matrix.org>
16:23:40
or am I wrong, Adam?
<@conan_kudo:matrix.org>
16:23:40
that's probably bad
<@conan_kudo:matrix.org>
16:23:59
I thought we had discussed criteria for the webui
<@adamwill:fedora.im>
16:24:08
Kamil Páral well, we have the final criterion "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration"
<@adamwill:fedora.im>
16:24:12
which is, ahem...broad
<@adamwill:fedora.im>
16:24:17
but could at least be *argued* to cover this
<@jkonecny:fedora.im>
16:24:17
I would say that we want to improve the situation but we just started the conversation about how, so it is too early to tell.
<@kparal:matrix.org>
16:24:45
yes, that's for custom install, we don't specifically cover "reinstall fedora while keeping home" in the guided form
<@adamwill:fedora.im>
16:24:47
Conan Kudo we did, i did update the criteria to some extent, but didn't entirely cover this
<@adamwill:fedora.im>
16:24:58
no it isn't
<@adamwill:fedora.im>
16:25:07
nothing in that criteria specifies 'custom' and it is not in a 'custom' section
<@adamwill:fedora.im>
16:25:15
nothing in that criterion specifies 'custom' and it is not in a 'custom' section
<@conan_kudo:matrix.org>
16:25:34
it's a direct guided option, which I assumed we had extended things to cover it
<@adamwill:fedora.im>
16:25:43
and the footnote says "Broadly what it's 'meant to mean' is that you should be able to do anything sane that the Installation Destination spoke attempts to let you do, without the installer exploding or failing", which implies that it is *not* specific to custom
<@kparal:matrix.org>
16:25:50
guided is covered here: https://fedoraproject.org/wiki/Fedora_42_Beta_Release_Criteria#Guided_partitioning
<@adamwill:fedora.im>
16:25:56
this is in Final
<@adamwill:fedora.im>
16:26:06
Final doesn't have separate sections and is intentionally broader than Beta
<@conan_kudo:matrix.org>
16:26:19
it also explicitly covers MBR
<@conan_kudo:matrix.org>
16:26:25
so this bug qualifies
<@adamwill:fedora.im>
16:26:42
based on the wording of the criterion and the footnote, i'd personally say we should read that criterion as covering the guided options in webui - to me that's clearly within what we intended
<@conan_kudo:matrix.org>
16:26:57
same
<@nielsenb:fedora.im>
16:28:06
I agree
<@adamwill:fedora.im>
16:28:10
we should update the footnote for the existence of webui, but for me the intent's pretty clear. in gtkui, "the Installation Destination spoke" contains *all* partitioning options, guided and custom
<@kparal:matrix.org>
16:29:04
so, we seem to agree that this can be fixed with a better UI/error message?
<@kparal:matrix.org>
16:29:16
I don't think we want to mandate MBR support forever
<@adamwill:fedora.im>
16:29:41
on the wording of the criterion a better "error message" might not strictly cover it, but certainly if the UX didn't allow you to *try* the affected paths on an MBR disk that'd be OK
<@conan_kudo:matrix.org>
16:30:00
I would probably expect a Change to declare MBR unsupported
<@conan_kudo:matrix.org>
16:30:03
that hasn't happened yet
<@conan_kudo:matrix.org>
16:30:09
so at least for now, I _do_ expect MBR to work
<@adamwill:fedora.im>
16:30:11
if the "error message" was something like "nope you can't do that, try again" but it wasn't *fatal*, we could probably argue that was also sufficient
<@adamwill:fedora.im>
16:30:24
if the "error message" was something like "nope you can't do that, try again" but it wasn't *fatal* - didn't crash or end the installer - we could probably argue that was also sufficient
<@kparal:matrix.org>
16:30:27
yes, the Change messaging didn't include this
<@conan_kudo:matrix.org>
16:30:37
and MBR can't be unsupported in Anaconda as long as we still support Raspberry Pi 3
<@adamwill:fedora.im>
16:31:02
meh, practically speaking i think i'm ok if webui doesn't support MBR but gtkui does. that's consistent with what we decided on the other blocker where webui wasn't going to support a thing
<@adamwill:fedora.im>
16:31:21
i really hope nobody's trying to install workstation live on the pi 3 :P
<@lruzicka:matrix.org>
16:31:23
+1
<@conan_kudo:matrix.org>
16:31:35
it's supported currently
<@conan_kudo:matrix.org>
16:31:54
and people do it with the rpi3 edk thingy
<@adamwill:fedora.im>
16:31:55
not the live iso, surely? i didn't think pi 3 could do generic UEFI install?
<@adamwill:fedora.im>
16:31:59
oh yikes
<@adamwill:fedora.im>
16:32:02
those people must love pain
<@conan_kudo:matrix.org>
16:32:07
yup
<@adamwill:fedora.im>
16:32:12
anyhoo
<@conan_kudo:matrix.org>
16:32:21
and because of restrictions in rpi3 firmware, you _must_ use MBR
<@adamwill:fedora.im>
16:32:45
i think i'll say formally i'm +1, with the note that we aren't mandating MBR support, a better 'failure path' would be OK
<@kparal:matrix.org>
16:33:39
sounds good
<@adamwill:fedora.im>
16:33:49
other votes?
<@derekenz:fedora.im>
16:34:11
Sounds ok +1
<@lruzicka:matrix.org>
16:34:40
If blocker than do not force Anaconda to implement it in WebUI -> that could cause more harm. I am fine with better error message.
<@nielsenb:fedora.im>
16:34:42
I would be fine with that
<@lruzicka:matrix.org>
16:35:22
If blocker then do not force Anaconda to implement it in WebUI -> that could cause more harm. I am fine with better error message.
<@adamwill:fedora.im>
16:36:24
proposed !agreed 2353002 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration". We note that resolving this does not require implementation of MBR support; this could be sufficiently addressed by not allowing the user to attempt unsupported operations on an MBR-labelled disk.
<@lruzicka:matrix.org>
16:36:48
ack
<@derekenz:fedora.im>
16:36:51
ack
<@boniboyblue:fedora.im>
16:36:53
ack
<@nielsenb:fedora.im>
16:37:00
ack
<@adamwill:fedora.im>
16:37:23
jkonecny if it turns out to be impossible to deal with this, let us know and we'll consider options
<@adamwill:fedora.im>
16:37:37
!agreed 2353002 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration". We note that resolving this does not require implementation of MBR support; this could be sufficiently addressed by not allowing the user to attempt unsupported operations on an MBR-labelled disk.
<@adamwill:fedora.im>
16:37:52
!link https://pagure.io/fedora-qa/blocker-review/issue/1806
<@adamwill:fedora.im>
16:37:52
!info Proposed Blocker, cockpit, NEW
<@adamwill:fedora.im>
16:37:52
!topic (2354497) re-format an encrypt partition make it pretty hard to continue the installation
<@adamwill:fedora.im>
16:37:52
!link https://bugzilla.redhat.com/show_bug.cgi?id=2354497
<@adamwill:fedora.im>
16:39:23
i guess i'd say +1 under the same criterion
<@conan_kudo:matrix.org>
16:39:36
+1 FinalBlocker
<@boniboyblue:fedora.im>
16:41:18
+1 FinalBlocker for me as well.
<@derekenz:fedora.im>
16:41:28
+1 FinalBlocker
<@nhanlon:beeper.com>
16:41:31
ditto, +1 FB
<@nielsenb:fedora.im>
16:41:49
It's not made explicit in the criteria, but I agree it should work as the installer offers it (and I would expect it to work, as the installer also explicitly asks if you want to encrypt on a fresh install)
<@nielsenb:fedora.im>
16:41:53
FinalBlocker +1
<@adamwill:fedora.im>
16:42:15
proposed !agreed 2354497 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" (can also be argued to violate the Beta custom partitioning criteria)
<@nielsenb:fedora.im>
16:42:38
ack
<@derekenz:fedora.im>
16:42:42
ack
<@conan_kudo:matrix.org>
16:42:48
ack
<@lruzicka:matrix.org>
16:42:51
I do not understand, however, why would someone reformat a disk and wanted the same LUKS? Why can't they create a new LUKS with the same password if it is reformatted anyway?
<@nielsenb:fedora.im>
16:43:15
I reformat / which is under luks, but preserve home
<@nielsenb:fedora.im>
16:43:28
As a common installer flow, at least for me
<@conan_kudo:matrix.org>
16:43:30
if there are multiple security keys, it may be desirable to preserve that setup
<@lruzicka:matrix.org>
16:43:46
hmm, ok
<@adamwill:fedora.im>
16:44:04
anyway, the installer offers it, so...
<@nielsenb:fedora.im>
16:44:12
Yeah, it's probably not what most people do
<@nielsenb:fedora.im>
16:44:27
But I can see where people would find themselves doing it
<@adamwill:fedora.im>
16:44:36
!agreed 2354497 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" (can also be argued to violate the Beta custom partitioning criteria)
<@nielsenb:fedora.im>
16:45:07
If someone told me it was going to be unsupported tomorrow, I don't think it would be world ending, but then the installer shouldn't let you do it
<@nielsenb:fedora.im>
16:45:15
Kinda like the last two bugs I guess
<@adamwill:fedora.im>
16:45:23
right, again, just not supporting it is an option. but it looks like a real fix is posted anyway
<@adamwill:fedora.im>
16:45:43
!info Proposed Blocker, kernel, NEW
<@adamwill:fedora.im>
16:45:43
!link https://bugzilla.redhat.com/show_bug.cgi?id=2353148
<@adamwill:fedora.im>
16:45:43
!topic (2353148) Fedora 42 crashes while booting on IPU6 laptops with an ivsc chip
<@adamwill:fedora.im>
16:45:43
!info Ticket vote: FinalFreezeException (+1,0,-0) (+adamwill)
<@adamwill:fedora.im>
16:45:43
!info Ticket vote: FinalBlocker (+3,0,-4) (+geraldosimiao, +nielsenb, +eischmann, -kparal, -derekenz, -lruzicka, -boniboyblue)
<@adamwill:fedora.im>
16:45:43
!link https://pagure.io/fedora-qa/blocker-review/issue/1801
<@adamwill:fedora.im>
16:45:48
whee
<@conan_kudo:matrix.org>
16:45:57
oof, that's pretty bad
<@adamwill:fedora.im>
16:46:04
i am currently trying to figure out a kernel arg workaround for this...blocklisting enough kernel modules *should* do it
<@adamwill:fedora.im>
16:46:16
but yeah, if you have an affected system it's bad.
<@conan_kudo:matrix.org>
16:46:22
FinalBlocker +1 on the basis this is actually a F42 change too
<@kparal:matrix.org>
16:47:10
the fix is ready, just not released
<@kparal:matrix.org>
16:47:19
it's even merged to the kernel tree
<@adamwill:fedora.im>
16:47:21
i'm super on the fence about blocking
<@adamwill:fedora.im>
16:47:51
obviously a fix existing makes it easier to say 'sure, +1' but if i'm strict on myself and apply the good ol' "would we really not release if this was the last blocker on thursday?" test it's tricky
<@kparal:matrix.org>
16:48:08
there's no such release criterion, sorry to inform you 🙂
<@kparal:matrix.org>
16:48:26
"all Changes must work" would be super nice, but we'd never release
<@conan_kudo:matrix.org>
16:48:39
I dunno man, crashing the whole system is a pretty valid criterion :)
<@nielsenb:fedora.im>
16:48:47
This passes the final blocker test for me at least, just because you can't easily "fix it in post"
<@conan_kudo:matrix.org>
16:48:53
I would be less about making sure it worked if we didn't advertise about it
<@kparal:matrix.org>
16:49:24
I covered that in the blocker ticket. It is and it is not, depends on the scale.
<@conan_kudo:matrix.org>
16:49:47
stop making this hard kamil :P
<@adamwill:fedora.im>
16:50:38
i think it is legit to consider it as a factor when making these subjective calls though
<@conan_kudo:matrix.org>
16:51:18
right, I'd be more on adamw's side about being on the fence if it wasn't a directly advertised feature for this release
<@conan_kudo:matrix.org>
16:51:29
that makes this much more painful
<@kparal:matrix.org>
16:51:57
punt and release the new kernel, so that we can avoid this decision? 🙂
<@conan_kudo:matrix.org>
16:52:22
if the new kernel releases before freeze again, sure :)
<@kparal:matrix.org>
16:52:48
this will surely get +1 FE
<@adamwill:fedora.im>
16:52:51
ok, got a module_blacklist recipe that works...it's a pretty icky workaround for folks who aren't used to kernel args i guess, but it works
<@conan_kudo:matrix.org>
16:53:02
the only time we waived such a similar condition was when we literally couldn't get shim signed
<@conan_kudo:matrix.org>
16:53:13
and we just had to accept fedora didn't work on newer computers
<@adamwill:fedora.im>
16:53:21
that one definitely had wider impact than this, i'd say
<@adamwill:fedora.im>
16:53:39
this really does just appear to be post-~2023 dell laptops, afaict
<@conan_kudo:matrix.org>
16:53:44
it's going to be messy as that hardware spreads though, esp with lenovo and framework preloads
<@adamwill:fedora.im>
16:53:46
nobody else seems to be using the vsc chip
<@conan_kudo:matrix.org>
16:53:53
it's going to be messy as that hardware spreads though, esp with lenovo preloads
<@adamwill:fedora.im>
16:54:05
Conan Kudo are you not aware of the vsc wrinkle?
<@conan_kudo:matrix.org>
16:54:11
no?
<@adamwill:fedora.im>
16:54:16
this isn't affecting *all* systems with IPU6 cameras
<@adamwill:fedora.im>
16:54:25
only ones with some extra chip, which in practice seems to be dells only
<@adamwill:fedora.im>
16:55:23
https://patchwork.kernel.org/project/linux-media/cover/1690631575-15124-1-git-send-email-wentong.wu@intel.com/
<@conan_kudo:matrix.org>
16:55:24
my thing is that is the case _right now_, but we have no idea about future hardware being prepped right now
<@adamwill:fedora.im>
16:55:48
says it's "available in existing commercial platforms from multiple OEMs" but no idea who else aside from dell that'd be
<@adamwill:fedora.im>
16:55:58
yeah, that's a valid concern
<@nielsenb:fedora.im>
16:56:13
In a world where Dell is the largest non-Apple vendor, I'm not sure "Dell only" has much weight to me
<@conan_kudo:matrix.org>
16:56:13
Dell is an early adopter for Intel stuff because $reasons
<@adamwill:fedora.im>
16:56:21
people could potentially be installing f42 on hardware all the way up till mid next year, and it'll be the "current" version till november
<@conan_kudo:matrix.org>
16:56:40
so it's a good signal for future hardware platforms from other OEMs
<@adamwill:fedora.im>
16:56:50
Conan Kudo other vendors are already using IPU6 cameras, but they *haven't* picked up ivsc it seems. no idea why/why not.
<@conan_kudo:matrix.org>
16:57:08
I dunno either, but I've seen Dell be the start for many things
<@nielsenb:fedora.im>
16:57:17
Their Intel checks haven't cleared yet
<@conan_kudo:matrix.org>
16:57:26
so I have to assume it will spread this year because Dell used it for a couple of years
<@conan_kudo:matrix.org>
16:57:42
LPCAMM was the same way, as well as a bunch of other things
<@boniboyblue:fedora.im>
16:57:45
Does today's new kernel fix this or will it be a future release?
<@adamwill:fedora.im>
16:58:21
there's no f42 kernel today
<@adamwill:fedora.im>
16:58:31
f40 and f41 aren't affected as the bug only appears with gcc 15
<@adamwill:fedora.im>
16:58:50
kernel-6.14.0-0.rc7.20250321gitb3ee1e460951.60.fc43 has the fix for rawhide, it looks like
<@adamwill:fedora.im>
16:58:54
i don't see an f42 build with the fix yet
<@boniboyblue:fedora.im>
16:59:01
My bad - though someone told me 6.14 stable was pushed.
<@adamwill:fedora.im>
16:59:18
the next f42 build should be for the next 'milestone' (rc8 or final)
<@boniboyblue:fedora.im>
16:59:24
My bad - thought someone told me 6.14 stable was pushed.
<@conan_kudo:matrix.org>
16:59:45
with 6.14 final tagged this morning, maybe we'll see 6.14 final land for f42 today
<@adamwill:fedora.im>
17:00:09
so hmm
<@adamwill:fedora.im>
17:00:14
let's at least do the easy one:
<@adamwill:fedora.im>
17:00:16
+1 FE
<@nielsenb:fedora.im>
17:00:24
FinalFE +1
<@boniboyblue:fedora.im>
17:00:34
FinalFE +1
<@derekenz:fedora.im>
17:00:39
FinalFE +1
<@conan_kudo:matrix.org>
17:00:42
FinalFE +1
<@kparal:matrix.org>
17:01:12
+1 FE
<@adamwill:fedora.im>
17:01:41
ok, so that's clear
<@adamwill:fedora.im>
17:01:45
now...blocker votes
<@adamwill:fedora.im>
17:01:50
i think i'm kinda at +0.1?
<@adamwill:fedora.im>
17:02:03
if we don't have a clear blocker vote we can punt it and hope it goes away with the FE. :P
<@conan_kudo:matrix.org>
17:02:05
+1 FinalBlocker
<@nielsenb:fedora.im>
17:02:08
12%-ish percent of the market, can't fix release media
<@nielsenb:fedora.im>
17:02:12
FinalBlocker +1
<@kparal:matrix.org>
17:03:05
I'm more towards -1, but I'm happy to withdraw it if most people want to block on it
<@adamwill:fedora.im>
17:03:17
too late, i counted it!
<@derekenz:fedora.im>
17:03:22
Same for me
<@kparal:matrix.org>
17:03:40
Pitty we don't have something like "delay 1 week most, then go"
<@boniboyblue:fedora.im>
17:03:41
I'm still FinalBlocker -1 on this.
<@adamwill:fedora.im>
17:04:03
Derek Enz same as who? is that a -1 or a +1?
<@derekenz:fedora.im>
17:04:12
-1
<@derekenz:fedora.im>
17:04:53
Agreed
<@lruzicka:matrix.org>
17:05:16
Same as Kamil
<@nielsenb:fedora.im>
17:05:19
I'm kinda surprised people are okay with unusable install media for relatively common new hardware, but the votes are the votes
<@geraldosimiao:matrix.org>
17:05:35
+1 FinalBlocker
<@boniboyblue:fedora.im>
17:06:19
If it was ALL Dell machines or ALL lenovo machines I would have a different opinion.
<@adamwill:fedora.im>
17:06:23
ok, so we're at +3.1 / -3 , i think
<@adamwill:fedora.im>
17:06:27
that sure smells like a punt!
<@conan_kudo:matrix.org>
17:07:06
I'm pretty disappointed too.
<@conan_kudo:matrix.org>
17:07:18
especially since this year is a refresh year for most companies
<@conan_kudo:matrix.org>
17:07:34
but in practice we'll hopefully have a fix anyway
<@adamwill:fedora.im>
17:07:37
proposed !agreed 2353148 - punt (delay decision) on blocker status, AcceptedFE (Final) - the vote on blocker status for this is split, but there is clear consensus for a freeze exception. As the fix for this is already lined up, we expect it will land before deciding the blocker status becomes crucial
<@geraldosimiao:matrix.org>
17:08:05
ack
<@boniboyblue:fedora.im>
17:08:14
ack
<@conan_kudo:matrix.org>
17:08:19
ack
<@kparal:matrix.org>
17:08:20
ack
<@derekenz:fedora.im>
17:08:22
ack
<@nielsenb:fedora.im>
17:08:32
Yeah, even if it's a relatively small portion of Dell laptops, that's still a lot of units
<@nielsenb:fedora.im>
17:08:33
ack
<@adamwill:fedora.im>
17:08:35
proposed !agreed 2353148 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - the vote on blocker status for this is split, but there is clear consensus for a freeze exception. As the fix for this is already lined up, we expect it will land before deciding the blocker status becomes crucial
<@adamwill:fedora.im>
17:08:47
!agreed 2353148 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - the vote on blocker status for this is split, but there is clear consensus for a freeze exception. As the fix for this is already lined up, we expect it will land before deciding the blocker status becomes crucial
<@conan_kudo:matrix.org>
17:08:57
we're going to have to figure out how to handle "new hardware borked" as a criterion
<@conan_kudo:matrix.org>
17:09:40
I'm not sure it's a straightforward one either
<@kparal:matrix.org>
17:09:42
it could work as a criterion, if we had a fix ready. I think I would support that
<@adamwill:fedora.im>
17:09:53
i think the existing criteria and process docs cover it fine, tbh
<@adamwill:fedora.im>
17:10:08
nothing in them to prevent us considering future hw
<@adamwill:fedora.im>
17:10:15
anyhoo
<@nielsenb:fedora.im>
17:10:21
It's just so hard to judge "specific hardware"
<@adamwill:fedora.im>
17:10:31
!info the sole proposed FE was already accepted as a blocker
<@adamwill:fedora.im>
17:10:37
so let's move on to
<@nielsenb:fedora.im>
17:10:37
Like, literally any Dell laptop will be more common than a DIY desktop config
<@adamwill:fedora.im>
17:10:44
!topic Accepted Final blockers
<@adamwill:fedora.im>
17:11:12
!info all accepted blockers are in some kind of 'fix on the way' state except:
<@adamwill:fedora.im>
17:11:19
!link https://pagure.io/fedora-qa/blocker-review/issue/1794
<@adamwill:fedora.im>
17:11:19
!topic (2352679) Fedora 42: Server boot aarch64 image exceeds maximum size
<@adamwill:fedora.im>
17:11:19
!link https://bugzilla.redhat.com/show_bug.cgi?id=2352679
<@adamwill:fedora.im>
17:11:19
!info Accepted Blocker, distribution, ASSIGNED
<@adamwill:fedora.im>
17:11:27
i think we did poke server WG about this
<@adamwill:fedora.im>
17:11:47
and it was on the agenda for the meeting last week which i didn't make it to
<@adamwill:fedora.im>
17:11:49
let me check the notes
<@adamwill:fedora.im>
17:13:20
https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-03-19/fedora-server.2025-03-19-17.00.log.txt
<@adamwill:fedora.im>
17:13:27
```
<@adamwill:fedora.im>
17:13:27
```
<@adamwill:fedora.im>
17:13:27
2025-03-19 18:06:41 <@pboy:fedora.im> Anything to discuss? Otherwise I would close.
<@adamwill:fedora.im>
17:13:27
2025-03-19 18:06:25 <@pboy:fedora.im> Let's discuss this problem on the mailing list.
<@adamwill:fedora.im>
17:13:27
2025-03-19 18:05:56 <@pboy:fedora.im> I see that we have already exceeded our time.
<@adamwill:fedora.im>
17:13:27
2025-03-19 18:05:18 <@pboy:fedora.im> Any ideas? I'd hate to just change the permissible size. We deliberately limited it to take into account the conditions in critical areas of our world.
<@adamwill:fedora.im>
17:13:36
so it seems like pboy wanted to look into it and potentially fix it
<@adamwill:fedora.im>
17:13:40
i guess i can start an ml thread
<@conan_kudo:matrix.org>
17:14:22
I don't think he understood how the image grows because of linux-firmware
<@adamwill:fedora.im>
17:17:22
yeah, i'm gonna mention that
<@adamwill:fedora.im>
17:17:32
i haven't looked into it specifically yet but it's always my first suspect these days :/
<@adamwill:fedora.im>
17:17:45
we can't do much about OEMs gleefully dumping another 50MB into it upstream every week
<@adamwill:fedora.im>
17:18:03
besides continuing to try and split things off where we can
<@conan_kudo:matrix.org>
17:18:08
there was a lot of arm specific firmware dumped in this cycle
<@conan_kudo:matrix.org>
17:18:25
specifically with Qualcomm X1 Extreme SoCs
<@adamwill:fedora.im>
17:18:51
fun
<@adamwill:fedora.im>
17:18:53
that's probably it, then
<@conan_kudo:matrix.org>
17:18:57
and there's probably more, but that one I paid attention to
<@adamwill:fedora.im>
17:19:00
i'll run through my usual analysis later if i get time
<@conan_kudo:matrix.org>
17:19:15
since Fedora KDE has been trying to get a WoA device supported
<@adamwill:fedora.im>
17:19:48
!info server WG is aware of this and has had an initial discussion, adamw has posted a mailing list thread about it now too. we'll make sure either the image is shrunk or the limit gets bumped
<@farchord:fedora.im>
17:20:13
I lack enough knowledge to properly boot my laptop on Fedora KDE lol I just tried, I guess using the dtb isnt enough lol
<@farchord:fedora.im>
17:20:38
On the Asus Vivobook S15 btw (Snapdragon X1 Elite)
<@adamwill:fedora.im>
17:20:41
!topic Open floor
<@adamwill:fedora.im>
17:20:46
any other business, folks?
<@boniboyblue:fedora.im>
17:21:12
Nothing from me at this time.
<@nielsenb:fedora.im>
17:21:18
Not from me
<@derekenz:fedora.im>
17:21:27
Nothing here
<@conan_kudo:matrix.org>
17:21:32
nothing from me
<@kparal:matrix.org>
17:24:12
I have something
<@adamwill:fedora.im>
17:24:18
go for it
<@kparal:matrix.org>
17:24:33
https://discussion.fedoraproject.org/t/136593/4
<@kparal:matrix.org>
17:24:56
https://discussion.fedoraproject.org/t/cant-log-in-to-gnome-when-mouse-keys-accessibility-option-is-enabled/135380
<@kparal:matrix.org>
17:24:56
the user is proposing this as a blocker:
<@nielsenb:fedora.im>
17:25:12
Well that's not great
<@kparal:matrix.org>
17:25:20
and it is honestly quite humiliating that we keep releasing like that, because the consequences are dire
<@adamwill:fedora.im>
17:25:35
oh good grief
<@kparal:matrix.org>
17:25:52
but it's already present in several releases, so my assessment is that there's low chance of having it as a blocker
<@kparal:matrix.org>
17:26:03
but I want to hear your thoughts
<@conan_kudo:matrix.org>
17:26:22
that's freaking awful
<@nielsenb:fedora.im>
17:26:31
I don't see a bug? So there was a low chance of it ever becoming blocking.
<@conan_kudo:matrix.org>
17:26:43
that's easily remediated
<@kparal:matrix.org>
17:26:49
there's a gnome bug link
<@nielsenb:fedora.im>
17:26:51
I would almost certainly be FinalBlocker +1 today.
<@adamwill:fedora.im>
17:26:51
Matthias Clasen around? any hope of this getting fixed?
<@conan_kudo:matrix.org>
17:26:56
the forum post can be transposed into a fedora bug
<@conan_kudo:matrix.org>
17:27:05
it's absolutely FinalBlocker to me
<@kparal:matrix.org>
17:27:12
https://gitlab.gnome.org/GNOME/mutter/-/issues/3708
<@adamwill:fedora.im>
17:27:22
since there's an upstream bug, a downstream bug is only useful for blocker/fe tracking
<@adamwill:fedora.im>
17:27:24
i'd certainly give this an fe
<@conan_kudo:matrix.org>
17:27:27
sigh anubis
<@adamwill:fedora.im>
17:27:45
you have problems with anubis? i haven't had any issues wit hit
<@adamwill:fedora.im>
17:27:59
the fact that we ship this in existing releases makes it a bit tricky as a blocker for me
<@kparal:matrix.org>
17:27:59
funnily enough, I think Lukas Brabec even reinstalled his mother's computer because of this, IIRC. She had it turned on probably by some accident.
<@kparal:matrix.org>
17:28:35
I might have mixed up names, but it doesn't really matter
<@conan_kudo:matrix.org>
17:28:48
apparently this bug kicks in with any a11y stuff turned on: https://gitlab.gnome.org/GNOME/mutter/-/issues/3708#note_2388446
<@conan_kudo:matrix.org>
17:29:05
that's considerably more serious
<@conan_kudo:matrix.org>
17:29:17
apparently this bug kicks in with any a11y stuff turned on in f42: https://gitlab.gnome.org/GNOME/mutter/-/issues/3708#note\_2388446
<@conan_kudo:matrix.org>
17:29:29
sometimes it causes my computer to lock up
<@kparal:matrix.org>
17:29:36
what does `a11y.keyboard` do?
<@conan_kudo:matrix.org>
17:29:40
my daily driver is still a 10 year old Intel MBP
<@adamwill:fedora.im>
17:29:53
there are two MRs for this, both of which seem to be just sitting around
<@adamwill:fedora.im>
17:29:58
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4083 and https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4195
<@conan_kudo:matrix.org>
17:30:21
it's the onscreen keyboard
<@kparal:matrix.org>
17:30:38
I wonder how many a11y users we actually have...
<@nielsenb:fedora.im>
17:30:55
None, they can't sign in
<@conan_kudo:matrix.org>
17:31:00
it's the onscreen keyboard, IIRC
<@kparal:matrix.org>
17:31:01
true
<@adamwill:fedora.im>
17:31:08
it looks like ubuntu backported the earlier MR
<@kparal:matrix.org>
17:31:09
that's what I was hinting at
<@adamwill:fedora.im>
17:31:43
well, there was also the infamous orca/wayland mess that was only recently resolved. but that would be for a different category of folks I guess (visual vs. movement impairment)
<@matthiasc:gnome.org>
17:32:57
adamw: for all the upsetness about this, it seems nobody has gotten around to looking at it in the last 5 months...
<@adamwill:fedora.im>
17:33:10
well, ubuntu backported one of the PRs, so i guess they're happy
<@matthiasc:gnome.org>
17:33:28
could be that mousekeys is just not a very commonly used a11y feature
<@adamwill:fedora.im>
17:33:30
carlos did 'look at it' apparently and filed https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4195
<@adamwill:fedora.im>
17:33:51
but that seems to have stalled after some initial discussion with jonas
<@matthiasc:gnome.org>
17:34:13
i'll see if they still remember any outcomes
<@adamwill:fedora.im>
17:34:36
Matthias Clasen daniel noted in the earlier MR: "Despite only happening when mouse keys is enabled, we're finding this has been close to the top gnome-shell 47 crashes for Ubuntu 24.10 in the last few days."
<@matthiasc:gnome.org>
17:35:02
curious
<@adamwill:fedora.im>
17:35:36
and per some discussion on the original issue it seems the crash now also happens with `org.gnome.desktop.a11y.keyboard` set (whatever that does)
<@conan_kudo:matrix.org>
17:35:55
rathann isn't in this room, but he is around in other matrix rooms
<@adamwill:fedora.im>
17:36:30
"Enable accessibility keyboard shortcuts", according to gsettings-desktop-schemas
<@conan_kudo:matrix.org>
17:36:37
huh neat
<@lruzicka:matrix.org>
17:40:49
What exactly does mousekeys do? I will try to switch it on so what do I expect?
<@kparal:matrix.org>
17:41:31
control your mouse with numpad, I believe
<@matthiasc:gnome.org>
17:41:41
it lets you move the pointer with the numeric block, indeed
<@matthiasc:gnome.org>
17:41:56
but who has a numpad nowadays...
<@adamwill:fedora.im>
17:42:13
filed https://bugzilla.redhat.com/show_bug.cgi?id=2354592
<@adamwill:fedora.im>
17:42:38
i'm gonna bet on "anyone who needs this accessibility feature", for a start
<@conan_kudo:matrix.org>
17:43:19
ooh that means this is a RHEL 10 bug too (even though RHEL 10 is out of scope here)
<@conan_kudo:matrix.org>
17:43:26
since this affects GNOME 47 and 48
<@adamwill:fedora.im>
17:43:51
probably?
<@conan_kudo:matrix.org>
17:44:41
will test later and find out
<@lruzicka:matrix.org>
17:45:59
I do have it, but I do not want cut myself of the system, spinning a VM
<@adamwill:fedora.im>
17:46:04
i'd guess the bug happens whether your keyboard has one or not
<@adamwill:fedora.im>
17:46:10
if you turn the feature on
<@kparal:matrix.org>
17:46:37
I tested it with F42, the bug is still present
<@nielsenb:fedora.im>
17:46:43
I would think the feature would take non-numpad keyboards into account and give you WASD or something, but maybe not
<@adamwill:fedora.im>
17:46:59
do we want to formally vote this one now, or just note it and vote next week if it's not resolved by then?
<@kparal:matrix.org>
17:47:03
you don't need to have a numpad, just enable it and you won't log in again
<@adamwill:fedora.im>
17:47:20
quick! vote on whether we should vote!
<@nielsenb:fedora.im>
17:47:41
+1 no votes from the open floor
<@kparal:matrix.org>
17:47:42
possibly keep it for later, because some people already left I think
<@conan_kudo:matrix.org>
17:48:27
enough of us are here to vote
<@lruzicka:matrix.org>
17:50:19
We can vote.
<@kparal:matrix.org>
17:50:34
we don't have an accessibility criterion, and this is not "basic functionality" of gnome-settings, most probably. But the outcome is quite severe.
<@derekenz:fedora.im>
17:50:40
Lets do this
<@lruzicka:matrix.org>
17:51:02
This would be accessibility, right? Why gnome settings?
<@kparal:matrix.org>
17:51:05
and it's already present in stable releases
<@kparal:matrix.org>
17:51:25
I don't think we can justify +1
<@adamwill:fedora.im>
17:51:25
i'd call it a conditional violation of the 'must boot to a working desktop' criterion
<@adamwill:fedora.im>
17:51:33
the condition being 'you need any affected accesibility feature
<@kparal:matrix.org>
17:51:47
unless there's someone with a high degree of criteria-fu...
<@adamwill:fedora.im>
17:51:51
well, i could topic it if we wanted to vote.
<@kparal:matrix.org>
17:51:51
like Adam
<@conan_kudo:matrix.org>
17:52:27
let's topic it and vote
<@lruzicka:matrix.org>
17:52:38
We did not know about the bug, did we? So basically we should not advocate with "we have released"
<@conan_kudo:matrix.org>
17:52:48
right
<@adamwill:fedora.im>
17:53:04
!topic (2354592) GNOME crashes on startup if keyboard accessibility features are enabled
<@nielsenb:fedora.im>
17:53:14
Also with the "we have released" argument, if it's something that keeps people from using Fedora, how / why would they report it?
<@adamwill:fedora.im>
17:53:15
!link https://bugzilla.redhat.com/show_bug.cgi?id=2354592
<@adamwill:fedora.im>
17:53:27
!info Proposed Blocker, mutter, POST
<@adamwill:fedora.im>
17:53:34
!info this is a late proposed blocker
<@adamwill:fedora.im>
17:53:57
the 'we already released' argument is a *practical* one
<@adamwill:fedora.im>
17:54:06
it more or less runs thus:
<@adamwill:fedora.im>
17:54:26
if we take a bug as a blocker, the *practical effect* of that for users is that when they go to download the "current Fedora", they will still get the old release, not the new one, until we fix the bug
<@adamwill:fedora.im>
17:54:40
however, since the old release *also contains the same bug*, we don't achieve any concrete improvement by blocking on it
<@adamwill:fedora.im>
17:54:54
a user who downloads "the current Fedora" is affected by the bug whether we block on it or not
<@adamwill:fedora.im>
17:55:20
the counterargument i guess is that we look worse if we knew about the problem and said 'eh we don't care we'll ship anyway'
<@lruzicka:matrix.org>
17:55:39
this +1
<@nielsenb:fedora.im>
17:55:45
And improvements to "future" Fedoras should hold weight
<@conan_kudo:matrix.org>
17:55:58
tbh, I am not super-motivated by "well it was always borked so it's fine"
<@conan_kudo:matrix.org>
17:56:23
we didn't _know_ it was broken until now
<@nielsenb:fedora.im>
17:56:24
There are times I can see looking the other way
<@nielsenb:fedora.im>
17:56:39
But when it's "oh hey, a class of people just can't use our marquee product"...
<@kparal:matrix.org>
17:57:02
well I published the common issue article in November
<@matthiasc:gnome.org>
17:57:18
immediate success, carlos merged one of the fixes
<@adamwill:fedora.im>
17:57:20
this is proposed as a violation of Basic criterion "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" in the case that the user requires an affected accessibility option
<@adamwill:fedora.im>
17:57:31
yay, we like success
<@adamwill:fedora.im>
17:57:44
i'm clearly +1 FE on this
<@nielsenb:fedora.im>
17:57:51
Yeah
<@conan_kudo:matrix.org>
17:57:52
success is great
<@nielsenb:fedora.im>
17:57:55
FinalFE +1
<@kparal:matrix.org>
17:58:11
FE +1
<@derekenz:fedora.im>
17:58:12
+1 FE
<@adamwill:fedora.im>
17:58:16
i'll do a quick build with the patch applied so we can be sure it actually works
<@geraldosimiao:matrix.org>
17:58:18
+1 FE
<@conan_kudo:matrix.org>
17:58:57
+1 FE +1 FB
<@adamwill:fedora.im>
17:58:59
ok, so we have clear FE approval
<@adamwill:fedora.im>
17:59:07
blocker votes? i'm kinda +0
<@adamwill:fedora.im>
17:59:20
(which is infinitesimally more blocker-y than -0)
<@conan_kudo:matrix.org>
17:59:20
+1 FinalBlocker
<@nielsenb:fedora.im>
17:59:23
FinalBlocker +1
<@kparal:matrix.org>
17:59:42
+0
<@derekenz:fedora.im>
18:00:09
+1 FinalBlocker
<@adamwill:fedora.im>
18:00:40
that's +3.(2*infinitesimal amount)
<@adamwill:fedora.im>
18:01:35
proposed !agreed 2354592 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" in the case that an affected a11y setting is enabled
<@conan_kudo:matrix.org>
18:01:47
ack
<@derekenz:fedora.im>
18:01:52
ack
<@nielsenb:fedora.im>
18:02:11
ack
<@adamwill:fedora.im>
18:02:54
!agreed 2354592 - AcceptedBlocker (Final) - this is accepted as a conditional violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" in the case that an affected a11y setting is enabled
<@adamwill:fedora.im>
18:03:00
alrighty
<@adamwill:fedora.im>
18:03:04
!topic Open floor, take 2
<@adamwill:fedora.im>
18:03:07
any other other business? :D
<@kparal:matrix.org>
18:03:18
nothing more from me 🙂
<@conan_kudo:matrix.org>
18:03:28
nothing more from me
<@derekenz:fedora.im>
18:03:38
nothing from me
<@lruzicka:matrix.org>
18:03:49
nothingham
<@nielsenb:fedora.im>
18:03:50
Nothing from me
<@adamwill:fedora.im>
18:04:36
alrighty, thanks a lot folks!
<@adamwill:fedora.im>
18:04:40
see you next bat time
<@adamwill:fedora.im>
18:04:42
!endmeeting