The custom build rules did not have rules for x64 Debug builds during
the refactoring. Fix this by removing all Platform and Configuration
conditions for it, since this is done on are configs in the same manner.
Noted by Ignacio Casal Quinteiro.
The original patch really should have introduced a helper - among
other things it deserves a code comment. We're likely to make
further changes too, so it's obviously better to only do it in one
place.
See: https://bugzilla.gnome.org/show_bug.cgi?id=761102
Being able to determine that a certificate chain is invalid is not
considered an error, but success. This might not be obvious at first
due to the way the method is named and described currently. Since we
cannot change the name, let's improve the description and clarify this
aspect of its behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=780310
g_dbus_proxy_get_cached_property() and
g_dbus_proxy_get_cached_property_names() can both return NULL if the
property cache is empty. Avoid a crash if this situation arises (which
it looks like it could, from reading the code) by gracefully bailing out
on NULL return values.
Coverity issues: #1257044, #1257045https://bugzilla.gnome.org/show_bug.cgi?id=741229
socket->priv->timeout is only a guint, and the multiplication is
performed before it’s widened to gint64 to be stored in start_time
(thanks, C). This means any timeout of 50 days or more would overflow.
Fixing this bug makes me feel a real sense of self-worth.
Coverity ID: 1159478
Signed-off-by: Philip Withnall <withnall@endlessm.com>
request_completion is checked several blocks higher in the function.
Spotted by Coverity.
Coverity ID: 1373215
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When compiling statically against the system-provided gettext on Mac OS
X, GLib needs to be linked against CoreFramework, which provides some
functions used by gettext.
Fix this by including the necessary macro magic from upstream gettext.
https://bugzilla.gnome.org/show_bug.cgi?id=725894
g_object_newv uses a GParameter as argument. Since GParameter
is deprecated due to this type is not introspectible,
g_object_newv is deprecated now.
https://bugzilla.gnome.org/show_bug.cgi?id=709865
g_object_new_with_properties is an alternative to g_object_newv.
The last one, takes an array of GParameter. However, GParameter
is a rarely used type and this type is not introspectible, so
it will not work properly in bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=709865
The previously documented requirements for implementing init() and
init_async() as completely idempotent were really quite hard to achieve,
and brought a lot of pain for very little gain. Many implementations of
GInitable and GAsyncInitable did not actually follow the requirements,
or did not correctly handle concurrent init_async() calls.
Relax those requirements so that classes can decide whether their init()
or init_async() implementations need to be idempotent.
https://bugzilla.gnome.org/show_bug.cgi?id=766660
This is effectively the mc-wait-for-name tool from
telepathy-mission-control; moving it in to gdbus-tool will make it more
widely useful without making people depend on telepathy-mission-control
for no other reason. The code here is reimplemented from scratch to use
GDBus.
It blocks until the specified well-known name is owned by some process
on the bus (which can be the session, system, or any other bus). By
passing --activate, the same (or a different) name can be auto-started
on the bus first.
A timeout can be specified to ensure the process doesn’t block forever.
https://bugzilla.gnome.org/show_bug.cgi?id=745971
This will help us break generic GType deadlocks between people using
GDBus in different threads (which is supported), not just by GType
usage in the GDBus thread.
This should fix the common cases we're seeing in the wild, although I
have some lingering concerns that if someone e.g. referenced
e.g. `G_TYPE_DBUS_AUTH_MECHANISM_SHA1` etc. we'd need to add those
too.
https://bugzilla.gnome.org/show_bug.cgi?id=674885
We currently assume that the OpenURI portal should be used
unconditionally when running inside a flatpak sandbox. While
the portal is what we usually want, there are exceptions:
Yelp is now included in the GNOME runtime to allow displaying
help without exporting the user documentation, and the sandboxed
app itself may register a scheme handler.
To account for those cases transparently, always try the normal
code path first and only fall back to calling the portal when
that fails.
https://bugzilla.gnome.org/show_bug.cgi?id=780471
Now that the old logging API forwards through to the new structured
logging API, we don’t need to check the level or domain of a message
against INFO_LEVELS or G_MESSAGES_DEBUG — just pass it straight through
to the new structured logging API writer function.
https://bugzilla.gnome.org/show_bug.cgi?id=775879
If encoding with small chunks such that the call to
g_base64_encode_close() has to deal with 0 < x < 24 bits of remaining
state, the encoding code would not correctly use zeroes to pad out the
state — it would use left-over state from an earlier iteration in the
encoding process.
This resulted in invalid base-64 encodings.
Add a unit test for incremental encoding using different sized chunks
too.
Thanks to Rainier Perske for reporting and analysing the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=780066
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These calls cause race warnings from tsan, but are not a thread safety
problem, because we can only ever observe single bit changes: all
modifications to the GSource.flags field are done with a lock held; all
reads are of independent fields, so no intermediate state can ever be
observed. This assumes that a non-atomic read will consistently give us
an old value or a new value.
In any case, these g_source_is_destroyed() calls can happen from any
thread, and the state could be changed from another thread immediately
after the call returns; so the checks are pointless. In addition,
calling g_source_set_ready_time() or g_source_destroy() on a destroyed
source is not a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=778049
For versions of GCC which support it (≥ 4), define G_MODULE_EXPORT as
__attribute__((visibility("default"))). This is normally a no-op, unless
compiling with -fvisibility=hidden, in which case it marks a symbol to
be publicly exported from the library, which is what G_MODULE_EXPORT is
for. Previously G_MODULE_EXPORT has only worked on Windows.
The compatibility check for whether the compiler supports
__attribute__((visibility)) is based on the __GNUC__ define, and is
similar to the check done in configure.ac for defining G_GNUC_INTERNAL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778287
