commit 80c4a9f912e8b2dd2377c5fc7c6dd687c719ac4e
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 30 22:32:01 2026 +0200

dev-util/amdsmi: new package, forked for ROCm 10.0

::gentoo stops at amdsmi-7.2.0, and amdsmi build-depends on
dev-libs/rocm-core:$. With rocm-core-10.0.0 installed that ebuild cannot
be rebuilt at all: portage answers a rebuild request by trying to DOWNGRADE
rocm-core to 7.2.4, which collides with dev-util/hip-10.0.0's
~dev-libs/rocm-core-10.0.0. Confirmed with the resolver, not by reading:

before [ebuild UD ] dev-libs/rocm-core-7.2.4:0/7.2 [10.0.0:0/10.0]
... slot conflict, exit 1
after [ebuild U ] dev-util/amdsmi-10.0.0:0/10.0::stuff [7.2.0:0/7.2::gentoo]
... exit 0, rocm-core untouched

An installed amdsmi-7.2.0 keeps working, because its RDEPEND is python-only --
which is why this stayed invisible until something tried to rebuild it.
`emerge -uDN @world` does, and that is where it surfaced.

Same fork rationale and the same SRC_URI shape as dev-util/roctracer: AMD
retired the rocm-* line at 7.2.4 and ROCm/amdsmi's own tags stop at
therock-7.10, so the 10.0 source ships only as the amdsmi.tar.gz asset on the
rocm-systems therock-<major.minor> release.

Three things had to change versus ::gentoo's 7.2.0, each verified against the
unpacked source:

- esmi_ib_library is now pinned by COMMIT, not by tag. Upstream's CMakeLists
sets ESMI_GIT_HASH and fetches that exact hash; ::gentoo's esmi_pkg_ver-4.2
tag is too old for the 10.0 API and fails to compile ("too many arguments to
function esmi_pwr_efficiency_mode_set", plus undeclared esmi_{pc6,cc6}_
enable_* and esmi_xgmi_pstate_range_get). Found by building, not by reading.
- Both ::gentoo patches are dropped as upstreamed: the no-git patch is
unnecessary because upstream rewrote the ESMI block to be offline-safe (the
fetch sits behind a src/e_smi.c existence test that our symlinked tarball
satisfies, and the git call behind an .git test a tarball cannot satisfy),
and the libdrm-compat patch is upstream as ROCm/amdsmi PR #165.
- The multilib target_link_libraries sed is dropped: at 10.0 that file has no
absolute path left. Its new anchor assert is what caught it.

Every remaining sed asserts its anchor first, matching the rest of the 10.0
stack. Build-verified as root: libamd_smi.so.27.0.0, the amd-smi CLI and the
python module all install, with no unresolved sonames.