[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Emdebian on armel: packages fail to build.

On Sun, 30 Nov 2008 20:02:02 +0100
"Dimitri Michaux" <dimitri.michaux@gmail.com> wrote:

> Hi Neil,

Please keep replies going to the list.

> Thank you for the fast and clear reply.
> > busybox is currently an "out-of-tree" manual build due to problems
> > with chpasswd and the Lenny freeze. Obtain the current source
> > package from the emdebian/ repository and use that.
> Ok, I will try that the next time I have time hopefully tomorrow or
> the day after tomorrow.
> > libstdc++6 and libgcc1 are from gcc-4.3 and are perennial problems.
> > You will need the full build log to find out what is going wrong.
> Were can I find the build log? I've looked around in the work
> directory and the home directory, but I can't find it.

If your emdebian working directory is /opt/emdebian inside the chroot,
the build log will be in:

Just use find for '*.build'.

However, if you actually run Debian unstable, all of this becomes a lot

> I'm running sid on my desktop, but I don't want to bloat or criple my
> system. so I'm compiling from within a Debian Sid chroot environment.
> Do you suggest something like this:
> chroot sid-rootfs emsource --arch armel -b --build-dep foo


On your normal sid system, outside any chroot:
$ sudo empdebuild create
$ em_autobuild --pbuilder --arch armel --log --package foo

Use a disposable chroot, via pbuilder. You create a tarball that is
decompressed each time, the build happens inside the chroot and all
the changes to the chroot are thrown away whilst the packages and the
build logs are copied out. All you have outside the chroot are the
sources, the patches, the packages, the build logs and the apt-cross
cache data.

Use em_autobuild --log, the build logs will go in the buildd/ directory
beneath your emdebian-tools working directory *outside* the chroot.

A Sid chroot is only needed if you are not running Sid. What you need
is a cross-building chroot and to be able to throw that chroot away
each time the build ends whilst copying the results out. pbuilder
provides that part of the code, empdebuild adds the cross-building
support. Do not use a chroot within a chroot unless you are not running

> > Now is probably not the time to be doing Emdebian Crush builds for
> > armel (or any architecture other than ARM). Everything has been
> > stalled by the delays to Lenny. Do us all a favour and use your
> > time to fix RC bugs so that we can release Lenny and then I'll be
> > able to help you.
> I would like to do that, but I don't have an arm board or do you mean
> fixing bugs in Lenny?

Fixing RC bugs in Debian to get Lenny released.

> > In the meantime, I'm looking at preparing Emdebian Grip for a list
> > of architectures, not just armel. Even there, problems exist that
> > cannot be fixed properly due to the freeze.
> I've tried grip, it's much faster, but when I tried to build a rootfs
> I failed on one package, don't know which anymore, but the problem
> could have also been that I tried to build the rootfs using
> debootstrap with --foreign and not with emsandbox

emsandbox cannot use Grip packages (yet). You need to use Grip natively
- on the same architecture. Grip does not build packages, it merely
repacks what already exists in Debian. It will always be faster.
However, there are bugs that prevent the normal use of such rootfs
setups - install-info needs to be replaced and update-alternatives
needs to be patched to not fail if a manpage does not exist when trying
to set it as an alternative for another manpage that does not exist.

Grip does build a working debootstrap environment when used natively
but the ongoing issue is that the bugs cannot be fixed because we
cannot get the fixes into Sid.

> It still isn't clear to me if I should compile from sid source
> packages or from lenny source packages.

targetsuite defaults to sid, unstable. Just as in Debian, you always
build on and for unstable. There are exceptional cases where you build
for testing or stable in Debian but those cases do not (yet) apply to
Emdebian (because we have no stable releases to which we need to
backport anything).

Everything depends on Sid but as Sid is frozen to release Lenny,
everything is waiting for Lenny. Not to use Lenny, but to get access to
Sid again to get the bugs fixed. Bugs in Emdebian builds are not
important enough to actually delay Lenny or to be fixed during the
Lenny freeze.

The longer it takes to release Lenny, the worse things will get in
Emdebian in term of unfixed bugs and build failures.

Work on getting Lenny released - that way everyone wins. We get our
first stable release, we get access to unstable to fix things for the
next release and we can start to implement changes in other parts of
Debian that help the development of other parts of Emdebian (like



Neil Williams

Attachment: pgp24Dk8meOO7.pgp
Description: PGP signature

Reply to: