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

[Opensync-users] Re: kdepim plugin crashing

[Guillaume P. <gpo...@gm...>]

Some news: I no longer experiment the crash.
Reason: unknown.
The only thing I did was to compile kitchensync as described here
(http://www.opensync.org/wiki/kitchensync), only changing KDE version
from 3.4 to 3.5. Then I launched kitchensync, which listed my "g"
group with its members. I tried to sync once - it crashed. Later I
relaunched kitchensync and it didn't crash. It even actually did
something with my phone, as the phone showed a synchronization
progress bar. Exactly what it did I don't know, as no contact on the
phone or in Kontact have changed...
But the fact is that the CLI doesn't crash anymore. It fails with an
OBEX error instead...
I'll hack a bit more now...
g

On 2/6/06, Guillaume Pothier <gpo...@gm...> wrote:
> Hi, I'm experiencing a systematic crash of the kdepim plugin with
> v0.18 as well as with latest svn sources.
>
> I have a sync group called "g" with a kdepim member and a irmc member.
> Below is the output of "msynctool --sync g". This is with latest svn
> version of opensync and kdepim plugin, with debugging turned on.
> My box has kde 3.5.1 from kubuntu breezy. KAdressBook is v3.5
> Any idea how I could fix this? Is there a way I can get a stack trace?
> g
>
>
>
> --------------------------
> gpothier@tadzim:~/tmp/opensync/svn/opensync$ msynctool --sync g
> [OSUSR] DEBUG: Detected User:
> UID: 1000
> GID: 1000
> Home: /home/gpothier
> OSyncDir: /home/gpothier/.opensync
> [OSGRP] DEBUG: Trying to load group from directory
> /home/gpothier/.opensync/group1
> Synchronizing group "g"
> [CLI] DEBUG: Creating new client 0x8052640
> [CLI] DEBUG: Creating new client 0x8052ae0
> [GRP] FULL DEBUG: locking file /home/gpothier/.opensync/group1/lock
> [GRP] FULL DEBUG: locking group: file exists
> [GRP] FULL DEBUG: Successfully locked
> [ENG] WARNING: Detected stale lock file. Slow-syncing
> The previous synchronization was unclean. Slow-syncing
> [ENG] FULL DEBUG: Sending message 0x80530b0:"ENGINE_CHANGED"
> [OSMEM] DEBUG: Instancing plugin kdepim-sync for member 1
> [kde] DEBUG: kde_initialize
> [kde] DEBUG: Loading implementation module
> [kde] DEBUG: Getting initialization function
> [kde] DEBUG: Initializing implementation module
> [OSMEM] DEBUG: Instancing plugin irmc-sync for member 2
> [ENG] DEBUG: Running the main loop
> [OSDB] DEBUG: Preparing to load changes from file
> /home/gpothier/.opensync/group1/change.db
> [OSDB] INFORMATION: Unable create changes table! table tbl_changes
> already exists
> [OSDB] DEBUG: Unable step count! not an error
> [ENG] DEBUG: Calling all client deciders (2)
> [ENG] FULL DEBUG: Sending message 0x806cbf0:"CLIENT_CHANGED" for
> client 0x8052640
> [ENG] FULL DEBUG: Sending message 0x80893f8:"CLIENT_CHANGED" for
> client 0x8052ae0
> [CLI] DEBUG: Client message handler called for message "CONNECT"
> [CLI] DEBUG: Client message handler called for message "CONNECT"
> KCrash: Application 'libopensync-kdepim-plugin' crashing...
> Segmentation fault
>

Re: [Opensync-users] How did you get SVN sources to compile with Ubuntu?

[Guillaume P. <gpo...@gm...>]

I remember that before ./configure & make & make install I did an
"autoreconf -s -i". My versions of autoreconf, autoconf and automake
are the same as yours.
I don't remember doing anything special.
I also compiled kitchensync, the UI shows up but it crashes when I try
to sync. But the CLI also crashes...
g

On 2/6/06, Achim Spangler <A.S...@os...> wrote:
> Hi,
> all - beginning from core opensync library, over the plugins kdepim and i=
rmc
> to the GUI multisync.
>
> So I think that the setup style of all opensync items are not compatible =
to
> the development tool chain in Ubuntu Breezy.
>
> I tried already copying the created files from 0.18 snapshort to the svn
> checkout working copy - but that doesn't help.
>
> Bye,
> Achim
> Am Montag, 6. Februar 2006 17:40 schrieb Guillaume Pothier:
> > Hi, I didn't have this problem with macros, but now that I think of it
> > I didn't compile the irmc plugin from svn (I still use v0.18). Which
> > module/plugin gave you the trouble?
> > g
> >
> > On 2/6/06, Achim Spangler <Ach...@mn...> wrote:
> > > Hi Guillaume,
> > > sorry for the offtopic response. But people like you with the same se=
tup
> > > could help me quite fast.
> > >
> > > What did you to avoid autoconf problems when compiling from SVN sourc=
es?
> > >
> > > I have nearly the same setup as you - but struggle with autoconf
> > > undefined macors (see my post).
> > >
> > > Thanks,
> > > Achim
> > >
> > > Am Montag, 6. Februar 2006 17:28 schrieb Guillaume Pothier:
> > > > My box has kde 3.5.1 from kubuntu breezy. KAdressBook is v3.5
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through lo=
g
> > > files for problems?  Stop!  Download the new AJAX search engine that
> > > makes searching your log files as easy as surfing the  web.  DOWNLOAD
> > > SPLUNK!
> > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&d=
at=3D121642
> > > _______________________________________________
> > > Opensync-users mailing list
> > > Ope...@li...
> > > https://lists.sourceforge.net/lists/listinfo/opensync-users
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files for problems?  Stop!  Download the new AJAX search engine that ma=
kes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=12164=
2
> > _______________________________________________
> > Opensync-users mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-users
>
> --
> Achim Spangler
> OSB AG Ingenieur- und IT-Dienstleistungen
> Klenzestra=DFe 38
> 80469 M=FCnchen
> Fon:   +49 (0) 89/23 88 57-49
> Fax:   +49 (0) 89/23 88 57-40
> Mobil: +49 (0)179/29 22 888
> Email: a.s...@os...
> WWW:  http://www.osb-ag.de/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Opensync-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-users
>

RE: [Opensync-users] How did you get SVN sources to compile with Ubuntu?

[<st...@ru...>]

I think you're probably referring to the "Debian way" of managing =
multiple versions of the same application. They use the term =
"alternatives".

The problem that you're having (me thinks) is that Ubuntu comes with =
version 1.4 as the "default" for automake but to build opensync you need =
to use 1.9 of automake.

So try the following:

1) Make sure that you have version 1.9 of automake installed on your =
system. (Run aptitude and check for the package "automake1.9". Install =
that if you need to).
2) Next run the command "sudo update-alternatives --config automake". =
This will bring up a list in which you'll be able to select version 1.9 =
as the default version.

After doing this, try to build opensync and see if you get further.

Hope this helps.

Regards, Stefan Freyr.

-----Original Message-----
From: ope...@li... on behalf of Achim =
Spangler
Sent: Mon 2/6/2006 4:34 PM
To: ope...@li...
Subject: [Opensync-users] How did you get SVN sources to compile with =
Ubuntu?
=20
Hi Guillaume,
sorry for the offtopic response. But people like you with the same setup =
could=20
help me quite fast.

What did you to avoid autoconf problems when compiling from SVN sources?

I have nearly the same setup as you - but struggle with autoconf =
undefined=20
macors (see my post).

Thanks,
Achim
Am Montag, 6. Februar 2006 17:28 schrieb Guillaume Pothier:
> My box has kde 3.5.1 from kubuntu breezy. KAdressBook is v3.5


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
_______________________________________________
Opensync-users mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensync-users

Re: [Opensync-users] How did you get SVN sources to compile with Ubuntu?

[Achim S. <A.S...@os...>]

Hi,
all - beginning from core opensync library, over the plugins kdepim and irm=
c=20
to the GUI multisync.

So I think that the setup style of all opensync items are not compatible to=
=20
the development tool chain in Ubuntu Breezy.

I tried already copying the created files from 0.18 snapshort to the svn=20
checkout working copy - but that doesn't help.

Bye,
Achim
Am Montag, 6. Februar 2006 17:40 schrieb Guillaume Pothier:
> Hi, I didn't have this problem with macros, but now that I think of it
> I didn't compile the irmc plugin from svn (I still use v0.18). Which
> module/plugin gave you the trouble?
> g
>
> On 2/6/06, Achim Spangler <Ach...@mn...> wrote:
> > Hi Guillaume,
> > sorry for the offtopic response. But people like you with the same setup
> > could help me quite fast.
> >
> > What did you to avoid autoconf problems when compiling from SVN sources?
> >
> > I have nearly the same setup as you - but struggle with autoconf
> > undefined macors (see my post).
> >
> > Thanks,
> > Achim
> >
> > Am Montag, 6. Februar 2006 17:28 schrieb Guillaume Pothier:
> > > My box has kde 3.5.1 from kubuntu breezy. KAdressBook is v3.5
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files for problems?  Stop!  Download the new AJAX search engine that
> > makes searching your log files as easy as surfing the  web.  DOWNLOAD
> > SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> > _______________________________________________
> > Opensync-users mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-users
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Opensync-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-users

=2D-=20
Achim Spangler
OSB AG Ingenieur- und IT-Dienstleistungen
Klenzestra=DFe 38
80469 M=FCnchen
=46on:   +49 (0) 89/23 88 57-49
=46ax:   +49 (0) 89/23 88 57-40
Mobil: +49 (0)179/29 22 888
Email: a.s...@os...
WWW:  http://www.osb-ag.de/

Re: [Opensync-users] How did you get SVN sources to compile with Ubuntu?

[Guillaume P. <gpo...@gm...>]

Hi, I didn't have this problem with macros, but now that I think of it
I didn't compile the irmc plugin from svn (I still use v0.18). Which
module/plugin gave you the trouble?
g

On 2/6/06, Achim Spangler <Ach...@mn...> wrote:
> Hi Guillaume,
> sorry for the offtopic response. But people like you with the same setup =
could
> help me quite fast.
>
> What did you to avoid autoconf problems when compiling from SVN sources?
>
> I have nearly the same setup as you - but struggle with autoconf undefine=
d
> macors (see my post).
>
> Thanks,
> Achim
> Am Montag, 6. Februar 2006 17:28 schrieb Guillaume Pothier:
> > My box has kde 3.5.1 from kubuntu breezy. KAdressBook is v3.5
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Opensync-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-users
>

[Opensync-users] How did you get SVN sources to compile with Ubuntu?

[Achim S. <Ach...@mn...>]

Hi Guillaume,
sorry for the offtopic response. But people like you with the same setup could 
help me quite fast.

What did you to avoid autoconf problems when compiling from SVN sources?

I have nearly the same setup as you - but struggle with autoconf undefined 
macors (see my post).

Thanks,
Achim
Am Montag, 6. Februar 2006 17:28 schrieb Guillaume Pothier:
> My box has kde 3.5.1 from kubuntu breezy. KAdressBook is v3.5

[Opensync-users] Irmc plugin doesn't appear in kitchensync/kontact

[Guillaume P. <gpo...@gm...>]

Hi,
I compiled and installed opensync and the irmc plugin from the latest
svn sources. When configuring a synchronization pair in kitchensync or
kontact, I don't have an option to choose an IrMC Konnector. Is it
normal or did my installation fail? Or is there something to do to
make the IrMC konnector available?
Regards,
Guillaume Pothier

[Opensync-users] kdepim plugin crashing

[Guillaume P. <gpo...@gm...>]

Hi, I'm experiencing a systematic crash of the kdepim plugin with
v0.18 as well as with latest svn sources.

I have a sync group called "g" with a kdepim member and a irmc member.
Below is the output of "msynctool --sync g". This is with latest svn
version of opensync and kdepim plugin, with debugging turned on.
My box has kde 3.5.1 from kubuntu breezy. KAdressBook is v3.5
Any idea how I could fix this? Is there a way I can get a stack trace?
g



--------------------------
gpothier@tadzim:~/tmp/opensync/svn/opensync$ msynctool --sync g
[OSUSR] DEBUG: Detected User:
UID: 1000
GID: 1000
Home: /home/gpothier
OSyncDir: /home/gpothier/.opensync
[OSGRP] DEBUG: Trying to load group from directory
/home/gpothier/.opensync/group1
Synchronizing group "g"
[CLI] DEBUG: Creating new client 0x8052640
[CLI] DEBUG: Creating new client 0x8052ae0
[GRP] FULL DEBUG: locking file /home/gpothier/.opensync/group1/lock
[GRP] FULL DEBUG: locking group: file exists
[GRP] FULL DEBUG: Successfully locked
[ENG] WARNING: Detected stale lock file. Slow-syncing
The previous synchronization was unclean. Slow-syncing
[ENG] FULL DEBUG: Sending message 0x80530b0:"ENGINE_CHANGED"
[OSMEM] DEBUG: Instancing plugin kdepim-sync for member 1
[kde] DEBUG: kde_initialize
[kde] DEBUG: Loading implementation module
[kde] DEBUG: Getting initialization function
[kde] DEBUG: Initializing implementation module
[OSMEM] DEBUG: Instancing plugin irmc-sync for member 2
[ENG] DEBUG: Running the main loop
[OSDB] DEBUG: Preparing to load changes from file
/home/gpothier/.opensync/group1/change.db
[OSDB] INFORMATION: Unable create changes table! table tbl_changes
already exists
[OSDB] DEBUG: Unable step count! not an error
[ENG] DEBUG: Calling all client deciders (2)
[ENG] FULL DEBUG: Sending message 0x806cbf0:"CLIENT_CHANGED" for
client 0x8052640
[ENG] FULL DEBUG: Sending message 0x80893f8:"CLIENT_CHANGED" for
client 0x8052ae0
[CLI] DEBUG: Client message handler called for message "CONNECT"
[CLI] DEBUG: Client message handler called for message "CONNECT"
KCrash: Application 'libopensync-kdepim-plugin' crashing...
Segmentation fault

[Opensync-users] Compile failure for fresh svn update for Ubuntu Breezy

[<ach...@mn...>]

Hi, =20
I checked out the current subversion versions of opensync and the irmc an=
d=20
kdepim plugins. But when I call autreconfig to get the configure scripts =
and=20
all other stuff created, I get some problems about unknown macros: =20
################################## =20
configure.in:19: error: possibly undefined macro: AC_DISABLE_STATIC =20
      If this token and others are legitimate, please use m4_pattern_allo=
w. =20
      See the Autoconf documentation. =20
configure.in:20: error: possibly undefined macro: AC_PROG_LIBTOOL =20
autoreconf: /usr/bin/autoconf failed with exit status: 1 =20
################################## =20
 =20
My versions are: =20
+ autoreconf --version =20
   =3D=3D> autoreconf (GNU Autoconf) 2.59 =20
+ autoconf --version =20
   =3D=3D> autoconf (GNU Autoconf) 2.59 =20
+ automake --version =20
   =3D=3D> automake (GNU automake) 1.9.5 =20
 =20
