opensync-users — The place to get help for the OpenSync project

[Opensync-users] amd64 and opensync

[Jason S. <jsi...@gm...>]

Has anyone tried it on amd64 OS?  I am running gentoo 64bit and
opensync failes to compile.  Here is the error that I get.

 gcc -DHAVE_CONFIG_H -I. -I. -I.. -pthread -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -Wall -I/usr/include/libxml2 -Werror
-DOPENSYNC_PLUGINDIR=3D\"/usr/local/lib/opensync/plugins\"
-DOPENSYNC_CONFIGDIR=3D\"/usr/local/share/opensync/defaults\"
-DOPENSYNC_FORMATSDIR=3D\"/usr/local/lib/opensync/formats\" -g -O2 -MT
opensync_debug.lo -MD -MP -MF .deps/opensync_debug.Tpo -c
opensync_debug.c  -fPIC -DPIC -o .libs/opensync_debug.o
opensync_debug.c: In function `osync_trace':
opensync_debug.c:64: warning: cast from pointer to integer of different siz=
e
opensync_debug.c:102: warning: cast to pointer from integer of different si=
ze
opensync_debug.c:102: warning: cast to pointer from integer of different si=
ze
make[2]: *** [opensync_debug.lo] Error 1
make[2]: Leaving directory `/home/jsievert/Desktop/libopensync-0.17/opensyn=
c'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jsievert/Desktop/libopensync-0.17'
make: *** [all] Error 2


Thanks,
Jason

Re: [Opensync-users] format an objtype swapped in trace output

[Eduardo P. H. <eha...@co...>]

On Tue, Aug 23, 2005 at 12:53:31PM +0200, Martin Felis wrote:
> Hi there,
>=20
> in the traces of opensync from function
> void osync_context_report_change(OSyncContext *context, OSyncChange
> *change) (about line 107 in opensync_context.c)
> are the format and objtype swapped.

Corrected on subversion repository. Thanks.

--=20
Eduardo

[Opensync-users] format an objtype swapped in trace output

[Martin F. <ma...@si...>]

Hi there,

in the traces of opensync from function
void osync_context_report_change(OSyncContext *context, OSyncChange
*change) (about line 107 in opensync_context.c)
are the format and objtype swapped.

bye
Martin

Re: [Opensync-users] crashes?

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

Hi,

please send me the traces of these 2 crashes so i can fix the issue with
the file-plugin.

And if you see something like g_assert_warning () it means that it did
not crash but it aborted since there is a programming bug somewhere.
Please also send me the assert message that was send to stdout in the 2.
assert.

Thanks

Armin

On Tue, 2005-08-23 at 00:58 +0200, Danny Backx wrote:
> Just wanted to send a message that I'm getting two kinds of crashes when
> trying to sync my Mio with the file-sync plugin.
> 
> One crash appears to be in the file-sync plugin :
> (gdb) where
> #0  0xffffe410 in ?? ()
> #1  0xb73efc48 in ?? ()
> #2  0x00000006 in ?? ()
> #3  0x00006641 in ?? ()
> #4  0xb7ba46e5 in raise () from /lib/tls/libc.so.6
> #5  0xb7ba6049 in abort () from /lib/tls/libc.so.6
> #6  0xb7eded0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
> #7  0xb7eded9d in g_log () from /usr/local/lib/libglib-2.0.so.0
> #8  0xb7edee44 in g_assert_warning ()
> from /usr/local/lib/libglib-2.0.so.0
> #9  0xb7e96372 in osync_hashtable_update_hash ()
> from /usr/local/lib/libopensync.so.0
> #10 0xb7b7934e in fs_commit_change ()
> from /usr/local/lib/opensync/plugins/file_sync.so
> #11 0xb7e94c3a in osync_member_commit_change ()
> from /usr/local/lib/libopensync.so.0
> #12 0xb7ea7d18 in client_message_handler ()
> from /usr/local/lib/libosengine.so.0
> #13 0xb7ea7689 in _queue_dispatch ()
> from /usr/local/lib/libosengine.so.0
> #14 0xb7ed70c4 in g_main_dispatch ()
> from /usr/local/lib/libglib-2.0.so.0
> #15 0xb7ed7f1d in g_main_context_dispatch ()
> from /usr/local/lib/libglib-2.0.so.0
> #16 0xb7ed82df in g_main_context_iterate ()
> from /usr/local/lib/libglib-2.0.so.0
> #17 0xb7ed88a3 in g_main_loop_run ()
> from /usr/local/lib/libglib-2.0.so.0
> #18 0xb7ef0bea in g_thread_create_proxy ()
> from /usr/local/lib/libglib-2.0.so.0
> #19 0xb7ce13b0 in start_thread () from /lib/tls/libpthread.so.0
> #20 0xb7c4426e in clone () from /lib/tls/libc.so.6
> 
> This may be the one where Armin said it was odd that the synce plugin
> didn't call hashing functions but did crash on them. It was the
> file-plugin that did this...
> 
> The other type of crash is this :
> #0  0xffffe410 in ?? ()
> #1  0xb6c16bd8 in ?? ()
> #2  0x00000006 in ?? ()
> #3  0x00005d2e in ?? ()
> #4  0xb7bcc6e5 in raise () from /lib/tls/libc.so.6
> #5  0xb7bce049 in abort () from /lib/tls/libc.so.6
> #6  0xb7f06d0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
> #7  0xb7f06d9d in g_log () from /usr/local/lib/libglib-2.0.so.0
> #8  0xb7f06e44 in g_assert_warning ()
> from /usr/local/lib/libglib-2.0.so.0
> #9  0xb7eba350 in osync_group_get_slow_sync ()
> from /usr/local/lib/libopensync.so.0
> #10 0xb7ebbb9c in osync_member_get_slow_sync ()
> from /usr/local/lib/libopensync.so.0
> #11 0xb7598307 in m_report_cal (ctx=0x8178938) at synce_plugin.c:485
> #12 0xb7598586 in get_changeinfo (ctx=0x8178938) at synce_plugin.c:554
> #13 0xb7ebc44d in osync_member_get_changeinfo ()
> from /usr/local/lib/libopensync.so.0
> #14 0xb7ecfccc in client_message_handler ()
> from /usr/local/lib/libosengine.so.0
> #15 0xb7ecf689 in _queue_dispatch ()
> from /usr/local/lib/libosengine.so.0
> #16 0xb7eff0c4 in g_main_dispatch ()
> from /usr/local/lib/libglib-2.0.so.0
> #17 0xb7efff1d in g_main_context_dispatch ()
> from /usr/local/lib/libglib-2.0.so.0
> #18 0xb7f002df in g_main_context_iterate ()
> from /usr/local/lib/libglib-2.0.so.0
> #19 0xb7f008a3 in g_main_loop_run ()
> from /usr/local/lib/libglib-2.0.so.0
> #20 0xb7f18bea in g_thread_create_proxy ()
> from /usr/local/lib/libglib-2.0.so.0
> #21 0xb7d093b0 in start_thread () from /lib/tls/libpthread.so.0
> #22 0xb7c6c26e in clone () from /lib/tls/libc.so.6
> 
> Cheers,
> 
> 	Danny
> 
> 
> 

