opensync-users

[Opensync-users] Hi there [synce-plugin]

[mirko <mi...@re...>]

Hi, i'm trying to develop a synce-plugin for opensync.
I just made my first release.. 0.01. it should work with addressbook but
it's still buggy. 
If someone is interested please watch my blog and give a try to it:
http://www.mirkuz.net/?cat=9

Re: [Opensync-users] Hi there [synce-plugin]

[David E. <tw...@us...>]

On Thu, 2005-08-11 at 16:27 +0200, mirko wrote:
> Hi, i'm trying to develop a synce-plugin for opensync.
> I just made my first release.. 0.01. it should work with addressbook but
> it's still buggy. 
> If someone is interested please watch my blog and give a try to it:
> http://www.mirkuz.net/?cat=9

Cool!

-- 
Regards,
               -\- David Eriksson -/-

        SynCE - http://synce.sourceforge.net
      ScummVM - http://scummvm.sourceforge.net
     Desquirr - http://desquirr.sourceforge.net

Re: [Opensync-users] Hi there [synce-plugin]

[Danny B. <dan...@sc...>]

Mirko, and others,

I tried the 0.01 version of the opensync synce plugin. My system has
Mandrake 10.1 installed, my PDA is a Mio 168 (like Mirko's). The
version of opensync is=20
	# msynctool --version
	This is msynctool version "0.90.14"
	using OpenSync version "0.14"

Three remarks from my initial test :
1. It wouldn't compile without removing -Werror from src/Makefile.
   The error was
	synce_plugin.c:551: warning: implicit declaration of function
`osync_plugin_new_info'

   Later, I would discover that this was related to the next remark.

2. After that, msynctool --listplugins didn't pick up the new library.
   Setting OSYNC_TRACE made me discover that the symbol
	osync_plugin_new_info()
   was used by the plugin, but not defined by my installation of
   opensync. Looking through the material on opensync.org makes me
   conclude that the synce-plugin, and some of the material on
   opensync.org, are referring to a newer version of the API than
   what I have.
   So I edited the get_info call to start with this :
	void get_info(OSyncPluginInfo *info)
	{
   instead of
        void get_info(OSyncPluginInfo *env)
	{
	   OSyncPluginInfo *info =3D osync_plugin_new_info((void*)env);

   Can someone comment on these API versions ?

3. I could then set up everything with msynctool. I added a pair to
   synchronize between synce and the file-sync plugin.

   The first attempt to synchronize did some work (and left a lot of
   files in the file-sync directory), but then msynctool crashed. Gdb
   shows the following stack trace :
#0  0xffffe410 in ?? ()
#1  0xb73e8c48 in ?? ()
#2  0x00000006 in ?? ()
#3  0x00002503 in ?? ()
#4  0xb7b926e5 in raise () from /lib/tls/libc.so.6
#5  0xb7b94049 in abort () from /lib/tls/libc.so.6
#6  0xb7e4ad0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
#7  0xb7e4ad9d in g_log () from /usr/local/lib/libglib-2.0.so.0
#8  0xb7e4ae44 in g_assert_warning ()
from /usr/local/lib/libglib-2.0.so.0
#9  0xb7ee8211 in osync_hashtable_update_hash ()
from /usr/local/lib/libopensync.so.0
#10 0xb756233b in fs_commit_change ()
from /usr/local/lib/opensync/plugins/file_sync.so
#11 0xb7ee684a in osync_member_commit_change ()
from /usr/local/lib/libopensync.so.0
#12 0xb7ef8910 in client_message_handler ()
from /usr/local/lib/libosengine.so.0
#13 0xb7ef8363 in _queue_dispatch ()
from /usr/local/lib/libosengine.so.0
#14 0xb7e430c4 in g_main_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#15 0xb7e43f1d in g_main_context_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#16 0xb7e442df in g_main_context_iterate ()
from /usr/local/lib/libglib-2.0.so.0
#17 0xb7e448a3 in g_main_loop_run ()
from /usr/local/lib/libglib-2.0.so.0
#18 0xb7e5cbea in g_thread_create_proxy ()
from /usr/local/lib/libglib-2.0.so.0
#19 0xb7cd03b0 in start_thread () from /lib/tls/libpthread.so.0
#20 0xb7c3226e in clone () from /lib/tls/libc.so.6

   A second attempt to synchronize required me to answer a lot of
   questions to solve synchronisation problems, but eventually the
   synchronisation succeeded.

  Danny

On Thu, 2005-08-11 at 16:27 +0200, mirko wrote:
> Hi, i'm trying to develop a synce-plugin for opensync.
> I just made my first release.. 0.01. it should work with addressbook but
> it's still buggy.=20
> If someone is interested please watch my blog and give a try to it:
> http://www.mirkuz.net/?cat=3D9
--=20
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: [Opensync-users] Hi there [synce-plugin]

[Armin B. <arm...@de...>]

Danny Backx wrote:
> Mirko, and others,
> 
> I tried the 0.01 version of the opensync synce plugin. My system has
> Mandrake 10.1 installed, my PDA is a Mio 168 (like Mirko's). The
> version of opensync is 
> 	# msynctool --version
> 	This is msynctool version "0.90.14"
> 	using OpenSync version "0.14"
> 
> Three remarks from my initial test :
> 1. It wouldn't compile without removing -Werror from src/Makefile.
>    The error was
> 	synce_plugin.c:551: warning: implicit declaration of function
> `osync_plugin_new_info'
> 
>    Later, I would discover that this was related to the next remark.
> 
> 2. After that, msynctool --listplugins didn't pick up the new library.
>    Setting OSYNC_TRACE made me discover that the symbol
> 	osync_plugin_new_info()
>    was used by the plugin, but not defined by my installation of
>    opensync. Looking through the material on opensync.org makes me
>    conclude that the synce-plugin, and some of the material on
>    opensync.org, are referring to a newer version of the API than
>    what I have.
>    So I edited the get_info call to start with this :
> 	void get_info(OSyncPluginInfo *info)
> 	{
>    instead of
>         void get_info(OSyncPluginInfo *env)
> 	{
> 	   OSyncPluginInfo *info = osync_plugin_new_info((void*)env);
> 
>    Can someone comment on these API versions ?
> 

i changed the API from this:

get_info(OSyncPluginInfo *info)

to this:

get_info(OSyncPluginInfo *env)
{
	OSyncPluginInfo *info = osync_plugin_new_info((void*)env);

some time ago to allow one module to register several plugins at once
(this is for example used in the syncml plugin). So you have to update
your opensync installation. If you would like to beta test plugins i
_strongly_ suggest that you use code directly from the repository so i
can deliver you fixes for bugs that will show up more easy.

> 3. I could then set up everything with msynctool. I added a pair to
>    synchronize between synce and the file-sync plugin.
> 

that trace shows that it aborted with g_assert_warning () so there
should be an assert message on stdour or stderr. can you show this
warning to me?

>    The first attempt to synchronize did some work (and left a lot of
>    files in the file-sync directory), but then msynctool crashed. Gdb
>    shows the following stack trace :
> #0  0xffffe410 in ?? ()
> #1  0xb73e8c48 in ?? ()
> #2  0x00000006 in ?? ()
> #3  0x00002503 in ?? ()
> #4  0xb7b926e5 in raise () from /lib/tls/libc.so.6
> #5  0xb7b94049 in abort () from /lib/tls/libc.so.6
> #6  0xb7e4ad0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
> #7  0xb7e4ad9d in g_log () from /usr/local/lib/libglib-2.0.so.0
> #8  0xb7e4ae44 in g_assert_warning ()
> from /usr/local/lib/libglib-2.0.so.0
> #9  0xb7ee8211 in osync_hashtable_update_hash ()
> from /usr/local/lib/libopensync.so.0
> #10 0xb756233b in fs_commit_change ()
> from /usr/local/lib/opensync/plugins/file_sync.so
> #11 0xb7ee684a in osync_member_commit_change ()
> from /usr/local/lib/libopensync.so.0
> #12 0xb7ef8910 in client_message_handler ()
> from /usr/local/lib/libosengine.so.0
> #13 0xb7ef8363 in _queue_dispatch ()
> from /usr/local/lib/libosengine.so.0
> #14 0xb7e430c4 in g_main_dispatch ()
> from /usr/local/lib/libglib-2.0.so.0
> #15 0xb7e43f1d in g_main_context_dispatch ()
> from /usr/local/lib/libglib-2.0.so.0
> #16 0xb7e442df in g_main_context_iterate ()
> from /usr/local/lib/libglib-2.0.so.0
> #17 0xb7e448a3 in g_main_loop_run ()
> from /usr/local/lib/libglib-2.0.so.0
> #18 0xb7e5cbea in g_thread_create_proxy ()
> from /usr/local/lib/libglib-2.0.so.0
> #19 0xb7cd03b0 in start_thread () from /lib/tls/libpthread.so.0
> #20 0xb7c3226e in clone () from /lib/tls/libc.so.6
> 
>    A second attempt to synchronize required me to answer a lot of
>    questions to solve synchronisation problems, but eventually the
>    synchronisation succeeded.
> 

This means that the format comparison is not yet completely correct for
this synchronization. Since your synchronization crashed on the previous
sync, opensync automatically initiated a slow-sync which means that it
compares every entry from the devices again.

If the comparison is not done 100% correct, it sometimes raises
conflicts when it should not have. Please take a look at this quide
which show how to enable tracing: http://www.opensync.org/wiki/tracing

After you have traced the synchronization which results in the
conflicts, please send me the trace files so i can fix this problem.

>   Danny
> 
> On Thu, 2005-08-11 at 16:27 +0200, mirko wrote:
> 
>>Hi, i'm trying to develop a synce-plugin for opensync.
>>I just made my first release.. 0.01. it should work with addressbook but
>>it's still buggy. 
>>If someone is interested please watch my blog and give a try to it:
>>http://www.mirkuz.net/?cat=9

Re: [Opensync-users] Hi there [synce-plugin]

[Danny B. <dan...@sc...>]

On Wed, 2005-08-17 at 11:09 +0200, Armin Bauer wrote:
> > 2. After that, msynctool --listplugins didn't pick up the new library.
> >    Setting OSYNC_TRACE made me discover that the symbol
> > 	osync_plugin_new_info()
> >    was used by the plugin, but not defined by my installation of
> >    opensync. Looking through the material on opensync.org makes me
> >    conclude that the synce-plugin, and some of the material on
> >    opensync.org, are referring to a newer version of the API than
> >    what I have.
> >    So I edited the get_info call to start with this :
> > 	void get_info(OSyncPluginInfo *info)
> > 	{
> >    instead of
> >         void get_info(OSyncPluginInfo *env)
> > 	{
> > 	   OSyncPluginInfo *info =3D osync_plugin_new_info((void*)env);
> >=20
> >    Can someone comment on these API versions ?
> >=20
>=20
> i changed the API from this:
>=20
> get_info(OSyncPluginInfo *info)
>=20
> to this:
>=20
> get_info(OSyncPluginInfo *env)
> {
> 	OSyncPluginInfo *info =3D osync_plugin_new_info((void*)env);
>=20
> some time ago to allow one module to register several plugins at once
> (this is for example used in the syncml plugin). So you have to update
> your opensync installation. If you would like to beta test plugins i
> _strongly_ suggest that you use code directly from the repository so i
> can deliver you fixes for bugs that will show up more easy.

Ok, I've downloaded and compiled from the repository now.

> > 3. I could then set up everything with msynctool. I added a pair to
> >    synchronize between synce and the file-sync plugin.
> >=20
>=20
> that trace shows that it aborted with g_assert_warning () so there
> should be an assert message on stdour or stderr. can you show this
> warning to me?

There were too many messages for the xterm log so it got lost. I'm
trying to reproduce now but I managed to clear my contacts by clearing
the directory :-)

I'll send a log of my attempts to upload it to Armin and Mirko, maybe
it's of help to them. They show similar interaction to what I
encountered the other day, but with another scenario (and now with
the right software version).

	Danny

> >    The first attempt to synchronize did some work (and left a lot of
> >    files in the file-sync directory), but then msynctool crashed. Gdb
> >    shows the following stack trace :
> > #0  0xffffe410 in ?? ()
> > #1  0xb73e8c48 in ?? ()
> > #2  0x00000006 in ?? ()
> > #3  0x00002503 in ?? ()
> > #4  0xb7b926e5 in raise () from /lib/tls/libc.so.6
> > #5  0xb7b94049 in abort () from /lib/tls/libc.so.6
> > #6  0xb7e4ad0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
> > #7  0xb7e4ad9d in g_log () from /usr/local/lib/libglib-2.0.so.0
> > #8  0xb7e4ae44 in g_assert_warning ()
> > from /usr/local/lib/libglib-2.0.so.0
> > #9  0xb7ee8211 in osync_hashtable_update_hash ()
> > from /usr/local/lib/libopensync.so.0
> > #10 0xb756233b in fs_commit_change ()
> > from /usr/local/lib/opensync/plugins/file_sync.so
> > #11 0xb7ee684a in osync_member_commit_change ()
> > from /usr/local/lib/libopensync.so.0
> > #12 0xb7ef8910 in client_message_handler ()
> > from /usr/local/lib/libosengine.so.0
> > #13 0xb7ef8363 in _queue_dispatch ()
> > from /usr/local/lib/libosengine.so.0
> > #14 0xb7e430c4 in g_main_dispatch ()
> > from /usr/local/lib/libglib-2.0.so.0
> > #15 0xb7e43f1d in g_main_context_dispatch ()
> > from /usr/local/lib/libglib-2.0.so.0
> > #16 0xb7e442df in g_main_context_iterate ()
> > from /usr/local/lib/libglib-2.0.so.0
> > #17 0xb7e448a3 in g_main_loop_run ()
> > from /usr/local/lib/libglib-2.0.so.0
> > #18 0xb7e5cbea in g_thread_create_proxy ()
> > from /usr/local/lib/libglib-2.0.so.0
> > #19 0xb7cd03b0 in start_thread () from /lib/tls/libpthread.so.0
> > #20 0xb7c3226e in clone () from /lib/tls/libc.so.6
> >=20
> >    A second attempt to synchronize required me to answer a lot of
> >    questions to solve synchronisation problems, but eventually the
> >    synchronisation succeeded.
> >=20
>=20
> This means that the format comparison is not yet completely correct for
> this synchronization. Since your synchronization crashed on the previous
> sync, opensync automatically initiated a slow-sync which means that it
> compares every entry from the devices again.
>=20
> If the comparison is not done 100% correct, it sometimes raises
> conflicts when it should not have. Please take a look at this quide
> which show how to enable tracing: http://www.opensync.org/wiki/tracing
>=20
> After you have traced the synchronization which results in the
> conflicts, please send me the trace files so i can fix this problem.
>=20
> >   Danny
> >=20
> > On Thu, 2005-08-11 at 16:27 +0200, mirko wrote:
> >=20
> >>Hi, i'm trying to develop a synce-plugin for opensync.
> >>I just made my first release.. 0.01. it should work with addressbook bu=
t
> >>it's still buggy.=20
> >>If someone is interested please watch my blog and give a try to it:
> >>http://www.mirkuz.net/?cat=3D9
--=20
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: [Opensync-users] Hi there [synce-plugin]

[Armin B. <arm...@de...>]

Hi,

Thats very weird.

According to the assert it stoped here:

** ERROR **: file opensync_hashtable.c: line 225
(osync_hashtable_update_hash): should not be reached
aborting...

The weird thing is: this function never could get called from the synce
plugin (all occurences are commented out) which leads me to the
conclusion that either you are using a different version of the synce
plugin than i use or the stack got corrupted in a very bad way.

can you check if your plugin calls osync_hashtable_update_hash or
osync_hashtable_report_deleted at some point?

Armin

Danny Backx wrote:
> On Wed, 2005-08-17 at 11:09 +0200, Armin Bauer wrote:
> 
>>>2. After that, msynctool --listplugins didn't pick up the new library.
>>>   Setting OSYNC_TRACE made me discover that the symbol
>>>	osync_plugin_new_info()
>>>   was used by the plugin, but not defined by my installation of
>>>   opensync. Looking through the material on opensync.org makes me
>>>   conclude that the synce-plugin, and some of the material on
>>>   opensync.org, are referring to a newer version of the API than
>>>   what I have.
>>>   So I edited the get_info call to start with this :
>>>	void get_info(OSyncPluginInfo *info)
>>>	{
>>>   instead of
>>>        void get_info(OSyncPluginInfo *env)
>>>	{
>>>	   OSyncPluginInfo *info = osync_plugin_new_info((void*)env);
>>>
>>>   Can someone comment on these API versions ?
>>>
>>
>>i changed the API from this:
>>
>>get_info(OSyncPluginInfo *info)
>>
>>to this:
>>
>>get_info(OSyncPluginInfo *env)
>>{
>>	OSyncPluginInfo *info = osync_plugin_new_info((void*)env);
>>
>>some time ago to allow one module to register several plugins at once
>>(this is for example used in the syncml plugin). So you have to update
>>your opensync installation. If you would like to beta test plugins i
>>_strongly_ suggest that you use code directly from the repository so i
>>can deliver you fixes for bugs that will show up more easy.
> 
> 
> Ok, I've downloaded and compiled from the repository now.
> 
> 
>>>3. I could then set up everything with msynctool. I added a pair to
>>>   synchronize between synce and the file-sync plugin.
>>>
>>
>>that trace shows that it aborted with g_assert_warning () so there
>>should be an assert message on stdour or stderr. can you show this
>>warning to me?
> 
> 
> There were too many messages for the xterm log so it got lost. I'm
> trying to reproduce now but I managed to clear my contacts by clearing
> the directory :-)
> 
> I'll send a log of my attempts to upload it to Armin and Mirko, maybe
> it's of help to them. They show similar interaction to what I
> encountered the other day, but with another scenario (and now with
> the right software version).
> 
> 	Danny
> 
> 
>>>   The first attempt to synchronize did some work (and left a lot of
>>>   files in the file-sync directory), but then msynctool crashed. Gdb
>>>   shows the following stack trace :
>>>#0  0xffffe410 in ?? ()
>>>#1  0xb73e8c48 in ?? ()
>>>#2  0x00000006 in ?? ()
>>>#3  0x00002503 in ?? ()
>>>#4  0xb7b926e5 in raise () from /lib/tls/libc.so.6
>>>#5  0xb7b94049 in abort () from /lib/tls/libc.so.6
>>>#6  0xb7e4ad0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
>>>#7  0xb7e4ad9d in g_log () from /usr/local/lib/libglib-2.0.so.0
>>>#8  0xb7e4ae44 in g_assert_warning ()
>>>from /usr/local/lib/libglib-2.0.so.0
>>>#9  0xb7ee8211 in osync_hashtable_update_hash ()
>>>from /usr/local/lib/libopensync.so.0
>>>#10 0xb756233b in fs_commit_change ()
>>>from /usr/local/lib/opensync/plugins/file_sync.so
>>>#11 0xb7ee684a in osync_member_commit_change ()
>>>from /usr/local/lib/libopensync.so.0
>>>#12 0xb7ef8910 in client_message_handler ()
>>>from /usr/local/lib/libosengine.so.0
>>>#13 0xb7ef8363 in _queue_dispatch ()
>>>from /usr/local/lib/libosengine.so.0
>>>#14 0xb7e430c4 in g_main_dispatch ()
>>>from /usr/local/lib/libglib-2.0.so.0
>>>#15 0xb7e43f1d in g_main_context_dispatch ()
>>>from /usr/local/lib/libglib-2.0.so.0
>>>#16 0xb7e442df in g_main_context_iterate ()
>>>from /usr/local/lib/libglib-2.0.so.0
>>>#17 0xb7e448a3 in g_main_loop_run ()
>>>from /usr/local/lib/libglib-2.0.so.0
>>>#18 0xb7e5cbea in g_thread_create_proxy ()
>>>from /usr/local/lib/libglib-2.0.so.0
>>>#19 0xb7cd03b0 in start_thread () from /lib/tls/libpthread.so.0
>>>#20 0xb7c3226e in clone () from /lib/tls/libc.so.6
>>>
>>>   A second attempt to synchronize required me to answer a lot of
>>>   questions to solve synchronisation problems, but eventually the
>>>   synchronisation succeeded.
>>>
>>
>>This means that the format comparison is not yet completely correct for
>>this synchronization. Since your synchronization crashed on the previous
>>sync, opensync automatically initiated a slow-sync which means that it
>>compares every entry from the devices again.
>>
>>If the comparison is not done 100% correct, it sometimes raises
>>conflicts when it should not have. Please take a look at this quide
>>which show how to enable tracing: http://www.opensync.org/wiki/tracing
>>
>>After you have traced the synchronization which results in the
>>conflicts, please send me the trace files so i can fix this problem.
>>
>>
>>>  Danny
>>>
>>>On Thu, 2005-08-11 at 16:27 +0200, mirko wrote:
>>>
>>>
>>>>Hi, i'm trying to develop a synce-plugin for opensync.
>>>>I just made my first release.. 0.01. it should work with addressbook but
>>>>it's still buggy. 
>>>>If someone is interested please watch my blog and give a try to it:
>>>>http://www.mirkuz.net/?cat=9

Re: [Opensync-users] Hi there [synce-plugin]

[Danny B. <dan...@sc...>]

Yes it does, at line 360, in get_changeinfo().

	Danny

On Thu, 2005-08-18 at 18:10 +0200, Armin Bauer wrote:
> Hi,
>=20
> Thats very weird.
>=20
> According to the assert it stoped here:
>=20
> ** ERROR **: file opensync_hashtable.c: line 225
> (osync_hashtable_update_hash): should not be reached
> aborting...
>=20
> The weird thing is: this function never could get called from the synce
> plugin (all occurences are commented out) which leads me to the
> conclusion that either you are using a different version of the synce
> plugin than i use or the stack got corrupted in a very bad way.
>=20
> can you check if your plugin calls osync_hashtable_update_hash or
> osync_hashtable_report_deleted at some point?
>=20
> Armin
>=20
> Danny Backx wrote:
> > On Wed, 2005-08-17 at 11:09 +0200, Armin Bauer wrote:
> >=20
> >>>2. After that, msynctool --listplugins didn't pick up the new library.
> >>>   Setting OSYNC_TRACE made me discover that the symbol
> >>>	osync_plugin_new_info()
> >>>   was used by the plugin, but not defined by my installation of
> >>>   opensync. Looking through the material on opensync.org makes me
> >>>   conclude that the synce-plugin, and some of the material on
> >>>   opensync.org, are referring to a newer version of the API than
> >>>   what I have.
> >>>   So I edited the get_info call to start with this :
> >>>	void get_info(OSyncPluginInfo *info)
> >>>	{
> >>>   instead of
> >>>        void get_info(OSyncPluginInfo *env)
> >>>	{
> >>>	   OSyncPluginInfo *info =3D osync_plugin_new_info((void*)env);
> >>>
> >>>   Can someone comment on these API versions ?
> >>>
> >>
> >>i changed the API from this:
> >>
> >>get_info(OSyncPluginInfo *info)
> >>
> >>to this:
> >>
> >>get_info(OSyncPluginInfo *env)
> >>{
> >>	OSyncPluginInfo *info =3D osync_plugin_new_info((void*)env);
> >>
> >>some time ago to allow one module to register several plugins at once
> >>(this is for example used in the syncml plugin). So you have to update
> >>your opensync installation. If you would like to beta test plugins i
> >>_strongly_ suggest that you use code directly from the repository so i
> >>can deliver you fixes for bugs that will show up more easy.
> >=20
> >=20
> > Ok, I've downloaded and compiled from the repository now.
> >=20
> >=20
> >>>3. I could then set up everything with msynctool. I added a pair to
> >>>   synchronize between synce and the file-sync plugin.
> >>>
> >>
> >>that trace shows that it aborted with g_assert_warning () so there
> >>should be an assert message on stdour or stderr. can you show this
> >>warning to me?
> >=20
> >=20
> > There were too many messages for the xterm log so it got lost. I'm
> > trying to reproduce now but I managed to clear my contacts by clearing
> > the directory :-)
> >=20
> > I'll send a log of my attempts to upload it to Armin and Mirko, maybe
> > it's of help to them. They show similar interaction to what I
> > encountered the other day, but with another scenario (and now with
> > the right software version).
> >=20
> > 	Danny
> >=20
> >=20
> >>>   The first attempt to synchronize did some work (and left a lot of
> >>>   files in the file-sync directory), but then msynctool crashed. Gdb
> >>>   shows the following stack trace :
> >>>#0  0xffffe410 in ?? ()
> >>>#1  0xb73e8c48 in ?? ()
> >>>#2  0x00000006 in ?? ()
> >>>#3  0x00002503 in ?? ()
> >>>#4  0xb7b926e5 in raise () from /lib/tls/libc.so.6
> >>>#5  0xb7b94049 in abort () from /lib/tls/libc.so.6
> >>>#6  0xb7e4ad0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
> >>>#7  0xb7e4ad9d in g_log () from /usr/local/lib/libglib-2.0.so.0
> >>>#8  0xb7e4ae44 in g_assert_warning ()
> >>>from /usr/local/lib/libglib-2.0.so.0
> >>>#9  0xb7ee8211 in osync_hashtable_update_hash ()
> >>>from /usr/local/lib/libopensync.so.0
> >>>#10 0xb756233b in fs_commit_change ()
> >>>from /usr/local/lib/opensync/plugins/file_sync.so
> >>>#11 0xb7ee684a in osync_member_commit_change ()
> >>>from /usr/local/lib/libopensync.so.0
> >>>#12 0xb7ef8910 in client_message_handler ()
> >>>from /usr/local/lib/libosengine.so.0
> >>>#13 0xb7ef8363 in _queue_dispatch ()
> >>>from /usr/local/lib/libosengine.so.0
> >>>#14 0xb7e430c4 in g_main_dispatch ()
> >>>from /usr/local/lib/libglib-2.0.so.0
> >>>#15 0xb7e43f1d in g_main_context_dispatch ()
> >>>from /usr/local/lib/libglib-2.0.so.0
> >>>#16 0xb7e442df in g_main_context_iterate ()
> >>>from /usr/local/lib/libglib-2.0.so.0
> >>>#17 0xb7e448a3 in g_main_loop_run ()
> >>>from /usr/local/lib/libglib-2.0.so.0
> >>>#18 0xb7e5cbea in g_thread_create_proxy ()
> >>>from /usr/local/lib/libglib-2.0.so.0
> >>>#19 0xb7cd03b0 in start_thread () from /lib/tls/libpthread.so.0
> >>>#20 0xb7c3226e in clone () from /lib/tls/libc.so.6
> >>>
> >>>   A second attempt to synchronize required me to answer a lot of
> >>>   questions to solve synchronisation problems, but eventually the
> >>>   synchronisation succeeded.
> >>>
> >>
> >>This means that the format comparison is not yet completely correct for
> >>this synchronization. Since your synchronization crashed on the previou=
s
> >>sync, opensync automatically initiated a slow-sync which means that it
> >>compares every entry from the devices again.
> >>
> >>If the comparison is not done 100% correct, it sometimes raises
> >>conflicts when it should not have. Please take a look at this quide
> >>which show how to enable tracing: http://www.opensync.org/wiki/tracing
> >>
> >>After you have traced the synchronization which results in the
> >>conflicts, please send me the trace files so i can fix this problem.
> >>
> >>
> >>>  Danny
> >>>
> >>>On Thu, 2005-08-11 at 16:27 +0200, mirko wrote:
> >>>
> >>>
> >>>>Hi, i'm trying to develop a synce-plugin for opensync.
> >>>>I just made my first release.. 0.01. it should work with addressbook =
but
> >>>>it's still buggy.=20
> >>>>If someone is interested please watch my blog and give a try to it:
> >>>>http://www.mirkuz.net/?cat=3D9
--=20
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: [Opensync-users] Hi there [synce-plugin]

[Armin B. <arm...@de...>]

Here in my version it is commented out (with the /* */ comments). Is it
also commented in yours?

Armin

Danny Backx wrote:
> Yes it does, at line 360, in get_changeinfo().
> 
> 	Danny
> 
> On Thu, 2005-08-18 at 18:10 +0200, Armin Bauer wrote:
> 
>>Hi,
>>
>>Thats very weird.
>>
>>According to the assert it stoped here:
>>
>>** ERROR **: file opensync_hashtable.c: line 225
>>(osync_hashtable_update_hash): should not be reached
>>aborting...
>>
>>The weird thing is: this function never could get called from the synce
>>plugin (all occurences are commented out) which leads me to the
>>conclusion that either you are using a different version of the synce
>>plugin than i use or the stack got corrupted in a very bad way.
>>
>>can you check if your plugin calls osync_hashtable_update_hash or
>>osync_hashtable_report_deleted at some point?
>>
>>Armin
>>
>>Danny Backx wrote:
>>
>>>On Wed, 2005-08-17 at 11:09 +0200, Armin Bauer wrote:
>>>
>>>
>>>>>2. After that, msynctool --listplugins didn't pick up the new library.
>>>>>  Setting OSYNC_TRACE made me discover that the symbol
>>>>>	osync_plugin_new_info()
>>>>>  was used by the plugin, but not defined by my installation of
>>>>>  opensync. Looking through the material on opensync.org makes me
>>>>>  conclude that the synce-plugin, and some of the material on
>>>>>  opensync.org, are referring to a newer version of the API than
>>>>>  what I have.
>>>>>  So I edited the get_info call to start with this :
>>>>>	void get_info(OSyncPluginInfo *info)
>>>>>	{
>>>>>  instead of
>>>>>       void get_info(OSyncPluginInfo *env)
>>>>>	{
>>>>>	   OSyncPluginInfo *info = osync_plugin_new_info((void*)env);
>>>>>
>>>>>  Can someone comment on these API versions ?
>>>>>
>>>>
>>>>i changed the API from this:
>>>>
>>>>get_info(OSyncPluginInfo *info)
>>>>
>>>>to this:
>>>>
>>>>get_info(OSyncPluginInfo *env)
>>>>{
>>>>	OSyncPluginInfo *info = osync_plugin_new_info((void*)env);
>>>>
>>>>some time ago to allow one module to register several plugins at once
>>>>(this is for example used in the syncml plugin). So you have to update
>>>>your opensync installation. If you would like to beta test plugins i
>>>>_strongly_ suggest that you use code directly from the repository so i
>>>>can deliver you fixes for bugs that will show up more easy.
>>>
>>>
>>>Ok, I've downloaded and compiled from the repository now.
>>>
>>>
>>>
>>>>>3. I could then set up everything with msynctool. I added a pair to
>>>>>  synchronize between synce and the file-sync plugin.
>>>>>
>>>>
>>>>that trace shows that it aborted with g_assert_warning () so there
>>>>should be an assert message on stdour or stderr. can you show this
>>>>warning to me?
>>>
>>>
>>>There were too many messages for the xterm log so it got lost. I'm
>>>trying to reproduce now but I managed to clear my contacts by clearing
>>>the directory :-)
>>>
>>>I'll send a log of my attempts to upload it to Armin and Mirko, maybe
>>>it's of help to them. They show similar interaction to what I
>>>encountered the other day, but with another scenario (and now with
>>>the right software version).
>>>
>>>	Danny
>>>
>>>
>>>
>>>>>  The first attempt to synchronize did some work (and left a lot of
>>>>>  files in the file-sync directory), but then msynctool crashed. Gdb
>>>>>  shows the following stack trace :
>>>>>#0  0xffffe410 in ?? ()
>>>>>#1  0xb73e8c48 in ?? ()
>>>>>#2  0x00000006 in ?? ()
>>>>>#3  0x00002503 in ?? ()
>>>>>#4  0xb7b926e5 in raise () from /lib/tls/libc.so.6
>>>>>#5  0xb7b94049 in abort () from /lib/tls/libc.so.6
>>>>>#6  0xb7e4ad0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
>>>>>#7  0xb7e4ad9d in g_log () from /usr/local/lib/libglib-2.0.so.0
>>>>>#8  0xb7e4ae44 in g_assert_warning ()
>>>>
>>>>>from /usr/local/lib/libglib-2.0.so.0
>>>>
>>>>>#9  0xb7ee8211 in osync_hashtable_update_hash ()
>>>>
>>>>>from /usr/local/lib/libopensync.so.0
>>>>
>>>>>#10 0xb756233b in fs_commit_change ()
>>>>
>>>>>from /usr/local/lib/opensync/plugins/file_sync.so
>>>>
>>>>>#11 0xb7ee684a in osync_member_commit_change ()
>>>>
>>>>>from /usr/local/lib/libopensync.so.0
>>>>
>>>>>#12 0xb7ef8910 in client_message_handler ()
>>>>
>>>>>from /usr/local/lib/libosengine.so.0
>>>>
>>>>>#13 0xb7ef8363 in _queue_dispatch ()
>>>>
>>>>>from /usr/local/lib/libosengine.so.0
>>>>
>>>>>#14 0xb7e430c4 in g_main_dispatch ()
>>>>
>>>>>from /usr/local/lib/libglib-2.0.so.0
>>>>
>>>>>#15 0xb7e43f1d in g_main_context_dispatch ()
>>>>
>>>>>from /usr/local/lib/libglib-2.0.so.0
>>>>
>>>>>#16 0xb7e442df in g_main_context_iterate ()
>>>>
>>>>>from /usr/local/lib/libglib-2.0.so.0
>>>>
>>>>>#17 0xb7e448a3 in g_main_loop_run ()
>>>>
>>>>>from /usr/local/lib/libglib-2.0.so.0
>>>>
>>>>>#18 0xb7e5cbea in g_thread_create_proxy ()
>>>>
>>>>>from /usr/local/lib/libglib-2.0.so.0
>>>>
>>>>>#19 0xb7cd03b0 in start_thread () from /lib/tls/libpthread.so.0
>>>>>#20 0xb7c3226e in clone () from /lib/tls/libc.so.6
>>>>>
>>>>>  A second attempt to synchronize required me to answer a lot of
>>>>>  questions to solve synchronisation problems, but eventually the
>>>>>  synchronisation succeeded.
>>>>>
>>>>
>>>>This means that the format comparison is not yet completely correct for
>>>>this synchronization. Since your synchronization crashed on the previous
>>>>sync, opensync automatically initiated a slow-sync which means that it
>>>>compares every entry from the devices again.
>>>>
>>>>If the comparison is not done 100% correct, it sometimes raises
>>>>conflicts when it should not have. Please take a look at this quide
>>>>which show how to enable tracing: http://www.opensync.org/wiki/tracing
>>>>
>>>>After you have traced the synchronization which results in the
>>>>conflicts, please send me the trace files so i can fix this problem.
>>>>
>>>>
>>>>
>>>>> Danny
>>>>>
>>>>>On Thu, 2005-08-11 at 16:27 +0200, mirko wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi, i'm trying to develop a synce-plugin for opensync.
>>>>>>I just made my first release.. 0.01. it should work with addressbook but
>>>>>>it's still buggy. 
>>>>>>If someone is interested please watch my blog and give a try to it:
>>>>>>http://www.mirkuz.net/?cat=9

RE: [Opensync-users] Hi there [synce-plugin]

[Mirkuz <me...@li...>]

> 
> Mirko, and others,
> 
> I tried the 0.01 version of the opensync synce plugin. My 
> system has Mandrake 10.1 installed, my PDA is a Mio 168 (like 
> Mirko's). The version of opensync is 
> 	# msynctool --version
> 	This is msynctool version "0.90.14"
> 	using OpenSync version "0.14"
> 

Since the devel of the plugin is done with the svn version of opensync you
should get the source from svn and compile it ;) (I will add a note on my
dev-blog)

> Three remarks from my initial test :
> 1. It wouldn't compile without removing -Werror from src/Makefile.
>    The error was
> 	synce_plugin.c:551: warning: implicit declaration of 
> function `osync_plugin_new_info'

I will remove the -Werror from the makefile in the next rel.

Tnx for your interest ;)

Re: [Opensync-users] Hi there [synce-plugin]

[Armin B. <arm...@de...>]

Mirkuz wrote:
>>Mirko, and others,
>>
>>I tried the 0.01 version of the opensync synce plugin. My 
>>system has Mandrake 10.1 installed, my PDA is a Mio 168 (like 
>>Mirko's). The version of opensync is 
>>	# msynctool --version
>>	This is msynctool version "0.90.14"
>>	using OpenSync version "0.14"
>>
> 
> 
> Since the devel of the plugin is done with the svn version of opensync you
> should get the source from svn and compile it ;) (I will add a note on my
> dev-blog)
> 

@Mirkuz:
Would you like to add your plugin to the opensync.org subversion
repository? Just drop me a note if you would so i can give you an account.

> 
>>Three remarks from my initial test :
>>1. It wouldn't compile without removing -Werror from src/Makefile.
>>   The error was
>>	synce_plugin.c:551: warning: implicit declaration of 
>>function `osync_plugin_new_info'
> 

I think this a very good demonstration where -Werror actually makes
sense. :) After all it was correct that it complained here since there
was a API version mismatch.

> 
> I will remove the -Werror from the makefile in the next rel.
> 
> Tnx for your interest ;)
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Opensync-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-users