We don't need to check for GLib 2.44 (the first release with g_autoptr()
support) since Flatpak requires that version in configure.ac.
Fixes https://github.com/flatpak/flatpak/issues/3403
In flatpak_dir_create_origin_remote() we reload the repo config after
adding an origin remote to it, but this only applies to the FlatpakDir
object used. In the case of flatpak_transaction_add_ref(), there is
another FlatpakDir object in the installation (priv->installation) which
needs to also be reloaded using flatpak_installation_drop_caches(). So
add a boolean out variable to flatpak_dir_create_origin_remote() and use
it to determine if it's necessary to call
flatpak_installation_drop_caches() (because if the origin remote already
exists we don't create another).
This commit also makes related changes at the other call sites of
create_origin_remote() (some indirectly via
flatpak_dir_ensure_bundle_remote()):
- in flatpak_dir_ensure_bundle_remote(), only set the out variable
created_remote to TRUE if a new remote was actually created
- in flatpak_installation_install_bundle(), only drop the installation
caches if a new remote was actually created
- in flatpak_transaction_resolve_bundles(), drop a redundant
flatpak_dir_recreate_repo() call and only drop installation caches
when necessary
Without these changes, this unit test failure occurs:
ERROR: testlibrary - Bail out!
flatpak:ERROR:tests/testlibrary.c:3311:test_transaction_install_local:
assertion failed (error == NULL): Remote "hello-origin" not found
(flatpak-error-quark, 7)
In test_transaction_install_local(), we test that the origin remote
created when installing from a local repo doesn't exist before
flatpak_transaction_run() is executed and does exist afterward. However,
the origin remote is created before the transaction is run; see the
flatpak_dir_create_origin_remote() call in
flatpak_transaction_add_ref(). The only reason this discrepancy has not
caused a test failure is that the FlatpakDir object held by the
FlatpakInstallation object is not reloaded when the origin remote is
added (so it's reading an old copy of the repo config). This issue will
be fixed in the commit following this one.
Fixes the missing 'app' directory:
Traceback (most recent call last):
File "/data/dwrobel1/rdkv/rpi-flutter-3/build-raspberrypirdkhybrefapp/tmp/sysroots/x86_64-linux/usr/bin/gdbus-codegen", line 39, in <module>
sys.exit(codegen_main.codegen_main())
File "/data/dwrobel1/rdkv/rpi-flutter-3/build-raspberrypirdkhybrefapp/tmp/sysroots/x86_64-linux/usr/share/glib-2.0/codegen/codegen_main.py", line 186, in codegen_main
h = open(c_code + '.h', 'w')
FileNotFoundError: [Errno 2] No such file or directory: './app/flatpak-permission-dbus-generated.h'
make: *** [app/flatpak-permission-dbus-generated.c] Error 1
make: *** Waiting for unfinished jobs....
It was called flatpak_exports_add_home_expose(), but it actually
exposed the entire host filesystem, to the extent possible.
Rename it to flatpak_exports_add_host_expose() to reflect that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Don't allow adding access to things like ~/foo xdg-foo/bar or similar
things just because you used to have home access, because such files
may be outside the homedir (for instance, if they are symlinks or configured
via xdg-user-dirs).
In flatpak-builtins-build-commit-from.c we call flatpak_repo_collect_sizes()
without initializing the passed in download size to zero, which mean
we sum with sizes with some random value as the start.
This is fixed by having flatpak_repo_collect_sizes() always initialize
the counters to 0 at the start.
Fixes https://github.com/flatpak/flatpak/issues/3362
This new permission exposes the host /dev, which is normally not visible
even with --device=all, as it is not really a device node but rather
a bunch of shared memory blocks available on the host.
This access is needed by jack, as explained at:
https://github.com/flatpak/flatpak/issues/1509
Long term I think a better solution for pro audio (like pipewire) is
a better solution, but for now we should at least allow jack apps to work.
Initialize the related-refs array with empty GPtrArray so that if
the remote has 'url= ' (for e.g., in case of flatpak bundle's remotes),
a empty array is returned instead of NULL.
(NULL mostly implies a operation has failed and error is set)
Also, this syncs the implementation of `if (*url == 0)` with
that of flatak_dir_find_remote_related_for_metadata function.
While flatpak carefully doesn’t expose any OSTree symbols in its C API,
it does sometimes return GErrors with the domain `OSTREE_GPG_ERROR`.
Applications can happily link against flatpak and receive such errors,
but won’t be able to understand them without also linking against
OSTree.
OSTree is a hard dependency of flatpak, so we might as well move it to
`Requires` rather than `Requires.private` to ensure that clients link
against it.
See https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/336/diffs#note_650999
Signed-off-by: Philip Withnall <withnall@endlessm.com>
