Sam James <[email protected]> writes: >> 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.
Yep, that fixed it, thanks! >> 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.) Ah, I assumed they would all be in git. Good to know. > 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 The main issue with this feature is that it is mostly a Solaris-ism, and platform-specific code must be used to implement it. Those APIs are pretty much chosen by best-effort matching the Solaris definition of hardware platform (-i) and processor (-p). >> 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. I'm pretty sure using 'uname -m' there wouldn't change the behavior, since it returns "aarch64". Whether it is worth changing and/or dropping that patch, I'll let you decide. Thanks for the help! Collin
