linux/poky.git/meta/recipes-devtools/python/python3, branch uninative-1.8

python: refresh patches

2018-03-09T17:17:04+00:00

The patch tool will apply patches by default with "fuzz", which is where if the hunk context isn't present but what is there is close enough, it will force the patch in. Whilst this is useful when there's just whitespace changes, when applied to source it is possible for a patch applied with fuzz to produce broken code which still compiles (see #10450). This is obviously bad. We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For that to be realistic the existing patches with fuzz need to be rebased and reviewed. (From OE-Core rev: 0b25fcee333e6207a8596d26adfa65fec85c26df) Signed-off-by: Ross Burton Signed-off-by: Alexander Kanavin Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python3: Fix python3-logging dependencies

2018-02-16T18:05:39+00:00

python3-logging depends on python3-netserver (logging/config.py:42) (From OE-Core rev: ea5f51cf2b885ba32a3e5fe6049141e45606ecf3) Signed-off-by: Tomasz Meresiński Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python3: update target and native recipes to 3.5.4

2018-02-06T11:06:27+00:00

Use the latest 3.5 version until the 3.6 migration is complete Removed the following upstreamed patches: - python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch - python3/upstream-random-fixes.patch Rebased the following pathes: - python3/0001-cross-compile-support.patch Regenerated the manifest based on the latest release version Updated the license checksum for the latest version that updated the copyright dates (From OE-Core rev: eb80d0391d7d4e83a61ed8850d936b102be3fa02) Signed-off-by: Derek Straka Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python3-manifest: add the _pydecimal files to the numbers package

2018-01-29T08:49:50+00:00

The _pydecimal files are required to use the numbers package and downstream packages are currently required to add a RDEPENDS on python3-misc to avoid an import error (From OE-Core rev: 4ca2d607a6b6fe8686bf89177287f2b9bae01245) Signed-off-by: Derek Straka Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python3: Fix native compilation of gdbm module and manifest

2018-01-20T22:31:56+00:00

The gdbm module wasnt being built on python3-native showing the following error during compilation: Failed to build these modules: _gdbm This patch adds the required dependency to fix the compilation problem. This issue on python3-native caused the manifest creation script to be unaware of the gdbm library, so this patch also fixes the create_manifest task for target python, and the manifest file to reflect the changes on target python as well. (From OE-Core rev: c47b54aeae5daabb458d6f7118a16257021c1822) Signed-off-by: Alejandro Hernandez Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python*-manifest.json: add dependencies, runpy

2018-01-20T22:31:56+00:00

* runpy allows running modules/scripts with 'python -m foo' - create explicit python2 and 3 packages rather than the misc catchall * python3-setuptools and html.parser RDEPENDS on _markupbase - add to python3-core rather than misc catchall * pip3 RDEPENDS on plistlib, http.client - already packaged in python2, add to python3 - add http/ to -netclient * "pip3 install" RDEPENDS on encodingds.idna - encodings.idna packaged in -core, but missing: - stringprep (move from -codecs to -core) - unicodedata (move from -codecs to -core) (From OE-Core rev: 65a85c7db3de8d16ff91a5208a59cc2202d34e5b) Signed-off-by: Tim Orling Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python3: Restructure python3 packaging and replace it with autopackaging

2018-01-20T22:31:56+00:00

See previous commit (python2 version) for more info, since mostly everything applies here as well. Old manifest file had several issues: - Its unorganized and hard to read and understand it for an average human being. - When a new package needs to be added, the user actually has to modify the script that creates the manifest, then call the script to create a new manifest, and then submit a patch for both the script and the manifest, so its a little convoluted. - Git complains every single time a patch is submitted to the manifest, since it violates some of its guidelines. - It changes or may change with every release of python, its impossible to know if the required files for a certain package have changed (it could have more or less dependencies), the only way of doing so would be to install and test them all one by one on separate individual images, and even then we wouldnt know if they require less dependencies, we would just know if an extra dependency is required since it would complain, lets face it, this isnt feasible. - The same thing happens for new packages, if someone wants to add a new package, its dependencies need to be checked manually one by one. Features/Fixes: - A new manifest format is used (JSON), easy to read and understand. This file is parsed by the python recipe and python packages read from here are passed directly to bitbake during parsing time. - It provides an automatic manifest creation task (explained on previous commit), which automagically checks for every package dependencies and adds them to the new manifest, hence we will have on each package exactly what that package needs to be run, providing finer granularity. - Dependencies are also checked automagically for new packages (explained on previous commit). This patch has the same features as the python2 version but it differs in the following ways: - Python3 handles precompiled bytecode files (*.pyc) differently. for this reason and since we are cross compiling, wildcards couldnt be avoided on python3 (See PEP #3147 [1]). Both the manifest and the manifest creation script handle this differently, the manifest for python3 has an extra field for cached files, which is how it lets the user install the cached files or not via : INCLUDE_PYCS = "1" on their local.conf. - Shared libraries nomenclature also changed on python3, so again, we use wildcards to deal with this issue ( See PEP #3149 [2]): - Fixes python3 manifest, python3-core should be base and everything should depend on it, hence several packages were deleted: python3-enum, re, gdbm, subprocess, signal, readline. - When building python3-native it adds as symlink to it called nativepython3, which is then isued by the create_manifest task. - Fixes [YOCTO #11513] while were at it. References: [1] https://www.python.org/dev/peps/pep-3147/ [2] https://www.python.org/dev/peps/pep-3149/ (From OE-Core rev: 54ac820b8a639950ccb534dcd9d6eaf8b2b736e0) Signed-off-by: Alejandro Hernandez Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python3: remove two setup.py cross-compile hacks

2017-12-02T11:25:32+00:00

Remove two unneeded hacks. The first hack ("setup.py: no host headers libs" patch) is not needed because we use cross-compiler (e.g. i586-oe-linux-gcc) which has not been configured with any host system include or library directories, and thus, we don't get any host system directories when running "gcc -E -v". The second hack becomes useless after the first hack has been removed and we get the standard include and lib directories normally from gcc. (From OE-Core rev: 9e9545ef818adfb57f428db96d4c2ebb0ea65ec6) Signed-off-by: Markus Lehtonen Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python3: improve reproducibility

2017-08-15T23:03:15+00:00

The compiled .pyc files contain time stamp corresponding to the compile time. This prevents binary reproducibility. This patch allows to achieve binary reproducibility by overriding the build time stamp by the value exported via SOURCE_DATE_EPOCH. Patch by Bernhard M. Wiedemann. [YOCTO#11241] (From OE-Core rev: 2175aec10a764bfc925a3fb447547982d0ae662f) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie

python2/python3: fix multiprocessing.BoundedSemaphore not work on qemux86/qemuarm

2017-08-13T08:27:37+00:00

In upstream, the following commit: https://github.com/python/cpython/commit/e711cafab13efc9c1fe6c5cd75826401445eb585 ... commit e711cafab13efc9c1fe6c5cd75826401445eb585 Author: Benjamin Peterson Date: Wed Jun 11 16:44:04 2008 +0000 Merged revisions 64104,64117 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk ... (see diff in setup.py) It assigned libraries for multiprocessing module according the host_platform, but not pass it to Extension. In glibc, the following commit caused two definition of sem_getvalue are different. https://sourceware.org/git/?p=glibc.git;a=commit;h=042e1521c794a945edc43b5bfa7e69ad70420524 (see diff in nptl/sem_getvalue.c for detail) `__new_sem_getvalue' is the latest sem_getvalue@@GLIBC_2.1 and `__old_sem_getvalue' is to compat the old version sem_getvalue@GLIBC_2.0. If not explicitly link to library pthread (-lpthread), it will load glibc's sem_getvalue randomly at runtime. Such as build python on linux x86_64 host and run the python on linux x86_32 target. If not link library pthread, it caused multiprocessing bounded semaphore could not work correctly. ... >>> import multiprocessing >>> pool_sema = multiprocessing.BoundedSemaphore(value=1) >>> pool_sema.acquire() True >>> pool_sema.release() Traceback (most recent call last): File "", line 1, in ValueError: semaphore or lock released too many times ... And the semaphore issue also caused multiprocessing.Queue().put() hung. (From OE-Core rev: ca1542cdf6b6437a2f3dcdb33ac5216bf841c04a) Signed-off-by: Hongxu Jia Signed-off-by: Ross Burton Signed-off-by: Richard Purdie