Hello, Ketvirtadienis 27 Birželis 2013 14:37:17 rašė: > On Thu, Jun 27, 2013 at 08:05:17PM +0200, Aurelien Jarno wrote: > > The problem is that the amd64 and ia64 build daemons which tried to > > build this version of eglibc are all using eatmydata. eatmydata do not > > correctly simulate fsync, msync and fdatasync as cancellation points. It > > should be possible fixing that by calling pthread_testcancel() from > > eatmydata, though I haven't tried that yet. > > It seems pretty testsuite-hostile to wrap builds in any LD_PRELOAD, as > you have no idea if the thing(s) the testsuites might be checking are > now invalidated by said preload. > > Was there actually a sane rationale put forward for this buildd change? > I can see the argument for wanting the apt/dpkg bits wrapped, but doing > so for the build itself just seems like asking for trouble, with very > little potential gain. Speaking with my maintainer hat on, when I first came upon eatmydata, I thought: it will be a huge time saviour for personal and maybe debian buildds. My primary idea was to wrap apt/dpkg with eatmydata since they use fsync() and friends *really* extensively. Too bad fsync() used to be (still is?) very slow on btrfs filesystem. For exactly this purpose eatmydata script supports "symlink mode" (see eatmydata(1)). Doing: # ln -s /usr/bin/eatmydata /usr/local/bin/apt-get # ln -s /usr/bin/eatmydata /usr/local/bin/dpkg in the buildd environment should be enough to wrap only these tools without too much hassle (i.e. sbuild configuration changes). I'm not sure how I feel about wrapping the whole build. Maybe it's not such a bad idea after all if somebody tested that it speeded things up much more significantly. However, I just wanted to let you know that a more conservative approach is possible. P.S. I'm aware that upstream released a new upstream release with the fix for this bug. However, packaging it might take some time due to significant buildsystem changes and other stuff. However, hopefully, I will get it eventually done in a few weeks. -- Modestas Vainius <modax@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part.