Skip to content
Snippets Groups Projects
  1. Oct 15, 2024
    • Simon McVittie's avatar
      pv-runtime: Use host versions of the libdrm family, if newer · 9d346343
      Simon McVittie authored
      In current Mesa versions, typically these are pulled in via explicit
      linking that generates a `DT_NEEDED` ELF header, either in individual
      DRI drivers in very old Mesa, in the Gallium "megadriver" in
      intermediate Mesa versions like the one in Debian 12, or in
      `libgallium-${VERSION}.so` in newer Mesa.
      
      However, Mesa merge request
      https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658
      
      
      suggests demoting the dependency on `libdrm_amdgpu.so.1` from
      `DT_NEEDED` to `dlopen()`. Changing that dependency from declarative to
      imperative breaks our ability to follow it, resulting in the container's
      older `libdrm_amdgpu.so.1` being used.
      
      In principle there's nothing to stop the same thing from happening for
      any of the libraries in the libdrm family, so look for all of them.
      For future-proofing, I've included all available drivers even if they
      are not available on x86 (but excluding exynos and omap, which seem to
      be only for 32-bit ARM hardware, which is probably no longer
      interesting).
      
      Tested-by: Dmitry Osipenko
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9d346343
    • Simon McVittie's avatar
      Merge branch 'wip/smcv/json' into 'main' · 7531b3a7
      Simon McVittie authored
      tests: Avoid invalid escaping in JSON
      
      See merge request !762
      7531b3a7
  2. Oct 14, 2024
    • Simon McVittie's avatar
      tests: Avoid invalid escaping in JSON · 9df1c6c1
      Simon McVittie authored
      MangoHud historically had paths like `"/usr/\$LIB/..."` in its JSON
      manifest, but this is not actually valid JSON, because JSON does not
      define a meaning for `\$`. The version of json-glib in Debian testing
      (Debian 13 prereleases) implements more correct / more strict JSON
      parsing, which correctly but perhaps unhelpfully diagnoses this as an
      error, breaking our test's expectations when our CI runs its tests in a
      recent development environment.
      
      We were not intentionally exercising the handling of invalid JSON, so
      test against valid JSON here.
      
      I've also opened https://gitlab.gnome.org/GNOME/json-glib/-/merge_requests/87
      
      
      to return json-glib in non-strict mode to its previous behaviour for
      these strings.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9df1c6c1
  3. Sep 16, 2024
  4. Sep 13, 2024
  5. Sep 12, 2024
    • Simon McVittie's avatar
      pv-runtime: If using host libxkbcommon, try to use host libxkbcommon-x11 · 652b6011
      Simon McVittie authored
      
      libxkbcommon is not really a graphics driver dependency as such, but
      it can end up being pulled in by graphics stack components, for example
      MangoHUD 0.7.2.
      
      libxkbcommon-x11 looks into private data structures from libxkbcommon,
      which is a reasonable thing to do since they come from the same source
      code and are upgraded at the same time, but can cause crashes if we
      pick up one but not the other from the graphics stack provider; so if
      we pick up libxkbcommon as a dependency of MangoHUD, we also need to
      take the matching libxkbcommon-x11 if it exists.
      
      If the graphics stack provider has libxkbcommon but not libxkbcommon-x11,
      there's really nothing we can do about that, so we will have to combine
      this change with trying harder to get Steam client packaging to pull in
      libxkb-common-x11.so.0.
      
      steamrt/tasks#530
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      652b6011
    • Simon McVittie's avatar
      pv-runtime: Generalize code to capture libraries related to glibc · 58c5d20c
      Simon McVittie authored
      
      Previously this was part of pv_runtime_collect_libc_family(), but in
      fact it's equally applicable for other libraries.
      
      For example, if we are using the host's libxkbcommon.so.0, we'll also
      want the host's libxkbcommon-x11.so.0 if at all possible, because
      libxkbcommon-x11 uses private data structures from libxkbcommon and
      will crash if they are not sufficiently similar.
      
      steamrt/tasks#530
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      58c5d20c
    • Simon McVittie's avatar
      library-cmp: When listing symbols, ignore the name of each verdef · b98b1448
      Simon McVittie authored
      
      Conventionally, for each version definition in a shared library, there
      is a symbol named after the verdef with absolute value 0. For example,
      libdbus has a symbol LIBDBUS_1_3@LIBDBUS_1_3, and similarly libxkbcommon
      has symbols V_0.8.0@V_0.8.0 and so on.
      
      These will typically not match any of the glob patterns that we use to
      mark symbols as being public or private, leading to spurious warnings
      like this one:
      
          i386-linux-gnu-capsule-capture-libs: warning: we are assuming "V_0.5.0" to be private, but it's just a guess
      
      So far, we have avoided this because we have not used the "symbols"
      comparison order for any library that has verdefs, but I'm intending
      to use "versions,name,symbols" for libxkbcommon.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      b98b1448
  6. Aug 23, 2024
  7. Aug 22, 2024
  8. Aug 20, 2024
  9. Aug 19, 2024
    • Simon McVittie's avatar
      run-outside-ldlp: Do basic logging initialization before parsing arguments · 35ce994c
      Simon McVittie authored
      
      _srt_log_failure() uses a custom log level that is understood by our
      log handler, so it doesn't work until we have set our log handler,
      which we do the first time _srt_util_set_glib_log_handler() is called.
      If we fail and early-return before the log handler is set, that leads
      to errors being reported strangely:
      
          $ srt-run-outside-ldlp --wrong
          steam-runtime-tools-LOG-0x100: 21:28:47.912: Unknown option --wrong
      
      Not setting the program name also meant that we'd log as `(null)`,
      for example:
      
          (null)[12345]: I: Found 'cat' at /usr/bin/cat
      
      or possibly crash if somehow run with a less tolerant libc.
      
      Fixes: ecaade46 "run-outside-ldlp: Add new tool for escaping the LDLP runtime"
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      35ce994c
  10. Aug 16, 2024
Loading