On Wed, Dec 14, 2022 at 10:48 AM enh <[email protected]> wrote: > > > On Tue, Dec 13, 2022 at 7:52 PM Rob Landley <[email protected]> wrote: > >> Thanks to Zach for getting me sh access to a mac, mac is passing its >> tests again. >> > > nice! thanks both! > > (i _won't_ be updating AOSP this week though because i'm ooo the next two > weeks, and don't want to leave any surprises for folks who will still be > working. i'll catch up with all we've missed in the first week of > january...) >
it later occurred to me there would be some value in me at least running the tests on android... looks like there's a realpath failure (but no change to any of the other tests): -- realpath PASS: realpath realpath . PASS: realpath missing PASS: realpath missing2 PASS: realpath -z PASS: realpath file PASS: realpath dir PASS: realpath --relative-to PASS: realpath --relative-to2 PASS: realpath --relative-to3 PASS: realpath --relative-to4 PASS: realpath --relative-base PASS: realpath --relative-base stomps --relative-to PASS: realpath -m with relative-base1 PASS: realpath -m with relative-base2 PASS: realpath -m with relative-base3 PASS: realpath missing defaults to -m PASS: realpath missing -e PASS: realpath -L PASS: realpath -s PASS: realpath -s link/.. PASS: realpath -s .. eats symlink FAIL: realpath -s .. eats symlink in $PWD echo -ne '' | cd dos && realpath -s .. --- expected 2022-12-16 17:30:41.167996851 +0000 +++ actual 2022-12-16 17:30:41.179996850 +0000 @@ -1 +1 @@ -/data/local/tmp/toybox-tests-tmp.gAHArSomwm/realpath +/data/local/tmp/toybox-tests-tmp.gAHArSomwm/realpath/one > It had two problems: >> >> A) The mac test for "does chmod +s work as a normal user" in chmod.test >> wasn't >> converted to the new format properly (5f7faac45363 missed one and I didn't >> notice because it only mattered on mac), which is weird because you'd >> think mac >> would hit that failure FIRST on github and android? (Weird. I just did >> homebrew, >> gmake macos_defconfig, gmake tests...) >> > > (i can't explain github, but Android doesn't have good infrastructure for > running macOS tests, so there's _nothing_ in Android's CI for that. we > _build_ for the mac, but we don't run the tests, which is why i pay so much > attention to the github test results, and haven't synced AOSP since they > went red.) > > >> II) Mac hasn't got O_PATH and portability.h was doing an #ifdef check and >> defining it, because it was only added to the kernel in 2011 (commit >> 1abf0c718f15a) and the 7 year horizon for that was still relevant >> pre-pandemic. >> >> Mac still hasn't got O_PATH but the numeric value Linux uses was already >> allocated in mac for O_SYMLINK "allow open of a symlink" (which Linux >> hasn't >> got), hence the weird behavior. >> >> Not a kernel bug, a portability.h bug. >> > > ah, that makes more sense! > > >> Rob >> >> P.S. Ironically, pulling the second mac fix into my main work tree hit a >> conflict because I was doing a pass tracking down the expiration dates of >> symbols in there, recording the kernel commit that added them. Which >> rolled to a >> stop because AT_FDCWD was added in 2006 and RLIMIT_RTTIME wsa 2008 and >> they've >> got to still be there because because a specific build environment needed >> them, >> but which one? Having updated Mac, BSD, and NDK build environments to >> regression >> test against hopefully lets me resume that cleanup... >> >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
