On Do, 2011-07-14 at 04:24 +0200, Chris Kühl wrote: > I've been working on getting my dbus-server-reorganization branch on > par with master and I think I've almost achieved that. Currently they > are both seeing 3 failures and 2 errors. I see that the 2 errors are > probably addressed in bug #20990 as they start to appear only after > the recent autosync changes. The 3 failures seem to be due to issues > with the password property in temporary configs. I've pastebin'ed my > output in case it's helpful: http://pastebin.com/kRe0sPBK
'Method "GetReports" ... doesn't exist' is (partly?) fixed by: commit f47d31580ddafa4a0243e809aa0ec5451e5182d3 Author: Patrick Ohly <[email protected]> Date: Tue Jul 12 12:46:47 2011 +0200 auto syncing: fix D-Bus API violations (part of BMC #20966) Auto-sync sessions did not properly activate their D-Bus support and thus couldn't be accessed via the Session D-Bus API. Must have affected showing progress of such sessions in the GTK sync-ui. They also weren't kept around for one minute, like the sessions started by a client. Therefore UIs which need to retrieve information about a completed session failed for a second reason. Fixed by adding the necessary "activate()" and use "addTimeout()" trick for session expiry also in the AutoSyncManager. The later was moved into DBusServer for that. I'm not sure whether the fix is complete, because I still see the failure in the nightly testing, in a slightly different way than locally (where I cannot reproduce it anymore): http://runtests.syncevolution.org/2011-07-13-19-56_dist/head-lucid-amd64/nightly.html http://runtests.syncevolution.org/2011-07-13-19-56_dist/head-lucid-amd64/6-dbus/SessionAPIsDummy_AutoSyncLocal.log [DEBUG 00:00:01] session /org/syncevolution/Session/17312472401310560063 deconstructing process 28897: arguments to dbus_connection_get_data() were incorrect, assertion "connection != NULL" failed in file dbus-connection.c line 5797. This is normally a bug in some application using the D-Bus library. Adding the auto sync tests broke some other tests, which I only noticed in that nightly testing. Fixed by: commit 811d10fc33f64a46ae43ce3903d637cad02c15f0 Author: Patrick Ohly <[email protected]> Date: Wed Jul 13 15:54:49 2011 +0200 D-Bus testing: avoid test failures due to GNOME keyring side effects The auto-sync tests modified the GNOME keyring by setting a password for the same URL that is also used in the password request tests, which caused those tests to fail. Ideally this would be fixed by running each test with a fresh GNOME keyring, but this is hard to set up. Instead solve the problem by keeping the URLs separate. > I said "almost" on par because I've been having issues when building > with --disable-shared and --enable-static. When trying this I get an > error telling me to add -ldl to the LDFLAGS which I've done and it > does in fact seem to build correctly. However, with this, the backends > don't get registered and I, of course, get tons of problems when > running the tests. This issue exists in the first commit on my branch > which moved the dbus-server over to its own directory. However, > everything does seem to build and work fine with only --enable-static > specified which is what I've been using for running the tests. Did you notice the rules which add the backend's *Register.cpp files to the syncevo-dbus-server? src/Makefile.am (generated from Makefile-gen.am) contains: BACKEND_REGISTRIES = ... backends/.../*Register.cpp This is then added to syncevo-dbus-server via: CORE_SOURCES += $(BACKEND_REGISTRIES) syncevo_dbus_server_SOURCES = \ ... $(CORE_SOURCES) The easiest solution might be to keep linking the main syncevo-dbus-server in "src", but with all code compiled in a sub-directory into a helper library. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
