[linux-yocto] 3.10, standard/base at 3.10.17, but reverts back to 3.10.10...
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
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.
>>> 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