Re: Using bitbake in minimal chroot environment

[Martin Jansa <martin.jansa@gmail.com>]

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