The comment I suggested is a helpful reminder for whoever does the OpenSSL update. It's not strictly required.

Would this also fix the "your system was restarted due to a problem?" issue I frequently see booting up macOS after rebooting cleanly from FreeBSD?

re: socket.cc: the cleanest way to handle this would probably have been some minor refactoring using a lambda function (the variable names could have remained the same and the captures could have been made explicit), but renaming the variables was easy enough that I think this is the best tradeoff to restore simultaneous root/unprivileged testing post-3fb03fb35b20.

socket.cc: rename variables with VSCode instead of by hand

In D61080#1403905, @markj wrote:

In D61080#1403850, @ngie wrote:

I also hate that I'm doing this manually, but the alternatives cost money and help burn up the planet (ChatGPT, Claude, etc), are not functional (DeepSeek-r2-coder, Mistral), or require a ton more investment doing a one-time task (Coccinelle, clang-tidy). There might be a way to do this with VSCode and a plugin, but that's the only thing I can think of at this point that would do it in an automated manner.

You don't need any of that. Any sane editor makes it easy, no plugins needed. For instance, https://stackoverflow.com/questions/597687/how-to-quickly-change-variable-names-in-vim

... Then I pointed out that the follow-up fix was setting WARNS incorrectly, but that can't be fixed directly for some reason...

• use slightly better names for some of the shadowed variables
• fix bugs with previous revisions around var naming

slight makefile tweak

Set errno = 0 before using getpwnam(3)

.

In D60928#1402098, @des wrote:

In D60928#1401926, @ngie wrote:

Maybe I'm misunderstanding of what you wrote:

The problem that needs solving is that mtree files do not respect build options.

@markj : ready.

Remove WARNS change from this diff

Move WARNS to this review/commit from D61066.

In D60928#1401441, @des wrote:

In D60928#1400324, @ngie wrote:

I don't follow this claim. Have you actually applied the patch and confirmed that it doesn't address the issue you're seeing locally?

I never claimed that it doesn't. Please do me the courtesy of reading and responding to what I actually wrote.

coverage.py runs pytest via a separate script (igor.py). It's probably doing some extra setup/teardown that raw pytest isn't doing (I'm seeing a lot of ImportErrors with a module that exists in the tests directory).

I'll try to look through this diff more in-depth in the next few days. Just one quick comment..

@vishwin : this differential needs to be rebased.

Could the bug addressed here have helped contribute to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=300451 ? I see TCP MTU in the stacktrace running the if_lagg tests, which seems weakly related to this issue.

Shuffle "tests" user resolving off to main(..).