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 > As for the cowbuilder/libeatmydata1 problem setting non-M-A > path to LD_PRELOAD, the root cause may not be eatmydata but cowbuilder > side. In cowbuilder chroot, > > root@goofy:/# echo $LD_PRELOAD > /usr/lib/cowdancer/libcowdancer.so > > So cowdancer library is the one to set to loads libeatmydata1. 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) > Unless it is written to understand M-A, it fails. > > I mean cowdancer is the one to be blamed. (wild guess but cowdancer is > not M-A and amd64 here.) > > What do you think? 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). The real issue tg pointed out is if there are different version inside the chroots and outside (like wheezy inside and sid outside) -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
