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
This pins versions of most dependencies, uses quotes for strings and
removes header cleanup from GTK+ module, because CI pipelines choke on
them being absent when ninja decides to rebuild everything when running
tests.
(cherry picked from commit a9f13fc91f7319b318e75a95a89918e9cadf94cf)
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.
Instead of checking explicitly for some options, we allow any value as
profile and assume is a development snapshot.
This will help with having Flatpak bundles/refs of different branches
with different purposes.
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.
Recently we have been seeing that gsettings doesn't work inside the
Flatpak build of Nautilus.
In 3f6cd2feb2
we gave full host access to Nautilus, so I expected that no more
--filesystem permission would be necessary.
For some reason... we still need to put that. Although it looks like a
bug somewhere.
For now, let's just explicitly allow access the desrt folder.