Re: [yocto] missing kernel in rootfs image

2012-02-24 Thread Joshua Immanuel 
On Tue, 2012-02-21 at 15:10 +0530, Joshua Immanuel wrote:
> While trying to generate my custom rootfs image, I added the
> linux_yocto_3.0.bbappend file to my custom layer and specified the
> KMACHINE, SRCREV and COMPATIBLE_MACHINE variables. I find the
> generated
> kernel image (bzImage-ekino.bin) in the tmp/deploy/images directory.
> 
> But, the rootfs image does not contain the kernel (in /boot
> directory).
> My machine configuration file has the following kernel specific lines
> 
> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> PREFERRED_VERSION_linux-yocto ?= "3.0%" 

Can someone explain the work flow behind the process of installing the
kernel into the rootfs image? My custom image has the IMAGE_INSTALL for
"task-core-boot". In turn, the task-core-boot recipe DEPENDS on
"virtual/kernel" this ensures that the kernel is staged. 

But, I am not sure which recipe/class is responsible for installing the
kernel in the final rootfs image. Should I explicitly add the
"linux-yocto" to RDEPENDS? 

Please guide me. 

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in


signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] how do I find the filename of the kernel

2012-02-24 Thread Joshua Immanuel 
Hello all,
I am trying to write a config file in grub-native recipe for which I
need the kernel filename (in my case bzImage-3.0.4-yocto-standard+).

I find in kernel.bbclass that the kernel file name is constructed from
"${KERNEL_IMAGETYPE}-${KERNEL_VERSION}". And the KERNEL_VERSION is
filled from the 'get_kernelversion' method in linux-kernel-base.bbclass,
which needs the location of kernel's build directory (${B}). Obviously,
this build directory location will not be available in other recipes.

So, how do I get the filename of the kernel in other recipes?

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in


signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/2] meta-intel: improve interactions with common layer

2012-02-24 Thread Paul Eggleton 
At the moment it is possible to enable one of the sub-layers of
meta-intel (e.g. meta-n450) without also enabling the meta-intel common
layer, which can lead to some nasty parsing errors. Here are two patches
to handle this situation in a nicer way.

