LGTM

Looks good. The web UI isn't allowing me to mark this as accepted for some reason but I'll merge it anyway.

In D41844#992483, @val_packett.cool wrote:

In D41844#992328, @editor_callfortesting.org wrote:

Can we land this without an aggressive MFC and test in CURRENT before the review goes stale?

+1. Will be a lot easier for me to submit my patches then. With those, it almost works well enough for me, the only thing missing is mmap'ed writes.

Rebase, update version to 6.5.0

Looks good to me.

Looks good, thanks!

Rebase

Rebase, update podman to 4.8.3

In D43121#988088, @dch wrote:

not sure what's missing but this fails on arm64. BTW if it helps I have one you can borrow as needed.

===>   buildah-1.33.2 depends on shared library: libgpgme.so - found (/usr/local/lib/libgpgme.so)
===>   Returning to build of buildah-1.33.2
===========================================================================
=======================<phase: configure      >============================
===== env: NO_DEPENDS=yes USER=dch UID=1002 GID=0
===>  Configuring for buildah-1.33.2
===========================================================================
=======================<phase: build          >============================
===== env: NO_DEPENDS=yes USER=dch UID=1002 GID=0
===>  Building for buildah-1.33.2
gmake[1]: Entering directory '/wrkdirs/usr/ports/sysutils/buildah/work/buildah-1.33.2'
gmake[1]: git: No such file or directory
rm -f internal/mkcw/embed/entrypoint.gz
gzip -k internal/mkcw/embed/entrypoint
gzip: can't stat: internal/mkcw/embed/entrypoint: No such file or directory
gmake[1]: *** [Makefile:86: internal/mkcw/embed/entrypoint.gz] Error 1
gmake[1]: Leaving directory '/wrkdirs/usr/ports/sysutils/buildah/work/buildah-1.33.2'
*** Error code 1

Looks good to me - the paragraphs I edited may need reformatting since I probably didn't estimate the 72 column mark consistently.

Fix for devel/bazel5 is merged in D42729. I will make a new diff for fixing devel/bazel which will also update to the current release version, 6.4.0.

In D41873#975105, @dfr wrote:

In D41873#975104, @manu wrote:

In D41873#975103, @dfr wrote:

In D41873#975075, @manu wrote:

I think that the question is should we have a FreeBSD-sh package or not.

I really like the idea of a FreeBSD-sh package - it covers what I'm trying to achieve here and avoids breaking up the carefully curated set of libs in runtime. We would have to be careful about upgrades to try to avoid leaving systems without /bin/sh.

There is always FreeBSD-rescue in case sh fails to upgrade

Good point. I will abandon this review and make one to add FreeBSD-sh.

In D41873#975104, @manu wrote:

In D41873#975103, @dfr wrote:

In D41873#975075, @manu wrote:

I think that the question is should we have a FreeBSD-sh package or not.

I really like the idea of a FreeBSD-sh package - it covers what I'm trying to achieve here and avoids breaking up the carefully curated set of libs in runtime. We would have to be careful about upgrades to try to avoid leaving systems without /bin/sh.

There is always FreeBSD-rescue in case sh fails to upgrade

In D41873#975075, @manu wrote:

I think that the question is should we have a FreeBSD-sh package or not.

Rebased, addressed most of kib@'s comments.

Looks good

Looks good to me.

Friendly ping - these ports are still broken on FreeBSD-14.0-RC4 which is a problem for me since I use bazel a lot and I want to be able to upgrade my home lab systems to FreeBSD-14.

In D41844#965693, @editor_callfortesting.org wrote:

Is there any assistance, short of time, that you could use from the community to help this along?

Perhaps just remove the dependency from caroot to certctl entirely?

That's what I was asking myself earlier but the problem with this approch is that if you pkg install FreeBSD-\* (or something like that) nothing guaranty that caroot will be installed before certctl and you have a non fonctional installation because certctl wasn't run.

I'm lost, what would caroot contain then ?

In D42095#960999, @des wrote:

In D42095#960934, @dfr wrote:

My goal with the previous change (hash 1d7ffb3) was to be able to install the caroot files in an empty chroot. This can be used as a base container image for statically linked SSL workloads.

You'd still need to hash them. So a better solution is to modify certctl to copy instead of symlinking, and just run certctl -D /path/to/jail without installing anything.

My goal with the previous change (hash 1d7ffb3) was to be able to install the caroot files in an empty chroot. This can be used as a base container image for statically linked SSL workloads. The other change in that commit to separate out openssl libs allows for a similar (but slightly larger) base image for dynamically linked SSL workloads. When building these images, I use the build host's certctl with DESTDIR set to generate the contents of $chroot/etc/ssl.

I'll land it shortly - I also plan to merge it to stable/14 and stable/13. I'll see what re@ thinks about releng/14.0.

Rebase, remove $FreeBSD$

Document the change to MANSPLITPKG

In D41844#953737, @arichardson wrote:

Thanks for working on this - I also tried to get it to work a few years ago but didn't get too far. It looks like this includes the fix to the uninitialized variable that I ran into (https://github.com/arichardson/cheribsd/commits/virtfs-cheribsd) so I think all of my fixes from back then are included.

In D41844#953727, @jrtc27 wrote:

Is there a reason why you use p9fs in a bunch of places rather than 9pfs? It’s called 9P not P9.