The manifest file was not regenerated when the package was updated.
(From OE-Core rev: c42a1cf42b88c0dc02baf807ee2aa3dab058c4cd)
Signed-off-by: Derek Straka <derek@asterius.io>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rebased:
- python/01-use-proper-tools-for-cross-build.patch
- python/fix-makefile-for-ptest.patch
- python/parallel-makeinst-create-bindir.patch
Removed Upstreamed Patch:
- python/Don-t-use-getentropy-on-Linux.patch
Updated license checksum for changes in the copyright date. The license
terms remain unchanged
Added an extra do_compile item to create the native pgen that no longer
gets compiled by default
(From OE-Core rev: 9f2de4f9cf1eb6de75dc789bd0549f45c7a68c55)
Signed-off-by: Derek Straka <derek@asterius.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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 <timothy.t.orling@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The reason we have a manifest file for python is that our goal is to
keep python-core as small as posible and add other python packages only
when the user needs them, hence why we split upstream python into several
packages.
Although our manifest file has 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.
This patch fixes those issues, while adding some additional features.
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 below),
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 below).
- Fixes the manifest in the following ways:
* python-core should be base and all packages should depend on it,
fixes lang, string, codecs, etc.
* Fixes packages with repeated files (e.g. bssdb and db, or
netclient and mime, and many others).
- Sitecustomize was fixed since encoding was deprecated.
- The JSON manifest file invalidates bitbake's cache, so if it changes
the python package will be rebuilt.
- It creates a solution for users that want precompiled bytecode files
(*.pyc) INCLUDE_PYCS = "1" can be set by the user on their local.conf to
include such files, some argument they get faster boot time, even when the
files would be created on their first run?, but they also sometimes give a
magic number error and take up space, so we leave it to the user to
decide if they want them or not.
- Fixes python-core dependencies, e.g.
When python is run on an image, it TRIES to import everything it needs,
but it doesnt necessarily fails when it doesnt find something, so even if
we didnt know, we had errors like (trimmed on purpose):
# trying /usr/lib/python2.7/_locale.so
# trying /usr/lib/python2.7/lib-dynload/_locale.so
# trying /usr/lib/python2.7/_sysconfigdata.so
while it didnt complain about _locale it should have imported it,
after creating a new manifest with the automated script we get:
# trying /usr/lib/python2.7/lib-dynload/_locale.so
dlopen("/usr/lib/python2.7/lib-dynload/_locale.so", 2);
import _locale # dynamically loaded from /usr/lib/python2.7/lib-dynload/_locale.so
How to use (after a new release of python, or maybe before every OE
release):
- A new task called create_manifest was added to the python package,
which may be invoked via:
$ bitbake python -c create_manifest
This task runs a script on native python on our HOST system, and since
the python and python-native packages come from the same source, we can
use it to know the dependencies of each module as if we were doing it
on an image, this script is called create_manifest.py and in a very
simplistic way it does the following:
1. Reads the JSON manifest file and creates a dictionary data structure
with all of our python packages, their FILES, RDEPENDS and SUMMARY.
2. Loops through all of them and runs every module listed on them
asynchronously, determining every dependency that they have.
3. These module dependencies are then handled, to be able to know which
packages contain those files and which should RDEPEND on one another.
4. The data structure that comes out of this, is then used to create a
new manifest file which is automatically copied onto the user's python
directory replacing the old one.
Create_manifest script features:
- Handles modules which dont exist anymore (new release for example).
- Handles modules that are builtin.
- Deals with modules which were not compiled (e.g. bsddb or ossaudiodev)
- Deals with packages which include folders.
- Deals with packages which include FILES with a wildcard.
- The manifest can be constructed on a multilib environment as well.
- This method works for both python modules and shared libraries used
by python.
How to add a new package:
- If a user wants to add a new package all that has to be done is
modify the python2-manifest.json file, and add the required file(s)
to the FILES list, the script should handle all the rest.
Real example:
We want to add a web browser package, including the file webbrowser.py
which at the moment is on python-misc.
"webbrowser": {
"files": ["${libdir}/python2.7/lib-dynload/webbrowser.py"],
"rdepends": [],
"summary": "Python Web Browser support"}
Run bitbake python -c create_manifest and the resulting manifest
should be completed after a few seconds, showing something like:
"webbrowser": {
"files": ["${libdir}/python2.7/webbrowser.py"],
"rdepends": ["core","fcntl","io","pickle","shell","subprocess"],
"summary": "Python Web Browser support"}
Known errors/issues:
- Some special packages are handled differently: core, misc,
modules,dev, staticdev.
All these should be handled manually, because they either include
binaries, static libraries, include files, etc. (something that we
cant import).
Specifically static libraries are not not supported by this method
and have to be handled by the user.
- The change should be transparent to the user, other than the fact
that now we CANT build python-foo (it was pretty dumb anyway, since
what building python-foo actually did was building the whole python
package anyway), but doing IMAGE_INSTALL_append = " python-foo"
would create an image with the requested package with no issues.
[YOCTO #11510] [YOCTO #11694] [YOCTO #11695]
(From OE-Core rev: 6959e2e4dba5bbfa6ffd49c44e738cc1c38bc280)
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>
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, backported from https://github.com/python/cpython/pull/296
[YOCTO#11241]
(From OE-Core rev: 2a044f1e4f5c63e11e631b31f741c7aabfa6f601)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In upstream, the following commit:
e711cafab1
...
commit e711cafab13efc9c1fe6c5cd75826401445eb585
Author: Benjamin Peterson <benjamin@python.org>
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 "<stdin>", line 1, in <module>
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 <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds or fixes the Upstream-Status for all remaining patches missing it
in OE-Core.
(From OE-Core rev: 563cab8e823c3fde8ae4785ceaf4d68a5d3e25df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE-2016-5636.patch and avoid_parallel_make_races_on_pgen.patch were
removed from SRC_URI as handled upstream in adf4266524.
(From OE-Core rev: 53c0d1f18d4a11b0130e54466c91320acf4f5b18)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch from 2.7 branch to fix a regression with glibc
2.24 causing "OSError: [Errno 38] Function not implemented" when
calling urandom() with older kernels.
(From OE-Core rev: 3f2be1c857a44030478ce25b4a722667b73de446)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enforce the correct tag names across all of oe-core for consistency.
(From OE-Core rev: 606a43dc38a00cc243f933722db657aea4129f8e)
Signed-off-by: Ross Burton <ross.burton@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>
* 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>
If the target and host have the same type, the system
may try to execute the instructions from the target
version. This can lead to illegal instructions
as well as the wrong copy of the code running.
Add CROSSPYTHONPATH for PYTHON_FOR_BUILD and export
the correct path to fix it.
(From OE-Core rev: 1cda7afd4173100e4185ee8759f6b2770bc93b72)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a variety of problems such as typos, bad punctuations, or incorrect
Upstream-Status values.
(From OE-Core rev: bd220fe6ce8c3a0805f13a14706d3130ea872604)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Parallel make races when linking PGEN affects target's python
compilation as well, adds patch from python-native to modify the
Makefile and avoid parallel make races, also updates upstream status
(From OE-Core rev: 4f0d1015aa3331ae7b376f836d3188b6017abfb1)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Based on Paul Eggletons work to partially upgrade to Python 2.7.6
Modified:
default-versions.inc: switched to python 2.7.9
generate-manifest-2.7.py: fixed _sysconfigdata
python-2.7-manifest.inc: fixed _sysconfigdata
python.inc: Updated checksums and source, no LICENSE
change just updated some dates
python-native_2.7.3 -> python-native_2.7.9 and updated patches
python_2.7.3 -> python_2.7.9, and added ac_cv_file__dev_ptmx=no
ac_cv_file__dev_ptc=no in EXTRA_OECONF to solve python
issue #3754, only needed when cross compiling, also updated patches
use_sysroot_ncurses_instead_of_host.patch: New patch to use ncursesw
from sysroot instead of hosts, introduced by fix for python issue #15268
Rebased:
01-use-proper-tools-for-cross-build.patch
03-fix-tkinter-detection.patch
05-enable-ctypes-cross-build.patch
06-avoid_usr_lib_termcap_path_in_linking.patch
avoid_warning_about_tkinter.patch
builddir.patch
fix_for_using_different_libdir.patch
host_include_contamination.patch
multilib.patch
nohostlibs.patch
search_db_h_in_inc_dirs_and_avoid_warning.patch
Deleted (fixed on upstream):
06-ctypes-libffi-fix-configure.patch
CVE-2013-4073_py27.patch
gcc-4.8-fix-configure-Wformat.patch
json-flaw-fix.patch
posix_close.patch
pypirc-secure.patch
python-2.7.3-CVE-2012-2135.patch
python-2.7.3-CVE-2013-1752-smtplib-fix.patch
python-2.7.3-CVE-2014-1912.patch
python-2.7.3-CVE-2014-7185.patch
python-2.7.3-berkeley-db-5.3.patch
python-fix-build-error-with-Readline-6.3.patch
remove-BOM-insection-code.patch
remove_sqlite_rpath.patch
python2.7.3-nossl3.patch
[YOCTO #7059]
(From OE-Core rev: d4ad95f0d5f08891637c644e85b09da9c4585059)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Integer overflow in bufferobject.c in Python before 2.7.8 allows
context-dependent attackers to obtain sensitive information from
process memory via a large size and offset in a "buffer" function.
This back-ported patch fixes CVE-2014-7185
(From OE-Core rev: 49ceed974e39ab8ac4be410e5caa5e1ef7a646d9)
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport patch from:
https://hg.python.org/cpython/rev/af46a001d5ec
SysLogHandler converts message to utf8 and adds BOM, supposedly
to conform with RFC5424, but the implementation is broken:
the RFC specifies that the BOM should prefix only unstructured
message part, but current Python implementation puts it in the
middle of structured part, thus confusing RFC-compliant receivers.
(From OE-Core rev: c51caffe5ac0d49844dcbac7967f609d44c20470)
Signed-off-by: yzhu1 <yanjun.zhu@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
musl has posix_close which conflicts in python
so lets rename it.
(From OE-Core rev: 9de4f6eb07696f618d4762c6eeb34dc9ea3080bd)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
http://bugs.python.org/issue21529
Python 2 and 3 are susceptible to arbitrary process memory reading by
a user or adversary due to a bug in the _json module caused by
insufficient bounds checking.
The sole prerequisites of this attack are that the attacker is able to
control or influence the two parameters of the default scanstring
function: the string to be decoded and the index.
The bug is caused by allowing the user to supply a negative index
value. The index value is then used directly as an index to an array
in the C code; internally the address of the array and its index are
added to each other in order to yield the address of the value that is
desired. However, by supplying a negative index value and adding this
to the address of the array, the processor's register value wraps
around and the calculated value will point to a position in memory
which isn't within the bounds of the supplied string, causing the
function to access other parts of the process memory.
(From OE-Core rev: 9ec213bf67afbdfdbe25802ec86487bb22aeb2e4)
Signed-off-by: Benjamin Peterson <benjamin@python.org>
Applied to python-native recipe in order to fix the above mentioned
vulnerability.
Upstream-Status: Submitted
Signed-off-by: Daniel BORNAZ <daniel.bornaz@enea.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Avoids the determinism problem shown with the warnings:
WARNING: QA Issue: python-tkinter rdepends on libx11 but its not a build dependency? [build-deps]
WARNING: QA Issue: python-tkinter rdepends on tcl-lib but its not a build dependency? [build-deps
(From OE-Core rev: 53ae544cfdac22c82af452b8c7ebe6664296bd9b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A remote user can send specially crafted data to trigger a buffer overflow
in socket.recvfrom_into() and execute arbitrary code on the target system.
The code will run with the privileges of the target service.
This back-ported patch fixes CVE-2014-1912
(From OE-Core rev: 344049ccfa59ae489c35fe0fb7592f7d34720b51)
Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport two patches from upstream:
use new readline function types (closes#20374)
Issue #20374: Avoid compiler warnings when compiling readline with libedit.
[YOCTO #6107]
(From OE-Core rev: a6b91ae7dec2edebc0eaea0592c42b1c455ad4d7)
Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <kergoth@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its bad practise to poke into the sysroot without knowledge of sstate.
This adds a patch to python allowing us to account for cross compiling
and allow it to find the Makefile/pyconfig.h files without needing them
in the sysroot for do_compile/do_install to complete.
Tested on two architectures and compared with buildhistory with no
significant delta.
(From OE-Core rev: 16da4f75a75dc8020803df9ea73a2a7ead88cc5a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On non-gplv3 builds, gdbm gets built different due to the different version
which triggers a different codepath in python's db support and then hence
triggers an invalid RPATH QA issue. This change extends the appropriate patch
to cover the code paths we need it to cover and avoid adding the problematic
RPATH.
(From OE-Core rev: 90540692c40719b757b80bdc6e78e679a3df83a7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
_bsddb module in python 2.7 could be built only with db version
between 4.1 and 4.7. A patch was added to avoid build warning
about this for [YOCTO #1937] but not actually fixed it.
This patch enable _bsddb module be built with db 5.3, and remove
--disable-statistics from the DB5_CONFIG to fix segmentation fault
when using _bsddb module in python.
[YOCTO #2749]
(From OE-Core rev: 11267f8a1ccf65142988b095351a84b0fa0fcbcf)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bin/python2 link is provided by the python install process,
so no need to create it.
rebase these patches to the newer code:
fix_for_using_different_libdir.patch
04-default-is-optimized.patch
remove this patch as it is upstream now:
sys_platform_is_now_always_linux2.patch
Change default python version to 2.7.3 in the distro config
(From OE-Core rev: 5d92a95ea9b480235b7c9ca5949a681376eba725)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sunaudiodev module is sunos specific so we avoid a warning by not.
adding this module to missing variable.
[YOCTO #1937]
(From OE-Core rev: a92847ed7671386225c0738d62780a9f1b043789)
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
_tkinter module needs tk module along with tcl. tk is not yet integrated
in yocto so we skip the check for this module.
Avoid a warning by not adding this module to missing variable.
[YOCTO #1937]
(From OE-Core rev: 3f1be431054b3947bee9a2503eea1a3cefb38f4c)
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
_bsddb module can be built only with db version between 4.1 and 4.7.
Avoid a warning by not adding this module to missing variable.
[YOCTO #1937]
(From OE-Core rev: d974ad03c58d7a221ebe3d59c57607928fbbd435)
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python should search for db.h in inc_dirs and not in a hardcoded path.
If db.h is found but HASHVERSION is not 2 we avoid a warning by not.
adding this module to missing variable.
[YOCTO #1937]
(From OE-Core rev: 79d0332f21769338a9f904308d8a808486e10fea)
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch was added for 64bit host machines. In the compile process python
is checking if platform is a 64bit platform using sys.maxint which is the host's
value. The patch fixes this issue so that python would check if TARGET machine
is 64bit not the HOST machine. In this way will have "dl" and "imageop" modules
built if HOST machine is 64bit but the target machine is 32bit.
[YOCTO #1937]
(From OE-Core rev: 4993f50744882ee384cb8fb106ad209f0d887b3f)
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The move of libcrypto to /lib instead of /usr/lib has broken the _hashlib module
compilation. There were also a number of other failing modules which should
have been building correctly. This turned out partly to be the /lib issue
but also due to a number of native paths creeping into compiler commandlines.
These changes add in /lib as part of the searh directory and remove
a number of host contamination issues within setup.py. Post release we
should really further go through this file and just delete large sections
of it as its hard to be sure what strange paths python is injecting as
search paths.
This patch also fixes issues where re-execution of the compile task
would corrupt the Makefile in various ways, again leading to puzzling
paths within the configuration.
(From OE-Core rev: 20e2761e1da1cb5dcd267e161f2a6b6a429e9f39)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit fixes python's install issue of not finding the
native pythong binray modules.
(From OE-Core rev: bf52e32e09423056c8c78760db22ca7497ec357d)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fixes many problems with linux2 vs. linux3. At least:
- Detected version was from build-host instead of target-host.
- linuxaudiodev and ossaudiodev were disabled for linux3.
- Files were missing in /usr/lib/python2.7/plat-linux3.
* Imported from upstream HG rev c816479f6aaf
* Bugtracker URL: http://bugs.python.org/issue12326
(From OE-Core rev: accb2b728ab10cae20be59253a56ac6410b8de10)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
