| Summary: | media-sound/xmms2-0.8-r1: fails to build (when installed valgrind is not working) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Sergei Trofimovich (RETIRED) <slyfox> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://tinderboxlogs.s3.amazonaws.com/tbamd64.excelsior.flameeyes.eu/media-sound%3Axmms2-0.8-r1%3A20120630-225305.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Diego Elio Pettenò (RETIRED)
2012-07-01 12:52:49 UTC
No, it's a build failure: * ebuild.sh, line 85: Called src_compile * environment, line 4949: Called die > But the FSM knows the reason, I can't make it out clearly from the parallel scons log... It's a waf build system which does not use waf-utils.eclass yet (will be on next revbump). As a result the build log is sequential. (In reply to comment #1) > No, it's a build failure: > > > * ebuild.sh, line 85: Called src_compile > * environment, line 4949: Called die ok :] Upstream runs tests right in the build phase. I haven't wrote anything sane to optionally factor out tests into a separate phase yet. > [214/214] utest: _build_/tests/test_server > [214/214] utest: _build_/tests/test_xmmstypes > Waf: Leaving directory `.../_build_' > test summary > Test(s) failed: > .../_build_/tests/test_server > .../_build_/tests/test_xmmstypes For some reason test binaries failed to run properly and returned nonzero status: > def summary(bld): > lst = getattr(bld, 'utest_results', []) > if lst: > Logs.pprint('CYAN', 'test summary') > > failed_tests = [] > > for (f, code, out, err) in lst: > if code != 0: > failed_tests.append(f) > Logs.pprint('NORMAL', out.decode("ascii", "ignore")) > > if len(failed_tests) > 0: > raise Errors.WafError("Test(s) failed:\n%s" % "\n".join(failed_tests)) The error does not trigger for me on stock ~amd64. For you it does not even show CUnit banner, which is weird. Can you try to run it manually with and without valgrind? at ${S}: _build_/tests/test_server; echo $? valgrind --log-file=/dev/null _build_/tests/test_server; echo $? Maybe it will spit something readable. I guess it's a hardened bit. > The error does not trigger for me on stock ~amd64.
> For you it does not even show CUnit banner, which is weird.
Gah, got it crashng after sqlite update. Sorry.
Looking at it.
(In reply to comment #3) > > The error does not trigger for me on stock ~amd64. > > For you it does not even show CUnit banner, which is weird. > > Gah, got it crashng after sqlite update. Sorry. > Looking at it. Or not: _build_/tests/test_xmmstypes.log: > valgrind: Fatal error at startup: a function redirection > valgrind: which is mandatory for this platform-tool combination > valgrind: cannot be set up. Details of the redirection are: > valgrind: > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: strlen > valgrind: in an object with soname matching: ld-linux-x86-64.so.2 Bet, you have the same contents. Pushed test failures to src_test() with the following:
> 01 Jul 2012; Sergei Trofimovich <slyfox@gentoo.org> xmms2-0.8-r1.ebuild:
> Workaround build failure when test failure occurs. Rerun tests in src_test().
> It moves valgrind misconfiguration error to src_test() phase (bug #424377 by
> Diego Elio Pettenò).
Wait, the tests depend on valgrind? That's wrong. Can they be run without valgrind or do they really expect it to work? If the former, simply disable valgrind by default, if the latter add REQUIRED_USE="test? ( valgrind )" and a DEPEND="valgrind? ( dev-util/valgrind )" so I know I can't run test for the package. The problem with valgrind is that it doesn't always support the latest greatest microarchitecture -- in this case it won't work at all on my interlagos/bulldozer CPU. (In reply to comment #6) > Wait, the tests depend on valgrind? That's wrong. Can they be run without > valgrind or do they really expect it to work? If the former, simply disable > valgrind by default, if the latter add REQUIRED_USE="test? ( valgrind )" and > a DEPEND="valgrind? ( dev-util/valgrind )" so I know I can't run test for > the package. > > The problem with valgrind is that it doesn't always support the latest > greatest microarchitecture -- in this case it won't work at all on my > interlagos/bulldozer CPU. valgrind's part of test is optional. I'll try to make it USE=valgrind guarded. Added USE=valgrind to de-automaigic this valgrind dependency: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7133a4cc49d1299e0a90ebf19ea6d2a92ed6f8b5 Thanks! *** Bug 442460 has been marked as a duplicate of this bug. *** |