Allow a snake-case in the app-id to convert to a '-' or '_' in the
DConf path to be considered similar enough for DConf migration purposes.
This allows the org.gnome.SoundJuicer app-id to migrate its
/org/gnome/sound-juicer DConf path.
F: Ignoring D-Conf migrate-path setting /org/gnome/sound-juicer/
Avoid shadowing variables that are already declared in a previous scope,
and make such occurrences compile-time errors. These are not functional
changes.
In a few places do related code cleanup.
A similar ostree PR is here:
https://github.com/ostreedev/ostree/pull/2195
Now that FlatpakExports can be told to look for /etc and /usr in a
fake directory hierarchy, we can assert that systems resembling
particular OSs' layouts still work, even if we are not running on that
OS right now. In particular, this provides unit tests for commits
12e3dc05, 08d65c54, 7872935e and fe2536b8.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The previous implementation was rather simplistic, and assumed that
all symlinks that get exported are in /tmp/something/test_full/.
Tighten up the assertions, while also coping with symlinks that are
created at top level, such as /bin -> usr/bin.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a runtime is installed explicitly rather than as a dependency, pin it
so it doesn't get automatically removed when unused runtimes are being
removed. We do this because the runtime might be installed for
development or other uses.
This commit also rearranges some code in the mask and pin commands, and
adds a unit test.
As discussed here [1], we want a way to mark runtimes to be kept even
when they are unused by any apps and we are removing such runtimes.
Currently this is a command that can be run manually; a subsequent
commit will pin runtimes automatically if they are installed
independently of any app.
A unit test is included.
[1] https://github.com/flatpak/flatpak/issues/2639#issuecomment-662311756
This gives us control over the paths that get shared (or not) and
whether they are symlinks, so that we can expand coverage later.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Historically we didn't accept them, but there's no real reason why not.
They're normalized to the form in which earlier Flatpak releases would
want to see them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Making it an equivalent of --filesystem=host would be misleading,
because it wouldn't do what you'd think it does: host mounts some host
system directories in their usual places, but others below /run/host.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Paths containing ".." are rejected: they're almost certainly a
terrible idea.
Paths containing "." or multiple slashes are syntactically normalized.
This assumes that nobody is going to use "--filesystem=/foo/bar/" to
mean "make /foo/bar available, unless it's a non-directory, in which
case fail".
Signed-off-by: Simon McVittie <smcv@collabora.com>
There's a limit to how many assertions we can make here right now,
because what we do here is very dependent on the "shape" of the host
filesystem. This could be extended in future by using a mock home
directory whose contents we control.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I was getting this in the CI:
--30631-- WARNING: unhandled amd64-linux syscall: 315
--30631-- You may be able to write your own handler.
--30631-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--30631-- Nevertheless we consider this a bug. Please report
--30631-- it at http://valgrind.org/support/bug_reports.html.
runtime/org.test.Platform/x86_64/stable: 13b73140218edd02a9d18bc178af1a3ad0203049f9f1ad8c51c62b3ee5f1acd9
==30631== Syscall param ioctl(generic) points to unaddressable byte(s)
==30631== at 0x53A437B: ioctl (syscall-template.S:78)
==30631== by 0x4B4456E: ??? (in /usr/lib/x86_64-linux-gnu/libostree-1.so.1.0.0)
==30631== by 0x4B466FB: ??? (in /usr/lib/x86_64-linux-gnu/libostree-1.so.1.0.0)
==30631== by 0x4B48F29: ostree_repo_write_content (in /usr/lib/x86_64-linux-gnu/libostree-1.so.1.0.0)
==30631== by 0x1D9161: flatpak_mtree_create_symlink (in /home/runner/work/flatpak/flatpak/_build/flatpak)
==30631== by 0x1DF95B: flatpak_repo_generate_appstream (in /home/runner/work/flatpak/flatpak/_build/flatpak)
==30631== by 0x157870: flatpak_builtin_build_update_repo (in /home/runner/work/flatpak/flatpak/_build/flatpak)
==30631== by 0x135793: main (in /home/runner/work/flatpak/flatpak/_build/flatpak)
==30631== Address 0xe is not stack'd, malloc'd or (recently) free'd
==30631==
{
<insert_a_suppression_name_here>
Memcheck:Param
ioctl(generic)
fun:ioctl
obj:/usr/lib/x86_64-linux-gnu/libostree-1.so.1.0.0
obj:/usr/lib/x86_64-linux-gnu/libostree-1.so.1.0.0
fun:ostree_repo_write_content
fun:flatpak_mtree_create_symlink
fun:flatpak_repo_generate_appstream
fun:flatpak_builtin_build_update_repo
fun:main
}
Currently when searching for a remote to provide the runtime for an app,
we search remotes in priority order. This commit makes it so we search
the remote providing the app before others with the same priority, and
otherwise still search in priority order. This means for the common
case where every remote has the default priority of 1, the app's origin
will have the first chance to provide the runtime. This behavior seems
logical, but the impetus for this change was also to keep a unit test
passing in eos-updater[1] after a port to FlatpakTransaction.
Originally the eos-updater unit test was written to prioritize the
origin remote regardless of the priorities on any other remote, but
during code review it was decided to let higher priority remotes stay
above the app's origin.
In practice it's usually true that only one remote provides a runtime
and priorities aren't set at all, so this is an edge case that probably
doesn't come up much.
A unit test and documentation updates are included.
[1] eede0a8b9c/tests/test-update-install-flatpaks.c (L1919)
Otherwise the installed tests will fail:
SUMMARY: total=32; passed=30; skipped=0; failed=2; user=820.8s; system=589.3s; maxrss=445132
FAIL: flatpak/test-oci-registry@user.wrap.test (Child process exited with code 1)
FAIL: flatpak/test-oci-registry@system.wrap.test (Child process exited with code 1)
due to:
error: The name org.flatpak.Authenticator.Oci was not provided by any .service files
Don't leave options set on the remote in one of the unit tests. If
something should be set for every test it should be done in
global_setup(). This commit also changes the FlatpakRemote
implementation to allow unsetting title and default branch.
Re-implement flatpak_installation_list_installed_refs_for_update() using
a FlatpakTransaction, so we can guarantee it always gives the same set
of things to update as the update command. This API is used by GNOME
Software and many times in the past g-s has not shown the same list of
apps to be updated as the flatpak CLI. See:
- https://gitlab.gnome.org/GNOME/gnome-software/issues/539
- https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/430
This commit also expands the unit tests for this API, which were already
quite good. Now we test that missing subpaths of locale extensions show
up as updates, and updates that have been pulled but not deployed show
up as well. The latter is a break from how this function used to behave,
but it seems unlikely to break any application.
Instead of having a global config option we scan a directory for
symlinks into the sideload repos. These come from
/var/lib/flatpak/sideload-repos and /run/flatpak/sideload-repos (for
default system installation).
This is much easier to update atomically, and the two different
options are useful for persistant (the first) or dynamic (the second)
usescase.
Fixes https://github.com/flatpak/flatpak/issues/3494
We use the localcache-repos option to ostree_repo_pull to make ostree
directly import any files that are locally available in the sideload
repo even when pulling the main commit from upstream.
This also adds a test that verifies that such files are not
pulled via http.
This is a new version of --deploy-collection-id that only applies
the collection id update for new (1.7.x+) version of flatpak clients.
This allows you to enable collection ids for sideload use but not
affect older clients where the p2p codepaths are not as tested.
This used to not be set for collection-id remotes as we used the
ostree-metadata branch for resolving. However, we now use the summary
always when doing a remote install (and not ostree-metadata for local
sideloads), so we still want to verify summary.
The signature on the summary is a nice security feature, but it is also
a very efficient small file to download to verify that no new summary
needs to be downloaded in the no-op update case.
* Test that we load from sideload repo even when online
* Test that when offline we don't update to older version in sideload repo
* Test update to explicit version in sideload repo
* Test updates to new version from sideload repo
Nothing fundamentally happens differently in ostree if the collection-id
is set, as long as we don't call the p2p specific apis. So, lets keep
using it instead of adding our own special magic.
Most code that looks for a regular collection id set on the remote is
removed, as these should never happen in flatpak repo setups now.
Some is replaces with looking at xa.sideload-collection-id:
* The libflatpak FlatpakRef::collection-id property now comes comes from the sideload id
* Various CLI commands showing or changing the collection-id for a remote now uses the sideload id
* Collection id deploy in update now sets the sideload-collection-id instead
* Setting the collection id for a remote in libflatpak now sets the sideload id
Additionally we now delete the code that allows unsigned summaries
when there is a collection id (because there is none).
create-usb now uses the sideload id as as collection id source when exporting.
The direct repo operations (export, bundle, commit-from) still support
collection ids, because on the server we do want to set it so that we
can sideload.
