Skip to content
Snippets Groups Projects
  1. Aug 20, 2021
  2. May 11, 2021
  3. Apr 21, 2021
  4. Mar 25, 2021
  5. Dec 04, 2020
  6. Nov 25, 2020
  7. Nov 20, 2020
  8. Nov 19, 2020
  9. Nov 17, 2020
  10. Nov 10, 2020
  11. Sep 14, 2020
  12. Jul 09, 2020
  13. Jul 08, 2020
  14. Jun 16, 2020
  15. Apr 14, 2020
  16. Apr 09, 2020
  17. Apr 03, 2020
    • Simon McVittie's avatar
      scripts: Assert that we have the desired Python version · b4f85647
      Simon McVittie authored
      
      In Steam Runtime 1 'scout' and Steam Runtime 1½ 'heavy' SDK
      environments, we have a backport of python3.5 in order to run Meson,
      and meson.build automatically selects it if available.
      
      In newer environments like a developer's laptop, we expect to have a
      strictly newer Python version, like the python3.7 in Debian 10.
      
      One notable exception is that we only require Python 3.4+ for scripts
      that are meant to run on test machines or on non-developer Steam users'
      systems, which right now just means the test UI. This version was chosen
      because SteamOS 2 'brewmaster' and Ubuntu 14.04 'trusty' both have 3.4.
      
      Ubuntu 12.04 'precise' only has 3.2, but the Steam client doesn't
      actually work on 12.04 any more for orthogonal reasons.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      b4f85647
  18. Mar 12, 2020
  19. Mar 06, 2020
  20. Mar 05, 2020
  21. Mar 04, 2020
  22. Feb 27, 2020
  23. Jan 09, 2020
  24. Dec 05, 2019
    • Simon McVittie's avatar
      Put symbolic links to dependencies in their own package · 9e9c20de
      Simon McVittie authored
      
      This avoids the need to Build-Conflict with the -helpers package,
      which we want to install in the SDK image.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9e9c20de
    • Simon McVittie's avatar
      Add Build-Conflicts on libsteam-runtime-tools-0-helpers · ea250de4
      Simon McVittie authored
      
      Since steam-runtime-tools was made relocatable in c3a06cce, its build
      will fail with the Steam Runtime 1 'scout' version of dpkg if it is
      already installed system-wide.
      
      If the SDK container where steam-runtime-tools is built has our
      $(pkglibexecdir) populated with symbolic links to the dependency
      libraries, then dpkg-shlibdeps will look there to convert DT_NEEDED
      dependencies into Debian dependencies. Unfortunately, the version of
      dpkg in SteamRT 1 'scout' has Debian bug #843073, which means it assumes
      all libraries are found via their canonical names as listed in the dpkg
      database, not a symlink-based alias. This results in the build failing
      with an error similar to:
      
          dpkg-shlibdeps: error: no dependency information found for
          /usr/lib/x86_64-linux-gnu/steam-runtime-tools-0/libglib-2.0.so.0
          (used by
          debian/libsteam-runtime-tools-0-helpers/usr/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-locale)
      
      Until we get a newer Docker image with a newer version of this
      package that works around this issue, we will have to remove it
      explicitly before running CI. Adding Build-Conflicts is not enough:
      autopkgtest installs build-dependencies, but does not remove
      Build-Conflicts.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      ea250de4
  25. Nov 20, 2019
  26. Nov 15, 2019
    • Simon McVittie's avatar
      Build -system-info and -check-locale with relative DT_RPATH · c3a06cce
      Simon McVittie authored
      
      This ensures that they can find the non-ubiquitous json-glib library,
      and the steam-runtime-tools library, even if relocated into a
      non-standard prefix like the LD_LIBRARY_PATH Steam Runtime.
      
      We can't just use a relative version of the standard library directory
      as our RPATH, because if we did that, we would load glibc from the
      same place. This causes crashes in pressure-vessel, where ld.so and
      the rest of glibc are often taken from the host system via
      /overrides/lib, and the glibc in /lib and /usr/lib is incompatible
      with ld.so. Instead, use a private library directory and populate it
      with relative symlinks to our non-glibc dependencies; we assume the
      host version of glibc is new enough that this is OK.
      
      Using DT_RPATH in preference to DT_RUNPATH means we take all our direct
      and indirect dependencies from the same place. This is important when
      libjson-glib (which won't ordinarily have a RUNPATH or RPATH) pulls in
      GIO as an indirect dependency of check-locale, which doesn't directly
      depend on GIO. The GIO library we get must match the versions of GLib
      and GObject we're using.
      
      This also bypasses LD_LIBRARY_PATH.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      c3a06cce
  27. Oct 31, 2019
  28. Oct 30, 2019
  29. Sep 26, 2019
  30. Sep 12, 2019
  31. Sep 11, 2019
  32. Sep 09, 2019
  33. Aug 22, 2019
  34. Aug 21, 2019
Loading