summaryrefslogtreecommitdiffstats
path: root/meta/classes
Commit message (Collapse)AuthorAgeFilesLines
...
* sstate.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 33611b69c221cf875eba1c7cb599c256825ae470) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* useradd.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 21969c3d1397e0a11a8cb9dad8ce3469ee655f57) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gtk-immodules-cache.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 11a2f932073635f9680470cd69216cecf7ed0c37) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* systemd.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-2/+1
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 8e956d66087b9c41591b8e4e817ed6c9e42f5981) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* license.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 8e9255763674703ea16651da64fe794e5359f16e) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* update-rc.d.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: a77b4e543407eee133fbd38ac9b69e90bea541e0) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gummiboot.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: f7c82acbac583c7838550175796a7aa697a5c7e0) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* systemd-boot.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: c61d7a01c89f0d25d069191cc47d6768bee2ce48) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* syslinux.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: cca772ecf0adafbd767974add27ada125aae5269) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* grub-efi.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 48c4faa1d7117732974e51428f7ed2f62ad7e7bf) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* useradd-staticids.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: e507cb978fd52164beb28324933cb3d5e368c3ab) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package_rpm.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: f0561ba205723fd7f05c28d501c2c517034b326c) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package_deb.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-5/+5
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 5a074e8a26d27ea9c4f31e2b75b2b14f6e0641d3) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package_ipk.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-5/+5
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 01e3ac73860a24710852383a15bb5d01db13de57) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* base.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions raise, not what metadata functions should be raising < kergoth> it didn't end up being used that way < kergoth> but there's really never a reason to raise it yourself FuncFailed.__init__ takes a 'name' argument rather than a 'msg' argument, which also shows that the original purpose got lost. (From OE-Core rev: 9635af9785509a39c1ac2509740d46276119a0ca) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/native: set lt_cv_sys_lib_dlsearch_path_specRoss Burton2016-10-041-2/+1
| | | | | | | | | | | | This variable is used by libtool to know what paths are on the default loader search path. As we have modified loader paths, native.bbclass can tell libtool that both the sysroot libdir and the host library paths are searched, so no RPATHs for those will be generated. (From OE-Core rev: 2d0a1b029447842a6f97f72ae636c9020c4206a9) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/cross: set lt_cv_sys_lib_dlsearch_path_specRoss Burton2016-10-041-0/+2
| | | | | | | | | | | | This variable is used by libtool to know what paths are on the default loader search path. As we have modified loader paths, cross.bbclass can tell libtool that both the sysroot libdir and the host library paths are searched, so no RPATHs for those will be generated. (From OE-Core rev: 5b61324fa76b27bb6ce13e78b17e767eed2f8f57) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* allarch: Fixes to stop rebuilds when change multilibsRichard Purdie2016-10-011-0/+5
| | | | | | | | | | When changing multilibs, allarch recipes should not be rebuilding. This adds enough variable exclusions to make this work properly. Future regressions will be prevented with new testing. (From OE-Core rev: ce1e7fcc60276040477c1d5e3129e029bb9f204b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nativesdk: Don't enable MULTILIBSRichard Purdie2016-10-011-0/+2
| | | | | | | | | | | package_write_rpm references the MULTILIBS variable and the checksums of nativesdk recipes were changing as a result of this. We don't need/want MULTILIBS values for nativesdk so disable this. (From OE-Core rev: 738ff6bc72533bbdeb58425b20b0bfbeff280a04) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* subprocess: remove Popen in favor of check_outputStephano Cetola2016-10-012-7/+10
| | | | | | | | | | | | | This begins moving away from the deprecated subprocess calls in an effort to eventually move to some more global abstraction using the run convenience method provided in python 3.5. [ YOCTO #9342 ] (From OE-Core rev: 0d6b7276003f1afabc6de683f663540327d52bdc) Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* grub-efi.bbclass: Add a space between root and append parameterRaymond Tan2016-10-011-1/+2
| | | | | | | | | | | | | | Add a space between the root and append parameter, similar to syslinux.bbclass, in creating the final grub.cfg. Without this, the final kernel boot parameters will concatenate into strings like root=/dev/ram0console=ttyS0... (From OE-Core rev: a3b271ec8e1b2758e1e619e76646d22fd5777ce3) Signed-off-by: Raymond Tan <raymond.tan@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib_header: avoid sstate checksum issues for -nativesdk recipesJoshua Lock2016-10-011-0/+5
| | | | | | | | | | | | | | | | | | Much as with -native recipes, as addressed in commit b15730caf0d4c40271796887505507f2501958bb, arch specific variables like MIPSPKGSFX_ABI were affecting -nativesdk sstate checksums for recipes like nativesdk-glibc-initial. Disable multilib_header for nativesdk as we don't use multilibs in this scenario. [YOCTO #10320] (From OE-Core rev: f1c7b4f16dc9a7e5155108641fed8b3d98c931f3) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image-buildinfo: restore trailing newlineAndré Draszik2016-10-011-1/+3
| | | | | | | | | | | The last line in the generated /etc/build doesn't end with a newline anymore, restore it. (From OE-Core rev: afbd3917061212558ccacda129eff516b735e5b1) Signed-off-by: André Draszik <git@andred.net> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cross-canadian/libgcc-common: Fixes for arm multilibRichard Purdie2016-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Arm is unusual in that we force it to "linux-gnueabi" and "linux" doesn't build. This was causing problems for multilib configurations which were assuming "linux" was the default compiler rather than linux-gnueabi. This change does two things, ensures symlinks are generated for linux-gnueabi and also adapts the libgcc code to account for the difference on arm. It still needs to immediately expand/save TARGET_VENDOR but we defer deciding what TARGET_OS should be until we know TARGET_ARCH (which the multilib code may change). [YOCTO #8642] Note that sanity tests of a 32 bit arm multilib still break due to issues with the kernel headers on a mixed bit system. This looks to be a general headers issue for the platform though and a different type of bug. (From OE-Core rev: bcddc3e7eff138add031bc9c9728be5a42fa62ef) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuboot: don't fail when QB_DEFAULT_KERNEL isn't symlinkMartin Jansa2016-09-301-1/+1
| | | | | | | | | | | | | | | | | | * in some cases we might set QB_DEFAULT_KERNEL to the real filename instead of symlink and then this whole readlink work around actually breaks the build, because os.readlink fails on normal files: >>> os.readlink('deploy/images/qemux86/bzImage-linux-yocto-qemux86-master-20160927084848.bin') 'bzImage-linux-yocto-qemux86.bin' >>> os.readlink('deploy/images/qemux86/bzImage-linux-yocto-qemux86.bin') Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: [Errno 22] Invalid argument: '/jenkins/mjansa/build-starfish-master-mcf/BUILD/deploy/images/qemux86/bzImage-linux-yocto-qemux86.bin' (From OE-Core rev: a11d0d8641b7dfb05c78645cf21f2c04a08c4822) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_base.bbclass: fix broken variablesIoan-Adrian Ratiu2016-09-281-1/+2
| | | | | | | | | | | | | | This function never worked because the SDK_OUTPUT and SDKPATH vars are written bash-style in a python function. The only reason it never failed a build is because the function bails out the start because of the flag CHECK_SDK_SYSROOTS. And I guess nobody tested with CHECK_SDK_SYSROOTS enabled until now. (From OE-Core rev: 9f60dfdaaa74b90ebcfcdd9f3817c62a56243e92) Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image_types.bbclass: remove redundant dependencyEd Bartosh2016-09-281-1/+0
| | | | | | | | | | | | | Removed parted-native dependency from do_image_wic as it's already mentioned in IMAGE_DEPENDS_wic variable. Thanks to Christopher Larson for pointing out to this. (From OE-Core rev: 82353471ccaae59967df7f14de0b4065cbc8169a) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* SDK: Allow changing SDKMACHINE without wiping TMP folderJuro Bystricky2016-09-281-1/+1
| | | | | | | | | | | | | | | | | | | When changing SDKMACHINE, we may encounter an error forcing us to wipe the TMP folder. Since only SDK_ARCH is captured in the PN of the crosssdk recipes, changes to SDK_OS result in conflicts. Eventually we hit the error: ERROR: ...: The recipe <...> is trying to install files into a shared area when those files already exist. The build has stopped as continuing in this scenario WILL break things This patchset addresses the problem by SDK_SYS as the recipe name suffix instead of SDK_ARCH. [YOCTO #9281] (From OE-Core rev: d2eccccb70e809d482c493922f23aef4409cfd82) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* archive.bbclass: fix do_ar_original archiving of multiple source reposPatrick Ohly2016-09-281-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a recipe uses more than one source which isn't a plain file (for example, multiple git repos), then do_ar_original created the source archives using the same filename and thus only archived one source. The "name" parameter is used as file suffix to create unique names for each source, leading to archives following this pattern: deploy/${TARGET_SYS}/${PF}/${PF}[-<name>].tar.gz. The ${PF} part is a bit redundant, which may or may not be desirable. The patch is more localized this way (no need to modify create_tarball()). For example, meta-oic's iotivity_1.1.1.bb uses: url_iotivity = "git://github.com/iotivity/iotivity.git" branch_iotivity = "1.1-rel" SRC_URI = "${url_iotivity};destsuffix=${S};branch=${branch_iotivity};protocol=http;" url_tinycbor = "git://github.com/01org/tinycbor.git" SRC_URI += "${url_tinycbor};name=tinycbor;destsuffix=${S}/extlibs/tinycbor/tinycbor;protocol=http" url_hippomocks = "git://github.com/dascandy/hippomocks.git" SRC_URI += "${url_hippomocks};name=hippomocks;destsuffix=${S}/extlibs/hippomocks-master;protocol=http" SRC_URI += "file://hippomocks_mips_patch" url_gtest = "http://pkgs.fedoraproject.org/repo/pkgs/gtest/gtest-1.7.0.zip/2d6ec8ccdf5c46b05ba54a9fd1d130d7/gtest-1.7.0.zip" SRC_URI += "${url_gtest};name=gtest;subdir=${BP}/extlibs/gtest" url_sqlite = "http://www.sqlite.org/2015/sqlite-amalgamation-3081101.zip" SRC_URI += "${url_sqlite};name=sqlite3;subdir=${BP}/extlibs/sqlite3;unpack=false" These now get archived in deploy/sources/*/iotivity-1.1.1-r2/ as: gtest-1.7.0.zip iotivity-1.1.1-r2-recipe.tar.gz sqlite-amalgamation-3081101.zip hippomocks_mips_patch iotivity-1.1.1-r2.tar.gz iotivity-1.1.1-r2-hippomocks.tar.gz iotivity-1.1.1-r2-tinycbor.tar.gz (From OE-Core rev: 5c63ffc706c0fff8cfb797a238f4f0e73ee2813d) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* archiver.bbclass: ignore unpack sub-directories in do_ar_originalPatrick Ohly2016-09-281-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | Support for absolute paths in the "subdir" parameter was recently added (bitbake rev: c3873346c6fa). The git fetcher has supported absolute paths in "destsuffix" already before. When the path is absolute as in destsuffix=${S}/foobar, the tmpdir used by do_ar_original gets ignored, which breaks: - source code archiving (tmpdir is empty) - compilation due to race conditions (for example, ${S} getting modified by do_ar_original while do_compile runs) To solve this, these parameters get removed from URLs before instantiating the fetcher for them. This is done unconditionally also for relative paths, because these paths are not useful when archiving the original source (upstream source does not have them, they only get used by the recipe during compilation). (From OE-Core rev: c27c464e267db3f4b08cbd966412d19b0e756d28) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* utils: Add all_multilib_tune_list functionRichard Purdie2016-09-281-0/+37
| | | | | | | | | | Its useful to be able to query a list of variables to obtain the values in each multilib context. This adds such a function which works even if called in the non-default recipe context. (From OE-Core rev: 4202a09dece07c0d3f654c2b1ae504a031b4ee90) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* autotools.bbclass: use python3 instead of python (v2)Markus Lehtonen2016-09-281-1/+1
| | | | | | | (From OE-Core rev: 97b21645fdcdb39a58546b5f4d763b920fe5fbd6) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemu.bbclass: Allow use different QEMU binary depending of targetOtavio Salvador2016-09-241-0/+5
| | | | | | | | | | | | | | There are architectures which support running in 32 and 64 bit flavours however the simulation is provided in a specific QEMU setting, requiring us to use a different binary. This patch allow this to be done using, for example: QEMU_TARGET_BINARY_ppce5500 = "qemu-ppc64abi32" (From OE-Core rev: 9b6d414fd27932ed1325de54e8e867c75b340e3d) Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scons.bbclass: rework parameters for install taskAndreas Müller2016-09-241-1/+1
| | | | | | | | | | | | Fixes: * During install all files were recompiled -> redurced build time * For some recipes we found lot of links to build host image path (From OE-Core rev: 3d1d287785c388bebba2ba1f2d8f843a5c6a2417) Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* testimage.bbclass: Add package manager dependencyMariano Lopez2016-09-231-0/+4
| | | | | | | | | | | | | | | | The feature to install packages in the target requires to build the package manager. It would fail, with very obtuse errors, if a test requires to install something and the package manager hasn't been build. This will add the package manager as dependency for testimage. [YOCTO #10260] (From OE-Core rev: cf548fd85297585cc5688eda45ee332200bbd4b7) Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toolchain-scripts-base: add base class for toolchain_create_sdk_versionJoshua Lock2016-09-232-13/+12
| | | | | | | | | | | | We use toolchain_create_sdk_version() in buildtools-tarball but don't want the extra classes toolchain-scripts pulls in, therefore split out a separate base class for this function which both toolchain-scripts and the buildtools-tarball can inherit. (From OE-Core rev: a398dfa654dc035c404fc12279fac9edf6403e11) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* base.bbclass: Drop unnecessary dirs settingRichard Purdie2016-09-221-1/+1
| | | | | | | | | | | | ${D} is listed in cleandirs so no need to list it in dirs as well. The default directory is ${B} so this is a cleanup which should have no changes to the execution. [YOCTO #10017] (From OE-Core rev: 7e0f95bf359bc3b5bb1578024a993e184de155cd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* autotools/siteinfo: Tweak CONFIG_SITE handling for determism/racesRichard Purdie2016-09-223-10/+16
| | | | | | | | | | | | | | | | | | | | | | As things stand there are multiple races in the CONFIG_SITE handling where checksums can change depending on whether site directories exist or not when parsing happens. This is bad. Secondly, there is a build race that occurs if you build virtuals in parallel with the "main" recipe, since the main recipe is parsed when the virtual is (since it sets variables like BBCLASSEXTEND) and with the current code, it may look for files and directories which could be created/destroyed which the loop is executing. This is also bad. The aclocal-copy directory should only ever be accessed by the call from autotools.bbclass. This changes the parameter name to make it clear and ensures all callers have the right usage, neatly avoiding all the problems above. Also added better comments. (From OE-Core rev: 3207244004c612c1a0e13921251003e5e635d1b1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Add kernel_version_sanity_check functionCalifornia Sullivan2016-09-211-0/+30
| | | | | | | | | | | | | | | | | | The kernel being built should match what the recipe claims it is building. This function ensures that happens by comparing the version information in the kernel's Makefile to the PV the recipe is using. v2 changes: * Match against PV instead of LINUX_VERSION * Match against EXTRAVERSION as well (e.g., -rc4) * Cleaned up version string building Fixes [YOCTO #6767]. (From OE-Core rev: ec467cfaea5c8cf22c61daa8845c2e4e96449512) Signed-off-by: California Sullivan <california.l.sullivan@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_base: fix support for changing SDKMACHINE settingsJoshua Lock2016-09-211-2/+2
| | | | | | | | | | | | | | | | | Include SDKMACHINE in the tasks stamp information and the name of the sstate-inputdirs so that changing SDKMACHINE doesn't result in valid output of the task being deleted when SDKMACHINE is changed. Without this patch changing SDKMACHINE and building an SDK resulted in toolchain installers for other SDKMACHINE's being deleted from the deploy directoy. [YOCTO #10275] (From OE-Core rev: d7a06b53af0066bd12f5f42e10e82b307fd069ce) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image_types: add parted-native to do_image_wic dependsEd Bartosh2016-09-201-0/+1
| | | | | | | | | | | | As parted is always used by wic it makes sense to make do_image_wic dependent on parted-native:do_populate_sysroot. This should help to avoid adding it to all wic image recipes. (From OE-Core rev: c687c9fcc010947f52e1cd153ea74ae5f6343ca4) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuboot.bbclass: don't fail on very first buildAndré Draszik2016-09-201-0/+1
| | | | | | | | | | | | | | | | | | During the very first build, the DEPLOY_DIR_IMAGE directory might not have been created yet, causing the creation of the qemuboot.conf config file to fail. This is because write_qemuboot_conf() runs at rootfs creation time, i.e. before deploy. So let's create the directory if necessary before trying to write the config file. (From OE-Core rev: ee4697350a553a36ca17b9376911e56eee43a465) Signed-off-by: André Draszik <git@andred.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* externalsrc.bbclass: Make reparsing work for BBCLASSEXTENDed recipesPeter Kjellerstedt2016-09-201-3/+17
| | | | | | | | | | | | | | | | | To make sure changes to any source files are detected when externalsrc is used, it sets BB_DONT_CACHE to force the recipe to be reparsed every time. Previously, this was done conditionally based on whether EXTERNALSRC was set. This worked fine for building the base recipe. But if one tried to build, e.g., a native version of it (provided via BBCLASSEXTEND), the recipe would not be reparsed as expected. To solve the above problem, BB_DONT_CACHE is now set for the base recipe if EXTERNALSRC is set for it or any of it derivatives. (From OE-Core rev: 449a0b21255d895e8620383ce76a9d7ea41b5cc6) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: assign INITRAMFS_BASE_NAME using ?=Andre McCurdy2016-09-201-1/+1
| | | | | | | | | | | | Default values for KERNEL_IMAGE_BASE_NAME and MODULE_IMAGE_BASE_NAME are already assigned using ?= and anyone wanting to over-ride one is likely to want to over-ride them all. Make the three consistent with each other. (From OE-Core rev: e30c6c93bb70d17244c90c2be12229148f8f6314) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuboot: also write the kernel link name to the conf fileJoshua Lock2016-09-201-2/+3
| | | | | | | | | | This will allow runqemu to fall back to trying the link name when a file matching the full name can't be found. (From OE-Core rev: 3ccbaaad75f0a53d8bcf6a5c748ec80c96a383bd) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* qemuboot: write the full kernel filename, not the link nameJoshua Lock2016-09-201-0/+8
| | | | | | | | | | | | | | | | | | | KERNEL_IMAGETYPE gives the filename of a symlink to the kernel, which may not be available i.e. if the user downloads some build artefacts to run on a local machine. It's also possible that the link will point to a newer kernel than was intended for use with the rootfs in the qemuboot.conf. It's much more reliable to read the name of the file KERNEL_IMAGETYPE is linking to and assign the full filename to QB_DEFAULT_KERNEL. [YOCTO #10285] (From OE-Core rev: d57bdacab13605ada4cd9e9159c18fdcd6eeacbc) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sanity.bbclass: split out config re-parse checkMarkus Lehtonen2016-09-161-15/+12
| | | | | | | | | | | | | | | | | Split out the functionality doing configuration re-parse check into a separate event handler that is hooked into ConfigParsed event. This will make config re-parsing actually work. Re-parsing in bitbake is triggered by setting BB_INVALIDCONF whose value is checked after configuration has been parsed (after ConfigParsed event). However, previously BB_INVALIDCONF was set in SanityCheck event handler which caused re-parsing never to happen. [YOCTO #10188] (From OE-Core rev: 8fda70bb74f7c63d393d5424436d034d2cc6c05e) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* useradd_base.bbclass: Do not mess with the gshadow file in the sysrootPeter Kjellerstedt2016-09-161-12/+0
| | | | | | | | | | | | | | | | | | | | | | Previously, if the gshadow file did not exist in the sysroot when perform_groupmems() was run, it would be temporarily created and removed again afterwards. This was supposedly due to groupmems failing if it does not exist. However, based on empirical testing and examination of the source code for groupmems, it should not fail if the gshadow file does not exist when groupmems is started. But it WILL fail if the file is removed sometime after its existence has been check at the beginning of the execution, but before it needs to be modified. And this is exactly what the previous code in perform_groupmems() could cause if multiple tasks simultaneously modified users or groups. It could cause any of the useradd, groupadd and groupmems commands to fail as long as at least one other recipe invoked perform_groupmems(). (From OE-Core rev: 4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cve-check.bbclass: Add classMariano Lopez2016-09-161-0/+267
| | | | | | | | | | | | | | | | | | | | | | This class adds a new task for all the recipes to use cve-check-tool in order to look for public CVEs affecting the packages generated. It is possible to use this class when building an image, building a recipe, or using the "world" or "universe" cases. In order to use this class it must be inherited and it will add the task automatically to every recipe. [YOCTO #7515] Co-authored by Ross Burton & Mariano Lopez (From OE-Core rev: d98338075ec3a66acb8828e74711550d53b4d91b) Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sanity: make license QA failures fatal againRoss Burton2016-09-161-6/+8
| | | | | | | | | | | | | | | | Previous work to clean up the license QA code (oe-core fbdf977) had the side effect that failing the license sanity check (bad or missing LIC_FILES_CHKSUM) would emit an error message but wouldn't actually abort the build. Solve this by changing populate_lic_qa_checksum() so that it tracks if the message class was in ERROR_QA and if so, aborts the function. [ YOCTO #10280 ] (From OE-Core rev: 5ba1a7505b904a4aa2118fa9614d76df97597af8) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-28 14:13:23 +0000