Re: [yocto] .bashrc not being used by root account

[Mihai Lindner]

On 10/17/2012 09:25 AM, Venkata ramana gollamudi wrote:

You can check the same with  "strace -f bash"
You can see the files being loaded, as there is a rc file loading sequence 
exists for bash.

Regards,
Ramana


From: yocto-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on behalf 
of Jonathan Haws [jonathan.h...@sdl.usu.edu]
Sent: Tuesday, October 16, 2012 9:32 PM
To: yocto@yoctoproject.org
Subject: [yocto] .bashrc not being used by root account

I have modified the .bashrc file for the system, however the root account does 
not seem to use it by default.  What am I missing?  I would rather not have to 
source the .bashrc file every time I login as root.


Try `echo $0` to see the shell you're in. By default you should be in 
`sh`, which does not source .bashrc.

You can execute `bash` after login, or change the login shell of 'root'.

Cheers,
--Mihai



Thanks,
Jonathan

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




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

[yocto] How to avoid re-creating a recipe (+my meta-bucket approach)

[Tim O'Callaghan]

Hi,

After seeing the lmsensors thread float by I thought it about time I started 
the discussion on how people manage to avoid re-inventing recipes, and to get 
the ball rolling, I thought I would describe mine.

As I do not have the any idea what recipes may be kicking about, I devised what 
I call the meta-bucket approach. It is pretty simple, I have a script that 
clones every existing OE/Yocto repository I know about into one easily 
grep-able place[1]. 

The to the main question, how are others managing this?

Best regards,

Tim.
[1] https://github.com/timoc/meta-bucket

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

Re: [yocto] How to avoid re-creating a recipe (+my meta-bucket approach)

[Paul Eggleton]

On Wednesday 17 October 2012 08:39:36 Tim O'Callaghan wrote:
> After seeing the lmsensors thread float by I thought it about time I started
> the discussion on how people manage to avoid re-inventing recipes, and to
> get the ball rolling, I thought I would describe mine.
> 
> As I do not have the any idea what recipes may be kicking about, I devised
> what I call the meta-bucket approach. It is pretty simple, I have a script
> that clones every existing OE/Yocto repository I know about into one easily
> grep-able place[1].
> 
> The to the main question, how are others managing this?

I clone the layer repositories most likely to hold new recipes and then use 
some scripts I wrote to process them into a list of recipes that can be easily 
searched using grep. I wouldn't mind sharing those scripts if some people 
would find them useful.

However, what I hope we can do in the 1.4 timeframe would be to implement my 
proposal here:

 https://bugzilla.yoctoproject.org/show_bug.cgi?id=3272

This would provide us with a way to search all published layers down to the 
recipe level from the web.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-fsl-ppc] hypervisor: add missing space character for PACKAGES_prepend

[Zhenhua Luo]

Signed-off-by: Zhenhua Luo 
---
 recipes-tools/embedded-hv/hypervisor_git.bb |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/recipes-tools/embedded-hv/hypervisor_git.bb 
b/recipes-tools/embedded-hv/hypervisor_git.bb
index 50697fc..3a3f605 100644
--- a/recipes-tools/embedded-hv/hypervisor_git.bb
+++ b/recipes-tools/embedded-hv/hypervisor_git.bb
@@ -3,6 +3,8 @@ SECTION = "embedded-hv"
 LICENSE = "BSD"
 LIC_FILES_CHKSUM = 
"file://README;endline=22;md5=0655bbc3b7d7166c30c87208b4e23cf0"
 
+PR = "r1"
+
 DEPENDS = "u-boot-mkimage-native"
 
 inherit deploy
@@ -74,6 +76,6 @@ do_deploy_append() {
 }
 
 ALLOW_EMPTY_${PN} = "1"
-PACKAGES_prepend = "${PN}-image ${PN}-partman"
+PACKAGES_prepend = "${PN}-image ${PN}-partman "
 FILES_${PN}-image = "/boot/"
 FILES_${PN}-partman = "${bindir}/partman"
-- 
1.7.9.5


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

Re: [yocto] How to avoid re-creating a recipe (+my meta-bucket approach)

[Tom Zanussi]

On Wed, 2012-10-17 at 08:39 +, Tim O'Callaghan wrote:
> Hi,
> 
> After seeing the lmsensors thread float by I thought it about time I started 
> the discussion on how people manage to avoid re-inventing recipes, and to get 
> the ball rolling, I thought I would describe mine.
> 
> As I do not have the any idea what recipes may be kicking about, I devised 
> what I call the meta-bucket approach. It is pretty simple, I have a script 
> that clones every existing OE/Yocto repository I know about into one easily 
> grep-able place[1]. 
> 
> The to the main question, how are others managing this?
> 
> Best regards,
> 
> Tim.
> [1] https://github.com/timoc/meta-bucket
> 

I do a similar thing - clone all the repos I can think of, and then have
OpenGrok index them all.  That makes everything available as a fully
searchable cross-referenced set of web pages.  Couldn't live without
it...

http://hub.opensolaris.org/bin/view/Project+opengrok/

Tom

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


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

[yocto] Cedar Trail and gst-vaapi fixes

[Ross Burton]

Hi,

Make gst-vaapi work on Cedar Trail, upgrade the gst-vaapi to the latest version
which doesn't need ffmpeg anymore, and remove the commercial restriction on
gst-vaapi.

The new gst-vaapi was tested on Cedar Trail, and played the Sintel 720p trailer
smoothly.  ffmpeg was required for the audio (MPEG4 AAC), but without that
present the video still plays.

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

[yocto] [PATCH 2/3] gstreamer-vaapi: upgrade to 0.3.8, and remove ffmpeg dependencies

[Ross Burton]

Signed-off-by: Ross Burton 
---
 .../gstreamer/gstreamer-vaapi_git.bb   |   21 ++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb 
b/common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb
index fe601cc..27552a2 100644
--- a/common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb
+++ b/common/recipes-multimedia/gstreamer/gstreamer-vaapi_git.bb
@@ -6,15 +6,14 @@ based plugins for GStreamer and helper libraries: 
`vaapidecode', \
 LICENSE = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"
 
-DEPENDS = "gstreamer libva ffmpeg"
+DEPENDS = "gstreamer libva"
 
-# 0.2.9 tag
-SRCREV = "c98c14bd32855467a5a0ff21b6c703e9e3461467"
-PV = "0.2.9+git${SRCPV}"
+# 0.3.8 tag
+SRCREV = "6ec4c2252a4aa706cd8631cb1083828485b9df9a"
+PV = "0.3.8+git${SRCPV}"
 PR = "r0"
 
-SRC_URI = "git://gitorious.org/vaapi/gstreamer-vaapi.git \
-   file://glib-includes.patch"
+SRC_URI = "git://gitorious.org/vaapi/gstreamer-vaapi.git"
 
 SRC_URI[md5sum] = "729d75f21df79114a8c81d896489e5ad"
 SRC_URI[sha256sum] = 
"f1770c4537f1615701dbc845eee5732fbb1036b3acafbc7488e551fab334a31d"
@@ -23,6 +22,16 @@ S = "${WORKDIR}/git"
 
 inherit autotools pkgconfig gtk-doc
 
+EXTRA_OECONF = "--disable-ffmpeg"
+
+do_configure_prepend() {
+  # DEBUG: Executing shell function do_configure
+  # ln: target `m4/' is not a directory: No such file or directory
+  # cp: cannot create regular file `m4/': Not a directory
+  # (should be fixed in autotools.bbclass)
+  mkdir --parents ${B}/m4
+}
+
 FILES_${PN} += "${libdir}/gstreamer-0.10/*.so"
 FILES_${PN}-dbg += "${libdir}/gstreamer-0.10/.debug"
 FILES_${PN}-dev += "${libdir}/gstreamer-0.10/*.la ${libdir}/gstreamer-0.10/*.a"
-- 
1.7.10

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

[yocto] [PATCH 1/3] cedartrail: add missing gst-va-intel-vaapi machine feature

[Ross Burton]

There needs to be a gst-va-* MACHINE_FEATURE to get the right VA elements in the
images.

Signed-off-by: Ross Burton 
---
 meta-cedartrail/conf/machine/cedartrail.conf |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cedartrail/conf/machine/cedartrail.conf 
b/meta-cedartrail/conf/machine/cedartrail.conf
index 33af012..ea50ea6 100644
--- a/meta-cedartrail/conf/machine/cedartrail.conf
+++ b/meta-cedartrail/conf/machine/cedartrail.conf
@@ -7,7 +7,7 @@
 require conf/machine/include/tune-atom.inc
 require conf/machine/include/ia32-base.inc
 
