It's a good cleanup, even if it doesn't solve the problem.

In D50339#1148754, @ivy wrote:

In D50339#1148701, @des wrote:

I would prefer fixing the mk scripts, if that's not too much work?

i don't think this is a problem in the mk scripts, the Makefile just wasn't accounting for the fact that the file is in a non-default conf group. unless there's something else to fix here?

Fix Dag-Erling's test in D50296

Implementation looks fine to me; it does make me wish that we'd settle on an appropriate test framework for lua, though. I'd love to have a test that confirms that the argv[0] behavior works as expected (and doesn't, e..g, crash when it's omitted). I don't insist on trying to solve that kind of problem before proceeding here, though... just something to think about.

I do wonder if @jmmv has an opinion, if he still gets/reads phab e-mail there, but I don't see off-hand why atf shouldn't try to function in these kinds of environments.

IMO you don't get the privilege of wearing the hat just because you didn't have a smaller display to test on. I don't think it's unreasonable to expect that we would choose a sensible font with all of these options at hand.

Need to fix the title... should've mentioned NFSv4 ACLs. *sigh*

In D50247#1146172, @imp wrote:

Oh, wait, sighup? That's different...
I think that's there so mail doesn't go into an infinite loop. But that maybe obsolete since the tty driver is now sane

In D50247#1146048, @ivy wrote:

that seems reasonable to me, but did you consider the other places it handles SIGHUP, e.g. collect.c?

In D50241#1146040, @dave_freedave.net wrote:

In D50241#1146027, @ziaee wrote:

Check out https://docs.freebsd.org/en/articles/license-guide/ or style.9 from current, there is a much shorter text you can use now. EDIT: This was for your other review, sorry.

That makes sense as I'm not comfortable changing licenses for existing code. But do you mean I should change for both D50244 and D50245 ? I think I just realized I did the usual thing of copying sys/netgraph/ng_sample.[ch] for creating ng_wormhole.[ch] and it has the "WHISTLE COMMUNICATIONS" disclaimer.

Should I change both to the much shorter text?

In D50247#1146023, @ivy wrote:

In D50247#1146015, @kevans wrote:

I forgot to note that this is a conformance motivated change

can you please link the relevant standard?

I forgot to note that this is a conformance motivated change, but I might need to go reread the spec and see if maybe we should flush then re-raise instead

In D50247#1146012, @imp wrote:

It flushesmore stdio output...
But i don't think that matters these days...
Back in the 80s it helped with debugging lex bugs iirc

Rebase and hit a few more devctl_notify() callers

Tap in bapt, too, since this could slightly change some nlsysevent semantics in more edgey cases.

Rebase past nlsysevent's devctl tap

In D50065#1144517, @glebius wrote:

I'd vote against putting it back. I submitted patch to the port upstream.

LGTM modulo the minor typos noted by @jlduran, but happy enough for those to be fixed pre-commit.

In D49970#1141594, @jhb wrote:

Hmm, isn't this backwards as style(9) requires tabs? Probably not worth swapping back at this point, but maybe avoid future style regressions?

If you're up for it, adding _FORTIFY_SOURCE support for this would be nearly trivial. The __ssp_redirect pattern for arc4random_buf in include/ssp/stdlib.h can be copied for this (the __buf and __len names are significant and used in the implementation for size-checking, other names are fair game) and tests added easily by copying arc4random_buf again in lib/libc/tests/secure/generate-fortify-tests.lua (regeneration requires devel/lua-luacheck for make generate-tests).

Please amend the commit message to point out that this may be worth a COMPILER_FEATURES entry in case it inspires someone to try and add more blocks stuff elsewhere, but it is hard to see the value with this little of proliferation at the moment

On second thought, I'm not so sure this will work anyways... I'd need to finish the sbuf in order to tap out a copy for netlink, since sbuf_data() is only guaranteed to work on a finished sbuf.

Seems reasonable to me, thanks!