Since flatpak_export_paths_export_context and flatpak_exports_from_context
are now in flatpak-context.c we make them begin with flatpak_context_
Closes: #1374
Approved by: alexlarsson
We had missing icons for a few apps due to this - if this ever happens
it means something very weird is going on with the export process in
a flatpak, so it's probably worth alerting the repo admin.
Closes: #1367
Approved by: pwithnall
The appstream spec suggests that IDs should end in .desktop, but does
not require it. Make the repo appstream update process permit this
so that the appstream and icons are extracted correctly.
Closes: #1367
Approved by: pwithnall
When loading data from e.g. an installed app we ignore any permissions
it requests that we don't know about, rather than failing. This allows
us to later add permissions in an optional way. If the added permissions
are not optional you can use the flatpak-version key to request a specific
flatpak version that supports them.
Closes: #1362
Approved by: alexlarsson
oci_pull_init_progress() seems to set all the default keys wanted by
ostree_repo_pull_default_console_progress_changed() except the
caught-error key, which was added in OSTree commit 5c4f26bd65b492.
Add that key, just in case something queries for it (if it’s missing
when that happens, an assertion failure will be hit).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1320
Approved by: cgwalters
When building with --disable-p2p, we create a stub type for
OstreeRepoFinderResult and OstreeRepoFinderResultv to avoid having to
add #ifdefs around all uses of them throughout the code base. We also
need to create autoptr functions for them so that the code can continue
to use g_autoptr(OstreeRepoFinderResult).
Previously, we were using `void` as the GDestroyNotify function for the
stub types. This wasn’t valid (it’s not a function), but it worked.
Since g_autolist() support has landed in GLib, this has broken. Fix it
by using a static inline no-op function as the GDestroyNotify function
instead. This should never be called, so exists purely to get things to
compile.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/issues/1279Closes: #1293
Approved by: mwleeds
Interestingly the telegram appid is "org.telegram.desktop", which means
the wrapper ends up having a .desktop extension which confuses the
desktop file exporter. We fix this by rewriting any exports before
creating the wrappers.
Fixes https://github.com/flathub/org.telegram.desktop/issues/18Closes: #1270
Approved by: alexlarsson
Emit a warning about them rather than ignoring them entirely.
Coverity CID: 1376554
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1267
Approved by: alexlarsson
Some of these were leaking entire file contents, or the whole of
xa.metadata.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1259
Approved by: mwleeds
This creates a $flatpakdir/exports/bin directory that contains wrappers
for all active installed applications, named by the application id.
If you add these directories to you $PATH, then this means you can more
easily launch flatpak apps on the commandline.
Closes: #1254
Approved by: alexlarsson
It doesn't really make sense for a runtime to export anything, so
lets just enforce that. Note, this is not necessary a security
issue, because anything exported from runtimes were rewritten
just like apps. It just enforces the expected behaviour of
runtimes.
Closes: #1254
Approved by: alexlarsson
If you're installing something and its already installed, we undeploy
the old install first before deploying the new. This makes it very
easy to switch an application from one remote to another, without
having to uninstall first, which is both painful and could cause
the download to be unnecessary large.
Closes: #1241
Approved by: alexlarsson
This lets you add overrides that affect all applications. Application
overrides have higher priority so will override the global overrides.
Closes: #1245
Approved by: alexlarsson
This means that if you e.g. do
flatpak run --filesystem=home --nofilesystem=~/foo
Then /.flatpak-info will contain:
filesystems=home;!~/foo
This also makes overrides with --nofilesystem work,
fixing https://github.com/flatpak/flatpak/issues/1232Closes: #1245
Approved by: alexlarsson
Currently --nofilesystem just means that we undo a similar --filesystem,
so --filesystem=~/foo/bar --nofilesystem=~/foo/bar means we can access foo.
If you did --filesystem=~/foo --nofilesystem=~/foo/bar then the later
would have no effect.
We now handle this by giving access to foo, but hiding bar beneath it.
Closes: #1245
Approved by: alexlarsson
We regressed on supporting --filesystem=xdg-config/kdeglobals:ro which
would create a "kdeglobals" in the apps own XDG_CONFIG_DIR which has
content from the host one. This broke in
f1df5cb1d9
where we added a symlink resolve, but that breaks when the target file
doesn't exist.
It seems like all callers rely on just the final element of the destination
path being created, so lets just resolve symlinks on the dir part.
Closes: #1229
Approved by: alexlarsson
This means flatpak can bootstrap itself from an empty /var on stateless
systems, which fixes https://github.com/flatpak/flatpak/issues/113, at
least for the CLI case.
Closes: #1195
Approved by: alexlarsson
This tries to ensure that FlatpakDir->repo is set, but if the
repo doesn't exists and we're unable to create it that is fine
and we continue running with repo == NULL.
This is useful because there are only a few operations that really
are useful/make sense with no repo set up, and we can ensure these
handle this well.
In particular, we want to allow flatpak remote-add using the
system-helper to work even if /var/lib/flatpak doesn't exist, so that
we can bootstrap a working flathub from a fresh /var.
Closes: #1195
Approved by: alexlarsson
Some apps, such as gnome-builder wants to access data from the
host, for instance in builders case the system includes. If you
have full filesystem access it is not really a loss of security
to also have /ect and /usr access, but for technical reasons
we can't expose them in the normal locations. However, we
can expose them in /run/host, so do that.
Closes: #1193
Approved by: alexlarsson
This shows information about a ref in a remote. Of particular interest
is the --log option which gives you a history which can be used
with update --commit=XXX to roll back an update.
Closes: #1174
Approved by: alexlarsson
