Skip to content
Snippets Groups Projects
  1. May 17, 2021
  2. May 12, 2021
  3. May 11, 2021
  4. May 07, 2021
  5. Apr 30, 2021
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      Update changelog · 1fa5d59f
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1fa5d59f
    • Ludovico de Nittis's avatar
      Merge branch 'wip/smcv/mtree' into 'master' · 20e57546
      Ludovico de Nittis authored
      pressure-vessel: Use a mtree(5) manifest to set up the runtime
      
      See merge request !295
      20e57546
    • Simon McVittie's avatar
      runtime: Add support for creating runtime from a mtree(5) · 799b7931
      Simon McVittie authored
      
      At the moment we deploy the runtime from a giant tarball to avoid Steam
      downloader limitations, but that leads to a noticeable delay the first
      time we launch a game after a new runtime version has been downloaded.
      
      Now that the Steam download mechanism can deal better with larger
      numbers of smaller files, we're considering returning to the original
      design where the runtime depot contains unpacked files. However, the
      Steam download mechanism doesn't preserve permissions, modification
      times, or filenames that differ only by case, and has not always
      preserved empty directories, so we need a way to deal with all of
      those things.
      
      By reading a manifest written in a subset of the BSD mtree(5) format,
      we can create directories and symlinks, and set permissions modification
      times on regular files. As a bonus, it's actually slightly faster to
      duplicate a runtime with hard-links (--copy-runtime mode) by reading the
      manifest than by reading the actual directory tree, because the manifest
      is more likely to be contiguous on disk.
      
      In principle the mtree(5) manifest could also be used to validate that
      the runtime content has not become corrupted by checking files against
      their sha256sums. This isn't implemented here (and it would have to be
      done only on demand rather than routinely, because it would be slow),
      but the parser does at least read the sha256.
      
      In the tests, we now need to remove the mtree manifest when copying
      and editing a runtime. When we edit a runtime in-place, it no longer
      conforms to the manifest, so this can't necesarily be expected to work.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      799b7931
    • Simon McVittie's avatar
      pressure-vessel: Add code to parse and apply a mtree(5) manifest · 1bdf777d
      Simon McVittie authored
      
      This can be used to create directories, symlinks and zero-byte files,
      create files as a clone (hard-link or copy) of files in a reference
      directory, assert that files exist, set executable/non-executable
      permissions, and set files' modification times.
      
      When cloning files from a reference directory, the default is to use
      the same filename as the destination, but that can be overridden
      (for example to deal with inconvenient/non-Windows-friendly filenames).
      This is also actually slightly faster than pv_cheap_tree_copy(),
      presumably because the manifest is contiguous on-disk and the
      directories are not necessarily.
      
      Setting directories' modification times is implemented, but probably
      won't work in practice, because any files we create in the directory
      will alter its mtime.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1bdf777d
  6. Apr 28, 2021
  7. Apr 27, 2021
  8. Apr 26, 2021
  9. Apr 22, 2021
    • Simon McVittie's avatar
      pressure-vessel: Remove utility function to look up ELF SONAME · 0ccd527d
      Simon McVittie authored
      
      This is no longer used.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      0ccd527d
    • Simon McVittie's avatar
      pv-runtime: Avoid opening libraries to determine their SONAME · fce30b8d
      Simon McVittie authored
      
      This is surprisingly expensive to do, particularly with a cold cache.
      If we can avoid this, then deleting unwanted libraries from the mutable
      copy of the runtime becomes a lot faster.
      
      With the disk cache cleared and running on slow hardware, this cuts
      down deletion of the unwanted libraries from 2-4 seconds to basically
      instantaneous.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      fce30b8d
    • Simon McVittie's avatar
      pv-runtime: Delete dangling development symlinks to overridden libraries · 640fc1af
      Simon McVittie authored
      
      Some development libraries follow this pattern, and we already delete
      those without needing to use libelf to load the library and find out
      its SONAME:
      
          libfcitx-config.so -> libfcitx-config.so.4
          libfcitx-config.so.4 -> libfcitx-config.so.4.1
          libfcitx-config.so.4.1
      
      However, other libraries follow this pattern, which results in the code
      that uses libelf to find the SONAME being the only way we can figure out
      that the .so symlink needs removing:
      
          libdbus-glib-1.so -> libdbus-glib-1.so.2.2.2
          libdbus-glib-1.so.2 -> libdbus-glib-1.so.2.2.2
          libdbus-glib-1.so.2.2.2
      
      To avoid relying on the libelf code path, which is surprisingly slow
      when run with a cold disk cache, we can do one scan through the
      directory removing regular files and runtime symlinks, and a second
      scan through the directory removing development symlinks that have
      become dangling as a result.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      640fc1af
Loading