5 ------------------------------------------------
6 synchronize personal information management data
7 ------------------------------------------------
16 Show available sources:
19 Show information about configuration(s):
20 syncevolution --print-servers|--print-configs|--print-peers
22 Show information about a specific configuration:
23 syncevolution --print-config [--quiet] <config> [main|<source> ...]
26 syncevolution --print-sessions [--quiet] <config>
28 Show information about SyncEvolution:
29 syncevolution --help|-h|--version
31 Run a synchronization as configured:
32 syncevolution <config> [<source> ...]
34 Run a synchronization with properties changed just for this run:
35 syncevolution --run <options for run> <config> [<source> ...]
37 Restore data from the automatic backups:
38 syncevolution --restore <session directory> --before|--after [--dry-run] <config> <source> ...
40 Modify a configuration:
41 syncevolution --configure <options> <config> [<source> ...]
42 syncevolution --remove|--migrate <options> <config>
45 syncevolution --print-items <config> <source>
48 syncevolution [--delimiter <string>] --export <dir>|<file>|- <config> <source> [<luid> ...]
51 syncevolution [--delimiter <string>|none] --import <dir>|<file>|- <config> <source>
54 syncevolution --update <dir> <config> <source>
55 syncevolution [--delimiter <string>|none] --update <file>|- <config> <source> <luid> ...
58 syncevolution --delete-items <config> <source> (<luid> ... | \*)
63 This text explains the usage of the SyncEvolution command line.
65 SyncEvolution synchronizes personal information management (PIM) data
66 such as contacts, appointments, tasks and memos using the Synthesis
67 sync engine, which provides support for the SyncML synchronization
70 SyncEvolution synchronizes with SyncML servers over HTTP and with
71 SyncML capable phones locally over Bluetooth (new in 1.0). Plugins
72 provide access to the data which is to be synchronized. Binaries are
73 available for Linux desktops (synchronizing data in GNOME Evolution,
74 with KDE supported indirectly already and Akonadi support in
75 development), for MeeGo (formerly Moblin) and for Maemo 5/Nokia
76 N900. The source code can be compiled for Unix-like systems and
77 provides a framework to build custom SyncML clients or servers.
82 The <config> and the <source> strings are used to find the
83 configuration files which determine how synchronization is going to
84 proceed. Each source corresponds to one local address book, calendar,
85 task list or set of memos and the corresponding database on the
86 peer. Depending on which parameters are given, different operations
89 Starting with SyncEvolution 1.0, <config> strings can have different
90 meanings. Typically, a simple string like `memotoo` refers to
91 the configuration for that peer, as it did in previous releases. A
92 peer is either a SyncML server (the traditional usage of
93 SyncEvolution) or a client (the new feature in 1.0).
95 Each peer configuration exists inside a specific context, typically
96 the `@default` context. All peers in the same context share some parts
97 of their configuration, for example, which local databases are to be
98 synchronized. In that sense, a configuration context can be seen as a
99 set of local databases plus the peer configurations that are
100 synchronized against those databases.
102 The peer-independent properties of a source can be configured by
103 giving the context name as <config> parameter ("@default
104 addressbook"). Operations manipulating the local data also accept
107 When different peers are meant to synchronize different local
108 databases, then different contexts have to be used when setting up the
109 peers by appending a context name after the `at` sign, as in
110 `memotoo2@other-context`. Later on, if `memotoo2` is
111 unique, the `@other-context` suffix becomes optional.
113 Sometimes it is also useful to change configuration options of a
114 context, without modifying a specific peer. This can be done by using
115 `@default` (or some other context name) without anything before the
116 `at` sign. The empty string "" is the same as `@default`. ::
120 If no arguments are given, then SyncEvolution will list all available
121 data sources regardless whether there is a configuration file for them
122 or not. The output includes the identifiers which can then be used to
123 select those sources in a configuration file. For each source one can
124 set a different synchronization mode in its configuration file. ::
126 syncevolution <config>
128 Without the optional list of sources, all sources which are enabled in
129 their configuration file are synchronized. ::
131 syncevolution <config> <source> ...
133 Otherwise only the ones mentioned on the command line are active. It
134 is possible to configure sources without activating their
135 synchronization: if the synchronization mode of a source is set to
136 `disabled`, the source will be ignored. Explicitly listing such a
137 source will synchronize it in `two-way` mode once.
139 In SyncEvolution's predefined configuration templates, the following
140 names for sources are used. Different names can be chosen for sources
141 that are defined manually. ::
143 * addressbook: a list of contacts
144 * calendar: calendar *events*
145 * memo: plain text notes
147 * calendar+todo: a virtual source combining one local "calendar" and
148 one "todo" source (required for synchronizing with some phones)
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> <config> [<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 <config>
189 Deletes the configuration. If the <config> refers to a specific
190 peer, only that peer's configuration is removed. If it refers to
191 a context, that context and all peers inside it are removed.
193 Note that there is no confirmation question. Neither local data
194 referenced by the configuration nor the content of log dirs are
197 syncevolution --run <options for run> <config> [<source> ...]
199 Options can also be overridden for just the current run, without
200 changing the configuration. In order to prevent accidentally running a
201 sync session when a configuration change was intended, either
202 --configure or --run must be given explicitly if options are specified
203 on the command line. ::
205 syncevolution --status <config> [<source> ...]
207 Prints what changes were made locally since the last synchronization.
208 Depends on access to database dumps from the last run, so using the
209 `logdir` option is recommended. ::
211 syncevolution --print-servers|--print-configs|--print-peers
212 syncevolution --print-config [--quiet] <config> [main|<source> ...]
213 syncevolution --print-sessions [--quiet] <config>
215 These commands print information about existing configurations. When
216 printing a configuration a short version without comments can be
217 selected with --quiet. When sources are listed, only their
218 configuration is shown. `Main` instead or in combination with sources
219 lists only the main peer configuration. ::
221 syncevolution --restore <session directory> --before|--after
222 [--dry-run] <config> <source> ...
224 This restores local data from the backups made before or after a
225 synchronization session. The --print-sessions command can be used to
226 find these backups. The source(s) have to be listed explicitly. There
227 is intentionally no default, because as with --remove there is no
228 confirmation question. With --dry-run, the restore is only simulated.
230 The session directory has to be specified explicitly with its path
231 name (absolute or relative to current directory). It does not have to
232 be one of the currently active log directories, as long as it contains
233 the right database dumps for the selected sources.
235 A restore tries to minimize the number of item changes (see section
236 `Item Changes and Data Changes`_). This means that items that are
237 identical before and after the change will not be transmitted anew to
238 the server during the next synchronization. If the server somehow
239 needs to get a clean copy of all items on the client then, use "--sync
240 refresh-from-client" in the next run. ::
242 syncevolution --print-items <config> <source>
243 syncevolution [--delimiter <string>] --export <dir>|<file>|- <config> <source> [<luid> ...]
244 syncevolution [--delimiter <string>|none] --import <dir>|<file>|- <config> <source>
245 syncevolution --update <dir> <config> <source>
246 syncevolution [--delimiter <string>|none] --update <file>|- <config> <source> <luid> ...
247 syncevolution --delete-items <config> <source> (<luid> ... | *)
249 Restore depends on the specific format of the automatic backups
250 created by SyncEvolution. Arbitrary access to item data is provided
251 with additional options. <luid> here is the unique local identifier
252 assigned to each item in the source, transformed so that it contains
253 only alphanumeric characters, dash and underscore. A star * in
254 --delete-items selects all items for deletion.
256 <config> and <source> must be given, but they do not have to refer to
257 existing configurations. In that case, the desired backend and must be
258 give via "--source-property type=<backend>", like this::
260 syncevolution --print-items --source-property type=evolution-contacts dummy-config dummy-source
262 The desired backend database can be chosen via "--source-property
268 Here is a full description of all <options> that can be put in front
269 of the server name. Whenever an option accepts multiple values, a
270 question mark can be used to get the corresponding help text and/or
271 a list of valid values.
274 Temporarily synchronize the active sources in that mode. Useful
275 for a `refresh-from-server` or `refresh-from-client` sync which
276 clears all data at one end and copies all items from the other.
278 --print-servers|--print-configs|--print-peers
279 Prints the names of all configured peers to stdout. There is no
280 difference between these options, the are just aliases.
282 --print-servers|--print-configs|--print-peers|-p
283 Prints the complete configuration for the selected <config>
284 to stdout, including up-to-date comments for all properties. The
285 format is the normal .ini format with source configurations in
286 different sections introduced with [<source>] lines. Can be combined
287 with --sync-property and --source-property to modify the configuration
288 on-the-fly. When one or more sources are listed after the <config>
289 name on the command line, then only the configs of those sources are
290 printed. `main` selects the main configuration instead of source
291 configurations. Using --quiet suppresses the comments for each property.
292 When setting a --template, then the reference configuration for
293 that peer is printed instead of an existing configuration.
296 Prints information about previous synchronization sessions for the
297 selected peer or context are printed. This depends on the `logdir`
298 option. The information includes the log directory name (useful for
299 --restore) and the synchronization report. In combination with
300 --quiet, only the paths are listed.
303 Modify the configuration files for the selected peer and/or sources.
304 If no such configuration exists, then a new one is created using one
305 of the template configurations (see --template option). When
306 creating a new configuration and listing sources explicitly on the
307 command line, only those sources will be set to active in the new
308 configuration, i.e. `syncevolution -c memotoo addressbook`
309 followed by `syncevolution memotoo` will only synchronize the
310 address book. The other sources are created in a disabled state.
311 When modifying an existing configuration and sources are specified,
312 then the source properties of only those sources are modified.
315 To prevent accidental sync runs when a configuration change was
316 intended, but the `--configure` option was not used, `--run` must be
317 specified explicitly when sync or source properties are selected
318 on the command line and they are meant to be used during a sync
319 session triggered by the invocation.
322 In older SyncEvolution releases a different layout of configuration files
323 was used. Using --migrate will automatically migrate to the new
324 layout and rename the <config> into <config>.old to prevent accidental use
325 of the old configuration. WARNING: old SyncEvolution releases cannot
326 use the new configuration!
328 The switch can also be used to migrate a configuration in the current
329 configuration directory: this preserves all property values, discards
330 obsolete properties and sets all comments exactly as if the configuration
331 had been created from scratch. WARNING: custom comments in the
332 configuration are not preserved.
334 --migrate implies --configure and can be combined with modifying
338 Shows all existing items using one line per item using
339 the format "<luid>[: <short description>]". Whether the description
340 is available depends on the backend and the kind of data that it
344 Writes all items in the source or all items whose <luid> is
345 given into a directory if the --export parameter exists and is a
346 directory. The <luid> of each item is used as file name. Otherwise it
347 creates a new file under that name and writes the selected items
348 separated by the chosen delimiter string. stdout can be selected with
351 The default delimiter (two line breaks) matches a blank line. As a special
352 case, it also matches a blank line with DOS line ending (line break,
353 carriage return, line break). This works for vCard 3.0 and iCalendar 2.0,
354 which never contain blank lines.
356 When exporting, the default delimiter will always insert two line
357 breaks regardless whether the items contain DOS line ends. As a
358 special case, the initial newline of a delimiter is skipped if the
359 item already ends in a newline.
362 Adds all items found in the directory or input file to the
363 source. When reading from a directory, each file is treated as one
364 item. Otherwise the input is split at the chosen delimiter. "none" as
365 delimiter disables splitting of the input.
368 Overwrites the content of existing items. When updating from a
369 directory, the name of each file is taken as its luid. When updating
370 from file or stdin, the number of luids given on the command line
371 must match with the number of items in the input.
374 Removes the specified items from the source. Most backends print
375 some progress information about this, but besides that, no further
376 output is produced. Trying to remove an item which does not exist
377 typically leads to an ERROR message, but is not reflected in a
378 non-zero result of the command line invocation itself because the
379 situation is not reported as an error by backends (removal of
380 non-existent items is not an error in SyncML). Use a star \* instead
381 or in addition to listing individual luids to delete all items.
383 --sync-property|-y <property>=<value>|<property>=?|?
384 Overrides a source-independent configuration property for the
385 current synchronization run or permanently when --configure is used
386 to update the configuration. Can be used multiple times. Specifying
387 an unused property will trigger an error message.
389 When using the configuration layout introduced with 1.0, some of the
390 sync properties are shared between peers, for example the directory
391 where sessions are logged. Permanently changing such a shared
392 property for one peer will automatically update the property for all
393 other peers in the same context because the property is stored in a
394 shared config file. When printing a config in verbose mode, a summary
395 comment shows which properties are shared in which way.
397 --source-property|-z <property>=<value>|<property>=?|?
398 Same as --sync-property, but applies to the configuration of all active
399 sources. `--sync <mode>` is a shortcut for `--source-property sync=<mode>`.
401 When combined with `--configure`, the configuration of all sources
402 is modified. The value is applied to all sources unless sources are
403 listed explicitly on the command line. So if you want to change a
404 source property of just one specific sync source, then use
405 `--configure --source-property ... <server> <source>`.
407 As with sync properties, some properties are shared between peers,
408 in particular the selection of which local data to synchronize.
410 --template|-l <peer name>|default|?<device>
411 Can be used to select from one of the built-in default configurations
412 for known SyncML peers. Defaults to the <config> name, so --template
413 only has to be specified when creating multiple different configurations
414 for the same peer, or when using a template that is named differently
415 than the peer. `default` is an alias for `memotoo` and can be
416 used as the starting point for servers which do not have a built-in
419 A pseudo-random device ID is generated automatically. Therefore setting
420 the `deviceId` sync property is only necessary when manually recreating a
421 configuration or when a more descriptive name is desired.
423 The available templates for different known SyncML servers are listed when
424 using a single question mark instead of template name. When using the
425 `?<device>` format, a fuzzy search for a template that might be
426 suitable for talking to such a device is done. The matching works best
427 when using `<device> = <Manufacturer> <Model>`. If you don't know the
428 manufacturer, you can just keep it as empty. The output in this mode
429 gives the template name followed by a short description and a rating how well
430 the template matches the device (100% is best).
433 The changes made to local data since the last synchronization are
434 shown without starting a new one. This can be used to see in advance
435 whether the local data needs to be synchronized with the server.
438 Suppresses most of the normal output during a synchronization. The
439 log file still contains all the information.
442 Save or retrieve passwords from the GNOME keyring when modifying the
443 configuration or running a synchronization. Note that using this option
444 applies to *all* passwords in a configuration, so setting a single
445 password as follows moves the other passwords into the keyring, if
446 they were not stored there already::
448 --keyring --configure --sync-property proxyPassword=foo
450 When passwords were stored in the keyring, their value is set to a single
451 hyphen ("-") in the configuration. This means that when running a
452 synchronization without the --keyring argument, the password has to be
453 entered interactively. The --print-config output always shows "-" instead
454 of retrieving the password from the keyring.
457 By default, the SyncEvolution command line is executed inside the
458 syncevo-dbus-server process. This ensures that synchronization sessions
459 started by the command line do not conflict with sessions started
460 via some other means (GUI, automatically). For debugging purposes
461 or very special use cases (running a local sync against a server which
462 executes inside the daemon) it is possible to execute the operation
463 without the daemon (--daemon=no).
466 Prints usage information.
469 Prints the SyncEvolution version.
474 List the known configuration templates::
476 syncevolution --template ?
478 Create a new configuration, using the existing Memotoo template::
480 syncevolution --configure \
481 --sync-property "username=123456" \
482 --sync-property "password=!@#ABcd1234" \
485 Note that putting passwords into the command line, even for
486 short-lived processes as the one above, is a security risk in shared
487 environments, because the password is visible to everyone on the
488 machine. To avoid this, remove the password from the command above,
489 then add the password to the right config.ini file with a text editor.
490 This command shows the directory containing the file::
492 syncevolution --print-configs
494 Review configuration::
496 syncevolution --print-config memotoo
498 Synchronize all sources::
500 syncevolution memotoo
502 Deactivate all sources::
504 syncevolution --configure \
505 --source-property sync=none \
508 Activate address book synchronization again, using the --sync shortcut::
510 syncevolution --configure \
514 Change the password for a configuration::
516 syncevolution --configure \
517 --sync-property password=foo \
520 Set up another configuration for under a different account, using
521 the same default databases as above::
523 syncevolution --configure \
524 --sync-property username=joe \
525 --sync-property password=foo \
529 Set up another configuration using the same account, but different
530 local databases (can be used to simulate synchronizing between two
531 clients, see `Exchanging Data`_::
533 syncevolution --configure \
534 --sync-property "username=123456" \
535 --sync-property "password=!@#ABcd1234" \
536 --source-property sync=none \
539 syncevolution --configure \
540 --source-property evolutionsource=<name of other address book> \
543 syncevolution --configure \
544 --source-property sync=two-way \
545 memotoo@other addressbook
547 syncevolution memotoo
548 syncevolution memotoo@other
550 Migrate a configuration from the <= 0.7 format to the current one
551 and/or updates the configuration so that it looks like configurations
552 created anew with the current syncevolution::
554 syncevolution --migrate memotoo
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 as
566 needed. Calendar items and tasks can be sent and received in iCalendar
567 2.0 as well as vCalendar 1.0, but vCalendar 1.0 should be avoided if
568 possible because it cannot represent all data that Evolution stores.
570 .. note:: The Evolution backends are mentioned as examples;
571 the same applies to other data sources.
573 How the server stores the items depends on its implementation and
574 configuration. To check which data is preserved, one can use this
575 procedure (described for contacts, but works the same way for
576 calendars and tasks):
578 1. synchronize the address book with the server
579 2. create a new address book in Evolution and view it in Evolution
580 once (the second step is necessary in at least Evolution 2.0.4
581 to make the new address book usable in SyncEvolution)
582 3. add a configuration for that second address book and the
583 same URI on the SyncML server, see EXAMPLES_ above
584 4. synchronize again, this time using the other data source
586 Now one can either compare the address books in Evolution or do that
587 automatically, described here for contacts:
589 - save the complete address books: mark all entries, save as vCard
590 - invoke `synccompare` with two file names as arguments and it will
591 normalize and compare them automatically
593 Normalizing is necessary because the order of cards and their
594 properties as well as other minor formatting aspects may be
595 different. The output comes from a side-by-side comparison, but
596 is augmented by the script so that the context of each change
597 is always the complete item that was modified. Lines or items
598 following a ">" on the right side were added, those on the
599 left side followed by a "<" were removed, and those with
600 a "|" between text on the left and right side were modified.
602 The automatic unit testing (see HACKING) contains a `testItems`
603 test which verifies the copying of special entries using the
606 Modifying one of the address books or even both at the same time and
607 then synchronizing back and forth can be used to verify that
608 SyncEvolution works as expected. If you do not trust SyncEvolution or
609 the server, then it is prudent to run these checks with a copy of the
610 original address book. Make a backup of the .evolution/addressbook
613 Item Changes and Data Changes
614 -----------------------------
616 SyncML clients and servers consider each entry in a database as one
617 item. Items can be added, removed or updated. This is the item change
618 information that client and server exchange during a normal,
619 incremental synchronization.
621 If an item is saved, removed locally, and reimported, then this is
622 usually reported to a peer as "one item removed, one added" because
623 the information available to SyncEvolution is not sufficient to
624 determine that this is in fact the same item. One exception are
625 iCalendar 2.0 items with their globally unique ID: the modification
626 above will be reported to the server as "one item updated".
628 That is better, but still not quite correct because the content of the
629 item has not changed, only the meta information about it which is used
630 to detect changes. This cannot be avoided without creating additional
631 overhead for normal synchronizations.
633 SyncEvolution reports *item changes* (the number of added, removed and
634 updated items) as well as *data changes*. These data changes are
635 calculated by comparing database dumps using the `synccompare` tool.
636 Because this data comparison ignores information about which data
637 belongs to which item, it is able to detect that re-adding an item
638 that was removed earlier does not change the data, in contrast to the
639 item changes. On the other hand, removing one item and adding a
640 different one may look like updating just one item.
642 Automatic Backups and Logging
643 -----------------------------
645 To support recovery from a synchronization which damaged the
646 local data or modified it in an unexpected way, SyncEvolution
647 can create the following files during a synchronization:
649 - a dump of the data in a format which can be restored by
650 SyncEvolution, usually a single file per item containing
651 in a standard text format (VCARD/VCALENDAR)
652 - a full log file with debug information
653 - another dump of the data after the synchronization for
654 automatic comparison of the before/after state with
657 If the server configuration option "logdir" is set, then
658 a new directory will be created for each synchronization
659 in that directory, using the format `<peer>-<yyyy>-<mm>-<dd>-<hh>-<mm>[-<seq>]`
660 with the various fields filled in with the time when the
661 synchronization started. The sequence suffix will only be
662 used when necessary to make the name unique. By default,
663 SyncEvolution will never delete any data in that log
664 directory unless explicitly asked to keep only a limited
665 number of previous log directories.
667 This is done by setting the "maxlogdirs" limit to something
668 different than the empty string and 0. If a limit is set,
669 then SyncEvolution will only keep that many log directories
670 and start removing the "less interesting" ones when it reaches
671 the limit. Less interesting are those where no data changed
672 and no error occurred.
674 To avoid writing any additional log file or database dumps during
675 a synchronization, the "logdir" can be set to "none". To reduce
676 the verbosity of the log, set "loglevel". If not set or 0, then
677 the verbosity is set to 3 = DEBUG when writing to a log file and
678 2 = INFO when writing to the console directly. To debug issues
679 involving data conversion, level 4 also dumps the content of
685 The following environment variables control where SyncEvolution finds
686 files and other aspects of its operations.
689 Overrides the proxy settings temporarily. Setting it to an empty value
690 disables the normal proxy settings.
692 HOME/XDG_CACHE_HOME/XDG_CONFIG_HOME
693 SyncEvolution follows the XDG_ desktop standard for its files. By default,
694 `$HOME/.config/syncevolution` is the location for configuration files.
695 `$HOME/.cache/syncevolution` holds session directories with log files and
698 .. _XDG: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
701 Setting this to any value disables the filtering of stdout and stderr
702 that SyncEvolution employs to keep noise from system libraries out
703 of the command line output.
705 SYNCEVOLUTION_GNUTLS_DEBUG
706 Enables additional debugging output when using the libsoup HTTP transport library.
708 SYNCEVOLUTION_BACKEND_DIR
709 Overrides the default path to plugins, normally `/usr/lib/syncevolution/backends`.
711 SYNCEVOLUTION_TEMPLATE_DIR
712 Overrides the default path to template files, normally
713 `/usr/share/syncevolution/templates`.
715 SYNCEVOLUTION_XML_CONFIG_DIR
716 Overrides the default path to the Synthesis XML configuration files, normally
717 `/usr/share/syncevolution/xml`. These files are merged into one configuration
718 each time the Synthesis SyncML engine is started as part of a sync session.
720 Note that in addition to this directory, SyncEvolution also always
721 searches for configuration files inside `$HOME/.config/syncevolution-xml`.
722 Files with the same relative path and name as in `/usr/share/syncevolution/xml`
723 override those files, others extend the final configuration.
728 See `known issues`_ and the `support`_ web page for more information.
730 .. _known issues: http://syncevolution.org/documentation/known-issues
731 .. _support: http://syncevolution.org/support
736 http://syncevolution.org
742 Patrick Ohly <patrick.ohly@intel.com>, http://www.estamos.de
744 http://syncevolution.org/about/contributors
745 :To contact the project publicly (preferred):
746 syncevolution@syncevolution.org
747 :Intel-internal team mailing list (confidential):
748 syncevolution@lists.intel.com