Simon McVittie dixit: >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"?
Yes, indeed. >-powerpc, -sparc teams: how are those buildds >(debian-project-be-1.buildd.org, blaauw.buildd.org, sompek.debian.net) >set up? >* host system suite: testing? unstable? other? >* kernel: seems to be 6.9.12 in each case, presumably from testing/unstable >* schroot: 1.6.13-4 or some sort of backport? >* is there any container/chroot/other confinement between the host system > and sbuild+schroot? >* any special schroot or kernel configuration? → cbmuser et al. >Thorsten, I see that >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=m68k&ver=59c-39&stamp=1724031130&raw=0, >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sh4&ver=59c-39&stamp=1724031300&raw=0 >seem to be running script(1) successfully, but failing with an error >that looks different (possibly related to using qemu-user on an amd64 >system). Can I assume that those are out-of-scope here? Right, these are from the failure to set argv[0] again, which is somehow on-again off-again with these hosts, despite qemu having been fixed ages ago. >> have you actually tested that this works? > >I initially provided the patch that was recently applied to schroot back >in 2017, and unfortunately I don't completely remember what I did 7 years Fair. >ago, but I think my usual reproducer for "do pseudo-terminals work?" was >to run something like "script -c 'cat /etc/os-release' /dev/null" inside >a schroot. Is that a good mockup of what mksh needs to do, or is there Half of it: mksh actually does things inside script(1) that use the tty. I cannot test this in that environment currently, but something like… case $(script -c 'echo true | env -i /bin/mksh-static -i' 2>&1) in *[!\ \#\$]*) echo fail ;; esac … or, if you can guarantee running as nōn-root (root ignores PS1 if it does not contain an octothorpe), case $(script -c 'echo true | env -i PS1=X /bin/mksh-static -i' 2>&1) in *[!X]*) echo fail ;; esac could work (i.e. test whether the returned text is just the prompt). The -i after the shell is important. You could also check for the warning message, but their format is not guaranteed to be fixed. Or just inspect this interactively. >I have not been continually testing that patch for 7 years, and I didn't >make the decision to integrate it now, so I can't speak to what testing >was done before the upload that integrated it. tbh I was more addressing the uploader with this, but I was rather tired yesternight when I found this and just wanted to throw the ball to “someone”. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
