From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: Merging problems
Date: Fri, 19 Dec 2014 08:07:50 -0500 [thread overview]
Message-ID: <54942326.8080806@windriver.com> (raw)
In-Reply-To: <1418992908.13316.14.camel@linuxfoundation.org>
On 2014-12-19, 7:41 AM, Richard Purdie wrote:
> On Fri, 2014-12-19 at 10:28 +0000, Richard Purdie wrote:
>> I want to give people a headsup that we're having problems merging
>> changes at the moment. We've been doing our best but the number of
>> things building up which are causing issues is overwheling our ability
>> to fix and stablise the build. It wasn't helped that I took a long
>> weekend's vacation last weekend. There are changes being made or tested
>> to the autobuilder which also isn't helping.
>>
>> The kernel series has several issues:
>>
>> * a random failure in do_kernel_configme [i]
>
> I think I have a handle on this. If you look at the autobuilder failure
> it says:
do you have a link to the actual failure ?
>
> | [INFO] Configuring target/machine combo: "standard/qemuppc"
> | [INFO] collecting configs in patches/meta-series
>
> and what concerns me is "patches/meta-series". I my local builds it
> says .meta/meta-series. Poking around kern-tools I see:
>
> """
> # determine the meta directory name. The meta directory is at the top level
> # of the repository, and is untracked.
> meta_dir_options=`git ls-files -o --directory`
> for m in $meta_dir_options; do
> if [ -d "$m" ]; then
> meta_dir=`echo $m | sed 's%/%%'`
> fi
> done
>
> if [ -z "$meta_dir" ]; then
> meta_dir=".meta"
> fi
> """
>
> which means that if a "patches" directory exists it will use it since
> the command looks for untracked directories. I also noticed that some
> places define the default as ".meta", some as "meta" and they look a bit
> confused but that is probably a separate issue.
They are consistent .. both are supported, we migrated from 'meta' to
.meta some time ago, but there are old trees that still have to build.
>
> The question is then how does a "patches" directory end up in the kernel
> source. I was able to create one with the commands:
>
> MACHINE=qemuppc bitbake linux-yocto perf -c clean
> MACHINE=qemuppc bitbake linux-yocto -c patch
> MACHINE=qemuppc bitbake perf -c unpack
> MACHINE=qemuppc bitbake linux-yocto -c kernel_configme
>
> which doesn't fail like the autobuilder but does put the metadata into
> the wrong place with the wrong data (into patches). I'm therefore
> guessing this is a big horrible race.
>
> Why does perf -c unpack create a patches directory? base.bbclass has:
>
> do_unpack[cleandirs] = "${S}/patches"
>
> The fix is therefore probably to not run the fetch/unpack/patch tasks in
> kernelsrc.bbclass.
Very likely. I'll have a look. I noticed about 6 months ago that a patches
directory was being created .. even when it was never going to be used.
I took steps to remove it before the linux-yocto builds continued, but
apparently it is sneaking back in through other means :)
Bruce
>
> Cheers,
>
> Richard
>
>
next prev parent reply other threads:[~2014-12-19 13:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-19 10:28 Merging problems Richard Purdie
2014-12-19 12:41 ` Richard Purdie
2014-12-19 13:07 ` Bruce Ashfield [this message]
2014-12-19 13:14 ` Bruce Ashfield
2014-12-19 13:15 ` Richard Purdie
2014-12-19 13:58 ` Bruce Ashfield
2014-12-20 11:15 ` Richard Purdie
2014-12-20 15:13 ` Bruce Ashfield
2014-12-20 22:17 ` Richard Purdie
2014-12-20 22:40 ` Richard Purdie
2014-12-21 2:04 ` Bruce Ashfield
2014-12-21 11:27 ` Richard Purdie
2014-12-21 12:35 ` Richard Purdie
2014-12-21 13:56 ` Richard Purdie
2014-12-22 3:40 ` Bruce Ashfield
2014-12-22 3:38 ` Bruce Ashfield
2014-12-20 19:19 ` Otavio Salvador
2014-12-20 22:14 ` Richard Purdie
2014-12-22 16:50 ` Martin Jansa
2014-12-22 17:00 ` Richard Purdie
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=54942326.8080806@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.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.