[mkroot] Design issue: uploading binaries.

[Alain Toussaint]

Could be both but at least mkroot. Basically, it's been slightly over
a year I've been building LFS svn on a bi-monthly basis and would like
to automate that. Automating mkroot & musl-cross-make would be a
useful addition to the linode server.

Alain

2017-06-21 17:41 GMT-04:00 Rob Landley <rob at landley.net>:
> 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
>>