On Sat, Jan 23, 2010 at 02:45:04PM +0000, Roger Leigh wrote: > On Sat, Jan 23, 2010 at 01:01:34PM +0100, Kurt Roeckx wrote: > > On Sat, Jan 23, 2010 at 11:37:38AM +0000, Roger Leigh wrote: > > > On Fri, Jan 22, 2010 at 10:31:29PM +0100, Kurt Roeckx wrote: > > > > Package: buildd > > > > Version: 0.59.1~rc1~buildd20100121.0 > > > > Severity: grave > > > > > > > > After the recent upgrade of the buildds, sbuild's gid > > > > got changed from 1000 to 106 or something simular. > > > > > > > > However, all the chroots still use gid 1000, so nothing > > > > can be build anymore. > > > > > > The postinst of sbuild does switch the sbuild group from > > > a user group to a system group. This was done in 0.59.3 > > > in May 2009. > > > > > > We take care to chown all files on the host owned by > > > group sbuild. Inside /var/lib/sbuild in the chroot, > > > this is taken care of at runtime by > > > Sbuild::ChrootSetup::basesetup which is called when > > > setting up a chroot in Sbuild::Chroot::_setup_options. > > > > > > On non-buildd hosts, such as all sbuild users using > > > testing or unstable, this group migration went > > > smoothly with no reported breakage. > > > > > > Could you let me know exactly which files and/or > > > directories are retaining the old group, and are > > > causing breakage as a consequence? > > > > Atleast everything in /build and /var/lib/sbuild > > These two should already be taken care of by basesetup. > > This does a chown of /build, and chown -R of /var/lib/sbuild, > on every sbuild invocation in that chroot. I've verified > that it's working for me by altering the group ownership and > then running sbuild; it's correctly set back to :sbuild. > > If you could try a manual run of sbuild in the chroot, > does this set the ownership correctly?
Yes it does. I think the problem was that buildd was still running and using the old group or something. Kurt -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
