This means use x11 if no alternative is present, and should be used
for applications that support both X11 and wayland, but want to be
sandboxed when running under a wayland compositor (but still want to
run under an X server).
Closes: #1416
Approved by: alexlarsson
When copying a commit, also bring forward any static deltas.
This is particularly interesting for flathub where we can
then generate static deltas on the build machines and then import
and sign it on the repo machine.
Closes: #1409
Approved by: alexlarsson
Updating the appstream data on every invocation of the search command
involves a lot of overhead, so instead only update it if it's at least a
day out of date. This is consistent with how tools like dnf work.
Closes: #1352
Approved by: alexlarsson
We no longer run appstream-builder (see commit 455d3a7b2) so update the
documentation for the --update-appstream option.
Closes: #1360
Approved by: alexlarsson
If the remote is a local path (absolute or relative starting with ./)
then we convert this to a file: uri, which are now supported to
install directly from a local repo.
This is very useful when testing locally built apps.
Closes: #1244
Approved by: alexlarsson
This lets you add overrides that affect all applications. Application
overrides have higher priority so will override the global overrides.
Closes: #1245
Approved by: alexlarsson
Currently "flatpak remotes" shows remotes across user and system
installations, but other remote commands (remote-delete, remote-modify,
remote-ls, remote-info) only work on one installation: the system one
unless overridden using --user or --installation. This commit changes
each command to infer the correct installation by checking which has
the specified remote. In case multiple installations have remotes by
the same name, the user is prompted to decide which to use.
This commit also adds unit tests and updates the man pages for the
aforementioned commands.
Fixes https://github.com/flatpak/flatpak/issues/787Closes: #1205
Approved by: alexlarsson
The "flatpak remote-ls" command can be used without specifying a remote,
so change the man page and --help output to reflect that.
Closes: #1210
Approved by: alexlarsson
The other commands that support --user and --system allow you to specify
an installation using --installation, so this makes search consistent
with that.
Closes: #1185
Approved by: TingPing
This shows information about a ref in a remote. Of particular interest
is the --log option which gives you a history which can be used
with update --commit=XXX to roll back an update.
Closes: #1174
Approved by: alexlarsson
This makes /app (or other destinations) read-only, which will be
later used by flatpak-builder when running tests, that should not
affect the build.
Closes: #1172
Approved by: alexlarsson
Some of these are grammatical errors, and some are mistakes caused by
copying phrases from the flatpak-install manpage.
Closes: #1177
Approved by: alexlarsson
The manpage description for flatpak-update's --appstream option says it
updates appstream data for the remote, but it's unclear that the remote
should be passed on the command line instead of a ref. This commit
updates the manpage to document that form of the command.
Closes: #1177
Approved by: alexlarsson
* Update appstream data on "flatpak update"
This is especially useful since we now have flatpak search which uses
this data.
* fixup! Update appstream data on "flatpak update"
* build-finish: Add --extension-priority option
This lets you set the priority of the extension.
* fixup! build-finish: Add --extension-priority option
* fixup! build-finish: Add --extension-priority option
This is useful for Flatpak runtime and app authors who want to know
which features they can use when targeting a particular branch,
or if they do not have a particular branch in mind, what value they
should put in the required-flatpak field.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We no longer use bwrap --die-with-parent by default, because it has
problems due to the semantics of PR_SET_PDEATHSIG. In particular, it
will kill bwrap as soon as *any* thread in the parent exits, not just
the main one.
This caused weird problems in gnome-builder, as seen in:
https://bugzilla.gnome.org/show_bug.cgi?id=783950#c14
It should be safe to use this from single-threaded apps though,
so flatpak-builder can still use it. It just has to explicitly
enable it.
This takes a list of properties and generate finish arguments.
Additionally you can specify "bundle": true, which causes f-b to emit
an actual extension implementation, similar to e.g. the locale
and debuginfo extension.
This makes sure we always delete build dirs, even if there
was a build failure. This is useful for automatic build systems
like flathub or continuous integration.
This fixes https://github.com/flatpak/flatpak/issues/646
In order to provide a transition path for repositories to add collection
IDs to themselves and propagate those collection IDs to clients’ remote
configurations, add another repo config key which controls whether the
repository’s collection ID is published. If xa.collection-id is set in
the repo’s published metadata, the client will update its configuration
to the given ID — but only if no ID is set already. This is a one-time
transition to prevent malicious repositories from remotely changing the
user’s configuration to associate their remote with a well-known
collection ID they don’t own.
Add a test for this.
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>
In order to eliminate some race conditions around updating the
summary{,.sig} file on the server, and to decouple signing the summary
from signing commits, and to support peer to peer mirrors of content
from multiple upstream collections: add support for unsigned summary
files.
This relaxes the requirement for gpg-verify-summary=true iff
collection-id is set in a remote’s local configuration. It depends on
some pending libostree changes to verify the ref for each commit using
the commit’s signed metadata. See
https://github.com/ostreedev/ostree/issues/983.
Metadata storage has moved from the summary file to a new
ostree-metadata well-known branch on each repository, since this can be
signed for each update and for each collection separately. If the
collection-id is set in a remote’s local configuration, flatpak will
retrieve all repository metadata from this branch rather than from the
summary file. If collection-id is unset, it will ignore this branch and
continue to use the summary file, which will continue to be updated (and
externally signed as summary.sig) for backwards compatibility.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Pass a --collection-id argument through to `flatpak build-export`.
Also add a ‘collection-id’ property to manifest files, which can be used
to set the collection ID on an exported repo (when using --repo) without
having to provide a command line option.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows you to automatically install/update dependencies required
by the manifest. The dependencies include:
Runtime, Sdk, Base, Sdk Extensions and Platform Extensions
There is also a --install-deps-only switch to make the build
stop after the dependencies are installed.
Fixes https://github.com/flatpak/flatpak/issues/955
