On 08/23/2017 10:40 AM, Khem Raj wrote:
On Wed, Aug 23, 2017 at 5:37 AM, Bruce Ashfield
<bruce.ashfi...@windriver.com> wrote:
On 08/22/2017 11:40 PM, Khem Raj wrote:
On Sun, Aug 20, 2017 at 7:58 PM, Bruce Ashfield
<bruce.ashfi...@windriver.com> wrote:
There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.
This meant that someone looking for "qemux86foo" (which is an
invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.
[YOCTO: #11878]
Signed-off-by: Bruce Ashfield <bruce.ashfi...@windriver.com>
---
meta/classes/kernel-yocto.bbclass | 3 +++
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 1ca0756c4959..3c6df92131bc 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -143,6 +143,9 @@ do_kernel_metadata() {
# expand kernel features into their full path equivalents
bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
-DKTYPE=${LINUX_KERNEL_TYPE})
+ if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
+ bbfatal_log "Could not locate BSP definiton for
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+ fi
this breaks non linux-yocto kernels which are using the kernel infra
from OE-Core
since they may not have kmeta structure and bsp_definition may be empty
for them
so either provide a way to override bsp_definition to something dummy or
infact
fall back to dummy by default with a warning or note during parse
time. fatal is a bit harsh here.
Fair enough. I can make it a warning versus fatal, or only make it
fatal if I detect a defconfig.
The issue is that the tools haven't found a configuration entry point
and could end up building a garbage/invalid configuration. A defconfig
could stand in as a 'valid entry' point, since it signifies a baseline
configuration.
Also, I do have completed code to move fragment merging into a common
location and avoid things like this .. once it goes through some more
compatibility testing, I'll post it to the list.
Irrespective this was merged today into master, can you send a followup
quickly so we can unbreak meta-raspberrypi
I hadn't pulled today, and yes, I'll send something by end of day, since
I don't want this to stay broken!
Cheers,
Bruce
Bruce
meta_dir=$(kgit --meta)
# run1: pull all the configuration fragments, no matter where
they come from
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 2217a31076a2..4a78b897d34f 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
"file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
DEPENDS = "git-native"
-SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c"
+SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"
PR = "r12"
PV = "0.2+git${SRCPV}"
--
2.5.0
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
