[linux-yocto] 3.10, standard/base at 3.10.17, but reverts back to 3.10.10...

[Bruce Ashfield]

On 13-11-07 01:13 PM, Darren Hart wrote:
> On Thu, 2013-11-07 at 11:54 -0500, Bruce Ashfield wrote:
>> On 13-11-07 11:28 AM, Darren Hart wrote:
>
>>> But, other than a bunch of hashes and control characters, very little is
>>> written to do_patch around the the code that changes branches.
>>
>> I've removed that for the verbose logging in the latest set of updates,
>> or to be precise, a V=1 type logging that drops the spinner and shows
>> you everything that happens in behind. With that, you'll see the
>> existing logs that say branch <foo> (reuse), when reusing a branch.
>
>
> Are these pending updates or something I already have access to?

Pending. They were too late for yocto 1.5. I broke things this week, but
I'll have them cleaned up soon.

You can enable it yourself in patchme by adding a second -v to:

    kgit-meta -v --continue --apply $meta_series

>
>
>>> So, there appear to be two uses of the same command: [branch]
>>>
>>>
>>> 1) Create a branch from the current HEAD on which to apply additional
>>>      features (merges,patches,etc).
>>>
>>> 2) Checkout an existing branch, and then do the patches/merges
>>
>> I wouldn't call those different uses, it is always:
>>
>>     - create branch from current position, re-use if there
>>     - do more work.
>>
>> Trust me on this, we cannot error if the branch already exists. Each and
>> every time you build what is described in the meta data is validated
>> against the tree, so it absolutely expects and deals with being run many
>> times on the same tree.
>
> I think I get that part, and I'm not saying we have to call this an
> error. What I'm trying to address is how to close the gap in intention
> versus execution.
>
> We've actually discussed the impotency of the recipe-space KBRANCH
> before, and it's still a problem we need to address. This may just be a
> documentation issue in the end, but I think we could narrow the semantic
> gap with the tooling as well.
>
> For example:
>
> 1) What does it mean to specify KBRANCH=/standard/base ?
>
> I think the typical BSP author's expectation would be that standard/base
> would be used as the base for the kernel build. Any patches or features
> would merged on top of that.
>
> The reality is that any branch command in the linux-yocto meta-data
> could render it completely ineffectual - or not, depending on whether or
> not the target branch already exists or not. We can certainly improve
> this.

It means that the branch will be built, or an error will the thrown. If
you deviate from KBRANCH_DEFAULT, it means you know what you are doing
and if that branch isn't built .. the build stops.


> 2) What is the outside-of-bitbake equivalent of KBRANCH?
>
> We should be adding some documentation on how to work with the kernel
> tools outside of bitbake. Right now that is shrouded in tribal knowledge
> which understandably widens the semantic gap.

There isn't one. If you are outside bitbake, you trust the meta data
and build where they leave the tree :) The branch specifications are
pretty much only around to keep the fetcher happy.

Cheers,

Bruce

>
> --
> Darren
>
>
>>
>> Bruce
>>
>>>
>>> In general, the problem for me is that branch implies checkout. THe
>>> instrumentation problem comes in that we are executing a generated file,
>>> rather than marching through it, which make instrumenting it cumbersome.
>>> Perhaps there is a good way, to put some print statements and if this
>>> then bail out with a horrible message code in the generated code, but
>>> the tooling is generic enough as make this difficult. I'll comment on
>>> this more in your other response after I drive in...
>>>
>>
>