GNOME Bugzilla – Bug 755075
Recent glib 2.45.8 change breaks account settings
Last modified: 2015-10-02 12:11:34 UTC
Glib 2.45.8 includes a change that causes evolution to fall back to the default values for most account settings. Among the affected settings are things like whether to use subscriptions or IDLE. I've bisected this bug down to this commit: https://git.gnome.org/browse/glib/commit/?id=00933dfc9cc525963c6833d3180b593a87bb15bb I'm not sure if this is a glib bug or if this change just exposed some bug hidden in evolution/e-d-s though.
Matthias, as it's a glib change, and eventually yours, could you have a look what can be wrong, please? Evolution uses CamelSettings for those values and has its own "proxy" for what to save/load,mostly generated on the fly within [1], though I do not see why your change would break it. One of a good adepts might be param_spec_clone() [2]. [1] https://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-source-camel.c [2] https://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-source-camel.c#n129
I get this debugging output when running evolution: > g_object_dispatch_properties_changed: quark 2 doesn't match 2538 for pspec:'real-trash-path' on 'ESourceCamelImapx' > g_object_dispatch_properties_changed: quark 0 doesn't match 2537 for pspec:'real-junk-path' on 'ESourceCamelImapx' > g_object_dispatch_properties_changed: quark 0 doesn't match 2536 for pspec:'namespace' on 'ESourceCamelImapx' > g_object_dispatch_properties_changed: quark 0 doesn't match 2522 for pspec:'filter-inbox' on 'ESourceCamelImapx' > g_object_dispatch_properties_changed: quark 61599488 doesn't match 2558 for pspec:'custom-args' on 'ESourceCamelSendmail' > g_object_dispatch_properties_changed: quark 1 doesn't match 2557 for pspec:'custom-binary' on 'ESourceCamelSendmail' > g_object_dispatch_properties_changed: quark 0 doesn't match 1054 for pspec:'path' on 'ESourceCamelMaildir' Which is just a print at the place of the glib commit from the comment #0, which shows the newly used quark, the quark which was used before the commit and the property name with an object type where these two quarks do not match. The reason is very simple, g_param_spec_get_name_quark() returns pspec->priv->name_quark, which is set only in g_param_spec_internal, where the 'internal' part of name really means it's not a public function. The pspec->priv->name_quark isn't set anywhere else in the glib/GObject sources. The param_spec_clone() in e-source-camel.c copies only public members of the structure, not the private (obviously), which explains why this stopped working. I guess it would be good to fix it on both sides, glib and eds, but I'll try to fix it in eds first.
Created attachment 311454 [details] [review] eds patch for evolution-data-server; More codding, less hacking. This makes it work, using only public and documented API, just as it should. The price is more code on the eds side.
I've got an approval from the release-team for a hard code freeze break, thus I pushed the fix into the sources: Created commit 5ee2b07 in eds master (3.18.0+)
I have no idea why eds would think that doing its own param_spec_clone() would be a good idea, but I'm glad you've found a way to fix it up.
*** Bug 755742 has been marked as a duplicate of this bug. ***
Hey Milan, is there any chance you could backport this to 3.16? Checking if it fixes the dup bug now
Yes, seems to be the same thing
*** Bug 755874 has been marked as a duplicate of this bug. ***
(In reply to Iain Lane from comment #7) > Hey Milan, is there any chance you could backport this to 3.16? Backport it where? The commit from comment #4 is cleanly applicable to 3.16.5. The 3.16.x is effectively dead for upstream. If you happen to use a distribution which ships the latest glib (apparently a development version, which the 2.45.x is), but keeps evolution(-data-server) behind, then ask them to backport the fix, in that particular distribution.
*** Bug 755940 has been marked as a duplicate of this bug. ***
Ok. I did that already to Ubuntu. I just thought that in the case of a 3.16.6 it would be good to have this patch.
(In reply to Iain Lane from comment #12) > I just thought that in the case of a 3.16.6 it would be good to have > this patch. Yes, understood, though there is not planned any release of 3.16.x, thus it doesn't make much sense, at least to me. As an example, if there would be a distribution shipping the latest glib, but outdated evolution-data-server, like version 3.10.x or even earlier, then that distribution would use the above fix too. The upstream will definitely not release evolution-data-server for each affected version due to the latest glib change.