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

[Bruce Ashfield]

On 13-11-07 02:06 PM, Darren Hart wrote:
> On Thu, 2013-11-07 at 13:45 -0500, Bruce Ashfield wrote:
>> On 13-11-07 01:13 PM, Darren Hart wrote:
>
>>> 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.
>
> But it didn't. I specified KBRANCH=/standard/base and it build
> standard/minnow, no complaints.

Check KBRANCH_DEFAULT. What's the value ? If they are the same, but
you set it .. the result is 'nil. And that's what you have. It
was the best way to detect that the user has really specified a
hard branch requirement. Otherwise, the meta-data in the kernel
is useless to get the tree to the right place.

That was supposed to be documented, I'll double check to see if that
isn't the case.

>
>>
>>
>>> 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.
>
> Right, that is what I remembered form our discussion. KBRANCH was only
> added to cooperate with SRCREVs. Unfortunately, as you said above, it
> has broader, more vague impacts on the build.
>
> I get that this is an annoyance for you ;-) but if I'm burning two days
> to resolve issues like this (and I wrote the book on it - haha), we can
> be sure that others will throw their hands up in the air give up long
> before this point.

Agreed. And I'm happy to make more changes to make this more
obvious, I don't like opaque errors. Including figuring out a better
way to detect when the recipe author means "use my branch or die!" :)

Bruce

>
>