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.
signature.asc
Description: Digital signature
