Virtaal installs a mime package for various .po-like file formats, one
of which has the extension .txt. This causes GLib to report ".txt"
files still as "text/plain" but no longer with complete certainty.
The result is that asserting !uncertain during the testsuite causes the
test to fail if Virtaal happens to be installed.
Remove this assertion.
We're testing for particular error messages, so we need to set to a C
locale to make sure we get the untranslated version.
Previously, this test set the LANG environment variable, but that's not
good enough if LANGUAGE is also set. The only way to ensure that
LANGUAGE is ignored is to disable l10n with LC_ALL=C.
Due to the split up of the property sheets, the install projects did not
have info on the Intermediate and Output Paths, which caused confusing
messages from Visual Studio to show up upon completing build+"install" and
closing Visual Studio on whether to reload the install project, at least on
Visual Studio 2008.
Include the property sheet which defines these properties to fix this.
Allow passing a NULL domain to g_test_expect_message(), and more
importantly, don't crash if a message with a NULL domain gets logged
while there is an expected message.
On Windows and OS X, FIONREAD on a UDP socket gets the total number of
bytes available, not the number of bytes available in the next packet,
which is the more useful number (and how the function always behaved
on Linux).
On OS X, fix this by using SO_NREAD. On Windows, fix this by doing a
MSG_PEEK recv() into a giant buffer, since there is apparently no
other way to get the information.
https://bugzilla.gnome.org/show_bug.cgi?id=686786
Implement gnulib strftime extensions for the '%z' numeric timezone
format. These are also supported and documented by GNU date(1):
%z +hhmm numeric time zone (e.g., -0400)
%:z +hh:mm numeric time zone (e.g., -04:00)
%::z +hh:mm:ss numeric time zone (e.g., -04:00:00)
%:::z numeric time zone with : to necessary precision (e.g., -04, +05:30)
https://bugzilla.gnome.org/show_bug.cgi?id=707151
AC_TRY_LINK should be used instead of AC_TRY_COMPILE because the code
will compile everywhere, either producing ``atomic'' code, or an
external reference to __sync_bool_compare_and_swap.
https://bugzilla.gnome.org/show_bug.cgi?id=706958
g_type_class_add_private() was doing
g_assert (node->data->instance.private_size <= 0xffff);
but that field is a guint16, so the check was a no-op. (Noticed by
clang, but not gcc for some reason.) Fix it to do the math in a gssize
variable and do the bounds checking there before updating the struct
field.
https://bugzilla.gnome.org/show_bug.cgi?id=706888
The requested_conditions list access is not threadsafe. When passing
the socket ownership from a GSource callback to another thread, which
also creates a GSocketSource for the socket, it can happen that the
original GSocketSource is finalized at the same time as the new one
is created. This would cause inconsistencies in the requested_conditions
list and can cause assertions or completely undefined behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=705027
The RunDLL command call during get_session_address_dbus_launch() was
expecting _g_win32_run_session_bus@16 and g_win32_run_session_bus
on Win32 and Win64 respectively at least when GLib is compiled with MSVC,
not g_win32_run_session_bus@16, which caused annoying RunDLL error dialogue
boxes to show up during the use of GtkApplication (such as when running
gtk3-demo-application on Windows), prevented GtkApplication items from
being run for more than one time during the lifespan of the program,
and this also interfered with some GTK+ tests, causing them to fail.
Update accordingly to address the issue.
Like the Visual Studio 2008 project files, split up the property sheets
so to ease maintenace, and to prepare to use autotools to fill in the
header entries to "install".
Put some of the items that are frequently repeated in the projects as well,
also to simplify maintenance.
Also, update the autotools files to automate the upgrade of Visual Studio
2010 project as we now have multiple property sheets to copy and process.
Split the property sheet into four sheets, to make maintainance of the
build files easier, and also to prepare for using autotools to fill in
the parts for the "installation" of headers.
Also put more of the items that are repeated in the projects into the
property sheets, also to improve ease of maintenance.
Updates to the Visual Studio 2010 projects will come later, as the script
to update them to Visual Studio 2012 must also be taken into account during'
the process.