incorporate 19.x diff

In D50650#1158444, @lwhsu wrote:

I fully agree the biggest and must be solved issue is the license concern, but putting "expressly forbidden" on a tool because of its current limitation is too narrow. I believe the spirit the project is being more inclusive, as long as the contribution can meet the requirements, e.g., the license, quality, convention, etc.

In D50650#1158379, @olivier wrote:

About the documentation, comments in code or commit message: Is using AI to fix my English forbidden too ?

This first sentence was written by non-native-English me, but for documentation or commit message, I might ask the AI to "fix my English," and the AI result will be something like this:

"Am I also prohibited from using AI to correct my English?"

I'm asking because I have dyslexia, which is a serious issue when you need to write in French (where correct writing is mandatory in French culture). Therefore, I'm accustomed to using software to check for all grammar and orthographic errors. However, since these tools are now AI-based, does that mean we can't use them either?

BTW when running this against 14.3-RC1 I needed to add a tiny sleep 3
at the end to accommodate pkg(8) still doing whatever pkg does:

Sorry I managed to be in Germany for the week when this landed...
I did some testing and the ASSUME... stuff is no longer needed AFAICT.

Unless there are major objections we could commit this and tinker later. LGTM, thanks moin!

\o/

I like this article. A lot. No specific feedback, just a general comment - who is the target audience for this?

Per core 2025050 meeting we agreed to proceed with this change.
Thanks all for your well-considered & cordial discussion.
I will amend the doceng to non-blocking, and commit the diff.

In D49757#1147858, @gordon wrote:

I’m not entirely sure what kind of approval from secteam is being sought. If someone in core would like to help me understand what kind of review is expected, I’d be happy to undertake it.

Until then, I don’t want to be the blocker for this otherwise reasonable sounding change.

handle case when var is *not* set and bmake complains about it

as mentioned on my email to re@ this would be handy for the multi-arch
container builds as well as possibly for general reproducible builds.

include bofh recommendations

waiting on doceng internal discussion.

thanks Doug, rebuilding with latest version atm.

LGTM, testing with stable/14 today. thanks Doug for tracking this down & explaining it.

LGTM, had to get past an unrelated panic to test this one :/

added clusteradm or secteam per review of 3rd party dependency.

per discussion in core@ this is OK, but should get an OK from either clusteradm or secteam, due to the 3rd party dependency. Other than that LGTM.

Some context:

{F114065412}

LGTM, maybe you were right and black will be a less jarring colour... needs doc approval for the website.

There are also PRs open for these, phab is simpler for review and a nicer patch mgmt workflow.

incorporate diizzy feedback where appropriate