Created attachment 528240 [details] python-3.4.8.log Reproduced on python-3.4.8, 3.5.5, and 3.6.5. ====================================================================== FAIL: test_fsize_ismax (test.test_resource.ResourceTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/dev-lang/python-3.4.8/work/Python-3.4.8/Lib/test/test_resource.py", line 31, in test_fsize_ismax self.assertEqual(resource.RLIM_INFINITY, max) AssertionError: 9223372036854775807 != -1 ---------------------------------------------------------------------- Ran 10 tests in 0.582s FAILED (failures=1) test test_resource failed 1 test failed again: test_resource
On alpha: Python 3.6.5 (default, Apr 22 2018, 18:05:17) [GCC 6.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import resource >>> resource.RLIM_INFINITY, (9223372036854775807,) >>> On amd64: Python 3.6.3 (default, Mar 19 2018, 14:16:48) [GCC 6.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import resource >>> resource.RLIM_INFINITY, (-1,) On ppc/ppc64: Python 3.6.5 (default, Apr 22 2018, 18:10:12) [GCC 7.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import resource >>> resource.RLIM_INFINITY -1
This was a regression in glibc-2.25 and I believe is fixed in 2.27.
Indeed updating to glibc-2.27 fixes that problem, and turns up another: 0:11:46 load avg: 5.74 [375/405/1] test_resource failed test test_resource failed -- Traceback (most recent call last): File "/var/tmp/portage/dev-lang/python-3.6.5/work/Python-3.6.5/Lib/test/support/__init__.py", line 555, in wrapper return func(*args, **kw) File "/var/tmp/portage/dev-lang/python-3.6.5/work/Python-3.6.5/Lib/test/test_resource.py", line 172, in test_prlimit_refcount self.assertEqual(resource.prlimit(0, resource.RLIMIT_AS, BadSeq()), PermissionError: [Errno 1] Operation not permitted Possible that it existed previously but the test bailed after the first failure.
Created attachment 813730 [details, diff] glibc patch to fix new failure
(In reply to matoro from comment #4) > Created attachment 813730 [details, diff] [details, diff] > glibc patch to fix new failure matoro: is this already upstreamed? if not could you please file a bug for glibc and attach it there?
(In reply to Andreas K. Hüttel from comment #5) > (In reply to matoro from comment #4) > > Created attachment 813730 [details, diff] [details, diff] [details, diff] > > glibc patch to fix new failure > > matoro: is this already upstreamed? if not could you please file a bug for > glibc and attach it there? We submitted it but aurel seems to indicate it was incorrect: https://sourceware.org/pipermail/libc-alpha/2022-October/142589.html At this point I'm not confident I did it correctly, but aurel seems to have no inclination to correct it. I'm also unsure if the fundamental objection to the behavior (breaking the expectation of getrlimit() returning some value x after a successful call to setrlimit(x)) is "blocking" or not. If you could poke in and revive the thread it might stimulate discussion again.
Can you file a bug as well upstream please?
Opened a bug https://sourceware.org/bugzilla/show_bug.cgi?id=30992
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=538db5c4dd47d9383cbeb8a3f23757a7477213d6 commit 538db5c4dd47d9383cbeb8a3f23757a7477213d6 Author: Matoro Mahri <matoro_gentoo@matoro.tk> AuthorDate: 2024-05-28 15:45:16 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-05-29 11:52:28 +0000 dev-lang/python: arch-specific test skips for alpha Bug: https://bugs.gentoo.org/931888 Bug: https://bugs.gentoo.org/653850 Signed-off-by: Matoro Mahri <matoro_gentoo@matoro.tk> Closes: https://github.com/gentoo/gentoo/pull/36875 Signed-off-by: Michał Górny <mgorny@gentoo.org> dev-lang/python/python-3.13.0_beta1_p3.ebuild | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
