[OE-core][Patch 1/2] kernel-yocto.bbclass: set +e in do_configme

[OE-core][Patch 1/2] kernel-yocto.bbclass: set +e in do_configme

[Max Krummenacher]

The script test the error code to give usefull debug output.
Aborting right after the failing process prevents that output.

This partly reverts commit ec281a948a ("kernel-yocto.bbclass:
do_kernel_configme: don't use +errexit, merge_config_build.log
and fail when /.config wasn't created")

Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
---
 meta/classes/kernel-yocto.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 54a1a1627a..7cedb05e93 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -338,6 +338,7 @@ do_kernel_configme[depends] += "bc-native:do_populate_sysroot bison-native:do_po
 do_kernel_configme[depends] += "kern-tools-native:do_populate_sysroot"
 do_kernel_configme[dirs] += "${S} ${B}"
 do_kernel_configme() {
+	set +e
 	# translate the kconfig_mode into something that merge_config.sh
 	# understands
 	case ${KCONFIG_MODE} in
-- 
2.20.1

[OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Max Krummenacher]

In the case of no patches or no configure fragments, during
do_kernel_metadata() scc is not called, and thus
kernel-sources/${meta_dir}/config.queue is not created.
Later do_kernel_configme fails because the file is missing.

| ERROR: Execution of 'run.do_kernel_configme.24874' failed with exit code 1:
| exit 1 from 'configs="$(scc --configs -o ${meta_dir})"'

Forcing at least an empty config.queue file fixes this.

Fixes: 23dcff0d396c (kernel/yocto: ensure that defconfigs are processed first)
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
---
 meta/classes/kernel-yocto.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 7cedb05e93..7ea3cb5e51 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -220,6 +220,8 @@ do_kernel_metadata() {
 		if [ $? -ne 0 ]; then
 			bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
 		fi
+	else
+		touch ${S}/${meta_dir}/config.queue
 	fi
 
 	# if KMETA_EXTERNAL_BSPS has been set, or it has been detected from
-- 
2.20.1

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Bruce Ashfield]

On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
>
> In the case of no patches or no configure fragments, during
> do_kernel_metadata() scc is not called, and thus
> kernel-sources/${meta_dir}/config.queue is not created.
> Later do_kernel_configme fails because the file is missing.

This is a really strange case, since in tree and defconfigs go through
the queue.

How are you ending up in this situation in the first place?

I'd rather not force create this, but detect the misconfiguration and
output a useful error message.

Bruce

>
> | ERROR: Execution of 'run.do_kernel_configme.24874' failed with exit code 1:
> | exit 1 from 'configs="$(scc --configs -o ${meta_dir})"'
>
> Forcing at least an empty config.queue file fixes this.
>
> Fixes: 23dcff0d396c (kernel/yocto: ensure that defconfigs are processed first)
> Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> ---
>  meta/classes/kernel-yocto.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
> index 7cedb05e93..7ea3cb5e51 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -220,6 +220,8 @@ do_kernel_metadata() {
>                 if [ $? -ne 0 ]; then
>                         bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
>                 fi
> +       else
> +               touch ${S}/${meta_dir}/config.queue
>         fi
>
>         # if KMETA_EXTERNAL_BSPS has been set, or it has been detected from
> --
> 2.20.1
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Andrey Zhizhikin]

On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> >
> > In the case of no patches or no configure fragments, during
> > do_kernel_metadata() scc is not called, and thus
> > kernel-sources/${meta_dir}/config.queue is not created.
> > Later do_kernel_configme fails because the file is missing.
>
> This is a really strange case, since in tree and defconfigs go through
> the queue.
>
> How are you ending up in this situation in the first place?

Can this be the same issue that was solved when defconfig is not in-tree?

I guess this could happen only when the list of elements defined as:
elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
would contain nothing at all, which means that even a defconfig is not found...

Max,
Can you reproduce this issue from the latest master? Fix for searching
for OOT defconfig is already merged there (see [1]).

>
> I'd rather not force create this, but detect the misconfiguration and
> output a useful error message.
>
> Bruce
>
> >
> > | ERROR: Execution of 'run.do_kernel_configme.24874' failed with exit code 1:
> > | exit 1 from 'configs="$(scc --configs -o ${meta_dir})"'
> >
> > Forcing at least an empty config.queue file fixes this.
> >
> > Fixes: 23dcff0d396c (kernel/yocto: ensure that defconfigs are processed first)
> > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> > ---
> >  meta/classes/kernel-yocto.bbclass | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
> > index 7cedb05e93..7ea3cb5e51 100644
> > --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -220,6 +220,8 @@ do_kernel_metadata() {
> >                 if [ $? -ne 0 ]; then
> >                         bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
> >                 fi
> > +       else
> > +               touch ${S}/${meta_dir}/config.queue
> >         fi
> >
> >         # if KMETA_EXTERNAL_BSPS has been set, or it has been detected from
> > --
> > 2.20.1
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
> 

[1]: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe

-- 
Regards,
Andrey.

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Max Krummenacher]

Hi Bruce, Hi Andrey

Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> > > In the case of no patches or no configure fragments, during
> > > do_kernel_metadata() scc is not called, and thus
> > > kernel-sources/${meta_dir}/config.queue is not created.
> > > Later do_kernel_configme fails because the file is missing.
> > 
> > This is a really strange case, since in tree and defconfigs go through
> > the queue.
> > How are you ending up in this situation in the first place?

I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
As far as I understand it no configure fragments kick in from anywhere.
Whith that the above case is what happens, i.e. none of the variables put together to
form 'elements' have any content.

Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs assignment

        sccs="$sccs_from_src_uri"
        bbwarn "sccs " $sccs
        bbwarn "sccs_from_src_uri " $sccs_from_src_uri
        bbwarn "sccs_defconfig " $sccs_defconfig

I get:

   WARNING: sccs 
   WARNING: sccs_from_src_uri 
   WARNING: sccs_defconfig  .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig

sccs_defconfig has been removed from the variables which form elements in commit
23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
processed first). Was that removal not intended?
In which of the variables would you expect an out of tree defconfig to end up?

I admit I lack the big picture of what kgit, scc and do_kernel_metadata and
friends really do, I wrote the patch under the impression that without
configuration fragments or patches one should not run scc here.

> 
> Can this be the same issue that was solved when defconfig is not in-tree?
> 
> I guess this could happen only when the list of elements defined as:
> elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
> would contain nothing at all, which means that even a defconfig is not found...
> 
> Max,
> Can you reproduce this issue from the latest master? Fix for searching
> for OOT defconfig is already merged there (see [1]).

Yes, I can, actually without your patch the build errors out earlier.
You could reproduce it too if you removed
    SRC_URI += "file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild that kernel e.g.
    MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme

> 
> > I'd rather not force create this, but detect the misconfiguration and
> > output a useful error message.
> > 
> > Bruce

Max

> [1]: 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe
> 

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Bruce Ashfield]

