[SyncEvolution] OneWay: Radicale to Google Calendar | Test
by api984
Hello,
I am trying out SyncEvolution. Currently I would try to
sync one way from Radicale to Google Calendar.
I read documentation.
But its hard to get some examples or more detail in docs. I am trying to
sync
Radicale CALDAV to Google Calendar. Radicale is company local
caldav server for calendaring and it works
pretty well. Since
Blackberry can't speak to CALDAV servers I am trying to sync to google
calendar.
If you ask why don't you use google instead of Radicale I
would say because we use thunderbird and
lightning and Lightning seems
to break a lot when using Google calendar. It's a bug I think with
authentification inside lightning. To avoid this I used radicale
instead.
Sync would look like?:
Radicale -> Local db (ical)
Local
-> google calendar
Or it can go directly?
I am still learning and
reading how to use syncevolution properly.
I am using SyncEvolution
1.2.2 on Ubuntu 10.04. LTS (workstation).
PS. Is there any way to
install it on Centos 5.2 x64 (server)?
Thank you.
--
Andrej
Pintar
email : api984(a)gmail.com
andrej(a)skrad.com
api984(a)api984.net
web: http://www.api984.net
contact cell: 00385 98 790
639
home server: http://anetlocal.poweredbyclear.com
ICQ:
191748772
Skype: api9841
Twitter: api984
MSN: fatallord(a)hotmail.com
IRC:
api984, freenode.net
::Software is like sex: it's better when it's
free::
9 years, 11 months
[SyncEvolution] one-way sync + sync tokens not updated
by Patrick Ohly
Hello!
SyncEvolution's ActiveSync backend is the first one which uses the
string tokens in StartDataRead() and EndDataWrite(). The backend always
runs inside a binfile-based SyncML client.
In one particular test I am using a "one-way-from-server" sync,
initiated by the client, and noticed a problem: the new token created by
the backend in EndDataWrite() was not passed to the StartDataRead() in
the next sync.
The backend cannot handle that, because the tokens come directly from
ActiveSync, which only allows reusing old tokens in a few limited cases.
In this case, the server rejected the obsolete token, causing an
unexpected slow sync.
Full log is here:
http://syncev.meego.com/2012-08-16-17-03_all/testing-amd64/14-exchange/Cl...
It has no debug output explaining the problem. I tracked it down to
this:
// save end of session state
localstatus TCustomImplDS::implSaveEndOfSession(bool aUpdateAnchors)
{
localstatus sta=LOCERR_OK;
PDEBUGBLOCKCOLL("SaveEndOfSession");
// update TCustomImplDS dsSavedAdmin variables (other levels have already updated their variables
if (aUpdateAnchors) {
if (!fRefreshOnly || fSlowSync) {
...
// also update opaque reference string possibly needed in DS API implementations
fPreviousToRemoteSyncIdentifier = fCurrentSyncIdentifier;
=> PDEBUGPRINTFX(DBG_ADMIN+DBG_DBAPI+DBG_EXOTIC,("updating sync token (fPreviousToRemoteSyncIdentifier) from %s to current sync token %s",fPreviousToRemoteSyncIdentifier.c_str(),fCurrentSyncIdentifier.c_str()));
} else {
=> PDEBUGPRINTFX(DBG_ADMIN+DBG_DBAPI+DBG_EXOTIC,("keeping old sync token (fPreviousToRemoteSyncIdentifier) %s instead of updating to current sync token %s",fPreviousToRemoteSyncIdentifier.c_str(),fCurrentSyncIdentifier.c_str()));
}
I added that debug output. It confirms that the "keeping old sync token"
branch is taken.
What is the rationale here? Is the goal perhaps that if the client
switches back to a two-way sync, all changes since the last two-way sync
get sent, despite the intermediate one-way sync?
Those changes include the changes made on behalf of the server during
the one-way-from-server sync. Is that filtered out?
My test is probably broken. IMHO one-way sync only makes sense into a
storage which never changes on the receiving side. In the ActiveSync
case, that cannot be guaranteed, so I might as well just skip the test.
OTOH, a user might decide to use an ActiveSync server as remote backup,
in which case one-way syncing makes sense again. Would it be acceptable
to always take the "updating sync token" branch above?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
9 years, 11 months
[SyncEvolution] issues with syncing photos
by Vladimir Elisseev
Hello,
I'm having some issues with synchronizing photos. In my setup I'm using
Funambol as a server, clients are Syncevolution and Funambol for
android. The problem appears in the following case:
1. the "Test" contact has been modified on the android device (any field
besides photo)
2. syncing with syncevolution gives a lot of lines with the same warning
"[WARNING] libebook: invalid character found in parameter spec", but
synchronization completed "successfully" and... photo's gone.
I'd appreciate any thoughts regarding this problem.
Regards,
Vlad.
9 years, 12 months
[SyncEvolution] Nokia N9 sync with task and notes support
by Michael Kummer
I use syncevolution on my N9 and it works perfectly with funambol calendar
and contacts. But I found no solution to sync also tasks and notes. What is
necessary to make it? Is it a hard show stopper or more a question of time
to write the code? I'am not a developer, only an interested user. Is this an
issue related to the N9 or related to funambol? Memotoo seems to have a sync
with tasks included, but not with notes.
I think there are more users of the N9 interested in a full working
solution.
Thank you very much for your help,
Michael
10 years
[SyncEvolution] SyncEvolution 1.2.99.3 and 1.2.99.4 released, bug tracking at freedesktop.org
by Patrick Ohly
Hello all!
Work towards the 1.3 release of SyncEvolution continued with two more
snapshots since the last announcement.
The project also moved its bug tracking from bugs.meego.com to
bugs.freedesktop.org. Most of the old issues were already migrated, the
rest will follow later. Please file new issues there:
http://bugs.freedesktop.org/enter_bug.cgi?product=SyncEvolution
The git repos are still at meego.com; they will move to freedesktop.org
eventually.
SyncEvolution 1.2.99.3 -> 1.2.99.4, 07.08.2012
==============================================
Another release candidate for SyncEvolution 1.3. Lesson learned:
declaring a snapshot as "final" is a good way of luring the hidden bugs
into the light. Of course, then another snapshot is needed...
Details:
* D-Bus server: fix support for autoSyncDelay > 0
Auto syncing was not getting triggered when using an autoSyncDelay > 0;
by default it is 5 minutes. Thanks to Vladimir Elisseev for reporting
this problem.
* command line: fixed --export <file name>
When exporting items into a file, the delimiter between items
was missing.
* config: improved 'maxlogdirs' documentation
The old explanation made it sound like nothing would get deleted by
default ("If set, ..."). That's not correct, by default only 10
sessions are kept.
Also explain the behavior of deleting intermediate sessions first.
* developers: fixed D-Bus interface XML
Reverted to Qt 4.x compatible annotations and changed "templateName"
to "getTemplate" to make it more obvious what the parameter does.
Only relevant for the out-of-tree Qt UI.
Fixed accidental removal of the "template" parameter in
Session.GetNamedConfig(). Was not used in practice, but has to be
correct in case that someone wants to use it.
SyncEvolution 1.2.99.2 -> 1.2.99.3, 24.07.2012
==============================================
Final release candidate for SyncEvolution 1.3 - fingers crossed,
knock on wood, etc.
ActiveSync is now available in binaries from syncevolution.org and
becomes the recommended way of synchronizing contacts with Google. EDS
3.5.x and later are supported when compiling from source;
syncevolution.org binaries continue to support only EDS up to 3.4.
Details:
* EDS: added support for EDS 3.5.x
When compiled against EDS 3.5.x or later, SyncEvolution now uses
the backend code originally written for the EClient API introduced
in EDS 3.2. That code was changed so that it works with the new
include file rules and ESourceRegistry in EDS 3.5.x. Support
for using the EClient API with EDS 3.4 was removed because maintaining
three different flavors of the EDS backend code would be too much
work and not gain much (just the possibility to test the EDSClient
code with 3.4).
At the moment, this is a compile time choice made automatically
by configure. syncevolution.org binaries are compiled against
an older EDS and thus do not work with EDS 3.5.x or later.
EDS 3.5.x handles authentication itself, using a standard system
prompt if necessary. SyncEvolution can no longer provide the password,
and thus the "databaseUser/Password" options have no effect when using
EDS 3.5.x.
* ActiveSync: updated to work with latest activesyncd and Google, package binaries
Syncing Google contacts was added to the nightly testing. Syncing
contacts and events with Exchange 2012 was already working. Setup
instructions and known issues are described here:
https://syncevolution.org/wiki/google-contacts-activesync
* local sync: don't drop data comparison output on target side
synccompare on the target side of a local sync was invoked with its
output being redirected via an unreliable socket to the local sync
parent. When the output was large, some of it might have been lost.
* local sync: fixed crash
When processing stdout from syncevo-local-child in
syncevo-dbus-helper, the LogRedirect class was invoked recursively and
tried to print the same stdout data repeatedly until the
syncevo-dbus-helper crashed due to the infinite recurssion.
* local sync: fixed helper process shutdown in case of parent failure
The helper process only detected that the parent failed when
it tried to log something while the parent had already shut down
the D-Bus connection. Even that did not work reliably and differed
between D-Bus libdbus and GIO.
Added several test cases and fixes for "process died prematurely"
error scenarios.
* Mobical (aka Everdroid): stopped testing memo syncing
Memos used to work, but now only trigger an unspecific 400 error
on the server side.
* autotools: ensure that link lines are complete
As mentioned by Tino Keitel on the mailing list, some libs and
executables were only implicitly linked against libraries that they
called directly. This happened to work by chance because these libraries
ended up in the running executable anyway, due to indirect loading.
Now there is a "make installcheck" test for this kind of defect
and the makefiles were updated to avoid it.
One exception is libsmltk, which depends on the caller providing
SySync logging support.
* D-Bus server: fixed HTTP presence for recent libdbus
Testing with libdbus 1.6.0 on Debian Testing failed because the lib
changed some behavior: instead of looking up the owner of a certain
bus name immediately, it now does that when invoking a
method. Therefore the check for "have connection" in SyncEvolution
was too simplistic and missed the fact that both were not usable,
causing the server to assume that HTTP was down while in reality it
should have assumed it to be up. This prevented auto-syncing and
manually clicking "Sync" in the GTK UI.
* syncevolution.org: declare dependencies on libical and EDS
Let the bundle .deb depend on libical if the lib was enabled during
compilation (for example, for CalDAV). This ensures that it gets
installed on systems which otherwise don't have it.
"syncevolution-evolution" is compatible (and depends on) EDS up to
and including 3.4. The package now declares that dependency and
conflicts with more recent EDS, because even if the older EDS libs
are still installed they won't work when the rest of EDS was
updated.
* CalDAV + syncevolution.org: fixed segfault without libical+libecal
When libical and libecal were not installed, trying to use the CalDAV
backend for VEVENTs segfaulted because it depends on libical and did
not check properly for it. Only affected syncevolution.org binaries.
Upgrading from release 1.2.x:
The sync format of existing configurations for Mobical (aka Everdroid)
must be updated manually, because the server has encoding problems when
using vCard 3.0 (now the default for Evolution contacts):
syncevolution --configure \
syncFormat=text/x-vcard \
mobical addressbook
The Funambol template explicitly enables usage of the
"refresh-from-server" sync mode to avoid getting throttled with 417
'retry later' errors. The same must be added to existing configs
manually:
syncevolution --configure \
enableRefreshSync=TRUE \
funambol
Upgrading from releases before 1.2:
Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. Releases >= 1.2
automatically migrates configurations. The old configurations
will still be available (see "syncevolution --print-configs") but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2012/syncevolution-12993-and-12994-r...
Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources
i386, lpia and amd64 binaries for Debian-based distributions are
available via the "unstable" syncevolution.org repository. Add the
following entry to your /apt/source.list, then install
"syncevolution-evolution":
deb http://downloads.syncevolution.org/apt unstable main
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can
no longer be supported with precompiled binaries because of missing
libraries, but the source still compiles when not enabling the GUI (the
default).
The same binaries are also available as .tar.gz and .rpm archives in
http://downloads.syncevolution.org/syncevolution/evolution. In contrast
to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the
content must be moved to /usr, because several files would not be found
otherwise.
After installation, follow the
http://syncevolution.org/documentation/getting-started steps.
--
Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution possible:
http://syncevolution.org/about/contributors
10 years
[SyncEvolution] sync-ui: "Sync now" button disabled
by Vladimir Elisseev
Hello,
I've noticed that scheduled sync doesn't work anymore even if the
"Automatic sync" is checked. As well the "Sync now" button is always
grayed out, though if I run syncevolution from command line, everything
works as expected. I suppose it's something to do with dbus interaction.
I'd appreciate any ideas.
I'm using the latest version 1.2.99.2.
Regards,
Vlad.
10 years
[SyncEvolution] Nokia N9 syncevo-to-syncevo weirdness
by Justus-bulk＠Piater.name
Hi -
I have the following two symptoms, which may or may not be related:
- syncevo-http-server (run on my Debian-wheezy laptop) produces, once
for each sync (irrespective of the --sync type, and for all calendars
and for the address book):
[ERROR] sync: SYSYNC Session aborted because of LOCAL SyncML error code 408
...
[ERROR] sync: SYSYNC Rejected with error: 0 0
syncevolution (on the N9, from
http://people.debian.org/~ovek/harmattan/) happily seems to complete
the sync nevertheless, with no errors.
- Some calendar entries do not show on the N9, even though they are
present in evolution. I can create them on the N9, but once I change
them on the laptop and sync them back (--sync refresh-from-server or
two-way), they no longer show on the N9, even though they are reported
as successfully synced.
I have not found a sure-fire way to reproduce this. Some new items,
created on the laptop and synced, show on the N9; others do not.
Sometimes deleting one appointment makes other appointments suddenly
show as they should.
This renders my N9 calendar utterly useless.
I have tried, to no avail:
- --sync refresh-from-server
- totally wiping the N9 calendar by moving ~/.calendar/db out of the way
- hunting for weird or broken calendar entries in evolution ical exports
I did not notice the problem before today. Yesterday I upgraded a bunch
of things, including libsynthesis0 and libsmltk0 (both to 3.4.0.16.7-1).
Are these perhaps broken?
Unfortunately there are other recent changes on my system that may be
related:
- N9 firmware upgrade to PR1.3 last week
- evolution, libevolution, libedata-book, libecal and the likes, all
upgraded to 3.4.3-1 a week ago
Hoping that someone might give me a clue, or point out a strategy that
might yield a clue, I posted terminal output and sync logs at
https://iis.uibk.ac.at/public/piater/syncevo/.
Thanks a bunch,
Justus
10 years
[SyncEvolution] SyncEvolution git repository and bug tracking
by Patrick Ohly
Hello!
Out of convenience I was using the MeeGo Bugzilla for bug tracking and
meego.gitorious.org for the code repositories. As I was told after my
FOSDEM talk, this apparently caused some people to think of
SyncEvolution as "only for MeeGo". That's a bit surprising, given that
SyncEvolution always, and primarily, was an independent upstream
project.
Besides giving that wrong impression, there are also more practical
reasons for switching to a different infrastructure. Mixing upstream and
distro bug tracking in the same bug tracker instance could have had some
positive aspects (cross-referencing), but in practice was just
confusing. Upstream bug tracking had to use the data schema from the
distro.
So where should SyncEvolution go?
I'm currently leaning towards a personal github project:
https://github.com/pohly/SyncEvolution
github has some builtin bug tracking. That may be good enough for
SyncEvolution.
Or should I try to get it hosted on freedesktop.org? I've always thought
of SyncEvolution as something for all Linux desktops, not just for
GNOME.
Any thoughts?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10 years
