[SyncEvolution] [Evolution Address Book] access to other books
by Ildar Mulyukov
Hi!
I've a quick question.
EDS have ability to sync with Google (incl. contacts) with it's own
means. This is the feature of the recent Evo.
But I'm unable to access that (imported from the Google) addressbook.
SyncEvo uses some default book for operations. I tried to play with the
database= parameter, but couldn't find the right value for it.
Can someone help? Thanks in advance.
Regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
8 years, 4 months
[SyncEvolution] Sync failure due to large addressbook entires.
by Ross Vandegrift
Hello,
Yesterday I used syncevolution to push my my address book out to Google
Contacts via SyncML. In a subsequent run, some contacts had photos
auto-added by Google.
This has partially broken sync with my S40 phone. It imposes a max
message size of 3k, and the images push those contacts over the limit.
Syncevolution notices this:
WARNING: outgoing item is larger (5334) than MaxObjSize (3000) of remote
-> suppress now/mark for resend
The sync mostly works, but takes around 15 minutes to finish. The
first time, my phone's progress indicator stuck at 95% complete. On
subsequent syncs, the phone finishes quickly but syncevo still waits
for 15 minutes. Oddly, the times in the log do not reflect this.
I don't care about having the photos associated with the contacts. Can
they be stripped out before contacts are sent to the phone? The only
config option on the phone side is to require a username/password.
Thanks,
Ross
8 years, 4 months
[SyncEvolution] SyncEvolution + libsynthesis git repos
by Patrick Ohly
Hello!
As mentioned in the SyncEvolution 1.3 announcement, git repos for the
SyncEvolution and the corresponding libsynthesis were moved to
http://cgit.freedesktop.org/SyncEvolution/
The upstream libsynthesis is at https://gitorious.org/libsynthesis
However, for building SyncEvolution please use the version from fdo.org,
because it may have required patches that are not yet included upstream.
As before, "for-master/xxx" branch names (or more general, "for-<branch
name>/xxx") refer to code which is to be merged into the corresponding
branch by the nightly testing. These branches can and do get rebased to
keep history linear when possible, so beware if you base your own work
on them. Use "git rebase -i" and pick your own commits when updating to
the latest "for-..." branch.
The new IVI code (in for-master/pim) is an example for such a branch.
--
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, 4 months
[SyncEvolution] failed to compile 1.3
by Elisseev V.
Hello,
I got an error (see below) while compiling the latest version (1.3),
although I haven't had any problems with 1.2.99.x versions. I'd greatly
appreciate any help.
Regards,
Vlad.
Configure parameters
***********************************************************************
./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --libdir=/usr/lib64
--disable-dependency-tracking --with-rst2man=/usr/bin/rst2man.py
--with-rst2html=/usr/bin/rst2html.py --enable-dbus-service
--disable-akonadi --disable-bluetooth --enable-dav --disable-sqlite
--enable-ebook --enable-ecal --enable-gnome-keyring --disable-kwallet
--disable-xmlrpc --disable-sqlite --disable-file
--disable-gnome-bluetooth-panel-plugin --enable-gui=gtk --enable-gtk=2
--enable-notify --disable-maintainer-mode
CONFIGURATION SUMMARY
Core SyncEvolution: yes
activesync: no
addressbook: no
akonadi: no
ebook: yes
ecal: yes
file: no
kcalextended: no
maemocal: no
qtcontacts: no
sqlite: no
dav: yes
xmlrpc: no
DBus service: yes
Notifications: yes
GIO GDBus: yes
GNOME keyring: yes
UI (DBus client): gtk (using gtk+-2.0)
Bluetooth transport: no
GNOME Bluetooth panel plugin: no
SHA-256: glib
API documentation: no
D-Bus Timeout Hack: yes
***********************************************************************
Compilation error
***********************************************************************
cp test/syncevo-phone-config.py src/syncevo-phone-config
perl -e '$syncfound=0; $sourcefound=0; $res=0;' \
-e 'sub run { $cmd = shift; $buffer = `env LD_LIBRARY_PATH=src/syncevo/.libs:src/gdbus/.libs:src/gdbusxx/.libs:src/build-synthesis/src/.libs:$ENV{LD_LIBRARY_PATH} $cm
d`; die if $?; return $buffer; }' \
-e 'while (<>) {' \
-e 's/^:Version: .*/:Version: 1.3/;' \
-e 's/:Date: .*/":Date: " . `date +%Y-%m-%d`/e;' \
-e 'if (s;(<< see "syncevolution --sync-property ." >>\n);run("src/syncevolution --daemon=no --sync-property ?") || $1;e) { $syncfound=1; }' \
-e 'if (s;(<< see "syncevolution --source-property ." >>\n);run("src/syncevolution --daemon=no --source-property ?") || $1;e) { $sourcefound=1; }' \
-e 'print;' \
-e '}' \
-e 'die "<<sync-property>> tag not in README.rst?!" unless $syncfound;' \
-e 'die "<<source-property>> tag not in README.rst?!" unless $sourcefound;' \
-e 'exit $res;' \
README.rst >README.patched.rst
syncevolution: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: boost::shared_ptr<T>::reference boost::shared_ptr<T>::operator*() const [with T = boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group, boost::optional<int> >, boost::signals2::slot4<bool, const SyncEvo::InitStateTri&, const std::basic_string<char>&, const std::basic_string<char>&, const SyncEvo::ConfigPasswordKey&, boost::function<bool(const SyncEvo::InitStateTri&, const std::basic_string<char>&, const std::basic_string<char>&, const SyncEvo::ConfigPasswordKey&)> >, boost::signals2::mutex>; boost::shared_ptr<T>::reference = boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group, boost::optional<int> >, boost::signals2::slot4<bool, const SyncEvo::InitStateTri&, const std::basic_string<char>&, const std::basic_string<char>&, const SyncEvo::ConfigPasswordKey&, boost::function<bool(const SyncEvo::InitStateTri&, const std::basic_string<char>&, const std::basic_string<char>&, const SyncEvo::ConfigPasswordKey&)> >, boost::signals2::mutex>&]: Assertion `px != 0' failed.
Died at -e line 2, <> line 674.
make[2]: *** [README.patched.rst] Error 255
make[2]: *** Deleting file `README.patched.rst'
make[2]: Leaving directory `/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/portage/tmp/portage/app-pda/syncevolution-1.3/work/syncevolution-1.3'
make: *** [all] Error 2
***********************************************************************
8 years, 4 months
[SyncEvolution] [NEWBIE] a couple of stupid questions
by Ildar Mulyukov
Hi, Patrick, ppl,
as the list is not overloaded, I'd like to ask a couple of lame
questions.
1. SyncML server can work with multiple number of clients, right? Is
this true for the SyncEvo server role too?
2. Having SyncEvo capable to act as a server and client, it is possible
to have a local SyncEvo server sync with a remote server, probably
through and intermediate local database with e.g. backend=file ?
thanks in advance. More questions follow.
Regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
blog: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
8 years, 4 months
[SyncEvolution] SyncEvolution 1.3 release preparations + ActiveSync
by Patrick Ohly
Hello!
I have finished packaging SyncEvolution 1.2.99.3. It is in the
"unstable" apt repo and downloads.syncevolution.org. However, I am going
to delay sending out the official announcement for a few more days
because I want to include some words about the migration of bug tracking
and git repo to freedesktop.org, which should happen this weekend.
The biggest change is that using ActiveSync is now possible without
compiling from source. See the attached release announcement and
https://syncevolution.org/wiki/google-contacts-activesync for details.
Feedback from early adopters would be very welcome to improve the Wiki
page.
--
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, 4 months
[SyncEvolution] SyncEvolution 1.2.99.4 for Maemo and Harmattan
by Ove Kåven
I've finally managed to get everything to work, I think.
Patrick, if you want to see my changes, you can download a tarball from
http://people.debian.org/~ovek/harmattan/syncevolution_1.2.99.4-1.tar.gz
It contains the git tree I work from. Most of the build system patches
are probably in the FREMANTLE-1-2-99-3 branch. I could perhaps make a
list if you want, but perhaps you want to look for yourself.
--- Notes for Maemo Fremantle:
The package should be available from extras-devel, or from
http://people.debian.org/~ovek/maemo/
The changelog is:
* Fixes to Maemo calendar backend.
- Updated to use SyncEvolution's new support for
automatically detecting whether to sync notes
in text/calendar or in text/plain format.
(Previously, the default was to always sync as
text/plain, which would lose any metadata.)
- Return ITEM_REPLACED instead of ITEM_MERGED if
the calendar-backend detects conflicts.
- Implemented SyncSourceLogging::getDescription(),
to make it easier for users to find out which
entry is the problem if something goes wrong.
- In listAllItems(), read entries from database
one by one, instead of loading everything into RAM
all at once. This may be a little slower, but it would
also reduce resident memory requirements for large
calendars. Since RAM is a precious resource on the
N900, this is hopefully a net win.
* Updated packaging for new SyncEvolution build system.
Build-Depend on automake 1.10, libtool, libboost1.42-dev,
and libcppunit-dev.
* Although I've tried to use the newest tools available in the
Fremantle repositories, they're still a bit old for the
SyncEvolution build system, and I had to patch the build
system a fair bit for it to work.
* Also patched the SyncEvolution code itself to work with
the fairly old compiler (gcc 4.2).
If people wish, the backend could be sped up by moving away from
TrackingSyncSource and use a timestamp-based approach (like KCalExtended
does) instead. A drawback of such an approach would be that you should
not change the calendar while a sync is in progress. I already wrote
some code for this, but didn't finish it since I wasn't sure it was
worth it.
--- Notes for MeeGo Harmattan:
The package should be available from
http://people.debian.org/~ovek/harmattan/
The changelog is:
* Embed libneon and host into the SyncEvolution packages,
so that DAV support can finally be enabled.
* Various fixes and enhancements to KCalExtended backend.
- Support synchronizing tasks and notes.
- In --print-databases, list UIDs instead of file name
(all listed calendars have the same file name anyway).
Allow selecting database by UID in addition to name.
- Only load one copy of the whole calendar into RAM when
starting the sync. It shouldn't be necessary to load two.
- Fixed failures when refreshing from remote peer
and the local database wasn't empty, and other bugs.
* Patches and updates from Fremantle merged into Harmattan tree.
The tasks and notes support is untested. Please report on how it works.
I also tried two other ways to improve the KCalExtended backend:
1. Convert it to TrackingSyncSource, for better reliability.
This proved infeasible because insertItem() needs to return a new
revision, but the new revision is not generated before calling save(),
which is only done in endSync(). And, of course, calling save() for
every single item is abysmally slow (and I couldn't even get it to work
properly). However, it might still be possible to rewrite the backend to
be TrackingSyncSource-*like*, with the difference of loading the new
revisions in endSync() instead of in insertItem(), which would not be as
slow. But probably still slower than the current approach.
2. Use partial loading of the calendar, to reduce memory requirements.
It turns out that the bug that caused this feature to be disabled,
bugs.meego.com/6061, is not actually fixed. It's fixed if a save() is
done between step 3 and 4 in Patrick's recipe, but it still fails if
there's no save(). And again, doing a save() in every single deleteItem
or insertItem is not desirable.
8 years, 4 months
[SyncEvolution] file backend question
by Ildar Mulyukov
Hello, Patrick, all,
I'm quite new to syncevo, so please forgive my lame questions.
1st, Patrick, thanks for your quick answer on Bug#54547.
New Q:
I want to set up one-way sync from the Google server for backup
purposes.
$ syncevolution --configure username=foobar sync=refresh-from-server
backend=file database=file:///tmp/2ab databaseFormat=text/x-vcard
syncFormat=text/x-vcard Google_Contacts
My contacts number > 50, so syncing 1st time it gets first 50 contacts.
But syncing 2nd time does:
[INFO] addressbook: deleting 1/50
...
[INFO] addressbook: deleting 50/50
[INFO] addressbook: started
[INFO] addressbook: received 1/50
...
[INFO] addressbook: received 50/50
Sucks :(
AFAIU this is because the file backend is flawed, not having any UID.
Now is it possible to improve it so it works as intended?
Thanks. Best regards,
--
Ildar Mulyukov, free SW designer/programmer
================================================
email: ildar(a)users.sourceforge.net
home: http://johan-notes.blogspot.com/
ALT Linux Sisyphus
================================================
8 years, 4 months
[SyncEvolution] PBAP: one-way sync modes
by Patrick Ohly
Hello!
For the PBAP caching mechanism in SyncEvolution I'd like to use the
Synthesis engine. I think that makes sense because the engine does a few
things which would have to be done manually otherwise (translate between
formats, finding pairs). The improvements below would also make sense in
other use cases.
At the moment the engine (or rather, SyncML) lacks a few things which I
need to change. I'm focusing on one-way-from-client syncing because the
server has a bit more control over what it does and because it matches
the SyncEvolution use case.
In SyncML, incremental one-way syncs fall back to a two-way slow sync
after a failure. If the server has an item which the client no longer
has, then the item will be recreated on the client, despite the
intention to only transfer data in one direction. Right?
This is undesirable in general (IMHO), and an absolute no-no for PBAP as
the client, because it cannot write the changes.
As a first step I would disable sending changes to the client if the
client asked for a one-way-from-client sync. The server's datastore can
already be marked read-only (<readonly> config option, SETREADONLY());
something similar for the peer's datastore would make sense. Then I
could leave the default behavior as it is and use a script function to
trigger the desired behavior.
Actually, there is SETREFRESHONLY(). According to the docs, it is meant
to be used for turning a two-way sync requested by the client into a
refresh-from-remote. I need to check whether I can use that or still
need to add/modify something.
Suppose a slow sync was done in that modified refresh-only mode. Any
item that the server has which are not on the client need to be removed
if the server's storage is meant to mirror the client.
At the moment, the engine cannot know whether it is meant to mirror the
data and thus it will leave the extra items on the server unchanged. I
intend to add a "<mirror>" config option similar to "<readonly>". If
set, the engine will not only avoid sending changes to the client, it
will also remove those extra local items.
Finally, during a slow sync where a match was found, extra properties in
the server's copy of an item must be removed to avoid keeping stale
data. This can already be done by configuring the merging of items
accordingly (instead of preserving as much data as possible, ensure that
the client's item is always considered the "winning" one and that its
version completely overwrites the server's).
--
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, 4 months