On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
>
> Hi Bruce, Hi Andrey
>
> Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> > On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> > > > In the case of no patches or no configure fragments, during
> > > > do_kernel_metadata() scc is not called, and thus
> > > > kernel-sources/${meta_dir}/config.queue is not created.
> > > > Later do_kernel_configme fails because the file is missing.
> > >
> > > This is a really strange case, since in tree and defconfigs go through
> > > the queue.
> > > How are you ending up in this situation in the first place?
>
> I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
> As far as I understand it no configure fragments kick in from anywhere.
> Whith that the above case is what happens, i.e. none of the variables put together to
> form 'elements' have any content.
>
> Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs assignment
>
>         sccs="$sccs_from_src_uri"
>         bbwarn "sccs " $sccs
>         bbwarn "sccs_from_src_uri " $sccs_from_src_uri
>         bbwarn "sccs_defconfig " $sccs_defconfig
>
> I get:
>
>    WARNING: sccs
>    WARNING: sccs_from_src_uri
>    WARNING: sccs_defconfig  .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig
>
> sccs_defconfig has been removed from the variables which form elements in commit
> 23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
> processed first). Was that removal not intended?
> In which of the variables would you expect an out of tree defconfig to end up?

It goes into the config.queue just like the rest of .scc files.

The changes I made recently were only to ensure that it was at the
bottom of the queue, so fragments can logically follow and adjust
settings. So no, the defconfig is not removed from the processing, it
has just been order adjusted.

