Source: fenix Version: 0.92a.dfsg1-12.1 Severity: important Tags: ftbfs trixie sid User: [email protected] Usertags: ftbfs-libsdl1.2-compat-dev
I tried recompiling fenix on a porterbox with libsdl1.2-compat-dev instead of libsdl1.2-dev, in preparation for having src:sdl12-compat take over the libsdl1.2-dev package name. I found that fenix failed its build-time tests in the schroot I was using for this, with two test failures similar to this: > prove -r -v debian/tests/t > > # Failed test 'stderr_is_eq: /home/smcv/tmp/fenix/fxi/src/fxi > fhello.dcb, ' > # at /home/smcv/tmp/fenix/debian/tests/t/lib/Test/Fenix/Run.pm line > 48. > # got: 'error: XDG_RUNTIME_DIR is invalid or not set in the > environment. > # ' > # expected: '' > # Looks like you failed 1 test of 2. > > # Failed test 'run a Fenix program' > # at /home/smcv/tmp/fenix/debian/tests/t/lib/Test/Fenix/Run.pm line 51. > # Looks like you failed 1 test of 4. This is related to <https://bugs.debian.org/858466>, which is arguably a schroot bug; but official Debian buildds and porterboxes use schroot, so we have to work around it. There are a few possible ways to do that: debian/rules could export SDL_VIDEODRIVER=dummy to prevent SDL from trying to use X11 (which fails) or Wayland (which also fails, but libwayland emits the message "XDG_RUNTIME_DIR is invalid or not set in the environment" in the process). This is probably the cleanest and simplest solution, and I've checked that it's sufficient. Or debian/rules could use xvfb-run to run the build-time tests, so that X11 will succeed, therefore Wayland will not be tried, therefore that message will not be produced. Or, debhelper compat level 13 sets a temporary XDG_RUNTIME_DIR by default while running build-time tests. Or, if debhelper compat level 13 is unsuitable for whatever reason, debian/rules could open-code creation of a temporary XDG_RUNTIME_DIR, similar to the code that was removed in <https://salsa.debian.org/gnome-team/glib/-/commit/2ab2db4b9c04ca4c99e329af3c93e642fa478806>. Please do one of those. If this is still happening when we are ready to make src:sdl12-compat take over the libsdl1.2-dev name, then this bug will become RC. Thanks, smcv
