Signed-off-by: Zhenhua Luo <b19537@...>
---
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

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

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

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-bounces@... [yocto-bounces@...] on behalf of Jonathan Haws [Jonathan.Haws@...]
Sent: Tuesday, October 16, 2012 9:32 PM
To: yocto@...
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@...
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

--
Mihai Lindner

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-bounces@... [yocto-bounces@...] on behalf of Jonathan Haws [Jonathan.Haws@...]
Sent: Tuesday, October 16, 2012 9:32 PM
To: yocto@...
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.

Thanks,
Jonathan

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

Hi,

diff --git a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
new file mode 100644
index 0000000..6bfa968
--- /dev/null
+++ b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
@@ -0,0 +1,24 @@
+
+# The emgd binary driver also provides egl, gles1, gles2 library &

headers.

+# To avoid conflict disable egl, gles1, gles2 from meta-dri if the
+BSP image # is bundling the emgd driver.
+
+python __anonymous () {
+ import re
+ xserver = d.getVar('XSERVER', True)
+ if 'emgd-driver-bin' in xserver.split(' '):
+ extra_oeconf = d.getVar('EXTRA_OECONF', True).split()
+ take_out = ["--enable-egl", "--enable-gles1", "--enable-gles2"]
+ put_in = ["--disable-egl", "--disable-gles1", "--disable-gles2"]
+ pattern = re.compile("--with-egl-platforms")
+ new_extra_oeconf = [ ]
+ for i in extra_oeconf:
+ if ( i not in take_out ) and ( not pattern.match(i)):
+ new_extra_oeconf.append(i)
+ for i in put_in:
+ new_extra_oeconf.append(i)
+
+ d.setVar('EXTRA_OECONF', ' '.join(new_extra_oeconf))
+ depends = d.getVar('DEPENDS', True)
+ d.setVar('DEPENDS', depends + " emgd-driver-bin")

Odd mix of whitespace and tabs above.

Also, I have to agree with Ross. This places very specific knowledge
of an external package in the general purpose recipe. This is
opposite of how these things should be built up.

Whitespace issues can be solved easily. But if this solution is not

acceptable, then I am not sure how to solve the issue. Do we push the issue
to 1.4?

Can you define a variable that EXTRA_OECONF includes which can be
manipulated in a bbappend in the meta-intel? This would keep this complex
logic out of the core recipe and move into the place that actually needs it.

If we can modify the recipe in poky, then this method is not needed to achieve same thing. But because of release we may not be able to do it.

Nitin

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

On 10/16/2012 03:17 PM, Kamble, Nitin A wrote:

-----Original Message-----
From: Hart, Darren
Sent: Monday, October 15, 2012 9:10 AM
To: Kamble, Nitin A
Cc: Zanussi, Tom; yocto@...
Subject: Re: [PATCHv4 6/8] mesa-dri.bbappend: avoid conflict with emgd-
driver-bin

On 10/11/2012 04:31 PM, nitin.a.kamble@... wrote:

From: Nitin A Kamble <nitin.a.kamble@...>

Extend the mesa-dri recipe from oecore to avoid conflict with files
generated by emgd-driver-bin recipe.

This extention is needed only when emgd-driver-bin recipe is included
in the target image, so the code is conditional to run only on the
machine with emgd graphics driver.

The emgd binary driver also provides egl, gles1, gles2 library & headers.
To avoid conflict disable egl, gles1, gles2 from meta-dri if the BSP
image is bundling the emgd driver.

This commits avoids these build warning

WARNING: The recipe is trying to install files into a shared area when those

files already exist. Those files are:

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/KHR/khrplatform.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/EGL/eglplatform.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/EGL/eglext.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/EGL/egl.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/GLES/glplatform.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/GLES/gl.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/GLES/glext.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2ext.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/usr/include/GLES2/gl2.h

/srv/home/nitin/build-test-bsps/build-

crownbay/tmp/sysroots/crownbay/u

sr/include/GLES2/gl2platform.h

This resolves part of the issue reported on the bug:
[Yocto #3238]

Signed-off-by: Nitin A Kamble <nitin.a.kamble@...>
---
.../recipes-graphics/mesa/mesa-dri_8.0.4.bbappend | 24

++++++++++++++++++++

1 files changed, 24 insertions(+), 0 deletions(-) create mode 100644
common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend

diff --git a/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
new file mode 100644
index 0000000..6bfa968
--- /dev/null
+++ b/common/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
@@ -0,0 +1,24 @@
+
+# The emgd binary driver also provides egl, gles1, gles2 library & headers.
+# To avoid conflict disable egl, gles1, gles2 from meta-dri if the
+BSP image # is bundling the emgd driver.
+
+python __anonymous () {
+ import re
+ xserver = d.getVar('XSERVER', True)
+ if 'emgd-driver-bin' in xserver.split(' '):
+ extra_oeconf = d.getVar('EXTRA_OECONF', True).split()
+ take_out = ["--enable-egl", "--enable-gles1", "--enable-gles2"]
+ put_in = ["--disable-egl", "--disable-gles1", "--disable-gles2"]
+ pattern = re.compile("--with-egl-platforms")
+ new_extra_oeconf = [ ]
+ for i in extra_oeconf:
+ if ( i not in take_out ) and ( not pattern.match(i)):
+ new_extra_oeconf.append(i)
+ for i in put_in:
+ new_extra_oeconf.append(i)
+
+ d.setVar('EXTRA_OECONF', ' '.join(new_extra_oeconf))
+ depends = d.getVar('DEPENDS', True)
+ d.setVar('DEPENDS', depends + " emgd-driver-bin")

Odd mix of whitespace and tabs above.

Also, I have to agree with Ross. This places very specific knowledge of an
external package in the general purpose recipe. This is opposite of how these
things should be built up.

Whitespace issues can be solved easily. But if this solution is not acceptable, then I am not sure how to solve the issue. Do we push the issue to 1.4?

Can you define a variable that EXTRA_OECONF includes which can be
manipulated in a bbappend in the meta-intel? This would keep this
complex logic out of the core recipe and move into the place that
actually needs it.

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

Hi,

From: Kishore Bodke <kishore.k.bodke@...>

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

Signed-off-by: Kishore Bodke <kishore.k.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..689377f 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 \
+ zlib-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..8b5e0f6 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 \
+ zlib-qat-module \
"

LICENSE = "MIT"
--
1.7.9.5

From: Kishore Bodke <kishore.k.bodke@...>

This adds a new recipe to build the Intel Quick Assist
Technology Memory Management Module for Zlib.

Signed-off-by: Kishore Bodke <kishore.k.bodke@...>
---
.../zlib-qat-module/zlib-qat-module.bb | 65 ++++++++++++++++++++
.../zlib-qat-module/zlib_qat_module.patch | 43 +++++++++++++
2 files changed, 108 insertions(+)
create mode 100644 common/recipes-core/zlib-qat-module/zlib-qat-module.bb
create mode 100644 common/recipes-core/zlib-qat-module/zlib-qat-module/zlib_qat_module.patch

diff --git a/common/recipes-core/zlib-qat-module/zlib-qat-module.bb b/common/recipes-core/zlib-qat-module/zlib-qat-module.bb
new file mode 100644
index 0000000..63eff03
--- /dev/null
+++ b/common/recipes-core/zlib-qat-module/zlib-qat-module.bb
@@ -0,0 +1,65 @@
+SUMMARY = "Zlib QAT_MEM Memory Management Module for Intel Quick Assist Technology"
+DESCRIPTION = "This software acelerates the data compression algorithm in the zlib \
+ software library via the Intel QuickAssist Technology implemented on \
+ Intel Communications Chipset 89xx Series based platforms."
+
+HOMEPAGE = "http://zlib.net/"
+SECTION = "libs"
+LICENSE = "Zlib & GPLv2 & BSD"
+
+LIC_FILES_CHKSUM = "file://${WORKDIR}/zlib-${PV}/zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9 \
+ file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6 \
+ file://${COMMON_LICENSE_DIR}/BSD;md5=3775480a712fc46a69647678acb234cb \
+ "
+
+PV = "1.2.7"
+ZLIB_QAT_VERSION = "0.4.0-011"
+
+PR="r0"
+
+SRC_URI = " \
+ http://www.zlib.net/zlib-${PV}.tar.gz;name=zlib \
+ http://downloadmirror.intel.com/20294/eng/zlib-1.2.7-qat.L.${ZLIB_QAT_VERSION}.tar.gz;name=zlib_qat \
+ file://zlib_qat_module.patch \
+ "
+
+SRC_URI[zlib.md5sum]="60df6a37c56e7c1366cca812414f7b85"
+SRC_URI[zlib.sha256sum]="fa9c9c8638efb8cb8ef5e4dd5453e455751e1c530b1595eed466e1be9b7e26c5"
+
+SRC_URI[zlib_qat.md5sum]="88e4140f98d2f9e170bf473f20e1a8d4"
+SRC_URI[zlib_qat.sha256sum]="3c360878127f3930e64640ef5a5822719a5059143326bb4c396645ae37b704a6"
+
+TARGET_CFLAGS += "-I ${S}/contrib/qat/ -I ${S}"
+
+S = "${WORKDIR}/zlib-${PV}/contrib/qat/qat_mem"
+
+inherit module
+
+export KERNEL_SOURCE_ROOT = "${STAGING_KERNEL_DIR}"
+
+do_patch() {
+
+ cd ${WORKDIR}/zlib-${PV}
+ patch -p0 < ${WORKDIR}/zlib-${PV}-qat.L.${ZLIB_QAT_VERSION}.patch
+
+ cd ${WORKDIR}
+ patch -p1 < ${WORKDIR}/zlib_qat_module.patch
+}
+
+do_compile() {
+
+ cd ${S}
+ oe_runmake KERNEL_CC="${KERNEL_CC}"
+
+}
+
+do_install_append() {
+
+ install -m 0755 -d ${D}${bindir}
+ install -m 0755 ${S}/qat_mem_test ${D}${bindir}
+
+}
+
+FILES_${PN} += " \
+ ${bindir}/qat_mem_test \
+ "
diff --git a/common/recipes-core/zlib-qat-module/zlib-qat-module/zlib_qat_module.patch b/common/recipes-core/zlib-qat-module/zlib-qat-module/zlib_qat_module.patch
new file mode 100644
index 0000000..a30f8b0
--- /dev/null
+++ b/common/recipes-core/zlib-qat-module/zlib-qat-module/zlib_qat_module.patch
@@ -0,0 +1,43 @@
+Index: zlib-qat-module-1.2.7-r0/zlib-1.2.7/contrib/qat/qat_mem/Makefile
+===================================================================
+--- zlib-qat-module-1.2.7-r0.orig/zlib-1.2.7/contrib/qat/qat_mem/Makefile 2012-10-16 13:53:10.258938722 -0700
++++ zlib-qat-module-1.2.7-r0/zlib-1.2.7/contrib/qat/qat_mem/Makefile 2012-10-16 13:59:18.174944864 -0700
+@@ -59,13 +59,10 @@
+ #
+ #
+ #########################################################################
+-
+ MODULENAME := qat_mem
+-KDIR := /lib/modules/$(shell uname -r)/build
++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:
+@@ -73,20 +70,15 @@
+ else
+ obj-m := $(MODULENAME).o
+ endif
+-
++modules_install:
++ $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules_install
+ $(MODULENAME)_test: $(MODULENAME)_test.c
+ $(CC) -g -o $(MODULENAME)_test $(MODULENAME)_test.c
+-
+-
+ load:
+ insmod ./$(MODULENAME).ko
+-
+ unload:
+ rmmod $(MODULENAME)
+-
+ test: all
+ ./$(MODULENAME)_test
+-
+ clean:
+ rm -f *.o *.ko Module.symvers modules.order *.mod.c .*.cmd $(MODULENAME)_test
+-
--
1.7.9.5

From: Kishore Bodke <kishore.k.bodke@...>

Hi,

This patch set adds a new recipe for Intel Quick Assist Technology
Memory Management Module based on Zlib and include it to the custom
build Image recipe to build them.

Please pull into meta-intel/master.

Thanks
Kishore.

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 Kishore/Zlib-qat_mem
http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=Kishore/Zlib-qat_mem

Kishore Bodke (2):
meta-intel/common: Add a new recipe for Zlib qat_mem Module.
meta-crystalforest: Add zlib-qat-module to the Image.

.../zlib-qat-module/zlib-qat-module.bb | 65 ++++++++++++++++++++
.../zlib-qat-module/zlib_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, 110 insertions(+)
create mode 100644 common/recipes-core/zlib-qat-module/zlib-qat-module.bb
create mode 100644 common/recipes-core/zlib-qat-module/zlib-qat-module/zlib_qat_module.patch

--
1.7.9.5

Jonathan Haws <Jonathan.Haws@...> writes:

I got the oe-classic recipe building with the latest version of
lm-sensors. However, I am now running into perl issues - when I try
to run sensors-detect, I get errors with the @INC paths - strict.pm is
not found anywhere on the filesystem. I went back to see if I had
left out perl support, but it was present and included. Where is
strict.pm? How can I get that in my image?

Thanks!

You might want to add 'perl-modules' to RDEPENDS_lmsensors-scripts.

Marc

Paul Eggleton <paul.eggleton@...> writes:

On Tuesday 16 October 2012 16:00:01 Jonathan Haws wrote:

I would be surprised if a recipe for lm-sensors has not already been
created, however I cannot find one. Can someone point me in the right
direction?

All I can find is a sysstat package that I can include via
IMAGE_INSTALL_append, however I cannot see how I can get the same
information out of it that lm-sensors gives me.

Has anyone got lm-sensors included in their image? If so, can you share the
recipe?

Unless anyone else pipes up, my local index suggests that this is something
that hasn't yet been brought up-to-date from OE-Classic.

http://git.openembedded.org/openembedded/tree/recipes/lm_sensors

Assuming nothing else is available you should be able to use this as a base.
There is a brief guide on the main things that need to be changed when
updating a recipe from OE-Classic here:

http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core

If you do come up with an updated recipe we'd love to have it added to meta-oe
or some other layer ;)

Paul,

In what section should the lmsensors recipe be added? Would 'recipe-bsp'
be ok?

Regards,

Marc

I got the oe-classic recipe building with the latest version of lm-sensors. However, I am now running into perl issues - when I try to run sensors-detect, I get errors with the @INC paths - strict.pm is not found anywhere on the filesystem. I went back to see if I had left out perl support, but it was present and included. Where is strict.pm? How can I get that in my image?

Thanks!

FYI, here is what the recipe looks like. It still gives a man page warning, but I am ignoring that for now.

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

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

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

FILES_lmsensors-sensors = "${bindir}/sensors ${sysconfdir}"
FILES_lmsensors-sensors-dbg += "${bindir}/.debug/sensors"
------------------------------------------------------------------------------------------------------------------------------------------------------------
________________________________________
From: yocto-bounces@... [yocto-bounces@...] on behalf of Marc Ferland [ferlandm@...]
Sent: Tuesday, October 16, 2012 11:37
To: yocto@...
Subject: Re: [yocto] lm-sensors not available as a package?

Paul Eggleton <paul.eggleton@...> writes:

On Tuesday 16 October 2012 16:00:01 Jonathan Haws wrote:

I would be surprised if a recipe for lm-sensors has not already been
created, however I cannot find one. Can someone point me in the right
direction?

All I can find is a sysstat package that I can include via
IMAGE_INSTALL_append, however I cannot see how I can get the same
information out of it that lm-sensors gives me.

Has anyone got lm-sensors included in their image? If so, can you share the
recipe?

Unless anyone else pipes up, my local index suggests that this is something
that hasn't yet been brought up-to-date from OE-Classic.

http://git.openembedded.org/openembedded/tree/recipes/lm_sensors

Assuming nothing else is available you should be able to use this as a base.
There is a brief guide on the main things that need to be changed when
updating a recipe from OE-Classic here:

http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core

If you do come up with an updated recipe we'd love to have it added to meta-oe
or some other layer ;)

I have a lmsensors recipe somewhere around here. I'll dust it off and
post it to the oe-core mailing list.

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

Paul Eggleton <paul.eggleton@...> writes:

On Tuesday 16 October 2012 16:00:01 Jonathan Haws wrote:

I would be surprised if a recipe for lm-sensors has not already been
created, however I cannot find one. Can someone point me in the right
direction?

All I can find is a sysstat package that I can include via
IMAGE_INSTALL_append, however I cannot see how I can get the same
information out of it that lm-sensors gives me.

Has anyone got lm-sensors included in their image? If so, can you share the
recipe?

Unless anyone else pipes up, my local index suggests that this is something
that hasn't yet been brought up-to-date from OE-Classic.

http://git.openembedded.org/openembedded/tree/recipes/lm_sensors

Assuming nothing else is available you should be able to use this as a base.
There is a brief guide on the main things that need to be changed when
updating a recipe from OE-Classic here:

http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core

If you do come up with an updated recipe we'd love to have it added to meta-oe
or some other layer ;)

