Make flatpak_dir_system_helper_call capable of dealing with a GUnixFDList
parameter and subsequently call g_dbus_connection_call_with_unix_fd_list_sync
for those methods.
Closes: #2657
Approved by: alexlarsson
The demo starts two instances by the same users so
the revoke doesn't really enforce any separation, but
it demos how you would do it.
Closes: #2657
Approved by: alexlarsson
By default we just spawn a writer from the fuse implementation,
but you can also do it manually with --backend and --socket,
allowing you to start the two in different contexts.
Closes: #2657
Approved by: alexlarsson
Currently when the user doesn't specify a branch to the run command, for
apps it will use the current branch and for runtimes it just tries to
use "master" and fails if that doesn't work. Since runtimes don't have
current branches, it would be nice if we could determine the right one
to use rather than just erroring out. So this commit changes the
implementation so that it looks at each installed runtime and if only
one matches it is used. If there's more than one match the user is
prompted to choose. This is the first interactivity added to the run
command but I don't think that's an issue; any time it's run in a
non-interactive shell it will error out upon encountering ambiguity.
Also, add a couple unit tests for the success path and error paths.
Fixes https://github.com/flatpak/flatpak/issues/2780Closes: #2788
Approved by: matthiasclasen
This commit makes it so that a unit test can create the test app and
runtime using a branch other than master, and changes test-run.sh to use
the branch "stable". This will allow the run command to be tested better
in the following commit.
Closes: #2788
Approved by: matthiasclasen
This script doesn't work anymore and it's not clear that it's worth
maintaining since no one seems to be using it.
Closes: #2788
Approved by: matthiasclasen
Calling this variable disable_interaction doesn't make sense because
there's still interaction if there's more than one option, so rename it
to assume_yes.
Closes: #2788
Approved by: matthiasclasen
For compatibility with libappstream we create a $origin ("flatpak")
subdirectory with symlinks to the size directories thus matching the
standard merged appstream layout if we assume the appstream has
origin=flatpak, which flatpak-builder creates.
See https://github.com/ximion/appstream/pull/224 for details.
Fixes https://github.com/flatpak/flatpak/pull/2779Closes: #2789
Approved by: alexlarsson
Currently a FlatpakTransaction object only operates on one installation,
but uses others (by default the system installations) for dependencies
such as runtimes. In addition to checking those dependency installations
for runtimes we check their configured remotes when deciding whether to
add a new remote as an origin for a flatpakref or as a runtime remote
for a flatpakref. This commit changes the behavior so that we only check
the installation being operated on to find out if a remote already
exists. This is the correct behavior in both cases: the origin remote
and the runtime remote. Otherwise the installation can error out when it
fails to find the runtime, or it can fail to respect the
SuggestRemoteName key which is supposed to dictate the name for the
origin remote.
One side effect of this is that a remote might be duplicated in the user
installation which already exists in the system installation, even if
the runtime it provides is already installed. But if you don't want
remotes in multiple installations you can just stick to using one
installation consistently.
Also, add a unit test for this in testlibrary.c (which required a bit of
refactoring).
Fixes https://github.com/flatpak/flatpak/issues/2758Closes: #2761
Approved by: alexlarsson
On the next lines after this prompt we list each remote so it doesn't
make much sense to mention the first one in the prompt.
Closes: #2761
Approved by: alexlarsson
The size is just a number, but the resulting GdkPixbuf could still be
quite big compared to the amount of data we're processing, so keep
4096x4096 as maximum dimensions.
Closes: #2747
Approved by: alexlarsson
Rather than creating a real temp directory and
then commiting that we generate an in-memory mtree
which mostly refers to pre-existing icon file
objects, and then the newly created appdata xml.
Closes: #2753
Approved by: alexlarsson
The gnome-apps repo is not being kept up to date so we don't want to
imply that people should use it, and make a few other tweaks to the
install command examples.
Closes: #2743
Approved by: matthiasclasen
It makes more sense to have this in flatpak_create_soup_session() so
every caller of that interprets the env var.
Closes: #2740
Approved by: matthiasclasen
Currently Flatpak has a few different implementations of helper
functions to download a URI using libsoup, but the best one seems to be
in common/flatpak-utils-http.c. So this commit deletes the others and
makes use of flatpak_load_http_uri() in place of download_uri() in a
few places. This has a couple consequences:
1) It means that we're now properly checking HTTP status codes rather
than assuming that the request was successful, in the install command,
remote-add command, and in FlatpakTransaction. This fixes an assertion
failure seen by a user when they tried to use a flatpakref URL that hit
a 404.
2) It means that in the places where we're using flatpak_load_http_uri()
we are only supporting http:// and https:// URLs not, say, file:// ones.
For the install and remote-add commands this was already being enforced.
For the handling of flatpakref files and bundles in FlatpakTransaction,
I believe it's just convention because it doesn't make much sense to
do anything else; this commit enforces that convention.
Also, add a unit test for the case of trying to install a flatpakref at
a URL that hits a 404 error.
Fixes https://github.com/flatpak/flatpak/issues/2727Closes: #2740
Approved by: matthiasclasen
Commit b20ee7e26 introduced a bug where flatpak_load_deploy_data()
returns NULL without setting @error in the case that there's a problem
reading the deploy file. I think this is causing a seg fault in
flatpak_installation_list_installed_refs() which tries to print the
error message after calling get_ref() (which indirectly loads the deploy
file).
I didn't personally verify that this fixes the GNOME Builder seg fault
that was reported, but it seems almost certain looking at the provided
stack trace, since get_ref() only returns NULL if
flatpak_dir_get_deploy_data() returns NULL, and that function clearly
sets the error pointer on failure except in flatpak_load_deploy_data().
I'm not sure why the deploy file doesn't exist (or is unreadable) for
the user who reported this seg fault.
Fixes https://github.com/flatpak/flatpak/issues/2717Closes: #2733
Approved by: matthiasclasen
