Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=1916094 ** Information from BlockerBugs App:
Commented but haven't voted yet: adamwill, kparal
The votes have been last counted at 2021-02-18 08:26 UTC and the last processed comment was #comment-716194
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
Well, it works with --allowerasing. I don't entirely recall whether we usually consider that OK or not.
--allowerasing
The ugly error should be fixed, but I think --allowerasing is acceptable, if gnome-software or other graphical upgrade tools (not sure what we we use in KDE) handle it well. --allowerasing might be needed for many upgrades this time, anyway, because of rdma-core no longer being multilib and we apparently don't have a better way to handle that: https://src.fedoraproject.org/rpms/rdma-core/pull-request/7
BetaBlocker -1 BetaFE +1
We used to not block on stuff requiring --allowerasing in the past, doesn't seem like an issue for Beta.
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F34 is no longer tracked by BlockerBugs, closing this ticket.
Log in to comment on this ticket.