Summary: | dev-libs/libevent-2.0.10 fails tests (regress: [Timed out] dns/gethostbyname6) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paweł Hajdan, Jr. (RETIRED) <phajdan.jr> |
Component: | [OLD] Library | Assignee: | Jeroen Roovers (RETIRED) <jer> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jeremy.william.murphy |
Priority: | Normal | Keywords: | TESTFAILURE |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Paweł Hajdan, Jr. (RETIRED)
2011-06-24 10:32:47 UTC
2.0.14 fails on EPOLL but passes EPOLL (changelist), however 2.0.15 does not fail at all. Recommend expedited stabling of 2.0.15? (In reply to comment #1) > 2.0.14 fails on EPOLL but passes EPOLL (changelist), however 2.0.15 does not > fail at all. How many times did you try? > Recommend expedited stabling of 2.0.15? No. The test suite simply fails whereas *lots* of software developers seem to think the library itself is pretty decent. Since it fails for you people, could you try if this patch works? After all, if the only way it dies is because someone (my predecessor) put the code in that makes it die(), then why don't we get rid of it? Index: libevent-2.0.15.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/dev-libs/libevent/libevent-2.0.15.ebuild,v retrieving revision 1.2 diff -u -B -r1.2 libevent-2.0.15.ebuild --- libevent-2.0.15.ebuild 12 Oct 2011 16:49:44 -0000 1.2 +++ libevent-2.0.15.ebuild 19 Oct 2011 17:11:25 -0000 @@ -40,7 +40,6 @@ src_test() { emake -C test check | tee "${T}"/tests - grep FAILED "${T}"/tests &>/dev/null && die "1 or more tests failed" } src_install() { (In reply to comment #2) > (In reply to comment #1) > > 2.0.14 fails on EPOLL but passes EPOLL (changelist), however 2.0.15 does not > > fail at all. > > How many times did you try? Whaaaaat? If you're suggesting that this test does not fail reliably (which is quite possible), then surely the test is broken? If the test depends on something unreliable like a network connection, then surely it should retry several times inside the test? > > Recommend expedited stabling of 2.0.15? > > No. The test suite simply fails whereas *lots* of software developers seem to > think the library itself is pretty decent. If the test itself is broken, then sure, let's get rid of it. But should we tell upstream too? Removed the FAILED check so that the test suite outcome is non-fatal. |