All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: Merging problems
Date: Fri, 19 Dec 2014 12:41:48 +0000	[thread overview]
Message-ID: <1418992908.13316.14.camel@linuxfoundation.org> (raw)
In-Reply-To: <1418984914.13316.6.camel@linuxfoundation.org>

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:

| [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.

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.

Cheers,

Richard




  reply	other threads:[~2014-12-19 12:42 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 [this message]
2014-12-19 13:07   ` Bruce Ashfield
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=1418992908.13316.14.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.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.