[Opensync-users] crashes?

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

Just wanted to send a message that I'm getting two kinds of crashes when
trying to sync my Mio with the file-sync plugin.

One crash appears to be in the file-sync plugin :
(gdb) where
#0  0xffffe410 in ?? ()
#1  0xb73efc48 in ?? ()
#2  0x00000006 in ?? ()
#3  0x00006641 in ?? ()
#4  0xb7ba46e5 in raise () from /lib/tls/libc.so.6
#5  0xb7ba6049 in abort () from /lib/tls/libc.so.6
#6  0xb7eded0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
#7  0xb7eded9d in g_log () from /usr/local/lib/libglib-2.0.so.0
#8  0xb7edee44 in g_assert_warning ()
from /usr/local/lib/libglib-2.0.so.0
#9  0xb7e96372 in osync_hashtable_update_hash ()
from /usr/local/lib/libopensync.so.0
#10 0xb7b7934e in fs_commit_change ()
from /usr/local/lib/opensync/plugins/file_sync.so
#11 0xb7e94c3a in osync_member_commit_change ()
from /usr/local/lib/libopensync.so.0
#12 0xb7ea7d18 in client_message_handler ()
from /usr/local/lib/libosengine.so.0
#13 0xb7ea7689 in _queue_dispatch ()
from /usr/local/lib/libosengine.so.0
#14 0xb7ed70c4 in g_main_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#15 0xb7ed7f1d in g_main_context_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#16 0xb7ed82df in g_main_context_iterate ()
from /usr/local/lib/libglib-2.0.so.0
#17 0xb7ed88a3 in g_main_loop_run ()
from /usr/local/lib/libglib-2.0.so.0
#18 0xb7ef0bea in g_thread_create_proxy ()
from /usr/local/lib/libglib-2.0.so.0
#19 0xb7ce13b0 in start_thread () from /lib/tls/libpthread.so.0
#20 0xb7c4426e in clone () from /lib/tls/libc.so.6

This may be the one where Armin said it was odd that the synce plugin
didn't call hashing functions but did crash on them. It was the
file-plugin that did this...

