From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Jeff Melville <dev@jeffmelville.com>, <yocto@yoctoproject.org>
Subject: Re: do_kernel_configme error when patches create directories
Date: Tue, 10 Mar 2015 09:57:32 -0400 [thread overview]
Message-ID: <54FEF84C.6060306@windriver.com> (raw)
In-Reply-To: <CAH7sbrwoZsNe39fv2UsL3K3jW__pAefeezUt0Z7a1vMXrUWTBA@mail.gmail.com>
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
>
prev parent reply other threads:[~2015-03-10 13:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-10 13:49 do_kernel_configme error when patches create directories Jeff Melville
2015-03-10 13:57 ` Bruce Ashfield [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54FEF84C.6060306@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=dev@jeffmelville.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.