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

[Darren Hart]

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.

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

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

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel