| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
gnome-build-meta is manual job as it takes some time. However, let's
run this job when the new tag is created to be sure that the release
is ok.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the default port - specified in mount file - is removed from
uri on client side, but it is not used by backend explicitely. It is not
a problem until the default port is changed in sshd_config and somebody
wants to connect to the server using the default port from mount file.
Let's use the port 22 explicitely, similarly as other backends do (i.e.
ftp, afc, afp).
Closes: https://gitlab.gnome.org/GNOME/gvfs/issues/129
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The set of daemons is a large list of executables to be built. To
ease its build an array of arrays was created, but this harms
readibility.
This has been improved by the use of the new dictionary types[0] and
the possibility of using a dictionary as a parameter in target
objects[1].
The individual dependencies have been moved directly to the new
dictionary because it remains clear their meaning.
[0] http://mesonbuild.com/Release-notes-for-0-47-0.html#new-builtin-object-type-dictionary
[1] http://mesonbuild.com/Release-notes-for-0-49-0.html#can-specify-keyword-arguments-with-a-dictionary
|
|
|
|
|
| |
man file building has been simplified by taking advantage of meson
arrays and generators placeholders.
|
|
|
|
|
|
| |
The use of an extra variable can be avoided and still maintain
readibility when checking compiler flags, so the build commands
have been changed.
|
|
|
|
|
|
|
|
|
| |
The used meson modules, default directories and includes have been
moved to the start of the build file, just after project related
information, so they are available early.
The way `po` directory path is defined has also been changed to
avoid the use of the `source_root` function.
|
|
|
|
|
|
|
|
|
| |
Although usually directory variables are set by using the `prefix`
directory, this might cause issues due to parameters that need
relative directories.
In order to ease the transition `prefix` directory has been stripped
from directory variables and only has been appended when necessary.
|
|
|
|
|
|
|
|
|
|
|
| |
When gvfs was ported to meson `gdbus-codegen` was not able to
generate the source and header files independently, and this caused
issues on highly parallelized build.
To avoid this issue a workaround was placed by using an external
script. However, recently glib and meson acquired support for
generating source and header files independently, so the
workaround has been removed.
|
|
|
|
|
|
|
|
|
|
| |
Functions derived from generators as `configure_file`,
`custom_target` and `i18n.merge_file` can use placeholders like
`@BASENAME@` that removes the extension from the input filename
string.
The output string has been replaced by this placeholder that
allows in some cases the use of less variables.
|
|
|
|
|
|
|
| |
The `install` and `install_dir` parameters must be the last
parameters in the `configure_file` function.
The paremeters have been reordered to fix this issue.
|
|
|
|
|
|
|
|
|
| |
The names of the variables in meson corresponding to the variables
obtained from the pkg-config files has been fixed by using a
pattern.
The pattern uses the dependency name as the prefix and the obtained
variable as the suffix.
|
|
|
|
|
|
|
| |
Since meson 0.49, the `/` character can be used to join paths[0], so
all the instances of `join_paths` have been replaced.
[0] http://mesonbuild.com/Release-notes-for-0-49-0.html#joining-paths-with-
|
|
|
|
|
|
|
|
|
|
| |
meson 0.49 has gained support for `libgcrypt-config` when using the
`dependency` function[0], so there is not need to call to it from
build files.
The minimum required meson version has also been bumped to 0.49.
[0] http://mesonbuild.com/Release-notes-for-0-49-0.html#libgcrypt-dependency-now-supports-libgcryptconfig
|
|
|
|
|
|
|
| |
Add missing trailing commas that avoids getting noise when another
file/parameter is added and eases reviewing changes[0].
[0] https://gitlab.gnome.org/GNOME/dconf/merge_requests/11#note_291585
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the available monitors install a set of files: volume monitor
files, DBus service files, etc...
These build commands are mostly common and only file names change,
which are built using a given pattern. These build commands have
been replaced by only one set of build commands that adapt to
monitors needs by changing their name and simplifies the entire
process.
These changes also help installing `GOA` and `MTP` necessary test
files.
|
|
|
|
|
| |
`gvfs_bindir` and `gvfs_includedir` are not used in any meson's
build files so they have been removed.
|
|
|
|
|
|
| |
Currently, out CI fails on forks, because $CI_REGISTRY_IMAGE doesn't
point to the origin and thus is empty. See relevant upstream bug report:
https://gitlab.com/gitlab-org/gitlab-runner/issues/1867
|
|
|
|
|
|
| |
This patch finally integrates our test suite in GitLab CI. Unfortunately,
many tests are skipped currently, because I was not able to make them work
in the Docker container yet.
|
|
|
|
|
|
|
|
|
|
|
| |
Recently, several patches had to be reverted because of too old meson
version in gnome-build-meta. Let's add gnome-build-meta job to prevent
similar problems in the future. The job is based .gitlab-ci.yml from
gnome-build-meta repository. I made some experiments to run it from
our Docker image including pregenerated buildstream cache, but it was
unexpectedly slower and also made the image too big. I am making the
job manual, because is quite slow and also it is not necessary to run
it always.
|
|
|
|
|
|
| |
Add a manual job to regenerate Docker image used by CI into GitLab CI
and use image with :latest tag by default. In case of some failures,
one can always use another tag.
|
| |
|
| |
|
|
|
|
|
|
| |
Update message for org.gtk.vfs.file-operations-helper action in
polkit org.gtk.vfs.file-operations.rules file to be obvious that it is
used when starting gvfsd-admin.
|
|
|
|
|
| |
Add comments to polkit org.gtk.vfs.file-operations.policy file explaining
the purpose of the different actions.
|
|
|
|
|
|
| |
Add comment to polkit org.gtk.vfs.file-operations.rules file explaining
the rule which allows starting gvfsd-admin without password for users
belonging to wheel group.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The backend currently allows to access and modify files without prompting
for password if any polkit authentication agent isn't available. This seems
isn't usually problem, because polkit agents are integral parts of
graphical environments / linux distributions. The agents can't be simply
disabled without root permissions and are automatically respawned. However,
this might be a problem in some non-standard cases.
This affects only users which belong to wheel group (i.e. those who are
already allowed to use sudo). It doesn't allow privilege escalation for
users, who don't belong to that group.
Let's return permission denied error also when the subject can't be
authorized by any polkit agent to prevent this behavior.
Closes: https://gitlab.gnome.org/GNOME/gvfs/issues/355
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue has been sitting around for ages without us understanding
what's going on. We finally got a repro scenario which showed that
it happens when another program steals the MTP device out from under
us, so that all MTP calls will start failing. In this case it's clear
that it's futile to keep trying to retry reading the event after a
failure.
I originally wrote the code to retry the read because I expected any
error to be transitory, but if the error is persistent, it's not good
behaviour - even if the memory leak was fixed (as you'd still be
busy-waiting in a tight loop).
So, given the situation, and the fact that I'm not aware of any
occurence of transitory event read failures, let's just say that
if an event read fails, we'll give up and the event is lost.
Note that I'm still not aware of the exact situation where the
problem was first observed (the reporters did not talk about
the use of VM software stealing devices) and so fixing this may
still result in them seeing a situation where they can't access
the device due to whatever the underlying cause is.
Closes: https://gitlab.gnome.org/GNOME/gvfs/issues/347
|
| |
|
| |
|
|
|
|
| |
This reverts commit 00b87d1f7119bbfb0e16eb3bc2fc24d3b8776d3a.
|
|
|
|
| |
This reverts commit c25bc351bb2605e57bc9a6d9250c9d4748c3d9e0.
|
|
|
|
| |
This reverts commit f4ee93b06cfc4d9f727f9174e40d08097a25d571.
|
|
|
|
| |
This reverts commit 5bc63310a721946199c68160b5134971d5fe0fc6.
|
|
|
|
| |
This reverts commit 9523d8e09e0088c8cd58ace494d47cc3083151fc.
|
|
|
|
| |
This reverts commit 22e9f7721b891b17cd726f1bf92b15a35be34d22.
|
|
|
|
| |
This reverts commit 12f4c5a98e1b4a1a0b5fba45439dab74d12519bb.
|
|
|
|
| |
This reverts commit dc34f1be6a3c1fa6d5615ad5d647003e7ce3196f.
|
|
|
|
| |
This reverts commit 32bde011b2522d302d72506884866bd809ef5bda.
|
|
|
|
| |
This reverts commit db31059d1b7b11b597b03064329fb1e8899b11f2.
|
|
|
|
| |
This reverts commit 28dfdbf9c759a4681c6b43b179079cba09e571b4.
|