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.

In D41446#944772, @freebsd_igalic.co wrote:

late to the party, but the man page is missing a .Dd update.

The code change here is fairly straightforward and brings netstat in line with similar support in ifconfig and route. The manpage change is larger and it would be nice to get a review if possible. I know people are busy this week preparing for the stable/14 branch - I'll leave the review up for another day. If someone has time to give it a review then great, otherwise I'll commit anyway and we can fix any manpage issues as followups.

In D41439#943930, @ehem_freebsd_m5p.com wrote:

This looks plausible. Likely it mostly amounts to a debugging tool since you would basically never want this in anything approximating a real world situation.

Would there be any objection to me merging this change and the related change in D40377 to stable/13? It would make setting up container networking for containerd and nerdctl much simpler. For podman, it could also make networking more efficient - we currently use two jails per container with one solely used to own the container vnet while also allowing access to host networking tools.