We add socat to the test runtime, and then we use that to run a
test app outside the sandbox as if it was inside.
The testcase connects creates a monitor and ensure we properly get signals
for updates.
This allows an application to request it to be updated to the latest version.
The updates are done out-of-process by re-spawning the portal (via
/proc/self/exe) and proxying the relevant events over a socket pair, in
order to avoid any long term stability or memory requirements from
running the update operation.
For example, if org.the.App or org.the.Platform is masked that means
we don't want to get any updates to it. Its very likely that we also
don't want updates to extensions of this app or runtime. For example,
we definately don't want to update the .Locale or .Debug extensions.
As per https://gitlab.gnome.org/GNOME/glib/merge_requests/490
there is a bug in glib < 2.60 where g_spawn_* can sometimes deadlock
due to using malloc in the child func to close fds.
We work around this in places where the code is (potentially) threaded
by passing glib flags to leave fds alone and then do a very naive
(but safe) fd cloexec loop ourselves.
This commands lets you selectively disable auto-download of extensions
based on patterns. With this we can have extensions that install
by default, yet still allow the user to not have them re-installed
each time flatpak update is run.
This fixes https://github.com/flatpak/flatpak/issues/3090
This means you can use "org.foo.bar//stable" instead of "org.foo.bar/*/stable"
which is similar to what other APIs do.
We want to use this for masking extensions too, thus the export.
This allows the introspection data to be generated with the correct type for each of these properties, instead of just `int`. This should improve the quality of the documentation as well as bindings generated from the introspection data.
This allows you to ensure that a particular app/runtime is installed
and with the latest version in a single operation, which is useful
for instance in automatic use, like CI systems.
If the installation contains 1 or more installed refs, but none of those
refs have a remote with a collection ID, then 'results' will be NULL but
'installed' will be non-NULL. Since
c29e686246, 'results[0]' is used in this
situation – a NULL pointer dereference. There is an existing 'results !=
NULL' check inside the body of this loop, but this is too late.
Check whether 'results' is NULL before dereferencing it.
Fixes#3134.
We want to block merging for these, to ensure that you autosquash
before merging.
Ideally we'd like automatic (or at least via a bot) autosquashing, but
that is not currently possible.
Otherwise the build failed on older glib version, but with this setup
we still disable all the GTimeVal deprecation warnings.
Closes: #3122
Approved by: alexlarsson
We generally want to avoid using deprecated stuff as much as we
can, while still depending on an old glib version. However, the GTimeVal
deprecation in 2.62 just is impossible to work around without bumping
the requirements, so ignore newer deprecations.
Closes: #3119
Approved by: alexlarsson
Assert it was successful instead. This is probably pointless from the
point of view of testing things (why would symlink() ever realistically
fail but everything else succeed?), but it does shut up a compiler
warning, which gives us a better chance to spot legitimate warnings in
future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #3116
Approved by: alexlarsson
Currently flatpak_installation_fetch_remote_ref_sync() does not work
offline. It returns an error when it fails to fetch the remote's summary
in flatpak_dir_get_remote_state(). This is a problem since GNOME
Software (or at least the Endless fork) uses this library function to
display apps it finds on a USB drive (see gs_plugin_refine_item_origin()
in gs-flatpak.c) and that's something that should work even offline.
So this commit changes flatpak_dir_get_remote_state_optional() so that
it accepts the only_cached option, and updates the call sites. Also have
fetch_remote_ref_sync() use flatpak_dir_get_remote_state_optional(),
which means that when we're offline we will use the xa.cache data in the
ostree-metadata ref as a list of refs list instead of using a summary.
However since the commit checksums are not in xa.cache, we don't have
enough information to form a FlatpakRemoteRef. So also call
ostree_repo_find_remotes_async() to get the commit from any LAN or USB
sources that may be available. This may not be very performant but at
least it only happens if the ref wasn't found in a remote summary; see
https://github.com/flatpak/flatpak/issues/1862
It's sad this code is so long-winded but it's difficult to break out a
helper function that could be shared with
list_remotes_for_configured_remote() above. Longer term we could improve
the ostree_repo_find_remotes_async() API and add options to remove the
need to manually handle OstreeRepoFinder objects.
Closes: #3114
Approved by: alexlarsson
Currently FlatpakInstalledRef objects are constructed without the
collection-id property set. This is a problem because in the USB app
update support in the Endless fork of GNOME Software, when we find a
FlatpakRemoteRef on a USB drive which matches the ref of a
FlatpakInstalledRef object, the collection IDs of the two objects must
also match, and currently the installed one has a NULL collection ID.
So get the collection ID on the relevant configured remote when
constructing a FlatpakInstalledRef. This should be good enough in most
cases but isn't perfect; see
https://github.com/flatpak/flatpak/issues/3103Closes: #3114
Approved by: alexlarsson
In commit b8a3075d8 I changed a few places to check if the array
returned by ostree_repo_find_remotes_finish() is empty, which would mean
either none of the configured remotes (or P2P sources) provide the
requested refs, or the one(s) that do are offline. That was mostly
correct but in the case of
flatpak_installation_list_installed_refs_for_update() we don't want to
treat empty results as an error, because otherwise GNOME Software prints
an error message when offline: "No remotes found which provide these
refs: ...".
So this commit makes list_installed_refs_for_update() return an empty
array in case it can't find any updates (we don't distinguish "remotes
checked and provide no updates" from "remotes couldn't be reached").
This matches the behavior of the non-P2P code: the for loop above which
handles remotes without collection IDs prints a debug message if an
error is encountered.
Also, add a unit test that fails without this patch.
Closes: #3066
Approved by: alexlarsson
The commands array contains entries that serve
just as section titles; avoid returning those
when looking for misspelt commands.
Pointed out in https://github.com/flatpak/flatpak/issues/3040Closes: #3107
Approved by: matthiasclasen
Support a list of versions that are supported. This will be useful
for e.g. the extra_data for extensions once that is backported to
1.2, because that will require it to say that it is supported for
> 1.2.5 in the 1.2 series and > 1.4.2 otherwise.
Closes: #3112
Approved by: alexlarsson
This sets required-flatpak in the metadata to some different versions
and ensure we're properly able or not able to install it.
Additionally it uses some options with multiple versions. This is not
yet supported but I want to test the existing code and make sure it
properly falls back to just using the first element of the list.
Closes: #3112
Approved by: alexlarsson
