Age | Commit message (Collapse) | Author | Files |
|
* openldap from meta-oe is autodetected and then libldap-2.4-2 runtime dependency added to curl and almost all meta-efl recipes
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These include files are really required, not optional.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
- The license file has changed, but the project still has the same
license
- Patches have been rebased on top of the 8.0 branch. crossfix.patch
and crossfix-mklib.patch have been merged as they address the same
problem
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This allows us to remove the docdir worksarounds and fixes other
potential relocation issues at the same time as cleaning up the
recipe.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
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]
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* Update to the latest version of psplash which fixes a segmentation fault
bug
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
when we build for nativesdk it needs tools from installed
glib-2.0-dev package. We zeroes out compile_resourses but
then genmarshal came up so instead of going about disabling
them one by one lets depend on glib-2.0-native since
thats the right thing to do.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Now that we have moved the rpm-createsolvedb.py
script to createrepo-native for good reason of
python-native dependency, we have to make sure
that it is staged before its used, unlike before
where it was under scripts/ dir and always existed
outside the realm of package management.
Fixes build error when doing meta-toolchain builds from
scratch
|
/home/kraj/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/meta-toolchain-1.0-r7/temp/run.populate_sdk_image.26712:
line 610: rpm-createsolvedb.py: command not found
| DEBUG: Python function do_populate_sdk finished
| ERROR: Function failed: populate_sdk_image (see
/home/kraj/yocto/poky/build/tmp/work/ppc64e5500-poky-linux/meta-toolchain-1.0-r7/temp/log.do_populate_sdk.26712
for further information)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* whole MACHINEOVERRIDES can change e.g. between MACHINES with different arm architecture, causing allarch packages to reexecute do_package
bitbake-diffsigs ../shr-core/tmp-eglibc/stamps/all-oe-linux/xserver-nodm-init-2.0-r16.do_package.sigdata.90e760a8f6cecbd87cb2e95f1237e3cc ../shr-core/tmp-eglibc/stamps/all-oe-linux/xserver-nodm-init-2.0-r16.do_package.sigdata.9eeccfd15f25032b3b6b132534660fff
basehash changed from 7618e17d3fda05d1f15246e6800ca0f0 to 97bc4dc8c1521c535bd96b2aa62d8a03
Variable MACHINEOVERRIDES value changed from ${MACHINE}${@bb.utils.contains("TUNE_FEATURES", "armv5", ":armv5", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv4", ":armv4", "" ,d)}:${MACHINE_CLASS} to ${MACHINE}${@bb.utils.contains("TUNE_FEATURES", "armv7a", ":armv7a", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv6", ":armv6", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv5", ":armv5", "" ,d)}${@bb.utils.contains("TUNE_FEATURES", "armv4", ":armv4", "" ,d)}:${MACHINE_CLASS}
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* same fix as
http://git.openembedded.org/openembedded-core/commit/?id=7d3fd68480d54a8ef0d91a772df3506cd45ef2c2
is needed for native too
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
tclConfig.sh is changed in do_install for cross compile and
is installed to STAGING_BINDIR_CROSS, but if SSTATE_DIR is set
and tcl is from sstage, tclConfig.sh can't be found in
STAGING_BINDIR_CROSS, add ${bindir_crossscripts}/tclConfig.sh
to sysroot stage can fix it.
[YOCTO #2891]
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This patch fixes parallel install issue that lib libpixbufloader-png.la
depends on libgdk_pixbuf-2.0.la which will be regenerated during insta-
llation, if libgdk_pixbuf-2.0.la is regenerating and at the same time
libpixbufloader-png.la links it, the error will happen.
Error message is:
* usr/bin/ld: cannot find -lgdk_pixbuf-2.0
* collect2: ld returned 1 exit status
Make an explicit dependency to the libs install targets would fix this
issue.
[YOCTO #2883]
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #2896]
The du-k-works test seems to assume that du -k on a directory with two files
totaling 80 kilobytes should report either 80k or 88k. In ext4 filesystm however,
both busybox' du -k and coreutils' du -k reports a size of 84k which causes the
test to fail.
Intergrate the patch from:
http://git.busybox.net/busybox/commit/?id=a5ee090e8651692545514a81a16c6cde3a2dc577
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If we don't do this, a stale limits.h may be detected in STAGING_DIR_TARGET
which would result in a different limits.h getting generated by gcc-cross-initial
that references it. The referenced limits.h will then not get found by eglibc-initial
causing rather strange build failures.
The simplest solution is to create a temporary sysroot containing only the things
gcc-cross-initial should care about and this results in a correct limits.h file
regardless of what else may have been built.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
reported and this should flush anything stale out
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Radu Moisan <radu.moisan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This fixes errors like:
| error: Failed dependencies:
| /bin/perl is needed by texi2html-5.0-r1.i586
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This fixes errors on distros with python as /bin/python of the form:
| error: Failed dependencies:
| /bin/python is needed by gnome-desktop-2.32.1-r5.i586
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|