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

[Peter A. Bigot]

On 08/29/2014 02:17 PM, Bruce Ashfield wrote:
> 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 ?

Branch names.  I don't have a separate repository for each kernel 
release, so I encode that into the branch name.  In the version 
currently in oe-core, the directory name was taken from the branch name 
with no ability to override it.

>
>> 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 don't particularly care what the directory name is; "meta" would be 
fine regardless of the branch name, if there's some way to communicate 
that to the infrastructure.

The point is that issuing a mv like:

        mv $checkpoint_dir .$checkpoint_dir

without ensuring that the value of the variable doesn't contain path 
components is fragile.  I'm not really clear on the goals of the 
construct, especially as the dot-qualified name didn't appear to be 
referenced again when I solved this locally.  If that's true, why not 
just delete it?  If there's some reason it needs to continue to exist in 
the filesystem, why not move it to ".checkpoint_dir" (as a bare name, 
not as the value of a variable)?

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

OK, thanks.

Peter

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