>
> I admit I lack the big picture of what kgit, scc and do_kernel_metadata and
> friends really do, I wrote the patch under the impression that without
> configuration fragments or patches one should not run scc here.
>
> >
> > Can this be the same issue that was solved when defconfig is not in-tree?
> >
> > I guess this could happen only when the list of elements defined as:
> > elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
> > would contain nothing at all, which means that even a defconfig is not found...
> >
> > Max,
> > Can you reproduce this issue from the latest master? Fix for searching
> > for OOT defconfig is already merged there (see [1]).
>
> Yes, I can, actually without your patch the build errors out earlier.
> You could reproduce it too if you removed

I can build here with a defconfig only kernel, so something else is wrong.

If you can send me (off list) the details of your build (your
bblayers, local.conf settings), I can fire up a build and see what has
gone wrong.

Bruce

>     SRC_URI += "file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
> from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild that kernel e.g.
>     MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme
>
> >
> > > I'd rather not force create this, but detect the misconfiguration and
> > > output a useful error message.
> > >
> > > Bruce
>
> Max
>
> > [1]:
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe
> >
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Bruce Ashfield]

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

On Fri, Jul 10, 2020 at 11:21 AM Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
>
> On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> >
> > Hi Bruce, Hi Andrey
> >
> > Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> > > On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> > > > > In the case of no patches or no configure fragments, during
> > > > > do_kernel_metadata() scc is not called, and thus
> > > > > kernel-sources/${meta_dir}/config.queue is not created.
> > > > > Later do_kernel_configme fails because the file is missing.
> > > >
> > > > This is a really strange case, since in tree and defconfigs go through
> > > > the queue.
> > > > How are you ending up in this situation in the first place?
> >
> > I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
> > As far as I understand it no configure fragments kick in from anywhere.
> > Whith that the above case is what happens, i.e. none of the variables put together to
> > form 'elements' have any content.
> >
> > Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs assignment
> >
> >         sccs="$sccs_from_src_uri"
> >         bbwarn "sccs " $sccs
> >         bbwarn "sccs_from_src_uri " $sccs_from_src_uri
> >         bbwarn "sccs_defconfig " $sccs_defconfig
> >
> > I get:
> >
> >    WARNING: sccs
> >    WARNING: sccs_from_src_uri
> >    WARNING: sccs_defconfig  .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig
> >
> > sccs_defconfig has been removed from the variables which form elements in commit
> > 23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
> > processed first). Was that removal not intended?
> > In which of the variables would you expect an out of tree defconfig to end up?
>
> It goes into the config.queue just like the rest of .scc files.
>
> The changes I made recently were only to ensure that it was at the
> bottom of the queue, so fragments can logically follow and adjust
> settings. So no, the defconfig is not removed from the processing, it
> has just been order adjusted.
>
> >
> > I admit I lack the big picture of what kgit, scc and do_kernel_metadata and
> > friends really do, I wrote the patch under the impression that without
> > configuration fragments or patches one should not run scc here.
> >
> > >
> > > Can this be the same issue that was solved when defconfig is not in-tree?
> > >
> > > I guess this could happen only when the list of elements defined as:
> > > elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
> > > would contain nothing at all, which means that even a defconfig is not found...
> > >
> > > Max,
> > > Can you reproduce this issue from the latest master? Fix for searching
> > > for OOT defconfig is already merged there (see [1]).
> >
> > Yes, I can, actually without your patch the build errors out earlier.
> > You could reproduce it too if you removed
>
> I can build here with a defconfig only kernel, so something else is wrong.
>
> If you can send me (off list) the details of your build (your
> bblayers, local.conf settings), I can fire up a build and see what has
> gone wrong.

Actually, I think I see the hole that this managed to sail through.
Can you try the attached patch ?

It isn't the final one, since I'm also going to add a message and
error if no configuration elements are found, but I wanted to see if
this addresses the immediate issue.

I'm actually in the midst of re-working quite a bit of this flow for
the fall release, so I'm trying to keep changes to a minimum at the
moment, since they could end up being tossed in the bin shortly.

Bruce

