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

[Darren Hart]

On Wed, 2013-11-06 at 23:22 -0800, Darren Hart wrote:
> On Wed, 2013-11-06 at 21:07 -0500, Bruce Ashfield wrote:
> > On 11/6/2013, 4:40 PM, Darren Hart wrote:
> > > On Tue, 2013-11-05 at 22:00 -0500, Bruce Ashfield wrote:
> > >> On 13-11-05 6:36 PM, Darren Hart wrote:
> > >>> On Tue, 2013-11-05 at 17:15 -0600, Tom Zanussi wrote:
> > >>>> On Tue, 2013-11-05 at 14:52 -0800, Darren Hart wrote:
> > >>>>> I'm working on rewriting the minnow-io feature to just apply patches.
> > >>>>> It's working.... but something is seriously horked with 3.10 - or my
> > >>>>> 3.10 tree.... or.... I don't know. HALP!
> > >>>>>
> > >>>>> The first problem was it was building PREEMPT_RT from a linux-yocto
> > >>>>> recipe. Turns out the eg20t feature has a branch (even in the
> > >>>>> yoctoproject.org git repo) which includes the preempt-rt sources, so
> > >>>>> those were all getting merged in. I removed the eg20t branch command and
> > >>>>> now preempt-rt isn't getting merged in. First I don't understand why
> > >>>>> eg20t even has a branch (did I do that?). Second, why would it contain
> > >>>>
> > >>>> I'm not sure how the eg20t branch could be getting merged in - the eg20t
> > >>>> feature doesn't contain a 'git merge', and is just there for the .cfg.
> > >>>>
> > >>>> The eg20t branch originally contained about 70 eg20t patches before
> > >>>> they'd gone upstream, and is now useless AFAIK, so should probably be
> > >>>> removed.
> > >>>>
> > >>>>> PREEMPT_RT? Fumbled upgrade?
> > >>>>
> > >>>> Sounds like it, but based on the above it shouldn't really matter as it
> > >>>> shouldn't be used at all..
> > >>>
> > >>> Right, it didn't have a merge command, just a branch:
> > >>>
> > >>> $ cat meta/cfg/kernel-cache/features/eg20t/eg20t.scc
> > >>> # changes should be staged on "eg20t"
> > >>> git branch eg20t master
> > >>>
> > >>> kconf hardware eg20t.cfg
> > >>>
> > >>> Still, including this scc brought in the eg20t branch. Perhaps if the
> > >>> branch name exists the branch command does a merge? Bug?
> > >>
> > >> We picked this up last week during some integration work @ Wind. The
> > >> git branch was only used when staging the branch, and shouldn't have
> > >> been in the .scc .. BSPs that are still including it are only working
> > >> because they aren't adding any patches AFTER the command.
> > >>
> > >> In your case, you are .. hence why things are going insane.
> > >>
> > >> I have a change queued that drops the branch command, and moves eg20t
> > >> to staging, and then "to be killed", as Tom points out.
> > >>
> > >>>
> > >>> I've confirmed this reverting to 3.10.10 happens in the do_patch()
> > >>> task, but I don't know where or why yet.
> > >>
> > >> Have you tried the same build with the branch command removed ?
> > >>
> > >
> > > I removed eg20t from minnow.scc completely and I removed all features
> > > added in the recipe. The do_patch() stage still reverts from 3.10.17 to
> > > 3.10.10. I'll start instrumenting the tools I guess.
> > 
> > It's not the tools, they don't mess with SRCREVs like this. My guess is
> > that you are hitting a corner case in the do_validate_branches. To solve
> > some issues with dynamic branches, they reset all branches that contain
> > the machine's SRCREV to that value, and then start processing changes.
> 
> This happens in patchme do_apply() somewhere. I'm currently
> instrumenting. I'll have a pile of cleanups and instrumentation
> patches ... hopefully tomorrow. My instrumentation tells this story so
> far:
> 
> NOTE: git HEAD prior to patchme: c03195e kconfig: inhibit unitialized
> variable warning
> meta-dir(): meta-branch=meta
> meta-dir(): using meta_dir=.meta
> ktgt=minnow
> meta_series=
> branch=standard/base
> meta_series=.meta/cfg/scratch/minnow-standard-meta
> Git HEAD: c03195e kconfig: inhibit unitialized variable warning
> do_init()
> Git HEAD: c03195e kconfig: inhibit unitialized variable warning
> Git HEAD: c03195e kconfig: inhibit unitialized variable warning
> do_apply()
> [INFO] validating against known patches  (minnow-standard-meta)
>   [##################################################]  (completed in 6
> seconds)                    
> Git HEAD: ebc8428 Merge tag 'v3.10.10' into standard/base
> NOTE: git HEAD after patchme: ebc8428 Merge tag 'v3.10.10' into
> standard/base
> 
> 
> > 
> > So double check two things. What is your machine's SRCREV ? Is it the
> > 3.10 hash ?
> 
> It's the HEAD of my standard/base, which is 3.10.17
> 
> >  And try doing a build with AUTOREV, that disables the branch
> > reset functionality and will point the smoking gun.
> 
> OK, let's give that a try.... but it happens patchme, so it should fix
> it....
> 
> Same deal.
> 
> 
> 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.
> 
> 2 days later.... now I can test the new minnow-io and 3.10 BSP.... sigh.
> 

OK, it occurs in wrap_meta_series() at:

source $_series.wrap

Which makes further instrumentation rather complicated.

I had a discussion with Arjan about code that needed to be easily
debugged... and I think this might qualify. His argument was that in
such a case, it made sense to code it in explicit steps and not make it
so generic that you had to unravel it before you could debug it. I think
we may have a highly generic implementation in a code base that really
might serve us better if it were written in explicit steps - difficult
to articulate what I'm trying to say here.... and I'm just a little
irritated with it ;-)

More tomorrow.

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