Using bitbake in minimal chroot environment

Using bitbake in minimal chroot environment

[Martin Jansa]

Hi,

I'm just thinking about using bitbake only in minimalistic 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
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.

If nobody points some big disadvantage I didn't think about, I'll give
it a try (with precompilled gentoo stage tarball it's task for half an
hour using cp :)).

Using some sofisticated sandbox setting (as gentoo ebuilds do) would be
also good alternative, is someone trying that?

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: Using bitbake in minimal chroot environment

[Philip Balister]

On 02/14/2010 05:56 AM, Martin Jansa wrote:
> Hi,
>
> I'm just thinking about using bitbake only in minimalistic 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
> 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 :)

Philip


>
> If nobody points some big disadvantage I didn't think about, I'll give
> it a try (with precompilled gentoo stage tarball it's task for half an
> hour using cp :)).
>
> Using some sofisticated sandbox setting (as gentoo ebuilds do) would be
> also good alternative, is someone trying that?
>
> Regards,
>

Re: Using bitbake in minimal chroot environment

[Frans Meulenbroeks]

2010/2/15 Philip Balister <philip@balister.org>:
> On 02/14/2010 05:56 AM, Martin Jansa wrote:
>>
>> Hi,
>>
>> I'm just thinking about using bitbake only in minimalistic 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.

>> 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 :)
>
> Philip
>
>
>>
>> If nobody points some big disadvantage I didn't think about, I'll give
>> it a try (with precompilled gentoo stage tarball it's task for half an
>> hour using cp :)).
>>
>> Using some sofisticated sandbox setting (as gentoo ebuilds do) would be
>> also good alternative, is someone trying that?
>>

Seems a good plan to me, please keep us posted.
(actually I've been considering building in a minimalistic VM)

FM

Re: Using bitbake in minimal chroot environment

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]

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.. 

If someone is interested in that chroot I can push tar.bz2 somewhere..
but I guess that it's not needed (as it's only slightly stripped stage3
gentoo tarball).

Additional apps built (qemu-kvm just because I have ASSUME_PROVIDED for
that as there is mmap issue fixed in that newer version)

qemu-kvm diffstat texi2html cvs screen subversion git bitbake

/etc/make.conf and chrootOE.sh I'm using in attachement

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

[-- Attachment #2: chrootOE.sh --]
[-- Type: application/x-sh, Size: 1020 bytes --]

[-- Attachment #3: make.conf --]
[-- Type: text/plain, Size: 733 bytes --]

CHOST="x86_64-pc-linux-gnu"
USE="mmx sse sse2 -kde -gnome -doc -epydoc -webdav -perl -berkdb -dso -nls -python -sdl"
CFLAGS="-O2 -march=barcelona -pipe -ftree-vectorize"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fvisibility=hidden"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu"
#MAKEOPTS="-j1"
MAKEOPTS="-j5"
ACCEPT_KEYWORDS="~amd64"
PORTDIR=/usr/portage
PORTAGE_TMPDIR=/tmp/tmpwork
DISTDIR=/tmp/distfiles
PKGDIR=/tmp/binpkgs
FEATURES="sandbox usersandbox"
GENTOO_MIRRORS="http://gentoo.mirror.web4u.cz/distfiles/"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
PORTAGE_ECLASS_WARNING_ENABLE="0"
QEMU_SOFTMMU_TARGETS="arm"
QEMU_USER_TARGETS="arm armeb"

PORTDIR_OVERLAY="
/usr/local/portage
"

Re: Using bitbake in minimal chroot environment

[Frans Meulenbroeks]

2010/2/15 Martin Jansa <martin.jansa@gmail.com>:
> 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..

Someone else told me the same today.
What exactly causes this? I would expect I/O to be the differentiating
factor as memory access and executing instructions should take the
same time, shouldn't it?
>
> If someone is interested in that chroot I can push tar.bz2 somewhere..
> but I guess that it's not needed (as it's only slightly stripped stage3
> gentoo tarball).
>
> Additional apps built (qemu-kvm just because I have ASSUME_PROVIDED for
> that as there is mmap issue fixed in that newer version)
>
> qemu-kvm diffstat texi2html cvs screen subversion git bitbake
>
> /etc/make.conf and chrootOE.sh I'm using in attachement

Thanks, will have a look at it!

Frans
>
> Regards,
>
> --
> uin:136542059                jid:Martin.Jansa@gmail.com
> Jansa Martin                 sip:jamasip@voip.wengo.fr
> JaMa
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>

Re: Using bitbake in minimal chroot environment

[Martin Jansa]

On Mon, Feb 15, 2010 at 06:57:22PM +0100, Frans Meulenbroeks wrote:
> Someone else told me the same today.
> What exactly causes this? I would expect I/O to be the differentiating
> factor as memory access and executing instructions should take the
> same time, shouldn't it?

AFAIK virtualized I/O is slowest part of virtualized world and building
with bitbake is IMHO mostly about I/O.

I'm running my gentoo system upgrades as well as all bitbake builds
(workdirs) on raid0 - strip over 3 SATA2 disks (before that I was using
huge tmpfs in RAM for workdirs - but that's not usable ie for OO.org
build :))

