Summary: | dev-python/testify-0.2.8: fails tests if localhost resolves to IPv6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://tinderboxlogs.s3.amazonaws.com/tbamd64.excelsior.flameeyes.eu/dev-python%3Atestify-0.2.8%3A20121011-191922.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Diego Elio Pettenò (RETIRED)
![]() I'm going to make a call on this and say this isn't a valid instance of attempting to connect to the 'network'. Network
has the 3 types; local, internet and de-militarised zone or such. The error cited here is
<urlopen error [Errno 111] Connection refused>
The connection it's refusing afaict is
self.connect_addr = "localhost:%d" % portnum.
I persistently get
test.plugins.http_reporter_test HTTPReporterTestCase.test_http_reporter_tries_twice ... WARNING 409 POST
/results?runner=tries_twice (127.0.0.1) 0.46ms
WARNING 409 POST /results?runner=tries_twice (127.0.0.1) 0.46ms
ERROR Skipping returning results for test test.plugins.http_reporter_test DummyTestCase.test because of error: error
ok in 0.01s
which happily carries on yielding
PASSED. 65 tests / 33 cases: 65 passed, 0 failed. (Total test time 1.21s)
So;
1. the system that has this fail has something set that mine doesn't to abort on this test
2. The connection self.connect_addr = "localhost:%d" % portnum. as far as connecting to the 'network' is local and is frankly innocuous, imo.
I'm still curious what the setup is that sees this do a fail. Wondering if the network per se is shutdown in total when running tests.
dev-python/testify $ USE_PYTHON="2.7-pypy-1.9 2.6 2.7" ebuild testify-0.2.8.ebuild clean test install.
yields
* Generating '/usr/bin/testify' wrapper script
>>> Completed installing testify-0.2.8 into /mnt/gen2/TmpDir/portage/dev-python/testify-0.2.8/image/
pypy builds fine, fails 3 tests related to sqlite. Final judgement call, I preferred PYTHON_TESTS_FAILURES_TOLERANT_ABIS="2.7-pypy-1.9" but it appears to not work, leaving PYTHON_TESTS_RESTRICTED_ABIS="2.7-pypy-1.*"
So it's a slightly different problem, but RESOLVED FIXED it ain't! frankly I find the test plugging into localhost innocuous. I can at this point find only one to dismiss the illegality of a test that accesses the local network, and I seek a seconder. Skipping the key tests via unittest doesn't apply since it's a custom python test run outside of unittest. The 'error' in fact appears a misanomer. """A simple test to make sure the HTTPReporter actually reports things.""" HTTPReporter appears to be passing the test, by reporting things that get called errors. There is 1 remaining piece to this puzzle though. What is it in yr system that triggers this as an error and would otherwise die except that you appear to have test-fail-continue set in FEATURES. Twice you've put this forward as an error and still my system sees this test blink but sees it continue giving it a pass. An error really does appear a misanomer, IPv6 or ney "frankly I find the test plugging into localhost innocuous." Sure, if it could resolve localhost to the correct IP family it tries to use, but if it fails, it's fucked up. dev-python/testify $ USE_PYTHON="2.6 2.7" ebuild testify-0.2.8.ebuild clean test * Testing of dev-python/testify-0.2.8 with CPython 2.6... ............................................................... PASSED. 63 tests / 32 cases: 63 passed, 0 failed. (Total test time 1.18s) * Testing of dev-python/testify-0.2.8 with CPython 2.7... ............................................................... PASSED. 63 tests / 32 cases: 63 passed, 0 failed. (Total test time 3.17s) "Sure, if it could resolve localhost to the correct IP family it tries to use" yes. By unanimous concensus, the test had to go. Fixed in portage 29 Nov. |