Skip to content
Snippets Groups Projects
  1. Feb 19, 2024
  2. Feb 09, 2024
    • Simon McVittie's avatar
      runtime: Only unset STEAM_ZENITY if it belongs to the LDLP runtime · 044c3777
      Simon McVittie authored
      
      There are currently four possibilities for STEAM_ZENITY:
      
      * unset
      * explicitly set to empty (to disable its use, as on Steam Deck)
      * absolute path of host zenity, typically /usr/bin/zenity
      * literal string "zenity" which will be found in scout's PATH
      
      In all cases except the last, there is no need to unset STEAM_ZENITY
      when "escaping" from the LDLP runtime, because the value will be
      equally valid in a host-like execution environment; and when the value
      is empty, it can be actively harmful to unset it, since this will result
      in using zenity when not intended.
      
      For completeness, we also unset STEAM_ZENITY if it is the absolute
      path of the LDLP runtime's zenity (which is not a situation that Steam
      ever sets up right now, but in principle it could be).
      
      steamrt/tasks#397
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      044c3777
    • Simon McVittie's avatar
      tests: Stop using Flatpak code · 544da35b
      Simon McVittie authored
      
      It's simpler if we avoid layering violations in the build system, and
      using flatpak_quote_argv() here doesn't buy us much.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      544da35b
    • Simon McVittie's avatar
      utils: Pass program name to _srt_async_signal_safe_error separately · 7af1db9f
      Simon McVittie authored
      
      This will let us call it (carefully) from library code.
      
      While we're changing its signature, also don't require the caller to
      pass a string that ends with a newline, making it more like g_error().
      It turns out that we got this wrong in one place already.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      7af1db9f
    • Simon McVittie's avatar
      scout-on-soldier: Remove workaround for mid 2021 configuration change · 1875f3a2
      Simon McVittie authored
      
      This script was added in June 2021 (T28437) when we migrated app ID
      1070560 from being a self-contained "pure scout" runtime
      (for which the entry point was ./_v2-entry-point) to being a layered
      scout-on-soldier runtime (for which the entry point is
      ./scout-on-soldier-entry-point-v2). At the time, the Steam client did
      not reliably pick up the configuration change until it was restarted.
      
      It seems safe to assume that all users have restarted Steam since 2021.
      
      Removing this workaround also incidentally removes one of our uses of
      zenity, which helps steamrt/tasks#397 and related tasks.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1875f3a2
    • Simon McVittie's avatar
      Rename PvBwrapLock to SrtFileLock and move it to common code · 9052fbd4
      Simon McVittie authored
      
      This was implemented to interact correctly with the locking scheme
      used in bwrap(1) (which uses the non-OFD flavour of fnctl locks), but
      is otherwise unrelated to bwrap(1) or pressure-vessel. Moving this into
      common code will facilitate using it outside pressure-vessel, in
      particular when unpacking `ubuntu12_64/steam-runtime-sniper/`.
      
      While I'm changing the interface anyway, take the opportunity to rename
      the WRITE flag to EXCLUSIVE, which is clearer.
      
      Helps: steamrt/tasks#387
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9052fbd4
    • Simon McVittie's avatar
      backports: Add a backport of g_closefrom(), g_fdwalk_set_cloexec() · 6ada39c3
      Simon McVittie authored
      
      These will be new API in GLib 2.79.2.
      
      The only code change in the implementation, other than the _glnx
      wrappers, was to use `close()` instead of `g_close (fd, NULL)` in a
      context where it must be async-signal safe.
      
      The test-case needed some more adjustments to be backwards-compatible
      with GLib from the distant past.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      6ada39c3
  3. Feb 02, 2024
  4. Jan 31, 2024
  5. Jan 12, 2024
  6. Dec 07, 2023
  7. Nov 22, 2023
  8. Nov 20, 2023
  9. Nov 17, 2023
    • Simon McVittie's avatar
      tests: Test pv-verify · 762212be
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      762212be
    • Simon McVittie's avatar
      tests/valgrind.sh: Don't show reachable objects by default · 873120b2
      Simon McVittie authored
      
      There are too many false positives if we do.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      873120b2
    • Simon McVittie's avatar
      subprocess: Avoid using timeout(1) to impose a timeout · d69f3e22
      Simon McVittie authored
      
      This is more difficult than you might think, because until GLib 2.78
      (which is far too new for us to depend on), there was a potential
      race condition between g_child_watch_source_new()'s use of waitpid(),
      and a kill() in the same main-context. We don't really want to use
      g_child_watch_source_new() anyway, because we don't know whether this
      library is going to be loaded by a process that is blocking SIGCHLD or
      handling SIGCHLD itself.
      
      Avoiding timeout(1) can result in a significant speedup on ARM hardware
      emulating x86 via FEX-Emu, which makes executable startup
      disproportionately expensive: each new executable needs to re-initialize
      the interpreter, which is normally fine, but the cost builds up when we
      run a very large number of very small processes.
      
      Avoiding timeout(1) is also good for robustness: in the past, Canonical's
      Steam Snap app has had an AppArmor profile that did not allow arbitrary
      coreutils commands to be run.
      
      In this initial implementation, we poll the process every 100ms. This
      is *much* slower than blocking (it adds up to 100ms to every subprocess
      execution, resulting in a slowdown from around 8 to 96 seconds for
      steam-runtime-system-info on x86), but it can be used as a fallback.
      It's in this commit to have an opportunity to test the fallback code path.
      Subsequent commits will speed this up again.
      
      Helps: #88
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d69f3e22
  10. Nov 16, 2023
  11. Nov 02, 2023
  12. Oct 30, 2023
  13. Oct 25, 2023
Loading