[OE-core] [PATCHv2] eglibc-2.14: add patch to fix libdl crash
From: Klaus Kurzmann m...@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 m...@fluxnetz.de
Signed-off-by: Martin Jansa martin.ja...@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 000..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/msg6.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=markuppathrev=691343
+http://repos.archlinuxppc.org/wsvn/filedetails.php?repname=packagespath=%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
+
Re: [OE-core] [oe-core][PATCHv3 01/31] xserver-xf86(-dri)-lite: rename to xserver-xorg and xserver-xorg-lite
BTW, I sent out 2 patches (to p...@yoctoproject.org) for bug 1670:
http://bugzilla.pokylinux.org/show_bug.cgi?id=1670#c2
Thanks,
-- Dexuan
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Cui, Dexuan
Sent: Wednesday, October 12, 2011 11:49 AM
To: Patches and discussions about the oe-core layer
Cc: Martin Jansa
Subject: Re: [OE-core] [oe-core][PATCHv3 01/31] xserver-xf86(-dri)-lite:
rename
to xserver-xorg and xserver-xorg-lite
Glad to see the patches to upgrade xserver and libx11. Good work! :-)
BTW, we also need to upgrade meta-intel's side since BSP can't build now:
http://bugzilla.pokylinux.org/show_bug.cgi?id=1670
I'm working on this bug.
Thanks,
-- Dexuan
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
Of
Martin Jansa
Sent: Saturday, October 08, 2011 1:05 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [oe-core][PATCHv3 01/31] xserver-xf86(-dri)-lite: rename
to
xserver-xorg and xserver-xorg-lite
* xserver-xorg is closer to upstream naming and
that's how it's named in OE-classic and meta-oe? It would make meta-oe
transition easier and better to do it now then convert meta-oe to
xserver-xf86 and then rename it back later.
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/distro/include/default-providers.inc |4 ++--
.../conf/distro/include/distro_tracking_fields.inc | 20
++--
meta/conf/machine/qemux86-64.conf |6 +++---
meta/conf/machine/qemux86.conf |6 +++---
meta/conf/multilib.conf|2 +-
...ver-xf86-common.inc = xserver-xorg-common.inc} |1 +
...xserver-xf86-lite.inc = xserver-xorg-lite.inc} |4 +---
.../crosscompile.patch |0
.../fix_open_max_preprocessor_error.patch |0
.../macro_tweak.patch |2 +-
...-lite_1.10.1.bb = xserver-xorg-lite_1.10.1.bb} |2 +-
...{xserver-xf86-dri-lite.inc = xserver-xorg.inc} |2 +-
.../cache-xkbcomp-output-for-fast-start-up.patch |0
.../crosscompile.patch |0
.../fix_macros1.patch |0
.../fix_open_max_preprocessor_error.patch |0
.../macro_tweak.patch |2 +-
...6-dri-lite_1.10.1.bb = xserver-xorg_1.10.1.bb} |2 +-
...er-xf86-dri-lite_git.bb = xserver-xorg_git.bb} |2 +-
19 files changed, 27 insertions(+), 28 deletions(-)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-common.inc =
xserver-xorg-common.inc} (96%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite.inc =
xserver-xorg-lite.inc} (95%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg-lite}/crosscompile.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg-lite}/fix_open_max_preprocessor_error.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg-lite}/macro_tweak.patch (93%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite_1.10.1.bb
=
xserver-xorg-lite_1.10.1.bb} (89%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite.inc =
xserver-xorg.inc} (97%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/cache-xkbcomp-output-for-fast-start-up.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-lite =
xserver-xorg}/crosscompile.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/fix_macros1.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/fix_open_max_preprocessor_error.patch (100%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite =
xserver-xorg}/macro_tweak.patch (93%)
rename
meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite_1.10.1.bb =
xserver-xorg_1.10.1.bb} (93%)
rename meta/recipes-graphics/xorg-xserver/{xserver-xf86-dri-lite_git.bb =
xserver-xorg_git.bb} (94%)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index d51ac64..a5cdb5b 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -3,8 +3,8 @@
#
PREFERRED_PROVIDER_virtual/db ?= db
PREFERRED_PROVIDER_virtual/db-native ?= db-native
-PREFERRED_PROVIDER_virtual/xserver ?= xserver-xf86
-PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xf86-dri-lite
+PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg
+PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xorg
[OE-core] [oe-core 0/4] Qt4, armv6, xserver-xorg changes
The following changes since commit 486b17af3e4cced76e9852e7634f75ea87433db2: shared-mime-info: Fix a parallel make race (2011-10-11 18:06:56 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib jansa/pull http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/pull GNUtoo (1): conf: machine: includes: add armv6-novfp support Martin Jansa (1): xserver-xorg: drop xorg-minimal-fonts from RDEPENDS Simon Busch (2): qt4-embedded: remove dependency on tslib and use std. linux input qt4-x11-free: bring back pkg-config fixups meta/conf/machine/include/arm/arch-armv6.inc | 45 +--- meta/conf/machine/include/tune-arm1136j-s.inc | 10 .../xorg-xserver/xserver-xorg-1.11.1.inc |2 + .../xorg-xserver/xserver-xorg-common.inc |1 - meta/recipes-qt/qt4/files/qte.sh |2 +- meta/recipes-qt/qt4/qt4-embedded.inc |6 +- meta/recipes-qt/qt4/qt4-x11-free.inc | 16 +++- 7 files changed, 60 insertions(+), 22 deletions(-) create mode 100644 meta/conf/machine/include/tune-arm1136j-s.inc -- 1.7.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
From: Simon Busch morp...@gravedo.de
In most cases we don't need tslib in std. configuration as touchscreen access
in most
devices today is done with linux input interface. If some specific machine has
a need for
tslib support it should add the dependency in it's machine layer again and
modify the
profile script accordingly.
Signed-off-by: Simon Busch morp...@gravedo.de
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-qt/qt4/files/qte.sh |2 +-
meta/recipes-qt/qt4/qt4-embedded.inc |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-qt/qt4/files/qte.sh b/meta/recipes-qt/qt4/files/qte.sh
index 21d6ecb..bb8dfae 100644
--- a/meta/recipes-qt/qt4/files/qte.sh
+++ b/meta/recipes-qt/qt4/files/qte.sh
@@ -2,6 +2,6 @@
if [ -e /dev/input/touchscreen0 ]
then
-QWS_MOUSE_PROTO=Tslib:/dev/input/touchscreen0
+QWS_MOUSE_PROTO=LinuxInput:/dev/input/touchscreen0
export QWS_MOUSE_PROTO
fi
diff --git a/meta/recipes-qt/qt4/qt4-embedded.inc
b/meta/recipes-qt/qt4/qt4-embedded.inc
index bee7345..179de87 100644
--- a/meta/recipes-qt/qt4/qt4-embedded.inc
+++ b/meta/recipes-qt/qt4/qt4-embedded.inc
@@ -2,8 +2,8 @@ DESCRIPTION = Qt is a versatile cross-platform application
framework -- this is
SECTION = libs
LICENSE = LGPLv2.1 | GPLv3
HOMEPAGE = http://qt.nokia.com;
-DEPENDS += directfb tslib
-INC_PR = r36
+DEPENDS += directfb
+INC_PR = r37
QT_BASE_NAME ?= qt4-embedded
QT_BASE_LIB ?= libqt-embedded
@@ -15,7 +15,7 @@ QT_CONFIG_FLAGS += \
-embedded ${QT_ARCH} \
-qtlibinfix ${QT_LIBINFIX} \
-plugin-gfx-transformed -plugin-gfx-qvfb -plugin-gfx-vnc
-plugin-gfx-directfb \
--plugin-mouse-tslib -qt-mouse-pc -qt-mouse-qvfb -qt-mouse-linuxinput \
+-qt-mouse-pc -qt-mouse-qvfb -qt-mouse-linuxinput \
-qt-kbd-tty \
-DQT_KEYPAD_NAVIGATION \
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core 2/4] qt4-x11-free: bring back pkg-config fixups
From: Simon Busch morp...@gravedo.de
With b40b9c024be5e1ec81a31961158b3e6b529acfe0 some pkg-config fixups where
removed from
qt4.inc which breaks the pkg-config files for qt4-embedded. Without that the
pkg-config
files for qt4-x11-free are broken. So this patch puts the fixes into the
qt4-x11-free.inc
file to be used by qt4-x11-free and not qt4-embedded.
Signed-off-by: Simon Busch morp...@gravedo.de
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-qt/qt4/qt4-x11-free.inc | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-qt/qt4/qt4-x11-free.inc
b/meta/recipes-qt/qt4/qt4-x11-free.inc
index f391028..04b7885 100644
--- a/meta/recipes-qt/qt4/qt4-x11-free.inc
+++ b/meta/recipes-qt/qt4/qt4-x11-free.inc
@@ -5,7 +5,7 @@ HOMEPAGE = http://qt.nokia.com;
SECTION = x11/libs
DEPENDS += virtual/libgl virtual/libx11 fontconfig libxft libxext libxrender
libxrandr libxcursor
-INC_PR = r32
+INC_PR = r33
QT_GLFLAGS ?= ${@base_contains('DISTRO_FEATURES', 'opengl', '-opengl',
'-no-opengl', d)}
QT_GLFLAGS_qemux86 = -opengl
@@ -16,3 +16,17 @@ QT_BASE_LIB ?= libqt
inherit qt4x11
+do_install_append() {
+ # fix pkgconfig, libtool and prl files
+ sed -i -e 's#I/usr/include#Iincludedir}#g' \
+-e 's#Iin#I${in#g' \
+${D}${libdir}/*.la ${D}${libdir}/*.prl ${D}${libdir}/pkgconfig/*.pc
+
+ # QT abuses $includedir to point to its headers, which breaks pkgconfig
sysroot, so
+ # manually fix it up here:
+ for pc in ${D}${libdir}/pkgconfig/*.pc ; do
+sed -i -e s:prefix}include/${QT_BASE_NAME}/$(basename $pc
.pc):prefix}/include: \
+ -e s,Cflags: ,Cflags: -IP{includedir}/${QT_BASE_NAME}/$(basename $pc
.pc) , \
+ -e 's:IP{:I${:g' $pc
+ done
+}
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core 4/4] xserver-xorg: drop xorg-minimal-fonts from RDEPENDS
* as discussed here
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-October/010899.html
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../xorg-xserver/xserver-xorg-1.11.1.inc |2 ++
.../xorg-xserver/xserver-xorg-common.inc |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.1.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.1.inc
index 690de3f..2c5bb0a 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.1.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-1.11.1.inc
@@ -3,5 +3,7 @@ SRC_URI += file://crosscompile.patch
# Misc build failure for master HEAD
SRC_URI += file://fix_open_max_preprocessor_error.patch
+PR = r1
+
SRC_URI[md5sum] = 4cdf54dc569b6a5548257c93a45dcd3d
SRC_URI[sha256sum] =
c069c177d9a80bca2ee1d49aa1af6d9f996c83e4ff12393cab2ca3f8817276f6
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc
b/meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc
index 0cc3dc0..a8c7b0a 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg-common.inc
@@ -60,7 +60,6 @@ PACKAGES =+ ${PN}-security-policy \
${PN}-module-libxf1bpp \
${PN}-module-libxf4bpp
-RDEPENDS_${PN} += xorg-minimal-fonts
RRECOMMENDS_${PN} += ${PN}-security-policy xkeyboard-config rgb
xserver-xf86-config
RDEPENDS_${PN}-xvfb += xkeyboard-config
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core 3/4] conf: machine: includes: add armv6-novfp support
From: GNUtoo gnu...@no-log.org
Signed-off-by: Denis 'GNUtoo' Carikli gnu...@no-log.org
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/arm/arch-armv6.inc | 45 -
meta/conf/machine/include/tune-arm1136j-s.inc | 10 +
2 files changed, 39 insertions(+), 16 deletions(-)
create mode 100644 meta/conf/machine/include/tune-arm1136j-s.inc
diff --git a/meta/conf/machine/include/arm/arch-armv6.inc
b/meta/conf/machine/include/arm/arch-armv6.inc
index 9f2e9ac..3dd6566 100644
--- a/meta/conf/machine/include/arm/arch-armv6.inc
+++ b/meta/conf/machine/include/arm/arch-armv6.inc
@@ -9,24 +9,37 @@ TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES,
armv6, -march=armv6,
require conf/machine/include/arm/arch-armv5-dsp.inc
# Little Endian
-AVAILTUNES += armv6 armv6t armv6hf armv6thf
-TUNE_FEATURES_tune-armv6 ?= armv6 vfp
-TUNE_FEATURES_tune-armv6t ?= armv6 vfp thumb
-TUNE_FEATURES_tune-armv6hf ?= ${TUNE_FEATURES_tune-armv6} callconvention-hard
-TUNE_FEATURES_tune-armv6thf ?= ${TUNE_FEATURES_tune-armv6t}
callconvention-hard
-PACKAGE_EXTRA_ARCHS_tune-armv6 = ${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp}
armv6-vfp
-PACKAGE_EXTRA_ARCHS_tune-armv6t = ${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp}
armv6-vfp armv6t-vfp
-PACKAGE_EXTRA_ARCHS_tune-armv6hf = ${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp}
armv6hf-vfp
-PACKAGE_EXTRA_ARCHS_tune-armv6thf = ${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp}
armv6hf-vfp armv6thf-vfp
+AVAILTUNES += armv6 armv6t
+TUNE_FEATURES_tune-armv6 ?= armv6
+TUNE_FEATURES_tune-armv6t ?= armv6 thumb
+PACKAGE_EXTRA_ARCHS_tune-armv6 = ${PACKAGE_EXTRA_ARCHS_tune-armv5} armv6
+PACKAGE_EXTRA_ARCHS_tune-armv6t = ${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv6
armv6t
+
+# Little Endian + VFP
+AVAILTUNES += armv6-vfp armv6t-vfp armv6hf-vfp armv6thf-vfp
+TUNE_FEATURES_tune-armv6-vfp ?= armv6 vfp
+TUNE_FEATURES_tune-armv6t-vfp ?= armv6 vfp thumb
+TUNE_FEATURES_tune-armv6hf-vfp ?= ${TUNE_FEATURES_tune-armv6-vfp}
callconvention-hard
+TUNE_FEATURES_tune-armv6thf-vfp ?= ${TUNE_FEATURES_tune-armv6t-vfp}
callconvention-hard
+PACKAGE_EXTRA_ARCHS_tune-armv6-vfp = ${PACKAGE_EXTRA_ARCHS_tune-armv5-vfp}
armv6-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6t-vfp = ${PACKAGE_EXTRA_ARCHS_tune-armv5t-vfp}
armv6-vfp armv6t-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6hf-vfp =
${PACKAGE_EXTRA_ARCHS_tune-armv5hf-vfp} armv6hf-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6thf-vfp =
${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vfp} armv6hf-vfp armv6thf-vfp
# Big Endian
-AVAILTUNES += armv6b armv6tb armv6hfb armv6thfb
+AVAILTUNES += armv6b armv6tb
TUNE_FEATURES_tune-armv6b ?= ${TUNE_FEATURES_tune-armv6} bigendian
TUNE_FEATURES_tune-armv6tb ?= ${TUNE_FEATURES_tune-armv6t} bigendian
-TUNE_FEATURES_tune-armv6hfb ?= ${TUNE_FEATURES_tune-armv6b}
callconvention-hard
-TUNE_FEATURES_tune-armv6thfb ?= ${TUNE_FEATURES_tune-armv6tb}
callconvention-hard
-PACKAGE_EXTRA_ARCHS_tune-armv6b = ${PACKAGE_EXTRA_ARCHS_tune-armv5eb-vfp}
armv6b-vfp
-PACKAGE_EXTRA_ARCHS_tune-armv6tb = ${PACKAGE_EXTRA_ARCHS_tune-armv5teb-vfp}
armv6b-vfp armv6tb-vfp
-PACKAGE_EXTRA_ARCHS_tune-armv6hfb = ${PACKAGE_EXTRA_ARCHS_tune-armv5ehfb-vfp}
armv6hfb-vfp
-PACKAGE_EXTRA_ARCHS_tune-armv6thfb =
${PACKAGE_EXTRA_ARCHS_tune-armv5tehfb-vfp} armv6hfb-vfp armv6thfb-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6b = ${PACKAGE_EXTRA_ARCHS_tune-armv5} armv6b
+PACKAGE_EXTRA_ARCHS_tune-armv6tb = ${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv6b
armv6tb
+# Big Endian + VFP
+AVAILTUNES += armv6b-vfp armv6tb-vfp armv6hfb-vfp armv6thfb-vfp
+TUNE_FEATURES_tune-armv6b-vfp ?= ${TUNE_FEATURES_tune-armv6-vfp} bigendian
+TUNE_FEATURES_tune-armv6tb-vfp ?= ${TUNE_FEATURES_tune-armv6t-vfp} bigendian
+TUNE_FEATURES_tune-armv6hfb-vfp ?= ${TUNE_FEATURES_tune-armv6b-vfp}
callconvention-hard
+TUNE_FEATURES_tune-armv6thfb-vfp ?= ${TUNE_FEATURES_tune-armv6tb-vfp}
callconvention-hard
+PACKAGE_EXTRA_ARCHS_tune-armv6b-vfp = ${PACKAGE_EXTRA_ARCHS_tune-armv6b}
armv6b-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6tb-vfp = ${PACKAGE_EXTRA_ARCHS_tune-armv6t}
armv6b-vfp armv6tb-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6hfb-vfp = armv6hfb-vfp
+PACKAGE_EXTRA_ARCHS_tune-armv6thfb-vfp = armv6hfb-vfp armv6thfb-vfp
diff --git a/meta/conf/machine/include/tune-arm1136j-s.inc
b/meta/conf/machine/include/tune-arm1136j-s.inc
new file mode 100644
index 000..ce9ae7c
--- /dev/null
+++ b/meta/conf/machine/include/tune-arm1136j-s.inc
@@ -0,0 +1,10 @@
+DEFAULTTUNE ?= arm1136js
+
+require conf/machine/include/arm/arch-armv6.inc
+
+TUNEVALID[arm1136js] = Enable arm1136js specific processor optimizations
+TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, arm1136js,
-mtune=arm1136j-s, , d)}
+
+AVAILTUNES += arm1136js
+TUNE_FEATURES_tune-arm1136js = ${TUNE_FEATURES_tune-armv6t} arm1136js
+PACKAGE_EXTRA_ARCHS_tune-arm1136js = ${PACKAGE_EXTRA_ARCHS_tune-armv6t}
--
1.7.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
Hi, Le 12/10/2011 09:45, Martin Jansa a écrit : From: Simon Buschmorp...@gravedo.de In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly. When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ? Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] git server move
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFOlU0rMkyGM64RGpERArroAJ9EuHaOEcv64o9q9kJLZk50/OLoSQCgmKjd Yxh2H5CGKREmOq32gr36aes= =Xubc -END PGP SIGNATURE- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
Op 12 okt. 2011, om 10:02 heeft Eric Bénard het volgende geschreven: Hi, Le 12/10/2011 09:45, Martin Jansa a écrit : From: Simon Buschmorp...@gravedo.de In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly. When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ? We ran into this at work and like Eric, I'm curious how calibration (and e.g. dejitter) works in the linux-input world combined with qt/e. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 2/4] qt4-x11-free: bring back pkg-config fixups
On Wednesday 12 October 2011 08:45:03 Martin Jansa wrote: From: Simon Busch morp...@gravedo.de With b40b9c024be5e1ec81a31961158b3e6b529acfe0 some pkg-config fixups where removed from qt4.inc which breaks the pkg-config files for qt4-embedded. Without that the pkg-config files for qt4-x11-free are broken. So this patch puts the fixes into the qt4-x11-free.inc file to be used by qt4-x11-free and not qt4-embedded. So why do we need these only in the X11 version? Surely they should be applicable to both embedded and X11, or not at all...? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/1] QA check for defined packages
On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote: I'm looking for some comments on this WIP patch. The reason I've added this is because the hob GUI requires us to offer much more reliable metadata - we show the user available packages, as defined by each recipe, to add to their image. Should a recipe define a package and yet not actually create it and the user has included that in their image we cause errors at build time. However whilst the idea seems sound enough, there are some caveats - running a world build with this patch I see failures fairly early on at least a few of which I'd expect we'll need to special-case: * eglibc-local * linux-yocto * linux-libc-headers * gcc-runtime Thoughts? I think we probably do need to cleanup some of that data. I have some thoughts about where we're at with hob and this is probably as good a time as any to share them. Effectively the problem is that there is a large body of data we only compute during the build process. This includes what the exact runtime dependencies of packages are, which packages exactly are generated (PACKAGES_DYNAMIC), what the size of the packages are, how long they take to build and so on. Some things we can fix, some things we can hack around but at the end of the day there are some things we just plain can't change. I'm beginning to think we need to have two phases of control of the system: a) The build phase This is the step that generates the package feeds. b) The image construction phase This is the step that takes the package feed data and turns it into an image. Obviously, you can skip to b) if you already have a package feed. So we'd be talking about two UI's that could effectively hand off to each other and share a build in progress feedback to the user system. The image construction dialog would have a Missing Packages? Build them here type switch. This would mean the build system can continue on at what it does best yet the UI can let the users do what they want to do, particularly on a prebuilt package feed. Thoughts? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/1] QA check for defined packages
On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote: Folks, I'm looking for some comments on this WIP patch. The reason I've added this is because the hob GUI requires us to offer much more reliable metadata - we show the user available packages, as defined by each recipe, to add to their image. Should a recipe define a package and yet not actually create it and the user has included that in their image we cause errors at build time. However whilst the idea seems sound enough, there are some caveats - running a world build with this patch I see failures fairly early on at least a few of which I'd expect we'll need to special-case: * eglibc-local * linux-yocto * linux-libc-headers * gcc-runtime You'd probably get much better results from this patch if you account for ALLOW_EMPTY_pkgname btw... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/1] QA check for defined packages
Op 12 okt. 2011, om 14:37 heeft Richard Purdie het volgende geschreven: On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote: I'm looking for some comments on this WIP patch. The reason I've added this is because the hob GUI requires us to offer much more reliable metadata - we show the user available packages, as defined by each recipe, to add to their image. Should a recipe define a package and yet not actually create it and the user has included that in their image we cause errors at build time. However whilst the idea seems sound enough, there are some caveats - running a world build with this patch I see failures fairly early on at least a few of which I'd expect we'll need to special-case: * eglibc-local * linux-yocto * linux-libc-headers * gcc-runtime Thoughts? I think we probably do need to cleanup some of that data. I have some thoughts about where we're at with hob and this is probably as good a time as any to share them. Effectively the problem is that there is a large body of data we only compute during the build process. This includes what the exact runtime dependencies of packages are, which packages exactly are generated (PACKAGES_DYNAMIC), what the size of the packages are, how long they take to build and so on. Some things we can fix, some things we can hack around but at the end of the day there are some things we just plain can't change. I'm beginning to think we need to have two phases of control of the system: a) The build phase This is the step that generates the package feeds. b) The image construction phase This is the step that takes the package feed data and turns it into an image. Obviously, you can skip to b) if you already have a package feed. So we'd be talking about two UI's that could effectively hand off to each other and share a build in progress feedback to the user system. The image construction dialog would have a Missing Packages? Build them here type switch. This would mean the build system can continue on at what it does best yet the UI can let the users do what they want to do, particularly on a prebuilt package feed. Thoughts? I really, really, REALLY like the attention packages feeds are getting lately on the oe-core and yocto mailinglists! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] flac: Add missing gettext dependency (requires iconv)
diff --git a/meta/recipes-multimedia/flac/flac_1.2.1.bb
b/meta/recipes-multimedia/flac/flac_1.2.1.bb
index 652d69a..5a9c66f 100644
--- a/meta/recipes-multimedia/flac/flac_1.2.1.bb
+++ b/meta/recipes-multimedia/flac/flac_1.2.1.bb
@@ -27,7 +27,7 @@ SRC_URI[sha256sum] =
9635a44bceb478bbf2ee8a785cf6986fba525afb5fad1fd4bba73cf71f
S = ${WORKDIR}/flac-${PV}
-inherit autotools
+inherit autotools gettext
EXTRA_OECONF = --disable-oggtest --disable-id3libtest \
--with-ogg-libraries=${STAGING_LIBDIR} \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Import python-setuptools from meta-oe (for glib-2.0)
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-devtools/python/python-setuptools_0.6c11.bb
b/meta/recipes-devtools/python/python-setuptools_0.6c11.bb
new file mode 100644
index 000..ca7335e
--- a/dev/null
+++ b/meta/recipes-devtools/python/python-setuptools_0.6c11.bb
@@ -0,0 +1,31 @@
+DESCRIPTION = Download, build, install, upgrade, and uninstall Python
packages
+HOMEPAGE = http://cheeseshop.python.org/pypi/setuptools;
+SECTION = devel/python
+LICENSE = PSF
+LIC_FILES_CHKSUM =
file://setup.py;beginline=23;endline=23;md5=8a314270dd7a8dbca741775415f1716e
+
+SRCNAME = setuptools
+PR = ml2
+DEPENDS += python
+DEPENDS_virtclass-native += python-native
+
+SRC_URI = \
+
http://cheeseshop.python.org/packages/source/s/setuptools/${SRCNAME}-${PV}.tar.gz\
+
+S = ${WORKDIR}/${SRCNAME}-${PV}
+
+inherit distutils
+
+do_install_prepend() {
+install -d ${D}/${libdir}/${PYTHON_DIR}/site-packages
+}
+
+RDEPENDS_${PN} = \
+ python-distutils \
+ python-compression \
+
+
+SRC_URI[md5sum] = 7df2a529a074f613b509fb44feefe74e
+SRC_URI[sha256sum] =
630fea9b726320b73ee3ca6ff61732cb32675b0389be658080fe46383b87a1d3
+
+BBCLASSEXTEND = native
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] atk: Upgrade 1.32.0 - 2.2.0
---
diff --git a/meta/recipes-support/atk/atk-1.32.0/remove.G_CONST_RETURN.patch
b/meta/recipes-support/atk/atk-1.32.0/remove.G_CONST_RETURN.patch
deleted file mode 100644
index 0de3f26..000
--- a/meta/recipes-support/atk/atk-1.32.0/remove.G_CONST_RETURN.patch
+++ b/dev/null
@@ -1,630 +0,0 @@
-Upstream-Status: Accepted
-
-Similar patch is already included in 2.0.1 and newer
-http://ftp.gnome.org/pub/gnome/sources/atk/2.0/atk-2.0.1.news
-
-Signed-off-by: Martin Jansa martin.ja...@gmail.com
-
-diff -uNr atk-1.32.0.orig/atk/atkaction.c atk-1.32.0/atk/atkaction.c
atk-1.32.0.orig/atk/atkaction.c2010-09-06 08:45:45.0 +0200
-+++ atk-1.32.0/atk/atkaction.c 2011-09-30 10:29:49.896997586 +0200
-@@ -101,7 +101,7 @@
- * Returns a description string, or %NULL
- * if @action does not implement this interface.
- **/
--G_CONST_RETURN gchar*
-+const gchar*
- atk_action_get_description (AtkAction *obj,
- gint i)
- {
-@@ -140,7 +140,7 @@
- * Returns a name string, or %NULL
- * if @action does not implement this interface.
- **/
--G_CONST_RETURN gchar*
-+const gchar*
- atk_action_get_name (AtkAction *obj,
- gint i)
- {
-@@ -166,7 +166,7 @@
- * Returns a name string, or %NULL
- * if @action does not implement this interface.
- **/
--G_CONST_RETURN gchar*
-+const gchar*
- atk_action_get_localized_name (AtkAction *obj,
-gint i)
- {
-@@ -203,7 +203,7 @@
- * if there is no keybinding for this action.
- *
- **/
--G_CONST_RETURN gchar*
-+const gchar*
- atk_action_get_keybinding (AtkAction *obj,
-gint i)
- {
-diff -uNr atk-1.32.0.orig/atk/atkaction.h atk-1.32.0/atk/atkaction.h
atk-1.32.0.orig/atk/atkaction.h2010-09-06 08:45:45.0 +0200
-+++ atk-1.32.0/atk/atkaction.h 2011-09-30 10:29:49.897997588 +0200
-@@ -55,16 +55,16 @@
- gboolean(*do_action) (AtkAction *action,
- gint i);
- gint(*get_n_actions) (AtkAction *action);
-- G_CONST_RETURN gchar* (*get_description) (AtkAction *action,
-+ const gchar* (*get_description) (AtkAction *action,
- gint i);
-- G_CONST_RETURN gchar* (*get_name) (AtkAction *action,
-+ const gchar* (*get_name) (AtkAction *action,
- gint i);
-- G_CONST_RETURN gchar* (*get_keybinding)(AtkAction *action,
-+ const gchar* (*get_keybinding)(AtkAction *action,
- gint i);
- gboolean(*set_description) (AtkAction *action,
- gint i,
- const gchar *desc);
-- G_CONST_RETURN gchar* (*get_localized_name)(AtkAction *action,
-+ const gchar* (*get_localized_name)(AtkAction *action,
- gint i);
- AtkFunction pad2;
- };
-@@ -85,11 +85,11 @@
- gboolean atk_action_do_action(AtkAction *action,
- gint i);
- gint atk_action_get_n_actions(AtkAction *action);
--G_CONST_RETURN gchar* atk_action_get_description (AtkAction *action,
-+const gchar* atk_action_get_description (AtkAction *action,
-gint i);
--G_CONST_RETURN gchar* atk_action_get_name (AtkAction *action,
-+const gchar* atk_action_get_name (AtkAction *action,
-gint i);
--G_CONST_RETURN gchar* atk_action_get_keybinding (AtkAction *action,
-+const gchar* atk_action_get_keybinding (AtkAction *action,
-gint i);
- gboolean atk_action_set_description (AtkAction *action,
-gint i,
-@@ -97,7 +97,7 @@
-
- /* NEW in ATK 1.1: */
-
--G_CONST_RETURN gchar* atk_action_get_localized_name (AtkAction *action,
-+const gchar* atk_action_get_localized_name (AtkAction *action,
-ginti);
-
- /*
-diff -uNr atk-1.32.0.orig/atk/atkdocument.c atk-1.32.0/atk/atkdocument.c
atk-1.32.0.orig/atk/atkdocument.c 2010-09-06 08:45:45.0 +0200
-+++ atk-1.32.0/atk/atkdocument.c 2011-09-30 10:29:49.898997588 +0200
-@@ -93,7 +93,7 @@
- *
- * Returns: a string indicating the document type
- **/
--G_CONST_RETURN gchar*
-+const gchar*
- atk_document_get_document_type (AtkDocument
[OE-core] [PATCH] pango: Update to work with glib-2.0
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-graphics/pango/pango-1.28.4/noconst.patch
b/meta/recipes-graphics/pango/pango-1.28.4/noconst.patch
new file mode 100644
index 000..d4832a5
--- a/dev/null
+++ b/meta/recipes-graphics/pango/pango-1.28.4/noconst.patch
@@ -0,0 +1,408 @@
+G_CONST_RETURN is deprecated in glib 2.30 so remove to to avoid
+build failures.
+
+RP 2011/10/12
+
+Upstream-Status: Pending
+
+Index: pango-1.28.4/pango/fonts.c
+===
+--- pango-1.28.4.orig/pango/fonts.c2011-10-12 01:32:09.372046342 +0100
pango-1.28.4/pango/fonts.c 2011-10-12 01:32:34.512036630 +0100
+@@ -165,7 +165,7 @@
+ * %NULL if not previously set. This has the same life-time
+ * as the font description itself and should not be freed.
+ **/
+-G_CONST_RETURN char *
++const char *
+ pango_font_description_get_family (const PangoFontDescription *desc)
+ {
+ g_return_val_if_fail (desc != NULL, NULL);
+@@ -1927,7 +1927,7 @@
+ * Return value: the name of the family. This string is owned
+ * by the family object and must not be modified or freed.
+ **/
+-G_CONST_RETURN char *
++const char *
+ pango_font_family_get_name (PangoFontFamily *family)
+ {
+ g_return_val_if_fail (PANGO_IS_FONT_FAMILY (family), NULL);
+@@ -2060,7 +2060,7 @@
+ * Return value: the face name for the face. This string is
+ * owned by the face object and must not be modified or freed.
+ **/
+-G_CONST_RETURN char *
++const char *
+ pango_font_face_get_face_name (PangoFontFace *face)
+ {
+ g_return_val_if_fail (PANGO_IS_FONT_FACE (face), NULL);
+Index: pango-1.28.4/pango/pango-attributes.c
+===
+--- pango-1.28.4.orig/pango/pango-attributes.c 2011-10-12 01:32:09.552046155
+0100
pango-1.28.4/pango/pango-attributes.c 2011-10-12 01:32:34.522037975
+0100
+@@ -97,7 +97,7 @@
+ *
+ * Since: 1.22
+ **/
+-G_CONST_RETURN char *
++const char *
+ pango_attr_type_get_name (PangoAttrType type)
+ {
+ const char *result = NULL;
+Index: pango-1.28.4/pango/pango-attributes.h
+===
+--- pango-1.28.4.orig/pango/pango-attributes.h 2011-10-12 01:32:12.712046218
+0100
pango-1.28.4/pango/pango-attributes.h 2011-10-12 01:32:36.342045777
+0100
+@@ -180,7 +180,7 @@
+ };
+
+ PangoAttrType pango_attr_type_register (const gchar*name);
+-G_CONST_RETURN char * pango_attr_type_get_name (PangoAttrType type)
G_GNUC_CONST;
++const char * pango_attr_type_get_name (PangoAttrType type) G_GNUC_CONST;
+
+ void pango_attribute_init(PangoAttribute *attr,
+ const PangoAttrClass *klass);
+Index: pango-1.28.4/pango/pango-context.c
+===
+--- pango-1.28.4.orig/pango/pango-context.c2011-10-12 01:32:09.782046152
+0100
pango-1.28.4/pango/pango-context.c 2011-10-12 01:32:34.532039187 +0100
+@@ -188,7 +188,7 @@
+ *
+ * Since: 1.6
+ **/
+-G_CONST_RETURN PangoMatrix *
++const PangoMatrix *
+ pango_context_get_matrix (PangoContext *context)
+ {
+ g_return_val_if_fail (PANGO_IS_CONTEXT (context), NULL);
+Index: pango-1.28.4/pango/pango-context.h
+===
+--- pango-1.28.4.orig/pango/pango-context.h2011-10-12 01:32:12.892046153
+0100
pango-1.28.4/pango/pango-context.h 2011-10-12 01:32:36.352046105 +0100
+@@ -86,7 +86,7 @@
+
+ voidpango_context_set_matrix (PangoContext
*context,
+ const PangoMatrix
*matrix);
+-G_CONST_RETURN PangoMatrix *pango_context_get_matrix (PangoContext
*context);
++const PangoMatrix *pango_context_get_matrix (PangoContext *context);
+
+ /* Break a string of Unicode characters into segments with
+ * consistent shaping/language engine and bidrectional level.
+Index: pango-1.28.4/pango/pango-font.h
+===
+--- pango-1.28.4.orig/pango/pango-font.h 2011-10-12 01:32:13.072046150
+0100
pango-1.28.4/pango/pango-font.h2011-10-12 01:32:36.362046243 +0100
+@@ -117,7 +117,7 @@
+ const char
*family);
+ void pango_font_description_set_family_static
(PangoFontDescription *desc,
+ const char
*family);
+-G_CONST_RETURN char *pango_font_description_get_family(const
PangoFontDescription *desc) G_GNUC_PURE;
++const char *pango_font_description_get_family(const
PangoFontDescription *desc) G_GNUC_PURE;
+ void pango_font_description_set_style
(PangoFontDescription *desc,
+
[OE-core] [PATCH] libunique: Update to work with glib-2.0
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-gnome/libunique/libunique/noconst.patch
b/meta/recipes-gnome/libunique/libunique/noconst.patch
new file mode 100644
index 000..2cc0347
--- a/dev/null
+++ b/meta/recipes-gnome/libunique/libunique/noconst.patch
@@ -0,0 +1,130 @@
+G_CONST_RETURN is deprecated in glib 2.30 so remove to to avoid
+build failures.
+
+RP 2011/10/12
+
+Upstream-Status: Pending
+
+Index: libunique-1.1.6/unique/uniqueapp.c
+===
+--- libunique-1.1.6.orig/unique/uniqueapp.c2011-10-12 01:21:25.842046488
+0100
libunique-1.1.6/unique/uniqueapp.c 2011-10-12 01:21:55.062046796 +0100
+@@ -781,7 +781,7 @@
+ }
+
+
+-G_CONST_RETURN gchar *
++const gchar *
+ unique_command_to_string (UniqueApp *app,
+ gint command)
+ {
+@@ -863,7 +863,7 @@
+ return retval;
+ }
+
+-G_CONST_RETURN gchar *
++const gchar *
+ unique_response_to_string (UniqueResponse response)
+ {
+ GEnumClass *enum_class;
+Index: libunique-1.1.6/unique/uniquebackend.c
+===
+--- libunique-1.1.6.orig/unique/uniquebackend.c2011-10-12
01:21:25.742046323 +0100
libunique-1.1.6/unique/uniquebackend.c 2011-10-12 01:21:55.062046796
+0100
+@@ -111,7 +111,7 @@
+ *
+ * Return value: FIXME
+ */
+-G_CONST_RETURN gchar *
++const gchar *
+ unique_backend_get_name (UniqueBackend *backend)
+ {
+ g_return_val_if_fail (UNIQUE_IS_BACKEND (backend), NULL);
+@@ -154,7 +154,7 @@
+ *
+ * Return value: FIXME
+ */
+-G_CONST_RETURN gchar *
++const gchar *
+ unique_backend_get_startup_id (UniqueBackend *backend)
+ {
+ g_return_val_if_fail (UNIQUE_IS_BACKEND (backend), NULL);
+Index: libunique-1.1.6/unique/uniquebackend.h
+===
+--- libunique-1.1.6.orig/unique/uniquebackend.h2011-10-12
01:21:25.992046521 +0100
libunique-1.1.6/unique/uniquebackend.h 2011-10-12 01:21:56.512047875
+0100
+@@ -94,10 +94,10 @@
+
+ UniqueBackend * unique_backend_create (void);
+
+-G_CONST_RETURN gchar *unique_backend_get_name (UniqueBackend
*backend);
++const gchar *unique_backend_get_name (UniqueBackend *backend);
+ void unique_backend_set_name (UniqueBackend
*backend,
+ const gchar *name);
+-G_CONST_RETURN gchar *unique_backend_get_startup_id (UniqueBackend
*backend);
++const gchar *unique_backend_get_startup_id (UniqueBackend *backend);
+ void unique_backend_set_startup_id (UniqueBackend
*backend,
+ const gchar
*startup_id);
+ GdkScreen * unique_backend_get_screen (UniqueBackend
*backend);
+Index: libunique-1.1.6/unique/uniqueinternals.h
+===
+--- libunique-1.1.6.orig/unique/uniqueinternals.h 2011-10-12
01:21:25.892046532 +0100
libunique-1.1.6/unique/uniqueinternals.h 2011-10-12 01:21:56.512047875
+0100
+@@ -44,11 +44,11 @@
+ * and then back into an id
+ */
+ UniqueResponseunique_response_from_string (const gchar*response);
+-G_CONST_RETURN gchar *unique_response_to_string(UniqueResponse response);
++const gchar *unique_response_to_string(UniqueResponse response);
+
+ gint unique_command_from_string (UniqueApp *app,
+ const gchar*command);
+-G_CONST_RETURN gchar *unique_command_to_string (UniqueApp *app,
++const gchar *unique_command_to_string (UniqueApp *app,
+ gintcommand);
+
+ G_END_DECLS
+Index: libunique-1.1.6/unique/uniquemessage.c
+===
+--- libunique-1.1.6.orig/unique/uniquemessage.c2011-10-12
01:21:25.942046524 +0100
libunique-1.1.6/unique/uniquemessage.c 2011-10-12 01:21:55.072046595
+0100
+@@ -185,7 +185,7 @@
+ *
+ * Since: 1.0.2
+ */
+-G_CONST_RETURN guchar *
++const guchar *
+ unique_message_data_get (UniqueMessageData *message_data,
+ gsize *length)
+ {
+@@ -525,7 +525,7 @@
+ * owned by the #UniqueMessageData structure and should not be
+ * modified or freed
+ */
+-G_CONST_RETURN gchar *
++const gchar *
+ unique_message_data_get_startup_id (UniqueMessageData *message_data)
+ {
+ g_return_val_if_fail (message_data != NULL, NULL);
+Index: libunique-1.1.6/unique/uniquemessage.h
+===
+--- libunique-1.1.6.orig/unique/uniquemessage.h2011-10-12
01:21:25.792046596 +0100
libunique-1.1.6/unique/uniquemessage.h 2011-10-12 01:21:56.512047875
+0100
[OE-core] [PATCH] eds: Update to work with glib-2.0
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch
b/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch
new file mode 100644
index 000..0785a93
--- a/dev/null
+++ b/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch
@@ -0,0 +1,78 @@
+G_CONST_RETURN is deprecated in glib 2.30 so remove to to avoid
+build failures. Also resolve other deprecation issues.
+
+RP 2011/10/12
+
+Upstream-Status: Pending
+
+Index: git/libedataserver/e-data-server-util.c
+===
+--- git.orig/libedataserver/e-data-server-util.c 2011-10-12
01:42:40.622045788 +0100
git/libedataserver/e-data-server-util.c2011-10-12 01:48:16.732045664
+0100
+@@ -165,7 +165,8 @@
+ static gunichar
+ stripped_char (gunichar ch)
+ {
+-gunichar *decomp, retval;
++gunichar decomp[4];
++gunichar retval;
+ GUnicodeType utype;
+ gsize dlen;
+
+@@ -175,7 +176,7 @@
+ case G_UNICODE_CONTROL:
+ case G_UNICODE_FORMAT:
+ case G_UNICODE_UNASSIGNED:
+-case G_UNICODE_COMBINING_MARK:
++case G_UNICODE_SPACING_MARK:
+ /* Ignore those */
+ return 0;
+break;
+@@ -183,7 +184,7 @@
+ /* Convert to lowercase, fall through */
+ ch = g_unichar_tolower (ch);
+ case G_UNICODE_LOWERCASE_LETTER:
+-if ((decomp = g_unicode_canonical_decomposition (ch, dlen)))
{
++if ((dlen = g_unichar_fully_decompose (ch, FALSE, decomp,
4))) {
+ retval = decomp[0];
+ g_free (decomp);
+ return retval;
+Index: git/addressbook/libedata-book/e-data-book-factory.c
+===
+--- git.orig/addressbook/libedata-book/e-data-book-factory.c 2011-10-12
01:52:25.692045500 +0100
git/addressbook/libedata-book/e-data-book-factory.c2011-10-12
01:53:31.862045707 +0100
+@@ -238,7 +238,7 @@
+ return g_strdup_printf (
+ /org/gnome/evolution/dataserver/addressbook/%d/%u,
+ getpid (),
+- g_atomic_int_exchange_and_add (counter, 1));
++ g_atomic_int_add (counter, 1));
+ }
+
+ static void
+Index: git/addressbook/libedata-book/e-data-book.c
+===
+--- git.orig/addressbook/libedata-book/e-data-book.c 2011-10-12
01:54:40.752045465 +0100
git/addressbook/libedata-book/e-data-book.c2011-10-12
01:55:16.012045897 +0100
+@@ -553,7 +553,7 @@
+
+ return g_strdup_printf
(/org/gnome/evolution/dataserver/addressbook/BookView/%d/%d,
+ getpid (),
+- g_atomic_int_exchange_and_add ((int*)counter,
1));
++ g_atomic_int_add ((int*)counter, 1));
+ }
+
+ static void
+Index: git/calendar/libedata-cal/e-data-cal-factory.c
+===
+--- git.orig/calendar/libedata-cal/e-data-cal-factory.c2011-10-12
01:57:56.612045081 +0100
git/calendar/libedata-cal/e-data-cal-factory.c 2011-10-12
01:57:58.832045211 +0100
+@@ -227,7 +227,7 @@
+ return g_strdup_printf (
+ /org/gnome/evolution/dataserver/calendar/%d/%u,
+ getpid (),
+- g_atomic_int_exchange_and_add (counter, 1));
++ g_atomic_int_add (counter, 1));
+ }
+
+ static void
diff --git a/meta/recipes-sato/eds/eds-dbus_git.bb
b/meta/recipes-sato/eds/eds-dbus_git.bb
index 7fa8311..9424353 100644
--- a/meta/recipes-sato/eds/eds-dbus_git.bb
+++ b/meta/recipes-sato/eds/eds-dbus_git.bb
@@ -12,7 +12,7 @@ DEPENDS = intltool-native glib-2.0 gtk+ gconf dbus db
gnome-common virtual/libi
SRCREV = 7337d11aed576e7caaa12b4e881ad8d33668799f
PV = 2.30+git${SRCPV}
-PR = r1
+PR = r3
SRC_URI = git://git.gnome.org/evolution-data-server;protocol=git \
file://oh-contact.patch;striplevel=0 \
@@ -20,6 +20,7 @@ SRC_URI =
git://git.gnome.org/evolution-data-server;protocol=git \
file://optional_imapx_provider.patch \
file://new-contact-fix.patch \
file://old-gdk-api.patch \
+ file://depbuildfix.patch \
file://iconv-detect.h
S = ${WORKDIR}/git
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] clutter-1.6: update to 1.6.18
From 345e241830ea193c282691479add4a00b0d8 Mon Sep 17 00:00:00 2001
From: Richard Purdie richard.pur...@linuxfoundation.org
Date: Wed, 12 Oct 2011 13:15:11 +
Subject:
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-graphics/clutter/clutter-1.6_1.6.14.bb
b/meta/recipes-graphics/clutter/clutter-1.6_1.6.18.bb
index 555133f..9c32efd 100644
--- a/meta/recipes-graphics/clutter/clutter-1.6_1.6.14.bb
+++ b/meta/recipes-graphics/clutter/clutter-1.6_1.6.18.bb
@@ -22,5 +22,5 @@ do_configure_prepend () {
sed -i -e 's/^DOLT//' ${S}/configure.ac
}
-SRC_URI[md5sum] = 1da9f983115f9bd28b0be8176e53fe36
-SRC_URI[sha256sum] =
0564e57ca8eb24e76014627c0bb28a80a6c01b620ba14bc4198365562549576d
+SRC_URI[md5sum] = 7302513c96b00588b7779918fae0b33b
+SRC_URI[sha256sum] =
d849f92944be193e9d8e707f1371e6bab7fca473e09a492265e2e2296febd749
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] clutter: Update git recipe to more recent version
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-graphics/clutter/clutter_git.bb
b/meta/recipes-graphics/clutter/clutter_git.bb
index 020453f..897f5ff 100644
--- a/meta/recipes-graphics/clutter/clutter_git.bb
+++ b/meta/recipes-graphics/clutter/clutter_git.bb
@@ -3,9 +3,13 @@ require clutter-package.inc
LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34
-SRCREV = e957e277b8a4893ce8c99e94402036d42a8b3748
-PV = 1.0.0+git${SRCPV}
-PR = r9
+DEPENDS += cogl
+
+SRCREV = 39db46123ed6bbbc3e6ad359a64d4d344ca9e11b
+PV = 1.8.0+git${SRCPV}
+PR = r0
+
+DEFAULT_PREFERENCE = -1
SRC_URI = git://git.gnome.org/clutter;protocol=git;branch=master \
file://enable_tests-654c26a1301c9bc5f8e3e5e3b68af5eb1b2e0673.patch;rev=654c26a1301c9bc5f8e3e5e3b68af5eb1b2e0673
\
@@ -14,6 +18,8 @@ S = ${WORKDIR}/git
BASE_CONF += --disable-introspection
+AUTOTOOLS_AUXDIR = ${S}/build
+
do_configure_prepend () {
# Disable DOLT
sed -i -e 's/^DOLT//' ${S}/configure.ac
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] autotools: Enhance gettext handling to better work with SCM versions of code
If we pull SCM based code using gettext, Makefile.in.in in the
po directory can be missing. We therefore need to add this if
its not already present. We could use gettextize if it wasn't
so broken (for example requiring user input on stdin and installing
way more files that we ever care about such as the m4 files).
We also have a problem if a recipe sets a different AUX dir, for
now fix this by allowing recipes to specify when this is being done
using the AUTOTOOLS_AUXDIR variable. Ultimately we could likely
figure this out automatically.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index a4ce851..0413322 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -80,6 +80,8 @@ oe_runconf () {
fi
}
+AUTOTOOLS_AUXDIR ?= ${S}
+
autotools_do_configure() {
case ${PN} in
autoconf*)
@@ -144,7 +146,11 @@ autotools_do_configure() {
echo no | glib-gettextize --force --copy
fi
else if grep ^[[:space:]]*AM_GNU_GETTEXT
$CONFIGURE_AC /dev/null; then
- cp ${STAGING_DATADIR}/gettext/config.rpath ${S}/
+# We'd call gettextize here if it wasn't so
broken...
+ cp ${STAGING_DATADIR}/gettext/config.rpath
${AUTOTOOLS_AUXDIR}/
+ if [ ! -e ${S}/po/Makefile.in.in ]; then
+ cp ${STAGING_DATADIR}/gettext/po/Makefile.in.in
${S}/po/
+fi
fi
fi
fi
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cogl: Add git recipe (required by clutter)
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-graphics/clutter/cogl.inc
b/meta/recipes-graphics/clutter/cogl.inc
new file mode 100644
index 000..387f6ec
--- a/dev/null
+++ b/meta/recipes-graphics/clutter/cogl.inc
@@ -0,0 +1,22 @@
+DESCRIPTION = Clutter graphics library
+HOMEPAGE = http://www.clutter-project.org/;
+LICENSE = LGPL
+
+STDDEPENDS = virtual/libx11 gtk-doc-native pango glib-2.0 libxfixes
gdk-pixbuf libxi
+BASE_CONF = --disable-gtk-doc ${@get_clutter_fpu_setting(bb, d)}
+
+DEPENDS = ${STDDEPENDS} virtual/libgl
+EXTRA_OECONF = ${BASE_CONF} --with-flavour=glx
+
+FILESPATH = ${FILE_DIRNAME}/clutter
+
+inherit autotools pkgconfig gtk-doc gettext
+
+#check for TARGET_FPU=soft and inform configure of the result so it can
disable some floating points
+require clutter-fpu.inc
+
+#Fix up some weirdness in the docs
+do_configure_prepend() {
+sed -i s:doc/reference/Makefile::g ${S}/configure.ac
+sed -i s:doc::g ${S}/Makefile.am
+}
diff --git a/meta/recipes-graphics/clutter/cogl_git.bb
b/meta/recipes-graphics/clutter/cogl_git.bb
new file mode 100644
index 000..890c654
--- a/dev/null
+++ b/meta/recipes-graphics/clutter/cogl_git.bb
@@ -0,0 +1,19 @@
+require cogl.inc
+
+LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34
+
+SRCREV = 0a70a159c65357809740971570b2e301451161b5
+PV = 1.8.0+git${SRCPV}
+PR = r0
+
+DEFAULT_PREFERENCE = -1
+
+SRC_URI = git://git.gnome.org/cogl;protocol=git;branch=master
+S = ${WORKDIR}/git
+
+AUTOTOOLS_AUXDIR = ${S}/build
+
+do_configure_prepend () {
+ # Disable DOLT
+ sed -i -e 's/^DOLT//' ${S}/configure.ac
+}
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Some further build dependency timings
On 10/11/11 6:35 AM, Richard Purdie wrote:
On Mon, 2011-10-10 at 21:45 +0100, Richard Purdie wrote:
Just for reference, with a base configuration, sato image:
real 50m8.223s
user 298m41.450s
sys 52m42.200s
adding:
ASSUME_PROVIDED =+ bison-native flex-native sqlite3-native git-native
(and hacking the pseudo recipe to use a sqlite3-native):
real 42m6.740s
user 296m21.940s
sys 52m25.220s
We continue to have real dependency issues around gettext in both the
native and target builds...
So to continue the story, adding:
DEBUG_FLAGS =
INHERIT_INSANE =
PACKAGE_CLASSES = package_ipk
USER_CLASSES =
Results in:
real 38m23.053s
user 237m7.430s
sys 39m3.720s
Then adding PSEUDO_RELOADED=yes to the environment of tasks not needing
pseudo (hack patch below):
real 36m20.683s
user 236m19.580s
sys 37m54.450s
Finally, adding:
DISABLESTATIC = --disable-static
DISABLESTATIC_pn-qemu =
DISABLESTATIC_pn-qemu-native =
DISABLESTATIC_pn-openssl =
DISABLESTATIC_pn-openssl-native =
EXTRA_OECONF += ${DISABLESTATIC}
real 34m53.877s
user 233m34.780s
sys 38m50.190s
Cheers,
Richard
--- a/bitbake/lib/bb/runqueue.py
+++ b/bitbake/lib/bb/runqueue.py
@@ -1096,6 +1096,10 @@ class RunQueueExecute:
logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' %
(fn, taskname, ', '.join(fakedirs)))
+else:
+envbackup[PSEUDO_RELOADED] = os.environ.get(PSEUDO_RELOADED)
+os.environ[PSEUDO_RELOADED] = yes
+fakeenv[PSEUDO_RELOADED] = yes
PSEUDO_RELOADED was intended to only be used internally by pseudo. Specifically
to signify to fork/exec that we're about to run the pseudo server process and to
remove PSEUDO from the LD_PRELOAD on the next fork/exec.
The system simply checks the environment on the fork-exec and doesn't check the
value on pseudo-load. This is why it works.
That side effect means that any subsequent calls can NOT re-enable pseudo as
it's no longer in memory at all.
So what you are seeing at best is the time difference from avoiding the
LD_PRELOAD and the jump table setup. (Even when pseudo is disabled, we need to
enable the jump table, we just pass the call to the original function.)
But more then likely because pseudo is no longer memory resident for the called
processes and it's sub-processes.. there is likely some place in the system that
uses pseudo functionality that is no longer functioning properly.
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.
Also if it is desired to unload pseudo, I'd suggest we add a new environment
variable to pseudo that is specific about unloading pseudo, instead of using the
existing PSEUDO_RELOADED. Not only is the name confusing, but since it's an
internal item it's behavior may change or go away in the future.
(Below is from the pseudo man page:
PSEUDO_RELOADED
This purely internal variable is used to track state while try-
ing to re-execute to get rid of the LD_PRELOAD value when
spawning a server. (The pseudo server itself cannot function
running in the pseudo environment.)
)
sys.stdout.flush()
sys.stderr.flush()
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] git server move
On Tue, Oct 11, 2011 at 3:26 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: is there more information about the reasons? Is it just a new machine? Where is it hosted now? Certainly. It is still hosted at OSUOSL. We had some problems with the original VM (Melo), so git has been running on a temporary VM (Garnet, our build instance). Now that we have a replacement for Melo (Opal), we are moving to this machine. So what are the fingerprints of the new keys? ;-) 1024 ad:8e:65:4e:dc:4c:d9:63:8f:67:b3:87:03:c9:a1:73 ssh_host_dsa_key.pub (DSA) 2048 ed:99:0d:c1:6e:6c:02:75:df:36:25:4d:62:39:b7:e5 ssh_host_rsa_key.pub (RSA) Let me know if you have any more questions. Thanks, Cliff -- = http://bec-systems.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Some further build dependency timings
On Wed, 2011-10-12 at 09:40 -0500, Mark Hatle wrote: --- a/bitbake/lib/bb/runqueue.py +++ b/bitbake/lib/bb/runqueue.py @@ -1096,6 +1096,10 @@ class RunQueueExecute: logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' % (fn, taskname, ', '.join(fakedirs))) +else: +envbackup[PSEUDO_RELOADED] = os.environ.get(PSEUDO_RELOADED) +os.environ[PSEUDO_RELOADED] = yes +fakeenv[PSEUDO_RELOADED] = yes PSEUDO_RELOADED was intended to only be used internally by pseudo. Specifically to signify to fork/exec that we're about to run the pseudo server process and to remove PSEUDO from the LD_PRELOAD on the next fork/exec. Right, I realised I was abusing it here, its good for a performance measurement though ;-) The system simply checks the environment on the fork-exec and doesn't check the value on pseudo-load. This is why it works. That side effect means that any subsequent calls can NOT re-enable pseudo as it's no longer in memory at all. So what you are seeing at best is the time difference from avoiding the LD_PRELOAD and the jump table setup. (Even when pseudo is disabled, we need to enable the jump table, we just pass the call to the original function.) But more then likely because pseudo is no longer memory resident for the called processes and it's sub-processes.. there is likely some place in the system that uses pseudo functionality that is no longer functioning properly. I'm not sure that there is in our use cases. If we need pseudo functionality the tasks are marked as fakeroot with a flag. If that flag is not set (which is when the above code triggers), its perfectly fine to have pseudo unload at the next exec. 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. Also if it is desired to unload pseudo, I'd suggest we add a new environment variable to pseudo that is specific about unloading pseudo, instead of using the existing PSEUDO_RELOADED. Not only is the name confusing, but since it's an internal item it's behavior may change or go away in the future. (Below is from the pseudo man page: PSEUDO_RELOADED This purely internal variable is used to track state while try- ing to re-execute to get rid of the LD_PRELOAD value when spawning a server. (The pseudo server itself cannot function running in the pseudo environment.) ) I suspect we may need a dedicated option for this... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] git server move
On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFOlU0rMkyGM64RGpERArroAJ9EuHaOEcv64o9q9kJLZk50/OLoSQCgmKjd Yxh2H5CGKREmOq32gr36aes= =Xubc -END PGP SIGNATURE- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] git server move
Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven: On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org Let me rephrase: when will it be working again? I still get No repositories found when clicking on a repo. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFOlU0rMkyGM64RGpERArroAJ9EuHaOEcv64o9q9kJLZk50/OLoSQCgmKjd Yxh2H5CGKREmOq32gr36aes= =Xubc -END PGP SIGNATURE- ___ 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] git server move
On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven: On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org Let me rephrase: when will it be working again? I still get No repositories found when clicking on a repo. Weird I see all the repos fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFOlU0rMkyGM64RGpERArroAJ9EuHaOEcv64o9q9kJLZk50/OLoSQCgmKjd Yxh2H5CGKREmOq32gr36aes= =Xubc -END PGP SIGNATURE- ___ 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 ___ Openembedded-devel mailing list openembedded-de...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] git server move
Le 12/10/2011 17:22, Khem Raj a écrit : On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooik...@dominion.thruhere.net wrote: Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven: On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooik...@dominion.thruhere.net wrote: When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org Let me rephrase: when will it be working again? I still get No repositories found when clicking on a repo. Weird I see all the repos fine. also works fine here on http://cgit.openembedded.org/ Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] git server move
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 12-10-11 17:22, Khem Raj schreef: On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven: On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org Let me rephrase: when will it be working again? I still get No repositories found when clicking on a repo. Weird I see all the repos fine. Old: http://cgit.openembedded.org/cgit.cgi/openembedded-core/log/?h=master-next New: http://cgit.openembedded.org/openembedded-core/log/?h=master-next So the URLs changed :( -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFOlbJUMkyGM64RGpERAu24AKClgYvg645M1A7QDsFwqqI2nitZvgCfYUJe xCOhSnarP1PELO3WyrhOSQg= =6oZd -END PGP SIGNATURE- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] git server move
On Wed, Oct 12, 2011 at 8:22 AM, Khem Raj raj.k...@gmail.com wrote: On Wed, Oct 12, 2011 at 8:18 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven: On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org Let me rephrase: when will it be working again? I still get No repositories found when clicking on a repo. Weird I see all the repos fine. Works here too. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] git server move
On Wednesday 12 October 2011 16:18:37 Koen Kooi wrote: Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven: On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org Let me rephrase: when will it be working again? I still get No repositories found when clicking on a repo. 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. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bitbake.conf: Exclude MACHINE from MACHINE_OVERRIDES variable dependency list
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/conf/bitbake.conf |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 11d76b8..8cf7a60 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -670,6 +670,7 @@ OVERRIDES =
${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVE
DISTROOVERRIDES ?= ${DISTRO}
MACHINEOVERRIDES ?= ${MACHINE}
OVERRIDES[vardepsexclude] = MACHINE
+MACHINEOVERRIDES[vardepsexclude] = MACHINE
CPU_FEATURES ?=
CPU_FEATURES_arm ?= vfp
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] git server move
On Wed, Oct 12, 2011 at 8:48 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 12 October 2011 16:18:37 Koen Kooi wrote: Op 12 okt. 2011, om 17:16 heeft Khem Raj het volgende geschreven: On Wed, Oct 12, 2011 at 1:17 AM, Koen Kooi k...@dominion.thruhere.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 11-10-11 21:11, Cliff Brake schreef: Hi, we are moving git.openembedded.org to a new server. SSH access on the old server has been disabled. git:// still works there. As soon as DNS propagates, SSH access will work with the new server. Let me know if you see any problems. When will cgit be back up? It should be up already. Do Ctrl+f5 in your browser on git.openembedded.org Let me rephrase: when will it be working again? I still get No repositories found when clicking on a repo. 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. Yes, however the new webserver is running on nginx so coming up with correct set of rules to reproduce old urls is a bit of challange. Right now the mails to openembedded-commit ml are probably not going and the url mentioned in those emails dont resolve as well but eventually they will Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/1] QA check for defined packages
On 10/12/2011 05:37 AM, Richard Purdie wrote: On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote: I'm looking for some comments on this WIP patch. The reason I've added this is because the hob GUI requires us to offer much more reliable metadata - we show the user available packages, as defined by each recipe, to add to their image. Should a recipe define a package and yet not actually create it and the user has included that in their image we cause errors at build time. However whilst the idea seems sound enough, there are some caveats - running a world build with this patch I see failures fairly early on at least a few of which I'd expect we'll need to special-case: * eglibc-local * linux-yocto * linux-libc-headers * gcc-runtime Thoughts? I think we probably do need to cleanup some of that data. I have some thoughts about where we're at with hob and this is probably as good a time as any to share them. Effectively the problem is that there is a large body of data we only compute during the build process. This includes what the exact runtime dependencies of packages are, which packages exactly are generated (PACKAGES_DYNAMIC), what the size of the packages are, how long they take to build and so on. Some things we can fix, some things we can hack around but at the end of the day there are some things we just plain can't change. I'm beginning to think we need to have two phases of control of the system: a) The build phase This is the step that generates the package feeds. b) The image construction phase This is the step that takes the package feed data and turns it into an image. I actually think this is a neat idea, in fact we have the beginnings of a Gtk+ GUI to create images from a package feed which Rob Bradford worked on some 3 years or so ago - puccho. It's no doubt bit-rotten but may be worth a look. I think we can reuse pieces from puccho and hob to create a GUI per this high-level design and I think we'd be much better off for it. Obviously, you can skip to b) if you already have a package feed. a), right? Indeed I expect that this will be more in line with certain proposed use cases. So we'd be talking about two UI's that could effectively hand off to each other and share a build in progress feedback to the user system. The image construction dialog would have a Missing Packages? Build them here type switch. This would mean the build system can continue on at what it does best yet the UI can let the users do what they want to do, particularly on a prebuilt package feed. I like it. I think we had to write one to throw away to realise quite how much data we're missing up front but I support the proposed design. Regards, Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 2/4] qt4-x11-free: bring back pkg-config fixups
On 12.10.2011 11:23, Paul Eggleton wrote: On Wednesday 12 October 2011 08:45:03 Martin Jansa wrote: From: Simon Busch morp...@gravedo.de With b40b9c024be5e1ec81a31961158b3e6b529acfe0 some pkg-config fixups where removed from qt4.inc which breaks the pkg-config files for qt4-embedded. Without that the pkg-config files for qt4-x11-free are broken. So this patch puts the fixes into the qt4-x11-free.inc file to be used by qt4-x11-free and not qt4-embedded. So why do we need these only in the X11 version? Surely they should be applicable to both embedded and X11, or not at all...? With b40b9c024be5e1ec81a31961158b3e6b529acfe0 I removed this fixups from qt4.inc as I had problems with building agains qt4-embedded as cflags were incorrect in the created pkg-config files. Now I switched my application to x11 and got other problems with the pkg-config files from qt4-x11-free which can be resolved with the fixups I removed before. So you are right we need them for qt4-x11-free but not for qt4-embedded. I didn't investigated from where these differences are coming. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
Op 12 okt. 2011 om 20:10 heeft Simon Busch morp...@gravedo.de het volgende geschreven: On 12.10.2011 10:02, Eric Bénard wrote: Hi, Le 12/10/2011 09:45, Martin Jansa a écrit : From: Simon Buschmorp...@gravedo.de In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly. When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ? Thats up to the environment you are using qt4-embedded in. In my case the setup is a little bit more complicated. We're using tslib but not directly in qt4-embedded (we can get rid of tslib completely but time is missing). I removed the dependency from qt4-embedded as qt4-embedded in oe-core should be the general thing used in all environments and therefore should be only a minimal setup with minimal dependencies. No, it should work in most cases, breaking qt:e like is not acceptable. If someone needs tslib for qt4-embedded for his machine layer he should include tslib support in the machine layer itself. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
On 12.10.2011 20:14, Koen Kooi wrote: Op 12 okt. 2011 om 20:10 heeft Simon Busch morp...@gravedo.de het volgende geschreven: On 12.10.2011 10:02, Eric Bénard wrote: Hi, Le 12/10/2011 09:45, Martin Jansa a écrit : From: Simon Buschmorp...@gravedo.de In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly. When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ? Thats up to the environment you are using qt4-embedded in. In my case the setup is a little bit more complicated. We're using tslib but not directly in qt4-embedded (we can get rid of tslib completely but time is missing). I removed the dependency from qt4-embedded as qt4-embedded in oe-core should be the general thing used in all environments and therefore should be only a minimal setup with minimal dependencies. No, it should work in most cases, breaking qt:e like is not acceptable. What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface). -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
On Wed, Oct 12, 2011 at 2:20 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 12 okt. 2011, om 10:02 heeft Eric Bénard het volgende geschreven: Hi, Le 12/10/2011 09:45, Martin Jansa a écrit : From: Simon Buschmorp...@gravedo.de In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly. When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ? We ran into this at work and like Eric, I'm curious how calibration (and e.g. dejitter) works in the linux-input world combined with qt/e. Not directly applicable, but I keep meaning to take a look at http://atrey.karlin.mff.cuni.cz/~metan/evfilter/ - it seems quite interesting. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
Op 12 okt. 2011, om 20:34 heeft Simon Busch het volgende geschreven: On 12.10.2011 20:14, Koen Kooi wrote: Op 12 okt. 2011 om 20:10 heeft Simon Busch morp...@gravedo.de het volgende geschreven: On 12.10.2011 10:02, Eric Bénard wrote: Hi, Le 12/10/2011 09:45, Martin Jansa a écrit : From: Simon Buschmorp...@gravedo.de In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly. When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ? Thats up to the environment you are using qt4-embedded in. In my case the setup is a little bit more complicated. We're using tslib but not directly in qt4-embedded (we can get rid of tslib completely but time is missing). I removed the dependency from qt4-embedded as qt4-embedded in oe-core should be the general thing used in all environments and therefore should be only a minimal setup with minimal dependencies. No, it should work in most cases, breaking qt:e like is not acceptable. What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface). When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/1] QA check for defined packages
On Wed, 2011-10-12 at 10:43 -0700, Joshua Lock wrote: On 10/12/2011 05:37 AM, Richard Purdie wrote: On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote: I'm looking for some comments on this WIP patch. The reason I've added this is because the hob GUI requires us to offer much more reliable metadata - we show the user available packages, as defined by each recipe, to add to their image. Should a recipe define a package and yet not actually create it and the user has included that in their image we cause errors at build time. However whilst the idea seems sound enough, there are some caveats - running a world build with this patch I see failures fairly early on at least a few of which I'd expect we'll need to special-case: * eglibc-local * linux-yocto * linux-libc-headers * gcc-runtime Thoughts? I think we probably do need to cleanup some of that data. I have some thoughts about where we're at with hob and this is probably as good a time as any to share them. Effectively the problem is that there is a large body of data we only compute during the build process. This includes what the exact runtime dependencies of packages are, which packages exactly are generated (PACKAGES_DYNAMIC), what the size of the packages are, how long they take to build and so on. Some things we can fix, some things we can hack around but at the end of the day there are some things we just plain can't change. I'm beginning to think we need to have two phases of control of the system: a) The build phase This is the step that generates the package feeds. b) The image construction phase This is the step that takes the package feed data and turns it into an image. I actually think this is a neat idea, in fact we have the beginnings of a Gtk+ GUI to create images from a package feed which Rob Bradford worked on some 3 years or so ago - puccho. It's no doubt bit-rotten but may be worth a look. I think we can reuse pieces from puccho and hob to create a GUI per this high-level design and I think we'd be much better off for it. Obviously, you can skip to b) if you already have a package feed. a), right? Indeed I expect that this will be more in line with certain proposed use cases. No, you'd skip the package feed generation and just end up using it so skip a) and start from b). So we'd be talking about two UI's that could effectively hand off to each other and share a build in progress feedback to the user system. The image construction dialog would have a Missing Packages? Build them here type switch. This would mean the build system can continue on at what it does best yet the UI can let the users do what they want to do, particularly on a prebuilt package feed. I like it. I think we had to write one to throw away to realise quite how much data we're missing up front but I support the proposed design. I'd not say thrown away. We've moved a lot of the code forward and significant pieces would get reused... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
Hi, Le 12/10/2011 20:10, Simon Busch a écrit : On 12.10.2011 10:02, Eric Bénard wrote: Le 12/10/2011 09:45, Martin Jansa a écrit : From: Simon Buschmorp...@gravedo.de In most cases we don't need tslib in std. configuration as touchscreen access in most devices today is done with linux input interface. If some specific machine has a need for tslib support it should add the dependency in it's machine layer again and modify the profile script accordingly. When using a resistive touchscreen, tslib is a common solution to handle calibration and raw value processing : do you think this is a good thing to remove this ? Thats up to the environment you are using qt4-embedded in. In my case the setup is a little bit more complicated. We're using tslib but not directly in qt4-embedded (we can get rid of tslib completely but time is missing). I removed the dependency from qt4-embedded as qt4-embedded in oe-core should be the general thing used in all environments and therefore should be only a minimal setup with minimal dependencies. If someone needs tslib for qt4-embedded for his machine layer he should include tslib support in the machine layer itself. removing tslib plugin in qt4e seems not the good solution as this plugin can be built but not installed by default. In my opinion that's only the qte.sh script which could be more generic and maybe could be in its own configuration package so that several machines can share the same qt4e packages (picking the plugins they need) and have their own qte-config (for example) package. Else, why don't you akso remove plugin-gfx-transformed which is not used be many machines, or plugin-gfx-vnc or plugin-gfx-directfb which is only used on machine needing directfb or plugin-gfx-qvfb as real machine don't need a virtual framebuffer or even qt-mouse-pc as you may think that pc with mouses don't need qtembedded ... in the end we may also notice that basic platforms can use qt without a display, so why not removing graphic support at all to make the think even more generic and reduce the number of dependencies ;-) Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/1] QA check for defined packages
On 10/12/2011 12:18 PM, Richard Purdie wrote: Obviously, you can skip to b) if you already have a package feed. a), right? Indeed I expect that this will be more in line with certain proposed use cases. No, you'd skip the package feed generation and just end up using it so skip a) and start from b). My bad, I read that as skip b), not skip to b). Apologies. So we'd be talking about two UI's that could effectively hand off to each other and share a build in progress feedback to the user system. The image construction dialog would have a Missing Packages? Build them here type switch. This would mean the build system can continue on at what it does best yet the UI can let the users do what they want to do, particularly on a prebuilt package feed. I like it. I think we had to write one to throw away to realise quite how much data we're missing up front but I support the proposed design. I'd not say thrown away. We've moved a lot of the code forward and significant pieces would get reused... Quite right, I meant the spirit of the quote. I've tried where possible to create re-usable components for hob. The crumbs module of the bb ui is chock full these days and there were various changes to core BitBake that will hopefully be useful outside of hob. Cheers, Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
On 12.10.2011 21:09, Koen Kooi wrote: What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface). When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction. You're talking here about one case where tslib is needed to get a working touchscreen. But there are even cases where tslib is not needed to get a working touchscreen. qt:e does not strongly depends on tslib, it can work without. So if you need it you should add it to your machine layer as it is really machine specific if you need tslib or not. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
On 12.10.2011 21:24, Simon Busch wrote: On 12.10.2011 21:09, Koen Kooi wrote: What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface). When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction. You're talking here about one case where tslib is needed to get a working touchscreen. But there are even cases where tslib is not needed to get a working touchscreen. qt:e does not strongly depends on tslib, it can work without. So if you need it you should add it to your machine layer as it is really machine specific if you need tslib or not. Eric brings it to the point, only resetting the qte.sh script to a default one which uses a linux input even node should be enough. -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
On Wed, Oct 12, 2011 at 12:24 PM, Simon Busch morp...@gravedo.de wrote: On 12.10.2011 21:09, Koen Kooi wrote: What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface). When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction. You're talking here about one case where tslib is needed to get a working touchscreen. But there are even cases where tslib is not needed to get a working touchscreen. The base should be the bare min necessary to function in the common case, in my opinion. Touchscreens that don't require calibration are few and far between, so making the majority of machines with touchscreens have to override it seems far from ideal. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
On 12.10.2011 21:29, Simon Busch wrote: On 12.10.2011 21:24, Simon Busch wrote: On 12.10.2011 21:09, Koen Kooi wrote: What is breaking qt:e in this case? For me it's just a feature reduction and not a break (as qt:e still works fine with the linux input interface). When your TS is suddenly uncalibrated and jittery, it's a breakage, not a feature reduction. You're talking here about one case where tslib is needed to get a working touchscreen. But there are even cases where tslib is not needed to get a working touchscreen. qt:e does not strongly depends on tslib, it can work without. So if you need it you should add it to your machine layer as it is really machine specific if you need tslib or not. Eric brings it to the point, only resetting the qte.sh script to a default one which uses a linux input even node should be enough. Sorry for my little generic trip ... :) I will provide another patch in the following days which just makes qte.sh use of a std. linux input dev node instead of a tslib one if nobody has any objections against this. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input
Hi, Le 12/10/2011 21:52, Simon Busch a écrit : I will provide another patch in the following days which just makes qte.sh use of a std. linux input dev node instead of a tslib one if nobody has any objections against this. maybe moving qt4-embedded-conf in its own recipe would be better : that would allow qte.sh customization without having to rebuild qt4-embedded. Then you could have qte.sh with linux input in your machine's overlay and could keep the default qte.sh as it actually is in oe-core. Also, does defaulting to linux input dev works in qemu machines (for example with qt4e-demo-image ? Eric ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] linux-yocto: config cleanup and streamlining
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.zanu...@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(-) -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] linux-yocto: config cleanup and streamlining
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
Signed-off-by: Tom Zanussi tom.zanu...@intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
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(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb
index 9746f1a..72db7bf 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb
@@ -16,7 +16,7 @@ LINUX_KERNEL_TYPE = preempt-rt
SRCREV_machine ?= 0936e13cc65d816f1759e2322c5e3fc82a5037f3
SRCREV_machine_qemuppc ?= 0936e13cc65d816f1759e2322c5e3fc82a5037f3
-SRCREV_meta ?= d05450e4aef02c1b7137398ab3a9f8f96da74f52
+SRCREV_meta ?= 353d43d340e87996b4be4c5f6ddb4447e050b65c
PR = r1
PV = ${LINUX_VERSION}+git${SRCPV}
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
index c36e8b5..9da7cc1 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb
@@ -18,7 +18,7 @@ SRCREV_machine_qemuppc ?=
eccd57eaa4c2b580b9adbbc39e19ecbff56779ae
SRCREV_machine_qemux86 ?= 72671808fdbe69a9fe03fd8f094e7c59da04a28c
SRCREV_machine_qemux86-64 ?= 2b2d0954a6fd12b4bb7f02f019bc62633c8060a1
SRCREV_machine ?= 6b2c7d65b844e686eae7d5cccb9b638887afe28e
-SRCREV_meta ?= d05450e4aef02c1b7137398ab3a9f8f96da74f52
+SRCREV_meta ?= 353d43d340e87996b4be4c5f6ddb4447e050b65c
PR = r2
PV = ${LINUX_VERSION}+git${SRCPV}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core 3/4] conf: machine: includes: add armv6-novfp support
On Wed, 2011-10-12 at 09:45 +0200, Martin Jansa wrote:
-TUNE_FEATURES_tune-armv6 ?= armv6 vfp
-TUNE_FEATURES_tune-armv6t ?= armv6 vfp thumb
+AVAILTUNES += armv6 armv6t
+TUNE_FEATURES_tune-armv6 ?= armv6
+TUNE_FEATURES_tune-armv6t ?= armv6 thumb
+PACKAGE_EXTRA_ARCHS_tune-armv6 = ${PACKAGE_EXTRA_ARCHS_tune-armv5} armv6
+PACKAGE_EXTRA_ARCHS_tune-armv6t = ${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv6
armv6t
+
+# Little Endian + VFP
+AVAILTUNES += armv6-vfp armv6t-vfp armv6hf-vfp armv6thf-vfp
+TUNE_FEATURES_tune-armv6-vfp ?= armv6 vfp
This patch doesn't seem to do what it says in the subject line. It
doesn't add an armv6-novfp tune, instead it removes vfp from the
existing armv6 and armv6t tunes.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eds: Update to work with glib-2.0
On 10/12/2011 06:39 AM, Richard Purdie wrote:
Signed-off-by: Richard Purdierichard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch
b/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch
new file mode 100644
index 000..0785a93
--- a/dev/null
+++ b/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch
@@ -0,0 +1,78 @@
+G_CONST_RETURN is deprecated in glib 2.30 so remove to to avoid
+build failures. Also resolve other deprecation issues.
+
+RP 2011/10/12
+
Shouldn't this really be a Signed-off-by line?
Sau!
+Upstream-Status: Pending
+
+Index: git/libedataserver/e-data-server-util.c
+===
+--- git.orig/libedataserver/e-data-server-util.c 2011-10-12
01:42:40.622045788 +0100
git/libedataserver/e-data-server-util.c2011-10-12 01:48:16.732045664
+0100
+@@ -165,7 +165,8 @@
+ static gunichar
+ stripped_char (gunichar ch)
+ {
+-gunichar *decomp, retval;
++gunichar decomp[4];
++gunichar retval;
+ GUnicodeType utype;
+ gsize dlen;
+
+@@ -175,7 +176,7 @@
+ case G_UNICODE_CONTROL:
+ case G_UNICODE_FORMAT:
+ case G_UNICODE_UNASSIGNED:
+-case G_UNICODE_COMBINING_MARK:
++case G_UNICODE_SPACING_MARK:
+ /* Ignore those */
+ return 0;
+break;
+@@ -183,7 +184,7 @@
+ /* Convert to lowercase, fall through */
+ ch = g_unichar_tolower (ch);
+ case G_UNICODE_LOWERCASE_LETTER:
+-if ((decomp = g_unicode_canonical_decomposition (ch,dlen))) {
++if ((dlen = g_unichar_fully_decompose (ch, FALSE, decomp,
4))) {
+ retval = decomp[0];
+ g_free (decomp);
+ return retval;
+Index: git/addressbook/libedata-book/e-data-book-factory.c
+===
+--- git.orig/addressbook/libedata-book/e-data-book-factory.c 2011-10-12
01:52:25.692045500 +0100
git/addressbook/libedata-book/e-data-book-factory.c2011-10-12
01:53:31.862045707 +0100
+@@ -238,7 +238,7 @@
+ return g_strdup_printf (
+ /org/gnome/evolution/dataserver/addressbook/%d/%u,
+ getpid (),
+- g_atomic_int_exchange_and_add (counter, 1));
++ g_atomic_int_add (counter, 1));
+ }
+
+ static void
+Index: git/addressbook/libedata-book/e-data-book.c
+===
+--- git.orig/addressbook/libedata-book/e-data-book.c 2011-10-12
01:54:40.752045465 +0100
git/addressbook/libedata-book/e-data-book.c2011-10-12
01:55:16.012045897 +0100
+@@ -553,7 +553,7 @@
+
+ return g_strdup_printf
(/org/gnome/evolution/dataserver/addressbook/BookView/%d/%d,
+ getpid (),
+- g_atomic_int_exchange_and_add ((int*)counter,
1));
++ g_atomic_int_add ((int*)counter, 1));
+ }
+
+ static void
+Index: git/calendar/libedata-cal/e-data-cal-factory.c
+===
+--- git.orig/calendar/libedata-cal/e-data-cal-factory.c2011-10-12
01:57:56.612045081 +0100
git/calendar/libedata-cal/e-data-cal-factory.c 2011-10-12
01:57:58.832045211 +0100
+@@ -227,7 +227,7 @@
+ return g_strdup_printf (
+ /org/gnome/evolution/dataserver/calendar/%d/%u,
+ getpid (),
+- g_atomic_int_exchange_and_add (counter, 1));
++ g_atomic_int_add (counter, 1));
+ }
+
+ static void
diff --git a/meta/recipes-sato/eds/eds-dbus_git.bb
b/meta/recipes-sato/eds/eds-dbus_git.bb
index 7fa8311..9424353 100644
--- a/meta/recipes-sato/eds/eds-dbus_git.bb
+++ b/meta/recipes-sato/eds/eds-dbus_git.bb
@@ -12,7 +12,7 @@ DEPENDS = intltool-native glib-2.0 gtk+ gconf dbus db
gnome-common virtual/libi
SRCREV = 7337d11aed576e7caaa12b4e881ad8d33668799f
PV = 2.30+git${SRCPV}
-PR = r1
+PR = r3
SRC_URI = git://git.gnome.org/evolution-data-server;protocol=git \
file://oh-contact.patch;striplevel=0 \
@@ -20,6 +20,7 @@ SRC_URI =
git://git.gnome.org/evolution-data-server;protocol=git \
file://optional_imapx_provider.patch \
file://new-contact-fix.patch \
file://old-gdk-api.patch \
+ file://depbuildfix.patch \
file://iconv-detect.h
S = ${WORKDIR}/git
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCHv2 29/30] mesa: add new version 7.11
On Mon, 2011-10-03 at 15:29 +0200, Martin Jansa wrote: Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/recipes-graphics/mesa/mesa-7.11.inc | 15 ++ .../mesa/mesa-dri-glsl-native_7.11.bb | 28 meta/recipes-graphics/mesa/mesa-dri_7.11.bb|4 +++ meta/recipes-graphics/mesa/mesa-xlib_7.11.bb |4 +++ 4 files changed, 51 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-graphics/mesa/mesa-7.11.inc create mode 100644 meta/recipes-graphics/mesa/mesa-dri-glsl-native_7.11.bb create mode 100644 meta/recipes-graphics/mesa/mesa-dri_7.11.bb create mode 100644 meta/recipes-graphics/mesa/mesa-xlib_7.11.bb I've been seeing a ton of different issues after the xserver upgrade with mesa/driver mismatches. In order to try and get some stability back to master, I've merged just enough of the mesa upgrade to 7.11 to get things building again. Looking at the rest of the patch, I have worried about machine specific elements in something which is not machine specific. The rest of the pieces are likley going to need more thought (per arch default config?). We should be able to sort through the remaining changes in this patch series as I like moving things to the common include, it just needs to be split from the version upgrade and the machine issue resolved. I've also bumped the video-intel driver version and merged a fix to get things to build. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eds: Update to work with glib-2.0
On Wed, 2011-10-12 at 14:35 -0700, Saul Wold wrote: On 10/12/2011 06:39 AM, Richard Purdie wrote: Signed-off-by: Richard Purdierichard.pur...@linuxfoundation.org --- diff --git a/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch b/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch new file mode 100644 index 000..0785a93 --- a/dev/null +++ b/meta/recipes-sato/eds/eds-dbus/depbuildfix.patch @@ -0,0 +1,78 @@ +G_CONST_RETURN is deprecated in glib 2.30 so remove to to avoid +build failures. Also resolve other deprecation issues. + +RP 2011/10/12 Shouldn't this really be a Signed-off-by line? The original intent with patches was to understand who wrote them. That is extremely useful information in X years time and was missing in many cases. The sign-off doesn't mean much in this context. The above does identify who wrote it (and when) so I'm not convinced there is a problem there. Admittedly I have not put my full name or email address so its not as clear as it could be but I've been doing this for a while now and I'm the only one signing patches with those initials... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gamin: Fix glib 2.30 deprecation issues
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-extended/gamin/gamin/noconst.patch
b/meta/recipes-extended/gamin/gamin/noconst.patch
new file mode 100644
index 000..7b2998c
--- a/dev/null
+++ b/meta/recipes-extended/gamin/gamin/noconst.patch
@@ -0,0 +1,59 @@
+G_CONST_RETURN is deprecated in glib 2.30 so remove to to avoid
+build failures.
+
+RP 2011/10/12
+
+Upstream-Status: Pending
+
+Index: gamin-0.1.10/server/gam_node.c
+===
+--- gamin-0.1.10.orig/server/gam_node.c2011-10-12 15:25:45.217178314
+0100
gamin-0.1.10/server/gam_node.c 2011-10-12 15:26:17.807178293 +0100
+@@ -122,7 +122,7 @@
+ * it has finished with the string. If it must keep it longer, it
+ * should makes its own copy. The returned string must not be freed.
+ */
+-G_CONST_RETURN char *
++const char *
+ gam_node_get_path(GamNode * node)
+ {
+ g_assert(node);
+Index: gamin-0.1.10/server/gam_node.h
+===
+--- gamin-0.1.10.orig/server/gam_node.h2011-10-12 15:25:46.857178269
+0100
gamin-0.1.10/server/gam_node.h 2011-10-12 15:26:28.637178297 +0100
+@@ -58,7 +58,7 @@
+ void gam_node_set_is_dir (GamNode *node,
+ gbooleanis_dir);
+
+-G_CONST_RETURN char *gam_node_get_path(GamNode *node);
++const char *gam_node_get_path(GamNode *node);
+
+ GList*gam_node_get_subscriptions (GamNode *node);
+
+Index: gamin-0.1.10/server/gam_subscription.c
+===
+--- gamin-0.1.10.orig/server/gam_subscription.c2011-10-12
15:25:40.497177525 +0100
gamin-0.1.10/server/gam_subscription.c 2011-10-12 15:26:39.867178304
+0100
+@@ -141,7 +141,7 @@
+ * @param sub the GamSubscription
+ * @returns The path being monitored. It should not be freed.
+ */
+-G_CONST_RETURN char *
++const char *
+ gam_subscription_get_path(GamSubscription * sub)
+ {
+ if (sub == NULL)
+Index: gamin-0.1.10/server/gam_subscription.h
+===
+--- gamin-0.1.10.orig/server/gam_subscription.h2011-10-12
15:25:28.507178266 +0100
gamin-0.1.10/server/gam_subscription.h 2011-10-12 15:25:58.817178285
+0100
+@@ -21,7 +21,7 @@
+
+ int gam_subscription_get_reqno(GamSubscription *sub);
+
+-G_CONST_RETURN char *gam_subscription_get_path (GamSubscription *sub);
++const char *gam_subscription_get_path (GamSubscription *sub);
+
+ GamListener *gam_subscription_get_listener (GamSubscription *sub);
+
diff --git a/meta/recipes-extended/gamin/gamin_0.1.10.bb
b/meta/recipes-extended/gamin/gamin_0.1.10.bb
index 080a325..9da7e51 100644
--- a/meta/recipes-extended/gamin/gamin_0.1.10.bb
+++ b/meta/recipes-extended/gamin/gamin_0.1.10.bb
@@ -8,10 +8,11 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=412a9be54757a155d0b997b52b519f62
DEPENDS = glib-2.0
PROVIDES = fam
-PR = r3
+PR = r4
SRC_URI = http://www.gnome.org/~veillard/gamin/sources/gamin-${PV}.tar.gz \
- file://no-abstract-sockets.patch
+ file://no-abstract-sockets.patch \
+ file://noconst.patch
SRC_URI[md5sum] = b4ec549e57da470c04edd5ec2876a028
SRC_URI[sha256sum] =
28085f0ae8be10eab582ff186af4fb0be92cc6c62b5cc19cd09b295c7c2899a1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] GIT_CORE_CONFIG needed? set by default?
All, I was having more issues with git over our proxy (again) and realized we were not setting GIT_CORE_CONFIG. This enables creation of the gitconfig file - otherwise it's not created. I'm not entirely sure if it falls back to the users gitconfig or not - point is I was thinking we should have this set by default so the gitconfig is created for the git related fetching and we can count on a consistent environment when it comes to debugging (we don't want to get messages with git failures only to find out the user has some weird foo in their own gitconfig). Comments? -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] qt4-x11-free: Fix broken regexes in qt4-x11-free's recipe.
From: Wenzong Fan wenzong@windriver.com
[YOCTO #1671]
qt4-x11-free's recipe includes a sed script to sanitize it's .prl files,
which are used by qmake to generate a list of libs and includes in the
Makefiles it generates. It however, fails to take into account the possibility
of trailing slashes, and thus leaves them in, and breaks gcc's syntax.
Update these regexes to account for them.
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
meta/recipes-qt/qt4/qt4.inc | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-qt/qt4/qt4.inc b/meta/recipes-qt/qt4/qt4.inc
index d6382f5..1406a87 100644
--- a/meta/recipes-qt/qt4/qt4.inc
+++ b/meta/recipes-qt/qt4/qt4.inc
@@ -294,13 +294,13 @@ do_install() {
rm -f ${D}/${bindir}/lrelease
# fix pkgconfig, libtool and prl files
- sed -i -e s#-L${S}/lib##g \
- -e s#-L${STAGING_LIBDIR}##g \
+ sed -i -e s#-L${S}/lib/\?##g \
+ -e s#-L${STAGING_LIBDIR}/\?##g \
-e 's#STAGING_LIBDIR}#libdir}'#g \
- -e s#-L${libdir}##g \
+ -e s#-L${libdir}/\?##g \
-e s#'$(OE_QMAKE_LIBS_X11)'#${OE_QMAKE_LIBS_X11}#g \
- -e s# -Wl,-rpath-link,${S}/lib##g \
- -e s# -Wl,-rpath-link,${libdir}##g \
+ -e s# -Wl,-rpath-link,${S}/lib/\?##g \
+ -e s# -Wl,-rpath-link,${libdir}/\?##g \
-e 's#Iin#I${in#g' \
${D}${libdir}/*.la ${D}${libdir}/*.prl
${D}${libdir}/pkgconfig/*.pc
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] qt4-x11-free: Fix broken regexes in qt4-x11-free's recipe.
From: Wenzong Fan wenzong@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(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
