Skip to content
Snippets Groups Projects
  1. Nov 30, 2020
  2. Nov 24, 2020
  3. Nov 17, 2020
    • Simon McVittie's avatar
      bwrap: Don't bind-mount files into /etc as part of binding /usr · 23035e38
      Simon McVittie authored
      
      If we want to deal with strange operating systems that use a non-standard
      filename for ld.so.cache, we'll have to special-case it. There's
      little extra cost to doing this because we already need to understand
      how ld.so.cache works, to be able to generate our own with different
      search paths.
      
      In situations where we just want a quick container to be able to inspect
      the runtime, we can deal with this by mounting all of /etc read-only.
      
      For the final container, we already iterate over all the files in the
      runtime's /etc, which will "naturally" include ld.so.cache and
      alternatives.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23035e38
  4. Oct 26, 2020
  5. Oct 22, 2020
    • Simon McVittie's avatar
      pressure-vessel: Disable GIO modules differently · 92b1c2b6
      Simon McVittie authored
      
      Now that GIO_MODULE_DIR has been backported into scout's GLib, we can
      disable GIO modules completely, instead of loading them but then not
      using them. This avoids some misleading warnings (#32).
      
      This will not be completely effective on non-Debian systems until we
      also patch scout's GLib to make GIO_MODULE_DIR take precedence over
      the hard-coded legacy search path /usr/lib/gio/modules.
      
      The unit test for this is still in tests/pressure-vessel/utils.c
      for now.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      92b1c2b6
  6. Oct 19, 2020
  7. Oct 06, 2020
  8. Oct 01, 2020
  9. Sep 30, 2020
  10. Sep 28, 2020
  11. Sep 25, 2020
  12. Sep 09, 2020
  13. Sep 08, 2020
  14. Sep 07, 2020
  15. Sep 04, 2020
  16. Sep 02, 2020
  17. Sep 01, 2020
    • Simon McVittie's avatar
      wrap: Don't populate environment of FlatpakBwrap that will be merged · 07f02a83
      Simon McVittie authored
      
      The default for a FlatpakBwrap object is to copy the calling
      environment as a base for the environment that it will build up.
      However, that's wrong if we are going to merge more than one
      FlatpakBwrap together: the merged FlatpakBwrap's argv will be appended
      to the destination FlatpakBwrap, but the merged envp will overwrite the
      corresponding variables in the destination.
      
      Avoid this by making sure that every time we merge two FlatpakBwrap
      objects, one of them has an empty environment.
      
      Resolves: T23422
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      07f02a83
  18. Aug 19, 2020
  19. Aug 18, 2020
Loading