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.
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
The script broke after killing off Autotools support, since the libgd
submodule was moved to /subprojects/libgd. Additionally, this commit
makes the script exit on error and makes xz print verbose output.
https://bugzilla.gnome.org/show_bug.cgi?id=781892
As of 0.40.0, Meson has the ability to initialize subprojects that are
git submodules. This removes the need for a separate script to achieve
that.
https://bugzilla.gnome.org/show_bug.cgi?id=781653
Meson looks for subprojects in subprojects/ by default. Since Autotools
is no longer a resident here, the submodule should be moved to the
subdirectory, instead of being linked to.
https://bugzilla.gnome.org/show_bug.cgi?id=780501