(Note that BitBake currently does not actually terminate when
LAYERDEPENDS are not satisfied - I've got a patch queued to fix this.)

The following changes since commit 1ca68394faf33416f2aabee27323da7510ad6609:

  netbase: put sys940x specific interfaces file in MACHINE directory 
(2012-02-10 17:27:27 -0800)

are available in the git repository at:
  git://git.yoctoproject.org/meta-intel-contrib paule/layerdepends
  
http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=paule/layerdepends

Paul Eggleton (2):
  meta-intel: replace "include" with "require"
  meta-intel: add LAYERDEPENDS for layers needing the meta-intel common
layer

 meta-cedartrail/conf/layer.conf |2 ++
 meta-cedartrail/conf/machine/cedartrail.conf|2 +-
 meta-crownbay/conf/layer.conf   |2 ++
 meta-crownbay/conf/machine/crownbay-noemgd.conf |4 ++--
 meta-crownbay/conf/machine/crownbay.conf|4 ++--
 meta-emenlow/conf/layer.conf|2 ++
 meta-emenlow/conf/machine/emenlow.conf  |4 ++--
 meta-fishriver/conf/layer.conf  |2 ++
 meta-fishriver/conf/machine/fishriver.conf  |2 +-
 meta-fri2/conf/layer.conf   |2 ++
 meta-fri2/conf/machine/fri2-noemgd.conf |4 ++--
 meta-fri2/conf/machine/fri2.conf|4 ++--
 meta-jasperforest/conf/layer.conf   |2 ++
 meta-n450/conf/layer.conf   |2 ++
 meta-n450/conf/machine/n450.conf|4 ++--
 meta-romley/conf/layer.conf |2 ++
 meta-romley/conf/machine/romley.conf|2 +-
 meta-sugarbay/conf/layer.conf   |2 ++
 meta-sys940x/conf/layer.conf|2 ++
 meta-sys940x/conf/machine/sys940x-noemgd.conf   |4 ++--
 meta-sys940x/conf/machine/sys940x.conf  |4 ++--
 21 files changed, 39 insertions(+), 19 deletions(-)

-- 
1.7.5.4

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

[yocto] [PATCH 2/2] meta-intel: add LAYERDEPENDS for layers needing the meta-intel common layer

2012-02-24 Thread Paul Eggleton 
These layers all contain machine configuration that depends on having
the meta-intel common layer enabled as well, so use LAYERDEPENDS in the
layer configuration for each one to make this explicit.

Signed-off-by: Paul Eggleton 
---
 meta-cedartrail/conf/layer.conf   |2 ++
 meta-crownbay/conf/layer.conf |2 ++
 meta-emenlow/conf/layer.conf  |2 ++
 meta-fishriver/conf/layer.conf|2 ++
 meta-fri2/conf/layer.conf |2 ++
 meta-jasperforest/conf/layer.conf |2 ++
 meta-n450/conf/layer.conf |2 ++
 meta-romley/conf/layer.conf   |2 ++
 meta-sugarbay/conf/layer.conf |2 ++
 meta-sys940x/conf/layer.conf  |2 ++
 10 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/meta-cedartrail/conf/layer.conf b/meta-cedartrail/conf/layer.conf
index cb4142d..c19c4c1 100644
--- a/meta-cedartrail/conf/layer.conf
+++ b/meta-cedartrail/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "cedartrail"
 BBFILE_PATTERN_cedartrail := "^${LAYERDIR}/"
 BBFILE_PRIORITY_cedartrail = "6"
+
+LAYERDEPENDS_cedartrail = "intel"
diff --git a/meta-crownbay/conf/layer.conf b/meta-crownbay/conf/layer.conf
index 52581e1..cb17298 100644
--- a/meta-crownbay/conf/layer.conf
+++ b/meta-crownbay/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "crownbay"
 BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
 BBFILE_PRIORITY_crownbay = "6"
+
+LAYERDEPENDS_crownbay = "intel"
diff --git a/meta-emenlow/conf/layer.conf b/meta-emenlow/conf/layer.conf
index 563b9c8..dda80c0 100644
--- a/meta-emenlow/conf/layer.conf
+++ b/meta-emenlow/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "emenlow"
 BBFILE_PATTERN_emenlow := "^${LAYERDIR}/"
 BBFILE_PRIORITY_emenlow = "6"
+
+LAYERDEPENDS_emenlow = "intel"
diff --git a/meta-fishriver/conf/layer.conf b/meta-fishriver/conf/layer.conf
index 9162b5e..61e292b 100644
--- a/meta-fishriver/conf/layer.conf
+++ b/meta-fishriver/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "fishriver"
 BBFILE_PATTERN_fishriver := "^${LAYERDIR}/"
 BBFILE_PRIORITY_fishriver = "6"
+
+LAYERDEPENDS_fishriver = "intel"
diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
index b30e776..4d140f9 100644
--- a/meta-fri2/conf/layer.conf
+++ b/meta-fri2/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "fri2"
 BBFILE_PATTERN_fri2 := "^${LAYERDIR}/"
 BBFILE_PRIORITY_fri2 = "6"
+
+LAYERDEPENDS_fri2 = "intel"
diff --git a/meta-jasperforest/conf/layer.conf 
b/meta-jasperforest/conf/layer.conf
index bfd7fc3..09f1647 100644
--- a/meta-jasperforest/conf/layer.conf
+++ b/meta-jasperforest/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "jasperforest"
 BBFILE_PATTERN_jasperforest := "^${LAYERDIR}/"
 BBFILE_PRIORITY_jasperforest = "6"
+
+LAYERDEPENDS_jasperforest = "intel"
diff --git a/meta-n450/conf/layer.conf b/meta-n450/conf/layer.conf
index f9cc7fe..2c905c2 100644
--- a/meta-n450/conf/layer.conf
+++ b/meta-n450/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "n450"
 BBFILE_PATTERN_n450 = "^${LAYERDIR}/"
 BBFILE_PRIORITY_n450 = "6"
+
+LAYERDEPENDS_n450 = "intel"
diff --git a/meta-romley/conf/layer.conf b/meta-romley/conf/layer.conf
index c5eeaab..8ce1a4d 100644
--- a/meta-romley/conf/layer.conf
+++ b/meta-romley/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "romley"
 BBFILE_PATTERN_romley := "^${LAYERDIR}/"
 BBFILE_PRIORITY_romley = "6"
+
+LAYERDEPENDS_romley = "intel"
diff --git a/meta-sugarbay/conf/layer.conf b/meta-sugarbay/conf/layer.conf
index 05ef1cd..eb8ec45 100644
--- a/meta-sugarbay/conf/layer.conf
+++ b/meta-sugarbay/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "sugarbay"
 BBFILE_PATTERN_sugarbay := "^${LAYERDIR}/"
 BBFILE_PRIORITY_sugarbay = "6"
+
+LAYERDEPENDS_sugarbay = "intel"
diff --git a/meta-sys940x/conf/layer.conf b/meta-sys940x/conf/layer.conf
index 459c710..5d588ad 100644
--- a/meta-sys940x/conf/layer.conf
+++ b/meta-sys940x/conf/layer.conf
@@ -8,3 +8,5 @@ BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
 BBFILE_COLLECTIONS += "sys940x"
 BBFILE_PATTERN_sys940x := "^${LAYERDIR}/"
 BBFILE_PRIORITY_sys940x = "6"
+
+LAYERDEPENDS_sys940x = "intel"
-- 
1.7.5.4

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

[yocto] [PATCH 1/2] meta-intel: replace "include" with "require"

2012-02-24 Thread Paul Eggleton 
We want a failure to occur if the files specified in these statements
can't be found (e.g. when there is a misconfiguration), so use require
instead of include.

Signed-off-by: Paul Eggleton 
---
 meta-cedartrail/conf/machine/cedartrail.conf|2 +-
 meta-crownbay/conf/machine/crownbay-noemgd.conf |4 ++--
 meta-crownbay/conf/machine/crownbay.conf|4 ++--
 meta-emenlow/conf/machine/emenlow.conf  |4 ++--
 meta-fishriver/conf/machine/fishriver.conf  |2 +-
 meta-fri2/conf/machine/fri2-noemgd.conf |4 ++--
 meta-fri2/conf/machine/fri2.conf|4 ++--
 meta-n450/conf/machine/n450.conf|4 ++--
 meta-romley/conf/machine/romley.conf|2 +-
 meta-sys940x/conf/machine/sys940x-noemgd.conf   |4 ++--
 meta-sys940x/conf/machine/sys940x.conf  |4 ++--
 11 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta-cedartrail/conf/machine/cedartrail.conf 
b/meta-cedartrail/conf/machine/cedartrail.conf
index ec84347..3bd5cf8 100644
--- a/meta-cedartrail/conf/machine/cedartrail.conf
+++ b/meta-cedartrail/conf/machine/cedartrail.conf
@@ -4,7 +4,7 @@
 #@DESCRIPTION: Machine configuration for Cedartrail systems
 # i.e. Cedarview processor + Tiger Point Chipset
 
-include conf/machine/include/tune-atom.inc
+require conf/machine/include/tune-atom.inc
 require conf/machine/include/ia32-base.inc
 
 XSERVER ?= "${XSERVER_IA32_BASE} \
diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf 
b/meta-crownbay/conf/machine/crownbay-noemgd.conf
index 80fc2a6..2c80bd8 100644
--- a/meta-crownbay/conf/machine/crownbay-noemgd.conf
+++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf
@@ -4,8 +4,8 @@
 #@DESCRIPTION: Machine configuration for Crown Bay systems, without 
Intel-proprietary graphics bits
 # i.e. E660 + EG20T
 
-include conf/machine/include/tune-atom.inc
-include conf/machine/include/ia32-base.inc
+require conf/machine/include/tune-atom.inc
+require conf/machine/include/ia32-base.inc
 
 XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
diff --git a/meta-crownbay/conf/machine/crownbay.conf 
b/meta-crownbay/conf/machine/crownbay.conf
index 15bfd52..2c1ef3d 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -4,8 +4,8 @@
 #@DESCRIPTION: Machine configuration for Crown Bay systems
 # i.e. E660 + EG20T
 
-include conf/machine/include/tune-atom.inc
-include conf/machine/include/ia32-base.inc
+require conf/machine/include/tune-atom.inc
+require conf/machine/include/ia32-base.inc
 
 XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
diff --git a/meta-emenlow/conf/machine/emenlow.conf 
b/meta-emenlow/conf/machine/emenlow.conf
index cf43d4f..78020ba 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -4,8 +4,8 @@
 #@DESCRIPTION: Machine configuration for eMenlow based systems, like the
 # Webs-2120 box.
 
-include conf/machine/include/tune-atom.inc
-include conf/machine/include/ia32-base.inc
+require conf/machine/include/tune-atom.inc
+require conf/machine/include/ia32-base.inc
 
 PREFERRED_PROVIDER_libdrm = "libdrm-poulsbo"
 PREFERRED_PROVIDER_drm = "libdrm-poulsbo"
diff --git a/meta-fishriver/conf/machine/fishriver.conf 
b/meta-fishriver/conf/machine/fishriver.conf
index b43282e..aa066db 100644
--- a/meta-fishriver/conf/machine/fishriver.conf
+++ b/meta-fishriver/conf/machine/fishriver.conf
@@ -4,7 +4,7 @@
 #@DESCRIPTION: Machine configuration for Fish River Island systems
 # i.e. Z530/E660 + EG20T
 
-include conf/machine/include/tune-atom.inc
+require conf/machine/include/tune-atom.inc
 require conf/machine/include/ia32-base.inc
 
 XSERVER ?= "${XSERVER_IA32_BASE} \
diff --git a/meta-fri2/conf/machine/fri2-noemgd.conf 
b/meta-fri2/conf/machine/fri2-noemgd.conf
index 911a449..a0eb8a0 100644
--- a/meta-fri2/conf/machine/fri2-noemgd.conf
+++ b/meta-fri2/conf/machine/fri2-noemgd.conf
@@ -4,8 +4,8 @@
 #@DESCRIPTION: Machine configuration for Fish River Island II systems
 # i.e. E660 + EG20T
 
-include conf/machine/include/tune-atom.inc
-include conf/machine/include/ia32-base.inc
+require conf/machine/include/tune-atom.inc
+require conf/machine/include/ia32-base.inc
 
 MACHINE_FEATURES += "wifi 3g pcbios efi"
 MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5"
diff --git a/meta-fri2/conf/machine/fri2.conf b/meta-fri2/conf/machine/fri2.conf
index c69aa40..3947736 100644
--- a/meta-fri2/conf/machine/fri2.conf
+++ b/meta-fri2/conf/machine/fri2.conf
@@ -4,8 +4,8 @@
 #@DESCRIPTION: Machine configuration for Fish River Island II systems
 # i.e. E660 + EG20T
 
-include conf/machine/include/tune-atom.inc
-include conf/machine/include/ia32-base.inc
+require conf/machine/include/tune-atom.inc
+require conf/machine/include/ia32-base.inc
 
 MACHINE_FEATURES += "wifi 3g pcbios efi"
 MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5"
diff --git a/meta-n450/conf/machine/n45

Re: [yocto] how do I find the filename of the kernel

2012-02-24 Thread Joshua Immanuel 
Hello all,

On Fri, 2012-02-24 at 14:56 +0530, Joshua Immanuel wrote:
> I find in kernel.bbclass that the kernel file name is
> constructed from "${KERNEL_IMAGETYPE}-${KERNEL_VERSION}". And the
> KERNEL_VERSION is filled from the 'get_kernelversion' method in
> linux-kernel-base.bbclass, which needs the location of kernel's build
> directory (${B}). Obviously, this build directory location will not be
> available in other recipes. 

Aww. Missed this. In kernel_do_install method of kernel.bbclass I found
that KERNEL_VERSION is echoed into a file
(${D}/kernel/kernel-abiversion). And this file is added to
sysroot_stage_dir. I guess, that I have to read that file in order to
get construct the kernel filename. Am I right?

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in


signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] adt-installer: cannot install package autoconf-nativesdk

