If the command calling `flatpak build` has already specified a
font-dirs.xml to map, then mapping in again may break (as exemplified in
Builder and Foundry).
This checks to see if an argument has already been mapped in before doing
so and resolves the issue with Builder/Foundry.
Follow-up to !6138Fixes: GNOME/gnome-builder#2387
(cherry picked from commit c896faae19)
There are a number of races, and failure conditions which can lead to a
pid of 0 being returned from flatpak_instance_get_child_pid. This would
lead to a whole bunch of things getting killed.
We will skip the instance in those cases now, and retry a few times. We
also notice when the instance just goes away by itself now.
This should make killing more robust, and especially not SIGKILL pid 0.
(cherry picked from commit 8354ee56cf)
Sudo can be used in several ways other than calling a command with the
root user. For example, one can use -u to run the command as the
specified user, or -g to specify a primary group to run the command
as.
Flatpak adds a check when --user is used to prevent an installation in
the root's directory, for example, but it does it by only checking if
sudo was used. As stated previously, it does not necessarily imply
root, so this patch explicitly checks if the command is being run with
the root user.
Fixes: https://github.com/flatpak/flatpak/issues/5979
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit f61d931da8)
flatpak run writes /run/host/font-dirs.xml, but flatpak build so far
didn't. This resulted in fontconfig writing:
Fontconfig error: Cannot load config file "/run/host/font-dirs.xml": No such file: /run/host/font-dirs.xml
to the stderr of all processes utilizing fontconfig and run during
flatpak build, as /run/host/font-dirs.xml is included via
/etc/fonts/50-flatpak.conf. This could cause issues for tests run during
building an application, for example.
Closes#6137
(cherry picked from commit 054f4f4a7b)
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
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.
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.
We add the component name as part of the fallback search.
Before this patch, queries as
flatpak search Element
or
flatpak search d-spy
return no results even though the search term coincides with the
application name.
For historical reasons g_qsort_with_data() "only" works with up to 2**31
items, so it won't necessarily work for pathologically large arrays
and therefore is deprecated.
One advantage of g_qsort_with_data() and its replacement g_sort_array()
is that GLib guarantees that they are a stable sort (will not permute
items that already compare equal), which is not a guarantee for glibc's
qsort() and qsort_r(). However, I don't think it's actually relevant
whether we are doing a stable sort in any of these places: most of the
time we are sorting an array of unique items (often the keys of a hash
table, which are necessarily unique), therefore the compare function
will not compare equal in any case.
Another advantage of the GLib functions is that they are portable,
unlike qsort_r(). However, Flatpak is Linux-only, so we can freely use
useful functions like qsort_r().
Signed-off-by: Simon McVittie <smcv@collabora.com>
KDE krunner supports DBus plugins that allow search completion
comparable to the already supported gnome-shell searchprovider.
Exporting the contents of the runner directory enables us to enable
search results from within flatpack applications.
Commit f268f4a870 that changed
flatpak_resolve_matching_remotes() to automatically pick the remote if
it's the only matching one, missed an opportunity to clean up the rest
of the function.
Now that `remote_dir_pairs->len == 1` is handled as a first case, we can
drop the old, dead code that handled it differently, and simplify the
nested conditionals.
This can be used to disable code paths that assemble relatively
"expensive" debug information when debugging is not enabled.
It's activated by `flatpak -v -v`.
With a sufficiently modern GLib version, it also activates for
`G_MESSAGES_DEBUG=all` or `G_MESSAGES_DEBUG=flatpak`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This further reduces circular dependencies: utils no longer has a
circular dependency with repo-utils or xml-utils.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a step towards removing the libostree dependency from
flatpak-utils, which should be one of the lowest-level components.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This breaks the circular dependency between flatpak-utils and flatpak-dir.
There is still a circular dependency between flatpak-dir and
flatpak-dir-utils, but I don't want to make flatpak-dir even larger.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This seems like an obvious set of functionality to be grouped together
in service of the wider goal of making flatpak-utils smaller and more
manageable.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This ensures that the command is not taken to be a bwrap option.
Resolves: CVE-2024-32462
Resolves: GHSA-phv6-cpc2-2fgj
Signed-off-by: Alexander Larsson <alexl@redhat.com>
[smcv: Fix DISABLE_SANDBOXED_TRIGGERS code path]
[smcv: Make flatpak_run_maybe_start_dbus_proxy() more obviously correct]
Signed-off-by: Simon McVittie <smcv@collabora.com>
The transaction ops are a g_autolist(FlatpakTransactionOperation) which
means the list gets freed automatically. Calling g_list_free_full
without clearing the variable to NULL results in a double-free.
Closes: https://github.com/flatpak/flatpak/issues/5763
Fixes: 6e3cc82a ("Fix memory leaks")
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
As discussed in #5695, I think we're reaching a point where removing
Autotools is preferable to fixing it.
1.14.x continues to use Autotools, so platforms whose Meson version is
too old can stay on that branch until it becomes unsupported. We have
a very conservative Meson dependency (Ubuntu 20.04).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This allows g_autoptr destructors to run, avoiding memory leaks being
reported by AddressSanitizer; they would be harmless, since we're about
to exit anyway, but AddressSanitizer can't tell the difference between
an O(n) problem and an O(1) harmless "leak".
Signed-off-by: Simon McVittie <smcv@collabora.com>
Flatpak looks for extensions in all installations, but `flatpak info -e`
would display an error when an extension isn't present in the same
installation as the ref.
Also display the installation name for each extension.
In order to maintain a system over time update automatically removes any EOL runtimes that are unused.
This extends it to also remove any autopruned refs. In practice this means removing no longer used driver versions as the system is updated.
Closes#5261
Unlike the instance directory, whose directory structure is
considered public API and is mounted in the sandbox, the private
instance directory is meant to hold private data or metadata about
an instance for use by internal components.
The private instance directory is not meant to be shared with any
external component, and provides no guarantees about its structure
or contents.
While the public instance directory is named "<instance-id>", the
private instance directory is named "<instance-id>-private". Both the
public and private instance directories share the same parent
directory.
The private instance directory relies on the same lock file as the
public instance directory, and both are garbage-collected together.
Use architecture instead of id in call to
flatpak_dir_load_appstream_store ().
Without this, remote-info does not show AppStream metadata.
Fixes: adb3b61f "decomposed: Return FlatpakDecomposed from flatpak_dir_find_remote_ref()"
Our only code that is conditional on the libappstream version wants
version 0.14.0, which conveniently is exactly the version that
introduced AS_CHECK_VERSION.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These functions are to do with being an interactive, terminal-oriented
CLI/TUI, so it would be inappropriate for library code in libflatpak
to call them, and it would also be inappropriate for daemons like the
session and system helpers to call them.
In fact all calls to these were already isolated to app/, so we can
easily move the terminal-related utilities themselves into app/.
As well as shrinking libflatpak, this makes it obvious that the system
helper does not actually need to call flatpak_disable_fancy_output():
it does not link any code that would be affected by that API call.
Signed-off-by: Simon McVittie <smcv@collabora.com>
