This runs the app in a very tight sandbox, with no access to anything
except /app and /run and some read-only host things like fonts and icons.
You can additionally add explicit permissions on the commandline,
like --share=network to actually grant some access.
This also sets $FLATPAK_SANDBOX_DIR to ~/.var/app/$appid/sandbox in the
environment.
So, if you run your instance with e.g. flatpak run --filesystem=/some/dir
you can now see this. This will be useful in the restart yourself
portal as we can then inherit such permissions.
When uninstalling, if no specific installation was specified with e.g.
--user or --system, automatically chose any unique match, or error
out if there are multiple alternatives.
Fixes#1321
We currently auto-pick installation for update when you didn't pick
any specific one, so we should complete from all of them too.
Closes: #1537
Approved by: mwleeds
The remote-ls command should skip remotes that have "xa.disable" set to
true or have no URL set, which can happen for remotes added for flatpak
bundle files.
Fixes https://github.com/flatpak/flatpak/issues/1427Closes: #1457
Approved by: alexlarsson
If the --show-details option is passed to the remotes command, show the
collection ID for each remote, which the user might need to know if
they're using flatpak's P2P support.
Closes: #1458
Approved by: alexlarsson
This isn't needed for servers and starting the a11y bus on a
fresh session bus takes upwards of 15 seconds.
Fixes#1471Closes: #1486
Approved by: alexlarsson
Currently the search command only searches remotes for apps and runtimes
that match the host architecture. This commit makes flatpak include all
supported architectures so for example you can see a 32-bit app on a
64-bit computer.
Fixes https://github.com/flatpak/flatpak/issues/1353Closes: #1430
Approved by: alexlarsson
On atomic, /home is a symlink to /var/home, which caused
problems in flatpak build when granting access to the homedir.
Due to a previous workaround (in 1aadc3ee40) we
make /var in the flatpak build sandbox be completely overridden
with $builddir/var so that the above symlink would not cause problems
in the persisted directory.
However, when we actually *want* to give access to that symlink this
causes problem.
In general, exposing /var in the sandbox has two uses:
* Allowing persisting tmpfiles in /var/tmp between individual
flatpak build commands (/tmp is per-build-command).
* Creating flatpaks from packages, such as rpms, where
we want to keep the rpm database (/var/lib/rpm) around during
the entire build so that dependencies can be resolved.
In order to handle these /var/home issues while still allowing
the above issues we instead persist only /var/tmp and /var/lib.
Fixes https://github.com/flatpak/flatpak/issues/1407Closes: #1421
Approved by: alexlarsson
When copying a commit, also bring forward any static deltas.
This is particularly interesting for flathub where we can
then generate static deltas on the build machines and then import
and sign it on the repo machine.
Closes: #1409
Approved by: alexlarsson
This fixes build-export so that it doesn't try to use uninitialized
memory in a timestamp object when creating appstream data. Before the
--timestamp option existed, a timestamp of 0 was used, so fall back to
that. Also, update a relevant comment.
Closes: #1408
Approved by: alexlarsson
For the "flatpak update" it makes sense to print a message when updating
the appstream data for each remote, but it makes less sense for the
search command, because it's output should just be the table of results.
Closes: #1352
Approved by: alexlarsson
Updating the appstream data on every invocation of the search command
involves a lot of overhead, so instead only update it if it's at least a
day out of date. This is consistent with how tools like dnf work.
Closes: #1352
Approved by: alexlarsson
This commit changes the search command to update appstream data from
each remote before searching it for the specified text. This way
users don't need to know to run "flatpak update --appstream".
Fixes https://github.com/flatpak/flatpak/issues/1339Closes: #1352
Approved by: alexlarsson
All flatpaks built using version 0.9.4 or newer should have the
xa.metadata field in the commit metadata, so warn if it doesn't exist.
This commit changes the info command to print a warning rather than
nothing and changes the info-remote command to print a warning rather
than error out.
Closes: #1351
Approved by: alexlarsson
If flatpak is compiled with P2P support and the commit in question has a
collection ID in its metadata, show it.
Closes: #1351
Approved by: alexlarsson
This is now in xdg-desktop-portal. We keep a version of the document
portal dbus XML so that we avoid weird build dependencies.
Flatpak itself is technically not dependent on the document portal,
but it is very much recommended that you use it.
Closes: #1398
Approved by: alexlarsson
When the specified remote existed, but had no updates we printed
a message like: error: Remote "flathub" not found
Closes: #1363
Approved by: alexlarsson
If flatpak is compiled with P2P support and the commit in question has a
collection ID in its metadata, show it.
Closes: #1312
Approved by: alexlarsson
When the --show-metadata option is used with remote-info, the metadata
variable is never initialized, causing flatpak to print "(null)". This
commit makes sure the variable is properly initialized so the metadata
prints correctly.
Closes: #1313
Approved by: alexlarsson
When a remote is found in multiple installations and we ask "Which do
you want to use (0 to abort)?", the 0 choice isn't working because the
min value in the call to flatpak_number_prompt() was set to 1. Fix that
so the user can abort if they want.
Fixes https://github.com/flatpak/flatpak/issues/1305
The error wasn’t being propagated properly, leading to a NULL pointer
dereference.
Coverity CID: 1463075
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1267
Approved by: alexlarsson
If the remote is a local path (absolute or relative starting with ./)
then we convert this to a file: uri, which are now supported to
install directly from a local repo.
This is very useful when testing locally built apps.
Closes: #1244
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 is a no-op on regular (archive) repos, but on bare repos it is
an optimization if the source is a checkout from the repo. This
happens in flatpak-builder (https://github.com/flatpak/flatpak-builder/pull/81)
when it commits the build to the cache during --install without --repo.
Closes: #1249
Approved by: alexlarsson
Now that flatpak update does both per-user and systemwide
per default it makes a lot of sense to say which one is being
updated.
Closes: #1248
Approved by: alexlarsson
