linux/poky.git/meta/recipes-devtools/python/python3, branch yocto-2.7

python3: Fix ptest output parsing

2019-04-11T20:12:48+00:00

A previous fix to python added -W and removed -v. This reverts that part of the change since we're no longer getting ptest results at all. This change back to more verbose output means we start getting test results again. (From OE-Core rev: d70c77e4d5ec1d7cb4f134377df11e6475f31062) Signed-off-by: Richard Purdie

python3: Avoid hanging tests

2019-04-11T20:12:48+00:00

There are python tests which hang with recent kernels, 5.0 onwards. This causes ptest to timeout for python3. Disable the problematic test until we better understand the real cause and fix of the issue (discussions are happening with upstream). See the patch for details/links. (From OE-Core rev: 2a48df02a2871635f8235645bfd7f7a3ff0aef31) Signed-off-by: Richard Purdie

openssh/util-linux/python*: Ensure ptest output is unbuffered

2019-04-09T12:44:39+00:00

We need to run sed with the -u option to ensure the output is unbuffered else ptest-runner may timeout thinkig things were idle. Busybox doesn't have the -u option so we need to RDEPEND on sed (which is a good thing to do if we use it anyway). Alex Kanavin should get credit for discovering the problem. (From OE-Core rev: d3ffbebf43c23faa43af81c9ecf6fcaef36d675b) Signed-off-by: Richard Purdie

python: improve ptest

2019-04-02T14:24:11+00:00

Add missing runtime dependencies: the test suite needs proper chmod from coreutils, and the Europe/Minsk timezone. Also change run-ptest to use -W (run verbosely on failure) instead of -v (always verbose) to hopefully reduce the noise in the ptest reports. (From OE-Core rev: 7574f6850797fb7556d2f8077860b7c1d26ae8ec) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

python3: tweaks to achieve 100% pass rate in ptest

2019-02-08T10:57:19+00:00

(From OE-Core rev: 22f4f1ef17219448416b7cf2a570c7acd7149a64) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

python3: upgrade to 3.7.2

2019-02-08T10:57:19+00:00

I took the same approach as the recent perl upgrade: write recipe from scratch, taking the pieces from the old recipe only when they were proven to be necessary. The pgo, manifest and ptest features are all preserved. New features: - native and target recipes are now unified into one recipe - check_build_completeness.py runs right after do_compile() and verifies that all optional modules have been built (a notorious source of regressions) - a new approach to sysconfig.py and distutils/sysconfig.py returning values appropriate for native or target builds: we copy the configuration file to a separate folder, add that folder to sys.path (through environment variable that differs between native and target builds), and point python to the file through another environment variable. There were a few other patches where it was difficult to decide if the patch is still relevant, and how to test that it works correctly; please add those as-needed by testing the new python. (From OE-Core rev: 02714c105426b0d687620913c1a7401b386428b6) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

python3: use ncursesw, not ncurses

2019-01-21T23:44:22+00:00

So that wide-char functions are accssible. [YOCTO #13142] (From OE-Core rev: 042187a65d0622fbd721346b4e55146616c87fd8) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

python/python3: use cc_basename to replace CC for checking compiler

2019-01-07T14:38:39+00:00

When working path contains "clang"/"gcc"/"icc", it might be part of $CC because of the "--sysroot" parameter. That could cause judgement error about clang/gcc/icc compilers. eg: if build under /yocto/builds/xicc/, bitbake python, $CC will contains xicc, will make $CC match *icc, but actuall xicc just folder name. When "*icc" is matched, below errors are reported when compiling python/python3: x86_64-wrs-linux-gcc: error: strict: No such file or directory x86_64-wrs-linux-gcc: error: unrecognized command line option '-fp-model' Here use cc_basename to replace CC for checking compiler to avoid such kind of issue. (From OE-Core rev: 96383efa2726ed1bf7893332d726112a8552fc24) Signed-off-by: Li Zhou Signed-off-by: Changqing Li Signed-off-by: Richard Purdie

python3: Fix do_configure check platform triplet error (2)

2018-12-15T17:10:52+00:00

When building for powerpc 32bit with musl following error triggered from do_configure: checking for the platform triplet based on compiler characteristics... powerpc-linux-gnu configure: error: internal configure error for the platform triplet, please file a bug report This is caused by PLATFORM_TRIPLET != MULTIARCH mismatch since MULTIARCH in case of musl is powerpc-linux-musl. Since triplet is used as part module name as described in PEP-3149 to make fix less intrusive alias powerpc-linux-musl to powerpc-linux-gnu to avoid possible runtime (e.g. tests) incompatibilities later. Fix was inspired by commit cda0ef61d373 ("python3: fix do_configure check platform triplet error"). (From OE-Core rev: b2ec91e12088afa0560aecede587d0970fc64110) Signed-off-by: Serhey Popovych Signed-off-by: Richard Purdie

create_manifest3: Dont match filenames which contain the directory name for new manifest

2018-12-09T11:08:11+00:00

When creating a new python3 manifest, there is a corner case on which the filepath for a certain dependency that was found, could contain the path of an existing folder, e.g. ${libdir}/python3/xmlrpclib.py module path contains ${libdir}/python3/xml, this causes an issue where the dependency doesnt get eventually added on FILES for that module. This patch checks if the dependency that was found is a directory, if it is, it checks if it matches one of the existing directories on the manifest, if it is not, then it checks if the dependency's path (without the filename) matches one of the directories. (From OE-Core rev: 59db12fdf294cfab5c1730337d092a75867658f7) Signed-off-by: Alejandro Enedino Hernandez Samaniego Signed-off-by: Richard Purdie