So this setup should be rather new. =20
When I try to compile the 0.18 source tar files, I can run =20
directly ./configure and everything compiles fine. =20
 =20
But now I'd like to use the current SVN version of Kitchenync with opensy=
nc =20
integration. I found a very fine compile instruction here: =20
http://www.opensync.org/wiki/kitchensync =20
 =20
But here the compile doesn't work due to some used opensync functions tha=
t =20
were only defined for current subversion version of opensync and not in 0=
.18 =20
(its the function osync_member_set_name ). =20
 =20
Thus I'd like to get the current subversion REPO version to compile at my=
 box. =20
 =20
I think, that simply adding the proposed m4_pattern_allow somewhere does =
not =20
really solve the root of the problem. I googled for some time - but didn'=
t =20
find any helping guide. =20
=20
##=20
Another request:=20
Are there some instructions on the prerequisites for compile?=20
I think I'm not a newbie in Linux and SW development - but it took me qui=
te a=20
long time to get all needed packages installed. So it would be very fine,=
 when=20
the developers could make a small list of all neded "-dev" packages. I th=
ink=20
the names for most distribs should be comparable enough so that a user ca=
n=20
find and install those packages in advance in one run.=20
=20
=20
 =20
Thanks for any help, =20
Achim =20
 =20
 =20
 =20
 =20
 =20

Re: [Opensync-users] SyncML over bluetooth/obex again

[Martin S. <mar...@hi...>]

I have opened a discussion about the necessary changes to openobex on
their mailing list and patches tracker:

http://sourceforge.net/mailarchive/forum.php?forum_id=9713 (the archive
will need some hours to get in sync)
http://sourceforge.net/tracker/index.php?func=detail&aid=1424504&group_id=8960&atid=308960

Still, I have no idea, why the idle callback in sml_support.c is not
called after starting the new thread. Maybe a bug in glib? I'm using
version 2.8.6.

Regards,

  Martin


Am Donnerstag, den 02.02.2006, 09:41 +0100 schrieb Martin Schulze:
> More comprehensive patches including server alerts compliant to SyncML
> 1.1 are now in ticket #146. The problem with the idle command I don't
> understand either. I will look at it again this weekend.
> 
> 
> Am Donnerstag, den 02.02.2006, 02:12 +0100 schrieb Armin Bauer:
> > Hi,
> > 
> > thanks for the patches! i will integrate them in libsyncml branch and
> > the plugin once i find some time (probably means: after my exams :)
> > 
> > Martin Schulze wrote:
> > > I've had a look at the libsyncml-threaded version this evening. From the
> > > sparse information that I could get, this seems to be the actively
> > > maintained branch. 
> > 
> > That is correct. All development is currently done in the threaded-branch.
> > 
> > > Attached are patches to this branch and the
> > > sycml-plugin from trunk.
> > > 
> > > With these patches applied to current svn, sycml-plugin compiles and
> > > runs with the libyscml-threaded version. There is no ChangeLog, so I
> > > have enclosed a short description of the changes below.
> > > 
> > > msynctool still doesn't work with my mobile phone. It doesn't seem to
> > > react on the SAN. I gather so much that SAN requires syncml 1.2 (at
> > > least the way it is currently implemented in libsyncml) and the SGH-D600
> > > only support syncml 1.1.
> > 
> > SAN was not defined prior to syncml 1.2 so there is no chance that a 1.1
> > phone can make any sense of it. in syncml 1.1 you just have to send a
> > normal alert to the phone to trigger the synchronization. I havent
> > tested yet if this is correctly done (at least not with a real phone).
> > 
> > > 
> > > Regards,
> > > 
> > >   Martin
> > > 
> > > _____________________________________________
> > > 
> > > libsyncml-2006_01_29.diff:
> > > 
> > > 	libsyncml/sml_queue.c: Rename the callback functions. Before, the
> > > callback functions from libopensync/osengine/osengine_queue.c were
> > > called on my testing platform (leading to SEGFAULT).
> > 
> > right. i think we should declare them static so that naming conflicts
> > like this cannot happen (or use the proper prefix)
> > 
> > > 	libsyncml/sml_transport.c: Fix typo in the documentation.
> > > 	libsyncml/sml_manager.c: Enhance _smlManagerDataHandler() to handle to
> > > only event type SML_TRANSPORT_EVENT_DATA. TODO: Probably, events of type
> > > SML_TRANSPORT_EVENT_CONNECT_DONE should also be forwarded to
> > > manager->eventCallback(). However, there is no SML_MANAGER* macro for
> > > this, yet.
> > > 	smlManagerSessionRemove() now calls manager->eventCallback() with
> > > SML_MANAGER_SESSION_END.
> > > 	smlManagerNew(): Fix typo.
> > > 	libsyncml/sml_support.c: The idle callback doesn't get called when a
> > > new thread is started. Work around: _start_main_loop().
> > 
> > i dont really understand why this is necessary. i used this code quite
> > often now and it worked very well.
> > 
> > > 
> > > syncml-plugin-2006_01_29.diff:
> > > 
> > > 	src/syncml_plugin.[hc]: Make it work with the libsyncml-threaded branch
> > > of libsyncml. Use smlManager to manage sessions. I'm not sure whether
> > > SmlDsSession is used correctly in batch_commit().
> > 
> > looks ok from the very first glance. the idea is that the syncml session
> > is used to control the commands that are sent and received. it also
> > handles stuff like the fragmentation. then there might be one or more
> > datasync session inside the syncml session where each ds session is
> > responsible for synchronizing a single format. so a synchronization
> > looks like this:
> > 
> > -> the syncml session is received
> > -> the ds servers get called and return the ds session(s)
> > -> the work is done on the ds sessions (like requesting data, sending
> > changes etc).
> > -> once each step is called for all ds sessions you call smlSessionFlush
> > to flush all remaining commands in the syncml session
> > 
> > Best Regards,
> > Armin Bauer
> > 
> > > 	src/syncml-obex-client: Rename 'path' to 'url'. Add new parameter
> > > 'port'.
> > > 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Opensync-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-users

[Opensync-users] Nokia 6020

[Luca <gol...@li...>]

Hello,
I'm trying to Sync my Nokia 6020 using evo2-sync + (presumably) irmc-sync.
I already managed to connect the phone to my notebook using the infrared
port.

My target is to sync the whole calendar/todo/contacts with Evolution2.

The phone is capable of SyncML syncing.

