commit 174c1273a922d662f22f58abb3e94c40648c9bf5
Author: Andrew Udvare <audvare@gmail.com>
Date: Wed Sep 16 10:22:50 2026 -0400

dev-util/ghidra-gamecube-loader: drop the version from patch filenames

PATCHES referenced $/$-..., which interpolates the current
version, so the next bump silently repoints it at files that do not exist and
only fails once src_prepare runs. Name the patches after $ instead.

Signed-off-by: Andrew Udvare <audvare@gmail.com>

commit c9b02340cf10377e7a3e6e02e83e74dbedb109ab
Author: Andrew Udvare <audvare@gmail.com>
Date: Mon Sep 14 14:04:37 2026 -0400

dev-util/ghidra-gamecube-loader: apply the patch once

src_prepare ran eapply over PATCHES and then called
ghidra-extension_src_prepare, which applies them as well. The second
run failed and took the prepare phase with it, so the package could not
be built at all. The eclass covers PATCHES on its own.

Signed-off-by: Andrew Udvare <audvare@gmail.com>

commit af21db41f0682b3ad3a7da64c0fc8cab77436d4d
Author: Andrew Udvare <audvare@gmail.com>
Date: Fri Sep 11 14:02:27 2026 -0400

dev-util/ghidra-gamecube-loader: new package, add 1.3.1

Built from upstream's sources with the load spec hijack patch that was
previously applied by hand out of tree, with the result uploaded to the
__distfiles__ release. The build pulled org.lz4:lz4-java from Maven Central,
which is what kept it out of Portage; dev-java/lz4-java provides the same jar,
so it is compiled against that and the jar is copied into the extension's lib/
where Ghidra picks it up, as upstream's archive does with its own copy.

The loader jar is identical to the one that archive contained, and it is now
compiled against both the installed Ghidra and the lz4 it will actually run
with rather than the versions upstream's CI picked.

Signed-off-by: Andrew Udvare <audvare@gmail.com>