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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
