February 2013 - Syncevolution-issues

[Bug 54998] New: disable PHOTO syncing for specific peers

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=54998 Bug #: 54998 Summary: disable PHOTO syncing for specific peers Classification: Unclassified Product: SyncEvolution Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: high Component: SyncML AssignedTo: syncevolution-issues(a)syncevolution.org ReportedBy: patrick.ohly(a)gmx.de CC: syncevolution-issues(a)syncevolution.org Some peers, in particular older phones, have problems when being sent lots of photo data. It may be more useful to exclude photo data altogether for such peers. See "[SyncEvolution] Sync failure due to large addressbook entires." A possible solution would be: - introduce a new session variable in the <sessioninitscript> - set that variable in remote rules (see stripUID for an example) or based on a new config property (see preventSlowSync) - extend the <outgoingscript> for contacts such that it unsets the PHOTO property before encoding a contact for the peer if that session variable is set - see VCARD_OUTGOING_PHOTO_INLINING_SCRIPT That should take care of sending data to the phone. Ensuring that the photo doesn't get lost when receiving an update is harder. Something might be possible with a custom <mergescript>, but I am not sure whether it really gets invoked during a normal import. Alternatively, dynamically updating the field attributes after parsing the peer's CtCap would be a more elegant solution, because it would use existing libsynthesis mechanisms: - don't send properties to a peer which the peer doesn't support (strip PHOTO when sending) - preserve local properties not supported by the peer (preserve PHOTO) However, implementing that will require considerable changes in libsynthesis: - expose the field list attributes to scripts - ensure that a script is called after parsing CtCap and before using the field list (perhaps <datastoreinitscript> is suitable) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

2 years, 3 months

1
2
0 / 0

[Bug 57004] New: preventing slow syncs must not cause slow syncs

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=57004 Priority: highest Bug ID: 57004 CC: syncevolution-issues(a)syncevolution.org Assignee: patrick.ohly(a)intel.com Summary: preventing slow syncs must not cause slow syncs Severity: normal Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: ASSIGNED Version: unspecified Component: SyncML Product: SyncEvolution When one source in a sync with multiple sources encounters a slow sync and thus aborts the sync, the other sources must not be affected. What happens instead is that they are forced into a slow sync in the next sync. Steps to reproduce: syncevolution --configure preventslowsync=1 memotoo_1 syncevolution memotoo_1 eds_contact eds_event cp -a ~/.config/syncevolution/ ~/.config/syncevolution_old syncevolution memotoo_1 eds_contact rm -rf ~/.config/syncevolution mv ~/.config/syncevolution_old ~/.config/syncevolution syncevolution memotoo_1 eds_contact => prevents slow sync due to wrong anchors on client, as expected syncevolution memotoo_1 eds_event => works syncevolution memotoo_1 eds_event eds_contact => prevents slow sync for eds_contact syncevolution memotoo_1 eds_event => should have worked, but now also encounters slow sync -- You are receiving this mail because: You are on the CC list for the bug.

2 years, 3 months

1
5
0 / 0

[Bug 57248] New: WebDAV: don't send Basic Auth via http

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=57248 Priority: high Bug ID: 57248 CC: syncevolution-issues(a)syncevolution.org Assignee: syncevolution-issues(a)syncevolution.org Summary: WebDAV: don't send Basic Auth via http Severity: major Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: ASSIGNED Version: unspecified Component: CalDAV/CardDAV Product: SyncEvolution SyncEvolution sends Basic Auth in its initial request, to avoid round-trips. If http with Digest Auth is used, then this behavior exposes the credentials. SyncEvolution should only send Basic Auth over https. See bug #56240 comment #4. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

5 years, 10 months

1
3
0 / 0

[Bug 55921] New: no logging during local sync

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=55921 Priority: high Bug ID: 55921 CC: syncevolution-issues(a)syncevolution.org Assignee: patrick.ohly(a)gmx.de Blocks: 55918 Summary: no logging during local sync Severity: enhancement Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: ASSIGNED Version: unspecified Component: SyncEvolution Product: SyncEvolution The local sync in the IVI use case must not write anything to disk except for the actual data changes. This means: - disable logging in .cache/syncevolution - don't write sync meta data to .config/syncevolution for PBAP, because it always does a slow sync and needs no meta data. -- You are receiving this mail because: You are on the CC list for the bug.

6 years, 6 months

1
4
0 / 0

[Bug 54906] New: support IPv6 on syncevolution.org

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=54906 Bug #: 54906 Summary: support IPv6 on syncevolution.org Classification: Unclassified Product: SyncEvolution Version: unspecified Platform: Other URL: https://bugs.meego.com/show_bug.cgi?id=25562 OS/Version: All Status: ASSIGNED Severity: enhancement Priority: low Component: SyncEvolution AssignedTo: syncevolution-issues(a)syncevolution.org ReportedBy: patrick.ohly(a)gmx.de CC: syncevolution-issues(a)syncevolution.org As pointed out in https://bugs.meego.com/show_bug.cgi?id=25562 the initial IPv6 setup on syncevolution.org did not work (some kind of SSL certificate issue when used over IPv6). Therefore the IPv6 address of syncevolution.org was removed from DNS again, as a short term workaround (not a pressing issue, though, so short term can become pretty long). Need to figure out what the problem was and fix it properly. It would be interesting to know whether https://01.org has the same problem - it uses a similar setup. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

