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

[Opensync-users] Re: Error Compiling Syncml-Plugin

[Tomislav V. <tv...@re...>]

On Tue, 2005-08-16 at 13:00 -0400, Norm Dressler wrote:
> Well, I have installed the libsyncml, libwbxml2, and libsoup as per the
> install doc but when it came to compiling the syncml plugin, I had the
> following error:
> syncml_plugin.c: In function `syncml_http_server_init':
> syncml_plugin.c:316: error: incompatible type for argument 2 of
> `smlDsServerNew'syncml_plugin.c:316: warning: passing arg 3 of
> `smlDsServerNew' from incompatible pointer type
> syncml_plugin.c:316: error: too few arguments to function
> `smlDsServerNew'

I used the patch in the attachment, which enables compiling. I still
need to set up my ip over bt before I can test it, but I hope it helps
you.

Regards,
-- 
Tomislav Vujec
Manager, Client Development
Red Hat  Otto-Hahn-Straße 20  85609 München-Dornach
Tel +49 89 205071 212 Fax +49 89 205071 111 Cell. +49 172 623 1214

[Opensync-users] Syncing two instances of opensync over network

[Dirk L. <di...@cs...>]

Hi there,

is it possible to sync two instances of opensync via network (e.g. one
as syncml client and the other one as syncml server)?

I would like to use such a feature in order to sync devices (mobile
phone, pda, laptop) to a central server.

Dirk

--

Dirk Leinenbach
Computer Science Department
Saarland University
Germany
Building 45, Room 318

Tel. +49 - 681 / 302 - 2036
Fax. +49 - 681 / 302 - 4290

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

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] opensync on x86_64

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

On Wed, August 17, 2005 11:21, Armin Bauer said:
>
>
> Roland Stoll wrote:
>> 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?

i have attached a backtrace.
After fs_initialize() returns, the value of 'member' in
osync_member_initialize() is changed. This happens only if file_sync.c is
compiled with -O2 and osync_member_get_config() is called in
fs_initialize().

Roland

Re: [Opensync-users] opensync on x86_64

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

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?

Armin

> 
> Roland.
> 
> 
> 
> -------------------------------------------------------
> 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] opensync on x86_64

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

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?


Roland.

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] Suggestion: remove -Werror

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

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.

Ill just install gcc4 here so i get these warnings as well so i can fix them

David Eriksson wrote:
> Armin & others,
> 
> I suggest that -Werror is removed from all Makefile.am files in
> OpenSync/libsyncml.
> 
> 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!
> 
> 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. 
> 
> (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! :-)
> 

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.

Re: [Opensync-users] opensync on x86_64

[Stefan B. <be...@su...>]

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)

        Stefan


-- 
Stefan Behlert

Re: [Opensync-users] Thunderbird plugin

[Aaron W. <li...@wh...>]

Hi Dan,

Dan Mosedale wrote:

> So Armin and I have talked about this before, and I still have some more
> investigation to do about some of the details of the various license
> interaction here.  Hopefully I'll find time to do this in the next month
> or two.

I have been looking into the license issue and will continue to do so. I
re-read the licenses again at a more civilised time of day and my
opinion on the issue has changed a bit. I am collecting opinions from
people in the know, so any comments would be appreciated. I will post a
short summary to the list if I get anything worth reading.

Aaron Whitehouse wrote:
>I'm sorry but I don't understand what you mean by more liberal. I just
>re-read the MPL and I understand it to be closer to the GPL than the
>LGPL.
I don't make a habit of replying to myself, but this just isn't correct
- and seeing as everyone was too polite to point it out, I though I
would. You can all take solace in the fact that I finally caught up ;).

Thanks for pointing me to the issues and for starting the bug request on
its journey,

Aaron

[Opensync-users] opensync on x86_64

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

Hi,

i tried opensync on an amd64 system. It dies with a segfault=20
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=20
result. I don't know how to track this. It seems to me, that the=20
stack gets somehow overwritten during the call to fs_initialize,=20
but this is only a guess.

