opensync-devel — The place to coordinate the development of OpenSync

[Opensync-devel] kitchensync

[deloptes <del...@ya...>]

I've fixed the member issue in kitchensync. Quentin will hopefully update
svn soon. I think it can be pushed to debian sid and other distros around
christmas, so that we may have testers of the whole environment.

What does the group think?

I also don't want to carry the burden of taking design decisions but I need
a hint to solve the id/remoteId issue in akonadi-sync.

regards

Re: [Opensync-devel] testing and documenting 0.4X

[Emanoil K. <del...@ya...>]

Chris,

I've worked on the akonadi stuff last weekend and I think it is good with all objsyncs now.

However there are still few issues that are bugging me.

Most of all when should I call update and report change and why if I reject a change (forcast sync) it then forgets about the change next time?
barry/google/evolution etc all have their own logic, so I don't know what exactly is going on behind those functions

Besides I found out in many of them after change_set_data usually *data  is freed and sometime also change is freed, however if I free change after data is free I get a free() corruption, which I found is probably related to change holding the pointer (and eventually deleting) - is it true?

in the current solution I found out it is better to free the change after reporting it.

Also the sync process needs to check id/remoteId not only id or remoteId. I found out setting and using the remoteId field in akonadi is very useful, but it also can lead to multiple items with the same UID. I definitely need to read more about it.

regards

PS: @Quenting. What is exactly the problem with kitchensync? The same as before or something new?


--- On Wed, 10/20/10, Chris Frey <cd...@fo...> wrote:

From: Chris Frey <cd...@fo...>
Subject: Re: testing and documenting 0.4X
To: "Quentin Denis" <que...@gm...>
Cc: "Emanoil Kotsev" <del...@ya...>, ewo...@kd...
Date: Wednesday, October 20, 2010, 8:13 PM

Hi Quentin,

Thanks for taking a stab at it.  Sorry that you ran into such a roadblock.

I'm still swamped this week.  I do need to get back to opensync things
very soon, but I have 3 or 4 loose end projects that need to be finished
first.

I think the GUIs are a weak spot in opensync... just like the plugins.
Everyone seems to use osynctool if they want reliability.

- Chris


On Tue, Oct 19, 2010 at 01:38:21PM +0200, Quentin Denis wrote:
> Hi guys,
> 
> I am very disappointed to report that removing the friend classes did not help 
> in fixing the bug. The error remains the same and I am about to give up. My 
> coding experience is definitely not far reaching enough to debug such an 
> issue.
> 
> People do not stop checking out and trying the kitchensync SVN, I am afraid of 
> disappointing those users with this blockage in the development.
> 
> Unless some external contributors will show up, I give you the lot of 
> kitchensync. Here is my last version: 
> http://dl.dropbox.com/u/3224566/kitchensync.tar.gz I did not commit it to svn 
> since it brings no fix.
> 
> Best regards,
> Quentin
> 
> 
> On Sunday 17 October 2010 20:30:13 you wrote:
> > On Sat, Oct 16, 2010 at 11:17:47AM +0200, Quentin Denis wrote:
> > > Hi Chris,
> > 
> > > How are you doing? I am writing you for a 3 small things:
> > Hi Quentin, good to hear from you.  I've been busy with Barry, processing
> > patches that improve Blackberry support, and reorganizing the library
> > code.  I've also been distracted by the new Ubuntu release, and
> > ran into a file corruption bug in User Mode Linux, so all that has
> > taken time away from opensync. :-)
> > 
> > > First, I have a small issue with the google-calendar plugin (the contacts
> > > should be ok since they sync successfully between SyncML, akonadi and
> > > file-
> > 
> > > sync):
> > Thanks for testing google-calendar.  Looking at your bug report, it looks
> > like the XSLT transform stuff is not yet working.  You'll have to
> > work with a different plugin until I get a chance to fix that up.
> > 
> > If you only sync calendar items, then I believe google-calendar will
> > be more reliable.  Contacts probably still need tweaking.
> > 
> > > Second, is possible to add the member/plugin-type in the following
> > > output:
> > > 
> > > ObjType: contact
> > > 
> > >         Member 2: Adding(0) Modifying(0) Deleting(0)
> > >         Member 1: Adding(5) Modifying(0) Deleting(0)
> > > 
> > > Let's say somehting like: Member 2 [file-sync]: Adding(0), Modifying(0),
> > > ...
> > 
> > I believe it is... it would be in the osynctool code, which would need
> > to call osync_member_get_pluginname().
> > 
> > Are you asking me to change it? :-)  Just want to be clear.
> > 
> > > Third, you recommended me to remove the friend statements to fix
> > > kitchensync. I had no time in the past weeks to hack again on
> > > kitchensync, but suppose I find some time for bigger modification, would
> > > you recommend me to write methods like getMember() and setMember() to
> > > replace the friend statement? Or are you thinking of a different
> > > solution?
> > 
> > Yes, something like that... the other way is to put all such data into
> > a struct, and then have one Get() function that returns a constant
> > reference to the struct, so it can't be changed.  To change it, you'd
> > need to use the setMember() functions.
> > 
> > Sort of like this:
> > 
> >     struct DataBlob
> >     {
> >         string something;
> >         int setting;
> >     };
> > 
> >     // then in the main class
> > 
> >     class Functionality
> >     {
> >         DataBlob m_data;
> > 
> >     public:
> >         const DataBlob& Get() const { return m_data; }
> > 
> >         void SetSomething(const string &s) { m_data.something = s; }
> >         void SetSetting(int s) { m_data.setting = s; }
> > 
> >         // and sometimes this even makes sense, if the blob
> >         // is truly simple data
> >         void Set(const DataBlob &d) { m_data = d; }
> >     };
> > 
> > Sometimes a series of simple get/set functions are are better, instead of
> > the struct method, but when porting legacy code that has a lot of public
> > variables, sometimes a single Get() that returns a const struct is easier.
> > 
> > The main advantage of get/set code, is that you can look at just the class
> > code, and verify that, yes, this code does not leak memory
> > or access invalid memory.  But if you have public data, or friend classes,
> > then you need to look at all the code that accesses the data to make
> > sure it is correct... a much harder job.
> > 
> > Of course, sometimes you do need friend classes.  I'm not saying to remove
> > it where it makes sense... I just seem to recall that 'friend' was used
> > in the kitchensync code as a convenience to avoid extra work, which might
> > now be coming back to bite us now that the code is large enough that it
> > is harder to understand.
> > 
> > Just my $0.02... There are lots of ways to debug things... gdb, valgrind,
> > logs... I just like code that is modular, since it makes maintenance
> > and programming easier.
> > 
> > - Chris



      

