<@adamwill:fedora.im>
16:00:14
!startmeeting F41-blocker-review
<@meetbot:fedora.im>
16:00:15
Meeting started at 2024-08-26 16:00:14 UTC
<@meetbot:fedora.im>
16:00:15
The Meeting name is 'F41-blocker-review'
<@adamwill:fedora.im>
16:00:17
!topic Roll Call
<@adamwill:fedora.im>
16:00:24
who's around for blocker review fun?
<@frantisekz:fedora.im>
16:01:11
!hi
<@zodbot:fedora.im>
16:01:12
František Zatloukal (frantisekz)
<@frantisekz:fedora.im>
16:02:18
Kamil Páral (or still on vacation?) coremodule Sumantro Mukherjee meeting time \o/
<@conan_kudo:matrix.org>
16:03:10
!hi
<@zodbot:fedora.im>
16:03:13
Neal Gompa (ngompa) - he / him / his
<@nhanlon:beeper.com>
16:03:20
!hi
<@zodbot:fedora.im>
16:03:21
Neil Hanlon (neil) - he / him / his
<@adamwill:fedora.im>
16:03:47
hello hello
<@frantisekz:fedora.im>
16:04:01
we'll hve quorum in the end, didn't seem like
<@adamwill:fedora.im>
16:04:12
three people is enough
<@adamwill:fedora.im>
16:04:24
although i guess technically we need the stakeholders.
<@adamwill:fedora.im>
16:04:46
nirik: around?
<@nirik:matrix.scrye.com>
16:05:04
sorta. Of course doing other stuff... ;)
<@adamwill:fedora.im>
16:06:13
ehhh, close enough!
<@adamwill:fedora.im>
16:06:22
we only have a few bugs to go through, so let's just give it a shot
<@nhanlon:beeper.com>
16:06:24
i'd be worried if ya weren't
<@adamwill:fedora.im>
16:06:33
boilerplate time
<@adamwill:fedora.im>
16:06:34
!topic Introduction
<@adamwill:fedora.im>
16:06:38
Why are we here?
<@adamwill:fedora.im>
16:06:42
!info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
<@adamwill:fedora.im>
16:06:44
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
16:06:47
<@adamwill:fedora.im>
16:06:50
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
16:06:52
<@adamwill:fedora.im>
16:06:55
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
16:06:57
<@adamwill:fedora.im>
16:07:00
<@adamwill:fedora.im>
16:07:02
<@adamwill:fedora.im>
16:07:20
!info for Beta, we have 1 proposed blocker and 1 proposed FE
<@adamwill:fedora.im>
16:07:29
!infor for Final, we have 2 proposed blockers
<@adamwill:fedora.im>
16:07:31
grr
<@adamwill:fedora.im>
16:07:37
!info for Final, we have 2 proposed blockers
<@adamwill:fedora.im>
16:07:46
who wants to secretarialize?
<@frantisekz:fedora.im>
16:07:54
I can :)
<@adamwill:fedora.im>
16:08:04
!info František Zatloukal will secretarialize, thanks
<@adamwill:fedora.im>
16:08:06
let's get started with:
<@adamwill:fedora.im>
16:08:10
!topic Proposed Beta blockers
<@adamwill:fedora.im>
16:08:19
!topic (2270430) Raspberry Pi 4: KDE initial setup is broken without nomodeset, KDE desktop won't load with nomodeset
<@adamwill:fedora.im>
16:08:23
<@adamwill:fedora.im>
16:08:26
<@adamwill:fedora.im>
16:08:28
!info Proposed Blocker, mesa, NEW
<@adamwill:fedora.im>
16:08:33
well hey Conan Kudo , you asked for it
<@conan_kudo:matrix.org>
16:08:51
fwiw, I appreciate it being highlighted :)
<@adamwill:fedora.im>
16:09:17
this does seem fairly blocker-y to me, it would look pretty bad to tell people to boot one way then another
<@conan_kudo:matrix.org>
16:09:18
are there any other aarch64 platforms beyond the rpi that are rb that we need to verify?
<@frantisekz:fedora.im>
16:09:51
I'd say https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices ?
<@conan_kudo:matrix.org>
16:09:57
I absolutely agree, I've started talking to upstream about what's causing this. They do seem to agree that kwin isn't where the problem is.
<@frantisekz:fedora.im>
16:10:07
but, idk if some of them are expected to have broken display out
<@frantisekz:fedora.im>
16:10:21
we usually test just the rpi in brno office
<@conan_kudo:matrix.org>
16:10:27
which sort of leaves me puzzled, since that's the common factor between the two
<@adamwill:fedora.im>
16:10:38
Conan Kudo: it's awkward. in theory all the ones listed by the arm team. in practice we don't have all of them to test and the list is old.
<@adamwill:fedora.im>
16:11:14
i'd say mainly focus on getting pi working.
<@conan_kudo:matrix.org>
16:11:19
worksforme
<@adamwill:fedora.im>
16:11:46
have we tested gtk apps on kde with mode-setting enabled?
<@adamwill:fedora.im>
16:11:54
maybe that's the issue? i-s uses gtk, iirc
<@conan_kudo:matrix.org>
16:11:59
right
<@conan_kudo:matrix.org>
16:12:01
that's what I was thinking
<@conan_kudo:matrix.org>
16:12:16
I vaguely recall that there have been other bugs with the rpi drivers with gtk
<@frantisekz:fedora.im>
16:12:18
I mean, we (mainly Lukas Brabec ) tests the Workstation build
<@frantisekz:fedora.im>
16:12:34
i-s should be gtk3 still? those apps work just fine
<@frantisekz:fedora.im>
16:12:52
gtk4 works without graphical corruption in the latest builds too
<@frantisekz:fedora.im>
16:12:56
but crashes often
<@conan_kudo:matrix.org>
16:14:01
I wonder if i-s being xwayland also has an impact
<@conan_kudo:matrix.org>
16:14:26
which would actually take us back to kwin 😅
<@conan_kudo:matrix.org>
16:14:32
and possibly xwayland too
<@adamwill:fedora.im>
16:14:35
yeah, it'd be gtk3
<@frantisekz:fedora.im>
16:15:20
one way around would be to force llvmpipe use for i-s for Beta release?
<@frantisekz:fedora.im>
16:15:29
the app doesn't need that much of performance
<@conan_kudo:matrix.org>
16:18:37
yeah, that's probably doable
<@conan_kudo:matrix.org>
16:19:04
that can be done by patching the backend runner script in the kde-settings package
<@adamwill:fedora.im>
16:19:31
anyway, we don't have to fix it here
<@adamwill:fedora.im>
16:19:33
we just have to vote on it
<@adamwill:fedora.im>
16:19:39
i'm +1 blocker, other votes?
<@conan_kudo:matrix.org>
16:19:42
+1 BetaBlocker
<@frantisekz:fedora.im>
16:19:45
yeah, +1
<@adamwill:fedora.im>
16:21:27
proposed !agreed 2270430 - AcceptedBlocker (Beta) - this is accepted as a violation of Basic criterion "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility", for the now release-blocking configuration of KDE on the Raspberry PI
<@frantisekz:fedora.im>
16:21:35
ack
<@conan_kudo:matrix.org>
16:21:59
ack
<@nirik:matrix.scrye.com>
16:22:01
ack
<@nirik:matrix.scrye.com>
16:22:03
+1 blocker
<@adamwill:fedora.im>
16:22:18
!agreed 2270430 - AcceptedBlocker (Beta) - this is accepted as a violation of Basic criterion "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility", for the now release-blocking configuration of KDE on the Raspberry PI
<@adamwill:fedora.im>
16:22:29
ok, let's do the:
<@adamwill:fedora.im>
16:22:34
!topic Proposed Beta freeze exception
<@adamwill:fedora.im>
16:22:36
!topic (2307728) gtk4 4.15.5 breaks display change confirmation dialog on X11
<@adamwill:fedora.im>
16:22:39
<@adamwill:fedora.im>
16:22:43
<@adamwill:fedora.im>
16:22:45
!info Proposed Freeze Exceptions, gtk4, NEW
<@frantisekz:fedora.im>
16:22:57
hmm, the x session shouldn't be in by default now?
<@frantisekz:fedora.im>
16:23:02
I didn't check though
<@adamwill:fedora.im>
16:23:14
yeah. i'm generally pretty ehhhhh on changing gtk during freeze to fix something in X.
<@adamwill:fedora.im>
16:23:19
of course, on upgraded systems it'll be there.
<@adamwill:fedora.im>
16:23:34
oh, it seems this is actually for Budgie
<@conan_kudo:matrix.org>
16:23:56
it probably also affects the other gtk-based X11 desktops
<@frantisekz:fedora.im>
16:24:42
so, +1 I guess, we can decide not to pull it in if gtk's diff is too large
<@adamwill:fedora.im>
16:24:58
yeah...i guess, if gtk folks say it's safe, i'll check
<@nirik:matrix.scrye.com>
16:25:45
+1 FE
<@adamwill:fedora.im>
16:25:49
+1 to grant the FE, will be careful about merging it
<@nhanlon:beeper.com>
16:26:30
+1 to all the above
<@adamwill:fedora.im>
16:26:30
proposed !agreed 2307728 - AcceptedFreezeException (Beta) - this is accepted as it breaks significant functionality on non-release-blocking desktops (including Budgie). we will check with GTK folks that the fix should be safe before landing it
<@frantisekz:fedora.im>
16:26:43
ack
<@nhanlon:beeper.com>
16:26:49
ack
<@nirik:matrix.scrye.com>
16:28:17
ack
<@adamwill:fedora.im>
16:28:27
!agreed 2307728 - AcceptedFreezeException (Beta) - this is accepted as it breaks significant functionality on non-release-blocking desktops (including Budgie). we will check with GTK folks that the fix should be safe before landing it
<@adamwill:fedora.im>
16:28:40
ok, moving onto:
<@adamwill:fedora.im>
16:28:43
!topic Proposed Final blockers
<@adamwill:fedora.im>
16:28:45
!topic (2307278) ABRT does not catch app crashes on Fedora 41
<@adamwill:fedora.im>
16:28:48
<@adamwill:fedora.im>
16:28:50
<@adamwill:fedora.im>
16:28:52
!info Proposed Blocker, abrt, NEW
<@frantisekz:fedora.im>
16:29:16
aka, found by accident when working on gtk4/rpi crashes
<@nirik:matrix.scrye.com>
16:29:22
I think this is almost fixed.
<@nirik:matrix.scrye.com>
16:30:25
+1 final blocker
<@frantisekz:fedora.im>
16:30:36
the issue is that the crashes aren't even visible in local abrt UI, that's related to infra issue too?
<@frantisekz:fedora.im>
16:30:53
anyhow, apart from +1 FinalBlocker, I'd also say +1 BetaFE
<@adamwill:fedora.im>
16:31:13
yeah, +1 to both
<@conan_kudo:matrix.org>
16:31:46
+1 BetaBlocker IMO
<@nirik:matrix.scrye.com>
16:31:47
yeah
<@adamwill:fedora.im>
16:32:04
i don't see any beta criterion it breaks.
<@conan_kudo:matrix.org>
16:32:05
we want those crash reports for final blocker tracking
<@conan_kudo:matrix.org>
16:32:22
hmm
<@conan_kudo:matrix.org>
16:32:35
if there's nothing to ground it, then +1 BetaFE and +1 FinalBlocker
<@adamwill:fedora.im>
16:34:16
proposed !agreed 2307278 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is accepted as a violation of the "basic functionality" criterion for the crash reporter app. We also accept it as a Beta FE as this is significant functionality for Beta testing, the value of Beta testing is lessened if this does not work
<@nhanlon:beeper.com>
16:34:34
ack
<@frantisekz:fedora.im>
16:34:35
ack
<@nirik:matrix.scrye.com>
16:35:21
ack
<@adamwill:fedora.im>
16:35:27
!agreed 2307278 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is accepted as a violation of the "basic functionality" criterion for the crash reporter app. We also accept it as a Beta FE as this is significant functionality for Beta testing, the value of Beta testing is lessened if this does not work
<@adamwill:fedora.im>
16:36:09
!topic (2303813) With 6.10 kernels before 6.10.5 and 6.11 kernels before rc4, gnome-disks is partly nonfunctional
<@adamwill:fedora.im>
16:36:11
<@adamwill:fedora.im>
16:36:14
<@adamwill:fedora.im>
16:36:16
!info Proposed Blocker, kernel, POST
<@adamwill:fedora.im>
16:36:36
so I tried to test this locally but ran into a *different* kernel issue on my system which screwed things up a bit
<@adamwill:fedora.im>
16:36:49
it doesn't work for me even with current kernels, but i don't know whether it worked on my hw with 6.9 or not
<@adamwill:fedora.im>
16:36:54
anyone else in a position to test?
<@nirik:matrix.scrye.com>
16:41:22
here on rawhide with nvme, that entry is greyed out too...
<@adamwill:fedora.im>
16:41:42
but we need to know whether it worked with 6.9, i guess
<@nirik:matrix.scrye.com>
16:42:03
yeah, I could try later. Can't really reboot right now.
<@adamwill:fedora.im>
16:42:08
smartctl -a gives me some info but also ends with "Read Self-test Log failed: Invalid Field in Command (0x6002)"
<@adamwill:fedora.im>
16:42:13
yeah, me either
<@adamwill:fedora.im>
16:42:18
i guess we'll have to punt this again as unclear
<@adamwill:fedora.im>
16:44:02
proposed !agreed 2303813 - punt (delay decision) - we're still not really clear on the contours of this or whether it's already fixed, due to differing hardware and lack of input from the reporter
<@frantisekz:fedora.im>
16:44:08
ack
<@conan_kudo:matrix.org>
16:44:19
ack
<@robatino:fedora.im>
16:45:03
i'm not the best person to test since i'm only running 41 in a vm (virtualbox)
<@robatino:fedora.im>
16:45:53
i know that on 3 different bare metal machines running 40, it was working with 6.9.12, broken in 6.10.3 and 6.10.4, and working again in 6.10.5 and 6.10.6
<@nirik:matrix.scrye.com>
16:47:15
same gnome-disks versions on the working/nonworking?
<@robatino:fedora.im>
16:47:38
yes, the gnome-disks version hasn't changed in a while
<@adamwill:fedora.im>
16:48:17
Andre Robatino: if you could test the same with f41 it would really help. you don't need to install, just boot a recent f41 workstation live on the affected system and see if it works
<@adamwill:fedora.im>
16:48:32
!agreed 2303813 - punt (delay decision) - we're still not really clear on the contours of this or whether it's already fixed, due to differing hardware and lack of input from the reporter
<@adamwill:fedora.im>
16:49:47
ok, let's take a quick look at;
<@adamwill:fedora.im>
16:49:51
!topic Accepted Beta blockers
<@adamwill:fedora.im>
16:49:58
!info reminder: we are not revoting here, just checking status
<@adamwill:fedora.im>
16:50:10
!topic (2305763) Orca crashes on Fedora 41 Pre-beta due to a Python "AttributeError".
<@adamwill:fedora.im>
16:50:13
<@adamwill:fedora.im>
16:50:15
<@adamwill:fedora.im>
16:50:17
!info Accepted Blocker, at-spi2-core, ON_QA
<@frantisekz:fedora.im>
16:50:25
this one should be fixed already?
<@adamwill:fedora.im>
16:50:29
!info this ought to be fixed, would be good if we can get confirmation
<@frantisekz:fedora.im>
16:51:00
I can give it a try tomorrow and close it if it's the case
<@adamwill:fedora.im>
16:51:03
i just ran it here and it didn't crash, so, that's good?
<@adamwill:fedora.im>
16:51:12
but i just ran 'orca' from a console, dunno if that's the reproducer
<@frantisekz:fedora.im>
16:51:12
or... like that :D
<@adamwill:fedora.im>
16:51:48
!topic (2276839) Fedora 41: Workstation live x86_64 image exceeds maximum size
<@adamwill:fedora.im>
16:51:50
<@adamwill:fedora.im>
16:51:53
<@adamwill:fedora.im>
16:51:55
!info Accepted Blocker, distribution, ASSIGNED
<@adamwill:fedora.im>
16:52:22
!info the plan here is "Let's try dropping botocore, and if that's not enough, the Workstation WG is okay to raise to 2.5GiB." unclear on the status of the botocore change
<@adamwill:fedora.im>
16:52:28
Conan Kudo - who was going to do that?
<@conan_kudo:matrix.org>
16:52:54
I guess I could try?
<@conan_kudo:matrix.org>
16:53:03
it's just adding an exclude to the kickstart, iirc
<@adamwill:fedora.im>
16:53:33
juhp said "I think the idea was to drop the Recommends from sos on python3-boto3"
<@adamwill:fedora.im>
16:53:44
but leaving it just out of the live image does seem more targeted
<@conan_kudo:matrix.org>
16:53:57
dropping it from the recommends is probably a bit much
<@adamwill:fedora.im>
16:54:30
!action Conan Kudo to try and implement dropping botocore from the image
<@adamwill:fedora.im>
16:54:42
!topic (2305291) GRUB 2.12 generated grub.cfg does not work with GRUB 2.06
<@adamwill:fedora.im>
16:54:46
<@adamwill:fedora.im>
16:54:49
<@adamwill:fedora.im>
16:54:52
!info Accepted Blocker, grub2, NEW
<@frantisekz:fedora.im>
16:54:55
this one could be revoted?
<@frantisekz:fedora.im>
16:55:34
IoT nor CoreOS should be affected?
<@adamwill:fedora.im>
16:56:34
see comment #6
<@adamwill:fedora.im>
16:56:40
it seems you need a package overlay to trigger the bug here
<@adamwill:fedora.im>
16:56:50
so i don't think we can conclude it's safe yet
<@frantisekz:fedora.im>
16:57:38
hmm, we can leave it as it is ofc, but I'd say that rebasing with overlayed package isn't technically supported?
<@adamwill:fedora.im>
16:57:57
ehhhh, i would really not want to go out on that limb
<@adamwill:fedora.im>
16:58:08
practically speaking you have to overlay stuff an awful lot of the time
<@nhanlon:beeper.com>
16:58:29
plus this isn't rebasing with an overlayed package, it's overlaying a package after rebasing
<@adamwill:fedora.im>
16:59:55
!info we could use some testing to clarify if IoT is affected by this
<@adamwill:fedora.im>
17:00:06
the proposed reproducer in comment #6 seems pretty simple, so we should just...try that
<@adamwill:fedora.im>
17:00:25
other than that, i don't have much here, anyone else?
<@naraiank:fedora.im>
17:00:40
!hi
<@zodbot:fedora.im>
17:00:42
Naraian K (naraiank) - he / him / his
<@frantisekz:fedora.im>
17:01:04
(wishing for successful compose)
<@adamwill:fedora.im>
17:01:28
yeah, that'd be nice
<@adamwill:fedora.im>
17:01:35
!topic (2282171) gsk: vulkan renderer breaks gtk4 apps on Raspberry Pi 4 and 400
<@adamwill:fedora.im>
17:01:38
<@adamwill:fedora.im>
17:01:40
<@adamwill:fedora.im>
17:01:42
!info Accepted Blocker, gtk4, NEW
<@adamwill:fedora.im>
17:01:46
so, sadness time
<@adamwill:fedora.im>
17:01:53
has anyone accepted any responsibility for doing any damn thing about this yet
<@frantisekz:fedora.im>
17:02:42
it got "better", now without graphical corruption
<@naraiank:fedora.im>
17:04:28
Oh, Raspberry..! 🫣
<@adamwill:fedora.im>
17:04:30
just the crashes
<@frantisekz:fedora.im>
17:04:43
yeah, plenty of them, easy to trigger by accident
<@adamwill:fedora.im>
17:05:29
is it only resizing a window that causes it? any other triggers?
<@frantisekz:fedora.im>
17:05:36
yeah
<@adamwill:fedora.im>
17:05:40
(can i change the description to "gsk: vulkan renderer causes gtk4 apps to crash on resize operations on Raspberry Pi 4 and 400"?)
<@frantisekz:fedora.im>
17:05:57
eg maximizing it via super + arrow up, but still technically the resize
<@frantisekz:fedora.im>
17:06:23
I don't think I've seen brab hitting a different trigger
<@adamwill:fedora.im>
17:06:37
the upstream issue was closed as 'fixed' by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7287 , i guess that fixed the corruption?
<@frantisekz:fedora.im>
17:07:03
hmm, I think it was fixed by different, gimme sec
<@frantisekz:fedora.im>
17:07:39
this one I believe: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7473
<@adamwill:fedora.im>
17:09:09
!info we seem to be making some progress with getting the different upstreams to collaborate on this, will keep monitoring it
<@adamwill:fedora.im>
17:10:13
!topic (2283978) Raspberry Pi 4 automatically suspends when idle, claims to support suspend, but can't be woken up
<@adamwill:fedora.im>
17:10:16
<@adamwill:fedora.im>
17:10:18
<@adamwill:fedora.im>
17:10:20
!info Accepted Blocker, kernel, NEW
<@adamwill:fedora.im>
17:10:39
!info we still will probably have to document or waive this, it doesn't look like anyone came up with any bright ideas
<@nirik:matrix.scrye.com>
17:10:42
big slice of 🥧 today
<@adamwill:fedora.im>
17:14:09
i guess that's the lot
<@adamwill:fedora.im>
17:14:19
!topic Open floor
<@adamwill:fedora.im>
17:14:21
any other business, folks?
<@frantisekz:fedora.im>
17:14:38
secretary duty will be done in roughly an hour, fyi
<@naraiank:fedora.im>
17:15:40
Nothing from me, for now.
<@nirik:matrix.scrye.com>
17:16:00
I'm wondering...
<@nirik:matrix.scrye.com>
17:16:29
did we ever do anything with the 'pi has no clock' bug? and should we try and poke again at the 'aarch64 random sigill' thing?
<@conan_kudo:matrix.org>
17:16:43
we didn't as far as I know
<@frantisekz:fedora.im>
17:16:52
nah, it's still NEW as Accepted Previous Release Blocker
<@adamwill:fedora.im>
17:17:01
oh yeah, sorry, didn't get to it
<@adamwill:fedora.im>
17:17:08
i think we should just give up on it as a blocker, clearly nobody is fixing it
<@adamwill:fedora.im>
17:17:13
but i argued that last cycle and got outvoted
<@adamwill:fedora.im>
17:17:23
for the other one, i think we're hanging our hopes on switching to kiwi or something
<@nirik:matrix.scrye.com>
17:17:50
I would think it would still happen with kiwi, but that would be a good datapoint.
<@conan_kudo:matrix.org>
17:18:27
well, we will find out with the kiwi mobile isos
<@conan_kudo:matrix.org>
17:18:53
with the latest update I made this morning to kiwi, I think I have every feature ported over that we use from lmc/lcc
<@conan_kudo:matrix.org>
17:19:13
the last one was the mediacheck stuff, and that was merged upstream this morning and I backported it
<@adamwill:fedora.im>
17:19:19
i don't think it necessarily would?
<@adamwill:fedora.im>
17:19:29
it was happening during the run of anaconda, and kiwi doesn't run anaconda to build live images, right
<@conan_kudo:matrix.org>
17:19:35
yeah no anaconda
<@salimma:fedora.im>
17:20:08
!hi
<@zodbot:fedora.im>
17:20:09
Michel Lind (salimma) - he / him / his
<@adamwill:fedora.im>
17:20:19
hi, welcome to the end. :D
<@nirik:matrix.scrye.com>
17:20:42
sure, it might no longer fail on building the image, but might have the bug on using that image? but perhaps not.
<@salimma:fedora.im>
17:20:47
I join and everyone runs away :/
<@adamwill:fedora.im>
17:22:18
!endmeeting