The other type of crash is this :
#0  0xffffe410 in ?? ()
#1  0xb6c16bd8 in ?? ()
#2  0x00000006 in ?? ()
#3  0x00005d2e in ?? ()
#4  0xb7bcc6e5 in raise () from /lib/tls/libc.so.6
#5  0xb7bce049 in abort () from /lib/tls/libc.so.6
#6  0xb7f06d0d in g_logv () from /usr/local/lib/libglib-2.0.so.0
#7  0xb7f06d9d in g_log () from /usr/local/lib/libglib-2.0.so.0
#8  0xb7f06e44 in g_assert_warning ()
from /usr/local/lib/libglib-2.0.so.0
#9  0xb7eba350 in osync_group_get_slow_sync ()
from /usr/local/lib/libopensync.so.0
#10 0xb7ebbb9c in osync_member_get_slow_sync ()
from /usr/local/lib/libopensync.so.0
#11 0xb7598307 in m_report_cal (ctx=3D0x8178938) at synce_plugin.c:485
#12 0xb7598586 in get_changeinfo (ctx=3D0x8178938) at synce_plugin.c:554
#13 0xb7ebc44d in osync_member_get_changeinfo ()
from /usr/local/lib/libopensync.so.0
#14 0xb7ecfccc in client_message_handler ()
from /usr/local/lib/libosengine.so.0
#15 0xb7ecf689 in _queue_dispatch ()
from /usr/local/lib/libosengine.so.0
#16 0xb7eff0c4 in g_main_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#17 0xb7efff1d in g_main_context_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#18 0xb7f002df in g_main_context_iterate ()
from /usr/local/lib/libglib-2.0.so.0
#19 0xb7f008a3 in g_main_loop_run ()
from /usr/local/lib/libglib-2.0.so.0
#20 0xb7f18bea in g_thread_create_proxy ()
from /usr/local/lib/libglib-2.0.so.0
#21 0xb7d093b0 in start_thread () from /lib/tls/libpthread.so.0
#22 0xb7c6c26e in clone () from /lib/tls/libc.so.6

Cheers,

	Danny



--=20
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

[Opensync-users] FYI: working on SynCE plugin also

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

Armin, MirKuZ,

I just wanted to let you know I'm working on the SynCE plugin as well.

I've taken MirKuZ's 0.01 work and extended it a bit. I was just about to
post my changes when I noticed that there was a 0.02 version out :-(

So I've ported my stuff in the 0.02 code base.

The file synchronisation code which you've guessed I'm working on is not
yet functional, but I've hooked it up with MirKuZ's code. I'm posting
this for two reasons : (1) I'm (again) asking for input : is this the
right way to proceed in connecting everything, and (2) trying to keep my
version and MirKuZ's as close to each other as possible.

My current code base is available at
 http://danny.backx.info/download/libopensync-plugin-synce-0.03.tar.gz

I'm willing to collaboration via subversion (even though I've never used
it, but I do use CVS a lot) if that would help.

	Danny
--=20
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: [Opensync-users] question: backing up non-PIM data from my Mio

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

Danny Backx wrote:
> Hmm, I don't understand the 2 groups issue fully.
> 
> Some other plugins (e.g. evolution2) have multiple parts in their
> configuration, for addresses, calendar entries, and tasks.
> 
> Are you saying it is not workable to extend MirKuZ's SynCE plugin,
> with those three but also a fourth entry (one in which we say which
> directory a computer should synchronize the filesystem of my PDA) ?

no, im saying that you should extend mirkuz plugin to allow
synchronization of files. This is by far the most easy and best approach.

> 
> Or is this because most plugins have address/calendar/tasks triplets
> and it would make configuration easier if filesystem were separate ?
> 

Imagine the following situation:

You have the synce device which can synchronize either contacts (as
vcards) or files. The other side is the file-sync plugin. Now lets
assume that there is one file in the directory of the file-sync plugin
which contains a vcard.

Either you want to synchronize this vcard in the file to the addressbook
of the device or you want to synchronize the whole file into a directory
of the device. Both are equal and there is no way for opensync to decide
which synchronization would be correct.

Since i could not find a way to solve this dilemma, i decided that it
would be best to not allow such a synchronization at all.

But you can of course still sync all PIM data (notes, contacts,
calendar, tasks, email etc) in a single group.

Hope this helps :)

> Thanks,
> 
> 	Danny
> 
> On Fri, 2005-08-19 at 21:36 +0200, Armin Bauer wrote:
> 
>>Danny Backx wrote:
>>
>>>Question on how to proceed with this.
>>>
>>>I'd like to use SynCE and OpenSync to back up my PDA. Not only the PIM
>>>data (the agenda, contacts, tasks), but also some of the file structures
>>>in its memory, or on the memory card.
>>>
>>>What's the best way to do this ? One end is probably the file plugin
>>>to opensync, I'm wondering about the other end. Should that be an
>>>extension to the 0.01 synce plugin by MirKuZ (i.e. extend it to do not
>>>only tasks, agenda, .. but also files); or should it be a separate
>>>plugin like MirKuZ's that just deals with files ?
>>>
>>
>>Hi,
>>
>>the best and easiest approach would be to extend mirkuz plugin to allow
>>the synchronization of files. You just tell opensync that you are able
>>to synchronize files in the get_info function and implement the
>>necessary functions to handle this. The rest will be handled by opensync.
>>
>>Note: you cannot however synchronize files and PIM data in the same sync
>>group, you need 2 groups for this. The reason is that opensync would
>>never know if you wanted to synchronize a vcard it gets from the
>>file-sync plugin to the file storage of the device or to the addressbook.
>>
>>
>>>Thanks for the advice,
>>>
>>>	Danny

