On Feb 27, 2026, at 7:48 PM, Kurt Miller <lists@intricatesoftware.com> wrote:
>
> On Feb 26, 2026, at 3:28 PM, Mikolaj Kucharski <mikolaj@kucharski.name> wrote:
>>
>> Hi.
>>
>> I would need help with this. I don't know Java ecosystem and I'm stuck
>> with multiple details. Each port has TODO file in it and also XXX or
>> FIXME markers inside.
>>
>> My main problem is, gradle or maven download files from the Internet
>> during build and I added facility based on Makefile from security/ghidra
>> to create deps tarball, but still some depds are missing and --offline
>> build fails with missing deps.
>>
>> There are also many hardcoded or duplicated files across the ports, as I
>> didn't manage to look into that part yet. I also don't know exactly how
>> to unhardcode things there.
>>
>> With attached dirty ports I have working signal-cli as a deamon and
>> I can communicate with it, which I'm supper happy about. I would
>> like to make signal-cli into the ports tree.
>>
>>
>> Attached tarball with following:
>>
>>
>> $ pkg_info signal-cli
>> Information for inst:signal-cli-0.13.24
>>
>> Comment:
>> command-line and D-Bus interface for Signal
>>
>> Description:
>> signal-cli is a command-line interface for libsignal-service-java. It supports
>> registering, verifying, sending and receiving messages. To be able to link to
>> an existing Signal-Android/signal-cli instance, signal-cli uses a patched
>> libsignal-service-java, because libsignal-service-java does not yet support
>> provisioning as a slave device. For registering you need a phone number where
>> you can receive SMS or incoming calls. signal-cli is primarily intended to be
>> used on servers to notify admins of important events. For this use-case, it has
>> a dbus interface, that can be used to send messages from any programming
>> language that has dbus bindings.
>>
>> Maintainer: The OpenBSD ports mailing-list <ports@openbsd.org>
>>
>> WWW: https://github.com/AsamK/signal-cli
>>
>>
>> $ pkg_info libsignal-client
>> Information for inst:libsignal-client-0.87.4
>>
>> Comment:
>> client library for the Signal Protocol
>>
>> Required by:
>> signal-cli-0.13.24
>>
>> Description:
>> libsignal-client is an implementation of the Signal client
>> protocol in Rust.
>>
>> It is under heavy development at the moment and subject to change
>> without notice. Its use outside Signal is not yet recommended.
>>
>> This package also includes Java bindings.
>>
>> Maintainer: The OpenBSD ports mailing-list <ports@openbsd.org>
>>
>> WWW: https://github.com/signalapp/libsignal
>>
>>
>> $ pkg_info sqlite-jdbc
>> Information for inst:sqlite-jdbc-3.51.2.0
>>
>> Comment:
>> JDBC driver for SQLite
>>
>> Required by:
>> signal-cli-0.13.24
>>
>> Description:
>> SQLite JDBC is a library for accessing and creating SQLite
>> database files in Java.
>>
>> Maintainer: The OpenBSD ports mailing-list <ports@openbsd.org>
>>
>> WWW: https://github.com/xerial/sqlite-jdbc
>>
>
> I looked quickly at your sqlite-jdbc Makefile and would suggest
> using a maven port as an example for inspiration such as net/jitsi/jicofo.
> In particular look at:
>
> MAVEN_REPO= -Dmaven.repo.local=${WRKDIR}/m2
>
> for how to get maven to avoid using home. In ghidra I was forced to
> do JDK_JAVA_OPTIONS="-Duser.home='${WRKSRC}/home'" for reasons specific
> to ghidra and probably should only be used as a last resort.
>
> If you are have having trouble building a complete ${WRKDIR}/m2 for a
> suplemental distfile I would be sure to delete ${HOME}/.m2 first to
> ensure maven is not picking up some of the depends from your local
> user maven cache.
>
> I'm going to be pressed for time to help more for the next week or
> two. Hopefully this will help enough to point you in the right
> direction.
I found some time to work on sqlite-jdbc. I made too many changes to
list all of them. Perhaps do a diff to your version to see all of the
changes.
Here are some highlights:
* This port has neither a build depend or run depend on sqlite3 in
ports. It builds its own copy into the libsqlitejdbc.so <http://libsqlitejdbc.so/> shared lib
inside the jar file. I have confirmed that via ktrace of make test.
It is fully self contained and may diverge in version numbers from
databases/sqlite3.
* There is no need to install libsqlitejdbc.so <http://libsqlitejdbc.so/> separately from the
jar file. It is inside the jar and java can find and use it there.
* The convention on OpenBSD is to install single jar's like this
into ${MODJAVA_JAR_DIR} unversioned. Your other ports that use
this need to adapt to the new location and unversioned jar.
* This is a MODJAVA_VER 11+ port and has been tested and passes
make test on aarch64, amd64, i386, sparc64. The all pass as follows:
Tests run: 451, Failures: 0, Errors: 0, Skipped: 8
When your other ports that use this are ready for the ports tree,
I believe this one is fully baked and ready. I would add it now
but I don't like having ports like this unless they are in use
as a depend of something useful.
For your other ports I will also recommend removing
JDK_JAVA_OPTIONS="-Duser.home=${WRKSRC}/home/gradle" and only
use as a last resort. In ghidra, there was java code outside
of gradle that was writing log files to a sub-directory in
${HOME}. That code could have been patched to write into
@{WRKSRC} but then I would have needed to verify if if the
code was only used in the building and not installed with
the port. The -g option for gradle should be enough to keep
it from using ${HOME}.
Also be sure your ${HOME}/.gradle cache is deleted before
trying to make a full set of depends for --offline.
Best,
-Kurt
No comments:
Post a Comment