* Re: missing mesa-dri dependency?
From: Koen Kooi @ 2011-10-15 14:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: Patches and discussions about the oe-core layer
In-Reply-To: <20111015130007.GB12684@jama.jama.net>
Op 15 okt. 2011 om 15:00 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
> On Sat, Oct 15, 2011 at 02:52:31PM +0200, Andreas Müller wrote:
>> On Thursday, October 13, 2011 10:24:19 AM Koen Kooi wrote:
>>> Hi,
>>>
>>> I remember fixing this in meta-oe, but now exactly how. IIRC both mesa-xlib and mesa-dri needed to get built.
>>>
>>> configure: error: Package requirements (glproto >= 1.4.14 dri >= 7.8.0) were not met:
>>> |
>>> | No package 'dri' found
>>> |
>>> | Consider adjusting the PKG_CONFIG_PATH environment variable if you
>>> | installed software in a non-standard prefix.
>>> |
>>> | Alternatively, you may set the environment variables DRI_CFLAGS
>>> | and DRI_LIBS to avoid the need to call pkg-config.
>>> | See the pkg-config man page for more details.
>>> | + bbfatal 'oe_runconf failed'
>>> | + echo 'ERROR: oe_runconf failed'
>>> | ERROR: oe_runconf failed
>>> | + exit 1
>>> | ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/xserver-xorg-1_1.11.1-r0/temp/log.do_configure.3602 for further information)
>>> NOTE: package xserver-xorg-1_1.11.1-r0: task do_configure: Failed
>>> ERROR: Task 1842 (/OE/tentacle/sources/openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.11.1.bb, do_configure) failed with exit code '1'
>>>
>>> regards,
>>>
>>> Koen
>> ping - or how do you workaround this for machines not supporting mesa-dri?
>
> use mesa-dri (with swrast) or mesa-xlib with xserver-xorg-lite
Switching to the -lite would troublesome from an upgrade path of view. As for TI chips I need to figure out how to enable using our new powervr dri module in this new setup.
regards,
koen
>>
>> Andreas
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Martin Jansa @ 2011-10-15 13:05 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111014081939.GC3542@jama.jama.net>
[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]
On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> On Thu, Oct 13, 2011 at 04:06:13PM -0700, nitin.a.kamble@intel.com wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
>
> This patch does not apply after
> 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
>
> can you rebase on top of oe-core?
>
> Also please drop
> DEFAULT_PREFERENCE = "-27"
>
> we have only one python version so I guess it's not usefull at all
> anymore
>
> I'll apply it manually, test it here.. and report if those modules are
> build later..
I've tried also to build it for qemux86-64 (my host is x86-64 too) and
it fails to build a bit sooner before building modules:
| x86_64-oe-linux-ar rc libpython2.7.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o
| x86_64-oe-linux-ar rc libpython2.7.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o
| x86_64-oe-linux-ranlib libpython2.7.a
| x86_64-oe-linux-gcc -m64 --sysroot=/OE/shr-core/tmp/sysroots/qemux86-64 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Xlinker -export-dynamic -o python \
| Modules/python.o \
| -L. -lpython2.7 -lpthread -ldl -lpthread -lutil -lm
| /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/python: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /OE/shr-core/tmp/work/x86_64-oe-linux/python-2.7.2-r0.0/Python-2.7.2/libpython2.7.so.1.0)
| make: *** [sharedmods] Error 1
| + die 'oe_runmake failed'
| + bbfatal 'oe_runmake failed'
| + echo 'ERROR: oe_runmake failed'
| ERROR: oe_runmake failed
| + exit 1
NOTE: package python-2.7.2-r0.0: task do_compile: Failed
ERROR: Task 230 (/OE/shr-core/openembedded-core/meta/recipes-devtools/python/python_2.7.2.bb, do_compile) failed with exit code '1'
ERROR: '/OE/shr-core/openembedded-core/meta/recipes-devtools/python/python_2.7.2.bb' failed
and
OE qemux86-64@shr ~/shr-core $ find /OE/shr-core/tmp/sysroots/qemux86-64 -name libc.so.6
/OE/shr-core/tmp/sysroots/qemux86-64/lib/libc.so.6
/OE/shr-core/tmp/sysroots/qemux86-64/usr/include/eglibc-locale-internal-x86_64-oe-linux/lib/libc.so.6
I have not special MULTILIB settings.. just used MACHINE=qemux86-64 as it is and build from scratch
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: missing mesa-dri dependency?
From: Martin Jansa @ 2011-10-15 13:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <201110151452.31950.schnitzeltony@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]
On Sat, Oct 15, 2011 at 02:52:31PM +0200, Andreas Müller wrote:
> On Thursday, October 13, 2011 10:24:19 AM Koen Kooi wrote:
> > Hi,
> >
> > I remember fixing this in meta-oe, but now exactly how. IIRC both mesa-xlib and mesa-dri needed to get built.
> >
> > configure: error: Package requirements (glproto >= 1.4.14 dri >= 7.8.0) were not met:
> > |
> > | No package 'dri' found
> > |
> > | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> > | installed software in a non-standard prefix.
> > |
> > | Alternatively, you may set the environment variables DRI_CFLAGS
> > | and DRI_LIBS to avoid the need to call pkg-config.
> > | See the pkg-config man page for more details.
> > | + bbfatal 'oe_runconf failed'
> > | + echo 'ERROR: oe_runconf failed'
> > | ERROR: oe_runconf failed
> > | + exit 1
> > | ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/xserver-xorg-1_1.11.1-r0/temp/log.do_configure.3602 for further information)
> > NOTE: package xserver-xorg-1_1.11.1-r0: task do_configure: Failed
> > ERROR: Task 1842 (/OE/tentacle/sources/openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.11.1.bb, do_configure) failed with exit code '1'
> >
> > regards,
> >
> > Koen
> ping - or how do you workaround this for machines not supporting mesa-dri?
use mesa-dri (with swrast) or mesa-xlib with xserver-xorg-lite
>
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: missing mesa-dri dependency?
From: Andreas Müller @ 2011-10-15 12:52 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <F17AC24E-C897-4BF3-990D-F9EE0A97E99E@dominion.thruhere.net>
On Thursday, October 13, 2011 10:24:19 AM Koen Kooi wrote:
> Hi,
>
> I remember fixing this in meta-oe, but now exactly how. IIRC both mesa-xlib and mesa-dri needed to get built.
>
> configure: error: Package requirements (glproto >= 1.4.14 dri >= 7.8.0) were not met:
> |
> | No package 'dri' found
> |
> | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> | installed software in a non-standard prefix.
> |
> | Alternatively, you may set the environment variables DRI_CFLAGS
> | and DRI_LIBS to avoid the need to call pkg-config.
> | See the pkg-config man page for more details.
> | + bbfatal 'oe_runconf failed'
> | + echo 'ERROR: oe_runconf failed'
> | ERROR: oe_runconf failed
> | + exit 1
> | ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/xserver-xorg-1_1.11.1-r0/temp/log.do_configure.3602 for further information)
> NOTE: package xserver-xorg-1_1.11.1-r0: task do_configure: Failed
> ERROR: Task 1842 (/OE/tentacle/sources/openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_1.11.1.bb, do_configure) failed with exit code '1'
>
> regards,
>
> Koen
ping - or how do you workaround this for machines not supporting mesa-dri?
Andreas
^ permalink raw reply
* Re: [PATCH 2/2] mesa-dri: move extra DRIMODULES to EXTRA_DRIMODULES
From: Martin Jansa @ 2011-10-15 10:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <363ECAF1-8602-4139-ADC9-2044FCB5456C@dominion.thruhere.net>
[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]
On Sat, Oct 15, 2011 at 12:29:52PM +0200, Koen Kooi wrote:
>
> Op 15 okt. 2011, om 12:24 heeft Martin Jansa het volgende geschreven:
>
> > * this way we can use
> > EXTRA_DRIMODULES_armv4t += ",glamo" in meta-openmoko layer and
> > EXTRA_DRIMODULES_armv4t += ",foo" in meta-bar layer without knowledge
> > of other modules in other layers in stack
>
> The above talks about 'MODULES', the actual patch about 'DRIVERS' :)
thanks for catching this.. I had it in meta-openmoko layer too :/
send new version simplified a bit more as nobody wants to disable swrast
and extra trailing ',' seems to be ignored fine
>
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> > meta/recipes-graphics/mesa/mesa-dri.inc | 6 ++++--
> > 1 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-graphics/mesa/mesa-dri.inc b/meta/recipes-graphics/mesa/mesa-dri.inc
> > index 795144a..4557bf8 100644
> > --- a/meta/recipes-graphics/mesa/mesa-dri.inc
> > +++ b/meta/recipes-graphics/mesa/mesa-dri.inc
> > @@ -4,9 +4,11 @@ LIB_DEPS += "libdrm expat"
> > # most of our targets do not have DRI so will use mesa-xlib
> > DEFAULT_PREFERENCE = "-1"
> >
> > +EXTRA_DRIDRIVERS = ""
> > +EXTRA_DRIDRIVERS_x86 = ",i915,i965"
> > +EXTRA_DRIDRIVERS_x86-64 = ",i915,i965"
> > DRIDRIVERS = "swrast"
> > -DRIDRIVERS_x86 = "swrast,i915,i965"
> > -DRIDRIVERS_x86-64 = "swrast,i915,i965"
> > +DRIDRIVERS += "${EXTRA_DRIDRIVERS}"
> >
> > EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium --without-gallium-drivers --with-dri-drivers=${DRIDRIVERS}"
> >
> > --
> > 1.7.7
> >
> >
> > _______________________________________________
> > 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.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [PATCH] mesa-dri: move extra DRIMODULES to EXTRA_DRIMODULES
From: Martin Jansa @ 2011-10-15 10:38 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <363ECAF1-8602-4139-ADC9-2044FCB5456C@dominion.thruhere.net>
* this way we can use
EXTRA_DRIDRIVERS_armv4t += ",glamo" in meta-openmoko layer and
EXTRA_DRIDRIVERS_armv4t += ",foo" in meta-bar layer without knowledge
of other modules in other layers in stack
* actually it's like old MACHINE_DRI_MODULES from OE-classic but renamed
to indicate that it should be used for architecture not machine
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-graphics/mesa/mesa-dri.inc | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa-dri.inc b/meta/recipes-graphics/mesa/mesa-dri.inc
index 795144a..ef0e8cf 100644
--- a/meta/recipes-graphics/mesa/mesa-dri.inc
+++ b/meta/recipes-graphics/mesa/mesa-dri.inc
@@ -4,11 +4,11 @@ LIB_DEPS += "libdrm expat"
# most of our targets do not have DRI so will use mesa-xlib
DEFAULT_PREFERENCE = "-1"
-DRIDRIVERS = "swrast"
-DRIDRIVERS_x86 = "swrast,i915,i965"
-DRIDRIVERS_x86-64 = "swrast,i915,i965"
+EXTRA_DRIDRIVERS = ""
+EXTRA_DRIDRIVERS_x86 = "i915,i965"
+EXTRA_DRIDRIVERS_x86-64 = "i915,i965"
-EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium --without-gallium-drivers --with-dri-drivers=${DRIDRIVERS}"
+EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium --without-gallium-drivers --with-dri-drivers=swrast,${EXTRA_DRIDRIVERS}"
python populate_packages_prepend() {
import os.path
--
1.7.7
^ permalink raw reply related
* Re: [PATCH 2/2] mesa-dri: move extra DRIMODULES to EXTRA_DRIMODULES
From: Koen Kooi @ 2011-10-15 10:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318674260-8320-2-git-send-email-Martin.Jansa@gmail.com>
Op 15 okt. 2011, om 12:24 heeft Martin Jansa het volgende geschreven:
> * this way we can use
> EXTRA_DRIMODULES_armv4t += ",glamo" in meta-openmoko layer and
> EXTRA_DRIMODULES_armv4t += ",foo" in meta-bar layer without knowledge
> of other modules in other layers in stack
The above talks about 'MODULES', the actual patch about 'DRIVERS' :)
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> meta/recipes-graphics/mesa/mesa-dri.inc | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa-dri.inc b/meta/recipes-graphics/mesa/mesa-dri.inc
> index 795144a..4557bf8 100644
> --- a/meta/recipes-graphics/mesa/mesa-dri.inc
> +++ b/meta/recipes-graphics/mesa/mesa-dri.inc
> @@ -4,9 +4,11 @@ LIB_DEPS += "libdrm expat"
> # most of our targets do not have DRI so will use mesa-xlib
> DEFAULT_PREFERENCE = "-1"
>
> +EXTRA_DRIDRIVERS = ""
> +EXTRA_DRIDRIVERS_x86 = ",i915,i965"
> +EXTRA_DRIDRIVERS_x86-64 = ",i915,i965"
> DRIDRIVERS = "swrast"
> -DRIDRIVERS_x86 = "swrast,i915,i965"
> -DRIDRIVERS_x86-64 = "swrast,i915,i965"
> +DRIDRIVERS += "${EXTRA_DRIDRIVERS}"
>
> EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium --without-gallium-drivers --with-dri-drivers=${DRIDRIVERS}"
>
> --
> 1.7.7
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH 2/2] mesa-common: install internal GL headers to libgl-dev
From: Koen Kooi @ 2011-10-15 10:28 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318672491-31826-2-git-send-email-Martin.Jansa@gmail.com>
Op 15 okt. 2011, om 11:54 heeft Martin Jansa het volgende geschreven:
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Acked-by: Koen Kooi <k-kooi@ti.com>
> ---
> meta/recipes-graphics/mesa/mesa-common.inc | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa-common.inc b/meta/recipes-graphics/mesa/mesa-common.inc
> index b8f2289..ca2d931 100644
> --- a/meta/recipes-graphics/mesa/mesa-common.inc
> +++ b/meta/recipes-graphics/mesa/mesa-common.inc
> @@ -51,3 +51,8 @@ FILES_libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/osmesa.h"
>
> FILES_${PN}-dbg += "${libdir}/dri/.debug/*"
> FILES_libegl-dbg += "${libdir}/egl/.debug/*"
> +
> +do_install_append () {
> + install -d ${D}/${includedir}/GL
> + cp -pPr ${S}/include/GL/internal* ${D}/${includedir}/GL
> +}
> --
> 1.7.7
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* [PATCH 2/2] mesa-dri: move extra DRIMODULES to EXTRA_DRIMODULES
From: Martin Jansa @ 2011-10-15 10:24 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1318674260-8320-1-git-send-email-Martin.Jansa@gmail.com>
* this way we can use
EXTRA_DRIMODULES_armv4t += ",glamo" in meta-openmoko layer and
EXTRA_DRIMODULES_armv4t += ",foo" in meta-bar layer without knowledge
of other modules in other layers in stack
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-graphics/mesa/mesa-dri.inc | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa-dri.inc b/meta/recipes-graphics/mesa/mesa-dri.inc
index 795144a..4557bf8 100644
--- a/meta/recipes-graphics/mesa/mesa-dri.inc
+++ b/meta/recipes-graphics/mesa/mesa-dri.inc
@@ -4,9 +4,11 @@ LIB_DEPS += "libdrm expat"
# most of our targets do not have DRI so will use mesa-xlib
DEFAULT_PREFERENCE = "-1"
+EXTRA_DRIDRIVERS = ""
+EXTRA_DRIDRIVERS_x86 = ",i915,i965"
+EXTRA_DRIDRIVERS_x86-64 = ",i915,i965"
DRIDRIVERS = "swrast"
-DRIDRIVERS_x86 = "swrast,i915,i965"
-DRIDRIVERS_x86-64 = "swrast,i915,i965"
+DRIDRIVERS += "${EXTRA_DRIDRIVERS}"
EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium --without-gallium-drivers --with-dri-drivers=${DRIDRIVERS}"
--
1.7.7
^ permalink raw reply related
* [PATCH 1/2] xserver-xorg: remove glx-use-tls again
From: Martin Jansa @ 2011-10-15 10:24 UTC (permalink / raw)
To: openembedded-core
* khem confirmed that uclibc does support it now
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-graphics/mesa/glx-use-tls.inc | 7 -------
.../recipes-graphics/xorg-xserver/xserver-xorg.inc | 3 +--
2 files changed, 1 insertions(+), 9 deletions(-)
delete mode 100644 meta/recipes-graphics/mesa/glx-use-tls.inc
diff --git a/meta/recipes-graphics/mesa/glx-use-tls.inc b/meta/recipes-graphics/mesa/glx-use-tls.inc
deleted file mode 100644
index 7530872..0000000
--- a/meta/recipes-graphics/mesa/glx-use-tls.inc
+++ /dev/null
@@ -1,7 +0,0 @@
-def get_tls_setting(bb, d):
- # until we have no prober TLS support in uclibc disable it
- if bb.data.getVar('TARGET_OS', d, 1).find('uclibc') >= 0 :
- return ""
- return "--enable-glx-tls"
-
-EXTRA_OECONF += "${@get_tls_setting(bb, d)}"
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
index 01cdd68..9246b06 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
@@ -3,11 +3,10 @@ require xserver-xorg-common.inc
PROTO_DEPS += "xf86driproto dri2proto"
LIB_DEPS += "virtual/libgl"
-require ../mesa/glx-use-tls.inc
-
EXTRA_OECONF += "\
--enable-dri \
--enable-dri2 \
+ --enable-glx-tls \
--with-pic \
--with-int10=x86emu \
"
--
1.7.7
^ permalink raw reply related
* [PATCH 2/2] mesa-common: install internal GL headers to libgl-dev
From: Martin Jansa @ 2011-10-15 9:54 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1318672491-31826-1-git-send-email-Martin.Jansa@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-graphics/mesa/mesa-common.inc | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa-common.inc b/meta/recipes-graphics/mesa/mesa-common.inc
index b8f2289..ca2d931 100644
--- a/meta/recipes-graphics/mesa/mesa-common.inc
+++ b/meta/recipes-graphics/mesa/mesa-common.inc
@@ -51,3 +51,8 @@ FILES_libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/osmesa.h"
FILES_${PN}-dbg += "${libdir}/dri/.debug/*"
FILES_libegl-dbg += "${libdir}/egl/.debug/*"
+
+do_install_append () {
+ install -d ${D}/${includedir}/GL
+ cp -pPr ${S}/include/GL/internal* ${D}/${includedir}/GL
+}
--
1.7.7
^ permalink raw reply related
* [PATCH 1/2] mesa: package gl/egl/osmesa to separate packages
From: Martin Jansa @ 2011-10-15 9:54 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-graphics/mesa/mesa-common.inc | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa-common.inc b/meta/recipes-graphics/mesa/mesa-common.inc
index 06ebb75..b8f2289 100644
--- a/meta/recipes-graphics/mesa/mesa-common.inc
+++ b/meta/recipes-graphics/mesa/mesa-common.inc
@@ -38,7 +38,16 @@ EXTRA_OECONF = "--enable-glu \
# Multiple virtual/gl providers being built breaks staging
EXCLUDE_FROM_WORLD = "1"
-PACKAGES =+ "libglu libglu-dev"
-
+PACKAGES =+ "libegl libegl-dev libegl-dbg libglu libglu-dev libosmesa libosmesa-dev libgl libgl-dev"
+FILES_libegl = "${libdir}/libEGL.so.* ${libdir}/egl/*.so"
+FILES_libgl = "${libdir}/libGL.so.*"
FILES_libglu = "${libdir}/libGLU.so.*"
+FILES_libosmesa = "${libdir}/libOSMesa.so.*"
+
+FILES_libegl-dev = "${libdir}/libEGL.* ${includedir}/EGL"
+FILES_libgl-dev = "${libdir}/libGL.* ${includedir}/GL"
FILES_libglu-dev = "${libdir}/libGLU.* ${includedir}/GL/glu*.h"
+FILES_libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/osmesa.h"
+
+FILES_${PN}-dbg += "${libdir}/dri/.debug/*"
+FILES_libegl-dbg += "${libdir}/egl/.debug/*"
--
1.7.7
^ permalink raw reply related
* Re: [oe-core 14/20] mesa-dri: introduce MACHINE_DRI_MODULES
From: Richard Purdie @ 2011-10-14 23:46 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKrN91FXYfxKXrLj-yJyS2ef+DqmA0n0xC0qwTuxSzApWw@mail.gmail.com>
On Fri, 2011-10-14 at 10:19 -0300, Otavio Salvador wrote:
> On Fri, Oct 14, 2011 at 08:29, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> ...
> >> At least here it hadn't built i915 or i965 drivers.
> >
> > I think there is a slight change in behaviour as the architectures it
> > would have built certain modules on used to get applied, now it doesn't
> > as we're passing a fixed list. We need to fix this but it shouldn't be
> > hard.
>
> I am sorry but I didn't get what you meant.
The old recipe just said "enable dri" and left it to the makefile to
decide what to build which it did based upon the target architecture.
I then changed the recipe to say i915 and i965 since the recipe was
marked x86 only. Now I've merged changes to default to swrast apart from
x86 (23 and 64 bit) where the intel modules are enabled. As and when any
other dependencies are fixed and people need other modules we'll enable
those on a per arch basis too.
This should hopefully resolve most of the issues people were seeing.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH] mesa-dri: Enable swrast only by default and intel drivers only on IA platform
From: Richard Purdie @ 2011-10-14 23:17 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1sqw2HbGXke_P8E2BwJJKUOs_YDkf2FFgSgC--CuQAnjXA@mail.gmail.com>
On Fri, 2011-10-14 at 15:53 -0700, Khem Raj wrote:
> On Fri, Oct 14, 2011 at 3:15 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Fri, 2011-10-14 at 18:05 +0200, Martin Jansa wrote:
> >> On Fri, Oct 14, 2011 at 04:55:50PM +0100, Richard Purdie wrote:
> >> > On Fri, 2011-10-14 at 17:30 +0200, Martin Jansa wrote:
> >> > > On Fri, Oct 14, 2011 at 04:25:16PM +0100, Richard Purdie wrote:
> >> > > > On Fri, 2011-10-14 at 11:46 -0300, Otavio Salvador wrote:
> >> > > > > +1
> >> > > > >
> >> > > > > Just another thing, I'd prefer to have DRIDRIVERS as ?= so machine can
> >> > > > > override it.
> >> > > >
> >> > > > I really wouldn't recommend overriding this on a per machine basis, it
> >> > > > needs to be on a per arch basis. This is because the recipe is not
> >> > > > machine specific (nor should it be).
> >> > > >
> >> > > > Configuration therefore falls to the distro, not machine.
> >> > >
> >> > > Why not make it machine specific only when machine provides own module
> >> > > (like the case with glamo on om-gta02)?
> >> > >
> >> > > Or recipe cannot change PACKAGE_ARCH in some special cases (like
> >> > > $MACHINE in path to some file in SRC_URI) anymore?
> >> >
> >> > It works just fine but its not nice practise in my opinion for a library
> >> > like this and I don't see there is any need in this case. Certainly I
> >> > don't see it as something OE-Core should be recommending.
> >>
> >> So can I send patches adding my glamo.patch to libdrm and mesa-dri so we
> >> can add glamo to
> >> DRIDRIVERS_armv4t ?
> >
> > No, what I mean is if the layer containing that machine appends those
> > patches for arm in general (or armv4t), you can then enable the dri
> > drivers for armv4t in general to.
>
> but there can be more than 1 armv4t machines in different layers.
Yes, I know. We established earlier that this will compile on other arm
machines. Obviously those machines would not include the module in their
rootfs, gta02 would. Building it shouldn't make much difference to them.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH] mesa-dri: Enable swrast only by default and intel drivers only on IA platform
From: Khem Raj @ 2011-10-14 22:53 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318630511.2342.52.camel@ted>
On Fri, Oct 14, 2011 at 3:15 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2011-10-14 at 18:05 +0200, Martin Jansa wrote:
>> On Fri, Oct 14, 2011 at 04:55:50PM +0100, Richard Purdie wrote:
>> > On Fri, 2011-10-14 at 17:30 +0200, Martin Jansa wrote:
>> > > On Fri, Oct 14, 2011 at 04:25:16PM +0100, Richard Purdie wrote:
>> > > > On Fri, 2011-10-14 at 11:46 -0300, Otavio Salvador wrote:
>> > > > > +1
>> > > > >
>> > > > > Just another thing, I'd prefer to have DRIDRIVERS as ?= so machine can
>> > > > > override it.
>> > > >
>> > > > I really wouldn't recommend overriding this on a per machine basis, it
>> > > > needs to be on a per arch basis. This is because the recipe is not
>> > > > machine specific (nor should it be).
>> > > >
>> > > > Configuration therefore falls to the distro, not machine.
>> > >
>> > > Why not make it machine specific only when machine provides own module
>> > > (like the case with glamo on om-gta02)?
>> > >
>> > > Or recipe cannot change PACKAGE_ARCH in some special cases (like
>> > > $MACHINE in path to some file in SRC_URI) anymore?
>> >
>> > It works just fine but its not nice practise in my opinion for a library
>> > like this and I don't see there is any need in this case. Certainly I
>> > don't see it as something OE-Core should be recommending.
>>
>> So can I send patches adding my glamo.patch to libdrm and mesa-dri so we
>> can add glamo to
>> DRIDRIVERS_armv4t ?
>
> No, what I mean is if the layer containing that machine appends those
> patches for arm in general (or armv4t), you can then enable the dri
> drivers for armv4t in general to.
but there can be more than 1 armv4t machines in different layers.
>
> It means you would have to keep the layer enabled whenever generating
> armv4t feeds but I think that is ok as long as you know about it?
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH] mesa-dri: Enable swrast only by default and intel drivers only on IA platform
From: Richard Purdie @ 2011-10-14 22:15 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111014160553.GM3542@jama.jama.net>
On Fri, 2011-10-14 at 18:05 +0200, Martin Jansa wrote:
> On Fri, Oct 14, 2011 at 04:55:50PM +0100, Richard Purdie wrote:
> > On Fri, 2011-10-14 at 17:30 +0200, Martin Jansa wrote:
> > > On Fri, Oct 14, 2011 at 04:25:16PM +0100, Richard Purdie wrote:
> > > > On Fri, 2011-10-14 at 11:46 -0300, Otavio Salvador wrote:
> > > > > +1
> > > > >
> > > > > Just another thing, I'd prefer to have DRIDRIVERS as ?= so machine can
> > > > > override it.
> > > >
> > > > I really wouldn't recommend overriding this on a per machine basis, it
> > > > needs to be on a per arch basis. This is because the recipe is not
> > > > machine specific (nor should it be).
> > > >
> > > > Configuration therefore falls to the distro, not machine.
> > >
> > > Why not make it machine specific only when machine provides own module
> > > (like the case with glamo on om-gta02)?
> > >
> > > Or recipe cannot change PACKAGE_ARCH in some special cases (like
> > > $MACHINE in path to some file in SRC_URI) anymore?
> >
> > It works just fine but its not nice practise in my opinion for a library
> > like this and I don't see there is any need in this case. Certainly I
> > don't see it as something OE-Core should be recommending.
>
> So can I send patches adding my glamo.patch to libdrm and mesa-dri so we
> can add glamo to
> DRIDRIVERS_armv4t ?
No, what I mean is if the layer containing that machine appends those
patches for arm in general (or armv4t), you can then enable the dri
drivers for armv4t in general to.
It means you would have to keep the layer enabled whenever generating
armv4t feeds but I think that is ok as long as you know about it?
Cheers,
Richard
^ permalink raw reply
* Re: [PATCHv2 26/30] glx-use-tls: add from meta-oe layer
From: Khem Raj @ 2011-10-14 20:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111014084032.GD3542@jama.jama.net>
On Fri, Oct 14, 2011 at 1:40 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> I'm not using uclibc at all, but if you're 100% sure, then I'll send
> patch removing glx-use-tls.inc after the rest of Xorg patchset is
> applied and mesa removed from meta-oe..
>
100%
> Regards,
>
^ permalink raw reply
* Re: [oe] git server move
From: Khem Raj @ 2011-10-14 18:23 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: Koen Kooi, openembedded-devel
In-Reply-To: <201110121648.29478.paul.eggleton@linux.intel.com>
On Wed, Oct 12, 2011 at 8:48 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
>
> I think you may find it's the "/cgit.cgi" part of the URL that's causing
> problems. It used to work, now it doesn't - if you remove it then you get a
> working interface.
>
> FWIW I'd be in favour of fixing it however; all of the links to cgit on my
> layer index page are now broken for example.
>
A bit of update on cgit.
The url redirect of openembedded-commit malining list links is not
working (thanks Tom Rini for his help)
/cgit.cgi is also rewritten to point to correct link so existing links
should work as usual. Please report any
issues you find with the cgit interface to the mailing list.
Thanks for you patience and support
-Khem
^ permalink raw reply
* Re: [PATCH] qt4: Added support for QtMobility 1.2
From: Saul Wold @ 2011-10-14 17:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <3C978CB0-754A-4835-9A02-DC29A5AC882B@dominion.thruhere.net>
On 10/14/2011 09:28 AM, Koen Kooi wrote:
>
> Op 14 okt. 2011, om 18:24 heeft Saul Wold het volgende geschreven:
>
>> On 10/14/2011 08:18 AM, Dmitry Cherukhin wrote:
>>> On Mon, 2011-09-26 at 16:32 -0700, Saul Wold wrote:
>>>> On 09/23/2011 07:13 AM, Dmitry Cherukhin wrote:
>>>>> This patch is indented to add new functionality,
>>>>> specifically, the patch adds support for
>>>>> the QtMobility 1.2 package.
>>>>>
>>>>> Added two recipes:
>>>>> 1) qt-mobility-x11 builds the QtMobility 1.2 package
>>>>> on the basis of qt4-x11-free;
>>>>> 2) qt-mobility-embedded builds the QtMobility 1.2 package
>>>>> on the basis of qt4-embedded.
>>>>>
>>>>> Signed-off-by: Dmitry Cherukhin<dima_ch@emcraft.com>
>>>>> ---
>>>>> meta/recipes-qt/qt4/files/qtm_qtmobility_pro.patch | 28 +++++++++++
>>>>> meta/recipes-qt/qt4/files/qtme_gstreamer_pro.patch | 16 ++++++
>>>>> meta/recipes-qt/qt4/qt-mobility-embedded_1.2.0.bb | 13 +++++
>>>>> meta/recipes-qt/qt4/qt-mobility-x11_1.2.0.bb | 11 ++++
>>>>> meta/recipes-qt/qt4/qt-mobility_1.2.0.inc | 51 ++++++++++++++++++++
>>>>> 5 files changed, 119 insertions(+), 0 deletions(-)
>>>>> create mode 100644 meta/recipes-qt/qt4/files/qtm_qtmobility_pro.patch
>>>>> create mode 100644 meta/recipes-qt/qt4/files/qtme_gstreamer_pro.patch
>>>>> create mode 100644 meta/recipes-qt/qt4/qt-mobility-embedded_1.2.0.bb
>>>>> create mode 100644 meta/recipes-qt/qt4/qt-mobility-x11_1.2.0.bb
>>>>> create mode 100644 meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
>>>>>
>>>>> diff --git a/meta/recipes-qt/qt4/files/qtm_qtmobility_pro.patch b/meta/recipes-qt/qt4/files/qtm_qtmobility_pro.patch
>>>>> new file mode 100644
>>>>> index 0000000..689c224
>>>>> --- /dev/null
>>>>> +++ b/meta/recipes-qt/qt4/files/qtm_qtmobility_pro.patch
>>>>> @@ -0,0 +1,28 @@
>>>>> +This patch fixes the following issue at the configure stage:
>>>>> + Project ERROR: Qt Mobility requires Qt 4.6 or higher. Qt was found.
>>>>> +The version of Qt is already 4.7.3, so this is misconfiguration problem.
>>>>> +
>>>>> +The origin of this patch is:
>>>>> + http://neophysis.git.sourceforge.net/git/gitweb.cgi?p=neophysis/openembedded;
>>>>> + a=blob;f=recipes/neophysis/qt-mobility-1.0.0/qtmobility_pro.patch;
>>>>> + h=fc5e1691aed47bc50d87e5c33497354182cacda4;hb=refs/heads/neophysis-testing-0.3
>>>>> +Upstream-Status: not-appropriate
>>>>
>>>> Please refer to wiki page on www.openembedded.org for the corrcet
>>>> formating of the Upstream-Status field. You are also missing a
>>>> Signed-off-by: line for each patch file.
>>>>
>>>> (I would give the exact page, but the site appears to be having problems)
>>>>
>>>
>>> Thanks!
>>> I removed all .patch files, new version of the patch is here:
>>> http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/8708
>>>
>> That's great, but that reader seems to mangle emails in a way that I can't use them for patching, it would be great if you could just send the v2 to this mailing list.
>
> The reader is just a view into the mail archive, so if you scroll back 8 days in your oe-core folder, you should see the patch :)
>
My bad, I was not seeing it because it had been tagged incorrectly in my
folder, found it now!
Sau!
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH] qt4: Added support for QtMobility 1.2
From: Otavio Salvador @ 2011-10-14 17:26 UTC (permalink / raw)
To: dima_ch, Patches and discussions about the oe-core layer
In-Reply-To: <1318605276.23340.578.camel@vladimir.emcraft.com>
On Fri, Oct 14, 2011 at 12:14, Dmitry Cherukhin <dima_ch@emcraft.com> wrote:
> On Thu, 2011-09-22 at 10:24 -0300, Otavio Salvador wrote:
>> On Thu, Sep 22, 2011 at 10:04, Dmitry Cherukhin <dima_ch@emcraft.com> wrote:
>> ...
>> > Upstream-Status: not-appropriate
>> ...
>>
>> This and an explanation of the reasoning of each patch ought to be
>> included into each .patch file that your commit is going to add.
>>
>
> I removed all .patch files, new version of the patch is here:
> http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/8708
From my side, this seems fine.
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply
* Re: [PATCH 0/1] qt4-x11-free: Fix broken regexes in qt4-x11-free's recipe.
From: Saul Wold @ 2011-10-14 16:58 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318472103.git.wenzong.fan@windriver.com>
On 10/12/2011 07:22 PM, wenzong.fan@windriver.com wrote:
> From: Wenzong Fan<wenzong.fan@windriver.com>
>
> This patch merged from Wind River Linux, it fix a potential '/' issue for
> qt4-x11-free.
>
> [yocto bug id: 1671]
>
> The following changes since commit b92b776d56e64a437181de9bc76f8dcc8e15a5f8:
> Richard Purdie (1):
> meta-yocto: Catch up with xserver and mesa upgrades/rename
>
> are available in the git repository at:
>
> git://git.pokylinux.org/poky-contrib wenzong/qt4_trailingslash
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/qt4_trailingslash
>
> Wenzong Fan (1):
> qt4-x11-free: Fix broken regexes in qt4-x11-free's recipe.
>
> meta/recipes-qt/qt4/qt4.inc | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
Merged into OE-Core
Thanks
Sau!
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* Re: [PATCH 0/1] linux-yocto: config cleanup and streamlining
From: Saul Wold @ 2011-10-14 16:41 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318452930.git.bruce.ashfield@windriver.com>
On 10/12/2011 01:58 PM, Bruce Ashfield wrote:
> Richard/Saul,
>
> This is a master only pull request (not that I need to
> tell you that) that contains some cleanups that Tom has been
> doing for various intel BSPs (although the changes will be
> useful elsewhere).
>
> I've also pushed these out to the dev kernel, in case anyone
> is interested.
>
> This incorporates the following meta branch commits:
>
> 353d43d fri2: cleanup bsp config
> 2a605e2 sugarbay: cleanup bsp config
> 47b76ed fishriver: cleanup bsp config
> ad6edab jasperforest: cleanup bsp config
> 07f7e89 emenlow: cleanup bsp config
> d32a651 crownbay: cleanup bsp config
> ad2d621 meta: add vesafb feature
> 913facf features/drm-psb: add related config options
>
> cc: Tom Zanussi<tom.zanussi@intel.com>
>
> Cheers,
>
> Bruce
>
> The following changes since commit 2cf9fb4df498fe0e4fa8356dc663fdfdec9a98cc:
>
> hal/hal-info: This is unsed in OE-Core and deprecated, drop (2011-10-12 14:12:10 +0100)
>
> are available in the git repository at:
> git://git.pokylinux.org/poky-contrib zedd/kernel
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
>
> Bruce Ashfield (1):
> linux-yocto: config cleanup and streamlining
>
> meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb | 2 +-
> meta/recipes-kernel/linux/linux-yocto_3.0.bb | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/1] QEMU 0.15 update please test
From: Khem Raj @ 2011-10-14 16:40 UTC (permalink / raw)
To: Saul Wold; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4E98641D.8040608@intel.com>
On Fri, Oct 14, 2011 at 9:32 AM, Saul Wold <saul.wold@intel.com> wrote:
> On 10/05/2011 12:45 PM, Khem Raj wrote:
>>
>> This brings in qemu-0.15 into OE-core I have had limited testing
>> on it and mainly on qemuarm. Please help testing it on other architectures
>> I will also work on getting it more solidified and bring some backports
>> as needed.
>>
>> The following changes since commit
>> abde9f65b1617ec61e964c4b3502fd4ad2215dcf:
>>
>> shared-mime-info: Upgrade recipes from 0.90 -> 0.91 (2011-10-05
>> 12:39:47 -0700)
>>
>> are available in the git repository at:
>> git://git.openembedded.org/openembedded-core-contrib kraj/qemu-update
>>
>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/qemu-update
>>
>> Khem Raj (1):
>> qemu-0.15: Add recipe and forward port patches from 0.14
>>
>> .../qemu/qemu-0.15.0/arm-bgr.patch | 30 +
>> .../qemu/qemu-0.15.0/enable-i386-linux-user.patch | 55 +
>> .../fallback-to-safe-mmap_min_addr.patch | 39 +
>> .../qemu/qemu-0.15.0/fix-configure-checks.patch | 22 +
>> .../qemu/qemu-0.15.0/fix-nogl.patch | 127 +
>> .../qemu/qemu-0.15.0/glflags.patch | 15 +
>> .../qemu/qemu-0.15.0/init-info.patch | 18 +
>> .../qemu/qemu-0.15.0/larger_default_ram_size.patch | 22 +
>> .../qemu/qemu-0.15.0/linker-flags.patch | 25 +
>> .../qemu/qemu-0.15.0/no-strip.patch | 15 +
>> .../qemu/qemu-0.15.0/opengl-sdl-fix.patch | 43 +
>> .../qemu/qemu-0.15.0/powerpc_rom.bin | Bin 0 -> 4096
>> bytes
>> .../qemu/qemu-0.15.0/qemu-git-qemugl-host.patch |34368
>> ++++++++++++++++++++
>> .../qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch | 118 +
>> .../qemugl-allow-glxcontext-release.patch | 65 +
>> .../qemu/qemu-0.15.0/qemugl-fix.patch | 74 +
>> meta/recipes-devtools/qemu/qemu_0.15.0.bb | 45 +
>> 17 files changed, 35081 insertions(+), 0 deletions(-)
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/arm-bgr.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/enable-i386-linux-user.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/fallback-to-safe-mmap_min_addr.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/fix-configure-checks.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/fix-nogl.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/glflags.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/init-info.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/larger_default_ram_size.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/linker-flags.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/no-strip.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/opengl-sdl-fix.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu-0.15.0/powerpc_rom.bin
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/qemu-git-qemugl-host.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/qemu-vmware-vga-depth.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-allow-glxcontext-release.patch
>> create mode 100644
>> meta/recipes-devtools/qemu/qemu-0.15.0/qemugl-fix.patch
>> create mode 100644 meta/recipes-devtools/qemu/qemu_0.15.0.bb
>>
>
> Merged into OE-Core
>
> I needed to add an additional patch to add glib-2.0-native to the
> qemu-native depends
yes that patch was already there on branch. I wonder why you did not get it.
>
> We will remove qemu-0.14 after we get through a QA cycle.
>
> Thanks
> Sau!
>
>
^ permalink raw reply
* Re: [PATCHv2] eglibc-2.14: add patch to fix libdl crash
From: Saul Wold @ 2011-10-14 16:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Cc: Martin Jansa, Klaus Kurzmann
In-Reply-To: <1318403001-30440-1-git-send-email-Martin.Jansa@gmail.com>
On 10/12/2011 12:03 AM, Martin Jansa wrote:
> From: Klaus Kurzmann<mok@fluxnetz.de>
>
> * Without this patch programs using alsa-lib crash (alsamixer for example).
> * This patch is taken verbatim from ArchLinux.
>
> Signed-off-by: Klaus Kurzmann<mok@fluxnetz.de>
> Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
> ---
> .../eglibc-2.14/glibc-2.14-libdl-crash.patch | 131 ++++++++++++++++++++
> meta/recipes-core/eglibc/eglibc_2.14.bb | 5 +-
> 2 files changed, 134 insertions(+), 2 deletions(-)
> create mode 100644 meta/recipes-core/eglibc/eglibc-2.14/glibc-2.14-libdl-crash.patch
>
> diff --git a/meta/recipes-core/eglibc/eglibc-2.14/glibc-2.14-libdl-crash.patch b/meta/recipes-core/eglibc/eglibc-2.14/glibc-2.14-libdl-crash.patch
> new file mode 100644
> index 0000000..e1f135c
> --- /dev/null
> +++ b/meta/recipes-core/eglibc/eglibc-2.14/glibc-2.14-libdl-crash.patch
> @@ -0,0 +1,131 @@
> +Without this patch programs using alsa-lib crash (alsamixer for example).
> +Removed Copyright reverts
> +
> +Upstream-Status: Pending
> +
> +http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=675155e9
> +http://sourceware.org/ml/libc-alpha/2011-06/msg00006.html
> +
> +many distributions are using this already
> +http://chakra-project.org/ccr/packages/glibc/glibc/PKGBUILD
> +http://mailman.archlinux.org/pipermail/arch-commits/2011-June/137142.html
> +http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/glibc/current/SOURCES/glibc-2.14-libdl-crash.patch?view=markup&pathrev=691343
> +http://repos.archlinuxppc.org/wsvn/filedetails.php?repname=packages&path=%2Fglibc%2Ftrunk%2Fglibc-2.14-libdl-crash.patch
> +
> +diff --git a/elf/dl-close.c b/elf/dl-close.c
> +index 73b2a2f..9bd91e3 100644
> +--- a/elf/dl-close.c
> ++++ b/elf/dl-close.c
> +@@ -119,17 +119,8 @@ _dl_close_worker (struct link_map *map)
> + if (map->l_direct_opencount> 0 || map->l_type != lt_loaded
> + || dl_close_state != not_pending)
> + {
> +- if (map->l_direct_opencount == 0)
> +- {
> +- if (map->l_type == lt_loaded)
> +- dl_close_state = rerun;
> +- else if (map->l_type == lt_library)
> +- {
> +- struct link_map **oldp = map->l_initfini;
> +- map->l_initfini = map->l_orig_initfini;
> +- _dl_scope_free (oldp);
> +- }
> +- }
> ++ if (map->l_direct_opencount == 0&& map->l_type == lt_loaded)
> ++ dl_close_state = rerun;
> +
> + /* There are still references to this object. Do nothing more. */
> + if (__builtin_expect (GLRO(dl_debug_mask)& DL_DEBUG_FILES, 0))
> +diff --git a/elf/dl-deps.c b/elf/dl-deps.c
> +index 9e30594..3890d00 100644
> +--- a/elf/dl-deps.c
> ++++ b/elf/dl-deps.c
> +@@ -478,6 +478,7 @@ _dl_map_object_deps (struct link_map *map,
> + nneeded * sizeof needed[0]);
> + atomic_write_barrier ();
> + l->l_initfini = l_initfini;
> ++ l->l_free_initfini = 1;
> + }
> +
> + /* If we have no auxiliary objects just go on to the next map. */
> +@@ -681,6 +682,7 @@ Filters not supported with LD_TRACE_PRELINKING"));
> + l_initfini[nlist] = NULL;
> + atomic_write_barrier ();
> + map->l_initfini = l_initfini;
> ++ map->l_free_initfini = 1;
> + if (l_reldeps != NULL)
> + {
> + atomic_write_barrier ();
> +@@ -689,5 +691,5 @@ Filters not supported with LD_TRACE_PRELINKING"));
> + _dl_scope_free (old_l_reldeps);
> + }
> + if (old_l_initfini != NULL)
> +- map->l_orig_initfini = old_l_initfini;
> ++ _dl_scope_free (old_l_initfini);
> + }
> +diff --git a/elf/dl-libc.c b/elf/dl-libc.c
> +index 7be9483..a13fce3 100644
> +--- a/elf/dl-libc.c
> ++++ b/elf/dl-libc.c
> +@@ -265,13 +265,13 @@ libc_freeres_fn (free_mem)
> +
> + for (Lmid_t ns = 0; ns< GL(dl_nns); ++ns)
> + {
> +- /* Remove all additional names added to the objects. */
> + for (l = GL(dl_ns)[ns]._ns_loaded; l != NULL; l = l->l_next)
> + {
> + struct libname_list *lnp = l->l_libname->next;
> +
> + l->l_libname->next = NULL;
> +
> ++ /* Remove all additional names added to the objects. */
> + while (lnp != NULL)
> + {
> + struct libname_list *old = lnp;
> +@@ -279,6 +279,10 @@ libc_freeres_fn (free_mem)
> + if (! old->dont_free)
> + free (old);
> + }
> ++
> ++ /* Free the initfini dependency list. */
> ++ if (l->l_free_initfini)
> ++ free (l->l_initfini);
> + }
> +
> + if (__builtin_expect (GL(dl_ns)[ns]._ns_global_scope_alloc, 0) != 0
> +diff --git a/elf/rtld.c b/elf/rtld.c
> +index 4a9109e..617e30e 100644
> +--- a/elf/rtld.c
> ++++ b/elf/rtld.c
> +@@ -2251,6 +2251,7 @@ ERROR: ld.so: object '%s' cannot be loaded as audit interface: %s; ignored.\n",
> + lnp->dont_free = 1;
> + lnp = lnp->next;
> + }
> ++ l->l_free_initfini = 0;
> +
> + if (l !=&GL(dl_rtld_map))
> + _dl_relocate_object (l, l->l_scope, GLRO(dl_lazy) ? RTLD_LAZY : 0,
> +diff --git a/include/link.h b/include/link.h
> +index e877104..051b99a 100644
> +--- a/include/link.h
> ++++ b/include/link.h
> +@@ -192,6 +192,9 @@ struct link_map
> + during LD_TRACE_PRELINKING=1
> + contains any DT_SYMBOLIC
> + libraries. */
> ++ unsigned int l_free_initfini:1; /* Nonzero if l_initfini can be
> ++ freed, ie. not allocated with
> ++ the dummy malloc in ld.so. */
> +
> + /* Collected information about own RPATH directories. */
> + struct r_search_path_struct l_rpath_dirs;
> +@@ -240,9 +243,6 @@ struct link_map
> +
> + /* List of object in order of the init and fini calls. */
> + struct link_map **l_initfini;
> +- /* The init and fini list generated at startup, saved when the
> +- object is also loaded dynamically. */
> +- struct link_map **l_orig_initfini;
> +
> + /* List of the dependencies introduced through symbol binding. */
> + struct link_map_reldeps
> diff --git a/meta/recipes-core/eglibc/eglibc_2.14.bb b/meta/recipes-core/eglibc/eglibc_2.14.bb
> index b2821db..571d39d 100644
> --- a/meta/recipes-core/eglibc/eglibc_2.14.bb
> +++ b/meta/recipes-core/eglibc/eglibc_2.14.bb
> @@ -3,7 +3,7 @@ require eglibc.inc
> SRCREV = "15225"
>
> DEPENDS += "gperf-native"
> -PR = "r0"
> +PR = "r1"
> PR_append = "+svnr${SRCPV}"
>
> EGLIBC_BRANCH="eglibc-2_14"
> @@ -19,7 +19,8 @@ SRC_URI = "svn://www.eglibc.org/svn/branches/;module=${EGLIBC_BRANCH};proto=http
> file://ppc-sqrt.patch \
> file://multilib_readlib.patch \
> file://eglibc-rpc-export-again.patch \
> - "
> + file://glibc-2.14-libdl-crash.patch \
> + "
> LIC_FILES_CHKSUM = "file://LICENSES;md5=98a1128c4b58120182cbea3b1752d8b9 \
> file://COPYING;md5=393a5ca445f6965873eca0259a17f833 \
> file://posix/rxspencer/COPYRIGHT;md5=dc5485bb394a13b2332ec1c785f5d83a \
Merged into OE-Core
Thanks
Sau!
^ permalink raw reply
* Re: [PATCH 0/2] Upgrade libfm/pcmanfm
From: Saul Wold @ 2011-10-14 16:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318385789.git.edwin.zhai@intel.com>
On 10/11/2011 07:20 PM, edwin.zhai@intel.com wrote:
> From: Zhai Edwin<edwin.zhai@intel.com>
>
> All,
> These 2 patches upgrade libfm and pcmanfm. Pls. help to review and pull.
>
> Thanks,
> Edwin
>
> The following changes since commit 0d8c8cf462e5df446669355b554b3d5fdc532a11:
>
> mutter: update to 2.29.1 and fix SRC_URI (2011-10-07 11:35:50 +0100)
>
> are available in the git repository at:
> git://git.pokylinux.org/poky-contrib gzhai/master2
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master2
>
> Zhai Edwin (2):
> libfm: Upgrade to 0.1.16
> pcmanfm: Upgrade to 0.9.9
>
> .../pcmanfm/files/owl-window-menu.patch | 53 ++++++++++----------
> .../pcmanfm/{pcmanfm_0.9.8.bb => pcmanfm_0.9.9.bb} | 6 +-
> .../libfm/libfm-0.1.14/use_deprecate_func.patch | 13 -----
> .../libfm/libfm-0.1.16/configure_fix.patch | 19 +++++++
> .../libfm/{libfm_0.1.14.bb => libfm_0.1.16.bb} | 8 ++--
> 5 files changed, 52 insertions(+), 47 deletions(-)
> rename meta/recipes-sato/pcmanfm/{pcmanfm_0.9.8.bb => pcmanfm_0.9.9.bb} (87%)
> delete mode 100644 meta/recipes-support/libfm/libfm-0.1.14/use_deprecate_func.patch
> create mode 100644 meta/recipes-support/libfm/libfm-0.1.16/configure_fix.patch
> rename meta/recipes-support/libfm/{libfm_0.1.14.bb => libfm_0.1.16.bb} (73%)
>
Merged into OE-Core
Thanks
Sau!
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox