Bug details: https://bugzilla.redhat.com/show_bug.cgi?id=2068773 Information from BlockerBugs App: <img alt="2068773" src="https://qa.fedoraproject.org/blockerbugs/api/v0/bugimg/2068773" />
The votes have been last counted at 2022-04-04 18:59 UTC and the last processed comment was #comment-790470
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
I suggest that it is not a regression in DNF but I suggest that something else was changed. Each release gets Fedora repositories bigger therefore dnf requires more memory to process them. The solution would be to make them smaller. The second possibility can be related to exchange of compression algorithm. This part is something not related to DNF at all. In future dnf can not load file lists on such a machines, but it requires development in upstream (RFE).
FinalBlocker -1
It feels really unfortunate to me that Fedora IoT doesn't really work on what I would consider one of the quintessential IoT devices, but I don't really see how we can block? If a device doesn't have enough memory, there isn't much we can do. Hopefully in the future these memory requirements can be addressed.
I agree with @jmracek. We should require the RFE for the future to make sure this does not need to happen.
Blocker mechanism is not intended for RFE, IMO, it could have been used if RPI Zero 2W was "supported device" which doesn't seem to be the case as per https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
AGREED RejectedFinalBlocker
The following votes have been closed:
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F36 is no longer tracked by BlockerBugs, closing this ticket.
Login to comment on this ticket.