-MACHINE_FEATURES += "pcbios efi"
+MACHINE_FEATURES += "pcbios efi va-impl-intel"
 
 XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
-- 
1.7.10

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

[yocto] [PATCH 3/3] meta-intel: don't require commercial licenses for gstreamer-vaapi

[Ross Burton]

Now that gstreamer-vaapi doesn't depend on ffmpeg, it can always be recommended
by the machine configuration.

Signed-off-by: Ross Burton 
---
 meta-cedartrail/conf/machine/cedartrail.conf |5 +
 meta-chiefriver/conf/machine/chiefriver.conf |5 +
 meta-crownbay/conf/machine/crownbay.conf |5 +
 meta-fri2/conf/machine/fri2.conf |5 +
 meta-sugarbay/conf/machine/sugarbay.conf |5 +
 meta-sys940x/conf/machine/sys940x.conf   |5 +
 6 files changed, 6 insertions(+), 24 deletions(-)

diff --git a/meta-cedartrail/conf/machine/cedartrail.conf 
b/meta-cedartrail/conf/machine/cedartrail.conf
index ea50ea6..40920fe 100644
--- a/meta-cedartrail/conf/machine/cedartrail.conf
+++ b/meta-cedartrail/conf/machine/cedartrail.conf
@@ -22,7 +22,4 @@ SYSLINUX_OPTS = "serial 0 115200"
 SERIAL_CONSOLE = "115200 ttyS0"
 APPEND += "console=ttyS0,115200 console=tty0"
 
-VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
-   "commercial", "gst-va-intel va-intel", "", d)}"
-
-MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
+MACHINE_EXTRA_RRECOMMENDS += "gst-va-intel va-intel"
diff --git a/meta-chiefriver/conf/machine/chiefriver.conf 
b/meta-chiefriver/conf/machine/chiefriver.conf
index a9c8e5a..8074623 100644
--- a/meta-chiefriver/conf/machine/chiefriver.conf
+++ b/meta-chiefriver/conf/machine/chiefriver.conf
@@ -15,7 +15,4 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_I965} \
"
 
-VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
-   "commercial", "gst-va-intel va-intel", "", d)}"
-
-MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES} lms"
+MACHINE_EXTRA_RRECOMMENDS += "gst-va-intel va-intel lms"
diff --git a/meta-crownbay/conf/machine/crownbay.conf 
b/meta-crownbay/conf/machine/crownbay.conf
index 72431de..bc0b0f9 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -23,7 +23,4 @@ PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
 
 APPEND += "video=vesafb vga=0x318 vmalloc=256MB"
 
-VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
-   "commercial", "gst-va-intel va-intel", "va-intel", d)}"
-
-MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
+MACHINE_EXTRA_RRECOMMENDS += "gst-va-intel va-intel"
diff --git a/meta-fri2/conf/machine/fri2.conf b/meta-fri2/conf/machine/fri2.conf
index dff11a8..46fd7a7 100644
--- a/meta-fri2/conf/machine/fri2.conf
+++ b/meta-fri2/conf/machine/fri2.conf
@@ -8,11 +8,8 @@ require conf/machine/include/tune-atom.inc
 require conf/machine/include/ia32-base.inc
 require conf/machine/include/meta-intel.inc
 
-VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
-   "commercial", "gst-va-intel va-intel", "va-intel", d)}"
-
 MACHINE_FEATURES += "wifi 3g pcbios efi va-impl-mixvideo"
-MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5 ${VA_FEATURES}"
+MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5 gst-va-intel 
va-intel"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto = "3.4%"
diff --git a/meta-sugarbay/conf/machine/sugarbay.conf 
b/meta-sugarbay/conf/machine/sugarbay.conf
index 17cc15c..3282fc8 100644
--- a/meta-sugarbay/conf/machine/sugarbay.conf
+++ b/meta-sugarbay/conf/machine/sugarbay.conf
@@ -16,7 +16,4 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_I965} \
"
 
-VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
-   "commercial", "gst-va-intel va-intel", "", d)}"
-
-MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
+MACHINE_EXTRA_RRECOMMENDS += "gst-va-intel va-intel"
diff --git a/meta-sys940x/conf/machine/sys940x.conf 
b/meta-sys940x/conf/machine/sys940x.conf
index bdd655f..7e0d289 100644
--- a/meta-sys940x/conf/machine/sys940x.conf
+++ b/meta-sys940x/conf/machine/sys940x.conf
@@ -26,7 +26,4 @@ PREFERRED_VERSION_emgd-driver-bin ?= "1.14"
 SERIAL_CONSOLE = "115200 ttyS0"
 APPEND += "console=ttyS0,115200 console=tty0"
 
-VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
-   "commercial", "gst-va-intel va-intel", "va-intel", d)}"
-
-MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
+MACHINE_EXTRA_RRECOMMENDS += "gst-va-intel va-intel"
-- 
1.7.10

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

Re: [yocto] [meta-fsl-ppc] hypervisor: add missing space character for PACKAGES_prepend

[McClintock Matthew-B29882]

Applied to meta-fsl-ppc denzil, danny, and master.

-M

On Wed, Oct 17, 2012 at 5:15 AM, Zhenhua Luo  wrote:
> Signed-off-by: Zhenhua Luo 
> ---
>  recipes-tools/embedded-hv/hypervisor_git.bb |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/recipes-tools/embedded-hv/hypervisor_git.bb 
> b/recipes-tools/embedded-hv/hypervisor_git.bb
> index 50697fc..3a3f605 100644
> --- a/recipes-tools/embedded-hv/hypervisor_git.bb
> +++ b/recipes-tools/embedded-hv/hypervisor_git.bb
> @@ -3,6 +3,8 @@ SECTION = "embedded-hv"
>  LICENSE = "BSD"
>  LIC_FILES_CHKSUM = 
> "file://README;endline=22;md5=0655bbc3b7d7166c30c87208b4e23cf0"
>
> +PR = "r1"
> +
>  DEPENDS = "u-boot-mkimage-native"
>
>  inherit deploy
> @@ -74,6 +76,6 @@ do_deploy_append() {
>  }
>
>  ALLOW_EMPTY_${PN} = "1"
> -PACKAGES_prepend = "${PN}-image ${PN}-partman"
> +PACKAGES_prepend = "${PN}-image ${PN}-partman "
>  FILES_${PN}-image = "/boot/"
>  FILES_${PN}-partman = "${bindir}/partman"
> --
> 1.7.9.5
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Requesting information on some variables

[Rifenbark, Scott M]

There is a bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3292) stating 
that we need better documentation describing how DISTRO_FEATURES, 
COMMON_FEATURES, and MACHINE_FEATURES actually affect the build.  I don't know 
anything about these variables beyond what is in the reference manual:

http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-DISTRO_FEATURES
http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-MACHINE_FEATURES
(no current entry for  COMMON_FEATURES)

Can anyone provide additional information for these three variables and how 
they interact with the build system and with one another?

Thanks,
Scott


Bug 3292

The documentation for the following variables:

DISTRO_FEATURES
COMMON_FEATURES
MACHINE_FEATURES

is inadequate to instruct would-be users of how changes will impact the system.

These variables combine to determine various aspects of how images and packages 
are built. They impact RDEPENDS of various packagegroups, impact the way live 
images are built, and certainly others. MACHINE_FEATURES as a documented list 
of values, DISTRO_FEATURES does not. I do not see COMMON_FEATURES listed at all.

A discussion of how these interrelate and how someone can discover the exact 
impact from the sources would be useful. For example, using "git grep 
'contains.*MACHINE_FEATURES.*'" to discover how the build is impacted 
would be a useful addition.

It isn't practical to define the dependency chains in the documentation, but 
providing the user with the background and tools to discover them seems 
appropriate.


Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)

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

Re: [yocto] Requesting information on some variables

[Paul Eggleton]

On Wednesday 17 October 2012 15:32:40 Rifenbark, Scott M wrote:
> There is a bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3292)
> stating that we need better documentation describing how DISTRO_FEATURES,
> COMMON_FEATURES, and MACHINE_FEATURES actually affect the build.  I don't
> know anything about these variables beyond what is in the reference manual:
> 
> http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#va
> r-DISTRO_FEATURES
> http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#v
> ar-MACHINE_FEATURES (no current entry for  COMMON_FEATURES)
> 
> Can anyone provide additional information for these three variables and how
> they interact with the build system and with one another?

Looking at the bug report I'm guessing Darren was looking at the current 
version of the documentation prior to adding a link to the section that lists 
DISTRO_FEATURES options (which only got added recently). However that list is 
incomplete and even then it does not explain how you would determine what the 
actual effect of adding or removing a feature would be.

