- Jan 08, 2020
-
-
Simon McVittie authored
This avoids a coreutils limitation in versions [8.27, 8.29), which unfortunately includes Ubuntu 18.04: timeout(1) relied on SIGCHLD not being blocked, but did not unblock it themselves. The Steam client runs s-r-s-i from a thread that has SIGCHLD blocked, and SIGALRM, SIGPIPE and SIGTRAP ignored. This is contrary to frequent expectations of general-purpose libraries and command-line utilities: in particular, SIGPIPE is used by processes writing to a pipe to detect that the read end has died, SIGTRAP is frequently used to terminate processes on an assertion failure, and SIGCHLD is often necessary for subprocess management. Games (whether Steam or non-Steam) appear to be run with only SIGPIPE and SIGTRAP ignored, so strictly speaking, unignoring those two makes the behaviour of s-r-s-i unlike the behaviour of actual games. However, the effect of unblocking SIGPIPE and SIGTRAP is to make s-r-s-i more likely to crash (the default disposition of both those signals is process termination), which is probably what we want: if there is any difference, we want s-r-s-i's helpers to be more strict than games (crash more often), so that they can act as an early-warning system for issues that could manifest in games. In s-r-s-i, don't unblock signals until after we have finished command-line parsing and redirected stdout to print to the original stderr. Otherwise, g_debug() would go to the original stdout, resulting in it being invalid JSON. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, we only called this if we were already going to call g_type_init(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 07, 2020
-
-
Simon McVittie authored
s-r-s-i: Really add --version option See merge request steam/steam-runtime-tools!95
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This was half-implemented in commit ed218ced. Fixes: ed218ced "Add --version argument to most executables" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 13, 2019
-
-
Simon McVittie authored
All of these need to include _steam-runtime-tools-config.h, which means they need the equivalent of Autotools -I${top_builddir}. This is done automatically when building steam-runtime-tools on its own, but not when building it as a subproject. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 09, 2019
-
-
Simon McVittie authored
utils: Don't consider exit status 255 to be signal 127 See merge request steam/steam-runtime-tools!91
-
Simon McVittie authored
Linux has 64 signals, numbered 1 to 64, of which signals 32 to 64 inclusive are the POSIX real-time signals. Older Linux versions had 31 signals, numbered 1 to 31. Some utilities, like old versions of vulkaninfo(1), use exit(-1) to signal errors. This really results in exit status (unsigned char)(-1), or 255, which timeout(1) passes through as-is. This can't be 128 + a signal number, because there aren't that many signals in practice. Stop interpreting exit statuses as signals after 128+SIGRTMAX (in practice 128+64) instead. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Make stringification of enums, flags less repetitive See merge request steam/steam-runtime-tools!90
-
Jeremy Whiting authored
-
Jeremy Whiting authored
-
Jeremy Whiting authored
-
- Dec 05, 2019
-
-
Simon McVittie authored
tests: Assert that test_missing_arch gives a useful diagnostic See merge request steam/steam-runtime-tools!89
-
Simon McVittie authored
The message is actually something like /path/to/hal9000-linux-gnu-inspect-library not found but I don't want to hard-code that, so just assert that the name of the executable is mentioned. This clarifies why we don't get an exit status: we never get as far as actually running anything. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Log exit status See merge request steam/steam-runtime-tools!87
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Fix CI failure in dpkg-shlibdeps See merge request steam/steam-runtime-tools!88
-
Jeremy Whiting authored
-
Jeremy Whiting authored
-
Jeremy Whiting authored
-
Jeremy Whiting authored
If helper times out or is killed we report the exit_status of the helper and terminating_signal if it was terminated. Tested locally by making wflinfo symlink point to hanging mock test. Will add unit tests in next commit. Also added SRT_LIBRARY_ISSUES_TIMEOUT for timeout result.
-
-
Simon McVittie authored
This avoids the need to Build-Conflict with the -helpers package, which we want to install in the SDK image. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This lets us have versioned dependencies on older versions. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As well as being a harmless and vaguely desirable change in its own right, this works around a bug in deb-build-snapshot, which doesn't always use the dist tarball that it just generated for the updated dpkg package. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Since steam-runtime-tools was made relocatable in c3a06cce, its build will fail with the Steam Runtime 1 'scout' version of dpkg if it is already installed system-wide. If the SDK container where steam-runtime-tools is built has our $(pkglibexecdir) populated with symbolic links to the dependency libraries, then dpkg-shlibdeps will look there to convert DT_NEEDED dependencies into Debian dependencies. Unfortunately, the version of dpkg in SteamRT 1 'scout' has Debian bug #843073, which means it assumes all libraries are found via their canonical names as listed in the dpkg database, not a symlink-based alias. This results in the build failing with an error similar to: dpkg-shlibdeps: error: no dependency information found for /usr/lib/x86_64-linux-gnu/steam-runtime-tools-0/libglib-2.0.so.0 (used by debian/libsteam-runtime-tools-0-helpers/usr/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-locale) Until we get a newer Docker image with a newer version of this package that works around this issue, we will have to remove it explicitly before running CI. Adding Build-Conflicts is not enough: autopkgtest installs build-dependencies, but does not remove Build-Conflicts. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 20, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Add check-gl draw a triangle using opengl test See merge request steam/steam-runtime-tools!83
-
Jeremy Whiting authored
Also added mock-mixed gl test to test scenario of wflinfo working but check-gl failing.
-
Jeremy Whiting authored
Just as with check-vulkan use --visible to see the triangle window otherwise application draws a few frames and reports any gl errors found or does exit 0 on success.
-
- Nov 19, 2019
-
-
Simon McVittie authored
Build -system-info and -check-locale with relative DT_RPATH See merge request steam/steam-runtime-tools!85
-
- Nov 18, 2019
-
-
Simon McVittie authored
Add missing string for cannot draw graphics issue. See merge request steam/steam-runtime-tools!86
-
Jeremy Whiting authored
-
- Nov 15, 2019
-
-
Simon McVittie authored
This ensures that they can find the non-ubiquitous json-glib library, and the steam-runtime-tools library, even if relocated into a non-standard prefix like the LD_LIBRARY_PATH Steam Runtime. We can't just use a relative version of the standard library directory as our RPATH, because if we did that, we would load glibc from the same place. This causes crashes in pressure-vessel, where ld.so and the rest of glibc are often taken from the host system via /overrides/lib, and the glibc in /lib and /usr/lib is incompatible with ld.so. Instead, use a private library directory and populate it with relative symlinks to our non-glibc dependencies; we assume the host version of glibc is new enough that this is OK. Using DT_RPATH in preference to DT_RUNPATH means we take all our direct and indirect dependencies from the same place. This is important when libjson-glib (which won't ordinarily have a RUNPATH or RPATH) pulls in GIO as an indirect dependency of check-locale, which doesn't directly depend on GIO. The GIO library we get must match the versions of GLib and GObject we're using. This also bypasses LD_LIBRARY_PATH. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 13, 2019
-
-
Simon McVittie authored
This made them usable from outside the LD_LIBRARY_PATH runtime, but breaks their use inside a pressure-vessel container. In pressure-vessel, the glibc family of libraries are typically taken from outside the container (for example /overrides/lib/x86_64-linux-gnu/libc.so.6), and the dynamic linker ld.so is replaced with one that is suitable for the libraries in /overrides. In general, these versions will be incompatible with the ones in /usr/lib/x86_64-linux-gnu, which unfortunately are the ones that get pulled in via the DT_RPATH. This reverts commit 91478a07. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-