[yocto] Trouble creating new package
Good morning everyone,
I am currently having issues creating a (very!) simple package. I have
looked at the latest reference manual and studied other .bb files to no
avail.
I am trying to build a simple web server called Hiawatha. To install
(http://www.hiawatha-webserver.org/howto/compilation_and_installation)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this behaviour in a .bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org;
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
SECTION = custom
PR = r0
SRC_URI = http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I feel this should be an
extremely easy piece of software to build - I think I'm just not
understanding the build system correctly
The error I receive when trying to build this package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/temp/log.do_install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
Thanks in advance,
Jack.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble creating new package
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell wrote:
Good morning everyone,
I am currently having issues creating a (very!) simple package. I have
looked at the latest reference manual and studied other .bb files to no
avail.
I am trying to build a simple web server called Hiawatha. To install
(http://www.hiawatha-webserver.org/howto/compilation_and_installation)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this behaviour in a .bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org;
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
SECTION = custom
PR = r0
SRC_URI = http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I feel this should be an
extremely easy piece of software to build - I think I'm just not
understanding the build system correctly
The error I receive when trying to build this package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/temp/log.do_install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't understand why
autotools should be inherited if it is only a make/configure combination
being used?
Best Regards
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding what's in an image
On 2012-01-09 17:51, James Abernathy wrote: I'm trying to understand how bitbake parses the poky directory tree a little better. The best I can figure all .bb files are NOT included. Just some of them are. I'm guessing that the .bb in the meta/recipe-sato named core-image-sato.bb is the one that is used to start the parsing if bitbake core-image-sato is executed. I originally thought all subdirectories of a path included in BBLAYER were parsed looking for .bb files, but now I know that is not true, but not sure why. For example, it does not appear that webkit is included in the core-image-sato even though the recipe-sato directory includes the webkit subdirectory with it's recipe. What would be the proper way of adding the webkit to core-image-sato?? The 'webkit' is just a library used to build tools such as a web browser. You might want to start with an application that actually uses webkit, such as web-webkit. To build an image which includes web-webkit, add this line to your local.conf file and rebuild the image: IMAGE_INSTALL += web-webkit You can also build packages which are not installed into your image by default and use a package manager (e.g. zypper) to install the package later onto a running system. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding what's in an image
On Jan 10, 2012, at 7:03 AM, Gary Thomas wrote: On 2012-01-09 17:51, James Abernathy wrote: I'm trying to understand how bitbake parses the poky directory tree a little better. The best I can figure all .bb files are NOT included. Just some of them are. I'm guessing that the .bb in the meta/recipe-sato named core-image-sato.bb is the one that is used to start the parsing if bitbake core-image-sato is executed. I originally thought all subdirectories of a path included in BBLAYER were parsed looking for .bb files, but now I know that is not true, but not sure why. For example, it does not appear that webkit is included in the core-image-sato even though the recipe-sato directory includes the webkit subdirectory with it's recipe. What would be the proper way of adding the webkit to core-image-sato?? The 'webkit' is just a library used to build tools such as a web browser. You might want to start with an application that actually uses webkit, such as web-webkit. To build an image which includes web-webkit, add this line to your local.conf file and rebuild the image: IMAGE_INSTALL += web-webkit You can also build packages which are not installed into your image by default and use a package manager (e.g. zypper) to install the package later onto a running system. This was very helpful. Before I got your email, I had gotten the advice to put the IMAGE_INSTALL += web-webkit into the core-image-sato.bb file. Both seem to work. Not sure which is the best approach. Maybe creating a .bbappend in my BSP?? So how do I know which applications are installed in an image? is there a how file of IMAGE_INSTALL statements? Jim A -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding what's in an image
On 2012-01-10 05:23, James Abernathy wrote: On Jan 10, 2012, at 7:03 AM, Gary Thomas wrote: On 2012-01-09 17:51, James Abernathy wrote: I'm trying to understand how bitbake parses the poky directory tree a little better. The best I can figure all .bb files are NOT included. Just some of them are. I'm guessing that the .bb in the meta/recipe-sato named core-image-sato.bb is the one that is used to start the parsing if bitbake core-image-sato is executed. I originally thought all subdirectories of a path included in BBLAYER were parsed looking for .bb files, but now I know that is not true, but not sure why. For example, it does not appear that webkit is included in the core-image-sato even though the recipe-sato directory includes the webkit subdirectory with it's recipe. What would be the proper way of adding the webkit to core-image-sato?? The 'webkit' is just a library used to build tools such as a web browser. You might want to start with an application that actually uses webkit, such as web-webkit. To build an image which includes web-webkit, add this line to your local.conf file and rebuild the image: IMAGE_INSTALL += web-webkit You can also build packages which are not installed into your image by default and use a package manager (e.g. zypper) to install the package later onto a running system. This was very helpful. Before I got your email, I had gotten the advice to put the IMAGE_INSTALL += web-webkit into the core-image-sato.bb file. Both seem to work. Not sure which is the best approach. Maybe creating a .bbappend in my BSP?? It's seldom a good idea to modify anything in the Yocto core unless that change should be pushed to everyone. Make the changes you need in your local layers. If you're building a specialized system/image for your target, you should probably consider making your own image recipe. The easiest way is to start with one of the extant image recipes and modifying it for your needs. So how do I know which applications are installed in an image? is there a how file of IMAGE_INSTALL statements? You could use hob to see which packages are in your image. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Unable to set system clock
Hi, I am getting problem in changing system clock of my board. On rebooting the board after changing time, I can see the new time in kernel boot messages like pmic_rtc pmic_rtc.1: setting system clock to 2012-01-10 18:22:15 UTC (1326219735) but again it used to reconfigure system clock. Kindly see the boot messages which comes after above mentioned message- Configuring network interfaces... done. Tue Jan 10 10:28:00 UTC 2012 INIT: Entering runlevel: 5 Starting syslogd/klogd: done So now on giving date command at prompt I am getting the same time which was there before root@mx35pdk:~# date Tue Jan 10 10:29:17 UTC 2012 What I am unable to understand is why this problem is coming with time only. Date is getting changed successfully. I am pretty sure from hardware point of view because Ltib rootfs is working fine with this board. Any replies would be appreciable. Thanks Regards, Navani Kamal Srivastava Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to set system clock
On 2012-01-10 05:57, Navani Kamal Srivastava wrote: Hi, I am getting problem in changing system clock of my board. On rebooting the board after changing time, I can see the new time in kernel boot messages like “pmic_rtc pmic_rtc.1: setting system clock to 2012-01-10 18:22:15 UTC (1326219735) “ but again it used to reconfigure system clock. Kindly see the boot messages which comes after above mentioned message- Configuring network interfaces... done. Tue Jan 10 10:28:00 UTC 2012 INIT: Entering runlevel: 5 Starting syslogd/klogd: done So now on giving “date” command at prompt I am getting the same time which was there before root@mx35pdk:~# date Tue Jan 10 10:29:17 UTC 2012 What I am unable to understand is why this problem is coming with time only. Date is getting changed successfully. I am pretty sure from hardware point of view because Ltib rootfs is working fine with this board. Any replies would be appreciable. What's your hardware target? There is a bug #1767 that can make the system always reset the clock to the saved timestamp on boot. This is probably what's happening to you. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble creating new package
On 10/01/12 11:21, Jack Mitchell wrote:
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell wrote:
Good morning everyone,
I am currently having issues creating a (very!) simple package. I have
looked at the latest reference manual and studied other .bb files to no
avail.
I am trying to build a simple web server called Hiawatha. To install
(http://www.hiawatha-webserver.org/howto/compilation_and_installation)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this behaviour in a .bb
file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org;
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I feel this should be an
extremely easy piece of software to build - I think I'm just not
understanding the build system correctly
The error I receive when trying to build this package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/temp/log.do_install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't understand why
autotools should be inherited if it is only a make/configure
combination being used?
Best Regards
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Ok, I have managed to get a bit further on this. I didn't realise that I
had to do
bitbake -c clean hiawatha
Everytime I had changed the package to ensure that it was building with
the new configuration. My new .bb looks like this:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org;
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
DEPENDS = openssl libxml2 libxslt
SECTION = custom
PR = r0
SRC_URI = http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
inherit autotools
EXTRA_OEMAKE = 'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include
-DWITHOUT_XATTR' \
'BUILDDIR=${S}'
EXTRA_OECONF = --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
--mandir=${mandir}
do_configure() {
oe_runconf
}
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
INCLUDEDIR=${includedir}
Now, this is building and installing however the Hiawatha binary doesn't
get included in the build. The configuration files make it in so I know
it's running the make install phase however I don't know how to find out
what is going on during the build and why the binary isn't making it in
the rootfs.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] augeas: Add libxml2 dependency
This patch fixes the following Augeas configure error.
| checking for LIBXML... no
| configure: error: Package requirements (libxml-2.0) were not met:
|
| No package 'libxml-2.0' found
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
| Alternatively, you may set the environment variables LIBXML_CFLAGS
| and LIBXML_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
| ERROR: oe_runconf failed
Signed-off-by: Martin Donnelly martin.donne...@ge.com
---
meta/recipes-extended/augeas/augeas.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/augeas/augeas.inc
b/meta/recipes-extended/augeas/augeas.inc
index 0c6d534..f9263cf 100644
--- a/meta/recipes-extended/augeas/augeas.inc
+++ b/meta/recipes-extended/augeas/augeas.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=bbb461211a33b134d42ed5ee802b37ff
SRC_URI = http://augeas.net/download/${BP}.tar.gz;
-DEPENDS = readline
+DEPENDS = readline libxml2
inherit autotools
--
1.7.6.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble creating new package
On Tue, Jan 10, 2012 at 8:20 AM, Jack Mitchell m...@communistcode.co.ukwrote:
On 10/01/12 11:21, Jack Mitchell wrote:
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell wrote:
Good morning everyone,
I am currently having issues creating a (very!) simple package. I have
looked at the latest reference manual and studied other .bb files to no
avail.
I am trying to build a simple web server called Hiawatha. To install
(http://www.hiawatha-**webserver.org/howto/**
compilation_and_installationhttp://www.hiawatha-webserver.org/howto/compilation_and_installation
)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this behaviour in a .bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE =
http://www.hiawatha-**webserver.orghttp://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=**a9b0a0eb7c54c87ec6ac05f5f603df
**6a
SECTION = custom
PR = r0
SRC_URI = http://www.hiawatha-**webserver.org/files/hiawatha-**
7.8.2.tar.gzhttp://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz
SRC_URI[md5sum] = **8aff3f8c759871ea1d1ff22e980303**32
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I feel this should be an
extremely easy piece of software to build - I think I'm just not
understanding the build system correctly
The error I receive when trying to build this package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/**beagleInitial/tmp/work/**
armv5te-poky-linux-gnueabi/**hiawatha-7.8.2-r0/temp/log.do_**install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-**git/beagleInitial/tmp/work/**
armv5te-poky-linux-gnueabi/**hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't understand why
autotools should be inherited if it is only a make/configure combination
being used?
Best Regards
__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto
Ok, I have managed to get a bit further on this. I didn't realise that I
had to do
bitbake -c clean hiawatha
Everytime I had changed the package to ensure that it was building with
the new configuration. My new .bb looks like this:
DESCRIPTION = Lightweight secure web server
HOMEPAGE =
http://www.hiawatha-**webserver.orghttp://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=**a9b0a0eb7c54c87ec6ac05f5f603df**
6a
DEPENDS = openssl libxml2 libxslt
SECTION = custom
PR = r0
SRC_URI = http://www.hiawatha-**webserver.org/files/hiawatha-**
7.8.2.tar.gzhttp://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz
SRC_URI[md5sum] = **8aff3f8c759871ea1d1ff22e980303**32
inherit autotools
EXTRA_OEMAKE = 'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include
-DWITHOUT_XATTR' \
'BUILDDIR=${S}'
EXTRA_OECONF = --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
--mandir=${mandir}
do_configure() {
oe_runconf
}
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
INCLUDEDIR=${includedir}
Now, this is building and installing however the Hiawatha binary doesn't
get included in the build. The configuration files make it in so I know
it's running the make install phase however I don't know how to find out
what is going on during the build and why the binary isn't making it in the
rootfs.
Maybe you need an IMAGE_INSTALL += hiawatha in you local.conf
Jim A
__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Related to eglibc
Hello Khem, Thanks for your reply. can you try it with eglibc-2.13 or eglibc-2.14 ? I tried using eglibc-2.13 and eglibc-2.14 but they didn't worked. Still Qt application are refreshing at every touch. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble creating new package
On 10/01/12 13:38, James Abernathy wrote:
On Tue, Jan 10, 2012 at 8:20 AM, Jack Mitchell m...@communistcode.co.uk
mailto:m...@communistcode.co.uk wrote:
On 10/01/12 11:21, Jack Mitchell wrote:
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell wrote:
Good morning everyone,
I am currently having issues creating a (very!) simple
package. I have
looked at the latest reference manual and studied
other .bb files to no
avail.
I am trying to build a simple web server called
Hiawatha. To install
(http://www.hiawatha-webserver.org/howto/compilation_and_installation)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this
behaviour in a .bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org
http://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I feel
this should be an
extremely easy piece of software to build - I think
I'm just not
understanding the build system correctly
The error I receive when trying to build this package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/temp/log.do_install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man
INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't
understand why autotools should be inherited if it is only a
make/configure combination being used?
Best Regards
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Ok, I have managed to get a bit further on this. I didn't realise
that I had to do
bitbake -c clean hiawatha
Everytime I had changed the package to ensure that it was building
with the new configuration. My new .bb looks like this:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org
http://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
DEPENDS = openssl libxml2 libxslt
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
inherit autotools
EXTRA_OEMAKE = 'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include
-DWITHOUT_XATTR' \
'BUILDDIR=${S}'
EXTRA_OECONF = --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
--mandir=${mandir}
do_configure() {
Re: [yocto] Trouble creating new package
On 2012-01-10 06:39, Jack Mitchell wrote:
On 10/01/12 13:38, James Abernathy wrote:
On Tue, Jan 10, 2012 at 8:20 AM, Jack Mitchell m...@communistcode.co.uk
mailto:m...@communistcode.co.uk wrote:
On 10/01/12 11:21, Jack Mitchell wrote:
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell wrote:
Good morning everyone,
I am currently having issues creating a (very!) simple package.
I have
looked at the latest reference manual and studied other .bb
files to no
avail.
I am trying to build a simple web server called Hiawatha. To
install
(http://www.hiawatha-webserver.org/howto/compilation_and_installation)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this behaviour in a
.bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org
http://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I feel this
should be an
extremely easy piece of software to build - I think I'm just not
understanding the build system correctly
The error I receive when trying to build this package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/temp/log.do_install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't understand why
autotools should be inherited if it is only a make/configure combination being
used?
Best Regards
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Ok, I have managed to get a bit further on this. I didn't realise that I
had to do
bitbake -c clean hiawatha
Everytime I had changed the package to ensure that it was building with the
new configuration. My new .bb looks like this:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org
http://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
DEPENDS = openssl libxml2 libxslt
SECTION = custom
PR = r0
SRC_URI = http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
inherit autotools
EXTRA_OEMAKE = 'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include
-DWITHOUT_XATTR' \
'BUILDDIR=${S}'
EXTRA_OECONF = --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
--mandir=${mandir}
do_configure() {
oe_runconf
}
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} INCLUDEDIR=${includedir}
Now, this is building and installing however the Hiawatha binary doesn't
get included in the build. The configuration files make it in so I know it's
Re: [yocto] Trouble creating new package
On 10/01/12 13:50, Gary Thomas wrote:
On 2012-01-10 06:39, Jack Mitchell wrote:
On 10/01/12 13:38, James Abernathy wrote:
On Tue, Jan 10, 2012 at 8:20 AM, Jack Mitchell
m...@communistcode.co.uk mailto:m...@communistcode.co.uk wrote:
On 10/01/12 11:21, Jack Mitchell wrote:
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell
wrote:
Good morning everyone,
I am currently having issues creating a (very!)
simple package. I have
looked at the latest reference manual and studied
other .bb files to no
avail.
I am trying to build a simple web server called
Hiawatha. To install
(http://www.hiawatha-webserver.org/howto/compilation_and_installation)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this
behaviour in a .bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org
http://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I
feel this should be an
extremely easy piece of software to build - I think
I'm just not
understanding the build system correctly
The error I receive when trying to build this
package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/temp/log.do_install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man
INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't
understand why autotools should be inherited if it is only a
make/configure combination being used?
Best Regards
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Ok, I have managed to get a bit further on this. I didn't
realise that I had to do
bitbake -c clean hiawatha
Everytime I had changed the package to ensure that it was
building with the new configuration. My new .bb looks like this:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org
http://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
DEPENDS = openssl libxml2 libxslt
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
inherit autotools
EXTRA_OEMAKE = 'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include
-DWITHOUT_XATTR' \
'BUILDDIR=${S}'
EXTRA_OECONF = --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
--mandir=${mandir}
do_configure() {
oe_runconf
}
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
INCLUDEDIR=${includedir}
Now, this is building and installing however the Hiawatha binary
doesn't get included
Re: [yocto] understanding what's in an image
On 01/09/2012 09:07 PM, Christopher Larson wrote: Read layer.conf in each layer. See the BBFILES variable. -- Christopher Larson On Monday, January 9, 2012 at 5:51 PM, James Abernathy wrote: I'm trying to understand how bitbake parses the poky directory tree a little better. The best I can figure all .bb files are NOT included. Just some of them are. I'm guessing that the .bb in the meta/recipe-sato named core-image-sato.bb is the one that is used to start the parsing if bitbake core-image-sato is executed. I originally thought all subdirectories of a path included in BBLAYER were parsed looking for .bb files, but now I know that is not true, but not sure why. For example, it does not appear that webkit is included in the core-image-sato even though the recipe-sato directory includes the webkit subdirectory with it's recipe. What would be the proper way of adding the webkit to core-image-sato?? Jim A ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto the layer.conf in meta/conf includes and covers all .bb files under it like receipe-sato, which includes web-webkit. So does this say that the web-webkit get's built by bitbake, but the images does not contain web-webkit until you put in the IMAGE_INSTALL += web-webit??? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding what's in an image
On 2012-01-10 07:48, Jim Abernathy wrote: On 01/09/2012 09:07 PM, Christopher Larson wrote: Read layer.conf in each layer. See the BBFILES variable. -- Christopher Larson On Monday, January 9, 2012 at 5:51 PM, James Abernathy wrote: I'm trying to understand how bitbake parses the poky directory tree a little better. The best I can figure all .bb files are NOT included. Just some of them are. I'm guessing that the .bb in the meta/recipe-sato named core-image-sato.bb is the one that is used to start the parsing if bitbake core-image-sato is executed. I originally thought all subdirectories of a path included in BBLAYER were parsed looking for .bb files, but now I know that is not true, but not sure why. For example, it does not appear that webkit is included in the core-image-sato even though the recipe-sato directory includes the webkit subdirectory with it's recipe. What would be the proper way of adding the webkit to core-image-sato?? Jim A ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto the layer.conf in meta/conf includes and covers all .bb files under it like receipe-sato, which includes web-webkit. So does this say that the web-webkit get's built by bitbake, but the images does not contain web-webkit until you put in the IMAGE_INSTALL += web-webit??? No, only packages which are needed to satisfy the needs of the given image are built. So, if your image does not include web-webkit, it won't be built even though there is a recipe for it. When building an image, bitbake looks at the image recipe and figures out what packages are needed (these are listed explicitly). Then any additional packages which are needed (DEPENDS, RDEPENDS, etc) will be added to the list. This process continues until all dependencies are met, yielding the final package set. Out of the 1000 or so possible recipes, you may end up only building a few hundred and many of these are support - i.e. only used for the build process itself. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding what's in an image
On 01/10/2012 09:57 AM, Gary Thomas wrote: On 2012-01-10 07:48, Jim Abernathy wrote: On 01/09/2012 09:07 PM, Christopher Larson wrote: Read layer.conf in each layer. See the BBFILES variable. -- Christopher Larson On Monday, January 9, 2012 at 5:51 PM, James Abernathy wrote: I'm trying to understand how bitbake parses the poky directory tree a little better. The best I can figure all .bb files are NOT included. Just some of them are. I'm guessing that the .bb in the meta/recipe-sato named core-image-sato.bb is the one that is used to start the parsing if bitbake core-image-sato is executed. I originally thought all subdirectories of a path included in BBLAYER were parsed looking for .bb files, but now I know that is not true, but not sure why. For example, it does not appear that webkit is included in the core-image-sato even though the recipe-sato directory includes the webkit subdirectory with it's recipe. What would be the proper way of adding the webkit to core-image-sato?? Jim A ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto the layer.conf in meta/conf includes and covers all .bb files under it like receipe-sato, which includes web-webkit. So does this say that the web-webkit get's built by bitbake, but the images does not contain web-webkit until you put in the IMAGE_INSTALL += web-webit??? No, only packages which are needed to satisfy the needs of the given image are built. So, if your image does not include web-webkit, it won't be built even though there is a recipe for it. When building an image, bitbake looks at the image recipe and figures out what packages are needed (these are listed explicitly). Then any additional packages which are needed (DEPENDS, RDEPENDS, etc) will be added to the list. This process continues until all dependencies are met, yielding the final package set. Out of the 1000 or so possible recipes, you may end up only building a few hundred and many of these are support - i.e. only used for the build process itself. This makes sense now, thanks. I did this via hob this morning and it become more obvious because hob approaches this process as all about the package. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble creating new package
On 10/01/12 13:56, Jack Mitchell wrote:
On 10/01/12 13:50, Gary Thomas wrote:
On 2012-01-10 06:39, Jack Mitchell wrote:
On 10/01/12 13:38, James Abernathy wrote:
On Tue, Jan 10, 2012 at 8:20 AM, Jack Mitchell
m...@communistcode.co.uk mailto:m...@communistcode.co.uk wrote:
On 10/01/12 11:21, Jack Mitchell wrote:
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell
wrote:
Good morning everyone,
I am currently having issues creating a (very!)
simple package. I have
looked at the latest reference manual and studied
other .bb files to no
avail.
I am trying to build a simple web server called
Hiawatha. To install
(http://www.hiawatha-webserver.org/howto/compilation_and_installation)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this
behaviour in a .bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org
http://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I
feel this should be an
extremely easy piece of software to build - I think
I'm just not
understanding the build system correctly
The error I receive when trying to build this
package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/temp/log.do_install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man
INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't
understand why autotools should be inherited if it is only a
make/configure combination being used?
Best Regards
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Ok, I have managed to get a bit further on this. I didn't
realise that I had to do
bitbake -c clean hiawatha
Everytime I had changed the package to ensure that it was
building with the new configuration. My new .bb looks like this:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org
http://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
DEPENDS = openssl libxml2 libxslt
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
inherit autotools
EXTRA_OEMAKE = 'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include
-DWITHOUT_XATTR' \
'BUILDDIR=${S}'
EXTRA_OECONF = --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
--mandir=${mandir}
do_configure() {
oe_runconf
}
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
INCLUDEDIR=${includedir}
Now, this is building and installing however
Re: [yocto] Trouble creating new package
On Tue, Jan 10, 2012 at 4:21 AM, Jack Mitchell m...@communistcode.co.uk wrote: Inheriting autotools makes no difference, I also don't understand why autotools should be inherited if it is only a make/configure combination being used? That's what autotools *is*. ./configure is almost always a script generated by autoconf, which is one of the tools referred to by autotools (autoconf, automake, libtool). -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto SWAT team kickoff
Hi all, We would like to kick off the Yocto SWAT team this week. Please see the following for the purpose of the SWAT team and let me know if you have any questions or concerns. We welcome any community participation on the SWAT team. At the same time, I will work with the team to make sure thing get started. Thanks, Song YOCTO SWAT TEAM GOAL The assembly of the Yocto Project SWAT team is mainly to tackle urgent technical problems that break build on the master branch or major release branches in a timely manner, thus to maintain the stability of the master and release branch. The SWAT team includes volunteers or appointed members of the Yocto Project team. Community members can also volunteer to be part of the SWAT team. SCOPE OF RESPONSIBILITY Whenever a build (nightly build, weekly build, release build) fails, the SWAT team is responsible for ensuring the necessary debugging occurs and organizing resources to solve the issue and ensure successful builds. If resolving the issues requires schedule or resource adjustment, the SWAT team should work with program and development management to accommodate the change in the overall planning. MEMBERS: * Darren Hart (US) * Elizabeth Flanagan (US) * Paul Eggleton (UK) * Jessica Zhang (US) * Dexuan Cui (CN) * Saul Wold (US) * Richard Purdie (UK) ROTATING CHAIR: A chairperson role will be rotated among team members each week. The Chairperson should monitor the build status for the entire week. Whenever a build is broken, the Chairperson should do necessary debugging and organize resources to solve the problems in a timely manner to meet the overall project and release schedule. The Chairperson serves as the focal point of the SWAT team to external people such as program managers or development managers. ROTATING PROCESS Each week on a specific day (propose Monday), a SWAT team meeting could be called at the chairperson's discretion to discuss current issues and status. Either during the meeting or offline, the Chairperson of last week will identify and pass the role to another person in the team. The program manager should be notified at the same time. Usually, this will take a simple round robin order. In case the next person cannot take the role due to tight schedule, vacation or some other reasons, the role will be passed to the next person. The current Chairperson's full name and email address will be published on the project status wiki page: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status under Current SWAT team Chairperson section. BKM (RICHARD PURDIE) When looking at a failure, the first question is what the baseline was and what changed. If there were recent known good builds it helps to narrow down the number of changes that were likely responsible for the failure. It's also useful to note if the build was from scratch or from existing sstate files. You can tell by seeing what setscene tasks run in the log. The primary responsibility is to ensure that any failures are categorized correctly and that the right people get to know about them. It's important *someone* is then tasked with fixing it. Image failures are particular tricky since its likely some component of the image that failed and the question is then whether that component changed recently, whether it was some kind of core functionality at fault and so on. Ideally we want to get the failure reported to the person who knows something about the area and can come up with a fix without it distracting them too much. As a secondary responsibility, its often helpful for to triage the failure. This might mean documenting a way to reproduce the failure outside a full build and/or documenting how the failure is happening and maybe even propose a fix. Sometimes failures are difficult to understand and can require direct ssh access to the autobuilder so the issue can be debugged passively on the system to examine contents of files and so forth. If doing this ensure you don't change any of the file system for example adding files that couldn't then be deleted by the autobuilder when it rebuilds. Rarely, live debugging might be needed where you'd su to the pokybuild user and run a build manually to see the failure in real time. If doing this, ensure you only create files as the pokybuild user and you are careful not to generate sstate packages which shouldn't be present or any other bad state that might get reused. In general its recommended not to do live debugging. This can be escalated to RP/Saul/Beth if needed. To fulfill the primary responsibility, it's suggested that bugs are opened on the bugzilla for each type of failure. This way, appropriate people can be brought into the discussion and a specific owner of the failure can be assigned. Replying to the build failure with the bug ID and also bringing the bug to the attention of anyone you suspect was responsible for the problem are also good practices.
[yocto] yocto on Acer Aspire One NAV50
I created a core-image-sato using the meta-n450 BSP hoping I could work with it on the Acer Aspire One 532h-2588. However, that netbook uses the Atheros AR5B95 wireless NIC and the Atheros AR8132 wired NIC, which are not recognized. Is there anything already in Yocto that could be turned on to support these devices, or am I left with porting the drives? Since Ubuntu 11.10 with it's kernel 3.0.0 supports these devices and runs on the netbook, I'm guessing it's a matter of configuring the kernel to include these modules. Does this sound right?? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble creating new package
On 01/10/2012 03:21 AM, Jack Mitchell wrote:
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell wrote:
Good morning everyone,
I am currently having issues creating a (very!) simple package. I have
looked at the latest reference manual and studied other .bb files to no
avail.
I am trying to build a simple web server called Hiawatha. To install
(http://www.hiawatha-webserver.org/howto/compilation_and_installation)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this behaviour in a .bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE = http://www.hiawatha-webserver.org;
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=a9b0a0eb7c54c87ec6ac05f5f603df6a
SECTION = custom
PR = r0
SRC_URI =
http://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz;
SRC_URI[md5sum] = 8aff3f8c759871ea1d1ff22e98030332
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
By using inherit autotools, you can remove this step and let bitbake
handle the configure and compile / make steps.
You can reduce the above to
EXTRA_OECONF = --disable-ipv6 --disable-ssl --disable-toolkit
--disable-xslt --disable-largefile
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
This generally looks correct, but I would move the install to the end,
not sure why but it might make a difference.
Another test you can do since it gets to the install point is to use
devshell (bitbake hiawatha -c devshell)
The will give you a shell with all the variables set and you can run the
make install directly on the command line and verify if there is a
problem there. You can also review the run scripts in the
temp/run.do_install.pid file for the hiawatha package.
Hope that helps you.
Sau!
Could someone point me in the right direction, I feel this should be an
extremely easy piece of software to build - I think I'm just not
understanding the build system correctly
The error I receive when trying to build this package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/temp/log.do_install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-git/beagleInitial/tmp/work/armv5te-poky-linux-gnueabi/hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't understand why
autotools should be inherited if it is only a make/configure combination
being used?
Best Regards
___
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 on Acer Aspire One NAV50
On 12-01-10 10:47 AM, James Abernathy wrote: I created a core-image-sato using the meta-n450 BSP hoping I could work with it on the Acer Aspire One 532h-2588. However, that netbook uses the Atheros AR5B95 wireless NIC and the Atheros AR8132 wired NIC, which are not recognized. Is there anything already in Yocto that could be turned on to support these devices, or am I left with porting the drives? Since Ubuntu 11.10 with it's kernel 3.0.0 supports these devices and runs on the netbook, I'm guessing it's a matter of configuring the kernel to include these modules. Does this sound right?? That should be all that is required. If the drivers you need are indeed in 3.0 (I didn't go check explicitly), then you can create a bbappend for the BSP in a layer, and add a configuration fragment that enables the drivers you need (as modules or builtin, your choice). Examples of config fragments are in the BSP/kernel guides found on the yocto project pages. Cheers, Bruce Jim A ___ 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] [PATCH 1/4] lttng-ust: Integrate into yocto linux
This patch intended to integrate the LTTng UST 2.0 package, which
contains the userspace tracer library to trace userspace codes.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb | 25 ++
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
diff --git a/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
b/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
new file mode 100644
index 000..846019e
--- /dev/null
+++ b/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
@@ -0,0 +1,25 @@
+SUMMARY = Linux Trace Toolkit Userspace Tracer 2.0
+DESCRIPTION = The LTTng UST 2.0 package contains the userspace tracer library
to trace userspace codes.
+HOMEPAGE = http://lttng.org/lttng2.0;
+BUGTRACKER = n/a
+
+LICENSE = LGPLv2.1+ BSD
+LIC_FILES_CHKSUM = file://COPYING;md5=e647752e045a8c45b6f583771bd561ef \
+
file://snprintf/snprintf.c;endline=32;md5=d3d544959d8a3782b2e07451be0a903c \
+
file://snprintf/various.h;endline=31;md5=89f2509b6b4682c4fc95255eec4abe44
+
+inherit autotools
+
+DEPENDS = liburcu util-linux
+
+SRC_URI = http://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.gz;
+
+SRC_URI[md5sum] = 0f09bb954c99cb99ab6997cd492953c1
+SRC_URI[sha256sum] =
e9ec3c55c2251b3f3b512bfa1015b0f67e35d55793850ccea5134f7b24ee3ba1
+
+S = ${WORKDIR}/lttng-ust-${PV}
+
+# Due to liburcu not building on MIPS currently this recipe needs to
+# be limited also.
+# So here let us first suppport x86/arm/powerpc platforms now.
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-linux'
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/4] lttng-tools: Integrated from git repo.
This patch intended to integrate the Linux trace toolkit, which
is a suite of tools designed to extract program execution details
from the Linux operating system and interpret them.
lttng-tools 2.0 is currently in pre-release(-pre16), so we have to
update it when official released.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
...tools-fix-compiling-error-for-powerpc-arm.patch | 28 +++
.../lttng-2.0/lttng-tools_2.0-pre16.bb | 29
2 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-kernel/lttng-2.0/lttng-tools-fix-compiling-error-for-powerpc-arm.patch
create mode 100644 meta/recipes-kernel/lttng-2.0/lttng-tools_2.0-pre16.bb
diff --git
a/meta/recipes-kernel/lttng-2.0/lttng-tools-fix-compiling-error-for-powerpc-arm.patch
b/meta/recipes-kernel/lttng-2.0/lttng-tools-fix-compiling-error-for-powerpc-arm.patch
new file mode 100644
index 000..f8e144f
--- /dev/null
+++
b/meta/recipes-kernel/lttng-2.0/lttng-tools-fix-compiling-error-for-powerpc-arm.patch
@@ -0,0 +1,28 @@
+From 5d8d75ab0c7f9e0009d90a2e5ad6475034a5c859 Mon Sep 17 00:00:00 2001
+From: Zumeng Chen zumeng.c...@windriver.com
+Date: Tue, 10 Jan 2012 12:41:45 +0800
+Subject: [PATCH 1/1] Fix compiling error on powerpc and arm
+
+For powerpc and arm, some MAP_ are defined asm/mman.h,
+so including it in header.
+
+Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
+---
+ common/runas.c |1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+diff --git a/common/runas.c b/common/runas.c
+index f612ccc..62a2791 100644
+--- a/common/runas.c
b/common/runas.c
+@@ -29,6 +29,7 @@
+ #include fcntl.h
+ #include sched.h
+ #include sys/mman.h
++#include asm/mman.h
+
+ #include lttngerr.h
+
+--
+1.7.5.4
+
diff --git a/meta/recipes-kernel/lttng-2.0/lttng-tools_2.0-pre16.bb
b/meta/recipes-kernel/lttng-2.0/lttng-tools_2.0-pre16.bb
new file mode 100644
index 000..d771ed9
--- /dev/null
+++ b/meta/recipes-kernel/lttng-2.0/lttng-tools_2.0-pre16.bb
@@ -0,0 +1,29 @@
+SECTION = devel
+SUMMARY = Linux Trace Toolkit Control
+DESCRIPTION = The Linux trace toolkit is a suite of tools designed \
+to extract program execution details from the Linux operating system \
+and interpret them.
+
+LICENSE = GPLv2.1
+LIC_FILES_CHKSUM = file://COPYING;md5=ab682a4729389c3f11913d758affe98e \
+file://gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
+file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca
+
+DEPENDS = liburcu popt lttng-ust
+
+SRCREV = f2ca2e251d8f49b0dbbcca529dd61b3562c1147f
+PV = v2.0.pre16+git${SRCREV}
+PR = r0
+
+SRC_URI = git://git.lttng.org/lttng-tools.git;protocol=git\
+ file://lttng-tools-fix-compiling-error-for-powerpc-arm.patch
+
+S = ${WORKDIR}/git
+
+inherit autotools
+
+export KERNELDIR=${STAGING_KERNEL_DIR}
+
+# Currenly lttng-tools doesn't supprt MIPS officially.
+# So here let us keep as-is.
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-linux'
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 4/4] babeltrace: Integrated from version 0.8
It provides trace read and write libraries, as well as a trace converter.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
meta/recipes-kernel/lttng-2.0/babeltrace_0.8.bb | 28 +++
1 files changed, 28 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-kernel/lttng-2.0/babeltrace_0.8.bb
diff --git a/meta/recipes-kernel/lttng-2.0/babeltrace_0.8.bb
b/meta/recipes-kernel/lttng-2.0/babeltrace_0.8.bb
new file mode 100644
index 000..dfa4790
--- /dev/null
+++ b/meta/recipes-kernel/lttng-2.0/babeltrace_0.8.bb
@@ -0,0 +1,28 @@
+SUMMARY = Babeltrace - Trace Format Babel Tower
+DESCRIPTION = Babeltrace provides trace read and write libraries in host
side, as well as a trace converter, which used to convert LTTng 2.0 traces into
human-readable log.
+HOMEPAGE = http://www.efficios.com/babeltrace/;
+BUGTRACKER = n/a
+
+LICENSE = MIT GPLV2
+LIC_FILES_CHKSUM = file://LICENSE;md5=8d1a03b3c17bdd158b3cbb34813b1423
+
+inherit autotools
+
+DEPENDS = gtk+ util-linux
+
+SRCREV = 31e670293588d7882a232bc14b93d5e956fa43f4
+PV = 0.8+git${SRCPV}
+PR = r0
+
+SRC_URI = git://git.efficios.com/babeltrace.git;protocol=git
+
+S = ${WORKDIR}/git
+
+do_configure_prepend () {
+ ${S}/bootstrap
+}
+
+# Due to liburcu not building on MIPS currently this recipe needs to
+# be limited also.
+# So here let us first suppport x86/arm/powerpc platforms now.
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-linux'
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 3/4] lttng-modules: from lttng-modules 2.0 git repo.
This patch intended to integrate the lttng-modules 2.0 package
containing the kernel tracer modules.
LTTng-modules 2.0 is currently in pre-release (-pre11), so we
have to update it when official released.
lttng-2.0 supports lttng-modules extra builds, which don't need
any patches on Linux kernel vs the previous version of lttng.
As described in README of lttng-modules-2.0, so far, it has been
tested in the latest kernel on x86 32/64-bit, and powerpc 32-bit,
, build tested on ARM. So does yocto kernel, the related tests
on qemux86 and qemuppc has been validated and a build test on
qemuarm passed too with this patcheset.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
...modules-replace-KERNELDIR-with-KERNEL_SRC.patch | 41
.../lttng-2.0/lttng-modules_2.0.pre11.bb | 27 +
2 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-kernel/lttng-2.0/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
create mode 100644 meta/recipes-kernel/lttng-2.0/lttng-modules_2.0.pre11.bb
diff --git
a/meta/recipes-kernel/lttng-2.0/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
b/meta/recipes-kernel/lttng-2.0/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
new file mode 100644
index 000..aa24171
--- /dev/null
+++
b/meta/recipes-kernel/lttng-2.0/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
@@ -0,0 +1,41 @@
+Upstream-Status: Inappropriate [embedded specific]
+
+lttng-modules: replace KERNELDIR with KERNEL_SRC
+
+Since lttng-modules uses the default way of module.bbclass to
+build and install lttng-modules, we do this replacement for
+it as-is.
+
+Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
+---
+ Makefile |7 +++
+ 1 files changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 5ac13d7..25caad5 100644
+--- a/Makefile
b/Makefile
+@@ -38,17 +38,16 @@ obj-m += lib/
+ endif
+
+ else
+- KERNELDIR ?= /lib/modules/$(shell uname -r)/build
+ PWD := $(shell pwd)
+ CFLAGS = $(EXTCFLAGS)
+
+ default:
+- $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
++ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules
+
+ modules_install:
+- $(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install
++ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules_install
+
+ clean:
+- $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
++ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) clean
+
+ endif
+--
+1.7.5.4
+
diff --git a/meta/recipes-kernel/lttng-2.0/lttng-modules_2.0.pre11.bb
b/meta/recipes-kernel/lttng-2.0/lttng-modules_2.0.pre11.bb
new file mode 100644
index 000..4bf636e
--- /dev/null
+++ b/meta/recipes-kernel/lttng-2.0/lttng-modules_2.0.pre11.bb
@@ -0,0 +1,27 @@
+SECTION = devel
+SUMMARY = Linux Trace Toolkit KERNEL MODULE
+DESCRIPTION = The lttng-modules 2.0 package contains the kernel tracer
modules
+LICENSE = LGPLv2.1 GPLv2
+LIC_FILES_CHKSUM = file://LICENSE;md5=1eb086682a7c65a45acd9bcdf6877b3e \
+file://gpl-2.0.txt;md5=751419260aa954499f7abaabaa882bbe \
+file://lgpl-2.1.txt;md5=243b725d71bb5df4a1e5920b344b86ad
+
+DEPENDS = virtual/kernel
+
+inherit module
+
+SRCREV = 4d3e89e379fc66480d729abe8daa5c86eb585400
+PV = 2.0.pre11+git${SRCREV}
+PR = r0
+
+SRC_URI = git://git.lttng.org/lttng-modules.git;protocol=git \
+ file://lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
+
+export INSTALL_MOD_DIR=kernel/lttng-modules
+
+S = ${WORKDIR}/git
+
+# Currenly lttng-tools doesn't supprt MIPS officially.
+# So here let us keep as-is.
+
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-linux'
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto on Acer Aspire One NAV50
On 01/10/2012 10:50 AM, Bruce Ashfield wrote: On 12-01-10 10:47 AM, James Abernathy wrote: I created a core-image-sato using the meta-n450 BSP hoping I could work with it on the Acer Aspire One 532h-2588. However, that netbook uses the Atheros AR5B95 wireless NIC and the Atheros AR8132 wired NIC, which are not recognized. Is there anything already in Yocto that could be turned on to support these devices, or am I left with porting the drives? Since Ubuntu 11.10 with it's kernel 3.0.0 supports these devices and runs on the netbook, I'm guessing it's a matter of configuring the kernel to include these modules. Does this sound right?? That should be all that is required. If the drivers you need are indeed in 3.0 (I didn't go check explicitly), then you can create a bbappend for the BSP in a layer, and add a configuration fragment that enables the drivers you need (as modules or builtin, your choice). Examples of config fragments are in the BSP/kernel guides found on the yocto project pages. If I'm only making changes to the .config parameters, do I still need to create a local bare clone of the yocto kernel and also git the poky-extras repository as mentioned in the Developers Manual appendix B? Jim A Cheers, Bruce Jim A ___ 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 on Acer Aspire One NAV50
On 12-01-10 11:31 AM, Jim Abernathy wrote: On 01/10/2012 10:50 AM, Bruce Ashfield wrote: On 12-01-10 10:47 AM, James Abernathy wrote: I created a core-image-sato using the meta-n450 BSP hoping I could work with it on the Acer Aspire One 532h-2588. However, that netbook uses the Atheros AR5B95 wireless NIC and the Atheros AR8132 wired NIC, which are not recognized. Is there anything already in Yocto that could be turned on to support these devices, or am I left with porting the drives? Since Ubuntu 11.10 with it's kernel 3.0.0 supports these devices and runs on the netbook, I'm guessing it's a matter of configuring the kernel to include these modules. Does this sound right?? That should be all that is required. If the drivers you need are indeed in 3.0 (I didn't go check explicitly), then you can create a bbappend for the BSP in a layer, and add a configuration fragment that enables the drivers you need (as modules or builtin, your choice). Examples of config fragments are in the BSP/kernel guides found on the yocto project pages. If I'm only making changes to the .config parameters, do I still need to create a local bare clone of the yocto kernel and also git the poky-extras repository as mentioned in the Developers Manual appendix B? Nope. You can just have your config fragment appended to the SRC_URI and it will be applied to the existing BSP. Only if you were creating a completely new board, and wanted to work with a local tree would you need those clones. Cheers, Bruce Jim A Cheers, Bruce Jim A ___ 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] [PATCH 1/4] lttng-ust: Integrate into yocto linux
On 01/10/2012 08:11 AM, Zumeng Chen wrote:
This patch intended to integrate the LTTng UST 2.0 package, which
contains the userspace tracer library to trace userspace codes.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb | 25
++
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
diff --git a/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
b/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
new file mode 100644
index 000..846019e
--- /dev/null
+++ b/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
@@ -0,0 +1,25 @@
+SUMMARY = Linux Trace Toolkit Userspace Tracer 2.0
+DESCRIPTION = The LTTng UST 2.0 package contains the userspace tracer
library to trace userspace codes.
+HOMEPAGE = http://lttng.org/lttng2.0;
+BUGTRACKER = n/a
+
+LICENSE = LGPLv2.1+ BSD
+LIC_FILES_CHKSUM = file://COPYING;md5=e647752e045a8c45b6f583771bd561ef \
+
file://snprintf/snprintf.c;endline=32;md5=d3d544959d8a3782b2e07451be0a903c \
+
file://snprintf/various.h;endline=31;md5=89f2509b6b4682c4fc95255eec4abe44
+
+inherit autotools
+
+DEPENDS = liburcu util-linux
+
+SRC_URI = http://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.gz;
+
+SRC_URI[md5sum] = 0f09bb954c99cb99ab6997cd492953c1
+SRC_URI[sha256sum] =
e9ec3c55c2251b3f3b512bfa1015b0f67e35d55793850ccea5134f7b24ee3ba1
+
+S = ${WORKDIR}/lttng-ust-${PV}
+
+# Due to liburcu not building on MIPS currently this recipe needs to
+# be limited also.
+# So here let us first suppport x86/arm/powerpc platforms now.
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-linux'
We had discussed using a different comment that more clearly stated why
this is necessary and use the same comment across all the patches
implementing this.
This applies to all 4 patches. The suggestion was in my response to
Patch 1/4 V1:
Looking through documentation.conf and existing poky sources, I believe
this test is correct. HOST/TARGET are the same in this case. The comment
is a bit confusing however. I believe the comment should read:
# liburcu doesn't build for MIPS
COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-linux'
The key difference being for instead of on. The rest of the comment
is redundant with the assignment itself. This applies to all 4 patches.
Otherwise, things look good.
--
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] Related to eglibc
On Tue, Jan 10, 2012 at 5:38 AM, Navani navani.srivast...@lnties.com wrote: Hello Khem, Thanks for your reply. can you try it with eglibc-2.13 or eglibc-2.14 ? I tried using eglibc-2.13 and eglibc-2.14 but they didn't worked. Still Qt application are refreshing at every touch. then you have to find differences how eglibc 2.11 is compiled the one which works. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/3][meta-intel] Alsa enhancements
CAVEAT: This series requires the alsa-state series recently submitted to the OE-Core mailing list. This series enables alsa as a MACHINE_FEATURE by default in the ia32-base so that alsa is enabled for all current BSP's. Following that the series drops the BSP-specific n450-audio recipe in favour of extending the common alsa-state recipe for alsa configuration. Note: the n450-audio recipe was not working in any stock image as alsa was not a listed MACHINE_FEATURE and the amixer package is not included by default. The following changes since commit 38f2b670bc37515bcb0fa7f98e338e5242d70386: meta-cedartrail: Create new layer for cedartrail System. (2012-01-09 17:55:07 -0600) are available in the git repository at: git://github.com/incandescant/meta-intel master https://github.com/incandescant/meta-intel/tree/master Joshua Lock (3): ia32-base: add alsa to MACHINE_FEATURES alsa-state: add alsa state for n450 n450-audio: drop this machine specific recipe in favour of alsa-state conf/machine/include/ia32-base.inc |2 +- meta-n450/conf/machine/n450.conf |2 - .../recipes-bsp/alsa-state/alsa-state.bbappend |1 + .../alsa-state/alsa-state/n450/asound.state| 450 meta-n450/recipes-bsp/n450-audio/n450-audio.bb | 30 -- .../recipes-bsp/n450-audio/n450-audio/n450-audio | 42 -- 6 files changed, 452 insertions(+), 75 deletions(-) create mode 100644 meta-n450/recipes-bsp/alsa-state/alsa-state.bbappend create mode 100644 meta-n450/recipes-bsp/alsa-state/alsa-state/n450/asound.state delete mode 100644 meta-n450/recipes-bsp/n450-audio/n450-audio.bb delete mode 100644 meta-n450/recipes-bsp/n450-audio/n450-audio/n450-audio -- 1.7.7.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/3] ia32-base: add alsa to MACHINE_FEATURES
Signed-off-by: Joshua Lock j...@linux.intel.com --- conf/machine/include/ia32-base.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/conf/machine/include/ia32-base.inc b/conf/machine/include/ia32-base.inc index 84693e2..8556d6e 100644 --- a/conf/machine/include/ia32-base.inc +++ b/conf/machine/include/ia32-base.inc @@ -6,7 +6,7 @@ # common settings for Intel-based machines # MACHINE_FEATURES += kernel26 screen keyboard pci usbhost ext2 ext3 x86 \ - acpi serial usbgadget + acpi serial usbgadget alsa MACHINE_EXTRA_RRECOMMENDS += kernel-modules eee-acpi-scripts MACHINE_ESSENTIAL_EXTRA_RDEPENDS += grub -- 1.7.7.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/3] alsa-state: add alsa state for n450
Add a custom asound.state for the n450 so that the alsa-state init
script sets (and restores) sound configuration appropriately.
Signed-off-by: Joshua Lock j...@linux.intel.com
---
.../recipes-bsp/alsa-state/alsa-state.bbappend |1 +
.../alsa-state/alsa-state/n450/asound.state| 450
2 files changed, 451 insertions(+), 0 deletions(-)
create mode 100644 meta-n450/recipes-bsp/alsa-state/alsa-state.bbappend
create mode 100644
meta-n450/recipes-bsp/alsa-state/alsa-state/n450/asound.state
diff --git a/meta-n450/recipes-bsp/alsa-state/alsa-state.bbappend
b/meta-n450/recipes-bsp/alsa-state/alsa-state.bbappend
new file mode 100644
index 000..72d991c
--- /dev/null
+++ b/meta-n450/recipes-bsp/alsa-state/alsa-state.bbappend
@@ -0,0 +1 @@
+FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
diff --git a/meta-n450/recipes-bsp/alsa-state/alsa-state/n450/asound.state
b/meta-n450/recipes-bsp/alsa-state/alsa-state/n450/asound.state
new file mode 100644
index 000..03a0bee
--- /dev/null
+++ b/meta-n450/recipes-bsp/alsa-state/alsa-state/n450/asound.state
@@ -0,0 +1,450 @@
+state.Intel {
+ control.1 {
+ iface MIXER
+ name 'Front Playback Volume'
+ value.0 36
+ value.1 36
+ comment {
+ access 'read write'
+ type INTEGER
+ count 2
+ range '0 - 39'
+ dbmin -5850
+ dbmax 0
+ dbvalue.0 -450
+ dbvalue.1 -450
+ }
+ }
+ control.2 {
+ iface MIXER
+ name 'Front Playback Switch'
+ value.0 true
+ value.1 true
+ comment {
+ access 'read write'
+ type BOOLEAN
+ count 2
+ }
+ }
+ control.3 {
+ iface MIXER
+ name 'Surround Playback Volume'
+ value.0 36
+ value.1 36
+ comment {
+ access 'read write'
+ type INTEGER
+ count 2
+ range '0 - 39'
+ dbmin -5850
+ dbmax 0
+ dbvalue.0 -450
+ dbvalue.1 -450
+ }
+ }
+ control.4 {
+ iface MIXER
+ name 'Surround Playback Switch'
+ value.0 false
+ value.1 false
+ comment {
+ access 'read write'
+ type BOOLEAN
+ count 2
+ }
+ }
+ control.5 {
+ iface MIXER
+ name 'Center Playback Volume'
+ value 36
+ comment {
+ access 'read write'
+ type INTEGER
+ count 1
+ range '0 - 39'
+ dbmin -5850
+ dbmax 0
+ dbvalue.0 -450
+ }
+ }
+ control.6 {
+ iface MIXER
+ name 'LFE Playback Volume'
+ value 36
+ comment {
+ access 'read write'
+ type INTEGER
+ count 1
+ range '0 - 39'
+ dbmin -5850
+ dbmax 0
+ dbvalue.0 -450
+ }
+ }
+ control.7 {
+ iface MIXER
+ name 'Center Playback Switch'
+ value false
+ comment {
+ access 'read write'
+ type BOOLEAN
+ count 1
+ }
+ }
+ control.8 {
+ iface MIXER
+ name 'LFE Playback Switch'
+ value false
+ comment {
+ access 'read write'
+ type BOOLEAN
+ count 1
+ }
+ }
+ control.9 {
+ iface MIXER
+ name 'Side Playback Volume'
+ value.0 36
+ value.1 36
+ comment {
+ access 'read write'
+ type INTEGER
+ count 2
+ range '0 - 39'
+ dbmin -5850
+ dbmax 0
+ dbvalue.0 -450
+ dbvalue.1 -450
+ }
+ }
+ control.10 {
+ iface MIXER
+ name 'Side Playback Switch'
+ value.0 false
+ value.1 false
+ comment {
+ access 'read write'
+ type BOOLEAN
+ count 2
[yocto] [PATCH 3/3] n450-audio: drop this machine specific recipe in favour of alsa-state
Signed-off-by: Joshua Lock j...@linux.intel.com
---
meta-n450/conf/machine/n450.conf |2 -
meta-n450/recipes-bsp/n450-audio/n450-audio.bb | 30 --
.../recipes-bsp/n450-audio/n450-audio/n450-audio | 42
3 files changed, 0 insertions(+), 74 deletions(-)
delete mode 100644 meta-n450/recipes-bsp/n450-audio/n450-audio.bb
delete mode 100644 meta-n450/recipes-bsp/n450-audio/n450-audio/n450-audio
diff --git a/meta-n450/conf/machine/n450.conf b/meta-n450/conf/machine/n450.conf
index 3e6a541..6ffdce9 100644
--- a/meta-n450/conf/machine/n450.conf
+++ b/meta-n450/conf/machine/n450.conf
@@ -14,5 +14,3 @@ XSERVER ?= ${XSERVER_IA32_BASE} \
SYSLINUX_OPTS = serial 0 115200
SERIAL_CONSOLE = 115200 ttyS0
APPEND += console=ttyS0,115200 console=tty0
-
-MACHINE_EXTRA_RRECOMMENDS += n450-audio
diff --git a/meta-n450/recipes-bsp/n450-audio/n450-audio.bb
b/meta-n450/recipes-bsp/n450-audio/n450-audio.bb
deleted file mode 100644
index 27904e3..000
--- a/meta-n450/recipes-bsp/n450-audio/n450-audio.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-SUMMARY = Provide a basic init script to enable audio
-DESCRIPTION = Set the volume and unmute the Front mixer setting during boot.
-SECTION = base
-LICENSE = MIT
-LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58
-
-PR = r4
-
-inherit update-rc.d
-
-RDEPENDS = alsa-utils-amixer
-
-SRC_URI = file://n450-audio
-
-INITSCRIPT_NAME = n450-audio
-INITSCRIPT_PARAMS = defaults 90
-
-do_install() {
- install -d ${D}${sysconfdir} \
- ${D}${sysconfdir}/init.d
- install -m 0755 ${WORKDIR}/n450-audio ${D}${sysconfdir}/init.d
-cat ${WORKDIR}/${INITSCRIPT_NAME} | \
-sed -e 's,/etc,${sysconfdir},g' \
--e 's,/usr/sbin,${sbindir},g' \
--e 's,/var,${localstatedir},g' \
--e 's,/usr/bin,${bindir},g' \
--e 's,/usr,${prefix},g'
${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
-chmod 755 ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
-}
-
diff --git a/meta-n450/recipes-bsp/n450-audio/n450-audio/n450-audio
b/meta-n450/recipes-bsp/n450-audio/n450-audio/n450-audio
deleted file mode 100644
index c5a0044..000
--- a/meta-n450/recipes-bsp/n450-audio/n450-audio/n450-audio
+++ /dev/null
@@ -1,42 +0,0 @@
-#!/bin/sh
-### BEGIN INIT INFO
-# Provides: n450 mixer setup
-# Required-Start:$syslog
-# Required-Stop: $syslog
-# Default-Start: 2 3 4 5
-# Default-Stop: 0 1 6
-# Short-Description: Initialize the n450 audio mixer
-# Description: Unmute FRONT and set volume to ~70%.
-### END INIT INFO
-
-# Author: Darren Hart dvh...@linux.intel.com
-# Based on /etc/init.d/skeleton
-
-PATH=/sbin:/usr/sbin:/bin:/usr/bin
-DESC=Audio mixer settings
-NAME=n450-audio
-AMIXER=`which amixer`
-SCRIPTNAME=/etc/init.d/$NAME
-
-# Exit if amixer is not installed
-[ -x $AMIXER ] || exit 0
-
-do_start() {
- # Enable the Front simple controls (black phones jack)
- $AMIXER sset Front 30 on /dev/null
-}
-
-case $1 in
-start)
- echo $NAME: setting default mixer settings.
- do_start
- ;;
-stop)
- ;;
-*)
- echo Usage: $SCRIPTNAME {start|stop} 2
- exit 3
- ;;
-esac
-
-exit 0
--
1.7.7.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, January 10, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada)
Attendees: Michael, Paul, Joshua, Saul, Darren, Matthew, Richard, Scott, Beth, Jessica, Jason (TI), Tom, Bruce, Mark, Denys, Jeff (WRS), Sean, Dave, Song Focus of the week: top priority is M2 stabilization and bug fixing. Continue with feature development. Action item: - Paul to work with Jeremy and others to move 1598 forward. (WIP) Agenda: * Opens collection - 5 min (Song) * Yocto 1.1.1 point release update - 10 min (Josh/Beth) - Late last night the build is out. Have all the fixes. One about HOB is not fixed, will be in the release note. CCB meeting in 2 hours. Joshua's branch will merge after CCB meeting. Doc string change are ready , Scott will need to run through the example after Beth gives the go-ahead. Beth can make that ready today. Scott does not need to re-verify after Josh's branch merges. * Yocto 1.2 M2 status - 10 min (Song/Bruce/Team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status - release date change from Feb. 3rd to 10th, everything else stays the same. - M2 code freeze already happened. We are in stabilization week. Top priority is to stabilize M2 build and bug fixing. - P1 features: HOB2 is in private branch, all M2 development is done. Richard has been reviewing patches. Have some comments, PRC team is working on them. ScottG's bitbake error handling feature will be handled by Richard and Paul. Richard has done some ground work. Will follow up with Scott and Paul on what and who for the next step. Package history (Paul) feature has made progress. Paul had discussions with Richard, we are ok with M2 delivery on this feature. There are some further work for M3 and possibly post 1.2. - We had less medium+ bug outstanding this week (91) compared with last week (108). Bug count is in control. Good progress from the team on bug fixing. * Opens - 10 min - Michael, worked at Intel on Yocto, now working for Linux foundation focusing on Yocto Project. background web side, small business, now working on upgrading Bugzilla and some virtualization, happy to work full time on Yocto. Will help with Shoeleather, available via IRC, email. - Song SWAT kickoff. Song has sent the email about the SWAT team to the yocto mailing list. SWAT team will be in position starting from this week. Either Darren or Beth will be the first rotating Chair person. - Mark: Cross pre-linker update - long standing bug (9 month), finally figured about the reason. Missing a check, sent out a patch to OE core already. Does not seem causing problems, does fix the problem. The fix should integrate by the end of the week. Now pre-linker works on all arch's except ppc64. * Action item Review - 5 min - Mark will review unsorted features from Wind River team and try to have them scheduled (WIP, Reviewed, some of them should be scheduled by WRS team. Song will follow up to double check. Drop this one from the list) - Song and Saul to follow on Scott Garman's M2 schedule conflict. (Richard and Paul will help, have a plan now.) - Paul to work with Jeremy and others to move 1598 forward. (WIP) - Paul to split feature 1566 (Song will follow up with Paul on this one, drop from the list) * Team Sharing Jeff - Nothing Denys - nothing Mark - Nothing beyond pre-link. Bruce - continue kernel update, testing qemu, ppc. Booted sato, having some trouble with cursors, should be completed soon. Tom - Coming back from vacation. Working on kernel usability tool, internal BSP stuff. Will continue these Jason - None Jessica - wrapped up for M2, staring to look at M3 items, need to sync with Tom tools. Beth - Working on M2. Scott - last week, 1.1.1 doc change. Beth set up some variables that simplified the doc release process. Scott will follow up with other work. 4-5 bugs addressed. Will continue on 1.1.1. Richard - catching up with backlogs from holidays, helping out on bitbake error handling. Working on bugs to improve user experience. We managed to keep the bug count in control. Matthew: not much, working on 1.1.1, will do Freedcale first release. Will help Joshua. Darren: some travel for internal projects. Functional poky-tiny in master now. Working on 3.2 kernel, a couple of BSPs, some support issues, swat team. Saul: bug fixing, patch reviewing, build, build fixing, thanks to the SWAT team. Joshua: looking at 1.1.1 now, fixing bugs and working on features. Paul: working on layers bugs, discussed with Mark. Resolving issues when flattening layers. Working on build history, data analysis. Will help error handling. Michael: learning and some ground stuff Sean: sending out proposal to mailing list: trying to have a monthly conference for developer discussion, architecture. Focusing on getting key releases done. Mentor would like to host it. Expand to OE-core and Yocto. This technical meeting is all Yocto. 2. advisory board, setting up developer day for ELC, we may be sending out something shortly. Feb 14. Mentor will be hosting BSP Summit, BSP in
Re: [yocto] [PATCH 0/3][meta-intel] Alsa enhancements
On Tue, 2012-01-10 at 09:39 -0800, Joshua Lock wrote: CAVEAT: This series requires the alsa-state series recently submitted to the OE-Core mailing list. Nice. Thanks for finally resolving this. When the other patches hit oe-core, I'll pull these in... Tom This series enables alsa as a MACHINE_FEATURE by default in the ia32-base so that alsa is enabled for all current BSP's. Following that the series drops the BSP-specific n450-audio recipe in favour of extending the common alsa-state recipe for alsa configuration. Note: the n450-audio recipe was not working in any stock image as alsa was not a listed MACHINE_FEATURE and the amixer package is not included by default. The following changes since commit 38f2b670bc37515bcb0fa7f98e338e5242d70386: meta-cedartrail: Create new layer for cedartrail System. (2012-01-09 17:55:07 -0600) are available in the git repository at: git://github.com/incandescant/meta-intel master https://github.com/incandescant/meta-intel/tree/master Joshua Lock (3): ia32-base: add alsa to MACHINE_FEATURES alsa-state: add alsa state for n450 n450-audio: drop this machine specific recipe in favour of alsa-state conf/machine/include/ia32-base.inc |2 +- meta-n450/conf/machine/n450.conf |2 - .../recipes-bsp/alsa-state/alsa-state.bbappend |1 + .../alsa-state/alsa-state/n450/asound.state| 450 meta-n450/recipes-bsp/n450-audio/n450-audio.bb | 30 -- .../recipes-bsp/n450-audio/n450-audio/n450-audio | 42 -- 6 files changed, 452 insertions(+), 75 deletions(-) create mode 100644 meta-n450/recipes-bsp/alsa-state/alsa-state.bbappend create mode 100644 meta-n450/recipes-bsp/alsa-state/alsa-state/n450/asound.state delete mode 100644 meta-n450/recipes-bsp/n450-audio/n450-audio.bb delete mode 100644 meta-n450/recipes-bsp/n450-audio/n450-audio/n450-audio ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch
On 12-01-02 02:31 PM, tom.zanu...@intel.com wrote: From: Tom Zanussitom.zanu...@intel.com This patchset adds a new yocto/emgd-1.10 feature branch to linux-yocto-3.0, alongside the existing yocto/emgd branch containing emgd-1.8. Bruce, please don't merge this yet though - it depends on the new emgd-1.10 recipe, which in turn depends on some new LICENSE_FLAGS functionality being merged. Will let you know when all that's taken care of and it's safe to pull this in. Just pinging. I assume these are safe to merge now ? Bruce Thanks, Tom The following changes since commit 6b4bf6173b0bd2d1619a8218bac66ebc4681dd35: Maurice Ma (1): x86, efi: Convert efi_phys_get_time() args to physical addresses are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0 Tom Zanussi (2): yocto/emgd: emgd 1.10 driver yocto/emgd: initial build fixups drivers/gpu/drm/Kconfig|9 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/emgd/Makefile | 294 + drivers/gpu/drm/emgd/emgd/cfg/config.h | 113 + drivers/gpu/drm/emgd/emgd/cfg/config_default.h | 198 + drivers/gpu/drm/emgd/emgd/cfg/config_helper.c | 244 + .../gpu/drm/emgd/emgd/core/init/cmn/igd_global.c | 34 + drivers/gpu/drm/emgd/emgd/core/init/cmn/igd_init.c | 918 +++ .../drm/emgd/emgd/core/init/cmn/init_dispatch.h| 65 + drivers/gpu/drm/emgd/emgd/core/init/plb/init_plb.c | 458 ++ .../drm/emgd/emgd/core/init/plb/micro_init_plb.c | 631 ++ drivers/gpu/drm/emgd/emgd/core/init/tnc/init_tnc.c | 621 ++ .../drm/emgd/emgd/core/init/tnc/micro_init_tnc.c | 992 +++ drivers/gpu/drm/emgd/emgd/display/dsp/cmn/dsp.c| 2368 +++ .../drm/emgd/emgd/display/dsp/cmn/dsp_dispatch.h | 64 + .../gpu/drm/emgd/emgd/display/dsp/plb/dsp_plb.c| 709 ++ .../gpu/drm/emgd/emgd/display/dsp/tnc/dsp_tnc.c| 542 ++ .../gpu/drm/emgd/emgd/display/mode/cmn/igd_mode.c | 2219 +++ drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.c | 1347 drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.h | 59 + .../drm/emgd/emgd/display/mode/cmn/micro_mode.c| 1744 + .../drm/emgd/emgd/display/mode/cmn/mode_dispatch.h | 383 ++ .../gpu/drm/emgd/emgd/display/mode/cmn/vga_mode.c | 1467 + .../drm/emgd/emgd/display/mode/plb/clocks_plb.c| 701 ++ .../drm/emgd/emgd/display/mode/plb/kms_mode_plb.c | 1102 .../emgd/emgd/display/mode/plb/micro_mode_plb.c| 1372 .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.c | 1932 ++ .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.h | 47 + .../drm/emgd/emgd/display/mode/tnc/clocks_tnc.c| 1180 .../drm/emgd/emgd/display/mode/tnc/kms_mode_tnc.c | 1721 + .../emgd/emgd/display/mode/tnc/micro_mode_tnc.c| 2643 .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.c | 1997 ++ .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.h | 52 + drivers/gpu/drm/emgd/emgd/display/pd/cmn/pd.c | 516 ++ .../gpu/drm/emgd/emgd/display/pi/cmn/displayid.c | 1058 +++ drivers/gpu/drm/emgd/emgd/display/pi/cmn/edid.c| 1187 .../drm/emgd/emgd/display/pi/cmn/i2c_dispatch.h| 78 + drivers/gpu/drm/emgd/emgd/display/pi/cmn/igd_pi.c | 260 + .../gpu/drm/emgd/emgd/display/pi/cmn/mode_table.c | 2545 .../gpu/drm/emgd/emgd/display/pi/cmn/pd_init_all.c | 215 + drivers/gpu/drm/emgd/emgd/display/pi/cmn/pi.c | 1883 ++ drivers/gpu/drm/emgd/emgd/display/pi/plb/i2c_plb.c | 940 +++ .../drm/emgd/emgd/display/pi/tnc/i2c_bitbash_tnc.c | 599 ++ .../drm/emgd/emgd/display/pi/tnc/i2c_gmbus_tnc.c | 929 +++ drivers/gpu/drm/emgd/emgd/drm/drm_emgd_private.h | 167 + drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c | 512 ++ drivers/gpu/drm/emgd/emgd/drm/emgd_crtc.c | 1004 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c | 2399 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_drv.h | 199 + drivers/gpu/drm/emgd/emgd/drm/emgd_encoder.c | 474 ++ drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c| 1403 drivers/gpu/drm/emgd/emgd/drm/emgd_fbcon.c | 801 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_interface.c | 2583 drivers/gpu/drm/emgd/emgd/drm/emgd_mmap.c | 186 + drivers/gpu/drm/emgd/emgd/drm/emgd_test_pvrsrv.c | 1365 drivers/gpu/drm/emgd/emgd/drm/image_data.h | 33 + drivers/gpu/drm/emgd/emgd/drm/splash_screen.c | 2221 +++ drivers/gpu/drm/emgd/emgd/drm/splash_screen.h | 280 + drivers/gpu/drm/emgd/emgd/drm/user_config.c| 252 + drivers/gpu/drm/emgd/emgd/drm/user_config.h| 113 + drivers/gpu/drm/emgd/emgd/gmm/gmm.c| 1005 +++
Re: [yocto] [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch
On Tue, 2012-01-10 at 15:50 -0500, Bruce Ashfield wrote: On 12-01-02 02:31 PM, tom.zanu...@intel.com wrote: From: Tom Zanussitom.zanu...@intel.com This patchset adds a new yocto/emgd-1.10 feature branch to linux-yocto-3.0, alongside the existing yocto/emgd branch containing emgd-1.8. Bruce, please don't merge this yet though - it depends on the new emgd-1.10 recipe, which in turn depends on some new LICENSE_FLAGS functionality being merged. Will let you know when all that's taken care of and it's safe to pull this in. Just pinging. I assume these are safe to merge now ? No, LICENSE_FLAGS has hit another snag - until that's in we can't pull in the emgd-1.10 recipe, and therefore can't pull the 1.10 kernel bits in either... Tom Bruce Thanks, Tom The following changes since commit 6b4bf6173b0bd2d1619a8218bac66ebc4681dd35: Maurice Ma (1): x86, efi: Convert efi_phys_get_time() args to physical addresses are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0 Tom Zanussi (2): yocto/emgd: emgd 1.10 driver yocto/emgd: initial build fixups drivers/gpu/drm/Kconfig|9 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/emgd/Makefile | 294 + drivers/gpu/drm/emgd/emgd/cfg/config.h | 113 + drivers/gpu/drm/emgd/emgd/cfg/config_default.h | 198 + drivers/gpu/drm/emgd/emgd/cfg/config_helper.c | 244 + .../gpu/drm/emgd/emgd/core/init/cmn/igd_global.c | 34 + drivers/gpu/drm/emgd/emgd/core/init/cmn/igd_init.c | 918 +++ .../drm/emgd/emgd/core/init/cmn/init_dispatch.h| 65 + drivers/gpu/drm/emgd/emgd/core/init/plb/init_plb.c | 458 ++ .../drm/emgd/emgd/core/init/plb/micro_init_plb.c | 631 ++ drivers/gpu/drm/emgd/emgd/core/init/tnc/init_tnc.c | 621 ++ .../drm/emgd/emgd/core/init/tnc/micro_init_tnc.c | 992 +++ drivers/gpu/drm/emgd/emgd/display/dsp/cmn/dsp.c| 2368 +++ .../drm/emgd/emgd/display/dsp/cmn/dsp_dispatch.h | 64 + .../gpu/drm/emgd/emgd/display/dsp/plb/dsp_plb.c| 709 ++ .../gpu/drm/emgd/emgd/display/dsp/tnc/dsp_tnc.c| 542 ++ .../gpu/drm/emgd/emgd/display/mode/cmn/igd_mode.c | 2219 +++ drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.c | 1347 drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.h | 59 + .../drm/emgd/emgd/display/mode/cmn/micro_mode.c| 1744 + .../drm/emgd/emgd/display/mode/cmn/mode_dispatch.h | 383 ++ .../gpu/drm/emgd/emgd/display/mode/cmn/vga_mode.c | 1467 + .../drm/emgd/emgd/display/mode/plb/clocks_plb.c| 701 ++ .../drm/emgd/emgd/display/mode/plb/kms_mode_plb.c | 1102 .../emgd/emgd/display/mode/plb/micro_mode_plb.c| 1372 .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.c | 1932 ++ .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.h | 47 + .../drm/emgd/emgd/display/mode/tnc/clocks_tnc.c| 1180 .../drm/emgd/emgd/display/mode/tnc/kms_mode_tnc.c | 1721 + .../emgd/emgd/display/mode/tnc/micro_mode_tnc.c| 2643 .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.c | 1997 ++ .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.h | 52 + drivers/gpu/drm/emgd/emgd/display/pd/cmn/pd.c | 516 ++ .../gpu/drm/emgd/emgd/display/pi/cmn/displayid.c | 1058 +++ drivers/gpu/drm/emgd/emgd/display/pi/cmn/edid.c| 1187 .../drm/emgd/emgd/display/pi/cmn/i2c_dispatch.h| 78 + drivers/gpu/drm/emgd/emgd/display/pi/cmn/igd_pi.c | 260 + .../gpu/drm/emgd/emgd/display/pi/cmn/mode_table.c | 2545 .../gpu/drm/emgd/emgd/display/pi/cmn/pd_init_all.c | 215 + drivers/gpu/drm/emgd/emgd/display/pi/cmn/pi.c | 1883 ++ drivers/gpu/drm/emgd/emgd/display/pi/plb/i2c_plb.c | 940 +++ .../drm/emgd/emgd/display/pi/tnc/i2c_bitbash_tnc.c | 599 ++ .../drm/emgd/emgd/display/pi/tnc/i2c_gmbus_tnc.c | 929 +++ drivers/gpu/drm/emgd/emgd/drm/drm_emgd_private.h | 167 + drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c | 512 ++ drivers/gpu/drm/emgd/emgd/drm/emgd_crtc.c | 1004 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c | 2399 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_drv.h | 199 + drivers/gpu/drm/emgd/emgd/drm/emgd_encoder.c | 474 ++ drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c| 1403 drivers/gpu/drm/emgd/emgd/drm/emgd_fbcon.c | 801 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_interface.c | 2583 drivers/gpu/drm/emgd/emgd/drm/emgd_mmap.c | 186 + drivers/gpu/drm/emgd/emgd/drm/emgd_test_pvrsrv.c | 1365
Re: [yocto] [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch
On 12-01-10 03:55 PM, Tom Zanussi wrote: On Tue, 2012-01-10 at 15:50 -0500, Bruce Ashfield wrote: On 12-01-02 02:31 PM, tom.zanu...@intel.com wrote: From: Tom Zanussitom.zanu...@intel.com This patchset adds a new yocto/emgd-1.10 feature branch to linux-yocto-3.0, alongside the existing yocto/emgd branch containing emgd-1.8. Bruce, please don't merge this yet though - it depends on the new emgd-1.10 recipe, which in turn depends on some new LICENSE_FLAGS functionality being merged. Will let you know when all that's taken care of and it's safe to pull this in. Just pinging. I assume these are safe to merge now ? No, LICENSE_FLAGS has hit another snag - until that's in we can't pull in the emgd-1.10 recipe, and therefore can't pull the 1.10 kernel bits in either... ok. no worries at all. I was wondering if I missed the update. No rush, I'll be able to merge this when it's ready. Bruce Tom Bruce Thanks, Tom The following changes since commit 6b4bf6173b0bd2d1619a8218bac66ebc4681dd35: Maurice Ma (1): x86, efi: Convert efi_phys_get_time() args to physical addresses are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0 Tom Zanussi (2): yocto/emgd: emgd 1.10 driver yocto/emgd: initial build fixups drivers/gpu/drm/Kconfig|9 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/emgd/Makefile | 294 + drivers/gpu/drm/emgd/emgd/cfg/config.h | 113 + drivers/gpu/drm/emgd/emgd/cfg/config_default.h | 198 + drivers/gpu/drm/emgd/emgd/cfg/config_helper.c | 244 + .../gpu/drm/emgd/emgd/core/init/cmn/igd_global.c | 34 + drivers/gpu/drm/emgd/emgd/core/init/cmn/igd_init.c | 918 +++ .../drm/emgd/emgd/core/init/cmn/init_dispatch.h| 65 + drivers/gpu/drm/emgd/emgd/core/init/plb/init_plb.c | 458 ++ .../drm/emgd/emgd/core/init/plb/micro_init_plb.c | 631 ++ drivers/gpu/drm/emgd/emgd/core/init/tnc/init_tnc.c | 621 ++ .../drm/emgd/emgd/core/init/tnc/micro_init_tnc.c | 992 +++ drivers/gpu/drm/emgd/emgd/display/dsp/cmn/dsp.c| 2368 +++ .../drm/emgd/emgd/display/dsp/cmn/dsp_dispatch.h | 64 + .../gpu/drm/emgd/emgd/display/dsp/plb/dsp_plb.c| 709 ++ .../gpu/drm/emgd/emgd/display/dsp/tnc/dsp_tnc.c| 542 ++ .../gpu/drm/emgd/emgd/display/mode/cmn/igd_mode.c | 2219 +++ drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.c | 1347 drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.h | 59 + .../drm/emgd/emgd/display/mode/cmn/micro_mode.c| 1744 + .../drm/emgd/emgd/display/mode/cmn/mode_dispatch.h | 383 ++ .../gpu/drm/emgd/emgd/display/mode/cmn/vga_mode.c | 1467 + .../drm/emgd/emgd/display/mode/plb/clocks_plb.c| 701 ++ .../drm/emgd/emgd/display/mode/plb/kms_mode_plb.c | 1102 .../emgd/emgd/display/mode/plb/micro_mode_plb.c| 1372 .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.c | 1932 ++ .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.h | 47 + .../drm/emgd/emgd/display/mode/tnc/clocks_tnc.c| 1180 .../drm/emgd/emgd/display/mode/tnc/kms_mode_tnc.c | 1721 + .../emgd/emgd/display/mode/tnc/micro_mode_tnc.c| 2643 .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.c | 1997 ++ .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.h | 52 + drivers/gpu/drm/emgd/emgd/display/pd/cmn/pd.c | 516 ++ .../gpu/drm/emgd/emgd/display/pi/cmn/displayid.c | 1058 +++ drivers/gpu/drm/emgd/emgd/display/pi/cmn/edid.c| 1187 .../drm/emgd/emgd/display/pi/cmn/i2c_dispatch.h| 78 + drivers/gpu/drm/emgd/emgd/display/pi/cmn/igd_pi.c | 260 + .../gpu/drm/emgd/emgd/display/pi/cmn/mode_table.c | 2545 .../gpu/drm/emgd/emgd/display/pi/cmn/pd_init_all.c | 215 + drivers/gpu/drm/emgd/emgd/display/pi/cmn/pi.c | 1883 ++ drivers/gpu/drm/emgd/emgd/display/pi/plb/i2c_plb.c | 940 +++ .../drm/emgd/emgd/display/pi/tnc/i2c_bitbash_tnc.c | 599 ++ .../drm/emgd/emgd/display/pi/tnc/i2c_gmbus_tnc.c | 929 +++ drivers/gpu/drm/emgd/emgd/drm/drm_emgd_private.h | 167 + drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c | 512 ++ drivers/gpu/drm/emgd/emgd/drm/emgd_crtc.c | 1004 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c | 2399 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_drv.h | 199 + drivers/gpu/drm/emgd/emgd/drm/emgd_encoder.c | 474 ++ drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c| 1403 drivers/gpu/drm/emgd/emgd/drm/emgd_fbcon.c | 801 +++ drivers/gpu/drm/emgd/emgd/drm/emgd_interface.c | 2583 drivers/gpu/drm/emgd/emgd/drm/emgd_mmap.c | 186 +
Re: [yocto] Yocto SWAT team kickoff
On Tue, Jan 10, 2012 at 7:24 AM, Liu, Song song@intel.com wrote: Hi all, We would like to kick off the Yocto SWAT team this week. Please see the following for the purpose of the SWAT team and let me know if you have any questions or concerns. We welcome any community participation on the SWAT team. At the same time, I will work with the team to make sure thing get started. Thanks, Song YOCTO SWAT TEAM GOAL The assembly of the Yocto Project SWAT team is mainly to tackle urgent technical problems that break build on the master branch or major release branches in a timely manner, thus to maintain the stability of the master and release branch. The SWAT team includes volunteers or appointed members of the Yocto Project team. Community members can also volunteer to be part of the SWAT team. SCOPE OF RESPONSIBILITY Whenever a build (nightly build, weekly build, release build) fails, the SWAT team is responsible for ensuring the necessary debugging occurs and organizing resources to solve the issue and ensure successful builds. If resolving the issues requires schedule or resource adjustment, the SWAT team should work with program and development management to accommodate the change in the overall planning. MEMBERS: * Darren Hart (US) * Elizabeth Flanagan (US) * Paul Eggleton (UK) * Jessica Zhang (US) * Dexuan Cui (CN) * Saul Wold (US) * Richard Purdie (UK) ROTATING CHAIR: A chairperson role will be rotated among team members each week. The Chairperson should monitor the build status for the entire week. Whenever a build is broken, the Chairperson should do necessary debugging and organize resources to solve the problems in a timely manner to meet the overall project and release schedule. The Chairperson serves as the focal point of the SWAT team to external people such as program managers or development managers. ROTATING PROCESS Each week on a specific day (propose Monday), a SWAT team meeting could be called at the chairperson's discretion to discuss current issues and status. Either during the meeting or offline, the Chairperson of last week will identify and pass the role to another person in the team. The program manager should be notified at the same time. Usually, this will take a simple round robin order. In case the next person cannot take the role due to tight schedule, vacation or some other reasons, the role will be passed to the next person. The current Chairperson's full name and email address will be published on the project status wiki page: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status under Current SWAT team Chairperson section. BKM (RICHARD PURDIE) When looking at a failure, the first question is what the baseline was and what changed. If there were recent known good builds it helps to narrow down the number of changes that were likely responsible for the failure. It's also useful to note if the build was from scratch or from existing sstate files. You can tell by seeing what setscene tasks run in the log. The primary responsibility is to ensure that any failures are categorized correctly and that the right people get to know about them. It's important *someone* is then tasked with fixing it. Image failures are particular tricky since its likely some component of the image that failed and the question is then whether that component changed recently, whether it was some kind of core functionality at fault and so on. Ideally we want to get the failure reported to the person who knows something about the area and can come up with a fix without it distracting them too much. As a secondary responsibility, its often helpful for to triage the failure. This might mean documenting a way to reproduce the failure outside a full build and/or documenting how the failure is happening and maybe even propose a fix. Sometimes failures are difficult to understand and can require direct ssh access to the autobuilder so the issue can be debugged passively on the system to examine contents of files and so forth. If doing this ensure you don't change any of the file system for example adding files that couldn't then be deleted by the autobuilder when it rebuilds. It is actually best for people to copy log files and the like to a private place. As the autobuilder runs 24/7 you do not want to run the risk of having work removed in the middle. Keep in mind, however, that while we are not particularly space constrained at the moment, it is best if people are diligent about cleaning up after themselves. Rarely, live debugging might be needed where you'd su to the pokybuild user and run a build manually to see the failure in real time. If doing this, ensure you only create files as the pokybuild user and you are careful not to generate sstate packages which shouldn't be present or any other bad state that might get reused. In general its recommended
Re: [yocto] [PATCH 1/4] lttng-ust: Integrate into yocto linux
于 2012年01月11日 00:58, Darren Hart 写道:
On 01/10/2012 08:11 AM, Zumeng Chen wrote:
This patch intended to integrate the LTTng UST 2.0 package, which
contains the userspace tracer library to trace userspace codes.
Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
---
meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb | 25 ++
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
diff --git a/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
b/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
new file mode 100644
index 000..846019e
--- /dev/null
+++ b/meta/recipes-kernel/lttng-2.0/lttng-ust_1.9.4.bb
@@ -0,0 +1,25 @@
+SUMMARY = Linux Trace Toolkit Userspace Tracer 2.0
+DESCRIPTION = The LTTng UST 2.0 package contains the userspace tracer library to
trace userspace codes.
+HOMEPAGE = http://lttng.org/lttng2.0;
+BUGTRACKER = n/a
+
+LICENSE = LGPLv2.1+ BSD
+LIC_FILES_CHKSUM = file://COPYING;md5=e647752e045a8c45b6f583771bd561ef \
+
file://snprintf/snprintf.c;endline=32;md5=d3d544959d8a3782b2e07451be0a903c \
+
file://snprintf/various.h;endline=31;md5=89f2509b6b4682c4fc95255eec4abe44
+
+inherit autotools
+
+DEPENDS = liburcu util-linux
+
+SRC_URI = http://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.gz;
+
+SRC_URI[md5sum] = 0f09bb954c99cb99ab6997cd492953c1
+SRC_URI[sha256sum] =
e9ec3c55c2251b3f3b512bfa1015b0f67e35d55793850ccea5134f7b24ee3ba1
+
+S = ${WORKDIR}/lttng-ust-${PV}
+
+# Due to liburcu not building on MIPS currently this recipe needs to
+# be limited also.
+# So here let us first suppport x86/arm/powerpc platforms now.
+COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-linux'
We had discussed using a different comment that more clearly stated why
this is necessary and use the same comment across all the patches
implementing this.
This applies to all 4 patches. The suggestion was in my response to
Patch 1/4 V1:
Oops, sorry Darren, all fixed and really soon for V4 on OE :-)
Regards,
Zumeng
Looking through documentation.conf and existing poky sources, I believe
this test is correct. HOST/TARGET are the same in this case. The comment
is a bit confusing however. I believe the comment should read:
# liburcu doesn't build for MIPS
COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*)-linux'
The key difference being for instead of on. The rest of the comment
is redundant with the assignment itself. This applies to all 4 patches.
Otherwise, things look good.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] hob usage
I have a question about hob usage. I understand the basics of hob and how it adds packages. I also understand how it will parse through my local.conf and include any extra packages that I may have included by using IMAGE_INSTALL += package. I've found that if I start with a clean BSP and use hob to add a package, it will allow me to save that configuration anywhere. I'm not sure where I should save it. It contains the IMAGE_INSTALL for the packages I've selected, but is also includes a 'require' statement, which seems to have a relative path, like: require recipes-sato/images/core-image-sato.bb Where is the location I should save the hob configuration file? I know that if I save it outside my poky directory, the package will not be included, so it's important where it goes. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] hob usage
On Tue, Jan 10, 2012 at 9:56 PM, Jim Abernathy jfaberna...@gmail.com wrote: I have a question about hob usage. I understand the basics of hob and how it adds packages. I also understand how it will parse through my local.conf and include any extra packages that I may have included by using IMAGE_INSTALL += package. I've found that if I start with a clean BSP and use hob to add a package, it will allow me to save that configuration anywhere. I'm not sure where I should save it. It contains the IMAGE_INSTALL for the packages I've selected, but is also includes a 'require' statement, which seems to have a relative path, like: require recipes-sato/images/core-image-sato.bb Where is the location I should save the hob configuration file? I know that if I save it outside my poky directory, the package will not be included, so it's important where it goes. This is one of those quirks about hob I found weird. I filed a bug about this: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1573 In general you need to save it somewhere one of your layers looks for additional recipes to run it from the command line. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Request to enable SMP and virtio for qemux86/x86-64
Bruce,
Can we enable SMP and virtio by default for qemux86/x86-64? This can achieve
huge perf boost for workload inside qemu. E.g. we enabled self-hosted image,
where we build yocto inside qemu.
Attached patch showes the kernel config option.
Is it reasonable?
Thanks,
Edwin
--
best rgds,
edwin
commit 8f2268237c5cb97052c2c9a6ea6c0f818d1a658d
Author: gzhai gzhai@gzhai-xps.(none)
Date: Fri Dec 9 10:32:50 2011 +0800
linux-yocto: enable smp for qemux86
Signed-off-by: None None
diff --git a/meta/recipes-kernel/linux/linux-yocto/extra.cfg b/meta/recipes-kernel/linux/linux-yocto/extra.cfg
new file mode 100644
index 000..efe1d9b
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto/extra.cfg
@@ -0,0 +1,7 @@
+CONFIG_SMP=y
+CONFIG_VIRTIO=y
+CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_BALLOON=y
+CONFIG_VIRTIO_RING=y
+CONFIG_VIRTIO_NET=y
+CONFIG_VIRTIO_BLK=y
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
index 4032567..850310a 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
@@ -20,11 +20,13 @@ SRCREV_machine_qemux86-64 ?= 988fcbe64829f0a03ccfcc08d45cedb26cabe9ed
SRCREV_machine ?= ab1de8c21d2b1d084b8488496d75cc54fcd94f02
SRCREV_meta ?= 67ce7623909cef63927fd145026aaf371cf4abf1
-PR = r2
+PR = r3
PV = ${LINUX_VERSION}+git${SRCPV}
SRC_URI = git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
+SRC_URI += file://extra.cfg
+
COMPATIBLE_MACHINE = (qemuarm|qemux86|qemuppc|qemumips|qemux86-64)
# Functionality flags
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
