@acm thanks your patch handles the web bits already? awesome :-) I'd suggested to @hayzam_gmail.com that he could generate those
directly as part of his own release process.

add acm@ patch to prepare and bundle npm assets

minor tweak to appease poudriere test

NB this is still WIP, we need to add in the typescript UI for embedding still.

picking this up post holidays, it seems:

thanks! are you ok to commit this?

rename 3-headed dog at gates of hell

I like the idea of just publishing these bigger image to mirrors.

which yields:

untested, proposed split. clang / lld / lldb seem intertwined.

woops actually nuke bhyve this time

update after initial feedback, remove a few more hardware-y packages

I'll also remove:

David Chisnall has pointed out the usefulness of having a "kitchen sink" container image.
He's currently doing an article for the FreeBSD Journal, and it would be handy if we can
build a sink for him to put his toys in...

Whichever path is chosen, please align release/tools/oci-image-runtime.conf as well to match FreeBSD-kerberos-lib|FreeBSD-krb5-lib as required, so that the container builds will work.

🚢 it!

use node24

mea culpa, mea culpa! thanks!

{F120959715} perfect, ship it!

updated with changes, thanks.

incorporate diizzy feedback

improve pkg-descr

fixed in d2fd973c7d34

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?