[Toybox] Android sitrep

[enh]

On Tue, Sep 17, 2019 at 12:29 PM enh <enh at google.com> wrote:
>
> 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?
>
> using toybox for the kernel builds too is deliberate, as part of the
> "hermetic build" mentioned in
> https://linuxplumbersconf.org/event/4/contributions/401/attachments/318/542/GKI_Progress.pdf

and also https://linuxplumbersconf.org/event/4/contributions/403/attachments/319/543/ABI_Monitoring.pdf
which has a slightly more detailed version of what was probably the
same slide at some point :-)

> >   * 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.
> >
> > * 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).