summaryrefslogtreecommitdiffstats
path: root/meta
Commit message (Collapse)AuthorAgeFilesLines
* pigz: Update SRC_URIRichard Purdie2016-10-051-0/+2
| | | | | | | | | | Upstream have released a new tarball and removed the old one. Revert to the Yocto Project source mirror instead, preserving the upstream version check. (From OE-Core rev: 839b17ffd96abff3e9cf47fb4a6d680637c865b1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* perf: Fix to obey LD failureSujith Haridasan2016-10-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch brings the last bit from meta-mentor for the perf to build successfully with minnowmax BSP. The meta-mentor commit for the same is: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/meta-mentor-staging?id=a8db95c0d4081cf96915e0c3c4063a44f55e21cc The previous fix: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/perf?id=ef942d6025e1a339642b10ec1e29055f4ee6bd46 was incomplete and was not submitted upstream. And due to that this change is required. When built on minnowmax ( machine name: intel-corei7-64), an error is noticed during the do_compile: /home/sujith/codebench-linux-install-2015.12-133-i686-pc-linux-gnu/codebench/bin/i686-pc-linux-gnu-ld: Relocatable linking with relocations from format elf64-x86-64 (/home/sujith/MEL/dogwood/build-minnowmax/tmp/work/intel_corei7_64-mel-linux/perf/1.0-r9/perf-1.0/fd/array.o) to format elf32-i386 (/home/sujith/MEL/dogwood/build-minnowmax/tmp/work/intel_corei7_64-mel-linux/perf/1.0-r9/perf-1.0/fd/libapi-in.o) is not supported This change help fix the issue. (From OE-Core rev: 122ae03e2f1a2252a6914d51087531557f9a08f2) Signed-off-by: Sujith Haridasan <Sujith_Haridasan@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sanity: Update minimum version requirement to 1.31.2Richard Purdie2016-10-051-1/+1
| | | | | | | | | This is so we can depend on the bb event threading fix which prevents event pipe corruption. (From OE-Core rev: 728269fe2839533a05e7f2532209466dc34e4174) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* alsa-lib: allow building ARM thumb againAndreas Müller2016-10-051-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The directive mentioned in the comment was removed in: commit 326c6802e49e5499e16cf141e1cdb0360fce14aa Author: Riku Voipio <riku.voipio@linaro.org> Date: Fri Feb 7 15:38:58 2014 +0200 alsa-lib: heavy pcm atomics cleanup The following patch comes from the realization that at least ARM code for atomics is quite broken and nobody has cared for a decade. A quick dive shows that only snd_atomic_{read,write}_{begin,end} appear to be used widely. These are implemented using wmb/rmb. Only other use of atomic functions is in pcm_meter.c. The #SND_PCM_TYPE_METER plugin type appears rarely, if ever, used. I presume these days anyone who wants a meter/scope will do in pulseaudio layer instead of alsa. It would seem better fit to have pcm_meter in alsa-plugins instead of alsa-lib, but I guess that would be an ABI break... So instead, I'm proposing here 1. Removal of all hand-crafted atomics from iatomic.h apart from barriers, which are used in snd_atomic_{read,write}_{begin,end}. 2. Using __sync_synchronize as the default fallback for barriers. This has been available since gcc 4.1, so it shouldn't be a problem. 3. Defining the few atomics used by pcm_meter.c withing pcm_meter.c itself, using gcc atomic builtins[1]. 4. Since gcc atomic builtins are available only since gcc 4.7, add a check for that in gcc configure.in, and don't build pcm meter plugin if using older gcc. The last point has the impact, that if there actually is someone who 1) uses the meter plugin 2) wants to upgrade to 2014 alsa-lib 3) but does not want to use a 2012+ gcc - that someone will be inconvenienced. Finally remove the unneeded configure check for cpu type. We can trust the gcc to set right flags for us. [1] http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html Signed-off-by: Riku Voipio <riku.voipio@linaro.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (From OE-Core rev: dd442652afef1f83fc6c9651976cd3ba28c83c85) Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* parselogs.py: Add disabling eDP error to x86_common whitelistCalifornia Sullivan2016-10-051-0/+1
| | | | | | | | | | | | | | The NUC6 firmware tells the kernel to try and initialize an embedded DisplayPort it does not have, causing this warning. Its harmless, so just whitelist it. Fixes [YOCTO #9434]. (From OE-Core rev: 4c3fb7f63aad4a5d1b9720c76091cd0646859c2a) Signed-off-by: California Sullivan <california.l.sullivan@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.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>
* Revert "gst-player: Disable visualizations"Jussi Kukkonen2016-10-052-37/+0
| | | | | | | | | | | | This reverts oe-core commit b79d1bf49b56a97216fb719ac19e4dd9022f15b4. Now that xf86-video-intel is upgraded, visualizations can be enabled by default. (From OE-Core rev: c0a22a8d3e5d44ae3fba14a52582d39cfc600318) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* xf86-video-intel: Upgrade to recent gitJussi Kukkonen2016-10-056-233/+10
| | | | | | | | | | | | | | | | Upgrade from the latest snapshot to a recent git revision. Without this xvideo does not work on skylake: Backporting the specific fixes turned out to be too complex. Remove patches that are in upstream already, rebase disable-x11-dri3.patch. Fixes [YOCTO #10041] (From OE-Core rev: 1e295903c89630d5813a0d924a3da47b52f377ac) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* matchbox-panel-2: Fix small systray icon drawingJussi Kukkonen2016-10-052-1/+37
| | | | | | | | | | | | | | Add patch to pack systray icons so that their drawing area is the size they expect (otherwise GtkStatusIcon based systray items can end up drawing "tiled", looking like 1.5 icons instead of a single icon). Fixes [YOCTO #9995] (From OE-Core rev: 6db56c4fd1f510a2d9ece30329e04ae591521906) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Revert "connman-gnome: StatusIcon adapts to size changes"Jussi Kukkonen2016-10-051-121/+15
| | | | | | | | | | | | | | | | | | The aim of the original commit was to make connman-gnome load the icons at the exact size of the systray. There are two problems with this: * There are not enough icon sizes provided to make the scaling look good at most sizes (including current panel size) * Both connman-gnome and mb-panel have bugs in the icon size update code and using scaling to exact size makes these much more visible (See bug 9995 for example). The problems the original commit tried to fix can be worked around with better packing in matchbox-panel-2. (From OE-Core rev: 82a34a770ad36fb370fff4dca66956fb47f1140c) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Revert "attr: Added ncurses to depends"Ross Burton2016-10-051-1/+1
| | | | | | | | | | | | There doesn't appear to be any reason to keep this dependency on ncurses in attr, so remove it. This reverts commit 7c474dc3d65bb3f71b375d36d81959cb405be80a. (From OE-Core rev: 53a0bf4ed3e0c4aed91242a0608e6c0693b3adfa) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* base-files: don't export TZ="UTC" from /etc/profileAndre McCurdy2016-10-051-6/+0
| | | | | | | | | | | | | | | If no /etc/localtime (or /etc/TZ for uclibc) is found, then the libc will default to UTC, so setting UTC as a fallback default via the TZ environment variable is redundant. Since having the TZ environment variable set causes /etc/localtime to be ignored, it can cause confusion if /etc/localtime is added interactively after /etc/profile has been run. (From OE-Core rev: 98b6420952cbf73ddd1318f36c68d575c330eb71) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* oeqa/selftest: Update test after fetcher error changesBenjamin Esquivel2016-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The following poky commit: 4359ef08 base.bbclass: Use bb.fatal() instead of raising FuncFailed changed the way the fetcher error is reported. Previous reporting: ...Function failed: Fetcher failure for URL:... New reporting: ...Fetcher failure for URL:... Updating how the check is done fixes the test error and accurately confirms the tested scenario for test_invalid_recipe_src_uri. [YOCTO #10370] (From OE-Core rev: 197da17dc97cef87375ae9190c6d1495e1c615b9) Signed-off-by: Benjamin Esquivel <benjamin.esquivel@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* systemtap: rationalise dependenciesRoss Burton2016-10-053-4/+33
| | | | | | | | | | | | | | | | | | | | | | Boost is an optional dependency but avoid build non-determinism by adding it as DEPENDS. It is only for the shared pointer types so can be disabled explicitly if required. Turn sqlite into a PACKAGECONFIG. Add a patch for the "monitor" feature to control the optional dependencies on ncurses and json-c. Previously this was enabled for target only but enable it everwhere now that json-c is available for native/nativesdk. Of course all of this was predicated about systemtap needing systemtap-native to be built, but it turns out that this dependency is due to oe-core 507bd2 which adds systemtap-native as DEPENDS for convenience. Remove this dependency, if the user wants systemtap-native then they can build it explicitly. (From OE-Core rev: fb9dc1cf7a2d6d5e22beb68f17b4c9c8d1136e37) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* json-c: add BBCLASSEXTEND for native and nativesdkRoss Burton2016-10-051-0/+2
| | | | | | | (From OE-Core rev: c2c053a016d9c146e46fc617cdbd9e8b34ea955f) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-libc-headers: if_tunnel: remove include of if/ip/in6.hBruce Ashfield2016-10-042-0/+34
| | | | | | | | | | | | | commit 1fe8e0f074c [include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h] breaks the builds of net-tools. We remove the new includes until such a time that userspace can adapt to the new kernel headers. (From OE-Core rev: cd3720317abaff1e857cfb6b1e2a3741baf8f944) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto/4.1/4.4: remove innappropriate standard/base patchesBruce Ashfield2016-10-046-23/+23
| | | | | | | | | | | | | | | | | | | Before standard/intel/* was created in the 4.1 and 4.4 kernel trees, some patches were merged to standard/base to add features/support for intel platforms. While this isn't entirely bad, there have been some compile issues reported in some configurations. Since we don't need these commits on standard/base, we can relocate them to make standard/base upstream clean. This commit removes those patches from standard/base, and restores then to the standard/intel/* branches. (From OE-Core rev: 2c19e6378697141992c9bd7ff2bd4d57a4f9fe9b) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-libc-headers: fix in/if.h includesBruce Ashfield2016-10-042-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following kernel commits broke the compilation of ppp, due to redefined structures. Nothing else breaks in userspace with or without these uapi changes, so we revert them to keep everything building. commit 05ee5de7451796cf9a8aeb2f05a57790d4fd2336 Author: Mikko Rapeli <mikko.rapeli@iki.fi> Date: Mon Aug 22 20:32:42 2016 +0200 include/uapi/linux/if_pppol2tp.h: include linux/in.h and linux/in6.h Fixes userspace compilation errors like: error: field <E2><80><98>addr<E2><80><99> has incomplete type struct sockaddr_in addr; /* IP address and port to send to */ ^ error: field <E2><80><98>addr<E2><80><99> has incomplete type struct sockaddr_in6 addr; /* IP address and port to send to */ Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> commit eafe92114308acf14e45c6c3d154a5dad5523d1a Author: Mikko Rapeli <mikko.rapeli@iki.fi> Date: Mon Aug 22 20:32:43 2016 +0200 include/uapi/linux/if_pppox.h: include linux/in.h and linux/in6.h Fixes userspace compilation errors: error: field <E2><80><98>addr<E2><80><99> has incomplete type struct sockaddr_in addr; /* IP address and port to send to */ error: field <E2><80><98>addr<E2><80><99> has incomplete type struct sockaddr_in6 addr; /* IP address and port to send to */ Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> (From OE-Core rev: 12451a412fb7b5706c1553618ee7b704234876cc) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto/4.8: update to 4.8 -final releaseBruce Ashfield2016-10-043-16/+16
| | | | | | | (From OE-Core rev: 7b3ae4631e2c68926b254d0d26608636a492b952) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-libc-headers: update to 4.8 finalBruce Ashfield2016-10-041-4/+3
| | | | | | | | | | We've been using a -rc4 variant of the libc-headers, now that 4.8 has been released, we switch to the final tgz of the headers. (From OE-Core rev: d7cef1c71dedacda86426a1f9f815a8b7108857b) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto/4.4: update to v4.4.22Bruce Ashfield2016-10-043-16/+16
| | | | | | | (From OE-Core rev: 286d893f9e7caed06035f7916492a74e0212df6a) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto/4.1: update to 4.1.33Bruce Ashfield2016-10-043-16/+16
| | | | | | | (From OE-Core rev: af4e9d92ae23f0e668da4732ef79cd1f1bb6fc1f) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto/4.8: mmc configuration for x86*Bruce Ashfield2016-10-043-3/+3
| | | | | | | | | | | | | | | | Updating the common-pc* configuration to have the following mmc configs available by default: meta/common-pc-64: use mmc-sdhci feature meta/common-pc: use mmc-sdhci feature meta: add mmc/mmc-sdhci feature meta: add mmc/mmc-block feature meta: add mmc/base feature (From OE-Core rev: 024ee2f47ebac39438f87069d48f5e34c9c81891) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: 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: ff310dd103e16a5345a4bb48090af05f50171de3) Signed-off-by: Ulf Magnusson <ulfalizer@gmail.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>
* binutils: apply RPATH fixes from our libtool patchesRoss Burton2016-10-042-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't autoreconf/libtoolize binutils as it has very strict requirements, so extend our patching of the stock libtool to include two fixes to RPATH behaviour, as part of the solution to ensure that native binaries don't have RPATHs pointing at the host system's /usr/lib. This generally doesn't cause a problem but it can cause some binaries (such as ar) to abort on startup: ./x86_64-pokysdk-linux-ar: relocation error: /usr/lib/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference The situation here is that ar is built and as it links to the host libc/loader has an RPATH for /usr/lib. If tmp is wiped and then binutils is installed from sstate relocation occurs and the loader changed to the sysroot, but there remains a RPATH for /usr/lib. This means that the sysroot loader is used with the host libc, which can be incompatible. By telling libtool that the host library paths are in the default search path, and ensuring that all default search paths are not added as RPATHs by libtool, the result is a binary that links to what it should be linking to and nothing else. [ YOCTO #9287 ] (From OE-Core rev: 6b201081b622cc083cc2b1a8ad99d6f7d2bea480) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* binutils: fix typo in libtool patchRoss Burton2016-10-041-2/+1
| | | | | | | | | There was a clear typo in a function name, correct it. (From OE-Core rev: dcf44e184a807d76463a3bf1b2315e80b9469de3) Signed-off-by: Ross Burton <ross.burton@intel.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>
* machine-sdk: Clear ABIEXTENSION to avoid sstate checksum mismatch issuesRichard Purdie2016-10-013-0/+3
| | | | | | | | | When switching MACHINE, nativeksdk recipes could end up being rebuilt. Clear ABIEXTENSION to avoid this problem and ensure sstate checksum consistency. (From OE-Core rev: 21cc2a3f63ea260dbf6b50e2fd4dd50cacdd9935) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-14 23:42:07 +0000