On 13 Nov 2024, at 18:20, Simon McVittie <s...@debian.org> wrote: > > 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.
Interesting, echo test > /proc/self/fd/2 does indeed work for me within cowbuilder login, which is surprising* but consistent with your schroot observations. So more investigation needed, including to see if I see the same failure building xorg-server or if it’s specific to the submitter’s environment. Jess * Although not really now I think about it, given it needs to work for e.g. pipes, and those will never have a valid path there >> 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