Skip to content
Snippets Groups Projects
  1. Jun 03, 2020
  2. Mar 13, 2020
  3. Mar 12, 2020
    • Simon McVittie's avatar
      CI: Codify how to build on Arch Linux · 1fd9e54b
      Simon McVittie authored
      
      Some libcapsule users and contributors are using Arch Linux or Manjaro
      rather than a Debian derivative.
      
      Many of the tests will be skipped on Gitlab-CI because they need a
      working bubblewrap, which isn't allowed inside unprivileged Docker;
      but this provides "executable documentation" for how to do a build
      and test.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1fd9e54b
  4. Jan 16, 2020
  5. Jan 15, 2020
  6. Nov 14, 2019
  7. Nov 11, 2019
  8. Oct 02, 2019
    • Simon McVittie's avatar
      build: Check that the compiler and --host are consistent · 8bf9b114
      Simon McVittie authored
      
      libcapsule's use with biarch containers like the Steam Runtime will
      frequently make it necessary to compile it for both x86_64 and i386.
      
      On recent Debian-derived OSs this is OK, because the toolchain is
      provided as a complete set of cross-compiler-style prefixed tools like
      i686-linux-gnu-gcc; but some OSs, like Arch Linux and very old versions
      of Debian, rely on 'gcc -m32' for their biarch support. This makes it
      very easy to do
      
          ./configure --build=x86_64-linux-gnu --host=i686-linux-gnu
      
      and accidentally produce x86_64 binaries, because there is no
      i686-linux-gnu-gcc. Give the user a hint towards the correct invocation
      in this case, which is:
      
          ./configure --build=x86_64-linux-gnu --host=i686-linux-gnu CC='gcc -m32'
      
      I've implemented this as a reusable macro, in case we want to add it to
      other projects that are likely to be cross-compiled by inexperienced
      cross-compiler users.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      8bf9b114
  9. Sep 26, 2019
    • 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: default avatarSimon McVittie <smcv@collabora.com>
      610c7004
    • Simon McVittie's avatar
      Prepare v0.20190926.0 · da30b75e
      Simon McVittie authored
      
      Signed-off-by: default 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: default 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: default avatarSimon McVittie <smcv@collabora.com>
      702fc558
  10. Sep 19, 2019
    • 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
  11. Sep 18, 2019
  12. Jul 25, 2019
  13. Jul 24, 2019
  14. Apr 16, 2019
  15. Apr 02, 2019
  16. Jan 30, 2019
Loading