summaryrefslogtreecommitdiff
path: root/meta/conf
AgeCommit message (Collapse)AuthorFiles
2013-11-12bitbake.conf: Default DISTRO to nodistroRichard Purdie2
An empty distro value leads to OVERRIDES and FILESOVERRIDES containing "::" entries which causes odd issues such as files being included when they shouldn't be. We could put in anonymous python to guard against empty entries but its messy and setting a default value for DISTRO to something harmless is much easier. This patch adds a weak default and ensures the sanity test doesn't complain about it. DISTRO_VERSION and SDK_VERSION are also updated to match. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-04documentation.conf: update contentsBelen Barros Pena1
This patch updates descriptions and brings more info for the variable configurations as documented in the OE-Core manual. This file is used by Toaster to display help for the configuration variables. Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-10-18local.conf.sample.extended: Add some additional comments for security flagsSaul Wold1
Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-10-16bitbake.conf: add WARN_QA and ERROR_QA to the hash whitelistRoss Burton1
I discovered bitbake rebuilding packages because WARN_QA had changed. These variables don't influence the output, so add them to the whitelist. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-10-14separatebuilddir: remove entries for imake and xorg-cf-filesCristiana Voicu1
Imake and the associated xorg-cf-files recipes were removed. Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-10-14bitbake.conf: Remove double slash from PATH_prepend and PKG_CONFIG_DIRMartin Jansa1
* we correctly have ${STAGING_DIR_NATIVE}${base_sbindir_native} and then double slash in ${STAGING_DIR_NATIVE}/${base_bindir_native} * similar in PKG_CONFIG_DIR where libdir also starts with slash ${STAGING_DIR_HOST}/${libdir}/pkgconfig * also fix double slash in insane.bbclass and staging.bbclass * I was a bit nervous about staging change (in case the / was important in some weird use-case, but the extra slash is there since following commit where other extra slashes were removed only the one before libdir was kept: commit 6ea78d648951e5bbe9669412c0863daaf7f49ca5 Author: Richard Purdie <rpurdie@linux.intel.com> Date: Mon Nov 2 17:10:51 2009 +0000 autotools.bbclass: Separate out useful staging functions into base.bbclass and call from autotools classes * this isn't fixing any real-world issue AFAIK, I was just trying to debug one weird case where debugedit fails with canonicalization unexpectedly shrank by one character and it's easier to grep for '//' without many harmless instances already in run* scripts etc Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-24documentation.conf: update contentsBelen Barros Pena1
Documentation.conf is used in WebHob to display information strings about the collected variables. This patch brings the file up-to-date with latest information available from the manual. Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-24qemu: don't claim support for IrDA and PCMCIARoss Burton1
QEMU machines don't have virtual IrDA or PCMCIA hardware, so don't claim to support them. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-20classes/imagetest-qemu: remove old image testing classPaul Eggleton1
This has now been superseded by testimage. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
2013-09-20conf/local.conf.sample: update for new testimage classPaul Eggleton1
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
2013-09-20bitbake.conf: define WORKDIR in terms of BASE_WORKDIRRoss Burton1
To make it easier to move WORKDIR, define it using the new variable BASE_WORKDIR, which is the root of the work directory. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-20bblayers.conf.sample: use ##OEROOT## instead of ##COREBASE##Ross Burton1
The variable ##COREBASE## has been deprecated, so use ##OEROOT## instead. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-17mesa: add virtual/mesa providerRoss Burton1
As there are two alternative mesa recipes (mesa and mesa-gl), there needs to be a virtual provider that recipes that explicitly need Mesa (such as xserver-xorg) can depend on. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-17avahi: fix and enable out-of-tree buildsRoss Burton1
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-17mesa-gl: add GL-only Mesa recipeRoss Burton2
Some machines have hardware-specific GL drivers that do EGL and GLES (many ARM boards). Others have their own EGL/GLES drivers and provide a Mesa DRI driver (EMGD). Previously adding Mesa, for software GL/GLX rendering in the first case and hardware GLX in the second, involved bbappends and changing Mesa to be machine-specific. By adding a just-GL Mesa the machine definition can combine it with the hardware drivers cleanly. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-13bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific ↵Richard Purdie2
directory Currently we have a hierarchy of pkgdata directories and the code has to put together a search path and look through each in turn until it finds the data it needs. This has lead to a number of hardcoded paths and file globing which is unpredictable and undesirable. Worse, certain tricks that should be easy like a GL specific package architecture become problematic with the curretn search paths. With the modern sstate code, we can do better and construct a single pkgdata directory for each machine in just the same way as we do for the sysroot. This is already tried and well tested. With such a single directory, all the code that iterated through multiple pkgdata directories and simply be removed and give a significant simplification of the code. Even existing build directories adapt to the change well since the package contents doesn't change, just the location they're installed to and the stamp for them. The only complication is the we need a different shlibs directory for each multilib. These are only used by package.bbclass and the simple fix is to add MLPREFIX to the shlib directory name. This means the multilib packages will repackage and the sstate checksum will change but an existing build directory will adapt to the changes safely. It is close to release however I believe the benefits this patch give us are worth consideration for inclusion and give us more options for dealing with problems like the GL one. It also sets the ground work well for shlibs improvements in 1.6. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-12layer.conf: Version bump for DEPLOY_DIR layout changeRichard Purdie1
Increase the version to signify the layout change of the images in the deploy directory. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-12bitbake.conf: include machine name in DEPLOY_DIR_IMAGEPaul Eggleton1
This allows a clean seperation between image outputs from different machines, and makes it possible to have convenience symlinks to make the output ready to deploy. This did require some surgery in runqemu; if explicit paths to the image and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined from bitbake or set in the environment. However the script does try to avoid requiring it unless it really is needed. Corresponding changes were made in the automated testing code as well. Based on an RFC patch by Koen Kooi <koen@dominion.thruhere.net> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-12bitbake.conf: Stop providing ${P} and ${PF} by defaultRichard Purdie1
For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. This looks nice at first glance however it turns out to be a bit problematic. Taking make as an example where there are two versions, 3.81 and 3.82, what should "bitbake make-3.81" do? Currently it builds make-3.81 and make-3.82 and breaks in interesting ways. Is that a bitbake bug? Well, it certainly shouldn't try and run the build. Why is it building 3.82 though? Its due to finding a dependency on "make-dev" and then trying to figure out what provides it? The answer is "make" and the default version of "make" is 3.82. So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = "3.81". Doing so resolved the above problem since now "make" resolves to "make-3.81". So what about if we have Recipe A: DEPENDS = "make-3.81" and Recipe B: DEPENDS = "make-3.82" That is clearly an error, easy. So finally what about if we have Recipe A: DEPENDS = "make-3.81" and Recipe B: DEPENDS = "make" The first recipe infers the PREFERRED_VERSION_make = "3.81" and then forces that version on everything else. Is that desired? Probably not in most cases, at least not silently. As mitigation, we could print a WARNING about this happening. The final part of the problem is that we can ony figure this out within bitbake itself. That means we'd have to teach bitbake about the PN-PV format of PROVIDES which is breaking the separation between bitbake and the metadata. We can't win :(. Nobody that I know of is using or relying on this functionality so perhaps we should just remove it instead which is what this patch does. Opinions? Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-11ia32-base: only depend on GL if opengl DISTRO_FEATURE enabledRoss Burton1
As Mesa refuses to compile if the "opengl" DISTRO_FEATURE isn't enabled, mesa-driver-i9xx and the GLX X module have to be conditional in the ia32 machine defintion too. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-11qemu: only depend on mesa-driver-swrast if opengl is enabledRoss Burton3
As Mesa refuses to compile if the "opengl" DISTRO_FEATURE isn't enabled, mesa-driver-swrast has to be conditional in the QEMU machine defintions too. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-09qemu.inc: remove apm as a MACHINE_FEATURESaul Wold1
APM is not only obsolete, but requires a kernel config enabled and is meaningless for QEMU VM [YOCTO #5121] Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-06kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and ↵Jason Wessel2
bundling This patch aims to fix the following two cases for the INITRAMFS generation. 1) Allow an image recipe to specify a paired INITRAMFS recipe such as core-image-minimal-initramfs. This allows building a base image which always generates the needed initramfs image in one step 2) Allow building a single binary which contains a kernel and the initramfs. A key requirement of the initramfs is to be able to add kernel modules. The current implementation of the INITRAMFS_IMAGE variable has a circular dependency when using kernel modules in the initramfs image.bb file that is caused by kernel.bbclass trying to build the initramfs before the kernel's do_install rule. The solution for this problem is to have the kernel's do_bundle_initramfs_image task depend on the do_rootfs from the INITRAMFS_IMAGE and not some intermediate point. The image.bbclass will also sets up dependencies to make the initramfs creation task run last. The code to bundle the kernel and initramfs together has been added. At a high level, all it is doing is invoking a second compilation of the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point to the generated initramfs from the image recipe. [YOCTO #4072] Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-09-06local.conf.sample.extended: Add an example of how to enable fortranRichard Purdie1
Add an example of how to enable FORTRAN from local.conf. Make it clear this is not officially supported. [YOCTO #5091] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-04bitbake.conf: Add SDKPKGSUFFIX to hash whitelistRichard Purdie1
The gcc recipes reference this however we account for it in the work directory paths and we don't want recipes depending on the value changing. This avoids unecessary rebuilds when switching SDKs. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-01meta: Don't use deprecated bitbake APIRichard Purdie1
These have been deprecated for a long time, convert the remaining references to the correct modules and prepare for removal of the compatibility support from bitbake. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-30web-webkit: Drop, we have midori nowRichard Purdie1
This was never a particularly useful browser and is a dead codebase, retire it and suggest midori instead. [YOCTO #2318] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-26SPDX:real-time license scanning and SPDX output.liangcao1
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. Signed-off-by: liangcao <liangcao@unomaha.edu> Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-08-26linux-libc-headers: update to v3.10Bruce Ashfield1
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. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-23default-providers: Set the preferred provider for bluezCristian Iorga1
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] Signed-off-by: Cristian Iorga <cristian.iorga@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-22Drop darwin8/darwin9 usageRichard Purdie1
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-22bitbake.conf: Work around dev symlink problems on darwinRichard Purdie1
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-22bitbake.conf/classes/gcc: Don't hardcode -nativesdkRichard Purdie1
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-22gettext: Improve USE_NLS handling for nativesdk/crosssdk/cross-canadianRichard Purdie1
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-08-22package_rpm.bbclass: NO_RECOMMENDATIONS supportMark Hatle2
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-08-22image.bbclass: Add basic support for PACKAGE_EXCLUDEMark Hatle1
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-08-20default-distrovars.inc: Add 'DISTRO_FEATURES_DEFAULT' variableOtavio Salvador1
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" `---- Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-08-20qemuppc: Change default tune to 74xxKhem Raj1
We use mac99 as platform for qemuppc lets choose a tuning thats appropriate for it Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-08-20tune-ppc7400.inc: Add tune fileKhem Raj1
This is appropriate tune for mac99/g4 platform that we use for emulating qemuppc Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-08-16qemu, default-providers: Add mesa as default virtual/eglMartin Jansa2
* it's safer to select it consistently with virtual/libgl* providers Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-08-13mesa: fix and enable out-of-tree buildsRoss Burton1
One patch (submitted upstream) for when Gallium is enabled, and another (inappropriate for upstream) to fix out-of-tree builds with 0003-EGL-Mutate-NativeDisplayType-depending-on-config. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-08-09separatebuilddir: add commentsRoss Burton1
Add a comment explaining the libproxy failure, and note that wpa-supplicant doesn't support B!=S. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-07-30csl-versions.inc: instruct user to check local.confLaurentiu Palcu1
In case the compiler version cannot be extracted instruct user to check that the toolchain supports MACHINE's architecture and that the latter is set correctly in local.conf. [YOCTO #4901] Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-07-27external-sourcery: add missing providersSaul Wold1
Addess the issue with multiple .bb providers ERROR: Multiple .bb files are due to be built which each provide virtual/libc (/srv/hdd/releases/dylan/meta/recipes-core/eglibc/eglibc_2.17.bb /srv/hdd/releases/dylan/meta/recipes-core/meta/external-sourcery-toolchain.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide virtual/arm-none-linux-gnueabi-libc-for-gcc (/srv/hdd/releases/dylan/meta/recipes-core/eglibc/eglibc_2.17.bb /srv/hdd/releases/dylan/meta/recipes-core/meta/external-sourcery-toolchain.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide virtual/libiconv (/srv/hdd/releases/dylan/meta/recipes-core/eglibc/eglibc_2.17.bb /srv/hdd/releases/dylan/meta/recipes-core/meta/external-sourcery-toolchain.bb). This usually means one provides something the other doesn't and should. Thanks to Kergoth (Chris Larson) and Lpapp (Lazslo) [YOCTO #4908] Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-07-27classes/rootfs_rpm: implement BAD_RECOMMENDATIONS for RPMPaul Eggleton1
Add support for the BAD_RECOMMENDATIONS variable that can be used to prevent specific packages from being installed via an RRECOMMENDS relationship when using the RPM backend. (Previously this functionality was only available when using ipk packaging.) In the process this moves the defaulting of BAD_RECOMMENDATIONS (as empty) to bitbake.conf since it is no longer specific to the ipk backend, as well as unifying some of the code that creates the configuration for smart for use on the host and target. Fixes [YOCTO #3916]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-07-18local.conf.sample.extended: add example for EXTRA_USERS_PARAMSChen Qi1
Add detailed explanation of EXTRA_USERS_PARAMS which is used for image level user/group configuration. [YOCTO #4074] Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-07-10security_flags: Add addition recipes to the non pie listSaul Wold1
Create a local SECURITY_NO_PIE_CFLAGS to cover the recipes that have issues with with pic and pie cflags set. Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-07-05tcmode-default: Pin eglibc to 2.18Khem Raj1
Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-07-05distro/conf: Drop libc-libm-bigKhem Raj2
Its gone with eglibc 2.18 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-07-05layer.conf: Bumping LAYERVERSION_coreElizabeth Flanagan1
Bumping LAYERVERSION_core to denote where meta-toolchain* is being depreciated. This goes back to my RFC: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39016 As we are removing meta-toolchain* and replacing it with bitbake <imagename> -c populate_sdk this causes issues with those of us who need to do automated builds both on the current development branch and on prior development branches. Example: For prior releases, I need to build meta-toolchain*. Without having a simple way to figure out where this is no longer the case, I (and other folks who run automated builds) end up having to jump through a lot of hoops trying to figure out where this layer changed. Utilizing LAYERVERSION_* to do it makes sense as there is a significant change that would cause issues for build engineers. Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>