Re: [Opensync-users] question: backing up non-PIM data from my Mio

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

Hmm, I don't understand the 2 groups issue fully.

Some other plugins (e.g. evolution2) have multiple parts in their
configuration, for addresses, calendar entries, and tasks.

Are you saying it is not workable to extend MirKuZ's SynCE plugin,
with those three but also a fourth entry (one in which we say which
directory a computer should synchronize the filesystem of my PDA) ?

Or is this because most plugins have address/calendar/tasks triplets
and it would make configuration easier if filesystem were separate ?

Thanks,

	Danny

On Fri, 2005-08-19 at 21:36 +0200, Armin Bauer wrote:
>=20
> Danny Backx wrote:
> > Question on how to proceed with this.
> >=20
> > I'd like to use SynCE and OpenSync to back up my PDA. Not only the PIM
> > data (the agenda, contacts, tasks), but also some of the file structure=
s
> > in its memory, or on the memory card.
> >=20
> > What's the best way to do this ? One end is probably the file plugin
> > to opensync, I'm wondering about the other end. Should that be an
> > extension to the 0.01 synce plugin by MirKuZ (i.e. extend it to do not
> > only tasks, agenda, .. but also files); or should it be a separate
> > plugin like MirKuZ's that just deals with files ?
> >=20
>=20
> Hi,
>=20
> the best and easiest approach would be to extend mirkuz plugin to allow
> the synchronization of files. You just tell opensync that you are able
> to synchronize files in the get_info function and implement the
> necessary functions to handle this. The rest will be handled by opensync.
>=20
> Note: you cannot however synchronize files and PIM data in the same sync
> group, you need 2 groups for this. The reason is that opensync would
> never know if you wanted to synchronize a vcard it gets from the
> file-sync plugin to the file storage of the device or to the addressbook.
>=20
> > Thanks for the advice,
> >=20
> > 	Danny
--=20
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: [Opensync-users] question: backing up non-PIM data from my Mio

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

Danny Backx wrote:
> Question on how to proceed with this.
> 
> I'd like to use SynCE and OpenSync to back up my PDA. Not only the PIM
> data (the agenda, contacts, tasks), but also some of the file structures
> in its memory, or on the memory card.
> 
> What's the best way to do this ? One end is probably the file plugin
> to opensync, I'm wondering about the other end. Should that be an
> extension to the 0.01 synce plugin by MirKuZ (i.e. extend it to do not
> only tasks, agenda, .. but also files); or should it be a separate
> plugin like MirKuZ's that just deals with files ?
> 

Hi,

the best and easiest approach would be to extend mirkuz plugin to allow
the synchronization of files. You just tell opensync that you are able
to synchronize files in the get_info function and implement the
necessary functions to handle this. The rest will be handled by opensync.

Note: you cannot however synchronize files and PIM data in the same sync
group, you need 2 groups for this. The reason is that opensync would
never know if you wanted to synchronize a vcard it gets from the
file-sync plugin to the file storage of the device or to the addressbook.

> Thanks for the advice,
> 
> 	Danny

[Opensync-users] question: backing up non-PIM data from my Mio

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

Question on how to proceed with this.

I'd like to use SynCE and OpenSync to back up my PDA. Not only the PIM
data (the agenda, contacts, tasks), but also some of the file structures
in its memory, or on the memory card.

What's the best way to do this ? One end is probably the file plugin
to opensync, I'm wondering about the other end. Should that be an
extension to the 0.01 synce plugin by MirKuZ (i.e. extend it to do not
only tasks, agenda, .. but also files); or should it be a separate
plugin like MirKuZ's that just deals with files ?

Thanks for the advice,

	Danny
--=20
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: [Opensync-users] "Member has not instanced a plugin yet"

[Eduardo P. H. <eha...@co...>]

On Fri, Aug 19, 2005 at 07:49:52PM +0200, Armin Bauer wrote:
> No problem. :)
> I should really add a trace that dumps the version of all components so
> i see this more easy.
>=20
> A question to everybody:
> I would like to have a get_version() function on all components that
> returns the current version as a const char *. It should work like this:
> If it is build from a downloaded package it should return the version
> like "0.17". But if it is checked out from the svn repository it should
> return something like: "svn:$revision" where revision is well the
> revision where it was last checked out.
> Does anyone know how to do this?

I think that the main problem is that the keyword expansion of subversion
doesn't have, AFAIK, a practical way to get the last revision of the a
whole directory, instead of the last revision the file where the keyword
is located.

--=20
Eduardo

Re: [Opensync-users] "Member has not instanced a plugin yet"

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

No problem. :)
I should really add a trace that dumps the version of all components so
i see this more easy.

A question to everybody:
I would like to have a get_version() function on all components that
returns the current version as a const char *. It should work like this:
If it is build from a downloaded package it should return the version
like "0.17". But if it is checked out from the svn repository it should
return something like: "svn:$revision" where revision is well the
revision where it was last checked out.
Does anyone know how to do this?

Armin