And with chroot I can use it without any problem (just updated path in
already used mount --bind).

Also for running it from VM I would need to update host kernel from time
to time, on the other side sharing kernel with my running system didn't
create any OE related issue (except that sanity check for mmap with 
2.6.33+ - which is already fixed)

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: Using bitbake in minimal chroot environment

[Mike Westerhof]

Frans Meulenbroeks wrote:
> 2010/2/15 Martin Jansa <martin.jansa@gmail.com>:
>>> 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..
> 
> Someone else told me the same today.
> What exactly causes this? I would expect I/O to be the differentiating
> factor as memory access and executing instructions should take the
> same time, shouldn't it?

I build in a VM often, and the difference is not very significant.  In
fact, I can't measure the difference in building SlugOS using the wall
clock.

I also tried placing all of my TMPDIR on a tmpfs on my 8GB RAM system,
and building SlugOS -- again, no difference compared to the normal SATA
hard drive for TMPDIR.

So my conclusion is that I/O is not the bottleneck for my OE builds, and
that's the only area where a VM is significantly different in terms of
performance (at least how I use VMs; perhaps other builds may observe
differences).

Before I ended up on my current contract, which locks me away behind
draconian firewalls, I used to take my autobuilder on the road with me
as a VM, building SlugOS and several of the OpenMoko distros -- I
heartily recommend that solution!

-Mike (mwester)

Re: Using bitbake in minimal chroot environment

[Martin Jansa]

On Mon, Feb 15, 2010 at 12:22:56PM -0600, Mike Westerhof wrote:
> So my conclusion is that I/O is not the bottleneck for my OE builds, and
> that's the only area where a VM is significantly different in terms of
> performance (at least how I use VMs; perhaps other builds may observe
> differences).

Interesting!

out of curiosity, how many threads were you using for that test? 
I'm using:
PARALLEL_MAKE="-j4"
BB_NUMBER_THREADS = "2"
for builds with my 1x AMD Phenom workstation at home and I would expect
even more I/O with more concurrent threads.

I didn't perform any sophisticated benchmark, but when I was using tmpfs
I compared build times with genlop/qlop gentoo utility which shows
history of all performed builds with time it used. So I've seen
significant speedup when switched from single-drive to tmpfs, then not
so significant slowdown when switched from tmpfs to raid0. But then I
didn't recheck diff between single-drive builds and raid0 (because
versions built were usually quite different)

Kind regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: Using bitbake in minimal chroot environment

[Koen Kooi]

-----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-----

Re: Using bitbake in minimal chroot environment

[Frans Meulenbroeks]

2010/2/15 Koen Kooi <k.kooi@student.utwente.nl>:
> -----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-----
>

Interesting results.
I had expected that ramfs would improve things. The only explanation I
have that it does not is that if you have sufficient RAM most of the
data will remain in the cache.
(although listening to the hard disk when building (dual core, 32 bit
OS, 4GB ram gives reason to suspect otherwise).

Frans.

Re: Using bitbake in minimal chroot environment

[Tom Rini]

On Mon, 2010-02-15 at 19:43 +0100, Koen Kooi wrote:

[snip]
> 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 :)

What are you (and everyone else saying it's fine) running the VM with?
I've got people reporting just unusable build times inside VMs on what
should be reasonable hardware.  That said, I've profiled some builds and
seen that IO is not a bottleneck (stuff like waiting for virtual/libc to
stage and gcc-cross to get populated is).

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: Using bitbake in minimal chroot environment

[Koen Kooi]

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

On 15-02-10 23:04, Tom Rini wrote:
> On Mon, 2010-02-15 at 19:43 +0100, Koen Kooi wrote:
> 
> [snip]
>> 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 :)
> 
> What are you (and everyone else saying it's fine) running the VM with?
> I've got people reporting just unusable build times inside VMs on what
> should be reasonable hardware.  That said, I've profiled some builds and
> seen that IO is not a bottleneck (stuff like waiting for virtual/libc to
> stage and gcc-cross to get populated is).

I'm using virtualbox on a Dell D630 (core2duo, 4GB of ram) laptop. I
managed to cut 2 hours (yes, hours) of the buildtime by moving lots of
stuff to new style staging. With a big tmpdir (6 machines, 2 different
archs, lots of machine specific stuff) old-style staging takes eons to
stat every file and build a list.
Using virtualbox on a 2GB osx machine isn't running so hot because OSX
seems to go out of its way to put the VM in swap instead of ram :(

regards,

Koen

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

iD8DBQFLecefMkyGM64RGpERAmLWAJ0dsBhzCnV86Z/rxJKVVGMUS+4q2wCfTPZb
ykkNNSvTlPN2ZEIQT8xgfqY=
=PZD0
-----END PGP SIGNATURE-----

Re: Using bitbake in minimal chroot environment

[Koen Kooi]

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

On 15-02-10 23:04, Tom Rini wrote:
> On Mon, 2010-02-15 at 19:43 +0100, Koen Kooi wrote:
> 
> [snip]
>> 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 :)
> 
> What are you (and everyone else saying it's fine) running the VM with?
> I've got people reporting just unusable build times inside VMs on what
> should be reasonable hardware.

If you're on cpus with hardware virtualization support (e.g. intel
core2) you do need to enable some bits in the bios (iirc turn on PAE) to
enable the 'zero overhead' stuff intel/amd marketing are raving about.

regards,

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

iD8DBQFLelMdMkyGM64RGpERAv5pAKCNr+wJqr3OPyJG++h1rF6hLPDtowCfXiUr
skypepZKHahO5rEr75qXzkc=
=kKuJ
-----END PGP SIGNATURE-----

Re: Using bitbake in minimal chroot environment

[Otavio Salvador]

Hello,

On Sun, Feb 14, 2010 at 11:56 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> If nobody points some big disadvantage I didn't think about, I'll give
> it a try (with precompilled gentoo stage tarball it's task for half an
> hour using cp :)).
>
> Using some sofisticated sandbox setting (as gentoo ebuilds do) would be
> also good alternative, is someone trying that?

