The threaded tests are using the default main context in the worker
thread, but were not g_main_context_acquire()ing it first, which meant
that g_tls_interaction_invoke_ask_password() in the main thread would
sometimes succeed in acquiring it itself and thus performing the
operation in the wrong thread. Fix that.
Also, we can't unref the loop from the worker thread, because the main
thread isn't holding a reference on it, and so it might end up being
destroyed while that thread is still inside g_main_loop_quit().
Improve a few situations where g_date_time_format() was getting the
padding wrong when displaying alt digits (eg: Arabic numerals) for
formatting time.
We now depend on nl_langinfo (_NL_CTYPE_OUTDIGITn_WC) to do the
conversion, which is very likely glibc-specific, but our previous method
relied on a glibc-specific printf() feature, so no harm done there.
Add a configure check for nl_langinfo (_NL_CTYPE_OUTDIGITn_WC).
Uncomment a few testcases that were failing previously.
https://bugzilla.gnome.org/show_bug.cgi?id=658107
(which shouldn't ever have been part of the API. Grr.)
Solaris /etc/services doesn't even have "http", which was causing
tests/network-address to fail...
On Solaris, getsockname() on an unconnected socket gives an addrlen of
0 and doesn't set the sockaddr. So use the SO_DOMAIN sockopt to find
the socket family in that case. (SO_DOMAIN doesn't exist everywhere,
so we can't use it unconditionally. Also, we have to only use it if
getsockname() fails, since SO_DOMAIN returns a bogus value for
accept()ed sockets on both Linux and Solaris...)
Also, link libgio to -lresolv explicitly, rather than depending on
getting it implicitly via the libasyncns build (which should
eventually be going away).
https://bugzilla.gnome.org/show_bug.cgi?id=645336
Explicitly mention C99's strftime() in the documentation for
g_date_time_format() as the one that we aim for compatibility with.
Specifically list the formats we do not support as well as the extra
ones that we borrow from glibc.
Test g_date_time_format() against strftime(). This test found quite a
few cases of incorrect behaviour on our part (fixes already committed
for those).
Our implementation of %W is incorrect. Nobody should want to use this
format anyway and the implementation is non-trivial, so rip it out
rather than fixing it.
Remove the testcase for %W as well.
%N is not specified in any standards document, but we use it to display
the number of microseconds.
The fact that our our current implementation of it is nearly useless
(since it does not zero-pad) coupled with the high chance that a future
version of the C standard may specify it with another meaning means that
we should drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=658061
%V represents the ISO 8601 week number of the current year as a
decimal number, range 01 to 53, where week 1 is the first week
that has at least 4 days in the new year
https://bugzilla.gnome.org/show_bug.cgi?id=658061
"kB" is used by GLib to mean 1000 bytes exactly -- not 1024. It is
therefore incorrect to translate this to KiB. Same for the other units.
The original commit ef3e5917ca fixing this
problem was reverted, so I'm applying it again.
See http://mail.gnome.org/archives/gnome-i18n/2011-July/msg00078.html
for more information.
Since there was nothing guaranteeing synchronization of the
assignments to checked and clockid, it would be possible for one
thread to set clockid = CLOCK_MONOTONIC, and for another thread to see
checked = TRUE but still clockid = CLOCK_REALTIME.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
Change the unix signal watch API to match other sources in both
available functions, names of those functions and order of the
parameters to the _full function.
https://bugzilla.gnome.org/show_bug.cgi?id=657705
* Add 'invoke' style method, which can be used to call an interaction
from any thread. The interaction will be run in the appropriate
#GMainContext
* Sync methods can be called whether main loop is running or not.
* Derived classes can choose to implement only sync or async
interaction method, and the invoke method will fill in the blanks.
* Documentation for the above.
* Tests for the above.
https://bugzilla.gnome.org/show_bug.cgi?id=657567
g_desktop_app_info_set_as_default_for_type() and
g_desktop_app_info_set_as_last_used_for_type () require the
application's ID, but depending on how the GAppInfo was created,
we might not be have one, and would thus silently fail to set
the default application, or last used application.
https://bugzilla.gnome.org/show_bug.cgi?id=657445
