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

From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: "André Draszik" <git@andred.net>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases
Date: Thu, 1 Sep 2016 23:18:50 -0400	[thread overview]
Message-ID: <27e6e15a-a78d-dafc-ecab-4a5c58fba529@windriver.com> (raw)
In-Reply-To: <1472746455.27417.57.camel@andred.net>

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