Please, help me :(

Tutorials are really appreciated, so are links.

Thanks and sorry for my bad english.

[Opensync-users] svn.opensync.org down?

[Guillaume P. <gpo...@gm...>]

Hi,
it seems there is a problem with the svn server:
gpothier@tadzim:~$ ping svn.opensync.org
ping: unknown host svn.opensync.org

Has the server changed name, or is it a temporary failure?
Regards,
Guillaume Pothier

Re: [Opensync-users] Libsyncml and syncml-plugin OBEX over bluetooth suport.

[<nhd...@gm...>]

VGhhbmtzIEFybWluLAoKICAgSSBzZW5kIGFuIHdyb25nIGluZm9ybWF0aW9uIGluIG15IG1haWwg
bXkgdGFyZ2V0IGRldmljZSBpcyBhIDY2ODEsIGJ1dCBJCnRpbmsgaXQgaXMgdmVyeSBzaW1pbGFy
IHRvIHRoZSAgNjY4MCAoRXhlcHQgZm9yIHRoZSBmcm9udCBjYW0gYW5kIHRoZSAzRwpzdXBwb3J0
KS4KCkdvb2QgbHVjayB3aXRoIHlvdXJzIGV4YW1zLgrBZHJpYW4gTO12aW8KbmhkZXpvaXRvQGdt
YWlsLmNvbQoKVHJhaW5lZSBpbiB0aGUKTm9raWEgVGVjaG5vbG9neSBJbnN0aXR1dGUgLSBJTmRU
IC0gd3d3LmluZHQub3JnCgpFbGVjdHJpY2FsIEVuZ2VuZWVyaW5nIHN0dWRlbnQgaW4gdGhlCkZl
ZGVyYWwgVW5pdmVyc2l0eSBvZiBDYW1waW5hIEdyYW5kZSAtIFVGQ0cgLSB3d3cudWZjZy5lZHUu
YnIKQ2VudHJlIG9mIEVsZWN0cmljYWwgRW5nZW5lZXJpbmcgYW5kIEluZm9ybWF0aWNzIC0gQ0VF
SQpBY2FkZW1pYyBVbml0IG9mIEVsZWN0cmljYWwgRW5nZW5lZXJpbmcgLSBVQUVFIC0gd3d3LmVl
LnVmY2cuZWR1LmJyCkxhYm9yYXRvcnkgb2YgRW1iZWRkZWQgU3lzdGVtcyBhbmQgUGVydmFzaXZl
IENvbXB1dGluZyAtCnd3dy5lbWJlZGRlZGFjYWRlbXkub3JnCgoKMjAwNi8yLzMsIEFybWluIEJh
dWVyIDxhcm1pbi5iYXVlckBkZXNzY29uLmNvbT46Cj4KPgo+Cj4gwWRyaWFuIEztdmlvIHdyb3Rl
Ogo+ID4gSGkgQXJtaW4sIEhpIEFsbCwKPiA+Cj4gPiAgIE15IG9iamVjdGl2ZSBpcyB0byBtYWtl
IGEgc3luY2hyb25pemF0aW9uIGJldHdlZW4gYW4gbW9iaWxlIHBob25lIChteQo+ID4gdGFyZ2V0
IGRldmljZSBpcyBhIDY2ODApIHVzaW5nIHRoZSBzeW5jbWwgcGx1Z2luIGFuZCBsaWJzeW5jbWwg
b3Zlcgo+ID4gYmx1ZXRvb3RoLgo+Cj4gc291bmRzIGxpa2UgYSBnb29kIGdvYWwuIGkgaGF2ZSBh
IDY2ODAgYXMgd2VsbCBzbyBpIHdpbGwgYmUgYWJsZSB0byBoZWxwCj4gd2l0aCB0aGUgZGVidWdn
aW5nLgo+Cj4gPgo+ID4gICBJIG5lZWQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxpYnN5bmNtbCBh
cmNoaXRlY3R1cmUgYW5kIHdoYXQgaGFzIHRvIGJlCj4gPiBkb25lLiBXaGljaCBwb2ludHMgSSBu
ZWVkIHRvIGltcGxlbWVudCB0byBtYWtlIHRoZSBzeW5jcm9uaXphdGlvbiB3b3JrCj4gPiB1c2lu
ZyB0aGUgb2JleCBvdmVyIGJsdWV0b290aCB0cmFuc3BvcnQ/Cj4KPiBteSBzdWdnZXN0aW9uIHdv
dWxkIGJlOgo+Cj4gLSBhcHBseSB0aGUgcGF0Y2hlcyBmcm9tIG1hcnRpbiBzY2h1bHplLiBoZSBh
bHJlYWR5IGhhcyBmaXhlZCBzb21lCj4gaXNzdWVzIG9mIHRoZSBsaWJyYXJ5IChpIHdhcyBub3Qg
eWV0IGFibGUgdG8gdHJ5IHRoZW0gbXlzZWxmIHRob3VnaCkuCj4gLSB1c2UgdGhlIHN5bmNtbC1o
dHRwLXNlcnZlci5jIGNvZGUgZnJvbSB0b29scy8gdG8gY3JlYXRlIGEgbmV3Cj4gc3luY21sLW9i
ZXgtY2xpZW50LmMgdG9vbC4gSW4gdGhpcyB0b29sIGNoYW5nZSB0aGUgdHJhbnNwb3J0IGZyb20K
PiBodHRwLXNlcnZlciB0byBvYmV4LWNsaWVudC4KPiAtIHRoZW4gdGVzdCB0aGUgb2JleCBjb25u
ZWN0aW9uIGZyb20gdGhpcyB0b29sIChvbmx5IHRoZSBvYmV4IGxheWVyKQo+IC0gYXMgc29vbiBh
cyB0aGlzIHdvcmtzLCB0ZXN0IHRoZSBzeW5jbWwgc2Vzc2lvbiBieSBhZGRpbmcgaGFyZGNvZGVk
Cj4gc3luY21sIGNvbW1hbmRzIHRvIHRoZSBzZXNzaW9uIGRpcmVjdGx5IGFuZCBsb29raW5nIGF0
IHRoZSByZXNwb25zZS4KPiAtIGlmIHRoaXMgd29ya3MsIHRyeSB0aGUgc21sRHNTZXJ2ZXIKPgo+
IHRoZSBtYWluIHBvaW50cyB3aGljaCBwcm9iYWJseSBkb250IHdvcmsgcmlnaHQgbm93OiBzeW5j
IGFsZXJ0cyBmb3IKPiBub24tMS4yIGRldmljZXMsIG1hcHBpbmcgY29tbWFuZHMgb2YgYSBzeW5j
IHNlc3Npb24gYW5kIHBhcnRzIG9mIHRoZQo+IHNtbE1hbmFnZXIgKE1hcnRpbiBhbHJlYWR5IGZp
eGVkIHBhcnRzIG9mIHRoaXMpCj4KPiBpIHdpbGwgam9pbiBpbiB0aGUgZGV2ZWxvcG1lbnQgYWdh
aW4gYXMgc29vbiBhcyBteSBleGFtcyBhcmUgb3Zlci4KPiBUaGFua3MgZm9yIGFsbCB5b3VyIGhl
bHAhCj4KPiBBcm1pbgo+Cj4gPgo+ID4gVGhhbmtzLAo+ID4gwWRyaWFuIEztdmlvCj4gPiBuaGRl
em9pdG9AZ21haWwuY29tIDxtYWlsdG86bmhkZXpvaXRvQGdtYWlsLmNvbT4KPiA+Cj4gPiBUcmFp
bmVlIGluIHRoZQo+ID4gTm9raWEgVGVjaG5vbG9neSBJbnN0aXR1dGUgLSBJTmRUIC0gd3d3Lmlu
ZHQub3JnIDxodHRwOi8vd3d3LmluZHQub3JnPgo+ID4KPiA+IEVsZWN0cmljYWwgRW5nZW5lZXJp
bmcgc3R1ZGVudCBpbiB0aGUKPiA+IEZlZGVyYWwgVW5pdmVyc2l0eSBvZiBDYW1waW5hIEdyYW5k
ZSAtIFVGQ0cgLSB3d3cudWZjZy5lZHUuYnIKPiA+IDxodHRwOi8vd3d3LnVmY2cuZWR1LmJyPgo+
ID4gQ2VudHJlIG9mIEVsZWN0cmljYWwgRW5nZW5lZXJpbmcgYW5kIEluZm9ybWF0aWNzIC0gQ0VF
SQo+ID4gQWNhZGVtaWMgVW5pdCBvZiBFbGVjdHJpY2FsIEVuZ2VuZWVyaW5nIC0gVUFFRSAtIHd3
dy5lZS51ZmNnLmVkdS5icgo+ID4gPGh0dHA6Ly93d3cuZWUudWZjZy5lZHUuYnI+Cj4gPiBMYWJv
cmF0b3J5IG9mIEVtYmVkZGVkIFN5c3RlbXMgYW5kIFBlcnZhc2l2ZSBDb21wdXRpbmcgLQo+ID4g
d3d3LmVtYmVkZGVkYWNhZGVteS5vcmcgPGh0dHA6Ly93d3cuZW1iZWRkZWRhY2FkZW15Lm9yZz4K
PiA+Cj4gPgo+ID4gMjAwNi8xLzYsIEFybWluIEJhdWVyIDxhcm1pbi5iYXVlckBkZXNzY29uLmNv
bQo+ID4gPG1haWx0bzphcm1pbi5iYXVlckBkZXNzY29uLmNvbT4+Ogo+ID4KPiA+Cj4gPgo+ID4g
ICAgIMFkcmlhbiBM7XZpbyB3cm90ZToKPiA+ICAgICA+IEhpIEFsbCwKPiA+ICAgICA+Cj4gPiAg
ICAgPiAgICBJIGFtIHJlYWRpbmcgdGhlIGNvZGUgb2YgdGhlIHN5bmNtbCBvcGVuc3luYyBwbHVn
aW4gYW5kIEkKPiBub3RpY2VkCj4gPiAgICAgPiB0aGF0IHRoZXJlIGlzIGFscmVhZHkgYSBiZWdp
bm5pbmcgb2YgaW1wbGVtZW50YXRpb24gb2YgdGhlIE9CRVgKPiA+ICAgICBzdXBwb3J0LAo+ID4g
ICAgID4gYW5kIEknbSBpbnRlcmVzdGVkIGluIGNvbnRyaWJ1dGluZyB3aXRoIHRoZSBwbHVnaW4g
ZGV2ZWxvcG1lbnQuCj4gPiAgICAgPgo+ID4gICAgID4gICAgSW4gdGhlIGdldF9pbmZvIGZ1bmN0
aW9uIGFuIG9wZW5zeW5jIG92ZXIgb2JleCBwbHVnaW4gaXMKPiA+ICAgICBjcmVhdGVkLCBidXQK
PiA+ICAgICA+IG9ubHkgdGhlIGluaXRpYWxpemUgYW5kIGNvbm5lY3QgZnVuY3Rpb25zIGFyZSBk
aWZmZXJlbnQgb2YgdGhlCj4gaHR0cAo+ID4gICAgID4gb25lcy4gRG8gb25seSB0aGVzZSB0d28g
ZnVuY3Rpb25zIHByb3ZpZGUgdGhlIG9iZXggc3VwcG9ydD8gT3IgaXMKPiBpdAo+ID4gICAgID4g
bmVjZXNzYXJ5IHRvIGltcGxlbWVudCB0aGUgb3RoZXJzIHRvbz8KPiA+Cj4gPiAgICAgbm8uIGkg
YWJzdHJhY3RlZCBtdWNoIG9mIHRoZSBjb25uZWN0aW9uIGluIHRoZSBzeW5jbWwgbGlicmFyeSBz
bwo+IG9ubHkKPiA+ICAgICB0aGVzZSAyIGZ1bmN0aW9ucyBoYXZlIHRvIGJlIGRpZmZlcmVudAo+
ID4KPiA+ICAgICA+Cj4gPiAgICAgPiAgICBJIG5vdGljZWQgdG9vIHRoYXQgdGhlIHN1cHBvcnQg
dG8gc3luY21sIGlzIGRvbmUgYnkgdGhlCj4gbGlic2luY21sCj4gPiAgICAgPiBsaWJyYXJ5LiBJ
cyB0aGlzIG9iZXggc3VwcG9ydCB3b3JraW5nIGluIHRoaXMgbGlicmFyeT8gT3IgZG9lcyBpdAo+
ID4gICAgIGZvbGxvdwo+ID4gICAgID4gdGhlIHBsdWdpbiBkZXZlbG9wbWVudD8KPiA+Cj4gPiAg
ICAgb2JleCBpdHNlbGYgaXMgYWxyZWFkeSB3b3JraW5nIGluIHRoZSBsaWJyYXJ5LiBidXQgdGhl
cmUgYXJlIHNvbWUKPiBvdGhlcgo+ID4gICAgIGlzc3VlcyB0byBhcmUgbm90IHlldCB3b3JraW5n
IGFuZCB3aGljaCBpIGFtIGltcGxlbWVudGluZyBhdCB0aGUKPiA+ICAgICBtb21lbnQuCj4gPgo+
ID4KPiA+ICAgICA+Cj4gPiAgICAgPiAgICBJIHdvdWxkIGxpa2UgdG8ga25vdyB0b28gaWYgdGhl
cmUgYXJlIHNvbWUgaW1wbGVtZW50aW9uIHBsYW5zLAo+IG9yCj4gPiAgICAgPiBzb21ldGhpbmcg
dG8gZ2l2ZSBtZSBhIHN0YXJ0aW5nIHBvaW50IHRvIGtub3cgd2hhdCBoYXMgdG8gYmUgZG9uZS4K
PiA+ICAgICA+Cj4gPgo+ID4gICAgIHRoZXJlIGlzIG5vICJmb3JtYWwiIGltcGxlbWVudGF0aW9u
IHBsYW4gZm9yIHRoZSBsaWJyYXJ5IGFuZCB0aGUKPiA+ICAgICBwbHVnaW4uCj4gPgo+ID4gICAg
IGRpZCB5b3UgYWxyZWFkeSB0YWtlIGEgbG9vayBhdCB0aGUgYXJjaGl0ZWN0dXJlIG9mIHN5bmNt
bCBsaWJyYXJ5Pwo+IGlmCj4gPiAgICAgeW91IHdhbnQgaSBjYW4gZ2l2ZSB5b3UgYSBzaG9ydCBp
bnRyb2R1Y3Rpb24gdG8gaG93IGl0IGlzCj4gaW1wbGVtZW50ZWQuCj4gPgo+ID4gICAgIEFybWlu
Cj4gPgo+ID4gICAgID4KPiA+ICAgICA+Cj4gPiAgICAgPiAtLQo+ID4gICAgID4gwWRyaWFuIEzt
dmlvCj4gPiAgICAgPiBuaGRlem9pdG9AZ21haWwuY29tIDxtYWlsdG86bmhkZXpvaXRvQGdtYWls
LmNvbT4gPG1haWx0bzoKPiA+ICAgICBuaGRlem9pdG9AZ21haWwuY29tIDxtYWlsdG86bmhkZXpv
aXRvQGdtYWlsLmNvbT4+Cj4gPiAgICAgPgo+ID4gICAgID4gVHJhaW5lZSBpbiB0aGUKPiA+ICAg
ICA+IE5va2lhIFRlY2hub2xvZ3kgSW5zdGl0dXRlIC0gSU5kVCAtIHd3dy5pbmR0Lm9yZwo+ID4g
ICAgIDxodHRwOi8vd3d3LmluZHQub3JnPiA8aHR0cDovL3d3dy5pbmR0Lm9yZy8+Cj4gPiAgICAg
PiA8IGh0dHA6Ly93d3cuaW5kdC5vcmcvPgo+ID4gICAgID4gRWxlY3RyaWNhbCBFbmdlbmVlcmlu
ZyBzdHVkZW50IGluIHRoZQo+ID4gICAgID4gRmVkZXJhbCBVbml2ZXJzaXR5IG9mIENhbXBpbmEg
R3JhbmRlIC0gVUZDRyAtIHd3dy51ZmNnLmVkdS5icgo+ID4gICAgIDxodHRwOi8vd3d3LnVmY2cu
ZWR1LmJyPgo+ID4gICAgID4gPCBodHRwOi8vd3d3LnVmY2cuZWR1LmJyLz4KPiA+ICAgICA+IENl
bnRyZSBvZiBFbGVjdHJpY2FsIEVuZ2VuZWVyaW5nIGFuZCBJbmZvcm1hdGljcyAtIENFRUkKPiA+
ICAgICA+IEFjYWRlbWljIFVuaXQgb2YgRWxlY3RyaWNhbCBFbmdlbmVlcmluZyAtIFVBRUUgLQo+
ID4gICAgIHd3dy5lZS51ZmNnLmVkdS5iciA8aHR0cDovL3d3dy5lZS51ZmNnLmVkdS5icj4KPiA+
ICAgICA+IDwgaHR0cDovL3d3dy5lZS51ZmNnLmVkdS5ici8+Cj4gPiAgICAgPiBMYWJvcmF0b3J5
IG9mIEVtYmVkZGVkIFN5c3RlbXMgYW5kIFBlcnZhc2l2ZSBDb21wdXRpbmcgLQo+ID4gICAgID4g
d3d3LmVtYmVkZGVkYWNhZGVteS5vcmcgPGh0dHA6Ly93d3cuZW1iZWRkZWRhY2FkZW15Lm9yZz4K
PiA+ICAgICA8aHR0cDovL3d3dy5lbWJlZGRlZGFjYWRlbXkub3JnLz4KPiA+Cj4gPgo+ID4KPiA+
Cj4gPgo+ID4KPiA+IC0tCj4gPiDBZHJpYW4gTO12aW8KPiA+IFVuaXZlcnNpZGFkZSBGZWRlcmFs
IGRlIENhbXBpbmEgR3JhbmRlIC0gVUZDRyAtIHd3dy51ZmNnLmVkdS5icgo+ID4gPGh0dHA6Ly93
d3cudWZjZy5lZHUuYnI+Cj4gPiBDZW50cm8gZGUgRW5nZW5oYXJpYSBFbOl0cmljYSBlIEluZm9y
bWF0aWNhIC0gQ0VFSQo+ID4gVW5pZGFkZSBBY2Fk6m1pY2EgZGUgRW5nZW5oYXJpYSBFbOl0cmlj
YSAtIFVBRUUgLSB3d3cuZWUudWZjZy5lZHUuYnIKPiA+IDxodHRwOi8vd3d3LmVlLnVmY2cuZWR1
LmJyPgo+ID4gTGFib3JhdPNyaW8gZGUgU2lzdGVtYXMgRW1iYXJjYWRvcyBlIENvbXB1dGHn428g
UGVydmFzaXZhIC0KPiA+IHd3dy5lbWJlZGRlZGFjYWRlbXkub3JnIDxodHRwOi8vd3d3LmVtYmVk
ZGVkYWNhZGVteS5vcmc+Cj4gPgo+ID4gLS0tLQo+ID4KPiA+ICAgICBO428gZXhpc3RlIGVtb+fj
bywgZSBzaW0gcGF6Lgo+ID4gICAgIE7jbyBleGlzdGUgaWdub3LibmNpYSwgZSBzaW0gY29uaGVj
aW1lbnRvLgo+ID4gICAgIE7jbyBleGlzdGUgcGFpeONvLCBlIHNpbSBzZXJlbmlkYWRlLgo+ID4g
ICAgIE7jbyBleGlzdGUgY2FvcywgZSBzaW0gaGFybW9uaWEuCj4gPiAgICAgTuNvIGV4aXN0ZSBt
b3J0ZSwgZSBzaW0gYSBGb3LnYS4KPiA+ICAgICCXTyBD82RpZ28gSmVkaQo+ID4KPiA+Cj4gPgo+
ID4KPiA+Cj4gPgo+ID4KPiA+Cj4gPiBGTk9SRAo+ID4KPiA+IC0tCj4gPiDBZHJpYW4gTO12aW8K
PiA+IFVuaXZlcnNpZGFkZSBGZWRlcmFsIGRlIENhbXBpbmEgR3JhbmRlIC0gVUZDRyAtIHd3dy51
ZmNnLmVkdS5icgo+ID4gPGh0dHA6Ly93d3cudWZjZy5lZHUuYnI+Cj4gPiBDZW50cm8gZGUgRW5n
ZW5oYXJpYSBFbOl0cmljYSBlIEluZm9ybWF0aWNhIC0gQ0VFSQo+ID4gVW5pZGFkZSBBY2Fk6m1p
Y2EgZGUgRW5nZW5oYXJpYSBFbOl0cmljYSAtIFVBRUUgLSB3d3cuZWUudWZjZy5lZHUuYnIKPiA+
IDxodHRwOi8vd3d3LmVlLnVmY2cuZWR1LmJyPgo+ID4gTGFib3JhdPNyaW8gZGUgU2lzdGVtYXMg
RW1iYXJjYWRvcyBlIENvbXB1dGHn428gUGVydmFzaXZhIC0KPiA+IHd3dy5lbWJlZGRlZGFjYWRl
bXkub3JnIDxodHRwOi8vd3d3LmVtYmVkZGVkYWNhZGVteS5vcmc+Cj4gPgo+ID4gLS0tLQo+ID4K
PiA+ICAgICBO428gZXhpc3RlIGVtb+fjbywgZSBzaW0gcGF6Lgo+ID4gICAgIE7jbyBleGlzdGUg
aWdub3LibmNpYSwgZSBzaW0gY29uaGVjaW1lbnRvLgo+ID4gICAgIE7jbyBleGlzdGUgcGFpeONv
LCBlIHNpbSBzZXJlbmlkYWRlLgo+ID4gICAgIE7jbyBleGlzdGUgY2FvcywgZSBzaW0gaGFybW9u
aWEuCj4gPiAgICAgTuNvIGV4aXN0ZSBtb3J0ZSwgZSBzaW0gYSBGb3LnYS4KPiA+ICAgICCXTyBD
82RpZ28gSmVkaQo+ID4KPiA+Cj4gPgo+ID4KPiA+Cj4gPgo+ID4KPiA+Cj4gPiBGTk9SRAo+Cj4K
Pgo+CgoKLS0KwWRyaWFuIEztdmlvClVuaXZlcnNpZGFkZSBGZWRlcmFsIGRlIENhbXBpbmEgR3Jh
bmRlIC0gVUZDRyAtIHd3dy51ZmNnLmVkdS5icgpDZW50cm8gZGUgRW5nZW5oYXJpYSBFbOl0cmlj
YSBlIEluZm9ybWF0aWNhIC0gQ0VFSQpVbmlkYWRlIEFjYWTqbWljYSBkZSBFbmdlbmhhcmlhIEVs
6XRyaWNhIC0gVUFFRSAtIHd3dy5lZS51ZmNnLmVkdS5icgpMYWJvcmF083JpbyBkZSBTaXN0ZW1h
cyBFbWJhcmNhZG9zIGUgQ29tcHV0YefjbyBQZXJ2YXNpdmEgLQp3d3cuZW1iZWRkZWRhY2FkZW15
Lm9yZwoKLS0tLQoKICAgIE7jbyBleGlzdGUgZW1v5+NvLCBlIHNpbSBwYXouCiAgICBO428gZXhp
c3RlIGlnbm9y4m5jaWEsIGUgc2ltIGNvbmhlY2ltZW50by4KICAgIE7jbyBleGlzdGUgcGFpeONv
LCBlIHNpbSBzZXJlbmlkYWRlLgogICAgTuNvIGV4aXN0ZSBjYW9zLCBlIHNpbSBoYXJtb25pYS4K
ICAgIE7jbyBleGlzdGUgbW9ydGUsIGUgc2ltIGEgRm9y52EuCiAgICCXTyBD82RpZ28gSmVkaQoK
CgoKCgoKCkZOT1JECg==

Re: [Opensync-users] evolution2 plugin not compatible with data-server???

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

try adding another line in configure.in:

pkg_emodules_14="evolution-data-server-1.4 libebook-1.4 libecal-1.4
libedata-book-1.4 libedata-cal-1.4 libedataserver-1.4"

and change the line

PKG_CHECK_MODULES(EPACKAGE, [$pkg_emodules_10], EDSFOUND=1, [EDSFOUND=0])

to

PKG_CHECK_MODULES(EPACKAGE, [$pkg_emodules_14], EDSFOUND=1, [EDSFOUND=0])

but i dont guarantee that the evo2 plugin works with eds1.4. Never tried it.

Best Regards,
Armin Bauer

Matteo Bottiroli wrote:
> After installed evolution-devel pack too, the error compiling
> (configuring) remains.....
> 
> help me please!!!
> 
> Regards
> 
> Il giorno gio, 02/02/2006 alle 14.41 +0100, Matteo Bottiroli ha scritto:
> 
>>in config.in (evo2 plugin, i'm trying to compile)
>>
>>pkg_modules="glib-2.0 opensync-1.0"
>>pkg_emodules_10="evolution-data-server-1.0 libebook-1.0 libecal-1.0
>>libedata-book-1.0 libedata-cal-1.0 libedataserver-1.0"
>>pkg_emodules_11="evolution-data-server-1.1 libebook-1.1 libecal-1.1
>>libedata-book-1.1 libedata-cal-1.1 libedataserver-1.1"
>>pkg_emodules_12="evolution-data-server-1.2 libebook-1.2 libecal-1.2
>>libedata-book-1.2 libedata-cal-1.2 libedataserver-1.2"
>>
>>export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}:/usr/lib/pkgconfig:
>>$prefix/lib/pkgconfig:/usr/local/lib/pkgconfig
>>
>>PKG_CHECK_MODULES(PACKAGE, [$pkg_modules], , AC_MSG_ERROR(GLib >= 2.0
>>and opensync >= 1.0 required))
>>
>>AC_SUBST(PACKAGE_CFLAGS)
>>AC_SUBST(PACKAGE_LIBS)
>>
>>PKG_CHECK_MODULES(EPACKAGE, [$pkg_emodules_10], EDSFOUND=1,
>>[EDSFOUND=0])
>>if test "x${EDSFOUND}" = "x0"; then
>>        PKG_CHECK_MODULES(EPACKAGE, [$pkg_emodules_11], EDSFOUND=1,
>>[EDSFOUND=0])
>>        if test "x${EDSFOUND}" = "x0"; then
>>                PKG_CHECK_MODULES(EPACKAGE,
>>[$pkg_emodules_12],,AC_MSG_ERROR(No compatible evolution-data-server was
>>found))
>>        fi
>>fi
>>
>>i can see just 1.0 1.1 1.2 data-server, not 1.4 (installed via rpm)
>>
>>On Thu, 2006-02-02 at 14:35 +0100, David Eriksson wrote:
>>> On Thu, 2006-02-02 at 13:48 +0100, Matteo Bottiroli wrote:
>>> > After a configure , i got this:
>>> > 
>>> > [root@localhost evolution2]# autoreconf -sfi configure.in: installing
>>> > `./install-sh'
>>> > configure.in: installing `./missing'
>>> > src/Makefile.am: installing `./depcomp'
>>> > [root@localhost evolution2]# ./configure
>>> > checking for a BSD-compatible install... /usr/bin/install -c
>>> > checking whether build environment is sane... yes
>>> > checking for gawk... gawk
>>> > checking whether make sets $(MAKE)... yes
>>> > checking for pkg-config... /usr/bin/pkg-config
>>> > checking pkg-config is at least version 0.9.0... yes
>>> > checking for PACKAGE... yes
>>> > checking for EPACKAGE... checking for EPACKAGE... checking for
>>> > EPACKAGE... configure: error: No compatible evolution-data-server was
>>> > found
>>> > 
>>> > my install is:
>>> > evolution-data-server-1.4.2.1-1.1.fc4.nr
>>> > evolution-2.4.2.1-1.1.fc4.nr
>>> > evolution-connector-2.4.2-1.1.fc4.nr
>>> > 
>>> > why???
>>> 
>>> You probably need the corresponding -devel packages.
>>> 
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>
>>_______________________________________________
>>Opensync-users mailing list
>>Ope...@li... <mailto:Ope...@li...>
>>https://lists.sourceforge.net/lists/listinfo/opensync-users
>>

Re: [Opensync-users] Libsyncml and syncml-plugin OBEX over bluetooth suport.

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

=C1drian L=EDvio wrote:
> Hi Armin, Hi All,
>=20
>   My objective is to make a synchronization between an mobile phone (my=

> target device is a 6680) using the syncml plugin and libsyncml over
> bluetooth.

sounds like a good goal. i have a 6680 as well so i will be able to help
with the debugging.

>=20
>   I need information about the libsyncml architecture and what has to b=
e
> done. Which points I need to implement to make the syncronization work
> using the obex over bluetooth transport?

my suggestion would be:

- apply the patches from martin schulze. he already has fixed some
issues of the library (i was not yet able to try them myself though).
- use the syncml-http-server.c code from tools/ to create a new
syncml-obex-client.c tool. In this tool change the transport from
http-server to obex-client.
- then test the obex connection from this tool (only the obex layer)
- as soon as this works, test the syncml session by adding hardcoded
syncml commands to the session directly and looking at the response.
- if this works, try the smlDsServer

the main points which probably dont work right now: sync alerts for
non-1.2 devices, mapping commands of a sync session and parts of the
smlManager (Martin already fixed parts of this)

i will join in the development again as soon as my exams are over.
Thanks for all your help!

Armin

>=20
> Thanks,
> =C1drian L=EDvio
> nhd...@gm... <mailto:nhd...@gm...>
>=20
> Trainee in the
> Nokia Technology Institute - INdT - www.indt.org <http://www.indt.org>
>=20
> Electrical Engeneering student in the
> Federal University of Campina Grande - UFCG - www.ufcg.edu.br
> <http://www.ufcg.edu.br>
> Centre of Electrical Engeneering and Informatics - CEEI
> Academic Unit of Electrical Engeneering - UAEE - www.ee.ufcg.edu.br
> <http://www.ee.ufcg.edu.br>
> Laboratory of Embedded Systems and Pervasive Computing -
> www.embeddedacademy.org <http://www.embeddedacademy.org>
>=20
>=20
> 2006/1/6, Armin Bauer <arm...@de...
> <mailto:arm...@de...>>:
>=20
>=20
>=20
>     =C1drian L=EDvio wrote:
>     > Hi All,
>     >
>     >    I am reading the code of the syncml opensync plugin and I noti=
ced
>     > that there is already a beginning of implementation of the OBEX
>     support,
>     > and I'm interested in contributing with the plugin development.
>     >
>     >    In the get_info function an opensync over obex plugin is
>     created, but
>     > only the initialize and connect functions are different of the ht=
tp
>     > ones. Do only these two functions provide the obex support? Or is=
 it
>     > necessary to implement the others too?
>=20
>     no. i abstracted much of the connection in the syncml library so on=
ly
>     these 2 functions have to be different
>=20
>     >
>     >    I noticed too that the support to syncml is done by the libsin=
cml
>     > library. Is this obex support working in this library? Or does it=

>     follow
>     > the plugin development?
>=20
>     obex itself is already working in the library. but there are some o=
ther
>     issues to are not yet working and which i am implementing at the
>     moment.
>=20
>=20
>     >
>     >    I would like to know too if there are some implemention plans,=
 or
>     > something to give me a starting point to know what has to be done=
=2E
>     >
>=20
>     there is no "formal" implementation plan for the library and the
>     plugin.
>=20
>     did you already take a look at the architecture of syncml library? =
if
>     you want i can give you a short introduction to how it is implement=
ed.
>=20
>     Armin
>=20
>     >
>     >
>     > --
>     > =C1drian L=EDvio
>     > nhd...@gm... <mailto:nhd...@gm...> <mailto:
>     nhd...@gm... <mailto:nhd...@gm...>>
>     >
>     > Trainee in the
>     > Nokia Technology Institute - INdT - www.indt.org
>     <http://www.indt.org> <http://www.indt.org/>
>     > < http://www.indt.org/>
>     > Electrical Engeneering student in the
>     > Federal University of Campina Grande - UFCG - www.ufcg.edu.br
>     <http://www.ufcg.edu.br>
>     > < http://www.ufcg.edu.br/>
>     > Centre of Electrical Engeneering and Informatics - CEEI
>     > Academic Unit of Electrical Engeneering - UAEE -
>     www.ee.ufcg.edu.br <http://www.ee.ufcg.edu.br>
>     > < http://www.ee.ufcg.edu.br/>
>     > Laboratory of Embedded Systems and Pervasive Computing -
>     > www.embeddedacademy.org <http://www.embeddedacademy.org>
>     <http://www.embeddedacademy.org/>
>=20
>=20
>=20
>=20
>=20
>=20
> --=20
> =C1drian L=EDvio
> Universidade Federal de Campina Grande - UFCG - www.ufcg.edu.br
> <http://www.ufcg.edu.br>
> Centro de Engenharia El=E9trica e Informatica - CEEI
> Unidade Acad=EAmica de Engenharia El=E9trica - UAEE - www.ee.ufcg.edu.b=
r
> <http://www.ee.ufcg.edu.br>
> Laborat=F3rio de Sistemas Embarcados e Computa=E7=E3o Pervasiva -
> www.embeddedacademy.org <http://www.embeddedacademy.org>
>=20
> ----
>=20
>     N=E3o existe emo=E7=E3o, e sim paz.
>     N=E3o existe ignor=E2ncia, e sim conhecimento.
>     N=E3o existe paix=E3o, e sim serenidade.
>     N=E3o existe caos, e sim harmonia.
>     N=E3o existe morte, e sim a For=E7a.
>     =97O C=F3digo Jedi
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> FNORD
>=20
> --=20
> =C1drian L=EDvio
> Universidade Federal de Campina Grande - UFCG - www.ufcg.edu.br
> <http://www.ufcg.edu.br>
> Centro de Engenharia El=E9trica e Informatica - CEEI
> Unidade Acad=EAmica de Engenharia El=E9trica - UAEE - www.ee.ufcg.edu.b=
r
> <http://www.ee.ufcg.edu.br>
> Laborat=F3rio de Sistemas Embarcados e Computa=E7=E3o Pervasiva -
> www.embeddedacademy.org <http://www.embeddedacademy.org>
>=20
> ----
>=20
>     N=E3o existe emo=E7=E3o, e sim paz.
>     N=E3o existe ignor=E2ncia, e sim conhecimento.
>     N=E3o existe paix=E3o, e sim serenidade.
>     N=E3o existe caos, e sim harmonia.
>     N=E3o existe morte, e sim a For=E7a.
>     =97O C=F3digo Jedi
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> FNORD

[Opensync-users] Libsyncml and syncml-plugin OBEX over bluetooth suport.

[<nhd...@gm...>]

SGkgQXJtaW4sIEhpIEFsbCwKCiAgTXkgb2JqZWN0aXZlIGlzIHRvIG1ha2UgYSBzeW5jaHJvbml6
YXRpb24gYmV0d2VlbiBhbiBtb2JpbGUgcGhvbmUgKG15CnRhcmdldCBkZXZpY2UgaXMgYSA2Njgw
KSB1c2luZyB0aGUgc3luY21sIHBsdWdpbiBhbmQgbGlic3luY21sIG92ZXIKYmx1ZXRvb3RoLgoK
ICBJIG5lZWQgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxpYnN5bmNtbCBhcmNoaXRlY3R1cmUgYW5k
IHdoYXQgaGFzIHRvIGJlCmRvbmUuIFdoaWNoIHBvaW50cyBJIG5lZWQgdG8gaW1wbGVtZW50IHRv
IG1ha2UgdGhlIHN5bmNyb25pemF0aW9uIHdvcmsgdXNpbmcKdGhlIG9iZXggb3ZlciBibHVldG9v
dGggdHJhbnNwb3J0PwoKVGhhbmtzLArBZHJpYW4gTO12aW8KbmhkZXpvaXRvQGdtYWlsLmNvbQoK
VHJhaW5lZSBpbiB0aGUKTm9raWEgVGVjaG5vbG9neSBJbnN0aXR1dGUgLSBJTmRUIC0gd3d3Lmlu
ZHQub3JnCgpFbGVjdHJpY2FsIEVuZ2VuZWVyaW5nIHN0dWRlbnQgaW4gdGhlCkZlZGVyYWwgVW5p
dmVyc2l0eSBvZiBDYW1waW5hIEdyYW5kZSAtIFVGQ0cgLSB3d3cudWZjZy5lZHUuYnIKQ2VudHJl
IG9mIEVsZWN0cmljYWwgRW5nZW5lZXJpbmcgYW5kIEluZm9ybWF0aWNzIC0gQ0VFSQpBY2FkZW1p
YyBVbml0IG9mIEVsZWN0cmljYWwgRW5nZW5lZXJpbmcgLSBVQUVFIC0gd3d3LmVlLnVmY2cuZWR1
LmJyCkxhYm9yYXRvcnkgb2YgRW1iZWRkZWQgU3lzdGVtcyBhbmQgUGVydmFzaXZlIENvbXB1dGlu
ZyAtCnd3dy5lbWJlZGRlZGFjYWRlbXkub3JnCgoKMjAwNi8xLzYsIEFybWluIEJhdWVyIDxhcm1p
bi5iYXVlckBkZXNzY29uLmNvbT46Cj4KPgo+Cj4gwWRyaWFuIEztdmlvIHdyb3RlOgo+ID4gSGkg
QWxsLAo+ID4KPiA+ICAgIEkgYW0gcmVhZGluZyB0aGUgY29kZSBvZiB0aGUgc3luY21sIG9wZW5z
eW5jIHBsdWdpbiBhbmQgSSBub3RpY2VkCj4gPiB0aGF0IHRoZXJlIGlzIGFscmVhZHkgYSBiZWdp
bm5pbmcgb2YgaW1wbGVtZW50YXRpb24gb2YgdGhlIE9CRVggc3VwcG9ydCwKPiA+IGFuZCBJJ20g
aW50ZXJlc3RlZCBpbiBjb250cmlidXRpbmcgd2l0aCB0aGUgcGx1Z2luIGRldmVsb3BtZW50Lgo+
ID4KPiA+ICAgIEluIHRoZSBnZXRfaW5mbyBmdW5jdGlvbiBhbiBvcGVuc3luYyBvdmVyIG9iZXgg
cGx1Z2luIGlzIGNyZWF0ZWQsIGJ1dAo+ID4gb25seSB0aGUgaW5pdGlhbGl6ZSBhbmQgY29ubmVj
dCBmdW5jdGlvbnMgYXJlIGRpZmZlcmVudCBvZiB0aGUgaHR0cAo+ID4gb25lcy4gRG8gb25seSB0
aGVzZSB0d28gZnVuY3Rpb25zIHByb3ZpZGUgdGhlIG9iZXggc3VwcG9ydD8gT3IgaXMgaXQKPiA+
IG5lY2Vzc2FyeSB0byBpbXBsZW1lbnQgdGhlIG90aGVycyB0b28/Cj4KPiBuby4gaSBhYnN0cmFj
dGVkIG11Y2ggb2YgdGhlIGNvbm5lY3Rpb24gaW4gdGhlIHN5bmNtbCBsaWJyYXJ5IHNvIG9ubHkK
PiB0aGVzZSAyIGZ1bmN0aW9ucyBoYXZlIHRvIGJlIGRpZmZlcmVudAo+Cj4gPgo+ID4gICAgSSBu
b3RpY2VkIHRvbyB0aGF0IHRoZSBzdXBwb3J0IHRvIHN5bmNtbCBpcyBkb25lIGJ5IHRoZSBsaWJz
aW5jbWwKPiA+IGxpYnJhcnkuIElzIHRoaXMgb2JleCBzdXBwb3J0IHdvcmtpbmcgaW4gdGhpcyBs
aWJyYXJ5PyBPciBkb2VzIGl0IGZvbGxvdwo+ID4gdGhlIHBsdWdpbiBkZXZlbG9wbWVudD8KPgo+
IG9iZXggaXRzZWxmIGlzIGFscmVhZHkgd29ya2luZyBpbiB0aGUgbGlicmFyeS4gYnV0IHRoZXJl
IGFyZSBzb21lIG90aGVyCj4gaXNzdWVzIHRvIGFyZSBub3QgeWV0IHdvcmtpbmcgYW5kIHdoaWNo
IGkgYW0gaW1wbGVtZW50aW5nIGF0IHRoZSBtb21lbnQuCj4KPgo+ID4KPiA+ICAgIEkgd291bGQg
bGlrZSB0byBrbm93IHRvbyBpZiB0aGVyZSBhcmUgc29tZSBpbXBsZW1lbnRpb24gcGxhbnMsIG9y
Cj4gPiBzb21ldGhpbmcgdG8gZ2l2ZSBtZSBhIHN0YXJ0aW5nIHBvaW50IHRvIGtub3cgd2hhdCBo
YXMgdG8gYmUgZG9uZS4KPiA+Cj4KPiB0aGVyZSBpcyBubyAiZm9ybWFsIiBpbXBsZW1lbnRhdGlv
biBwbGFuIGZvciB0aGUgbGlicmFyeSBhbmQgdGhlIHBsdWdpbi4KPgo+IGRpZCB5b3UgYWxyZWFk
eSB0YWtlIGEgbG9vayBhdCB0aGUgYXJjaGl0ZWN0dXJlIG9mIHN5bmNtbCBsaWJyYXJ5PyBpZgo+
IHlvdSB3YW50IGkgY2FuIGdpdmUgeW91IGEgc2hvcnQgaW50cm9kdWN0aW9uIHRvIGhvdyBpdCBp
cyBpbXBsZW1lbnRlZC4KPgo+IEFybWluCj4KPiA+Cj4gPgo+ID4gLS0KPiA+IMFkcmlhbiBM7XZp
bwo+ID4gbmhkZXpvaXRvQGdtYWlsLmNvbSA8bWFpbHRvOm5oZGV6b2l0b0BnbWFpbC5jb20+Cj4g
Pgo+ID4gVHJhaW5lZSBpbiB0aGUKPiA+IE5va2lhIFRlY2hub2xvZ3kgSW5zdGl0dXRlIC0gSU5k
VCAtIHd3dy5pbmR0Lm9yZyA8aHR0cDovL3d3dy5pbmR0Lm9yZy8+Cj4gPiA8aHR0cDovL3d3dy5p
bmR0Lm9yZy8+Cj4gPiBFbGVjdHJpY2FsIEVuZ2VuZWVyaW5nIHN0dWRlbnQgaW4gdGhlCj4gPiBG
ZWRlcmFsIFVuaXZlcnNpdHkgb2YgQ2FtcGluYSBHcmFuZGUgLSBVRkNHIC0gd3d3LnVmY2cuZWR1
LmJyCj4gPiA8aHR0cDovL3d3dy51ZmNnLmVkdS5ici8+Cj4gPiBDZW50cmUgb2YgRWxlY3RyaWNh
bCBFbmdlbmVlcmluZyBhbmQgSW5mb3JtYXRpY3MgLSBDRUVJCj4gPiBBY2FkZW1pYyBVbml0IG9m
IEVsZWN0cmljYWwgRW5nZW5lZXJpbmcgLSBVQUVFIC0gd3d3LmVlLnVmY2cuZWR1LmJyCj4gPiA8
aHR0cDovL3d3dy5lZS51ZmNnLmVkdS5ici8+Cj4gPiBMYWJvcmF0b3J5IG9mIEVtYmVkZGVkIFN5
c3RlbXMgYW5kIFBlcnZhc2l2ZSBDb21wdXRpbmcgLQo+ID4gd3d3LmVtYmVkZGVkYWNhZGVteS5v
cmcgPGh0dHA6Ly93d3cuZW1iZWRkZWRhY2FkZW15Lm9yZy8+Cj4KPgo+Cj4KCgotLQrBZHJpYW4g
TO12aW8KVW5pdmVyc2lkYWRlIEZlZGVyYWwgZGUgQ2FtcGluYSBHcmFuZGUgLSBVRkNHIC0gd3d3
LnVmY2cuZWR1LmJyCkNlbnRybyBkZSBFbmdlbmhhcmlhIEVs6XRyaWNhIGUgSW5mb3JtYXRpY2Eg
LSBDRUVJClVuaWRhZGUgQWNhZOptaWNhIGRlIEVuZ2VuaGFyaWEgRWzpdHJpY2EgLSBVQUVFIC0g
d3d3LmVlLnVmY2cuZWR1LmJyCkxhYm9yYXTzcmlvIGRlIFNpc3RlbWFzIEVtYmFyY2Fkb3MgZSBD
b21wdXRh5+NvIFBlcnZhc2l2YSAtCnd3dy5lbWJlZGRlZGFjYWRlbXkub3JnCgotLS0tCgogICAg
TuNvIGV4aXN0ZSBlbW/n428sIGUgc2ltIHBhei4KICAgIE7jbyBleGlzdGUgaWdub3LibmNpYSwg
ZSBzaW0gY29uaGVjaW1lbnRvLgogICAgTuNvIGV4aXN0ZSBwYWl4428sIGUgc2ltIHNlcmVuaWRh
ZGUuCiAgICBO428gZXhpc3RlIGNhb3MsIGUgc2ltIGhhcm1vbmlhLgogICAgTuNvIGV4aXN0ZSBt
b3J0ZSwgZSBzaW0gYSBGb3LnYS4KICAgIJdPIEPzZGlnbyBKZWRpCgoKCgoKCgoKRk5PUkQKCi0t
CsFkcmlhbiBM7XZpbwpVbml2ZXJzaWRhZGUgRmVkZXJhbCBkZSBDYW1waW5hIEdyYW5kZSAtIFVG
Q0cgLSB3d3cudWZjZy5lZHUuYnIKQ2VudHJvIGRlIEVuZ2VuaGFyaWEgRWzpdHJpY2EgZSBJbmZv
cm1hdGljYSAtIENFRUkKVW5pZGFkZSBBY2Fk6m1pY2EgZGUgRW5nZW5oYXJpYSBFbOl0cmljYSAt
IFVBRUUgLSB3d3cuZWUudWZjZy5lZHUuYnIKTGFib3JhdPNyaW8gZGUgU2lzdGVtYXMgRW1iYXJj
YWRvcyBlIENvbXB1dGHn428gUGVydmFzaXZhIC0Kd3d3LmVtYmVkZGVkYWNhZGVteS5vcmcKCi0t
LS0KCiAgICBO428gZXhpc3RlIGVtb+fjbywgZSBzaW0gcGF6LgogICAgTuNvIGV4aXN0ZSBpZ25v
cuJuY2lhLCBlIHNpbSBjb25oZWNpbWVudG8uCiAgICBO428gZXhpc3RlIHBhaXjjbywgZSBzaW0g
c2VyZW5pZGFkZS4KICAgIE7jbyBleGlzdGUgY2FvcywgZSBzaW0gaGFybW9uaWEuCiAgICBO428g
ZXhpc3RlIG1vcnRlLCBlIHNpbSBhIEZvcudhLgogICAgl08gQ/NkaWdvIEplZGkKCgoKCgoKCgpG
Tk9SRAo=

[Opensync-users] Libsyncml and syncml-plugin OBEX over bluetooth suport.

[<nhd...@gm...>]

SGkgQXJtaW4sCgogIE15IG9iamVjdGl2ZSBpcyB0byBtYWtlIGEgc3luY2hyb25pemF0aW9uIGJl
dHdlZW4gYW4gbW9iaWxlIHBob25lIChteQp0YXJnZXQgZGV2aWNlIGlzIGEgNjY4MCkgdXNpbmcg
dGhlIHN5bmNtbCBwbHVnaW4gYW5kIGxpYnN5bmNtbCBvdmVyCmJsdWV0b290aC4KCiAgSSBuZWVk
IGluZm9ybWF0aW9uIGFib3V0IHRoZSBsaWJzeW5jbWwgYXJjaGl0ZWN0dXJlIGFuZCB3aGF0IGhh
cyB0byBiZQpkb25lLiBXaGljaCBwb2ludHMgSSBuZWVkIHRvIGltcGxlbWVudCB0byBtYWtlIHRo
ZSBzeW5jcm9uaXphdGlvbiB3b3JrIHVzaW5nCnRoZSBvYmV4IG92ZXIgYmx1ZXRvb3RoIHRyYW5z
cG9ydD8KClRoYW5rcywKwWRyaWFuIEztdmlvCm5oZGV6b2l0b0BnbWFpbC5jb20KClRyYWluZWUg
aW4gdGhlCk5va2lhIFRlY2hub2xvZ3kgSW5zdGl0dXRlIC0gSU5kVCAtIHd3dy5pbmR0Lm9yZwoK
RWxlY3RyaWNhbCBFbmdlbmVlcmluZyBzdHVkZW50IGluIHRoZQpGZWRlcmFsIFVuaXZlcnNpdHkg
b2YgQ2FtcGluYSBHcmFuZGUgLSBVRkNHIC0gd3d3LnVmY2cuZWR1LmJyCkNlbnRyZSBvZiBFbGVj
dHJpY2FsIEVuZ2VuZWVyaW5nIGFuZCBJbmZvcm1hdGljcyAtIENFRUkKQWNhZGVtaWMgVW5pdCBv
ZiBFbGVjdHJpY2FsIEVuZ2VuZWVyaW5nIC0gVUFFRSAtIHd3dy5lZS51ZmNnLmVkdS5icgpMYWJv
cmF0b3J5IG9mIEVtYmVkZGVkIFN5c3RlbXMgYW5kIFBlcnZhc2l2ZSBDb21wdXRpbmcgLQp3d3cu
ZW1iZWRkZWRhY2FkZW15Lm9yZwoKCjIwMDYvMS82LCBBcm1pbiBCYXVlciA8YXJtaW4uYmF1ZXJA
ZGVzc2Nvbi5jb20+Ogo+Cj4KPgo+IMFkcmlhbiBM7XZpbyB3cm90ZToKPiA+IEhpIEFsbCwKPiA+
Cj4gPiAgICBJIGFtIHJlYWRpbmcgdGhlIGNvZGUgb2YgdGhlIHN5bmNtbCBvcGVuc3luYyBwbHVn
aW4gYW5kIEkgbm90aWNlZAo+ID4gdGhhdCB0aGVyZSBpcyBhbHJlYWR5IGEgYmVnaW5uaW5nIG9m
IGltcGxlbWVudGF0aW9uIG9mIHRoZSBPQkVYIHN1cHBvcnQsCj4gPiBhbmQgSSdtIGludGVyZXN0
ZWQgaW4gY29udHJpYnV0aW5nIHdpdGggdGhlIHBsdWdpbiBkZXZlbG9wbWVudC4KPiA+Cj4gPiAg
ICBJbiB0aGUgZ2V0X2luZm8gZnVuY3Rpb24gYW4gb3BlbnN5bmMgb3ZlciBvYmV4IHBsdWdpbiBp
cyBjcmVhdGVkLCBidXQKPiA+IG9ubHkgdGhlIGluaXRpYWxpemUgYW5kIGNvbm5lY3QgZnVuY3Rp
b25zIGFyZSBkaWZmZXJlbnQgb2YgdGhlIGh0dHAKPiA+IG9uZXMuIERvIG9ubHkgdGhlc2UgdHdv
IGZ1bmN0aW9ucyBwcm92aWRlIHRoZSBvYmV4IHN1cHBvcnQ/IE9yIGlzIGl0Cj4gPiBuZWNlc3Nh
cnkgdG8gaW1wbGVtZW50IHRoZSBvdGhlcnMgdG9vPwo+Cj4gbm8uIGkgYWJzdHJhY3RlZCBtdWNo
IG9mIHRoZSBjb25uZWN0aW9uIGluIHRoZSBzeW5jbWwgbGlicmFyeSBzbyBvbmx5Cj4gdGhlc2Ug
MiBmdW5jdGlvbnMgaGF2ZSB0byBiZSBkaWZmZXJlbnQKPgo+ID4KPiA+ICAgIEkgbm90aWNlZCB0
b28gdGhhdCB0aGUgc3VwcG9ydCB0byBzeW5jbWwgaXMgZG9uZSBieSB0aGUgbGlic2luY21sCj4g
PiBsaWJyYXJ5LiBJcyB0aGlzIG9iZXggc3VwcG9ydCB3b3JraW5nIGluIHRoaXMgbGlicmFyeT8g
T3IgZG9lcyBpdCBmb2xsb3cKPiA+IHRoZSBwbHVnaW4gZGV2ZWxvcG1lbnQ/Cj4KPiBvYmV4IGl0
c2VsZiBpcyBhbHJlYWR5IHdvcmtpbmcgaW4gdGhlIGxpYnJhcnkuIGJ1dCB0aGVyZSBhcmUgc29t
ZSBvdGhlcgo+IGlzc3VlcyB0byBhcmUgbm90IHlldCB3b3JraW5nIGFuZCB3aGljaCBpIGFtIGlt
cGxlbWVudGluZyBhdCB0aGUgbW9tZW50Lgo+Cj4KPiA+Cj4gPiAgICBJIHdvdWxkIGxpa2UgdG8g
a25vdyB0b28gaWYgdGhlcmUgYXJlIHNvbWUgaW1wbGVtZW50aW9uIHBsYW5zLCBvcgo+ID4gc29t
ZXRoaW5nIHRvIGdpdmUgbWUgYSBzdGFydGluZyBwb2ludCB0byBrbm93IHdoYXQgaGFzIHRvIGJl
IGRvbmUuCj4gPgo+Cj4gdGhlcmUgaXMgbm8gImZvcm1hbCIgaW1wbGVtZW50YXRpb24gcGxhbiBm
b3IgdGhlIGxpYnJhcnkgYW5kIHRoZSBwbHVnaW4uCj4KPiBkaWQgeW91IGFscmVhZHkgdGFrZSBh
IGxvb2sgYXQgdGhlIGFyY2hpdGVjdHVyZSBvZiBzeW5jbWwgbGlicmFyeT8gaWYKPiB5b3Ugd2Fu
dCBpIGNhbiBnaXZlIHlvdSBhIHNob3J0IGludHJvZHVjdGlvbiB0byBob3cgaXQgaXMgaW1wbGVt
ZW50ZWQuCj4KPiBBcm1pbgo+Cj4gPgo+ID4KPiA+IC0tCj4gPiDBZHJpYW4gTO12aW8KPiA+IG5o
ZGV6b2l0b0BnbWFpbC5jb20gPG1haWx0bzpuaGRlem9pdG9AZ21haWwuY29tPgo+ID4KPiA+IFRy
YWluZWUgaW4gdGhlCj4gPiBOb2tpYSBUZWNobm9sb2d5IEluc3RpdHV0ZSAtIElOZFQgLSB3d3cu
aW5kdC5vcmcgPGh0dHA6Ly93d3cuaW5kdC5vcmcvPgo+ID4gPGh0dHA6Ly93d3cuaW5kdC5vcmcv
Pgo+ID4gRWxlY3RyaWNhbCBFbmdlbmVlcmluZyBzdHVkZW50IGluIHRoZQo+ID4gRmVkZXJhbCBV
bml2ZXJzaXR5IG9mIENhbXBpbmEgR3JhbmRlIC0gVUZDRyAtIHd3dy51ZmNnLmVkdS5icgo+ID4g
PGh0dHA6Ly93d3cudWZjZy5lZHUuYnIvPgo+ID4gQ2VudHJlIG9mIEVsZWN0cmljYWwgRW5nZW5l
ZXJpbmcgYW5kIEluZm9ybWF0aWNzIC0gQ0VFSQo+ID4gQWNhZGVtaWMgVW5pdCBvZiBFbGVjdHJp
Y2FsIEVuZ2VuZWVyaW5nIC0gVUFFRSAtIHd3dy5lZS51ZmNnLmVkdS5icgo+ID4gPGh0dHA6Ly93
d3cuZWUudWZjZy5lZHUuYnIvPgo+ID4gTGFib3JhdG9yeSBvZiBFbWJlZGRlZCBTeXN0ZW1zIGFu
ZCBQZXJ2YXNpdmUgQ29tcHV0aW5nIC0KPiA+IHd3dy5lbWJlZGRlZGFjYWRlbXkub3JnIDxodHRw
Oi8vd3d3LmVtYmVkZGVkYWNhZGVteS5vcmcvPgo+Cj4KPgo+CgoKLS0KwWRyaWFuIEztdmlvClVu
aXZlcnNpZGFkZSBGZWRlcmFsIGRlIENhbXBpbmEgR3JhbmRlIC0gVUZDRyAtIHd3dy51ZmNnLmVk
dS5icgpDZW50cm8gZGUgRW5nZW5oYXJpYSBFbOl0cmljYSBlIEluZm9ybWF0aWNhIC0gQ0VFSQpV
bmlkYWRlIEFjYWTqbWljYSBkZSBFbmdlbmhhcmlhIEVs6XRyaWNhIC0gVUFFRSAtIHd3dy5lZS51
ZmNnLmVkdS5icgpMYWJvcmF083JpbyBkZSBTaXN0ZW1hcyBFbWJhcmNhZG9zIGUgQ29tcHV0Yefj
byBQZXJ2YXNpdmEgLQp3d3cuZW1iZWRkZWRhY2FkZW15Lm9yZwoKLS0tLQoKICAgIE7jbyBleGlz
dGUgZW1v5+NvLCBlIHNpbSBwYXouCiAgICBO428gZXhpc3RlIGlnbm9y4m5jaWEsIGUgc2ltIGNv
bmhlY2ltZW50by4KICAgIE7jbyBleGlzdGUgcGFpeONvLCBlIHNpbSBzZXJlbmlkYWRlLgogICAg
TuNvIGV4aXN0ZSBjYW9zLCBlIHNpbSBoYXJtb25pYS4KICAgIE7jbyBleGlzdGUgbW9ydGUsIGUg
c2ltIGEgRm9y52EuCiAgICCXTyBD82RpZ28gSmVkaQoKCgoKCgoKCkZOT1JECg==

Re: [Opensync-users] evolution2 plugin not compatible with data-server???

[Matteo B. <m.b...@mb...>]

After installed evolution-devel pack too, the error compiling
(configuring) remains.....

help me please!!!

Regards

Il giorno gio, 02/02/2006 alle 14.41 +0100, Matteo Bottiroli ha scritto:

> in config.in (evo2 plugin, i'm trying to compile)
> 
> pkg_modules="glib-2.0 opensync-1.0"
> pkg_emodules_10="evolution-data-server-1.0 libebook-1.0 libecal-1.0
> libedata-book-1.0 libedata-cal-1.0 libedataserver-1.0"
> pkg_emodules_11="evolution-data-server-1.1 libebook-1.1 libecal-1.1
> libedata-book-1.1 libedata-cal-1.1 libedataserver-1.1"
> pkg_emodules_12="evolution-data-server-1.2 libebook-1.2 libecal-1.2
> libedata-book-1.2 libedata-cal-1.2 libedataserver-1.2"
> 
> export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}:/usr/lib/pkgconfig:
> $prefix/lib/pkgconfig:/usr/local/lib/pkgconfig
> 
> PKG_CHECK_MODULES(PACKAGE, [$pkg_modules], , AC_MSG_ERROR(GLib >= 2.0
> and opensync >= 1.0 required))
> 
> AC_SUBST(PACKAGE_CFLAGS)
> AC_SUBST(PACKAGE_LIBS)
> 
> PKG_CHECK_MODULES(EPACKAGE, [$pkg_emodules_10], EDSFOUND=1,
> [EDSFOUND=0])
> if test "x${EDSFOUND}" = "x0"; then
>         PKG_CHECK_MODULES(EPACKAGE, [$pkg_emodules_11], EDSFOUND=1,
> [EDSFOUND=0])
>         if test "x${EDSFOUND}" = "x0"; then
>                 PKG_CHECK_MODULES(EPACKAGE,
> [$pkg_emodules_12],,AC_MSG_ERROR(No compatible evolution-data-server was
> found))
>         fi
> fi
> 
> i can see just 1.0 1.1 1.2 data-server, not 1.4 (installed via rpm)
> 
> On Thu, 2006-02-02 at 14:35 +0100, David Eriksson wrote:
> > On Thu, 2006-02-02 at 13:48 +0100, Matteo Bottiroli wrote:
> > > After a configure , i got this:
> > > 
> > > [root@localhost evolution2]# autoreconf -sfi configure.in: installing
> > > `./install-sh'
> > > configure.in: installing `./missing'
> > > src/Makefile.am: installing `./depcomp'
> > > [root@localhost evolution2]# ./configure
> > > checking for a BSD-compatible install... /usr/bin/install -c
> > > checking whether build environment is sane... yes
> > > checking for gawk... gawk
> > > checking whether make sets $(MAKE)... yes
> > > checking for pkg-config... /usr/bin/pkg-config
> > > checking pkg-config is at least version 0.9.0... yes
> > > checking for PACKAGE... yes
> > > checking for EPACKAGE... checking for EPACKAGE... checking for
> > > EPACKAGE... configure: error: No compatible evolution-data-server was
> > > found
> > > 
> > > my install is:
> > > evolution-data-server-1.4.2.1-1.1.fc4.nr
> > > evolution-2.4.2.1-1.1.fc4.nr
> > > evolution-connector-2.4.2-1.1.fc4.nr
> > > 
> > > why???
> > 
> > You probably need the corresponding -devel packages.
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Opensync-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-users
> 

Re: [Opensync-users] evolution2 plugin not compatible with data-server???

[Matteo B. <m.b...@mb...>]

in config.in (evo2 plugin, i'm trying to compile)

pkg_modules="glib-2.0 opensync-1.0"
pkg_emodules_10="evolution-data-server-1.0 libebook-1.0 libecal-1.0
libedata-book-1.0 libedata-cal-1.0 libedataserver-1.0"
pkg_emodules_11="evolution-data-server-1.1 libebook-1.1 libecal-1.1
libedata-book-1.1 libedata-cal-1.1 libedataserver-1.1"
pkg_emodules_12="evolution-data-server-1.2 libebook-1.2 libecal-1.2
libedata-book-1.2 libedata-cal-1.2 libedataserver-1.2"

export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}:/usr/lib/pkgconfig:
$prefix/lib/pkgconfig:/usr/local/lib/pkgconfig

PKG_CHECK_MODULES(PACKAGE, [$pkg_modules], , AC_MSG_ERROR(GLib >= 2.0
and opensync >= 1.0 required))

AC_SUBST(PACKAGE_CFLAGS)
AC_SUBST(PACKAGE_LIBS)

PKG_CHECK_MODULES(EPACKAGE, [$pkg_emodules_10], EDSFOUND=1,
[EDSFOUND=0])
if test "x${EDSFOUND}" = "x0"; then
        PKG_CHECK_MODULES(EPACKAGE, [$pkg_emodules_11], EDSFOUND=1,
[EDSFOUND=0])
        if test "x${EDSFOUND}" = "x0"; then
                PKG_CHECK_MODULES(EPACKAGE,
[$pkg_emodules_12],,AC_MSG_ERROR(No compatible evolution-data-server was
found))
        fi
fi

i can see just 1.0 1.1 1.2 data-server, not 1.4 (installed via rpm)

On Thu, 2006-02-02 at 14:35 +0100, David Eriksson wrote:
> On Thu, 2006-02-02 at 13:48 +0100, Matteo Bottiroli wrote:
> > After a configure , i got this:
> > 
> > [root@localhost evolution2]# autoreconf -sfi configure.in: installing
> > `./install-sh'
> > configure.in: installing `./missing'
> > src/Makefile.am: installing `./depcomp'
> > [root@localhost evolution2]# ./configure
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether build environment is sane... yes
> > checking for gawk... gawk
> > checking whether make sets $(MAKE)... yes
> > checking for pkg-config... /usr/bin/pkg-config
> > checking pkg-config is at least version 0.9.0... yes
> > checking for PACKAGE... yes
> > checking for EPACKAGE... checking for EPACKAGE... checking for
> > EPACKAGE... configure: error: No compatible evolution-data-server was
> > found
> > 
> > my install is:
> > evolution-data-server-1.4.2.1-1.1.fc4.nr
> > evolution-2.4.2.1-1.1.fc4.nr
> > evolution-connector-2.4.2-1.1.fc4.nr
> > 
> > why???
> 
> You probably need the corresponding -devel packages.
> 

Re: [Opensync-users] evolution2 plugin not compatible with data-server???

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

On Thu, 2006-02-02 at 13:48 +0100, Matteo Bottiroli wrote:
> After a configure , i got this:
> 
> [root@localhost evolution2]# autoreconf -sfi configure.in: installing
> `./install-sh'
> configure.in: installing `./missing'
> src/Makefile.am: installing `./depcomp'
> [root@localhost evolution2]# ./configure
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking for PACKAGE... yes
> checking for EPACKAGE... checking for EPACKAGE... checking for
> EPACKAGE... configure: error: No compatible evolution-data-server was
> found
> 
> my install is:
> evolution-data-server-1.4.2.1-1.1.fc4.nr
> evolution-2.4.2.1-1.1.fc4.nr
> evolution-connector-2.4.2-1.1.fc4.nr
> 
> why???

You probably need the corresponding -devel packages.

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

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

[Opensync-users] evolution2 plugin not compatible with data-server???

[Matteo B. <m.b...@mb...>]

After a configure , i got this:

[root@localhost evolution2]# autoreconf -sfi configure.in: installing
`./install-sh'
configure.in: installing `./missing'
src/Makefile.am: installing `./depcomp'
[root@localhost evolution2]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for PACKAGE... yes
checking for EPACKAGE... checking for EPACKAGE... checking for
EPACKAGE... configure: error: No compatible evolution-data-server was
found

my install is:
evolution-data-server-1.4.2.1-1.1.fc4.nr
evolution-2.4.2.1-1.1.fc4.nr
evolution-connector-2.4.2-1.1.fc4.nr

why???

Regards.

Re: [Opensync-users] SyncML over bluetooth/obex again

[Martin S. <mar...@hi...>]

You need a recent cvs checkout of openobex.

Martin


Am Montag, den 30.01.2006, 15:27 -0200 schrieb =C1drian L=EDvio:
> Hi=20
>=20
>    I'm trying to build the libyscml-threaded version,  I instaled the
> libsoup-2.2.9, and patched the libwbxml with the patch in the
> libyscml-threaded dir, I have also instaled the openobex-dev package,
> but when I run the configure script:
>=20
> ./configure --prefix=3D/home/local/workspace/syncml-testdir
> --with-wbxml=3D/home/local/workspace/syncml-testdir
>=20
>    I got:
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>   Unit Tests:             Enabled
>   Tracing:                Enabled
>   Tools:                  Enabled
>   Libwbxml:               Enabled
>=20
> The transports are:
>   Http Client:            Enabled
>   Http Server:            Enabled
>   Obex Client:            Disabled
>   Obex Server:            Disabled
>=20
> Done configuring.
> Please review the settings above
> If they are ok, build libsyncml and install it.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
>     I noticide that there is no openobex.pc file
> in /usr/lib/pkgconfig/ then I create one:
>=20
> # Package Information for pkg-config
>=20
> prefix=3D/usr
> exec_prefix=3D${prefix}
> libdir=3D${exec_prefix}/lib
> includedir=3D${prefix}/include
>=20
> Name: openobex
> Description: openobex adricionado por mim
> Version:1.0
> Libs: -L${libdir} -lopenobex
> Cflags: -I${includedir}
>=20
>    but the configure script don't work, in the configure.ac file I
> noticed that the required version is the 1.1,
>=20
> PKG_CHECK_MODULES(LIBOPENOBEX, openobex >=3D 1.1, HAVE_OPENOBEX=3Dyes,
> HAVE_OPENOBEX=3Dno)
>=20
> Someone can help me?
>=20
> Regards,=20
> =C1drian L=EDvio
> Universidade Federal de Campina Grande - UFCG - www.ufcg.edu.br
> Centro de Engenharia El=E9trica e Informatica - CEEI=20
> Unidade Acad=EAmica de Engenharia El=E9trica - UAEE - www.ee.ufcg.edu.br
> Laborat=F3rio de Sistemas Embarcados e Computa=E7=E3o Pervasiva -
> www.embeddedacademy.org
>=20
> 2006/1/28, Martin Schulze <mar...@hi...>:
>         I've had a look at the libsyncml-threaded version this
>         evening. From the
>         sparse information that I could get, this seems to be the
>         actively
>         maintained branch. Attached are patches to this branch and the
>         sycml-plugin from trunk.=20
>        =20
>         With these patches applied to current svn, sycml-plugin
>         compiles and
>         runs with the libyscml-threaded version. There is no
>         ChangeLog, so I
>         have enclosed a short description of the changes below.
>        =20
>         msynctool still doesn't work with my mobile phone. It doesn't
>         seem to=20
>         react on the SAN. I gather so much that SAN requires syncml
>         1.2 (at
>         least the way it is currently implemented in libsyncml) and
>         the SGH-D600
>         only support syncml 1.1.
>        =20
>         Regards,
>        =20
>           Martin
>        =20
>         _____________________________________________=20
>        =20
>         libsyncml-2006_01_29.diff:
>        =20
>                 libsyncml/sml_queue.c: Rename the callback functions.
>         Before, the
>         callback functions from libopensync/osengine/osengine_queue.c
>         were
>         called on my testing platform (leading to SEGFAULT).=20
>                 libsyncml/sml_transport.c: Fix typo in the
>         documentation.
>                 libsyncml/sml_manager.c: Enhance
>         _smlManagerDataHandler() to handle to
>         only event type SML_TRANSPORT_EVENT_DATA. TODO: Probably,
>         events of type=20
>         SML_TRANSPORT_EVENT_CONNECT_DONE should also be forwarded to
>         manager->eventCallback(). However, there is no SML_MANAGER*
>         macro for
>         this, yet.
>                 smlManagerSessionRemove() now calls
>         manager->eventCallback() with=20
>         SML_MANAGER_SESSION_END.
>                 smlManagerNew(): Fix typo.
>                 libsyncml/sml_support.c: The idle callback doesn't get
>         called when a
>         new thread is started. Work around: _start_main_loop().
>        =20
>         syncml-plugin-2006_01_29.diff:=20
>        =20
>                 src/syncml_plugin.[hc]: Make it work with the
>         libsyncml-threaded branch
>         of libsyncml. Use smlManager to manage sessions. I'm not sure
>         whether
>         SmlDsSession is used correctly in batch_commit().
>                 src/syncml-obex-client: Rename 'path' to 'url'. Add
>         new parameter=20
>         'port'.
>        =20
>        =20
>         Am Samstag, den 28.01.2006, 02:18 +0100 schrieb Martin
>         Schulze:
>         > Am Samstag, den 28.01.2006, 01:36 +0100 schrieb Martin
>         Schulze:
>         > > Am Freitag, den 27.01.2006, 12:43 -0200 schrieb =C1drian
>         L=EDvio:=20
>         > > > Hi
>         > > >    I am also studing the libsyncml.
>         > > >
>         > > >    Which version of the libsyncml are you studing, the
>         libsyncml
>         > > > (trunk) or libsyncml-threaded (branch)?=20
>         > >
>         > > I have checked out the trunk version (following the
>         instructions in the
>         > > wiki). I will try the libsyncml-threaded version ...
>         > >
>         > > >    Do you have any problem building the lib?=20
>         > >
>         > > trunk compiles out-of-the-box.
>         >
>         > So does libsyncml-threaded (with current cvs versions of
>         openobex and
>         > libsoup). However, sycml-plugin doesn't compile with
>         > libsyncml-threaded  ...=20
>         >
>         > Regards,
>         >
>         >   Martin
>         >
>         > > > Thanks.
>         > > >
>         > > > --
>         > > > =C1drian L=EDvio
>         > > > Universidade Federal de Campina Grande - UFCG -
>         www.ufcg.edu.br
>         > > > Centro de Engenharia El=E9trica e Informatica - CEEI
>         > > > Unidade Acad=EAmica de Engenharia El=E9trica - UAEE -
>         www.ee.ufcg.edu.br
>         > > > Laborat=F3rio de Sistemas Embarcados e Computa=E7=E3o
>         Pervasiva -
>         > > > www.embeddedacademy.org
>         > > >
>         > > >=20
>         > > > 2006/1/26, Martin Schulze <mar...@hi...>:
>         > > >         I have the impression that the SGH-D600 doesn't
>         support the=20
>         > > >         full syncml=20
>         > > >         specification. In particular,
>         > > >         http://www.traud.de/gsm/samsung.htm names
>         > > >         some restictions on the sync alert sent by the
>         server.=20
>         > > >         Therefore, I'm
>         > > >         trying to gain a more detailed understanding of
>         the libsyncml
>         > > >         code.
>         > > >
>         > > >         Currently, I don't understand the following
>         point:=20
>         > > >
>         > > >           libopensync obviously waits for a feedback on
>         the
>         > > >         notification request
>         > > >         (which my mobile phone doesn't give; see last
>         email). As far=20
>         > > >         as I can
>         > > >         gather from the code, the execution flow should
>         be like this:
>         > > >
>         > > >           smlTransportReceive() -> smlSessionReceive()
>         ->=20
>         > > >         smlSessionDispatchCommand() -> [chain of
>         callbacks] ->
>         > > >         osync_context_report_success()
>         > > >
>         > > >         If osync_context_report_success() is not called
>         within 60s=20
>         > > >         after the
>         > > >         notification request, a timeout error is
>         reported (which is
>         > > >         what I get).
>         > > >
>         > > >         However, even if the SGH-D600 _would_ send an
>         answer, I don't=20
>         > > >         understand
>         > > >         how the above call chain can be triggered:
>         > > >         smlTransportReceive() doesn't
>         > > >         get called from the OBEX transport layer,
>         neither gets=20
>         > > >         smlDsServerRegister() which registers the first
>         callback in
>         > > >         [chain of
>         > > >         callbacks]. (Both functions get called from the
>         http transport
>         > > >         layer.)=20
>         > > >         Is the OBEX transport layer incomplete? Did I
>         miss something?
>         > > >
>         > > >         Regards,
>         > > >
>         > > >           Martin
>         > > >
>         > > >=20
>         > > >         Am Donnerstag, den 26.01.2006, 00:45 +0100
>         schrieb Martin
>         > > >         Schulze:
>         > > >         > $ msynctool --sync testsync --wait
>         > > >         >                             ^^^^^^
>         > > >         >
>         > > >         > As it turns out, this was _not_ the way to go
>         for the
>         > > >         SGH-D600.
>         > > >         >
>         > > >         >=20
>         > > >         > Instead, I had to insert a hack in
>         > > >         >
>         > > >         > libsyncml/libsyncml/transport/obex_client.c
>         > > >         >
>         > > >         > that sends an AT command=20
>         > > >         >
>         > > >         > AT+CPROT=3D0
>         > > >         >
>         > > >         > to the pseudo serial device and listens for
>         the answer
>         > > >         >=20
>         > > >         > CONNECT
>         > > >         >
>         > > >         > _before_ sending the OBEX connect request.
>         Then, the
>         > > >         SGH-D600 answers
>         > > >         > with a connect response with connection ID 2.
>         Am OBEX put=20
>         > > >         (final)
>         > > >         > request follows and gets a success respone.
>         > > >         >
>         > > >         > Unfortunately, nothing more happens. After
>         while, msynctool=20
>         > > >         quits with
>         > > >         > the message
>         > > >         >
>         > > >         > Member 2 of type syncml-obex-client had an
>         error while
>         > > >         connecting:=20
>         > > >         > Timeout while waiting for a reply to message
>         "CONNECT"
>         > > >         > ...
>         > > >         >
>         > > >         > What exactly it is msynctool waiting for? Any
>         ideas why it=20
>         > > >         doesn't get
>         > > >         > what it awaits?
>         > > >         >
>         > > >         >
>         > > >         > Regards,
>         > > >         >
>         > > >         >   Martin
>         > > >         >
>         > > >         >
>         > > >         > Am Montag, den 23.01.2006, 17:47 +0100 schrieb
>         Martin
>         > > >         Schulze:
>         > > >         > > $ msynctool --sync testsync --wait
>         > > >         > >
>         > > >         > > This doesn't seem to work for the Samsung -
>         at least I
>         > > >         have no idea how=20
>         > > >         > > to initiate the sync from the SGH-D600,
>         then, so the
>         > > >         msynctool waits ad
>         > > >         > > infinitum.
>         > > >         > >
>         > > >         > > What changes are needed in libsyncml to
>         trigger the
>         > > >         syncronization from
>         > > >         > > the pc side?
>         > > >         > >
>         > > >         > > Regards,=20
>         > > >         > >
>         > > >         > >   Martin
>         > > >         > >
>         > > >         > >
>         > > >         > > Am Montag, den 23.01.2006, 11:25 +0000
>         schrieb kevin=20
>         > > >         james:
>         > > >         > > > I've been trying to sync my Nokia 6680
>         with opensync,
>         > > >         first trying the
>         > > >         > > > syncml-http-server, until I realised that
>         it is only
>         > > >         inbound and my
>         > > >         > > > laptop doesn't have a "real" IP address.
>         > > >         > > >=20
>         > > >         > > > Then I tried using the obex-client - some
>         info on the
>         > > >         mailing list
>         > > >         > > > archive (from around November time) says
>         it's still not
>         > > >         working, don't
>         > > >         > > > know if that's changed yet. Also I
>         couldn't find any
>         > > >         info on what the
>         > > >         > > > config needs to be.
>         > > >         > > >
>         > > >         > > > One thing (I think) I did find out is that
>         the=20
>         > > >         obex-client is also
>         > > >         > > > inbound only, so you will need to test it
>         with:
>         > > >         > > >
>         > > >         > > > $ msynctool --sync testsync --wait=20
>         > > >         > > >
>         > > >         > > > so that it will wait for a connection.
>         > > >         > > >
>         > > >         > > > I am still having problems at the phone
>         end trying to
>         > > >         use bluetooth/obex
>         > > >         > > > so I have no messages from opensync saying
>         if anything
>         > > >         has worked or
>         > > >         > > > not. I saw someone mention that some of
>         the devs have
>         > > >         6680's - do any of
>         > > >         > > > them have any advice?
>         > > >         > > >
>         > > >         > > > Cheers,=20
>         > > >         > > > KEv.
>         > > >         > > >
>         > > >         > > >
>         > > >         > > > On Mon, 2006-01-23 at 01:11 +0100, Martin
>         Schulze wrote:
>         > > >         > > > > Hi!
>         > > >         > > > >
>         > > >         > > > > Encouraged by
>         > > >         > > > >
>         > > >         > > > >
>         > > >
>         http://sourceforge.net/mailarchive/forum.php?thread_id=3D9428612&=
forum_id=3D44467
>         > > >         > > > >
>         > > >         > > > > I've configured a synchronizing group
>         between my
>         > > >         evolution environment
>         > > >         > > > > (plugin evo2-sync) and /dev/rfcomm0
>         (plugin
>         > > >         syncml-obex-client) which is=20
>         > > >         > > > > bound to the serial port bluetooth
>         service of my
>         > > >         mobile phone (Samsung
>         > > >         > > > > SGH-D600). libsyncml and syncml-plugin
>         are fresh
>         > > >         checkouts from svn. The
>         > > >         > > > > configuration for the syncml-plugin
>         reads:
>         > > >         > > > >=20
>         > > >         > > > > <config>
>         > > >         > > > >   <username></username>
>         > > >         > > > >   <password></password>=20
>         > > >         > > > >   <path>/dev/rfcomm0</path>
>         > > >         > > > >   <type>1</type>
>         > > >         > > > >   <usestringtable>2</usestringtable>
>         > > >         > > > >   <onlyreplace>0</onlyreplace>
>         > > >         > > > >   <contact_db>addressbook</contact_db>
>         > > >         > > > >   <calendar_db>calendar</calendar_db>
>         > > >         > > > >   <task_db>tasks</task_db>
>         > > >         > > > > </config>
>         > > >         > > > >
>         > > >         > > > > However, I run into the same troubles
>         discussed in
>         > > >         > > > >
>         > > >         > > > >
>         > > >
>         http://sourceforge.net/mailarchive/forum.php?thread_id=3D8902424&=
forum_id=3D44467
>         > > >         > > > >
>         > > >         > > > > E.i.
>         > > >         > > > >=20
>         > > >         > > > > $ msynctool --sync testsync
>         > > >         > > > >
>         > > >         > > > > yields:
>         > > >         > > > >=20
>         > > >         > > > > Synchronizing group "testsync"
>         > > >         > > > > Member 1 of type evo2-sync just
>         connected
>         > > >         > > > > Member 2 of type syncml-obex-client had
>         an error while
>         > > >         connecting: No
>         > > >         > > > > success
>         > > >         > > > > Member 1 of type evo2-sync just
>         disconnected=20
>         > > >         > > > > All clients have disconnected
>         > > >         > > > > The sync failed: Unable to connect one
>         of the members
>         > > >         > > > > Error synchronizing: Unable to connect
>         one of the
>         > > >         members
>         > > >         > > > >
>         > > >         > > > > The trace output from the
>         syncml-obex-client plugin
>         > > >         reads as follows:
>         > > >         > > > >
>         > > >         > > > > [1137969737.641293]     +++++++++ This
>         is the client
>         > > >         #2
>         > > >         > > > > (syncml-obex-client plugin) of group
>         testsync
>         > > >         +++++++++
>         > > >         > > > > [1137969737.746230 ]
>         > > >         >>>>>>>  client_message_handler(0x80638f0,
>         > > >         > > > > 0x8077aa0, 0x80614e0)
>         > > >         > > > > [1137969737.746285]             [CLI]
>         DEBUG: Client
>         > > >         message handler
>         > > >         > > > > called for message "CONNECT"
>         > > >         > > > > [1137969737.746306]
>         > > >         >>>>>>>  osync_member_connect(0x80625c0,
>         > > >         > > > > 0xb7ebbd70, 0x8077aa0)
>         > > >         > > > > [1137969737.746330]
>         >>>>>>>
>         > > >         > > > > client_connect(0x8077e08)
>         > > >         > > > > [1137969741.853995]
>         > > >         >>>>>>>=20
>         > > >         > > > >
>         osync_context_report_osyncerror(0x8077e08,
>         > > >         0xb6b99244:(No success))
>         > > >         > > > > [1137969741.854070]
>         > > >         [CLI] WARNING:=20
>         > > >         > > > > Member is replying with message
>         0x807ef48 to message
>         > > >         0x8077aa0:"CONNECT"
>         > > >         > > > > with error 1: No success
>         > > >         > > > > [ 1137969741.854106]
>         > > >         <<<<<<<
>         > > >         > > > > osync_context_report_osyncerror
>         > > >         > > > > [1137969741.854126]
>         <--- ERROR ---
>         > > >         client_connect:
>         > > >         > > > > No success
>         > > >         > > > > [1137969741.854145]
>         > > >         <<<<<<<  osync_member_connect=20
>         > > >         > > > > [1137969741.854163]
>         > > >         <<<<<<<  client_message_handler
>         > > >         > > > >
>         > > >         > > > > Does anybody have an idea where the
>         problem lies? To
>         > > >         start with: is it
>         > > >         > > > > more likely from the OBEX transport
>         layer or a SyncML
>         > > >         related problem?
>         > > >         > > > > Is there anything I can do to help
>         getting the thing
>         > > >         to work?
>         > > >         > > > >
>         > > >         > > > > The only information related to SyncML
>         with my mobile
>         > > >         phone I've found
>         > > >         > > > > up to now is here:
>         > > >         > > > >
>         > > >         > > > > http://www.traud.de/gsm/samsung.htm
>         > > >         > > > >=20
>         > > >         > > > > I have just e-mailed Samsung about the
>         SyncML version
>         > > >         that the SGH-D600
>         > > >         > > > > is using. Has it already been clarified,
>         how to find
>         > > >         the correct values
>         > > >         > > > > of the XXX_db parameters in the
>         configuration of the
>         > > >         syncml-plugin?
>         > > >         > > > >
>         > > >         > > > > Regards,
>         > > >         > > > >=20
>         > > >         > > > >   Martin
>         > > >         > > > >
>         > > >         > > > >
>         > > >         > > > >
>         > > >         > > > >=20
>         > > >         > > > >
>         > > >
>         -------------------------------------------------------
>         > > >         > > > > This SF.net email is sponsored by:
>         Splunk Inc. Do you
>         > > >         grep through log files
>         > > >         > > > > for problems?  Stop!  Download the new
>         AJAX search
>         > > >         engine that makes
>         > > >         > > > > searching your log files as easy as
>         surfing
>         > > >         the  web.  DOWNLOAD SPLUNK!
>         > > >         > > > >=20
>         > > >
>         http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D2304=
86&dat=3D121642
>         > > >         > > > >
>         _______________________________________________=20
>         > > >         > > > > Opensync-users mailing list
>         > > >         > > > > Ope...@li...
>         > > >         > > > >=20
>         > > >
>         https://lists.sourceforge.net/lists/listinfo/opensync-users
>         > > >         > > > >
>         > > >         > > >=20
>         > > >         > >
>         > > >         > >
>         > > >         > >
>         > > >         > >
>         -------------------------------------------------------
>         > > >         > > This SF.net email is sponsored by: Splunk
>         Inc. Do you grep
>         > > >         through log files
>         > > >         > > for problems?  Stop!  Download the new AJAX
>         search engine
>         > > >         that makes
>         > > >         > > searching your log files as easy as surfing
>         > > >         the  web.  DOWNLOAD SPLUNK!
>         > > >         > >
>         > > >
>         http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D2304=
86&dat=3D121642
>         > > >         > >
>         _______________________________________________=20
>         > > >         > > Opensync-users mailing list
>         > > >         > > Ope...@li...
>         > > >         > >=20
>         > > >
>         https://lists.sourceforge.net/lists/listinfo/opensync-users
>         > > >         >
>         > > >         >=20
>         > > >         >
>         > > >         >
>         -------------------------------------------------------
>         > > >         > This SF.net email is sponsored by: Splunk Inc.
>         Do you grep
>         > > >         through log files=20
>         > > >         > for problems?  Stop!  Download the new AJAX
>         search engine
>         > > >         that makes
>         > > >         > searching your log files as easy as surfing
>         > > >         the  web.  DOWNLOAD SPLUNK!
>         > > >         >
>         > > >
>         http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D2304=
86&dat=3D121642
>         > > >         >
>         _______________________________________________=20
>         > > >         > Opensync-users mailing list
>         > > >         > Ope...@li...
>         > > >         >
>         https://lists.sourceforge.net/lists/listinfo/opensync-users
>         > > >
>         > > >
>         > > >
>         > > >
>         -------------------------------------------------------
>         > > >         This SF.net email is sponsored by: Splunk Inc.
>         Do you grep
>         > > >         through log files
>         > > >         for problems?  Stop!  Download the new AJAX
>         search engine that
>         > > >         makes
>         > > >         searching your log files as easy as surfing
>         > > >         the  web.  DOWNLOAD SPLUNK!
>         > > >
>         http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D2304=
86&dat=3D121642
>         > > >         _______________________________________________
>         > > >         Opensync-users mailing list
>         > > >         Ope...@li...
>         > > >
>         https://lists.sourceforge.net/lists/listinfo/opensync-users
>         > > >
>         > > >
>         > > >
>         > > >
>         > >
>         > >
>         > >
>         > > -------------------------------------------------------
>         > > This SF.net email is sponsored by: Splunk Inc. Do you grep
>         through log files=20
>         > > for problems?  Stop!  Download the new AJAX search engine
>         that makes
>         > > searching your log files as easy as surfing
>         the  web.  DOWNLOAD SPLUNK!
>         > >
>         http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=
=121642
>         > > _______________________________________________
>         > > Opensync-users mailing list
>         > > Ope...@li...
>         > >
>         https://lists.sourceforge.net/lists/listinfo/opensync-users
>         >
>         >
>         >
>         > -------------------------------------------------------=20
>         > This SF.net email is sponsored by: Splunk Inc. Do you grep
>         through log files
>         > for problems?  Stop!  Download the new AJAX search engine
>         that makes
>         > searching your log files as easy as surfing
>         the  web.  DOWNLOAD SPLUNK!=20
>         >
>         http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=
=121642
>         > _______________________________________________=20
>         > Opensync-users mailing list
>         > Ope...@li...
>         > https://lists.sourceforge.net/lists/listinfo/opensync-users
>        =20
>        =20
>=20

Re: [Opensync-users] Re: [OpenSync] #146: adapt syncml-plugin to work with libsyncml-threaded and make libsyncml more functional

[Martin S. <mar...@hi...>]

Am Donnerstag, den 02.02.2006, 01:28 +0100 schrieb Armin Bauer:
> 
> Martin Schulze wrote:
> > This ticket documents how far I've got with my efforts to sync my mobile
> > phone with some calendar on the pc.
> > 
> > Apart from the two patches, I need a hack in
> > smlTransportObexClientConnect() to initialize the OBEX server and the
> > syncml client on the SGH-D600. Also, to be compliant with the
> > information provided by http://www.traud.de/gsm/samsung.htm I need a
> > hacked openobex so that the OBEX PUT final command is an empty packet
> > without (end of) body header.
> > 
> > Still, my mobile doesn't give any response to the OBEX GET command that
> > I send after the (SyncML 1.1 compliant) server alert :-( I'm not really
> > sure what to try next.
> 
> what obex responds exactly do you get from the phone to the GET command?
> and are you sure that the server alert was correct (did you compare it
> to an alert of another working software?). some phone respond with
> errors on the obex layer if there was an error in the syncml data.

No response at all!
... until 10 minutes after this email: the OBEX body header has to be
sent with in a seperate package, otherwise the OBEX server on the mobile
phone hangs. I will try to make this configurable (so that the
syncml-plugin can decide according to the needs of the syncml-client)
and get the necessary patches into openobex this weekend.

Martin

> 
> Armin
> 
> > 
> > People with a Nokia phone might be more lucky. At least, the OBEX
> > packets sent over the line with the two patches from ticket #146 should
> > match the suggestions in
> > http://discussion.forum.nokia.com/forum/showthread.php?t=44303
> > 
> > Regards,
> > 
> >   Martin
> > 
> > 
> > Am Mittwoch, den 01.02.2006, 21:28 +0000 schrieb OpenSync:
> > 
> >>#146: adapt syncml-plugin to work with libsyncml-threaded and make libsyncml more
> >>functional
> >>---------------------------+------------------------------------------------
> >>       Id:  146            |      Status:  new                     
> >>Component:  SyncML-Plugin  |    Modified:  Wed Feb  1 22:28:44 2006
> >> Severity:  normal         |   Milestone:                          
> >> Priority:  normal         |     Version:                          
> >>    Owner:  ehabkost       |    Reporter:  mar...@hi... 
> >>---------------------------+------------------------------------------------
> >> All recent development seems to have gone into the "threaded" branch of
> >> libsyncml.
> >> However:
> >> - libsyncml-threaded is incomplete (e.g. session handling in SmlManager is
> >> non-functional)
> >> - syncml-plugin still targets libsyncml trunk
> >> - server initiated alerts (syncml 1.1) are not supported yet, which makes
> >> it pretty useless for many applications
> >>
> >>
> >> 
> >>Ticket URL: <http://www.opensync.org/ticket/146>
> >>OpenSync <http://www.opensync.org>
> >>A Synchronization Framework
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > _______________________________________________
> > Opensync-users mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-users
> > 

Re: [Opensync-users] SyncML over bluetooth/obex again

[Martin S. <mar...@hi...>]

More comprehensive patches including server alerts compliant to SyncML
1.1 are now in ticket #146. The problem with the idle command I don't
understand either. I will look at it again this weekend.


Am Donnerstag, den 02.02.2006, 02:12 +0100 schrieb Armin Bauer:
> Hi,
> 
> thanks for the patches! i will integrate them in libsyncml branch and
> the plugin once i find some time (probably means: after my exams :)
> 
> Martin Schulze wrote:
> > I've had a look at the libsyncml-threaded version this evening. From the
> > sparse information that I could get, this seems to be the actively
> > maintained branch. 
> 
> That is correct. All development is currently done in the threaded-branch.
> 
> > Attached are patches to this branch and the
> > sycml-plugin from trunk.
> > 
> > With these patches applied to current svn, sycml-plugin compiles and
> > runs with the libyscml-threaded version. There is no ChangeLog, so I
> > have enclosed a short description of the changes below.
> > 
> > msynctool still doesn't work with my mobile phone. It doesn't seem to
> > react on the SAN. I gather so much that SAN requires syncml 1.2 (at
> > least the way it is currently implemented in libsyncml) and the SGH-D600
> > only support syncml 1.1.
> 
> SAN was not defined prior to syncml 1.2 so there is no chance that a 1.1
> phone can make any sense of it. in syncml 1.1 you just have to send a
> normal alert to the phone to trigger the synchronization. I havent
> tested yet if this is correctly done (at least not with a real phone).
> 
> > 
> > Regards,
> > 
> >   Martin
> > 
> > _____________________________________________
> > 
> > libsyncml-2006_01_29.diff:
> > 
> > 	libsyncml/sml_queue.c: Rename the callback functions. Before, the
> > callback functions from libopensync/osengine/osengine_queue.c were
> > called on my testing platform (leading to SEGFAULT).
> 
> right. i think we should declare them static so that naming conflicts
> like this cannot happen (or use the proper prefix)
> 
> > 	libsyncml/sml_transport.c: Fix typo in the documentation.
> > 	libsyncml/sml_manager.c: Enhance _smlManagerDataHandler() to handle to
> > only event type SML_TRANSPORT_EVENT_DATA. TODO: Probably, events of type
> > SML_TRANSPORT_EVENT_CONNECT_DONE should also be forwarded to
> > manager->eventCallback(). However, there is no SML_MANAGER* macro for
> > this, yet.
> > 	smlManagerSessionRemove() now calls manager->eventCallback() with
> > SML_MANAGER_SESSION_END.
> > 	smlManagerNew(): Fix typo.
> > 	libsyncml/sml_support.c: The idle callback doesn't get called when a
> > new thread is started. Work around: _start_main_loop().
> 
> i dont really understand why this is necessary. i used this code quite
> often now and it worked very well.
> 
> > 
> > syncml-plugin-2006_01_29.diff:
> > 
> > 	src/syncml_plugin.[hc]: Make it work with the libsyncml-threaded branch
> > of libsyncml. Use smlManager to manage sessions. I'm not sure whether
> > SmlDsSession is used correctly in batch_commit().
> 
> looks ok from the very first glance. the idea is that the syncml session
> is used to control the commands that are sent and received. it also
> handles stuff like the fragmentation. then there might be one or more
> datasync session inside the syncml session where each ds session is
> responsible for synchronizing a single format. so a synchronization
> looks like this:
> 
> -> the syncml session is received
> -> the ds servers get called and return the ds session(s)
> -> the work is done on the ds sessions (like requesting data, sending
> changes etc).
> -> once each step is called for all ds sessions you call smlSessionFlush
> to flush all remaining commands in the syncml session
> 
> Best Regards,
> Armin Bauer
> 
> > 	src/syncml-obex-client: Rename 'path' to 'url'. Add new parameter
> > 'port'.
> > 

Re: [Opensync-users] SyncML over bluetooth/obex again

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

Hi,

thanks for the patches! i will integrate them in libsyncml branch and
the plugin once i find some time (probably means: after my exams :)

Martin Schulze wrote:
> I've had a look at the libsyncml-threaded version this evening. From the
> sparse information that I could get, this seems to be the actively
> maintained branch. 

That is correct. All development is currently done in the threaded-branch.

> Attached are patches to this branch and the
> sycml-plugin from trunk.
> 
> With these patches applied to current svn, sycml-plugin compiles and
> runs with the libyscml-threaded version. There is no ChangeLog, so I
> have enclosed a short description of the changes below.
> 
> msynctool still doesn't work with my mobile phone. It doesn't seem to
> react on the SAN. I gather so much that SAN requires syncml 1.2 (at
> least the way it is currently implemented in libsyncml) and the SGH-D600
> only support syncml 1.1.

SAN was not defined prior to syncml 1.2 so there is no chance that a 1.1
phone can make any sense of it. in syncml 1.1 you just have to send a
normal alert to the phone to trigger the synchronization. I havent
tested yet if this is correctly done (at least not with a real phone).

> 
> Regards,
> 
>   Martin
> 
> _____________________________________________
> 
> libsyncml-2006_01_29.diff:
> 
> 	libsyncml/sml_queue.c: Rename the callback functions. Before, the
> callback functions from libopensync/osengine/osengine_queue.c were
> called on my testing platform (leading to SEGFAULT).

right. i think we should declare them static so that naming conflicts
like this cannot happen (or use the proper prefix)

> 	libsyncml/sml_transport.c: Fix typo in the documentation.
> 	libsyncml/sml_manager.c: Enhance _smlManagerDataHandler() to handle to
> only event type SML_TRANSPORT_EVENT_DATA. TODO: Probably, events of type
> SML_TRANSPORT_EVENT_CONNECT_DONE should also be forwarded to
> manager->eventCallback(). However, there is no SML_MANAGER* macro for
> this, yet.
> 	smlManagerSessionRemove() now calls manager->eventCallback() with
> SML_MANAGER_SESSION_END.
> 	smlManagerNew(): Fix typo.
> 	libsyncml/sml_support.c: The idle callback doesn't get called when a
> new thread is started. Work around: _start_main_loop().

i dont really understand why this is necessary. i used this code quite
often now and it worked very well.

> 
> syncml-plugin-2006_01_29.diff:
> 
> 	src/syncml_plugin.[hc]: Make it work with the libsyncml-threaded branch
> of libsyncml. Use smlManager to manage sessions. I'm not sure whether
> SmlDsSession is used correctly in batch_commit().

looks ok from the very first glance. the idea is that the syncml session
is used to control the commands that are sent and received. it also
handles stuff like the fragmentation. then there might be one or more
datasync session inside the syncml session where each ds session is
responsible for synchronizing a single format. so a synchronization
looks like this:

-> the syncml session is received
-> the ds servers get called and return the ds session(s)
-> the work is done on the ds sessions (like requesting data, sending
changes etc).
-> once each step is called for all ds sessions you call smlSessionFlush
to flush all remaining commands in the syncml session

Best Regards,
Armin Bauer

> 	src/syncml-obex-client: Rename 'path' to 'url'. Add new parameter
> 'port'.
>