I think Darren's suggestion of using "git grep" to find the actual effect is 
good, after some preamble that mentions we use the "base_contains" function in 
various recipes and configuration files in order to change behaviour based on 
the presence or absence of features, giving at least one example from the 
current metadata.

Some explanation of how these variables relate to eachother:

* DISTRO_FEATURES is used to enable/disable software features (some of which 
are related to hardware feature support). This is set in the distro .conf file.

* MACHINE_FEATURES describes what hardware features a specific machine 
supports. It is set in the machine .conf file.

* COMBINED_FEATURES lists features both enabled by DISTRO_FEATURES and 
supported by the hardware as declared by MACHINE_FEATURES. It is set 
automatically by the build system.

The COMBINED_FEATURES mechanism allows a BSP to declare that a piece of 
hardware supports a feature, but a person building a distro (or OS) to decide 
that they don't want to support the feature; thus the feature only gets 
enabled in the software if it appears on in both places.

Cheers,
Paul

 
> Thanks,
> Scott
> 
> 
> Bug 3292
> 
> The documentation for the following variables:
> 
> DISTRO_FEATURES
> COMMON_FEATURES
> MACHINE_FEATURES
> 
> is inadequate to instruct would-be users of how changes will impact the
> system.
> 
> These variables combine to determine various aspects of how images and
> packages are built. They impact RDEPENDS of various packagegroups, impact
> the way live images are built, and certainly others. MACHINE_FEATURES as a
> documented list of values, DISTRO_FEATURES does not. I do not see
> COMMON_FEATURES listed at all.
> 
> A discussion of how these interrelate and how someone can discover the exact
> impact from the sources would be useful. For example, using "git grep
> 'contains.*MACHINE_FEATURES.*'" to discover how the build is
> impacted would be a useful addition.
> 
> It isn't practical to define the dependency chains in the documentation, but
> providing the user with the background and tools to discover them seems
> appropriate.
> 
> 
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702
> 503.341.0418 (cell)
-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Requesting information on some variables

[Rifenbark, Scott M]

This is helpful... thanks Paul.

-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] 
Sent: Wednesday, October 17, 2012 8:59 AM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Requesting information on some variables

On Wednesday 17 October 2012 15:32:40 Rifenbark, Scott M wrote:
> There is a bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3292)
> stating that we need better documentation describing how DISTRO_FEATURES,
> COMMON_FEATURES, and MACHINE_FEATURES actually affect the build.  I don't
> know anything about these variables beyond what is in the reference manual:
> 
> http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#va
> r-DISTRO_FEATURES
> http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#v
> ar-MACHINE_FEATURES (no current entry for  COMMON_FEATURES)
> 
> Can anyone provide additional information for these three variables and how
> they interact with the build system and with one another?

Looking at the bug report I'm guessing Darren was looking at the current 
version of the documentation prior to adding a link to the section that lists 
DISTRO_FEATURES options (which only got added recently). However that list is 
incomplete and even then it does not explain how you would determine what the 
actual effect of adding or removing a feature would be.

I think Darren's suggestion of using "git grep" to find the actual effect is 
good, after some preamble that mentions we use the "base_contains" function in 
various recipes and configuration files in order to change behaviour based on 
the presence or absence of features, giving at least one example from the 
current metadata.

Some explanation of how these variables relate to eachother:

* DISTRO_FEATURES is used to enable/disable software features (some of which 
are related to hardware feature support). This is set in the distro .conf file.

* MACHINE_FEATURES describes what hardware features a specific machine 
supports. It is set in the machine .conf file.

* COMBINED_FEATURES lists features both enabled by DISTRO_FEATURES and 
supported by the hardware as declared by MACHINE_FEATURES. It is set 
automatically by the build system.

The COMBINED_FEATURES mechanism allows a BSP to declare that a piece of 
hardware supports a feature, but a person building a distro (or OS) to decide 
that they don't want to support the feature; thus the feature only gets 
enabled in the software if it appears on in both places.

Cheers,
Paul

 
> Thanks,
> Scott
> 
> 
> Bug 3292
> 
> The documentation for the following variables:
> 
> DISTRO_FEATURES
> COMMON_FEATURES
> MACHINE_FEATURES
> 
> is inadequate to instruct would-be users of how changes will impact the
> system.
> 
> These variables combine to determine various aspects of how images and
> packages are built. They impact RDEPENDS of various packagegroups, impact
> the way live images are built, and certainly others. MACHINE_FEATURES as a
> documented list of values, DISTRO_FEATURES does not. I do not see
> COMMON_FEATURES listed at all.
> 
> A discussion of how these interrelate and how someone can discover the exact
> impact from the sources would be useful. For example, using "git grep
> 'contains.*MACHINE_FEATURES.*'" to discover how the build is
> impacted would be a useful addition.
> 
> It isn't practical to define the dependency chains in the documentation, but
> providing the user with the background and tools to discover them seems
> appropriate.
> 
> 
> Scott Rifenbark
> Intel Corporation
> Yocto Project Documentation
> 503.712.2702
> 503.341.0418 (cell)
-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to avoid re-creating a recipe (+my meta-bucket approach)

[Philip Balister]

On 10/17/2012 01:49 AM, Paul Eggleton wrote:

On Wednesday 17 October 2012 08:39:36 Tim O'Callaghan wrote:

After seeing the lmsensors thread float by I thought it about time I started
the discussion on how people manage to avoid re-inventing recipes, and to
get the ball rolling, I thought I would describe mine.

As I do not have the any idea what recipes may be kicking about, I devised
what I call the meta-bucket approach. It is pretty simple, I have a script
that clones every existing OE/Yocto repository I know about into one easily
grep-able place[1].

The to the main question, how are others managing this?


I clone the layer repositories most likely to hold new recipes and then use
some scripts I wrote to process them into a list of recipes that can be easily
searched using grep. I wouldn't mind sharing those scripts if some people
would find them useful.

However, what I hope we can do in the 1.4 timeframe would be to implement my
proposal here:

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=3272

This would provide us with a way to search all published layers down to the
recipe level from the web.


This is an excellent idea!

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

Re: [yocto] Requesting information on some variables

[Rudolf Streif]

Scott,

Thanks for addressing this confusing part. The list of DISTRO_FEATURES (DF)
and MACHINE_FEATURES (MF) in the documentation also does not seem to be
complete. For instance, vfat is (at least the code in bitbake.conf that
intersects DF and MF suggests so) is a MF as well as a DF.

It also seems that any package is fair game for DF (which makes sense) but
the documentation says "The items below are valid options for
DISTRO_FEATURES
:".

Some elaboration on the features would be great too. From the explanation
it is not obvious why ext2 is considered a DF as well as a MF. The same
seems to be the case with vfat (although not listed in the documentation).
Other file systems e.g. ext3 etc. are purely considered DF.

Here are the variables from a build environment building for the Beagleboard

bitbake core-image-minimal -e | grep MACHINE_FEATURES
MACHINE_FEATURES="apm usbgadget usbhost vfat alsa"

bitbake core-image-minimal -e | grep DISTRO_FEATURES
DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia usbgadget
usbhost wifi xattr nfs zeroconf pci 3g x11 ipv4 ipv6 libc-backtrace
libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets
libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg
libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm
libc-libm-big libc-locales libc-locale-code libc-memusage libc-nis
libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc
libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp
libc-posix-regexp-glibc libc-posix-wchar-io largefile opengl pulseaudio"

bitbake core-image-minimal -e | grep COMBINED_FEATURES
COMBINED_FEATURES="alsa usbgadget usbhost"

CF seems to be an intersection of DF and MF.  If I remove usbgadget from MF
then CF will of course not contain it. DF will still have it. What actually
does get included with the image? Is it DF - [list of all available machine
features] + CF?

[list of all available machine features] is then the superset of MF that is
typically defined in a machine.conf file. That list must be implicit
somewhere in the classes/configuration files somewhere, possibly
bitbake.conf.

That leads me to the next question. I have seen BSPs that include 'screen'
into MF in their machine.conf files. That feature is also in the
documentation. But it does not show up anywhere in DF or bitbake.conf etc.

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

Re: [yocto] lm-sensors not available as a package?

[Jonathan Haws]

Marc,

If you have a working recipe, I would love to see it.  Maybe you have already 
solved some of the issues I have been seeing.

I have a recipe that installs the software, however, I would like to have it 
run sensors-detect on first boot as well as install the lm_sensors.init script 
to /etc/init.d.  My recipe now looks like this:


DESCRIPTION = "Hardware health monitoring applications"
HOMEPAGE = "http://www.lm-sensors.org/";
DEPENDS = "sysfsutils virtual/libiconv"
LICENSE = "GPLv2"
PR = "r1"
DEPENDS = "bison-native flex-native"
PACKAGE_ARCH = "${MACHINE_ARCH}"

