On Wed, Aug 28, 2019 at 5:08 PM enh <e...@google.com> wrote: > > i guess now's a good time for another sitrep, since i've been out sick > all week and so had time to poke at various things, and there's been > quite a lot going on: > > * after the genuine dd bug found by the continuous tests was fixed, > i've seen no more test failures there. > > * md5sum and sha*sum were motivating cases to actually properly > support macOS builds. > > * i now, for my sins, have three different .config files, three > different generated/ directories, and a short script using NOBUILD to > regenerate the generated/ files. > > * the good news about that is that i no longer have any need to > build toys/android/ stuff on the host. would you like me to clean up > some of the compatibility cruft that (iirc) is only there to support > that? if it's not useful to me, i'm assuming it's not useful to > anyone? > > * the bad news that turned into good news was that this > accidentally regressed someone's kernel builds (because AOSP doesn't > need nproc, and i cleaned up the host configs to only include tools > actually used, not everything that goes on the device). i added nproc > back to the linux host toybox, and the person who was affected added a > kernel build to the presubmit check for a toybox prebuilt update. so > if we break kernel builds in some way we won't see it when i sync with > github, but we will see it when the build folks try to build a new > prebuilt. which is still fairly frequently. > > * anecdotally i've heard that tar and xargs (independently) gave > them problems, but i've yet to receive the promised bug reports. > > * it's still not 100% clear to me whether they consider using > toybox for these builds to be deliberate or accidental. it happened by > accident (in search of a hermetic build), but they've kept it for now > so ... deliberate? > > * there's a macOS toybox prebuilt now too, updated whenever the linux one > is. > > * i _added_ md5sum and sha*sum which the mac doesn't normally have > (the slightly different md5 and shasum instead). > > * i switched over everything used in the AOSP build that's currently > toybox on linux to being toybox on the mac too (except date and stat). > that's only been in a day, but it hasn't had to be reverted yet. > > * date and stat need a bit of tree cleanup because there are places > that _expect_ differences in behavior.
(this cleanup is done now... everything from toybox that's used to build AOSP on a linux host is now also used to build AOSP on a macOS host.) > * unrelated, i built a static toybox binary. > > * the transitive dependencies are pretty gross thanks to the cgroup > stuff. i wonder if anyone uses that enough for it to be really worth > it, or whether we could drop it without anyone noticing? > > * the chips in those devices are old enough that you need a generic > build to not die immediately with SIGILL. (i didn't have any of my > usual tools to work out _what_ the invalid instruction is.) > > * ran tests (with some difficulty) on jellybean, and had about 100 > failures out of about 1200 tests. (`adb shell` didn't return exit > status that far back, so this is grep for PASS and FAIL rather than > the usual output from my little test runner.) > > * a bunch of the failures are because the current tz code in libc.a > doesn't support the tz data format back in jellybean. i _think_ kitkat > was the transition, so i'd like to rerun the tests when i've had > chance to plug a kitkat device in at my desk. > > * regardless, it seems like it might be plausibly useful to make a > static toybox available on ci.android.com. don't know whether you'd > want to link to that (which was why i pinged you on that bug about > switching to README.md like all the cool kids). _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net