On Tue, Sep 6, 2022 at 5:09 PM enh <[email protected]> wrote: > > > On Sun, Sep 4, 2022 at 2:16 AM Rob Landley <[email protected]> wrote: > >> 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.) >> > > 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. > > >> 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 saw it, but didn't you see my reply saying that it didn't work? > > >> I checked in the rest of it, lemme know what I broke? >> > > it doesn't seem to work at all? > > 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? > > 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 > > 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.) > > 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... > > from this line: > > SKIP=0 # End of tests that don't work on MacOS X > > i don't think you even believed in it yourself :-) did you accidentally > check in something that was between two changes? >
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! i think your `skipnot` was really close; it just needed to not be so negative :-) > Thanks, >> >> Rob >> >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