2012-02-24 Thread Andrea Galbusera 
Hi,
I'm having the following error while trying the adt-installer for the
first time. I'm using current edison git branch and following the ADT
user's guide. The adt_installer tarball was generated inside my Yocto
build tree. The adt_installer.conf I use is basically the default one
(just changed YOCTOADT_TARGET_SYSROOT_LOC_arm to my needs). Here is
the log relevant snip:

Start installing selected native ADT for archs: arm x86...
###
Please note from this point on installation requires sudo password ...
###

Dangling opkg cache folder ///var/lib/opkg detected. Continue
installation will remove the folder!
[ADT_INST] Do you want to continue installation? Please enter Y/N:
Updating opkg...
Downloading http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/Packages.
Updated list of available packages in ///var/lib/opkg/lists/yp-i686-nativesdk.
opkg update process ended...
Installing pseudo nativesdk ...

Installing pseudo-nativesdk (1.1.1-r2) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/pseudo-nativesdk_1.1.1-r2_i686-nativesdk.ipk.
Installing eglibc-nativesdk (2.13-r15+svnr14157) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/eglibc-nativesdk_2.13-r15+svnr14157_i686-nativesdk.ipk.
Configuring eglibc-nativesdk.
Configuring pseudo-nativesdk.
Installing opkg nativesdk ...

Installing opkg-nativesdk (1:0.1.8+svnr625-r2) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/opkg-nativesdk_0.1.8+svnr625-r2_i686-nativesdk.ipk.
Configuring opkg-nativesdk.
Installing pkgconfig nativesdk ...

Installing pkgconfig-nativesdk (0.25-r0) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/pkgconfig-nativesdk_0.25-r0_i686-nativesdk.ipk.
Configuring pkgconfig-nativesdk.
Installing libtool nativesdk ...

Installing libtool-nativesdk (2.4-r2) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/libtool-nativesdk_2.4-r2_i686-nativesdk.ipk.
Configuring libtool-nativesdk.
Installing autoconf nativesdk ...

Unknown package 'autoconf-nativesdk'.
Collected errors:
 * opkg_install_cmd: Cannot install package autoconf-nativesdk.

#
# Meet error(s) when installing Yocto ADT! Please check log file for details.
#


The installer was built against the latest version of its recipe as
per commit c6ec5a0d9e31a1694aba25e2ff76f1c933e556d5,
adt-installer-0.1.8+svnr596-r6. I guess a change was made with commit
de68393270d5455b4861d38cef3f081b9667d25f which requires installing
autoconf/automake-nativesdk but relevant ipks are missing from
http://adtrepo.yoctoproject.org/1.1/adt-ipk/, which is still default
in latest adt_installer.conf.

Am I guessing right? First time digging into the adt_installer so I
might be completely out of track! Is this a known limit if building
adt_installer with latest edison branch? Should I file a bug for this?
If so, what's the best solution right now? Maybe using the edison
original adt_installer from the yocto downloads...

Thanks in advance
Regards,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] missing kernel in rootfs image

2012-02-24 Thread Bruce Ashfield 

On 12-02-24 03:29 AM, Joshua Immanuel wrote:

On Tue, 2012-02-21 at 15:10 +0530, Joshua Immanuel wrote:

 While trying to generate my custom rootfs image, I added the