Take a look in cowbuilder, from Debian. It uses copy-on-write to
create chroots for building packages in a clean chroot; it might be
used to prepare a clean chroot to a full build of OE from time to OE
and catch bugs on it.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: Using bitbake in minimal chroot environment

[Martin Jansa]

On Tue, Feb 16, 2010 at 11:52:09AM -0200, Otavio Salvador wrote:
> Hello,
> 
> On Sun, Feb 14, 2010 at 11:56 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > If nobody points some big disadvantage I didn't think about, I'll give
> > it a try (with precompilled gentoo stage tarball it's task for half an
> > hour using cp :)).
> >
> > Using some sofisticated sandbox setting (as gentoo ebuilds do) would be
> > also good alternative, is someone trying that?
> 
> Take a look in cowbuilder, from Debian. It uses copy-on-write to
> create chroots for building packages in a clean chroot; it might be
> used to prepare a clean chroot to a full build of OE from time to OE
> and catch bugs on it.

Thanks, I'll check that later, now I'm quite happy with chroot I have
now.

Only problem I had was with cvs for autopoint. It clearly has problem
when used on chroot/mount --bind and also with newer glibc.

So finally I found working combination in gentoo.
Reported with patch here:
http://bugs.gentoo.org/show_bug.cgi?id=289022

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: Using bitbake in minimal chroot environment

[Marcin Juszkiewicz]

Dnia poniedziałek, 15 lutego 2010 o 23:04:37 Tom Rini napisał(a):

> What are you (and everyone else saying it's fine) running the VM with?
> I've got people reporting just unusable build times inside VMs on what
> should be reasonable hardware.

From my tests VM builds are slower on my hardware. But thats due to fact that 
VirtualBox or KVM use just one core for VM when natively I can use all 
4 cores. And this makes a difference.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: Using bitbake in minimal chroot environment

[Koen Kooi]

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

On 18-02-10 10:20, Marcin Juszkiewicz wrote:
> Dnia poniedziałek, 15 lutego 2010 o 23:04:37 Tom Rini napisał(a):
> 
>> What are you (and everyone else saying it's fine) running the VM with?
>> I've got people reporting just unusable build times inside VMs on what
>> should be reasonable hardware.
> 
> From my tests VM builds are slower on my hardware. But thats due to fact that 
> VirtualBox or KVM use just one core for VM when natively I can use all 
> 4 cores. And this makes a difference.

Virtualbox uses 2 cores for my vm, but my laptop only has 2 :) You can
even assign it virtual cores if you wish. In the XP and OSX vbox,
haven't tried the linux one yet.

regards,

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

iD8DBQFLfQvQMkyGM64RGpERAiJmAKCeYVyOn67vFW16DiBNagBqvAjWMACdG7p2
RIcTn8+tG1eIcDFeccakerY=
=qVR5
-----END PGP SIGNATURE-----

Re: Using bitbake in minimal chroot environment

[Henning Heinold]

On Thu, Feb 18, 2010 at 10:20:05AM +0100, Marcin Juszkiewicz wrote:
> Dnia poniedziałek, 15 lutego 2010 o 23:04:37 Tom Rini napisał(a):
> 
> > What are you (and everyone else saying it's fine) running the VM with?
> > I've got people reporting just unusable build times inside VMs on what
> > should be reasonable hardware.
> 
> From my tests VM builds are slower on my hardware. But thats due to fact that 
> VirtualBox or KVM use just one core for VM when natively I can use all 
> 4 cores. And this makes a difference.
> 
> Regards, 
> -- 
> JID:      hrw@jabber.org
> Website:  http://marcin.juszkiewicz.com.pl/
> LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

On newer kvm you can use:

-smp n
           Simulate an SMP system with n CPUs. On the PC target, up to 255 CPUs are supported. On Sparc32 target, Linux limits the
           number of usable CPUs to 4

Bye Henning