8:28 p.m.
https://bugs.freedesktop.org/show_bug.cgi?id=56263
Priority: medium
Bug ID: 56263
CC: syncevolution-issues(a)syncevolution.org
Assignee: syncevolution-issues(a)syncevolution.org
Summary: Can't synchronise CardDAV with Basic Auth
Severity: normal
Classification: Unclassified
OS: All
Reporter: fdo-bugs(a)cryptobitch.de
Hardware: Other
Status: UNCONFIRMED
Version: 1.3
Component: CalDAV/CardDAV
Product: SyncEvolution
Created attachment 68886
--> https://bugs.freedesktop.org/attachment.cgi?id=68886&action=edit
full stacktrace
I think I convinced syncevolution to connect to a CardDAV instance like so:
URL=http://foo/
syncevolution --daemon=no --configure \
--template webdav \
username=user1 \
password=pw1 \
syncURL=${URL} \
target-config@radicale
syncevolution --daemon=no --configure \
database=${URL}muelli/test/ \
backend=caldav \
target-config@radicale calendar1
syncevolution --daemon=no --configure \
--template SyncEvolution_Client \
sync=none \
syncURL=local://@radicale \
username= \
password= \
radicale
syncevolution --daemon=no --configure \
sync=two-way \
backend=calendar \
database=GCal \
radicale calendar1
syncevolution --daemon=no --configure \
database=${URL}muelli/cards/ \
backend=carddav \
username=user1 \
password=pw1 \
target-config@radicale cards1
syncevolution --daemon=no --configure \
sync=two-way \
backend=contacts \
database=Personal \
radicale cards1
holy cow, that was quite tiresome and utterly frustrating. Four quite complex
commands to eventually be able to connect to the calendar, then another two to
eventually make addressbook work. That's not fun.
And now it doesn't even work and I feel unable to get more useful information.
So here is the problem:
$ syncevolution --daemon=no --print-items target-config@radicale cards1
342F8BEA-54AC0772-04A3D2F6%2evcf
$ syncevolution --daemon=no target-config@radicale cards1
[INFO] addressbook: inactive
[INFO] calendar: inactive
[INFO] calendar1: inactive
[INFO] memo: inactive
[INFO] todo: inactive
[INFO] SoupTransport Failure: http://foo/ via libsoup: Authorization Required
[INFO] Transport giving up after 0 retries and 0:00min
[ERROR] transport problem: transport failed, retry period exceeded
[INFO] cards1: inactive
[ERROR] cards1: aborted on behalf of user (local, status 20017)
Synchronization failed, see
/home/muelli/.cache/syncevolution/target_+config(a)radicale-2012-10-21-21-39/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| cards1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| aborted on behalf of user (local, status 20017) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Oct 21 21:39:47 2012, duration 0:01min |
| external transport failure (local, status 20043) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: transport problem: transport failed, retry period
exceeded
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --sync slow
target-config@radicale cards1
[DEBUG 00:00:00] Sun 2012-10-21 20:21:28 UTC = 22:21 +0200 CEST
[DEVELOPER 00:00:00] SyncML server account: user1
[DEVELOPER 00:00:00] client: SyncEvolution 1.3.1 for workstation
[DEVELOPER 00:00:00] device ID:
syncevolution-72d6f9ea-d180-4fd1-8cb5-3b523888a138
[DEVELOPER 00:00:00]
[DEVELOPER 00:00:00] Scanning backend libraries in
/usr/lib64/syncevolution/backends/
[DEVELOPER 00:00:00] Loading backend library syncaddressbook.so
[DEVELOPER 00:00:00] Loading backend library syncebook.so
[DEVELOPER 00:00:00] Loading backend library syncecal.so
[DEVELOPER 00:00:00] Loading backend library syncfile.so
[DEVELOPER 00:00:00] Loading backend library synckcalextended.so
[DEVELOPER 00:00:00] Loading backend library syncmaemocal.so
[DEVELOPER 00:00:00] Loading backend library syncqtcontacts.so
[DEVELOPER 00:00:00] Loading backend library syncsqlite.so
[DEVELOPER 00:00:00] Loading backend library syncxmlrpc.so
[DEVELOPER 00:00:00] Loading backend library syncakonadi.so
[DEVELOPER 00:00:00] Loading backend library syncdav.so
[DEVELOPER 00:00:00] Loading backend library platformgnome.so
[DEVELOPER 00:00:00] Loading backend library platformkde.so
[DEVELOPER 00:00:00] Loading backend library syncactivesync.so
[INFO 00:00:00] addressbook: inactive
[INFO 00:00:00] calendar: inactive
[INFO 00:00:00] calendar1: inactive
[INFO 00:00:00] memo: inactive
[INFO 00:00:00] todo: inactive
[DEBUG 00:00:00] checking sync password syncURL
[DEBUG 00:00:00] checking sync password username
[DEBUG 00:00:00] checking sync password password
[DEBUG 00:00:00] checking sync password logdir
[DEBUG 00:00:00] checking sync password loglevel
[DEBUG 00:00:00] checking sync password notifyLevel
[DEBUG 00:00:00] checking sync password printChanges
[DEBUG 00:00:00] checking sync password dumpData
[DEBUG 00:00:00] checking sync password maxlogdirs
[DEBUG 00:00:00] checking sync password autoSync
[DEBUG 00:00:00] checking sync password autoSyncInterval
[DEBUG 00:00:00] checking sync password autoSyncDelay
[DEBUG 00:00:00] checking sync password preventSlowSync
[DEBUG 00:00:00] checking sync password useProxy
[DEBUG 00:00:00] checking sync password proxyHost
[DEBUG 00:00:00] checking sync password proxyUsername
[DEBUG 00:00:00] checking sync password proxyPassword
[DEBUG 00:00:00] checking sync password clientAuthType
[DEBUG 00:00:00] checking sync password RetryDuration
[DEBUG 00:00:00] checking sync password RetryInterval
[DEBUG 00:00:00] checking sync password remoteIdentifier
[DEBUG 00:00:00] checking sync password PeerIsClient
[DEBUG 00:00:00] checking sync password SyncMLVersion
[DEBUG 00:00:00] checking sync password PeerName
[DEBUG 00:00:00] checking sync password deviceId
[DEBUG 00:00:00] checking sync password remoteDeviceId
[DEBUG 00:00:00] checking sync password enableWBXML
[DEBUG 00:00:00] checking sync password enableRefreshSync
[DEBUG 00:00:00] checking sync password maxMsgSize
[DEBUG 00:00:00] checking sync password maxObjSize
[DEBUG 00:00:00] checking sync password SSLServerCertificates
[DEBUG 00:00:00] checking sync password SSLVerifyServer
[DEBUG 00:00:00] checking sync password SSLVerifyHost
[DEBUG 00:00:00] checking sync password WebURL
[DEBUG 00:00:00] checking sync password IconURI
[DEBUG 00:00:00] checking sync password ConsumerReady
[DEBUG 00:00:00] checking sync password peerType
[DEBUG 00:00:00] checking sync password HashCode
[DEBUG 00:00:00] checking sync password ConfigDate
[DEBUG 00:00:00] checking sync password lastNonce
[DEBUG 00:00:00] checking sync password deviceData
[DEBUG 00:00:00] checking sync password defaultPeer
[DEBUG 00:00:00] checking sync password keyring
[DEBUG 00:00:00] checking sync password webDAVCredentialsOkay
[DEBUG 00:00:00] checking source cards1 password sync
[DEBUG 00:00:00] checking source cards1 password uri
[DEBUG 00:00:00] checking source cards1 password backend
[DEBUG 00:00:00] checking source cards1 password syncFormat
[DEBUG 00:00:00] checking source cards1 password forceSyncFormat
[DEBUG 00:00:00] checking source cards1 password database
[DEBUG 00:00:00] checking source cards1 password databaseFormat
[DEBUG 00:00:00] checking source cards1 password databaseUser
[DEBUG 00:00:00] checking source cards1 password databasePassword
[DEBUG 00:00:00] checking source cards1 password adminData
[DEBUG 00:00:00] checking source cards1 password synthesisID
[DEBUG 00:00:00] sync is starting, catch signals
[DEBUG 00:00:00] SuspendFlags: (re)activating, currently inactive
[DEBUG 00:00:00] SuspendFlags: activating signal handler(s) with fds 7->6
[DEBUG 00:00:00] SuspendFlags: catch SIGINT
[DEBUG 00:00:00] SuspendFlags: catch SIGTERM
[DEBUG 00:00:00] ready to sync
[DEBUG 00:00:00] CreateContext SyncEvolution//cards1 => 0
[DEBUG 00:00:00] Module_Version = 01090100
[DEBUG 00:00:00] Module_Capabilities:
[DEBUG 00:00:00] PLATFORM:Linux
[DEBUG 00:00:00] DLL:true
[DEBUG 00:00:00] MINVERSION:V1.0.6.0
[DEBUG 00:00:00] MANUFACTURER:SyncEvolution
[DEBUG 00:00:00] DESCRIPTION:SyncEvolution Synthesis DB Plugin
[DEBUG 00:00:00] plugin_datastore_str:no
[DEBUG 00:00:00] plugin_datastore_key:yes
[DEBUG 00:00:00] ITEM_AS_KEY:yes
[DEBUG 00:00:00] plugin_datablob:no
[DEBUG 00:00:00] cards1: Module_PluginParams
[DEBUG 00:00:00] cards1: Engine=01090100
[DEBUG 00:00:00] cards1:
[DEBUG 00:00:00] Module_Capabilities:
[DEBUG 00:00:00] PLATFORM:Linux
[DEBUG 00:00:00] DLL:true
[DEBUG 00:00:00] MINVERSION:V1.0.6.0
[DEBUG 00:00:00] MANUFACTURER:SyncEvolution
[DEBUG 00:00:00] DESCRIPTION:SyncEvolution Synthesis DB Plugin
[DEBUG 00:00:00] plugin_datastore_str:no
[DEBUG 00:00:00] plugin_datastore_key:yes
[DEBUG 00:00:00] ITEM_AS_KEY:yes
[DEBUG 00:00:00] plugin_datablob:no
[DEBUG 00:00:00] unexpected HTTP response: status 401/Authorization Required,
content type text/html; charset=iso-8859-1, body:
[DEBUG 00:00:00] <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
[DEBUG 00:00:00] <html><head>
[DEBUG 00:00:00] <title>401 Authorization Required</title>
[DEBUG 00:00:00] </head><body>
[DEBUG 00:00:00] <h1>Authorization Required</h1>
[DEBUG 00:00:00] <p>This server could not verify that you
[DEBUG 00:00:00] are authorized to access the document
[DEBUG 00:00:00] requested. Either you supplied the wrong
[DEBUG 00:00:00] credentials (e.g., bad password), or your
[DEBUG 00:00:00] browser doesn't understand how to supply
[DEBUG 00:00:00] the credentials required.</p>
[DEBUG 00:00:00] <hr>
[DEBUG 00:00:00] <address>Apache Server at ${URL} Port 80</address>
[DEBUG 00:00:00] </body></html>
[INFO 00:00:00] SoupTransport Failure: http://${URL}/ via libsoup:
Authorization Required
[INFO 00:00:00] Transport giving up after 0 retries and 0:01min
[DEBUG 00:00:00] TransportException thrown at src/syncevo/SyncContext.cpp:3809
[ERROR 00:00:00] transport problem: transport failed, retry period exceeded
[DEBUG 00:00:00] aborting after catching fatal error
[INFO 00:00:00] cards1: inactive
[ERROR 00:00:00] cards1: aborted on behalf of user (local, status 20017)
[DEBUG 00:00:00] SuspendFlags: deactivating fds 7->6
[DEBUG 00:00:00] SuspendFlags: close m_receiverFD 6
[DEBUG 00:00:00] SuspendFlags: close m_senderFD 7
[DEBUG 00:00:00] SuspendFlags: done with deactivation
[DEBUG 00:00:00] Module_DeleteContext cards1
Synchronization failed, see
/home/muelli/.cache/syncevolution/target_+config(a)radicale-2012-10-21-22-21/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| cards1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| aborted on behalf of user (local, status 20017) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Oct 21 22:21:28 2012, duration 0:01min |
| external transport failure (local, status 20043) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: transport problem: transport failed, retry period
exceeded
[DEBUG 00:00:00] removing
/home/muelli/.cache/syncevolution/target_+config@radicale-2012-10-21-21-08
$ syncevolution --daemon=no --status target-config@radicale cards1
[DEBUG 00:00:00] Sun 2012-10-21 19:40:43 UTC = 21:40 +0200 CEST
[INFO 00:00:00] addressbook: inactive
[INFO 00:00:00] calendar: inactive
[INFO 00:00:00] calendar1: inactive
[INFO 00:00:00] memo: inactive
[INFO 00:00:00] todo: inactive
[DEBUG 00:00:00] cards1: using full item scan to detect changes
syncevolution: /usr/include/boost/smart_ptr/shared_ptr.hpp:424: T*
boost::shared_ptr<T>::operator->() const [with T = SyncEvo::Neon::Session]:
Assertion `px != 0' failed.
Aborted (core dumped)
#5 0x00007f8040b99f80 in SyncEvo::WebDAVSource::listAllItems (this=0x90ee70,
revisions=std::map with 0 elements) at
src/backends/webdav/WebDAVSource.cpp:1348
data = <error reading variable: Cannot access memory at address
0x6695f>
parser = {m_parser = 0x0, m_stack = std::list = {[0] = {m_start =
{<boost::function4<int, int, char const*, char const*, char const**>> =
{<boost::function_base> = {vtable = 0x1, functor = {obj_ptr = 0x0, type = {type
= 0x0, const_qualified = 216, volatile_qualified = 70}, func_ptr = 0,
bound_memfunc_ptr = {memfunc_ptr = NULL, obj_ptr = 0x396cc0e2e4}, obj_ref =
{obj_ptr = 0x0, is_const_qualified = 216, is_volatile_qualified = 70}, data = 0
'\000'}}, static args = <optimized out>, static arity = <optimized
out>}, <No
data fields>}, m_data = {<boost::function3<int, int, char const*, unsigned
long>> = {<boost::function_base> = {vtable = 0x90f8d8, functor = {obj_ptr =
0x90f8f8, type = {type = 0x90f8f8, const_qualified = 96, volatile_qualified =
95}, func_ptr = 0x90f8f8, bound_memfunc_ptr = {memfunc_ptr = (void
(boost::detail::function::X::*)(boost::detail::function::X * const, int))
0x90f8f8, this adjustment 9527136, obj_ptr = 0x396cc14915}, obj_ref = {obj_ptr
= 0x90f8f8, is_const_qualified = 96, is_volatile_qualified = 95}, data = -8
'\370'}}, static args = <optimized out>, static arity = <optimized
out>}, <No
data fields>}, m_end = {<boost::function3<int, int, char const*, char
const*>>
= {<boost::function_base> = {vtable = 0x7fff0b535258, functor = {obj_ptr =
0x916d20, type = {type = 0x916d20, const_qualified = 144, volatile_qualified =
false}, func_ptr = 0x916d20, bound_memfunc_ptr = {memfunc_ptr = (void
(boost::detail::function::X::*)(boost::detail::function::X * const, int))
0x916d20, this adjustment 144, obj_ptr = 0x90f8d8}, obj_ref = {obj_ptr =
0x916d20, is_const_qualified = 144, is_volatile_qualified = false}, data = 32 '
'}}, static args = <optimized out>, static arity = <optimized out>},
<No data
fields>}}, [1] = {m_start = {<boost::function4<int, int, char const*, char
const*, char const**>> = {<boost::function_base> = {vtable = 0x0, functor =
{obj_ptr = 0x90f900, type = {type = 0x90f900, const_qualified = false,
volatile_qualified = 249}, func_ptr = 0x90f900, bound_memfunc_ptr =
{memfunc_ptr = (void (boost::detail::function::X::*)(boost::detail::function::X
* const, int)) 0x90f900, this adjustment 9500928, obj_ptr = 0x0}, obj_ref =
{obj_ptr = 0x90f900, is_const_qualified = false, is_volatile_qualified = 249},
data = 0 '\000'}}, static args = <optimized out>, static arity =
<optimized
out>}, <No data fields>}, m_data = {<boost::function3<int, int, char
const*,
unsigned long>> = {<boost::function_base> = {vtable = 0x396d3b0000, functor =
{obj_ptr = 0x0, type = {type = 0x0, const_qualified = false, volatile_qualified
= false}, func_ptr = 0, bound_memfunc_ptr = {memfunc_ptr = NULL, obj_ptr =
0x7f8040e293a8}, obj_ref = {obj_ptr = 0x0, is_const_qualified = false,
is_volatile_qualified = false}, data = 0 '\000'}}, static args = <optimized
out>, static arity = <optimized out>}, <No data fields>}, m_end =
{<boost::function3<int, int, char const*, char const*>> =
{<boost::function_base> = {vtable = 0x396d3b0778, functor = {obj_ptr =
0x6424f8, type = {type = 0x6424f8, const_qualified = 248, volatile_qualified =
36}, func_ptr = 0x6424f8, bound_memfunc_ptr = {memfunc_ptr = (void
(boost::detail::function::X::*)(boost::detail::function::X * const, int))
0x6424f8, this adjustment 6563064, obj_ptr = 0x6424f8}, obj_ref = {obj_ptr =
0x6424f8, is_const_qualified = 248, is_volatile_qualified = 36}, data = -8
'\370'}}, static args = <optimized out>, static arity = <optimized
out>}, <No
data fields>}}<error reading variable: Cannot access memory at address
0xa1>...}, m_href = "\000\020\267B\200\177\000\000
\313&C\200\177\000\000\350\003#C\200\177\000\000
\000\267B\200\177\000\000`\306&C\200\177\000\000@\313&C\200\177\000\000\000\000\000\000\000\000\000\000\260\317&C\200\177\000\000\000\000\000\000\000\000\000\000\270\005#C\200\177\000\000\230\006#C\200\177\000\000\210\006#C\200\177\000\000\000\000\000\000\000\000\000\000H\006#C\200\177\000\000X\006#C\200\177\000\000\310\006#C\200\177\000\000\330\006#C\200\177\000\000\350\006#C\200\177\000\000h\006#C\200\177\000\000x\006#C\200\177\000\000\330\005#C\200\177\000\000\350\005#C\200\177\000\000\310\005#C\200\177",
'\000' <repeats 42 times>"\250, \006#C\200\177", '\000'
<repeats 18
times>"\270,
\006#C\200\177\000\000\000\000\000\000\000\000\000\000\370\005#C\200\177\000\000\030\006#C\200\177\000\000\b\006#C\200"...
<Address 0x7f804326d000 out of bounds>, m_etag = <error reading variable:
Cannot access memory at address 0xffffffffffffffe8>}
report = {m_method = <error reading variable: Cannot access memory at
address 0xffffffffffffffe8>, m_session = @0x0, m_req = 0x9194e8, m_result =
0x0, m_parser = 0x916d48}
query =
"\366r\227f)=\016\350_w\234\030\347\337\202\025{\035{d\224s\024Q\035\206\233!\232o\210
#\253d\t\016\202\020(9\352\211\301\271T\302\243MJ\355\237\257\204\347\212\340!{{\307\260\r\350\374\062\342\070\347\275\354cw\206\326C\321\037V\333\205\250q\034\300\207\375\257\341aI\363\242\254\200-sKK\326&6\314\360#\022\347\324g\315\311\357~\242\356\265K\256|\022:\251\000\204$\b\021\021\005\367\064\261x\325ov\375l\256\031\202\347\316Ja\230S\354)YH\241\256C\264\352!\344e@D\222}\022\275\347\022\202\027\200\226\206zWDQ\362\355\373kw\000[\275u\347\301\060\307\203\034\005!Y\200\364z\346S\267\374\337\355\345'*\032\325Q\200\272\314\256\"\210\353u\253.\237\246\020bv\351\234\215\327\250\301\330\023\026\026V>\213\275\t\325\310\352X\314\206v\252K\377\256c\346\366\203\264\315;\211\343&&\344\202\025]\264\332\240{\301\204\254e\257d\t3j\"\274\334\347\320\200\217N\355\237\376\231\306\221{\322?Z\246ER\272{4\342m\330z\377\212\026H\253\256D\017\343c\205\335\003\350\324z\205\205\321\210P\"\307\254q\034\b\026\316^\213/\325#k\303\036=\003\214\375\257T\350\237c'\263\337\006w\257P\352K\306\344q\263
J\265\261\273\331ovpz\272\315\233t\037f8\317\347\224V\033\021\340\223\222!l\263\233\034\357\316':!>\211\332K>\030\246,I!Us\205\226}"...
<Address 0x41b73e out of bounds>
deadline = {<timespec> = {tv_sec = 4294967296, tv_nsec = 4294967799},
<No data fields>}
#6 0x00007f8042ddef22 in initRevisions (this=0x90f8d8) at
src/syncevo/SyncSource.cpp:915
No locals.
#7 SyncEvo::SyncSourceRevisions::initRevisions (this=0x90f8d8) at
src/syncevo/SyncSource.cpp:910
No locals.
#8 0x00007f8042de39f5 in SyncEvo::SyncSourceRevisions::detectChanges
(this=0x90f8d8, trackingNode=..., mode=<optimized out>) at
src/syncevo/SyncSource.cpp:1102
revUpdates = std::map with 0 elements
props = {<std::map<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, SyncEvo::InitStateClass<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >,
SyncEvo::Nocase<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const,
SyncEvo::InitStateClass<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > > >> = std::map with 0 elements, <No
data fields>}
#9 0x00007f8042e9366e in SyncEvo::TrackingSyncSource::checkStatus
(this=0x90ee70, changes=...) at src/syncevo/TrackingSyncSource.cpp:64
mode = <optimized out>
oldRevision = ""
#10 0x00007f8042e31d31 in operator() (a0=..., this=<optimized out>) at
/usr/include/boost/function/function_template.hpp:760
No locals.
#11 SyncEvo::SyncContext::checkSourceChanges (this=this@entry=0x8d9a50,
sourceList=..., changes=...) at src/syncevo/SyncContext.cpp:4012
local = {m_backupBefore = {m_numItems = -1}, m_backupAfter =
{m_numItems = -1}, m_stat = {{{0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0,
0, 0, 0}, {0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0,
0, 0, 0, 0, 0, 0}}, {{0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0, 0, 0, 0},
{0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0, 0,
0, 0}}, {{0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0,
0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0, 0, 0, 0, 0}}},
m_mode = SyncEvo::SYNC_NONE, m_restarts = 0, m_first = false, m_resume = false,
m_status = SyncEvo::STATUS_OK, m_virtualSource = ""}
source = 0x90ee70
_foreach_continue4009 = false
#12 0x00007f8042e3c14d in SyncEvo::SyncContext::status (this=0x8d9a50) at
src/syncevo/SyncContext.cpp:3939
I made Apache enforce Basic Auth and the server logs are the following:
for the --print-items:
user1 [21/Oct/2012:21:55:00 +0200] "PROPFIND foo/muelli/cards/ HTTP/1.1" 207
666 "-" "-"
for the non working sync:
user1 [21/Oct/2012:21:55:59 +0200] "PROPFIND foo/muelli/cards/ HTTP/1.1" 207
666 "-" "-"
[21/Oct/2012:21:56:00 +0200] "POST foo/ HTTP/1.1" 401 476 "-"
"SyncEvolution"
Note that the POST doesn't use authentication.
This is SyncEvolution 1.3.1 from
http://koji.fedoraproject.org/koji/search?terms=syncevolution-1.3.1-2.fc1...
While I may just have set SyncEvolution up wrongly (very possible), I do feel
that there s a bug somewhere. The crasher ultimately is.
Anyway, I expected to make it synchronise the via CardDAV, especially since the
calendar part works.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
6:51 a.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
--- Comment #1 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to comment #0)
holy cow, that was quite tiresome and utterly frustrating. Four
quite
complex commands to eventually be able to connect to the calendar, then
another two to eventually make addressbook work. That's not fun.
It would have been possible with two more complex commands (by combining the
setup of all sources into one invocation), but I guess that wouldn't have made
it easier.
I'm open for suggestions how this could be made simpler. There's a mail thread
about that here:
http://comments.gmane.org/gmane.comp.mobile.syncevolution/3992
And now it doesn't even work and I feel unable to get more
useful
information.
So here is the problem:
$ syncevolution --daemon=no --print-items target-config@radicale cards1
342F8BEA-54AC0772-04A3D2F6%2evcf
$ syncevolution --daemon=no target-config@radicale cards1
You are trying to sync with the "target config". Syncing must be triggered via
the "sync" config. In other words, do:
syncevolution radicale cards1
The reason why you get no useful error output is that the target config looks
like a normal SyncML config to SyncEvolution (syncURL set to http:// with
username/password available).
As I said in the mail thread, I am not happy with the "target-config" aspect.
But the discussion did not reach a conclusion on how it can be avoided.
$ syncevolution --daemon=no --status target-config@radicale cards1
[DEBUG 00:00:00] Sun 2012-10-21 19:40:43 UTC = 21:40 +0200 CEST
[INFO 00:00:00] addressbook: inactive
[INFO 00:00:00] calendar: inactive
[INFO 00:00:00] calendar1: inactive
[INFO 00:00:00] memo: inactive
[INFO 00:00:00] todo: inactive
[DEBUG 00:00:00] cards1: using full item scan to detect changes
syncevolution: /usr/include/boost/smart_ptr/shared_ptr.hpp:424: T*
boost::shared_ptr<T>::operator->() const [with T = SyncEvo::Neon::Session]:
Assertion `px != 0' failed.
Aborted (core dumped)
[...]
While I may just have set SyncEvolution up wrongly (very possible), I
do
feel that there s a bug somewhere. The crasher ultimately is.
Anyway, I expected to make it synchronise the via CardDAV, especially since
the calendar part works.
Hmm, I thought I had fixed the "--status" problem:
commit 3d299422f929a647d33b5dec91d53d77c369bcb6
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Jun 29 08:41:31 2012 +0200
WebDAV: --status for WebDAV source aborted
The command line --status operation did not complete when applied to a
CalDAV/CardDAV source. Instead it aborted because the operation took a
code path where the backend was not fully initialized.
Oh, I see: the very first time a source is used it goes through yet another
code path. The downside of trying to minimize requests - many special cases :-(
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
9:29 a.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
Tobias Mueller <fdo-bugs(a)cryptobitch.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Tobias Mueller <fdo-bugs(a)cryptobitch.de> ---
(In reply to comment #1)
I'm open for suggestions how this could be made simpler.
There's a mail
thread about that here:
http://comments.gmane.org/gmane.comp.mobile.syncevolution/3992
Thanks for the hint. And thanks for working on that!
In my dream, it only asks me about the type of data to be synced and the remote
and local storage, i.e.
--calendar --local evolution:Personal --remote
caldav://foo:bar@baz/user/storage/
or so.
Or better yet, it would auto detect that I have calendar data remotely and
select that.
> And now it doesn't even work and I feel unable to get more
useful
> information.
>
> So here is the problem:
> $ syncevolution --daemon=no --print-items target-config@radicale cards1
> 342F8BEA-54AC0772-04A3D2F6%2evcf
> $ syncevolution --daemon=no target-config@radicale cards1
You are trying to sync with the "target config". Syncing must be triggered
via the "sync" config.
oh. wow. That's all double dutch to me :-\ I
read the explanation on the
website though. A couple of times. It's just mind blowingly much information.
In other words, do:
syncevolution radicale cards1
Thanks! That seems to do it.
I probably could have gotten suspicious by this line:
[DEVELOPER 00:00:00] SyncML server account: user1
But then
again, that line also appears in other logs (just without the
username)
I do get empty vcards, however. On the server side, I hav e the following in
the collection:
BEGIN:VCALENDAR
PRODID:-//Radicale//NONSGML Radicale Server//EN
VERSION:2.0
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20121022T084031Z
N:evolution on bigbox;test;frmo;;
FN:test frmo evolution on bigbox
X-EVOLUTION-FILE-AS:evolution on bigbox\, test
X-MOZILLA-HTML:FALSE
UID:3c59174f-d09b-43aa-9eee-26f3740c0ac7
X-RADICALE-NAME:3c59174f-d09b-43aa-9eee-26f3740c0ac7.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20091222T233858Z
N:Mueller;Tobias;;;
FN:Tobias Mueller
X-EVOLUTION-FILE-AS:Mueller\, Tobias
NICKNAME:muelli
UID:13fc9240-91c7-4644-95e1-033729e236cb
X-RADICALE-NAME:13fc9240-91c7-4644-95e1-033729e236cb.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20091222T233858Z
N:Mueller;Tobias;;;
FN:Tobias Mueller
X-EVOLUTION-FILE-AS:Mueller\, Tobias
NICKNAME:muelli
UID:1ec200d5-735b-4d16-a0cd-0bcfb0923fa4
X-RADICALE-NAME:1ec200d5-735b-4d16-a0cd-0bcfb0923fa4.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
URL:
TITLE:
ROLE:
X-EVOLUTION-MANAGER:
X-EVOLUTION-ASSISTANT:
NICKNAME:
X-EVOLUTION-SPOUSE:
NOTE:
FN:test contact
N:contact;test;;;
X-EVOLUTION-FILE-AS:contact\, test
X-EVOLUTION-BLOG-URL:
CALURI:
FBURL:
X-EVOLUTION-VIDEO-URL:
X-MOZILLA-HTML:FALSE
X-RADICALE-NAME:342F8BEA-54AC0772-04A3D2F6.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20091222T233858Z
N:Mueller;Tobias;;;
FN:Tobias Mueller
X-EVOLUTION-FILE-AS:Mueller\, Tobias
NICKNAME:muelli
UID:1e91aa4d-11ca-4580-bc35-2ba170338837
X-RADICALE-NAME:1e91aa4d-11ca-4580-bc35-2ba170338837.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20121022T084031Z
N:evolution on bigbox;test;frmo;;
FN:test frmo evolution on bigbox
X-EVOLUTION-FILE-AS:evolution on bigbox\, test
X-MOZILLA-HTML:FALSE
UID:2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac
X-RADICALE-NAME:2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20121022T084031Z
N:evolution on bigbox;test;frmo;;
FN:test frmo evolution on bigbox
X-EVOLUTION-FILE-AS:evolution on bigbox\, test
X-MOZILLA-HTML:FALSE
UID:72e42321-92d7-4197-b150-1ee77a370645
X-RADICALE-NAME:72e42321-92d7-4197-b150-1ee77a370645.vcf
END:VCARD
END:VCALENDAR
But locally, I get 6 contacts, four of which are empty. The other two are "test
frmo evolution..." and a "Tobias Mueller", but I don't know which (as
the above
mentioned file contains multiple) :-\
Oh, I see: the very first time a source is used it goes through yet
another
code path. The downside of trying to minimize requests - many special cases
:-(
So shall this bug be about tracking that crasher, then?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
9:47 a.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
Patrick Ohly <patrick.ohly(a)gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|syncevolution-issues@syncev |patrick.ohly(a)gmx.de
|olution.org |
--- Comment #3 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to comment #2)
(In reply to comment #1)
> I'm open for suggestions how this could be made simpler. There's a mail
> thread about that here:
> http://comments.gmane.org/gmane.comp.mobile.syncevolution/3992
>
Thanks for the hint. And thanks for working on that!
In my dream, it only asks me about the type of data to be synced and the
remote and local storage, i.e.
--calendar --local evolution:Personal --remote
caldav://foo:bar@baz/user/storage/
or so.
Or better yet, it would auto detect that I have calendar data remotely and
select that.
In other words, add a setup wizard mode to the command line. That's doable, but
also quite a bit of work.
> > $ syncevolution --daemon=no target-config@radicale cards1
>
> You are trying to sync with the "target config". Syncing must be
triggered
> via the "sync" config.
oh. wow. That's all double dutch to me :-\ I read the explanation on the
website though. A couple of times. It's just mind blowingly much information.
Did the terminology section help? It should have. If not, I need to reword it.
I probably could have gotten suspicious by this line:
> [DEVELOPER 00:00:00] SyncML server account: user1
But then again, that line also appears in other logs (just without the
username)
It probably would make sense to add more explicit INFO lines about what
SyncEvolution is doing. Before 1.3, such output would have been mixed with
normal output (for example, the item content in --export -), therefore
SyncEvolution was very quiet. Since 1.3, such messages go to stderr and can be
used more liberally. It's just again something that has been done yet.
I do get empty vcards, however.
The output of
SYNCEVOLUTION_DEBUG=1 syncevolution --daemon-no --export -
target-config@radicale cards1
would be useful.
On the server side, I hav e the following in
the collection:
BEGIN:VCALENDAR
PRODID:-//Radicale//NONSGML Radicale Server//EN
VERSION:2.0
BEGIN:VCARD
That looks suspicious. Normally VCARDs are not stored inside VCALENDAR.
> Oh, I see: the very first time a source is used it goes through
yet another
> code path. The downside of trying to minimize requests - many special cases
> :-(
So shall this bug be about tracking that crasher, then?
That, and the empty vCard issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
10:59 a.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
--- Comment #4 from Tobias Mueller <fdo-bugs(a)cryptobitch.de> ---
(In reply to comment #3)
In other words, add a setup wizard mode to the command line.
That's doable,
but also quite a bit of work.
Hm. Maybe not exactly a wizard with steps and all. But in the case of CalDAV or
CardDAV, it should be possible to check the remote contents for being either
calendar, todolist or addressbook data, I think.
Did the terminology section help? It should have. If not, I need to
reword
it.
Hm. I don't know. It's just so much text. Every time I read it, I feel
it's
totally clear. But shortly after that, when trying to interact with
SyncEvolution, that feeling is gone and total confusion and frustration kicks
in. Many things seem to be implicit and it's not immediately clear what the
things are, that I give a name, i.e. "target-config@radicale",
"calendar1",
"radicale". And if anything goes wrong, the sanest thing to do seems to be to
mv ~/.config/syncevolution out of the way, because I find it not discoverable
which part failed due to which configuration (and how to change it then). That
also adds to the frustration.
I'm just ranting here without any proposal at all. Shame on me. But despite my
really unimportant frustration, I do appreciate all your efforts and I am
grateful that you really try to make syncing happen (it's 2012 after all...).
Anyway, maybe a picture would help. For various use cases. For me, I would
probably appreciate a picture with PC, a "cloud", several databases and the
relevant terms attached to them.
> I do get empty vcards, however.
The output of
SYNCEVOLUTION_DEBUG=1 syncevolution --daemon-no --export -
target-config@radicale cards1
would be useful.
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --print-items
target-config@radicale cards1
[DEBUG 00:00:00] Wed 2012-10-24 10:32:09 UTC = 12:32 +0200 CEST
[DEBUG 00:00:00] using libneon neon 0.29.6: Library build, IPv6, Expat 2.0.1,
zlib 1.2.5, GNU TLS 2.12.14. with SSL, ZLIB, IPV6, TS_SSL, I18N
HTTP session to http://${URL}:80 begins.
sess: libproxy #0=direct://
[DEBUG 00:00:00] cards1: slow sync or testing, do full item scan to detect
changes
[DEBUG 00:00:00] starting PROPFIND, credentials unverified, deadline in 300.0s
ah_create, for WWW-Authenticate
Running pre_send hooks
[DEBUG 00:00:00] forced sending credentials
Sending request headers:
PROPFIND /muelli/cards/ HTTP/1.1
Keep-Alive:
Connection: TE, Keep-Alive
TE: trailers
Host: ${URL}
Depth: 1
Content-Length: 141
Content-Type: application/xml
Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Sending request-line and headers:
Doing DNS lookup on ${URL}...
req: Connecting to ip.ip.ip.ip:80
Sending request body:
Body block (141 bytes):
[<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"><prop>
<getetag xmlns="DAV:"/>
<resourcetype xmlns="DAV:"/>
</prop></propfind>
]
Request sent; retry is 0.
[status-line] < HTTP/1.1 207 Unknown
[hdr] Date: Wed, 24 Oct 2012 10:32:09 GMT
Header Name: [date], Value: [Wed, 24 Oct 2012 10:32:09 GMT]
[hdr] Server: Apache
Header Name: [server], Value: [Apache]
[hdr] DAV: 1, 2, 3, calendar-access, addressbook, extended-mkcol
Header Name: [dav], Value: [1, 2, 3, calendar-access, addressbook,
extended-mkcol]
[hdr] Content-Length: 2289
Header Name: [content-length], Value: [2289]
[hdr] Keep-Alive: timeout=15, max=100
Header Name: [keep-alive], Value: [timeout=15, max=100]
[hdr] Connection: Keep-Alive
Header Name: [connection], Value: [Keep-Alive]
[hdr] Content-Type: text/xml
Header Name: [content-type], Value: [text/xml]
[hdr]
End of headers.
Running post_headers hooks
Reading 2289 bytes of response body.
Got 1160 bytes.
Read block (1160 bytes):
[<?xml version="1.0"?>
<multistatus xmlns="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<response>
<href>/muelli/cards/</href>
<propstat>
<prop>
<getetag>"-7768052930791486994"</getetag>
<resourcetype>
<C:calendar />
<collection />
</resourcetype>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/muelli/cards/3c59174f-d09b-43aa-9eee-26f3740c0ac7.vcf</href>
<propstat>
<prop>
<getetag>"6142677616598662413"</getetag>
<resourcetype />
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/muelli/cards/13fc9240-91c7-4644-95e1-033729e236cb.vcf</href>
<propstat>
<prop>
<getetag>"-793186154807718785"</getetag>
<resourcetype />
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/muelli/cards/1ec200d5-735b-4d16-a0cd-0bcfb0923fa4.vcf</href>
<propstat>
<prop>
<getetag>"-7419273146883220427"</getetag>
<resourcetype />
</prop>
<status>HTTP/1.1 200]
[DEBUG 00:00:00] item 3c59174f-d09b-43aa-9eee-26f3740c0ac7.vcf = rev
6142677616598662413
[DEBUG 00:00:00] item 13fc9240-91c7-4644-95e1-033729e236cb.vcf = rev
-793186154807718785
Reading 1129 bytes of response body.
Got 1129 bytes.
Read block (1129 bytes):
[ OK</status>
</propstat>
</response>
<response>
<href>/muelli/cards/342F8BEA-54AC0772-04A3D2F6.vcf</href>
<propstat>
<prop>
<getetag>"6187965458013749004"</getetag>
<resourcetype />
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/muelli/cards/1e91aa4d-11ca-4580-bc35-2ba170338837.vcf</href>
<propstat>
<prop>
<getetag>"6030810582171879567"</getetag>
<resourcetype />
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/muelli/cards/2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac.vcf</href>
<propstat>
<prop>
<getetag>"-6196304151567771931"</getetag>
<resourcetype />
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/muelli/cards/72e42321-92d7-4197-b150-1ee77a370645.vcf</href>
<propstat>
<prop>
<getetag>"3294707919730409193"</getetag>
<resourcetype />
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
]
[DEBUG 00:00:00] item 1ec200d5-735b-4d16-a0cd-0bcfb0923fa4.vcf = rev
-7419273146883220427
[DEBUG 00:00:00] item 342F8BEA-54AC0772-04A3D2F6.vcf = rev 6187965458013749004
[DEBUG 00:00:00] item 1e91aa4d-11ca-4580-bc35-2ba170338837.vcf = rev
6030810582171879567
[DEBUG 00:00:00] item 2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac.vcf = rev
-6196304151567771931
[DEBUG 00:00:00] item 72e42321-92d7-4197-b150-1ee77a370645.vcf = rev
3294707919730409193
Running post_send hooks
ah_post_send (#0), code is 207 (want 401), WWW-Authenticate is (none)
Request ends, status 207 class 2xx, error line:
207 Unknown
[DEBUG 00:00:00] credentials accepted
Running destroy hooks.
Request ends.
13fc9240-91c7-4644-95e1-033729e236cb%2evcf
1e91aa4d-11ca-4580-bc35-2ba170338837%2evcf
1ec200d5-735b-4d16-a0cd-0bcfb0923fa4%2evcf
2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac%2evcf
342F8BEA-54AC0772-04A3D2F6%2evcf
3c59174f-d09b-43aa-9eee-26f3740c0ac7%2evcf
72e42321-92d7-4197-b150-1ee77a370645%2evcf
sess: Destroying session.
On the server side, I hav e the following in
> the collection:
>
> BEGIN:VCALENDAR
> PRODID:-//Radicale//NONSGML Radicale Server//EN
> VERSION:2.0
> BEGIN:VCARD
That looks suspicious. Normally VCARDs are not stored inside VCALENDAR.
uh. interesting. Maybe a radicale bug. Apparently, it's not a very nice
Ca{rd,l}DAV server as it doesn't care about standards so much (besides it being
*very* slow with a couple of hundred items). But it still seems to be nicest
server out there :-\
--
You are receiving this mail because:
You are on the CC list for the bug.
4:39 p.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
--- Comment #5 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to comment #4)
[...]
I'll reply to the usability comments separately (and later - not much time
right now).
> > I do get empty vcards, however.
>
> The output of
> SYNCEVOLUTION_DEBUG=1 syncevolution --daemon-no --export -
> target-config@radicale cards1
>
> would be useful.
>
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --print-items
target-config@radicale cards1
That's not quite what I would like to see - please retry with "--export -"
instead of "--print-items". The --print-items does not try to get any content
data.
Maybe a radicale bug. Apparently, it's not a very nice
Ca{rd,l}DAV server as it doesn't care about standards so much (besides it
being *very* slow with a couple of hundred items). But it still seems to be
nicest server out there :-\
It's the easiest to set up from scratch. DAViCal is another, a lot more
standard-compliant alternative. It installs easily on Debian.
--
You are receiving this mail because:
You are on the CC list for the bug.
11:37 p.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
--- Comment #6 from Tobias Mueller <fdo-bugs(a)cryptobitch.de> ---
Created attachment 69048
--> https://bugs.freedesktop.org/attachment.cgi?id=69048&action=edit
syncevolution --export -
(In reply to comment #5)
That's not quite what I would like to see
oups. Faux pas on
my side. I didn't read carefully enough. Sorry. The data is
attached.
FWIW: I get interesting log messages on the server side whenever I do the
export:
Oct 25 01:11:46 hostname grsec: From ip.ip.ip.ip: denied RWX mmap of <anonymous
mapping> by /usr/sbin/apache2[apache2:3603] uid/euid:500/500 gid/egid:500/5
00, parent /usr/sbin/apache2[apache2:2813] uid/euid:0/0 gid/egid:0/0
That is a grsec hardened kernel probably complaining about the Python
interpreter. Which is weird, because other Python processes do not cause this
message. Anyway, the exported vcards look good.
--
You are receiving this mail because:
You are on the CC list for the bug.
6:37 a.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
--- Comment #7 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to comment #6)
Created attachment 69048 [details]
syncevolution --export -
(In reply to comment #5)
> That's not quite what I would like to see
oups. Faux pas on my side. I didn't read carefully enough. Sorry. The data
is attached.
It shows that the server encapsulates the VCARD inside a VCALENDAR, just like
it did in its internal storage. That's incorrect and cannot be parsed by
SyncEvolution: --export just dumps the data, but syncing needs to parse it and
thus fails.
I've no idea why Radicale does this - please bring it up there and report back
here.
--
You are receiving this mail because:
You are on the CC list for the bug.
1:06 p.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
--- Comment #8 from Tobias Mueller <fdo-bugs(a)cryptobitch.de> ---
(In reply to comment #7)
It shows that the server encapsulates the VCARD inside a VCALENDAR,
just
like it did in its internal storage. That's incorrect and cannot be parsed
by SyncEvolution: --export just dumps the data, but syncing needs to parse
it and thus fails.
I've no idea why Radicale does this - please bring it up there and report
back here.
hm. I can't reproduce. So while experimenting, I must have made some weird
requests or mixed things up. I guess the empty VCards are not a problem then.
--
You are receiving this mail because:
You are on the CC list for the bug.
1:13 p.m.
New subject: [Bug 56263] Can't synchronise CardDAV with Basic Auth
https://bugs.freedesktop.org/show_bug.cgi?id=56263
--- Comment #9 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to comment #4)
(In reply to comment #3)
> In other words, add a setup wizard mode to the command line. That's doable,
> but also quite a bit of work.
>
Hm. Maybe not exactly a wizard with steps and all. But in the case of CalDAV
or CardDAV, it should be possible to check the remote contents for being
either calendar, todolist or addressbook data, I think.
The command line as it stands today manipulates and uses configs. Any kind of
code which helps creating configs for specific use cases is a separate layer,
which today doesn't exist in the command line.
I'm unsure how to move forward though. Add that layer for the creation of
configs? All other operations then would still expose the user to the details.
Or add some high-level config which then gets translated into the actual mode
of operation underneath?
> Did the terminology section help? It should have. If not, I need
to reword
> it.
>
Hm. I don't know. It's just so much text. Every time I read it, I feel it's
totally clear. But shortly after that, when trying to interact with
SyncEvolution, that feeling is gone and total confusion and frustration
kicks in. Many things seem to be implicit and it's not immediately clear
what the things are, that I give a name, i.e. "target-config@radicale",
"calendar1", "radicale".
Would a command line syntax that doesn't use positional arguments be better? On
the one hand, the current syntax allows very short commands ("syncevolution
radicale calendar").
On the other hand, combined with the lack of constraints for config names,
detecting user errors is hard: "syncevolution --foo bar" uses "--foo"
as config
name, which is not what the user wanted.
The alternative would be "syncevolution --config radicale --source calendar"
where "--source" may be repeated multiple times.
And if anything goes wrong, the sanest thing to do
seems to be to mv ~/.config/syncevolution out of the way, because I find it
not discoverable which part failed due to which configuration (and how to
change it then). That also adds to the frustration.
Understandable. I try to remedy that by listing individual steps in the HOWTOs
(like using the target side in isolation), but it's hard to discover that.
Anyway, maybe a picture would help. For various use cases. For me, I
would
probably appreciate a picture with PC, a "cloud", several databases and the
relevant terms attached to them.
Okay. So, who draws one? ;-/
--
You are receiving this mail because:
You are on the CC list for the bug.
8:02 a.m.
New subject: [Bug 56263] CardDAV: "--status target-config@radicale cards" aborts
https://bugs.freedesktop.org/show_bug.cgi?id=56263
Patrick Ohly <patrick.ohly(a)gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
Summary|Can't synchronise CardDAV |CardDAV: "--status
|with Basic Auth |target-config@radicale
| |cards" aborts
--- Comment #10 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to comment #2)
(In reply to comment #1)
> > $ syncevolution --daemon=no --status target-config@radicale
cards1
> Oh, I see: the very first time a source is used it goes through
yet another
> code path. The downside of trying to minimize requests - many special cases
> :-(
So shall this bug be about tracking that crasher, then?
Yep.
I've fixed the abort. While doing it, I realized that "--status
target-config@..." cannot really report on the status of the target side of the
sync, because nothing in the command line identifies *which* sync is meant to
be reported on: the same target config can be used in multiple sync configs,
therefore the meta data which tracks changes is attached to the sync config,
not the target config.
I know, not obvious, despite being internally consistent :-/
I've opened a feature request for adding more error messages when a target
config is used in operations where it makes no sense: bug #57145.
This also includes an error for attempting to sync the target config (as in
comment #0).
--
You are receiving this mail because:
You are on the CC list for the bug.
3027
days inactive
3052
days old
syncevolution-issues@syncevolution.org
10 comments
1 participants
participants (1)
-
bugzilla-daemon＠freedesktop.org