GitLab

This command collects the various commandline utilities that
are currently shipped in gvfs, and unifies them under a single,
command-style binary.

The tools just use GIO APIs, so it makes sense for them to live here.

There was a stray 'of' here.

https://bugzilla.gnome.org/show_bug.cgi?id=744456

This makes them easier to identify when debugging and profiling.

This patch was somewhat less than interesting to write.

https://bugzilla.gnome.org/show_bug.cgi?id=767765

This will be useful for printing out GPids in printf()-style functions.

https://bugzilla.gnome.org/show_bug.cgi?id=767765

Apply the same changes as in commit
7563ab47 to gio/Makefile.am.

https://bugzilla.gnome.org/show_bug.cgi?id=725902

In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.

This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).

A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264

https://bugzilla.gnome.org/show_bug.cgi?id=662802

Even if systemtap is not enabled in configure when running distcheck.

https://bugzilla.gnome.org/show_bug.cgi?id=662802

The list of supported schemes is not known at compile-time, so it is
wrong to iterate the list with G_N_ELEMENTS() and we miss all but the
first scheme. Fix by checking for the %NULL sentinel instead.

https://bugzilla.gnome.org/show_bug.cgi?id=768119

The function is expected to return a %NULL-terminated array, but
commit 375b4ca6 dropped the sentinel when adding support for
additional custom schemes. Add it back.

https://bugzilla.gnome.org/show_bug.cgi?id=768119

Add filesystem attribute to detect remote filesystems in order to
replace hardcoded filesystem types in GtkFileSystem. Set this attribute
also for GLocalFile appropriately.

Bump version to 2.49.3, so that early adopters of new API have a version
number to target.

If none of the closures in the hash table return a non-null value, the
loop never ends. Since the end of the hash table has been reached at
that point, g_hash_table_iter_next() starts asserting.

The possible fix is making the return value of g_hash_table_iter_next()
the condition in the loop.

https://bugzilla.gnome.org/show_bug.cgi?id=768029

Add a new API to allow clients to register a custom GFile implementation
handling a particular URI scheme.
This can be useful for tests, but also for cases where a different URI
scheme is desired to be used with another custom GFile backend.

As an additional cleanup, we can use this to register the "resource" URI
scheme too.

Based on a patch by Jasper St. Pierre <jstpierre@mecheye.net>.

https://bugzilla.gnome.org/show_bug.cgi?id=767887

(cherry picked from commit 7cb5b02e)

5cea1c86 introduced accessors for 64bit
ints to gsettings, at which point the testcases were expanded.

Unfortunately, the expanded tests contained a bug: integer constants
passed to g_object_set() for a 64-bit property need an up-cast.  Add
that now.

Problem found by Iain Lane.

The probes.d file should be distributed even if GLib is build with
dtrace disabled. This is what’s done in the glib and gobject
directories.

This makes it easier to use GKeyFile from language bindings, and makes
the API more consistent and modern with the new data type available in
GLib.

https://bugzilla.gnome.org/show_bug.cgi?id=767880

The ability to pass libtool via $(CC) to dtrace and have it respect this
appears to be a feature that is only present in the systemtap version of
the tool.  In particular, FreeBSD (which seems to be using a copy of the
tool from Solaris) doesn't support this.

The result is that, with $(CC) ignored, and a .lo file specified in -o,
we get an ELF written to the .lo.

Instead of trying to have dtrace run libtool we can have libtool run
dtrace.  dtrace is really just a compiler that produces an object file
here, and it even understands -o, so libtool can make the appropriate
adjustments.

There appears to be some prior art for this approach.  A quick search
shows that at least QEMU is using this approach.  It also appears to
work on Linux with systemtap's dtrace and on FreeBSD.

This may regress cross-compilation because the dtrace command will have
no way of knowing which compiler we intend for it to use to produce the
object file.  I say "may" because I don't know if dtrace ever worked in
the first place under cross-compilation.

https://bugzilla.gnome.org/show_bug.cgi?id=725902

The previous update did not account for when no exec_prefix is spcified,
so update that, and use ${prefix} by default.  Clean up a bit as well.

The condition removed erroneously excluded UTC-based and DST-less
timezones and so left the GArray with no contents, so GTimeZone functions
returned whatever random garbage was in memory.

g_close() does not have G_GNUC_WARN_UNUSED_RESULT, so these casts are
unnecessary.

