summaryrefslogtreecommitdiff
path: root/meta/classes
AgeCommit message (Collapse)AuthorFiles
2017-04-12sstate.bbclass: check if mirror directory is writableEd Bartosh1
Commit 51edde653707e7a3cd2186082458f01f32cd1996 makes a wrong assumption that SSTATE_MIRRORS have write permissions. A mirror is by definition outside of it's user control. In my use case it happens I does not have permissions to update the access time of the dereferenced symbolic-link file. Checked if file is writable before changing its atime. Thanks to Paulo Neves for the patch. [YOCTO #11307] Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-12qemuboot: write native sysroot of qemu-helper into qemuboot.confEd Bartosh1
Native sysroot of qemu-helper contains all required tools (qemu-system and tunctl atm) for runqemu to work. It's not removed by rm_dir and should always exist. It makes sense to write it into qemuboot.conf to make runqemu to use it as a default directory for native tools. This should also speed up runqemu as it doesn't need to run to run 'bitbake qemu-helper -e' to get its native sysroot. [YOCTO #11266] [YOCTO #11193] Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-12meta: classes: Add building dir to uImage creationMylène Josserand1
On the do_uboot_mkimage task from kernel-uimage.bbclass, in case KEEPUIMAGE is different than the default "yes" value, the uboot-mkimage command fails because the path of the created uImage does not exist. On this task, we are under the BUILDDIR so there is no folder arch/<ARCH>/boot. Add the ${B} (for kernel build directory) as prefix to this folder fixes the problem. Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-12blacklist.bbclass: fix for multilibRobert Yang2
* Fixed: The netmap has been blacklisted in meta-networking/recipes-kernel/netmap/netmap_git.bb, but lib32-netmap still can be built (suppose it doesn't depend on another broken recipe netmap-modules, it is a little complicated, will talk below): $ bitbake lib32-netmap This is because of the old code masks on bb.event.ConfigParsed which can only handle global blacklist, netmap sets blacklist in the recipe, so it can't be handled, and lib32-netmap can be built. which was incorrect: blacklist_multilib_eventhandler[eventmask] = "bb.event.ConfigParsed" Move multilib code into multilib.bbclass can fix the problem easily: $ bitbake lib32-netmap ERROR: Nothing PROVIDES 'lib32-netmap' ERROR: lib32-netmap was skipped: Recipe is blacklisted: BROKEN: <foo> * Not fixed Another problem is netmap-modules has also been blacklisted in the recipe, and the recipe inherits module.bbclass, so multilib.bbclass doesn't handle it as the code shows: # There should only be one kernel in multilib configs # We also skip multilib setup for module packages. provides = (e.data.getVar("PROVIDES") or "").split() if "virtual/kernel" in provides or bb.data.inherits_class('module-base', e.data): raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel") And netmap-modules provides lib32-netmap-modules which is handled in multilib_global.bbclass, so bitbake lib32-netmap-modules can't show the blacklist message: $ bitbake netmap-modules ERROR: Nothing PROVIDES 'netmap-modules' ERROR: netmap-modules was skipped: Recipe is blacklisted: BROKEN: <foo> ERROR: netmap-modules was skipped: We shouldn't have multilib variants for the kernel $ bitbake lib32-netmap-modules ERROR: Nothing PROVIDES 'lib32-netmap-modules'. Close matches: netmap-modules netmap-modules lib32-fbset-modes Note the different messages between netmap-modules and lib32-netmap-modules. This is because multilib.bbclass doesn't handle the "module" recipe so there is no PN called lib32-netmap-modules, therefore blacklist.bbclass can't handle it. Note, there are two "netmap-modules" which needs to be fixed later. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-12native/nativesdk: Use fixed DISTRO_FEATURESJussi Kukkonen3
There seems to be little advantage to letting distro features affect native builds. There is a significant disadvantage: a change to DISTRO_FEATURES will trigger a lot of unnecessary native tasks. In a test like this: $ bitbake core-image-minimal # append " systemd" to DISTRO_FEATURES $ bitbake core-image-minimal The latter build takes 44 minutes (28%) of cpu-time less with this patch (skipping 135 native tasks). Sadly wall clock time was not affected as glibc remains the bottleneck. Set native distro features to DISTRO_FEATURES_NATIVE appended with an intersection of DISTRO_FEATURES and DISTRO_FEATURES_FILTER_NATIVE. Current default values (baitbake.conf) are * DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation" (as gtk-doc-native has much less dependencies when built without it) * DISTRO_FEATURES_NATIVE ?= "x11" (to enable native UIs even if target does not containe them) Do the variable setting in native_virtclass_handler() because otherwise it could still be overridden by appends and the feature backfilling. Shuffle the early returns so DISTRO_FEATURES gets set as long as the packagename ends with "-native". Add similar variables for nativesdk. To make nativesdk work we need to enable the locale options so nativesdk-glibc-locales can build and to avoid the init manager check in the nativesdk case so add those fixes. Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11runqemu: do not rely on grepping imagesRobert Yang1
Fixed when the image is large and not enough memory: grep: memory exhausted Aborted [YOCTO #11073] Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11staging: Fix sysroot problem with populate_sysroot dependencies on do_fetchRichard Purdie1
Dependencies on svn:// urls were failing as the cleandirs on do_fetch was destroying any sysroot setup by the extend_recipe_sysroot function. Add code so that if the task do_fetch, we move the cleandirs to a separate function before the extend_recipe_sysroot prefunc else we'd wipe out the sysroot we just created. This allows fetcher do_populate_sysroot dependencies to work correctly again. I did try various other approaches and a seperate function with cleandirs was the cleanest way to add this without code duplication or too much complexity. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11toaster: fix SDK artifact captureDavid Reyna1
Use the TaskArtifacts event to scan the SDK and ESDK manifests to cleanly collect the respective artifact files. The previous method was broken when the SDK file deployment moved from the do_populate_sdk[_ext] tasks to their sstate tasks. That method is disabled (but not yet removed) in preparation for the rest of refactor work for the parent #10283 work. [YOCTO #10850] Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11classes/buildhistory: save output file signatures for sstate tasksPaul Eggleton1
Save a file per task listing sha256sums for each file staged, i.e. the output of the task. Some caveats: 1) This only covers sstate tasks since it uses SSTATEPOSTUNPACKFUNCS, however those are generally the most interesting in terms of output anyway. 2) The signature is taken before applying any relocations, so any relocated files will actually have different signatures, but that's churn that you probably won't want to see here. 3) At the moment if you run the same build twice without sstate you will very likely see changes in the output for certain tasks due to things like timestamps being present in the binary output. Fixing that is a general Linux ecosystem problem - see this page for our efforts to resolve it on our side: https://wiki.yoctoproject.org/wiki/Reproducible_Builds NOTE: you need to set your BUILDHISTORY_FEATURES value to include "task" to enable collection of these signatures as it is is disabled by default. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11classes/uninative: set SSTATEPOSTUNPACKFUNCS[vardepvalueexclude] properlyPaul Eggleton1
Append to the value with appendVarFlag() instead of setting it outright, so that we can also append to it in other places. Accordingly, this varflag is pipe-separated (since we want to be able to exclude any string fragment, in this case including the leading space), thus put a leading pipe character to play nicely with any existing value. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11classes/buildhistory: write out task signatures on every buildPaul Eggleton1
If we want to determine what changed since the last build, one angle from which to look at it is to check the signatures. However, if we don't actually have the signatures from the last build we don't have anywhere to start. Save the signatures on each build in order to give us the starting point. NOTE: you need to set your BUILDHISTORY_FEATURES value to include "task" to enable collection of these signatures as it is is disabled by default. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11buildhistory.bbclass: do not influence sstate of do_rootfsPatrick Ohly1
Enabling or disabling buildhistory caused a rebuild of images, which is undesirable. For example, it prevented image reuse from a main build with buildhistory in a following oe-selftest where buildhistory must be disabled. The reason are the additional ROOTFS_POSTUNINSTALL_COMMAND and ROOTFS_POSTUNINSTALL_COMMAND entries. Those need to be excluded both via vardepvalueexclude and vardepsexclude. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11Revert "staging: Fix sysroot problem with populate_sysroot dependencies on ↵Richard Purdie1
do_fetch" There seems to be an issue with the patch, revert for now. This reverts commit cd5e0a32184d98beb8d81e6b5527166d3ca4fb3c.
2017-04-10staging: Fix sysroot problem with populate_sysroot dependencies on do_fetchRichard Purdie1
Dependencies on svn:// urls were failing as the cleandirs on do_fetch was destroying any sysroot setup by the extend_recipe_sysroot function. Add code so that if the task do_fetch, we move the cleandirs to the extend_recipe_sysroot task else we'd wipe out the sysroot we just created. This allows fetcher do_populate_sysroot dependencies to work correctly again. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-08cross-canadian.bbclass: override TARGET_* flagsMing Liu1
Some TARGET_* flags are being exported in bitbake.conf currently, so they are impacting all the tasks of a cross-canadian recipe even they are not in use at all. This can lead a lot of churn when the cross-canadian sysroot are shared by machines while they have defined different TARGET_* flags. Fix it by overriding with BUILDSDK_* flags. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-08nativesdk.bbclass: override TARGET_* flagsMing Liu1
Some TARGET_* flags are being exported in bitbake.conf currently, so they are impacting all the tasks of a nativesdk recipe even they are not in use at all. This can lead a lot of churn when the nativesdk sysroot are shared by machines while they have defined different TARGET_* flags. Fix it by overriding with BUILDSDK_* flags. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-08crosssdk.bbclass: override TARGET_* flagsMing Liu1
Some TARGET_* flags are being exported in bitbake.conf currently, so they are impacting all the tasks of a crosssdk recipe even they are not in use at all. This can lead a lot of churn when the crosssdk sysroot are shared by machines while they have defined different TARGET_* flags. Fix it by overriding with BUILD_* flags. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-08cross.bbclass: override TARGET_* flagsMing Liu1
Some TARGET_* flags are being exported in bitbake.conf currently, so they are impacting all the tasks of a cross recipe even they are not in use at all. This can lead a lot of churn when the cross sysroot are shared by machines while they have defined different TARGET_* flags. And sometimes it even causes "Taskhash mismatch" errors. Fix it by overriding with BUILD_* flags. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-08sstate: Skip glibc do_stash_locale and gcc do_gcc_stash_builddir tasksRichard Purdie1
We never need these tasks as dependencies of other sstate tasks since they're only ever needed to build artefacts so we can always skip them and save some time/space. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-08license.bbclass: improve reproducibilityJuro Bystricky1
Two identical builds can end up having deploy/licenses folders that differ. This is observed in cases where there are several different license files of the same name in different folders, i.e. "COPYING". In those case we have to differentiate the files somehow and we do it via file expensions such as COPYING.0, COPYING.1. However, which file will get which extension is presently random. This means, for example, that COPYING.0 in one build is the same as COPYING.1 in the other (and vice versa). Although there is mothing wrong with this, for the sake of binary reproducibility it is preferable to have a deterministic outcome. Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-08package.bbclass: add CONFFILES to pkgdataDavid Vincent1
Emit CONFFILES variable in pkgdata, or else the get_conffiles function will return 'None' for some packages instead of the expected value. This is especially true for optional module packages. Signed-off-by: David Vincent <freesilicon@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-08package_ipk.bbclass: Replace empty lines in DESCRIPTION with '.'Mariano Lopez1
opkg uses empty lines as separator for next package and if an ipk file was packaged with empty lines in DESCRIPTION opkg won't be able to handle such ipk file, this happens at execution time. This commit will replace empty lines in DESCRIPTION with a '.' when generating an ipk package to avoid this issue. [YOCTO #10677] Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-05kernel.bbclass: move in addtask kernel_link_images statement from ↵Ming Liu1
linux-yocto.inc Add kernel_link_images task in kernel.bbclass instead of adding it in linux-yocto.inc, or else the recipes inheriting kernel.bbclass might run into implicit dependency issues. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-05sanity: explain where TMPDIR is if we're telling the user to delete itRoss Burton1
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-05recipe_sanity: Drop now unused FILESDIRRichard Purdie1
FILESDIR is long dead and unreferenced pretty much anywhere now, drop these sanity references too. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-31kernel.bbclass: introduce INITRAMFS_IMAGE_NAMEMing Liu2
It defaults to ${INITRAMFS_IMAGE}-${MACHINE} if INITRAMFS_IMAGE is not empty. This allows the end users to be able to override the initramfs image name with a customized value. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-31kernel.bbclass: fix a typoMing Liu1
In a addtask statement, do_strip should be strip. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-31distutils3.bbclass: Fix path to python for scriptsSerhii Popovych1
This change is similar to the recently introduced change to the distutils.bbclass fixing shebang line in python scripts for nativesdk class builds. v2: Rebased on top of new head. Cc: XE-Linux <xe-linux-external@cisco.com> Signed-off-by: Serhii Popovych <spopovyc@cisco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-31distutils.bbclass: Fix path to python for scriptsSerhii Popovych1
Commit 11229de (distutils: Replacing path to native python by path to python in the image to support python packages with console-script setup) replaces path to python-native with path to the python interpreter in the target image. However on nativesdk builds ${bindir} expanded to the ${SDKPATHNATIVE}${prefix_nativesdk} making shebang line pointing to the absolute path to env(1) in SDKPATHNATIVE which may not be present if coreutils isn't part of nativesdk. On the other hand commit cf63d90 (bitbake.conf: Define USRBINPATH globally instead of individually) introduces USRBINPATH variable which has correct value regarding build class and intended for this use case. v2: Rebased on top of new head. Cc: XE-Linux <xe-linux-external@cisco.com> Signed-off-by: Serhii Popovych <spopovyc@cisco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-30base.bbclass: ensure HOSTTOOLS links point to executablesRoss Burton1
Use the new executable argument to bb.utils.which() to ensure that the symlinks point to executable files and not for example directories with the right name which happened to be on $PATH. [ YOCTO #11256 ] Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-30multilib_header: Update wrapper to handle arm 32/64 bitRichard Purdie1
Having arm 32/64 bit headers coexisting turns out to be tricky. Unfortunately our wrapper works using wordsize.h and this differs on arm so we can't use it. Therefore replicate the logic here for arm. I did look into writing our own wordsize.h but we also need to remap kernel headers on arm and since wordsize.h comes from libc, that doesn't work for kernel headers. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-30ccache: Use MULTIMACH_TARGET_SYS not HOST_SYSRichard Purdie1
I suspect this was a typo and that TARGET_SYS makes more sense here. Its also the only remaining user of MULTIMACH_HOST_SYS in OE-Core. Change it. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-30sanity: Drop obsolete TMPDIR ABI conversionsRichard Purdie1
When we get to version 12 we have a hard break as we can't convert to newer versions. There is no point in running the old conversions on an old tmpdir only to hit that block. Remove all the old conversions to avoid that and make things clearer. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-30populate_sdk_ext.bbclass: enhance compatibility with rm_work.bbclassPatrick Ohly1
"bitbake -c populate_dsk_ext" must not trigger do_rm_work, because it is impossible to declare that the additional tasks activated by "-c populate_dsk_ext" must run before do_rm_work. When do_populate_dsk_ext and do_rm_work are both active, the resulting race condition breaks do_populate_dsk_ext. The existing bitbake dependencies can't be used for that, because "addtask populate_dsk_ext before do_rm_work" would then always execute populate_dsk_ext also in normal builds. do_populate_dsk_ext triggers do_rm_work indirectly through the dependency on do_build of the SDK_TARGETs. Using the new do_build_without_rm_work instead (when available, with do_build as before if not) avoids the problem. However, one has to be careful to not trigger do_rm_work in the same build in some other way. "bitbake core-image-sato:do_populate_sdk_ext core-image-sato:do_build" still fails, for example. Doing one after the other works. Fixes: [YOCTO 11042] Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-30rm_work.bbclass: introduce do_build_without_rm_workPatrick Ohly1
Some classes, for example populate_sdk_ext.bbclass, must be able to trigger a full build of a recipe without also triggering do_rm_work. They cannot depend on do_build anymore, because that would trigger do_rm_work. Instead, do_build_without_rm_work can be used. It has the exact same dependencies as do_build, minus do_rm_work and do_rm_work_all. This may also be useful in a test build of a recipe where one wants to preserve the work directory without having to modify configuration settings: bitbake foobar:do_build_without_rm_work Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-28systemd-boot: write startup.nshChristopher Larson1
This aligns with the behavior of grub-efi and gummiboot, and is needed to fix auto-boot of intel-corei7-64 for non-GPLv3 builds. Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-28oeqa: QEMU_USE_KVM can list machinesPatrick Ohly1
Previously, QEMU_USE_KVM=True enabled the use of kvm only when "x86" was in the MACHINE name. That is too limiting, because for example intel-corei7-64 can also use kvm but it wasn't possible to enable that without changing OE-core. That traditional usage is still supported. In addition, QEMU_USE_KVM can be set to a list of space-separated MACHINE names for which kvm is to be enabled. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-28dnf: move the entire dnf/rpm4 stack to Python 3Alexander Kanavin1
[YOCTO #11180] Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-28insane.bbclass: error if file-rdeps not metStephano Cetola1
Missing runtime dependencies should result in an error rather than a warning. Indeed, if RPM is listed in PACKAGE_CLASSES, it will throw an error rather than install packages with missing dependencies. This functionality should be consistent across package types. This patch ensures that an error will be thrown. [YOCTO #10949] Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-27classes: Replace "if test" file tests with POSIX file testsuninative-1.6Robert P. J. Day9
In entire meta/classes/ directory, replace shell tests of the form "if test -? ..." with POSIX tests of the form "if [ -? ... Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-27autotools.bbclass: Replace "grep ... >/dev/null" with "grep -q"Robert P. J. Day1
For aesthetic style reasons, use "grep -q" instead of ">/dev/null". Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-26image_types: perform fsck on created ext imageEnrico Jorns1
When performing a file system check, the image created with mkfs will trigger Pass 3A ('Optimizing directories') which turns the file system into state "changed" (EXT2_FLAG_CHANGED). This will let fsck request a reboot by setting the return code flag "2". The result of this is that each ext-image built with oe-core will trigger a reboot during the first time an fsck is triggered. A common case where this might occur is when fsck detects having a future superblock write time. This always happens when booting a newly created ext4 rootfs with a target that does not have a recent time set. This patch moves the initial fsck run that performs the optimization from the target to the host system and thus prevents the target from performing an avoidable reboot. Signed-off-by: Enrico Jorns <ejo@pengutronix.de> Signed-off-by: Ulrich Ölmann <uol@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-23staging: Remove uninstalled dependencies from sysrootsRichard Purdie1
Currently, if something is added to a sysroot, its hash remains unchanged, and it continues to be buildable, it doesn't get removed from the sysroot. This patch handles the case where something is removed from DEPENDS or [depends]. It does introduce its own issue where something could get removed even though some other task in parallel may have the same requirement. This case should be extrememly rare and fixing the more common DEPENDS removal is likely the bigger win though. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-23staging: Update extend_recipe_sysroot vardepsexclude after code changesRichard Purdie1
Changed were made to the code but not reflected in vardepsexclude, fix this. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-23staging: Drop BB_SETSCENE_VERIFY_FUNCTION2Richard Purdie1
The original description for this was: """ Since we clean out do_populate_sysroot if do_configure runs, don't allow do_populate_sysroot_setscene functions if we're going to run do_configure. """ With RSS, we don't need to clean do_populate_sysroot any more. Since we no longer do that, this function also has no purpose any longer and can also be removed. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-23staging: Drop do_configure clean prefuncRichard Purdie1
With recipe specific sysroots its now pointless to do this, may as well save the cpu cycles. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-23staging: Drop BB_SETSCENE_VERIFY_FUNCTION since it was replacedRichard Purdie1
BB_SETSCENE_VERIFY_FUNCTION2 replaced BB_SETSCENE_VERIFY_FUNCTION and due to our minimum bitbake requirements there is no point in retaining the older version any more. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-23native.bbclass: clear MACHINE_FEATURESAndre McCurdy1
Try to avoid native recipes accidentally being dependent on MACHINE_FEATURES. This simple change doesn't prevent MACHINE_FEATURES set via MACHINE_FEATURES_BACKFILL sneaking through, but it's better than nothing. Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-23core-image.bbclass: update available IMAGE_FEATURESTrevor Woerner1
Update the list of available IMAGE_FEATURES with the sub-features of 'debug-tweaks' and add 'splash'. Signed-off-by: Trevor Woerner <twoerner@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-22sign_rpm.bbclass: do not set/use RPM_GPG_PUBKEYAlexander Kanavin1
This is entirely unnecessary (we can ask the signer backend to export the key to a file when needed), and was causing confusing selftest failures due to the variable being set from two different places. [YOCTO #11191] Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>