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: /opt/emdebian/trunk/g/gcc-4.3/trunk/gcc-4.3_4.3.2-1em1_arm.build Just use find for '*.build'. However, if you actually run Debian unstable, all of this becomes a lot easier. > 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 No. 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 Sid. > > 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 TDebs). http://people.debian.org/~codehelp/tdeb/ -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp24Dk8meOO7.pgp
Description: PGP signature