<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 6, 2022 at 5:11 PM enh <<a href="mailto:enh@google.com">enh@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 6, 2022 at 5:09 PM enh <<a href="mailto:enh@google.com" target="_blank">enh@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 4, 2022 at 2:16 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/1/22 18:00, enh via Toybox wrote:<br>
> Afaik, I'm the only person regularly running the toybox tests as<br>
> root (in Android's CI), so I haven't actually fixed the character<br>
> special and block special tests for macOS here --- I've fixed them<br>
> so they work again on Android and Linux, and am just assuming we'll<br>
> "skipnot" them on macOS. The first person to want to run the tests<br>
> as root on macOS can fix this more thoroughly.<br>
<br>
I need to run the root tests more myself (part of what running the tests under<br>
mkroot is supposed to allow). I'm trying to fix it to work with "sys" and...<br>
<br>
-crw-rw---- 1 root sys 12,  34 1970-01-01 00:00 dir/char<br>
+crw-rw-r-- 1 root sys 12, 34 Jan  1  1970 dir/char<br>
<br>
Why would that change between root and non-root... because it didn't, devuan<br>
changed the default format out from under me in a version "upgrade". (Yes, this<br>
is more "make test_tar" without the rest of toybox, meaning it's not using<br>
toybox ls, meaning your previous argument circles around again...)<br>
<br>
I can force the time format with --full-time, although does the mac ls command<br>
have that...<br>
<br>
<a href="https://apple.stackexchange.com/questions/15170/how-do-i-change-the-time-format-used-by-ls-command-line-on-osx" rel="noreferrer" target="_blank">https://apple.stackexchange.com/questions/15170/how-do-i-change-the-time-format-used-by-ls-command-line-on-osx</a><br>
<br>
No it does  not. Nor does it provide an obvious alternative, they recommend<br>
"brew install coreutils". Right, I'm pretty happy saying mac only supports "make<br>
tests" all at once with macos_defconfig, and if you want more than that you can<br>
set up the $PATH to appropriate commands yourself. (Comparing toybox, busybox,<br>
and debian makes sense. Comparing with macosx is out of scope.)<br></blockquote><div><br></div><div>it's also useful for debugging specific mac issues... i currently have to `rm tests/*.test` and then `git checkout -- tests/tar.test` to test tar on macos in a reasonable amount of time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Except with --full-time it goes:<br>
<br>
crw-rw---- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char<br>
<br>
Luckily we forced TZ=UTC but what if the underlying filesystem doesn't SUPPORT<br>
nanoseconds? (Will it still display them? Are any filesystems that don't support<br>
nanoseconds still a concern?)<br>
<br>
Possibly toybox ls should support --time-format=long-iso (ahem: time-style)...<br>
except, even then the spacing is off when I list /dev? Why is the spacing off?<br>
Because a couple entries in /dev have:<br>
<br>
crw-rw----+ 1 root    video    81,   0 2022-09-01 11:12 video0<br>
crw-rw----+ 1 root    video    81,   1 2022-09-01 11:12 video1<br>
<br>
What does the plus mean? I've never seen the plus before... Sigh:<br>
<br>
<a href="https://en.wikipedia.org/wiki/File-system_permissions#:~:text=access%20control%20list" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/File-system_permissions#:~:text=access%20control%20list</a><br>
<br>
Debian does not have selinux enabled! Grrr. I'm guessing udevd has common rules<br>
or something, not chasing it down right now and in any case "system it's running<br>
on" can have arbitrary nuts spacing, so NOSPACE=1 the test. Does mksh support<br>
prefix assignments on functions...<br>
<br>
  $ mksh -c 'x() echo "$ABC"; ABC=def x'<br>
  def<br>
<br>
Yes it does. Right.<br>
<br>
Alright, put all this together and:<br>
<br>
-crw-rw---- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char<br>
+crw-rw-r-- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char<br>
<br>
The file creation permissions are still different. Your patch didn't change the<br>
permissions? The umask 0002 is zapping o+w but not o+r...?<br>
<br>
Ah, it's another "toybox" vs "debian du jour". Can coreutils please STOP<br>
RANDOMLY CHANGING STUFF? Grrr. Luckily, mknod has -m. (Checking to see if macos'<br>
mknod has -m, I find that macos does not appear to HAVE a command line mknod<br>
utility, just the system call? Anyway: gestalt toybox testing there, yay.)<br>
<br>
And a TODO item added to see if mknod's default permissions should change. (I.E.<br>
track down when/why gnu/mknod changed.)<br>
<br>
> Also use a consistent group as well as user for the "ownership"<br>
> test.<br>
<br>
Except it's "wheel" on the BSD-alikes, that change was made for a reason. Let's<br>
see... teach "skipnot" to exit with true or false and have an && thingy on the<br>
end to chgrp.<br>
<br>
> With this patch, the tests still pass on Linux and macOS but also<br>
> pass as root on Android.<br>
<br>
I can't seem to fix the last one:<br>
<br>
FAIL: tar ownership<br>
echo -ne '' | tar c --owner root --group sys --mtime @1234567890 dir/file | SUM 3<br>
--- expected    2022-09-04 09:11:48.899556402 +0000<br>
+++ actual      2022-09-04 09:11:48.903556402 +0000<br>
@@ -1 +1 @@<br>
-2d7b96c7025987215f5a41f10eaa84311160afdb<br>
+d9e7fb3884430d29e7eed0dc04a2593dd260df14<br>
<br>
And alas I dunno what the difference IS, the downside of an opaque hash. (It's<br>
consistently doing it with debian's tar and my tar so the file's got something<br>
different. Deleting and recreating dir/file right before the test isn't changing<br>
it...)<br>
<br>
The problem is, if you're still seeing the OLD hash, I can't just change it to<br>
the one I'm seeing. If you are, could you send me the tarball? (You saw the<br>
"save all tarballs" hack a couple emails back, right? I should work the test<br>
name in there or something, although "sha1sum *" should let you know which one<br>
has the matching hash...)<br></blockquote><div><br></div><div>i saw it, but didn't you see my reply saying that it didn't work?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I checked in the rest of it, lemme know what I broke?<br></blockquote><div><br></div><div>it doesn't seem to work at all?</div><div><br></div><div>you got the test the wrong way round (it should have been `&& SKIP=1` not `|| SKIP=1`), but then it only seems to last for one test anyway?</div><div><br></div><div>oh, because you're supposed to count the number of tests to skip? i'm not sure i have the words to express how terrible of an idea this seems to me? that's so unreadable an idea even its own author got it wrong? :-P</div><div><br></div><div>i still don't understand why there isn't just a "positive" version of skipnot? personally i think the only thing wrong with skipnot is that it's backwards, which makes the tests hard to read. i actually _like_ having a `skip_if` on tests; each test is understandable in its own right, without you needing to read any context. (that's actually part of why _i_ wasn't offended by the repetition of all the uname checks in my version, but i'd much rather factor out a DARWIN=1 or something if you want something brief like `skip_if DARWIN` instead.)</div><div><br></div><div>but expecting humans to _count_ the number of tests to skip (and to know, when adding/removing/changing existing tests, that they might invisibly be in such a "block") sounds like the kind of thing that even a FORTRAN IV programmer might have said "dude, are you sure?" to...</div><div><br></div><div>from this line:</div><div><br></div><div>SKIP=0 # End of tests that don't work on MacOS X<br></div><div><br></div><div>i don't think you even believed in it yourself :-) did you accidentally check in something that was between two changes?</div></div></div></blockquote><div><br></div><div>forgot to say that i've sent you the minimal patch to get this working anyway, even though i'm really unconvinced that this is a good route to go down!</div></div></div></blockquote><div><br></div><div>and the good news is that the tests do now pass on Android as root. (and only github runs mac CI, so i should be able to get this update in!)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>i think your `skipnot` was really close; it just needed to not be so negative :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
<br>
Rob<br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>