Gilles Filippini a écrit , Le 31/08/2014 10:47: > Kurt Roeckx a écrit , Le 30/08/2014 22:32: >> On Sat, Aug 30, 2014 at 08:10:41PM +0200, Philipp Kern wrote: >>> On Sat, Aug 30, 2014 at 03:34:32PM +0200, Gilles Filippini wrote: >>>> insighttoolkit4 repeatedly FTBFS on amd64 [1] because of ENOSPC. A >>>> manual build on porterbox barriere.debian.org reported a need of ~44GB >>>> while it failed on buildd barber at approx 37GB of disk space. >>>> >>>> [1] https://buildd.debian.org/status/logs.php?pkg=insighttoolkit4&arch=amd64 >>>> >>>> I really don't know how the build space could be optimized. The only >>>> solutions I can think of right now are: >>>> * force the build on a buildd with at least 44GB of free space >>>> * do a source + amd64 binary upload instead of source only upload. >>>> >>>> Note: this is blocking the ongoing hdf5 transition. >>> >>> I wonder if we should standardize on 50 GB everywhere. But then at some point >>> there needs to be a cut-off. And if the packaging could be optimized to need >>> less (i.e. avoid unnecessary disk use), that'd be splendid. >> >> I actually don't have an amd64 buildd that has both enough RAM and >> disk space. Brahms is the only one with enough disk space, but it >> only has 2 GB of RAM and gcc gets OOM killed there. >> >> So if DSA can arange 50 GB of disk space on barber, it would could >> build it there. >> >> Since it was already build on the porterbox, do you plan to upload >> that? > > That's what I intend if there is no solution on the maintainer or buildd > sides. Uploaded. The build actually required ~48GB of disk space (before dh_compress and dh_strip). Thanks, _g.
Attachment:
signature.asc
Description: OpenPGP digital signature