7 years, 1 month

1
1
0 / 0

[Bug 56524] New: PIM Manager: accent-insensitive search

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=56524 Priority: medium Bug ID: 56524 CC: syncevolution-issues(a)syncevolution.org Assignee: syncevolution-issues(a)syncevolution.org Blocks: 56141 Summary: PIM Manager: accent-insensitive search Severity: enhancement Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: ASSIGNED Version: unspecified Component: SyncEvolution Product: SyncEvolution Currently, searching can be case-insensitive and case-sensitive. The difference between characters with and without accent is still relevant, so "Muller" does not find "Müller". It could be useful to also ignore accents. One way to implement this might be: - decompose as NFKD - throw away characters which are modifiers or accents (exact filter to be decided) See: http://unicode.org/reports/tr15/#Norm_Forms -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

7 years, 2 months

1
4
0 / 0

[Bug 59551] New: incremental PHOTO download, avoid sync if no change

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=59551 Priority: high Bug ID: 59551 CC: syncevolution-issues(a)syncevolution.org Assignee: patrick.ohly(a)intel.com Summary: incremental PHOTO download, avoid sync if no change Severity: normal Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: ASSIGNED Version: unspecified Component: SyncEvolution Product: SyncEvolution Tracked as one issue, because it affects the same code. The first part, incremental PHOTO download, has the goal of making the text-only properties available sooner. This can be done by doing the initial sync with a filter that excludes PHOTO data, then do the next sync with PHOTO data. The second part is meant to avoid expensive work (syncing) and thus save CPU cycles: by checksumming the downloaded data, it becomes possible to detect the case where nothing changed and avoid the syncing. Some complications: - When switching between downloads with and without PHOTO, then two checksums are needed. - If the checksum without PHOTO data matches, then we still need to download with PHOTO data, because the PHOTOs might have changed. - At the moment, doing a sync without PHOTO after a sync with PHOTO will remove the PHOTO data from the local cache. The engine would have to be configured so that it knows whether PHOTOs are part of the sync or not (relevant also for other issues, see feature request/bug #54998). A simpler solution would be the following: - If a phone has never been synced before, do a sync without PHOTO data. This will add the text-only properties quickly. - Immediately do a sync with PHOTOs, to add that data. Keep a checksum of that sync. - In all future syncs, download with PHOTO data and compare the checksum to avoid syncing when nothing changed. This logic can be implemented entirely in the PBAP backend. -- You are receiving this mail because: You are on the CC list for the bug.

7 years, 4 months

1
7
0 / 0

[Bug 60380] New: PIM: CATEGORIES

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=60380 Priority: medium Bug ID: 60380 CC: syncevolution-issues(a)syncevolution.org Assignee: syncevolution-issues(a)syncevolution.org Blocks: 55918, 56141 Summary: PIM: CATEGORIES Severity: enhancement Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: NEW Version: unspecified Component: SyncEvolution Product: SyncEvolution Support reading and writing of CATEGORIES. Reading can be done with folks, writing cannot because there is no detail defined for it: http://telepathy.freedesktop.org/doc/folks-eds/vala/Edsf.PersonaStore.add... No upstream bug for it at the moment. Need to create one once we have a patch. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

7 years, 8 months

1
3
0 / 0

[Bug 60373] New: folks + GEO

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=60373 Priority: medium Bug ID: 60373 CC: syncevolution-issues(a)syncevolution.org Assignee: syncevolution-issues(a)syncevolution.org Blocks: 55926 Summary: folks + GEO Severity: normal Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de URL: https://bugzilla.gnome.org/show_bug.cgi?id=627400 Hardware: Other Status: ASSIGNED Version: unspecified Component: SyncEvolution Product: SyncEvolution folks currently doesn't support the GEO property. There is an open upstream bug about it, but they don't have time to work on it ATM: https://bugzilla.gnome.org/show_bug.cgi?id=627400 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

7 years, 8 months

1
3
0 / 0

[Bug 60374] New: PIM: GEO

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=60374 Priority: medium Bug ID: 60374 CC: syncevolution-issues(a)syncevolution.org Assignee: syncevolution-issues(a)syncevolution.org Summary: PIM: GEO Severity: enhancement Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: ASSIGNED Version: unspecified Component: SyncEvolution Depends on: 60373 Product: SyncEvolution SyncEvolution can now sync the GEO property. PIM Manager itself has to go through folks, which doesn't support it yet (bug #60373). -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

7 years, 8 months

1
4
0 / 0

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Syncevolution-issues February 2013