Hi, (I may not have been coherent last night ... Let me fix them here.)
This problem is a user setting problem of pbuilder/cowbuilder and many associated web documentation problem. eatmydata package is working OK now here. In that sense, it is not even a bug for the cowbuilder package. On Thu, Oct 16, 2014 at 05:55:30PM +0200, Mattia Rizzolo wrote: > On Thu, Oct 16, 2014 at 5:24 PM, Osamu Aoki <[email protected]> wrote: > > It looks like the sid version of eatmydata has been fixed to add > > libeatmydata1 to dep. So I do not see problem now for my sid chroot. I > > This is part of the package now being M-A capable Yes. This transition demands several package usages and guide documents to be updated. Notably, cowbuilder and git-pbuilder(git-buildpackage) related ones. This is a problem of "how we set these tools for eatmydata". > not sure what the libcowdancer library is supposed to do, but it has > nothing to do with eatmydata: > http://codesearch.debian.net/search?q=eatmydata+package%3Acowdancer > (I'd be surprise if somebody is able to call it without at least part > of the name) Well do not be surprized :-) It parses shell script as its configuration. Many users who uses pbuilder with eatmydata set up ~/.pbuilderrc. My ~./pbuilderrc after fixing for the new unstable ieatmydata package contains: | # eatmydata | if [ -z "$LD_PRELOAD" ]; then | LD_PRELOAD=libeatmydata.so | else | LD_PRELOAD="$LD_PRELOAD":libeatmydata.so | fi | export LD_PRELOAD This should be typical for people using git-buildpackage tool chain. See buggy documentation (for sid): https://wiki.ubuntu.com/PbuilderHowto https://wiki.debian.org/cowbuilder https://wiki.debian.org/git-pbuilder https://people.debian.org/~osamu/maint-guide.html#pbuilder-setup (debmake package) As you can see, they all use (stable/testing path for libeatmydata.so): | LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so | LD_PRELOAD="$LD_PRELOAD":/usr/lib/libeatmydata/libeatmydata.so No wonder it breaks under sid chroot which uses different path. > I think the point is how do you load eatmydata. If you do > printf " /usr/lib/libeatmydata/libeatmydata.so" >> /etc/ld.so.preload > like a package I just see then it will fail for sure, but if you do > LD_PRELOAD="libeatmydata.so" it will just work, with whichever arch > (as I said, an even an arm64 chroot works here). Yes, for the unstable package. > The real issue tg pointed out is if there are different version inside > the chroots and outside (like wheezy inside and sid outside) Very true. This let me spend some time to figure out. It seems both have to be the same type with the matching LD_PRELOAD setting. I had to install unstable version of eatmydata/libeatmydata1 for both. (I have testing system with sid chroot for building package. Testing migration of 82-2 is not yet.) Regars, Osamu -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
