ubuntu-phone team mailing list archive

[Vicamo Yang <vicamo.yang@xxxxxxxxxxxxx>]

Hi,

A little bit off the topic but I think docker fulfills the requirements
quite well.
To give docker a try, `docker pull -a vicamo/ubuntu-sdk` gives two images
tagged as vivid-<host>_<target>.
Note that each of them takes more than 1GB disk space.

Here are images generated along with the github repositories for the
Dockerfiles:
https://registry.hub.docker.com/u/vicamo/ubuntu-sdk/
https://registry.hub.docker.com/u/vicamo/ubuntu-core/
https://github.com/vicamo/docker-brew-ubuntu-core
https://github.com/vicamo/docker-images/blob/master/ubuntu-sdk/vivid-amd64_armhf/Dockerfile
https://github.com/vicamo/docker-images/blob/master/ubuntu-sdk/vivid-i386_i386/Dockerfile

Have fun!


On Tue, Feb 17, 2015 at 1:53 AM, Zoltán Balogh <zoltan.balogh@xxxxxxxxxxxxx>
wrote:

> Hi,
>
> The root file system we use to build and package apps with the SDK are
> chroots wrapped around with schroot and click. This chroot contains the
> application development framework and documentation.
>
> The purpose of this chroot is to make the phone APIs, libraries available
> for the developers who might be on Trusty or on Utopic. So the chroot
> contains the stuff what is on the real device.
>
> Right now we create these chroots on the first start of the Ubuntu SDK.
> There are few problems with this flow:
>
> 1. The `click chroot create` uses schroot debootsrap what downloads the
> core bootsrap and installs the requested framework. It means about 1.7GB
> downloaded data and hundreds of .deb packages. It is a slow and fragile
> process.
>
> 2. The schroot debootstrap creates the actual snapshot of the Ubuntu
> series, so it is working with a rather fluid base. The Utopic based RTM
> target is stable, but the development release, as expected is a constantly
> changing target. So we hardly have a solid common base.
>
> We have been talking about the possibility of releasing the SDK frameworks
> in single downloadable static  images.
>
> The benefits of such SDK distribution model are:
>
> 1. Smaller and single downloadable root file system
>
> 2.  Static and versioned images what we could release together with the
> device images
>
> I made a simple pilot project to demonstrate how the real implementation
> would look [3]
>
> This project have two scripts:
>
> 1. create_static_schroot.sh
>
> This script is for
>
> 1.1 creating static image: sudo create_static_schroot.sh -c -a armhf -f
> ubuntu-sdk-15.04
> 1.2 installing the created image: sudo create_static_schroot.sh -i
> click-ubuntu-sdk-15.04-armhf-amd64.tar.gz
> 1.3 downloading and installing the image: create_static_schroot.sh -d -a
> armhf -f ubuntu-sdk-15.04
>
> The -h parameter shows all the available options.
>
> The static images are hosted on people.canonical.com [2]
>
> Right now there are both i386 and armhf images for 15.04
>
> 2. test_static_chroot.sh
>
> This script is for banchmarking the click chroot creation and the
> create_static_schroot.sh -d -a armhf -f ubuntu-sdk-15.04
>
> I have asked folks around to help with the benchmarking, because the
> chroot creation in any case depends on the bandwidth.
>
> I got results from DanChapman, zbenjamin, kalikiana and zsombi plus my own
> test [1]. The result is that downloading from the people.canonoical.com
> the image and setting it up for schroot takes 40-60% of the time of
> creating a click chroot.
>
> Please give these scripts a try and let's discuss about how to go forward.
> I would definetly suggest to work out this model a bit more and start
> hosting SDK images alongside with the other system images and teach either
> the Ubuntu SDK or the click itself to optionally use the static images
> instead of the dynamically created bootstraps.
>
> cheers,
>
> bzoltan
>
> [1]  http://paste.ubuntu.com/10257872/ http://pastebin.ubuntu.com/
> 10257860/ http://paste.ubuntu.com/10257687/
> [2] http://people.canonical.com/~bzoltan/static_chroots/
> [3] lp:~bzoltan/+junk/static_chroots
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Vicamo Yang