GitLab

Visual Studio 2008 does not come with stdint.h, so define intmax_t instead
on Visual Studio 2008 so that the code will continue to build.  This was
previously unnoticed as building GTK+ since 3.16 requires an
implementation of stdint.h (such as msinttypes), and it took care of the
need of including the stdint.h header here, but people could be very well
using GLib without using GTK+ 3.x.

glib installs a gdb helper file named `glib.py`.
Then the "hook" file updates `sys.path` and does `import glib`.

This will fail if glib has already been imported into gdb, say
using `from gi.repository import GLib`.  This is due to a namespace clash.

One fix would be to rename the gdb helper files to not clash with
other Python modules.  This should be done for all such helper files.

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

(cherry picked from commit 67ce4d8c)

Commit 7b3f6da3 broke ABI compatibility, because of newly added vfunc.
Move the vfunc to the end to ensure ABI compatibility.

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

So that early adopters of new API have a version number to target.

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

Nautilus wants to show entries in the sidebar only for removable devices.
It uses currently sort of conditions to determine which devices should be
shown. Those condition fails in some cases unfortunatelly. Lets provide
g_drive_is_removable() which uses udisks Removable property to determine
which devices should be shown. It should return true for all drives with
removable media, or flash media, or drives on usb and firewire buses.

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

Since hal is dead and buried, and has been superseded by the udisks2
modules in GVFS.

This was causing anything listed in $(installed_test_extra_scripts) to
not be installed.

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

Fallback code for g_date_time_format_locale() fetches translated
strings (such as day and month names) from .mo catalogues via
gettext. These strings always come in UTF-8 encoding, because
that is the encoding that glib sets when it initializes gettext
for itself.
However, the non-fallback code uses nl_langinfo() and expects
its results to be in locale-dependent encoding.

This mismatch can result in UTF-8 strings being converted to UTF-8,
producing gibberish.

Fix this by converting UTF-8 strings to locale-dependent encoding
before using them. Also fix the code that was already doing the locale->UTF-8
conversion to not convert the strings when they are already UTF-8-encoded.

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

This prevents testsuite from trying to build any TESTS in that
subdirectory, which will fail, because there are no TESTS defined
in that Makefile.am.

This happens when user runs make check TESTS=...

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

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

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

There is no need to call g_variant_builder_clear() after the
g_variant_builder_end(). This is mentioned in docs of the former
function, but not in the docs of the latter one. Add them there too.

asan noticed an array out of bound access in this function, which was
because we were accessing G_N_ELEMENTS + 1.

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

Instead of finding the GSequence, just walk up
the tree and determine if the iter is the end node.

https://bugzilla.gnome.org/show_bug.cgi?id=749583Signed-off-by: Garrett Regier <garrettregier@gmail.com>

Explicitly suggest to use g_main_context_pop_thread_default() when there's no
user control on the life cycle of the thread being used.

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

This adds a new --c-generate-autocleanup option to gdbus-codegen
which can be used to instruct gdbus-codegen about what autocleanup
definitions to emit.

Doing this unconditionally was found to interfere with existing
code out in the wild.

The new option takes an argument that can be
none, objects or all; to indicate whether to generate no
autocleanup functions, only do it for object types, or do it
for interface types as well. The default is 'objects', which
matches the unconditional behavior of gdbus-codegen on the 2.48
branch.

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

Later Visual Studio versions does not allow one to define known keywords,
even if they are actually not known to the compiler.  Avoid this issue by
checking more conditions before we define inline as __inline:

-We are not building under C++ mode.
-We are on Visual Studio 2013 or earlier.

Where both of these conditions need to hold true.

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

Use the g_file_test() API instead of the g_stat() + S_ISDIR combo to fix
builds on compilers that do not support S_ISDIR.

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

This ensures that g_socket_get_fd() will return -1 after the socket has
been closed.

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

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

The use of past tense in g_task_had_error makes one assume that it
won't forget about any errors that might have occurred. Except, in
reality, it would.

