If you have a repo where a needed object has been inadvertantly removed,
all you'll get is a "No such metadata object" error with no clue about
where it was referenced from.
Add some debug messages to provide clues about which objects are being
traversed and found.
https://bugzilla.gnome.org/show_bug.cgi?id=764006Closes: #224
Approved by: cgwalters
When prune fails, it can be really difficult to figure out why. This at
least lets you know which objects are being considered.
https://bugzilla.gnome.org/show_bug.cgi?id=764006Closes: #224
Approved by: cgwalters
The dirtree object is required for traversing, so don't use the
load_variant_if_exists() function. This will return a
G_IO_ERROR_NOT_FOUND to the caller rather than trying to ref a NULL
variant in ostree_repo_commit_traverse_iter_init_dirtree() if the object
is missing.
https://bugzilla.gnome.org/show_bug.cgi?id=764091
If a commit only pull has been done, then the commit object exists in
the object store in addition to the commitpartial file. Traversing this
partial commit will likely fail, but that's expected. If traverse
returns a G_IO_ERROR_NOT_FOUND in this case, continue with pruning.
https://bugzilla.gnome.org/show_bug.cgi?id=764091
test-lzma builds a copy of the compressor and decompressor directly, so
the compiler needs access to the LZMA headers and the linker needs to
link the program with liblzma.
libtest always makes a copy of the gpghome directory to the test
directory, so there's no need to operate on the installed copy. This
allows test-remote-gpg-import to pass as an unprivileged user since it
otherwise couldn't create the temp files gpgme creates.
On 32 bit systems, _FILE_OFFSET_BITS will be set to 64 by
AC_SYS_LARGEFILE. This causes the glibc headers to use readdir64 rather
than readdir. Emulate that behavior in the preloader or the tests will
all fail with "No such file or directory".
This test uses gpgme directly to verify the signatures, so it needs to
find the gpgme headers and link with gpgme to ensure the linker can
resolve the symbols.
The object count comes from g_hash_table_size(), so it's not a 0 based
index. In order to maintain the mod calculations correctly, just print
out index + 1.
https://bugzilla.gnome.org/show_bug.cgi?id=746360
Dan Nicholson