summaryrefslogtreecommitdiffstats
path: root/meta/classes
Commit message (Collapse)AuthorAgeFilesLines
* image_types: Use softer setting of WKS_FILESaul Wold2016-10-251-1/+1
| | | | | | | | | | | This will allow for more flexibility and overrides in BSP layers. (From OE-Core rev: 1886ab2f1dc1e3b5758a85604998e8deb9198f5e) Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* buildstats: check IMAGE_ROOTFS exists before checking its sizeMikko Ylinen2016-10-251-6/+7
| | | | | | | | | | | | | | | | | | After 0d6b7276003f1afabc6de683f663540327d52bdc, the exceptions are correctly checked if the rootfs size check fails. In case of a failure a build error is triggered. However, there are cases where this is known to fail (e.g., with meta-swupd the rootfs for swupd images is other than IMAGE_ROOTFS). Because of that, check IMAGE_ROOTFS exists before trying to get the size of it. Also, in case of any error catched as err, simply print out a warning. (From OE-Core rev: b4929542ff01a24bea5edd1c40e3174f55e213ff) Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* insane.bbclass: fix package_qa_check_arch() for mips64-o32Robert Yang2016-10-151-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed: MACHINE = "qemumips64" DEFAULTTUNE = "mips64-o32" $ bitbake linux-yocto ERROR: linux-yocto-4.8+gitAUTOINC+03bf3dd731_674818dad5-r0 do_package_qa: QA Issue: Bit size did not match (32 to 64) linux-yocto on /work/qemumips64-poky-linux/linux-yocto/4.8+gitAUTOINC+03bf3dd731_674818dad5-r0/packages-split/kernel-module-parport/lib/modules/4.8.0-yocto-standard/kernel/drivers/parport/parport.ko [arch] The mips64-n32 works since it would set ABIEXTENSION to "n32" so that TARGET_OS is linux-gnun32, and it will skip the check, but "mips64-o32" doesn't set ABIEXTENSION to "o32", "n32" or "32", so the error happend. Skip the check if mips64.*32 matches DEFAULTTUNE can fix the problem. Another way to fix the problem is define ABIEXTENSION to "o32" or "32" for mips64-o32, but that may make things confused since "o32" is purely 32 bit. [YOCTO #10305] (From OE-Core rev: 4e61d8d6f4619dbfaeb5ca642449de7cf4b3e92d) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: explicitly set DL_DIRRoss Burton2016-10-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The eSDK generation assumes that DL_DIR is downloads/ under the build directory, and puts files such as a freshly buily uninative tarball in there expecting bitbake will find it later. Whilst ${TOPDIR}/downloads/ is in fact the default value for DL_DIR in bitbake.conf, and any instances of DL_DIR are removed from the original local.conf, there is still the possibility that other layers could contain a site.conf that assigns DL_DIR. If this happens the errors are quite mysterious as it fails to find the uninative tarball and so the hashes all change, and eSDK building fails. Ensure that this cannot happen by explicitly assigning the DL_DIR that we require, instead of assuming that the default value will be used. [ YOCTO #10439 ] (From OE-Core rev: bc2e6f5eab47e869dbc4a3eacfe759b9b1cacaee) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* live-vm-common.bbclass: Allow to use different kernel image than ↵Martin Jansa2016-10-151-2/+6
| | | | | | | | | | | | | | KERNEL_IMAGETYPE for /vmlinuz * syslinux config hardcodes kernel image as /vmlinuz add warning message when the selected image doesn't exist and allow to select different image with VM_DEFAULT_KERNEL variable (qemuboot.bbclass is using QB_DEFAULT_KERNEL) (From OE-Core rev: e6b21d1b3716ee6f4aec1674e56f06b2963a7968) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image_types.bbclass: add dependency do_image_wic -> do_bootimgEd Bartosh2016-10-151-0/+5
| | | | | | | | | | | | | | | | | | To produce certain types of images wic uses do_bootimg results to assemble final image. For example, it copies BOOT/EFI directory produced by do_bootimg to boot partition for every EFI image. The tricky part of this is that do_bootimg task is not always run, so we can't always make do_image_wic depend on do_bootimg. We only need to do it if do_bootimg present in task graph. Thank to Cristopher Larson for this fix. (From OE-Core rev: 1a961b4becf677c9eb07c5b24a8ddb75044663d1) 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>
* package_tar: avoid chdir warnings and restore cwd after packagingRobert Yang2016-10-151-0/+5
| | | | | | | | | | | Fixed: WARNING: attr-2.4.47-r0 do_package_write_tar: Task do_package_tar changed cwd to /path/to/attr/2.4.47-r0/packages-split/attr-locale-sv (From OE-Core rev: 3753d07c9ff33b9a97aca61ad312b0e283c4c68d) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* insane.bbclass: Additional "mips" and "mipsel" machine definitionsJuro Bystricky2016-10-151-0/+2
| | | | | | | | | | | | | | Add "mips" and "mipsel" to "machdata" table. Although there is a way to add entries to the "machdata" table from a BSP without modifying the insane.bbclass directly, MIPS is already supported in poky and as such the relevant entries should be present in insane.bbclass. (From OE-Core rev: 3ba03d1affa6f647e9a03c8ba4389606a0da8e8b) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-arch.bbclass: Add xtensa and arc into valid_archs tableJuro Bystricky2016-10-151-1/+1
| | | | | | | | | | | Both "arc" and "xtensa" are valid Linux architectures, add them into valid_archs table. (From OE-Core rev: 20d511cd1b7fe4891f7842be12f13a92da433c46) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* pixbufcache: handle gdk-pixbuf not being presentRoss Burton2016-10-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | It's possible - albeit unlikely - that gdk-pixbuf isn't present in the sysroot when a recipe inheriting this class is and the sysroot is finalised. One example would be if the sstate archive has librsvg but not gdk-pixbuf: librsvg will be extracted from the sstate but gdk-pixbuf will be built to "fill in the gap". In this situation the setscene completion hook installed by pixbufcache.bbclass will attempt to execute gdk-pixbuf-query-loaders, but that binary hasn't been installed by gdk-pixbuf yet. Also add gdk-pixbuf-native to DEPENDS in native builds to ensure that the binaries we expect will be present, as it's possible to build loaders without linking to GdkPixbuf. [ YOCTO #10420 ] (From OE-Core rev: 03cdb3366ded46cd760656e4cda0be37c1f82109) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Remove RM_OLD_IMAGE, it's no longer usefulJoshua Lock2016-10-155-20/+1
| | | | | | | | | | | | | | | | Since the move to put image deployment under sstate control in d54339d4b1a7e884de636f6325ca60409ebd95ff old images are automatically removed before a new image is deployed (the default behaviour of the sstate logic). RM_OLD_IMAGE is therefore no longer required to provide this behaviour, remove the variable and its users. (From OE-Core rev: 93631befe8b962bf99524746b49f4ebca336175c) 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>
* classes/externalsrc: re-run do_configure when configure files changePaul Eggleton2016-10-113-0/+26
| | | | | | | | | | | | | | | | | | If the user modifies files such as CMakeLists.txt in the case of cmake, we want do_configure to re-run so that those changes can take effect. In order to accomplish that, have a variable CONFIGURE_FILES which specifies a list of files that will be put into do_configure's checksum (either full paths, or just filenames which will be searched for in the entire source tree). CONFIGURE_FILES then just needs to be set appropriately depending on what do_configure is doing; for now I've set this for autotools and cmake which are the most common cases. Fixes [YOCTO #7617]. (From OE-Core rev: 923fc20c2862a6d75f949082c9f6532ab7e2d2cd) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* update-rc.d.bbclass: ignore init script return codeMarkus Lehtonen2016-10-111-2/+2
| | | | | | | | | | | | | | | | | We need to ignore the return code from the init script 'stop' command in the preinst and prerm scriptlets. Otherwise package upgrade or deinstallation (at least when opkg is used) is likely to fail if the daemon is not running. That is because an init script possibly returns '1' if you try to stop a service that is not running which, in turn, causes the scriptlet to fail which, in turn, causes the package (de-)installation to fail. [YOCTO #10299] (From OE-Core rev: daa3c266a7ffa060b52381fa00df518102fceda8) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* insane: display names instead of ELF machine numbersRoss Burton2016-10-111-2/+2
| | | | | | | | | | | The 'arch' QA test currently simply outputs the ELF machine field as a number which isn't helpful. Display this as a human-readable name to make it clearer to the user what the problem is. (From OE-Core rev: 607a2a1de4b77818c3e801a4de7ff0888229e036) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* archiver: fix gcc-source handlingSaul Wold2016-10-111-2/+3
| | | | | | | | | | | | | The source archiver was not handling the gcc-source target correctly, since it uses the work-shared directory, we don't want to unpack and patch it twice, just as the comments say, but the code was not there to check for the gcc-source target. [YOCTO #10265] (From OE-Core rev: bbac0699ceadb7a25a60643fb23dffce8b4d23d0) Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* testimage: disable build tests for qemumips and qemumips64Joshua Lock2016-10-091-0/+6
| | | | | | | | | | | | | | | | | It's not uncommon for qemumips[64] builds on the Yocto Project autobuilder to fail during Sanity Tests after a very long timeout period. This is due to the MIPS emulation in QEMU being slow and some of the build tests taking a very long time on MIPS machines. This patch works around this slowness by disabling the more complex build tests for QEMU MIPS machines. [YOCTO #10340] (From OE-Core rev: 4a1c04c0d509b2cda9b2ccd5a80523c05fa279c6) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* update-rc.d.bbclass: check that init script is executable before running itMarkus Lehtonen2016-10-071-1/+1
| | | | | | | | | | | | | Check that the init script that is going to be called in the prerm() script really exists and is executable. There might be a packaging bug or the script might've been removed already earlier in prerm(). [YOCTO #10299] (From OE-Core rev: aabb87c9dbd60fe9467ca0354ec05c275a3f1b1a) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-22 09:12:56 +0000