Skip to content
Snippets Groups Projects
  1. Jun 28, 2021
  2. Mar 31, 2021
    • Ludovico de Nittis's avatar
      urlopen: Add a more clever xdg-open executable · 2f212fc2
      Ludovico de Nittis authored and Simon McVittie's avatar Simon McVittie committed
      When inside a Steam Runtime container we currently make `xdg-open`
      points to the `flatpak-xdg-utils` implementation that relies on
      `xdg-desktop-portal`. But if an user doesn't have a working
      `xdg-desktop-portal` it will fail.
      
      Additionally the `steam://`
      
       URLs might end up opening another instance
      of the Steam client, even if one instance was already running. This can
      happen if more than one version are installed, e.g. the Steam client
      from the distro repositories and the Flatpak version.
      
      With this alternative implementation we try a more clever approach that
      should workaround the `xdg-open` shortcomings that we experienced in our
      Steam related use cases.
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      [smcv: Install all /usr/bin/steam-runtime-* executables]
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      2f212fc2
  3. Mar 30, 2021
  4. Nov 10, 2020
    • Simon McVittie's avatar
      input-device: Add skeleton API for enumeration and monitoring · a08464d9
      Simon McVittie authored
      
      This includes:
      
      * a public interface implemented by input device monitors
      * a public interface to be implemented by the input devices they signal
      * a mock implementation for unit-testing
      * a unit test for the API
      * a simple implementation in terms of inotify on /dev
      * a monitor that can print input devices in JSON format on stdout,
        and optionally monitor them
      
      Implementations in terms of udev, SDL, or a portal service are not yet
      included. Details of the devices, beyond their paths in /dev and /sys,
      are also not included.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      a08464d9
  5. Oct 22, 2020
  6. Oct 07, 2020
  7. Jun 10, 2020
  8. Apr 14, 2020
  9. Jan 09, 2020
    • Simon McVittie's avatar
      build: Consistently sort dependencies in stack order · 9a3cfb41
      Simon McVittie authored
      
      It's slightly preferable to list linker and compiler flags in stack
      order, with the lowest in the stack first. This allows use of a
      higher-level library from a non-standard prefix without also necessarily
      picking up lower-level libraries from the same non-standard-prefix.
      For example, if /path/to/json-glib also includes a copy of GLib, then
      
          -L/path/to/glib -lglib-2.0 -L/path/to/json-glib -ljson-glib-1.0
      
      will link the GLib from /path/to/glib, but
      
          -L/path/to/json-glib -ljson-glib-1.0 -L/path/to/glib -lglib-2.0
      
      will link both the GLib and the json-glib from /path/to/json-glib.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9a3cfb41
  10. 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
  11. Nov 13, 2019
    • Simon McVittie's avatar
      Revert "Build -system-info and -check-locale with relative DT_RPATH" · a32d9290
      Simon McVittie authored
      
      This made them usable from outside the LD_LIBRARY_PATH runtime, but breaks
      their use inside a pressure-vessel container. In pressure-vessel, the
      glibc family of libraries are typically taken from outside the container
      (for example /overrides/lib/x86_64-linux-gnu/libc.so.6), and the dynamic
      linker ld.so is replaced with one that is suitable for the libraries
      in /overrides. In general, these versions will be incompatible with the
      ones in /usr/lib/x86_64-linux-gnu, which unfortunately are the ones that
      get pulled in via the DT_RPATH.
      
      This reverts commit 91478a07.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      a32d9290
  12. Nov 08, 2019
    • Simon McVittie's avatar
      Build -system-info and -check-locale with relative DT_RPATH · 91478a07
      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.
      
      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>
      91478a07
  13. Sep 09, 2019
  14. Aug 06, 2019
  15. Jun 27, 2019
Loading