After the --redirect-url= test is finished it leaves the remote with a
different url, which is confusing the other tests.
In particular, at some point we remove the remote and add it back,
which gets us back to the old url, but at that point the summary (from
the newer url) has a later mtime than the old one so the old one keeps
getting used.
So, we unset the redirect and set back the old url. Also, the following test
had to be tweaked for this change.
We enforce --no-update-summary when we create test apps and
runtimes, and then we ensure we always manually call update_repo
after all modifications are done.
This means we save work avoiding summary updates, but it also means we
can do special handling in update_summary and guarantee that this is
the only place this happens. For example, we want this to work around
the mtime handling of summary updates.
We remember what action we took for EOLs, and for sub-refs (ie .Locale)
we reuse that.
Also, we show if eol:ed refs are pinned (as that makes them not be
auto-uninstalled), and we list the apps that use the eol:ed runtime
ref.
Example run:
```
Looking for updates…
Info: (pinned) org.gnome.Sdk.Compat.i386 is end-of-life, with reason:
The GNOME 3.34 runtime is no longer supported as of 14th August 2020. Please ask your application developer to migrate to a supported platform.
Info: org.gnome.Platform is end-of-life, with reason:
The GNOME 3.32 runtime is no longer supported as of 11th March 2020. Please ask your application developer to migrate to a supported platform.
Applications using this runtime:
org.gnome.HexGL
```
Currently if an app has been renamed and you run "flatpak update" you
will be prompted to decide whether to install the new name of the app
(and uninstall the existing one). However, in such a situation
flatpak_installation_list_installed_refs_for_update() does not return
the app, and therefore gnome-software doesn't see any updates available
(except in the case where the installed commit is older than the commit
with the eol-rebase metadata).
So include end-of-life-rebased apps in the returned list. Patches to
make gnome-software update such apps properly are forthcoming.
I checked that the included unit test only passes with this patch to
libflatpak.
This means we do a bit less string operations, but it also allows us
to pick up the collection-id when listing refs from a file: uri, fixing
the issues described in https://github.com/flatpak/flatpak/pull/3909
This slightly changes the behaviour of collection ids and remotes.
When listing regular remotes we only ever return the refs with the
collection id specified by the configuration of that remote. However,
when specifying a file: uri for the remote name we return all the refs
in the repo, with their corresponding collection id.
This means the test suite has to change a bit as before we returned
all the collrefs from the remote, not just the one matching the configured
collection id.
getters now have three forms:
const char *foo_peek() returns pointer into data and length
const char* foo_get() returns zero terminated pointer into data
char *foo_dup() returns allocated zero terminated pointer
Not everything has all of these (as that is not always possible), but
it is clear what each one does.
We also now support storing a collection id for a
FlatpakDecomposed. This is not typically done (as we use the source
remote to define the collecion id and don't expose this concept to the
user). However, for the case when directly listing a local repo (such as
a side-load repo) we need this.
We now validate the arch string. The valid chars are a-z, A-Z, 0-9 and
_. This was't previously verified, but no arches in existance have other
chars.
There is a new flatpak_decomposed_new_from_decomposed() which lets you
modify part of another ref. Say replace the arch or the branch and
keep the rest the same.
These now take (optional) string length args:
flatpak_id_has_subref_suffix()
flatpak_levenshtein_distance()
flatpak_is_valid_name()
flatpak_is_valid_branch()
The code to use the pre-generated test platform was buggy so it wasn't
used. Also, generate a "stable" branch of it too as that is used
by test-run.sh.
This way we can get the proper eol status for the new to-be-installed
refs, rather than whatever was previously installed. This allows us to
detect when a runtime is updated and the new one is eol, and nothing
uses it, so it can be auto-uninstalled.
Rather than trying to figure out which runtimes are affected byt
the current setup of ops we run flatpak_dir_list_unused_refs() twice,
once with and once without the changes the transaction will cause.
Any unused refs after the transaction that were not unused before are
caused by the transaction and we start uninstall ops for those.
Also rename flatpak_dir_list_unused_refs_with_options() to
flatpak_dir_list_unused_refs() as it need not be so long.
In case a runtime becomes unused and then later becomes End-Of-Life, it
is currently not removed. So this commit removes such runtimes in the
update command, as discussed in #2639. A unit test is included.
I am planning to propose to use the FlatpakTransaction API added here in
gnome-software, so that users don't have to use the CLI at all for
runtimes to be cleaned up. KDE Discover already removes unused runtimes
periodically.
We normally don't remove a runtime when the last app using it is
uninstalled, since runtimes are large and re-downloading it in the
future may be difficult. But if the runtime is end-of-life, there's a
reasonable chance it won't be used again, so uninstall it in that case.
Similarly, if the last app using a runtime is upgraded to a different
runtime, and the runtime is EOL, uninstall it.
A unit test is included, and the subsequent unit test also had to be
modified. Otherwise we get a "Update is older than current version"
error, since the runtime is installed from test-repo but
setup_repo_no_add() calls make_runtime() which uses the one in
runtime-repo instead, which is older than the one in test-repo.
commit 6b46d9a0ed that added DConf path
skewering to camelcase conversion only allowed it in one direction
(skewered path1 and camelcase path2).
That turned out to be not enough to allow /org/gnome/sound-juicer/ to
/org/gnome/SoundJuicer/ conversion as the caller had the
flatpak_dconf_path_is_similar() arguments the other way around.
This commit implements it both ways to avoid confusion which way it
should be called.
F: Ignoring D-Conf migrate-path setting /org/gnome/sound-juicer/
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)
