<@adamwill:fedora.im>
18:00:38
!startmeeting F44 Final Go/No-Go meeting
<@meetbot:fedora.im>
18:00:39
Meeting started at 2026-04-16 18:00:38 UTC
<@meetbot:fedora.im>
18:00:39
The Meeting name is 'F44 Final Go/No-Go meeting'
<@adamwill:fedora.im>
18:00:46
!topic Roll Call
<@jlinton:fedora.im>
18:00:48
!hi
<@zodbot:fedora.im>
18:00:49
Jeremy Linton: Jeremy Linton (jlinton)
<@adamwill:fedora.im>
18:00:50
who's around for go/no-go fun?
<@nirik:matrix.scrye.com>
18:00:54
cool. Morning all
<@boniboyblue:fedora.im>
18:00:57
!hi
<@korora:fedora.im>
18:01:00
!hi
<@zodbot:fedora.im>
18:01:00
Christopher Boni: Christopher Boni (boniboyblue)
<@zodbot:fedora.im>
18:01:01
Jocelyn (she/her) (Server WG: Docs) (UTC -5): Jocelyn Gould (korora) - she / her / hers
<@geraldosimiao:matrix.org>
18:01:04
!hi
<@joshuastrobl:matrix.org>
18:01:04
!hi
<@derekenz:fedora.im>
18:01:06
!hi
<@zodbot:fedora.im>
18:01:06
geraldosimiao: Geraldo S. Simião Kutz (geraldosimiao) - he / him / his
<@zodbot:fedora.im>
18:01:06
Joshua Strobl: Joshua Strobl (joshstrobl) - he / him / his
<@zodbot:fedora.im>
18:01:07
Derek Enz: Derek Enz (derekenz)
<@lruzicka:fedora.im>
18:01:25
!hi
<@zodbot:fedora.im>
18:01:29
Lukáš Růžička: Lukáš Růžička (lruzicka)
<@adamwill:fedora.im>
18:01:46
!hi
<@psklenar:fedora.im>
18:01:51
!hi
<@willy:fedora.im>
18:01:56
!hi
<@zodbot:fedora.im>
18:02:06
adamw: Adam Williamson (adamwill) - he / him / his
<@zodbot:fedora.im>
18:02:09
Petr Sklenar: Petr Sklenar (psklenar)
<@nirik:matrix.scrye.com>
18:02:21
oh sure, why not...
<@nirik:matrix.scrye.com>
18:02:23
!hi
<@zodbot:fedora.im>
18:02:28
nirik: Kevin Fenzi (kevin) - he / him / his
<@adamwill:fedora.im>
18:03:17
3. Test matrices are fully completed
<@adamwill:fedora.im>
18:03:17
2. No remaining blocker bugs
<@adamwill:fedora.im>
18:03:17
1. Release candidate compose is available
<@adamwill:fedora.im>
18:03:17
!info This is determined in a few ways:
<@adamwill:fedora.im>
18:03:17
!topic Purpose of this meeting
<@adamwill:fedora.im>
18:03:17
4. Fedora CoreOS and IoT are ready
<@adamwill:fedora.im>
18:03:17
!info Purpose of this meeting is to check whether or not F44 Final is ready for shipment, according to the release criteria.
<@adamwill:fedora.im>
18:03:41
...guess the script needs a tweak there. oh well
<@adamwill:fedora.im>
18:03:42
!topic Current status - RC
<@marmijo:fedora.im>
18:03:43
!hi
<@adamwill:fedora.im>
18:03:49
we do, indeed, have an RC!
<@zodbot:fedora.im>
18:03:55
marmijo: Michael Armijo (marmijo)
<@adamwill:fedora.im>
18:03:58
https://download.fedoraproject.org/pub/alt/stage/44_RC-1.2/
<@adamwill:fedora.im>
18:04:08
!agreed RC-1.2 is available and will be discussed for release readiness
<@adamwill:fedora.im>
18:04:20
!topic Current status - blockers
<@adamwill:fedora.im>
18:04:20
!link https://qa.fedoraproject.org/blockerbugs/milestone/44/final/buglist
<@adamwill:fedora.im>
18:04:31
!info This section will be led by...also me *puts on different hat*
<@adamwill:fedora.im>
18:04:53
!topic Proposed Final blockers
<@adamwill:fedora.im>
18:04:59
!link https://bugzilla.redhat.com/show_bug.cgi?id=2458907
<@adamwill:fedora.im>
18:04:59
!info Proposed Blocker, anaconda, NEW
<@adamwill:fedora.im>
18:04:59
!link https://pagure.io/fedora-qa/blocker-review/issue/2113
<@adamwill:fedora.im>
18:04:59
!topic (2458907) Installation of the system failed: Storing configuration files and kickstarts org.fedoraproject.Anaconda.Error: 'NoneType' object has no attribute 'path'
<@adamwill:fedora.im>
18:05:44
this seems like a kinda intermittent flake
<@adamwill:fedora.im>
18:05:59
i think i have seen it once or twice myself
<@nirik:matrix.scrye.com>
18:06:01
so, this is reusing an install on btrfs on raid?
<@adamwill:fedora.im>
18:06:11
(oddly i don't recall ever seeing openqa hit it?)
<@nirik:matrix.scrye.com>
18:06:30
yeah, probibly some kind of race?
<@adamwill:fedora.im>
18:06:38
no, not reuse, reformat
<@lruzicka:fedora.im>
18:06:44
this is reusing /boot and /boot/efi and creating RAID 0 on top of partitions
<@adamwill:fedora.im>
18:06:49
(oh, yeah, that's probably why openqa doesn't see it, we don't really do that)
<@nirik:matrix.scrye.com>
18:07:37
while this would be good to fix, I don't think it's blocker worthy... not always happening and a case not many people use. So, -1 blocker, +1 FE
<@adamwill:fedora.im>
18:07:44
yeah, that's kinda where I am
<@lruzicka:fedora.im>
18:07:53
to me it seems like a race condition, the exact same scenario succeeded next time
<@adamwill:fedora.im>
18:07:59
i always feel a bit nervous giving late FEs for storage code, but mmf
<@lruzicka:fedora.im>
18:08:09
I kept it for this discussion just in case
<@lruzicka:fedora.im>
18:09:17
I would go even further with -1 FB and -1 FE. The fix could land post release.
<@adamwill:fedora.im>
18:09:39
other votes?
<@conan_kudo:matrix.org>
18:10:02
!hi
<@zodbot:fedora.im>
18:10:04
Conan Kudo 🤢: Neal Gompa (ngompa) - he / him / his
<@geraldosimiao:matrix.org>
18:10:05
this is the kickstart bug right?
<@nirik:matrix.scrye.com>
18:10:09
The fix seems pretty simple...
<@lruzicka:fedora.im>
18:10:10
Hi, Conan
<@derekenz:fedora.im>
18:10:25
Simple fix?
<@conan_kudo:matrix.org>
18:10:45
this reasoning doesn't make sense
<@adamwill:fedora.im>
18:10:51
no, nothing to do with kickstart?
<@conan_kudo:matrix.org>
18:10:52
we don't officially publish respins on the website
<@conan_kudo:matrix.org>
18:11:06
anaconda won't ship fixes post-GA without serious pushing
<@adamwill:fedora.im>
18:11:14
post-release installer fix is fairly useless, yeah
<@adamwill:fedora.im>
18:11:25
lukas may have just meant it's fine for it to be fixed in f45 though
<@lruzicka:fedora.im>
18:11:26
Yeah, true.
<@nirik:matrix.scrye.com>
18:11:32
well, it is useful for the next release in any case
<@conan_kudo:matrix.org>
18:11:40
then I would leave it as a blocker
<@conan_kudo:matrix.org>
18:11:43
+1 FB
<@nirik:matrix.scrye.com>
18:11:48
anyhow, we are sidetracking. ;)
<@conan_kudo:matrix.org>
18:11:56
doesn't mean we can't waive it, but ignoring the broken isn't okay with me
<@adamwill:fedora.im>
18:12:21
how do you mean "leave" it as a blocker?
<@conan_kudo:matrix.org>
18:12:41
if it isn't going to be fixed for F44, then it automatically moves to F45
<@geraldosimiao:matrix.org>
18:12:45
I'm not sure about it, but I'm more a +1 FB
<@conan_kudo:matrix.org>
18:12:48
as a blocker
<@lruzicka:fedora.im>
18:12:51
Take it as a final blocker and waive it if needed -> so that it stays for 45
<@nirik:matrix.scrye.com>
18:12:58
well, it's not a blocker. we are voting on that now. ;)
<@adamwill:fedora.im>
18:13:12
right...and the first votes were all -1
<@geraldosimiao:matrix.org>
18:13:20
yeah, I think whe should grant it FB for now
<@boniboyblue:fedora.im>
18:13:23
I'm FB+1
<@lruzicka:fedora.im>
18:13:35
But it does not happen all the time, so even if the error is there, users do not have to hit that.
<@geraldosimiao:matrix.org>
18:13:35
+1 FB
<@adamwill:fedora.im>
18:13:39
why are people suddenly +1? what's the rationale? i don't see an argument yet
<@conan_kudo:matrix.org>
18:13:52
well I just got here
<@derekenz:fedora.im>
18:14:02
Hmmmm
<@adamwill:fedora.im>
18:14:11
it's a rarely-occurring flake that goes away if you reboot and try again
<@lruzicka:fedora.im>
18:14:17
The problem is that I did the scenario three times and only hit it the first time
<@conan_kudo:matrix.org>
18:14:18
but bugs that result in failed installs are usually blockery to me
<@adamwill:fedora.im>
18:14:19
doesn't really feel blockery to me
<@nirik:matrix.scrye.com>
18:14:25
I am still -1 blocker, +1 FB (in case we slip for something else, it might be nice to fix this as the fix is small and pretty self contained)
<@geraldosimiao:matrix.org>
18:14:39
"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. "
<@geraldosimiao:matrix.org>
18:14:39
https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Disk_layouts
<@boniboyblue:fedora.im>
18:14:57
A failed installation, even if just one times out of three, is still pretty bad to me.
<@adamwill:fedora.im>
18:15:04
geraldosimiao well it can, like 99/100 tries :)
<@derekenz:fedora.im>
18:15:09
So its rare?
<@lruzicka:fedora.im>
18:15:12
It is capable indeed (in 66 percents)
<@lruzicka:fedora.im>
18:15:32
It is capable indeed (in 66 percents in my trials)
<@adamwill:fedora.im>
18:15:38
Derek Enz i guess we don't have data to say for sure, but i run a lot of installs and i've seen this or something like it...maybe two or three times?
<@geraldosimiao:matrix.org>
18:15:40
ohh, its occurs only sometimes?
<@geraldosimiao:matrix.org>
18:15:50
the bug?
<@derekenz:fedora.im>
18:15:52
FB -1 FE +1
<@joshuastrobl:matrix.org>
18:16:14
Not only rare but is this a common disk configuration to begin with, writing on top of an existing /boot rather than just wiping away and installing fresh?
<@adamwill:fedora.im>
18:16:15
i mean, if we're just blocking on any occasional anaconda crash, there's all the ones here to look through - https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&classification=Fedora&component=anaconda&list_id=13666245&product=Fedora&product=Fedora%20EPEL
<@boniboyblue:fedora.im>
18:16:25
Just looking at rhbz I can also see quite a few bug reports of this same issue.
<@adamwill:fedora.im>
18:16:29
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&classification=Fedora&component=anaconda&list_id=13666245&product=Fedora&product=Fedora%20EPEL
<@adamwill:fedora.im>
18:16:29
```
<@adamwill:fedora.im>
18:16:29
i mean, if we're just blocking on any occasional anaconda crash, there's all the ones here to look through
<@adamwill:fedora.im>
18:16:29
```
<@adamwill:fedora.im>
18:17:17
several of them are probably this, yeah
<@lruzicka:fedora.im>
18:17:32
If one reuses an existing partition and reformats it should not make any difference to deleting it and recreating with same settings
<@adamwill:fedora.im>
18:18:01
i see four there on the first page. 2 for 43, 2 for 44
<@psklenar:fedora.im>
18:18:14
I'm more like FB -1 ; maybe it could affect anyone but it seems you can solve by repartitioning
<@sgallagh:fedora.im>
18:18:25
I’m 0 FB, +1 FE
<@boniboyblue:fedora.im>
18:18:30
I've got 10: https://bugzilla.redhat.com/buglist.cgi?quicksearch=component%3Danaconda%20version%3D44%20NoneType&list_id=13666187
<@derekenz:fedora.im>
18:18:43
Sigh
<@lruzicka:fedora.im>
18:18:49
You can solve it by restarting Anaconda and retrying the exact same steps :D
<@geraldosimiao:matrix.org>
18:19:24
we have in other times granted FB status to bugs that affect a critrion, and then we waive them because theire rare and so...
<@derekenz:fedora.im>
18:19:39
Good point
<@conan_kudo:matrix.org>
18:19:53
right and that's why I voted it as a blocker
<@geraldosimiao:matrix.org>
18:19:54
but ok, we can also just skip that and not grant the FB status now
<@conan_kudo:matrix.org>
18:19:57
because that is the right thing to do
<@geraldosimiao:matrix.org>
18:20:05
ok, yeah
<@geraldosimiao:matrix.org>
18:20:14
we have a clear criterion
<@adamwill:fedora.im>
18:20:20
geraldosimiao yes, we can do that, but we can also decide whether this one is a blocker :) that comes first
<@geraldosimiao:matrix.org>
18:20:25
it affects this criterion
<@adamwill:fedora.im>
18:20:30
opinion is split
<@derekenz:fedora.im>
18:20:42
FB 0 FE +1
<@lruzicka:fedora.im>
18:20:53
The problem for me is that it only sometimes breaks the criterion.
<@lruzicka:fedora.im>
18:21:32
Personally, I have seen this just exactly once today in all installations I have done so far in F44.
<@adamwill:fedora.im>
18:21:34
there are 31 'NoneType' object has no attribute 'path' bugs in total it looks like - https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&component=anaconda&list_id=13666248&order=id%2C%20&product=Fedora&query_format=advanced&short_desc=%27NoneType%27%20object%20has%20no%20attribute%20%27path%27&short_desc_type=substring
<@nirik:matrix.scrye.com>
18:21:35
It's IMHO not a case too many people would hit.... in fact, people testing the rc's would normally hit it more (doing lots of installs)
<@geraldosimiao:matrix.org>
18:21:37
I'm still +1 FB (and latter waive it using the "rare" argument)
<@adamwill:fedora.im>
18:21:43
there are 31 'NoneType' object has no attribute 'path' bugs in total it looks like - `https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&component=anaconda&list_id=13666248&order=id%2C%20&product=Fedora&query_format=advanced&short_desc=%27NoneType%27%20object%20has%20no%20attribute%20%27path%27&short_desc_type=substring`
<@adamwill:fedora.im>
18:21:48
that does seem like quite a lot
<@adamwill:fedora.im>
18:22:19
(and that's only NEW and ASSIGNED ones I guess, some have been closed as dupes already)
<@derekenz:fedora.im>
18:22:47
Rare but sometimes for some folks all it takes is one time
<@adamwill:fedora.im>
18:23:44
seeing if katerina is around
<@conan_kudo:matrix.org>
18:23:50
it's also a destructive failure because it happens close to the end of the install process
<@conan_kudo:matrix.org>
18:24:07
I don't remember the exact steps so I'm not sure if it's before or after initramfs is generated
<@geraldosimiao:matrix.org>
18:24:14
so it seems we have allot of anaconda bugs, or its mainly variations of this same bug
<@conan_kudo:matrix.org>
18:24:19
I don't remember the exact steps so I'm not sure if it's before or after initramfs/bootloader config is generated
<@adamwill:fedora.im>
18:24:20
meh, i mean, you obviously wanted to destroy whatever it destroyed anyway...
<@adamwill:fedora.im>
18:24:33
i suspect all of those are *likely* the same
<@nirik:matrix.scrye.com>
18:24:34
well, you are reformatting your install, so yeah, it's destructive.
<@adamwill:fedora.im>
18:24:46
but i'm asking katerina
<@geraldosimiao:matrix.org>
18:25:01
if its the same bug or related to it, its not so rare.
<@nirik:matrix.scrye.com>
18:25:08
I think some of those are another bug around storing the kickstart?
<@adamwill:fedora.im>
18:25:19
oh hmm, right
<@nirik:matrix.scrye.com>
18:25:40
oh, perhaps it is the same one. not clear
<@adamwill:fedora.im>
18:25:54
let me see
<@adamwill:fedora.im>
18:25:58
about half of them mention kickstarts
<@nirik:matrix.scrye.com>
18:26:55
yeah, the kickstart mentioning ones are this bug, the others are other I think... like other installs.
<@nirik:matrix.scrye.com>
18:27:49
so I think 9 of them are this bug? but it's hard to be sure.
<@adamwill:fedora.im>
18:28:06
it's a two page result
<@adamwill:fedora.im>
18:28:10
there's 4 on the second page
<@adamwill:fedora.im>
18:28:31
the github fix does seem specifc to kickstarts
<@nirik:matrix.scrye.com>
18:28:44
ok, 13 then
<@aggraxis:fedora.im>
18:29:18
!hi
<@zodbot:fedora.im>
18:29:19
Paul Maconi (Aggraxis): Paul Maconi (aggraxis) - he / him / his
<@adamwill:fedora.im>
18:29:31
i think at least some of the others are the same
<@adamwill:fedora.im>
18:29:51
they seem to be ones where the report doesn't have logs attached for some reason, but in e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2445989 you can see we're in org.fedoraproject.Anaconda.Modules.GenerateKickstart
<@adamwill:fedora.im>
18:30:42
https://bugzilla.redhat.com/show_bug.cgi?id=2445392 the later-attached log is also in GenerateKickstart
<@adamwill:fedora.im>
18:30:57
so...yeah, i think probably all of them are this. so, humm. 31 reports does feel like kinda a lot. i feel a bit more +1y
<@nirik:matrix.scrye.com>
18:32:03
I suppose... I guess most people wouldn't bother to file.
<@adamwill:fedora.im>
18:32:21
and the people who did file often seem fairly annoyed about it
<@adamwill:fedora.im>
18:32:45
can everyone vote again so i don't have to look through acres of scrollback? :D
<@nirik:matrix.scrye.com>
18:32:54
understanadably.
<@nirik:matrix.scrye.com>
18:33:28
understandably
<@boniboyblue:fedora.im>
18:33:47
FB +1
<@sgallagh:fedora.im>
18:33:50
I guess I'm coming down on the +1 side, given the number of reports
<@sgallagh:fedora.im>
18:33:59
I guess I'm coming down on the +1 FB side, given the number of reports
<@derekenz:fedora.im>
18:34:10
FB +1
<@conan_kudo:matrix.org>
18:34:18
+1 FB
<@nirik:matrix.scrye.com>
18:34:23
I guess I can be a weak +1 blocker given the numbers. Still don't think it's super common and it doesn't happen all the time either... but I suppose we should squash it.
<@adamwill:fedora.im>
18:34:29
i guess i'm +0.342
<@korora:fedora.im>
18:34:32
FB +1
<@conan_kudo:matrix.org>
18:34:37
there's already a fix prepared
<@conan_kudo:matrix.org>
18:34:41
it just needs to land
<@nirik:matrix.scrye.com>
18:34:50
well, and actually be tested to fix it. ;)
<@conan_kudo:matrix.org>
18:35:06
get Kamil to test it
<@adamwill:fedora.im>
18:35:09
we have no time to land anything without a slip at this point, just to be clear
<@conan_kudo:matrix.org>
18:35:11
he hits all the fun breakages
<@nirik:matrix.scrye.com>
18:35:45
right.
<@nirik:matrix.scrye.com>
18:36:06
(but we could use the 'late blocker' clause)
<@adamwill:fedora.im>
18:36:32
proposed !agreed 2458907 - AcceptedBlocker (Final) - this is accepted as a conditional 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" (and other storage-y criteria). It doesn't happen every time even to affected scenarios, but we believe there are 31 open reports of this, which feels like a lot, enough to justify blocker status
<@lruzicka:fedora.im>
18:36:33
Kamil is ill.
<@aggraxis:fedora.im>
18:36:37
FB +1. Dude, some of these reports, though...
<@derekenz:fedora.im>
18:36:45
ack
<@lruzicka:fedora.im>
18:36:49
ack
<@geraldosimiao:matrix.org>
18:36:51
ack
<@nirik:matrix.scrye.com>
18:36:51
ack
<@aggraxis:fedora.im>
18:36:52
ack
<@conan_kudo:matrix.org>
18:36:52
ack
<@boniboyblue:fedora.im>
18:36:56
ack
<@adamwill:fedora.im>
18:37:05
!agreed 2458907 - AcceptedBlocker (Final) - this is accepted as a conditional 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" (and other storage-y criteria). It doesn't happen every time even to affected scenarios, but we believe there are 31 open reports of this, which feels like a lot, enough to justify blocker status
<@adamwill:fedora.im>
18:37:13
!link https://pagure.io/fedora-qa/blocker-review/issue/2109
<@adamwill:fedora.im>
18:37:13
!info Proposed Blocker, grub2, NEW
<@adamwill:fedora.im>
18:37:13
!topic (2457333) Grub environment block is corrupted at first boot
<@adamwill:fedora.im>
18:37:13
!link https://bugzilla.redhat.com/show_bug.cgi?id=2457333
<@nirik:matrix.scrye.com>
18:37:15
yes, people are sometimes horrible. ;(
<@adamwill:fedora.im>
18:38:12
i actually see the error messages at least on some x86_64 VM installs too
<@sgallagh:fedora.im>
18:38:20
It's me. I'm people.
<@adamwill:fedora.im>
18:38:22
pretty sure i saw them on both virtualbox and vmware install tests I just did
<@adamwill:fedora.im>
18:38:31
this guy
<@conan_kudo:matrix.org>
18:38:45
anokata!
<@derekenz:fedora.im>
18:38:57
Same here
<@adamwill:fedora.im>
18:39:00
Jeremy Linton are we actually sure this is "keeping the grub menu from showing up", though?
<@nirik:matrix.scrye.com>
18:39:04
soylent fedora is people! :) sorry... I digress.
<@conan_kudo:matrix.org>
18:39:06
yeah I saw it today when doing some testing for a kernel bug
<@adamwill:fedora.im>
18:39:08
i thought we intentionally hide it on workstation unless the previous boot failed
<@jlinton:fedora.im>
18:39:26
Its hard to get into when it throws that message, so....
<@conan_kudo:matrix.org>
18:39:41
it doesn't prevent the menu from working for me though
<@conan_kudo:matrix.org>
18:39:43
it's just an extra message
<@jlinton:fedora.im>
18:40:07
And it gets fixed if you remove the enviroment block stanza in the grubenv, so? The worrying part is that it looks like a random sector offset.
<@adamwill:fedora.im>
18:40:35
i'm mostly interested in the *practical consequence*
<@adamwill:fedora.im>
18:40:49
like is this actually making it harder to get into the boot menu when you need to, or does workstation just make that hard anyway
<@jlinton:fedora.im>
18:40:53
You can get into the menu, it just requires hitting esc/whatever at exactly the right moment to avoid landing in the bios menu, but getting into the grub one.
<@conan_kudo:matrix.org>
18:41:15
this is generally hard on desktop installs regardless of the message
<@nirik:matrix.scrye.com>
18:41:18
you should be able to hold down control or shift to get into it too... at least thats always worked for me
<@conan_kudo:matrix.org>
18:41:23
ironically the message lengthens the window to get in slightly
<@sgallagh:fedora.im>
18:41:47
s/ironically/fortunately/
<@conan_kudo:matrix.org>
18:41:55
:D
<@lruzicka:fedora.im>
18:42:01
I have been seeing similar errors for a couple of years. These are cosmetics, never prevent the menu from showing or system from running (in my experience)
<@nirik:matrix.scrye.com>
18:42:30
yeah, same here I have seen them, but they don't seem to actually break anything.
<@conan_kudo:matrix.org>
18:42:39
for a while in Fedora Asahi Remix we used the hidden mode before switching to this mode for hiding the menu... hidden mode tells you that you can press a button to activate the menu
<@nirik:matrix.scrye.com>
18:42:40
they look bad tho. ;)
<@lruzicka:fedora.im>
18:42:43
The very first I reported to GRUB when Jan Hlavac was around.
<@jlinton:fedora.im>
18:43:09
Well the envorment block is used for last boot selection, and timeouts, right? Basically boot persisted data?
<@derekenz:fedora.im>
18:43:25
Yeah the Welcome to Grub moves down pretty quickly
<@jlinton:fedora.im>
18:43:27
so none of that should "break" the boot, just make it boot the wrong kernel, etc.
<@adamwill:fedora.im>
18:43:31
i'm not sure the timeout is actually configured in grubenv? i thought it was in the regular config?
<@nirik:matrix.scrye.com>
18:43:37
and if the boot was successful?
<@conan_kudo:matrix.org>
18:43:51
it's in grubenv
<@adamwill:fedora.im>
18:43:56
ah, ok
<@jlinton:fedora.im>
18:43:56
and should it decide to write, potentially corrupt the filesystem? I'm not sure why it thinkgs 512 sectors is a good place to write.
<@conan_kudo:matrix.org>
18:43:59
and grub default
<@conan_kudo:matrix.org>
18:44:15
the good news is that it's not actually corrupted
<@jlinton:fedora.im>
18:44:19
thats what I thought, but this seems to be changing that?
<@conan_kudo:matrix.org>
18:44:22
the bad news is I know what's wrong
<@conan_kudo:matrix.org>
18:44:42
the bootloader folks reached out to me yesterday evening about it and I gave them guidance on the fix
<@adamwill:fedora.im>
18:44:47
so far i'm feeling -1y
<@conan_kudo:matrix.org>
18:44:51
it's basically failing because /boot is ext4
<@conan_kudo:matrix.org>
18:45:02
it falls back to the grubenv file because there is no envblock driver for ext4
<@nirik:matrix.scrye.com>
18:45:02
so... I wonder if the 'successfull boot' thing is breaking it.
<@conan_kudo:matrix.org>
18:45:06
but it flips out on it
<@conan_kudo:matrix.org>
18:45:39
the fix is basically an update to the grub modules to check really hard that boot data is on btrfs before opening the envblock
<@conan_kudo:matrix.org>
18:45:57
Leo Sandoval has a WIP patch to fix it
<@conan_kudo:matrix.org>
18:46:26
the fix is basically an update to the grub modules to check really hard that boot data is on btrfs before attempting to open the envblock
<@derekenz:fedora.im>
18:47:06
Well theres a fix at least
<@nirik:matrix.scrye.com>
18:47:17
anyhow, does this do anything more than print an anoying error message? Does it break anything?
<@lruzicka:fedora.im>
18:47:41
I do not think so.
<@conan_kudo:matrix.org>
18:47:43
nope
<@conan_kudo:matrix.org>
18:47:48
it just prints an annoying message
<@derekenz:fedora.im>
18:47:54
Just prints the error
<@korora:fedora.im>
18:47:56
The bug report says it keeps the menu from showing up
<@conan_kudo:matrix.org>
18:48:04
this is the WIP patch he's working on: https://src.fedoraproject.org/fork/lsandova/rpms/grub2/c/c67c2d27109f6f6ed8c841915aecdae6d7356319
<@adamwill:fedora.im>
18:48:43
so long as we don't have any evidence this actually makes getting into the menu harder or corrupts filesystems or anything, i'm -1
<@conan_kudo:matrix.org>
18:49:04
-1 FB +1 FE
<@lruzicka:fedora.im>
18:49:17
I am -1 fb, too. +1 common bugs
<@nirik:matrix.scrye.com>
18:49:21
well, Jeremy Linton said it did in the bug? or is that just our defaults causing doom?
<@adamwill:fedora.im>
18:49:39
i think so, yeah
<@korora:fedora.im>
18:49:41
-1 fb / +1 fe
<@derekenz:fedora.im>
18:49:49
Yeah FB -1 FE +1
<@adamwill:fedora.im>
18:49:58
the rest of us are saying he's wrong and it's just only as hard as it is on workstation (and anything else that does menu_auto_hide) anyway
<@sgallagh:fedora.im>
18:50:00
-1 FB / -1 FE
<@nirik:matrix.scrye.com>
18:50:16
I'm -1 blocker bug based on it not causing any actual doom.
<@sgallagh:fedora.im>
18:50:22
I don't want us taking a patch to GRUB that only addresses an aesthetic issue this late
<@nirik:matrix.scrye.com>
18:50:48
I'm not understanding how that patch fixes this, but we don't have to try and explain it to me here. ;)
<@conan_kudo:matrix.org>
18:52:03
it makes it so the call is never made to the envblock if not btrfs
<@conan_kudo:matrix.org>
18:52:16
so the error doesn't happen because it never tries to do something unsupported
<@adamwill:fedora.im>
18:52:31
proposed !agreed 2457333 - RejectedBlocker (Final) - this is rejected on the basis we don't believe it has serious practical consequences beyond the ugly errors; it was suggested that it makes getting into the grub menu harder, but we don't think that's true, we think it's only as hard as it always has been on installs that use menu_auto_hide. We will leave FE decision to happen async
<@conan_kudo:matrix.org>
18:52:36
ack
<@adamwill:fedora.im>
18:52:39
(FE vote is a bit split, let's not spend time on it here)
<@lruzicka:fedora.im>
18:52:39
ack
<@derekenz:fedora.im>
18:52:40
ack
<@psklenar:fedora.im>
18:52:47
ack
<@korora:fedora.im>
18:52:47
ack
<@nirik:matrix.scrye.com>
18:52:49
ack
<@aggraxis:fedora.im>
18:52:54
ack
<@boniboyblue:fedora.im>
18:52:58
ack
<@adamwill:fedora.im>
18:53:08
!agreed 2457333 - RejectedBlocker (Final) - this is rejected on the basis we don't believe it has serious practical consequences beyond the ugly errors; it was suggested that it makes getting into the grub menu harder, but we don't think that's true, we think it's only as hard as it always has been on installs that use menu_auto_hide. We will leave FE decision to happen async
<@adamwill:fedora.im>
18:53:34
hmm, let me do something flashy
<@geraldosimiao:matrix.org>
18:53:35
ack
<@adamwill:fedora.im>
18:53:46
!topic (2441941) Graphics break when trying to type LUKS password and (2455924) ThinkPad X1 Carbon Gen 13: black screen when typing LUKS password
<@adamwill:fedora.im>
18:53:50
!link https://bugzilla.redhat.com/show_bug.cgi?id=2441941
<@adamwill:fedora.im>
18:53:52
!link https://bugzilla.redhat.com/show_bug.cgi?id=2455924
<@geraldosimiao:matrix.org>
18:54:04
👀
<@adamwill:fedora.im>
18:54:04
!link https://pagure.io/fedora-qa/blocker-review/issue/2047
<@adamwill:fedora.im>
18:54:08
!link https://pagure.io/fedora-qa/blocker-review/issue/2097
<@adamwill:fedora.im>
18:54:12
!info Proposed Blocker, kernel, NEW (both)
<@adamwill:fedora.im>
18:54:31
!info Ticket vote: BetaBlocker (+2,0,-0) (+nielsenb, +psklenar) (2441941) FinalBlocker (+3,0,-0) (+pstourac, +asciiwolf, +psklenar) (2455924)
<@adamwill:fedora.im>
18:54:47
these are very similar but we're not sure yet whether they're the same
<@adamwill:fedora.im>
18:55:03
they're both basically 'i can't see when typing the encryption passphrase', but they differ in details
<@adamwill:fedora.im>
18:55:40
there are various references in each to *other* similar problems too, including https://bugzilla.redhat.com/show_bug.cgi?id=2438727 and https://bugzilla.redhat.com/show_bug.cgi?id=2430613
<@sgallagh:fedora.im>
18:55:54
You can't see, but you can still type the password and have it accepted, right?
<@adamwill:fedora.im>
18:56:00
i'm finding it pretty hard to make up my mind on these. it does feel like there's *something* going on
<@korora:fedora.im>
18:56:08
That's the way it sounds
<@psklenar:fedora.im>
18:56:10
right
<@adamwill:fedora.im>
18:56:19
well yes, but it's pretty non-obvious what's going on unless you're quite familiar with the boot process and make an educated guess
<@adamwill:fedora.im>
18:56:36
the case where the screen is frozen and keypresses aren't echoed feels less bad, but 'the screen is entirely blank' is...badf
<@adamwill:fedora.im>
18:56:40
the case where the screen is frozen and keypresses aren't echoed feels less bad, but 'the screen is entirely blank' is...bad
<@conan_kudo:matrix.org>
18:57:00
back when I had a redhat laptop that was docked, I'm pretty sure I had this issue
<@nirik:matrix.scrye.com>
18:57:15
I wonder... if you hit esc and go to text entry does that work?
<@adamwill:fedora.im>
18:57:32
i wish i had an affected laptop :/
<@conan_kudo:matrix.org>
18:57:35
so it's not _new_ to me
<@sgallagh:fedora.im>
18:57:42
I haven't been able to reproduce this with any of my hardware, but I guess it sounds like it only happens on high-refresh screens?
<@adamwill:fedora.im>
18:57:46
we do have two affected RHers, which *should* help
<@conan_kudo:matrix.org>
18:57:49
so it's not _new_ to me (since that laptop was years old)
<@adamwill:fedora.im>
18:57:51
Petr Sklenar are you around or is it too late?
<@psklenar:fedora.im>
18:58:25
I am here, but not with the laptop, I had it for two days only
<@psklenar:fedora.im>
18:58:36
I am here, but not with the affected laptop, I had it for two days only
<@adamwill:fedora.im>
18:59:01
that's part of the awkwardness, it's hard to find patterns. the xps 13 pro case is not higher refresh rate, but it also seems a bit different from petr's case. vit's case may well be the same as petr's but i'm not totally sure. https://bugzilla.redhat.com/show_bug.cgi?id=2430613 is AMD hardware so might be a bit different again?
<@derekenz:fedora.im>
18:59:07
X1 laptop?
<@adamwill:fedora.im>
18:59:21
can you get it back?
<@psklenar:fedora.im>
18:59:29
ThinkPad X1 Carbon Gen 13 , 120hz display
<@psklenar:fedora.im>
18:59:42
I can , next week
<@adamwill:fedora.im>
18:59:54
ok, so we at least have a shot at trying to debug *your* case, if we slip
<@adamwill:fedora.im>
19:00:18
i just wish we had a bit more data, it's so hard to parse atm
<@nirik:matrix.scrye.com>
19:00:36
yeah, seems all over the place... ;(
<@conan_kudo:matrix.org>
19:00:44
alas my old P1 was 90Hz display and had the problem
<@conan_kudo:matrix.org>
19:00:51
don't have it anymore since it was never my laptop
<@conan_kudo:matrix.org>
19:01:29
but if anyone has one of those P1s from 2021~2023, they might also have it
<@adamwill:fedora.im>
19:01:49
https://bugzilla.redhat.com/show_bug.cgi?id=2387045 is another similar thing, filed on kernel 6.15 on f42, a commenter says "reproduced" on an nvidia GPU on kernel 6.18...
<@adamwill:fedora.im>
19:02:05
https://bugzilla.redhat.com/show_bug.cgi?id=2387045 is another similar thing, filed on kernel 6.15 on f42, a commenter says "reproduced" on an nvidia GPU on kernel 6.18 on f43...
<@nirik:matrix.scrye.com>
19:02:22
I mean, the common thing is plymouth perhaps?
<@adamwill:fedora.im>
19:02:29
on the whole i'd lean very slightly towards -1 as too hardware-specific and slippery to pin down, but...
<@adamwill:fedora.im>
19:02:39
well, i mean, only in the sense that plymouth is *always* involved in this path, no?
<@adamwill:fedora.im>
19:02:46
i am a bit curious whether minimal installs are affected
<@conan_kudo:matrix.org>
19:02:47
this is not a new problem either
<@adamwill:fedora.im>
19:02:53
as they either don't have plymouth or don't use the graphical mode (I forget which)
<@conan_kudo:matrix.org>
19:03:05
my Framework 16 is affected
<@conan_kudo:matrix.org>
19:03:19
which is a dual-GPU amd+amd setup
<@conan_kudo:matrix.org>
19:03:25
I just ignore it
<@adamwill:fedora.im>
19:03:32
https://bugzilla.redhat.com/show_bug.cgi?id=2387045 is another similar thing, filed on kernel 6.15 on f42 with an intel/nvidia hybrid system, a commenter says "reproduced" on an nvidia-only system on kernel 6.18 on f43...
<@nirik:matrix.scrye.com>
19:03:52
I'm also inclined to -1 at this point...but more data would be nice.
<@adamwill:fedora.im>
19:03:52
i mean, we still don't know if these are even all the same problem or lots of different bugs with the same symptom :/
<@adamwill:fedora.im>
19:04:09
other votes?
<@adamwill:fedora.im>
19:04:28
https://bugzilla.redhat.com/show_bug.cgi?id=2444365 looks like another nvidia case
<@conan_kudo:matrix.org>
19:04:43
do we have actual openqa tests for LUKS?
<@adamwill:fedora.im>
19:04:46
"when a Nvidia card is set for the display and no other driver (than simpledrm) can use it...The current situation is a black display without any prompt"
<@conan_kudo:matrix.org>
19:04:48
with plymouth
<@adamwill:fedora.im>
19:05:01
Conan Kudo 🤢 yes, but openqa is virtio graphics on a vm, pretty different from real hardware
<@conan_kudo:matrix.org>
19:05:08
yeah
<@lruzicka:fedora.im>
19:05:11
We have some. They were not failing.
<@korora:fedora.im>
19:05:18
I'm -1. This sounds hardware specific with certian configs
<@conan_kudo:matrix.org>
19:05:19
I currently turn off simpledrm on my laptop so plymouth loads properly
<@conan_kudo:matrix.org>
19:05:33
I'm -1 FB but should be documented
<@adamwill:fedora.im>
19:05:50
documenting would be easier if i knew what the hell to write :P
<@korora:fedora.im>
19:05:58
I agree with Conan that it should be documented.
<@adamwill:fedora.im>
19:06:00
"just keep typing your password until morale improves"
<@derekenz:fedora.im>
19:06:14
LOL
<@lruzicka:fedora.im>
19:06:26
If you do not see anything after boot, just type your LUKS password and hit enter :D
<@conan_kudo:matrix.org>
19:06:28
turning off simpledrm fixes a lot of these issues from my own testing
<@conan_kudo:matrix.org>
19:06:44
`sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm=0"`
<@nirik:matrix.scrye.com>
19:07:06
that would be another good datapoint to get from affected users.
<@sgallagh:fedora.im>
19:07:19
I'm kind of +1 FB, planning to waive on a combination of "late blocker" and "hard to fix" (since we can't reproduce it)
<@derekenz:fedora.im>
19:08:03
Leaning FB +1
<@korora:fedora.im>
19:08:35
+1 FB, with a waiver.
<@adamwill:fedora.im>
19:08:40
pvalena just posted to the bug saying that turning simpledrm *on* fixes it. *throws hands in air, walks away*
<@nirik:matrix.scrye.com>
19:08:51
well, we didn't find it late did we? I mean, lots of these are older bugs
<@adamwill:fedora.im>
19:09:10
it was proposed as a blocker fairly late, but i don't think within the meaning of the waive rules
<@adamwill:fedora.im>
19:09:57
"bugs proposed as blockers 5 days or fewer before the scheduled Go_No_Go_Meeting for a milestone release (Beta or Final) can be considered under this policy"
<@bittin_:mozilla.org>
19:10:01
are we go?
<@adamwill:fedora.im>
19:10:17
it was proposed april 7...which is 9 days before *this* meeting, but 2 days before the *originally-scheduled* one
<@adamwill:fedora.im>
19:10:24
we're not there yet
<@adamwill:fedora.im>
19:10:28
go back to bed :)
<@adamwill:fedora.im>
19:10:40
anyway, policy is we discuss blocker status first, talk about waivers later
<@nirik:matrix.scrye.com>
19:10:48
"the bug" which one? too many tabs. ;)
<@adamwill:fedora.im>
19:11:04
right now we're at about +3 / -3
<@lruzicka:fedora.im>
19:11:05
I suppose the black screen one.
<@bittin_:mozilla.org>
19:11:09
ah sorry my Matrix was stupid
<@sgallagh:fedora.im>
19:11:10
The symptom is fairly bad and it seems to affect an decent number of modern laptops.
<@adamwill:fedora.im>
19:11:14
nirik https://bugzilla.redhat.com/show_bug.cgi?id=2455924
<@derekenz:fedora.im>
19:11:38
Yeah not good
<@adamwill:fedora.im>
19:11:39
unfortunately we can't really punt from this meeting, so we're all going to sit here till enough people vote or change their vote. :P
<@sgallagh:fedora.im>
19:11:40
On the other hand, we have apparently no idea why it's happening or even a good idea of what hardware
<@nirik:matrix.scrye.com>
19:12:21
or even if it's all the same thing
<@lruzicka:fedora.im>
19:12:21
I am -1 FB, document and suggest the grubby config workaround
<@conan_kudo:matrix.org>
19:12:21
yeah, I would say it sucks and blockery, but I have no idea wtf is wrong
<@adamwill:fedora.im>
19:12:24
it's also not clear this is anything new in f44, which is also a factor in evaluating a subjective case like this
<@conan_kudo:matrix.org>
19:12:34
it's _definitely_ not new
<@psklenar:fedora.im>
19:12:34
that's my first concerns about new users, buying new laptop and ...
<@astranovus:matrix.org>
19:12:38
can you allow dnf and discovery updates but delay the iso for a week
<@conan_kudo:matrix.org>
19:12:39
but we could have _new cases_ triggering it
<@derekenz:fedora.im>
19:12:47
Yep
<@adamwill:fedora.im>
19:12:56
Lukáš Růžička if you can find a consistent workaround in this mess of bugzilla posts, you're doing better than me :P
<@conan_kudo:matrix.org>
19:13:22
it could even be that for amd/intel, simpledrm off fixes it, but nvidia is the opposite
<@sgallagh:fedora.im>
19:13:22
The idea of a reviewer hitting this gives me agita
<@conan_kudo:matrix.org>
19:13:28
which is insane
<@lruzicka:fedora.im>
19:13:32
I even do not have the laptop. Althoug, I once had a P1 ... should try to look for it.
<@lruzicka:fedora.im>
19:13:59
I need to move to another computer now, wife heads to bed, will be back in 5
<@adamwill:fedora.im>
19:14:15
also, since we're technically discussing two bugs here: for people who are +1 , which do we want to block on? the 'probably 120Hz intel laptops we guess' one? the 'xps 13 pro whatever the heck is in that' one? the nvidia cases?
<@adamwill:fedora.im>
19:14:29
how many of those things need to be fixed to constitute the blocker being resolved?
<@adamwill:fedora.im>
19:14:52
we can go back to taking it bug-by-bug if that'd be clearer...i just kindawanted to highlight we've got a fuzzy mess of similar-but-probably-not-the-same things
<@sgallagh:fedora.im>
19:15:27
At minimum, whichever one is the "blank screen" case
<@nirik:matrix.scrye.com>
19:15:31
I mean I guess technically one the proposed one is proposed? ;)
<@derekenz:fedora.im>
19:15:40
Agree
<@korora:fedora.im>
19:15:43
What Stephen said
<@conan_kudo:matrix.org>
19:15:51
yeah black/blank screen is probably the worst
<@adamwill:fedora.im>
19:16:21
two are proposed, i set the topic to both of them
<@adamwill:fedora.im>
19:16:40
oh, hmm, i see https://src.fedoraproject.org/rpms/plymouth/c/e557f357478374dddf6d67a41724f7949a5e84b6?branch=rawhide in the plymouth history
<@nirik:matrix.scrye.com>
19:19:09
well, both of them are the blank screen case? just different hardware so it may or may not be the same issue.
<@adamwill:fedora.im>
19:19:29
the xps 13 plus one is not 'blank screen'
<@adamwill:fedora.im>
19:19:55
"the LUKS passphrase screen looks OK until I start typing the password, then the Plymouth screen disappears and the screen start flickering with a sort of blank screen"
<@nirik:matrix.scrye.com>
19:21:00
ok, and the other one just blank?
<@adamwill:fedora.im>
19:21:07
i'm kinda struggling with, ok, if we say one or both of these (or all three with the nvidia thing) are blockers, what next? turn simpledrm back on for luks? but that presumably breaks everything we previously turned it off for. if not that, what?
<@adamwill:fedora.im>
19:21:18
the intel bug reporters seem to say screen is totally blank, yeah
<@adamwill:fedora.im>
19:21:22
Petr Sklenar is that right?
<@nirik:matrix.scrye.com>
19:21:30
and also that f43 had the same issue?
<@adamwill:fedora.im>
19:21:32
you see nothing till you've blind-typed your passphrase?
<@nirik:matrix.scrye.com>
19:21:55
"I tried fedora43 without updates and the issue was there too."
<@psklenar:fedora.im>
19:23:13
no idea whats next if its blocker. Now there is no solution. I dont think there would be next week.
<@sgallagh:fedora.im>
19:24:27
Petr Sklenar: That's why my follow-up would be to waive it under the "hard to fix" exception. It would become an auto-blocker for F45 in that case.
<@nirik:matrix.scrye.com>
19:24:28
In some ways the xps13 one is worse...
<@korora:fedora.im>
19:24:51
I feel like we don't have enough specific information to fix any of these at the moment
<@lruzicka:fedora.im>
19:25:23
Can plymouth be switched off with a kernel argument?
<@adamwill:fedora.im>
19:25:27
yeah, xps 13 case is weird, it's better at boot but worse after
<@lruzicka:fedora.im>
19:25:29
Would that work?
<@adamwill:fedora.im>
19:25:43
Petr Sklenar can you see grub?
<@nirik:matrix.scrye.com>
19:26:07
you can also switch to text luks prompt with esc, but I don't know if that works around any of these cases (the screen could just stay blank)
<@adamwill:fedora.im>
19:26:25
`rd.plymouth=0` or `plymouth.enable=0` should do it
<@psklenar:fedora.im>
19:26:35
after typing password by blind, there were grub (I hope I remember well)
<@adamwill:fedora.im>
19:26:42
i doubt esc will work, i think it just goes between plymouth 'pretty' and plymouth 'ugly' these days?
<@adamwill:fedora.im>
19:27:00
Petr Sklenar no, that can't be right. grub already happened before the encryption passphrase
<@lruzicka:fedora.im>
19:27:03
Grub shoul be there first?
<@adamwill:fedora.im>
19:27:13
i'm asking whether you can see it to get into it before we reach boot (and potentially try one of those boot args)
<@adamwill:fedora.im>
19:27:31
(although of course as we just established, workstation and kde make getting into grub tricky anyway...)
<@adamwill:fedora.im>
19:27:47
i'm asking whether you can see it to get into it before we reach passphrase entry (and potentially try one of those boot args)
<@adamwill:fedora.im>
19:28:22
ok, let's try this:
<@adamwill:fedora.im>
19:28:38
!info switching to single bug topic
<@psklenar:fedora.im>
19:28:48
The first what I could see , there is blank screen for typing password
<@adamwill:fedora.im>
19:28:48
!link https://pagure.io/fedora-qa/blocker-review/issue/2097
<@adamwill:fedora.im>
19:28:48
!topic (2455924) ThinkPad X1 Carbon Gen 13: black screen when typing LUKS password
<@adamwill:fedora.im>
19:28:48
!link https://bugzilla.redhat.com/show_bug.cgi?id=2455924
<@adamwill:fedora.im>
19:28:48
!info Proposed Blocker, kernel, NEW
<@adamwill:fedora.im>
19:28:48
!info Ticket vote: FinalBlocker (+3,0,-0) (+pstourac, +asciiwolf, +psklenar)
<@nirik:matrix.scrye.com>
19:28:49
anyhow, I still don't think these are blockers because we don't have enough data to tell how widespread it is or if they are related or the like. But if everyone else wants to call em blockers, ok then
<@psklenar:fedora.im>
19:29:05
The first what I could see , there is black screen for typing password
<@adamwill:fedora.im>
19:29:16
let's consider just this one, petr's 120Hz intel laptop case (that is *probably* also vit ondruch's case)
<@adamwill:fedora.im>
19:29:33
blank screen at passphrase entry, if you blind type the password, system boots OK
<@adamwill:fedora.im>
19:29:37
are we blocking on this? votes
<@sgallagh:fedora.im>
19:30:01
+1 FB
<@derekenz:fedora.im>
19:30:08
FB +1
<@psklenar:fedora.im>
19:30:10
+1 FB
<@korora:fedora.im>
19:30:18
+1 FB
<@nirik:matrix.scrye.com>
19:30:29
-1 (because it seems limited hardware wise from what we know, and was also present in f43) but feel free to drown me out
<@conan_kudo:matrix.org>
19:31:53
+1 FB
<@korora:fedora.im>
19:32:11
I missed the part about this one being present in F43...
<@korora:fedora.im>
19:32:26
-1 FB/+1 FE
<@nirik:matrix.scrye.com>
19:32:43
sounds like folks want to mark this blocker, no worries, shall we ?
<@sp1tfire:matrix.org>
19:32:45
-1
<@mpearson:matrix.org>
19:32:47
Sorry - I was AFK - but let me know if I should be doing anything as it's one of our systems. We preloaded the Carbon 13 with Fedora - and I've not seen this complaint before
<@mpearson:matrix.org>
19:33:04
I'm mostly here to be nosy as I want to be F44 on the Carbon 14.....
<@adamwill:fedora.im>
19:33:28
mpearson is it a 120Hz model?
<@aggraxis:fedora.im>
19:33:29
-1 FB - mostly for the same reasons as kevin
<@adamwill:fedora.im>
19:33:39
(the one we sell as a preload)
<@mpearson:matrix.org>
19:33:43
Catching up to be honest - will need to go and look at the bug and check
<@adamwill:fedora.im>
19:33:47
(the one sold as a preload)
<@mpearson:matrix.org>
19:33:59
Only SKU blocked is the MIPI camera one with Fedora
<@adamwill:fedora.im>
19:34:02
also, i guess preloads aren't encrypted, right?
<@mpearson:matrix.org>
19:34:12
That probably has the high end OLED tho
<@nirik:matrix.scrye.com>
19:34:13
ha, +4/-4 so far. sheesh.
<@conan_kudo:matrix.org>
19:34:17
yeah they aren't encrypted
<@mpearson:matrix.org>
19:34:19
They are not encrypted - good point
<@adamwill:fedora.im>
19:34:43
i count +5 / -3
<@derekenz:fedora.im>
19:34:46
Thanks LOL
<@aggraxis:fedora.im>
19:34:51
enroll that sucker in tpm unlock with clevis and call it a day lol
<@adamwill:fedora.im>
19:34:55
oh jocelyn changed
<@sp1tfire:matrix.org>
19:35:06
-1 FB
<@korora:fedora.im>
19:35:11
I do that from time to time. ;)
<@adamwill:fedora.im>
19:35:13
so, yeah, we're a bit stuck
<@adamwill:fedora.im>
19:35:18
technically, the default decision is reject
<@adamwill:fedora.im>
19:35:39
though i don't know if we've ever had to do that, we've always got a 3 vote delta before
<@nirik:matrix.scrye.com>
19:35:46
you didn't vote yet? tiebreaker?
<@nirik:matrix.scrye.com>
19:36:03
oh, there's +3 in ticket too
<@adamwill:fedora.im>
19:36:09
well, i guess the default is leave it proposed, which is effectively a rejection if we're otherwise go, but leaves it open if we're not
<@adamwill:fedora.im>
19:36:22
i guess what we can do is leave this open and move on with the list and see where we get by the end
<@korora:fedora.im>
19:36:28
I do want to add that I feel like I've experienced this bug, but I don't recall which machine and what the hardware config was like
<@lruzicka:fedora.im>
19:36:36
Yeah, let's do it
<@adamwill:fedora.im>
19:37:18
proposed !agreed - 2455924 - punt (delay decision) - we do not have a clear call on this bug (we're at +4 / -4 in meeting, +6 / -4 with tracker votes added). we'll continue with the other proposed blockers then circle back later if necessary
<@adamwill:fedora.im>
19:37:30
i guess i could vote +1 just to give us a decision, but...heh
<@sgallagh:fedora.im>
19:37:40
ack
<@nirik:matrix.scrye.com>
19:37:46
ack
<@korora:fedora.im>
19:37:47
ack
<@derekenz:fedora.im>
19:37:48
ack
<@psklenar:fedora.im>
19:37:52
ack
<@aggraxis:fedora.im>
19:37:53
ack
<@adamwill:fedora.im>
19:37:59
!agreed - 2455924 - punt (delay decision) - we do not have a clear call on this bug (we're at +4 / -4 in meeting, +6 / -4 with tracker votes added). we'll continue with the other proposed blockers then circle back later if necessary
<@adamwill:fedora.im>
19:38:11
ok, and i suspect it'll be the same, but:
<@adamwill:fedora.im>
19:38:12
!link https://pagure.io/fedora-qa/blocker-review/issue/2047
<@adamwill:fedora.im>
19:38:12
!link https://bugzilla.redhat.com/show_bug.cgi?id=2441941
<@adamwill:fedora.im>
19:38:12
!topic (2441941) Graphics break when trying to type LUKS password (Dell XPS 13 Plus, jeischmann)
<@adamwill:fedora.im>
19:38:12
!info Proposed Blocker, kernel, NEW
<@adamwill:fedora.im>
19:38:12
!info Ticket vote: BetaBlocker (+2,0,-0) (+nielsenb, +psklenar)
<@adamwill:fedora.im>
19:38:31
this is the other case - Dell XPS 13 Plus, seems like it has graphical corruption issues both during and after boot, including at passphrase prompt
<@lruzicka:fedora.im>
19:38:45
Can this be escaped away?
<@nirik:matrix.scrye.com>
19:40:06
I don't like on this one that the booted system is not usable. ;(
<@korora:fedora.im>
19:41:13
Do we have any idea what the GPU is?
<@adamwill:fedora.im>
19:41:17
yeah, that sucks. but...it *is* only one system, so far
<@korora:fedora.im>
19:41:28
or the grapics setup in enera;?
<@adamwill:fedora.im>
19:41:28
the other commenters clearly have completely different hardware, and don't actually describe their symptoms
<@nirik:matrix.scrye.com>
19:41:29
this one also affects f43, but not GA, only updates...
<@adamwill:fedora.im>
19:41:34
Jocelyn (she/her) 🏳️⚧️ it's intel
<@adamwill:fedora.im>
19:41:45
Jocelyn (Server WG: Docs) (UTC -5) it's intel
<@adamwill:fedora.im>
19:41:51
00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [Iris Xe Graphics] [8086:a7a0] (rev 04)
<@nirik:matrix.scrye.com>
19:41:54
yeah, if it's isolated to just this one thing, I can be -1 blocker.
<@korora:fedora.im>
19:42:16
Do we have any other reports with the Raptor Lake GPUs?
<@conan_kudo:matrix.org>
19:42:33
what is Raptor Lake?
<@conan_kudo:matrix.org>
19:42:45
ah 13th and 14th gen
<@conan_kudo:matrix.org>
19:43:00
so these are very new
<@sgallagh:fedora.im>
19:43:08
-1 FB
<@korora:fedora.im>
19:43:17
-1 fb
<@adamwill:fedora.im>
19:43:23
not that new?
<@adamwill:fedora.im>
19:43:24
2022
<@sgallagh:fedora.im>
19:43:28
And if it appeared in F43 after updates, that presumably means we can fix this in post-install update for F44 too
<@korora:fedora.im>
19:43:28
The newest I have is Kaby Lake
<@adamwill:fedora.im>
19:43:35
dell stopped doing the xps 13 plus because everyone hated the capacitative keyboard thing iirc
<@sp1tfire:matrix.org>
19:43:38
They were launched back in 2023, not that new ig.
<@conan_kudo:matrix.org>
19:43:49
oh yeah
<@conan_kudo:matrix.org>
19:43:53
that torturous computer
<@lruzicka:fedora.im>
19:43:57
-1 fb, document
<@conan_kudo:matrix.org>
19:44:13
if we have only one example and no other reports from other 13/14 gen intel systems... -1 FB and document
<@adamwill:fedora.im>
19:44:23
i feel like we can document this as a sign from God to get a better laptop
<@korora:fedora.im>
19:44:55
Agreed
<@conan_kudo:matrix.org>
19:44:55
I have a snarky comment about dells that I could put in here
<@aggraxis:fedora.im>
19:44:58
-1 fb
<@sp1tfire:matrix.org>
19:45:02
-1 FB
<@boniboyblue:fedora.im>
19:45:19
I'm also FB -1
<@lruzicka:fedora.im>
19:45:20
prDELL
<@sp1tfire:matrix.org>
19:45:29
They were launched back in 2023, not that new.
<@adamwill:fedora.im>
19:45:33
proposed !agreed 2441941 - RejectedBlocker (Final) - this specific case seems different from other early-boot graphics issues and so far seems specific to the XPS Plus 9320 (other folks commenting on the bug clearly have very different hardware and don't describe the same symptoms). On that basis it's rejected as a blocker for not being known to affect a wide-enough range of hardware
<@lruzicka:fedora.im>
19:45:46
ack jeeves
<@adamwill:fedora.im>
19:45:52
i don't mind dells in general, i used xps 13s for years. but the xps 13 plus was an awful idea
<@conan_kudo:matrix.org>
19:45:57
ack
<@derekenz:fedora.im>
19:46:04
ack
<@sgallagh:fedora.im>
19:46:04
"snarky" and "comments about Dells" are redundant. 🏃♂️➡️
<@korora:fedora.im>
19:46:05
ack
<@sgallagh:fedora.im>
19:46:10
ack
<@aggraxis:fedora.im>
19:46:24
ack
<@korora:fedora.im>
19:46:30
I have a Dell server, but my macines are all etiher self built or ThinkPads
<@psklenar:fedora.im>
19:46:31
ack
<@adamwill:fedora.im>
19:47:06
!agreed 2441941 - RejectedBlocker (Final) - this specific case seems different from other early-boot graphics issues and so far seems specific to the XPS Plus 9320 (other folks commenting on the bug clearly have very different hardware and don't describe the same symptoms). On that basis it's rejected as a blocker for not being known to affect a wide-enough range of hardware
<@sgallagh:fedora.im>
19:47:06
It was just a joke. Dells are no worse than any other pre-fab machines.
<@adamwill:fedora.im>
19:47:31
!info Proposed Blocker, kernel, NEW
<@adamwill:fedora.im>
19:47:31
!info Ticket vote: FinalBlocker (+1,0,-1) (+loquser, -pbrobinson)
<@adamwill:fedora.im>
19:47:31
!link https://pagure.io/fedora-qa/blocker-review/issue/2111
<@adamwill:fedora.im>
19:47:31
!topic (2458899) An update broke the realtek chip rtl8852be on fedora 44 kde
<@adamwill:fedora.im>
19:47:31
!link https://bugzilla.redhat.com/show_bug.cgi?id=2458899
<@korora:fedora.im>
19:47:32
Oh, I know. :)
<@adamwill:fedora.im>
19:47:49
this showed up late, without much detail
<@nirik:matrix.scrye.com>
19:48:05
yeah, not much info here to go on...
<@conan_kudo:matrix.org>
19:48:16
uhh wut?
<@nirik:matrix.scrye.com>
19:48:32
also was a beta install?
<@nirik:matrix.scrye.com>
19:48:51
but updated after I guess.
<@korora:fedora.im>
19:49:47
This was posted to BZ 12 hours ago.
<@korora:fedora.im>
19:50:20
I bet this RTL8852BE is a common chip though
<@sgallagh:fedora.im>
19:50:40
I'm running that chip on my system right now
<@sgallagh:fedora.im>
19:50:48
On F44 KDE, fully updated.
<@nirik:matrix.scrye.com>
19:50:56
let me check smolt... </old fedora joke>
<@conan_kudo:matrix.org>
19:51:07
we should bring that back
<@adamwill:fedora.im>
19:52:11
https://www.reddit.com/r/archlinux/comments/1s8myt8/kerneldriver_bug_issue_with_wifi_need_help/
<@nirik:matrix.scrye.com>
19:52:22
Stephen Gallagher: rtw89 driver?
<@adamwill:fedora.im>
19:52:23
"the realtek chips are notorious for this kind of crap especially after kernel updates. "
<@conan_kudo:matrix.org>
19:53:00
I think there's a meme about "friends don't let friends buy realtek"
<@aggraxis:fedora.im>
19:53:28
Real friends don't let friends by realtek lol
<@sgallagh:fedora.im>
19:53:36
`lsmod` says "yes"
<@adamwill:fedora.im>
19:53:51
ok, one data point is enough for me
<@adamwill:fedora.im>
19:53:52
-1
<@aggraxis:fedora.im>
19:53:55
ok, so we have evidence of a working device running the afflicted software
<@aggraxis:fedora.im>
19:53:58
-1 fb
<@conan_kudo:matrix.org>
19:54:09
-1 FB
<@korora:fedora.im>
19:54:13
I'm -1 as this is the only instane that we've heard about
<@sp1tfire:matrix.org>
19:54:14
-1 FB
<@psklenar:fedora.im>
19:54:16
-1 fb , one user
<@sgallagh:fedora.im>
19:54:21
-1 FB
<@nirik:matrix.scrye.com>
19:54:25
yeah, -1 based on what we have now
<@derekenz:fedora.im>
19:54:26
Yeah FB -1
<@boniboyblue:fedora.im>
19:54:41
I'm FB -1 as well - just not enough information on the bug report.
<@lruzicka:fedora.im>
19:55:18
-1 final block, buy some decent stock
<@adamwill:fedora.im>
19:55:29
proposed !agreed 2458899 - RejectedBlocker (Final) - so far there is only one report of this that we can find, and sgallagh has the same chip in his laptop and it's working fine on F44. So with the available info at this point we cannot conclude that this has a wide enough hardware impact to be considered a blocker
<@korora:fedora.im>
19:55:36
ack
<@psklenar:fedora.im>
19:55:38
ack
<@aggraxis:fedora.im>
19:55:38
ack
<@sgallagh:fedora.im>
19:55:40
patch
<@nirik:matrix.scrye.com>
19:55:45
ack
<@lruzicka:fedora.im>
19:55:47
ack
<@sgallagh:fedora.im>
19:55:48
(It's my desktop, not laptop)
<@conan_kudo:matrix.org>
19:55:49
ack
<@derekenz:fedora.im>
19:55:54
ack
<@adamwill:fedora.im>
19:56:08
proposed !agreed 2458899 - RejectedBlocker (Final) - so far there is only one report of this that we can find, and sgallagh has the same chip in his system and it's working fine on F44. So with the available info at this point we cannot conclude that this has a wide enough hardware impact to be considered a blocker
<@adamwill:fedora.im>
19:56:10
patched
<@adamwill:fedora.im>
19:57:00
hum, bugzilla search found https://bugzilla.redhat.com/show_bug.cgi?id=2458629
<@adamwill:fedora.im>
19:57:08
which is either a more detailed and interesting report, or LLMslop
<@adamwill:fedora.im>
19:57:30
ehh, leaning toward 'interesting report', though it's also on f43
<@nirik:matrix.scrye.com>
19:57:46
it's quite... long
<@adamwill:fedora.im>
19:58:12
yeah
<@adamwill:fedora.im>
19:58:17
anyhow, just a sidebar. let's go with this
<@nirik:matrix.scrye.com>
19:58:19
but also doesn't seem like the same thing to me.
<@sgallagh:fedora.im>
19:58:36
Yeah, I agree. Also, different hardware.
<@adamwill:fedora.im>
19:58:49
it mentions the rtw89 driver
<@conan_kudo:matrix.org>
19:58:50
ehhh
<@adamwill:fedora.im>
19:58:51
anyhoo
<@conan_kudo:matrix.org>
19:58:53
this report feels off
<@adamwill:fedora.im>
19:58:58
!agreed 2458899 - RejectedBlocker (Final) - so far there is only one report of this that we can find, and sgallagh has the same chip in his system and it's working fine on F44. So with the available info at this point we cannot conclude that this has a wide enough hardware impact to be considered a blocker
<@conan_kudo:matrix.org>
19:59:01
anyway, it doesn't matter for this discussion
<@adamwill:fedora.im>
19:59:13
!info Ticket vote: FinalBlocker (+1,0,-0) (+derekenz)
<@adamwill:fedora.im>
19:59:13
!topic (2458901) An incomplete spanned btrfs makes anaconda not see the drive, and crash when rescanning
<@adamwill:fedora.im>
19:59:13
!link https://bugzilla.redhat.com/show_bug.cgi?id=2458901
<@adamwill:fedora.im>
19:59:13
!link https://pagure.io/fedora-qa/blocker-review/issue/2112
<@adamwill:fedora.im>
19:59:13
!info Proposed Blocker, python-blivet, ASSIGNED
<@adamwill:fedora.im>
19:59:15
whew, last one
<@sgallagh:fedora.im>
19:59:20
adamw: Yes, but RTL8922AU device
<@adamwill:fedora.im>
19:59:41
so this is basically like installing with one disk from a RAID set attached, and you just want to wipe it and install to it as a normal disk
<@adamwill:fedora.im>
19:59:54
i'm pretty sure we had proposed blockers on that scenario in the past. i don't remember what we decided
<@adamwill:fedora.im>
20:00:17
it does feel a bit blocker-y to me under the criteria. it's probably a *relatively* rare situation, but quite bad if you're trapped in it...
<@sgallagh:fedora.im>
20:00:27
IMHO, that should work, but I'm not convinced it's a frequent-enough situation to be worth blocking on.
<@conan_kudo:matrix.org>
20:00:29
I think we did block on it before?
<@conan_kudo:matrix.org>
20:00:56
is there a way out that a user can reasonably do?
<@nirik:matrix.scrye.com>
20:01:07
yeah, I don't think it's too common...
<@sgallagh:fedora.im>
20:01:08
I think we blocked on it years ago when fakeraid was still in vogue.
<@nirik:matrix.scrye.com>
20:01:15
boot and wipefs -a on it?
<@korora:fedora.im>
20:02:14
In the past when I've had this type of issue, I simply drop to a command prompt nad nuke the thing from orbit
<@conan_kudo:matrix.org>
20:02:19
it's probably reasonable to block even now since softraid never left us
<@adamwill:fedora.im>
20:02:52
i think i'm +1 on this
<@conan_kudo:matrix.org>
20:03:06
+1 FB as well
<@korora:fedora.im>
20:03:23
I am +1 as well, even though there are workarounds, but a newer user may not know them
<@sgallagh:fedora.im>
20:03:30
0 from me; I don't have a good sense of how likely this is to be encountered.
<@adamwill:fedora.im>
20:03:46
note this one isn't technically a 'how often is it encountered' decision because it's not subjective
<@lruzicka:fedora.im>
20:03:47
0
<@adamwill:fedora.im>
20:03:57
note this one isn't technically a 'how often is it encountered' decision because it's not a conditional violation
<@sgallagh:fedora.im>
20:04:11
adamw: It's hardware-specific
<@conan_kudo:matrix.org>
20:04:20
this is also a regression, it used to work and it broke accidentally
<@adamwill:fedora.im>
20:04:20
i would say it's not, in relation to the criterion
<@adamwill:fedora.im>
20:04:25
the criterion basically says "this has to work"
<@nirik:matrix.scrye.com>
20:04:32
I suppose +1... it's a bad case if you don't know how to get past it.
<@conan_kudo:matrix.org>
20:04:43
it can also be synthesized in a VM independent of disk layout
<@adamwill:fedora.im>
20:04:49
this isn't the same as a very general "system must boot" criterion where we say "well, on most hardware it does"
<@adamwill:fedora.im>
20:04:55
there are pretty specifically-worded criteria here
<@conan_kudo:matrix.org>
20:05:00
just make two partitions on a single disk, raid the partitions in btrfs, delete the other member and now busted
<@aggraxis:fedora.im>
20:05:01
+1 ... This would be a panic moment for someone who doesn't know how to deal with it.
<@aggraxis:fedora.im>
20:05:12
It looks like a fix is in work
<@adamwill:fedora.im>
20:05:13
https://bugzilla.redhat.com/show_bug.cgi?id=2458901#c10 has the specific references
<@conan_kudo:matrix.org>
20:05:18
just make two partitions on a single disk, raid the partitions in btrfs, delete the other partition and now busted
<@sgallagh:fedora.im>
20:05:49
OK, upon rereading the criterion, I guess I can be +1 FB here.
<@aggraxis:fedora.im>
20:06:15
Yeah, the criterion are pretty clear.
<@sgallagh:fedora.im>
20:06:30
But if this turns out to be the last blocker, I'm going to be a bit sad.
<@adamwill:fedora.im>
20:06:45
proposed !agreed 2458901 - AcceptedBlocker (Final) - this is accepted as a violation of the criteria cited in https://bugzilla.redhat.com/show_bug.cgi?id=2458901#c10
<@adamwill:fedora.im>
20:06:50
oh, we have *lots* of blockers
<@derekenz:fedora.im>
20:06:59
ack
<@adamwill:fedora.im>
20:07:01
next we decide if we want to waive...all of them
<@aggraxis:fedora.im>
20:07:15
ack
<@korora:fedora.im>
20:07:30
ack
<@conan_kudo:matrix.org>
20:07:31
ack
<@nirik:matrix.scrye.com>
20:07:35
ack
<@lruzicka:fedora.im>
20:07:38
ack
<@boniboyblue:fedora.im>
20:07:43
ack
<@adamwill:fedora.im>
20:07:56
!agreed 2458901 - AcceptedBlocker (Final) - this is accepted as a violation of the criteria cited in https://bugzilla.redhat.com/show_bug.cgi?id=2458901#c10
<@adamwill:fedora.im>
20:08:14
!info that's all the proposed blockers
<@adamwill:fedora.im>
20:08:27
!topic Waiver consideration
<@farchord:fedora.im>
20:08:48
FYI, I had the issue on 44 where the LUKS screen was essentially frozen (Not showing keyboard inputs). I know I added a kernel argument to make it working again, if you need help troubleshooting that one I can try to go remove the kernel argument to help
<@farchord:fedora.im>
20:08:58
My laptop is a Framework 16 with the Ryzen AI 3rd gen
<@adamwill:fedora.im>
20:09:09
so, if I'm counting right, we now have 4 outright accepted blockers
<@adamwill:fedora.im>
20:09:26
!info the following bugs are currently accepted blockers:
<@nirik:matrix.scrye.com>
20:09:32
feel free to test and post results to the bug(s)
<@adamwill:fedora.im>
20:09:35
!link https://bugzilla.redhat.com/show_bug.cgi?id=2448283
<@adamwill:fedora.im>
20:09:40
!link https://bugzilla.redhat.com/show_bug.cgi?id=2453216
<@adamwill:fedora.im>
20:09:44
!link https://bugzilla.redhat.com/show_bug.cgi?id=2458907
<@adamwill:fedora.im>
20:09:50
!link https://bugzilla.redhat.com/show_bug.cgi?id=2458901
<@adamwill:fedora.im>
20:10:06
we accepted those two, right? 'nonetype' has no attribute 'path' and incomplete btrfs?
<@conan_kudo:matrix.org>
20:10:20
yes
<@adamwill:fedora.im>
20:10:21
does anyone want to consider waiving all four of these?
<@adamwill:fedora.im>
20:10:37
i don't really feel like waiving all of them
<@conan_kudo:matrix.org>
20:11:05
I don't either
<@adamwill:fedora.im>
20:11:18
i was willing to waive the plasma-setup ones if they were the last two. i'd *maybe* consider waiving either of the others if it was the last one. but the overall feeling is...maybe another week wouldn't hurt? especially since it looks like we can definitely fix the two we accepted
<@adamwill:fedora.im>
20:11:32
and maybe at least clarify some stuff around the luks cases
<@adamwill:fedora.im>
20:11:41
Jef Spaleta are you around btw?
<@nirik:matrix.scrye.com>
20:11:44
yeah.
<@conan_kudo:matrix.org>
20:11:45
yeah
<@conan_kudo:matrix.org>
20:11:49
that's my feeling too
<@sgallagh:fedora.im>
20:12:47
If we slip, can we be REALLY conservative about slipping in FE changes?
<@adamwill:fedora.im>
20:12:57
we sure can!
<@adamwill:fedora.im>
20:13:04
(the big one already went in rc-1.2 anyway)
<@nirik:matrix.scrye.com>
20:14:28
So, info no go, send announcement, don't profit?
<@jspaleta:fedora.im>
20:14:41
im here... i look forward to making this discussion harder than it needs to be
<@adamwill:fedora.im>
20:14:42
Jef Spaleta are you particularly sad if we decide not to waive these four bugs and slip a week?
<@adamwill:fedora.im>
20:14:49
see a bit above for the list
<@zodbot:fedora.im>
20:14:53
aggraxis gave a cookie to jspaleta. They now have 19 cookies, 11 of which were obtained in the Fedora 43 release cycle
<@adamwill:fedora.im>
20:14:59
Jef Spaleta are you particularly sad if we decide not to waive these four bugs, and slip a week?
<@zodbot:fedora.im>
20:15:09
korora gave a cookie to jspaleta. They now have 20 cookies, 12 of which were obtained in the Fedora 43 release cycle
<@jspaleta:fedora.im>
20:15:09
i am not sad... blame it on me.. im new
<@adamwill:fedora.im>
20:15:17
!agreed this is all Jef's fault
<@korora:fedora.im>
20:15:27
ack
<@adamwill:fedora.im>
20:15:36
alright, so i'm not seeing much appetite for waiving all the blockers
<@jspaleta:fedora.im>
20:15:50
does this mean I need to rededit the release schedule edit im trying to do right now
<@nirik:matrix.scrye.com>
20:15:57
Jef Spaleta: no no, you need to blame it on the last person. ;)
<@adamwill:fedora.im>
20:15:59
!agreed there is no proposal to waive all four outstanding accepted blockers
<@adamwill:fedora.im>
20:16:03
Jef Spaleta yes, yes it does
<@adamwill:fedora.im>
20:16:09
bump everything another week, call it release target #2
<@jspaleta:fedora.im>
20:16:17
even better.. becasue smartsheet is smarter than me
<@adamwill:fedora.im>
20:16:24
hence the same
<@adamwill:fedora.im>
20:16:28
you're not called SmartJef, are you? well then
<@jspaleta:fedora.im>
20:16:46
replease Jef with another three letter word...
<@farchord:fedora.im>
20:16:51
Darn you Jeff!
<@adamwill:fedora.im>
20:17:12
alright, since we have outstanding blockers, let's cut to:
<@adamwill:fedora.im>
20:17:18
!topic Go/No-Go decision
<@adamwill:fedora.im>
20:17:27
I will poll each team. Please reply “go” or “no-go”
<@adamwill:fedora.im>
20:17:30
FESCo?
<@jspaleta:fedora.im>
20:17:49
I will refrain from regaling everuone here with my personal history concerning the word DARN..
<@nirik:matrix.scrye.com>
20:18:06
no go
<@conan_kudo:matrix.org>
20:18:09
No-Go
<@sgallagh:fedora.im>
20:18:13
No go
<@adamwill:fedora.im>
20:18:21
Releng?
<@sgallagh:fedora.im>
20:18:36
Jef Spaleta: Hole-y socks?
<@nirik:matrix.scrye.com>
20:18:49
no going
<@farchord:fedora.im>
20:18:57
I'd love to hear it in #social:fedoraproject.org at some point 🙂
<@jspaleta:fedora.im>
20:18:58
https://en.wikipedia.org/wiki/SuperDARN
<@adamwill:fedora.im>
20:19:00
QA?
<@lruzicka:fedora.im>
20:19:10
noey goey
<@psklenar:fedora.im>
20:19:12
no go
<@boniboyblue:fedora.im>
20:19:18
no go
<@derekenz:fedora.im>
20:19:19
no go
<@adamwill:fedora.im>
20:19:24
!agreed Fedora Linux 44 Final is NO-GO
<@sgallagh:fedora.im>
20:19:46
Nifty
<@adamwill:fedora.im>
20:19:55
!info The next F44 Final Go/No-Go meeting will be Thursday, 2026-04-23 at 1800 UTC
<@adamwill:fedora.im>
20:20:15
!info F44 Final shifts to target date #2: Tuesday 2026-04-28
<@jspaleta:fedora.im>
20:20:22
so final 2nd target date shifts a week in the schedule... on it right now
<@adamwill:fedora.im>
20:20:23
!action jspaleta to announce decision
<@jspaleta:fedora.im>
20:20:43
great where do i announce?
<@conan_kudo:matrix.org>
20:21:01
devel-announce, test-announce, I think?
<@adamwill:fedora.im>
20:21:16
Jef Spaleta technically the schedule was already wrong. we should have had apr 21 listed as 'target date #1' and apr 28 listed as 'target date #2' already, with target date 1 as the current target, and at this point we would just shift to target date 2
<@adamwill:fedora.im>
20:21:32
Jef Spaleta look for old mails from Ben / Aoife and do what they did i guess
<@adamwill:fedora.im>
20:22:16
Jef Spaleta i can forward you the last one i did, in 39 cycle
<@jspaleta:fedora.im>
20:23:04
its fine... i just need to know the locations i need to drop the announcement.. I'll write a klingon sonnet.. it will be fun
<@jspaleta:fedora.im>
20:23:10
schedule edit going in right now.
<@adamwill:fedora.im>
20:23:31
!topic Open floor
<@adamwill:fedora.im>
20:23:40
for the record, i'll note that test coverage was excellent
<@adamwill:fedora.im>
20:23:56
so i'm *hopeful* there shouldn't be too many more potential blockers lurking after these
<@adamwill:fedora.im>
20:24:32
anything else before we close out? thanks for sticking through a long meeting, folks
<@supakeen:fedora.im>
20:24:36
They always come late I guess.
<@adamwill:fedora.im>
20:24:39
i will secretarialize the decisions after i've had lunch
<@nirik:matrix.scrye.com>
20:24:45
nothing could possibly go wrong now!
<@lruzicka:fedora.im>
20:24:51
Will there be a BRM on Monday?
<@sgallagh:fedora.im>
20:24:59
adamw: Thank you for running this exceptionally long meeting
<@adamwill:fedora.im>
20:25:04
we do try and catch stuff early but the more testing you do, the more you find...
<@farchord:fedora.im>
20:25:12
..... You'd think you'd have heard of 'jinxing' by now 😆
<@adamwill:fedora.im>
20:25:21
assume so, yeah, i'll cancel if there's absolutely nothing to review at that point
<@supakeen:fedora.im>
20:25:25
adamw: Oh yea, but I mean people at large only really start testing at the RC so the blockers end up coming in late if they find any :)
<@zodbot:fedora.im>
20:25:31
kevin has already given cookies to adamwill during the F43 timeframe
<@korora:fedora.im>
20:25:35
adamwThanks for running the meeting
<@supakeen:fedora.im>
20:25:45
Thanks for the meeting, it's been long enough :)
<@nirik:matrix.scrye.com>
20:25:46
thanks adamw
<@adamwill:fedora.im>
20:25:50
cya everyone
<@adamwill:fedora.im>
20:25:53
!endmeeting