If a backup file is created, opened successfully, then fstat() on it
fails (perhaps due to another process deleting it in the mean time?),
the FD will be leaked.

Coverity issue: #1159485

https://bugzilla.gnome.org/show_bug.cgi?id=730187

This adds a basic tapset for GIO, covering various interesting parts of
GTask.

https://bugzilla.gnome.org/show_bug.cgi?id=759813

Expand the set of available probes, and add a few more output parameters
to some of the existing ones to make them more useful. I do not know if
this breaks any existing stability guarantees for GLib’s SystemTap
tapset, as it is effectively just adding some more local variables in
the user’s probe.

https://bugzilla.gnome.org/show_bug.cgi?id=759813

Previously this would cause an assertion failure when checking the paths
of exported objects, as it would try to check that their paths started
with ‘//’ due to mishandling the root object case.

Includes a unit test.

https://bugzilla.gnome.org/show_bug.cgi?id=761810

These differentiate between strings in the GLib filename encoding, and
strings in UTF-8.

https://bugzilla.gnome.org/show_bug.cgi?id=700756

These differentiate between strings in the GLib filename encoding, and
strings in UTF-8.

https://bugzilla.gnome.org/show_bug.cgi?id=700756

Add it to g_application_command_line_get_cwd(). Also add a clarifying
internal comment about the cwd private member.

https://bugzilla.gnome.org/show_bug.cgi?id=700756

Also use size_t rather than int, allowing for larger files to be
handled.

https://bugzilla.gnome.org/show_bug.cgi?id=700756

proxy->priv->name_owner gets overwritten in async_init_data_set_name_owner() on the
assumption that it will always be NULL when we get there. However,
on_name_owner_changed() can run first, and it does set name_owner.

==20126== 42 bytes in 6 blocks are definitely lost in loss record 15,174 of 48,256
==20126==    at 0x4C280F3: malloc (vg_replace_malloc.c:299)
==20126==    by 0x7541D00: g_malloc (gmem.c:104)
==20126==    by 0x7558FEE: g_strdup (gstrfuncs.c:364)
==20126==    by 0x6DF8E4F: on_name_owner_changed (gdbusproxy.c:1399)
==20126==    by 0x6DE94C4: emit_signal_instance_in_idle_cb (gdbusconnection.c:3743)
==20126==    by 0x753C315: g_main_dispatch (gmain.c:3066)
==20126==    by 0x753C315: g_main_context_dispatch (gmain.c:3642)
==20126==    by 0x753C667: g_main_context_iterate.isra.24 (gmain.c:3713)
==20126==    by 0x753CA69: g_main_loop_run (gmain.c:3907)
==20126==    by 0x5E38000: meta_run (main.c:556)
==20126==    by 0x401EC0: main (main.c:441)

https://bugzilla.gnome.org/show_bug.cgi?id=755439

Allow the use of shorthands using ${prefix} for exec_prefix, and
${exec_prefix} for includedir and libdir, which makes the generated .pc
files a bit cleaner and more flexible.

For the Visual Studio 201x projects, we can force the "install" projects
to always run in a simpler way, by specifying an output file that will
never exist.  Makes things look a bit cleaner.

We may not have $(CopyDir) created, which the script that generates the
.pc files check for, so create it if it is not there.  This makes things a
bit more convenient for people.

Revert all annotation changes for environment variables and command line
arguments.

See commit f8189ddf.

Revert all annotation changes for environment variables and command line
arguments.

See commit 41013a01.

Visual Studio actually supports long long types, but HAVE_LONG_LONG is
undefined for Visual Studio builds, likely due to issues in previous
gnulib code for printf functionality, that was bundled with GLib.

Since gnulib has much better support with Visual Studio nowadays (which we
updated the related code to last October), and HAVE_LONG_LONG being undefined
actually causes issues in Visual Studio builds, which was demonstrated with
the type-test test program in tests/, we should always define HAVE_LONG_LONG
in config.h.win32.in.

Thanks to Paolo Borelli for the heads up on the issue.

https://bugzilla.gnome.org/show_bug.cgi?id=767245

Adds the filename annotation for all file names
and things which can contain file names like
environment variables, argv-

On Unix they can contain anything while on Windows
they are always utf-8.

https://bugzilla.gnome.org/show_bug.cgi?id=767245