- Sep 02, 2016
-
-
- Aug 17, 2016
-
-
Matthias Clasen authored -
Matthias Clasen authored
-
Currently the docs for GChecksumType are simpy annotated with 'Since 2.16' which is when GChecksumType was first introduced. No mention is made of the fact that the G_CHECKSUM_SHA512 constant was only added much later in 2.36. Signed-off-by:
Daniel P. Berrange <berrange@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=769027
-
Make it clear that this signal is only guaranteed to be emitted when a key has been read before. https://bugzilla.gnome.org/show_bug.cgi?id=750257
-
-
-
Matthias Clasen authored
In the case that *p is '\0', we should return p + 1, not p. This change allows to simplify g_utf8_find_next_char a bit. https://bugzilla.gnome.org/show_bug.cgi?id=547200
-
As claimed by valgrind in a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1317369 https://bugzilla.gnome.org/show_bug.cgi?id=766933
-
-
GSettings objects were not unreffed in test_flags, test_enums and test_ranges tests and when we skip internationalization tests, ie test_l10n(_context). https://bugzilla.gnome.org/show_bug.cgi?id=768560
-
As specified in the g_key_file_get_double documentation. https://bugzilla.gnome.org/show_bug.cgi?id=768504
-
As specified in the documentation of g_key_file_get_double function. https://bugzilla.gnome.org/show_bug.cgi?id=768504
-
-
-
-
-
It is required to correctly show translated messages on some locales. https://bugzilla.gnome.org/show_bug.cgi?id=760423
-
All versions since Visual C++ 2005 have this available, so we can just use it for G_STRUCT_OFFSET. See: https://msdn.microsoft.com/en-us/library/dz4y9b9a.aspx
-
OS X apparently stringifies the IPv6 address "::80" as "::0.0.0.128", which is bizarre, but that address *is* in a "reserved for future use" range, so it's not unambiguously wrong I guess. Anyway, fix the text to use an address everyone can agree on. https://bugzilla.gnome.org/show_bug.cgi?id=768551
-
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 dtr...
-
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
-
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
-
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
-
This fixes a build failure in Continuous that resulted in the error: ../../../gio/tests/test.gresource.xml: Failed to locate 'test-generated.txt' in any source directory. Makefile:4676: recipe for target 'test.gresource' failed make[6]: *** [test.gresource] Error 1
-
Don't require that files can be resolved when generating dependencies. Original patch by Garret Regier. https://bugzilla.gnome.org/show_bug.cgi?id=673101
-
Some compilers have trouble with such sequences. Visual C++ may or may not generate a warning in this particular case depending on if the local code page supports an ellipsis. https://bugzilla.gnome.org/show_bug.cgi?id=767218
-
-
Lots of projects like NetworkManager, ostree, udisks, soon polkit, etc. do this or *should* do this. And we need to support that forever. https://bugzilla.gnome.org/show_bug.cgi?id=767172
-
Matthias Clasen authored
We now use markdown.
-
This probably used to be a part of libgsystem.
-
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
-
Matthias Clasen authored
-
- Aug 15, 2016
-
-
Simon McVittie authoredgcc 6 warns (fatally, by default) that %c only uses a 2-digit year in some locales. The precise format does not seem to be important for this sample code, so use ISO 8601 instead of suppressing the warning with a pragma. Signed-off-by:
Simon McVittie <smcv@debian.org> Reviewed-by: Colin Walters Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768453 (cherry picked from commit 037719c2)
-
- Jun 24, 2016
-
-
- Jun 22, 2016
-
-
Chun-wei Fan authored
Allow the use of ${exec_prefix} for libdir and includedir when passing them in as arguments to the script.
-
- Jun 19, 2016
-
-
John Ralls authored
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. (cherry picked from commit 35b401c8)
-
- Jun 15, 2016
-
-
Chun-wei Fan authored
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.
-
