Collin Funk <[email protected]> writes: > DJ Delorie <[email protected]> writes: > >> This has come up a few times in the past, and I agree the right >> solution is "don't use them", but popular GNU/Linux distros have >> carried patches in the past (similar to the attached) and people have >> gotten used to them producing *something*, and things broke when the >> patches got dropped. Canonicalizing "it's just -m" might help people >> switch, too. >> >> I am also contemplating an extension to glibc's confstr() that can >> return something more specific than "uname -m" that might be more >> useful but less compatible than past behavior, but I don't know if it >> would make the portability situation better or worse ;-) >> >> The patch only falls back to -m if the user explicitly asked for -p or >> -i, it does not affect -a/-A. It also does not complain if uname() >> fails. > > I'd prefer that people just fix the buggy programs that use 'uname -p'. > Some notes on various distributions, since these options have > unfortunately caused me a lot of wasted time. > > Various Ubuntu software packages broke when they decided to abandon GNU > coreutils because the package they used to replace it didn't have the > patch they used for GNU coreutils. They plan to remove it in Ubuntu > 27.04 [1]. Until then, it gives this annoying output, telling you three > times that you use x86_64 (that also prints a pointer to a variable that > is no longer in scope): > > $ gnuuname -a > Linux 3fbca5011dfa 7.3.3-300.fc45.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov > 6 20:37:28 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux > > Fedora removed their patch 4 years ago [2]. I am not sure if they ran > into any issues because of the behavior change. Here are some related > Red Hat Jira tickets that I haven't looked into much [3][4][5][6]. > > I don't know if Debian ever used a patch for this behavior. I checked > all Debian versions from Squeeze (2011) to Trixie (2025), and both > options return unknown in all versions, so I don't think they did. > > SUSE uses a patch that reads from /proc/cpuinfo for 'uname -p', only on > i686, otherwise, it uses the machine member of struct utsname. It uses > the machine member of struct utsname for 'uname -i' [7]. This leads to a > similar 'uname -a' output to that seen on Ubuntu: > > $ uname -a > Linux f959b35856a3 7.3.3-300.fc45.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov > 6 20:37:28 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux > > Gentoo does something here, probably reading from /proc, but I checked > in a container without the ability to install packages to investigate > further.
In our Gentoo stage3 containers, you should be able to run `emerge-webrsync` or `emerge --sync` and then be able to install packages, if that helps. > Also, I don't see any relevant patches for this behavior, which > is confusing [8]: > > $ uname -i > AuthenticAMD > $ uname -p > AMD Ryzen 7 3700X 8-Core Processor > > I've CC'd Sam James, since he likely knows what the Gentoo version is > doing and can point out something (likely obvious) that I am missing. Thank you Collin! In coreutils-9.12-patches.tar.xz, we have: 0001-uname-Add-processor-hardware-platform-option.patch 0002-tests-sandbox-fixes.patch 0003-dircolors-Add-more-dir-file-colors.patch 0004-cp-ignore-EEXIST-errors-from-mkdir.patch and then some backports. 0002 isn't relevant to upstream. (We use tarballs for larger patchsets sometimes. I am slowly converting these to be based on git repos wherever possible.) That 0001 patch has the following header: > From 4b2dffb164ac638091aa9de36bc88f4802a2bf43 Mon Sep 17 00:00:00 2001 > From: Mike Frysinger <[email protected]> > Date: Wed, 5 Aug 2015 07:45:29 +0000 > Subject: [PATCH 1/4] uname: Add --processor/--hardware-platform option > > On linux platforms, grok /proc/cpuinfo for the CPU/vendor info. > > Prob not suitable for upstream seeing as how it's 100% linux-specific > http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00063.html > > Patch originally by Carlos E. Gorges <[email protected]>, but > heavily reworked to suck less. > > To add support for additional platforms, check out the show_cpuinfo() > func in the linux/arch/<ARCH>/ source tree of the kernel. > > (rebased by sam for ~9.1) > > Signed-off-by: Sam James <[email protected]> I see one ebuild uses `uname -p`, but I think on arm64, it may actually do what they were expecting: $ grep -rsin uname.*-p media-libs/libaom/libaom-3.14.1.ebuild:128: if use arm && ! use cpu_flags_arm_neon && [[ $(uname -p) == "aarch64" ]] ; then media-libs/libaom/libaom-9999.ebuild:128: if use arm && ! use cpu_flags_arm_neon && [[ $(uname -p) == "aarch64" ]] ; then media-libs/libaom/libaom-3.12.1.ebuild:127: if use arm && ! use cpu_flags_arm_neon && [[ $(uname -p) == "aarch64" ]] ; then dev-util/plan9port/files/plan9port-builderr.patch:13: # On Solaris x86, uname -p cannot be trusted. These days, we try to avoid patching in options or anything that users may be surprised lacks on another distro. But I was reluctant to drop the patch when I last rebased it as I wasn't aware of the context (not sure if my rebase predates those events you mention happening) and because of the risk of breaking anything that has come to rely on it. I can certainly look at dropping it. > > It seems that the patches are gradually being dropped. > > Collin > > [1] https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2150305 > [2] > https://src.fedoraproject.org/rpms/coreutils/c/cd953e11dd78cada371f0389171cea671949141b > [3] https://redhat.atlassian.net/browse/RHEL-74146 > [4] https://redhat.atlassian.net/browse/RHEL-79768 > [5] https://redhat.atlassian.net/browse/RHEL-184885 > [6] https://redhat.atlassian.net/browse/RHEL-39739 > [7] > https://build.opensuse.org/projects/openSUSE:Factory/packages/coreutils/files/coreutils-sysinfo.patch?expand=1 > [8] > https://github.com/gentoo/gentoo/tree/5daa2fa3c472125b5b251a74bb05ba0bca7c4011/sys-apps/coreutils/files thanks, sam
signature.asc
Description: PGP signature
