This means that the remote is there, but disabled.
This is needed for e.g. bundles without origin url, and when bundles
starting using this codepath this regressed like in:
https://github.com/flatpak/flatpak/issues/314
For a long time we have been disallowing "-" in application names,
which is different than what dbus allows for bus names. Also "-" used
to be not allowed by GApplication in glib. This is in part because
dbus object paths do *not* allow dashes, so you can't legally map
from e.g. a valid name like "org.foo-bar.gazonk" to a valid path
like "/org/foo-bar/gazonk".
This is a problem because many existing apps already use "-" in the
name, either as the last part (org.gnome.font-viewer) or because
the dns name it refers to has a dash.
This was recently discussed in the dbus community, and the result
is to recommend that "-" in the bus names be converted to "_" in object
paths.
This change makes it also allowed to have "-" in a flatpak app id.
For flatpak specifically we were relying on "-" not being allowed to
handle the case of exporting "org.foo.App-symbolic.png". If "-" is
allowed this name can conflict between apps called "org.foo.App-symbolic"
and "org.foo.App".
To handle this we add two special cases:
* App ids can't end with "-symbolic".
* Apps are allowed to export files with $appid-symbolic as prefix.
Commit 352e761c0e started the trend
to print the errno error code when unable to open a file, make all
occurrences where files are opened print the same kind of message.
These are similar to .flatpakrepo, but for a single app.
For example, if you have a file gedit.flatpakref with this:
[Flatpak Ref]
Title=GEdit
Name=org.gnome.gedit
Branch=stable
Url=http://sdk.gnome.org/repo-apps/
IsRuntime=False
GPGKey=mQENBFUUCGcBCAC/K9WeV4xCaKr3NKRqPXeY5mpaXAJyasLqCtrDx92WUgbu0voWrhohNAKpqizod2dvzc/XTxm3rHyIxmNfdhz1gaGhynU75Qw4aJVcly2eghTIl++gfDtOvrOZo/VuAq30f32dMIgHQdRwEpgCwz7WyjpqZYltPAEcCNL4MTChAfiHJeeiQ5ibystNBW8W6Ymf7sO4m4g5+/aOxI54oCOzD9TwBAe+yXcJJWtc2rAhMCjtyPJzxd0ZVXqIzCe1xRvJ6Rq7YCiMbiM2DQFWXKnmYQbj4TGNMnwNdAajCdrcBWEMSbzq7EzuThIJRd8Ky4BkEe1St6tuqwFaMZz+F9eXABEBAAG0KEdub21lIFNESyAzLjE2IDxnbm9tZS1vcy1saXN0QGdub21lLm9yZz6JATgEEwECACIFAlUUCGcCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEArkz6VV0VKBa5cH/0vXa31YgEjNk78gGFXqnQxdD1WYA87OYxDi189l4lA802EFTF4wCBuZyDOqdd5BhS3Ab0cR778DmZXRUP2gwe+1zTJypU2JMnDpkwJ4NK1VP6/tE4SAPrznBtmb76BKaWBqUfZ9Wq1zg3ugvqkZB/Exq+usypIOwQVp1KL58TrjBRda0HvRctzkNhr0qYAtkfLFe0GvksBp4vBm8uGwAx7fw/HbhIjQ9pekTwvB+5GwDPO/tSip/1bQfCS+XJB8Ffa04HYPLGedalnWBrwhYY+G/kn5Zh9L/AC8xeLwTJTHM212rBjPa9CWs9C6a57MSaeGIEHLC1hEyiJJ15w8jmY=
You can then install gedit with
flatpak install --from gedit.flatpakref
This is no longer needed, as we don't hard-require systemd --user.
We keep the opion there, but hidden in order to be backwards compatible
with old code that used this.
This has two advantages. First of all (and most important) it
lets us put a /.flatpak-info file in it, so that the dbus peers
it talks to have the right "source" app id and sandboxed status.
Secondly, it lets us run the bus with readonly access to things,
thus being somewhat more secure.
The info file is always standalone, as it never needs to stack on top
of another context. This means we can remove all "negative" attributes
such as "shared=!network", making it easier to parse this file.
The old location keeps working because we create a symlink.
The interesting part of this is that the sandbox now can't modify,
remove or replace the file, and it is in a fixed position. This means
that given a sandboxed pid, we can find this file as
"/proc/$pid/root/.flatpak-info".
This is very nice for two reasons:
* We can use this instead of the cgroup to find out if a pid is
sandboxed or not. This means we can drop the dependency on
systemd --user for this.
* We can get more information about the peer process that the
app id. For instance, we can see what permissions the sandboxed
app has.
This lets any client, possibly in a sandbox if it has access to the
session helper, spawn a process on the host, outside any sandbox.
Clearly this is not something you typically want a sandboxed app to
do. However, it is sometimes very useful when using flatpak mainly
for distribution. For instance, an IDE needs to use this to launch a
flatpak build operation inside the sandbox. (Because otherwise recursive
calls to flatpak will not work.)
This enables support for ptrace and perf for the app, similar
to what run -d manually gave you before. This is nice to be
able to package an app like gnome-software.
If there are multiple refs pointing to the same revision, then
collecting the size and metadata info for each of them is wasteful.
Maintain a hash table of the data so that it's only collected once per
revision.
This slightly widens an existing race where a ref could be updated
before the summary file is regenerated. In that case, the data in the
xa.cache variant would correspond to the wrong revision. I don't believe
this can be fixed unless there's locking at the ostree level.
If there are non-flatpak refs in the ostree repo, there's no use in
collecting size or metadata information for them. Instead, only operate
on refs in the appstream, app or runtime prefixes.
If flatpak is built from a separate build directory, code generation
fails because the directory structure is not in place. Create the
necessary directories before code generation.
