This is specifically for running build-time tests in the Autotools build
system, and is not used when running installed-tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 597abdc5853d5ae0b9c212aeb5517bd2eeab2717)
The subpath is resolved relative to the root of the commit, so we can
use either an absolute or a relative path interchangeably. When using
libostree < 2021.6 with GLib >= 2.71, absolute paths cause an assertion
failure here; that was a libostree bug and was fixed in 2021.6, but we
can interoperate with more versions by sticking to relative paths, and
there's no real reason to prefer absolute.
Resolves: https://github.com/flatpak/flatpak/issues/4805
Co-authored-by: Corentin Noël <corentin.noel@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2df1b1628c277cd4ce2d40c31bd6a3eb3ee9662e)
As with non-path-based AF_UNIX sockets, both of these are going to
require --share=network to be enabled, so print a warning if it isn't.
We don't automatically enable --share=network, because that elevates
the privileges of apps that would otherwise have entered a new network
namespace, but regular users of remote X11 can choose to enable it with
`flatpak run --share=network` or `flatpak override --share=network`.
Resolves: https://github.com/flatpak/flatpak/issues/397
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit db885e0542700fa5aa98f890a78699ee6e182bb7)
If the filesystem-backed Unix socket (G_UNIX_SOCKET_ADDRESS_PATH) does
not exist, X11 clients can also use a Linux abstract Unix socket
(G_UNIX_SOCKET_ADDRESS_ABSTRACT), or even a TCP socket.
Both of these are going to require --share=network to be enabled, so
print a warning if it isn't. We don't automatically enable
--share=network, because that elevates the privileges of apps that would
otherwise have entered a new network namespace, but users can make it
work with `flatpak run --share=network` or
`flatpak override --share=network`.
When falling back to an abstract Unix socket or to a TCP socket, we
can't remap the display number to the fixed :99.0 that we normally use,
so adjust write_xauth() to be able to avoid doing that.
Resolves: https://github.com/flatpak/flatpak/issues/4702
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 1d81d610532c5bdfca20a2ec30ff2d56611d3ca0)
We still don't support rewriting XAUTHORITY for these, but at least we
understand them now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 69f347e58affaaa64178c114b5f2004734ae0ad7)
xauth and xcb both treat this as a request to use AF_UNIX.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit c3395a0e8307ff3dcab37169998d5155da3aacca)
This allows it to be unit-tested.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 18db8e8713c11582f84d2f0f073b3d666100c0fa)
In practice, au_len comes from one of the length fields in an Xauth
struct, which are all of type unsigned short, so it cannot really be
negative; but if we passed a negative argument here, the comparisons
would not behave as intended. Use the more correct size_t.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2358d25684696e9f6363acb0baa619ca1898d965)
We're not going to call XauDisposeAuth on local_xa, so it's OK to put
a "borrowed" constant string here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 39823be84f1ff23f4efb97b7ef99dd92889d0559)
It is already the case that when we are using ALL_DIRS, we always
combine it with OPTIONAL_REPO, meaning no need to populate empty
installations. ALL_DIRS is used for commands that iterate through all
known installations to enumerate apps/runtimes, such as `flatpak run`
and `flatpak list`; for these commands, it's reasonable to say that
if the installation does not have a libostree repository, then that's
equivalent to it having a libostree repository with no apps and no
runtimes. Make this happen automatically if forgotten.
For STANDARD_DIRS, we were inconsistent about this: `flatpak remote-list`
had OPTIONAL_REPO, but the other commands did not.
STANDARD_DIRS is used for `flatpak create-usb`, and for all the commands
that manipulate remotes.
For the commands that manipulate remotes, it seems reasonable to say
that if an installation has no libostree repository and we are unable
to create one, then that's equivalent to an installation with a
libostree repository but no remotes.
Similarly, for create-usb, an installation where we are unable to create
a libostree repository seems like it should be equivalent to an
installation whose libostree repository does not contain any of the
refs we are interested in.
Resolves: https://github.com/flatpak/flatpak/issues/4111
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3f144d1e02fa060680eba18a9dd81969682a3170)
libostree makes heavy use of fd-based I/O, which has the disadvantage
that it is rarely obvious what path an error message is referring to.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit d106384446ae57c78a76f4a0a0360797df62c31f)
If we are running a CLI command in the background, then EnsureRepo
might require authorization. Silently skip it if allow_empty was true,
as it is for commands that iterate through all repositories.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 48f40d45045071c0e073061b72a1c32fb0562c3f)
Previously, if /var/lib/flatpak didn't exist then we would use the
system helper to create and populate it, but if it existed and was empty,
we could only populate it if we had privileges. This led to errors from
libostree:
Creating repo: mkdirat: Permission denied
The EnsureRepo method call is allowed by default for active local users,
so do this even if allow_empty is true: this will incorporate
/etc/flatpak/remotes.d into the repository, whether it is newly-created
or not. This makes a `flatpak search` work immediately, without having
to fetch metadata explicitly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2489b915efae3a78ca7040c39161f8c304e4c7a5)
I'm about to add another caller for this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8537b3412ad70479b16ad2c880c73ba37daf80d0)
This is a combination of these two commits from the main branch:
build-finish: Export appstream metainfo into a single directory
(cherry picked from commit 766bf5f08a256431cde8bca6228a4964a73ff6bc)
Export to share/metainfo not share/appdata
(cherry picked from commit 3c63cac8f9c0b45d6e6b8f4167845366a6bb34d9)
However this commit only allows the exports when deploying an
install/update, not when building a new Flatpak, so we avoid a warning
message but arguably don't add any new features to the stable branch.
Fixes https://github.com/flatpak/flatpak/issues/4800
If WAYLAND_DISPLAY starts with a '/', use it for the socket path as-is.
See [1].
[1]: d690712b7b/src/wayland-client.c (L1064-1095)
Signed-off-by: Julian Orth <ju.orth@gmail.com>
(cherry picked from commit aac1205d66e03facc965279d5825272597b305d0)
Put the configured server address string in PULSE_SERVER if it appears
to be remote. This should be enough for apps that already have network
access via --share=network.
If remote access to a PulseAudio server has been selected but the app
does not already have the --share=network permission, we don't want to
add --share=network automatically, because that would open up the app's
access to network resources, perhaps unexpectedly. However, users of
this non-default configuration can use `flatpak run --share=network` or
`flatpak override --share=network` to open up that access if they
consider it to be safe enough.
Resolves: https://github.com/flatpak/flatpak/issues/3908
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ee418c1f2010b0ffa5ad40c96a04d054eadce202)
In some OS configurations, unprivileged users cannot read back messages
that they have written to the system log. This test cannot succeed if that
happens, so skip it.
In particular, if the Journal is only in-memory rather than persisted
to disk (as it was by default in Debian 10), then there are no per-user
Journal files, only a single system-wide Journal which requires privileges
to read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 8b05f6b3 "Add a unit test for the history command"
(cherry picked from commit 0deb80efa8642e575ae9ae28bee49d74e6c024f3)
All the details of the bug are in:
https://github.com/ostreedev/ostree/pull/2549https://github.com/flatpak/flatpak/issues/3479
This patch works around it by marking the commit we're about to pull
partial, so that if the .commit object exists in a staging directory
from a previous failed pull, it will not be erroneously considered a
complete commit, even by affected versions of libostree that don't have
the above patch. If for some reason the commit in the staging dir is
complete, libostree should harmlessly verify that and pull it in.
Usually the commit we are pulling does not already exist in the local
repo, but add a check anyway so we don't risk marking a complete commit
as partial, and so this works on the code path from
"flatpak install --reinstall ..."
Fixes#3479
(cherry picked from commit 11158c24817ee7e5a7e5766e49e0a74b6ba6763d)
Due to previous bugs we were leaving a lot of temp files around
in the appstream deploy dirs, which could add up to using a lot of
space. So, lets find and delete these on updates.
This check only happens on a successful update to a new appstream,
which isn't that often, so the cost of this check is unlikely to be a
problem.
(cherry picked from commit d4a9f3ba23d7e3aac08745f57cabd244d68c71bd)
If during appstream deploy there is an error, the temporary files were
not deleted, resulting in leaked files in /var/lib/flatpak/appstream.
Over time these could add up to a significant size. In particular this
happes if several deploys happen in parallel, because then the final
move into place will fail with EEXIST.
This fixes the cleanup of both the temporary directory and the temporary
link on any error.
Fixes https://github.com/flatpak/flatpak/issues/4735
(cherry picked from commit 61f9297cbc2c046520c4c9807df67729ffb1855f)
Trying to run sandboxed GStreamer applications from within jhbuild, for
example, would make those applications fail to find their plugins.
$ LANG=C flatpak run org.gnome.Totem.Devel
** (totem:2): WARNING **: 19:32:06.406: Element 'gtkglsink' is missing, verify your installation
** (totem:2): WARNING **: 19:32:06.406: Element 'glsinkbin' is missing, verify your installation
Don't propagate those GStreamer environment variables to within the
sandbox to avoid that problem.
See https://gitlab.gnome.org/GNOME/totem/-/issues/504
(cherry picked from commit 4470bf142523e8a9bd6791880a66676225dea555)
The history test fails sometimes in the CI due to the remote add
operation being missing from the history command's output:
+ diff history-log -
0a1
> add remote system (history-installation) test-repo
Presumably this is due to that operation happening in the same second
that is passed to --since, so move the sleep statement to make sure a
second passes before we do anything.
There's no need to use polkit in the history command, so don't start the
agent in flatpak-main.c. This means we can avoid a test failure in
test-history.sh which was caused by old versions of valgrind being
unaware of syscall sched_getattr, which is used in g_bus_get_sync(),
itself called by install_polkit_agent().
(cherry picked from commit dd9fe190661bce70adf4e3df972b8033a656d48a)
Without this change there are history entries showing pulls into
temporary repos which we don't want.
(cherry picked from commit e18df8379a88fd1cd0272d6a6cbec4afc57d1397)
Currently we include entries in the output of the history command for
pulls of appstream refs, e.g. "appstream2/x86_64". However since they
don't have an application ID the Application column shows up blank and
it seems like a pull of nothing which is confusing. These are basically
an implementation detail like the temp repo pulls we already exclude, so
I think it makes sense to exclude them from the output.
It would also make sense to exclude pulls of ostree-metadata refs, but
for some reason I don't see those in practice, even with a collection ID
set on the remote.
(cherry picked from commit fbad9641b73632c0577d0dc9c38f1ea9c8aa6223)
The history command seems to have been broken since it was changed to
use FlatpakDecomposed, since that type only works for app or runtime
refs, resulting in errors such as:
$ flatpak history
error: appstream2/x86_64 is not application or runtime
Fix this by making the logic a bit smarter, and don't let any one
invalid ref entry prevent the whole command from working.
Fixes#4332
(cherry picked from commit e44b54856e98fb080ded77159979ddd6022981f2)
