[PATCH 0/6] kernel-yocto: consolidated pull request

[PATCH 0/6] kernel-yocto: consolidated pull request

[Bruce Ashfield]

Hi all,

Here's a collection of changes that have been queued over the past couple of
weeks.

I'm working on some additional -stable updates, as well as a new release
kernel for the fall release, but I wanted to get this queue cleared first.

The patches:

  linux-yocto/4.1: netfilter: x_tables: fix stable backport
  linux-yocto/4.1: bump to v4.1.29
  linux-yocto/4.1: config updates
  linux-yocto/4.4: -rt update patch meta-data to remove ()

Are typical -stable, and bug fix changes. I haven't seen any issues in my
local builds, so all looks well there. These can be taken in isolation from
the kernel tools changes that follow:

  kernel-yocto: streamline patch, configuration and audit phases
  yocto-bsp/yocto-kernel: update to work with the latest kern-tools

Are the important part of this series, and a significant contribution to the
fall release. I've been testing these for some time, and we've run the
kernel lab and yocto-bsp scripts against the tools. We haven't found a
regression yet, but I'm sure there are some lurking. These definitely need
cycles on the autobuilders.

From the patch itself:

[
   We've been running with a set of kern-tools that were designed to work
   with build systems that knew nothing about git, trees, commits, etc.

   As such, there's been a set of shims/wrappers in place to work with
   within bitbake/oe-core. These were the *me scripts: createme, updateme,
   patchme and configme.

   With this commit, we strip that legacy code and use the tools directly.
   This means less complexity, fewer corner cases .. and no surprises
   when the tools are arunning. As another benefit, the tools consume
   much less time during a typical build and have no noticeable impact
   on the overall build time.

   Existing .scc files, features, and processing are not impacted as
   these tools are compatible with existing feature descriptions and
   kerne configuration fragments.

   The audit of kernel configuration fragments is now detached
   from the linux-yocto build structure and process. This means that
   they can eventually be tweaked to offer kernel audit to any type of
   kernel build and configuration process.

   Additionally, the kernel symbol audit phase can now resolve symbol
   dependencies and offer guidance when a symbol is missing:

      WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0 do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:

      ---------- CONFIG_BT_6LOWPAN -----------------
      Config: CONFIG_BT_6LOWPAN
      From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
      Requested value:  CONFIG_BT_6LOWPAN=y
      Actual value:

      Config 'BT_6LOWPAN' has the following conditionals:
        BT_LE && 6LOWPAN (value: "n")
      Dependency values are:
        BT_LE [y] 6LOWPAN [n]
]

This is the 2nd step in making fragments, and their audit available to
any type of kernel build. They are also a significant simplification and
speed up of the processing. There's no branching, no conditioning of the
tree, etc.

The shortlogs of the tools changes are:

   4b5de90 kconf_check: use symbol_why to provide diagnostics on missing options
   92f8053 symbol_why: introduce symbol_why
   779d675 Makefile: add Kconfiglib to install list
   39c00bc tools: import Kconfiglib
   68531c9 kgit: add repo clean function
   b73353f kgit-scc: update tree gen to new kern-tools
   09a1a6c kgit: detect if sourced
   2bad46f kgit-meta: adapt to new scc/spp meta series generation
   8332818 kconf_check: standalone operation and command line options
   d7e06ed spp/scc: streamline patch and config series generation
   f67df1c merge_config: update to mainline variant
   a67df68 kgit-s2q: log last patch applied

The overall diffstat for the tools changes are:

    b/Makefile                  |   26 -
    b/tools/kconf_check         |  923 ++++++++++++++++--------------------
    b/tools/kgit                |  320 ++++++++----
    b/tools/kgit-init           |  301 ++---------
    b/tools/kgit-meta           | 1119 +++-----------------------------------------
    b/tools/kgit-s2q            |   29 -
    b/tools/kgit-scc            |  238 ++-------
    b/tools/merge_config.sh     |  102 ++--
    b/tools/scc                 |  290 +++++++----
    b/tools/scc-cmds/auto.cmd   |   30 +
    b/tools/scc-cmds/branch.cmd |   38 +
    b/tools/scc-cmds/define.cmd |    9
    b/tools/scc-cmds/kconf.cmd  |   55 ++
    b/tools/scc-cmds/mark.cmd   |    4
    b/tools/scc-cmds/patch.cmd  |   32 +
    b/tools/spp                 |  653 +++++++++++++++++--------
    b/tools/symbol_why.py       |  236 +++++++++
    tools/configme              |  397 ---------------
    tools/createme              |  235 ---------
    tools/patchme               |  132 -----
    tools/pre_config            |  226 --------
    tools/updateme              |  621 ------------------------
    22 files changed, 2001 insertions(+), 4015 deletions(-)

We end up at a 2:1 code reduction, and the raw tools are directly used, wins
on both counts.

Note: there are still warnings in the kernel meta-data, they are being worked
on, but I've left them in place so a few people can see the new kernel audit
information :)

Cheers,

Bruce


