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