People have actually been testing this?

[Rob Landley]

So I've been trying to bisect the bug I posted yesterday, where 'struct 
in6_pktinfo' is an incomplete type (in the nptl branch, but not in the 
0.9.30.1 release), and this breaks the busybox build.

While bisecting, I hit an "undefined NULL" over a larger range, which hid the 
introduction of the bug I was looking for.  So I bisected _that_ one to where 
it was fixed at git 6d3ed00a41a948, and made a patch I could apply to earlier 
versions.

Doing a fresh bisect to find the next bug masking the introduction of the one I 
was looking for, I hit the "conflicting types for getline" bug.  While looking 
for where _that_ got fixed, I saw the bug where it tries to use fcntl64 and 
can't find it, and the fun little bug where the ldconfig.c build dies with an 
unexpected something before 'err'.

This is not "the occasional commit breaks the tree".  The tree being broken is 
not only the norm, but it tends to be broken for more than one reason at any 
given time.  So far, bisecting hasn't hit on a single commit since the last 
release where the tree actually _did_ work.

I note that I'm actually testing the old threads, not nptl.  This is pure 
regression testing.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds