In D47682#1087412, @emaste wrote:

LGTM

Can we simplify this eventually and standardize on only the first case?

Thanks for the review; this was based on an earlier attempt to look at release (April this year?) for firmware and trying to figure out how things are put together.
I'll let it sit until at least RC1 is out in case other changes need to be done to avoid conflicts.

Update comment as pointed out by @emaste.

"cleanup" the PKGCMD bits as requested by @jrtc27 .
I have not tested NO_ROOT again.

Implement --pause with a 5 second delay as suggested by @jrtc27.

Remove the bits about the broken NO_ROOT bit.

In D47666#1086828, @dsl wrote:

I can build a kernel with ACPI_DEBUG without any troubles, but my Honeycomb has to be revived. Could you give it a try @phk @bz ?

The wlanconfig change got committed as 5399052c63a7a3d2f54615d31bfd092ab887a600
and the description was locally removed from the commit message.

Unless releng has any objections I'll commit this around Tue 19.11. afternoon UTC.
I would still hope releng to comment on it before if not at least by accepting or requesting changes.

Unless there'll be any comments I'll commit this around Tue 19.11. afternoon UTC

In D47500#1086528, @adrian wrote:

landed

I don't know what your nice 8 core laptop is but again I am also not sure why it matters. Please write a proper commit message.

Can you please write a normal descriptive commit message.

Do we still want this (and the accompanying bsdinstall change) in 14.2-R or not? As otherwise I'll have to add rtw89 firmware at least there.

In case you know anyone else who could review this please add them!

Can this be simplified to simply check if uc_delay_us is > 0? Otherwise from scrolling through uc_write_delay would be a bool or are we expecting more values?

Thank you @cperciva for aligning the templates and re-generating the pages! ( 38b6739c2f3f4168b17b0094b6a7abbe52cfa39b )

In D47272#1084351, @mhorne wrote:

Thank you! Also for the stamp which cheered me up when I saw it :)

I think I should have abandoned it. Not that I love Lua but -X has since done my job, especially since -X can have comments.

If you do not use arc diff --create/--update please upload a diff -U9999 so that there is context to be displayed.

correct spellelelng of make

Generation happened already; I'll need to talk to releng / @cperciva to see if it can be re-generated or if it is too late for 14.2.
I also thought the generation would happen just before the release given it's website/ .

The #ifdef bits probably need to be addressed; the whitespace and punctuation could be optional.

Please don't accept your own revisions. That's implied ;-)

In D47512#1083788, @emaste wrote:

And in that regard inet.4 and the implementation seem to differ.

That's rather unfortunate, and I didn't realize that until a few hours ago when I spotted the text in in draft-schoen-intarea-unicast-240.

In D47512#1083767, @emaste wrote:

In particular, the current state as described in draft-schoen-intarea-unicast-240 seems undesirable:

All known TCP/IP implementations either interoperate properly with
packets with sources or destinations in the 240/4 range, or ignore
these packets entirely, except FreeBSD and NetBSD, which have support
for 240/4 for some purposes while blocking it for others.

With this a recursive check-license passed to the end.

Please don't flip the switch before it's in the IANA list.
That draft (if not updated--and IETF just happened-were there any news?) will expire end of this year.
Even source [2] after all says towards the end "Should you use Class E space? The short version is, Typically no."
Arista and Juniper also treat it as an "supported but opt-in" according to the draft.

• deal with dual-license, single license file (used archivers/p5-Archive-Any as sample as it was the first hit)
• detect collisions with well-known names "lICENSE" and "catalog.mk" (more likely the formware is common) and work around them automatically (if the ports maintainer hasn't done manually)
• make sure PLIST is correct with that

If you want me to build/test the stack of changes let me know; otherwise this one is good to go from me.

Possibly a bit more verbose commit message and Fixes: e4611d26265fb

Abandon on favor of just committed D47481

Can you bump .Dd on all these (I'll also need to do on iwm.4 given I forgot)

In D47380#1083399, @mat wrote:

This looks sound.
I have only run it in my head though.

Have you checked if there are ports where this now gives an error?

@bofh ping6

ACK and insta-MFC to the tagged Quaterly branch as well?

I'll just get this in; we'll have a few days until we'll expand anything from this file again.

In D47481#1083478, @cperciva wrote:

I'm not 100% certain that this is the right way to do "configuration" stuff from within ports, but I don't know enough about ports magic. Hopefully someone with more ports experience can chime in on this soon; if not, go ahead and commit since we need to get this into the tree soon for the release.

I had finished a 14.1 and current poudriere build before submitting also checking plists for both cases (given I had an error in one case in the first run I hope I got it right this time).

Added it to D47481 which needs to bump it for all of the wifi-firmware-<name>-kmod ports anyway.
Saves us from conflicts between the individual ports and the common framework. Seems easier to track it there and always bump there.

Increase PORTREVISION for the introduction of the loader TUNABLE files.

In D47480#1083451, @cperciva wrote:

Needs a FWDRV_VERSION bump?