SRC_URI = 
"http://dl.lm-sensors.org/lm-sensors/releases/lm_sensors-${PV}.tar.bz2";

LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
file://COPYING.LGPL;md5=4fbd65380cdd255951079008b364516c \
   "

SRC_URI[md5sum] = "f357ba00b080ab102a170f7bf8bb2578"
SRC_URI[sha256sum] = 
"f13dd885406841a7352ccfb8b9ccb23c4c057abe3de4258da5444c149a9e3ae1"

S = "${WORKDIR}/lm_sensors-${PV}"

EXTRA_OEMAKE = 'LINUX=${STAGING_KERNEL_DIR} EXLDFLAGS="${LDFLAGS}" \
MACHINE=${TARGET_ARCH} PREFIX=${prefix} CC="${CC}" AR="${AR}"'

do_compile() {
oe_runmake user PROG_EXTRA=sensors
}

do_install() {
oe_runmake user_install DESTDIR=${D}
install -m 0755 ${S}/prog/init/lm_sensors.init 
${D}/${sysconfdir}/init.d/lm_sensors.init

ln -sf ../init.d/lm_sensors.init 
${D}${sysconfdir}/rcS.d/S90lm_sensors.init
}

pkr_postinst_lmsensors-scripts() {
#!/bin/sh -e
if [ x"$D" = "x" ]; then
# Actions to carry out on the device go here
yes | sensors-detect
else
exit 1
fi
}

PACKAGES =+ "lmsensors-sensors lmsensors-sensors-dbg"
PACKAGES =+ "lmsensors-scripts"

FILES_lmsensors-scripts = "${bindir}/*.pl ${bindir}/ddcmon 
${sbindir}/fancontrol* ${sbindir}/pwmconfig ${sbindir}/sensors-detect 
${sysconfdir}/init.d/lm_sensors.init"
RDEPENDS_lmsensors-scripts += "lmsensors-sensors perl bash perl-modules"

FILES_lmsensors-sensors = "${bindir}/sensors ${sysconfdir}"
FILES_lmsensors-sensors-dbg += "${bindir}/.debug/sensors"


However, I get the following errors when building:


ERROR: Function failed: do_install (see 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/temp/log.do_install.9255
 for further information)
ERROR: Logfile of failure stored in: 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/temp/log.do_install.9255
Log data follows:
| DEBUG: Executing shell function do_install
| NOTE: make -j 4 
LINUX=/opt/yocto/poky/build/tmp/sysroots/penryn/usr/src/kernel 
EXLDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed MACHINE=x86_64 
PREFIX=/usr CC=x86_64-poky-linux-gcc-m64  -march=core2 -msse3 
-mtune=generic -mfpmath=sse --sysroot=/opt/yocto/poky/build/tmp/sysroots/penryn 
AR=x86_64-poky-linux-ar user_install 
DESTDIR=/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image
| mkdir -p 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/lib
 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/include/sensors
 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/man/man3
 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/man/man5
| mkdir -p 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/sbin
 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/man/man8
| mkdir -p 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/sbin
 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/man/man8
| mkdir -p 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/bin
 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/man/man1
| install -m 755 prog/detect/sensors-detect 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/sbin
| install -m 755 prog/pwm/fancontrol prog/pwm/pwmconfig 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/sbin
| install -m 755 prog/sensors/sensors 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/bin
| install -m 644 lib/libsensors.a 
/opt/yocto/poky/build/tmp/work/penryn-poky-linux/lmsensors-apps-3.3.2-r1/image/usr/lib
| install -m 644 prog/pwm/fancontrol.8 prog/pwm/pwmconfig.8 
/opt/yoc

Re: [yocto] lm-sensors not available as a package?

[Marc Ferland]

Jonathan Haws  writes:

> Marc,
>
> If you have a working recipe, I would love to see it.  Maybe you have
> already solved some of the issues I have been seeing.
>
> I have a recipe that installs the software, however, I would like to
> have it run sensors-detect on first boot as well as install the
> lm_sensors.init script to /etc/init.d.  My recipe now looks like this:
>
Hi Jonathan,

I have posted a firt version of my recipe to the oe-core mailing
list. You can try this.

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-October/031002.html

I'll probably post a revised version by the end of the week to the
meta-oe mailing list as suggested by Paul and Martin.

Enjoy!

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

[yocto] [PATCH 0/2][meta-intel] meta-crystalforest: Add openssl qat_mem module

[kishore . k . bodke]

From: Kishore Bodke 

Hi,

This patch set adds a new recipe for Intel Quick Assist Technology
Memory Management Module based on Openssl and inlcude them into custom
build Image recipe.

Please pull into meta-intel/master.

Thanks
Kishore.

The following changes since commit 4614417599d35b004e4cf8a4d27530212cc05e20:

  sugarbay: update kernel repo srcrevs (2012-10-16 21:14:55 -0500)

are available in the git repository at:

  git://git.pokylinux.org/meta-intel-contrib Kishore/openssl-qat_mem
  
http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=Kishore/openssl-qat_mem

Kishore Bodke (2):
  meta-intel/common: Add new recipe for libcrypto module.
  meta-crystalforest: Add openssl-qat-module to the Image.

 common/recipes-connectivity/openssl-qat-module.bb  |   63 
 .../openssl-qat-module/openssl_qat_module.patch|   43 +
 .../recipes-qat-image/images/core-image-qat-sdk.bb |1 +
 .../recipes-qat-image/images/core-image-qat.bb |1 +
 4 files changed, 108 insertions(+)
 create mode 100644 common/recipes-connectivity/openssl-qat-module.bb
 create mode 100644 
common/recipes-connectivity/openssl-qat-module/openssl_qat_module.patch

-- 
1.7.9.5

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

[yocto] [PATCH 2/2] [meta-intel] meta-crystalforest: Add openssl-qat-module to the Image.

[kishore . k . bodke]

From: Kishore Bodke 

This adds the openssl-qat-module to build with the custom
Image.

Signed-off-by: Kishore Bodke 
---
 .../recipes-qat-image/images/core-image-qat-sdk.bb |1 +
 .../recipes-qat-image/images/core-image-qat.bb |1 +
 2 files changed, 2 insertions(+)

diff --git a/meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb 
b/meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb
index 27feb0d..20aae7e 100644
--- a/meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb
+++ b/meta-crystalforest/recipes-qat-image/images/core-image-qat-sdk.bb
@@ -9,6 +9,7 @@ IMAGE_INSTALL += " \
calgary-corpus \
canterbury-corpus \
silesia-corpus \
+   openssl-qat-module \
"
 
 LICENSE = "MIT"
diff --git a/meta-crystalforest/recipes-qat-image/images/core-image-qat.bb 
b/meta-crystalforest/recipes-qat-image/images/core-image-qat.bb
index 7c61ec6..eb1c30a 100644
--- a/meta-crystalforest/recipes-qat-image/images/core-image-qat.bb
+++ b/meta-crystalforest/recipes-qat-image/images/core-image-qat.bb
@@ -9,6 +9,7 @@ IMAGE_INSTALL += " \
calgary-corpus \
canterbury-corpus \
silesia-corpus \
+   openssl-qat-module \
"
 
 LICENSE = "MIT"
-- 
1.7.9.5

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

[yocto] [PATCH 1/2] [meta-intel] meta-intel/common: Add new recipe for libcrypto module.

[kishore . k . bodke]

From: Kishore Bodke 

This adds a new recipe to include the Intel Quick Assist
Technology libcrypto Memory Management Module.

Signed-off-by: Kishore Bodke 
---
 common/recipes-connectivity/openssl-qat-module.bb  |   63 
 .../openssl-qat-module/openssl_qat_module.patch|   43 +
 2 files changed, 106 insertions(+)
 create mode 100644 common/recipes-connectivity/openssl-qat-module.bb
 create mode 100644 
common/recipes-connectivity/openssl-qat-module/openssl_qat_module.patch

