gmane.comp.mobile.syncevolution

Re: Sychronizing abook and SyncML server

Tom Kazimiers — 2012-05-24T10:29:27

Hi,

On 22.05.2012 13:02, Patrick Ohly wrote:

Yes, they are.


Sounds reasonable. If you have a commit to try out for me, I could give
you some feedback whether that was the problem.


True, I thought this would be alright as the output indicating those
local changes are produced by this sync, too. If you want I could send
you the initial sync log as well.


Thanks, I'll have a look at it.

Cheers,
Tom

_______________________________________________
SyncEvolution mailing list
SyncEvolution-iSTEHRHt8w9N2k9L2T2VtNi2O/JbrIOy< at >public.gmane.org
http://lists.syncevolution.org/listinfo/syncevolution

Re: Sychronizing abook and SyncML server

Tom Kazimiers — 2012-05-24T08:01:43

Hi,

On 23.05.2012 09:30, tino.keitel+syncevolution-rAwCM5oiXHA< at >public.gmane.org wrote:

thanks for your suggestion, I will give it a try. However, I would
prefer read-write access to the contact data. Also abook is a pretty
simple and easy CLI front-end to the address data which I would like to
keep. It is therefore likely I will look into an abook backend of
syncevolution anyway .

Cheers,
Tom

_______________________________________________
SyncEvolution mailing list
SyncEvolution-iSTEHRHt8w9N2k9L2T2VtNi2O/JbrIOy< at >public.gmane.org
http://lists.syncevolution.org/listinfo/syncevolution

Re: api/ui change: setting properties at different levels + new notifyLevel (was: Re: Help! how do I stop desktop notifications!)

Patrick Ohly — 2012-05-23T07:54:23

Good things come to those who wait... if you haven't given up waiting,
that is. My apologies for taking so long to get back to this.

A patch implementing the "notifyLevel" as described above is now in the
master branch and will be in the upcoming 1.2.99.1 pre-release of
SyncEvolution 1.3.

I've not implemented the multi-level config handling. It's complex
enough as it is...

Re: Sychronizing abook and SyncML server

2012-05-23T07:30:22

Hi,

I use lbdb to lookup email adresses in mutt. My lbdb is configured to
use the evolution-data-server addressbook, which is synced with
syncevolution.  It is read-only in mutt, though.  I don't know if this
fits your needs.

Regards,
Tino

Re: Sychronizing abook and SyncML server

Patrick Ohly — 2012-05-22T11:02:11

I have an inkling what it could be. Are these duplicates byte-identical?

The before/after comparisons are based on copying all items into the
session directories. To save space, hard links are used between
identical files. I suspect that this de-duplication is a bit too
aggressive and fails to reproduce your duplicates, although they are
still in your real data set.


The log you sent seems to be a from a sync where no data was exchanged
(not even the newly duplicated item). Never mind, let me test my theory.


It can be problem when SyncML servers expect SyncEvolution+abook to
store more data than it really supports. Normally, a SyncML server only
sends supported data and preserves unsupported data server-side. Well,
good ones do that. SyncEvolution+Synthesis as server do it, in which
case giving them wrong information about the locally supported data can
cause data loss. Doesn't matter in simple cases where all involved peers
support the same data.


https://syncevolution.org/development has some pointers. Please don't
hesitate to ask. I'm also on IRC (freenode, pohly).

Re: Sychronizing abook and SyncML server

Tom Kazimiers — 2012-05-22T09:53:16

Hi Patrick,

On 22.05.2012 09:18, Patrick Ohly wrote:

Sorry for not making me clear. A new initial sync shows no problems, the
local (file) database has (of course) no changes. Then I modify an entry
(one vCard file, say file "4") and sync it. The sync works fine, but
starting with that sync (even in the sync's own output, it looks like if
there is a --status call right after the syncing) I get the output
above. Every duplicate in the data base gets marked as "added during
sync". So if there are two identical vCard files (say "7" and "13"), one
of them (e.g. "7") will show up as "added during sync". These are not
necessarily the entries that one has been editing before. The duplicates
have been there before and I don't think they are produced by
syncevolution, gotta check this tonight. This needs some more
investigation on my side.


