[Debian-med-packaging] Bug#759794: insighttoolkit4: FTBFS on amd64 with ENOSPC

[Gilles Filippini]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20140903/180b3a68/attachment.sig>