Adding generated files to foo_SOURCES causes them to be distributed,
even if that was not intended. Use nodist_foo_SOURCES instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There's no need for this file to be executable. If it was executed,
shells would typically try to execute it as a shell script (because it
isn't an ELF executable and doesn't start with #!), which isn't going
to work.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This ensures that when the operation to install the app completes, the
app is ready to run — rather than having to wait for subsequent
operations to install extensions which the app depends on (such as
content, or locales).
This fits in with the current ordering for *un*installing apps, where
the main app is uninstalled first, followed by its extensions.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/issues/3017
Files in the srcdir need to be explicitly prefixed as such in rule
commands. This fixes `make install` when installed-tests are enabled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than this weird shell loop with a timeout and polling we
move the httpd spawning entirely into the python code, and use
a pipe to synchronize the spawning. This way we can also use
the shell job control to properly clean up any running processes
from the test suite.
Additionally, this adds some (lame) support for token handling in the
test webserver, where you for any file foo can create a foo.need_token
containing a token that is needed for that file.
FlatpakTransaction inherently doesn't differentiate between a
autoupdate and a regular update; both are
FLATPAK_TRANSACTION_OPERATION_UPDATE.
This getter can help differentiate between a regular update
and autoupdate in clients like gnome-software. Autoupdates
work in two separate transaction passes; first that runs with
"no-deploy" and the second pass that deploys all the downloaded
update (i.e. with "no-pull").
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 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.
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 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
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
If xa.languages is set, use these, and no others. Otherwise, take the union
of xa.extra-languages, and the system default locales for system repos;
xa.extra-languages for user repo and the langs based on the user's locale
Fixes https://github.com/flatpak/flatpak/issues/3043
Currently if you have a remote configured with the URL
"https://dl.flathub.org/repo/" (as you would if you use the flatpakrepo
file) and you use a flatpakref file which specifies the URL
"https://dl.flathub.org/repo", Flatpak tries to add a duplicate remote
because it doesn't see those URLs as equal. So ignore the trailing slash
when comparing remote URLs. OSTree works equally well with both kinds
(it uses g_build_filename()).
Flathub served flatpakref files with URLs missing a trailing slash until
this commit:
https://github.com/flathub/ansible-playbook/commit/b20694f09
Also, add a unit test that fails without this patch.
Fixes https://github.com/flatpak/flatpak/issues/2979Closes: #3065
Approved by: alexlarsson
Currently the "test_remote()" test calls
flatpak_remote_set_gpg_verify (remote, FALSE) and disables GPG
verification on a remote while a collection ID is set on it, which
should not be possible. The remote-add command enforces that GPG
verification is used if a collection ID is set, but the library API does
not. This commit changes libflatpak to return an error when such an
invalidly configured remote is being committed to disk. Also, update the
unit test to check for the newly added error, and to unset the
collection ID before disabling GPG verification.
Later in the unit test, GPG verification is re-enabled on the remote,
but libflatpak erroneously sets gpg-verify-summary=true in addition to
gpg-verify=true (summary verification is supposed to be disabled when
collections are used, but the library doesn't notice the mistake since a
collection ID isn't set in the same transaction and was already set).
This fix addresses both issues.
Closes: #3095
Approved by: alexlarsson
Currently if you delete a remote when it still has installed apps (using
--force), you're then unable to uninstall those orphaned apps (or
runtimes). This commit makes the uninstall operation succeed despite the
missing remote. Since we don't need a FlatpakRemoteState for an
uninstall operation, just avoid calling flatpak_ensure_remote_state().
Also, do some refactoring in flatpak_transaction_real_run() that should
improve readability and allows us to add a g_return_val_if_fail() in the
helper function, which ensures that only uninstall operations are
allowed to not have remote state.
This also includes a unit test for uninstalling with a missing remote.
Fixes https://github.com/flatpak/flatpak/issues/1982Closes: #3067
Approved by: alexlarsson
The org.freedesktop.Flatpak user D-Bus service isn't just used by
flatpak(1) or applications running as Flatpaks. It's also used by
toolbox(1) for similar reasons:
* To keep various configuration files inside the container
synchronized with the host
* To let the container request certain commands to be run on the host
The org.freedesktop.Flatpak D-Bus service itself doesn't need much in
the way of dependencies, but inherits a lot of unused shared library
linkages through the libflatpak-common.la convenience library. Removing
these unused shared libraries reduces the footprint of toolbox(1) for
those who care about such things. eg., Fedora CoreOS.
This commit brings down the number of shared libraries to 19 from 62.
Closes: #3052
Approved by: alexlarsson
Unfortunately in commit 253fcc6e3 I broke the build-bundle command so
that it is unable to resolve remote refs (as opposed to local ones).
This means in the normal case of building a bundle for an app installed
from a remote it fails:
$ flatpak build-bundle /var/lib/flatpak/repo gnome-calculator.flatpak org.gnome.Calculator stable
error: Refspec 'app/org.gnome.Calculator/x86_64/stable' not found
This is because flatpak_repo_resolve_rev() interprets a NULL remote name
to mean the ref is local (in refs/heads/) but in this case we just don't
know which remote it's from. This commit fixes the issue by using
ostree_repo_resolve_rev() directly which searches refs/heads/ and
refs/remotes/, and if that fails falling back to iterating over refs
returned by ostree_repo_list_collection_refs() to catch collection-refs
that may be in refs/mirrors/.
Also, add a unit test that fails without this patch.
Fixes https://github.com/flatpak/flatpak/issues/3026Closes: #3032
Approved by: alexlarsson
This sets FLATPAK_FANCY_OUTPUT=0 in most tests and then special cases
the test_fancy_output() test in case the installable tests are running
on an actual tty. This was causing failures because the added bold escapes
caused some test cases to not generate the expected output.
Closes: #2907
Approved by: alexlarsson
This is basically modify_remote, but it fails if the remote is
already configured instead of modifying it. Although it also
has a if_needed option, and if that is set it will silently complete
as a no-op (exept resetting filters).
Closes: #2888
Approved by: alexlarsson
