1. 26 Sep, 2019 4 commits
    • Simon McVittie's avatar
      Add basic Gitlab-CI using deb-build-snapshot · 610c7004
      Simon McVittie authored
      This verifies that libcapsule compiles and works on Debian 9,
      Ubuntu 18.04 and Debian 10.
      
      To use, change your libcapsule fork's CI/CD settings to include:
      
          Custom CI config path: ci/gitlab-ci.yml
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      610c7004
    • Simon McVittie's avatar
      Prepare v0.20190926.0 · da30b75e
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      da30b75e
    • Simon McVittie's avatar
      capture-libs: Treat unversioned libraries as in indeterminate order · d3d888c9
      Simon McVittie authored
      On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular
      file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most
      shared libraries.
      
      However, on Fedora 30 it is a symlink to a versioned name like
      libgcc_s-9-20190827.so.1. The name used in Fedora happens to be less
      than libgcc_s.so.1 in strverscmp() order, causing capsule-capture-libs
      to prefer the Debian/Manjaro libgcc_s.so.1, even if the container is
      older. This can cause problems if an old Debian-derived container like the
      Steam Runtime is used on a newer Fedora host, with host graphics drivers
      imported by using capsule-capture-libs: the container's libgcc_s.so.1
      does not satisfy the versioned symbol requirements of the graphics driver,
      causing loading to fail.
      
      Treat a regular file libgcc_s.so.1 as indeterminate order (or "equal"),
      so that we fall back to the default behaviour, which is currently to
      take the host version of the library in the case of a tie.
      
      This is a stopgap solution: ideally we would consider the versioned
      symbols exported by both libraries, and take whichever one has a superset
      of the version definitions exported by the other, if there is a strict
      superset in either direction (in the case of libgcc, in fact there is).
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      d3d888c9
    • Simon McVittie's avatar
      Revert "WIP: capture-libs: Treat unversioned libraries as in indeterminate order" · 702fc558
      Simon McVittie authored
      This reverts commit faf3daa9, which
      was merged with an outdated commit message.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      702fc558
  2. 19 Sep, 2019 1 commit
    • Simon McVittie's avatar
      WIP: capture-libs: Treat unversioned libraries as in indeterminate order · faf3daa9
      Simon McVittie authored
      On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular
      file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most
      shared libraries. However, on Fedora 30 it is a symlink to a versioned
      name like libgcc_s-9-20190827.so.1.
      
      This can cause problems if a Debian-derived container is used on a Fedora
      host, with host graphics drivers.
      
      TODO: it isn't clear whether this change makes any practical difference,
      because strverscmp("libgcc_s.so.1", "libgcc_s-9-20190827.so.1") == 0
      anyway.
      faf3daa9
  3. 18 Sep, 2019 2 commits
  4. 25 Jul, 2019 1 commit
  5. 24 Jul, 2019 2 commits
  6. 16 Apr, 2019 1 commit
  7. 02 Apr, 2019 10 commits
  8. 30 Jan, 2019 18 commits
  9. 15 Aug, 2018 1 commit