[buildd-tools-devel] Bug#626826: Bug#626826: sbuild: /var/lock being absolute symlink -> "Another sbuild process (...) is currently using the build chroot"

[Roger Leigh]

On Sun, May 15, 2011 at 07:25:19PM +0200, Jakub Wilk wrote:
> Due to the advent of /run, I manually changed layout of my chroots,
> so that they look like this:
> 
> $ ls -ld /srv/chroots/unstable-i386/{var,run}/lock
> drwxrwxrwt 2 root root 4096 May 15 01:19 /srv/chroots/unstable-i386/run/lock
> lrwxrwxrwx 1 root root    9 May 15 14:59 /srv/chroots/unstable-i386/var/lock -> /run/lock
> 
> Unfortunately, sbuild is not happy with such a layout, and I cannot
> build more than one package in parallel (even though I use cloned
> chroots, so it should be possible). I get this message instead:
> 
> Another sbuild process (job zlib_1.2.3.4.dfsg-3, pid 5534 by user sbuild) is currently using the build chroot; waiting...
> 
> It looks like sbuild uses /run/lock from the outside of the chroot.
> When I changed the symlink to a relative one, the problem
> disappeared.

Thanks for bringing this up.  I think that, by default, initscripts
will leave the chroot /var/run and /var/lock in place, which implies
that they will be separate from the host unless you switch to using
/run with /var/run and /var/lock as symlinks (as you have done).
However, this won't be the case for newly-debootstrapped chroots once
base-files is updated.

I would certainly prefer to use relative symlinks--I took this up on
debian-policy last week.  This is because relative symlinks between
top-level directories must be absolute according to section 10.5.
I'll certainly bring this issue to their attention.

sbuild could switch to using /run/lock directly.  However... if it's
set up using the default scheme, it will be symlinked to /var/lock
which will again be the host's /var/lock.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110515/3fb4b9d3/attachment.pgp>