Re: [Opensync-devel] xmlEscapeEntities : char out of range

[deloptes <del...@ya...>]

Daniel Gollub wrote:

> On Friday, October 29, 2010 09:51:25 am deloptes wrote:
>> there is QString.toLatin1() pretty often in the code, but I am not a big
>> fan of old 8bit encoding done in Latin1, so what kind of encoding should
>> I use UTF-8?
> 
> Yes, please use in xmlformat utf8.
> 
> Best Regards,
> Daniel
> 

thanks. I think I know what's the problem.
akonadi-sync had an error and exported empty data so file-sync created empty
files which reported in the next sync are breaking in xml - cool :-).

my question however was if when storing data into osync_data obj I should
use QSring.toUtf8() instead toLatin1. This means how the bytestream should
be formated when stored with set_data, respectively if using utf8 for
reading and dealing with hashes.

I'm not sure if it makes difference, but it should as the bytestream, stored
in char* should be constant, so 

thanks

Re: [Opensync-devel] xmlEscapeEntities : char out of range

[Daniel G. <go...@b1...>]

On Friday, October 29, 2010 09:51:25 am deloptes wrote:
> there is QString.toLatin1() pretty often in the code, but I am not a big
> fan of old 8bit encoding done in Latin1, so what kind of encoding should I
> use UTF-8?

Yes, please use in xmlformat utf8.

Best Regards,
Daniel

-- 
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970 
Mail: go...@b1...

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

[Opensync-devel] xmlEscapeEntities : char out of range

[deloptes <del...@ya...>]

this is the other thing that is bugging me.

there is QString.toLatin1() pretty often in the code, but I am not a big fan
of old 8bit encoding done in Latin1, so what kind of encoding should I use
UTF-8?

regards

[Opensync-devel] akonadi-sync phase 2

[deloptes <del...@ya...>]

Hi,

for pity I've found out that the current solution works for contacts very
well, but for the other types and particularly when using more then one it
is producing errors. Especially after rejecting a forecast.

I'm trying to find out why and I thing it is context related, but first of
all I'm not sure where I have to set userdata (
osync_objtype_sink_set_userdata ( sink, this ); ) in the syncbase class or
in the derived classes? Or it doesn't matter. the second question is how it
is supposed to set context info and sink. Can someone with more programming
experience give me a hint. After thinking a lot in he past days I think it
is correct to put it in the base class and not as it is now - in the
derived classes.

the second question is in general about how ctx,info etc are passed to the
subclass - dereferencing. where should it take place? I've added also
sb->setSink(sink); to the WRAP makro and the function in the manner of  the
rest

#define WRAP() \
  osync_trace( TRACE_ENTRY, "%s(%p,%p, %p, %p)", __PRETTY_FUNCTION__, sink,
info, ctx, userdata); \
  SinkBase *sb = reinterpret_cast<SinkBase*>(userdata); \
  sb->setSink(sink);\
  sb->setPluginInfo( info );\
  sb->setContext( ctx );

