10:54 a.m.
Hello,
Today one of my PCs had a major upgrade (to Debian "Jessie"). In the
process, Evolution was upgraded from 3.8.5 to 3.12.9.
The initial (slow) sync went well (I saw some contacts exchanged).
But afterwards, each subsequent attempt at syncing with Memotoo gives me
an "error 10508", whatever type of sync (normal or slow) I try.
Also tried to "refresh from server", but no luck.
So thanks a lot in advance for any help. Best regards,
--
Daniel CLEMENT
2:42 a.m.
On Tue, 2015-05-26 at 16:54 +0200, Daniel CLEMENT wrote:
Hello,
Today one of my PCs had a major upgrade (to Debian "Jessie"). In the
process, Evolution was upgraded from 3.8.5 to 3.12.9.
The initial (slow) sync went well (I saw some contacts exchanged).
But afterwards, each subsequent attempt at syncing with Memotoo gives me
an "error 10508", whatever type of sync (normal or slow) I try.
Also tried to "refresh from server", but no luck.
What's the console output when running a sync from the command line?
What's in the html log pointed to at the end of the console output?
--
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:50 a.m.
Le mercredi 27 mai 2015 à 08:42 +0200, Patrick Ohly a écrit :
On Tue, 2015-05-26 at 16:54 +0200, Daniel CLEMENT wrote:
> Hello,
>
> Today one of my PCs had a major upgrade (to Debian "Jessie"). In the
> process, Evolution was upgraded from 3.8.5 to 3.12.9.
>
> The initial (slow) sync went well (I saw some contacts exchanged).
>
> But afterwards, each subsequent attempt at syncing with Memotoo gives me
> an "error 10508", whatever type of sync (normal or slow) I try.
>
> Also tried to "refresh from server", but no luck.
What's the console output when running a sync from the command line?
The output is below. The error n° is different when run from command
line.
What's in the html log pointed to at the end of the console
output?
I'm attaching the file. Hope that it reaches the list. It looks to me
that there could be a problem with vCard versions (which may have
changed in the newer Evolution)?
command line output:
---
[1]daniel@e6330d ~ $ syncevolution memotoo
[INFO] calendar+todo: inactive
[INFO] addressbook: starting first time sync from server (peer is
server)
[INFO] calendar: starting first time sync from server (peer is server)
[INFO] memo: starting first time sync from server (peer is server)
[INFO] todo: resuming first time sync from server (peer is server)
[INFO] creating complete data backup of datastore todo before sync
(enabled with dumpData and needed for printChanges)
Local data changes to be applied during synchronization:
*** todo ***
Comparison was impossible.
[INFO] addressbook: first time sync done unsuccessfully
[ERROR] addressbook: local, status 20048
[INFO] calendar: first time sync done unsuccessfully
[ERROR] calendar: local, status 20048
[INFO] memo: first time sync done unsuccessfully
[ERROR] memo: local, status 20048
[ERROR] Aborting because of unexpected slow sync for datastore(s):
addressbook calendar memo
[INFO] Doing a slow synchronization may lead to duplicated items or
[INFO] lost data when the server merges items incorrectly. Choosing
[INFO] a different synchronization mode may be the better alternative.
[INFO] Restart synchronization of affected source(s) with one of the
[INFO] following sync modes to recover from this problem:
[INFO] slow, refresh-from-server, refresh-from-client
[INFO]
[INFO] Analyzing the current state:
[INFO] syncevolution --status memotoo addressbook calendar memo
[INFO]
[INFO] Running with one of the three modes:
[INFO] syncevolution --sync [slow|refresh-from-remote|
refresh-from-local] memotoo addressbook calendar memo
[INFO] todo: resumed first time sync done unsuccessfully
[ERROR] todo: aborted on behalf of user (local, status 20017)
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed,
see /home/daniel/.cache/syncevolution/memotoo-2015-05-27-11-33/syncevolution-log.html for
details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| unexpected slow sync (local, status 22000) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| unexpected slow sync (local, status 22000) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| unexpected slow sync (local, status 22000) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| todo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 0 before sync, 0 after it |
| aborted on behalf of user (local, status 20017) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Wed May 27 11:33:40 2015, duration 0:01min |
| aborted on behalf of user (local, status 20017) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: local, status 20048
Doing a slow synchronization may lead to duplicated items or
lost data when the server merges items incorrectly. Choosing
a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the
following sync modes to recover from this problem:
slow, refresh-from-server, refresh-from-client
Analyzing the current state:
syncevolution --status memotoo addressbook calendar memo
Running with one of the three modes:
syncevolution --sync [slow|refresh-from-remote|refresh-from-local]
memotoo addressbook calendar memo
Data modified locally during synchronization:
*** todo ***
no changes
---
Best regards,
--
Daniel CLEMENT
6:45 a.m.
On Wed, 2015-05-27 at 11:50 +0200, Daniel CLEMENT wrote:
[1]daniel@e6330d ~ $ syncevolution memotoo
[INFO] calendar+todo: inactive
[INFO] addressbook: starting first time sync from server (peer is
server)
[INFO] calendar: starting first time sync from server (peer is server)
[INFO] memo: starting first time sync from server (peer is server)
[INFO] todo: resuming first time sync from server (peer is server)
[INFO] creating complete data backup of datastore todo before sync
(enabled with dumpData and needed for printChanges)
Local data changes to be applied during synchronization:
*** todo ***
Comparison was impossible.
[INFO] addressbook: first time sync done unsuccessfully
[ERROR] addressbook: local, status 20048
[INFO] calendar: first time sync done unsuccessfully
[ERROR] calendar: local, status 20048
[INFO] memo: first time sync done unsuccessfully
[ERROR] memo: local, status 20048
[ERROR] Aborting because of unexpected slow sync for datastore(s):
addressbook calendar memo
[INFO] Doing a slow synchronization may lead to duplicated items or
[INFO] lost data when the server merges items incorrectly. Choosing
[INFO] a different synchronization mode may be the better alternative.
[INFO] Restart synchronization of affected source(s) with one of the
[INFO] following sync modes to recover from this problem:
[INFO] slow, refresh-from-server, refresh-from-client
[INFO]
[INFO] Analyzing the current state:
[INFO] syncevolution --status memotoo addressbook calendar memo
[INFO]
[INFO] Running with one of the three modes:
[INFO] syncevolution --sync [slow|refresh-from-remote|refresh-from-local] memotoo
addressbook calendar memo
Please follow these instructions and then report back. SyncEvolution is
always going to stop like this in your current state unless you tell it
otherwise, which is intentional.
--
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.
8:04 a.m.
Le mercredi 27 mai 2015 à 12:45 +0200, Patrick Ohly a écrit :
On Wed, 2015-05-27 at 11:50 +0200, Daniel CLEMENT wrote:
> [...]
> [INFO]
> [INFO] Analyzing the current state:
> [INFO] syncevolution --status memotoo addressbook calendar memo
> [INFO]
> [INFO] Running with one of the three modes:
> [INFO] syncevolution --sync [slow|refresh-from-remote|refresh-from-local]
memotoo addressbook calendar memo
Please follow these instructions and then report back. SyncEvolution is
always going to stop like this in your current state unless you tell it
otherwise, which is intentional.
Yes, I've seen and tried this (full outputs below)
1) -- status (says that no comparison is possible)
2) -- sync slow : seems to complain about an offending contact called
Pioneer
3) --sync refresh-from-remote : more or less the same result.
It stills stops at this particular contact even after I deleted it on
the server.
daniel@e6330d ~ $ syncevolution --status memotoo addressbook calendar
memo
[INFO] calendar+todo: inactive
[INFO] todo: inactive
[INFO] Local item changes:
[INFO]
+---------------------------------------------|-----------------------+
[INFO] | Source | NEW | MOD | DEL |
TOTAL|
[INFO]
+---------------------------------------------+-----+-----+-----+-----+
[INFO] | addressbook | 0 | 0 | 0 |
283 |
[INFO]
+---------------------------------------------+-----+-----+-----+-----+
[INFO] | calendar | 0 | 0 | 0 |
1978 |
[INFO]
+---------------------------------------------+-----+-----+-----+-----+
[INFO] | memo | 0 | 0 | 0 |
19 |
[INFO]
+---------------------------------------------+-----+-----+-----+-----+
[INFO] | start Wed May 27 13:38:28 2015, duration 0:01min
|
[INFO]
+---------------------------------------------+-----+-----+-----+-----+
Local data changes to be applied remotely during synchronization:
*** addressbook ***
Comparison was impossible.
*** calendar ***
Comparison was impossible.
*** memo ***
Comparison was impossible.
-----
daniel@e6330d ~ $ syncevolution --sync slow memotoo addressbook calendar
memo[INFO] calendar+todo: inactive
[INFO] todo: inactive
[INFO] addressbook: starting first time sync from server (peer is
server)
[INFO] calendar: starting first time sync from server (peer is server)
[INFO] memo: starting first time sync from server (peer is server)
[INFO] creating complete data backup of datastore addressbook before
sync (enabled with dumpData and needed for printChanges)
Local data changes to be applied during synchronization:
*** addressbook ***
Comparison was impossible.
[INFO] addressbook: deleting "Pioneer"
[ERROR] addressbook: error code from SyncEvolution fatal error (local,
status 10500): addressbook: deleting contact pas-id-5532AC2B00000000:
FOREIGN KEY constraint failed
[INFO] creating complete data backup of datastore calendar before sync
(enabled with dumpData and needed for printChanges)
*** calendar ***
Comparison was impossible.
[INFO] addressbook: deleting 1/283
[INFO] addressbook: first time sync done unsuccessfully
[ERROR] addressbook: local, status 10508
[INFO] calendar: first time sync done unsuccessfully
[ERROR] calendar: local, status 10508
[INFO] memo: first time sync done unsuccessfully
[ERROR] memo: local, status 10508
[ERROR] error code from Synthesis engine local, status 10508
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed,
see /home/daniel/.cache/syncevolution/memotoo-2015-05-27-13-40/syncevolution-log.html for
details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 283 before sync, 283 after it |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 1978 before sync, 1978 after it |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Wed May 27 13:40:58 2015, duration 0:20min |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: error code from SyncEvolution fatal error
(local, status 10500): addressbook: deleting contact
pas-id-5532AC2B00000000: FOREIGN KEY constraint failed
Data modified locally during synchronization:
*** addressbook ***
no changes
*** calendar ***
no changes
-----
[1]daniel@e6330d ~ $ syncevolution --sync refresh-from-remote memotoo
addressbook calendar memo
[INFO] calendar+todo: inactive
[INFO] todo: inactive
[INFO] addressbook: starting first time sync from server (peer is
server)
[INFO] calendar: starting first time sync from server (peer is server)
[INFO] memo: starting first time sync from server (peer is server)
[INFO] creating complete data backup of datastore addressbook before
sync (enabled with dumpData and needed for printChanges)
Local data changes to be applied during synchronization:
*** addressbook ***
no changes
[INFO] addressbook: deleting "Pioneer"
[ERROR] addressbook: error code from SyncEvolution fatal error (local,
status 10500): addressbook: deleting contact pas-id-5532AC2B00000000:
FOREIGN KEY constraint failed
[INFO] creating complete data backup of datastore calendar before sync
(enabled with dumpData and needed for printChanges)
*** calendar ***
no changes
[INFO] addressbook: deleting 1/283
[INFO] addressbook: first time sync done unsuccessfully
[ERROR] addressbook: local, status 10508
[INFO] calendar: first time sync done unsuccessfully
[ERROR] calendar: local, status 10508
[INFO] memo: first time sync done unsuccessfully
[ERROR] memo: local, status 10508
[ERROR] error code from Synthesis engine local, status 10508
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed,
see /home/daniel/.cache/syncevolution/memotoo-2015-05-27-13-48/syncevolution-log.html for
details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 283 before sync, 283 after it |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 1978 before sync, 1978 after it |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Wed May 27 13:48:56 2015, duration 0:20min |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: error code from SyncEvolution fatal error
(local, status 10500): addressbook: deleting contact
pas-id-5532AC2B00000000: FOREIGN KEY constraint failed
Data modified locally during synchronization:
*** addressbook ***
no changes
*** calendar ***
no changes
--
Daniel CLEMENT
8:53 a.m.
On Wed, 2015-05-27 at 14:04 +0200, Daniel CLEMENT wrote:
[INFO] addressbook: deleting "Pioneer"
[ERROR] addressbook: error code from SyncEvolution fatal error (local,
status 10500): addressbook: deleting contact pas-id-5532AC2B00000000:
FOREIGN KEY constraint failed
[INFO] creating complete data backup of datastore calendar before sync
(enabled with dumpData and needed for printChanges)
*** calendar ***
Comparison was impossible.
Looks like your local EDS database got corrupted during the distro
upgrade. Can you report this to the distro and/or Evolution developers?
As you have all your data on the remote server, you can recover from
this by shutting down Evolution, removing the local address book
(somewhere under ~/.local/share/evolution) and syncing from the server.
--
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.
10:44 a.m.
On Wed, 2015-05-27 at 14:53 +0200, Patrick Ohly wrote:
On Wed, 2015-05-27 at 14:04 +0200, Daniel CLEMENT wrote:
> FOREIGN KEY constraint failed
Hi,
that was a bug in the address book code in evolution-data-server,
see [1] for more information.
Bye,
Milan
[1] https://bugzilla.gnome.org/show_bug.cgi?id=743996
11:02 a.m.
On Wed, 2015-05-27 at 16:44 +0200, Milan Crha wrote:
On Wed, 2015-05-27 at 14:53 +0200, Patrick Ohly wrote:
> On Wed, 2015-05-27 at 14:04 +0200, Daniel CLEMENT wrote:
> > FOREIGN KEY constraint failed
Hi,
that was a bug in the address book code in evolution-data-server,
see [1] for more information.
Bye,
Milan
[1] https://bugzilla.gnome.org/show_bug.cgi?id=743996
Ah, thanks a lot Milan.
The workaround in https://bugzilla.gnome.org/show_bug.cgi?id=743996#c16
may be useful for users who do not have the chance to get a patched EDS
binary.
--
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 a.m.
Le mercredi 27 mai 2015 à 14:53 +0200, Patrick Ohly a écrit :
On Wed, 2015-05-27 at 14:04 +0200, Daniel CLEMENT wrote:
> [INFO] addressbook: deleting "Pioneer"
> [ERROR] addressbook: error code from SyncEvolution fatal error (local,
> status 10500): addressbook: deleting contact pas-id-5532AC2B00000000:
> FOREIGN KEY constraint failed
> [INFO] creating complete data backup of datastore calendar before sync
> (enabled with dumpData and needed for printChanges)
> *** calendar ***
> Comparison was impossible.
Looks like your local EDS database got corrupted during the distro
upgrade.
Certainly, even manual deletion of the above contact failed with
"FOREIGN KEY constraint failed".
Can you report this to the distro and/or Evolution developers?
I'll do it ASAP.
As you have all your data on the remote server, you can recover from
this by shutting down Evolution, removing the local address book
(somewhere under ~/.local/share/evolution) and syncing from the server.
Hmm... This did work for the address book, but alas not for the calendar
and the memos.
I tried and deleted ~/.local/share/evolution/memos/system/journal.ics
(or /.local/share/evolution/calendar/system/calendar.ics) like I had
done for /.local/share/evolution/addressbook/system/contacts.db.
Then e.g.
syncevolution --sync refresh-from-remote memotoo memo
gives me an error code 10508:
[1]daniel@e6330d ~ $ syncevolution --sync refresh-from-remote memotoo
memo
[INFO] addressbook: inactive
[INFO] calendar: inactive
[INFO] calendar+todo: inactive
[INFO] todo: inactive
[INFO] memo: starting first time sync from server (peer is server)
[INFO] creating complete data backup of datastore memo before sync
(enabled with dumpData and needed for printChanges)
Local data changes to be applied during synchronization:
*** memo ***
no changes
[INFO] memo: first time sync done unsuccessfully
[ERROR] memo: local, status 10508
[ERROR] error code from Synthesis engine local, status 10508
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed,
see /home/daniel/.cache/syncevolution/memotoo-2015-05-27-16-57/syncevolution-log.html for
details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 19 before sync, 19 after it |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Wed May 27 16:57:50 2015, duration 0:01min |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: local, status 10508
Data modified locally during synchronization:
*** memo ***
no changes
--
Daniel CLEMENT
11:10 a.m.
On Wed, 2015-05-27 at 17:00 +0200, Daniel CLEMENT wrote:
Le mercredi 27 mai 2015 à 14:53 +0200, Patrick Ohly a écrit :
> On Wed, 2015-05-27 at 14:04 +0200, Daniel CLEMENT wrote:
> > [INFO] addressbook: deleting "Pioneer"
> > [ERROR] addressbook: error code from SyncEvolution fatal error (local,
> > status 10500): addressbook: deleting contact pas-id-5532AC2B00000000:
> > FOREIGN KEY constraint failed
> > [INFO] creating complete data backup of datastore calendar before sync
> > (enabled with dumpData and needed for printChanges)
> > *** calendar ***
> > Comparison was impossible.
>
> Looks like your local EDS database got corrupted during the distro
> upgrade.
Certainly, even manual deletion of the above contact failed with
"FOREIGN KEY constraint failed".
> Can you report this to the distro and/or Evolution developers?
I'll do it ASAP.
Not necessary anymore, as Milan pointed out, it is a known (and fixed)
issue.
Hmm... This did work for the address book, but alas not for the
calendar
and the memos.
I tried and deleted ~/.local/share/evolution/memos/system/journal.ics
(or /.local/share/evolution/calendar/system/calendar.ics) like I had
done for /.local/share/evolution/addressbook/system/contacts.db.
Then e.g.
syncevolution --sync refresh-from-remote memotoo memo
gives me an error code 10508:
[1]daniel@e6330d ~ $ syncevolution --sync refresh-from-remote memotoo
memo
[INFO] addressbook: inactive
[INFO] calendar: inactive
[INFO] calendar+todo: inactive
[INFO] todo: inactive
[INFO] memo: starting first time sync from server (peer is server)
[INFO] creating complete data backup of datastore memo before sync
(enabled with dumpData and needed for printChanges)
Local data changes to be applied during synchronization:
*** memo ***
no changes
[INFO] memo: first time sync done unsuccessfully
[ERROR] memo: local, status 10508
[ERROR] error code from Synthesis engine local, status 10508
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed,
see /home/daniel/.cache/syncevolution/memotoo-2015-05-27-16-57/syncevolution-log.html for
details.
What further details does that file have about the 508 error?
--
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:21 a.m.
Le mercredi 27 mai 2015 à 17:10 +0200, Patrick Ohly a écrit :
On Wed, 2015-05-27 at 17:00 +0200, Daniel CLEMENT wrote:
> [...]
>
> > Can you report this to the distro and/or Evolution developers?
>
> I'll do it ASAP.
Not necessary anymore, as Milan pointed out, it is a known (and fixed)
issue.
Yes, I saw Milan's post (thanks!) just when I was sending mine.
> Hmm... This did work for the address book, but alas not for the calendar
> and the memos.
>
> I tried and deleted ~/.local/share/evolution/memos/system/journal.ics
> (or /.local/share/evolution/calendar/system/calendar.ics) like I had
> done for /.local/share/evolution/addressbook/system/contacts.db.
>
> Then e.g.
> syncevolution --sync refresh-from-remote memotoo memo
> gives me an error code 10508:
>
> [...]
What further details does that file have about the 508 error?
Below is the end of the log file, from the point where the 508 error
appears:
-----
–
[2015-05-27 16:57:51.582] 'SessionAbort' - Aborting Session, Status=508,
ProblemSource=LOCAL [--][++] [->end] [->enclosing]
[2015-05-27 16:57:51.582] WARNING: Aborting Session with Reason
Status 508 (LOCAL problem) ***
[2015-05-27 16:57:51.582] --------------- Ignoring all commands in
this message (after 0 sec. request processing, 0 sec. total) with Status
514 (0=none) from here on
–
[2015-05-27 16:57:51.582] 'DSAbort' - Aborting datastore sync,
abortStatusCode=508, localProblem=yes, resumable=yes [--][++] [->end]
[->enclosing]
–
[2015-05-27 16:57:51.582] 'SaveSuspendState' - Saving state for
suspend/resume, datastore=memo [--][++] [->end] [->enclosing]
+
[2015-05-27 16:57:51.582] 'SaveResumeMarks' - let
implementation save resume info, datastore=memo [--][++] [->end]
[->enclosing]
–[2015-05-27 16:57:51.582] End of 'SaveSuspendState' [->top]
[->enclosing]
[2015-05-27 16:57:51.582] *************** Warning: Datastore
flagged aborted (after 0 sec. request processing, 0 sec. total) with
LOCAL Status 508
–[2015-05-27 16:57:51.582] End of 'DSAbort' [->top] [->enclosing]
–[2015-05-27 16:57:51.582] End of 'SessionAbort' [->top] [->enclosing]
–
[2015-05-27 16:57:51.582] 'DSStateChange' - Datastore changes state,
datastore=memo, oldstate=sync_mode_stable, newstate=completed [--][++]
[->end] [->enclosing]
[2015-05-27 16:57:51.582] Sync Statistics for 'memo' (./memo), slow
sync
[2015-05-27 16:57:51.582]
==================================================
on Client on Server
Added: 0 0
Deleted: 0 0
Updated: 0 0
Rejected with error: 0 0
Content Data Bytes sent: 0
Content Data Bytes received: 0
Duration of sync [seconds]: 0
[2015-05-27 16:57:51.582] Warning: Failed with status code=508,
statistics are incomplete!!
–[2015-05-27 16:57:51.582] End of 'DSStateChange' [->top] [->enclosing]
–
[2015-05-27 16:57:51.582] 'DSStateChange' - Datastore changes state,
datastore=memo, oldstate=completed, newstate=idle [--][++] [->end]
[->enclosing]
[2015-05-27 16:57:51.582] endDataWrite called, write not started
–[2015-05-27 16:57:51.583] End of 'DSStateChange' [->top] [->enclosing]
[2015-05-27 16:57:51.583] DeleteContext
[2015-05-27 16:57:51.583] Never received status for command 'SyncHdr',
(outgoing MsgID=2, CmdID=0)
[2015-05-27 16:57:51.583] Deleted command 'SyncHdr' (outgoing MsgID=2,
CmdID=0)
[2015-05-27 16:57:51.583] Deleted command 'Status' (outgoing MsgID=0,
CmdID=0)
[2015-05-27 16:57:51.583] memo: first time sync done unsuccessfully
[2015-05-27 16:57:51.583] local, status 10508
[2015-05-27 16:57:51.584] error code from Synthesis engine local, status
10508
[2015-05-27 16:57:51.584] aborting after catching fatal error
[2015-05-27 16:57:51.584] closing session
[2015-05-27 16:57:51.584] --------- END of embedded log for session ID
'212299541870833' ---------
[2015-05-27 16:57:51.584] session closed
--
Daniel CLEMENT
11:34 a.m.
On Wed, 2015-05-27 at 17:21 +0200, Daniel CLEMENT wrote:
> > Then e.g.
> > syncevolution --sync refresh-from-remote memotoo memo
> > gives me an error code 10508:
> >
> > [...]
>
> What further details does that file have about the 508 error?
>
Below is the end of the log file, from the point where the 508 error
appears:
-----
–
[2015-05-27 16:57:51.582] 'SessionAbort' - Aborting Session,
Status=508,
ProblemSource=LOCAL [--][++] [->end] [->enclosing]
What's above it? That's where the real issue should be logged. You may
have to run with loglevel=4 to see more.
--
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:51 a.m.
Le mercredi 27 mai 2015 à 17:34 +0200, Patrick Ohly a écrit :
On Wed, 2015-05-27 at 17:21 +0200, Daniel CLEMENT wrote:
> > > Then e.g.
> > > syncevolution --sync refresh-from-remote memotoo memo
> > > gives me an error code 10508:
> > >
> > > [...]
> >
> > What further details does that file have about the 508 error?
> >
>
> Below is the end of the log file, from the point where the 508 error
> appears:
> -----
> –
> [2015-05-27 16:57:51.582] 'SessionAbort' - Aborting Session,
> Status=508,
> ProblemSource=LOCAL [--][++] [->end] [->enclosing]
What's above it? That's where the real issue should be logged. You may
have to run with loglevel=4 to see more.
Hope I didn't mess up the command line, here is what I did:
syncevolution --run loglevel@memotoo=4 --sync refresh-from-remote
memotoo memo
I'm attaching the log file (the copy/paste doesn't look good in plain
text).
--
Daniel CLEMENT
4:01 a.m.
On Wed, 2015-05-27 at 17:51 +0200, Daniel CLEMENT wrote:
Le mercredi 27 mai 2015 à 17:34 +0200, Patrick Ohly a écrit :
> On Wed, 2015-05-27 at 17:21 +0200, Daniel CLEMENT wrote:
> > > > Then e.g.
> > > > syncevolution --sync refresh-from-remote memotoo memo
> > > > gives me an error code 10508:
> > > >
> > > > [...]
> > >
> > > What further details does that file have about the 508 error?
> > >
> >
> > Below is the end of the log file, from the point where the 508 error
> > appears:
> > -----
> > –
> > [2015-05-27 16:57:51.582] 'SessionAbort' - Aborting Session,
> > Status=508,
> > ProblemSource=LOCAL [--][++] [->end] [->enclosing]
>
> What's above it? That's where the real issue should be logged. You may
> have to run with loglevel=4 to see more.
>
Hope I didn't mess up the command line, here is what I did:
syncevolution --run loglevel@memotoo=4 --sync refresh-from-remote
memotoo memo
I'm attaching the log file (the copy/paste doesn't look good in plain
text).
Reading calendar items seems to fail, with no obvious error logging at
all.
Does "LD_DEBUG=1 syncevolution --daemon=no --print-items memotoo memo"
show anything? Do you have memos locally?
Do you perhaps still have obsolete EDS libraries installed?
Try this:
for i in /usr/lib/syncevolution/backends/syncecal*.so; do echo $i; if ldd $i | grep -q
"not found"; then echo " unusable"; else echo " usable";
fi; done
syncevolution --daemon=no --version
On my own Debian installation, I somehow ended up with syncecal-4.so and
syncecal-5.so as usable. syncecal-5.so is the version which gets picked,
which happens to match libecal-1.2.so.16 because both use libical.so.1.
syncecal-4.so is usable because I had an obsolete libical.so.0 installed
which wasn't used anymore by anything and could be removed.
--
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:22 a.m.
Le jeudi 28 mai 2015 à 10:01 +0200, Patrick Ohly a écrit :
[...]
> >
> Hope I didn't mess up the command line, here is what I did:
> syncevolution --run loglevel@memotoo=4 --sync refresh-from-remote
> memotoo memo
>
> I'm attaching the log file (the copy/paste doesn't look good in plain
> text).
Reading calendar items seems to fail, with no obvious error logging at
all.
Memos "almost" worked. I erased
~/.local/share/evolution/memos/system/journal.ics and then I could
perform a refresh-from-remote sync, only for memos, which successfully
recreated the above file. But the subsequent attempts failed.
And I could not do the same with the calendar.ics file.
Does "LD_DEBUG=1 syncevolution --daemon=no --print-items memotoo memo"
show anything?
The result looks correct:
daniel@e6330d ~ $ LD_DEBUG=1 syncevolution --daemon=no --print-items
memotoo memo
warning: debug option `1' unknown; try LD_DEBUG=help
syuid131753%2e212299596272388-rid: Logitech Harmony :
syuid247279%2e212299596272398-rid: NUMEN :
syuid295660%2e212299596272393-rid: Livres
syuid408817%2e212299596272365-rid: E-mail jetable
syuid409316%2e212299596272406-rid: Quickstep
syuid458695%2e212299596272416-rid: Naissance Parents :
syuid633486%2e212299596272346-rid: Clés autos
syuid696773%2e212299596272358-rid: Caractéristiques de ...
syuid697395%2e212299596272441-rid: Papier peint
syuid699214%2e212299596272383-rid: Courbes périlleuses
syuid771910%2e212299596272378-rid: Piles montres
syuid781737%2e212299596272412-rid: Films à rechercher :
syuid797248%2e212299596272420-rid: Scolinfo
syuid806450%2e212299596272424-rid: e-CB
syuid836056%2e212299596272372-rid: Pour les lavabos :
syuid898450%2e212299596272428-rid: MAIF (sinistres) :
syuid916864%2e212299596272436-rid: Livres
syuid941545%2e212299596272402-rid: Diagral :
syuid951393%2e212299596272432-rid: Adresse plan Google
Do you have memos locally?
Yes, they match the above list.
Do you perhaps still have obsolete EDS libraries installed?
Quite possible, at least because at first I was using the Debian
repository, before adding the Syncevolution repository.
Try this:
for i in /usr/lib/syncevolution/backends/syncecal*.so; do echo $i; if ldd $i | grep -q
"not found"; then echo " unusable"; else echo " usable";
fi; done
syncevolution --daemon=no --version
daniel@e6330d ~ $ for i in /usr/lib/syncevolution/backends/syncecal*.so;
do echo $i; if ldd $i | grep -q "not found"; then echo " unusable";
else echo " usable"; fi; done
/usr/lib/syncevolution/backends/syncecal-2.so
usable
/usr/lib/syncevolution/backends/syncecal-3.so
usable
/usr/lib/syncevolution/backends/syncecal-4.so
usable
/usr/lib/syncevolution/backends/syncecal-5.so
usable
/usr/lib/syncevolution/backends/syncecal.so
usable
It makes a whole lot, though everything is "usable". Could it be the
problem? Should I do some cleanup there?
On my own Debian installation, I somehow ended up with syncecal-4.so and
syncecal-5.so as usable. syncecal-5.so is the version which gets picked,
which happens to match libecal-1.2.so.16 because both use libical.so.1.
syncecal-4.so is usable because I had an obsolete libical.so.0 installed
which wasn't used anymore by anything and could be removed.
To be precise, I am running Linux Mint Debian, which is now (after the
upgrade) identical to Debian Stable (aka Jessie now), except for some
Mint-desktop specific packages. For all the Gnome stuff like Evolution,
there is no difference.
--
Daniel CLEMENT
5:26 a.m.
On Thu, 2015-05-28 at 11:22 +0200, Daniel CLEMENT wrote:
Le jeudi 28 mai 2015 à 10:01 +0200, Patrick Ohly a écrit :
> Try this:
>
> for i in /usr/lib/syncevolution/backends/syncecal*.so; do echo $i; if ldd $i | grep
-q "not found"; then echo " unusable"; else echo "
usable"; fi; done
> syncevolution --daemon=no --version
daniel@e6330d ~ $ for i in /usr/lib/syncevolution/backends/syncecal*.so;
do echo $i; if ldd $i | grep -q "not found"; then echo "
unusable";
else echo " usable"; fi; done
/usr/lib/syncevolution/backends/syncecal-2.so
usable
/usr/lib/syncevolution/backends/syncecal-3.so
usable
/usr/lib/syncevolution/backends/syncecal-4.so
usable
/usr/lib/syncevolution/backends/syncecal-5.so
usable
/usr/lib/syncevolution/backends/syncecal.so
usable
It makes a whole lot, though everything is "usable". Could it be the
problem? Should I do some cleanup there?
It would be a good start. Something is messed up in your EDS
installation if you can create the memo.ics file, but then not read it
again.
--
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.
6:19 a.m.
Le jeudi 28 mai 2015 à 11:26 +0200, Patrick Ohly a écrit :
On Thu, 2015-05-28 at 11:22 +0200, Daniel CLEMENT wrote:
> Le jeudi 28 mai 2015 à 10:01 +0200, Patrick Ohly a écrit :
> > Try this:
> >
> > for i in /usr/lib/syncevolution/backends/syncecal*.so; do echo $i; if ldd $i |
grep -q "not found"; then echo " unusable"; else echo "
usable"; fi; done
> > syncevolution --daemon=no --version
>
> daniel@e6330d ~ $ for i in /usr/lib/syncevolution/backends/syncecal*.so;
> do echo $i; if ldd $i | grep -q "not found"; then echo "
unusable";
> else echo " usable"; fi; done
> /usr/lib/syncevolution/backends/syncecal-2.so
> usable
> /usr/lib/syncevolution/backends/syncecal-3.so
> usable
> /usr/lib/syncevolution/backends/syncecal-4.so
> usable
> /usr/lib/syncevolution/backends/syncecal-5.so
> usable
> /usr/lib/syncevolution/backends/syncecal.so
> usable
>
> It makes a whole lot, though everything is "usable". Could it be the
> problem? Should I do some cleanup there?
It would be a good start. Something is messed up in your EDS
installation if you can create the memo.ics file, but then not read it
again.
Hmm... I could check that all of the above libraries are part of the
syncevolution-bundle package, which of course I want to keep. So I
manually erased syncecal-2, -3 and-4.so, then:
daniel@e6330d ~ $ syncevolution --run loglevel@memotoo=4 --sync
refresh-from-remote memotoo calendar
did start, but gave tons of errors like the one below:
[INFO] calendar: adding "Heures de colles"
[ERROR] calendar: error code from SyncEvolution fatal error (local,
status 10500): calendar: need non-empty LUID and revision string
(in fact one such error for each calendar item as far as I could check),
and the command failed to complete, I had to interrupt it manually.
After that, I have a calendar.ics file (which I had erased), but I can't
see it in Evolution.
--
Daniel CLEMENT
6:36 a.m.
On Thu, 2015-05-28 at 12:19 +0200, Daniel CLEMENT wrote:
Le jeudi 28 mai 2015 à 11:26 +0200, Patrick Ohly a écrit :
> On Thu, 2015-05-28 at 11:22 +0200, Daniel CLEMENT wrote:
> > Le jeudi 28 mai 2015 à 10:01 +0200, Patrick Ohly a écrit :
> > > Try this:
> > >
> > > for i in /usr/lib/syncevolution/backends/syncecal*.so; do echo $i; if ldd
$i | grep -q "not found"; then echo " unusable"; else echo "
usable"; fi; done
> > > syncevolution --daemon=no --version
> >
> > daniel@e6330d ~ $ for i in /usr/lib/syncevolution/backends/syncecal*.so;
> > do echo $i; if ldd $i | grep -q "not found"; then echo "
unusable";
> > else echo " usable"; fi; done
> > /usr/lib/syncevolution/backends/syncecal-2.so
> > usable
> > /usr/lib/syncevolution/backends/syncecal-3.so
> > usable
> > /usr/lib/syncevolution/backends/syncecal-4.so
> > usable
> > /usr/lib/syncevolution/backends/syncecal-5.so
> > usable
> > /usr/lib/syncevolution/backends/syncecal.so
> > usable
> >
> > It makes a whole lot, though everything is "usable". Could it be the
> > problem? Should I do some cleanup there?
>
> It would be a good start. Something is messed up in your EDS
> installation if you can create the memo.ics file, but then not read it
> again.
Hmm... I could check that all of the above libraries are part of the
syncevolution-bundle package, which of course I want to keep.
That's not what I meant. When you run
"ldd /usr/lib/syncevolution/backends/syncecal-3.so | grep ecal" it will
point you to a libecal version that belongs to an obsolete EDS.
Check in aptitude under "obsolete" packages, or use "dpkg -S" to
locate
the owner of that libecal*.so*. Get rid of those.
Same for all other obsolete /usr/lib/libe*.*so* files.
--
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.
10:01 a.m.
Le jeudi 28 mai 2015 à 12:36 +0200, Patrick Ohly a écrit :
[...]That's not what I meant. When you run
"ldd /usr/lib/syncevolution/backends/syncecal-3.so | grep ecal" it will
point you to a libecal version that belongs to an obsolete EDS.
Check in aptitude under "obsolete" packages, or use "dpkg -S" to
locate
the owner of that libecal*.so*. Get rid of those.
It pointed me to libecal-1.2-15, which was from the old (3.8) version. I
guess it was not removed by the upgrade because the new (3.12) has a
different name (libecal-1.2-16).
Same for all other obsolete /usr/lib/libe*.*so* files.
I checked carefully and I had to suppress 4 more:
libedata-cal-1.2-20
libebackend-1.2-6
libedatabook-1.2-17
libedataserver-1.2-17
for which the newer version also has a different name.
I confirmed with a search for version in Synaptic that all my
Evolution-related packages are from the 3.12 now.
But I still cant sync. Still this error code 508, e.g. the memos:
-----
daniel@e6330d ~ $ syncevolution --run loglevel@memotoo=4 --sync
refresh-from-remote memotoo memo
[INFO] addressbook: inactive
[INFO] calendar: inactive
[INFO] calendar+todo: inactive
[INFO] todo: inactive
[INFO] memo: starting first time sync from server (peer is server)
[INFO] creating complete data backup of datastore memo before sync
(enabled with dumpData and needed for printChanges)
Local data changes to be applied during synchronization:
*** memo ***
no changes
[INFO] memo: first time sync done unsuccessfully
[ERROR] memo: local, status 10508
[ERROR] error code from Synthesis engine local, status 10508
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed,
see /home/daniel/.cache/syncevolution/memotoo-2015-05-28-15-41/syncevolution-log.html for
details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| memo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 19 before sync, 19 after it |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Thu May 28 15:41:54 2015, duration 0:01min |
| local, status 10508 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: local, status 10508
Data modified locally during synchronization:
*** memo ***
no changes
-----
From the log file:
-----
[2015-05-28 15:41:55.123] StartDataRead last='' resume=''
res=508
[2015-05-28 15:41:55.124] DBapi::StartDataRead fatal error: 508
–[2015-05-28 15:41:55.124] End of 'ReadSyncSet' [->top]
[->enclosing]
–[2015-05-28 15:41:55.124] End of 'DSStateChange' [->top] [->enclosing]
–
[2015-05-28 15:41:55.124] 'SessionAbort' - Aborting Session, Status=508,
ProblemSource=LOCAL [--][++] [->end] [->enclosing]
[2015-05-28 15:41:55.124] WARNING: Aborting Session with Reason
Status 508 (LOCAL problem) ***
--
Daniel CLEMENT
11:24 a.m.
On Thu, 2015-05-28 at 16:01 +0200, Daniel CLEMENT wrote:
Le jeudi 28 mai 2015 à 12:36 +0200, Patrick Ohly a écrit :
> [...]That's not what I meant. When you run
> "ldd /usr/lib/syncevolution/backends/syncecal-3.so | grep ecal" it will
> point you to a libecal version that belongs to an obsolete EDS.
>
> Check in aptitude under "obsolete" packages, or use "dpkg -S" to
locate
> the owner of that libecal*.so*. Get rid of those.
It pointed me to libecal-1.2-15, which was from the old (3.8) version. I
guess it was not removed by the upgrade because the new (3.12) has a
different name (libecal-1.2-16).
>
> Same for all other obsolete /usr/lib/libe*.*so* files.
>
I checked carefully and I had to suppress 4 more:
libedata-cal-1.2-20
libebackend-1.2-6
libedatabook-1.2-17
libedataserver-1.2-17
for which the newer version also has a different name.
What about libical?
I confirmed with a search for version in Synaptic that all my
Evolution-related packages are from the 3.12 now.
But I still cant sync.
Can you create and later read memos via the Evolution UI? Can you do the
--print-items of those with the SyncEvolution command line? There's no
point trying to sync if that already fails.
Can you check whether your memo storage is really the local storage? In
other words, your .config/evolution/sources/ file with "Memo List"
inside should have BackendName=local.
--
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:20 p.m.
Le jeudi 28 mai 2015 à 17:24 +0200, Patrick Ohly a écrit :
On Thu, 2015-05-28 at 16:01 +0200, Daniel CLEMENT wrote:
> Le jeudi 28 mai 2015 à 12:36 +0200, Patrick Ohly a écrit :
> > [...]That's not what I meant. When you run
> > "ldd /usr/lib/syncevolution/backends/syncecal-3.so | grep ecal" it
will
> > point you to a libecal version that belongs to an obsolete EDS.
> >
> > Check in aptitude under "obsolete" packages, or use "dpkg
-S" to locate
> > the owner of that libecal*.so*. Get rid of those.
>
> It pointed me to libecal-1.2-15, which was from the old (3.8) version. I
> guess it was not removed by the upgrade because the new (3.12) has a
> different name (libecal-1.2-16).
> >
> > Same for all other obsolete /usr/lib/libe*.*so* files.
> >
> I checked carefully and I had to suppress 4 more:
> libedata-cal-1.2-20
> libebackend-1.2-6
> libedatabook-1.2-17
> libedataserver-1.2-17
> for which the newer version also has a different name.
What about libical?
I had a look at it too. I have libical0 v. 0.48-2 (which is in the
dependencies of Syncevolution-bundle) and libical1a v. 1.0-1.3
(dependency of Evolution).
> I confirmed with a search for version in Synaptic that all my
> Evolution-related packages are from the 3.12 now.
>
> But I still cant sync.
Can you create and later read memos via the Evolution UI?
Yes. Here's a sample memo called "test" which I added. I mention it for
comparison with what follows. It looks like that in journal.ics:
-----
BEGIN:VJOURNAL
UID:20150528T153358Z-3805-1000-3269-0@e6330d
DTSTAMP:20150528T152917Z
SUMMARY:Test
DESCRIPTION:memo test
DTSTART;VALUE=DATE:20150528
CLASS:PUBLIC
SEQUENCE:1
CREATED:20150528T153409Z
LAST-MODIFIED:20150528T153409Z
END:VJOURNAL
-----
Can you do the
--print-items of those with the SyncEvolution command line?
Yes but there's perhaps something strange:
-----
daniel@e6330d ~ $ LD_DEBUG=1 syncevolution --daemon=no --print-items
local memo
warning: debug option `1' unknown; try LD_DEBUG=help
20150528T153358Z-3805-1000-3269-0%40e6330d-rid: Test
syuid032069%2e212299623336289-rid: Adresse plan Google
[... other memos...]
-----
Al memos but the one just created begin with "syuid". (I assume this
means they've been synced, instead of created locally on this PC.)
There's no
point trying to sync if that already fails.
Can you check whether your memo storage is really the local storage? In
other words, your .config/evolution/sources/ file with "Memo List"
inside should have BackendName=local.
I could not locate any file in this folder with "Memo List" inside. The
same is true on my main PC. So I searched for "BackendName=local"
instead, and I got only 2 relevant results:
- system-calendar.source
- system-address-book.source
So no trace of memos. OTTH if syncevolution --print-items finds them I
guess it should be OK...
--
Daniel CLEMENT
9:26 a.m.
On Thu, 2015-05-28 at 18:20 +0200, Daniel CLEMENT wrote:
Le jeudi 28 mai 2015 à 17:24 +0200, Patrick Ohly a écrit :
> On Thu, 2015-05-28 at 16:01 +0200, Daniel CLEMENT wrote:
> > Le jeudi 28 mai 2015 à 12:36 +0200, Patrick Ohly a écrit :
> > > [...]That's not what I meant. When you run
> > > "ldd /usr/lib/syncevolution/backends/syncecal-3.so | grep ecal"
it will
> > > point you to a libecal version that belongs to an obsolete EDS.
> > >
> > > Check in aptitude under "obsolete" packages, or use "dpkg
-S" to locate
> > > the owner of that libecal*.so*. Get rid of those.
> >
> > It pointed me to libecal-1.2-15, which was from the old (3.8) version. I
> > guess it was not removed by the upgrade because the new (3.12) has a
> > different name (libecal-1.2-16).
> > >
> > > Same for all other obsolete /usr/lib/libe*.*so* files.
> > >
> > I checked carefully and I had to suppress 4 more:
> > libedata-cal-1.2-20
> > libebackend-1.2-6
> > libedatabook-1.2-17
> > libedataserver-1.2-17
> > for which the newer version also has a different name.
>
> What about libical?
I had a look at it too. I have libical0 v. 0.48-2 (which is in the
dependencies of Syncevolution-bundle) and libical1a v. 1.0-1.3
(dependency of Evolution).
I'm not sure whether it matters, but to be on the safe side, please also
remove libical0. The bundle depends on one or the other.
Yes but there's perhaps something strange:
-----
daniel@e6330d ~ $ LD_DEBUG=1 syncevolution --daemon=no --print-items
local memo
warning: debug option `1' unknown; try LD_DEBUG=help
20150528T153358Z-3805-1000-3269-0%40e6330d-rid: Test
syuid032069%2e212299623336289-rid: Adresse plan Google
[... other memos...]
-----
Al memos but the one just created begin with "syuid". (I assume this
means they've been synced, instead of created locally on this PC.)
The syuid UIDs come from
src/syncevo/configs/scripting/10newuid.xml:
<function><![CDATA[
// create a UID
string newuid() {
return "syuid" + NUMFORMAT(RANDOM(1000000),6,"0") +
"." +
(string)MILLISECONDS(NOW());
}
]]></function>
This happens when the server doesn't send any UID although (ultimately)
iCalendar 2.0 requires it.
--
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.
10:44 a.m.
Le vendredi 29 mai 2015 à 15:26 +0200, Patrick Ohly a écrit :
[...]
> >
> > What about libical?
>
> I had a look at it too. I have libical0 v. 0.48-2 (which is in the
> dependencies of Syncevolution-bundle) and libical1a v. 1.0-1.3
> (dependency of Evolution).
I'm not sure whether it matters, but to be on the safe side, please also
remove libical0. The bundle depends on one or the other.
Hmm... It seems to depend on both: if I try to uninstall libical0 from
Synaptic, it wants to remove syncevolution-evolution and
syncevolution-bundle. So I don't go any further, because I assume that
if I suppress and then reinstall syncevolution-bundle, libical0 will get
reinstalled too.
OTTH, if I boldly remove manually the files installed by the package
libical0, that is:
libical.so.0
libical.so.0.48.0
libicalss.so.0
libicalss.so.0.48.0
libicalvcal.so.0
libicalvcal.so.0.48.0
(all from /usr/lib), then syncevo-dbus-server won't start and
syncevolution complains:
daniel@e6330d ~ $ syncevolution --sync refresh-from-remote memotoo memos
syncevolution: error while loading shared libraries: libical.so.0:
cannot open shared object file: No such file or directory
> Yes but there's perhaps something strange:
> -----
> daniel@e6330d ~ $ LD_DEBUG=1 syncevolution --daemon=no --print-items
> local memo
> warning: debug option `1' unknown; try LD_DEBUG=help
> 20150528T153358Z-3805-1000-3269-0%40e6330d-rid: Test
> syuid032069%2e212299623336289-rid: Adresse plan Google
> [... other memos...]
> -----
> Al memos but the one just created begin with "syuid". (I assume this
> means they've been synced, instead of created locally on this PC.)
The syuid UIDs come from
src/syncevo/configs/scripting/10newuid.xml:
<function><![CDATA[
// create a UID
string newuid() {
return "syuid" + NUMFORMAT(RANDOM(1000000),6,"0") +
"." +
(string)MILLISECONDS(NOW());
}
]]></function>
This happens when the server doesn't send any UID although (ultimately)
iCalendar 2.0 requires it.
So, nothing wrong with my journal.ics file.
--
Daniel CLEMENT
11:04 a.m.
On Fri, 2015-05-29 at 16:44 +0200, Daniel CLEMENT wrote:
daniel@e6330d ~ $ syncevolution --sync refresh-from-remote memotoo
memos
syncevolution: error while loading shared libraries: libical.so.0:
cannot open shared object file: No such file or directory
Which version of SyncEvolution is that?
1.5 does not link against libical.so.0 (ldd `which syncevolution ` |
grep libical).
However, Debian renamed libical1 into libical1a, and while I have
adapted the package of SyncEvolution to accomodate for that, that change
is not released yet. So your observation is right, currently
SyncEvolution pulls in libical0.
--
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:56 a.m.
Le vendredi 29 mai 2015 à 17:04 +0200, Patrick Ohly a écrit :
On Fri, 2015-05-29 at 16:44 +0200, Daniel CLEMENT wrote:
> daniel@e6330d ~ $ syncevolution --sync refresh-from-remote memotoo memos
> syncevolution: error while loading shared libraries: libical.so.0:
> cannot open shared object file: No such file or directory
Which version of SyncEvolution is that?
It's
syncevolution-evolution 1:1.5-1
syncevolution-bundle 1:1.5-2
but while the main (older) PC (the one I'm writing from) uses
http://downloads.syncevolution.org/apt/ (stable main)
the 2nd one (upgraded, which has problems) is set to
https://download.01.org/syncevolution/apt/ (stable main)...
1.5 does not link against libical.so.0 (ldd `which syncevolution ` |
grep libical).
... and the result of this command line gives different results:
(old PC) no output, which I assume is normal;
(upgraded PC)
daniel@e6330d ~ $ ldd `which syncevolution ` | grep libical
libical.so.0 => /usr/lib/libical.so.0 (0x00007f680aa6b000)
libicalss.so.0 => /usr/lib/libicalss.so.0 (0x00007f680a852000)
libicalvcal.so.0 => /usr/lib/libicalvcal.so.0 (0x00007f680a63c000)
and indeed if the result of syncevolution --version begins with
SyncEvolution 1.5
it continues slightly differently:
(old PC)
using libedataserver-1.2.so.16
using libecal-1.2.so.11
using libecal-1.2.so.11
using libbluetooth.so.3
(upgraded PC)
using libical.so.1
using libical.so.1
using libbluetooth.so.3
So this gives me the idea to set the Syncevolution repository to
http://downloads.syncevolution.org/apt/ on the new PC and reinstall both
syncevolution packages from there.
However, Debian renamed libical1 into libical1a, and while I have
adapted the package of SyncEvolution to accomodate for that, that change
is not released yet. So your observation is right, currently
SyncEvolution pulls in libical0.
--
Daniel CLEMENT
4:13 p.m.
On Fri, 2015-05-29 at 17:56 +0200, Daniel CLEMENT wrote:
Le vendredi 29 mai 2015 à 17:04 +0200, Patrick Ohly a écrit :
> On Fri, 2015-05-29 at 16:44 +0200, Daniel CLEMENT wrote:
> > daniel@e6330d ~ $ syncevolution --sync refresh-from-remote memotoo memos
> > syncevolution: error while loading shared libraries: libical.so.0:
> > cannot open shared object file: No such file or directory
>
> Which version of SyncEvolution is that?
It's
syncevolution-evolution 1:1.5-1
syncevolution-bundle 1:1.5-2
but while the main (older) PC (the one I'm writing from) uses
http://downloads.syncevolution.org/apt/ (stable main)
the 2nd one (upgraded, which has problems) is set to
https://download.01.org/syncevolution/apt/ (stable main)...
>
> 1.5 does not link against libical.so.0 (ldd `which syncevolution ` |
> grep libical).
... and the result of this command line gives different results:
(old PC) no output, which I assume is normal;
(upgraded PC)
daniel@e6330d ~ $ ldd `which syncevolution ` | grep libical
libical.so.0 => /usr/lib/libical.so.0 (0x00007f680aa6b000)
libicalss.so.0 => /usr/lib/libicalss.so.0 (0x00007f680a852000)
libicalvcal.so.0 => /usr/lib/libicalvcal.so.0 (0x00007f680a63c000)
I'm very suspicious about the binary that you are running on this
upgraded PC. Please check that it really comes from the official .deb:
which syncevolution
file `which syncevolution`
md5sum `which syncevolution`
dpkg -S `which syncevolution`
Assuming that you are on amd64 (aka 64 bit), that should give:
$ which syncevolution
/usr/bin/syncevolution
$ file `which syncevolution`
/usr/bin/syncevolution: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.6.15,
BuildID[sha1]=05708d05d234df537c464157b331ddb901d52600, not stripped
$ md5sum `which syncevolution`
c0405aa56a9976159386c54b7ac47ae1 /usr/bin/syncevolution
$ dpkg -S `which syncevolution`
syncevolution-bundle: /usr/bin/syncevolution
--
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.
2:43 a.m.
Le vendredi 29 mai 2015 à 22:13 +0200, Patrick Ohly a écrit :
On Fri, 2015-05-29 at 17:56 +0200, Daniel CLEMENT wrote:
> [...]
> > Which version of SyncEvolution is that?
>
> It's
> syncevolution-evolution 1:1.5-1
> syncevolution-bundle 1:1.5-2
>
> but while the main (older) PC (the one I'm writing from) uses
> http://downloads.syncevolution.org/apt/ (stable main)
> the 2nd one (upgraded, which has problems) is set to
> https://download.01.org/syncevolution/apt/ (stable main)...
> >
> > 1.5 does not link against libical.so.0 (ldd `which syncevolution ` |
> > grep libical).
>
> ... and the result of this command line gives different results:
> (old PC) no output, which I assume is normal;
> (upgraded PC)
> daniel@e6330d ~ $ ldd `which syncevolution ` | grep libical
> libical.so.0 => /usr/lib/libical.so.0 (0x00007f680aa6b000)
> libicalss.so.0 => /usr/lib/libicalss.so.0 (0x00007f680a852000)
> libicalvcal.so.0 => /usr/lib/libicalvcal.so.0 (0x00007f680a63c000)
I'm very suspicious about the binary that you are running on this
upgraded PC. Please check that it really comes from the official .deb:
which syncevolution
file `which syncevolution`
md5sum `which syncevolution`
dpkg -S `which syncevolution`
Assuming that you are on amd64 (aka 64 bit), that should give:
$ which syncevolution
/usr/bin/syncevolution
$ file `which syncevolution`
/usr/bin/syncevolution: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.6.15,
BuildID[sha1]=05708d05d234df537c464157b331ddb901d52600, not stripped
$ md5sum `which syncevolution`
c0405aa56a9976159386c54b7ac47ae1 /usr/bin/syncevolution
$ dpkg -S `which syncevolution`
syncevolution-bundle: /usr/bin/syncevolution
I get precisely that. Same thing on the older PC.
I modified the repository on the upgraded PC to match the other one
(http://downloads.syncevolution.org/apt/) and reinstalled (purging the
cache), but I believe the 2 repos have exactly the same files (not a
surprise).
After that I also re-ran ldd `which syncevolution ` | grep libical on
the newer PC, and the output still has the same references to
libical*.so.0 as above, unlike the older PC.
--
Daniel CLEMENT
7:30 a.m.
On Sat, 2015-05-30 at 08:43 +0200, Daniel CLEMENT wrote:
Le vendredi 29 mai 2015 à 22:13 +0200, Patrick Ohly a écrit :
> On Fri, 2015-05-29 at 17:56 +0200, Daniel CLEMENT wrote:
> I'm very suspicious about the binary that you are running on this
> upgraded PC. Please check that it really comes from the official .deb:
>
> which syncevolution
> file `which syncevolution`
> md5sum `which syncevolution`
> dpkg -S `which syncevolution`
>
> Assuming that you are on amd64 (aka 64 bit), that should give:
>
> $ which syncevolution
> /usr/bin/syncevolution
> $ file `which syncevolution`
> /usr/bin/syncevolution: ELF 64-bit LSB executable, x86-64, version 1
> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 2.6.15,
> BuildID[sha1]=05708d05d234df537c464157b331ddb901d52600, not stripped
> $ md5sum `which syncevolution`
> c0405aa56a9976159386c54b7ac47ae1 /usr/bin/syncevolution
> $ dpkg -S `which syncevolution`
> syncevolution-bundle: /usr/bin/syncevolution
>
I get precisely that. Same thing on the older PC.
So it must be some of libraries that the executable is linked against
which has the hard dependency on libical.so.0.
Try this:
LD_TRACE_LOADED_OBJECTS=1 LD_DEBUG=files syncevolution 2>&1 | grep -C2 libical
I get no output here because the main executable and none of its direct
dependencies uses libical. In your case, I'd expect to see an
explanation for the "error while loading shared libraries:
libical.so.0".
--
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.
10:38 a.m.
Le samedi 30 mai 2015 à 13:30 +0200, Patrick Ohly a écrit :
On Sat, 2015-05-30 at 08:43 +0200, Daniel CLEMENT wrote:
> Le vendredi 29 mai 2015 à 22:13 +0200, Patrick Ohly a écrit :
> > On Fri, 2015-05-29 at 17:56 +0200, Daniel CLEMENT wrote:
> > I'm very suspicious about the binary that you are running on this
> > upgraded PC. Please check that it really comes from the official .deb:
> >
> > which syncevolution
> > file `which syncevolution`
> > md5sum `which syncevolution`
> > dpkg -S `which syncevolution`
> >
> > Assuming that you are on amd64 (aka 64 bit), that should give:
> >
> > $ which syncevolution
> > /usr/bin/syncevolution
> > $ file `which syncevolution`
> > /usr/bin/syncevolution: ELF 64-bit LSB executable, x86-64, version 1
> > (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> > GNU/Linux 2.6.15,
> > BuildID[sha1]=05708d05d234df537c464157b331ddb901d52600, not stripped
> > $ md5sum `which syncevolution`
> > c0405aa56a9976159386c54b7ac47ae1 /usr/bin/syncevolution
> > $ dpkg -S `which syncevolution`
> > syncevolution-bundle: /usr/bin/syncevolution
> >
> I get precisely that. Same thing on the older PC.
So it must be some of libraries that the executable is linked against
which has the hard dependency on libical.so.0.
Try this:
LD_TRACE_LOADED_OBJECTS=1 LD_DEBUG=files syncevolution 2>&1 | grep -C2 libical
I get no output here because the main executable and none of its direct
dependencies uses libical. In your case, I'd expect to see an
explanation for the "error while loading shared libraries:
libical.so.0".
There's a lot of output here:
daniel@e6330d ~ $ LD_TRACE_LOADED_OBJECTS=1 LD_DEBUG=files syncevolution
2>&1 | grep -C2 libical
3617:
3617:
3617: file=libical.so.0 [0]; needed
by /usr/local/lib/libsynthesis.so.0 [0]
3617: file=libical.so.0 [0]; generating link map
3617: dynamic: 0x00007f2a7a9bfd60 base: 0x00007f2a7a760000
size: 0x0000000000262340
3617: entry: 0x00007f2a7a77bdb0 phdr: 0x00007f2a7a760040
phnum: 7
3617:
3617:
3617: file=libicalss.so.0 [0]; needed
by /usr/local/lib/libsynthesis.so.0 [0]
3617: file=libicalss.so.0 [0]; generating link map
3617: dynamic: 0x00007f2a7a75ccf0 base: 0x00007f2a7a547000
size: 0x0000000000218888
3617: entry: 0x00007f2a7a54f9e0 phdr: 0x00007f2a7a547040
phnum: 7
3617:
3617:
3617: file=libicalvcal.so.0 [0]; needed
by /usr/local/lib/libsynthesis.so.0 [0]
3617: file=libicalvcal.so.0 [0]; generating link map
3617: dynamic: 0x00007f2a7a543ce0 base: 0x00007f2a7a331000
size: 0x0000000000215168
3617: entry: 0x00007f2a7a337f10 phdr: 0x00007f2a7a331040
phnum: 7
--
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f2a7ac8c000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x00007f2a7a9c3000)
libical.so.0 => /usr/lib/libical.so.0 (0x00007f2a7a760000)
libicalss.so.0 => /usr/lib/libicalss.so.0 (0x00007f2a7a547000)
libicalvcal.so.0 => /usr/lib/libicalvcal.so.0 (0x00007f2a7a331000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2a7a116000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2
(0x00007f2a79daf000)
In particular, what's this libsynthesis.so.0 in /usr/local/lib? Is that
again a residue of the patched version that I had compiled once on this
PC?
Under /usr/local/lib I still have these libsynthesis* files:
libsynthesis.a
libsynthesis.la
libsynthesissdk.a
libsynthesissdk.la
libsynthesis.so
libsynthesis.so.0
libsynthesis.so.0.6.0
libsynthesisstubs.a
libsynthesisstubs.la
which I had forgotten here because everything went well under the old
Linux Mint Debian. Are they the cause of all this trouble?
--
Daniel CLEMENT
2:23 p.m.
On Sat, 2015-05-30 at 16:38 +0200, Daniel CLEMENT wrote:
Le samedi 30 mai 2015 à 13:30 +0200, Patrick Ohly a écrit :
> On Sat, 2015-05-30 at 08:43 +0200, Daniel CLEMENT wrote:
> > Le vendredi 29 mai 2015 à 22:13 +0200, Patrick Ohly a écrit :
> > > On Fri, 2015-05-29 at 17:56 +0200, Daniel CLEMENT wrote:
> > > I'm very suspicious about the binary that you are running on this
> > > upgraded PC. Please check that it really comes from the official .deb:
> > >
> > > which syncevolution
> > > file `which syncevolution`
> > > md5sum `which syncevolution`
> > > dpkg -S `which syncevolution`
> > >
> > > Assuming that you are on amd64 (aka 64 bit), that should give:
> > >
> > > $ which syncevolution
> > > /usr/bin/syncevolution
> > > $ file `which syncevolution`
> > > /usr/bin/syncevolution: ELF 64-bit LSB executable, x86-64, version 1
> > > (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> > > GNU/Linux 2.6.15,
> > > BuildID[sha1]=05708d05d234df537c464157b331ddb901d52600, not stripped
> > > $ md5sum `which syncevolution`
> > > c0405aa56a9976159386c54b7ac47ae1 /usr/bin/syncevolution
> > > $ dpkg -S `which syncevolution`
> > > syncevolution-bundle: /usr/bin/syncevolution
> > >
> > I get precisely that. Same thing on the older PC.
>
> So it must be some of libraries that the executable is linked against
> which has the hard dependency on libical.so.0.
>
> Try this:
> LD_TRACE_LOADED_OBJECTS=1 LD_DEBUG=files syncevolution 2>&1 | grep -C2
libical
>
> I get no output here because the main executable and none of its direct
> dependencies uses libical. In your case, I'd expect to see an
> explanation for the "error while loading shared libraries:
> libical.so.0".
>
>
There's a lot of output here:
daniel@e6330d ~ $ LD_TRACE_LOADED_OBJECTS=1 LD_DEBUG=files syncevolution
2>&1 | grep -C2 libical
3617:
3617:
3617: file=libical.so.0 [0]; needed
by /usr/local/lib/libsynthesis.so.0 [0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And here's the smoking gun.
In particular, what's this libsynthesis.so.0 in /usr/local/lib?
Is that
again a residue of the patched version that I had compiled once on this
PC?
Yes.
Under /usr/local/lib I still have these libsynthesis* files:
libsynthesis.a
libsynthesis.la
libsynthesissdk.a
libsynthesissdk.la
libsynthesis.so
libsynthesis.so.0
libsynthesis.so.0.6.0
libsynthesisstubs.a
libsynthesisstubs.la
which I had forgotten here because everything went well under the old
Linux Mint Debian. Are they the cause of all this trouble?
Yes. Please remove them, they are no longer compatible with the rest of
your system. Besides, they prevent you from using the potentially more
recent libsynthesis packaged with SyncEvolution.
--
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.
8:46 a.m.
Le samedi 30 mai 2015 à 20:23 +0200, Patrick Ohly a écrit :
[...]
> Under /usr/local/lib I still have these libsynthesis* files:
> libsynthesis.a
> [...]
> libsynthesisstubs.la
> which I had forgotten here because everything went well under the old
> Linux Mint Debian. Are they the cause of all this trouble?
Yes. Please remove them, they are no longer compatible with the rest of
your system. Besides, they prevent you from using the potentially more
recent libsynthesis packaged with SyncEvolution.
I removed these packages, and with huge relief I saw the 1st sync
complete without problem.
My apology again for the waste of time. No excuse, but I had completely
forgotten those files in the cleanup of the compiled version. And they
remained unnoticed until the upgrade.
I'm reassured to know that Syncevolution will run on my main PC (on
which I never compile anything) when I upgrade it to Linux Mint Debian
Jessie.
Many thanks,
--
Daniel CLEMENT
1978
days inactive
1983
days old
syncevolution@synevolution.org
30 comments
3 participants
participants (3)
-
Daniel CLEMENT -
Milan Crha -
Patrick Ohly