- Feb 15, 2018
-
-
Iain Lane authored
-
- Feb 14, 2018
-
-
Iain Lane authored
-
Iain Lane authored
-
Iain Lane authored
-
Iain Lane authored
debian/patches/gdbus-threading-test-Allow-even-longer-for-test_method_ca.patch: Drop, applied upstream in this release.
-
Iain Lane authored
-
Iain Lane authored
Update to upstream version '2.55.2' with Debian dir 8d9dae26198751ee9ee2aadaf30a73acf6a81cf7
-
Iain Lane authored
-
Iain Lane authored
-
- Feb 11, 2018
-
-
Matthias Clasen authored
-
- Feb 10, 2018
-
-
Cheng-Chia Tseng authored
-
- Feb 09, 2018
-
-
Fran Dieguez authored
-
Mikhail Zabaluev authored
The existing array annotation is inconsistent with the other conversion functions. Now that the implementation guarantees no embedded NULs, the return value can be re-annotated. https://bugzilla.gnome.org/show_bug.cgi?id=756128
-
Mikhail Zabaluev authored
Note that the g_convert() API works with byte arrays. It's wrong to default to utf8 there, because iconv can read and produce strings with interior nul characters which are not allowed in (type utf8). The documentation was misleading about that in some places, so that got corrected as well. Strings in the locale encoding are annotated as dynamic-length byte arrays because they don't have any guaranteed format and can contain nul bytes. For UTF-8 strings in g_*_{from,to}_utf8(), GLib assumes no embedded nul bytes and the (type utf8) annotations on the UTF-8 parameters and return values remain as they were. Likewise for (type filename). https://bugzilla.gnome.org/show_bug.cgi?id=756128
-
- Feb 08, 2018
-
-
Philip Withnall authored
This improves the formatting of the documentation ever so slightly. Signed-off-by: Philip Withnall <withnall@endlessm.com> Reviewed-by: nobody
-
Philip Withnall authored
After building a test run of all GNOME modules against this, we can conclude that it is a visible API break: it breaks the NetworkManager build. http://build.gnome.org/continuous/buildmaster/builds/2018/02/08/46/build/log-NetworkManager.txt NetworkManager is (almost legitimately) passing a gpointer to G_VALUE_TYPE, which I think is a use case we should continue supporting. This reverts commit a05a21be. https://bugzilla.gnome.org/show_bug.cgi?id=793186
-
Emmanuele Bassi authored
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> https://bugzilla.gnome.org/show_bug.cgi?id=793298
-
Philip Withnall authored
We’ve moved to GNOME GitLab! This is great. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=793298
-
Philip Withnall authored
I’m not sure how I’ve been conned into this. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=793298
-
Sebastian Dröge authored
It's not possible to subclass GValue, and by always explicitly casting here it is easy to write broken code (e.g. passing a GValue**) without the compiler warning about that. By not casting, the compiler will error out if anything but a GValue* is passed here. https://bugzilla.gnome.org/show_bug.cgi?id=793186
-
Philip Withnall authored
Introduced in commit 1574321e. This fix introduces no functional changes (just a cast). Signed-off-by: Philip Withnall <withnall@endlessm.com> Reviewed-by: nobody
-
- Feb 06, 2018
-
-
Matthias Clasen authored
Not everybody knows console color codes by heart.
-
Philip Withnall authored
g_variant_get_objpathv() doesn’t exist. The code actually meant g_variant_get_objv(). This fixes a leak with `ao`-type properties in generated code. Previously they wouldn’t be freed; now the container is (correctly) freed. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=770335
-
Philip Withnall authored
This seems to have been present since the code was introduced in commit cedc8229. The attr variable is defined under one #ifdef, but destroyed under another, which doesn’t make any sense. The second #ifdef variable is actually an enum value, rather than the static initialiser value which makes more sense in the context. Note that GMutex used to be statically initialised to the value of PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP in gthread.h, before this was reworked in commit e081eadd. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=793026
-
Allison Lortie authored
g_key_file_get_locale_string() returns a translated string from the keyfile. In some cases, it may be useful to know the locale that that string came from. Add a new API, g_key_file_get_locale_for_key(), that returns the locale of the string. Include tests. (Modified by Philip Withnall to rename the API and fix some minor review issues. Squash in a separate test case commit.) https://bugzilla.gnome.org/show_bug.cgi?id=605700
-
- Feb 05, 2018
-
-
Kukuh Syafaat authored
-
- Feb 04, 2018
-
-
Piotr Drąg authored
-
Philip Withnall authored
From commit 99b792fa. Spotted by Coverity; CID 1385719. Signed-off-by: Philip Withnall <withnall@endlessm.com>
-
- Feb 03, 2018
-
-
Patrick Griffis authored
(Minor wording tweak by Philip Withnall.) https://bugzilla.gnome.org/show_bug.cgi?id=520116
-
- Feb 02, 2018
-
-
Philip Withnall authored
res_query() uses global state in the form of the struct __res_state which contains the contents of resolv.conf (and other things). On Linux, this state seems to be thread-local, so there is no problem. On OS X, however, it is not, and hence multiple res_query() calls from parallel threads will compete and return bogus results. The fix for this is to use res_nquery(), introduced in BIND 8.2, which takes an explicit state argument. This allows us to manually store the state thread-locally. If res_nquery() isn’t available, we fall back to res_query(). It should be available on OS X though. As a data point, it’s available on Fedora 27. There’s a slight complication in the fact that OS X requires the state to be freed using res_ndestroy() rather than res_nclose(). Linux uses res_nclose(). (See, for example, the NetBSD man page: https://www.unix.com/man-page/netbsd/3/res_ninit/. The Linux one is incomplete and not so useful: http://man7.org/linux/man-pages/man3/resolver.3.html. ) The new code will call res_ninit() once per res_nquery() task. This is not optimal, but no worse than before — since res_query() was being called in a worker thread, on Linux, it would implicitly initialise the thread-local struct __res_state when it was called. We’ve essentially just made that explicit. In practical terms, this means a stat("/etc/resolv.conf") call per res_nquery() task. In future, we could improve this by using an explicit thread pool with some manually-created worker threads, each of which initialises a struct __res_state on spawning, and only updates it on receiving the #GResolver::reload signal. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=792050
-
Allison Lortie authored
Some projects use child schemas in an odd way: they link children which already have their path pre-defined. This causes the child schema (and its keys) to be printed out twice: - once because it is, itself, a non-relocatable schema - once, as a recursion from its parent We can avoid this by not recursing into child schemas that are non-relocatable (on the assumption that they will be enumerated elsewhere). https://bugzilla.gnome.org/show_bug.cgi?id=723003
-
Philip Withnall authored
When compiling with G_LOG_USE_STRUCTURED, g_message(), g_debug(), etc. use g_log_structured(). The message format string and its format arguments are passed as the final set of arguments in a longer varargs list, which includes the log domain and level (and other) fields. Passing the message format in this way means it’s not possible for the compiler to know to check its format placeholders when compiling with -Wformat. Fix support for this by adding a new semi-private helper function, _g_log_structured_standard(), which only uses varargs for the message format and its arguments, and uses fixed arguments for the other fields. This is then converted to a set of GLogFields and passed to g_log_structured() as normal. Support for -Wformat when compiling *without* G_LOG_USE_STRUCTURED was never broken. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=793074
-
Philip Withnall authored
Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=658713
-
Philip Withnall authored
g_data_input_stream_read_upto() was introduced in 2.26; now it’s GLib 2.56, we can probably deprecate the old versions (since the handling of consuming the stop character differs between the sync and async versions of it). Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=584284
-
Philip Withnall authored
Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=790698
-
Philip Withnall authored
The behaviour of upstream iconv() when faced with a character which is valid in the input encoding, but not representable in the output encoding, is implementation defined: http://pubs.opengroup.org/onlinepubs/9699919799/ Specifically: If iconv() encounters a character in the input buffer that is valid, but for which an identical character does not exist in the target codeset, iconv() shall perform an implementation-defined conversion on this character. This behaviour was being exposed in our g_iconv() wrapper and also in g_convert_with_iconv() — but users of g_convert_with_iconv() (both the GLib unit tests, and the implementation of g_convert_with_fallback()) were assuming that iconv() would return EILSEQ if faced with an unrepresentable character. On platforms like NetBSD, this is not the case: NetBSD’s iconv() finishes the conversion successfully, and outputs a string containing replacement characters. It signals those replacements in its return value from iconv(), which is positive (specifically, non-zero) in such a case. Let’s codify the existing assumed behaviour of g_convert_with_iconv(), documenting that it will return G_CONVERT_ERROR_INVALID_SEQUENCE if faced with an unrepresentable character. As g_iconv() is a thin wrapper around iconv(), leave the behaviour there implementation-defined (but document it as such). Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=790698
-
Philip Withnall authored
Also rename it to make it clearer how it’s encoded (as UTF-8). Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=790698
-
Philip Withnall authored
Fix capitalisation of GLib, make some text less gender-specific, and add some missing colons. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=790698
-
Philip Withnall authored
Another part of the long tail of converting our documentation from DocBook to Markdown. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=790698
-
Philip Withnall authored
off64_t doesn’t exist in any standard (definitely not C99), and so goffset is actually closer to off_t in 64-bit mode. However, goffset is always defined as gint64, so make that clear. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=792856
-