...

void SinkBase::setSink(OSyncObjTypeSink *sink)
{
    Q_ASSERT( mSink == 0 || sink == mSink );
    mSink = sink;
}

another option would be to move the wrap(sink) call from the derived into
the base class instead setting the mSink, but what is in wrap sink must be
set at init, so may be I'll just leave it. I started looking into barryenv
to see how it is handling the env, but was busy and did not move further.

I'll probably have to upload to svn my current version, but let me know
first if there is a theoretical background. If I solve this I think it will
be almost perfectly working. The other thing I want to implement is (in the
manner of barry sync) using the id or remoteId of an item + revision to do
the checking/finding etc of items. originally the author was using the id,
which made it impossible to correlate by uid ... or was id intended to
be "fake" id in the barry code?

thanks

[Opensync-devel] hash of a change

[deloptes <del...@ya...>]

Do you know if hash = 0 has some special meaning in the hashtable/get change
type?

I keep getting different sets of add/modify changes when saying N to 
Synchronization Forecast Summary

I'm not sure why. Either wrong report/update, not unreffed changes or there
is something I don't understand

regards

Re: [Opensync-devel] Two brakes in libopensync

[Emanoil K. <del...@ya...>]

Hi,

--- On Thu, 10/21/10, Ian Martin <ian...@ca...> wrote:


I imagine kitchensync is being compiled with the -Wundef option

Revision 6150 contains the patch from ticket
http://www.opensync.org/ticket/1263 that fixes this problem

Do people think -Wundef be added to the Hacking build flags?

I'm getting this warning when compiling plugins too, not just kitchensync. I'm using debian sid with whatever default c/c++ version there.

And there is no -Wundef explicitely set in the cmake files, so may be compiler related.

regards



      

Re: [Opensync-devel] Two brakes in libopensync

[Ian M. <ian...@ca...>]

>> > 2. the __sun statement in opensync.h causes frequent troubles:
>> > [ 1%] Building CXX object
>> > libqopensync/CMakeFiles/qopensync.dir/callbackhandler.o
>> > cc1plus: warnings being treated as errors In file included from
>> > /home/murz/temp/2010-09/sync/kitchensync/libqopensync/callbackhandler.cpp
>> > :22: /usr/include/libopensync1/opensync/opensync.h:52: error: "__sun" is
>> > not defined
>> >
>> >
>> > How can we fix this issue? I do it by removing the lines 52-54 in
>> > opensync.h,  but this is only my simple workaround.
>>
>> What compiler do you use?  Maybe very recent versions of gcc are more
>> picky about these kind of if/then/else macro structures.
> I am using gcc 4.5.0. This issue concerns many users out there and it is
> really not a clean and nice solution to tell them to edit the opensync.h file.
>
> What can we do about that? In the worst case scenario I would suggest to
> remove that macro.
>

I imagine kitchensync is being compiled with the -Wundef option

Revision 6150 contains the patch from ticket
http://www.opensync.org/ticket/1263 that fixes this problem

Do people think -Wundef be added to the Hacking build flags?

Ian

Re: [Opensync-devel] Two brakes in libopensync

[Graham C. <g+o...@co...>]

On Thursday 21 October 2010 08:22:21 Quentin Denis wrote:
> Well, as far as I have experienced, even building outside the tree was in
> some case not possible (i.e. cmake ../file-sync). You probably then have
> to set a series of env variables, but IMHO these are exaggerated measures.
> I would suggest to remove this constraint if there is no major
> counter-argument.

I can't comment on whether the restriction is a good thing.  I vaguely 
remember when it was introduced and that whoever did it had what they believed 
to be good reasons but I have no idea what they were.

For your information, I have attached (if this list accepts attachments -- if 
not, drop me an email if you want me to send it) the script that I "source" in 
order to set up the env variables for my development builds.  Note that this 
was derived from someone else's script a long time ago -- apologies that I 
cannot remember who supplied the original.  In my case, I have an "opensync" 
directory which is a parent of the various svn checkout directories for the 
components and is also a parent for the build directory.

I can also send you, if you want, the scripts and rules files I use for the 
builds which create debian packages for Maemo.  They work slightly differently.

Graham

Re: [Opensync-devel] Two brakes in libopensync

[Quentin D. <que...@gm...>]

