summaryrefslogtreecommitdiffstats
path: root/meta/classes
Commit message (Collapse)AuthorAgeFilesLines
...
* classes/populate_sdk_ext: add symlinks and unfsd to support Eclipse pluginPaul Eggleton2016-10-071-2/+12
| | | | | | | | | | | | | | The Yocto Project Eclipse plugin requires that runqemu and unfsd are accessible within the SDK, and indeed the standard SDK has these. This turns out to be fairly easy to do - we just need to add unfsd and symlink it, runqemu and a few other scripts into the SDK's bin directory. Fixes [YOCTO #10214]. (From OE-Core rev: 9007e0e3fce7e09b043fead54b17f69c1661d162) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/uboot-extlinux-config: Add classFabio Berton2016-10-071-0/+126
| | | | | | | | | | | | | | | | | | | | | | This class allow the extlinux.conf generation for U-Boot use. The U-Boot support for it is given to allow the Generic Distribution Configuration specification use by OpenEmbedded-based products. This class can be inherited by u-boot recipes to create extlinux.conf and boot using menu options. U-boot with extlinux support is machine dependent, so to use this class you need to set UBOOT_EXTLINUX to 1 in machine configuration file and also set root= kernel cmdline UBOOT_EXTLINUX_ROOT. This variable is used to pass root kernel cmdline, e.g: UBOOT_EXTLINUX_ROOT = "root=/dev/mmcblk2p2" (From OE-Core rev: 7c18abeb2a6ef8b7bb53aa92a9ee76bd465fada2) Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linuxloader.bbclass: Adjust mips to cover all mips/mips64Mark Hatle2016-10-071-1/+4
| | | | | | | | | | | | | | | | [YOCTO #10389] Use a glob (*) to match all mips (not previously matched). This will ensure that the linuxloader is properly returned for mips, mipsel, mips64, mips64el and their n32 variants. See: https://sourceware.org/glibc/wiki/ABIList#mips for the official list of loaders. (From OE-Core rev: b90d68fda3d14b4d19b7ffcb5b80ed28563a616d) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* siteinfo.bbclass: Add mipsisa{32, 64}r6{el, } supportZubair Lutfullah Kakakhel2016-10-071-0/+4
| | | | | | | | | Add support for MIPS Release 6 ISA (From OE-Core rev: fcb67508be00cdd22181d6c9e4c3d29dfa578b45) Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linuxloader.bbclass: Add mipsisa{32, 64}r6{el, } supportZubair Lutfullah Kakakhel2016-10-071-0/+3
| | | | | | | | | | | | | Add support for MIPS Release 6 ISA. The loader is located at a new place for multiarch. For more details, check https://wiki.debian.org/Multiarch and https://sourceware.org/glibc/wiki/ABIList#mips (From OE-Core rev: 27537d146f3f143b06819102c348c8914287ec8e) Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libc-package.bbclass: Add mipsisa{32, 64}r6{el, } supportZubair Lutfullah Kakakhel2016-10-071-0/+4
| | | | | | | | | Add support for MIPS Release 6 ISA (From OE-Core rev: 8e098ddb656d39c56427ad45e0fa429b8f0153f5) Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-arch.bbclass: Add mipsisa{32, 64}r6{el, } supportZubair Lutfullah Kakakhel2016-10-071-1/+1
| | | | | | | | | Add support for MIPS Release 6 ISA (From OE-Core rev: aecb57f2fd65a1bfbc2e9a23fba4984d44055c4c) Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* insane.bbclass: Add mipsisa{32, 64}r6{el, }Zubair Lutfullah Kakakhel2016-10-071-0/+4
| | | | | | | | | Add support for MIPS release 6 of the ISA (From OE-Core rev: 6613ee0155de1e0afd30cd8d8290eda3f7486337) Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* utils.bbclass: add function to check for git config userStephano Cetola2016-10-073-9/+19
| | | | | | | | | | | | | | | | | | | | | | If attempting to patch a git repo without a proper git config setup, an error will occur saying user.name/user.email are needed by git am/apply. After some code was removed from kernel-yocto, it was simple enough to reproduce this error by creating a kernel patch and using a container to build. This patch abstracts out functionality that existed in buildhistory for use in other classes. It also adds a call to this functionality to the kernel-yocto class. Fixes [YOCTO #10346] introduced in OE-core revision 0f698dfd1c8bbc0d53ae7977e26685a7a3df52a3 (From OE-Core rev: 25b43cb05c645e43f96bc18906441b8fdc272228) Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* icecc.bbclass: replace os.popen with subprocess.check_outputMartin Jansa2016-10-061-4/+10
| | | | | | | | | * otherwise there is a lot of warnings about missing close on file descriptor (From OE-Core rev: 629ff6eb58ddad2d533cbcc8b1a4594d3c8fd441) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_base.bbclass: Make do_populate_sdk depend on ↵Peter Kjellerstedt2016-10-061-1/+1
| | | | | | | | | PACKAGE_EXCLUDE_COMPLEMENTARY (From OE-Core rev: 06c732bb8e2896d789716e7f0635aac9ff3a2d42) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image.bbclass: Make do_rootfs depend on PACKAGE_EXCLUDE_COMPLEMENTARYPeter Kjellerstedt2016-10-061-1/+1
| | | | | | | (From OE-Core rev: 7294c550eb3c7e31f8b80c7055aa84945c75c7f1) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/sstate.bbclass: Enable thread lock when checkstatusAníbal Limón2016-10-051-0/+4
| | | | | | | | | | | | | | The checkstatus function fires an event to notify bitbake UI about the progress of the task, this function is implemented using ThreadPool and is causing event lose when multiple threads tries to fire an event (writes over socket/fd). [YOCTO #10330] (From OE-Core rev: 6e0bb9d141438c0051c32b0d3a247915b71ccb82) Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* testimage.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: 5f8eb6726a492d259bfe25b0bbce2333c9505504) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* utility-tasks.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: de45a7e302fe5a2a08baf26c91e2c788d7285263) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package.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: 8443b6f3f25181f5ac49bc25a1387cd05b814376) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libc-package.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: 5369bb7fa6238cc85f0b5263519974c1a2d9eea8) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* testsdk.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: 086240468265dc15c5b4cdb2594d5aa7c3114dda) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* chrpath.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: 20e669f56489b2c8a9bc6a0e6f3eac81ef35445a) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-27 07:25:04 +0000