[SyncEvolution] Sync fail with status 400
by Renato Filho
I using sync evolution to sync my contacts and after a while I started
to received the error 400 during the sync and now every sync
("two-way") returns the same error.
What is causing this error?
How I should recovery from this error?
Attached you will find the log level 5 of the sync operation
Thanks
8 years, 1 month
Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
by Khurshid Alam
Hi,
I have few questions as well,
On Fri, Apr 4, 2014 at 2:22 PM, Patrick Ohly <patrick.ohly(a)intel.com>
wrote
> syncevolution --configure \
> printChanges=0 \
> loglevel=3 \
> syncURL=none \
> target-config@google
>
> Remember that the command line is doing sanity checks when creating
> new
> configs to catch typos, so we have to confirm explicitly that this new
> config is meant to be created without a syncURL.
>
> Now we need to enable access to the main-google-addressbook. It would
> be
> inactive otherwise. This is useful when configuring a peer in a
> context
> which has many different sources defined, but you only want the peer
> to
> have access to a certain subset of them. Any "sync" value other than
> "none" is okay here.
>
> syncevolution --configure \
> sync=two-way \
> target-config@google main-google-addressbook
>
Can this be done with a single command line?
syncevolution --configure \
printChanges=0 \
loglevel=3 \
syncURL=none \
target-config@google main-google-addressbook
I omitted "sync=tow-way" parameter because it can be defined when we
pair the sources....or can it?
> The next step is to set up the actual connection between @default and
> @google. We want to choose sources explicitly, so disable all sources
> which might be defined in the @default context:
>
> syncevolution --configure \
> syncURL=local://@google \
> peerIsClient=1 \
> sync=none \
> google@default
>
> Then pair the sources. We are doing that for only one pair of sources
> here, but it could also be done for more.
>
> syncevolution --configure \
> sync=two-way \
> uri=main-google-addressbook \
> google@default my-vcard-source
>
So basically in first configuration, "sync=none" disables all sources
in the @default (including my-vcard-source) & in 2nd configuration, it,
again, enables nothing but "my-vcard-source" (via sync=two-way) & pairs
it with main-google-addressbook.
This is kind of a roundabout way to me. And why do we have to do
everything with @default context? What if I configure without it:
1. syncevolution --configure \
syncURL=local://@google \
peerIsClient=1 \
google my-vcard-source
2. syncevolution --configure \
sync=two-way \
uri=main-google-addressbook \
google my-vcard-source
3. syncevolution google my-vcard-source
Here, as any other sources are not defined, they will simply remain
inactive during the sync. Aren't they?
> And now sync:
>
> syncevolution --sync slow google@default
> syncevolution google@default
>
Lets say I also have a second source enabled in the @default context:
my-vcard-source2
So this command: "syncevolution google@default my-vcard-source2" will
only sync my-vcard-source2. Right?
Thanks.
8 years, 1 month
[SyncEvolution] SyncEvolution release process
by Patrick Ohly
Hello!
I would like to try something new. So far, a release was done like this:
1. Tag the source code.
2. Run it through the automatic testing, which also produces binary
packages and source .tar.gz.
3. Check results.
4. Push to "experimental" repo, install, do some manual tests.
5. If all okay, push to "stable" repo (for stable releases) resp.
"unstable" (for pre-releases) and announce the new release.
6. If not okay, fix issues and restart from step 1.
The downside here is that new stable releases, like the upcoming 1.4.1
release, get little real world testing before being rolled out to all
users of the stable release branch (aka "stable" repo).
To avoid that, I'd like to introduce an intermediate step after 4 and
before 5 where I push the upcoming stable release update to "unstable",
announce it here on the list and/or in specific bugs that users might be
watching, and only once the release has seen some testing move it to the
"stable" repo with a formal, more widely distributed announcement. If
user testing finds regressions, the version will be superseded with a
fixed version.
This only makes sense if there really are users who are willing to pull
from "unstable" and provide feedback. Any volunteers?
Then update today from unstable and try out 1.4.1...
Changes in that release are:
SyncEvolution 1.4 -> 1.4.1, 31.03.2014
======================================
The first bug fix release in the 1.4 series addresses some issues which
occurred on some systems.
Details:
* EDS: only load one backend plugin of each kind
SyncEvolution was meant to load the syncecal or syncebook shared object
which uses the most recent libraries (libical, libecal/libebook) on
the system and then stop loooking for alternatives. Due to a string
handling bug the check for already backends always found nothing,
leading to multiple conflicting backends loaded on some systems (for
example, those with libical0 and libical1 installed).
If that happened, the backend became unusable.
* ical: workaround for libical 1.0 builtin timezone change
libical 1.0 started to return VTIMEZONE definitions with multiple
absolute transition times instead of RRULEs. This causes problems when
exchanging data with peers (see
https://sourceforge.net/p/freeassociation/bugs/95/).
In SyncEvolution, this affected sending an event using New Zealand
time in vCalendar 1.0 format to a phone, because the internal,
out-dated definition of the time zone in libsynthesis was used as
fallback when loading RRULE-based timezone definitions from libical
failed (see "[SyncEvolution] Some events showing wrong time on
phone"). It might also affect exchanging data with CalDAV peers (not
tested).
The workaround is to include the original code from libical.
* dbus-session.sh: create XDG_RUNTIME_DIR
More recent distros (for example, Ubuntu Saucy) rely on
XDG_RUNTIME_DIR. Each time dbus-session.sh runs, it must
ensure that the runtime dir exists and is empty.
This was a problem when trying to run activesyncd + SyncEvolution
on a headless Ubuntu Saucy server (see FDO #76273).
* Akonadi: support KDE Notes, enhanced "database" check
The KDE Notes resources store items under a different MIME type than the one
used in AKonadi (see "[Kde-pim] note format"). SyncEvolution use the same type
as Akonadi and thus did not find existing KDE Notes resources.
To support both while KDE and Akonadi transition to the same type,
SyncEvolution now looks for notes resources using both MIME types and accepts
both kinds of items when reading. When writing, SyncEvolution picks the MIME
type that is supported by the resource, which hopefully avoids confusing the
KDE app using the resource (untested).
As a positive side effect, the "database" value used for opening a resource is
now checked more thoroughly. Non-existent resources and the type mismatches
like pointing a "kde-contacts" backend to a calendar resource are now detected
early.
* Akonadi: ensure that UID is set (FDO #74342)
Akonadi resources do not enforce iCalendar 2.0 semantic like
"each VEVENT must have a UID" (see "[Kde-pim] iCalendar semantic").
When receiving an event from a peer which itself does not enforce
that semantic (Funambol, vCalendar 1.0 based phones), then we
need to generate a UID, otherwise KOrganizer will ignore the
imported event.
* Akonadi: avoid threading problem in HTTP server mode (FDO #75672)
When used as storage in a server, Akonadi got called in a background thread
that gets created to handle slow initialization of sources and preventing
ensuing timeouts in HTTP clients (probably not needed for Akonadi itself,
but may still be useful when combining it with other sources).
Akonadi cannot be used like that, leading to false "Akonadi not running"
errors or (if one got past that check) failing item operations.
* autotools: Add QtCore include path to KDEPIM_CFLAGS (FDO #75670)
This fixes an issue where configure fails to find Akonadi when
test programs do not compile because QString is not found.
* Enhanced testing again: faster execution, less false negatives
under load. Re-enabled testing of Akonadi.
--
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.
8 years, 1 month
Re: [SyncEvolution] Configuring a target
by Patrick Ohly
On Wed, 2014-04-02 at 08:49 +0000, Emiliano Heyns wrote:
> On 01/04/2014 18:05:50, "Patrick Ohly" <patrick.ohly(a)intel.com> wrote:
>
> >On Tue, 2014-04-01 at 16:52 +0200, Emiliano Heyns wrote:
> >> The lastest version of the script now lists my google calendar (yay!)
> >> but I can't get it to list my other calendars on the same Google Cal
> >> account.
> >
> >You are right, the database discovery is broken for Google (and
> >possibly
> >other servers). I looked into it and have a fix.
> >
> >You can get around that for now by using database=
> >https://www.google.com/calendar/dav/[calendar-ID]/events?SyncEvolution=Go...
> >with [calendar-ID] replaced by the string that Google shows in its web
> >interface when you click on "calendar settings" in the context menu of
> >the desired calendar.
> >
> Splendid, that works. BTW, I'm reply-all'ing to these messages, but
> should these go to the list instead?
Yes, it would have been good to CC the list. I thought it was on CC
already, but we must have lost it at some point during the discussion.
I'm adding it back.
> I can now access the GCal database, but if I don't pass the credentials
> on the command line, it fails or hangs. Can I store these in gconf too?
No, SyncEvolution doesn't use gconf for passwords. That activesyncd does
is kind of hacky.
In SyncEvolution, you need to use the command line to set the passwords
initially. There are ways to set the value without leaking it to other
processes:
password (no default, unshared)
password used for authorization with the peer; in addition to specifying it directly as plain text,
it can also be read from the standard input or from an environment variable of your choice:
plain text : password = <insert your password here>
ask : password = -
env variable: password = ${<name of environment variable>}
When using "-", the user needs to type it each time the password is
needed.
Under the hood, SyncEvolution stores passwords in GNOME Keyring or
KWallet. One could pre-populate that storage with a password and then
use "-", but the exact keys to find the password are not documented.
What might work better is to use password=id:<config name>, for example
password=id:google-credentials, and configure "google-credentials" with
syncevolution username=john.doe(a)googlemail.com \
password=foobar \
syncURL=https://www.googleapis.com google-credentials
This is guaranteed to use a network password in GNOME Keyring for server
www.googleapis.com and login
patrick.ohly(a)googlemail.com.
Also note that username/password access to Google services is no longer
officially supported by Google. Long-term they expect everyone to use
OAuth2. SyncEvolution can do that with the help of GNOME Online
Accounts, Ubuntu Online Accounts or gSSO. The downside is that in all
cases you need a UI at least during the initial login.
> This is how I'm setting it up:
>
> OPTIONS=
> OPTIONS="${OPTIONS} password=${GOOGLE[password]}"
> OPTIONS="${OPTIONS}
> syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google"
> OPTIONS="${OPTIONS}
> database=https://www.google.com/calendar/dav/${GOOGLE[calendar]}/events?S..."
> syncevolution --configure --template none backend=caldav
> username=${GOOGLE[email]} $OPTIONS target-config@Google
> And this is how I'm printing the DB:
>
> OPTIONS=
> OPTIONS="${OPTIONS} password=${GOOGLE[password]}"
> OPTIONS="${OPTIONS}
> database=https://www.google.com/calendar/dav/${GOOGLE[calendar]}/events?S..."
> syncevolution --print-databases username=${GOOGLE[email]} backend=caldav
> $OPTIONS
> Setting up the actual sync (exchange-local so far -- on to google once I
> understand this) is still mystifying. This is what works (for Exchange
> <-> Local), but I have no idea why:
>
> # TODO: I thought "syncevolution --configure" set up a peer...
What --configure creates depends on what config name and source name(s)
(if any) are given.
> is the
> x@y automatically a sync config between peers?
Only if you configure it for that. The key property here is the syncURL.
It determines what the config syncs with.
> Does this set up all
> possible (cal-cal, contact-contact) pairings?
> syncevolution --configure --template none username= password=
> printChanges=1 Exchange@Local
No. If you don't use a template, no sources (and thus no such pairings)
will be configured.
Also note that the template is only relevant when creating a new config.
Once the config exists, such a --configure operation will merely update
the given properties.
> # TODO: Seems to be necessary but I don't know what it does.
> syncevolution --configure syncUrl=local://@Exchange peerIsClient=1
> Exchange@Local
It declares that Exchange@Local is meant to sync with the
target-config@Exchange, which is the config where access to Exchange
gets defined.
> # TODO -- what is the meaning of 'uri=contacts' here? The docs say "is
> added to the end of the server URL". Is this then the actual sync setup
> between contacts-exchange and contacts-local?
> syncevolution --configure sync=two-way uri=contacts Exchange@Local
> contacts
> syncevolution --configure sync=two-way uri=calendar Exchange@Local
> calendar
Sources have names on both sides of a sync. The names can be identical
(as in this example), in which case specifying the uri is optional. The
names can also be different, for example "my-personal-contacts" locally
and "default-addressbook" remotely, in which case uri must be used to
match the two.
> # TODO -- why are we setting up two-way sync here again? Isn't this
> part of the peer setup I did earlier?
> syncevolution --configure --template none username=${EXCHANGE[email]}
> password= printChanges=1 target-config@Exchange
This defines how to access Exchange. This is different from the
definition of the local storage.
> # TODO -- What is the meaning of the last contacts/calendar in these
> lines? Shouldn't this be part of the peer setup rather than the sync
> setup?
> syncevolution --configure sync=two-way uri=contacts
> target-config@Exchange contacts
> syncevolution --configure sync=two-way uri=calendar
> target-config@Exchange calendar
This *is* the peer (target-config@Exchange). uri in this context
specified a name alias, which means that (if the value was different,
which it isn't here) the same source can be addressed under different
names.
Using different names is not recommended, though, because it confuses
the Synthesis engine a bit. It's only needed for clients that use fixed
uris and a server setup where sources cannot be named as expected by
that one client (think of a server config which has to work for two
different clients).
--
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.
8 years, 1 month
