It turns out the underlying call ostree_repo_query_object_storage_size
doesn't work for staged objects, so we work around this by actually
loading the object, walking back to the original unix input stream
and fstat:ing the fd from that.
I just saw a confusing error messages that looked like two error
messages just running into each other. Better to end the first
one with a colon when using g_prefix_error.
The underlying setters interpret NULL as 'unset this key', but
we never pass NULL. Since empty strings are not useful values
for title or default-branch or redirect-url, just interpret
an explicit empty value as 'unset this key'. E.g. to unset
the redirect url, use
flatpak build-update-repo --redirect-url= ~/my-repo/
When clients install/update they will see this property in the
(signed) summary and update the url in the config, making this
essentially a permanent redirect.
We download the summary and send it to the system helper, it verifies
the checksum and applies the changes, with the same polkit permissions
required as for an app update (i.e. typically none).
This allows us to update metadata automatically, without permission
requests.
Whenever you explicitly specify some value (e.g. for
title or default-branch) we set a $KEY-is-set option
to True, and if that is set we never automatically update it.
Differentiate between the 'extension point' (definition of
a place where extensions can be mounted) and the 'extension'
(a runtime matching an extension point).
I was seeing this when trying to run flatpak's tests in ostree's CI:
https://github.com/ostreedev/ostree/pull/824
The race here is that the python process can still be writing to the output
while sed is reading it, and hence we'll find a difference on the next line.
Fix this by making a tmp copy of the file, which then both sed and cmp will
read consistently.
I'm not *entirely* sure this will fix the problem as I couldn't easily reproduce
the race locally, but I believe it at least fixes *a* race.
The system-cache (summaries and temporary repos for downloads) are moved
from ~/.local/share/flatpak/system-cache to
~/.cache/flatpak/system-cache (or wherever XDG_CACHE_HOME is) because
this is the proper location for caches.
Fixes https://github.com/flatpak/flatpak/issues/767
This ensures that no processes from the build lives
past the return of the build itself, which might
accidentally happen.
We still allow apps to stay around after the regular
flatpak run command finished though, as this is sometimes
done on purpose.
If the app explicitly grants access to the host /tmp (for
instance telegram) then when this is being exposed as a symlink
in the sandbox we get an error because /tmp already exists
as a dir, which we create very early on.
It doesn't really make sense to keep /tmp as a symlink in
the sandbox anyway, so we just special case this and mount
the symlink target as /tmp.
