Two bugs fixed here:
1. status handler could potentially be called several times with "idle"
2. the StatusChanged handler did things differently from GetStatus
An invalid type (like inactive backend, or something the user
entered into the file manually) raises an exception when accessing
the source parameters. This exception must be caught and transformed
into the SourceUnusable exception expected by D-Bus clients.
An unset type leads to a NULL SyncSource pointer. This was checked,
but without raising an exception. CheckSource() thus incorrectly
reported success.
Shutting down a sync session because of user-requested abort does not
cancel pending messages, because that would be allowed to block. Instead
the transport agent is destructed.
The SoupTransportAgent did not cancel the pending message and
therefore callbacks for a stale instance of it were invoked later on
*if* the main loop was activated again. This can only happen in the
syncevo-dbus-server, not the command line.
Apply temporary configs when calling other APIs
of sessions. This makes configs that users temporarily
set affect other APIs.
All sources filters in m_sourceFilters must be set
to config not only for existing sources in config but also
for non-existing sources. This could help users temporarily
do some operations without flushing any configs.
Currently affected APIs are Session.CheckSource,
Session.GetDatabases, Session.GetConfig, Session.Sync.
Also add 3 unit tests for CheckSource, GetDatabases
and GetConfig to test the temporary config is in
effect for them. They all are passed.
'getSyncSources' of SyncConfig only returns shared sources
in shared layout and peer sources in other layouts.
Peer sources must also be included in shared layout. Moreover,
new sources in sources filters should be taken into consideration.
It should return an union of:
1. contextpath/sources
2. peers/[one-peer]/sources
3. sources in sources filter
Implement 3 unit tests for status and 1 unit test for
progress. For status,
1) test a full status list when a sync is executed
This is checked in TestSessionAPIsReal.testSync
2) test status when session is aborted
3) test status when session is suspended
For progress, test progress number is increasing
when a sync is executed. Also combine this check in
TestSessionAPIsReal.testSync
It is necessary to specify own signal receivers in
subclasses of DBusUtil to let them add new operations.
Two methods "progressChanged" and "statusChanged" are
added in DBusUtil. They are called when handling
statusChanged and progressChanged signals in setUpListeners.
By checking progress in "progressChanged", we can
make sure that aborting or suspending takes place when
sync is running.
SESSION_END always flushes status no matter whether
there is any change of status. It will duplicate
status and send them to dbus clients.
Only send StatusChanged signal when there is a change
of status.
This problem was found by the unit test which will
check any two adjacent statuses should not be the same.
The status 'SYNC_RUNNING' should be set firstly
in Session.run instead of setting it when
SESSION_START event is reported. This could mislead
dbus clients.
Instead of fetching a specific repo, use just "git fetch" to
pull updates into an existing repo. Specifying the repo
should have worked, but apparently is not done correctly (not
yet?) by the git in Debian Stable.
Using "git fetch" assumes that the URL of the repo does not
change between updates. That should be the case for us.
In a setup where it was run inside schroot we got error
messages from schroot because gconfd got stuck and prevented
a clean unmount of /tmp. Even "kill -9" wouldn't get rid of
such a hanging gconfd.
As a workaround, running the setup command twice seems to
succeed, including getting rid of the handing gconfd.
Previously do cleanup operation after implementing
a syncevolution setup. But if this setup raises
exceptions, we might get incorrect test results.
so clean all these files before doing any other
preparations
move 'evolution-prebuilt' summary from interoperability test
to client::source. Write xml and xsl codes to generate
html output to show its testing results.
Checking out a branch which only exists remotely requires
a bit more work. Checking out tags might also have failed
due to an unnecessary "git pull". Now "git tag" and "git branch"
are used to check what the requested revision is and do the
necessary opertions.
The "prebuilt" test ran, but because it used the build directory
of the current platform it didn't find any backends, or the wrong
ones. Fixed by only using the backend setting from the previous
testing if the directory really exists and falling back to the
relative "backends" directory otherwise.
It might be possible to always use "backends". In order to not
change the running testing this wasn't done.
These two options must be part of VALGRIND_ARGS is non-default
values are desired. Previously --leak-check=yes and --trace-children=no
were always set by the script, which is too inflexible.
Add README.zyb file for ZYB interoperability test and
customize specified test cases for ZYB.
Now ZYB only supports contacts(vcard2.1). Now all test
cases of contacts are passed.
Some properties in vcard21 are dismissed by ZYB server.
So we ignore them in synccompare:
CALURI, CATEGORIES, FBURL, NICKNAME, X-MOZILLA-HTML,
PHOTO, X-EVOLUTION-FILE-AS, X-ANNIVERSARY,
X-ASSISTANT, X-EVOLUTION-BLOG-URL, X-EVOLUTION-VIDEO-URL,
X-GROUPWISE, X-ICQ, X-MANAGER, X-SPOUSE, X-YAHOO, X-AIM
ZYB may send mismatched anchors though
there is no mistake between two syncs. If client
checks anchor, then a slow sync will be initiated.
So, synthesis adds an element 'lenientmode' in
'remoterule' to provide capability of disabling
or enabling anchors checking. Disable this kind
of checking for ZYB.
Mobical has a known server issue that it initiates a
slow sync when one client syncs with it in one-way-from-client
mode from the second time.
Because Mobical has no schedule on this, we skip this
test for Mobical interoperability test.
The command line did not read the global defaultPeer property unless
it found an existing context. This is an unnecessary optimization,
reading from an non-existant context yields no properties except
perhaps for defaultPeer, so we can do that and get the correct
result with and without a context.
Jussi mentioned that he didn't get defaultPeer when reading a
template. Added TestMultipleConfigs.testSharedTemplate to verify
that, but it passes without issues.
This patch allows a user to read and write the single "defaultPeer"
property in ~/.config/syncevolution/config.ini even when selecting
a peer which has a legacy config in ~/.config/syncevolution/<name>.
This is more convenient and ensures that the sync-UI works correctly
even in those cases where the legacy config cannot (or has not) been
migrated.
It works by adding multiplexing of properties to the HTTP_SERVER case
and then using a separate global config node.
Really, really old configs in .sync4j/evolution do not share the
defaultPeer property, but I think this is acceptable.
Broke while adding support for shared configs. We didn't have a test
for it, therefore this went unnoticed. I have added a test for it
(CmdlineTest::printFileTemplates) and fixed the issue (using the wrong
file layout for templates).
The test depends on having access to installed templates in a known
location, which previously was a problem due to the hard-coded
TEMPLATE_DIR. Now SyncContext::createServerTemplate() checks an env
variable (SYNCEVOLUTION_TEMPLATE_DIR) which is set by most of the
command line tests to prevent reading from there unintentionally and
once to "./templates" to ensure reading from there.
Adding
to the comment of "type" tripped up the Cmdline test,
which scans for lines which look like default property
values.
Rephrased the comment to avoid that, by removing the
"evolutionsource" keyword and the assignment.
Since introducing shared configs, the default value of "sync" is
"none", so that peers which happen to share a source not configured
for them do not accidentally use it.
The code which prepared templates had not been adapted, breaking the
Cmdline test. Now an unset sync property is set to "two-way" for all
four default data sources, just like it was set before.
File templates can still set a specific source to some other default,
like "sync = none".
More recent libtool versions contain a check that the
install dir doesn't deviate too much from the libdir
compiled into the libs. This check failed when the
chosen path ended with a slash, leading to:
libtool: install: error: cannot install `syncecal.la' to a directory not ending in ...
I consider this a bug in libtool and sent a bug report
together with a fix. In the meantime, let's avoid the
problem by not adding any redundant slash in our
path...
This depends on peer/context awareness in the code which looks for
the old config and renames it. If the old config is not in the same
context as the new one, it is searched by peer name alone. This
works for all old-style configs as well as rewriting a peer inside
the same context.
