Skip to content
Snippets Groups Projects
  1. Jul 22, 2024
  2. Jul 19, 2024
    • Simon McVittie's avatar
      Merge branch 'wip/task477' into 'main' · 7c58bfcd
      Simon McVittie authored
      pv-runtime: Try to mount /usr/${LIB}/gconv into container
      
      See merge request !726
      7c58bfcd
    • Simon McVittie's avatar
      pv-runtime: Try to mount /usr/${LIB}/gconv into container · 744fecda
      Simon McVittie authored
      
      Previously we assumed that the hard-coded directory used to dlopen
      gconv modules matched the realpath() of the directory containing
      libc.so.6, disregarding any compatibility symlinks: for example, on
      Red Hat, 64-bit gconv modules are in /usr/lib64/gconv, and on Debian
      they're in /usr/lib/x86_64-linux-gnu/gconv.
      
      However, this turns out not to be true on Void Linux, where
      /usr/lib64 -> lib is a non-canonical path, but the hard-coded path
      that will be used to load iconv modules is /usr/lib64/gconv anyway.
      
      We cannot simply set GCONV_PATH, because apparently setting
      `GCONV_PATH=/usr/lib/gconv:/usr/lib32/gconv` will break 32-bit
      applications: unlike the equivalent with LD_LIBRARY_PATH, a 32-bit
      application would try and fail to load the 64-bit module from
      /usr/lib/gconv (it will fail to load because its word size does not
      match the word size of the process), and then will not fall back to
      /usr/lib32/gconv as one might expect.
      
      Luckily, on Void Linux, the libdl dynamic string token ${LIB} has been
      chosen such that the correct path for each architecture's gconv modules
      is /usr/${LIB}/gconv. We can use this as an additional guess at the
      necessary mount point for the gconv modules, mounting /usr/lib/gconv
      onto both /usr/lib/gconv and /usr/lib64/gconv - that way, it doesn't
      matter whether the path hard-coded in glibc matches our old heuristic
      or our new heuristic, because either one will work.
      
      steamrt/tasks#477, ValveSoftware/steam-runtime#680
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      744fecda
  3. Jul 18, 2024
  4. Jul 17, 2024
    • Simon McVittie's avatar
      pv-runtime: Don't try to mask /etc/vulkan/*.d · f926ea58
      Simon McVittie authored
      
      Since updating our Flatpak-derived code, every time we start a container
      we log messages like:
      
          N: Not replacing "/etc/vulkan/implicit_layer.d" with tmpfs: Path "/etc" is reserved by the container framework
      
      We only import selected directories from /etc into the container's /etc,
      and none of the directories below /etc/vulkan are among them, so there
      is actually no need to mask these directories. Silence the warning by
      not attempting to mask them.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      f926ea58
    • Simon McVittie's avatar
      Update changelog · 9b2356c7
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9b2356c7
    • Simon McVittie's avatar
      Revert "pv-runtime: Add a mechanism to take custom CA certificates from the host" · 9e3d9c85
      Simon McVittie authored
      
      This was implemented in a way that assumed it would only be enabled
      on specially-flagged developer systems, making it acceptable for the
      implementation to be non-robust and make assumptions about the host
      systems on which it would be enabled; but current Steam betas enable
      it for the steamwebhelper unconditionally, which would cause serious
      regressions on non-Debian-derived, non-Arch-derived host OSs.
      
      Revert the addition of this feature to avoid regressions. Before
      reinstating it, we will either need to arrange for Steam to enable it
      conditionally as previously planned, or make the implementation fail
      gracefully and harmlessly on non-Debian-compatible host systems.
      
      This reverts commit d6a519f5.
      
      steamrt/tasks#416
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9e3d9c85
  5. Jul 09, 2024
Loading