On Monday 18 October 2010 19:31:15 opensync-devel-
re...@li... wrote:
> Date: Mon, 18 Oct 2010 18:36:45 +0200
> From: Michael Banck <mb...@gm...>
> Subject: Re: [Opensync-devel] Two brakes in libopensync
> To: ope...@li...
> Message-ID:
>         <201...@ni...>
> Content-Type: text/plain; charset=us-ascii
> 
> On Mon, Oct 18, 2010 at 05:45:28PM +0200, Quentin Denis wrote:
> > 1. The cmake macro MacroEnsureOutOfSourceBuild prevents from building
> > the  sources within the source directory. OpenSync is the first source I
> > know that uses this annoying macro. Why? It makes the compilation
> > process just more painful, removing this macro will make things much
> > easier. As far as I have experienced, building outside the source
> > directory has no advantage, so why forcing it?
> 
> For the record, building out of the source tree is usual practise in
> cmake-based projects anyway, though I am not aware of other projects
> enforcing this.  One of the advantages is that you can easily clean up
> your build tree by just removing it.
Well, as far as I have experienced, even building outside the tree was in some 
case not possible (i.e. cmake ../file-sync). You probably then have to set a 
series of env variables, but IMHO these are exaggerated measures. I would 
suggest to remove this constraint if there is no major counter-argument.


> > 2. the __sun statement in opensync.h causes frequent troubles:
> > [ 1%] Building CXX object 
> > libqopensync/CMakeFiles/qopensync.dir/callbackhandler.o
> > cc1plus: warnings being treated as errors In file included from 
> > /home/murz/temp/2010-09/sync/kitchensync/libqopensync/callbackhandler.cpp
> > :22: /usr/include/libopensync1/opensync/opensync.h:52: error: "__sun" is
> > not defined
> > 
> >
> > How can we fix this issue? I do it by removing the lines 52-54 in
> > opensync.h,  but this is only my simple workaround.
> 
> What compiler do you use?  Maybe very recent versions of gcc are more
> picky about these kind of if/then/else macro structures.
I am using gcc 4.5.0. This issue concerns many users out there and it is 
really not a clean and nice solution to tell them to edit the opensync.h file.

What can we do about that? In the worst case scenario I would suggest to 
remove that macro.


-Quentin

[Opensync-devel] akonadi-sync todos

[deloptes <del...@ya...>]

hi, everybody,

the good news. akonadi-sync improved and few fixes were applied, so now
syncing with contacts and events is almost perfect. However I have two
questions:

1) is note vs. contact a reserved word in <ObjType>contact</ObjType>. I
think I remeber I have read that few objtypes are supported ... but where?

I have event/todo/journal as members of calendar and notes as different type
in kde. This is still the same discussion as before. notes are not journal
notes or are they? I'm a bit lost here

2) I'm not sure why I get often errors while working on todo in the xml part
of opensync. I actually managed to sync once or twice todos,  but still
from time to time there are errors as shown below. If some one has
experience it would be highly appreciated to give me advice.
To me it looks like 'AlarmDisplay' is not supported by xsd.

Regards

--------------------------

akonadi_opensync(15906) DataSink::reportChange: Id: 7295
akonadi_opensync(15906) DataSink::reportChange:
RemoteId: "libkcal-533583710.225"
akonadi_opensync(15906) DataSink::reportChange:
Mime: "application/x-vnd.akonadi.calendar.todo"
akonadi_opensync(15906) DataSink::reportChange: Revision: 0
akonadi_opensync(15906) DataSink::reportChange: StorageCollectionId: 22
akonadi_opensync(15906) DataSink::reportChange: Url:
KUrl("akonadi:?item=7295")
akonadi_opensync(15906) DataSink::reportChange: item.payloadData().data()
 BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 3.2//EN
VERSION:2.0
BEGIN:VTODO
DTSTAMP:20101020T204624Z
ORGANIZER;CN="Deloptes":MAILTO:developer@lisa
CREATED:20101019T235801Z
UID:libkcal-533583710.225
LAST-MODIFIED:20101019T235801Z
DESCRIPTION:asdfasdf
SUMMARY:asdfasd
LOCATION:asdfasdf
PRIORITY:5
DUE;VALUE=DATE:20101027
PERCENT-COMPLETE:0
END:VTODO

END:VCALENDAR
akonadi_opensync(15906) DataSink::slotItemsReceived: slotItemsReceived done
akonadi_opensync(15906) DataSink::slotGetChangesFinished:
akonadi_opensync(15906) SinkBase::success:
akonadi_opensync(15906) DataSink::slotGetChangesFinished: got all changes
success().
Received an entry libkcal-1127466685.636 (xmlformat-todo) from member 2
(akonadi-sync). Changetype ADDED
element AlarmDisplay: Schemas validity error : Element 'AlarmDisplay': This
element is not expected. Expected is one of ( Alarm, Attach, Attendee,
CalendarScale, Categories, Class, Comment, Completed, Contact, Created ).
ERROR: XMLFormat validation failed.
EXIT_ERROR: osync_converter_invoke: XMLFormat validation failed.
EXIT_ERROR: osync_format_env_convert: XMLFormat validation failed.
Main sink of member 2 of type akonadi-sync had an error: XMLFormat
validation failed.
EXIT_ERROR: _osync_engine_receive_change: XMLFormat validation failed.
Received an entry libkcal-533583710.225 (xmlformat-todo) from member 2
(akonadi-sync). Changetype ADDED
todo sink of member 2 of type akonadi-sync just sent all changes
Main sink of member 2 of type akonadi-sync just sent all changes
akonadi_opensync(15912) DataSink::slotItemsReceived:
akonadi_opensync(15912) DataSink::slotItemsReceived: retrieved 9 items

--------------------------


[1287607172.329244]                                                                    
>>>>>>>  osync_xmlfield_sort(0x7f60dc007ab0)
[1287607172.329262]                                                                    
<<<<<<<  osync_xmlfield_sort
[1287607172.329275]                                                                    
Attribute: "END", Component:"VTODOEND:VCALENDAR"
[1287607172.329287]                                                            
<<<<<<<  vcalendar_parse_attributes: Done
[1287607172.329304]                                                            
>>>>>>>  osync_xmlformat_sort(0x7f60dc000ee0)
[1287607172.329321]                                                            
<<<<<<<  osync_xmlformat_sort
[1287607172.329363]                                                            
[SENSITIVE CONTENT HIDDEN]
[1287607172.329384]                                                    
<<<<<<<  conv_vcalendar_to_xmlformat: TRUE
[1287607172.329399]                                             <<<<<<< 
Converter function. output_size: 56, output_data: 0x7f60dc000ee0
[1287607172.329412]                                             >>>>>>> 
validate_xmlformat(0x7f60dc000ee0, 56, 0x2231e30, 0x7f60e2aabc30)
[1287607172.329472]                                             ERROR:
XMLFormat validation failed.
[1287607172.329489]                                             <<<<<<< 
validate_xmlformat: FALSE
[1287607172.329501]                                     <--- ERROR ---
osync_converter_invoke: XMLFormat validation failed.
[1287607172.329520]                             <--- ERROR ---
osync_format_env_convert: XMLFormat validation failed.
[1287607172.329537]                             >>>>>>> 
osync_status_update_member(0x213bea0, 0x1fb6650, 3, (null), 0x7f60dc007a60)
[1287607172.329551]                                     >>>>>>> 
member_status(0x7f60dc005f90, (nil))
[1287607172.329570]                                     <<<<<<< 
member_status
[1287607172.329583]                             <<<<<<< 
osync_status_update_member
[1287607172.329595]                     <--- ERROR ---
_osync_engine_receive_change: XMLFormat validation failed.
[1287607172.329611]             <<<<<<<  _osync_client_proxy_message_handler
[1287607172.329625]     <<<<<<<  _incoming_dispatch: Done dispatching
[1287607172.329881]     >>>>>>>  _incoming_dispatch(0x2303a00)

Re: [Opensync-devel] Two brakes in libopensync

[Emanoil K. <del...@ya...>]

--- On Mon, 10/18/10, Michael Banck <mb...@gm...> wrote:

>  
> > 2. the __sun statement in opensync.h causes frequent
> troubles:
> > [ 1%] Building CXX object 
> >
> libqopensync/CMakeFiles/qopensync.dir/callbackhandler.o
> > cc1plus: warnings being treated as errors In file
> included from 
> >
> /home/murz/temp/2010-09/sync/kitchensync/libqopensync/callbackhandler.cpp:22:
> > /usr/include/libopensync1/opensync/opensync.h:52:
> error: "__sun" is not 
> > defined
> > 
> > How can we fix this issue? I do it by removing the
> lines 52-54 in opensync.h, 
> > but this is only my simple workaround.
> 
> What compiler do you use?  Maybe very recent versions
> of gcc are more
> picky about these kind of if/then/else macro structures.
> 
> 

Actually the compiler I'm using is gcc-4.4 (g++ resp.) from debian sid and I'm getting the same warning on compile

For the modules not found issue I setup the CMAKE modules path (see the docs)

regards

regards


      

Re: [Opensync-devel] Two brakes in libopensync

[Michael B. <mb...@gm...>]

On Mon, Oct 18, 2010 at 05:45:28PM +0200, Quentin Denis wrote:
> 1. The cmake macro MacroEnsureOutOfSourceBuild prevents from building the 
> sources within the source directory. OpenSync is the first source I know that 
> uses this annoying macro. Why? It makes the compilation process just more 
> painful, removing this macro will make things much easier. As far as I have 
> experienced, building outside the source directory has no advantage, so why 
> forcing it?

For the record, building out of the source tree is usual practise in
cmake-based projects anyway, though I am not aware of other projects
enforcing this.  One of the advantages is that you can easily clean up
your build tree by just removing it.
 
> 2. the __sun statement in opensync.h causes frequent troubles:
> [ 1%] Building CXX object 
> libqopensync/CMakeFiles/qopensync.dir/callbackhandler.o
> cc1plus: warnings being treated as errors In file included from 
> /home/murz/temp/2010-09/sync/kitchensync/libqopensync/callbackhandler.cpp:22:
> /usr/include/libopensync1/opensync/opensync.h:52: error: "__sun" is not 
> defined
> 
> How can we fix this issue? I do it by removing the lines 52-54 in opensync.h, 
> but this is only my simple workaround.

What compiler do you use?  Maybe very recent versions of gcc are more
picky about these kind of if/then/else macro structures.


Michael

[Opensync-devel] Two brakes in libopensync

[Quentin D. <que...@gm...>]

Hi guys,

I would like to discuss two issues that brake any compilation that depends on 
the opensync libs:


1. The cmake macro MacroEnsureOutOfSourceBuild prevents from building the 
sources within the source directory. OpenSync is the first source I know that 
uses this annoying macro. Why? It makes the compilation process just more 
painful, removing this macro will make things much easier. As far as I have 
experienced, building outside the source directory has no advantage, so why 
forcing it?

I removed the following lines in 
/usr/share/libopensync1/cmake/modules/OpenSyncInternal.cmake to get rid of 
that macro:

INCLUDE( MacroEnsureOutOfSourceBuild )
MACRO_ENSURE_OUT_OF_SOURCE_BUILD("${CMAKE_PROJECT_NAME} doesn't allow to build 
within the source directory. Please, create a seperate build directory and run 
'cmake ${PROJECT_SOURCE_DIR} [options]'!")

Could we remove them from the sources? What is your opinion?


2. the __sun statement in opensync.h causes frequent troubles:
[ 1%] Building CXX object 
libqopensync/CMakeFiles/qopensync.dir/callbackhandler.o
cc1plus: warnings being treated as errors In file included from 
/home/murz/temp/2010-09/sync/kitchensync/libqopensync/callbackhandler.cpp:22:
/usr/include/libopensync1/opensync/opensync.h:52: error: "__sun" is not 
defined

How can we fix this issue? I do it by removing the lines 52-54 in opensync.h, 
but this is only my simple workaround.


Kind regards,
Quentin

PS: I created an official page for kitchensync in kde-apps.org: http://kde-
apps.org/content/show.php/KitchenSync?content=132538 . The GUI works quite 
well now, there is only that small annoying bug with the member class. We are 
trying to figure out how to fix it, help is welcome! ;)

Re: [Opensync-devel] snycml plugin

[deloptes <del...@ya...>]

Tino Keitel wrote:

> if (strstr(name, "21") != NULL)

you are right, this is much better.

regards

Re: [Opensync-devel] snycml plugin

[Tino K. <tin...@ti...>]

On Sat, Oct 16, 2010 at 10:31:01 +0200, deloptes wrote:
> To avoid this warning
> 
> opensync/libopensync-plugin-syncml/trunk/src/syncml_devinf.c: In
> function ‘get_database_pref_content_type’:
> opensync/libopensync-plugin-syncml/trunk/src/syncml_devinf.c:17: warning:
> ordered comparison of pointer with integer zero
> opensync/libopensync-plugin-syncml/trunk/src/syncml_devinf.c:23: warning:
> ordered comparison of pointer with integer zero
> 
> I've changed this
> 
>         if (strstr(name, "21") > 0)

[...]

> to
> 
>         if (sizeof(strstr(name, "21")) > 0)

This looks strange, if not broken. Why not consider the possible return
values of strstr() and do it like this?

if (strstr(name, "21") != NULL)

Regards,
Tino

[Opensync-devel] GPE plugin updated

[Graham C. <g+o...@co...>]

FYI, I have updated (r6147) the GPE plugin to the latest API -- it seems to 
basically work although I haven't done exhaustive tests.

However, the capabilities stuff is completely broken -- the format of the 
capabilities file is completely different.  Anyone got a working capabilities 
file I could use as an example?

Graham

[Opensync-devel] snycml plugin

[deloptes <del...@ya...>]

To avoid this warning

opensync/libopensync-plugin-syncml/trunk/src/syncml_devinf.c: In
function ‘get_database_pref_content_type’:
opensync/libopensync-plugin-syncml/trunk/src/syncml_devinf.c:17: warning:
ordered comparison of pointer with integer zero
opensync/libopensync-plugin-syncml/trunk/src/syncml_devinf.c:23: warning:
ordered comparison of pointer with integer zero

I've changed this

        if (strstr(name, "21") > 0)
            ct = SML_ELEMENT_TEXT_VCARD;
        else
            ct = SML_ELEMENT_TEXT_VCARD_30;
    } else if (!strcmp(objtype, "event") ||
               !strcmp(objtype, "todo")) {
        if (strstr(name, "10") > 0)
            ct = SML_ELEMENT_TEXT_VCAL;
        else
            ct = SML_ELEMENT_TEXT_ICAL;

to

        if (sizeof(strstr(name, "21")) > 0)
            ct = SML_ELEMENT_TEXT_VCARD;
        else
            ct = SML_ELEMENT_TEXT_VCARD_30;
    } else if (!strcmp(objtype, "event") ||
               !strcmp(objtype, "todo")) {
        if (sizeof(strstr(name, "10")) > 0)
            ct = SML_ELEMENT_TEXT_VCAL;
        else
            ct = SML_ELEMENT_TEXT_ICAL;

regards

Re: [Opensync-devel] possible issues in libwbxml

[Emanoil K. <del...@ya...>]

Thanks. I hope what I'm doing helps improve.

regards


      

Re: [Opensync-devel] syncml-ds-tool

[deloptes <del...@ya...>]

Chris Frey wrote:

> If the stack trace doesn't include function names, then you'll need to
> recompile the libraries with debug info enabled (gcc's -g flag).

Last question - how do I do this in cmake

everything I've tried shows no debug symbols in gdb

the new thing this time was this message

warning: Can't read pathname for load map: Input-/Outputerror.

but it is just a warning

thanks in advance

Re: [Opensync-devel] possible issues in libwbxml

[Michael B. <mic...@cm...>]

On 10/13/10 20:25, deloptes wrote:
> 
> After enabling debug and warnings at compile time I get warnings which might
> lead to issues in libwbxml
> 
> developer@lisa:~/opensync/libwbxml/trunk/build$ make && make install
> Scanning dependencies of target wbxml2
> [  5%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_base64.o
> [ 11%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_buffers.o
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_buffers.c: In
> function ‘wbxml_buffer_get_char’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_buffers.c:170: warning:
> comparison of unsigned expression < 0 is always false

Fixed by removing the comparison.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_buffers.c: In
> function ‘wbxml_buffer_strip_blanks’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_buffers.c:363: warning:
> comparison of unsigned expression >= 0 is always true

Fixed by removing the line.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_buffers.c: In
> function ‘grow_buff’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_buffers.c:709: warning:
> comparison of unsigned expression < 0 is always false

Fixed by removing the condition.

All bugs in wbxml_buffers had no effect.

> [ 16%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_charset.o
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_charset.c: In
> function ‘binary_search’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_charset.c:317: warning: unused
> parameter ‘in_buf’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_charset.c:318: warning: unused
> parameter ‘in_buf_len’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_charset.c:319: warning: unused
> parameter ‘in_seq’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_charset.c:320: warning: unused
> parameter ‘in_seq_len’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_charset.c:321: warning: unused
> parameter ‘out_pos’

The function binary_search is not implemented yet. Therefore you get a
warning on the unused parameters.

> [ 22%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_conv.o
> [ 27%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_elt.o
> [ 33%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_encoder.o
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c: In
> function ‘wbxml_encoder_set_flow_mode’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c:623: warning: unused
> parameter ‘flow_mode’

The parameter was simply ignored by the code. This is a real bug. Fixed.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c: In
> function ‘parse_cdata’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c:1346: warning: unused
> parameter ‘node’

I created ticket #43.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c: In
> function ‘parse_pi’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c:1381: warning: unused
> parameter ‘encoder’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c:1381: warning: unused
> parameter ‘node’

The function is not implemented yet.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c: In
> function ‘wbxml_encode_wv_integer’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_encoder.c:3038: warning:
> comparison of unsigned expression >= 0 is always true

Fixed by using a signed integer.

> [ 38%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_errors.o
> [ 44%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_lists.o
> [ 50%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_log.o
> [ 55%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_mem.o
> [ 61%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_parser.o
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_parser.c: In
> function ‘wbxml_parser_parse’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_parser.c:246: warning: suggest
> braces around empty body in an ‘if’ statement

Fixed.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_parser.c: In
> function ‘check_public_id’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_parser.c:564: warning:
> comparison between signed and unsigned integer expressions

I created ticket #44 to track the issue.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_parser.c: In
> function ‘parse_switch_page’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_parser.c:1096: warning: suggest
> braces around empty body in an ‘if’ statement

Fixed.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_parser.c: In
> function ‘parse_opaque’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_parser.c:1748: warning: suggest
> braces around empty body in an ‘if’ statement

Fixed.

> [ 66%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_tables.o
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tables.c: In
> function ‘wbxml_tables_get_wbxml_publicid’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tables.c:3434: warning:
> comparison between signed and unsigned integer expressions

I created ticket #45 to track the issue.

> [ 72%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_tree.o
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree.c: In
> function ‘wbxml_tree_node_elt_get_from_name’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree.c:752: warning: unused
> parameter ‘recurs’

I created ticket #46 to track the issue.

> [ 77%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_tree_clb_wbxml.o
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c: In
> function ‘wbxml_tree_clb_wbxml_start_element’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c:63: warning:
> unused parameter ‘empty’

I created ticket #47 to track the issue.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c: In
> function ‘wbxml_tree_clb_wbxml_end_element’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c:81: warning:
> unused parameter ‘element’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c:81: warning:
> unused parameter ‘empty’

This is part of ticket #47.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c: In
> function ‘wbxml_tree_clb_wbxml_pi’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c:217: warning:
> unused parameter ‘ctx’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c:217: warning:
> unused parameter ‘target’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_wbxml.c:217: warning:
> unused parameter ‘data’

This function is not implemented yet.

> [ 83%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_tree_clb_xml.o
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_xml.c: In
> function ‘wbxml_tree_clb_xml_decl’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_xml.c:49: warning:
> unused parameter ‘standalone’

I created ticket #48 to track the issue.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_xml.c: In
> function ‘wbxml_tree_clb_xml_doctype_decl’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_xml.c:73: warning:
> unused parameter ‘doctypeName’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_xml.c:76: warning:
> unused parameter ‘has_internal_subset’

I created ticket #49 to track the issue.

> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_xml.c: In
> function ‘wbxml_tree_clb_xml_pi’:
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_xml.c:532: warning:
> unused parameter ‘target’
> /home/yoki/opensync/libwbxml/trunk/src/wbxml_tree_clb_xml.c:533: warning:
> unused parameter ‘data’

The function is not implemented yet (PI is widely ignored today).

I will check the newly created tickets over the next days.

Best regards

Michael
-- 
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 70143          ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704           Unter den Linden 6
mic...@cm...       D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C  C643 D8BD 1918 2030 5AAB

Re: [Opensync-devel] syncml-ds-tool

[Chris F. <cd...@fo...>]

On Wed, Oct 13, 2010 at 03:18:16AM -0700, Emanoil Kotsev wrote:
> Thanks Daniel
> 
> --- On Wed, 10/13/10, Daniel Gollub <go...@b1...> wrote:
> 
> > From: Daniel Gollub <go...@b1...>
> > ? ? ? ? ? ? ? ? 
> > 
> > Could you send the full backtrace?
> > 
> > Run: bt .. in gdb commandline.
> > 
> > And make sure libsyncml and syncml-ds-tool are build with
> > debuginfo - gcc flag 
> > -g ...
> > 
> 
> I'm not sure I've understood exactly what you mean (or what I am
> supposed to do). I don't have that much experience or knowledge of the
> devs language.

There was a segfault reported in the original email, so he's asking
for a gdb debugger stack trace. :-)

	ulimit -c unlimited
	<run program that crashes>
	gdb /some/program core
	> bt

If the stack trace doesn't include function names, then you'll need to
recompile the libraries with debug info enabled (gcc's -g flag).

- Chris

Re: [Opensync-devel] syncml-ds-tool

[deloptes <del...@ya...>]

Michael Banck wrote:

> On Wed, Oct 13, 2010 at 10:01:15PM +0200, deloptes wrote:
>> EXIT_ERROR: _recv_event: Forbidden (0x43)
> 
> As far as I know, Forbidden (0x43) is a rather generic error message.

thanks

> 
> Try changing the version of syncml (e.g. 1.1 vs. 1.2) you request, if
> it's a Nokia mobile, try adding "PC Suite" (or whatever the name was) as
> identifier, and possibly try to turn on/off wbxml.

I did the  version change ... to match the one on the phone syncml-ds-tool
started but broke in the middle.
May be I have to apply your next suggestion

> 
> I think there is a wiki page on libsyncml.opensnyc.org somewhere which
> discusses this.
> 

Where - the one that explains how to configure the svn plugin?

Are you using USB or Bluetooth? and
Why there is only "Bluetooth/Internet" in the Sync configure menu.

Are there docs on it?

Thanks

Re: [Opensync-devel] syncml-ds-tool

[Michael B. <mb...@gm...>]

On Wed, Oct 13, 2010 at 10:01:15PM +0200, deloptes wrote:
> EXIT_ERROR: _recv_event: Forbidden (0x43)

As far as I know, Forbidden (0x43) is a rather generic error message.

Try changing the version of syncml (e.g. 1.1 vs. 1.2) you request, if
it's a Nokia mobile, try adding "PC Suite" (or whatever the name was) as
identifier, and possibly try to turn on/off wbxml.

I think there is a wiki page on libsyncml.opensnyc.org somewhere which
discusses this.


Michael