<@amoloney:fedora.im>
17:00:51
!startmeeting F40 Final Go/No-Go meeting
<@meetbot:fedora.im>
17:00:52
Meeting started at 2024-04-11 17:00:51 UTC
<@meetbot:fedora.im>
17:00:52
The Meeting name is 'F40 Final Go/No-Go meeting'
<@amoloney:fedora.im>
17:01:02
!info roll call
<@amoloney:fedora.im>
17:01:04
!hi
<@zodbot:fedora.im>
17:01:06
Aoife Moloney (amoloney)
<@coremodule:fedora.im>
17:01:15
!hello2
<@zodbot:fedora.im>
17:01:16
Geoffrey Marr (coremodule)
<@pboy:fedora.im>
17:01:23
!hi
<@zodbot:fedora.im>
17:01:24
Peter Boy (pboy)
<@thebeanogamer:fedora.im>
17:01:31
!hi
<@zodbot:fedora.im>
17:01:35
Daniel Milnes (thebeanogamer) - he / him / his
<@nirik:matrix.scrye.com>
17:01:45
morning
<@geraldosimiao:matrix.org>
17:02:09
!hi
<@thebeanogamer:fedora.im>
17:02:10
Afternoon
<@frantisekz:fedora.im>
17:02:10
o/
<@zodbot:fedora.im>
17:02:10
Geraldo S. Simião Kutz (geraldosimiao) - he / him / his
<@brianc07:fedora.im>
17:02:17
Evening
<@amoloney:fedora.im>
17:02:29
!topic Purpose of this meeting
<@amoloney:fedora.im>
17:02:38
!info Purpose of this meeting is to check whether or not F40 Final is ready for shipment, according to the release criteria.
<@amoloney:fedora.im>
17:02:52
!info This is determined in a few ways:
<@amoloney:fedora.im>
17:03:02
!info 1. Release candidate compose is available
<@amoloney:fedora.im>
17:03:12
!info 2. No remaining blocker bugs
<@geraldosimiao:matrix.org>
17:03:17
good evening
<@lruzicka:matrix.org>
17:03:19
Hello
<@amoloney:fedora.im>
17:03:22
!info 3. Test matrices are fully completed
<@sgallagh:fedora.im>
17:03:24
!hi
<@zodbot:fedora.im>
17:03:25
Stephen Gallagher (sgallagh) - he / him / his
<@amoloney:fedora.im>
17:03:33
!info 4. Fedora CoreOS and IoT are ready
<@brianc07:fedora.im>
17:03:45
!hi
<@zodbot:fedora.im>
17:03:47
None (brianc07)
<@amoloney:fedora.im>
17:04:05
hi folks! thats the boiler plate stuff done anyway so we all know what were about :)
<@geraldosimiao:matrix.org>
17:04:39
I'm here for cookies
<@geraldosimiao:matrix.org>
17:04:43
:)
<@amoloney:fedora.im>
17:04:55
oh always a benefit!
<@geraldosimiao:matrix.org>
17:05:09
thanks :D
<@amoloney:fedora.im>
17:05:26
without further adieu, lets get to our RC
<@amoloney:fedora.im>
17:05:30
!topic Current status - RC
<@amoloney:fedora.im>
17:05:44
Do we have a candidate to decide on today?
<@adamwill:fedora.im>
17:05:47
yup. we sure do got one.
<@adamwill:fedora.im>
17:05:59
in a shocking break with recent tradition, we just have *one*, as well!
<@adamwill:fedora.im>
17:06:08
https://dl.fedoraproject.org/pub/alt/stage/40_RC-1.13/
<@conan_kudo:matrix.org>
17:06:49
!hi
<@amoloney:fedora.im>
17:06:51
!info the RC 1.13 https://dl.fedoraproject.org/pub/alt/stage/40_RC-1.13/ is what we will be deciding release readiness for Fedora Linux 40 final at the go/no-go meeting
<@zodbot:fedora.im>
17:06:52
Neal Gompa (ngompa) - he / him / his
<@nirik:matrix.scrye.com>
17:07:10
as a side note the 1.12 with busted names never got synced properly. I didn't think it was worth doing since it was not possible and we had a newer one.
<@amoloney:fedora.im>
17:07:43
lucky (version) number 13 :D
<@geraldosimiao:matrix.org>
17:08:11
I didn't realised that
<@amoloney:fedora.im>
17:08:16
in that case, lets move on to our blocker segment
<@geraldosimiao:matrix.org>
17:08:17
😐️
<@amoloney:fedora.im>
17:08:28
!topic Current status - blockers
<@amoloney:fedora.im>
17:08:47
<@amoloney:fedora.im>
17:09:02
adamw: will turn over the reins to you
<@adamwill:fedora.im>
17:09:10
okey dokey
<@adamwill:fedora.im>
17:09:14
+10 for spelling 'reins' correctly
<@amoloney:fedora.im>
17:09:26
I am a horse person L(
<@amoloney:fedora.im>
17:09:28
:)
<@adamwill:fedora.im>
17:09:31
!topic (2274006) Unable to Boot - efibootmgr failed with "Could not prepare Boot variable: Invalid argument", CreateBLSEntriesTask task did not run, thus no bootloader entry
<@geraldosimiao:matrix.org>
17:09:36
reeeeeins
<@adamwill:fedora.im>
17:09:37
<@adamwill:fedora.im>
17:09:40
<@adamwill:fedora.im>
17:09:43
!info Proposed Blocker, efibootmgr, NEW
<@adamwill:fedora.im>
17:10:04
so...really, there's nothing to indicate this is anything other than a system-specific blip. nobody else has reported this afaik
<@adamwill:fedora.im>
17:10:10
so, i'm -1 blocker based on current info
<@nirik:matrix.scrye.com>
17:10:24
yeah, -1 blocker here based on what we know now
<@sgallagh:fedora.im>
17:10:29
-3 for not spelling "ado" correctly, though 😥
<@adamwill:fedora.im>
17:10:33
'createblsentries does not run if efibootmgr fails' is a general issue, but not worth blocking on, I don't think. if efibootmgr fails you've got issues.
<@adamwill:fedora.im>
17:10:40
Stephen Gallagher: i was being a gentleman on that one.
<@amoloney:fedora.im>
17:11:10
cant be right all of the time, I need to leave a little room for you to correct me 😋
<@sgallagh:fedora.im>
17:11:47
Yeah, nothing I read in that BZ suggests that it's a general problem. -1 Blocker
<@lruzicka:matrix.org>
17:12:46
-1 blocker
<@frantisekz:fedora.im>
17:12:52
yep, -1 Blocker
<@adamwill:fedora.im>
17:12:54
proposed !agreed 2274006 - RejectedBlocker (Final) - while this is clearly a significant bug for the reporter, no information so far indicates a more widespread issue, there is likely something system-specific about this efibootmgr failure
<@geraldosimiao:matrix.org>
17:12:59
ack
<@nirik:matrix.scrye.com>
17:13:07
ack
<@amoloney:fedora.im>
17:13:14
+1 fwiw
<@adamwill:fedora.im>
17:13:27
!agreed 2274006 - RejectedBlocker (Final) - while this is clearly a significant bug for the reporter, no information so far indicates a more widespread issue, there is likely something system-specific about this efibootmgr failure
<@adamwill:fedora.im>
17:13:31
!topic (2272758) Illegal instruction errors in libQt6Core
<@adamwill:fedora.im>
17:13:34
<@adamwill:fedora.im>
17:13:37
<@adamwill:fedora.im>
17:13:40
!info Proposed Blocker, gcc, NEW
<@adamwill:fedora.im>
17:13:42
!info Ticket vote: FinalBlocker (+1,0,-0) (+frantisekz)
<@adamwill:fedora.im>
17:13:45
!info Ticket vote: FinalFreezeException (+3,0,-0) (+geraldosimiao, +adamwill, +ngompa)
<@sgallagh:fedora.im>
17:15:21
Aoife Moloney: Did you mean "ack" or "+1 to blocking on it"?
<@farribeiro:matrix.org>
17:15:23
!hi
<@nirik:matrix.scrye.com>
17:15:25
This is another of those 'how widespread is this affected hardware' things. ;(
<@zodbot:fedora.im>
17:15:25
Fábio Ribeiro (farribeiro) - he / him / his
<@adamwill:fedora.im>
17:15:27
so, this one is pretty borderline. on current information, the impact of this is: it affects CPUs with AES-NI ('aes'), but not AVX ('avx'). this is a fairly small set of CPUs - some very old Intel 'mainline' CPUs from the time period between AES-NI and AVX (e.g. the Core i5-650), and some more recent very CPUs targeted at very low-end and/or embedded systems. There are wiki pages linked in the bug report which give the exact affected models
<@amoloney:fedora.im>
17:15:29
I mean ack, sorry
<@amoloney:fedora.im>
17:15:44
forgot the language is different at this bit
<@sgallagh:fedora.im>
17:16:15
No problem, just wanted to make sure you didn't have an argument for blocking that we failed to catch
<@adamwill:fedora.im>
17:16:27
the impact of the bug seems to be: you can't boot Plasma. desktops with no qt6 in their boot chain boot, but anything linked against qt6 will crash, which includes various popular apps, plus tracker-miners apparently (which runs by default on GNOME)
<@adamwill:fedora.im>
17:17:20
this is really tricky for me. it's obviously really bad if you have affected hardware. and multiple testers hit this in real life, which kinda indicates yes, people *do* want to run the affected things on the affected hardware. but otoh...the numbers say it's still a pretty small percentage.
<@adamwill:fedora.im>
17:17:36
the only hard data we have is from the steam hardware survey, which obviously isn't perfect as gamers tend to have higher-end systems in general.
<@conan_kudo:matrix.org>
17:17:41
I'm really not a fan of this bug existing in delivered media :/
<@conan_kudo:matrix.org>
17:18:01
this also affects Fedora Workstation and any variant delivering Fedora Media Writer
<@sgallagh:fedora.im>
17:18:05
adamw: Yeah, it's not great, but I kind of feel like I wouldn't block on this if it was the last blocker. (Which it might be!)
<@nirik:matrix.scrye.com>
17:18:07
if we do accept this, whats the chances we could land a fix soon and do a 1.14 ? or would it mean slip for sure
<@adamwill:fedora.im>
17:18:12
it's realllly tight for me
<@adamwill:fedora.im>
17:18:16
i feel like i'm a +0.2
<@adamwill:fedora.im>
17:18:25
nirik: i think it has to be a slip at this point
<@frantisekz:fedora.im>
17:18:27
on the other hand... to be really sure we would have to rebuild bunch of stuff
<@sgallagh:fedora.im>
17:18:29
nirik: Definitely a slip
<@frantisekz:fedora.im>
17:18:38
we're not sure what everything can be affected
<@adamwill:fedora.im>
17:18:39
gcc is *still* not done and we need to factor in another 8-9 hour compose
<@nirik:matrix.scrye.com>
17:18:52
sure.
<@adamwill:fedora.im>
17:18:58
František Zatloukal: i would aim to just rebuild qt6 and hope that's sufficient
<@adamwill:fedora.im>
17:19:09
in theory the bug could affect other apps but i don't think we have any clear indication yet that it *does*
<@adamwill:fedora.im>
17:19:11
node was something else
<@sgallagh:fedora.im>
17:19:48
Yeah, Node was unrelated, is already fixed and isn't in the boot path anyway
<@nirik:matrix.scrye.com>
17:19:54
Yeah, I'm on the fence here too...
<@adamwill:fedora.im>
17:19:56
as a bit of foreshadowing, i should say that i feel very on-the-edge about the release *in general*. there's a whole bunch of these little 'ehhh, it's kinda close' issues
<@jforbes:fedora.im>
17:19:58
Well, if we are going to slip we could bring in 6.8.5 and get the spectre bhi fixes and amd
<@adamwill:fedora.im>
17:20:15
jforbes: except, that intel 'system doesn't boot' bug i posted in the kernel channel...
<@adamwill:fedora.im>
17:20:26
oh, i see, you said it should be ok
<@jforbes:fedora.im>
17:20:33
adamw: except that doesn't impact Fedora at all
<@adamwill:fedora.im>
17:20:38
yeah, spectre bhi is something
<@adamwill:fedora.im>
17:20:50
i didn't put it on the blocker list because RH rated it 'moderate' so it kinda can't be
<@adamwill:fedora.im>
17:21:02
but yeah, let's try and stay on topic as much as possible, just wanted to set the context
<@nirik:matrix.scrye.com>
17:21:11
so, given this is the 'early' date anyhow, and this is not something we can fix post release very easily, I'm inclined to blocker now.
<@adamwill:fedora.im>
17:21:45
yeah, that's kinda my thinking. and, cards on the table, i kinda feel like 'make this a blocker and we can fix some other stuff too'
<@amoloney:fedora.im>
17:21:51
let me ask you this - would you all go away from this meeting with a GO regretting allowing this bug to be there?
<@nirik:matrix.scrye.com>
17:22:10
I had hopes for go today, but I'll get over my disappointment, I'm sure. ;)
<@frantisekz:fedora.im>
17:22:43
I won't be sad for just this one, but it's bunch of things that aren't as polished as they could for the final
<@sgallagh:fedora.im>
17:22:53
I'd like to register my concern that if we slip, there's a pile of stuff to land as FEs that could destabilize things for next week,
<@lruzicka:matrix.org>
17:22:58
How exactly are we going to fix this? Would it require something big that could affect many other things?
<@geraldosimiao:matrix.org>
17:23:06
+1 to that
<@frantisekz:fedora.im>
17:23:12
new gcc and qt rebuild
<@frantisekz:fedora.im>
17:23:16
lruzicka:
<@geraldosimiao:matrix.org>
17:23:19
we're at eraly target date
<@adamwill:fedora.im>
17:23:22
lruzicka: wait for gcc to finish building, rebuild qt6
<@geraldosimiao:matrix.org>
17:23:31
we're at early target date
<@adamwill:fedora.im>
17:23:31
Stephen Gallagher: what things are you concerned about specifically?
<@adamwill:fedora.im>
17:23:39
maybe we can talk about that later, actually
<@nirik:matrix.scrye.com>
17:23:42
We don't have to land FE's BTW...
<@nirik:matrix.scrye.com>
17:23:57
we _can_ or we can decide they are too risky at this point and not
<@sgallagh:fedora.im>
17:23:58
adamw: Well, among other things, pulling in a whole new kernel seems risky at this point.
<@adamwill:fedora.im>
17:24:26
yeah, let's talk about that bit later
<@lruzicka:matrix.org>
17:24:31
also the rebuild might not go as easy as it looks
<@geraldosimiao:matrix.org>
17:24:42
A blocker now can give us time to properly fix the systemmonitor bug this time too
<@amoloney:fedora.im>
17:25:01
I would advocate for a good end-user experience so if there are things that would benefit from an extra few days to polish, I think its reasonable to allow us miss the early target
<@adamwill:fedora.im>
17:25:06
okay, let's try and focus a bit :D
<@geraldosimiao:matrix.org>
17:25:21
A blocker now can give us time to properly fix the systemmonitor and the kdehelper bugs this time too
<@nirik:matrix.scrye.com>
17:25:39
So, yeah, to get back to it... +1 blocker well, or +0.8 :)
<@adamwill:fedora.im>
17:25:42
i think i'm gonna reluctantly come off the fence as a +1. it's not a lot of systems, but it's systems we do intend to work on, and clearly some people really are out there using them.
<@geraldosimiao:matrix.org>
17:25:53
A blocker now can give us time to properly fix the kdehelper bug this time too
<@lruzicka:matrix.org>
17:26:07
why could not we fix it a little later?
<@frantisekz:fedora.im>
17:26:13
nope
<@lruzicka:matrix.org>
17:26:18
someone said we could not, whyM
<@frantisekz:fedora.im>
17:26:19
it affects kde live installs
<@nirik:matrix.scrye.com>
17:26:22
release media will be set
<@nirik:matrix.scrye.com>
17:26:31
boot from f40 media -> bug
<@adamwill:fedora.im>
17:26:32
lruzicka: it would be baked into the plasma live
<@adamwill:fedora.im>
17:26:37
you could never boot it on an affected system
<@sgallagh:fedora.im>
17:26:38
lruzicka: Because it breaks the Live media for KDE
<@sgallagh:fedora.im>
17:26:42
On the affected hardware
<@sgallagh:fedora.im>
17:27:12
Which, I guess, is probably enough justification.
<@sgallagh:fedora.im>
17:27:53
Still, the "affected hardware" basically boils down to "Intel shipping out silicon mistakes as a low-cost alternative"
<@adamwill:fedora.im>
17:28:06
i think we can all agree to blame intel
<@conan_kudo:matrix.org>
17:28:34
Yes indeed
<@nirik:matrix.scrye.com>
17:28:35
I thought we were supposed to blame canada? oh wait, that was something different...
<@adamwill:fedora.im>
17:28:43
blame canadian intel
<@lruzicka:matrix.org>
17:28:46
That is of course a problem, but if people would be aware, could they boot from F39 and update later? We could describe it in common bugs.
<@adamwill:fedora.im>
17:28:52
any other votes? we're at +2 now, i believe
<@sgallagh:fedora.im>
17:29:05
I guess +1 blocker
<@adamwill:fedora.im>
17:29:08
lruzicka: i mean, sure, but that's a pretty drastic workaround.
<@nirik:matrix.scrye.com>
17:29:11
There are of course workarounds... but they are... not great
<@lruzicka:matrix.org>
17:29:12
I am playing a devil's advocate, because that's what I do best-
<@geraldosimiao:matrix.org>
17:29:23
I'll go with FinalBlocker +1
<@conan_kudo:matrix.org>
17:29:30
+1 blocker
<@brianc07:fedora.im>
17:29:33
+1
<@amoloney:fedora.im>
17:29:34
Im +1 blocker, it just reads too close to bad PR for me
<@thebeanogamer:fedora.im>
17:29:38
FinalBlocker +1
<@frantisekz:fedora.im>
17:29:41
+1
<@adamwill:fedora.im>
17:29:47
okey dokey
<@lruzicka:matrix.org>
17:29:57
so far to you I may
<@conan_kudo:matrix.org>
17:30:08
This is the release people are paying a lot of attention to
<@conan_kudo:matrix.org>
17:30:35
And having it not boot is pretty bad
<@sgallagh:fedora.im>
17:31:09
Hey, if it doesn't boot, they're not vulnerable to security issues!
<@adamwill:fedora.im>
17:31:09
proposed !agreed 2272758 - AcceptedBlocker (Final) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" for Plasma on affected systems. We know affected CPUs are a fairly small minority, but they're still hardware we intend to support, and the fact that multiple people reported this means there really are folks out there who want to run the affected software on the affected CPUs
<@geraldosimiao:matrix.org>
17:31:18
ack
<@nirik:matrix.scrye.com>
17:31:23
ack
<@frantisekz:fedora.im>
17:31:25
ack
<@amoloney:fedora.im>
17:31:27
ack
<@sgallagh:fedora.im>
17:31:31
ack
<@conan_kudo:matrix.org>
17:31:35
Ack
<@pboy:fedora.im>
17:31:35
ck
<@adamwill:fedora.im>
17:31:38
!agreed 2272758 - AcceptedBlocker (Final) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" for Plasma on affected systems. We know affected CPUs are a fairly small minority, but they're still hardware we intend to support, and the fact that multiple people reported this means there really are folks out there who want to run the affected software on the affected CPUs
<@pboy:fedora.im>
17:31:38
ck
<@adamwill:fedora.im>
17:31:45
!topic (2274490) nVidia RTX 3000 GPUs are inoperable in Fedora 40 (nouveau)
<@adamwill:fedora.im>
17:31:48
<@adamwill:fedora.im>
17:31:50
<@adamwill:fedora.im>
17:31:54
!info Proposed Blocker, kernel, NEW
<@brianc07:fedora.im>
17:31:56
ack
<@adamwill:fedora.im>
17:32:06
so the title of this one obviously sounds bad, but current testing suggests it's probably not accurate
<@sgallagh:fedora.im>
17:32:13
When did this one come in? Today?
<@frantisekz:fedora.im>
17:32:22
so for this one, the current candidate has stalled boot for 120 seconds and then boots with just the iGPU available
<@adamwill:fedora.im>
17:32:26
it might be more like "RTX 3000 GPUs in hybrid laptops" or "RTX x000 GPUs in hybrid laptops" or...something
<@frantisekz:fedora.im>
17:32:29
it apparently regressed in 6.8.x kernels
<@adamwill:fedora.im>
17:32:30
i'm trying to get more data
<@adamwill:fedora.im>
17:32:43
yeah, today
<@frantisekz:fedora.im>
17:32:51
the proposed scratch-built kernel still shows no nVidia GPU avail, but doesn't stall the boot for 120 seconds
<@frantisekz:fedora.im>
17:32:57
on my system
<@conan_kudo:matrix.org>
17:33:08
Do we have sample machines to troubleshoot this with?
<@jforbes:fedora.im>
17:33:19
I have nothing with nvidia here
<@adamwill:fedora.im>
17:33:30
Conan Kudo: who's "we"? this is why i sent out messages to test@ and discourse :)
<@nirik:matrix.scrye.com>
17:33:34
yeah, it's hard to vote on this one here... not enough info really....
<@adamwill:fedora.im>
17:33:43
could probably do a follow-up to say 'test all nvidia hybrid laptops", though
<@sgallagh:fedora.im>
17:33:49
Do we know if it's limited to 3xxx series?
<@frantisekz:fedora.im>
17:33:55
tflink said in the quality channel "F40 RC1.3 boots fine on my nvidia laptop"
<@sgallagh:fedora.im>
17:33:58
I have a desktop with a 4000 I could boot a Live on...
<@sgallagh:fedora.im>
17:34:08
But it's obviously not a hybrid system
<@adamwill:fedora.im>
17:34:15
jforbes: what's the story with the scratch build you sent? is that just an idea you had, or is it something from upstream?
<@conan_kudo:matrix.org>
17:34:18
I didn't observe this on my hybrid gtx 1650 system
<@sgallagh:fedora.im>
17:34:18
I have a desktop with a 4070 I could boot a Live on...
<@frantisekz:fedora.im>
17:34:25
laptop 3070 he said
<@frantisekz:fedora.im>
17:34:43
so it may not affect all the 3000 hybrid configs in the end
<@adamwill:fedora.im>
17:34:53
Stephen Gallagher: the other affected person on test@ says they have a Dell XPS 15 9500 with GTX 1650 Ti
<@frantisekz:fedora.im>
17:35:24
I mean, the hybrid design is a mess, it varies from hw to hw, it can have different wiring for video out...
<@adamwill:fedora.im>
17:35:51
so...it seems pretty fuzzy. basically we only know that frantisek's slimbook with a GTX 3000-series and AV's Dell with a GTX 1650 Ti hybrid seem to be affected by the same issue
<@jforbes:fedora.im>
17:35:56
adamw: it is a patch queued for 6.8.6, specifically https://lore.kernel.org/stable/20240411095425.054960679@linuxfoundation.org/
<@conan_kudo:matrix.org>
17:36:10
František Zatloukal: yeah, that might be why my Lenovo isn't affected
<@adamwill:fedora.im>
17:36:42
ah, k. so maybe we should let dave know about this bug and frantisek's result with that patch...
<@sgallagh:fedora.im>
17:36:45
Huh... I just noticed we don't have aarch64 Live images for Workstation on RC 13.
<@nirik:matrix.scrye.com>
17:36:58
yep.
<@adamwill:fedora.im>
17:37:10
Stephen Gallagher: yes, this is good old https://bugzilla.redhat.com/show_bug.cgi?id=2247319 .
<@sgallagh:fedora.im>
17:37:16
Not technically a blocker, but that sucks.
<@adamwill:fedora.im>
17:37:16
all help fixing that is gratefully received!
<@adamwill:fedora.im>
17:37:32
note, arm deployment is usually done from the disk images, not live ISOs.
<@sgallagh:fedora.im>
17:37:49
adamw: I've installed it on quite a few VMs
<@adamwill:fedora.im>
17:38:04
you can deploy on a VM from the disk image too...
<@sgallagh:fedora.im>
17:38:05
Usually from an Apple Silicon host
<@nirik:matrix.scrye.com>
17:38:26
anyhow, based on what we know I am inclined to -1 blocker +1 FE... given that it does boot, and the hardware affected is likely small... and could be fixed after release by updates. sorta
<@jmontleon:fedora.im>
17:38:31
I have an lenovo x1 gen 3 with a 1650 Ti Mobile I can try on and add a comment to the bug if it adds any value
<@conan_kudo:matrix.org>
17:38:33
Yep, it's the required media for vms on Macs
<@adamwill:fedora.im>
17:38:39
i wonder if we might want to use a de-optimized libblockdev that 'fixes' the sigill at least for the next rc compose, though. eh, i can talk that over with nirik later
<@conan_kudo:matrix.org>
17:38:51
Please do!
<@nirik:matrix.scrye.com>
17:39:06
we could try. I meant to ask tools folks to look at that bug, but didn't get enough time to do so
<@adamwill:fedora.im>
17:39:07
so, if we assume we are slipping for the other blocker (not waiving it), i'd be a punt on this
<@jforbes:fedora.im>
17:39:09
So, we do have ways to disable nouveau for hybrid configs, and a kernel update should fix it.
<@adamwill:fedora.im>
17:39:16
if we really have to make a decision i'd be a tentative -1
<@adamwill:fedora.im>
17:39:44
jforbes: well, frantisek said the patch gets rid of the boot delay but doesn't actually make the nvidia adapter work
<@conan_kudo:matrix.org>
17:39:46
I'm +1 FB on this, unfortunately
<@jforbes:fedora.im>
17:39:50
If we compare nouveau on a stock F39 kernel, it was pretty much useless too
<@frantisekz:fedora.im>
17:40:10
yeah, the scope of things it can do went from zero... :D
<@adamwill:fedora.im>
17:40:26
i guess on a hybrid system i wouldn't generally be +1 blocker if *one* of the GPUs works so you can see stuff out of the box, thinking about it
<@adamwill:fedora.im>
17:40:34
František Zatloukal: oh, it didn't work before either?
<@frantisekz:fedora.im>
17:41:02
it didn't do reclocking afaik, so the perf was useless, below the iGPU
<@adamwill:fedora.im>
17:41:10
ah
<@jforbes:fedora.im>
17:41:12
Correct
<@frantisekz:fedora.im>
17:41:30
I'd say +1 FE just to remove the boot stalling
<@jforbes:fedora.im>
17:41:30
Before 6.8, those GPUs pretty much required the nvidia driver.
<@adamwill:fedora.im>
17:41:33
so yeah, if we have to make a call right now i think i'm -1, given the uncertain impact
<@adamwill:fedora.im>
17:41:55
(and the previous not-great state on the same hw)
<@frantisekz:fedora.im>
17:42:24
yeah, -1 Blocker +1 FE sounds fine
<@sgallagh:fedora.im>
17:43:00
-1 FinalBlocker, +1 FinalFE
<@geraldosimiao:matrix.org>
17:43:04
FinalBlocker -1 FinalFE +1
<@lruzicka:matrix.org>
17:43:40
-1 FB, +1FE
<@jforbes:fedora.im>
17:43:41
I am okay with doing a 6.8.5-301 that will add the patch which gets rid of the delay, and has the bluetooth fix
<@conan_kudo:matrix.org>
17:44:07
If there was no patches ready, then I'd agree with the rest, but there are, so I'm still +1 FB
<@pboy:fedora.im>
17:44:22
I think -1 FB, it's too special and Nvidia
<@adamwill:fedora.im>
17:44:38
reminder again that granting an FE doesn't mean we *have* to pull it in (though personally, if we slip a week, i'm in favour of taking a new kernel)
<@jforbes:fedora.im>
17:44:39
Well, patch doesn't fix, it simply gets rid of the 120 second delay
<@pboy:fedora.im>
17:45:33
I would really prefer to keep kernel as is.
<@nirik:matrix.scrye.com>
17:45:35
right and we should be clear on what we want in a new kernel... not everything. ;)
<@adamwill:fedora.im>
17:45:37
proposed !agreed 2274490 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected based on current assessment that it seems to affect only some hybrid laptops which already didn't have great nouveau support before 6.8 series. it is annoying on those systems, but not fatal, can be fixed post-release, and we just don't think that's a broad enough impact to block on
<@nirik:matrix.scrye.com>
17:45:50
ack
<@amoloney:fedora.im>
17:45:55
ack
<@sgallagh:fedora.im>
17:46:00
ack
<@pboy:fedora.im>
17:46:01
ack
<@adamwill:fedora.im>
17:46:05
nirik: you want a cherry-picked 6.8.4 build or something? mehh. i'm fine with 6.8.5 anyway, let's argue about itlater
<@conan_kudo:matrix.org>
17:46:11
Reluctant ack
<@adamwill:fedora.im>
17:46:16
!agreed 2274490 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected based on current assessment that it seems to affect only some hybrid laptops which already didn't have great nouveau support before 6.8 series. it is annoying on those systems, but not fatal, can be fixed post-release, and we just don't think that's a broad enough impact to block on
<@adamwill:fedora.im>
17:46:56
!info 2274061 was accepted as an FE and fixed in 1.13, so we don't really need to worry about that one
<@jforbes:fedora.im>
17:46:59
Well, I wouldn't drop in 6.8.6, but 6.8.5 is already in testing and has some important fixes CVE and existing FEs
<@adamwill:fedora.im>
17:47:09
(well, 'fixed', we bodged it up enough that nobody complained yet)
<@conan_kudo:matrix.org>
17:47:15
We are going to have to consider these blocker worthy soon, though
<@adamwill:fedora.im>
17:47:17
!topic (2271837) The KDE help center does not show the documentation for KDE applications.
<@jforbes:fedora.im>
17:47:23
so adding fixes to it specifically
<@adamwill:fedora.im>
17:47:24
<@adamwill:fedora.im>
17:47:27
<@adamwill:fedora.im>
17:47:31
!info Accepted Blocker, khelpcenter, MODIFIED
<@adamwill:fedora.im>
17:47:44
This is technically already an accepted blocker, but it's changed a bit
<@adamwill:fedora.im>
17:48:01
we accepted it under original description, pulled in a proposed fix, closed it, forgot about it
<@adamwill:fedora.im>
17:48:12
then lruzicka tested it this morning and it turns out the fix we pulled in caused other problems
<@adamwill:fedora.im>
17:48:15
so now it's broken...differently
<@adamwill:fedora.im>
17:48:25
there is a better fix upstream we can pull that would hopefully fix it harder
<@geraldosimiao:matrix.org>
17:48:28
yeah
<@adamwill:fedora.im>
17:48:39
question now is, is the current breakage still blocking
<@lruzicka:matrix.org>
17:48:45
yeah, fix it harder
<@geraldosimiao:matrix.org>
17:48:45
the new fix is better than the old one
<@adamwill:fedora.im>
17:48:56
i'd at least say we should keep it as an FE, not sure if the current breakage is bad enough to be a blocker
<@sgallagh:fedora.im>
17:49:01
I'd kind of prefer if this was a new ticket, since it's not the same set of failures.
<@geraldosimiao:matrix.org>
17:49:09
thats something to think about really
<@adamwill:fedora.im>
17:49:19
might be clearer, but let's pretend it is for now, i can bureaucratize whatever we decide later
<@adamwill:fedora.im>
17:49:30
geraldosimiao: what do you think? you tested it the most, you and lukas
<@nirik:matrix.scrye.com>
17:49:35
Yeah, at least a FE...
<@geraldosimiao:matrix.org>
17:49:36
tha fix for the first one introduce other erros
<@geraldosimiao:matrix.org>
17:49:55
I think this is not soooo blockery
<@lruzicka:matrix.org>
17:49:56
When I first discovered this, I thought it would be withing one application. Then I realized it is global. Today, it still seems global to me.
<@lruzicka:matrix.org>
17:50:10
So the KDE Help Center looks broken.
<@geraldosimiao:matrix.org>
17:50:17
its something like +0.6 blocker
<@sgallagh:fedora.im>
17:50:17
The current breakage doesn't pass muster for "last blocker at Go/No-Go" for me, but I'd be good with an FE
<@sgallagh:fedora.im>
17:50:21
We're slipping anyway.
<@geraldosimiao:matrix.org>
17:51:08
It seems the new fix is ready and fix correctly this time, as I understood
<@adamwill:fedora.im>
17:51:22
yes. well, we need to verify it really does fix all the issues you saw
<@lruzicka:matrix.org>
17:51:23
The Help Center is in preinstalled applications that we do expect to work.
<@geraldosimiao:matrix.org>
17:51:26
just have to package it
<@adamwill:fedora.im>
17:51:26
but that's the presumption
<@lruzicka:matrix.org>
17:51:28
so we can block on it.
<@sgallagh:fedora.im>
17:51:34
We should take the new fix, but if it turns out not to be a 100% fix, I wouldn't block on it
<@adamwill:fedora.im>
17:51:42
i will do a build after the meeting (if nobody else gets to it first)
<@adamwill:fedora.im>
17:52:04
proposal: we bump this back to proposed blocker, accepted FE, and punt on it
<@frantisekz:fedora.im>
17:52:16
propasal +1
<@adamwill:fedora.im>
17:52:22
eh, that's kinda cowardly, but hey.
<@sgallagh:fedora.im>
17:52:25
adamw: +1
<@geraldosimiao:matrix.org>
17:52:40
ok, proposing: let keep it blocker and if it turns out to be something harder to fix or not so good, we discus later?
<@nirik:matrix.scrye.com>
17:52:46
sure, ok....
<@adamwill:fedora.im>
17:53:13
either way works practically speaking
<@amoloney:fedora.im>
17:53:15
I would be +1 to geraldosimiao
<@adamwill:fedora.im>
17:53:37
i guess as this is already an accepted blocker i can just !info it and we can massage it later
<@geraldosimiao:matrix.org>
17:53:50
it is already blocker
<@geraldosimiao:matrix.org>
17:53:55
just keep like this
<@adamwill:fedora.im>
17:54:09
!info this was partly but not fully addressed in RC-1.13, the fix introduced other problems. assuming we are going to slip for other blockers and do another RC-1.14, we will update to the improved upstream fix that should resolve all issues
<@adamwill:fedora.im>
17:54:19
that seem ok?
<@geraldosimiao:matrix.org>
17:54:28
ack
<@nirik:matrix.scrye.com>
17:54:30
sure...
<@amoloney:fedora.im>
17:54:32
sounds good to me
<@frantisekz:fedora.im>
17:54:37
lgtm
<@geraldosimiao:matrix.org>
17:54:41
ok
<@sumantrom:fedora.im>
17:54:52
Ack
<@adamwill:fedora.im>
17:55:02
!topic (2242759) dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key
<@adamwill:fedora.im>
17:55:05
<@adamwill:fedora.im>
17:55:07
<@adamwill:fedora.im>
17:55:10
!info Accepted Previous Release Blocker, distribution, NEW
<@adamwill:fedora.im>
17:55:16
aaand we still have this.
<@adamwill:fedora.im>
17:55:23
nobody came up with a genius fix yet. geniuses still welcome.
<@amoloney:fedora.im>
17:55:27
😥
<@nirik:matrix.scrye.com>
17:55:35
lets just set our clocks back before this bug was reported. ;)
<@frantisekz:fedora.im>
17:55:42
(at least we got rid of shim though... :D )
<@adamwill:fedora.im>
17:56:00
so, i guess we could vote to waive this and the other two blockers if we want to ship, but i'm getting the sense we don't really want to do that
<@amoloney:fedora.im>
17:56:04
time is just a construct anyway...
<@adamwill:fedora.im>
17:56:05
so i can just note that, yup, it's still here
<@conan_kudo:matrix.org>
17:56:22
Yeah, no
<@nirik:matrix.scrye.com>
17:56:54
there's some proposals... but where would that happen? dnf?
<@brianc07:fedora.im>
17:57:02
Not waiving these
<@amoloney:fedora.im>
17:57:20
I saw it suggested somewhere to maybe have this one as a common bugs if no fix can be found. Is that an option in case we are still in this position next week?
<@sgallagh:fedora.im>
17:57:46
It's been here for a couple releases now, no?
<@adamwill:fedora.im>
17:57:56
!info this is still outstanding. it is difficult to fix and hence a waiver candidate, but we're not going that route today as we have other blockers we don't want to waive. any great ideas to fix this are still welcome
<@amoloney:fedora.im>
17:58:16
it was in f39 for sure
<@adamwill:fedora.im>
17:58:16
Stephen Gallagher: this is the second it's been a blocker for, i think, but i think it did kinda exist before that, it's just becoming progressively more likely to affect more systems as time goes on, aiui
<@adamwill:fedora.im>
17:58:26
Aoife Moloney: sure, is it not one yet?
<@adamwill:fedora.im>
17:58:45
that info look good to everyone?
<@amoloney:fedora.im>
17:58:52
could be.. checking
<@amoloney:fedora.im>
17:58:58
and yes info is good for me
<@geraldosimiao:matrix.org>
17:59:10
that info looks good yes
<@conan_kudo:matrix.org>
17:59:58
This is the new shim bug 😨
<@amoloney:fedora.im>
18:00:07
adamw: yep its listed for f40 https://discussion.fedoraproject.org/t/f38-to-f39-40-dnf-system-upgrade-can-fail-on-raspberry-pi/92403
<@conan_kudo:matrix.org>
18:00:29
That is, it hangs around because it's hard to fix
<@adamwill:fedora.im>
18:00:37
alrighty
<@amoloney:fedora.im>
18:00:39
so theres some flexibility to waive if it comes down to this as a deal breaker
<@nirik:matrix.scrye.com>
18:00:43
it's no 998, but hey....
<@adamwill:fedora.im>
18:00:46
i think that concludes the blocker portion of the meeting
<@adamwill:fedora.im>
18:00:49
Aoife Moloney: sure, we waived it for f39
<@adamwill:fedora.im>
18:00:55
i would assume we'd waive it again if it's the last thing
<@geraldosimiao:matrix.org>
18:01:09
yup
<@adamwill:fedora.im>
18:01:15
if nobody has an actual plan to fix it, we can't really just sit around sucking our thumbs till someone comes up with one
<@conan_kudo:matrix.org>
18:01:20
Fair! 😂
<@adamwill:fedora.im>
18:01:39
at some point we can declare the pi 3 is too old to care about any more and it's not a blocker any more. a plan with no drawbacks!
<@sgallagh:fedora.im>
18:02:07
I thought this was the Pi 4...
<@jforbes:fedora.im>
18:02:09
kernel is now building as the 6.8.5 in testing now with only the BT FE and the nouveau improvement
<@frantisekz:fedora.im>
18:02:13
yeah, both
<@frantisekz:fedora.im>
18:02:33
basically any hw without hw clock i'd say
<@frantisekz:fedora.im>
18:02:37
would be affected
<@conan_kudo:matrix.org>
18:03:49
We also have cases where we don't bring up the RTC early enough, but that's somewhat rare I think
<@adamwill:fedora.im>
18:04:03
oh, sigh, pi 4 too? well great. anyhoo
<@conan_kudo:matrix.org>
18:04:35
It's forever...
<@nirik:matrix.scrye.com>
18:04:38
always install fresh pie
<@conan_kudo:matrix.org>
18:04:59
RTC is such a dumb thing to cheap out on
<@sgallagh:fedora.im>
18:05:00
mmmm pie
<@amoloney:fedora.im>
18:05:07
With a clear blocker having been found do we still need to go through the test matrices part of this meeting? Or could we call it?
<@amoloney:fedora.im>
18:05:16
Obvs with a poll of course
<@conan_kudo:matrix.org>
18:05:28
We can call it
<@conan_kudo:matrix.org>
18:05:53
We know it's no-go
<@adamwill:fedora.im>
18:06:04
yeah, i think we could short-circuit at this point
<@adamwill:fedora.im>
18:06:16
we should probably note the IoT issue too, though
<@amoloney:fedora.im>
18:06:36
cool, just wanted to double check so I didnt cut anything too short
<@geraldosimiao:matrix.org>
18:06:42
yeah, going to Final Target date #1 mostly
<@brianc07:fedora.im>
18:06:45
no-go
<@adamwill:fedora.im>
18:06:46
!info we also have an issue with the IoT installer image showing pre-release warnings: https://pagure.io/fedora-iot/issue/57 . That's to do with osbuild, the osbuild team is working on it
<@adamwill:fedora.im>
18:07:07
we would need to resolve that in time to do an IoT compose without pre-release warnings
<@adamwill:fedora.im>
18:07:15
before whenever the release date turns out to be
<@adamwill:fedora.im>
18:09:16
okay...proceed to voting :|
<@sgallagh:fedora.im>
18:09:21
IoT is blocking, isn't it?
<@adamwill:fedora.im>
18:09:26
yets
<@adamwill:fedora.im>
18:09:34
but not built as part of the regular compose
<@sgallagh:fedora.im>
18:09:50
That fails blocker criteria, then
<@nirik:matrix.scrye.com>
18:09:52
I'm fine with saying no go and ending. ;)
<@adamwill:fedora.im>
18:09:58
it has its own compose, and we give the iot team leeway to nominate the compose that gets shipped. it's usually one built a bit after the main compose, after the final stable push
<@sgallagh:fedora.im>
18:10:11
ah okay
<@amoloney:fedora.im>
18:10:15
!topic Go/No-Go decision
<@sgallagh:fedora.im>
18:10:17
But yeah, that needs fixing
<@adamwill:fedora.im>
18:10:44
Stephen Gallagher: yeah, it would be more sensitive if we were go this week. with a week's slip we should be able to figure it out one way or another.
<@amoloney:fedora.im>
18:11:07
Im going to poll the teams now, are you all ready?
<@geraldosimiao:matrix.org>
18:11:19
ok
<@geraldosimiao:matrix.org>
18:11:25
ready
<@adamwill:fedora.im>
18:11:27
sure!
<@amoloney:fedora.im>
18:11:48
here we go....
<@amoloney:fedora.im>
18:11:50
Please reply “go” or “no-go”
<@amoloney:fedora.im>
18:11:57
QA?
<@adamwill:fedora.im>
18:12:03
no-go
<@geraldosimiao:matrix.org>
18:12:07
no-go
<@amoloney:fedora.im>
18:12:17
FESCo?
<@sgallagh:fedora.im>
18:12:19
no-go
<@nirik:matrix.scrye.com>
18:12:20
no go 🏁
<@amoloney:fedora.im>
18:12:25
Rel-Eng?
<@nirik:matrix.scrye.com>
18:12:28
no go 🏁
<@amoloney:fedora.im>
18:12:48
Well rats
<@amoloney:fedora.im>
18:13:01
!agreed Fedora Linux 40 final is NO GO
<@amoloney:fedora.im>
18:13:28
!info The next F40 Final Go/No-Go meeting will be Thursday, 2024-04-18 at 1700 UTC
<@amoloney:fedora.im>
18:13:58
info F340Final shifts to target date #1: Tuesday 2024-04-23
<@frantisekz:fedora.im>
18:14:03
wow
<@frantisekz:fedora.im>
18:14:06
340
<@amoloney:fedora.im>
18:14:12
!info F340Final shifts to target date #1: Tuesday 2024-04-23
<@jforbes:fedora.im>
18:14:26
We've come a long way this year
<@geraldosimiao:matrix.org>
18:14:27
👀
<@amoloney:fedora.im>
18:14:32
!info F40 Final shifts to target date #1: Tuesday 2024-04-23
<@adamwill:fedora.im>
18:14:39
340 feels about right
<@geraldosimiao:matrix.org>
18:14:40
"doc, I1m from the future"
<@geraldosimiao:matrix.org>
18:14:51
"doc, I´m from the future"
<@brianc07:fedora.im>
18:14:52
300 versions shipped 👀️
<@jforbes:fedora.im>
18:14:58
Where we're going, we won't need kernels....
<@amoloney:fedora.im>
18:15:04
!action @amoloney to announce decision
<@frantisekz:fedora.im>
18:15:07
we should use that in our perf review QE team!
<@amoloney:fedora.im>
18:15:15
!topic Open Floor
<@sgallagh:fedora.im>
18:15:23
By that point, hopefully we're just booting directly from the galactic hive-mind
<@amoloney:fedora.im>
18:15:25
I dunno why I capitalized those...
<@amoloney:fedora.im>
18:15:34
anyway, anything else before I release you all?
<@jforbes:fedora.im>
18:15:47
something something kernelless.cloud
<@nirik:matrix.scrye.com>
18:16:11
singularities are great, everyone should have one!
<@amoloney:fedora.im>
18:17:37
Ok ye are all getting a bit silly now so Im ending the meeting :)
<@geraldosimiao:matrix.org>
18:17:47
fair
<@amoloney:fedora.im>
18:17:52
thank you all for your participation and see you same bat time, same bat channel
<@amoloney:fedora.im>
18:17:56
!endmeeting