On Fri, Jul 10, 2020 at 11:12 AM Max Krummenacher <[email protected]> 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 <[email protected]>
> > wrote:
> > > On Fri, Jul 10, 2020 at 5:06 AM Max Krummenacher <[email protected]>
> > > 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140522):
https://lists.openembedded.org/g/openembedded-core/message/140522
Mute This Topic: https://lists.openembedded.org/mt/75414806/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
