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 required for e.g. G_DECLARE_FINAL_TYPE, and most current
distros have this now.
This fixes https://github.com/flatpak/flatpak/issues/622
For distributions that want to build against older glib, see
the issue above, it has patches to make that work.
This just adds the arch name to the cache branch names, which
means a build on a different arch will not invalidate the other
arch:s build.
Fixes https://github.com/flatpak/flatpak/issues/628
Avoid setting a temporary variable flatpak_dirs which, while not
exported to the environment, would still be defined as a
shell "parameter" (variable) in the login shell itself.
Consistently put the Flatpak directories before other XDG_DATA_DIRS,
rather than putting them last if XDG_DATA_DIRS happens to be already
set.
Expand XDG_DATA_HOME if necessary, rather than assuming it will
always be ~/.local/share.
I don't know exactly which shells source profile.d, but it's possible
that one of them might only implement POSIX test syntax, so prefer
[ x = y ] over [ x == y ].
Fix some insufficient quoting that could have gone wrong if
XDG_DATA_DIRS somehow contained spaces.
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
When calculating the progress of a flatpak installation,
it considers the extra-data and OSTree pull as different
operations and that makes the progress to go back and
forth between 0% and 100%.
Consumers of this API, like GNOME Software, end up having
a bad experience reporting the progress of a Flatpak app
instalation.
Fix that by using a set of heuristics to improve the process,
splitting the operation in parts that can be tracked (or at
least estimated).
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.
* Append flatpak data dirs if XDG_DATA_DIRS is already set
Otherwise it will be impossible to run flatpak apps from desktop menus.
This issue can happen if another app (e.g. snapd) wants to add custom
folders to XDG_DATA_DIRS through /etc/profile.d
If XDG_DATA_DIRS is empty or unset, define it as before.
Fixes#606
A few options aren't documented in the manpages. This commit adds
documentation for them based on the --help output and relevant commit
messages. Some of it could probably use more elaboration.
For a few commands the options aren't fully documented. This commit
makes the manpage documentation (almost) match the options shown
when you run "<command> --help" on the command line.
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.
Colin Walters