linux_yocto_3.0.bbappend file to my custom layer and specified the
KMACHINE, SRCREV and COMPATIBLE_MACHINE variables. I find the
generated
kernel image (bzImage-ekino.bin) in the tmp/deploy/images directory.

But, the rootfs image does not contain the kernel (in /boot
directory).
My machine configuration file has the following kernel specific lines

 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto ?= "3.0%"


Can someone explain the work flow behind the process of installing the
kernel into the rootfs image? My custom image has the IMAGE_INSTALL for
"task-core-boot". In turn, the task-core-boot recipe DEPENDS on
"virtual/kernel" this ensures that the kernel is staged.

But, I am not sure which recipe/class is responsible for installing the
kernel in the final rootfs image. Should I explicitly add the
"linux-yocto" to RDEPENDS?


Are you past this issue yet ? I'm not sure, since you did have some
other email that looked to be past this .. or maybe they weren't.

Darren went through the process of documenting these variables and
was looking into some related issues. Darren: is this something that
you ran into ?

Cheers,

Bruce



Please guide me.

Regards
Joshua



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


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

Re: [yocto] Yocto Project Quick Start Feedback

2012-02-24 Thread Rifenbark, Scott M 
Darren and all,

Good feedback on the YP QS.  Here are my thoughts...

It seems that both Inaky and Mohamed are experienced embedded developers.  From 
reading the thread "New User feedback from Inaky and Mohamed" it was obvious 
that you two know what you are doing in the embedded world.  You guys represent 
one type of user YP needs to address.  Your feedback points out that you are 
probably finding it tedious to wade through a bunch of introductory stuff 
before getting to a point where you actually use something. That is good 
feedback.

Other users that the YP QS must address consist of people investigating 
embedded development for the first time, non-Linux people, people unfamiliar 
with open source development in general, etc.  Because the target audience of 
the YP QS is broad, it needs to fundamentally flow to satisfy the lowest common 
denominator - thus, its current flow and level of information.  To date, yours 
is the first feedback that has indicated the QS needed to "cut to the chase" so 
to speak.  This type of feedback is valid and would be expected from advanced 
users such as you.  

I can make some changes to the QS structure to better address the advanced 
user.  I can disrupt the advanced user's reading right up front and point them 
off to a section in the QS that essentially does what Darren is proposing as a 
flow here.  The section can be a single page targeted for the advanced user 
that is not interested in introductory material but just wants the nuts and 
bolts.

I will also play around with the color scheme for the Notes and Tips in the QS. 
 This type of feedback is highly subjective.  What one person feels is 
distracting might not be distracting for another.  That said, however, it is 
valid feedback and I will see about toning down the note boxes.  I don't like 
footnotes for the type of information I am using for Notes and Tips.  Footnotes 
tend to get lost and are best suited for anecdotal information that a reader 
could do without but for which might be curious. 

Thanks for great feedback on the YP documentation.  It is input like this that 
will continue to make YP and its documentation better. 

Best, 
Scott



-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com] 
Sent: Thursday, February 23, 2012 6:41 PM
To: Yocto Project
Cc: Rifenbark, Scott M; Perez-Gonzalez, Inaky; Abbas, Mohamed
Subject: Yocto Project Quick Start Feedback

Scott,

I received from first-time-user feedback regarding the quick start page.
I thought it was good stuff that you should here and consider
incorporating into the document.

1) There is too much introduction, education, and Note blocks before
   we get the user going. The quick start is really about getting them
   going as quickly as possible:

   o Package install
   o Download
   o Build

   There are four "pages" of detail before we get to installing
   packages. 6 before we run any Yocto specific commands.

2) It can be confusing about what to download, since we mention the
   Yocto Project Download page (which has a ton of stuff on it) before
   we tell them to download edison with wget.

3) The Note blocks are huge and distracting for the content. Notes
   should probably be light gray on white in a smaller font, rather
   than white on dark gray. They distract from the primary content.

4) There probably is no need to separate "The Linux Distribution" from
   "The Packages". These convey similar information, and consume a lot
   of space doing so.

5) All the information is good, but it would be good to rearrange things
   such that a new user can actually get a "Quick Start". The Notes
   could be real footnotes, and things like the Development Environment
   section should be "Further Reading" rather than "Required Reading"
   for the "Quick Start".

6) As "Further Reading" we should include something like a "Bitbake
   Flashcard" that outlines the common commands:
   -c listtasks
   -c compile -f
   -c cleansstate (so people don't just start off with
   "rm -rf tmp sstate-cache")
   -e
   -g depexp -u

I think a good goal would be that a user can run the qemu command
without having to scroll passed the initial screen on the Quick Start guide!

Consider:

Yocto Project Quick Start
=
Ubuntu Dependencies
---
$ sudo dpkg-reconfigure dash
  Select "No"
$ sudo apt-get install sed wget cvs subversion git-core coreutils \
  unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
  python-pysqlite2 diffstat help2man make gcc build-essential \
  g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
  mercurial autoconf automake groff libtool xterm

Fedora Dependencies
---
 $ sudo yum groupinstall "development tools"
 $ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
 unzip python-psyco perl texinfo texi2html diffstat openjade \
 docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
 doc

Re: [yocto] missing kernel in rootfs image

2012-02-24 Thread Darren Hart 


On 02/24/2012 06:45 AM, Bruce Ashfield wrote:
> On 12-02-24 03:29 AM, Joshua Immanuel wrote:
>> On Tue, 2012-02-21 at 15:10 +0530, Joshua Immanuel wrote:
>>>  While trying to generate my custom rootfs image, I added the
>>> linux_yocto_3.0.bbappend file to my custom layer and specified the
>>> KMACHINE, SRCREV and COMPATIBLE_MACHINE variables. I find the
>>> generated
>>> kernel image (bzImage-ekino.bin) in the tmp/deploy/images directory.
>>>
>>> But, the rootfs image does not contain the kernel (in /boot
>>> directory).
>>> My machine configuration file has the following kernel specific lines
>>>
>>>  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>>>  PREFERRED_VERSION_linux-yocto ?= "3.0%"
>>
>> Can someone explain the work flow behind the process of installing the
>> kernel into the rootfs image? My custom image has the IMAGE_INSTALL for
>> "task-core-boot". In turn, the task-core-boot recipe DEPENDS on
>> "virtual/kernel" this ensures that the kernel is staged.
>>
>> But, I am not sure which recipe/class is responsible for installing the
>> kernel in the final rootfs image. Should I explicitly add the
>> "linux-yocto" to RDEPENDS?
> 
> Are you past this issue yet ? I'm not sure, since you did have some
> other email that looked to be past this .. or maybe they weren't.
> 
> Darren went through the process of documenting these variables and
> was looking into some related issues. Darren: is this something that
> you ran into ?


