[OE-core] [PATCH] populate_sdk_base.bbclass: Allow installation of ix86 SDK on x86_64 host
Commit c04f5435 populate_sdk_base.bbclass: use SDK_ARCH instead
of SDKMACHINE prevents not only the installation of 64 bit SDK
configurations on 32 bit hosts (which indeed cannot work), but also
the legitimate installation of a 32 bit SDK on a 64 bit host.
Fix this.
While there, also make sure we use the same patterns (i[3-6]86 resp.
x86[-_]64 to get unified strings for both INST_ARCH and SDK_ARCH.
Signed-off-by: Wolfgang Denk w...@denx.de
---
meta/classes/populate_sdk_base.bbclass | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index da846b4..c587af8 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -122,11 +122,14 @@ fakeroot create_shar() {
#!/bin/bash
INST_ARCH=$(uname -m | sed -e s/i[3-6]86/ix86/ -e s/x86[-_]64/x86_64/)
-SDK_ARCH=$(echo ${SDK_ARCH} | sed -e s/i[5-6]86/ix86/)
+SDK_ARCH=$(echo ${SDK_ARCH} | sed -e s/i[3-6]86/ix86/ -e
s/x86[-_]64/x86_64/)
if [ $INST_ARCH != $SDK_ARCH ]; then
- echo Error: Installation machine not supported!
- exit 1
+ # Allow for installation of ix86 SDK on x86_64 host
+ if [ $INST_ARCH != x86_64 -o $SDK_ARCH != ix86 ]; then
+ echo Error: Installation machine not supported!
+ exit 1
+ fi
fi
DEFAULT_INSTALL_DIR=${SDKPATH}
--
1.7.11.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07
Dear Radu, In message 501f63ff.1070...@intel.com you wrote: Actually a plain make NAME does the same as make NAME_config make all. You might also consider running ./MAKEALL NAME instead, which aut-adjusts to te number of available cores on the build host, so you get somewhat reduced build times. I've tried to build this way but got into some errors and did not pursued further in debugging them. However, because UBOOT_MACHINE is Could you please tell me exactly what these errors were? Log files etc. highly appreciated... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If programming was easy, they wouldn't need something as complicated as a human being to do it, now would they? - L. Wall R. L. Schwartz, _Programming Perl_ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07
Dear Radu, In message 501fc96a.8000...@intel.com you wrote: in the new shell make coreboot-x86 (without _config) The output I got is as follows: Configuring for coreboot-x86 - Board: coreboot, Options: SYS_TEXT_BASE=0xFC make /bin/bash: i386-linux-gcc: command not found /bin/bash: i386-linux-gcc: command not found It seems CROSS_COMPILE is set to i386-linux-, but i386-linux-gcc is not anywhere in your PATH. Please check your PATH and fix it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Advice is seldom welcome; and those who want it the most always like it the least. -- Philip Earl of Chesterfield ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07
Dear Radu, In message 501fd013.5040...@intel.com you wrote: CROSS_COMPILE is set in EXTRA_OEMAKE which is used in oe-runmake() within do_compile() Running devshell is achieved in do_devshell() which is run after do_patch() but before do_compile(), that's why in devshell CROSS_COMPILE is not (yet) set. But CROSS_COMPILE _is_ set (and apparently has the value i386-linux-. The problem is that PATH is not set such that it contains any such file as i386-linux-gcc. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][RFC] u-boot: Upgrade to upstream stable 2012.07
Dear Radu Moisan, In message 1343997523-4117-1-git-send-email-radu.moi...@intel.com you wrote: Building u-boot requires UBOOT_MACHINE. In the u-boot README file building u-boot is achieved with make NAME_config and then make all. I assumend UBOOT_MACHINE to be the NAME part and thus, Actually a plain make NAME does the same as make NAME_config make all. You might also consider running ./MAKEALL NAME instead, which aut-adjusts to te number of available cores on the build host, so you get somewhat reduced build times. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de An Elephant is a mouse with an Operating System. - Knuth ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] u-boot: Don't make the -Os removal part of global settings.
Dear Khem Raj, In message CAMKF1sp8=orefknds00t-rxovvgwarautrzmnqvzdy13fxu...@mail.gmail.com you wrote: -O2 causes much bigger memory footprint, so the code does not fit any more in the memory map and/or flash sectors that are reserved for it. Hmm interesting so we are living on edge here Well, -O2 can mean some 30% bigger code size than -Os. This hurts for memory-footprint optimized code like a boot loader. [It also hurts in terms of exacution speed on most embedded systems...] Thanks for the info You are welcome. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] perl: Allow perl to cross build and native build in a directory named t
Dear Jason Wessel, In message 1337749401-27198-1-git-send-email-jason.wes...@windriver.com you wrote: If any directory in leading up to your tmp directory has the name t perl will fail to build with a very cryptic error shown below: pod/buildtoc: no pods at pod/buildtoc line 305. make[1]: *** [pod/perltoc.pod] Error 255 This error message is missing in the patch itself: --- /dev/null +++ b/meta/recipes-devtools/perl/perl-5.14.2/perl-build-in-t-dir.patch @@ -0,0 +1,35 @@ +Upstream-Status:Pending + +Perl cannot cross build in a path containing a directory that +has the name of t. + +You get an error like: + + +Signed-off-by: Jason Wessel jason.wes...@windriver.com ... i. e. here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de More software projects have gone awry for lack of calendar time than for all other causes combined. - Fred Brooks, Jr., _The Mythical Man Month_ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Add KERNEL_EXTRA_ARGS parameter
With recent kernel versions, some ARM configurations need may fail to
build with errors like this:
multiple load addresses: 0x80008000 0x80008000
This is incompatible with uImages
Specify LOADADDR on the commandline to build an uImage
We cannot pass this information in EXTRA_OEMAKE, as
meta/classes/kernel.bbclass explicitly ignores all EXTRA_OEMAKE
settings. So add KERNEL_EXTRA_ARGS parameter so affected boards
can add for example
KERNEL_EXTRA_ARGS = LOADADDR=0x80008000
to their configuration. We make this general enough so other needed
command line options can be passed as well when compiling the kernel.
Signed-off-by: Wolfgang Denk w...@denx.de
---
See also
http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/19444
meta/classes/kernel.bbclass |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 139bad9..7a554f0 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -71,6 +71,9 @@ PACKAGE_ARCH = ${MACHINE_ARCH}
UBOOT_ENTRYPOINT ?= 20008000
UBOOT_LOADADDRESS ?= ${UBOOT_ENTRYPOINT}
+# Some Linux kenrel configurations need additional parameters on the command
line
+KERNEL_EXTRA_ARGS ?=
+
# For the kernel, we don't want the '-e MAKEFLAGS=' in EXTRA_OEMAKE.
# We don't want to override kernel Makefile variables from the environment
EXTRA_OEMAKE =
@@ -82,7 +85,7 @@ KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:]
== .gz else s)(d.g
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake include/linux/version.h CC=${KERNEL_CC} LD=${KERNEL_LD}
- oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD}
+ oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD} ${KERNEL_EXTRA_ARGS}
if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; then
gzip -9c ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_OUTPUT}
fi
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] [PATCH] Add KERNEL_EXTRA_ARGS parameter
Dear Khem Raj, In message camkf1so3xwmob30-yogul9jcuhotesmgtdrxtlwkt_dyn-l...@mail.gmail.com you wrote: Add KERNEL_EXTRA_ARGS parameter so affected boards can add for example KERNEL_EXTRA_ARGS = LOADADDR=0x80008000 to their configuration. We make this general enough so other needed command line options can be passed as well when compiling the kernel. will EXTRA_OEMAKE = ... work ? No, it will not, as meta/classes/kernel.bbclass explicitly ignores all EXTRA_OEMAKE settings: ... # For the kernel, we don't want the '-e MAKEFLAGS=' in EXTRA_OEMAKE. # We don't want to override kernel Makefile variables from the environment EXTRA_OEMAKE = ... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I express preference for a chronological sequence of events which precludes a violence. - Terry Pratchett, _The Dark Side of the Sun_ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC] [PATCH] Add KERNEL_EXTRA_ARGS parameter
With recent kernel versions, some ARM configurations need may fail to
build with errors like this:
multiple load addresses: 0x80008000 0x80008000
This is incompatible with uImages
Specify LOADADDR on the commandline to build an uImage
Add KERNEL_EXTRA_ARGS parameter so affected boards can add for example
KERNEL_EXTRA_ARGS = LOADADDR=0x80008000
to their configuration. We make this general enough so other needed
command line options can be passed as well when compiling the kernel.
Signed-off-by: Wolfgang Denk w...@denx.de
---
meta/classes/kernel.bbclass |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 139bad9..7a554f0 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -71,6 +71,9 @@ PACKAGE_ARCH = ${MACHINE_ARCH}
UBOOT_ENTRYPOINT ?= 20008000
UBOOT_LOADADDRESS ?= ${UBOOT_ENTRYPOINT}
+# Some Linux kenrel configurations need additional parameters on the command
line
+KERNEL_EXTRA_ARGS ?=
+
# For the kernel, we don't want the '-e MAKEFLAGS=' in EXTRA_OEMAKE.
# We don't want to override kernel Makefile variables from the environment
EXTRA_OEMAKE =
@@ -82,7 +85,7 @@ KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:]
== .gz else s)(d.g
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake include/linux/version.h CC=${KERNEL_CC} LD=${KERNEL_LD}
- oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD}
+ oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD} ${KERNEL_EXTRA_ARGS}
if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; then
gzip -9c ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_OUTPUT}
fi
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/5] u-boot-fw-utils: add 2012.04 release
Dear Otavio Salvador, In message 0d6637cfcd02587fe62c2c550aac5a33ce9cc72d.1335118370.git.ota...@ossystems.com.br you wrote: Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.bb | 33 1 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-bsp/u-boot/u-boot-fw-utils_2012.04.bb Please update and use v2012.04.01 instead. This is a bug fix release which fixes a nasty bug in the command line processing, which can cause incorrect execution of commands and scripts. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Out of register space (ugh) - vi ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] specific version dependenciews
Dear Richard, In message 1332203843.9740.76.camel@ted you wrote: ... Some MACHINEs require a package A (some library), but in specific versions: say machine X needs version A-1.2, while machine Y needs version A-1.5. Package A itself depends on another package B (another library). The problem is, that different versions of A require specific versions of B. For example, to build A-1.2 we must use B-4.5, but to build A-1.5 we must use B-8.2. I am aware that I can describe the dependencies at the top leven, stating for example that machine X needs A-1.2 and B-4.5, while machine Y needs A-1.5 and B-8.2. However, this seems clumsy, as the version depency A-B is something that is only defined by the implementation of A, and I would like to keep it encapsulated at this level. Is there a clever way to describe such a multi-level dependency chain? If you mark A and B as machine specific, the system should be able to cope with the problem and set the preferred versions at the machine level. I'm sorry, but I don't understand what you mean. How do I mark a package as machine specific? And would setting the preferred versions at the machine level not be exactly what I am trying to avoid? I don't want to make the machine descriptions aware of any version dependencies between A and B. I would like to put this information into the description of A, so that when a specific version of A gets built, automatically the matching version of B will be chosen. Can this be done? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is easier to change the specification to fit the program than vice versa. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] specific version dependenciews - was: Linking two recipes
Dear Denys, In message 20120320004345.gg15...@denix.org you wrote: Is there a clever way to describe such a multi-level dependency chain? Will this help? See line #4 in the first example and lines #30-31 in second: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/gnutls/gnutls.inc#n4 http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/xserver-nodm-init/xserver-nodm-init_2.0.bb#n30 Yes, this looks indeed interesting. Is there also away to ask for a specific package version, i. e. instead of libgcrypt (= 1.4.2) something like libgcrypt (= 1.4.2) or libgcrypt-1.4.2 or such? There are some caveats with that notation, IIRC... What would these be? Is there any documentation about such details? I searched the bitbake, poky and yocto docs but could not find it... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] specific version dependenciews
Dear Richard,
In message 1332254996.9740.97.camel@ted you wrote:
How do I mark a package as machine specific?
PACKAGE_ARCH = ${MACHINE_ARCH}
And would setting the preferred versions at the machine level not be
exactly what I am trying to avoid?
I don't want to make the machine descriptions aware of any version
dependencies between A and B. I would like to put this information
into the description of A, so that when a specific version of A gets
built, automatically the matching version of B will be chosen.
Can this be done?
You could write the dependency A in the form:
DEPENDS = B-1.2
where 1.2 is version of B you want. This has been known to work in the
past but isn't well supported/well tested. It can work since B PROVIDES
${PN}-${PV}.
We will try this.
Thanks a lot!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Everybody is talking about the weather but nobody does anything
about it. - Mark Twain
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] specific version dependenciews - was: Linking two recipes
Dear Henning, In message 20120320140310.ga14...@rhein.zuhause.netz you wrote: we do not support version bounding in the recipes directly. You might have to go with the PREFFRED_VERSION prefix for the recipes in the machine file. Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You got to learn three things. What's real, what's not real, and what's the difference. - Terry Pratchett, _Witches Abroad_ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] specific version dependenciews - was: Linking two recipes
Dear Richard, In message 1332192150.9740.72.camel@ted you wrote: On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote: Hello, I have recipes for two applications Recipe A and Recipe B. Recipe B requires a lib.so file and init.h file which are installed by Recipe A. ... recipe B needs to do: DEPENDS += recipeA I have a similar, but more complicated requirement which I don;t know how to implement (if this is possible at all): Some MACHINEs require a package A (some library), but in specific versions: say machine X needs version A-1.2, while machine Y needs version A-1.5. Package A itself depends on another package B (another library). The problem is, that different versions of A require specific versions of B. For example, to build A-1.2 we must use B-4.5, but to build A-1.5 we must use B-8.2. I am aware that I can describe the dependencies at the top leven, stating for example that machine X needs A-1.2 and B-4.5, while machine Y needs A-1.5 and B-8.2. However, this seems clumsy, as the version depency A-B is something that is only defined by the implementation of A, and I would like to keep it encapsulated at this level. Is there a clever way to describe such a multi-level dependency chain? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/5] self-hosted: Add ext2 utilites and perl-pod for building
Dear Saul Wold, In message 71f6cb63e711721a1a03cfc1c0f1d054472241fe.1323554268.git@linux.intel.com you wrote: Add self-hosted-host-tools for non-build related tools ... +e2fsprogs \ ... +genext2fs \ It's certainly nice to have the ext2 tools then, but would it not also make a lot of sense to include mtd-utils (so we can erase flash and create UBI volumes / UBIFS file system images) and eventually even dosfstools? Most embedded systems come with NAND these days, and a lot of them use UBI/UBIFS... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If all you have is a hammer, everything looks like a nail. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: renamed dir from uboot to the more appropriate u-boot
Dear Martin Jansa, In message 20111209080731.gb3...@jama.jama.net you wrote: On Fri, Dec 09, 2011 at 08:55:05AM +0100, Anders Darander wrote: * Frans Meulenbroeks fransmeulenbro...@gmail.com [111209 08:25]: recipe dirs normally have the name of the (main) package and the official name is u-boot From this I guess that there aren't any other changes in the patch, apart from the renames? Next time, could you add '-M' to `git format-patch`, to make git detect renames? That results in smaller and easier to review patches. Just because of Coordinating inter-layer dependencies thread I have to say, that this will break parsing for people using ie meta-openmoko and meta-nokia BSP layers: meta-nokia/recipes-bsp/uboot/u-boot_git.bb:require recipes-bsp/uboot/u-boot .inc meta-openmoko/recipes-bsp/uboot/u-boot_git.bb:require recipes-bsp/uboot/u-b oot.inc But I'll try to update meta-smartphone layers as soon as this change is applied in oe-core.. meta-ti is already using recipes-bsp/u-boot so I guess it's worth renaming. It's highly advisable to perform the rename ASAP. There is an Austrian lawyer who claims to have IP rights on the name uboot. We had to sign a Cease and Desist Notice and update all web pages to change all ocurrences of uboot into u-boot (which actually required extensions to the wiki we used). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can't say I've ever been lost, but I was bewildered once for three days. - Daniel Boone (Attributed) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
