With pure clone of https://github.com/python/cpython.git (no patches applied whatsoever, and the last commit is https://github.com/python/cpython/commit/650406fe7373f31b595b381d4f2f02065607386a) and pure

./configure && make -j2 && make -j2 test I get one failed test:

======================================================================
ERROR: test_linux_constants (test.test_resource.ResourceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/matej/Repos/cpython/Lib/test/test_resource.py", line 139, in test_linux_constants
    self.assertIsInstance(resource.RLIMIT_RTTIME, int)
AttributeError: 'module' object has no attribute 'RLIMIT_RTTIME'

----------------------------------------------------------------------
Ran 9 tests in 0.468s

FAILED (errors=1, skipped=1)
test test_resource failed
make: *** [test] Error 1

Christian, could you have a look? I think this was added in #19324.

What's the output of "uname -r" on your machine?

Patch with fix.

I'm checking the kernel version manually. requires_linux_version() works only per test. I don't want to write a test case for each attribute ...

Do we really need to test these constants in unit test?

Other constants such as RLIMIT_STACK, RLIMIT_DATA, etc are not being tested. Other consideration includes people built custom kernel without these constants, or maybe they have outdated glibc.

Additionally, it is very uncommon to use os.uname in unittest. Other than this test, it is only Lib/test/test_locale.py that uses os.uname.

Or if we really want to test these constants, we can use something like this:

if hasattr(resource, 'RLIMIT_NICE'):
    self.assertIsInstance(resource.RLIMIT_NICE, int)

Or if we want to be so strict:

if hasattr(resource, 'RLIMIT_NICE'):
    self.assertTrue(-20 <= resource.RLIMIT_NICE <= 19)

Reference:
http://man7.org/conf/lca2006/Linux_2.6_changes/rlimit_5.html

RLIMIT_NICE (2.6.12)

    Process nice value has range -20 (high) to +19 (low); influences kernel scheduler.

On 22/10/13 20:43, Christian Heimes wrote:
> Christian Heimes added the comment:
> 
> What's the output of "uname -r" on your machine?

2.6.32-358.23.2.el6.i686

This issue has been accidentally fixed by http://hg.python.org/cpython/rev/513da56d28de commit.

Time to close it? Any last words?

Since the test now passes I'm going to close this as fixed.