make.conf:

OPTIONS_UNSET=DOCS NLS
WRKDIRPREFIX=/usr/obj

In D18535#395442, @eugen_grosbein.net wrote:

In D18535#395370, @sobomax wrote:

In D18535#395273, @eugen_grosbein.net wrote:

Yes, it requires corruption of private node memory. As owner of multiple routers mass servicing thousands of customers using multiple NETGRAPH nodes I can assure you that panic is not appropriatie action. Appropriate action is some form of block for traffic flow trough the node in question (with logging) leaving other nodes working.

Well, that's where I respectively disagree. As an owner of hundreds of FreeBSD systems servicing many millions of customers I think that rebooting the system immediately after any slight kernel heap/stack memory corruption is detected is not just appropriate but the only sane action available. Shutting down particular netgraph node and hope for the best would just leave the service down indefinitely with no hope for any sorts of automatic recovery.

Node destruction and recreation is easily implemented automatic recovery. We obviously have different usage patterns. I use net/mpd5 that can use ng_nat connecting it to the session that can be destroyed and re-created by any of "client" or "server" recovering from corruption and not interfering with other sessions. Other usage patterns can react on such event to re-create nodes too.

int ret; rather than uint*_t ret;

In D18546#395445, @eugen_grosbein.net wrote:

Hmm, there was https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229432 and corresponding commit https://svnweb.freebsd.org/base?view=revision&revision=336195 fixing the problem.

Was it insufficient or your tree does not have that fix?

This is just a test for: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233177
The patch is committed in rP487439 and rP487440, and I already got approval from @sunpoet.

Add patch of www/nghttp2

"Make it so" from manpages.

Address comments from sbruno. Leave the obsolete files but remove the MK_TIMED.

Address comments from bcr@ and bz@

I realize it's a little late, but login.conf does not belong to login(8). It belongs to login_cap(3), which is part of libutil.

I couldn't reproduce the original issue that @lev encountered. I tried these steps:

Hm, this should really not be necessary, as llvm-tblgen is always built from scratch during bootstrap, if the MK_SYSTEM_COMPILER logic detects that the base system compiler doesn't match the compiler in the source checkout. Maybe this is something PowerPC specific? @emaste or @jhibbits any ideas?

rebase.