landlock is set to auto, but that causes our pipelines to fail because
when landlock.h is detected, but is disabled in the kernel, the build
errors. The suggested route is to use explicit build options.
Related: https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/508
It has recently started to depend on unstable version of tracker-sparql
e02ecb3171
In due time, that should be available in the SDK, but we are moving to fast to wait for that, so let's unblock our CI pipeline.
Nautilus uses NautilusPreviewer regardless of if we are using the
development or default profile. Now that Sushi has introduced a
nightly version, let's default the Nautilus nightly version to use
Sushi nightly when available. If NautilusPreviewerDevel is not
available then fall back to NautilusPreviewer
vala bindings were removed in [1] which is causing out pipelines to
fail. We don't need them anyways, so disable the build options for
libportal and libcloudproviders.
[1] 6a9ed593d3
At some point, the flatpak command line interface changed so it is not
possible to add multiple values to a same key with a single --add-policy
call. Doing this now results in a single value added, with the ';'
escaped, this breaks Tracker portal access and results in Nautilus resorting
to the built-in miner instance.
It is however possible to call --add-policy multiple times to make
a multi-valued key, this restores the intended behavior and provides
access to the two tracker:FileSystem and tracker:Documents graphs.
Adapt the flatpak manifest to do this.
Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2838
The `--talk-name=org.gtk.vfs` statement should not be used in manifests
as there is no service with such name. The `--talk-name=org.gtk.vfs.*`
statement should be pretty enough for the GVfs access. See:
https://docs.flatpak.org/en/latest/sandbox-permissions.html#gvfs-access
Let's drop that statement.
The flatpak jobs are broken currently, because the tracker-miners project
fails to build due to missing upower-glib depenedency. It is used to tweak
the behavior when running on battery. It used to be automatically disabled
until the following MR:
https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1121. I suppose
it is safe to disable this functionality as our flatpak isn't meant for
production. Let's explicitely disable that to fix our pipeline.
When unmounting a volume from the sidebar, there's a feature to also
empty the trash, which is crashing because of an x11 dependency in
GTK. It turns out that that dependency is only if you can't
communicate with the org.gtkMountOperationHandler dbus interface.
Add talk-name to the flatpak manifest.
filesystem=host blacklists /tmp. We are going to want to
save a temporary archive for the Email To function.
If we save it outside of the /tmp directory, it could
end up wasting a lot of disk space. Allow access
to /tmp
Nautilus launches external programs (i.e. Settings & gnome-disks)
directly via the commandline which doesn't work in flatpaks.
Create new module nautilus-dbus-launcher to allow for launching
these programs via DBus. nautilus-application holds ono a
singleton instance of the dbus launcher (similar to undo manager
and tag manager) so we don't need to create proxies over and over again.
By giving the --device=dri permission, Nautilus can access
the GPU. This wasn't a big deal with GTK3, but on GTK4 that
enabled hardware-accelerated rendering via OpenGL, and it
makes a noticeable difference in terms of CPU usage and
perceived performance.
libportal changed the name of their primary branch to
`main`. `flatpak` can't automatically handle `main`,
so we need to specify it manually.
Should fix the recent CI failures.
The new major version of the toolkit is a requirement to fix old issues and enable future enhancements.
Update symbols and adapt logic to API changes.
Update and simplify UI definitions.
Update local copy of places sidebar and places view.
Replace dependencies with their GTK4-compatible successors.
Make a minimum changes required to build and run, with known
regressions to be fixed in future commits.
For a detailed breakup of the changes, see the 36 commits-deep
log leading to d5763facb1e5045251171ed1273dca0859f3542f.
This is the main part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/276
Build log contains deprecation warnings for gexiv2 functions.
Replaced `gexiv2_metadata_has_tag()` with
`gexiv2_metadata_try_has_tag()` and `gexiv2_metadata_get_orientation()`
with `gexiv2_metadata_try_get_orientation()`
Closes: #2033
Changes in libportal main branch break the CI and require dependency
changes which we shouldn't make on stable branch.
(cherry picked from commit 67927cb09b)
The flatpak build currently fails because of gexiv2 build failure, which is
a problem for our contributors and among others breaks our CI pipeline. The
potential fix is available already for a couple of days on
https://gitlab.gnome.org/GNOME/gexiv2/-/merge_requests/63 but not yet merged.
Let's temporarily pin the gexiv2 and exiv2 dependencies to the stable branches
to fix those issues.
We already disable introspection, which is required by the vapi and
python3 options.
We don't really on either and this is breaking the CI.
(cherry picked from commit 46579d08b0b1183aa36544e0e949a6d42c53ce84)
The build log contains warnings about deprecated gexiv2 functions. Let's
port to the new API, unpin exiv3 and gexiv2 dependencies in flatpak manifests
and bump the build dependency accordingly to get rid of the warnings.
The network access is no more needed for gvfs support as it currently
uses named sockets instead of abstract ones. It is enough to allow access
to `xdg-run/gvfsd` folder, where the named sockets reside. I'm not aware
of other reasons for allowing network access. Let's drop the network
access. This also workarounds "Too many open files" errors caused by
leftover sockets (GNOME/gvfs#542).
Relates: https://gitlab.gnome.org/GNOME/gvfs/-/issues/515
Tracker 3 is provided in the Flatpak SDK, see
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/630.
We still build tracker-miners inside the Flatpak bundle, so that the
org.freedesktop.Tracker3.Miner.Files settings schema is available, and
so that the tests that depend on Tracker can pass as part of the CI
build.
Access to the host's miners is controlled by the new
org.freedesktop.Tracker.portal process provided in Tracker 3.
We've pinned to specific versions, because their
git master branches have API-breaking changes.
Instead, let's follow from the tracker[-miners]-2.3 branches, where
the stable API is still maintained.
tracker-miners master requires tracker-testutils 2.0, but they are not
provided by tracker 2.3.2 and tracker master provides just version 3.0.
Let's use tracker-miners 2.3.2 to workaround this issue.
Flatpak generation fails currently because tracker-miners still requires
tracker API version 2.0. Let's use tracker 2.3.2, until tracker-miners
will be ported to 3.0.
I don't see any reason to manually specify libdir for tracker as
it seemingly uses the same directory by default. Let's remove that
redundant definition.
We are near 3.36, so let's update the dependencies.
gexiv2 git master is failing to build locally, so I've
updated it to the latest tag that builds locally.
The prefix is not localized, and tends to ellipsize the name.
With the introduction of an icon for the development profile, there is
enough visual distinction in the app grip.
So, drop the prefix.
Part of https://gitlab.gnome.org/GNOME/Initiatives/issues/12
We were using the xdg directories to check whether we can star a file
or not, since the star feature only works on directories that are
tracked by tracker.
Tracker is usually shipped in distributions tracking the
xdg-directories, so we check that as a stop gap solution for 3.30
since we didn't have time to actually query what directories tracker
is tracking and match that.
This work makes it so that we show the star action on tracked
directories.