Zach Bean wrote:
> Quoting Armin Bauer <arm...@de...>:
> 
> 
>>Hi Zach,
>>
>>i found the error. you are using a old version if the msynctool.
>>Please
>>update multisync 0.90.
> 
> 
> Oops... I can't believe I did that...  it works great now.
> 
> Sorry for wasting your time :o)
> 
> Zach
> 

Re: [Opensync-users] "Member has not instanced a plugin yet"

[Zach B. <zb...@fo...>]

Quoting Armin Bauer <arm...@de...>:

> Hi Zach,
> 
> i found the error. you are using a old version if the msynctool.
> Please
> update multisync 0.90.

Oops... I can't believe I did that...  it works great now.

Sorry for wasting your time :o)

Zach

-- 
And I say, Give me back my memory, or I'll rip you into three boy scouts
and a watchband!
                                           ---Aaron in "Remind Me Again"
------------------------------------------------------------------------
Zach Bean, zb...@fo..., we...@fo...          http://www.forty2.com

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]

[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] "Member has not instanced a plugin yet"

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

Hi Zach,

i found the error. you are using a old version if the msynctool. Please
update multisync 0.90.

The version you are using is calling osync_member_get_config which means
that it only tries to read the config from the member. But there cannot
be a config at this time since you are trying to configure it. The new
version calls osync_member_get_config_or_default.

Armin