diff --git a/common/recipes-connectivity/openssl-qat-module.bb 
b/common/recipes-connectivity/openssl-qat-module.bb
new file mode 100644
index 000..cf08213
--- /dev/null
+++ b/common/recipes-connectivity/openssl-qat-module.bb
@@ -0,0 +1,63 @@
+SUMMARY = "libcrypto* (OpenSSL*) QAT_MEM Memory Management Module for Intel 
Quick Assist Technology"
+DESCRIPTION = "This software adds an engine that accelerates some of the 
libcrypto algorithms via the \
+   Intel QuickAssist Technology implemented on Intel 
Communications Chipset 89xx Series \
+   based platforms."
+
+HOMEPAGE = "http://www.openssl.org/";
+SECTION = "libs/network"
+
+LICENSE = "openssl"
+
+LIC_FILES_CHKSUM = 
"file://${WORKDIR}/openssl-${PV}/LICENSE;md5=f9a8f968107345e0b75aa8c2ecaa7ec8"
+
+PV = "1.0.1"
+PR="r0"
+
+OPENSSL_QAT_VERSION = "0.4.0-012"
+
+SRC_URI = " \
+   http://www.openssl.org/source/openssl-${PV}.tar.gz;name=openssl 
\
+   
http://downloadmirror.intel.com/19368/eng/libcrypto-openssl-${PV}-qat.L.${OPENSSL_QAT_VERSION}.tar.gz;name=libcrypto;striplevel=2
 \