The following changes since commit 6b66e9317f4ec3a69f98f29836aafa35b52f3fc7:

  Allow for simultaneous do_rootfs tasks with rpm (2016-08-12 15:25:22 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (6):
  linux-yocto/4.1: netfilter: x_tables: fix stable backport
  linux-yocto/4.1: bump to v4.1.29
  linux-yocto/4.1: config updates
  linux-yocto/4.4: -rt update patch meta-data to remove ()
  kernel-yocto: streamline patch, configuration and audit phases
  yocto-bsp/yocto-kernel: update to work with the latest kern-tools

 meta/classes/kernel-yocto.bbclass                  | 143 ++++++++-------------
 .../kern-tools/kern-tools-native_git.bb            |   4 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb    |   6 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb    |   2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb  |   6 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb  |   2 +-
 meta/recipes-kernel/linux/linux-yocto_4.1.bb       |  20 +--
 meta/recipes-kernel/linux/linux-yocto_4.4.bb       |   2 +-
 scripts/lib/bsp/kernel.py                          |   1 -
 .../linux/files/machine-standard.scc               |   2 +-
 .../linux/files/machine-standard.scc               |   2 +-
 .../linux/files/machine-standard.scc               |   2 +-
 .../linux/files/machine-standard.scc               |   2 +-
 .../linux/files/machine-standard.scc               |   2 +-
 .../linux/files/machine-standard.scc               |  10 +-
 .../linux/files/machine-standard.scc               |   2 +-
 16 files changed, 85 insertions(+), 123 deletions(-)

-- 
2.5.0

[PATCH 1/6] linux-yocto/4.1: netfilter: x_tables: fix stable backport

[Bruce Ashfield]

There was an issue with a netfilter backport in 4.1.28-stable. To
address it, we backport the -stable fix:

    netfilter: x_tables: fix stable backport

    Stable-4.1 backport of mainline commit 364723410175 ("netfilter:
    x_tables: validate targets of jumps") doesn't handle correctly the fact
    that 4.1 kernel is missing commit 482cfc318559 ("netfilter: xtables:
    avoid percpu ruleset duplication") so that t->entries is still a per-cpu
    array in find_jump_target().

    Use the same fix as e.g. stable-3.14 backport.

    Fixes: 8163327a3a92 ("netfilter: x_tables: validate targets of jumps")
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  2 +-
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 16 ++++++++--------
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index 4171062..6411175 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -11,7 +11,7 @@ python () {
         raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "0b68498784da5defb7658675e37d9bc615cd4c50"
+SRCREV_machine ?= "5772feaf5827e42e1950a91d95b2fc3c1845b5c6"
 SRCREV_meta ?= "0d6de63d4603b9cc3a4a68391bcb5156b9b0cf96"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index 08b931c..9eae2e1 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -9,7 +9,7 @@ LINUX_VERSION ?= "4.1.28"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "44af900716206d4cae283aa74e92f4118720724a"
+SRCREV_machine ?= "f6ab3612272bb22bac371403121609c66c50cd45"
 SRCREV_meta ?= "0d6de63d4603b9cc3a4a68391bcb5156b9b0cf96"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index ef3d000..8ba0bea 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,14 +11,14 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "460340f28dd4ed608fd66692bcbac0bb24fe4aaf"
-SRCREV_machine_qemuarm64 ?= "44af900716206d4cae283aa74e92f4118720724a"
-SRCREV_machine_qemumips ?= "0ff21b2a5e92defa32b7cb76d39980b63a2eb5ca"
-SRCREV_machine_qemuppc ?= "6bd2872ce7e397d285f7df00f4d0efac286e2401"
-SRCREV_machine_qemux86 ?= "44af900716206d4cae283aa74e92f4118720724a"
-SRCREV_machine_qemux86-64 ?= "44af900716206d4cae283aa74e92f4118720724a"
-SRCREV_machine_qemumips64 ?= "248861985b609d1cd24e8d23b7d15abfb31cbdc2"
-SRCREV_machine ?= "44af900716206d4cae283aa74e92f4118720724a"
+SRCREV_machine_qemuarm ?= "2f133a201f2bbde4ce33731d1596d5144360bf87"
+SRCREV_machine_qemuarm64 ?= "f6ab3612272bb22bac371403121609c66c50cd45"
+SRCREV_machine_qemumips ?= "d1cbc627631f706d19e8e4518bfc38b266f3fb9f"
+SRCREV_machine_qemuppc ?= "d1699ce26291a3e07113057ad7e235f7891e73fb"
+SRCREV_machine_qemux86 ?= "f6ab3612272bb22bac371403121609c66c50cd45"
+SRCREV_machine_qemux86-64 ?= "f6ab3612272bb22bac371403121609c66c50cd45"
+SRCREV_machine_qemumips64 ?= "725278e5cbc402139051032a7b2137f6707c46d6"
+SRCREV_machine ?= "f6ab3612272bb22bac371403121609c66c50cd45"
 SRCREV_meta ?= "0d6de63d4603b9cc3a4a68391bcb5156b9b0cf96"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; \
-- 
2.5.0

[PATCH 2/6] linux-yocto/4.1: bump to v4.1.29

[Bruce Ashfield]

Integrating the korg 4.1.29 -stable release

Signed-off-by: Bruce Ashfield <bruce@zedd.org>
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20 ++++++++++----------
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index 6411175..d25911d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -11,13 +11,13 @@ python () {
         raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "5772feaf5827e42e1950a91d95b2fc3c1845b5c6"
-SRCREV_meta ?= "0d6de63d4603b9cc3a4a68391bcb5156b9b0cf96"
+SRCREV_machine ?= "b1e722634976e1bcf9dc73bcbcfe3487c3fd7e4d"
+SRCREV_meta ?= "71dddd41d8395014d942ac8f20f1255751cb144f"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.1.28"
+LINUX_VERSION ?= "4.1.29"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index 9eae2e1..afc8819 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "4.1.28"
+LINUX_VERSION ?= "4.1.29"
 
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "f6ab3612272bb22bac371403121609c66c50cd45"
-SRCREV_meta ?= "0d6de63d4603b9cc3a4a68391bcb5156b9b0cf96"
+SRCREV_machine ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
+SRCREV_meta ?= "71dddd41d8395014d942ac8f20f1255751cb144f"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index 8ba0bea..b17d591 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "2f133a201f2bbde4ce33731d1596d5144360bf87"
-SRCREV_machine_qemuarm64 ?= "f6ab3612272bb22bac371403121609c66c50cd45"
-SRCREV_machine_qemumips ?= "d1cbc627631f706d19e8e4518bfc38b266f3fb9f"
-SRCREV_machine_qemuppc ?= "d1699ce26291a3e07113057ad7e235f7891e73fb"
-SRCREV_machine_qemux86 ?= "f6ab3612272bb22bac371403121609c66c50cd45"
-SRCREV_machine_qemux86-64 ?= "f6ab3612272bb22bac371403121609c66c50cd45"
-SRCREV_machine_qemumips64 ?= "725278e5cbc402139051032a7b2137f6707c46d6"
-SRCREV_machine ?= "f6ab3612272bb22bac371403121609c66c50cd45"
-SRCREV_meta ?= "0d6de63d4603b9cc3a4a68391bcb5156b9b0cf96"
+SRCREV_machine_qemuarm ?= "09b5eed6e905503646514803787d82f504013144"
+SRCREV_machine_qemuarm64 ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
+SRCREV_machine_qemumips ?= "582073e7a49b0847052be78254805f33635dc837"
+SRCREV_machine_qemuppc ?= "0914d10f46f22582e955b06590768ec51e8a91c3"
+SRCREV_machine_qemux86 ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
+SRCREV_machine_qemux86-64 ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
+SRCREV_machine_qemumips64 ?= "ca25d7656f7eaeb8454a182cfa38fb704ec85276"
+SRCREV_machine ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
+SRCREV_meta ?= "71dddd41d8395014d942ac8f20f1255751cb144f"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.1.28"
+LINUX_VERSION ?= "4.1.29"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.5.0

Re: [PATCH 2/6] linux-yocto/4.1: bump to v4.1.29

[Richard Purdie]

On Mon, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
> Integrating the korg 4.1.29 -stable release
> 
> Signed-off-by: Bruce Ashfield <bruce@zedd.org>
> ---
>  meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
>  meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
>  meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20 ++++++++++---
> -------
>  3 files changed, 16 insertions(+), 16 deletions(-)

FWIW since the update before this one, we've seen a lot of instability
in ppc:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/builds/881/steps/Running%20Sanity%20Tests/logs/stdio

basically the network seems very flaky. Doesn't happen every time but
we are seeing a rising number of these kinds of 'random' failures. Are
there any ppc changes or fixes which look like they're responsible, I'm
pretty sure its something 4.1 kernel related...

The update also triggered a new 'error' for amd_nb in the error log
parsing which I just whitelisted, probably from some change in the
configuration options enabled.

Cheers,

Richard

Re: [PATCH 2/6] linux-yocto/4.1: bump to v4.1.29

[Bruce Ashfield]

On 2016-08-18 11:15 AM, Richard Purdie wrote:
> On Mon, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
>> Integrating the korg 4.1.29 -stable release
>>
>> Signed-off-by: Bruce Ashfield <bruce@zedd.org>
>> ---
>>  meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
>>  meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
>>  meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20 ++++++++++---
>> -------
>>  3 files changed, 16 insertions(+), 16 deletions(-)
>
> FWIW since the update before this one, we've seen a lot of instability
> in ppc:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/builds/881/steps/Running%20Sanity%20Tests/logs/stdio
>
> basically the network seems very flaky. Doesn't happen every time but
> we are seeing a rising number of these kinds of 'random' failures. Are
> there any ppc changes or fixes which look like they're responsible, I'm
> pretty sure its something 4.1 kernel related...
>
> The update also triggered a new 'error' for amd_nb in the error log
> parsing which I just whitelisted, probably from some change in the
> configuration options enabled.

I have a 4.1.30 update queued locally, and I'll double check to see
what may have changed in the configuration that could explain any
new warnings or instability.

Bruce

>
> Cheers,
>
> Richard
>

Re: [PATCH 2/6] linux-yocto/4.1: bump to v4.1.29

[Richard Purdie]

On Thu, 2016-08-18 at 11:16 -0400, Bruce Ashfield wrote:
> On 2016-08-18 11:15 AM, Richard Purdie wrote:
> > On Mon, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
> > > Integrating the korg 4.1.29 -stable release
> > > 
> > > Signed-off-by: Bruce Ashfield <bruce@zedd.org>
> > > ---
> > >  meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
> > >  meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
> > >  meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
> > > ++++++++++---
> > > -------
> > >  3 files changed, 16 insertions(+), 16 deletions(-)
> > 
> > FWIW since the update before this one, we've seen a lot of
> > instability
> > in ppc:
> > 
> > https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
> > builds/881/steps/Running%20Sanity%20Tests/logs/stdio
> > 
> > basically the network seems very flaky. Doesn't happen every time
> > but
> > we are seeing a rising number of these kinds of 'random' failures.
> > Are
> > there any ppc changes or fixes which look like they're responsible,
> > I'm
> > pretty sure its something 4.1 kernel related...
> > 
> > The update also triggered a new 'error' for amd_nb in the error log
> > parsing which I just whitelisted, probably from some change in the
> > configuration options enabled.
> 
> I have a 4.1.30 update queued locally, and I'll double check to see
> what may have changed in the configuration that could explain any
> new warnings or instability.

Just to be clear, the amb_nd change was on qemux86* on 4.1

https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/911/steps/Running%20Sanity%20Tests/logs/stdio

fixed with:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26b0657b2f78751e60df6e695d5bc0dd703a5bc2

The ppc issue is a separate one.

Cheers,

Richard

Re: [PATCH 2/6] linux-yocto/4.1: bump to v4.1.29

[Bruce Ashfield]

On 2016-08-18 11:20 AM, Richard Purdie wrote:
> On Thu, 2016-08-18 at 11:16 -0400, Bruce Ashfield wrote:
>> On 2016-08-18 11:15 AM, Richard Purdie wrote:
>>> On Mon, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
>>>> Integrating the korg 4.1.29 -stable release
>>>>
>>>> Signed-off-by: Bruce Ashfield <bruce@zedd.org>
>>>> ---
>>>>  meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
>>>>  meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
>>>>  meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
>>>> ++++++++++---
>>>> -------
>>>>  3 files changed, 16 insertions(+), 16 deletions(-)
>>>
>>> FWIW since the update before this one, we've seen a lot of
>>> instability
>>> in ppc:
>>>
>>> https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
>>> builds/881/steps/Running%20Sanity%20Tests/logs/stdio
>>>
>>> basically the network seems very flaky. Doesn't happen every time
>>> but
>>> we are seeing a rising number of these kinds of 'random' failures.
>>> Are
>>> there any ppc changes or fixes which look like they're responsible,
>>> I'm
>>> pretty sure its something 4.1 kernel related...
>>>
>>> The update also triggered a new 'error' for amd_nb in the error log
>>> parsing which I just whitelisted, probably from some change in the
>>> configuration options enabled.
>>
>> I have a 4.1.30 update queued locally, and I'll double check to see
>> what may have changed in the configuration that could explain any
>> new warnings or instability.
>
> Just to be clear, the amb_nd change was on qemux86* on 4.1
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/911/steps/Running%20Sanity%20Tests/logs/stdio
>
> fixed with:
>
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26b0657b2f78751e60df6e695d5bc0dd703a5bc2

I had a look at this, and I don't have a root cause for why this is
just popping up now. I'm trying to track down an older build, so I can
compare the .configs.

The kernel code, and Kconfig files themselves haven't changed in some
time, and the symbol in question AMD_NB is default 'y' if the
dependencies are met. We include cfg/amd.scc in all of the qemux86*
builds, so it gets enabled (as it should have before).

I could force that option off, but the whitelist is an appropriate fix,
since this is an interaction between qemu and the kernel, whereas the
files that include amd.scc are targeted at a range of platforms.

>
> The ppc issue is a separate one.

I've been blasting away on my 4.1.30 qemuppc build, and I'm not seeing
anything yet, but I will keep trying.

Bruce

>
> Cheers,
>
> Richard
>
>

Re: [PATCH 2/6] linux-yocto/4.1: bump to v4.1.29

[Richard Purdie]

On Fri, 2016-08-19 at 10:57 -0400, Bruce Ashfield wrote:
> On 2016-08-18 11:20 AM, Richard Purdie wrote:
> > On Thu, 2016-08-18 at 11:16 -0400, Bruce Ashfield wrote:
> > > On 2016-08-18 11:15 AM, Richard Purdie wrote:
> > > > On Mon, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
> > > > > Integrating the korg 4.1.29 -stable release
> > > > > 
> > > > > Signed-off-by: Bruce Ashfield <bruce@zedd.org>
> > > > > ---
> > > > >  meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++--
> > > > > -
> > > > >  meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++--
> > > > > -
> > > > >  meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
> > > > > ++++++++++---
> > > > > -------
> > > > >  3 files changed, 16 insertions(+), 16 deletions(-)
> > > > 
> > > > FWIW since the update before this one, we've seen a lot of
> > > > instability
> > > > in ppc:
> > > > 
> > > > https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-
> > > > lsb/
> > > > builds/881/steps/Running%20Sanity%20Tests/logs/stdio
> > > > 
> > > > basically the network seems very flaky. Doesn't happen every
> > > > time
> > > > but
> > > > we are seeing a rising number of these kinds of 'random'
> > > > failures.
> > > > Are
> > > > there any ppc changes or fixes which look like they're
> > > > responsible,
> > > > I'm
> > > > pretty sure its something 4.1 kernel related...
> > > > 
> > > > The update also triggered a new 'error' for amd_nb in the error
> > > > log
> > > > parsing which I just whitelisted, probably from some change in
> > > > the
> > > > configuration options enabled.
> > > 
> > > I have a 4.1.30 update queued locally, and I'll double check to
> > > see
> > > what may have changed in the configuration that could explain any
> > > new warnings or instability.
> > 
> > Just to be clear, the amb_nd change was on qemux86* on 4.1
> > 
> > https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-l
> > sb/builds/911/steps/Running%20Sanity%20Tests/logs/stdio
> > 
> > fixed with:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26b0657b2f7875
> > 1e60df6e695d5bc0dd703a5bc2
> 
> I had a look at this, and I don't have a root cause for why this is
> just popping up now. I'm trying to track down an older build, so I
> can
> compare the .configs.
> 
> The kernel code, and Kconfig files themselves haven't changed in some
> time, and the symbol in question AMD_NB is default 'y' if the
> dependencies are met. We include cfg/amd.scc in all of the qemux86*
> builds, so it gets enabled (as it should have before).
> 
> I could force that option off, but the whitelist is an appropriate
> fix,
> since this is an interaction between qemu and the kernel, whereas the
> files that include amd.scc are targeted at a range of platforms.
> 
> > 
> > The ppc issue is a separate one.
> 
> I've been blasting away on my 4.1.30 qemuppc build, and I'm not
> seeing
> anything yet, but I will keep trying.

Its still going on even with the recent updates:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/builds/889/steps/Running%20Sanity%20Tests/logs/stdio

Seems the network works intermittently, dropping connections...

Cheers,

Richard

Re: [PATCH 2/6] linux-yocto/4.1: bump to v4.1.29

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 4038 bytes --]

On Wed, Aug 24, 2016 at 7:25 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Fri, 2016-08-19 at 10:57 -0400, Bruce Ashfield wrote:
> > On 2016-08-18 11:20 AM, Richard Purdie wrote:
> > > On Thu, 2016-08-18 at 11:16 -0400, Bruce Ashfield wrote:
> > > > On 2016-08-18 11:15 AM, Richard Purdie wrote:
> > > > > On Mon, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
> > > > > > Integrating the korg 4.1.29 -stable release
> > > > > >
> > > > > > Signed-off-by: Bruce Ashfield <bruce@zedd.org>
> > > > > > ---
> > > > > >  meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++--
> > > > > > -
> > > > > >  meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++--
> > > > > > -
> > > > > >  meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
> > > > > > ++++++++++---
> > > > > > -------
> > > > > >  3 files changed, 16 insertions(+), 16 deletions(-)
> > > > >
> > > > > FWIW since the update before this one, we've seen a lot of
> > > > > instability
> > > > > in ppc:
> > > > >
> > > > > https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-
> > > > > lsb/
> > > > > builds/881/steps/Running%20Sanity%20Tests/logs/stdio
> > > > >
> > > > > basically the network seems very flaky. Doesn't happen every
> > > > > time
> > > > > but
> > > > > we are seeing a rising number of these kinds of 'random'
> > > > > failures.
> > > > > Are
> > > > > there any ppc changes or fixes which look like they're
> > > > > responsible,
> > > > > I'm
> > > > > pretty sure its something 4.1 kernel related...
> > > > >
> > > > > The update also triggered a new 'error' for amd_nb in the error
> > > > > log
> > > > > parsing which I just whitelisted, probably from some change in
> > > > > the
> > > > > configuration options enabled.
> > > >
> > > > I have a 4.1.30 update queued locally, and I'll double check to
> > > > see
> > > > what may have changed in the configuration that could explain any
> > > > new warnings or instability.
> > >
> > > Just to be clear, the amb_nd change was on qemux86* on 4.1
> > >
> > > https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-l
> > > sb/builds/911/steps/Running%20Sanity%20Tests/logs/stdio
> > >
> > > fixed with:
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26b0657b2f7875
> > > 1e60df6e695d5bc0dd703a5bc2
> >
> > I had a look at this, and I don't have a root cause for why this is
> > just popping up now. I'm trying to track down an older build, so I
> > can
> > compare the .configs.
> >
> > The kernel code, and Kconfig files themselves haven't changed in some
> > time, and the symbol in question AMD_NB is default 'y' if the
> > dependencies are met. We include cfg/amd.scc in all of the qemux86*
> > builds, so it gets enabled (as it should have before).
> >
> > I could force that option off, but the whitelist is an appropriate
> > fix,
> > since this is an interaction between qemu and the kernel, whereas the
> > files that include amd.scc are targeted at a range of platforms.
> >
> > >
> > > The ppc issue is a separate one.
> >
> > I've been blasting away on my 4.1.30 qemuppc build, and I'm not
> > seeing
> > anything yet, but I will keep trying.
>
> Its still going on even with the recent updates:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
> builds/889/steps/Running%20Sanity%20Tests/logs/stdio
>
> Seems the network works intermittently, dropping connections...
>

Hmm.

I've had a qemuppc up and running for 3 days now, doing transfers of files
from my server, and yet my network hasn't dropped.
I'll continue trying to figure this out.

Bruce


>
> Cheers,
>
> Richard
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 6733 bytes --]

[PATCH 3/6] linux-yocto/4.1: config updates

[Bruce Ashfield]

Integrating the following configuration changes:

 features: usb-net: provide more coverage on USB network devices
 features: broxton: enable iTCO watchdog support
 features: broxton: enable iSMT support
 features: broxton: enable LPC bridge function for Intel ICH and SCH

Signed-off-by: Bruce Ashfield <bruce@zedd.org>
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index d25911d..0fd78ff 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "b1e722634976e1bcf9dc73bcbcfe3487c3fd7e4d"
-SRCREV_meta ?= "71dddd41d8395014d942ac8f20f1255751cb144f"
+SRCREV_meta ?= "497e2eb5c259c4ac434d09555b33da9ed4a8667e"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index afc8819..485843d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
-SRCREV_meta ?= "71dddd41d8395014d942ac8f20f1255751cb144f"
+SRCREV_meta ?= "497e2eb5c259c4ac434d09555b33da9ed4a8667e"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index b17d591..d3963f9 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
 SRCREV_machine_qemux86-64 ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
 SRCREV_machine_qemumips64 ?= "ca25d7656f7eaeb8454a182cfa38fb704ec85276"
 SRCREV_machine ?= "053af7be9159a0b5a016a3e399de1484e51f26cd"
-SRCREV_meta ?= "71dddd41d8395014d942ac8f20f1255751cb144f"
+SRCREV_meta ?= "497e2eb5c259c4ac434d09555b33da9ed4a8667e"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
-- 
2.5.0

[PATCH 4/6] linux-yocto/4.4: -rt update patch meta-data to remove ()

[Bruce Ashfield]

The existing kernel patching scripts don't like () in patch names, since they
are detected as function calls. Although the scripts will be updated to avoid
this error, it is worthwhile fixing the patch names in the meantime.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_4.4.bb      | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
index 82ea08b..2b10d90 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "2b65eaade74b9ec3b3009a6939461ea55d646801"
-SRCREV_meta ?= "86bf91f444418076181fedba14bdafad3a531cf0"
+SRCREV_meta ?= "b030d96c7b8c391a9e155719d649eb0f87358117"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;branch=${KBRANCH};name=machine \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
index fca2c54..78b148c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "ddab242999407fadae68e7ee5381b0ec6679d443"
-SRCREV_meta ?= "86bf91f444418076181fedba14bdafad3a531cf0"
+SRCREV_meta ?= "b030d96c7b8c391a9e155719d649eb0f87358117"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index ef0e64b..170f34c 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "ddab242999407fadae68e7ee5381b0ec6679d443"
 SRCREV_machine_qemux86-64 ?= "ddab242999407fadae68e7ee5381b0ec6679d443"
 SRCREV_machine_qemumips64 ?= "2d0080f2350e088bdc6129c376eb9e2654a0448a"
 SRCREV_machine ?= "ddab242999407fadae68e7ee5381b0ec6679d443"
-SRCREV_meta ?= "86bf91f444418076181fedba14bdafad3a531cf0"
+SRCREV_meta ?= "b030d96c7b8c391a9e155719d649eb0f87358117"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
-- 
2.5.0

[PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[Bruce Ashfield]

We've been running with a set of kern-tools that were designed to work
with build systems that knew nothing about git, trees, commits, etc.

As such, there's been a set of shims/wrappers in place to work with
within bitbake/oe-core. These were the *me scripts: createme, updateme,
patchme and configme.

With this commit, we strip that legacy code and use the tools directly.
This means less complexity, fewer corner cases .. and no surprises
when the tools are arunning. As another benefit, the tools consume
much less time during a typical build and have no noticeable impact
on the overall build time.

Existing .scc files, features, and processing are not impacted as
these tools are compatible with existing feature descriptions and
kerne configuration fragments.

The audit of kernel configuration fragments is now detached
from the linux-yocto build structure and process. This means that
they can eventually be tweaked to offer kernel audit to any type of
kernel build and configuration process.

Additionally, the kernel symbol audit phase can now resolve symbol
dependencies and offer guidance when a symbol is missing:

   WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0 do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:

   ---------- CONFIG_BT_6LOWPAN -----------------
   Config: CONFIG_BT_6LOWPAN
   From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
   Requested value:  CONFIG_BT_6LOWPAN=y
   Actual value:

   Config 'BT_6LOWPAN' has the following conditionals:
     BT_LE && 6LOWPAN (value: "n")
   Dependency values are:
     BT_LE [y] 6LOWPAN [n]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel-yocto.bbclass                  | 143 ++++++++-------------
 .../kern-tools/kern-tools-native_git.bb            |   4 +-
 2 files changed, 55 insertions(+), 92 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index a9d4205..8650e55 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -119,77 +119,42 @@ do_kernel_metadata() {
 	patches="${@" ".join(find_patches(d))}"
 	feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"
 
-	# add any explicitly referenced features onto the end of the feature
-	# list that is passed to the kernel build scripts.
-	if [ -n "${KERNEL_FEATURES}" ]; then
-		for feat in ${KERNEL_FEATURES}; do
-			addon_features="$addon_features --feature $feat"
-		done
-	fi
-
 	# check for feature directories/repos/branches that were part of the
 	# SRC_URI. If they were supplied, we convert them into include directives
 	# for the update part of the process
-	if [ -n "${feat_dirs}" ]; then
-	    for f in ${feat_dirs}; do
+	for f in ${feat_dirs}; do
 		if [ -d "${WORKDIR}/$f/meta" ]; then
-		    includes="$includes -I${WORKDIR}/$f/meta"
+			includes="$includes -I${WORKDIR}/$f/meta"
 		elif [ -d "${WORKDIR}/$f" ]; then
-		    includes="$includes -I${WORKDIR}/$f"
+			includes="$includes -I${WORKDIR}/$f"
 		fi
-	    done
-	fi
+	done
+	for s in ${sccs}; do
+		sdir=$(dirname $s)
+		includes="$includes -I${sdir}"
+	done
 
-	# updates or generates the target description
-	updateme ${updateme_flags} -DKDESC=${KMACHINE}:${LINUX_KERNEL_TYPE} \
-                         ${includes} ${addon_features} ${ARCH} ${KMACHINE} ${sccs} ${patches}
-	if [ $? -ne 0 ]; then
-		bbfatal_log "Could not update ${machine_branch}"
-	fi
+	# expand kernel features into their full path equivalents
+	bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE})
+	meta_dir=$(kgit --meta)
+
+	# run1: pull all the configuration fragments, no matter where they come from
+	scc --force -o ${S}/${meta_dir}:cfg,meta ${includes} ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
+
+	# run2: only generate patches for elements that have been passed on the SRC_URI
+	scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} ${sccs} ${patches} ${KERNEL_FEATURES}
 }
 
 do_patch() {
 	cd ${S}
 
-	# executes and modifies the source tree as required
-	patchme ${KMACHINE}
-	if [ $? -ne 0 ]; then
-		bberror "Could not apply patches for ${KMACHINE}."
-		bbfatal_log "Patch failures can be resolved in the linux source directory ${S})"
-	fi
-
-	# check to see if the specified SRCREV is reachable from the final branch.
-	# if it wasn't something wrong has happened, and we should error.
-	machine_srcrev="${SRCREV_machine}"
-	if [ -z "${machine_srcrev}" ]; then
-		# fallback to SRCREV if a non machine_meta tree is being built
-		machine_srcrev="${SRCREV}"
-		# if SRCREV cannot be reached something is wrong.
-		if [ -z "${machine_srcrev}" ]; then
-			bbfatal "Neither SRCREV_machine or SRCREV was specified!"
-		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"
-			bbfatal "Check the BSP description for incorrect branch selection, or other errors."
+	meta_dir=$(kgit --meta)
+	(cd ${meta_dir}; ln -sf patch.queue series)
+	if [ -f "${meta_dir}/series" ]; then
+		kgit-s2q --gen -v --patches .kernel-meta/
+		if [ $? -ne 0 ]; then
+			bberror "Could not apply patches for ${KMACHINE}."
+			bbfatal_log "Patch failures can be resolved in the linux source directory ${S})"
 		fi
 	fi
 }
@@ -258,26 +223,37 @@ do_kernel_metadata[depends] = "kern-tools-native:do_populate_sysroot"
 
 do_kernel_configme[dirs] += "${S} ${B}"
 do_kernel_configme() {
-	bbnote "kernel configme"
-	export KMETA=${KMETA}
+	set +e
 
-	if [ -n "${KCONFIG_MODE}" ]; then
-		configmeflags=${KCONFIG_MODE}
-	else
-		# If a defconfig was passed, use =n as the baseline, which is achieved
-		# via --allnoconfig
+	# translate the kconfig_mode into something that merge_config.sh
+	# understands
+	case ${KCONFIG_MODE} in
+		allnoconfig)
+			config_flags="-n"
+			;;
+		alldefconfig)
+			config_flags=""
+			;;
+	    *)
 		if [ -f ${WORKDIR}/defconfig ]; then
