| Summary: | regression introduced in mock after version 1.1.8 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | manuel wolfshant <manuel.wolfshant> |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.1 | CC: | acathrow, dallan, jcpunk, lfarkas, mebrown, pasteur, toracat, williams |
| Target Milestone: | rc | ||
| Target Release: | 6.1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-11-11 22:14:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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. |
Description of problem: libvirt-0.8.7-18.el6.src.rpm cannot be built due to a failing test Version-Release number of selected component (if applicable): mock-1.1.10 and newer How reproducible: always Steps to Reproduce: 1. mock -r epel-6-x86_64 libvirt-0.8.7-18.el6.src.rpm Actual results: Build fails, build.log reveals: TEST: commandtest ................... 19 FAIL FAIL: commandtest Expected results: TEST: commandtest ................... 19 OK PASS: commandtest Additional info: Problem was seen while recompiling libvirt to add xen support. mock-1.1.8 works; I have not tested mock-1.1.9