Skip to content
Snippets Groups Projects
  1. Jun 17, 2020
    • Simon McVittie's avatar
      runtime: Optionally copy the runtime, and bind-mount the copy · 66d41ccd
      Simon McVittie authored
      
      This is good for two reasons. In a Flatpak runtime, we will not be able
      to do tricks with arbitrary bind-mounts; if we want the host library
      stack, we will have to rewrite the mutable copy of the runtime to
      replace container libraries with symlinks into /run/host. Also, when
      not in a Flatpak runtime, having a mutable copy of the immutable runtime
      gives developers a chance to edit the runtime to inject workarounds or
      things they're testing.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      66d41ccd
  2. Jun 16, 2020
    • Simon McVittie's avatar
      runtime: Don't use bwrap to run locale-gen when not required · a7741724
      Simon McVittie authored
      
      If we're running locale-gen on the host system, we might as well just
      run it, without wrapping bwrap around it. This requires the new
      --output-dir option in p-v-locale-gen.
      
      To stay consistent, also move from bwrap --chdir DIR to
      p-v-locale-gen --output-dir DIR in the case where we still need to
      use bwrap.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      a7741724
    • Simon McVittie's avatar
      runtime: Access runtime without using bwrap if possible · 135bea0b
      Simon McVittie authored
      
      If the runtime is already "the right shape", then we don't need to
      use bwrap to mount it on /usr and populate a suitable tmpfs root
      filesystem.
      
      We need to do this if we want to support being run from inside a
      Flatpak, because we can't run bwrap inside Flatpak. It might also
      speed up accesses to suitable runtimes, because we won't waste time
      invoking extra bwrap processes.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      135bea0b
    • Simon McVittie's avatar
      runtime: Really use the realpath() of the host ld.so · d8cc2d35
      Simon McVittie authored
      
      flatpak_canonicalize_filename() only does a syntactic normalization,
      eliminating ./ and similar constructs; it does not resolve symbolic
      links. We need to use the realpath() of the 64-bit dynamic linker,
      because otherwise, when we start replacing the dynamic linker in the
      container with a symlink into /run/host, the host system might have
      a symlink /lib64/ld-linux-x86-64.so.2 pointing outside /lib64,
      for example to /lib/ld-linux-x86-64-2.30.so.
      Then we'd get:
      
          runtime's ld-linux-x86-64.so.2 ->
          /run/host/lib64/ld-linux-x86-64.so.2 ->
          /lib/ld-linux-x86-64-2.30.so ->
          does not necessarily exist inside container
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      d8cc2d35
    • Simon McVittie's avatar
      6fdde58f
    • Simon McVittie's avatar
      runtime: Sort DRI "search path" more carefully · 623648fd
      Simon McVittie authored
      
      As noted in the comment, the order matters.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      623648fd
    • Simon McVittie's avatar
      runtime: Save a bwrap invocation and a shell by not using globbing · b51d3fd8
      Simon McVittie authored
      
      This was using bwrap to make ${libdir}/dri available on
      /run/host/${libdir}/dri, in order to run the equivalent of:
      
          ln -fns /run/host/${libdir}/dri/* /overrides/lib/${tuple}/dri/
      
      Instead of using the shell wildcard '*' to implement readdir(), let's
      just call readdir(${libdir}/dri) ourselves, and fix up the symlink
      targets to point into /run/host/${libdir}/dri.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      b51d3fd8
    • Simon McVittie's avatar
      runtime: Reset PATH in the container · 3fea265c
      Simon McVittie authored
      
      The PATH from outside the container doesn't really make sense inside
      the container, because the directory hierarchy could be totally different
      (particularly on unusual host systems like GoboLinux and Exherbo).
      
      Resetting it also makes sure we don't pick up local installations in
      ~/bin or ~/.local/bin, which could have dependencies that are
      unsatisfied in the container.
      
      Conversely, the PATH from the host might not include everything we need
      in the container. If the host system is an OS that only supports
      merged-/usr use, like Arch Linux, then it might not have both /usr/bin
      and /bin in the PATH - but if the container is not merged /usr, like a
      scout SDK sysroot, then we'll need both.
      
      This approximately matches Flatpak's behaviour: by default it resets
      PATH to /app/bin:/usr/bin (because it puts app-specific content in /app
      and can assume that its runtimes are always merged-/usr).
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      3fea265c
  3. Jun 12, 2020
  4. May 21, 2020
  5. May 20, 2020
  6. May 18, 2020
  7. Apr 15, 2020
  8. Apr 09, 2020
  9. Mar 24, 2020
  10. Mar 23, 2020
  11. Mar 18, 2020
  12. Mar 04, 2020
Loading