What sort of image are you creating (live, ext3, cpio)? You want to look
at the do_install() for the linux-yocto recipe. The bits you're
interested in are in meta/classes/kernel.bbclass in the
kernel_do_install() function. I suggest instrumenting that and sorting
out where things are going wrong from there.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] missing kernel in rootfs image

2012-02-24 Thread Joshua Immanuel 
On Fri, 2012-02-24 at 09:45 -0500, Bruce Ashfield wrote:
> > Can someone explain the work flow behind the process of installing
> > the kernel into the rootfs image? My custom image has the
> > IMAGE_INSTALL for "task-core-boot". In turn, the task-core-boot
> > recipe DEPENDS on "virtual/kernel" this ensures that the kernel is
> > staged.
> >
> > But, I am not sure which recipe/class is responsible for installing
> > the kernel in the final rootfs image. Should I explicitly add the
> > "linux-yocto" to RDEPENDS?
> 
> Are you past this issue yet ? I'm not sure, since you did have some
> other email that looked to be past this .. or maybe they weren't. 

I'm not sure how to put this. When I added the "linux-yocto" to
RDEPENDS_task* I was able to get the kernel image in the rootfs image
(ext3 image). But on the next compilation (i mean when I did $ bitbake
custom-image again) it complained dependency failed for task-*. So, I
ended up removing the line from RDEPENDS_task* but the final rootfs
image retained the kernel file in it.

I am in a confusion of which one to blame. I guess, the only way to
rebuild the tasks for custom-image is to remove tmp and sstate-cache
directories and build again.

$ bitbake -c clean task-*
$ bitbake -c clean custom-image

The above commands doesn't completely re-build the tasks listed for
custom-image. So, I guess the problem still exists.

Regards
Joshua
-- 
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in


signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project Quick Start Feedback

2012-02-24 Thread William Mills 

Scott, Darren & All,

First I want to say I am very excited to see this deep and targeted 
discussion on the docs.  I think it says very good things about where 
yocto is as a project.


Just a thought:  Something that often works well in both teaching and 
movies is to start the story right at some action and then go and 
explain how you got there. (No I am not talking about Memento.)


That said, when I first tried Yocto/Poky I was not new to embedded or OE 
and just wanted the meat of how poky expected me to do this.  I really 
did not have an issue skimming and finding what I was looking for and 
the background information aclimated me to some "Yocto-speak" and customs.


I read through the notes & tips.  I thought they were all important and 
I have seen a number of people get caught on each of them.


The only exception I found was the tip of rm_work.  I think this should 
be removed.  We have seen rm_work interfere with sstate and I have not 
seen it decrease the peak disk space needed, just the end state. 
Perhaps this is better than when I last tested.  At any rate I don't 
think we run any automated builds with rm_work enabled so should we 
really be encouraging the new user to try this out?


I don't think we should delete a lot from the QS and any reorder is 
probably fine tunning.


Bill

On 02/24/2012 10:43 AM, Rifenbark, Scott M wrote:

Darren and all,

Good feedback on the YP QS.  Here are my thoughts...

It seems that both Inaky and Mohamed are experienced embedded developers.  From reading 
the thread "New User feedback from Inaky and Mohamed" it was obvious that you 
two know what you are doing in the embedded world.  You guys represent one type of user 
YP needs to address.  Your feedback points out that you are probably finding it tedious 
to wade through a bunch of introductory stuff before getting to a point where you 
actually use something. That is good feedback.

Other users that the YP QS must address consist of people investigating embedded 
development for the first time, non-Linux people, people unfamiliar with open source 
development in general, etc.  Because the target audience of the YP QS is broad, it needs 
to fundamentally flow to satisfy the lowest common denominator - thus, its current flow 
and level of information.  To date, yours is the first feedback that has indicated the QS 
needed to "cut to the chase" so to speak.  This type of feedback is valid and 
would be expected from advanced users such as you.

I can make some changes to the QS structure to better address the advanced 
user.  I can disrupt the advanced user's reading right up front and point them 
off to a section in the QS that essentially does what Darren is proposing as a 
flow here.  The section can be a single page targeted for the advanced user 
that is not interested in introductory material but just wants the nuts and 
bolts.

I will also play around with the color scheme for the Notes and Tips in the QS. 
 This type of feedback is highly subjective.  What one person feels is 
distracting might not be distracting for another.  That said, however, it is 
valid feedback and I will see about toning down the note boxes.  I don't like 
footnotes for the type of information I am using for Notes and Tips.  Footnotes 
tend to get lost and are best suited for anecdotal information that a reader 
could do without but for which might be curious.

Thanks for great feedback on the YP documentation.  It is input like this that 
will continue to make YP and its documentation better.

Best,
Scott



-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com]
Sent: Thursday, February 23, 2012 6:41 PM
To: Yocto Project
Cc: Rifenbark, Scott M; Perez-Gonzalez, Inaky; Abbas, Mohamed
Subject: Yocto Project Quick Start Feedback

Scott,

I received from first-time-user feedback regarding the quick start page.
I thought it was good stuff that you should here and consider
incorporating into the document.

1) There is too much introduction, education, and Note blocks before
we get the user going. The quick start is really about getting them
going as quickly as possible:

o Package install
o Download
o Build

There are four "pages" of detail before we get to installing
packages. 6 before we run any Yocto specific commands.

2) It can be confusing about what to download, since we mention the
Yocto Project Download page (which has a ton of stuff on it) before
we tell them to download edison with wget.

3) The Note blocks are huge and distracting for the content. Notes
should probably be light gray on white in a smaller font, rather
than white on dark gray. They distract from the primary content.

4) There probably is no need to separate "The Linux Distribution" from
"The Packages". These convey similar information, and consume a lot
of space doing so.

5) All the information is good, but it would be good to rearrange things
such that a new user can act

[yocto] USB touchscreen integration

2012-02-24 Thread Autif Khan 
I have a touchscreen made by AUO. It came with a driver which I have
written a recipe for and it seems to be compiling and when the
touchscreen is detected, the driver seems to be loading and
controlling the touchscreen. (Its not under the control of hid_core
driver).

It shows up in /proc/bus/input/devices

I: Bus=0003 Vendor=03eb Product=201c Version=1503
N: Name="pixcir_hid_mt_v2.0"
P: Phys=
S: 
Sysfs=/devices/pci:00/:00:17.0/:01:00.0/:02:02.0/usb3/3-1/3-1:1.0/input/input4
U: Uniq=
H: Handlers=mouse0
B: PROP=0
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=65 3

