In D54182#1239946, @kiwi wrote:

I think this is same issues we have with samba and sssd2.
In fact building tools with krb5 enabled per default should not be a good idea, because there is several way to acheive that and for some users they may not need this.

In D54182#1239024, @timur wrote:

The question is what problem are you trying to tackle. Chasing the software versions was never the good practice, IMHO, but see yourself.

The root of the problem here is the fact that maintainer of the dns/bind-tools doesn't want to enable krb5 support by default, so we don't have OOTB solution for the signed DNS updates in the AD configuration. This port was trying to close that gap, providing Samba AD, installable from the packages, without the need for building it separately.

This doesn't look like and adequate replacement:

====> GSSAPI Security API support: you have to select exactly one of them
     GSSAPI_BASE=off: Using Heimdal in base (nsupdate is broken)
     GSSAPI_HEIMDAL=off: Using security/heimdal (nsupdate is broken)
     GSSAPI_MIT=off: Using security/krb5
     GSSAPI_NONE=on: Disable

Again, it could be that with the current state of Samba it's (almost) impossible to retain AD functionality and we should concentrate only on the basic fileserver with ability to join AD domain.

Then we can drop a lot of patches, dependencies and this port all together.

I removed all committers from reviewers because most of us cannot contribute here.

In D52303#1235851, @jrtc27 wrote:

In D52303#1235848, @michaelo wrote:

In D52303#1235845, @jrtc27 wrote:

All these messages exist for humans to read, so why are we changing it to a less-human-readable format?

You consider a mess endian format easier to read with RFC timezones people need to look up? Can you enumarate all of them? Have you read my previous message? I am not printing seconds since epoch.

Yes, I read your message, I had forgotten some of the context when revisiting this. YYYY-MM-DDTHH:mm:ss+TZ is not human-friendly, it's a big mess of numbers that's way too information-dense.

A few more issues and note the nss/WINDOWS deletion.

In D52303#1235845, @jrtc27 wrote:

All these messages exist for humans to read, so why are we changing it to a less-human-readable format?

@emaste done as requested. It is only build now:

root@deblndw013x10v:~
# grep 2025- buildworld kernel installworld
buildworld:>>> World build started on 2025-12-05T13:46:35+01:00
buildworld:>>> World build completed on 2025-12-05T17:28:39+01:00
kernel:>>> Kernel build for GENERIC started on 2025-12-05T17:44:37+01:00
kernel:>>> Kernel build for GENERIC completed on 2025-12-05T18:14:43+01:00
kernel:>>> Install check kernel started on 2025-12-05T18:14:44+01:00
kernel:>>> Installing kernel GENERIC on 2025-12-05T18:14:44+01:00
kernel:>>> Installing kernel GENERIC completed on 2025-12-05T18:15:26+01:00
installworld:make[1]: /usr/obj/root/freebsd-src/amd64.amd64/toolchain-metadata.mk:1: Using cached toolchain metadata from build at deblndw013x10v.innomotics.net on 2025-12-05T13:52:04+01:00
installworld:>>> Install check world started on 2025-12-05T18:16:07+01:00
installworld:>>> Installing everything started on 2025-12-05T18:16:32+01:00
installworld:make[3]: /usr/obj/root/freebsd-src/amd64.amd64/toolchain-metadata.mk:1: Using cached toolchain metadata from build at deblndw013x10v.innomotics.net on 2025-12-05T13:52:04+01:00
installworld:>>> Installing everything completed on 2025-12-05T18:24:54+01:00
root@deblndw013x10v:~
# uname -a
FreeBSD deblndw013x10v.innomotics.net 16.0-CURRENT FreeBSD 16.0-CURRENT #1 use-iso-8601-build-n282325-56b9c752e8d6: Fri Dec  5 18:14:04 CET 2025     root@deblndw013x10v.innomotics.net:/usr/obj/root/freebsd-src/amd64.amd64/sys/GENERIC amd64

Merged.

A few more notes:

• Autofirma.js: You should create a package install message to tell how to install this with Firefox AND you have to fix the path in it
• usr/bin/autofirma: It is completely unusable on FreeBSD: shebang wrong, path to JAR wrong, eventually path to java should be absolute and maybe not rely on PATH
• autofirma.jar\nss\WINDOWS: is large and can be completely wiped
• afirma.desktop: completely unpatched:

