Hi, Quoting Raphaël Hertzog (2015-09-02 15:50:42) > I had to reinstall a machine, but I had the possibility to keep around > all the build chroots since they were stored in a separate filesystem. > So I did that but the resulting system failed miserably. sbuild would not > run, it would immediately fail (cf log below). > > I had to resort to strace-debugging to understand that it failed > while it tried to create /var/lib/sbuild/apt.conf.XXXX in the chroot. > Since the sbuild user is created dynamically, it had a different uid > outside the chroot compared to inside the chroot. And this operation failed > with EPERM. > > IMO sbuild should: > - be fixed to error out with a clear error message of what went wrong > - probably do a "chown -R sbuild:sbuild /var/lib/sbuild" inside the chroot > just like it already does for other files > > Sample build log:
this sounds like a likely problem, given that sbuild is horrible at reporting what exactly went wrong (if something went wrong) and given that the success of the File::Temp call for /var/lib/sbuild/apt.conf.XXXXXX in lib/Sbuild/ResolverBase.pm is indeed never checked! On the other hand I am somehow unable to reproduce this bug. Using sbuild-shell I opened a shell in a local sid chroot and changed the owner of /var/lib/sbuild/ to root and removed all read and write access for everybody. But even after that I was able to build a package! Investigating further, this seems to be because `chown -R sbuild:sbuild /var/lib/sbuild` is already run in lib/Sbuild/ChrootSetup.pm (at least this explains why it works for me). So I wonder why it does not work for you? Can you try to create some steps to set up a broken chroot that exhibit the behaviour you observe? If you do not manage, maybe you can share your chroot somehow? Thanks! cheers, josch
signature.asc
Description: signature
