[Toybox] Android binaries?

enh enh at google.com
Thu Sep 3 08:02:01 PDT 2020


On Thu, Sep 3, 2020, 01:04 Rob Landley <rob at landley.net> wrote:

> On 9/2/20 12:01 PM, enh wrote:
> > if you choose sdk_arm64 (or sdk_x86_64) off ci.android.com
> > <http://ci.android.com>, click on the little "download" icon on most
> recent
> > green build (or whichever build you want), the list of artifacts should
> now
> > contain toybox-static32 and toybox-static64.
>
> Yay! Ish. Hmmm... Ah, I was looking at sdk_x86, not sdk_x86_64. Yay, found
> it.
>
> > so some human effort required (afaik there's no URL that gives you the
> latest
> > green build), but a lot less effort than building AOSP...
>
>
> https://ci.android.com/builds/submitted/6810156/sdk_x86_64-sdk/latest/toybox-static64
> works but https://ci.android.com/builds/submitted/ is 404 which means
> this isn't
> a real web page but a database lookup emitted by CGI parsing the whole
> URL. So
> having a "latest" symlink under submitted isn't a question of a dumb little
> script to ln -sf after a successful build, instead somebody has to find the
> person who understands code that's never shipped to the outside world to
> dig
> through to where a new feature would need to be added in the plumbing.
>
> Sigh. If you hover over the top level cell that says "sdk" the hover text
> says
> "show last known good build", so there IS awareness that this is a feature
> people would want... but of course it's not a URL. It's javascript to
> redisplay
> the table showing just one row. Extra code to be LESS flexible.
>
> > ~/Downloads$ chmod a+x ./toybox-static64
> > ~/Downloads$ ./toybox-static64 date
> > Wed Sep  2 16:44:54 GMT 2020
> >
> > i'm not going to run anything else on this "real computer" or i'll be
> back
> > complaining that we should change top to not use KiB on a machine with
> 64GiB of
> > RAM,
>
> My current laptop (Dell Latitude E6230, I spent almost $200 on this thing
> _before_ upgrading the memory and hard drive) has 16 gigs of ram, same
> number of
> digits.
>
> The human_readable_long() plumbing will adjust the units to show the
> appropriate
> number of digits, the thing is we're telling it "8 digits" and 16229720K
> is 8
> digits (plus a unit).
>
> I think you want commas, which would take up digits and bump it down to
> 16,230M?
>
> > and that we need to examine /proc/sys/kernel/pid_max to know how wide pid
> > fields need to be again :-)
>
> Isn't it 6 digits now? 999999 processes? (Didn't we have this discussion
> already
> about ps? In theory top inherits that code...)
>

Yes, but my desktop has 7 digits (now at least --- I don't know whether my
desktop and laptop always differed like this, or this is from the ubuntu ->
debian switch).

We could bump the hard-coded value again, but that seems like a lot of
wasted empty columns for small systems?

>
Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20200903/bb7ff4b2/attachment-0001.html>


More information about the Toybox mailing list