It was a normal two-way sync. When I found out that the duplicates might
be a problem (and I don't want duplicates anyway), I deleted them. To
avoid searching for the correct log file and to see if the can be
reproduced I just started from scratch: removed all vCards, refreshed
from the server, copied a vCard file, named it differently and started
the sync. The same problem as described above occurred. I sent the log
file to you directly. Now every sync call shows the output until I
remove the duplicate.


Alright, thanks. It's getting clearer :-).


Yes, I already noticed that. The vCard files of syncevolution are more
detailed. I did't check if this is a problem for abook, though -- will
do so in the next days.


Thanks for the hints. I will look into this if there are problems.


I am able to program C++, yes. Implementing an abook backend would IMHO
be the cleanest solution. So if there are problems with abook reading
syncevolution's more detailed vCard files, I will have look at the
source code and see if I can add an abook backend. Maybe, I'll do this
even if abook has no problems with those files. So checking out the
developer documentation is one of the next steps.

Cheers,
Tom


_______________________________________________
SyncEvolution mailing list
SyncEvolution-iSTEHRHt8w9N2k9L2T2VtNi2O/JbrIOy< at >public.gmane.org
http://lists.syncevolution.org/listinfo/syncevolution

Re: Sychronizing abook and SyncML server

Patrick Ohly — 2012-05-22T07:18:39

Modified or duplicated? What you show are added entries.


It certainly doesn't look normal. Was this a normal two-way sync or a
slow sync? During a slow sync it can happen that the SyncML server
duplicates items.

If it was a normal sync, then please send the syncevolution-log.html
file of that session. You can find it in the directory listed by
"syncevolution --print-sessions".


Correct. All peers in the same context share the same database settings.


It's quite likely that at some point you will find that abook and the
current file backend use different vCard flavors (= slightly different
properties).

The format of the file backend is a mixture of all known properties,
defined in /usr/share/syncevolution/xml/datatypes/01vcard-profile.xml.
The downside for your purpose is that the engine doesn't know about
limitations in abook and/or won't format properties exactly as needed by
abook. Not sure how much of an issue that will be.

As a first step you could modify that file directly, ignoring anything
with "rule=KDE". A cleaner solution would be needed to include your
changes back into SyncEvolution, for example by adding more conditional
sections and making the file backend format more configurable.

Or implement a backend which reads/writes abook directly... can you
program in C++?

Re: Sychronizing abook and SyncML server

Tom Kazimiers — 2012-05-21T22:53:23

Hi Patrick,

thanks for your reply.

On Sun, May 20, 2012 at 09:03:30PM +0200, Patrick Ohly wrote:

Yes, I aim for two-way synchronization. This, indeed, needs to be
handled with caution. Thanks for the hints on that.

Okay, good to know. I am still in the process of finding out how
everything ties together. But more and more things start to make sense.
I now use the simpler way suggested by you.

It now works using the approach you suggested. I might had something
configured wrongly with my previous setup. However, it seems
syncevolution has a problem with different entries having the same
content. What happens is: a first synchronisation works without
problems and also --status calls show no changes. But after I change a
file and sync it I get new output from --status and sync calls:

Data modified locally during synchronization:
*** addressbook ***
   before sync | after sync
   removed during sync <
   > added during sync
-------------------------------------------------------------------------------
   > …
   > …
…
-------------------------------------------------------------------------------

Every duplicate entry is listed there as locally modified during sync. I
did not change anything on those files, though. After having removed all
duplicates, it works without problems. I just was wondering about this
behaviour.

Thanks a lot! This makes the configuration much easier. So this
configuration adds a new peer (funambol) to the context "< at >local",
doesn't it? And because the < at >local context has a file backend the peer's
data gets stored in vCards?

It might have been due to some misconfiguration here. The
synchronisation does work now with your config.

Next I will look into getting this to work with abook.

Cheers,
Tom
_______________________________________________
SyncEvolution mailing list
SyncEvolution-iSTEHRHt8w9N2k9L2T2VtNi2O/JbrIOy< at >public.gmane.org
http://lists.syncevolution.org/listinfo/syncevolution

Re: Sychronizing abook and SyncML server

Patrick Ohly — 2012-05-20T19:03:30

Do you aim for two-way synchronization? In that case you'll have to be
more careful when exporting from abook (don't rewrite files
unnecessarily, to avoid turning every sync into a "refresh from abook")
and when importing into abook (don't overwrite data which is more
recent; can be done by always syncing abook->file->SyncML->file->abook,
as you said).


What you seem to be trying here is the configuration of a local sync
config between < at >default addressbook(= usually EDS) and < at >local
addressbook (= file). This should work, but is unnecessarily complex -
see below for a simpler way.


What changes do you make to the vCard files? It should be possible to
modify them (which must touch the last modified time stamp), add new
files (file name doesn't matter) and delete some.

It will be easier to test this when syncing Funambol directly against
your < at >local file source:
   syncevolution --configure \
                 --template funambol \
                 funambol< at >local \
                 addressbook

Strictly speaking, the "--template" parameter is redundant because
SyncEvolution would guess the right template based on the config name.

Now you can synchronize with "syncevolution funambol< at >local" and check
for changes with "syncevolution --status funambol< at >local". The latter
command will tell you which changes in the file address book
SyncEvolution sees, without changing anything.



It should be possible to do this, either as you planned or directly. I'm
not sure yet why it fails.

Sychronizing abook and SyncML server

Tom Kazimiers — 2012-05-19T18:44:33

Hi all,

I try to have two different databases in sync: abook [1] and a SyncML
server. Abook is a small address book program that integrates well with
the mail client mutt. It is able to export and import its data in
various formats, amongst them VCard. Since syncevolution is able to
handle this, it seems to be the perfect tool for the job. Using abook's
VCard export/import functionality, it will create/read one VCard file
for its whole data base. This can be split into single files for the
use with syncevolution.

I hope the actual syncing will work like this: export current abook
data to VCard, split it into one file per item, use this as the file
backend data for syncevolution, sync, combine single updated VCard files
into single files and import them back into abook.

However, after a lot of reading and fiddling with syncevolution I
couldn't manage to get it to work. I would appreciate it very much if
you could show me the right direction. This is what I did:

I added a peer (I think) for the SyncML server which seems to
synchronize fine, called funambol< at >default. Then I added another
context (that's what I think it is) for the local VCard file backend:

    syncevolution --configure backend=file \
        database=/home/tom/tmp/sync/vcard-dir \
        databaseformat=text/vcard < at >local addressbook

Based on this I created another peer, local< at >default:

    syncevolution --configure syncURL=local://< at >local \
        peerIsClient=1 sync=two-way local addressbook

Now it seems I can update my local VCard data with the help of these
two commands:

    syncevolution funambol< at >default
    syncevolution local< at >default
 
With this I am able to update the VCard folder (here:
/home/tom/tmp/sync/vcard-dir). But I don't seem to be able to get changes
from the VCard files back to the SyncML server. All the changes I make to
the VCard files are not recognized by syncevolution (I try to sync with
the last two commands as well).

Based on this I have two questions:

1. Does my approach make sense at all?
2. Why isn't my modified VCard data synced back?

Thanks in advance,
Tom

[1] http://abook.sourceforge.net/
_______________________________________________
SyncEvolution mailing list
SyncEvolution-iSTEHRHt8w9N2k9L2T2VtNi2O/JbrIOy< at >public.gmane.org
http://lists.syncevolution.org/listinfo/syncevolution

Re: Need to sync twice when using Ubuntu development release

Jane Atkinson — 2012-05-15T08:19:05

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/05/12 20:00, Patrick Ohly wrote:

This is for syncing direct with CalDAV/CardDAV via Bluetooth?

Then I'm still interested. Syncing via Evolution has improved somewhat
since I started this thread, but it still misbehaves from time to time.

It's been a while since I compiled anything, so binaries would be
appreciated.

Thanks

Jane Atkinson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPshFoAAoJEERzSJEx033j/BAH/0F77dccyTniIlG4RMOo5fXo
JDzba8ZLbH4lVz710AbAV9tZ2Mkb0d4LlpovJEY+ZcQxbaAz1v6ZyNVmTG2ogg4J
mmT4apzHHToN8xZNv8Ao91EdZbOgX5VhH5pG8q5XiEbGX7u5njp3a47KllXtygv4
ZU6B0xpiDFOYhkkBv4tgpKKwL0LHNJzTmnlUvnLdpTF1Kk3T6aKwRbYZgk4yk0N7
7/yIbont7xxw6+W1Yd5zYVYcCbxbl/Xha4yKXQPy8dxbeaduJtfegwu8ny+rGVy8
hGqklrQibCCjABg7HF3Aai412ML+7qOSfTt7X8N9eTOp9OV3F9OV/oaCFczMZ94=
=/1JU
-----END PGP SIGNATURE-----

Re: Correct way to start auto. sync

Patrick Ohly — 2012-05-15T08:42:27

Autotools should do that automatically. The startup script and .desktop
files use < at >libexecdir< at > and the startup script installs into
$libexec_dir.

Re: bridgie syncml server and caldav/card dav server

Patrick Ohly — 2012-05-15T08:04:08

I solved this (https://bugs.meego.com/show_bug.cgi?id=23764) in the
upcoming 1.3 release by checking database/databaseUser/databasePassword
in the CalDAV/CardDAV backends.

Robert, if you want, then I can make binaries available. See also my
email to Jane ("Need to sync twice when using Ubuntu development
release").

Re: Need to sync twice when using Ubuntu development release

Patrick Ohly — 2012-05-15T08:00:51

This hasn't been forgotten
(https://bugs.meego.com/show_bug.cgi?id=23764), it just didn't have high
priority. I've now added the necessary changes. Nightly testing includes
setups where CalDAV/CardDAV are used in a SyncML server and in a SyncML
client.

Jane, are you still interested? I can make binaries available, if
necessary. Otherwise just compile the "master" branches of libsynthesis
and SyncEvolution.

Further instructions are in the updated README.rst (aka man page) - see
database/databaseUser/databasePassword:

CalDAV and CardDAV
==================

This section explains how to use local syncing for CalDAV and
CardDAV. Both protocols are based on WebDAV and are provided by the
same backend. They share ``username/password/syncURL`` properties
defined in their target config.

The credentials must be provided if the server is password
protected. The ``syncURL`` is optional if the ``username`` is an email
address and the server supports auto-discovery of its CalDAV and/or
CardDAV services (using DNS SRV entries, ``.well-known`` URIs, properties
of the current principal, ...).

Alternatively, credentials can also be set in the ``databaseUser`` and
``databasePassword`` properties of the source. The downside is that these
values have to be set for each source and cannot be shared. The advantage
is that, in combination with setting ``database``, such sources can be
used as part of a normal SyncML server or client sync config. SyncEvolution
then reads and writes data directly from the server and exchanges it
via SyncML with the peer that is defined in the sync config.

The ``database`` property of each source can be set to the URL of a
specific *collection* (= database in WebDAV terminology). If not set,
then the WebDAV backend first locates the server based on ``username``
or ``syncURL`` and then scans it for the default event resp. contact
collection. This is done once in the initial synchronization. At the end
of a successful synchroniation, the automatic choice is made permanent
by setting the ``database`` property.

  **Warning:** the protocols do not uniquely identify this default
  collection. The backend tries to make an educated guess, but it might
  pick the wrong one if the server provides more than one address book
  or calendar. It is safer to scan for collections manually with
  ``--print-databases`` and then use the URL of the desired collection
  as value of ``database``.

To scan for collections, use::

   syncevolution --print-databases \
                 backend=<caldav or carddav> \
                 username=<email address or user name> \
                 "password=!< at >#ABcd1234" \
                 syncURL=<base URL of server, if auto-discovery is not supported>

Configuration templates for Google Calendar, Yahoo Calendar and a
generic CalDAV/CardDAV server are included in SyncEvolution. The Yahoo
template also contains an entry for contact synchronization, but using
it is not recommended due to known server-side issues.

The following commands set up synchronization with a generic WebDAV
server that supports CalDAV, CardDAV and auto-discovery. For Google and Yahoo,
replace ``webdav`` with ``google-calendar`` resp. ``yahoo`` and remove the
``addressbook`` source when setting up the sync config. ::

   # configure target config
   syncevolution --configure \
                --template webdav \
                username=123456-hcDgGtZH8xNBDgjK7y7TUQ< at >public.gmane.org \
                "password=!< at >#ABcd1234" \
                target-config< at >webdav

   # configure sync config
   syncevolution --configure \
                 --template SyncEvolution_Client \
                 syncURL=local://< at >webdav \
                 username= \
                 password= \
                 webdav \
                 calendar addressbook

   # initial slow sync
   syncevolution --sync slow webdav

   # incremental sync
   syncevolution webdav

Here are some alternative ways of configuring the target config::

   # A) Server has one URL as starting point instead of DNS auto-discovery.
   syncevolution --configure \
                --template webdav \
                username=123456 \
                "password=!< at >#ABcd1234" \
                syncURL=http://example.com \
                target-config< at >webdav

   # B) Explicitly specify collections (from server documentation or --print-databases).
   #    The 'calendar' and 'addressbook' names are the ones expected by the sync config
   #    above, additional sources can also be configured and/or the names can be changed.
   syncevolution --configure \
                username=123456 \
                "password=!< at >#ABcd1234" \
                addressbook/backend=carddav \
                addressbook/database=http://example.com/addressbooks/123456/ \
                calendar/backend=caldav \
                calendar/database=http://example.com/calendar/123456/ \
                target-config< at >webdav \
                calendar addressbook

Finally, here is how the ``< at >webdav`` context needs to be configured so that SyncML
clients or servers can be added to it::

   # configure sources
   syncevolution --configure \
                databaseUser=123456 \
                "databasePassword=!< at >#ABcd1234" \
                addressbook/backend=carddav \
                addressbook/database=http://example.com/addressbooks/123456/ \
                calendar/backend=caldav \
                calendar/database=http://example.com/calendar/123456/ \
                < at >webdav \
                calendar addressbook

   # configure one peer (Memotoo in this example):
   syncevolution --configure \
                 username=654321 \
                 password=^749< at >2524 \
                 memotoo< at >webdav

   # sync
   syncevolution --sync slow memotoo< at >webdav

Re: Correct way to start auto. sync

Daniel CLEMENT — 2012-05-15T07:37:14

Just a remark about the location of the syncevo-dbus-server.

The Debian/XFCE system I'm working on now doesn't have a /usr/libexec.

The syncevo-dbus-server file is under /usr/lib/syncevolution so I
believe the syncevo-dbus-server-startup.sh has to go there too (with the
path properly updated
in  /etc/xdg/autostart/syncevo-dbus-server.desktop).

Perhaps some environment variable can take care of this difference.

Best regards, Daniel Clément

Patrick Ohly wrote:

Re: syncevolution.org + SSL certificate + mailman

Patrick Ohly — 2012-05-15T07:09:04

[...]        

This was fixed by removing the forced redirect. However, browsers might
still remember the redirect. At least on my desktop, Firefox still
suffered from the problem whereas w3m and Chromium worked fine.

The shift+reload trick doesn't work, because Firefox redirects
immediately. I guess I'll have to wait for some cache entries to time
out...

Re: Trouble transferring Funambol parameters to new PC

Daniel CLEMENT — 2012-05-14T15:30:41

Thanks for your help, Patrick.

Patrick Ohly wrote:

I was able to sync from the command line, first

syncevolution --sync slow funambol

which came up with error 22001, then (to get more detail):

syncevolution --run loglevel< at >default=4 funambol

which, to my surprise, ran fine.

I think I have located the errors. I have contact lists in Evolution,
and after the sync they were incomplete. The trouble is, my phone does
not support them (it retains only one name). So as a workaround, I made
another address book in Evolution, dedicated to contact lists, which
won't get synced. (I don't find this is not particularly smart, because
if I modify a contact which is in a list, I'll have to change the list
too.)

I guess I was trying "too often", and perhaps the time it took me to do
the command-line sync was a sufficient delay. 

[...]

Re: server class + fork/exec dbus-server + command line testing

Patrick Ohly — 2012-05-14T11:58:25

Hello!

All code is now in the master branch, including the fork/exec rewrite of
syncevo-dbus-server. The full test that ran over the weekend showed that
D-Bus worked without issues across the board (Ubuntu Lucid -> Debian
Testing, with GIO D-Bus and libdbus). Thanks everyone for making this
possible.

fork/exec in syncevo-dbus-server does not help with the "fork:
out-of-memory" errors seen when running client-test under valgrind,
because the latter doesn't use D-Bus at all... I might change that, to
make the testing more realistic.

Re: Trouble transferring Funambol parameters to new PC

Patrick Ohly — 2012-05-14T09:28:47

Only some of your appointments were accepted by the server. Only a
detailed log (loglevel=4, syncevolution-log.html) will show which ones
had issues... but that doesn't match with what you said below about
appointments missing in the UI.


I've seen the same thing in last weekend's test run. For me, all tests
against onemedia.com failed. All tests I looked at had this 417 error,
which is "try again later" - in other words, don't sync too often, for
some definition of "too often".

I've asked Funambol on their user's mailing list for clarification.


Create a dummy appointment locally first. Same for memos and contacts. A
known issue when your local databases are completely empty. Will be
fixed in SyncEvolution 1.3.

Trouble transferring Funambol parameters to new PC

Daniel CLEMENT — 2012-05-14T08:47:00

Hi,

I'm really struggling to transfer my Funambol sync settings on another
system.

Previous setup was Ubuntu 10.04 (Evolution 2.28), new one is Linux Mint
LMDE with Evolution 3.2.2, to which I imported my data.

Syncevolution is the same version (1.2.2) so I just moved the
~/.config/syncevolution folder.

But now I'm locked in a loop of errors which I can't escape. I get
either
* an error 22001 for the appointments;
* errors 417 and "impossible to complete SyncML" for contacts and memos
(in either order).

I have tried to start again with an empty .config/syncevolution folder,
but then when I try to set up Funambol, it's missing the all-important
appointments checkbox.

I'm out of ideas... TIA for any advice. Regards,

Re: Problems with multiple calendars and addressbooks

Patrick Ohly — 2012-05-14T07:41:08

Looks good to me. But I've only had a very brief look; the ultimate test
will be when some other user tries to follow it.


I've turned it into a Wiki page (with proper author information), and
added a short comment at the end of the HOWTO page about how to do that.

https://syncevolution.org/wiki/multiple-databases-funambol-server