commit 31fc1eb337707e0073ffcae6e58972edc8912be0
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 30 22:35:16 2026 +0200

dev-libs/rocdbgapi: new package, forked for ROCm 10.0

::gentoo stops at 7.2.0, and this one RDEPENDs on dev-libs/rocm-comgr:$
-- a RUNTIME subslot pin, so an installed 7.2.0 keeps the entire 7.2 closure
alive and makes the 10.0 stack unresolvable for @world. Unlike the amdsmi case
this blocks immediately rather than only on rebuild, because the pin is in
RDEPEND rather than DEPEND.

It is also not droppable: dev-debug/gdb pulls it in for AMD GPU debugging, so
"remove it from @world" would take gdb's GPU support with it. Forking is the
only fix that keeps both.

Resolver-verified rather than argued:
[ebuild U ] dev-libs/rocdbgapi-10.0.0:0/10.0::stuff [7.2.0:0/7.2::gentoo]
exit 0, no rocm-core/rocm-comgr downgrade.

Same SRC_URI shape as dev-util/roctracer and dev-util/amdsmi: AMD retired the
rocm-* line at 7.2.4, so 10.0 ships as the rocdbgapi.tar.gz asset on the
rocm-systems therock-<major.minor> release.

::gentoo's rocdbgapi-6.3.0-fix-libcxx.patch is deliberately not forked in --
its own 7.2.0 ebuild declares no PATCHES at all, so that file is stale in
::gentoo rather than something 10.0 made obsolete (checked, not assumed).

Every src_prepare substitution asserts its anchor first, matching the rest of
the 10.0 stack; three of the four decide install paths, which is the quietest
way for a silent sed no-op to go wrong. Build-verified as root:
librocm-dbgapi.so.0.80.0.

commit 8a7082f1ba65632398134de525d263330415ac96
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Dec 6 21:51:11 2025 +0100

*/*: drop rocm/hip as newer version is in main tree

Signed-off-by: Ivan S. Titov <iohann.s.titov@gmail.com>

commit cfa997ed467a25f0a98e30e69523013fb12b4136
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Oct 18 14:26:09 2025 +0200

added rocm and HIP v. 6.4.4 for now, as main tree lags