It shows up as /dev/input/mouse0

While this is great, I am not sure how to wire this up with X so that
the mouse is actually functional on the screen.

A quick search at yocto wiki resulted in nothing, and google's search
in site:yoctoproject.org also resulted in somewhat irrelevant results.

I am using poky master on machine crownbay. X is running very well on
an LVDS monitor. Keyboard and mouse run fine when externally
connected. This query is limited to wiring a USB touchscreen with
yocto.

I am not sure what the next steps are. Please help!

Thanks

Autif
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project Quick Start Feedback

2012-02-24 Thread Rifenbark, Scott M 
Bill, 

Thanks for this level of feedback.  I'm especially encouraged to hear that the 
QS seemed to work for your level of expertise, which also seems to be in the 
expert area.  I think fact that you were not bothered by skimming for essential 
information reinforces the subjectivity of it all.  

The "movie" angle is interesting.  Picture this... the opening 1/2 page sets up 
the packages for Ubuntu, downloads files, builds core-image-sata, and runs 
qemu.  All this done without even telling anyone what YP is.  Follow that by 
"what just happened... we just built and ran an image using the Yocto Project.  
Then the QS launches into the "Welcome" stuff and flows on as normal.  That 
would be a unique beginning for a technical manual.

The rm_work comment is concerning.  It sounds like that should just be removed.

Scott

-Original Message-
From: William Mills [mailto:wmi...@ti.com] 
Sent: Friday, February 24, 2012 11:47 AM
To: Rifenbark, Scott M
Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard; 
Perez-Gonzalez, Inaky
Subject: Re: [yocto] Yocto Project Quick Start Feedback

Scott, Darren & All,

First I want to say I am very excited to see this deep and targeted 
discussion on the docs.  I think it says very good things about where 
yocto is as a project.

Just a thought:  Something that often works well in both teaching and 
movies is to start the story right at some action and then go and 
explain how you got there. (No I am not talking about Memento.)

That said, when I first tried Yocto/Poky I was not new to embedded or OE 
and just wanted the meat of how poky expected me to do this.  I really 
did not have an issue skimming and finding what I was looking for and 
the background information aclimated me to some "Yocto-speak" and customs.

I read through the notes & tips.  I thought they were all important and 
I have seen a number of people get caught on each of them.

The only exception I found was the tip of rm_work.  I think this should 
be removed.  We have seen rm_work interfere with sstate and I have not 
seen it decrease the peak disk space needed, just the end state. 
Perhaps this is better than when I last tested.  At any rate I don't 
think we run any automated builds with rm_work enabled so should we 
really be encouraging the new user to try this out?

I don't think we should delete a lot from the QS and any reorder is 
probably fine tunning.

Bill

On 02/24/2012 10:43 AM, Rifenbark, Scott M wrote:
> Darren and all,
>
> Good feedback on the YP QS.  Here are my thoughts...
>
> It seems that both Inaky and Mohamed are experienced embedded developers.  
> From reading the thread "New User feedback from Inaky and Mohamed" it was 
> obvious that you two know what you are doing in the embedded world.  You guys 
> represent one type of user YP needs to address.  Your feedback points out 
> that you are probably finding it tedious to wade through a bunch of 
> introductory stuff before getting to a point where you actually use 
> something. That is good feedback.
>
> Other users that the YP QS must address consist of people investigating 
> embedded development for the first time, non-Linux people, people unfamiliar 
> with open source development in general, etc.  Because the target audience of 
> the YP QS is broad, it needs to fundamentally flow to satisfy the lowest 
> common denominator - thus, its current flow and level of information.  To 
> date, yours is the first feedback that has indicated the QS needed to "cut to 
> the chase" so to speak.  This type of feedback is valid and would be expected 
> from advanced users such as you.
>
> I can make some changes to the QS structure to better address the advanced 
> user.  I can disrupt the advanced user's reading right up front and point 
> them off to a section in the QS that essentially does what Darren is 
> proposing as a flow here.  The section can be a single page targeted for the 
> advanced user that is not interested in introductory material but just wants 
> the nuts and bolts.
>
> I will also play around with the color scheme for the Notes and Tips in the 
> QS.  This type of feedback is highly subjective.  What one person feels is 
> distracting might not be distracting for another.  That said, however, it is 
> valid feedback and I will see about toning down the note boxes.  I don't like 
> footnotes for the type of information I am using for Notes and Tips.  
> Footnotes tend to get lost and are best suited for anecdotal information that 
> a reader could do without but for which might be curious.
>
> Thanks for great feedback on the YP documentation.  It is input like this 
> that will continue to make YP and its documentation better.
>
> Best,
> Scott
>
>
>
> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com]
> Sent: Thursday, February 23, 2012 6:41 PM
> To: Yocto Project
> Cc: Rifenbark, Scott M; Perez-Gonzalez, Inaky; Abbas, Mohamed
> Subject: Yocto Project Quick Start Feedb

Re: [yocto] Yocto Project Quick Start Feedback

2012-02-24 Thread William Mills 

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:

The "movie" angle is interesting.  Picture this... the opening 1/2 page sets up the packages 
for Ubuntu, downloads files, builds core-image-sata, and runs qemu.  All this done without even telling 
anyone what YP is.  Follow that by "what just happened... we just built and ran an image using the 
Yocto Project.  Then the QS launches into the "Welcome" stuff and flows on as normal.  That 
would be a unique beginning for a technical manual.


I sense some derision in your word "unique"?  Thats fine, your doing 
most of the work and you have to be happy with it.


However I don't think it is unique.  Yes it would be a bad approuch to 
use in a reference manual but I have found a number of  intros/tutorials 
start this way and I always enjoy the approuch.  Perhaps the QS at only 
9 printed pages is too short to be structured this way.  The QS guide 
itself is just this "taste of the bigger picture" for the full doc set.


As I said, just some thoughts.

Bill
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-ti] bitbake ti-syslink fails for MACHINE=c6a816x

2012-02-24 Thread Brian Hutchinson 
On Fri, Feb 24, 2012 at 4:07 PM, Monk, Roger  wrote:
> I don't think it is worth spending too much time debugging this, since this 
> version of syslink is pretty old now and there will likely be further issues 
> in this environment even if we can can get th build to complete, since there 
> are other related dependencies.  Best would be to look at adding the version 
> >= those versions that are used in DVSDK 5.03.  This is planned, but we don't 
> have a schedule at the moment.  If you have some time to help integrate these 
> newer components it would be a big help.
>
> Thanks,
> ~roger

