<@kparal:matrix.org>
16:01:09
!startmeeting F42-blocker-review
<@meetbot:fedora.im>
16:01:11
Meeting started at 2025-03-10 16:01:09 UTC
<@meetbot:fedora.im>
16:01:11
The Meeting name is 'F42-blocker-review'
<@kparal:matrix.org>
16:01:16
!topic Roll Call
<@conan_kudo:matrix.org>
16:01:38
!hi
<@zodbot:fedora.im>
16:01:39
Neal Gompa (ngompa) - he / him / his
<@kparal:matrix.org>
16:01:39
hello, who's here for your favorite blocker review relaxation time?
<@nielsenb:fedora.im>
16:01:55
!hi
<@zodbot:fedora.im>
16:01:57
Brandon Nielsen (nielsenb)
<@lbrabec:matrix.org>
16:02:14
!hi
<@zodbot:fedora.im>
16:02:15
No Fedora Accounts users have the @lbrabec:matrix.org Matrix Account defined
<@amoloney:fedora.im>
16:02:23
!hi
<@zodbot:fedora.im>
16:02:25
Aoife Moloney (amoloney)
<@boniboyblue:fedora.im>
16:03:10
!hi
<@zodbot:fedora.im>
16:03:11
Christopher Boni (boniboyblue)
<@derekenz:fedora.im>
16:03:18
!hi
<@zodbot:fedora.im>
16:03:19
Derek Enz (derekenz)
<@decathorpe:fedora.im>
16:03:37
!hi
<@zodbot:fedora.im>
16:03:38
Fabio Valentini (decathorpe) - he / him / his
<@kparal:matrix.org>
16:05:05
let's start
<@kparal:matrix.org>
16:05:11
!topic Introduction
<@kparal:matrix.org>
16:05:17
Why are we here?
<@kparal:matrix.org>
16:05:21
!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.
<@kparal:matrix.org>
16:05:24
!info We'll be following the process outlined at:
<@kparal:matrix.org>
16:05:26
!link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
<@kparal:matrix.org>
16:05:29
!info The bugs up for review today are available at:
<@kparal:matrix.org>
16:05:32
!link http://qa.fedoraproject.org/blockerbugs/current
<@kparal:matrix.org>
16:05:35
!info The criteria for release blocking bugs can be found at:
<@kparal:matrix.org>
16:05:38
!link https://fedoraproject.org/wiki/Basic_Release_Criteria
<@kparal:matrix.org>
16:05:41
!link https://fedoraproject.org/wiki/Fedora_42_Beta_Release_Criteria
<@kparal:matrix.org>
16:05:44
!link https://fedoraproject.org/wiki/Fedora_42_Final_Release_Criteria
<@kparal:matrix.org>
16:06:32
Today we have:
<@kparal:matrix.org>
16:06:35
!info 0 Proposed Blockers
<@kparal:matrix.org>
16:06:39
!info 5 Accepted Blockers
<@kparal:matrix.org>
16:06:41
!info 0 Accepted 0-day Blockers
<@kparal:matrix.org>
16:06:44
!info 0 Accepted Previous Release Blockers
<@kparal:matrix.org>
16:06:47
!info 3 Proposed Freeze Exceptions
<@kparal:matrix.org>
16:06:49
!info 9 Accepted Freeze Exceptions
<@kparal:matrix.org>
16:07:23
since we have no proposed blockers, let's start with proposed freeze exceptions
<@kparal:matrix.org>
16:07:51
!topic Proposed Beta Freeze Exceptions
<@kparal:matrix.org>
16:07:58
!topic (2347151) use entire disk by default seems risky
<@kparal:matrix.org>
16:08:01
!link https://bugzilla.redhat.com/show_bug.cgi?id=2347151
<@kparal:matrix.org>
16:08:03
!link https://pagure.io/fedora-qa/blocker-review/issue/1787
<@kparal:matrix.org>
16:08:06
!info Proposed Freeze Exceptions, anaconda-webui, POST
<@kparal:matrix.org>
16:08:08
!info Ticket vote: BetaFreezeException (+1,0,-0) (+kparal)
<@kparal:matrix.org>
16:09:10
this seems sensible and changing the default option should be low risk
<@nielsenb:fedora.im>
16:09:29
What was the anaconda default?
<@boniboyblue:fedora.im>
16:09:43
Erase everything / Automatic setup.
<@nielsenb:fedora.im>
16:10:36
I suppose the merit of a change is somewhat orthogonal to its freeze status
<@nielsenb:fedora.im>
16:11:06
From a freeze standpoint, I can't see this breaking anything else
<@kparal:matrix.org>
16:11:29
oh, I forgot, we need a secretary. Fortunately, we seem to have a volunteer in Lukas Brabec , right Lukas? 🙂
<@lbrabec:matrix.org>
16:12:25
you seem to be deliberately misunderstanding what volunteering means, but yes :-)
<@kparal:matrix.org>
16:12:32
Awesome!
<@kparal:matrix.org>
16:12:47
!info Lukas Brabec will act as the secretary
<@kparal:matrix.org>
16:13:09
so, any FE votes here?
<@boniboyblue:fedora.im>
16:13:23
+1 for me.
<@nielsenb:fedora.im>
16:13:26
BetaFE +1
<@derekenz:fedora.im>
16:13:29
BetaFE +1
<@nielsenb:fedora.im>
16:13:34
If people want this change, I have no issue with it going in
<@lbrabec:matrix.org>
16:13:38
I don't understand why this should be FE...
<@decathorpe:fedora.im>
16:13:42
BetaFE+1
<@nielsenb:fedora.im>
16:13:47
I do think ultimately no default will satisfy everyone
<@boniboyblue:fedora.im>
16:14:30
True but if the user then proceeds to wipe their other OS it'll be by their own doing.
<@kparal:matrix.org>
16:14:33
I think because we want to lower the number of people who erasing their disk by accident, by not reading correctly and clicking Next every time
<@kparal:matrix.org>
16:14:45
I think because we want to lower the number of people who erase their disk by accident, by not reading correctly and clicking Next every time
<@decathorpe:fedora.im>
16:14:48
Making a destructive action a deliberate choice makes sense to me.
<@lbrabec:matrix.org>
16:14:54
sure I understand that and I agree
<@lbrabec:matrix.org>
16:15:14
but why FE?
<@nielsenb:fedora.im>
16:15:25
That's where I'm at, if we're going to change the default, might as well change to something non destructive
<@kparal:matrix.org>
16:15:27
are you suggesting this to be a blocker?
<@kparal:matrix.org>
16:15:38
if this should go into Beta, it needs to be one or the other
<@lbrabec:matrix.org>
16:16:54
well I don't think it needs to go to beta... there is window between beta and final, right?
<@kparal:matrix.org>
16:17:01
sure, if it doesn
<@kparal:matrix.org>
16:17:07
doesn't go into Beta, it will land later
<@kparal:matrix.org>
16:17:37
anaconda devs proposed it as a FE, so they would like to have it in Beta, is my understanding
<@lbrabec:matrix.org>
16:18:06
okay then, +1 BetaFE
<@kparal:matrix.org>
16:18:18
ok, thanks
<@kparal:matrix.org>
16:18:30
proposed !agreed 2347151 - Accepted as a Beta Freeze Exception - This seems very low risk, and the new default to make a destructive action a deliberate choice makes sense to us.
<@kparal:matrix.org>
16:19:21
(ack/nack/patch)
<@nielsenb:fedora.im>
16:19:30
ack
<@derekenz:fedora.im>
16:19:34
ack
<@lbrabec:matrix.org>
16:20:25
ack
<@kparal:matrix.org>
16:20:38
!agreed 2347151 - Accepted as a Beta Freeze Exception - This seems very low risk, and the new default to make a destructive action a deliberate choice makes sense to us.
<@kparal:matrix.org>
16:20:52
!topic (2351031) Update the Asahi audio stack for Fedora Linux 42
<@kparal:matrix.org>
16:20:55
!link https://bugzilla.redhat.com/show_bug.cgi?id=2351031
<@kparal:matrix.org>
16:20:58
!link https://pagure.io/fedora-qa/blocker-review/issue/1786
<@kparal:matrix.org>
16:21:01
!info Proposed Freeze Exceptions, asahi-audio, NEW
<@kparal:matrix.org>
16:21:04
!info Ticket vote: BetaFreezeException (+3,0,-0) (+lruzicka, +lbrabec, +kparal)
<@kparal:matrix.org>
16:22:04
looks safe to me, and Asahi is really trying to follow the same lifecycle as Fedora. Seems OK to push these stable for them.
<@decathorpe:fedora.im>
16:22:55
yeah. BetaFE+1
<@derekenz:fedora.im>
16:23:02
BetaFE +1
<@nielsenb:fedora.im>
16:23:05
BetaFE +1
<@kparal:matrix.org>
16:24:08
proposed !agreed 2351031 - Accepted as a Beta Freeze Exception - This seems low risk and will help Asahi downstream.
<@decathorpe:fedora.im>
16:24:34
ack
<@lbrabec:matrix.org>
16:24:35
ack
<@derekenz:fedora.im>
16:24:37
ack
<@nielsenb:fedora.im>
16:24:38
ack
<@kparal:matrix.org>
16:25:15
!agreed 2351031 - Accepted as a Beta Freeze Exception - This seems low risk and will help Asahi downstream.
<@kparal:matrix.org>
16:26:05
!topic (2349606) GTK3-based apps' menus are glitched on KDE, potentially causing the whole app to become unresponsive
<@kparal:matrix.org>
16:26:08
!link https://bugzilla.redhat.com/show_bug.cgi?id=2349606
<@kparal:matrix.org>
16:26:11
!link https://pagure.io/fedora-qa/blocker-review/issue/1775
<@kparal:matrix.org>
16:26:13
!info Proposed Freeze Exceptions, gtk3, NEW
<@kparal:matrix.org>
16:26:16
!info Ticket vote: BetaBlocker (+2,0,-6) (+ngompa, +geraldosimiao, -kparal, -lruzicka, -lbrabec, -adamwill, -derekenz, -boniboyblue)
<@kparal:matrix.org>
16:26:19
!info Ticket vote: BetaFreezeException (+3,0,-0) (+nixuser, +nielsenb, +kparal)
<@kparal:matrix.org>
16:26:32
this was already rejected as a blocker, and reproposed as a FE
<@conan_kudo:matrix.org>
16:26:41
I'm fine with it as an FE
<@conan_kudo:matrix.org>
16:26:47
+1 BetaFE
<@decathorpe:fedora.im>
16:26:54
yeah, BetaFE+1
<@lbrabec:matrix.org>
16:27:05
+1 BetaFE
<@derekenz:fedora.im>
16:27:07
+1 BetaFE
<@kparal:matrix.org>
16:27:10
there is a slight chance that the gtk3 fix might do something else, but OTOH in workstation everything should be mostly gtk4
<@boniboyblue:fedora.im>
16:27:22
+1 BetaFE
<@kparal:matrix.org>
16:27:45
we'll pull it in if we see no bad behavior elsewhere, so after some feedback
<@kparal:matrix.org>
16:28:04
(but there's no update proposed yet)
<@kparal:matrix.org>
16:28:58
proposed !agreed 2349606 - Accepted as a Beta Freeze Exception - We would like to fix certain GTK apps misbehaving in KDE Plasma.
<@decathorpe:fedora.im>
16:29:18
ack
<@derekenz:fedora.im>
16:29:21
ack
<@lbrabec:matrix.org>
16:29:23
ack
<@nielsenb:fedora.im>
16:29:30
ack
<@kparal:matrix.org>
16:29:41
!agreed 2349606 - Accepted as a Beta Freeze Exception - We would like to fix certain GTK apps misbehaving in KDE Plasma.
<@kparal:matrix.org>
16:31:18
hmm, I wonder whether we now review accepted beta blockers or vote for proposed final blockers
<@kparal:matrix.org>
16:32:16
!topic Accepted Beta Blockers
<@kparal:matrix.org>
16:32:44
!topic (2349658) anaconda text mode installer fails to run on fallback
<@kparal:matrix.org>
16:32:46
!link https://bugzilla.redhat.com/show_bug.cgi?id=2349658
<@kparal:matrix.org>
16:32:48
!link https://pagure.io/fedora-qa/blocker-review/issue/1776
<@kparal:matrix.org>
16:32:51
!info Accepted Blocker, anaconda, VERIFIED
<@kparal:matrix.org>
16:32:55
this one is verified, but not closed
<@kparal:matrix.org>
16:33:31
I think we can just close this, all relevant builds should be stable already
<@kparal:matrix.org>
16:33:50
Lukas Brabec: thoughts?
<@kparal:matrix.org>
16:35:26
!info This looks like it can be just closed as fixed.
<@kparal:matrix.org>
16:35:52
!topic (2350605) The dev-gpt-auto-root.device times out and makes system not bootable.
<@kparal:matrix.org>
16:35:56
!link https://bugzilla.redhat.com/show_bug.cgi?id=2350605
<@kparal:matrix.org>
16:35:59
!link https://pagure.io/fedora-qa/blocker-review/issue/1783
<@kparal:matrix.org>
16:36:02
!info Accepted Blocker, systemd, NEW
<@kparal:matrix.org>
16:36:16
this is our current room-on-fire
<@kparal:matrix.org>
16:37:05
Adam CCed people who should be able to change the default boot args, hopefully that will be enough to get it fixed
<@kparal:matrix.org>
16:37:30
!info this waits on devs to adjust default boot args
<@lbrabec:matrix.org>
16:38:18
There is a comment "This update has been unpushed.", is that relevant for us?
<@kparal:matrix.org>
16:38:33
that's because a newer anaconda replaced it, I hope
<@kparal:matrix.org>
16:39:20
ok, let's go on
<@kparal:matrix.org>
16:39:34
don't fall asleep just yet, we go to another set of proposed blockers!
<@kparal:matrix.org>
16:39:47
!topic Proposed Final Blockers
<@kparal:matrix.org>
16:39:56
!topic (2349754) dnf system-upgrade no longer accepts --allowerasing
<@kparal:matrix.org>
16:39:59
!link https://bugzilla.redhat.com/show_bug.cgi?id=2349754
<@kparal:matrix.org>
16:40:01
!link https://pagure.io/fedora-qa/blocker-review/issue/1778
<@kparal:matrix.org>
16:40:04
!info Proposed Blocker, dnf5, POST
<@kparal:matrix.org>
16:40:06
!info Ticket vote: FinalBlocker (+2,0,-0) (+boniboyblue, +nielsenb)
<@conan_kudo:matrix.org>
16:40:23
Yeah this is bad from a UX perspective
<@conan_kudo:matrix.org>
16:40:29
FinalBlocker +1
<@kparal:matrix.org>
16:40:42
note that we don't have a criterion for it
<@kparal:matrix.org>
16:40:59
so if we agree we want to block on this, we need to come up with one
<@kparal:matrix.org>
16:41:10
not right now, of course
<@decathorpe:fedora.im>
16:41:25
"upgrade doesn't work" isn't a blocker? :D
<@kparal:matrix.org>
16:41:56
https://fedoraproject.org/wiki/Fedora_42_Beta_Release_Criteria#Upgrade_requirements
<@kparal:matrix.org>
16:42:02
"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. "
<@kparal:matrix.org>
16:42:25
that will not hit that issue, and if it does, we just fix the deps, so --allowerasing is never needed in this case
<@decathorpe:fedora.im>
16:42:40
(given the amount of times that --allowerasing is required to make upgrade work at all, I mean - it *shouldn't* be needed, but it often is)
<@decathorpe:fedora.im>
16:43:09
and upgrade path / fedora-obsolete-packages is a bit of a whack-a-mole game
<@kparal:matrix.org>
16:43:23
we would need to say that a method for dealing with broken dependencies (e.g. by removing affected packages) must be available and working in dnf for system upgrades
<@kparal:matrix.org>
16:43:49
or, we can wait a week or two and the devs might fix it by then and we don't need to define a new criterion, at least for this cycle 😄
<@kparal:matrix.org>
16:45:07
so, any other thoughts?
<@kparal:matrix.org>
16:45:43
are we in general for blocking on this? I can punt it at the moment, given that we don't have the criterion, and see what happens in a week
<@nielsenb:fedora.im>
16:45:50
I'm still on team block, and update criteria
<@decathorpe:fedora.im>
16:45:51
Punt+1 :)
<@nielsenb:fedora.im>
16:46:15
And if we don't block, update criteria with a footnote making it clear this isn't a blocking case
<@kparal:matrix.org>
16:46:40
It is clear that this is not covered, at least in my view
<@kparal:matrix.org>
16:46:56
not at the moment
<@lruzicka:matrix.org>
16:46:57
If the DNF5 functionality is not there, we cannot enforce it.
<@nielsenb:fedora.im>
16:47:09
That's fair
<@kparal:matrix.org>
16:47:26
the functionality is disabled by accident
<@kparal:matrix.org>
16:47:55
of course if they insisted that they don't want to support it, then it would be a different conversation
<@lruzicka:matrix.org>
16:48:46
The bug does not say it is by accident. It only says it could be useful.
<@kparal:matrix.org>
16:49:18
It was there and it dropped out when they refactored their whole cmdline interface in DNF5
<@kparal:matrix.org>
16:49:53
also, it's already merged
<@kparal:matrix.org>
16:50:06
ah, actually even built in rawhide
<@kparal:matrix.org>
16:51:13
proposed !agreed 2349754 - Punt - People are in general in favor of blocking on this, but there's no direct criterion for it. It seems it will be fixed soon anyway, let's wait a while before potentially proposing a criterion (if we decide to block on it).
<@lruzicka:matrix.org>
16:51:56
If this is already merged, why do we need to punt?
<@lruzicka:matrix.org>
16:52:01
Why no FE?
<@lruzicka:matrix.org>
16:52:14
Why not FE?
<@conan_kudo:matrix.org>
16:52:17
frankly I don't think we should let this by without having a criterion defined
<@kparal:matrix.org>
16:52:18
this will go into F40 and F41, not F42
<@kparal:matrix.org>
16:52:36
it can only be a 0 day blocker
<@kparal:matrix.org>
16:52:42
so no FE
<@kparal:matrix.org>
16:53:26
I do believe that a Beta 0 day blocker would be too harsh at this point
<@kparal:matrix.org>
16:53:37
so Final, if we have a criterion and it's not still fixed
<@lruzicka:matrix.org>
16:53:57
I do not think this should be a blocker. This will go away, when it hits former releases and it will also become part of F42 so that we will not have the same sitation with F43.
<@kparal:matrix.org>
16:55:34
Even if it's fixed, we can always propose a criterion later. We just must not forget (and find the time).
<@kparal:matrix.org>
16:55:56
ok, so, any votes towards the Punt proposal above?
<@nielsenb:fedora.im>
16:56:11
I'm fine with punt?
<@derekenz:fedora.im>
16:56:13
Punt
<@nielsenb:fedora.im>
16:56:14
Punt +1
<@lbrabec:matrix.org>
16:56:32
ack punt
<@kparal:matrix.org>
16:57:05
!agreed 2349754 - Punt - People are in general in favor of blocking on this, but there's no direct criterion for it. It seems it will be fixed soon anyway, let's wait a while before potentially proposing a criterion (if we decide to block on it).
<@kparal:matrix.org>
16:57:23
!topic (1801539) ostree-based systems deployed with blivet can't fstrim LUKS-encrypted partitions of SSD hard drive by default
<@kparal:matrix.org>
16:57:26
!link https://bugzilla.redhat.com/show_bug.cgi?id=1801539
<@kparal:matrix.org>
16:57:29
!link https://pagure.io/fedora-qa/blocker-review/issue/1782
<@kparal:matrix.org>
16:57:32
!info Proposed Blocker, python-blivet, POST
<@kparal:matrix.org>
16:57:35
!info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
<@nielsenb:fedora.im>
16:58:05
Did we not need to ack the punt?
<@kparal:matrix.org>
16:59:16
I took your +1 punt as acks
<@kparal:matrix.org>
16:59:22
was it not meant that way?
<@derekenz:fedora.im>
16:59:38
just in case ack
<@nielsenb:fedora.im>
17:00:10
It's fine with me, I was just making sure we didn't miss anything
<@kparal:matrix.org>
17:01:36
sorry I still haven't read this one, just reading it
<@boniboyblue:fedora.im>
17:03:51
Annoying issue that I've had on my own hardware.
<@kparal:matrix.org>
17:04:00
so it looks like the only release-blocking image this affects is IoT, but only if it has full disk encryption enabled?
<@kparal:matrix.org>
17:04:10
how frequent is that, Lukas Brabec ?
<@kparal:matrix.org>
17:04:28
also, do SDcards (often used in IoT, right) support trim anyway?
<@lbrabec:matrix.org>
17:04:40
I don't think so
<@kparal:matrix.org>
17:05:04
jkonecny: are you here?
<@kparal:matrix.org>
17:07:14
I believe this one should definitely be documented as a CommonBug. But at this moment I don't see a good argument for blocking on it. IoT doesn't seem to be likely affected by this. And we don't block on Silverblue.
<@kparal:matrix.org>
17:08:37
also, we've shipped it this way for at least 5 years. It sucks, but weakens the blocker proposal even more.
<@nielsenb:fedora.im>
17:09:50
I agree
<@kparal:matrix.org>
17:09:54
I'm currently mostly -1 blocker on this. And I'm saying that as someone who wouldn't run a system without fstrim.
<@lruzicka:matrix.org>
17:09:57
-1 FB
<@nielsenb:fedora.im>
17:10:16
I agree
<@conan_kudo:matrix.org>
17:10:32
the fstrim service isn't required for anything using btrfs, fwiw
<@conan_kudo:matrix.org>
17:10:41
since btrfs does trim on its own
<@kparal:matrix.org>
17:12:10
Conan Kudo: but this is about disk encryption, and if you have btrfs on top of it, any discard call won't be forwarded through LUKS anyway
<@conan_kudo:matrix.org>
17:12:30
oof
<@cmurf:fedora.im>
17:12:56
it should pass through LUKS
<@kparal:matrix.org>
17:12:56
but only for ostree deployments
<@kparal:matrix.org>
17:13:37
it should, if you allow it, and that's what this bug is about - the config files doesn't work on ostree installs. Or am I reading it wrong?
<@kparal:matrix.org>
17:14:15
"It seems that somehow LUKS (dm-crypt) in Silverblue is not properly configured to pass discard commands."
<@kparal:matrix.org>
17:14:42
and then details about crypttab etc
<@cmurf:fedora.im>
17:14:48
Oh I see right. Adding `discard` to `/etc/crypttab` may be implemented by Anaconda. So everywhere else it's probably the cryptsetup default which is no discard.
<@boniboyblue:fedora.im>
17:14:57
Not helpful for us but the workaround is pretty simple - pretty sure it's just one terminal command.
<@conan_kudo:matrix.org>
17:15:35
we could flip the default in cryptsetup?
<@conan_kudo:matrix.org>
17:15:47
it doesn't seem like a good default currently
<@kparal:matrix.org>
17:15:58
it's being discussed in there
<@kparal:matrix.org>
17:16:14
but not really important for this decision, I think
<@kparal:matrix.org>
17:16:21
blocker decision, I mean
<@kparal:matrix.org>
17:16:40
so right now I see -3 blocker votes, -2 here and -1 from the vote ticket
<@derekenz:fedora.im>
17:16:51
FinalBlocker -1
<@cmurf:fedora.im>
17:16:52
Well the logic behind the default is it's more secure to not put TRIM "holes" in the media which I guess some crypto folks think makes it easier to infer what's on the drive (?) Not my area.
<@boniboyblue:fedora.im>
17:16:56
FinalBlocker -1
<@cmurf:fedora.im>
17:17:31
yeah -1 since I'm here babbling anyway 😂
<@kparal:matrix.org>
17:19:35
proposed !agreed 1801539 - Rejected as a Final Blocker - Silverblue is not a blocking deliverable, so we can't consider it here. IoT should be affected by this in theory, but in practice it seems unlikely that full disk encryption is used at scale there, by our estimate. Also, many SD cards (used in IoT) might not even support trim. Additionally, this problem has been around for 5 years already, further weakening the blocker proposal. We will document this as a CommonBug instead.
<@derekenz:fedora.im>
17:20:00
ack
<@boniboyblue:fedora.im>
17:20:03
ack
<@nielsenb:fedora.im>
17:20:18
ack
<@lbrabec:matrix.org>
17:20:58
ack
<@lruzicka:matrix.org>
17:21:48
ack
<@kparal:matrix.org>
17:22:33
!agreed 1801539 - Rejected as a Final Blocker - Silverblue is not a blocking deliverable, so we can't consider it here. IoT should be affected by this in theory, but in practice it seems unlikely that full disk encryption is used at scale there, by our estimate. Also, many SD cards (used in IoT) might not even support trim. Additionally, this problem has been around for 5 years already, further weakening the blocker proposal. We will document this as a CommonBug instead.
<@kparal:matrix.org>
17:23:15
!topic Open Discussion <your bugs here>
<@kparal:matrix.org>
17:23:31
That's all! Is there anything else to discuss?
<@lruzicka:matrix.org>
17:24:04
Not at the moment.
<@conan_kudo:matrix.org>
17:24:08
nope
<@derekenz:fedora.im>
17:24:12
nope
<@nielsenb:fedora.im>
17:24:32
Not from me
<@boniboyblue:fedora.im>
17:25:08
Nothing from me.
<@kparal:matrix.org>
17:25:26
Thanks everyone for coming and helping out, then! See you next time 🙂
<@kparal:matrix.org>
17:25:32
!endmeeting