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.
Otherwise, all the progress reporting for the extra data being downloaded
won't work, as the main context used by OstreeAsyncProgress will not be
the same than the one from the nested main loop used to download this.
This is supposed to list all the currently loaded "non-standard" gl drivers.
If FLATPAK_GL_DRIVERS is set, then that is used, otherwise it looks
for an nvidia driver and if so, uses that, and always adding "default"
at the end which is meant to resolve to a stable mesa fallback build, as
well as "host" which can be used if you have a host-side driver
as an unmaintained extension.
If directory is "foo" and the extension id ends with ".ext" and
subdirectory-suffix is "sub" then the extension point will
be "/usr/foo/ext/sub" rather than just "/usr/foo/ext".
This is very useful when the extension point naming scheme is
"reversed". For instance, this happens for the /usr/share/themes directory.
An extension point for a gtk3 theme would be in /usr/share/themes/$NAME/gtk-3.0,
which could be achived by using subdirectory-suffix=gtk-3.0.
If your extension points set this, then each extension will have
the corresponding subdirectory added to LD_LIBRARY_PATH.
We also support a priority property in the ExtensionOf group
in the extensions themselves to set the search order.
If we sort, or subset the extensions we use, then we can't just
set need_tmpfs on the first one, instead do the checking
for the first one when we're applying the extensions.
The main loop that is initiated while the extra data is being downloaded
needs a different context to be the thread-default one, otherwise the
operations just hang when running from a different thread.
Matthias Clasen