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

[Bruce Ashfield]

On 13-11-07 11:28 AM, Darren Hart wrote:
> On Thu, 2013-11-07 at 08:58 -0500, Bruce Ashfield wrote:
>> On 13-11-07 02:22 AM, Darren Hart wrote:
>>> BUT! AHA. Some git branch --contains on the commits listed in the output
>>> above reveal that "standard/minnow" HEAD is v3.10.10. Now, it is
>>> supposed to be using standard/base, but I think I've seen this before,
>>> if the tools try to create a branch that already exists, they just use
>>> the existing one.
>>>
>>> Delete standard/minnow from the publish tree... and vwhalla... no more
>>> resetting to an older tree.
>>>
>>> So.... some kind of 'bbwarn "Hey dummy, this branch already exists"' is
>>> in order. Digging in to see if I can find where and include it in my
>>> instrumentation patches.
>>
>> But typically, that is an expected / good thing :) If you are working
>> from a tree with an existing git branch, that's the content you want
>> to use.
>>
>> Fundamentally you work from branches as a human, and that's what the
>> tools want to do .. let you work from the content you put in place.
>> SRCREVs are fine for a build system .. but as we all know, by
>> themselves they aren't something we can grab onto and remember. Hence
>> why branches (iterative development) is balanced with SRCREV processing.
>>
>> The tools will already indicate if you are re-using a branch, but since
>> things are no longer verbosely put to the build screen, you'd have to
>> hunt that up from a build log.
>
> But it didn't. This change to standard/minnow happened in patchme as
> part of the do_patch task and there is next to nothing written to the
> log.do_patch. There is quite a bit of improvement to be done in terms of
> how logging interacts with bitbake - I have the start of a logging
> mechanisms similar to bitbake (but not dependent on it) which I'd like
> to be able to pass in debug level to from bitbake which would also allow
> it to be used from the command line.
>
> 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.

>
>>
>> SRCREV does matter, and right now it only works in the opposite order that
>> you were hitting ..if you branch is newer than the SRCREV, it is reset.
>> If it isn't as far along, you get what is on the branch.
>>
>> Open a bug and I'll make that other case be handled in 1.6.
>
> OK, but I'm not quite sure what the nature of the bug is yet.
>
> So the scenario is this.
>
> KBRANCH is standard/base
>
> The BSP for minnow-standard.scc does:
>
> 	include ktypes/standard
> 	branch minnow
>
> There is some ambiguity in semantics of the branch command.
>
>  From the kernel-dev manual:
>
> 	Notice the branch fri2 command, which creates a
> 	machine-specific branch into which source changes are applied.
>
> But also:
>
> 	Another method is to use the branch command in the BSP
> 	description:
>
> 		mybsp.scc:
> 			...
> 			branch mynewbranch
>
> So, there appear to be two uses of the same command:



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

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