<@adamwill:fedora.im>
16:00:51
!startmeeting F44-blocker-review
<@meetbot:fedora.im>
16:00:52
Meeting started at 2026-03-30 16:00:51 UTC
<@meetbot:fedora.im>
16:00:52
The Meeting name is 'F44-blocker-review'
<@adamwill:fedora.im>
16:00:54
!topic Roll Call
<@jgroman:fedora.im>
16:01:52
!hi
<@zodbot:fedora.im>
16:02:02
Jaroslav Groman (jgroman)
<@jcline:fedora.im>
16:02:05
!hi
<@zodbot:fedora.im>
16:02:08
Jeremy Cline (jcline) - he / him / his
<@derekenz:fedora.im>
16:02:18
!hi
<@zodbot:fedora.im>
16:02:19
Derek Enz (derekenz)
<@adamwill:fedora.im>
16:02:22
how's everyone doing, ready for blocker fun?
<@lruzicka:fedora.im>
16:02:50
!hi
<@zodbot:fedora.im>
16:02:52
Lukáš Růžička (lruzicka)
<@conan_kudo:matrix.org>
16:02:58
!hi
<@lruzicka:fedora.im>
16:02:59
Reddy for the meeting.
<@zodbot:fedora.im>
16:03:02
Neal Gompa (ngompa) - he / him / his
<@kparal:matrix.org>
16:04:07
!hi
<@zodbot:fedora.im>
16:04:09
Kamil Páral (kparal) - he / him / his
<@adamwill:fedora.im>
16:04:42
alrighty, let's get rolling
<@adamwill:fedora.im>
16:05:37
!link http://qa.fedoraproject.org/blockerbugs/current
<@adamwill:fedora.im>
16:05:37
!topic Introduction
<@adamwill:fedora.im>
16:05:37
Why are we here?
<@adamwill:fedora.im>
16:05:37
!info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
<@adamwill:fedora.im>
16:05:37
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
16:05:37
!link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
<@adamwill:fedora.im>
16:05:37
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
16:05:37
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
16:05:37
!link https://fedoraproject.org/wiki/Basic_Release_Criteria
<@adamwill:fedora.im>
16:05:37
!link https://fedoraproject.org/wiki/Fedora_44_Beta_Release_Criteria
<@adamwill:fedora.im>
16:05:37
!link https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria
<@adamwill:fedora.im>
16:05:52
!info for Final, we have:
<@adamwill:fedora.im>
16:05:52
!info 3 Accepted Blockers
<@adamwill:fedora.im>
16:05:52
!info 3 Proposed Blockers
<@adamwill:fedora.im>
16:05:57
!info 2 Proposed Freeze Exceptions
<@adamwill:fedora.im>
16:05:57
!info 3 Accepted Freeze Exceptions
<@adamwill:fedora.im>
16:06:04
who wants to secretarialize?
<@kparal:matrix.org>
16:08:30
I can
<@lruzicka:fedora.im>
16:09:13
I can, too
<@lruzicka:fedora.im>
16:09:37
But if Kamil wants it
<@adamwill:fedora.im>
16:10:13
hehe
<@adamwill:fedora.im>
16:10:22
!info kparal and/or lruzicka can fight over secretary duties
<@kparal:matrix.org>
16:11:04
I yield!
<@adamwill:fedora.im>
16:11:18
ok, let's get started with:
<@adamwill:fedora.im>
16:11:23
!topic Proposed Final blockers
<@adamwill:fedora.im>
16:11:32
!link https://bugzilla.redhat.com/show_bug.cgi?id=2451701
<@adamwill:fedora.im>
16:11:32
!link https://pagure.io/fedora-qa/blocker-review/issue/2082
<@adamwill:fedora.im>
16:11:32
!topic (2451701) ngtcp2-crypto-gnutls-1.21.0-1.fc43.aarch64 requires ngtcp2(aarch-64) = 1.21.0-1.fc43, but none of the providers can be installed
<@adamwill:fedora.im>
16:11:32
!info Proposed Blocker, ngtcp2, NEW, depends on other bugs
<@adamwill:fedora.im>
16:14:10
so this one's interesting because openQA tests don't see the same as Petr
<@adamwill:fedora.im>
16:14:14
I don't know why not
<@adamwill:fedora.im>
16:14:29
in openQA, dnf downgrades ngtcp2 packages and the upgrade succeeds, which is what I'd expect
<@adamwill:fedora.im>
16:15:03
in any case, the update is stable now so this particular issue ought to be resolved, but i'd love to know why we got different results
<@kparal:matrix.org>
16:17:40
he uses aarch64, that might be a difference?
<@kparal:matrix.org>
16:17:57
also he's using TMT-provisioned machines which have some kind of extra repo added
<@kparal:matrix.org>
16:18:08
also he uses TMT-provisioned machines which have some kind of extra repo added
<@adamwill:fedora.im>
16:18:32
the openQA test i referred to is aarch654
<@lruzicka:fedora.im>
16:18:33
I linked a bug which also prevents upgrades and which happened on x86_64.
<@adamwill:fedora.im>
16:18:35
the openQA test i referred to is aarch64
<@lruzicka:fedora.im>
16:18:59
In my case, the situation cannot be fixed with `--enable-repo=updates-testing`
<@lruzicka:fedora.im>
16:19:17
It only happens on DVD, not on Netinst.
<@adamwill:fedora.im>
16:19:18
is that with this same package?
<@adamwill:fedora.im>
16:19:26
if not, it's a different bug and we'll get to it
<@lruzicka:fedora.im>
16:19:45
No, a different one. But I haven't proposed it as a blocker.
<@lruzicka:fedora.im>
16:19:58
https://bugzilla.redhat.com/show_bug.cgi?id=2452216
<@lruzicka:fedora.im>
16:20:33
I have a theory that openQA does not hit, because it starts from a kickstarted installation and not from a Live or DVD ISO.
<@adamwill:fedora.im>
16:20:40
oh, that one. it works with --allowerasing , right? i think that makes it not a blocker.
<@lruzicka:fedora.im>
16:20:50
I have a theory that openQA does not hit it, because it starts from a kickstarted installation and not from a Live or DVD ISO.
<@adamwill:fedora.im>
16:21:02
openQA tries with --allowerasing if the upgrade fails without it, but i think i checked and it doesn't actually hit that path atm, so still a mystery
<@adamwill:fedora.im>
16:21:36
anyhoo
<@adamwill:fedora.im>
16:21:45
for this bug: I propose we punt and ask petr to re-check, as it should be fixed
<@derekenz:fedora.im>
16:22:01
Punt
<@lruzicka:fedora.im>
16:22:14
+1 punt
<@conan_kudo:matrix.org>
16:22:48
punt +1
<@kparal:matrix.org>
16:24:30
wfm
<@adamwill:fedora.im>
16:24:42
proposed !agreed 2451701 - punt (delay decision) - in theory we'd like to clarify why Petr's testing and openQA got different results, but in practice we suspect this is now fixed anyway because the update is now stable. So we'll just ask Petr to re-test and expect the result to be "it's fine now" and the bug to be closed
<@derekenz:fedora.im>
16:25:22
ack
<@kparal:matrix.org>
16:25:37
ack
<@jgroman:fedora.im>
16:25:42
ack
<@adamwill:fedora.im>
16:26:03
!agreed 2451701 - punt (delay decision) - in theory we'd like to clarify why Petr's testing and openQA got different results, but in practice we suspect this is now fixed anyway because the update is now stable. So we'll just ask Petr to re-test and expect the result to be "it's fine now" and the bug to be closed
<@adamwill:fedora.im>
16:27:50
!info Ticket vote: FinalBlocker (+1,0,-0) (+asciiwolf)
<@adamwill:fedora.im>
16:27:50
!info Proposed Blocker, plasma-keyboard, NEW
<@adamwill:fedora.im>
16:27:50
!link https://pagure.io/fedora-qa/blocker-review/issue/2081
<@adamwill:fedora.im>
16:27:50
!link https://bugzilla.redhat.com/show_bug.cgi?id=2449945
<@adamwill:fedora.im>
16:27:50
!topic (2449945) KDE editor (kwrite, kate...) corrupts text on selection
<@kparal:matrix.org>
16:30:09
+1 blocker
<@adamwill:fedora.im>
16:30:09
disabling on-screen keyboard entirely seems sort of a radical 'solution'
<@adamwill:fedora.im>
16:30:18
(and has significant consequences for tablets and a11y)
<@adamwill:fedora.im>
16:30:33
but we don't have to litigate it here i guess
<@kparal:matrix.org>
16:30:38
https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Default_application_functionality
<@kparal:matrix.org>
16:30:38
for text editor and file manager, at least
<@adamwill:fedora.im>
16:31:31
yeah, +1
<@derekenz:fedora.im>
16:32:08
FinalBlocker +1
<@adamwill:fedora.im>
16:33:58
proposed !agreed 2449945 - AcceptedBlocker (Final) - accepted as a violation of Final criterion "For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test: ... text editor"
<@derekenz:fedora.im>
16:34:11
ack
<@jgroman:fedora.im>
16:34:16
ack
<@conan_kudo:matrix.org>
16:34:23
ack
<@lruzicka:fedora.im>
16:34:30
ack
<@adamwill:fedora.im>
16:35:14
!agreed 2449945 - AcceptedBlocker (Final) - accepted as a violation of Final criterion "For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test: ... text editor"
<@adamwill:fedora.im>
16:35:23
!link https://pagure.io/fedora-qa/blocker-review/issue/2078
<@adamwill:fedora.im>
16:35:23
!topic (2448283) Selecting a non-ASCII capable keyboard layout should automatically also select US English as a second layout
<@adamwill:fedora.im>
16:35:23
!link https://bugzilla.redhat.com/show_bug.cgi?id=2448283
<@adamwill:fedora.im>
16:35:23
!info Proposed Blocker, plasma-setup, NEW
<@adamwill:fedora.im>
16:35:47
so this one was discussed last week, but i decided to un-accept it so we can discuss it again based on lruzicka's testing
<@lruzicka:fedora.im>
16:37:53
My findings are here: https://bugzilla.redhat.com/show_bug.cgi?id=2448283#c2
<@kparal:matrix.org>
16:38:17
this is a mess
<@adamwill:fedora.im>
16:38:21
also, there's a bit of development this morning: Michael Catanzaro noticed/remembered that what we intend to do for the GNOME case is just *skip those pages entirely*
<@kparal:matrix.org>
16:38:41
do we have a "this is a mess" criterion?
<@adamwill:fedora.im>
16:38:44
since webui already covers language and input config, g-i-s should not do it, and rely on whatever the user picked in webui
<@adamwill:fedora.im>
16:39:06
this is what we did at some point in the past, but then we put the pages back in a couple of releases ago because, at that point, webui didn't have language/input config
<@conan_kudo:matrix.org>
16:39:12
that breaks down for OEM provisioning though
<@adamwill:fedora.im>
16:39:12
now it does, we should be able to just take them out again
<@adamwill:fedora.im>
16:39:17
i'm asking kde team if we can do the same for kde
<@conan_kudo:matrix.org>
16:39:34
the whole point of g-i-s and p-s is that we are explicitly assuming every install is equivalent to an OEM install
<@conan_kudo:matrix.org>
16:39:48
taking those pages out defeats that
<@adamwill:fedora.im>
16:39:51
that's certainly not how we've been drawing it up for workstation at least
<@adamwill:fedora.im>
16:40:19
for workstation the design for several releases has been that g-i-s should run on first *live* boot, cover this, then anaconda and post-install should accept what it did
<@adamwill:fedora.im>
16:40:36
but for right now we seem to be at the 'webui should do it and post-install g-i-s should go with what it did' stage
<@conan_kudo:matrix.org>
16:40:52
but that hasn't happened yet
<@adamwill:fedora.im>
16:41:03
for workstation the design for several releases has been that g-i-s should run on first *live* boot, cover this, then anaconda and post-install should accept what it did. we had a test implementation of this for a while but it never got upstreamed and now it's stuck
<@conan_kudo:matrix.org>
16:41:14
errgh
<@adamwill:fedora.im>
16:41:21
the full design hasn't, no, but 'rely on what webui did' seems reasonable and i'm pretty sure we did it before
<@lruzicka:fedora.im>
16:41:30
GIS goes with what webui chose, afaik, the choices are clearly made in GIS, so if you just hit Next, it is fine.
<@adamwill:fedora.im>
16:41:45
OEMs are not in the release criteria...and since they are using custom images they could change the g-i-s / p-s config back themselves, potentially
<@adamwill:fedora.im>
16:42:04
Lukáš Růžička it doesn't clearly indicate that it picked up what you did in webui, though
<@conan_kudo:matrix.org>
16:42:09
yes, but it doesn't hide the page
<@conan_kudo:matrix.org>
16:42:17
hiding the page entirely is very different
<@adamwill:fedora.im>
16:42:21
for keyboard layout it just says "English (US)", it doesn't indicate that in fact it's actually going to go with the correct switched layout
<@conan_kudo:matrix.org>
16:42:45
pre-selecting makes sense, hiding doesn't
<@conan_kudo:matrix.org>
16:43:14
one reason it doesn't is that there's literally no way to provision a Linux system without a language being set
<@lruzicka:fedora.im>
16:44:08
I am checking right now, if going through the GIS settings reveals something.
<@adamwill:fedora.im>
16:44:15
don't bother, i'm already at it :)
<@adamwill:fedora.im>
16:44:32
that's what you get on the layout page
<@adamwill:fedora.im>
16:44:39
that ticked entry says "English (USA)"
<@adamwill:fedora.im>
16:45:34
there is no indication that what's actually configured is switched US English / Russian, and *during g-i-s itself*, layout switching doesn't appear to be available
<@adamwill:fedora.im>
16:46:37
hmm. that's weird - on this install I just ran, i did actually wind up with a pure us english layout. even after g-i-s, no russian.
<@adamwill:fedora.im>
16:46:57
but I think on the one I ran last night, i got the same as you, the switched layout was configured even though g-i-s didn't indicate it
<@adamwill:fedora.im>
16:47:18
ohhh, wait, duh. i didn't do the config at install time. sigh
<@adamwill:fedora.im>
16:50:05
what did you find, lruzicka?
<@lruzicka:fedora.im>
16:51:42
I found that GIS selects the language I chose, see
<@lruzicka:fedora.im>
16:52:24
I only shows English as a layout (but I kept is a primary layout)
<@lruzicka:fedora.im>
16:53:23
And I end up with functional multi layout:
<@lruzicka:fedora.im>
16:53:25
Tested right now
<@lruzicka:fedora.im>
16:53:43
It only shows English as a layout (but I kept is a primary layout)
<@lruzicka:fedora.im>
16:53:54
It only shows English as a layout (but I kept it a primary layout)
<@adamwill:fedora.im>
16:54:00
yeah, so that's what i found too - the layout page doesn't indicate that you actually have a correct switched config
<@adamwill:fedora.im>
16:54:20
still, it's less confusing than the KDE state, and you're probably *more* likely to accept the default and proceed
<@adamwill:fedora.im>
16:54:44
so, hmm, as kparal said, this is a mess
<@lruzicka:fedora.im>
16:55:07
I could achieve the same with KDE, too.
<@lruzicka:fedora.im>
16:55:15
Shall I try again?
<@adamwill:fedora.im>
16:55:33
yes, but since KDE shows *nothing at all* as being selected on the layout page, I argue users are very likely to click something, which is the wrong choice
<@adamwill:fedora.im>
16:55:49
i don't think just clicking "Next" on a page which shows *no layout selected at all* is the natural action
<@lruzicka:fedora.im>
16:56:05
Sure, if they click something, then it probably breaks the setup.
<@adamwill:fedora.im>
16:56:24
if they click US English, it's a minor inconvenience; if they click Russian (or whatever), the system is basically broken unless they go back and change it.
<@adamwill:fedora.im>
16:57:36
aside from that, for KDE I think we do have a technical criteria violation - the criteria say "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... In the "initial setup" utility (if applicable)", but in my testing that wasn't the case. even if p-s does set up the switched config in the *installed* system if you just click through the empty layout page, the switched layout is not used *in p-s itself*
<@conan_kudo:matrix.org>
16:58:46
yes, that I agree with
<@adamwill:fedora.im>
16:59:05
but you could argue that requirement is a bit unnecessary for switched layout cases
<@adamwill:fedora.im>
16:59:16
because almost anything you want to type in an initial setup tool is gonna be with the ASCII layout
<@adamwill:fedora.im>
16:59:30
i sort of want to rewrite the criterion a bit with different requirements for switched layouts, but that's getting even messier...
<@adamwill:fedora.im>
16:59:45
because almost anything you want to type in an initial setup tool is gonna be with the ASCII layout, which in practice is almost always US English or something almost identical to it
<@adamwill:fedora.im>
17:00:02
because almost anything you want to type in an initial setup tool is gonna be with the ASCII layout, which in practice is almost always US English or something sufficiently similar to it that it will always be a workable alterntaive
<@adamwill:fedora.im>
17:00:06
because almost anything you want to type in an initial setup tool is gonna be with the ASCII layout, which in practice is almost always US English or something sufficiently similar to it that it will always be a workable alternative
<@adamwill:fedora.im>
17:00:33
oh, yeah, there's also the thing i found where it seems like layout switching in the installer itself doesn't actually work in KDE, though that has the same caveat (it's not *really* necessary)
<@adamwill:fedora.im>
17:01:02
let's see. freeze is tomorrow
<@adamwill:fedora.im>
17:01:13
we still have...ten days till first go/no-go
<@adamwill:fedora.im>
17:01:30
maybe we need to punt this and spend some time carving it up into a few different more accurate issues we can consider separately
<@adamwill:fedora.im>
17:02:09
wdyt?
<@conan_kudo:matrix.org>
17:03:13
yeah that makes sense to me
<@lruzicka:fedora.im>
17:03:19
We can do it.
<@conan_kudo:matrix.org>
17:03:29
we should also talk to Merritt and get these prioritized as they are carved up
<@lruzicka:fedora.im>
17:03:30
Will this be considered a hard to fix?
<@adamwill:fedora.im>
17:03:37
some bits of it might be, i guess
<@conan_kudo:matrix.org>
17:03:45
have to ask Merritt about it
<@adamwill:fedora.im>
17:03:48
i think once we cut it up into separate bits we can get a clearer picture of what's feasible to fix
<@adamwill:fedora.im>
17:04:08
michael said he's going to put the 'hide the pages in g-i-s' thing in an update we'll need for a blocker anyway
<@adamwill:fedora.im>
17:04:24
so that should mostly cover workstation, assuming we re-test and it works as intended
<@adamwill:fedora.im>
17:07:53
proposed !agreed 2448283 - punt (delay decision) - further testing has indicated there are several issues here, none of which is quite as clear-cut as first thought. we will delay the decision here so we can split this into several more specific reports that each be considered on their own merits
<@derekenz:fedora.im>
17:08:04
ack
<@jgroman:fedora.im>
17:08:33
ack
<@kparal:matrix.org>
17:08:50
ack
<@lruzicka:fedora.im>
17:08:53
ack
<@adamwill:fedora.im>
17:08:58
!agreed 2448283 - punt (delay decision) - further testing has indicated there are several issues here, none of which is quite as clear-cut as first thought. we will delay the decision here so we can split this into several more specific reports that each be considered on their own merits
<@adamwill:fedora.im>
17:09:16
ok, let's move on to:
<@adamwill:fedora.im>
17:09:21
!topic Proposed Final freeze exceptions
<@adamwill:fedora.im>
17:09:29
!link https://bugzilla.redhat.com/show_bug.cgi?id=2444726
<@adamwill:fedora.im>
17:09:29
!info Proposed Freeze Exceptions, firefox, NEW
<@adamwill:fedora.im>
17:09:29
!link https://pagure.io/fedora-qa/blocker-review/issue/2084
<@adamwill:fedora.im>
17:09:29
!topic (2444726) Workstation live Installer sometimes apparently freezes near the end, logs indicate install actually completed
<@adamwill:fedora.im>
17:09:29
!info Ticket vote: FinalFreezeException (+2,0,-0) (+derekenz, +asciiwolf)
<@adamwill:fedora.im>
17:09:41
so...is the thesis here that this is RAM related?
<@adamwill:fedora.im>
17:09:45
if so, what are we proposing to do about it?
<@decathorpe:fedora.im>
17:10:26
why is this a firefox bug?
<@kparal:matrix.org>
17:10:47
+1 FE
<@supakeen:fedora.im>
17:10:55
I guess because on workstation the installer runs in Firefox, which is thin.
<@supakeen:fedora.im>
17:10:57
!hi
<@zodbot:fedora.im>
17:10:58
Simon de Vlieger (supakeen) - he / him / his
<@decathorpe:fedora.im>
17:11:13
this has been happening to me with GTK-based anaconda for years, including on c10s. though I think I've only ever seen it in VMs, it looks like the VM locks up during bootloader installation.
<@lruzicka:fedora.im>
17:11:30
+1 FE
<@adamwill:fedora.im>
17:11:41
I mainly put it on firefox because it doesn't appear to ever happen on KDE
<@adamwill:fedora.im>
17:11:43
which uses slitherer
<@adamwill:fedora.im>
17:12:22
the openQA case definitely appears new. i do not remember ever seeing this before the f44 cycle.
<@adamwill:fedora.im>
17:12:43
the VM is not 'locked up', either - we can switch to a VT and collect logs fine
<@decathorpe:fedora.im>
17:13:06
hm, ok. very similar but slightly different symptoms then :(
<@decathorpe:fedora.im>
17:14:12
I've just come to accept the fact that installs in VMs appear borked during the "configuring" stage, but things appear to actually have installed correctly when you force-reset the VM 🙃
<@adamwill:fedora.im>
17:14:49
https://openqa.fedoraproject.org/tests/4519370#next_previous is the openQA test log for aarch64 F45 KDE live install - note there's only one '_do_install_and_reboot' failure, and it's not this bug. https://openqa.fedoraproject.org/tests/4519372#next_previous is the Workstation log - note how many do_install_and_reboot failures there are, and most of them are this
<@decathorpe:fedora.im>
17:15:02
anyway +1 FE
<@decathorpe:fedora.im>
17:15:05
sorry for the tangent :)
<@adamwill:fedora.im>
17:16:11
https://openqa.fedoraproject.org/tests/4519906#next_previous is F43 aarch64 workstation - there's a few do_install_and_reboot fails, but i just clicked through and none of them are this, they're all something else
<@adamwill:fedora.im>
17:17:04
hmmm
<@adamwill:fedora.im>
17:17:34
ah, I wrote in the original descriptio "This never seems to happen on KDE (where the installer UI runs in slitherer). It seems like it's happening more often on Rawhide than on F44, but that *could* just be chance." - I guess it's not,as the pattern has continued
<@adamwill:fedora.im>
17:17:47
ah, I wrote in the original description "This never seems to happen on KDE (where the installer UI runs in slitherer). It seems like it's happening more often on Rawhide than on F44, but that *could* just be chance." - I guess it's not chance, as the pattern has continued
<@decathorpe:fedora.im>
17:17:57
from what I can tell it has more to do with how the VM is configured on the host than the actual guest
<@decathorpe:fedora.im>
17:18:18
assuming that it's a variation of the same bug
<@adamwill:fedora.im>
17:19:01
hmm, anyway. i guess i can be +1 FE in principle if someone finds a magic fix for this somehow
<@supakeen:fedora.im>
17:20:21
+1 FE, I don't know if there are good ways to debug a hung Firefox.
<@adamwill:fedora.im>
17:21:26
proposed !agreed 2444726 - AcceptedFreezeException (Final) - there seem to be various mysterious aspects to this, but we agree that if somebody somehow figures out what's going on and finds a safe fix, the issue certainly qualifies as an FE in principle (it's a very visible and apparently-critical issue that can't be fixed with an update, even if in *fact* the install probably went fine and will work on reboot)
<@lruzicka:fedora.im>
17:21:51
ack
<@derekenz:fedora.im>
17:21:56
ack
<@supakeen:fedora.im>
17:22:10
ack
<@adamwill:fedora.im>
17:22:45
!agreed 2444726 - AcceptedFreezeException (Final) - there seem to be various mysterious aspects to this, but we agree that if somebody somehow figures out what's going on and finds a safe fix, the issue certainly qualifies as an FE in principle (it's a very visible and apparently-critical issue that can't be fixed with an update, even if in fact the install probably went fine and will work on reboot)
<@adamwill:fedora.im>
17:22:57
!link https://bugzilla.redhat.com/show_bug.cgi?id=2450672
<@adamwill:fedora.im>
17:22:57
!topic (2450672) Black screen after installing a number of updates including dpkg + grub
<@adamwill:fedora.im>
17:22:57
!link https://pagure.io/fedora-qa/blocker-review/issue/2085
<@adamwill:fedora.im>
17:22:57
!info Proposed Freeze Exceptions, grub2, NEW
<@adamwill:fedora.im>
17:23:57
i guess i can be +1 FE to this in principle, on the 'fixing upgrades during freeze is a good idea' precedent
<@conan_kudo:matrix.org>
17:25:37
dpkg? :o
<@conan_kudo:matrix.org>
17:25:46
+1 FE
<@derekenz:fedora.im>
17:26:16
FE +1
<@supakeen:fedora.im>
17:26:17
+1 FE but does this belong in the blocker review? I don't think it'd affect any of our deliverables if it indeed only affects people with set themes *and* the update is also in 43?
<@supakeen:fedora.im>
17:26:29
+1 FE but does this belong in the 44 blocker review? I don't think it'd affect any of our deliverables if it indeed only affects people with set themes _and_ the update is also in 43?
<@jcline:fedora.im>
17:26:36
Yeah, FE +1. No idea how common grub themes are, but clearly someone is using htem
<@adamwill:fedora.im>
17:26:58
we're in FE review, not blocker review :)
<@adamwill:fedora.im>
17:27:00
they'er combined
<@adamwill:fedora.im>
17:27:18
this would be a proposed blocker if it affected any kinda default install
<@supakeen:fedora.im>
17:27:32
Right, just that this also affect 43 since it was also shipped there :)
<@adamwill:fedora.im>
17:28:08
yeah, but we don't freeze updates for f43
<@adamwill:fedora.im>
17:28:13
so the fix can go to f43 as soon as it's ready
<@supakeen:fedora.im>
17:28:18
True :)
<@adamwill:fedora.im>
17:29:35
proposed !agreed 2450672 - AcceptedFreezeException (Final) - this is accepted on the basis that it's a pretty bad experience if you have the config that triggers this, and you can potentially hit it on upgrade to F44 during freeze since updates-testing repo is not enabled by default on stable releases, and we want to avoid that happening if possible
<@supakeen:fedora.im>
17:29:55
ack
<@supakeen:fedora.im>
17:30:05
ack, thanks for the additional clarification on that.
<@jgroman:fedora.im>
17:30:25
ack
<@derekenz:fedora.im>
17:30:25
ack
<@kparal:matrix.org>
17:30:44
ack
<@adamwill:fedora.im>
17:30:50
!agreed 2450672 - AcceptedFreezeException (Final) - this is accepted on the basis that it's a pretty bad experience if you have the config that triggers this, and you can potentially hit it on upgrade to F44 during freeze since updates-testing repo is not enabled by default on stable releases, and we want to avoid that happening if possible
<@adamwill:fedora.im>
17:31:09
meanwhile, a new proposed blocker emerged
<@adamwill:fedora.im>
17:31:15
!link https://pagure.io/fedora-qa/blocker-review/issue/2086
<@adamwill:fedora.im>
17:31:15
!info Proposed Blocker, systemd, NEW
<@adamwill:fedora.im>
17:31:15
!topic (2453005) systemd-oomd.service is not enabled on some systems
<@adamwill:fedora.im>
17:31:15
!link https://bugzilla.redhat.com/show_bug.cgi?id=2453005
<@adamwill:fedora.im>
17:31:35
!info NOTE: this is a new proposed blocker, we are back in blocker review, sorry for not noting it clearly
<@adamwill:fedora.im>
17:31:44
this seems a bit fuzzy ATM
<@supakeen:fedora.im>
17:33:53
It hasn't been touched in a pretty long time. I think a punt is in order to ask more questions (e.g. I'd be interested in knowing what's actually in their preset files).
<@adamwill:fedora.im>
17:34:01
it's potentially a blocker if we can prove it affects upgrades from a cleanly installed/updated F42/F43, I guess
<@adamwill:fedora.im>
17:34:14
but on the whole yeah, i was thinking punt
<@supakeen:fedora.im>
17:34:59
I see you already mentioned the relevant file so let's see what's in it and then go from there on what might (or might not) cause it.
<@supakeen:fedora.im>
17:36:00
There *might* be some rare situation where `systemctl preset-all` didn't get called in some code-path at some point in time; however unlikely? E.g. not considered a first-boot or something after installation.
<@adamwill:fedora.im>
17:36:07
proposed !agreed 2453005 - punt (delay decision) - there seems to be a lot of uncertainty about this ATM. we will wait for more info from the reporter, and possibly some independent re-testing of clean f42 / f43 installs and upgrades, to make the determination
<@derekenz:fedora.im>
17:36:13
ack
<@supakeen:fedora.im>
17:36:14
ack
<@jgroman:fedora.im>
17:36:40
ack
<@adamwill:fedora.im>
17:37:03
!agreed 2453005 - punt (delay decision) - there seems to be a lot of uncertainty about this ATM. we will wait for more info from the reporter, and possibly some independent re-testing of clean f42 / f43 installs and upgrades, to make the determination
<@adamwill:fedora.im>
17:37:10
ok, let's take a quick look through:
<@adamwill:fedora.im>
17:37:14
!topic Accepted Final blockers
<@adamwill:fedora.im>
17:37:21
!info Accepted Blocker, mesa, NEW
<@adamwill:fedora.im>
17:37:21
!topic (2359799) Inital-setup: VK_ERROR_DEVICE_LOST using nvidia hardware
<@adamwill:fedora.im>
17:37:21
!link https://bugzilla.redhat.com/show_bug.cgi?id=2359799
<@adamwill:fedora.im>
17:37:21
!link https://pagure.io/fedora-qa/blocker-review/issue/2074
<@adamwill:fedora.im>
17:37:32
sadly still just sorta sitting around, we really need...someone...to figure out what the heck to do about it
<@adamwill:fedora.im>
17:39:54
anyone got any bright ideas?
<@supakeen:fedora.im>
17:40:22
No NVIDIA in this household either.
<@conan_kudo:matrix.org>
17:40:24
I have no hardware either, but I wonder if this is the root issue for the crashes I've got reports on with nvidia
<@adamwill:fedora.im>
17:41:37
!action adamw to try and find someone who can investigate this
<@adamwill:fedora.im>
17:42:18
!info we are still kinda stuck waiting for any kinda technical investigation here, I will try and find someone who is able to look into it
<@adamwill:fedora.im>
17:42:24
!link https://bugzilla.redhat.com/show_bug.cgi?id=2446745
<@adamwill:fedora.im>
17:42:24
!topic (2446745) gnome-initial-setup does not enable third party repos
<@adamwill:fedora.im>
17:42:24
!info Accepted Blocker, selinux-policy, MODIFIED
<@adamwill:fedora.im>
17:42:24
!link https://pagure.io/fedora-qa/blocker-review/issue/2080
<@adamwill:fedora.im>
17:42:51
!info this got re-opened today because the SELinux fix was necessary but not sufficient, a gnome-initial-setup fix is also needed. mcatanzaro is on it
<@adamwill:fedora.im>
17:44:04
!topic (2391723) `shim-ia32` missing since `shim-15.8-4`
<@adamwill:fedora.im>
17:44:04
!info Accepted Blocker, shim, ON_QA
<@adamwill:fedora.im>
17:44:04
!link https://bugzilla.redhat.com/show_bug.cgi?id=2391723
<@adamwill:fedora.im>
17:44:04
!link https://pagure.io/fedora-qa/blocker-review/issue/2075
<@supakeen:fedora.im>
17:44:17
So the above should be complete but I don't think anyone has tested on real hardware yet.
<@supakeen:fedora.im>
17:44:31
Just before this meeting I've sent off an email to Hans to see if he has time to test on hardware.
<@supakeen:fedora.im>
17:44:56
We verified at least the `image-builder` ISO's with the following virtualized thing: https://github.com/osbuild/images/pull/1604#issuecomment-4045838167 (which is a bit annoying as 32-bit openedk isn't shipped on newer Fedora's).
<@adamwill:fedora.im>
17:45:06
this looks it should be fixed, we just need confirmation...
<@adamwill:fedora.im>
17:45:24
!info we believe all necessary bits of this are now done, but it would be good to get confirmation from someone with real hardware
<@adamwill:fedora.im>
17:46:10
!topic (2448365) rpi4 fails to boot from usb drive after upgrade to RC3
<@adamwill:fedora.im>
17:46:10
!link https://bugzilla.redhat.com/show_bug.cgi?id=2448365
<@adamwill:fedora.im>
17:46:10
!info Accepted Blocker, uboot-tools, ASSIGNED
<@adamwill:fedora.im>
17:46:10
!link https://pagure.io/fedora-qa/blocker-review/issue/2079
<@supakeen:fedora.im>
17:46:52
I'm planning on verifying the above with the latest u-boot build currently in Bodhi (which also enabled NVMe booting on the Pi 5 \o/).
<@adamwill:fedora.im>
17:48:10
thanks.
<@adamwill:fedora.im>
17:48:38
!info we are still waiting on a fix here, and/or for Peter to clarify what "context" is needed. Simon will test the latest uboot build and see if it changes things here
<@supakeen:fedora.im>
17:50:46
FWIW it can happen that USB boot doesn't work from *some* USB sticks/disks but works from others; from what I recall it has something to do with how quickly they come up after the bus gets reset or such but I'll see.
<@adamwill:fedora.im>
17:51:00
fun
<@adamwill:fedora.im>
17:51:15
ok, I guess that's everything
<@adamwill:fedora.im>
17:51:17
!topic Open floor
<@adamwill:fedora.im>
17:51:20
any other business, folks?
<@derekenz:fedora.im>
17:52:07
Nothing here
<@supakeen:fedora.im>
17:52:19
No, thank you :)
<@adamwill:fedora.im>
17:53:38
alrighty, thanks for coming, everyone
<@lruzicka:fedora.im>
17:53:57
nothing here
<@adamwill:fedora.im>
17:54:37
!endmeeting