All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: yocto@yoctoproject.org, gary@mlbassoc.com
Subject: Re: meta-mono core-image-mono failing
Date: Thu, 22 May 2014 10:56:24 +0100	[thread overview]
Message-ID: <537DC9C8.6080002@dynamicdevices.co.uk> (raw)
In-Reply-To: <1400748019.17834.37.camel@ted>


On 22/05/2014 09:40, Richard Purdie wrote:
> On Thu, 2014-05-22 at 09:29 +0100, Alex J Lennon wrote:
>> On 22/05/2014 09:23, Richard Purdie wrote:
>>> On Thu, 2014-05-22 at 00:23 +0100, Alex J Lennon wrote:
>>>> Thanks Stefan.  > daisy was my suspicion but that seemed unlikely so I
>>>> have a clean Fedora build underway with daisy / meta-mono /
>>>> core-image-mono to prove it to myself as a first pass before trying master.
>>>>
>>>> As I do this I am thinking it would be nice if there were canonical
>>>> images of Yocto-X.Y available to run up on Amazon/Azure/elsewhere to
>>>> prove these things out in the background without mashing my SSDs.
>>>>
>>>> I am guessing somebody has done this already but I hunted around Amazon
>>>> and couldn't see any community images that looked useful (?)
>>>>
>>>> Similarly (and I confess I haven't yet had time to understand
>>>> AutoBuilder as I should) presumably there are a number of daily builds
>>>> in the cloud, on each of the supported host platforms, for each of the
>>>> advertised layers, and if they fail then maintainers are kicked? Is that
>>>> how things work? If so, can you advise how I request to add meta-mono to
>>>> the kick-list?
>>> Its a nice idea but right now we struggle to test and keep OE-Core
>>> building, let alone trying to define tests for every other layer :(. The
>>> amount of time I and others spend on this for OE-Core is phenomenal.
>> I can well imagine Richard! I've often wondered how the team(s) manage
>> to keep everything running along so smoothly.
>>
>>> If we had more people and resources, sure but right now there is no such
>>> setup.
>> Like you I'm very time constrained here unfortunately, but I like the
>> idea of having some baseline VM images ready to go on Amazon or Azure as
>> a starting point for testing at least.
>>
>> If such a thing hasn't already been done I might try to put those
>> together. If I do get around to it I'll you know (if of interest)
> FWIW we do have the build-appliance image and that is able to run builds
> within it. It sounds like you just need a slightly different version of
> that (with the UI removed).

Thanks Richard. That sounds useful.

So, I have the build-appliance image running in VMWare. I was also
looking at the design document here,

https://wiki.yoctoproject.org/wiki/Build_Appliance_Design

The appliance image seems quite large, at 4GB for the vmdk or so
uncompressed, in the context of aiming for a 100MB download?

Looking at the f/s it seems most of this is because the sources have
already been downloaded and the native recipes built?

3.5G    ./build/downloads
1.3G    ./build/tmp/work
2.1G    ./build/tmp
5.5G    ./build
5.6G    .

I guess there's a tradeoff here between getting started building images
within the appliance quickly and the size of the appliance download?

Then, looking at the running virtual machine, it seems that if I do
something like bitbake build-appliance on my own Ubuntu 12.04 host I
would generate an appliance targetted at qemux86-64?

What I'd believe I'd like to have is ready-to-run images of the vanilla
host installations ( Fedora, OpenSUSE, Debian, and Ubuntu, x32 x64),
prepped with needed Yocto dependencies and a baseline daisy tree, to
verify Yocto build in those host environments.

I don't quite understand what elements of "my" build host actually get
pulled into the appliance image that is built (I suspect none?)

So I wonder if there's a way with the appliance to build something that
I can then sit on top of those vanilla host installations (possibly with
a separate block store image somewhere in AWS containing all the
downloads so I don't have that replicated across the images).

Does that make sense? Can you offer any advice on how to achieve that?

Thanks,

Alex




      reply	other threads:[~2014-05-22  9:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-21 18:25 meta-mono core-image-mono failing Chris Morgan
2014-05-21 18:57 ` Gary Thomas
2014-05-21 19:07   ` Chris Morgan
2014-05-21 20:15     ` Alex J Lennon
2014-05-21 20:26       ` Chris Morgan
2014-05-21 20:35         ` Alex J Lennon
2014-05-21 22:28           ` Chris Morgan
2014-05-22  7:59         ` Alex J Lennon
2014-05-21 23:10       ` Stefan Stanacar
2014-05-21 23:23         ` Alex J Lennon
2014-05-22  8:23           ` Richard Purdie
2014-05-22  8:29             ` Alex J Lennon
2014-05-22  8:40               ` Richard Purdie
2014-05-22  9:56                 ` Alex J Lennon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=537DC9C8.6080002@dynamicdevices.co.uk \
    --to=ajlennon@dynamicdevices.co.uk \
    --cc=gary@mlbassoc.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.