We explicitly don't want this in Fedora. rpm uses "uname -m" and we explicitly decided that arm64 would be kept out. We want this reverted [1] before GA because teams install vanilla installer and never update it, as well as it being on live images and Arm images from the duration of the release. As documented in the upstream PR [2] the commit was for one company and their use of alien in a different distribution. We need to revert this to ensure no support issues for the lifetime of F-31 and any ongoing that may happen until a workable compromise can be agreed upon upstream. The arm64.rpm packages wouldn't be useable on el7/el8 or other Fedora releases which also adds to the support issues. some what related to rhbz 1691430 [1] https://github.com/rpm-software-management/rpm/pull/901/commits/0351a07fe5fe3c82cc8bdc4d85de9ff4624945c6 [2] https://github.com/rpm-software-management/rpm/pull/901
Proposed as a Blocker for 31-final by Fedora user pbrobinson using the blocker tracking app because: Support issues on a primary architecture
FEDORA-2019-b674cf1e25 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b674cf1e25
Discussed during the 2019-10-21 blocker review meeting: [0] The decision to delay the classification of this bug as a blocker and to classify this bug as an "AcceptedFreezeException" was made as we accept pbrobinson's contention as ARM lead that this is undesired functionality that we don't want shipped in F31 as it may create a support burden. There is no clear rationale for blocker status but we leave the possibility open for further review at go/no-go meeting depending on how things go this week. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-21/f31-blocker-review.2019-10-21-16.00.txt
This must not be allowed to ship in Fedora or it will become a permanent problem requiring continual effort to undo.
Here's the comment I added to the upstream issue, for context: Let me be very, very clear: The name of the 64-bit Arm architecture state in which 64-bit binaries are executed is - and always has been - "aarch64". There was never an "arm64", nor does it exist. The name "arm64" is also an explicit violation of Arm's trademark policy. When Arm first created the 64-bit Arm architecture, they explicitly and proactively asked that we (and everyone else) use the name "aarch64" to describe it so that it would not contain a trademarked name, and because it was their architecture to name since they invented it in the first place and did the initial enablement work for toolchains and other prerequisite components for bringup. There were two categories of responses to this polite and reasonable request: Those who listened and collaborated to adopt the name of the architecture Those who did not listen and chose the name "arm64" for other reasons The name of the architecture is - and always has been - "aarch64". The name "arm64" is not a valid name and it should not be perpetuated simply because some chose to use it instead.
I sure do wish this had been addressed earlier. However, here we are now. The rationale from Peter and additional support from Jon are both quite strong. I don't think we can ship like this. If we need to, let's consider pulling the aarch64 images from the GA release and putting them out as an update the following week.
The change is in the current release candidate, so we should be fine. It'd be good if Peter/Jon can confirm it's as expected: https://kojipkgs.fedoraproject.org/compose/31/Fedora-31-20191022.4/compose/
(In reply to Adam Williamson from comment #7) > The change is in the current release candidate, so we should be fine. It'd > be good if Peter/Jon can confirm it's as expected: > https://kojipkgs.fedoraproject.org/compose/31/Fedora-31-20191022.4/compose/ Working to confirm both this and the other blocker ATM
rpm-4.15.0-5.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b674cf1e25
FEDORA-2019-fec5c2fbb8 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fec5c2fbb8
rpm-4.15.0-6.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.