This commit ensures that flatpak_remote_state_save_summary()
initializes the passed GError pointer when returning FALSE. I found this
when looking into https://github.com/flatpak/flatpak/issues/1255 because
at the time of that bug report flatpak_dir_update_appstream() had this
g_file_replace_contents() code in it, which would have caused a seg
fault in update_appstream() after an unsuccessful call to
flatpak_dir_update_appstream().
Fixes https://github.com/flatpak/flatpak/issues/1255Closes: #1893
Approved by: alexlarsson
If a remote is added or modified in the cloned FlatpakDir
we also drop caches in the one in the installation.
Fixes#1882Closes: #1883
Approved by: alexlarsson
If the system helper process exits due to being idle the
FlatpakSystemHelper dbus proxy will return errors on
all calls, because it resolves the well known name to
a unique name on creation, which means it will try
to talk to the old idle-exited instance.
The fix is to not use GDBusProxy, but instead manually
call g_dbus_connection_call_sync().
Fixes#1845Closes: #1873
Approved by: mwleeds
This adds the flatpak_transaction_add_install_flatpakref method
to easily install from flatpakref files. It additionally
adds a new signal called add-new-remote which is called in two
cases:
To ask if the user wants to add a "normal" remote for the url
specified by a flatpakref file.
When a new remote is required for the runtimes the application
depends on.
Closes: #1868
Approved by: alexlarsson
This will be used as the default when installing something that
doesn't specify a ref, such as a flatpakref file.
Closes: #1868
Approved by: alexlarsson
This is used to create the /var/lib/flatpak repo if
needed so that other later operations work. We have
some partial support for it not working in various
operations (using the allow_empty argument) but
this is in no way complete. For example, this
can easily happen if you have a per-user installation
but no system one and then you run flatpak install
with no --user, then it will try to figure out
which one to use and die.
In the case that the collection ID configured on a remote is NULL the
repo metadata comes from the summary file. But if there's an error
fetching the summary in _flatpak_dir_get_remote_state() and then
flatpak_remote_state_ensure_metadata() is called, the
metadata_fetch_error variable will be NULL and "unknown error" will be
returned as the error message. This commit returns the
summary_fetch_error message in that case so the user gets a slightly
more helpful error message.
Some Endless computers in Africa have recently been hitting this code
path and printing "unknown error" messages.
Closes: #1844
Approved by: alexlarsson
When the user runs with gid=X, but X doesn't have an entry in
/etc/groups, then a segmentation fault occured. This was happening
because flatpak-run.c didn't guard against a NULL pointer after calling
getgrgid() in flatpak_run_setup_base_argv.
Closes: #1850Closes: #1851
Approved by: alexlarsson
When allocating an instance id we create a unique directory
in $XDG_RUN_DIR/.flatpak/$id and create a .ref file in it which
we then read-lock (with F_SETLK). This lock is also taken by
the bwrap pid 1, so it will be taken for as long as the
app lives.
To clean up old is we remove any directories where we can successfully
write-lock the .ref file. As long as the sandbox lives this should
make it safe against removal.
However, there is a tiny race in the sandbox setup between the inital
O_CREAT of the .ref file and the F_SETLK fcntl. A GC at this point
may find the .ref file existing but not locked and then remove the
directory.
We work around this by only trying to lock .ref files that are more
than 3 seconds old.
Now that flatpak depends on ostree 2018.6 we don't need to check if we
have 2018.5. Remove the check and update a comment.
Closes: #1813
Approved by: alexlarsson
This allows us to resolve as many operations as possible in parallel
which is much faster than doing the p2p queries for each potential
update.
Fixes#1592Closes: #1796
Approved by: alexlarsson
This takes a list of refs + remotes and optional commit, all
which need to be p2p (i.e. have collection-id != NULL) refs, and
uses the p2p API to resolve the refs to the latest available commit
it and the matching metadata for that version.
It does this by doing a find_remotes() and then a pull_from_remotes
with PULL_FLAG_COMMIT_ONLY and then extracting the metadata
from the commit object.
We also do some checking before pulling so that if we have the latest
reported commit already available locally then we don't pull anything
for that ref (instead resolving to the locally available metadata).
We always pull to a child repo so that we have write-rights even as a
user (in the system case) and so we can properly clean up the temporary
results.
Note, this unconditionally uses the p2p APIs, and it relies on the latest
ostree master which has a fix that allows us to read the latest refs from
the transaction.
Closes: #1796
Approved by: alexlarsson
There is no need to force a fsync after pulling into the child repo,
because we will anyway copy/verify it into the system repo. It is
never used for stable storage.
This makes system installation faster.
Closes: #1808
Approved by: alexlarsson
This commit removes fetches of ostree-metadata from
flatpak_dir_install() and flatpak_dir_update(), which both pull it into
the child repo when doing system-helper deployments. Both functions have
a FlatpakRemoteState object passed in and when that is initialized,
_flatpak_dir_fetch_remote_state_metadata_branch() pulls and deploys
ostree-metadata so it can be queried against for repo metadata and
served onto LAN and USB peers. So there's no need to pull it again here.
The issue of resolving a ref and its metadata atomically remains, but
that will be addressed by https://github.com/flatpak/flatpak/pull/1796.
Closes: #1806
Approved by: alexlarsson
This changes the signals to use a FlatpakTransactionOperation
argument instead of a bunch of arguments in the signal, making
this easier to extend in the future.
This is an API break, but nobody is using this API yet, and it
was only available in one unstable release.
Closes: #1797
Approved by: alexlarsson
This signal is emitted after all the added operations and their dependencies
are resolved and we have the full list of things that will be
done as part of the transaction. At this point you can call
flatpak_transaction_get_operations() and decide if you want to
continue with the operation.
Closes: #1797
Approved by: alexlarsson
