confirm_runtime_removal() doesn't know about autoprune-unless
extensions, so it prompts unnecessarily when they're removed by
`flatpak uninstall --unused`. To avoid this, we can simply skip it and
trust flatpak_dir_list_unused_refs().
Closes#5712
Helps #2718
Static libraries do not carry information about their dependencies.
Thus, libflatpak_dep must include all of the dependencies for
libraries to link against libflatpak. To do this, I've repurposed the
libflatpak_common_deps variable, which previously was either empty or
contained only wayland_client, and was then included into the list of
dependencies for libflatpak-common, to be a list of all dependencies
required to both build libflatpak-common, and link against it (or
libflatpak).
This fixes building Flatpak with -Ddefault_library=static. gtkdoc
must currently be disabled due to a Meson bug I'm working on[1].
[1]: https://github.com/mesonbuild/meson/pull/14257
And add the FLATPAK_TTY_PROGRESS env var to re-enable it.
This seems to only be supported by recent versions of terminal emulators
which will cause problems with shipping Flatpak on older distros.
Closes https://github.com/flatpak/flatpak/issues/6052
The ostree and Flatpak APIs both refer to "end of life", but
this internal #define (though not the data stored in the cache)
refer to "end of line".
Fix this.
This is a new warning. Reproducible on F41
Fixes:
../common/flatpak-installation.c:1963: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:1858: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2129: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2014: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:1732: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2177: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2220: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
../common/flatpak-installation.c:2608: Warning: Flatpak: invalid closure annotation: only valid on callback parameters
Signed-off-by: Hubert Figuière <hub@figuiere.net>
Instead of hardcoding /var/tmp when temporarily downloading layer
tarballs, support overriding with a FLATPAK_DOWNLOAD_TMPDIR
environment variable.
We don't use TMPDIR because the layer tarballs can be very big
(in extreme cases like an SDK > 1GB), and TMPDIR is more
likely to point to a in-memory tmpfs.
Now that we read remotes from $datadir/flatpaks/remotes.d as well as
/etc/flatpaks/remotes.d, we should have a mechanism to redirect this, as
we do for almost all other filesystem path locations.
To avoid an explosion of new variables, we introduce FLATPAK_DATA_DIR to
represent configuration that ships with the operating system.
This is useful:
- To fix sandboxing of tests
- When installing using flatpak into a chroot, so that we read
the chroot's configuration rather than the host.
It also is used when reading triggers, but the current
FLATPAK_TRIGGERSDIR is left for compatibility.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Following on systemd adopting the progress OSC that ConEmu and Windows
Terminal use, this exports the progress percentage to the terminal
emulator.
VTE also has support for this in the upcoming 0.80 release and is used
by Ptyxis to display progress in the tab widget.
As described in #5614, `WAYLAND_SOCKET` provides a single-use socket
as a file descriptor, which some Wayland compositors use to track
special-purpose Wayland clients like input methods and panels.
Since #5615, there are two cases for how it works:
1. With `--nosocket=inherit-wayland-socket` (default): the file
descriptor is marked close-on-exec so that the sandboxed app does
not inherit it, and the `WAYLAND_SOCKET` environment variable
becomes unset. Every time the sandboxed app connects to Wayland,
because `WAYLAND_SOCKET` is unset, it will fall back to the ordinary,
public `WAYLAND_DISPLAY`.
2. With `--socket=inherit-wayland-socket`: the file descriptor is
allowed to be inherited, and the environment variable continues
to be set. The first time the sandboxed app connects to Wayland,
it will connect to the `WAYLAND_SOCKET`. The second and subsequent
connection attempts will be to the ordinary `WAYLAND_DISPLAY`.
However, when #4920 added a code path for the Wayland security-context-v1
interface, it was implemented as a completely separate code path which
early-returned from flatpak_run_add_wayland_args() before the point
where #5615 subsequently added the implementation for (1.). The practical
result of this is that if the compositor sets `WAYLAND_SOCKET` for
a Flatpak app, and it also happens to implement security-context-v1,
then the application will always inherit the `WAYLAND_SOCKET` as though
`--socket=inherit-wayland-socket` had been used. In this case, the app's
first connection to Wayland will use the `WAYLAND_SOCKET` (bypassing
the security context mechanism), the same as in compositors that do not
implement security-context-v1 at all, and only the second and subsequent
connections will use the special per-app `WAYLAND_DISPLAY` created by the
security context mechanism. This seems likely to be unexpected.
To give maintainers and users a choice between behaviours (1.) and (2.),
we can put the security-context-v1 code path through the same code to
handle `WAYLAND_SOCKET` that is used for Wayland compositors that do not
implement that interface. This means that
`--nosocket=inherit-wayland-socket` disables `WAYLAND_SOCKET` in all
cases: if the compositor supports security-context-v1 and the feature
was also available when Flatpak was compiled, then all of the sandboxed
app's Wayland connections will be to the per-app `WAYLAND_DISPLAY`
created by security-context-v1, and otherwise all of the sandboxed app's
Wayland connections will be to the ordinary, public `WAYLAND_DISPLAY`.
With `--socket=inherit-wayland-socket`, the sandboxed app's
first connection to Wayland will continue to be to the inherited
`WAYLAND_SOCKET` fd, and the second and subsequent connections will
be to the `WAYLAND_DISPLAY`, which might either be the special per-app
version created by security-context-v1, or the ordinary public version.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In the older code path where we were not using Wayland security contexts,
we would try to preserve the name of the Wayland display socket
(`$WAYLAND_DISPLAY`), only falling back to `wayland-0` if the name was
something unconventional (contains `/` or does not start with `wayland-`).
This means that in practice, apps could often successfully use a value
of `$WAYLAND_DISPLAY` from the wrong "world" - for example reading the
value used outside the sandbox from a file in code that runs inside the
sandbox, or conversely, passing the value used inside the sandbox via
IPC to a service like gpg-agent outside the sandbox.
However, the implementation in
flatpak_run_add_wayland_security_context_args() did not do this, and
instead would unconditionally use `wayland-0`. There's no real need to
enforce use of that name.
Apps should not really be passing the string value of `WAYLAND_DISPLAY`
across a sandbox boundary, but in practice some do, and we will get
better interoperability if we try to keep that working in at least the
simple cases. This is similar in spirit to how we have handled X11
since 2022 (flatpak/flatpak#5034).
For now, we skip the last few lines of flatpak_run_add_wayland_args() if
we are using Wayland security contexts, to preserve existing
functionality. A subsequent commit will revisit that.
Resolves: https://github.com/flatpak/flatpak/issues/5863
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a slight generalization of the reproducer contributed by Will
Thompson: as well as exercising the case where the parent is a dangling
symlink (reproducing GNOME/libglnx#1), this also exercises the case where
the parent is a non-directory non-symlink (in this case a regular file).
Reproduces: GNOME/libglnx#1
Co-authored-by: Will Thompson <wjt@endlessos.org>
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we try to create `link/content` where `link` is a dangling symlink,
recursing to create `link` will succeed (mkdirat fails with EEXIST,
which is explicitly ignored), but then mkdirat for `link/content` will
still fail. Fail gracefully instead of crashing out with an assertion
failure.
Resolves: GNOME/libglnx#1
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise it could potentially race with tests in other executables that
also want to create `./test`, or interfere with other test-cases in the
same executable that expect `./test` to be nonexistent or empty.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Meson 1.1.0 officially deprecates string defaults for boolean options,
but boolean defaults worked in many older Meson versions, going back to
at least 0.49.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Without this, "as-installed" tests via `ginsttest-runner` will fail,
for example in Debian's autopkgtest framework.
Fixes: 1d56bd37 "context: Implement device lists for usb"
Signed-off-by: Simon McVittie <smcv@debian.org>
