Skip to content
Snippets Groups Projects
  1. Aug 06, 2024
    • Simon McVittie's avatar
      Update changelog · 87bb21cf
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      87bb21cf
    • Simon McVittie's avatar
      Merge libcapsule subtree v0.20240806.0 · 577a4c1f
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      577a4c1f
    • Simon McVittie's avatar
      Prepare v0.20240806.0 · f87c1373
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      f87c1373
    • Simon McVittie's avatar
      Merge branch 'wip/refi64/logger-reopen-fix' into 'main' · 411fb777
      Simon McVittie authored
      logger: Fix always re-opening files when --log-fd is used
      
      See merge request !743
      411fb777
    • Simon McVittie's avatar
      capture-libs: Never undo our rewriting of the symlink target · a7e7fa13
      Simon McVittie authored
      Previously, if we were using --remap-link-prefix but not --link-target
      (as in pressure-vessel), and if the path at which we found the
      library in the provider (`needed_path_in_provider`) was such that
      after resolving symlinks, the canonicalized result (`path`) did not
      match any of the --remap-link-prefix options, then we would reset
      to using the `needed_path_in_provider` as the symlink target.
      
      However, this was wrong, because it did not take into account the
      possibility that the original path might have matched one of the
      --remap-link-prefix options even though its canonicalized version didn't.
      
      For example, consider the NixOS "FHS environment", a bwrap-based
      container that has been populated with symlinks of the form
      /lib/libGL.so.1 -> /nix/store/something. Depending on the precise
      behaviour of libc and libdl (the exact trigger for the differing
      behaviour is unknown), when we open that library, we might find
      that the `needed_path_in_provider` is either /lib/libGL.so.1
      or a path below /nix/store.
      
      If the `needed_path_in_provider` is /lib/libGL.so.1, we would
      canonicalize it to /nix/store/something, then decide that
      /nix/store/something didn't match any of the remapping rules such
      as `/lib*` → `/run/host/lib*`, and go back to using /lib/libGL.so.1
      as the symlink target. But, inside pressure-vessel's container, `/lib`
      is from the container runtime and not the provider - which is precisely
      why we need to rewrite /lib paths to /run/host/lib in order to be
      able to find the library we want.
      
      Instead, we must limit the situation where we keep the
      `needed_path_in_provider` as-is to the situation where there is no
      symlink target rewriting: no --link-target, and no --remap-link-prefix.
      In this situation, we are expecting the meaning of a symlink in the
      container environment to be identical to the meaning of a symlink in
      the environment from which we are running capsule-capture-libs,
      therefore it's slightly preferable to use a non-canonicalized symlink
      if we have one: that way, if the target of a symlink changes during
      the container's lifetime (perhaps as a result of an OS upgrade),
      it will still work.
      
      Conversely, if we are using either --link-target or --remap-link-prefix,
      we want to stick to using only the canonicalized paths of libraries,
      because that's the only way we can avoid a symlink being interpreted
      differently outside and inside the container, for example as a result
      of its parent directory being mounted in a different place, or as a
      result of something different being mounted at its target.
      
      This means that we have to relax one of our test assertions slightly.
      
      Helps: https://github.com/ValveSoftware/steam-runtime/issues/684
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      a7e7fa13
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      logger: When we reopen a file, log an info message that says why · d43f5da2
      Simon McVittie authored
      
      This would have made it considerably easier to spot that
      commit 8f65507d "logger: Recreate output log files if they get deleted"
      was reopening the log file more often than it should have been.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d43f5da2
    • Simon McVittie's avatar
      logger: When we reopen a file, make sure to record its new identity · 478c424c
      Simon McVittie authored
      
      Otherwise, after reopening a deleted or replaced file, we would reopen
      it once per line, because its inode number constantly differs from
      the original inode number.
      
      After commit 1f502cb4 "logger: Fix always re-opening files when
      --log-fd is used", this was the only remaining place where we assign
      to self->file_fd without also assigning to self->file_stat.
      
      Fixes: 8f65507d "logger: Recreate output log files if they get deleted"
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      478c424c
    • Simon McVittie's avatar
      tests: Assert that "quiet:" works as intended · b58a3d40
      Simon McVittie authored
      
      In a test that already emits a warning message, prepending "quiet:"
      to the pattern should de-escalate the warning to a debug message.
      
      In a test that emits a fatal error, prepending "quiet:" to the pattern
      has no effect: it's still an error.
      
      steamrt/tasks#488
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      b58a3d40
    • Simon McVittie's avatar
      capture-libs: Add a new flag to suppress warnings · f18de5a3
      Simon McVittie authored
      
      Sometimes we find ourselves capturing a library for which the
      dependencies can legitimately be missing, for example
      `libnvidia-pkcs11.so.*` on Ubuntu 24.04 (which depends on OpenSSL 1.1,
      which Ubuntu no longer provides).
      
      This is really an OS bug (providing a library without its dependencies),
      and ideally Ubuntu should stop providing `libnvidia-pkcs11.so.*`
      (like Debian did), but it results in confusing messages that could make
      a user wrongly believe that it's the root cause of a genuine problem.
      
      steamrt/tasks#488
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      f18de5a3
  2. Aug 05, 2024
  3. Aug 02, 2024
  4. Aug 01, 2024
  5. Jul 31, 2024
  6. Jul 26, 2024
Loading