11:05 a.m.
Hi to all @syncevolution, sorry for bothering you, but I hope one could save
me some digging by answering my questions.
I thank you in advance for the patience and support.
1.
I have an item uid: libkcal-1629736449.222
which is returned by syncevolution (--print-items)
as urlencoded libkcal-1629736449%2e222
Is this on purpose and why?
2.
How are the sources/databases handled - example if I have 3 calendars
(1default, 1 read only and 1 custom). Imagine I set the custom or the
default as inactive or active - how would this influence the sync?
3.
About the platform support.
Is this also picked up by the engine automatically ?
I saw something about KDE in the sync src code as well.
I would like to implement similar functionality with the tdewallet - it
sounds like nice feature to have when dealing with passwords, but I need
some hint here as I was not able to understand from the kde code what
exactly has to be done, so that syncevo can cope with it.
example
info.m_backendRule = "KDE";
4.
My last question is related to the problem I described earlier. When
compiled as shared I get the backend registered twice. When I compile
static it shows up once. I do have different descriptions in the registerMe
function and in the createSource function.
Should I post those functions here?
Thats it for now. Thanks in advance once again
regards
3:01 a.m.
On Wed, 2016-02-03 at 20:05 +0100, deloptes wrote:
Hi to all @syncevolution, sorry for bothering you, but I hope one
could save
me some digging by answering my questions.
I thank you in advance for the patience and support.
1.
I have an item uid: libkcal-1629736449.222
which is returned by syncevolution (--print-items)
as urlencoded libkcal-1629736449%2e222
Is this on purpose and why?
Internally, item uids can be arbitrary strings. For use in shell
scripting, the command line tool escapes "unsafe" characters when
printing them and unescapes them when parsing parameters.
So yes, it is intentional. Whether a dot should be considered safe is
debatable.
2.
How are the sources/databases handled - example if I have 3 calendars
(1default, 1 read only and 1 custom). Imagine I set the custom or the
default as inactive or active - how would this influence the sync?
I'm not sure I follow. Do you mean you have a sync configuration and
then change the sync mode of one datastore set to "none"? It'll be
ignored when running a sync for that sync configuration.
3.
About the platform support.
Is this also picked up by the engine automatically ?
I saw something about KDE in the sync src code as well.
I would like to implement similar functionality with the tdewallet - it
sounds like nice feature to have when dealing with passwords, but I need
some hint here as I was not able to understand from the kde code what
exactly has to be done, so that syncevo can cope with it.
The platform modules themselves just register themselves when loaded by
hooking into the callbacks provided by the core libraries. For example,
KDEPlatformRegister.cpp hooks into the password handling via the boost
signal returned by GetLoadPasswordSignal().
Then KWalletLoadPasswordSlot() itself decides whether it is active.
UseKWallet() has some comments about the logic for that.
Basically that is what you need to replicate.
example
info.m_backendRule = "KDE";
That is not related to password handling. It is what a datastore uses to
configure the conversion from the internal data format into the vCard
"dialect" used by the store.
In this example, src/syncevo/configs/datatypes/01vcard-profile.xml has
conditional rules that are only active in the "KDE" case.
4.
My last question is related to the problem I described earlier. When
compiled as shared I get the backend registered twice. When I compile
static it shows up once. I do have different descriptions in the registerMe
function and in the createSource function.
Should I post those functions here?
That may help.
Have you tried what I suggested, i.e. removing one of your two shared
modules and checking how that affects the result?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
5:26 a.m.
Patrick Ohly wrote:
On Wed, 2016-02-03 at 20:05 +0100, deloptes wrote:
> Hi to all @syncevolution, sorry for bothering you, but I hope one could
> save me some digging by answering my questions.
> I thank you in advance for the patience and support.
>
> 1.
> I have an item uid: libkcal-1629736449.222
> which is returned by syncevolution (--print-items)
> as urlencoded libkcal-1629736449%2e222
>
> Is this on purpose and why?
Internally, item uids can be arbitrary strings. For use in shell
scripting, the command line tool escapes "unsafe" characters when
printing them and unescapes them when parsing parameters.
So yes, it is intentional. Whether a dot should be considered safe is
debatable.
Understood - thanks - just needed confirmation.
> 2.
> How are the sources/databases handled - example if I have 3 calendars
> (1default, 1 read only and 1 custom). Imagine I set the custom or the
> default as inactive or active - how would this influence the sync?
I'm not sure I follow. Do you mean you have a sync configuration and
then change the sync mode of one datastore set to "none"? It'll be
ignored when running a sync for that sync configuration.
I try to explain. I have calendar datastore with 3 databases : 1 is the
default (my calendar), 2 is holidays (read only) 3 is custom calendar.
I'm not sure what happens when I try to sync with my phone. Would all
databases be pushed to the default calendar in the phone? For this I would
just disable 2 and 3 and let only 1 active. The plugin ignores the
databases which are not active and provides the items from the active only
for sync.
Now in regards to your comment - does it mean I have to configure explicitly
the database I want to sync.
This also delivers few possible scenarios if a database was configured (and
was active) but for some reason the user would have deactivated it. what
happens
example --print-databases
TDE PIM Calendar = TDE PIM Events = tdepim-calendar:
resource (kOBUWNvG42) <default>
feiertage (uZzNwmwG32) <read-only>
custom (xYggAVX5Bu)
In this case syncevolution would sync resource + custom - correct?
Or it should be explicitly configured - this is a bit confusing from the
documentation on the other plugins I could read so far.
Now imagine it was configured for sync:
- what would happen on the other side - does resource+custom go into one
calendar and if what happens when I sync back.
- what if I would deactivate custom
> 3.
> About the platform support.
> Is this also picked up by the engine automatically ?
> I saw something about KDE in the sync src code as well.
> I would like to implement similar functionality with the tdewallet - it
> sounds like nice feature to have when dealing with passwords, but I need
> some hint here as I was not able to understand from the kde code what
> exactly has to be done, so that syncevo can cope with it.
The platform modules themselves just register themselves when loaded by
hooking into the callbacks provided by the core libraries. For example,
KDEPlatformRegister.cpp hooks into the password handling via the boost
signal returned by GetLoadPasswordSignal().
Then KWalletLoadPasswordSlot() itself decides whether it is active.
UseKWallet() has some comments about the logic for that.
Basically that is what you need to replicate.
Ok thanks - I assume it is not a precondition for the plugin to work
> example
>
> info.m_backendRule = "KDE";
That is not related to password handling. It is what a datastore uses to
configure the conversion from the internal data format into the vCard
"dialect" used by the store.
In this example, src/syncevo/configs/datatypes/01vcard-profile.xml has
conditional rules that are only active in the "KDE" case.
Thanks, but perhaps I should take care of that as well, because KDE is
successor of what is now TDE. I need to check if KDE can be reused or I
should have own version.
> 4.
> My last question is related to the problem I described earlier. When
> compiled as shared I get the backend registered twice. When I compile
> static it shows up once. I do have different descriptions in the
> registerMe function and in the createSource function.
> Should I post those functions here?
That may help.
Have you tried what I suggested, i.e. removing one of your two shared
modules and checking how that affects the result?
Yes I did, but it did not help - I removed all (so,a,la) for the addressbook
but calendar/todo/tasks showed up.
I tried with function implementation and looked into the cal/cardDav - liked
the class function impl, but still same result. I attach it here in a txt
file
6:30 a.m.
On Fri, 2016-02-05 at 14:26 +0100, deloptes wrote:
Patrick Ohly wrote:
> On Wed, 2016-02-03 at 20:05 +0100, deloptes wrote:
>> 2.
>> How are the sources/databases handled - example if I have 3 calendars
>> (1default, 1 read only and 1 custom). Imagine I set the custom or the
>> default as inactive or active - how would this influence the sync?
>
> I'm not sure I follow. Do you mean you have a sync configuration and
> then change the sync mode of one datastore set to "none"? It'll be
> ignored when running a sync for that sync configuration.
I try to explain. I have calendar datastore with 3 databases : 1 is the
default (my calendar), 2 is holidays (read only) 3 is custom calendar.
I'm not sure what happens when I try to sync with my phone. Would all
databases be pushed to the default calendar in the phone?
That depends on the backend. Each datastore in a sync config invokes the
backend, which then picks an actual database based on the "database"
parameter configured for the datastore.
Usually, that parameter is empty, which typically means "pick the
default". But that's entirely up to the backend. See
EvolutionSyncSource::findSource() for an example how that is done in
EDS.
Now in regards to your comment - does it mean I have to configure
explicitly
the database I want to sync.
This also delivers few possible scenarios if a database was configured (and
was active) but for some reason the user would have deactivated it. what
happens
example --print-databases
TDE PIM Calendar = TDE PIM Events = tdepim-calendar:
resource (kOBUWNvG42) <default>
feiertage (uZzNwmwG32) <read-only>
custom (xYggAVX5Bu)
In this case syncevolution would sync resource + custom - correct?
No, your backend would only access one.
>> 4.
>> My last question is related to the problem I described earlier. When
>> compiled as shared I get the backend registered twice. When I compile
>> static it shows up once. I do have different descriptions in the
>> registerMe function and in the createSource function.
>> Should I post those functions here?
>
> That may help.
>
> Have you tried what I suggested, i.e. removing one of your two shared
> modules and checking how that affects the result?
>
Yes I did, but it did not help - I removed all (so,a,la) for the addressbook
but calendar/todo/tasks showed up.
That confirms my theory: I bet your register_func object linked into
both shared modules, and then each module registers both kinds of data.
You need two registration files, one per module, and only register data
provided by that module in the file.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
9:13 a.m.
Thanks for all the information.
Patrick Ohly wrote:
That confirms my theory: I bet your register_func object linked into
both shared modules, and then each module registers both kinds of data.
You need two registration files, one per module, and only register data
provided by that module in the file.
I attached the two functions/objects - to me it looks different, so the
issue would be in the way of building and linking the .so libraries.
I will double check this - perhaps some inheritance in the variables.
thanks!
Could you also help with configuration? I wanted to try TDE
contacts/calendar with local file and from the documentation I tried to
configure like this, but it did not work
# configure target config
syncevolution --configure \
--template none \
addressbook/backend=file \
addressbook/database=file:///tmp/testabc \
calendar/backend=file \
calendar/database=file:///tmp/testcal \
target-config@file
# configure sync config
syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://@file \
username= \
password= \
addressbook/backend=tdepim-contacts \
calendar/backend=tdepim-calendar \
file \
calendar addressbook
last I tried this
# configure target config
syncevolution --configure \
--template none \
username= \
password= \
addressbook/backend=file \
addressbook/database=file:///tmp/testabc \
addressbook/syncFormat=text/vcard \
calendar/backend=file \
calendar/database=file:///tmp/testcal \
calendar/syncFormat=text/calendar \
test1@file
# configure sync config
syncevolution --configure \
--template none \
peerIsClient=1 \
syncURL=local://@file \
username= \
password= \
addressbook/backend=tdepim-contacts \
addressbook/database=kxXrRFzP9c \
calendar/backend=tdepim-calendar \
calendar/database=ZsPZokpoTg \
file \
calendar addressbook
and executed with --sync slow
but it fails saying no DB was active for the target-config. I'm reading the
docs to get proper understanding what how works and how it should be
configured, and perhaps I need to look forward for debuggin - though in the
attached relevant logs I see the objects are created in my plugin, so I'm
not sure which DB - perhaps the file one ... or am I missing something?
regards
12:37 p.m.
New subject: [SyncEvolution] TDEPIM sync questions [solved double register]
Patrick Ohly wrote:
That confirms my theory: I bet your register_func object linked into
both shared modules, and then each module registers both kinds of data.
You need two registration files, one per module, and only register data
provided by that module in the file.
I solved this - the problem was including the xxxRegxxx.cpp in the
xxxSource.cpp and listing it in the src_backends_tdepim_xxxxxxx_src
variable.
Now looking forward to configure it properly and test it.
regards
1:56 a.m.
Patrick Ohly wrote:
You need two registration files, one per module, and only register data
provided by that module in the file.
It was not easy to understand the logic of configuration, but after reading
couple of times the server howto, the akonadi howto and the examples
https://syncevolution.org/wiki/http-server-howto
https://syncevolution.org/wiki/kde-akonadi
https://syncevolution.org/documentation/syncevolution-usage#examples
I was able to compile somehow of working configuration.
I am afraid I need to do some minor fixing now.
I also have a question here.
When I run
syncevolution --sync slow <config>
It does now exit, but staying there after
Synchronization successfull
Changes applied ....
Data modified ....
*** @..../addressbook ***
no changes
Thanks for the ideas and support so far.
regards
4:26 a.m.
On 06/02/16 09:56, deloptes wrote:
It does now exit, but staying there after
Synchronization successfull
Changes applied ....
Data modified ....
*** @..../addressbook ***
no changes
I assume you meant "It does NOT exit". In my experience, the appearance
of syncevolution not exiting is often due to the "changes" perl script
which, in may case, can take a VERY long time. I don't remember the
name of the script offhand but while it is "hung" you may want to see if
there is a process running perl on your system.
I recommend that while initially testing you set "printChanges=0" (if
you have a lot of data you may want to set dumpData=0 as well, except
when you really want to save the data). Turning off both those at least
means you are really just testing the sync code.
That may not be your problem at all, but it is worth checking.
Graham
11:35 a.m.
On Sat, 2016-02-06 at 12:26 +0000, Graham Cobb wrote:
On 06/02/16 09:56, deloptes wrote:
> It does now exit, but staying there after
>
> Synchronization successfull
> Changes applied ....
> Data modified ....
> *** @..../addressbook ***
> no changes
I assume you meant "It does NOT exit". In my experience, the appearance
of syncevolution not exiting is often due to the "changes" perl script
which, in may case, can take a VERY long time. I don't remember the
name of the script offhand but while it is "hung" you may want to see if
there is a process running perl on your system.
I recommend that while initially testing you set "printChanges=0" (if
you have a lot of data you may want to set dumpData=0 as well, except
when you really want to save the data). Turning off both those at least
means you are really just testing the sync code.
That may not be your problem at all, but it is worth checking.
Agreed.
In addition, running with
SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=10 ....
is also recommended. This keeps all operations inside a single process
(nice for running under gdb), without suppressing any debug output that
might come from inside the libraries that are getting called.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
4:46 p.m.
Graham Cobb wrote:
On 06/02/16 09:56, deloptes wrote:
> It does now exit, but staying there after
>
> Synchronization successfull
> Changes applied ....
> Data modified ....
> *** @..../addressbook ***
> no changes
I assume you meant "It does NOT exit". In my experience, the appearance
of syncevolution not exiting is often due to the "changes" perl script
which, in may case, can take a VERY long time. I don't remember the
name of the script offhand but while it is "hung" you may want to see if
there is a process running perl on your system.
I recommend that while initially testing you set "printChanges=0" (if
you have a lot of data you may want to set dumpData=0 as well, except
when you really want to save the data). Turning off both those at least
means you are really just testing the sync code.
That may not be your problem at all, but it is worth checking.
Graham
Hi Graham,
I think we've met in the OpenSync project at some point. I do not have any
perl process doing something. I have 340 contacts - not sure if it is a
lot - first testing just the addressbook. It looks like it finishes the
sync and waiting for something. I didn't have time to try the option you
mentioned - and I am not sure where I ahve to put them.
Still studing the configuration.
I'm just not sure why I have to press CTRL+C twice to get it to the end, but
I'll figure it out.
I think I have a problem with understanding the configuration and how I can
create a test setup where I have a local sync server (file backend) and TDE
PIM on the other side.
It looks like it worked for addressbook, but trying to reproduce or extend
it with calendar was not successfull yet.
Perhaps someone can help a bit here
Please comment the config below and why extending it with calendar did not
work, also if it is proper to clean up by doing
rm -rf ~/.cache/syncevolution/ ~/.config/syncevolution/ /tmp/test
Thanks in advance
======== config script =======
peer=tdepim
datapath=/tmp/test
# configure target config
syncevolution --configure \
--template none \
username= \
password= \
target-config@${peer}
# Remove the "--source-property type" lines to use the Evolution backends.
syncevolution --configure \
--template none \
--source-property type=file:text/vcard:3.0 \
--source-property evolutionsource=file://${datapath}/addressbook \
${peer} addressbook
syncevolution --configure \
--source-property sync=two-way \
${peer} addressbook
# configure sync config
syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://@${peer} \
peerIsClient=1 \
username= \
password= \
${peer} \
addressbook
syncevolution --configure \
addressbook/backend=tdepim-contacts \
addressbook/database=kxXrRFzP9c \
@${peer} addressbook
3:48 a.m.
On Sun, 2016-02-07 at 01:46 +0100, deloptes wrote:
Graham Cobb wrote:
> On 06/02/16 09:56, deloptes wrote:
>> It does now exit, but staying there after
>>
>> Synchronization successfull
>> Changes applied ....
>> Data modified ....
>> *** @..../addressbook ***
>> no changes
>
> I assume you meant "It does NOT exit". In my experience, the appearance
> of syncevolution not exiting is often due to the "changes" perl script
> which, in may case, can take a VERY long time. I don't remember the
> name of the script offhand but while it is "hung" you may want to see if
> there is a process running perl on your system.
>
> I recommend that while initially testing you set "printChanges=0" (if
> you have a lot of data you may want to set dumpData=0 as well, except
> when you really want to save the data). Turning off both those at least
> means you are really just testing the sync code.
>
> That may not be your problem at all, but it is worth checking.
>
> Graham
Hi Graham,
I think we've met in the OpenSync project at some point. I do not have any
perl process doing something. I have 340 contacts - not sure if it is a
lot - first testing just the addressbook. It looks like it finishes the
sync and waiting for something. I didn't have time to try the option you
mentioned - and I am not sure where I ahve to put them.
Still studing the configuration.
I'm just not sure why I have to press CTRL+C twice to get it to the end, but
I'll figure it out.
It seems to hang somewhere. Running the command line I gave with
--daemon=no under gdb should make it obvious where that is.
I think I have a problem with understanding the configuration and how
I can
create a test setup where I have a local sync server (file backend) and TDE
PIM on the other side.
It looks like it worked for addressbook, but trying to reproduce or extend
it with calendar was not successfull yet.
Perhaps someone can help a bit here
Please comment the config below and why extending it with calendar did not
work,
Not sure about calendar. It should be enough to replace "addressbook"
with "calendar" and "tdepim-contacts" with
"tdepim-calendar".
Before you try to sync it is probably easier to check that access to TDE
data works. See https://syncevolution.org/wiki/item-operations
also if it is proper to clean up by doing
rm -rf ~/.cache/syncevolution/ ~/.config/syncevolution/ /tmp/test
Yes, that should cover everything.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:45 p.m.
Patrick Ohly wrote:
It seems to hang somewhere. Running the command line I gave with
--daemon=no under gdb should make it obvious where that is.
thanks for the hint - see the gdb output below. I read your msg after I have
posted mine already.
But I still do not understand what is exactly wrong by looking at the
relevant places - or more precisely why the client wouldn't close the
connection.
Before you try to sync it is probably easier to check that access to TDE
data works. See https://syncevolution.org/wiki/item-operations
Thanks,
I already did that for each datastore type and it does correctly output the
items. I also tried "--export - tdepim " which also exits normally.
I'm not sure if it is a code issue or config issue. Looking at my code I
tend to think it is config issue, but looking at the gdb output it could be
that something is not exiting properly or at all. So the local transport
does not shutdown properly|at all.
Could you help with this a bit please!
regards
=========== GDB ========
^C
Program received signal SIGINT, Interrupt.
0x00007ffff543ce8d in poll () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0 0x00007ffff543ce8d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff639dee4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff639e272 in g_main_loop_run ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff6c5d1bb in SyncEvo::LocalTransportAgent::shutdown
(this=0x6e7390) at src/syncevo/LocalTransportAgent.cpp:465
#4 0x00007ffff6d243b8 in SyncEvo::SyncContext::doSync
(this=this@entry=0x6b9780) at src/syncevo/SyncContext.cpp:4478
#5 0x00007ffff6d2c934 in SyncEvo::SyncContext::sync (this=0x6b9780,
report=report@entry=0x7fffffffda88)
at src/syncevo/SyncContext.cpp:3442
#6 0x00007ffff6ca81c8 in SyncEvo::Cmdline::run
(this=this@entry=0x7fffffffda50) at src/syncevo/Cmdline.cpp:1725
#7 0x0000000000414198 in SyncEvo::main (argc=<optimized out>,
argv=<optimized out>) at src/syncevolution.cpp:531
11:25 p.m.
On Sun, 2016-02-07 at 21:45 +0100, deloptes wrote:
I already did that for each datastore type and it does correctly
output the
items. I also tried "--export - tdepim " which also exits normally.
I'm not sure if it is a code issue or config issue. Looking at my code I
tend to think it is config issue, but looking at the gdb output it could be
that something is not exiting properly or at all. So the local transport
does not shutdown properly|at all.
In case of a local sync, two processes are involved. You need to attach
to syncevo-local-sync (gdb -p `pidof syncevo-local-sync`) and have a
look where that one is stuck when the problem occurs.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:19 a.m.
Patrick Ohly wrote:
In case of a local sync, two processes are involved. You need to
attach
to syncevo-local-sync (gdb -p `pidof syncevo-local-sync`) and have a
look where that one is stuck when the problem occurs.
Thanks again for the hint. I do not have that much experience in debugging
at this level.
I'll check the details in the evening. If someone has time and idea to help
me further, here is the bt output (gdb -p `pidof syncevo-local-sync`).
Loaded symbols for /usr/lib/libtqui.so.1
0x00007ffff5170e8d in poll () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0 0x00007ffff5170e8d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff5ec4ee4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff5ec4ffc in g_main_context_iteration ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff6b03891 in SyncEvo::LocalTransportAgentChild::step
(this=this@entry=0x67fd30,
status="waiting for parent's ACK for sync report") at
src/syncevo/LocalTransportAgent.cpp:818
#4 0x00007ffff6b08bed in SyncEvo::LocalTransportAgentChild::run
(this=0x67fd30) at src/syncevo/LocalTransportAgent.cpp:1147
#5 0x00007ffff6afd5b0 in SyncEvo::LocalTransportMain (argc=<optimized out>,
argv=<optimized out>)
at src/syncevo/LocalTransportAgent.cpp:1335
#6 0x00007ffff50b2b45 in __libc_start_main (main=0x400940
<SyncEvo::main(int, char**)>, argc=1, argv=0x7fffffffde98,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized
out>,
stack_end=0x7fffffffde88) at libc-start.c:287
#7 0x000000000040099f in _start ()
Thank you in advance.
1:56 a.m.
On Mon, 2016-02-08 at 09:19 +0100, deloptes wrote:
Patrick Ohly wrote:
> In case of a local sync, two processes are involved. You need to attach
> to syncevo-local-sync (gdb -p `pidof syncevo-local-sync`) and have a
> look where that one is stuck when the problem occurs.
Thanks again for the hint. I do not have that much experience in debugging
at this level.
I'll check the details in the evening. If someone has time and idea to help
me further, here is the bt output (gdb -p `pidof syncevo-local-sync`).
Loaded symbols for /usr/lib/libtqui.so.1
0x00007ffff5170e8d in poll () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0 0x00007ffff5170e8d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff5ec4ee4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff5ec4ffc in g_main_context_iteration ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff6b03891 in SyncEvo::LocalTransportAgentChild::step
(this=this@entry=0x67fd30,
status="waiting for parent's ACK for sync report") at
src/syncevo/LocalTransportAgent.cpp:818
#4 0x00007ffff6b08bed in SyncEvo::LocalTransportAgentChild::run
(this=0x67fd30) at src/syncevo/LocalTransportAgent.cpp:1147
#5 0x00007ffff6afd5b0 in SyncEvo::LocalTransportMain (argc=<optimized out>,
argv=<optimized out>)
at src/syncevo/LocalTransportAgent.cpp:1335
#6 0x00007ffff50b2b45 in __libc_start_main (main=0x400940
<SyncEvo::main(int, char**)>, argc=1, argv=0x7fffffffde98,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized
out>,
stack_end=0x7fffffffde88) at libc-start.c:287
#7 0x000000000040099f in _start ()
So that really looks like an issue with the LocalTransport IPC
mechanism. The "waiting for parent's ACK for sync report" explains what
the target side of the local sync is waiting for.
It's not clear why that fails.
LocalTransportAgent::storeSyncReport() is the parent side and logs "got
child sync report" once the data made it across the local D-Bus
connection. Do you see that when running with SYNCEVOLUTION_DEBUG and
loglevel=10?
Another test might be to set up syncing between file backends. For that
replace the TDE datastores on the target side of your sync config with
another file backend, like you did on the local side. If that also
fails, then it should be a problem that is completely independent of
your TDE work.
However, then you'd still have to debug it, as I haven't seen that
myself so far :-/
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
11:46 p.m.
Patrick Ohly wrote:
LocalTransportAgent::storeSyncReport() is the parent side and logs
"got
child sync report" once the data made it across the local D-Bus
connection. Do you see that when running with SYNCEVOLUTION_DEBUG and
loglevel=10?
yes I see status=200 - everything went good, but the one side is waiting for
the other to close the connection, which never happens
Another test might be to set up syncing between file backends. For that
replace the TDE datastores on the target side of your sync config with
another file backend, like you did on the local side. If that also
fails, then it should be a problem that is completely independent of
your TDE work.
OK
I'll try to do that and report back, thanks
However, then you'd still have to debug it, as I haven't seen that
myself so far :-/
There is a lot of //TODOs all arround those lines reported. I was just not
at 100% sure if I have the proper setup, but now I think so and sooner or
later we'll solve this ACK issue.
thanks
8:52 a.m.
Patrick Ohly wrote:
Another test might be to set up syncing between file backends. For
that
replace the TDE datastores on the target side of your sync config with
another file backend, like you did on the local side. If that also
fails, then it should be a problem that is completely independent of
your TDE work.
File to File works :-(
regards
8:55 a.m.
On Wed, 2016-02-10 at 17:52 +0100, deloptes wrote:
Patrick Ohly wrote:
> Another test might be to set up syncing between file backends. For that
> replace the TDE datastores on the target side of your sync config with
> another file backend, like you did on the local side. If that also
> fails, then it should be a problem that is completely independent of
> your TDE work.
File to File works :-(
Hmm. At least that gives you something to compare the debug output
against. I'm afraid I'm out of further ideas.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
9:34 a.m.
Patrick Ohly wrote:
Hmm. At least that gives you something to compare the debug output
against. I'm afraid I'm out of further ideas.
What is expected to happen when it hangs - when does this ACK is sent?
I see shutdown() is called and it is waiting to shut down. What does this
shutdown() causes - I don't feel like studing the code at the moment, but
at the end perhaps this should happen.
As I said before, all the relevant places have some TODOs that sound
related.
ideas are welcome
regards
4:50 a.m.
deloptes wrote:
I think I have a problem with understanding the configuration and how I
can create a test setup where I have a local sync server (file backend)
and TDE PIM on the other side.
It looks like it worked for addressbook, but trying to reproduce or extend
it with calendar was not successfull yet.
The problem with syncing calendar items was solved.
It turned out to be a code issue, so after fixing it I now can sync all
types, but I still have the problem, that it hangs in the middle and I have
to hit CTRL+C twice or more times to get back to the shell.
I don't know in which direction I have to look - something related to the
transport? Could you please help?
In the config I have now - I am not sure where I had to apply dumpData=0 and
printChanges=0
syncevolution --configure \
--template none \
username= \
password= \
dumpData=0 \
printChanges=0 \
target-config@${peer}
syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://@${peer} \
peerIsClient=1 \
dumpData=0 \
printChanges=0 \
username= \
password= \
${peer} \
addressbook calendar todo memo
Here is what I see executing
SYNCEVOLUTION_DEBUG=1 syncevolution loglevel=10 --daemon=no --sync slow
tdepim addressbook
...
[DEBUG 00:00:05] before SessionStep: STEPCMD_STEP
[DEBUG 00:00:05] after SessionStep: STEPCMD_SENDDATA
[DEBUG 00:00:05] @default/addressbook: total number of items received 345
[DEBUG 00:00:05] before SessionStep: STEPCMD_SENTDATA
[DEBUG 00:00:05] @default/addressbook: DeleteContext
[DEBUG 00:00:05] @default/addressbook: DeleteContext
[DEBUG 00:00:05] after SessionStep: STEPCMD_OK
[DEBUG 00:00:05] before SessionStep: STEPCMD_STEP
[DEBUG 00:00:05] after SessionStep: STEPCMD_PROGRESS
[DEBUG 00:00:05] before SessionStep: STEPCMD_STEP
[DEBUG 00:00:05] after SessionStep: STEPCMD_DONE
[DEBUG 00:00:05] parent is shutting down
[DEBUG 00:00:05] waiting for child to stop
[INFO @tdepim 00:00:05] @tdepim/addressbook: first time sync done
successfully
[DEBUG 00:00:05] waiting for child to stop
Synchronization successful.
Changes applied during synchronization (@tdepim):
+---------------|-----------------------|-----------------------|-CON-+
| | @tdepim | @default | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 345 | 0 | 0 | 0 | 0 |
| slow, 65 KB sent by client, 0 KB received |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun 07 Feb 2016 12:57:30 PM CET, duration 0:05min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
[DEBUG 00:00:05] got child sync report:
[DEBUG 00:00:05] end = 1454846255
[DEBUG 00:00:05] source-addressbook-backup-after = -1
[DEBUG 00:00:05] source-addressbook-backup-before = -1
[DEBUG 00:00:05] source-addressbook-first = true
[DEBUG 00:00:05] source-addressbook-mode = slow
[DEBUG 00:00:05] source-addressbook-resume = false
[DEBUG 00:00:05] source-addressbook-stat-local-any-sent = 66842
[DEBUG 00:00:05] source-addressbook-stat-remote-added-total = 345
[DEBUG 00:00:05] source-addressbook-status = 0
[DEBUG 00:00:05] start = 1454846250
[DEBUG 00:00:05] status = 200
^C[DEBUG 00:00:08] SuspendFlags: read 7 from fd 6
[DEBUG 00:00:08] reveived signal 2
^C[DEBUG 00:00:08] SuspendFlags: read 7 from fd 6
[DEBUG 00:00:08] reveived signal 2
[DEBUG 00:00:08] CancelTransport: cancelling because of SuspendFlags::ABORT
[DEBUG 00:00:08] killing local transport child in cancel()
[DEBUG 00:00:08] ForkExecParent: killing syncevo-local-sync 86649 with
signal 0 (SIGINT SIGTERM)
[DEBUG 00:00:08] child process has quit with status 15
[DEBUG 00:00:08] ForkExecParent: child 86649 was signaled yes, signal 15
(SIGINT=2, SIGTERM=15), int sent yes, term sent yes
[DEBUG 00:00:08] ForkExecParent: shutting down, telling syncevo-local-sync
86649 that it lost the connection, it is watching
[DEBUG 00:00:08]
ForkExecParentDBusAPI /org/syncevolution/forkexec/parent/forkexec1:
destroying with 1 active watches
[DEBUG 00:00:08] closing session
[DEBUG 00:00:08] session closed
[DEBUG 00:00:08] SuspendFlags: deactivating fds 7->6
[DEBUG 00:00:08] SuspendFlags: close m_receiverFD 6
[DEBUG 00:00:08] SuspendFlags: close m_senderFD 7
[DEBUG 00:00:08] SuspendFlags: done with deactivation
[DEBUG 00:00:08] Module_DeleteContext addressbook
[DEBUG 00:00:08] Module_DeleteContext addressbook
[DEBUG 00:00:08] Module_DeleteContext 'session'
Synchronization successful.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @tdepim | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 345 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| slow, 0 KB sent by client, 65 KB received |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Feb 7 12:57:30 2016, duration 0:09min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
[DEBUG 00:00:08] log path -> /home/emanoil/.cache/syncevolution, <okay>
12:15 p.m.
Hi Graham,
it took me a while to get the basics working.
Regarding the configuration this is what I did for testing TDEPIM to LOCAL file store
syncevolution --configure \
--template none \
username= \
password= \
addressbook/backend=tdepim-contacts \
addressbook/database="kxXrRFzP9c" \
addressbook/databaseFormat="text/vcard" \
calendar/backend=tdepim-calendar \
calendar/database="ZsPZokpoTg" \
calendar/databaseFormat="text/calendar" \
todo/backend=tdepim-tasks \
todo/database="ZsPZokpoTg" \
todo/databaseFormat="text/calendar" \
memo/backend=tdepim-memos \
memo/database="ZsPZokpoTg" \
memo/databaseFormat="text/plain" \
target-config@${peer} addressbook calendar todo memo
# Remove the "--source-property type" lines to use the Evolution backends.
syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://target-config@${peer} \
peerIsClient=1 \
--source-property type=file:text/vcard:3.0 \
--source-property evolutionsource=file://${datapath}/addressbook \
${peer} addressbook
syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://target-config@${peer} \
peerIsClient=1 \
--source-property type=file:text/calendar:2.0 \
--source-property evolutionsource=file://${datapath}/calendar \
${peer} calendar
syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://target-config@${peer} \
peerIsClient=1 \
--source-property type=file:text/calendar:2.0 \
--source-property evolutionsource=file://${datapath}/todo \
${peer} todo
syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://target-config@${peer} \
peerIsClient=1 \
--source-property type=file:text/plain:1.0 \
--source-property evolutionsource=file://${datapath}/memo \
${peer} memo
I had to change something in the LocalTransportAgent.cpp to get the peer exiting and sync
completing
My addressbook works fine. Calendar/todo/memo is missing the data at the end.I need to
have a look why now.
regards
On Saturday, February 6, 2016 1:26 PM, Graham Cobb <g+syncevolution(a)cobb.uk.net>
wrote:
On 06/02/16 09:56, deloptes wrote:
It does now exit, but staying there after
Synchronization successfull
Changes applied ....
Data modified ....
*** @..../addressbook ***
no changes
I assume you meant "It does NOT exit". In my experience, the appearance
of syncevolution not exiting is often due to the "changes" perl script
which, in may case, can take a VERY long time. I don't remember the
name of the script offhand but while it is "hung" you may want to see if
there is a process running perl on your system.
I recommend that while initially testing you set "printChanges=0" (if
you have a lot of data you may want to set dumpData=0 as well, except
when you really want to save the data). Turning off both those at least
means you are really just testing the sync code.
That may not be your problem at all, but it is worth checking.
Graham
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
1801
days inactive
1813
days old
syncevolution@synevolution.org
20 comments
4 participants
participants (4)
-
deloptes -
Emanoil Kotsev -
Graham Cobb -
Patrick Ohly