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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