+   file://openssl_qat_module.patch;striplevel=1 \
+   "
+
+SRC_URI[openssl.md5sum]="134f168bc2a8333f19f81d684841710b"
+SRC_URI[openssl.sha256sum]="4d9f0a594a9a89b28e1a04a9504c04104f6508ee27ad1e0efdd17a7a6dbb"
+
+SRC_URI[libcrypto.md5sum] = "e4e131fa56d3aa1a52b5bdb9f8fe5a69"
+SRC_URI[libcrypto.sha256sum] = 
"19a80ae6e78548934295d312148e4254c18dabd25e2fd72de5796d8ac15b1cfb"
+
+S = "${WORKDIR}/openssl-${PV}/engines/qat_engine/qat_mem"
+
+export KERNEL_SOURCE_ROOT = "${STAGING_KERNEL_DIR}"
+inherit module
+
+do_patch() {
+
+   cd ${WORKDIR}/openssl-${PV}
+   patch -p2 < 
${WORKDIR}/libcrypto-openssl-${PV}-qat.L.${OPENSSL_QAT_VERSION}.patch
+
+   cd ${WORKDIR}
+   patch -p1 <${WORKDIR}/openssl_qat_module.patch
+
+}
+
+do_compile()   {
+
+   cd ${S}
+   oe_runmake  KERNEL_CC="${KERNEL_CC}"
+}
+
+do_install_append(){
+
+   install -m 0755 -d  ${D}${bindir} \
+   ${D}${includedir}/engines/qat_engine/qat_mem
+
+   install -m 0755 ${S}/qat_mem_test   
${D}${bindir}
+   install -m 0750 ${S}/*.h
${D}${includedir}/engines/qat_engine/qat_mem/
+
+}
+
+FILES_${PN} += "\
+   ${bindir}/qat_mem_test \
+   "
diff --git 
a/common/recipes-connectivity/openssl-qat-module/openssl_qat_module.patch 
b/common/recipes-connectivity/openssl-qat-module/openssl_qat_module.patch
new file mode 100644
index 000..dfed3c0
--- /dev/null
+++ b/common/recipes-connectivity/openssl-qat-module/openssl_qat_module.patch
@@ -0,0 +1,43 @@
+Index: 
openssl-qat-module-1.0.1-r0/openssl-1.0.1/engines/qat_engine/qat_mem/Makefile
+===
+--- 
openssl-qat-module-1.0.1-r0.orig/openssl-1.0.1/engines/qat_engine/qat_mem/Makefile
 2012-10-17 13:31:27.932376960 -0700
 
openssl-qat-module-1.0.1-r0/openssl-1.0.1/engines/qat_engine/qat_mem/Makefile   
   2012-10-17 13:35:40.396389410 -0700
+@@ -9,13 +9,9 @@
+ MODULENAME:= qat_mem
+ ### should not need to change stuff below ##
+ 
+-
+-KDIR  := /lib/modules/$(shell uname -r)/build
+-#KDIR := /exports/linux-2.6.12.2/
++KDIR  := $(KERNEL_SOURCE_ROOT)
+ PWD   := $(shell pwd)
+-
+-CC:= gcc -Wall -imacros /usr/src/kernels/$(shell uname 
-r)/include/linux/autoconf.h
+-
++CC:= $(KERNEL_CC) -Wall -imacros 
$(KERNEL_SOURCE_ROOT)/include/generated/autoconf.h
+ ifeq ($(KERNELRELEASE),)
+ all:  $(MODULENAME)_test
+ all:
+@@ -23,20 +19,15 @@
+ else
+   obj-m   := $(MODULENAME).o
+ endif
+-
+ $(MODULENAME)_test: $(MODULENAME)_test.c
+   $(CC) -g -o $(MODULENAME)_test $(MODULENAME)_test.c
+-
+-
++modules_install:
++  $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules_install
+ load:
+   insmod ./$(MODULENAME).ko
+-
+ unload:
+   rmmod $(MODULENAME)
+-
+ test: all
+   ./$(MODULENAME)_test.sh
+-
+ clean:
+   rm -f *.o *.ko Modules.symvers *.mod.c .*.cmd $(MODULENAME)_test
+-
-- 
1.7.9.5

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

Re: [yocto] Requesting information on some variables

[Rifenbark, Scott M]

Rudi,

Thanks for the added investigation here.  The original bug report listed 
COMMON_FEATURES as an undocumented variable.  I see, however, that the variable 
referred to by both you and Paul Eggleton is COMBINED_FEATURES.  I just did a 
grep through my entire poky tree, which had built out the core-image-minimal 
image for the qemux86 MACHINE and came up empty for "COMMON_FEATURES" except 
where the string is part of other variables.  So, it appears there is no 
COMMON_FEATURES variable.

According to Paul, COMBINED_FEATURES is a list of features common to both 
MACHINE_FEATURES and DISTRO_FEATURES.

It also seems that the lists presented in the documentation for both valid 
distro and machine options are not really finite lists.  I am trying to get an 
answer to that.  But, the fact that you grep'ed out such a huge list of DF 
below shows that they far exceed the 16 features listed in the documentation.  
I'll update the preamble to the "Distro" and "Machine" sections in the 
reference manual when I get the real story on those lists.

I don't know the relationship between "features" and "packages"...  maybe it is 
a one-to-one relationship.  But, there are some other variables that affect 
packages and features (according to the documentation) that are considered 
during the build.  These are the ones listed in the manual's glossary section:


* MACHINE_ESSENTIAL_EXTRA_RDEPENDS

* MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS

* MACHINE_EXTRA_RDEPENDS

* MACHINE_EXTRA-RRECOMMENDS

* DISTRO_EXTRA_RRECOMMENDS

* DISTRO_FEATURES_BACKFILL

* DISTRO_FEATURES_BACKFILL_CONSIDERED

* MACHINE_FEATURES_BACKFILL

* MACHINE_FEATURES_BACKFILL_CONSIDERED

I suspect that there is a DISTRO_EXTRA_RDEPENDS variable as well but I don't 
have it in the manual (should be added if so).  Also, not sure if there are 
variables for DISTRO_ESSENTIAL_EXTRA_RDEPENDS and 
DISTRO_ESSENTIAL_EXTRA_RRECOMMENDS.  If those really exist, then I need to add 
them as well.

Finally, the BACKFILL variables also contribute to the MACHINE_FEATURES and 
DISTRO_FEATURES set.  It looks like *_FEATURES_BACKFILL, which is set in the 
bitbake.conf file, is a way to make sure a feature is always included as part 
of *_FEATURES. While *_BACKFILL_CONSIDERED is used in specific machine 
configurations (.conf) to disable a particular feature when it also 
appears with *_FEATURES_BACKFILL.   So these variables add to the mix also.

I have emails out asking questions and am trying to fully understand it myself.

Thanks,
Scott


From: rstr...@linuxfoundation.org [mailto:rstr...@linuxfoundation.org] On 
Behalf Of Rudolf Streif
Sent: Wednesday, October 17, 2012 1:16 PM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Requesting information on some variables

Scott,

Thanks for addressing this confusing part. The list of DISTRO_FEATURES (DF) and 
MACHINE_FEATURES (MF) in the documentation also does not seem to be complete. 
For instance, vfat is (at least the code in bitbake.conf that intersects DF and 
MF suggests so) is a MF as well as a DF.

It also seems that any package is fair game for DF (which makes sense) but the 
documentation says "The items below are valid options for 
DISTRO_FEATURES:".

Some elaboration on the features would be great too. From the explanation it is 
not obvious why ext2 is considered a DF as well as a MF. The same seems to be 
the case with vfat (although not listed in the documentation). Other file 
systems e.g. ext3 etc. are purely considered DF.

Here are the variables from a build environment building for the Beagleboard

bitbake core-image-minimal -e | grep MACHINE_FEATURES
MACHINE_FEATURES="apm usbgadget usbhost vfat alsa"

bitbake core-image-minimal -e | grep DISTRO_FEATURES
DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia usbgadget 
usbhost wifi xattr nfs zeroconf pci 3g x11 ipv4 ipv6 libc-backtrace 
libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt 
libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg libc-fstab 
libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm libc-libm-big 
libc-locales libc-locale-code libc-memusage libc-nis libc-nsswitch libc-rcmd 
libc-rtld-debug libc-spawn libc-streams libc-sunrpc libc-utmp libc-utmpx 
libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc 
libc-posix-wchar-io largefile opengl pulseaudio"

bitbake core-image-minimal -e | grep COMBINED_FEATURES
COMBINED_FEATURES="alsa usbgadget usbhost"

CF seems to be an intersection of DF and MF.  If I remove usbgadget from MF 
then CF will of course not contain it. DF will still have it. What actually 
does get included with the image? Is it DF - [list of all available machine 
features] + CF?

[list of all available machine features] is then the superset of MF that is 
typically d

Re: [yocto] [meta-intel][PATCH] ffmpeg: set LICENSE_FLAGS

[Tom Zanussi]

On Mon, 2012-10-15 at 11:30 +0100, Paul Eggleton wrote:
> Signed-off-by: Paul Eggleton 
> ---
>  common/recipes-multimedia/ffmpeg/ffmpeg.inc |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/common/recipes-multimedia/ffmpeg/ffmpeg.inc 
> b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
> index 96da7c2..3ce950e 100644
> --- a/common/recipes-multimedia/ffmpeg/ffmpeg.inc
> +++ b/common/recipes-multimedia/ffmpeg/ffmpeg.inc
> @@ -5,6 +5,8 @@ SECTION = "libs"
>  PRIORITY = "optional"
>  LICENSE = "GPLv2+ & LGPLv2.1+"
>  
> +LICENSE_FLAGS = "commercial"
> +
>  ARM_INSTRUCTION_SET = "arm"
>  
>  DEPENDS = "zlib libogg libvorbis libtheora liba52 libva yasm-native"

Pulled into meta-intel/master.

Thanks,

Tom

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

Re: [yocto] [PATCH] cedartrail: add missing gst-va-intel-vaapi machine feature"

[Tom Zanussi]

Does this supercede the one in the 'Cedar Trail and gst-vaapi fixes'
patchset?

Also, do you have a branch we can pull from?

Tom

On Tue, 2012-10-16 at 17:13 +0100, Ross Burton wrote:
> There needs to be a gst-va-* MACHINE_FEATURE to get the right VA elements in 
> the
> images.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta-cedartrail/conf/machine/cedartrail.conf |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-cedartrail/conf/machine/cedartrail.conf 
> b/meta-cedartrail/conf/machine/cedartrail.conf
> index 33af012..540771d 100644
> --- a/meta-cedartrail/conf/machine/cedartrail.conf
> +++ b/meta-cedartrail/conf/machine/cedartrail.conf
> @@ -7,7 +7,7 @@
>  require conf/machine/include/tune-atom.inc
>  require conf/machine/include/ia32-base.inc
>  
> -MACHINE_FEATURES += "pcbios efi"
> +MACHINE_FEATURES += "pcbios efi gst-va-video-vaapi"
>  
>  XSERVER ?= "${XSERVER_IA32_BASE} \
> ${XSERVER_IA32_EXT} \


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

Re: [yocto] [PATCH] cedartrail: add missing gst-va-intel-vaapi machine feature"

[Ross Burton]

On Wednesday, 17 October 2012 at 22:23, Tom Zanussi wrote:
> Does this supercede the one in the 'Cedar Trail and gst-vaapi fixes'
> patchset?

This patch is incorrect, the one I sent today was the correct one.  
> Also, do you have a branch we can pull from?

I do now - git.yoctoproject.org:user-contrib/ross/meta-intel, in the "cdt" 
branch.  Don't just pull the entire branch, you'll want to cherry-pick the 
commits I mailed.  There are other commits in that branch that depend on 
patches that haven't landed in oe-core yet…   

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

Re: [yocto] 1.3 RC4 full pass results

[Flanagan, Elizabeth]

On Wed, Oct 17, 2012 at 1:52 PM, Zhang, Jessica  wrote:
>
> As to sato-sdk for qemuarm issue (3290), I think Beth has regenerated it.  
> Can we have a quick check to ensure it’s working now?

Yes, this was due to us needing to regenerate qemuarm. Only the main
builder populates the adtrepo. As the images for the first run were
incorrectly generated for qemuarm, they had to be done by hand. This
was finished yesterday and the bug report updated.

-b

>
>
>
> Thanks,
>
> Jessica
>
>
>
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
> On Behalf Of Serban, Laurentiu
> Sent: Wednesday, October 17, 2012 12:48 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] 1.3 RC4 full pass results
>
>
>
>
>
> Hello guys,
>
>
>
> Here are the test results for the 1.3 RC4 full pass.
>
> The commit id is:  1b1b83651af33ffcb204031e2790719e3b0b45bb
>
>
>
> For the performance tests: the build for sato x86 took 88 minutes (same as 
> for RC3)
>
>
>
> The following issue are encountered. I also updated with comments from 
> Jessica and Saul:
>
> -  For the BSPs:
>
> o   For qemu x86_64 images – the zypper refresh fails (2694),
>
> -  For core build system:
>
> o   There are still errors with the do_rootfs fails for 
> lib64-core-image-sato-sdk (2918)
>
> -  For ADT
>
> o   ADT couldn't be installed properly for RC4 because sato sdk for qemuarm 
> does not exist (3290)
>
> o   GL support still available on qemuarm (3287)
>
>
>
>
>
>
>
> Test Result Summary
>
> Component
>
> Target
>
> Status
>
> Comments
>
> Boards
>
> p1022ds
>
> GOOD
>
> Everything runs well
>
> Beagleboard
>
> GOOD
>
> Everything runs well
>
> Routerstationpro
>
> GOOD
>
> Everything runs well
>
> Mpc8315e-rdb
>
> GOOD
>
> Sudoku-savant issue (2878)
>
> eMenlow-sato-sdk
>
> BUGGY
>
> Usb mount fails (2643)
>
> Blacksand-sato-sdk
>
> GOOD
>
> Everything runs well
>
> Sugarbay sato-sdk
>
> GOOD
>
> Everything runs well
>
> Crownbay-emgd-sato-sdk
>
> GOOD
>
> Standby fails (2792), Xorg issue (1258),
>
> FRI2-sato
>
> BUGGY
>
> Blocked (3294)
>
> HuronRiver-sato
>
> GOOD
>
> Everything runs well
>
> Jasperforest-lsb
>
> BUGGY
>
> zypper is not installed in core-image-lsb-sdk (3098)
>
> QEMU
>
>
>
>
>
>
>
> Qemuarm
>
> GOOD
>
> Everything runs well
>
> Qemuppc
>
> GOOD
>
> Everything runs well
>
> Qemumips
>
> GOOD
>
> Everything runs well
>
> qemux86
>
> GOOD
>
> Everything runs well
>
> qemux86-64
>
> BUGGY
>
> Zypper issue (2694)
>
> Core build system
>
>
>
> BUGGY
>
> lib64-core-image-sato-sdk fails due to do_rootfs issue (2918)
>
> HOB
>
>
>
> GOOD
>
> Everything runs well
>
> ADT
>
>
>
> BUGGY
>
> ADT couldn't be installed properly for RC4 because sato sdk for qemuarm does 
> not exist (3290)
>
> GL support still available on qemuarm (3287)
>
> Stress Testing
>
> GOOD
>
> Both Crashme and Helltest on Jasperforest could pass 24 hours stress testing
>
> Distribution Support
>
> GOOD
>
> Everything runs well for Ubuntu 12.04, Ubuntu 12.10 – nightly, OpenSuse 12.1, 
> OpenSuse 12.2 RC2, Fedora 17, CentOs 6.3, Fedora 16
>
> Power and Performance
>
> GOOD
>
> one qemux86 sato build on a Core i7 machine costs 88 minutes with the 
> packages previously fetched.
>
> Compliance
>
> GOOD
>
> Tests on Huron River and BlackSand passed
>
> Build Appliance
>
> GOOD
>
> Everything runs well on VMWare Player (on Ubuntu). The relevant tests were 
> performed also for qemu-kvm on Fedora 17 libvirt and
>
> VMWare Workstation.(Ubuntu)
>
>
>
>
>
> Detailed Test Result for each component
>
> Target
>
> Total TCs
>
> Not Run
>
> Passed
>
> Failed
>
> Not testable (Blocked)
>
> Beagleboard Sato-SDK
>
> 42
>
> 0
>
> 42
>
> 0
>
> 0
>
> Routerstationpro Sato-SDK
>
> 35
>
> 0
>
> 35
>
> 0
>
> 0
>
> p1022ds-sato-sdk
>
> 37
>
> 0
>
> 37
>
> 0
>
> 0
>
> Mpc8315e-rdb Sato-SDK
>
> 37
>
> 0
>
> 37
>
> 0
>
> 0
>
> eMenlow Sato-sdk
>
> 67
>
> 0
>
> 66
>
> 1 (bug 2643)
>
> 0
>
> n450 Sato-sdk
>
> 67
>
> 0
>
> 67
>
> 0
>
> 0
>
> Crownbay-Sato-sdk
>
> 65
>
> 0
>
> 62
>
> 2 (1258, 2792)
>
> 1 (2792)
>
> FRI2 Sato-sdk
>
> 85
>
> 0
>
> 0
>
> 0
>
> 85 (3294)
>
> HuronRiver Sato-sdk
>
> 68
>
> 0
>
> 68
>
> 0
>
> 0
>
> Sugarbay sato-sdk
>
> 68
>
> 0
>
> 68
>
> 0
>
> 0
>
> Jasperforest lsb-sdk
>
> 34
>
> 0
>
> 27
>
> 7 (3098)
>
> 0
>
> Qemuarm Sato
>
> 31
>
> 0
>
> 31
>
> 0
>
> 0
>
> Qemuarm Sato-SDK
>
> 36
>
> 0
>
> 36
>
> 0
>
> 0
>
> Qemumips Sato
>
> 31
>
> 0
>
> 31
>
> 0
>
> 0
>
> Qemumips Sato-SDK
>
> 36
>
> 0
>
> 36
>
> 0
>
> 0
>
> Qemuppc Sato
>
> 31
>
> 0
>
> 31
>
> 0
>
> 0
>
> Qemuppc Sato-SDK
>
> 36
>
> 0
>
> 36
>
> 0
>
> 0
>
> Qemux86-64 Sato
>
> 30
>
> 0
>
> 27
>
> 3 (bug 2694)
>
> 0
>
> Qemux86-64 Sato-SDK
>
> 36
>
> 0
>
> 32
>
> 4 (bug 2694)
>
> 0
>
> Qemux86 Sato
>
> 30
>
> 0
>
> 30
>
> 0
>
> 0
>
> Qemux86 Sato-SDK
>
> 36
>
> 0
>
> 36
>
> 0
>
> 0
>
> Core build system
>
> 59
>
> 0
>
> 57
>
> 2 (2918)
>
> 0
>
> HOB
>
> 38
>
> 0
>
> 38
>
> 0
>
> 0
>
> ADT
>
> 52
>
> 0
>
> 45
>
> 7(3290, 3287)
>
> 0
>
> Build Appliance
>
> 42
>

Re: [yocto] Tune qemuarm settings and build everything except the kernel?

[Evade Flow]

Hi, again---I thought we were switching h/w platforms, but it turns out
we'll be sticking with this system for a bit longer.

> I am guessing its some sort of Tegra CPU which had FPU but no neon
> unit...

Right, it's a Tegra 2 T20, which lacks the NEON extension.

> we dont have default tunes available readily that are good for tegra
> but its not hard to create one

Erm. :-% I guess 'hard' is relative. Could you provide an extra hint
about this? Do you mean I should make a copy of 'tune-cortexa9.inc' and
change DEFAULTTUNE from 'cortexa9-neon' to 'cortexa9'? Or, is there a
way to include the existing file and override the default?

Also, I'm not sure what do to with the 'VFP Tunes'. I found this thread

  - 
http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg09497.html

which seems to talk about some of these issues. I think I need to add
'-mfpu=vfpv3-d16' to the compiler flags, but, as this is the first
'real' thing I've tried to do with bitbake, I'm unsure how to accomplish
this...



On Fri, Aug 31, 2012 at 7:00 PM, Khem Raj  wrote:
> Hi Evade,
>
> Glad it worked for you at first go. Thats quite an achievement for yocto
>
> On Fri, Aug 31, 2012 at 2:58 PM, Evade Flow  wrote:
>>
>> Now I'm wondering: is there any easy way to optimize for the actual
>> target(s) a bit more than the qemuarm MACHINE type does?  The example
>> Makefiles for the old project all contain this line:
>>
>>CFLAGS = -g -mcpu=arm1136jf-s -O2 -pipe
>>
>> What's the best way to arrange for that '-mcpu' option to be used by all
>> recipes? Also, are there other optimizations I should consider?  I'm
>> appending some details about the board in question, as well as the
>> complete output from booting it to a prompt. I'd be ever so grateful if
>> someone could recommend sensible base settings for this system, and
>> explain how to create a Poky 'layer', or 'machine'---or whatever the
>> right nomenclature is---to apply these settings.
>>
>> Sorry for the long post, and thanks in advance for any advice!
>>
>>
>> --
>>
>> ~ # uname -a
>> Linux localhost 2.6.36.2-WR3.0.2ax_standard #1 SMP PREEMPT Wed Oct 19 
>> 21:58:54
>> EEST 2011 armv7l armv7l armv7l GNU/Linux ODBP D1.0.1 (10.11.2011)
>>
>> ~ # cat /proc/cpuinfo
>> Processor   : ARMv7 Processor rev 0 (v7l)
>> processor   : 0
>> BogoMIPS: 1795.68
>>
>> Features: swp half thumb fastmult vfp edsp vfpv3 vfpv3d16
>
>
> I am guessing its some sort of Tegra CPU which had FPU but no neon unit
> there is rich set of tuning available for arm.
>
> So you would create  configuration file for your machine. May be just
> start by making a copy of
> qemuarm.conf
>
> then you would select the right tuning
>
> require conf/machine/include/tune-arm926ejs.inc currently select arm926
> you might want something more appropriate.
>
> add
> conf/machine/include/tune-arm1136jf-s.inc
>
> this will get to what you had in old project
>
> and you can also go a step further and make it more appropriate for
> tegra cpu that you have
> we dont have default tunes available readily that are good for tegra
> but its not hard to create one
>
> Look at
>
> e.g on tune-cortexa9.inc
>
> you would create something similar for your cpu and then select proper
> default tunings.
>
> Have fun
>
> -Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cedar Trail and gst-vaapi fixes

[Bodke, Kishore K]

>-Original Message-
>From: Ross Burton [mailto:ross.bur...@intel.com]
>Sent: Wednesday, October 17, 2012 8:21 AM
>To: Bodke, Kishore K; Kamble, Nitin A; dvh...@linux.intel.com
>Cc: yocto@yoctoproject.org
>Subject: Cedar Trail and gst-vaapi fixes
>
>Hi,
>
>Make gst-vaapi work on Cedar Trail, upgrade the gst-vaapi to the latest
>version
>which doesn't need ffmpeg anymore, and remove the commercial restriction
>on
>gst-vaapi.
>
>The new gst-vaapi was tested on Cedar Trail, and played the Sintel 720p trailer
>smoothly.  ffmpeg was required for the audio (MPEG4 AAC), but without that
>present the video still plays.

Hi,

Wanted to check if you had a chance to look into the cpu uitilization?
We had less than 15% cpu uitilization, with the acceleration while playing the 
video.

Thanks
Kishore.
>
>Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/3][meta-intel]meta-cedartrail: Update README, Fix Package Rename issue & Add dev headers

[rahul . saxena]

From: Rahul Saxena 

This patch series does the following:
-- Update README with product name and state Gfx acceleration support
-- Fix package naming issue: Yocto bugzilla  bug  #3286. 
-- Add development headers in  pvr driver recipe

Pl pull into master branch

Thanks
Rahul
--
The following changes since commit 5164713bfbef16e1a49bc599ec0d738df52ab254:

  meta-crystalforest: Update SRCREV for meta. (2012-10-15 14:38:40 -0500)

are available in the git repository at:
  git://git.pokylinux.org/meta-intel-contrib master16oct-rsaxena
  
http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=master16oct-rsaxena

Rahul Saxena (3):
  meta-cedartrail: Update README with product name and state Gfx
acceleration support
  meta-cedartrail: Fix package naming issue
  meta-cedartrail: Add development packages to pvr driver recipe

 meta-cedartrail/README |7 
 .../xorg-driver/cdv-pvr-driver_1.0.3.bb|   39 +++-
 2 files changed, 45 insertions(+), 1 deletions(-)

-- 
1.7.4.1

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

[yocto] [PATCH 1/3] meta-cedartrail: Update README with product name and state Gfx acceleration support

[rahul . saxena]

From: Rahul Saxena 

Add CPU and Chipset product names. Explicitly state support for Gfx & Media
acceleration.

Signed-off-by: Rahul Saxena 
---
 meta-cedartrail/README |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/meta-cedartrail/README b/meta-cedartrail/README
index 81a1260..bd00d19 100755
--- a/meta-cedartrail/README
+++ b/meta-cedartrail/README
@@ -2,6 +2,13 @@ This README file contains information on building the 
meta-cedartrail
 BSP layer, and booting the images contained in the /binary directory.
 Please see the corresponding sections below for details.
 
+The 'Cedar Trail' platform consists of the Cedarview (Intel® Atom™
+N2600, N2800 and D2550) processor, plus the Tiger Point
+(Intel® NM10 Express) Chipset. 
+
+It also supports on-chip SGX545 graphics and media accelerator
+via the Cedar Trail Power VR (PVR) graphics driver.
+
 Dependencies
 
 
-- 
1.7.4.1

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

[yocto] [PATCH 2/3] meta-cedartrail: Fix package naming issue

[rahul . saxena]

From: Rahul Saxena 

cdv-pvr-driver was generating rpm packages with name "libwsbm"
This name can potentialy clash with other package names.
Fix this problem by specifying package names in the recipe with the
PKG_ vars
This fixes bug: [YOCTO #3286]

Signed-off-by: Rahul Saxena 
---
 .../xorg-driver/cdv-pvr-driver_1.0.3.bb|8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git 
a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb 
b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
index cd3407c..2f44649 100644
--- a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
+++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = " \
 
 DEPENDS = "rpm-native libva"
 
-PR = "r2"
+PR = "r3"
 
 PSB-VIDEO = "psb-video-cdv-1.0.3-1.1.i586.rpm"
 PSB-VIDEO-REV = "1.0.3"
@@ -44,6 +44,12 @@ SRC_URI[psbrpm.sha256sum] = 
"0861d69b44d5ce29a3f778ac82976a22f7726af84d9b2e5438c
 SRC_URI[wsbmrpm.md5sum] = "b8b21ca8325abd7850d197f9bf3071c7"
 SRC_URI[wsbmrpm.sha256sum] = 
"f436386967c1adec5211e662251bd542bbe0b8cd55e1d9f9c203da5ee934d4f0"
 
+# make sure generated rpm packages get non conflicting names
+PKG_${PN} = "cdv-pvr-driver"
+PKG_${PN}-dev = "cdv-pvr-driver-dev"
+PKG_${PN}-dbg = "cdv-pvr-driver-dbg"
+PKG_${PN}-doc = "cdv-pvr-driver-doc"
+
 S  = "${WORKDIR}/cdv-graphics-drivers_${PV}"
 
 # These are closed binaries generated elsewhere so don't check ldflags
-- 
1.7.4.1

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

[yocto] [PATCH 3/3] meta-cedartrail: Add development packages to pvr driver recipe

[rahul . saxena]

From: Rahul Saxena 

Add header files from development packages

Signed-off-by: Rahul Saxena 
---
 .../xorg-driver/cdv-pvr-driver_1.0.3.bb|   33 +++-
 1 files changed, 32 insertions(+), 1 deletions(-)

diff --git 
a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb 
b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
index 2f44649..e9d4ede 100644
--- a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
+++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.3.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = " \
 
 DEPENDS = "rpm-native libva"
 
-PR = "r3"
+PR = "r4"
 
 PSB-VIDEO = "psb-video-cdv-1.0.3-1.1.i586.rpm"
 PSB-VIDEO-REV = "1.0.3"
@@ -23,8 +23,10 @@ PVR-BIN = "pvr-bin-cdv-1.0.3-1.1.i586.rpm"
 PVR-BIN-REV = "1.7.862890"
 PVR-BIN-REV_N = "1.7.862890_05"
 PVR-BIN-REV_LIC = "1.0.3"
+PVR-BIN-DEV = "pvr-bin-cdv-devel-1.0.3-1.1.i586.rpm"
 
 LIBWSBM = "libwsbm-cdv-1.1.0-3.1.i586.rpm"
+LIBWSBM-DEV = "libwsbm-cdv-devel-1.1.0-3.1.i586.rpm"
 
 
 NON-OSS-PATH = 
"http://repo.meego.com/MeeGo/updates/1.2.0/repos/non-oss/ia32/packages/";
@@ -33,17 +35,26 @@ OSS-PATH = 
"http://repo.meego.com/MeeGo/updates/1.2.0/repos/oss/ia32/package
 
 SRC_URI = "${NON-OSS-PATH}${PSB-VIDEO};name=psbrpm;unpack=0 \
   ${NON-OSS-PATH}${PVR-BIN};name=pvrrpm;unpack=0 \
+  ${NON-OSS-PATH}${PVR-BIN-DEV};name=pvrrpmdev;unpack=0 \
   ${OSS-PATH}${LIBWSBM};name=wsbmrpm;unpack=0 \
+  ${OSS-PATH}${LIBWSBM-DEV};name=wsbmrpmdev;unpack=0 \
"
 SRC_URI[pvrrpm.md5sum] = "3ae7db98825af642445f75f4b5ddb303"
 SRC_URI[pvrrpm.sha256sum] = 
"42b97e5d663444f35b1ee51cdf9573e3b1d5a4f49ae854218c5c4c9a66ba95cf"
 
+SRC_URI[pvrrpmdev.md5sum] = "e8f0815b5bbf94311a7cf229451f651f"
+SRC_URI[pvrrpmdev.sha256sum] = 
"facb67f6b8413504e7ba570a4e3e3ee20cb90d7bd02b303653f9ce5cc4fd7b20"
+
 SRC_URI[psbrpm.md5sum] =  "ec486193dc4b3f91bc7c5e18d9ca9d8a"
 SRC_URI[psbrpm.sha256sum] = 
"0861d69b44d5ce29a3f778ac82976a22f7726af84d9b2e5438c18da5263ffdac"
 
 SRC_URI[wsbmrpm.md5sum] = "b8b21ca8325abd7850d197f9bf3071c7"
 SRC_URI[wsbmrpm.sha256sum] = 
"f436386967c1adec5211e662251bd542bbe0b8cd55e1d9f9c203da5ee934d4f0"
 
+SRC_URI[wsbmrpmdev.md5sum] = "895d0cafd878fcbe4e2f845b8e09eea3"
+SRC_URI[wsbmrpmdev.sha256sum] = 
"605ba605a2617ee67863d5becac114ce7f4ea440854543f75465e16f463bad70"
+
+
 # make sure generated rpm packages get non conflicting names
 PKG_${PN} = "cdv-pvr-driver"
 PKG_${PN}-dev = "cdv-pvr-driver-dev"
@@ -149,6 +160,26 @@ do_install() {
install -d -m 0755 ${D}${datadir}/doc/psb-video-cdv-${PSB-VIDEO-REV}
install -d -m 0755 ${D}${datadir}/doc/pvr-bin-cdv-${PVR-BIN-REV_N}
 
+rpm2cpio.sh  ${S}/${PVR-BIN-DEV}  | cpio -id
+   install -d -m 0644 ${D}${includedir}
+   install -d -m 0644 ${D}${includedir}/GLES
+   install -d -m 0644 ${D}${includedir}/VG
+   install -d -m 0644 ${D}${includedir}/GLES2
+   install -d -m 0644 ${D}${includedir}/KHR
+   install -d -m 0644 ${D}${includedir}/EGL
+
+install -m 0644 ${S}/${includedir}/GLES/*.h
${D}${includedir}/GLES
+install -m 0644 ${S}/${includedir}/VG/*.h  
${D}${includedir}/VG
+install -m 0644 ${S}/${includedir}/GLES2/*.h   
${D}${includedir}/GLES2
+install -m 0644 ${S}/${includedir}/KHR/*.h 
${D}${includedir}/KHR
+install -m 0644 ${S}/${includedir}/EGL/*.h 
${D}${includedir}/EGL
+
+   rpm2cpio.sh ${S}/${LIBWSBM-DEV} | cpio -id
+   install -d -m 0644 ${D}${includedir}/wsbm
+
+install -m 0644 ${S}/${includedir}/wsbm/*.h
${D}${includedir}/wsbm
+install -m 0644 ${S}/${libdir}/libwsbm.so  
${D}${libdir}/libwsbm.so
+
install -m 0755 
${S}/usr/share/doc/psb-video-cdv-${PSB-VIDEO-REV}/license.txt 
${D}${datadir}/doc/psb-video-cdv-${PSB-VIDEO-REV}/license.txt
 
 }
-- 
1.7.4.1

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