I'm using Thorsten's regression report in #983423 as my representative sample of a package that regressed with schroot 1.6.13-4, because mksh builds much more quickly than gcc-14, but I suspect that the same would apply equally to Adrian's regression report in #856877: the important factor is probably just "any package that wants to run script(1) or expect(1)".
I was not able to reproduce the mksh build failure, so there must be some relevant difference in setup (other than CPU architecture, which shouldn't actually matter here) between the affected -ports buildds and my attempt to set up a mockup of a buildd. Please could a buildd operator provide more details of how something resembling the -ports buildd environment can be replicated in a test VM? On Mon, 19 Aug 2024 at 17:02:33 +0100, Simon McVittie wrote: > On Sun, 18 Aug 2024 at 23:44:57 +0000, Thorsten Glaser wrote: > > On three buildds, mksh FTBFS already because the whole > > /dev/ptmx and /dev/pts stuff is malfunctioning again > > Which buildds? Are you referring to -ports builds > https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=powerpc&ver=59c-39&stamp=1724031073&raw=0, > https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=ppc64&ver=59c-39&stamp=1724031078&raw=0, > https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sparc64&ver=59c-39&stamp=1724031447&raw=0 > each of which reported > "script: failed to create pseudo-terminal: Permission denied"? I was unable to reproduce this build failure in an amd64 unstable VM (created with autopkgtest-build-qemu, if it matters), coincidentally with a 6.9.12-1 kernel matching those buildds, by running these commands as a user in the sudo and sbuild groups from a virtual console or from an interactive ssh shell: sudo sbuild-createchroot sid /srv/sid http://192.168.122.1:3142/debian sbuild -dsid mksh where http://192.168.122.1:3142 is an apt-cacher-ng instance (replace that argument with http://deb.debian.org/debian or similar if required). I also tried running sbuild with no controlling tty, by doing this outside the test VM: ssh -T user@testvm sbuild -n -dsid mksh and that also seems to be working fine: mksh can run its test suite involving script(1), and the test suite and build succeed. sbuild-createchroot defaulted to creating this schroot configuration: [sid-amd64-sbuild] description=Debian sid/amd64 autobuilder groups=root,sbuild root-groups=root,sbuild profile=sbuild type=directory directory=/srv/sid union-type=overlay There must presumably be something different about how sbuild-createchroot and schroot are configured or invoked on the affected buildds, but I don't know specifically what. On my test VM, while I have one ssh session active (logged in as 'user' on /dev/pts/0), some relevant parts of the VM's /dev look like this: $ ls -l /dev/console /dev/ptmx /dev/pts/* /dev/tty crw------- 1 root root 5, 1 Aug 19 22:06 /dev/console crw-rw-rw- 1 root tty 5, 2 Aug 19 23:08 /dev/ptmx crw--w---- 1 user tty 136, 0 Aug 19 23:08 /dev/pts/0 c--------- 1 root root 5, 2 Aug 19 22:06 /dev/pts/ptmx crw-rw-rw- 1 root tty 5, 0 Aug 19 22:55 /dev/tty (/dev/pts/ptmx having permissions 000 is strange, but seems to be expected, and does not cause observable brokenness for the VM: in particular script(1) still works fine there, because accessing /dev/ptmx is successful.) The /dev in /srv/sid/dev (the base chroot created by debootstrap) has: crw-rw-rw- 1 root root 5, 1 Aug 19 22:47 console lrwxrwxrwx 1 root root 13 Aug 19 22:47 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Aug 19 22:47 full crw-rw-rw- 1 root root 1, 3 Aug 19 22:47 null crw-rw-rw- 1 root root 5, 2 Aug 19 22:47 ptmx drwxr-xr-x 2 root root 4096 Aug 19 22:47 pts # is empty crw-rw-rw- 1 root root 1, 8 Aug 19 22:47 random drwxr-xr-x 2 root root 4096 Aug 19 22:47 shm # is empty lrwxrwxrwx 1 root root 15 Aug 19 22:47 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Aug 19 22:47 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Aug 19 22:47 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root root 5, 0 Aug 19 22:47 tty crw-rw-rw- 1 root root 1, 9 Aug 19 22:47 urandom crw-rw-rw- 1 root root 1, 5 Aug 19 22:47 zero The /dev in the schroot environment while one of my mksh builds was running (ls -l /run/schroot/mount/sid-*/dev) has: crw--w---- 1 user tty 136, 0 Aug 19 22:51 console lrwxrwxrwx 1 root root 13 Aug 19 22:47 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Aug 19 22:47 full crw-rw-rw- 1 root root 1, 3 Aug 19 22:47 null crw-rw-rw- 1 root root 5, 2 Aug 19 22:50 ptmx drwxr-xr-x 2 root root 0 Aug 19 22:48 pts # devpts mounted crw-rw-rw- 1 root root 1, 8 Aug 19 22:47 random drwxrwxrwt 2 root root 40 Aug 19 22:48 shm # tmpfs mounted lrwxrwxrwx 1 root root 15 Aug 19 22:47 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Aug 19 22:47 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Aug 19 22:47 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root root 5, 0 Aug 19 22:47 tty crw-rw-rw- 1 root root 1, 9 Aug 19 22:47 urandom crw-rw-rw- 1 root root 1, 5 Aug 19 22:47 zero and /run/schroot/mount/sid-*/dev/pts/ptmx is char device 5,2 with permissions 0666 (because it's a new instance of devpts with ptmxmode=666). If I ran sbuild from a terminal, the terminal is mounted over the schroot's /dev/console (necessary to make processes inside an interactive schroot detect the terminal as expected). If I didn't, the schroot's /dev/console remains as char device 5,1. If the regression in 1.6.13-4 had been reported as a bug, I would be tagging it moreinfo at this point. smcv
