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

[Johannes Schauer]

Hi,

Quoting Santiago Vila (2016-07-01 10:44:28)
> > Santiago, I noticed that you are using a directory type chroot without
> > using union-type=overlay. Could it be that your /chroot/stretch/build
> > directory contains leftovers of previous builds?
> 
> That both can't be and should not be :-)
> 
> It "can't be" because even if du is accounting for any leftover,
> in either case the reported space would never be higher than the disk
> size (I don't have such a big disk).
> 
> Also, it "should not be" because sbuild creates a temporary directory in
> /chroot/stretch/build named
> 
> /chroot/stretch/build/sourcename-randomstring
> 
> I want to believe that the "du" command is performed on this last
> directory, not on its parent, but I will leave this to you to check, since
> you know the code a lot better than me.

indeed, unless I am missing something, any invocation of 'du' in the sbuild
code base operates on the right directory, namely the one that is replaced with
<<PKGBUILDDIR>> in the build log and which takes the form of:

/build/srcpkgname-randomstring/srcpkgname-version

Thus, the directory should be unique for each build and not contain anything
from possibly parallel builds.

The only other du usage is on the files generated by sbuild, for example the
.deb packages it leaves outside the chroot. But that path also exactly points
at the .deb...

It would indeed help most if I could see the problem in one of my own machines.
But so far I'm unable to reproduce the issue.

Could you maybe:

 1. use debootstrap to create a new chroot
 2. bind-mount /dev, /proc and /sys into that
 3. chroot into the directory
 4. install sbuild
 5. run sbuild-update --keygen
 6. run sbuild-createchroot
 7. build a package

For me, following these steps lets sbuild produce the expected output. Can you
confirm this? I can also send you a sequence of command line invocations to
achieve the above if that makes things easier for you.

If you can confirm this, can you show me what the difference is between that
setup and yours?

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160701/cefd8f0e/attachment.sig>