Hi, let me try to pick up this topic again and lets hope I dont mess up somewhere because this thread is already a bit old :)
On Sat, Aug 20, 2011 at 07:36:54PM +0200, Yann Dirson wrote: > > 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. I posted bugreports to make fakeroot and fakechroot multiarch a while ago. fakeroot: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636192 I wrote with the maintainer clint adams and he wants the fakeroot multiarch package not to require any helper (neither dh nor cdbs). I have a working update for fakeroot that makes the package multiarch but requires debhelper. I didnt find time to convert that to "do everything manually" yet. fakechroot: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632954 but the maintainer is mia and the package orphaned so someone has to care about it. > > > 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. Yes it's orphaned but timo lindfors (lindi) expressed interest in looking into the issue as well. > Note that your patch there looks more of a workaround than a real fix, > I'll see later what I can do with it. I had the same impression - if you manage to gain more insight than I was able to it would be great :) > 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 ? fakechroot can't handle statically linked binaries so it is replaced by a dummy instead same thing is done for ldd which is not replaced by a dummy but by a perl script using objdump to emulate ldd's behavior. https://github.com/fakechroot/fakechroot/wiki/ManFakechroot with respect to qtmoko, can we reevaluate the current situation? cheers, josch -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20110913061228.GA6575@hoothoot