Zach Bean wrote:
> Quoting Armin Bauer <arm...@de...>:
> 
> 
>>Glad to hear you like opensync. :)
>>
>>Please send me the traces so i can take a look.
> 
> 
> I've attached the trace file for you.  Thanks a lot for your help!
> 
> Zach
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> [1124402376.204030]	>>>>>>>  osync_env_initialize(0x804d5d0, 0xbffffd18)
> [1124402376.204603]		>>>>>>>  osync_env_load_plugins(0x804d5d0, (null), 0xbffffd18)
> [1124402376.221605]			>>>>>>>  osync_module_load_dir(0x804d5d0, /usr/local/lib/opensync/plugins, 0xbffffd18)
> [1124402376.276758]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/plugins/file_sync.so, 0xbffffc54)
> [1124402376.850702]					osync_plugin_new_info(0x804d5d0): 0x8051910
> [1124402376.851245]				<<<<<<<  osync_module_load: 0x8051040
> [1124402376.851886]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/plugins/syncml_plugin.so, 0xbffffc54)
> [1124402377.599342]					osync_plugin_new_info(0x804d5d0): 0x8054058
> [1124402377.599825]				<<<<<<<  osync_module_load: 0x8050fd0
> [1124402377.600429]			<<<<<<<  osync_module_load_dir
> [1124402377.600907]		<<<<<<<  osync_env_load_plugins
> [1124402377.601201]		>>>>>>>  osync_env_load_formats(0x804d5d0, (null), 0xbffffd18)
> [1124402377.601576]			>>>>>>>  osync_module_load_dir(0x804d5d0, /usr/local/lib/opensync/formats, 0xbffffd18)
> [1124402377.623209]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/xml-vcard.so, 0xbffffc54)
> [1124402377.698760]					osync_env_format_set_compare_func(0x804d5d0, xml-contact, 0x4064b670)
> [1124402377.699365]				<<<<<<<  osync_module_load: 0x8054850
> [1124402377.700368]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/xml-vcal.so, 0xbffffc54)
> [1124402377.758347]					osync_env_format_set_compare_func(0x804d5d0, xml-event, 0x40659ad0)
> [1124402377.759017]					osync_env_format_set_compare_func(0x804d5d0, xml-todo, 0x40659ba0)
> [1124402377.759317]				<<<<<<<  osync_module_load: 0x8054d68
> [1124402377.760077]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/xml-evolution.so, 0xbffffc54)
> [1124402378.112218]				<<<<<<<  osync_module_load: 0x8054e50
> [1124402378.112672]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/xml-vnote.so, 0xbffffc54)
> [1124402378.301576]					osync_env_format_set_compare_func(0x804d5d0, xml-note, 0x40673d20)
> [1124402378.301907]				<<<<<<<  osync_module_load: 0x80558e0
> [1124402378.302917]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/xml-kde.so, 0xbffffc54)
> [1124402378.344725]				<<<<<<<  osync_module_load: 0x8055da0
> [1124402378.485883]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/data.so, 0xbffffc54)
> [1124402378.503252]					osync_env_format_set_compare_func(0x804d5d0, plain, 0x4009c9e0)
> [1124402378.503744]				<<<<<<<  osync_module_load: 0x8055f38
> [1124402378.504648]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/event.so, 0xbffffc54)
> [1124402378.659179]					osync_env_format_set_compare_func(0x804d5d0, vevent10, 0x40603b20)
> [1124402378.659470]					osync_env_format_set_compare_func(0x804d5d0, vevent20, 0x40603b20)
> [1124402378.659686]				<<<<<<<  osync_module_load: 0x8056388
> [1124402378.660085]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/todo.so, 0xbffffc54)
> [1124402378.797035]					osync_env_format_set_compare_func(0x804d5d0, vtodo10, 0x40685b20)
> [1124402378.797442]					osync_env_format_set_compare_func(0x804d5d0, vtodo20, 0x40685b20)
> [1124402378.797777]				<<<<<<<  osync_module_load: 0x80568f0
> [1124402378.798468]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/contact.so, 0xbffffc54)
> [1124402378.896195]					osync_env_format_set_compare_func(0x804d5d0, vcard21, 0x40688c00)
> [1124402378.896601]					osync_env_format_set_compare_func(0x804d5d0, vcard30, 0x40688c00)
> [1124402378.896954]				<<<<<<<  osync_module_load: 0x8056e48
> [1124402378.897838]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/note.so, 0xbffffc54)
> [1124402378.965804]					osync_env_format_set_compare_func(0x804d5d0, vnote11, 0x404d6b90)
> [1124402378.966206]				<<<<<<<  osync_module_load: 0x8057418
> [1124402378.966679]				>>>>>>>  osync_module_load(0x804d5d0, /usr/local/lib/opensync/formats/file.so, 0xbffffc54)
> [1124402379.128131]					osync_env_format_set_compare_func(0x804d5d0, file, 0x4068bde0)
> [1124402379.128593]				<<<<<<<  osync_module_load: 0x80578e0
> [1124402379.129161]			<<<<<<<  osync_module_load_dir
> [1124402379.129479]		<<<<<<<  osync_env_load_formats
> [1124402379.137431]		[OSUSR] DEBUG: Detected User:
> UID: 1001
> GID: 1001
> Home: /home/zb
> OSyncDir: /home/zb/.opensync
> [1124402379.138486]		>>>>>>>  osync_group_load(0x804d5d0, /home/zb/.opensync/group1, 0xbffffc84)
> [1124402379.138700]			[OSGRP] DEBUG: Trying to load group from directory /home/zb/.opensync/group1
> [1124402379.138937]			>>>>>>>  osync_conv_env_new(0x804d5d0)
> [1124402379.139351]				New converter from vcard21 to xml-contact
> [1124402379.139635]				New converter from xml-contact to vcard21
> [1124402379.140111]				New converter from vcard30 to xml-contact
> [1124402379.140557]				New converter from xml-contact to vcard30
> [1124402379.141203]				New converter from vevent10 to xml-event
> [1124402379.141577]				New converter from xml-event to vevent10
> [1124402379.141897]				New converter from vevent20 to xml-event
> [1124402379.142254]				New converter from xml-event to vevent20
> [1124402379.142588]				New converter from vtodo10 to xml-todo
> [1124402379.142903]				New converter from xml-todo to vtodo10
> [1124402379.143360]				New converter from vtodo20 to xml-todo
> [1124402379.143720]				New converter from xml-todo to vtodo20
> [1124402379.144052]				New converter from vnote11 to xml-note
> [1124402379.144359]				New converter from xml-note to vnote11
> [1124402379.144663]				New converter from file to plain
> [1124402379.144865]				New converter from plain to file
> [1124402379.145206]			<<<<<<<  osync_conv_env_new: 0x804f1f8
> [1124402381.20295]			>>>>>>>  osync_member_load(0x804f098, /home/zb/.opensync/group1/1, 0xbffffc84)
> [1124402381.227923]			<<<<<<<  osync_member_load: Loaded member: 0x8059560
> [1124402381.228301]			>>>>>>>  osync_member_load(0x804f098, /home/zb/.opensync/group1/2, 0xbffffc84)
> [1124402381.229483]			<<<<<<<  osync_member_load: Loaded member: 0x8059a20
> [1124402381.229801]		<<<<<<<  osync_group_load
> [1124402381.230093]	<<<<<<<  osync_env_initialize
> [1124402381.230495]	>>>>>>>  osync_member_get_config(0x8059560, 0xbffffcb0, 0xbffffcb4, 0xbffffcb8)
> [1124402381.230754]	<--- ERROR --- osync_member_get_config: Member has not instanced a plugin yet
> [1124402381.231699]	>>>>>>>  osync_env_finalize(0x804d5d0, 0xbffffd18)
> [1124402381.231960]		osync_plugin_free(0x8051910)
> [1124402381.232160]		osync_plugin_free(0x8054058)
> [1124402381.232485]		osync_module_unload(0x804d5d0, 0x8051040)
> [1124402381.232719]		osync_module_unload(0x804d5d0, 0x8050fd0)
> [1124402381.232944]		osync_module_unload(0x804d5d0, 0x8054850)
> [1124402381.233163]		osync_module_unload(0x804d5d0, 0x8054d68)
> [1124402381.233482]		osync_module_unload(0x804d5d0, 0x8054e50)
> [1124402381.233687]		osync_module_unload(0x804d5d0, 0x80558e0)
> [1124402381.233885]		osync_module_unload(0x804d5d0, 0x8055da0)
> [1124402381.234095]		osync_module_unload(0x804d5d0, 0x8055f38)
> [1124402381.234306]		osync_module_unload(0x804d5d0, 0x8056388)
> [1124402381.234515]		osync_module_unload(0x804d5d0, 0x80568f0)
> [1124402381.234729]		osync_module_unload(0x804d5d0, 0x8056e48)
> [1124402381.234937]		osync_module_unload(0x804d5d0, 0x8057418)
> [1124402381.235134]		osync_module_unload(0x804d5d0, 0x80578e0)
> [1124402381.235483]	<<<<<<<  osync_env_finalize

