It is confusing if we explicitly have to specify
the <> GVariant wrapping with --data, but
flatpak permissions strips it when displaying the
result.
Make it transparent by auto-applying the wrapping,
so what you need to pass to --data is the same
as what flatpak permissions shows you.
Don't skip entries that have no permissions.
I was wasting some time to track down why my
permission-set --data command wasn't working,
when in reality, the permissions command was
just not listing the entries I was adding :(
An event happens more often as its frequency gets higher, so these
values were confusing me.
Rename the constants to include their unit (ms) as well, to avoid
confusion.
Anything that affects public API (such as
flatpak_transaction_progress_set_update_frequency()) or libostree's
options passed to ostree_repo_pull_with_options(), is left as is.
Show active and background state, based on information obtained
from the background portal backend about which apps have (active) windows.
This currently tries all known portal backends in turn. It might
be nicer to have a portal frontend api to query this, or to find
out which backend to talk to.
We were unconditionally adding the instance column,
which causes table headers to be off-by-one when
instance is not among the requested columns.
Change things to only add the instance column
when requested.
This uses the new bwrap feature via flatpak run --parent-expose-pids to
make new new sandbox pid namespace be a child of the callers sandbox.
Pretty obvious, the only weird thing is that we can't get the peer pid
directly from the caller (as it goes via the dbus proxy) so we have
to look that up from the instance data.
Given the pid of an existing flatpak process, if --parent-expose-pids is
specified, the new sandbox is run such that its processes are visible in
the specified sandbox.
In all other senses the two are disjoint though. The new sandbox is
still isolated from the host and the existing sandbox.
These are explicitly made short to save space, so lets have defines
for them to make sure we don't mistype them, especially as we
will be adding new keys.
There is no need to read the links, just look at the inode nr
which is the same info, and that also works on the bind-mounted
.userns thing where readlink fails.
Also, don't fail for non-existing namespaces.
Assuming unprivileged namespaces works we can now user the .userns
bindmount to access the intermediate bubblewrap user namespace.
This also drops the warning about root, and make sure we drop all caps
at the end.
Neither of these ever need a polkit agent, and run/build are somewhat
performance sensitive and we don't want to connect to dbus unnecessarily.
For enter this is critical though, as the dbus connection starts a thread
which is not compatible with the setns syscall.
Due to bug #3215 some systems have refs in refs/mirrors/ in addition to
the usual refs/remotes/ location. The remote refs are always at least as
new as the mirror ones since the repo_pull() invocation in
flatpak_dir_pull() which does not use OSTREE_PULL_FLAGS_MIRROR happened
after the one that did. Cleaning up these mirror refs is important since
otherwise when the remote ref is either updated or removed (by an
uninstall) disk space will be leaked since the mirror ref will point to
a no longer needed commit.
So, remove (almost) all mirror refs during flatpak repair, uninstall,
or update operations. And for the uninstall and update operations do it
in FlatpakDir so that it happens regardless of if the CLI of libflatpak
are used.
Also, add a unit test for this.
Fixes https://github.com/flatpak/flatpak/issues/3222
In commit 0772ab6c9 we changed "in preference of" to "in favor of" in an
informational message produced by FlatpakCliTransaction for clarity. Do
the same for FlatpakQuietTransaction.
Currently, if you run:
flatpak remote-ls flathub --app-runtime=com.endlessm.Platform//eos3.2
you see no apps (correct) but hundreds of runtimes. This is inconsistent
with the documentation for the '--app-runtime' option, which says:
> List applications that use the given runtime
To fix this, default to not showing runtimes if '--app-runtime' is
given. This is consistent with the behaviour if just '--app' is
specified. If you run 'flatpak list --app-runtime=com.example.Foo
--runtime' then you get apps using that runtime, plus all other
runtimes, which seems fair enough to me.
Accept the locale format as documented by `setlocale(3)`, rather than
another arbitrary format.
This reworks the validation code, and was tested to accept all the
locales on my F30 system using:
```
flatpak config --user --set extra-languages $(locale -a | tr -s '\n' ';' | head -c -1)
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to configure gnome-software to show specific apps in one region
without showing to all language speakers, we allow the storage of full
locales on the extra-languages key. However, these locales are ignored when
calling flatpak_installation_get_default_languages, so locales will be reduced
to their language identifier (eg. en_IN locale will be returned as 'en', and
az_Latn_AZ will be returned as 'az'). In order to get the full locales, we can
call flatpak_installation_get_default_locales instead, which can return languages
and locales.
