[oe] [PATCH 2/2] tzdata: bump version to 2010k
Signed-off-by: Simon Busch morp...@gravedo.de
---
recipes/tzdata/tzdata_2010j.bb | 10 --
recipes/tzdata/tzdata_2010k.bb | 10 ++
2 files changed, 10 insertions(+), 10 deletions(-)
delete mode 100644 recipes/tzdata/tzdata_2010j.bb
create mode 100644 recipes/tzdata/tzdata_2010k.bb
diff --git a/recipes/tzdata/tzdata_2010j.bb b/recipes/tzdata/tzdata_2010j.bb
deleted file mode 100644
index 79b7769..000
--- a/recipes/tzdata/tzdata_2010j.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-require tzdata.inc
-
-# Note that elsie.nci.nih.gov removes old archives when new is being
-# released. So if this doesn't build for you because of missing source file
-# just bump it to the latest available version, removing old one
-
-PR = ${INC_PR}.0
-
-SRC_URI[tar.md5sum] = f668f66b260e14b477eac3f48bcfb5f4
-SRC_URI[tar.sha256sum] =
dcf2101d0c5bb20a7f182866ea3e52b54c8f4d129c025a96c9a31377676f554b
diff --git a/recipes/tzdata/tzdata_2010k.bb b/recipes/tzdata/tzdata_2010k.bb
new file mode 100644
index 000..216ae75
--- /dev/null
+++ b/recipes/tzdata/tzdata_2010k.bb
@@ -0,0 +1,10 @@
+require tzdata.inc
+
+# Note that elsie.nci.nih.gov removes old archives when new is being
+# released. So if this doesn't build for you because of missing source file
+# just bump it to the latest available version, removing old one
+
+PR = ${INC_PR}.0
+
+SRC_URI[tar.md5sum] = 5e2086249d6a6bb116534d358661ad3f
+SRC_URI[tar.sha256sum] =
ef69c99504c0fd9864ba8ef1daae5f2d4df097cf7dc350f09b8f70386272408d
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] tzcode-native: bump version to 2010k
---
recipes/tzcode/tzcode-native_2010j.bb | 16
recipes/tzcode/tzcode-native_2010k.bb | 16
2 files changed, 16 insertions(+), 16 deletions(-)
delete mode 100644 recipes/tzcode/tzcode-native_2010j.bb
create mode 100644 recipes/tzcode/tzcode-native_2010k.bb
diff --git a/recipes/tzcode/tzcode-native_2010j.bb
b/recipes/tzcode/tzcode-native_2010j.bb
deleted file mode 100644
index 7e1ae77..000
--- a/recipes/tzcode/tzcode-native_2010j.bb
+++ /dev/null
@@ -1,16 +0,0 @@
-require tzcode-native.inc
-
-# Note that elsie.nci.nih.gov removes old versions when new is coming out
-# So if this doesn't build for you because of missing source file, just
-# bump it to the latest available version, removing old one
-# Also, tzdata (and it is needed to build tzcode) version can differ from
-# tzcode version, thus this variable
-
-TZDATA_PV = 2010j
-
-SRC_URI[tzcode-2010j.md5sum] = 5ba8345720296d3a659b349b2052d139
-SRC_URI[tzcode-2010j.sha256sum] =
f32b46405190e3a5f1ee4db9fb50aaf1379e6af4e5493402ebfc8ee757058e97
-SRC_URI[tzdata-2010j.md5sum] = f668f66b260e14b477eac3f48bcfb5f4
-SRC_URI[tzdata-2010j.sha256sum] =
dcf2101d0c5bb20a7f182866ea3e52b54c8f4d129c025a96c9a31377676f554b
-
-PR = ${INC_PR}.0
diff --git a/recipes/tzcode/tzcode-native_2010k.bb
b/recipes/tzcode/tzcode-native_2010k.bb
new file mode 100644
index 000..21796d6
--- /dev/null
+++ b/recipes/tzcode/tzcode-native_2010k.bb
@@ -0,0 +1,16 @@
+require tzcode-native.inc
+
+# Note that elsie.nci.nih.gov removes old versions when new is coming out
+# So if this doesn't build for you because of missing source file, just
+# bump it to the latest available version, removing old one
+# Also, tzdata (and it is needed to build tzcode) version can differ from
+# tzcode version, thus this variable
+
+TZDATA_PV = 2010k
+
+SRC_URI[tzcode-2010k.md5sum] = 63cd2199679c91bed972a0248d6916af
+SRC_URI[tzcode-2010k.sha256sum] =
96671eac3a98d0c974833c8bfa7ea9b537cc9d32573e902103846b90f6dccdbd
+SRC_URI[tzdata-2010k.md5sum] = 5e2086249d6a6bb116534d358661ad3f
+SRC_URI[tzdata-2010k.sha256sum] =
ef69c99504c0fd9864ba8ef1daae5f2d4df097cf7dc350f09b8f70386272408d
+
+PR = ${INC_PR}.0
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/2] tzcode-native: bump version to 2010k
В сообщении от Вторник 10 августа 2010 10:01:31 автор Simon Busch написал: --- recipes/tzcode/tzcode-native_2010j.bb | 16 recipes/tzcode/tzcode-native_2010k.bb | 16 2 files changed, 16 insertions(+), 16 deletions(-) delete mode 100644 recipes/tzcode/tzcode-native_2010j.bb create mode 100644 recipes/tzcode/tzcode-native_2010k.bb Signed-off-by is missing in the first patch, please resend it with SOB added. -- 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 1/2] tzcode-native: bump version to 2010k
On Tue, 10 Aug 2010 10:10:42 +0400, Roman I Khimov ro...@khimov.ru wrote: В сообщении от Вторник 10 августа 2010 10:01:31 автор Simon Busch написал: --- recipes/tzcode/tzcode-native_2010j.bb | 16 recipes/tzcode/tzcode-native_2010k.bb | 16 2 files changed, 16 insertions(+), 16 deletions(-) delete mode 100644 recipes/tzcode/tzcode-native_2010j.bb create mode 100644 recipes/tzcode/tzcode-native_2010k.bb Signed-off-by is missing in the first patch, please resend it with SOB added. Oh, sorry. I send the wrong file ... locally I already added the missing SOB line. Will resend the patch this evening. regards, morphis ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
2010/8/10 Graham Gower graham.go...@gmail.com: On 10 August 2010 04:31, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/8/9 Chris Larson clar...@kergoth.com: On Mon, Aug 9, 2010 at 6:26 AM, Hauser, Wolfgang (external) wolfgang.hauser.exter...@eads.com wrote: PREFERRED_VERSION_package_local = xxx is how you use the override. The real solution woud be to either temporary store the PREFERRED_VERSION and apply it later on. Alternately we could parse local.conf twice, the first time ignoring the PREFERRED lines, and the 2nd time only looking at these. Yet another solution could be to split local.conf into two pieces, one with settings like MACHINE and DISTRO, the other one with the overrides. Wouldn't it be far simpler to fix the distro conf file(s)? E.g. apply something like this: s/^PREFERRED_VERSION_\([a-z]*\) =/PREFERRED_VERSION_\1 ?=/ Yeah. Didn't really think about that one, but if distro's want to change and adhere to it, that would be the simplest solution Machines that pin something should probably also use weak binding. Conceptually it is probably marginally less desirable than a solution where local.conf has *always* control. What do the distro's think about this? Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] package_ipk.bbclass: remove redundant dependencies upon opkg/opkg-collateral.
Signed-off-by: Graham Gower graham.go...@gmail.com
---
classes/package_ipk.bbclass |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/classes/package_ipk.bbclass b/classes/package_ipk.bbclass
index 3d70181..5d388da 100644
--- a/classes/package_ipk.bbclass
+++ b/classes/package_ipk.bbclass
@@ -1,6 +1,5 @@
inherit package
-BOOTSTRAP_EXTRA_RDEPENDS += opkg-collateral opkg
IMAGE_PKGTYPE ?= ipk
IPKGCONF_TARGET = ${STAGING_ETCDIR_NATIVE}/opkg.conf
--
1.7.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] task-boot.bb: Don't pull in u-a if ONLINE_PACKAGE_MANAGEMENT=none.
This makes it possible to build an opkgless system, without having to set
DISTRO_UPDATE_ALTERNATIVES. In the unlikely event that someone doesn't want
opkg, but does want update-alternatives, one can set DISTRO_UPDATE_ALTERNATIVES
in the local.conf.
Signed-off-by: Graham Gower graham.go...@gmail.com
---
recipes/tasks/task-boot.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/recipes/tasks/task-boot.bb b/recipes/tasks/task-boot.bb
index 45d50ef..d193393 100644
--- a/recipes/tasks/task-boot.bb
+++ b/recipes/tasks/task-boot.bb
@@ -17,7 +17,7 @@ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?=
# u-a script used for building image which is defined with
# PREFERRED_PROVIDER_virtual/update-alternatives-native
-DISTRO_UPDATE_ALTERNATIVES ?=
${PREFERRED_PROVIDER_virtual/update-alternatives}
+DISTRO_UPDATE_ALTERNATIVES ?=
$...@base_conditional(ONLINE_PACKAGE_MANAGEMENT, none, ,
${PREFERRED_PROVIDER_virtual/update-alternatives}, d)}
# Make sure we build the kernel
DEPENDS = virtual/kernel
--
1.7.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] SDK problems. GCC won't launch because it can't find libmpfr.so.4
I've compiled an SDK from a source tree in //data/src/lead-dev/openembedded/, and the resulting gcc compiler for arm has an RPATH of //data/src/lead-dev/openembedded/build/angstrom-dev/sysroots/i686-linux/usr/lib/, and will only run on my machine as long as that directory exists. If I remove that directory, it complains about libmpfr.so.4 not being found. The previous SDK I built also had this odd RPATH, but gcc would run on other systems even if the RPATH-directory didn't exist. I have placed the toolchain in a custom location and compile small applications with makefiles pointing to it. I tried unpacking to /usr/local/angstrom instead and ran the environment setup script, but got the same error. - Tasslehoff ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] ncurses: added 5.7 recipe
On Mon, Aug 9, 2010 at 7:49 PM, Martin Jansa martin.ja...@gmail.com wrote:
On Fri, Jul 30, 2010 at 2:29 PM, Enrico Scholz
enrico.sch...@sigma-chemnitz.de wrote:
It uses ideas from the old 5.4 recipe but brings a lot of new features
like widec libs, pkgconfig files or splitted library packages.
As lot of packages depend on ncurses, whole distribution must be
probably rebuild when updating to this new version.
Due to this and the complex recipe, it has a negative DEFAULT_PREFERENCE
for now.
Hi,
Only breakage I noticed sofar is in pidgin when pidgin-2.6.6 checks
for wide char support:
configure:16212: checking if
/OE/tmpdir-dev-shr/sysroots/armv4t-oe-linux-gnueabi/usr/include/ncurses.h
supports wide characters
| #ifndef get_wch
| # error get_wch not found!
| #endif
and then it decides not to build finch (and later do_package fails).
is it about ENABLE_WIDEC, or something else?
Thanks!
The problem seems to be in ncurses's do_install where you first install
widec if enabled and then always narrowc, which overwrittes curses.h.
With this change I was able to build pidgin with finch without
problem, but no idea if it's right way to fix it.
diff --git a/recipes/ncurses/ncurses_5.7.bb b/recipes/ncurses/ncurses_5.7.bb
index 3562685..725cf7b 100644
--- a/recipes/ncurses/ncurses_5.7.bb
+++ b/recipes/ncurses/ncurses_5.7.bb
@@ -90,12 +90,12 @@ _install_opts = \
do_install() {
-! ${ENABLE_WIDEC} || \
-oe_runmake -C widec ${_install_opts}
-
oe_runmake -C narrowc ${_install_opts} \
install.data install.progs
+! ${ENABLE_WIDEC} || \
+oe_runmake -C widec ${_install_opts}
+
cd narrowc
Regards,
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] openmoko: removed distro
On Tue, Aug 10, 2010 at 11:02:43AM +0200, Frans Meulenbroeks wrote: As discussed on #oe on aug 10, 2010. Removed because this is not used or maintained any more. A message * * *Sorry, The Openmoko distribution has been removed on aug 10, 2010. *It is recommended to use the SHR distro instead. \ *\ *If you really need Openmoko you can still find it in git. * * will be given if someone is still using it. Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com Acked-by: Marcin Juszkiewicz h...@openembedded.org Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de with warning modifications suggested now on IRC by hrw: Acked-by: Martin Jansa martin.ja...@gmail.com Regards, ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] SDK problems. GCC won't launch because it can't find libmpfr.so.4
This is apparently because it wants a native version of libmpfr.so.4, which is not available for Ubuntu 10.04. OE compiled a version of the library in the TMPDIR where I created the SDK, but of course that is not distributed with the SDK. I tried grabbing libmpfr.so.4 from Ubuntu 10.10, but then it complained about libgmp.so.10 not being found. Am I doing something very wrong compiling the SDK since it creates a GCC that wants libraries not present on the system where I created the SDK? - Tasslehoff ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [Angstrom-devel] Can't build gstreamer-ti
On 08/09/2010 04:37 PM, Chethan Pandarinath wrote: This seems to be the same error: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/42905.aspx With the problem being that the cl6x compiler isn't bundled with the rest of the toolchain, and has to be downloaded separately. But I've downloaded those tools and was able to build this recipe just a few weeks ago. I think something in the staged packaging has broken it. On Mon, Aug 9, 2010 at 6:17 PM, Gary Thomasg...@mlbassoc.com wrote: Current org.openembedded.dev tree: commit 9b1a9d8fd143fdab0a169dfda77a5309d52f76a4 Author: Stefan Schmidtste...@buglabs.net Date: Mon Aug 9 17:26:00 2010 +0200 firmware: Add recipe to work with the marvell-sdio-tf-fw MACHINE=beagleboard, DISTRO=angstrom, TARGET=gstreamer-ti | Compiling failure.c... | /local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-cgt6x-tree/bin/cl6x -g -d_DEBUG --no_compress -dMAX_DSPS=1 -dMAX_PROCESSORS=2 -dID_GPP=1 -dOMAP3530 -dPROC_COMPONENT -dPOOL_COMPONENT -dNOTIFY_COMPONENT -dMPCS_COMPONENT -dRINGIO_COMPONENT -dMPLIST_COMPONENT -dMSGQ_COMPONENT -dMSGQ_ZCPY_LINK -dCHNL_COMPONENT -dCHNL_ZCPY_LINK -dZCPY_LINK -dPROCID=0 -dOMAP3530 -dOMAP3530_INTERFACE=SHMEM_INTERFACE -dPHYINTERFACE=SHMEM_INTERFACE -dDSP_SWI_MODE -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc/DspBios -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc/DspBios/5.XX -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc/DspBios/5.XX/OMAP3530 -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc/OMAP3530 -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc/C64XX -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/src/base/gen -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/src/base/gen/DspBios -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/src/base/gen/DspBios/ -I/local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dspbios-tree/packages/ti/bios/include -I/local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-cgt6x-tree/include -I/local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dspbios-tree/packages/ti/rtdx/include/c6000 -I/local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dspbios-tree/packages/ti/psl/include -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/BUILD/OMAP3530_0/INCLUDE -q -pdr -pdv -pden -ml3 -mv6400+ --disable:sploop -fr/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/BUILD/OMAP3530_0/GEN/OBJ/DEBUG failure.c | /bin/sh: /local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-cgt6x-tree/bin/cl6x: No such file or directory | make[3]: *** [failure.c.deb] Error 127 | make[3]: Leaving directory `/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/src/base/gen' | make[2]: *** [objdeb] Error 2 | make[2]: Leaving directory `/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/src/base/gen' | make[1]: *** [gen.objdeb] Error 2 | make[1]: Leaving directory `/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/src/base' | make: *** [base.objdeb] Error 2 NOTE: package ti-dsplink-1_1_64-r88h: task do_compile: Failed ERROR: TaskFailed event exception, aborting ERROR: Build of /local/Angstrom_BeagleBoard/openembedded/recipes/ti/ ti-dsplink_1.64.bb do_compile failed -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Angstrom-distro-devel mailing list angstrom-distro-de...@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel -- Gary
Re: [oe] [PATCH] angstrom-uboot-scripts: debugged beagleboard validation boot/user scripts
Am Montag, den 09.08.2010, 13:52 -0500 schrieb Jason Kridner: Signed-off-by: Jason Kridner jkrid...@beagleboard.org […] I know this has already been committed in 9eab7a12e4a94efbb53e5e43beeb67d15ae9eab5 [1]. But I do not like the commit summary. Is this script developed in a repository somewhere else? Maybe put a link to the revision there. --- recipes/angstrom/angstrom-uboot-scripts.bb |2 +- .../beagleboard-validation-boot.cmd| 15 +++ .../beagleboard-validation-user.cmd| 15 +++ 3 files changed, 15 insertions(+), 17 deletions(-) […] diff --git a/recipes/angstrom/angstrom-uboot-scripts/beagleboard-validation-boot.cmd b/recipes/angstrom/angstrom-uboot-scripts/beagleboard-validation-boot.cmd index 50a82a6..71d314c 100644 --- a/recipes/angstrom/angstrom-uboot-scripts/beagleboard-validation-boot.cmd +++ b/recipes/angstrom/angstrom-uboot-scripts/beagleboard-validation-boot.cmd @@ -1,14 +1,13 @@ -setenv dvimode 'hd720' -setenv vram '16M omapfb.vram=0:8M,1:4M,2:4M' +# On xM: bootargs=console=ttyS2,115200n8 mem=...@0x8000 mem=3...@0x8800 mpurate=1000 buddy=none camera=lbcm3m1 vram=16M omapfb.vram=0:8M,1:4M,2:4M omapfb.mode=dvi:hd720 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait +mmc init +setenv dvimode hd720 +setenv vram 16M omapfb.vram=0:8M,1:4M,2:4M Also a note would have been nice, why the »'« were removed. […] Thanks, Paul [1] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=9eab7a12e4a94efbb53e5e43beeb67d15ae9eab5 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] beagleboard-test-scripts: updated to latest
Am Montag, den 09.08.2010, 18:58 -0500 schrieb Jason Kridner: It would be great, if you could add a link to the updated revision [1] into the commit message. [1] http://gitorious.org/beagleboard-validation/scripts/commit/f009c731df5c410eb819fa90f199713ea60cea6a Signed-off-by: Jason Kridner jkrid...@beagleboard.org Acked-by: Paul Menzel paulepan...@users.sourceforge.net […] 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] [Angstrom-devel] Can't build gstreamer-ti
On 08/10/2010 04:58 AM, Gary Thomas wrote: On 08/09/2010 04:37 PM, Chethan Pandarinath wrote: This seems to be the same error: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/42905.aspx With the problem being that the cl6x compiler isn't bundled with the rest of the toolchain, and has to be downloaded separately. But I've downloaded those tools and was able to build this recipe just a few weeks ago. I think something in the staged packaging has broken it. I worked past this problem by installing a symlink by hand to my DVSDK installed tools. Next problem :-( | /local/Angstrom_BeagleBoard/tmp/sysroots/i686-linux/usr/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld: warning: package/cfg/bin/ti_platforms_evm3530/app_remote_xv5T.xdl contains output sections; did you forget -T? | /local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-codec-engine-2_25_01_06-r5/codec_engine_2_25_01_06/packages/ti/sdo/ce/lib/release/ce.av5T(Engine.ov5T): In function `Engine_deleteNode': | Engine.c:(.text+0x19d4): undefined reference to `__aeabi_uidiv' | /local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-codec-engine-2_25_01_06-r5/codec_engine_2_25_01_06/packages/ti/sdo/ce/osal/linux/lib/release/osal_linux_470.av5T(Global_noOS.ov5T): In function `Global_atexit': | Global_noOS.c:(.text+0x238): undefined reference to `atexit' | /local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dsplink-tree/packages/dsplink/gpp/export/BIN/Linux/OMAP3530/RELEASE/dsplink.lib: In function `_RingIO_writerAcquire': | ringio.c:(.text+0x24e4): undefined reference to `__aeabi_uidivmod' | ringio.c:(.text+0x261c): undefined reference to `__aeabi_uidivmod' | ringio.c:(.text+0x2654): undefined reference to `__aeabi_uidivmod' | /local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dsplink-tree/packages/dsplink/gpp/export/BIN/Linux/OMAP3530/RELEASE/dsplink.lib: In function `_RingIO_readerAcquire': | ringio.c:(.text+0x28ac): undefined reference to `__aeabi_uidivmod' | ringio.c:(.text+0x2bd4): undefined reference to `__aeabi_uidivmod' | /local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dsplink-tree/packages/dsplink/gpp/export/BIN/Linux/OMAP3530/RELEASE/dsplink.lib:ringio.c:(.text+0x2eb4): more undefined references to `__aeabi_uidivmod' follow | /local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-dsplink-tree/packages/dsplink/gpp/export/BIN/Linux/OMAP3530/RELEASE/dsplink.lib: In function `DRV_installCleanupRoutines': | ringio.c:(.text+0x9354): undefined reference to `atexit' | collect2: ld returned 1 exit status | make[1]: *** [bin/ti_platforms_evm3530/app_remote.xv5T] Error 1 | gmake: *** [/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-codec-engine-2_25_01_06-r5/codec_engine_2_25_01_06/examples/ti/sdo/ce/examples/apps/speech,.executables] Error 2 | make[1]: *** [all] Error 2 | make[1]: Leaving directory `/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-codec-engine-2_25_01_06-r5/codec_engine_2_25_01_06/examples/ti/sdo/ce/examples/apps/speech' | make: *** [all] Error 2 NOTE: package ti-codec-engine-2_25_01_06-r5: task do_compile: Failed ERROR: TaskFailed event exception, aborting ERROR: Build of /local/Angstrom_BeagleBoard/openembedded/recipes/ti/ti-codec-engine_2.25.01.06.bb do_compile failed How were these packages built to be put on the Angstrom package feed? Am I doing something wrong? On Mon, Aug 9, 2010 at 6:17 PM, Gary Thomasg...@mlbassoc.com wrote: Current org.openembedded.dev tree: commit 9b1a9d8fd143fdab0a169dfda77a5309d52f76a4 Author: Stefan Schmidtste...@buglabs.net Date: Mon Aug 9 17:26:00 2010 +0200 firmware: Add recipe to work with the marvell-sdio-tf-fw MACHINE=beagleboard, DISTRO=angstrom, TARGET=gstreamer-ti | Compiling failure.c... | /local/Angstrom_BeagleBoard/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/usr/share/ti/ti-cgt6x-tree/bin/cl6x -g -d_DEBUG --no_compress -dMAX_DSPS=1 -dMAX_PROCESSORS=2 -dID_GPP=1 -dOMAP3530 -dPROC_COMPONENT -dPOOL_COMPONENT -dNOTIFY_COMPONENT -dMPCS_COMPONENT -dRINGIO_COMPONENT -dMPLIST_COMPONENT -dMSGQ_COMPONENT -dMSGQ_ZCPY_LINK -dCHNL_COMPONENT -dCHNL_ZCPY_LINK -dZCPY_LINK -dPROCID=0 -dOMAP3530 -dOMAP3530_INTERFACE=SHMEM_INTERFACE -dPHYINTERFACE=SHMEM_INTERFACE -dDSP_SWI_MODE -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc/DspBios -I/local/Angstrom_BeagleBoard/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink-1_1_64-r88h/dsplink_linux_1_64/dsplink/dsp/inc/DspBios/5.XX
Re: [oe] [Angstrom-devel] Can't build gstreamer-ti
Hi, this is known use binutils 2.18 for now. Bye Henning ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] cross.bbclass: Override STAGING_* paths to match cross installation
On Mon, 2010-08-09 at 08:48 -0700, Khem Raj wrote:
On Mon, Aug 9, 2010 at 4:12 AM, Richard Purdie rpur...@rpsys.net wrote:
Hi Khem,
On Sun, 2010-08-08 at 23:44 -0700, Khem Raj wrote:
Signed-off-by: Khem Raj raj.k...@gmail.com
---
classes/cross.bbclass |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/classes/cross.bbclass b/classes/cross.bbclass
index cf14db1..64f7902 100644
--- a/classes/cross.bbclass
+++ b/classes/cross.bbclass
@@ -50,6 +50,14 @@ exec_prefix = ${prefix}
base_sbindir = ${base_prefix}/bin
sbindir = ${exec_prefix}/bin
+# staging should be special for cross
+STAGING_BINDIR = ${bindir}
+STAGING_LIBDIR = ${libdir}
+STAGING_INCDIR = ${includedir}
+STAGING_ETCDIR = ${sysconfdir}
+STAGING_DATADIR = ${datadir}
+STAGING_SBINDIR = ${sbindir}
+
do_install () {
oe_runmake 'DESTDIR=${D}' install
}
Can you explain a bit more about why is this needed?
yes. for cross packages prefix is set in cross.bbclass to be
${base_prefix}${prefix_native}/${BASE_PACKAGE_ARCH}
which already points into native sysroot and bindir, datadir etc are
defined based on prefix in bitbake.conf so
for cross packages datadir already points to where it is in the final
install location of the cross packages.
but STAGING_* dirs are then defined like below
STAGING_DIR_HOST = ${STAGING_DIR}/${BASEPKG_HOST_SYS}
STAGING_BINDIR = ${STAGING_DIR_HOST}${bindir}
where
STAGING_DIR_HOST expands to native sysroot in the case of cross
packages because for them BASEPKG_HOST_SYS
is the build system itself. I think this is a the reason why we have
NATIVE_STAGING_* vars defined separately.
probably we should have the same set defined for cross too may be
something like CROSS_STAGING_* is one solution.
and now all these STAGING_* defines create another native sysroot
directory insise the existing one.
so I get
/scratch/oe/sysroot/x86_64-linux/scrarch/oe/sysroot/x86_64-linux/usr/armv5te/shared/
etc. paths while
building binutils-cross
because STAGING_* variables are used in autotools.bbclass
Thats why this patch
So the problem is empty directory creation?
I'm tempted to suggest a more radical approach of not having all these
directories created by autotools.bbclass...
Cheers,
Richard
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/2] tzdata: bump version to 2010k
Signed-off-by: Simon Busch morp...@gravedo.de
---
recipes/tzdata/tzdata_2010j.bb | 10 --
recipes/tzdata/tzdata_2010k.bb | 10 ++
2 files changed, 10 insertions(+), 10 deletions(-)
delete mode 100644 recipes/tzdata/tzdata_2010j.bb
create mode 100644 recipes/tzdata/tzdata_2010k.bb
diff --git a/recipes/tzdata/tzdata_2010j.bb b/recipes/tzdata/tzdata_2010j.bb
deleted file mode 100644
index 79b7769..000
--- a/recipes/tzdata/tzdata_2010j.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-require tzdata.inc
-
-# Note that elsie.nci.nih.gov removes old archives when new is being
-# released. So if this doesn't build for you because of missing source file
-# just bump it to the latest available version, removing old one
-
-PR = ${INC_PR}.0
-
-SRC_URI[tar.md5sum] = f668f66b260e14b477eac3f48bcfb5f4
-SRC_URI[tar.sha256sum] =
dcf2101d0c5bb20a7f182866ea3e52b54c8f4d129c025a96c9a31377676f554b
diff --git a/recipes/tzdata/tzdata_2010k.bb b/recipes/tzdata/tzdata_2010k.bb
new file mode 100644
index 000..216ae75
--- /dev/null
+++ b/recipes/tzdata/tzdata_2010k.bb
@@ -0,0 +1,10 @@
+require tzdata.inc
+
+# Note that elsie.nci.nih.gov removes old archives when new is being
+# released. So if this doesn't build for you because of missing source file
+# just bump it to the latest available version, removing old one
+
+PR = ${INC_PR}.0
+
+SRC_URI[tar.md5sum] = 5e2086249d6a6bb116534d358661ad3f
+SRC_URI[tar.sha256sum] =
ef69c99504c0fd9864ba8ef1daae5f2d4df097cf7dc350f09b8f70386272408d
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 2/2] linux-palmpre: bump git revision
The new version fixes a compile problem with software using the kernel typedefs
u8 and __u8
Signed-off-by: Simon Busch morp...@gravedo.de
---
recipes/linux/linux-palmpre_git.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/recipes/linux/linux-palmpre_git.bb
b/recipes/linux/linux-palmpre_git.bb
index 4deaaf2..59e8d6c 100644
--- a/recipes/linux/linux-palmpre_git.bb
+++ b/recipes/linux/linux-palmpre_git.bb
@@ -11,7 +11,7 @@ file://defconfig \
S = ${WORKDIR}/git/
-SRCREV = d2f6283b8ca5b59e7f181ed391adf0e23e346c6d
+SRCREV = 96eba42952e860f652e66a72569319dfd35756dc
KV = 2.6.24
PR=r1
PV = ${KV}+gitr${SRCPV}
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] linux-palmpre: add git version
The sources from Palm for the Palm Pre has beed modified with little improvements and are rebased against the latest version from Palm found at http://opensource.palm.com from time to time. The modified kernel tree is maintained by the FSO team. Signed-off-by: Simon Busch morp...@gravedo.de --- recipes/linux/linux-palmpre/defconfig | 1867 + recipes/linux/linux-palmpre_git.bb| 23 + 2 files changed, 1890 insertions(+), 0 deletions(-) create mode 100644 recipes/linux/linux-palmpre/defconfig create mode 100644 recipes/linux/linux-palmpre_git.bb diff --git a/recipes/linux/linux-palmpre/defconfig b/recipes/linux/linux-palmpre/defconfig new file mode 100644 index 000..08c5bb0 --- /dev/null +++ b/recipes/linux/linux-palmpre/defconfig @@ -0,0 +1,1867 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.24-palm +# Wed May 26 09:04:32 2010 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_MMU=y +# CONFIG_NO_IOPORT is not set +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_ZONE_DMA=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION=-joplin-3430 +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +CONFIG_TASKSTATS=y +CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y +# CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set +# CONFIG_AUDIT is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=16 +CONFIG_CGROUPS=y +# CONFIG_CGROUP_DEBUG is not set +CONFIG_CGROUP_NS=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_FAIR_USER_SCHED is not set +CONFIG_FAIR_CGROUP_SCHED=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_SYSFS_DEPRECATED=y +CONFIG_RELAY=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_TMPFS_ACCOUNTING=y +CONFIG_VM_EVENT_COUNTERS=y +# CONFIG_SLUB_DEBUG is not set +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_KMOD=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +CONFIG_BLK_DEV_IO_TRACE=y +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=cfq + +# +# System Type +# +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS7500 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_CO285 is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_L7200 is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_PNX4008 is not set +# CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_RPC is not set +# CONFIG_ARCH_SA1100 is not set +# CONFIG_ARCH_S3C2410 is not set +# CONFIG_ARCH_SHARK is not set +# CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_DAVINCI is not set +CONFIG_ARCH_OMAP=y + +# +# TI OMAP Implementations +# +CONFIG_ARCH_OMAP_OTG=y +# CONFIG_ARCH_OMAP1 is not set +# CONFIG_ARCH_OMAP2 is not set +CONFIG_ARCH_OMAP3=y + +# +# OMAP Feature Selections +# +# CONFIG_OMAP_DEBUG_POWERDOMAIN is not set +# CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set
[oe] [PATCH 5/5] lvm2.inc: remove unnecessary EXTRA_OECONF_arm line from recipe
Signed-off-by: Simon Busch morp...@gravedo.de
---
recipes/lvm2/lvm2.inc |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/recipes/lvm2/lvm2.inc b/recipes/lvm2/lvm2.inc
index db3a1c1..da7cc9c 100644
--- a/recipes/lvm2/lvm2.inc
+++ b/recipes/lvm2/lvm2.inc
@@ -12,7 +12,6 @@ SRC_URI =
ftp://sources.redhat.com/pub/lvm2/old/LVM2.${PV}.tgz \
# Unset user/group to unbreak install.
EXTRA_OECONF = --with-user= --with-group= --disable-o_direct
-EXTRA_OECONF_arm = --with-user= --with-group= --disable-o_direct
inherit autotools
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/4] lvm2: rebase all recipes on a global lvm2.inc recipe
Am 28.07.2010 20:07, schrieb Stefan Schmidt:
Hello.
On Wed, 2010-07-28 at 19:20, Simon Busch wrote:
On 28.07.2010 15:44, Stefan Schmidt wrote:
On Mon, 2010-07-26 at 21:58, Simon Busch wrote:
On 26.07.2010 09:46, Stefan Schmidt wrote:
Hello.
On Tue, 2010-07-20 at 20:44, Simon Busch wrote:
This rebases all specific versions of lvm2 on a global recipe lvm2.inc
which defines the
common parameters for building lvm2. Staging is overwritten as we don't
need any of the
executables or manpages the build of lvm2 produces for any related
builds.
Signed-off-by: Simon Busch morp...@gravedo.de
Looks good. Two comments below.
Thank you for commenting this patches!
diff --git a/recipes/lvm2/lvm2.inc b/recipes/lvm2/lvm2.inc
new file mode 100644
index 000..a7e37b5
--- /dev/null
+++ b/recipes/lvm2/lvm2.inc
@@ -0,0 +1,20 @@
+SECTION = utils
+DESCRIPTION = LVM2 is a set of utilities to manage logical volumes in
Linux.
+LICENSE = GPL
+DEPENDS = device-mapper
+INC_PR = r2
+
+S = ${WORKDIR}/LVM2.${PV}
+SRC_URI = ftp://sources.redhat.com/pub/lvm2/old/LVM2.${PV}.tgz \
+ file://crosscompile_fix.patch
+
+# Unset user/group to unbreak install.
+EXTRA_OECONF = --with-user= --with-group= --disable-o_direct
+EXTRA_OECONF_arm = --with-user= --with-group= --disable-o_direct
I can see that you just merged this in from an already existing recipe,
but do
we know why we have an overrirde for ARM here which changes nothing?
Looks bogus
to me.
Hm, you are right. I checked it with recompiling without the
EXTRA_OECONF_arm statement. It works fine. Is it ok if I supply an extra
patch removing this statement or should I rework this patch?
Both is fine with me.
+inherit autotools
+
+# We don't need to stage anything (the executables are no needed at
build time by any
+# other recipe)
+do_stage() {
+}
While we don't need the executables the don't hurd either IMHO. Can we
get rid
of this?
The problem was, that the executables and manpages where installed into
the staging dir and never removed, when the packages was clean ur
purged. So I added the empty do_stage block to avoid stage of anything
from this package as we don't need them anyway.
Hm, this smells like a bug somewhere else. Did the staged binaries bring in
other problems or could they get staged until we find out why they are not
removed?
Staging this binaries let the recompile of the same package fail as it
tries to install the binaries + man pages again.
Any hints where the bug could be? Within the staging logic?
Good question. Maybe only a bug in the clean step that it ignores the files
during cleaning. Anybody else an idea?
You could also add a do_install_append which removes the binaries again.
Hm, is that the best solution? I think it's better to stage nothing as
we now we don't really need anything to be staged. So is it ok leaving
this patch as it is and commit it?
regards,
morphis
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] conf/distro/include: remove unused versions
On Tue, Aug 10, 2010 at 06:52:37PM +0200, Frans Meulenbroeks wrote: Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com --- While browsing through conf/distro/include I notided some files that were not used. Triggered by this I did a grep in conf/distro and conf/distro/include to see what files were actually used. I manually compared this with the contents of the include directory The folllowing files were not used by any distro. (and there is also no require for them in the recipes dir). Unless someone comes up with a reason to keep one of them, I propose to remove these. IE fso-autorev.inc is still usefull and usually included from local.conf. preferred-xorg I proposed to cleanup already in http://patchwork.openembedded.org/patch/2262/ conf/distro/include/preferred-xorg-versions-live.inc is only one I maintain up-to-date with my xorg bumps (and can be usefull if you want latest xorg stuff from local.conf while your distro includes ie X11R7.5 and you want to overwritte it with latest). No strong opinion about other .inc. Regards, ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [RFC] add maintainers to distro conf files, move or remove orphaned distro's, remove obsolete distro's
Dear all, For me it is totally unclear about most of the distro's whether they are still used, and if so, who maintains them (and who to contact when there are issues) As distro's are first class citizens it seems like a good plan to identify in the conf file who is the maintainer (yes, I know we have the MAINTAINERS file, but I am not too sure whether it is up to date and not all distro's are listed there). distros that have no active maintainer should either be pruned or moved to an archived or unmaintained directory or so. For all distro's I tried to identify the maintainer. In that process MAINTAINERS was leading. If there was no entry in MAINTAINERS (bad sign:-( ) I've used git blame to find out who created the recipe/was the major author of it. At the end of this post is the list. Proposal: (0) maintainers listed below but not listed in MAINTAINERS, please claim (or deny) ownership. Ditto if you are maintaining a distro but you are not listed. (1) add an explict MAINTAINER(S) line in each distro conf file (2) owners of a distro that feel that the distro is dead, please remove the distro. (3) either remove orphaned distro's or move them to an unmaintained directory. (4) for distros that are removed (and maybe also for the ones that are moved) add a note stating that they still can be found in git (see openmoko.conf as example) Your feedback is appreciated Frans PS: it is by no means my intention to remove anything that is still in use/maintained, but I feel it would help us if it is clear who maintains what. Also having dead stuff around that is not maintained is probably due to lead to frustration if a naive user comes along and tries to build it anyway. Guess that is better avoided (note also that the code still remains available in git) amsdelta-oe.conf Not listed in MAINTAINERS created by Jonathan McDowell in 2006 angstrom-2008.1-legacy.conf angstrom-2008.1.conf Denys Dmytriyenko Dmitry Eremin-Solenikov Junqian Gordon Xu 'xjqian' Khem Raj Koen Kooi Marco Cavallini Martin 'JaMa' Jansa Philipp Zabel Richard Purdie Rick Farina Stelios Koroneos Tim Ellis asusoe.conf Not listed in MAINTAINERS created by Rod Whitby in 2005 celinux-test.conf Not listed in MAINTAINERS created by Marcin Juszkiewicz in 2006 chinook-compat.conf Robert Schuster 'thebohemian' colinuxoe.conf Not listed in MAINTAINERS created by Chris Larson in 2005 foonas.conf Tim Ellis ?~Xyvind Repvik gmustix.conf Not listed in MAINTAINERS created by Marcin Juszkiewicz in 2006 iphone-compat.conf Not listed in MAINTAINERS created by eremy Laine in 2009 jlime-2010.1.conf Kristoffer Ericson kaeilos-2010.conf kaeilos.conf Marco Cavallini maemo5-compat.conf Not listed in MAINTAINERS created by Marcin Juszkiewicz in 2010 mamona.conf Rodrigo 'vivijim' Vivi micro-uclibc.conf micro.conf Not listed in MAINTAINERS created by Martin Lund in 2009 minimal-uclibc.conf minimal.conf Michael 'Mickey' Lauer nylon.conf Not listed in MAINTAINERS created by Martin Dietze in 2009 openmn.conf Not listed in MAINTAINERS created by nslu2-linux@bkbits.net (!) in 2005 openmoko.conf retired per today openprotium.conf Andy Wilcox openwrt-sdk.conf Not listed in MAINTAINERS oplinux-uclibc.conf oplinux.conf Stelios Koroneos sharprom-compatible.conf Not listed in MAINTAINERS probbly also created by nslu2-linux@bkbits.net, but file has been touched by several people shr.conf Martin 'JaMa' Jansa slugos-native.conf slugos.conf ?~Xyvind Repvik ucslugc.conf Not listed in MAINTAINERS created by John Bowler in 2005, content is mostly from Rod Whitby (2006/2007) wrt54oe.conf Not listed in MAINTAINERS created by Chris Larson in 2005, content is mostly from Marcin Juszkiewicz (2005) Distro's mentioned in MAINTAINERS but with no entry in conf/distro: arago (Denys Dmytriyenko) eRouter (Jamie Lenehan) familiar (Erik Hovland) Sonkei (Rolf 'Laibsch' Leggewie, Matthias 'CoreDump' Hentges) poky (Richard Purdie) openzaurus (Richard Purdie) I know some of these have their own git. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/2] tzdata: bump version to 2010k
В сообщении от Вторник 10 августа 2010 19:27:57 автор Simon Busch написал: Signed-off-by: Simon Busch morp...@gravedo.de Uhm. I meant, the _first_ one, which is for tzcode-native. BTW, it would be nice if you've updated patchwork when submitting updated patches: http://patchwork.openembedded.org/ -- 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] conf/distro/include: remove unused versions
2010/8/10 Martin Jansa martin.ja...@gmail.com: On Tue, Aug 10, 2010 at 06:52:37PM +0200, Frans Meulenbroeks wrote: Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com --- While browsing through conf/distro/include I notided some files that were not used. Triggered by this I did a grep in conf/distro and conf/distro/include to see what files were actually used. I manually compared this with the contents of the include directory The folllowing files were not used by any distro. (and there is also no require for them in the recipes dir). Unless someone comes up with a reason to keep one of them, I propose to remove these. IE fso-autorev.inc is still usefull and usually included from local.conf. Ok, then lets keep it. preferred-xorg I proposed to cleanup already in http://patchwork.openembedded.org/patch/2262/ Missed that. sry. do you still want an ack for it. conf/distro/include/preferred-xorg-versions-live.inc is only one I maintain up-to-date with my xorg bumps (and can be usefull if you want latest xorg stuff from local.conf while your distro includes ie X11R7.5 and you want to overwritte it with latest). Ok, so good to keep as well No strong opinion about other .inc. Well the om can go as openmoko is declared dead. Personally I was not really sure whether freeze.inc actually is used and/or is worthwhile to retain. Frans ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] cross.bbclass: Override STAGING_* paths to match cross installation
On Tue, Aug 10, 2010 at 7:53 AM, Richard Purdie rpur...@rpsys.net wrote:
On Mon, 2010-08-09 at 08:48 -0700, Khem Raj wrote:
On Mon, Aug 9, 2010 at 4:12 AM, Richard Purdie rpur...@rpsys.net wrote:
Hi Khem,
On Sun, 2010-08-08 at 23:44 -0700, Khem Raj wrote:
Signed-off-by: Khem Raj raj.k...@gmail.com
---
classes/cross.bbclass | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/classes/cross.bbclass b/classes/cross.bbclass
index cf14db1..64f7902 100644
--- a/classes/cross.bbclass
+++ b/classes/cross.bbclass
@@ -50,6 +50,14 @@ exec_prefix = ${prefix}
base_sbindir = ${base_prefix}/bin
sbindir = ${exec_prefix}/bin
+# staging should be special for cross
+STAGING_BINDIR = ${bindir}
+STAGING_LIBDIR = ${libdir}
+STAGING_INCDIR = ${includedir}
+STAGING_ETCDIR = ${sysconfdir}
+STAGING_DATADIR = ${datadir}
+STAGING_SBINDIR = ${sbindir}
+
do_install () {
oe_runmake 'DESTDIR=${D}' install
}
Can you explain a bit more about why is this needed?
yes. for cross packages prefix is set in cross.bbclass to be
${base_prefix}${prefix_native}/${BASE_PACKAGE_ARCH}
which already points into native sysroot and bindir, datadir etc are
defined based on prefix in bitbake.conf so
for cross packages datadir already points to where it is in the final
install location of the cross packages.
but STAGING_* dirs are then defined like below
STAGING_DIR_HOST = ${STAGING_DIR}/${BASEPKG_HOST_SYS}
STAGING_BINDIR = ${STAGING_DIR_HOST}${bindir}
where
STAGING_DIR_HOST expands to native sysroot in the case of cross
packages because for them BASEPKG_HOST_SYS
is the build system itself. I think this is a the reason why we have
NATIVE_STAGING_* vars defined separately.
probably we should have the same set defined for cross too may be
something like CROSS_STAGING_* is one solution.
and now all these STAGING_* defines create another native sysroot
directory insise the existing one.
so I get
/scratch/oe/sysroot/x86_64-linux/scrarch/oe/sysroot/x86_64-linux/usr/armv5te/shared/
etc. paths while
building binutils-cross
because STAGING_* variables are used in autotools.bbclass
Thats why this patch
So the problem is empty directory creation?
yes.
I'm tempted to suggest a more radical approach of not having all these
directories created by autotools.bbclass...
thats a good idea I can look into it.
yeah this patch actually will need another patch in crosssdk.bbclass.
Actually STAGING_DIR is a bit confusing when it comes to cross and sdk
packages.
May be we should have STAGING_DIR_{CROSS|NATIVE|SDK|NATIVESDK|TARGET}
all defined and used appropriately. right now the STAGING_DIR_HOST and
these various STAGING_DIR_* defines get it very confusing.
Cheers,
Richard
___
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] gcc-cross-initial-4.3.3-r14.1 failed on SH4 angstrom
On Tue, Aug 10, 2010 at 2:35 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: HI, I'm currently trying to use OE for a titan (SH4) board with Angstrom distrib I've attached my conf and log gcc-cross-initial-4.3.3-r14.1 failled to compile due to the fact that it's include /usr/include is some have any idea? Please use gcc 4.4.4 for SH platform. Best Regards, J. ___ 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] glibc-initial do_install failure
On Mon, Aug 9, 2010 at 2:39 PM, Adrian Alonso aalons...@gmail.com wrote: Hi Khem, Log with -v option at http://pastebin.com/5mB7CvHm OK it seems its using right assembler then I wonder why linker can not understand the objects generated by it. Try to generate a .o with this gcc for a small hello world program with and then put it somewhere or run readelf over it and inspect. Thanks On Mon, Aug 9, 2010 at 4:06 PM, Khem Raj raj.k...@gmail.com wrote: On Mon, Aug 9, 2010 at 1:39 PM, Adrian Alonso aalons...@gmail.com wrote: Hi, I'm trying to build glibc-initial_2.3.6 for Microblaze arch and it fails in do_install function at final stage when linking libc.so; Error log attached I notice that this always happends when invoking gcc with -shared flag it always returns the same error: /tmp/ccvUy8ol.o: could not read symbols: File format not recognized | collect2: ld returned 1 exit status | ERROR: Function do_install failed The combination of tools that trying to build binutils: 2.20.1 gcc: 4.5 Microblaze svn branch glibc: 2.3.6 from petalogix know working port for microblaze Computer host: Fedora 13 Can any one give me some advise on how to root cause and solve this problem? The problem is that its not using the right assembler AFAICT the log you attached does not help. Can you try that same command individually with -v added to it please. Thx -Khem ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel -- Saludos Adrian Alonso http://aalonso.wordpress.com ___ 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] [OE][PATCH] pkgconfig.bbclass: Remove spurious rpaths and -isystem includes from pkgconfig files.
On Sun, Aug 8, 2010 at 10:48 AM, Roman I Khimov ro...@khimov.ru wrote:
I have -isystem... change in my own patch queue and rpath-link should be
fine also. I'm not so sure about incdir or libdir change though.
Okay---cool.
The libdir incdir stuff would be for such a case:
To compile against libfoo, you need to include a non-standard path
such as -I/usr/include/libfoo/bar/. Normally pkgconfig just adds this
flag but the path (pre-pkgconfig.bbclass) is gross (staging
path/usr/include/libfoo/bar/); the pkgconfig.bbclass strips this down
to a floating 'libfoo/bar' in the flags line when it should be
'-I/usr/include/libfoo/bar'.
I think the patch as I submitted it doesn't fix this properly for all
cases. Also relies on ${prefix} to be correctly set for
pkgconfig---is this a safe assumption?
Should I split out the -rpath-link and -isystem into a separate patch?
Thanks,
Ash
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/2] tzcode-native: bump version to 2010k
Signed-off-by: Simon Busch morp...@gravedo.de
---
recipes/tzcode/tzcode-native_2010j.bb | 16
recipes/tzcode/tzcode-native_2010k.bb | 16
2 files changed, 16 insertions(+), 16 deletions(-)
delete mode 100644 recipes/tzcode/tzcode-native_2010j.bb
create mode 100644 recipes/tzcode/tzcode-native_2010k.bb
diff --git a/recipes/tzcode/tzcode-native_2010j.bb
b/recipes/tzcode/tzcode-native_2010j.bb
deleted file mode 100644
index 7e1ae77..000
--- a/recipes/tzcode/tzcode-native_2010j.bb
+++ /dev/null
@@ -1,16 +0,0 @@
-require tzcode-native.inc
-
-# Note that elsie.nci.nih.gov removes old versions when new is coming out
-# So if this doesn't build for you because of missing source file, just
-# bump it to the latest available version, removing old one
-# Also, tzdata (and it is needed to build tzcode) version can differ from
-# tzcode version, thus this variable
-
-TZDATA_PV = 2010j
-
-SRC_URI[tzcode-2010j.md5sum] = 5ba8345720296d3a659b349b2052d139
-SRC_URI[tzcode-2010j.sha256sum] =
f32b46405190e3a5f1ee4db9fb50aaf1379e6af4e5493402ebfc8ee757058e97
-SRC_URI[tzdata-2010j.md5sum] = f668f66b260e14b477eac3f48bcfb5f4
-SRC_URI[tzdata-2010j.sha256sum] =
dcf2101d0c5bb20a7f182866ea3e52b54c8f4d129c025a96c9a31377676f554b
-
-PR = ${INC_PR}.0
diff --git a/recipes/tzcode/tzcode-native_2010k.bb
b/recipes/tzcode/tzcode-native_2010k.bb
new file mode 100644
index 000..21796d6
--- /dev/null
+++ b/recipes/tzcode/tzcode-native_2010k.bb
@@ -0,0 +1,16 @@
+require tzcode-native.inc
+
+# Note that elsie.nci.nih.gov removes old versions when new is coming out
+# So if this doesn't build for you because of missing source file, just
+# bump it to the latest available version, removing old one
+# Also, tzdata (and it is needed to build tzcode) version can differ from
+# tzcode version, thus this variable
+
+TZDATA_PV = 2010k
+
+SRC_URI[tzcode-2010k.md5sum] = 63cd2199679c91bed972a0248d6916af
+SRC_URI[tzcode-2010k.sha256sum] =
96671eac3a98d0c974833c8bfa7ea9b537cc9d32573e902103846b90f6dccdbd
+SRC_URI[tzdata-2010k.md5sum] = 5e2086249d6a6bb116534d358661ad3f
+SRC_URI[tzdata-2010k.sha256sum] =
ef69c99504c0fd9864ba8ef1daae5f2d4df097cf7dc350f09b8f70386272408d
+
+PR = ${INC_PR}.0
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/2] tzdata: bump version to 2010k
Am 10.08.2010 19:53, schrieb Roman I Khimov: В сообщении от Вторник 10 августа 2010 19:27:57 автор Simon Busch написал: Signed-off-by: Simon Busch morp...@gravedo.de Uhm. I meant, the _first_ one, which is for tzcode-native. BTW, it would be nice if you've updated patchwork when submitting updated patches: http://patchwork.openembedded.org/ Sorry for this. I choose the file to send too quickly so I dismissed to choose the first one :) I have updated the status of the patches in the patchwork system (never worked with it before, so I decided to reject the wrong patches). Hope now everything is fine and the patches will be ack'ed :) regards, morphis ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [RFC] add maintainers to distro conf files, move or remove orphaned distro's, remove obsolete distro's
Dnia wtorek, 10 sierpnia 2010 o 19:41:27 Frans Meulenbroeks napisał(a): celinux-test.conf Not listed in MAINTAINERS created by Marcin Juszkiewicz in 2006 Created for CELF and their testlab. No idea is it in use or not. Probably Tim Bird would be a good contact. IIRC it was Angstrom fork. gmustix.conf Not listed in MAINTAINERS created by Marcin Juszkiewicz in 2006 I did not created it. Maybe I pushed someone's patch. iphone-compat.conf Not listed in MAINTAINERS created by eremy Laine in 2009 Imported from Poky or based on it probably. maemo5-compat.conf Not listed in MAINTAINERS created by Marcin Juszkiewicz in 2010 Created by Robert Schuster and edited/merged by me. nylon.conf Not listed in MAINTAINERS created by Martin Dietze in 2009 IIRC it is older then 2009 even. openmn.conf Not listed in MAINTAINERS created by nslu2-linux@bkbits.net (!) in 2005 Maintained outside of OE tree and not merged back. openwrt-sdk.conf Not listed in MAINTAINERS Created in 2008/2009 to use OpenEmbedded to build packages compatible with OpenWRT. Worth staying. sharprom-compatible.conf Not listed in MAINTAINERS probbly also created by nslu2-linux@bkbits.net, but file has been touched by several people Rolf 'Laibsch' Leggewie is closest to being maintainer of it. ucslugc.conf Not listed in MAINTAINERS created by John Bowler in 2005, content is mostly from Rod Whitby (2006/2007) Yet another nslu2 distro - no idea is it in use. wrt54oe.conf Not listed in MAINTAINERS created by Chris Larson in 2005, content is mostly from Marcin Juszkiewicz (2005) Gives packages which can be installed under OpenWRT 8.x (WhiteRussian). Distro's mentioned in MAINTAINERS but with no entry in conf/distro: arago (Denys Dmytriyenko) External tree. familiar (Erik Hovland) Dead, already removed from OE. Sonkei (Rolf 'Laibsch' Leggewie, Matthias 'CoreDump' Hentges) OpenZaurus clone - was maintained externally. openzaurus (Richard Purdie) Dead, already removed from OE. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/2] tzdata: bump version to 2010k
В сообщении от Вторник 10 августа 2010 22:51:17 автор Simon Busch написал: Sorry for this. I choose the file to send too quickly so I dismissed to choose the first one :) I have updated the status of the patches in the patchwork system (never worked with it before, so I decided to reject the wrong patches). Just for the future, a more appropriate status in this case is Superseded. Checked and pushed both, thanks! -- 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] [Angstrom-devel] Can't build gstreamer-ti
On Tue, Aug 10, 2010 at 06:48:55AM -0600, Gary Thomas wrote: On 08/10/2010 04:58 AM, Gary Thomas wrote: But I've downloaded those tools and was able to build this recipe just a few weeks ago. I think something in the staged packaging has broken it. I worked past this problem by installing a symlink by hand to my DVSDK installed tools. Next problem :-( | Engine.c:(.text+0x19d4): undefined reference to `__aeabi_uidiv' How were these packages built to be put on the Angstrom package feed? Am I doing something wrong? As Henning already said, Codec Engine only builds and works with binutils 2.18 (which IS Angstrom's default, btw) on TI OMAP3/DaVinci processors. -- Denys ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] ecore: remove fix-ecore-fb-initialization.patch
Removing the fix-ecore-fb-initialization patch as it let ecore open the supplied
touchscreen device twice which results in an error on platforms where the
touchscreen
device node can be opened only once. Furthermore I doubt that it is necessary
to open the
touchscreen device node more than one time.
Signed-off-by: Simon Busch morp...@gravedo.de
---
recipes/efl1/ecore.inc |2 -
.../efl1/ecore/fix-ecore-fb-initialization.patch | 29
2 files changed, 0 insertions(+), 31 deletions(-)
delete mode 100644 recipes/efl1/ecore/fix-ecore-fb-initialization.patch
diff --git a/recipes/efl1/ecore.inc b/recipes/efl1/ecore.inc
index bb7eea5..081572d 100644
--- a/recipes/efl1/ecore.inc
+++ b/recipes/efl1/ecore.inc
@@ -12,8 +12,6 @@ inherit efl
BBCLASSEXTEND = native
-SRC_URI += file://fix-ecore-fb-initialization.patch
-
do_configure_prepend() {
touch ${S}/po/Makefile.in.in || true
sed -i -e 's: po::g' ${S}/Makefile.am
diff --git a/recipes/efl1/ecore/fix-ecore-fb-initialization.patch
b/recipes/efl1/ecore/fix-ecore-fb-initialization.patch
deleted file mode 100644
index 2ac61ca..000
--- a/recipes/efl1/ecore/fix-ecore-fb-initialization.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-#
-# The whole ecore-fb init logic is somewhat flawed; with this patch we
-# get at least a working touchscreen w/ tslib again.
-#
-# Signed-off-by: Michael 'Mickey' Lauer mla...@vanille-media.de
-#
-
-Index: ecore/src/lib/ecore_fb/ecore_fb.c
-===
ecore.orig/src/lib/ecore_fb/ecore_fb.c
-+++ ecore/src/lib/ecore_fb/ecore_fb.c
-@@ -46,6 +46,9 @@
-
-if (!ecore_fb_vt_init())
- return --_ecore_fb_init_count;
-+
-+ if (!ecore_fb_ts_init())
-+ return --_ecore_fb_init_count;
-
-ECORE_FB_EVENT_KEY_DOWN = ecore_event_type_new();
-ECORE_FB_EVENT_KEY_UP= ecore_event_type_new();
-@@ -70,6 +73,7 @@
-if (--_ecore_fb_init_count != 0)
- return _ecore_fb_init_count;
-
-+ ecore_fb_ts_shutdown();
-ecore_fb_vt_shutdown();
-
-return _ecore_fb_init_count;
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] [PATCH] tslib: add config files for palmpre machine
Signed-off-by: Simon Busch morp...@gravedo.de --- recipes/tslib/tslib/palmpre/ts.conf | 27 +++ recipes/tslib/tslib/palmpre/tslib.sh |6 ++ 2 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 recipes/tslib/tslib/palmpre/ts.conf create mode 100644 recipes/tslib/tslib/palmpre/tslib.sh diff --git a/recipes/tslib/tslib/palmpre/ts.conf b/recipes/tslib/tslib/palmpre/ts.conf new file mode 100644 index 000..8857e8d --- /dev/null +++ b/recipes/tslib/tslib/palmpre/ts.conf @@ -0,0 +1,27 @@ +# Uncomment if you wish to use the linux input layer event interface +# module_raw input + +module cry8mrln_palmpre + +# Uncomment if you're using a Sharp Zaurus SL-5500/SL-5000d +# module_raw collie + +# Uncomment if you're using a Sharp Zaurus SL-C700/C750/C760/C860 +# module_raw corgi + +# Uncomment if you're using a device with a UCB1200/1300/1400 TS interface +# module_raw ucb1x00 + +# Uncomment if you're using an HP iPaq h3600 or similar +# module_raw h3600 + +# Uncomment if you're using a Hitachi Webpad +# module_raw mk712 + +# Uncomment if you're using an IBM Arctic II +# module_raw arctic2 + +# module pthres pmin=1 +# module variance delta=30 +# module dejitter delta=100 +# module linear diff --git a/recipes/tslib/tslib/palmpre/tslib.sh b/recipes/tslib/tslib/palmpre/tslib.sh new file mode 100644 index 000..5c1cc25 --- /dev/null +++ b/recipes/tslib/tslib/palmpre/tslib.sh @@ -0,0 +1,6 @@ +#!/bin/sh + +TSLIB_TSDEVICE=/dev/touchscreen + +export TSLIB_TSDEVICE + -- 1.7.0.4 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/2] tzdata: bump version to 2010k
On Tue, Aug 10, 2010 at 11:20:18PM +0400, Roman I Khimov wrote: В сообщении от Вторник 10 августа 2010 22:51:17 автор Simon Busch написал: Sorry for this. I choose the file to send too quickly so I dismissed to choose the first one :) I have updated the status of the patches in the patchwork system (never worked with it before, so I decided to reject the wrong patches). Just for the future, a more appropriate status in this case is Superseded. Checked and pushed both, thanks! Ok, will remember this for the future. Thank you for the review and committing both recipes. regards, morphis ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10-08-10 01:15, Graham Gower wrote: On 10 August 2010 04:31, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/8/9 Chris Larson clar...@kergoth.com: On Mon, Aug 9, 2010 at 6:26 AM, Hauser, Wolfgang (external) wolfgang.hauser.exter...@eads.com wrote: Hello, I want to change some used versions of packages, so I added a PREFERRED_VERSION_package=xxx for the packages I want to have a special(newer) version to be used. But e. g. for busybox the version defined in the used distro.conf is used instead of my setting in local.conf. Should local.conf not overrule distro/machine.conf ?? Conceptually, local should override everything, as it's the most specific information available, but from a technical standpoint, we can't parse the machine and distro configs until local.conf is parsed, as that's usually where the MACHINE and DISTRO are set. You can use a 'local' override to get around it, or you can ask the distro/machine maintainer to use ?= assignments (set only if unset). PREFERRED_VERSION_package_local = xxx is how you use the override. The real solution woud be to either temporary store the PREFERRED_VERSION and apply it later on. Alternately we could parse local.conf twice, the first time ignoring the PREFERRED lines, and the 2nd time only looking at these. Yet another solution could be to split local.conf into two pieces, one with settings like MACHINE and DISTRO, the other one with the overrides. Wouldn't it be far simpler to fix the distro conf file(s)? E.g. apply something like this: s/^PREFERRED_VERSION_\([a-z]*\) =/PREFERRED_VERSION_\1 ?=/ What's the point of setting a preferred version at all if you make it a weak assignment? The distro nearly always knows better and if you want to use a different version, sending a patch to change that version for review isn't exactly rocket science. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFMYbuWMkyGM64RGpERArMuAKCmQ+N+ZFpZv9/s24LYacKaPMLUJwCfaUGs JSGK2aDWhxS1Ii6uVkUGoIQ= =jBaa -END PGP SIGNATURE- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
On Tue, Aug 10, 2010 at 1:50 PM, Koen Kooi k.k...@student.utwente.nlwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10-08-10 01:15, Graham Gower wrote: On 10 August 2010 04:31, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/8/9 Chris Larson clar...@kergoth.com: On Mon, Aug 9, 2010 at 6:26 AM, Hauser, Wolfgang (external) wolfgang.hauser.exter...@eads.com wrote: Hello, I want to change some used versions of packages, so I added a PREFERRED_VERSION_package=xxx for the packages I want to have a special(newer) version to be used. But e. g. for busybox the version defined in the used distro.conf is used instead of my setting in local.conf. Should local.conf not overrule distro/machine.conf ?? Conceptually, local should override everything, as it's the most specific information available, but from a technical standpoint, we can't parse the machine and distro configs until local.conf is parsed, as that's usually where the MACHINE and DISTRO are set. You can use a 'local' override to get around it, or you can ask the distro/machine maintainer to use ?= assignments (set only if unset). PREFERRED_VERSION_package_local = xxx is how you use the override. The real solution woud be to either temporary store the PREFERRED_VERSION and apply it later on. Alternately we could parse local.conf twice, the first time ignoring the PREFERRED lines, and the 2nd time only looking at these. Yet another solution could be to split local.conf into two pieces, one with settings like MACHINE and DISTRO, the other one with the overrides. Wouldn't it be far simpler to fix the distro conf file(s)? E.g. apply something like this: s/^PREFERRED_VERSION_\([a-z]*\) =/PREFERRED_VERSION_\1 ?=/ What's the point of setting a preferred version at all if you make it a weak assignment? The distro nearly always knows better and if you want to use a different version, sending a patch to change that version for review isn't exactly rocket science. How about having decent usability? The user asking for something and not getting it is completely unintuitive. If the user doesn't know what they want, they won't request a specific version. If they do request it, they should get it, anything else is an OE usability issue. -- 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] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
On 11 August 2010 06:26, Chris Larson clar...@kergoth.com wrote: On Tue, Aug 10, 2010 at 1:50 PM, Koen Kooi k.k...@student.utwente.nlwrote: What's the point of setting a preferred version at all if you make it a weak assignment? The distro nearly always knows better and if you want to use a different version, sending a patch to change that version for review isn't exactly rocket science. How about having decent usability? The user asking for something and not getting it is completely unintuitive. If the user doesn't know what they want, they won't request a specific version. If they do request it, they should get it, anything else is an OE usability issue. Precisely. The user shouldn't have to understand the details of parsing order, weak assignments, etc. in order to write a local.conf which works for them. Patch to follow. -Graham ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] Mass convert PREFERRED_VERSION_* to be weakly assigned.
On 11 August 2010 09:56, Philip Balister phi...@balister.org wrote:
On 08/10/2010 04:47 PM, Graham Gower wrote:
find conf -type f -exec sed -i -e 's/^PREFERRED_VERSION_\([^ \t]*\)\([
\t]*\)=/PREFERRED_VERSION_\1\2?=/' {} \;
Shouldn't DISTRO's decide on a per DISTRO decision whether or not their
preferred versions are weak?
I;m not entirely opposed to make the assignment weak for Angstrom, but I am
very opposed to making all DISTRO's use the same policy.
Surely having disunity by giving different distros different policies
would be worse?
It is a real nuisance trying to debug someone's Angstrom build, only to fins
out they have loads of local overrides.
Point taken. local.conf really should be a mandatory piece of
information when reporting an issue.
Philip
-Graham
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] Mass convert PREFERRED_VERSION_* to be weakly assigned.
On Tue, Aug 10, 2010 at 6:05 PM, Graham Gower graham.go...@gmail.com wrote:
On 11 August 2010 09:56, Philip Balister phi...@balister.org wrote:
On 08/10/2010 04:47 PM, Graham Gower wrote:
find conf -type f -exec sed -i -e 's/^PREFERRED_VERSION_\([^ \t]*\)\([
\t]*\)=/PREFERRED_VERSION_\1\2?=/' {} \;
Shouldn't DISTRO's decide on a per DISTRO decision whether or not their
preferred versions are weak?
I;m not entirely opposed to make the assignment weak for Angstrom, but I am
very opposed to making all DISTRO's use the same policy.
Surely having disunity by giving different distros different policies
would be worse?
whats issue with current versioning ? you always have _local override
if you want
to disregard what DISTRO sets it to. IMO it should be left upto DISTRO to hard
assign or weak assign them. I dont think its a good idea to make all weak
-Khem
It is a real nuisance trying to debug someone's Angstrom build, only to fins
out they have loads of local overrides.
Point taken. local.conf really should be a mandatory piece of
information when reporting an issue.
Philip
-Graham
___
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] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
On Wed, Aug 11, 2010 at 09:14:41AM +0930, Graham Gower wrote: On 11 August 2010 06:26, Chris Larson clar...@kergoth.com wrote: On Tue, Aug 10, 2010 at 1:50 PM, Koen Kooi k.k...@student.utwente.nlwrote: What's the point of setting a preferred version at all if you make it a weak assignment? The distro nearly always knows better and if you want to use a different version, sending a patch to change that version for review isn't exactly rocket science. How about having decent usability? The user asking for something and not getting it is completely unintuitive. If the user doesn't know what they want, they won't request a specific version. If they do request it, they should get it, anything else is an OE usability issue. Precisely. The user shouldn't have to understand the details of parsing order, weak assignments, etc. in order to write a local.conf which works for them. Yeah, and then distro maintainers are blamed for the breakage when users unpin and change specific dependency for a package. It's not just the parsing order problem. It's not clear for users that if they change anything in local.conf, it can break. I.e. you break it - you fix it. -- Denys ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] Mass convert PREFERRED_VERSION_* to be weakly assigned.
On Wed, Aug 11, 2010 at 09:17:47AM +0930, Graham Gower wrote:
find conf -type f -exec sed -i -e 's/^PREFERRED_VERSION_\([^ \t]*\)\([
\t]*\)=/PREFERRED_VERSION_\1\2?=/' {} \;
Signed-off-by: Graham Gower graham.go...@gmail.com
NACK! Not acceptable!
In general - distro maintainers should decide whether to hard pin the version
or not.
Specifically - below is totally wrong! There is a very delicate dependency
between specific versions of TI components and in this case they are all based
on CodecEngine, changing CodecEngine version will change the versions for
all the dependencies:
...gstrom-codec-engine-2.25-preferred-versions.inc | 22 +-
...rom-codec-engine-2.25.01-preferred-versions.inc | 66 +-
...rom-codec-engine-2.25.02-preferred-versions.inc | 66 +-
...trom-codec-engine-latest-preferred-versions.inc | 66 +-
...-engine-latestproduction-preferred-versions.inc | 66 +-
diff --git
a/conf/distro/include/angstrom-codec-engine-2.25-preferred-versions.inc
b/conf/distro/include/angstrom-codec-engine-2.25-preferred-versions.inc
index 3c3480c..67c3920 100644
--- a/conf/distro/include/angstrom-codec-engine-2.25-preferred-versions.inc
+++ b/conf/distro/include/angstrom-codec-engine-2.25-preferred-versions.inc
@@ -1,14 +1,14 @@
# Codec engine needs a specific set of version of its dependencies, so we
specify them here:
-PREFERRED_VERSION_ti-codec-engine = 2_25_00_05
+PREFERRED_VERSION_ti-codec-engine ?= 2_25_00_05
-PREFERRED_VERSION_ti-biosutils = 1_02_02
-PREFERRED_VERSION_ti-cgt6x = 6_1_9
-PREFERRED_VERSION_ti-dspbios = 5_41_02_14
-PREFERRED_VERSION_ti-dsplink-module = 1_64
-PREFERRED_VERSION_ti-edma3lld = 01_11_00_02
-PREFERRED_VERSION_ti-framework-components = 2_25_00_04
-PREFERRED_VERSION_ti-linuxutils = 2_25_01_06
-PREFERRED_VERSION_ti-lpm-module = 2_24_01
-PREFERRED_VERSION_ti-xdais = 6_25_00_07
-PREFERRED_VERSION_ti-xdctools = 3_16_01_27
+PREFERRED_VERSION_ti-biosutils ?= 1_02_02
+PREFERRED_VERSION_ti-cgt6x ?= 6_1_9
+PREFERRED_VERSION_ti-dspbios ?= 5_41_02_14
+PREFERRED_VERSION_ti-dsplink-module ?= 1_64
+PREFERRED_VERSION_ti-edma3lld ?= 01_11_00_02
+PREFERRED_VERSION_ti-framework-components ?= 2_25_00_04
+PREFERRED_VERSION_ti-linuxutils ?= 2_25_01_06
+PREFERRED_VERSION_ti-lpm-module ?= 2_24_01
+PREFERRED_VERSION_ti-xdais ?= 6_25_00_07
+PREFERRED_VERSION_ti-xdctools ?= 3_16_01_27
diff --git
a/conf/distro/include/angstrom-codec-engine-2.25.01-preferred-versions.inc
b/conf/distro/include/angstrom-codec-engine-2.25.01-preferred-versions.inc
index 5a16f2c..2a9a8ce 100644
--- a/conf/distro/include/angstrom-codec-engine-2.25.01-preferred-versions.inc
+++ b/conf/distro/include/angstrom-codec-engine-2.25.01-preferred-versions.inc
@@ -1,41 +1,41 @@
# Codec engine needs a specific set of version of its dependencies, so we
specify them here:
# - using edma-lld 01.11.00.03 (instead of 01.11.00.02) to fix installer
issue.
-PREFERRED_VERSION_ti-codec-engine = 2_25_01_06
-PREFERRED_VERSION_ti-codec-engine-examples = 2_25_01_06
+PREFERRED_VERSION_ti-codec-engine ?= 2_25_01_06
+PREFERRED_VERSION_ti-codec-engine-examples ?= 2_25_01_06
-PREFERRED_VERSION_ti-biosutils = 1_02_02
-PREFERRED_VERSION_ti-cgt6x = 6_1_9
-PREFERRED_VERSION_ti-dspbios = 5_41_02_14
-PREFERRED_VERSION_ti-dsplink = 1_64
-PREFERRED_VERSION_ti-dsplink-examples = 1_64
-PREFERRED_VERSION_ti-dsplink-module = 1_64
-PREFERRED_VERSION_ti-edma3lld = 01_11_00_03
-PREFERRED_VERSION_ti-framework-components = 2_25_01_05
-PREFERRED_VERSION_ti-linuxutils = 2_25_01_06
-PREFERRED_VERSION_ti-local-power-manager = 1_24_01
-PREFERRED_VERSION_ti-lpm-module = 1_24_01
-PREFERRED_VERSION_ti-lpm-utils = 1_24_01
-PREFERRED_VERSION_ti-xdais = 6_25_01_08
-PREFERRED_VERSION_ti-xdctools = 3_16_01_27
+PREFERRED_VERSION_ti-biosutils ?= 1_02_02
+PREFERRED_VERSION_ti-cgt6x ?= 6_1_9
+PREFERRED_VERSION_ti-dspbios ?= 5_41_02_14
+PREFERRED_VERSION_ti-dsplink ?= 1_64
+PREFERRED_VERSION_ti-dsplink-examples ?= 1_64
+PREFERRED_VERSION_ti-dsplink-module ?= 1_64
+PREFERRED_VERSION_ti-edma3lld ?= 01_11_00_03
+PREFERRED_VERSION_ti-framework-components ?= 2_25_01_05
+PREFERRED_VERSION_ti-linuxutils ?= 2_25_01_06
+PREFERRED_VERSION_ti-local-power-manager ?= 1_24_01
+PREFERRED_VERSION_ti-lpm-module ?= 1_24_01
+PREFERRED_VERSION_ti-lpm-utils ?= 1_24_01
+PREFERRED_VERSION_ti-xdais ?= 6_25_01_08
+PREFERRED_VERSION_ti-xdctools ?= 3_16_01_27
-PREFERRED_VERSION_ti-codecs-dm355 = 1_13_000
-PREFERRED_VERSION_ti-codecs-dm355-server = 1_13_000
-PREFERRED_VERSION_ti-codecs-dm365 = 3_10_00_02
-PREFERRED_VERSION_ti-codecs-dm365-server = 3_10_00_02
-PREFERRED_VERSION_ti-codecs-dm6446 = 2_05_00_00
-PREFERRED_VERSION_ti-codecs-dm6446-server = 2_05_00_00
-PREFERRED_VERSION_ti-codecs-dm6467 = 1_00_00_03
-PREFERRED_VERSION_ti-codecs-dm6467-server = 1_00_00_03
-PREFERRED_VERSION_ti-codecs-omap3530 = 1_00_01
-PREFERRED_VERSION_ti-codecs-omap3530-server = 1_00_00
Re: [oe] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
On 11 August 2010 11:12, Denys Dmytriyenko de...@denix.org wrote: On Wed, Aug 11, 2010 at 09:14:41AM +0930, Graham Gower wrote: On 11 August 2010 06:26, Chris Larson clar...@kergoth.com wrote: On Tue, Aug 10, 2010 at 1:50 PM, Koen Kooi k.k...@student.utwente.nlwrote: What's the point of setting a preferred version at all if you make it a weak assignment? The distro nearly always knows better and if you want to use a different version, sending a patch to change that version for review isn't exactly rocket science. How about having decent usability? The user asking for something and not getting it is completely unintuitive. If the user doesn't know what they want, they won't request a specific version. If they do request it, they should get it, anything else is an OE usability issue. Precisely. The user shouldn't have to understand the details of parsing order, weak assignments, etc. in order to write a local.conf which works for them. Yeah, and then distro maintainers are blamed for the breakage when users unpin and change specific dependency for a package. It's not just the parsing order problem. It's not clear for users that if they change anything in local.conf, it can break. I.e. you break it - you fix it. Ok, I'm not so passionate about this change... But I'd like to highlight why this is not particularly intuitive. My experience has been that only certain image targets will build without overrides in a local.conf. E.g. In order to get gpe-image to build, i needed to set PREFERRED_VERSION_gpsd = 2.39, because prismstumbler doesn't work with the API of newer gpsd versions and prismstumbler is included in the gpe-image. Since no gpsd version was pinned in the distro i was using, this override worked. But then i determined that udev 151 didn't like my old kernel, so I set PREFERRED_VERSION_udev = 141. Only this doesn't work because the (angstrom) distro pins it and the 151 version is silently picked up. I now understand why, but I didn't at the time. So PREFERRED_VERSION_foo=123 might work, or it might not. And the same goes for PREFERRED_PROVIDER_foo, which is actually less consistent because some use a weak assignment in the conf files and others don't. Oh, and where is the ?= operator documented? I would have expected to find it here: http://bitbake.berlios.de/manual/ch02.html -Graham ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] gcc-cross-initial-4.3.3-r14.1 failed on SH4 angstrom
On 11:27 Tue 10 Aug , Khem Raj wrote: On Tue, Aug 10, 2010 at 2:35 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: HI, I'm currently trying to use OE for a titan (SH4) board with Angstrom distrib I've attached my conf and log gcc-cross-initial-4.3.3-r14.1 failled to compile due to the fact that it's include /usr/include is some have any idea? Please use gcc 4.4.4 for SH platform. How can we update oe to do it automaticly for SH? I known how to do in my conf or the machine but not in the distro for a specific arch Best Regards, J. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
On Wed, Aug 11, 2010 at 12:13:08PM +0930, Graham Gower wrote: Ok, I'm not so passionate about this change... But I'd like to highlight why this is not particularly intuitive. My experience has been that only certain image targets will build without overrides in a local.conf. But then i determined that udev 151 didn't like my old kernel, so I set PREFERRED_VERSION_udev = 141. Only this doesn't work because the (angstrom) distro pins it and the 151 version is silently picked up. I now understand why, but I didn't at the time. Yeah, udev 141 doesn't like glibc 2.9 either. So PREFERRED_VERSION_foo=123 might work, or it might not. And the same goes for PREFERRED_PROVIDER_foo, which is actually less consistent because some use a weak assignment in the conf files and others don't. Oh, and where is the ?= operator documented? I would have expected to find it here: http://bitbake.berlios.de/manual/ch02.html The only place I was able to find it explained is in OpenEmbedded manual under Conditional assignment of Syntax of recipes chapter: http://docs.openembedded.org/usermanual/html/recipes_syntax.html -- Denys ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
Frans Meulenbroeks wrote: 2010/8/10 Graham Gower graham.go...@gmail.com: On 10 August 2010 04:31, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/8/9 Chris Larson clar...@kergoth.com: On Mon, Aug 9, 2010 at 6:26 AM, Hauser, Wolfgang (external) wolfgang.hauser.exter...@eads.com wrote: PREFERRED_VERSION_package_local = xxx is how you use the override. The real solution woud be to either temporary store the PREFERRED_VERSION and apply it later on. Alternately we could parse local.conf twice, the first time ignoring the PREFERRED lines, and the 2nd time only looking at these. Yet another solution could be to split local.conf into two pieces, one with settings like MACHINE and DISTRO, the other one with the overrides. Wouldn't it be far simpler to fix the distro conf file(s)? E.g. apply something like this: s/^PREFERRED_VERSION_\([a-z]*\) =/PREFERRED_VERSION_\1 ?=/ Yeah. Didn't really think about that one, but if distro's want to change and adhere to it, that would be the simplest solution Machines that pin something should probably also use weak binding. Conceptually it is probably marginally less desirable than a solution where local.conf has *always* control. What do the distro's think about this? I think it is the decision of EACH DISTRO to make, and not something to be dictated by OE in general. Mind you, I appreciate the general recommendation -- it's a sound idea to make it so that a knowledgeable developer's local.conf overrides most distro preferred version settings. I use the technique frequently. But on the other hand, I appreciate the ability to lock down some preferred versions where I feel that it simply doesn't make sense to let local.conf override. For example, there's usually a LOT more to changing the kernel version for SlugOS than just setting PREFERRED_VERSION. By the time a developer has figured out OE well enough so they can find the distro conf files and understand how they work, then I expect they also understand what extra stuff they need to do for the kernel as well. (Not to mention that I could - and should - add some comments in the distro conf file to explain how that all works, which is something I can't do in a generic local.conf file quite so well.) It's a trivial point; if the community wants to begin to dictate such little nuances to distros, it's not important enough to me to argue. But you asked what the distros think, so I answered. :) -Mike (mwester) ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] Mass convert PREFERRED_VERSION_* to be weakly assigned.
Graham Gower wrote:
find conf -type f -exec sed -i -e 's/^PREFERRED_VERSION_\([^ \t]*\)\([
\t]*\)=/PREFERRED_VERSION_\1\2?=/' {} \;
Signed-off-by: Graham Gower graham.go...@gmail.com
---
conf/distro/amsdelta-oe.conf |2 +-
conf/distro/angstrom-2008.1.conf | 10 +-
conf/distro/celinux-test.conf | 14 +-
conf/distro/chinook-compat.conf| 128 ++--
conf/distro/foonas.conf|8 +-
conf/distro/gmustix.conf | 16 +-
.../include/angstrom-2008-preferred-versions.inc | 114 ++--
...gstrom-codec-engine-2.25-preferred-versions.inc | 22 +-
...rom-codec-engine-2.25.01-preferred-versions.inc | 66 +-
...rom-codec-engine-2.25.02-preferred-versions.inc | 66 +-
...trom-codec-engine-latest-preferred-versions.inc | 66 +-
...-engine-latestproduction-preferred-versions.inc | 66 +-
conf/distro/include/angstrom-jalimo.conf | 20 +-
.../include/kaeilos-2009-preferred-versions.inc| 116 ++--
conf/distro/include/maemo-preferred.inc| 12 +-
conf/distro/include/oplinux.inc|2 +-
conf/distro/include/preferred-gpe-versions-2.7.inc |2 +-
conf/distro/include/preferred-om-2009-versions.inc | 54 +-
.../distro/include/preferred-opie-cvs-versions.inc |2 +-
.../include/preferred-opie-versions-1.2.3.inc | 384 ++--
.../include/preferred-opie-versions-1.2.4.inc | 382 ++--
conf/distro/include/preferred-opie-versions.inc| 382 ++--
conf/distro/include/preferred-shr-versions.inc | 74 ++--
conf/distro/include/preferred-slugos-versions.inc |2 +-
NAK. Please read the comments around that change in
preferred-slugos-versions.inc; it is required in order to override the
machine conf file's selection of the kernel.
-Mike (mwester)
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] gcc-cross-initial-4.3.3-r14.1 failed on SH4 angstrom
On Tue, Aug 10, 2010 at 7:45 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 11:27 Tue 10 Aug , Khem Raj wrote: On Tue, Aug 10, 2010 at 2:35 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: HI, I'm currently trying to use OE for a titan (SH4) board with Angstrom distrib I've attached my conf and log gcc-cross-initial-4.3.3-r14.1 failled to compile due to the fact that it's include /usr/include is some have any idea? Please use gcc 4.4.4 for SH platform. How can we update oe to do it automaticly for SH? I known how to do in my conf or the machine but not in the distro for a specific arch e.g. for angstrom you will add ANGSTROM_GCC_VERSION_sh4 ?= 4.4.4 to angstrom-2008.1.conf Best Regards, J. ___ 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] Why PREFERRED_VERSION setting of distro.conf overrules local.conf setting ?
On Tue, Aug 10, 2010 at 1:56 PM, Chris Larson clar...@kergoth.com wrote: On Tue, Aug 10, 2010 at 1:50 PM, Koen Kooi k.k...@student.utwente.nlwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10-08-10 01:15, Graham Gower wrote: On 10 August 2010 04:31, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: 2010/8/9 Chris Larson clar...@kergoth.com: On Mon, Aug 9, 2010 at 6:26 AM, Hauser, Wolfgang (external) wolfgang.hauser.exter...@eads.com wrote: Hello, I want to change some used versions of packages, so I added a PREFERRED_VERSION_package=xxx for the packages I want to have a special(newer) version to be used. But e. g. for busybox the version defined in the used distro.conf is used instead of my setting in local.conf. Should local.conf not overrule distro/machine.conf ?? Conceptually, local should override everything, as it's the most specific information available, but from a technical standpoint, we can't parse the machine and distro configs until local.conf is parsed, as that's usually where the MACHINE and DISTRO are set. You can use a 'local' override to get around it, or you can ask the distro/machine maintainer to use ?= assignments (set only if unset). PREFERRED_VERSION_package_local = xxx is how you use the override. The real solution woud be to either temporary store the PREFERRED_VERSION and apply it later on. Alternately we could parse local.conf twice, the first time ignoring the PREFERRED lines, and the 2nd time only looking at these. Yet another solution could be to split local.conf into two pieces, one with settings like MACHINE and DISTRO, the other one with the overrides. Wouldn't it be far simpler to fix the distro conf file(s)? E.g. apply something like this: s/^PREFERRED_VERSION_\([a-z]*\) =/PREFERRED_VERSION_\1 ?=/ What's the point of setting a preferred version at all if you make it a weak assignment? The distro nearly always knows better and if you want to use a different version, sending a patch to change that version for review isn't exactly rocket science. How about having decent usability? The user asking for something and not getting it is completely unintuitive. If the user doesn't know what they want, they won't request a specific version. If they do request it, they should get it, anything else is an OE usability issue. why not use _local override and I think if user want to alter a distro choice I consider that user to be not a beginner. -- 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 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