Re: [Opensync-users] "Member has not instanced a plugin yet"

[Zach B. <zb...@fo...>]

Quoting Armin Bauer <arm...@de...>:

> Glad to hear you like opensync. :)
> 
> Please send me the traces so i can take a look.

I've attached the trace file for you.  Thanks a lot for your help!

Zach


-- 
And I say, Give me back my memory, or I'll rip you into three boy scouts
and a watchband!
                                           ---Aaron in "Remind Me Again"
------------------------------------------------------------------------
Zach Bean, zb...@fo..., we...@fo...          http://www.forty2.com

Re: [Opensync-users] "Member has not instanced a plugin yet"

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

Zach Bean wrote:
> Hi all,
> 
> I've been trying to set up opensync for the last couple of days, using
> the
> instructions at SetupGuide in the wiki.  Creating the group and adding
> members seems to work just fine, but when I try to configure them, this
> happens:
> 
> $ msynctool --showgroup filefile
> Groupname: filefile
> Member 1: file-sync
> Member 2: file-sync
> $ msynctool --configure filefile 1
> Unable to get configdata for member 1: Member has not instanced a plugin
> yet
> 
> Turning on tracing reveals that this error comes from
> osync_member_get_config, but looking at the code, I was unable to figure
> out what was going wrong.
> 
> I've tried using versions 0.16, 0.17 and svn revision 597, and they all
> give the same error.
> 
> I'd be very appreciative for any help you might be able to give me.
> Opensync looks like a really nice project, and I'm anxious to play with
> it
> :o)
> 

Hi,

Glad to hear you like opensync. :)

Please send me the traces so i can take a look

Armin

> Thanks,
> Zach Bean
> 

[Opensync-users] "Member has not instanced a plugin yet"

[Zach B. <zb...@fo...>]

Hi all,

I've been trying to set up opensync for the last couple of days, using
the
instructions at SetupGuide in the wiki.  Creating the group and adding
members seems to work just fine, but when I try to configure them, this
happens:

$ msynctool --showgroup filefile
Groupname: filefile
Member 1: file-sync
Member 2: file-sync
$ msynctool --configure filefile 1
Unable to get configdata for member 1: Member has not instanced a plugin
yet

Turning on tracing reveals that this error comes from
osync_member_get_config, but looking at the code, I was unable to figure
out what was going wrong.

I've tried using versions 0.16, 0.17 and svn revision 597, and they all
give the same error.

I'd be very appreciative for any help you might be able to give me.
Opensync looks like a really nice project, and I'm anxious to play with
it
:o)

Thanks,
Zach Bean

-- 
And I say, Give me back my memory, or I'll rip you into three boy scouts
and a watchband!
                                           ---Aaron in "Remind Me Again"
------------------------------------------------------------------------
Zach Bean, zb...@fo..., we...@fo...          http://www.forty2.com

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] Trouble with syncml plugin

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

Ciro Scognamiglio wrote:
> Armin Bauer wrote:
> 
>>Hi,
>>
>>sorry that i didnt provide much information on how to use this plugin:
>>
>>Please see http://www.opensync.org/wiki/syncml-guide for a guide how to
>>use the syncml plugin.
>>
>>Please note: This plugin is pre-beta and will likely fail. I am really
>>thankfull that you consider beta testing my software! Please report any
>>bugs you encounter so i can fix them quickly
>>
> 
> 
> does the actual version of the syncml plugin "do something"?
> I have just installed and configured everything on my machine but I
> cannot get my p800 sync with opensync via syncml.
> 
> It simply abort the initial connection telling "could not estabilish a
> connection, check settings, try later" (this on the phone)
> 
> I have yet to try sniffing the traffic between the two, but first I
> would like to know if the syncml plugin can actually sync something :)
> 

Yes the syncml plugin can sync but at the moment there are some bugs
that prevent the start of the sync for some devices. These should be
fixed in some days. Im already working on this.

I will post a message to this list once it is ready.

thanks for considering beta testing opensync :)

> I have created a profile syncml<->file and configured correctly
> everything....even though I have noticed that the "resource" names are
> not configured anywhere.
> On the phone (and in general with syncml applications) one should
> specify the name of a resource (like "addressbook" or "notes"), infact
> in the old multisync it worked this way...
> 
> any hints?
> I would like to get kde and my phone synced once for all :) (and I am
> talking about addressbook, notes and calendar please ;))
> 
> C.
> 
> 
> -------------------------------------------------------
> 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

Re: [Opensync-users] Trouble with syncml plugin

[Ciro S. <mo...@ol...>]

