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

[Bruce Ashfield]

On 2016-09-01 11:18 PM, Bruce Ashfield wrote:
> 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 spoke too soon. The error that I was able to trigger was valid,
and in fact, when I tried the same test on krogoth it also failed
there as well.

So there is something I still don't have right in the two layers to
trigger the same scenario you are seeing.

If you could do that mock up, it would help immensely.

Also, if you are open to changing the layer structure a bit, I could
always suggest a new way to organize things.

Cheers,

Bruce

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