<@adamwill:fedora.im>
16:00:37
!startmeeting F43-blocker-review
<@meetbot:fedora.im>
16:00:38
Meeting started at 2025-09-15 16:00:37 UTC
<@meetbot:fedora.im>
16:00:38
The Meeting name is 'F43-blocker-review'
<@adamwill:fedora.im>
16:00:40
!topic Roll Call
<@adamwill:fedora.im>
16:00:46
ahoyhoy, who's around for blocker review fun?
<@nielsenb:fedora.im>
16:00:55
!hi
<@zodbot:fedora.im>
16:00:57
Brandon Nielsen (nielsenb)
<@derekenz:fedora.im>
16:01:07
!hi
<@zodbot:fedora.im>
16:01:09
Derek Enz (derekenz)
<@pboy:fedora.im>
16:01:39
!hi
<@zodbot:fedora.im>
16:01:39
Peter Boy (pboy)
<@kparal:matrix.org>
16:01:57
!hi
<@zodbot:fedora.im>
16:02:00
Kamil Páral (kparal) - he / him / his
<@lruzicka:fedora.im>
16:02:19
High there
<@lruzicka:fedora.im>
16:02:28
!high
<@conan_kudo:matrix.org>
16:02:28
!hi
<@zodbot:fedora.im>
16:02:30
Neal Gompa (ngompa) - he / him / his
<@lruzicka:fedora.im>
16:02:36
!hi
<@zodbot:fedora.im>
16:02:38
Lukáš Růžička (lruzicka)
<@patrikp:matrix.org>
16:04:24
Hello.
<@adamwill:fedora.im>
16:06:42
how's everyone doing
<@adamwill:fedora.im>
16:06:54
let's get rolling with some exciting boilerplate!
<@conan_kudo:matrix.org>
16:07:04
just got back from Berlin over the weekend, and nearly ready for devconf.us :)
<@adamwill:fedora.im>
16:07:16
jetsetter
<@adamwill:fedora.im>
16:07:20
!link http://qa.fedoraproject.org/blockerbugs/current
<@adamwill:fedora.im>
16:07: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:07:20
Why are we here?
<@adamwill:fedora.im>
16:07:20
!topic Introduction
<@adamwill:fedora.im>
16:07:20
!info We'll be following the process outlined at:
<@adamwill:fedora.im>
16:07:20
!link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
<@adamwill:fedora.im>
16:07:20
!info The bugs up for review today are available at:
<@adamwill:fedora.im>
16:07:20
!link https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria
<@adamwill:fedora.im>
16:07:20
!link https://fedoraproject.org/wiki/Fedora_43_Beta_Release_Criteria
<@adamwill:fedora.im>
16:07:20
!link https://fedoraproject.org/wiki/Basic_Release_Criteria
<@adamwill:fedora.im>
16:07:20
!info The criteria for release blocking bugs can be found at:
<@adamwill:fedora.im>
16:07:54
!info for F43 Final, we have:
<@adamwill:fedora.im>
16:07:55
!info 7 Accepted Blockers
<@adamwill:fedora.im>
16:07:55
!info 8 Proposed Blockers
<@adamwill:fedora.im>
16:08:24
oh whoops, a couple of those had enough votes to get knocked off before the meeting, never mind, we'll include 'em
<@adamwill:fedora.im>
16:08:35
who wants to secretarialize?
<@lruzicka:fedora.im>
16:09:10
I will do it
<@boniboyblue:fedora.im>
16:09:26
!hi
<@zodbot:fedora.im>
16:09:27
Christopher Boni (boniboyblue)
<@adamwill:fedora.im>
16:10:07
!info lruzicka will secretarialize
<@adamwill:fedora.im>
16:10:10
ok, let's get started with:
<@adamwill:fedora.im>
16:10:13
!topic Proposed Final blockers
<@adamwill:fedora.im>
16:10:22
!info Proposed Blocker, arm-image-installer, NEW
<@adamwill:fedora.im>
16:10:22
!link https://bugzilla.redhat.com/show_bug.cgi?id=2391231
<@adamwill:fedora.im>
16:10:22
!link https://pagure.io/fedora-qa/blocker-review/issue/1923
<@adamwill:fedora.im>
16:10:22
!topic (2391231) Fails to create boot medium for Fedora Server on Radxa Rock Pi 4
<@adamwill:fedora.im>
16:10:37
so hey, this is where we get to flex our brand new "subjective discussion of ARM hardware platforms" muscles!
<@conan_kudo:matrix.org>
16:10:50
joooy
<@adamwill:fedora.im>
16:10:50
how's everyone feeling about how important rockchips-based SBCs are? don't all rush at once
<@conan_kudo:matrix.org>
16:11:13
in _theory_ they're pretty important... except I don't own any functioning hardware with them
<@pboy:fedora.im>
16:11:22
It's not "just" Radxa, but every SBC model
<@adamwill:fedora.im>
16:12:00
Peter Boy (ServerWG, Docs) we need to discuss one bug at a time here
<@adamwill:fedora.im>
16:12:04
this one is specific to rockchips
<@adamwill:fedora.im>
16:12:17
if there's a generic issue about LVM, that needs to be filed separately to avoid confusion
<@pboy:fedora.im>
16:12:42
Well, both are in the same bug report.
<@pboy:fedora.im>
16:12:53
If I remember correctly
<@adamwill:fedora.im>
16:13:06
that's the confusion...
<@kparal:matrix.org>
16:13:11
sorry, I need to go afk for a longer time
<@adamwill:fedora.im>
16:13:18
ok, see you later kamil
<@adamwill:fedora.im>
16:14:12
i guess what we need to do here is clarify how many bugs we're dealing with and whether they're related
<@pboy:fedora.im>
16:14:45
One Part of the error lies in the arm-image-installer program, which fails during an installation step with LVM that is necessary for Server. The consequence is that Fedora Server can in the Beta version not be installed on any SBC model at all.
<@pboy:fedora.im>
16:14:54
The second part of this error is that even the minimal version, which does not use LVM, does not boot on either the Radxa Rock Pi 4 nor the Pine64 RockPro64. Here, the cause may be specific to RockChip models. The Raspberry Pi 4 obviously boots minimal.
<@nielsenb:fedora.im>
16:15:04
I don't quite understand why the LVM step only fails for Server, but I can confirm the Pi is impacted.
<@derekenz:fedora.im>
16:15:26
Yes can confirm the Ri4
<@nielsenb:fedora.im>
16:15:29
So the LVM thing is its own bug
<@pboy:fedora.im>
16:15:34
Because Server is the only one using LVM
<@adamwill:fedora.im>
16:15:44
Brandon Nielsen because only the server images *uses* LVM, i think
<@nielsenb:fedora.im>
16:15:52
Oh yeah, Workstation went to btrfs forever ago, forgot
<@derekenz:fedora.im>
16:15:55
Yes can confirm the Rpi4
<@adamwill:fedora.im>
16:16:17
Peter Boy (ServerWG, Docs) can you please file a second bug, then, and clarify which issue you want each bug report to cover?
<@adamwill:fedora.im>
16:16:28
do we want to make this one the bug for "server LVM issue" or "rockchip firmware size issue"?
<@pboy:fedora.im>
16:17:15
The bug is about arm-image-installer. It is the one wich affects any SBC model, not only Radxa.
<@pboy:fedora.im>
16:17:28
Radxa is the model, I detected it first.
<@adamwill:fedora.im>
16:17:42
OK
<@pboy:fedora.im>
16:17:59
See https://bugzilla.redhat.com/show_bug.cgi?id=2391231
<@adamwill:fedora.im>
16:19:13
yes, that is the bug we're on.
<@adamwill:fedora.im>
16:19:42
so, counting this as "we can't currently write a bootable Server image for any platform", votes? I'm +1 blocker for that, since Server disk image is a blocker medium
<@adamwill:fedora.im>
16:19:48
so, counting this as "we can't currently write a bootable Server image for any platform", votes? I'm +1 blocker for that, since Server disk image is a blocking medium
<@adamwill:fedora.im>
16:19:56
so, counting this as "we can't currently write a bootable Server image for any ARM platform", votes? I'm +1 blocker for that, since Server disk image is a blocking medium
<@nielsenb:fedora.im>
16:19:59
Agreed, LVM issue is a blocker
<@conan_kudo:matrix.org>
16:20:02
it is?
<@pboy:fedora.im>
16:20:02
The problem is, Peter talked about the second issue in the thread.
<@nielsenb:fedora.im>
16:20:03
FinalBlocker +1
<@adamwill:fedora.im>
16:20:13
Peter Boy (ServerWG, Docs) it's fine with a sufficient clarification
<@adamwill:fedora.im>
16:20:27
also could you two play rock paper scissors and whoever loses change your name? it'd make meetings clearer. ;P
<@adamwill:fedora.im>
16:20:55
waaait
<@adamwill:fedora.im>
16:20:58
conan's right
<@pboy:fedora.im>
16:20:59
Well, we will try
<@adamwill:fedora.im>
16:21:02
https://docs.fedoraproject.org/en-US/releases/f43/blocking/
<@nielsenb:fedora.im>
16:21:03
Right, it's not
<@nielsenb:fedora.im>
16:21:07
I rescind my vote
<@adamwill:fedora.im>
16:21:22
somehow we wound up with the minimal *disk image* as blocking, but the server *dvd and netinst* as blocking
<@nielsenb:fedora.im>
16:21:23
Those are ISOs listed, derp
<@adamwill:fedora.im>
16:21:27
not sure how we wound up there, but hey
<@adamwill:fedora.im>
16:21:37
so on that basis, this wouldn't be a blocker...
<@nielsenb:fedora.im>
16:21:43
Yup
<@nielsenb:fedora.im>
16:21:46
FinalBlocker -1
<@pboy:fedora.im>
16:21:54
SBC cannot use ISO. The image is the ISO here
<@nielsenb:fedora.im>
16:22:34
That may be true, but the image isn't a blocking deliverable as per the official list adamw posted
<@conan_kudo:matrix.org>
16:22:47
FinalBlocker -1 FinalFE +1
<@nielsenb:fedora.im>
16:22:52
Only Workstation, KDE, and Minimal
<@nielsenb:fedora.im>
16:23:36
That fact the server disk image is currently not at all useful is definitely a problem, but not a release blocking one
<@pboy:fedora.im>
16:23:44
Well, OK, so we would drop the SBC completely from Server distribution. Any issues with that?
<@conan_kudo:matrix.org>
16:24:13
that's up to you
<@adamwill:fedora.im>
16:24:16
well, we should probably take a breath and figure out how we got to where we are, hre
<@pboy:fedora.im>
16:24:24
We don't want distribute a useless, non-functional distributable
<@adamwill:fedora.im>
16:25:12
also, not being blocking doesn't mean the bug won't be fixed
<@adamwill:fedora.im>
16:25:38
looking back, the server disk image has never been blocking, it seems like
<@adamwill:fedora.im>
16:25:43
always the minimal disk image and the server ISOs
<@adamwill:fedora.im>
16:25:52
i'd have to do some digging to find out when we decided that, though
<@pboy:fedora.im>
16:27:19
Maybe it gets fixed. but when? Maybe fixed in 44. That doesn't not resolve the problem with 43.
<@adamwill:fedora.im>
16:28:10
i mean, it may still get fixed for f43. there's no need to drop the image immediately
<@pboy:fedora.im>
16:28:45
Agreed, we can try a FE. But if not, we should agree to drop it.
<@conan_kudo:matrix.org>
16:28:49
we also have a whole month to decide whether LVM will get fixed or not
<@adamwill:fedora.im>
16:29:03
it looks like aarch64 images were first added to blocking list in 26, and it was the ISOs then
<@adamwill:fedora.im>
16:29:13
https://fedoraproject.org/wiki/Releases/25/ReleaseBlocking vs. https://fedoraproject.org/wiki/Releases/26/ReleaseBlocking
<@adamwill:fedora.im>
16:29:24
the 32-bit server disk image was blocking at that time. but the 64-bit server disk image never was
<@adamwill:fedora.im>
16:29:36
anyhoo
<@adamwill:fedora.im>
16:30:01
shall we accept this as an FE?
<@adamwill:fedora.im>
16:30:07
i'm -1 blocker +1 FE under current status
<@conan_kudo:matrix.org>
16:30:10
sure
<@derekenz:fedora.im>
16:30:15
Yes
<@nielsenb:fedora.im>
16:30:19
FinalFE +1
<@derekenz:fedora.im>
16:30:39
FinalFE +1
<@pboy:fedora.im>
16:30:49
FinalFE +1
<@lruzicka:fedora.im>
16:31:00
FinalFE +1
<@pboy:fedora.im>
16:31:01
Server WG is somewhat ambivalent. Some would like to get rid of the low-level SBCs. They only embarrass us. This would be an opportunity.
<@nielsenb:fedora.im>
16:32:19
I feel like they missed an opportunity when QA was dropping the ARM support list
<@conan_kudo:matrix.org>
16:32:34
that's not really decision to make in this meeting, but if you want to drop it, that's your call
<@nielsenb:fedora.im>
16:32:42
Could have said "we only want ServerReady" or some such, which I think RadXa might support?
<@adamwill:fedora.im>
16:32:45
well, i mean, as things stand, you sort of *did* drop them already
<@conan_kudo:matrix.org>
16:32:50
FinalFE +1
<@adamwill:fedora.im>
16:32:51
technically no Server image is blocking on SBCs
<@adamwill:fedora.im>
16:33:00
the question is more "do you want to add them" :D
<@nielsenb:fedora.im>
16:33:13
Can you drop what was never picked up? :D
<@conan_kudo:matrix.org>
16:33:32
only the Orion O6
<@pboy:fedora.im>
16:34:01
They have been available on the download page for years.
<@adamwill:fedora.im>
16:34:32
proposed !agreed 2391231 RejectedBlocker AcceptedFreezeException - this is rejected as it's specific to the Server aarch64 disk image and that image is not release-blocking, per https://docs.fedoraproject.org/en-US/releases/f43/blocking/ . it's accepted as an FE as it's obviously a significant bug that cannot be fully resolved with a post-release update
<@adamwill:fedora.im>
16:34:50
ah, i see, you're saying stop shipping the image *at all*
<@adamwill:fedora.im>
16:34:55
well yeah, that'd be up to the WG
<@conan_kudo:matrix.org>
16:35:15
you could also not use LVM in the image and that would fix it too
<@conan_kudo:matrix.org>
16:35:24
most of these problems stem from LVM+XFS
<@lruzicka:fedora.im>
16:35:32
ack (to the proposal)
<@derekenz:fedora.im>
16:35:34
ack
<@pboy:fedora.im>
16:35:36
Conan Kudo: :-)
<@conan_kudo:matrix.org>
16:35:38
ack
<@adamwill:fedora.im>
16:35:49
!agreed 2391231 RejectedBlocker AcceptedFreezeException - this is rejected as it's specific to the Server aarch64 disk image and that image is not release-blocking, per https://docs.fedoraproject.org/en-US/releases/f43/blocking/ . it's accepted as an FE as it's obviously a significant bug that cannot be fully resolved with a post-release update
<@adamwill:fedora.im>
16:35:58
!topic (2394950) No thumbnails for video, music, epub and pdf formats
<@adamwill:fedora.im>
16:35:58
!info Ticket vote: FinalFreezeException (+1,0,-0) (+kparal)
<@adamwill:fedora.im>
16:35:58
!info Ticket vote: FinalBlocker (+2,0,-1) (+nielsenb, +derekenz, -kparal)
<@adamwill:fedora.im>
16:35:58
!info Proposed Blocker, distribution, NEW, depends on other bugs
<@adamwill:fedora.im>
16:35:58
!link https://pagure.io/fedora-qa/blocker-review/issue/1926
<@adamwill:fedora.im>
16:35:58
!link https://bugzilla.redhat.com/show_bug.cgi?id=2394950
<@conan_kudo:matrix.org>
16:36:26
I think this is a fairly serious user experience regression
<@conan_kudo:matrix.org>
16:36:41
technically it _could_ be fixed with updates, but the first impression would be pretty bad
<@nielsenb:fedora.im>
16:37:13
Yeah, I agree it's not *technically* basic functionality
<@nielsenb:fedora.im>
16:37:22
But it's a noticeable regression
<@conan_kudo:matrix.org>
16:37:48
it also would break on upgrade too
<@nielsenb:fedora.im>
16:37:52
Plus the discussion on the ticket makes it sound like thumbnailers are crashing, and nautilus just handles that gracefully, which isn't great.
<@conan_kudo:matrix.org>
16:37:53
which makes the impact pretty severe
<@adamwill:fedora.im>
16:37:55
well, 'is it basic functionality' is the main question here
<@conan_kudo:matrix.org>
16:38:15
I would argue it is basic functionality of picking and looking at files
<@nielsenb:fedora.im>
16:38:17
I think most people using a full-fat DE would consider it basic
<@conan_kudo:matrix.org>
16:38:37
even in lightweight DEs, I think most would argue it's basic for file managers and file pickers to show that
<@conan_kudo:matrix.org>
16:39:34
the problem is that we don't know how broad the damage is for glycin-only gdk-pixbuf
<@adamwill:fedora.im>
16:39:44
i asked mcatanzaro if he can join
<@conan_kudo:matrix.org>
16:39:51
one thing that worries me is that it might have busted some of the wallpaper stuff in various spins
<@conan_kudo:matrix.org>
16:40:21
with the exception of KDE and LXQt, everyone uses gdk-pixbuf for that
<@lruzicka:fedora.im>
16:40:34
I do not remember how that should look like? Is it expected to see small versions of the videos and pictures?
<@lruzicka:fedora.im>
16:40:39
Or is this ok?
<@conan_kudo:matrix.org>
16:40:41
yes
<@conan_kudo:matrix.org>
16:40:51
you should see a frame or a small animated loop
<@conan_kudo:matrix.org>
16:41:05
depending on whether it's a still or movie
<@conan_kudo:matrix.org>
16:41:41
yeah that's the broken output
<@lruzicka:fedora.im>
16:41:45
So this above is not working?
<@conan_kudo:matrix.org>
16:42:02
yes, that's what "not working" looks like
<@mcatanzaro:gnome.org>
16:42:30
<@mcatanzaro:gnome.org>
16:42:30
It's a serious regression but it's also expected, we replaced totem with showtime and showtime does not have its own thumbnailer like totem did
<@mcatanzaro:gnome.org>
16:42:30
In theory we could try using totem thumbnailer anyway
<@adamwill:fedora.im>
16:42:32
Lukáš Růžička we actually had to update some openqa needles for this
<@mcatanzaro:gnome.org>
16:42:37
There's also an ffmpeg thumbnailer that might work
<@adamwill:fedora.im>
16:42:37
but i didn't get time to look into the cause
<@mcatanzaro:gnome.org>
16:43:45
The upstream issue report is https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/issues/35 and includes a proposed replacement, https://gitlab.gnome.org/sophie-h/gst-video-thumbnailer
<@mcatanzaro:gnome.org>
16:43:45
But this is not packaged for Fedora yet, and it doesn't have any releases and is not an official GNOME package yet.
<@mcatanzaro:gnome.org>
16:43:45
<@mcatanzaro:gnome.org>
16:44:19
So... sorry, it's a significant flaw in GNOME 49 and we don't really have a plan other than "wait for upstream"
<@mcatanzaro:gnome.org>
16:44:46
It's not an accident though. I knew thumbnails would be missing.
<@adamwill:fedora.im>
16:45:25
how practical are the ffmpeg / totem options?
<@conan_kudo:matrix.org>
16:46:15
ffmpeg option is pretty easy to do
<@conan_kudo:matrix.org>
16:46:23
even the gst one wouldn't be hard
<@conan_kudo:matrix.org>
16:46:47
thumbnailer configuration was committed on Saturday to the gst one
<@conan_kudo:matrix.org>
16:46:58
totem is toast with glycin
<@decathorpe:fedora.im>
16:47:11
yeah, going back to totem-video-thumbnailer is not an option since it crashes with glycin-only gdk-pixbuf.
<@decathorpe:fedora.im>
16:47:25
it has the same issue as the epub thumbnailer
<@conan_kudo:matrix.org>
16:47:49
tbh, I'm more in favor of reverting glycin this cycle
<@conan_kudo:matrix.org>
16:48:00
it really should have been a fedora change with how much fallout it created
<@decathorpe:fedora.im>
16:48:36
fwiw as glycin package maintainer I would prefer to revert for F43 too. just for purely egotistical reasons (my sanity)
<@decathorpe:fedora.im>
16:49:18
it really wasn't anticipated how much breakage there would be in unexpected places
<@conan_kudo:matrix.org>
16:49:30
I kind of had some idea but I didn't realize that nobody else did
<@conan_kudo:matrix.org>
16:49:46
I only knew because last cycle I did all the JXL enablement stuff and saw how far gdk-pixbuf impacts Fedora
<@adamwill:fedora.im>
16:51:51
well, whether to revert is a bit out of scope of the meeting
<@conan_kudo:matrix.org>
16:51:59
it is a valid way to fix this
<@adamwill:fedora.im>
16:52:03
sure
<@conan_kudo:matrix.org>
16:52:21
but the actual issue I think is FB worthy
<@adamwill:fedora.im>
16:52:21
but we don't have to decide how to fix it here :)
<@adamwill:fedora.im>
16:52:28
i think i'm a weak +1 blocker
<@conan_kudo:matrix.org>
16:52:36
+1 FinalBlocker
<@adamwill:fedora.im>
16:52:38
and leave it up to assignee/workstation wg to decide how to fix it
<@lruzicka:fedora.im>
16:53:25
+1 FinalBlocker
<@nielsenb:fedora.im>
16:53:43
FinalBlocker +1
<@pboy:fedora.im>
16:54:04
Finalblocker 0
<@adamwill:fedora.im>
16:54:56
derek was +1 in the ticket
<@derekenz:fedora.im>
16:55:00
Yes
<@adamwill:fedora.im>
16:55:08
so that's...+5 , -1 (kamil)
<@adamwill:fedora.im>
16:56:48
proposed !agreed 2394950 - AcceptedBlocker (Final) - this is accepted as a violation of "the following applications must start successfully and withstand a basic functionality test" for the file manager. it's a close call, but we think thumbnails are sufficiently important that it'd create a very bad impression for them to be broken
<@conan_kudo:matrix.org>
16:56:55
ack
<@adamwill:fedora.im>
16:56:58
and i totally forgot i have to go meet a guy to look at windows
<@derekenz:fedora.im>
16:56:58
ack
<@adamwill:fedora.im>
16:56:58
ugh
<@adamwill:fedora.im>
16:57:01
can somebody take over?
<@nielsenb:fedora.im>
16:57:04
ack
<@adamwill:fedora.im>
16:57:16
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting is the SOP. but more or less just keep doing what i've been doing
<@adamwill:fedora.im>
16:57:28
https://qa.fedoraproject.org/blockerbugs/milestone/43/final/meeting is where you copy/paste the magic lines from
<@adamwill:fedora.im>
16:58:11
otherwise i'll be back when i can
<@lruzicka:fedora.im>
16:58:48
!agreed 2394950 - AcceptedBlocker (Final) - this is accepted as a violation of "the following applications must start successfully and withstand a basic functionality test" for the file manager. it's a close call, but we think thumbnails are sufficiently important that it'd create a very bad impression for them to be broken
<@lruzicka:fedora.im>
16:59:43
Shall we continue without Adam then?
<@nielsenb:fedora.im>
17:00:45
I think that leaves 3 of us
<@nielsenb:fedora.im>
17:01:08
So right at the minimum
<@lruzicka:fedora.im>
17:01:19
Yeah
<@lruzicka:fedora.im>
17:01:43
But I will have to go in an hour, or so, so that would leave you at the minimum, too :D
<@lruzicka:fedora.im>
17:01:56
Let's try and see how it goes.
<@lruzicka:fedora.im>
17:02:26
!info Proposed Blocker, dracut, ASSIGNED
<@lruzicka:fedora.im>
17:02:26
!topic (2394213) default hostonly-mode "sloppy" results in significant increase in initramfs size
<@lruzicka:fedora.im>
17:02:26
!link https://bugzilla.redhat.com/show_bug.cgi?id=2394213
<@lruzicka:fedora.im>
17:02:26
!link https://pagure.io/fedora-qa/blocker-review/issue/1925
<@lruzicka:fedora.im>
17:02:26
!info Ticket vote: FinalBlocker (+2,0,-0) (+derekenz, +nielsenb)
<@nielsenb:fedora.im>
17:03:27
This one basically boils down to, do we see upgrades of legacy installs with smaller /boot partitions as blocking?
<@conan_kudo:matrix.org>
17:03:31
yes
<@conan_kudo:matrix.org>
17:04:03
that is a natural consequence of making in-place upgrades a release-blocking exercise
<@nielsenb:fedora.im>
17:04:07
I could be swayed either way, at some point when you change a default, support of the old default becomes untenable
<@lruzicka:fedora.im>
17:05:11
This will be a problem for anyone that have set their boot partitions too little.
<@conan_kudo:matrix.org>
17:05:14
unfortunately, the missing grub piece to move boot to btrfs subvolume hasn't been added to the fedora grub tree, so I don't have an nice migration path for existing separate /boot
<@nielsenb:fedora.im>
17:05:51
I can't see when the default changed
<@nielsenb:fedora.im>
17:06:01
I can't find when the default changed
<@nielsenb:fedora.im>
17:06:45
Do you know if that's planning on landing at some point?
<@conan_kudo:matrix.org>
17:07:16
there's a bug open for it...
<@conan_kudo:matrix.org>
17:07:19
!bug 2372973
<@zodbot:fedora.im>
17:07:21
RHBZ#2372973 (https://bugzilla.redhat.com/2372973): [grub2]: GRUB is unable to use bootloader header space for grubenv on btrfs (patch available)
<@conan_kudo:matrix.org>
17:07:40
it's waiting on the grub maintainers
<@lruzicka:fedora.im>
17:08:38
Would that be able to fix an existing installation with a small boot partition?
<@conan_kudo:matrix.org>
17:09:06
yes
<@conan_kudo:matrix.org>
17:09:21
basically make a new subvolume, update the config, and reboot to switch to it
<@conan_kudo:matrix.org>
17:09:31
after syncing all the files out of the partition
<@conan_kudo:matrix.org>
17:09:42
you could optionally delete the volume later and expand the btrfs volume to take that space
<@lruzicka:fedora.im>
17:09:53
So, if we decided that it was a blocker, there would be a solution with the SuSE's patch, if I understand this correctly.
<@conan_kudo:matrix.org>
17:10:04
it would be _a_ way to solve it, yes
<@nielsenb:fedora.im>
17:10:05
A manual solution, but yes
<@conan_kudo:matrix.org>
17:10:20
another way would be to force dracut to use strict mode for hostonly by default by patching dracut
<@lruzicka:fedora.im>
17:10:42
This would have to be documented in any case, of course.
<@nielsenb:fedora.im>
17:10:50
I personally would rather see us configure dracut to strict, but I understand the apprehension
<@conan_kudo:matrix.org>
17:10:50
yup
<@nielsenb:fedora.im>
17:11:04
And I think even changing dracut now leaves some people stuck
<@decathorpe:fedora.im>
17:12:03
yeah, the only way for some people that are already stuck is to set installonly_limit=2
<@decathorpe:fedora.im>
17:12:37
there's like a dozen "help boot full can't upgrade" posts on discourse already
<@nielsenb:fedora.im>
17:12:56
I think we have people that already have full boots, because the change has already landed, would setting installonly_limit fix that case?
<@nielsenb:fedora.im>
17:13:09
Wouldn't they also need to manually remove a kernel?
<@supakeen:fedora.im>
17:13:11
They would also need to manually remove the old kernels AFAIK.
<@decathorpe:fedora.im>
17:13:30
the next dnf transaction would remove the oldest one
<@decathorpe:fedora.im>
17:13:58
(yes, I tested this)
<@nielsenb:fedora.im>
17:14:00
I guess, again, we're not deciding how to fix it here, just whether we block on it
<@conan_kudo:matrix.org>
17:14:09
we should block on it
<@nielsenb:fedora.im>
17:14:12
Though this would be helpful commonbugs fodder
<@conan_kudo:matrix.org>
17:14:14
+1 FinalBlocker
<@nielsenb:fedora.im>
17:14:23
I'm still team blocker as well
<@nielsenb:fedora.im>
17:14:26
FinalBlocker +1
<@decathorpe:fedora.im>
17:14:51
fwiw this not only prevents upgrades to F43 but also updates on existing F42 installs but yes :)
<@lruzicka:fedora.im>
17:14:53
Ok, but if basically this is a progress
<@derekenz:fedora.im>
17:14:55
Sill FinalBlocker +1
<@lruzicka:fedora.im>
17:15:06
That's 3
<@derekenz:fedora.im>
17:15:10
Still FinalBlocker +1
<@lruzicka:fedora.im>
17:15:10
I would like to ask:
<@pboy:fedora.im>
17:15:43
+1
<@supakeen:fedora.im>
17:16:24
I'm +1 FinalBlocker for it, but not on the basis of it blocking upgrades since I feel we can document our way out of that (or package), I am +1 FinalBlocker on the basis that 512 MiB VMs/SBCs no longer boot.
<@lruzicka:fedora.im>
17:16:27
If this is how the software develops, and sloppy would be a safer option in terms of bringing more drivers into the system ... would it not be worse for people who might need to change hardware between reboots?
<@lruzicka:fedora.im>
17:16:32
if we used strict?
<@nielsenb:fedora.im>
17:17:05
Yes
<@decathorpe:fedora.im>
17:17:19
isn't that what the rescue kernel is for? ...
<@nielsenb:fedora.im>
17:18:03
Also yes, at least as I understand it. But having to use that instead of it "just working" is still worse.
<@lruzicka:fedora.im>
17:18:04
+5 blocker / 0 non-blocker so far
<@decathorpe:fedora.im>
17:18:38
to me it sounds like as if the new sloppy sloppy mode is just approaching what the rescue initramfs is doing. which is just duplicating or triplicating stuff on /boot
<@nielsenb:fedora.im>
17:18:49
But even sloppy already doesn't include *everything*, so depending on the hardware change you might be stuck anyway
<@lruzicka:fedora.im>
17:19:28
Ok, what I liked about Linux was that it would mostly work when something was changed.
<@nielsenb:fedora.im>
17:19:31
Which I why I really don't understand the "let's include ever more stuff with sloppy"
<@nielsenb:fedora.im>
17:19:53
Because any line except "everything" is pretty arbitrary
<@lruzicka:fedora.im>
17:20:17
Sure. You cannot have everything, the line needs be drawn somewhere.
<@nielsenb:fedora.im>
17:20:25
It is a cool trick, but not at the cost of breaking in place upgrades
<@nielsenb:fedora.im>
17:20:31
At least to me
<@supakeen:fedora.im>
17:21:14
Anyhow, I think we've determined this to be a blocker and we can move on? :)
<@lruzicka:fedora.im>
17:21:20
So, is there anyone against a blocker?
<@lruzicka:fedora.im>
17:23:47
Let me write the reasoning.
<@lruzicka:fedora.im>
17:26:26
proposed !agreed 2394213 - AcceptedBlocker (Final) - this is accepted as a violation of "Upgrade requirements" criterion because increasing the initramfs space makes the system unable to upgrade if the space on the boot partition is taken by bigger images.
<@lruzicka:fedora.im>
17:26:52
maybe patch
<@conan_kudo:matrix.org>
17:26:59
ack
<@derekenz:fedora.im>
17:27:08
ack
<@pboy:fedora.im>
17:27:13
ack
<@lruzicka:fedora.im>
17:27:42
proposed !agreed 2394213 - AcceptedBlocker (Final) - this is accepted as a violation of "Upgrade requirements" criterion because increasing the initramfs space makes the system unable to upgrade if the space on the boot partition is taken by bigger images. We think that this is serious enough to be addressed before the Final release.
<@lruzicka:fedora.im>
17:27:54
Please reack, I added one more line.
<@derekenz:fedora.im>
17:28:16
ack
<@nielsenb:fedora.im>
17:28:23
ack
<@pboy:fedora.im>
17:28:38
ack
<@lruzicka:fedora.im>
17:28:42
!agreed 2394213 - AcceptedBlocker (Final) - this is accepted as a violation of "Upgrade requirements" criterion because increasing the initramfs space makes the system unable to upgrade if the space on the boot partition is taken by bigger images. We think that this is serious enough to be addressed before the Final release.
<@lruzicka:fedora.im>
17:28:55
Is adamw back?
<@lruzicka:fedora.im>
17:29:32
!info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
<@lruzicka:fedora.im>
17:29:32
!link https://bugzilla.redhat.com/show_bug.cgi?id=2391242
<@lruzicka:fedora.im>
17:29:32
!topic (2391242) Firefox slows down significantly when private mode invoked
<@lruzicka:fedora.im>
17:29:32
!info Proposed Blocker, firefox, NEW
<@lruzicka:fedora.im>
17:29:32
!link https://pagure.io/fedora-qa/blocker-review/issue/1896
<@lruzicka:fedora.im>
17:29:58
So this one has been around for some time, we have already punted it twice.
<@lruzicka:fedora.im>
17:30:44
In the meantime it has evolved into a possible Mesa issue.
<@lruzicka:fedora.im>
17:31:04
https://gitlab.freedesktop.org/mesa/mesa/-/issues/13877
<@lruzicka:fedora.im>
17:32:30
The closest reproducer being: The problem can be triggered, fairly reliably, by attempting to resize or close Firefox windows, or when selecting locations while downloading files.
<@lruzicka:fedora.im>
17:33:11
It seems to affect AMD drivers, although Mesa developer claims that no AMD related issues are seen in the log files.
<@lruzicka:fedora.im>
17:33:21
adamw: you can take it, then :D
<@pboy:fedora.im>
17:34:00
Sorry, I have to leave for a family dinner. It's late in the evening in Europe.
<@pboy:fedora.im>
17:34:01
Bye
<@lruzicka:fedora.im>
17:34:11
Bye, Peter Boy (ServerWG, Docs)
<@nielsenb:fedora.im>
17:34:15
It's starting to appear to me like quite a bit of AMD hardware is affected
<@aggraxis:fedora.im>
17:34:39
!hi
<@zodbot:fedora.im>
17:34:40
Paul Maconi (aggraxis) - he / him / his
<@aggraxis:fedora.im>
17:34:52
I've been lurking. I can try to pick up for Peter
<@lruzicka:fedora.im>
17:34:58
Sure
<@adamwill:fedora.im>
17:35:04
i think it's all strix point-ish hardware affected
<@lruzicka:fedora.im>
17:36:11
I updated to the latest Mesa and I have not seen the issue since then. Might be coincidence, might be fixed.
<@nielsenb:fedora.im>
17:36:44
Someone reported a Kracken
<@lruzicka:fedora.im>
17:37:02
There is a workaround suggested, to use Zink for FF rendering.
<@nielsenb:fedora.im>
17:37:10
And a Bonaire
<@lruzicka:fedora.im>
17:37:22
Are these also AMD?
<@lruzicka:fedora.im>
17:37:55
Yes, they are :D
<@nielsenb:fedora.im>
17:38:16
I was happy to ignore it when it was just the privileged Strix users negatively impacted :D
<@adamwill:fedora.im>
17:40:22
where'd you see a bonaire?
<@nielsenb:fedora.im>
17:40:59
https://bugzilla.mozilla.org/show_bug.cgi?id=1986254
<@nielsenb:fedora.im>
17:41:19
Last report
<@adamwill:fedora.im>
17:41:50
that doesn't actually say it's seeing the same refresh issues as me and lukas, though...
<@adamwill:fedora.im>
17:44:10
i guess i might wanna punt on this one for more clarification? it is a *bit* fuzzy atm
<@lruzicka:fedora.im>
17:45:34
Maybe, it will go away by itself, if we wait long enough - Czech government uses this technique. :D
<@adamwill:fedora.im>
17:46:59
ah, the ostrich blocker philosophy
<@nielsenb:fedora.im>
17:47:12
I think all governments do
<@lruzicka:fedora.im>
17:47:58
I have no problem to punt it again :D
<@lruzicka:fedora.im>
17:48:52
I have to leave for 10-15 mins, I will kiss my daughters a good night.
<@lruzicka:fedora.im>
17:48:59
+1 punt for this one
<@nielsenb:fedora.im>
17:49:29
I'm fine with a punt
<@nielsenb:fedora.im>
17:49:34
Punt +1
<@adamwill:fedora.im>
17:50:46
proposed !agreed 2391242 - punt (delay decision) - we agreed to punt this one as the exact details of the problem are still not clear. we'll continue working with upstream(s) to clarify the issue for next week's meeting
<@aggraxis:fedora.im>
17:51:03
looks good to me
<@nielsenb:fedora.im>
17:51:12
ack
<@derekenz:fedora.im>
17:51:24
ack
<@derekenz:fedora.im>
17:52:06
Sorry gtg
<@adamwill:fedora.im>
17:53:20
!agreed 2391242 - punt (delay decision) - we agreed to punt this one as the exact details of the problem are still not clear. we'll continue working with upstream(s) to clarify the issue for next week's meeting
<@adamwill:fedora.im>
17:53:31
!info Proposed Blocker, glycin, ON_QA
<@adamwill:fedora.im>
17:53:31
!topic (2393593) Crashes in prefer_sve_ifuncs/__uname on SVE enabled machine due to seccomp filter
<@adamwill:fedora.im>
17:53:31
!link https://bugzilla.redhat.com/show_bug.cgi?id=2393593
<@adamwill:fedora.im>
17:53:31
!info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +derekenz)
<@adamwill:fedora.im>
17:53:31
!link https://pagure.io/fedora-qa/blocker-review/issue/1917
<@adamwill:fedora.im>
17:56:06
Jeremy Linton around?
<@adamwill:fedora.im>
17:56:11
it seems a bit unclear what hw this affects
<@adamwill:fedora.im>
17:57:31
i'm not sure what aarch64 machines are SVE-enabled. sounds like orion6 and maybe newer / heavier AWS instances?
<@adamwill:fedora.im>
18:00:20
i could be punt on this just so it'll go away when the update goes stable. :P
<@nielsenb:fedora.im>
18:00:44
Yeah
<@nielsenb:fedora.im>
18:01:00
I don't think glycin is real relevant on AWS
<@lruzicka:fedora.im>
18:01:05
#metoo
<@lruzicka:fedora.im>
18:01:22
+1 punt
<@nielsenb:fedora.im>
18:01:26
And if it's "just" the Orion for consumer hardware, I'm not real compelled to block
<@nielsenb:fedora.im>
18:01:30
So a punt would be fine
<@adamwill:fedora.im>
18:01:55
ok
<@jlinton:fedora.im>
18:02:04
Hi/ yes i'm around
<@aggraxis:fedora.im>
18:02:22
I'm not even sure you can call some of the other examples from wikipedia and elsewhere citing SVE support as "consumer hardware"
<@jlinton:fedora.im>
18:02:46
This is any SVE machine, which is anything v9+ but the apple HW at this point.
<@conan_kudo:matrix.org>
18:02:47
no AS hardware supports SVE either
<@jlinton:fedora.im>
18:03:16
I'm fine with it not blocking, although there is a build, i have on my sanity check list.
<@adamwill:fedora.im>
18:03:35
i can be -1 too
<@adamwill:fedora.im>
18:03:36
:P
<@jlinton:fedora.im>
18:03:39
Final yes, not beta
<@jlinton:fedora.im>
18:03:45
final blocker, yes
<@adamwill:fedora.im>
18:03:56
oh, we're on final here
<@adamwill:fedora.im>
18:04:03
beta is old news
<@jlinton:fedora.im>
18:05:19
Its a fairly small fix, which will fix anyone trying to run anything gnome'ish on !sbc levels of HW.
<@adamwill:fedora.im>
18:05:54
since we all get a vote now, i'm not convinced i wanna hold up final for what practically appears to be a single board nobody can buy (asahi has their own release process, we don't account for apple hw here)
<@adamwill:fedora.im>
18:06:03
since we all get a vote now, i'm not convinced i wanna hold up final for what practically appears to be a single board that's a pain to buy (asahi has their own release process, we don't account for apple hw here)
<@adamwill:fedora.im>
18:06:12
but on the whole, punt seems tactically appropriate
<@nielsenb:fedora.im>
18:07:06
Yeah
<@jlinton:fedora.im>
18:07:09
Its not just that board.
<@nielsenb:fedora.im>
18:07:10
Punt +1
<@jlinton:fedora.im>
18:07:15
its any server GUI app too
<@jlinton:fedora.im>
18:07:25
because the server space has had SVE for 5+ years now.
<@jlinton:fedora.im>
18:07:37
and the phone space for the last couple.
<@adamwill:fedora.im>
18:07:45
we don't block on graphical stuff on servers on x86_64
<@jlinton:fedora.im>
18:07:48
so any phone SoC style devices.
<@adamwill:fedora.im>
18:07:56
the supported graphical server interface is 'access it with cockput'
<@adamwill:fedora.im>
18:08:01
the supported graphical server interface is 'access it with cockpit'
<@jlinton:fedora.im>
18:08:14
which might be the latest laptops too, i've not checked anything newer than the x13s
<@adamwill:fedora.im>
18:08:18
anyhow
<@jlinton:fedora.im>
18:08:28
Cockpit is going to have the same issues
<@jlinton:fedora.im>
18:08:35
because it has a IPKVM function
<@conan_kudo:matrix.org>
18:09:07
nothing we can actually run on that people can buy supports SVE as far as I can see, beyond maybe cloud hardware
<@adamwill:fedora.im>
18:09:14
proposed !agreed 2393593 - punt (delay decision) - the call on whether this affects enough hardware to be a blocker is complex, and practically speaking, it should get closed relatively soon when the update goes stable anyway, so we can avoid spending time on it
<@conan_kudo:matrix.org>
18:09:18
ack
<@aggraxis:fedora.im>
18:09:20
ack
<@jlinton:fedora.im>
18:09:21
This is the equivilant of saying that machines with AVX2 aren't supported.
<@adamwill:fedora.im>
18:09:58
well, no, it isn't, because we definitely have tens of thousands of people running fedora on those.
<@nielsenb:fedora.im>
18:10:08
ack
<@adamwill:fedora.im>
18:10:09
we do not definitely have tens of thousands of people running graphical fedora on...whatever this breaks.
<@conan_kudo:matrix.org>
18:10:20
and also it has been a long time since an x86 instruction causes runtime failures
<@conan_kudo:matrix.org>
18:10:39
this isn't the first time in the past few years that it has happened with arm stuff
<@adamwill:fedora.im>
18:10:50
!agreed 2393593 - punt (delay decision) - the call on whether this affects enough hardware to be a blocker is complex, and practically speaking, it should get closed relatively soon when the update goes stable anyway, so we can avoid spending time on it
<@adamwill:fedora.im>
18:10:59
!link https://pagure.io/fedora-qa/blocker-review/issue/1927
<@adamwill:fedora.im>
18:10:59
!link https://bugzilla.redhat.com/show_bug.cgi?id=2372978
<@adamwill:fedora.im>
18:10:59
!topic (2372978) packagekitd runs in infinite loop consuming lot of CPU
<@adamwill:fedora.im>
18:10:59
!info Proposed Blocker, PackageKit, NEW
<@conan_kudo:matrix.org>
18:11:36
wonder if that's more rpm6 fallout
<@conan_kudo:matrix.org>
18:12:05
those are all old gpg keys being auto-added because of "desired" behavior to hide gpg stuff
<@nielsenb:fedora.im>
18:12:56
I have seen the errors on a Pi, but I guess I didn't notice if packagekit was spinning
<@nielsenb:fedora.im>
18:13:03
I don't see either behavior on my laptop
<@adamwill:fedora.im>
18:13:29
we only reverted to packagekit quite late for beta, remember
<@conan_kudo:matrix.org>
18:14:25
but I haven't seen it in Fedora KDE stuff either (we never did the dnf5daemon thing)
<@lruzicka:fedora.im>
18:15:23
I did see this (or something similar) on my machine. When I deleted the google-chrome repository, it sort of went away
<@adamwill:fedora.im>
18:15:32
ah
<@adamwill:fedora.im>
18:15:36
that seems important
<@conan_kudo:matrix.org>
18:15:48
oh that means it's related to how chrome keys are managed by google
<@conan_kudo:matrix.org>
18:15:58
wouldn't be the first time that has broken things
<@nielsenb:fedora.im>
18:16:11
Do we block on things related to the chrome repo?
<@nielsenb:fedora.im>
18:16:18
I feel like it's been conditional in the past
<@lruzicka:fedora.im>
18:16:19
But I get a lot of these:
<@lruzicka:fedora.im>
18:16:19
kvě 27 14:07:15 localhost-live.lan packagekitd[1925]: Failed to get cache filename for glibc
<@lruzicka:fedora.im>
18:16:19
kvě 27 14:07:15 localhost-live.lan packagekitd[1925]: Failed to get cache filename for libarchive
<@lruzicka:fedora.im>
18:16:19
```
<@lruzicka:fedora.im>
18:16:19
kvě 27 14:07:15 localhost-live.lan packagekitd[1925]: Failed to get cache filename for glibc
<@lruzicka:fedora.im>
18:16:19
kvě 27 14:07:15 localhost-live.lan packagekitd[1925]: Failed to get cache filename for elfutils-libs
<@lruzicka:fedora.im>
18:16:19
```
<@nielsenb:fedora.im>
18:16:47
Hm, I don't see those either
<@nielsenb:fedora.im>
18:16:52
#blessed
<@adamwill:fedora.im>
18:17:45
this feels like a bit of a tough one to call a blocker to me...
<@lruzicka:fedora.im>
18:17:57
“Blessed are the meek, for they shall inherit the earth.”
<@adamwill:fedora.im>
18:17:58
but, let's see where my vm test goes
<@adamwill:fedora.im>
18:19:04
i have a bunch of those 'failed to get cache filename' ones in the live session, but they don't seem to be looping at least
<@lruzicka:fedora.im>
18:20:18
No, fortunately, these are not looping.
<@adamwill:fedora.im>
18:22:20
ok, my fresh install is done, let's see\
<@adamwill:fedora.im>
18:23:00
don't see this yet at all
<@nielsenb:fedora.im>
18:23:14
Clone it, add the chrome repo
<@adamwill:fedora.im>
18:23:28
yeah, was planning that
<@adamwill:fedora.im>
18:25:33
still nothing yet
<@adamwill:fedora.im>
18:26:14
so, hum. another pnut?
<@adamwill:fedora.im>
18:26:16
also punt
<@nielsenb:fedora.im>
18:26:25
I guess
<@nielsenb:fedora.im>
18:26:32
Punt +1
<@conan_kudo:matrix.org>
18:26:34
+1 punt
<@lruzicka:fedora.im>
18:26:42
+1 punt
<@aggraxis:fedora.im>
18:27:00
+1 punt
<@adamwill:fedora.im>
18:28:20
proposed !agreed 2372978 - punt (delay decision) - we weren't able to reproduce this on a clean f43 beta install in a quick test, so we want to punt to try and get more detail on when and why this issue happens
<@nielsenb:fedora.im>
18:28:57
ack
<@aggraxis:fedora.im>
18:28:59
ack
<@conan_kudo:matrix.org>
18:29:12
ack
<@adamwill:fedora.im>
18:29:26
!agreed 2372978 - punt (delay decision) - we weren't able to reproduce this on a clean f43 beta install in a quick test, so we want to punt to try and get more detail on when and why this issue happens
<@adamwill:fedora.im>
18:29:35
!topic (2394561) SELinux is preventing systemd from 'open' accesses on the file /tmp/webui-cockpit-ws.env.
<@adamwill:fedora.im>
18:29:35
!link https://bugzilla.redhat.com/show_bug.cgi?id=2394561
<@adamwill:fedora.im>
18:29:35
!info Proposed Blocker, selinux-policy, ASSIGNED
<@adamwill:fedora.im>
18:29:35
!link https://pagure.io/fedora-qa/blocker-review/issue/1922
<@adamwill:fedora.im>
18:29:35
!info Ticket vote: FinalBlocker (+4,0,-0) (+geraldosimiao, +derekenz, +nielsenb, +kparal)
<@adamwill:fedora.im>
18:30:37
seems pretty open and shut
<@adamwill:fedora.im>
18:30:40
+1 blocker
<@adamwill:fedora.im>
18:30:41
anyone opposed?
<@aggraxis:fedora.im>
18:30:54
I saw this as well during testing for multiple images
<@aggraxis:fedora.im>
18:30:57
+1 blocker
<@nielsenb:fedora.im>
18:31:22
FinalBlocker +1
<@lruzicka:fedora.im>
18:31:28
+1 FinalBlocker
<@adamwill:fedora.im>
18:31:37
proposed !agreed 2394561 - AcceptedBlocker (Final) - this is accepted as a violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image..."
<@aggraxis:fedora.im>
18:32:11
ack
<@nielsenb:fedora.im>
18:32:41
ack
<@lruzicka:fedora.im>
18:32:59
ack
<@adamwill:fedora.im>
18:33:06
!agreed 2394561 - AcceptedBlocker (Final) - this is accepted as a violation of "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image..."
<@adamwill:fedora.im>
18:33:19
!link https://pagure.io/fedora-qa/blocker-review/issue/1921
<@adamwill:fedora.im>
18:33:19
!info Proposed Blocker, spice-vdagent, NEW
<@adamwill:fedora.im>
18:33:19
!link https://bugzilla.redhat.com/show_bug.cgi?id=2394505
<@adamwill:fedora.im>
18:33:19
!topic (2394505) copy and paste doesn't not work between f42 host and f43 guest
<@adamwill:fedora.im>
18:33:19
!info Ticket vote: FinalBlocker (+0,0,-3) (-boniboyblue, -nielsenb, -kparal)
<@adamwill:fedora.im>
18:33:19
!info Ticket vote: FinalFreezeException (+1,0,-0) (+kparal)
<@adamwill:fedora.im>
18:34:07
agreed with the sentiment in the ticket, it's annoying but not a blocker
<@aggraxis:fedora.im>
18:35:06
same. And it looks like it's not every variant. The cinnamon clients behaved.
<@adamwill:fedora.im>
18:35:16
this particular case is specific to workstation.
<@lruzicka:fedora.im>
18:35:30
It hinders testability
<@adamwill:fedora.im>
18:35:34
only the vm end should matter, though.
<@adamwill:fedora.im>
18:35:48
Lukáš Růžička it's very easy to work around. just start the service manually
<@lruzicka:fedora.im>
18:36:54
Hmm, via systemctl?
<@conan_kudo:matrix.org>
18:37:19
wait, is this related to some of the changes with xdg-autostart for gnome 49?
<@conan_kudo:matrix.org>
18:37:35
I vaguely recall that stuff was completely rejiggered this cycle
<@adamwill:fedora.im>
18:38:22
Yes.
<@conan_kudo:matrix.org>
18:38:33
oh so I guess we need to get the user unit working now?
<@adamwill:fedora.im>
18:38:43
Check the links I just added. The vdagent just isn't being autostarted any more.
<@adamwill:fedora.im>
18:38:45
Yes.
<@adamwill:fedora.im>
18:39:24
do we want to accept as an FE?
<@adamwill:fedora.im>
18:39:26
i'd say yes
<@adamwill:fedora.im>
18:39:32
it'd be nice to fix this in the release lives
<@conan_kudo:matrix.org>
18:39:36
yeah probably
<@conan_kudo:matrix.org>
18:39:44
good for reputation stuff
<@conan_kudo:matrix.org>
18:39:48
+1 FinalFE
<@lruzicka:fedora.im>
18:40:18
Definitely, +1 FinalFE at least
<@nielsenb:fedora.im>
18:40:22
FinalFE +1
<@aggraxis:fedora.im>
18:41:01
+1 FinalFE
<@adamwill:fedora.im>
18:41:24
proposed !agreed 2394505 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this clearly doesn't meet the blocker criteria (note it's been broken forever on KDE and we're not blocking on that), but it's very annoying and would be good to ensure it's fixed on the Final workstation live if we can, so accepted as an FE
<@nielsenb:fedora.im>
18:41:35
ack
<@aggraxis:fedora.im>
18:41:42
ack
<@cmurf:fedora.im>
18:42:14
<@cmurf:fedora.im>
18:42:14
<@cmurf:fedora.im>
18:42:14
Maybe add this to the devel discussion.
<@cmurf:fedora.im>
18:42:14
If sloppy is even remotely a possibility for 43, I think we should preemptively bump boot volume for new installations to 2GiB. And in Fedora 41 & 42 only push an update changing dnf.conf to limit 2 kernels...
<@cmurf:fedora.im>
18:42:14
<@cmurf:fedora.im>
18:42:14
Does this only prevent the kernel from updating? The remaining updates proceed? What about major/system upgrades?
<@cmurf:fedora.im>
18:42:14
The change from 500M to 1G boot was around 2016 or 2017. There is a devel discussion but no change proposal.
<@lruzicka:fedora.im>
18:42:22
ack
<@cmurf:fedora.im>
18:42:42
<@cmurf:fedora.im>
18:42:42
Does this only prevent the kernel from updating? The remaining updates proceed? What about major/system upgrades?
<@cmurf:fedora.im>
18:42:42
If sloppy is even remotely a possibility for 43, I think we should preemptively bump boot volume for new installations to 2GiB. And in Fedora 41 & 42 only push an update changing dnf.conf to limit 2 kernels...
<@cmurf:fedora.im>
18:42:42
Maybe I should add this to the devel discussion?
<@cmurf:fedora.im>
18:42:42
The change from 500M to 1G boot was around 2016 or 2017. There is a devel discussion but no change proposal.
<@cmurf:fedora.im>
18:42:55
<@cmurf:fedora.im>
18:42:55
If sloppy is even remotely a possibility for 43, I think we should preemptively bump boot volume for new installations to 2GiB. And in Fedora 41 & 42 only push an update changing dnf.conf to limit 2 kernels...
<@cmurf:fedora.im>
18:42:55
The change from 500M to 1G boot was around 2016 or 2017. There is a devel discussion but no change proposal.
<@cmurf:fedora.im>
18:42:55
Maybe I should add this to the devel discussion?
<@cmurf:fedora.im>
18:42:55
<@cmurf:fedora.im>
18:42:55
Does this only prevent the kernel from updating? The remaining updates proceed? What about major/system upgrades?
<@adamwill:fedora.im>
18:43:32
wow, welcome to an hour ago, cmurf
<@adamwill:fedora.im>
18:43:41
!agreed 2394505 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this clearly doesn't meet the blocker criteria (note it's been broken forever on KDE and we're not blocking on that), but it's very annoying and would be good to ensure it's fixed on the Final workstation live if we can, so accepted as an FE
<@adamwill:fedora.im>
18:43:54
that's all the proposed blockers
<@adamwill:fedora.im>
18:44:04
and there are no FEs
<@nielsenb:fedora.im>
18:44:08
I have to go, bye all!
<@adamwill:fedora.im>
18:44:09
so let's very quickly do...
<@adamwill:fedora.im>
18:44:11
cta brandon!
<@adamwill:fedora.im>
18:44:15
!topic Accepted Final Blockers
<@adamwill:fedora.im>
18:44:40
!info all but one of these are 'image oversize' blockers, i will take appropriate action on those (mostly, propose increasing the limits)
<@adamwill:fedora.im>
18:44:50
!action adamw to deal with all the image oversize bugs, somehow or other
<@adamwill:fedora.im>
18:44:58
!link https://pagure.io/fedora-qa/blocker-review/issue/1888
<@adamwill:fedora.im>
18:44:58
!info Accepted Blocker, gjs, NEW
<@adamwill:fedora.im>
18:44:58
!topic (2391291) Switching on magnifier keeps crashing Gnome Shell
<@adamwill:fedora.im>
18:44:58
!link https://bugzilla.redhat.com/show_bug.cgi?id=2391291
<@adamwill:fedora.im>
18:46:16
anyone know if we're anywhere on this?
<@adamwill:fedora.im>
18:46:53
ah, looks like there's a request in the upstream issue
<@adamwill:fedora.im>
18:46:54
https://gitlab.gnome.org/GNOME/gjs/-/issues/705#note_2548444
<@adamwill:fedora.im>
18:47:00
"would someone be able to get one by executing call gjs_dumpstack() in GDB when paused on the crash site?"
<@adamwill:fedora.im>
18:47:07
can you do that, Lukáš Růžička ?
<@adamwill:fedora.im>
18:47:30
i think you should be able to attach gdb to a running gnome-shell from a vt, or so
<@lruzicka:fedora.im>
18:47:32
I have read the requirement, but I do not know how to get what he wants.
<@lruzicka:fedora.im>
18:47:52
how do I gdb the whole gnome-shell?
<@adamwill:fedora.im>
18:49:06
you `gdb attach` to the process. in theory, anyway
<@adamwill:fedora.im>
18:49:15
i haven't done it for a while
<@lruzicka:fedora.im>
18:49:17
aaahha
<@adamwill:fedora.im>
18:49:20
could ask for help in the workstation room also
<@lruzicka:fedora.im>
18:49:30
I will try that tomorrow.
<@adamwill:fedora.im>
18:49:30
maybe you give it a go and if you can't get it going ask me or kparal?
<@lruzicka:fedora.im>
18:49:54
Yeah.
<@adamwill:fedora.im>
18:50:06
!info upstream asked us for a js stack trace, we will try to provide one
<@adamwill:fedora.im>
18:50:23
!action lruzicka to try and provide requested info in https://gitlab.gnome.org/GNOME/gjs/-/issues/705#note_2548444 , kparal and adamw to assist if necessary
<@adamwill:fedora.im>
18:50:38
!topic Open floor
<@adamwill:fedora.im>
18:50:43
any other business before I go for lunch? :D
<@lruzicka:fedora.im>
18:50:55
nopey
<@aggraxis:fedora.im>
18:51:15
Nothing, thank you for taking us through this.
<@zodbot:fedora.im>
18:51:52
aggraxis gave a cookie to lruzicka. They now have 37 cookies, 2 of which were obtained in the Fedora 42 release cycle
<@adamwill:fedora.im>
18:52:50
thanks for coming folks!
<@adamwill:fedora.im>
18:52:52
!endmeeting