Added code which checks for existence of the helper binary in the
libexec dir when it is given without any path component. Searching
inside the PATH env variable is still used as fallback when not
found in libexec (useful for testing without actually installing
in the final destination).
Dead code, doesn't work. Merely committing as reminder. As before,
anything written by the child's logging code to stdout is printed
directly to the parent's stdout (no redirection anywhere).
The problems with this patch were:
- when SYNCEVOLUTION_DEBUG was set, the code still redirected
the child's stdout to stderr
- the child prints INFO messages which are relevant for the user;
with redirection, those do not reach the user
- the child's ERROR messages end up being printed as
[ERROR] stderr output: [ERROR] ....
When calling a method, give the peer unlimited time to reply. Relevant
in particular for local sync, where the time for processing a message
is basically unpredictable.
Communication with the D-Bus daemon still uses the default timeout.
Instead of overloading std::pair with additional meaning, use
GDBusCXX::DBusArray when we want to pass byte arrays. Allows defining
"normal" traits for std::pair.
API change, must be done in both D-Bus CXX layers and in the code using it.
- moved common code into base class (prepare/send) reps. .cpp file (CheckError())
- retrieve D-Bus error description from error message and use it as part of
the C++ exception description, in addition to the error name (only error
name was used before)
- add call operators with up to 10 parameters
Checking authentication needs to be abstraced and cannot be done with
a libdbus-only method. At the moment the assumption is that the
connecting client is at least from the same user.
ForkExecParent is now keeping track of the current state:
IDLE, /**< instance constructed, but start() not called yet */
STARTING, /**< start() called */
CONNECTED, /**< child has connected, D-Bus connection established */
TERMINATED /**< child has quit */
Was needed for local sync and might be useful also elsewhere, thus
implemented in the core fork/exec code itself.
Methods called from glib C code must not throw exceptions. If that
happens, the problem will be reported via onFailure.
The more likely problem is that the child quits prematurely or with an
error code. Both is reported via onFailure now, so the user of
ForkExecParent no longer has to watch the child itself.
The parameter wasn't really needed for anything. Everything happens
inside the main context and the caller is responsible for creating and
running a loop.
This depends on glib and D-Bus support. There is no global switch for
D-Bus on/off, only one for syncevo-dbus-server on/off, so that is what
is getting checked for now. The utility class is inside
libsyncevolution.la, so that library now also depends on
libgdbussyncevo.la, if enabled.
The actual implementation uses the GDBus client/server utility classes
abnd g_spawn(). A child watch is used to detect premature exits of the
child.
The idea was to also have a failure signal. Except for "child quit
without establishing connection" there is no error which currently has
to be reported, and that problem is already reported via the onQuit
signal. Therefore there is no onFailure signal yet.
AllocStringArray() allocates at least the array of plain string
pointers and optionally also copies the strings. Arbitrary alloc/free
functions can be used. Default is to not copy strings and use new []
for the array. That matches a usage where the strings are owned by
some collection and the array is in a boost::scoped_array.
Can run as both client and server. Linked against libsyncevolution
only because it needs some utility methods in it.
Logs authentication state when a new connection is created. Currently
such connections are unauthenticated at first. If the client has the
same user ID as the server, it is allowed to proceed (tested
empirically). If not, authentication fails and handle_message() is
not called (but the connection remains open!?).
Disconnects are not properly detected because GDBus for libdbus
doesn't support reporting disconnects on a connection (not
implemented). Instead of relying on it, better watch child or parent
via some other means. In this example, the server side just keeps
the connection open until the next client connects. The client
lets GDBus exit() the process on disconnect.
Added methods and classes for setting up direct D-Bus communication.
Only implemented for the non-GIO GDBus at the moment.
The callback must not throw exceptions because it is invoked from
plain C code.
First, asynchronous method replies were not detected because their
dbus_traits still had "asynchronous = false". Second, the NULL reply
from an asynchrounous implementation was passed to
g_dbus_connection_send_message(), causing an error message to be
logged.
Adding the always-on '/' object for ConnMan broke Bluez testing,
because adding a second '/' object for the Bluez calls fails with:
KeyError: "Can't register the object-path handler for '/': there is already a handler"
This makes sense, because at the D-Bus message might be sent directly,
without including the well-known bus name, and thus finding the right
right object cannot be done by bus name.
Solved by registering a unified ConnMan/Bluez root object which provides
both interfaces.
syncevo-dbus-server tried to connect to Network Manager on the system
bus when doing unit testing of the ConnMan code, which influenced the
outcome of the tests. Now test-dbus.py disables the usage of Network
Manager via the new DBUS_TEST_NETWORK_MANAGER env variable.
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.
ssize_t and size_t were taken for granted after including
some C++ header files. That's not guaranteed and breaks
on FC17 with g++ 4.7.
Probably the "pure C++" lcs code shouldn't use these types;
for now let's simply include unistd.h.
When NEON_LIBS=-lneon-gnutls, the sed invocation didn't properly turn
that into -ldl. Instead it used -ldl-gnutls, which caused a link error.
Fixed with an extended regex.
Partial cherry-pick from 856576df99 (without the install check).
SyncEvolution did not recognize any cellular connectivity as suitable
for syncing. The check for "connected technology" is unnecessary,
anything which makes the computer "online" should be good enough.
So now just use the ConnMan "State" property.
Additional benefit: will continue to work with ConnMan 1.0, which
won't have the "ConnectedTechnologies" property anymore.
The SyncEvolution code also (mis)used the "AvailableTechnologies"
property to determine whether OBEX over Bluetooth might work. As this
property is also going away, too, am changing the code so that
Bluetooth is always considered available (was already the case when
using Network Manager).
The Python D-Bus test for this functionality was overly complex (used
hidden state, code duplication) and didn't work (BMC #21541). Cleaned
up, which revealed some undesirable and broken behavior (BMC #24648).
That needs to be fixed separately. At the moment the test checks the
current behavior and works around the bug, so it passes.
The logic for dumpData and printChanges wasn't implemented correctly.
- run sync with dumpData=0 printChanges=0 => writes database dumps
("before/after" in logdir) although it shouldn't
- run status check (--status) with dumpData=1 printChanges=0 => dumps and
prints changes although it should do neither
- same for --restore
The fix is to check the "print changes" setting in addition to (and
not instead of) m_doLogging. m_doLogging is merely an override used in
testing. If false, then the logdir handling and thus data dumps are
disabled.
For --status only check printChanges. This used to print changes and
thus dump data when either dumpData or printChanges were set. It makes
more sense to only produce the output when exactly that is asked for.
SyncEvolution is known to work with EDS 3.2. Therefore use the
libebook/ecal/edataserver libs from 3.2 if available, without warnings
in the --version output. Also happens with inconsistent distro setups
where the old libs are available and would have been prefered by
SyncEvolution 1.2.1 even though the old libs no longer work with EDS
3.2.
The file is necessary for running autogen.sh. Without it, the
src/dbus/qt directory was entered without having generated its
Makefile during configure, leading to a compile error.
When bundling the libsynthesis source code, it's .gitignore file was
also bundled. The .gitignore caused problems when re-importing the
.tar.gz into git and normally isn't necessary, so don't ship it.
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.
g_variant_get() does not work for C++ bool directly because at least
on x86_64, C++ bool uses 1 byte while gboolean uses 4. This caused
random stack corruption when unpacking four bytes into an address
which only had room for one. Caused "syncevolution --version" to segfault
when using a corrupted std::string later.
DBusCallObject and friends were not used anywhere. Removed.
DBusObject and DBusRemoteObject used pure virtual methods to let
derived classes provide information about interface, path,
destination, method and the connection. The idea behind that was that
most of these strings are static and thus do not need to be copied.
The downside is that one had to derive from these classes in order to
provide the required information. The same class could not own two
instances of the generic DBusObject to access two different
destinations. It also sprinkled the code for setting up D-Bus
operations into several different places (constructor, class definition).
Now the information is passed to the DBus[Remote]Object constructor
and stored in the classes, which are thus merely containers for the
information and thus easier to use. Users of the classes still derive
from them, to keep the change smaller, although that is no longer
necessary.
Removed plain DBusConnection pointers from the C++ interface, return
DBusConnectionPtr instead. The exception is DBusObject, which still
returns plain pointers owned by the instance (as before) to ease
integration with the underlying D-Bus library. DBUS_CONNECTION_TYPE
is not needed.
This revealed that quite some code incorrectly took another reference
to the connection when assigning to DBusConnectionPtr (assignment
always increases the refcount, only in the constructor is that
optional). As a result the private connections were never
destructed. Apparently there were some global pointers to active
connections, so that this (minor) resource leak didn't show up in
valgrind.
It also showed that the closing of the D-Bus connection never happened
properly, although libdbus requires it. The ref counting mechanism
cannot be used for this because it cannot be checked whether the last
reference is about to be dropped. The slightly hackish solution is to
designate one DBusObject as the "main owner" of the connection. When
that object destructs, it closes the connection. There might still be
some other references; they simply cannot (and shouldn't) send or
receive messages anymore.
When compiling libsynthesis as part of the normal make invocation,
libsyncevolution.la had a dependency on libsynthesis.la, but no rule
to generate it. That worked for "make all" (because it entered the
subdir first), but not for "make <something>" where <something>
dependended on libsynthesis.
This commit adds such a rule. It is enough for initial builds, but not
complete yet because the outer make doesn't know the dependencies of
libsynthesis.la and thus won't trigger rebuilds. Add the complete file
list?
After removing a watch, destroying the glib source once more accessed
the now invalid "watch" pointer in finalize_watch(). Found in D-Bus
server mode after closing one connection.
The GSource was kept running and continued to use the freed
connection. Must use g_source_destroy() instead of g_source_unref() to
remove the source from the main loop in addition to decreasing its
ref count.
free_watch() is the right place to free WatchData, not
finalize_watch(), because the call sequence is free_watch() ->
g_source_destroy(source) -> finalize_watch().
Closing an unshared connection in free_connection() is too late,
because that is the destructor callback which is only called after
the last reference was already dropped. For the same reason the
dbus_connection_unref() there was wrong.
That code was never called in SyncEvolution because all connections
had their reference count increased one time to often when assigning
to DBusConnectionPtr. Fix will be committed separately. The problems
in this commit were found after fixing that problem and introducing
temporary connections in a D-Bus server, because then the faulty code
was called.
