Fix some test fallout found on Linux/Sparc #1643
Conversation
DerDakon
force-pushed
the
sparc-fallout
branch
from
e622ebf
to
40a7e39
Compare
|
I don't understand the test error, looks unrelated to me. |
DerDakon
force-pushed
the
sparc-fallout
branch
from
61ee1ed
to
d848ad1
Compare
DerDakon
force-pushed
the
sparc-fallout
branch
2 times, most recently
from
ce7b212
to
996043d
Compare
Signed-off-by: Rolf Eike Beer <eike@sf-mail.de>
…nd configuration Signed-off-by: Rolf Eike Beer <eike@sf-mail.de>
|
Ping? |
| @@ -173,8 +173,10 @@ def test_rlimit(self): | |||
| self.assertEqual(hasattr(psutil.Process, "rlimit"), LINUX or FREEBSD) | |||
|
|
|||
| def test_io_counters(self): | |||
| not_on_linux = (LINUX and not os.path.exists('/proc/1/io')) | |||
There was a problem hiding this comment.
It's Linux, but the thing doesn't exist here. I'm open for any better name.
There was a problem hiding this comment.
I see. It's OK, let's let it fail.
There was a problem hiding this comment.
It will constantly fail e.g. on my sparc machine because this simply does not exist there, annoying me during the stabilizations for Gentoo because the testsuite is marked as failed.
There was a problem hiding this comment.
These tests are supposed to be "alarms" testing API availability depending on the OS. I prefer to have them failing.
There was a problem hiding this comment.
But the API is not generally available on Linux. That's all what I'm testing here: if these iocounters are available. Thinking about that this test could result in a false negative for the (unlikely) case that one has locked down /proc access more than usual, e.g. to not show processes of other users.
If you don't like this one just cherry-pick the first one.
There was a problem hiding this comment.
But the API is not generally available on Linux
It is generally available, at least on the majority of Linux i686 / x86 archs / distros I've seen. Most likely it's not available on Sparc, in which case I prefer to know with an explicit failure.
I understand it is annoying to see a failure on your specific arch / distro, but (in my mind) these tests checking API availability assume psutil is running on the most common arch / distro, not the "uncommon one", and are designed to (fail) be like this on purpose.
If you don't like this one just cherry-pick the first one.
Wouldn't know how to do that.
There was a problem hiding this comment.
This is a kernel configuration thing. We have even bug reports that this is failing on amd64 (and again).
This fixes most of the problems reported in #1635.