Skip to content
Snippets Groups Projects
  1. Oct 10, 2023
  2. Oct 06, 2023
  3. Oct 05, 2023
  4. Oct 04, 2023
    • Simon McVittie's avatar
      pv-runtime: Use a closer match for 99-pulseaudio-default.conf · 6315238a
      Simon McVittie authored
      `pcm.!default pulse` assumes that a device named `pulse` already exists
      in the configuration (which it might, but equally it might not) and
      overwrites (because of the `!`) the definition of the `default` device
      with an alias for `pulse`, which could be written as
      
          pcm_devices["default"] = pcm_devices["pulse"]
      
      in a somewhat more conventional language.
      
      In contrast to that, `pcm.!default { type pulse }` overwrites the
      definition of the `default` device with a newly-defined device whose
      *type* is `pulse`, more like this pseudocode:
      
          pcm_devices["default"] = new PcmDevice(type="pulse")
      
      The latter is what `99-pulseaudio-default.conf.example` actually does,
      and therefore what the fdo runtime's `99-pulseaudio-default.conf`
      actually does (because it's just a copy of
      `99-pulseaudio-default.conf.example`, see
      https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/870889cdde734557298b8e0e4506e275cacb4f90
      for the precise implementation).
      
      In pressure-vessel we write this to `/etc/asound.conf` rather than into
      `/etc/alsa/conf.d/` because very old versions of libasound like the one
      in Steam Runtime 1 'scout' only supported the former and not the latter,
      but otherwise we intend to mimic what the fdo runtime does, so let's
      mimic it a little closer. This should make games and other programs
      that output via libasound, like Shadowrun Returns and `aplay`, more
      reliable in the container.
      
      One other minor divergence from `99-pulseaudio-default.conf.example`
      is that we don't set the human-readable name
      `Default ALSA Output (currently PulseAudio Sound Server)` on the
      device, which seems a bit much for a targeted fix.
      
      Thanks: Nozomi Miyamori
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/623
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      6315238a
    • Simon McVittie's avatar
      tests: Stop assuming libcrypt will be pulled into a scout container · d6f8bc11
      Simon McVittie authored
      
      This is not guaranteed to be the case now that we are treating libcrypt
      as potentially a separate library, which is necessary to support
      use of libxcrypt.
      
      Fixes: 81d0099a "Merge libcapsule/v0.20230928.0"
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d6f8bc11
  5. Sep 28, 2023
  6. Sep 27, 2023
  7. Sep 26, 2023
    • Simon McVittie's avatar
      capture-libs: Don't treat libcrypt.so.1 as part of glibc · 451b114f
      Simon McVittie authored
      
      libcrypt.so.1 is build-time optional since glibc 2.28, and is not built
      by default since 2.38. In newer distributions like Debian >= 11 and
      Ubuntu >= 20.04, it's usually replaced by libxcrypt, either compiled
      to be a drop-in replacement for glibc's libcrypt.so.1 (as in Debian,
      and therefore the Steam Runtime), or with its own SONAME libcrypt.so.2
      and optionally a secondary build as libcrypt.so.1 (as in Arch).
      
      Because libxcrypt implements a superset of the glibc libcrypt.so.1 ABI,
      adding some functions and symvers of its own, it is backward- but not
      forward-compatible: it's OK to use libxcrypt libcrypt.so.1 as a
      replacement for glibc libcrypt.so.1, but it is not OK to do the opposite.
      This means it would be incorrect for us to use a system copy of glibc
      libcrypt.so.1 (perhaps from glibc 2.32 or newer) as a replacement for a
      container's libxcrypt libcrypt.so.1, even if the system copy of glibc
      is strictly newer than the container's glibc (for example,
      Steam Runtime 3 'sniper' is based on Debian 11, so it comes with
      glibc 2.31 and libxcrypt).
      
      Unlike libpthread, libdl and librt, symbols from `libcrypt.so.1` were
      never absorbed into `libc.so.6`, so we don't have to apply the reasoning
      seen in 4c2e3e3b "capture-libs: Add a special case to support glibc 2.34+".
      
      In practice we've always got away with it in the past, but it's something
      that could cause a crash or incompatibility. I'm now looking into the
      possibility of backporting libxcrypt into Steam Runtime 1 and 2
      (steamrt/tasks#332), which makes it more important to get this right.
      
      Accordingly, exclude libcrypt.so.1 from that special treatment, and
      instead set it up to be compared separately using the same comparators
      we use for glibc: by public symvers, then by public symbols, and as a
      last resort by name.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      451b114f
    • Simon McVittie's avatar
      library-cmp: Make some symbols static · 0b1179c9
      Simon McVittie authored
      
      These are only directly used within their translation unit,
      therefore don't need to be extern.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      0b1179c9
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      capture-libs: Add references for some more architectures · b321c0af
      Simon McVittie authored
      
      Just for completeness, we're not going to support any of these any
      time soon.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      b321c0af
  8. Sep 22, 2023
  9. Sep 19, 2023
Loading