Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423

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.”)