control: tag -1 unreproducible moreinfo control: severity -1 minor On Mon, Mar 30, 2015 at 09:11:50AM +0000, Thorsten Glaser wrote: > Debian Bug Tracking System dixit: > > >Bug #781485 [git-buildpackage] git-pbuilder: uses incorrect path for the > >LD_PRELOAD for libeatmydata.so > >Bug reassigned from package 'git-buildpackage' to 'pbuilder'. > > Huh? > > What exactly does gbp run when you invoke it like this? > > If it runs “eatmydata pbuilder”, then this is not a bug but happens > when the host is wheezy and the chroot is jessie/sid, and known. > > The correct way (currently) to do this is to invoke it like this: > > env LD_LIBRARY_PATH=/usr/lib/libeatmydata \ > LD_PRELOAD=libeatmydata.so pbuilder …
actually, the `eatmydata pbuilder` call should work just fine if you are in
testing/sid environment and you are loading a wheezy chroot. The reverse isn't
true, unless you have the testing version of libeatmydata.
This should work since libeatmydata 82-5, thanks to a patch from tg.
For Russ: yes, the library position changed to a multiarch-enabled position, and
now you can run chroot for different architecture all of them using
libeatmydata.
The actual question for the OP is: given that pbuilder has no direct support for
libeatmydata, and neither does gbp, how did you configure the whole machinery?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: Digital signature
