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.

Use a new variable, LINKTAGS, to make the interface between bsd.lib.mk and bsd.links.mk clearer.

In D41841#953640, @emaste wrote:

I wonder if something like LINKTAGS=dev and then

.if defined(LINKTAGS)
        ${INSTALL_LINK} ${TAG_ARGS:D${TAG_ARGS},${LINKTAGS}} ${DESTDIR}${s} ${DESTDIR}${t}

is more clear?

Remove build-essential, moving its dependencies to clang (except for
clibs-dev as discussed). Also move crt*.o from utilities to clibs-dev to
allow linking programs without needing to install utilities.

On reflection, it seems clear that lld, libcompiler_rt-dev and the new clang-dev are needed for any meaningful use of clang and should probably be dependencies of the FreeBSD-clang package. I would like to keep clibs-dev separate though - clang doesn't require these to be installed, e.g. for embedded development and conversely, clibs-dev could be used with some other compiler. I will remove the metapackage and add new dependencies to clang. This would allow installing a functional toolchain with just 'pkg install FreeBSD-clang FreeBSD-clibs-dev' which seems reasonable.

In D41815#953116, @jrtc27 wrote:

Why doesn’t clang-dev depend on everything you need to build C/C++ binaries?

In D41815#953113, @manu wrote:

I'm not sure about the build-essential meta package, we wanted to avoid adding this kind of package since the begining because we wanted to add the notion of pkg groups (metapackage at the repository level) for this.
Otherwise the rest looks good.

In D41439#946716, @royger wrote:

Would it be simpler to not set IFCAP_LRO in the if_setcapenable() call on create_netdev() if xn_enable_lro is false? I think that way we would avoid exposing feature-gso-tcpv4 on xenstore and you won't need to modify talk_to_backend().

Rebased and simplified based on review feedback.

Any feedback or questions for this would be welcome - I need bazel5 to build to unblock building packages for podman and related ports.