Save PKG (the actual output package name, which is often different due
to debian renaming), and PKGE/PKGV/PKGR (which may be manipulated in
certain special cases e.g. gitpkgv.bbclass in meta-oe, the
external-sourcery-toolchain recipe, etc.) Note that these are only
written when they are different from the normal package name in the
case of PKG, or PE/PV/PR for the other variables.
Also, use PKGE/PKGV/PKGR instead of PE/PV/PR when comparing package
versions since these actually represent the version that the package
manager sees.
Implements [YOCTO #2787].
(From OE-Core rev: 65d7e9b2d4d8115ac9fd513c04f39a2df9556a5a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Write the value of these package script variables into the packageinfo
so that any changes to them can be tracked (in separate files since they
are multi-line).
Inspired by an earlier patch from Andreas Müller <schnitzeltony@googlemail.com>
(From OE-Core rev: 988a417c857c01c87de6ba9602968059cf8d830f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getlastrecipeversion and readRecipeInfo weren't called anywhere.
Remove them so we don't have to keep them up-to-date with future
additions to the recipe info file.
(From OE-Core rev: 22bf6284576ccee607d7bd197420a29242df11c0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a package is removed from PACKAGES, ensure that the package info file
and directory are removed from buildhistory so that we don't have stale
data lying around.
(From OE-Core rev: 223b183197b363edef0c11a25bad33555fca5a15)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the ability to set BUILDHISTORY_KEEP_VERSIONS = "1" to save the
package history as flat versioned files rather than relying on git to
keep previous versions of the package information. git has proven to
work quite well in this capacity.
(From OE-Core rev: ccedfd250620fc562988ba730ad5717b107a9d3e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* openldap from meta-oe is autodetected and then libldap-2.4-2 runtime dependency added to curl and almost all meta-efl recipes
(From OE-Core rev: 666b67179d4492e4d950b94457ebf8cac6454f7d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.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
(From OE-Core rev: e4039eb74b20e96d4b8837cd58cf2d13d091e1ad)
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>
It is considered good practice to use the build system provided
variables instead of directly specify hardcoded paths.
(From OE-Core rev: ce2665b6ae77770d69ffbc4d45c96ce829d16738)
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.
(From OE-Core rev: c859717f522098e7c68df578d59011f68122dc2c)
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.
(From OE-Core rev: 8b94cd639c02bcc653312575592673c36df0ec92)
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.
(From OE-Core rev: 3068d5c44667bc238f2331d36cb116403560c83f)
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.
(From OE-Core rev: 3fce22d81cc27629c7c3fd4c174b68c8ced468cf)
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.
(From OE-Core rev: bc45d990938c1b1d761cee6e90464d22f854a2ab)
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.
(From OE-Core rev: e044be34601dcc8eeca7f96d628964bebf562e2e)
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.
(From OE-Core rev: 7b77d4372ace6aa2400e3328875b39b4f67476d0)
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.
(From OE-Core rev: 998b94adbbc0f0f036c5816fbf6ee594dba90c1c)
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.
(From OE-Core rev: aada9260af9dcac42c21e189fdf6698e509c26a4)
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.
(From OE-Core rev: 43a7286ed5f628f04597ce7e4bea0d91bc95b09b)
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.
(From OE-Core rev: 5082056a4671570ca4578da2f622b3cc6f9f2dda)
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.
(From OE-Core rev: 7556e60bf23c07646594a1704b3db7dfc29e631d)
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.
(From OE-Core rev: b7134e8f76026d15a5e35c6a2e5d77d5e48c2787)
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.
(From OE-Core rev: 3be575babcdb12f95f4882d3c42bdf3ba1ec1900)
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.
(From OE-Core rev: f8f33550f5cc263673cbd481a567116514603b8d)
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.
(From OE-Core rev: 095f9c056373a252c0ba2679d8e6f4ad932a958d)
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.
(From OE-Core rev: c0ebcac02023705aead0d2588224a62d64fe1752)
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.
(From OE-Core rev: 73ee5587a46751ed39a181b3ff2a12d4a3086c21)
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.
(From OE-Core rev: b93a9dadc9a2754d4e33929bda8dba46dd20b694)
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.
(From OE-Core rev: 7b13be661c869eb4bf88d16a928a97edd5bc203b)
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.
(From OE-Core rev: 0a8003a3542d17332488ca715619990b222ceb71)
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.
(From OE-Core rev: a9c73d9d3dd5f7fbee82d7ed3cb88a80aa3cbfbd)
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.
(From OE-Core rev: 84fd332ab2f2c512109fc0a080d03533883fa235)
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.
(From OE-Core rev: 72fd0993d8643d7ca52d954d65395585fdf34b03)
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.
(From OE-Core rev: 6f0eebbd12d79a86dd4a79f87b6be4758439a3f5)
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]
(From OE-Core rev: 11267f8a1ccf65142988b095351a84b0fa0fcbcf)
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
(From OE-Core rev: 662637decc23888c9b0da93807257943bab14583)
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.
(From OE-Core rev: 5416bf849ceefb49f06bedfa5e67595e9c68582a)
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)
(From OE-Core rev: 90cfe33d30ef4f9491bd52e7965c5279a2e2650c)
Signed-off-by: Khem Raj <raj.khem@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]
(From OE-Core rev: 7a97abb3f1c2ff8fd2dc7c59f866430cf99ab82d)
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]
(From OE-Core rev: e6fb5a25a098bd639be4b176f58e552404232c93)
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
