On Thu, 2012-03-15 at 09:30 +0100, Krzesimir Nowak wrote:
2012/3/15 Chris Kühl <blixtra(a)gmail.com>:
> On Wed, Mar 14, 2012 at 11:28 AM, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
>> On Thu, 2012-03-08 at 17:18 +0100, Chris Kühl wrote:
>>> It's been rebased and we've squashed the changes into about a dozen
>>> commits. The tests seem to give us the same results as before the
>>> rebase.
>>
>> And those are? In other words, which tests are known to fail, and why?
>>
>
> I've pushed a branch called css-without-known-test-failures[1] whose
> most recent commit comments out all the tests in test/test-dbus.py
> that fail. However, there as a bug I introduced during the last
> rebase. The fix for that can be found here[2].
>
> All but one of the failures is due to the incomplete AutoSync and
> Connection functionality. The restart test has never worked for us on
> any branch.
That test should work without problems if you run test-dbus.py while
being in the same directory as syncevo-dbus-server binary. That is
because execve's first parameter should be a path (relative or
absolute) to binary and in case of test-dbus.py only
'syncevo-dbus-server' is passed here. It is not absolute path and thus
execlv looks for binary in current running directory only. Seems like
execve does not look for binary in PATH environment variable.
In other words, the initial start of syncevo-dbus-server (via PATH)
works, but restarting it fails (because PATH is not used and the argv[0]
is not found)?
I see how that can happen. The way I run the tests avoids that problem.
It shouldn't be a problem in the main usage of the restart feature
either: when syncevo-dbus-server is activated via D-Bus, it should see a
full path in argv[0].
--
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.