btw. compiling with -Werror fails because casting void* to int=20
gives a warning on x86_64.
opensync_debug.c:65: warning: cast from pointer to integer of different siz=
e


This is a run of msynctool --sync filefile in gdb

roland@alderaan:~/opensync$ gdb ./bin/msynctool
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you ar=
e
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-linux"...Using host libthread_db library=
 "/lib/libthread_db.so.1".

(gdb) break opensync_member.c:982
No source file named opensync_member.c.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (opensync_member.c:982) pending.
(gdb) run --sync filefile
Starting program: /home/roland/opensync/bin/msynctool --sync filefile
[Thread debugging using libthread_db enabled]
[New Thread 46912515451632 (LWP 32346)]
Breakpoint 2 at 0x2aaaaad56f94: file opensync_member.c, line 982.
Pending breakpoint "opensync_member.c:982" resolved
Synchronizing group "filefile"
The previous synchronization was unlean. Slow-syncing
[Switching to Thread 46912515451632 (LWP 32346)]

Breakpoint 2, osync_member_initialize (member=3D0x515750, error=3D0x7fffffc=
fb538)
    at opensync_member.c:982
982             if (!(member->plugindata =3D functions.initialize(member, e=
rror))) {
(gdb) print *member
$1 =3D {id =3D 1, configdir =3D 0x5157e0 "/home/roland/.opensync/group1/1",
  configdata =3D 0x0, configsize =3D 0, plugin =3D 0x50a2e0,
  memberfunctions =3D 0x5156f0, group =3D 0x506740, enginedata =3D 0x512a70=
,
  plugindata =3D 0x0, format_sinks =3D 0x50a170, objtype_sinks =3D 0x50a140=
,
  pluginname =3D 0x517760 "file-sync", accepted_objtypes =3D 0x0, filters =
=3D 0x0,
  extension =3D 0x0, loop =3D 0x512b80}
(gdb) s
fs_initialize (member=3D0x7fffffcfb538, error=3D0x7fffffcfb538) at file_syn=
c.c:66
66      {
(gdb) print *member
$2 =3D {id =3D 0, configdir =3D 0x0, configdata =3D 0x0, configsize =3D 0, =
plugin =3D 0x0,
  memberfunctions =3D 0x0, group =3D 0x0, enginedata =3D 0x0, plugindata =
=3D 0x0,
  format_sinks =3D 0x0, objtype_sinks =3D 0x0, pluginname =3D 0x0,
  accepted_objtypes =3D 0x0, filters =3D 0x0, extension =3D 0x0, loop =3D 0=
x0}
(gdb) finish
Run till exit from #0  fs_initialize (member=3D0x7fffffcfb538,
    error=3D0x7fffffcfb538) at file_sync.c:66
0x00002aaaaad56f9c in osync_member_initialize (member=3D0x0,
    error=3D0x7fffffcfb538) at opensync_member.c:982
982             if (!(member->plugindata =3D functions.initialize(member, e=
rror))) {
Value returned is $3 =3D (void *) 0x517670
(gdb) print *member
Cannot access memory at address 0x0
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaad56f9f in osync_member_initialize (member=3D0x0,
    error=3D0x7fffffcfb538) at opensync_member.c:982
982             if (!(member->plugindata =3D functions.initialize(member, e=
rror))) {
(gdb)


Roland

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] Thunderbird plugin

[Dan M. <dm...@mo...>]

Armin Bauer wrote:
> Yes, you are right. The MPL license is the only problem since it would
> be more liberal than the LGPL. But i really dont want to relicense
> Opensync under the MPL or a similar license. I think the LGPL should be
> libreral enough (but the opinions differ on this point :)
>   
So Armin and I have talked about this before, and I still have some more 
investigation to do about some of the details of the various license 
interaction here.  Hopefully I'll find time to do this in the next month 
or two.

More generally, though, one thing that's worth keeping in mind: OpenSync 
becomes exponentially more attractive to both users and developers the 
more widely it's deployed.  More people are likely to contribute to it, 
including commercial vendors from the sync world and the device world. 
So logistically speaking, this means that the more comfortable your 
license appears to vendors of all flavors, the more likely the project 
is to succeed.  My experience is that vendors who are not open-source 
purists tend to be more comfortable going with more "liberal" licenses, 
for whatever that's worth.

Dan

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

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

Hi,

On Tue, Aug 16, 2005 at 07:40:08PM +0200, 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

I agree that users doesn't need -Werror. I use CFLAGS to set lots of
debugigng flags, and I can set -Werror there, too.

Unless we make sure that the code work with the most-pedantic-compiler
out there, then maybe we can keep the flag. If we aren't able to make
it compile without warnings on gcc4, I think we should remove -Werror
it until we avoid these warnings.

>=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! :-)

I guess that this is not a problem.  :)

