Skip to content
Snippets Groups Projects
  1. Dec 15, 2022
  2. Aug 10, 2022
  3. Jul 28, 2022
  4. Jul 26, 2022
  5. Jul 25, 2022
  6. Jul 21, 2022
  7. Jun 16, 2022
  8. Jun 15, 2022
  9. Jun 13, 2022
  10. Jun 09, 2022
  11. Jun 08, 2022
  12. May 27, 2022
  13. Mar 11, 2022
  14. Mar 10, 2022
    • Simon McVittie's avatar
      _v2-entry-point: Make sure ./var is not a symlink · a587ac87
      Simon McVittie authored
      Some users might be tempted to redirect ./var to another filesystem,
      but this will make the runtime a lot slower, more space-consuming and
      less reliable, because we rely on being able to make hard links
      between the distributed files and the temporary container root.
      
      The correct way to relocate the Steam Linux Runtime depot is to set up
      a Steam library on a suitable filesystem (which for best results should
      be a fully-featured Unix filesystem like ext4, btrfs or xfs, although
      NTFS can be made to work with some difficulty), and then use Steam's
      "Properties -> Local Files -> Move install folder..." to move the
      Steam Linux Runtime into it.
      
      Helps: https://github.com/ValveSoftware/steam-runtime/issues/495
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      a587ac87
  15. Feb 22, 2022
  16. Feb 14, 2022
  17. Feb 11, 2022
    • Simon McVittie's avatar
      scout-on-soldier: Unpack our own Steam Runtime if necessary · 65ae90fa
      Simon McVittie authored
      This avoids game crashes in some of the unsupported configurations where
      a distribution or end user has either disabled the Steam Runtime with
      STEAM_RUNTIME=0, or switched to a modified, unofficial or otherwise
      out-of-band Steam Runtime with STEAM_RUNTIME=/some/path.
      
      Normally, when developers and tinkerers are experimenting with new
      Steam Runtime versions, we can assume that they have previously run
      Steam with the supported runtime at least once. In that scenario,
      ~/.steam/root/ubuntu12_32/steam-runtime will be a valid scout runtime:
      it might not be the one the user intended, and it might be out of date,
      but it will probably work.
      
      However, if someone has been *consistently* setting STEAM_RUNTIME ever
      since the first time they ran Steam, then it will never have had the
      opportunity to unpack the supported runtime, and
      ~/.steam/root/ubuntu12_32/steam-runtime will still be the heavily
      cut-down runtime from the bootstrapper, which is insufficient for
      launching games because it does not implement the whole Steam Runtime ABI
      (in particular, Dota 2 fails to launch because libpng12.so.12 is
      missing).
      
      As before, developers and tinkerers can bypass all of this by setting
      STEAM_RUNTIME_SCOUT in addition to STEAM_RUNTIME. As with STEAM_RUNTIME,
      setting this variable is unsupported and users who have overridden it
      are responsible for the consequences (do not report bugs). We cannot
      reuse the same variable for this purpose, because of the dual role of
      STEAM_RUNTIME: it's a way for developers to switch to a different
      scout runtime, but it's also a way for libraries inside the runtime
      to detect the location of the runtime environment, which needs to be
      disabled while we are setting up the container runtime.
      
      Resolves: https://github.com/ValveSoftware/Dota-2/issues/2018
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      65ae90fa
  18. Oct 29, 2021
  19. Oct 28, 2021
    • Simon McVittie's avatar
      scripts: Ignore errors when showing diagnostic messages · afa2a3de
      Simon McVittie authored
      If users of an X11 environment restart it inside a terminal emulator, and
      then close the terminal emulator (which seems to be a somewhat popular
      meme on various forums), we can end up with stdout/stderr pointing to a
      pseudo-terminal that is no longer associated with a terminal emulator.
      All writes to such a terminal fail, and when we're running under
      `set -e`, that will terminate the script. Worse, we can't even diagnose
      what has happened, because any error messages we might have shown are
      also going into the void.
      
      Mitigate this by ignoring `set -e` when logging diagnostic messages,
      analogous to the behaviour of `g_warning()` and similar C API calls.
      (After all, what would we do about it - log a diagnostic message?)
      
      Related to <https://github.com/ValveSoftware/steam-for-linux/issues/8069
      
      >.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      afa2a3de
  20. Sep 16, 2021
  21. Sep 10, 2021
  22. Sep 09, 2021
Loading