Exec=/usr/bin/autofirma %u
Icon=/usr/lib/Autofirma/Autofirma.png

• What happened to the env var to NSS?

In D52303#1235058, @jrtc27 wrote:

I believe the right thing to do is just set LC_ALL=C in the places where it matters. Seconds since epoch is a horrible format to put in human-readable strings. Most of the existing uses of date already set LC_ALL=C, either explicitly for that command or implicitly from earlier in the script (such as both newvers.sh).

@jrtc27 Have you checked what concerned you?

Does not apply for me:

osipovmi@deblndw011x:~/var/Projekte/freebsd/ports (bastille-1.2.0)
$ git arc patch -c D54012
 INFO  Base commit is not in local repository; trying to fetch.
Prüfe Patch sysutils/bastille/pkg-descr...
Prüfe Patch sysutils/bastille/distinfo...
Prüfe Patch sysutils/bastille/Makefile...
Fehler: bei der Suche nach:
PORTNAME=      bastille
DISTVERSION=   1.1.2.251119
CATEGORIES=    sysutils
MAINTAINER=    jdhurtado@orbiware.com
# co-maintainer: snarfingcode666@gmail.com

I have checked https://github.com/BastilleBSD/bastille/compare/1.1.2.251119...1.1.3.251130. The diff is so big that I think that this is much more than a bugfix release. It should have been 1.2.0, IMHO.

In D53807#1232338, @fernape wrote:

Is there anything else that needs to be done here at the moment?

@vishwin Have you had time to check the updated patch? The distutils approach is now behind a switch, being an opt-in.

Remove obsolete patch

rebase onto main

In D53807#1230956, @fernape wrote:

autofirma.jar contains directories linux/windows/osx (sic!) with a binary-bundled certutil, I bet this is libnss3-tools and maybe need to provide certutil.

I don't know the use of that. At least for my simple use (either stand alone or via web) it works fine for me.

I would at least strip all of those foreign binaries from the JAR since they bloat the package w/o any benefit.

I did not inspect the .jar files internally. In orther to do that, I assume I should unpack it and repack the .jar with only the relevant files?

In D53807#1230948, @fernape wrote:

In D53807#1230515, @michaelo wrote:

This port made me curious, though I don't live in Spain:

• Why the hell did they pack a deb package in a ZIP file, clowns
• The data.tar has some interesting things you like have missed:
  • Autofirma.js is for Firefox which will autoinject into prefs.js, it is user.js for Autofirma. You didn't handle this at all. It contains also a path which needs to be fixed for LOCALBASE

Do I need to? The file is packed in case someone wants to install it in his/her home preferences.

This port made me curious, though I don't live in Spain:

• Why the hell did they pack a deb package in a ZIP file, clowns
• The data.tar has some interesting things you like have missed:
  • Autofirma.js is for Firefox which will autoinject into prefs.js, it is user.js for Autofirma. You didn't handle this at all. It contains also a path which needs to be fixed for LOCALBASE
  • What happened to autofirmaConfigurador.jar?
  • Autofirma.png is located next to the JAR, will it be found in a different location?
  • You did not patch afirma.desktop
  • es.gob.afirma.metainfo.xml isn't required? ...and it clearly states that is depends on libnss3-tools

Out of curiousity, since I see Mozilla and NSS here, does the library internally use NSS for something? Does it perform System#loadLibrary()? If yes, you might want to depend on NSS as well. Maybe you should investigate...

In D46236#1225446, @mandree wrote:

How many years is this going to take?

Rework to "git describe --tags"

In D53837#1230021, @driesm wrote:

@michaelo, I rather we keep the bellow fields. You can get them from using git describe --tags.

DISTVERSION= 1.6.2-34
DISTVERSIONSUFFIX= -g73b127

In D53837#1230008, @driesm wrote:

So when I'm understanding correctly, we switch to the ISO timestamp forever.
And in the future when the -devel and normal port diverge more, we use the commit hash and update the iso timestamp to the commit hash in question?

Seems fine for me.

In D53837#1230006, @driesm wrote:

So if we return to using a commit hash, it keeps working with versioning, then it seems reasonable to me.

In D53837#1229977, @meta wrote:

I still want to use DISTVERSION=1.7.0 and not overwrite the version in post-patch. Because the commit e2ebcea and the tag v1.7.0 are identical, and point to the same commit. At this point, the tarball can be shared between vm-bhyve and vm-bhyve-devel. There is no need to keep tarballs with different checksums in distfiles when their contents are identical.

However, this version is now acceptable to me. Feel free to land if it looks good to @driesm.

Update distname and tag name according to Porter's Handbook: https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github-ex2

In D53833#1229951, @driesm wrote:

Sounds good, go for it!! Lets MFQ the -devel port as @meta suggested.

In D53833#1229926, @meta wrote:

I think we can update sysutils/vm-bhyve-devel to 1.7.0 as well. Both are currently at the same version since only a few commits have been added after the release.

If we update the quarterly branch as well, how about updating sysutils/vm-bhyve-devel in 2025Q4 and keeping sysutils/vm-bhyve as it is until the next quarter? This is just a suggestion, though.

Sync with vm-bhyve-devel

In D53813#1229885, @adrian wrote:

In D53813#1229884, @michaelo wrote:

Isn't it better not to have a driver at all rather than having one which is six years old, a preview and heck knows working at all reasonably?

no?

We can always delete it and replace it with another if it doesn't pan out but people have the hardware now and we should have something.

Isn't it better not to have a driver at all rather than having one which is six years old, a preview and heck knows working at all reasonably?

Maintainer, any objection?

Maintainer, any objection?

Just experienced the inconsistency with distutils myself:

In D53766#1228004, @yuri wrote:

I am sorry that I didn't notice this review.

Maintainer has ignored my review and updated the port.

It took me countless hours, but these do build:

archivers/py-cramjam chinese/py-rjieba databases/py-datafusion databases/py-sqlglotrs databases/py-sqloxide devel/py-tox-toml-fmt devel/py-deptry devel/py-qcs-sdk-python devel/py-regress devel/py-rpds-py devel/py-ruff devel/py-pyperscan devel/py-pyproject-fmt-rust devel/py-jellyfish devel/py-orjson devel/py-pendulum devel/py-pydantic-core devel/py-pyproject-fmt devel/py-ty devel/py-watchfiles devel/py-pycrdt devel/py-dbt-extractor devel/py-ormsgpack devel/py-fastuuid devel/py-uv-build08 lang/py-dhall math/py-clarabel math/py-pcodec misc/py-lazrs misc/py-hf-xet misc/py-polars misc/py-pyqir misc/py-safetensors www/py-adblock www/py-jh2 www/py-nh3 www/py-qh3 www/py-granian www/py-pywry www/py-primp security/py-cryptography textproc/py-pycddl textproc/py-jiter textproc/py-tokenizers textproc/py-textual-speedups x11-fonts/py-shaperglot

In D53687#1226367, @kai wrote:

Please check beforehand whether devel/py-maturin builds on all Tier1 FreeBSD releases (maybe CURRENT as well, if possible) and that the consumers (retrievable e.g. with portgrep -o -s -d py-maturin) also builds fine.
Otherwise, LGTM and thank you very much!

Now use "make cargo-crates"

Recreate crates list

In D53686#1226200, @tagattie wrote:

Hi @michaelo, thanks for an update to the port.

It appears some updates to CARGO_CRATES and distinfo are missing.

Can you update Makefile.crates using make cargo-crates and resubmit the patch?

Thanks!

truss output:

root@135-release-amd64-default-head:/usr/ports/devel/uv # grep /usr/local/etc --color out
read(3,"includedir /usr/local/etc/libmap"...,35) = 35 (0x23)
open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0165) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/local/etc/xdg/uv/uv.toml",0x348e6c167210,0x0) ERR#2 'No such file or directory'
fstatat(AT_FDCWD,"/usr/local/etc/uv/uv.toml",0x348e6c167210,0x0) ERR#2 'No such file or directory'
root@135-release-amd64-default-head:/usr/ports/devel/uv #

Creates file produced by:

awk '/name = / { gsub(/"/, "", $3); name=$3 } /version = / { gsub(/"/, "", $3); print "\t\t" name "-" $3 " \\" }' Cargo.lock | sort -u > ../../Makefile.crates

Manually applied by maintainer.