>
> Bruce
>
> >     SRC_URI += "file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
> > from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild that kernel e.g.
> >     MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme
> >
> > >
> > > > I'd rather not force create this, but detect the misconfiguration and
> > > > output a useful error message.
> > > >
> > > > Bruce
> >
> > Max
> >
> > > [1]:
> > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe
> > >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: 0001-kernel-yocto-account-for-extracted-defconfig-in-elem.patch --]
[-- Type: application/octet-stream, Size: 1382 bytes --]

From ad4f60bc119ae974870d7d6a2a5100630d1f2acb Mon Sep 17 00:00:00 2001
From: Bruce Ashfield <bruce.ashfield@gmail.com>
Date: Fri, 10 Jul 2020 11:24:06 -0400
Subject: [PATCH] kernel-yocto: account for extracted defconfig in elements
 check

The test for whether or not scc should to invoked to generate a
config.queue was missing the newly created sccs_defconfig variable.
We need to test for that variable as well, or we may miss generating
the config.queue in some cases.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
 meta/classes/kernel-yocto.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 330933a397..3bcd74a295 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -251,7 +251,7 @@ do_kernel_metadata() {
 	meta_dir=$(kgit --meta)
 
 	# run1: pull all the configuration fragments, no matter where they come from
-	elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
+	elements="`echo -n ${bsp_definition} $sccs_defconfig ${sccs} ${patches} ${KERNEL_FEATURES}`"
 	if [ -n "${elements}" ]; then
 		echo "${bsp_definition}" > ${S}/${meta_dir}/bsp_definition
 		scc --force -o ${S}/${meta_dir}:cfg,merge,meta ${includes} $sccs_defconfig $bsp_definition $sccs $patches ${KERNEL_FEATURES}
-- 
2.19.1

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Max Krummenacher]

Hi Bruce

Am Freitag, den 10.07.2020, 11:28 -0400 schrieb Bruce Ashfield:
> On Fri, Jul 10, 2020 at 11:21 AM Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
> > On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> > > Hi Bruce, Hi Andrey
> > > 
> > > Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> > > > On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > > > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> > > > > > In the case of no patches or no configure fragments, during
> > > > > > do_kernel_metadata() scc is not called, and thus
> > > > > > kernel-sources/${meta_dir}/config.queue is not created.
> > > > > > Later do_kernel_configme fails because the file is missing.
> > > > > 
> > > > > This is a really strange case, since in tree and defconfigs go through
> > > > > the queue.
> > > > > How are you ending up in this situation in the first place?
> > > 
> > > I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
> > > As far as I understand it no configure fragments kick in from anywhere.
> > > Whith that the above case is what happens, i.e. none of the variables put together to
> > > form 'elements' have any content.
> > > 
> > > Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs assignment
> > > 
> > >         sccs="$sccs_from_src_uri"
> > >         bbwarn "sccs " $sccs
> > >         bbwarn "sccs_from_src_uri " $sccs_from_src_uri
> > >         bbwarn "sccs_defconfig " $sccs_defconfig
> > > 
> > > I get:
> > > 
> > >    WARNING: sccs
> > >    WARNING: sccs_from_src_uri
> > >    WARNING: sccs_defconfig  .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig
> > > 
> > > sccs_defconfig has been removed from the variables which form elements in commit
> > > 23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
> > > processed first). Was that removal not intended?
> > > In which of the variables would you expect an out of tree defconfig to end up?
> > 
> > It goes into the config.queue just like the rest of .scc files.
> > 
> > The changes I made recently were only to ensure that it was at the
> > bottom of the queue, so fragments can logically follow and adjust
> > settings. So no, the defconfig is not removed from the processing, it
> > has just been order adjusted.
> > 
> > > I admit I lack the big picture of what kgit, scc and do_kernel_metadata and
> > > friends really do, I wrote the patch under the impression that without
> > > configuration fragments or patches one should not run scc here.
> > > 
> > > > Can this be the same issue that was solved when defconfig is not in-tree?
> > > > 
> > > > I guess this could happen only when the list of elements defined as:
> > > > elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
> > > > would contain nothing at all, which means that even a defconfig is not found...
> > > > 
> > > > Max,
> > > > Can you reproduce this issue from the latest master? Fix for searching
> > > > for OOT defconfig is already merged there (see [1]).
> > > 
> > > Yes, I can, actually without your patch the build errors out earlier.
> > > You could reproduce it too if you removed
> > 
> > I can build here with a defconfig only kernel, so something else is wrong.
> > 
> > If you can send me (off list) the details of your build (your
> > bblayers, local.conf settings), I can fire up a build and see what has
> > gone wrong.
> 
> Actually, I think I see the hole that this managed to sail through.
> Can you try the attached patch ?
> 
> It isn't the final one, since I'm also going to add a message and
> error if no configuration elements are found, but I wanted to see if
> this addresses the immediate issue.

