Worked on jethro (and it's already in krogoth). Git detected a conflict that I
think was only white
space.
>From b01d2e26bb038240fb609ef78727696c729711ba Mon Sep 17 00:00:00 2001
From: Bruce Ashfield <bruce.ashfi...@windriver.com>
Date: Thu, 21 Apr 2016 11:23:45 -0400
Subject: [PATCH] kernel-yocto: allow branch auditing to be suspended
When working on the yocto-bsp and kernel-lab update for yocto 1.2
we found it was impossible for a end-user BSP to isolate patches
on a branch, since with the following commit:
[kernel-yocto: enforce SRC_URI specified branch]
Any new branch would be switched to whatever was specified on the
SRC_URI and undoing the work that the yocto-bsp tool did to support
board specific patches.
To fix this, we'll keep the enforcing of branch consistency enabled
by default, but introduce a variable "KMETA_AUDIT" that when not
set will skip the check.
There's no impact for existing users, and it is only something that
other plumbing commands and tools will need to use (or care about).
[YOCTO: #9120]
(From OE-Core rev: 1d4c120edeb6e45665eafd6962a10ebb89d758eb)
Signed-off-by: Bruce Ashfield <bruce.ashfi...@windriver.com>
Signed-off-by: Ross Burton <ross.bur...@intel.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
Conflicts:
meta/classes/kernel-yocto.bbclass
---
meta/classes/kernel-yocto.bbclass | 16 ++++++++++++++++
meta/recipes-kernel/linux/linux-yocto.inc | 1 +
2 files changed, 17 insertions(+)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index c2d0d30..c6431a4 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -170,6 +170,22 @@ do_patch() {
fi
fi
+ if [ -n "${KMETA_AUDIT}" ]; then
+ current_branch=`git rev-parse --abbrev-ref HEAD`
+ machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
+ if [ "${current_branch}" != "${machine_branch}" ]; then
+ bbwarn "After meta data application, the kernel tree branch is
${current_branch}."
+ bbwarn "The SRC_URI specified branch ${machine_branch}."
+ bbwarn ""
+ bbwarn "The branch will be forced to ${machine_branch}, but
this means the board meta data"
+ bbwarn "(.scc files) do not match the SRC_URI specification."
+ bbwarn ""
+ bbwarn "The meta data and branch ${machine_branch} should be
inspected to ensure the proper"
+ bbwarn "kernel is being built."
+ git checkout -f ${machine_branch}
+ fi
+ fi
+
if [ "${machine_srcrev}" != "AUTOINC" ]; then
if ! [ "$(git rev-parse --verify ${machine_srcrev}~0)" = "$(git
merge-base ${machine_srcrev} HEAD)" ]; then
bberror "SRCREV ${machine_srcrev} was specified, but is
not reachable"
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 81ffa24..1e383c8 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -33,6 +33,7 @@ SRCREV_FORMAT ?= "meta_machine"
# 2: report options that are not hardware related, but set by a BSP
KCONF_AUDIT_LEVEL ?= "1"
KCONF_BSP_AUDIT_LEVEL ?= "0"
+KMETA_AUDIT ?= "yes"
LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
--
1.9.1
From: Bruce Ashfield <bruce.ashfi...@windriver.com>
Sent: Friday, June 24, 2016 9:36 AM
To: Jake Swensen; yocto@yoctoproject.org
Subject: [EXTERNAL] Re: [yocto] question: yocto-bsp tool warnings
On 2016-06-23 05:52 PM, Jake Swensen wrote:
> I've been looking into setting up my own BSP layer based on the
> standard/beaglebone branch and I've run into some warnings I wasn't familiar
> with. I created a test BSP with the yocto-bsp tool and set MACHINE=test,
> (which is the name of my meta layer) then ran it. This produced several
> warnings:
>
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> After meta data application, the kernel tree branch is standard/test.
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> The SRC_URI specified branch standard/base.
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> The branch will be forced to standard/base, but this means the board meta data
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> (.scc files) do not match the SRC_URI specification.
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> The meta data and branch standard/base should be inspected to ensure the
> proper
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> kernel is being built.
>
> I found the patch which enabled this warning, but I'm unsure how to alleviate
> it. I do intend to use the standard/test branch, but I'm not sure which
> SRC_URI is telling bitbake to build the standard/base.
I'm actively changing the code in this area, so what I'm about to
describe will be valid for about a month, and then it'll be simpler
to explain.
When you are building linux-yocto BSPs (as the yocto-bsp tool is
manipulating) there are two ways that what is build is specifiied:
the SRC_URI (bitbake, the fetcher, etc) and kernel meta-data (the
kernel-cache repository you see on the SRC_URI).
The SRC_URI must specify a branch and SRCREV, since the fetcher
requires it, and that is typically what is built (hence no warning).
But the kernel meta data also has a complete description of the
tree structure (the branching standard/base, standard/common-pc, etc),
since it validates and can re-construct the tree from scratch.
So if the recipe and meta-data disagree on the branch that is to
be built, that warning is displayed, just so there are no surprises.
It is completely valid to build something different than the kernel
meta data describes, which is why the flag KMETA_AUDIT was also
added. When it is set to a non-zero valid, the auditing happens, but
if you clear it in your bbappend, you'll no longer see the warning.
But that commit 1ce221da64e21b9ee0a743dc9372236ab22e21ba (poky), is
only in master. I should get it nominated for backporting to the
release branches. IF you cherry-pick and try it out, that would be
helpful.
Cheers,
Bruce
>
> Any idea where to start looking?
>
> Patch that enabled the warnings:
> http://lists.openembedded.org/pipermail/openembedded-core/2016-April/119808.html
>
>
>
>
3M security scanners have not detected any malicious content in this message.
To report this email as SPAM, please forward it to s...@websense.com
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
