On Wed, Dec 28, 2022 at 12:10:51AM +0100, Johannes Schauer Marin Rodrigues wrote: > Note, that if you keep upgrading a Debian unstable chroot across multiple > releases, it will end up looking slightly different than a freshly > debootstrapped Debian unstable chroot. So I think there is value in > semi-regularly re-creating the build chroot from scratch. Maybe write a script > that does what you need?
That's true, but the number of user/group id's that sbuild would actually care about is probably quite small and might very well just be sbuild:sbuild I would think, no? > Finally, I think this is something that could be solved in sbuild. Ultimately, > schroot is able to do things as the root user, so it should have sufficient > permissions to fix up a chroot that carries incorrect permissions. Could you > quickly note in a bug against sbuild on the Debian BTS which steps exactly you > carried out so that I am able to reproduce your problem? Sure, no problem. > I'm making no promises that I'll find the time to improve the schroot backend > of sbuild to survive the kind of chroot-rsync that you have performed but if > this is important to you, then maybe we can make a trade and I implement this > sbuild functionality and you have a look at pull requests > https://github.com/tytso/e2fsprogs/pull/118 or #107 and leave some comments in > return? :) Thanks for the reminder, I'll take a look. Most of the patch proposals for e2fsprogs end up going to linux-e...@vger.kernel.org (so that other ext4 developers can review them), and I sometimes forgot to look over the github pull requests. I'm also about to go on a Panama Canal cruise, where my internet access may be limited (which is why I was trying to get sbuild setup on my laptop in the first place :-), and e-mail has the advantage of being much easily cacheable using offlineimap... - Ted