--=20
Eduardo

[Opensync-users] Suggestion: remove -Werror

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

Armin & others,

I suggest that -Werror is removed from all Makefile.am files in
OpenSync/libsyncml.

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!

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. 

(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! :-)

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

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

[Opensync-users] Error Compiling Syncml-Plugin

[Norm D. <no...@dr...>]

Hi again...

Well, I have installed the libsyncml, libwbxml2, and libsoup as per the
install doc but when it came to compiling the syncml plugin, I had the
following error:
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include/opensync-1.0
-I/usr/local/include/libsyncml-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -Wall -Werror
-I/usr/local/include/opensync-1.0 -I/usr/local/include/libsyncml-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/libxml2 -g -O2 -MT syncml_plugin.lo -MD -MP
-MF .deps/syncml_plugin.Tpo -c syncml_plugin.c  -fPIC -DPIC
-o .libs/syncml_plugin.o
syncml_plugin.c: In function `syncml_http_server_init':
syncml_plugin.c:316: error: incompatible type for argument 2 of
`smlDsServerNew'syncml_plugin.c:316: warning: passing arg 3 of
`smlDsServerNew' from incompatible pointer type
syncml_plugin.c:316: error: too few arguments to function
`smlDsServerNew'
make[2]: *** [syncml_plugin.lo] Error 1
make[2]: Leaving directory `/home/norm/opensync/syncml-plugin/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/norm/opensync/syncml-plugin'
make: *** [all] Error 2


Any suggestions what could be wrong?  I did as the manual said --
autoreconf -sfi, ./configure then make...

 Norm 

Re: [Opensync-users] libsyncml -- how to install/build?

[Norm D. <no...@dr...>]

Thanks -- why isn't this more clear?  Shouldn't the 'documents' be under
documentation on the wiki?

On Tue, 2005-16-08 at 17:27 +0200, Stefan Armbruster wrote:
> http://www.opensync.org/wiki/syncml-guide
> 
> Stefan
> 
> Am Dienstag, 16. August 2005 17:20 schrieb Norm Dressler:
> > As the topic says -- no install/build instructions and need to
> > build/install to build the syncml plugin.
> >
> > Norm
> >
> >
> >
> > -------------------------------------------------------
> > 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
> 
> 
> -------------------------------------------------------
> 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] libsyncml -- how to install/build?

[Stefan A. <ml...@ar...>]

http://www.opensync.org/wiki/syncml-guide

Stefan

Am Dienstag, 16. August 2005 17:20 schrieb Norm Dressler:
> As the topic says -- no install/build instructions and need to
> build/install to build the syncml plugin.
>
> Norm
>
>
>
> -------------------------------------------------------
> 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

[Opensync-users] libsyncml -- how to install/build?

[Norm D. <ndr...@di...>]

As the topic says -- no install/build instructions and need to
build/install to build the syncml plugin.

Norm

Re: [Opensync-users] Opensync versus Multisync

[Norm D. <ndr...@di...>]

On Tue, 2005-16-08 at 08:11 +0200, David Eriksson wrote:
> On Mon, 2005-08-15 at 17:51 -0400, Norm Dressler wrote:
> > What I'm referring to is the pre-req for the syncml plugin from
> > libsyncml.sourceforge.net.
> 
> Yes, but the one used by OpenSync is at http://libsyncml.opensync.org/

DOH.

Ok, it finally made it through my thick skull LOL.  

What's the subversion command to download this version?  The download
link doesn't show it at all so I'm assuming you have to use subversion
to get it... 

Armin, it seems I've neglected to build new debian packages for the
latest versions as well so I'll see about doing that for you as well.

Norm

Re: [Opensync-users] Opensync versus Multisync

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

I think the best start for the syncml plugin is this wiki page:
http://www.opensync.org/wiki/syncml-guide

I changed libsyncml.sf.net to point to my libsyncml.opensync.org now.
The project space was donated to me by the original author. I just didnt
find the time yet to update it correctly. sorry for the inconvience!

Armin

David Eriksson wrote:
> On Mon, 2005-08-15 at 17:51 -0400, Norm Dressler wrote:
> 
>>What I'm referring to is the pre-req for the syncml plugin from
>>libsyncml.sourceforge.net.
> 
> 
> Yes, but the one used by OpenSync is at http://libsyncml.opensync.org/
> 
> 
>>Norm
>>
>>On Mon, 2005-15-08 at 19:50 +0200, Maciek Borowka wrote:
>>
>>>On Monday 15 August 2005 19:41, Norm Dressler wrote:
>>>
>>>>Hmm.. can't seem to compile LibSyncML on Debian.  It says I need CommonC
>>>>++ but I have installed it (commoncpp2-dev).
>>>
>>>As far as I know, LibSyncML you are talking about has nothing to do with the 
>>>libsyncml Armin has started to develop for opensync (except the name of 
>>>course).
>>>
>>>./Maciek
> 
> 

Re: [Opensync-users] Opensync versus Multisync

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

On Mon, 2005-08-15 at 17:51 -0400, Norm Dressler wrote:
> What I'm referring to is the pre-req for the syncml plugin from
> libsyncml.sourceforge.net.

Yes, but the one used by OpenSync is at http://libsyncml.opensync.org/

> Norm
> 
> On Mon, 2005-15-08 at 19:50 +0200, Maciek Borowka wrote:
> > On Monday 15 August 2005 19:41, Norm Dressler wrote:
> > > Hmm.. can't seem to compile LibSyncML on Debian.  It says I need CommonC
> > > ++ but I have installed it (commoncpp2-dev).
> > 
> > As far as I know, LibSyncML you are talking about has nothing to do with the 
> > libsyncml Armin has started to develop for opensync (except the name of 
> > course).
> > 
> > ./Maciek

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

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

Re: [Opensync-users] Opensync versus Multisync

[Norm D. <no...@dr...>]

I solved my original error with the configure (ccgnu-config needed to be
linked to ccgnu2-config).

Now I get nothing but grief compiling...is there a mailing list for
libsyncml or better yet, anyone have a working debian package?  Here are
the errors I get when I compile it:

g++ -DHAVE_CONFIG_H -I. -I. -I.. -W -D_REENTRANT -D_THREAD_SAFE
-D_GNU_SOURCE -I../include -I.. -c main.cc -MT main.lo -MD -MP
-MF .deps/main.TPlo  -fPIC -DPIC -o .libs/main.lo
In file included from /usr/include/c++/3.3/backward/iostream.h:31,
                 from ../include/syncml.h:39,
                 from main.cc:34:
/usr/include/c++/3.3/backward/backward_warning.h:32:2: warning: #warning
This file includes at least one deprecated or antiquated header. Please
consider using one of the 32 headers found in section 17.4.1.2 of the C
++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:34:
../include/syncml.h:259: error: syntax error before `=' token
../include/syncml.h:260: error: syntax error before `=' token
../include/syncml.h:261: error: syntax error before `=' token

