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

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