syncevolution.org binaries are now getting compiled on Ubuntu Trusty and thus
no longer support distros with older EDS. The code should still compile
against older EDS (for example, for Maemo), but that is not getting tested
anymore.
This allows removing the dynamic linker hacks related to older libraries,
which was only used in those binaries. Instead, backends using libical or EDS
get compiled on Ubuntu Trusty and then the soname of those libs get patched to
make the backend module usable in combination with a different set of
libs. That patching is part of a script maintained in the syncevolution.org
build infrastructure.
This approach was already used before to generate different EDS backends
for EDS versions with the newer EClient API, because that turned out to be
easier than the dynamic loading approach. It works because none of the methods
used by SyncEvolution changed their ABI, only some other parts of the
libraries did. Should there ever be a situation again that cannot be handled
like this, then backends might also get compiled on different distros than
Ubuntu Trusty (however, that may lead to problems due to the libstdc++ ABI
changes - to be decided...).
libical still requires one special hack: system time zone loading in
libical v1 (and only in that version, v2 has builtin support again) must
be overridden such that time zones are generated with rules instead
of transitions because that is more compatible with the peers that
SyncEvolution exchanges data with.
That hack now relies on overriding the two relevant functions inside the main
binaries (has to be there, otherwise libical still ends up calling its own
internal implementation). The overriding code is in
libsyncevo-icaltz-util.so.0 and depends on libical.so.1. If
libsyncevo-icaltz-util.so.0 can be loaded, the wrappers in the main binary use
it, otherwise they fall through to the code from the current libical.so, which
then should be libical.so.2 or more recent.
This hack is active by default when libical v1 is detected during configuration.
Because of the confustion around the libical 1.0 ABI, Debian ended
up renaming the package for Debian Jessie while keeping the libical.so.1
soname. Pre-built binaries from older distros work, so just adapt
the package meta data.
The word "source" implies reading, while in fact access is read/write.
"datastore" avoids that misconception. Writing it in one word emphasizes
that it is single entity.
While renaming, also remove references to explicit --*-property
parameters. The only necessary use today is "--sync-property ?"
and "--datastore-property ?".
--datastore-property was used instead of the short --store-property
because "store" might be mistaken for the verb. It doesn't matter
that it is longer because it doesn't get typed often.
--source-property must remain valid for backward compatility.
As many user-visible instances of "source" as possible got replaced in
text strings by the newer term "datastore". Debug messages were left
unchanged unless some regex happened to match it.
The source code will continue to use the old variable and class names
based on "source".
Various documentation enhancements:
Better explain what local sync is and how it involves two sync
configs. "originating config" gets introduces instead of just
"sync config".
Better explain the relationship between contexts, sync configs,
and source configs ("a sync config can use the datastore configs in
the same context").
An entire section on config properties in the terminology
section. "item" added (Todd Wilson correctly pointed out that it was
missing).
Less focus on conflict resolution, as suggested by Graham Cobb.
Fix examples that became invalid when fixing the password
storage/lookup mechanism for GNOME keyring in 1.4.
The "command line conventions", "Synchronization beyond SyncML" and
"CalDAV and CardDAV" sections were updated. It's possible that the
other sections also contain slightly incorrect usage of the
terminology or are simply out-dated.
At least on OpenSUSE, ldconfig must be run after installing
SyncEvolution to update the shared library information cache.
Do that automatically as part of the rpm's post and postun steps.
The syncevolution-bundle description was wrong. It incorrectly
used the description of a meta package.
Renaming the backends now needs to be done before calling make.
This is used to include two versions of syncecal.so:
- one for EDS >= 3.6 < 3.10
- one for EDS >= 3.10 with the libecal-1.2 soname patched
The second flavor became necessary because EDS 3.10 accidentally
changed the soname. The API and ABI actually is the same, so
we don't need to compile twice.
The package meta data must include additional alternatives for
libecal and libebook when including extra backends. This must
be passed in via EXTRA_BACKENDS_ECAL/EBOOK_REQUIRES; the makefile
does not attempt to determine what those are.
kdebase-runtime became kde-runtime in Debian Wheezy. Accept both
as prerequisite of syncevolution-kde to allow installation on
newer distros without pulling in the transitional kdebase-runtime
package.
Only the "client-test" executable and its test data were installed so far, in
/usr/bin resp. the doc dir. Now also test-dbus.py and testpim.py plus their
data files get installed, using a new /usr/lib/syncevolution/test directory
for all test files and commands.
"runtests.py --prebuilt" can take one or more .deb files including these
tests, will install them as the "compile" operation and then will use the
installed SyncEvolution, without overriding any paths. This relies on having
suitable rights for "dpkg" and /usr/lib/syncevolution/test; the way how that
is done in the nightly testing is via chroots where the entire file system
is writable by the normal test user.
Normal users without such write access to /usr/lib/syncevolution/test need
to copy that directory into their home directory first.
When trying to add provideruoa.so compiled on Ubuntu Quantal to
the archive compiled on Ubuntu Lucid, undefined references to
future libstdc++ tripped up the symbol check.
This is actually okay for system libraries, the .so will simply
not load and/or work on older systems. Filter out such warnings,
starting with libstdc++. Other system libs can be added as needed.
libical 1.0 changed the library name to libical.so.1, causing dependency
problems becaus syncevolution.org binaries required libical.so.0.
It turned out that the relevant parts of the API and ABI had not changed,
so simply allowing both versions of the library is sufficient.
In addition, a detection of libical.so.1 gets added, just in case.
The backends must be compiled differently for EDS < 3.6 (using the old
API before EBookClient, ECalClient and ESource, ideally in
compatibility mode) and for EDS >= 3.6 (using the new API, with hard
linking against libebook-1.2.so.14, libecal-1.2.so.15,
libedataserver-1.2.so.17).
With these changes, a SyncEvolution binary compiled for the older EDS
API will be able to load and use backends compiled against the current
one. Both backends can be installed in the same
lib/syncevolution/backends dir under different names. The newer ones
must have an additional -<version> appendix before the .so suffix.
Then loading will attempt to use those backends first and if
successful, skip the older ones. This is necessary because loading
both into the same process will fail due to symbol clashes. If
unsuccessful (as on systems with only the older EDS), the dynamic
linker will fail and SyncEvolution proceeds with the backends for the
old API.
Packaging of binaries as .dev/.rpm/.tar.gz includes these additional
backends if given in the EXTRA_BACKENDS variable when invoking "make
deb rpm distbin".
Installation on older Linux distros was not possible because the ebook/ecal
package dependencies were named incorrectly, for example libebook-1.2-10
instead of libebook1.2-10. Only more recent packages have the extra
dash, for example libebook-1.2-12.
Reported by Mariusz Sokolowski.
The syncactivesync.so backend file is no longer included in the
syncevolution-bundle archives. It used to be empty anyway and just
marked the ActiveSync backend as not enabled. This was necessary
because the SyncEvolution reference platform, Ubuntu Lucid, does not
have the necessary libs to compile activesyncd.
Now a fully functional backend and activesyncd get compiled on Debian
Wheezy and packaged (outside of the Makefile) as
"syncevolution-activesync" and "activesyncd".
See https://syncevolution.org/wiki/google-contacts-activesync
As mentioned by Tino Keitel on the mailing list, some libs and
executables were only implicitly linked against libraries that they
called directly. This happened to work by chance because these libraries
ended up in the running executable anyway, due to indirect loading.
To catch such problems, the "make installcheck" was extended:
dpkg-shlibdeps is run, if available, and the error output is scanned
for the messages which indicate that a symbol is used without linking
to the right library (example output below).
Had to fix quite a few _LIBADD lines to pass the test.
Some exceptions are allowed:
- libsmltk depends on the caller providing SySync logging support.
- libneon is intentionally not linked explicitly for syncevolution.org
binaries, to make resulting binaries work with GNUTLS and OpenSSL.
dpkg-shlibdeps: warning: debian/syncevolution-libs/usr/lib/syncevolution/backends/syncdav.so contains an unresolvable reference to symbol icalparameter_new_from_value_string: it's probably a plugin.
dpkg-shlibdeps: warning: 51 other similar warnings have been skipped (use -v to see them all).
...
dpkg-shlibdeps: warning: symbol dlsym used by debian/libsyncevolution0/usr/lib/libsyncevolution.so.0.0.0 found in none of the libraries.
dpkg-shlibdeps: warning: symbol dlerror used by debian/libsyncevolution0/usr/lib/libsyncevolution.so.0.0.0 found in none of the libraries.
dpkg-shlibdeps: warning: symbol dlopen used by debian/libsyncevolution0/usr/lib/libsyncevolution.so.0.0.0 found in none of the libraries.
Let the bundle .deb depend on libical if the lib was enabled during
compilation (for example, for CalDAV). This ensures that it gets
installed on systems which otherwise don't have it.
The EDS backend in the syncevolution.org packages are compiled
for the API in EDS <= 3.4. With some tricks (dynamically
loading libs) it works across a range of libecal and libebook
releases.
Now the syncevolution-evolution meta package declares that
it depends on one of these libecal/ebook libraries (was missing
earlier), to ensure that the libs get installed on a system
which did not have them already.
The dynamic loading will no longer attempt to work with
EDS 3.6. For EDS 3.6 it will be necessary to update the EClient
variant of the EDS backend and compile the syncevolution.org
binaries differently.
The previous commit broke parallel "make deb" (because mv *.deb
matched different package builds and then mv only succeeded for one)
and "make rpm" (because the mv was looking in the wrong place).
The packages unintentionally contained README.rst, README.rst.patched
and README files in a second /usr/share/doc directory.
They were picked up by checkinstall because they happened to be in the
current directory. Fixed by preparing running checkinstall inside
a "checkinstall" directory which contains just the content needed
for packaging.
/etc still wasn't included because removing developer files
accidentally removed it - probably came from some now obsolete attempt
to remove Buteo files.
On the other hand, developer files were not remove properly
from .deb and .rpm because the path prefix wasn't right.
syncevo-dbus-server wasn't started automatically as part of a user
session because /etc/xdg/autostart/syncevo-dbus-server.desktop wasn't
included in the packages. This broke auto syncing after a session
restart (required manually starting SyncEvolution).
The traditional "syncevolution-evolution" .deb package will be
replaced with "syncevolution-bundle". A meta "syncevolution-evolution"
package depends on it, to support seamless updates for users who have
"syncevolution-evolution" installed.
Binary dependencies of the main .deb are ignored for backends
because loading them is optional. The new "syncevolution-kde"
package has the right dependencies for KDE/Akonadi, while
"syncevolution-evolution" mostly just lists standard libs
if the "EDS compatibility" mode is used, where libebook/libecal
are loaded dynamically.
Compiling on Ubuntu Lucid and finding package dependencies with
dpkg-shlibdeps led to a .deb which wasn't installable on
Debian Testing because the kdelibs5 and kdepimlibs5 are no
longer provided. They were replaced with individual library
packages.
Handle that by overriding the output of dpkg-shlibdeps when
it contains kdelibs5 or kdepimlibs5 and allow the more recent
packages as alternative.
libsyncevolution depends on libgdbussyncevo. On installation the
former needs to be relinked, but the latter is still not installed
and that causes linking to fail with following message:
/usr/bin/ld: cannot find -lgdbussyncevo
That is so, because the order of installing binaries is not
dependency-based but more like target directory based:
install-exec-am: install-binPROGRAMS install-binSCRIPTS \
install-libLTLIBRARIES install-libexecPROGRAMS \
install-libexecSCRIPTS install-nodist_binSCRIPTS \
install-pkglibLTLIBRARIES
libsyncevolution is installed during install-libLTLIBRARIES, while
its dependency is installed during later install-pkglibLTLIBRARIES.
Conflicts:
Makefile.am
configure-post.in
configure.ac
src/Makefile-gen.am
src/dbus/qt/Makefile.am
src/syncevo-dbus-server.cpp
test/test-dbus.py
Conflicts caused by renaming of files on master. Manually applied the
relevant changes to the renamed files.
Fedora's build of SyncEvolution 1.2.1 failed because running the
uninstalled src/syncevolution didn't find the necessary shared
objects. Not sure why: on Debian Testing, src/syncevolution invokes
src/.libs/lt-syncevolution, which has the necessary paths set as
RPATH.
As a workaround, set LD_LIBRARY_PATH explicitly. This intentionally
includes a path which is only relevant on the master branch
(gdbuscxx), to simplify merging.
The <<insert sync/source-property>> tags were visible in the --help
output. Now it says
<< see "syncevolution --sync/source-property ?" >>
These special tags still get expanded in README and man page.
That expansion is done by invoking the uninstalled syncevolution
binary. If that failed, compilation aborted. That's still the case
for native compilation (because we want to catch problems). For
cross-compilation such a failure is okay and keeps the tags in
the README/man page. That's done because running a binary compiled
for an entirely different architecture is not guaranteed to work.
All but toplevel Makefile.am are replaced with their non-recursive
counterparts. The generation of configure.in was removed (and thus
configure-{pre,post}.in are also removed) in favor of configure.ac
and m4 macros adding backend specific configure parts.
Version number is generated like in old build system.
There are still many things to improve, but for now there are no
immediate regressions. AUTOTOOLS-TODO contains a list of possible
improvements and fixes. AUTOTOOLS-TESTING contains what was tested
with current build system (configure flags, make options).
When --enable-neon-compatibility is used, libneon.so.27 and
libneon-gnutls.so.27 are opened dynamically instead of linking against
them. The Debian package specifies that it depends on one of these two
libs in this case. Don't use --enable-neon-compatibility when not
enabling WebDAV to avoid this dependency.
This change is necessary for Debian Testing, which no longer has
libneon.so.27 at all. Note that the very latest Debian Testing also
has another problem because libnotify1 was dropped in favor of
libnotify4.
Some unintended usage of libical slipped into the 1.1.99.5
syncevolution.org binaries, breaking the syncwebdav.so. It wasn't
linked against libical, but depended on some of its methods.
This commit strenghtens the installcheck-local test. First, it checks
for undefined symbols in the blacklisted libraries (detects the
syncwebdav.so case). Second, it also checks for the blacklisted
libraries (might be linked unnecessarily, for example when forgetting
to add -Wl,--as-needed). Third, it checks syncevolution (relevant when
linking everything statically). Finally, it does the check on the
installed files (should have been like that all along).
Patching the top-level Makefile.am is no longer necessary
thanks to the simplified gen-autotools.sh approach. Renaming
it back to the normal Makefile.am.
This change makes it possible to add a new backend without
changing any of the core files. It also gets rid of some
hacks (like -export-dynamic for the binary) by putting all
core SyncEvolution code into a library.
The transition is not quite complete: there are still
some lists of existing backends, which will be removed
soon. EvolutionSmartPtr.h and EvolutionSyncSource depend
on Evolution/GNOME libs, which forces all backends to
use the right -I flags.
git-svn-id: https://zeitsenke.de/svn/SyncEvolution/trunk@684 15ad00c4-1369-45f4-8270-35d70d36bdcd
- the new checkinstall --docdir=: syntax is used to avoid adding the name twice
- description-pak was not created and thus missing from package
git-svn-id: https://zeitsenke.de/svn/SyncEvolution/trunk@476 15ad00c4-1369-45f4-8270-35d70d36bdcd
