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.
Currently network is used during build time because of pip fetching from
internet.
However network should not be used during build time.
To fix this issue, use gcovr.json generated by flatpak-pip-generator
and replace them with gcovr module in org.gnome.Nautilus.json and
org.gnome.Nautilus.yml and remove build option that uses network.
Closes issue https://gitlab.gnome.org/GNOME/nautilus/issues/681
Builder keeps trying to format the JSON automatically for any change,
which is quite cumbersome since it appears as a changed file on git and
also it's a mess if an actual change happens.
Just accept the defeat and go with whatever Builder wants.
The YAML files already use the gitlab URLs, while the json doesn't.
The gnome-apps-nightly build script reads the json file, and the
builds have been failing because of this.
Update the json file accordingly.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/485
So far we have been building master of all of our dependencies, also
master of the Sdk. This is good for testing the next version of the
ecosystem, but has many downsides that we now can avoid with Flatpak.
For instance, we want to be buildable at any point in the history,
specially when doing bisects. Also, we need to be a bit stable so that
when designers, users or others build the latest Nautilus they are able
to work with it regardless of its dependencies on other projects.
Even more, now with CI we can test the master of the ecosystem regularly
while not affecting our regular development and operations by depending
on that.
So let's separate in two different manifests the development version
with stable dependencies, intended for our regular operations, and a
development version with all the ecosystem on master, to test the
ecosystem regularly on the CI or on-demand locally.
This is one of prerequisite steps to take before fully switching to GTK+
4, as gnome-desktop has code, depending on GTK+ 3. Since the
thumbnailing machinery is self-contained, it can easily be just copied
over.