Hi Mattia,
Mattia Rizzolo wrote (18 Oct 2014 13:25:49 GMT) :
2) the target chroot has the libeatmydata1 package installed
That is something I can easily do (backport it).
I already planned a classic backport to wheezy-backports, once I'm
sure there are no more real big bugs with this new
On Thu, May 28, 2015 at 01:44:26PM +0200, intrigeri wrote:
Hi Mattia,
Mattia Rizzolo wrote (18 Oct 2014 13:25:49 GMT) :
2) the target chroot has the libeatmydata1 package installed
That is something I can easily do (backport it).
I already planned a classic backport to
Mattia Rizzolo dixit:
It should work just fine provided that
1) the target arch is the same as the host
This is something that will, for me, almost never be the case.
I currently have 22 chroots, one (1) of them being the same
as the host arch (x32); the others are all for a different
Control: clone -1 -2
control: reassign -2 eatmydata 82-1
control: severity -2 normal
control: retitle -2 the eatmydata binary should work with different
arches transparently
On Sat, Oct 18, 2014 at 12:51 PM, Thorsten Glaser t...@mirbsd.de wrote:
Mattia Rizzolo dixit:
It should work just fine
control: reassign 765579 debmake 4.1.7-1
control: tags 765579 pending
control: retitle 765579 update cowbuilder+eatmydata setup for post-82
On Sat, Oct 18, 2014 at 03:25:49PM +0200, Mattia Rizzolo wrote:
You're right, cloned this bug where I'll track this (I already have
sketched up an ugly
Mattia Rizzolo dixit:
For now, manually set LD_PRELOAD to libeatmydata.so works, though.
Ah ok, so I replace everywhere “eatmydata” with
“env LD_PRELOAD=${LD_PRELOAD:+$LD_PRELOAD:}libeatmydata.so”
and it should work?
2) the target chroot has the libeatmydata1 package installed
That is
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
Osamu Aoki dixit:
Well do not be surprized :-) It parses shell script as its
configuration. Many users who uses pbuilder with eatmydata set up
~/.pbuilderrc.
Ah, I do not do this.
I invoke the tools like this (scripted):
eatmydata env DIST=hardy/i386 LANG=C LC_CTYPE=C LC_NUMERIC=C \
On Oct 17, 2014 7:29 PM, Thorsten Glaser t...@mirbsd.de wrote:
Osamu Aoki dixit:
I invoke the tools like this (scripted):
eatmydata env DIST=hardy/i386 LANG=C LC_CTYPE=C LC_NUMERIC=C \
LC_TIME=C LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C LC_PAPER=C \
LC_NAME=C LC_ADDRESS=C
Hi,
http://bugs.debian.org/765579
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
hope this will migrate to testing before release.
As for the cowbuilder/libeatmydata1 problem setting non-M-A
path to
On Thu, Oct 16, 2014 at 5:24 PM, Osamu Aoki os...@debian.org 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
11 matches
Mail list logo
