If I set the IPv6 "forwarding" property to off

Why does the computer still forward IPv6 packets from interface to interface?

If I turn the IPv4 forwarding property off, it immediately stops forwarding things

bug?

does that target interface have forwarding enabled? ire_recv_forward_v6() is checking ill_flags & ILLF_ROUTER on source and destination

ipadm show-ifprop -p forwarding

Yeah, it's on for the interfaces

I guess there's a bug with the global toggle then

I have filed illumos#18171

... fenix? 18171

I don't know what it is about this bot but I seem clinically incapable of triggering it

fenix? illumos 18171

BUG 18171: IPv6 "forwarding" property does not inhibit forwarding (New)

↳ illumos.org/issues/18171

[illumos-gate] 18101 bhyve: use speed in hci to allow backend modify it. -- ShengYi Hung <aokblast⊙Fo>

danmcd: I have never used the auto-test thing where it derives the tests from the directory

danmcd: aside from your experience today, does it tend to be fine?

I have almost 4 years of test results to make me feel pretty happy about all of that.

I run the tests using this: github.com/TritonDataCenter/illumos…c/test/smartos-test/smartos-test.sh

Good part is here: github.com/TritonDataCenter/illumos…t/smartos-test/smartos-test.sh#L350

that might help me clean up this arm64-gate wad some

just say "run the ../32 and ../64 tests", rather than enumerating them all twice

(and make the ../32 ones i86pc-specific)

[illumos-gate] 18161 dmake(1) could use posix_spawn() to run commands -- Andy Fiddaman <illumos⊙fn>

andyf: glad that circumstances got that one into my merge :)

It's time to run another another build on aarch64!

andyf: if you want to measure yourself, you'll want a baseline with only michael's fixes

I can do that. dmake is self-contained so copying the binary back and forth gives a clean way to test.

andyf: looks like the optimized descriptor-copying thing for the spawn syscall turned out to be not too hairy to pull off. Nice!

Yes! Thanks for suggesting that, I'm not sure I'd have thought to do it otherwise.

richlowe / andyf: so I attempted to use the configure command in the README.md in github.com/illumos/gcc and the subsequent build failed in one of the later stages (with a ".. already configured" error, I think.. it's been a while).

I think I'm missing a secret handshake..

(want to clear up the open issues on my pull request that improves locale support in libstdc++)

I've only ever used the omnios build scripts to drive that (github.com/omniosorg/omnios-build/b…lob/master/build/gcc14/build.sh#L98 ) but I should take a look at the README

I was confused by the "../../configure ..." instead of "./configure ..."

not sure what that was supposed to imply..

Probably an out of tree build thing, with that being the path back? I will read and stop guessing.

if I wrote it, it will assume an out-of-tree build

sorry

"../../configure" reads to me as two-subdirs-deep-in-tree (which ones?) rather than out-of-tree....

probably gcc/build/foo/

sommerfeld: almost certaily gcc/build/<foo>, indeed

if people are looking at illumos/gcc, can someone bump the default branch? :)

(if they didn't already)

heh yeah

that got me the other day

richlowe: I'd change it (illumos/gcc default branch) if I had access but I don't think I do..