This is needed for updating piglit to use Python 3.
Python 2 based recipe can be later moved to meta-oe.
(From OE-Core rev: 3e751bd05f7033b15e717fa4d56fefd915d2ea0c)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will be necessary for transiting piglit to Python 3.
Python 2 recipe should be kept as it is used by mesa (and
gobject-introspection, for now).
(From OE-Core rev: 72be3752a56d681672fb3e04413ff3cc59391150)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code that utilized them was superseded by the code (in the same patch!)
that is utilizing STAGING_LIBDIR/STAGING_INCDIR, and wasn't correct in the
first place as HOST_SYS is not necessarily the same as the sysroot directory
name.
(From OE-Core rev: 8834e81a38c24a066bb4fefa93da61011d0db244)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Need add python3-git to buildtools-tarball for the py3 build.
(From OE-Core rev: fa19a541deb46dec1f4fbd60f08584daa06e2d6b)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Need add python3-git to buildtools-tarball for the py3 build, and the
dependencies chain is:
python3-git -> python3-gitdb
(From OE-Core rev: b13babf07d77bcbed21c24761e2f4ada9ba85507)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Need add python3-git to buildtools-tarball for the py3 build, and the
dependencies chain is:
python3-git -> python3-gitdb -> python3-async
(From OE-Core rev: 816a518ecab232e4efe26ad203ce42c4543a79ca)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Need add python3-git to buildtools-tarball for the py3 build, and the
dependencies chain is:
python3-git -> python3-gitdb -> python3-smmap
(From OE-Core rev: 762c280259b90d2cb827b8f8dc62490e36bd7df8)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The error reporting improvements were merged upstream (smartpm 406541f569)
and refactored later (smartpm 20af0aac33), yet a part of the patch was
kept here (oe-core 5fc580fc44).
Due to the upstream refactoring the patch still applies cleanly, but it
isn't actually needed. The added changes are duplicate or dead code.
(From OE-Core rev: f1cfa9ab5d79198671275cea2c9864ce0cbcb9f0)
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SmartPM could misinterpret RPM transaction error as success,
if ts.run() (RPM Python API) returns an empty problems list.
This could happen for example if the RPM database is partially corrupted
such that the transaction does not have any problems like conflicts or
missing dependencies, but still can't be committed.
The added patch fixes the problem in the upstream sources;
one of the existing patches has to be adjusted to still apply.
(From OE-Core rev: 1dc5f5d5c844585eec114be9480e0e4d8e60d09c)
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SmartPM's --remove-all option was unusable, because the fix from
commit 03266e89a6 was lost in commit 5fc580fc44. Thus, add a new
patch to fix --remove-all.
It seems like the previous fix was lost by mistake:
Upstream merged the *old* version of the patch (smartpm 406541f569),
and when SmartPM in oe-core was upgraded to the new upstream release,
the --remove-all fix from the *new* patch was not carried over.
(From OE-Core rev: ba2adda60dd34b6a8feba413e3207dd8e4580294)
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes inconsistency where expat dependency is
then depending upon build host having it or not having it
Fixes errors like
WARNING: renaming "pyexpat" since importing it failed: build/lib.linux-x86_64-2.7/pyexpat.so: undefined symbol: XML_SetCommentHandler
also reported here
https://dev.openwrt.org/ticket/20087
This work due to the fact that we use -isystem pointing to native sysroot
so the search order of native includedir is moved after buildhosts system
includdirs. Moment we replace it with -I, build falls apart
This also fixes the error
Caught exception: <type 'exceptions.ImportError'> ImportError('No module named _elementtree',)
where gobject-introspection-native fails to find _elementtree
which is only compiled if expat is available
(From OE-Core rev: a63798df712bf0d2362e07713c06af3b071a10b2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gnomebase class already depends on gnome-common-native, so there's no need
to depend on it again.
(From OE-Core rev: 13621e8ac158e1eb65a04054899f7cdec796d38f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ac_cv_sizeof_off_t was previously in the site cache files, which was breaking
large file support and required a workaround in each recipe that actually wanted
to use large files.
Now that the entry has been removed from the site cache, we can remove the
workarounds.
(From OE-Core rev: 1485d7cae88adb3575c6eaa47784fe50820d2740)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
NPY_SIZEOF_OFF_T must be defined. Otherwise:
/home/ricardo/curro/qt5022/oe/openembedded-core/build/tmp-glibc/sysroots
/qemux86-64/usr/lib/python2.7/site-packages/numpy/core/include/numpy/
npy_common.h:140:9: warning: "NPY_SIZEOF_OFF_T" is not defined [-Wundef]
#if NPY_SIZEOF_OFF_T == NPY_SIZEOF_SHORT
^
/home/ricardo/curro/qt5022/oe/openembedded-core/build/tmp-glibc/sysroots/
qemux86-64/usr/lib/python2.7/site-packages/numpy/core/include/numpy
/npy_common.h:142:11: warning: "NPY_SIZEOF_OFF_T" is not defined [-Wundef]
#elif NPY_SIZEOF_OFF_T == NPY_SIZEOF_INT
^
/home/ricardo/curro/qt5022/oe/openembedded-core/build/tmp-glibc/sysroots/
qemux86-64/usr/lib/python2.7/site-packages/numpy/core/include/numpy/
npy_common.h:144:11: warning: "NPY_SIZEOF_OFF_T" is not defined [-Wundef]
#elif NPY_SIZEOF_OFF_T == NPY_SIZEOF_LONG
^
/home/ricardo/curro/qt5022/oe/openembedded-core/build/tmp-glibc/sysroots/
qemux86-64/usr/lib/python2.7/site-packages/numpy/core/include/numpy/
npy_common.h:146:11: warning: "NPY_SIZEOF_OFF_T" is not defined [-Wundef]
#elif NPY_SIZEOF_OFF_T == NPY_SIZEOF_LONGLONG
^
/home/ricardo/curro/qt5022/oe/openembedded-core/build/tmp-glibc/sysroots/
qemux86-64/usr/lib/python2.7/site-packages/numpy/core/include/numpy/
npy_common.h:149:10: error: #error Unsupported size for type off_t
#error Unsupported size for type off_t
(From OE-Core rev: f0b21c0c1a5f50126eff098568a792a1be85f422)
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ideally this would be an option but that means conditional inherits. For now
Python 2 is clearly the default Python in oe-core so switch to Python 2 instead
of 3.
This stops python3 being pulled inadvertently into builds, and appearing in
images that have ptest-pkgs installed (via dbus-test).
(From OE-Core rev: 7ae7277a577b2732eff7812860a7c7967644e532)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* restore changes from:
http://git.openembedded.org/openembedded-core/commit/?id=53ae544cfdac22c82af452b8c7ebe6664296bd9b
* which were shamelessly removed in upgrade to 2.7.9:
http://git.openembedded.org/openembedded-core/commit/?id=d4ad95f0d5f08891637c644e85b09da9c4585059
and then spread to python3 as well
* fixes following issues reported by test-dependencies
WARN: python3: python3-tkinter rdepends on glibc, but it isn't a build dependency?
WARN: python3: python3-tkinter rdepends on libpython3, but it isn't a build dependency?
WARN: python3: python3-tkinter rdepends on tcl-lib, but it isn't a build dependency?
WARN: python: python-tkinter rdepends on glibc, but it isn't a build dependency?
WARN: python: python-tkinter rdepends on libpython2, but it isn't a build dependency?
WARN: python: python-tkinter rdepends on tcl-lib, but it isn't a build dependency?
and following QA warnings in normal builds:
python-2.7.11: python-tkinter rdepends on tcl-lib, but it isn't a build dependency, missing tcl in DEPENDS or PACKAGECONFIG? [build-deps]
python-2.7.11: /usr/lib/python2.7/lib-dynload/_tkinter.so contained in package python-tkinter requires libtk8.6.so, but no providers found in RDEPENDS_python-tkinter? [file-rdeps]
python3-3.5.1: python3-tkinter rdepends on tcl-lib, but it isn't a build dependency, missing tcl in DEPENDS or PACKAGECONFIG? [build-deps]
python3-3.5.1: /usr/lib/python3.5/lib-dynload/_tkinter.cpython-35m-arm-linux-gnueabi.so contained in package python3-tkinter requires libtk8.6.so, but no providers found in RDEPENDS_python3-tkinter? [file-rdeps]
(From OE-Core rev: 8cc5e36cd7978186d5ea1fe8af2f2bd6b3df8885)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The RPM4 support we added to SMART doesn't appear to work, remove
it as part of the removal of RPM4 from OE-Core.
Refresh the smart-add-for-rpm-ignoresize-check.patch which was
applied after smart-rpm4-fixes.patch and doesn't apply cleanly once
that patch is removed.
(From OE-Core rev: e1108fa41742e726aa578d0298fa6397b2663ff3)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Match API version in cached _numpyconfig.h to the
one mandated by numpy version in use.
(From OE-Core rev: 7a0ba5cbb1ea0a379c1e61fb58d7595e8f8480c4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove build path in comments:
Without the fix:
...
|This file is generated by /buildarea/raid0/hjia/build-20160225-yocto-
buildpath/tmp/work/core2-64-poky-linux/python-numpy/1.10.4-r0/numpy
-1.10.4/setup.py
...
With the fix:
...
|This file is generated by /numpy-1.10.4/setup.py
...
[YOCTO #7058]
(From OE-Core rev: 06835e109264b0472f4a47e33a74b0c872ebd7f1)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The compile() method returns objects that inherit from ast.AST so it's best that
python-core contains this class.
[YOCTO #8684]
(From OE-Core rev: 48bc643a4ebe74d0fa49fedbe7b0fd63fd0003e8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For p1022ds bsp, the MULTIARCH is powerpc-linux-gnuspev1 and
python3 did not recognize the extra 'v1' which caused python3
configure error for the platform triplet.
Q:Why Python3 check platform triplet?
A:Under Linux, GNU/KFreeBSD and the Hurd, C extensions now include
the architecture triplet in the extension name, to make it easy to
test builds for different ABIs in the same working tree.
vim config.log
...
EXT_SUFFIX='.cpython-35m-powerpc-linux-gnuspe.so'
...
Here is the generated C extensions which take platform triplet into account.
...
|image/usr/lib/python3.5/lib-dynload/_datetime.cpython-35m-powerpc-linux-gnuspe.so
...
https://bugs.python.org/issue22980https://www.python.org/dev/peps/pep-3149/https://bugs.python.org/review/22980/patch/14593/54808
[YOCTO #9226]
(From OE-Core rev: cda0ef61d37357fed1daa22f6a59ef9f906fcada)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new version of pygobject relies in gobject introspection;
this has prevented the update previously.
(From OE-Core rev: 12d61ac95b6bfae60dd4a7c7239bc8b8b0bcafbb)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-pygtk hasn't been updated in several years, is incompatible
with the current version of pygobject, and is generally obsolete as
all modern python gtk apps use introspection directly.
(From OE-Core rev: 14f62d1663b7a9082b8026cd5d22eea66ad75174)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previous, two things were wrong:
1) lib_basename was set from STAGING_LIBDIR only if prefix parameter was empty or missing
2) if prefix was not empty, lib_basename reverted to sys.lib, even if STAGING_LIBDIR
should've overriden it
(From OE-Core rev: 28d29004aa7d17794216d7df55afc308b1f0e806)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In python 3.4 python-config was rewritten in shell, ironically
to support cross-compilation:
https://bugs.python.org/issue16235
This new shell version is broken in several ways, and doesn't
have our oe-specific tweaks. Let's revert to the old script,
which is still provided.
(From OE-Core rev: b0d714c7f831828a5e09381fe36e3f859c16b2d9)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When trying to install packages using python-setuptools, compilation
may fail complaining about the py_compile module not existing, this
presented itself when installing pyephem for example, this patch
adds python-compile to setuptools RDEPENDS to fix the issue.
[YOCTO 9009]
(From OE-Core rev: 1348fe26a182330475ca163e87205dc162fb3f6a)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-xml depends on python-elementtree as the latter just contains a C library
used by the former. However there's no point to this split apart from
increasing the number of packages, so merge -elementtree into python-xml.
(From OE-Core rev: 5f7206eba3953b7f29148ecfb791995773ee5fc7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This ensures that the nativesdk python functions correctly without needing to
set PYTHONHOME in the sdk environment setup script.
(From OE-Core rev: c5629268b0f8ae0a425c98337d13e8dc83107e13)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python 3 resurrected the default to optimised patch, on the rationale that
embedded systems want all the performance they can get. Unfortunately the only
impact Python "optimisation" has is to remove all asserts which can be actively
harmful, so remove this patch.
(From OE-Core rev: 1e43b836106ed13cde294e2c565eaea6fe5efca7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These variables are exported through distutils.bbclass, so there's no need to do
it again.
(From OE-Core rev: 247522b0eae6ec528350888d2283e84bb1e250fa)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The python-nose upgrade to 1.3.7 required a new unittest runtime dependency
after this, bitbake cant find a runtime provider for it when trying to build
python-nose-native, this patch makes python-native RPROVIDES python-unittest-native
to fix the issue.
(From OE-Core rev: 4583cd1bb15306e8f0ab7bcd80732e6f35aa4533)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrades python-setuptools to 19.2, easy_install works out of the box
adds the package python-plistlib to the manifest as it is needed by
setuptools now, and also updates runtime dependencies
(From OE-Core rev: 25efefac9f68d34bbb109645a515010b846c3a8b)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Installing python3-modules should install *all* of the Python standard library,
not just most of it.
(From OE-Core rev: b2c1c48d90aa9a94f90836557856e0319ddcb524)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