Let's use a boolean flag to remember the error once it's been
propagated, as opposed to keeping the error around. This ensures that
the g_task_propagate_* methods continue to give invalid results when
called more than once, as mentioned in the documentation.

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

Some GNOME projects unconditionally work around the generated code's
lack of g_autoptr support by defining the autoptr cleanup function
themselves, which is not forward-compatible; as a result, commit
cbbcaa4d broke them. Do not define the cleanup function unless the
including app "opts in" to newer APIs via GLIB_VERSION_MAX_ALLOWED.

Projects requiring compatibility with GLib < 2.49 can get a
forward-compatible g_autoptr for a generated GInterface type found in
a library, for example ExampleAnimal in the GIO tests, by declaring
and using a typedef with a distinct name outside the library's
namespace:

    typedef AutoExampleAnimal ExampleAnimal;
    G_DEFINE_AUTOPTR_CLEANUP_FUNC (AutoExampleAnimal, g_object_unref)

    ...

    g_autoptr (AutoExampleAnimal) animal = NULL;

    /* returns ExampleAnimal * */
    animal = example_animal_proxy_new_sync (...);
    /* takes ExampleAnimal * first argument */
    example_animal_call_poke_sync (animal, ...);
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=763379Reviewed-by: Colin Walters <walters@verbum.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>

The rest of the generated classes gained g_autoptr support in fd6ca66c,
but this one is still missing. Because whatever_proxy_new_finish() and
whatever_proxy_new_sync() are declared as returning a Whatever *
instead of a WhateverProxy *, and the generated method-call stubs
act on a Whatever *, it's reasonably common to want to declare a
g_autoptr (Whatever).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/review?bug=763379Reviewed-by: Colin Walters <walters@verbum.org>

If you set the source name after attaching to the context, you have to
lock the context to free/assign the new source name.

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

gdbus-tool prints a hint about the expected arguments to a function call
in case of errors.  Unfortunately, it prints this message on all errors.
I've seen this confuse users several times -- they go on tweaking the
arguments trying to get the correct type, even though they had it
correct in the first place.

Let's limit the hint to the case where it was actually invalid arguments
that triggered the problem.  Also, adjust the code that prints the
message so that it will also report on the case that no arguments were
expected.

We could possibly get closer to what we want by comparing the list of
expected arguments with the parameter list, as it was parsed from the
user, but that would involve composing the expected type.  Let's keep
this simple for now.

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

https://bugzilla.gnome.org/show_bug.cgi?id=755898Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>

Do the actual wait dance even if wait timeout is < 10ms. Otherwise
we might busyloop.

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

When debugging a program or testing a change to an installed version, it
is often useful to be able to replace resources in the program or a
library, without recompiling.

To support this, for debugging and hacking purposes, it's now possible
to define a G_RESOURCE_OVERLAYS environment variable as a
colon-separated list of substitutions to perform when looking up
GResources.

A substitution has the form

  "/org/gtk/libgtk=/home/desrt/gtk-overlay"

The part before the '=' is the resource subpath for which the overlay
applies.  The part after is a filesystem path which contains files and
subdirectories as you would like to be loaded as resources with the
equivalent names.

In the example above, if an application tried to load a resource with
the resource path '/org/gtk/libgtk/ui/gtkdialog.ui' then GResource would
check the filesystem path '/home/desrt/gtk-overlay/ui/gtkdialog.ui'.  If
a file was found there, it would be used instead.

Substitutions must start with a slash, and must not have a trailing
slash before the '='.  It is possible to overlay the location of a
single resource with an individual file.

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

Replace the hand-written equivalent of this with the call to the
GHashTable built-in version to save a few lines of code.

The GResource code was written a couple of years before this function
existed.

Similarly, replace a set-mode usage of g_hash_table_insert() with a call
to g_hash_table_add().

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

Types are transformable if they are compatible *or* a transformation function
is registered.

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

Commit 99bdfd1b introduced a direct call to pthreads_setname_np in the
'thread' test case.  Because we are directly calling pthreads functions
from this file now, we need to make sure we link it with the system
thread library flags (as we already do for another file).

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