Re: A couple of polystrap patches, and more problems to be solved

On Thu, Jun 30, 2011 at 08:36:23AM +0200, Johannes Schauer wrote:
> > It looks like fakeroot and fakechroot are both required in the rootfs:
> > [...]
> > Has anyone encountered this problem ?
> You need to make foreign fakeroot/fakechroot libraries accessible by
> putting shared libraries of your target architecture in the adequate
> library directory. For example for armel I do this:

I had suspected something like that, but unfortunately did not got
further in that direction than noticing the dpkg-cross does not handle
those 2 packages as I had expected.

In fact, fake*root being able to find the shared libs in /usr/lib/,
dpkg-cross would probably have worked at low cost by relocating those
paths in the offocial debs - but it looks unlikely to get such a
change done in a squeeze update.

For ease of use, it would still be great to have dpkg-cross deal with
those special packages.  I don't like adding special cases, but if
dpkg-cross is doomed to the pre-multiarch era, maybe this would be -
although borderline, I admit - acceptable ?


> wget http://ftp.debian.org/debian/pool/main/f/fakechroot/fakechroot_2.14-1_armel.deb
> wget http://ftp.debian.org/debian/pool/main/f/fakeroot/fakeroot_1.14.5-1_armel.deb
> sudo mkdir -p /usr/lib/arm-linux-gnueabi/
> dpkg-deb --fsys-tarfile fakeroot_1.14.5-1_armel.deb | sudo tar -xf - --strip-components=4 -C /usr/lib/arm-linux-gnueabi/ ./usr/lib/libfakeroot/libfakeroot-sysv.so
> dpkg-deb --fsys-tarfile fakechroot_2.14-1_armel.deb | sudo tar -xf - --strip-components=4 -C /usr/lib/arm-linux-gnueabi/ ./usr/lib/fakechroot/libfakechroot.so

For a dpkg-cross-compatible squeeze setup, that gives:

dpkg-deb --fsys-tarfile fakeroot_1.14.4-1_armel.deb | sudo tar -xf - --strip-components=4 -C /usr/arm-linux-gnueabi/lib/ ./usr/lib/libfakeroot/libfakeroot-sysv.so
dpkg-deb --fsys-tarfile fakechroot_2.9-1.1+squeeze1_armel.deb | sudo tar -xf - --strip-components=4 -C /usr/arm-linux-gnueabi/lib/ ./usr/lib/fakechroot/libfakechroot.so


> Probably also something that multiarch is able to solve?

As I understand it, it will be a bug if the preload libs are not moved
to multiarch dirs.


> > Nevertheless, even with that hack, polystrap later fails with:
> > 
> > + fakechroot chroot qtmoko-rootfs /var/lib/dpkg/info/bluez-alsa.preinst install
> > [...]/qtmoko-rootfs/bin/sh: Can't open /var/lib/dpkg/info/bluez-alsa.preinst
> > 
> > ... although that preinst script does exist in the rootfs.  However,
> > it does not exist in my /, whereas the ones which were successfully
> > launched do exist.
> 
> This sounds like: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611156

Yes.  But I just notice that fakechroot has been recently orphaned
following maintainer becoming MUA, so no feedback to be waited for
here.

Note that your patch there looks more of a workaround than a real fix,
I'll see later what I can do with it.


> > Hm, not so true: x11-common still spits an anoying error:
> > 
> > + fakechroot chroot qtmoko-rootfs /var/lib/dpkg/info/x11-common.preinst install
> > Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Debconf/Config.pm line 22.
> > /var/lib/dpkg/info/x11-common.config: 127: awk: not found
> > /var/lib/dpkg/info/x11-common.preinst: 134: awk: not found
> > 
> > ...although I have gawk installed, the alternative has not been
> > created at that time.
> 
> Maybe connected to the fakechroot issue? Or in some other way connected
> to the unsolved problems above? See if it's still there once you have
> the fakeroot/fakechroot libraries in /usr/lib/arm-linux-gnueabi/ and
> fixed your fakechroot with the patch I provided in the bugreport.

The fake*root libs should not matter, my hack was also causing the
same ones to be used, although from a different dir.  And if I apply
your workaround to the native fakeroot, the same problems still occur.

> > <digression>
> > Looks like a sign that a step-by-step process would be needed, much
> > like apt is capable to finish configuration of some packages before
> > unpacking others.  In that case, it could be sufficient to first
> > install and configure the base system, and then call multistrap a
> > second time for extra packages - or make it just generic and let the
> > user define as many successive multistrap runs as he may need.
> > 
> > This also brings me to another question: the run of *.preinst _after_
> > having unpacked the deb.  While it is probably necessary (and maybe
> > even safe ?  I have not looked at how d-i does) for essential
> > packages, for installation of later packages, it would surely be safer
> > to run the preinst first, as they are intended.  That also seems to
> > hint for multiple steps, with "unpack-before-preinst" being a per-step
> > option.
> > </digression>
> > 
> > Afterwards, both configure attempts fail because of lack of ldconfig -
> > I'm not sure to understand what is supposed to provide them:
> > 
> > + fakechroot chroot qtmoko-rootfs /usr/bin/dpkg --configure -a
> > dpkg: warning: 'ldconfig' not found in PATH or not executable.
> > dpkg: 1 expected program not found in PATH or not executable.
> > NB: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.
> > + fakechroot chroot qtmoko-rootfs /usr/bin/dpkg --configure -a
> > dpkg: warning: 'ldconfig' not found in PATH or not executable.
> > dpkg: 1 expected program not found in PATH or not executable.
> > NB: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.
> 
> Using your provided config I can perfectly build a qtmoko rootfs here.

Could you send me the polystrap log under sh -x ?

I fail to see why mawk would get configured before x11-common on your
machine and not on mine :)

As for ldconfig, it may just be failing because I have a
./sbin/ldconfig.REAL here, but to better understand, I'd need some
background about *why* these backups are taken, and *who* is supposed
to mess with those files, which we don't want to.  Could you add a
small comment nearby in the script to make it clear ?

Best regards,
-- 
Yann