* [PATCH] bitbake.conf: Use TRANSLATED_TARGET_ARCH in OVERRIDES since any variable with _ in it isuseless there (e.g. x86_64)
From: Richard Purdie @ 2011-10-14 14:40 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index a1420cf..0ae8059 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -666,7 +666,7 @@ AUTO_LIBNAME_PKGS = "${PACKAGES}"
#
# This works for functions as well, they are really just environment variables.
# Default OVERRIDES to make compilation fail fast in case of build system misconfiguration.
-OVERRIDES = "${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
+OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable"
DISTROOVERRIDES ?= "${DISTRO}"
MACHINEOVERRIDES ?= "${MACHINE}"
^ permalink raw reply related
* [PATCH 1/1] cmake : Disable building ccmake.
From: Philip Balister @ 2011-10-14 14:31 UTC (permalink / raw)
To: openembedded-core
ccmake fails to build due to an as-needed type error with -ltinfo. Disable
it for now since the build fails and cmake is what we need for target
sdk.
Signed-off-by: Philip Balister <philip@balister.org>
---
meta/recipes-devtools/cmake/cmake_2.8.5.bb | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-devtools/cmake/cmake_2.8.5.bb b/meta/recipes-devtools/cmake/cmake_2.8.5.bb
index 4fa9562..c0c5cad 100644
--- a/meta/recipes-devtools/cmake/cmake_2.8.5.bb
+++ b/meta/recipes-devtools/cmake/cmake_2.8.5.bb
@@ -30,6 +30,7 @@ EXTRA_OECMAKE=" \
-DCMAKE_DOC_DIR=${docdir_stripped}/cmake-${CMAKE_MAJOR_VERSION} \
-DCMAKE_USE_SYSTEM_LIBRARIES=1 \
-DKWSYS_CHAR_IS_SIGNED=1 \
+ -DBUILD_CursesDialog=0 \
${@base_contains('DISTRO_FEATURES', 'largefile', '-DKWSYS_LFS_WORKS=1', '-DKWSYS_LFS_DISABLE=1', d)} \
"
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 1/2] pulseaudio: make bluetooth support conditional upon DISTRO_FEATURES
From: Koen Kooi @ 2011-10-14 14:09 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <9adcdda8d76bf9201fd6275b3d140498c2ddd774.1318601142.git.paul.eggleton@linux.intel.com>
Op 14 okt. 2011, om 16:07 heeft Paul Eggleton het volgende geschreven:
> If "bluetooth" is in DISTRO_FEATURES then enable bluetooth and depend on
> bluez4, otherwise disable it.
>
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
> meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 +++--
> .../pulseaudio/pulseaudio_0.9.22.bb | 2 +-
> .../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
Slightly off-topic, PA has had a 1.0 release recently, any volunteers for adding it?
^ permalink raw reply
* [PATCH 2/2] bluez4: disable hidd, pand & dund
From: Paul Eggleton @ 2011-10-14 14:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318601142.git.paul.eggleton@linux.intel.com>
These daemons have been deprecated for some time, as their functionality
is now provided within the main bluetoothd daemon.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/recipes-connectivity/bluez/bluez4.inc | 6 +++---
meta/recipes-connectivity/bluez/bluez4_4.96.bb | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc b/meta/recipes-connectivity/bluez/bluez4.inc
index 5dacd92..fc515f6 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -27,9 +27,9 @@ EXTRA_OECONF = "\
--enable-bccmd \
--enable-hid2hci \
--enable-dfutool \
- --enable-hidd \
- --enable-pand \
- --enable-dund \
+ --disable-hidd \
+ --disable-pand \
+ --disable-dund \
--disable-cups \
--enable-test \
--enable-datafiles \
diff --git a/meta/recipes-connectivity/bluez/bluez4_4.96.bb b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
index 420a525..52268cf 100644
--- a/meta/recipes-connectivity/bluez/bluez4_4.96.bb
+++ b/meta/recipes-connectivity/bluez/bluez4_4.96.bb
@@ -1,6 +1,6 @@
require bluez4.inc
-PR = "r2"
+PR = "r3"
SRC_URI += "file://bluetooth.conf"
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] pulseaudio: make bluetooth support conditional upon DISTRO_FEATURES
From: Paul Eggleton @ 2011-10-14 14:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1318601142.git.paul.eggleton@linux.intel.com>
If "bluetooth" is in DISTRO_FEATURES then enable bluetooth and depend on
bluez4, otherwise disable it.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 +++--
.../pulseaudio/pulseaudio_0.9.22.bb | 2 +-
.../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 2a8e74d..bb32467 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -9,7 +9,8 @@ LIC_FILES_CHKSUM = "file://GPL;md5=4325afd396febcb659c36b49533135d4 \
file://src/pulsecore/vector.h;beginline=1;endline=21;md5=1b561f0a2ca47b1fa49862a6ccaacff1"
DEPENDS = "libatomics-ops liboil avahi libsamplerate0 libsndfile1 libtool virtual/libx11"
# optional
-DEPENDS += "bluez4 udev alsa-lib glib-2.0 dbus consolekit"
+DEPENDS += "udev alsa-lib glib-2.0 dbus consolekit \
+ ${@base_contains('DISTRO_FEATURES', 'bluetooth', 'bluez4', '', d)}"
SRC_URI = "http://0pointer.de/lennart/projects/pulseaudio/pulseaudio-${PV}.tar.gz \
file://gcc4-compile-fix.patch \
@@ -19,7 +20,7 @@ inherit autotools pkgconfig
EXTRA_OECONF = "\
--disable-lynx \
- --enable-bluez \
+ ${@base_contains('DISTRO_FEATURES', 'bluetooth', '--enable-bluez', '--disable-bluez', d)} \
--disable-polkit \
--with-x \
--without-jack \
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.22.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.22.bb
index da2e988..3067365 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.22.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.22.bb
@@ -1,6 +1,6 @@
require pulseaudio.inc
-PR = "r6"
+PR = "r7"
DEPENDS += "gdbm speex"
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
index 1edd913..33f5e15 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
@@ -1,6 +1,6 @@
require pulseaudio.inc
-PR = "r4"
+PR = "r5"
DEPENDS += "gdbm speex"
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] A couple of bluetooth improvements
From: Paul Eggleton @ 2011-10-14 14:07 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 362512b83775ad7020e5870a594f0e7ca9ef83ba:
bitbake.conf Exclude MACHINE from MACHINEOVERRIDE variable dependencies (2011-10-14 13:51:14 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/bluetooth
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/bluetooth
Paul Eggleton (2):
pulseaudio: make bluetooth support conditional upon DISTRO_FEATURES
bluez4: disable hidd, pand & dund
meta/recipes-connectivity/bluez/bluez4.inc | 6 +++---
meta/recipes-connectivity/bluez/bluez4_4.96.bb | 2 +-
meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 +++--
.../pulseaudio/pulseaudio_0.9.22.bb | 2 +-
.../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
5 files changed, 9 insertions(+), 8 deletions(-)
--
1.7.4.1
^ permalink raw reply
* Re: [oe-core 11/20] mesa: package gl/egl/osmesa to separate packages
From: Martin Jansa @ 2011-10-14 14:02 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318600723.2342.17.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]
On Fri, Oct 14, 2011 at 02:58:34PM +0100, Richard Purdie wrote:
> On Fri, 2011-10-14 at 15:32 +0200, Koen Kooi wrote:
> > Op 14 okt. 2011, om 13:19 heeft Martin Jansa het volgende geschreven:
> >
> > > On Fri, Oct 14, 2011 at 12:12:11PM +0100, Richard Purdie wrote:
> > >> On Thu, 2011-10-13 at 13:30 +0200, Martin Jansa wrote:
> > >>> * also install internal GL headers to libgl-dev
> > >>>
> > >>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > >>> ---
> > >>> meta/recipes-graphics/mesa/mesa-common.inc | 18 ++++++++++++++++--
> > >>> 1 files changed, 16 insertions(+), 2 deletions(-)
> > >>>
> > >>> diff --git a/meta/recipes-graphics/mesa/mesa-common.inc b/meta/recipes-graphics/mesa/mesa-common.inc
> > >>> index 89ef0cf..62d9b24 100644
> > >>> --- a/meta/recipes-graphics/mesa/mesa-common.inc
> > >>> +++ b/meta/recipes-graphics/mesa/mesa-common.inc
> > >>> @@ -40,7 +40,21 @@ require glx-use-tls.inc
> > >>> # 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/*"
> > >>> +
> > >>> +do_install_append () {
> > >>> + install -d ${D}/${includedir}/GL
> > >>> + cp -pPr ${S}/include/GL/internal* ${D}/${includedir}/GL
> > >>> +}
> > >>
> > >> This last do_install_append is wrong. Things should only be using
> > >> installed header files, not internal uninstalled ones. If the need
> > >> anything else there is a bug. I know the intel video driver had issues
> > >> in this area but those were fixed in the driver.
> > >
> > > checking from where we got this in meta-oe I've found really old commit
> > > http://git.openembedded.org/openembedded/commit/packages/mesa/mesa-common.inc?id=523eeb1062797a8562446fbefe9413a59540816b
> > > so you're right, I'll try to rebuild without this and drop this part
> > > from patchset.
> > >
> > >> What other issues are people seeing without this piece?
> > >
> > > Unless someone else knows about still broken driver :).
> >
> >
> > | glxdriswrast.c:39:39: fatal error: GL/internal/dri_interface.h: No such file or directory
> > | compilation terminated.
> > | glxdricommon.c:36:39: fatal error: GL/internal/dri_interface.h: No such file or directory
> > | compilation terminated.
> > | make[1]: *** [glxdricommon.lo] Error 1
> > | make[1]: *** Waiting for unfinished jobs....
> > | make[1]: *** [glxdriswrast.lo] Error 1
> > | make[1]: Leaving directory `/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/xserver-xorg-2_1.11.1-r1/xorg-server-1.11.1/glx'
> >
> > Xorg requires 'mesa-dri', which doesn't build anymore due to the COMPATIBLE_HOST :(
>
> This means the swrast dri backend should be installing that file...
>
> Hmm, so does the xserver now require the dri backend and the xlib one is
> now defunct?
I'm using mesa-xlib with xserver-xorg-lite and mesa-dri with
xserver-xorg, but in both cases with this do_install_append..
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [oe-core 11/20] mesa: package gl/egl/osmesa to separate packages
From: Richard Purdie @ 2011-10-14 13:58 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <31C6262B-E2E3-4C58-AFD9-BC8D2366C566@dominion.thruhere.net>
On Fri, 2011-10-14 at 15:32 +0200, Koen Kooi wrote:
> Op 14 okt. 2011, om 13:19 heeft Martin Jansa het volgende geschreven:
>
> > On Fri, Oct 14, 2011 at 12:12:11PM +0100, Richard Purdie wrote:
> >> On Thu, 2011-10-13 at 13:30 +0200, Martin Jansa wrote:
> >>> * also install internal GL headers to libgl-dev
> >>>
> >>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >>> ---
> >>> meta/recipes-graphics/mesa/mesa-common.inc | 18 ++++++++++++++++--
> >>> 1 files changed, 16 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-graphics/mesa/mesa-common.inc b/meta/recipes-graphics/mesa/mesa-common.inc
> >>> index 89ef0cf..62d9b24 100644
> >>> --- a/meta/recipes-graphics/mesa/mesa-common.inc
> >>> +++ b/meta/recipes-graphics/mesa/mesa-common.inc
> >>> @@ -40,7 +40,21 @@ require glx-use-tls.inc
> >>> # 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/*"
> >>> +
> >>> +do_install_append () {
> >>> + install -d ${D}/${includedir}/GL
> >>> + cp -pPr ${S}/include/GL/internal* ${D}/${includedir}/GL
> >>> +}
> >>
> >> This last do_install_append is wrong. Things should only be using
> >> installed header files, not internal uninstalled ones. If the need
> >> anything else there is a bug. I know the intel video driver had issues
> >> in this area but those were fixed in the driver.
> >
> > checking from where we got this in meta-oe I've found really old commit
> > http://git.openembedded.org/openembedded/commit/packages/mesa/mesa-common.inc?id=523eeb1062797a8562446fbefe9413a59540816b
> > so you're right, I'll try to rebuild without this and drop this part
> > from patchset.
> >
> >> What other issues are people seeing without this piece?
> >
> > Unless someone else knows about still broken driver :).
>
>
> | glxdriswrast.c:39:39: fatal error: GL/internal/dri_interface.h: No such file or directory
> | compilation terminated.
> | glxdricommon.c:36:39: fatal error: GL/internal/dri_interface.h: No such file or directory
> | compilation terminated.
> | make[1]: *** [glxdricommon.lo] Error 1
> | make[1]: *** Waiting for unfinished jobs....
> | make[1]: *** [glxdriswrast.lo] Error 1
> | make[1]: Leaving directory `/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/xserver-xorg-2_1.11.1-r1/xorg-server-1.11.1/glx'
>
> Xorg requires 'mesa-dri', which doesn't build anymore due to the COMPATIBLE_HOST :(
This means the swrast dri backend should be installing that file...
Hmm, so does the xserver now require the dri backend and the xlib one is
now defunct?
Cheers,
Richard
^ permalink raw reply
* Re: [oe-core 11/20] mesa: package gl/egl/osmesa to separate packages
From: Koen Kooi @ 2011-10-14 13:32 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111014111926.GF3542@jama.jama.net>
Op 14 okt. 2011, om 13:19 heeft Martin Jansa het volgende geschreven:
> On Fri, Oct 14, 2011 at 12:12:11PM +0100, Richard Purdie wrote:
>> On Thu, 2011-10-13 at 13:30 +0200, Martin Jansa wrote:
>>> * also install internal GL headers to libgl-dev
>>>
>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>> ---
>>> meta/recipes-graphics/mesa/mesa-common.inc | 18 ++++++++++++++++--
>>> 1 files changed, 16 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/recipes-graphics/mesa/mesa-common.inc b/meta/recipes-graphics/mesa/mesa-common.inc
>>> index 89ef0cf..62d9b24 100644
>>> --- a/meta/recipes-graphics/mesa/mesa-common.inc
>>> +++ b/meta/recipes-graphics/mesa/mesa-common.inc
>>> @@ -40,7 +40,21 @@ require glx-use-tls.inc
>>> # 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/*"
>>> +
>>> +do_install_append () {
>>> + install -d ${D}/${includedir}/GL
>>> + cp -pPr ${S}/include/GL/internal* ${D}/${includedir}/GL
>>> +}
>>
>> This last do_install_append is wrong. Things should only be using
>> installed header files, not internal uninstalled ones. If the need
>> anything else there is a bug. I know the intel video driver had issues
>> in this area but those were fixed in the driver.
>
> checking from where we got this in meta-oe I've found really old commit
> http://git.openembedded.org/openembedded/commit/packages/mesa/mesa-common.inc?id=523eeb1062797a8562446fbefe9413a59540816b
> so you're right, I'll try to rebuild without this and drop this part
> from patchset.
>
>> What other issues are people seeing without this piece?
>
> Unless someone else knows about still broken driver :).
| glxdriswrast.c:39:39: fatal error: GL/internal/dri_interface.h: No such file or directory
| compilation terminated.
| glxdricommon.c:36:39: fatal error: GL/internal/dri_interface.h: No such file or directory
| compilation terminated.
| make[1]: *** [glxdricommon.lo] Error 1
| make[1]: *** Waiting for unfinished jobs....
| make[1]: *** [glxdriswrast.lo] Error 1
| make[1]: Leaving directory `/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/xserver-xorg-2_1.11.1-r1/xorg-server-1.11.1/glx'
Xorg requires 'mesa-dri', which doesn't build anymore due to the COMPATIBLE_HOST :(
^ permalink raw reply
* Re: [oe-core 14/20] mesa-dri: introduce MACHINE_DRI_MODULES
From: Otavio Salvador @ 2011-10-14 13:19 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318591756.23801.259.camel@ted>
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.
--
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 2/2] data.py: fixed message domain errors
From: Richard Purdie @ 2011-10-14 12:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1315913433-32608-2-git-send-email-s.stirtzel@googlemail.com>
On Tue, 2011-09-13 at 13:30 +0200, Samuel Stirtzel wrote:
> The dynamic message domain was introduced by Richard Purdie with the following patch:
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a6c48298b17e6a5844b3638b422fe226e3b67b89
>
> Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
> ---
> meta/lib/oe/data.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Patches 1 and 2 merged to master, thanks.
Sorry about the delay.
Richard
^ permalink raw reply
* Re: [PATCH] Import python-setuptools from meta-oe (for glib-2.0)
From: Richard Purdie @ 2011-10-14 12:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4E95E543.803@gmail.com>
On Wed, 2011-10-12 at 12:06 -0700, Khem Raj wrote:
> On 10/12/2011 6:36 AM, Richard Purdie wrote:
> > +DEPENDS += "python"
> > +DEPENDS_virtclass-native += "python-native"
> > +
>
> wouldnt BBCLASSEXTEND convert python into python-native ?
Yes, it should. There must be something else odd going on here but that
can likley be removed...
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH] nfs-utils: separate nfs-utils-client and nfs-utils-stats
From: Richard Purdie @ 2011-10-14 12:37 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318506253-31111-1-git-send-email-Martin.Jansa@gmail.com>
On Thu, 2011-10-13 at 13:44 +0200, Martin Jansa wrote:
> * move python runtime dependency only to nfs-utils-stats
>
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> .../nfs-utils/nfs-utils_1.2.3.bb | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH 0/4] Qt4 and image building improvements
From: Richard Purdie @ 2011-10-14 12:32 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318516840.git.otavio@ossystems.com.br>
On Thu, 2011-10-13 at 14:41 +0000, Otavio Salvador wrote:
> The following changes since commit 5ad1ca59dea6d5045f252ed7b786ad193faced64:
>
> xf86-video-intel: Update 2.15.0 -> 2.16.0 (2011-10-12 22:59:14 +0100)
>
> are available in the git repository at:
> git://github.com/OSSystems/oe-core master
> https://github.com/OSSystems/oe-core/tree/HEAD
>
> Otavio Salvador (4):
> image-live.bbclass: allow override of initrd image
> initramfs-live-boot: make it more generic and easy to use
> qt4: use 4.7.4 as default preference
> distro_tracking_fields.inc: update qt4 related entries
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Kamble, Nitin A @ 2011-10-14 12:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111014091136.GE3542@jama.jama.net>
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Friday, October 14, 2011 2:12 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> from 2.6.6 to 2.7.2
>
> 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?
Ok, I will do the rebase and send new commits. I was getting into some unrelated issues with the top of the oecore, hence I was using the 1.1 edison branch to do this work.
> >
> > Also please drop
> > DEFAULT_PREFERENCE = "-27"
Done in my branch.
> >
> > 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..
>
> seems the same as with previous version..
>
> log.do_compile full of
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so: file
> not recognized: File format not recognized
> collect2: ld returned 1 exit status
I am not seeing this error.
>
> and only built module is sqlite
> OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0 $ ls
> Python-2.7.2/build/lib.linux-x86_64-2.7/
> _sqlite3.so
>
> while with 2.6 we had a lot of modules
> $ ls Python-2.6.6/build/lib.linux-x86_64-2.6/
> _bisect.so _codecs_jp.so _ctypes.so _fileio.so
> _json.so _random.so _testcapi.so bz2.so
> datetime.so itertools.so parser.so spwd.so
> unicodedata.so
> _bytesio.so _codecs_kr.so _ctypes_test.so _functools.so
> _locale.so _socket.so _weakref.so cPickle.so fcntl.so
> math.so pyexpat.so strop.so zlib.so
> _codecs_cn.so _codecs_tw.so _curses.so _hashlib.so
> _lsprof.so _sqlite3.so array.so cStringIO.so
> future_builtins.so mmap.so readline.so syslog.so
> _codecs_hk.so _collections.so _curses_panel.so _heapq.so
> _multibytecodec.so _ssl.so audioop.so cmath.so gdbm.so
> nis.so resource.so termios.so
> _codecs_iso2022.so _csv.so _elementtree.so _hotshot.so
> _multiprocessing.so _struct.so binascii.so crypt.so grp.so
> operator.so select.so time.so
I am seeing these .so modules built:
$ find image/ | grep "\.so"
image/usr/lib/python2.7/lib-dynload/_codecs_tw.so
image/usr/lib/python2.7/lib-dynload/mmap.so
image/usr/lib/python2.7/lib-dynload/resource.so
image/usr/lib/python2.7/lib-dynload/_random.so
image/usr/lib/python2.7/lib-dynload/termios.so
image/usr/lib/python2.7/lib-dynload/_codecs_jp.so
image/usr/lib/python2.7/lib-dynload/strop.so
image/usr/lib/python2.7/lib-dynload/_io.so
image/usr/lib/python2.7/lib-dynload/syslog.so
image/usr/lib/python2.7/lib-dynload/_codecs_hk.so
image/usr/lib/python2.7/lib-dynload/_testcapi.so
image/usr/lib/python2.7/lib-dynload/_collections.so
image/usr/lib/python2.7/lib-dynload/_socket.so
image/usr/lib/python2.7/lib-dynload/future_builtins.so
image/usr/lib/python2.7/lib-dynload/_csv.so
image/usr/lib/python2.7/lib-dynload/operator.so
image/usr/lib/python2.7/lib-dynload/parser.so
image/usr/lib/python2.7/lib-dynload/crypt.so
image/usr/lib/python2.7/lib-dynload/_elementtree.so
image/usr/lib/python2.7/lib-dynload/nis.so
image/usr/lib/python2.7/lib-dynload/_lsprof.so
image/usr/lib/python2.7/lib-dynload/_multiprocessing.so
image/usr/lib/python2.7/lib-dynload/_codecs_kr.so
image/usr/lib/python2.7/lib-dynload/cmath.so
image/usr/lib/python2.7/lib-dynload/_multibytecodec.so
image/usr/lib/python2.7/lib-dynload/array.so
image/usr/lib/python2.7/lib-dynload/bz2.so
image/usr/lib/python2.7/lib-dynload/_codecs_cn.so
image/usr/lib/python2.7/lib-dynload/_ssl.so
image/usr/lib/python2.7/lib-dynload/cStringIO.so
image/usr/lib/python2.7/lib-dynload/_json.so
image/usr/lib/python2.7/lib-dynload/_ctypes_test.so
image/usr/lib/python2.7/lib-dynload/_struct.so
image/usr/lib/python2.7/lib-dynload/itertools.so
image/usr/lib/python2.7/lib-dynload/zlib.so
image/usr/lib/python2.7/lib-dynload/spwd.so
image/usr/lib/python2.7/lib-dynload/_codecs_iso2022.so
image/usr/lib/python2.7/lib-dynload/audioop.so
image/usr/lib/python2.7/lib-dynload/math.so
image/usr/lib/python2.7/lib-dynload/ossaudiodev.so
image/usr/lib/python2.7/lib-dynload/_bisect.so
image/usr/lib/python2.7/lib-dynload/_hotshot.so
image/usr/lib/python2.7/lib-dynload/_curses.so
image/usr/lib/python2.7/lib-dynload/select.so
image/usr/lib/python2.7/lib-dynload/linuxaudiodev.so
image/usr/lib/python2.7/lib-dynload/time.so
image/usr/lib/python2.7/lib-dynload/pyexpat.so
image/usr/lib/python2.7/lib-dynload/cPickle.so
image/usr/lib/python2.7/lib-dynload/fcntl.so
image/usr/lib/python2.7/lib-dynload/binascii.so
image/usr/lib/python2.7/lib-dynload/_functools.so
image/usr/lib/python2.7/lib-dynload/_sqlite3.so
image/usr/lib/python2.7/lib-dynload/_heapq.so
image/usr/lib/python2.7/lib-dynload/datetime.so
image/usr/lib/python2.7/lib-dynload/readline.so
image/usr/lib/python2.7/lib-dynload/_curses_panel.so
image/usr/lib/python2.7/lib-dynload/gdbm.so
image/usr/lib/python2.7/lib-dynload/_locale.so
image/usr/lib/python2.7/lib-dynload/_hashlib.so
image/usr/lib/python2.7/lib-dynload/unicodedata.so
image/usr/lib/python2.7/lib-dynload/grp.so
image/usr/lib/python2.7/lib-dynload/_ctypes.so
image/usr/lib/libpython2.7.so.1.0
image/usr/lib/libpython2.7.so
>
> Can you please test that you have non-empty python-syslog python-
> resource python-elementtree python-fcntl python-zlib?
> And test build for qemuarm, because I guess that it links to -native
> libpython2.7 when you're building qemux86 on x86 host.
>
I tested for qemumips, and it worked like qemux86. I think qemuarm will not be different, I will give it a try.
Thanks,
Nitin
> But it seems that python runtime works now, thanks!
>
> Regards,
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
^ permalink raw reply
* Re: [RFC] Preventing race when compiling external kernel modules
From: Richard Purdie @ 2011-10-14 11:58 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <BF4FDC68-E435-4309-8B20-8415A7C990EE@dominion.thruhere.net>
On Fri, 2011-10-14 at 13:49 +0200, Koen Kooi wrote:
> Op 14 okt. 2011, om 13:42 heeft Richard Purdie het volgende geschreven:
>
> > On Fri, 2011-10-14 at 12:47 +0200, Anders Darander wrote:
> >> * Anders Darander <anders@chargestorm.se> [111014 09:55]:
> >>> In our local tree, I've circumvented this race by applying a patch like
> >>> [3]. (Well, we could likely have put the lock in do_make_scripts()
> >>> instead of module_do_compile(), as we have done currently). Obviously,
> >>> I'm not proposing to apply this patch, as it depends on lockfile from
> >>> the procmail-package (host-package).
> >>
> >> Just to confirm, it seems (after a very few tests) that it indeed is
> >> enough to guard the do_make_scripts() with the lock.
> >>
> >> However, the question on how to make the real solution remains...
> >
> > I've not tested this but it might give you enough info to test
> > something:
> >
> > (Basic idea is to promote that function to a task, then apply a lock to
> > it).
>
> Or taking a step back, deleting the scripts to save 0.002 kilobytes in
> sysroot was not a good idea. Shall we just stop deleting them and go
> back to the old way which actually worked?
It doesn't work, the scripts are compiled binaries and switching between
32 and 64 bit systems with sstate was a disaster. Either we need to
split the scripts off and mark them as "native" architecture or rebuild
them, we chose the latter for good reason.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 1/1] lsb: Change link of ${baselib} to lib64 for 64bits system
From: Richard Purdie @ 2011-10-14 11:56 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <8110c8b70b1778b7aa9b34a984c7073c800c1a96.1317030097.git.xiaofeng.yan@windriver.com>
On Sun, 2011-10-09 at 15:11 +0800, Xiaofeng Yan wrote:
> From: Xiaofeng Yan <xiaofeng.yan@windriver.com>
>
> Binaries of lsb test suite need ld-linux.so* in /lib64.
> for example:
> Target$ ./lsbcmdchk
> -sh: ./lsbcmdchk: No such file or directory
> Target$ strings lsbcmdchk | grep "ld-"
> /lib64/ld-lsb-x86-64.so.3
>
> "lsbcmdchk" from lsb test suite is a binary program.
> A new modification to lsb_1.4.bb caused that binaries from lsb test suite can't run
> because binaries of lsb test suite need ld-linux.so* in /lib64.
> But the link is changed due to adding multilib. I changed this link again.
>
> Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
> ---
> meta/recipes-extended/lsb/lsb_1.4.bb | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-extended/lsb/lsb_1.4.bb b/meta/recipes-extended/lsb/lsb_1.4.bb
> index d472012..5df08b8 100644
> --- a/meta/recipes-extended/lsb/lsb_1.4.bb
> +++ b/meta/recipes-extended/lsb/lsb_1.4.bb
> @@ -2,7 +2,7 @@ DESCRIPTION = "LSB support for Poky Linux"
> SECTION = "console/utils"
> HOMEPAGE = "http://prdownloads.sourceforge.net/lsb"
> LICENSE = "GPLv2+"
> -PR = "r1"
> +PR = "r2"
>
> LIC_FILES_CHKSUM = "file://README;md5=12da544b1a3a5a1795a21160b49471cf"
>
> @@ -69,7 +69,7 @@ do_install_append(){
> install -m 0755 ${WORKDIR}/init-functions ${D}/${baselib}/lsb
> if [ "${TARGET_ARCH}" == "x86_64" ];then
> cd ${D}
> - ln -sf ${baselib} lib
> + ln -sf ${baselib} lib64
> cd ${D}/${baselib}
> ln -sf ld-linux-x86-64.so.2 ld-lsb-x86-64.so.2
> ln -sf ld-linux-x86-64.so.2 ld-lsb-x86-64.so.3
> @@ -82,7 +82,7 @@ do_install_append(){
>
> if [ "${TARGET_ARCH}" == "powerpc64" ];then
> cd ${D}
> - ln -sf ${baselib} lib
> + ln -sf ${baselib} lib64
> cd ${D}/${baselib}
> ln -sf ld64.so.1 ld-lsb-ppc64.so.2
> ln -sf ld64.so.1 ld-lsb-ppc64.so.3
I'm afraid we need to add a bit more logic here. $baselib can be "lib",
"lib64" or anything else the user desires. I'd suggest we do something
like:
if [ "${baselib}" != "lib64" ]; then
ln -sf ${baselib} lib64
fi
Cheers,
Richard
^ permalink raw reply
* Re: [CONSOLIDATED PULL 00/28] Catching up & Upgrades
From: Richard Purdie @ 2011-10-14 11:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318570250.git.sgw@linux.intel.com>
On Thu, 2011-10-13 at 22:32 -0700, Saul Wold wrote:
> Richard,
>
> This is a batch of pull requests that have been pending for a bit
> and seem to be clean, I have also included some updates that have
> been built.
>
> Thanks
> Sau!
>
>
> The following changes since commit 4d5c0f9838a3e96d1cfb4ca2fb27161d6cf0de8f:
>
> xf86-video-intel_2.16.0: fix buildfix.patch to apply (2011-10-14 00:46:53 +0100)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib sgw/stage
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
>
> Bruce Ashfield (1):
> linux-yocto: config cleanup and streamlining
>
> Christopher Larson (2):
> autoconf: no need to hardcode the full path to m4
> autotools: fix multi-word arguments for EXTRA_OECONF
>
> Khem Raj (4):
> farsight2, ldconfig-native, gnutls: There is no GPLv2.1, correct the
> fields
> qemu-0.15: Add recipe and forward port patches from 0.14
> glib-2.0: Extend to provide nativesdk recipe
> qemu.inc: Add glib-2.0-nativesdk to qemu-nativesdk DEPENDS
>
> Klaus Kurzmann (1):
> eglibc-2.14: add patch to fix libdl crash
>
> Noor Ahsan (1):
> bluez4: Add ending quote of FILES_${PN}-dbg
>
> Otavio Salvador (2):
> image-live.bbclass: allow override of initrd image
> initramfs-live-boot: make it more generic and easy to use
>
> Saul Wold (11):
> shadow-native: Bump PR for patch update
> distro_tracking_fields: Updates
> v86d: update to 0.1.10
> libaio: Update to 0.3.109
> libtiff: Update to 3.9.5
> augeas: Update to 0.9.0
> libgcrypt: Update to 1.5.0
> rxvt-unicode: Update to 9.12
> rsync: Update to 3.0.9
> bash: update to 4.2
> qemu.inc: qemu-native also needs glib-2.0 native
>
> Tom Rini (1):
> libnl2: Fix a race on route/pktloc_syntax.h
>
> Wenzong Fan (1):
> qt4-x11-free: Fix broken regexes in qt4-x11-free's recipe.
>
> Xiaofeng Yan (2):
> lsb: Change link of ${baselib} to lib64 for 64bits system
> distro_tracking_fields.inc: Add maintainer for some packages without
> maintainer
>
> Zhai Edwin (2):
> libfm: Upgrade to 0.1.16
> pcmanfm: Upgrade to 0.9.9
Merged to master, thanks apart from the lsb change which I'll reply to.
Cheers,
Richard
^ permalink raw reply
* Re: [RFC] Preventing race when compiling external kernel modules
From: Koen Kooi @ 2011-10-14 11:49 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318592560.942.3.camel@ted>
Op 14 okt. 2011, om 13:42 heeft Richard Purdie het volgende geschreven:
> On Fri, 2011-10-14 at 12:47 +0200, Anders Darander wrote:
>> * Anders Darander <anders@chargestorm.se> [111014 09:55]:
>>> In our local tree, I've circumvented this race by applying a patch like
>>> [3]. (Well, we could likely have put the lock in do_make_scripts()
>>> instead of module_do_compile(), as we have done currently). Obviously,
>>> I'm not proposing to apply this patch, as it depends on lockfile from
>>> the procmail-package (host-package).
>>
>> Just to confirm, it seems (after a very few tests) that it indeed is
>> enough to guard the do_make_scripts() with the lock.
>>
>> However, the question on how to make the real solution remains...
>
> I've not tested this but it might give you enough info to test
> something:
>
> (Basic idea is to promote that function to a task, then apply a lock to
> it).
Or taking a step back, deleting the scripts to save 0.002 kilobytes in sysroot was not a good idea. Shall we just stop deleting them and go back to the old way which actually worked?
^ permalink raw reply
* Re: [RFC] Preventing race when compiling external kernel modules
From: Richard Purdie @ 2011-10-14 11:42 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111014104745.GD4437@ad.chargestorm.se>
On Fri, 2011-10-14 at 12:47 +0200, Anders Darander wrote:
> * Anders Darander <anders@chargestorm.se> [111014 09:55]:
> > In our local tree, I've circumvented this race by applying a patch like
> > [3]. (Well, we could likely have put the lock in do_make_scripts()
> > instead of module_do_compile(), as we have done currently). Obviously,
> > I'm not proposing to apply this patch, as it depends on lockfile from
> > the procmail-package (host-package).
>
> Just to confirm, it seems (after a very few tests) that it indeed is
> enough to guard the do_make_scripts() with the lock.
>
> However, the question on how to make the real solution remains...
I've not tested this but it might give you enough info to test
something:
(Basic idea is to promote that function to a task, then apply a lock to
it).
diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index 572df0d..5602e74 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -14,8 +14,10 @@ do_make_scripts() {
-C ${STAGING_KERNEL_DIR} scripts
}
+addtask make_scripts before compile
+do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
+
module_do_compile() {
- do_make_scripts
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR} \
KERNEL_SRC=${STAGING_KERNEL_DIR} \
Cheers,
Richard
^ permalink raw reply related
* Re: [oe-core 00/20] Xorg, mesa changes
From: Martin Jansa @ 2011-10-14 11:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318591599.23801.257.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]
On Fri, Oct 14, 2011 at 12:26:30PM +0100, Richard Purdie wrote:
> On Thu, 2011-10-13 at 13:30 +0200, Martin Jansa wrote:
> > Mostly cleanup in mesa directory.
> >
> > Most controversial is
> > mesa-dri: introduce MACHINE_DRI_MODULES
> > but maybe we can use it as distro variable and keep it with default arch.
> > But then we cannot just add ie glamo dri module from meta-openmoko like this:
> > http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=b50c8d00cf764c276b0792c0623b8eda3d18d343
> > without distro (setting MACHINE_DRI_MODULES) depending on such bsp layer.
> >
> > The following changes since commit 5ad1ca59dea6d5045f252ed7b786ad193faced64:
> >
> > xf86-video-intel: Update 2.15.0 -> 2.16.0 (2011-10-12 22:59:14 +0100)
> >
> > are available in the git repository at:
> > git://git.openembedded.org/openembedded-core-contrib jansa/x11-v4
> > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/x11-v4
> >
> > Martin Jansa (20):
> > xserver-xorg: drop xorg-minimal-fonts from RDEPENDS
> > xserver-xorg: move PE to xserver-xorg-common and bump it
> > xorg-driver-common: bump PE for upgrade path for meta-oe users
> > mesa-dri-glsl-native: fix LICENSE
> > mesa: move common patches which could be used in both mesa-dri and
> > mesa-xlib from mesa-dri to mesa
> > mesa-common: add common LIC_FILES_CHKSUM for newer mesa versions
> > mesa-common: MesaDemos is now separate recipes, bump PE, introduce
> > INC_PR
> > mesa-common: use glx-use-tls.inc instead of enabling glx-tls every
> > time
> > mesa-7.11: move shared DEPENDS, SRC_URI, checksums and
> > do_configure_prepend to shared .inc file
> > mesa: move shared PROTO_DEPS, LIB_DEPS and DEPENDS to common .inc
> > mesa: package gl/egl/osmesa to separate packages
> > mesa-xlib: move shared options to .inc
> > mesa-dri: move shared options to mesa-dri.inc
> > mesa-dri: introduce MACHINE_DRI_MODULES
> > mesa-dri: LEAD_SONAME shouldn't be needed now, when we're packaging
> > each lib in separate package
> > mesa-dri: drop COMPATIBLE_HOST, swrast should work for everybody
> > mesa-git: move shared parts from mesa-dri_git to mesa-git.inc and add
> > mesa-xlib_git
> > mesa-git: lower D_P a bit more then all mesa-dri
> > mesa-git: upgrade from 7.7+git to 7.11+git
> > mesa-git: fix LIC_FILES_CHKSUM
>
> I merged most of this. The pieces I didn't take:
>
> * MACHINE_DRI_MODULES piece
> * Drop COMPATIBLE_HOST (due to above)
> * glx-tls piece
> * FILES changes (due to do_install_append)
I've just pushed rebased jansa/x11-v4 with this last 4 patches
> This was *much* easier to review and I'm grateful for that, thanks!
good, you're welcome
> I think the actions are now:
>
> a) Resolve the MACHINE_DRI_MODULES discussion. Short term we can make
> the i915/965 pieces ia32 only and then remove the COMPATIBLE_MACHINES
OK
> b) Drop the glx/tls piece
I'll send patch dropping also the file and from xserver-xorg after mesa
is dropped in meta-oe so we don't introduce parsing issues
> c) Drop the do_install_append
resolved in 1/4 which is
mesa: package gl/egl/osmesa to separate packages
without do_install_append (that is moved to 3/4)
> and then we should have this all resolved :)
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: Some further build dependency timings
From: Richard Purdie @ 2011-10-14 11:34 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318430990.23801.176.camel@ted>
On Wed, 2011-10-12 at 15:49 +0100, Richard Purdie wrote:
> On Wed, 2011-10-12 at 09:40 -0500, Mark Hatle wrote:
> > It would be interesting to determine first off, if there is anywhere pseudo
> > should be running that it currently isn't. And second if this is simply due to
> > LD_PRELOAD time, or if enabling the jump table is the culprit.
> >
> > One potential optimization, when PSEUDO_DISABLE=1 is to only setup the jump
> > table entries for fork/exec items.
>
> Agreed, I don't know where the time is being spent exactly at this
> point. I do know we execute an absolute ton of exec/fork calls so
> removing any overhead from them will improve our speed though. This
> change means do_configure won't run with pseudo enabled for example
> which is a very exec heavy task.
So we did some tests, I thought I'd share the results:
base build config:
real 38m12.356s
user 236m4.710s
sys 39m38.180s
adding in the psuedo patches but not enabling (effectively jitter
measurement):
real 38m13.034s
user 235m44.250s
sys 39m6.150s
enabling the lazy linking:
real 38m16.121s
user 236m1.300s
sys 39m45.860s
Enable PSEUDO_UNLOAD:
real 35m46.281s
user 233m56.750s
sys 37m51.400s
So the big win isn't the linking, its the unloading of pseudo when we
don't need it...
Cheers,
Richard
^ permalink raw reply
* Re: [oe-core 14/20] mesa-dri: introduce MACHINE_DRI_MODULES
From: Richard Purdie @ 2011-10-14 11:29 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKp-CRpH0U7=k3inmg3gKqLFuHSUOA2JTc9+Jev+Op5p_Q@mail.gmail.com>
On Thu, 2011-10-13 at 11:32 -0300, Otavio Salvador wrote:
> On Thu, Oct 13, 2011 at 10:56, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> ...
> >> btw: in old recipes there was --with-dri-drivers with only one -, so maybe it
> >> wasn't actually working even for i915, i965 before or configure has benevolent syntax
> >
> > It defaults to enable all modules. We don't have libdrm-nouveau (or
> > llvm) so we had to change the config options to explicitly enable the
> > pieces I know are cared about on x86 in the latest version. This is why
> > the COMPATIBLE_HOST is there too since that recipe was always meaning to
> > compile these modules.
> ...
>
> 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.
Cheers,
Richard
^ permalink raw reply
* Re: [oe-core 00/20] Xorg, mesa changes
From: Richard Purdie @ 2011-10-14 11:26 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1318505196.git.Martin.Jansa@gmail.com>
On Thu, 2011-10-13 at 13:30 +0200, Martin Jansa wrote:
> Mostly cleanup in mesa directory.
>
> Most controversial is
> mesa-dri: introduce MACHINE_DRI_MODULES
> but maybe we can use it as distro variable and keep it with default arch.
> But then we cannot just add ie glamo dri module from meta-openmoko like this:
> http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=b50c8d00cf764c276b0792c0623b8eda3d18d343
> without distro (setting MACHINE_DRI_MODULES) depending on such bsp layer.
>
> The following changes since commit 5ad1ca59dea6d5045f252ed7b786ad193faced64:
>
> xf86-video-intel: Update 2.15.0 -> 2.16.0 (2011-10-12 22:59:14 +0100)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib jansa/x11-v4
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/x11-v4
>
> Martin Jansa (20):
> xserver-xorg: drop xorg-minimal-fonts from RDEPENDS
> xserver-xorg: move PE to xserver-xorg-common and bump it
> xorg-driver-common: bump PE for upgrade path for meta-oe users
> mesa-dri-glsl-native: fix LICENSE
> mesa: move common patches which could be used in both mesa-dri and
> mesa-xlib from mesa-dri to mesa
> mesa-common: add common LIC_FILES_CHKSUM for newer mesa versions
> mesa-common: MesaDemos is now separate recipes, bump PE, introduce
> INC_PR
> mesa-common: use glx-use-tls.inc instead of enabling glx-tls every
> time
> mesa-7.11: move shared DEPENDS, SRC_URI, checksums and
> do_configure_prepend to shared .inc file
> mesa: move shared PROTO_DEPS, LIB_DEPS and DEPENDS to common .inc
> mesa: package gl/egl/osmesa to separate packages
> mesa-xlib: move shared options to .inc
> mesa-dri: move shared options to mesa-dri.inc
> mesa-dri: introduce MACHINE_DRI_MODULES
> mesa-dri: LEAD_SONAME shouldn't be needed now, when we're packaging
> each lib in separate package
> mesa-dri: drop COMPATIBLE_HOST, swrast should work for everybody
> mesa-git: move shared parts from mesa-dri_git to mesa-git.inc and add
> mesa-xlib_git
> mesa-git: lower D_P a bit more then all mesa-dri
> mesa-git: upgrade from 7.7+git to 7.11+git
> mesa-git: fix LIC_FILES_CHKSUM
I merged most of this. The pieces I didn't take:
* MACHINE_DRI_MODULES piece
* Drop COMPATIBLE_HOST (due to above)
* glx-tls piece
* FILES changes (due to do_install_append)
This was *much* easier to review and I'm grateful for that, thanks!
I think the actions are now:
a) Resolve the MACHINE_DRI_MODULES discussion. Short term we can make
the i915/965 pieces ia32 only and then remove the COMPATIBLE_MACHINES
b) Drop the glx/tls piece
c) Drop the do_install_append
and then we should have this all resolved :)
Cheers,
Richard
^ permalink raw reply
* Re: [oe-core 11/20] mesa: package gl/egl/osmesa to separate packages
From: Martin Jansa @ 2011-10-14 11:19 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1318590739.23801.253.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]
On Fri, Oct 14, 2011 at 12:12:11PM +0100, Richard Purdie wrote:
> On Thu, 2011-10-13 at 13:30 +0200, Martin Jansa wrote:
> > * also install internal GL headers to libgl-dev
> >
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> > meta/recipes-graphics/mesa/mesa-common.inc | 18 ++++++++++++++++--
> > 1 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-graphics/mesa/mesa-common.inc b/meta/recipes-graphics/mesa/mesa-common.inc
> > index 89ef0cf..62d9b24 100644
> > --- a/meta/recipes-graphics/mesa/mesa-common.inc
> > +++ b/meta/recipes-graphics/mesa/mesa-common.inc
> > @@ -40,7 +40,21 @@ require glx-use-tls.inc
> > # 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/*"
> > +
> > +do_install_append () {
> > + install -d ${D}/${includedir}/GL
> > + cp -pPr ${S}/include/GL/internal* ${D}/${includedir}/GL
> > +}
>
> This last do_install_append is wrong. Things should only be using
> installed header files, not internal uninstalled ones. If the need
> anything else there is a bug. I know the intel video driver had issues
> in this area but those were fixed in the driver.
checking from where we got this in meta-oe I've found really old commit
http://git.openembedded.org/openembedded/commit/packages/mesa/mesa-common.inc?id=523eeb1062797a8562446fbefe9413a59540816b
so you're right, I'll try to rebuild without this and drop this part
from patchset.
> What other issues are people seeing without this piece?
Unless someone else knows about still broken driver :).
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ 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