[buildd-tools-devel] Bug#825359: sbuild: unrealistic figure about total space used

[Santiago Vila]

On Fri, 1 Jul 2016, Johannes Schauer wrote:

> On Thu, 30 Jun 2016 22:42:47 +0200 Helge Deller <deller at gmx.de> wrote:
> > For example, the "binutils" logs (see last column):
> > https://buildd.debian.org/status/logs.php?pkg=binutils&arch=hppa show that
> > sbuild version 0.68.0 gives a usage of 740 MB, while starting with sbuild
> > version 0.69.0 it gives a usage of ~4.30 GB disc usage.
> 
> This is another interesting datapoint. The increase here is consistently about
> six times of the former value.

I have several virtual machines. Sometimes I use stretch, sometimes I
use jessie and sbuild from backports.

This is the data I have for binutils:

binutils_2.26-10_amd64-20160610-1951
sbuild (Debian sbuild) 0.69.0 (08 May 2016) on bdj2
Build needed 04:56:11, 31592136k disc space

binutils_2.26-10_amd64-20160612-1951
sbuild (Debian sbuild) 0.69.0 (08 May 2016) on bdj2
Build needed 04:57:32, 31592172k disc space

binutils_2.26-11_amd64-20160618-1950
sbuild (Debian sbuild) 0.69.0 (08 May 2016) on bdj2
Build needed 04:51:15, 31590444k disc space

binutils_2.26-12_amd64-20160630-0751
sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on marcial
Build needed 03:44:52, 10547196k disc space


and this is the data I have for firefox-esr, another affected package:


firefox-esr_45.0.2esr-1_amd64-20160419-0751
sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on skywalker3
Build needed 01:41:58, 10643840k disc space

firefox-esr_45.1.1esr-1_amd64-20160513-0751
sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on skywalker2
Build needed 01:33:36, 10632576k disc space

firefox-esr_45.2.0esr-1_amd64-20160613-2145
sbuild (Debian sbuild) 0.69.0 (08 May 2016) on bdj2
Build needed 03:01:49, 1946533792k disc space

firefox-esr_45.2.0esr-1_amd64-20160630-0358
sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on marcial
Build needed 02:05:56, 10462332k disc space


My virtual machine bdj2 is somewhat special because it runs stretch
but it is still using a custom kernel 3.16.7 from jessie.

Maybe that's the way to reproduce it, or maybe not.

Thanks.