I just need to get syslink and sysbios going on C6A816x & L138.  We
bitbake our rootfs image from Angstrom at the moment.  Can you advise
the best way to get syslink/sysbios going on these two targets?  Our
build machines a Linux based.  Should I be using the versions that are
packaged inside the ezsdk .bin file?

I can also help integrating but I might need some direction to get started.

Regards,

Brian
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-ti] bitbake ti-syslink fails for MACHINE=c6a816x

2012-02-24 Thread Brian Hutchinson 
Oops, hit return too quick on auto completion of email address ...
this was meant for meta-ti list!

Please forgive me and sorry for the noise.

Brian
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project Quick Start Feedback

2012-02-24 Thread Rifenbark, Scott M 
Bill, 

You are reading me wrong.  I actually like the idea.  It fits a Quick Start.  I 
was going to divert the expert reader anyway.  The reason I tried to paint the 
picture here was to see what others thought of the idea. 

Scott

-Original Message-
From: William Mills [mailto:wmi...@ti.com] 
Sent: Friday, February 24, 2012 1:07 PM
To: Rifenbark, Scott M
Cc: Darren Hart; Yocto Project; Abbas, Mohamed; Purdie, Richard; 
Perez-Gonzalez, Inaky
Subject: Re: [yocto] Yocto Project Quick Start Feedback

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:
> The "movie" angle is interesting.  Picture this... the opening 1/2 page sets 
> up the packages for Ubuntu, downloads files, builds core-image-sata, and runs 
> qemu.  All this done without even telling anyone what YP is.  Follow that by 
> "what just happened... we just built and ran an image using the Yocto 
> Project.  Then the QS launches into the "Welcome" stuff and flows on as 
> normal.  That would be a unique beginning for a technical manual.

I sense some derision in your word "unique"?  Thats fine, your doing 
most of the work and you have to be happy with it.

However I don't think it is unique.  Yes it would be a bad approuch to 
use in a reference manual but I have found a number of  intros/tutorials 
start this way and I always enjoy the approuch.  Perhaps the QS at only 
9 printed pages is too short to be structured this way.  The QS guide 
itself is just this "taste of the bigger picture" for the full doc set.

As I said, just some thoughts.

Bill
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] package requires different glib version

2012-02-24 Thread Saxena, Rahul 

Had a question on Glib. The configuration script of one of the packages I am 
trying to build requires glib >= 2.31.10 ,
but the Edision branch has 2.28 version.  What does one generally do in these 
type of cases ?


Thanks
Rahul
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Bugzilla downtime begins in 30 minutes

2012-02-24 Thread Michael Halstead 
We are starting the bug tracker upgrade in 30 minutes. There will be
some downtime during the transition because we are both upgrading and
moving to new servers.

I will send another list mail went the process is complete.

Michael Halstead
Sys Admin / Yocto Project



smime.p7s
Description: S/MIME Cryptographic Signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Bugzilla 4.0.3 online

2012-02-24 Thread Michael Halstead 
Bugzilla is updated and live on the new server at
https://bugzilla.yoctoproject.org/. SSL is now required to connect and
all page loads will use the yoctoproject.org domain. Old bookmarks
should be redirected properly.

If you find issues with the new version please e-mail me at
mich...@yoctoproject.org or open a bug at
https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Bugzilla

Michael Halstead
Sys Admin / Yocto Project



smime.p7s
Description: S/MIME Cryptographic Signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [KERNEL] [PATCH 0/1] Add PVR feature for Cedartrail

2012-02-24 Thread kishore . k . bodke 
From: Kishore Bodke 

Hi,

This is a new feature added to enable PVR for the Cedartrail BSP in the kernel.

Please pull into meta/cfg/kernel-cache/cfg for both linux-yocto-3.0 and 
linux-yocto-3.2 .

Thanks
Kishore.

The following changes since commit b78a519841bd8b477cad599af8d38df6760445c1:

  fri2: use emgd-1.10 (2012-02-05 00:55:05 -0500)

are available in the git repository at:
  git://git.pokylinux.org/linux-yocto-2.6.37-contrib 
kishore/meta-cedartrail/pvr-feature
  
http://git.pokylinux.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=kishore/meta-cedartrail/pvr-feature

Kishore Bodke (1):
  enable pvr features. Cedartrail has pvr kernel features and
patches.

 meta/cfg/kernel-cache/cfg/drm-cdvpvr.cfg |9 +
 meta/cfg/kernel-cache/cfg/drm-cdvpvr.scc |2 ++
 2 files changed, 11 insertions(+), 0 deletions(-)
 create mode 100644 meta/cfg/kernel-cache/cfg/drm-cdvpvr.cfg
 create mode 100644 meta/cfg/kernel-cache/cfg/drm-cdvpvr.scc

-- 
1.7.5.4

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

[yocto] [KERNEL][PATCH 1/1] enable pvr features.

2012-02-24 Thread kishore . k . bodke 
From: Kishore Bodke 

Cedartrail has pvr kernel features and patches.

Signed-off-by: Kishore Bodke 
---
 meta/cfg/kernel-cache/cfg/drm-cdvpvr.cfg |9 +
 meta/cfg/kernel-cache/cfg/drm-cdvpvr.scc |2 ++
 2 files changed, 11 insertions(+), 0 deletions(-)
 create mode 100644 meta/cfg/kernel-cache/cfg/drm-cdvpvr.cfg
 create mode 100644 meta/cfg/kernel-cache/cfg/drm-cdvpvr.scc

diff --git a/meta/cfg/kernel-cache/cfg/drm-cdvpvr.cfg 
b/meta/cfg/kernel-cache/cfg/drm-cdvpvr.cfg
new file mode 100644
index 000..0ab4488
--- /dev/null
+++ b/meta/cfg/kernel-cache/cfg/drm-cdvpvr.cfg
@@ -0,0 +1,9 @@
+CONFIG_HIGHMEM4G=y
+CONFIG_STAGING=y
+CONFIG_DRM=y
+CONFIG_SND_HDA_CODEC_HDMI=y
+CONFIG_DRM_INTEL_CDV=y
+CONFIG_DRM_CDV_RELEASE=y
+
+# CONFIG_DRM_CDV_DEBUG is not set
+# CONFIG_DRM_PVR_PDUMP is not se
diff --git a/meta/cfg/kernel-cache/cfg/drm-cdvpvr.scc 
b/meta/cfg/kernel-cache/cfg/drm-cdvpvr.scc
new file mode 100644
index 000..fbb8316
--- /dev/null
+++ b/meta/cfg/kernel-cache/cfg/drm-cdvpvr.scc
@@ -0,0 +1,2 @@
+kconf hardware drm-cdvpvr.cfg
+git merge yocto/pvr
-- 
1.7.5.4

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

