Since we switched to libappstream we really have an implicit dependency
on this, as there are no versions of it building with glib earlier
than 2.46.
This isn't dropping a lot of old code, but at least it is more truthful
about our actual dependencies.
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 adds support for being used as a Meson subproject, and fixes some
minor bugs and compiler warnings.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The systemd-userdbd service was added in systemd 245, which was
released in March 2020 and is available in RHEL 9. Therefore, it's
safe to assume that the systemd_userdbd_stream_connect() SELinux
interface is also available on all relevant operating systems, unless
there's reason to believe otherwise.
https://bugzilla.redhat.com/show_bug.cgi?id=2071217
Of the 19 instances where g_mkdir_with_parents() is used, these are
the only ones where the return value is ignored. This triggers
Coverity.
It might not be strictly necessary to handle the errors, but doing so
can only help with debugging.
Of the 16 instances where g_file_delete() is used, these are the only
ones where the return value is ignored. This triggers Coverity.
It might not be strictly necessary to handle the errors, but doing so
can only help with debugging.
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>
We support the "summary-arches" variable to limit which arches goes
into the compat summary file. However, its currently always adding in
the compat arches of whatever arches you list. This means we can't
e.g. keep compat summary support for aarch64, but not for armv7, which
is a problem as we're nearing the 10MB summary size limit of ostree
for old clients.
So, just keep the exact arches listed. If you want to keep compat
arches, you need to explicitly list them.
This lets us verify that our ability to do releases hasn't regressed.
Run this as part of the "valgrind" build, since we want to enable
gtk-doc for distcheck, and it's this build that already enables gtk-doc.
We don't want to do this in the main Autotools build, since
that enables AddressSanitizer, which often works badly with the
"scanner" tools in gtk-doc and GObject-Introspection - although this
is currently mitigated by --enable-asan not actually working as
intended (see #4844).
Signed-off-by: Simon McVittie <smcv@collabora.com>
For the build that uses --enable-asan, explicitly disable introspection,
since the GObject-Introspection scanner works poorly with libtool
and AddressSanitizer (see #4844); the only reason this worked until
now is that --enable-asan doesn't currently do anything (again,
see #4844).
For the build that runs tests under valgrind, we already can't use
AddressSanitizer, making this a good place to explicitly enable
introspection, so that we have at least one build with it enabled.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We want to have gtk-doc enabled in the build that will run
`make distcheck`, but the clang/CodeQL build seems like a poor fit for
that, since it runs twice (for C and Python) and has extra
instrumentation. Move it to the build where we will run tests under
valgrind, which is already somewhat slow.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We explicitly enable gtk-doc for one of our builds (the one that uses
clang on Ubuntu 18.04). There's no real need to enable it for more than
one build.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Meson's TAP parser is more strict than the one in Automake, and will
not accept and ignore arbitrary output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Meson's TAP parser won't accept this, unlike Automake's. At the moment
libtest.sh directs stderr to stdout anyway, so there is no practical
effect for this change, but a subsequent commit will remove that merging.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids polluting stdout with the output of the launched app,
which would corrupt the test's TAP output. With Autotools, we get away
with it, because Automake's TAP parser is permissive, but Meson's TAP
parser is more strict.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
