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

Bruce Ashfield bruce.ashfield at windriver.com
Thu Nov 7 10:45:13 PST 2013

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.



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

More information about the linux-yocto mailing list