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.
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.
When hacking on Nautilus, it is very inconvenient to have to close any
running instance before running the built version. This commit enables
running three different instances by changing the application ID.
Beside the default “profile” is one crafted for stable flatpak
releases and one for development. The stable flatpak profile adds an
identifying mark to the about dialog to aid collecting information in
bug reports. The development profile is that plus additional styling to
help visually identify the development instance. It also will be used
when generating Flatpak bundles with the help of CI.
Generally, the implementation is slightly hacky to allow all the
different workflows, spanning from regular installations to GNOME
Builder flatpak builds, as each comes with its own quirks.
So we can actually enter the environment and run ninja test and other stuff.
This is pretty handy for development, and our main flatpak manifest is for that
use.
Nautilus as a file manager needs access to the whole file system, for
that there is a value called "host" which allows direct access to it.
Use it instead of just access to home.
Closes#201
