On 08/07/2014 11:16 AM, Bruce Ashfield wrote:
On Thu, Aug 7, 2014 at 10:27 AM, Peter A. Bigot <p...@pabigot.com> wrote:
First, some yak shaving:
If something goes wrong with linux-yocto's do_patch, it prints:
| ERROR. Could not apply patches for beaglebone.
| Patch failures can be resolved in the devshell (bitbake -c devshell
linux-yocto)
In fact, you can't, because meta/classes/devshell.bbclass has:
addtask devshell after do_patch
so there's a chicken/egg thing here because bitbake never gets to devshell.
No idea how to fix that.
Now: What goes wrong with do_patch for me ultimately turns out to be
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5090 biting me again a
year after I filed and forgot it, because I set KMETA=yocto-3.14/meta
because that's the branch name in my local kernel directory. Various kgit-*
tools still want to use KMETA to name the directory as well as the branch,
and they are not happy when KMETA isn't meta.
I'm going to try to do a patch for that, if it's agreed that KMETA really
does only name the branch and something else needs to propagate the
directory name among all the scripts.
I have an entire series that addresses issues like this. The work with 3.16
delayed sending anything out. When I'm back from holidays, I'll be sending
out those changes. So by about the M3 milestone of 1.7, most everything
should be sorted.
It definitely isn't trivial to break the branch == directory rule that has been
around for 7 years, but I think I've sorted through most of the wreckage
now.
I see there are some patches that have already been merged into
yocto-kernel-tools for this. At a glance, there's still a construct
that breaks my use case: I have branch names like yocto-3.14/meta and
the pattern:
if [ ! -d ".$checkpoint_dir" ]; then
mv $checkpoint_dir .$checkpoint_dir
fi
does not work in this situation because there is no directory
.yocto-3.14 into which yocto-3.14/meta can be moved.
I'd hoped to have a chance to try out your solution before it got
merged, but please do announce once the full set of changes is available
so if there are problems we can get them resolved before the feature freeze.
Thanks.
Peter
Before I do that, is that the intended behavior? I was going to add
KMETA_DIR as the companion variable, and probably have all the meta_dir()
shell functions in the *me scripts export that.
It is the intended behaviour. Adding another variable isn't the right
fix either,
I'm deleting linux-yocto specific variables, not adding more. Logic to determine
the right directory name has been added to the scripts, when the directory and
branch don't match.
Are patches to yocto-kernel-tools to be sent to this list?
To the linux-yocto mailing list.
Also, is there a reason all the support scripts are present in the
meta/scripts directory of the KMETA branches, even though when you run
bitbake the versions that come from kern-tools are the ones that are
actually used? Their presence tricked me into thinking that the ones in the
meta branch were what I should be patching....
They are there as a snapshot / reference. They can be used in a pinch
to regenerate tree, based only on a clone of the tree. But the default is
to use the ones from the tools .. since that is where changes get pushed first.
Bruce
Peter
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
