flatpak build-update-repo now lets you modify the
autenticator-name/install/options keys, and these are migrated to
the summary/metadata during update.
When we call flatpak_dir_update_remote_configuration we pass it
the pre-existing FlatpakRemoteState (if known) and also take into
account if it actually changed anything before blowing away the
cached remote state.
We also ensure we have metadata in
flatpak_dir_update_remote_configuration_for_state to ensure the passed
in optional state has metadata in it.
This warning is meant for interactive use, and as per #3316 it often
breaks non-interactive stuff like scripts. So, we only warn on ttys,
and only on normally interactive operations like run, install and update
to avoid warnings in cases like building (where XDG_DATA_DIRS is not
needed) or information gathering things like e.g. flatpak info.
It often happens that people use --user or --system or --installation
and get a "Remote not found" error message, because they don't
understand that remotes have to be defined separately in each
installation. Make the error message more helpful by pointing out when
one of those options was used.
Fixes https://github.com/flatpak/flatpak/issues/3296
This is a g_autoptr version of OstreeAsyncProgress that also
calls ostree_async_progress_finish() before being freed.
This should be used in all "leaf" functions that creates an asyncprogress
to avoid leaking any idle change idle sources. Using a auto* means
some code can be cleaned up to avoid goto out style handling for this.
Also, this adds a missing finish() in
_flatpak_dir_fetch_remote_state_metadata_branch().
This is a slightly incompatible change, as we now only support
oci images generated with (what was before) build-export --oci-use-labels.
However, there are not a lot of OCI implementations in the wild, and
we can modify the ones in use to ensure there are labels (and
annotations if needed for older flatpak clients).
This also removes the --oci-use-label option from build-bundle --oci as
this is now the default.
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.
