On Feb 27, 2026, at 7:48 PM, Kurt Miller <[email protected]> wrote: > > On Feb 26, 2026, at 3:28 PM, Mikolaj Kucharski <[email protected]> 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 <[email protected]> >> >> 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 <[email protected]> >> >> 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 <[email protected]> >> >> 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
databases.sqlite-jdbc.tgz
Description: Binary data
