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/
If you do something like:
flatpak build --talk-name=org.foo.Bar appdir
Then we now spawn a dbus proxy for the app.
However, we don't do this by default, even if the
runtime or the app metadata allows this, because
we want builds to normally be disconnected from
the build host.
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.
By splitting the extra-data setup - where we set the number of
extra-data downloads and auxiliary information - and download -
where we actually fetch the extra-data - we can have more precise
progress reports.
Otherwise, clients such as GNOME Software won't be able to report
any progress once the flatpak application has been downloaded and
we enter the stage to download the extra data.
In extract_extra_data(), flatpak currently returns TRUE whenever
flatpak_repo_get_extra_data_sources() returns NULL, which is correct
most of the times since that's usually caused by the extra-data
finish-args argument not being present.
However, that operation relies on OSTree's ostree_repo_load_variant()
too, which could fail for unrelated reasons. And in those cases flatpak
would still keep returning TRUE here even in cases where the extra-data
sources could be there, but an error happened while retrieving it.
This seems to be a bug leading to unlikely -yet possible- situations,
where the user would end up with an "external app" like Spotify reported
to be succesfully installed but without the files/extra directory, which
is useless.
Before this commit
$ flatpak install --arch someArch --from some.flatpakref
Would completely ignore the arch argument and only install for the
default flatpak architecture. Since flatpakref files don't include
an arch field, there's no reason we can't attempt to install the
arch specified on the command line.
This change fixes GCC compiler warnings where a cleanup function was
specified on an uninitialised pointer, which in the view of GCC could
result in an errornous free of uninitialised memory, if the functions
that initialise them do not return NULL.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
If the bundle contains an origin link we can now install related
things from it, such as locale data.
You can also build the bundle with --runtime-repo=URL, where the url
points to a flatpakrepo file for a repo with runtimes. This works
similar to the RuntimeRepo= feature in flatpakref files.
This will be useful for testing purposes, so that we can provide
our own versions of the configuration files normally under
/etc/flatpak/installations.d.
This will allow explicitly referring to the default installation
using the 'default' ID, as well as overriding its values via a
configuration file specifying that same ID.
Implemented the following functions along with the required internal APIs:
* flatpak_installation_get_id ()
* flatpak_installation_get_display_name ()
* flatpak_installation_get_priority ()
* flatpak_installation_get_storage_type ()
As per the discussion with GNOME Software maintainer Richard Hughes [1],
we need to support a few additional fields in the configuration files
for better integration with external clients. Thus, this commits adds
support for reading "DisplayName", "StorageType" and "Priority" values
from the configuration files, being all of them optional.
Note: priorities are currently used to sort the system installations
list statically stored in flatpak-dir.c (bigger number, bigger priority).
[1] https://mail.gnome.org/archives/gnome-software-list/2016-December/msg00000.html
This information will be used when querying system-wide installations,
so that we can refer to those pre-configured installations by the id
defined in the configuration files under /etc/flatpak/installations.d
This will return an array of FlatpakDir instances with all the system
installations configured via key files in an optional drop-in directory
under FLATPAK_CONFIGDIR/installations.d, plus the default one.
User and system installations is no longer a binary decision, so remove
this API to force explicit calls to either flatpak_dir_get_system_default()
or flatpak_dir_get_system_list() when dealing with system installations.
There will be a way to retrieve the list of all system installations,
not just the default one, so we rename this for backward compatibility.
Note that some (most?) of the places where we will be now using this
renamed function will likely have to migrate to using specific system
installations, but we don't have the necessary APIs yet so we do this
as an initial step to all the incremental changes that will come next.
This was manully checked in some places, which can now be dropped, but
also the places that didn't check it before were buggy and needed
to check this, so better just fail early.
This avoids an unnecessary call to flatpak_dir_modify_remote() or to
the system helper's D-Bus method ConfigureRemote, which also prevents
bothering the user to authenticate via PolKit for no reason.
Add logic in flatpak_dir_update_remote_configuration() so that the step of
configuring the local remotes after fetching the required date from the
server's summary file is performed via the system helper when present.
Note this will require the user authorizing the action by introducing
the password explicitly when asked, but this is necessary as updating
the local remotes configuration is something that can't be allowed
without explicit authentication.
It turns out that flatpak_dir_remote_fetch_summary can return TRUE,
yet leave summary_bytes NULL. The code further down does not deal
gracefully with summary_bytes being NULL, so error out early instead
of crashing.
We don't really need to create an origin remote if the same
uri is already there for an enumeratable remote, we can
just reuse that. Having multiple remotes for a single
repository just means we'll be downloading the summary file
multiple times.
Without this patch flatpak-remote-add (and anything else that uses this
section of code) segfaults if org.freedesktop.Flatpak.SystemHelper is
unavailable because it tries to cast an integer to a GDbusProxy.
Colin Walters