The regression still exists in mock 1.1.14, it fails exactly as before

TEST: sockettest
      ......................................   38  OK
PASS: sockettest

TEST: commandtest
      ..!!.!!!!!!!!!!!...                      19  FAIL
FAIL: commandtest

(In reply to comment #1)
> The regression still exists in mock 1.1.14, it fails exactly as before
> 
> TEST: sockettest
>       ......................................   38  OK
> PASS: sockettest
> 
> TEST: commandtest
>       ..!!.!!!!!!!!!!!...                      19  FAIL
> FAIL: commandtest

Can you turn on some debugging logic in the commandtest routine and see if we can get an idea why it's failing?

I get the following after adding the following lines just prior to "make check" in the specfile:

export VIR_TEST_VERBOSE=1
export LIBVIRT_LOG_OUTPUTS=3:stderr
export LIBVIRT_LOG_FILTERS="1:command"
export VIR_TEST_DEBUG=2

TEST: commandtest
 1) Command Exec test0 test                                           ... 22:55:24.762: 3468: info : libvirt vers
ion: 0.8.7, package: 18.el6.1 (Unknown, 2011-09-22-22:53:25, wolfy)
22:55:24.762: 3468: error : virCommandWait:1226 : internal error Child process exited with status 1.
22:55:24.762: 3468: info : libvirt version: 0.8.7, package: 18.el6.1 (Unknown, 2011-09-22-22:53:25, wolfy)
22:55:24.762: 3468: error : virCommandWait:1226 : internal error Child process exited with status 1.
OK
 2) Command Exec test1 test                                           ... OK
 3) Command Exec test2 test                                           ... FAILED
 4) Command Exec test3 test                                           ... FAILED
 5) Command Exec test4 test                                           ... OK
 6) Command Exec test5 test                                           ... FAILED
 7) Command Exec test6 test                                           ... FAILED
 8) Command Exec test7 test                                           ... FAILED
 9) Command Exec test8 test                                           ... FAILED
10) Command Exec test9 test                                           ... FAILED
11) Command Exec test10 test                                          ... FAILED
12) Command Exec test11 test                                          ... FAILED
13) Command Exec test12 test                                          ... FAILED
14) Command Exec test13 test                                          ... FAILED
15) Command Exec test14 test                                          ... FAILED
16) Command Exec test15 test                                          ... FAILED
17) Command Exec test16 test                                          ... OK
18) Command Exec test17 test                                          ... OK
19) Command Exec test18 test                                          ... OK
FAIL: commandtest

I am not sure how to generate a more verbose log. Please let me know if you need any other logs or instructions on how to retrieve any other useful info and I will be glad to help in debugging.
I can also upload all the logs if this helps.

W may need to get someone that knows the guts of libvirt, since I have no idea what is failing. 

We need to know why the child process started by test0 exited with a non-zero status. 

Oddly enough it looks like the test framework thinks test0 succeeded (printed Ok). And it also looks like you have five other tests that succeeded.

Just tried rebuilding the above libvirt version in my latest mock tree, but seeing the same result (commandtest failure). Really need someone that knows something about libvirt to give me a clue as to what's actually failing.

Probably not the solution per se .... but

Regarding the failure to build libvirt, this post addresses that:

http://www.redhat.com/archives/libvir-list/2011-July/msg00251.html

When I applied the referenced patch:

https://gitorious.org/~jfehlig/libvirt/libvirt-libxl/commit/f0e9dfeca967d05f23409c838619d9357d4f7d7f

building libvirt in mock-1.1.11 went through.

Manuel, 

Sounds like you need to cherry-pick the git commit from comment #6. 

Would you do so and confirm/deny that libvirt builds with the latest mock?

I will ASAP. Give me a day or two.

Thanks, no huge rush now that it's not a mock bug :)

I'm not sure if you can call this "not a mock bug" though. The fact is that earlier versions of mock did not have this issue.

By the way, I just tested with mock-1.1.16-1.el6. Building libvirt-0.8.7-18.el6_1.4 fails without the git commit and succeeds with it applied.

(In reply to comment #10)
> I'm not sure if you can call this "not a mock bug" though. The fact is that
> earlier versions of mock did not have this issue.
>

If your read the archive link above, you'll note the comment "recently changed to where a new process group is created by the builder". Mock did change to create a new process group for the chroot back when we were dealing with pty issues. So yeah, I call test failure, not mock bug.

then why not change to rhel-6 and libvirt?

(In reply to comment #12)
> then why not change to rhel-6 and libvirt?

I don't understand what you're asking.

if i understand correctly it's not a mock bug, but a libvirt's check bug. is it true?
if yes then please change this bug to libvirt (from mock) and rhel-6 (from epel-6).

I confirm that(In reply to comment #10)
> I'm not sure if you can call this "not a mock bug" though. The fact is that
> earlier versions of mock did not have this issue.

Well, I have mixed feelings about this. Just because a bug in an app did not manifest itself with a previous incarnation of mock does not mean that the application was not buggy.


> By the way, I just tested with mock-1.1.16-1.el6. Building
> libvirt-0.8.7-18.el6_1.4 fails without the git commit and succeeds with it
> applied.
I confirm this. Just did the same experiment but using mock-1.1.17 and obtained the same results. Compiles OK with the patch applied, fails in commandtest without the patch.

Almost certainly it's because when I cleaned up the PTY handling code I had to call os.setsid() which starts a new session and as a side effect creates a new process group. 

So I agree with Levente that this is a libvirt issue and not a mock issue. 

Changing the component to libvirt and OS to rhel-6

Per comment 6, libvirt has a spurious testsuite failure unless you backport commit f0e9dfeca; but this commit was added in upstream 0.9.0, therefore it is already present in the RHEL 6.2 build of libvirt.

Unless we need to backport this to RHEL 6.1.z, we can probably close this bug.

(In reply to comment #18)
> Per comment 6, libvirt has a spurious testsuite failure unless you backport
> commit f0e9dfeca; but this commit was added in upstream 0.9.0, therefore it is
> already present in the RHEL 6.2 build of libvirt.

Closing as CURRENTRELEASE.

imho 6.2 is not release and until then it can't be closed...

anyway in 6.2 beta libvirt requires sanlock-devel which is not exists...

(In reply to comment #20)
> imho 6.2 is not release and until then it can't be closed...

I agree.

> anyway in 6.2 beta libvirt requires sanlock-devel which is not exists...

Are you sure? I was able to install libvirt-0.9.4-12.el6.x86_64 and that did not require sanlock-devel. At any rate, sanlock-devel is in the optional-6-beta repository.