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

dev-util/ghidraorbis: 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 490db0d7b6c107665c17ea92a6fefc7178b5049b
Author: Andrew Udvare <audvare@gmail.com>
Date: Mon Sep 14 13:43:07 2026 -0400

dev-util/ghidraorbis: version scheme to 1.NNN, apply the patch once

Upstream tags builds as 1.0 plus a build number. Portage compares a
component with a leading zero as a string, so 1.096 sorted above
1.0144 and every later build will lose to an older one whenever the
counter gains a digit. Dropping the zero gives 1.96 < 1.144 < 1.1000,
and 1.144 still sorts above the 1.0144 it replaces. The tag is rebuilt
from PV through MY_PV.

src_prepare ran eapply over PATCHES and then called
ghidra-extension_src_prepare, which applies them as well. The exporter
patch went in twice and javac rejected the duplicate
canExportDomainObject, so the package could not be built at all. The
eclass covers PATCHES on its own, so the override is gone.

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

commit efd18e3a93878a351dde8f2a336d21b62fb0a604
Author: Andrew Udvare <audvare@gmail.com>
Date: Mon Sep 14 12:27:52 2026 -0400

dev-util/ghidraorbis: restrict livecheck to release tags

The repository also carries commit hashes as tags, and 3b96037 read as
version 96037, which beat the packaged 1.0144.

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

commit 638f4429cbd28cfbb763353d60d8cbfc15d399e2
Author: Andrew Udvare <audvare@gmail.com>
Date: Fri Sep 11 15:23:57 2026 -0400

dev-util/ghidraorbis: new package, add 1.0144

Built from upstream's sources rather than its prebuilt archive, with a patch
implementing the exporter method Ghidra 12 made abstract. Upstream's archive
does not implement it either, so it was not merely uncompilable against current
Ghidra, it raises an AbstractMethodError when that method is called.

Everything else in the jar matches upstream's archive. That archive also
duplicates the three data files into lib/, which its Gradle build does by
listing the data directory as a runtime dependency; they are loaded with
Application.findDataFileInAnyModule(), which reads data/, so the copies serve
no purpose and are not reproduced.

The patch is marked binary because the file it applies to has CRLF line
endings.

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