[Toybox] Android sitrep

enh enh at google.com
Mon Sep 16 12:43:37 PDT 2019


On Wed, Aug 28, 2019 at 5:08 PM enh <enh at 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).



More information about the Toybox mailing list