We require jobs to succeed before a PR can be merged. If a PR only
touches files which match `paths-ignore`, the jobs won't run and the PR
can't be merged.
The number of PRs which only touch those files is small, and the extra
CI runs resulting from that can be ignored.
If an SDK is already installed in a dir that is not targeted with a
flatpak transaction, and the transaction has auto_install_sdk set,
add_new_dep_op returns NULL in dep_op which is not correctly handled in
add_deps.
Fixes#5894
There are a number of races, and failure conditions which can lead to a
pid of 0 being returned from flatpak_instance_get_child_pid. This would
lead to a whole bunch of things getting killed.
We will skip the instance in those cases now, and retry a few times. We
also notice when the instance just goes away by itself now.
This should make killing more robust, and especially not SIGKILL pid 0.
We could previously just assume that the first enabled remote
(potentially matching the collection ID) contains the ref, but that
obviously is not always the case.
The change here looks up the remote state of the remotes to figure out
if they actually contain the ref, and adds the first matching remote to
the transaction.
Sudo can be used in several ways other than calling a command with the
root user. For example, one can use -u to run the command as the
specified user, or -g to specify a primary group to run the command
as.
Flatpak adds a check when --user is used to prevent an installation in
the root's directory, for example, but it does it by only checking if
sudo was used. As stated previously, it does not necessarily imply
root, so this patch explicitly checks if the command is being run with
the root user.
Fixes: https://github.com/flatpak/flatpak/issues/5979
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Those schemes are in use by flathub, usually to be handled by an app
store, but we can also handle it directly with `flatpak install`.
Base on an idea from user bbb651 in
https://github.com/flatpak/flatpak/pull/6259.
The appstream docs say:
Release data may be present directly in a component metainfo file, but
also optionally be split out into an external metadata file.
The file must be installed as
/usr/share/metainfo/releases/%{cid}.releases.xml, where cid is the
component ID of the component the release information belongs to.
This change allows flatpak build-finish to export those external release
files.
Closes#6057
PIDs are pretty much always a bad idea because they can be racy. The
authorization did use the PID though. We can replace it by a check via
the system bus name.
Closes: https://github.com/flatpak/flatpak/issues/6212
For OCI remotes, the existing sideload repository system doesn't
work: identity for OCI remotes is done by manifest digest (disguised
as a fake commit ID internally), instead of by ostree commit, so
we have no way of knowing whether a sideloaded image matches the
summary.
Allow specifying a new form of sideload repository with:
--sideload-repo=oci:<path>
The desired use case for this is preinstalling Flatpaks during OS
install, and for this, binding the entire repository to a single
collection ID is both inconvenient and not useful, so OCI sideload
repostories don't have a defined collection ID - they just apply to
all OCI remotes. (And, because of this, they are restricted to
the command line.)
The memory management of returning a VarRefInfoRef is tricky - it
points to data owned by the summary or the sideload repo. External
consumers were always retrieving a copy of the summary metadata,
so make the public function do that.
For some reason, flatpak build always had host permissions set by
default. There really isn't a good reason for this. The build should be
isolated from the host as much as possible by default.
Without doing so, flatpak_dir_get_config() won't reflect changes made
with flatpak_dir_set_config().
This fixes passing multiple patterns to `flatpak mask` for the system
installation.
Closes#5464
Fixes#4268
Make sure that session-helper always tracks the destinations of symlinks.
This fixes a race condition on systems where '/etc/resolv.conf' is a symlink.
Otherwise we try to call setfattr which fails and have_xattr reports
that there is no xattr support. This might then obviously be wrong and
the test can fail because of that.
If the binaries are not available in the environment, the trigger will
not do anything. The tests will not know about this and fail. So only
test for the results of the triggers if they have the dependencies they
require.
This adds a new type that is meant to track more complex permissions
than a pure bitmask, including conditional dependencies. It is not yet
used, but it will be used for at least the socket and device
permissions.
For each possible permission we track whether the permission is
unconditionally allowed, unconditionally disallowed, or if it is
conditionally allowed (allowed if some conditions are met).
Additionally we track for each permission whether stacking the context
on top of another will reset permissions in the layer below. This is a
new feature, because previously merging layers *always* overrode the
value from below, whereas conditional permissions can either stack on
top of, or replace the underlying layer.
In terms of the keyfile, there are 4 possible types of layers:
1) Add a permission, removes all partial permissions below
socket=pipewire
2) Remove access, removes both partial and full permissions below
socket=!pipewire
3) Adds a partial permission, keeping whatever is already there:
socket=pipewire;pipewire:if:has-wayland
Note: This adds a plain `pipewire` for backwards compat.
Note: If parent has full pipewire access, this is a no-op.
4) Adds a partial permission, remove all previous access
socket=!pipewire;pipewire;pipewire:if:has-wayland
Note: This seems weird as it has both !pipewire and pipewire, but older versions
will read these in order and get the right result.
Additionally, partial permissions can have multiple conditions:
socket=pipewire;pipewire:if:has-something;pipewire:if:has-other;
In such a case the socket will be accessible if any condition matches.
Conditions can also be negated:
socket=pipewire;pipewire:if:!has-something;
Due to backwards compatibility we have to add the non-conditional
permission as well as the conditional, as older flatpak will ignore
the conditional. This is handle when serializing/deserializing the
permissions, and internally we don't have to care about this.
Instead of pulling out data from the context and passing it to the
function. This allows to make further changes to the function which
require more data from the context.
This moves the allocation of the GPtrArray to the caller which will
become useful in a future commit because another function can add more
elements to the same array.
If the internal_tests option is enabled we build some internal tests
into the binary. These are added to the tests we run in testlibrary.
This is not intended to be enabled in production, as it adds size to
the real binary, but is useful for CI and development.
This makes it possible to pass arguments to g_test_init via mesons
--test-args. This can be useful when one wants to run a single test with
`meson test testlibrary --test-args='-p /context'.
This will pass the exact appstream component ID to copy_icon
This was introduced in 7dd92d8a9be2e14313e2cda7dea44298fbb005a4 to
handle appstream component IDs that ended in two `.desktop` suffixes.
Recent analysis of appstream data shows that at least on Flathub no such
appstream cid exist anymore and Telegram now has component ID
`com.telegram.desktop`.
With the switch to libappstream, appstreamcli-compose produces icons in
`share/app-info/flatpak` named by the appstream component ID instead of
the `$FLATPAK_ID` used by appstream-glib. This causes applications whose
`$FLATPAK_ID` does not end with `.desktop` but their appstream-component
ID ends in `.desktop` ie. `$FLATPAK_ID != appstream-cid` to loose icons
from the appstream ostree ref as `copy_icon` was being fed the id
without `.desktop` but icons were created by appstreamcli
with `.desktop` in them.
This will avoid adding anymore ID heuristics/workarounds on either side,
per the discussion in [1].
An application with the `$FLATPAK_ID` `com.telegram.desktop` and the
appstream ID `com.telegram.desktop.desktop` will be broken with this
change but such dual `.desktop` IDs are non existent and should be fixed
individually or be blocked on an app store level.
[1]: https://github.com/flathub/flathub/issues/4222
Instead of clearing the environment that we spawn the flatpak executable
with, we use the new --clear-env. For environment variables that we
inherit from the calling instance, we append them as arguments after the
--clear-env so it starts from a clean slate.
Closes: https://github.com/flatpak/flatpak/issues/5271
Upstream/vendor configuration files should be installed under /usr/,
so that local users/admins can install overrides in /etc/.
Distributions like Ubuntu are already manually configuring this,
so just make it the default.
Fixes c75ba1c7e1587300be9a418116c02d0b6bf8b34e
```
In file included from /usr/lib/aarch64-linux-gnu/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:34,
from /usr/include/glib-2.0/glib/galloca.h:34,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gbinding.h:30,
from /usr/include/glib-2.0/glib-object.h:24,
from /usr/include/glib-2.0/gio/gioenums.h:30,
from /usr/include/glib-2.0/gio/giotypes.h:30,
from /usr/include/glib-2.0/gio/gio.h:28,
from ../common/flatpak-utils-http.c:23:
In function ‘glib_autoptr_clear_GFileEnumerator’,
inlined from ‘glib_autoptr_cleanup_GFileEnumerator’ at /usr/include/glib-2.0/gio/gio-autocleanups.h:69:1,
inlined from ‘flatpak_get_certificates_for_uri’ at ../common/flatpak-utils-http.c:284:34:
/usr/include/glib-2.0/glib/gmacros.h:1361:10: warning: ‘enumerator’ may be used uninitialized [-Wmaybe-uninitialized]
1361 | { if (_ptr) (cleanup) ((ParentName *) _ptr); } \
| ^
/usr/include/glib-2.0/glib/gmacros.h:1379:3: note: in expansion of macro ‘_GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS’
1379 | _GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS(TypeName, TypeName, func)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/gio/gio-autocleanups.h:69:1: note: in expansion of macro ‘G_DEFINE_AUTOPTR_CLEANUP_FUNC’
69 | G_DEFINE_AUTOPTR_CLEANUP_FUNC(GFileEnumerator, g_object_unref)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../common/flatpak-utils-http.c: In function ‘flatpak_get_certificates_for_uri’:
../common/flatpak-utils-http.c:284:34: note: ‘enumerator’ was declared here
284 | g_autoptr(GFileEnumerator) enumerator;
```
