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

["Max Krummenacher" <max.oss.09@gmail.com>]

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