2025-09-22 16:01:19 <@adamwill:fedora.im> !startmeeting F43-blocker-review
2025-09-22 16:01:20 <@meetbot:fedora.im> Meeting started at 2025-09-22 16:01:19 UTC
2025-09-22 16:01:20 <@meetbot:fedora.im> The Meeting name is 'F43-blocker-review'
2025-09-22 16:01:24 <@adamwill:fedora.im> !topic Roll Call
2025-09-22 16:01:29 <@adamwill:fedora.im> hi hi, who's around for blocker review fun?
2025-09-22 16:01:34 <@jlinton:fedora.im> .hi
2025-09-22 16:01:35 <@boniboyblue:fedora.im> !hi
2025-09-22 16:01:36 <@zodbot:fedora.im> Christopher Boni (boniboyblue)
2025-09-22 16:01:37 <@pvalena:matrix.org> Hi!
2025-09-22 16:01:39 <@kashyapc:fedora.im> !hi
2025-09-22 16:01:41 <@zodbot:fedora.im> Kashyap Chamarthy (kashyapc)
2025-09-22 16:01:41 <@jlinton:fedora.im> !hi
2025-09-22 16:01:42 <@nielsenb:fedora.im> !hi
2025-09-22 16:01:42 <@zodbot:fedora.im> Jeremy Linton (jlinton)
2025-09-22 16:01:43 <@zodbot:fedora.im> Brandon Nielsen (nielsenb)
2025-09-22 16:02:02 <@pvalena:matrix.org> !hi
2025-09-22 16:02:03 <@zodbot:fedora.im> No Fedora Accounts users have the @pvalena:matrix.org Matrix Account defined
2025-09-22 16:02:14 <@kashyapc:fedora.im> I'm afraid, I did not come prepared, as I got dragged into some RISC-V hardware wrangling stuff for Fedora
2025-09-22 16:02:16 <@derekenz:fedora.im> !hi
2025-09-22 16:02:18 <@zodbot:fedora.im> Derek Enz (derekenz)
2025-09-22 16:02:22 <@pboy:fedora.im> !hi 
2025-09-22 16:02:23 <@zodbot:fedora.im> Peter Boy (pboy)
2025-09-22 16:02:55 <@jsteffan:fedora.im> !hi
2025-09-22 16:02:56 <@zodbot:fedora.im> Jonathan Steffan (jsteffan)
2025-09-22 16:03:05 <@pvalena:fedora.im> !hi
2025-09-22 16:03:06 <@zodbot:fedora.im> Pavel Valena (pvalena)
2025-09-22 16:03:31 <@adamwill:fedora.im> hi hi everyone, thanks for coming
2025-09-22 16:04:05 <@kparal:matrix.org> !hi
2025-09-22 16:04:07 <@zodbot:fedora.im> Kamil Páral (kparal) - he / him / his
2025-09-22 16:07:04 <@adamwill:fedora.im> sorry, i didn't get ahead of the ticket votes this morning (had a meeting before that one) so i'm trying to do that
2025-09-22 16:07:06 <@adamwill:fedora.im> let's get started, though
2025-09-22 16:07:14 <@adamwill:fedora.im> boilerplate!
2025-09-22 16:07:15 <@adamwill:fedora.im> !info The bugs up for review today are available at:
2025-09-22 16:07:15 <@adamwill:fedora.im> !topic Introduction
2025-09-22 16:07:15 <@adamwill:fedora.im> Why are we here?
2025-09-22 16:07:15 <@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-22 16:07:15 <@adamwill:fedora.im> !info We'll be following the process outlined at:
2025-09-22 16:07:15 <@adamwill:fedora.im> !info The criteria for release blocking bugs can be found at:
2025-09-22 16:07:15 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Basic_Release_Criteria
2025-09-22 16:07:15 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Fedora_43_Beta_Release_Criteria
2025-09-22 16:07:15 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria
2025-09-22 16:07:15 <@adamwill:fedora.im> !link http://qa.fedoraproject.org/blockerbugs/current
2025-09-22 16:07:15 <@adamwill:fedora.im> !link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
2025-09-22 16:07:45 <@adamwill:fedora.im> !info for Fedora 43 Final, we have: 10 proposed blockers and 2 proposed freeze exceptions (I'll cut that down a bit as we go)
2025-09-22 16:07:57 <@adamwill:fedora.im> lruzicka can't make the meeting but said he will secretarialize
2025-09-22 16:08:02 <@adamwill:fedora.im> !info lruzicka will secretarialize later
2025-09-22 16:08:12 <@adamwill:fedora.im> let's get started with:
2025-09-22 16:08:17 <@adamwill:fedora.im> !topic Proposed Final blockers
2025-09-22 16:08:33 <@adamwill:fedora.im> !topic (2397086) Drop-down menus not working over RDP in Anaconda
2025-09-22 16:08:33 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2397086
2025-09-22 16:08:33 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1943
2025-09-22 16:08:33 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+5,0,-0) (+boniboyblue, +kparal, +lruzicka, +derekenz, +geraldosimiao)
2025-09-22 16:08:33 <@adamwill:fedora.im> !info Proposed Blocker, anaconda, NEW
2025-09-22 16:09:00 <@adamwill:fedora.im> so this one has +5, but...i felt like it could use a bit of discussion. it is *possible* to complete an install over RDP; just don't open any dropdown menus. ;) openQA has an RDP install test that does this
2025-09-22 16:09:02 <@kparal:matrix.org> it happens on F42 as well, I just tested it
2025-09-22 16:09:14 <@adamwill:fedora.im> i think it's supportable to vote it as a conditional blocker on the condition that you need to open a dropdown menu, though...
2025-09-22 16:09:18 <@adamwill:fedora.im> yeah, that angle too
2025-09-22 16:09:27 <@kparal:matrix.org> it will be very hard to not use dropdowns in blivet-gui
2025-09-22 16:09:39 <@adamwill:fedora.im> this is why we shouldn't have two freaking custom partitioning UIs
2025-09-22 16:09:40 <@adamwill:fedora.im> sigh
2025-09-22 16:09:55 <@kparal:matrix.org> I'm sure there are some dropdown in custom as well
2025-09-22 16:10:02 <@kparal:matrix.org> I'm sure there are some dropdowns in custom as well
2025-09-22 16:10:10 <@kparal:matrix.org> I just didn't look
2025-09-22 16:11:51 <@adamwill:fedora.im> oh i'm sure you can find them anywhere, kamil :D
2025-09-22 16:12:19 <@kparal:matrix.org> there are everywhere in Custom 😉 
2025-09-22 16:12:42 <@conan_kudo:matrix.org> !hi
2025-09-22 16:12:43 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2025-09-22 16:12:46 <@pboy:fedora.im> A good remote installation capability is quite important for Server in some data centers.
2025-09-22 16:12:51 <@kashyapc:fedora.im> adamw: Are you really "against" custom partitioning UIs? :)  Maybe you just say it out of annoyance.
2025-09-22 16:12:55 <@kparal:matrix.org> I think the only possible excuse to reject this is to claim that nobody yelled hard since F42, so it's very niche
2025-09-22 16:13:46 <@nielsenb:fedora.im> That's the only justifications I can come up with
2025-09-22 16:13:51 <@nielsenb:fedora.im> Feels pretty open and shut otherwise
2025-09-22 16:13:55 <@conan_kudo:matrix.org> I don't think it's a very good justification
2025-09-22 16:14:09 <@pboy:fedora.im> Well, in F42 we had no rdp at all for Server, due to a missunderstanding with Anal´conda team. We yelled out loadly!
2025-09-22 16:14:14 <@conan_kudo:matrix.org> the RDP stuff landed halfway through F42 development
2025-09-22 16:14:19 <@kparal:matrix.org> I didn't say it was good justification, I'm not convinced myself
2025-09-22 16:14:29 <@conan_kudo:matrix.org> so I don't think reasonable testing was even possible
2025-09-22 16:14:43 <@geraldosimiao:matrix.org> !hi
2025-09-22 16:14:44 <@zodbot:fedora.im> Geraldo S. Simião Kutz (geraldosimiao) - he / him / his
2025-09-22 16:14:57 <@adamwill:fedora.im> i'm not opposed to accepting it, just wanted to have the discussion
2025-09-22 16:15:15 <@conan_kudo:matrix.org> I think it should be accepted
2025-09-22 16:16:10 <@adamwill:fedora.im> proposed !agreed 2397086 - AcceptedBlocker (Final) - this is accepted as a conditional violation of Basic criterion "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and RDP installation interfaces.". while it's technically possible to complete an install, this makes it hard if you need for any reason to use any dropdown menu (in gtkui), which is pretty common, and we agree that's common enough to constitute a blocker
2025-09-22 16:16:14 <@conan_kudo:matrix.org> ack
2025-09-22 16:16:19 <@derekenz:fedora.im> ack
2025-09-22 16:16:19 <@geraldosimiao:matrix.org> ack
2025-09-22 16:16:22 <@nielsenb:fedora.im> ack
2025-09-22 16:16:24 <@kparal:matrix.org> ack
2025-09-22 16:16:28 <@boniboyblue:fedora.im> ack
2025-09-22 16:16:30 <@pboy:fedora.im> ack
2025-09-22 16:17:15 <@adamwill:fedora.im> !agreed 2397086 - AcceptedBlocker (Final) - this is accepted as a conditional violation of Basic criterion "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and RDP installation interfaces.". while it's technically possible to complete an install, this makes it hard if you need for any reason to use any dropdown menu (in gtkui), which is pretty common, and we agree that's common enough to constitute a blocker
2025-09-22 16:17:26 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1938
2025-09-22 16:17:26 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+5,1,-0) (+chrismurphy, +nielsenb, +boniboyblue, +lruzicka, +derekenz, kparal)
2025-09-22 16:17:26 <@adamwill:fedora.im> !info Proposed Blocker, anaconda-webui, POST
2025-09-22 16:17:26 <@adamwill:fedora.im> !topic (2396646) The web UI doesn't warn users when reusing a /home partition on an encrypted disk.
2025-09-22 16:17:26 <@adamwill:fedora.im> !info Ticket vote: FinalFreezeException (+3,0,-0) (+geraldosimiao, +nielsenb, +kparal)
2025-09-22 16:17:26 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2396646
2025-09-22 16:17:33 <@adamwill:fedora.im> this one has +3, but i'm not sure all voters entirely understood the nuance here
2025-09-22 16:18:04 <@kparal:matrix.org> the use case is pretty niche, but the cockpit UI makes it quite easy to set up, so... shrug
2025-09-22 16:18:24 <@kparal:matrix.org> it's actually quite easy to created a filesystem directly on the whole disk by accident 🙂 
2025-09-22 16:18:30 <@kparal:matrix.org> it's actually quite easy to create a filesystem directly on the whole disk by accident 🙂 
2025-09-22 16:18:34 <@adamwill:fedora.im> it's not about a disk with a single partition, it's about a disk with *no partitions at all*, just a filesystem directly on the disk. which is a thing you can do, but it's a bit niche. we care about it *somewhat* more these days because the cockpit storage UI used in webui lets you do this, whereas it's more or less impossible (I think) to do this in blivet-gui / gtkui custom partitioning
2025-09-22 16:18:55 <@adamwill:fedora.im> maybe we should actually talk to cockpit storage folks about making it less easy to do this
2025-09-22 16:19:19 <@kparal:matrix.org> yes, that would make a better UI, I believe
2025-09-22 16:19:21 <@nielsenb:fedora.im> Isn't it about a disk that's FDE?
2025-09-22 16:19:26 <@adamwill:fedora.im> yes, but not only that
2025-09-22 16:19:43 <@adamwill:fedora.im> if you set up "FDE" with blivet (gtkui) you'll still get a disk with partitions
2025-09-22 16:20:03 <@nielsenb:fedora.im> Does it fail in the case where you don't use partitions, but also don't use FDE?
2025-09-22 16:20:13 <@kparal:matrix.org> for the use case of full disk encryption, it actually makes more sense to ignore partitions. As long as you really want a full disk encrypted (and then use e.g. LVM on top of it)
2025-09-22 16:20:22 <@adamwill:fedora.im> well no, because there's only an issue if there's encryption
2025-09-22 16:20:32 <@kparal:matrix.org> I believe that wouldn't trigger the bug
2025-09-22 16:20:33 <@adamwill:fedora.im> the issue is that, to actually reuse the partition, the installer needs to decrypt it
2025-09-22 16:20:54 <@adamwill:fedora.im> the issue is that, to actually reuse the encrypted device, the installer needs to decrypt it
2025-09-22 16:21:42 <@adamwill:fedora.im> so in this specific case, the installer will let you set things up like it will reuse the encrypted-direct-on-disk-filesystem as /home , but it actually doesn't, it leaves that device out of the installed system config and so /home will just be a directory on the root filesystem
2025-09-22 16:22:01 <@pboy:fedora.im> And without a partition is is difficult to recognize is as a useful disk. 
2025-09-22 16:22:33 <@adamwill:fedora.im> blivet is able to deal with this kind of device, i think, it's just a bit not hooked up in the 'notice the device is encrypted and deal with that' pathway i expect
2025-09-22 16:23:05 <@cmurf:fedora.im> That detail went over my head for sure.
2025-09-22 16:23:09 <@conan_kudo:matrix.org> this is more fallout from not having the blivet storage stuff exposed in the web UI
2025-09-22 16:23:30 <@adamwill:fedora.im> i mean, not *really*
2025-09-22 16:24:38 <@adamwill:fedora.im> you could conceivably have produced this config before webui existed...webui just makes it more likely...
2025-09-22 16:25:07 <@pboy:fedora.im> According to bug, there is already an upstream fix.
2025-09-22 16:25:25 <@adamwill:fedora.im> hmm, do we know if gtkui properly handles this state? i guess it's kinda academic
2025-09-22 16:25:38 <@pboy:fedora.im> So its not too bad to make it a blocker
2025-09-22 16:26:49 <@kparal:matrix.org> I'm fine with not making it a blocker. There is no damage and the use case is very very specific.
2025-09-22 16:27:02 <@adamwill:fedora.im> i'm kinda 0 on it, like kamil...you can argue it's within the criteria but it is a bit niche. i suppose it depends exactly how common it is for people to wind up setting things up this way
2025-09-22 16:27:34 <@adamwill:fedora.im> webui is new enough still that we don't really have a feel for how commonly people are winding up in this state, i don't think
2025-09-22 16:27:37 <@kparal:matrix.org> well, if we accept it in webui, and gtk turns out to break with it as well, it should be blocker with gtk as well
2025-09-22 16:27:49 <@cmurf:fedora.im> It's not entirely exotic. 
2025-09-22 16:27:56 <@adamwill:fedora.im> i guess i was thinking if it's broken in both that makes it slightly more +1, but it's a small difference
2025-09-22 16:28:19 <@conan_kudo:matrix.org> it's less exotic now that reusing home is built into the webui
2025-09-22 16:28:39 <@kparal:matrix.org> I can test gtk, but it will take some time
2025-09-22 16:29:00 <@adamwill:fedora.im> not worth it now
2025-09-22 16:29:19 <@adamwill:fedora.im> i guess we can accept it with the current votes for now, but i think kparal and i may repropose it if fixing turns out to be difficult
2025-09-22 16:29:20 <@cmurf:fedora.im> It should depend on bklid figuring out what magica are identifiable in any case, I'm not sure why the lack of GPT or MBR results in confusion 
2025-09-22 16:29:48 <@cmurf:fedora.im> It should depend on bklid figuring out what magics are identifiable in any case, I'm not sure why the lack of GPT or MBR results in confusion 
2025-09-22 16:30:13 <@cmurf:fedora.im> It should depend on bklid figuring out what magics (fs signatures) are identifiable in any case, I'm not sure why the lack of GPT or MBR results in confusion 
2025-09-22 16:30:34 <@jlinton:fedora.im> I've done partitionsless filesystems on 'raw' disk in the past, I think its fairly common for network attached storage which provides a thin provisioning device. One just creates a massive disk and sets it up without a partition table on the host.
2025-09-22 16:31:35 <@adamwill:fedora.im> right, but you *also* need to encrypt it to hit this. and it needs to be a reusable partition (which I think is just /home ?)
2025-09-22 16:31:43 <@adamwill:fedora.im> right, but you *also* need to encrypt it to hit this. and it needs to be a reusable location (which I think is just /home ?)
2025-09-22 16:32:05 <@kparal:matrix.org> I guess any location can be marked as not formatted, except /
2025-09-22 16:32:22 <@adamwill:fedora.im> hmm, okay. i thought the logic was the other way around (it makes you reformat everything except /home )
2025-09-22 16:32:49 <@nielsenb:fedora.im> I think it depends on if you use the reuse home option, or custom option
2025-09-22 16:32:49 <@kparal:matrix.org> I would have to check, but my memory suggests otherwise
2025-09-22 16:33:14 <@kparal:matrix.org> custom mount point assignment needs to be used for this, I believe. At least I used it
2025-09-22 16:33:30 <@supakeen:fedora.im> !hi
2025-09-22 16:33:31 <@zodbot:fedora.im> Simon de Vlieger (supakeen) - he / him / his
2025-09-22 16:33:35 <@adamwill:fedora.im> hi simon
2025-09-22 16:33:36 <@supakeen:fedora.im> Apologies, I had the wrong time in my agenda.
2025-09-22 16:34:09 <@adamwill:fedora.im> the fix has been merged, so we *could* just punt this and hope it's gone next week. :D
2025-09-22 16:34:18 <@cmurf:fedora.im> I thought webui no longer requires reformat of `/`
2025-09-22 16:34:28 <@conan_kudo:matrix.org> it does not
2025-09-22 16:34:34 <@cmurf:fedora.im> It'll just delete everything 
2025-09-22 16:34:44 <@conan_kudo:matrix.org> it blows away subvolumes
2025-09-22 16:34:49 <@conan_kudo:matrix.org> and recreates them
2025-09-22 16:35:07 <@conan_kudo:matrix.org> for non-btrfs, I think it still reformats
2025-09-22 16:35:35 <@cmurf:fedora.im> Guess I'll need to poke it with a stick
2025-09-22 16:36:07 <@boniboyblue:fedora.im> I'm still +1 but happy to punt for another week.
2025-09-22 16:37:42 <@cmurf:fedora.im> It really should not delete subvolumes without explicit user endorsement 
2025-09-22 16:37:42 <@adamwill:fedora.im> cmurf Brandon Nielsen Derek Enz are you still +1?
2025-09-22 16:37:53 <@derekenz:fedora.im> Still +1
2025-09-22 16:37:58 <@derekenz:fedora.im> Punt is fine
2025-09-22 16:38:09 <@adamwill:fedora.im> if you're all +1, we're going accept, which is totally fine
2025-09-22 16:38:10 <@nielsenb:fedora.im> I would be willing to punt
2025-09-22 16:38:10 <@cmurf:fedora.im> I'm +1 unless it turns out it's difficult to fix
2025-09-22 16:38:11 <@adamwill:fedora.im> just want it to be clear
2025-09-22 16:38:12 <@geraldosimiao:matrix.org> I'm +1 on that, seeing all the arguments here
2025-09-22 16:38:19 <@adamwill:fedora.im> ok, then we have the votes
2025-09-22 16:38:22 <@nielsenb:fedora.im> I don't think I misunderstood anything, so I remain +1, but would be willing to punt
2025-09-22 16:38:24 <@geraldosimiao:matrix.org> but if you all wanna punt, ok
2025-09-22 16:39:56 <@adamwill:fedora.im> proposed !agreed 2396646 - AcceptedBlocker (Final) - this is accepted as a violation of "the installer must be able to: ... Assign mount points to existing storage volumes", noting the "Re-using /home" footnote below, in the specific case that the /home to be reused is both encrypted and a direct-on-disk filesystem (not a partition). this is a fairly uncommon case but we decided it was potentially common enough (given the webui's ability to create such a layout) that we should block on it
2025-09-22 16:40:04 <@derekenz:fedora.im> ack
2025-09-22 16:40:09 <@geraldosimiao:matrix.org> ack
2025-09-22 16:40:22 <@boniboyblue:fedora.im> ack
2025-09-22 16:40:25 <@supakeen:fedora.im> ack
2025-09-22 16:40:32 <@adamwill:fedora.im> !agreed 2396646 - AcceptedBlocker (Final) - this is accepted as a violation of "the installer must be able to: ... Assign mount points to existing storage volumes", noting the "Re-using /home" footnote below, in the specific case that the /home to be reused is both encrypted and a direct-on-disk filesystem (not a partition). this is a fairly uncommon case but we decided it was potentially common enough (given the webui's ability to create such a layout) that we should block on it
2025-09-22 16:40:42 <@adamwill:fedora.im> !info Ticket vote: FinalFreezeException (+3,0,-0) (+kparal, +lruzicka, +geraldosimiao)
2025-09-22 16:40:42 <@adamwill:fedora.im> !info Proposed Blocker, authselect, ASSIGNED
2025-09-22 16:40:42 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1936
2025-09-22 16:40:42 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2396016
2025-09-22 16:40:42 <@adamwill:fedora.im> !topic (2396016) Authselect doesn't regenerate new profile with pam_lastlog2 support in Fedora Silverblue 43
2025-09-22 16:40:42 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+0,0,-6) (-boniboyblue, -nielsenb, -kparal, -lruzicka, -catanzaro, -geraldosimiao)
2025-09-22 16:41:11 <@adamwill:fedora.im> so this has -6 ticket votes but I left it on the list because all the -1s seem to be on the assumption it's silverblue-only, but a comment on the bug mentions workstation
2025-09-22 16:41:14 <@adamwill:fedora.im> i figured we should dig into that a bit
2025-09-22 16:41:36 <@adamwill:fedora.im> https://bugzilla.redhat.com/show_bug.cgi?id=2396016#c3 - "I'm already on F43 workstation (non-silverblue) and editing /etc/pam.d/postlogin-ac does not help - gdm doesn't show a gui."
2025-09-22 16:42:05 <@adamwill:fedora.im> still, i think this can't be a general 'upgrade workstation and everything go boom' situation or we'd be seeing a lot more yelling (and failed openqa tests)
2025-09-22 16:42:19 <@adamwill:fedora.im> anyone up to speed on the details here?
2025-09-22 16:42:55 <@kparal:matrix.org> I'm not
2025-09-22 16:44:39 <@adamwill:fedora.im> we can still reject it on the grounds "we're pretty sure it's not affecting a clean upgrade from N-2", i guess
2025-09-22 16:44:54 <@nielsenb:fedora.im> Yeah, I haven't seen it
2025-09-22 16:45:35 <@kparal:matrix.org> we can do that, or punt
2025-09-22 16:46:04 <@aggraxis:fedora.im> You know, I haven't done much upgrade testing. Just fresh installs. That's pretty wild.
2025-09-22 16:46:10 <@adamwill:fedora.im> ok, if nobody here is an expert on this thing, let's go with 'reject for now'
2025-09-22 16:46:13 <@kashyapc:fedora.im> I'm not up on the details, but if we're "pretty sure" that an upgrade from F41 doesn't affect it, "rejecting makes sense"
2025-09-22 16:46:20 <@kashyapc:fedora.im> I'm not up on the details, but if we're "pretty sure" that an upgrade from F41 doesn't affect it, "rejecting" makes sense.
2025-09-22 16:47:05 <@geraldosimiao:matrix.org> Punt +1
2025-09-22 16:47:20 <@adamwill:fedora.im> proposed !agreed 2396016 - RejectedBlocker (Final) - so far we think it's pretty clear this doesn't meet the criteria ("For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed.") We're not sure the issue is restricted to Silverblue, but openQA testing at least indicates it's not affecting a clean F41 -> F43 upgrade
2025-09-22 16:47:28 <@adamwill:fedora.im> but if people really want to punt, we can pivot..
2025-09-22 16:47:50 <@geraldosimiao:matrix.org> It seems we need investigate a little more
2025-09-22 16:47:56 <@kparal:matrix.org> ack
2025-09-22 16:47:58 <@adamwill:fedora.im> https://openqa.fedoraproject.org/tests/3787282 is the openQA F41 -> F43 upgrade test, if anyone wants receipts
2025-09-22 16:48:10 <@supakeen:fedora.im> i'm ack with that
2025-09-22 16:50:43 <@boniboyblue:fedora.im> ack
2025-09-22 16:51:41 <@adamwill:fedora.im> !agreed 2396016 - RejectedBlocker (Final) - so far we think it's pretty clear this doesn't meet the criteria ("For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed.") We're not sure the issue is restricted to Silverblue, but openQA testing at least indicates it's not affecting a clean F41 -> F43 upgrade
2025-09-22 16:51:50 <@adamwill:fedora.im> !info Proposed Blocker, distribution, NEW
2025-09-22 16:51:50 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1941
2025-09-22 16:51:50 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2397163
2025-09-22 16:51:50 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+5,0,-1) (+leigh123linux, +catanzaro, +imsedgar, +nielsenb, +lruzicka, -kevin)
2025-09-22 16:51:50 <@adamwill:fedora.im> !topic (2397163) openh264 repository issues (like geoblocking) prevent various package management operations
2025-09-22 16:52:07 <@adamwill:fedora.im> this technically has +4, but i'm bringing it up because nirik was -1 and i think we should let him argue the case
2025-09-22 16:52:26 <@adamwill:fedora.im> if he's here...
2025-09-22 16:53:01 <@nirik:matrix.scrye.com> I just added my case to the bug
2025-09-22 16:53:11 <@kparal:matrix.org> honestly this feels more political than technical decision to me, and I wonder whether I'm the right person voting for it
2025-09-22 16:53:16 <@supakeen:fedora.im> Is it possible for users to work around this in the more general case?
2025-09-22 16:53:23 <@adamwill:fedora.im> to me the clear bug is "packages are geoblocked but metadata isn't"
2025-09-22 16:53:26 <@supakeen:fedora.im> E.g. by changing from the metalink to a specific mirror in their region?
2025-09-22 16:53:30 <@kashyapc:fedora.im> Yeah, I agree with Kevin's rationale with Infra Hat on. If he says it's "not worth it for everyone else", I'd go with it, FWIW.
2025-09-22 16:53:32 <@derekenz:fedora.im> This is more of a Cisco issue?
2025-09-22 16:53:38 <@kashyapc:fedora.im> Yeah, I agree with Kevin's rationale with his Infra Hat on. If he says it's "not worth it for everyone else", I'd go with it, FWIW.
2025-09-22 16:53:44 <@adamwill:fedora.im> regardless of political feelings about who should be blocked and who shouldn't, i think everyone can agree that the block should be consistent, right?
2025-09-22 16:53:45 <@supakeen:fedora.im> So librepo doesn't end up pulling repomd.xml from one mirror and files from another (I think that's what's going on?).
2025-09-22 16:53:50 <@nirik:matrix.scrye.com> also, if we disable it, don't we break all upgrades?
2025-09-22 16:54:04 <@kparal:matrix.org> if metadata become geoblocked, does it fix the use case? can users update their systems?
2025-09-22 16:54:38 <@decathorpe:fedora.im> as far as I can tell, yes
2025-09-22 16:54:42 <@nirik:matrix.scrye.com> it would, but we don't know exactly what cisco has blocked... and if we start blocking more... that might mean we block those regions entirely.
2025-09-22 16:55:00 <@adamwill:fedora.im> unfortunately we can't block on 'cisco, fix your crap'
2025-09-22 16:55:10 <@nielsenb:fedora.im> Which is why it should be behind the third party flag, but that's a discussion for elsewhere I guess...
2025-09-22 16:55:11 <@derekenz:fedora.im> We are required by US Law to block some regions of Ukraine but we are not required to block all of Ukraine. We were updating the way we distribute this software and we unintentionally blocked all of Ukraine.
2025-09-22 16:55:19 <@derekenz:fedora.im> From Cisco it seems
2025-09-22 16:55:26 <@kparal:matrix.org> also worth noting is that users are already affected on F41 and F42
2025-09-22 16:55:52 <@nirik:matrix.scrye.com> IANAL, and none of you are my lawyer, so we should try and avoid speculating as to what we think we should or shouldn't do. :)
2025-09-22 16:55:56 <@adamwill:fedora.im> true, but the 'noopenh264 to openh264' switcheroo is kind of a 'usually happens once at first update' thing, right?
2025-09-22 16:56:11 <@adamwill:fedora.im> nirik I think Derek is quoting Cisco there
2025-09-22 16:56:19 <@adamwill:fedora.im> what's the source, derek?
2025-09-22 16:56:26 <@derekenz:fedora.im> YES
2025-09-22 16:56:27 <@nirik:matrix.scrye.com> ah, could be.
2025-09-22 16:56:30 <@nielsenb:fedora.im> Yes, though I noticed on my laptop it switched back against my wishes somehow
2025-09-22 16:56:30 <@decathorpe:fedora.im> at first update, yes, or ... it has already happened on F41 or F42, and is blocking upgrades now.
2025-09-22 16:56:41 <@kparal:matrix.org> I tried, and you can't switch back from openh264 to noopenh264. And some core system packages depend on openh264, so you can't remove it either.
2025-09-22 16:56:43 <@decathorpe:fedora.im> (because of an soname bump in F43+)
2025-09-22 16:57:08 <@adamwill:fedora.im> i move that this bug sucks and i hate it
2025-09-22 16:57:12 <@nirik:matrix.scrye.com> so disabling this repo on our end would mean new installs would work, but break all the upgrading users. ;(
2025-09-22 16:57:20 <@decathorpe:fedora.im> yup
2025-09-22 16:57:34 <@decathorpe:fedora.im> unless Obsoletes are added to noopenh264 that remove openh264 on upgrade.
2025-09-22 16:57:43 <@adamwill:fedora.im> i think i kinda agree with nirik that i'm not sure any change fedora can make here would make things, overall, *better*
2025-09-22 16:57:45 <@nirik:matrix.scrye.com> yeah, see my note on the bug...
2025-09-22 16:58:16 <@nirik:matrix.scrye.com> I also think it sucks and is bad... but I don't think disabling is the answer.
2025-09-22 16:58:19 <@kashyapc:fedora.im> Ugh, looks like we have to choose the "least worst of the available options"
2025-09-22 16:58:22 <@nielsenb:fedora.im> Not better now, but better in the future, if Fedora doesn't distribute it, it's 3rd party dangit
2025-09-22 16:58:35 <@nirik:matrix.scrye.com> we don't distribute it. ;)
2025-09-22 16:58:50 <@geraldosimiao:matrix.org> but if we introduce a noopenh264-compat? just for fallback sake? (I know it is too late )
2025-09-22 16:58:55 <@nielsenb:fedora.im> Right, so why is it not counted as a 3rd party repo?
2025-09-22 16:59:13 <@decathorpe:fedora.im> (FWIW I only acted as the messenger when I proposed it as a blocker bug, I don't personally think disabling the repo is a good solution - but neither is keeping it enabled :( )
2025-09-22 16:59:20 <@nirik:matrix.scrye.com> because we built in, we signed it, it's ours, cisco is just distributing it for us.
2025-09-22 16:59:21 <@nielsenb:fedora.im> Which isn't the bug here, but this has made me angry since it was introduced
2025-09-22 16:59:39 <@nirik:matrix.scrye.com> would things distributed by mirrors be 3rd party? ;)
2025-09-22 17:00:36 <@adamwill:fedora.im> technically, remember, what we're deciding here is "is this a blocker bug?", not "should we disable the repo?"
2025-09-22 17:00:36 <@derekenz:fedora.im> For licensing issues correct?
2025-09-22 17:00:43 <@adamwill:fedora.im> the blocker decision does not and cannot dictate solutions
2025-09-22 17:00:58 <@adamwill:fedora.im> the question is "based on the release criteria, is this bug a sufficient reason not to release fedora 43"
2025-09-22 17:01:18 <@adamwill:fedora.im> in this case I'd say it's relevant to consider the question of how the same issue is affecting f41 and f42, as well
2025-09-22 17:01:22 <@nielsenb:fedora.im> They would if Fedora couldn't distribute the content themselves
2025-09-22 17:01:30 <@geraldosimiao:matrix.org> well, for now I'm still blocker -1
2025-09-22 17:01:52 <@nielsenb:fedora.im> Yeah, I sorta forgot it's borked for that too, so I kinda feel like blocking doesn't fix anything now
2025-09-22 17:02:13 <@nirik:matrix.scrye.com> for patent issues.
2025-09-22 17:02:31 <@adamwill:fedora.im> do we know what the experience is for an existing f42 system that's already done the openh264 switcheroo and just wants to install regular updates? is that broken?
2025-09-22 17:02:40 <@nirik:matrix.scrye.com> no
2025-09-22 17:02:46 <@adamwill:fedora.im> do we know what the experience is for an existing f42 system that's already done the openh264 switcheroo and just wants to install regular updates (*not* upgrade to f43)? is that broken?
2025-09-22 17:02:57 <@nirik:matrix.scrye.com> they can get the metadata fine, there's no updates in the transaction, all works
2025-09-22 17:03:06 <@nirik:matrix.scrye.com> if we did update it tho, they would hit the issue
2025-09-22 17:03:07 <@adamwill:fedora.im> ok, so, let me see if this is right:
2025-09-22 17:03:15 <@kparal:matrix.org> I saw some reports that it prevents users from doing a system update
2025-09-22 17:03:47 <@derekenz:fedora.im> F42 or F43?
2025-09-22 17:03:49 <@adamwill:fedora.im> 2. fresh f41/f42 install - would probably have problems
2025-09-22 17:03:49 <@adamwill:fedora.im> 1. existing f41/f42 install - things are OK so long as we don't update openh264
2025-09-22 17:03:49 <@adamwill:fedora.im> 3. upgrade from f41/f42 to f43 - will fail
2025-09-22 17:03:49 <@kashyapc:fedora.im> So it prevents classic `dnf update` on F42?
2025-09-22 17:03:53 <@nirik:matrix.scrye.com> only I think if they haven't done the initial switch.
2025-09-22 17:04:04 <@decathorpe:fedora.im> it breaks as soon as there is a newer version of openh264 in the repos than what the user has installed. so both updates on F42 and upgrades from F41 or F42 to F43 would be affected.
2025-09-22 17:04:13 <@kparal:matrix.org> well, I guess it makes sense that it should affect them only if they haven't done the switch
2025-09-22 17:04:20 <@kparal:matrix.org> otherwise I don't know why they would be blocked
2025-09-22 17:04:35 <@nirik:matrix.scrye.com> adamw: I think yes, but note that all this is limited to those regions cisco is blocking only. Everyone else is fine
2025-09-22 17:04:46 <@decathorpe:fedora.im> so ... what Adam said. things look like they're arriving out of order for me 😬
2025-09-22 17:04:56 <@adamwill:fedora.im> nirik sure.
2025-09-22 17:05:13 <@adamwill:fedora.im> do we have any indication that anywhere outside of ukraine is in the broken state?
2025-09-22 17:06:22 <@supakeen:fedora.im> Bit hard to tell, but more than Ukraine is blocked I'd assume.
2025-09-22 17:06:42 <@supakeen:fedora.im> It's specifically about regions that were unblocked during F42 and are blocked *now* right?
2025-09-22 17:06:43 <@boniboyblue:fedora.im> Serbia was another one mentioned on the Fedora Discord.
2025-09-22 17:06:49 <@kparal:matrix.org> https://discussion.fedoraproject.org/t/161434/8
2025-09-22 17:07:02 <@kparal:matrix.org> the check-host.net link is still resolving for me
2025-09-22 17:07:09 <@kparal:matrix.org> but it says Ukraine and Russia
2025-09-22 17:07:15 <@adamwill:fedora.im> ah, found https://github.com/cisco/openh264/issues/3886#issuecomment-3140896204 is the source of the text derek quoted earlier
2025-09-22 17:07:43 <@adamwill:fedora.im> Simon de Vlieger remember it's not just 'where is blocked', the question is 'where are the packages blocked but the metadata not blocked'
2025-09-22 17:08:05 <@supakeen:fedora.im> Right, sorry, I asked before if in the case of librepo it's possible that it pulls repomd.xml from a different mirror than the packages?
2025-09-22 17:08:12 <@adamwill:fedora.im> if both are blocked, things are working as intended, aside from the political questions which we aren't going to resolve here
2025-09-22 17:08:26 <@adamwill:fedora.im> Simon de Vlieger generally speaking yes, but i don't believe the cisco repo works that way
2025-09-22 17:08:28 <@kparal:matrix.org> more reports of Russia are in the upstream cisco ticket
2025-09-22 17:08:43 <@kparal:matrix.org> but there are also claims that Russia is in the sanctions list and that it's expected
2025-09-22 17:09:03 <@kparal:matrix.org> can't verify that claim, I tried to look at the lists and it's not an easy read, so...
2025-09-22 17:09:32 <@adamwill:fedora.im> yeah, there is only *one* URL for the cisco repo in the metalink
2025-09-22 17:09:40 <@adamwill:fedora.im> so it should always try to get the metadata from there, aiui
2025-09-22 17:09:56 <@adamwill:fedora.im> ```
2025-09-22 17:09:56 <@adamwill:fedora.im>     <url protocol="https" type="https" location="US" preference="100">https://codecs.fedoraproject.org/openh264/43/x86_64/repodata/repomd.xml</url>
2025-09-22 17:09:56 <@adamwill:fedora.im> ```
2025-09-22 17:09:56 <@adamwill:fedora.im>    </resources>
2025-09-22 17:09:56 <@adamwill:fedora.im>    <resources maxconnections="1">
2025-09-22 17:10:28 <@supakeen:fedora.im> Yea, that makes sense. Ok then there's just nothing we can really do about it no matter how much it sucks. We can only suggest users perform a clean install instead of update for those affected?
2025-09-22 17:10:33 <@adamwill:fedora.im> nirik is it correct to say that fedora/rh decides what's geoblocked for that URL (the metadata), but cisco controls what's blocked for the packages (which are in AWS apparently), and the task here is keeping those definitions synced?
2025-09-22 17:10:58 <@kparal:matrix.org> I'm sure I can come up with a workaround for existing F41 and F42 users
2025-09-22 17:10:59 <@adamwill:fedora.im> no, clean install won't help.
2025-09-22 17:11:09 <@kparal:matrix.org> to swap openh264 to noopenh264
2025-09-22 17:11:32 <@kparal:matrix.org> but then we have to exclude openh264 permanently from transactions, that might also be doable
2025-09-22 17:11:36 <@nirik:matrix.scrye.com> adamw: yes
2025-09-22 17:11:52 <@nirik:matrix.scrye.com> well, ideally yes...
2025-09-22 17:11:57 <@conan_kudo:matrix.org> Yes
2025-09-22 17:13:32 <@kparal:matrix.org> so I would suggest to come up and document the workaround, and don't block on this, I don't think it's in the interest of majority of users, and all current "solutions" suck anyway. Hopefully things get improved during the F43 lifecycle.
2025-09-22 17:13:51 <@adamwill:fedora.im> well, i was trying to reason towards 'what is the impact of releasing f43'
2025-09-22 17:14:06 <@adamwill:fedora.im> i can see two things that would do specifically:
2025-09-22 17:14:32 <@adamwill:fedora.im> 1) there would be the usual flood of people wanting to upgrade to the new stable release, and for those in affected locations, it would fail
2025-09-22 17:15:11 <@adamwill:fedora.im> 2. there would probably be a smaller flood of people in affected locations wanting to do a fresh install of the new release who would not *otherwise* have done a fresh install of f42 instead, and they will see problems
2025-09-22 17:15:32 <@adamwill:fedora.im> if we *don't* release f43, we avoid those problems. at the cost of, you know, all the other costs of not releasing
2025-09-22 17:15:41 <@adamwill:fedora.im> that's the basis on which we have to make the blocker determination, i think.
2025-09-22 17:15:55 <@nielsenb:fedora.im> Patent expiration would be best
2025-09-22 17:16:11 <@adamwill:fedora.im> we block until everyone agrees the patents have expired! i like it
2025-09-22 17:16:46 <@nielsenb:fedora.im> That's a plan I can get behind
2025-09-22 17:17:10 <@adamwill:fedora.im> https://github.com/cisco/openh264/issues/3886#issuecomment-3271407996 seems to be the latest update from cisco, btw
2025-09-22 17:17:12 <@nirik:matrix.scrye.com> no more releases! hurray!
2025-09-22 17:17:26 <@nielsenb:fedora.im> Do we agree there's any actual bug in Fedora software?
2025-09-22 17:17:34 <@nielsenb:fedora.im> If not, I'm not really sure it's appropriate to block
2025-09-22 17:17:40 <@adamwill:fedora.im> based on the above...i think i'm -1 blocker, i just don't see the tradeoff on this one, though it does suck for affected folks
2025-09-22 17:18:00 <@kparal:matrix.org> also Cisco is actively trying to fix this on their side
2025-09-22 17:18:04 <@adamwill:fedora.im> Brandon Nielsen the 'bug' is "fedora's geoblock list for the metadata doesn't match cisco's geoblock list for the packages"
2025-09-22 17:18:34 <@nielsenb:fedora.im> Yeah, so there really is no good way out of this
2025-09-22 17:18:40 <@nielsenb:fedora.im> FinalBlocker -1
2025-09-22 17:19:10 <@kashyapc:fedora.im> Yeah, not much to do than to keep an eye on the upstream ticket until the next meet?
2025-09-22 17:19:16 <@supakeen:fedora.im> -1 on blocker but it *might* be nice to write this down as an ongoing issue.
2025-09-22 17:19:46 <@supakeen:fedora.im> (I don't know where, some status page perhaps?)
2025-09-22 17:20:03 <@kparal:matrix.org> I'll try to come up with some common bugs workaround
2025-09-22 17:20:22 <@derekenz:fedora.im> FinalBlocker -1
2025-09-22 17:20:46 <@geraldosimiao:matrix.org> FinalBlocker -1
2025-09-22 17:21:53 <@boniboyblue:fedora.im> FB -1
2025-09-22 17:22:48 <@adamwill:fedora.im> proposed !agreed 2397163 - RejectedBlocker (Final) - we agree this is a very awkward state for folks in affected locations, but as there is no entirely Fedora-controlled "fix" possible and the issue is not entirely limited to Fedora 43, we agreed it doesn't make sense to block on it. we will wait on cisco to complete the process of refining their geoblock, then see where we stand and if we need to consider any changes on the fedora side
2025-09-22 17:22:54 <@derekenz:fedora.im> ack
2025-09-22 17:23:04 <@kparal:matrix.org> ack
2025-09-22 17:23:10 <@supakeen:fedora.im> ack
2025-09-22 17:23:10 <@decathorpe:fedora.im> ack
2025-09-22 17:23:23 <@nielsenb:fedora.im> ack
2025-09-22 17:23:53 <@kparal:matrix.org> ack
2025-09-22 17:24:08 <@kparal:matrix.org> it seems I have a short memory
2025-09-22 17:24:23 <@kashyapc:fedora.im> Not just you
2025-09-22 17:24:36 <@cmurf:fedora.im> Mine is shorter 
2025-09-22 17:24:37 <@derekenz:fedora.im> Glad Im not alone
2025-09-22 17:24:57 <@boniboyblue:fedora.im> ack
2025-09-22 17:25:29 <@adamwill:fedora.im> !agreed 2397163 - RejectedBlocker (Final) - we agree this is a very awkward state for folks in affected locations, but as there is no entirely Fedora-controlled "fix" possible and the issue is not entirely limited to Fedora 43, we agreed it doesn't make sense to block on it. we will wait on cisco to complete the process of refining their geoblock, then see where we stand and if we need to consider any changes on the fedora side
2025-09-22 17:25:50 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+3,0,-0) (+kparal, +lruzicka, +derekenz)
2025-09-22 17:25:50 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1944
2025-09-22 17:25:50 <@adamwill:fedora.im> !info Proposed Blocker, gnome-shell, POST
2025-09-22 17:25:50 <@adamwill:fedora.im> !topic (2397256) gnome-shell crashes when dragging a Chromium tab into a new window
2025-09-22 17:25:50 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2397256
2025-09-22 17:26:00 <@adamwill:fedora.im> this is right on +3 and i didn't get to it yet, so...let's just take a quick look. :D
2025-09-22 17:26:15 <@kparal:matrix.org> don't try it live now
2025-09-22 17:26:30 <@adamwill:fedora.im> ok, so sure, chromium is not our default browser, but crashing shell is...bad.
2025-09-22 17:26:31 <@supakeen:fedora.im> [adamw has disconnected]
2025-09-22 17:26:32 <@adamwill:fedora.im> it smells +1 to me.
2025-09-22 17:26:46 <@kparal:matrix.org> it also applies to Chrome
2025-09-22 17:26:49 <@adamwill:fedora.im> i don't use chromium, what kind of a person do you take me for
2025-09-22 17:26:59 <@adamwill:fedora.im> firefox all the way, baby. (restarting firefox 20 times a day, baby)
2025-09-22 17:27:51 <@nielsenb:fedora.im> Browsers weren't meant to have tabs, or separate windows tied to the same process.
2025-09-22 17:28:37 <@adamwill:fedora.im> computers were a mistake!
2025-09-22 17:28:42 <@adamwill:fedora.im> fedora 44 for the ibm selectric
2025-09-22 17:29:19 <@adamwill:fedora.im> (dozens of typewriting enthusiasts around the world are struck by a sudden wave of foreboding they cannot explain)
2025-09-22 17:31:35 <@adamwill:fedora.im> any other votes?
2025-09-22 17:32:06 <@nielsenb:fedora.im> I really don't like shell crashes, who knows what else will trigger them, plus Chromium and friends are pretty common
2025-09-22 17:32:13 <@nielsenb:fedora.im> FinalBlocker +1
2025-09-22 17:34:27 <@adamwill:fedora.im> proposed !agreed 2397256 - AcceptedBlocker (Final) - this is accepted as a violation of the cited criterion, counting 'drag tab to create a new window') as a "regular operation" for a browser, and noting that while chromium/chrome is not the default browser in any Fedora edition, they are very widely used so we can expect this bug will be commonly encountered, and the consqeuence is very bad (full desktop crash)
2025-09-22 17:34:30 <@supakeen:fedora.im> ack
2025-09-22 17:34:32 <@derekenz:fedora.im> ack
2025-09-22 17:34:41 <@geraldosimiao:matrix.org> ack
2025-09-22 17:34:43 <@nielsenb:fedora.im> ack
2025-09-22 17:34:50 <@adamwill:fedora.im> !agreed 2397256 - AcceptedBlocker (Final) - this is accepted as a violation of the cited criterion, counting 'drag tab to create a new window') as a "regular operation" for a browser, and noting that while chromium/chrome is not the default browser in any Fedora edition, they are very widely used so we can expect this bug will be commonly encountered, and the consqeuence is very bad (full desktop crash)
2025-09-22 17:35:03 <@adamwill:fedora.im> !info Proposed Blocker, gnome-software, VERIFIED
2025-09-22 17:35:03 <@adamwill:fedora.im> !info Ticket vote: FinalFreezeException (+6,0,-0) (+boniboyblue, +adamwill, +geraldosimiao, +nielsenb, +kparal, +kashyapc)
2025-09-22 17:35:03 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+3,0,-4) (+asciiwolf, +lruzicka, +derekenz, -boniboyblue, -nielsenb, -kparal, -kashyapc)
2025-09-22 17:35:03 <@adamwill:fedora.im> !topic (2395811) libreoffice language packs not found in gnome-software
2025-09-22 17:35:03 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2395811
2025-09-22 17:35:03 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1930
2025-09-22 17:36:07 <@adamwill:fedora.im> ok, so we have +3/-4 here
2025-09-22 17:39:30 <@geraldosimiao:matrix.org> I'm still voting it for just a FE and not a FinalBlock. It's similar to what we do have in the KDE desktop libreoffice behavior. Itas a regression sure, but the fix already landed.
2025-09-22 17:39:51 <@adamwill:fedora.im> yeah, i'm still -1
2025-09-22 17:40:00 <@adamwill:fedora.im> if we can't change enough minds we can punt it and it should go away, anyhow
2025-09-22 17:40:07 <@supakeen:fedora.im> finalblocker -1
2025-09-22 17:40:13 <@adamwill:fedora.im> Derek Enz did the discussion change your mind?
2025-09-22 17:40:17 <@kparal:matrix.org> this feature is not available in KDE at all, IIUIC
2025-09-22 17:40:23 <@kparal:matrix.org> so not sure why it would be a blocker in Gnome
2025-09-22 17:40:33 <@derekenz:fedora.im> FinalBlocker 0
2025-09-22 17:40:36 <@geraldosimiao:matrix.org> yeah, thats my point
2025-09-22 17:41:10 <@adamwill:fedora.im> man, i have sent myself down a wiki wormhole on typewriters now. typewriters were *wild*
2025-09-22 17:41:20 <@adamwill:fedora.im> "To support backspacing over previously typed characters, the spacing code for the last forty or so characters typed was mechanically stored by small sliding plates in a carrier wheel"
2025-09-22 17:41:39 <@supakeen:fedora.im> Yes, and then we taught sand to think and that gets us where we are now.
2025-09-22 17:41:59 <@nielsenb:fedora.im> Even the basic mechanics are pretty wild, see also sewing machines
2025-09-22 17:42:25 <@supakeen:fedora.im> Anyhow with my vote I think it's +3/-5 is that enough for a break or does it need to be punted?
2025-09-22 17:42:37 <@adamwill:fedora.im> derek went to 0
2025-09-22 17:42:43 <@adamwill:fedora.im> so we're +2 / -5, which is rejectable
2025-09-22 17:43:43 <@adamwill:fedora.im> proposed !agreed 2395811 - RejectedBlocker (Final) - this is rejected as, while it's unfortunate, it doesn't obviously break any criteria (and we note it's just the same as the longstanding experience on KDE). It's already accepted as an FE
2025-09-22 17:43:53 <@nielsenb:fedora.im> ack
2025-09-22 17:43:54 <@supakeen:fedora.im> ack
2025-09-22 17:43:56 <@derekenz:fedora.im> ack
2025-09-22 17:44:09 <@adamwill:fedora.im> !agreed 2395811 - RejectedBlocker (Final) - this is rejected as, while it's unfortunate, it doesn't obviously break any criteria (and we note it's just the same as the longstanding experience on KDE). It's already accepted as an FE
2025-09-22 17:44:20 <@adamwill:fedora.im> last one!
2025-09-22 17:44:20 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1937
2025-09-22 17:44:20 <@adamwill:fedora.im> !info Proposed Blocker, uboot-tools, NEW
2025-09-22 17:44:20 <@adamwill:fedora.im> !info Ticket vote: FinalBlocker (+3,0,-0) (+nielsenb, +lruzicka, +derekenz)
2025-09-22 17:44:20 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2396309
2025-09-22 17:44:20 <@adamwill:fedora.im> !topic (2396309) Radxa Rock Pi 4 and Pine64 RockPro64 boards fail to boot, probably all RockChip models
2025-09-22 17:44:27 <@supakeen:fedora.im> So. This one I looked into.
2025-09-22 17:44:36 <@adamwill:fedora.im> thanks for that
2025-09-22 17:44:55 <@supakeen:fedora.im> The boards mentioned there have the ability to have firmware loaded onto the disk image, in the first x megabyte available.
2025-09-22 17:45:04 <@supakeen:fedora.im> Fedora IoT, and Fedora ARM Minimal keep 8 MiB of start offset for this.
2025-09-22 17:45:08 <@supakeen:fedora.im> Kiwi produced images keep 0.
2025-09-22 17:45:22 <@supakeen:fedora.im> ImageFactory produced images ued to keep 2 (as per Peter's comment).
2025-09-22 17:45:41 <@adamwill:fedora.im> iot and arm minimal are built with osbuild, right?
2025-09-22 17:45:52 <@adamwill:fedora.im> Conan Kudo do you agree this needs fixing in kiwi? can you fix it?
2025-09-22 17:45:54 <@supakeen:fedora.im> Correct, osbuild/image-builder have always had this offset.
2025-09-22 17:46:09 <@supakeen:fedora.im> Now arm-image-installer assumes there's enough room at the start of the partition table to plop the firmware there.
2025-09-22 17:46:27 <@adamwill:fedora.im> what did it do before?
2025-09-22 17:46:43 <@supakeen:fedora.im> Sorry, I think it always did that.
2025-09-22 17:47:04 <@supakeen:fedora.im> Anyhow, there neesd to be some offset on the disk images and I'm trying to figure out if it should be 8 MiB or 16 MiB.
2025-09-22 17:47:19 <@adamwill:fedora.im> okay.
2025-09-22 17:47:40 <@adamwill:fedora.im> do we know of any other hw that uses this, or is it rockchip only?
2025-09-22 17:47:46 <@supakeen:fedora.im> AllWinner.
2025-09-22 17:47:54 <@supakeen:fedora.im> But it's firmware is ~1 MiB I believe.
2025-09-22 17:48:24 <@supakeen:fedora.im> Note that there is a workaround for rockchip, and that is to flash the firmware to SPI and then flash with arm-image-installer with --board=none.
2025-09-22 17:49:09 <@adamwill:fedora.im> okay. that sounds kinda hefty, though.
2025-09-22 17:49:19 <@supakeen:fedora.im> It is a lot less friendly.
2025-09-22 17:49:33 <@adamwill:fedora.im> i think i'm fine with +1 here given it was on the previous 'supported hw' list and pboy says it's a significant platform for server
2025-09-22 17:49:42 <@adamwill:fedora.im> just hoping neal knows what to do to fix it
2025-09-22 17:49:46 <@supakeen:fedora.im> +1 finalblocker for me as well
2025-09-22 17:50:20 <@adamwill:fedora.im> oh, wait, hum, we have the 'what images are affected' problem right?
2025-09-22 17:50:39 <@supakeen:fedora.im> All Kiwi produced ARM disk images is my assumption, I spot tested about half of them and none have any offset.
2025-09-22 17:50:58 <@adamwill:fedora.im> technically the release blocking aarch64 disk images are IoT, minimal,Workstation, KDE
2025-09-22 17:51:16 <@adamwill:fedora.im> workstation and KDE are kiwi-produced, I think?
2025-09-22 17:51:21 <@supakeen:fedora.im> They are.
2025-09-22 17:51:26 <@adamwill:fedora.im> ok, we can go with that
2025-09-22 17:52:24 <@adamwill:fedora.im> proposed !agreed 2396309 - AcceptedBlocker (Final) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" on all (we believe) Rockchip SBCs, with the Workstation and KDE aarch64 disk images (which are release-blocking and produced by Kiwi so affected by the bug)
2025-09-22 17:52:31 <@derekenz:fedora.im> ack
2025-09-22 17:52:33 <@supakeen:fedora.im> ack
2025-09-22 17:52:57 <@nielsenb:fedora.im> ack
2025-09-22 17:53:04 <@adamwill:fedora.im> !agreed 2396309 - AcceptedBlocker (Final) - this is accepted as a violation of "All release-blocking images must boot in their supported configurations" on all (we believe) Rockchip SBCs, with the Workstation and KDE aarch64 disk images (which are release-blocking and produced by Kiwi so affected by the bug)
2025-09-22 17:53:14 <@adamwill:fedora.im> and that's all the proposed blockers. whee
2025-09-22 17:53:23 <@supakeen:fedora.im> Thanks all! I have to run for dinner :)
2025-09-22 17:53:26 <@adamwill:fedora.im> !info there are no proposed FEs
2025-09-22 17:53:28 <@adamwill:fedora.im> thanks simon!
2025-09-22 17:53:32 <@adamwill:fedora.im> let's take a quick look through
2025-09-22 17:53:36 <@adamwill:fedora.im> !topic Accepted Final blockers
2025-09-22 17:54:03 <@adamwill:fedora.im> !topic (2360054) Fedora 43: Everything boot x86_64 image exceeds maximum size
2025-09-22 17:54:03 <@adamwill:fedora.im> !info Accepted Blocker, distribution, ASSIGNED
2025-09-22 17:54:03 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1857
2025-09-22 17:54:03 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2360054
2025-09-22 17:54:50 <@adamwill:fedora.im> !info adamw did an investigation at https://bugzilla.redhat.com/show_bug.cgi?id=2360054#c40 . based on that we may be able to get the size under 1.2G. under 1G is unlikely. this applies to the Server x86_64 netinst as well, and likely also mostly applies to the aarch64 Server and Everything images
2025-09-22 17:55:24 <@adamwill:fedora.im> !action adamw to see if he can propose some trims, then likely also propose bumping the limits which are still at 1G to 1.2G
2025-09-22 17:56:46 <@geraldosimiao:matrix.org> the limits could go up to 2G, ltes be honest, its even hard to find a pendrive at this size
2025-09-22 17:56:50 <@kparal:matrix.org> we might also propose to weaken the criterion, but it might be too late 
2025-09-22 17:57:03 <@aggraxis:fedora.im> I'm all about 2G and free tacos.
2025-09-22 17:57:14 <@adamwill:fedora.im> i honestly think it's worth having the criteria so we at least *check* when the size bumps significantly and figure out why
2025-09-22 17:57:17 <@aggraxis:fedora.im> I thought for server, anyhow, we were going to relax a belt quite a bit last go around
2025-09-22 17:57:21 <@adamwill:fedora.im> i'd want to know if/why it went from 1.2 to 1.9
2025-09-22 17:57:24 <@geraldosimiao:matrix.org> tacos night, every night
2025-09-22 17:57:40 <@adamwill:fedora.im> iirc we bumped aarch64 from 1 to 1.2 last time round, or something like that
2025-09-22 17:57:47 <@adamwill:fedora.im> but some of these four images are still at 1 right now
2025-09-22 17:57:49 <@adamwill:fedora.im> brb, call of nature
2025-09-22 17:58:04 <@kparal:matrix.org> it makes sense in certain cases, but when we're trying to trim 3 MB because it's over some arbitrary limit, then it doesn't
2025-09-22 17:58:46 <@aggraxis:fedora.im> I would be more concerned about relative growth of like 15-20% more than looking for pennies in the couch, as it were.
2025-09-22 17:59:12 <@aggraxis:fedora.im> Which maybe this fits that bill, but it's pretty clear it wasn't "oh someone left a bowling ball in the image"
2025-09-22 18:00:40 <@aggraxis:fedora.im> If we're getting hit twice for some of these big firmware issues, that's just going to be unfortunate each time someone stuffs a big firmware in there.
2025-09-22 18:01:25 <@adamwill:fedora.im> bumping the limit by a chunk beyond where it currently is each time effectively achieves that
2025-09-22 18:01:38 <@adamwill:fedora.im> it's not like i'm going to proposed bumping it to 1.0634723G
2025-09-22 18:01:47 <@adamwill:fedora.im> anyhoo
2025-09-22 18:02:52 <@adamwill:fedora.im> we've noted things :D let's go on
2025-09-22 18:02:59 <@adamwill:fedora.im> !info Accepted Blocker, distribution, ASSIGNED
2025-09-22 18:02:59 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1859
2025-09-22 18:02:59 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2360056
2025-09-22 18:02:59 <@adamwill:fedora.im> !topic (2360056) Fedora 43: Workstation live x86_64 image exceeds maximum size
2025-09-22 18:03:26 <@adamwill:fedora.im> !info adamwill also investigated this one, although not in as much detail because...erofs is weird or something? https://bugzilla.redhat.com/show_bug.cgi?id=2360056#c38
2025-09-22 18:06:02 <@adamwill:fedora.im> not much else to say, if I can't figure out how to get accurate measurements we might just have to bump the size
2025-09-22 18:06:22 <@adamwill:fedora.im> !topic (2394358) Fedora 43: Container_Toolbox container x86_64 image exceeds maximum size
2025-09-22 18:06:22 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2394358
2025-09-22 18:06:22 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1918
2025-09-22 18:06:22 <@adamwill:fedora.im> !info Accepted Blocker, distribution, ASSIGNED
2025-09-22 18:06:55 <@adamwill:fedora.im> this one is kinda with debarshi i think
2025-09-22 18:07:00 <@adamwill:fedora.im> he wanted to 'investigate'
2025-09-22 18:08:14 <@adamwill:fedora.im> !info this is kinda on the toolbox team (debarshi) now we figured out more or less the background (see https://bugzilla.redhat.com/show_bug.cgi?id=2393443 ), we have needinfo'd him
2025-09-22 18:08:25 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2394213
2025-09-22 18:08:25 <@adamwill:fedora.im> !topic (2394213) default hostonly-mode "sloppy" results in significant increase in initramfs size
2025-09-22 18:08:25 <@adamwill:fedora.im> !info Accepted Blocker, dracut, MODIFIED
2025-09-22 18:08:25 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1925
2025-09-22 18:08:35 <@pvalena:fedora.im> 👋
2025-09-22 18:08:52 <@adamwill:fedora.im> !info this is gradually getting worked out between upstream and downstream, seems like it's actively being worked on and we should have a good resolution
2025-09-22 18:08:54 <@adamwill:fedora.im> hi pavel
2025-09-22 18:09:00 <@adamwill:fedora.im> does that sound accurate? anything you want to add?
2025-09-22 18:09:29 <@pvalena:fedora.im> sounds ok... the question is when it will be and what changes to make
2025-09-22 18:10:01 <@pvalena:fedora.im> we have latest dracut only in rawhide - because of some breaking changes, so I'll have to manualy backport everything else
2025-09-22 18:10:39 <@pvalena:fedora.im> * or draft some custom downstream changes... for now, I'd rather stick with what upstream released
2025-09-22 18:10:40 <@adamwill:fedora.im> ok...i think we can mostly leave it to your discretion how to handle the backporting. minimal change is always the ideal
2025-09-22 18:11:12 <@pvalena:fedora.im> thanks! any help / opinions are welcome in the issue
2025-09-22 18:12:45 <@pvalena:fedora.im> thanks! any help / opinions are welcome in the issue (or in the Bug)
2025-09-22 18:12:48 <@adamwill:fedora.im> we'll keep an eye on it for sure
2025-09-22 18:12:50 <@adamwill:fedora.im> thanks for your work
2025-09-22 18:13:10 <@adamwill:fedora.im> !action pvalena to continue working out the best backport strategy for F43 release and post-release updates
2025-09-22 18:13:17 <@derekenz:fedora.im> Need to go too. Have a great day or evening everybody 
2025-09-22 18:13:24 <@adamwill:fedora.im> thanks derek
2025-09-22 18:13:27 <@adamwill:fedora.im> we're just about done
2025-09-22 18:13:38 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2391242
2025-09-22 18:13:38 <@adamwill:fedora.im> !info Accepted Blocker, firefox, NEW
2025-09-22 18:13:38 <@adamwill:fedora.im> !topic (2391242) Graphical glitches, slow performance and/or crashes using Firefox on AMD graphics adapters
2025-09-22 18:13:38 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1896
2025-09-22 18:14:27 <@adamwill:fedora.im> !info a lot of progress has been made on this one at various levels and we now have a pretty clear understanding of the bug. it looks like it is ultimately firefox doing something wrong. we have pretty high confidence this can be addressed somehow soon. appropriate maintainers are aware of the problem at all levels
2025-09-22 18:14:39 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2394950
2025-09-22 18:14:39 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1926
2025-09-22 18:14:39 <@adamwill:fedora.im> !info Accepted Blocker, glycin, NEW, depends on other bugs
2025-09-22 18:14:39 <@adamwill:fedora.im> !topic (2394950) No thumbnails for video, music, epub and pdf formats
2025-09-22 18:15:23 <@adamwill:fedora.im> !info there is a plan outlined at https://bugzilla.redhat.com/show_bug.cgi?id=2394950#c8 , so this is in the desktop team's court ATM
2025-09-22 18:15:38 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2395957
2025-09-22 18:15:38 <@adamwill:fedora.im> !info Accepted Blocker, gnome-initial-setup, NEW
2025-09-22 18:15:38 <@adamwill:fedora.im> !topic (2395957) Incorrect keyboard layout in Initial Setup
2025-09-22 18:15:38 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1932
2025-09-22 18:16:46 <@adamwill:fedora.im> !info we need the desktop team to take a look at this. mcatanzaro has CCed himself so they should be aware. we could also try to pin the cause down a little more, possibly
2025-09-22 18:16:59 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2372978
2025-09-22 18:16:59 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1927
2025-09-22 18:16:59 <@adamwill:fedora.im> !info Accepted Blocker, libdnf, POST
2025-09-22 18:16:59 <@adamwill:fedora.im> !topic (2372978) packagekitd shows "failed to add subkeys for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-XX-secondary" errors every second and consumes a lot of CPU if google-chrome repository is enabled
2025-09-22 18:17:30 <@adamwill:fedora.im> !info this one has been fully worked out and a fix proposed and tested, we just need to wait for a new libdnf release or backport it. adamw may backport the fix soon since it's quite a bad bug
2025-09-22 18:17:49 <@adamwill:fedora.im> !info Accepted Blocker, selinux-policy, ASSIGNED
2025-09-22 18:17:49 <@adamwill:fedora.im> !topic (2394561) SELinux is preventing systemd from 'open' accesses on the file /tmp/webui-cockpit-ws.env.
2025-09-22 18:17:49 <@adamwill:fedora.im> !link https://bugzilla.redhat.com/show_bug.cgi?id=2394561
2025-09-22 18:17:49 <@adamwill:fedora.im> !link https://pagure.io/fedora-qa/blocker-review/issue/1922
2025-09-22 18:18:35 <@adamwill:fedora.im> !indo zdenek has diagnosed this in https://bugzilla.redhat.com/show_bug.cgi?id=2394561#c8 , but it sounds like fixing it may not be straightforward
2025-09-22 18:18:55 <@adamwill:fedora.im> !action adamw and lruzicka to work with pvalena and cockpit team to explain why this is a blocker and figure out a way forward
2025-09-22 18:20:48 <@adamwill:fedora.im> aaand that's everything
2025-09-22 18:20:50 <@adamwill:fedora.im> !topic Open floor
2025-09-22 18:20:55 <@adamwill:fedora.im> any other business, if anyone else is left? :D
2025-09-22 18:22:18 <@aggraxis:fedora.im> thank you adamw for keeping us rolling and everyone for voting and participating :)
2025-09-22 18:23:20 <@decathorpe:fedora.im> IIUC the thumbnailer stuff should be mostly fixed with the next glycin release, which was expected for last Friday but hasn't materialized yet
2025-09-22 18:25:52 <@adamwill:fedora.im> yeah, that's what the 'plan' says
2025-09-22 18:25:58 <@adamwill:fedora.im> we have a bit of time, so we can just check in next week
2025-09-22 18:27:07 <@decathorpe:fedora.im> great, more bus factor = me stuff 
2025-09-22 18:30:01 <@adamwill:fedora.im> alright, thanks a lot everyone
2025-09-22 18:30:03 <@adamwill:fedora.im> see you next time
2025-09-22 18:30:05 <@adamwill:fedora.im> !endmeeting