[linux-yocto] KMETA branch/directory redux (yocto #5090)

[Peter A. Bigot]

On 08/07/2014 11:16 AM, Bruce Ashfield wrote:
> On Thu, Aug 7, 2014 at 10:27 AM, Peter A. Bigot <pab at 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 at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/linux-yocto
>