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

[Gert Wollny]

Disk space used for building of  ITK 4.8 with only 2 and 3 dimensions
to wrap: 

chroot base system with all deps installed: 3.0GB 

Source code unpacked:   ~1.0GB 
Build dir 36GB 
Debian dir   5.1GB Sum: 42GB 

Total:  45GB 

The now successful build in the log report 50.72 GB [1], which means we
look at 5-6 GB difference. 

Also of interest: 

The difference between the stripped and unstripped python bindings *.so
files is about 3.4GB (for 2;3 dims wrapped), I guess that a copy of
this stripped info would add to the build process if debug packages are
generated automatically. 


Best, 
Gert




 

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

[Gert Wollny]

Hello Steven, 

On Sun, 2015-10-04 at 11:09 -0500, Steve M. Robbins wrote:
> There are two things that could probably help:
> > 
> >  - change the python-binding dimensions to use only 2 an 3. 
> 
> I can definitely make this change for the next upload.  
> Did you ever quantify whether this saves on disk space?

At that time I didn't :-/ I'll see what this does now. I'll get back to
you when it's done. 

> 
> I think in the coming months there will be an archive-wide automatic
> debug package generation [1] .  We can then drop the -dbg package.  I
> haven't checked, but I suspect it will still require building with 
> -g.

Which means that during the package build at least the compressed size
of the python bindings debug info might be added to the build size. 

Best, 
Gert 

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

[Steve M. Robbins]

Hello Gert,

I ran into this issue again today which prompted me to re-read this bug log.

On Sat, 30 Aug 2014 16:15:19 +0200 Gert Wollny  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.
> 
> There are two things that could probably help:
> 
>  - change the python-binding dimensions to use only 2 an 3. I enabled
>also 4 because in our lab we have to deal with 3D+t data, but in the
>end using 4D data with python is not such a good idea memory-wise. 
>(On Monday I will check how much this actually saves)

I can definitely make this change for the next upload.  
Did you ever quantify whether this saves on disk space?

>  - build with -g1 or even -g0 (have to look up if this is not against
>Debian Policy).  The python bindings creates a lots of debugging info
>that gets thrown away anyway. We would then also have to disable the
>lib*-dbg package.

I think in the coming months there will be an archive-wide automatic debug 
package generation [1] .  We can then drop the -dbg package.  I haven't 
checked, but I suspect it will still require building with -g.

[1]  https://lists.debian.org/debian-devel/2015/08/msg00443.html

Thanks,
-Steve


signature.asc
Description: This is a digitally signed message part.

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

[Gert Wollny]

 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.

There are two things that could probably help:

 - change the python-binding dimensions to use only 2 an 3. I enabled
   also 4 because in our lab we have to deal with 3D+t data, but in the
   end using 4D data with python is not such a good idea memory-wise. 
   (On Monday I will check how much this actually saves)
 - build with -g1 or even -g0 (have to look up if this is not against
   Debian Policy).  The python bindings creates a lots of debugging info
   that gets thrown away anyway. We would then also have to disable the
   lib*-dbg package.


   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org