This looks better in case there are warnings or info messages printed
during the update operation, since those are separated from each other
by newlines (at least the EOL ones).
In the tests we don't use a systemwide helper anyway, so the polkit
stuff is unnecessary. Also, for some reason this was taking a very
long time for me, causing the tests to be super slow.
This makes it a lot easier to give guidance on using `flatpak run -d` or
`flatpak-coredumpctl`, because there's an easy way to install the
relevant refs.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
As discussed in #4848, this disables fuzzy matching entirely if stdin or
stdout is not a tty, meaning that something like "flatpak install
firefox" would be treated as incorrect syntax, since this syntax is
intended for interactive CLI use. Even before this commit, "flatpak
install firefox" would error out if run without a tty, since we don't
automatically choose a matching app ID even if there is only one match.
However "flatpak install -y firefox" could work before, but won't any
more. People should be specifying the full app ID in any context other
than a tty.
This commit also introduces a new env var so the unit tests can continue
to check the fuzzy matching behavior, despite them being run without a
tty.
As discussed in #4848, this disables fuzzy matching when the string
given has a period in it. So for example "flatpak install org.mozilla"
would not offer "org.mozilla.firefox" even though the string given is a
substring of the app ID. This is desirable because it helps ensure fuzzy
matching is only used when the user intended to use it.
As with the previous commit that fixed#4829, this does technically
break backwards compatibility, but only in an interface intended for
interactive use by a human, not an interface that's used
programmatically, so it seems okay.
The "*unspecified*" bits are ugly, and the ref/arch/branch syntax is
especially confusing when we're doing fuzzy matching, since it implies
the id was searched for exactly.
Currently if you specify one non-existent ref to the uninstall command,
it exits with a non-zero status:
$ flatpak uninstall notaflatpak
error: notaflatpak/*unspecified*/*unspecified* not installed
...but if you specify more than one non-existent ref you get warnings
for each and a zero exit status:
$ flatpak uninstall notaflatpak alsonot
Warning: notaflatpak is not installed
Warning: alsonot is not installed
So make the latter case error out like the former.
Recent Meson versions have warnings if you add the subprojects
directory as an include path, because the way Meson wants to consume
subprojects is by the subproject's build system producing a Meson
dependency object that encapsulates its include directory. Flatpak
doesn't have a Meson build system yet, but I'm working on that.
libglnx seems to be set up to have the libglnx directory be its include
path instead: for example, ostree (by the author of libglnx) already
uses "libglnx.h" or <libglnx.h> everywhere. Do the same here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently, when using the sideloading support for offline updates, there
are two types of directories that are interesting: an ostree repo
directory on a directory that was passed to `flatpak create-usb`. By
default the latter has a repo at the subpath ".ostree/repo", and if a
custom destination was specified with "--destination-repo", a symlink is
created pointing to it in ".ostree/repos.d".
Currently Flatpak supports either repos or create-usb dirs in the
`sideload-repos` directory in either the Flatpak installation or
`/run/flatpak` (see flatpak(1)), but only supports repo directories
being passed to "--sideload-repo" for the install and update commands.
This is pretty confusing and actually made me think the sideload support
was broken because I forgot about this limitation. So change things so
we can accept either type of directory specified either way: via option
or via the "sideload-repos" directories.
I've tested all of the following cases:
- pointing to a repo with --sideload-repo
- pointing to a create-usb dir with --sideload-repo
- linking to a repo in ~/.local/share/flatpak/sideload-repos
- linking to a create-usb dir in ~/.local/share/flatpak/sideload-repos
- pulling from a sideload repo when online as a performance improvement
If the user hasn't typed a '-', don't offer options in the tab
autocompletion. This is consistent with other linux commands, and less
messy.
Fixes https://github.com/flatpak/flatpak/issues/4753
In https://github.com/flatpak/flatpak/issues/4535 it was brough to light
that the search command strips the ".desktop" suffix from app IDs even
if they genuinely end in .desktop. This commit fixes the reverse issue
now that we've ported to libappstream: don't include the .desktop suffix
even if it's present in the id of the appstream component, which it
sometimes is.
Fortunately we already ignore any components that don't have flatpak
<bundle> elements, so we can unambiguously get the ID there.
Fixes#4535
Older versions of libappstream don't provide AS_CHECK_VERSION() so we
can't use that, and we need the check because as_component_get_branch()
is only in libappstream >= 0.14.0, and the return value of
as_metadata_parse_file() changed in 0.14.0
Since the port from libappstream-glib to libappstream, these wrappers
are trivially thin and can be dropped.
This commit introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
libappstream-glib is mostly unmaintained, and libappstream is more
actively developed (and up to date with the AppStream specification).
Port from libappstream-glib to libappstream. Handily, a lot of the APIs
are exactly the same. The main changes are:
* `AsApp` → `AsComponent`
* `AsStore` → `AsMetadata`
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(Mostly done by Philip, then Phaedrus finished this)
It is common for the build directory to be within a Git checkout.
Developers never want to check this directory into Git.
Make 'flatpak build-init', and hence 'flatpak-builder', create a blanket
.gitignore file inside this directory, so the containing checkout
doesn't need to predict the name of the build directory and ignore it.
(Inspired by Meson's treatment of its build directory.)
It is already the case that when we are using ALL_DIRS, we always
combine it with OPTIONAL_REPO, meaning no need to populate empty
installations. ALL_DIRS is used for commands that iterate through all
known installations to enumerate apps/runtimes, such as `flatpak run`
and `flatpak list`; for these commands, it's reasonable to say that
if the installation does not have a libostree repository, then that's
equivalent to it having a libostree repository with no apps and no
runtimes. Make this happen automatically if forgotten.
For STANDARD_DIRS, we were inconsistent about this: `flatpak remote-list`
had OPTIONAL_REPO, but the other commands did not.
STANDARD_DIRS is used for `flatpak create-usb`, and for all the commands
that manipulate remotes.
For the commands that manipulate remotes, it seems reasonable to say
that if an installation has no libostree repository and we are unable
to create one, then that's equivalent to an installation with a
libostree repository but no remotes.
Similarly, for create-usb, an installation where we are unable to create
a libostree repository seems like it should be equivalent to an
installation whose libostree repository does not contain any of the
refs we are interested in.
Resolves: https://github.com/flatpak/flatpak/issues/4111
Signed-off-by: Simon McVittie <smcv@collabora.com>
Commits that are found to have missing or invalid objects need to be
marked partial so that when the thing referencing them is reinstalled,
the missing objects will be pulled. libostree treats non-partial commits
as complete even if they're not, since verifying their completeness is
an expensive operation.
This exactly mirrors what the "ostree fsck" command does when it finds
corruption in a commit.
This fix is especially important because corrupt repos have been an
issue lately so we at least need repair to work properly.
Relatedly, delete invalid commit objects to ensure they are
re-downloaded, though it's not clear that code path is almost ever
reachable.
Fixes https://github.com/flatpak/flatpak/issues/4618
There's no need to use polkit in the history command, so don't start the
agent in flatpak-main.c. This means we can avoid a test failure in
test-history.sh which was caused by old versions of valgrind being
unaware of syscall sched_getattr, which is used in g_bus_get_sync(),
itself called by install_polkit_agent().
Currently we include entries in the output of the history command for
pulls of appstream refs, e.g. "appstream2/x86_64". However since they
don't have an application ID the Application column shows up blank and
it seems like a pull of nothing which is confusing. These are basically
an implementation detail like the temp repo pulls we already exclude, so
I think it makes sense to exclude them from the output.
It would also make sense to exclude pulls of ostree-metadata refs, but
for some reason I don't see those in practice, even with a collection ID
set on the remote.
The history command seems to have been broken since it was changed to
use FlatpakDecomposed, since that type only works for app or runtime
refs, resulting in errors such as:
$ flatpak history
error: appstream2/x86_64 is not application or runtime
Fix this by making the logic a bit smarter, and don't let any one
invalid ref entry prevent the whole command from working.
Fixes#4332
Have heard of people running Flatpak commands with both sudo and --user,
and not expecting it work on the root user's installation. Let's just
not allow it since it's not something people ever do intentionally.
The man page states that the --all option for the list command includes
runtime extensions (e.g. that end in .Locale or .Debug) and this is the
case. When --all is omitted, we only show such extensions when the thing
they extend is not already in the list. However when you run a command
like "flatpak list --runtime --columns=application,branch", you get a
list that excludes runtime locale extensions but includes app locale
extensions, since the corresponding apps are not in the list despite
presumably being installed. This doesn't seem like the right behavior,
so tweak the logic so that app locale extensions are excluded when --all
is omitted and --runtime is used.
Strictly speaking the "extension-of" information is not guaranteed to be
present in the deploy data (which acquires it from the metadata), but in
practice it seems to be present for all but Sources extensions, and I
think it should be considered required since we are already using it to
implement functionality elsewhere in Flatpak:
https://github.com/flatpak/flatpak/issues/4585
This fixes a few issues with the unit test logs that make them ugly:
1. Currently some lines of output from a command will appear after the
line from xtrace which has the next command, since the command was
printing to stdout and xtrace uses stderr. E.g. "Installation complete."
will appear after "+ flatpak --user install -y ..." but it is from the
previous install command.
2. Lines of output have many spaces after them to pad them to the table
width but this is not needed for non-fancy output.
3. Lines of output are mixed with output from httpd since they don't end
with a newline character, e.g. "Installing… ▊
4%127.0.0.1 - - [16/Nov/2021 00:18:24] "GET /..."
This is similar to what is done for desktop files and allows
applications to use a flatpak's metainfo to retrieve e.g. required
input controllers or the supported screen sizes. Similar to what can be
done for non-flatpak'ed apps by looking at
/usr/share/{metainfo,appdata}.
Since flatpak moves the metadata from metainfo/ to appdata/ during build
we only need to export files from that single directory.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Currently if the user specifies a ref to install that has been renamed
via the end-of-life-rebased mechanism, for example "flatpak install
com.visualstudio.code.oss", Flatpak erroneously tries to install both
the old and new versions of the app. This happens because the code
handling end-of-life-rebase conditions is written assuming the rebased
app is being updated rather than installed for the first time.
Specifically, in FlatpakCliTransaction and FlatpakQuietTransaction, in
end_of_lifed_with_rebase(), we treat a failure of
flatpak_transaction_add_uninstall() as fatal and return FALSE from the
signal handler, which means that the install operation that triggered
the signal will not be skipped (see the docs for
FlatpakTransaction::end-of-lifed-with-rebase).
So, instead check for the FLATPAK_ERROR_NOT_INSTALLED error code and
ignore it, so that the installation of the old version of the renamed
app will be properly cancelled.
Fixes https://github.com/flatpak/flatpak/issues/3754