I have a lmsensors recipe somewhere around here. I'll dust it off and
post it to the oe-core mailing list.

Marc

Is there a way to clone yocto repositories (say, poky) over https?

As Paul mentioned, there is work in progress to make it possible to clone
yocto repos over http. This should be finished in the very near future, but in
the meantime, I've created some (very) unofficial mirrors here:

http://github.com/yoctoproject-mirrors

I have a script running that syncs all of these every 15 minutes or so.
Perhaps this will help you until the official HTTP access is available. (Just
be advised: I plan to delete these mirrors when they are no longer
necessary...)


On Tue, Oct 16, 2012 at 6:50 AM, Paul Eggleton
<paul.eggleton@...> wrote:

On Friday 11 May 2012 09:35:30 Chin Huat Ang wrote:

Is there a way to clone yocto repositories (say, poky) over https?

I'm behind a firewall where git port is blocked, getting it opened is a
bureaucracy nightmare.

Sorry, it's taken us a while to look into this but we have opened a bug to
track it - you may wish to add yourself to the CC list:

http://bugzilla.yoctoproject.org/show_bug.cgi?id=3263

Cheers,
Paul

--

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

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

Signed-off-by: Ross Burton <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} \
--
1.7.10

On Tuesday 16 October 2012 16:00:01 Jonathan Haws wrote:

I would be surprised if a recipe for lm-sensors has not already been
created, however I cannot find one. Can someone point me in the right
direction?

All I can find is a sysstat package that I can include via
IMAGE_INSTALL_append, however I cannot see how I can get the same
information out of it that lm-sensors gives me.

Has anyone got lm-sensors included in their image? If so, can you share the
recipe?

Unless anyone else pipes up, my local index suggests that this is something
that hasn't yet been brought up-to-date from OE-Classic.

http://git.openembedded.org/openembedded/tree/recipes/lm_sensors

Assuming nothing else is available you should be able to use this as a base.
There is a brief guide on the main things that need to be changed when
updating a recipe from OE-Classic here:

http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core

If you do come up with an updated recipe we'd love to have it added to meta-oe
or some other layer ;)

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre