Created attachment 265074 [details] Patch LubeLogger is a self-hosted, open source, vehicle maintenance record system and fuel mileage tracker written in .NET. This is my first time submitting to the ports tree. I used the Porters' Handbook and multimedia/jellyfin as a starting point. Any feedback is welcome and appreciated.
Created attachment 267017 [details] Updated patch with newest version Updated to 1.5.6 from project upstream.
Created attachment 268385 [details] Updated patch with newest version This is the latest version I can upgrade to until .NET 10 leaves devel and enters the dotnet package for FreeBSD ports. If someone could look at this and give me feedback or accept it I would appreciate it :)
GH_TAGNAME= v${DISTVERSION} should be omitted in preference of DISTNAMEPREFIX=v There are a lot of ports that follow this scheme and can be used as a reference. The nuget machinery in Ports isn't stabilized yet, so I'm reluctant to merge yet another .NET port without streamlining nuget-based builds. I also don't have time to improve it or to update .NET to 10, so I'm afraid this contribution would have to dwell in Bugzilla a bit more.
Thanks, I can make that change no problem. Oh no, that's really unfortunate about the .NET tooling. I tried to follow the machinery other popular ports, such as Jellyfin, were using as closely as I could. Is there anything I can do to help smooth those processes out?
(In reply to Adam T. Carpenter from comment #4) The most "canonical" NuGen-based port I aware of is shells/powershell. It would help if you redo your port in the powershell's style (your nuget.mk should be similar to powershell's one). There is also an attempt to extract NuGet machinery into a new USES module: https://github.com/freebsd/freebsd-ports/pull/462
Created attachment 269576 [details] Updated patch with better nuget tooling
(In reply to Gleb Popov from comment #5) Alright, this patch has the much nicer shells/powershell nuget tooling. I see why you prefer it to jellyfin's. Thanks for the advice! This installs and runs well, passes portlint and portclippy, and also passes poudriere testport.
Created attachment 269976 [details] lubelogger port jailed Here is my take on this port. I made lubelogger run inside the jail, which allowed to not introduce a new system user. Adam, let me know if you're OK with this patch, so I can merge it.
(In reply to Gleb Popov from comment #8) Thanks for the patch. I use jails extensively on my home server, but I've never used a port which installed and ran in a jail by default (or at least, I didn't realize it). Is this a common pattern with www ports? Are there any concerns with nested/hierarchical jails for users who will want to install this port within a jail to run it? Apologies if I am out of the loop. I like what you have here, just want to understand better.
(In reply to Adam T. Carpenter from comment #9) > Is this a common pattern with www ports? No. The rc-subr-jail thingie used by the rc script to set up the jail is my own invention. It is pretty raw at the moment and is employed by just one other port - net-p2p/cardano-node There is another way to put a service into jail - service jails [1]. It requires about zero involvement from the rc script itself, but the tradeoff is that the jail's root matches the host's root. On other words, there is no isolation on the filesystem layer. On the rc-subr-jail case, the jail root is /var/db/${name}/jail, which gets populated by stuff that is really required for the program to run. > Are there any concerns with nested/hierarchical jails for users who will want to install this port within a jail to run it? I did not consider such a use case, so it might not work. But it also might just work as long as outer jail is created with sufficient capabilities allowed. [1] https://docs.freebsd.org/en/books/handbook/jails/#service-jails
(In reply to Gleb Popov from comment #10) I am testing your patch and I can't seem to get it to build. When I make or use poudriere testport, I get this message. /usr/ports/www/lubelogger/work/lubelog-1.5.9/CarCareTracker.csproj : error NU1301: The local source '/usr/local/poudriere/ports/porting/distfiles/nuget' doesn't exist. I'm pretty sure it's the change to the patch-nuget.config, which now uses an alias %%NUGET_DISTDIR%%. Is there something additional I need to do to make sure this shortcut is compatible? I can debug what that expands to but was curious if you've run into this before.
(In reply to Adam T. Carpenter from comment #11) Not sure how could it be missing, because it is populated by make fetch. How are you running poudriere exactly?
(In reply to Gleb Popov from comment #12) My mistake, please disregard my last comment. I see what I did now and I am able to build and install your patch successfully. Once I built lubelogger, I tried testing this service jail within my existing setup, which is installing the package and running it from within a jail on my host. This does initially fail due to nullfs mount permissions inside the nested jail. mount_nullfs: /var/db/lubelogger/jail/usr/local/share/lubelogger: Operation not permitted mount_nullfs: /var/db/lubelogger/jail/lib: Operation not permitted mount_nullfs: /var/db/lubelogger/jail/libexec: Operation not permitted mount_nullfs: /var/db/lubelogger/jail/usr/lib: Operation not permitted mount_nullfs: /var/db/lubelogger/jail/usr/local/lib: Operation not permitted mount_nullfs: /var/db/lubelogger/jail/usr/local/share/icu: Operation not permitted I'm sure there is a workaround for this, but my understanding was allowing jails to mount nullfs within themselves is not great security. I will try out a couple of workarounds, but my preference may be that this runs as a standard daemon, and then users can opt to install and run this package within a jail, rather than installing the package on their host and using the service jail implicitly. What do you think about that?
(In reply to Adam T. Carpenter from comment #13) If I understand it correctly, you have done some jail setup manually, probably with some tool like iocage or many others. My approach does not require any setup from the user, because jail gets created on the fly. The only reasons I see why your approach might be desired are 1. You want one jail to contain multiple services. 2. You don't want to install packages onto host system. If those are valid reasons for you, I can look into making this auto-jailing functionality optional, just like how it is done for cardano-node.
(In reply to Gleb Popov from comment #14) That is correct, I am using Bastille for jail construction and automation. It's nice because I can also write Bastille files to handle initialization and setup of more complex services. Mostly, it's reason #2 however, and that is isolating the package installs away from the host. It makes it nicer for managing mixed version dependencies and testing upgrades before "promoting" them to production. If it's alright with you I would really appreciate the optional auto-jailing functionality. I see huge benefits to the service jail for some users, and for a native install for others.
Created attachment 270338 [details] Final unjailed version I've gone back to the unjailed version, because my main motivation for jail was to get rid of UIDs/GIDs changes. But now we have to create a new user anyways, so it is easier to drop the jailing stuff rather than trying to make it optional. Adam let me know if this version works for you and if you're OK with it let's finally push this.
(In reply to Gleb Popov from comment #16) Yep, this works well for me. Thank you Gleb, ready to push!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f324263fd8784dbbde36c89bacb7deeee725313b commit f324263fd8784dbbde36c89bacb7deeee725313b Author: Adam T. Carpenter <atc@53hor.net> AuthorDate: 2026-02-27 01:28:32 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2026-05-03 14:18:55 +0000 www/lubelogger: Add new port PR: 290719 Co-authored-by: Gleb Popov <arrowd@FreeBSD.org> GIDs | 2 +- UIDs | 2 +- www/Makefile | 1 + www/lubelogger/Makefile (new) | 69 +++ www/lubelogger/distinfo (new) | 31 ++ www/lubelogger/files/lubelogger.in (new) | 36 ++ www/lubelogger/files/patch-nuget.config (new) | 12 + www/lubelogger/nuget.mk (new) | 17 + www/lubelogger/pkg-descr (new) | 9 + www/lubelogger/pkg-plist (new) | 655 ++++++++++++++++++++++++++ 10 files changed, 832 insertions(+), 2 deletions(-)
Thank you for your contribution.