- Sep 15, 2023
-
-
Simon McVittie authored
check-va-api: Don't claim to have provided a reference frame Closes #117 See merge request !587
-
- Sep 11, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
App 1070560: was SLR, now SLR 1.0 (scout) App 1391110: was SLR - soldier, now SLR 2.0 (soldier) App 1628350: was SLR - sniper, now SLR 3.0 (sniper) The more generic name "Steam Linux Runtime" now refers to the whole container runtime ecosystem. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We're now trying to be consistent about "Steam Linux Runtime" meaning the thing that uses pressure-vessel and bubblewrap. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 07, 2023
-
-
Simon McVittie authored
In principle the context is a required parameter for vaCreateBuffer(), but in practice Mesa doesn't do anything with it, not even a validity check for it not being VA_INVALID_ID. Non-Mesa drivers, like the one from Intel and the unofficial one for Nvidia hardware via nvdec and cuda, do check for this. Thanks: Emil Velikov Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 05, 2023
-
-
Simon McVittie authored
We're decoding a single frame, so there is no previous frame that we could possibly refer to; and our single frame is an i-frame (keyframe), so we don't need a reference anyway. When Mesa is compiled with assertions enabled, if num_ref_frames is greater than 0, it asserts that ReferenceFrames[0] up to ReferenceFrames[num_ref_frames-1] inclusive are valid handles to reference frames. In our case, that array is zero-filled, and 0 clearly can't be a valid handle to a previous frame because we don't have any previous frames at all, causing an assertion failure and crash. Closes: #117 Thanks: David Rosca 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
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
identify-library-api: On Exherbo, run both versions of ldconfig See merge request !586
-
- Sep 04, 2023
-
-
Simon McVittie authored
Unlike other multiarch/multilib designs, Exherbo has one build of ldconfig per architecture, each with its own configuration that only searches libraries intended for that word size. Helps: https://github.com/ValveSoftware/steam-runtime/issues/615 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
If we use this in run.sh in preference to running /sbin/ldconfig directly, then we'll only need to add support for distributions with more than one parallel ldconfig binary (like Exherbo) in one place. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 01, 2023
-
-
Simon McVittie authored
No functional change intended. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 31, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
pv-runtime: Tolerate inability to chmod files if the permissions look OK See merge request !582
-
Ludovico de Nittis authored
Build system cleanup See merge request !585
-
Simon McVittie authored
This allows doing: meson setup _build meson test -C _build without an intervening `meson compile` step. Previously, this would have failed because the tests require various helpers and fixtures, while some of the code under test also requires helper programs, and some of the code under test *is* a CLI program. For a project this small, there's no real need to distinguish precisely which programs are needed by which test: we can just assume that all tests need all programs, like Autotools would. Includes: https://gitlab.gnome.org/GNOME/libglnx/-/merge_requests/51 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 30, 2023
-
-
Simon McVittie authored
If we don't do this, we won't be able to give the tests proper dependencies on the helper programs that they use. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Update libglnx See merge request !584
-
Simon McVittie authored
It is somewhat common for Steam-on-Linux users to have their default Steam library on an NTFS drive: even though this is not really recommended, a dual-boot system could have most of its available space formatted as NTFS. In this case we still try to set the permissions we wanted, and show a warning if we can't; but as long as files and directories that we want to be executable are executable, and other files are at least readable, we might as well try to continue and see whether it works. Similarly, it is somewhat common for users of multi-user systems to have a Steam library that is owned by one Unix user, but writeable by another Unix user and shared by both. This is not a recommended setup, because the inability to chmod the other user's files will frequently break expectations, and it removes any effective privilege separation between the users, hence requiring the users to trust each other completely (each user can cause arbitrary code execution for the other by overwriting a game binary). However, some users do this anyway, both on Windows and Linux, and expect it to work. As with the NTFS case, we can try to proceed and hope for the best. Note that this change specifically does not affect having *Proton* installed in a location not owned by the current user, which will still not work. Wine has a specific check for the wineprefix being owned by the current Unix user (which is known to cause problems), and will refuse to run if it is not. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/434 Resolves: https://github.com/ValveSoftware/steam-runtime/issues/491 Resolves: https://github.com/ValveSoftware/steam-runtime/issues/544 Resolves: https://github.com/ValveSoftware/steam-runtime/issues/606 Helps: https://github.com/ValveSoftware/steam-runtime/issues/460 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This gives us more control over which operations we will allow to fail, which is important if we want to cope with filesystems where fchmod() can't work, for example NTFS or a directory owned by a different user. 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
If we can't chmod the file, we should say what the current owner and permissions look like, to assist debugging. In particular, this is likely to happen on NTFS or when operating on a directory owned by a different user. For example, if the filesystem is owned by root (steam-runtime#544) we might say: Unable to change mode of ... from 0777 (owner: "root", group: "root", non-member) to 0644: ... or if the file is owned by the current user but the filesystem does not allow chmod anyway (steam-runtime#606) we might say: Unable to change mode of ... from 0755 (owner: current user, group: "users") to 0644: ... Helps: https://github.com/ValveSoftware/steam-runtime/issues/434 Helps: https://github.com/ValveSoftware/steam-runtime/issues/460 Helps: https://github.com/ValveSoftware/steam-runtime/issues/477 Helps: https://github.com/ValveSoftware/steam-runtime/issues/491 Helps: https://github.com/ValveSoftware/steam-runtime/issues/544 Helps: https://github.com/ValveSoftware/steam-runtime/issues/606 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
I'm going to extend this to cope better with filesystems where we do not own the files or otherwise cannot change their ownership, and that will be easier if we can early-return on success or if there is nothing to do. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the filesystem or file ownership doesn't support setting the mtime, all of them will fail in the same way, leading to a lot of log-spam. In particular, this is likely to happen on NTFS or when operating on a directory owned by a different user. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is just syntactic sugar for something we do quite often. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Fixes: b5441dc6 "pressure-vessel: Warn if we have to fall back to copying" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 29, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
-
Simon McVittie authored
testutils: Add a backport of g_test_disable_crash_reporting() See merge request GNOME/libglnx!50
-
- Aug 24, 2023
-
-
Ludovico de Nittis authored
system-info: Check whether the Steam Runtime is on an unsupported filesystem See merge request !583
-
Simon McVittie authored
The preferred way to install all versions of the Steam Runtime, both LD_LIBRARY_PATH and container, is on a fully-featured local Unix filesystem such as ext4, btrfs or xfs. If that is not how it's installed, we should flag that in system-info reports so that we can treat it as a possible root cause for user-visible issues: as with many of our issue flags, it isn't *necessarily* a problem, but it's a *potential* problem. Ignore these issue flags during unit testing, because the filesystem we're running on during unit testing isn't under our control. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 23, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 17, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-