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
> <[email protected]> wrote:
> > 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.
>
> 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
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140526):
https://lists.openembedded.org/g/openembedded-core/message/140526
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]]
-=-=-=-=-=-=-=-=-=-=-=-
