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