On 13 Nov 2024, at 10:47, Simon McVittie <s...@debian.org> wrote: > > On Wed, 13 Nov 2024 at 09:55:43 +0000, Mark Hindley wrote: >> In version 21.1.14-2 of src:xorg-server, the new compile time Xvfb check >> fails >> in a pbuilder/cowbuilder chroot: >> >> sudo cowbuilder --build --basepath /var/cache/pbuilder/base-sid.cow/ >> xorg-server_21.1.14-2.dsc > ... >> # Check basic functionality of Xvfb >> PATH="debian/build/main/hw/vfb:$PATH" sh debian/local/xvfb-run -a -e >> /proc/self/fd/2 -s -noreset xdpyinfo >> debian/local/xvfb-run: 159: cannot create /proc/self/fd/2: Permission denied >> debian/local/xvfb-run: 82: cannot create /proc/self/fd/2: Permission denied > > Does pbuilder not make /proc available in the usual way, or mount it with > unusual/restrictive options, or something like that? > > It would be possible to work around this by letting Xvfb's stderr go > to the default /dev/null, or by adding a special case that detects the > path /proc/self/fd/2 or /dev/stderr and using >&2 in this case, but I > would really prefer to be able to treat a normally-functioning /proc as > "part of the API" that we expect from any reasonable build environment. > > Several packages that use xvfb-run for their test suites are also using > "-e /proc/self/fd/2" to make Xvfb failures like #1082659 a bit more > feasible to debug, so they will also FTBFS in pbuilder/cowbuilder > until/unless this can be addressed somehow.
It’s mounted /proc for quite a few years now similarly to how schroot recently started to, but /proc/*/fd/N has always been a little broken. Isn’t that also true of schroot though? I seem to recall observing the same thing there when testing the new schroot code recently. Jess
