Rebase, add Makefile.inc1 change to build it during bootstrap

It looks like these are @dumbbell's from rG:01655b8522ac1 and rG:740be6d75549c so can have just a Jean-Sébastien Pédron copyright I think.

I'd commit the makeman.lua change first (it LGTM) as we want it to be correct regardless of whether we use it by default or not.

For cases where we aren't removing the license boilerplate text (because it has minor additions etc.) the SPDX tag should come first. SDPX comes after the copyright statement if we're omitting the boilerplate.

Yes we might be able to use C23 [[maybe_unused]] in the future but we have a lot of places (headers, code shared with other projects) where we cannot require C23.

It needs to take the target arch into account.

See https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/Process/Utility/FreeBSDSignals.cpp

It seems I had these in my WIP tree as 8 and 9 with a comment LLDB is adding support for sync MTE exception and async MTE reporting.

At some point in the future we should clean up old version support, and move the content here.

There doesn't seem to be a general definition of __maybe_unused in FreeBSD

LGTM. Was added in deb9bfbd5bcea so copyright statement looks good.

Oh, in that case I think it's fine.

This statement is confusing to me. I'm not sure why an upgrade is a downgrade, and why it's safer.

Do newly added tests report failure if sg3_utils is not updated?

How about commenting out the Makefile change for now with a comment about needing newer sg3_utils?

Grammar suggestions

OBE. I'd still like us to provide some more clarity on releases -- right now 15.0 and 14.4 are "Production Releases" with no advice on how to pick one or the other. But the specific issue related to this review is gone.

This arrived in fc32c802158f4e with no prior history. Agree that "network suds" does not make sense, and is not a simple typo for something that would make sense. I see that DragonflyBSD still has this same text, fwiw.

Is this waiting on anything else?

Do we want to leave it as aarch64/Makefile.inc? It seems a bit strange to .include a Makefile.

Or, something along the lines of:

size_t res __maybe_unused;
res = iov_to_buf(...);
assert (res == VTSCSI_IN_HEADER_LEN(q->vsq_sc);

With D55536 landed this review should be closed, right?

tidy up

I think this is sensible. Could this also be achieved via USE_STRICT_TMPPATH? I'd like to see that (eventually) become the default, and we could remove the PATH= setting then.

Agree with @ivy wrt !

It's probably worth bringing in a wholesale update, but if there's a need for this change and the commit is ready and tested we should just go ahead with it.

This seems like a good idea to me; will take a detailed look soon. Patch needs to be rebased.

Will also regenerate src.conf.5

What should we do with it now?

I think the dependencies of this change are good to go in. I like the way this is going, but don't have time to review in depth immediately.
It'd be nice if this review can be split into smaller pieces, but not surprising if there's no way to do so that makes sense.

This LGTM but would like to hear @ivy's thoughts, given the Reported by

I've applied the recent update to my testing tree

I don't see it committed?

9fd978680db649 (Baptiste Daroussin      2024-01-04 15:09:44 +0100 5015) SYSCTL_PROC(_security_jail, OID_AUTO, mlock_allowed,
9fd978680db649 (Baptiste Daroussin      2024-01-04 15:09:44 +0100 5016)     CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_MPSAFE,
9fd978680db649 (Baptiste Daroussin      2024-01-04 15:09:44 +0100 5017)     NULL, PR_ALLOW_MLOCK, sysctl_jail_default_allow, "I",
9fd978680db649 (Baptiste Daroussin      2024-01-04 15:09:44 +0100 5018)     "Processes in jail can lock/unlock physical pages in memory");

Or maybe we can add asprintf_flags or such and incrementally migrate callers?