All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Using bitbake in minimal chroot environment
Date: Mon, 15 Feb 2010 19:43:06 +0100	[thread overview]
Message-ID: <hlc4jp$cfc$1@ger.gmane.org> (raw)
In-Reply-To: <20100215171952.GA3233@jama>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-02-10 18:19, Martin Jansa wrote:
> On Mon, Feb 15, 2010 at 05:59:39PM +0100, Frans Meulenbroeks wrote:
>>>> I'm just thinking about using bitbake only in minimalistic chroot.
> 
> Already rebuilding in new chroot :).
> 
>>>>
>>>> What are advantages/disadvantages?
>>>>
>>>> How I see it:
>>>>
>>>> Advantages:
>>>> 1) more secure (I started to use separate user for bitbake, when I
>>>>    started to play with bitbake master instead release - because that
>>>>    warning it said), but chroot is even better.
>>>> 2) less problems when autotools pick some header or lib from buildhost
>>>>    instead of staging
>>>> 3) easier to check, that -native package is missing for some important
>>>>    lib
>>>>
>>>> Disadvantages:
>>>> 1) Few more MB for building environment (extra libc, gcc, binutils, git,
>>>>    svn, sh, etc. installed in chroot
>>
>> If they are on the same filesystem you could use hard links and save those MBs.
> 
> Not so big problem for me, so I used mount --bind for dirs I want to
> share (ie /usr/portage as I'm using gentoo) and it took only about
> 100MB.. so not a big deal
> 
>>>> 2) More administrative to keep chroot system updated
>>>> 3) harder to check, that autotools won't pick something from buildhost
>>>>    in normal environment before pushing new version/recipe (ie I won't
>>>>    have SDL libs installed in chroot, but everybody else will and maybe
>>>>    build will fail for them after I push some recipe.
>>>
>>> I see this as a good thing :)
> 
> The last point? Well it's good for me (less issues) but if I push some
> recipe failing for 99% other builders just because they have pretty
> standard libs on their systems, then I should be blamed for pushing
> crappy recipe :).
> 
>> Seems a good plan to me, please keep us posted.
>> (actually I've been considering building in a minimalistic VM)
> 
> Well VM would be much slower.. 

On a recent intel/amd cpu VMs I can't measure much difference between VM
and non-vm builds.
My main buildmachine at work is an ubuntu 8.04LTS vm running under
windows XP. The only major speedup I can get building in a native
install would be using 64bit, since the VM is 32 bit, but it does expose
both CPU cores :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLeZW6MkyGM64RGpERAtFOAJ9hOQA/80gWA5pzQQW9vZ34Kcmy7ACgh6vV
zSccfttlBkf/RDcRCiYQMqg=
=ID01
-----END PGP SIGNATURE-----




  parent reply	other threads:[~2010-02-15 18:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-14 13:56 Using bitbake in minimal chroot environment Martin Jansa
2010-02-15 15:24 ` Philip Balister
2010-02-15 16:59   ` Frans Meulenbroeks
2010-02-15 17:19     ` Martin Jansa
2010-02-15 17:57       ` Frans Meulenbroeks
2010-02-15 18:12         ` Martin Jansa
2010-02-15 18:22         ` Mike Westerhof
2010-02-15 18:36           ` Martin Jansa
2010-02-15 18:43       ` Koen Kooi [this message]
2010-02-15 20:53         ` Frans Meulenbroeks
2010-02-15 22:04         ` Tom Rini
2010-02-15 22:15           ` Koen Kooi
2010-02-16  8:11           ` Koen Kooi
2010-02-18  9:20           ` Marcin Juszkiewicz
2010-02-18  9:43             ` Koen Kooi
2010-02-18 13:30             ` Henning Heinold
2010-02-16 13:52 ` Otavio Salvador
2010-02-17  9:35   ` Martin Jansa

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='hlc4jp$cfc$1@ger.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.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.