[yocto] do_kernel_configme error when patches create directories

[Bruce Ashfield]

On 15-03-10 09:49 AM, Jeff Melville wrote:
> I'm using a Yocto flow to build for the Zynq with the meta-xilinx with
> some customizations:
> - I'm using a bbappend to replace the linux-xlnx 3.14 kernel with one
> that has had mainline changes from 3.14.17 merged in.
> - I added a task between patch and configure for applying the Xenomai
> kernel patches and running the Xenomai prepare_kernel script.
>
> All layers are on the dizzy branch. The linux-xlnx recipe inherits
> from linux-yocto but obtains the metadeta from an out of tree source
> using a SRC_URI append with type=kmeta. This ends up getting copied
> into the kernel tree with during the kernel_configme task. This is my
> first time working with a kernel recipe in the linux-yocto style so
> I'm still coming up to speed a bit.
>
> The problem arises because the Xenomai patch process creates
> additional directories in the Linux tree. As part of the
> kernel_configme task, the kgit-meta script will attempt to use the
> last unversioned directory returned by 'git ls-files -o --directory'
> as the metadata directory, which does not work.
>
> Two questions:
> 1) What is the best short term way for me to work around this?

Write a _append to the do_kernel_checkout that removes the extra
directories. But since I have no idea what the directories are
used for .. that may or may not be a good thing.

> 2) Is there a way to patch the meta directory detection in kgit-meta
> to make it more robust against false detections?

Its software, so everything is possible :) But that code was written to
free ourselves from being locked to the meta-data directory needing
to match the meta-data repo/branch name, and to not introduce yet
another arcane variable to the build process.

If I tweak this yet again, other use cases will potentially break, so
it has to be carefully done.

I have some ideas on how to do this though .. can you open an
enhancement request in the yocto bugzilla and assign it to me ?

Cheers,

Bruce


>
> Thanks,
> Jeff
>