Armin Bauer wrote:
> Hi,
> 
> sorry that i didnt provide much information on how to use this plugin:
> 
> Please see http://www.opensync.org/wiki/syncml-guide for a guide how to
> use the syncml plugin.
> 
> Please note: This plugin is pre-beta and will likely fail. I am really
> thankfull that you consider beta testing my software! Please report any
> bugs you encounter so i can fix them quickly
> 

does the actual version of the syncml plugin "do something"?
I have just installed and configured everything on my machine but I
cannot get my p800 sync with opensync via syncml.

It simply abort the initial connection telling "could not estabilish a
connection, check settings, try later" (this on the phone)

I have yet to try sniffing the traffic between the two, but first I
would like to know if the syncml plugin can actually sync something :)

I have created a profile syncml<->file and configured correctly
everything....even though I have noticed that the "resource" names are
not configured anywhere.
On the phone (and in general with syncml applications) one should
specify the name of a resource (like "addressbook" or "notes"), infact
in the old multisync it worked this way...

any hints?
I would like to get kde and my phone synced once for all :) (and I am
talking about addressbook, notes and calendar please ;))

C.

Re: [Opensync-users] opensync on x86_64

[Roland S. <ro...@xi...>]

On Wed, August 17, 2005 11:21, Armin Bauer said:
>
>
> Roland Stoll wrote:
>> On Wed, August 17, 2005 10:38, Stefan Behlert said:
>>
>>>Moin,
>>>
>>>On Aug 16, 05 23:26:47 +0200, Roland Stoll wrote:
>>>
>>>>Hi,
>>>>
>>>>i tried opensync on an amd64 system. It dies with a segfault
>>>>in osync_member_initialize when the initialize function of the
>>>>plugin is called.
>>>>I tried this with gcc-3.2 -3.3 and -4.0 and always got the same
>>>>result. I don't know how to track this. It seems to me, that the
>>>>stack gets somehow overwritten during the call to fs_initialize,
>>>>but this is only a guess.
>>>>
>>>>btw. compiling with -Werror fails because casting void* to int
>>>>gives a warning on x86_64.
>>>>opensync_debug.c:65: warning: cast from pointer to integer of different
>>>>size
>>>
>>>I've appended a patch, please try to apply that and see if it's better
>>>then.
>>>(I currently don't have time to check the latest version, so the patch
>>>might not be sufficient)
>>>
>>
>>
>> Thank you. This solved the compilation issue.
>>
>> running msynctool --sync on a group with a file-sync still segfaults. I
>> found out, that it works when file_sync.c is compiled without
>> optimizations.
>>
>> Is this a gcc bug maybe?
>>
>
> Maybe its just another assumption i made about the size of variables
> that are not true any more on x64. Can you please show me a backtrace of
> this new segfault?

You're right. attached is a patch that solves this problem.
gsize is 8 byte on x86_64 and casting (int*) to (gsize*) in 
osync_file_read() overwrites the stack in fs_initialize which leads to the
wrong value of member in osync_member_initialize().
I didn't want to change the interface, so i used a temp. variable.

Now i can try to sync something :-)

Roland.

Re: [Opensync-users] Suggestion: remove -Werror

[Eduardo P. H. <eha...@co...>]

On Wed, Aug 17, 2005 at 11:00:32AM +0200, Armin Bauer wrote:
> I dont think this is a good idea. After all the warnings are supposed to
> help us by warning us of a possible problem. So i think its better if we
> go the hard way and just fix these compilation problems.

Well, that's a good point. -Werror is a problem only if we take too much
time to fix the compilation problems, and doesn't add any note or warning
anywhere, saying that the code as-is (i.e. without changes on Makefile)
won't build on gcc4 (that is the case until we fix the gcc4 warnings).

>=20
> Ill just install gcc4 here so i get these warnings as well so i can fix t=
hem

If we fix the warning, I agree to keep the flag. What I think that we
couldn't keep doing was: having code that we know that won't build,
and no warning anywhere about it.

BTW, I've just compiled opensyn cusing gcc 4.0.1, and I haven't seen any
warning. Is any of you seeing warnings on building opensync (I haven't
tested the plugins neither multisync) using gcc4?

>=20
> David Eriksson wrote:
> > Armin & others,
> >=20
> > I suggest that -Werror is removed from all Makefile.am files in
> > OpenSync/libsyncml.
> >=20
> > This will prevent unneccessary support requests for compilation problems
> > caused by stricted compilers (gcc4 :-) -- I have had a fair share of
> > those in SynCE for this reason!
> >=20
> > For developers, the same effect as having -Werror in Makefile.am can be
> > attained by setting the CFLAGS environment variable to -Werror before
> > running ./configure.=20
> >=20
> > (In order for this to work, it must be made sure that AM_CFLAGS and not
> > CFLAGS is used Makefile.am for this to work properly, but I don't think
> > this is an issue with OpenSync! :-)
> >=20
>=20
> I took a quickl look and im using AM_CFLAGS everywhere so this should
> already work. But like i said i think its better to use -Werror.

--=20
Eduardo