<@adamwill:fedora.im>
16:00:42
!startmeeting F41-blocker-review
<@meetbot:fedora.im>
16:00:43
Meeting started at 2024-09-03 16:00:42 UTC
<@meetbot:fedora.im>
16:00:43
The Meeting name is 'F41-blocker-review'
<@adamwill:fedora.im>
16:00:47
!topic Roll Call
<@adamwill:fedora.im>
16:00:50
who's around for blocker fun, folks?
<@farribeiro:matrix.org>
16:00:56
!hi
<@jnsamyak:matrix.org>
16:01:02
!hi
<@zodbot:fedora.im>
16:01:02
Fábio Ribeiro (farribeiro) - he / him / his
<@zodbot:fedora.im>
16:01:05
Samyak Jain (jnsamyak) - he / him / his
<@jnsamyak:matrix.org>
16:01:07
double meeting
<@derekenz:fedora.im>
16:01:08
!hi
<@zodbot:fedora.im>
16:01:09
Derek Enz (derekenz)
<@nielsenb:fedora.im>
16:01:28
!hi
<@zodbot:fedora.im>
16:01:29
Brandon Nielsen (nielsenb)
<@frantisekz:fedora.im>
16:01:56
!hi
<@zodbot:fedora.im>
16:01:57
František Zatloukal (frantisekz)
<@adamwill:fedora.im>
16:02:08
hi hi everyone
<@adamwill:fedora.im>
16:03:08
boilerplate time!
<@adamwill:fedora.im>
16:03:09
!topic Introduction
<@conan_kudo:matrix.org>
16:03:09
!hi
<@zodbot:fedora.im>
16:03:11
Neal Gompa (ngompa) - he / him / his
<@adamwill:fedora.im>
16:03:12
Why are we here?
<@adamwill:fedora.im>
16:03:20
!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:03:22
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
16:03:25
!link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
<@adamwill:fedora.im>
16:03:27
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
16:03:29
!link http://qa.fedoraproject.org/blockerbugs/current
<@adamwill:fedora.im>
16:03:32
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
16:03:35
!link https://fedoraproject.org/wiki/Basic_Release_Criteria
<@adamwill:fedora.im>
16:03:38
!link https://fedoraproject.org/wiki/Fedora_41_Beta_Release_Criteria
<@adamwill:fedora.im>
16:03:40
!link https://fedoraproject.org/wiki/Fedora_41_Final_Release_Criteria
<@adamwill:fedora.im>
16:04:00
!info for Beta, we have 2 proposed blockers and 2 proposed FEs
<@adamwill:fedora.im>
16:04:15
!info no proposals for Final as of now
<@adamwill:fedora.im>
16:04:20
who wants to secretarialize?
<@frantisekz:fedora.im>
16:04:27
I can
<@adamwill:fedora.im>
16:04:33
!info František Zatloukal will secretarialize
<@adamwill:fedora.im>
16:04:43
alrighty, let's get going with:
<@adamwill:fedora.im>
16:04:47
!topic Proposed Beta blockers
<@adamwill:fedora.im>
16:04:55
!topic (2308952) The updates-testing repo isn't enabled by default
<@adamwill:fedora.im>
16:04:58
!link https://bugzilla.redhat.com/show_bug.cgi?id=2308952
<@adamwill:fedora.im>
16:05:00
!link https://pagure.io/fedora-qa/blocker-review/issue/1633
<@adamwill:fedora.im>
16:05:02
!info Proposed Blocker, fedora-repos, NEW
<@adamwill:fedora.im>
16:05:05
!info Ticket vote: BetaBlocker (+2,2,-0) (+lruzicka, +pbrobinson, kparal, nielsenb)
<@adamwill:fedora.im>
16:05:08
!info Ticket vote: BetaFreezeException (+1,0,-0) (+adamwill)
<@frantisekz:fedora.im>
16:05:20
so, FE it is if we have no crits for it
<@adamwill:fedora.im>
16:05:24
so there isn't actually any criterion for this, so i just voted FE for it. it's accepted as an FE
<@adamwill:fedora.im>
16:05:46
for beta we say the system must be capable of installing updates
<@kparal:matrix.org>
16:05:55
I don't feel that strongly about this as Stephen does
<@adamwill:fedora.im>
16:06:00
which i think is actually sufficient - in theory we could just fix this with an update after beta went out
<@conan_kudo:matrix.org>
16:06:29
I expect fesco will fast-track a blocker criterion for this today
<@conan_kudo:matrix.org>
16:06:42
there's a ticket for it now
<@kparal:matrix.org>
16:06:50
I actually this we don't need a criterion for this. But anyway, at this moment, I think just FE exception is fine.
<@conan_kudo:matrix.org>
16:06:58
!fesco 3266
<@zodbot:fedora.im>
16:06:59
● **Opened:** 3 hours ago by sgallagh
<@zodbot:fedora.im>
16:06:59
**fesco #3266** (https://pagure.io/fesco/issue/3266):**Fedora 41 Beta Blocker: require the updates-testing repository to be active**
<@zodbot:fedora.im>
16:06:59
<@zodbot:fedora.im>
16:06:59
● **Assignee:** Not Assigned
<@zodbot:fedora.im>
16:06:59
● **Last Updated:** 31 minutes ago
<@nielsenb:fedora.im>
16:07:06
FE feels sufficient to me
<@nhanlon:beeper.com>
16:07:14
!hi
<@zodbot:fedora.im>
16:07:15
Neil Hanlon (neil) - he / him / his
<@kparal:matrix.org>
16:07:34
I actually think we don't need a criterion for this. But anyway, at this moment, I think just FE exception is fine.
<@frantisekz:fedora.im>
16:08:51
so... we can punt blocker decision/wait for fesco, and I can mark it as acceptedblocker once they make the decision?
<@adamwill:fedora.im>
16:10:48
we can punt it, sure
<@adamwill:fedora.im>
16:11:38
proposed !agreed 2308952 - punt (delay decision) - as this is already accepted as an FE and the blocker status appears to be subject to FESCo jumping all over it, we'll delay the decision on blocker status while that happens. in any case the bug will shortly be fixed.
<@frantisekz:fedora.im>
16:12:03
ack
<@sumantrom:fedora.im>
16:12:16
ack
<@farribeiro:matrix.org>
16:12:18
ack
<@nielsenb:fedora.im>
16:12:32
"FESCo jumping all over it" 🤣
<@nielsenb:fedora.im>
16:12:34
ack
<@conan_kudo:matrix.org>
16:12:43
ack
<@adamwill:fedora.im>
16:12:56
!agreed 2308952 - punt (delay decision) - as this is already accepted as an FE and the blocker status appears to be subject to FESCo jumping all over it, we'll delay the decision on blocker status while that happens. in any case the bug will shortly be fixed.
<@adamwill:fedora.im>
16:13:17
!topic (2309337) Synchronous Exception on boot
<@adamwill:fedora.im>
16:13:21
!link https://bugzilla.redhat.com/show_bug.cgi?id=2309337
<@adamwill:fedora.im>
16:13:24
!link https://pagure.io/fedora-qa/blocker-review/issue/1637
<@adamwill:fedora.im>
16:13:26
!info Proposed Blocker, grub2, NEW
<@adamwill:fedora.im>
16:13:29
!info Ticket vote: BetaBlocker (+0,0,-2) (-nielsenb, -ngompa)
<@adamwill:fedora.im>
16:13:52
i could've -1ed this and skipped it at the meeting, but left it on the agenda in case Peter Robinson has any input
<@adamwill:fedora.im>
16:14:07
afaics the affected system isn't on any supported HW lists, and we don't have reports of this on any supported system
<@pbrobinson:fedora.im>
16:14:27
which ones?
<@conan_kudo:matrix.org>
16:14:56
https://www.ipi.wiki/pages/ampere-altra-developer-platform
<@conan_kudo:matrix.org>
16:15:01
apparently that system ^
<@pbrobinson:fedora.im>
16:15:24
so the ampere platforms are part of the general SystemReady ServerReady platforms we support
<@conan_kudo:matrix.org>
16:15:39
I didn't even know anyone had one
<@conan_kudo:matrix.org>
16:15:44
they're freakishly expensive
<@pbrobinson:fedora.im>
16:15:55
and infra have a bunch, it looks like the original grub2.12-1 build works, but it regressed in later builds
<@pbrobinson:fedora.im>
16:16:25
and I've not looked closely at the actrual issue but it could end up being an issue on other platforms like ones in Fedora infra
<@nielsenb:fedora.im>
16:16:31
Yeah, my vote actually changes given that it should be "SystemReady"
<@conan_kudo:matrix.org>
16:16:37
same
<@pbrobinson:fedora.im>
16:16:47
a LOT of people at arm run Fedora on them as workstations for example
<@nielsenb:fedora.im>
16:17:05
...are they hiring...?
<@pbrobinson:fedora.im>
16:17:17
yes
<@pbrobinson:fedora.im>
16:17:29
depends on your skillset
<@nielsenb:fedora.im>
16:17:36
Cooler than any workstation I've been issued
<@conan_kudo:matrix.org>
16:18:01
it'd better be, it's liquid-cooled!
<@adamwill:fedora.im>
16:18:04
$2600, yikes
<@geraldosimiao:matrix.org>
16:18:14
Hi!
<@humaton:fedora.im>
16:18:32
compared to similar systems 2600 is not that much
<@pbrobinson:fedora.im>
16:18:42
the concern I would have here is what other ServerReady platforms could be affected
<@adamwill:fedora.im>
16:18:43
well, if we want to block on this hw, it should be added to whichever list of blocking arm hw we're treating as canonical rn
<@geraldosimiao:matrix.org>
16:18:47
!hi
<@zodbot:fedora.im>
16:18:48
Geraldo S. Simião Kutz (geraldosimiao) - he / him / his
<@geraldosimiao:matrix.org>
16:19:02
Sorry for being so late
<@adamwill:fedora.im>
16:19:09
the criteria link to https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms
<@nielsenb:fedora.im>
16:19:12
"SystemReady" is already listed as supported on the wiki page I think is canonical
<@pbrobinson:fedora.im>
16:19:15
adamwwell ServerReady is a general category we already block on
<@adamwill:fedora.im>
16:19:19
which was last revised 2020, according to its header
<@adamwill:fedora.im>
16:19:23
Peter Robinson: what page says that?
<@nielsenb:fedora.im>
16:19:30
https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices
<@adamwill:fedora.im>
16:19:51
ah, the *other* one.
<@conan_kudo:matrix.org>
16:19:58
we block on all of those?
<@frantisekz:fedora.im>
16:20:08
I thought
<@adamwill:fedora.im>
16:20:13
see, i would read the sub-bullets under that "SBSA and SystemReady machines" bullet as being the specific ones that are blocking
<@pbrobinson:fedora.im>
16:20:24
that's arm32 platforms
<@adamwill:fedora.im>
16:20:31
Conan Kudo: technically no, since the criteria link to the *other* page. i've been trying to get those two reconciled forever.
<@adamwill:fedora.im>
16:21:09
if someone wants to tell me we can make one of them a redirect to the other i am all in favor of that
<@pbrobinson:fedora.im>
16:21:14
Yes so the "SBSA and SystemReady machines " is the category
<@adamwill:fedora.im>
16:21:52
right, but if we blocked on this specific one i'd expect it listed as a sub-bullet
<@adamwill:fedora.im>
16:22:04
or for there to be some kinda catch-all "we block on any of them"
<@adamwill:fedora.im>
16:22:56
openqa testing at least indicates that it works on qemu/kvm - https://openqa.fedoraproject.org/tests/2851727 is an install from the server netinst, for e.g.
<@adamwill:fedora.im>
16:23:26
can anyone test on the LX2160A ?
<@adamwill:fedora.im>
16:23:32
which is the thing in the list?
<@nhanlon:beeper.com>
16:25:42
that looks like a chip used in whitebox switches...
<@nhanlon:beeper.com>
16:26:01
i.e. embedded not server
<@pbrobinson:fedora.im>
16:26:02
Yep, I can probably dig mine out of where ever I shoved it and test
<@adamwill:fedora.im>
16:26:23
shall we say for now that we're punting for more testing and maybe a clarification on the supported hardware list?
<@nhanlon:beeper.com>
16:26:48
anyways, i can test an ampere server today and see if I can figure anything out. Was deep in the weeds of arm booting a few weeks agao..
<@nielsenb:fedora.im>
16:28:50
I'm okay with a punt
<@adamwill:fedora.im>
16:29:00
proposed !agreed 2309337 - punt (delay decision) - there's some ambiguity around the ARM supported hardware list, here, and we would like to see additional testing to see if other SystemReady hardware is affected
<@nhanlon:beeper.com>
16:29:03
+1 punt
<@nhanlon:beeper.com>
16:29:06
ack
<@farribeiro:matrix.org>
16:29:12
Ack
<@nielsenb:fedora.im>
16:29:14
ack
<@derekenz:fedora.im>
16:29:15
ack
<@frantisekz:fedora.im>
16:29:16
ack
<@adamwill:fedora.im>
16:30:05
!agreed 2309337 - punt (delay decision) - there's some ambiguity around the ARM supported hardware list, here, and we would like to see additional testing to see if other SystemReady hardware is affected
<@geraldosimiao:matrix.org>
16:30:14
ack
<@adamwill:fedora.im>
16:30:16
!action adamw to mail arm@ list about reconciling the supported HW lists
<@adamwill:fedora.im>
16:30:28
ok, let's move on to:
<@adamwill:fedora.im>
16:30:34
!topic Proposed Beta freeze exceptions
<@adamwill:fedora.im>
16:31:01
!topic (2297927) rpmsign broken: error: sign_hash failed
<@adamwill:fedora.im>
16:31:04
!link https://bugzilla.redhat.com/show_bug.cgi?id=2297927
<@adamwill:fedora.im>
16:31:06
!link https://pagure.io/fedora-qa/blocker-review/issue/1630
<@adamwill:fedora.im>
16:31:09
!info Proposed Freeze Exceptions, ima-evm-utils, ON_QA
<@adamwill:fedora.im>
16:31:12
!info Ticket vote: BetaFreezeException (+1,0,-0) (+ngompa)
<@nielsenb:fedora.im>
16:33:52
Is there some reason this shouldn't just be a 0day?
<@adamwill:fedora.im>
16:35:04
Peter Robinson proposed it
<@adamwill:fedora.im>
16:35:33
peter, when you say this is "used by IoT Edition" is it used in a way that's significant during compose, initial deployment, or use before first update?
<@pbrobinson:fedora.im>
16:36:21
it may cause issues with rpm signing and IMA is used as part of IoT hecne the freeze exception a IoT would want it fixed in the official beta
<@pbrobinson:fedora.im>
16:37:21
yes, so IMA is used in the disk image creation as we lay them down on disk, but it may cause upgrade issues for users that are actively using IMA hence the request for a FE
<@adamwill:fedora.im>
16:37:39
okay, sure
<@adamwill:fedora.im>
16:37:42
+1 what he said
<@geraldosimiao:matrix.org>
16:37:49
FE +1
<@conan_kudo:matrix.org>
16:37:50
that makes it sound blockery rather than FE, but +1
<@nielsenb:fedora.im>
16:37:51
Seems self contained enough...
<@nielsenb:fedora.im>
16:37:55
BetaFE +1
<@frantisekz:fedora.im>
16:38:06
+1 then
<@derekenz:fedora.im>
16:38:08
+1
<@kparal:matrix.org>
16:38:16
fe +1
<@adamwill:fedora.im>
16:38:33
proposed !agreed 2297927 - AcceptedFE (Beta) - this is accepted as it potentially has consequences during compose of IoT and upgrade of IoT systems to Beta, per Peter
<@frantisekz:fedora.im>
16:38:38
ack
<@nielsenb:fedora.im>
16:38:44
ack
<@conan_kudo:matrix.org>
16:38:52
ack
<@geraldosimiao:matrix.org>
16:39:04
ack
<@farribeiro:matrix.org>
16:39:38
Ack
<@adamwill:fedora.im>
16:41:48
!agreed 2297927 - AcceptedFE (Beta) - this is accepted as it potentially has consequences during compose of IoT and upgrade of IoT systems to Beta, per Peter
<@adamwill:fedora.im>
16:41:54
!topic (2304328) Multiple issues migrating from ostree-boot to rust-bootupd
<@adamwill:fedora.im>
16:41:57
!link https://bugzilla.redhat.com/show_bug.cgi?id=2304328
<@adamwill:fedora.im>
16:41:59
!link https://pagure.io/fedora-qa/blocker-review/issue/1638
<@adamwill:fedora.im>
16:42:01
!info Proposed Freeze Exceptions, rust-bootupd, NEW
<@adamwill:fedora.im>
16:42:08
oooh, "multiple issues".
<@nielsenb:fedora.im>
16:44:55
I would like at least some clarification of the potential blast radius
<@nielsenb:fedora.im>
16:45:15
Some kind of FE definitely feels warranted
<@pbrobinson:fedora.im>
16:45:26
probably any of the atomic desktops and related
<@nielsenb:fedora.im>
16:45:55
But only the rust-bootupd package needs to be touched?
<@adamwill:fedora.im>
16:47:32
yeah
<@adamwill:fedora.im>
16:47:47
travier seems to have proposed this as a kind of catch-all for "whatever he thinks needs fixing"
<@adamwill:fedora.im>
16:47:51
it would be nice to have a clearer scope of work
<@adamwill:fedora.im>
16:47:56
travier: around?
<@adamwill:fedora.im>
16:51:21
hmm
<@sgallagh:fedora.im>
16:51:29
👋
<@adamwill:fedora.im>
16:51:40
i think i'm gonna say we should punt this and request a clearer definition of exactly what is envisaged to be fixed here, just for form's sak
<@nielsenb:fedora.im>
16:51:48
Yeah
<@sgallagh:fedora.im>
16:52:06
+1
<@sgallagh:fedora.im>
16:52:14
(to what Adam just said, sorry)
<@adamwill:fedora.im>
16:53:54
proposed !agreed 2304328 - punt (delay decision) - we're generally inclined to +1 appropriate and scoped fixes for bootupd, but this seems like a very vague ticket, we would like to ask travier for more clarity on which of the 7.5 listed issues are considered in scope for fixing here
<@frantisekz:fedora.im>
16:54:10
ack
<@farribeiro:matrix.org>
16:54:24
Ack
<@nielsenb:fedora.im>
16:54:25
ack
<@sgallagh:fedora.im>
16:54:28
ack
<@geraldosimiao:matrix.org>
16:54:37
ack
<@nielsenb:fedora.im>
16:54:50
We're doing fractional issues now? Fractional scaling is still beta
<@frantisekz:fedora.im>
16:55:32
(?b)le{e,a}ding edge!
<@adamwill:fedora.im>
16:55:39
!agreed 2304328 - punt (delay decision) - we're generally inclined to +1 appropriate and scoped fixes for bootupd, but this seems like a very vague ticket, we would like to ask travier for more clarity on which of the 7.5 listed issues are considered in scope for fixing here
<@adamwill:fedora.im>
16:55:59
okay, let's do a quick spin through
<@adamwill:fedora.im>
16:56:02
!topic Accepted Beta blockers
<@adamwill:fedora.im>
16:56:12
!info as a reminder, we're not generally revoting these, just checking in on status
<@adamwill:fedora.im>
16:56:19
!topic (2276839) Fedora 41: Workstation live x86_64 image exceeds maximum size
<@adamwill:fedora.im>
16:56:21
!link https://bugzilla.redhat.com/show_bug.cgi?id=2276839
<@adamwill:fedora.im>
16:56:24
!info Accepted Blocker, distribution, ASSIGNED
<@adamwill:fedora.im>
16:56:41
so we tried droppnig botocore but it didn't help much. at this point i think the plan is to say This Is Fine and bump the max size
<@adamwill:fedora.im>
16:57:11
what that would usually mean is updating https://docs.fedoraproject.org/en-US/releases/f41/blocking/
<@adamwill:fedora.im>
16:57:18
this is somewhat stymied by the fact that page doesn't exist yet
<@sgallagh:fedora.im>
16:57:20
Yeah, let's just keep feeding more bits into it.
<@adamwill:fedora.im>
16:57:29
which means someone's behind on an SOP, or an SOP is missing a bit
<@adamwill:fedora.im>
16:58:25
oh, aoife's status says she's out sick. soo, i guess i can get on this...
<@adamwill:fedora.im>
16:59:00
Conan Kudo can you officially declare for the record that workstation wg wants the max size bumped? i think that'd be good enough of a paper trail
<@conan_kudo:matrix.org>
16:59:20
sure
<@frantisekz:fedora.im>
16:59:38
sure's not enough, it needs to be "I hereby declare that..."
<@frantisekz:fedora.im>
16:59:39
:D
<@conan_kudo:matrix.org>
16:59:47
lol
<@nielsenb:fedora.im>
17:00:03
Hear ye, hear ye
<@conan_kudo:matrix.org>
17:00:08
"I hereby declare that the Workstation Live image can be increased to 2.5GB."
<@conan_kudo:matrix.org>
17:00:24
"I hereby declare that the Workstation Live image can be increased to 2.5GB on behalf of the Fedora Workstation Working Group."
<@conan_kudo:matrix.org>
17:00:31
František Zatloukal: fancy enough for you?
<@sgallagh:fedora.im>
17:00:35
Boo, no "gavel" emoji
<@adamwill:fedora.im>
17:00:38
!info we haven't been able to reduce the size. Conan Kudo says workstation WG wants it bumped to 2.5 GB. as aoife is out sick adam will try and get the f41 blocking page created with the new size
<@adamwill:fedora.im>
17:00:49
!action adamw to get f41 pgm docs created
<@frantisekz:fedora.im>
17:00:57
yeah, fancyness overload moments now! 😁😅
<@adamwill:fedora.im>
17:01:15
!topic (2305291) GRUB 2.12 generated grub.cfg does not work with GRUB 2.06
<@adamwill:fedora.im>
17:01:18
!link https://bugzilla.redhat.com/show_bug.cgi?id=2305291
<@adamwill:fedora.im>
17:01:21
!link https://pagure.io/fedora-qa/blocker-review/issue/1618
<@adamwill:fedora.im>
17:01:23
!info Accepted Blocker, grub2, NEW
<@adamwill:fedora.im>
17:01:56
so...there's a workaround for atomic desktops here, but that doesn't apply to IoT
<@adamwill:fedora.im>
17:02:03
Peter Robinson can IoT use the same workaround?
<@amoloney:fedora.im>
17:02:33
I'm here, just about...
<@adamwill:fedora.im>
17:02:39
go back to bed!
<@amoloney:fedora.im>
17:03:06
Please !action me whatever needs updating/doing and I'll read over the meeting logs and get it done tomorrow
<@adamwill:fedora.im>
17:03:45
it's nothing major, i'll do it today, but if i don't have commit rights you can review/merge it when you're better
<@geraldosimiao:matrix.org>
17:03:46
Aoife Moloney - Out Sick: get well 🙂
<@sgallagh:fedora.im>
17:03:49
Aoife Moloney - Out Sick: Get some rest and feel better. We need you in top shape
<@amoloney:fedora.im>
17:05:12
Ok leaving now 😅 thanks folks I should be in better shape tomorrow
<@adamwill:fedora.im>
17:06:07
!info it seems like the shape of this issue is known and there's a workaround for the atomic desktops, but there doesn't seem to be anything in place yet to address it for IoT
<@adamwill:fedora.im>
17:06:30
i guess we can't do much more about this, ball is in IoT team's court
<@adamwill:fedora.im>
17:06:52
!topic (2282171) gsk: vulkan renderer causes gtk4 apps to crash on resize operations on Raspberry Pi 4 and 400
<@adamwill:fedora.im>
17:06:55
!link https://bugzilla.redhat.com/show_bug.cgi?id=2282171
<@adamwill:fedora.im>
17:06:57
!info Accepted Blocker, gtk4, NEW
<@adamwill:fedora.im>
17:07:28
ahhh, this one. so now people seem to be happily optimizing the gl renderer, which is lovely but doesn't help much so long as we're using the vulkan one
<@frantisekz:fedora.im>
17:07:35
hmm, that's a bit unfortunate situation, there's some movement around ngl performance regression fix (ngl rednerer was new in f40)
<@frantisekz:fedora.im>
17:07:41
gl was used before
<@frantisekz:fedora.im>
17:07:52
but the default (vk) is still crashing on window resizing
<@frantisekz:fedora.im>
17:08:57
I mean, I don't see a problem in adding if driver == "v3d": return ngl somewhere in gtk...
<@frantisekz:fedora.im>
17:09:07
but upstream didn't seem too happy bout that
<@adamwill:fedora.im>
17:09:59
right, this seems like something somebody could definitely fix somewhere if they would just do it
<@adamwill:fedora.im>
17:10:03
i do see "The rpi is pretty much the exception because it advertises itself as a very capable Vulkan driver which makes GTK choose Vulkan over GL"
<@adamwill:fedora.im>
17:12:34
beta early target is 09-17. i'm thinking it might be worth kicking this to fesco at this point
<@adamwill:fedora.im>
17:12:41
if we wait another week it's quite tight
<@frantisekz:fedora.im>
17:12:51
+1
<@nielsenb:fedora.im>
17:13:02
Can we just pull the proposed fix...?
<@nielsenb:fedora.im>
17:13:09
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7287
<@frantisekz:fedora.im>
17:13:26
this is in afaik
<@nielsenb:fedora.im>
17:13:34
Oh
<@nielsenb:fedora.im>
17:13:49
So if that didn't fix it, we should note that on one of the issues
<@adamwill:fedora.im>
17:13:56
there were multiple issues
<@adamwill:fedora.im>
17:14:00
some are resolved but some still outstanding
<@frantisekz:fedora.im>
17:14:02
yes, 4.14.5 contains that PR
<@adamwill:fedora.im>
17:14:11
František Zatloukal: do we actually have a single clear upstream ticket for the remaining issue?
<@frantisekz:fedora.im>
17:14:19
heh, lemme see
<@frantisekz:fedora.im>
17:15:42
hmm, no, sigh...
<@frantisekz:fedora.im>
17:15:58
if only the original issue that Lukas Brabec created wasn't closed, we'd have one
<@frantisekz:fedora.im>
17:16:16
I can create one later in the evening
<@adamwill:fedora.im>
17:16:20
maybe file a new one just for clarity, yeah
<@frantisekz:fedora.im>
17:16:23
stacktrace is attached to the bz
<@adamwill:fedora.im>
17:16:28
with the exact current issue description and trace
<@adamwill:fedora.im>
17:16:32
upstream hates bz :P
<@frantisekz:fedora.im>
17:16:46
will do, in span of few hours
<@adamwill:fedora.im>
17:16:53
then if they want to say it's mesa's fault, fine, at least we have a paper trail
<@adamwill:fedora.im>
17:16:54
thanks
<@adamwill:fedora.im>
17:17:25
!info we are still waiting for the various upstreams here to agree on who needs to fix what to address this
<@adamwill:fedora.im>
17:17:43
!action František Zatloukal to file a new upstream gtk issue clearly explaining the remaining issue, with the stace trace attached
<@adamwill:fedora.im>
17:18:01
!action adamw to alert fesco to the stuck blocker
<@adamwill:fedora.im>
17:18:15
!topic (2283978) Raspberry Pi 4 automatically suspends when idle, claims to support suspend, but can't be woken up
<@adamwill:fedora.im>
17:18:18
!link https://bugzilla.redhat.com/show_bug.cgi?id=2283978
<@adamwill:fedora.im>
17:18:20
!info Accepted Blocker, kernel, NEW
<@sgallagh:fedora.im>
17:18:37
adamw: Mesa is the stuck blocker?
<@frantisekz:fedora.im>
17:18:49
still an issue, retested today with and without https://bodhi.fedoraproject.org/updates/FEDORA-2024-dbf55dbc52
<@sgallagh:fedora.im>
17:18:50
We have the FESCo meeting running right now, I can bring it up in Open Floor
<@frantisekz:fedora.im>
17:18:57
mesa or gtk
<@frantisekz:fedora.im>
17:19:00
we aren't sure
<@adamwill:fedora.im>
17:19:04
Stephen Gallagher: i was going to ,but thanks
<@adamwill:fedora.im>
17:19:14
Stephen Gallagher: there's a whole lot of finger-pointing going on
<@sgallagh:fedora.im>
17:19:37
adamw: OK, I'll make sure it is on the agenda and you can provide the fingers.
<@adamwill:fedora.im>
17:19:42
rgr
<@adamwill:fedora.im>
17:20:40
this is kind of another one where we're waiting around for someone to do...something
<@adamwill:fedora.im>
17:21:06
Conan Kudo: i'm surprised by the KDE report, actually, does KDE have the same "suspend after 15 mins on AC" rule as GNOME?
<@adamwill:fedora.im>
17:21:13
Conan Kudo: i'm surprised by the KDE report, actually, does KDE have the same "suspend after 15 mins even on AC" rule as GNOME?
<@conan_kudo:matrix.org>
17:21:14
yes
<@frantisekz:fedora.im>
17:21:14
we can add this one to "upgrades borked on devices without time keeping chip" and keep it rolling over forever
<@adamwill:fedora.im>
17:21:20
fun
<@conan_kudo:matrix.org>
17:21:20
we implemented it very shortly after GNOME
<@conan_kudo:matrix.org>
17:21:26
Lenovo asked us to
<@conan_kudo:matrix.org>
17:21:29
so we did :)
<@frantisekz:fedora.im>
17:21:29
it's broken on pressing "sleep" there too, obviously
<@adamwill:fedora.im>
17:21:54
so we're kinda down to "we need a way to disable suspend on Pis" or documenting it, i think
<@adamwill:fedora.im>
17:22:05
given that we're not gonna get both desktops to change their suspend policies, i don't think
<@conan_kudo:matrix.org>
17:22:06
can we tell systemd suspend doesn't exist?
<@adamwill:fedora.im>
17:22:38
there are various ways to disable suspend
<@adamwill:fedora.im>
17:22:43
the trick is doing it *only on raspberry pis*
<@adamwill:fedora.im>
17:22:56
i don't think we can do that at install time. we don't know we're installing on a raspberry pi.
<@adamwill:fedora.im>
17:23:03
so it has to be at runtime, somehow.
<@frantisekz:fedora.im>
17:23:15
maybe something in arm-image-installer?
<@nielsenb:fedora.im>
17:23:18
arm image installer does
<@frantisekz:fedora.im>
17:23:20
it knows the board
<@conan_kudo:matrix.org>
17:24:17
technically udev rules can know too
<@conan_kudo:matrix.org>
17:24:30
I think at least with dt mode there's a procfs thing
<@conan_kudo:matrix.org>
17:24:42
not sure about tianocore/uefi mode
<@adamwill:fedora.im>
17:24:50
yeah, i was thinking about a udev rule
<@adamwill:fedora.im>
17:25:05
or i guess we could do it in the arm image installer, if it's able to do that kinda thing
<@adamwill:fedora.im>
17:25:12
does someone want an action item to look at it>?
<@jannau:fedora.im>
17:25:44
Systemd has platform integration for units and would know as well
<@adamwill:fedora.im>
17:27:22
okay...
<@adamwill:fedora.im>
17:28:00
!info this more or less boils down to 'find a way to disable suspend only on raspberry pis (but not in the kernel because jforbes says that won't fly upstream), or document it and move on'. we had some ideas in the meeting which we can note in the bugzilla
<@adamwill:fedora.im>
17:28:21
!info 2309138 is ON_QA so let's assume that's on track
<@nhanlon:beeper.com>
17:28:29
y'all still going RIP
<@adamwill:fedora.im>
17:28:32
!topic (2270430) Raspberry Pi 4: KDE initial setup is broken without nomodeset, KDE desktop won't load with nomodeset
<@adamwill:fedora.im>
17:28:35
!link https://bugzilla.redhat.com/show_bug.cgi?id=2270430
<@adamwill:fedora.im>
17:28:38
!info Accepted Blocker, xorg-x11-server-Xwayland, POST
<@adamwill:fedora.im>
17:28:39
last one
<@frantisekz:fedora.im>
17:28:57
I've verified the proposed fix
<@frantisekz:fedora.im>
17:28:58
works
<@adamwill:fedora.im>
17:29:04
awesome
<@zodbot:fedora.im>
17:29:14
neil gave a cookie to frantisekz. They now have 53 cookies, 4 of which were obtained in the Fedora 40 release cycle
<@frantisekz:fedora.im>
17:29:16
there is some dicussion upstream going on
<@zodbot:fedora.im>
17:29:24
geraldosimiao gave a cookie to frantisekz. They now have 54 cookies, 5 of which were obtained in the Fedora 40 release cycle
<@frantisekz:fedora.im>
17:29:25
regarding the possible effects on nvidia
<@zodbot:fedora.im>
17:29:38
ngompa gave a cookie to frantisekz. They now have 55 cookies, 6 of which were obtained in the Fedora 40 release cycle
<@frantisekz:fedora.im>
17:29:47
ohh, I'll get fat, thanks!
<@zodbot:fedora.im>
17:29:50
farribeiro gave a cookie to frantisekz. They now have 56 cookies, 7 of which were obtained in the Fedora 40 release cycle
<@adamwill:fedora.im>
17:29:51
!info this is in progress with a patch posted upstream, some possible side effects of the patch are being discussed, we will continue to monitor progress, there is enough time to let it ride for a bit before attempting a build
<@zodbot:fedora.im>
17:30:08
sgallagh gave a cookie to frantisekz. They now have 57 cookies, 8 of which were obtained in the Fedora 40 release cycle
<@adamwill:fedora.im>
17:30:23
!topic Open floor
<@adamwill:fedora.im>
17:30:25
any other business, folks?
<@frantisekz:fedora.im>
17:30:44
(as always, I'll process the bz/pagure changes in about 2 hours)
<@zodbot:fedora.im>
17:31:31
kparal has already given cookies to frantisekz during the F40 timeframe
<@adamwill:fedora.im>
17:31:48
thanks frantisek
<@zodbot:fedora.im>
17:31:58
adamwill gave a cookie to frantisekz. They now have 58 cookies, 9 of which were obtained in the Fedora 40 release cycle
<@adamwill:fedora.im>
17:32:29
okay, i guess we're done then
<@adamwill:fedora.im>
17:32:31
thanks for coming!
<@adamwill:fedora.im>
17:32:34
!endmeeting