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
>
> 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
