Dear Maintainer,

On a Raspi 4B, I have warzone2100 installed. However, trying to run it fails:

philipp@raspi-rebstock:~$ warzone2100
bwrap: execvp /sys: No such file or directory
philipp@raspi-rebstock:~$ which warzone2100
/usr/games/warzone2100

But if I use the binary, it works:

philipp@raspi-rebstock:~$ /usr/games/warzone2100.real

starts the game. Also, I can start warzone2100 normally on two amd64 systems.

Control: retitle -1 warzone2100: /usr/games/warzone2100 wrapper script assumes XAUTHORITY is set

This appears to be because the /usr/games/warzone2100 wrapper script
invokes bubblewrap without sufficient caution, and assumes that the
environment variable XAUTHORITY will always be set. If it isn't, the
environment variable reference expands to 0 arguments, and bubblewrap's
command-line parser gets confused.

Is there a reason why this game, specifically, needs to be sandboxed? Is
it believed to be particularly susceptible to attacks?

If the wrapper script is necessary, I would recommend putting it through
shellcheck(1), and using `set -eu -o pipefail` ("unofficial strict
mode") since it's a bash script already; or maybe rewriting it in a
language with less dysfunctional error behaviour than bash, such as
Python, Perl or even C.

Should this (and other references to .local/share) be using
"${XDG_DATA_HOME:-"$HOME/.local/share"}", or does this game hard-code
~/.local/share contrary to the XDG basedir spec[1]?

This and other references to /run/user/$UID should probably be
$XDG_RUNTIME_DIR, and should be quoted. In practice systemd does set
XDG_RUNTIME_DIR=/run/user/$(id -u), but this is not an API guarantee.

This will prevent this game from using joysticks or gamepads, if that's
relevant to its control scheme.

This should probably be something like

${XAUTHORITY+--ro-bind-try "$XAUTHORITY" "$XAUTHORITY"}

     smcv

[1] https://specifications.freedesktop.org/basedir-spec/latest/