-			configmeflags="--allnoconfig"
+			config_flags="-n"
 		fi
-	fi
+	    ;;
+	esac
 
 	cd ${S}
-	PATH=${PATH}:${S}/scripts/util
-	configme ${configmeflags} --reconfig --output ${B} ${LINUX_KERNEL_TYPE} ${KMACHINE}
+
+	meta_dir=$(kgit --meta)
+	configs="$(scc --configs -o ${meta_dir})"
+	if [ -z "${configs}" ]; then
+		bbfatal_log "Could not find configuration queue (${meta_dir}/config.queue)"
+	fi
+
+	ARCH=${ARCH} merge_config.sh -O ${B} ${config_flags} ${configs} > ${meta_dir}/cfg/merge_config_build.log 2>&1
 	if [ $? -ne 0 ]; then
 		bbfatal_log "Could not configure ${KMACHINE}-${LINUX_KERNEL_TYPE}"
 	fi
-	
+
 	echo "# Global settings from linux recipe" >> ${B}/.config
 	echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config
 }
@@ -295,36 +271,23 @@ python do_kernel_configcheck() {
         kmeta = "." + kmeta
 
     pathprefix = "export PATH=%s:%s; " % (d.getVar('PATH', True), "${S}/scripts/util/")
-    cmd = d.expand("cd ${S}; kconf_check -config %s/meta-series ${S} ${B}" % kmeta)
+
+    cmd = d.expand("scc --configs -o ${S}/.kernel-meta")
+    ret, configs = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
+
+    cmd = d.expand("cd ${S}; kconf_check --report -o ${S}/%s/cfg/ ${B}/.config ${S} %s" % (kmeta,configs))
     ret, result = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
 
     config_check_visibility = int(d.getVar( "KCONF_AUDIT_LEVEL", True ) or 0)
     bsp_check_visibility = int(d.getVar( "KCONF_BSP_AUDIT_LEVEL", True ) or 0)
 
     # if config check visibility is non-zero, report dropped configuration values
-    mismatch_file = "${S}/" + kmeta + "/" + "mismatch.cfg"
+    mismatch_file = d.expand("${S}/%s/cfg/mismatch.txt" % kmeta)
     if os.path.exists(mismatch_file):
         if config_check_visibility:
             with open (mismatch_file, "r") as myfile:
                 results = myfile.read()
                 bb.warn( "[kernel config]: specified values did not make it into the kernel's final configuration:\n\n%s" % results)
-
-    # if config check visibility is level 2 or higher, report non-hardware options
-    nonhw_file = "${S}/" + kmeta + "/" + "nonhw_report.cfg"
-    if os.path.exists(nonhw_file):
-        if config_check_visibility > 1:
-            with open (nonhw_file, "r") as myfile:
-                results = myfile.read()
-                bb.warn( "[kernel config]: BSP specified non-hw configuration:\n\n%s" % results)
-
-    bsp_desc = "${S}/" + kmeta + "/" + "top_tgt"
-    if os.path.exists(bsp_desc) and bsp_check_visibility > 1:
-        with open (bsp_desc, "r") as myfile:
-            bsp_tgt = myfile.read()
-            m = re.match("^(.*)scratch.obj(.*)$", bsp_tgt)
-            if not m is None:
-                bb.warn( "[kernel]: An auto generated BSP description was used, this normally indicates a misconfiguration.\n" +
-                         "Check that your machine (%s) has an associated kernel description." % "${MACHINE}" )
 }
 
 # Ensure that the branches (BSP and meta) are on the locations specified by
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 c3ded98..6877a0c 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -1,10 +1,10 @@
 SUMMARY = "Tools for managing Yocto Project style branched kernels"
 LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70cd5f52972f8884b80743d"
+LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1bda400e2828845ba0d06c"
 
 DEPENDS = "git-native"
 
-SRCREV = "a6a6f6e1e738d2ecd26b675e9bec867105703416"
+SRCREV = "4b5de9011b31ff92ba2b6e052ab818b09affd905"
 PR = "r12"
 PV = "0.2+git${SRCPV}"
 
-- 
2.5.0

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[André Draszik]

My kmeta stuff is located directly inside two meta-* layers (i.e. not in an
extra git repo), where the 2nd layer's kernel recipes .bbappends to the 1st
one with additional kmeta things.

This used to work fine, but since this commit it doesn't anymore as only the
kmeta stuff from the 2nd layer is being copied into workdir.

Have I been doing something that wasn't guaranteed / supposed to work in the
first place? Or should that still work? Is it worth fixing or should I
rethink my approach?


Cheers,
Andre'


On Mo, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
> We've been running with a set of kern-tools that were designed to work
> with build systems that knew nothing about git, trees, commits, etc.
> 
> As such, there's been a set of shims/wrappers in place to work with
> within bitbake/oe-core. These were the *me scripts: createme, updateme,
> patchme and configme.
> 
> With this commit, we strip that legacy code and use the tools directly.
> This means less complexity, fewer corner cases .. and no surprises
> when the tools are arunning. As another benefit, the tools consume
> much less time during a typical build and have no noticeable impact
> on the overall build time.
> 
> Existing .scc files, features, and processing are not impacted as
> these tools are compatible with existing feature descriptions and
> kerne configuration fragments.
> 
> The audit of kernel configuration fragments is now detached
> from the linux-yocto build structure and process. This means that
> they can eventually be tweaked to offer kernel audit to any type of
> kernel build and configuration process.
> 
> Additionally, the kernel symbol audit phase can now resolve symbol
> dependencies and offer guidance when a symbol is missing:
> 
>    WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0
> do_kernel_configcheck: [kernel config]: specified values did not make it
> into the kernel's final configuration:
> 
>    ---------- CONFIG_BT_6LOWPAN -----------------
>    Config: CONFIG_BT_6LOWPAN
>    From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-
> source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
>    Requested value:  CONFIG_BT_6LOWPAN=y
>    Actual value:
> 
>    Config 'BT_6LOWPAN' has the following conditionals:
>      BT_LE && 6LOWPAN (value: "n")
>    Dependency values are:
>      BT_LE [y] 6LOWPAN [n]
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/classes/kernel-yocto.bbclass                  | 143 ++++++++------
> -------
>  .../kern-tools/kern-tools-native_git.bb            |   4 +-
>  2 files changed, 55 insertions(+), 92 deletions(-)
> 
> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-
> yocto.bbclass
> index a9d4205..8650e55 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -119,77 +119,42 @@ do_kernel_metadata() {
>  	patches="${@" ".join(find_patches(d))}"
>  	feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"
>  
> -	# add any explicitly referenced features onto the end of the
> feature
> -	# list that is passed to the kernel build scripts.
> -	if [ -n "${KERNEL_FEATURES}" ]; then
> -		for feat in ${KERNEL_FEATURES}; do
> -			addon_features="$addon_features --feature $feat"
> -		done
> -	fi
> -
>  	# check for feature directories/repos/branches that were part of
> the
>  	# SRC_URI. If they were supplied, we convert them into include
> directives
>  	# for the update part of the process
> -	if [ -n "${feat_dirs}" ]; then
> -	    for f in ${feat_dirs}; do
> +	for f in ${feat_dirs}; do
>  		if [ -d "${WORKDIR}/$f/meta" ]; then
> -		    includes="$includes -I${WORKDIR}/$f/meta"
> +			includes="$includes -I${WORKDIR}/$f/meta"
>  		elif [ -d "${WORKDIR}/$f" ]; then
> -		    includes="$includes -I${WORKDIR}/$f"
> +			includes="$includes -I${WORKDIR}/$f"
>  		fi
> -	    done
> -	fi
> +	done
> +	for s in ${sccs}; do
> +		sdir=$(dirname $s)
> +		includes="$includes -I${sdir}"
> +	done
>  
> -	# updates or generates the target description
> -	updateme ${updateme_flags}
> -DKDESC=${KMACHINE}:${LINUX_KERNEL_TYPE} \
> -                         ${includes} ${addon_features} ${ARCH}
> ${KMACHINE} ${sccs} ${patches}
> -	if [ $? -ne 0 ]; then
> -		bbfatal_log "Could not update ${machine_branch}"
> -	fi
> +	# expand kernel features into their full path equivalents
> +	bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
> -DKTYPE=${LINUX_KERNEL_TYPE})
> +	meta_dir=$(kgit --meta)
> +
> +	# run1: pull all the configuration fragments, no matter where
> they come from
> +	scc --force -o ${S}/${meta_dir}:cfg,meta ${includes}
> ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
> +
> +	# run2: only generate patches for elements that have been passed
> on the SRC_URI
> +	scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes}
> ${sccs} ${patches} ${KERNEL_FEATURES}
>  }
>  
>  do_patch() {
>  	cd ${S}
>  
> -	# executes and modifies the source tree as required
> -	patchme ${KMACHINE}
> -	if [ $? -ne 0 ]; then
> -		bberror "Could not apply patches for ${KMACHINE}."
> -		bbfatal_log "Patch failures can be resolved in the linux
> source directory ${S})"
> -	fi
> -
> -	# check to see if the specified SRCREV is reachable from the
> final branch.
> -	# if it wasn't something wrong has happened, and we should error.
> -	machine_srcrev="${SRCREV_machine}"
> -	if [ -z "${machine_srcrev}" ]; then
> -		# fallback to SRCREV if a non machine_meta tree is being
> built
> -		machine_srcrev="${SRCREV}"
> -		# if SRCREV cannot be reached something is wrong.
> -		if [ -z "${machine_srcrev}" ]; then
> -			bbfatal "Neither SRCREV_machine or SRCREV was
> specified!"
> -		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"
> -			bbfatal "Check the BSP description for incorrect
> branch selection, or other errors."
> +	meta_dir=$(kgit --meta)
> +	(cd ${meta_dir}; ln -sf patch.queue series)
> +	if [ -f "${meta_dir}/series" ]; then
> +		kgit-s2q --gen -v --patches .kernel-meta/
> +		if [ $? -ne 0 ]; then
> +			bberror "Could not apply patches for
> ${KMACHINE}."
> +			bbfatal_log "Patch failures can be resolved in
> the linux source directory ${S})"
>  		fi
>  	fi
>  }
> @@ -258,26 +223,37 @@ do_kernel_metadata[depends] = "kern-tools-
> native:do_populate_sysroot"
>  
>  do_kernel_configme[dirs] += "${S} ${B}"
>  do_kernel_configme() {
> -	bbnote "kernel configme"
> -	export KMETA=${KMETA}
> +	set +e
>  
> -	if [ -n "${KCONFIG_MODE}" ]; then
> -		configmeflags=${KCONFIG_MODE}
> -	else
> -		# If a defconfig was passed, use =n as the baseline,
> which is achieved
> -		# via --allnoconfig
> +	# translate the kconfig_mode into something that merge_config.sh
> +	# understands
> +	case ${KCONFIG_MODE} in
> +		allnoconfig)
> +			config_flags="-n"
> +			;;
> +		alldefconfig)
> +			config_flags=""
> +			;;
> +	    *)
>  		if [ -f ${WORKDIR}/defconfig ]; then
> -			configmeflags="--allnoconfig"
> +			config_flags="-n"
>  		fi
> -	fi
> +	    ;;
> +	esac
>  
>  	cd ${S}
> -	PATH=${PATH}:${S}/scripts/util
> -	configme ${configmeflags} --reconfig --output ${B}
> ${LINUX_KERNEL_TYPE} ${KMACHINE}
> +
> +	meta_dir=$(kgit --meta)
> +	configs="$(scc --configs -o ${meta_dir})"
> +	if [ -z "${configs}" ]; then
> +		bbfatal_log "Could not find configuration queue
> (${meta_dir}/config.queue)"
> +	fi
> +
> +	ARCH=${ARCH} merge_config.sh -O ${B} ${config_flags} ${configs} >
> ${meta_dir}/cfg/merge_config_build.log 2>&1
>  	if [ $? -ne 0 ]; then
>  		bbfatal_log "Could not configure ${KMACHINE}-
> ${LINUX_KERNEL_TYPE}"
>  	fi
> -	
> +
>  	echo "# Global settings from linux recipe" >> ${B}/.config
>  	echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >>
> ${B}/.config
>  }
> @@ -295,36 +271,23 @@ python do_kernel_configcheck() {
>          kmeta = "." + kmeta
>  
>      pathprefix = "export PATH=%s:%s; " % (d.getVar('PATH', True),
> "${S}/scripts/util/")
> -    cmd = d.expand("cd ${S}; kconf_check -config %s/meta-series ${S}
> ${B}" % kmeta)
> +
> +    cmd = d.expand("scc --configs -o ${S}/.kernel-meta")
> +    ret, configs = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
> +
> +    cmd = d.expand("cd ${S}; kconf_check --report -o ${S}/%s/cfg/
> ${B}/.config ${S} %s" % (kmeta,configs))
>      ret, result = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
>  
>      config_check_visibility = int(d.getVar( "KCONF_AUDIT_LEVEL", True )
> or 0)
>      bsp_check_visibility = int(d.getVar( "KCONF_BSP_AUDIT_LEVEL", True )
> or 0)
>  
>      # if config check visibility is non-zero, report dropped
> configuration values
> -    mismatch_file = "${S}/" + kmeta + "/" + "mismatch.cfg"
> +    mismatch_file = d.expand("${S}/%s/cfg/mismatch.txt" % kmeta)
>      if os.path.exists(mismatch_file):
>          if config_check_visibility:
>              with open (mismatch_file, "r") as myfile:
>                  results = myfile.read()
>                  bb.warn( "[kernel config]: specified values did not make
> it into the kernel's final configuration:\n\n%s" % results)
> -
> -    # if config check visibility is level 2 or higher, report non-
> hardware options
> -    nonhw_file = "${S}/" + kmeta + "/" + "nonhw_report.cfg"
> -    if os.path.exists(nonhw_file):
> -        if config_check_visibility > 1:
> -            with open (nonhw_file, "r") as myfile:
> -                results = myfile.read()
> -                bb.warn( "[kernel config]: BSP specified non-hw
> configuration:\n\n%s" % results)
> -
> -    bsp_desc = "${S}/" + kmeta + "/" + "top_tgt"
> -    if os.path.exists(bsp_desc) and bsp_check_visibility > 1:
> -        with open (bsp_desc, "r") as myfile:
> -            bsp_tgt = myfile.read()
> -            m = re.match("^(.*)scratch.obj(.*)$", bsp_tgt)
> -            if not m is None:
> -                bb.warn( "[kernel]: An auto generated BSP description was
> used, this normally indicates a misconfiguration.\n" +
> -                         "Check that your machine (%s) has an associated
> kernel description." % "${MACHINE}" )
>  }
>  
>  # Ensure that the branches (BSP and meta) are on the locations specified
> by
> 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 c3ded98..6877a0c 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> @@ -1,10 +1,10 @@
>  SUMMARY = "Tools for managing Yocto Project style branched kernels"
>  LICENSE = "GPLv2"
> -LIC_FILES_CHKSUM =
> "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70cd5f52972f8884
> b80743d"
> +LIC_FILES_CHKSUM =
> "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1bda400e2828845
> ba0d06c"
>  
>  DEPENDS = "git-native"
>  
> -SRCREV = "a6a6f6e1e738d2ecd26b675e9bec867105703416"
> +SRCREV = "4b5de9011b31ff92ba2b6e052ab818b09affd905"
>  PR = "r12"
>  PV = "0.2+git${SRCPV}"
>  
> -- 
> 2.5.0
> 

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[Bruce Ashfield]

On 2016-08-30 05:05 AM, André Draszik wrote:
> My kmeta stuff is located directly inside two meta-* layers (i.e. not in an
> extra git repo), where the 2nd layer's kernel recipes .bbappends to the 1st
> one with additional kmeta things.
>
> This used to work fine, but since this commit it doesn't anymore as only the
> kmeta stuff from the 2nd layer is being copied into workdir.
>
> Have I been doing something that wasn't guaranteed / supposed to work in the
> first place? Or should that still work? Is it worth fixing or should I
> rethink my approach?

That was complexity that I had tried to remove, but thinking on it a
bit, I think I can restore that without adding much complexity.

I'm just finishing work on the 4.8 kernel today, and can look at this
tomorrow.

Do you have any public layers that I can reference to pull together a
test case ?

Bruce


>
>
> Cheers,
> Andre'
>
>
> On Mo, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
>> We've been running with a set of kern-tools that were designed to work
>> with build systems that knew nothing about git, trees, commits, etc.
>>
>> As such, there's been a set of shims/wrappers in place to work with
>> within bitbake/oe-core. These were the *me scripts: createme, updateme,
>> patchme and configme.
>>
>> With this commit, we strip that legacy code and use the tools directly.
>> This means less complexity, fewer corner cases .. and no surprises
>> when the tools are arunning. As another benefit, the tools consume
>> much less time during a typical build and have no noticeable impact
>> on the overall build time.
>>
>> Existing .scc files, features, and processing are not impacted as
>> these tools are compatible with existing feature descriptions and
>> kerne configuration fragments.
>>
>> The audit of kernel configuration fragments is now detached
>> from the linux-yocto build structure and process. This means that
>> they can eventually be tweaked to offer kernel audit to any type of
>> kernel build and configuration process.
>>
>> Additionally, the kernel symbol audit phase can now resolve symbol
>> dependencies and offer guidance when a symbol is missing:
>>
>>    WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0
>> do_kernel_configcheck: [kernel config]: specified values did not make it
>> into the kernel's final configuration:
>>
>>    ---------- CONFIG_BT_6LOWPAN -----------------
>>    Config: CONFIG_BT_6LOWPAN
>>    From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-
>> source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
>>    Requested value:  CONFIG_BT_6LOWPAN=y
>>    Actual value:
>>
>>    Config 'BT_6LOWPAN' has the following conditionals:
>>      BT_LE && 6LOWPAN (value: "n")
>>    Dependency values are:
>>      BT_LE [y] 6LOWPAN [n]
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>  meta/classes/kernel-yocto.bbclass                  | 143 ++++++++------
>> -------
>>  .../kern-tools/kern-tools-native_git.bb            |   4 +-
>>  2 files changed, 55 insertions(+), 92 deletions(-)
>>
>> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-
>> yocto.bbclass
>> index a9d4205..8650e55 100644
>> --- a/meta/classes/kernel-yocto.bbclass
>> +++ b/meta/classes/kernel-yocto.bbclass
>> @@ -119,77 +119,42 @@ do_kernel_metadata() {
>>  	patches="${@" ".join(find_patches(d))}"
>>  	feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"
>>
>> -	# add any explicitly referenced features onto the end of the
>> feature
>> -	# list that is passed to the kernel build scripts.
>> -	if [ -n "${KERNEL_FEATURES}" ]; then
>> -		for feat in ${KERNEL_FEATURES}; do
>> -			addon_features="$addon_features --feature $feat"
>> -		done
>> -	fi
>> -
>>  	# check for feature directories/repos/branches that were part of
>> the
>>  	# SRC_URI. If they were supplied, we convert them into include
>> directives
>>  	# for the update part of the process
>> -	if [ -n "${feat_dirs}" ]; then
>> -	    for f in ${feat_dirs}; do
>> +	for f in ${feat_dirs}; do
>>  		if [ -d "${WORKDIR}/$f/meta" ]; then
>> -		    includes="$includes -I${WORKDIR}/$f/meta"
>> +			includes="$includes -I${WORKDIR}/$f/meta"
>>  		elif [ -d "${WORKDIR}/$f" ]; then
>> -		    includes="$includes -I${WORKDIR}/$f"
>> +			includes="$includes -I${WORKDIR}/$f"
>>  		fi
>> -	    done
>> -	fi
>> +	done
>> +	for s in ${sccs}; do
>> +		sdir=$(dirname $s)
>> +		includes="$includes -I${sdir}"
>> +	done
>>
>> -	# updates or generates the target description
>> -	updateme ${updateme_flags}
>> -DKDESC=${KMACHINE}:${LINUX_KERNEL_TYPE} \
>> -                         ${includes} ${addon_features} ${ARCH}
>> ${KMACHINE} ${sccs} ${patches}
>> -	if [ $? -ne 0 ]; then
>> -		bbfatal_log "Could not update ${machine_branch}"
>> -	fi
>> +	# expand kernel features into their full path equivalents
>> +	bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
>> -DKTYPE=${LINUX_KERNEL_TYPE})
>> +	meta_dir=$(kgit --meta)
>> +
>> +	# run1: pull all the configuration fragments, no matter where
>> they come from
>> +	scc --force -o ${S}/${meta_dir}:cfg,meta ${includes}
>> ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}
>> +
>> +	# run2: only generate patches for elements that have been passed
>> on the SRC_URI
>> +	scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes}
>> ${sccs} ${patches} ${KERNEL_FEATURES}
>>  }
>>
>>  do_patch() {
>>  	cd ${S}
>>
>> -	# executes and modifies the source tree as required
>> -	patchme ${KMACHINE}
>> -	if [ $? -ne 0 ]; then
>> -		bberror "Could not apply patches for ${KMACHINE}."
>> -		bbfatal_log "Patch failures can be resolved in the linux
>> source directory ${S})"
>> -	fi
>> -
>> -	# check to see if the specified SRCREV is reachable from the
>> final branch.
>> -	# if it wasn't something wrong has happened, and we should error.
>> -	machine_srcrev="${SRCREV_machine}"
>> -	if [ -z "${machine_srcrev}" ]; then
>> -		# fallback to SRCREV if a non machine_meta tree is being
>> built
>> -		machine_srcrev="${SRCREV}"
>> -		# if SRCREV cannot be reached something is wrong.
>> -		if [ -z "${machine_srcrev}" ]; then
>> -			bbfatal "Neither SRCREV_machine or SRCREV was
>> specified!"
>> -		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"
>> -			bbfatal "Check the BSP description for incorrect
>> branch selection, or other errors."
>> +	meta_dir=$(kgit --meta)
>> +	(cd ${meta_dir}; ln -sf patch.queue series)
>> +	if [ -f "${meta_dir}/series" ]; then
>> +		kgit-s2q --gen -v --patches .kernel-meta/
>> +		if [ $? -ne 0 ]; then
>> +			bberror "Could not apply patches for
>> ${KMACHINE}."
>> +			bbfatal_log "Patch failures can be resolved in
>> the linux source directory ${S})"
>>  		fi
>>  	fi
>>  }
>> @@ -258,26 +223,37 @@ do_kernel_metadata[depends] = "kern-tools-
>> native:do_populate_sysroot"
>>
>>  do_kernel_configme[dirs] += "${S} ${B}"
>>  do_kernel_configme() {
>> -	bbnote "kernel configme"
>> -	export KMETA=${KMETA}
>> +	set +e
>>
>> -	if [ -n "${KCONFIG_MODE}" ]; then
>> -		configmeflags=${KCONFIG_MODE}
>> -	else
>> -		# If a defconfig was passed, use =n as the baseline,
>> which is achieved
>> -		# via --allnoconfig
>> +	# translate the kconfig_mode into something that merge_config.sh
>> +	# understands
>> +	case ${KCONFIG_MODE} in
>> +		allnoconfig)
>> +			config_flags="-n"
>> +			;;
>> +		alldefconfig)
>> +			config_flags=""
>> +			;;
>> +	    *)
>>  		if [ -f ${WORKDIR}/defconfig ]; then
>> -			configmeflags="--allnoconfig"
>> +			config_flags="-n"
>>  		fi
>> -	fi
>> +	    ;;
>> +	esac
>>
>>  	cd ${S}
>> -	PATH=${PATH}:${S}/scripts/util
>> -	configme ${configmeflags} --reconfig --output ${B}
>> ${LINUX_KERNEL_TYPE} ${KMACHINE}
>> +
>> +	meta_dir=$(kgit --meta)
>> +	configs="$(scc --configs -o ${meta_dir})"
>> +	if [ -z "${configs}" ]; then
>> +		bbfatal_log "Could not find configuration queue
>> (${meta_dir}/config.queue)"
>> +	fi
>> +
>> +	ARCH=${ARCH} merge_config.sh -O ${B} ${config_flags} ${configs} >
>> ${meta_dir}/cfg/merge_config_build.log 2>&1
>>  	if [ $? -ne 0 ]; then
>>  		bbfatal_log "Could not configure ${KMACHINE}-
>> ${LINUX_KERNEL_TYPE}"
>>  	fi
>> -	
>> +
>>  	echo "# Global settings from linux recipe" >> ${B}/.config
>>  	echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >>
>> ${B}/.config
>>  }
>> @@ -295,36 +271,23 @@ python do_kernel_configcheck() {
>>          kmeta = "." + kmeta
>>
>>      pathprefix = "export PATH=%s:%s; " % (d.getVar('PATH', True),
>> "${S}/scripts/util/")
>> -    cmd = d.expand("cd ${S}; kconf_check -config %s/meta-series ${S}
>> ${B}" % kmeta)
>> +
>> +    cmd = d.expand("scc --configs -o ${S}/.kernel-meta")
>> +    ret, configs = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
>> +
>> +    cmd = d.expand("cd ${S}; kconf_check --report -o ${S}/%s/cfg/
>> ${B}/.config ${S} %s" % (kmeta,configs))
>>      ret, result = oe.utils.getstatusoutput("%s%s" % (pathprefix, cmd))
>>
>>      config_check_visibility = int(d.getVar( "KCONF_AUDIT_LEVEL", True )
>> or 0)
>>      bsp_check_visibility = int(d.getVar( "KCONF_BSP_AUDIT_LEVEL", True )
>> or 0)
>>
>>      # if config check visibility is non-zero, report dropped
>> configuration values
>> -    mismatch_file = "${S}/" + kmeta + "/" + "mismatch.cfg"
>> +    mismatch_file = d.expand("${S}/%s/cfg/mismatch.txt" % kmeta)
>>      if os.path.exists(mismatch_file):
>>          if config_check_visibility:
>>              with open (mismatch_file, "r") as myfile:
>>                  results = myfile.read()
>>                  bb.warn( "[kernel config]: specified values did not make
>> it into the kernel's final configuration:\n\n%s" % results)
>> -
>> -    # if config check visibility is level 2 or higher, report non-
>> hardware options
>> -    nonhw_file = "${S}/" + kmeta + "/" + "nonhw_report.cfg"
>> -    if os.path.exists(nonhw_file):
>> -        if config_check_visibility > 1:
>> -            with open (nonhw_file, "r") as myfile:
>> -                results = myfile.read()
>> -                bb.warn( "[kernel config]: BSP specified non-hw
>> configuration:\n\n%s" % results)
>> -
>> -    bsp_desc = "${S}/" + kmeta + "/" + "top_tgt"
>> -    if os.path.exists(bsp_desc) and bsp_check_visibility > 1:
>> -        with open (bsp_desc, "r") as myfile:
>> -            bsp_tgt = myfile.read()
>> -            m = re.match("^(.*)scratch.obj(.*)$", bsp_tgt)
>> -            if not m is None:
>> -                bb.warn( "[kernel]: An auto generated BSP description was
>> used, this normally indicates a misconfiguration.\n" +
>> -                         "Check that your machine (%s) has an associated
>> kernel description." % "${MACHINE}" )
>>  }
>>
>>  # Ensure that the branches (BSP and meta) are on the locations specified
>> by
>> 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 c3ded98..6877a0c 100644
>> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> @@ -1,10 +1,10 @@
>>  SUMMARY = "Tools for managing Yocto Project style branched kernels"
>>  LICENSE = "GPLv2"
>> -LIC_FILES_CHKSUM =
>> "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70cd5f52972f8884
>> b80743d"
>> +LIC_FILES_CHKSUM =
>> "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1bda400e2828845
>> ba0d06c"
>>
>>  DEPENDS = "git-native"
>>
>> -SRCREV = "a6a6f6e1e738d2ecd26b675e9bec867105703416"
>> +SRCREV = "4b5de9011b31ff92ba2b6e052ab818b09affd905"
>>  PR = "r12"
>>  PV = "0.2+git${SRCPV}"
>>
>> --
>> 2.5.0
>>

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[André Draszik]

On Di, 2016-08-30 at 09:05 -0400, Bruce Ashfield wrote:
> On 2016-08-30 05:05 AM, André Draszik wrote:
> > 
> > My kmeta stuff is located directly inside two meta-* layers (i.e. not in
> > an
> > extra git repo), where the 2nd layer's kernel recipes .bbappends to the
> > 1st
> > one with additional kmeta things.
> > 
> > This used to work fine, but since this commit it doesn't anymore as only
> > the
> > kmeta stuff from the 2nd layer is being copied into workdir.
> > 
> > Have I been doing something that wasn't guaranteed / supposed to work in
> > the
> > first place? Or should that still work? Is it worth fixing or should I
> > rethink my approach?
> 
> That was complexity that I had tried to remove, but thinking on it a
> bit, I think I can restore that without adding much complexity.
> 
> I'm just finishing work on the 4.8 kernel today, and can look at this
> tomorrow.

Thank you Bruce!

> Do you have any public layers that I can reference to pull together a
> test case ?

Unfortunately not :-(

But I'm happy to test and report back!


Cheers,
Andre'

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[Bruce Ashfield]

On 2016-08-30 10:19 AM, André Draszik wrote:
> On Di, 2016-08-30 at 09:05 -0400, Bruce Ashfield wrote:
>> On 2016-08-30 05:05 AM, André Draszik wrote:
>>>
>>> My kmeta stuff is located directly inside two meta-* layers (i.e. not in
>>> an
>>> extra git repo), where the 2nd layer's kernel recipes .bbappends to the
>>> 1st
>>> one with additional kmeta things.
>>>
>>> This used to work fine, but since this commit it doesn't anymore as only
>>> the
>>> kmeta stuff from the 2nd layer is being copied into workdir.
>>>
>>> Have I been doing something that wasn't guaranteed / supposed to work in
>>> the
>>> first place? Or should that still work? Is it worth fixing or should I
>>> rethink my approach?
>>
>> That was complexity that I had tried to remove, but thinking on it a
>> bit, I think I can restore that without adding much complexity.
>>
>> I'm just finishing work on the 4.8 kernel today, and can look at this
>> tomorrow.
>
> Thank you Bruce!

Can you clarify for me if you are are using SRC_URI items tagged with
'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
items directly to the SRC_URI ?

Bruce

>
>> Do you have any public layers that I can reference to pull together a
>> test case ?
>
> Unfortunately not :-(
>
> But I'm happy to test and report back!
>
>
> Cheers,
> Andre'
>

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[André Draszik]

On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote:
> Can you clarify for me if you are are using SRC_URI items tagged with
> 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
> items directly to the SRC_URI ?

I do both:

in the 1st layer, my kernel recipe boils down to:

SRC_URI = "\
    git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
    file://0001-a-patch.patch \
    file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
"

KERNEL_FEATURES_append = " patches/some-patches.scc"
KERNEL_FEATURES_append = " patches/more-patches.scc"
KERNEL_FEATURES_append = " patches/even-more-patches.scc"

some of the above in turn include additional .scc items recursively.


In the 2nd layer, my .bbappend boils down to:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"

KERNEL_FEATURES_append_tgm = " patches/tgm.scc"

2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd
layer. I don't specifically add another SRC_URI item tagged with 'kmeta' (or
any other explicit SRC_URI item for that matter).


Andre'

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[Bruce Ashfield]

On 2016-08-31 4:54 AM, André Draszik wrote:
> On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote:
>> Can you clarify for me if you are are using SRC_URI items tagged with
>> 'kmeta', i.e. a directory of fragments, or are you just adding .cfg/.scc
>> items directly to the SRC_URI ?
>
> I do both:
>
> in the 1st layer, my kernel recipe boils down to:
>
> SRC_URI = "\
>     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
>     file://0001-a-patch.patch \
>     file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
> "
>
> KERNEL_FEATURES_append = " patches/some-patches.scc"
> KERNEL_FEATURES_append = " patches/more-patches.scc"
> KERNEL_FEATURES_append = " patches/even-more-patches.scc"
>
> some of the above in turn include additional .scc items recursively.
>
>
> In the 2nd layer, my .bbappend boils down to:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"
>
> KERNEL_FEATURES_append_tgm = " patches/tgm.scc"
>
> 2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd
> layer. I don't specifically add another SRC_URI item tagged with 'kmeta' (or
> any other explicit SRC_URI item for that matter).

One more clarification. From our problem description, are you saying
that in your runs, only the meta data from layer2 is getting copied
and not that from layer1 ?

I ran my sanity test, and saw meta data from both my layers copied ..
so I'm worried that I misunderstood the issue you are seeing.

But looking at the code, I can definitely do some minor tweaks in this
area .. I'm just trying to get the reproducer nailed down.

Bruce

>
>
> Andre'
>

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[André Draszik]

On Mi, 2016-08-31 at 16:17 -0400, Bruce Ashfield wrote:
> On 2016-08-31 4:54 AM, André Draszik wrote:
> > 
> > On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote:
> > > 
> > > Can you clarify for me if you are are using SRC_URI items tagged with
> > > 'kmeta', i.e. a directory of fragments, or are you just adding
> > > .cfg/.scc
> > > items directly to the SRC_URI ?
> > 
> > I do both:
> > 
> > in the 1st layer, my kernel recipe boils down to:
> > 
> > SRC_URI = "\
> >     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
> > stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
> >     file://0001-a-patch.patch \
> >     file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
> > "
> > 
> > KERNEL_FEATURES_append = " patches/some-patches.scc"
> > KERNEL_FEATURES_append = " patches/more-patches.scc"
> > KERNEL_FEATURES_append = " patches/even-more-patches.scc"
> > 
> > some of the above in turn include additional .scc items recursively.
> > 
> > 
> > In the 2nd layer, my .bbappend boils down to:
> > 
> > FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"
> > 
> > KERNEL_FEATURES_append_tgm = " patches/tgm.scc"
> > 
> > 2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd
> > layer. I don't specifically add another SRC_URI item tagged with 'kmeta'
> > (or
> > any other explicit SRC_URI item for that matter).
> 
> One more clarification. From our problem description, are you saying
> that in your runs, only the meta data from layer2 is getting copied
> and not that from layer1 ?

That is what I had inferred from the error message:

| DEBUG: Executing shell function do_kernel_metadata
| ERROR. input file "patches/some-patches.scc" does not exist
| ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
|        See /tmp/tmp.mPP1jtatxm for details
| ERROR. input file "patches/some-patches.scc" does not exist
| ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
|        See /tmp/tmp.v9LU9ccpbl for details
| WARNING: exit code 1 from a shell command.


> I ran my sanity test, and saw meta data from both my layers copied ..
> so I'm worried that I misunderstood the issue you are seeing.

I can see that they are actually copied indeed, but it doesn't find them...
The file /tmp/tmp.v9LU9ccpbl mentioned above is empty.

> But looking at the code, I can definitely do some minor tweaks in this
> area .. I'm just trying to get the reproducer nailed down.

I can try to create one for you if you prefer tomorrow, rather than wasting
your time with this, if you don't get any further?


Andre'

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[Bruce Ashfield]

On 2016-09-01 12:14 PM, André Draszik wrote:
> On Mi, 2016-08-31 at 16:17 -0400, Bruce Ashfield wrote:
>> On 2016-08-31 4:54 AM, André Draszik wrote:
>>>
>>> On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote:
>>>>
>>>> Can you clarify for me if you are are using SRC_URI items tagged with
>>>> 'kmeta', i.e. a directory of fragments, or are you just adding
>>>> .cfg/.scc
>>>> items directly to the SRC_URI ?
>>>
>>> I do both:
>>>
>>> in the 1st layer, my kernel recipe boils down to:
>>>
>>> SRC_URI = "\
>>>     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
>>> stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
>>>     file://0001-a-patch.patch \
>>>     file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
>>> "
>>>
>>> KERNEL_FEATURES_append = " patches/some-patches.scc"
>>> KERNEL_FEATURES_append = " patches/more-patches.scc"
>>> KERNEL_FEATURES_append = " patches/even-more-patches.scc"
>>>
>>> some of the above in turn include additional .scc items recursively.
>>>
>>>
>>> In the 2nd layer, my .bbappend boils down to:
>>>
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"
>>>
>>> KERNEL_FEATURES_append_tgm = " patches/tgm.scc"
>>>
>>> 2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd
>>> layer. I don't specifically add another SRC_URI item tagged with 'kmeta'
>>> (or
>>> any other explicit SRC_URI item for that matter).
>>
>> One more clarification. From our problem description, are you saying
>> that in your runs, only the meta data from layer2 is getting copied
>> and not that from layer1 ?
>
> That is what I had inferred from the error message:
>
> | DEBUG: Executing shell function do_kernel_metadata
> | ERROR. input file "patches/some-patches.scc" does not exist
> | ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
> |        See /tmp/tmp.mPP1jtatxm for details
> | ERROR. input file "patches/some-patches.scc" does not exist
> | ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
> |        See /tmp/tmp.v9LU9ccpbl for details
> | WARNING: exit code 1 from a shell command.
>
>
>> I ran my sanity test, and saw meta data from both my layers copied ..
>> so I'm worried that I misunderstood the issue you are seeing.
>
> I can see that they are actually copied indeed, but it doesn't find them...
> The file /tmp/tmp.v9LU9ccpbl mentioned above is empty.

Yah, that's a temporary file used in the processing. I'm going to clean
up the logging a bit as I work through this.

I think I can fix things with some path manipulations, but am still
working on it.

>
>> But looking at the code, I can definitely do some minor tweaks in this
>> area .. I'm just trying to get the reproducer nailed down.
>
> I can try to create one for you if you prefer tomorrow, rather than wasting
> your time with this, if you don't get any further?

I'm going to be trying this later tonight (Thursday, Eastern Time), but
even if you can throw a mock up out, it will help me debug more.

Bruce

>
>
> Andre'
>

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[Bruce Ashfield]

On 2016-09-01 12:14 PM, André Draszik wrote:
> On Mi, 2016-08-31 at 16:17 -0400, Bruce Ashfield wrote:
>> On 2016-08-31 4:54 AM, André Draszik wrote:
>>>
>>> On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote:
>>>>
>>>> Can you clarify for me if you are are using SRC_URI items tagged with
>>>> 'kmeta', i.e. a directory of fragments, or are you just adding
>>>> .cfg/.scc
>>>> items directly to the SRC_URI ?
>>>
>>> I do both:
>>>
>>> in the 1st layer, my kernel recipe boils down to:
>>>
>>> SRC_URI = "\
>>>     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
>>> stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
>>>     file://0001-a-patch.patch \
>>>     file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
>>> "
>>>
>>> KERNEL_FEATURES_append = " patches/some-patches.scc"
>>> KERNEL_FEATURES_append = " patches/more-patches.scc"
>>> KERNEL_FEATURES_append = " patches/even-more-patches.scc"
>>>
>>> some of the above in turn include additional .scc items recursively.
>>>
>>>
>>> In the 2nd layer, my .bbappend boils down to:
>>>
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"
>>>
>>> KERNEL_FEATURES_append_tgm = " patches/tgm.scc"
>>>
>>> 2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd
>>> layer. I don't specifically add another SRC_URI item tagged with 'kmeta'
>>> (or
>>> any other explicit SRC_URI item for that matter).
>>
>> One more clarification. From our problem description, are you saying
>> that in your runs, only the meta data from layer2 is getting copied
>> and not that from layer1 ?
>
> That is what I had inferred from the error message:
>
> | DEBUG: Executing shell function do_kernel_metadata
> | ERROR. input file "patches/some-patches.scc" does not exist
> | ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
> |        See /tmp/tmp.mPP1jtatxm for details
> | ERROR. input file "patches/some-patches.scc" does not exist
> | ERROR: could not process input files: <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch patches/some-patches.scc patches/more-patches.scc patches/even-more-patches.scc patches/tgm.scc
> |        See /tmp/tmp.v9LU9ccpbl for details
> | WARNING: exit code 1 from a shell command.
>
>
>> I ran my sanity test, and saw meta data from both my layers copied ..
>> so I'm worried that I misunderstood the issue you are seeing.
>
> I can see that they are actually copied indeed, but it doesn't find them...
> The file /tmp/tmp.v9LU9ccpbl mentioned above is empty.
>
>> But looking at the code, I can definitely do some minor tweaks in this
>> area .. I'm just trying to get the reproducer nailed down.
>
> I can try to create one for you if you prefer tomorrow, rather than wasting
> your time with this, if you don't get any further?

I was able to trigger a similar trap to the above. And yes, it was sort
of working by luck before.

I need to stare at this for a few hours and figure out the right way to
restore similar behaviour. But now .. sleep.

Cheers,

Bruce

>
>
> Andre'
>

Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases

[Bruce Ashfield]

On 2016-09-01 11:18 PM, Bruce Ashfield wrote:
> On 2016-09-01 12:14 PM, André Draszik wrote:
>> On Mi, 2016-08-31 at 16:17 -0400, Bruce Ashfield wrote:
>>> On 2016-08-31 4:54 AM, André Draszik wrote:
>>>>
>>>> On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote:
>>>>>
>>>>> Can you clarify for me if you are are using SRC_URI items tagged with
>>>>> 'kmeta', i.e. a directory of fragments, or are you just adding
>>>>> .cfg/.scc
>>>>> items directly to the SRC_URI ?
>>>>
>>>> I do both:
>>>>
>>>> in the 1st layer, my kernel recipe boils down to:
>>>>
>>>> SRC_URI = "\
>>>>     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
>>>> stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \
>>>>     file://0001-a-patch.patch \
>>>>     file://kernel-meta;type=kmeta;destsuffix=${KMETA} \
>>>> "
>>>>
>>>> KERNEL_FEATURES_append = " patches/some-patches.scc"
>>>> KERNEL_FEATURES_append = " patches/more-patches.scc"
>>>> KERNEL_FEATURES_append = " patches/even-more-patches.scc"
>>>>
>>>> some of the above in turn include additional .scc items recursively.
>>>>
>>>>
>>>> In the 2nd layer, my .bbappend boils down to:
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:"
>>>>
>>>> KERNEL_FEATURES_append_tgm = " patches/tgm.scc"
>>>>
>>>> 2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd
>>>> layer. I don't specifically add another SRC_URI item tagged with
>>>> 'kmeta'
>>>> (or
>>>> any other explicit SRC_URI item for that matter).
>>>
>>> One more clarification. From our problem description, are you saying
>>> that in your runs, only the meta data from layer2 is getting copied
>>> and not that from layer1 ?
>>
>> That is what I had inferred from the error message:
>>
>> | DEBUG: Executing shell function do_kernel_metadata
>> | ERROR. input file "patches/some-patches.scc" does not exist
>> | ERROR: could not process input files:
>> <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig
>> <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch
>> patches/some-patches.scc patches/more-patches.scc
>> patches/even-more-patches.scc patches/tgm.scc
>> |        See /tmp/tmp.mPP1jtatxm for details
>> | ERROR. input file "patches/some-patches.scc" does not exist
>> | ERROR: could not process input files:
>> <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig
>> <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch
>> patches/some-patches.scc patches/more-patches.scc
>> patches/even-more-patches.scc patches/tgm.scc
>> |        See /tmp/tmp.v9LU9ccpbl for details
>> | WARNING: exit code 1 from a shell command.
>>
>>
>>> I ran my sanity test, and saw meta data from both my layers copied ..
>>> so I'm worried that I misunderstood the issue you are seeing.
>>
>> I can see that they are actually copied indeed, but it doesn't find
>> them...
>> The file /tmp/tmp.v9LU9ccpbl mentioned above is empty.
>>
>>> But looking at the code, I can definitely do some minor tweaks in this
>>> area .. I'm just trying to get the reproducer nailed down.
>>
>> I can try to create one for you if you prefer tomorrow, rather than
>> wasting
>> your time with this, if you don't get any further?
>
> I was able to trigger a similar trap to the above. And yes, it was sort
> of working by luck before.

I spoke too soon. The error that I was able to trigger was valid,
and in fact, when I tried the same test on krogoth it also failed
there as well.

So there is something I still don't have right in the two layers to
trigger the same scenario you are seeing.

If you could do that mock up, it would help immensely.

Also, if you are open to changing the layer structure a bit, I could
always suggest a new way to organize things.

Cheers,

Bruce

>
> I need to stare at this for a few hours and figure out the right way to
> restore similar behaviour. But now .. sleep.
>
> Cheers,
>
> Bruce
>
>>
>>
>> Andre'
>>
>

[PATCH 6/6] yocto-bsp/yocto-kernel: update to work with the latest kern-tools

[Bruce Ashfield]

With some recent changes in the kern tools, we can drop some changes in
the yocto-bsp and yocto-kernel tools that ensured proper patching and
BSP inheritance.

In particular, we no longer need to signify the start of patching, and
we must instruct the tools that we only want configuration fragments
via inheritance .. no patches (since they are already applied).

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 scripts/lib/bsp/kernel.py                                      |  1 -
 .../arch/arm/recipes-kernel/linux/files/machine-standard.scc   |  2 +-
 .../arch/i386/recipes-kernel/linux/files/machine-standard.scc  |  2 +-
 .../arch/mips/recipes-kernel/linux/files/machine-standard.scc  |  2 +-
 .../mips64/recipes-kernel/linux/files/machine-standard.scc     |  2 +-
 .../powerpc/recipes-kernel/linux/files/machine-standard.scc    |  2 +-
 .../arch/qemu/recipes-kernel/linux/files/machine-standard.scc  | 10 +++++-----
 .../x86_64/recipes-kernel/linux/files/machine-standard.scc     |  2 +-
 8 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/scripts/lib/bsp/kernel.py b/scripts/lib/bsp/kernel.py
index 32cab3b..a3ee325 100644
--- a/scripts/lib/bsp/kernel.py
+++ b/scripts/lib/bsp/kernel.py
@@ -331,7 +331,6 @@ def write_patch_items(scripts_path, machine, patch_items):
     patch list [${machine}-user-patches.scc].
     """
     f = open_user_file(scripts_path, machine, machine+"-user-patches.scc", "w")
-    f.write("mark patching start\n")
     for item in patch_items:
         f.write("patch " + item + "\n")
     f.close()
diff --git a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/files/machine-standard.scc b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/files/machine-standard.scc
index 405972d..8a88157 100644
--- a/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/files/machine-standard.scc
+++ b/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel/linux/files/machine-standard.scc
@@ -3,7 +3,7 @@ define KMACHINE {{=machine}}
 
 define KARCH arm
 
-include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}}
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}} nopatch
 {{ if need_new_kbranch == "y": }}
 define KTYPE {{=new_kbranch}}
 branch {{=machine}}
diff --git a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine-standard.scc b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine-standard.scc
index 67a54be..38d1ca5 100644
--- a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine-standard.scc
+++ b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine-standard.scc
@@ -3,7 +3,7 @@ define KMACHINE {{=machine}}
 
 define KARCH i386
 
-include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}}
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}} nopatch
 {{ if need_new_kbranch == "y": }}
 define KTYPE {{=new_kbranch}}
 branch {{=machine}}
diff --git a/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/files/machine-standard.scc b/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/files/machine-standard.scc
index 7c9dc52..b34f3d3 100644
--- a/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/files/machine-standard.scc
+++ b/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel/linux/files/machine-standard.scc
@@ -3,7 +3,7 @@ define KMACHINE {{=machine}}
 
 define KARCH mips
 
-include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}}
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}} nopatch
 {{ if need_new_kbranch == "y": }}
 define KTYPE {{=new_kbranch}}
 branch {{=machine}}
diff --git a/scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/files/machine-standard.scc b/scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/files/machine-standard.scc
index 7c9dc52..b34f3d3 100644
--- a/scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/files/machine-standard.scc
+++ b/scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel/linux/files/machine-standard.scc
@@ -3,7 +3,7 @@ define KMACHINE {{=machine}}
 
 define KARCH mips
 
-include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}}
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}} nopatch
 {{ if need_new_kbranch == "y": }}
 define KTYPE {{=new_kbranch}}
 branch {{=machine}}
diff --git a/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/files/machine-standard.scc b/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/files/machine-standard.scc
index 89b344f..c166fcd 100644
--- a/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/files/machine-standard.scc
+++ b/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel/linux/files/machine-standard.scc
@@ -3,7 +3,7 @@ define KMACHINE {{=machine}}
 
 define KARCH powerpc
 
-include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}}
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}} nopatch
 {{ if need_new_kbranch == "y": }}
 define KTYPE {{=new_kbranch}}
 branch {{=machine}}
diff --git a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/machine-standard.scc b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/machine-standard.scc
index 14554da..43cf642 100644
--- a/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/machine-standard.scc
+++ b/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel/linux/files/machine-standard.scc
@@ -4,15 +4,15 @@ define KMACHINE {{=machine}}
 define KARCH {{=qemuarch}}
 
 {{ if qemuarch == "i386" or qemuarch == "x86_64": }}
-include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}}
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}} nopatch
 {{ if qemuarch == "arm": }}
-include bsp/arm-versatile-926ejs/arm-versatile-926ejs-standard
+include bsp/arm-versatile-926ejs/arm-versatile-926ejs-standard nopatch
 {{ if qemuarch == "powerpc": }}
-include bsp/qemu-ppc32/qemu-ppc32-standard
+include bsp/qemu-ppc32/qemu-ppc32-standard nopatch
 {{ if qemuarch == "mips": }}
-include bsp/mti-malta32/mti-malta32-be-standard
+include bsp/mti-malta32/mti-malta32-be-standard nopatch
 {{ if qemuarch == "mips64": }}
-include bsp/mti-malta64/mti-malta64-be-standard
+include bsp/mti-malta64/mti-malta64-be-standard nopatch
 {{ if need_new_kbranch == "y": }}
 define KTYPE {{=new_kbranch}}
 branch {{=machine}}
diff --git a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/machine-standard.scc b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/machine-standard.scc
index 9c9cc90..a2b2910 100644
--- a/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/machine-standard.scc
+++ b/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel/linux/files/machine-standard.scc
@@ -3,7 +3,7 @@ define KMACHINE {{=machine}}
 
 define KARCH x86_64
 
-include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}}
+include {{=map_standard_kbranch(need_new_kbranch, new_kbranch, existing_kbranch)}} nopatch
 {{ if need_new_kbranch == "y": }}
 define KTYPE {{=new_kbranch}}
 branch {{=machine}}
-- 
2.5.0

Re: [PATCH 0/6] kernel-yocto: consolidated pull request

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

On 15 August 2016 at 19:26, Bruce Ashfield <bruce.ashfield@windriver.com>
wrote:

> Are the important part of this series, and a significant contribution to
> the
> fall release. I've been testing these for some time, and we've run the
> kernel lab and yocto-bsp scripts against the tools. We haven't found a
> regression yet, but I'm sure there are some lurking. These definitely need
> cycles on the autobuilders.
>

qemux86 throws these warnings at me:

WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_ddab242999-r0
do_kernel_configcheck: [kernel config]: specified values did not make it
into the kernel's final configuration:

---------- CONFIG_BT_6LOWPAN -----------------
Config: CONFIG_BT_6LOWPAN
From:
/data/poky-master/tmp-glibc/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
Requested value:  CONFIG_BT_6LOWPAN=y
Actual value:

Config 'BT_6LOWPAN' has the following conditionals:
  BT_LE && 6LOWPAN (value: "n")
Dependency values are:
  BT_LE [y] 6LOWPAN [n]

---------- CONFIG_BT_CMTP -----------------
Config: CONFIG_BT_CMTP
From:
/data/poky-master/tmp-glibc/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
Requested value:  CONFIG_BT_CMTP=m
Actual value:

Config 'BT_CMTP' has the following conditionals:
  BT_BREDR && ISDN_CAPI (value: "n")
Dependency values are:
  BT_BREDR [y] ISDN_CAPI [n]

Ross

[-- Attachment #2: Type: text/html, Size: 2727 bytes --]

Re: [PATCH 0/6] kernel-yocto: consolidated pull request

[Bruce Ashfield]

On 2016-08-16 12:00 PM, Burton, Ross wrote:
>
> On 15 August 2016 at 19:26, Bruce Ashfield <bruce.ashfield@windriver.com
> <mailto:bruce.ashfield@windriver.com>> wrote:
>
>     Are the important part of this series, and a significant
>     contribution to the
>     fall release. I've been testing these for some time, and we've run the
>     kernel lab and yocto-bsp scripts against the tools. We haven't found a
>     regression yet, but I'm sure there are some lurking. These
>     definitely need
>     cycles on the autobuilders.
>
>
> qemux86 throws these warnings at me:

Yep, that was covered in my 0/N:

"Note: there are still warnings in the kernel meta-data, they are being 
worked
on, but I've left them in place so a few people can see the new kernel audit
information :)"

Cheers,

Bruce

>
> WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_ddab242999-r0
> do_kernel_configcheck: [kernel config]: specified values did not make it
> into the kernel's final configuration:
>
> ---------- CONFIG_BT_6LOWPAN -----------------
> Config: CONFIG_BT_6LOWPAN
> From:
> /data/poky-master/tmp-glibc/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
> Requested value:  CONFIG_BT_6LOWPAN=y
> Actual value:
>
> Config 'BT_6LOWPAN' has the following conditionals:
>   BT_LE && 6LOWPAN (value: "n")
> Dependency values are:
>   BT_LE [y] 6LOWPAN [n]
>
> ---------- CONFIG_BT_CMTP -----------------
> Config: CONFIG_BT_CMTP
> From:
> /data/poky-master/tmp-glibc/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
> Requested value:  CONFIG_BT_CMTP=m
> Actual value:
>
> Config 'BT_CMTP' has the following conditionals:
>   BT_BREDR && ISDN_CAPI (value: "n")
> Dependency values are:
>   BT_BREDR [y] ISDN_CAPI [n]
>
> Ross

Re: [PATCH 0/6] kernel-yocto: consolidated pull request

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 164 bytes --]

On 16 August 2016 at 17:01, Bruce Ashfield <bruce.ashfield@windriver.com>
wrote:

> Yep, that was covered in my 0/N:
>

<cough>

I'll get my coat.

Ross

[-- Attachment #2: Type: text/html, Size: 592 bytes --]

Re: [PATCH 0/6] kernel-yocto: consolidated pull request

[Bruce Ashfield]

On 2016-08-16 12:10 PM, Burton, Ross wrote:
>
> On 16 August 2016 at 17:01, Bruce Ashfield <bruce.ashfield@windriver.com
> <mailto:bruce.ashfield@windriver.com>> wrote:
>
>     Yep, that was covered in my 0/N:
>
>
> <cough>
>
> I'll get my coat.

... and hopefully hit me with it for hiding that note way down in a
TL;DR 0/N message.

Bruce



>
> Ross

Re: [PATCH 0/6] kernel-yocto: consolidated pull request

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

On 16 August 2016 at 17:11, Bruce Ashfield <bruce.ashfield@windriver.com>
wrote:

> ... and hopefully hit me with it for hiding that note way down in a
> TL;DR 0/N message.
>

Oh it was definitely sensible, you covered everything in the cover letter
that I only skimmed last week and promptly forgot...

Ross

[-- Attachment #2: Type: text/html, Size: 731 bytes --]

[PATCH 0/6] kernel-yocto: consolidated pull request

[Bruce Ashfield]

Hi all,

This pull request includes -stable updates for all the kernels that are
currently in master.  I'll be dropping one kernel as I move to 4.12+ for
the fall release, but for now, they all continue to get updates.

I've done smoke build/boot testing on the updates, but the build matrix
is huge, so I'll keep an eye on any autobuilder results just in case
something slipped through.

We also have some configuration changes and a bug fix to the kern-tools
when a BSP includes a file and inhibits patches.

Cheers,

Bruce

The following changes since commit 4a7612c7a12b9a381fb8343ba9586272b889fc15:

  buildhistory: skip tests if GitPython module is missing (2017-06-07 16:00:49 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (6):
  linux-yocto/meta: configuration changes (wifi, kexec and nft)
  kern-tools: avoid syntax errors when inheriting meta data
  linux-yocto-rt: 4.9-rt18
  linux-yocto/4.10: update to v4.10.17
  linux-yocto/4.9: update to 4.9.31
  linux-yocto/4.4: update to v4.4.71

 .../kern-tools/kern-tools-native_git.bb              |  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb     |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb      |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb      |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb    |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb    |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.10.bb        | 20 ++++++++++----------
 meta/recipes-kernel/linux/linux-yocto_4.4.bb         | 20 ++++++++++----------
 meta/recipes-kernel/linux/linux-yocto_4.9.bb         | 20 ++++++++++----------
 10 files changed, 49 insertions(+), 49 deletions(-)

-- 
2.5.0

[PATCH 0/6] kernel-yocto: consolidated pull request

[Bruce Ashfield]

Hi all,

There are a couple of repeated patches in this series, but I'm
sending them along just to make sure that all my pending patches
are grouped together.

In this series, we have a configuratiion tweak (that fixes a build
warning), -stable updates for all the active kernels, a bug fix for
error propagation .. and finally a bump of linux-yocto-dev to
4.12+.

The next LTS kernel was picked to be 4.14, so once again, we are
going to be in an awkward timing window for the release. To make
sure that we are ready for whatever the timing is, I've bumped
this to 4.12 and integrated the pre-rc1 changes into the tree ..
so this puts -dev at somewhere between 4.12 and 4.13 with this
update.

cheers,

Bruce

The following changes since commit 854c8c2e4c24ea3ddfec6e5b5f6477f0620510e4:

  oeqa/tinfoil: Improve test_wait_event for race issues (2017-07-08 13:34:46 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (6):
  kernel-yocto: propagate configuration errors to bbclass
  kernel-yocto/meta: smp configuration changes
  linux-yocto/4.1: update to v4.1.41
  linux-yocto/4.4: update to v4.4.76
  linux-yocto/4.9: update to v4.9.36
  linux-yocto-dev: bump to 4.12+

 meta/classes/kernel-yocto.bbclass                  |  3 ++-
 meta/recipes-kernel/linux/linux-yocto-dev.bb       |  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb    |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb   |  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb    |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb    |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb  |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb |  2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb  |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb  |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb       | 20 ++++++++++----------
 meta/recipes-kernel/linux/linux-yocto_4.10.bb      |  2 +-
 meta/recipes-kernel/linux/linux-yocto_4.4.bb       | 20 ++++++++++----------
 meta/recipes-kernel/linux/linux-yocto_4.9.bb       | 20 ++++++++++----------
 14 files changed, 54 insertions(+), 53 deletions(-)

-- 
2.5.0

[PATCH 0/6] kernel-yocto: consolidated pull request

[Bruce Ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Richard,

Here's my queued set of update to linux -yocto. These are -stable, and of
course the AB INT fix provided by paulg.

The other change is one to the -dev kernel that allows the single AUTOREV
recipe to continue to work in older releases as we march through newer
kernels in master. Some users ran into this problem recently, and have
tested/confirmed the fix. There's no change to anyone but a linux-yocto-dev
kernel consumer.

Cheers,

Bruce

The following changes since commit 682ddc5f2a2493e5c7760c0745dacd24fe975479:

  releases: put release number after "Release Series" (2021-06-14 22:45:33 +0100)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (6):
  linux-yocto-dev: base AUTOREV on specified version
  linux-yocto/5.4: update to v5.4.124
  linux-yocto/5.10: restore aufs
  linux-yocto/5.10: update to v5.10.43
  linux-yocto/5.4: update to v5.4.125
  linux-yocto/5.10: cgroup1: fix leaked context root causing sporadic
    NULL deref in LTP

 meta/classes/kernel-yocto.bbclass             | 24 +++++++++++++++++++
 .../linux/linux-yocto-rt_5.10.bb              |  6 ++---
 .../linux/linux-yocto-rt_5.4.bb               |  6 ++---
 .../linux/linux-yocto-tiny_5.10.bb            |  8 +++----
 .../linux/linux-yocto-tiny_5.4.bb             |  8 +++----
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 +++++++++----------
 meta/recipes-kernel/linux/linux-yocto_5.4.bb  | 22 ++++++++---------
 7 files changed, 61 insertions(+), 37 deletions(-)

-- 
2.19.1

[PATCH 0/6] kernel-yocto: consolidated pull request

[Bruce Ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Richard,

Here's the next set of -stable updates to the active kernels, a -rt
bugfix import and some configuration tweaks requested by Ross.

I do have commits locally to make 5.13 the default kernel for the
reference poky layers, but I'm heading out on vacation and won't
be around to do a lot of debugging if they cause issues.

I was planning on holding them and sending them, plus the 5.4 removal
in mid August. If you want them sooner, or for testing, I can make
them available .. just let me know.

Bruce

The following changes since commit 4a1381d350aa1acc75ca1e6d03b8067483c162f5:

  archiver.bbclass: fix do_ar_configured failure for kernel (2021-07-28 23:47:00 +0100)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (6):
  linux-yocto/5.10: update to v5.10.53
  linux-yocto/5.13: update to v5.13.5
  linux-yocto/5.4: update to v5.4.135
  linux-yocto-rt/5.10: update to -rt47
  linux-yocto/5.10: enable TYPEC_TCPCI in usbc fragment
  linux-yocto/5.13: enable TYPEC_TCPCI in usbc fragment

 .../linux/linux-yocto-rt_5.10.bb              |  6 ++---
 .../linux/linux-yocto-rt_5.13.bb              |  6 ++---
 .../linux/linux-yocto-rt_5.4.bb               |  6 ++---
 .../linux/linux-yocto-tiny_5.10.bb            |  8 +++---
 .../linux/linux-yocto-tiny_5.13.bb            |  8 +++---
 .../linux/linux-yocto-tiny_5.4.bb             |  8 +++---
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 ++++++++---------
 meta/recipes-kernel/linux/linux-yocto_5.13.bb | 26 +++++++++----------
 meta/recipes-kernel/linux/linux-yocto_5.4.bb  | 22 ++++++++--------
 9 files changed, 57 insertions(+), 57 deletions(-)

-- 
2.19.1

[PATCH 0/6] kernel-yocto: consolidated pull request

[bruce.ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Richard,

A few aufs fixes, -stable and a configuration fixup for ARM/x86 split,
but otherwise, not a lot here.

I know the release is going to be cut shortly, so these can either be
post or in the release, obviously up to you. I'm sitting on other
changes that might cause issues, and will send them after the release.

Bruce


The following changes since commit 6459a06f2ed7d47f5df0c50d95e182e432311d53:

  unzip: fix CVE-2021-4217 (2022-04-04 13:00:16 +0100)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (6):
  linux-yocto/5.15: update to v5.15.32
  linux-yocto/5.10: update to v5.10.109
  linux-yocto/5.15: aufs: fixes and optimization
  linux-yocto-rt/5.15: aufs: compile fix
  linux-yocto/5.15: features/security: Move x86_64 configs to separate
    file
  linux-yocto/5.10: features/security: Move x86_64 configs to separate
    file

 .../linux/linux-yocto-rt_5.10.bb              |  6 ++---
 .../linux/linux-yocto-rt_5.15.bb              |  6 ++---
 .../linux/linux-yocto-tiny_5.10.bb            |  8 +++---
 .../linux/linux-yocto-tiny_5.15.bb            |  8 +++---
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 ++++++++---------
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +++++++++----------
 6 files changed, 39 insertions(+), 39 deletions(-)

-- 
2.19.1