During build-time tests, bwrap doesn't necessarily work. In particular,
official Debian autobuilders can't enter namespaces.
We continue to leave the sandbox enabled in the build-export calls in
tests/test-extensions.sh, tests/test-unsigned-summaries.sh
and tests/test-update-remote-configuration.sh, which are already
skipped if bwrap isn't available. This means we exercise both the
normal and --disable-sandbox code paths.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #2661
Approved by: alexlarsson
In a previous iteration of the work for supporting multiple collection
bindings on a commit[1][2] the key ostree.collections-binding was used,
but it was decided that ostree.collection-refs-binding makes more sense.
So update build-commit-from in one place where the old key was still
being used. This impact of this bug is that we would overwrite the value
of ostree.collection-refs-binding on the new commit with the one on the
source commit (which may not have all the same collection-refs
associated with it). However since the libostree support for that key
hasn't been merged that wouldn't cause any problems yet.
[1] https://github.com/flatpak/flatpak/pull/2634
[2] https://github.com/ostreedev/ostree/pull/1805Closes: #2644
Approved by: matthiasclasen
These don't have AS_BUNDLE_KIND_FLATPAK, but we can just
assume all bundles are flatpak bundles in the appstream data
we get from flatpak.
Closes: #2650
Approved by: alexlarsson
If this is passed, we add an extra collection id binding to
the commit, as well as create a separate ref for that particular
collection id.
This weakly depends on:
https://github.com/ostreedev/ostree/pull/1805
In that without that change ostree pull will not respect
multiple collection-id bindings. It will still work for
the main/first collection id though.
Closes: #2634
Approved by: alexlarsson
This file lists the directories that are remapped in the sandbox,
allowing fontconfig to use the correct cache identifier for the
host-side caches.
As an example, this generates:
```
$ ./flatpak run --command=sh org.gnome.gedit
[📦 org.gnome.gedit flatpak]$ cat /run/host/font-dirs.xml
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<remap-dir as-path="/usr/share/fonts">/run/host/fonts</remap-dir>
<remap-dir as-path="/home/alex/.fonts">/run/host/user-fonts</remap-dir>
</fontconfig>
```
Closes: #2635
Approved by: alexlarsson
We don't want line editing to interfere with our
formatting, so we turn on raw mode while we do
fancy progress reporting. We use raw mode at the
same times as we hide the cursor.
This should prevent partial Escape sequences from
showing up in the output.
Closes: #2638
Approved by: alexlarsson
This function helpfully does not 0-terminate the buffer,
so we have to do that ourselves. Also make the buffer
as large as possibly required, and handle errors.
Closes: #2630
Approved by: matthiasclasen
We can't look at the FLATPAK_VALIDATE_ICON environment variable
inside the sandbox. Use /proc/self/exe to find the binary to reexec.
Closes: #2618
Approved by: alexlarsson
We need to handle source directories not existing, for example /lib64
on a pure 32-bit system.
Because relative symlinks in a directory that is itself a symlink do
not have the same meaning as the same relative symlink in a bind-mount
of that directory, ideally we want to use --symlink for /lib and /lib64
on merged-/usr systems, but --ro-bind on non-merged-/usr systems.
Also bind /etc/ld.so.cache into the sandbox.
This is especially important for libstdc++ on distributions that
don't have it directly in a libdir and the runtime linker doesn't
look where needed without /etc/ld.so.cache (e.g. if libstdc++ is
in a GCC per-version subdirectory handled via /etc/ld.so.conf.d/).
Changes originally made in libgnome-desktop by Iain Lane (see
<https://bugzilla.gnome.org/show_bug.cgi?id=787072>).
Adapted from https://github.com/flatpak/xdg-desktop-portal/pull/289
by Simon McVittie.
Closes: #2618
Approved by: alexlarsson
Make the icon validator reexec itself inside a sandbos
if the --sandbox option is given. This lets us share
the sandbox setup between all users of this tool.
An additional advantage is that this makes the sandbox
setup code testable by iself.
Closes: #2618
Approved by: alexlarsson
The spec allowed either timestamp or date to
be specified for a release, so we should support
both.
Closes: #2614Closes: #2619
Approved by: alexlarsson
Allow to override ellipsization with a suffix on the colum.
Use
:s or :start for ellipsization at the start,
:m or :middle for ellipsization in the middle,
:e or :end for ellipsization at the end,
:f or :full for no ellipsization.
This can be helpful when it is important to see certain
columns in full.
Closes: #2621
Approved by: alexlarsson
This lets us export D-Bus service files for
names like org.foo.Bar.Application.Tracker.service
when the app-id is org.foo.Bar.
Closes: #2615Closes: #2616
Approved by: alexlarsson
For example, someone today got warning messages for deploy refs:
Remote (null) for ref deploy/runtime/org.freedesktop.Platform.html5-codecs/x86_64/18.08 is missing
Closes: #2611
Approved by: matthiasclasen
These were part of the flatpak-builder tests, and are no longer
distributed in tarballs or used by Flatpak's tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2607
Approved by: matthiasclasen
If the user (erroneously) runs as root while modifying their user
installation, e.g. with "sudo flatpak --user install ...", this can
cause "permission denied" errors later on when they try to operate on
the installation as their own user. So refuse to execute a transaction
on a user-owned installation as root. Root can still operate on their
own per-user installation.
This approach does have a weakness: if flatpak is running as root when the user
installation is first created, it will be owned by root and therefore
avoid this check. I'm not sure what could be done about that.
Fixes https://github.com/flatpak/flatpak/issues/2565Closes: #2575
Approved by: alexlarsson
While we don't need any of the modules (the png loader
is compiled in), gdk-pixbuf refused to operate without
a loaders.cache file, which only gets created when installing
modules :(
Closes: #2523
Approved by: alexlarsson
Avoid linking to the same fd.o spec just linked to a few lines above,
and rearrange things to be more readable.
Closes: #2606
Approved by: matthiasclasen
The compatible architectures are not symmetric: x86_64 and aarch64 can
run i386 and arm binaries, but i386 and arm cannot usually run x86_64
and aarch64 binaries.
This caused test failures on Debian i386 autobuilders.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #2603
Approved by: matthiasclasen
AsciiWolf