On 9/1/22 18:00, enh via Toybox wrote: > Afaik, I'm the only person regularly running the toybox tests as > root (in Android's CI), so I haven't actually fixed the character > special and block special tests for macOS here --- I've fixed them > so they work again on Android and Linux, and am just assuming we'll > "skipnot" them on macOS. The first person to want to run the tests > as root on macOS can fix this more thoroughly.
I need to run the root tests more myself (part of what running the tests under mkroot is supposed to allow). I'm trying to fix it to work with "sys" and... -crw-rw---- 1 root sys 12, 34 1970-01-01 00:00 dir/char +crw-rw-r-- 1 root sys 12, 34 Jan 1 1970 dir/char Why would that change between root and non-root... because it didn't, devuan changed the default format out from under me in a version "upgrade". (Yes, this is more "make test_tar" without the rest of toybox, meaning it's not using toybox ls, meaning your previous argument circles around again...) I can force the time format with --full-time, although does the mac ls command have that... https://apple.stackexchange.com/questions/15170/how-do-i-change-the-time-format-used-by-ls-command-line-on-osx No it does not. Nor does it provide an obvious alternative, they recommend "brew install coreutils". Right, I'm pretty happy saying mac only supports "make tests" all at once with macos_defconfig, and if you want more than that you can set up the $PATH to appropriate commands yourself. (Comparing toybox, busybox, and debian makes sense. Comparing with macosx is out of scope.) Except with --full-time it goes: crw-rw---- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char Luckily we forced TZ=UTC but what if the underlying filesystem doesn't SUPPORT nanoseconds? (Will it still display them? Are any filesystems that don't support nanoseconds still a concern?) Possibly toybox ls should support --time-format=long-iso (ahem: time-style)... except, even then the spacing is off when I list /dev? Why is the spacing off? Because a couple entries in /dev have: crw-rw----+ 1 root video 81, 0 2022-09-01 11:12 video0 crw-rw----+ 1 root video 81, 1 2022-09-01 11:12 video1 What does the plus mean? I've never seen the plus before... Sigh: https://en.wikipedia.org/wiki/File-system_permissions#:~:text=access%20control%20list Debian does not have selinux enabled! Grrr. I'm guessing udevd has common rules or something, not chasing it down right now and in any case "system it's running on" can have arbitrary nuts spacing, so NOSPACE=1 the test. Does mksh support prefix assignments on functions... $ mksh -c 'x() echo "$ABC"; ABC=def x' def Yes it does. Right. Alright, put all this together and: -crw-rw---- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char +crw-rw-r-- 1 root sys 12, 34 1970-01-01 00:00:00.000000000 +0000 dir/char The file creation permissions are still different. Your patch didn't change the permissions? The umask 0002 is zapping o+w but not o+r...? Ah, it's another "toybox" vs "debian du jour". Can coreutils please STOP RANDOMLY CHANGING STUFF? Grrr. Luckily, mknod has -m. (Checking to see if macos' mknod has -m, I find that macos does not appear to HAVE a command line mknod utility, just the system call? Anyway: gestalt toybox testing there, yay.) And a TODO item added to see if mknod's default permissions should change. (I.E. track down when/why gnu/mknod changed.) > Also use a consistent group as well as user for the "ownership" > test. Except it's "wheel" on the BSD-alikes, that change was made for a reason. Let's see... teach "skipnot" to exit with true or false and have an && thingy on the end to chgrp. > With this patch, the tests still pass on Linux and macOS but also > pass as root on Android. I can't seem to fix the last one: FAIL: tar ownership echo -ne '' | tar c --owner root --group sys --mtime @1234567890 dir/file | SUM 3 --- expected 2022-09-04 09:11:48.899556402 +0000 +++ actual 2022-09-04 09:11:48.903556402 +0000 @@ -1 +1 @@ -2d7b96c7025987215f5a41f10eaa84311160afdb +d9e7fb3884430d29e7eed0dc04a2593dd260df14 And alas I dunno what the difference IS, the downside of an opaque hash. (It's consistently doing it with debian's tar and my tar so the file's got something different. Deleting and recreating dir/file right before the test isn't changing it...) The problem is, if you're still seeing the OLD hash, I can't just change it to the one I'm seeing. If you are, could you send me the tarball? (You saw the "save all tarballs" hack a couple emails back, right? I should work the test name in there or something, although "sha1sum *" should let you know which one has the matching hash...) I checked in the rest of it, lemme know what I broke? Thanks, Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
