This file lists the directories that are remapped in the sandbox,
allowing fontconfig to use the correct cache identifier for the
host-side caches.
As an example, this generates:
```
$ ./flatpak run --command=sh org.gnome.gedit
[📦 org.gnome.gedit flatpak]$ cat /run/host/font-dirs.xml
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<remap-dir as-path="/usr/share/fonts">/run/host/fonts</remap-dir>
<remap-dir as-path="/home/alex/.fonts">/run/host/user-fonts</remap-dir>
</fontconfig>
```
Closes: #2635
Approved by: alexlarsson
The spec allowed either timestamp or date to
be specified for a release, so we should support
both.
Closes: #2614Closes: #2619
Approved by: alexlarsson
This lets us export D-Bus service files for
names like org.foo.Bar.Application.Tracker.service
when the app-id is org.foo.Bar.
Closes: #2615Closes: #2616
Approved by: alexlarsson
If the user (erroneously) runs as root while modifying their user
installation, e.g. with "sudo flatpak --user install ...", this can
cause "permission denied" errors later on when they try to operate on
the installation as their own user. So refuse to execute a transaction
on a user-owned installation as root. Root can still operate on their
own per-user installation.
This approach does have a weakness: if flatpak is running as root when the user
installation is first created, it will be owned by root and therefore
avoid this check. I'm not sure what could be done about that.
Fixes https://github.com/flatpak/flatpak/issues/2565Closes: #2575
Approved by: alexlarsson
We want to move away from using dconf inside the sandbox,
and instead use the keyfile backend for GSettings, which
has gained the capability to read defaults and locks.
This change makes the dconf database contents and locks
available in a suitable format. The files appear inside
the sandbox in the /etc/glib-2.0/settings directory.
We only export the default values for keys in the dconf
subtree whose path matches the app id, as well as prefixes
listed in paths key from the X-DConf group in metadata.
This commit adds a new dependency, since we're now linking
against libdconf.
Closes: #2295
Approved by: alexlarsson
We no longer use it here. flatpak itself still links
against it. This avoids problems with consumers who
might also link against libappstream.
Closes: #2580
Approved by: alexlarsson
This function has libappstream-glib types in the
api, which we want to drop. And it is only used
in app/, so move it there.
Closes: #2580
Approved by: alexlarsson
Document the values returned by flatpak_installation_get_id()
and by flatpak_installation_get_display_name() for standard
installations.
Closes: #2583
Approved by: alexlarsson
Return non-NULL strings from flatpak_dir_get_id()
and flatpak_dir_get_display_name() for user installations,
to save library users the hassle of dealing with NULL
return values.
Closes: #2583
Approved by: alexlarsson
When we deploy e.g. app/org.foo.bar/x86_64/stable, then we
also create a deploy/app/org.foo.bar/x86_64/stable ref pointing to
the latest deployed commit. We also remove it when an app is uninstalled.
This means that a prune operation will not delete objects that are deployed
(which would not save any space anyway). This is nice because this can
happen for instance when you flatpak update --no-deploy.
Fixes https://github.com/flatpak/flatpak/issues/2085Closes: #2563
Approved by: alexlarsson
It's no longer true that it's the pull code's job to resolve a ref to a
specific commit. Ever since commit 66eee3c2c this is the job of the
resolve_ops() function used by FlatpakTransaction (at least, when a
transaction is being used). So update a couple comments to avoid
confusion.
Closes: #2587
Approved by: alexlarsson
It is possible for self->repo to be NULL, therefore
call flatpak_dir_ensure_repo() in a bunch more places,
before accessing self->repo.
Closes: #2483Closes: #2484
Approved by: matthiasclasen
This is a variant that allows to enter multiple numbers,
either individually, or as range. Parts can be separated
by space or comma. Examples:
1-3,5
1 2 4
6
Closes: #2559
Approved by: alexlarsson
In some cases, when NULL was passed for an OstreeProgress,
the library code would instantate its own progress object
and write progress information out to the console. That
is not a good thing for a library to do - it has the
potential to mess up the cli tools output.
Stop doing this, and require that all callers pass
a non-NULL progress.
Closes: #2468
Approved by: alexlarsson
Ostree just gives us a generic G_IO_ERROR_FAILED (boo!),
so we need to scrape the message to infer that this was
out-of-space. Translate this to an explicit error code
that we handle in the UI.
Closes: #2477
Approved by: alexlarsson
Move this typedef to flatpak-complete.h, where it
belongs. Also add a autoptr definition for it and use
it to avoid leaking the completion in flatpak-main.c.
Closes: #2534
Approved by: alexlarsson
FlatpakInstance was not dealing well with sandboxes
that don't have an application. In this case, the
metadata does not have an Application group, but
a Runtime group instead.
Closes: #2482
Approved by: matthiasclasen
'flatpak install sdk' offers me 34 choices, so double digits
seem very realistic here. Make the numbers line up in this
case.
Closes: #2476
Approved by: matthiasclasen
Avoid unnecessary complications from accepting installation
IDs which won't work well on the commandline or in filenames.
Closes: #2514
Approved by: mwleeds
When pulling the ostree-metadata branch for p2p remotes we passed
NULL for progress which caused it to report with the default console
progress, which doesn't make any sense for the (small) ostree-metadata
branch.
Closes: #2456
Approved by: alexlarsson
This is copying code from the unstall command that
was added for the --unused option, and makes it
available as a library api.
Closes: #1747Closes: #2444
Approved by: alexlarsson
Now that we're moving away from a pure ASCII esthetic,
it looks odd to me to have a mixture of 3 dots and
proper ellipsis, so switch everything over to use
U+2026 instead of 3 dots.
Some minor other formatting and string changes
are included here as well.
Closes: #2454
Approved by: alexlarsson
Use only the last section in the id for origin remotes, to avoid
the origin column being really wide when listing stuff.
Closes: #2448
Approved by: alexlarsson
Bubblewrap has a --chdir option to control the directory
that the command is run in. Add an argument for this to
the flatpak_run_app function, update all callers, and add
a --cwd option to flatpak run that uses this new argument.
Closes: #2443
Approved by: alexlarsson
We load the per-app appstream xml.gz during deploy and inject name,
summary and version from it into the deploy data. For older deploys
that don't have this data we re-create it when needed (with the hope
that updates to app eventually makes this unnecessary due to new deploys).
Additionally this removes the support for generating deploy files where
they don't exist, as support for this predates xdg-app 0.6, so should not
exist in real life.
Closes: #2409
Approved by: alexlarsson
This adds a version to the deply data format, assuming that if
there is no version then it is 0. Also extends all loaders so that
it can specify a required version, with the goal that most users
are fine with old versions, but if you need more recent we have
a (costly) conversion process to upgrade (will be added later).
The library and the flatpak list/info commands require the most
current version for full info, all other users can use any version.
Also, as part of this we now pass the ref to flatpak_load_deploy_data()
as this will be needed later for the backwards compat support.
Closes: #2409
Approved by: alexlarsson
