4 SyncEvolution synchronizes personal information management (PIM) data
5 like contacts, calendars, tasks and memos via the SyncML information
6 synchronization standard. It supports all of these for GNOME's
7 Evolution and contacts for the system address book of the Nokia
8 Internet Tablets, Mac OS X and (at one point, but not anymore) the
9 iPhone. The command-line tool 'syncevolution' (compiled separately for
10 each of these platforms) executes the synchronization. On platforms
11 with GTK, the 'sync-ui' provides a graphical user interface. The
12 project 'Genesis' (available separately) implements a graphical
13 frontend that sits in the system tray.
15 The items are exchanged in the vCard 2.1/3.0, iCalender 2.0/vCalendar 1.0
16 and textual format via the open source Synthesis SyncML engine,
17 which makes SyncEvolution compatible with the majority of SyncML
18 servers. Full, one-way and incremental synchronization of items are
21 SyncEvolution does not synchronize with another SyncML capable device
22 or another computer directly. A SyncML server that that device and
23 SyncEvolution can talk to is needed. There are several options for
25 - using a web service like ScheduleWorld or myFUNAMBOL which store
26 the data to be synchronized on a server and provide access to it
28 - installing a SyncML server like the free one from Funambol on
30 - installing a SyncML server on the desktop
33 The recommended solution is ScheduleWorld because it is easier than
34 setting up a server and provides better support for vCard and
35 iCalendar data than the stock Funambol server installation. Setting up
36 a server on the desktop has the additional problem that not all mobile
37 devices can communicate with the desktop via HTTP.
39 All SyncML synchronization modes are supported by SyncEvolution:
40 - exchanging just the changes between client and server ("two-way")
41 - sending just the changes in one direction ("one-way-from-client/server")
42 - replacing all items with the ones stored in the peer
43 ("refresh-from-client/server")
44 - a full synchronization where all items are sent to the server and
45 the server then decides which items need to be deleted, added or
46 updated on the client ("slow")
48 The remainder of this document assumes that either Funambol's
49 myFUNAMBOL service or ScheduleWorld are used: because ScheduleWorld is
50 based on the Funambol server, configuration and usage are often
53 With a server that fully supports SyncML and vCard/iCalender
55 - copy a complete database to the server and restore it
57 - delete or modify an item locally, then make the same change
59 - delete, modify or add items on the server (by synchronizing with
60 another client or using a web interface), then apply the same
62 - conflict resolution (where two clients modify the same item,
63 then sync with the server) is handled by the server, but
64 SyncEvolution has support which ensures that no data is lost
65 by creating duplicates (see "Conflict Resolution" below)
67 For conflict resolution and synchronization between clients which
68 support different attributes of items the server needs an
69 understanding of the format of items. The Funambol server supports
70 that for contacts, but not yet for the calendar events and tasks that
71 SyncEvolution sends; see "Configuration with Funambol" below for more
72 information. ScheduleWorld also works with SyncEvolution for
79 To install SyncEvolution, just unpack an archive with a precompiled
80 binary for your platform in a directory of your choice or install one
81 of the packages. Then create a configuration as described below under
82 "Configuration". No special environment variables are needed, although
83 one might want to add the directory which contains the "syncevolution"
84 binary to the shell's PATH variable.
86 When a binary packages is not available for the target system
87 and/or is not up-to-date, compiling from source can also be used
88 to produce a binary. See below in "Compiling from Source" for details.
90 Although all of the features are covered by unit testing and
91 have been verified to work, it is highly recommended that you
93 $HOME/.evolution/addressbook
94 $HOME/.evolution/calendar
95 $HOME/.evolution/tasks
96 $HOME/.evolution/memos
97 directories before running SyncEvolution for the first time with
98 Evolution. In older Evolution versions the same data is found in
101 Configuration templates for SyncML servers are searched in the following
103 - "default/syncevolution" inside --sysconfdir DIR, usually
104 /etc/default/syncevolution (when packaged for a distribution) or
105 /usr/local/etc/default/syncevolution (when compiling from source)
108 The properties defined in a template override the default properties,
109 so usually only those properties which specifically need to be set for
110 a certain server should be listed in its template config.
116 Currently SyncEvolution comes as a simple command line tool which is
117 configured via files. The general synopsis of the command line
120 syncevolution [<options>] [<server>] [<source> ...]
122 The <server> and the <source> strings are used to find the
123 configuration files which determine how synchronization is going to
124 proceed. Each source corresponds to one local address book, calendar,
125 task list or set of memos and the corresponding database on the
126 server. Depending on which parameters are given, different operations
131 If no arguments are given, then SyncEvolution will list all available
132 data sources regardless whether there is a configuration file for them
133 or not. The output includes the identifiers which can then be used to
134 select those sources in a configuration file. For each source one can
135 set a different synchronization mode in its configuration file.
137 syncevolution <server>
139 Without the optional list of sources all sources which are enabled in
140 their configuration file are synchronized.
142 syncevolution <server> <source> ...
144 Otherwise only the ones mentioned on the command line are active. It
145 is possible to configure sources without activating their
146 synchronization: if the synchronization mode of a source is set to
147 "none", the source will be ignored. Explicitly listing such a source
148 will synchronize it in "two-way" mode once.
150 Progress and error messages are written into a log file that is
151 preserved for each synchronization run. Details about that is found in
152 the "Automatic Backups and Logging" section below. All errors and
153 warnings are printed directly to the console in addition to writing
154 them into the log file. Before quitting SyncEvolution will print a
155 summary of how the local data was modified. This is done with the
156 "synccompare" utility script described in the "Exchanging Data"
159 When the "logdir" option is enabled (since v0.9 done by default for
160 new configurations), then the same comparison is also done before the
161 synchronization starts.
163 In case of a severe error the synchronization run is aborted
164 prematurely and SyncEvolution will return a non-zero value. Recovery
165 from failed synchronization is done by forcing a full synchronization
166 during the next run, i.e. by sending all items and letting the SyncML
167 server compare against the ones it already knows. This is avoided
168 whenever possible because matching items during a slow synchronization
169 can lead to duplicate entries.
171 After a successful synchronization the server's configuration file is
172 updated so that the next run can be done incrementally. If the
173 configuration file has to be recreated e.g. because it was lost, the
174 next run recovers from that by doing a full synchronization. The risk
175 associated with this is that the server might not recognize items that
176 it already has stored previously which then would lead to duplication
179 syncevolution --configure <options for configuration> <server> [<source> ...]
181 Options in the configuration can be modified via the command
182 line. Source properties are changed for all sources unless sources are
183 listed explicitly. Some source properties have to be different for
184 each source, in which case syncevolution must be called multiple times
185 with one source listed in each invocation.
187 syncevolution --remove <server>
189 Deletes the configuration of the selected server. Note that there is
190 no confirmation question. Neither local data referenced by the
191 configuration nor the content of log dirs are deleted.
193 syncevolution --run <options for run> <server> [<source> ...]
195 Options can also be overridden for just the current run, without
196 changing the configuration. In order to prevent accidentally running a
197 sync session when a configuration change was intended, either
198 --configure or --run must be given explicitly if options are specified
201 syncevolution --status <server> [<source> ...]
203 Prints what changes were made locally since the last synchronization.
204 Depends on access to database dumps from the last run, so using the
205 "logdir" option is recommended.
207 syncevolution --print-servers
208 syncevolution --print-config [--quiet] <server> [sync|<source> ...]
209 syncevolution --print-sessions [--quiet] <server>
211 These commands print information about existing configurations. When
212 printing a configuration a short version without comments can be
213 selected with --quiet. When sources are listed, only their
214 configuration is shown. "Sync" instead or in combination with sources
215 lists only the main server configuration.
217 With --print-session information about previous synchronization sessions
218 for the selected server are printed. This depends on the "logdir" option.
219 The information includes the log directory name (useful for --restore)
220 and the synchronization report. In combination with --quiet, only the
223 syncevolution --restore <session directory> --before|--after [--dry-run] <server> <source> ...
225 This restores local data from the backups made before or after a
226 synchronization session. The --print-sessions command can be used to
227 find these backups. The source(s) have to be listed explicitly. There
228 is intentionally no default, because as with --remove there is no
229 confirmation question. With --dry-run, the restore is only simulated.
231 The session directory has to be specified explicitly with its path
232 name (absolute or relative to current directory). It does not have to
233 be one of the currently active log directories, as long as it contains
234 the right database dumps for the selected sources.
236 A restore tries to minimize the number of item changes (see section
237 "Item Changes and Data Changes"). This means that items that are
238 identical before and after the change will not be transmitted anew to
239 the server during the next synchronization. If the server somehow
240 needs to get a clean copy of all items on the client then, use "--sync
241 refresh-from-client" in the next run.
244 Here is a full description of all <options> that can be put in front
245 of the server name. Whenever an option accepts multiple values, a
246 question mark can be used to get the corresponding help text and/or
247 a list of valid values.
251 Temporarily synchronize the active sources in that mode. Useful
252 for a "refresh-from-server" or "refresh-from-client" sync which
253 clears all data at one end and copies all items from the other.
256 Prints the names of all configured servers to stdout.
259 Prints the complete configuration for the selected server
260 to stdout, including up-to-date comments for all properties. The
261 format is the normal .ini format with source configurations in
262 different sections introduced with [<source>] lines. Can be combined
263 with --sync-property and --source-property to modify the configuration
264 on-the-fly. When one or more sources are listed after the <server>
265 name on the command line, then only the configs of those sources are
266 printed. "Sync" selects the main configuration instead of source
267 configurations. Using --quiet suppresses the comments for each property.
268 When setting a --template, then the reference configuration for
269 that server is printed instead of an existing configuration.
272 Modify the configuration files for the selected server. If no such
273 configuration exists, then a new one is created using one of the
274 template configurations (see --template option). When creating
275 a new configuration only the active sources will be set to active
276 in the new configuration, i.e. "syncevolution -c scheduleworld addressbook"
277 followed by "syncevolution scheduleworld" will only synchronize the
278 address book. The other sources are created in a disabled state.
279 When modifying an existing configuration and sources are specified,
280 then the source properties of only those sources are modified.
283 To prevent accidental sync runs when a configuration change was
284 intended, but the "--configure" option was not used, "--run" must be
285 specified explicitly when sync or source properties are selected
286 on the command line and they are meant to be used during a sync
287 session triggered by the invocation.
290 In SyncEvolution <= 0.7 a different layout of configuration files
291 was used. Using --migrate will automatically migrate to the new
292 layout and rename the old directory $HOME/.sync4j/evolution/<server>
293 into $HOME/.sync4j/evolution/<server>.old to prevent accidental use
294 of the old configuration. WARNING: old SyncEvolution releases cannot
295 use the new configuration!
296 The switch can also be used to migrate a configuration in the current
297 configuration directory: this preserves all property values, discards
298 obsolete properties and sets all comments exactly as if the configuration
299 had been created from scratch. WARNING: custom comments in the
300 configuration are not preserved.
301 --migrate implies --configure and can be combined with modifying
304 --sync-property|-y <property>=<value>
306 --sync-property|-y <property>=?
307 Overrides a configuration property in the <server>/config.ini file
308 for the current synchronization run or permanently when --configure
309 is used to update the configuration. Can be used multiple times.
310 Specifying an unused property will trigger an error message.
312 --source-property|-z <property>=<value>
313 --source-property|-z ?
314 --source-property|-z <property>=?
315 Same as --sync-property, but applies to the configuration of all active
316 sources. "--sync <mode>" is a shortcut for "--source-property sync=<mode>".
318 When combined with "--configure", the configuration of all sources is
319 modified. Properties cannot be specified differently for different
320 sources, so if you want to change a source property of just one specific
321 sync source, then use "--configure --source-property ... <server> <source>".
323 --template|-l <server name>|default|?
324 Can be used to select from one of the built-in default configurations
325 for known SyncML servers. Defaults to the <server> name, so --template
326 only has to be specified when creating multiple different configurations
327 for the same server. "default" is an alias for "scheduleworld" and can be
328 used as the starting point for servers which do not have a built-in
330 Each template contains a pseudo-random device ID. Therefore setting the
331 "deviceId" sync property is only necessary when manually recreating a
332 configuration or when a more descriptive name is desired.
335 The changes made to local data since the last synchronization are
336 shown without starting a new one. This can be used to see in advance
337 whether the local data needs to be synchronized with the server.
340 Suppresses most of the normal output during a synchronization. The
341 log file still contains all the information.
344 Save or retrieve passwords from the GNOME keyring when modifying the
345 configuration or running a synchronization. Note that using this option
346 applies to *all* passwords in a configuration, so setting a single
347 password as follows moves the other passwords into the keyring, if
348 they were not stored there already:
349 --keyring --configure --sync-property proxyPassword=foo
351 When passwords were stored in the keyring, their value is set to "-"
352 in the configuration. This means that when running a synchronization
353 without the --keyring argument, the password has to be entered
354 interactively. The --print-config output always shows "-" instead of
355 retrieving the password from the keyring.
358 Prints usage information.
361 Prints the SyncEvolution version.
366 Migrate a configuration from the <= 0.7 format to the current one
367 and/or updates the configuration so that it looks like configurations
368 created anew with the current syncevolution:
369 $ syncevolution --migrate scheduleworld
371 Deactivate all sources:
372 $ syncevolution --configure \
373 --source-property sync=none \
376 Activate address book synchronization again, using the --sync shortcut:
377 $ syncevolution --configure \
379 scheduleworld addressbook
381 Change the password for a configuration:
382 $ syncevolution --configure \
383 --sync-property password=foo \
386 Set up another configuration for scheduleworld under a different name:
387 $ syncevolution --configure \
388 --sync-property username=joe \
389 --sync-property password=foo \
390 --template scheduleworld \
397 The configuration file of a certain <server> is stored in
398 $XDG_CONFIG_HOME/syncevolution/<server>/config.ini
399 with " $HOME/.config" as fallback if XDG_CONFIG_HOME is not
400 set. Each data source is configured in
401 $XDG_CONFIG_HOME/syncevolution/<server>/sources/<source>/config.ini
403 The configuration of older SyncEvolution releases in the
404 following directory is also still supported:
405 $HOME/.sync4j/evolution/<server>/spds/syncml/config.txt
407 The format is a simple list of
409 pairs with one pair per line. Leading spaces and space around the
410 equals character and at the end of the line are skipped. In other words,
411 values can neither start or end with spaces nor contain line breaks. Do not
412 put quotation marks around <value>, they would be treated as part of the
413 value itself. Lines starting with a hash (#) after optional leading
414 spaces are treated as comments and skipped.
416 All supported properties are listed in the template configurations.
417 Those which have reasonable defaults do not have to be set and are
418 commented out in the template configurations. Normally at least the
419 following configuration options need to be adapted:
428 See "syncevolution --sync-property ?" for options in the server
429 configuration and "syncevolution --source-property ?"
430 for options in each data source configuration.
432 Each data source corresponds to one database at the SyncML server.
433 The local data source is determined by the type of data given in
434 "type" and uniquely identified with the "evolutionsource" property.
435 To get a list of available data sources, run SyncEvolution with no
436 arguments. "evolutionsource" can be set to either the name or URL
437 of a data source that SyncEvolution prints then.
439 The "uri" property is used to identify with which database on the
440 SyncML server the local data is to be synchronized. Each server
441 usually documents what needs to be configured here. The template
442 configurations already have this set correctly.
444 One can synchronize with multiple server databases in one run, but the
445 same server database can only be accessed once. To synchronize the
446 same server database with multiple local data sources, one
447 has to setup two independent configurations with different "deviceId"
448 settings and synchronize them separately. To create such a setup simply
449 copy the whole configuration tree of the server, e.g.:
450 cp -r ~/.config/syncevolution/localhost ~/.config/syncevolution/localhost_copy
451 and then edit ~/.config/syncevolution/localhost_copy/config.ini
452 to update the "deviceId" and the sources/*/config.ini files to update
453 the "evolutionsource".
455 If an Evolution data source requires authentication, the
456 "evolutionuser" and "evolutionpassword" are used as credentials.
457 In this case the directory that contains the source's config.ini should
458 only be accessible by the user. Usually these fields can be left
459 empty. Specifying a single hyphen ("-") as value for a password
460 instructs SyncEvolution to ask for the password at runtime. The
461 value "${<name of environment variable>}" takes the password from
462 the named environment variable. Entering the password manually
463 is the most secure method.
466 *** Warning: setting evolutionuser/password in cases where it is not
467 *** needed as with local calendars and addressbooks can cause
468 *** the Evolution backend to hang.
471 SSL encryption of the HTTP connection is supported if the underlying
472 platform supports it. In order to enable it, use a syncURL with https
473 instead of http prefix. Not all servers support this, though. In the
474 default configuration, servers must present a trusted certificate
475 where the host name of the certificate matches the host name of the
476 URL. Configuration settings can be used to relax this checking, but
477 this makes the connection less secure and is not recommended.
479 If you get errors about a missing certificate file under
480 /etc/ssl/certs, then check whether the system packages which provide
481 that file are installed. On Debian/Ubuntu the package is called
482 "ca-certificates". Alternatively it is possible to specify a different
483 location of a custom certificate file in the configuration.
486 Automatic Backups and Logging
487 -----------------------------
489 To support recovery from a synchronization which damaged the
490 local data or modified it in an unexpected way, SyncEvolution
491 can create the following files during a synchronization:
492 - a dump of the data in a format which can be imported
493 back into Evolution, e.g. .vcf for address books
494 - a full log file with debug information
495 - a dump of the data after the synchronization for
496 automatic comparison of the before/after state with
499 If the server configuration option "logdir" is set, then
500 a new directory will be created for each synchronization
501 in that directory, using the format
502 <server>-<yyyy>-<mm>-<dd>-<hh>-<mm>[-<seq>]
503 with the various fields filled in with the time when the
504 synchronization started. The sequence suffix will only be
505 used when necessary to make the name unique. By default,
506 SyncEvolution will never delete any data in that log
507 directory unless explicitly asked to keep only a limited
508 number of previous log directories.
510 This is done by setting the "maxlogdirs" limit to something
511 different than the empty string and 0. If a limit is set,
512 then SyncEvolution will only keep that many log directories
513 and start removing the oldest ones when it reaches the limit.
514 This cleanup is only done after a successful synchronization
515 and is limited to directories that match the pattern for
516 SyncEvolution log directory names, so it is safe to put other
517 files or directories into the configured log directory.
519 To avoid writing any additional log file or database dumps during
520 a synchronization the "logdir" can be set to "none". To reduce
521 the verbosity of the log, set "loglevel". If not set or 0, then
522 the verbosity is set to 3 = DEBUG when writing to a log file and
523 2 = INFO when writing to the console directly.
526 Configuration with ScheduleWorld
527 --------------------------------
529 It is recommended to sync against the new vCard 3.0 URI (card3) and
530 iCalendar 2.0 URIs (cal2, task2), using the "text/vcard", "text/calendar"
531 and "text/x-todo" type setting respectively. These are the native formats of
532 Evolution and a lot of effort went into ensuring that they store as
533 much Evolution data as possible. The "note" URI and "text/x-journal" type
534 can be used to synchronize memos.
536 SyncEvolution is primarily tested against ScheduleWorld. The
537 "scheduleworld" configuration template is ready to be used with these
538 URIs, one only has to fill in the real username and password.
541 Configuration with Funambol
542 ---------------------------
544 A default Funambol installation already contains databases which
545 SyncEvolution can synchronize with Evolution address books and
546 calendars. They are adressed in a source config with
550 for calendars. Tasks (aka todos) are not supported directly.
552 At some point the Funambol server started supporting iCalendar 2.0 for
553 calendars. This is the more capable (and recommended!) format, but the
554 server does not suggest it as "preferred". Therefore the client's
555 configuration must use the exclamation qualifier to pick the
556 2.0 format (part of the current template):
557 type = calendar:text/calendar!
563 SyncEvolution transmits address book entries as vCard 2.1 or 3.0
564 depending on the type chosen in the configuration. Evolution uses
565 3.0 internally, so SyncEvolution converts between the two formats
566 as needed. Calendar items and tasks can be sent and received
567 in iCalendar 2.0 as well as vCalendar 1.0, but vCalendar 1.0 should
568 be avoided if possible because it cannot represent all data that
571 How the server stores the items depends on its implementation and
572 configuration. In the default Funambol server installation, contacts
573 and calendar items are converted into an internal format, but at
574 least for contacts it preserves most of the properties used by
575 Evolution whereas iCalendar 2.0 items are not preserved properly
576 in Funambol 6.0. ScheduleWorld uses the same format as Evolution for
577 calendars and tasks and thus requires no conversion.
579 To check which data is preserved, one can use this procedure
580 (described for contacts, but works the same way for calendars and
582 1. synchronize the address book with the server
583 2. create a new address book in Evolution and view it in Evolution
584 once (the second step is necessary in at least Evolution 2.0.4
585 to make the new address book usable in SyncEvolution)
586 3. add a configuration for that second address book and the
587 same URI on the SyncML server
588 4. synchronize again, this time using the other data source
590 Now one can either compare the address books in Evolution or do that
591 automatically, described here for contacts:
592 - save the complete address books: mark all entries, save as vCard
593 - invoke synccompare with two file names as arguments and it will
594 normalize and compare them automatically
596 Normalizing is necessary because the order of cards and their
597 properties as well as other minor formatting aspects may be
598 different. The output comes from a side-by-side comparison, but
599 is augmented by the script so that the context of each change
600 is always the complete item that was modified. Lines or items
601 following a ">" on the right side were added, those on the
602 left side followed by a "<" were removed, and those with
603 a "|" between text on the left and right side were modified.
605 The automatic unit testing (see HACKING) contains a "testItems"
606 test which verifies the copying of special entries using the
609 Modifying one of the address books or even both at the same time and
610 then synchronizing back and forth can be used to verify that
611 SyncEvolution works as expected. If you do not trust SyncEvolution or
612 the server, then it is prudent to run these checks with a copy of the
613 original address book. Make a backup of the .evolution/addressbook
617 Item Changes and Data Changes
618 -----------------------------
620 SyncML clients and servers consider each entry in a database as one
621 item. Items can be added, removed or updated. This is the item change
622 information that client and server exchange during a normal,
623 incremental synchronization.
625 If an item is saved, removed locally, and reimported, then this is
626 usually reported to a peer as "one item removed, one added" because
627 the information available to SyncEvolution is not sufficient to
628 determine that this is in fact the same item. One exception are
629 iCalendar 2.0 items with their globally unique ID: the modification
630 above will be reported to the server as "one item updated".
632 That is better, but still not quite correct because the content of the
633 item has not changed, only the meta information about it which is used
634 to detect changes. This cannot be avoided without creating additional
635 overhead for normal synchronizations.
637 SyncEvolution reports "item changes" (the number of added, removed and
638 updated items) as well as data changes. These data changes are
639 calculated by comparing database dumps. Because this data comparison
640 ignores information about which data belongs to which item, it is able
641 to detect that re-adding an item that was removed earlier does not
642 change the data, in contrast to the item changes. On the other hand,
643 removing one item and adding a different one may look like updating
644 just one item, which is not quite correct.
650 If two clients make changes to the same item, the first one to
651 synchronize will copy its changes to the server. The second one
652 then runs into a conflict when it tries to push its own changes
655 The SyncML server now has to decide how to proceed. Some decide
656 to preserve both conflicting items, leading to duplicates which
657 have to be merged manually later. Other servers merge automatically
658 and throw away conflicting data based on heuristics; this may
659 remove valid data. The client has no control over the method
660 chosen by the server.
662 Merging items on the server is difficult because the SyncML protocol
663 does not specify which parts of a conflicting item were updated.
664 In general a server can only make more or less educated guesses
665 which might lead to data loss. It is better to avoid this situation
666 in the first place by synchronizing before making changes.
669 Known Problems + Support
670 ------------------------
672 Please visit http://syncevolution.org/ for up-to-date
673 information about known problems and links to places where further
677 Compiling from Source
678 ---------------------
680 To compile the code the source or an installation of the Synthesis
681 SyncML engine is needed. A compatible snapshot of it is included in
682 SyncEvolution source packages and will be used
683 automatically. Instructions for working with upstream Synthesis
684 sources directly are contained in the HACKING document.
686 Also needed are the Evolution and Boost (>= 1.35) development
687 files. For HTTP, either Curl or libsoup can be used.
689 On Debian based systems the required packages can be installed with
690 apt-get install evolution-data-server-dev \
691 libecal1.2-dev libebook1.2-dev \
695 libboost-dev >= 1.34, available as libboost1.35-dev backport for Debian Etch.
697 Necessary on some distros due to bad dependencies (not needed by SyncEvolution itself):
698 apt-get install libdb3-dev
700 Optional (enables reading proxy settings from GNOME preferences):
701 apt-get install libsoup-gnome2.4-dev
703 See also the libsynthesis README file for other required packages.
705 The test framework also requires CPPUnit:
706 apt-get install libcppunit-dev
708 For the GUI and its D-Bus based service backend:
709 apt-get install libdbus-glib-1-dev \
712 libgtk2.0-dev libglade2-dev \
713 libgnome-keyring-dev \
714 libgconf2-dev libgnomevfs2-dev
716 Optional packages for GUI:
717 apt-get install libunique-dev
719 libunique = ensure that GTK GUI only runs once per user
721 The build system is the normal autotools system. See INSTALL for
722 general instructions how to use that and "./configure --help" for
723 SyncEvolution specific options.
725 Note that compiling without the Evolution development files is
726 possible. But because this is usually not what people want,
727 the configure script needs explicit --disable-ecal --disable-ebook
728 parameters, otherwise it will refuse to compile without Evolution
731 When compiling from a git checkout, remember to run "./autogen.sh".
733 apt-get install libtool intltool automake
736 Supporting SyncEvolution
737 ------------------------
739 SyncEvolution is free software: available free of charge and you have
740 the freedom of modifying and distributing it. If you are a software
741 developer, the best way to support SyncEvolution is to port it to
742 other backends and systems. Get in touch if you want to hear more
745 If you are a (hopefully happy) user of SyncEvolution, then you can
746 make your appreciation or suggestions for improvements known in
747 several ways. Although SyncEvolution is free, this does not mean that
748 its development did not cost much effort - quite the opposite, a lot
749 of time went into it.
751 - Send a postcard to the author (see main page).
752 - Leave comments on the author's blog (http://www.estamos.de/blog).
753 - Donations are not necessary and cannot be accepted either.
761 http://www.estamos.de/