SliTaz Repositories

     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/python/stuff/patches/13a39142c047.diff	Sat Nov 21 14:32:44 2020 +0100
     1.3 @@ -0,0 +1,72 @@
     1.4 +Error in the end of the `make install`:
     1.5 +
     1.6 +```
     1.7 +Traceback (most recent call last):
     1.8 +  File "${src}/Lib/runpy.py", line 163, in _run_module_as_main
     1.9 +    mod_name, _Error)
    1.10 +  File "${src}/Lib/runpy.py", line 111, in _get_module_details
    1.11 +    __import__(mod_name)  # Do not catch exceptions initializing package
    1.12 +  File "${src}/Lib/ensurepip/__init__.py", line 9, in <module>
    1.13 +    import tempfile
    1.14 +  File "${src}/Lib/tempfile.py", line 35, in <module>
    1.15 +    from random import Random as _Random
    1.16 +  File "${src}/Lib/random.py", line 885, in <module>
    1.17 +    _inst = Random()
    1.18 +  File "${src}/Lib/random.py", line 97, in __init__
    1.19 +    self.seed(x)
    1.20 +  File "${src}/Lib/random.py", line 113, in seed
    1.21 +    a = long(_hexlify(_urandom(2500)), 16)
    1.22 +OSError: [Errno 38] Function not implemented
    1.23 +make: *** [Makefile:927: install] Error 1
    1.24 +```
    1.25 +
    1.26 +While the normal installing process is following:
    1.27 +
    1.28 +```
    1.29 +Collecting setuptools
    1.30 +Collecting pip
    1.31 +Installing collected packages: setuptools, pip
    1.32 +Successfully installed pip-9.0.1 setuptools-28.8.0
    1.33 +```
    1.34 +
    1.35 +Discussion found here: http://bugs.python.org/issue29188
    1.36 +Patch found in the discussion above:
    1.37 +https://hg.python.org/cpython/rev/13a39142c047
    1.38 +
    1.39 +Chunk #1 is removed from the original patch because it rejected.
    1.40 +
    1.41 +
    1.42 +# HG changeset patch
    1.43 +# User Victor Stinner <victor.stinner@gmail.com>
    1.44 +# Date 1483956641 -3600
    1.45 +# Node ID 13a39142c0473ecb64fcd4b12a915025df6e4310
    1.46 +# Parent  cb4f73be9486d47f1dc4285998d1532d8857c59e
    1.47 +Don't use getentropy() on Linux
    1.48 +
    1.49 +Issue #29188: Support glibc 2.24 on Linux: don't use getentropy() function but
    1.50 +read from /dev/urandom to get random bytes, for example in os.urandom().  On
    1.51 +Linux, getentropy() is implemented which getrandom() is blocking mode, whereas
    1.52 +os.urandom() should not block.
    1.53 +
    1.54 +diff --git a/Python/random.c b/Python/random.c
    1.55 +--- a/Python/random.c
    1.56 ++++ b/Python/random.c
    1.57 +@@ -97,8 +97,15 @@ win32_urandom(unsigned char *buffer, Py_
    1.58 + }
    1.59 + 
    1.60 + /* Issue #25003: Don't use getentropy() on Solaris (available since
    1.61 +- * Solaris 11.3), it is blocking whereas os.urandom() should not block. */
    1.62 +-#elif defined(HAVE_GETENTROPY) && !defined(sun)
    1.63 ++   Solaris 11.3), it is blocking whereas os.urandom() should not block.
    1.64 ++
    1.65 ++   Issue #29188: Don't use getentropy() on Linux since the glibc 2.24
    1.66 ++   implements it with the getrandom() syscall which can fail with ENOSYS,
    1.67 ++   and this error is not supported in py_getentropy() and getrandom() is called
    1.68 ++   with flags=0 which blocks until system urandom is initialized, which is not
    1.69 ++   the desired behaviour to seed the Python hash secret nor for os.urandom():
    1.70 ++   see the PEP 524 which was only implemented in Python 3.6. */
    1.71 ++#elif defined(HAVE_GETENTROPY) && !defined(sun) && !defined(linux)
    1.72 + #define PY_GETENTROPY 1
    1.73 + 
    1.74 + /* Fill buffer with size pseudo-random bytes generated by getentropy().
    1.75 +