Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Kamble, Nitin A 
 
  So the topic branch commit is present much deeper in the branch with
 different commit-id.
  May be merging of the emgd branch resulted it. Is it issue with the
  emgd branch rebased to an undesired point?
 
 It shouldn't be. That commit shouldn't be present in the repository at all (it
 isn't in mine). The emgd branches are off master, same repo and can't bring
 in something like this.

Right. I think it got placed there after merge with the emgd branch done by the
kernel-tools.

 
 So something is getting tied in a knot when the repository is fetched into the
 source dir.

I don't see any issue with the fetch. As noemgd BSPs are working as expected.

 
 For your builds that work, do you have that commit present ?
 

The emenlow-noemgd build sees the right HEAD commit. So the issue is definitely 
something to do
with the merge with the emgd branch.

Nitin


___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield 

On 13-03-05 12:35 PM, Kamble, Nitin A wrote:


So the topic branch commit is present much deeper in the branch with

different commit-id.

May be merging of the emgd branch resulted it. Is it issue with the
emgd branch rebased to an undesired point?


It shouldn't be. That commit shouldn't be present in the repository at all (it
isn't in mine). The emgd branches are off master, same repo and can't bring
in something like this.


Right. I think it got placed there after merge with the emgd branch done by the
kernel-tools.


That doesn't make sense either. The merge of the emgd branch is just
the git merge of a locally staged branch in the linux-yocto repository.
That commit you reference shouldn't be in the emgd branch, or any
branch if a clean linux-yocto-3.8 tree is being used.

Cheers,

Bruce





So something is getting tied in a knot when the repository is fetched into the
source dir.


I don't see any issue with the fetch. As noemgd BSPs are working as expected.



For your builds that work, do you have that commit present ?



The emenlow-noemgd build sees the right HEAD commit. So the issue is definitely 
something to do
with the merge with the emgd branch.

Nitin




___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Kamble, Nitin A 


 -Original Message-
 From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
 Sent: Tuesday, March 05, 2013 9:50 AM
 To: Kamble, Nitin A
 Cc: linux-yo...@yoctoproject.org
 Subject: Re: v3.8 kernel recipes in meta-intel
 
 On 13-03-05 12:35 PM, Kamble, Nitin A wrote:
 
  So the topic branch commit is present much deeper in the branch with
  different commit-id.
  May be merging of the emgd branch resulted it. Is it issue with the
  emgd branch rebased to an undesired point?
 
  It shouldn't be. That commit shouldn't be present in the repository
  at all (it isn't in mine). The emgd branches are off master, same
  repo and can't bring in something like this.
 
  Right. I think it got placed there after merge with the emgd branch
  done by the kernel-tools.
 
 That doesn't make sense either. The merge of the emgd branch is just the git
 merge of a locally staged branch in the linux-yocto repository.
 That commit you reference shouldn't be in the emgd branch, or any branch if
 a clean linux-yocto-3.8 tree is being used.

Right, so the kernl tools are producing unwanted state of the topic branch when
emgd branch is considered. And I guess you would know better why kernl tools 
are doing it.

Nitin


 
 Cheers,
 
 Bruce
 
 
 
  So something is getting tied in a knot when the repository is fetched
  into the source dir.
 
  I don't see any issue with the fetch. As noemgd BSPs are working as
 expected.
 
 
  For your builds that work, do you have that commit present ?
 
 
  The emenlow-noemgd build sees the right HEAD commit. So the issue is
  definitely something to do with the merge with the emgd branch.
 
  Nitin
 
 

___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield 

On 13-03-05 12:56 PM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 9:50 AM
To: Kamble, Nitin A
Cc: linux-yo...@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 12:35 PM, Kamble, Nitin A wrote:


So the topic branch commit is present much deeper in the branch with

different commit-id.

May be merging of the emgd branch resulted it. Is it issue with the
emgd branch rebased to an undesired point?


It shouldn't be. That commit shouldn't be present in the repository
at all (it isn't in mine). The emgd branches are off master, same
repo and can't bring in something like this.


Right. I think it got placed there after merge with the emgd branch
done by the kernel-tools.


That doesn't make sense either. The merge of the emgd branch is just the git
merge of a locally staged branch in the linux-yocto repository.
That commit you reference shouldn't be in the emgd branch, or any branch if
a clean linux-yocto-3.8 tree is being used.


Right, so the kernl tools are producing unwanted state of the topic branch when
emgd branch is considered. And I guess you would know better why kernl tools 
are doing it.


Not exactly, I must not be understanding what you are describing.
There's no way for the kern-tools to create a commit ID. They can only
work with what's present in the tree.

If you see the SRCREV to foo, and validate_branches is telling you
that foo isn't present in the tree at all, that's not related to
the kern tools at all. It's related to the repository that is cloned
into the WORKDIR for building.

If you can make your recipes and updates public, I can try and do a build
here.

Bruce



Nitin




Cheers,

Bruce





So something is getting tied in a knot when the repository is fetched
into the source dir.


I don't see any issue with the fetch. As noemgd BSPs are working as

expected.




For your builds that work, do you have that commit present ?



The emenlow-noemgd build sees the right HEAD commit. So the issue is
definitely something to do with the merge with the emgd branch.

Nitin






___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Kamble, Nitin A 
 Not exactly, I must not be understanding what you are describing.
 There's no way for the kern-tools to create a commit ID. They can only work
 with what's present in the tree.
 
 If you see the SRCREV to foo, and validate_branches is telling you that
 foo isn't present in the tree at all, that's not related to the kern tools 
 at all.
 It's related to the repository that is cloned into the WORKDIR for building.
 
 If you can make your recipes and updates public, I can try and do a build
 here.
 

Bruce,
   I think I found the issue. The problem is the SRC_URI in the .bbappend is 
pointing to the linux-yocto-dev repo.
I guess that explains all the behavior. Thanks for looking into this. Now it 
does not look like kern tools issue.

Nitin


___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Bruce Ashfield 

On 13-03-05 12:00 PM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:41 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 11:39 AM, Kamble, Nitin A wrote:




-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, March 05, 2013 8:37 AM
To: Kamble, Nitin A
Cc: linux-yocto@yoctoproject.org
Subject: Re: v3.8 kernel recipes in meta-intel

On 13-03-05 11:33 AM, Kamble, Nitin A wrote:

Hi Bruce,

 I am seeing some unexpected behavior of the v3.8 kernel bits.
Here is what I am trying to do.



Something is up with your linux-yocto clone:



Hi  Bruce,
 This is not with the local repo. As you can see the SRC_URI it is
pointing to the Upstream repo.


By local, I meant the repository the fetcher creates. That commit ID is valid in
the upstream repository, so there's nothing I can say about why it isn't in the
clone that is presented for building.

Bruce


Bruce,
   I tried doing bitbake cleanall  for the linux-yocto recipe. And it removed 
my local copy,
  and in the next build, it did take lot of time to clone it. But still the 
same build error.

I wonder why the same commit  topic branch is working for emenlow-noemgd BSP
and does not working for emenlow? The only relevant difference I see here is  
SRCURI.


What do you see if you head into the linux source build dir and
run the same commands that I tried below ?

Bruce



Nitin





Nitin




git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
Author: Tom Zanussi tom.zanu...@intel.com
Date:   Fri Oct 5 11:35:26 2012 -0500

   perf annotate: replace 'expand' with equivalent sed expression

   We don't have 'expand' in our userspace so we need to accomplish the
   same thing using 'sed', which we do have.

   Signed-off-by: Tom Zanussi tom.zanu...@intel.com

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 07aaeea..ff162ae 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -826,7 +826,7 @@ fallback:
   snprintf(command, sizeof(command),
%s %s%s --start-address=0x%016 PRIx64
 --stop-address=0x%016 PRIx64
- -d %s %s -C %s|grep -v %s|expand,
+ -d %s %s -C %s|grep -v %s|sed 's/\t//g',
objdump_path ? objdump_path : objdump,
disassembler_style ? -M  : ,
disassembler_style ? disassembler_style : ,

git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
 standard/arm-versatile-926ejs
 standard/base
 standard/beagleboard
 standard/ck
 standard/common-pc-64/base
 standard/common-pc-64/chiefriver
 standard/common-pc-64/crystalforest
 standard/common-pc-64/jasperforest
 standard/common-pc-64/rangeley
 standard/common-pc-64/romley
 standard/common-pc-64/sugarbay
 standard/common-pc/atom-pc
 standard/common-pc/base
 standard/crownbay
 standard/edf
 standard/emenlow
 standard/fri2
 standard/fsl-mpc8315e-rdb
 standard/mti-malta32
 standard/mti-malta64
 standard/preempt-rt/base
 standard/preempt-rt/fri2
 standard/preempt-rt/qemuppc
 standard/preempt-rt/routerstationpro
 standard/qemuppc
 standard/routerstationpro
 standard/sys940x
 standard/tiny/base
 standard/tiny/common-pc
 standard/tiny/fri2

Whereas the tree you have locally doesn't have the commit at all.

Bruce



I am seeing this build error:

ERROR: Function failed: do_validate_branches (see
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-

poky-li

nux/linux-

yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2

4_b170394a475b96ecc9

2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for
further information)

ERROR: Logfile of failure stored in:
/srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-

poky-li

nux/linux-

yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2

4_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-

r4.0/temp/log.do_validate_b

ranches.3414

Log data follows:

| DEBUG: Executing shell function do_validate_branches

| error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5

This is with the master branches of poky  oecore + v3.8 bbappends
in the meta-intel layer.

* poky.git :  master: commit
93ec7b4d1550e07caec86e2998d0f94a01c7e785

* meta-intel.git :  master: commit
4ffe40409f8cd0f354a7488113ef888b42867033

And this is my v3.8 bbappend in the meta-intel

meta-emenlow/recipes-kernel/linux/linux-yocto_3.8.bbappend :

FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:

COMPATIBLE_MACHINE_emenlow = emenlow

KMACHINE_emenlow = emenlow

KBRANCH_emenlow = standard/emenlow

KERNEL_FEATURES_emenlow_append =  features/drm-emgd/drm-

emgd-

1.16

Re: [linux-yocto] v3.8 kernel recipes in meta-intel

2013-03-05 Thread Kamble, Nitin A 


 -Original Message-
 From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
 Sent: Tuesday, March 05, 2013 8:41 AM
 To: Kamble, Nitin A
 Cc: linux-yocto@yoctoproject.org
 Subject: Re: v3.8 kernel recipes in meta-intel
 
 On 13-03-05 11:39 AM, Kamble, Nitin A wrote:
 
 
  -Original Message-
  From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
  Sent: Tuesday, March 05, 2013 8:37 AM
  To: Kamble, Nitin A
  Cc: linux-yocto@yoctoproject.org
  Subject: Re: v3.8 kernel recipes in meta-intel
 
  On 13-03-05 11:33 AM, Kamble, Nitin A wrote:
  Hi Bruce,
 
  I am seeing some unexpected behavior of the v3.8 kernel bits.
  Here is what I am trying to do.
 
 
  Something is up with your linux-yocto clone:
 
 
  Hi  Bruce,
  This is not with the local repo. As you can see the SRC_URI it is
  pointing to the Upstream repo.
 
 By local, I meant the repository the fetcher creates. That commit ID is valid 
 in
 the upstream repository, so there's nothing I can say about why it isn't in 
 the
 clone that is presented for building.
 
 Bruce

Bruce,
  I tried doing bitbake cleanall  for the linux-yocto recipe. And it removed 
my local copy,
 and in the next build, it did take lot of time to clone it. But still the same 
build error.

I wonder why the same commit  topic branch is working for emenlow-noemgd BSP 
and does not working for emenlow? The only relevant difference I see here is  
SRCURI.

Nitin

 
 
  Nitin
 
 
 
 git show b170394a475b96ecc92cbc9e4b002bed0a9f69c5
  commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
  Author: Tom Zanussi tom.zanu...@intel.com
  Date:   Fri Oct 5 11:35:26 2012 -0500
 
perf annotate: replace 'expand' with equivalent sed expression
 
We don't have 'expand' in our userspace so we need to accomplish the
same thing using 'sed', which we do have.
 
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
 
  diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
  index 07aaeea..ff162ae 100644
  --- a/tools/perf/util/annotate.c
  +++ b/tools/perf/util/annotate.c
  @@ -826,7 +826,7 @@ fallback:
snprintf(command, sizeof(command),
 %s %s%s --start-address=0x%016 PRIx64
  --stop-address=0x%016 PRIx64
  - -d %s %s -C %s|grep -v %s|expand,
  + -d %s %s -C %s|grep -v %s|sed 's/\t//g',
 objdump_path ? objdump_path : objdump,
 disassembler_style ? -M  : ,
 disassembler_style ? disassembler_style : ,
 
 git branch --contains b170394a475b96ecc92cbc9e4b002bed0a9f69c5
  standard/arm-versatile-926ejs
  standard/base
  standard/beagleboard
  standard/ck
  standard/common-pc-64/base
  standard/common-pc-64/chiefriver
  standard/common-pc-64/crystalforest
  standard/common-pc-64/jasperforest
  standard/common-pc-64/rangeley
  standard/common-pc-64/romley
  standard/common-pc-64/sugarbay
  standard/common-pc/atom-pc
  standard/common-pc/base
  standard/crownbay
  standard/edf
  standard/emenlow
  standard/fri2
  standard/fsl-mpc8315e-rdb
  standard/mti-malta32
  standard/mti-malta64
  standard/preempt-rt/base
  standard/preempt-rt/fri2
  standard/preempt-rt/qemuppc
  standard/preempt-rt/routerstationpro
  standard/qemuppc
  standard/routerstationpro
  standard/sys940x
  standard/tiny/base
  standard/tiny/common-pc
  standard/tiny/fri2
 
  Whereas the tree you have locally doesn't have the commit at all.
 
  Bruce
 
 
  I am seeing this build error:
 
  ERROR: Function failed: do_validate_branches (see
  /srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-
  poky-li
  nux/linux-
  yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2
  4_b170394a475b96ecc9
 
  2cbc9e4b002bed0a9f69c5-r4.0/temp/log.do_validate_branches.3414 for
  further information)
 
  ERROR: Logfile of failure stored in:
  /srv/home/nitin/build-test-bsps/build-emenlow/tmp/work/emenlow-
  poky-li
  nux/linux-
  yocto/3.8+gitAUTOINC+c2ed0f16fdec628242a682897d5d86df4547cf2
  4_b170394a475b96ecc92cbc9e4b002bed0a9f69c5-
  r4.0/temp/log.do_validate_b
  ranches.3414
 
  Log data follows:
 
  | DEBUG: Executing shell function do_validate_branches
 
  | error: no such commit b170394a475b96ecc92cbc9e4b002bed0a9f69c5
 
  This is with the master branches of poky  oecore + v3.8 bbappends
  in the meta-intel layer.
 
  * poky.git :  master: commit
  93ec7b4d1550e07caec86e2998d0f94a01c7e785
 
  * meta-intel.git :  master: commit
  4ffe40409f8cd0f354a7488113ef888b42867033
 
  And this is my v3.8 bbappend in the meta-intel
 
  meta-emenlow/recipes-kernel/linux/linux-yocto_3.8.bbappend :
 
  FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
 
  COMPATIBLE_MACHINE_emenlow = emenlow
 
  KMACHINE_emenlow = emenlow
 
  KBRANCH_emenlow = standard/emenlow
 
  KERNEL_FEATURES_emenlow_append =