Created attachment 244554 [details] Adds new port, devel/reposilite New port for reposilite [https://reposilite.com], a lightweight repository manager for Maven based artifacts. Very useful since artifactory is now FORBIDDEN.
As you have mentioned that this is your first port, have you ran portlint -abct, portfmt, portclippy? Have you tested this port in poudriere specially on 12.4 i386, 12.4 amd64, 13.2, amd64 and preferably 14.0 SNAPSHOT amd64? Have you tried make index after adding the ports tree? These are the basic checklist any committer will go through before committing so if you can do that before hand it definitely reduces the time required to commit.
(In reply to Muhammad Moinur Rahman from comment #1) No, I've only tested building in poudriere on 13.2. I'll go through the list and fix any problems I might find
Created attachment 244556 [details] Add new port devel/reposilite, fixed portlint issues Fixed issues discovered by portlint
Ran `port test` and fixed all warnings and errors. I get a warning about dependecy not being declared on /usr/local/openjdk11/bin/java, but I'm not sure I need it if I have USE_JAVA and JAVA_VERSION in Makefile? It builds in Poudriere 13.2. It just fetches the jar from upstream, so it's very unlikely that any port specific issues are found on other releases or archs
Will review in the next couple of days if you leave the time for it. Please note that there is also Nexus 2 OSS in the tree for years now.
A few issues: * Makefile: ** Should have: NO_ARCH= yes NO_BUILD= yes NO_TEST= yes ** Empty STRIP isn't necessary ** USE_RC_SUBR=${PORTNAME} ** REPOSILITEUSER?=${PORTNAME} ** I was once told that one should supply the DISTVERSION only and the framework will derive the PORTVERSION automatically * reposilite.in: ** reposilite_run_dir => reposilite_rundir (similar to etcdir= ** reposilite_rundir: should be filtered from the Makefile ** reposilite_user: should be filtered from the Makefile ** reposilite_dir: does not make sense because the JAR cannot be moved, it is mandated by the Makefile (convention) especially because you have hardcoded the JAR name ** Beat me, but where does daemon(8) receive user/group to drop privs? ** Who needs this "export JAVA_HOME=${reposilite_java_home}"? ** reposilite_java_home is not used at all! reposilite_cmd completely ignores it. Totally defeats the purpose ** required_files: Does not make sense to me. Java presence is during build/installation; ${reposilite_config} is never created by you at installation time ** I believe that this is redundant: reposilite_precmd. All required trees should be created at installation time: See https://github.com/michael-o/freebsd-ports/blob/c44ab5af99444359c6baab54143f2ddf8d21d999/devel/nexus2-oss/Makefile#L106-L108 and added to pkg-plist ** This is logically wrong: ${reposilite_dir:="%%DATADIR%%"}. DATADIR is in share for static (!) files installed and used read-only at runtime. It is not a work directory. What you need is ${reposilite_workdir:="%%WORKDIR%%"} where WORKDIR points to /var/reposilite. ** The header comment are partially inconsistent, e.g. rundir. ** folder ==> directory ** reposilite_flags or reposilite_args? Sould be args... ** reposilite_max_mem should be generalized to reposilite_java_opts. Why 32M? Leave it empty since this should be user-configured unless you know better. ** reposilite_cmd: This should not be overwritable, no? Yes, I am picky, but the later you address the issues the more expensive it is going to be. Please have a look at by Nexus 2 port, it separates between etcdir/rundir/workdir and datadir. Should be here as well: https://github.com/michael-o/freebsd-ports/tree/master/devel/nexus2-oss
Created attachment 256953 [details] Patch adding devel/reposilite (In reply to Michael Osipov from comment #6) Hello! I'm hoping to pick this up, I've added an attachment with a patch that I think addresses the issues you pointed out if you would be available to review it. It builds and subsequently runs on 14.2-RELEASE. Cheers, Þorsteinn
(In reply to Þorsteinn from comment #7) Noted, will try to review next week for you. This is a good alternative to fully fledged Nexus server.
(In reply to Michael Osipov from comment #8) Thanks mate! I also have poudriere logs of the build if you'd like.
Going through, first issue: The JAR contains shared objects which are loaded at runtime: * libsqlitejdbc * libjansi * libjnidispatch (JNA) libsqlitejdbc contains a bundled SQLite library which is not desired because only external dependencies guarantee security issues to be addressed in time. Here we need to revive java/sqlitejdbc first, depend on it and strip the .so files from the JARs. A couple of years ago I have upstreamed all necessary changes to libsqlitejdbc to properly dynamically link with FreeBSD. It just works. libjansi.so: In theory we can compile ourselves and I have upstreamed here as well, but since this is a small library and I know the author I am fine with it being bundled. libjnidispatch: We have devel/jna, basically same as for libsqlitejdbc: strip the JAR and runtime depend
I forgot, libconscrypt could also be a problem. Reference: $ tar tzf reposilite-3.5.20-all.jar | grep .so\$ org/sqlite/native/Linux/armv7/libsqlitejdbc.so org/sqlite/native/Linux/arm/libsqlitejdbc.so org/sqlite/native/Linux/x86_64/libsqlitejdbc.so org/sqlite/native/Linux/riscv64/libsqlitejdbc.so org/sqlite/native/Linux/x86/libsqlitejdbc.so org/sqlite/native/Linux/ppc64/libsqlitejdbc.so org/sqlite/native/Linux/armv6/libsqlitejdbc.so org/sqlite/native/Linux/aarch64/libsqlitejdbc.so org/sqlite/native/Linux-Musl/x86_64/libsqlitejdbc.so org/sqlite/native/Linux-Musl/x86/libsqlitejdbc.so org/sqlite/native/Linux-Musl/aarch64/libsqlitejdbc.so org/sqlite/native/FreeBSD/x86_64/libsqlitejdbc.so org/sqlite/native/FreeBSD/x86/libsqlitejdbc.so org/sqlite/native/FreeBSD/aarch64/libsqlitejdbc.so org/sqlite/native/Linux-Android/arm/libsqlitejdbc.so org/sqlite/native/Linux-Android/x86_64/libsqlitejdbc.so org/sqlite/native/Linux-Android/x86/libsqlitejdbc.so org/sqlite/native/Linux-Android/aarch64/libsqlitejdbc.so org/fusesource/jansi/internal/native/FreeBSD/x86/libjansi.so org/fusesource/jansi/internal/native/FreeBSD/x86_64/libjansi.so org/fusesource/jansi/internal/native/Linux/arm/libjansi.so org/fusesource/jansi/internal/native/Linux/arm64/libjansi.so org/fusesource/jansi/internal/native/Linux/armv6/libjansi.so org/fusesource/jansi/internal/native/Linux/armv7/libjansi.so org/fusesource/jansi/internal/native/Linux/ppc64/libjansi.so org/fusesource/jansi/internal/native/Linux/x86/libjansi.so org/fusesource/jansi/internal/native/Linux/x86_64/libjansi.so org/fusesource/jansi/internal/native/Windows/arm64/libjansi.so META-INF/native/libconscrypt_openjdk_jni-linux-x86_64.so com/sun/jna/linux-x86/libjnidispatch.so com/sun/jna/linux-x86-64/libjnidispatch.so com/sun/jna/linux-arm/libjnidispatch.so com/sun/jna/linux-armel/libjnidispatch.so com/sun/jna/linux-aarch64/libjnidispatch.so com/sun/jna/linux-ppc/libjnidispatch.so com/sun/jna/linux-ppc64le/libjnidispatch.so com/sun/jna/linux-mips64el/libjnidispatch.so com/sun/jna/linux-loongarch64/libjnidispatch.so com/sun/jna/linux-s390x/libjnidispatch.so com/sun/jna/linux-riscv64/libjnidispatch.so com/sun/jna/sunos-x86/libjnidispatch.so com/sun/jna/sunos-x86-64/libjnidispatch.so com/sun/jna/sunos-sparc/libjnidispatch.so com/sun/jna/sunos-sparcv9/libjnidispatch.so com/sun/jna/freebsd-x86/libjnidispatch.so com/sun/jna/freebsd-x86-64/libjnidispatch.so com/sun/jna/openbsd-x86/libjnidispatch.so com/sun/jna/openbsd-x86-64/libjnidispatch.so
Some new points: * The configuration.cdn.sample is never provided/marked as real file (without .sample), thus cannot be handled by the pkg system properly during update/deinstall * The JAR should be part of the pkg-plist * The work/rundir should be likely protected, e.g., https://github.com/freebsd/freebsd-ports/blob/11dc3fd02ee2fb8de91ca0e88e0a5c0fe15575a5/devel/nexus2-oss/pkg-plist#L345-L348 and https://github.com/freebsd/freebsd-ports/blob/11dc3fd02ee2fb8de91ca0e88e0a5c0fe15575a5/devel/nexus2-oss/pkg-plist#L1-L15 * ${reposilite_rundir}/${reposilite_workdir} in reposilite.in are never declared/initialized * reposilite.in: has user hardcoded They are likely others as soon as you have patched these.
(In reply to Michael Osipov from comment #10) By stripping the JAR file would we just delete jnidispatch.so and libsqlitejdbc.so, re-pack the JAR file and LIB_DEPEND on devel/jna and java/sqlitejdb? What's involved in reviving java/sqlitejdb and how would we handle that? (In reply to Michael Osipov from comment #11) If we're not bundling libconscrypt, wouldn't it need to be ported as well?
(In reply to Michael Osipov from comment #12) * The configuration.cdn.sample is never provided/marked as real file (without .sample), thus cannot be handled by the pkg system properly during update/deinstall The config file is set up as outlined in the porter's handbook here: https://docs.freebsd.org/en/books/porters-handbook/plist/#plist-config and the @sample macro here: https://docs.freebsd.org/en/books/porters-handbook/plist/#plist-keywords-sample from which I understand that only the .sample file could be given and then it would copy it to the actual config file if one doesn't exist, in a way that doesn't wipe the config on deinstall/update. Am I misunderstanding something and should I be creating it somewhere? * The JAR should be part of the pkg-plist I'll move the JAR from PLIST_FILES+= to the actual pkg-plist file and update the permissions on the directories. * The work/rundir should be likely protected I'll update the permissions accordingly. * ${reposilite_rundir}/${reposilite_workdir} in reposilite.in are never declared/initialized * reposilite.in: has user hardcoded My bad, they were supposed to be %%WORKDIR%% and %%REPOSILITE_USER%%, i'll update that.
(In reply to Þorsteinn from comment #14) Can you provide an updated patch? I'd like to finalize this one next month.
I believe, --token option with some random password should be provided and printed if workdir is empty. Reposilite starts without any users and requires interactive steps. I hope this port will be finished, because artifactory will expire soon.
(In reply to Ivan from comment #16) As said, I waiting for the potential maintainer to address open issues. I need to think about devel/nexus2-oss. Whether I will migrate off or introduce a devel/nexus3-oss port.
I tried stripping the .so files from the jar and running it. It wouldn't start with the version of sqlitejdbc in ports, but I fetched the jar from https://github.com/xerial/sqlite-jdbc and extracted libsqlitejdbc.so and with that reposilite at least starts up. xerial/sqlite-jdbc is in part based on the old sqlitejdbc, but it's not the same project. Is it kosher to migrate java/sqlitejdbc to new upstream, or should we create a new port?
(In reply to Einar Bjarni Halldórsson from comment #18) It is fine to upgrade the port. Please file an issue and wait for the maintainer to react.
Created attachment 260289 [details] Updated This addresses most of the comments from Michael, but not stripping the jar and linking with dynamic libraries from ports. I got it running, but only with sqlite-jdbc .so from github. The current version of sqlitejdbc in ports is too old and updating that port is not something we can spend time on. We can either commit the port as-is or someone else can do the work to strip the jar and link with libraries from ports.
(In reply to Einar Bjarni Halldórsson from comment #20) * Why are the UIDs and GIDs files included? It should only contain a diff. * Let's keep SQLite as-is and add a comment in the Makefile. Honestly, I do not understand at all why they use SQLite instead of H2, HSQLDB or anything else in pure Java to avoid that pain. The problem of the bundled so is that is contains an amalgamation of SQLite instead of using the port...
(In reply to Ivan from comment #16) > I believe, --token option with some random password should be provided and printed if workdir is empty. Reposilite starts without any users and requires interactive steps. Except --token option creates a *TEMPORARY* password. It's deleted as soon as the server shuts down.
(In reply to Michael Osipov from comment #21) > Why are the UIDs and GIDs files included? It should only contain a diff. UIDs and GIDs files are included becuse we're building and running this in production in poudriere using a ports overlay. I'll create another patch that doesn't include the files but has a patch for /UIDs and /GIDs > Let's keep SQLite as-is and add a comment in the Makefile. Honestly, I do not understand at all why they use SQLite instead of H2, HSQLDB or anything else in pure Java to avoid that pain. The problem of the bundled so is that is contains an amalgamation of SQLite instead of using the port... From the sample config: # Database configuration. Supported storage providers: # - mysql localhost:3306 database user password # - sqlite reposilite.db # - sqlite --temporary # Experimental providers (not covered with tests): # - postgresql localhost:5432 database user password # - h2 reposilite
Created attachment 260291 [details] New patch, now includes diff for UIDs and GIDs
(In reply to Michael Osipov from comment #21) Ready for commit?
(In reply to Einar Bjarni Halldórsson from comment #25) I will get back to this next month.
Created attachment 260870 [details] Update reposilite to 3.5.24
Going through now...
Please update the patch: root@deblndw011x:/var/poudriere/ports/default-head (main =) # git apply /tmp/patch /tmp/patch:222: trailing whitespace. # REQUIRE: networking error: patch failed: GIDs:309 error: GIDs: patch does not apply error: patch failed: UIDs:315 error: UIDs: patch does not apply /tmp/patch:212: new blank line at EOF. +
Created attachment 261140 [details] Update UID and GID for reposilite user
Created attachment 261143 [details] New port devel/reposilite New patch, with updated UID and GID
Created attachment 261150 [details] New port devel/reposilite Here is a simplified and updated port which addresses several runtime issues as well. I have found one bug: https://github.com/dzikoysk/reposilite/issues/2418 This one is problematic: https://github.com/dzikoysk/reposilite/blob/46ffce1fd65edbdea907e317df823242157b978e/reposilite-backend/src/main/resources/tinylog.properties#L27-L28, it is not relative to WORKDIR, a design flaw. There is one more open question: Are you concerned about privacy in a multiuser environment? If yes, would you consider this: @dir(%%USER%%,%%GROUP%%,755) %%ETCDIR%% @dir(%%USER%%,%%GROUP%%,750) %%RUNDIR%% @dir(%%USER%%,%%GROUP%%,750) %%LOGDIR%% @dir(%%USER%%,%%GROUP%%,750) %%WORKDIR%% Please take your time and review my changes and comment.
(In reply to Michael Osipov from comment #32) > Here is a simplified and updated port which addresses several runtime issues as well. Looks good. > I have found one bug: https://github.com/dzikoysk/reposilite/issues/2418 Good, hopefully it will get addressed quickly > This one is problematic: https://github.com/dzikoysk/reposilite/blob/46ffce1fd65edbdea907e317df823242157b978e/reposilite-backend/src/main/resources/tinylog.properties#L27-L28, it is not relative to WORKDIR, a design flaw. I see you worked around it with `reposilite_tinylog_config` in the rc script. It looks good. > There is one more open question: Are you concerned about privacy in a multiuser environment? If yes, would you consider this: @dir(%%USER%%,%%GROUP%%,755) %%ETCDIR%% @dir(%%USER%%,%%GROUP%%,750) %%RUNDIR%% @dir(%%USER%%,%%GROUP%%,750) %%LOGDIR%% @dir(%%USER%%,%%GROUP%%,750) %%WORKDIR%% I usually run single purpose VM's or jails, so I'm not very concerned personally, but I think those are sane defaults, and they're easy enough to change if users are so inclined.
There is no issue though which kept me bugging: tinylog. I am convinced that passing the system properties isn't enough. To get full control of logging we should extract the properties file and pass is as sample. Then the admin can fully control it. I will apply the chmod changes to the dirs as well.
Created attachment 261180 [details] New port devel/reposilite Here is an updated version. Works great for me in Poudriere. Please have look. If good, I will open up a review to get a commit approval.
(In reply to Michael Osipov from comment #35) I built it as well in poudriere. Running now, looks good +1
https://reviews.freebsd.org/D50802
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=0b108c81eb38d0b1c2c933dd502c70947376070d commit 0b108c81eb38d0b1c2c933dd502c70947376070d Author: Einar Bjarni Halldórsson <einar@isnic.is> AuthorDate: 2025-06-10 13:24:32 +0000 Commit: Michael Osipov <michaelo@FreeBSD.org> CommitDate: 2025-06-12 08:41:29 +0000 [NEW PORT] devel/reposilite: Lightweight repository manager for Maven based artifacts Co-authored-by: Michael Osipov <michaelo@FreeBSD.org> PR: 273495 Tested by: michaelo Approved by: otis (mentor) Differential Revision: https://reviews.freebsd.org/D50802 GIDs | 2 +- UIDs | 2 +- devel/Makefile | 1 + devel/reposilite/Makefile (new) | 67 ++++++++++++++++++++ devel/reposilite/distinfo (new) | 3 + .../files/configuration.cdn.sample (new) | 71 ++++++++++++++++++++++ devel/reposilite/files/reposilite.in (new) | 64 +++++++++++++++++++ devel/reposilite/pkg-descr (new) | 2 + devel/reposilite/pkg-plist (new) | 9 +++ 9 files changed, 219 insertions(+), 2 deletions(-)
I still would like to know this: > Very useful since artifactory is now FORBIDDEN.