Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2396016 ** Information from BlockerBugs App:
Commented but haven't voted yet: adamwill
The votes have been last counted at 2025-09-23 07:37 UTC and the last processed comment was #comment-986915
To learn how to vote, see: https://pagure.io/fedora-qa/blocker-review A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)
BetaBlocker +1
BetaBlocker
FinalBlocker
BetaFE
FinalFE
0Day
PreviousRelease
+1
0
-1
Is Silverblue actually release blocking?
Silverblue isn't a release blocking deliverable. Here's a list of the currently blocking deliverables: https://docs.fedoraproject.org/en-US/releases/f43/blocking/
FinalBlocker -1
This seems bad, but I don't think we can really block on a non-release blocking deliverable.
FinalBlocker -1 FinalFE +1
@lruzicka I think you typoed your vote.
https://bugzilla.redhat.com/show_bug.cgi?id=2396016#c3 seems to suggest this is not Silverblue-specific. I'm not sure what is needed to trigger it, though. Very old pre-authselect installation?
AGREED RejectedFinalBlocker
Discussed at the 2025-09-22 (blocker / freeze exception) review meeting:
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
https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-22/f43-blocker-review.2025-09-22-16.01.txt
The following votes have been closed:
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F43 is no longer tracked by BlockerBugs, closing this ticket.