[OE-core] [PATCH] bc: use update-alternatives to make dc play nice with busybox
From: Denys Dmytriyenko de...@ti.com
busybox' default configuration enables dc app, which bc also provides,
setup update-alternatives to resolve the conflict.
Signed-off-by: Denys Dmytriyenko de...@ti.com
---
meta/recipes-extended/bc/bc_1.06.bb | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/bc/bc_1.06.bb
b/meta/recipes-extended/bc/bc_1.06.bb
index 02915e1..d8d8f4d 100644
--- a/meta/recipes-extended/bc/bc_1.06.bb
+++ b/meta/recipes-extended/bc/bc_1.06.bb
@@ -11,11 +11,20 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
SECTION = base
DEPENDS = flex
-PR = r0
+PR = r1
SRC_URI = ${GNU_MIRROR}/bc/bc-${PV}.tar.gz
SRC_URI[md5sum] = d44b5dddebd8a7a7309aea6c36fda117
SRC_URI[sha256sum] =
4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea72c0e33
-inherit autotools
+do_install_append () {
+ mv ${D}${bindir}/dc ${D}${bindir}/dc.${PN}
+}
+
+inherit autotools update-alternatives
+
+ALTERNATIVE_NAME = dc
+ALTERNATIVE_LINK = ${bindir}/dc
+ALTERNATIVE_PATH = ${bindir}/dc.${PN}
+ALTERNATIVE_PRIORITY = 100
--
1.7.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] linux-yocto: support externalsrc builds
On Tue, 2012-03-27 at 22:31 -0400, Bruce Ashfield wrote: There are a few extra task that modify the source tree that should be removed when externalsrc is inherited by a recipe that uses a linux-yocto tree. Adding those tasks to SRCTREECOVEREDTASKS means that they are skipped and externalsrc works as intended. Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com --- meta/classes/kernel-yocto.bbclass |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 9/9] local.conf.sample.extended: The set for archiving packages
On Tue, 2012-03-27 at 10:24 +0800, Xiaofeng Yan wrote: From: Xiaofeng Yan xiaofeng@windriver.com User can use these variables to get atchiving packages they want. Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com --- meta-yocto/conf/local.conf.sample.extended | 32 1 files changed, 32 insertions(+), 0 deletions(-) This commit introduced duplicate information as Chris noted. I also thought we could make it clearer so in the end I pretty much rewrote it (to mention INHERIT += too). I've merged a patch along these lines which should complete this series now. I would note that a few people have ideas for cleanups to the code. For example, rather than figuring out .bb and .inc files as you do now, there is a bitbake variable you can look at to get this information. I'm seeing the merged code as a first draft of this which we can now iterate over and improve. As such I'll take improvement patches. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] zypper: Fix build with gcc 4.7
On Tue, 2012-03-27 at 19:41 -0700, Khem Raj wrote: More details in patch header Signed-off-by: Khem Raj raj.k...@gmail.com --- .../recipes-extended/zypper/zypper/gcc-scope.patch | 20 meta/recipes-extended/zypper/zypper_git.bb |3 ++- 2 files changed, 22 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-extended/zypper/zypper/gcc-scope.patch Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Tue, 27 Mar 2012, Christopher Larson wrote: IMAGE_INSTALL_append or IMAGE_INSTALL_append_pn-core-image-minimal or whatever when I need to quickly add a package temporarily, myself. i'll get to the other responses shortly but i'm summarizing this topic at my wiki here: http://www.crashcourse.ca/wiki/index.php/OE-Core#Adding_a_single_package_to_a_build rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Tue, 27 Mar 2012, Christopher Larson wrote: I IMAGE_INSTALL_append or IMAGE_INSTALL_append_pn-core-image-minimal or whatever when I need to quickly add a package temporarily, myself. once i add this package and build a new image to verify it was added, i want to revert and rebuild the original QEMU image again. so after removing that line from local.conf, what's the bitbake clean incantation to remove all traces of sysfsutils from my build directory, so that i can rebuild the image with a simple $ bitbake core-image-minimal thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] ghostscript: fix parallel make issue
[Yocto 1202] Update ghostscript-9.02-parallel-make.patch to fix parallel make failure. Bump up PR. Signed-off-by: Kang Kai kai.k...@windriver.com --- .../ghostscript-9.02-parallel-make.patch | 13 + .../ghostscript/ghostscript_9.05.bb|2 +- 2 files changed, 14 insertions(+), 1 deletions(-) diff --git a/meta/recipes-extended/ghostscript/ghostscript/ghostscript-9.02-parallel-make.patch b/meta/recipes-extended/ghostscript/ghostscript/ghostscript-9.02-parallel-make.patch index bb0c41c..94ad5f5 100644 --- a/meta/recipes-extended/ghostscript/ghostscript/ghostscript-9.02-parallel-make.patch +++ b/meta/recipes-extended/ghostscript/ghostscript/ghostscript-9.02-parallel-make.patch @@ -1,6 +1,8 @@ When parallel make it will fail with multi copy, see http://bugzilla.pokylinux.org/show_bug.cgi?id=1202 +Update for psi/int.mak to avoid parallel build error. + Upstream-Status: Pending Signed-off-by: Kang Kai kai.k...@windriver.com @@ -34,3 +36,14 @@ Index: ghostscript-9.04/base/lib.mak $(GLCC) $(GLO_)gconfig.$(OBJ) $(C_) $(GLGEN)gconfig.c $(GLOBJ)gscdefs.$(OBJ) : $(GLSRC)gscdef.c\ +--- ghostscript-9.05/psi/int.mak.orig 2012-03-28 14:48:20.082048252 +0800 ghostscript-9.05/psi/int.mak 2012-03-28 14:55:03.142053958 +0800 +@@ -272,7 +272,7 @@ + $(gconf_h) $(gconfigd_h) $(gsmemory_h) $(gstypes_h)\ + $(iminst_h) $(iref_h) $(ivmspace_h) $(opdef_h) $(iplugin_h) + $(RM_) $(PSGEN)iconfig.c +- $(CP_) $(gconfig_h) $(PSGEN)gconfig.h ++ -$(CP_) $(gconfig_h) $(PSGEN)gconfig.h + $(CP_) $(PSSRC)iconf.c $(PSGEN)iconfig.c + $(PSCC) $(PSO_)iconfig.$(OBJ) $(C_) $(PSGEN)iconfig.c + diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.05.bb b/meta/recipes-extended/ghostscript/ghostscript_9.05.bb index 67b1cf7..6fc9f57 100644 --- a/meta/recipes-extended/ghostscript/ghostscript_9.05.bb +++ b/meta/recipes-extended/ghostscript/ghostscript_9.05.bb @@ -15,7 +15,7 @@ SECTION = console/utils LICENSE = GPLv3 LIC_FILES_CHKSUM = file://LICENSE;md5=c5326026692dbed183f0558f926580f8 -PR = r0 +PR = r1 DEPENDS = ghostscript-native tiff jpeg fontconfig cups DEPENDS_virtclass-native = -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips
From: Martin Jansa martin.ja...@gmail.com Still need mesa-xlib for emulation of GLX interface on qemuarm/qemumips, where mesa-dri doesn't work for pure qemu emulator. [YOCTO #2066] fixed. --- meta/conf/distro/include/default-providers.inc |2 +- meta/recipes-graphics/mesa/mesa-xlib.inc |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index 54c90d3..3850a2f 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -5,7 +5,7 @@ PREFERRED_PROVIDER_virtual/db ?= db PREFERRED_PROVIDER_virtual/db-native ?= db-native PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xorg -PREFERRED_PROVIDER_virtual/libgl ?= mesa-dri +PREFERRED_PROVIDER_virtual/libgl ?= mesa-xlib PREFERRED_PROVIDER_virtual/update-alternatives ?= update-alternatives-cworth PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim diff --git a/meta/recipes-graphics/mesa/mesa-xlib.inc b/meta/recipes-graphics/mesa/mesa-xlib.inc index b720e14..c431eab 100644 --- a/meta/recipes-graphics/mesa/mesa-xlib.inc +++ b/meta/recipes-graphics/mesa/mesa-xlib.inc @@ -1 +1,3 @@ EXTRA_OECONF += --with-driver=xlib --without-gallium-drivers + +COMPATIBLE_MACHINE = (qemuarm|qemumips|qemuppc) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] gl fix on qemuarm/qemumips
From: Zhai Edwin edwin.z...@intel.com RP, This fix make GL apps runs on qemuarm with emulated GLX interface from mesa-xlib. [YOCTO #2066] got fixed. Thanks, Edwin The following changes since commit 265903bdffb10c95ceaf7a892151a50b67939c71: procps: don't print error message with kernel 3.0+ (2012-03-28 10:16:30 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib gzhai/fix2 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/fix2 Martin Jansa (1): virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips meta/conf/distro/include/default-providers.inc |2 +- meta/recipes-graphics/mesa/mesa-xlib.inc |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
I always use bitbake -c clean -c cleansstate package for that purpose. On Wed, Mar 28, 2012 at 11:35 AM, Robert P. J. Day rpj...@crashcourse.cawrote: On Tue, 27 Mar 2012, Christopher Larson wrote: I IMAGE_INSTALL_append or IMAGE_INSTALL_append_pn-core-image-minimal or whatever when I need to quickly add a package temporarily, myself. once i add this package and build a new image to verify it was added, i want to revert and rebuild the original QEMU image again. so after removing that line from local.conf, what's the bitbake clean incantation to remove all traces of sysfsutils from my build directory, so that i can rebuild the image with a simple $ bitbake core-image-minimal thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips
On Wed, Mar 28, 2012 at 06:10:26PM +0800, edwin.z...@intel.com wrote: From: Martin Jansa martin.ja...@gmail.com I don't think I've ever sent something like this. Actually I've sent patch: default-providers: switch virtual/libgl from mesa-xlib to mesa-dri * to match default virtual/xserver And this just reverts it + adds suspicious COMPATIBLE_MACHINE.. Cheers, Still need mesa-xlib for emulation of GLX interface on qemuarm/qemumips, where mesa-dri doesn't work for pure qemu emulator. [YOCTO #2066] fixed. --- meta/conf/distro/include/default-providers.inc |2 +- meta/recipes-graphics/mesa/mesa-xlib.inc |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index 54c90d3..3850a2f 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -5,7 +5,7 @@ PREFERRED_PROVIDER_virtual/db ?= db PREFERRED_PROVIDER_virtual/db-native ?= db-native PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xorg -PREFERRED_PROVIDER_virtual/libgl ?= mesa-dri +PREFERRED_PROVIDER_virtual/libgl ?= mesa-xlib PREFERRED_PROVIDER_virtual/update-alternatives ?= update-alternatives-cworth PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim diff --git a/meta/recipes-graphics/mesa/mesa-xlib.inc b/meta/recipes-graphics/mesa/mesa-xlib.inc index b720e14..c431eab 100644 --- a/meta/recipes-graphics/mesa/mesa-xlib.inc +++ b/meta/recipes-graphics/mesa/mesa-xlib.inc @@ -1 +1,3 @@ EXTRA_OECONF += --with-driver=xlib --without-gallium-drivers + +COMPATIBLE_MACHINE = (qemuarm|qemumips|qemuppc) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Wednesday 28 March 2012 07:06:21 Robert P. J. Day wrote: On Wed, 28 Mar 2012, Paul Eggleton wrote: On Wednesday 28 March 2012 12:51:46 Marko Katić wrote: I always use bitbake -c clean -c cleansstate package for that purpose. Firstly, cleansstate does a clean already, so no need to specify that as well. Secondly, images are always rebuilt so provided you comment out the IMAGE_INSTALL_append or whatever you have done to change the image contents, you can just build the image again and it will be rebuilt as it was before. i was testing the various solutions presented, and the first couple worked just by changing the local.conf file (both adding and removing), but the third using DISTRO_EXTRA_RDEPENDS didn't appear to make a difference after i added the appropriate line to local.conf. if i add the line: DISTRO_EXTRA_RDEPENDS += sysfsutils do you know if this requires an explicit reconfiguration of some kind to be picked up? it's exactly these niggling details i'm trying to clarify. Yes, it will. You would need to clean and rebuild task-base because unlike the other methods the dependency gets built into a task package. This is one of the reasons you should not use DISTRO_EXTRA_RDEPENDS from local.conf - this is intended to be set from the distro configuration only. Please don't recommend this to be modified from local.conf - stick to CORE_IMAGE_EXTRA_INSTALL (or IMAGE_INSTALL_append, if you must). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Wed, 28 Mar 2012, Paul Eggleton wrote: On Wednesday 28 March 2012 07:06:21 Robert P. J. Day wrote: On Wed, 28 Mar 2012, Paul Eggleton wrote: On Wednesday 28 March 2012 12:51:46 Marko Katić wrote: I always use bitbake -c clean -c cleansstate package for that purpose. Firstly, cleansstate does a clean already, so no need to specify that as well. Secondly, images are always rebuilt so provided you comment out the IMAGE_INSTALL_append or whatever you have done to change the image contents, you can just build the image again and it will be rebuilt as it was before. i was testing the various solutions presented, and the first couple worked just by changing the local.conf file (both adding and removing), but the third using DISTRO_EXTRA_RDEPENDS didn't appear to make a difference after i added the appropriate line to local.conf. if i add the line: DISTRO_EXTRA_RDEPENDS += sysfsutils do you know if this requires an explicit reconfiguration of some kind to be picked up? it's exactly these niggling details i'm trying to clarify. Yes, it will. You would need to clean and rebuild task-base because unlike the other methods the dependency gets built into a task package. This is one of the reasons you should not use DISTRO_EXTRA_RDEPENDS from local.conf - this is intended to be set from the distro configuration only. Please don't recommend this to be modified from local.conf - stick to CORE_IMAGE_EXTRA_INSTALL (or IMAGE_INSTALL_append, if you must). even though i realize this technique is not encouraged for local.conf, as i mentioned, i just tested using it from scratch in a brand new build and it still didn't add that package to my image. if it should have, then something isn't working. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] ghostscript: Fixes for parallel_make
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- diff --git a/meta/recipes-extended/ghostscript/ghostscript/ghostscript-9.02-parallel-make.patch b/meta/recipes-extended/ghostscript/ghostscript/ghostscript-9.02-parallel-make.patch index bb0c41c..8491053 100644 --- a/meta/recipes-extended/ghostscript/ghostscript/ghostscript-9.02-parallel-make.patch +++ b/meta/recipes-extended/ghostscript/ghostscript/ghostscript-9.02-parallel-make.patch @@ -5,9 +5,14 @@ Upstream-Status: Pending Signed-off-by: Kang Kai kai.k...@windriver.com -RP: Tweaked to include lib.mak fixes ghostscript-9.02/base/unixhead.mak.orig2011-07-27 17:06:17.749456100 +0800 -+++ ghostscript-9.02/base/unixhead.mak 2011-07-27 17:06:37.449456100 +0800 +RP: Extended || true to all CP_ operations, they all can race e.g.: +| cp -f ./obj/gconfxx.h ./obj/gconfig.h +| cp: cannot create regular file `./obj/gconfig.h': File exists + +Index: ghostscript-9.05/base/unixhead.mak +=== +--- ghostscript-9.05.orig/base/unixhead.mak2012-03-28 10:55:23.804608117 + ghostscript-9.05/base/unixhead.mak 2012-03-28 10:56:47.544606075 + @@ -54,7 +54,7 @@ # Define generic commands. @@ -17,11 +22,20 @@ RP: Tweaked to include lib.mak fixes RM_=rm -f RMN_=rm -f -Index: ghostscript-9.04/base/lib.mak +Index: ghostscript-9.05/base/lib.mak === ghostscript-9.04.orig/base/lib.mak 2011-11-25 13:06:21.728502636 + -+++ ghostscript-9.04/base/lib.mak 2011-11-25 13:08:33.924504957 + -@@ -592,10 +592,8 @@ +--- ghostscript-9.05.orig/base/lib.mak 2012-03-28 10:55:23.816608117 + ghostscript-9.05/base/lib.mak 2012-03-28 10:55:41.864605914 + +@@ -327,7 +327,7 @@ + $(GLOBJ)md5.$(OBJ) : $(GLSRC)md5.c $(AK) $(md5_h) $(std_h) $(MAKEDIRS) $(EXP)$(ECHOGS_XE) + $(EXP)$(ECHOGS_XE) -w $(GLGEN)md5.h -x 23 include -x 2022 memory_.h -x 22 + $(EXP)$(ECHOGS_XE) -a $(GLGEN)md5.h -+R $(GLSRC)md5.h +- $(CP_) $(GLSRC)md5.c $(GLGEN)md5.c ++ $(CP_) $(GLSRC)md5.c $(GLGEN)md5.c || true + $(GLCC) $(GLO_)md5.$(OBJ) $(C_) $(GLGEN)md5.c + $(RM_) $(GLGEN)md5.c $(GLGEN)md5.h + +@@ -593,22 +593,20 @@ $(gscdefs_h) $(gconf_h)\ $(gxdevice_h) $(gxiclass_h) $(gxiodev_h) $(gxiparam_h) $(TOP_MAKEFILES)\ $(MAKEDDIRS) @@ -29,8 +43,828 @@ Index: ghostscript-9.04/base/lib.mak - $(RM_) $(GLGEN)gconfig.h - $(CP_) $(gconfig_h) $(GLGEN)gconfig.h - $(CP_) $(GLSRC)gconf.c $(GLGEN)gconfig.c -+ $(CP_) $(gconfig_h) $(GLGEN)gconfig.h || true -+ $(CP_) $(GLSRC)gconf.c $(GLGEN)gconfig.c || true ++ $(CP_) $(gconfig_h) $(GLGEN)gconfig.h || true || true ++ $(CP_) $(GLSRC)gconf.c $(GLGEN)gconfig.c || true || true $(GLCC) $(GLO_)gconfig.$(OBJ) $(C_) $(GLGEN)gconfig.c $(GLOBJ)gscdefs.$(OBJ) : $(GLSRC)gscdef.c\ + $(std_h) $(gscdefs_h) $(gconfigd_h) $(TOP_MAKEFILES) $(MAKEDIRS) + $(RM_) $(GLGEN)gscdefs.c +- $(CP_) $(GLSRC)gscdef.c $(GLGEN)gscdefs.c ++ $(CP_) $(GLSRC)gscdef.c $(GLGEN)gscdefs.c || true + $(GLCC) $(GLO_)gscdefs.$(OBJ) $(C_) $(GLGEN)gscdefs.c + + $(AUX)gscdefs.$(OBJ) : $(GLSRC)gscdef.c\ + $(std_h) $(gscdefs_h) $(gconfigd_h) $(TOP_MAKEFILES) $(MAKEDIRS) + $(RM_) $(AUX)gscdefs.c +- $(CP_) $(GLSRC)gscdef.c $(AUX)gscdefs.c ++ $(CP_) $(GLSRC)gscdef.c $(AUX)gscdefs.c || true + $(GLCCAUX) $(AUXO_)gscdefs.$(OBJ) $(C_) $(AUX)gscdefs.c + + $(GLOBJ)gxacpath.$(OBJ) : $(GLSRC)gxacpath.c $(AK) $(gx_h)\ +@@ -1428,7 +1426,7 @@ + $(GLJCC) $(GLO_)sjpegc_0.$(OBJ) $(C_) $(GLSRC)sjpegc.c + + $(GLOBJ)sjpegc.$(OBJ) : $(GLOBJ)sjpegc_$(SHARE_JPEG).$(OBJ) +- $(CP_) $(GLOBJ)sjpegc_$(SHARE_JPEG).$(OBJ) $(GLOBJ)sjpegc.$(OBJ) ++ $(CP_) $(GLOBJ)sjpegc_$(SHARE_JPEG).$(OBJ) $(GLOBJ)sjpegc.$(OBJ) || true + + # sdcparam is used by the filter operator and the PS/PDF writer. + # It is not included automatically in sdcte/d. +@@ -1456,7 +1454,7 @@ + $(GLJCC) $(GLO_)sdcte_0.$(OBJ) $(C_) $(GLSRC)sdcte.c + + $(GLOBJ)sdcte.$(OBJ) : $(GLOBJ)sdcte_$(SHARE_JPEG).$(OBJ) $(MAKEDIRS) +- $(CP_) $(GLOBJ)sdcte_$(SHARE_JPEG).$(OBJ) $(GLOBJ)sdcte.$(OBJ) ++ $(CP_) $(GLOBJ)sdcte_$(SHARE_JPEG).$(OBJ) $(GLOBJ)sdcte.$(OBJ) || true + + + $(GLOBJ)sjpege_1.$(OBJ) : $(GLSRC)sjpege.c $(AK)\ +@@ -1472,7 +1470,7 @@ + $(GLJCC) $(GLO_)sjpege_0.$(OBJ) $(C_) $(GLSRC)sjpege.c + + $(GLOBJ)sjpege.$(OBJ) : $(GLOBJ)sjpege_$(SHARE_JPEG).$(OBJ) $(MAKEDIRS) +- $(CP_) $(GLOBJ)sjpege_$(SHARE_JPEG).$(OBJ) $(GLOBJ)sjpege.$(OBJ) ++ $(CP_) $(GLOBJ)sjpege_$(SHARE_JPEG).$(OBJ) $(GLOBJ)sjpege.$(OBJ) || true + + # sdeparam is used by the filter operator and the PS/PDF writer. + # It is not included automatically in sdcte. +@@ -1504,7 +1502,7 @@ + $(GLJCC) $(GLO_)sdctd_0.$(OBJ) $(C_) $(GLSRC)sdctd.c + + $(GLOBJ)sdctd.$(OBJ) : $(GLOBJ)sdctd_$(SHARE_JPEG).$(OBJ) $(MAKEDIRS) +- $(CP_)
[OE-core] [PATCH] gcc-cross-intermediate: Ensure we move the libraries from the correct location
This fixes multilib issues if you try for example to use a BASELIB of /lib32
which wouldn't work without this change since the compiler install location
is taken from gcc -print-multi-os-directory which can still turn out to be
/lib.
The reason is that a 32 bit gcc has no multilib code enabled and will always
return . as that value rather than ../${base_libdir} which our changes
to gcc enable and return in 64 bit mode.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
b/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
index ea105e6..316a764 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
@@ -37,7 +37,8 @@ do_compile () {
do_install () {
oe_runmake 'DESTDIR=${D}' install
install -d ${D}${target_base_libdir}/
- mv ${D}${exec_prefix}/${TARGET_SYS}/${baselib}/*
${D}${target_base_libdir}/
+ osdir=`${D}${STAGING_BINDIR_TOOLCHAIN}.${PN}/${TARGET_PREFIX}gcc
-print-multi-os-directory`
+ mv ${D}${exec_prefix}/${TARGET_SYS}/lib/$osdir/*
${D}${target_base_libdir}/
# We don't really need this (here shares/ contains man/, info/,
locale/).
rm -rf ${D}${datadir}/
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] tiff: Make builds deterministic
libtiff now depends on lzma which can be obtained from xz and doesn't use lzo.
Previously, libtiff would detect and use lzma if it was present leading to
a number of race conditions including failures in things linking to libtiff
such as ghostscript since lzma could be removed while being rebuild leading
to failures in linking.
This patch corrects the dependency.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.0.1.bb
b/meta/recipes-multimedia/libtiff/tiff_4.0.1.bb
index 6fb4163..54c4cbc 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.0.1.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.0.1.bb
@@ -2,8 +2,8 @@ DESCRIPTION = This software provides support for the Tag Image
File Format (TIF
LICENSE = BSD-2-Clause
LIC_FILES_CHKSUM = file://COPYRIGHT;md5=34da3db46fab7501992f9615d7e158cf
HOMEPAGE = http://www.remotesensing.org/libtiff/;
-DEPENDS = zlib jpeg lzo
-PR = r0
+DEPENDS = zlib jpeg xz
+PR = r1
SRC_URI = ftp://ftp.remotesensing.org/pub/libtiff/tiff-${PV}.tar.gz \
file://libtool2.patch
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Wednesday 28 March 2012 07:14:41 Robert P. J. Day wrote: even though i realize this technique is not encouraged for local.conf, as i mentioned, i just tested using it from scratch in a brand new build and it still didn't add that package to my image. if it should have, then something isn't working. So, there are two reasons why it might not work: 1) If you're using core-image-minimal, it will never be included using DISTRO_EXTRA_RDEPENDS (nor MACHINE_EXTRA_RDEPENDS, for that matter). This is because core-image-minimal does not include task-base - only the minimum required to get a working system. 2) Otherwise, if task-base has already been built and will be included (which it will be for any image that inherits from core-image and does not override IMAGE_INSTALL, e.g. core-image-sato) but you aren't using OEBasicHash (defaults to enabled for latest Poky, but not for OE-Core's default policy) then changing DISTRO_EXTRA_RDEPENDS after the fact won't do anything unless you force task-base to rebuild. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips
On Wed, 2012-03-28 at 12:58 +0200, Martin Jansa wrote: On Wed, Mar 28, 2012 at 06:10:26PM +0800, edwin.z...@intel.com wrote: From: Martin Jansa martin.ja...@gmail.com I don't think I've ever sent something like this. Actually I've sent patch: default-providers: switch virtual/libgl from mesa-xlib to mesa-dri * to match default virtual/xserver And this just reverts it + adds suspicious COMPATIBLE_MACHINE.. Cheers, Still need mesa-xlib for emulation of GLX interface on qemuarm/qemumips, where mesa-dri doesn't work for pure qemu emulator. [YOCTO #2066] fixed. --- meta/conf/distro/include/default-providers.inc |2 +- meta/recipes-graphics/mesa/mesa-xlib.inc |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index 54c90d3..3850a2f 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -5,7 +5,7 @@ PREFERRED_PROVIDER_virtual/db ?= db PREFERRED_PROVIDER_virtual/db-native ?= db-native PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xorg -PREFERRED_PROVIDER_virtual/libgl ?= mesa-dri +PREFERRED_PROVIDER_virtual/libgl ?= mesa-xlib PREFERRED_PROVIDER_virtual/update-alternatives ?= update-alternatives-cworth PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim diff --git a/meta/recipes-graphics/mesa/mesa-xlib.inc b/meta/recipes-graphics/mesa/mesa-xlib.inc index b720e14..c431eab 100644 --- a/meta/recipes-graphics/mesa/mesa-xlib.inc +++ b/meta/recipes-graphics/mesa/mesa-xlib.inc @@ -1 +1,3 @@ EXTRA_OECONF += --with-driver=xlib --without-gallium-drivers + +COMPATIBLE_MACHINE = (qemuarm|qemumips|qemuppc) I agree this COMPATIBLE_MACHINE is wrong. I'd suggest we need to change both xserver-org to xserver-xorg-lite and libgl to meta-xlib and then this might work better and address Martin's concerns too. I'd like to understand why dri can't work under qemu too though. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] clutter: clutter_git is really clutter-1.8_git, rename
Both these clutter recipes provide 1.8. With different PN namespace, a world build cna build both causing the clutter libraries to disappear at certain points of the build. In particular, this causes issues for mx. This patch puts then into the same PN namespace so only one can be built. [YOCTO #2158] Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- diff --git a/meta/recipes-graphics/clutter/clutter_git.bb b/meta/recipes-graphics/clutter/clutter-1.8_git.bb index 9f7b048..9f7b048 100644 --- a/meta/recipes-graphics/clutter/clutter_git.bb +++ b/meta/recipes-graphics/clutter/clutter-1.8_git.bb ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Wed, 28 Mar 2012, Paul Eggleton wrote: On Wednesday 28 March 2012 07:14:41 Robert P. J. Day wrote: even though i realize this technique is not encouraged for local.conf, as i mentioned, i just tested using it from scratch in a brand new build and it still didn't add that package to my image. if it should have, then something isn't working. So, there are two reasons why it might not work: 1) If you're using core-image-minimal, it will never be included using DISTRO_EXTRA_RDEPENDS (nor MACHINE_EXTRA_RDEPENDS, for that matter). This is because core-image-minimal does not include task-base - only the minimum required to get a working system. ah, quite so, i didn't notice that, i'll try again with another image just for verification. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Wed, Mar 28, 2012 at 1:22 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 28 March 2012 07:14:41 Robert P. J. Day wrote: even though i realize this technique is not encouraged for local.conf, as i mentioned, i just tested using it from scratch in a brand new build and it still didn't add that package to my image. if it should have, then something isn't working. So, there are two reasons why it might not work: 1) If you're using core-image-minimal, it will never be included using Robert, core-image-base is much better for testing (is a bit like Angstrom console-image) Paul, maybe core-image-base (and core-image-core) should be listed in the output of oe-init-build-env co.? Regards Andrea DISTRO_EXTRA_RDEPENDS (nor MACHINE_EXTRA_RDEPENDS, for that matter). This is because core-image-minimal does not include task-base - only the minimum required to get a working system. 2) Otherwise, if task-base has already been built and will be included (which it will be for any image that inherits from core-image and does not override IMAGE_INSTALL, e.g. core-image-sato) but you aren't using OEBasicHash (defaults to enabled for latest Poky, but not for OE-Core's default policy) then changing DISTRO_EXTRA_RDEPENDS after the fact won't do anything unless you force task-base to rebuild. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
Op 27 mrt. 2012, om 05:20 heeft Robert P. J. Day het volgende geschreven: i'm currently poring over the OE docs (including the ones at the yocto site), and i'm trying to figure out how to simply add a package to an image through one's local.conf file. Why throught local.conf. Image recipes are really small and easy to understand. Just make a copy of the recipe you want to change and change that, no need to go poke at it from non obvious places. I really don't understand why people are so against creating their own image recipe since foo-image.bb is not really foo-image anymore if you add 'bar' to it thru e.g. local.conf. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Wed, 28 Mar 2012, Koen Kooi wrote: Op 27 mrt. 2012, om 05:20 heeft Robert P. J. Day het volgende geschreven: i'm currently poring over the OE docs (including the ones at the yocto site), and i'm trying to figure out how to simply add a package to an image through one's local.conf file. Why throught local.conf. Image recipes are really small and easy to understand. Just make a copy of the recipe you want to change and change that, no need to go poke at it from non obvious places. I really don't understand why people are so against creating their own image recipe since foo-image.bb is not really foo-image anymore if you add 'bar' to it thru e.g. local.conf. actually, i have no problem with that, as long as the same philosophy holds in the official OE/yocto docs. but if the docs themselves explain how to do it through local.conf, then it should be supported. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] eglibc-2.15: Update SRCREV
On Fri, Mar 23, 2012 at 7:26 PM, Martin Jansa martin.ja...@gmail.com wrote: On Fri, Mar 23, 2012 at 02:17:02PM +0100, Martin Jansa wrote: On Fri, Mar 23, 2012 at 12:05:25PM +, Richard Purdie wrote: On Thu, 2012-03-22 at 19:56 -0700, Khem Raj wrote: Get new patches and remove the one that got merged upstream Signed-off-by: Khem Raj raj.k...@gmail.com --- .../eglibc/eglibc-2.15/GLRO_dl_debug_mask.patch | 108 .../eglibc-2.15/armv4-eabi-compile-fix.patch | 25 - .../eglibc/eglibc-2.15/initgroups_keys.patch | 20 meta/recipes-core/eglibc/eglibc_2.15.bb | 5 +- 4 files changed, 131 insertions(+), 27 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/GLRO_dl_debug_mask.patch delete mode 100644 meta/recipes-core/eglibc/eglibc-2.15/armv4-eabi-compile-fix.patch create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/initgroups_keys.patch Since 2.15 isn't the default I'm tempted to merge this despite the point we're at in the release cycle. I'd like to give anyone using this the opportunity to comment first though. I'm testing this on all archs I'm using (armv4t, armv5te, armv7a, x86-64) and will report tomorrow. Doesn't look related to this change, but I got interesing error on other buildhost (on mine everything seems fine sofar including tests on target), I don't have log from armv4t build on mine, because it's on tmpfs and there was unexpected reboot when I wasn't home :/. Hi Martin Does it look good for your testing ? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] eglibc-2.15: Update SRCREV
On Wed, Mar 28, 2012 at 07:15:32AM -0700, Khem Raj wrote: On Fri, Mar 23, 2012 at 7:26 PM, Martin Jansa martin.ja...@gmail.com wrote: On Fri, Mar 23, 2012 at 02:17:02PM +0100, Martin Jansa wrote: On Fri, Mar 23, 2012 at 12:05:25PM +, Richard Purdie wrote: On Thu, 2012-03-22 at 19:56 -0700, Khem Raj wrote: Get new patches and remove the one that got merged upstream Signed-off-by: Khem Raj raj.k...@gmail.com --- .../eglibc/eglibc-2.15/GLRO_dl_debug_mask.patch | 108 .../eglibc-2.15/armv4-eabi-compile-fix.patch | 25 - .../eglibc/eglibc-2.15/initgroups_keys.patch | 20 meta/recipes-core/eglibc/eglibc_2.15.bb | 5 +- 4 files changed, 131 insertions(+), 27 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/GLRO_dl_debug_mask.patch delete mode 100644 meta/recipes-core/eglibc/eglibc-2.15/armv4-eabi-compile-fix.patch create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/initgroups_keys.patch Since 2.15 isn't the default I'm tempted to merge this despite the point we're at in the release cycle. I'd like to give anyone using this the opportunity to comment first though. I'm testing this on all archs I'm using (armv4t, armv5te, armv7a, x86-64) and will report tomorrow. Doesn't look related to this change, but I got interesing error on other buildhost (on mine everything seems fine sofar including tests on target), I don't have log from armv4t build on mine, because it's on tmpfs and there was unexpected reboot when I wasn't home :/. Hi Martin Does it look good for your testing ? Seems fine in runtime any hint about that build issue? Today I got another one :/ build-x86_64-oe-linux/shlib.lds:127: syntax error while building eglibc I had reports about this before, but wasn't able to reproduce it on my machine, today I got it for first time (maybe because of building with -j8 instead of -j4), so I've created simple testcase to compare interim outputs from shlib.lds creation: http://build.shr-project.org/tests/jama/shlib-issue/ Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC][PATCH] gcc-configure: Pass distinct target flags
When building gcc-cross-canadian libgcc is built using
headers from gcc-crosssdk and not the target sysroot
because we do not pass proper CFLAGS for target bits
so it ends up using CFLAGS that were meant for compiling
canadian gcc itself. It does not show up as a problem
when building SDK with eglibc because eglibc-nativesdk
and eglibc have identical headers. The problem shows
up clearly when you try to build uclibc based meta-toolchain
since then nativesdk libc and target libc are different
Signed-off-by: Khem Raj raj.k...@gmail.com
---
meta/recipes-devtools/gcc/gcc-configure-common.inc |4
meta/recipes-devtools/gcc/gcc-configure-cross.inc |4
meta/recipes-devtools/gcc/gcc-configure-sdk.inc|6 +-
3 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc
b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index 04eda9e..8ec8dd1 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -104,6 +104,10 @@ do_configure () {
export CXXFLAGS_FOR_BUILD=${BUILD_CXXFLAGS}
export LDFLAGS_FOR_BUILD=${BUILD_LDFLAGS}
export ARCH_FLAGS_FOR_TARGET=${ARCH_FLAGS_FOR_TARGET}
+ export CFLAGS_FOR_TARGET=${TARGET_CFLAGS}
+ export CPPFLAGS_FOR_TARGET=${TARGET_CPPFLAGS}
+ export CXXFLAGS_FOR_TARGET=${TARGET_CXXFLAGS}
+ export LDFLAGS_FOR_TARGET=${TARGET_LDFLAGS}
(cd ${S} gnu-configize) || die failure running gnu-configize
oe_runconf
diff --git a/meta/recipes-devtools/gcc/gcc-configure-cross.inc
b/meta/recipes-devtools/gcc/gcc-configure-cross.inc
index 91834c2..65e340a 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-cross.inc
@@ -20,6 +20,10 @@ do_compile_prepend () {
export LD_FOR_TARGET=${TARGET_SYS}-ld
export NM_FOR_TARGET=${TARGET_SYS}-nm
export CC_FOR_TARGET=${CCACHE} ${TARGET_SYS}-gcc ${TARGET_CC_ARCH}
+ export CFLAGS_FOR_TARGET=${TARGET_CFLAGS}
+ export CPPFLAGS_FOR_TARGET=${TARGET_CPPFLAGS}
+ export CXXFLAGS_FOR_TARGET=${TARGET_CXXFLAGS}
+ export LDFLAGS_FOR_TARGET=${TARGET_LDFLAGS}
}
LIBGCCS_VAR = -lgcc_s
diff --git a/meta/recipes-devtools/gcc/gcc-configure-sdk.inc
b/meta/recipes-devtools/gcc/gcc-configure-sdk.inc
index 3043814..54e8ede 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-sdk.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-sdk.inc
@@ -30,7 +30,7 @@ export WINDRES_FOR_TARGET = ${TARGET_PREFIX}windres
#
# We need to override this and make sure the compiler can find staging
#
-export ARCH_FLAGS_FOR_TARGET = --sysroot=${STAGING_DIR_TARGET}
+export ARCH_FLAGS_FOR_TARGET = --sysroot=${STAGING_DIR_TARGET} -isystem
=${target_includedir}
do_configure () {
export CC_FOR_BUILD=${BUILD_CC}
@@ -39,6 +39,10 @@ do_configure () {
export CPPFLAGS_FOR_BUILD=${BUILD_CPPFLAGS}
export CXXFLAGS_FOR_BUILD=${BUILD_CXXFLAGS}
export LDFLAGS_FOR_BUILD=${BUILD_LDFLAGS}
+ export CFLAGS_FOR_TARGET=${TARGET_CFLAGS}
+ export CPPFLAGS_FOR_TARGET=${TARGET_CPPFLAGS}
+ export CXXFLAGS_FOR_TARGET=${TARGET_CXXFLAGS}
+ export LDFLAGS_FOR_TARGET=${TARGET_LDFLAGS}
(cd ${S} gnu-configize) || die failure running gnu-configize
oe_runconf
}
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk
Hi joaohf, Thank for the hint! I have got the patches from genext2fs-devel mailing list and did some tests: I can successfully create a .ext2 file of 8.5GB with genext2fs now! I’ll send an update to the genext2fs recipe later. Thanks, -- Dexuan From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Jo?o Henrique Freitas Sent: Wednesday, March 28, 2012 4:46 AM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk Hi, I guess we can just put that in the docs for now. For future improvement though I wonder if we can trick the fetcher into just pulling across the current files into the rootfs. I'll put that on my todo list for later. The following thread suggest a patch to fix it: http://sourceforge.net/mailarchive/forum.php?thread_name=1307458172.10974.64.camel%40skunkforum_name=genext2fs-devel Thanks. -- --- João Henrique Freitas - joaohf_at_gmail.comhttp://joaohf_at_gmail.com Campinas-SP-Brasil BSD051283 LPI 1 http://www.joaohfreitas.eti.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] self-hosted-image: pre-populate the builder user with poky source
Hi Saul,
Did you test bitbake core-image-minimal inside the vmware guest?
I got the following ERROR immediately:
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker
(see sanity.conf).
Following is the list of potential problems / advisories:
Pseudo is not functioning correctly, which will cause failures during
package installation. Please check your configuration.
ERROR: Execution of event handler 'check_sanity_eventhandler' failed
I suspect in the guest, pseudo is not setup properly?
Thanks,
-- Dexuan
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Tuesday, March 27, 2012 1:43 PM
To: openembedded-core@lists.openembedded.org
Cc: Cui, Dexuan
Subject: [PATCH 1/6] self-hosted-image: pre-populate the builder user with
poky source
From: Dexuan Cui dexuan@intel.com
This patch installs the poky source into the /home/builder/poky/ of the
self-hosted-image.
This makes the user of self-hosted-image easier to start a build.
I think the recent poky master is stable enough, so I specify a commit number
by SRCREV -- we may want to update this number before releasing 1.2.
This patch fixes [YOCTO #2065]
Signed-off-by: Dexuan Cui dexuan@intel.com
Added code for supporting target based pseudo fixed indentation
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/images/self-hosted-image.bb | 41
+++-
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index d56c2cb..5aa670d 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de
20420
-PR = r5
+PR = r6
CORE_IMAGE_EXTRA_INSTALL = \
task-self-hosted \
@@ -13,7 +13,10 @@ CORE_IMAGE_EXTRA_INSTALL = \ IMAGE_FEATURES
+= x11-mini package-management
# Ensure there's enough space to do a core-image-minimal build, with
rm_work enabled -IMAGE_ROOTFS_EXTRA_SPACE = 2621440
+IMAGE_ROOTFS_EXTRA_SPACE = 1048576
+#IMAGE_ROOTFS_EXTRA_SPACE = 2621440
+#IMAGE_ROOTFS_EXTRA_SPACE = 20971520
+#IMAGE_ROOTFS_EXTRA_SPACE = 5242880
# Do a quiet boot with limited console messages APPEND += quiet
@@ -21,3 +24,37 @@ APPEND += quiet
IMAGE_FSTYPES = vmdk
inherit core-image
+
+SRCREV = 26a46938d3ea1821e7bec4fa6cc8379babad238b
+SRC_URI = git://git.yoctoproject.org/poky;protocol=git
+
+fakeroot do_populate_poky_src () {
+ # Because fetch2's git's unpack uses -s cloneflag, the unpacked git repo
+ # will become invalid in the target.
+ rm -rf ${WORKDIR}/git/.git
+ rm -f ${WORKDIR}/git/.gitignore
+
+ cp -Rp ${WORKDIR}/git ${IMAGE_ROOTFS}/home/builder/poky
+
+ mkdir -p ${IMAGE_ROOTFS}/home/builder/poky/build/conf
+ cp -Rp ${DL_DIR} ${IMAGE_ROOTFS}/home/builder/poky/build
+ echo /usr/bin
${IMAGE_ROOTFS}/home/builder/poky/build/pseudodone
+ echo BB_NO_NETWORK = \1\
${IMAGE_ROOTFS}/home/builder/poky/build/conf/auto.conf
+ echo INHERIT += \rm_work\
${IMAGE_ROOTFS}/home/builder/poky/build/conf/auto.conf
+mkdir -p ${IMAGE_ROOTFS}/home/builder/pseudo
+echo export PSEUDO_PREFIX=/usr
${IMAGE_ROOTFS}/home/builder/.bashrc
+echo export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
${IMAGE_ROOTFS}/home/builder/.bashrc
+echo export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
+${IMAGE_ROOTFS}/home/builder/.bashrc
+
+chown builder.builder ${IMAGE_ROOTFS}/home/builder/pseudo
+
+ chown -R builder.builder ${IMAGE_ROOTFS}/home/builder/poky }
+
+IMAGE_PREPROCESS_COMMAND += do_populate_poky_src;
+
+python do_get_poky_src () {
+bb.build.exec_func('base_do_fetch', d)
+bb.build.exec_func('base_do_unpack', d) } addtask do_get_poky_src
+before do_rootfs
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] eglibc-2.15: Update SRCREV
On Wed, Mar 28, 2012 at 7:33 AM, Martin Jansa martin.ja...@gmail.com wrote: On Wed, Mar 28, 2012 at 07:15:32AM -0700, Khem Raj wrote: On Fri, Mar 23, 2012 at 7:26 PM, Martin Jansa martin.ja...@gmail.com wrote: On Fri, Mar 23, 2012 at 02:17:02PM +0100, Martin Jansa wrote: On Fri, Mar 23, 2012 at 12:05:25PM +, Richard Purdie wrote: On Thu, 2012-03-22 at 19:56 -0700, Khem Raj wrote: Get new patches and remove the one that got merged upstream Signed-off-by: Khem Raj raj.k...@gmail.com --- .../eglibc/eglibc-2.15/GLRO_dl_debug_mask.patch | 108 .../eglibc-2.15/armv4-eabi-compile-fix.patch | 25 - .../eglibc/eglibc-2.15/initgroups_keys.patch | 20 meta/recipes-core/eglibc/eglibc_2.15.bb | 5 +- 4 files changed, 131 insertions(+), 27 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/GLRO_dl_debug_mask.patch delete mode 100644 meta/recipes-core/eglibc/eglibc-2.15/armv4-eabi-compile-fix.patch create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/initgroups_keys.patch Since 2.15 isn't the default I'm tempted to merge this despite the point we're at in the release cycle. I'd like to give anyone using this the opportunity to comment first though. I'm testing this on all archs I'm using (armv4t, armv5te, armv7a, x86-64) and will report tomorrow. Doesn't look related to this change, but I got interesing error on other buildhost (on mine everything seems fine sofar including tests on target), I don't have log from armv4t build on mine, because it's on tmpfs and there was unexpected reboot when I wasn't home :/. Hi Martin Does it look good for your testing ? Seems fine in runtime any hint about that build issue? Today I got another one :/ build-x86_64-oe-linux/shlib.lds:127: syntax error while building eglibc I had reports about this before, but wasn't able to reproduce it on my machine, today I got it for first time (maybe because of building with -j8 instead of -j4), so I've created simple testcase to compare interim outputs from shlib.lds creation: http://build.shr-project.org/tests/jama/shlib-issue/ yes I am aware of this problem. Somehow tokens in linker script gets eaten up which results in unbalanced parens. I havent tracked it down. I have seen this with eglibc 2.13 as well. Are you using gold by any chance. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] genext2fs: support large files and filesystems without using large amounts of memor
Hi RP, Saul, Paul, Darren, Mark, Josh and joaohf and all, please comment. Let's figure out if this big patch is accepatable or not... With this patch, I can successfully create a 8.5GB .ext3 file with genext2fs. The speed is slow -- I spent about 1.5 hours. The following changes since commit 265903bdffb10c95ceaf7a892151a50b67939c71: procps: don't print error message with kernel 3.0+ (2012-03-28 10:16:30 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/master http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/master Dexuan Cui (1): genext2fs: support large files and filesystems without using large amounts of memory ...01-Fix-warnings-remove-some-unused-macros.patch | 70 ++ .../0002-Add-put_blk-and-put_nod-routines.patch| 1121 .../0003-Add-get_blkmap-and-put_blkmap.patch | 220 ...lker-for-walking-through-directory-entrie.patch | 355 +++ ...05-Make-filesystem-struct-not-an-overloay.patch | 372 +++ ...0006-Improve-the-efficiency-of-extend_blk.patch | 270 + ...ove-hdlinks-into-the-filesystem-structure.patch | 173 +++ ...t-the-creation-of-the-filesystem-structur.patch | 93 ++ ...e-byte-swapping-into-the-get-put-routines.patch | 419 ...rt-over-to-keeping-the-filesystem-on-disk.patch | 837 +++ ...les-into-the-filesystem-a-piece-at-a-time.patch | 101 ++ ...upport-large-file-support-and-rework-hole.patch | 209 .../0013-Add-volume-id-support.patch | 84 ++ ...014-Remove-unneeded-setting-of-s_reserved.patch | 26 + ...-Rework-creating-the-lost-found-directory.patch | 55 + ...ix-the-documentation-for-the-new-L-option.patch | 27 + .../0017-Fix-file-same-comparison.patch| 28 + ...andle-files-changing-while-we-are-working.patch | 87 ++ ...ke-sure-superblock-is-clear-on-allocation.patch | 40 + .../genext2fs-1.4.1/fix-nbblocks-cast.patch| 18 +- .../genext2fs/genext2fs-1.4.1/update_to_1.95.patch | 119 +++ meta/recipes-devtools/genext2fs/genext2fs_1.4.1.bb | 24 +- 22 files changed, 4738 insertions(+), 10 deletions(-) create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0001-Fix-warnings-remove-some-unused-macros.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0002-Add-put_blk-and-put_nod-routines.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0003-Add-get_blkmap-and-put_blkmap.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0004-Add-a-dirwalker-for-walking-through-directory-entrie.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0005-Make-filesystem-struct-not-an-overloay.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0006-Improve-the-efficiency-of-extend_blk.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0007-Move-hdlinks-into-the-filesystem-structure.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0008-Separate-out-the-creation-of-the-filesystem-structur.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0009-Move-byte-swapping-into-the-get-put-routines.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0010-Convert-over-to-keeping-the-filesystem-on-disk.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0011-Copy-files-into-the-filesystem-a-piece-at-a-time.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0012-Add-rev-1-support-large-file-support-and-rework-hole.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0013-Add-volume-id-support.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0014-Remove-unneeded-setting-of-s_reserved.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0015-Rework-creating-the-lost-found-directory.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0016-Fix-the-documentation-for-the-new-L-option.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0017-Fix-file-same-comparison.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0018-Handle-files-changing-while-we-are-working.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/0019-Make-sure-superblock-is-clear-on-allocation.patch create mode 100644 meta/recipes-devtools/genext2fs/genext2fs-1.4.1/update_to_1.95.patch -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Problem with perl upstream link
From time to time my build crashes after trying to unpack the downloaded perl package: Check the log here: ERROR: Logfile of failure stored in: BUILD/tmp-eglibc-eglibc/work/i686-linux/perl-native-5.14.2-r0/temp/log.do_unpack.14775 Log data follows: | NOTE: Unpacking BUILD/tmp-eglibc-eglibc/work/i686-linux/perl-native-5.14.2-r0/ | | gzip: stdin: invalid compressed data--crc error | tar: Child returned status 1 | tar: Error is not recoverable: exiting now | ERROR: Function failed: Unpack failure for URL: ' http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz'. Unpack command PATH=... tar xz --no-same-owner -f DOWNLOADS/perl-5.14.2.tar.gz failed with return value 2 NOTE: package perl-native-5.14.2-r0: task do_unpack: Failed To check the remote i did a simple test: wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz --2012-03-28 21:09:11-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz Resolving www.cpan.org... 207.171.7.177, 199.15.176.140, 2620:101:d000:8::140:1, ... Connecting to www.cpan.org|207.171.7.177|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 15223598 (15M) [application/octet-stream] Saving to: `perl-5.14.2.tar.gz' 100%[===] 15,223,598 1.07M/s in 99s 2012-03-28 21:10:52 (151 KB/s) - `perl-5.14.2.tar.gz' saved [15223598/15223598] tar xz --no-same-owner -f /media/HDD-WRS/yocto/2012-03-28-18-49-yocto-ve/../downloads/perl-5.14.2.tar.gz gzip: stdin: invalid compressed data--crc error tar: Child returned status 1 tar: Exiting with failure status due to previous errors Anybody knows about this issue? @g ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] qemu.inc: Use '=+' for IMAGE_FSTYPES
As per http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html a machine conf file should use '=+' to set IMAGE_FSTYPES. Signed-off-by: Tom Rini tr...@ti.com --- meta/conf/machine/include/qemu.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc index 10ab76e..a34477c 100644 --- a/meta/conf/machine/include/qemu.inc +++ b/meta/conf/machine/include/qemu.inc @@ -3,7 +3,7 @@ PREFERRED_PROVIDER_virtual/xserver ?= xserver-kdrive MACHINE_FEATURES = apm alsa pcmcia bluetooth irda usbgadget screen -IMAGE_FSTYPES ?= tar.bz2 ext3 +IMAGE_FSTYPES =+ tar.bz2 ext3 ROOT_FLASH_SIZE = 280 -- 1.7.0.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu.inc: Use '=' for IMAGE_FSTYPES
On Mon, Mar 26, 2012 at 05:56:16PM +0100, Richard Purdie wrote: On Mon, 2012-03-26 at 09:25 -0700, Tom Rini wrote: On Mon, Mar 26, 2012 at 10:15:13AM +0100, Richard Purdie wrote: On Fri, 2012-03-23 at 10:35 -0700, Tom Rini wrote: As per http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019772.html a machine conf file should use '=' to set IMAGE_FSTYPES. Signed-off-by: Tom Rini tr...@ti.com --- meta/conf/machine/include/qemu.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) As someone pointed out, what I mentioned in that email sadly doesn't work although it would be nice if they did. I suspect this is why we're using += since: We aren't using += today. We (openembedded-core) use ?=. meta-intel uses += and meta-ti is mixed (and I don't have meta-fsl-* handy). - The machine needs to say 'I need or support the following formats' so the machine ensures those formats exist at a minimum: IMAGE_FSTYPES += - The distro needs to say 'I always want format X' so the distro can do: IMAGE_FSTYPES += yyy - The user needs to say 'I know best, give me only format X' This one is the problem case so the user has to use overrides: IMAGE_FSTYPES_override = X (where override can be MACHINE or forcevariable) - The user needs to say 'I know best, give me what you support + X' IMAGE_FSTYPES += X Whilst I think that is less than ideal since it forces use of overrides in local.conf to override, changing the += in machine conf files doesn't gain us much, it just breaks += in local.conf. I'm open to other feedback though... Well, I suggested ??= / ?= and posted some results from bitbake -e... Ok. += plays out as above. I realise its not what is in qemu.inc, it is used in meta-intel though which I looked at after qemu.inc and I guess has confused me. With ?= in machine.conf: The user defined IMAGE_FSTYPES would override the machine ones. Distro can still append to it. The downside is a user append would not work out as expected. So the question is which is the more user expected behaviour? =+ makes overwriting IMAGE_FSTYPES hard ?= makes appending IMAGE_FSTYPES hard I suspect a user is more likely to want to append than overwrite. Getting an append to work with ?= is extremely non-obvious, even worse syntax than the =+ overwriting case with overrides. So bottom line, I'm tempted to recommend we use =+. Further thoughts? Richard, So, what is the subtle difference between += that we started with and =+ that you recommended at the end? I realize those are for append and prepend, but are they handled any different? Was your recommendation to use =+ at the end, instead of += that was used originally, based on some specifics? Thanks. -- Denys ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] adding a single package to an image -- what's the proper way?
On Wednesday 28 March 2012 15:19:20 Andrea Adami wrote: Robert, core-image-base is much better for testing (is a bit like Angstrom console-image) Paul, maybe core-image-base (and core-image-core) should be listed in the output of oe-init-build-env co.? Possibly. In the next development cycle though I would like to do a rework of the images and tasks so that they are better named and particularly in the case of tasks, more effective. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qt4: move from 4.8.0 to 4.8.1
* No changes other than source checksums and PR at recipe level.
* DEFAULT_PREFERENCE still set to -1
Signed-off-by: Andreas Oberritter o...@opendreambox.org
---
* Considering that OE-core is in a stabilization phase, updating
Qt may be a bad idea. However, version 4.8.0 has D_P=-1, so
4.7.4 still gets built by default.
* Even if this won't get applied now, other people might be
interested in testing this version and giving feedback.
* This recipe has been compile-tested on x86 and x86_64
for mips32el (qt4-native and qt4-embedded).
meta/recipes-qt/qt4/{qt-4.8.0.inc = qt-4.8.1.inc} |4 ++--
.../0001-Added-Openembedded-crossarch-option.patch |0
.../{qt-4.8.0 = qt-4.8.1}/configure-lflags.patch |0
.../configure_oe_compiler.patch|0
.../{qt-4.8.0 = qt-4.8.1}/fix-translations.patch |0
.../recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/g++.conf |0
.../hack-out-pg2-4.7.0.patch |0
.../qt4/{qt-4.8.0 = qt-4.8.1}/linux.conf |0
.../{qt-4.8.0 = qt-4.8.1}/pulseaudio-config.patch |0
.../{qt-4.8.0 = qt-4.8.1}/qmake_cxx_eval.patch|0
.../{qt-4.8.0 = qt-4.8.1}/qmake_pri_fixes.patch |0
...qt4-embedded_4.8.0.bb = qt4-embedded_4.8.1.bb} |2 +-
.../{qt4-native_4.8.0.bb = qt4-native_4.8.1.bb} |4 ++--
meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.0.bb | 10 --
meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.1.bb | 10 ++
...qt4-x11-free_4.8.0.bb = qt4-x11-free_4.8.1.bb} |2 +-
16 files changed, 16 insertions(+), 16 deletions(-)
rename meta/recipes-qt/qt4/{qt-4.8.0.inc = qt-4.8.1.inc} (93%)
rename meta/recipes-qt/qt4/{qt-4.8.0 =
qt-4.8.1}/0001-Added-Openembedded-crossarch-option.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/configure-lflags.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/configure_oe_compiler.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/fix-translations.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/g++.conf (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/hack-out-pg2-4.7.0.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/linux.conf (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/pulseaudio-config.patch
(100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/qmake_cxx_eval.patch (100%)
rename meta/recipes-qt/qt4/{qt-4.8.0 = qt-4.8.1}/qmake_pri_fixes.patch (100%)
rename meta/recipes-qt/qt4/{qt4-embedded_4.8.0.bb = qt4-embedded_4.8.1.bb}
(89%)
rename meta/recipes-qt/qt4/{qt4-native_4.8.0.bb = qt4-native_4.8.1.bb} (60%)
delete mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.0.bb
create mode 100644 meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.1.bb
rename meta/recipes-qt/qt4/{qt4-x11-free_4.8.0.bb = qt4-x11-free_4.8.1.bb}
(90%)
diff --git a/meta/recipes-qt/qt4/qt-4.8.0.inc b/meta/recipes-qt/qt4/qt-4.8.1.inc
similarity index 93%
rename from meta/recipes-qt/qt4/qt-4.8.0.inc
rename to meta/recipes-qt/qt4/qt-4.8.1.inc
index c0d90cd..cd78401 100644
--- a/meta/recipes-qt/qt4/qt-4.8.0.inc
+++ b/meta/recipes-qt/qt4/qt-4.8.1.inc
@@ -22,8 +22,8 @@ SRC_URI =
http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.
file://linux.conf \
-SRC_URI[md5sum] = e8a5fdbeba2927c948d9f477a6abe904
-SRC_URI[sha256sum] =
9392b74e485e15f75a3e07a527547d4f6747eaf55ebce71ba0e863a9fd320b6e
+SRC_URI[md5sum] = 7960ba8e18ca31f0c6e4895a312f92ff
+SRC_URI[sha256sum] =
ef851a36aa41b4ad7a3e4c96ca27eaed2a629a6d2fa06c20f072118caed87ae8
S = ${WORKDIR}/qt-everywhere-opensource-src-${PV}
diff --git
a/meta/recipes-qt/qt4/qt-4.8.0/0001-Added-Openembedded-crossarch-option.patch
b/meta/recipes-qt/qt4/qt-4.8.1/0001-Added-Openembedded-crossarch-option.patch
similarity index 100%
rename from
meta/recipes-qt/qt4/qt-4.8.0/0001-Added-Openembedded-crossarch-option.patch
rename to
meta/recipes-qt/qt4/qt-4.8.1/0001-Added-Openembedded-crossarch-option.patch
diff --git a/meta/recipes-qt/qt4/qt-4.8.0/configure-lflags.patch
b/meta/recipes-qt/qt4/qt-4.8.1/configure-lflags.patch
similarity index 100%
rename from meta/recipes-qt/qt4/qt-4.8.0/configure-lflags.patch
rename to meta/recipes-qt/qt4/qt-4.8.1/configure-lflags.patch
diff --git a/meta/recipes-qt/qt4/qt-4.8.0/configure_oe_compiler.patch
b/meta/recipes-qt/qt4/qt-4.8.1/configure_oe_compiler.patch
similarity index 100%
rename from meta/recipes-qt/qt4/qt-4.8.0/configure_oe_compiler.patch
rename to meta/recipes-qt/qt4/qt-4.8.1/configure_oe_compiler.patch
diff --git a/meta/recipes-qt/qt4/qt-4.8.0/fix-translations.patch
b/meta/recipes-qt/qt4/qt-4.8.1/fix-translations.patch
similarity index 100%
rename from meta/recipes-qt/qt4/qt-4.8.0/fix-translations.patch
rename to meta/recipes-qt/qt4/qt-4.8.1/fix-translations.patch
diff --git a/meta/recipes-qt/qt4/qt-4.8.0/g++.conf
b/meta/recipes-qt/qt4/qt-4.8.1/g++.conf
similarity index 100%
rename from meta/recipes-qt/qt4/qt-4.8.0/g++.conf
rename to
Re: [OE-core] [PATCH 1/2] eglibc-2.15: Update SRCREV
On Wed, Mar 28, 2012 at 09:10:57AM -0700, Khem Raj wrote: On Wed, Mar 28, 2012 at 7:33 AM, Martin Jansa martin.ja...@gmail.com wrote: On Wed, Mar 28, 2012 at 07:15:32AM -0700, Khem Raj wrote: On Fri, Mar 23, 2012 at 7:26 PM, Martin Jansa martin.ja...@gmail.com wrote: On Fri, Mar 23, 2012 at 02:17:02PM +0100, Martin Jansa wrote: On Fri, Mar 23, 2012 at 12:05:25PM +, Richard Purdie wrote: On Thu, 2012-03-22 at 19:56 -0700, Khem Raj wrote: Get new patches and remove the one that got merged upstream Signed-off-by: Khem Raj raj.k...@gmail.com --- .../eglibc/eglibc-2.15/GLRO_dl_debug_mask.patch | 108 .../eglibc-2.15/armv4-eabi-compile-fix.patch | 25 - .../eglibc/eglibc-2.15/initgroups_keys.patch | 20 meta/recipes-core/eglibc/eglibc_2.15.bb | 5 +- 4 files changed, 131 insertions(+), 27 deletions(-) create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/GLRO_dl_debug_mask.patch delete mode 100644 meta/recipes-core/eglibc/eglibc-2.15/armv4-eabi-compile-fix.patch create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/initgroups_keys.patch Since 2.15 isn't the default I'm tempted to merge this despite the point we're at in the release cycle. I'd like to give anyone using this the opportunity to comment first though. I'm testing this on all archs I'm using (armv4t, armv5te, armv7a, x86-64) and will report tomorrow. Doesn't look related to this change, but I got interesing error on other buildhost (on mine everything seems fine sofar including tests on target), I don't have log from armv4t build on mine, because it's on tmpfs and there was unexpected reboot when I wasn't home :/. Hi Martin Does it look good for your testing ? Seems fine in runtime any hint about that build issue? Today I got another one :/ build-x86_64-oe-linux/shlib.lds:127: syntax error while building eglibc I had reports about this before, but wasn't able to reproduce it on my machine, today I got it for first time (maybe because of building with -j8 instead of -j4), so I've created simple testcase to compare interim outputs from shlib.lds creation: http://build.shr-project.org/tests/jama/shlib-issue/ yes I am aware of this problem. Somehow tokens in linker script gets eaten up which results in unbalanced parens. I havent tracked it down. I have seen this with eglibc 2.13 as well. Are you using gold by any chance. Not in that build I have seen it for first time (it was for qemux86-64 with distroless oe-core). Cheers, Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] self-hosted-image: pre-populate the builder user with poky source
On 03/28/2012 08:35 AM, Cui, Dexuan wrote:
Hi Saul,
Did you test bitbake core-image-minimal inside the vmware guest?
I got the following ERROR immediately:
This should be addressed by the 5/6 patch that adds the correct PSEUDO_*
setup into the minix session script.
I guess that you tried to run this on the command line and as you might
notice I modified the bashrc, but for some reason that did not get
picked up when the shell started up, I think we need to force the
builder user to get /bin/bash as a shell not /bin/sh
Sau!
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker
(see sanity.conf).
Following is the list of potential problems / advisories:
Pseudo is not functioning correctly, which will cause failures during
package installation. Please check your configuration.
ERROR: Execution of event handler 'check_sanity_eventhandler' failed
I suspect in the guest, pseudo is not setup properly?
Thanks,
-- Dexuan
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Tuesday, March 27, 2012 1:43 PM
To: openembedded-core@lists.openembedded.org
Cc: Cui, Dexuan
Subject: [PATCH 1/6] self-hosted-image: pre-populate the builder user with
poky source
From: Dexuan Cuidexuan@intel.com
This patch installs the poky source into the /home/builder/poky/ of the
self-hosted-image.
This makes the user of self-hosted-image easier to start a build.
I think the recent poky master is stable enough, so I specify a commit number
by SRCREV -- we may want to update this number before releasing 1.2.
This patch fixes [YOCTO #2065]
Signed-off-by: Dexuan Cuidexuan@intel.com
Added code for supporting target based pseudo fixed indentation
Signed-off-by: Saul Wolds...@linux.intel.com
---
meta/recipes-core/images/self-hosted-image.bb | 41
+++-
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb
index d56c2cb..5aa670d 100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de
20420
-PR = r5
+PR = r6
CORE_IMAGE_EXTRA_INSTALL = \
task-self-hosted \
@@ -13,7 +13,10 @@ CORE_IMAGE_EXTRA_INSTALL = \ IMAGE_FEATURES
+= x11-mini package-management
# Ensure there's enough space to do a core-image-minimal build, with
rm_work enabled -IMAGE_ROOTFS_EXTRA_SPACE = 2621440
+IMAGE_ROOTFS_EXTRA_SPACE = 1048576
+#IMAGE_ROOTFS_EXTRA_SPACE = 2621440
+#IMAGE_ROOTFS_EXTRA_SPACE = 20971520
+#IMAGE_ROOTFS_EXTRA_SPACE = 5242880
# Do a quiet boot with limited console messages APPEND += quiet
@@ -21,3 +24,37 @@ APPEND += quiet
IMAGE_FSTYPES = vmdk
inherit core-image
+
+SRCREV = 26a46938d3ea1821e7bec4fa6cc8379babad238b
+SRC_URI = git://git.yoctoproject.org/poky;protocol=git
+
+fakeroot do_populate_poky_src () {
+ # Because fetch2's git's unpack uses -s cloneflag, the unpacked git repo
+ # will become invalid in the target.
+ rm -rf ${WORKDIR}/git/.git
+ rm -f ${WORKDIR}/git/.gitignore
+
+ cp -Rp ${WORKDIR}/git ${IMAGE_ROOTFS}/home/builder/poky
+
+ mkdir -p ${IMAGE_ROOTFS}/home/builder/poky/build/conf
+ cp -Rp ${DL_DIR} ${IMAGE_ROOTFS}/home/builder/poky/build
+ echo /usr/bin
${IMAGE_ROOTFS}/home/builder/poky/build/pseudodone
+ echo BB_NO_NETWORK = \1\
${IMAGE_ROOTFS}/home/builder/poky/build/conf/auto.conf
+ echo INHERIT += \rm_work\
${IMAGE_ROOTFS}/home/builder/poky/build/conf/auto.conf
+mkdir -p ${IMAGE_ROOTFS}/home/builder/pseudo
+echo export PSEUDO_PREFIX=/usr
${IMAGE_ROOTFS}/home/builder/.bashrc
+echo export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
${IMAGE_ROOTFS}/home/builder/.bashrc
+echo export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
+${IMAGE_ROOTFS}/home/builder/.bashrc
+
+chown builder.builder ${IMAGE_ROOTFS}/home/builder/pseudo
+
+ chown -R builder.builder ${IMAGE_ROOTFS}/home/builder/poky }
+
+IMAGE_PREPROCESS_COMMAND += do_populate_poky_src;
+
+python do_get_poky_src () {
+bb.build.exec_func('base_do_fetch', d)
+bb.build.exec_func('base_do_unpack', d) } addtask do_get_poky_src
+before do_rootfs
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] self-hosted-image: pre-populate the builder user with poky source
On 03/28/2012 01:45 PM, Paul Eggleton wrote:
On Monday 26 March 2012 22:42:55 Saul Wold wrote:
From: Dexuan Cuidexuan@intel.com
This patch installs the poky source into the /home/builder/poky/ of the
self-hosted-image.
This makes the user of self-hosted-image easier to start a build.
I think the recent poky master is stable enough, so I specify
a commit number by SRCREV -- we may want to update this number before
releasing 1.2.
This patch fixes [YOCTO #2065]
Signed-off-by: Dexuan Cuidexuan@intel.com
Added code for supporting target based pseudo
fixed indentation
Signed-off-by: Saul Wolds...@linux.intel.com
---
meta/recipes-core/images/self-hosted-image.bb | 41
+++- 1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/images/self-hosted-image.bb
b/meta/recipes-core/images/self-hosted-image.bb index d56c2cb..5aa670d
100644
--- a/meta/recipes-core/images/self-hosted-image.bb
+++ b/meta/recipes-core/images/self-hosted-image.bb
@@ -4,7 +4,7 @@ LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
-PR = r5
+PR = r6
CORE_IMAGE_EXTRA_INSTALL = \
task-self-hosted \
@@ -13,7 +13,10 @@ CORE_IMAGE_EXTRA_INSTALL = \
IMAGE_FEATURES += x11-mini package-management
# Ensure there's enough space to do a core-image-minimal build, with
rm_work enabled -IMAGE_ROOTFS_EXTRA_SPACE = 2621440
+IMAGE_ROOTFS_EXTRA_SPACE = 1048576
+#IMAGE_ROOTFS_EXTRA_SPACE = 2621440
+#IMAGE_ROOTFS_EXTRA_SPACE = 20971520
+#IMAGE_ROOTFS_EXTRA_SPACE = 5242880
# Do a quiet boot with limited console messages
APPEND += quiet
@@ -21,3 +24,37 @@ APPEND += quiet
IMAGE_FSTYPES = vmdk
inherit core-image
+
+SRCREV = 26a46938d3ea1821e7bec4fa6cc8379babad238b
+SRC_URI = git://git.yoctoproject.org/poky;protocol=git
+
+fakeroot do_populate_poky_src () {
+ # Because fetch2's git's unpack uses -s cloneflag, the unpacked git repo
+ # will become invalid in the target.
+ rm -rf ${WORKDIR}/git/.git
+ rm -f ${WORKDIR}/git/.gitignore
+
+ cp -Rp ${WORKDIR}/git ${IMAGE_ROOTFS}/home/builder/poky
+
+ mkdir -p ${IMAGE_ROOTFS}/home/builder/poky/build/conf
+ cp -Rp ${DL_DIR} ${IMAGE_ROOTFS}/home/builder/poky/build
Could we change this last line to:
mkdir ${IMAGE_ROOTFS}/home/builder/poky/build/downloads
cp -RpL ${DL_DIR}/* ${IMAGE_ROOTFS}/home/builder/poky/build/downloads/
This does two things:
1) Handles if DL_DIR on the build machine is not called downloads (which by
chance mine was not when I tested it)
2) I notice if you set up a separate downloads directory and then use own-
mirrors to fetch from your original downloads directory (possibly unorthodox,
but it gets you a clean downloads directory without redownloading everything)
you get symlinks into the original downloads dir rather than copied files. I
don't know how many people will hit this but since we never want any symlinks
in this directory in the self-hosted image, I think using -L is worth doing
here.
That seems like a completely reasonable change and makes good sense,
your right I did assume DL_DIR would include downloads.
Sau!
Cheers,
Paul
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu.inc: Use '=' for IMAGE_FSTYPES
On Wed, 2012-03-28 at 14:54 -0400, Denys Dmytriyenko wrote: On Mon, Mar 26, 2012 at 05:56:16PM +0100, Richard Purdie wrote: On Mon, 2012-03-26 at 09:25 -0700, Tom Rini wrote: On Mon, Mar 26, 2012 at 10:15:13AM +0100, Richard Purdie wrote: On Fri, 2012-03-23 at 10:35 -0700, Tom Rini wrote: As per http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019772.html a machine conf file should use '=' to set IMAGE_FSTYPES. Signed-off-by: Tom Rini tr...@ti.com --- meta/conf/machine/include/qemu.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) As someone pointed out, what I mentioned in that email sadly doesn't work although it would be nice if they did. I suspect this is why we're using += since: We aren't using += today. We (openembedded-core) use ?=. meta-intel uses += and meta-ti is mixed (and I don't have meta-fsl-* handy). - The machine needs to say 'I need or support the following formats' so the machine ensures those formats exist at a minimum: IMAGE_FSTYPES += - The distro needs to say 'I always want format X' so the distro can do: IMAGE_FSTYPES += yyy - The user needs to say 'I know best, give me only format X' This one is the problem case so the user has to use overrides: IMAGE_FSTYPES_override = X (where override can be MACHINE or forcevariable) - The user needs to say 'I know best, give me what you support + X' IMAGE_FSTYPES += X Whilst I think that is less than ideal since it forces use of overrides in local.conf to override, changing the += in machine conf files doesn't gain us much, it just breaks += in local.conf. I'm open to other feedback though... Well, I suggested ??= / ?= and posted some results from bitbake -e... Ok. += plays out as above. I realise its not what is in qemu.inc, it is used in meta-intel though which I looked at after qemu.inc and I guess has confused me. With ?= in machine.conf: The user defined IMAGE_FSTYPES would override the machine ones. Distro can still append to it. The downside is a user append would not work out as expected. So the question is which is the more user expected behaviour? =+ makes overwriting IMAGE_FSTYPES hard ?= makes appending IMAGE_FSTYPES hard I suspect a user is more likely to want to append than overwrite. Getting an append to work with ?= is extremely non-obvious, even worse syntax than the =+ overwriting case with overrides. So bottom line, I'm tempted to recommend we use =+. Further thoughts? Richard, So, what is the subtle difference between += that we started with and =+ that you recommended at the end? I realize those are for append and prepend, but are they handled any different? Was your recommendation to use =+ at the end, instead of += that was used originally, based on some specifics? Thanks. I'm using += and =+ interchangeably. The contrast was with ?= which I argued against. Order in this case doesn't matter and I have no preference over += or =+, it simply doesn't matter. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu.inc: Use '=' for IMAGE_FSTYPES
On Wed, Mar 28, 2012 at 10:11:44PM +0100, Richard Purdie wrote: On Wed, 2012-03-28 at 14:54 -0400, Denys Dmytriyenko wrote: On Mon, Mar 26, 2012 at 05:56:16PM +0100, Richard Purdie wrote: On Mon, 2012-03-26 at 09:25 -0700, Tom Rini wrote: On Mon, Mar 26, 2012 at 10:15:13AM +0100, Richard Purdie wrote: On Fri, 2012-03-23 at 10:35 -0700, Tom Rini wrote: As per http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019772.html a machine conf file should use '=' to set IMAGE_FSTYPES. Signed-off-by: Tom Rini tr...@ti.com --- meta/conf/machine/include/qemu.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) As someone pointed out, what I mentioned in that email sadly doesn't work although it would be nice if they did. I suspect this is why we're using += since: We aren't using += today. We (openembedded-core) use ?=. meta-intel uses += and meta-ti is mixed (and I don't have meta-fsl-* handy). - The machine needs to say 'I need or support the following formats' so the machine ensures those formats exist at a minimum: IMAGE_FSTYPES += - The distro needs to say 'I always want format X' so the distro can do: IMAGE_FSTYPES += yyy - The user needs to say 'I know best, give me only format X' This one is the problem case so the user has to use overrides: IMAGE_FSTYPES_override = X (where override can be MACHINE or forcevariable) - The user needs to say 'I know best, give me what you support + X' IMAGE_FSTYPES += X Whilst I think that is less than ideal since it forces use of overrides in local.conf to override, changing the += in machine conf files doesn't gain us much, it just breaks += in local.conf. I'm open to other feedback though... Well, I suggested ??= / ?= and posted some results from bitbake -e... Ok. += plays out as above. I realise its not what is in qemu.inc, it is used in meta-intel though which I looked at after qemu.inc and I guess has confused me. With ?= in machine.conf: The user defined IMAGE_FSTYPES would override the machine ones. Distro can still append to it. The downside is a user append would not work out as expected. So the question is which is the more user expected behaviour? =+ makes overwriting IMAGE_FSTYPES hard ?= makes appending IMAGE_FSTYPES hard I suspect a user is more likely to want to append than overwrite. Getting an append to work with ?= is extremely non-obvious, even worse syntax than the =+ overwriting case with overrides. So bottom line, I'm tempted to recommend we use =+. Further thoughts? Richard, So, what is the subtle difference between += that we started with and =+ that you recommended at the end? I realize those are for append and prepend, but are they handled any different? Was your recommendation to use =+ at the end, instead of += that was used originally, based on some specifics? Thanks. I'm using += and =+ interchangeably. The contrast was with ?= which I argued against. Order in this case doesn't matter and I have no preference over += or =+, it simply doesn't matter. So I guess I'll spin everything one more time and drop the meta-intel version and we'll just use += since that's the common one. -- Tom ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bc: use update-alternatives to make dc play nice with busybox
On Wed, Mar 28, 2012 at 09:38:04AM +0100, Richard Purdie wrote:
On Wed, 2012-03-28 at 02:11 -0400, Denys Dmytriyenko wrote:
From: Denys Dmytriyenko de...@ti.com
busybox' default configuration enables dc app, which bc also provides,
setup update-alternatives to resolve the conflict.
Signed-off-by: Denys Dmytriyenko de...@ti.com
---
meta/recipes-extended/bc/bc_1.06.bb | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/bc/bc_1.06.bb
b/meta/recipes-extended/bc/bc_1.06.bb
index 02915e1..d8d8f4d 100644
--- a/meta/recipes-extended/bc/bc_1.06.bb
+++ b/meta/recipes-extended/bc/bc_1.06.bb
@@ -11,11 +11,20 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
SECTION = base
DEPENDS = flex
-PR = r0
+PR = r1
SRC_URI = ${GNU_MIRROR}/bc/bc-${PV}.tar.gz
SRC_URI[md5sum] = d44b5dddebd8a7a7309aea6c36fda117
SRC_URI[sha256sum] =
4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea72c0e33
-inherit autotools
+do_install_append () {
+ mv ${D}${bindir}/dc ${D}${bindir}/dc.${PN}
+}
+
+inherit autotools update-alternatives
+
+ALTERNATIVE_NAME = dc
+ALTERNATIVE_LINK = ${bindir}/dc
+ALTERNATIVE_PATH = ${bindir}/dc.${PN}
+ALTERNATIVE_PRIORITY = 100
I think you should just be able to do:
ALTERNATIVE_LINKS = ${bindir}/dc
ALTERNATIVE_PRIORITY = 100
inherit autotools update-alternatives
?
Yes, quite right. I see plenty of other recipes do it the hard way though...
--
Denys
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2] bc: use update-alternatives to make dc play nice with busybox
From: Denys Dmytriyenko de...@ti.com
busybox' default configuration enables dc app, which bc also provides,
setup update-alternatives to resolve the conflict.
Signed-off-by: Denys Dmytriyenko de...@ti.com
---
meta/recipes-extended/bc/bc_1.06.bb |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/bc/bc_1.06.bb
b/meta/recipes-extended/bc/bc_1.06.bb
index 02915e1..283e2d8 100644
--- a/meta/recipes-extended/bc/bc_1.06.bb
+++ b/meta/recipes-extended/bc/bc_1.06.bb
@@ -11,11 +11,14 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
SECTION = base
DEPENDS = flex
-PR = r0
+PR = r1
SRC_URI = ${GNU_MIRROR}/bc/bc-${PV}.tar.gz
SRC_URI[md5sum] = d44b5dddebd8a7a7309aea6c36fda117
SRC_URI[sha256sum] =
4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea72c0e33
-inherit autotools
+inherit autotools update-alternatives
+
+ALTERNATIVE_LINKS = ${bindir}/dc
+ALTERNATIVE_PRIORITY = 100
--
1.7.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips
On Wed, Mar 28, 2012 at 12:34:43PM +0100, Richard Purdie wrote: On Wed, 2012-03-28 at 12:58 +0200, Martin Jansa wrote: On Wed, Mar 28, 2012 at 06:10:26PM +0800, edwin.z...@intel.com wrote: From: Martin Jansa martin.ja...@gmail.com I don't think I've ever sent something like this. Actually I've sent patch: default-providers: switch virtual/libgl from mesa-xlib to mesa-dri * to match default virtual/xserver And this just reverts it + adds suspicious COMPATIBLE_MACHINE.. Cheers, Still need mesa-xlib for emulation of GLX interface on qemuarm/qemumips, where mesa-dri doesn't work for pure qemu emulator. I agree this COMPATIBLE_MACHINE is wrong. I just want to mesa-xlib only for qemumips/qemuppc/qemuarm. I'd suggest we need to change both xserver-org to xserver-xorg-lite and libgl to meta-xlib and then this might work better and address Martin's concerns too. You mean add xserver-xorg-lite as preferred virtual/xserver in meta/conf/machine/qemumips.conf? I'd like to understand why dri can't work under qemu too though. I think this requires: emulated graphic HW capability in qemumips/qemuarm, and an drm driver to match the emulated HW. With them, we can turn on enable-dri for mesa-dri and fight the build issue. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- best rgds, edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips
On Wed, Mar 28, 2012 at 12:58:37PM +0200, Martin Jansa wrote: On Wed, Mar 28, 2012 at 06:10:26PM +0800, edwin.z...@intel.com wrote: From: Martin Jansa martin.ja...@gmail.com I don't think I've ever sent something like this. Actually I've sent patch: default-providers: switch virtual/libgl from mesa-xlib to mesa-dri * to match default virtual/xserver Yes, this is just a revert to fix the GL failure. Sorry, I don't notice that git keep the original author when you revert:( Could you pls. explain why mesa-xlib doesn't match xserver-xorg? Thanks, Edwin And this just reverts it + adds suspicious COMPATIBLE_MACHINE.. Cheers, Still need mesa-xlib for emulation of GLX interface on qemuarm/qemumips, where mesa-dri doesn't work for pure qemu emulator. [YOCTO #2066] fixed. --- meta/conf/distro/include/default-providers.inc |2 +- meta/recipes-graphics/mesa/mesa-xlib.inc |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index 54c90d3..3850a2f 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -5,7 +5,7 @@ PREFERRED_PROVIDER_virtual/db ?= db PREFERRED_PROVIDER_virtual/db-native ?= db-native PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xorg -PREFERRED_PROVIDER_virtual/libgl ?= mesa-dri +PREFERRED_PROVIDER_virtual/libgl ?= mesa-xlib PREFERRED_PROVIDER_virtual/update-alternatives ?= update-alternatives-cworth PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim diff --git a/meta/recipes-graphics/mesa/mesa-xlib.inc b/meta/recipes-graphics/mesa/mesa-xlib.inc index b720e14..c431eab 100644 --- a/meta/recipes-graphics/mesa/mesa-xlib.inc +++ b/meta/recipes-graphics/mesa/mesa-xlib.inc @@ -1 +1,3 @@ EXTRA_OECONF += --with-driver=xlib --without-gallium-drivers + +COMPATIBLE_MACHINE = (qemuarm|qemumips|qemuppc) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- best rgds, edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] virtual/libgl: switch back to mesa-xlib for qemuarm/qemumips
On Thu, Mar 29, 2012 at 09:31:28AM +0800, Zhai, Edwin wrote: On Wed, Mar 28, 2012 at 12:58:37PM +0200, Martin Jansa wrote: On Wed, Mar 28, 2012 at 06:10:26PM +0800, edwin.z...@intel.com wrote: From: Martin Jansa martin.ja...@gmail.com I don't think I've ever sent something like this. Actually I've sent patch: default-providers: switch virtual/libgl from mesa-xlib to mesa-dri * to match default virtual/xserver Yes, this is just a revert to fix the GL failure. Sorry, I don't notice that git keep the original author when you revert:( FWIW: It doesn't keep the original author here, but maybe you have different git.. Could you pls. explain why mesa-xlib doesn't match xserver-xorg? see: http://patches.openembedded.org/patch/13631/ Thanks, Edwin And this just reverts it + adds suspicious COMPATIBLE_MACHINE.. Cheers, Still need mesa-xlib for emulation of GLX interface on qemuarm/qemumips, where mesa-dri doesn't work for pure qemu emulator. [YOCTO #2066] fixed. --- meta/conf/distro/include/default-providers.inc |2 +- meta/recipes-graphics/mesa/mesa-xlib.inc |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index 54c90d3..3850a2f 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -5,7 +5,7 @@ PREFERRED_PROVIDER_virtual/db ?= db PREFERRED_PROVIDER_virtual/db-native ?= db-native PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xorg -PREFERRED_PROVIDER_virtual/libgl ?= mesa-dri +PREFERRED_PROVIDER_virtual/libgl ?= mesa-xlib PREFERRED_PROVIDER_virtual/update-alternatives ?= update-alternatives-cworth PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim diff --git a/meta/recipes-graphics/mesa/mesa-xlib.inc b/meta/recipes-graphics/mesa/mesa-xlib.inc index b720e14..c431eab 100644 --- a/meta/recipes-graphics/mesa/mesa-xlib.inc +++ b/meta/recipes-graphics/mesa/mesa-xlib.inc @@ -1 +1,3 @@ EXTRA_OECONF += --with-driver=xlib --without-gallium-drivers + +COMPATIBLE_MACHINE = (qemuarm|qemumips|qemuppc) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- best rgds, edwin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson clar...@kergoth.com wrote: If you can explain why the override isn't overriding the default TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently modify all of the elements... I'm happy to accept the changes to all of the tunings. See above. It's not an override. And plenty of files already specify TUNE_PKGARCH_tune-tune, so I don't see how it'd be inconsistent to do so for the defaults, personally. If no one else has complained so far it makes me believe they are not missing any TUNE_PKGARCH_tune-tune then. -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson clar...@kergoth.com wrote: If you can explain why the override isn't overriding the default TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently modify all of the elements... I'm happy to accept the changes to all of the tunings. See above. It's not an override. And plenty of files already specify TUNE_PKGARCH_tune-tune, so I don't see how it'd be inconsistent to do so for the defaults, personally. If no one else has complained so far it makes me believe they are not missing any TUNE_PKGARCH_tune-tune then. I don't understand the point you're attempting to make here. -- Christopher Larson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf
On Wed, Mar 28, 2012 at 11:54 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 b29...@freescale.com wrote: On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson clar...@kergoth.com wrote: If you can explain why the override isn't overriding the default TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently modify all of the elements... I'm happy to accept the changes to all of the tunings. See above. It's not an override. And plenty of files already specify TUNE_PKGARCH_tune-tune, so I don't see how it'd be inconsistent to do so for the defaults, personally. If no one else has complained so far it makes me believe they are not missing any TUNE_PKGARCH_tune-tune then. I don't understand the point you're attempting to make here. Nevermind. Anyways, powerpc64 needs these too... -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
