1. 04 Oct, 2018 5 commits
  2. 01 Oct, 2018 2 commits
  3. 27 Sep, 2018 1 commit
  4. 28 Aug, 2018 2 commits
  5. 23 Aug, 2018 5 commits
  6. 22 Aug, 2018 1 commit
  7. 21 Aug, 2018 3 commits
  8. 20 Aug, 2018 4 commits
  9. 19 Aug, 2018 3 commits
    • Will Thompson's avatar
      repo: remove outdated note from write_config() docs · 2b198693
      Will Thompson authored
      Since 9dc6ddce it has not been true that
      'new_config' was simply ref'd: it's serialized, and then re-parsed into
      a new GKeyFile.
      
      Closes: #1707
      Approved by: jlebon
      2b198693
    • Will Thompson's avatar
      man/ostree.repo-config: improve min-free-space-* docs · ada5716f
      Will Thompson authored
      0 is not a valid value (the units are required), and 1MB is taken to
      mean 1048576 bytes, not 1000000 bytes (unlike other human-readable sizes
      in libostree, which are formatted by g_format_size(), and hence use
      power-of-10 units). It's probably a bit late to change this latter
      point, but the documentation should mention it.
      
      Define 'MB' etc. more precisely; include the byte counts in the
      examples; and improve the formatting of the min-free-space-* paragraphs.
      Signed-off-by: 's avatarWill Thompson <wjt@endlessm.com>
      
      Closes: #1706
      Approved by: mwleeds
      ada5716f
    • Jonathan Lebon's avatar
      ci: Bump rpm-ostree tag we build for tests · 57dbd176
      Jonathan Lebon authored
      The latest rpm-ostree release no longer requires `python3-devel` so `dnf
      builddep` here is no longer pulling it in, subsequently causing issues
      when building an older rpm-ostree release. Let's just bump the release
      tag so we don't have to also start keeping track of older dependencies.
      
      Closes: #1708
      Approved by: cgwalters
      57dbd176
  10. 14 Aug, 2018 7 commits
    • Dan Nicholson's avatar
      repo: Add OSTREE_REPO_TEST_ERROR=invalid-cache env var · 4e6b13e8
      Dan Nicholson authored
      Add an invalid-cache test error flag to ensure that the code that checks
      for and recovers from a corrupted summary cache is hit. This helps make
      sure that the recovery path is actually used without resorting to
      G_MESSAGES_DEBUG.
      
      Closes: #1698
      Approved by: cgwalters
      4e6b13e8
    • Dan Nicholson's avatar
      tests: Test for recovery from corrupted summary cache · 1b5cb52d
      Dan Nicholson authored
      Check that recovery from a corrupted summary cache (cached summary
      doesn't match cached signature) works.
      
      Closes: #1698
      Approved by: cgwalters
      1b5cb52d
    • Dan Nicholson's avatar
      lib/pull: Fetch summary if cached version doesn't match signature · e5061f54
      Dan Nicholson authored
      If for some reason the cached summary doesn't match the cached signature
      then fetch the remote summary and verify again. Since commit c4c2b5eb
      this is unlikely to happen since the summary will only be cached if it
      matches the signature. However, if the summary cache has been corrupted
      for any other reason then it's best to be safe and fetch the remote
      summary again.
      
      This is essentially the corollary to c4c2b5eb. Where that commit helps
      you from getting into the corrupted summary cache in the first place,
      this helps you get out of it. Without this the client can get wedged
      until a prune or the remote server republishes the summary.
      
      Closes: #1698
      Approved by: cgwalters
      e5061f54
    • Dan Nicholson's avatar
      lib/pull: Add debug message when loading summary from cache · 1c69f1ed
      Dan Nicholson authored
      This helps when debugging issues with the cached summary handling.
      
      Closes: #1698
      Approved by: cgwalters
      1c69f1ed
    • Dan Nicholson's avatar
      tests: Add tests for remote summary update races · ce4eb12f
      Dan Nicholson authored
      There have been subtle bugs in the past when a client pulls while the
      remote server is updating the summary. The client may get the old
      summary and new signature or vice versa. Add tests to simulate this
      behavior to make sure there aren't regressions in the future.
      
      Closes: #1698
      Approved by: cgwalters
      ce4eb12f
    • Stefan Agner's avatar
      Avoid race condition in case tests directory does not exist · 4a389b30
      Stefan Agner authored
      Make sure the tests directory exists before symlinking files
      into it.
      
      Closes: #1703
      
      Closes: #1704
      Approved by: cgwalters
      4a389b30
    • Alexander Larsson's avatar
      ostree_repo_pull_from_remotes_async: Fix leak of options · 0a53af80
      Alexander Larsson authored
      copy_option() unnecessarily passed ownership of the value
      to g_variant_dict_insert_value, but that already refs, so it was leaked.
      
      Closes: #1702
      Approved by: cgwalters
      0a53af80
  11. 13 Aug, 2018 2 commits
  12. 01 Aug, 2018 5 commits
    • Jonathan Lebon's avatar
      lib/commit: Only auto-update summary if refs were written · 521e0ec3
      Jonathan Lebon authored
      Closes: #1693
      Approved by: mwleeds
      521e0ec3
    • Jonathan Lebon's avatar
      lib/config: Deprecate commit-update-summary option · 72a54fa8
      Jonathan Lebon authored
      Now that we have `auto-update-summary`, there is no point in having
      `commit-update-summary`. The latter also only had an effect through
      the `commit` CLI command, whereas the former is embedded directly in
      libostree.
      
      There is one corner case that slips through: `commit` would update the
      summary file even if orphan commits were created, which we no longer do
      here. I can't imagine anyone relying on this, so it seems safe to drop.
      
      Closes: #1689
      
      Closes: #1693
      Approved by: mwleeds
      72a54fa8
    • Jonathan Lebon's avatar
      lib/config: Rename change-update-summary to auto-... · 786ee6bd
      Jonathan Lebon authored
      Mildly bikeshed, though I find the name `auto-update-summary` to be
      easier to grok than `change-update-summary`. I think it's because it can
      be read as "verb-verb-noun" rather than "noun-verb-noun".
      
      Closes: #1693
      Approved by: mwleeds
      786ee6bd
    • Jonathan Lebon's avatar
      lib/refs: Use GLNX_HASH_TABLE_FOREACH_KV helper · 3e96ec98
      Jonathan Lebon authored
      Closes: #1693
      Approved by: mwleeds
      3e96ec98
    • Matthew Leeds's avatar
      lib/repo-pull: Use correct keyring for dynamic remotes · daa57b46
      Matthew Leeds authored
      Normally, a configured remote will only serve refs with one associated
      collection ID, but temporary remotes such as USB drives or LAN peers can
      serve refs from multiple collection IDs which may use different GPG
      keyrings. So the OstreeRepoFinderMount and OstreeRepoFinderAvahi classes
      create dynamic OstreeRemote objects for each (uri, keyring) pair. So if
      for example the USB mounted at /mnt/usb serves content from the
      configured remotes "eos-apps" and "eos-sdk", the OstreeRepoFinderResult
      array returned by ostree_repo_find_remotes_async() will have one result
      with a remote called something like
      file_mnt_usb_eos-apps.trustedkeys.gpg and the list of refs on the USB
      that came from eos-apps, and another result with a remote
      file_mnt_usb_eos-sdk.trustedkeys.gpg and the list of refs from eos-sdk.
      
      Unfortunately while OstreeRepoFinderMount and OstreeRepoFinderAvahi
      correctly only include refs in a result if the ref uses the associated
      keyring, the find_remotes_cb() function used to clean up the set of
      results looks at the remote summary file and includes every ref that's
      in the intersection with the requested refs, regardless of whether it
      uses a different remote's keyring. This leads to an error when you try
      to pull from a USB containing refs from different collection IDs: the
      pull using the wrong collection ID will error out with "Refspec not
      found" and the result with the correct keyring will then be ignored "as
      it has no relevant refs or they have already been pulled." So the pull
      ultimately fails.
      
      This commit fixes the issue by filtering refs coming from a dynamic
      remote, so that only ones with the collection ID associated with the
      keyring remote are examined. This only needs to be done for dynamic
      remotes because you should be able to pull any ref from a configured
      remote using its keyring. It's also only done when looking at the
      collection map in the summary file, because LAN/USB remotes won't have a
      "main" collection ID set (OSTREE_SUMMARY_COLLECTION_ID).
      
      Closes: #1695
      Approved by: pwithnall
      daa57b46