Skip to content
Snippets Groups Projects
  1. Dec 03, 2020
    • Simon McVittie's avatar
      runtime: Create more symlinks for ${PLATFORM}-dependent libdirs · 49a496ed
      Simon McVittie authored
      
      Since glibc 2.26, the ${PLATFORM} for x86_64 can expand to "haswell"
      or "xeon_phi" in addition to "x86_64".
      
      To make it clearer what's going on, stop pretending that library paths
      based on ${PLATFORM} have anything to do with multiarch tuples.
      Instead, create symlinks like
      /overrides/lib/platform-haswell -> x86_64-linux-gnu and
      /overrides/lib/platform-i686 -> i386-linux-gnu.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      49a496ed
    • Ludovico de Nittis's avatar
      runtime: Do not dlopen layers if it is not needed · 92534fff
      Ludovico de Nittis authored
      
      Currently the Vulkan layer loader does not support having multiple layer
      manifests with the same "name" field.
      This can be a problem when you want to support multiple ABIs.
      
      For this reason some layers, like vkBasalt, use a "library_path" with
      just the filename of the library. In this way, at execution time, the
      correct library will be chosen automatically.
      
      To expand the special tokens LIB, PLATFORM and ORIGIN we dlopened the
      layers. But instead of always doing it, now we dlopen layers only if
      they actually contain at least one of those tokens.
      In this way we can speed up the whole process a little bit and also keep
      basenames as is, so that their correct library can still be chosen
      automatically at execution time.
      
      Partial addresses #39
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      92534fff
  2. Nov 30, 2020
  3. Nov 20, 2020
  4. Nov 18, 2020
  5. Nov 17, 2020
  6. Oct 26, 2020
  7. Oct 01, 2020
  8. Sep 29, 2020
  9. Sep 25, 2020
  10. Sep 21, 2020
  11. Sep 09, 2020
  12. Sep 08, 2020
  13. Sep 04, 2020
  14. Sep 03, 2020
  15. Sep 02, 2020
    • Ludovico de Nittis's avatar
      Initial support for custom graphics provider path and Flatpak · d7ad67a2
      Ludovico de Nittis authored
      
      pressure-vessel had a few hard coded assumptions about the host system
      and where to look at for the graphics provider.
      
      For example it was assumed that the root was the same host system used
      by both pressure-vessel current environment (where pressure-vessel-wrap
      runs) and also later on by `bwrap`.
      
      But when we run pressure-vessel in a Flatpak container, the final
      `bwrap` command is expected to be executed against the real host system
      (mounted in `/run/host`, in Flatpak).
      
      Also when we are in a Flatpak container we might want to pick the
      graphics stack from the host system (`/run/host`), from the Flatpak
      container itself or it could even be a completely separate one.
      (T22373, T22371)
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      d7ad67a2
    • Ludovico de Nittis's avatar
      bwrap: Build arguments to bind /usr if already in a container · f81c2d57
      Ludovico de Nittis authored
      
      The filesystem that is providing /usr might not be mounted
      in the same place in the current namespace, and on the host
      system where bwrap will be run. If it isn't, we need
      to use one path to do file I/O when inspecting it, but pass
      a different path to bwrap.
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      f81c2d57
  16. Aug 20, 2020
  17. Aug 19, 2020
  18. Aug 18, 2020
    • Simon McVittie's avatar
      runtime: Always provide adverb at /run/pressure-vessel/pv-from-host · 220657c6
      Simon McVittie authored
      
      While we control /run, we might as well be consistent.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      220657c6
    • Simon McVittie's avatar
      adverb, wrap: Add --terminate-timeout, --terminate-idle-timeout options · 18bdc4b9
      Simon McVittie authored
      
      This will let us have the following logic when sharing a container
      between multiple commands using -launcher and -launch:
      
      * For setup commands, don't wrap the launched command in the adverb.
        If the setup command starts background processes, they'll continue
        to run. This matches how installscript commands have historically
        worked for Windows (and Wine/Proton) games in Steam: the setup
        command is launched with system(), and can leak background
        processes like wineserver.
      
      * For the main game, wait for all processes to exit, by wrapping
        the launched command in the adverb, with --subreaper only. This
        matches how native Linux games, and the main command of
        Windows/Wine/Proton games, have historically worked in Steam.
      
      * When all processes belonging to the main game have exited,
        the -launcher can exit, at which point the subreaper that wraps it
        can clean up any background processes from the setup commands.
      
      --terminate-idle-timeout can be used to wait a few seconds before
      sending SIGTERM, if desired.
      
      Because the adverb now blocks SIGCHLD, we need to unblock it before
      running the child process; otherwise the child process will inherit
      the blocked signal, breaking things like g_spawn_async().
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      18bdc4b9
  19. Aug 11, 2020
  20. Jul 29, 2020
  21. Jul 21, 2020
  22. Jul 09, 2020
  23. Jul 08, 2020
  24. Jun 23, 2020
    • Simon McVittie's avatar
      runtime: Break hard-link for lock file when copying runtime · 978cc6e4
      Simon McVittie authored
      
      Because we do a "cheap copy" with hard-links where possible, .ref is a
      hard-link to its counterpart in the original (non-copied) runtime, so a
      lock on one is a lock on the other. We hold a lock on the original
      runtime while we do setup, so we would never actually delete the
      temporary runtimes unless we break the hard-link by re-creating the
      lock file.
      
      Resolves: T22035
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      978cc6e4
Loading