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

[Bruce Ashfield]

On 14-08-29 03:09 PM, Peter A. Bigot wrote:
> 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

Yep. Some work in progress that I didn't want to lose, rebasing some
old patches into a larger series.

> 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

directory names or branch names ?

> 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'm not looking for completely flexibility, since my statement of
not introducing any new variables to broadcast the directory name
holds. But within that bound, I'm willing to tweak things more.

The construct is simply to hide the top level meta directory from
the content branches, git status, etc. So it take a directory name
of "foo", which should be where the meta data is stored on the
meta branch, and renames it ".foo". What exactly are you using
as a directory to hold the meta-data ?

I'll run some extra tests to make sure I hit those cases, but
I'll send the bulk of the changes regardless, since small incremental
changes aren't issues post feature freeze.

Bruce

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