Re: [OE-core] [PATCH 3/4] libx11: don't split libX11-xcb out into a libx11-xcb package
Op 10 sep. 2012, om 19:20 heeft Ross Burton ross.bur...@intel.com het volgende geschreven: As XCB is a hard requirement for libX11, and libX11-xcb.so is a deprecated 3KB .so, it's not worth splitting it into a separate package. What's the upgrade path? This commit will create a clash because now 2 packages will provide the same file. Is that pain really worth it? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we have items to check
Op 10 sep. 2012, om 21:09 heeft Matthew McClintock m...@freescale.com het
volgende geschreven:
Right now, we delay running the serial console checks to we boot up. This
causes
issues for read only file systems. So, if have not configured any serial
ports to
check via SERIAL_CONSOLES_CHECK we can skip the check at boot. This fixes any
issues with read only file systems and ipk packaging.
Signed-off-by: Matthew McClintock m...@freescale.com
---
.../sysvinit/sysvinit-inittab_2.88dsf.bb |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index 1089edb..5394f18 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -65,7 +65,11 @@ if [ x$D == x ]; then
done
kill -HUP 1
else
- exit 1
+ if [ ${SERIAL_CONSOLES_CHECK} = ]; then
+ exit 0
+ else
+ exit 1
+ fi
fi
}
MIssing PR bump
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
On Mon, Sep 10, 2012 at 8:11 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
Updating to 3.4.10 which has been soaking for a bit now, as well
as picking up the following meta commits from Tom Z:
a82db2f meta: have systemtap use kprobes and uprobes feature
d5d5b80 meta: add kprobes support to ktypes/standard
b32d373 meta: add kprobes feature
d40ed99 meta: have uprobe feature use uprobe.cfg
a69d1db meta: add uprobe.cfg
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |8
meta/recipes-kernel/linux/linux-yocto_3.4.bb| 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index b2620ea..3b36378 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = standard/preempt-rt/base
KBRANCH_qemuppc = standard/preempt-rt/qemuppc
-LINUX_VERSION ?= 3.4.9
+LINUX_VERSION ?= 3.4.10
LINUX_KERNEL_TYPE = preempt-rt
KMETA = meta
-SRCREV_machine ?= 9032b1e9daf5b4396f939981c3be95f67802d18c
-SRCREV_machine_qemuppc ?= 08ce190232f89303772b6591ca7daaf2820eb74e
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
+SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
+SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 06bcb9a..7258cba 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH_DEFAULT = standard/base
KBRANCH = ${KBRANCH_DEFAULT}
-SRCREV_machine_qemuarm ?= 84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
-SRCREV_machine_qemumips ?= ba0e336d4527080233c3c410989d4f351529ee4e
-SRCREV_machine_qemuppc ?= e82b8a111430e3820b11f507863c4b8e8734ed8e
-SRCREV_machine_qemux86 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine_qemux86-64 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine_qemuarm ?= b15e7b1e9b58b9863bd87778775f86cd8d8880ea
+SRCREV_machine_qemumips ?= 8d5b98f263b5119af2dc30223f311be17173bab9
+SRCREV_machine_qemuppc ?= b9a720ca38d298ed457f37d099c85771f9164b19
+SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
Doesn't different SRCREV_machine for each MACHINE cause LOCALCOUNT in
SRCPV incrementing on each MACHINE switch?
They are stored under same key:
sqlite select * from BB_URI_LOCALCOUNT where key like '%linux-yocto-3.4%';
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_rev|84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_count|16
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_count|9
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_rev|19f7e43b54aef08d58135ed2a897d77b624b320a
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_count|7
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_rev|9032b1e9daf5b4396f939981c3be95f67802d18c
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_count|10
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_count|8
So I guess if you build linux-yocto-3.4 for qemuarm, qemux86-64, then
switch back to qemuarm you'll see linux-yocto built again, same
source, but different SRCPV (LOCALCOUNT).
Cheers,
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sanity.bbclass: Move back to running at ConfigParsed time
On Thu, Sep 6, 2012 at 12:42 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2012-09-05 at 15:21 -0700, Chris Larson wrote: On Wed, Sep 5, 2012 at 7:27 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: If we don't do this, users can get extremely confused errors since the sanity tests happen too late (after parsing) and don't see the warnings. Can you elaborate on this? This commit message is extremely unclear. If there's an open bug in bugzilla or something that could be referred to here, that'd be helpful. Sorry, I should have elaborated. Set an invalid MACHINE, try and build and you set all kinds of nasty warnings and no sensible message about what is wrong. Today with latest oe-core and bitbake I've set MACHINE=pitz (instead of spitz) and the output doesn't look very tidy. Shows couple of DEBUG entries even without debug enabled and then actuall ERROR, see attached log. Cheers, bitbake.log Description: Binary data ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] DEPENDS_virtclass-native = libpng jpeg not extended to libpng-native jpeg-native
Hi, in meta-openembedded/meta-oe/recipes-extended/libwmf/libwmf_0.2.8.4.bb: DEPENDS_virtclass-native = libpng jpeg DEPENDS = libpng jpeg expat gtk+ BBCLASSEXTEND = native Did it work (at least at some point of time) that DEPENDS for libwmf-native were expanded to libpng-native and jpeg-native? Because now it does not: OE tuna@shr ~/shr-core $ bitbake-diffsigs stamps.1347348593/nokia900/x86_64-linux/libwmf-native-0.2.8.4-r1.do_configure.sigdata.315a83efebb27040d6bf0aaead16671e stamps.1347348593/om-gta02/x86_64-linux/libwmf-native-0.2.8.4-r1.do_configure.sigdata.0f8349ada0c8a18a6d6ed7b7841ec955 Hash for dependent task libpng_1.2.49.bb.do_populate_sysroot changed from 640001ee0530e51ef0aefb300c34f7dd to 7ba7d74a27e1e0af253ddac00a2be1c2 Hash for dependent task libjpeg-turbo_svn.bb.do_populate_sysroot changed from 3fe6eae3a6fd1af40233d548680c5bab to ff852ac3d5e826ff74e68b5ddc4ac3e1 So native recipe depending on target checksum - rebuilding with each MACHINE switch. I can fix it by: DEPENDS_virtclass-native = libpng-native jpeg-native but maybe there is more cases like this and this could be checked by native.bbclass or something like that. Cheers, signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] gettext: Make gettext 0.16.1 extend native and nativesdk.
gettext 0.16.1 is a GPLv2 version of gettext. Making that extend native and
nativesdk makes sure we use the same version of gettext for compiling internally
as well as in our toolchain.
Signed-off-by: Martin Ertsaas mert...@cisco.com
---
meta/recipes-core/gettext/gettext_0.16.1.bb |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-core/gettext/gettext_0.16.1.bb
b/meta/recipes-core/gettext/gettext_0.16.1.bb
index fa8a213..00045d5 100644
--- a/meta/recipes-core/gettext/gettext_0.16.1.bb
+++ b/meta/recipes-core/gettext/gettext_0.16.1.bb
@@ -93,3 +93,5 @@ FILES_gettext-runtime-doc = ${mandir}/man1/gettext.* \
do_install_append() {
rm -f ${D}${libdir}/preloadable_libintl.so
}
+
+BBCLASSEXTEND = native nativesdk
--
1.7.8.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] bash: Make bash_3.2.48 a nativesdk package.
3.2.48 is the bash package in oe-core which is not GPLv3. Making that a
nativesdk
package makes sure we have the same bash version in our toolchain as in our
image.
Signed-off-by: Martin Ertsaas mert...@cisco.com
---
meta/recipes-extended/bash/bash_3.2.48.bb |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-extended/bash/bash_3.2.48.bb
b/meta/recipes-extended/bash/bash_3.2.48.bb
index 509d7a0..c317a02 100644
--- a/meta/recipes-extended/bash/bash_3.2.48.bb
+++ b/meta/recipes-extended/bash/bash_3.2.48.bb
@@ -48,3 +48,5 @@ pkg_postinst_${PN} () {
grep -q bin/bash $D${sysconfdir}/shells || echo /bin/bash
$D${sysconfdir}/shells
grep -q bin/sh $D${sysconfdir}/shells || echo /bin/sh
$D${sysconfdir}/shells
}
+
+BBCLASSEXTEND = nativesdk
--
1.7.8.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] DEPENDS_virtclass-native = libpng jpeg not extended to libpng-native jpeg-native
On Tue, 2012-09-11 at 10:03 +0200, Martin Jansa wrote: Hi, in meta-openembedded/meta-oe/recipes-extended/libwmf/libwmf_0.2.8.4.bb: DEPENDS_virtclass-native = libpng jpeg DEPENDS = libpng jpeg expat gtk+ BBCLASSEXTEND = native Did it work (at least at some point of time) that DEPENDS for libwmf-native were expanded to libpng-native and jpeg-native? I don't think that has ever worked. Its assumed that if you're going to use class overrides, you put the right thing in place. Because now it does not: OE tuna@shr ~/shr-core $ bitbake-diffsigs stamps.1347348593/nokia900/x86_64-linux/libwmf-native-0.2.8.4-r1.do_configure.sigdata.315a83efebb27040d6bf0aaead16671e stamps.1347348593/om-gta02/x86_64-linux/libwmf-native-0.2.8.4-r1.do_configure.sigdata.0f8349ada0c8a18a6d6ed7b7841ec955 Hash for dependent task libpng_1.2.49.bb.do_populate_sysroot changed from 640001ee0530e51ef0aefb300c34f7dd to 7ba7d74a27e1e0af253ddac00a2be1c2 Hash for dependent task libjpeg-turbo_svn.bb.do_populate_sysroot changed from 3fe6eae3a6fd1af40233d548680c5bab to ff852ac3d5e826ff74e68b5ddc4ac3e1 So native recipe depending on target checksum - rebuilding with each MACHINE switch. I can fix it by: DEPENDS_virtclass-native = libpng-native jpeg-native but maybe there is more cases like this and this could be checked by native.bbclass or something like that. That is the correct thing to do, the code assumes when you write explicit class overrides, you mean what you say... 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] webkit-gtk: work around Make bug by re-running make
On 10 September 2012 22:23, Colin Walters walt...@verbum.org wrote: On Mon, 2012-09-10 at 17:14 -0400, Colin Walters wrote: On Mon, 2012-09-10 at 17:02 +0100, Ross Burton wrote: +# fixed in Make CVS, so 3.83 won't have this problem. I know this will be painful, but did you consider looking at the make version and determine whether or not this workaround is necessary? Or actually, why not just backport the make patch into core now? I had a branch that added make-replacement-native 3.81 as a dependency of WebKit, but that's far too fragile. An alternative would be to add make-native as part of the bootstrap. At this late stage in the release that's rather invasive. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] libx11: don't split libX11-xcb out into a libx11-xcb package
On 11 September 2012 07:22, Koen Kooi k...@dominion.thruhere.net wrote: What's the upgrade path? This commit will create a clash because now 2 packages will provide the same file. Is that pain really worth it? The pain is just a matter of some dependencies I - again :( - forgot to add. The library disappearing entirely at some glorious point in the future (from the list Martin provided, it looks like libstartup-notification and libpulse are the main offenders) is a good reason to ditch this patch. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] /usr/bin/python is needed by git
I'm not sure where this issue is coming from so I'm just going to dump the output log and see if anyone bites. From what I can tell it is maybe an RPM dependency issue...? WARNING: Host distribution Arch Linux has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Loading cache: 100% |#| ETA: 00:00:00 Loaded 1206 entries from dependency cache. Parsing recipes: 100% |###| Time: 00:00:00 Parsing of 896 .bb files complete (894 cached, 2 parsed). 1205 targets, 57 skipped, 7 masked, 0 errors. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beaglebone DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120911 TUNE_FEATURES = armv7a vfp neon cortexa8 TARGET_FPU= vfp-neon meta meta-yocto= master:7250638ec895bc89508711831083d43b9e1e9826 meta-ti = master:7b54887b9505bb8334bfbe4094a2c396add8da48 meta-db = master:4da6bda041dbbcee2d7464668de280d84c035fa9 NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: kmod: /bin/kmod, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libkmod.so.2 = /usr/lib/libkmod.so.2 (0xdead1000) WARNING: QA Issue: libpam: /lib/security/pam_cracklib.so, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libcrack.so.2 = /usr/lib/libcrack.so.2 (0xdead3000) WARNING: QA Issue: libpam: /lib/security/pam_cracklib.so, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libz.so.1 = /usr/lib/libz.so.1 (0xdead4000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0 (0xdead2000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0xdead3000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libffi.so.5 = /usr/lib/libffi.so.5 (0xdead4000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0xdead5000) WARNING: QA Issue: udev: /lib/udev/udev-acl, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0xdead2000) WARNING: QA Issue: php: Files/directories were installed but not shipped /mnt /mnt/storage /mnt/storage/yoctoBuilds /mnt/storage/yoctoBuilds/poky-beaglebone.git /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/sysroots ERROR: Function failed: do_rootfs (see /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/work/beaglebone-poky-linux-gnueabi/core-image-db-1.0-r0/temp/log.do_rootfs.15968 for further information) ERROR: Logfile of failure stored in: /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/work/beaglebone-poky-linux-gnueabi/core-image-db-1.0-r0/temp/log.do_rootfs.15968 Log data follows: | DEBUG: Executing shell function do_rootfs | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/beaglebone... | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/armv7a_vfp_neon... | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/all... |total: 1 0.00 MB 88.851492 secs |fingerprint: 2487 0.065276 MB 0.731218 secs |install: 829 0.00 MB 67.751171 secs |digest: 1658 11.934144 MB 0.117111 secs |signature:1658 0.00 MB 5.105333 secs |dbadd: 829 0.00 MB 67.590105 secs |dbget: 17782 0.00 MB 0.058949 secs |dbput: 829 6.853944 MB 57.990037 secs |readhdr: 8291 13.578976 MB 3.732102 secs |hdrload: 4452 21.570272 MB 0.088323 secs |hdrget: 159643
[OE-core] [PATCH 1/2] classes/sanity: skip tune checks if machine is invalid
If there is no valid machine configuration it's almost guaranteed that
the tune checks will fail, so just suppress them in that case.
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/classes/sanity.bbclass | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 8f42fca..1210f14 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -320,13 +320,16 @@ def check_sanity(sanity_data):
messages = messages + 'Bitbake version %s is required and version %s
was found\n' % (minversion, bb.__version__)
# Check that the MACHINE is valid, if it is set
+machinevalid = True
if sanity_data.getVar('MACHINE', True):
if not check_conf_exists(conf/machine/${MACHINE}.conf, sanity_data):
messages = messages + 'Please set a valid MACHINE in your
local.conf or environment\n'
+machinevalid = False
else:
messages = messages + check_sanity_validmachine(sanity_data)
else:
messages = messages + 'Please set a MACHINE in your local.conf or
environment\n'
+machinevalid = False
# Check we are using a valid lacal.conf
current_conf = sanity_data.getVar('CONF_VERSION', True)
@@ -428,9 +431,10 @@ def check_sanity(sanity_data):
messages = messages + pseudo_msg + '\n'
check_supported_distro(sanity_data)
-toolchain_msg = check_toolchain(sanity_data)
-if toolchain_msg != :
-messages = messages + toolchain_msg + '\n'
+if machinevalid:
+toolchain_msg = check_toolchain(sanity_data)
+if toolchain_msg != :
+messages = messages + toolchain_msg + '\n'
# Check if DISPLAY is set if IMAGETEST is set
if not sanity_data.getVar( 'DISPLAY', True ) and sanity_data.getVar(
'IMAGETEST', True ) == 'qemu':
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] sanity.bbclass: Move back to running at ConfigParsed time
On Tuesday 11 September 2012 08:39:39 Martin Jansa wrote: Today with latest oe-core and bitbake I've set MACHINE=pitz (instead of spitz) and the output doesn't look very tidy. Shows couple of DEBUG entries even without debug enabled and then actuall ERROR, see attached log. I've just sent a patch to the bitbake list that fixes this, as well as a patch to the OE-Core list that gets rid of the not particularly useful tune check failures when MACHINE is invalid. 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] connman: remove trailing whitespace
Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/recipes-connectivity/connman/connman.inc |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/connman/connman.inc b/meta/recipes-connectivity/connman/connman.inc index 59ec1fa..5b94a1e 100644 --- a/meta/recipes-connectivity/connman/connman.inc +++ b/meta/recipes-connectivity/connman/connman.inc @@ -1,5 +1,5 @@ SUMMARY = A daemon for managing internet connections within embedded devices -DESCRIPTION = The ConnMan project provides a daemon for managing \ +DESCRIPTION = The ConnMan project provides a daemon for managing \ internet connections within embedded devices running the Linux \ operating system. The Connection Manager is designed to be slim and \ to use as few resources as possible, so it can be easily integrated. \ -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] bash: Make bash_3.2.48 a nativesdk package.
On 09/11/12 10:29, Martin Ertsaas wrote:
3.2.48 is the bash package in oe-core which is not GPLv3. Making that a
nativesdk
package makes sure we have the same bash version in our toolchain as in our
image.
Signed-off-by: Martin Ertsaas mert...@cisco.com
---
meta/recipes-extended/bash/bash_3.2.48.bb |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-extended/bash/bash_3.2.48.bb
b/meta/recipes-extended/bash/bash_3.2.48.bb
index 509d7a0..c317a02 100644
--- a/meta/recipes-extended/bash/bash_3.2.48.bb
+++ b/meta/recipes-extended/bash/bash_3.2.48.bb
@@ -48,3 +48,5 @@ pkg_postinst_${PN} () {
grep -q bin/bash $D${sysconfdir}/shells || echo /bin/bash
$D${sysconfdir}/shells
grep -q bin/sh $D${sysconfdir}/shells || echo /bin/sh
$D${sysconfdir}/shells
}
+
+BBCLASSEXTEND = nativesdk
This can be ignored. Just found out that this bash does not like to be a
nativesdk package. It fails with
./mkbuiltins: error while loading shared libraries: __vdso_gettimeofday:
invalid mode for dlopen(): Invalid argument
Any idea what this might be, so I can fix the patch.
Sorry for sending this before it was actually ready.
- Martin
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] opkg svn: Add the --force-arch option
Hi All, Thank you very much for your suggestions, do we have a final solution or work around please? If we refer to the rpm, it doesn't care about the package's version, it just selects the newest build package, I had applied a patch to make it respect to the arch before. It seems that we have no good solution for the PREFERRED_VERSION pkg during the package installation, what does the package management system knows is the arch's priority, the PREFERRED_VERSION pkg always has a higher priority than others in the feed. So maybe respect to the arch is the only way that we have current. I'd like to submit such a patch if you are OK with it: Let the arch priority win the higher version is the default way for opkg, and add an option (--select-higher-version) for it to make the higher version win the arch priority, so that the user can have another choice. // Robert On 09/09/2012 04:40 AM, Paul Eggleton wrote: On Saturday 08 September 2012 21:08:55 Phil Blundell wrote: a) for people who are not using O_P_M, it's becoming apparent that the whole concept of using opkg (or rpm, or any other external package manager) for rootfs construction is more of a liability than an asset because bitbake has more knowledge about which particular binaries ought to be installed. For those use-cases, it might be better to think in terms of abolishing opkg altogether which would solve this problem and a variety of others. On the other hand, using the package manager for rootfs construction for those that *are* using online package management allows us to have at least some confidence that a rootfs produced directly from the metadata and one produced by on-system upgrades will be the same; you can also have package management on in one image and off in another (or change it on the fly) and expect to have the same contents, apart from the package manager being removed. The potential for subtle differences in behaviour is too great to go down the path of implementing it ourselves IMO, not to mention the extra code paths to maintain. b) for people who _are_ using O_P_M, specifying --force-arch during rootfs construction is all very well but they might still lose during a subsequent opkg upgrade. So for these use cases, it seems as though something a bit more sticky might be required. In terms of a proper solution I agree with this - opkg needs to handle the package architecture configuration internally rather than us overriding it at rootfs construction time. If you're advocating spending effort implementing something I think that's where it should be spent. Cheers, Paul ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
On Tue, Sep 11, 2012 at 08:31:42AM -0400, Bruce Ashfield wrote:
On 12-09-11 02:59 AM, Martin Jansa wrote:
On Mon, Sep 10, 2012 at 8:11 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
Updating to 3.4.10 which has been soaking for a bit now, as well
as picking up the following meta commits from Tom Z:
a82db2f meta: have systemtap use kprobes and uprobes feature
d5d5b80 meta: add kprobes support to ktypes/standard
b32d373 meta: add kprobes feature
d40ed99 meta: have uprobe feature use uprobe.cfg
a69d1db meta: add uprobe.cfg
Signed-off-by: Bruce Ashfieldbruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |8
meta/recipes-kernel/linux/linux-yocto_3.4.bb| 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index b2620ea..3b36378 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = standard/preempt-rt/base
KBRANCH_qemuppc = standard/preempt-rt/qemuppc
-LINUX_VERSION ?= 3.4.9
+LINUX_VERSION ?= 3.4.10
LINUX_KERNEL_TYPE = preempt-rt
KMETA = meta
-SRCREV_machine ?= 9032b1e9daf5b4396f939981c3be95f67802d18c
-SRCREV_machine_qemuppc ?= 08ce190232f89303772b6591ca7daaf2820eb74e
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
+SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
+SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 06bcb9a..7258cba 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH_DEFAULT = standard/base
KBRANCH = ${KBRANCH_DEFAULT}
-SRCREV_machine_qemuarm ?= 84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
-SRCREV_machine_qemumips ?= ba0e336d4527080233c3c410989d4f351529ee4e
-SRCREV_machine_qemuppc ?= e82b8a111430e3820b11f507863c4b8e8734ed8e
-SRCREV_machine_qemux86 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine_qemux86-64 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine_qemuarm ?= b15e7b1e9b58b9863bd87778775f86cd8d8880ea
+SRCREV_machine_qemumips ?= 8d5b98f263b5119af2dc30223f311be17173bab9
+SRCREV_machine_qemuppc ?= b9a720ca38d298ed457f37d099c85771f9164b19
+SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
Doesn't different SRCREV_machine for each MACHINE cause LOCALCOUNT in
SRCPV incrementing on each MACHINE switch?
They are stored under same key:
sqlite select * from BB_URI_LOCALCOUNT where key like '%linux-yocto-3.4%';
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_rev|84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_count|16
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_count|9
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_rev|19f7e43b54aef08d58135ed2a897d77b624b320a
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_count|7
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_rev|9032b1e9daf5b4396f939981c3be95f67802d18c
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_count|10
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_count|8
So I guess if you build linux-yocto-3.4 for qemuarm, qemux86-64, then
switch back to qemuarm you'll see linux-yocto built again, same
source, but different SRCPV (LOCALCOUNT).
That does look to be the case, and it matches what I've observed
over time. I'm not sure of an alternative at the moment, since the
fetcher is such a cranky beast with respect to fetching changes to
the right machine branches.
Why not remove it from SRCREV_FORMAT, keep only meta SRCPV and just bump
PR when SRCREV of some machine kbranch is changed?
Current SRCREV_FORMAT doesn't show which branch it was so it
[OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
Hi,
when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz)
or -mtune=arm926ej-s (when built for qemuarm).
From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine, you are
expected to use a different PACKAGE_ARCH. If you do that, you will get a
different package feed for the different binaries, different WORKDIR and so on.
This was always the way the package architectures was intended to work and
nothing has changed there. Yes, you as the user changing various variables can
create inconsistent package feeds. There are 101 ways you can do that, the
simple answer is just don't. We're therefore unlikely to add MACHINE to
DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended.
Does qemuarm use oe-core as it's intended?
Shouldn't spitz produce something like armv5te-xscale and qemuarm
armv5te-arm926ejs?
It would cause all recipes to build again (cannot share armv5te feed anymore),
but at least it would build it and user will really get it on target, right now
opkg upgrade can download some packages with xscale some with arm926ej-s.
$ ~/bitbake/bin/bitbake-diffsigs
stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc
stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14
basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to
d8dd2ff8613d0aafe60bef1a1e9469a1
Variable TUNE_CCARGS value changed from
${@bb.utils.contains(TUNE_FEATURES, armv5,
-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}, , d)}
${@bb.utils.contains(TUNE_FEATURES, armv4,
-march=armv4${ARMPKGSFX_THUMB}, , d)}
${@bb.utils.contains(TUNE_FEATURES, thumb, ${ARM_THUMB_M_OPT}, , d)}
${@bb.utils.contains(TUNE_FEATURES, no-thumb-interwork,
-mno-thumb-interwork, -mthumb-interwork, d)}
${@bb.utils.contains(TUNE_FEATURES, vfp,
bb.utils.contains(TUNE_FEATURES, callconvention-hard, -mfloat-abi=hard,
-mfloat-abi=softfp, d), ,d)}
${@bb.utils.contains(TUNE_FEATURES, xscale, -mtune=xscale, , d)}
to
${@bb.utils.contains(TUNE_FEATURES, armv5,
-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}, , d)}
${@bb.utils.contains(TUNE_FEATURES, armv4,
-march=armv4${ARMPKGSFX_THUMB}, , d)}
${@bb.utils.contains(TUNE_FEATURES, thumb, ${ARM_THUMB_M_OPT}, , d)}
${@bb.utils.contains(TUNE_FEATURES, no-thumb-interwork,
-mno-thumb-interwork, -mthumb-interwork, d)}
${@bb.utils.contains(TUNE_FEATURES, vfp,
bb.utils.contains(TUNE_FEATURES, callconvention-hard, -mfloat-abi=hard,
-mfloat-abi=softfp, d), ,d)}
${@bb.utils.contains(TUNE_FEATURES, arm926ejs, -mtune=arm926ej-s, ,
d)}
--
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] /usr/bin/python is needed by git
On 9/11/12 4:34 AM, Jack Mitchell wrote: I'm not sure where this issue is coming from so I'm just going to dump the output log and see if anyone bites. From what I can tell it is maybe an RPM dependency issue...? WARNING: Host distribution Arch Linux has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Loading cache: 100% |#| ETA: 00:00:00 Loaded 1206 entries from dependency cache. Parsing recipes: 100% |###| Time: 00:00:00 Parsing of 896 .bb files complete (894 cached, 2 parsed). 1205 targets, 57 skipped, 7 masked, 0 errors. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beaglebone DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120911 TUNE_FEATURES = armv7a vfp neon cortexa8 TARGET_FPU= vfp-neon meta meta-yocto= master:7250638ec895bc89508711831083d43b9e1e9826 meta-ti = master:7b54887b9505bb8334bfbe4094a2c396add8da48 meta-db = master:4da6bda041dbbcee2d7464668de280d84c035fa9 NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: kmod: /bin/kmod, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libkmod.so.2 = /usr/lib/libkmod.so.2 (0xdead1000) WARNING: QA Issue: libpam: /lib/security/pam_cracklib.so, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libcrack.so.2 = /usr/lib/libcrack.so.2 (0xdead3000) WARNING: QA Issue: libpam: /lib/security/pam_cracklib.so, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libz.so.1 = /usr/lib/libz.so.1 (0xdead4000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0 (0xdead2000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0xdead3000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libffi.so.5 = /usr/lib/libffi.so.5 (0xdead4000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0xdead5000) WARNING: QA Issue: udev: /lib/udev/udev-acl, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0xdead2000) WARNING: QA Issue: php: Files/directories were installed but not shipped /mnt /mnt/storage /mnt/storage/yoctoBuilds /mnt/storage/yoctoBuilds/poky-beaglebone.git /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/sysroots ERROR: Function failed: do_rootfs (see /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/work/beaglebone-poky-linux-gnueabi/core-image-db-1.0-r0/temp/log.do_rootfs.15968 for further information) ERROR: Logfile of failure stored in: /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/work/beaglebone-poky-linux-gnueabi/core-image-db-1.0-r0/temp/log.do_rootfs.15968 Log data follows: | DEBUG: Executing shell function do_rootfs | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/beaglebone... | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/armv7a_vfp_neon... | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/all... |total: 1 0.00 MB 88.851492 secs |fingerprint: 2487 0.065276 MB 0.731218 secs |install: 829 0.00 MB 67.751171 secs |digest: 1658 11.934144 MB 0.117111 secs |signature:1658 0.00 MB 5.105333 secs |dbadd: 829 0.00 MB 67.590105 secs |dbget: 17782 0.00 MB 0.058949 secs |dbput: 829 6.853944 MB 57.990037 secs |readhdr: 8291 13.578976 MB 3.732102 secs |hdrload: 4452 21.570272 MB 0.088323 secs |hdrget
Re: [OE-core] [PATCH 1/1] linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
On 12-09-11 08:37 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 08:31:42AM -0400, Bruce Ashfield wrote:
On 12-09-11 02:59 AM, Martin Jansa wrote:
On Mon, Sep 10, 2012 at 8:11 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
Updating to 3.4.10 which has been soaking for a bit now, as well
as picking up the following meta commits from Tom Z:
a82db2f meta: have systemtap use kprobes and uprobes feature
d5d5b80 meta: add kprobes support to ktypes/standard
b32d373 meta: add kprobes feature
d40ed99 meta: have uprobe feature use uprobe.cfg
a69d1db meta: add uprobe.cfg
Signed-off-by: Bruce Ashfieldbruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |8
meta/recipes-kernel/linux/linux-yocto_3.4.bb| 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index b2620ea..3b36378 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = standard/preempt-rt/base
KBRANCH_qemuppc = standard/preempt-rt/qemuppc
-LINUX_VERSION ?= 3.4.9
+LINUX_VERSION ?= 3.4.10
LINUX_KERNEL_TYPE = preempt-rt
KMETA = meta
-SRCREV_machine ?= 9032b1e9daf5b4396f939981c3be95f67802d18c
-SRCREV_machine_qemuppc ?= 08ce190232f89303772b6591ca7daaf2820eb74e
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
+SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
+SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 06bcb9a..7258cba 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH_DEFAULT = standard/base
KBRANCH = ${KBRANCH_DEFAULT}
-SRCREV_machine_qemuarm ?= 84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
-SRCREV_machine_qemumips ?= ba0e336d4527080233c3c410989d4f351529ee4e
-SRCREV_machine_qemuppc ?= e82b8a111430e3820b11f507863c4b8e8734ed8e
-SRCREV_machine_qemux86 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine_qemux86-64 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine_qemuarm ?= b15e7b1e9b58b9863bd87778775f86cd8d8880ea
+SRCREV_machine_qemumips ?= 8d5b98f263b5119af2dc30223f311be17173bab9
+SRCREV_machine_qemuppc ?= b9a720ca38d298ed457f37d099c85771f9164b19
+SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
Doesn't different SRCREV_machine for each MACHINE cause LOCALCOUNT in
SRCPV incrementing on each MACHINE switch?
They are stored under same key:
sqlite select * from BB_URI_LOCALCOUNT where key like '%linux-yocto-3.4%';
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_rev|84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_count|16
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_count|9
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_rev|19f7e43b54aef08d58135ed2a897d77b624b320a
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_count|7
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_rev|9032b1e9daf5b4396f939981c3be95f67802d18c
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_count|10
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_count|8
So I guess if you build linux-yocto-3.4 for qemuarm, qemux86-64, then
switch back to qemuarm you'll see linux-yocto built again, same
source, but different SRCPV (LOCALCOUNT).
That does look to be the case, and it matches what I've observed
over time. I'm not sure of an alternative at the moment, since the
fetcher is such a cranky beast with respect to fetching changes to
the right machine branches.
Why not remove it from SRCREV_FORMAT, keep only meta SRCPV and just bump
PR when SRCREV of some machine kbranch is changed?
I like the sound of it, but as far as I know, wouldn't that fix the
package revision, but cause the fetcher problems ? I've added Richard
to the cc, since I'm
Re: [OE-core] [PATCH 1/1] linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
On Tue, Sep 11, 2012 at 09:27:50AM -0400, Bruce Ashfield wrote:
On 12-09-11 08:37 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 08:31:42AM -0400, Bruce Ashfield wrote:
On 12-09-11 02:59 AM, Martin Jansa wrote:
On Mon, Sep 10, 2012 at 8:11 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
Updating to 3.4.10 which has been soaking for a bit now, as well
as picking up the following meta commits from Tom Z:
a82db2f meta: have systemtap use kprobes and uprobes feature
d5d5b80 meta: add kprobes support to ktypes/standard
b32d373 meta: add kprobes feature
d40ed99 meta: have uprobe feature use uprobe.cfg
a69d1db meta: add uprobe.cfg
Signed-off-by: Bruce Ashfieldbruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |8
meta/recipes-kernel/linux/linux-yocto_3.4.bb| 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index b2620ea..3b36378 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = standard/preempt-rt/base
KBRANCH_qemuppc = standard/preempt-rt/qemuppc
-LINUX_VERSION ?= 3.4.9
+LINUX_VERSION ?= 3.4.10
LINUX_KERNEL_TYPE = preempt-rt
KMETA = meta
-SRCREV_machine ?= 9032b1e9daf5b4396f939981c3be95f67802d18c
-SRCREV_machine_qemuppc ?= 08ce190232f89303772b6591ca7daaf2820eb74e
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
+SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
+SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 06bcb9a..7258cba 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH_DEFAULT = standard/base
KBRANCH = ${KBRANCH_DEFAULT}
-SRCREV_machine_qemuarm ?= 84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
-SRCREV_machine_qemumips ?= ba0e336d4527080233c3c410989d4f351529ee4e
-SRCREV_machine_qemuppc ?= e82b8a111430e3820b11f507863c4b8e8734ed8e
-SRCREV_machine_qemux86 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine_qemux86-64 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine_qemuarm ?= b15e7b1e9b58b9863bd87778775f86cd8d8880ea
+SRCREV_machine_qemumips ?= 8d5b98f263b5119af2dc30223f311be17173bab9
+SRCREV_machine_qemuppc ?= b9a720ca38d298ed457f37d099c85771f9164b19
+SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
Doesn't different SRCREV_machine for each MACHINE cause LOCALCOUNT in
SRCPV incrementing on each MACHINE switch?
They are stored under same key:
sqlite select * from BB_URI_LOCALCOUNT where key like
'%linux-yocto-3.4%';
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_rev|84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_count|16
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_count|9
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_rev|19f7e43b54aef08d58135ed2a897d77b624b320a
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_count|7
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_rev|9032b1e9daf5b4396f939981c3be95f67802d18c
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_count|10
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_count|8
So I guess if you build linux-yocto-3.4 for qemuarm, qemux86-64, then
switch back to qemuarm you'll see linux-yocto built again, same
source, but different SRCPV (LOCALCOUNT).
That does look to be the case, and it matches what I've observed
over time. I'm not sure of an alternative at the moment, since the
fetcher is such a cranky beast with respect to fetching changes to
the right machine branches.
Why not remove it from SRCREV_FORMAT, keep only
Re: [OE-core] /usr/bin/python is needed by git
On 11/09/12 14:04, Mark Hatle wrote: On 9/11/12 4:34 AM, Jack Mitchell wrote: I'm not sure where this issue is coming from so I'm just going to dump the output log and see if anyone bites. From what I can tell it is maybe an RPM dependency issue...? WARNING: Host distribution Arch Linux has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Loading cache: 100% |#| ETA: 00:00:00 Loaded 1206 entries from dependency cache. Parsing recipes: 100% |###| Time: 00:00:00 Parsing of 896 .bb files complete (894 cached, 2 parsed). 1205 targets, 57 skipped, 7 masked, 0 errors. Build Configuration: BB_VERSION= 1.15.3 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = beaglebone DISTRO= poky DISTRO_VERSION= 1.2+snapshot-20120911 TUNE_FEATURES = armv7a vfp neon cortexa8 TARGET_FPU= vfp-neon meta meta-yocto= master:7250638ec895bc89508711831083d43b9e1e9826 meta-ti = master:7b54887b9505bb8334bfbe4094a2c396add8da48 meta-db = master:4da6bda041dbbcee2d7464668de280d84c035fa9 NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: kmod: /bin/kmod, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libkmod.so.2 = /usr/lib/libkmod.so.2 (0xdead1000) WARNING: QA Issue: libpam: /lib/security/pam_cracklib.so, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libcrack.so.2 = /usr/lib/libcrack.so.2 (0xdead3000) WARNING: QA Issue: libpam: /lib/security/pam_cracklib.so, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libz.so.1 = /usr/lib/libz.so.1 (0xdead4000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0 (0xdead2000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0xdead3000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libffi.so.5 = /usr/lib/libffi.so.5 (0xdead4000) WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0xdead5000) WARNING: QA Issue: udev: /lib/udev/udev-acl, installed in the base_prefix, requires a shared library under exec_prefix (/usr): libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0xdead2000) WARNING: QA Issue: php: Files/directories were installed but not shipped /mnt /mnt/storage /mnt/storage/yoctoBuilds /mnt/storage/yoctoBuilds/poky-beaglebone.git /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/sysroots ERROR: Function failed: do_rootfs (see /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/work/beaglebone-poky-linux-gnueabi/core-image-db-1.0-r0/temp/log.do_rootfs.15968 for further information) ERROR: Logfile of failure stored in: /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/work/beaglebone-poky-linux-gnueabi/core-image-db-1.0-r0/temp/log.do_rootfs.15968 Log data follows: | DEBUG: Executing shell function do_rootfs | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/beaglebone... | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/armv7a_vfp_neon... | Generating solve db for /mnt/storage/yoctoBuilds/poky-beaglebone.git/beaglebone-db/tmp/deploy/rpm/all... |total: 1 0.00 MB 88.851492 secs |fingerprint: 2487 0.065276 MB 0.731218 secs |install: 829 0.00 MB 67.751171 secs |digest: 1658 11.934144 MB 0.117111 secs |signature:1658 0.00 MB 5.105333 secs |dbadd: 829 0.00 MB 67.590105 secs |dbget: 17782 0.00 MB 0.058949 secs |dbput: 829 6.853944 MB 57.990037 secs |readhdr: 8291 13.578976 MB 3.732102 secs |hdrload
[OE-core] [PATCH] nativesdk-qemu: fix SDK relocation issue
User mode emulation binaries are linked using a local linker script. The
nativesdk ones were not used and the resulting binaries did not have the
interp section resized. Hence, those binaries could not be relocated.
[YOCTO #3083]
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
.../qemu/qemu-1.2.0/relocatable_sdk.patch | 34
meta/recipes-devtools/qemu/qemu_1.2.0.bb |4 +++
2 files changed, 38 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu-1.2.0/relocatable_sdk.patch
diff --git a/meta/recipes-devtools/qemu/qemu-1.2.0/relocatable_sdk.patch
b/meta/recipes-devtools/qemu/qemu-1.2.0/relocatable_sdk.patch
new file mode 100644
index 000..0a01a8a
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu-1.2.0/relocatable_sdk.patch
@@ -0,0 +1,34 @@
+Upstream-Status: Inappropriate [SDK specific]
+
+In order to be able to change the dynamic loader path when relocating
+binaries, the interp section has to be made big enough to accomodate
+the new path (4096 is the maximum path length in Linux).
+
+Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
+
+Index: qemu-1.2.0/i386.ld
+===
+--- qemu-1.2.0.orig/i386.ld
qemu-1.2.0/i386.ld
+@@ -8,7 +8,7 @@ SECTIONS
+ {
+ /* Read-only sections, merged into text segment: */
+ . = 0x6000 + SIZEOF_HEADERS;
+- .interp : { *(.interp) }
++ .interp : { *(.interp); . = 0x1000; }
+ .hash : { *(.hash) }
+ .dynsym: { *(.dynsym) }
+ .dynstr: { *(.dynstr) }
+Index: qemu-1.2.0/x86_64.ld
+===
+--- qemu-1.2.0.orig/x86_64.ld
qemu-1.2.0/x86_64.ld
+@@ -6,7 +6,7 @@ SECTIONS
+ {
+ /* Read-only sections, merged into text segment: */
+ . = 0x6000 + SIZEOF_HEADERS;
+- .interp : { *(.interp) }
++ .interp : { *(.interp); . = 0x1000; }
+ .hash : { *(.hash) }
+ .dynsym : { *(.dynsym) }
+ .dynstr : { *(.dynstr) }
diff --git a/meta/recipes-devtools/qemu/qemu_1.2.0.bb
b/meta/recipes-devtools/qemu/qemu_1.2.0.bb
index 55ac532..636a666 100644
--- a/meta/recipes-devtools/qemu/qemu_1.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_1.2.0.bb
@@ -17,6 +17,10 @@ SRC_URI = \
SRC_URI[md5sum] = 78eb1e984f4532aa9f2bdd3c127b5b61
SRC_URI[sha256sum] =
c8b84420d9f4869397f84cad2dabd9a475b7723d619a924a873740353e9df936
+SRC_URI_append_virtclass-nativesdk = \
+file://relocatable_sdk.patch \
+
+
do_configure_prepend_virtclass-nativesdk() {
if [ ${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} = ]
; then
# Undo the -lX11 added by linker-flags.patch
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote:
Hi,
when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz)
or -mtune=arm926ej-s (when built for qemuarm).
From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine, you are
expected to use a different PACKAGE_ARCH. If you do that, you will get a
different package feed for the different binaries, different WORKDIR and so
on. This was always the way the package architectures was intended to work
and nothing has changed there. Yes, you as the user changing various
variables can create inconsistent package feeds. There are 101 ways you can
do that, the simple answer is just don't. We're therefore unlikely to add
MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its
intended.
Does qemuarm use oe-core as it's intended?
CCing bluelightning because xscale is used in lot of meta-handheld machines:
Does this make sense?
OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr tune-arm926*;
diff -uNr tune-xscale.inc*
--- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200
+++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200
@@ -8,4 +8,4 @@
AVAILTUNES += arm926ejs
TUNE_FEATURES_tune-arm926ejs = ${TUNE_FEATURES_tune-armv5te} arm926ejs
PACKAGE_EXTRA_ARCHS_tune-arm926ejs = ${PACKAGE_EXTRA_ARCHS_tune-armv5te}
-
+TUNE_PKGARCH_tune-arm926ejs = armv5te-arm926ejs
--- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200
+++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200
@@ -8,10 +8,12 @@
AVAILTUNES += xscale
TUNE_FEATURES_tune-xscale = ${TUNE_FEATURES_tune-armv5te} xscale
PACKAGE_EXTRA_ARCHS_tune-xscale = ${PACKAGE_EXTRA_ARCHS_tune-armv5te}
+TUNE_PKGARCH_tune-xscale = armv5te-xscale
AVAILTUNES += xscale-be
TUNE_FEATURES_tune-xscale-be = ${TUNE_FEATURES_tune-armv5teb} xscale
bigendian
PACKAGE_EXTRA_ARCHS_tune-xscale-be = ${PACKAGE_EXTRA_ARCHS_tune-armv5teb}
+TUNE_PKGARCH_tune-xscale-be = armv5teb-xscale
# webkit-gtk has alignment issues with double instructions on armv5 so
# disable them here
Shouldn't spitz produce something like armv5te-xscale and qemuarm
armv5te-arm926ejs?
It would cause all recipes to build again (cannot share armv5te feed anymore),
but at least it would build it and user will really get it on target, right
now
opkg upgrade can download some packages with xscale some with arm926ej-s.
$ ~/bitbake/bin/bitbake-diffsigs
stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc
stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14
basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to
d8dd2ff8613d0aafe60bef1a1e9469a1
Variable TUNE_CCARGS value changed from
${@bb.utils.contains(TUNE_FEATURES, armv5,
-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}, , d)}
${@bb.utils.contains(TUNE_FEATURES, armv4,
-march=armv4${ARMPKGSFX_THUMB}, , d)}
${@bb.utils.contains(TUNE_FEATURES, thumb, ${ARM_THUMB_M_OPT}, , d)}
${@bb.utils.contains(TUNE_FEATURES, no-thumb-interwork,
-mno-thumb-interwork, -mthumb-interwork, d)}
${@bb.utils.contains(TUNE_FEATURES, vfp,
bb.utils.contains(TUNE_FEATURES, callconvention-hard, -mfloat-abi=hard,
-mfloat-abi=softfp, d), ,d)}
${@bb.utils.contains(TUNE_FEATURES, xscale, -mtune=xscale, , d)}
to
${@bb.utils.contains(TUNE_FEATURES, armv5,
-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}, , d)}
${@bb.utils.contains(TUNE_FEATURES, armv4,
-march=armv4${ARMPKGSFX_THUMB}, , d)}
${@bb.utils.contains(TUNE_FEATURES, thumb, ${ARM_THUMB_M_OPT}, , d)}
${@bb.utils.contains(TUNE_FEATURES, no-thumb-interwork,
-mno-thumb-interwork, -mthumb-interwork, d)}
${@bb.utils.contains(TUNE_FEATURES, vfp,
bb.utils.contains(TUNE_FEATURES, callconvention-hard, -mfloat-abi=hard,
-mfloat-abi=softfp, d), ,d)}
${@bb.utils.contains(TUNE_FEATURES, arm926ejs, -mtune=arm926ej-s, ,
d)}
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 0/1] Fix nativesdk-qemu relocation issue
Changes in V2: - bump PR Thanks, Laurentiu The following changes since commit 7250638ec895bc89508711831083d43b9e1e9826: upstream_tracking: Fix format issues (2012-09-10 23:21:12 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lpalcu/qemu_issue http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/qemu_issue Laurentiu Palcu (1): nativesdk-qemu: fix SDK relocation issue .../qemu/qemu-1.2.0/relocatable_sdk.patch | 34 meta/recipes-devtools/qemu/qemu_1.2.0.bb |6 2 files changed, 40 insertions(+) create mode 100644 meta/recipes-devtools/qemu/qemu-1.2.0/relocatable_sdk.patch -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libgpg-error: Use the source file for the licence checksum
It makes sense to us the license checksum from the source .in file rather than that from the generated file which configure can change (or remove). Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- diff --git a/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb b/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb index 8186236..64b50b9 100644 --- a/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb +++ b/meta/recipes-support/libgpg-error/libgpg-error_1.10.bb @@ -5,7 +5,7 @@ BUGTRACKER = https://bugs.g10code.com/gnupg/index; LICENSE = GPLv2+ LGPLv2.1+ LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \ file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \ - file://src/gpg-error.h;endline=23;md5=83c16c8f5cea85affa1ff270a6f4fcff \ + file://src/gpg-error.h.in;endline=23;md5=508c78081f11544da0fbb8c95913a301 \ file://src/init.c;endline=20;md5=b69742f2a8827d494c6f6a4b1768416c ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] arch-ia32: Add x32 to MACHINEOVERRIDES
This will allow the KERNEL_FEATURES to trigger the x32 ABI via overrides
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/machine/include/ia32/arch-ia32.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
b/meta/conf/machine/include/ia32/arch-ia32.inc
index 15f67d7..fa70e57 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -24,6 +24,7 @@ ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES,
mx32, x32, ,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -mx32, , d)}
TUNE_LDARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -m
elf32_x86_64, , d)}
TUNE_ASARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -x32, , d)}
+MACHINEOVERRIDES .= ${@bb.utils.contains(TUNE_FEATURES, mx32, :x32,
,d)}
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] libgnome-keyring: add missing DEPENDS on intltool-native
From: Jackie Huang jackie.hu...@windriver.com The following changes since commit 48169c6bc44c546cecaa06207b6c36da558b81f7: classes/packageinfo: use better method to check if package exists (2012-09-10 21:52:37 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/bug3081_libgnome-kering_0911 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/bug3081_libgnome-kering_0911 Jackie Huang (1): libgnome-keyring: add missing DEPENDS on intltool-native .../recipes-gnome/gnome/libgnome-keyring_2.32.0.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] libgnome-keyring: add missing DEPENDS on intltool-native
From: Jackie Huang jackie.hu...@windriver.com libgnome-keyring requires command 'intltoolize' in configure, so add DEPENDS intltool-native. [YOCTO #3081] Signed-off-by: Jackie Huang jackie.hu...@windriver.com --- .../recipes-gnome/gnome/libgnome-keyring_2.32.0.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb b/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb index cf18732..8ed44f3 100644 --- a/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb +++ b/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb @@ -9,11 +9,11 @@ LIC_FILES_CHKSUM = file://COPYING;md5=0914b9d3ebaba41ef2e3e0ae16f296cf \ file://egg/egg-dh.h;endline=22;md5=1626c16af2a8da1f88324cf3ced33f08 SECTION = x11/gnome/libs -PR = r2 +PR = r3 inherit gnome gtk-doc -DEPENDS = dbus libgcrypt glib-2.0 +DEPENDS = dbus libgcrypt glib-2.0 intltool-native SRC_URI[archive.md5sum] = c42b2ca66204835d901d3dbfc1fa5ae6 SRC_URI[archive.sha256sum] = 56388c0d81ddfdb57d30e4963c83ecc1c18498aab99395420e0fff69929a0f0c -- 1.7.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] arch-ia32: Add x32 to MACHINEOVERRIDES
On Tue, 2012-09-11 at 08:07 -0700, Saul Wold wrote:
This will allow the KERNEL_FEATURES to trigger the x32 ABI via overrides
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/machine/include/ia32/arch-ia32.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
b/meta/conf/machine/include/ia32/arch-ia32.inc
index 15f67d7..fa70e57 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -24,6 +24,7 @@ ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES,
mx32, x32, ,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -mx32, ,
d)}
TUNE_LDARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -m
elf32_x86_64, , d)}
TUNE_ASARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -x32, ,
d)}
+MACHINEOVERRIDES .= ${@bb.utils.contains(TUNE_FEATURES, mx32, :x32,
,d)}
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
This is just for the kernel issue, right?
In that case, just use ${@bb.utils.contains(TUNE_FEATURES, mx32,
, ,d)} in the kernel recipe code...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] linux-yocto: x32 and features update
Richard/Saul, This is my part of a change that Saul will complete with the addition of x32 as a machine override for x86 BSPs that have x32 as their tuning. With this change, the x32 configuration fragment will be appended to any give x86 BSP configuration and it will support the userspace tuning. Also bundled with this change is an associated change to not have the linux-yocto recipes directly assign KERNEL_FEATURES, but instead always append to the variable. This allows features like x32 to be tested by setting the variable in a local.conf or machine .conf file. Cheers, Bruce cc: Saul Wold saul.w...@intel.com The following changes since commit cc8bfedabfe61a0e06a8a8199f8c0fce4738260a: linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates (2012-09-10 14:05:15 -0400) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/x32 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/x32 Bruce Ashfield (2): linux-yocto*: append to KERNEL_FEATURES instead of assigning linux-yocto/3.4: add x32 configuration fragment and tuning hook meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb |2 +- meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb |2 +- meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |5 +++-- meta/recipes-kernel/linux/linux-yocto_3.0.bb|2 +- meta/recipes-kernel/linux/linux-yocto_3.2.bb|2 +- meta/recipes-kernel/linux/linux-yocto_3.4.bb|5 +++-- 6 files changed, 10 insertions(+), 8 deletions(-) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] linux-yocto*: append to KERNEL_FEATURES instead of assigning
It is sometimes useful for KERNEL_FEATURES to be set in a machine or other configuration file. The linux-yocto recipes currently initialize the variable, which clobbers any values set by .conf files. Appending to the variables allows these settings to propagate to the kernel configuration, while maintaining the existing set of added kernel features. 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-rt_3.2.bb |2 +- meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |2 +- meta/recipes-kernel/linux/linux-yocto_3.0.bb|2 +- meta/recipes-kernel/linux/linux-yocto_3.2.bb|2 +- meta/recipes-kernel/linux/linux-yocto_3.4.bb|2 +- 6 files changed, 6 insertions(+), 6 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 a16b549..0cdc7c0 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb @@ -22,7 +22,7 @@ SRC_URI = git://git.yoctoproject.org/linux-yocto-3.0.git;protocol=git;bareclone COMPATIBLE_MACHINE = (qemux86|qemux86-64|qemuarm) # Functionality flags -KERNEL_FEATURES = features/netfilter +KERNEL_FEATURES_append = features/netfilter KERNEL_FEATURES_append = features/taskstats KERNEL_FEATURES_append_qemux86 = cfg/sound KERNEL_FEATURES_append_qemux86-64 = cfg/sound diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb index 05362ef..a3900ce 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb @@ -23,7 +23,7 @@ SRC_URI = git://git.yoctoproject.org/linux-yocto-3.2.git;protocol=git;bareclone COMPATIBLE_MACHINE = (qemux86|qemux86-64|qemuarm) # Functionality flags -KERNEL_FEATURES = features/netfilter +KERNEL_FEATURES_append = features/netfilter KERNEL_FEATURES_append = features/taskstats KERNEL_FEATURES_append_qemux86 = cfg/sound KERNEL_FEATURES_append_qemux86-64 = cfg/sound diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb index 3b36378..4fd3845 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb @@ -23,7 +23,7 @@ SRC_URI = git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;bareclone COMPATIBLE_MACHINE = (qemux86|qemux86-64|qemuarm) # Functionality flags -KERNEL_FEATURES = features/netfilter +KERNEL_FEATURES_append = features/netfilter KERNEL_FEATURES_append = features/taskstats KERNEL_FEATURES_append_qemux86 = cfg/sound KERNEL_FEATURES_append_qemux86-64 = cfg/sound diff --git a/meta/recipes-kernel/linux/linux-yocto_3.0.bb b/meta/recipes-kernel/linux/linux-yocto_3.0.bb index d16cdf0..e917beb 100644 --- a/meta/recipes-kernel/linux/linux-yocto_3.0.bb +++ b/meta/recipes-kernel/linux/linux-yocto_3.0.bb @@ -27,7 +27,7 @@ SRC_URI = git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;b COMPATIBLE_MACHINE = qemuarm|qemux86|qemuppc|qemumips|qemux86-64 # Functionality flags -KERNEL_FEATURES = features/netfilter +KERNEL_FEATURES_append = features/netfilter KERNEL_FEATURES_append = features/taskstats KERNEL_FEATURES_append_qemux86 = cfg/sound KERNEL_FEATURES_append_qemux86-64 = cfg/sound diff --git a/meta/recipes-kernel/linux/linux-yocto_3.2.bb b/meta/recipes-kernel/linux/linux-yocto_3.2.bb index ba4b536..45414d5 100644 --- a/meta/recipes-kernel/linux/linux-yocto_3.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto_3.2.bb @@ -27,7 +27,7 @@ SRC_URI = git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;bareclone=1;b COMPATIBLE_MACHINE = qemuarm|qemux86|qemuppc|qemumips|qemux86-64 # Functionality flags -KERNEL_FEATURES=features/netfilter +KERNEL_FEATURES_append= features/netfilter KERNEL_FEATURES_append= features/taskstats KERNEL_FEATURES_append_qemux86= cfg/sound KERNEL_FEATURES_append_qemux86-64= cfg/sound diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb b/meta/recipes-kernel/linux/linux-yocto_3.4.bb index 7258cba..59ad4b2 100644 --- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb @@ -24,6 +24,6 @@ COMPATIBLE_MACHINE = qemuarm|qemux86|qemuppc|qemumips|qemux86-64 # Functionality flags KERNEL_REVISION_CHECKING= -KERNEL_FEATURES=features/netfilter +KERNEL_FEATURES_append = features/netfilter KERNEL_FEATURES_append_qemux86= cfg/sound KERNEL_FEATURES_append_qemux86-64= cfg/sound -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb|3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
\ No newline at end of file
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 59ad4b2..bcd1292 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -9,7 +9,7 @@ SRCREV_machine_qemuppc ?=
b9a720ca38d298ed457f37d099c85771f9164b19
SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
-SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
@@ -27,3 +27,4 @@ KERNEL_REVISION_CHECKING=
KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append_qemux86= cfg/sound
KERNEL_FEATURES_append_qemux86-64= cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb|3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
Scratch this bit and below, as I think I will use the other mechanism
you talked about to go from a .conf file.
Sau!
\ No newline at end of file
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 59ad4b2..bcd1292 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -9,7 +9,7 @@ SRCREV_machine_qemuppc ?=
b9a720ca38d298ed457f37d099c85771f9164b19
SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
-SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
@@ -27,3 +27,4 @@ KERNEL_REVISION_CHECKING=
KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append_qemux86= cfg/sound
KERNEL_FEATURES_append_qemux86-64= cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] arch-ia32: Add x32 to MACHINEOVERRIDES
On 09/11/2012 08:13 AM, Richard Purdie wrote:
On Tue, 2012-09-11 at 08:07 -0700, Saul Wold wrote:
This will allow the KERNEL_FEATURES to trigger the x32 ABI via overrides
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/machine/include/ia32/arch-ia32.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
b/meta/conf/machine/include/ia32/arch-ia32.inc
index 15f67d7..fa70e57 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -24,6 +24,7 @@ ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, mx32, x32,
,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -mx32, ,
d)}
TUNE_LDARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -m elf32_x86_64,
, d)}
TUNE_ASARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -x32, , d)}
+MACHINEOVERRIDES .= ${@bb.utils.contains(TUNE_FEATURES, mx32, :x32,
,d)}
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
This is just for the kernel issue, right?
In that case, just use ${@bb.utils.contains(TUNE_FEATURES, mx32,
, ,d)} in the kernel recipe code...
It's possible that there will be other recipes that need patches or
other changes in the future, but I guess we can cross that bridge when
we come to it.
I think I will actually use the features update that Bruce just added
from here instead. Since multiple BSP could take advantage of x32 we
should not have to edit each of there kernel recipes. It should just be
enabled based on the x32 DEFAULTTUNE.
Thanks
Sau!
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 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
On 12-09-11 11:33 AM, Saul Wold wrote:
On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
Scratch this bit and below, as I think I will use the other mechanism
you talked about to go from a .conf file.
Works for me. The meta change is staged and pushed out, I'll update this
patch to not have the KERNEL_FEATURES portion.
Bruce
Sau!
\ No newline at end of file
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 59ad4b2..bcd1292 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -9,7 +9,7 @@ SRCREV_machine_qemuppc ?=
b9a720ca38d298ed457f37d099c85771f9164b19
SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
-SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
@@ -27,3 +27,4 @@ KERNEL_REVISION_CHECKING=
KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append_qemux86= cfg/sound
KERNEL_FEATURES_append_qemux86-64= cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
On 09/11/2012 08:39 AM, Bruce Ashfield wrote:
On 12-09-11 11:33 AM, Saul Wold wrote:
On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
Scratch this bit and below, as I think I will use the other mechanism
you talked about to go from a .conf file.
Works for me. The meta change is staged and pushed out, I'll update this
patch to not have the KERNEL_FEATURES portion.
Thanks, see my other email to RP, since x32 is a feature that any x86-64
machine might want to enable based on the DEFAULTTUNE it makes more
sense to be in the machine config includes.
Sau!
Bruce
Sau!
\ No newline at end of file
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 59ad4b2..bcd1292 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -9,7 +9,7 @@ SRCREV_machine_qemuppc ?=
b9a720ca38d298ed457f37d099c85771f9164b19
SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
-SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
@@ -27,3 +27,4 @@ KERNEL_REVISION_CHECKING=
KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append_qemux86= cfg/sound
KERNEL_FEATURES_append_qemux86-64= cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
___
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] git: add missing Python dependency
On 9/11/12 5:33 AM, Jack Mitchell wrote: From: Jack Mitchell jack.mitch...@dbbroadcast.co.uk Add python to DEPENDS as it fails to install on target with RPM failing at do_rootfs due to un-met dependencies. Signed-off-by: Jack Mitchell jack.mitch...@dbbroadcast.co.uk --- meta/recipes-devtools/git/git.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/git/git.inc b/meta/recipes-devtools/git/git.inc index 6748b70..9181da6 100644 --- a/meta/recipes-devtools/git/git.inc +++ b/meta/recipes-devtools/git/git.inc @@ -1,7 +1,7 @@ DESCRIPTION = The git revision control system used by the Linux kernel developers SECTION = console/utils LICENSE = GPLv2 -DEPENDS = openssl curl zlib expat +DEPENDS = openssl curl zlib expat python I think this depends is needed based on some easy evaluation of git. git (at least git-native) provides one example python script, and some python modules.. these should be broken off into other sub packages to help eliminate the -runtime- python requirement (I'm assuming they're both optional for general git usage) But someone with more knowledge with git then me should go that. --Mark PROVIDES_append_virtclass-native = git-replacement-native ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
On 9/11/12 8:48 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote:
Hi,
when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz)
or -mtune=arm926ej-s (when built for qemuarm).
I argued this when we original did the work for the tunings, and I lost
From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine, you are
expected to use a different PACKAGE_ARCH. If you do that, you will get a
different package feed for the different binaries, different WORKDIR and so on.
This was always the way the package architectures was intended to work and
nothing has changed there. Yes, you as the user changing various variables can
create inconsistent package feeds. There are 101 ways you can do that, the
simple answer is just don't. We're therefore unlikely to add MACHINE to
DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended.
That is certainly my expectation. I'm not sure that the arm926ej-s can produce
binaries that are -not- arm5te binaries -- as that seems to be the standard for
what an armv5te is. The xscale on the other hand is capable of having different
tuning parameters and had a few additional instructions. In the past I've
generated a tuning simple called xscale that was compatible w/ armv5te. This
way you could share non-optimized things, and go w/ xscale as necessary.
Does qemuarm use oe-core as it's intended?
CCing bluelightning because xscale is used in lot of meta-handheld machines:
Does this make sense?
OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr tune-arm926*;
diff -uNr tune-xscale.inc*
--- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200
+++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200
@@ -8,4 +8,4 @@
AVAILTUNES += arm926ejs
TUNE_FEATURES_tune-arm926ejs = ${TUNE_FEATURES_tune-armv5te} arm926ejs
PACKAGE_EXTRA_ARCHS_tune-arm926ejs = ${PACKAGE_EXTRA_ARCHS_tune-armv5te}
-
+TUNE_PKGARCH_tune-arm926ejs = armv5te-arm926ejs
I'd suggest simply arm926ejs
--- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200
+++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200
@@ -8,10 +8,12 @@
AVAILTUNES += xscale
TUNE_FEATURES_tune-xscale = ${TUNE_FEATURES_tune-armv5te} xscale
PACKAGE_EXTRA_ARCHS_tune-xscale = ${PACKAGE_EXTRA_ARCHS_tune-armv5te}
+TUNE_PKGARCH_tune-xscale = armv5te-xscale
Again simplify to xscale
AVAILTUNES += xscale-be
TUNE_FEATURES_tune-xscale-be = ${TUNE_FEATURES_tune-armv5teb} xscale
bigendian
PACKAGE_EXTRA_ARCHS_tune-xscale-be = ${PACKAGE_EXTRA_ARCHS_tune-armv5teb}
+TUNE_PKGARCH_tune-xscale-be = armv5teb-xscale
And xscaleeb (or be)
--Mark
# webkit-gtk has alignment issues with double instructions on armv5 so
# disable them here
Shouldn't spitz produce something like armv5te-xscale and qemuarm
armv5te-arm926ejs?
It would cause all recipes to build again (cannot share armv5te feed anymore),
but at least it would build it and user will really get it on target, right now
opkg upgrade can download some packages with xscale some with arm926ej-s.
$ ~/bitbake/bin/bitbake-diffsigs
stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc
stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14
basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to
d8dd2ff8613d0aafe60bef1a1e9469a1
Variable TUNE_CCARGS value changed from
${@bb.utils.contains(TUNE_FEATURES, armv5,
-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}, , d)}
${@bb.utils.contains(TUNE_FEATURES, armv4, -march=armv4${ARMPKGSFX_THUMB},
, d)}
${@bb.utils.contains(TUNE_FEATURES, thumb, ${ARM_THUMB_M_OPT}, , d)}
${@bb.utils.contains(TUNE_FEATURES, no-thumb-interwork, -mno-thumb-interwork,
-mthumb-interwork, d)}
${@bb.utils.contains(TUNE_FEATURES, vfp, bb.utils.contains(TUNE_FEATURES, callconvention-hard,
-mfloat-abi=hard, -mfloat-abi=softfp, d), ,d)}
${@bb.utils.contains(TUNE_FEATURES, xscale, -mtune=xscale, , d)}
to
${@bb.utils.contains(TUNE_FEATURES, armv5,
-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}, , d)}
${@bb.utils.contains(TUNE_FEATURES, armv4, -march=armv4${ARMPKGSFX_THUMB},
, d)}
${@bb.utils.contains(TUNE_FEATURES, thumb, ${ARM_THUMB_M_OPT}, , d)}
${@bb.utils.contains(TUNE_FEATURES, no-thumb-interwork, -mno-thumb-interwork,
-mthumb-interwork, d)}
${@bb.utils.contains(TUNE_FEATURES, vfp, bb.utils.contains(TUNE_FEATURES, callconvention-hard,
-mfloat-abi=hard, -mfloat-abi=softfp, d), ,d)}
${@bb.utils.contains(TUNE_FEATURES, arm926ejs, -mtune=arm926ej-s, ,
d)}
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
Openembedded-core mailing list
Re: [OE-core] [PATCH] arch-ia32: Add x32 to MACHINEOVERRIDES
On 9/11/12 10:36 AM, Saul Wold wrote:
On 09/11/2012 08:13 AM, Richard Purdie wrote:
On Tue, 2012-09-11 at 08:07 -0700, Saul Wold wrote:
This will allow the KERNEL_FEATURES to trigger the x32 ABI via overrides
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/machine/include/ia32/arch-ia32.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
b/meta/conf/machine/include/ia32/arch-ia32.inc
index 15f67d7..fa70e57 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -24,6 +24,7 @@ ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES, mx32, x32,
,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -mx32, ,
d)}
TUNE_LDARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -m elf32_x86_64,
, d)}
TUNE_ASARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -x32, ,
d)}
+MACHINEOVERRIDES .= ${@bb.utils.contains(TUNE_FEATURES, mx32, :x32,
,d)}
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
This is just for the kernel issue, right?
In that case, just use ${@bb.utils.contains(TUNE_FEATURES, mx32,
, ,d)} in the kernel recipe code...
It's possible that there will be other recipes that need patches or
other changes in the future, but I guess we can cross that bridge when
we come to it.
I think I will actually use the features update that Bruce just added
from here instead. Since multiple BSP could take advantage of x32 we
should not have to edit each of there kernel recipes. It should just be
enabled based on the x32 DEFAULTTUNE.
I know there are a few other things that can (and should) change behavior based
on the x32 flag.. but flag or override, it just changes slightly the
implementation mechanism -- either should work as long as we consistently use it.
--Mark
Thanks
Sau!
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] arch-ia32: Add x32 to MACHINEOVERRIDES
On Tue, 2012-09-11 at 08:36 -0700, Saul Wold wrote:
On 09/11/2012 08:13 AM, Richard Purdie wrote:
On Tue, 2012-09-11 at 08:07 -0700, Saul Wold wrote:
This will allow the KERNEL_FEATURES to trigger the x32 ABI via overrides
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/machine/include/ia32/arch-ia32.inc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
b/meta/conf/machine/include/ia32/arch-ia32.inc
index 15f67d7..fa70e57 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -24,6 +24,7 @@ ABIEXTENSION .= ${@bb.utils.contains(TUNE_FEATURES,
mx32, x32, ,d)}
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -mx32,
, d)}
TUNE_LDARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -m
elf32_x86_64, , d)}
TUNE_ASARGS += ${@bb.utils.contains(TUNE_FEATURES, mx32, -x32,
, d)}
+MACHINEOVERRIDES .= ${@bb.utils.contains(TUNE_FEATURES, mx32,
:x32, ,d)}
# ELF64 ABI
TUNEVALID[m64] = IA32e (x86_64) ELF64 standard ABI
This is just for the kernel issue, right?
In that case, just use ${@bb.utils.contains(TUNE_FEATURES, mx32,
, ,d)} in the kernel recipe code...
It's possible that there will be other recipes that need patches or
other changes in the future, but I guess we can cross that bridge when
we come to it.
I think I will actually use the features update that Bruce just added
from here instead. Since multiple BSP could take advantage of x32 we
should not have to edit each of there kernel recipes. It should just be
enabled based on the x32 DEFAULTTUNE.
No, no, no. DEFAULTTUNE is a really bad idea for these kind of
decisions, what if x32 is one of the other tunes enabled?
You're not the first person to use DEFAULTTUNE like this recently and
its not what its intended for at all :/.
Also, the kernel features are specific to linux-yocto so you can't use
them from a core ABI file.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we have items to check
Right now, we delay running the serial console checks to we boot up. This causes
issues for read only file systems. So, if have not configured any serial ports
to
check via SERIAL_CONSOLES_CHECK we can skip the check at boot. This fixes any
issues with read only file systems and ipk packaging.
Signed-off-by: Matthew McClintock m...@freescale.com
---
v2: bump PR
.../sysvinit/sysvinit-inittab_2.88dsf.bb |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index 1089edb..ec27b8c 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -2,7 +2,7 @@ DESCRIPTION = Inittab for sysvinit
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
-PR = r7
+PR = r8
SRC_URI = file://inittab
@@ -65,7 +65,11 @@ if [ x$D == x ]; then
done
kill -HUP 1
else
- exit 1
+ if [ ${SERIAL_CONSOLES_CHECK} = ]; then
+ exit 0
+ else
+ exit 1
+ fi
fi
}
--
1.7.9.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
On Tue, 2012-09-11 at 08:41 -0700, Saul Wold wrote:
On 09/11/2012 08:39 AM, Bruce Ashfield wrote:
On 12-09-11 11:33 AM, Saul Wold wrote:
On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
Scratch this bit and below, as I think I will use the other mechanism
you talked about to go from a .conf file.
Works for me. The meta change is staged and pushed out, I'll update this
patch to not have the KERNEL_FEATURES portion.
Thanks, see my other email to RP, since x32 is a feature that any x86-64
machine might want to enable based on the DEFAULTTUNE it makes more
sense to be in the machine config includes.
No, it doesn't.
What we need here is:
-KERNEL_FEATURES_append = features/taskstats
+KERNEL_FEATURES_append = features/taskstats
${@bb.utils.contains(TUNE_FEATURES, mx32, cfg/x32, ,d)}
which is simple, effective and to the point. If we start needing lots of
these, we can look at an x32 override but right now I don't see the
need.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, Sep 11, 2012 at 10:51:40AM -0500, Mark Hatle wrote:
On 9/11/12 8:48 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote:
Hi,
when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz)
or -mtune=arm926ej-s (when built for qemuarm).
I argued this when we original did the work for the tunings, and I lost
From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine, you
are expected to use a different PACKAGE_ARCH. If you do that, you will get
a different package feed for the different binaries, different WORKDIR and
so on. This was always the way the package architectures was intended to
work and nothing has changed there. Yes, you as the user changing various
variables can create inconsistent package feeds. There are 101 ways you
can do that, the simple answer is just don't. We're therefore unlikely to
add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as
its intended.
That is certainly my expectation. I'm not sure that the arm926ej-s can
produce
binaries that are -not- arm5te binaries -- as that seems to be the standard
for
what an armv5te is. The xscale on the other hand is capable of having
different
tuning parameters and had a few additional instructions. In the past I've
generated a tuning simple called xscale that was compatible w/ armv5te.
This
way you could share non-optimized things, and go w/ xscale as necessary.
Few more comments I did on IRC:
16:41:23 JaMa let's hope RP will comment on that as that was his comment I
was copypasting
16:41:53 JaMa e.g. ppc seems to set TUNE_PKGARCH for each tune-*
16:44:24 JaMa but it would be better to set xscale/arm926 tune only for
packages where such -mtune brings some speedup (and for those where we set
PACKAGE_ARCH = MACHINE_ARCH already) and build the rest only with -march
16:45:36 JaMa but mixed feed and -mtune=xscale packages on arm926 targets
looks like worst case
16:50:20 JaMa oe-classic had the same issue with mixed -mtune in package
arch feeds, but at least it wasn't rebuilding them after each machine switch
And I'm not sure where we could decide what's worth -mtune and what is not,
because in recipe we can do it only with a lot of _arch overrides and in tune
file with lot of _pn-foo overrides (and some could be also in other layers then
oe-core etc.)
But it would be nice to share most packages as general armv5te between e.g.
spitz and qemuarm builds.
Cheers,
Does qemuarm use oe-core as it's intended?
CCing bluelightning because xscale is used in lot of meta-handheld machines:
Does this make sense?
OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr
tune-arm926*; diff -uNr tune-xscale.inc*
--- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200
+++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200
@@ -8,4 +8,4 @@
AVAILTUNES += arm926ejs
TUNE_FEATURES_tune-arm926ejs = ${TUNE_FEATURES_tune-armv5te} arm926ejs
PACKAGE_EXTRA_ARCHS_tune-arm926ejs = ${PACKAGE_EXTRA_ARCHS_tune-armv5te}
-
+TUNE_PKGARCH_tune-arm926ejs = armv5te-arm926ejs
I'd suggest simply arm926ejs
--- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200
+++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200
@@ -8,10 +8,12 @@
AVAILTUNES += xscale
TUNE_FEATURES_tune-xscale = ${TUNE_FEATURES_tune-armv5te} xscale
PACKAGE_EXTRA_ARCHS_tune-xscale = ${PACKAGE_EXTRA_ARCHS_tune-armv5te}
+TUNE_PKGARCH_tune-xscale = armv5te-xscale
Again simplify to xscale
AVAILTUNES += xscale-be
TUNE_FEATURES_tune-xscale-be = ${TUNE_FEATURES_tune-armv5teb} xscale
bigendian
PACKAGE_EXTRA_ARCHS_tune-xscale-be =
${PACKAGE_EXTRA_ARCHS_tune-armv5teb}
+TUNE_PKGARCH_tune-xscale-be = armv5teb-xscale
And xscaleeb (or be)
--Mark
# webkit-gtk has alignment issues with double instructions on armv5 so
# disable them here
Shouldn't spitz produce something like armv5te-xscale and qemuarm
armv5te-arm926ejs?
It would cause all recipes to build again (cannot share armv5te feed
anymore),
but at least it would build it and user will really get it on target,
right now
opkg upgrade can download some packages with xscale some with arm926ej-s.
$ ~/bitbake/bin/bitbake-diffsigs
stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc
stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14
basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to
d8dd2ff8613d0aafe60bef1a1e9469a1
Variable TUNE_CCARGS value changed from
${@bb.utils.contains(TUNE_FEATURES, armv5,
Re: [OE-core] [PATCH 2/2] linux-yocto/3.4: add x32 configuration fragment and tuning hook
On 09/11/2012 08:58 AM, Richard Purdie wrote:
On Tue, 2012-09-11 at 08:41 -0700, Saul Wold wrote:
On 09/11/2012 08:39 AM, Bruce Ashfield wrote:
On 12-09-11 11:33 AM, Saul Wold wrote:
On 09/11/2012 08:17 AM, Bruce Ashfield wrote:
When x32 is the tuning for a x86 MACHINE, the kernel should also have
CONFIG_X86_X32=y.
This can be accomplished by adding the x32 configuraion fragment to the
KERNEL_FEATURES when x32 is the tuning for a given machine.
cc: Saul Wold s...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 3 ++-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index 4fd3845..156fb93 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -10,7 +10,7 @@ KMETA = meta
SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
-SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
+SRCREV_meta ?= e0374ce012e7e6fc8e5bb8b957addb0478950898
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
@@ -27,3 +27,4 @@ KERNEL_FEATURES_append = features/netfilter
KERNEL_FEATURES_append = features/taskstats
KERNEL_FEATURES_append_qemux86 = cfg/sound
KERNEL_FEATURES_append_qemux86-64 = cfg/sound
+KERNEL_FEATURES_append_x32 = cfg/x32
Scratch this bit and below, as I think I will use the other mechanism
you talked about to go from a .conf file.
Works for me. The meta change is staged and pushed out, I'll update this
patch to not have the KERNEL_FEATURES portion.
Thanks, see my other email to RP, since x32 is a feature that any x86-64
machine might want to enable based on the DEFAULTTUNE it makes more
sense to be in the machine config includes.
No, it doesn't.
What we need here is:
-KERNEL_FEATURES_append = features/taskstats
+KERNEL_FEATURES_append = features/taskstats ${@bb.utils.contains(TUNE_FEATURES, mx32,
cfg/x32, ,d)}
No, this would then only address the qemu machine, what about all the HW
BSP that might want it, they would need to add this same line. If I add
the KERNEL_FEATURES_append to the arch-ia32.inc, conditional on mx32,
then any x86-64 BSP can just enable that TUNE, isn't that the point of
the machine config tuning?
which is simple, effective and to the point. If we start needing lots of
these, we can look at an x32 override but right now I don't see the
need.
And it does not have to be an x32 override, we just set it in the
arch-ia32.inc file where we define that TUNE.
That seems the best way.
Sau!
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 1/1] image_types.bbclass: Round up ROOTFS_SIZE after base_size check
On 09/10/2012 11:18 AM, Andrei Gherzan wrote:
If we round up ROOTFS_SIZE to IMAGE_ROOTFS_ALIGNMENT before checking if
base_size is greater then IMAGE_ROOTFS_SIZE, we can end up adding an
unaligned value to IMAGE_ROOTFS_SIZE. Obviously, if
IMAGE_ROOTFS_EXTRA_SPACE was overwritten with an unaligned value. So
let's add the round up code after the base_size calculus and it's
comparison.
Signed-off-by: Andrei Gherzan and...@gherzan.ro
---
meta/classes/image_types.bbclass |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index d286eea..0bd7a6f 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -82,9 +82,13 @@ runimagecmd () {
# The base_size gets calculated:
# - initial size determined by `du -ks` of the IMAGE_ROOTFS
# - then multiplied by the IMAGE_OVERHEAD_FACTOR
- # - then rounded up to IMAGE_ROOTFS_ALIGNMENT
# - finally tested against IMAGE_ROOTFS_SIZE
- ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR} + ${IMAGE_ROOTFS_ALIGNMENT} - 1; base_size -= base_size %
${IMAGE_ROOTFS_ALIGNMENT}; print ((base_size ${IMAGE_ROOTFS_SIZE} ? base_size
: ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+ ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{base_size = $1 *
${IMAGE_OVERHEAD_FACTOR}; print ((base_size ${IMAGE_ROOTFS_SIZE} ? base_size
: ${IMAGE_ROOTFS_SIZE}) + ${IMAGE_ROOTFS_EXTRA_SPACE}) }'`
+
+ # Round up ROOTFS_SIZE to IMAGE_ROOTFS_ALIGNMENT
+ ROOTFS_SIZE=`expr ${ROOTFS_SIZE} + ${IMAGE_ROOTFS_ALIGNMENT} - 1`
+ ROOTFS_SIZE=`expr ${ROOTFS_SIZE} - ${ROOTFS_SIZE} %
${IMAGE_ROOTFS_ALIGNMENT}`
+
I saw a new expr failure on rootfs this morning testing with this patch,
I have to dig into it to figure out what went wrong.
Sau!
${cmd}
# Now create the needed compressed versions
cd ${DEPLOY_DIR_IMAGE}/
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
On 9/11/12 10:59 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 10:51:40AM -0500, Mark Hatle wrote:
On 9/11/12 8:48 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote:
Hi,
when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz)
or -mtune=arm926ej-s (when built for qemuarm).
I argued this when we original did the work for the tunings, and I lost
From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine, you are
expected to use a different PACKAGE_ARCH. If you do that, you will get a
different package feed for the different binaries, different WORKDIR and so on.
This was always the way the package architectures was intended to work and
nothing has changed there. Yes, you as the user changing various variables can
create inconsistent package feeds. There are 101 ways you can do that, the
simple answer is just don't. We're therefore unlikely to add MACHINE to
DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended.
That is certainly my expectation. I'm not sure that the arm926ej-s can produce
binaries that are -not- arm5te binaries -- as that seems to be the standard for
what an armv5te is. The xscale on the other hand is capable of having different
tuning parameters and had a few additional instructions. In the past I've
generated a tuning simple called xscale that was compatible w/ armv5te. This
way you could share non-optimized things, and go w/ xscale as necessary.
Few more comments I did on IRC:
16:41:23 JaMa let's hope RP will comment on that as that was his comment I was
copypasting
16:41:53 JaMa e.g. ppc seems to set TUNE_PKGARCH for each tune-*
16:44:24 JaMa but it would be better to set xscale/arm926 tune only for
packages where such -mtune brings some speedup (and for those where we set
PACKAGE_ARCH = MACHINE_ARCH already) and build the rest only with -march
16:45:36 JaMa but mixed feed and -mtune=xscale packages on arm926 targets
looks like worst case
16:50:20 JaMa oe-classic had the same issue with mixed -mtune in package
arch feeds, but at least it wasn't rebuilding them after each machine switch
And I'm not sure where we could decide what's worth -mtune and what is not,
because in recipe we can do it only with a lot of _arch overrides and in tune
file with lot of _pn-foo overrides (and some could be also in other layers then
oe-core etc.)
But it would be nice to share most packages as general armv5te between e.g.
spitz and qemuarm builds.
This really hints that defining the tunings become a distribution configuration.
You should be able to do:
DEFAULTTUNE_pn-openssl = xscale
To enable just openssl benefits from the xscale tunings. (The pn- may not be
needed.. I can never remember anymore...) But that was the original idea with
the tunings, make a way to specify DEFAULTTUNE for various things when
alternative, but compatible tunings made a difference... set that in the
distro.conf and you have an optimized distribution for specific uses. (You of
course could also move that to a machine setting or similar file.)
--Mark
Cheers,
Does qemuarm use oe-core as it's intended?
CCing bluelightning because xscale is used in lot of meta-handheld machines:
Does this make sense?
OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr tune-arm926*;
diff -uNr tune-xscale.inc*
--- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200
+++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200
@@ -8,4 +8,4 @@
AVAILTUNES += arm926ejs
TUNE_FEATURES_tune-arm926ejs = ${TUNE_FEATURES_tune-armv5te} arm926ejs
PACKAGE_EXTRA_ARCHS_tune-arm926ejs = ${PACKAGE_EXTRA_ARCHS_tune-armv5te}
-
+TUNE_PKGARCH_tune-arm926ejs = armv5te-arm926ejs
I'd suggest simply arm926ejs
--- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200
+++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200
@@ -8,10 +8,12 @@
AVAILTUNES += xscale
TUNE_FEATURES_tune-xscale = ${TUNE_FEATURES_tune-armv5te} xscale
PACKAGE_EXTRA_ARCHS_tune-xscale = ${PACKAGE_EXTRA_ARCHS_tune-armv5te}
+TUNE_PKGARCH_tune-xscale = armv5te-xscale
Again simplify to xscale
AVAILTUNES += xscale-be
TUNE_FEATURES_tune-xscale-be = ${TUNE_FEATURES_tune-armv5teb} xscale
bigendian
PACKAGE_EXTRA_ARCHS_tune-xscale-be = ${PACKAGE_EXTRA_ARCHS_tune-armv5teb}
+TUNE_PKGARCH_tune-xscale-be = armv5teb-xscale
And xscaleeb (or be)
--Mark
# webkit-gtk has alignment issues with double instructions on armv5 so
# disable them here
Shouldn't spitz produce something like armv5te-xscale and qemuarm
armv5te-arm926ejs?
It would cause all recipes to build again (cannot share armv5te feed anymore),
but at least it would build it and user will really get it on target, right now
opkg upgrade can download some packages with xscale some with arm926ej-s.
$
Re: [OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
Op 11 sep. 2012, om 17:51 heeft Mark Hatle mark.ha...@windriver.com het volgende geschreven: On 9/11/12 8:48 AM, Martin Jansa wrote: On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote: Hi, when building spitz and qemuarm (both produces packages in armv5te feed) resulting packages are tuned with -mtune=xscale (when built for spitz) or -mtune=arm926ej-s (when built for qemuarm). I argued this when we original did the work for the tunings, and I lost From https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended. That is certainly my expectation. I'm not sure that the arm926ej-s can produce binaries that are -not- arm5te binaries -- as that seems to be the standard for what an armv5te is. The xscale on the other hand is capable of having different tuning parameters and had a few additional instructions. From a gcc point of view both are the same ISA, but using xscale will take in account the absurdly long pipeline on that SoC. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED REQUEST 00/13] Misc Fixes (cover only)
The following changes since commit 48169c6bc44c546cecaa06207b6c36da558b81f7:
classes/packageinfo: use better method to check if package exists (2012-09-10
21:52:37 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Bruce Ashfield (1):
linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
Khem Raj (2):
gcc-4.7: Fix build for armv4/EABI and ppc/Os
gcc-4.7: Backport libgcc fixes to appease the new build sequence
Mark Asselstine (1):
base-files: provide a mechanism to skip creation of the hostname file
Mark Hatle (3):
image.bbclass: Enable the complementary install to be called w/
globbing params
package_rpm.bbclass: Avoid unnecessary installs in complementary pass
qt4: Update qt4.inc to remove staticdev deps in -dbg packages
Matthew McClintock (1):
sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we
have items to check
Phil Blundell (3):
perl-native: PROVIDE libmodule-build-perl-native for consistency with
non-native perl
shadow: Fix various invalid assumptions about directory layout
shadow-native: Ensure that ${sbindir} and ${base_sbindir} are
respected
Ross Burton (2):
webkit-gtk: work around Make bug by re-running make
telepathy-idle: fix parallel build
meta/classes/image.bbclass |4 +-
meta/classes/package_rpm.bbclass |9 ++-
.../build-fix-for-make-j-safety.patch | 39
.../fix-svc-gtk-doc.h-target.patch | 24 +-
.../telepathy/telepathy-idle_0.1.12.bb |5 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 14 ++--
.../sysvinit/sysvinit-inittab_2.88dsf.bb |6 +-
meta/recipes-devtools/gcc/gcc-4.7.inc |6 +-
...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93
...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 ++
.../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch| 31 +++
.../gcc/gcc-4.7/ppc_no_crtsavres.patch | 72 +++
meta/recipes-devtools/perl/perl-native_5.14.2.bb |3 +
.../shadow/shadow-native_4.1.4.3.bb| 11 ++-
meta/recipes-extended/shadow/shadow_4.1.4.3.bb | 17 +++-
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb|8 +-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 16 ++--
meta/recipes-qt/qt4/qt4-embedded.inc |2 +-
meta/recipes-qt/qt4/qt4-x11-free.inc |2 +-
meta/recipes-qt/qt4/qt4.inc|2 +-
meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb | 22 +
21 files changed, 380 insertions(+), 55 deletions(-)
create mode 100644
meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/build-fix-for-make-j-safety.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch
create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch
--
1.7.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] Package upgrades
This is another set of package upgrades compiled on all architectures
and tested using core-image-sato.
The following changes since commit 7250638ec895bc89508711831083d43b9e1e9826:
upstream_tracking: Fix format issues (2012-09-10 23:21:12 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib cmuscax/upgrades
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=cmuscax/upgrades
Constantin Musca (5):
boost: upgrade to 1.51.0
glew: upgrade to 1.9.0
libexif: upgrade to 0.6.21
sysstat: upgrade to 10.1.1
openssl: upgrade to 1.0.1c
.../openssl-1.0.0j/debian/debian-targets.patch | 54 -
.../openssl/openssl-1.0.0j/debian/pic.patch| 242
.../configure-targets.patch|0
.../debian/block_digicert_malaysia.patch | 29 +++
.../openssl-1.0.1c/debian/block_diginotar.patch| 67 ++
.../debian/c_rehash-compat.patch | 15 +-
.../openssl-1.0.1c/debian/c_rehash-multi.patch | 89 +++
.../debian/ca.patch|1 +
.../openssl-1.0.1c/debian/config-hurd.patch| 18 ++
.../openssl-1.0.1c/debian/debian-targets.patch | 67 ++
.../openssl-1.0.1c/debian/default_bits.patch | 14 ++
.../openssl/openssl-1.0.1c/debian/dgst_hmac.patch | 54 +
.../openssl/openssl-1.0.1c/debian/gnu_source.patch | 27 +++
.../debian/libdoc-manpgs-pod-spell.patch | 239 +++
.../openssl-1.0.1c/debian/libssl-misspell.patch| 14 ++
.../debian/make-targets.patch | 13 +-
.../debian/man-dir.patch |1 +
.../debian/man-section.patch |1 +
.../debian/no-rpath.patch |1 +
.../debian/no-symbolic.patch |1 +
.../debian/openssl-pod-misspell.patch | 125 ++
.../openssl/openssl-1.0.1c/debian/pic.patch| 178 ++
.../openssl/openssl-1.0.1c/debian/pkcs12-doc.patch | 39
.../openssl-1.0.1c/debian/pod_ec.misspell.patch| 14 ++
.../debian/pod_pksc12.misspell.patch | 14 ++
.../openssl-1.0.1c/debian/pod_req_misspell2.patch | 15 ++
.../debian/pod_s_server.misspell.patch | 14 ++
.../debian/pod_x509setflags.misspell.patch | 14 ++
.../openssl/openssl-1.0.1c/debian/rehash-crt.patch | 36 +++
.../openssl/openssl-1.0.1c/debian/rehash_pod.patch | 63 +
.../openssl-1.0.1c/debian/renegiotate_tls.patch| 13 ++
.../openssl-1.0.1c/debian/shared-lib-ext.patch | 17 ++
.../openssl/openssl-1.0.1c/debian/stddef.patch | 15 ++
.../openssl/openssl-1.0.1c/debian/valgrind.patch | 23 ++
.../debian/version-script.patch| 203 ++--
.../engines-install-in-libdir-ssl.patch|0
.../{openssl-1.0.0j = openssl-1.0.1c}/find.pl |0
.../oe-ldflags.patch |0
.../openssl-fix-link.patch |0
.../openssl_fix_for_x32.patch | 38 ++-
.../shared-libs.patch | 33 +--
.../{openssl_1.0.0j.bb = openssl_1.0.1c.bb} | 37 ++-
meta/recipes-extended/sysstat/sysstat_10.0.5.bb|8 -
meta/recipes-extended/sysstat/sysstat_10.1.1.bb|8 +
.../glew/{glew_1.7.0.bb = glew_1.9.0.bb} |6 +-
.../boost/{boost_1.50.0.bb = boost_1.51.0.bb} |4 +-
.../{libexif_0.6.20.bb = libexif_0.6.21.bb} |4 +-
47 files changed, 1465 insertions(+), 403 deletions(-)
delete mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.0j/debian/debian-targets.patch
delete mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.0j/debian/pic.patch
rename meta/recipes-connectivity/openssl/{openssl-1.0.0j =
openssl-1.0.1c}/configure-targets.patch (100%)
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/block_digicert_malaysia.patch
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/block_diginotar.patch
rename meta/recipes-connectivity/openssl/{openssl-1.0.0j =
openssl-1.0.1c}/debian/c_rehash-compat.patch (77%)
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/c_rehash-multi.patch
rename meta/recipes-connectivity/openssl/{openssl-1.0.0j =
openssl-1.0.1c}/debian/ca.patch (93%)
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/config-hurd.patch
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/debian-targets.patch
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/default_bits.patch
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/dgst_hmac.patch
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.1c/debian/gnu_source.patch
create mode 100644
[OE-core] [PATCH 4/5] sysstat: upgrade to 10.1.1
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/recipes-extended/sysstat/sysstat_10.0.5.bb |8
meta/recipes-extended/sysstat/sysstat_10.1.1.bb |8
2 files changed, 8 insertions(+), 8 deletions(-)
delete mode 100644 meta/recipes-extended/sysstat/sysstat_10.0.5.bb
create mode 100644 meta/recipes-extended/sysstat/sysstat_10.1.1.bb
diff --git a/meta/recipes-extended/sysstat/sysstat_10.0.5.bb
b/meta/recipes-extended/sysstat/sysstat_10.0.5.bb
deleted file mode 100644
index 1c8595a..000
--- a/meta/recipes-extended/sysstat/sysstat_10.0.5.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require sysstat.inc
-
-LIC_FILES_CHKSUM = file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b
-
-PR = ${INC_PR}.1
-
-SRC_URI[md5sum] = 208dd236d726d20591d53d3a20124dd4
-SRC_URI[sha256sum] =
1f474d6ca742af73d0f9d09a374bda64c72bccb126aef327fa74383ff438feff
diff --git a/meta/recipes-extended/sysstat/sysstat_10.1.1.bb
b/meta/recipes-extended/sysstat/sysstat_10.1.1.bb
new file mode 100644
index 000..54b0226
--- /dev/null
+++ b/meta/recipes-extended/sysstat/sysstat_10.1.1.bb
@@ -0,0 +1,8 @@
+require sysstat.inc
+
+LIC_FILES_CHKSUM = file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b
+
+PR = ${INC_PR}.0
+
+SRC_URI[md5sum] = 8250cdcbc4a959c8a05e4186fbd13d84
+SRC_URI[sha256sum] =
119c7a23c5597d6d0df0b229c54984a35f357ecbd1c96da8cef4d105e8dfdacf
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED REQUEST 00/13] Misc Fixes (cover only)
On 09/11/2012 09:14 AM, Saul Wold wrote:
The following changes since commit 48169c6bc44c546cecaa06207b6c36da558b81f7:
classes/packageinfo: use better method to check if package exists
(2012-09-10 21:52:37 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Bruce Ashfield (1):
linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
Khem Raj (2):
gcc-4.7: Fix build for armv4/EABI and ppc/Os
gcc-4.7: Backport libgcc fixes to appease the new build sequence
Mark Asselstine (1):
base-files: provide a mechanism to skip creation of the hostname file
Mark Hatle (3):
image.bbclass: Enable the complementary install to be called w/
globbing params
package_rpm.bbclass: Avoid unnecessary installs in complementary pass
qt4: Update qt4.inc to remove staticdev deps in -dbg packages
Matthew McClintock (1):
sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we
have items to check
Scratch this one, I missed the v2 posted while I was heads down prepping
this!
Sau!
Phil Blundell (3):
perl-native: PROVIDE libmodule-build-perl-native for consistency with
non-native perl
shadow: Fix various invalid assumptions about directory layout
shadow-native: Ensure that ${sbindir} and ${base_sbindir} are
respected
Ross Burton (2):
webkit-gtk: work around Make bug by re-running make
telepathy-idle: fix parallel build
meta/classes/image.bbclass |4 +-
meta/classes/package_rpm.bbclass |9 ++-
.../build-fix-for-make-j-safety.patch | 39
.../fix-svc-gtk-doc.h-target.patch | 24 +-
.../telepathy/telepathy-idle_0.1.12.bb |5 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 14 ++--
.../sysvinit/sysvinit-inittab_2.88dsf.bb |6 +-
meta/recipes-devtools/gcc/gcc-4.7.inc |6 +-
...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93
...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 ++
.../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch| 31 +++
.../gcc/gcc-4.7/ppc_no_crtsavres.patch | 72 +++
meta/recipes-devtools/perl/perl-native_5.14.2.bb |3 +
.../shadow/shadow-native_4.1.4.3.bb| 11 ++-
meta/recipes-extended/shadow/shadow_4.1.4.3.bb | 17 +++-
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb|8 +-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 16 ++--
meta/recipes-qt/qt4/qt4-embedded.inc |2 +-
meta/recipes-qt/qt4/qt4-x11-free.inc |2 +-
meta/recipes-qt/qt4/qt4.inc|2 +-
meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb | 22 +
21 files changed, 380 insertions(+), 55 deletions(-)
create mode 100644
meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/build-fix-for-make-j-safety.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch
create mode 100644 meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, Sep 11, 2012 at 11:09:53AM -0500, Mark Hatle wrote:
On 9/11/12 10:59 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 10:51:40AM -0500, Mark Hatle wrote:
On 9/11/12 8:48 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote:
Hi,
when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz)
or -mtune=arm926ej-s (when built for qemuarm).
I argued this when we original did the work for the tunings, and I lost
From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine, you
are expected to use a different PACKAGE_ARCH. If you do that, you will
get a different package feed for the different binaries, different
WORKDIR and so on. This was always the way the package architectures was
intended to work and nothing has changed there. Yes, you as the user
changing various variables can create inconsistent package feeds. There
are 101 ways you can do that, the simple answer is just don't. We're
therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH,
please just use it as its intended.
That is certainly my expectation. I'm not sure that the arm926ej-s can
produce
binaries that are -not- arm5te binaries -- as that seems to be the
standard for
what an armv5te is. The xscale on the other hand is capable of having
different
tuning parameters and had a few additional instructions. In the past I've
generated a tuning simple called xscale that was compatible w/ armv5te.
This
way you could share non-optimized things, and go w/ xscale as necessary.
Few more comments I did on IRC:
16:41:23 JaMa let's hope RP will comment on that as that was his comment
I was copypasting
16:41:53 JaMa e.g. ppc seems to set TUNE_PKGARCH for each tune-*
16:44:24 JaMa but it would be better to set xscale/arm926 tune only for
packages where such -mtune brings some speedup (and for those where we set
PACKAGE_ARCH = MACHINE_ARCH already) and build the rest only with -march
16:45:36 JaMa but mixed feed and -mtune=xscale packages on arm926
targets looks like worst case
16:50:20 JaMa oe-classic had the same issue with mixed -mtune in package
arch feeds, but at least it wasn't rebuilding them after each machine switch
And I'm not sure where we could decide what's worth -mtune and what is not,
because in recipe we can do it only with a lot of _arch overrides and in
tune
file with lot of _pn-foo overrides (and some could be also in other layers
then oe-core etc.)
But it would be nice to share most packages as general armv5te between
e.g. spitz and qemuarm builds.
This really hints that defining the tunings become a distribution
configuration.
You should be able to do:
DEFAULTTUNE_pn-openssl = xscale
Where? in some distro config? What after I switch machine to some armv7a
machine? (that's why I said a lot of _arch overrides)
something like:
# to set only armv5te as default (for most PN)
DEFAULTTUNE_armv5te = armv5te
# then use optimized DEFAULTTUNE where it's worth
DEFAULTTUNE_pn-openssl_spitz = xscale
DEFAULTTUNE_pn-openssl_mycorei7 = corei7
But that sucks because I have to list all MACHINES which have some
optimized DEFAULTTUNE.
What about something like this:
bitbake.conf:
OPTDEFAULTTUNE ??= ${DEFAULTTUNE}
conf/machine/include/tune-xscale.inc:
-DEFAULTTUNE ?= xscale
+OPTDEFAULTTUNE ?= xscale
conf/machine/include/tune-arm926ejs.inc
-DEFAULTTUNE ?= arm926ejs
+OPTDEFAULTTUNE ?= arm926ejs
conf/distro/include/opt-default-tune.inc:
DEFAULTTUNE_pn-openssl = ${OPTDEFAULTTUNE}
DEFAULTTUNE_pn-mplayer = ${OPTDEFAULTTUNE}
That would be easier to manage I guess.
To enable just openssl benefits from the xscale tunings. (The pn- may not be
needed.. I can never remember anymore...) But that was the original idea
with
the tunings, make a way to specify DEFAULTTUNE for various things when
alternative, but compatible tunings made a difference... set that in the
distro.conf and you have an optimized distribution for specific uses. (You
of
course could also move that to a machine setting or similar file.)
--Mark
Cheers,
Does qemuarm use oe-core as it's intended?
CCing bluelightning because xscale is used in lot of meta-handheld
machines:
Does this make sense?
OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr
tune-arm926*; diff -uNr tune-xscale.inc*
--- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200
+++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200
@@ -8,4 +8,4 @@
AVAILTUNES += arm926ejs
TUNE_FEATURES_tune-arm926ejs = ${TUNE_FEATURES_tune-armv5te}
arm926ejs
PACKAGE_EXTRA_ARCHS_tune-arm926ejs =
${PACKAGE_EXTRA_ARCHS_tune-armv5te}
-
+TUNE_PKGARCH_tune-arm926ejs = armv5te-arm926ejs
I'd
Re: [OE-core] [PATCH 11/32] sysvinit-inittab_2.88dsf.bb: Allow multiple serial port consoles to be defined
On Tue, Sep 11, 2012 at 6:49 AM, Phil Blundell ph...@gnu.org wrote:
On Mon, 2012-08-13 at 14:14 -0700, Scott Garman wrote:
+pkg_postinst_${PN} () {
+# run this on the target
+if [ x$D == x ]; then
By the way, == is a bashism; that should just be = for portability.
Or you can use '-z $D' which is also portable.
Ok - will send a v3 shortly.
-M
p.
___
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] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? That's a DISTRO policy decision really. armv5te, in common with most of the PACKAGE_ARCHes, represents an ISA. That is, it is guaranteed to only contain instructions which are supported by all v5TE cores (which includes both ARM926EJ-S and XScale). It obviously follows from this that packages with PACKAGE_ARCH=armv5te are suitable for running on both qemuarm and xscale MACHINEs. Note that a binary that was built with -mtune=arm926ej-s is still an ARMv5TE binary and will run just fine on xscale. It won't run quite as fast as one that was built -mtune=xscale, though the performance difference is not so great as to be completely crippling. With current gcc, the reverse is true as well: a binary built -mtune=xscale is also still ARMv5TE and will run just fine on ARM926EJ-S, and in fact the performance penalty is less this way around. Now, if your DISTRO feels that the performance difference is important enough to be worth distinguishing the packages, you can certainly arrange for those two tunings to get separate PACKAGE_ARCHes and maintain parallel feeds. But in the general case it's not totally obvious that this would be worthwhile, and I'm not sure it is a very useful thing to do by default. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, Sep 11, 2012 at 05:46:12PM +0100, Phil Blundell wrote: On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? That's a DISTRO policy decision really. armv5te, in common with most of the PACKAGE_ARCHes, represents an ISA. That is, it is guaranteed to only contain instructions which are supported by all v5TE cores (which includes both ARM926EJ-S and XScale). It obviously follows from this that packages with PACKAGE_ARCH=armv5te are suitable for running on both qemuarm and xscale MACHINEs. Note that a binary that was built with -mtune=arm926ej-s is still an ARMv5TE binary and will run just fine on xscale. It won't run quite as fast as one that was built -mtune=xscale, though the performance difference is not so great as to be completely crippling. With current gcc, the reverse is true as well: a binary built -mtune=xscale is also still ARMv5TE and will run just fine on ARM926EJ-S, and in fact the performance penalty is less this way around. Now, if your DISTRO feels that the performance difference is important enough to be worth distinguishing the packages, you can certainly arrange for those two tunings to get separate PACKAGE_ARCHes and maintain parallel feeds. But in the general case it's not totally obvious that this would be worthwhile, and I'm not sure it is a very useful thing to do by default. But that is default now, that's why I've started this thread. It uses PACKAGE_ARCH=armv5te while using -mtune. Causing different sstate checksums and rebuilds when you switch e.g. qemuarm and spitz. If we drop DEFAULTTUNE from tune-xscale and tune-arm926ejs then PACKAGE_ARCH=armv5te would be the same and the same feed will be built only once. And if DISTO feels that the performance difference is important then something like OPTDEFAULTTUNE could be added: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029455.html Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, 2012-09-11 at 18:53 +0200, Martin Jansa wrote: If we drop DEFAULTTUNE from tune-xscale and tune-arm926ejs then PACKAGE_ARCH=armv5te would be the same and the same feed will be built only once. Well, that would also make those two tune files rather useless. It seems like it would be better to just refrain from including them if you don't want the corresponding tunings. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, Sep 11, 2012 at 06:14:22PM +0100, Phil Blundell wrote: On Tue, 2012-09-11 at 18:53 +0200, Martin Jansa wrote: If we drop DEFAULTTUNE from tune-xscale and tune-arm926ejs then PACKAGE_ARCH=armv5te would be the same and the same feed will be built only once. Well, that would also make those two tune files rather useless. It seems like it would be better to just refrain from including them if you don't want the corresponding tunings. But that does not allow me to still use it for few packages if my DISTRO decides it's worth it. I'll test tomorrow, something like top 3 patches here: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, Sep 11, 2012 at 07:21:07PM +0200, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 06:14:22PM +0100, Phil Blundell wrote:
On Tue, 2012-09-11 at 18:53 +0200, Martin Jansa wrote:
If we drop DEFAULTTUNE from tune-xscale and tune-arm926ejs then
PACKAGE_ARCH=armv5te would be the same and the same feed will be built
only once.
Well, that would also make those two tune files rather useless. It
seems like it would be better to just refrain from including them if you
don't want the corresponding tunings.
But that does not allow me to still use it for few packages if my DISTRO
decides it's worth it.
I'll test tomorrow, something like top 3 patches here:
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune
If this works then DISTRO would have finer control of which DEFAULTTUNE
to use
1) default: don't use mtune, optimize only for march (don't mix mtune in
the same feed).
2) include optimized-tune.inc in distro.conf: use mtune only for some packages,
but
with separate package feed for them
3) DEFAULTTUNE = ${OPTDEFAULTTUNE} in distro.conf: always use best mtune
available for MACHINE, but unlike current default, don't mix them in
same package feed
DEFAULTTUNE = ${OPTDEFAULTTUNE} should also be used for PACKAGE_ARCH ==
MACHINE_ARCH
--
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] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, 2012-09-11 at 19:35 +0200, Martin Jansa wrote:
If this works then DISTRO would have finer control of which DEFAULTTUNE
to use
1) default: don't use mtune, optimize only for march (don't mix mtune in
the same feed).
2) include optimized-tune.inc in distro.conf: use mtune only for some
packages, but
with separate package feed for them
3) DEFAULTTUNE = ${OPTDEFAULTTUNE} in distro.conf: always use best mtune
available for MACHINE, but unlike current default, don't mix them in
same package feed
DEFAULTTUNE = ${OPTDEFAULTTUNE} should also be used for PACKAGE_ARCH ==
MACHINE_ARCH
Yeah, that all sounds fairly reasonable to me. I'm not sure that
optimized-tune.inc belongs in oe-core, since its contents is inherently
distro-specific, but the general plan seems pretty good.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, Sep 11, 2012 at 06:37:23PM +0100, Phil Blundell wrote:
On Tue, 2012-09-11 at 19:35 +0200, Martin Jansa wrote:
If this works then DISTRO would have finer control of which DEFAULTTUNE
to use
1) default: don't use mtune, optimize only for march (don't mix mtune in
the same feed).
2) include optimized-tune.inc in distro.conf: use mtune only for some
packages, but
with separate package feed for them
3) DEFAULTTUNE = ${OPTDEFAULTTUNE} in distro.conf: always use best mtune
available for MACHINE, but unlike current default, don't mix them in
same package feed
DEFAULTTUNE = ${OPTDEFAULTTUNE} should also be used for PACKAGE_ARCH ==
MACHINE_ARCH
Yeah, that all sounds fairly reasonable to me. I'm not sure that
optimized-tune.inc belongs in oe-core, since its contents is inherently
distro-specific, but the general plan seems pretty good.
OK, thanks
I've put optimized-tune.inc to oe-core only to share knowledge of which
packages are worth using OPTDEFAULTTUNE, but I expect DISTRO maintainers
to add their own entries too (e.g. for stuff which is only in their own
layer), so I'm fine with optimized-tune.inc in meta-distro too.
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we have items to check
Right now, we delay running the serial console checks to we boot up. This causes
issues for read only file systems. So, if have not configured any serial ports
to
check via SERIAL_CONSOLES_CHECK we can skip the check at boot. This fixes any
issues with read only file systems and ipk packaging.
Signed-off-by: Matthew McClintock m...@freescale.com
---
v2: bump PR
v3: change a == bashism to =
.../sysvinit/sysvinit-inittab_2.88dsf.bb | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index 1089edb..5b79caf 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -2,7 +2,7 @@ DESCRIPTION = Inittab for sysvinit
LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
-PR = r7
+PR = r8
SRC_URI = file://inittab
@@ -54,7 +54,7 @@ EOF
pkg_postinst_${PN} () {
# run this on the target
-if [ x$D == x ]; then
+if [ x$D = x ]; then
tmp=${SERIAL_CONSOLES_CHECK}
for i in $tmp
do
@@ -65,7 +65,11 @@ if [ x$D == x ]; then
done
kill -HUP 1
else
- exit 1
+ if [ ${SERIAL_CONSOLES_CHECK} = ]; then
+ exit 0
+ else
+ exit 1
+ fi
fi
}
--
1.7.9.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: should it really have TUNE_ARCH armv5te?
On 9/11/12 12:43 PM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 06:37:23PM +0100, Phil Blundell wrote:
On Tue, 2012-09-11 at 19:35 +0200, Martin Jansa wrote:
If this works then DISTRO would have finer control of which DEFAULTTUNE
to use
1) default: don't use mtune, optimize only for march (don't mix mtune in
the same feed).
2) include optimized-tune.inc in distro.conf: use mtune only for some packages,
but
with separate package feed for them
3) DEFAULTTUNE = ${OPTDEFAULTTUNE} in distro.conf: always use best mtune
available for MACHINE, but unlike current default, don't mix them in
same package feed
DEFAULTTUNE = ${OPTDEFAULTTUNE} should also be used for PACKAGE_ARCH ==
MACHINE_ARCH
Yeah, that all sounds fairly reasonable to me. I'm not sure that
optimized-tune.inc belongs in oe-core, since its contents is inherently
distro-specific, but the general plan seems pretty good.
OK, thanks
I've put optimized-tune.inc to oe-core only to share knowledge of which
packages are worth using OPTDEFAULTTUNE, but I expect DISTRO maintainers
to add their own entries too (e.g. for stuff which is only in their own
layer), so I'm fine with optimized-tune.inc in meta-distro too.
Along those lines.. I'm always asked for optimized crypto libraries (nss,
openssl, beecrypt, etc...), database (mysql or similar), codecs, sometimes libc
itself, and graphics drivers.. otherwise nobody seems to care if it's good enough.
--Mark
Cheers,
___
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 v3] sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we have items to check
On Tue, 2012-09-11 at 12:56 -0500, Matthew McClintock wrote: Right now, we delay running the serial console checks to we boot up. This causes issues for read only file systems. So, if have not configured any serial ports to check via SERIAL_CONSOLES_CHECK we can skip the check at boot. This fixes any issues with read only file systems and ipk packaging. Signed-off-by: Matthew McClintock m...@freescale.com --- v2: bump PR v3: change a == bashism to = Looks good. Thanks. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] eglibc: Restore ${PN} to before ${PN}-dev in PACKAGES
Commit 13544fbc6217fee1731a6da1e2cf94901a500842 changed the ordering
of PACKAGES so that ${PN}-dev came before ${PN}. However, this caused
the FILES matching to go wrong if ${libdir} == ${base_libdir}. Fix this
by moving ${PN} ahead of ${PN}-dev once again.
Signed-off-by: Phil Blundell p...@pbcl.net
---
meta/recipes-core/eglibc/eglibc-package.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index edf7a75..adf31de 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -17,7 +17,7 @@ python __anonymous () {
# Set this to zero if you don't want ldconfig in the output package
USE_LDCONFIG ?= 1
-PACKAGES = ${PN}-dbg catchsegv sln nscd ldd ${PN}-mtrace ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile
libsotruss ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN} eglibc-extra-nss
+PACKAGES = ${PN}-dbg catchsegv sln nscd ldd ${PN}-mtrace ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile
libsotruss ${PN} eglibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc
# The ld.so in this eglibc supports the GNU_HASH
RPROVIDES_${PN} = glibc rtld(GNU_HASH)
--
1.7.9
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] eglibc: Restore ${PN} to before ${PN}-dev in PACKAGES
Ah right, yeah, I guess so. Thanks, I'll re-send.
Do we have any roadmap for getting to a point where we don't need to
keep bumping PR by hand anymore?
p.
On Tue, 2012-09-11 at 20:09 +0200, Martin Jansa wrote:
Missing PR bumps?
On Tue, Sep 11, 2012 at 8:04 PM, Phil Blundell ph...@gnu.org wrote:
Commit 13544fbc6217fee1731a6da1e2cf94901a500842 changed the ordering
of PACKAGES so that ${PN}-dev came before ${PN}. However, this caused
the FILES matching to go wrong if ${libdir} == ${base_libdir}. Fix this
by moving ${PN} ahead of ${PN}-dev once again.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] eglibc: Restore ${PN} to before ${PN}-dev in PACKAGES
Commit 13544fbc6217fee1731a6da1e2cf94901a500842 changed the ordering
of PACKAGES so that ${PN}-dev came before ${PN}. However, this caused
the FILES matching to go wrong if ${libdir} == ${base_libdir}. Fix this
by moving ${PN} ahead of ${PN}-dev once again.
Signed-off-by: Phil Blundell p...@pbcl.net
---
V2: now with high-tech PR goodness
meta/recipes-core/eglibc/eglibc-package.inc |2 +-
meta/recipes-core/eglibc/eglibc_2.16.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index edf7a75..adf31de 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -17,7 +17,7 @@ python __anonymous () {
# Set this to zero if you don't want ldconfig in the output package
USE_LDCONFIG ?= 1
-PACKAGES = ${PN}-dbg catchsegv sln nscd ldd ${PN}-mtrace ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile
libsotruss ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN} eglibc-extra-nss
+PACKAGES = ${PN}-dbg catchsegv sln nscd ldd ${PN}-mtrace ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile
libsotruss ${PN} eglibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc
# The ld.so in this eglibc supports the GNU_HASH
RPROVIDES_${PN} = glibc rtld(GNU_HASH)
diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb
b/meta/recipes-core/eglibc/eglibc_2.16.bb
index c4bc18c..ffa4d5f 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = 20393
DEPENDS += gperf-native
-PR = r7
+PR = r8
PR_append = +svnr${SRCPV}
EGLIBC_BRANCH=eglibc-2_16
--
1.7.9
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] eglibc: Restore ${PN} to before ${PN}-dev in PACKAGES
On 09/11/2012 11:14 AM, Phil Blundell wrote:
Commit 13544fbc6217fee1731a6da1e2cf94901a500842 changed the ordering
of PACKAGES so that ${PN}-dev came before ${PN}. However, this caused
the FILES matching to go wrong if ${libdir} == ${base_libdir}. Fix this
by moving ${PN} ahead of ${PN}-dev once again.
Signed-off-by: Phil Blundell p...@pbcl.net
---
V2: now with high-tech PR goodness
meta/recipes-core/eglibc/eglibc-package.inc |2 +-
meta/recipes-core/eglibc/eglibc_2.16.bb |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
b/meta/recipes-core/eglibc/eglibc-package.inc
index edf7a75..adf31de 100644
--- a/meta/recipes-core/eglibc/eglibc-package.inc
+++ b/meta/recipes-core/eglibc/eglibc-package.inc
@@ -17,7 +17,7 @@ python __anonymous () {
# Set this to zero if you don't want ldconfig in the output package
USE_LDCONFIG ?= 1
-PACKAGES = ${PN}-dbg catchsegv sln nscd ldd ${PN}-mtrace ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile libsotruss
${PN}-dev ${PN}-staticdev ${PN}-doc ${PN} eglibc-extra-nss
+PACKAGES = ${PN}-dbg catchsegv sln nscd ldd ${PN}-mtrace ${PN}-utils
eglibc-thread-db ${PN}-pic libcidn libmemusage libsegfault ${PN}-pcprofile libsotruss
${PN} eglibc-extra-nss ${PN}-dev ${PN}-staticdev ${PN}-doc
Did you do a build with BUILD_HISTORY enabled and verified nothing
changes in the standard case?
Sau!
# The ld.so in this eglibc supports the GNU_HASH
RPROVIDES_${PN} = glibc rtld(GNU_HASH)
diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb
b/meta/recipes-core/eglibc/eglibc_2.16.bb
index c4bc18c..ffa4d5f 100644
--- a/meta/recipes-core/eglibc/eglibc_2.16.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.16.bb
@@ -3,7 +3,7 @@ require eglibc.inc
SRCREV = 20393
DEPENDS += gperf-native
-PR = r7
+PR = r8
PR_append = +svnr${SRCPV}
EGLIBC_BRANCH=eglibc-2_16
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, Sep 11, 2012 at 9:13 AM, Koen Kooi k...@dominion.thruhere.net wrote: From a gcc point of view both are the same ISA, but using xscale will take in account the absurdly long pipeline on that SoC. Not really, when you tune for XScale it will use ldrd/strd and pld if possible ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
On Tue, 2012-09-11 at 11:40 -0700, Khem Raj wrote: On Tue, Sep 11, 2012 at 9:13 AM, Koen Kooi k...@dominion.thruhere.net wrote: From a gcc point of view both are the same ISA, but using xscale will take in account the absurdly long pipeline on that SoC. Not really, when you tune for XScale it will use ldrd/strd and pld if possible Are you sure? As far as I remember, the only effects of -mtune=xscale are to alter some minor pipeline-related tradeoffs in code generation. In particular, LDM is especially slow on xscale so it is usually best avoided unless loading very large numbers of registers. I can't think of any reason why pld would be any more beneficial on xscale than generic v5TE, and I don't think gcc does anything special with it in that regard. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED REQUEST 00/13] Misc Fixes (cover only)
On Tue, Sep 11, 2012 at 11:19 AM, Saul Wold s...@linux.intel.com wrote:
On 09/11/2012 09:14 AM, Saul Wold wrote:
The following changes since commit
48169c6bc44c546cecaa06207b6c36da558b81f7:
classes/packageinfo: use better method to check if package exists
(2012-09-10 21:52:37 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Bruce Ashfield (1):
linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
Khem Raj (2):
gcc-4.7: Fix build for armv4/EABI and ppc/Os
gcc-4.7: Backport libgcc fixes to appease the new build sequence
Mark Asselstine (1):
base-files: provide a mechanism to skip creation of the hostname file
Mark Hatle (3):
image.bbclass: Enable the complementary install to be called w/
globbing params
package_rpm.bbclass: Avoid unnecessary installs in complementary pass
qt4: Update qt4.inc to remove staticdev deps in -dbg packages
Matthew McClintock (1):
sysvinit-inittab_2.88dsf.bb: only run serial checks at boot if we
have items to check
Scratch this one, I missed the v2 posted while I was heads down prepping
this!
v3 now!
-M
Sau!
Phil Blundell (3):
perl-native: PROVIDE libmodule-build-perl-native for consistency with
non-native perl
shadow: Fix various invalid assumptions about directory layout
shadow-native: Ensure that ${sbindir} and ${base_sbindir} are
respected
Ross Burton (2):
webkit-gtk: work around Make bug by re-running make
telepathy-idle: fix parallel build
meta/classes/image.bbclass |4 +-
meta/classes/package_rpm.bbclass |9 ++-
.../build-fix-for-make-j-safety.patch | 39
.../fix-svc-gtk-doc.h-target.patch | 24 +-
.../telepathy/telepathy-idle_0.1.12.bb |5 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 14 ++--
.../sysvinit/sysvinit-inittab_2.88dsf.bb |6 +-
meta/recipes-devtools/gcc/gcc-4.7.inc |6 +-
...-vis_hide-gen-hide-list-Do-not-make-defin.patch | 93
...USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch | 49 ++
.../gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch| 31 +++
.../gcc/gcc-4.7/ppc_no_crtsavres.patch | 72
+++
meta/recipes-devtools/perl/perl-native_5.14.2.bb |3 +
.../shadow/shadow-native_4.1.4.3.bb| 11 ++-
meta/recipes-extended/shadow/shadow_4.1.4.3.bb | 17 +++-
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb|8 +-
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 16 ++--
meta/recipes-qt/qt4/qt4-embedded.inc |2 +-
meta/recipes-qt/qt4/qt4-x11-free.inc |2 +-
meta/recipes-qt/qt4/qt4.inc|2 +-
meta/recipes-sato/webkit/webkit-gtk_1.8.2.bb | 22 +
21 files changed, 380 insertions(+), 55 deletions(-)
create mode 100644
meta/recipes-connectivity/telepathy/telepathy-idle-0.1.12/build-fix-for-make-j-safety.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch
___
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] autotools.bbclass: Add functionality to force a clean of ${B} when reconfiguring (and ${S} != ${B})
On Tue, Sep 11, 2012 at 9:22 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Unfortunately whilst rerunning configure and make against a project will
mostly
work there are situations where it does not correctly do the right thing.
In particular, eglibc and gcc will fail out with errors where settings
do not match a previously built configuration. It could be argued they are
broken but the situation is what it is. There is the possibility of more
subtle
errors too.
This patch adds removal of the build directory (${B}) when configure is
rerunning, the sstate checksum for do_configure has changed and ${S} != ${B}.
We could simply use a stamp but saving out the previous configuration checksum
adds some data at no real overhead.
If we find there are things where we want to disable this behaviour with
CONFIGURESTAMPFILE = in the recipe, or users could disable it globally.
[YOCTO #2774]
[YOCTO #2848]
This is particularly helpful for eglibc and gcc which use split builds by
default and
are a particular source of reconfigure type problems.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Is it feasible to back port this to denzil? I've encountered what I
think are similar issues reconfiguring gcc for example.
-M
---
diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 4c4bf87..a5997c5 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -89,6 +89,27 @@ oe_runconf () {
AUTOTOOLS_AUXDIR ?= ${S}
+CONFIGURESTAMPFILE = ${WORKDIR}/configure.sstate
+
+autotools_preconfigure() {
+ if [ -n ${CONFIGURESTAMPFILE} -a -e ${CONFIGURESTAMPFILE} ]; then
+ if [ `cat ${CONFIGURESTAMPFILE}` != ${BB_TASKHASH} -a
${S} != ${B} ]; then
+ echo Previously configured separate build directory
detected, cleaning ${B}
+ rm -rf ${B}
+ mkdir ${B}
+ fi
+ fi
+}
+
+autotools_postconfigure(){
+ if [ -n ${CONFIGURESTAMPFILE} ]; then
+ echo ${BB_TASKHASH} ${CONFIGURESTAMPFILE}
+ fi
+}
+
+do_configure[prefuncs] += autotools_preconfigure
+do_configure[postfuncs] += autotools_postconfigure
+
autotools_do_configure() {
case ${PN} in
autoconf*)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Sato virtual keyboard - how to close it?
Hello, In the Sato desktop, there is a virtual keyboard which you can bring up to enter text from a touchscreen interface. Once that keyboard pops up, how do you close it? I'm not seeing anything obvious. I'm helping out with a demo at a conference and could use this info urgently. Thanks, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Sato virtual keyboard - how to close it?
On 11 September 2012 20:13, Scott Garman scott.a.gar...@intel.com wrote: In the Sato desktop, there is a virtual keyboard which you can bring up to enter text from a touchscreen interface. Once that keyboard pops up, how do you close it? I'm not seeing anything obvious. I'm helping out with a demo at a conference and could use this info urgently. Moving the focus from a text field will do it. I thought there was a keyboard icon on the panel which should explicitly hide it, but maybe not. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 06/18] libx11: move keysymdefdir option to .inc
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |2 +-
meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb |2 --
meta/recipes-graphics/xorg-lib/libx11.inc |4 +++-
meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |2 --
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index dd9e7d9..9a7de33 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -25,6 +25,6 @@ DEPENDS += libxcb bigreqsproto xproto xextproto xtrans
libxau xcmiscproto \
FILESDIR = ${@os.path.dirname(d.getVar('FILE', True))}/libx11
-EXTRA_OECONF += --disable-xlocale --with-keysymdefdir=${STAGING_INCDIR}/X11
+EXTRA_OECONF += --disable-xlocale
CFLAGS += -D_GNU_SOURCE
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
index 9e88d45..714b993 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
@@ -18,5 +18,3 @@ RPROVIDES_${PN}-locale = libx11-locale
SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
SRC_URI[sha256sum] =
c382efd7e92bfc3cef39a4b7f1ecf2744ba4414a705e3bc1e697f75502bd4d86
-
-EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11/
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index 22b26cc..a524c5f 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -9,7 +9,7 @@ require xorg-lib-common.inc
inherit siteinfo
PE = 1
-INC_PR = r3
+INC_PR = r4
PROVIDES = virtual/libx11
@@ -23,6 +23,8 @@ FILES_${PN} += ${datadir}/X11/XKeysymDB
${datadir}/X11/XErrorDB ${libdir}/X11/X
FILES_${PN}-xcb += ${libdir}/libX11-xcb.so.*
FILES_${PN}-locale += ${datadir}/X11/locale ${libdir}/X11/locale
+EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11/
+
# Almost nothing uses XCMS
PACKAGECONFIG ??=
PACKAGECONFIG[xcms] = --enable-xcms,--disable-xcms
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
index 2e47899..0ba0f9b 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
@@ -5,8 +5,6 @@ PR = ${INC_PR}.0
BBCLASSEXTEND = native nativesdk
-EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11
-
DEPENDS += util-macros xtrans libxdmcp libxau \
bigreqsproto xproto xextproto xcmiscproto \
xf86bigfontproto kbproto inputproto libxcb \
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 01/18] libx11: use INC_PR
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |2 +-
meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb |2 +-
meta/recipes-graphics/xorg-lib/libx11.inc |1 +
meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |2 +-
4 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index 7d4facd..ed5a890 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -5,7 +5,7 @@ this version.
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-PR = r1
+PR = ${INC_PR}.0
SRC_URI += file://x11_disable_makekeys.patch \
file://X18NCMSstubs.diff \
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
index 3d5a306..e8661f3 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
@@ -5,7 +5,7 @@ DESCRIPTION += Support for XCMS is disabled in this version.
LICENSE = MIT MIT-style BSD
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-PR = r1
+PR = ${INC_PR}.0
DEPENDS += libxcb xproto xextproto xtrans libxau kbproto inputproto
xf86bigfontproto xproto-native
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index 592f116..9e8c863 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -9,6 +9,7 @@ require xorg-lib-common.inc
inherit siteinfo
PE = 1
+INC_PR = r1
PROVIDES = virtual/libx11
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
index a65ab1f..2e47899 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
@@ -1,7 +1,7 @@
require libx11.inc
inherit gettext
-PR = r1
+PR = ${INC_PR}.0
BBCLASSEXTEND = native nativesdk
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 12/18] default-providers: default to libx11, not -trim
Signed-off-by: Ross Burton ross.bur...@intel.com --- meta/conf/distro/include/default-providers.inc |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc index 2d8a17d..07222c2 100644 --- a/meta/conf/distro/include/default-providers.inc +++ b/meta/conf/distro/include/default-providers.inc @@ -10,7 +10,7 @@ PREFERRED_PROVIDER_virtual/libgles1 ?= mesa-dri PREFERRED_PROVIDER_virtual/libgles2 ?= mesa-dri PREFERRED_PROVIDER_virtual/update-alternatives ?= update-alternatives-cworth PREFERRED_PROVIDER_virtual/update-alternatives-native ?= opkg-native -PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim +PREFERRED_PROVIDER_virtual/libx11 ?= libx11 PREFERRED_PROVIDER_xf86-video-intel ?= xf86-video-intel # -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 05/18] libx11: move xcms disabling to PACKAGECONFIG in libx11.inc
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |2 +-
meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb |2 +-
meta/recipes-graphics/xorg-lib/libx11.inc |6 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index e6aa63f..dd9e7d9 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -25,6 +25,6 @@ DEPENDS += libxcb bigreqsproto xproto xextproto xtrans
libxau xcmiscproto \
FILESDIR = ${@os.path.dirname(d.getVar('FILE', True))}/libx11
-EXTRA_OECONF += --disable-xcms --disable-xlocale
--with-keysymdefdir=${STAGING_INCDIR}/X11
+EXTRA_OECONF += --disable-xlocale --with-keysymdefdir=${STAGING_INCDIR}/X11
CFLAGS += -D_GNU_SOURCE
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
index e8661f3..9e88d45 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
@@ -19,4 +19,4 @@ RPROVIDES_${PN}-locale = libx11-locale
SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
SRC_URI[sha256sum] =
c382efd7e92bfc3cef39a4b7f1ecf2744ba4414a705e3bc1e697f75502bd4d86
-EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11/ --disable-xcms
+EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11/
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index fb1daf2..22b26cc 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -9,7 +9,7 @@ require xorg-lib-common.inc
inherit siteinfo
PE = 1
-INC_PR = r2
+INC_PR = r3
PROVIDES = virtual/libx11
@@ -23,6 +23,10 @@ FILES_${PN} += ${datadir}/X11/XKeysymDB
${datadir}/X11/XErrorDB ${libdir}/X11/X
FILES_${PN}-xcb += ${libdir}/libX11-xcb.so.*
FILES_${PN}-locale += ${datadir}/X11/locale ${libdir}/X11/locale
+# Almost nothing uses XCMS
+PACKAGECONFIG ??=
+PACKAGECONFIG[xcms] = --enable-xcms,--disable-xcms
+
do_compile_prepend() {
cd ${S}/src/util
mv makekeys.c.orig makekeys.c || true
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 04/18] xorg-lib: move options to disable documentation to xorg-lib-common
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11.inc |4 +---
meta/recipes-graphics/xorg-lib/libxi_1.6.1.bb |4 +---
meta/recipes-graphics/xorg-lib/xorg-lib-common.inc |3 ++-
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index 9e8c863..fb1daf2 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -9,7 +9,7 @@ require xorg-lib-common.inc
inherit siteinfo
PE = 1
-INC_PR = r1
+INC_PR = r2
PROVIDES = virtual/libx11
@@ -17,8 +17,6 @@ XORG_PN = libX11
LICENSE = MIT MIT-style BSD
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-EXTRA_OECONF += --with-groff=no --with-ps2pdf=no --with-fop=no
--disable-specs
-
PACKAGES =+ ${PN}-xcb
FILES_${PN} += ${datadir}/X11/XKeysymDB ${datadir}/X11/XErrorDB
${libdir}/X11/Xcms.txt
diff --git a/meta/recipes-graphics/xorg-lib/libxi_1.6.1.bb
b/meta/recipes-graphics/xorg-lib/libxi_1.6.1.bb
index 575d130..c327f25 100644
--- a/meta/recipes-graphics/xorg-lib/libxi_1.6.1.bb
+++ b/meta/recipes-graphics/xorg-lib/libxi_1.6.1.bb
@@ -14,11 +14,9 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=17b064789fab936a1c58c4e13d965b0f \
DEPENDS += libxext inputproto
PE = 1
-PR = r0
+PR = r1
XORG_PN = libXi
-EXTRA_OECONF_append = --enable-specs=no
-
SRC_URI[md5sum] = 78ee882e1ff3b192cf54070bdb19938e
SRC_URI[sha256sum] =
f2e3627d7292ec5eff488ab58867fba14a62f06e72a8d3337ab6222c09873109
diff --git a/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
b/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
index 55eaf49..c911925 100644
--- a/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
+++ b/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
@@ -13,7 +13,8 @@ S = ${WORKDIR}/${XORG_PN}-${PV}
inherit autotools pkgconfig
-EXTRA_OECONF = --enable-malloc0returnsnull --with-fop=no --without-xmlto
+EXTRA_OECONF = --enable-malloc0returnsnull \
+--disable-specs --with-groff=no --with-ps2pdf=no --with-fop=no
--without-xmlto
python () {
whitelist = [ pixman, libpciaccess ]
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 10/18] libx11: make bigfont an optional (disabled by default) packageconfig option
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11.inc |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index 85fdbe7..d56aa23 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -11,7 +11,7 @@ inherit siteinfo
FILESPATH = ${FILE_DIRNAME}/libx11
PE = 1
-INC_PR = r6
+INC_PR = r7
PROVIDES = virtual/libx11
@@ -20,7 +20,7 @@ LICENSE = MIT MIT-style BSD
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
DEPENDS += xproto xextproto xtrans libxcb kbproto inputproto
-DEPENDS += xf86bigfontproto xproto-native
+DEPENDS += xproto-native
PACKAGES =+ ${PN}-xcb
@@ -30,9 +30,11 @@ FILES_${PN}-locale += ${datadir}/X11/locale
${libdir}/X11/locale
EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11/
-# Almost nothing uses XCMS
+# Let people with incredibly archaic requirements enable Xcms and BigFont, but
+# disable them by default.
PACKAGECONFIG ??=
PACKAGECONFIG[xcms] = --enable-xcms,--disable-xcms
+PACKAGECONFIG[bigfont] =
--enable-xf86bigfont,--disable-xf86bigfont,xf86bigfontproto
do_compile_prepend() {
cd ${S}/src/util
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 08/18] libx11: merge patches into a single directory
Signed-off-by: Ross Burton ross.bur...@intel.com --- .../xorg-lib/libx11-1.5.0/keysymdef_include.patch | 23 - .../libx11-1.5.0/makekeys_crosscompile.patch | 76 --- .../libx11-1.5.0/x11_disable_makekeys.patch| 34 -- .../xorg-lib/libx11-diet-1.5.0/X18NCMSstubs.diff | 541 .../libx11-diet-1.5.0/fix-disable-xlocale.diff | 17 - .../libx11-diet-1.5.0/fix-utf8-wrong-define.patch | 19 - .../libx11-diet-1.5.0/keysymdef_include.patch | 23 - .../libx11-diet-1.5.0/x11_disable_makekeys.patch | 34 -- .../libx11-trim-1.5.0/keysymdef_include.patch | 23 - .../libx11-trim-1.5.0/makekeys_crosscompile.patch | 76 --- .../libx11-trim-1.5.0/x11_disable_makekeys.patch | 34 -- meta/recipes-graphics/xorg-lib/libx11.inc |4 +- .../xorg-lib/libx11/X18NCMSstubs.diff | 541 .../xorg-lib/libx11/fix-disable-xlocale.diff | 17 + .../xorg-lib/libx11/fix-utf8-wrong-define.patch| 19 + .../xorg-lib/libx11/keysymdef_include.patch| 23 + .../xorg-lib/libx11/makekeys_crosscompile.patch| 76 +++ .../xorg-lib/libx11/x11_disable_makekeys.patch | 34 ++ 18 files changed, 713 insertions(+), 901 deletions(-) delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-1.5.0/keysymdef_include.patch delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-1.5.0/makekeys_crosscompile.patch delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-1.5.0/x11_disable_makekeys.patch delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.5.0/X18NCMSstubs.diff delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.5.0/fix-disable-xlocale.diff delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.5.0/fix-utf8-wrong-define.patch delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.5.0/keysymdef_include.patch delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-diet-1.5.0/x11_disable_makekeys.patch delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-trim-1.5.0/keysymdef_include.patch delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-trim-1.5.0/makekeys_crosscompile.patch delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-trim-1.5.0/x11_disable_makekeys.patch create mode 100644 meta/recipes-graphics/xorg-lib/libx11/X18NCMSstubs.diff create mode 100644 meta/recipes-graphics/xorg-lib/libx11/fix-disable-xlocale.diff create mode 100644 meta/recipes-graphics/xorg-lib/libx11/fix-utf8-wrong-define.patch create mode 100644 meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch create mode 100644 meta/recipes-graphics/xorg-lib/libx11/makekeys_crosscompile.patch create mode 100644 meta/recipes-graphics/xorg-lib/libx11/x11_disable_makekeys.patch diff --git a/meta/recipes-graphics/xorg-lib/libx11-1.5.0/keysymdef_include.patch b/meta/recipes-graphics/xorg-lib/libx11-1.5.0/keysymdef_include.patch deleted file mode 100644 index d1bdab9..000 --- a/meta/recipes-graphics/xorg-lib/libx11-1.5.0/keysymdef_include.patch +++ /dev/null @@ -1,23 +0,0 @@ -Upstream-Status: Inappropriate [configuration] - -Signed-off-by: Martin Jansa martin.ja...@gmail.com - -diff -uNr libX11-1.3.6.orig//configure.ac libX11-1.3.6/configure.ac libX11-1.3.6.orig//configure.ac2010-09-20 08:04:16.0 +0200 -+++ libX11-1.3.6/configure.ac 2010-09-28 16:29:26.0 +0200 -@@ -355,7 +355,14 @@ - # Find keysymdef.h - # - AC_MSG_CHECKING([keysym definitions]) --KEYSYMDEFDIR=`$PKG_CONFIG --variable=includedir xproto`/X11 -+AC_ARG_WITH(keysymdefdir, -+AC_HELP_STRING([--with-keysymdefdir=DIR], [The location of keysymdef.h]), -+KEYSYMDEFDIR=$withval, KEYSYMDEFDIR=) -+ -+if test x$KEYSYMDEFDIR = x; then -+ KEYSYMDEFDIR=`$PKG_CONFIG --variable=includedir xproto`/X11 -+fi -+ - FILES=keysymdef.h XF86keysym.h Sunkeysym.h DECkeysym.h HPkeysym.h - for i in $FILES; do - if test -f $KEYSYMDEFDIR/$i; then diff --git a/meta/recipes-graphics/xorg-lib/libx11-1.5.0/makekeys_crosscompile.patch b/meta/recipes-graphics/xorg-lib/libx11-1.5.0/makekeys_crosscompile.patch deleted file mode 100644 index daf3696..000 --- a/meta/recipes-graphics/xorg-lib/libx11-1.5.0/makekeys_crosscompile.patch +++ /dev/null @@ -1,76 +0,0 @@ -Because the size of unsigned long is different between 32-bit -and 64-bit, judge whether target is 32-bit or 64-bit and tell -makekey. - -The error information from LSB Test suite is as follow: -VSW5TESTSUITE PURPOSE 7 -Assertion XStringToKeysym-7.(A) -When the string argument is the name of a KeySym in the -table with the prefix XK_ removed, then a call to -XStringToKeysym returns that KeySym. -METH: For each KeySym name in table with code G: -METH: Call XStringToKeysym to obtain the KeySym defined for that string. -METH: Verify that XStringToKeysym did not return NoSymbol. -METH: Verify that the returned string is correct. -CHECK: XStringToKeysym-7 1, line 130 -CHECK: XStringToKeysym-7 2, line
[OE-core] [RFC 15/18] libx11: drop makekeys_crosscompile.patch, effectively merged upstream
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../xorg-lib/libx11/makekeys_crosscompile.patch| 76
meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |3 +-
2 files changed, 1 insertion(+), 78 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-lib/libx11/makekeys_crosscompile.patch
diff --git a/meta/recipes-graphics/xorg-lib/libx11/makekeys_crosscompile.patch
b/meta/recipes-graphics/xorg-lib/libx11/makekeys_crosscompile.patch
deleted file mode 100644
index daf3696..000
--- a/meta/recipes-graphics/xorg-lib/libx11/makekeys_crosscompile.patch
+++ /dev/null
@@ -1,76 +0,0 @@
-Because the size of unsigned long is different between 32-bit
-and 64-bit, judge whether target is 32-bit or 64-bit and tell
-makekey.
-
-The error information from LSB Test suite is as follow:
-VSW5TESTSUITE PURPOSE 7
-Assertion XStringToKeysym-7.(A)
-When the string argument is the name of a KeySym in the
-table with the prefix XK_ removed, then a call to
-XStringToKeysym returns that KeySym.
-METH: For each KeySym name in table with code G:
-METH: Call XStringToKeysym to obtain the KeySym defined for that string.
-METH: Verify that XStringToKeysym did not return NoSymbol.
-METH: Verify that the returned string is correct.
-CHECK: XStringToKeysym-7 1, line 130
-CHECK: XStringToKeysym-7 2, line 140
-CHECK: XStringToKeysym-7 3, line 150
-CHECK: XStringToKeysym-7 4, line 160
-CHECK: XStringToKeysym-7 5, line 170
-CHECK: XStringToKeysym-7 6, line 180
-CHECK: XStringToKeysym-7 7, line 190
-CHECK: XStringToKeysym-7 8, line 200
-CHECK: XStringToKeysym-7 9, line 210
-CHECK: XStringToKeysym-7 10, line 220
-CHECK: XStringToKeysym-7 11, line 230
-CHECK: XStringToKeysym-7 12, line 240
-CHECK: XStringToKeysym-7 13, line 250
-CHECK: XStringToKeysym-7 14, line 260
-CHECK: XStringToKeysym-7 15, line 270
-CHECK: XStringToKeysym-7 16, line 280
-CHECK: XStringToKeysym-7 17, line 290
-CHECK: XStringToKeysym-7 18, line 300
-CHECK: XStringToKeysym-7 19, line 310
-CHECK: XStringToKeysym-7 20, line 320
-
-Upstream-Status: Pending
-
-Signed-off-by: dbuit...@windriver.com
-
libX11-1.3.4.orig/src/util/makekeys.c 2010-01-15 09:11:36.0
+0800
-+++ libX11-1.3.4/src/util/makekeys.c 2011-05-24 19:04:25.454774908 +0800
-@@ -33,6 +33,7 @@
- #include X11/keysymdef.h
- #include stdio.h
- #include stdlib.h
-+#include stdint.h
-
- typedef unsigned long Signature;
-
-@@ -124,7 +125,12 @@
- name = info[i].name;
- sig = 0;
- while ((c = *name++))
-- sig = (sig 1) + c;
-+#ifdef USE32
-+ sig = (uint32_t)(sig 1) + c;
-+#else
-+ sig = (uint64_t)(sig 1) + c;
-+#endif
-+
- first = j = sig % z;
- for (k = 0; tab[j]; k++) {
- j += first + 1;
-@@ -163,7 +169,11 @@
- name = info[i].name;
- sig = 0;
- while ((c = *name++))
-- sig = (sig 1) + c;
-+#ifdef USE32
-+ sig = (uint32_t)(sig 1) + c;
-+#else
-+ sig = (uint64_t)(sig 1) + c;
-+#endif
- first = j = sig % z;
- while (offsets[j]) {
- j += first + 1;
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
index c138785..5a66eb5 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
@@ -1,13 +1,12 @@
require libx11.inc
inherit gettext
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
BBCLASSEXTEND = native nativesdk
SRC_URI += file://keysymdef_include.patch \
file://x11_disable_makekeys.patch \
- file://makekeys_crosscompile.patch \
SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 07/18] libx11: remove redundant license data
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |2 --
meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb |3 ---
2 files changed, 5 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index 9a7de33..04ee1b8 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -3,8 +3,6 @@ require libx11.inc
DESCRIPTION += Support for XCMS and XLOCALE is disabled in \
this version.
-LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-
PR = ${INC_PR}.2
SRC_URI += file://x11_disable_makekeys.patch \
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
index 714b993..6550903 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
@@ -2,9 +2,6 @@ require libx11.inc
DESCRIPTION += Support for XCMS is disabled in this version.
-LICENSE = MIT MIT-style BSD
-LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-
PR = ${INC_PR}.0
DEPENDS += libxcb xproto xextproto xtrans libxau kbproto inputproto
xf86bigfontproto xproto-native
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 11/18] libx11-diet: remove statements that are redundant
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index 5ab..cb9a5ef 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -3,7 +3,7 @@ require libx11.inc
DESCRIPTION += Support for XCMS and XLOCALE is disabled in \
this version.
-PR = ${INC_PR}.2
+PR = ${INC_PR}.3
SRC_URI += file://x11_disable_makekeys.patch \
file://X18NCMSstubs.diff \
@@ -18,8 +18,4 @@ RPROVIDES_${PN}-locale = libx11-locale
SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
SRC_URI[sha256sum] =
c382efd7e92bfc3cef39a4b7f1ecf2744ba4414a705e3bc1e697f75502bd4d86
-FILESDIR = ${@os.path.dirname(d.getVar('FILE', True))}/libx11
-
EXTRA_OECONF += --disable-xlocale
-CFLAGS += -D_GNU_SOURCE
-
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 03/18] libx11-diet: you can't disable UDC, because it's always disabled
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index d821744..e6aa63f 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -1,11 +1,11 @@
require libx11.inc
-DESCRIPTION += Support for UDC, XCMS and XLOCALE is disabled in \
+DESCRIPTION += Support for XCMS and XLOCALE is disabled in \
this version.
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-PR = ${INC_PR}.1
+PR = ${INC_PR}.2
SRC_URI += file://x11_disable_makekeys.patch \
file://X18NCMSstubs.diff \
@@ -25,6 +25,6 @@ DEPENDS += libxcb bigreqsproto xproto xextproto xtrans
libxau xcmiscproto \
FILESDIR = ${@os.path.dirname(d.getVar('FILE', True))}/libx11
-EXTRA_OECONF += --disable-udc --disable-xcms --disable-xlocale
--with-keysymdefdir=${STAGING_INCDIR}/X11
+EXTRA_OECONF += --disable-xcms --disable-xlocale
--with-keysymdefdir=${STAGING_INCDIR}/X11
CFLAGS += -D_GNU_SOURCE
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 16/18] libx11: makekeys can be cross-compiled now, so don't hack around
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |5 +--
meta/recipes-graphics/xorg-lib/libx11.inc | 43 ++--
.../xorg-lib/libx11/x11_disable_makekeys.patch | 34
meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |4 +-
4 files changed, 16 insertions(+), 70 deletions(-)
delete mode 100644
meta/recipes-graphics/xorg-lib/libx11/x11_disable_makekeys.patch
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index cb9a5ef..0a90f46 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -3,10 +3,9 @@ require libx11.inc
DESCRIPTION += Support for XCMS and XLOCALE is disabled in \
this version.
-PR = ${INC_PR}.3
+PR = ${INC_PR}.4
-SRC_URI += file://x11_disable_makekeys.patch \
-file://X18NCMSstubs.diff \
+SRC_URI += file://X18NCMSstubs.diff \
file://keysymdef_include.patch \
file://fix-disable-xlocale.diff \
file://fix-utf8-wrong-define.patch \
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index d56aa23..3ecd9e5 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -11,7 +11,7 @@ inherit siteinfo
FILESPATH = ${FILE_DIRNAME}/libx11
PE = 1
-INC_PR = r7
+INC_PR = r8
PROVIDES = virtual/libx11
@@ -22,12 +22,6 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
DEPENDS += xproto xextproto xtrans libxcb kbproto inputproto
DEPENDS += xproto-native
-PACKAGES =+ ${PN}-xcb
-
-FILES_${PN} += ${datadir}/X11/XKeysymDB ${datadir}/X11/XErrorDB
${libdir}/X11/Xcms.txt
-FILES_${PN}-xcb += ${libdir}/libX11-xcb.so.*
-FILES_${PN}-locale += ${datadir}/X11/locale ${libdir}/X11/locale
-
EXTRA_OECONF += --with-keysymdefdir=${STAGING_INCDIR}/X11/
# Let people with incredibly archaic requirements enable Xcms and BigFont, but
@@ -36,29 +30,18 @@ PACKAGECONFIG ??=
PACKAGECONFIG[xcms] = --enable-xcms,--disable-xcms
PACKAGECONFIG[bigfont] =
--enable-xf86bigfont,--disable-xf86bigfont,xf86bigfontproto
-do_compile_prepend() {
- cd ${S}/src/util
- mv makekeys.c.orig makekeys.c || true
- touch makekeys-makekeys.o
- (
- unset CC LD CXX CCLD CFLAGS CPPFLAGS LDFLAGS CXXFLAGS
- # MIN_REHASH 10 is only in 1.0.1
- sed -i -e 's:MIN_REHASH 10:MIN_REHASH 16:g' makekeys.c
- sed -i -e 's:MIN_REHASH 15:MIN_REHASH 16:g' makekeys.c
- touch makekeys-makekeys.o;
- if [ ${SITEINFO_BITS} == 64 ]; then
- ${BUILD_CC} ${BUILD_CFLAGS} -I${STAGING_INCDIR_NATIVE}
makekeys.c -I${S}/include -o makekeys
- else
- ${BUILD_CC} ${BUILD_CFLAGS} -I${STAGING_INCDIR_NATIVE}
-DUSE32 makekeys.c -I${S}/include -o makekeys
- fi
- )
- if [ $? != 0 ]; then
- exit 1
- fi
- # mv to stop it getting rebuilt
- mv makekeys.c makekeys.c.orig
- cd ../../
-}
+# src/util/makekeys needs to be compiled natively, so tell it what compiler to
+# use.
+export CC_FOR_BUILD = ${BUILD_CC}
+export CFLAGS_FOR_BUILD = ${BUILD_CFLAGS}
+export CPPFLAGS_FOR_BUILD = ${BUILD_CPPFLAGS}
+export LDFLAGS_FOR_BUILD = ${BUILD_LDFLAGS}
+
+PACKAGES =+ ${PN}-xcb
+
+FILES_${PN} += ${datadir}/X11/XKeysymDB ${datadir}/X11/XErrorDB
${libdir}/X11/Xcms.txt
+FILES_${PN}-xcb += ${libdir}/libX11-xcb.so.*
+FILES_${PN}-locale += ${datadir}/X11/locale ${libdir}/X11/locale
# Multiple libx11 derivatives from from this file and are selected by
virtual/libx11
# A world build should only build the correct version, not all of them.
diff --git a/meta/recipes-graphics/xorg-lib/libx11/x11_disable_makekeys.patch
b/meta/recipes-graphics/xorg-lib/libx11/x11_disable_makekeys.patch
deleted file mode 100644
index 69f9e6c..000
--- a/meta/recipes-graphics/xorg-lib/libx11/x11_disable_makekeys.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-Upstream-Status: Pending
-
-Index: libX11-1.5.0/src/util/Makefile.am
-===
libX11-1.5.0.orig/src/util/Makefile.am
-+++ libX11-1.5.0/src/util/Makefile.am
-@@ -1,27 +1,2 @@
--
--noinst_PROGRAMS=makekeys
--
--makekeys_CFLAGS = \
-- $(X11_CFLAGS) \
-- $(CWARNFLAGS)
--
--makekeys_CPPFLAGS = \
-- -I$(top_srcdir)/include
--
--CC = @CC_FOR_BUILD@
--CPPFLAGS = @CPPFLAGS_FOR_BUILD@
--CFLAGS = @CFLAGS_FOR_BUILD@
--LDFLAGS = @LDFLAGS_FOR_BUILD@
--
- EXTRA_DIST = mkks.sh
-
--if LINT
--# Check source code with tools like lint sparse
--
--ALL_LINT_FLAGS=$(LINT_FLAGS) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
-- $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS)
--
--lint:
-- $(LINT) $(ALL_LINT_FLAGS) makekeys.c
--
--endif LINT
diff --git
[OE-core] [RFC 02/18] libx11-diet: you can't disable XCB anymore, so don't try
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index ed5a890..d821744 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -1,11 +1,11 @@
require libx11.inc
-DESCRIPTION += Support for XCB, UDC, XCMS and XLOCALE is disabled in \
+DESCRIPTION += Support for UDC, XCMS and XLOCALE is disabled in \
this version.
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
SRC_URI += file://x11_disable_makekeys.patch \
file://X18NCMSstubs.diff \
@@ -20,11 +20,11 @@ RPROVIDES_${PN}-locale = libx11-locale
SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
SRC_URI[sha256sum] =
c382efd7e92bfc3cef39a4b7f1ecf2744ba4414a705e3bc1e697f75502bd4d86
-DEPENDS += bigreqsproto xproto xextproto xtrans libxau xcmiscproto \
+DEPENDS += libxcb bigreqsproto xproto xextproto xtrans libxau xcmiscproto \
libxdmcp xf86bigfontproto kbproto inputproto xproto-native
FILESDIR = ${@os.path.dirname(d.getVar('FILE', True))}/libx11
-EXTRA_OECONF += --without-xcb --disable-udc --disable-xcms --disable-xlocale
--with-keysymdefdir=${STAGING_INCDIR}/X11
+EXTRA_OECONF += --disable-udc --disable-xcms --disable-xlocale
--with-keysymdefdir=${STAGING_INCDIR}/X11
CFLAGS += -D_GNU_SOURCE
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 14/18] distro-tracking: remove libx11-trim
Signed-off-by: Ross Burton ross.bur...@intel.com --- meta-yocto/conf/distro/include/distro_alias.inc |1 - meta-yocto/conf/distro/include/maintainers.inc |1 - meta-yocto/conf/distro/include/recipe_color.inc |1 - 3 files changed, 3 deletions(-) diff --git a/meta-yocto/conf/distro/include/distro_alias.inc b/meta-yocto/conf/distro/include/distro_alias.inc index c63bd47..509dcde 100644 --- a/meta-yocto/conf/distro/include/distro_alias.inc +++ b/meta-yocto/conf/distro/include/distro_alias.inc @@ -183,7 +183,6 @@ DISTRO_PN_ALIAS_pn-liburcu = Fedora=userspace-rcu Ubuntu=liburcu0 DISTRO_PN_ALIAS_pn-libusb-compat = OSPDT DISTRO_PN_ALIAS_pn-libx11 = Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11 DISTRO_PN_ALIAS_pn-libx11-diet = Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11 -DISTRO_PN_ALIAS_pn-libx11-trim = Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11 DISTRO_PN_ALIAS_pn-libxcalibrate = OSPDT upstream=http://cgit.freedesktop.org/xorg/lib/libXCalibrate/; DISTRO_PN_ALIAS_pn-libxfontcache = Mandriva=libxfontcache Debian=libxfontcache DISTRO_PN_ALIAS_pn-libxft = Mandriva=libxft Debian=libxft2 Ubuntu=libxft2 diff --git a/meta-yocto/conf/distro/include/maintainers.inc b/meta-yocto/conf/distro/include/maintainers.inc index dace3b9..fe8284e 100644 --- a/meta-yocto/conf/distro/include/maintainers.inc +++ b/meta-yocto/conf/distro/include/maintainers.inc @@ -358,7 +358,6 @@ RECIPE_MAINTAINER_pn-libuser = Valentin Popa valentin.p...@intel.com RECIPE_MAINTAINER_pn-libvorbis = Cristian Iorga cristian.io...@intel.com RECIPE_MAINTAINER_pn-libx11 = Valentin Popa valentin.p...@intel.com RECIPE_MAINTAINER_pn-libx11-diet = Kai Kang kai.k...@windriver.com -RECIPE_MAINTAINER_pn-libx11-trim = Valentin Popa valentin.p...@intel.com RECIPE_MAINTAINER_pn-libxau = Valentin Popa valentin.p...@intel.com RECIPE_MAINTAINER_pn-libxaw = Valentin Popa valentin.p...@intel.com RECIPE_MAINTAINER_pn-libxcalibrate = Valentin Popa valentin.p...@intel.com diff --git a/meta-yocto/conf/distro/include/recipe_color.inc b/meta-yocto/conf/distro/include/recipe_color.inc index 612a698..894c76a 100644 --- a/meta-yocto/conf/distro/include/recipe_color.inc +++ b/meta-yocto/conf/distro/include/recipe_color.inc @@ -210,7 +210,6 @@ RECIPE_COLOR_pn-liburcu = yellow RECIPE_COLOR_pn-libusb1 = yellow RECIPE_COLOR_pn-libuser = yellow RECIPE_COLOR_pn-libx11 = yellow -RECIPE_COLOR_pn-libx11-trim = yellow RECIPE_COLOR_pn-libxau = yellow RECIPE_COLOR_pn-libxaw = red RECIPE_COLOR_pn-libxcalibrate = yellow -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Sato virtual keyboard - how to close it?
On 09/11/2012 12:16 PM, Burton, Ross wrote: On 11 September 2012 20:13, Scott Garman scott.a.gar...@intel.com wrote: In the Sato desktop, there is a virtual keyboard which you can bring up to enter text from a touchscreen interface. Once that keyboard pops up, how do you close it? I'm not seeing anything obvious. I'm helping out with a demo at a conference and could use this info urgently. Moving the focus from a text field will do it. I thought there was a keyboard icon on the panel which should explicitly hide it, but maybe not. Negatory on both counts. Sounds like a bug? Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 09/18] libx11: refresh dependencies, and centralise into libx11.inc
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb |3 ---
meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb |2 --
meta/recipes-graphics/xorg-lib/libx11.inc |5 -
meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |5 -
4 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
index 04ee1b8..5ab 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.5.0.bb
@@ -18,9 +18,6 @@ RPROVIDES_${PN}-locale = libx11-locale
SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
SRC_URI[sha256sum] =
c382efd7e92bfc3cef39a4b7f1ecf2744ba4414a705e3bc1e697f75502bd4d86
-DEPENDS += libxcb bigreqsproto xproto xextproto xtrans libxau xcmiscproto \
-libxdmcp xf86bigfontproto kbproto inputproto xproto-native
-
FILESDIR = ${@os.path.dirname(d.getVar('FILE', True))}/libx11
EXTRA_OECONF += --disable-xlocale
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
index 6550903..6619946 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
@@ -4,8 +4,6 @@ DESCRIPTION += Support for XCMS is disabled in this version.
PR = ${INC_PR}.0
-DEPENDS += libxcb xproto xextproto xtrans libxau kbproto inputproto
xf86bigfontproto xproto-native
-
SRC_URI += file://x11_disable_makekeys.patch \
file://keysymdef_include.patch \
file://makekeys_crosscompile.patch
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc
b/meta/recipes-graphics/xorg-lib/libx11.inc
index 1e9f942..85fdbe7 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -11,7 +11,7 @@ inherit siteinfo
FILESPATH = ${FILE_DIRNAME}/libx11
PE = 1
-INC_PR = r5
+INC_PR = r6
PROVIDES = virtual/libx11
@@ -19,6 +19,9 @@ XORG_PN = libX11
LICENSE = MIT MIT-style BSD
LIC_FILES_CHKSUM = file://COPYING;md5=172255dee66bb0151435b2d5d709fcf7
+DEPENDS += xproto xextproto xtrans libxcb kbproto inputproto
+DEPENDS += xf86bigfontproto xproto-native
+
PACKAGES =+ ${PN}-xcb
FILES_${PN} += ${datadir}/X11/XKeysymDB ${datadir}/X11/XErrorDB
${libdir}/X11/Xcms.txt
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
index 0ba0f9b..c138785 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
@@ -5,11 +5,6 @@ PR = ${INC_PR}.0
BBCLASSEXTEND = native nativesdk
-DEPENDS += util-macros xtrans libxdmcp libxau \
-bigreqsproto xproto xextproto xcmiscproto \
-xf86bigfontproto kbproto inputproto libxcb \
-xproto-native
-
SRC_URI += file://keysymdef_include.patch \
file://x11_disable_makekeys.patch \
file://makekeys_crosscompile.patch \
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 18/18] libx11: revise keysymdef patch based on submission upstream
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../xorg-lib/libx11/keysymdef_include.patch| 38
meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb |2 +-
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch
b/meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch
index d1bdab9..ba65319 100644
--- a/meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch
+++ b/meta/recipes-graphics/xorg-lib/libx11/keysymdef_include.patch
@@ -1,23 +1,47 @@
-Upstream-Status: Inappropriate [configuration]
+From 547937d82084f2cce7e3f0849b5112a20c467146 Mon Sep 17 00:00:00 2001
+From: Ross Burton ross.bur...@intel.com
+Date: Tue, 11 Sep 2012 17:39:12 +0100
+Subject: [PATCH] Allow overriding location of keysymdef.h
-Signed-off-by: Martin Jansa martin.ja...@gmail.com
+Currently keysymdef.h is found by using the includedir of xproto. This doesn't
+work when cross-compiling with a sysroot as that ends up being
/usr/include/X11,
+not a path into the cross-build environment.
-diff -uNr libX11-1.3.6.orig//configure.ac libX11-1.3.6/configure.ac
libX11-1.3.6.orig//configure.ac2010-09-20 08:04:16.0 +0200
-+++ libX11-1.3.6/configure.ac 2010-09-28 16:29:26.0 +0200
-@@ -355,7 +355,14 @@
+So, add an option to allow explicitly specifying the location of keysymdef.h,
+and verify that the specified or found path exists.
+
+(original patch by Martin Jansa martin.ja...@gmail.com, revised by myself)
+
+Upstream-Status: Submitted [xorg-devel]
+Signed-off-by: Ross Burton ross.bur...@intel.com
+---
+ configure.ac | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 48a0c8a..200db15 100644
+--- a/configure.ac
b/configure.ac
+@@ -306,7 +306,18 @@ AC_CHECK_FUNC(poll, [AC_DEFINE(USE_POLL, 1, [poll()
function is available])], )
# Find keysymdef.h
#
AC_MSG_CHECKING([keysym definitions])
-KEYSYMDEFDIR=`$PKG_CONFIG --variable=includedir xproto`/X11
+AC_ARG_WITH(keysymdefdir,
-+AC_HELP_STRING([--with-keysymdefdir=DIR], [The location of
keysymdef.h]),
++AC_HELP_STRING([--with-keysymdefdir=DIR], [The location of
keysymdef.h (defaults to xproto include dir)]),
+KEYSYMDEFDIR=$withval, KEYSYMDEFDIR=)
+
+if test x$KEYSYMDEFDIR = x; then
+ KEYSYMDEFDIR=`$PKG_CONFIG --variable=includedir xproto`/X11
+fi
+
++if test ! -d $KEYSYMDEFDIR; then
++ AC_MSG_ERROR([$KEYSYMDEFDIR doesn't exist or isn't a directory])
++fi
++
FILES=keysymdef.h XF86keysym.h Sunkeysym.h DECkeysym.h HPkeysym.h
for i in $FILES; do
if test -f $KEYSYMDEFDIR/$i; then
+--
+1.7.10.4
+
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
index 793496c..94e2051 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.5.0.bb
@@ -1,7 +1,7 @@
require libx11.inc
inherit gettext
-PR = ${INC_PR}.1
+PR = ${INC_PR}.2
BBCLASSEXTEND = native nativesdk
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 13/18] libx11-trim: remove, it's the same as libx11 now
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb | 15 ---
1 file changed, 15 deletions(-)
delete mode 100644 meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
diff --git a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
deleted file mode 100644
index 6619946..000
--- a/meta/recipes-graphics/xorg-lib/libx11-trim_1.5.0.bb
+++ /dev/null
@@ -1,15 +0,0 @@
-require libx11.inc
-
-DESCRIPTION += Support for XCMS is disabled in this version.
-
-PR = ${INC_PR}.0
-
-SRC_URI += file://x11_disable_makekeys.patch \
-file://keysymdef_include.patch \
-file://makekeys_crosscompile.patch
-
-RPROVIDES_${PN}-dev = libx11-dev
-RPROVIDES_${PN}-locale = libx11-locale
-
-SRC_URI[md5sum] = 78b4b3bab4acbdf0abcfca30a8c70cc6
-SRC_URI[sha256sum] =
c382efd7e92bfc3cef39a4b7f1ecf2744ba4414a705e3bc1e697f75502bd4d86
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC 17/18] libx11-diet: remove un-needed chunk from stubs patch
Signed-off-by: Ross Burton ross.bur...@intel.com --- .../xorg-lib/libx11/X18NCMSstubs.diff | 20 1 file changed, 20 deletions(-) diff --git a/meta/recipes-graphics/xorg-lib/libx11/X18NCMSstubs.diff b/meta/recipes-graphics/xorg-lib/libx11/X18NCMSstubs.diff index 8cd1870..9e91a8b 100644 --- a/meta/recipes-graphics/xorg-lib/libx11/X18NCMSstubs.diff +++ b/meta/recipes-graphics/xorg-lib/libx11/X18NCMSstubs.diff @@ -519,23 +519,3 @@ Index: libX11-1.3/src/locking.c _XLockMutex_fn = _XLockMutex; _XUnlockMutex_fn = _XUnlockMutex; _XCreateMutex_fn = _XCreateMutex; -Index: libX11-1.3/configure.ac -=== libX11-1.3.orig/configure.ac -+++ libX11-1.3/configure.ac -@@ -289,7 +289,14 @@ else - fi - AC_SUBST(KEYSYMDEF) - --AM_CONDITIONAL(UDC, test xfalse = xtrue) -+AC_ARG_ENABLE(udc, -+ AC_HELP_STRING([--disable-udc], -+[Disable Xlib support for UDC *EXPERIMENTAL*]), -+ [UDC=$enableval],[UDC=yes]) -+AM_CONDITIONAL(UDC, [test x$UDC = xyes ]) -+if test x$UDC = xyes; then -+ AC_DEFINE(UDC,1,[Include support for UDC]) -+fi - - AC_ARG_ENABLE(xcms, - AC_HELP_STRING([--disable-xcms], -- 1.7.10 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Sato virtual keyboard - how to close it?
On 11 September 2012 20:19, Scott Garman scott.a.gar...@intel.com wrote: Negatory on both counts. Sounds like a bug? Certainly does. Not sure how that regressed or how QA didn't notice. So clicking on a button or check box doesn't make the keyboard hide? Eek. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Sato virtual keyboard - how to close it?
On 09/11/2012 12:23 PM, Burton, Ross wrote: On 11 September 2012 20:19, Scott Garman scott.a.gar...@intel.com wrote: Negatory on both counts. Sounds like a bug? Certainly does. Not sure how that regressed or how QA didn't notice. So clicking on a button or check box doesn't make the keyboard hide? Eek. Eek, indeed! I just tested with the last bernard point-release, and it too has the same issue. I understand Sato may be going by the wayside, but in case anyone wants to fix this, I've filed bug #3093 for it: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3093 Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] linux-yocto/3.4: v3.4.10 and uprobes/kprobes configuration updates
On 12-09-11 09:33 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 09:27:50AM -0400, Bruce Ashfield wrote:
On 12-09-11 08:37 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 08:31:42AM -0400, Bruce Ashfield wrote:
On 12-09-11 02:59 AM, Martin Jansa wrote:
On Mon, Sep 10, 2012 at 8:11 PM, Bruce Ashfield
bruce.ashfi...@windriver.comwrote:
Updating to 3.4.10 which has been soaking for a bit now, as well
as picking up the following meta commits from Tom Z:
a82db2f meta: have systemtap use kprobes and uprobes feature
d5d5b80 meta: add kprobes support to ktypes/standard
b32d373 meta: add kprobes feature
d40ed99 meta: have uprobe feature use uprobe.cfg
a69d1db meta: add uprobe.cfg
Signed-off-by: Bruce Ashfieldbruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb |8
meta/recipes-kernel/linux/linux-yocto_3.4.bb| 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index b2620ea..3b36378 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = standard/preempt-rt/base
KBRANCH_qemuppc = standard/preempt-rt/qemuppc
-LINUX_VERSION ?= 3.4.9
+LINUX_VERSION ?= 3.4.10
LINUX_KERNEL_TYPE = preempt-rt
KMETA = meta
-SRCREV_machine ?= 9032b1e9daf5b4396f939981c3be95f67802d18c
-SRCREV_machine_qemuppc ?= 08ce190232f89303772b6591ca7daaf2820eb74e
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine ?= a35693b1287c0e50cdca33a1b95af0ff48b43cd0
+SRCREV_machine_qemuppc ?= 85a1190530cb5749f5f831670976b163438dc301
+SRCREV_meta ?= d9d5fc63d8b38705036e946ea77d971d95de11ad
PR = ${INC_PR}.0
PV = ${LINUX_VERSION}+git${SRCPV}
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 06bcb9a..7258cba 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH_DEFAULT = standard/base
KBRANCH = ${KBRANCH_DEFAULT}
-SRCREV_machine_qemuarm ?= 84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
-SRCREV_machine_qemumips ?= ba0e336d4527080233c3c410989d4f351529ee4e
-SRCREV_machine_qemuppc ?= e82b8a111430e3820b11f507863c4b8e8734ed8e
-SRCREV_machine_qemux86 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine_qemux86-64 ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_machine ?= 0985844fa6235422c67ef269952fa4e765f252f9
-SRCREV_meta ?= 463299bc2e533e1bd38b0053ae7b210980f269c3
+SRCREV_machine_qemuarm ?= b15e7b1e9b58b9863bd87778775f86cd8d8880ea
+SRCREV_machine_qemumips ?= 8d5b98f263b5119af2dc30223f311be17173bab9
+SRCREV_machine_qemuppc ?= b9a720ca38d298ed457f37d099c85771f9164b19
+SRCREV_machine_qemux86 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine_qemux86-64 ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_machine ?= 46d8c757b3be1953f30d6745505d24436e2d6844
+SRCREV_meta ?= a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab
Doesn't different SRCREV_machine for each MACHINE cause LOCALCOUNT in
SRCPV incrementing on each MACHINE switch?
They are stored under same key:
sqliteselect * from BB_URI_LOCALCOUNT where key like '%linux-yocto-3.4%';
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_rev|84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_count|16
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_count|9
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_rev|19f7e43b54aef08d58135ed2a897d77b624b320a
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_count|7
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_rev|9032b1e9daf5b4396f939981c3be95f67802d18c
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_count|10
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_count|8
So I guess if you build linux-yocto-3.4 for qemuarm, qemux86-64, then
switch back to qemuarm you'll see linux-yocto built again, same
source, but different SRCPV (LOCALCOUNT).
That does look to be the case, and it matches what I've observed
over time. I'm not sure of an alternative at the moment, since the
fetcher is such a cranky beast with respect to fetching changes to
the right machine branches.
Why not remove it from SRCREV_FORMAT, keep only meta SRCPV and just bump
PR when SRCREV of some machine kbranch is changed?
I like the sound of it, but as far
Re: [OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
On (11/09/12 19:53), Phil Blundell wrote:
On Tue, 2012-09-11 at 11:40 -0700, Khem Raj wrote:
On Tue, Sep 11, 2012 at 9:13 AM, Koen Kooi k...@dominion.thruhere.net
wrote:
From a gcc point of view both are the same ISA, but using xscale will
take in account the absurdly long pipeline on that SoC.
Not really, when you tune for XScale it will use ldrd/strd and pld if
possible
Are you sure? As far as I remember, the only effects of -mtune=xscale
are to alter some minor pipeline-related tradeoffs in code generation.
In particular, LDM is especially slow on xscale so it is usually best
avoided unless loading very large numbers of registers.
yes that seems to be right looking at trunk and it does not prefer
LDRD/STRD/PLD too.
so all my claims are not valid anymore.
const struct tune_params arm_xscale_tune =
{
arm_xscale_rtx_costs,
xscale_sched_adjust_cost,
2,/* Constant limit. */
3,/* Max cond insns. */
ARM_PREFETCH_NOT_BENEFICIAL,
true, /* Prefer constant pool. */
arm_default_branch_cost,
false /* Prefer LDRD/STRD. */
};
I can't think of any reason why pld would be any more beneficial on
xscale than generic v5TE, and I don't think gcc does anything special
with it in that regard.
p.
--
-Khem
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] udev: upgrade to 182
On 09/06/2012 02:27 AM, Alex DAMIAN wrote:
From: Alexandru DAMIAN alexandru.dam...@intel.com
This is the final upgrade of udev. Futher upgrades will only
come in conjunction with systemd.
The v4l1 removal patch is deprecated as the bug is fixed inside udev.
There is a new patch fixing the path for default sh interpreter.
New debug binaries are generated, and udev.inc is modified to package
those correctly.
The install locations changed for udevd and udevadm, so the scripts
are updated accordingly.
Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
Alex,
I have had some problems with this patch trying to build it. It was
looking on my host for usbutils version .82 or greater, but we have the
new numbered 006 usbutils and it failed.
Also, why did you not take the meta-oe version, did you compare your
changes with the version is meta-oe? This was mentioned once before?
Thanks
Sau!
Conflicts:
meta/recipes-core/udev/udev_164.bb
---
.../initscripts/initscripts-1.0/volatiles |2 +-
meta/recipes-core/udev/udev.inc| 12 +++--
...yboard_force_release.sh-shell-script-path.patch | 35 ++
meta/recipes-core/udev/udev/include_resource.patch | 31
meta/recipes-core/udev/udev/init | 14 +++---
meta/recipes-core/udev/udev/udev-166-v4l1-1.patch | 50
meta/recipes-core/udev/udev/udev-cache |2 +-
meta/recipes-core/udev/udev_164.bb |9
meta/recipes-core/udev/udev_182.bb |9
9 files changed, 61 insertions(+), 103 deletions(-)
create mode 100644
meta/recipes-core/udev/udev/0001-Fixing-keyboard_force_release.sh-shell-script-path.patch
delete mode 100644 meta/recipes-core/udev/udev/include_resource.patch
delete mode 100644 meta/recipes-core/udev/udev/udev-166-v4l1-1.patch
delete mode 100644 meta/recipes-core/udev/udev_164.bb
create mode 100644 meta/recipes-core/udev/udev_182.bb
diff --git a/meta/recipes-core/initscripts/initscripts-1.0/volatiles
b/meta/recipes-core/initscripts/initscripts-1.0/volatiles
index b2ae279..e0741aa 100644
--- a/meta/recipes-core/initscripts/initscripts-1.0/volatiles
+++ b/meta/recipes-core/initscripts/initscripts-1.0/volatiles
@@ -36,4 +36,4 @@ f root root 0664 /var/log/wtmp none
f root root 0664 /var/run/utmp none
l root root 0644 /etc/resolv.conf /var/run/resolv.conf
f root root 0644 /var/run/resolv.conf none
-
+l root root 0755 /run /var/run
diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index 9cc00e8..fafd9ce 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -6,9 +6,10 @@ LICENSE = GPLv2.0+ LGPLv2.1+
LICENSE_${PN} = GPLv2.0+
LICENSE_libudev = LGPLv2.1+
LICENSE_libgudev = LGPLv2.1+
-LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
-
file://libudev/COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
-
file://extras/gudev/COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343
+LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
+file://src/COPYING;md5=17c4e5fb495e6707ac92a3864926f979 \
+
file://src/gudev/COPYING;md5=fb494485a7d0505308cb68e4997cc266
+
DEPENDS = acl glib-2.0 libusb usbutils pciutils gperf-native libxslt-native
RPROVIDES_${PN} = hotplug
@@ -16,6 +17,7 @@ RRECOMMENDS_${PN} += udev-extraconf usbutils-ids
pciutils-ids
RDEPENDS_libudev = ${PN} (= ${EXTENDPKGV})
SRC_URI = ${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \
+
file://0001-Fixing-keyboard_force_release.sh-shell-script-path.patch \
file://run.rules \
file://udev.rules \
file://devfs-udev.rules \
@@ -32,7 +34,7 @@ inherit autotools pkgconfig update-rc.d
# udevd/udevadm - /sbin/, libudev.so.* - /lib/
sbindir = ${base_sbindir}
-libexecdir = ${base_libdir}/udev
+libexecdir = ${base_libdir}
EXTRA_OECONF = --disable-introspection --with-rootlibdir=${base_libdir} \
--with-pci-ids-path=${datadir}/pci.ids
@@ -50,6 +52,8 @@ FILES_${PN} += ${libexecdir} ${libdir}/ConsoleKit
RRECOMMENDS_${PN} += udev-utils
FILES_${PN}-dbg += ${libexecdir}/.debug
+FILES_${PN}-dbg += ${base_libdir}/udev/.debug/
+FILES_${PN}-dbg += ${base_libdir}/udev/.debug/*
FILES_${PN}-dev = ${datadir}/pkgconfig/udev.pc
FILES_libudev = ${base_libdir}/libudev.so.*
FILES_libudev-dbg = ${base_libdir}/.debug/libudev.so.*
diff --git
a/meta/recipes-core/udev/udev/0001-Fixing-keyboard_force_release.sh-shell-script-path.patch
b/meta/recipes-core/udev/udev/0001-Fixing-keyboard_force_release.sh-shell-script-path.patch
new file mode 100644
index 000..41deafa
--- /dev/null
+++
b/meta/recipes-core/udev/udev/0001-Fixing-keyboard_force_release.sh-shell-script-path.patch
@@ -0,0 +1,35 @@
+From 0f8290c943da298abd269ca60fd8375dfb219971 Mon Sep 17
Re: [OE-core] Sato virtual keyboard - how to close it?
On Tue, 2012-09-11 at 12:36 -0700, Scott Garman wrote: On 09/11/2012 12:23 PM, Burton, Ross wrote: On 11 September 2012 20:19, Scott Garman scott.a.gar...@intel.com wrote: Negatory on both counts. Sounds like a bug? Certainly does. Not sure how that regressed or how QA didn't notice. So clicking on a button or check box doesn't make the keyboard hide? Eek. Eek, indeed! I just tested with the last bernard point-release, and it too has the same issue. I understand Sato may be going by the wayside, but in case anyone wants to fix this, I've filed bug #3093 for it: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3093 There has been a bug open for this for years :( https://bugzilla.yoctoproject.org/show_bug.cgi?id=149 Ross appears to have recently closed it as NOTABUG but I think he misunderstood the problem. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] /usr/bin/python is needed by git
HI Mark, I sent a patch (see above) which added python as a dependency and that seemed to fix it. Whether or not this is the right fix I don't know... should git require the python binary to run? I really don't know much about it... I wonder what needs python in git. Can you inspect ? -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ 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
