[Toybox] one last find thing...

[Rob Landley]

On 6/22/19 1:39 PM, enh wrote:
> on the bright side, this has been the kick in the pants necessary to
> get me to concentrate on running the toybox tests in presubmit.
> 
> current status (after the various patches i've sent out this morning)
> looks like this:
> 
> PASSED: 64

Yay

> FAILED: blkid
> FAILED: cp
> FAILED: du
> FAILED: echo
> FAILED: split

These are all passing for me here, built both with devuan's gcc and with the
NDK. I don't know why they aren't for you.

> FAILED: touch

An endless parade of:

__bionic_open_tzdata: couldn't find any tzdata when looking for UTC0!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!

but that's bionic (even statically linked) needing system context to run. A bit
like how glibc static linking can't do name server lookups unless it can dlopen
additional shared libraries.

> FAILED: grep

This works built with devuan's gcc but with the NDK:

grep: bad REGEX '': empty (sub)expression
FAIL: grep -e blah -e ''
grep: bad REGEX '': empty (sub)expression
PASS: grep -w ''
grep: bad REGEX '': empty (sub)expression
FAIL: grep -w '' 2

I vaguely recall I have a todo item for that but, it's gotten buried under
layers of new todo items...

> FAILED: chgrp

Requires root but passes under sudo on devuan.

(I note bionic treats uids/gids differently, so there may be a design issue there.)

> FAILED: chown

Same as chgrp.

> FAILED: ifconfig

Requires root _and_ a specific environment (the dummy driver), I need to revisit
this when I get mkroot merged.

My roadmap for this is:

1) Eliminate remaining busybox commands (route and sh) from mkroot. (I'm working
on toysh now and hope to have something mkroot can use... well before I have to
go get another $DAYJOB.)

2) simplify mkroot and merge it into toybox as a "make root" target (easy once
it no longer needs busybox)

3) extend the test suite to use qemu and run tests under a VM with a known
environment (for stuff like ifconfig).

Working on it...

> FAILED: killall

Fails here, but just ignore/diable it for now. (It's basically just one one test
anyway. This is another test that should really happen in the vm because the
tests going weird can be bad for the host system. If your desktop is running as
you, killing the wrong bits of it requires a logout and you lose all your open
windows. Yes I hit this developing this. :)

> FAILED: modinfo

This one got hit by kernel version skew. It's checking the "ne2k_pci" driver
from the host system, which A) isn't guaranteed to be there, B) was for a
previous kernel version and what fields it has in its info changed since then.

This one is in my "post-mkroot" pile as well, but really what I should probably
do is put together a dummy driver and check it into tests/files so we're
querying a known file with known fields.

> FAILED: tar

Ooh, interesting, that _used_ to pass but:

tar: Not tar
FAIL: tar pass /dev/loop0
echo -ne '' | tar c --numeric-owner --mtime @0 /dev/loop0 2>/dev/null | LST
--- expected	2019-06-23 02:02:07.192019390 +0000
+++ actual	2019-06-23 02:02:07.196019390 +0000
@@ -1 +0,0 @@
-brw-rw---- 0/6 7,0 1970-01-01 00:00 dev/loop0
.singlemake:1631: recipe for target 'test_tar' failed
make: *** [test_tar] Error 1

Ah. Devuan hasn't got a /dev/loop0, you have to loop-control to request new
devices now. Hit by kernel version skew between Ubuntu 14.04 and devuan ascii
2.0. And this means there are NO block devices guaranteed to be there in /dev.
(Speaking of which, I should dust off my patch to fix disabling the block layer
but allowing external initramfs images...)

Once again: mkroot.

> FAILED: unzip

I haven't implemented zip and unzip yet. (Not hard, just time consuming. I want
to do the compression side of deflate first, and last time I was poking at that
I went down a rathole of "so when DO dictionary resets happen" and there was no
good answer (different implementations to it differently) but people _kinda_
care that the hashes of tarballs match up, and I think the answer to _that_ one
was "every 256k of input"? Anyway, got distracted, haven't gotten back to it
since...)

> FAILED: xargs

Hmmm, this one is sort of an actual regression:

FAIL: xargs -s too long
echo -ne 'one two three' | xargs -s 9 echo 2>/dev/null || echo ok
--- expected	2019-06-22 21:14:07.948030205 -0500
+++ actual	2019-06-22 21:14:07.960030205 -0500
@@ -1,3 +1 @@
-one
-two
 ok
.singlemake:1727: recipe for target 'test_xargs' failed
make: *** [test_xargs] Error 1

Because "echo three" is 10 characters so can never fit in an -s 9 constraint.
But we changed the design (during that long thread with Linus about how big the
environment space actually is) to basically just "try it with one arg" as the
fallback for a line that won't fit in the environment, so that's what it's doing
now, and succeeding. All 3 failing tests were doing various edge cases of that
and now expect different results.

But TEST_HOST is passing which means the debian xargs is doing what we _used_ to
do, so we should probably go back to doing that too...

  $ echo three | xargs -s 9 echo
  xargs: argument line too long

I'll throw it on the todo heap.

> in the short term i'll probably just disable the failing tests
> (because automating testing of 63 commands is better than none), but
> i'll start going through the failures too... can't keep things green
> if they're not green to start with :-)

VERBOSE=1 and VERBOSE=fail are your friends. Also VERBOSE=nopass.

Rob