Bug 2203350

Summary:	uname -p on Fedora 38+ says "unknown"
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	coreutils	Assignee:	Kamil Dudka <kdudka>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	admiller, jamartis, jarodwilson, kdudka, kzak, ovasik, p, svashisht, vmihalko
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-05-14 15:29:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Williamson 2023-05-12 04:42:08 UTC

On Fedora 38 and later, running `uname -p` says "unknown". On Fedora 37 - at least Fedora 37 original release images, haven't checked an updated system yet - `uname -p` gives the arch, at least on my system and VMs running on that system it does (x86_64).

This is an issue because Python `platform.processor()` basically just returns the output of `uname -p`, or an empty string if it's "unknown". I have a script that relies on that output to figure out what arch it's running on, which was broken because of this - I had to implement a fallback to `platform.machine()` if the output of `platform.processor()` is empty.

Reproducible: Always

Steps to Reproduce:
1. Run `uname -p`

Actual Results:  
It says "unknown"

Expected Results:  
It should say something...more useful

Comment 1 Kamil Dudka 2023-05-14 15:29:17 UTC

I believe the ultimate fix is to use `platform.machine()` unconditionally in the script.

The -i and -p options of uname have been documented as non-portable since 2015:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-7-g6d67649

*** This bug has been marked as a duplicate of bug 2126206 ***