[SyncEvolution] sync-ui does not work
by Christian
Hi having problems with sync-ui,
I am neither able to edit the examles, nor to add a new one. :(
What am I missing ?
using:
- libsysthesis 3.4.0.16.6
- syncevolution 1.2.2
on a openSUSE 11.4
getting:
(sync-ui:4879): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive: assertion
`GTK_IS_WIDGET (widget)' failed
** (sync-ui:4879): WARNING **: only file:// icon uri is supported:
image://themedimage/icons/services/egroupware
** (sync-ui:4879): WARNING **: only file:// icon uri is supported:
image://themedimage/icons/services/funambol
** (sync-ui:4879): WARNING **: only file:// icon uri is supported:
image://themedimage/icons/services/gmail
** (sync-ui:4879): WARNING **: only file:// icon uri is supported:
image://themedimage/icons/services/memotoo
** (sync-ui:4879): WARNING **: only file:// icon uri is supported:
image://themedimage/icons/services/everdroid
** (sync-ui:4879): WARNING **: only file:// icon uri is supported:
image://themedimage/icons/services/ovi
** (sync-ui:4879): WARNING **: Server.GetConfig() failed: Did not
receive a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.
If I close sync-ui and start it a second time, then the shown examples
in the previous try are now "vanished". No examples are shown or could
be retrieved.
If I kill syncevo-dbus-server and then start sync-ui, examples are shown
again, but neither editable nor addable new ones.
Any help would be appreciated.
Thanks
--
Christian
----------------------------------------------------
- Please do not 'CC' me on list mails.
Just reply to the list :)
----------------------------------------------------
Der ultimative shop für Sportbekleidung und Zubehör
http://www.sc24.de
----------------------------------------------------
8 years, 2 months
[SyncEvolution] Duplicates in Evolution Birthday Calendar
by Roth
Hallo there,
since a sync of Evolution with my Funambol server I have duplicates of
my birthday entries in Evolution.
I couldn't figure out how to delete them.
Can anybody help me out with this issue please?
Where does Evolution store the birthday calendar entries?
Thanks and kind regards
Max
8 years, 2 months
Re: [SyncEvolution] GDBus C++ add_filter + fork/exec dbus-server
by Patrick Ohly
On Thu, 2012-03-15 at 10:21 +0100, Krzesimir Nowak wrote:
> W dniu 14 marca 2012 15:30 użytkownik Patrick Ohly
> <patrick.ohly(a)intel.com> napisał:
> > Hello Krzesimir!
> >
> > You added the add/remove_filter() methods to DBusConnectionPtr, with the
> > comment "those additions will be needed for ForkExec ready message
> > handling" in the commit message.
> >
> > The methods themselves are not documented. Can you explain a bit how
> > this is meant to work?
>
> The history is that I needed to add a new signal to ForkExec, because
> activation of DBus interface on child side was racing with using this
> interface on parent side.
Wouldn't it be easier to delay message processing on the child side
until the child is set up, then enable the message processing?
http://developer.gnome.org/gio/unstable/GDBusConnection.html#GDBusConnect...
mentions G_DBUS_CONNECTION_FLAGS_DELAY_MESSAGE_PROCESSING and
g_dbus_connection_start_message_processing() for this purpose.
Then the parent can start making method calls right away. They simply
will not be processed before the child is really ready to handle them.
--
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.
8 years, 2 months
[SyncEvolution] problem syncing calendar between Nokia N900 and owncloud calDav calendar
by karlitos
Hello
I was trying to set up a synchronization between my Nokia N900 phone and
owncloud (www.http://owncloud.org/). I followed instructions made by one of the
developpers of owncloud (http://tanghus.net/2012/01/syncing-your-n900-with-
owncloud/).
Syncing the contacts works suprisingly well, but I stucked by the initial slow
sync with the contacts. If I try to run the synchronization using:
$ syncevolution --sync slow owncloud-calendar
as described in the how-to I got following output :
#######################
[INFO] @default/contacts: inactive
[INFO @owncloud-calendar] @owncloud-calendar/addressbook: inactive
[INFO @owncloud-calendar] @owncloud-calendar/memo: inactive
[INFO @owncloud-calendar] @owncloud-calendar/todo: inactive
[INFO @owncloud-calendar] @owncloud-calendar/contacts: inactive
[INFO @owncloud-calendar] @owncloud-calendar/calendar: starting first time sync,
two-way
[INFO @owncloud-calendar] creating complete data backup before sync (enabled
with dumpData and needed for printChanges)
@owncloud-calendar data changes to be applied during synchronization:
*** @owncloud-calendar/calendar ***
no changes
[INFO] @default/calendar: starting first time sync, two-way
[ERROR] @default/calendar: error code from SyncEvolution fatal error (local,
status 10500): @default/calendar: not found: N900
[INFO] @default/calendar: first time sync done unsuccessfully
[ERROR] @default/calendar: fatal error (local, status 10500)
[INFO] creating complete data backup after sync (enabled with dumpData and
needed for printChanges)
Synchronization failed, see /home/user/.cache/syncevolution/owncloud_+calendar-
2012-03-11-19-46/syncevolution-log.html for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @owncloud-calendar | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| slow, 0 KB sent by client, 0 KB received |
| fatal error (local, status 10500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Mar 11 19:46:50 2012, duration 0:08min |
| fatal error (local, status 10500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: error code from SyncEvolution fatal error (local,
status 10500): @default/calendar: not found: N900
[ERROR @owncloud-calendar] parent has died unexpectedly
[INFO @owncloud-calendar] @owncloud-calendar/calendar: first time sync done
unsuccessfully
[ERROR @owncloud-calendar] @owncloud-calendar/calendar: aborted on behalf of
user (local, status 20017)
[INFO @owncloud-calendar] creating complete data backup after sync (enabled with
dumpData and needed for printChanges)
Synchronization failed, see
/home/user/.cache/syncevolution/target_+config@owncloud_+calendar-2012-03-11-19-
46-a/syncevolution-log.html for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @owncloud-calendar | @default | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| slow, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 0 before sync, 0 after it |
| aborted on behalf of user (local, status 20017) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Mar 11 19:46:53 2012, duration 0:06min |
| external transport failure (local, status 20043) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: parent has died unexpectedly
Data modified @owncloud-calendar during synchronization:
*** @owncloud-calendar/calendar ***
no changes
[ERROR @owncloud-calendar] writev(): Broken pipe
#######################
Here is my set up :
syncevolution --configure \
--template SyncEvolution \
backend=CalDAV \
--sync-property username=karlitos \
--sync-property password=****** \
--sync-property
syncURL=http://192.168.178.4/owncloud/apps/calendar/caldav.php/calendars/karlito
s/calendar \
--sync-property deviceId=n900 \
consumerReady=0 \
target-config@owncloud-calendar
syncevolution --configure \
--template "SyncEvolution Client" \
syncURL=local://@owncloud-calendar \
evolutionsource=N900 \
username= \
password= \
type=maemo-events \
consumerReady=1 \
owncloud-calendar calendar
I tried to use google to find out what is going worng, but without success.
Could anybody please give me some hints ? I have no idea where to start to find
the error.
Thanks in advance - K
8 years, 2 months
[SyncEvolution] shutdown request handling + fork/exec dbus-server
by Patrick Ohly
Hello Chris!
Your patch removes the Server::m_shutdownSession and replaces it with a
boolean m_shutdownRequested + a timeout that is set once in
Server::fileModified().
The comment in server.h still refers to m_shutdownSession and explains
that its purpose was to prevent other sessions from running. How is that
handled now?
More specifically, consider the following sequence of events:
1. files are modified and the quiesence timeout is started
2. a client connects, starts a session and syncs
3. the timeout triggers, causing the server to shut down
If it works as designed (we don't have tests for it, do we?), then the
syncevo-dbus-helper will continue to run and complete the session. But
the client will see an unexpected server disconnect and won't be able to
monitor progress of the still running session, because the running
helper isn't connected to any syncevo-dbus-server instance.
It could even be worse: with bad timing, an obsolete syncevo-dbus-helper
might get started which then fails because it doesn't match the
installed files.
IMHO adding any kind of resource should be prevented while the
m_shutdownRequested flag is set. Returning an error message to the
client would be okay and in fact better than the previous behavior
(letting it create a session, then disconnect without any specific error
message).
Do you agree with this analysis or did I miss something?
Don't bother changing code, I'm just trying to clarify the existing one.
--
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.
8 years, 2 months
[SyncEvolution] GDBus C++ add_filter + fork/exec dbus-server
by Patrick Ohly
Hello Krzesimir!
You added the add/remove_filter() methods to DBusConnectionPtr, with the
comment "those additions will be needed for ForkExec ready message
handling" in the commit message.
The methods themselves are not documented. Can you explain a bit how
this is meant to work?
I stumbled over this when I added an error exception which prevents
adding new resources to a server which is already shutting down:
void Server::addResource(const Resource_t &resource, const boost::function<void()> &callback)
{
==> if (m_shutdownRequested) {
==> // don't allow new resources, we cannot activate them
==> SE_THROW("server shutting down");
==> }
m_waitingResources.insert(resource);
checkQueue(callback);
}
It killed the syncevo-dbus-server because there was nothing catching the
exception. Regardless whether this is the right approach for solving the
shutdown problem, throwing and exception should never have that effect.
Further analysis showed that the call stack is (boost function levels
omitted):
#0 0x00007ffff092ab40 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x0000000000d710cf in SyncEvo::Server::addResource(boost::shared_ptr<SyncEvo::Resource> const&, boost::function<void ()> const&) (this=0x7fffffffdb70, resource=..., callback=...)
at /home/pohly/syncevolution/syncevolution/src/dbus/server/server.cpp:447
#2 0x0000000000d7179e in SyncEvo::Server::startSessionCb (this=0x7fffffffdb70, client=..., resource=...,
result=...) at /home/pohly/syncevolution/syncevolution/src/dbus/server/server.cpp:190
...
#8 0x0000000000dc786f in SyncEvo::SessionResource::onSessionReady(boost::function<void (boost::shared_ptr<SyncEvo::SessionResource> const&)> const&) (this=0x7fffe402d430, callback=...)
at /home/pohly/syncevolution/syncevolution/src/dbus/server/session-resource.cpp:403
...
#23 0x0000000000fc5c08 in SyncEvo::ForkExecParent::connectionFilter (this=0x7fffe402cf30, conn=..., message=...)
at /home/pohly/syncevolution/syncevolution/src/syncevo/ForkExec.cpp:219
...
#29 0x0000000000f0389d in GDBusCXX::filter_cb (conn=0x1a7bdb0, message=0x1a928f0, user_data=0x7fffe4033a80)
at /home/pohly/syncevolution/syncevolution/src/gdbusxx/gdbus-cxx-bridge.cpp:60
#30 0x00007ffff177dab8 in on_worker_message_received (worker=<optimized out>, message=0x1a928f0,
user_data=0x1a7bdb0) at /tmp/buildd/glib2.0-2.30.2/./gio/gdbusconnection.c:2250
...
#42 0x00007ffff0be27e6 in g_thread_create_proxy (data=0x1a84460) at /tmp/buildd/glib2.0-2.30.2/./glib/gthread.c:1962
#43 0x00007ffff671eb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#44 0x00007ffff012b90d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#45 0x0000000000000000 in ?? ()
Two observations:
1. GDBusCXX::filter_cb() is a callback for C code, and thus must
catch all exceptions in the code that it calls, then translate
them into some kind of C error return code (or whatever the
right error handling is).
2. g_dbus_connection_add_filter() says that "filters are run in a
dedicated message handling thread so they can't block and,
generally, can't do anything but signal a worker thread". These
are severe restrictions that aren't documented anywhere in the
add_filter() method, nor does our code conform to these
restrictions. For example, it calls the logging system, which is
not thread-safe.
I think we need a better solution for the problem. FWIW, the main thread
was idling at the time:
Thread 1 (Thread 0x7ffff7faf960 (LWP 25268)):
#0 0x00007ffff0120cc3 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=10)
at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007ffff0bbd5d8 in g_main_context_poll (n_fds=4, fds=0x7fffe40329c0, timeout=10, context=0x1a75780,
priority=<optimized out>) at /tmp/buildd/glib2.0-2.30.2/./glib/gmain.c:3391
#2 g_main_context_iterate (context=0x1a75780, block=<optimized out>, dispatch=1, self=<optimized out>)
at /tmp/buildd/glib2.0-2.30.2/./glib/gmain.c:3071
#3 0x00007ffff0bbde02 in g_main_loop_run (loop=0x1a75870) at /tmp/buildd/glib2.0-2.30.2/./glib/gmain.c:3284
#4 0x0000000000d75661 in SyncEvo::Server::run (this=0x7fffffffdb70)
at /home/pohly/syncevolution/syncevolution/src/dbus/server/server.cpp:398
#5 0x0000000000d6b6c4 in main (argc=1, argv=0x7fffffffe158, envp=0x7fffffffe168)
at /home/pohly/syncevolution/syncevolution/src/dbus/server/main.cpp:141
Perhaps the add_filter callback should be limited to the bare minimum of
functionality and do nothing more than waking up the main thread, to
finish whatever work is needed in ForkExec startup?
--
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.
8 years, 2 months
[SyncEvolution] Concurrent sync sessions update - Almost done
by Chris Kühl
Hi Patrick,
We've now got the GIO GDBus issues fixed and all the non-autosync &
non-connection tests pass with both DBus wrappers. We are currently
going through the code and making sure code is commented properly,
debugging output is cleaned up and header files are organized more
cleanly. The uncleaned code is in the knowak/for-Chris branch. We
don't suspect to be making anymore logic changes to that, just clean
it up. The clean-up will be finished tomorrow and I'll place it in a
branch named concurrent-sync-sessions-for-review.
Cheers,
Chris
8 years, 2 months
Re: [SyncEvolution] Failed with status code=20048, statistics are incomplete!! - Memotoo
by Patrick Ohly
Thomas Pequet wrote:
> I have an user who has problem to sync Ubuntu and
> Memotoo.
> The first sync works and after the seconds sync ask
> him a slow sync ...
> (I think it is because there is error: Warning: Failed
> with status
> code=20048, statistics are incomplete!!)
>
> See the log joined to help me to find a solution.
Not sure why this didn't make it to the list. I only got a bounce
notification.
The log shows an unexpected slow sync, caused by an anchor mismatch:
Saved Last Remote Server Anchor='20120228T115051Z', received <last>
Remote Server Anchor='1330608696000' (must match for normal sync)
It's a bit curious that in one case the anchor is a time stamp, in the
other a number. Both are strings sent by the Memotoo server. Did you
perhaps change the anchor formatting from "seconds since epoch as time
stamp" to "seconds since epoch as integer"? I haven't checked whether
20120228T115051Z matches 1330608696000 when interpreted like that.
Instead of blindly doing the slow sync, the user is asked first.
When using the command line, the user should see some instructions for
resolving this, namely doing some kind of refresh sync, or allowing the
slow sync.
In the GTK UI he or she should be pointed toward the recovery dialog,
which has similar options.
--
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.
8 years, 2 months
