As as user, I found this man page very helpful and was able to set up my iwx interface using the information presented here. I actually did not know that iwx was in the tree because I didn't see a man page for it, until I saw a link to https://people.freebsd.org/~ziaee/tmp/iwx.4.pdf

In D49995#1140411, @kp wrote:

In D49995#1140390, @guest-patmaddox wrote:

In D49995#1140226, @kp wrote:

I'm very happy to see this work, not so much for the performance improvement (although we're not going to say no to that!), but because users keep getting caught out when they assign addresses to bridge member interfaces. That breaks multicast, for example, which is bad for IPv4 and catastrophic for IPv6. This has been documented for a long time, but users keep doing it anyway. Making it impossible will save a lot of frustration.

Where is this currently documented? In if_bridge(4) the only somewhat-related part I see is:

https://docs.freebsd.org/en/books/handbook/advanced-networking/
"If the bridge host needs an IP address, set it on the bridge interface, not on the member interfaces."

That should probably be a bit more prominent, but actually making incorrect configuration impossible is a better solution than documenting the pitfalls in a bigger font.

In D49995#1140226, @kp wrote:

I'm very happy to see this work, not so much for the performance improvement (although we're not going to say no to that!), but because users keep getting caught out when they assign addresses to bridge member interfaces. That breaks multicast, for example, which is bad for IPv4 and catastrophic for IPv6. This has been documented for a long time, but users keep doing it anyway. Making it impossible will save a lot of frustration.

Maintain the make clean and rm -Rf. Simply run chflags first so no warnings are emitted in make clean due to schg files.

In D49775#1138257, @imp wrote:

DESTDIR used to be completely deleted. Now that is gone and the dirs remain since make clean doesn't remove those, right?

I have reviewed https://reviews.freebsd.org/D11905 which originally only ran @cd ${.CURDIR} && ${MAKE} clean. I have updated the comment to what I believe more clearly describes the intent of the separate aftercheck target.

It's still misspelled :) The correct spelling is "Equivalent" (I realize now that my inline comment / code suggestion did not come through the email so it may not have been obvious)

LGTM

As @ngie pointed out, I think the ratio is confusing. For reference, here are how Elixir and RSpec (Ruby) report a test run including skips:

I'm moving this work to https://github.com/freebsd/freebsd-src/pull/1550 where I'm more comfortable working with small commits, and it seems like GitHub is preferred for outside contributors.

Remove additional sources of non-determinism:

Update reproducible.sh to build a clean tree and env

Well, I sure made a major miscalculation... buildworld buildkernel has to be reproducible first :facepalm:

Added some notes to potential reviewers. Done for now, until I get feedback.

• add reproducible.sh to demonstrate usage
• edit release(7) language

Updated release(7). I'd like feedback on content before I get into the nitty-gritty of formatting.

• fix mtree link entry
• verify schg
• do not apply file time when WITHOUT_REPRODUCIBLE_BUILD
• apply for all dist files when run as root

I have wanted a utility that does exactly this. install -C does something similar, but has other stuff I don’t want. So far I just end up scripting cmp(1) to do the check.

I suggest we start with a switch which enables the new solution. That means it does not break stuff for people who upgrade.

In D38826#887279, @dvl wrote:

All jails.conf jail (in /etc/jail.conf, /etc/jail.*.conf and /etc/jail.conf.d/*.conf) start automatically, without the need to define them in jail_list in rc.conf

That will require an UPDATING notice.

AND: perhap a switch[es] to preserve the old behavior and if set, enable the new behavior.

This is my first attempt at a code contribution to FreeBSD... hopefully I'm going about it the right way.