12:49 a.m.
http://bugs.meego.com/show_bug.cgi?id=5609
Summary: nightly testing: integrate syncevo-dbus-server testing
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: High
Component: SyncEvolution
AssignedTo: yongsheng.zhu(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
Yongsheng, you were involved in setting up testing of syncevo-dbus-server in
the nightly testing, right?
Can you finish the work done by Junhui by:
- merging the relevant code into the main syncevolution repository,
in test or test/dbus (whatever is more suitable)
- integrating it properly into the cron job
At the moment, the cron job executes ~nightly/nightly.sh, which looks like
this:
rm -fr /tmp/test/*; cd ~/dbus-testing && sh dbus-session.sh python
getResult_send.py > run.log 2>&1
cd ~/syncevolution-testing; runtests all >run.log 2>&1
Doesn't that use the *old* syncevolution from the previous night for D-Bus
testing? That looks wrong.
Another problem is that D-Bus testing should be skipped if the necessary
binaries didn't compile.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
noon
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #1 from yongsheng <yongsheng.zhu(a)intel.com> 2010-08-22 19:00:11 PDT ---
(In reply to comment #0)
Yongsheng, you were involved in setting up testing of
syncevo-dbus-server in
the nightly testing, right?
Can you finish the work done by Junhui by:
- merging the relevant code into the main syncevolution repository,
in test or test/dbus (whatever is more suitable)
- integrating it properly into the cron job
I'll have a look.
At the moment, the cron job executes ~nightly/nightly.sh, which looks
like
this:
rm -fr /tmp/test/*; cd ~/dbus-testing && sh dbus-session.sh python
getResult_send.py > run.log 2>&1
cd ~/syncevolution-testing; runtests all >run.log 2>&1
Doesn't that use the *old* syncevolution from the previous night for D-Bus
testing? That looks wrong.
why? I think both 'dbus-testing' and
'syncevolution-testing' pull the latest
code from gitorious.org before running.
Another problem is that D-Bus testing should be skipped if the
necessary
binaries didn't compile.
yes, it's reasonable to do this kind of
checking.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:05 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #2 from pohly <patrick.ohly(a)intel.com> 2010-08-23 00:05:11 PDT ---
(In reply to comment #1)
(In reply to comment #0)
> Doesn't that use the *old* syncevolution from the previous night for D-Bus
> testing? That looks wrong.
why? I think both 'dbus-testing' and 'syncevolution-testing' pull the
latest
code from gitorious.org before running.
Does 'dbus-testing' really compile its own binaries? That's unnecessary. In
order to test what we ship, it should test with the Ubuntu Hardy binaries.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:55 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|yongsheng.zhu(a)intel.com |qiankun.miao(a)intel.com
--- Comment #3 from pohly <patrick.ohly(a)intel.com> 2010-08-24 04:55:12 PDT ---
I believe Qiankun took over this task.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
3:09 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #4 from qkmiao <qiankun.miao(a)intel.com> 2010-09-08 22:09:04 PDT ---
Dbus-testing has been merged into nightly. The source code has been in
syncevolution/test now.
Configurations are separated from testing by adding some command line options.
'Dbus-testing' will use the same syncevolution source code with
'syncevolution-testing', but compile its own binary using different compile
flags against 'syncevolution-testing'. 'Dbus-testing' will be skipped if
the
binary was not compiled successfully.
(In reply to comment #3)
I believe Qiankun took over this task.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
7:37 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #5 from pohly <patrick.ohly(a)intel.com> 2010-09-09 02:37:04 PDT ---
(In reply to comment #4)
Dbus-testing has been merged into nightly. The source code has been
in
syncevolution/test now.
That much I see in the "dbus-testing" branch. There's now a new
test/getResult_send.py script. Please, pick a better name. It is not at all
obvious from the name which results are meant, and the comment at the top of
the file adds no additional information either ("get the results and send
them"). Such comments are totally redundant.
But where is the documentation on how to integrate this script with the
"runtest.py" invocation? What assumptions are made about the work environment?
How does it relate to test-dbus.py?
For example, showTestCases() opens a testCaseNames.txt in the work path. Does
that mean that defining the work path is mandatory? Where does that file come
from?
There are some example invocations, but they seem to be incomplete.
Configurations are separated from testing by adding some command line
options.
'Dbus-testing' will use the same syncevolution source code with
'syncevolution-testing', but compile its own binary using different compile
flags against 'syncevolution-testing'. 'Dbus-testing' will be skipped if
the
binary was not compiled successfully.
Sorry, I don't understand how this is meant to work. What I expect to happen is
this:
- runtest.py is used to compile binaries
- if the binaries were compiled successfully,
also run test-dbus.py using them and send out the results
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
7:45 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
yongsheng <yongsheng.zhu(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |yongsheng.zhu(a)intel.com
--- Comment #6 from yongsheng <yongsheng.zhu(a)intel.com> 2010-09-09 02:45:05 PDT ---
Sorry, I don't understand how this is meant to work. What I
expect to happen is
this:
- runtest.py is used to compile binaries
- if the binaries were compiled successfully,
I think it's not so needed since
they use different configure options. To
simple, I like to leave it as current status.
also run test-dbus.py using them and send out the results
dbus-server uses gnome-keyring. dbus daemon pops up a dialog to input password
to access keyring in usual. We don't find a good method to solve it in chroot
environment. I suggest just testing it in current environment.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:24 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #7 from pohly <patrick.ohly(a)intel.com> 2010-09-09 04:24:20 PDT ---
(In reply to comment #6)
> Sorry, I don't understand how this is meant to work. What I
expect to happen is
> this:
> - runtest.py is used to compile binaries
> - if the binaries were compiled successfully,
I think it's not so needed since they use different configure options. To
simple, I like to leave it as current status.
I disagree. I want the testing to cover the bits and bytes that we ship, not
something else, *in particular* if it gets compiled with different configure
options. Different options always come with the risk of hiding bugs that occur
with the ones used for release.
> also run test-dbus.py using them and send out the results
dbus-server uses gnome-keyring. dbus daemon pops up a dialog to input password
to access keyring in usual. We don't find a good method to solve it in chroot
environment. I suggest just testing it in current environment.
What do you mean? Don't test as part of the nightly testing?
Regarding the keyring, how about this: make the usage of the keyring
configurable via ~/.config/syncevolution/config.ini (similar to the "current
config" setting), turn the "--keyring" parameter into an alias for this
property (similar to "--sync"). Then turn off the keyring in the chroot.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
10:09 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #8 from pohly <patrick.ohly(a)intel.com> 2010-09-09 05:09:23 PDT ---
(In reply to comment #7)
Regarding the keyring, how about this: make the usage of the keyring
configurable via ~/.config/syncevolution/config.ini (similar to the "current
config" setting), turn the "--keyring" parameter into an alias for this
property (similar to "--sync"). Then turn off the keyring in the chroot.
See also bug #6368 "--keyring does not work".
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:15 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #9 from yongsheng <yongsheng.zhu(a)intel.com> 2010-09-09 06:15:14 PDT ---
Regarding the keyring, how about this: make the usage of the keyring
configurable via ~/.config/syncevolution/config.ini (similar to the "current
config" setting), turn the "--keyring" parameter into an alias for this
property (similar to "--sync"). Then turn off the keyring in the chroot.
I don't understand you.It's not for syncevoution but for
syncevo-dbus-server.
If syncevo-dbus-server is compiled with keyring, then we can't disable it.
then keyring daemon needs password and pops up a dialog at the first time
syncevo-dbus-server accesses it.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:56 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #10 from pohly <patrick.ohly(a)intel.com> 2010-09-09 06:56:04 PDT ---
(In reply to comment #9)
> Regarding the keyring, how about this: make the usage of the
keyring
> configurable via ~/.config/syncevolution/config.ini (similar to the "current
> config" setting), turn the "--keyring" parameter into an alias for
this
> property (similar to "--sync"). Then turn off the keyring in the chroot.
I don't understand you.It's not for syncevoution but for syncevo-dbus-server.
If syncevo-dbus-server is compiled with keyring, then we can't disable it.
Of course we can disable it at runtime. Just don't call any of the functions,
depending on some "if()" check.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12:05 a.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #11 from pohly <patrick.ohly(a)intel.com> 2010-09-09 07:05:24 PDT ---
(In reply to comment #10)
(In reply to comment #9)
> > Regarding the keyring, how about this: make the usage of the keyring
> > configurable via ~/.config/syncevolution/config.ini (similar to the
"current
> > config" setting), turn the "--keyring" parameter into an alias
for this
> > property (similar to "--sync"). Then turn off the keyring in the
chroot.
>
> I don't understand you.It's not for syncevoution but for
syncevo-dbus-server.
> If syncevo-dbus-server is compiled with keyring, then we can't disable it.
Of course we can disable it at runtime. Just don't call any of the functions,
depending on some "if()" check.
If you mean "we can't disable it because there is no --keyring parameter",
then
you are right. That's why I suggested adding a new global property, which is
always available.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:07 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #12 from qkmiao <qiankun.miao(a)intel.com> 2010-09-16 00:07:23 PDT ---
Updated dbus-testing branch.
(In reply to comment #7)
I disagree. I want the testing to cover the bits and bytes that we
ship, not
something else, *in particular* if it gets compiled with different configure
options. Different options always come with the risk of hiding bugs that occur
with the ones used for release.
We don't need to get source code and compile it for dbus-testing, just use the
same as client-testing. Right? By now, dbus-testing and client-testing scripts
have some differences in build path, install path, result path. Do we need to
align dbus-testing with client-testing?
Another approach is that we can build client-testing and dbus-testing
separately with the same configure options.
Regarding the keyring, how about this: make the usage of the keyring
configurable via ~/.config/syncevolution/config.ini (similar to the "current
config" setting), turn the "--keyring" parameter into an alias for this
property (similar to "--sync"). Then turn off the keyring in the chroot.
A new property "GnomeKeyring" has been added to enable or disable gnomekeyring
at runtime. Help to review code in dbus-testing branch.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:10 p.m.
New subject: [Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #13 from pohly <patrick.ohly(a)intel.com> 2010-09-16 01:10:27 PDT ---
(In reply to comment #12)
Updated dbus-testing branch.
(In reply to comment #7)
> I disagree. I want the testing to cover the bits and bytes that we ship, not
> something else, *in particular* if it gets compiled with different configure
> options. Different options always come with the risk of hiding bugs that occur
> with the ones used for release.
We don't need to get source code and compile it for dbus-testing, just use the
same as client-testing. Right?
Yes, but more precisely, dbus-testing should use the binaries built as part of
the head-evolution-hardy-2.22.1-amd64/ia32 environments, because those are the
binaries that we release.
By now, dbus-testing and client-testing scripts
have some differences in build path, install path, result path. Do we need to
align dbus-testing with client-testing?
Yes.
Another approach is that we can build client-testing and
dbus-testing
separately with the same configure options.
That would just duplicate the work of compiling the source code. It also does
not catch the (unlikely) situation of a cosmic ray toggling a bit in the
binaries that we release, breaking the syncevo-dbus-server in that release.
> Regarding the keyring, how about this: make the usage of the
keyring
> configurable via ~/.config/syncevolution/config.ini (similar to the "current
> config" setting), turn the "--keyring" parameter into an alias for
this
> property (similar to "--sync"). Then turn off the keyring in the chroot.
A new property "GnomeKeyring" has been added to enable or disable gnomekeyring
at runtime. Help to review code in dbus-testing branch.
Let's not make this specific to GNOME. We might have a similar situation with
KDE Wallet soon. Here's what I would like to see implemented:
property name: "keyring"
sharing: setSharing(ConfigProperty::GLOBAL_SHARING), just like "default peer"
value: several options: yes/on/1, no/off/0, GNOME (case insensitive)
command line: --keyring[=xxx] as alias for --sync-property keyring=xxx (like
--sync, with --keyring equal to --sync-property keyring=on)
default for keyring=yes: GNOME, can be made more intelligent later on
Check that "client-test SyncEvolution" (configure --enable-integration-tests)
still works. It tests configuration layout pretty thoroughly.
Also, please split your patch into independent pieces. One patch should add the
new property and have BMC #6368 in the summary, the other the changes for D-Bus
testing with BMC #5609.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:21 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #14 from pohly <patrick.ohly(a)intel.com> 2010-10-14 03:21:34 PDT ---
From bug #7761 comment #3:
(In reply to comment #2)
patrick, this fix makes one case of test-dbus failed. you can find it
in the
nightly report.
Which one? This here?
FAIL: check the Server.GetCapabilities() call
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/nightly/syncevolution-testing/syncevolution/test/test-dbus.py",
line 557, in testCapabilities
self.failUnlessEqual(capabilities, ['ConfigChanged', 'GetConfigName',
'Notifications', 'SessionFlags', 'Version'])
AssertionError: dbus.Array([dbus.String(u'ConfigChanged'),
dbus.String(u'GetConfigName'), dbus.String(u'Notifications'),
dbus.String(u'SessionAttach'), dbus.String(u'SessionFlags'),
dbus.String(u'Version')], signature=dbus.Signature('s')) !=
['ConfigChanged',
'GetConfigName', 'Notifications', 'SessionFlags',
'Version']
The test-dbus.py script seems to be out-dated:
http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/te...
self.failUnlessEqual(capabilities, ['ConfigChanged', 'GetConfigName',
'Notifications', 'SessionAttach', 'SessionFlags',
'Version'])
How can this happen? Isn't the nightly testing using the version of
test-dbus.py from the checkout that it is testing?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:43 a.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #15 from qkmiao <qiankun.miao(a)intel.com> 2010-10-14 07:43:04 PDT ---
(In reply to comment #14)
From bug #7761 comment #3:
(In reply to comment #2)
> patrick, this fix makes one case of test-dbus failed. you can find it in the
> nightly report.
Which one? This here?
FAIL: check the Server.GetCapabilities() call
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/nightly/syncevolution-testing/syncevolution/test/test-dbus.py",
line 557, in testCapabilities
self.failUnlessEqual(capabilities, ['ConfigChanged',
'GetConfigName',
'Notifications', 'SessionFlags', 'Version'])
AssertionError: dbus.Array([dbus.String(u'ConfigChanged'),
dbus.String(u'GetConfigName'), dbus.String(u'Notifications'),
dbus.String(u'SessionAttach'), dbus.String(u'SessionFlags'),
dbus.String(u'Version')], signature=dbus.Signature('s')) !=
['ConfigChanged',
'GetConfigName', 'Notifications', 'SessionFlags',
'Version']
The test-dbus.py script seems to be out-dated:
http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/te...
self.failUnlessEqual(capabilities, ['ConfigChanged', 'GetConfigName',
'Notifications', 'SessionAttach', 'SessionFlags',
'Version'])
How can this happen? Isn't the nightly testing using the version of
test-dbus.py from the checkout that it is testing?
I checked the nightly testing script. test-dbus.py was not the latest code. It
was got from /home/nightly/syncevolution-testing/syncevolution/test. I am not
very clear about the history why sub-directory "syncevolution" used in
/home/nightly/syncevolution-testing. I will fix this.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:11 a.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #16 from pohly <patrick.ohly(a)intel.com> 2011-01-19 06:11:22 PST ---
(In reply to comment #15)
> The test-dbus.py script seems to be out-dated:
>
http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/te...
>
> self.failUnlessEqual(capabilities, ['ConfigChanged',
'GetConfigName',
> 'Notifications', 'SessionAttach', 'SessionFlags',
'Version'])
>
> How can this happen? Isn't the nightly testing using the version of
> test-dbus.py from the checkout that it is testing?
I checked the nightly testing script. test-dbus.py was not the latest code. It
was got from /home/nightly/syncevolution-testing/syncevolution/test. I am not
very clear about the history why sub-directory "syncevolution" used in
/home/nightly/syncevolution-testing. I will fix this.
This issue came up again: test-dbus.py on "master" is working, the one used in
the nightly testing is not. To answer the question:
/home/nightly/syncevolution-testing/syncevolution is used to boot-strap testing
when no /work/runtests exists.
As many of the actual tests scripts then should come from the checked-out
sources in /work/runtests, in particular test-dbus.py.
Do you still intend to fix this issue?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4:43 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #17 from qkmiao <qiankun.miao(a)intel.com> 2011-01-19 21:43:07 PST ---
(In reply to comment #16)
This issue came up again: test-dbus.py on "master" is
working, the one used in
the nightly testing is not. To answer the question:
/home/nightly/syncevolution-testing/syncevolution is used to boot-strap testing
when no /work/runtests exists.
As many of the actual tests scripts then should come from the checked-out
sources in /work/runtests, in particular test-dbus.py.
Do you still intend to fix this issue?
This issue has been fixed. Let's check tomorrow's nightly test results. I just
did a test, and there are still 5 test cases failed with test-dbus.py on
"master".
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:22 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #18 from pohly <patrick.ohly(a)intel.com> 2011-01-19 23:22:33 PST ---
(In reply to comment #17)
(In reply to comment #16)
> This issue came up again: test-dbus.py on "master" is working, the one
used in
> the nightly testing is not. To answer the question:
> /home/nightly/syncevolution-testing/syncevolution is used to boot-strap testing
> when no /work/runtests exists.
>
> As many of the actual tests scripts then should come from the checked-out
> sources in /work/runtests, in particular test-dbus.py.
>
> Do you still intend to fix this issue?
This issue has been fixed.
How? Manually updating the /home/nightly/syncevolution-testing/syncevolution
solves it once, but is not the right long-term solution.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:31 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #19 from qkmiao <qiankun.miao(a)intel.com> 2011-01-19 23:31:06 PST ---
(In reply to comment #18)
How? Manually updating the
/home/nightly/syncevolution-testing/syncevolution
solves it once, but is not the right long-term solution.
Fixed in the script(/home/nightly/syncevolution-testing/getResult_send.py)
which invokes test-dbus.py.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:12 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #20 from pohly <patrick.ohly(a)intel.com> 2011-01-20 01:12:38 PST ---
(In reply to comment #19)
(In reply to comment #18)
> How? Manually updating the /home/nightly/syncevolution-testing/syncevolution
> solves it once, but is not the right long-term solution.
Fixed in the script(/home/nightly/syncevolution-testing/getResult_send.py)
which invokes test-dbus.py.
Okay.
So what about integrating the D-Bus testing such that it uses the precompiled
binaries? Is that still open?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:23 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #21 from qkmiao <qiankun.miao(a)intel.com> 2011-01-20 01:23:36 PST ---
(In reply to comment #20)
So what about integrating the D-Bus testing such that it uses the
precompiled
binaries? Is that still open?
Yes, this problem is still open. I will be free to do this after Chinese New
Year holiday (after Feb. 8).
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
10:57 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #22 from pohly <patrick.ohly(a)intel.com> 2011-01-21 03:57:34 PST ---
How is the "dbus_unittest" configuration for the TestSessionAPIsReal tests
created?
Due to the changes in the on-disk format, this configuration must be explicitly
converted:
http://mob-sync2.sh.intel.com/dbus_results/20110121/test-dbus-log/TestSes...
[ERROR] error code from SyncEvolution local, status 22005: Proceeding would
modify config 'dbus_unittest' such that the previous SyncEvolution release will
not be able to use it. Stopping now. Please explicitly acknowledge this step by
running the following command on the command line: syncevolution --migrate
'dbus_unittest'
Can this be changed such that the configuration is created anew with the
current SyncEvolution version each time the D-Bus runs start?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:17 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #23 from qkmiao <qiankun.miao(a)intel.com> 2011-01-23 22:17:42 PST ---
(In reply to comment #22)
How is the "dbus_unittest" configuration for the
TestSessionAPIsReal tests
created?
This configuration is created by user before running dbus-testing.
Due to the changes in the on-disk format, this configuration must be
explicitly
converted:
http://mob-sync2.sh.intel.com/dbus_results/20110121/test-dbus-log/TestSes...
[ERROR] error code from SyncEvolution local, status 22005: Proceeding would
modify config 'dbus_unittest' such that the previous SyncEvolution release will
not be able to use it. Stopping now. Please explicitly acknowledge this step by
running the following command on the command line: syncevolution --migrate
'dbus_unittest'
By running: syncevolution --migrate 'dbus_unittest', this failure has
been
fixed.
Can this be changed such that the configuration is created anew with
the
current SyncEvolution version each time the D-Bus runs start?
We can use
SetConfig() to set configuration for each testcase. I not very clear
about creating with the current SyncEvolution version. How can we get the
current correct configuration?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:56 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #24 from pohly <patrick.ohly(a)intel.com> 2011-01-23 22:56:31 PST ---
(In reply to comment #23)
> Can this be changed such that the configuration is created anew
with the
> current SyncEvolution version each time the D-Bus runs start?
We can use SetConfig() to set configuration for each testcase. I not very clear
about creating with the current SyncEvolution version. How can we get the
current correct configuration?
This could be done with the "setup-evolution" script in the nightly test setup.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
3:47 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #25 from qkmiao <qiankun.miao(a)intel.com> 2011-01-24 20:47:25 PST ---
(In reply to comment #24)
This could be done with the "setup-evolution" script in the
nightly test setup.
Is this script in syncevolution-testing : "setup-syncevolution.sh"?
I have some questions about this script.
Does this script change with SyncEvolution update? How is this script created?
This script is used to setup client-test configuration and is not about
dbus_unittest configuration. How can we use this script to get configuration
for dbus-testing? Patrick, Could you provide some detail about creating
configuration each time dbus-testing starts?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:22 p.m.
New subject: [MeeGo Projects - Bug 5609] nightly testing: integrate syncevo-dbus-server testing
http://bugs.meego.com/show_bug.cgi?id=5609
--- Comment #26 from pohly <patrick.ohly(a)intel.com> 2011-01-24 23:22:07 PST ---
(In reply to comment #25)
(In reply to comment #24)
> This could be done with the "setup-evolution" script in the nightly test
setup.
Is this script in syncevolution-testing : "setup-syncevolution.sh"?
Yes.
I have some questions about this script.
Does this script change with SyncEvolution update? How is this script created?
This script is maintained manually and typically does not change. It contains
the credentials and per server/host configuration options. Because of that
confidential information it cannot be in the public SyncEvolution repo.
This script is used to setup client-test configuration and is not
about
dbus_unittest configuration. How can we use this script to get configuration
for dbus-testing? Patrick, Could you provide some detail about creating
configuration each time dbus-testing starts?
You could add "dbus_testing" as an alternative name for some existing server:
memotoo*|dbus_testing) ...
Then further down, in addition to creating two configs for client-test (for
client in 1 2; do ...), also create the $TEST config for the D-Bus tests.
To use this modified script, invoke it before running test-dbus.py.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4254
days inactive
4412
days old
syncevolution-issues@syncevolution.org
26 comments
1 participants
participants (1)
-
bugzilla＠meego.com