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?

If you want you can remove the (!<space>IEEE..) spaces but otherwise I am fine by reading through it again.
Like the QOS_MASK_ANY change introduced.

I'll leave the comment here (applies to github as well I would assume):

Sorry. My fault. It seems I was stuck on the change from diff1 to diff2. I'll try to have a look during Sunday. It's after 1AM here.

@cperciva is it currently okay to commit to 14.2R release notes or would that be a problem? I noticed with BETA2 it got expanded.

I think D47173

If you want please address the comments but given none is a logic problem I'll leave it to you.

You need to properly rebase your changes or diff to the right branch. The SPDX Tag or the $FreeBSD$ removal should not be part of a review change here.

Corrrect speelling as pointed out by @mat.

I have no idea where to report all the bugs or unexpected behavior I found during testing but it wasn't pleasant to use the installer again after a decade or so.

I would give this up if D47481 can make it. Will help more cases than just this one as outlined there.

Just leaving this here as this would render some of this logic unneeded (also installer later): https://github.com/freebsd/pkg/issues/2195

Could this also be relevant to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268687 (and possibly others if you search for rtwn on bugzilla)?

remove quotes

@manu I tried and also switched to getopts.

What would you do with -q in the non-'-n' case? Also not print the echos in line (old/new) 115/131 and 120/136 or just leave as-is for now?

I would love feedback from releng on this at this point as BETA2 is approaching soon...

• also guard wifi-firmware with NOPKG
• correct the commands for NO_ROOT installations
• for pkg-stage: check for NO_ROOT and email a loud warning that it is not yet supported though it seems easy to make it work for FreeBSD at this point; move the XXX into the check; this allows me to test build a dvd with NO_ROOT

Yeah, we do all our CheriBSD CI builds on Linux hosts and also support building release media on macOS for ease of local testing. That’s only (mini-)memstick/bootonly/disc1/ftp though, no dvd1 (due to pkg), and no VM images.

Guard pkg invokations by only running them on FreeBSD.

How do we envision a build/install media creation for pkgbase in the future? I would highly assume you'll need to sort that issue somehow anyway.

I can confirm that (with my local repo of only providing the wifi-firmware) they ended up (to my surprise only) on the dvd1.iso (and neither disc1 or especially not the memstick).

I also tried memstick and dvd1; I manually (so far) afterwards ran fwget from the shell (and in case of rtw8x added the tunable to loader.conf) and the system came up fine after a reboot.

Given rtw88 and iwlwifi still have firmware in src.git I ran a test with rtw89 which came up booting disc1 as well.
So this part works.

In D47408#1081453, @emaste wrote:

It's unfortunate there's so much duplication (already) here. Anyway I think this is OK. A comment might be useful although git blame on this file will turn up the reason this is here.