I don't have to test, this was actually my first approach to make the
build succeed. I thought it to be to invasive for all the other use
cases which I do not fully understand.

If you're working on anything that includes the effects of the attached
patch just drop my submission. Thanks for the work.

I put a workaround for this issue in our kernel recipe, so for me there
is no rush to have it fixed in openembedded-core.

Max

If anyone would need the quick and dirty workaround:

+do_kernel_metadata_append () {
+       touch ${S}/.kernel-meta/config.queue
+}

> 
> I'm actually in the midst of re-working quite a bit of this flow for
> the fall release, so I'm trying to keep changes to a minimum at the
> moment, since they could end up being tossed in the bin shortly.
> 
> Bruce
> 
> > Bruce
> > 
> > >     SRC_URI += "file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
> > > from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild that kernel e.g.
> > >     MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme
> > > 
> > > > > I'd rather not force create this, but detect the misconfiguration and
> > > > > output a useful error message.
> > > > > 
> > > > > Bruce
> > > 
> > > Max
> > > 
> > > > [1]:
> > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe
> > > > 
> > 
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> 
> 

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Bruce Ashfield]

On Fri, Jul 10, 2020 at 11:52 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
>
> Hi Bruce
>
> Am Freitag, den 10.07.2020, 11:28 -0400 schrieb Bruce Ashfield:
> > On Fri, Jul 10, 2020 at 11:21 AM Bruce Ashfield
> > <bruce.ashfield@gmail.com> wrote:
> > > On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> > > > Hi Bruce, Hi Andrey
> > > >
> > > > Am Freitag, den 10.07.2020, 15:21 +0200 schrieb Andrey Zhizhikin:
> > > > > On Fri, Jul 10, 2020 at 2:47 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > > > > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher <max.oss.09@gmail.com> wrote:
> > > > > > > In the case of no patches or no configure fragments, during
> > > > > > > do_kernel_metadata() scc is not called, and thus
> > > > > > > kernel-sources/${meta_dir}/config.queue is not created.
> > > > > > > Later do_kernel_configme fails because the file is missing.
> > > > > >
> > > > > > This is a really strange case, since in tree and defconfigs go through
> > > > > > the queue.
> > > > > > How are you ending up in this situation in the first place?
> > > >
> > > > I have a kernel recipe with SRC_URI = "git://kernel-git file://defconfig"
> > > > As far as I understand it no configure fragments kick in from anywhere.
> > > > Whith that the above case is what happens, i.e. none of the variables put together to
> > > > form 'elements' have any content.
> > > >
> > > > Notably, $sccs is empty. I.e. if I add some bbwarns after the sccs assignment
> > > >
> > > >         sccs="$sccs_from_src_uri"
> > > >         bbwarn "sccs " $sccs
> > > >         bbwarn "sccs_from_src_uri " $sccs_from_src_uri
> > > >         bbwarn "sccs_defconfig " $sccs_defconfig
> > > >
> > > > I get:
> > > >
> > > >    WARNING: sccs
> > > >    WARNING: sccs_from_src_uri
> > > >    WARNING: sccs_defconfig  .../recipes-kernel/linux/linux-toradex-4.14-2.3.x/mx8/defconfig
> > > >
> > > > sccs_defconfig has been removed from the variables which form elements in commit
> > > > 23dcff0d396c (oe: e6845327b693) (kernel/yocto: ensure that defconfigs are
> > > > processed first). Was that removal not intended?
> > > > In which of the variables would you expect an out of tree defconfig to end up?
> > >
> > > It goes into the config.queue just like the rest of .scc files.
> > >
> > > The changes I made recently were only to ensure that it was at the
> > > bottom of the queue, so fragments can logically follow and adjust
> > > settings. So no, the defconfig is not removed from the processing, it
> > > has just been order adjusted.
> > >
> > > > I admit I lack the big picture of what kgit, scc and do_kernel_metadata and
> > > > friends really do, I wrote the patch under the impression that without
> > > > configuration fragments or patches one should not run scc here.
> > > >
> > > > > Can this be the same issue that was solved when defconfig is not in-tree?
> > > > >
> > > > > I guess this could happen only when the list of elements defined as:
> > > > > elements="`echo -n ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES}`"
> > > > > would contain nothing at all, which means that even a defconfig is not found...
> > > > >
> > > > > Max,
> > > > > Can you reproduce this issue from the latest master? Fix for searching
> > > > > for OOT defconfig is already merged there (see [1]).
> > > >
> > > > Yes, I can, actually without your patch the build errors out earlier.
> > > > You could reproduce it too if you removed
> > >
> > > I can build here with a defconfig only kernel, so something else is wrong.
> > >
> > > If you can send me (off list) the details of your build (your
> > > bblayers, local.conf settings), I can fire up a build and see what has
> > > gone wrong.
> >
> > Actually, I think I see the hole that this managed to sail through.
> > Can you try the attached patch ?
> >
> > It isn't the final one, since I'm also going to add a message and
> > error if no configuration elements are found, but I wanted to see if
> > this addresses the immediate issue.
>
> I don't have to test, this was actually my first approach to make the
> build succeed. I thought it to be to invasive for all the other use
> cases which I do not fully understand.
>

