Skip to content
Snippets Groups Projects
  1. Aug 01, 2023
  2. Jul 28, 2023
  3. Jul 27, 2023
  4. Jul 18, 2023
  5. Jul 17, 2023
    • Simon McVittie's avatar
      exports: Don't try to export paths that refer to the container · 4782d67f
      Simon McVittie authored
      We can have two kinds of filename in /overrides: either the symbolic
      link points to a path that is already going to be in the container,
      like /run/host/… or /usr/…, or it points to a path that is only
      in the container if we explicitly ask the FlatpakExports object to
      share it, like /home/….
      
      For the paths that are already set up for the container, it's
      both misleading and useless to go through the motions of asking
      FlatpakExports to share it. It's misleading because it looks for a
      container-side filename in an environment that probably won't have it,
      like /usr/lib/x86_64-linux-gnu/… on a Fedora system that only has
      /usr/lib64, and even if we do find it, it's not the version of that file
      that we want to use. It's also useless because even if we do find
      the desired filename on the host, FlatpakExports will refuse to export
      paths below a prefix such as /usr that is controlled by the runtime.
      
      A secondary benefit of this change is that it results in summarizing
      the contents of /overrides in a debug-level log, which is useful for
      situations like <https://github.com/ValveSoftware/Dota-2/issues/2392
      
      >
      where we suspect that those contents might be wrong.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      4782d67f
    • Simon McVittie's avatar
      runtime: Ignore nvidia-vaapi-driver when capturing VA-API drivers · 3d83a211
      Simon McVittie authored
      Normally, we can rely on driver modules such as DRI, VA-API, Vulkan and
      GLX having relatively minimal, low-level dependencies, which are not too
      much trouble to import into the container. However, nvidia-vaapi-driver
      pulls in GStreamer core libraries, all of GLib, elfutils' libdw, and
      several compression libraries.
      
      The more libraries we import into the container, the more likely we
      are to have one of the failure modes that our container is designed
      to avoid: either a library that causes trouble for some reason (like
      libbz2 in Dota-2#2392), or a game developer accidentally relying on
      application-level functionality of a newer operating system that our
      container cannot guarantee to provide in a portable way.
      
      GStreamer is particularly problematic here, because it has its own
      plugin architecture. Importing a driver that links to GStreamer, but
      none of GStreamer's plugins, is unlikely to work as desired: it will be
      unable to encode or decode any videos, likely making nvidia-vaapi-driver
      essentially useless.
      
      Resolves: https://github.com/ValveSoftware/Dota-2/issues/2392
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      3d83a211
    • Simon McVittie's avatar
      runtime: Cope with OSs where an alias is used as the canonical SONAME · 109a384c
      Simon McVittie authored
      The upstream SONAME of the reference libbz2 library is libbz2.so.1.0,
      but Fedora and its derivatives patch the build system to change the
      SONAME to libbz2.so.1. In Debian (and therefore the Steam Runtime)
      we provide libbz2.so.1 as an alias for the canonical library name,
      but in Fedora, libbz2.so.1 *is* the canonical library name (and there
      is no libbz2.so.1.0 symlink).
      
      We do not normally need a host copy of libbz2 at all, because graphics
      drivers do not normally depend on it. but nvidia-vaapi-driver pulls it
      in via GStreamer and elfutils libdw.
      
      When we set up the container, in the common case where we do not need
      to use the host libbz2.so.1.0, we make sure to create a symlink
      libbz2.so.1 in /overrides/lib/TUPLE/aliases, pointing to the runtime's
      driver. Similarly, if we use a newer host copy of libbz2.so.1.0 as a
      dependency of a graphics driver, we would create a symlink libbz2.so.1
      pointing to that (via /overrides/lib/TUPLE/libbz2.so.1.0).
      
      The case that we did not deal correctly with until now is that the
      graphics driver dependencies on the host include libbz2.so.1, with its
      SONAME set accordingly. If that happens, then we need to create a
      symlink that is the reverse of what we would usually do, with
      libbz2.so.1.0 pointing to the host's libbz2.so.1.
      
      Resolves: https://github.com/ValveSoftware/Dota-2/issues/2392
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      109a384c
    • Simon McVittie's avatar
      runtime: Expand logging for aliases · 574298dc
      Simon McVittie authored
      
      Not many libraries have aliases, and those that do are unusual and
      relatively likely to go wrong, so it's worth being a little more
      verbose here.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      574298dc
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      runtime: If creating one alias fails, move on to the next one · 60dae345
      Simon McVittie authored
      
      If we need aliases for (for example) libbz2.so.1.0 and libOSMesa.so.8,
      and creating the alias symlink for libbz2.so.1.0 fails, there's no
      reason not to try to set up libOSMesa.so.8.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      60dae345
    • Simon McVittie's avatar
  6. Jul 12, 2023
  7. Jun 21, 2023
  8. Jun 19, 2023
  9. Jun 16, 2023
Loading