[oe] [PATCH V2] sdcc-native: Add bison-native and flex-native to DEPENDS
* configure script was giving error Cannot find required program bison. and
Cannot find required program flex.. So added bison-native and flex-native to
DEPENDS list.
* Bump PR to r1.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
recipes/sdcc/sdcc-native_2.8.0.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/recipes/sdcc/sdcc-native_2.8.0.bb
b/recipes/sdcc/sdcc-native_2.8.0.bb
index 60cebbe..ace693f 100644
--- a/recipes/sdcc/sdcc-native_2.8.0.bb
+++ b/recipes/sdcc/sdcc-native_2.8.0.bb
@@ -1,5 +1,6 @@
require sdcc_${PV}.bb
-DEPENDS =
+DEPENDS = bison-native flex-native
+PR = r1
# don't need native-tools patch here
SRC_URI = ${SOURCEFORGE_MIRROR}/sdcc/sdcc-src-${PV}.tar.bz2 \
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH V2] sdcc-native: convert to new style staging, remove 'do_stage()'
* Remove do_stage() function from the recipe. do_install function of
autotools.bbclass replaces the do-stage function of the recipe.
* Bump PR to r2
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
recipes/sdcc/sdcc-native_2.8.0.bb |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/recipes/sdcc/sdcc-native_2.8.0.bb
b/recipes/sdcc/sdcc-native_2.8.0.bb
index ace693f..1cecef0 100644
--- a/recipes/sdcc/sdcc-native_2.8.0.bb
+++ b/recipes/sdcc/sdcc-native_2.8.0.bb
@@ -1,6 +1,6 @@
require sdcc_${PV}.bb
DEPENDS = bison-native flex-native
-PR = r1
+PR = r2
# don't need native-tools patch here
SRC_URI = ${SOURCEFORGE_MIRROR}/sdcc/sdcc-src-${PV}.tar.bz2 \
@@ -8,7 +8,3 @@ SRC_URI = ${SOURCEFORGE_MIRROR}/sdcc/sdcc-src-${PV}.tar.bz2 \
inherit native
-do_stage() {
-oe_runmake install
-}
-
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] alsa-utils failure
On Mon, Aug 16, 2010 at 10:21:02PM -0700, Khem Raj wrote: On (17/08/10 07:03), Martin Jansa wrote: On Mon, Aug 16, 2010 at 07:20:23PM -0700, Philip Balister wrote: At least one other person is seeing this. Mine is on a clean build on a new F13 machine. Any thoughts? It's calling ncurses-config from your host which returns also -ltinfo. heh you beat me to it. I was about to ask for ncurses5-config --libs output on f13 :) but yes thats precisely the problem Default ncurses in OE (5.4) doesn't have ncurses-config. It will build ok with 5.7 or you have to update configure to ignore ncurses-config from host. why dont we make 5.7 default for ncurses ? I would like to, it seems working well in SHR, only needs few PR bumps (as lot of stuff was linked agains ncurses package and now it's splitted to libncurses5 etc. And ie mc is now linked only to libtinfo. Enrico did good jub with 5.7, if someone sends patch with PR bumps (again) and drops D_P = -1 or even removal of 5.4 I'll definetely ACK it. Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] rootfs_ipk.bbclass: remove host's lists in /var/lib/opkg/*
On Tue, Aug 17, 2010 at 09:47:55AM +0930, Graham Gower wrote:
Signed-off-by: Graham Gower graham.go...@gmail.com
Acked-by: Martin Jansa martin.ja...@gmail.com
---
classes/rootfs_ipk.bbclass |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/classes/rootfs_ipk.bbclass b/classes/rootfs_ipk.bbclass
index db04fb6..915e3d7 100644
--- a/classes/rootfs_ipk.bbclass
+++ b/classes/rootfs_ipk.bbclass
@@ -98,15 +98,19 @@ fakeroot rootfs_ipk_do_rootfs () {
else
rm -f ${IMAGE_ROOTFS}${libdir}/opkg/lists/*
fi
-
+
+ # Remove lists, but leave SHR's tmp dir if it exists.
+ rm -f ${IMAGE_ROOTFS}/var/lib/opkg/* || true
+
# Keep these lines until package manager selection is
implemented
ln -s opkg ${IMAGE_ROOTFS}${sysconfdir}/ipkg
ln -s opkg ${IMAGE_ROOTFS}${libdir}/ipkg
else
rm -rf ${IMAGE_ROOTFS}${libdir}/opkg
rm -rf ${IMAGE_ROOTFS}/usr/lib/opkg
+ rm -rf ${IMAGE_ROOTFS}/var/lib/opkg
fi
-
+
log_check rootfs
rm -rf ${IPKG_TMP_DIR}
}
--
1.7.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] sgmlspl-native: convert to new style staging, remove do_stage()
* Remove do_stage() from the recipe. The cpan_do_install () replaces the
do_stage () of the recipe.
* Bump PR to r1
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
recipes/sgmlspl/sgmlspl-native_1.03ii.bb |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/recipes/sgmlspl/sgmlspl-native_1.03ii.bb
b/recipes/sgmlspl/sgmlspl-native_1.03ii.bb
index 36bb366..0a4cd12 100644
--- a/recipes/sgmlspl/sgmlspl-native_1.03ii.bb
+++ b/recipes/sgmlspl/sgmlspl-native_1.03ii.bb
@@ -2,6 +2,7 @@ DESCRIPTION = A simple post-processor for SGMLS and NSGMLS
HOMEPAGE =
http://search.cpan.org/src/DMEGG/SGMLSpm-1.03ii/DOC/HTML/SGMLSpm/sgmlspm.html;
SECTION = libs
LICENSE = GPL
+PR = r1
SRC_URI = http://www.cpan.org/authors/id/D/DM/DMEGG/SGMLSpm-${PV}.tar.gz \
file://combined.patch
@@ -10,14 +11,6 @@ S = ${WORKDIR}/SGMLSpm
inherit native cpan
-do_install() {
- :
-}
-
-do_stage() {
- oe_runmake install_vendor
-}
-
PACKAGES = ${PN}-dbg
SRC_URI[md5sum] = 5bcb197fd42e67d51c739b1414d514a7
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] openssl: update 1.0.0 to 1.0.0a
В сообщении от Понедельник 16 августа 2010 23:35:59 автор Khem Raj написал: IMO the newest version in a recipe should always be default preference this way we can stabilize recipe upgrades quicker. This also means a wider testing before pushing a new recipe DEFAULT_PREFERENCE = -1 makes it to escape the testing. Well, consider Perl, for example. Making 5.10.1 a default preference would break binary packaged perl modules built for 5.8.8, so technically some massive PR bump (most probably DISTRO_PR) is needed when updating to 5.10.1. Forcing distro maintainers to do that is not nice, IMO. Although the way it is now Perl 5.10.1 seems to be rarely used, which is also not nice. Probably, there is no way to solve this problem for everyone. With D_P it's not used much, removing D_P is asking for YOU BROKE MY BUILD!!! love messages from random corners. -- http://roman.khimov.ru mailto: ro...@khimov.ru gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3 signature.asc Description: This is a digitally signed message part. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] bison: add flex dependency
2010/8/16 Jason Kridner jkrid...@beagleboard.org:
It seems that bison was missing this dependency. I'm not 100% certain this
is the right way to add it, so I'm leaving off my signed-off-by in hopes that
someone will ack this who really knows.
---
recipes/bison/bison.inc | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes/bison/bison.inc b/recipes/bison/bison.inc
index 22672e2..d32f454 100644
--- a/recipes/bison/bison.inc
+++ b/recipes/bison/bison.inc
@@ -3,12 +3,12 @@ HOMEPAGE = http://www.gnu.org/software/bison/;
LICENSE = GPL
SECTION = devel
PRIORITY = optional
-DEPENDS = virtual/libintl
+DEPENDS = virtual/libintl virtual/flex
SRC_URI = ${GNU_MIRROR}/bison/bison-${PV}.tar.gz \
file://m4.patch
-INC_PR = r7
+INC_PR = r8
inherit autotools gettext
--
It is my impression that virtual is only to be used if there can be
different packages acting as source (so different providers) (e.g. for
gcc, libc, u-boot, kernel etc)
AFAIK that is not the case for flex so I would just have written
DEPENDS = virtual/libintl flex-native
Anyway, I peeked in the code and I can confirm that a dependency on
flex exists. This went unnoticed until now as normally flex was
already dragged in by another package.
Either the change from Jason or the line I give above can have my ack.
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] openssl: update 1.0.0 to 1.0.0a
On Tue, Aug 17, 2010 at 10:50:13AM +0400, Roman I Khimov wrote: В сообщении от Понедельник 16 августа 2010 23:35:59 автор Khem Raj написал: IMO the newest version in a recipe should always be default preference this way we can stabilize recipe upgrades quicker. This also means a wider testing before pushing a new recipe DEFAULT_PREFERENCE = -1 makes it to escape the testing. Well, consider Perl, for example. Making 5.10.1 a default preference would break binary packaged perl modules built for 5.8.8, so technically some massive PR bump (most probably DISTRO_PR) is needed when updating to 5.10.1. Forcing distro maintainers to do that is not nice, IMO. But if you drop D_P globally you can bump PR of depending packages just once. If distro maintainders add P_V_perl = 5.10.1 one by one, then we'll have multiple PR bumps. Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] openssl: update 1.0.0 to 1.0.0a
2010/8/17 Roman I Khimov ro...@khimov.ru: В сообщении от Понедельник 16 августа 2010 23:35:59 автор Khem Raj написал: IMO the newest version in a recipe should always be default preference this way we can stabilize recipe upgrades quicker. This also means a wider testing before pushing a new recipe DEFAULT_PREFERENCE = -1 makes it to escape the testing. Well, consider Perl, for example. Making 5.10.1 a default preference would break binary packaged perl modules built for 5.8.8, so technically some massive PR bump (most probably DISTRO_PR) is needed when updating to 5.10.1. Forcing distro maintainers to do that is not nice, IMO. Although the way it is now Perl 5.10.1 seems to be rarely used, which is also not nice. Probably, there is no way to solve this problem for everyone. With D_P it's not used much, removing D_P is asking for YOU BROKE MY BUILD!!! love messages from random corners. We really need a mechanism that takes changes of all lower versions into account. This has been discussed before. I seem to recall that RP had some ideas on that. Removing D_P is not too nice for the reasons you specify (and bumping DISTRO_PR for all distro's in unison is hard too (and some distro's do not seem to be that acive). A distro could decide to go there on its own by pinning to 5.10.1 and do a DISTRO_PR bump. It would already help if the major distro's did this. Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] evince_2.30.0.bb: Problem with new style staging?
Am Sonntag, den 15.08.2010, 20:45 +0200 schrieb Paul Menzel:
Am Sonntag, den 15.08.2010, 10:46 +0200 schrieb Paul Menzel:
I set up a basic build host with no GNOME installed and did `bitbake
beagleboard-demo-image` with the standard local.conf provided by
Ȧngström and org.openembedded.dev.
Compile is failing because it is looking for a file on the build hosts
environment (and not stagang(?)).
xsltproc -o evince-C.omf --stringparam db2omf.basename evince
--stringparam db2omf.format 'docbook' --stringparam db2omf.dtd
-//OASIS//DTD DocBook XML V4.1.2//EN --stringparam db2omf.lang C
--stringparam db2omf.omf_dir /usr/share/omf --stringparam db2omf.help_dir
/usr/share/gnome/help --stringparam db2omf.omf_in
/home/paul/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/evince-2.30.0-r1/evince-2.30.0/help/evince.omf.in
`/home/paul/oe/build/angstrom-dev/sysroots/i686-linux/usr/bin/pkg-config
--variable db2omf gnome-doc-utils` C/evince.xml || { rm -f evince-C.omf;
exit 1; }
warning: failed to load external entity
/usr/share/xml/gnome/xslt/docbook/omf/db2omf.xsl
cannot parse /usr/share/xml/gnome/xslt/docbook/omf/db2omf.xsl
make[2]: *** [evince-C.omf] Error 1
make[2]: Leaving directory
`/home/paul/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/evince-2.30.0-r1/evince-2.30.0/help'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/paul/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/evince-2.30.0-r1/evince-2.30.0'
make: *** [all] Error 2
FATAL: oe_runmake failed
ERROR: Function do_compile failed
The call of `xsltproc` seems to point to the wrong location. Does anyone
know how to fix this error besides installing those files on the build
host?
Judging from `run.do_compile.6321` `PKG_CONFIG_PATH` gets set
incorrectly.
export
PKG_CONFIG_PATH=/oe/build/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig:/oe/build/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/pkgconfig
I checked `gnome-doc-utils.pc` in these directories and both point to
`/usr/share/xml/gnome/xslt/docbook/omf/db2omf.xsl`, which is incorrect
(`datadir=/usr/share`)
In the staging(?) path
`/oe/build/angstrom-dev/sysroots/i686-linux/usr/lib/pkgconfig/`
everything is set up correctly.
datadir=/oe/build/angstrom-dev/sysroots/i686-linux/usr/share
Also running
/oe/build/angstrom-dev/sysroots/i686-linux/usr/bin/pkg-config
--variable db2omf gnome-doc-utils
in a clean environment without exporting `PKG_CONFIG_PATH` works.
Is this a problem with new style staging? Could you please provide a
hint on how to fix this.
I am stuck. Could someone take a look at this please and give me a hint
on how to proceed? (I know the week just started.)
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] `DEFAULT_PREFERENCE = -1` of current (upstream) releases (was: [PATCH] openssl: update 1.0.0 to 1.0.0a)
Am Dienstag, den 17.08.2010, 10:50 +0400 schrieb Roman I Khimov: В сообщении от Понедельник 16 августа 2010 23:35:59 автор Khem Raj написал: IMO the newest version in a recipe should always be default preference this way we can stabilize recipe upgrades quicker. This also means a wider testing before pushing a new recipe DEFAULT_PREFERENCE = -1 makes it to escape the testing. Well, consider Perl, for example. Making 5.10.1 a default preference would break binary packaged perl modules built for 5.8.8, so technically some massive PR bump (most probably DISTRO_PR) is needed when updating to 5.10.1. Forcing distro maintainers to do that is not nice, IMO. Although the way it is now Perl 5.10.1 seems to be rarely used, which is also not nice. Probably, there is no way to solve this problem for everyone. With D_P it's not used much, removing D_P is asking for YOU BROKE MY BUILD!!! love messages from random corners. What about removing `DEFAULT_PREFERENCE = -1` and have the distributions not wanting it pinning to the old version? This could be done after a period of time after the push and an announcement to the list asking what distribution prefers what and make that change in one commit. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] flex: disabled packaged staging of native builds
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
On Mon, Aug 16, 2010 at 7:43 PM, Tom Rini tom_r...@mentor.com wrote:
Jason Kridner wrote:
---
recipes/flex/flex.inc | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/recipes/flex/flex.inc b/recipes/flex/flex.inc
index 49b26e8..5d3f076 100644
--- a/recipes/flex/flex.inc
+++ b/recipes/flex/flex.inc
@@ -4,7 +4,7 @@ LICENSE = BSD
DEPENDS = gettext
-INC_PR = r5
+INC_PR = r6
S = ${WORKDIR}/flex-${PV}
@@ -16,3 +16,5 @@ inherit autotools gettext
# static-only library; that might be an error
FILES_${PN} += ${libdir}/libfl.a
+
+PSTAGING_DISABLED_virtclass-native = 1
I assume you've ran into 2.3.35 not being relocation happy? Have you been
able to look at this at all? 2.3.31 works so it's something 'bad' done
upstream. Thanks!
I did, but I didn't look into the details. bison-native wouldn't
rebuild when I used my flex-native pstage. bitbake -c clean
flex-native fixed it, so...
After that would rebuilding from pstage cause the error again?
I'm a little bit worried that we inhibit PSTAGING because e.g.
something else is wrong (e.g. a change elsewhere that should have been
resulted in a flex PR bump).
Besides (but this is more a global remark): it would be nice if a
recipe disables something that there is a short description why this
is done. (at least in the commit message, but imho preferably in the
recipe, so in half a year time, people still know why it is done and
can much easier judge if it can be removed).
Frans.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] rename files dirs
Currently lots of our patches reside in a directory called files. Somewhere in the past koen explained me that that is not really proper (and I agree with them). I disagree with that. In fact I'd rather suggest the other way, which is: Put them all into files/ unless you have a compelling reason not to, i.e. the moment one patch does not apply any longer to all versions of the recipes; then it should be moved to PN-PV directory. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] `DEFAULT_PREFERENCE = -1` of current (upstream) releases (was: [PATCH] openssl: update 1.0.0 to 1.0.0a)
Am 17.08.2010 um 09:26 schrieb Paul Menzel: Am Dienstag, den 17.08.2010, 10:50 +0400 schrieb Roman I Khimov: В сообщении от Понедельник 16 августа 2010 23:35:59 автор Khem Raj написал: IMO the newest version in a recipe should always be default preference this way we can stabilize recipe upgrades quicker. This also means a wider testing before pushing a new recipe DEFAULT_PREFERENCE = -1 makes it to escape the testing. Well, consider Perl, for example. Making 5.10.1 a default preference would break binary packaged perl modules built for 5.8.8, so technically some massive PR bump (most probably DISTRO_PR) is needed when updating to 5.10.1. Forcing distro maintainers to do that is not nice, IMO. Although the way it is now Perl 5.10.1 seems to be rarely used, which is also not nice. Probably, there is no way to solve this problem for everyone. With D_P it's not used much, removing D_P is asking for YOU BROKE MY BUILD!!! love messages from random corners. What about removing `DEFAULT_PREFERENCE = -1` and have the distributions not wanting it pinning to the old version? This could be done after a period of time after the push and an announcement to the list asking what distribution prefers what and make that change in one commit. That sounds good to me. We should really try to keep a reasonable default set of preferences so that certain DISTRO setting are not mandatory. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] rename files dirs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-08-10 10:39, Dr. Michael Lauer wrote: Currently lots of our patches reside in a directory called files. Somewhere in the past koen explained me that that is not really proper (and I agree with them). I disagree with that. In fact I'd rather suggest the other way, which is: Put them all into files/ unless you have a compelling reason not to, i.e. the moment one patch does not apply any longer to all versions of the recipes; then it should be moved to PN-PV directory. What's wrong with putting those patches in PN/ instead of files/? Having them in files/ significantly threatens all efforts to clean up the recipes/ structure :( -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFMak6cMkyGM64RGpERAi7ZAKC3znJEhz9R+E+ogbSIk+CFNhscJwCeNzU5 bj8CdsrE7eEOUc9QyPoJ2JE= =R/wu -END PGP SIGNATURE- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] rename files dirs
Am 17.08.2010 um 10:55 schrieb Koen Kooi: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-08-10 10:39, Dr. Michael Lauer wrote: Currently lots of our patches reside in a directory called files. Somewhere in the past koen explained me that that is not really proper (and I agree with them). I disagree with that. In fact I'd rather suggest the other way, which is: Put them all into files/ unless you have a compelling reason not to, i.e. the moment one patch does not apply any longer to all versions of the recipes; then it should be moved to PN-PV directory. What's wrong with putting those patches in PN/ instead of files/? Having them in files/ significantly threatens all efforts to clean up the recipes/ structure :( I didn't say it's wrong, but rather that the workflow I presented feels more natural to me. I can live with putting them all in PN. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] loading jffs2 image on arm926ek board
Hello, I have used openembedded to build rfs image with x libraries for arm926ek board. After loading the image i got following error: bootm 0x2000 ## Booting image at 2000 ... Image Name: Linux-2.6.32.9 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1392284 Bytes = 1.3 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux.. done, booting the kernel. Linux version 2.6.32.9 (r...@nakshatra) (gcc version 4.2.2) #14 Fri Apr 9 16:01:58 NPT 2010 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Atmel AT91SAM9261-EK Ignoring unrecognised tag 0x54410008 Memory policy: ECC disabled, Data cache writeback Clocks: CPU 198 MHz, master 99 MHz, main 18.432 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: mem=128M console=ttyS0,115200 rootfstype=jffs2 root=/dev/mtdblock0 rw init=/bin/sh PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 126932KB available (2520K code, 184K data, 124K init, 0K highmem) Hierarchical RCU implementation. NR_IRQS:192 AT91: 96 gpio irqs in 3 banks Console: colour dummy device 80x30 console [ttyS0] enabled Calibrating delay loop... 99.12 BogoMIPS (lpj=495616) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 bio: create slab bio-0 at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Switching to clocksource pit NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 NetWinder Floating Point Emulator V0.97 (double precision) JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. msgmni has been set to 248 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) io scheduler noop registered io scheduler anticipatory registered (default) atmel_lcdfb atmel_lcdfb.0: backlight control is not available atmel_lcdfb atmel_lcdfb.0: 600KiB frame buffer at 2790 (mapped at ffc0) Console: switching to colour frame buffer device 80x30 atmel_lcdfb atmel_lcdfb.0: fb0: Atmel LCDC at 0x0060 (mapped at c885a000), irq 21 atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL atmel_usart.1: ttyS1 at MMIO 0xfffb (irq = 6) is a ATMEL_SERIAL atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL atmel_usart.3: ttyS3 at MMIO 0xfffb8000 (irq = 8) is a ATMEL_SERIAL brd: module loaded NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit) AT91 NAND: 8-bit, Software ECC Scanning device for bad blocks Bad eraseblock 56 at 0x0070 Bad eraseblock 1909 at 0x0eea Creating 2 MTD partitions on atmel_nand: 0x-0x0800 : Partition 1 0x0800-0x1000 : Partition 2 atmel_spi atmel_spi.0: Atmel SPI Controller at 0xfffc8000 (irq 12) dm9000 Ethernet Driver, V1.31 dm9000 dm9000.0: read wrong id 0x342a0028 dm9000 dm9000.0: read wrong id 0x2b2a dm9000 dm9000.0: read wrong id 0x2b2a0028 dm9000 dm9000.0: read wrong id 0x342a0028 dm9000 dm9000.0: read wrong id 0x2b2a0028 dm9000 dm9000.0: read wrong id 0x2b2a2928 dm9000 dm9000.0: read wrong id 0x2b2a0028 dm9000 dm9000.0: read wrong id 0x2b002928 dm9000 dm9000.0: wrong id: 0x2b002928 dm9000 dm9000.0: not found (-19). usbmon: debugfs is not available ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver at91_ohci at91_ohci: AT91 OHCI at91_ohci at91_ohci: new USB bus registered, assigned bus number 1 at91_ohci at91_ohci: irq 20, io mem 0x0050 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected usbcore: registered new interface driver cdc_acm cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. udc: at91_udc version 3 May 2006 mice: PS/2 mouse device common for all mice ads7846 spi0.2: touchscreen, irq 29 input: ADS7843 Touchscreen as /devices/platform/atmel_spi.0/spi0.2/input/input0 i2c /dev entries driver TCP cubic registered NET: Registered protocol family 17 usb 1-1: new full speed USB device using at91_ohci and address 2 usb 1-1: configuration #1 chosen from 1 choice scsi0 : SCSI emulation for USB Mass Storage devices VFS: Mounted root
[oe] [PATCH] cacaoh-native: Removed legacy style staging
* converted do_stage to do_install
* replaced ${STAGING_BINDIR} with ${D}${bindir}
* bumped the PR in the .bb files
Signed-off-by: Fahad Usman fahad_us...@mentor.com
---
recipes/cacao/cacaoh-native.inc |6 +++---
recipes/cacao/cacaoh-native_0.99.3.bb |2 +-
recipes/cacao/cacaoh-native_0.99.4.bb |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/recipes/cacao/cacaoh-native.inc b/recipes/cacao/cacaoh-native.inc
index a44c503..d255df4 100644
--- a/recipes/cacao/cacaoh-native.inc
+++ b/recipes/cacao/cacaoh-native.inc
@@ -20,7 +20,7 @@ do_compile() {
oe_runmake -C src/vmcore libvmcore.la
oe_runmake -C src/cacaoh cacaoh
}
-
-do_stage() {
- install -m 0755 src/cacaoh/.libs/cacaoh ${STAGING_BINDIR}/cacaoh-${PV}
+do_install() {
+ install -d ${D}${bindir}/cacaoh-${PV}
+ install -m 0755 src/cacaoh/.libs/cacaoh ${D}${bindir}/cacaoh-${PV}
}
diff --git a/recipes/cacao/cacaoh-native_0.99.3.bb
b/recipes/cacao/cacaoh-native_0.99.3.bb
index b3baee0..b321329 100644
--- a/recipes/cacao/cacaoh-native_0.99.3.bb
+++ b/recipes/cacao/cacaoh-native_0.99.3.bb
@@ -1,6 +1,6 @@
require cacaoh-native.inc
-PR = r1
+PR = r2
SRC_URI =
http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.bz2;
diff --git a/recipes/cacao/cacaoh-native_0.99.4.bb
b/recipes/cacao/cacaoh-native_0.99.4.bb
index a9effc0..e269e43 100644
--- a/recipes/cacao/cacaoh-native_0.99.4.bb
+++ b/recipes/cacao/cacaoh-native_0.99.4.bb
@@ -1,6 +1,6 @@
require cacaoh-native.inc
-PR = r0
+PR = r1
SRC_URI =
http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.bz2;
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] cacaoh-native: used oe-stylize.py
* just incorporated the output of oe-stylize.py, no functionality is changed
Signed-off-by: Fahad Usman fahad_us...@mentor.com
---
recipes/cacao/cacaoh-native.inc |7 +++
recipes/cacao/cacaoh-native_0.99.3.bb |5 ++---
recipes/cacao/cacaoh-native_0.99.4.bb |5 ++---
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/recipes/cacao/cacaoh-native.inc b/recipes/cacao/cacaoh-native.inc
index d255df4..fcbe93b 100644
--- a/recipes/cacao/cacaoh-native.inc
+++ b/recipes/cacao/cacaoh-native.inc
@@ -1,7 +1,6 @@
DESCRIPTION = Header generator for Cacao JVM - Needed for cross-compilation
builds
HOMEPAGE = http://www.cacaojvm.org/;
-LICENSE = GPL
-
+LICENSE = GPL
DEPENDS = libtool-native zlib-native virtual/javac-native classpath-native
S = ${WORKDIR}/cacao-${PV}
@@ -21,6 +20,6 @@ do_compile() {
oe_runmake -C src/cacaoh cacaoh
}
do_install() {
- install -d ${D}${bindir}/cacaoh-${PV}
- install -m 0755 src/cacaoh/.libs/cacaoh ${D}${bindir}/cacaoh-${PV}
+ install -d ${D}${bindir}/cacaoh-${PV}
+ install -m 0755 src/cacaoh/.libs/cacaoh ${D}${bindir}/cacaoh-${PV}
}
diff --git a/recipes/cacao/cacaoh-native_0.99.3.bb
b/recipes/cacao/cacaoh-native_0.99.3.bb
index b321329..1bc3b84 100644
--- a/recipes/cacao/cacaoh-native_0.99.3.bb
+++ b/recipes/cacao/cacaoh-native_0.99.3.bb
@@ -1,8 +1,7 @@
-require cacaoh-native.inc
-
PR = r2
SRC_URI =
http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.bz2;
-
SRC_URI[md5sum] = db93ab31c6d1b7f1e213771bb81bde58
SRC_URI[sha256sum] =
1ea5bd257f755ffcae2c7a1935c37147c7392478922410e0870361eea08b6c27
+
+require cacaoh-native.inc
diff --git a/recipes/cacao/cacaoh-native_0.99.4.bb
b/recipes/cacao/cacaoh-native_0.99.4.bb
index e269e43..d0fc1c0 100644
--- a/recipes/cacao/cacaoh-native_0.99.4.bb
+++ b/recipes/cacao/cacaoh-native_0.99.4.bb
@@ -1,8 +1,7 @@
-require cacaoh-native.inc
-
PR = r1
SRC_URI =
http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.bz2;
-
SRC_URI[md5sum] = 63220327925ace13756ae334c55a3baa
SRC_URI[sha256sum] =
1dfc4903dc0172286df4f1740fd0f12749ac81d51c602290b47cbe83d51e1d56
+
+require cacaoh-native.inc
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] mpfr-native_svn.bb: Problems accessing the repository(s) behind a proxy
Hello, as I am sitting behind an restrictive proxy, I'm unable to use svn: protocol. The svn repository used for mpfr-native_svn.bb is accessible via svn: or https: . The https: access needs an authentication (--username= --password==) according to the webpage. Is there a possibility to send the authentication for SRC_URIs using https: and ignore the ? FETCHCOMMAND_SVN ? Or, how can I pin the mpfr_3.0.0.bb for native stage ? Regards Wolfgang Hauser ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] cacaoh-native: used oe-stylize.py
2010/8/17 Fahad Usman fahad_us...@mentor.com:
* just incorporated the output of oe-stylize.py, no functionality is changed
Signed-off-by: Fahad Usman fahad_us...@mentor.com
---
recipes/cacao/cacaoh-native.inc | 7 +++
recipes/cacao/cacaoh-native_0.99.3.bb | 5 ++---
recipes/cacao/cacaoh-native_0.99.4.bb | 5 ++---
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/recipes/cacao/cacaoh-native.inc b/recipes/cacao/cacaoh-native.inc
index d255df4..fcbe93b 100644
--- a/recipes/cacao/cacaoh-native.inc
+++ b/recipes/cacao/cacaoh-native.inc
@@ -1,7 +1,6 @@
DESCRIPTION = Header generator for Cacao JVM - Needed for cross-compilation
builds
HOMEPAGE = http://www.cacaojvm.org/;
-LICENSE = GPL
-
+LICENSE = GPL
DEPENDS = libtool-native zlib-native virtual/javac-native classpath-native
S = ${WORKDIR}/cacao-${PV}
@@ -21,6 +20,6 @@ do_compile() {
oe_runmake -C src/cacaoh cacaoh
}
do_install() {
- install -d ${D}${bindir}/cacaoh-${PV}
- install -m 0755 src/cacaoh/.libs/cacaoh ${D}${bindir}/cacaoh-${PV}
+ install -d ${D}${bindir}/cacaoh-${PV}
+ install -m 0755 src/cacaoh/.libs/cacaoh ${D}${bindir}/cacaoh-${PV}
}
diff --git a/recipes/cacao/cacaoh-native_0.99.3.bb
b/recipes/cacao/cacaoh-native_0.99.3.bb
index b321329..1bc3b84 100644
--- a/recipes/cacao/cacaoh-native_0.99.3.bb
+++ b/recipes/cacao/cacaoh-native_0.99.3.bb
@@ -1,8 +1,7 @@
-require cacaoh-native.inc
-
PR = r2
SRC_URI =
http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.bz2;
-
SRC_URI[md5sum] = db93ab31c6d1b7f1e213771bb81bde58
SRC_URI[sha256sum] =
1ea5bd257f755ffcae2c7a1935c37147c7392478922410e0870361eea08b6c27
+
+require cacaoh-native.inc
diff --git a/recipes/cacao/cacaoh-native_0.99.4.bb
b/recipes/cacao/cacaoh-native_0.99.4.bb
index e269e43..d0fc1c0 100644
--- a/recipes/cacao/cacaoh-native_0.99.4.bb
+++ b/recipes/cacao/cacaoh-native_0.99.4.bb
@@ -1,8 +1,7 @@
-require cacaoh-native.inc
-
PR = r1
SRC_URI =
http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.bz2;
-
SRC_URI[md5sum] = 63220327925ace13756ae334c55a3baa
SRC_URI[sha256sum] =
1dfc4903dc0172286df4f1740fd0f12749ac81d51c602290b47cbe83d51e1d56
+
+require cacaoh-native.inc
--
Have you tested this?
Moving a require file might lead to errors or unexpected results
a require (or include) is an inclusion of the file. Moving it might
cause a problem if the recipe itself redefines a var that is also
defined in the inc file.
(e.g. if the recipe overrules the DEPENDS that are in an .inc file)
Frans.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] openssl: update 1.0.0 to 1.0.0a
On Mon, Aug 16, 2010 at 10:36:18PM +0400, Roman I Khimov wrote: * exactly one fix, considered as safe upgrade Signed-off-by: Roman I Khimov khi...@altell.ru Acked-by: Martin Jansa martin.ja...@gmail.com --- .../include/angstrom-2008-preferred-versions.inc |4 +- conf/distro/include/preferred-shr-versions.inc |4 +- .../openssl/openssl-1.0.0/configure-targets.patch | 25 - recipes/openssl/openssl-1.0.0/debian.patch | 515 .../engines-install-in-libdir-ssl.patch| 53 -- recipes/openssl/openssl-1.0.0/libdeps-first.patch | 27 - recipes/openssl/openssl-1.0.0/oe-ldflags.patch | 22 - recipes/openssl/openssl-1.0.0/shared-libs.patch| 48 -- .../openssl/openssl-1.0.0a/configure-targets.patch | 25 + recipes/openssl/openssl-1.0.0a/debian.patch| 515 .../engines-install-in-libdir-ssl.patch| 53 ++ recipes/openssl/openssl-1.0.0a/libdeps-first.patch | 27 + recipes/openssl/openssl-1.0.0a/oe-ldflags.patch| 22 + recipes/openssl/openssl-1.0.0a/shared-libs.patch | 48 ++ recipes/openssl/openssl-native_1.0.0.bb| 27 - recipes/openssl/openssl-native_1.0.0a.bb | 27 + recipes/openssl/openssl_1.0.0.bb | 30 -- recipes/openssl/openssl_1.0.0a.bb | 30 ++ 18 files changed, 751 insertions(+), 751 deletions(-) delete mode 100644 recipes/openssl/openssl-1.0.0/configure-targets.patch delete mode 100644 recipes/openssl/openssl-1.0.0/debian.patch delete mode 100644 recipes/openssl/openssl-1.0.0/engines-install-in-libdir-ssl.patch delete mode 100644 recipes/openssl/openssl-1.0.0/libdeps-first.patch delete mode 100644 recipes/openssl/openssl-1.0.0/oe-ldflags.patch delete mode 100644 recipes/openssl/openssl-1.0.0/shared-libs.patch create mode 100644 recipes/openssl/openssl-1.0.0a/configure-targets.patch create mode 100644 recipes/openssl/openssl-1.0.0a/debian.patch create mode 100644 recipes/openssl/openssl-1.0.0a/engines-install-in-libdir-ssl.patch create mode 100644 recipes/openssl/openssl-1.0.0a/libdeps-first.patch create mode 100644 recipes/openssl/openssl-1.0.0a/oe-ldflags.patch create mode 100644 recipes/openssl/openssl-1.0.0a/shared-libs.patch delete mode 100644 recipes/openssl/openssl-native_1.0.0.bb create mode 100644 recipes/openssl/openssl-native_1.0.0a.bb delete mode 100644 recipes/openssl/openssl_1.0.0.bb create mode 100644 recipes/openssl/openssl_1.0.0a.bb ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] cacaoh-native: Removed legacy style staging
2010/8/17 Fahad Usman fahad_us...@mentor.com:
* converted do_stage to do_install
* replaced ${STAGING_BINDIR} with ${D}${bindir}
* bumped the PR in the .bb files
Signed-off-by: Fahad Usman fahad_us...@mentor.com
---
recipes/cacao/cacaoh-native.inc | 6 +++---
recipes/cacao/cacaoh-native_0.99.3.bb | 2 +-
recipes/cacao/cacaoh-native_0.99.4.bb | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/recipes/cacao/cacaoh-native.inc b/recipes/cacao/cacaoh-native.inc
index a44c503..d255df4 100644
--- a/recipes/cacao/cacaoh-native.inc
+++ b/recipes/cacao/cacaoh-native.inc
@@ -20,7 +20,7 @@ do_compile() {
oe_runmake -C src/vmcore libvmcore.la
oe_runmake -C src/cacaoh cacaoh
}
-
-do_stage() {
- install -m 0755 src/cacaoh/.libs/cacaoh ${STAGING_BINDIR}/cacaoh-${PV}
+do_install() {
+ install -d ${D}${bindir}/cacaoh-${PV}
+ install -m 0755 src/cacaoh/.libs/cacaoh ${D}${bindir}/cacaoh-${PV}
}
diff --git a/recipes/cacao/cacaoh-native_0.99.3.bb
b/recipes/cacao/cacaoh-native_0.99.3.bb
index b3baee0..b321329 100644
--- a/recipes/cacao/cacaoh-native_0.99.3.bb
+++ b/recipes/cacao/cacaoh-native_0.99.3.bb
@@ -1,6 +1,6 @@
require cacaoh-native.inc
-PR = r1
+PR = r2
SRC_URI =
http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.bz2;
diff --git a/recipes/cacao/cacaoh-native_0.99.4.bb
b/recipes/cacao/cacaoh-native_0.99.4.bb
index a9effc0..e269e43 100644
--- a/recipes/cacao/cacaoh-native_0.99.4.bb
+++ b/recipes/cacao/cacaoh-native_0.99.4.bb
@@ -1,6 +1,6 @@
require cacaoh-native.inc
-PR = r0
+PR = r1
SRC_URI =
http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-${PV}/cacao-${PV}.tar.bz2;
--
1.6.3.3
I think you need
NATIVE_INSTALL_WORKS = 1
in your recipe.
When updating your patch please resubmit as v2 and update patchwork
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Write access for Simon Busch
Hello. Over the last days I reviewed some patches from him. I have done this earlier as well and have the feeling that he it ready for write access now. The work was done well and he was always open for feedback and happy to fix other issues around the original problem. regards Stefan Schmidt ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Write access for Simon Busch
On 17/08/10 13:06, Stefan Schmidt wrote: Hello. Over the last days I reviewed some patches from him. I have done this earlier as well and have the feeling that he it ready for write access now. The work was done well and he was always open for feedback and happy to fix other issues around the original problem. Approved by me. G ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] loading jffs2 image on arm926ek board
Le 17/08/2010 11:38, rani rajaram : Hello, I have used openembedded to build rfs image with x libraries for arm926ek board. We need more information here: - where did you store your jffs2 image in NAND flash (which address)? - what is your NAND flash partitioning? After loading the image i got following error: bootm 0x2000 ## Booting image at 2000 ... Image Name: Linux-2.6.32.9 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1392284 Bytes = 1.3 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux.. done, booting the kernel. Linux version 2.6.32.9 (r...@nakshatra) (gcc version 4.2.2) #14 Fri Apr 9 16:01:58 NPT 2010 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Atmel AT91SAM9261-EK Ignoring unrecognised tag 0x54410008 Memory policy: ECC disabled, Data cache writeback Clocks: CPU 198 MHz, master 99 MHz, main 18.432 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: mem=128M console=ttyS0,115200 rootfstype=jffs2 root=/dev/mtdblock0 rw init=/bin/sh It seems that you are using mtd0 as rootfs: did you flashed your jffs2 at address 0 of NAND? PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 126932KB available (2520K code, 184K data, 124K init, 0K highmem) Hierarchical RCU implementation. NR_IRQS:192 AT91: 96 gpio irqs in 3 banks Console: colour dummy device 80x30 console [ttyS0] enabled Calibrating delay loop... 99.12 BogoMIPS (lpj=495616) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 bio: create slab bio-0 at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Switching to clocksource pit NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 NetWinder Floating Point Emulator V0.97 (double precision) JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. msgmni has been set to 248 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) io scheduler noop registered io scheduler anticipatory registered (default) atmel_lcdfb atmel_lcdfb.0: backlight control is not available atmel_lcdfb atmel_lcdfb.0: 600KiB frame buffer at 2790 (mapped at ffc0) Console: switching to colour frame buffer device 80x30 atmel_lcdfb atmel_lcdfb.0: fb0: Atmel LCDC at 0x0060 (mapped at c885a000), irq 21 atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL atmel_usart.1: ttyS1 at MMIO 0xfffb (irq = 6) is a ATMEL_SERIAL atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL atmel_usart.3: ttyS3 at MMIO 0xfffb8000 (irq = 8) is a ATMEL_SERIAL brd: module loaded NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit) AT91 NAND: 8-bit, Software ECC Scanning device for bad blocks Bad eraseblock 56 at 0x0070 Bad eraseblock 1909 at 0x0eea Creating 2 MTD partitions on atmel_nand: 0x-0x0800 : Partition 1 0x0800-0x1000 : Partition 2 atmel_spi atmel_spi.0: Atmel SPI Controller at 0xfffc8000 (irq 12) dm9000 Ethernet Driver, V1.31 dm9000 dm9000.0: read wrong id 0x342a0028 dm9000 dm9000.0: read wrong id 0x2b2a dm9000 dm9000.0: read wrong id 0x2b2a0028 dm9000 dm9000.0: read wrong id 0x342a0028 dm9000 dm9000.0: read wrong id 0x2b2a0028 dm9000 dm9000.0: read wrong id 0x2b2a2928 dm9000 dm9000.0: read wrong id 0x2b2a0028 dm9000 dm9000.0: read wrong id 0x2b002928 dm9000 dm9000.0: wrong id: 0x2b002928 dm9000 dm9000.0: not found (-19). usbmon: debugfs is not available ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver at91_ohci at91_ohci: AT91 OHCI at91_ohci at91_ohci: new USB bus registered, assigned bus number 1 at91_ohci at91_ohci: irq 20, io mem 0x0050 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected usbcore: registered new interface driver cdc_acm cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. udc: at91_udc version 3 May 2006 mice: PS/2 mouse device common
Re: [oe] Write access for Simon Busch
Am Dienstag, 17. August 2010, 14:06:43 schrieb Stefan Schmidt: Hello. Over the last days I reviewed some patches from him. I have done this earlier as well and have the feeling that he it ready for write access now. The work was done well and he was always open for feedback and happy to fix other issues around the original problem. +1 from me regards Stefan Schmidt -- Klaus 'mrmoku' Kurzmann ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] eds-dbus: depends on libsoup-2.4
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/eds/eds-dbus_git.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes/eds/eds-dbus_git.bb b/recipes/eds/eds-dbus_git.bb
index 16b3276..9bee1e0 100644
--- a/recipes/eds/eds-dbus_git.bb
+++ b/recipes/eds/eds-dbus_git.bb
@@ -1,11 +1,11 @@
DESCRIPTION = Evolution database backend server
HOMEPAGE = http://labs.o-hand.com/embedded-eds/;
LICENSE = LGPL
-DEPENDS = libical intltool-native libglade glib-2.0 gtk+ gconf dbus db
gnome-common virtual/libiconv zlib intltool libxml2
+DEPENDS = libical intltool-native libglade glib-2.0 gtk+ gconf dbus db
gnome-common virtual/libiconv zlib intltool libxml2 libsoup-2.4
SRCREV = 91812cd2f797fb8ec8befbb2685037584ce144ee
PV = 1.4.0
-PR = r4
+PR = r5
PE = 1
PR_append = +gitr${SRCREV}
--
1.5.6.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] rpm2cpio-native: Run oe-stylize.py
* Run oe-stylize.py script on recipe and modified the recipe according to the
output of oe-stylize.py.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb
b/recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb
index 151753d..252fd53 100644
--- a/recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb
+++ b/recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb
@@ -1,28 +1,25 @@
# rpm2cpio-native build file
# Copyright (C) 2005, Advanced Micro Devices, Inc. All Rights Reserved
# Released under the MIT license (see COPYING.MIT)
+LICENSE = BSD
+DEPENDS = perl-native
-DEPENDS=perl-native
-LICENSE=BSD
-SRC_URI=http://www.freebsd.org/cgi/cvsweb.cgi/%7Echeckout%7E/ports/archivers/rpm2cpio/files/rpm2cpio?rev=1.2;
+SRC_URI =
http://www.freebsd.org/cgi/cvsweb.cgi/%7Echeckout%7E/ports/archivers/rpm2cpio/files/rpm2cpio?rev=1.2;
+SRC_URI[md5sum] = 07f64fa3dae6eb8b1b578d01473a5c07
+SRC_URI[sha256sum] =
a98cb1d9903192c4fcf40d82c705e091a5c193f87327703217749a5f4cc6197d
-inherit native
+S = ${WORKDIR}
-S=${WORKDIR}
+inherit native
do_compile() {
}
-
do_stage() {
- install -d ${STAGING_BINDIR}
- sed -e '1,1s|${bindir}/|${bindir}/env |' rpm2cpio?rev=1.2 \
-${STAGING_BINDIR}/rpm2cpio.pl
-
- my_PERL=/usr/bin/env perl
- sed -e s%/[a-zA-Z0-9/]*/bin/perl%$my_PERL%g -i
${STAGING_BINDIR}/rpm2cpio.pl
-
- chmod 0755 ${STAGING_BINDIR}/rpm2cpio.pl
+install -d ${STAGING_BINDIR}
+sed -e '1,1s|${bindir}/|${bindir}/env |' rpm2cpio?rev=1.2 \
+ ${STAGING_BINDIR}/rpm2cpio.pl
+my_PERL=/usr/bin/env perl
+sed -e s%/[a-zA-Z0-9/]*/bin/perl%$my_PERL%g -i
${STAGING_BINDIR}/rpm2cpio.pl
+chmod 0755 ${STAGING_BINDIR}/rpm2cpio.pl
}
-SRC_URI[md5sum] = 07f64fa3dae6eb8b1b578d01473a5c07
-SRC_URI[sha256sum] =
a98cb1d9903192c4fcf40d82c705e091a5c193f87327703217749a5f4cc6197d
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/2] rpm2cpio-native: convert to new style staging, remove 'do_stage()'
* Replace do_stage() with do_install from the recipe and replace all
occurrences of ${STAGING_BINDIR} with ${D}{bindir}.
* Add NATIVE_INSTALL_WORKS = 1
* Bump PR to r1
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb
b/recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb
index 252fd53..ac3d673 100644
--- a/recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb
+++ b/recipes/rpm2cpio/rpm2cpio-native_1.2_2.bb
@@ -3,6 +3,7 @@
# Released under the MIT license (see COPYING.MIT)
LICENSE = BSD
DEPENDS = perl-native
+PR = r1
SRC_URI =
http://www.freebsd.org/cgi/cvsweb.cgi/%7Echeckout%7E/ports/archivers/rpm2cpio/files/rpm2cpio?rev=1.2;
SRC_URI[md5sum] = 07f64fa3dae6eb8b1b578d01473a5c07
@@ -14,12 +15,14 @@ inherit native
do_compile() {
}
-do_stage() {
-install -d ${STAGING_BINDIR}
+do_install() {
+install -d ${D}${bindir}
sed -e '1,1s|${bindir}/|${bindir}/env |' rpm2cpio?rev=1.2 \
- ${STAGING_BINDIR}/rpm2cpio.pl
+ ${D}${bindir}/rpm2cpio.pl
my_PERL=/usr/bin/env perl
-sed -e s%/[a-zA-Z0-9/]*/bin/perl%$my_PERL%g -i
${STAGING_BINDIR}/rpm2cpio.pl
-chmod 0755 ${STAGING_BINDIR}/rpm2cpio.pl
+sed -e s%/[a-zA-Z0-9/]*/bin/perl%$my_PERL%g -i
${D}${bindir}/rpm2cpio.pl
+chmod 0755 ${D}${bindir}/rpm2cpio.pl
}
+NATIVE_INSTALL_WORKS = 1
+
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] cacaoh-native: Removed legacy style staging
2010/8/17 Frans Meulenbroeks fransmeulenbro...@gmail.com: I think you need NATIVE_INSTALL_WORKS = 1 in your recipe. When updating your patch please resubmit as v2 and update patchwork Frans I am getting the same .pkg file and staging directory both with or without the NATIVE_INSTALL_WORKS = 1 line, should i still add it and update the patch? Thanks, Fahad ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] cacaoh-native: used oe-stylize.py
2010/8/17 Frans Meulenbroeks fransmeulenbro...@gmail.com: Have you tested this? Moving a require file might lead to errors or unexpected results a require (or include) is an inclusion of the file. Moving it might cause a problem if the recipe itself redefines a var that is also defined in the inc file. (e.g. if the recipe overrules the DEPENDS that are in an .inc file) Frans. yes, it appears to be working exactly the way it was before using the oe-stylize.py Fahad ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] bison: add flex dependency
On Mon, 2010-08-16 at 16:26 -0500, Jason Kridner wrote: -DEPENDS = virtual/libintl +DEPENDS = virtual/libintl virtual/flex Does this actually work? I couldn't immediately spot any obvious package which PROVIDES virtual/flex, and that sounds like a strange kind of virtual to have since I don't think there are any alternative implementations of flex. (But if bison actually depends on lex generically, rather than flex specifically, it might make some sense to introduce a virtual/lex and have flex PROVIDE it.) p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] sox-native: Run oe-stylize.py
* Run oe-stylize.py script on the recipe and modified the recipe according to
the output of oe-stylize.py.
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
recipes/sox/sox-native_13.0.0.bb | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/recipes/sox/sox-native_13.0.0.bb b/recipes/sox/sox-native_13.0.0.bb
index 9be0322..0dc90ca 100644
--- a/recipes/sox/sox-native_13.0.0.bb
+++ b/recipes/sox/sox-native_13.0.0.bb
@@ -7,13 +7,12 @@ inherit native
do_patch() {
true
}
-
-do_stage() {
- make bindir=${STAGING_BINDIR} libdir=${STAGING_LIBDIR}
mandir=${STAGING_DIR_HOST}${layout_mandir} includedir=${STAGING_INCDIR}
install
- rm ${STAGING_BINDIR}/rec
- ln -s ${STAGING_BINDIR}/play ${STAGING_BINDIR}/rec
-}
-
do_install() {
true
}
+do_stage() {
+make bindir=${STAGING_BINDIR} libdir=${STAGING_LIBDIR}
mandir=${STAGING_DIR_HOST}${layout_mandir} includedir=${STAGING_INCDIR}
install
+rm ${STAGING_BINDIR}/rec
+ln -s ${STAGING_BINDIR}/play ${STAGING_BINDIR}/rec
+}
+
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/2] sox-native: convert to new style staging, remove do_stage()
* Replace the do_stage name with do_install.
* Replace ${STAGING_BINDIR} with ${D}${bindir}, ${STAGING_LIBDIR} with
${D}${libdir}, ${STAGING_DIR_HOST}${layout_mandir} with ${D}${layout_mandir}
and ${STAGING_INCDIR} with ${D}${includedir}
* Remove previous do_install().
* Bump PR to r2
Signed-off-by: Noor Ahsan noor_ah...@mentor.com
---
recipes/sox/sox-native_13.0.0.bb | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/recipes/sox/sox-native_13.0.0.bb b/recipes/sox/sox-native_13.0.0.bb
index 0dc90ca..84a131e 100644
--- a/recipes/sox/sox-native_13.0.0.bb
+++ b/recipes/sox/sox-native_13.0.0.bb
@@ -1,4 +1,5 @@
include sox_${PV}.bb
+PR = r2
S = ${WORKDIR}/sox-${PV}
@@ -8,11 +9,9 @@ do_patch() {
true
}
do_install() {
-true
-}
-do_stage() {
-make bindir=${STAGING_BINDIR} libdir=${STAGING_LIBDIR}
mandir=${STAGING_DIR_HOST}${layout_mandir} includedir=${STAGING_INCDIR}
install
-rm ${STAGING_BINDIR}/rec
-ln -s ${STAGING_BINDIR}/play ${STAGING_BINDIR}/rec
+make bindir=${D}${bindir} libdir=${D}${libdir}
mandir=${D}${layout_mandir} includedir=${D}${includedir} install
+rm ${D}${bindir}/rec
+ln -s ${D}${bindir}/play ${D}${bindir}/rec
}
+
--
1.6.3.3
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] bison: add flex dependency
On Tue, 2010-08-17 at 16:14 +0200, Frans Meulenbroeks wrote: 2010/8/17 Phil Blundell ph...@gnu.org: On Mon, 2010-08-16 at 16:26 -0500, Jason Kridner wrote: -DEPENDS = virtual/libintl +DEPENDS = virtual/libintl virtual/flex Does this actually work? I couldn't immediately spot any obvious package which PROVIDES virtual/flex, and that sounds like a strange kind of virtual to have since I don't think there are any alternative implementations of flex. (But if bison actually depends on lex generically, rather than flex specifically, it might make some sense to introduce a virtual/lex and have flex PROVIDE it.) is there another popular lexer apart from flex? And will bison build with it? Well, there's lex itself obviously. I'm not sure whether bison will actually work with it, and I guess the majority of lex afficionados will probably be using yacc rather than bison in any case, so it probably isn't all that big a deal. But if bison does indeed support non-flex implementations of lex then it would be nice to expose that in the metadata. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] OE weekly changelog 2010-08-09 to 2010-08-16
OE weekly changelog for org.openembedded.dev, 2010-08-09 to 2010-08-16 Andrea Adami (4): klibc: remove old unused 1.5 and 1.5.15 recipes. klibc: remove now unused OE losetup patch (upstream since 1.5.17) kexecboot: bump to 5e020abcb38b7dcfeb1eed2350a4221e7bda7020 klibc: bump to 1.5.19 Christian Rüb (1): advancedcaching: new version 0.6.1.5 Enrico Scholz (1): ncurses: swapped installation of widec and narrowc headers Frans Meulenbroeks (208): cdparanoia: oe-stylize tgt: oe-stylize mythtv: removed tabs cdstatus: removed tabs MAINTAINERS: updated my entry openmoko: removed distro openmoko: removed distro mokoslug.conf: removed distro angstrom-2007-for-openmoko.inc: removed MAINTAINERS: removed openmoko distro maintainer as openmoko has been termina alsa: removed old versions abiword: removed 2.5.2; 3 years old and default pref -1 autoconf: remove a few old unused versions zziplib: remove old versions zeroconf 0.6.1: removed (5 years old) zeroconf: renamed files to zeroconf-0.9 cdparanoia_9.8alpha.bb: removed old version dpkg: remove old unpinned versions urjtag: added git version mythtv: upgraded to SRCREV 25609 serload-native: Removing legacy staging genboot-native: Removing legacy staging gcc4.2.x: patch Makefile.in for cross compile badness sdcc: removed old version libidl: remove old version 0.8.10 intltool: removed old versions intltool/files: removed; was only used by now removed recipes gmp: removed old versions preferred-om-2009-versions.inc: removed; unused and om is not supported any gcc4.5: patch Makefile.in for cross compile badness guile: removed unused 1.8.5 and 1.8.6 orbit2: removed old versions coreutils: removed old versions devio: removed some old versions libtool: removed some old versions php: removed some old versions apt: remvoed old 0.7.3 version m4: removed old version 1.4.8 dtc: removed old 1.1 version gcc4.3.x: patch Makefile.in for cross compile badness gcc4.4.x: patch Makefile.in for cross compile badness sqlite: removed 3.6.2 and 3.6.5 patchutils: remove old versions raptor: added recipe flickcurl: moved to 1.19, updated deps hamlib: remove old version xfsprogs: removed old version xscreensaver: removed old version zsh: remove old version openvpn: removed old versions openswan: removed old version openssh: remove old versions; these have security vulnerabilities that are s hostap: remove 0.4.4 quilt: remove old versions quagga: remove old versions qemu: removed old version mt-daapd: removed old versions libmusicbrainz: remove old versions enchant: remove old versions chicken: removed old versions c-ares: removed old versions wxwidgets: removed FILESDIR cmake: remove old versions xvidcap remove old versions xvidcap: fixed up DEPENDS opie-dagger: moved to nonworking; depends on sword which is in nonworking nonworking/php: removed nonworking/icecast: removed nonworking/e2fsprogs:removed e2fsprogs: remove old versions minisip: moved to nonworking obsolete/quilt: removed; newer version exists in recipes obsolete/zd1211: newer version in recipes xvidcap: moved to 1.1.7 xvidcap_1.1.7rc1.bb: deleted, apparently missed it in my previous commit vim: remved FILESDIR from inc; renamed patches dir vim: removed old patch zlib: renamed and split files dir zd1211: removed files dir zziplib: removed stale patch file zziplib moved files dir to zziplib zenity: removed old version pyorbit: remove old version libbonobo: removed old versions libbonoboui: remove old versions libwnck: remove old versions metacity: remove old version libgnomeui: removed old versions libgnomeprintui; remove old versions libgnomeprint: remove old versions libgnomecanvas: remove old versions libgnomecups: remove old versions libgnomekbd: remove old versions libgnome: remove old versions cheese: remove old versions at-spi: remove old versions epiphany-extensions: remove old versions epiphany: remove old versions gconf: remove old versions gconf-editor: remove old versions gdm: remove old versions gedit-plugins: remove old versions gedit: remove old versions gnumeric: remove old versions goffice: remove old versions gvfs: remove old versions system-tools-backends: remove old versions libxklavier: remove old versions libunique: remove old versions libsoup-2.4: remove old versions libsoup: remove old versions liboobs: remove old versions libgweather: remove old versions libgtop: remove old versions libgsf: remove old versions libgdata: remove old versions libart-lgpl: remove old versions gnome-applets: remove old versions gnome-bluetooth: remove old versions gnome-common: remove old versions gnome-control-center: remove old versions gnome-cups-manager: remove old versions gnome-desktop: remove old versions gnome-doc-utils: remove old versions gnome-dvb-daemon: remove
Re: [oe] What to do about the poor bitbake Quality Control?
On Sun, Aug 15, 2010 at 11:38 PM, Gary Thomas g...@mlbassoc.com wrote: The biggest problem (as discussed at great length already) is that the distance from 'dev' to 'stable' can be measured in years :-( 'stable' just isn't useful at all for current work... I must admit that some percentage of the time I also experience build errors, but I've simply adapted my work-flow to deal with it. For my project work, I simply build over the course of a week or so until I get something stable, and then lock down my OE version for my development. I think it would be very useful to have a stable branch that is only synchronised with dev when X number of targets build from a clean build. It seems like this would be high value, with little effort. Of course there will be corner things that break, but at least a new beagleboard user can check out something and have reasonable confidence that it will build images. Does anyone have suggestions for the branch name and a reasonable subset of machines and build targets? Perhaps someone is already running these clean builds? At one point we had a machine at OSUOSL dedicated to this purpose, but no one ever set it up. Thanks, Cliff -- = http://bec-systems.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OE on my new tablet. How write a new machine conf file?
On Fri, Aug 13, 2010 at 4:46 PM, Davide Pasini ilp...@inwind.it wrote: Hi all I'm new in OpenEmbedded and it is a very good idea! Maybe this is not the right place for a newbie help req but the user mail list is a desert. I bought a china tablet few days ago. It has Android or WinCe OS. I'd like to install a linux distro on it. I'm trying to build my distro (minimal distro with only a shell interface) but I'm lost in the .conf files. Obviously my machine is not in the machines list and I'd like to create an ad-hoc conf file maybe starting from an existing machine file. my device mount an ARM 11 (ARM v6) CPU and this is the link to some additional infos http://forum.xda-developers.com/showthread.php?t=740631 How write a new machine conf file? Any help is appreciated. Just look at the existing ones and copy/modify one that is reasonably close. The other thing that is typically required is to add/modify a kernel recipe for your machine. See: http://wiki.openembedded.net/index.php/Adding_a_new_Machine for more information. Thanks, Cliff -- = http://bec-systems.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Write access for Simon Busch
Am 17.08.2010 14:06, schrieb Stefan Schmidt: Hello. Over the last days I reviewed some patches from him. I have done this earlier as well and have the feeling that he it ready for write access now. The work was done well and he was always open for feedback and happy to fix other issues around the original problem. regards Stefan Schmidt Thank you Stefan for proposing me and all other for the approvement! regards, morphis ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] flex: disabled packaged staging of native builds
Frans Meulenbroeks wrote:
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
On Mon, Aug 16, 2010 at 7:43 PM, Tom Rini tom_r...@mentor.com wrote:
Jason Kridner wrote:
---
recipes/flex/flex.inc |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/recipes/flex/flex.inc b/recipes/flex/flex.inc
index 49b26e8..5d3f076 100644
--- a/recipes/flex/flex.inc
+++ b/recipes/flex/flex.inc
@@ -4,7 +4,7 @@ LICENSE = BSD
DEPENDS = gettext
-INC_PR = r5
+INC_PR = r6
S = ${WORKDIR}/flex-${PV}
@@ -16,3 +16,5 @@ inherit autotools gettext
# static-only library; that might be an error
FILES_${PN} += ${libdir}/libfl.a
+
+PSTAGING_DISABLED_virtclass-native = 1
I assume you've ran into 2.3.35 not being relocation happy? Have you been
able to look at this at all? 2.3.31 works so it's something 'bad' done
upstream. Thanks!
I did, but I didn't look into the details. bison-native wouldn't
rebuild when I used my flex-native pstage. bitbake -c clean
flex-native fixed it, so...
After that would rebuilding from pstage cause the error again?
I'm a little bit worried that we inhibit PSTAGING because e.g.
something else is wrong (e.g. a change elsewhere that should have been
resulted in a flex PR bump).
So, this change is fine itself. The problem is that flex 2.3.35 has
introduced a hardcoded path somewhere into the binary. So blacklisting
and bumping PR means that pstaging is sane again.
Besides (but this is more a global remark): it would be nice if a
recipe disables something that there is a short description why this
is done. (at least in the commit message, but imho preferably in the
recipe, so in half a year time, people still know why it is done and
can much easier judge if it can be removed).
Yes, I agree with that, a comment why is good.
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Usage of NATIVE_INSTALL_WORKS
Chris Larson wrote:
On Mon, Aug 16, 2010 at 4:37 AM, Enrico Scholz
enrico.sch...@sigma-chemnitz.de wrote:
Hi,
http://wiki.openembedded.org/index.php/Legacy_staging states that
NATIVE_INSTALL_WORKS must be set when there is a non trivial
do_install() function and BBCLASSEXTEND is used.
But
| git grep NATIVE_INSTALL_WORKS conf/ classes/ lib/
shows only one place where this variable is evaluated:
| classes/staging.bbclass:elif bb.data.getVar('NATIVE_INSTALL_WORKS',
d, 1) == 1:
| classes/staging.bbclass-legacy = False
And there, it is used only in the is_legacy_staging() function, to
override legacy/non-legacy detection results.
Is there still any use for this variable in modern staging? Or shall it
be purged from non-legacy recipes?
If you purge it from particular non-legacy recipes, the legacy detection
code will misidentify those as legacy and fail to do the correct thing.
Can we update the wiki page to expand on when this is needed a little
bit more then? My quick read of is_legacy_staging() says that if
do_stage is empty (and it should be if you convert from do_stage to
do_install right) NATIVE_INSTALL_WORKS shouldn't be needed.
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Usage of NATIVE_INSTALL_WORKS
On Tue, Aug 17, 2010 at 10:48 AM, Tom Rini tom_r...@mentor.com wrote:
Chris Larson wrote:
On Mon, Aug 16, 2010 at 4:37 AM, Enrico Scholz
enrico.sch...@sigma-chemnitz.de wrote:
Hi,
http://wiki.openembedded.org/index.php/Legacy_staging states that
NATIVE_INSTALL_WORKS must be set when there is a non trivial
do_install() function and BBCLASSEXTEND is used.
But
| git grep NATIVE_INSTALL_WORKS conf/ classes/ lib/
shows only one place where this variable is evaluated:
| classes/staging.bbclass:elif bb.data.getVar('NATIVE_INSTALL_WORKS',
d, 1) == 1:
| classes/staging.bbclass-legacy = False
And there, it is used only in the is_legacy_staging() function, to
override legacy/non-legacy detection results.
Is there still any use for this variable in modern staging? Or shall it
be purged from non-legacy recipes?
If you purge it from particular non-legacy recipes, the legacy detection
code will misidentify those as legacy and fail to do the correct thing.
Can we update the wiki page to expand on when this is needed a little bit
more then? My quick read of is_legacy_staging() says that if do_stage is
empty (and it should be if you convert from do_stage to do_install right)
NATIVE_INSTALL_WORKS shouldn't be needed.
Removing the do_stage function from the recipe doesn't necessarily result in
an empty do_stage. If you look at native.bbclass, you'll see that do_stage
is do_stage_native. If your do_stage is do_stage_native and you haven't set
AUTOTOOLS_NATIVE_STAGE_INSTALL, it'll fall back to legacy staging, at least
if I'm reading is_legacy_staging correctly.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Usage of NATIVE_INSTALL_WORKS
Chris Larson wrote:
On Tue, Aug 17, 2010 at 10:48 AM, Tom Rini tom_r...@mentor.com wrote:
Chris Larson wrote:
On Mon, Aug 16, 2010 at 4:37 AM, Enrico Scholz
enrico.sch...@sigma-chemnitz.de wrote:
Hi,
http://wiki.openembedded.org/index.php/Legacy_staging states that
NATIVE_INSTALL_WORKS must be set when there is a non trivial
do_install() function and BBCLASSEXTEND is used.
But
| git grep NATIVE_INSTALL_WORKS conf/ classes/ lib/
shows only one place where this variable is evaluated:
| classes/staging.bbclass:elif bb.data.getVar('NATIVE_INSTALL_WORKS',
d, 1) == 1:
| classes/staging.bbclass-legacy = False
And there, it is used only in the is_legacy_staging() function, to
override legacy/non-legacy detection results.
Is there still any use for this variable in modern staging? Or shall it
be purged from non-legacy recipes?
If you purge it from particular non-legacy recipes, the legacy detection
code will misidentify those as legacy and fail to do the correct thing.
Can we update the wiki page to expand on when this is needed a little bit
more then? My quick read of is_legacy_staging() says that if do_stage is
empty (and it should be if you convert from do_stage to do_install right)
NATIVE_INSTALL_WORKS shouldn't be needed.
Removing the do_stage function from the recipe doesn't necessarily result in
an empty do_stage. If you look at native.bbclass, you'll see that do_stage
is do_stage_native. If your do_stage is do_stage_native and you haven't set
AUTOTOOLS_NATIVE_STAGE_INSTALL, it'll fall back to legacy staging, at least
if I'm reading is_legacy_staging correctly.
So, perhaps it's time to convert that real quick? Or is there some
reason I'm not seeing as to why we wouldn't want to:
- Change native.bbclass do_stage / do_stage_native to do_install /
do_install
- Drop NATIVE_INSTALL_WORKS
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] bison: add flex dependency
On Tue, Aug 17, 2010 at 9:57 AM, Phil Blundell ph...@gnu.org wrote: On Mon, 2010-08-16 at 16:26 -0500, Jason Kridner wrote: -DEPENDS = virtual/libintl +DEPENDS = virtual/libintl virtual/flex Does this actually work? No. Sorry for the bad patch. I couldn't immediately spot any obvious package which PROVIDES virtual/flex, and that sounds like a strange kind of virtual to have since I don't think there are any alternative implementations of flex. (But if bison actually depends on lex generically, rather than flex specifically, it might make some sense to introduce a virtual/lex and have flex PROVIDE it.) p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] flex: disabled packaged staging of native builds
flex-2.5.35 introduced a hardcoded path somewhere that prevents packaged
staging from working.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/flex/flex.inc |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/recipes/flex/flex.inc b/recipes/flex/flex.inc
index 49b26e8..39f4ec2 100644
--- a/recipes/flex/flex.inc
+++ b/recipes/flex/flex.inc
@@ -4,7 +4,7 @@ LICENSE = BSD
DEPENDS = gettext
-INC_PR = r5
+INC_PR = r6
S = ${WORKDIR}/flex-${PV}
@@ -16,3 +16,6 @@ inherit autotools gettext
# static-only library; that might be an error
FILES_${PN} += ${libdir}/libfl.a
+
+# flex-2.5.35 adds a hard-coded path that causes failures when using packaged
staging
+PSTAGING_DISABLED_virtclass-native = 1
--
1.5.6.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] beagleboard-test-image: add g_ether kernel module
Signed-off-by: Jason Kridner jkrid...@beagleboard.org --- recipes/images/beagleboard-test-image.bb |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/recipes/images/beagleboard-test-image.bb b/recipes/images/beagleboard-test-image.bb index cbb2e7d..71cbbab 100644 --- a/recipes/images/beagleboard-test-image.bb +++ b/recipes/images/beagleboard-test-image.bb @@ -20,6 +20,7 @@ IMAGE_INSTALL += \ nano \ cpuburn-neon \ kernel-module-mt9t112 \ + kernel-module-g-ether \ u-boot-mkimage \ sox \ devmem2 \ -- 1.5.6.4 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] beagleboard-olddemo-image: saved off beagleboard-demo-image
I want to use the name beagleboard-demo-image for what actually ships
with the xM boards.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/images/beagleboard-olddemo-image.bb | 30 +++
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 recipes/images/beagleboard-olddemo-image.bb
diff --git a/recipes/images/beagleboard-olddemo-image.bb
b/recipes/images/beagleboard-olddemo-image.bb
new file mode 100644
index 000..d83281c
--- /dev/null
+++ b/recipes/images/beagleboard-olddemo-image.bb
@@ -0,0 +1,30 @@
+# Demo image for beagleboard
+
+IMAGE_LINGUAS = de-de fr-fr en-gb en-us pt-br es-es kn-in ml-in ta-in
+
+XSERVER ?= xserver-xorg \
+ xf86-input-evdev \
+ xf86-input-mouse \
+ xf86-video-fbdev \
+ xf86-input-keyboard \
+
+
+ANGSTROM_EXTRA_INSTALL ?=
+SPLASH = exquisite exquisite-themes exquisite-theme-angstrom
+
+export IMAGE_BASENAME = Beagleboard-demo-image
+
+DEPENDS = task-base
+IMAGE_INSTALL = \
+${XSERVER} \
+${ANGSTROM_EXTRA_INSTALL} \
+task-beagleboard-demo \
+${SPLASH} \
+
+
+IMAGE_PREPROCESS_COMMAND = create_etc_timestamp
+
+#zap root password for release images
+ROOTFS_POSTPROCESS_COMMAND += 'install_linguas;
$...@base_conditional(DISTRO_TYPE, release, zap_root_password; , ,d)}'
+
+inherit image
--
1.5.6.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] quilt: disable packaged staging on native builds
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/quilt/quilt-native.inc |3 +++
recipes/quilt/quilt_0.48.bb|2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/recipes/quilt/quilt-native.inc b/recipes/quilt/quilt-native.inc
index 10d8183..f422b63 100644
--- a/recipes/quilt/quilt-native.inc
+++ b/recipes/quilt/quilt-native.inc
@@ -6,6 +6,9 @@ RDEPENDS_${PN} = diffstat-native patch-native bzip2-native
util-linux-native
FILESPATHPKG =. quilt-${PV}
INHIBIT_AUTOTOOLS_DEPS = 1
+# Several packages fail to patch when using quilt from packaged staging
+PSTAGING_DISABLED_virtclass-native = 1
+
inherit autotools native
PATCHTOOL = patch
diff --git a/recipes/quilt/quilt_0.48.bb b/recipes/quilt/quilt_0.48.bb
index 0a066df..99dc2a2 100644
--- a/recipes/quilt/quilt_0.48.bb
+++ b/recipes/quilt/quilt_0.48.bb
@@ -1,6 +1,6 @@
require quilt-package.inc
-PR=r1
+PR=r2
SRC_URI[md5sum] = f77adda60039ffa753f3c584a286f12b
SRC_URI[sha256sum] =
73fd760d3b5cbf06417576591dc37d67380d189392db9000c21b7cbebee49ffc
--
1.5.6.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] beagleboard-olddemo-image: saved off beagleboard-demo-image
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
I want to use the name beagleboard-demo-image for what actually ships
with the xM boards.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/images/beagleboard-olddemo-image.bb | 30
+++
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 recipes/images/beagleboard-olddemo-image.bb
diff --git a/recipes/images/beagleboard-olddemo-image.bb
b/recipes/images/beagleboard-olddemo-image.bb
new file mode 100644
index 000..d83281c
--- /dev/null
+++ b/recipes/images/beagleboard-olddemo-image.bb
@@ -0,0 +1,30 @@
+# Demo image for beagleboard
+
+IMAGE_LINGUAS = de-de fr-fr en-gb en-us pt-br es-es kn-in ml-in ta-in
+
+XSERVER ?= xserver-xorg \
+ xf86-input-evdev \
+ xf86-input-mouse \
+ xf86-video-fbdev \
+ xf86-input-keyboard \
+
+
+ANGSTROM_EXTRA_INSTALL ?=
+SPLASH = exquisite exquisite-themes exquisite-theme-angstrom
+
+export IMAGE_BASENAME = Beagleboard-demo-image
+
+DEPENDS = task-base
+IMAGE_INSTALL = \
+ ${XSERVER} \
+ ${ANGSTROM_EXTRA_INSTALL} \
+ task-beagleboard-demo \
+ ${SPLASH} \
+
+
+IMAGE_PREPROCESS_COMMAND = create_etc_timestamp
+
+#zap root password for release images
+ROOTFS_POSTPROCESS_COMMAND += 'install_linguas;
$...@base_conditional(DISTRO_TYPE, release, zap_root_password; , ,d)}'
+
+inherit image
--
What about a better name? E.g. XM-demo-iimage?
And to widen the question: do we want to maintain customer/supplier
specific images in the oe repo?
The company I work for also has some images, but for now we opted to
keep them in a private overlay.
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] quilt: disable packaged staging on native builds
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/quilt/quilt-native.inc | 3 +++
recipes/quilt/quilt_0.48.bb | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/recipes/quilt/quilt-native.inc b/recipes/quilt/quilt-native.inc
index 10d8183..f422b63 100644
--- a/recipes/quilt/quilt-native.inc
+++ b/recipes/quilt/quilt-native.inc
@@ -6,6 +6,9 @@ RDEPENDS_${PN} = diffstat-native patch-native bzip2-native
util-linux-native
FILESPATHPKG =. quilt-${PV}
INHIBIT_AUTOTOOLS_DEPS = 1
+# Several packages fail to patch when using quilt from packaged staging
+PSTAGING_DISABLED_virtclass-native = 1
+
inherit autotools native
PATCHTOOL = patch
diff --git a/recipes/quilt/quilt_0.48.bb b/recipes/quilt/quilt_0.48.bb
index 0a066df..99dc2a2 100644
--- a/recipes/quilt/quilt_0.48.bb
+++ b/recipes/quilt/quilt_0.48.bb
@@ -1,6 +1,6 @@
require quilt-package.inc
-PR=r1
+PR=r2
SRC_URI[md5sum] = f77adda60039ffa753f3c584a286f12b
SRC_URI[sha256sum] =
73fd760d3b5cbf06417576591dc37d67380d189392db9000c21b7cbebee49ffc
--
1.5.6.4
I have some concerns with this patch.
I have a quilt native in my pstage dir from aug 7. (pstage is outside TMPDIR)
Just did a bitbake beagleboard-demo-image after removing TMPDIR, with
quilt-native and quite some other packages in my pstage dir.
I am at Running task 7313 of 11636, lots of packages have been
compiled and no patch has failed.
My proposal is to put this patch on hold until proven to be an issue
by someone else.
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] esc-gst: added revision 6
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/esc/esc-gst_6.bb | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 recipes/esc/esc-gst_6.bb
diff --git a/recipes/esc/esc-gst_6.bb b/recipes/esc/esc-gst_6.bb
new file mode 100644
index 000..88840db
--- /dev/null
+++ b/recipes/esc/esc-gst_6.bb
@@ -0,0 +1,23 @@
+DESCRIPTION = Gstreamer scripts for Embedded Systems Conference workshop
+LICENSE = Various
+
+SRC_URI =
http://hivelocity.dl.sourceforge.net/project/showoff/esc_gst_scripts.tar.gz \
+
+SRC_URI[md5sum] = 944f4ea58e81c3a32b947322ac8f9e1d
+SRC_URI[sha256sum] =
589c3b611406f255204e1993e470d0d69ac8f12ff479febf4d5dc92915f982da
+
+S = ${WORKDIR}/esc-gst
+
+do_install() {
+ESC_FILES=a1 a2 a3 a4 a5 a6 d1 d2 d3 d4 d5 d6 g1 g2 g3 g4 g5 g6 g7 g8 g9
+ESC_FILES=${ESC_FILES} n1 n2 n3 n4 p1 s v1 v2 v3 v4
+install -d ${D}${datadir}/esc-gst
+for F in ${ESC_FILES} ; do
+install -m 0755 ${S}/${F} ${D}${datadir}/esc-gst
+done
+install -m 0644 ${S}/README ${D}${datadir}/esc-gst
+install -d ${D}${datadir}/applications
+install -m 0644 ${S}/GStreamer_Class.desktop ${D}${datadir}/applications/
+}
+
+FILES_${PN} += ${datadir}/esc-gst
--
1.5.6.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] beagleboard-olddemo-image: saved off beagleboard-demo-image
On 08/17/2010 12:54 PM, Frans Meulenbroeks wrote: 2010/8/17 Jason Kridnerjkrid...@beagleboard.org: I want to use the name beagleboard-demo-image for what actually ships with the xM boards. +inherit image -- What about a better name? E.g. XM-demo-iimage? And to widen the question: do we want to maintain customer/supplier specific images in the oe repo? The company I work for also has some images, but for now we opted to keep them in a private overlay. In this case, beagleboard.org points people at oe dev to do builds, so it is appropriate to have this image in dev. I do think they should just edit the existing file, no need to save the old one. I suspect that 90% of people using the beagle build images from narcissus anyway. Philip ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] quilt: disable packaged staging on native builds
On Tue, Aug 17, 2010 at 1:03 PM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/quilt/quilt-native.inc |3 +++
recipes/quilt/quilt_0.48.bb|2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/recipes/quilt/quilt-native.inc
b/recipes/quilt/quilt-native.inc
index 10d8183..f422b63 100644
--- a/recipes/quilt/quilt-native.inc
+++ b/recipes/quilt/quilt-native.inc
@@ -6,6 +6,9 @@ RDEPENDS_${PN} = diffstat-native patch-native
bzip2-native util-linux-native
FILESPATHPKG =. quilt-${PV}
INHIBIT_AUTOTOOLS_DEPS = 1
+# Several packages fail to patch when using quilt from packaged staging
+PSTAGING_DISABLED_virtclass-native = 1
+
inherit autotools native
PATCHTOOL = patch
diff --git a/recipes/quilt/quilt_0.48.bb b/recipes/quilt/quilt_0.48.bb
index 0a066df..99dc2a2 100644
--- a/recipes/quilt/quilt_0.48.bb
+++ b/recipes/quilt/quilt_0.48.bb
@@ -1,6 +1,6 @@
require quilt-package.inc
-PR=r1
+PR=r2
SRC_URI[md5sum] = f77adda60039ffa753f3c584a286f12b
SRC_URI[sha256sum] =
73fd760d3b5cbf06417576591dc37d67380d189392db9000c21b7cbebee49ffc
--
1.5.6.4
I have some concerns with this patch.
I have a quilt native in my pstage dir from aug 7. (pstage is outside
TMPDIR)
Just did a bitbake beagleboard-demo-image after removing TMPDIR, with
quilt-native and quite some other packages in my pstage dir.
I am at Running task 7313 of 11636, lots of packages have been
compiled and no patch has failed.
My proposal is to put this patch on hold until proven to be an issue
by someone else.
Did you build with TMPDIR in a *different* location using prebuilts? If not
you didn't prove anything at all about the relocatability of quilt. If a
package isn't relocatable, it shouldn't be enabled for pstaging, as the
package can't be used reliably.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] beagleboard-olddemo-image: saved off beagleboard-demo-image
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
On Tue, Aug 17, 2010 at 3:54 PM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
I want to use the name beagleboard-demo-image for what actually ships
with the xM boards.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/images/beagleboard-olddemo-image.bb | 30
+++
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 recipes/images/beagleboard-olddemo-image.bb
diff --git a/recipes/images/beagleboard-olddemo-image.bb
b/recipes/images/beagleboard-olddemo-image.bb
new file mode 100644
index 000..d83281c
--- /dev/null
+++ b/recipes/images/beagleboard-olddemo-image.bb
@@ -0,0 +1,30 @@
+# Demo image for beagleboard
+
+IMAGE_LINGUAS = de-de fr-fr en-gb en-us pt-br es-es kn-in ml-in ta-in
+
+XSERVER ?= xserver-xorg \
+ xf86-input-evdev \
+ xf86-input-mouse \
+ xf86-video-fbdev \
+ xf86-input-keyboard \
+
+
+ANGSTROM_EXTRA_INSTALL ?=
+SPLASH = exquisite exquisite-themes exquisite-theme-angstrom
+
+export IMAGE_BASENAME = Beagleboard-demo-image
+
+DEPENDS = task-base
+IMAGE_INSTALL = \
+ ${XSERVER} \
+ ${ANGSTROM_EXTRA_INSTALL} \
+ task-beagleboard-demo \
+ ${SPLASH} \
+
+
+IMAGE_PREPROCESS_COMMAND = create_etc_timestamp
+
+#zap root password for release images
+ROOTFS_POSTPROCESS_COMMAND += 'install_linguas;
$...@base_conditional(DISTRO_TYPE, release, zap_root_password; ,
,d)}'
+
+inherit image
--
What about a better name? E.g. XM-demo-iimage?
I don't know why we need two demo images. This should run on Rev Cx as well.
Actually XM-demo-image was just a proposal
For me beagleboard-olddemo-image indicates that it is not really an up
to date version.
I think I would prefer a name that better indicates the purpose. Maybe
add stable in the name?
Another option would be to have the image delivered with the XM as
e.g. beagleboard-demo-image_1.0 and the newer versions e.g. 1.1 etc
(or 2.0 or whatever)
And to widen the question: do we want to maintain customer/supplier
specific images in the oe repo?
The company I work for also has some images, but for now we opted to
keep them in a private overlay.
I want this to be public and part of the mainline to make it easy for
people to reproduce. It is for a relatively broad target. Is there a
reason it shouldn't be there?
Ok, I understand that (and I have not really a problem with that). It
is just the name that didn't make me too happy.
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] beagleboard-olddemo-image: saved off beagleboard-demo-image
On Tue, Aug 17, 2010 at 5:01 PM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
On Tue, Aug 17, 2010 at 3:54 PM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
I want to use the name beagleboard-demo-image for what actually ships
with the xM boards.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/images/beagleboard-olddemo-image.bb | 30
+++
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 recipes/images/beagleboard-olddemo-image.bb
diff --git a/recipes/images/beagleboard-olddemo-image.bb
b/recipes/images/beagleboard-olddemo-image.bb
new file mode 100644
index 000..d83281c
--- /dev/null
+++ b/recipes/images/beagleboard-olddemo-image.bb
@@ -0,0 +1,30 @@
+# Demo image for beagleboard
+
+IMAGE_LINGUAS = de-de fr-fr en-gb en-us pt-br es-es kn-in ml-in ta-in
+
+XSERVER ?= xserver-xorg \
+ xf86-input-evdev \
+ xf86-input-mouse \
+ xf86-video-fbdev \
+ xf86-input-keyboard \
+
+
+ANGSTROM_EXTRA_INSTALL ?=
+SPLASH = exquisite exquisite-themes exquisite-theme-angstrom
+
+export IMAGE_BASENAME = Beagleboard-demo-image
+
+DEPENDS = task-base
+IMAGE_INSTALL = \
+ ${XSERVER} \
+ ${ANGSTROM_EXTRA_INSTALL} \
+ task-beagleboard-demo \
+ ${SPLASH} \
+
+
+IMAGE_PREPROCESS_COMMAND = create_etc_timestamp
+
+#zap root password for release images
+ROOTFS_POSTPROCESS_COMMAND += 'install_linguas;
$...@base_conditional(DISTRO_TYPE, release, zap_root_password; ,
,d)}'
+
+inherit image
--
What about a better name? E.g. XM-demo-iimage?
I don't know why we need two demo images. This should run on Rev Cx as well.
Actually XM-demo-image was just a proposal
For me beagleboard-olddemo-image indicates that it is not really an up
to date version.
I think I would prefer a name that better indicates the purpose. Maybe
add stable in the name?
Another option would be to have the image delivered with the XM as
e.g. beagleboard-demo-image_1.0 and the newer versions e.g. 1.1 etc
(or 2.0 or whatever)
Koen wanted to keep the old one around--I'm not sure for what purpose.
And to widen the question: do we want to maintain customer/supplier
specific images in the oe repo?
The company I work for also has some images, but for now we opted to
keep them in a private overlay.
I want this to be public and part of the mainline to make it easy for
people to reproduce. It is for a relatively broad target. Is there a
reason it shouldn't be there?
Ok, I understand that (and I have not really a problem with that). It
is just the name that didn't make me too happy.
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] beagleboard-olddemo-image: saved off beagleboard-demo-image
Am Dienstag, den 17.08.2010, 23:01 +0200 schrieb Frans Meulenbroeks:
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
On Tue, Aug 17, 2010 at 3:54 PM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
2010/8/17 Jason Kridner jkrid...@beagleboard.org:
I want to use the name beagleboard-demo-image for what actually ships
with the xM boards.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/images/beagleboard-olddemo-image.bb | 30
+++
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 recipes/images/beagleboard-olddemo-image.bb
diff --git a/recipes/images/beagleboard-olddemo-image.bb
b/recipes/images/beagleboard-olddemo-image.bb
new file mode 100644
index 000..d83281c
--- /dev/null
+++ b/recipes/images/beagleboard-olddemo-image.bb
@@ -0,0 +1,30 @@
+# Demo image for beagleboard
+
+IMAGE_LINGUAS = de-de fr-fr en-gb en-us pt-br es-es kn-in ml-in ta-in
+
+XSERVER ?= xserver-xorg \
+ xf86-input-evdev \
+ xf86-input-mouse \
+ xf86-video-fbdev \
+ xf86-input-keyboard \
+
+
+ANGSTROM_EXTRA_INSTALL ?=
+SPLASH = exquisite exquisite-themes exquisite-theme-angstrom
+
+export IMAGE_BASENAME = Beagleboard-demo-image
+
+DEPENDS = task-base
+IMAGE_INSTALL = \
+${XSERVER} \
+${ANGSTROM_EXTRA_INSTALL} \
+task-beagleboard-demo \
+${SPLASH} \
+
+
+IMAGE_PREPROCESS_COMMAND = create_etc_timestamp
+
+#zap root password for release images
+ROOTFS_POSTPROCESS_COMMAND += 'install_linguas;
$...@base_conditional(DISTRO_TYPE, release, zap_root_password; ,
,d)}'
+
+inherit image
--
What about a better name? E.g. XM-demo-iimage?
I don't know why we need two demo images. This should run on Rev Cx as
well.
Actually XM-demo-image was just a proposal
For me beagleboard-olddemo-image indicates that it is not really an up
to date version.
I think I would prefer a name that better indicates the purpose. Maybe
add stable in the name?
So why create an “old” image? What is the difference between these two
images anyway?
Another option would be to have the image delivered with the XM as
e.g. beagleboard-demo-image_1.0 and the newer versions e.g. 1.1 etc
(or 2.0 or whatever)
[…]
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] esc-media: updated revision
Added startup.wav (missed it the first time).
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/esc/esc-media_5.bb | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 recipes/esc/esc-media_5.bb
diff --git a/recipes/esc/esc-media_5.bb b/recipes/esc/esc-media_5.bb
new file mode 100644
index 000..6572cf6
--- /dev/null
+++ b/recipes/esc/esc-media_5.bb
@@ -0,0 +1,23 @@
+DESCRIPTION = Media files to include on the Embedded Systems Conference
workshop
+LICENSE=Various
+
+SRC_URI =
http://hivelocity.dl.sourceforge.net/project/showoff/esc_media_files.tar.gz;
+SRC_URI[md5sum] = 54b69a8568cc99b836eb7ce40c9bd2a2
+SRC_URI[sha256sum] =
f4c43ba2b7cfb3e3c6d3ce87dc63194c76fbe1a905a9cebc0102a615165bed59
+
+S=${WORKDIR}/esc_media_files
+
+do_install() {
+ESC_MEDIA=2009-obama-congress-speech.avi AlphaAnimal.license \
+ AlphaAnimal.m4a BigBuckBunny_640x360.m4v bbb.flac \
+ bbb.mp3 bbb.ogg davincieffect.aac gstreamer-logo.svg \
+ sprc720.flv startup.wav
+
+install -d ${D}${datadir}/esc-media
+for F in ${ESC_MEDIA} ; do
+install -m 0644 ${S}/${F} ${D}${datadir}/esc-media
+done
+}
+
+FILES_${PN} += ${datadir}/esc-media
+
--
1.5.6.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] evince_2.30.0.bb: Problem with new style staging?
On Tue, Aug 17, 2010 at 12:30 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
Am Sonntag, den 15.08.2010, 20:45 +0200 schrieb Paul Menzel:
Am Sonntag, den 15.08.2010, 10:46 +0200 schrieb Paul Menzel:
I set up a basic build host with no GNOME installed and did `bitbake
beagleboard-demo-image` with the standard local.conf provided by
Ȧngström and org.openembedded.dev.
Compile is failing because it is looking for a file on the build hosts
environment (and not stagang(?)).
xsltproc -o evince-C.omf --stringparam db2omf.basename evince
--stringparam db2omf.format 'docbook' --stringparam db2omf.dtd
-//OASIS//DTD DocBook XML V4.1.2//EN --stringparam db2omf.lang C
--stringparam db2omf.omf_dir /usr/share/omf --stringparam
db2omf.help_dir /usr/share/gnome/help --stringparam db2omf.omf_in
/home/paul/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/evince-2.30.0-r1/evince-2.30.0/help/evince.omf.in
`/home/paul/oe/build/angstrom-dev/sysroots/i686-linux/usr/bin/pkg-config
--variable db2omf gnome-doc-utils` C/evince.xml || { rm -f evince-C.omf;
exit 1; }
warning: failed to load external entity
/usr/share/xml/gnome/xslt/docbook/omf/db2omf.xsl
cannot parse /usr/share/xml/gnome/xslt/docbook/omf/db2omf.xsl
make[2]: *** [evince-C.omf] Error 1
make[2]: Leaving directory
`/home/paul/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/evince-2.30.0-r1/evince-2.30.0/help'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/paul/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/evince-2.30.0-r1/evince-2.30.0'
make: *** [all] Error 2
FATAL: oe_runmake failed
ERROR: Function do_compile failed
The call of `xsltproc` seems to point to the wrong location. Does anyone
know how to fix this error besides installing those files on the build
host?
Judging from `run.do_compile.6321` `PKG_CONFIG_PATH` gets set
incorrectly.
export
PKG_CONFIG_PATH=/oe/build/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig:/oe/build/angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/share/pkgconfig
I checked `gnome-doc-utils.pc` in these directories and both point to
`/usr/share/xml/gnome/xslt/docbook/omf/db2omf.xsl`, which is incorrect
(`datadir=/usr/share`)
In the staging(?) path
`/oe/build/angstrom-dev/sysroots/i686-linux/usr/lib/pkgconfig/`
everything is set up correctly.
datadir=/oe/build/angstrom-dev/sysroots/i686-linux/usr/share
Also running
/oe/build/angstrom-dev/sysroots/i686-linux/usr/bin/pkg-config
--variable db2omf gnome-doc-utils
in a clean environment without exporting `PKG_CONFIG_PATH` works.
Is this a problem with new style staging? Could you please provide a
hint on how to fix this.
I am stuck. Could someone take a look at this please and give me a hint
on how to proceed? (I know the week just started.)
I fixed it. Update evince and see if it builds for you now.
Thanks,
Paul
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] quilt: disable packaged staging on native builds
Jason Kridner wrote:
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
recipes/quilt/quilt-native.inc |3 +++
recipes/quilt/quilt_0.48.bb|2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/recipes/quilt/quilt-native.inc b/recipes/quilt/quilt-native.inc
index 10d8183..f422b63 100644
--- a/recipes/quilt/quilt-native.inc
+++ b/recipes/quilt/quilt-native.inc
@@ -6,6 +6,9 @@ RDEPENDS_${PN} = diffstat-native patch-native bzip2-native
util-linux-native
FILESPATHPKG =. quilt-${PV}
INHIBIT_AUTOTOOLS_DEPS = 1
+# Several packages fail to patch when using quilt from packaged staging
+PSTAGING_DISABLED_virtclass-native = 1
+
inherit autotools native
PATCHTOOL = patch
diff --git a/recipes/quilt/quilt_0.48.bb b/recipes/quilt/quilt_0.48.bb
index 0a066df..99dc2a2 100644
--- a/recipes/quilt/quilt_0.48.bb
+++ b/recipes/quilt/quilt_0.48.bb
@@ -1,6 +1,6 @@
require quilt-package.inc
-PR=r1
+PR=r2
SRC_URI[md5sum] = f77adda60039ffa753f3c584a286f12b
SRC_URI[sha256sum] =
73fd760d3b5cbf06417576591dc37d67380d189392db9000c21b7cbebee49ffc
After some poking, testing and what I pushed recently, NAK. What's
going on here is that we didn't have a real non-legacy staging. As seen
in quilt-package.inc, the normal autotools install rules don't move the
install around for us, so we ended up with, in some cases (No, I can't
explain why off the top of my head, but yes, I've seen both what Jason
saw and what Frans saw in the past) empty pstaging packages, which means
no quilt, and a certain failure to apply patches. To Chris' concern,
I've gotten past the point of a patch being applied with quilt-native
from pstaging from a TMPDIR named differently than what I extracted
pstaging into.
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] x11vnc: replace definition of pointer
Avoids conflict with Xdefs.h definition of 'pointer'.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
...0001-replaced-pointer-with-x11vnc_pointer.patch | 237
recipes/vnc/x11vnc_0.9.11.bb |6 +-
2 files changed, 242 insertions(+), 1 deletions(-)
create mode 100644
recipes/vnc/files/0001-replaced-pointer-with-x11vnc_pointer.patch
diff --git a/recipes/vnc/files/0001-replaced-pointer-with-x11vnc_pointer.patch
b/recipes/vnc/files/0001-replaced-pointer-with-x11vnc_pointer.patch
new file mode 100644
index 000..1212299
--- /dev/null
+++ b/recipes/vnc/files/0001-replaced-pointer-with-x11vnc_pointer.patch
@@ -0,0 +1,237 @@
+From e1b41de977fef61a957ab871ed1f23c05cc2fd75 Mon Sep 17 00:00:00 2001
+From: Jason Kridner jkrid...@beagleboard.org
+Date: Wed, 18 Aug 2010 00:15:24 -0500
+Subject: [PATCH] replaced pointer() with x11vnc_pointer()
+
+Avoids conflict with pointer definition in /usr/include/X11/Xdefs.h.
+
+Signed-off-by: Jason Kridner jkrid...@beagleboard.org
+---
+ x11vnc/connections.c |2 +-
+ x11vnc/keyboard.c|4 ++--
+ x11vnc/pointer.c | 16
+ x11vnc/pointer.h |2 +-
+ x11vnc/remote.c |6 +++---
+ x11vnc/scan.c|4 ++--
+ x11vnc/screen.c |2 +-
+ x11vnc/userinput.c |8
+ 8 files changed, 22 insertions(+), 22 deletions(-)
+
+diff --git a/x11vnc/connections.c b/x11vnc/connections.c
+index 7c549ec..71a2bd1 100644
+--- a/x11vnc/connections.c
b/x11vnc/connections.c
+@@ -3145,7 +3145,7 @@ static void pmove(int x, int y) {
+ return;
+ }
+ rfbLog(pmove: x y: %d %d\n, x, y);
+- pointer(0, x, y, NULL);
++ x11vnc_pointer(0, x, y, NULL);
+ X_LOCK;
+ XFlush_wr(dpy);
+ X_UNLOCK;
+diff --git a/x11vnc/keyboard.c b/x11vnc/keyboard.c
+index 58e866d..613b8ab 100644
+--- a/x11vnc/keyboard.c
b/x11vnc/keyboard.c
+@@ -2898,9 +2898,9 @@ static void pipe_keyboard(rfbBool down, rfbKeySym
keysym, rfbClientPtr client) {
+ t[1] = '\0';
+ if (sscanf(t, %d, butt) == 1) {
+ mask = 1(butt-1);
+- pointer(mask, x, y, client);
++ x11vnc_pointer(mask, x, y, client);
+ mask = 0;
+- pointer(mask, x, y, client);
++ x11vnc_pointer(mask, x, y, client);
+ }
+ b++;
+ }
+diff --git a/x11vnc/pointer.c b/x11vnc/pointer.c
+index 5e11ed4..45cf47e 100644
+--- a/x11vnc/pointer.c
b/x11vnc/pointer.c
+@@ -54,7 +54,7 @@ int pointer_queued_sent = 0;
+
+ void initialize_pointer_map(char *pointer_remap);
+ void do_button_mask_change(int mask, int button);
+-void pointer(int mask, int x, int y, rfbClientPtr client);
++void x11vnc_pointer(int mask, int x, int y, rfbClientPtr client);
+ void initialize_pipeinput(void);
+ int check_pipeinput(void);
+ void update_x11_pointer_position(int x, int y);
+@@ -408,7 +408,7 @@ void do_button_mask_change(int mask, int button) {
+ continue;
+ }
+ if (debug_pointer) {
+- rfbLog(pointer(): sending button %d
++ rfbLog(x11vnc_pointer(): sending button %d
+%s (event %d)\n, mb, bmask
+ ? down : up, k+1);
+ }
+@@ -427,7 +427,7 @@ void do_button_mask_change(int mask, int button) {
+ if (debug_pointer dpy) {
+ char *str = XKeysymToString(XKeycodeToKeysym(
+ dpy, key, 0));
+- rfbLog(pointer(): sending button %d
++ rfbLog(x11vnc_pointer(): sending button %d
+ down as keycode 0x%x (event %d)\n,
+ i+1, key, k+1);
+ rfbLog( down=%d up=%d keysym:
+@@ -560,7 +560,7 @@ if (debug_scroll 1) fprintf(stderr, internal scrollbar:
%dx%d\n, w, h);
+ for (i=0; i MAX_BUTTONS; i++) {
+ if ( (button_mask (1i)) != (mask (1i)) ) {
+ if (debug_pointer) {
+- rfbLog(pointer(): mask change: mask: 0x%x -
++ rfbLog(x11vnc_pointer(): mask change: mask: 0x%x -
+ 0x%x button: %d\n, button_mask, mask,i+1);
+ }
+ do_button_mask_change(mask, i+1); /* button # is i+1 */
+@@ -659,7 +659,7 @@ static void pipe_pointer(int mask, int x, int y,
rfbClientPtr client) {
+ * This may queue pointer events rather than sending them immediately
+ * to the X server. (see update_x11_pointer*())
+ */
+-void pointer(int mask, int x, int y, rfbClientPtr client) {
++void x11vnc_pointer(int