Aha. And right you were. It always used to be accounted for in that
test, and when I jiggled it, I missed that side effect. *sigh*

There's lots I don't like with the routines, they were written quite a
while ago and have some nasty conventions that I wouldn't use now.
Hence why I'm working on some medium size changes to it .. but there
are so many use cases I risk breaking, the effort is slow :)

> If you're working on anything that includes the effects of the attached
> patch just drop my submission. Thanks for the work.

The report was useful, so thanks for that. I'll clean up my effort and
have it in my next pull request.

Cheers,

Bruce

>
> I put a workaround for this issue in our kernel recipe, so for me there
> is no rush to have it fixed in openembedded-core.
>
> Max
>
> If anyone would need the quick and dirty workaround:
>
> +do_kernel_metadata_append () {
> +       touch ${S}/.kernel-meta/config.queue
> +}
>
> >
> > I'm actually in the midst of re-working quite a bit of this flow for
> > the fall release, so I'm trying to keep changes to a minimum at the
> > moment, since they could end up being tossed in the bin shortly.
> >
> > Bruce
> >
> > > Bruce
> > >
> > > >     SRC_URI += "file://0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch"
> > > > from meta-freescale/recipes-kernel/linux/linux-imx_5.4.3.bb and rebuild that kernel e.g.
> > > >     MACHINE=imx8qmmek bitbake virtual/kernel -fc kernel_configme
> > > >
> > > > > > I'd rather not force create this, but detect the misconfiguration and
> > > > > > output a useful error message.
> > > > > >
> > > > > > Bruce
> > > >
> > > > Max
> > > >
> > > > > [1]:
> > > > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7dbc62a672909adce316bb4a8772be0ee9b480fe
> > > > >
> > >
> > > --
> > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > thee at its end
> > > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core][Patch 2/2] kernel-yocto.bbclass: force creation of config.queue

[Pierre-Jean Texier]

Max, all,

Le 10/07/2020 à 17:52, Max Krummenacher a écrit :
> I don't have to test, this was actually my first approach to make the
> build succeed. I thought it to be to invasive for all the other use
> cases which I do not fully understand.
> 
> If you're working on anything that includes the effects of the attached
> patch just drop my submission. Thanks for the work.
> 
> I put a workaround for this issue in our kernel recipe, so for me there
> is no rush to have it fixed in openembedded-core.
> 
> Max
> 
> If anyone would need the quick and dirty workaround:
> 
> +do_kernel_metadata_append () {
> +       touch ${S}/.kernel-meta/config.queue
> +}

Thanks for this.
I have the same problem on my side (poky master + meta-freescale ->
imx7s-warp) and this one fixes my build issue [1].

[1] - http://51.75.135.20:8080/job/imx7s-warp/104/console
-- 
Pierre-Jean Texier
Embedded Linux Engineer
https://koncepto.io