On Wed, 13 Nov 2024 at 11:13:22 +0000, Jessica Clarke wrote:
> Uh, I meant to refer to schroot’s new */dev/pts* behaviour. Have you
> tried the trixie/sid version? I expect you’ll see similar issues.
xorg-server_2:21.1.14-2 builds successfully for me in a trixie/sbuild
version of schroot invoked non-interactively, and built successfully on
a riscv64 buildd (which I believe is relatively up-to-date).
Writing to /proc/self/fd/2 and /dev/stderr is also working OK for me in
an interactive schroot on the porterbox ricci, with schroot 1.6.13-5,
which appears to be using a new instance of /dev/pts per chroot. In
my case, /proc/self/fd/2 points to /dev/pts/0, which doesn't actually
exist in /dev/pts as seen from the chroot - but opening it works anyway,
albeit possibly only because /dev/console as seen from the chroot is
the same device ("test /proc/self/fd/2 -ef /dev/console" succeeds).
Sorry, I'm not able to set up an environment to try various possible
code paths interactively right now: I don't routinely run pbuilder or
cowbuilder (precisely because it is not what the official buildds use),
and xorg-server is not my top priority.
> This isn’t really a new problem, it’s just another case
> similar to redirecting to a file that lives outside the chroot, for
> which neither chroot tool currently has a general solution.
Please try with:
https://salsa.debian.org/xorg-team/xserver/xorg-server/-/merge_requests/14
which hopefully addresses whatever is the failing scenario?
smcv
