service start|stop epmd fails when flags are provided:

\o/ a long overdue improvement! thanks!

Let's upstream this first and then I can just bump the port.

fix map error

tidy up patch

fix family alignment in rule generation and skip cross-family rules

added in 0e4fb336cba5439a9f7f692df86c87a6dc1519f8

already commited

ETOOMUCHWORK

committed 145f0ec9835c

resolved with patch by 0mp.

dealt with upstream

committed in c472205f33b9e41f1bf8d6818023dfc1b427bc29

dropped

committed

fixed with upstream to avoid new port

committed as cbab6614c1e2 devel/py-condense-json: new port - condenses using replacement strings

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.