linux/poky.git/meta/conf, branch 1.5_M4.rc2

SPDX:real-time license scanning and SPDX output.

2013-08-26T12:19:41+00:00

SPDX integrates real-time license scanning, generates SPDX standard output and license verification information during the OE-Core build process. The existing module includes scanning patched packages and creating package and file level SPDX documents. (From OE-Core rev: 7a37cc81fb95d56b5ac5e5ca22a1900e45717911) Signed-off-by: liangcao Signed-off-by: Elizabeth Flanagan Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

linux-libc-headers: update to v3.10

2013-08-26T10:29:45+00:00

Now that the 3.10 kernel has been released we can bump the libc-headers to that version and remove the 3.8 variant. Userspace compatibility is maintained through kernel versions, we also make the single 3.10 version the toolchain default. (From OE-Core rev: 4e79a46254e778f85c00efd4b0085cbaeb6e0d4d) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

default-providers: Set the preferred provider for bluez

2013-08-23T15:20:14+00:00

There is a need for a default provider for bluez now that bluez5 recipe is also present. After the introduction of bluez5 recipe, the following warnings are displayed: "NOTE: multiple providers are available for runtime libasound-module-bluez (bluez4, bluez5) NOTE: consider defining a PREFERRED_PROVIDER entry to match libasound-module-bluez" Upon debug, bitbake shows: DEBUG: checking PREFERRED_PROVIDER_bluez4 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101-r5 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez5 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7-r0 (value None) against ['bluez4', 'bluez5'] Bitbake is faced with the question "what should provide libasound-module-bluez?" which is a runtime name. It needs to try and find a PREFERRED_PROVIDER entry which matches this but those use *build time* naming. So it converts "libasound-module-bluez" into the canonical ${PN} of bluez4 and bluez5 and then tries to look those up. What it actually should do is go one step further of mapping bluez4/bluez5 into the virtual/bluez but that does not happen. Bug opened on this issue: YB5044 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5044 [YOCTO #5030] (From OE-Core rev: 6f07d066074b1e01ff3c16408812e6b6d5e531ac) Signed-off-by: Cristian Iorga Signed-off-by: Richard Purdie

Drop darwin8/darwin9 usage

2013-08-23T15:20:13+00:00

There were darwin8/darwin9 overrides spinkled in the code from times gone by. Lets settle on the darwin override and remove the others since its pointless duplication. We always inject darwin into OVERRIDES if needed in the darwin8/9 cases. (From OE-Core rev: 8d5e6eed7802a6056f9eaa50a85e3eee00fe2742) Signed-off-by: Richard Purdie

bitbake.conf: Work around dev symlink problems on darwin

2013-08-23T15:20:13+00:00

On darwin, we have: libxxx.dylib -> libxxx.Y.dylib compared to Linux which has: libxxx.so -> libxxx.so.Y Our ordering of PACKAGES with -dev first and then ${PN} makes it impossible to match the files correctly using simple globbing. This makes darwin targets completely broken since both the libs and the dev symlinks end up in ${PN}-dev. Whilst this commit is a hack, it at least puts the files into ${PN} and allows the builds to be used. Symlinks don't take up much space so this isn't the end of the world. I'm open to better solutions to this. (From OE-Core rev: 51c3dbe2df45096bbd7866adabb08e114952ff13) Signed-off-by: Richard Purdie

bitbake.conf/classes/gcc: Don't hardcode -nativesdk

2013-08-23T15:20:12+00:00

Hardcoding -nativesdk as the sdk package architecture is inflexible. We may have multiple different target OS and we need a way to be able to separate them. Turning this into a configurable value allows the flexibility we need to build different SDKMACHINEs with different OS targets. The commit should have no behaviour change, just makes things more configurable. (From OE-Core rev: a2110e86b98d646e136de9ec6b8e668079b0d4f4) Signed-off-by: Richard Purdie

gettext: Improve USE_NLS handling for nativesdk/crosssdk/cross-canadian

2013-08-23T15:20:11+00:00

The gettext handling of USE_NLS has become a bit tricky to understand, or alter from the SDK context. This patch introduces a SDKUSE_NLS which can be set to configure a given SDK/ADT to use NLS or not. This is independent of the target system NLS usage. The code in gettext.bbclass is therefore simplified and the classes themselves now set USE_NLS to appropriate values. No NLS is used for native, cross and crosssdk since it is never used there and would just increase build time. (From OE-Core rev: fe634d47449899f7424adb77ff5bc7ddf8a07a47) Signed-off-by: Richard Purdie

package_rpm.bbclass: NO_RECOMMENDATIONS support

2013-08-22T17:30:00+00:00

Add NO_RECOMMENDATIONS support. A way to disable all recommended packages from being installed. This will help shrink the size of the resulting filesystem. Add documentation on NO_RECOMMENDATIONS and BAD_RECOMMENDATIONS. Note, using NO_RECOMMENDATIONS has side effects such that kernel-modules may not have been installed. A user will need to manually add to their image any kernel-modules required to be on the image for functionality. (From OE-Core rev: 0341bfa886ea851f5a394051545b4e624d8003dd) Signed-off-by: Mark Hatle Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

image.bbclass: Add basic support for PACKAGE_EXCLUDE

2013-08-22T17:29:59+00:00

Add the foundation for the PACKAGE_EXCLUDE support. As part of this work, it was noticed that the PACKAGE_INSTALL and PACKAGE_INSTALL_ATTEMPTONLY were still using he 'normal' version for dependencies. This should no longer be necessary as of the change in the way the complementary package groups (dev, dbg, ptest and others) are defined. By making this change the dependency tree is more correct than before, and gives the ability for manipulating PACKAGE_INSTALL and PACKAGE_INSTALL_ATTEMPTONLY, while adjusting the dependencies at the same time. Warning messages will be generated if the user is trying to exclude a package that was previously in the PACKAGE_INSTALL or PACKAGE_INSTALL_ATTEMPTONLY variables. (See additional commits for package manager specific support.) Add documentation on PACKAGE_EXCLUDE and related variables. (From OE-Core rev: 208d4d5ef7c5ead35dc27b7808f92ed377377aa4) Signed-off-by: Mark Hatle Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

default-distrovars.inc: Add 'DISTRO_FEATURES_DEFAULT' variable

2013-08-20T14:31:25+00:00

When making distributions based on the default distro-less config, it is useful to be able to reuse the default DISTRO_FEATURES options without the need of duplication. The new variable, DISTRO_FEATURES_DEFAULT, allow this reuse and customization. So distros can include 'default-distrovars.inc' and use: ,----[ Use example ] | DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature" `---- (From OE-Core rev: 660ec04786162ff7f40aa78eb154dc4b5bf6ed9f) Signed-off-by: Otavio Salvador Signed-off-by: Saul Wold Signed-off-by: Richard Purdie