Johannes Schauer a écrit le 02/04/2020 à 01:59 : > Hi, > > Quoting Gilles Filippini (2020-03-21 15:28:32) >> On Wed, 26 Feb 2020 19:59:20 +0100 Johannes Schauer <jo...@debian.org> wrote: >>> On Sat, 22 Feb 2020 17:45:36 +0100 Johannes Schauer <jo...@debian.org> >>> wrote: >>>> Quoting Jörg Frings-Fürst (2020-02-22 17:36:10) >>>>> Am Samstag, den 22.02.2020, 17:17 +0100 schrieb Johannes Schauer: >>>>>> Control: severity -1 important >>>>>> >>>>>> Quoting Johannes Schauer (2020-02-22 17:05:47) >>>>>>> Quoting Jörg Frings-Fürst (2020-02-22 16:48:52) >>>>>>>>> please show me evidence of that. >>>>>>>>> >>>>>>>>> Setting a bug severity to serious means that sbuild will be >>>>>>>>> removed from >>>>>>>>> testing in March. You should have evidence before such a >>>>>>>>> drastic measure is >>>>>>>>> taken. >>>>>>>> All packages that directly or indirectly have systemd as build >>>>>>>> depend can no >>>>>>>> longer be compiled. I think that is reason enough. >>>>>>> >>>>>>> Indeed I now see the problem myself. >> >> I've just been bitten by this while building stimfit into a fresh >> unstable sbuild chroot. >> >> Setting once and for all the correct permissions using sbuild-shell >> fixed the problem for this chroot: >> $ echo "/bin/chown root:root / && /bin/chmod a+rX /" | \ >> sudo sbuild-shell <sbuild-chroot> > > I may have a theory... > > All you who have this error (Jörg + Gilles), did you use a command line with > sbuild-createchroot that has "$(mktemp -d)" in it? Depending on what your > $TMPDIR is, the problem might be that the create directory has permissions > 700. > This means that the root directory of the tarball that is created will only be > readable by root which kills it for most applications. Debootstrap doesn't > care > but mmdebstrap explicitly does a "chmod 0755" on the root directory which is > why you might not see the problem with mmdebstrap but only with debootstrap. > > So could you please confirm the following: > > - try doing "tar -tvf /srv/... | head" on the chroot tarball and have a look > at the permissions of ./ -- what are they? > > - the problem only occurs when you use "$(mktemp -d)" when running > sbuild-creatchroot and it goes away if you use any other directory outside > $TMPDIR as temporary directory like for example ~/tmp. So for example > create > your chroot like this: > > $ sudo sbuild-createchroot --make-sbuild-tarball=/srv/... unstable > ~/tmp > > - if the answer to above question is "yes": when you use "$(mktemp -d)" then > the directory that is created has permissions 700, right?
The problem occurs in both cases: $ $ sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz \ --chroot-prefix=foo --keep-sbuild-chroot-dir unstable \ "$(TMPDIR= mktemp -d)" http://ftp.de.debian.org/debian ... $ tar tvaf foo.tar.gz | head -4 drwx------ pini/pini 0 2020-04-02 22:17 ./ drwxrws--- sbuild/sbuild 0 2020-04-02 22:17 ./build/ drwxr-xr-x root/root 0 2020-04-02 22:16 ./mnt/ drwxr-xr-x root/root 0 2020-04-02 22:16 ./dev/ $ sudo sbuild-createchroot --make-sbuild-tarball=bar.tar.gz \ --chroot-prefix=bar --keep-sbuild-chroot-dir unstable \ "$(TMPDIR=~/tmp mktemp -d)" http://ftp.de.debian.org/debian ... $ tar tvaf bar.tar.gz | head -4 drwx------ pini/pini 0 2020-04-02 22:26 ./ drwxrws--- sbuild/sbuild 0 2020-04-02 22:26 ./build/ drwxr-xr-x root/root 0 2020-04-02 22:25 ./mnt/ drwxr-xr-x root/root 0 2020-04-02 22:25 ./dev/ The temporary directory has permission 700 in both cases: drwx------ 22 pini pini 4096 avril 2 22:17 /tmp/tmp.wnCEvIIVxV drwx------ 22 pini pini 4096 avril 2 22:26 /home/pini/tmp/tmp.5cz5ZSXoKd This is expected (excerpt from the mktemp man page): > Files are created u+rw, and directories u+rwx, minus umask restrictions. Thanks, _g.
signature.asc
Description: OpenPGP digital signature