....and it goes on and on....

On Mon, 2005-15-08 at 17:51 -0400, Norm Dressler wrote:
> What I'm referring to is the pre-req for the syncml plugin from
> libsyncml.sourceforge.net.
> 
> Norm
> 
> On Mon, 2005-15-08 at 19:50 +0200, Maciek Borowka wrote:
> > On Monday 15 August 2005 19:41, Norm Dressler wrote:
> > > Hmm.. can't seem to compile LibSyncML on Debian.  It says I need CommonC
> > > ++ but I have installed it (commoncpp2-dev).
> > 
> > As far as I know, LibSyncML you are talking about has nothing to do with the 
> > libsyncml Armin has started to develop for opensync (except the name of 
> > course).
> > 
> > ./Maciek
> > 
> 
> 
> 
> -------------------------------------------------------
> 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

[Opensync-users] Unrelated questions

[Aaron W. <li...@wh...>]

I thought it best to separate these to help those reading in the
archives. For those looking for the original post it is under "Mozilla
Thunderbird Plugin".

> <snip>So to enable opensync to sync passwords you
> would create a plugin that introduces the new object type "Password".
> Then you would introduce the formats used by passwordsafe and eWallet.
> The last thing you would need are the plugins that are capable of
> reading and writing to these 2 storages.
I see, so the creator of the object type would create a new xml format
which was the union of the formats which they expected opensync to
support. How much do the read/write plugins need to do? In the
whitepaper I recall it talking of opening/closing connections, but was
not really sure on the separation here. Is the language of SyncML in one
plugin and the HTTP plugin over which it talks in another (or am I
completely misunderstanding SyncML here)? Connections such as Bluetooth
etc. are handled at the OS level, aren't they?

