GVfs communicates with daemons over abstract sockets. Currently, synchronous
GIO API doesn't work for GVfs locations, because abstract sockets seem to be
blocked by sandbox permissions. This is not problem in most cases as Nautilus
uses asynchronous API usually. But this breaks e.g. "Empty Trash" functionality
as it is for some reason based on synchronous API.
In order to fix this problems, it is necessary to allow access to sockets
beginning with `unix:abstract=/dbus-vfs-daemon/socket-`, but I am not aware of
better way than adding `--share=network`, which allows access to all abstract
sockets:
http://docs.flatpak.org/en/latest/sandbox-permissions-reference.html#f2
Just a note that it is not clear to me, why it affects only the synchronous
API as the asynchronous API also uses abstract sockets. See the corresponding
Flatpak bug:
https://github.com/flatpak/flatpak/issues/2711
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.
builddir: true is assumed always whenever the buildsystem is meson.
libdir no longer needs to be specified, and cmake was patched to
be able to deal with lib64. See [1] for more.
[1]: https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/77
This seems to have been broken for a while now cause by default
it tries to install a python overide in the python shared packages
in /usr, but this is immutable since it comes from the runtime.
This patch disables that.
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.
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
