Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
On Wed, Oct 5, 2011 at 09:22, Koen Kooi k...@dominion.thruhere.net wrote: Op 5 okt. 2011 om 07:10 heeft Otavio Salvador ota...@ossystems.com.br het volgende geschreven: On Tue, Oct 4, 2011 at 19:00, Richard Purdie richard.pur...@linuxfoundation.org wrote: Really? hal doesn't really replace udev though, we can just use udev directly in place of it for many things now? Yes, many moved from hal to udev. Specifically which applications are people using with dependencies on hal? As has been pointed out we can fix the xserver and that appears to be the only thing remaining in OE-Core? OE-Core can be easily hal-less but I just ask for hal to not be removed from meta data as I and probably others hasn't finish the move to udev yet. Put it in your own layer if you need it. No point in keeping obsolete stuff in oe-core. I wouldn't call it obsolete as it is still a valid option to Xorg and maybe others. So people might want to use it. I use it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
Op 5 okt. 2011 om 07:27 heeft Otavio Salvador ota...@ossystems.com.br het volgende geschreven: On Wed, Oct 5, 2011 at 09:22, Koen Kooi k...@dominion.thruhere.net wrote: Op 5 okt. 2011 om 07:10 heeft Otavio Salvador ota...@ossystems.com.br het volgende geschreven: On Tue, Oct 4, 2011 at 19:00, Richard Purdie richard.pur...@linuxfoundation.org wrote: Really? hal doesn't really replace udev though, we can just use udev directly in place of it for many things now? Yes, many moved from hal to udev. Specifically which applications are people using with dependencies on hal? As has been pointed out we can fix the xserver and that appears to be the only thing remaining in OE-Core? OE-Core can be easily hal-less but I just ask for hal to not be removed from meta data as I and probably others hasn't finish the move to udev yet. Put it in your own layer if you need it. No point in keeping obsolete stuff in oe-core. I wouldn't call it obsolete as it is still a valid option to Xorg and maybe others. So people might want to use it. I use it. So put it in your own layer, it has no place in oe-core anymore. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
On Wed, Oct 05, 2011 at 07:29:10AM -0500, Koen Kooi wrote:
Op 5 okt. 2011 om 07:27 heeft Otavio Salvador ota...@ossystems.com.br het
volgende geschreven:
On Wed, Oct 5, 2011 at 09:22, Koen Kooi k...@dominion.thruhere.net wrote:
Op 5 okt. 2011 om 07:10 heeft Otavio Salvador ota...@ossystems.com.br
het volgende geschreven:
On Tue, Oct 4, 2011 at 19:00, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Really? hal doesn't really replace udev though, we can just use udev
directly in place of it for many things now?
Yes, many moved from hal to udev.
Specifically which applications are people using with dependencies on
hal? As has been pointed out we can fix the xserver and that appears to
be the only thing remaining in OE-Core?
OE-Core can be easily hal-less but I just ask for hal to not be
removed from meta data as I and probably others hasn't finish the move
to udev yet.
Put it in your own layer if you need it. No point in keeping obsolete
stuff in oe-core.
I wouldn't call it obsolete as it is still a valid option to Xorg and
maybe others. So people might want to use it. I use it.
So put it in your own layer, it has no place in oe-core anymore.
Agreed, that it has no place in oe-core anymore, but not sure if we can
keep
CONFIG_MANAGER_OPTION +=
${@['--disable-config-hal','--enable-config-hal',''][bb.data.getVar('DISTRO_XORG_CONFIG_MANAGER',d)
in ['hal']]}
in xserver-xorg or we'll force averybody with hal in his layer to
.bbappend xserver-xorg too.
Regards,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
On Wed, 2011-10-05 at 14:34 +0200, Martin Jansa wrote:
On Wed, Oct 05, 2011 at 07:29:10AM -0500, Koen Kooi wrote:
Op 5 okt. 2011 om 07:27 heeft Otavio Salvador ota...@ossystems.com.br het
volgende geschreven:
On Wed, Oct 5, 2011 at 09:22, Koen Kooi k...@dominion.thruhere.net
wrote:
Op 5 okt. 2011 om 07:10 heeft Otavio Salvador ota...@ossystems.com.br
het volgende geschreven:
On Tue, Oct 4, 2011 at 19:00, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Really? hal doesn't really replace udev though, we can just use udev
directly in place of it for many things now?
Yes, many moved from hal to udev.
Specifically which applications are people using with dependencies on
hal? As has been pointed out we can fix the xserver and that appears to
be the only thing remaining in OE-Core?
OE-Core can be easily hal-less but I just ask for hal to not be
removed from meta data as I and probably others hasn't finish the move
to udev yet.
Put it in your own layer if you need it. No point in keeping obsolete
stuff in oe-core.
I wouldn't call it obsolete as it is still a valid option to Xorg and
maybe others. So people might want to use it. I use it.
So put it in your own layer, it has no place in oe-core anymore.
Agreed, that it has no place in oe-core anymore, but not sure if we can
keep
CONFIG_MANAGER_OPTION +=
${@['--disable-config-hal','--enable-config-hal',''][bb.data.getVar('DISTRO_XORG_CONFIG_MANAGER',d)
in ['hal']]}
in xserver-xorg or we'll force averybody with hal in his layer to
.bbappend xserver-xorg too.
I don't mind that staying in the xserver recipe config for now, I do
think hal needs to move somewhere other than oe-core though. A
deprecated layer in meta-oe might be one idea which would keep a common
recipe around for now but make it clear its on its way out.
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] Improve handling of 'all' architecture recipes and their interaction with sstate
On Wed, Oct 5, 2011 at 6:02 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2011-10-05 at 14:34 +0200, Martin Jansa wrote:
On Wed, Oct 05, 2011 at 07:29:10AM -0500, Koen Kooi wrote:
Op 5 okt. 2011 om 07:27 heeft Otavio Salvador ota...@ossystems.com.br
het volgende geschreven:
On Wed, Oct 5, 2011 at 09:22, Koen Kooi k...@dominion.thruhere.net
wrote:
Op 5 okt. 2011 om 07:10 heeft Otavio Salvador ota...@ossystems.com.br
het volgende geschreven:
On Tue, Oct 4, 2011 at 19:00, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Really? hal doesn't really replace udev though, we can just use udev
directly in place of it for many things now?
Yes, many moved from hal to udev.
Specifically which applications are people using with dependencies on
hal? As has been pointed out we can fix the xserver and that appears
to
be the only thing remaining in OE-Core?
OE-Core can be easily hal-less but I just ask for hal to not be
removed from meta data as I and probably others hasn't finish the move
to udev yet.
Put it in your own layer if you need it. No point in keeping obsolete
stuff in oe-core.
I wouldn't call it obsolete as it is still a valid option to Xorg and
maybe others. So people might want to use it. I use it.
So put it in your own layer, it has no place in oe-core anymore.
Agreed, that it has no place in oe-core anymore, but not sure if we can
keep
CONFIG_MANAGER_OPTION +=
${@['--disable-config-hal','--enable-config-hal',''][bb.data.getVar('DISTRO_XORG_CONFIG_MANAGER',d)
in ['hal']]}
in xserver-xorg or we'll force averybody with hal in his layer to
.bbappend xserver-xorg too.
I don't mind that staying in the xserver recipe config for now, I do
think hal needs to move somewhere other than oe-core though. A
deprecated layer in meta-oe might be one idea which would keep a common
recipe around for now but make it clear its on its way out.
I think if there are more than one usecases then moving it to
meta-retired or some such
would be ok otherwise I am of opinion that it should be part of distro
layer which wants to use it
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
On Sat, 2011-10-01 at 15:48 -0300, Otavio Salvador wrote: On Fri, Sep 30, 2011 at 14:09, Richard Purdie richard.pur...@linuxfoundation.org wrote: ... Thanks. I've taken the two patches. I'd love to get rid of hal, in fact its on my list of things that need to migrate out of OE-Core... ... From default images this shouldn't be difficult but don't remove hal from oe-core since many embedded OS still use it and haven't migrate to udev or devicekit yet. Really? hal doesn't really replace udev though, we can just use udev directly in place of it for many things now? Specifically which applications are people using with dependencies on hal? As has been pointed out we can fix the xserver and that appears to be the only thing remaining in OE-Core? 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] Improve handling of 'all' architecture recipes and their interaction with sstate
Op 4 okt. 2011 om 17:00 heeft Richard Purdie richard.pur...@linuxfoundation.org het volgende geschreven: On Sat, 2011-10-01 at 15:48 -0300, Otavio Salvador wrote: On Fri, Sep 30, 2011 at 14:09, Richard Purdie richard.pur...@linuxfoundation.org wrote: ... Thanks. I've taken the two patches. I'd love to get rid of hal, in fact its on my list of things that need to migrate out of OE-Core... ... From default images this shouldn't be difficult but don't remove hal from oe-core since many embedded OS still use it and haven't migrate to udev or devicekit yet. Really? hal doesn't really replace udev though, we can just use udev directly in place of it for many things now? Specifically which applications are people using with dependencies on hal? As has been pointed out we can fix the xserver and that appears to be the only thing remaining in OE-Core? Angstrom is completely hal-less nowadays :) Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
On Fri, Sep 30, 2011 at 05:19, Martin Jansa martin.ja...@gmail.com wrote: meta/recipes-support/hal/hal-info.inc | 1 - meta/recipes-support/hal/hal-info_20091130.bb | 2 + meta/recipes-support/hal/hal-info_git.bb | 2 +- ... Please use INC_PR for those. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
On Fri, Sep 30, 2011 at 14:09, Richard Purdie richard.pur...@linuxfoundation.org wrote: ... Thanks. I've taken the two patches. I'd love to get rid of hal, in fact its on my list of things that need to migrate out of OE-Core... ... From default images this shouldn't be difficult but don't remove hal from oe-core since many embedded OS still use it and haven't migrate to udev or devicekit yet. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
From: Richard Purdie richard.pur...@linuxfoundation.org
* Jansa: rebased on current master, added nocompiler patch also to
font-alias, dropped allarch from linux-firmware, gnome-icon-theme, hal-info as
those are checking compiler (ie in intltool check) and better to build
them as default arch instead of rebuilding after every machine
change.
* this is also part of [BUGID# 1075]
* tested except linux-firmware (SRC_URI is offline)
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../resolvconf/resolvconf_1.59.bb |7 ++--
.../update-alternatives-dpkg.inc |5 +--
meta/recipes-gnome/gnome/gnome-common_2.28.0.bb|7 +---
.../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb |5 +--
.../hicolor-icon-theme/hicolor-icon-theme_0.12.bb |6 +--
.../ttf-fonts/liberation-fonts_1.04.bb |5 ++-
.../ttf-fonts/liberation-fonts_1.06.bb |5 ++-
.../ttf-fonts/ttf-bitstream-vera_1.10.bb |5 ++-
.../xcursor-transparent-theme_0.1.1.bb |6 +--
.../xorg-font/encodings/nocompiler.patch | 31
meta/recipes-graphics/xorg-font/encodings_1.0.4.bb |8 +++--
.../xorg-font/font-alias-1.0.3/nocompiler.patch| 30 +++
.../recipes-graphics/xorg-font/font-alias_1.0.3.bb |8 +++--
.../xorg-font/xorg-minimal-fonts.bb|5 ++-
.../linux-firmware/linux-firmware_git.bb |4 +--
.../sato-icon-theme/sato-icon-theme.inc|4 +--
.../sato-icon-theme/sato-icon-theme_0.4.1.bb |2 +
meta/recipes-support/hal/hal-info.inc |1 -
meta/recipes-support/hal/hal-info_20091130.bb |2 +
meta/recipes-support/hal/hal-info_git.bb |2 +-
20 files changed, 102 insertions(+), 46 deletions(-)
create mode 100644 meta/recipes-graphics/xorg-font/encodings/nocompiler.patch
create mode 100644
meta/recipes-graphics/xorg-font/font-alias-1.0.3/nocompiler.patch
diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
b/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
index 94231e0..50252b1 100644
--- a/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
+++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
@@ -11,13 +11,15 @@ AUTHOR = Thomas Hood
HOMEPAGE = http://packages.debian.org/resolvconf;
DEPENDS = bash
RDEPENDS_${PN} = bash
-PR = r0
+PR = r1
SRC_URI = ${DEBIAN_MIRROR}/main/r/resolvconf/resolvconf_${PV}.tar.gz
SRC_URI[md5sum] = 59b20258bb8a3c25b8c4083fc0279547
SRC_URI[sha256sum] =
37691677cea24da66d6664c98668b5f16667c0133f17feb166f246ee923ad756
+inherit allarch
+
do_compile () {
:
}
@@ -31,6 +33,3 @@ do_install () {
install -m 0644 README ${D}${docdir}/${P}/
install -m 0644 man/resolvconf.8 ${D}${mandir}/man8/
}
-
-PACKAGE_ARCH = all
-
diff --git
a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
b/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
index c881ae0..e95a307 100644
--- a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
+++ b/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
@@ -7,10 +7,9 @@ LICENSE = GPL
SECTION = base
SRC_URI = ${DEBIAN_MIRROR}/main/d/dpkg/dpkg_${PV}.tar.bz2
S = ${WORKDIR}/dpkg-${PV}
-PACKAGE_ARCH = all
-INC_PR = r3
+INC_PR = r4
-inherit gettext
+inherit gettext allarch
do_patch () {
cat ${S}/scripts/update-alternatives.pl | \
diff --git a/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
b/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
index 570c45a..8936dbd 100644
--- a/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
+++ b/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
@@ -6,11 +6,8 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
SECTION = x11/gnome
-PR = r0
-inherit gnome
-
-# all isn't appropriate since STAGING_DATADIR is target specific
-# PACKAGE_ARCH=all
+PR = r1
+inherit gnome allarch
# The omf.make file failed if scrollkeeper doesn't happen to be
# installed
diff --git a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
index 55868ab..956c015 100644
--- a/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
+++ b/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
@@ -9,7 +9,7 @@ SECTION = x11/gnome
DEPENDS = icon-naming-utils-native glib-2.0 intltool-native
RDEPENDS_${PN} = hicolor-icon-theme
RRECOMMENDS_${PN} = librsvg-gtk
-PR = r1
+PR = r2
FILES_${PN} += ${datadir}/*
@@ -22,6 +22,3 @@ SRC_URI[sha256sum] =
ea7e05b77ead159379392b3b275ca0c9cbacd7d936014e447cc7c5e27a
EXTRA_OECONF = --disable-hicolor-check
--with-iconmap=${STAGING_LIBDIR_NATIVE}/../libexec/icon-name-mapping
inherit autotools
-
-# We can't do this until the output is shared into all target sysroots
-#PACKAGE_ARCH = all
diff --git
Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
I'd not forgotten about this patch, just been distracted by other
things. I've run some further tests on the changes here and have
comments below. Summary is I think some pieces can merge, other pieces
need more work. Lets try and get the pieces that are ready merged, then
worry about the remainder.
On Fri, 2011-09-30 at 10:19 +0200, Martin Jansa wrote:
From: Richard Purdie richard.pur...@linuxfoundation.org
* Jansa: rebased on current master, added nocompiler patch also to
font-alias, dropped allarch from linux-firmware, gnome-icon-theme, hal-info
as
those are checking compiler (ie in intltool check) and better to build
them as default arch instead of rebuilding after every machine
change.
* this is also part of [BUGID# 1075]
* tested except linux-firmware (SRC_URI is offline)
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../resolvconf/resolvconf_1.59.bb |7 ++--
.../update-alternatives-dpkg.inc |5 +--
meta/recipes-gnome/gnome/gnome-common_2.28.0.bb|7 +---
.../recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb |5 +--
.../hicolor-icon-theme/hicolor-icon-theme_0.12.bb |6 +--
.../ttf-fonts/liberation-fonts_1.04.bb |5 ++-
.../ttf-fonts/liberation-fonts_1.06.bb |5 ++-
.../ttf-fonts/ttf-bitstream-vera_1.10.bb |5 ++-
.../xcursor-transparent-theme_0.1.1.bb |6 +--
.../xorg-font/encodings/nocompiler.patch | 31
meta/recipes-graphics/xorg-font/encodings_1.0.4.bb |8 +++--
.../xorg-font/font-alias-1.0.3/nocompiler.patch| 30 +++
.../recipes-graphics/xorg-font/font-alias_1.0.3.bb |8 +++--
.../xorg-font/xorg-minimal-fonts.bb|5 ++-
.../linux-firmware/linux-firmware_git.bb |4 +--
.../sato-icon-theme/sato-icon-theme.inc|4 +--
.../sato-icon-theme/sato-icon-theme_0.4.1.bb |2 +
meta/recipes-support/hal/hal-info.inc |1 -
meta/recipes-support/hal/hal-info_20091130.bb |2 +
meta/recipes-support/hal/hal-info_git.bb |2 +-
20 files changed, 102 insertions(+), 46 deletions(-)
create mode 100644 meta/recipes-graphics/xorg-font/encodings/nocompiler.patch
create mode 100644
meta/recipes-graphics/xorg-font/font-alias-1.0.3/nocompiler.patch
diff --git a/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
b/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
index 94231e0..50252b1 100644
--- a/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
+++ b/meta/recipes-connectivity/resolvconf/resolvconf_1.59.bb
@@ -11,13 +11,15 @@ AUTHOR = Thomas Hood
HOMEPAGE = http://packages.debian.org/resolvconf;
DEPENDS = bash
RDEPENDS_${PN} = bash
-PR = r0
+PR = r1
SRC_URI = ${DEBIAN_MIRROR}/main/r/resolvconf/resolvconf_${PV}.tar.gz
SRC_URI[md5sum] = 59b20258bb8a3c25b8c4083fc0279547
SRC_URI[sha256sum] =
37691677cea24da66d6664c98668b5f16667c0133f17feb166f246ee923ad756
+inherit allarch
+
do_compile () {
:
}
@@ -31,6 +33,3 @@ do_install () {
install -m 0644 README ${D}${docdir}/${P}/
install -m 0644 man/resolvconf.8 ${D}${mandir}/man8/
}
-
-PACKAGE_ARCH = all
-
resolvconf is fine except we should drop the DEPENDS = bash (the
RDEPENDS is fine).
diff --git
a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
b/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
index c881ae0..e95a307 100644
--- a/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
+++ b/meta/recipes-devtools/update-alternatives/update-alternatives-dpkg.inc
@@ -7,10 +7,9 @@ LICENSE = GPL
SECTION = base
SRC_URI = ${DEBIAN_MIRROR}/main/d/dpkg/dpkg_${PV}.tar.bz2
S = ${WORKDIR}/dpkg-${PV}
-PACKAGE_ARCH = all
-INC_PR = r3
+INC_PR = r4
-inherit gettext
+inherit gettext allarch
do_patch () {
cat ${S}/scripts/update-alternatives.pl | \
This doesn't build.
ERROR: Logfile of failure stored
in:
/media/build1/poky/build/tmp/work/all-poky-linux/update-alternatives-dpkg-1.16.0.3-r4.0/temp/log.do_configure.24532
Log data follows:
| NOTE: Checking autotools environment for common misconfiguration
| ERROR: virtual/gettext required but not in DEPENDS for
file
/media/build1/poky/build/tmp/work/all-poky-linux/update-alternatives-dpkg-1.16.0.3-r4.0/dpkg-1.16.0.3/configure.ac.
| Missing inherit gettext?
diff --git a/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
b/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
index 570c45a..8936dbd 100644
--- a/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
+++ b/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
@@ -6,11 +6,8 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
SECTION = x11/gnome
-PR = r0
-inherit gnome
-
-# all
Re: [OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
On Fri, Sep 30, 2011 at 03:15:15PM +0100, Richard Purdie wrote: I'd not forgotten about this patch, just been distracted by other things. I've run some further tests on the changes here and have comments below. Summary is I think some pieces can merge, other pieces need more work. Lets try and get the pieces that are ready merged, then worry about the remainder. Could we clean out the problematic pieces and resubmit please so we can at least get those pieces in? :) pushed as 6 patches to oe-core-contrib jansa/allarch 1st patch contains changes you've marked as fine 2nd is hal-info, which is imho not worth debugging it as nobody likes hal nowadays (I've tried to patch configure.in, but recipe doesn't call reautoconf IIRC..) the rest is kept as reminder which recipes needs to be taken care of. Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
