We artificially limit the metadata phase to the first 20 metadata
objects, because otherwise that phase takes too long time, as it
downloads content at the same time.
For the delta case we can get perfect results by just ignoring
the counts and relying on the sizes. However, this needs a
recent ostree that supports the fetched-delta-part-size field.
For the object case we keep using the object average size
to estimate a size which we can compare with the extra data
size.
Now that we have access to the total extra-data download size,
we can have much more precise progress reports by summing up
all the download sizes from OSTree and extra-data.
This patch makes the progress report callback use the extra-data
sizes, as well as calculate the average size (in bytes) of the
content.
flatpak/flatpak#609
It turns out the underlying call ostree_repo_query_object_storage_size
doesn't work for staged objects, so we work around this by actually
loading the object, walking back to the original unix input stream
and fstat:ing the fd from that.
When clients install/update they will see this property in the
(signed) summary and update the url in the config, making this
essentially a permanent redirect.
This is a pretty standalone object, and it is nicer to
have it in its own files. All users have been updated
to include the new flatpak-table-printer.h header.
The new `glnx_regfile_copy_bytes()` is better than the previous
`flatpak_copy_bytes()` in that it will use reflink/sendfile if available.
More information in 3a4d0f4684
This means we verify the exact data we use, which is
what was signed. In particular, this means in the
system-helper we don't open us up to the user
manipulating the file while it is being applied.
This ensures the actual manifest ref matches what was specified
in the index. This is required as the goal is to sign/trust
the manifest, but not necessarily the index.
We should not terminate the extension search just because
an earlier directory succeeds. Even non-existant directories
succeed, and anyway we should continue searching even if it
wasn't empty, because multiple subdir extensions may match.
Fixes https://github.com/flatpak/flatpak/issues/654
In ostree I maintain what I consider a "baseline" set of compiler
warnings that should *always* be fatal for a modern C project.
I noticed while working on a previous patch that a `-Werror=format`
warning wasn't fatal.
There are a few that are really, really important like
`-Werror=missing-prototypes`. I also take some like `-Werror=misleading-indentation`
which already caught some bugs. See also https://lwn.net/Articles/678019/
One benefit here becomes immediately obvious - `flatpak_fail()` was lacking
`G_GNUC_PRINTF` which meant we missed a lot of type checking. Fix up the
callers.
This is a major change in the OCI support, as the format of the OCI image
registries changed. Instead of now having a "ref" file for each image
in the repo it has a single index json file, where the ref name is now
a per-image annotation.
This allows us to support OCI much better, as we can now use the actual
flatpak ref as the OCI ref name, and we can find all the flatpak refs
in a remote.
So, with this you can just use:
flatpak remote-add --oci remote-name URL
and then you can use the regular flatpak operations on the remote.
This means an extension point can include extensions of multiple
(specified) versions. This is useful for e.g. the GL extensions,
where we want a single extension for all the essentially unversioned
GL extensions (like the nvidia one) that is used by all the
runtimes.
So far, the installation of external apps can only be cancelled
before flatpak starts downloading the extra data, as there's no
cancellable being passed to g_input_stream_read_async().
This fixes that problem, making it possible to cancel installs
from GNOME Software regardless of the installation stage.
Alexander Larsson