Rewrite the install rule for GSettings schemas to not depend on an
obscure chunk of non-portable sed that nobody understands the purpose
of.
Instead, use make's VPATH feature to resolve the paths of the files that
need to be installed. No need to depend on the .valid targets here
since automake already ensures that 'make all' is complete before 'make
install' is permitted to run.
Fix a small bug in the synchronous lookup code introduced in the fix
for bug 629274
(cherry picked from commit cd4f818b301bfc6855b27feba5a0dfdca60027c1)
Add some words and example code to the documentation about why you might
want to manually invoke gsettings-data-convert and how you should go
about doing that.
(cherry picked from commit dfb0577ef4947afb32d91a72769bd22d6c1edfaa)
RFC 2782 says that if there is no SRV record for
_SERVICE._PROTOCOL.DOMAIN, you should fall back to trying just DOMAIN,
with the default port for SERVICE. Do that.
https://bugzilla.gnome.org/show_bug.cgi?id=629274
(cherry picked from commit e410131021036532e6e9622e8b977222389b44e9)
Previously if there were multiple SRV records, only the first would
be iterated by the GSocketConnectable interface
(cherry picked from commit 19243c247d8a89c6467bd21109b7f0d4b1cb081a)
Otherwise, attempting to create a GSocketConnection from the socket
will likely return the wrong type, since the protocol won't match any
of the registered subtypes.
Also add the start of a GSocket test program (from davidz).
https://bugzilla.gnome.org/show_bug.cgi?id=627171
(cherry picked from commit 87d06109ab325a4a68e151015381e7e1b33bdf7d)
Of course, a proper implementation of close() will just ignore an
invalid parameter silently, and set errno. But apparently the "debug"
version of the Microsoft C library generates some noise in this
case. So avoid that. Thanks to John Emmas for reporting.
After the recent changes to message filtering, it can happen that
data->message is NULL when we get here.
(cherry picked from commit fe1186a842458dcc647c5f9ab03f17c762354e95)
Implement the second feature requested in the bug: silently ignore
override files that attempt to override schemas that are not currently
installed.
Also, support 'strictness' being optional for other errors when parsing
override files (ie: inability to open the file, unknown key name, parse
errors, out of range). We don't completely back out the file in this
case — as that is difficult with the current implementation — but just
ignore the override for the single key.
Implement the first of two features requested in the bug: when
encountering a broken .xml schema file, back out the changes in that
file and continue to parse other files.
This prevents a single broken .xml file from messing up GSettings for
everyone else.
Add a --strict option to get the old behaviour. Use this from the test
cases.
