This will allow the same script to be used to generate
Makefile-test-matrix.am.inc and its Meson equivalent.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The Meson build files that I'm working on enable more compiler warnings
by default than Autotools does, and in particular -Wmissing-declarations
complains about global functions that are not predeclared. There's no
need for this one to be global.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with commit de9fe1cb "common: Work around new glib codegen
autogenerating g_autoptr support", this avoids colliding with newer
versions of gdbus-codegen generating their own autocleanups. This is
helpful when using Meson, in which the gdbus-codegen integration
generates more autocleanups by default.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When we add a Meson build system, we will need to add a meson.build in the
subdirectories that were ignored by these rules. Ignore individual files
instead of entire subdirectories.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It's clearly quite important to have read access to /var/lib/flatpak
and it's contents. This explicitly permits that to avoid running
into SELinux denials.
https://bugzilla.redhat.com/show_bug.cgi?id=2070741
Typo correction has nothing to do with --no-pull or --no-deploy so it
doesn't make sense to test them together when we already test each
separately.
[smcv: Resolve conflict with #4858]
The system-helper (ie., the `flatpak-system-helper` process) is
labelled with flatpak_helper_exec_t and runs in the flatpak_helper_t
domain, and needs to be able to read /etc/passwd. This explicitly
permits it to do so to avoid running into SELinux denials.
https://bugzilla.redhat.com/show_bug.cgi?id=2070350
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.
If we're using a system copy of xdg-dbus-proxy, it's not really correct
to include a header from our subproject (which we are otherwise not
going to be compiling), and Meson is stricter about this than Autotools.
Instead, duplicate the FlatpakPolicy enum, which is the only part we
actually need.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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
Having this patch here rather than in x-d-p means we don't have to carry
downstream changes to the file in x-d-p.
This commit also makes the validator error out if the icon is not
square, since it's simpler to parse one number, and in practice all
icons are square.
The subpath is resolved relative to the root of the commit, so we can
use either an absolute or a relative path interchangeably. When using
libostree < 2021.6 with GLib >= 2.71, absolute paths cause an assertion
failure here; that was a libostree bug and was fixed in 2021.6, but we
can interoperate with more versions by sticking to relative paths, and
there's no real reason to prefer absolute.
Resolves: https://github.com/flatpak/flatpak/issues/4805
Co-authored-by: Corentin Noël <corentin.noel@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is specifically for running build-time tests in the Autotools build
system, and is not used when running installed-tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
* Add `--add-seccomp` (prerequisite for flatpak/flatpak#4462)
* Add a warning when repeated options are ignored
* Add a Meson build system
* Invoke bash via `PATH`
* Exit early when `argc == 0`
Signed-off-by: Simon McVittie <smcv@collabora.com>
* Improve compatibility with eCryptFS (related to #4673)
* Improve compatibility with copying pseudo-files from /proc
* Add a flag to skip fchown() in glnx_file_copy_at()
* Add a rewinddir() wrapper to GLnxDirFdIterator
* Rename its generated config header to libglnx-config.h
* Fix a potential double-free while manipulating xattrs
* Use REUSE for copyright/licensing statements
Note that after merging this in an existing checkout, it will be
necessary to re-run autogen.sh.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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 some OS configurations, unprivileged users cannot read back messages
that they have written to the system log. This test cannot succeed if that
happens, so skip it.
In particular, if the Journal is only in-memory rather than persisted
to disk (as it was by default in Debian 10), then there are no per-user
Journal files, only a single system-wide Journal which requires privileges
to read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 8b05f6b3 "Add a unit test for the history command"
All the details of the bug are in:
https://github.com/ostreedev/ostree/pull/2549https://github.com/flatpak/flatpak/issues/3479
This patch works around it by marking the commit we're about to pull
partial, so that if the .commit object exists in a staging directory
from a previous failed pull, it will not be erroneously considered a
complete commit, even by affected versions of libostree that don't have
the above patch. If for some reason the commit in the staging dir is
complete, libostree should harmlessly verify that and pull it in.
Usually the commit we are pulling does not already exist in the local
repo, but add a check anyway so we don't risk marking a complete commit
as partial, and so this works on the code path from
"flatpak install --reinstall ..."
Fixes#3479
