When a collection ID is set on a remote configuration,
gpg-verify-summary should be set to FALSE because flatpak uses signed
per-repo and per-commit metadata instead. The flatpak command line
already does this (use flatpak remote-modify --collection-id=... and
notice that gpg-verify-summary is then set to false). This commit
changes libflatpak to have the same behavior. Specifically, with a
collection ID set gpg-verify-summary is set to false and otherwise its
value matches that of gpg-verify. This commit also adds a test for this
in testlibrary.c.
Fixes https://github.com/flatpak/flatpak/issues/1479Closes: #1501
Approved by: pwithnall
Mark subpaths as a NULL terminated array. Without this the GIR makes
this a single utf8 parameter and bindings can't use it.
Closes: #1327
Approved by: cgwalters
If you're installing something and its already installed, we undeploy
the old install first before deploying the new. This makes it very
easy to switch an application from one remote to another, without
having to uninstall first, which is both painful and could cause
the download to be unnecessary large.
Closes: #1241
Approved by: alexlarsson
This introduces no functional changes, but makes it a bit more obvious
that we do temporarily have ownership of the FlatpakInstallation
instance.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1138
Approved by: alexlarsson
If a particular system installation is inaccessible (for example,
because it doesn’t currently exist, and we don’t have permissions to
create it), don’t error out of flatpak_get_system_installations().
Instead, do what the documentation says will happen, and ignore the
failure (emit a warning message about it).
The function continues to return an error if *no* installations could be
found.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1138
Approved by: alexlarsson
This is a method to explicitly prune the local repo, which
users might want to use if they had explicitly removed refs from
the underlying flatpak repo and want to ensure that the objects
referred to by those refs are cleared to save on disk space.
Closes: #1034
Approved by: alexlarsson
In some cases, a user might pull a ref into the local repository and
not deploy it by using FLATPAK_INSTALL_FLAGS_NO_DEPLOY. Later on, that
user might decide that they don't want to deploy the ref after all,
but there was no way to remove that ref from the local repository
in the public API, so it takes up disk space.
Add flatpak_installation_remove_local_ref_sync to remove a given
ref from the local repository if the ref is known and
flatpak_installation_cleanup_local_refs_sync to remove all undeployed
refs.
Fixes#1031Closes: #1034
Approved by: alexlarsson
We have the same flags for flatpak_installation_update and we use
flatpak_dir_install from within FlatpakInstallation but always set
the no_pull/no_deploy flags to FALSE. Previously, passing
FLATPAK_INSTALL_FLAGS_NO_PULL and FLATPAK_INSTALL_FLAGS_NO_DEPLOY
wouldn't do anything because of that.
This has the unfortunate side effect of always returning an error
when FLATPAK_INSTALL_FLAGS_NO_DEPLOY is passed, because
flatpak_installation_install_full tries to get a FlatpakInstalledRef
for the flatpak when it is installed, but obviously it can't do that
since installing an app in an undeployed state doesn't "install" it
so much as just cloning it to the local repository.
As a result, when FLATPAK_INSTALL_FLAGS_NO_PULL is passed, the
FLATPAK_ERROR_ONLY_PULLED Will be set and the caller must respond
accordingly.
We're scoping the deploy directory by the subpaths these days, so
we need to take that into account when finding the metadata file.
Fixes https://github.com/flatpak/flatpak/issues/1014
This is declared in the header file, but was never actually implemented.
Oops.
If anybody is hit by this issue, they can work around it by using
g_object_get() to get the FlatpakRemote:type property, which this is the
getter for.
Add it to the tests as well, so it gets exercised.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than a lot of #ifdef mess in the public headers, Alex would
prefer that the P2P API is made unconditionally public. This assumes
that they are unlikely to change in future. If they do, we just make
them return NULL or break API and drop them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This isn’t really used internally, but will be used by gnome-software
for when it configures new flatpak remotes.
This is new public API, but is only declared if compiling with
--enable-p2p.
Includes some basic smoketests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will only be built when configured with P2P support. We can’t use
glib-mkenums here, as it doesn’t know about the #ifdef
FLATPAK_ENABLE_P2P which surrounds the enum definition. By manually
writing the get_type() function, we can surround it by #ifdefs as
appropriate.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add support for collection IDs to the code which finds and pulls
related refs and other extensions.
Currently, related refs must have the same collection ID as the parent
ref — this is the most likely scenario anyway. In future, it should be
possible to extend the code to support pulling related refs from other
collections.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This adds a new collection-id property which is only enabled if
FLATPAK_ENABLE_P2P is defined. The internal machinery for handling it is
always enabled, to reduce the amount of #ifdef spam.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Also expose a new flatpak_remote_get_remote_type() API so that users can
query what type of remote something is — whether it’s a USB or LAN
remote, or something statically configured.
Make this all conditional on compiling with --enable-p2p.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Search for updates on peer to peer sources as well as the internet in
check_for_updates(), and pass the resulting OstreeRepoFinderResult array
to the pull() calls, so a consistent set of checksums are pulled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The GLib logging framework automatically appends a \n to messages, so it
doesn’t need to be added by callers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Sometimes we need to pull a commit without using static deltas to e.g.
make sure that an app with a corrupted commit can still be updated by
pulling the new commit in full.
This option has been added to the FlatpakUpdateFlags,
FlatpakInstallFlags, as well as a parameter for the CLI.
After the introduction of linear progress reports based on
heuristics, Flatpak still couldn't make precise reports for
the extra-data field is contained in the commits. When we
were setting extra-data up, Flatpak didn't have the commits,
so it always failed.
Fix that by downloading the commits first, and then setting
up the extra-data fields.
flatpak/flatpak#609
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/
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).
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.
