[mkroot] Design issue: uploading binaries.

[Rob Landley]

On 06/21/2017 04:08 PM, Alain Toussaint wrote:
> Would it be useful to have a linode server for that. I've been mulling
> for one myself and would likely rent one soon which I can make
> available to mkroot and install travis-ci on it.
> 
> Alain

For mkroot, or for musl-cross-make?

For mkroot I'm ok building binaries as part of a release. (I already
have to do that to test everything before shipping it.)

For musl-cross-make, I'm fuzzy on the details of Rich's plans.

Rob

> 2017-06-21 16:46 GMT-04:00 Rob Landley <rob at landley.net>:
>> I built mkroot binaries for a bunch of targets, but am not quite sure
>> where (or if) to upload them. This remains an unsolved problem and I'm
>> open to suggestions.
>>
>> I can stick them on landley.net/mkroot pretty easily, but the project
>> doesn't have the same kind of website the old one did. It's a
>> self-contained github project with a README. In theory github has a
>> "releases" mechanism that lets you attach binaries to a tag, but the
>> web-based mechanism is very manual and
>> https://developer.github.com/v3/repos/releases/ is not making a lot of
>> sense to me. (Googling for this sort of thing finds stuff for the older
>> https://developer.github.com/v3/repos/downloads/ mechanism that was
>> deprecated and removed in 2012.)
>>
>> (I'm also leaning towards not posting binaries until I get busybox
>> cleaned out of the build. At which point everything would be bsd/pd
>> licensed.)
>>
>> As for toolchain binaries, I've been poking Rich Felker about uploading
>> musl-cross-make binaries for ages (although he's now waited long enough
>> that https://lwn.net/Articles/726023/ happened and kinda took the
>> thunder away from that), and _he_ wants to use
>> https://docs.travis-ci.com/user/deployment/releases/ to produce and
>> automatically upload them for each new tag. Which is nice, but neither
>> of us has sat down to work out how to actually do it, and github has a
>> 1gb quota per account that could get eaten pretty quickly by that sort
>> of thing.
>>
>> Meanwhile, the kernel guys are using
>> https://www.kernel.org/pub/tools/crosstool/ which doesn't have a C
>> library (so you can pretty much _only_ build the kernel with them, no
>> userspace). And I have a todo item to try to build stuff with Android's
>> NDK when the next version ships.
>>
>> Lack of native compiler binary tarballs (which only musl-cross-make
>> builds, and it's still not providing downloadable binaries) is
>> semi-blocking the next major design stage, which is reproducing
>> aboriginal linux's build control images under mkroot. What it's building
>> right now isn't a development environment. I have to compile make from
>> source (and/or implement one in toybox), but without a toolchain it's
>> not much use.
>>
>> That said I do have an mcm-buildall.sh script checked in, and I can just
>> have this _also_ depend on the mcm symlink like cross.sh does now...
>>
>> Rob
>> _______________________________________________
>> mkroot mailing list
>> mkroot at lists.landley.net
>> http://lists.landley.net/listinfo.cgi/mkroot-landley.net
>