These look good.

In D49967#1237244, @markmi_dsl-only.net wrote:

It turns out that this change looks to have notable port-package build time consequences for at least aarch64 on ampere[123] and on, for example, the Microsoft Dev Kit 2023 that I have access to.
. . .

fix after translation

Good catch! Switch both shell names in that section to manpage links.

fixes after translation

Would it be possible to generate the same bootstrap for arm as for the others? I can give you access to an ARM box if you need.

fix of the first translation.

fixes of first translation.

This feels like it needs a comment somehow, but the earlier comment about APERF/MPERF seem to cover it well enough...

Looks good, but cannot be committed on its own as it would break powerd(8), see comment in D55606.

Fix also in stdext and stdext3

Some suggested changes, looks good.

Looks good.

Move non-POSIX options block in the STANDARDS section.

In D56090#1282965, @ziaee wrote:

The COMPATIBILITY section is a GNU-ism.

Proper cleanup when mcnt = 0

Merged, thanks Artem! I trimmed the commit message title, some git tooling expects it to be under 51 characters, so try and shoot for that when possible.

Thanks for the patch! The mdoc(7) manual explains that it's important to use standardized sections wherever possible to reinforce the idea that people can jump directly to the relevant section. The COMPATIBILITY section is a GNU-ism. Please put this in the STANDARDS section. Other than that, looks good to me!

In D55887#1279151, @thj wrote:

I think we should probably have tests check we do the correct things when we get a jumbogram. If these tests aren't run they don't really help with that.

I don't think the numbering gap is a problem, I'd leave the others alone.

Do you have any history for why these are disabled? I they are from the initial netflix work when the frag vulnerabilities came up?

__ASSUME_ALIGNED could work. __builtin_assume_aligned is broadly supported so I double we even need a fall back.

I like the overall change. I've at most skimmed the makefile bits, but this seems like a move in the right direction.

In D55936#1282780, @imp wrote:

For the UEFI Boot items, there's another pull request that starts to export EFI data to Lua that might be useful... But I've not had time to look closely at both of these.

Looks good to me. Thank you.

Correct grammar.