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
If this is passed, we add an extra collection id binding to
the commit, as well as create a separate ref for that particular
collection id.
This weakly depends on:
https://github.com/ostreedev/ostree/pull/1805
In that without that change ostree pull will not respect
multiple collection-id bindings. It will still work for
the main/first collection id though.
Closes: #2634
Approved by: alexlarsson
Avoid linking to the same fd.o spec just linked to a few lines above,
and rearrange things to be more readable.
Closes: #2606
Approved by: matthiasclasen
We may not want to guarantee all the formats that this
datetime parser accepts, but NOW seems useful enough and
is already mentioned in flatpak-build-commit-from(1).
Closes: #2498
Approved by: matthiasclasen
Add a rule to generate a single-file html version of the
libflatpak api reference, for integration into readthedocs.
This is pretty plain, but serves the purpose.
Closes: #2526
Approved by: matthiasclasen
This more closely matches the recently changed --help output for these
options, and distinguishes them from the options that only print some
information and exit.
Closes: #2537
Approved by: matthiasclasen
Make it clear that flatpak(1) only lists global options,
and individual commands have their own.
Add a reference to flatpak-installation(5)
Closes: #2513
Approved by: mwleeds
Add a flatpak-spawn(1) man page. While it is not ideal
to have the docs live separately from the code, having
it here ensures that it will be available everywhere
all the other flatpak documentation is.
Closes: #2437
Approved by: alexlarsson
We ran into some issues on flathub where a build with very large
files caused the parallel delta generation to use a lot of paging,
essentially blocking progress. This option can at least allow you
to make progress in that case, although we should ideally have
a better solution.
Closes: #2416
Approved by: alexlarsson
Capitalize Flatpak in text, add a paragraph about building
that references flatpak-builder, and add a reference to
www.flatpak.org.
Closes: #2410
Approved by: alexlarsson
Rename permission-list and document-list to
permissions and documents, for consistency with
how we handle remotes. The old command names
are kept as hidden aliases.
Closes: #2131Closes: #2366
Approved by: mwleeds
Make it clear that the command can be used a few different ways, and the
option used determines the needed positional arguments.
Closes: #2361
Approved by: matthiasclasen
This adds support for fuzzy matching ref names (AKA "typo helper") to
the uninstall command to mirror what the install command has. In short,
this means you can do "flatpak uninstall gedit" instead of "flatpak
uninstall org.gnome.gedit". Flatpak will prompt you to choose between
similarly named installed refs, and will only make the choice for you if
--assumeyes was used and there's only one match.
Note that this commit does have the side effect that if there are
multiple matching refs with the same ID (e.g. with different branches or
in different installations) you are prompted to choose between them.
Previously you were shown an error message.
Closes: #2330
Approved by: matthiasclasen
This commit adds a key called DeployCollectionID to the flatpakref and
flatpakrepo file formats, which is intended to replace the CollectionID
key (which is still supported but deprecated). The reason for the change
is the same as for the metadata key change from xa.collection-id to
ostree.deploy-collection-id, which is that old versions of Flatpak
(roughly 0.9.8 through 1.0.1 depending on compile time options) hit
various bugs when collection IDs are in use. Flathub will soon enable
the metadata key to deploy collection IDs, and this change means Flathub
can also deploy the collection ID in flatpakref and flatpakrepo files
without affecting old clients.
Adding DeployCollectionID to the flatpakref and flatpakrepo files will
mean the flathub remote can be automatically configured with a
collection ID without depending on the metadata key to do that.
Closes: #2329
Approved by: alexlarsson
Make synopses more concise in various place, improve
consistency of formatting, and fix some small mistakes
and oversights.
Closes: #2307
Approved by: matthiasclasen
A convenience wrapper around ostree_repo_get_min_free_space_bytes().
Clients programs like gnome-software can get the value of minimum free
space as defined in the OSTree repo. This can be useful in various
disk-space checks these client program can implement.
At Endless, we have downstream heuristics in gnome-software which
determine the success/failure likelihood of an install/update
operation to some extend. Depending upon the likelihood of the
success/failure we dispatch install/update/auto-update operations.
With client programs gaining features such as auto-updates, it makes
sense to have a min-free-space API so that these programs can check
free-space availablity vs minimum free space defined by user inside
OSTree's repo before auto-updating. Although, OSTree will certainly
fail operations over-stepping min-free-space's value; It's just a
matter of convenience to provide a way to query the value to client
programs as well.
Closes: #2274
Approved by: matthiasclasen
Currently the install command requires the user to specify the remote
name in addition to each ref that is to be installed. This commit
implements an auto-detection feature so that the user can specify only
refs (or partial refs) and Flatpak will try to determine the remote to
use.
The Flatpak security model does not consider all remotes equally
trustworthy, but that's okay because the user is asked to confirm the
remote choice before it's used.
The way it's implemented is that we look at only the first ref (even if
there are several) and iterate through each remote in each installation
trying to find it, stopping at the first one where it's found and asking
for confirmation of it. There's a trade-off here between efficiency and
accuracy, since it could be pretty costly to search every remote in
every installation. I think this should be good enough for most use
cases, and the user is still free to specify a remote and avoid that
code path.
This should hopefully save people a bit of typing and make the Flatpak
CLI a bit friendlier.
Closes: #2113
Approved by: matthiasclasen
This commit implements a "typo helper" for the install command, so that
if you don't get the app ID exactly correct you're prompted with
similarly named apps available in the remote that you can choose from.
Essentially this allows you to do "flatpak install flathub devhelp"
instead of "flatpak install flathub org.gnome.Devhelp".
The choice is only made for you in two cases: 1. If it's an exact match
and there's only one match, it is used as before this commit. 2. If the
-y/--assume-yes option was used and there's only one match, it is used.
Presumably scripts would always specify the full app ID, so this should
only affect users on the command line who choose to use that option.
In the future we may want to use the groundwork laid in this commit to
add similar functionality to other commands, like perhaps remote-info
and run.
This is a partial fix for https://github.com/flatpak/flatpak/issues/1258Closes: #2113
Approved by: matthiasclasen
Avoid the 3-second 'afterlife' of instances by using
kill (pid, 0) instead of checking the file lock. We
trade pid for lock races, but this seems more reliable.
Also add flatpak_installation_launch_full that returns
a FlatpakInstance for the launched app, and lets us
avoid races around killing the app, by using a child
watch.
Closes: #2221
Approved by: matthiasclasen