>>2) I understand that opensync needs to be trained to convert between
>>formats, <snip> but how does opensync compare information in formats
>>when it is not converting? An example of this would be jPilot <snip>

> Jpilot has to do some sort of comparison to see if 2 objects contain
> the same information or if they differ.
> This would also be possible in opensync. Lets assume that we have
> contacts encoded in the format "Palm database". The format plugin
> would then provide a compare() function for this format that would
> tell you if 2 objects are the same (how the compare function does this
> is up to the developer). But the same plugin could also provide
> convert() function

Okay - I didn't realise that so much of the work was done by the plugin
itself. I assumed that the plugin 'taught' opensync to read the format,
gave it a list of what was mapped to what and that opensync did the
actual syncing and merging etc. If it is handled within the plugin it
would make plugins more powerful, but I imagine more prone to being
badly written; Am I correct in thinking that a lazy plugin writer could
omit the difficult merging code and leave the user losing data? From
your answer that seems logical, but that doesn't sit with the merging
posts which I have read about clever systems to write to each device
(regardless of type) and see by trial and error what it can handle.

> I hope this answers your question :)
I think so, thank you :).

>>3) How intelligent is the merging functionality intended to be?

> in this case opensync would merge the changes since none of the
> changes overlap.

As I just asked, will this be a global answer or only if hard-working
people such as yourself write the format plugin ;)?

> This is a very good question. in my opinion we should not try to
> overcome limitations of devices by introducing "hacks". But i guess
> people will try to do this anyways :)

If Opensync wants to consolidate all syncing projects into one, I doubt
that it will have a choice. Otherwise other projects will fill the gap
for specific devices and everyone will lose.

> This problem with recurrences is even more special <snip> Opensync
> would need to be able to detect that this is really a modification of
> another object, update the recurrence rule and write this modified
> object. This would be _VERY_ difficult.

Ergh... that sounds unpleasant. It sounds like another example of
something better written once in some global function than in each
plugin, however. Is that possible?

> The mapping of the custom fields could be done in a different way: The
> configuration of the palm plugin could hold the information on where to
> map the custom fields. This way all userinterface could easily
> implement these options.

Do you mean as mapped against fields in the Opensync xml schema? That
would be a much cleaner way to do things... and would mean that if you
had 6 pairs syncing to Evolution, you would only need to set Evolution
information up once.

> I hope i was able to answer some.

Indeed you were :).

Don't hurry yourself to reply, I would hate to think that I was pulling
people from actually writing the programme in order to answer my silly
questions ;)!

Thanks again for your time,
Aaron