In particular this tests commit 3aaea7d2 "Expose /var/usrlocal if
"--filesystem=host" is specified" and checks that /var/usrlocal is
counted as part of --filesystem=host-usr.
Signed-off-by: Simon McVittie <smcv@collabora.com>
To be excluded from tarball releases, generated files need to be in
nodist_ lists of sources every time they appear.
Fixes: 412c1577 "portal: Add some test coverage"
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fix an “The application foo requires the runtime bla which was not
found” error when using libflatpak (not the CLI) to install an
application whose runtime is provided by a different repo, and which is
for a non-default architecture.
This is a follow-up to commit f2ff664ff.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It doesn’t look like this error path is taken very often. Spotted while
reading through the code.
This function is opportunistically looking for dependencies, so a
failure in one remote shouldn’t make the whole operation fail.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The client-side proposed for flatpak-spawn uses --app-path, but the
actual implementation on D-Bus uses file descriptor passing and an
option named app-fd, so the documentation of the D-Bus interface should
be written in terms of app-fd.
Fixes: 3ebf371f "run: Allow caller to replace /app and/or /usr"
Signed-off-by: Simon McVittie <smcv@collabora.com>
For whatever reason parts of mono is installed, but the repo is not
configured so there is a version conflict on update:
libglib2.0-cil is already the newest version (2.12.45-0xamarin19+ubuntu1604b1).
libglib2.0-cil set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libglib2.0-cil-dev : Depends: libglib2.0-cil (= 2.12.10-6) but 2.12.45-0xamarin19+ubuntu1604b1 is to be installed
E: Unable to correct problems, you have held broken packages.
If the deploy metadata is missing for the locale runtime of an app which
is being uninstalled, flatpak will currently abort on an assertion
failure.
Prevent that abort, at the expense of not uninstalling the locale
runtime. A better fix could be found for this in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3943
During unit testing we don't have a complete Flatpak app or runtime
available, and `flatpak run` is not necessarily in FLATPAK_BINDIR yet;
but we can run the portal with this environment variable set, to
specify a mock implementation of Flatpak.
This helps to reproduce #4286.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Just because we can allocate a new, unused fd in the portal's fd space,
that doesn't mean that fd number is going to be unused in the child
process's fd space: we might need to remap it.
Resolves: flatpak/flatpak#4286
Fixes: aeb6a7ab "portal: Convert --env in extra-args into --env-fd"
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will allow us to add additional mapping entries for fds to be
used internally by `flatpak run`, in particular --env-fd.
Defer the second pass through the fd array until the last possible
moment, so that any extra fds we want to add (like the --env-fd) have
already been added by then.
Helps: flatpak/flatpak#4286
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise we'll run out of file descriptors eventually, when starting
a sufficiently large number of subsandboxes.
Resolves: flatpak/flatpak#4285
Fixes: aeb6a7ab "portal: Convert --env in extra-args into --env-fd"
Signed-off-by: Simon McVittie <smcv@collabora.com>
These functions were already annotated with G_GNUC_PRINTF, so gcc
can assume that the format string and arguments match up.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This allows callers to be checked for mismatches between format string
and arguments, and also means gcc can assume that the format string and
the arguments match up correctly when forwarding them to functions
like g_strdup_vprintf, removing the need to suppress -Wformat-nonliteral
warnings.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In principle this could have been subject to a format string attack
via an argument containing %n, although in practice the code that uses
this format string is #if 0.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we use x86_64 and i386 in places where any architecture would do,
it's harder to recognise whether the test is assuming every machine
is x86 and would fail elsewhere (e.g. as fixed in #4142). When just
parsing abstract strings where any syntactically valid architecture
would do, let's use rare/niche architectures that none of the maintainers
are running on, so that hard-coding x86_64 or i386 stands out more.
I've used mips64 and m68k because they happen to be the same length as
x86_64 and i386, avoiding re-indentation.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currenly we only list arch in the list of things to install from a
transaction if not all the refs are the same arch. It makes more sense
to show the arch even if its unique if they are not the primary arch.
It turns out that we can't currently uninstall a ref from a
non-standard arch without specifying the arch even if there is no similar
ref installed for the main arch. (#4264)
The fundamental reason for this that `flatpak_dir_find_installed_ref(s)`
currently only returns refs with standard arches unless you explicitly
specify an arch.
This changes flatpak_dir_find_installed_refs() to always return
all the refs for all installed arches. This is generally what
we want anyway, except in the case of "flatpak run org.some.Platform" where
we don't want to prompt if there are multiple arches installed, so that
is manually changed.
This changes find_matching_ref() to look for refs in all arches, but
always prefer (without prompting) the default arch if that is installed.
This also matches what all current callers want.
Fixes#4264
By default we only download the main arch subsummary, so if you added
a ref for some other arch it failed to find the ref. This works with the
CLI, because it explicilty loads the subsummary when its trying to expand
the parial ref to the full ref. However apps using libflatpak don't do that
so they failed.
If the tests are run as root, the system helper is not used even when
commands are run with `--system`. This means a different cache path is
used (see `_flatpak_dir_ensure_repo()`). The tests did not accommodate
for that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If looking up the summary for a ref without an arch (for example,
`ostree-metadata`, which the Endless OS version of flatpak uses in some
backwards-compatibility code), avoid passing `NULL` to `strcmp()` and
hence crashing.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
