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
Reply to: