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

Re: [Opensync-devel] evolution plugin (not reporting deletes)

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

Nicolas wrote:

> Linked to bug :
> 
> https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/658459
> 
> Regards,
> 

Is it evolution problem or not?

regards

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

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

It seems usb is working better

 syncml-ds-tool -u
Superuser privileges are required to access complete USB information.
Found 2 USB OBEX interfaces
Interface 0:
        Manufacturer: Nokia
        Product: Nokia 5530 XpressMusic
        Interface description: SYNCML-SYNC
Interface 1:
        Manufacturer: Nokia
        Product: Nokia 5530 XpressMusic
        Interface description: PC Suite Service

--discover works well

but sync does not 

Main sink of member 2 of type akonadi-sync just connected
contact sink of member 2 of type akonadi-sync just connected
Main sink of member 1 of type syncml-obex-client just connected
ERROR: Forbidden (0x43)
EXIT_ERROR: _recv_event: Forbidden (0x43)
ERROR: Forbidden (0x43)
contact sink of member 1 of type syncml-obex-client had an error: Forbidden
(0x43)

further testing syncml-ds-tool with gdb I see

Reading symbols from /opt/testing/opensync/bin/syncml-ds-tool...(no
debugging symbols found)...done.
(gdb) r -u
Starting program: /opt/testing/opensync/bin/syncml-ds-tool -u
[Thread debugging using libthread_db enabled]
Superuser privileges are required to access complete USB information.
Found 2 USB OBEX interfaces
Interface 0:
        Manufacturer: Nokia
        Product: Nokia 5530 XpressMusic
        Interface description: SYNCML-SYNC
Interface 1:
        Manufacturer: Nokia
        Product: Nokia 5530 XpressMusic
        Interface description: PC Suite Services
Use '-u interface_number' to connect
** Message: syncml-ds-tool failed.

Program exited with code 01.
(gdb) r -u 0
Starting program: /opt/testing/opensync/bin/syncml-ds-tool -u 0
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5e29d8a in _IO_vfprintf_internal (s=0x7fffffffde40, format=<value
optimized out>, ap=0x7fffffffdff0) at vfprintf.c:1614
1614    vfprintf.c: Datei oder Verzeichnis nicht gefunden.
        in vfprintf.c


I then configured the phone properly (I believe)

and got some meaningful output though the tool failed again

however if I try osynctool with --sync I get

ERROR: Forbidden (0x43)
EXIT_ERROR: _recv_event: Forbidden (0x43)
ERROR: Forbidden (0x43)
contact sink of member 1 of type syncml-obex-client had an error: Forbidden
(0x43)
ERROR: At least one sink_engine failed while connecting
ERROR: No objtypes left without error. Aborting
ERROR: No objtypes left without error. Aborting


What can be this?

Anyway I've got tired for today, please give me some meaningful feedback.

Thanks and regards

Re: [Opensync-devel] evolution plugin (not reporting deletes)

[Nicolas <pr...@fr...>]

Linked to bug : 

https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/658459

Regards,

Le mercredi 06 octobre 2010 à 21:14 +0200, deloptes a écrit :
> it seems that the evolution plugin is not working (not reporting deletes or
> modifications)
> 
> what can be wrong
> 
> I wanted to use it for testing but it seems to not be possible, then I tried
> it with the file sync, but it also does not work
> 
> regards
> 
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
> 

[Opensync-devel] possible issues in libwbxml

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

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
/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
/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
[ 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’
[ 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’
/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’
/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’
/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
[ 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
/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
/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
/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
[ 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
[ 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’
[ 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’
/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’
/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’
[ 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’
/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’
/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’
[ 88%] Building C object src/CMakeFiles/wbxml2.dir/wbxml_wrap_syncml.o
Linking C shared library libwbxml2.so
[ 88%] Built target wbxml2
Scanning dependencies of target wbxml2xml
[ 94%] Building C object tools/CMakeFiles/wbxml2xml.dir/wbxml2xml_tool.o
Linking C executable wbxml2xml
[ 94%] Built target wbxml2xml
Scanning dependencies of target xml2wbxml
[100%] Building C object tools/CMakeFiles/xml2wbxml.dir/xml2wbxml_tool.o
Linking C executable xml2wbxml
[100%] Built target xml2wbxml
[ 88%] Built target wbxml2
[ 94%] Built target wbxml2xml
[100%] Built target xml2wbxml

[Opensync-devel] vnote11 reported unexpected

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

Another question for you that we may discuss until the weekend.

As I mentioned I'm using evo2-sync as a pair for testing akonadi-sync and I've noticed that evo2-sync is reporting notes in vnote11 format and not journal (which is breaking the sync as akonadi-sync expects vjournal), which makes me think it is picking up the first available format from the opposite member. It is either the plugin or (what I think) the libopensync itself, selecting the first available path for the "note" sync. How can I tell opensync (from akonadi POV) I can and I want vjournal. I've tried setting preferred format in discover but it does not help much. The odd thing is that evolution does not report vnote11 as supported at all.

Do I need to file bugs ... in normal life I would.

here a portion to give you an idea

akonadi_opensync(29750) DataSink::commit: change uid: "20100910T224808Z-11504-1010-1-0@lisa"
akonadi_opensync(29750) DataSink::commit: objform: vnote11
akonadi_opensync(29750) DataSink::commit:
akonadi_opensync(29750) DataSink::commit: data "BEGIN:VNOTE
VERSION:1.1
CATEGORIES:first
CREATED:20100910T224808Z
LAST-MODIFIED:20100910T224808Z
SUMMARY:asdfasdf
UID:20100910T224808Z-11504-1010-1-0@lisa
END:VNOTE
"
akonadi_opensync(29750) DataSink::collection:
akonadi_opensync(29750) DataSink::setPayload:
akonadi_opensync(29750) DataSink::setPayload: notes
ERROR: Broken Pipe
ERROR: Broken Pipe
ERROR: Broken Pipe
ERROR: Trying to send to a queue thats not connected
ERROR: Broken Pipe

OK! Completing synchronization!
ERROR: Broken Pipe
ERROR: Broken Pipe
ERROR: Broken Pipe
Error for entry 20100910T224808Z-11504-1010-1-0@lisa (vnote11) and member 2 (akonadi-sync): Broken Pipe
Mapping Error: Broken Pipe
EXIT_ERROR: osync_obj_engine_commit_change_callback: Broken Pipe

and this data is coming from evo2. and evo2 is reporting vjournal.
Hm ... from the way I see how evolution works I don't think I'll upgrade my current debian system soon.
Perhaps it would be better to get the syncing with kde3 done for now.
However I would like to work on this plugin to get it stable until I move to kde4.

I'm also not sure if I have to try fixing evo2-sync the way I think it should work and proposing a patch. It would be very nice if someone knowing evo api gets involved.

regards

--- On Wed, 10/13/10, Daniel Gollub <go...@b1...> wrote:

> From: Daniel Gollub <go...@b1...>
> Subject: Re: [Opensync-devel] syncml-ds-tool
> To: ope...@li..., del...@ya...
> Date: Wednesday, October 13, 2010, 1:41 AM
> On Wednesday, October 13, 2010
> 08:59:11 am deloptes wrote:
> > developer@lisa:~/kde-testdir$ gdb syncml-ds-tool
> > GNU gdb (GDB) 7.2-debian
> > Copyright (C) 2010 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html>
> > ...
> > Starting program:
> /opt/testing/opensync/bin/syncml-ds-tool -b
> > xx:xx:xx:xx:xx:xx 7
> > [Thread debugging using libthread_db enabled]
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00007ffff5e23d8a in _IO_vfprintf_internal
> (s=0x7fffffffddc0,
> > format=<value optimized out>,
> ap=0x7fffffffdf70)
> >     at vfprintf.c:1614
> > 1614    vfprintf.c: No such file or
> directory.
> >         in vfprintf.c
> > (gdb)             
>                 
> 
> 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 ...
> 
> Best Regards,
> Daniel
> 
> -- 
> Daniel Gollub           
>             Geschaeftsfuehrer:
> Ralph Dehner
> Linux Consultant & Developer     
>    Unternehmenssitz:  Vohburg
> B1 Systems GmbH           
>           Amtsgericht:   
>    Ingolstadt
> Mobil: +49-(0)-160 47 73 970     
>    Handelsregister:   HRB
> 3537
> EMail: go...@b1... 
>         http://www.b1-systems.de
> 
> Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088
> Vohburg
> http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D
> 


      

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

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

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.

I'm wondering if it is not better to wait until the weekend as then I'll be able to reboot the server and check again (I've installed some updates that affected glibc, but I couldn't reboot). I've also installed the latest kernel 2.26.35.7. I want to see if it will behave the same when everything is fresh.
Let me know if you think it is relevant.
I've also observed messages in dmesg when osplugin fails (I think it is comming from the threads)

Last but not least - I don't know how to make my mortal user talk to the BT device - it lacks privileges, or something else.

Can someone share config and experience with me please?!

regards


      

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

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

On Wednesday, October 13, 2010 08:59:11 am deloptes wrote:
> developer@lisa:~/kde-testdir$ gdb syncml-ds-tool
> GNU gdb (GDB) 7.2-debian
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> ...
> Starting program: /opt/testing/opensync/bin/syncml-ds-tool -b
> xx:xx:xx:xx:xx:xx 7
> [Thread debugging using libthread_db enabled]
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff5e23d8a in _IO_vfprintf_internal (s=0x7fffffffddc0,
> format=<value optimized out>, ap=0x7fffffffdf70)
>     at vfprintf.c:1614
> 1614    vfprintf.c: No such file or directory.
>         in vfprintf.c
> (gdb)                              

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 ...

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
Linux Consultant & Developer         Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

[Opensync-devel] syncml-ds-tool

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

I'm not sure about this message

do you have any idea

developer@lisa:~/kde-testdir$ gdb syncml-ds-tool
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
...
Starting program: /opt/testing/opensync/bin/syncml-ds-tool -b
xx:xx:xx:xx:xx:xx 7
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5e23d8a in _IO_vfprintf_internal (s=0x7fffffffddc0, format=<value
optimized out>, ap=0x7fffffffdf70)
    at vfprintf.c:1614
1614    vfprintf.c: No such file or directory.
        in vfprintf.c
(gdb)                              

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

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

Emanoil Kotsev wrote:

> Hi, opensync masters,
> 
> I'm wondering if someone is following the user group as there is no much
> activity.

Thanks for the responses.

Now, it seems dbus was involved in my problems. When I started trying to
configure bluetooth I noticed that it gave a message in syslog "Unable to
get on D-Bus". I needed to restart udev and dbus and had a successfull sync
(at least in theory). I think this is due to the fact that I'm running this
on a server that does not reboot with ssh -X and somehow dbus is not happy
with it. However here is the success message.

regards

OK! Completing synchronization!
contact sink of member 2 of type akonadi-sync committed all changes.
event sink of member 2 of type akonadi-sync committed all changes.
contact sink of member 1 of type evo2-sync committed all changes.
Sent an entry libkcal-1785285018.544 (vevent20) to member 1 (evo2-sync).
Changetype MODIFIED
Sent an entry libkcal-2095366325.846 (vevent20) to member 1 (evo2-sync).
Changetype MODIFIED
event sink of member 1 of type evo2-sync committed all changes.
Main sink of member 1 of type evo2-sync committed all changes.
Main sink of member 2 of type akonadi-sync committed all changes.
All clients have written
akonadi_opensync(16687) DataSink::syncDone: sync for sink member done
akonadi_opensync(16687) SinkBase::success:
contact sink of member 2 of type akonadi-sync reported sync done.
contact sink of member 1 of type evo2-sync reported sync done.
akonadi_opensync(16687) DataSink::syncDone: sync for sink member done
akonadi_opensync(16687) SinkBase::success:
event sink of member 2 of type akonadi-sync reported sync done.
event sink of member 1 of type evo2-sync reported sync done.
Main sink of member 1 of type evo2-sync reported sync done.
Main sink of member 2 of type akonadi-sync reported sync done.
All clients reported sync done
The sync was successful
contact sink of member 2 of type akonadi-sync just disconnected
event sink of member 2 of type akonadi-sync just disconnected
Main sink of member 2 of type akonadi-sync just disconnected
contact sink of member 1 of type evo2-sync just disconnected
event sink of member 1 of type evo2-sync just disconnected
Main sink of member 1 of type evo2-sync just disconnected
All clients have disconnected
akonadi_opensync(16687) akonadi_finalize:

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

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

Hi,

--- On Mon, 10/11/10, Chris Frey <cd...@fo...> wrote:

> From: Chris Frey <cd...@fo...>
> 
> I do, I've just been busy and have to catchup.

good to hear
 
> 
> > I'm also wondering if someone could fix the evolution
> plugin because I can not use it for testing the
> akonadi-plugin, or can you give me some idea on how to setup
> a testing env for Calendar.
> 
> Today is Canadian Thanksgiving, so it won't be today. 
> But I use the
> evolution plugin regularly, and am interested in fixing
> bugs in it.
> 

Ok, ok greetings. I'm not that much in a hurry. 

regards


      

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

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

On Mon, Oct 11, 2010 at 06:22:50AM -0700, Emanoil Kotsev wrote:
> I'm wondering if someone is following the user group as there is no much activity.

I do, I've just been busy and have to catchup.


> I'm also wondering if someone could fix the evolution plugin because I can not use it for testing the akonadi-plugin, or can you give me some idea on how to setup a testing env for Calendar.

Today is Canadian Thanksgiving, so it won't be today.  But I use the
evolution plugin regularly, and am interested in fixing bugs in it.

- Chris

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

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

Hi, opensync masters,

I'm wondering if someone is following the user group as there is no much activity.

I'm also wondering if someone could fix the evolution plugin because I can not use it for testing the akonadi-plugin, or can you give me some idea on how to setup a testing env for Calendar.

I think my testing env with evolution got dirty and I have miserable results, so I setup an environment in a vmware and there it works almost fine (without enabling notes and todos)

I need a testing plan too. Do you have something at hand or already done.

regards 


      

Re: [Opensync-devel] akonadi-sync (discussion)

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

--- On Tue, 10/5/10, deloptes <del...@ya...> wrote:

> > Does translation between Evolution vCard flavor
> (X-EVOLUTION-*
> > extensions) and KDE flavor (X-something, don't have it
> at hand) work?
> > 
> 
> I think it worked for the few items I've prepared for
> testing.

The problem is in evo2-sync not using the correct UID to manage the entries. I filed a bug, but I'm not sure if I reported it here

regards


      

Re: [Opensync-devel] akonadi-sync (discussion)

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

deloptes wrote:

> I had a closer look into the discover funtion and I think it can do much
> more then mapping event obj and contact.

So I took advantage to add support for multiple collection.

The thing is that I have to run --discover after each --configure and I am
not sure if it is intended to work like this.

I think the discover should check if the engine supports the formats at the
opposite end, which I want to implement next, to avoid the second run of
discover.

The action plan for the sync is for what I believe that is rational and
pragmatic as following:

 1. --configure (optional, ATM mandatory)
 2. --discover  (mandatory)
 3. --configure (enable disable ressources)
 4. -- sync

So this is my goal, next

A. check for ressources and report syncs only if format is supported by the
other member(s) in the discover phase
B. Work the event/note/todo sync out
C. Check why todo is reporting XML validation error.

My question is why this is causing a problem in the sync

BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:1.0
BEGIN:VTODO
DUE:20101201T000000
DCREATED:20100917T231809Z
UID:libkcal-1407423793.37
SEQUENCE:5
LAST-MODIFIED:20101010T215459Z
X-ORGANIZER:MAILTO:developer@lisa
SUMMARY:Finish the pluging
STATUS:NEEDS_ACTION
PRIORITY:5
END:VTODO

END:VCALENDAR

anyway, I'll look forward to understand how calendars are to be handled

regards

Re: [Opensync-devel] Updating debian unstable

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

Michael Banck wrote:

> Hi,
> 
> On Wed, Sep 15, 2010 at 03:36:03AM -0400, Chris Frey wrote:
>> On Wed, Sep 15, 2010 at 09:22:28AM +0200, Michael Banck wrote:
>> > It is not out of date, it is the currently released development
>> > release,
>> > as far as I know.  Also 0.22, is still in the stable release, it is not
>> > gone from Debian entirely, just from testing/unstable. (There was talk
>> > about reviving 0.22 just for the python plugins, which apparently seem
>> > to work well for some people still, but I did not get around it so far,
>> > and with the freeze in effect I doubt it is doable)
>> 
>> If 0.22 could return to Squeeze, that would be great.  Let me know
>> how I can help, because that would make my life easier.
> 
> I have now made the case of reverting to 0.22 to the Debian release
> team, let's see whether they accept this.  I believe those are the
> main issues currently:
> 
> 1. The syncml plugin 0.22 version is not ported to libsyncml-0.5.4.  So
> unless somebody ports it, it will have to be dropped.

I am heavy debian user and I know they will have somewhere backported apps
in repository for installation, so I don't think it is really an issue.

To be honest if you miss a train you probably get late for where you are
going, so I think opensync missed the train for the next debian stable
already. Nevertheless I personally want to be finally able to sync my
desktop somewhen in the future, so I would put some time into makeing it
possible for at least the future stable and testing. If we have 0.40 in
next testing what is now sid, I hope more people would use it and report
problems.

I don't see issues with the engine itself, but rather as someone mentioned
in the known formats and in the plugins. I'm not sure which version was
referred but from what I've seen until now it is working pretty well at
least for the contacts in kde 4.5/6. 

> 
> 2. The google-calendar plugin crashes if changes have been made in the
> other member.  This is ticket #750, which maybe only applies to a
> google-calendar plugin ported to 4suite XML (Debian and Ubuntu have
> dropped python-xml, so it had to be ported).  I found out that earlier
> versions (0.x) of 4suite worked fine, see my analysis here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468601#25
> But I guess this will have to be fixed on the google-calendar side.  The
> 4suite port is also in that bug report to look at.
> 
> 3. I had issues with the evolution plugin where changes made in its
> addressbook were not reported to the engine.  I have not investigated
> this in detail.

I opened a bug for this, because I wanted to use it for testing the
akonadi-plugin. It made me sick why it was not reporting changes or deletes
so I looked into the code and found the issue. I think it is severe bug and
the plugin will not work for syncing. If it has the same logic in 0.22 or
0.39 probably it is not working as well.

> 
>> > We could package subversion snapshots as well, but for the first part
>> > of 2010, I was not aware of any major advances in opensync which would
>> > have warranted that.
>> 
>> I think it is less about progress made or not, and more about having an
>> automated system for creating binary packages for people who just want
>> to run a quick test and help developers.
> 
> Automatic building and uploading does not really work well with Debian,
> uploads are supposed to happen manually.  Also, the opensync API has
> still been changing and packages might be broken more than working.  It
> would make more sense to have more regular releases of opensync, in my
> opinion.
> 
> Once squeeze is out and 0.4x packages work somewhat reliably, I can
> upload backports of them for squeeze users to enjoy.
> 

I was thinking to create a debian dir and introduce it to the other opensync
members. The build process is somehow trivial for (most) of them that I
have already compiled.

osynctool --listplugins
Available plugins:
syncml-http-server
syncml-http-client
syncml-obex-client
file-sync
evo2-sync
akonadi-sync


For now filesync is working very well with akonadi and contacts. I'm planing
to start testing syncml with akonadi in few days. I could try fixing the
evo2 plugin too, but ATM I have too many business projects open and no time
to learn the evo api also my C/C++ experience is not at high professional
level. In this concern I also think we need better API documentation but it
is not related to debian or stability. It would just help doing things
faster.

So to sum up I think it is better to test squeeze with 0.22 and members from
backports and to see what needs to be done. If it's too much then leave it
or patch the old libsyncml. Unfortunately I'm not planning to use squeeze
but rather stay on what will be testing next, so I'm not interested in
doing anything for squeeze. If you need a good desktop then debian testing
is the best (my humbled opinion). Squeeze is problematic to me because of
the kde release.

Thanks for the discussion as I think it's _finally_ time to have linux
syncable with mobiles and sort this topic out.

regards

Re: [Opensync-devel] Updating debian unstable

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

Hi,

On Wed, Sep 15, 2010 at 03:36:03AM -0400, Chris Frey wrote:
> On Wed, Sep 15, 2010 at 09:22:28AM +0200, Michael Banck wrote:
> > It is not out of date, it is the currently released development release,
> > as far as I know.  Also 0.22, is still in the stable release, it is not
> > gone from Debian entirely, just from testing/unstable. (There was talk
> > about reviving 0.22 just for the python plugins, which apparently seem
> > to work well for some people still, but I did not get around it so far,
> > and with the freeze in effect I doubt it is doable)
> 
> If 0.22 could return to Squeeze, that would be great.  Let me know
> how I can help, because that would make my life easier.

I have now made the case of reverting to 0.22 to the Debian release
team, let's see whether they accept this.  I believe those are the
main issues currently:

1. The syncml plugin 0.22 version is not ported to libsyncml-0.5.4.  So
unless somebody ports it, it will have to be dropped.

2. The google-calendar plugin crashes if changes have been made in the
other member.  This is ticket #750, which maybe only applies to a
google-calendar plugin ported to 4suite XML (Debian and Ubuntu have
dropped python-xml, so it had to be ported).  I found out that earlier
versions (0.x) of 4suite worked fine, see my analysis here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468601#25
But I guess this will have to be fixed on the google-calendar side.  The
4suite port is also in that bug report to look at.

3. I had issues with the evolution plugin where changes made in its
addressbook were not reported to the engine.  I have not investigated
this in detail.

> > We could package subversion snapshots as well, but for the first part of
> > 2010, I was not aware of any major advances in opensync which would have
> > warranted that.
> 
> I think it is less about progress made or not, and more about having an
> automated system for creating binary packages for people who just want
> to run a quick test and help developers.

Automatic building and uploading does not really work well with Debian,
uploads are supposed to happen manually.  Also, the opensync API has
still been changing and packages might be broken more than working.  It
would make more sense to have more regular releases of opensync, in my
opinion.

Once squeeze is out and 0.4x packages work somewhat reliably, I can
upload backports of them for squeeze users to enjoy.


Michael

Re: [Opensync-devel] evolution plugin (not reporting deletes)

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

--- On Wed, 10/6/10, deloptes <del...@ya...> wrote:

> From: deloptes <del...@ya...>

bug #1264: evo2 plugin X-EVOLUTION-FILE-AS

opened


      

Re: [Opensync-devel] evolution plugin (not reporting deletes)

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

deloptes wrote:

> what can be wrong

it seems that evolution or the plugin is rewriting/reporting internal ids
for the items sent.

thus no items are registered on the opposite side. it might be also an
evolution issue.

[Opensync-devel] evolution plugin (not reporting deletes)

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

it seems that the evolution plugin is not working (not reporting deletes or
modifications)

what can be wrong

I wanted to use it for testing but it seems to not be possible, then I tried
it with the file sync, but it also does not work

regards

Re: [Opensync-devel] akonadi-sync (discussion)

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

Chris Frey wrote:

> Great news!  I so far haven't had the time to setup an akonadi system
> here to test with, but I'm sure there are Akonadi fans out there who
> can help test. :-)

Personal thanks for your support and guiding.

I will need to have a look into configure/discover/initialize.
I am afraid I've misunderstood what it is doing exactly at that time.

I need confirmation on the scenario to save time on reading and looking into
the documentation or other code.

What I did not understand is that the library is taking action on configure
(running with --config option) and that it keeps somewhere track of what is
supported/enabled, so I think the right flow would be

1 --configure (initial)
2 --discover
3 --configure
4 --sync

in 1 you start with the default config (providing information on what is
supported by the plugin and announcing it to the library
in 2 you discover supported features (means verify the opposite side
supports this too).
in 3 you set configuration on what was already configured
 i.e. you know that akonadi definitely supports events/contacts etc and you
 can choose what you would like to use
in 4 you initiate the sync process for the enabled ressources

Well, if those assumptions are true, then the plugin is doing some wired
things :-). I'm sorry for this. I need a bit of assistance here.

I'm moving to the next step to do the calendar sync with its components.
The challenge I am facing now is that if I enable calendar it enables
also "birthdays & anniversaries" ressource which appears as second
ressource and overwrites the url of the previously discovered ressource in
the config. So I am back to the point how to manage multiple akonadi
collections from the same type. I think I need to introduce a new function
for creating of ressource and putting into the config. The need is obvious.
In default configuration you can not put something you don't know.

The better approach however is to drop the <Url>default</Url> property from
the config and let the plugin manage the collections itself.
I will introducing mimetype to the config and filter based on mimetype
through the collection and let the plugin manage the rest.

The name would be then a generic one like "Contacts" and will be not
overwritten in the discover step 2 and step 3 will be optional.

So summing up

in 1 you can define which types of objects you are interested in.
in 2 you will discover what types akonadi supports and this will be written
in the config. Here I will rewrite the discover function to map objType to
mimeType
in 3 you will be able to select what objects you want to sync

in the actual sync the plugin will find the collection based on mimetype and
get the desired item to do the change.

I will need also support for few error cases and reporting to the library,
also what kind of actions can be taken on failure (hashtable actions or
what?)

many thanks and regards

Re: [Opensync-devel] Updating debian unstable

[Juha T. <Juh...@ik...>]

On Wednesday 15 September 2010 11:48:17 you wrote:
> On Wednesday, September 15, 2010 08:36:48 pm Juha Tuomala wrote:
> > We had such blurp for long time and for reason. denisq during his 
> > front page editing hosed 
> > 
> > http://opensync.org/wiki/WikiStart?action=diff&version=139&old_version=138
> > 
> > is for some reason, my guess is that he thought that makes opensync sound 
> > like unfinished - something that it is.
> 
> Could you move that back on the front page?

I let the person who removed it to put it back. Among other useful
stuff that has been flushed.

> > My question is, what is the gain from having anyone to log in and
> > change wiki compared to manually created accounts? It would kill spamming
> > that we've been targeted for years at least. I've a feeling that
> > nobody of old farts is looking after what goes on in wiki these days.
> 
> Good point ... could you start a different thread about that?

That didn't lead anywhere, so if nobody is against it, I switch off that
open account creating and also clean up all spammer and suspicious accounts
from db.


Tuju

-- 
Better to have one, and not need it, than to need one and not have it.

Re: [Opensync-devel] akonadi-sync (discussion)

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

Hi,

On Mon, Oct 04, 2010 at 11:22:42PM +0200, deloptes wrote:
> I'm pleased to announce a version (Revision 6142) that is basically working
> (I tested it with file-sync and with evolution)

Great work!


Michael

Re: [Opensync-devel] akonadi-sync (discussion)

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

Patrick Ohly wrote:

> On Mon, 2010-10-04 at 23:22 +0200, deloptes wrote:
>> I'm pleased to announce a version (Revision 6142) that is basically
>> working (I tested it with file-sync and with evolution)
> 
> Does translation between Evolution vCard flavor (X-EVOLUTION-*
> extensions) and KDE flavor (X-something, don't have it at hand) work?
> 

I think it worked for the few items I've prepared for testing.
I need to fix few things in discover/configure in the next few days, but I'm
optimistic. 

regards

Re: [Opensync-devel] akonadi-sync (discussion)

[Patrick O. <pat...@gm...>]

On Mon, 2010-10-04 at 23:22 +0200, deloptes wrote:
> I'm pleased to announce a version (Revision 6142) that is basically working
> (I tested it with file-sync and with evolution)

Does translation between Evolution vCard flavor (X-EVOLUTION-*
extensions) and KDE flavor (X-something, don't have it at hand) work?

-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/

Re: [Opensync-devel] akonadi-sync (discussion)

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

On Mon, Oct 04, 2010 at 11:22:42PM +0200, deloptes wrote:
> Hi, again,
> 
> I'm pleased to announce a version (Revision 6142) that is basically working
> (I tested it with file-sync and with evolution)

Great news!  I so far haven't had the time to setup an akonadi system
here to test with, but I'm sure there are Akonadi fans out there who
can help test. :-)

- Chris