Skip to content
Snippets Groups Projects
  1. Aug 05, 2024
  2. May 20, 2024
  3. May 16, 2024
    • Simon McVittie's avatar
      utils test: Locate test data relative to executable correctly · d89d6cda
      Simon McVittie authored
      
      Because libcapsule uses non-recursive make, G_TEST_SRCDIR and
      G_TEST_BUILDDIR are set to the top-level directory of the source/build
      tree. When running the test suite "as-installed", the equivalent for
      both is `${libexecdir}/installed-tests/libcapsule`.
      
      This matters because we locate the "version 1" and "version 2" libraries
      during testing as `${builddir}/tests/version{1,2}`, which is incorrect
      (a duplicate `tests/`) if the `${builddir}` is set to the `tests`
      subdirectory rather than the top-level directory.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d89d6cda
    • Simon McVittie's avatar
      debian: Require at least automake 1.15 · 381a4f2f
      Simon McVittie authored
      
      Steam Runtime 1 'scout' only has 1.11 as its default version, and that's
      too old for AM_TESTS_ENVIRONMENT to be respected. It does have 1.15
      available, so make sure we have at least that version one way or another.
      
      At the moment this is mitigated by the fact that scout only has GLib 2.32,
      which is too old, and we use --with-glib=auto to skip building and running
      the one test that uses GLib (utils.t) when building on scout - which
      happens to be the only test where correct handling of AM_TESTS_ENVIRONMENT
      was strictly required. However, if we backport a newer GLib into scout,
      we'll start running that test, and therefore we'll need it to work.
      
      steamrt/tasks#112
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      381a4f2f
  4. Mar 05, 2024
  5. Sep 28, 2023
  6. 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
  7. Aug 02, 2023
    • Simon McVittie's avatar
      Release v0.20230802.0 · 12874211
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      12874211
    • Simon McVittie's avatar
      CI: Use Debian 13 prereleases to test with sanitizers · 23f1a939
      Simon McVittie authored
      
      Now that the tests pass on merged-/usr systems, we can use a more modern
      Debian suite.
      
      Normally I'd use the latest Debian stable (Debian 12), but that seems
      to have a false positive for a printf argument to %s being NULL,
      causing the asan/ubsan builds to fail; so use Debian 10 and 11 as our
      representatives of older systems, together with Debian 13 prereleases
      as our representative of a modern system.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23f1a939
    • Simon McVittie's avatar
      tests: Fix expectations for merged-/usr systems · de669890
      Simon McVittie authored
      
      Previously, we were assuming that the symlink created by
      capsule-capture-libs would point to the `realpath()` of a library,
      possibly with a `--link-target` prefix. However, it actually only
      resolves the symlink representing the SONAME: it will resolve `libz.so.1`
      to `libz.so.1.2.13`, but unlike Perl `abs_path()` or C `realpath()`,
      it will not necessarily resolve symlinks in the directory hierarchy
      leading up to that point.
      
      For example, on a merged-/usr system like Debian >= 12, /lib is a
      symbolic link to usr/lib. The realpath() of `libz.so.1` is something like
      `/usr/lib/MULTIARCH/libz.so.1.2.13`, but because both `/lib/MULTIARCH`
      and `/usr/lib/MULTIARCH` appear in `/etc/ld.so.conf.d`, it is undefined
      whether capsule-capture-libs will output `/lib/MULTIARCH/libz.so.1.2.13`
      or `/usr/lib/MULTIARCH/libz.so.1.2.13`.
      
      Relax the expectations of this test so we only say that the symlink
      points to some reasonable `$libdir`, followed by the `basename()` of the
      `realpath()` of `libc.so.6`.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      de669890
    • Simon McVittie's avatar
      75294a71
    • Simon McVittie's avatar
      capture-libs: Use warnx() instead of warn() when errno is not set · 6ff340cb
      Simon McVittie authored
      
      `warn(fmt, args)` is equivalent to (pseudocode)
      `warnx(fmt + ": %s", args, strerror(errno))`. In contexts where we do
      not have a useful value for errno, or where we are showing an error
      message that should already contain a previous result of strerror, we
      should use warnx() instead. This avoids showing a misleading errno
      which might have been set for some unrelated reason.
      
      Prompted by jupiter/tasks#887.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      6ff340cb
  8. Aug 01, 2023
  9. Jul 27, 2023
  10. Oct 06, 2022
  11. Jun 23, 2022
  12. Jun 22, 2022
  13. Oct 26, 2021
  14. Oct 25, 2021
Loading