Hi,
On Fri, Sep 25, 2026 at 1:16 AM Kurt Miller <lists@intricatesoftware.com> wrote:
On Sep 23, 2026, at 3:19 PM, Sebastian Reitenbach <sebastia@l00-bugdead-prods.de> wrote:
>
> Hi,
>
> my /usr/local/share/java looks alike:
>
> total 5344
> drwxr-xr-x 8 root wheel 512 Sep 22 16:58 .
> drwxr-xr-x 246 root wheel 4608 Sep 22 16:58 ..
> drwxr-xr-x 10 root wheel 512 Sep 15 13:43 ghidra
> drwxr-xr-x 5 root wheel 512 Sep 15 14:59 gradle
> drwxr-xr-x 2 root wheel 512 Sep 15 14:59 opencv4
> drwxr-xr-x 2 root wheel 1024 Sep 22 16:51 openjfx
> drwxr-xr-x 2 root wheel 512 Sep 15 21:28 sevenzipjbinding
> -rw-r--r-- 1 root bin 2543583 Sep 22 16:57 sleuthkit-4.15.0.jar
> -rw-r--r-- 1 root bin 142214 Sep 22 16:57 sleuthkit-caseuco-4.15.0.jar
> drwxr-xr-x 2 root wheel 512 Sep 18 21:45 sqlite-jdbc
>
>
> because of examples of ghidra, gradle, opencv4, I did create port dependent subdirs, i.e. openjfx, sevenzipjbinding, sqlite-jdbc.
> Sleuthkit is a bit alienating, but that was where it ended up by default, probably should move it into a sleuthkit subdir as well.
>
>
> Your sqlite-jdbc, puts it into the more general /usr/local/share/java/classes.
> Don't know what's the "standard", but I my gut likes the independent subdirectories by port, but I could also update all my new ports, to store jars in /usr/local/share/java/classes like sqlite-jdbc does.
>
> Any objection to rename it to sqlite-jdbc?
Yes, the convention on OpenBSD for jar’s like this is to install
it in MODJAVA_JAR_DIR unversioned. See jna, protobuf-java,
tanukiwrapper, etc.
>
> Also your version seems to be newer, that the one I picked from the dependencies off of sleuthkit.
>
> In any case, it fails to build:
I have updated it to the latest version, fixed the build errors
and rerolled the maven dependancies. See attached v2.
I have tested this on aarch64/amd64/i386/sparc64 they all report:
[INFO] Tests run: 465, Failures: 0, Errors: 0, Skipped: 8
> But then in autopsy, there's the version hardcoded many times:
You can patch all those places to the unversion jar or copy the
unversioned jar into the version that it expects in a post-extract
makefile target. If the api is stable this will work, if not you
will need to update to the new api with patches. I would try the
copy approach to reduce the set of patches you need to maintain
first.
> With the build.xml It's basically injecting the sqlite-jdbc.jar into the autopsy.jar. And the other xml files are there to tell autopsy, where to find it (If I understand correctly)
> I've no idea, if there would be a switch to tell it to not embed sqlite-jdbc.jar (maybe patch the Core/build.xml to stop copying in the first place?) and rather to include
> the sqlite-jdbc.jar that's available via the port?
You can allow it to embed the sqlite-jdbc.jar into autopsy.jar. The
java ecosystem does not conform with BSD build practices and forcing
it to will spiral into a set of patches you may not want to maintain.
that indeed seems to be the way of least resistant. Embedded into sleuthkit and autopsy that way worked.
The only thing I wonder: you install in /usr/local/share/java/classes, whereas there are other ports, that install in /usr/local/share/java/<portname>, i.e. opencv4.
For openjfx and sevenzipjbinding, I chose the <PORTNAME> subdirectory, but could put them into classes as well.
For autopsy then I have this in the config file:
-J-Djava.library.path=/usr/local/lib/sevenzipjbinding:/usr/local/share/java/opencv4:/usr/local/lib
with everything in classes, it would make it shorter here, but I don't know, would it pick up stuff it won't need?
cheers,
Sebastian
Best,
-Kurt
--
No comments:
Post a Comment