linux/poky.git/meta/recipes-devtools/python/python_2.7.3.bb, branch 1.6_M3.final

python_2.7.3.bb: Inherit python-dir

2014-02-02T22:37:39+00:00

So it can get the correct python direcotries for python2 (From OE-Core rev: cfc780ec26474a61bd52a8f6a66c7280fa12a075) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

python, python-native: fix PARALLEL_MAKEINST failure

2013-12-03T17:45:53+00:00

When using make -j with the 'install' target, it's possible for altbininstall (which normally creates BINDIR) and libainstall (which doesn't, though it installs python-config there) to race, resulting in a failure due to attempting to install python-config into a nonexistent BINDIR. Ensure it also exists in the libainstall target. (From OE-Core rev: 54da47f3ddc1c009594744793060ffd09db3ad11) Signed-off-by: Christopher Larson Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

python: do not replace ccache in the middle of a path

2013-12-03T17:45:51+00:00

Python recipe did a sed s/ccache/$(CCACHE) on the Makefile, which replaces all "ccache" including ones that consist of a full path. This leads to build error when building in a project path with "ccache" in its name. Fix it by only replacing "ccache " with "$(CCACHE) ". (From OE-Core rev: 1181112cf65bc0186807fc59399c5dddcb9f9449) Signed-off-by: Lei Liu Signed-off-by: Richard Purdie

python: Fix ptest not working problems

2013-11-18T17:19:10+00:00

The run-ptest contained in python uses a Makefile. The path of the Makefile is changed to ${libdir}/python/ptest in do_install_ptest. However, the directory is wrong when the project is configured with "--enable-multilib=lib32" In addition, do_install_ptest is defined before "inherit ptest", so it is overriden by the one in ptest.bbclass. do_install_ptest is moved down. (From OE-Core rev: 0eb947454e1c92467283e6f1adeca67c7c57698b) Signed-off-by: Zhangle Yang Signed-off-by: Richard Purdie

python: Ensure build completes before install

2013-10-07T08:37:32+00:00

At the start of install, python swizzles the makefiles around, leading to chunks of do_compile running again. These race against the install target, leading to errors if pieces are being recompiled whilst others are being installed. For now, workaround this by running the compile target with the new makefile, then running install ensuring a parallel make race doesn't happen. (From OE-Core rev: 72938a8631cfe5be5ac88ad67f2db595e2487e86) Signed-off-by: Richard Purdie

python: Backport 2 CVE from upstream

2013-08-30T17:06:32+00:00

These are back ports of 2 patches from upstream to address CVE-2011-4944 CVE-2013-4238 (From OE-Core rev: 4606eab53e8eff57d6369ea20a5ea63916ea3ea7) Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

python: Add ptest

2013-07-24T10:35:34+00:00

Install python test suite and run it as ptest (From OE-Core rev: a768047cb8fc00ecf13f4db08117c348a9312c47) Signed-off-by: Tudor Florea Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

python: Add nativesdk wrapper to handle terminfo

2013-06-18T16:33:14+00:00

Currently if you build nativesdk-python, install it and try and run it, you see it search in the default nativesdk path for terminfo files when the readline module is used. If terminfo files cannot be found, or if the ones found are incorrect, the system may emit control characters which confuse commandline processing. This patch sets the TERMINFO_DIRS variable to ensure the correct locations are searched for terminfo files, starting with the nativesdk terminfo files and falling back to the host systtem's. (From OE-Core rev: 682861166f39fbdcd0c9b923139faab2d40362cf) Signed-off-by: Richard Purdie

python: -Wformat is needed by gcc 4.8

2013-06-14T11:44:37+00:00

This fixes errors in packages using python( build with gcc 4.8) | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/qemuarm/usr/include/python2.7/modsupport.h:27:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=] | PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3); | ^ | cc1: all warnings being treated as errors | cc1: all warnings being treated as errors (From OE-Core rev: 5745a482a85c064a1eec960aff104cf8ce588e30) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

python: remove the default optimization

2013-05-10T10:43:12+00:00

We had hard coded python-native and python's default optimization to 1, which made the "assert" statement didn't work, and removed the "-O/-OO" (optimization options), the target python had a "-N" option to disable the default optimization, but the native python didn't. I think that we can set the environment variable PYTHONOPTIMIZE or use "python -O" if we need to optimize, but I'm not sure whether we need to set it by default, it would confuse the user or cause/hide unexpected problems if the "assert" doesn't work. [YOCTO #4427] (From OE-Core rev: 165ed464bbb9bf985dde9d8c15d000809901fff6) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie