In general xa.filter being "" means don't filter, so that it can be
used to override-unset a previous filter. However, We canonicalize
to unset/NULL when comparing, returing, or setting the ostree config.
Closes: #2884
Approved by: alexlarsson
This kind of remotes don't work very well, because they are not modifiable
or removable and can cause conflicts with pre-existing remotes.
We instead want to switch to a way to define default remotes that
is applied to the regular ostree repo config, allowing later changes.
Closes: #2884
Approved by: alexlarsson
This is in preparation for writing some unit tests
for these functions. Apparently they are not too
trivial to get them wrong.
Closes: #2880
Approved by: alexlarsson
This is kind of special as it handles non-existing filter keys
as "override to no filters" instead of "leave existing filters" whic
we do for other things. However, that matches how we want to use
.flatpakrepo files to override site-local filters.
Closes: #2869
Approved by: alexlarsson
If there is a filter for the remote, include the checksum of it
in the directory name for the deploy dir. This way we re-deploy the
appstream if the filter changes.
Closes: #2869
Approved by: alexlarsson
This means only refs that are allowed will be visible in the deployed
appstream.
This sometimes means we have to uncompress the xml.gz before rewriting
and then re-compressing that.
As a result of this we now always end up with both the compressed and
the uncompressed xml file, whereas we before didn't get an uncompressed
one if the remote was using the old appstream format.
Closes: #2869
Approved by: alexlarsson
Full names are:
* flatpak_remote_state_lookup_ref()
* flatpak_dir_list_all_remote_refs()
This should be enough to not get any stray refs, because due to the
complexities of p2p all accesses go via FlatpakRemoteState.
The one leftover to non-filtered stuff is the appstream file, a later
commit will handle that.
Closes: #2869
Approved by: alexlarsson
If this is set to a pathname in the configuration of a remote we load
that file and keep track of it as a filter. No filter is actually applied
yet though.
There is two levels of caching, consecutive lookups of the filter
with less than 500msec between use the previous value. Once its more
that that we stat() the file and compare the mtime, reloading the file
if the mtime changes. We also directly reload the file if the pathname
changes.
Closes: #2869
Approved by: alexlarsson
Filters are specified as a list of
op glob
where op can be allow or deny, and the blogs are partial refs
where * means anything in this part of the ref, and non-specified
trailing parts of the ref matches anything.
By default everything is allowed, but if you specify some
deny rules all that they match is denied, except if there is
an specific allow rule.
Internally this takes all the allow and deny globs and convert
them into two combined regular expressions.
Some examples:
* - match anything
app/* - match all apps
runtime/* - match all runtimes
app/*/x86_64 - match all x86-64 apps
app/org.gnome.*/*/stable - match all stable gnome apps
org.gnome.frogr* - match frogr and extensions
This means you can do a both whitelisting:
deny *
allow org.the.good.app*
Or blacklisting:
deny org.the.bad.app*
Closes: #2869
Approved by: alexlarsson
The function was already leaking the result of
extract_unix_path_from_dbus_address() in the case where that call
succeeded. Since commit 0e545799 it would also leak the result of
g_build_filename in the case where it checked $XDG_RUNTIME_DIR/bus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2877
Approved by: matthiasclasen
This matches what's now implemented in libdbus, GDBus and sd-bus.
If $DBUS_SESSION_BUS_ADDRESS is unset, check whether $XDG_RUNTIME_DIR/bus
is a socket owned by Flatpak's uid; if it is, use it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2874
Approved by: alexlarsson
readlink() and readlinkat() have weird semantics (they return the
number of bytes they would have written if there was enough space,
even if that's larger than the buffer), but glnx_readlinkat_malloc()
takes care to do the right thing in all situations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2873
Approved by: matthiasclasen
There is no great place for this, but the transaction api is
the primary place affected by this problem so I put the note there.
Closes: #2856
Approved by: alexlarsson
We need this to ensure that the dir can be shared with the new
system-helper flatpak user. Old dirs can happen to get less
permissions if there was a umask set when it was created.
Closes: #2856
Approved by: alexlarsson
Old versions of the create-usb command created a summary file in the
local repo being pulled from (e.g. /var/lib/flatpak/repo) but this
summary generation turned out not to be necessary and was removed. So
any computer which used the create-usb command before commit 7c5751a4f
will have a leftover /var/lib/flatpak/repo/summary file which becomes
outdated as apps are updated and installed. This causes problems for the
next invocation of (a recent version of) the create-usb command which
will use the outdated summary during the pull and fail with an error
message like:
error: Importing 3b1293596e9aa67f6fd0daeae477cb94603a4e8ca9e825f446d3dd04a2b5d5ec.commit:
fstatat(3b/1293596e9aa67f6fd0daeae477cb94603a4e8ca9e825f446d3dd04a2b5d5ec.commit): No such file or directory
So this commit makes the create-usb command delete the summary if it
exists before pulling onto the repo on the USB drive. This means USB
copies will work again for any users that used the USB app copy feature
in Endless OS 3.4.7.
Closes: #2854
Approved by: alexlarsson
When an appstream update is cancelled while downloading
icons, properly fail. Otherwise, the next update attempt
will see an up-to-date timestamp, think everyhing is ok
and not download the missing icons.
Closes: https://github.com/flatpak/flatpak/issues/2835Closes: #2836
Approved by: alexlarsson
flatpak run checks if there is any previous-ids for the app and
sees if there is a corresponding app-dir in ~/.var/app/ .
If so, it renames that app-dir to the new app-id and provides
a symlink from old app-id dir to new app-id dir, and exposes
these symlinks to the sandbox. The symlink is needed because even
though the XDG_DATA_DIR and other environment variables are set
to the new ID by flatpak run, the app itself could've stored
(eg in GSettings, or other files) paths which contained the old ID.
https://phabricator.endlessm.com/T23532Closes: #2775
Approved by: alexlarsson
end-of-lifed-with-rebase runs earlier in the transaction system than end-of-lifed, meaning it can modify the transaction for rebasing.
The new flatpak_transaction_add_rebase() function can then be used to apply the rebase if wanted.
Closes: #2775
Approved by: alexlarsson
With the new eol signal the list of ops can change during a resolve
operation, in which case we need to loop until things are stable.
Closes: #2775
Approved by: alexlarsson
When migrating an installed app from eos-apps to Flathub, it may have
had a different app ID (com.example.App) in eos-apps to the Flathub ID
(net.example.app). The migration logic arranges for previous-ids to be
set in the deploy file, and flatpak-dir.c preserves this across app
updates.
A user may have the app on their desktop or pinned to the taskbar under
its old ID, and the Shell uses X-Flatpak-RenamedFrom to update these to
the new ID. The migration logic arranges for the old ID to be added to
X-Flatpak-RenamedFrom at migration time; we need to also preserve this
across app updates.
Note that the Flathub version of the app may well have its own entries
in X-Flatpak-RenamedFrom. It is unlikely that these will overlap with
ours, but for neatness we take care to avoid adding duplicates.
https://phabricator.endlessm.com/T23845
Rebase 1.1.3 (T25194): Fix some minor merge conflicts
Closes: #2775
Approved by: alexlarsson
