3:16 p.m.
Hello Chris!
One comment on your commit in the test-dbus branch:
-----------------------------------
commit da74d2aa1b671c0794cd88a854e137ae93ee102a
Author: Chris Kühl <chrisk(a)openismus.com>
Date: Tue Jun 28 14:48:56 2011 +0200
test-dbus: Remove check for only one report.
Whenever there is an existing sync report in the cache directory, the
testSync test fails. This fixes that, albeit probably naively.
diff --git a/test/test-dbus.py b/test/test-dbus.py
index b6d99c4..083e8b5 100755
--- a/test/test-dbus.py
+++ b/test/test-dbus.py
@@ -636,7 +636,7 @@ class DBusUtil(Timeout):
# now check that report is sane
reports = self.session.GetReports(0, 100, utf8_strings=True)
- self.assertEqual(len(reports), 1)
+ #self.assertEqual(len(reports), 1)
if expectedResult:
self.assertEqual(int(reports[0]["status"]), expectedResult)
-----------------------------------
"the cache" directory should be ./test-dbus/cache/syncevolution, which
is getting cleared before running each test. See the xdg_root part of
test-dbus.py.
Which test has the problem with too many reports? Does it use its own
XDG root?
--
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.
5:58 p.m.
On Wed, 2011-06-29 at 13:16 -0700, Patrick Ohly wrote:
Hello Chris!
One comment on your commit in the test-dbus branch:
-----------------------------------
commit da74d2aa1b671c0794cd88a854e137ae93ee102a
Author: Chris Kühl <chrisk(a)openismus.com>
Date: Tue Jun 28 14:48:56 2011 +0200
test-dbus: Remove check for only one report.
[...]
Which test has the problem with too many reports? Does it use its
own
XDG root?
I found that the TestSessionAPIsReal tests using the real config
"dbus_unittest" failed when too many reports where stored. I don't know
how this was meant to work; one possible solution is to configure that
config so that at most one report is retained. I've changed test-dbus.py
accordingly and also removed the mangling of the "database" property:
""" All unit tests in this class have a dependency on a real sync
config named 'dbus_unittest'. That config must have preventSlowSync=0,
maxLogDirs=1, username, password set such that syncing succeeds
for at least one source. It does not matter which data is synchronized.
For example, the following config will work:
syncevolution --configure --template <server of your choice> \
username=<your username> \
password=<your password> \
preventSlowSync=0 \
maxLogDirs=1 \
backend=file \
database=file:///tmp/test_dbus_data \
databaseFormat=text/vcard \
dbus_unittest@test-dbus addressbook
"""
This fixes two out of seven failures that I was seeing, after I merged
Chris' fix for the templates.
Here's a temporary analysis of the failure. I'll continue to look into it.
FAIL: read templates
Fails if the host has paired Bluetooth devices because they get included in the list.
Cannot be fixed easily.
FAIL: a second session should not run unless the first one stops
AssertionError: ['session /org/syncevolution/Session/12604096081309383605 idle',
'session /org/syncevolution/Session/2552452311309383604 done'] != ['session
/org/syncevolution/Session/12604096081309383605 idle', 'session
/org/syncevolution/Session/12604096081309383605 ready', 'session
/org/syncevolution/Session/2552452311309383604 done']
"Ready" before "Done"? Might be harmless, need to check.
FAIL: Executes a real sync with no corresponding config.
AssertionError: dbus.UInt32(500L) != 10500
"No such config" should be a local error, not a remote one. Must be fixed in
syncevo-dbus-server.
FAIL: set up auto sync, then check that server restarts
AssertionError: '/tmp/local/libexec/syncevo-dbus-server' !=
'/home/pohly/work/syncevolution/src/syncevo-dbus-server'
Caused by a mix-up between paths: as long as syncevo-dbus-server is only once in PATH,
this doesn't occur.
FAIL: master must detect a hanging child
Sync succeeds although it shouldn't - timing changes?
--
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.
5:24 a.m.
On Thu, Jun 30, 2011 at 12:58 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Wed, 2011-06-29 at 13:16 -0700, Patrick Ohly wrote:
> Hello Chris!
>
> One comment on your commit in the test-dbus branch:
>
> -----------------------------------
> commit da74d2aa1b671c0794cd88a854e137ae93ee102a
> Author: Chris Kühl <chrisk(a)openismus.com>
> Date: Tue Jun 28 14:48:56 2011 +0200
>
> test-dbus: Remove check for only one report.
[...]
> Which test has the problem with too many reports? Does it use its own
> XDG root?
I found that the TestSessionAPIsReal tests using the real config
"dbus_unittest" failed when too many reports where stored. I don't know
how this was meant to work; one possible solution is to configure that
config so that at most one report is retained. I've changed test-dbus.py
accordingly and also removed the mangling of the "database" property:
""" All unit tests in this class have a dependency on a real sync
config named 'dbus_unittest'. That config must have preventSlowSync=0,
maxLogDirs=1, username, password set such that syncing succeeds
for at least one source. It does not matter which data is synchronized.
For example, the following config will work:
syncevolution --configure --template <server of your choice> \
username=<your username> \
password=<your password> \
preventSlowSync=0 \
maxLogDirs=1 \
backend=file \
database=file:///tmp/test_dbus_data \
databaseFormat=text/vcard \
dbus_unittest@test-dbus addressbook
"""
Thanks, this worked for that issue. I've removed that commit from the
test-dbus branch now.
This fixes two out of seven failures that I was seeing, after I
merged
Chris' fix for the templates.
Here's a temporary analysis of the failure. I'll continue to look into it.
FAIL: read templates
Fails if the host has paired Bluetooth devices because they get included in the list.
Cannot be fixed easily.
FAIL: a second session should not run unless the first one stops
AssertionError: ['session /org/syncevolution/Session/12604096081309383605 idle',
'session /org/syncevolution/Session/2552452311309383604 done'] != ['session
/org/syncevolution/Session/12604096081309383605 idle', 'session
/org/syncevolution/Session/12604096081309383605 ready', 'session
/org/syncevolution/Session/2552452311309383604 done']
"Ready" before "Done"? Might be harmless, need to check.
FAIL: Executes a real sync with no corresponding config.
AssertionError: dbus.UInt32(500L) != 10500
"No such config" should be a local error, not a remote one. Must be fixed in
syncevo-dbus-server.
Ok. Good to know. I'm using memotoo for testing and assumed the test
was intolerant to remote configurations, thus my commit to the
test-dbus branch allowing error code 500. I'll remove that commit and
see If I can fix this.
FAIL: set up auto sync, then check that server restarts
AssertionError: '/tmp/local/libexec/syncevo-dbus-server' !=
'/home/pohly/work/syncevolution/src/syncevo-dbus-server'
Caused by a mix-up between paths: as long as syncevo-dbus-server is only once in PATH,
this doesn't occur.
FAIL: master must detect a hanging child
Sync succeeds although it shouldn't - timing changes?
Ok, thanks for the insight.
Would it be possible for you to make a step by step list of what you
do to set up your environment for testing? I think this might help us
find why we are getting different results for the "defaultPeer" issue,
for example.
Cheers,
Chris
8:57 a.m.
On Fri, 2011-07-01 at 12:24 +0200, Chris Kühl wrote:
Would it be possible for you to make a step by step list of what you
do to set up your environment for testing? I think this might help us
find why we are getting different results for the "defaultPeer" issue,
for example.
The only setup required in the host is the configuration of the
"dbus_unittest" sync config. I added some comments about that to the
TestSessionAPIsReal class, which is the only class which should depend
on it. In particular the shared properties tests should be independent
of that.
Don't run syncevo-http-server. It is not used by D-Bus testing.
Another possible difference might be how the script gets invoked. I
always run them in the out-of-tree build tree, inside "src". I run with
PATH=.:$PATH <absolute path to source>/test/dbus-test.py
This copies <path>/test/dbus-test into ./dbus-test, which is relevant
for some tests which expect a well-defined xdg root.
Your patch to use different names for the reference files and the local
copy makes sense. I don't normally notice such things because I never
run anything other than autogen in my source tree ;-}
In related news, I updated the test scripts so that D-Bus testing can be
run as part of the regular nightly testing, in each of the chroots where
tests are run. I triggered a test run, but network problems broke it
because the SyncEvolution sources couldn't be updated from gitorious.
Otherwise I would have been able now to point to
http://runtests.syncevolution.org and reports which contain D-Bus test
results.
--
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.
4:28 p.m.
On Fri, Jul 1, 2011 at 3:57 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Fri, 2011-07-01 at 12:24 +0200, Chris Kühl wrote:
> Would it be possible for you to make a step by step list of what you
> do to set up your environment for testing? I think this might help us
> find why we are getting different results for the "defaultPeer" issue,
> for example.
The only setup required in the host is the configuration of the
"dbus_unittest" sync config. I added some comments about that to the
TestSessionAPIsReal class, which is the only class which should depend
on it. In particular the shared properties tests should be independent
of that.
Ok, and yes, that configuration change fixed at least one failure. The
additional comments are very welcome.
Don't run syncevo-http-server. It is not used by D-Bus testing.
Yes, this was cleared up in a previous mail.
Another possible difference might be how the script gets invoked. I
always run them in the out-of-tree build tree, inside "src". I run with
PATH=.:$PATH <absolute path to source>/test/dbus-test.py
If I've cleaned my system-wide directories of the syncevolution files
I find that this doesn't work. I've got to additionally add the
environment variables for the template and xml files. For me
specifically it's...
SYNCEVOLUTION_XML_CONFIG_DIR=/home/chris/checkout/meego/syncevolution/src/syncevo/configs/
SYNCEVOLUTION_TEMPLATE_DIR=/home/chris/checkout/meego/syncevolution/src/templates/
PATH=.:$PATH /home/chris/checkout/meego/syncevolution/test/test-dbus.py
-v
With those things are fine... well, besides the failures we're trying to fix.
.
This copies <path>/test/dbus-test into ./dbus-test, which is
relevant
for some tests which expect a well-defined xdg root.
Your patch to use different names for the reference files and the local
copy makes sense. I don't normally notice such things because I never
run anything other than autogen in my source tree ;-}
Hopefully that can avoid a bit of confusion in the future for some poor soul.
In related news, I updated the test scripts so that D-Bus testing can
be
run as part of the regular nightly testing, in each of the chroots where
tests are run. I triggered a test run, but network problems broke it
because the SyncEvolution sources couldn't be updated from gitorious.
Otherwise I would have been able now to point to
http://runtests.syncevolution.org and reports which contain D-Bus test
results.
This would be very nice to have. Much less chance it'd fall into such
disrepair if it were run along side the other tests every night.
Cheers,
Chris
2:14 p.m.
On Fri, 2011-07-01 at 23:28 +0200, Chris Kühl wrote:
On Fri, Jul 1, 2011 at 3:57 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Fri, 2011-07-01 at 12:24 +0200, Chris Kühl wrote:
> Another possible difference might be how the script gets invoked. I
> always run them in the out-of-tree build tree, inside "src". I run with
> PATH=.:$PATH <absolute path to source>/test/dbus-test.py
>
If I've cleaned my system-wide directories of the syncevolution files
I find that this doesn't work. I've got to additionally add the
environment variables for the template and xml files. For me
specifically it's...
SYNCEVOLUTION_XML_CONFIG_DIR=/home/chris/checkout/meego/syncevolution/src/syncevo/configs/
SYNCEVOLUTION_TEMPLATE_DIR=/home/chris/checkout/meego/syncevolution/src/templates/
PATH=.:$PATH /home/chris/checkout/meego/syncevolution/test/test-dbus.py
-v
My assumption was that syncevo-dbus-server is compiled and installed
properly. If you want to run without installing, then setting these env
variables is indeed necessary.
When compiling with modules (--enable-shared), then setting
SYNCEVOLUTION_BACKEND_DIR is also necessary.
> In related news, I updated the test scripts so that D-Bus
testing can be
> run as part of the regular nightly testing, in each of the chroots where
> tests are run. I triggered a test run, but network problems broke it
> because the SyncEvolution sources couldn't be updated from gitorious.
> Otherwise I would have been able now to point to
> http://runtests.syncevolution.org and reports which contain D-Bus test
> results.
>
This would be very nice to have. Much less chance it'd fall into such
disrepair if it were run along side the other tests every night.
Exactly.
--
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.
10:32 a.m.
Hello!
I found another dependency of the tests on the host setup: the default
backend had to have suitable databases configured. Test failures in the
nightly testing were the result. For example:
http://runtests.syncevolution.org/2011-07-03-21-30_all/head-lucid-i386/ni...
http://runtests.syncevolution.org/2011-07-03-21-30_all/head-lucid-i386/6-...
Instead of documenting this and changing the nightly test setup, I
removed this dependency. I also merged the patch for avoiding the
"test-dbus" name clash, albeit changed the name once more because I
preferred a different name. See master branch:
commit 3d461623d046293931578f79dc9eaf04fc6f81d3
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jul 4 17:18:58 2011 +0200
D-Bus testing: fixed wrong check in TestConnection.testStartSync
The test checked for zero status for inactive sources, whereas the
current implementation doesn't report anything for these sources at
all. Both is acceptable, but let's keep the test strict and check for
the current behavior.
commit be08788419c69abe7833919dd5084481c4c9b88c
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jul 4 17:10:41 2011 +0200
D-Bus testing: avoid dependency on default backend and its databases
TestConnection and TestSessionAPIsDummy used configs with
backend=addressbook/calendar/todo/memo which had to have databases
with a name derived from CLIENT_TEST_EVOLUTION_SOURCE and the source
name. This was neither documented nor did the required databases match
the ones used by the client-test programs anymore.
For the sake of making the test setup easier, this commit changes
these tests so that they use the file backend (always available) and
file://temp-test-dbus/<source name> databases (created if needed by
the backend). In other words, the tests now run without manual setup
of the host.
The downside is that D-Bus testing no longer covers the real
sources. That's okay, client-test covers that, whereas test-dbus.py
should focus on the D-Bus API itself.
commit 32c78d4d8138c04b755e6075725b126e62dea8c3
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jun 27 15:55:49 2011 +0200
D-Bus testing: use 'temp-test-dbus' as name of directory created for testing
'temp-test-dbus' is a bit more suitable than 'xdg-root' because
* it ties the directory to the script which creates it
* 'temp' implies that it holds no important data
* it is used for various files ('xdg_root' in the Python source
is a bit misleading)
commit 8933a5959596ccaa2cc02ff1ee9b6d62f4197673
Author: Chris Kühl <chrisk(a)openismus.com>
Date: Mon Jun 27 15:55:49 2011 +0200
test-dbus: Change default fr xdg_root
The default value of 'test-dbus' is the same name as the directory
holding the source files used for testing. In the DBusUtil.runTest the
xdg_root directory is removed. So, when running test-dbus-py from the
test directory it deletes the directory in which the source file
reside.
--
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.
3:03 p.m.
On Wed, 2011-06-29 at 15:58 -0700, Patrick Ohly wrote:
FAIL: a second session should not run unless the first one stops
AssertionError:
['session /org/syncevolution/Session/12604096081309383605 idle',
'session /org/syncevolution/Session/2552452311309383604 done'] !=
['session /org/syncevolution/Session/12604096081309383605 idle',
'session /org/syncevolution/Session/12604096081309383605 ready',
'session /org/syncevolution/Session/2552452311309383604 done']
"Ready" before "Done"? Might be harmless, need to check.
Seems to occur only when running all tests. A bit mysterious,
syncevo-dbus-server should be restarted for each test.
Perhaps this has something to do with the mock net.connman.Manager
implementation that some of the tests created on the D-Bus session bus.
I saw some "TypeError: 'NoneType' object is not iterable" errors caused
by it, because its GetProperties() method doesn't have a final "else"
clause and just returns without value. Will look further.
FAIL: Executes a real sync with no corresponding config.
AssertionError: dbus.UInt32(500L) != 10500
"No such config" should be a local error, not a remote one. Must be
fixed in syncevo-dbus-server.
commit cb9b7c3e2b3ac58aec4438019853207521a164f4
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jul 4 21:05:52 2011 +0200
error handling: recognize local errors again
Commit 3f1185, contained in 1.1.99.3, changed
SyncContext::throwError() so that it throws a StatusException with
STATUS_FATAL. Previously a runtime exception was thrown, which
Exception::handle() recorded as a local error.
This commit fixes that regression by throwing a STATUS_FATAL +
LOCAL_STATUS_CODE, which restores the traditional result of
throwError().
Found by test-dbus.py TestDBusSyncError.testSyncNoConfig.
FAIL: master must detect a hanging child
Sync succeeds although it shouldn't - timing changes?
commit 083984b1cf1e990f45dc05179f2e9bcd2ff47cda
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jul 4 21:25:23 2011 +0200
D-Bus testing: removed invalid TestLocalSync.testTimeout
Commit 1a40a29 (added after 1.1.99.4) removed timeouts in the local
transport, reasoning that such timeouts only make sense in unreliable
transports and only cause problems (like premature aborts).
Therefore the TestLocalSync.testTimeout which tested the old behavior
became invalid. Removed completely.
--
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.
2:40 a.m.
On Mon, Jul 4, 2011 at 10:03 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Wed, 2011-06-29 at 15:58 -0700, Patrick Ohly wrote:
> FAIL: a second session should not run unless the first one stops
> AssertionError:
> ['session /org/syncevolution/Session/12604096081309383605 idle',
> 'session /org/syncevolution/Session/2552452311309383604 done'] !=
> ['session /org/syncevolution/Session/12604096081309383605 idle',
> 'session /org/syncevolution/Session/12604096081309383605 ready',
> 'session /org/syncevolution/Session/2552452311309383604 done']
> "Ready" before "Done"? Might be harmless, need to check.
Seems to occur only when running all tests. A bit mysterious,
syncevo-dbus-server should be restarted for each test.
Perhaps this has something to do with the mock net.connman.Manager
implementation that some of the tests created on the D-Bus session bus.
I saw some "TypeError: 'NoneType' object is not iterable" errors
caused
by it, because its GetProperties() method doesn't have a final "else"
clause and just returns without value. Will look further.
> FAIL: Executes a real sync with no corresponding config.
> AssertionError: dbus.UInt32(500L) != 10500
> "No such config" should be a local error, not a remote one. Must be
> fixed in syncevo-dbus-server.
commit cb9b7c3e2b3ac58aec4438019853207521a164f4
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jul 4 21:05:52 2011 +0200
error handling: recognize local errors again
Commit 3f1185, contained in 1.1.99.3, changed
SyncContext::throwError() so that it throws a StatusException with
STATUS_FATAL. Previously a runtime exception was thrown, which
Exception::handle() recorded as a local error.
This commit fixes that regression by throwing a STATUS_FATAL +
LOCAL_STATUS_CODE, which restores the traditional result of
throwError().
Found by test-dbus.py TestDBusSyncError.testSyncNoConfig.
Ok, so this is the proper place to do this change. I was doing this in
the server on my branch. I've removed that commit now.
> FAIL: master must detect a hanging child
> Sync succeeds although it shouldn't - timing changes?
commit 083984b1cf1e990f45dc05179f2e9bcd2ff47cda
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Jul 4 21:25:23 2011 +0200
D-Bus testing: removed invalid TestLocalSync.testTimeout
Commit 1a40a29 (added after 1.1.99.4) removed timeouts in the local
transport, reasoning that such timeouts only make sense in unreliable
transports and only cause problems (like premature aborts).
Therefore the TestLocalSync.testTimeout which tested the old behavior
became invalid. Removed completely.
With these changes, I'm down to only one failure and errors associated
to the global property issue. Also, out of curiosity, I rebased me
dbus-server-reorganization branch onto master and ran the test. It
returns the exact same results as the master branch. So, everything
seems to be alright there thus far. Unfortunately, the "same results"
means that it also has the defaultPeer issue which I'm trying to find
a fix for.
Also, feel free to merge or cherry-pick any remaining commits from the
test-dbus branch at this point.
Cheers,
Chris
2:48 a.m.
On Tue, 2011-07-05 at 09:40 +0200, Chris Kühl wrote:
With these changes, I'm down to only one failure
The one about TestDBusSession.testSecondSession, right? I'm looking at
it now. As I suspected, the Connman class is to blame. The mock class
remains active and then messes with the mainloop, which confuses the
other test.
Unfortunately, the "same results"
means that it also has the defaultPeer issue which I'm trying to find
a fix for.
See my other mail about how defaultPeer should be stored (gdb back
traces, etc.).
Note that you can set
debugger = "gdb"
at the top of test-dbus.py to invoke an interactive debug session on
syncevo-dbus-server while running a single test.
--
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.
5:02 a.m.
On Tue, Jul 5, 2011 at 9:48 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Tue, 2011-07-05 at 09:40 +0200, Chris Kühl wrote:
> With these changes, I'm down to only one failure
The one about TestDBusSession.testSecondSession, right?
Correct.
I'm looking at
it now. As I suspected, the Connman class is to blame. The mock class
remains active and then messes with the mainloop, which confuses the
other test.
> Unfortunately, the "same results"
> means that it also has the defaultPeer issue which I'm trying to find
> a fix for.
See my other mail about how defaultPeer should be stored (gdb back
traces, etc.).
Note that you can set
debugger = "gdb"
at the top of test-dbus.py to invoke an interactive debug session on
syncevo-dbus-server while running a single test.
Yes, thanks. I'm aware of the debugger option. Working on it.
Cheers,
Chris
2:31 p.m.
On Tue, 2011-07-05 at 12:02 +0200, Chris Kühl wrote:
On Tue, Jul 5, 2011 at 9:48 AM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Tue, 2011-07-05 at 09:40 +0200, Chris Kühl wrote:
>> With these changes, I'm down to only one failure
>
> The one about TestDBusSession.testSecondSession, right?
Correct.
Fixed, I believe:
commit 5bcb6e4827f2ef6a594a67eeab6f337c4eb1fe26
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Tue Jul 5 20:59:34 2011 +0800
D-Bus testing: fixed TestSessionAPIsDummy.testCheckSourceInvalidType
The test was meant to check the error triggered by setting an
invalid backend value. Instead it checked the usability of such
a source and thus duplicated the (badly named) testCheckSourceNoType.
testCheckSourceInvalidType itself failed to pass when SyncEvolution
was compiled with modules, because then the "apple-contacts" backend
wasn't installed and SetConfig() failed with an unexpected error.
Now the test triggers that error in call cases with "backend =
no-such-backend"
and checks that the right error is reported.
--
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.
7:58 a.m.
On Tue, Jul 5, 2011 at 9:31 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Tue, 2011-07-05 at 12:02 +0200, Chris Kühl wrote:
> On Tue, Jul 5, 2011 at 9:48 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > On Tue, 2011-07-05 at 09:40 +0200, Chris Kühl wrote:
> >> With these changes, I'm down to only one failure
> >
> > The one about TestDBusSession.testSecondSession, right?
>
> Correct.
Fixed, I believe:
I can confirm. I've just got this pesky global property error left
now. Wondering if it might be better to trudge ahead with getting the
dbus-server-reorganization branch merged and come back to this issue
later.
Cheers,
Chris
8:23 a.m.
On Wed, 2011-07-06 at 14:58 +0200, Chris Kühl wrote:
I can confirm. I've just got this pesky global property error
left
now. Wondering if it might be better to trudge ahead with getting the
dbus-server-reorganization branch merged and come back to this issue
later.
I can't merge that branch before releasing 1.2, and I can't release 1.2
without fixing that global property error first.
I know that you want to continue with your real work. But the problem is
that I simply can't seem to reproduce it myself, so I need help by
someone who can.
Perhaps we can meet on chat and compare notes about interactive debugger
sessions?
--
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.
9:45 a.m.
On Wed, Jul 6, 2011 at 3:23 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Wed, 2011-07-06 at 14:58 +0200, Chris Kühl wrote:
> I can confirm. I've just got this pesky global property error left
> now. Wondering if it might be better to trudge ahead with getting the
> dbus-server-reorganization branch merged and come back to this issue
> later.
I can't merge that branch before releasing 1.2, and I can't release 1.2
without fixing that global property error first.
Ah, I see.
I know that you want to continue with your real work. But the problem
is
that I simply can't seem to reproduce it myself, so I need help by
someone who can.
Perhaps we can meet on chat and compare notes about interactive debugger
sessions?
Sure. Let's set up a time to do this. Tomorrow is fine with me... but
we can arrange this off-list.
Cheers,
Chris
3494
days inactive
3501
days old
syncevolution@synevolution.org
14 comments
2 participants
participants (2)
-
Chris Kühl -
Patrick Ohly