March 2013 - Syncevolution-issues

[Bug 59985] New: Feature Request: Setting up Owncloud within GUI

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=59985 Priority: medium Bug ID: 59985 CC: syncevolution-issues(a)syncevolution.org Assignee: syncevolution-issues(a)syncevolution.org Summary: Feature Request: Setting up Owncloud within GUI Severity: enhancement Classification: Unclassified OS: All Reporter: lebochequirit(a)gmail.com Hardware: All Status: NEW Version: unspecified Component: GTK UI Product: SyncEvolution Syncing with Owncloud does work via command line, but it's quite an effort and way beyond many users knowledge. Also, setting up auto-sync is much easier from within the GUI. A predefined Owncloud Service would be of major use for many, many users. I'm sorry to say so, but the usability of Evolution and in parts Owncloud depends on you, as both platforms seem not to care about each other :-) Thanks for your excellent work so far, L.B.Q.R. -- 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
8
0 / 0

[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 61851] New: gnutls + neon: memory leak

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=61851 Priority: medium Bug ID: 61851 CC: syncevolution-issues(a)syncevolution.org Assignee: syncevolution-issues(a)syncevolution.org Summary: gnutls + neon: memory leak Severity: normal Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: NEW Version: 1.3.99.3 Component: SyncEvolution Product: SyncEvolution Started to appear after switching testing-amd64 apple caldav testing to https. Need to investigate, going to suppress it for now in sys.supp. # ==4782== 2,048 bytes in 1 blocks are definitely lost in loss record 2,395 of 2,503 # ==4782== at 0x4C28BED: malloc (vg_replace_malloc.c:263) # ==4782== by 0x4C28D6F: realloc (vg_replace_malloc.c:632) # ==4782== by 0x10955415: ??? (in /usr/lib/x86_64-linux-gnu/libgnutls.so.26.22.4) # ==4782== by 0x109480DD: ??? (in /usr/lib/x86_64-linux-gnu/libgnutls.so.26.22.4) # ==4782== by 0x10944048: gnutls_session_get_data2 (in /usr/lib/x86_64-linux-gnu/libgnutls.so.26.22.4) # ==4782== by 0x6E4D666: ne_sock_connect_ssl (in /usr/lib/libneon-gnutls.so.27.2.6) # ==4782== by 0x6E572DE: ??? (in /usr/lib/libneon-gnutls.so.27.2.6) # ==4782== by 0x6E454F9: ??? (in /usr/lib/libneon-gnutls.so.27.2.6) # ==4782== by 0x6E45D1B: ne_begin_request (in /usr/lib/libneon-gnutls.so.27.2.6) # ==4782== by 0x6E453AC: ne_request_dispatch (in /usr/lib/libneon-gnutls.so.27.2.6) # ==4782== by 0x6E52BCC: ??? (in /usr/lib/libneon-gnutls.so.27.2.6) # ==4782== by 0x8ECB01: SyncEvo::Neon::Session::propfindURI(std::string const&, int, ne_propname const*, boost::function<void ()(SyncEvo::Neon::URI const&, ne_prop_result_set_s const*)> const&, SyncEvo::Timespec const&) (NeonCXX.cpp:426) # ==4782== by 0x8ECE4E: SyncEvo::Neon::Session::propfindProp(std::string const&, int, ne_propname const*, boost::function<void ()(SyncEvo::Neon::URI const&, ne_propname const*, char const*, ne_status const*)> const&, SyncEvo::Timespec const&) (NeonCXX.cpp:461) # ==4782== by 0x8E1539: SyncEvo::WebDAVSource::databaseRevision() (WebDAVSource.cpp:1332) # ==4782== by 0x8CF30C: SyncEvo::CalDAVSource::subDatabaseRevision() (CalDAVSource.h:37) # ==4782== by 0xA56FCC: SyncEvo::MapSyncSource::endSync(bool) (MapSyncSource.cpp:252) # ==4782== by 0x86FCEB: SyncEvo::TestingSyncSourcePtr::stopAccess() (ClientTest.cpp:349) # ==4782== by 0x870424: SyncEvo::TestingSyncSourcePtr::reset(SyncEvo::TestingSyncSource*, SyncEvo::TestingSyncSourcePtr::Flags) (ClientTest.cpp:294) # ==4782== by 0x7A3188: SyncEvo::LocalTests::testImport() (ClientTest.cpp:1473) # ==4782== by 0x7546B50: CppUnit::TestCaseMethodFunctor::operator()() const (in /usr/lib/libcppunit-1.12.so.1.0.0) # ==4782== by 0x753CBB4: CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (in /usr/lib/libcppunit-1.12.so.1.0.0) # ==4782== by 0x7543B71: CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (in /usr/lib/libcppunit-1.12.so.1.0.0) # ==4782== by 0x754C6F4: CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::string const&) (in /usr/lib/libcppunit-1.12.so.1.0.0) # ==4782== by 0x754676E: CppUnit::TestCase::run(CppUnit::TestResult*) (in /usr/lib/libcppunit-1.12.so.1.0.0) # ==4782== by 0x754C679: CppUnit::TestResult::runTest(CppUnit::Test*) (in /usr/lib/libcppunit-1.12.so.1.0.0) # ==4782== by 0x754EB38: CppUnit::TestRunner::run(CppUnit::TestResult&, std::string const&) (in /usr/lib/libcppunit-1.12.so.1.0.0) # ==4782== by 0x7550DA5: CppUnit::TextTestRunner::run(std::string, bool, bool, bool) (in /usr/lib/libcppunit-1.12.so.1.0.0) # ==4782== by 0x6B921A: main (client-test-main.cpp:349) -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

6 years, 6 months

1
3
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 62516] New: PIM manager: include .txt files in distribution

by bugzilla-daemon＠freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=62516 Priority: medium Bug ID: 62516 CC: syncevolution-issues(a)syncevolution.org Assignee: patrick.ohly(a)intel.com Summary: PIM manager: include .txt files in distribution Severity: normal Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: ASSIGNED Version: 1.3.99.3 Component: SyncEvolution Product: SyncEvolution pim-manager-api.txt is not part of source code distribution. Must add it to EXTRA_DIST. -- You are receiving this mail because: You are on the CC list for the bug.

7 years, 7 months

1
2
0 / 0

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Syncevolution-issues March 2013