When a backend is inactive, it is meant to ignore generic types like
"calendar". The idea behind that is that typically users install or
compile just the backends they want, and then ask for the "calendar"
backend using the generic sync templates or instructions.
When adding the TDEPIM calendar backend, that broke because it also
instantiated itself for those terms when active. The other TDEPIM
backends already did this as intended.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
The latest activesyncd contains GSettings schema files
which get installed by the top-level makefile, therefore
we have to install everything.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
The *Register.cpp files and everything they include must compile
without hard dependencies on header files which are TDE specific,
so add some ifdefs. Compiling with TDE backends disabled broke
because of this.
When enabled (untested!), it is unclear how some of these *Register.cpp
could have worked without including the header file that defines the
class they instantiate. Added the necessary includes.
A closing } was missing (found by cppcheck, which tests all variations
of the code, not just those currently enabled).
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
dbus-launch is considered deprecated because of the X11 dependency.
See https://lists.debian.org/debian-devel/2016/08/msg00554.html "Mass bug
filing: use and misuse of dbus-launch (dbus-x11)"
The script still needs to start the D-Bus daemon when used in the nightly
testing, so the code now does it as in
6cc8062cfb
syncevo-http-server still has some usage of dbus-launch left, but that's
strictly for systems which don't have the more modern D-Bus.
With the recent change ("Add a systemd user service as a backend for the D-Bus
session services"), activating syncevo-dbus-server via D-Bus will integrate
better with systemd. When auto-starting via the .desktop file, we can do the
same by activating via D-Bus.
We use dbus-send for that, if available. A recent busctl from systemd could
also be used, but for example the one in Debian Jessie is still to old. Better
use dbus-send. Directly starting the binary is used as fallback.
Based on a patch from Simon McVittie.
On systems with a systemd user session and a D-Bus user bus that
uses it for activation, this ensures that syncevo-dbus-server ends
up in its own cgroup, instead of being treated as part of dbus.service.
If org._01.pim.contacts and org.syncevolution are activated in quick
succession, it also prevents a race condition that would make one of
the activations fail, similar to
<https://bugs.freedesktop.org/show_bug.cgi?id=53220> in
telepathy-mission-control.
Apparently there's a race condition in the OBEX transport that causes the
connection to phones via Bluetooth to be shut down prematurely. Some phones
react by doing a slow sync instead of an incremental sync the next time.
Waiting during shutdown should address the problem (however, it was not
possible to confirm this).
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.
Previously, backends were loaded in a constructor. At some point (*), that
loading crashed with a segfault in the dynamic linker. To make debugging a bit
easier and rule out non-determinism as the root cause of that crash, loading
backends was moved into SyncContect::initMain().
(*) the crash happened when there were two backends which couldn't
be loaded due to missing libraries and was related to error strings.
A simpler test program did not trigger the problem, and now SyncEvolution
has suitable backends for (hopefully?!) all platforms, so it no longer
occurs, at least not during automated testing.
SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --version now
dumps also the debug information gathered by the binary
compatibility code. It was only available in sync logs before.
We call some pthread methods and thus must link against libpthread.
Previously this must have worked by accident, but started failing
on more recent distros.
DAViCal on Debian Stretch incorrectly re-formats contacts which do not have a
REV property (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837154).
Until this gets fixed we work around the problem by including a REV in all
test cases, which implies refreshing the Google CardDAV patch.
Recent shells filter out environment variables that are not valid shell
variables, so for example,
SYNCEVOLUTION_FILE_SOURCE_DELAY_OPEN_addressbook-slow-server did not get
passed through to syncevo-dbus-server because of the hyphen. As a result, the
tests became unreliable (non-deterministic timing) or outright failed.
Now we ensure that these variables are valid also in a shell and in addition,
make the test stricter such that it detects when the file backend did not
wait.
Recent distros like Debian Stretch have newer dbus-monitor with
extended content that no longer matched the regex used before. The
relaxed regex works with old and new dbus-monitor.
When building on the new syncevolution.org reference platform, Ubuntu Trusty,
building rpm packages with checkinstall fails for unknown reasons. As
providing those rpms is of questionable value (libraries are more likely to be
different on rpm-based distros than on Debian/Ubuntu), building rpm simply
gets disabled entirely.
As a fallback for users there still are the plain .tar.gz archives containing
the same files.
Previously, when --enabled was not given, all tests were run. That was meant
to simplify running all tests, but that is rare and more likely to happen by
mistake when not selecting tests correctly in the automated testing, so now we
revert the logic and don't select a test if no --enable filter is set.
The XDG symlinks were created as fallback in case that the XDG env variables
somehow were ignored. In practice, the symlinks were not needed, so it didn't
matter that they were set incorrectly to the path name outside of the chroot.
But it's confusing when debugging the setup and just plain wrong, so better
fix it...
client-test makes new directories user-readable because that is
the default for all SyncEvolution directories. But after publishing
the test results, they need to be world-readable, because they are
going to be accessed via some kind of web server running under
some different user.
These linker flags are added to those normally used for linking against
libsyncevolution. The intended usage is to extend linking of syncevolution.org
binaries such that static versions of libcppunit, libpcrecpp and libopenobex
are used, because the ABI of those libs have changed such that binaries linked
on Ubuntu Trusty would not run on more recent distros like Ubuntu Xenial.
For example, on Ubuntu Trusty i386 one can configure with:
PCRECPP_LIBS=-lpcre \
LIBOPENOBEX_LIBS=-lpcre \
'--with-extra-core-ldadd=/usr/lib/i386-linux-gnu/libpcrecpp.a -lpcre /usr/lib/libopenobex.a /usr/lib/i386-linux-gnu/libusb.a' \
CPPUNIT_LIBS=/usr/lib/i386-linux-gnu/libcppunit.a
Now cppcheck is found via the normal PKG_CHECK_MODULES. The advantage
is that CPPUNIT_CFLAGS and CPPUNIT_LIBS can be overridden with
configure parameters, which will be used to link cppcheck statically
into syncevolution.org binaries (libcppunit ABI has changed).
syncevolution.org binaries are going to support distros >= Ubuntu Trusty.
All of those have libnotify.so.4, so the old binary compatibility hack is
no longer needed.
cppcheck correctly warned that initializing a reference is enough,
no need to copy the string:
dbus-sync.cpp:97: cppcheck performance: passedByValue - Function parameter
'source' should be passed by reference.
cppcheck seems to mix up different template variations. The following error
needs to be suppressed in the classes which don't even have an m_a member:
gdbus-cxx-bridge.h:330: cppcheck warning: uninitMemberVar - Member variable
'Set::m_a' is not initialized in the constructor.
gdbus-cxx-bridge.h:339: cppcheck warning: uninitMemberVar - Member variable
'Set::m_a' is not initialized in the constructor.
cppcheck correctly warns about the old code as less efficient (looks
at entire string instead of just the start). Using boost::starts_with
is less obscure and avoids the warning.
Building client-test fails because a const pointer looses the
const attribute while passing it through boost::bind.
Fixes:
boost/lambda/detail/function_adaptors.hpp:357:16: error: invalid conversion
from 'const SyncEvo::SyncSource*' to 'SyncEvo::SyncSource*' [-fpermissive]
return func(a1);
When compiling as C++14 (the default under gcc 6), template
expansion no longer picks the right instantiation of push_back.
We have to disambiguate which of the different push_back
alternatives we want.
Fixes:
Cmdline.cpp:1734:85: error: no matching function for call to 'bind(<unresolved
overloaded function type>, const boost::reference_wrapper<std::__cxx11::list<std::__cxx11::basic_string<char> >
>, const boost::arg<1>&)'
processLUIDs(source, boost::bind(&list<string>::push_back, boost::ref(luids), _1));
The implicit conversion of boost::shared_ptr->bool is no
longer supported when compiling as C++14 (the default under
gcc 6). We have to cast explicitly.
Fixes errors like this:
Logging.h:258:41: error: cannot convert 'const boost::shared_ptr<SyncEvo::Logger>' to 'bool' in return
operator bool () const { return m_logger; }
libical v2 provides support for interoperable timezone definitions
again, so the copy of the original code that was added for libical v1
is not needed anymore and also wouldn't compile.
Therefore SyncEvolution can drop it when being compiled for v2. In that
case, a corresponding change in libsynthesis calls
icaltzutil_set_exact_vtimezones_support(0) to enable interoperable
timezones.
This addresses compilation and running with libical v2, i.e. what
normal distros are doing. Compiling with libical v1 and running
with v2 needs to be addressed separately, if possible at all.