Re: [yocto] adt-installer: cannot install package autoconf-nativesdk

2012-02-24 Thread Joshua Lock 

Hi Andrea,

On 24/02/12 05:40, Andrea Galbusera wrote:

The installer was built against the latest version of its recipe as
per commit c6ec5a0d9e31a1694aba25e2ff76f1c933e556d5,
adt-installer-0.1.8+svnr596-r6. I guess a change was made with commit
de68393270d5455b4861d38cef3f081b9667d25f which requires installing
autoconf/automake-nativesdk but relevant ipks are missing from
http://adtrepo.yoctoproject.org/1.1/adt-ipk/, which is still default
in latest adt_installer.conf.

Am I guessing right? First time digging into the adt_installer so I
might be completely out of track! Is this a known limit if building
adt_installer with latest edison branch? Should I file a bug for this?
If so, what's the best solution right now? Maybe using the edison
original adt_installer from the yocto downloads...


This sounds like you've correctly deduced the issue - it looks like 
there may be required changes which need backporting to the edison 
repository - I'm currently running some builds to verify this.


Please do report this information on bugzilla so that we can track it. 
It's my first time digging into the ADT installer too so it may take a 
couple of days to pull together all of the required fixes.


Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] DEPEND creep breaking poky-tiny

2012-02-24 Thread Darren Hart 
I'm working through some issues with a poky-tiny build of
core-image-minimal failing. The first error is attributable to"

commit f3677d679e5c74f9877f36cdb170bbfea9b7b9bb
glib-2.0: Add missing DEPENDS on dbus

dbus eventually pulls in shadow, which fails configure with the minimal
libc configuration in poky-tiny. Removing this dependency allows us to
make progress. (I understand a proper fix is needed, as the dependency
was added for a reason).

Next up is popt failing due to missing native language or widechar
support. pkgconfig is what brings in popt, and also what brought in glib
above. Nothing in popt suggests it changed recently, which leads me to
believe that the pkgconfig bit is new as I'm pretty sure I didn't need
glib in poky-tiny originally at all.

Has pkgconfig been added recently? Seems silly to ask, but that is where
things are pointing...

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Bugzilla 4.0.3 online

2012-02-24 Thread Darren Hart 
So far so good. 3 bugs opened, 1 fixed. :-)

On 02/24/2012 04:22 PM, Michael Halstead wrote:
> Bugzilla is updated and live on the new server at
> https://bugzilla.yoctoproject.org/. SSL is now required to connect and
> all page loads will use the yoctoproject.org domain. Old bookmarks
> should be redirected properly.
> 
> If you find issues with the new version please e-mail me at
> mich...@yoctoproject.org or open a bug at
> https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Bugzilla
> 
> Michael Halstead
> Sys Admin / Yocto Project
> 
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEPEND creep breaking poky-tiny

2012-02-24 Thread Darren Hart 


On 02/24/2012 09:55 PM, Darren Hart wrote:
> I'm working through some issues with a poky-tiny build of
> core-image-minimal failing. The first error is attributable to"
> 
> commit f3677d679e5c74f9877f36cdb170bbfea9b7b9bb
> glib-2.0: Add missing DEPENDS on dbus
> 
> dbus eventually pulls in shadow, which fails configure with the minimal
> libc configuration in poky-tiny. Removing this dependency allows us to
> make progress. (I understand a proper fix is needed, as the dependency
> was added for a reason).
> 
> Next up is popt failing due to missing native language or widechar
> support. pkgconfig is what brings in popt, and also what brought in glib
> above. Nothing in popt suggests it changed recently, which leads me to
> believe that the pkgconfig bit is new as I'm pretty sure I didn't need
> glib in poky-tiny originally at all.
> 
> Has pkgconfig been added recently? Seems silly to ask, but that is where
> things are pointing...

At some point opkg gained an RDEPENDS on pkgconfig. Trying to track down
where...


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEPEND creep breaking poky-tiny

2012-02-24 Thread Darren Hart 


On 02/24/2012 09:55 PM, Darren Hart wrote:
> I'm working through some issues with a poky-tiny build of
> core-image-minimal failing. The first error is attributable to"
> 
> commit f3677d679e5c74f9877f36cdb170bbfea9b7b9bb
> glib-2.0: Add missing DEPENDS on dbus
> 
> dbus eventually pulls in shadow, which fails configure with the minimal
> libc configuration in poky-tiny. Removing this dependency allows us to
> make progress. (I understand a proper fix is needed, as the dependency
> was added for a reason).
> 
> Next up is popt failing due to missing native language or widechar
> support. pkgconfig is what brings in popt, and also what brought in glib
> above. Nothing in popt suggests it changed recently, which leads me to
> believe that the pkgconfig bit is new as I'm pretty sure I didn't need
> glib in poky-tiny originally at all.
> 
> Has pkgconfig been added recently? Seems silly to ask, but that is where
> things are pointing...
> 


commit 76640582e8ba114d4e80a494f6680fd0ce57ca58
Date:   Tue Jan 31 15:52:27 2012 +

pkgconfig: Ensure pkgconfig RDEPENDS are tracked

RP, is this meant to force the building of pkgconfig? It changes the
requirement from pkgconfig-native to both pkgconfig and
pkgconfig-native.


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] apt-native_0.7.14.bb failed

2012-02-24 Thread JINGZHE YU 
Hi,

I tried to build image with: bitbake -k core-image-sato, with
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2

but it failed, here is error message:

---
NOTE: Running task 5229 of 5288 (ID: 82,
/home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/
apt-native_0.7.14.bb, do_install)
NOTE: package apt-native-0.7.14-r5: task do_install: Started
ERROR: Function 'do_install_base' failed (see
/home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773
for further information)
ERROR: Logfile of failure stored in:
/home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773
Log data follows:
| oe_libinstall: cd bin
| oe_libinstall: install -d
/home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/image/home/jingzhe/yocto/edison-6.0-build/tmp/sysroots/i686-linux/usr/lib//
| ERROR: oe_libinstall: unable to locate shared library
| ERROR: Function 'do_install_base' failed (see
/home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773
for further information)
NOTE: package apt-native-0.7.14-r5: task do_install: Failed
ERROR: Task 82
(/home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/
apt-native_0.7.14.bb, do_install) failed with exit code '1'
ERROR: '/home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/
apt-native_0.7.14.bb' failed
--

does anybody know how to solve it?

br,

Jingzhe
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto