[OE-core] [PATCH 2/4] pcmanfm: Upgrade to 0.9.10
From: Zhai Edwin edwin.z...@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
.../{pcmanfm_0.9.9.bb = pcmanfm_0.9.10.bb}|4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-sato/pcmanfm/{pcmanfm_0.9.9.bb = pcmanfm_0.9.10.bb} (88%)
diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_0.9.9.bb
b/meta/recipes-sato/pcmanfm/pcmanfm_0.9.10.bb
similarity index 88%
rename from meta/recipes-sato/pcmanfm/pcmanfm_0.9.9.bb
rename to meta/recipes-sato/pcmanfm/pcmanfm_0.9.10.bb
index af283f6..e62cb0d 100644
--- a/meta/recipes-sato/pcmanfm/pcmanfm_0.9.9.bb
+++ b/meta/recipes-sato/pcmanfm/pcmanfm_0.9.10.bb
@@ -24,8 +24,8 @@ SRC_URI = ${SOURCEFORGE_MIRROR}/pcmanfm/pcmanfm-${PV}.tar.gz
\
SRC_URI_append_poky = file://owl-window-menu.patch
-SRC_URI[md5sum] = f31ed6defb600f7046a456220d8efa3a
-SRC_URI[sha256sum] =
bc48af4ade638b47e4207cc274f6e38c2bd3786a811d20da47c3df9907c6fb6c
+SRC_URI[md5sum] = d34a3530a6c5dcd674d23021d71c3e95
+SRC_URI[sha256sum] =
f133c6f207f719d1fc69fe8bc07b2de6883c6937ffa87448df42e3b1a30e0298
inherit autotools pkgconfig
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] x11vnc: Upgrade to 0.9.13
From: Zhai Edwin edwin.z...@intel.com
Signed-off-by: Zhai Edwin edwin.z...@intel.com
---
.../x11vnc/{x11vnc_0.9.12.bb = x11vnc_0.9.13.bb} |8
1 files changed, 4 insertions(+), 4 deletions(-)
rename meta/recipes-graphics/x11vnc/{x11vnc_0.9.12.bb = x11vnc_0.9.13.bb}
(66%)
diff --git a/meta/recipes-graphics/x11vnc/x11vnc_0.9.12.bb
b/meta/recipes-graphics/x11vnc/x11vnc_0.9.13.bb
similarity index 66%
rename from meta/recipes-graphics/x11vnc/x11vnc_0.9.12.bb
rename to meta/recipes-graphics/x11vnc/x11vnc_0.9.13.bb
index 9bf7d41..4b8bed4 100644
--- a/meta/recipes-graphics/x11vnc/x11vnc_0.9.12.bb
+++ b/meta/recipes-graphics/x11vnc/x11vnc_0.9.13.bb
@@ -5,18 +5,18 @@ SECTION = x11/utils
AUTHOR = Karl Runge
LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=361b6b837cad26c6900a926b62aada5f \
-
file://x11vnc/x11vnc.h;endline=33;md5=ee4946e57bb73ecf93d7d98a3d48c6be
+
file://x11vnc/x11vnc.h;endline=33;md5=6f95dc6535467d7ee1563fd434fb372e
DEPENDS = openssl virtual/libx11 libxext avahi jpeg zlib
-PR = r2
+PR = r0
SRC_URI = ${SOURCEFORGE_MIRROR}/libvncserver/x11vnc/${PV}/x11vnc-${PV}.tar.gz\
file://starting-fix.patch \
file://endian-fix.patch
-SRC_URI[md5sum] = 1498a68d02aa7b6c97bf746c073c8d00
-SRC_URI[sha256sum] =
60a7cceee2c9a5f1c854340b2bae13f975ac55906237042f81f795b28a154a79
+SRC_URI[md5sum] = a372ec4fe8211221547b1c108cf56e4c
+SRC_URI[sha256sum] =
f6829f2e629667a5284de62b080b13126a0736499fe47cdb447aedb07a59f13b
inherit autotools
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
From: openembedded-core-boun...@lists.openembedded.org
[openembedded-core-boun...@lists.openembedded.org] on behalf of Richard
Purdie [richard.pur...@linuxfoundation.org]
Sent: Thursday, December 01, 2011 9:33 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] Coordinating inter-layer dependencies
On Thu, 2011-12-01 at 14:07 +0100, Martin Jansa wrote:
On Thu, Dec 01, 2011 at 10:59:03AM -0200, Otavio Salvador wrote:
On Thu, Dec 1, 2011 at 10:37, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote:
A while back I've proposed to make .bbappend without corresponding .bb
only big fat warning, but not fatal to parse. Now you cannot even
build
eglibc if there is libdrm bbappend you don't care at all about..
You can do this by setting:
BB_DANGLINGAPPENDS_WARNONLY
This is even worse; you end up with a package without the changes done on
the bbappend and as most bbappend files do not change PR, adding it later
won't force a package update.
If we find a way to allow PRINC in multiple bbappends for same .bb then
we can say that every .bbappend should use PRINC.
For record I'll include my discussion about PRINC with RP and kergoth:
10:47 JaMa RP__: is there any way to improve PRINC concept to allow
multiple increments for same recipe while parsing multiple layers?
10:48 RP__ JaMa: PRINC_append = .1 ?
10:49 JaMa RP__: ie when meta-openmoko sets PRINC = 1 and meta-shr
sets PRINC = 2 then if you're unlucky meta-openmoko is parsed later and
bumping PRINC in meta-shr won't help
10:49 RP__ JaMa: I wonder if you could do PRINC := ${PRINC + 1}
10:50 JaMa and do we have default PRINC = 0 somewhere?
10:50 RP__ JaMa: you might need to add that
10:50 JaMa ok, I'll try this, thanks
10:51 JaMa currently I'm moving PRINC only to meta-shr layer.. but that
breaks stuff if someone is using any BSP layer from meta-smartphone..
14:53 JaMa RP__: btw that PRINC trick didn't work (int type didn't like
expresion :/)
15:13 RP__ JaMa: ah, try PRINC := ${int(PRINC) + 1}
15:21 JaMa RP__: still ValueError: invalid literal for int() with base
10: '${int(PRINC) + 1}'
15:21 JaMa with added PRINC := 0 to bitbake.conf
15:22 RP__ PRINC := ${int(d.getVar(PRINC)) + 1} ? :/
15:22 JaMa whole log http://paste.pocoo.org/show/514437/
15:22 * RP__ was trying to be too clever I suspect
15:23 JaMa ValueError: invalid literal for int() with base 10:
'${int(d.getVar(PRINC)) + 1}'
15:41 kergoth PRINC is unquoted there, so it tries to get a value for a
key of None
16:24 RP__ kergoth: right, trying to do too many things at once :/
16:24 RP__ kergoth: any thoughts on that knotty change to add the footer?
17:05 JaMa kergoth: something like this? ValueError: invalid literal for
int() with base 10: ${int(d.getVar('PRINC')) + 1}
Maybe someone else has better idea?
Looking at that I was missing something obvious. Try:
PRINC := ${@int(PRINC) + 1}
Cheers,
Richard
As I understand it, the PRINC increases the PR of the appended recipe. Then the
resulting package will have a version that is the same as the next version of
the base recipe. Since many people (me included) hardly remember what they did
a month ago, isn't there a big risk of confusion in your deployed systems if
packages are upgraded there?
I do something like PR .= .local0 where local is the name of the layer
containing the .bbappend.
Of course this will create extensive version strings if multiple .bbappends are
applied but the alternative is that you have no idea what layers that appended
and what the the base version of the recipe really was.
// Mats
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Feedback on building openembedded-core for qemuarm. Excerpts from buildlog
Op 1 dec. 2011, om 17:31 heeft Ulf Samuelsson het volgende geschreven: 2011-12-01 16:37, Koen Kooi skrev: Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: On 11/29/2011 03:06 PM, Koen Kooi wrote: Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: On 2011-11-29 16:03, Richard Purdie wrote: 2.ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz; is no longer available. tzdata , same problem. The recipe is located in two places. meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the problem This is what the build uses. This is something to raise with the meta-oe maintainers. I think there isn't a problem in OECore. Since we now have a large number of layers, maybe it is a good idea to define in each layer, how the git send email should behave in by providing a better .git/config file in the trunk? I.E: [sendemail] to = openembedded-core@lists.openembedded.org or meta-angstrom/.git/config [sendemail] to = angstrom-distro-de...@linuxtogo.org [format] subjectprefix = [meta-angstrom] No need to look in the README file with this. That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers Even if it is not the preferred way, it would direct the discussion to the appropriate list. This would reduce the number of mis-directed emails to this list. You can't fix stupid, sadly. Tend to disagree. The whole purpose of OE is to make it possible for people, stupid or not, to go off and make things which they would not be able to do on their own. As I see it, it is no real drawback of adding this, and at least some benefit. The drawback is that people will postpone reading the README even longer. Why are you so dead against having people read the README? signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] classes/buildhistory: add new output history collection class
Op 2 dec. 2011, om 00:56 heeft Paul Eggleton het volgende geschreven: Create a new build output history reporting class, using testlab.bbclass from meta-oe as a base. This records information from images produced by the build process in text files structured suitably for tracking within a git repository, thus enabling monitoring of changes over time. Build history collection can be enabled simply by adding the following to your local.conf: INHERIT += buildhistory The output after a build can then be found in BUILDHISTORY_DIR (defaults to TMPDIR/buildhistory). If you set up this directory as a git repository and set BUILDHISTORY_COMMIT to 1 in local.conf, the build history data will be committed on every build. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/classes/buildhistory.bbclass | 105 + meta/classes/rootfs_ipk.bbclass | 27 +- meta/classes/rootfs_rpm.bbclass | 41 +-- 3 files changed, 167 insertions(+), 6 deletions(-) create mode 100644 meta/classes/buildhistory.bbclass diff --git a/meta/classes/buildhistory.bbclass b/meta/classes/buildhistory.bbclass new file mode 100644 index 000..79a074c --- /dev/null +++ b/meta/classes/buildhistory.bbclass @@ -0,0 +1,105 @@ +# +# Records history of build output in order to detect regressions +# +# Based in part on testlab.bbclass +# +# Copyright (C) 2011 Intel Corporation +# Copyright (C) 2007, 2008 Koen Kooi k...@openembedded.org I know I forgot to update it, but that should be: 2007 - 2011 regards, Koen signature.asc Description: Message signed with OpenPGP using GPGMail ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Fwd: You have been unsubscribed from the Openembedded-core mailing list
Why have I been unsubscribed from the list?? Are we censoring users that voice opinions that for whatever reason do not meet the list maintainer ?? Or did I say something that violates the list etiquette? If so I would have appreciated a message about that (and perhaps a warning upfront). Not that I can recall having said something wrong Frans. -- Forwarded message -- From: openembedded-core-boun...@lists.openembedded.org Date: 2011/12/2 Subject: You have been unsubscribed from the Openembedded-core mailing list To: fransmeulenbro...@gmail.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: You have been unsubscribed from the Openembedded-core mailing list
On Fri, 2011-12-02 at 12:02 +0100, Frans Meulenbroeks wrote: Why have I been unsubscribed from the list?? That is rather bizarre. Mailman will unsubscribe you if too many mails are returned undeliverable, but you ought to get a warning before that happens. I'll have a look at the logs and see if I can figure out what's going on. Did it allow you to re-subscribe? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: You have been unsubscribed from the Openembedded-core mailing list
2011/12/2 Phil Blundell ph...@gnu.org On Fri, 2011-12-02 at 12:02 +0100, Frans Meulenbroeks wrote: Why have I been unsubscribed from the list?? That is rather bizarre. Mailman will unsubscribe you if too many mails are returned undeliverable, but you ought to get a warning before that happens. I'll have a look at the logs and see if I can figure out what's going on. Did it allow you to re-subscribe? Yes, I could resubscribe (obviously, otherwise i could not post to the list as afaik only subscribers may post) Thanks for looking into this. Frans ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 2/2] classes/buildhistory: merge in package history functionality
On Friday 02 December 2011 11:15:31 Koen Kooi wrote: Does this do a commit per build as well? Yes, since the commit occurs when bitbake completes (in response to the BuildCompleted event). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] classes/buildhistory: add new output history collection class
On Friday 02 December 2011 11:03:34 Koen Kooi wrote: I know I forgot to update it, but that should be: 2007 - 2011 OK, I have updated this in the branch. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
Ideally a specific revision of a layer should specify on which revision it depends on/was tested with, so people can reproduce that same setup. Randomly mixing revisions is a recipe for problems. Expecting that a layer informs its users that something is changing is probably not workable. How would a layer maintainer know what layers are actually depending on it (especially for things like oe-core)? If one is using the head of a layer one is living on the bleeding edge (and hence sometimes one bleeds) (and doing production work based on that seems unwise). Then again, I seem to recall that somewhere in the spring we agreed on a deprecation policy where high impact changes like for toolchain would be done like: - commit new version - wait a while (2 weeks?) - remove old version thus giving people a chance to migrate. Frans. (PS: of course it is also possible to proceed in a perfectly synchronised lockstep, but that probably requires some central coordination and some staging trees or so to test against before the lockstep is performed) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Fri, Dec 2, 2011 at 11:34, Frans Meulenbroeks fransmeulenbro...@gmail.com wrote: Ideally a specific revision of a layer should specify on which revision it depends on/was tested with, so people can reproduce that same setup. I've been using combo-layer to this to work here at O.S. Systems and this has been very easy to handle. I made an internal repository that has oe-core and the layers I need so co-workers can get it and trust it will work; the person doing the update on the layers is expected to do a build before pushing it onto our internal repository and thus this works very well. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Packages Upgrade, Dec2, 2011
On Fri, 2011-12-02 at 15:55 +0800, edwin.z...@intel.com wrote: From: Zhai Edwin edwin.z...@intel.com All, These are upgrade for libfm, pcmanfm and x11vnc. Pls. help review and pull. The following changes since commit 9d6790c4409dee4d08fe6a47450125c406d0ba32: cooker.py: Allow the -e option to work with virtual classes and -b (2011-12-01 23:14:05 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib gzhai/master2 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=gzhai/master2 Zhai Edwin (4): libfm: Upgrade to 0.1.17 pcmanfm: Upgrade to 0.9.10 x11vnc: Upgrade to 0.9.13 distro-tracking: Update info after last upgrade Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] ltp: Add recipe from OE
The pull request is to address [YOCTO #1568] - Add recipe for ltp/posix tests
and automate test.
ltp is ported from OE and updated to latest version(20110915). Testcases are
installed
to ${D}/opt/ltp and POISX test suite is also copied into ${D}/opt/ltp/testcases
folder.
Include ltp to testapps list.
Note that some cases are removed from ltp since they depend on expect. Currently
there is no expect recipe in OE and we will add it for enhancement next.
The following changes since commit e57935dc18d576feb1003b48e7cdc72a444131b8:
Revert classes/buildhistory: add new output history collection class
(2011-12-01 23:00:52 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib jxu49/oe-contrib
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jxu49/oe-contrib
Jiajun Xu (3):
ltp: Add recipe from OE
distro_tracking_fields: add information for ltp
task-core-tools: add ltp to testapps list
.../conf/distro/include/distro_tracking_fields.inc |8 +++
meta/recipes-core/tasks/task-core-tools.bb |3 +-
meta/recipes-extended/ltp/ltp_20110915.bb | 67
3 files changed, 77 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-extended/ltp/ltp_20110915.bb
___
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] bootimage: Use ${S} explicitly for generated config files
On Thu, 2011-12-01 at 19:20 -0800, Darren Hart wrote:
The syslinux and grub-efi classes were generating config files in the current
working directory. This caused a failure due to a race in the creation of the
directories leading to cwd changing and the build failing to find the config
files. While this has been addressed in bitbake, it is better to use an
explicit path.
While ${WORKDIR} may seem a more appropriate place, the recipe
already uses ${S} for the hdd and cd construction, so we use ${S}
here to keep things consolidated and consistent and address the issue
with minimal change.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/classes/grub-efi.bbclass |8 +++-
meta/classes/syslinux.bbclass |4 ++--
2 files changed, 5 insertions(+), 7 deletions(-)
Merged to master, thanks.
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] task-core-tools: add ltp to testapps list
Signed-off-by: Jiajun Xu jiajun...@intel.com
---
meta/recipes-core/tasks/task-core-tools.bb |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/tasks/task-core-tools.bb
b/meta/recipes-core/tasks/task-core-tools.bb
index 12d4ff9..6632b4f 100644
--- a/meta/recipes-core/tasks/task-core-tools.bb
+++ b/meta/recipes-core/tasks/task-core-tools.bb
@@ -6,7 +6,7 @@ DESCRIPTION = Tools tasks for OE-Core
LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
-PR = r13
+PR = r14
PACKAGES = \
task-core-tools-debug \
@@ -98,4 +98,5 @@ RDEPENDS_task-core-tools-testapps = \
xprop \
xvideo-tests \
clutter-box2d \
+ltp \
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] distro_tracking_fields: add information for ltp
Add information for recipe ltp, which is ported from OE. Signed-off-by: Jiajun Xu jiajun...@intel.com --- .../conf/distro/include/distro_tracking_fields.inc |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index 073521f..fa15f24 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -6092,6 +6092,14 @@ RECIPE_MANUAL_CHECK_DATE_pn-libiconv = Nov 22, 2011 DISTRO_PN_ALIAS_pn-libiconv = Fedora=mingw-libiconv Opensuse=cross-mingw-libiconv RECIPE_MAINTAINER_pn-libiconv = Saul Wold s...@linux.intel.com +RECIPE_STATUS_pn-ltp = green +RECIPE_LATEST_VERSION_pn-ltp = 20110915 +RECIPE_LATEST_RELEASE_DATE_pn-ltp = Sep 15, 2011 +RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-ltp = 3 months +RECIPE_NO_OF_PATCHES_pn-ltp = 0 +RECIPE_LAST_UPDATE_pn-ltp = Dec 2, 2011 +RECIPE_MAINTAINER_pn-ltp = Jiajun Xu jiajun...@intel.com + DISTRO_PN_ALIAS_pn-qt4-native = Fedora=qt4 Debian=qt4-dev-tools DISTRO_PN_ALIAS_pn-update-alternatives-dpkg = Opensuse=update-alternatives Mandriva=update-alternatives RECIPE_MAINTAINER_pn-update-alternatives-dpkg = Dongxiao Xu dongxiao...@intel.com -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] ltp: Add recipe from OE
Port ltp recipe from OE and upgraged to latest version(20110915).
Install ltp into ${D}/opt/ltp and POSIX test suite is also copied
into ${D}/opt/ltp/testcases.
TODO: Some cases are removed since they depend on command 'expect'.
It is not in Poky or OE and we will add it for enhancement next.
Signed-off-by: Jiajun Xu jiajun...@intel.com
---
meta/recipes-extended/ltp/ltp_20110915.bb | 67 +
1 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-extended/ltp/ltp_20110915.bb
diff --git a/meta/recipes-extended/ltp/ltp_20110915.bb
b/meta/recipes-extended/ltp/ltp_20110915.bb
new file mode 100644
index 000..ff5ea47
--- /dev/null
+++ b/meta/recipes-extended/ltp/ltp_20110915.bb
@@ -0,0 +1,67 @@
+SUMMARY = Linux Test Project
+DESCRIPTION = The Linux Test Project is a joint project with SGI, IBM, OSDL,
and Bull with a goal to deliver test suites to the open source community that
validate the reliability, robustness, and stability of Linux. The Linux Test
Project is a collection of tools for testing the Linux kernel and related
features.
+HOMEPAGE = http://ltp.sourceforge.net;
+SECTION = console/utils
+
+PR = r0
+
+LICENSE = GPLv2 GPLv2+ LGPLv2+ LGPLv2.1+ BSD-2-Clause
+SRC_URI = ${SOURCEFORGE_MIRROR}/ltp/ltp-full-${PV}.bz2
+
+LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
+
file://testcases/kernel/mce-test/COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
+
file://testcases/kernel/controllers/freezer/COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3
\
+
file://testcases/kernel/controllers/freezer/run_freezer.sh;startline=5;endline=17;md5=aeac3f7691caa2e76fd5a732fbd6510d
\
+
file://testcases/kernel/fs/ext4-new-features/ffsb-6.0-rc2/COPYING;md5=c46082167a314d785d012a244748d803
\
+
file://testcases/kernel/hotplug/memory_hotplug/COPYING;md5=e04a2e542b2b8629bf9cd2ba29b0fe41
\
+
file://testcases/kernel/hotplug/cpu_hotplug/COPYING;md5=e04a2e542b2b8629bf9cd2ba29b0fe41
\
+
file://testcases/open_posix_testsuite/COPYING;md5=216e43b72efbe4ed9017cc19c4c68b01
\
+
file://tools/netpipe-2.4/COPYING;md5=18810669f13b87348459e611d31ab760 \
+
file://tools/netpipe-2.4-ipv6/COPYING;md5=18810669f13b87348459e611d31ab760 \
+
file://tools/top-LTP/proc/COPYING;md5=6e29c688d912da12b66b73e32b03d812 \
+
file://tools/pounder21/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
+
file://utils/benchmark/kernbench-0.42/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
\
+
+
+SRC_URI[md5sum] = 582fb78d7bf78a624a4387f29327d166
+SRC_URI[sha256sum] =
013f7f2f6fdf46b7d73216533c3d4c2d91f0a2cec522bf026f7c8920ede83d2c
+
+export prefix = /opt/ltp
+export exec_prefix = /opt/ltp
+
+inherit autotools
+
+FILES_${PN}-dbg += /opt/ltp/runtest/.debug
+FILES_${PN}-dbg += /opt/ltp/testcases/bin/.debug
+FILES_${PN}-dbg += /opt/ltp/testcases/bin/*/bin/.debug
+FILES_${PN}-dbg += /opt/ltp/testcases/bin/*/test/.debug
+FILES_${PN}-dbg += /opt/ltp/scenario_groups/.debug
+FILES_${PN}-dbg += /opt/ltp/testscripts/.debug
+FILES_${PN}-dbg += /opt/ltp/testscripts/open_posix_testsuite/.debug
+
+FILES_${PN} += /opt/ltp/* /opt/ltp/runtest/* /opt/ltp/scenario_groups/*
/opt/ltp/testcases/bin/* /opt/ltp/testcases/bin/*/bin/* /opt/ltp/testscripts/*
/opt/ltp/testcases/open_posix_testsuite/*
/opt/ltp/testcases/open_posix_testsuite/conformance/*
/opt/ltp/testcases/open_posix_testsuite/Documentation/*
/opt/ltp/testcases/open_posix_testsuite/functional/*
/opt/ltp/testcases/open_posix_testsuite/include/*
/opt/ltp/testcases/open_posix_testsuite/scripts/*
/opt/ltp/testcases/open_posix_testsuite/stress/*
/opt/ltp/testcases/open_posix_testsuite/tools/*
+
+TARGET_CC_ARCH += ${LDFLAGS}
+
+do_unpack_append() {
+bb.build.exec_func('do_extract_tarball', d)
+}
+
+do_extract_tarball() {
+ if test -f ${WORKDIR}/ltp-full-${PV} ; then
+ tar x --no-same-owner -f ${WORKDIR}/ltp-full-${PV}
+ mv ${WORKDIR}/ltp-full-${PV} ${WORKDIR}/ltp-${PV}
+ fi
+}
+
+do_install(){
+ install -d ${D}/opt/ltp/
+ oe_runmake DESTDIR=${D} SKIP_IDCHECK=1 install
+
+ # Copy POSIX test suite into ${D}/opt/ltp/testcases by manual
+ cp -r testcases/open_posix_testsuite ${D}/opt/ltp/testcases
+
+ # We need to remove all scripts which depend on /usr/bin/expect, since
expect is not supported in poky
+ # We will add expect for enhancement in future
+ find ${D} -type f -print | xargs grep \!.*\/usr\/bin\/expect | awk
-F: '{print $1}' | xargs rm -f
+}
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Fri, Dec 02, 2011 at 08:46:43AM +, Mats Kärrman wrote:
From: openembedded-core-boun...@lists.openembedded.org
[openembedded-core-boun...@lists.openembedded.org] on behalf of Richard
Purdie [richard.pur...@linuxfoundation.org]
Sent: Thursday, December 01, 2011 9:33 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] Coordinating inter-layer dependencies
On Thu, 2011-12-01 at 14:07 +0100, Martin Jansa wrote:
On Thu, Dec 01, 2011 at 10:59:03AM -0200, Otavio Salvador wrote:
On Thu, Dec 1, 2011 at 10:37, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2011-12-01 at 13:24 +0100, Martin Jansa wrote:
A while back I've proposed to make .bbappend without corresponding
.bb
only big fat warning, but not fatal to parse. Now you cannot even
build
eglibc if there is libdrm bbappend you don't care at all about..
You can do this by setting:
BB_DANGLINGAPPENDS_WARNONLY
This is even worse; you end up with a package without the changes done
on
the bbappend and as most bbappend files do not change PR, adding it
later
won't force a package update.
If we find a way to allow PRINC in multiple bbappends for same .bb then
we can say that every .bbappend should use PRINC.
For record I'll include my discussion about PRINC with RP and kergoth:
10:47 JaMa RP__: is there any way to improve PRINC concept to allow
multiple increments for same recipe while parsing multiple layers?
10:48 RP__ JaMa: PRINC_append = .1 ?
10:49 JaMa RP__: ie when meta-openmoko sets PRINC = 1 and meta-shr
sets PRINC = 2 then if you're unlucky meta-openmoko is parsed later and
bumping PRINC in meta-shr won't help
10:49 RP__ JaMa: I wonder if you could do PRINC := ${PRINC + 1}
10:50 JaMa and do we have default PRINC = 0 somewhere?
10:50 RP__ JaMa: you might need to add that
10:50 JaMa ok, I'll try this, thanks
10:51 JaMa currently I'm moving PRINC only to meta-shr layer.. but
that breaks stuff if someone is using any BSP layer from meta-smartphone..
14:53 JaMa RP__: btw that PRINC trick didn't work (int type didn't
like expresion :/)
15:13 RP__ JaMa: ah, try PRINC := ${int(PRINC) + 1}
15:21 JaMa RP__: still ValueError: invalid literal for int() with base
10: '${int(PRINC) + 1}'
15:21 JaMa with added PRINC := 0 to bitbake.conf
15:22 RP__ PRINC := ${int(d.getVar(PRINC)) + 1} ? :/
15:22 JaMa whole log http://paste.pocoo.org/show/514437/
15:22 * RP__ was trying to be too clever I suspect
15:23 JaMa ValueError: invalid literal for int() with base 10:
'${int(d.getVar(PRINC)) + 1}'
15:41 kergoth PRINC is unquoted there, so it tries to get a value for
a key of None
16:24 RP__ kergoth: right, trying to do too many things at once :/
16:24 RP__ kergoth: any thoughts on that knotty change to add the
footer?
17:05 JaMa kergoth: something like this? ValueError: invalid literal
for int() with base 10: ${int(d.getVar('PRINC')) + 1}
Maybe someone else has better idea?
Looking at that I was missing something obvious. Try:
PRINC := ${@int(PRINC) + 1}
Cheers,
Richard
As I understand it, the PRINC increases the PR of the appended recipe. Then
the resulting package will have a version that is the same as the next
version of the base recipe. Since many people (me included) hardly remember
what they did a month ago, isn't there a big risk of confusion in your
deployed systems if packages are upgraded there?
I do something like PR .= .local0 where local is the name of the layer
containing the .bbappend.
Of course this will create extensive version strings if multiple .bbappends
are applied but the alternative is that you have no idea what layers that
appended and what the the base version of the recipe really was.
So if you have some layer adding
layerB: PR .= .b0
and other
layerA: PR .= .a0
and PR appends are evaluated in this order, then you will break upgrade
patch forever if you have to remove layerB for some reason and you
cannot even fix it by bumping numbers in your layerA unless you rename
all PR appends as .c0 right? That's why I prefer to use PRINC.
Yes it increases PR of desired number, but every time.. so if upper
layer increments PR your .bbappend will again increment it so you still
get always increasing sequence.
Only problem was multiple .bbappends overwritting PRINC value in each
other, but RP's latest proposal:
PRINC := ${@int(PRINC) + 1}
works and I'm going to push meta-smartphone migration to this PRINC
usage instead of more common 'PRINC = 1'
for bb in `git grep ^PRINC . | sed 's/:.*//g'`; do sed -i 's/PRINC *=
*\(.*\)/PRINC := ${@int(PRINC) + \1}/g' $bb; done
And I'll send patch here to add default PRINC = 0 to bitbake.conf,
because otherwise it fails with:
ERROR: Failure expanding variable PRINC[:=],
[OE-core] [PATCH] bitbake.conf: add default PRINC 0 to be able to increment it
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/bitbake.conf |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 87efd8e..552942b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -166,6 +166,7 @@ ASSUME_PROVIDED = \
PN = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[0] or
'defaultpkgname'}
PV = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[1] or '1.0'}
PR = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[2] or 'r0'}
+PRINC := 0
PF = ${PN}-${EXTENDPE}${PV}-${PR}
EXTENDPE = ${@['','${PE\x7d_'][d.getVar('PE',1) 0]}
P = ${PN}-${PV}
--
1.7.8.rc4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bitbake.conf: add default PRINC 0 to be able to increment it
On Fri, 2011-12-02 at 17:22 +0100, Martin Jansa wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/bitbake.conf |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 87efd8e..552942b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -166,6 +166,7 @@ ASSUME_PROVIDED = \
PN = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[0] or
'defaultpkgname'}
PV = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[1] or '1.0'}
PR = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[2] or 'r0'}
+PRINC := 0
PF = ${PN}-${EXTENDPE}${PV}-${PR}
EXTENDPE = ${@['','${PE\x7d_'][d.getVar('PE',1) 0]}
P = ${PN}-${PV}
Why does this need := ? (it doesn't)
Also, can you change the expression in base.bbclass from:
princ = d.getVar('PRINC', True)
if princ:
to:
if princ and princ != 0:
since otherwise I think this will have rather a negative effect on
parsing speed.
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] logrotate: Add dependency on popt lib.
On 11/29/2011 07:00 AM, Stefan Schmidt wrote: Without this logrotate may fail like this: compilation terminated. | config.c:9:18: fatal error: popt.h: No such file or directory Signed-off-by: Stefan Schmidtste...@datenfreihafen.org --- meta/recipes-extended/logrotate/logrotate_3.7.9.bb |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-extended/logrotate/logrotate_3.7.9.bb b/meta/recipes-extended/logrotate/logrotate_3.7.9.bb index b736593..8dc0504 100644 --- a/meta/recipes-extended/logrotate/logrotate_3.7.9.bb +++ b/meta/recipes-extended/logrotate/logrotate_3.7.9.bb @@ -2,9 +2,9 @@ DESCRIPTION = Rotates, compresses, removes and mails system log files SECTION = console/utils HOMEPAGE = https://fedorahosted.org/releases/l/o/logrotate; LICENSE = GPLv2 -PR = r0 +PR = r1 -DEPENDS=coreutils +DEPENDS=coreutils popt LIC_FILES_CHKSUM = file://COPYING;md5=18810669f13b87348459e611d31ab760 Merged into OE-Core Thanks Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] x11vnc: Upgrade to 0.9.13
On Fri, Dec 2, 2011 at 1:55 AM, edwin.z...@intel.com wrote: -PR = r2 +PR = r0 Isn't this wrong? -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] sstate.bbclass: add option to use alternate compression in lieu of gzip
The savings can be substantial. The resutls below are for a
core-image-minimal type image:
gzip:1.1G sstate-cache
xz 714M sstate-cache
Signed-off-by: Matthew McClintock m...@freescale.com
---
v2: This one actually works!
meta/classes/sstate.bbclass | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 3d259f0..e3a2a83 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -18,6 +18,9 @@ SSTATE_MANMACH ?= ${SSTATE_PKGARCH}
SSTATEPOSTINSTFUNCS ?=
+SSTATE_PKG_SUFFIX ?= tgz
+SSTATE_PKG_TAROPT ?= z
+
python () {
if bb.data.inherits_class('native', d):
bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d)
@@ -155,7 +158,7 @@ def sstate_installpkg(ss, d):
oe.path.remove(dir)
sstateinst = bb.data.expand(${WORKDIR}/sstate-install-%s/ % ss['name'],
d)
-sstatepkg = bb.data.getVar('SSTATE_PKG', d, True) + '_' + ss['name'] +
.tgz
+sstatepkg = bb.data.expand(${SSTATE_PKG} + '_' + ss['name'] +
.${SSTATE_PKG_SUFFIX}, d)
if not os.path.exists(sstatepkg):
pstaging_fetch(sstatepkg, d)
@@ -206,7 +209,7 @@ def sstate_clean_cachefile(ss, d):
import oe.path
sstatepkgdir = bb.data.getVar('SSTATE_DIR', d, True)
-sstatepkgfile = sstatepkgdir + '/' + bb.data.getVar('SSTATE_PKGSPEC', d,
True) + *_ + ss['name'] + .tgz*
+sstatepkgfile = bb.data.expand(sstatepkgdir + '/' + ${SSTATE_PKGSPEC} +
*_ + ss['name'] + .${SSTATE_PKG_SUFFIX}*, d)
bb.note(Removing %s % sstatepkgfile)
oe.path.remove(sstatepkgfile)
@@ -351,7 +354,7 @@ def sstate_package(ss, d):
tmpdir = bb.data.getVar('TMPDIR', d, True)
sstatebuild = bb.data.expand(${WORKDIR}/sstate-build-%s/ % ss['name'], d)
-sstatepkg = bb.data.getVar('SSTATE_PKG', d, True) + '_'+ ss['name'] +
.tgz
+sstatepkg = bb.data.expand(${SSTATE_PKG} + '_' + ss['name'] +
.${SSTATE_PKG_SUFFIX}, d)
bb.mkdirhier(sstatebuild)
bb.mkdirhier(os.path.dirname(sstatepkg))
for state in ss['dirs']:
@@ -448,9 +451,9 @@ sstate_create_package () {
cd ${SSTATE_BUILDDIR}
# Need to handle empty directories
if [ $(ls -A) ]; then
- tar -czf ${SSTATE_PKG} *
+ tar -${SSTATE_PKG_TAROPT}cf ${SSTATE_PKG} *
else
- tar -cz --file=${SSTATE_PKG} --files-from=/dev/null
+ tar -${SSTATE_PKG_TAROPT}c --file=${SSTATE_PKG}
--files-from=/dev/null
fi
cd ${WORKDIR}
@@ -463,7 +466,7 @@ sstate_create_package () {
sstate_unpack_package () {
mkdir -p ${SSTATE_INSTDIR}
cd ${SSTATE_INSTDIR}
- tar -xvzf ${SSTATE_PKG}
+ tar -${SSTATE_PKG_TAROPT}xvf ${SSTATE_PKG}
}
BB_HASHCHECK_FUNCTION = sstate_checkhashes
@@ -483,7 +486,7 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn,
d):
}
for task in range(len(sq_fn)):
-sstatefile = bb.data.expand(${SSTATE_DIR}/ + sq_hashfn[task] + _ +
mapping[sq_task[task]] + .tgz, d)
+sstatefile = bb.data.expand(${SSTATE_DIR}/ + sq_hashfn[task] + _ +
mapping[sq_task[task]] + .${SSTATE_PKG_SUFFIX}, d)
sstatefile = sstatefile.replace(${BB_TASKHASH}, sq_hash[task])
if os.path.exists(sstatefile):
bb.debug(2, SState: Found valid sstate file %s % sstatefile)
@@ -508,7 +511,7 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn,
d):
if task in ret:
continue
-sstatefile = bb.data.expand(${SSTATE_DIR}/ + sq_hashfn[task] +
_ + mapping[sq_task[task]] + .tgz, d)
+sstatefile = bb.data.expand(${SSTATE_DIR}/ + sq_hashfn[task] +
_ + mapping[sq_task[task]] + .${SSTATE_PKG_SUFFIX}, d)
sstatefile = sstatefile.replace(${BB_TASKHASH}, sq_hash[task])
srcuri = file:// + os.path.basename(sstatefile)
--
1.7.6.1
___
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] x11vnc: Upgrade to 0.9.13
On Friday 02 December 2011 17:21:57 McClintock Matthew-B29882 wrote: On Fri, Dec 2, 2011 at 1:55 AM, edwin.z...@intel.com wrote: -PR = r2 +PR = r0 Isn't this wrong? In this case since PV has been increased at the same time (by renaming the recipe) it's not only OK, it's recommended practice. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] x11vnc: Upgrade to 0.9.13
On Fri, Dec 2, 2011 at 11:27 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: In this case since PV has been increased at the same time (by renaming the recipe) it's not only OK, it's recommended practice. Ahh Ok. New recipe = reset PR. Thanks, Matthew ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2] bitbake.conf: add default PRINC 0 to be able to increment it
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/classes/base.bbclass |2 +-
meta/conf/bitbake.conf|1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index ea53498..fbcaefb 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -335,7 +335,7 @@ python () {
# If PRINC is set, try and increase the PR value by the amount specified
princ = d.getVar('PRINC', True)
-if princ:
+if princ and princ != 0:
pr = d.getVar('PR', True)
pr_prefix = re.search(\D+,pr)
prval = re.search(\d+,pr)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index acba388..e80cc32 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -167,6 +167,7 @@ ASSUME_PROVIDED = \
PN = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[0] or
'defaultpkgname'}
PV = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[1] or '1.0'}
PR = ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[2] or 'r0'}
+PRINC ?= 0
PF = ${PN}-${EXTENDPE}${PV}-${PR}
EXTENDPE = ${@['','${PE\x7d_'][d.getVar('PE',1) 0]}
P = ${PN}-${PV}
--
1.7.8.rc4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Make missing checksums an error
NOTE: this requires a patch I sent to the BitBake list[1] to error cleanly, otherwise you'll see a Python backtrace and the build fail... Per some discussion on the list recently this patch sets BB_STRICT_CHECKSUM in the default-distrovars.inc so that missing checksums in recipes raises an error. Cheers, Joshua 1. lists.linuxtogo.org/pipermail/bitbake-devel/2011-December/thread.html The following changes since commit 044324465bd54d53ae768f3c1e7468ae0e0c6200: dpkg-native: Fix perl path (2011-12-02 15:31:03 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib josh/checksums http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/checksums Joshua Lock (1): default-distrovars: missing checksums should raise an error meta/conf/distro/include/default-distrovars.inc |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) -- 1.7.7.3 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] default-distrovars: missing checksums should raise an error
Set BB_STRICT_CHECKSUM in default-distrovars so that an error is raised if no checksum is set. Signed-off-by: Joshua Lock j...@linux.intel.com --- meta/conf/distro/include/default-distrovars.inc |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc index 6f5f1c0..e1594f3 100644 --- a/meta/conf/distro/include/default-distrovars.inc +++ b/meta/conf/distro/include/default-distrovars.inc @@ -48,3 +48,6 @@ NO32LIBS ??= 1 BBINCLUDELOGS ??= yes SDK_VERSION ??= oe-core.0 DISTRO_VERSION ??= oe-core.0 + +# Missing checksums should raise an error +BB_STRICT_CHECKSUM = 1 -- 1.7.7.3 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] bitbake.conf: add default PRINC 0 to be able to increment it
On Fri, Dec 2, 2011 at 11:39 AM, Martin Jansa martin.ja...@gmail.com wrote:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/classes/base.bbclass | 2 +-
meta/conf/bitbake.conf | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index ea53498..fbcaefb 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -335,7 +335,7 @@ python () {
# If PRINC is set, try and increase the PR value by the amount specified
princ = d.getVar('PRINC', True)
- if princ:
+ if princ and princ != 0:
Could also do:
if int(princ):
Or:
PRINC[type] = integer # and:
if oe.data.typed_value('PRINC', d):
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
On Fri, Dec 2, 2011 at 9:18 AM, Martin Jansa martin.ja...@gmail.com wrote: So if you have some layer adding layerB: PR .= .b0 and other layerA: PR .= .a0 and PR appends are evaluated in this order, then you will break upgrade patch forever if you have to remove layerB for some reason and you cannot even fix it by bumping numbers in your layerA unless you rename all PR appends as .c0 right? That's why I prefer to use PRINC. And if you *remove* a layer you used to use? Will this not result in it decrementing and breaking the upgrade path in that way? Or does this persist the way localcount does? -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 05/11] mesa-dri, mesa-xlib: fix compilation with x32 toolchain
From: Nitin A Kamble nitin.a.kam...@intel.com
Add support for building with x32 toolchain.
Simplified the use of SRC_URI S vars across multiple files.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: H.J. Lu hjl.to...@gmail.com
---
meta/recipes-graphics/mesa/mesa-7.11.inc | 11 ++--
meta/recipes-graphics/mesa/mesa-common.inc |2 -
meta/recipes-graphics/mesa/mesa-dri_7.11.bb|2 +-
meta/recipes-graphics/mesa/mesa-git.inc|6 ++--
meta/recipes-graphics/mesa/mesa-xlib_7.11.bb |2 +-
.../mesa/mesa/mesa_fix_for_x32.patch | 24
6 files changed, 37 insertions(+), 10 deletions(-)
create mode 100644 meta/recipes-graphics/mesa/mesa/mesa_fix_for_x32.patch
diff --git a/meta/recipes-graphics/mesa/mesa-7.11.inc
b/meta/recipes-graphics/mesa/mesa-7.11.inc
index 2f14ed4..7c4a690 100644
--- a/meta/recipes-graphics/mesa/mesa-7.11.inc
+++ b/meta/recipes-graphics/mesa/mesa-7.11.inc
@@ -1,9 +1,14 @@
DEPENDS += mesa-dri-glsl-native
-SRC_URI += file://uclibc.patch \
-file://crossfix.patch \
-file://crossfix-mklib.patch \
+
+SRC_URI = ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2 \
+ file://uclibc.patch \
+ file://crossfix.patch \
+ file://crossfix-mklib.patch \
+ file://mesa_fix_for_x32.patch \
+S = ${WORKDIR}/Mesa-${PV}
+
SRC_URI[md5sum] = ff03aca82d0560009a076a87c888cf13
SRC_URI[sha256sum] =
f8bf37a00882840a3e3d327576bc26a79ae7f4e18fe1f7d5f17a5b1c80dd7acf
diff --git a/meta/recipes-graphics/mesa/mesa-common.inc
b/meta/recipes-graphics/mesa/mesa-common.inc
index df035e6..59e8e64 100644
--- a/meta/recipes-graphics/mesa/mesa-common.inc
+++ b/meta/recipes-graphics/mesa/mesa-common.inc
@@ -15,8 +15,6 @@ LIC_FILES_CHKSUM =
file://docs/license.html;md5=7a3373c039b6b925c427755a4f779c1
INC_PR = r13
PE = 2
-SRC_URI = ftp://ftp.freedesktop.org/pub/mesa/${PV}/MesaLib-${PV}.tar.bz2;
-S = ${WORKDIR}/Mesa-${PV}
PROTO_DEPS = xf86driproto glproto
LIB_DEPS = virtual/libx11 libxext libxxf86vm libxdamage libxfixes
libxml2-native
diff --git a/meta/recipes-graphics/mesa/mesa-dri_7.11.bb
b/meta/recipes-graphics/mesa/mesa-dri_7.11.bb
index 5d25127..219e555 100644
--- a/meta/recipes-graphics/mesa/mesa-dri_7.11.bb
+++ b/meta/recipes-graphics/mesa/mesa-dri_7.11.bb
@@ -1,4 +1,4 @@
include mesa-common.inc
include mesa-${PV}.inc
include mesa-dri.inc
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
diff --git a/meta/recipes-graphics/mesa/mesa-git.inc
b/meta/recipes-graphics/mesa/mesa-git.inc
index 594d9b8..1b4c0a6 100644
--- a/meta/recipes-graphics/mesa/mesa-git.inc
+++ b/meta/recipes-graphics/mesa/mesa-git.inc
@@ -6,9 +6,9 @@ PV = 7.11+gitr${SRCPV}
LIC_FILES_CHKSUM =
file://docs/license.html;md5=03ccdc4c379c4289aecfb8892c546f67
FILESEXTRAPATHS_prepend := ${THISDIR}/mesa-git:
-SRC_URI = git://anongit.freedesktop.org/git/mesa/mesa;protocol=git
-SRC_URI += file://uclibc.patch \
-file://crossfix.patch \
+SRC_URI = git://anongit.freedesktop.org/git/mesa/mesa;protocol=git \
+ file://uclibc.patch \
+ file://crossfix.patch \
S = ${WORKDIR}/git
diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.11.bb
b/meta/recipes-graphics/mesa/mesa-xlib_7.11.bb
index 95ff5e8..7912287 100644
--- a/meta/recipes-graphics/mesa/mesa-xlib_7.11.bb
+++ b/meta/recipes-graphics/mesa/mesa-xlib_7.11.bb
@@ -1,5 +1,5 @@
include mesa-common.inc
include mesa-${PV}.inc
include mesa-xlib.inc
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
diff --git a/meta/recipes-graphics/mesa/mesa/mesa_fix_for_x32.patch
b/meta/recipes-graphics/mesa/mesa/mesa_fix_for_x32.patch
new file mode 100644
index 000..22a2339
--- /dev/null
+++ b/meta/recipes-graphics/mesa/mesa/mesa_fix_for_x32.patch
@@ -0,0 +1,24 @@
+UpstreamStatus: Pending
+
+get correct compiler options for x32 gcc.
+
+Received this patch from H.J. Lu hjl.to...@gmail.com
+
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com 2011/12/01
+
+--- Mesa-7.11/bin/mklib.x322011-11-30 14:29:14.976465283 -0800
Mesa-7.11/bin/mklib2011-11-30 14:32:48.591525193 -0800
+@@ -335,7 +335,12 @@ case $ARCH in
+ set ${OBJECTS}
+ ABI32=`file $1 | grep 32-bit`
+ if [ ${ABI32} -a `uname -m` = x86_64 ] ; then
+- OPTS=-m32 ${OPTS}
++ ABIX32=`file $1 | grep x86-64`
++ if [ ${ABI32} ]; then
++ OPTS=-mx32 ${OPTS}
++ else
++ OPTS=-m32 ${OPTS}
++ fi
+ fi
+
+ if [ ${ALTOPTS} ] ; then
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/11] recipe fixes for x32 toolchain
From: Nitin A Kamble nitin.a.kam...@intel.com These commits fixes building of various recipes with x32 toolchain for x32 target/machines. And these do not affect these recipes for other non-x32 targets. X32 is new ABI for x86-64 architecture. For more information refer: https://sites.google.com/site/x32abi/ Thanks, Nitin The following changes since commit 9be6d59b78510443d0944513503d515df13caa45: dpkg-native: Fix perl path (2011-12-02 15:31:08 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib nitin/x32 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin.x32 Nitin A Kamble (11): gst-fluendo-mpegdemux: rework the CC hack mdadm: fix CC definition in the Makefile openssl-1.0.0e: fix to wotk with x32 toolchain gmp: fix the recipe for x32 target mesa-dri, mesa-xlib: fix compilation with x32 toolchain glib-2.0: fix compilatoin with x32 toolchain libxt: fix compilatoin with x32 toolchain liboil: patch source code for x32 xproto: fix compilation with x32 toolchain libaio: patch source code for x32 libatomics-ops: patch source code for x32 .../openssl-1.0.0e/openssl_fix_for_x32.patch | 90 meta/recipes-connectivity/openssl/openssl.inc | 15 +- .../recipes-connectivity/openssl/openssl_1.0.0e.bb |3 +- .../glib-2.0/glib-2.0/glib-2.0_fix_for_x32.patch | 76 +++ meta/recipes-core/glib-2.0/glib-2.0_2.30.1.bb |3 +- .../libaio/libaio/libaio_fix_for_x32.patch | 61 ++ meta/recipes-extended/libaio/libaio_0.3.109.bb |5 +- .../mdadm/files/mdadm_fix_for_x32.patch| 24 ++ meta/recipes-extended/mdadm/mdadm_3.2.2.bb |3 +- meta/recipes-graphics/mesa/mesa-7.11.inc | 11 +- meta/recipes-graphics/mesa/mesa-common.inc |2 - meta/recipes-graphics/mesa/mesa-dri_7.11.bb|2 +- meta/recipes-graphics/mesa/mesa-git.inc|6 +- meta/recipes-graphics/mesa/mesa-xlib_7.11.bb |2 +- .../mesa/mesa/mesa_fix_for_x32.patch | 24 ++ .../xorg-lib/libxt/libxt_fix_for_x32.patch | 19 ++ meta/recipes-graphics/xorg-lib/libxt_1.1.1.bb |4 +- .../xorg-proto/xproto/xproto_fix_for_x32.patch | 22 ++ meta/recipes-graphics/xorg-proto/xproto_7.0.22.bb |4 +- meta/recipes-multimedia/gstreamer/gst-fluendo.inc |2 +- .../libatomics-ops_fix_for_x32.patch | 41 .../pulseaudio/libatomics-ops_1.2.bb |5 +- meta/recipes-support/gmp/gmp/gmp_bugfix.patch | 94 meta/recipes-support/gmp/gmp/gmp_fix_for_x32.patch | 45 meta/recipes-support/gmp/gmp_5.0.2.bb |6 +- .../liboil/liboil-0.3.17/liboil_fix_for_x32.patch | 222 meta/recipes-support/liboil/liboil_0.3.17.bb |3 +- 27 files changed, 762 insertions(+), 32 deletions(-) create mode 100644 meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl_fix_for_x32.patch create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/glib-2.0_fix_for_x32.patch create mode 100644 meta/recipes-extended/libaio/libaio/libaio_fix_for_x32.patch create mode 100644 meta/recipes-extended/mdadm/files/mdadm_fix_for_x32.patch create mode 100644 meta/recipes-graphics/mesa/mesa/mesa_fix_for_x32.patch create mode 100644 meta/recipes-graphics/xorg-lib/libxt/libxt_fix_for_x32.patch create mode 100644 meta/recipes-graphics/xorg-proto/xproto/xproto_fix_for_x32.patch create mode 100644 meta/recipes-multimedia/pulseaudio/libatomics-ops/libatomics-ops_fix_for_x32.patch create mode 100644 meta/recipes-support/gmp/gmp/gmp_bugfix.patch create mode 100644 meta/recipes-support/gmp/gmp/gmp_fix_for_x32.patch create mode 100644 meta/recipes-support/liboil/liboil-0.3.17/liboil_fix_for_x32.patch -- 1.7.6.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 01/11] gst-fluendo-mpegdemux: rework the CC hack
From: Nitin A Kamble nitin.a.kam...@intel.com
This fixes bug: [YOCTO #1403]
Earlier hack was breaking compiler parameters set by tune settings. And that
caused x32
build failure. Now previous CC parameters are kept intact while adding new -L
parameter.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta/recipes-multimedia/gstreamer/gst-fluendo.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
index 203bdba..9615454 100644
--- a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
@@ -14,5 +14,5 @@ FILES_${PN}-dev += ${libdir}/gstreamer-0.10/*.la
${libdir}/gstreamer-0.10/*.a
EXTRA_OECONF = --disable-debug --disable-valgrind
# Hack to get STAGING_LIBDIR into the linker path when building
-CC = ${CCACHE} ${HOST_PREFIX}gcc -L${STAGING_LIBDIR}
+CC += -L${STAGING_LIBDIR}
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 08/11] liboil: patch source code for x32
From: Nitin A Kamble nitin.a.kam...@intel.com Make the assembly syntax compatible with x32 gcc. Othewise x32 gcc throws errors. This Fixes bug: [YOCTO #1412] Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- .../liboil/liboil-0.3.17/liboil_fix_for_x32.patch | 222 meta/recipes-support/liboil/liboil_0.3.17.bb |3 +- 2 files changed, 224 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-support/liboil/liboil-0.3.17/liboil_fix_for_x32.patch diff --git a/meta/recipes-support/liboil/liboil-0.3.17/liboil_fix_for_x32.patch b/meta/recipes-support/liboil/liboil-0.3.17/liboil_fix_for_x32.patch new file mode 100644 index 000..473380e --- /dev/null +++ b/meta/recipes-support/liboil/liboil-0.3.17/liboil_fix_for_x32.patch @@ -0,0 +1,222 @@ +Upstream-Status: Pending + +Make the assembly syntax compatible with x32 gcc. Othewise x32 gcc throws errors. + +Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com +2011/12/01 + + +Index: liboil-0.3.17/liboil/amd64/wavelet.c +=== +--- liboil-0.3.17.orig/liboil/amd64/wavelet.c liboil-0.3.17/liboil/amd64/wavelet.c +@@ -21,14 +21,14 @@ deinterleave2_asm (int16_t *d1, int16_t + asm volatile (\n + sub $2, %%rcx\n + 1:\n +-movw (%1,%%rcx,4), %%ax\n +-movw %%ax, (%0,%%rcx,2)\n +-movw 2(%1,%%rcx,4), %%ax\n +-movw %%ax, (%2,%%rcx,2)\n +-movw 4(%1,%%rcx,4), %%ax\n +-movw %%ax, 2(%0,%%rcx,2)\n +-movw 6(%1,%%rcx,4), %%ax\n +-movw %%ax, 2(%2,%%rcx,2)\n ++movw (%q1,%%rcx,4), %%ax\n ++movw %%ax, (%q0,%%rcx,2)\n ++movw 2(%q1,%%rcx,4), %%ax\n ++movw %%ax, (%q2,%%rcx,2)\n ++movw 4(%q1,%%rcx,4), %%ax\n ++movw %%ax, 2(%q0,%%rcx,2)\n ++movw 6(%q1,%%rcx,4), %%ax\n ++movw %%ax, 2(%q2,%%rcx,2)\n + sub $2, %%rcx\n + jge 1b\n + : +r (d1), +r (s_2xn), +r (d2), +c (n) +@@ -53,20 +53,20 @@ deinterleave2_mmx (int16_t *d1, int16_t + asm volatile (\n + xor %%rcx, %%rcx\n + 1:\n +-movq (%1,%%rcx,4), %%mm0\n +-movq 8(%1,%%rcx,4), %%mm1\n ++movq (%q1,%%rcx,4), %%mm0\n ++movq 8(%q1,%%rcx,4), %%mm1\n + pslld $16, %%mm0\n + pslld $16, %%mm1\n + psrad $16, %%mm0\n + psrad $16, %%mm1\n + packssdw %%mm1, %%mm0\n +-movq %%mm0, (%0,%%rcx,2)\n +-movq (%1,%%rcx,4), %%mm0\n +-movq 8(%1,%%rcx,4), %%mm1\n ++movq %%mm0, (%q0,%%rcx,2)\n ++movq (%q1,%%rcx,4), %%mm0\n ++movq 8(%q1,%%rcx,4), %%mm1\n + psrad $16, %%mm0\n + psrad $16, %%mm1\n + packssdw %%mm1, %%mm0\n +-movq %%mm0, (%2,%%rcx,2)\n ++movq %%mm0, (%q2,%%rcx,2)\n + add $4, %%rcx\n + cmp %3, %%ecx\n + jl 1b\n +@@ -93,10 +93,10 @@ deinterleave2_mmx_2 (int16_t *d1, int16_ + asm volatile (\n + xor %%rcx, %%rcx\n + 1:\n +-pshufw $0xd8, (%1,%%rcx,4), %%mm0\n +-movd %%mm0, (%0,%%rcx,2)\n +-pshufw $0x8d, (%1,%%rcx,4), %%mm0\n +-movd %%mm0, (%2,%%rcx,2)\n ++pshufw $0xd8, (%q1,%%rcx,4), %%mm0\n ++movd %%mm0, (%q0,%%rcx,2)\n ++pshufw $0x8d, (%q1,%%rcx,4), %%mm0\n ++movd %%mm0, (%q2,%%rcx,2)\n + add $2, %%rcx\n + cmp %3, %%ecx\n + jl 1b\n +@@ -123,16 +123,16 @@ deinterleave2_mmx_3 (int16_t *d1, int16_ + asm volatile (\n + xor %%rcx, %%rcx\n + 1:\n +-movq (%1,%%rcx,4), %%mm1\n +-movq (%1,%%rcx,4), %%mm2\n +-movq 8(%1,%%rcx,4), %%mm0\n ++movq (%q1,%%rcx,4), %%mm1\n ++movq (%q1,%%rcx,4), %%mm2\n ++movq 8(%q1,%%rcx,4), %%mm0\n + punpcklwd %%mm0, %%mm1\n + punpckhwd %%mm0, %%mm2\n + movq %%mm1, %%mm0\n + punpcklwd %%mm2, %%mm0\n + punpckhwd %%mm2, %%mm1\n +-movq %%mm0, (%0,%%rcx,2)\n +-movq %%mm1, (%2,%%rcx,2)\n ++movq %%mm0, (%q0,%%rcx,2)\n ++movq %%mm1, (%q2,%%rcx,2)\n + add $4, %%rcx\n + cmp %3, %%ecx\n + jl 1b\n +@@ -159,26 +159,26 @@ deinterleave2_mmx_4 (int16_t *d1, int16_ + asm volatile (\n + xor %%rcx, %%rcx\n + 1:\n +-movq (%1,%%rcx,4), %%mm1\n ++movq (%q1,%%rcx,4), %%mm1\n + movq %%mm1, %%mm2\n +-movq 8(%1,%%rcx,4), %%mm0\n +- movq 16(%1,%%rcx,4), %%mm5\n ++movq 8(%q1,%%rcx,4), %%mm0\n ++ movq 16(%q1,%%rcx,4), %%mm5\n + punpcklwd %%mm0, %%mm1\n + movq %%mm5, %%mm6\n + punpckhwd %%mm0, %%mm2\n +- movq 24(%1,%%rcx,4), %%mm4\n ++ movq 24(%q1,%%rcx,4), %%mm4\n + movq %%mm1, %%mm0\n + punpcklwd %%mm4, %%mm5\n + punpcklwd %%mm2, %%mm0\n + punpckhwd %%mm4, %%mm6\n + punpckhwd %%mm2, %%mm1\n + movq %%mm5, %%mm4\n +-movq %%mm0, (%0,%%rcx,2)\n ++movq
[OE-core] [PATCH 06/11] glib-2.0: fix compilatoin with x32 toolchain
From: Nitin A Kamble nitin.a.kam...@intel.com
Pass along CC CFLAGS vars so that the tune parameters set get used.
This fixes compilation with x32 toolchain.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: H.J. Lu hjl.to...@gmail.com
---
.../glib-2.0/glib-2.0/glib-2.0_fix_for_x32.patch | 76
meta/recipes-core/glib-2.0/glib-2.0_2.30.1.bb |3 +-
2 files changed, 78 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-core/glib-2.0/glib-2.0/glib-2.0_fix_for_x32.patch
diff --git a/meta/recipes-core/glib-2.0/glib-2.0/glib-2.0_fix_for_x32.patch
b/meta/recipes-core/glib-2.0/glib-2.0/glib-2.0_fix_for_x32.patch
new file mode 100644
index 000..70cbbbe
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/glib-2.0_fix_for_x32.patch
@@ -0,0 +1,76 @@
+UpstreamStatus: Pending
+
+Pass CC CFLAGS vars so that tune parameters get used.
+This fixes compilation with x32 toolchain.
+
+Received this patch from H.J. Lu hjl.to...@gmail.com
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com 2011/07/13
+
+Index: glib-2.30.0/glib/Makefile.am
+===
+--- glib-2.30.0.orig/glib/Makefile.am
glib-2.30.0/glib/Makefile.am
+@@ -359,10 +359,10 @@ INSTALL_PROGS=
+
+ if ENABLE_DTRACE
+ glib_probes.h: glib_probes.d Makefile
+- $(AM_V_GEN) $(DTRACE) -C -h -s $ -o $@.tmp
++ $(AM_V_GEN) CFLAGS=$(CFLAGS) $(DTRACE) -C -h -s $ -o $@.tmp
+ @$(SED) -e s,define STAP_HAS_SEMAPHORES 1,undef STAP_HAS_SEMAPHORES,
$@.tmp $@ rm -f $@.tmp
+ glib_probes.o: glib_probes.d Makefile
+- $(AM_V_GEN) $(DTRACE) -G -s $ -o $@
++ $(AM_V_GEN) CFLAGS=$(CFLAGS) $(DTRACE) -G -s $ -o $@
+ BUILT_SOURCES += glib_probes.h glib_probes.o
+ CLEANFILES += glib_probes.h glib_probes.h.tmp
+ libglib_2_0_la_LIBADD += glib_probes.o
+Index: glib-2.30.0/glib/Makefile.in
+===
+--- glib-2.30.0.orig/glib/Makefile.in
glib-2.30.0/glib/Makefile.in
+@@ -1691,10 +1691,10 @@ uninstall-local: uninstall-ms-lib uninst
+ @OS_WIN32_AND_DLL_COMPILATION_FALSE@uninstall-def-file:
+
+ @ENABLE_DTRACE_TRUE@glib_probes.h: glib_probes.d Makefile
+-@ENABLE_DTRACE_TRUE@ $(AM_V_GEN) $(DTRACE) -C -h -s $ -o $@.tmp
++@ENABLE_DTRACE_TRUE@ $(AM_V_GEN) CC=$(CC) CFLAGS=$(CFLAGS) $(DTRACE) -C
-h -s $ -o $@.tmp
+ @ENABLE_DTRACE_TRUE@ @$(SED) -e s,define STAP_HAS_SEMAPHORES 1,undef
STAP_HAS_SEMAPHORES, $@.tmp $@ rm -f $@.tmp
+ @ENABLE_DTRACE_TRUE@glib_probes.o: glib_probes.d Makefile
+-@ENABLE_DTRACE_TRUE@ $(AM_V_GEN) $(DTRACE) -G -s $ -o $@
++@ENABLE_DTRACE_TRUE@ $(AM_V_GEN) CC=$(CC) CFLAGS=$(CFLAGS) $(DTRACE) -G
-s $ -o $@
+
+ gspawn-win32-helper-console.c:
+ echo '#define HELPER_CONSOLE' $@
+Index: glib-2.30.0/gobject/Makefile.am
+===
+--- glib-2.30.0.orig/gobject/Makefile.am
glib-2.30.0/gobject/Makefile.am
+@@ -141,10 +141,10 @@ gobject_c_sources = \
+
+ if ENABLE_DTRACE
+ gobject_probes.h: gobject_probes.d Makefile
+- $(AM_V_GEN) $(DTRACE) -C -h -s $ -o $@.tmp
++ $(AM_V_GEN) CFLAGS=$(CFLAGS) $(DTRACE) -C -h -s $ -o $@.tmp
+ @$(SED) -e s,define STAP_HAS_SEMAPHORES 1,undef STAP_HAS_SEMAPHORES,
$@.tmp $@ rm -f $@.tmp
+ gobject_probes.o: gobject_probes.d Makefile
+- $(AM_V_GEN) $(DTRACE) -G -s $ -o $@
++ $(AM_V_GEN) CFLAGS=$(CFLAGS) $(DTRACE) -G -s $ -o $@
+ BUILT_SOURCES += gobject_probes.h gobject_probes.o
+ CLEANFILES += gobject_probes.h
+ libgobject_2_0_la_LIBADD += gobject_probes.o
+Index: glib-2.30.0/gobject/Makefile.in
+===
+--- glib-2.30.0.orig/gobject/Makefile.in
glib-2.30.0/gobject/Makefile.in
+@@ -1581,10 +1581,10 @@ uninstall-ms-lib:
+ @OS_WIN32_AND_DLL_COMPILATION_FALSE@uninstall-def-file:
+
+ @ENABLE_DTRACE_TRUE@gobject_probes.h: gobject_probes.d Makefile
+-@ENABLE_DTRACE_TRUE@ $(AM_V_GEN) $(DTRACE) -C -h -s $ -o $@.tmp
++@ENABLE_DTRACE_TRUE@ $(AM_V_GEN) CFLAGS=$(CFLAGS) $(DTRACE) -C -h -s $ -o
$@.tmp
+ @ENABLE_DTRACE_TRUE@ @$(SED) -e s,define STAP_HAS_SEMAPHORES 1,undef
STAP_HAS_SEMAPHORES, $@.tmp $@ rm -f $@.tmp
+ @ENABLE_DTRACE_TRUE@gobject_probes.o: gobject_probes.d Makefile
+-@ENABLE_DTRACE_TRUE@ $(AM_V_GEN) $(DTRACE) -G -s $ -o $@
++@ENABLE_DTRACE_TRUE@ $(AM_V_GEN) CFLAGS=$(CFLAGS) $(DTRACE) -G -s $ -o $@
+
+ # This is read by gobject-introspection/misc/ and gtk-doc
+ gobject-public-headers.txt: Makefile
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.30.1.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.30.1.bb
index 408ab83..bf415a1 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.30.1.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.30.1.bb
@@ -1,6 +1,6 @@
require glib.inc
-PR = r0
+PR = r1
PE = 1
DEPENDS += libffi python-argparse-native
@@ -13,6 +13,7 @@ SRC_URI =
${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.bz2 \
[OE-core] [PATCH 02/11] mdadm: fix CC definition in the Makefile
From: Nitin A Kamble nitin.a.kam...@intel.com
By hardcoding CC's definition in the Makefile, all the gcc parameters
set by tune settings are lost. Causing compile failure with x32 toolchain
As the bitbake defined CC is good, there is no need to redfine CC in the
make file, hence removed it to fix the issue.
This fixes bug: [YOCTO #1414]
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
.../mdadm/files/mdadm_fix_for_x32.patch| 24
meta/recipes-extended/mdadm/mdadm_3.2.2.bb |3 +-
2 files changed, 26 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-extended/mdadm/files/mdadm_fix_for_x32.patch
diff --git a/meta/recipes-extended/mdadm/files/mdadm_fix_for_x32.patch
b/meta/recipes-extended/mdadm/files/mdadm_fix_for_x32.patch
new file mode 100644
index 000..898e70b
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/mdadm_fix_for_x32.patch
@@ -0,0 +1,24 @@
+UpstreamStatus: pending
+
+By hardcoding CC's definition in the Makefile, all the gcc parameters
+set by tune settings are lost. Causing compile failure with x32 toolchain
+
+As the bitbake defined CC is good, there is no need to redfine CC in the
+make file, hence removed it to fix the issue.
+
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com
+2011/12/01
+
+Index: mdadm-3.2.2/Makefile
+===
+--- mdadm-3.2.2.orig/Makefile
mdadm-3.2.2/Makefile
+@@ -40,7 +40,7 @@ KLIBC=/home/src/klibc/klibc-0.77
+
+ KLIBC_GCC = gcc -nostdinc -iwithprefix include -I$(KLIBC)/klibc/include
-I$(KLIBC)/linux/include -I$(KLIBC)/klibc/arch/i386/include
-I$(KLIBC)/klibc/include/bits32
+
+-CC = $(CROSS_COMPILE)gcc
++#CC = $(CROSS_COMPILE)gcc
+ CXFLAGS = -ggdb
+ CWFLAGS = -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter
+ ifdef WARN_UNUSED
diff --git a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
index 97878ed..7e380ec 100644
--- a/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
+++ b/meta/recipes-extended/mdadm/mdadm_3.2.2.bb
@@ -8,10 +8,11 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://mdmon.c;beginline=4;endline=18;md5=af7d8444d9c4d3e5c7caac0d9d34039d \
file://mdadm.h;beglinlne=4;endline=22;md5=462bc9936ac0d3da110191a3f9994161
-PR = r2
+PR = r3
SRC_URI = ${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.bz2 \
file://0001-mdadm-fix-build-failures-ppc64.patch \
+ file://mdadm_fix_for_x32.patch \
SRC_URI[md5sum] = 12ee2fbf3beddb60601fb7a4c4905651
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 04/11] gmp: fix the recipe for x32 target
From: Nitin A Kamble nitin.a.kam...@intel.com
Add support for building with x32 toolchain.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: H.J. Lu hjl.to...@gmail.com
---
meta/recipes-support/gmp/gmp/gmp_bugfix.patch | 94
meta/recipes-support/gmp/gmp/gmp_fix_for_x32.patch | 45 +
meta/recipes-support/gmp/gmp_5.0.2.bb |6 +-
3 files changed, 143 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-support/gmp/gmp/gmp_bugfix.patch
create mode 100644 meta/recipes-support/gmp/gmp/gmp_fix_for_x32.patch
diff --git a/meta/recipes-support/gmp/gmp/gmp_bugfix.patch
b/meta/recipes-support/gmp/gmp/gmp_bugfix.patch
new file mode 100644
index 000..a96136f
--- /dev/null
+++ b/meta/recipes-support/gmp/gmp/gmp_bugfix.patch
@@ -0,0 +1,94 @@
+UpstreamStatus: Pending
+
+When LONG_MIN is passed to val, -val is undefined. This patch fixes
+it. See for details: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066
+
+Received this patch from H.J. Lu hjl.to...@gmail.com
+
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com 2011/12/01
+
+--- gmp-4.3.2/mpf/iset_si.c.ll 2010-01-07 12:09:03.0 -0800
gmp-4.3.2/mpf/iset_si.c2011-11-30 16:42:35.827944358 -0800
+@@ -31,7 +31,7 @@ mpf_init_set_si (mpf_ptr r, long int val
+ r-_mp_prec = prec;
+ r-_mp_d = (mp_ptr) (*__gmp_allocate_func) ((prec + 1) * BYTES_PER_MP_LIMB);
+
+- vl = (mp_limb_t) (unsigned long int) (val = 0 ? val : -val);
++ vl = (mp_limb_t) (val = 0 ? (unsigned long int) val : -(unsigned long int)
val);
+
+ r-_mp_d[0] = vl GMP_NUMB_MASK;
+ size = vl != 0;
+--- gmp-4.3.2/mpf/set_si.c.ll 2010-01-07 12:09:03.0 -0800
gmp-4.3.2/mpf/set_si.c 2011-11-30 16:42:47.823878367 -0800
+@@ -27,7 +27,7 @@ mpf_set_si (mpf_ptr dest, long val)
+ mp_size_t size;
+ mp_limb_t vl;
+
+- vl = (mp_limb_t) (unsigned long int) (val = 0 ? val : -val);
++ vl = (mp_limb_t) (val = 0 ? (unsigned long int) val : -(unsigned long int)
val);
+
+ dest-_mp_d[0] = vl GMP_NUMB_MASK;
+ size = vl != 0;
+--- gmp-4.3.2/mpz/cmp_si.c.ll 2010-01-07 12:09:03.0 -0800
gmp-4.3.2/mpz/cmp_si.c 2011-11-30 13:44:25.923319700 -0800
+@@ -27,7 +27,7 @@ _mpz_cmp_si (mpz_srcptr u, signed long i
+ {
+ mp_size_t usize = u-_mp_size;
+ mp_size_t vsize;
+- mp_limb_t u_digit;
++ mp_limb_t u_digit, vl_digit;
+
+ #if GMP_NAIL_BITS != 0
+ /* FIXME. This isn't very pretty. */
+@@ -41,11 +41,14 @@ _mpz_cmp_si (mpz_srcptr u, signed long i
+
+ vsize = 0;
+ if (v_digit 0)
+-vsize = 1;
++{
++ vsize = 1;
++ vl_digit = (mp_limb_t) (unsigned long) v_digit;
++}
+ else if (v_digit 0)
+ {
+ vsize = -1;
+- v_digit = -v_digit;
++ vl_digit = (mp_limb_t) -(unsigned long) v_digit;
+ }
+
+ if (usize != vsize)
+@@ -56,10 +59,10 @@ _mpz_cmp_si (mpz_srcptr u, signed long i
+
+ u_digit = u-_mp_d[0];
+
+- if (u_digit == (mp_limb_t) (unsigned long) v_digit)
++ if (u_digit == vl_digit)
+ return 0;
+
+- if (u_digit (mp_limb_t) (unsigned long) v_digit)
++ if (u_digit vl_digit)
+ return usize;
+ else
+ return -usize;
+--- gmp-4.3.2/mpz/iset_si.c.ll 2010-01-07 12:09:03.0 -0800
gmp-4.3.2/mpz/iset_si.c2011-11-30 13:44:25.924319695 -0800
+@@ -31,7 +31,7 @@ mpz_init_set_si (mpz_ptr dest, signed lo
+ dest-_mp_alloc = 1;
+ dest-_mp_d = (mp_ptr) (*__gmp_allocate_func) (BYTES_PER_MP_LIMB);
+
+- vl = (mp_limb_t) (unsigned long int) (val = 0 ? val : -val);
++ vl = (mp_limb_t) (val = 0 ? (unsigned long int) val : -(unsigned long int)
val);
+
+ dest-_mp_d[0] = vl GMP_NUMB_MASK;
+ size = vl != 0;
+--- gmp-4.3.2/mpz/set_si.c.ll 2010-01-07 12:09:03.0 -0800
gmp-4.3.2/mpz/set_si.c 2011-11-30 13:44:25.947319574 -0800
+@@ -27,7 +27,7 @@ mpz_set_si (mpz_ptr dest, signed long in
+ mp_size_t size;
+ mp_limb_t vl;
+
+- vl = (mp_limb_t) (unsigned long int) (val = 0 ? val : -val);
++ vl = (mp_limb_t) (val = 0 ? (unsigned long int) val : -(unsigned long int)
val);
+
+ dest-_mp_d[0] = vl GMP_NUMB_MASK;
+ size = vl != 0;
diff --git a/meta/recipes-support/gmp/gmp/gmp_fix_for_x32.patch
b/meta/recipes-support/gmp/gmp/gmp_fix_for_x32.patch
new file mode 100644
index 000..aa5641c
--- /dev/null
+++ b/meta/recipes-support/gmp/gmp/gmp_fix_for_x32.patch
@@ -0,0 +1,45 @@
+Upstream-Status: Pending
+
+Add X32 support in gmp configure.
+
+Patch Originator: H J Lu @ Intel
+Patch modified for Yocto by Nitin Kamble
+Signed Off By: Nitin A Kamble nitin.a.kam...@intel.com 2011/11/21
+
+--- gmp-4.3.2/configure.in.x32 2011-08-12 15:03:06.143548291 -0700
gmp-4.3.2/configure.in 2011-08-12 15:06:20.580595316 -0700
+@@ -1499,6 +1499,25 @@ case $host in
+ path_64=x86_64/atom x86_64
+ ;;
+ esac
++
++ # X32 support.
++ case x$path_64 in
++xx86_64*)
++ case x$CC $CFLAGS in
++x*-mx32*)
++ abilist=x32 64 32
[OE-core] [PATCH 09/11] xproto: fix compilation with x32 toolchain
From: Nitin A Kamble nitin.a.kam...@intel.com Don't always define LONG64 for AMD64 X32 defines __amd64__/amd64 with 32bit long. We should simply check __LP64__ before defining LONG64 without checking __amd64__/amd64. This fixes compilation with x32 toolchain. Signed-Off-By: H.J. Lu hjl.to...@gmail.com Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com 2011/12/1 --- .../xorg-proto/xproto/xproto_fix_for_x32.patch | 22 meta/recipes-graphics/xorg-proto/xproto_7.0.22.bb |4 ++- 2 files changed, 25 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-graphics/xorg-proto/xproto/xproto_fix_for_x32.patch diff --git a/meta/recipes-graphics/xorg-proto/xproto/xproto_fix_for_x32.patch b/meta/recipes-graphics/xorg-proto/xproto/xproto_fix_for_x32.patch new file mode 100644 index 000..c9fbb6f --- /dev/null +++ b/meta/recipes-graphics/xorg-proto/xproto/xproto_fix_for_x32.patch @@ -0,0 +1,22 @@ +UpstreamStatus: Pending + +Don't always define LONG64 for AMD64 + +X32 defines __amd64__/amd64 with 32bit long. We should simply check +__LP64__ before defining LONG64 without checking __amd64__/amd64. + +This fixes compilation with x32 toolchain. + +Received this patch from H.J. Lu hjl.to...@gmail.com +Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com 2011/12/1 + +--- xproto-7.0.22/Xmd.h.x322009-07-11 04:19:50.0 -0700 xproto-7.0.22/Xmd.h2011-11-30 17:14:19.290395893 -0800 +@@ -62,7 +62,6 @@ SOFTWARE. + defined(__ia64__) || defined(ia64) || \ + defined(__sparc64__) || \ + defined(__s390x__) || \ +- defined(__amd64__) || defined(amd64) || \ + defined(__powerpc64__) + # define LONG64 /* 32/64-bit architecture */ + # endif diff --git a/meta/recipes-graphics/xorg-proto/xproto_7.0.22.bb b/meta/recipes-graphics/xorg-proto/xproto_7.0.22.bb index 54f8482..8f76314 100644 --- a/meta/recipes-graphics/xorg-proto/xproto_7.0.22.bb +++ b/meta/recipes-graphics/xorg-proto/xproto_7.0.22.bb @@ -8,9 +8,11 @@ System. LICENSE = MIT MIT-style LIC_FILES_CHKSUM = file://COPYING;md5=b9e051107d5628966739a0b2e9b32676 -PR = r0 +PR = r1 PE = 1 +SRC_URI += file://xproto_fix_for_x32.patch + EXTRA_OECONF_append = --enable-specs=no BBCLASSEXTEND = native nativesdk -- 1.7.6.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/11] libaio: patch source code for x32
From: Nitin A Kamble nitin.a.kam...@intel.com
This Fixes bug: [YOCTO #1417]
Properly load arguments 5 an 6 for x86-64 syscall
Use asm (r10) and asm (r8) to load arguments 5 an 6 for x86-64
syscall so that it works with both x32 and x86-64.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Signed-Off-By: H.J. Lu hjl.to...@gmail.com
---
.../libaio/libaio/libaio_fix_for_x32.patch | 61
meta/recipes-extended/libaio/libaio_0.3.109.bb |5 +-
2 files changed, 64 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-extended/libaio/libaio/libaio_fix_for_x32.patch
diff --git a/meta/recipes-extended/libaio/libaio/libaio_fix_for_x32.patch
b/meta/recipes-extended/libaio/libaio/libaio_fix_for_x32.patch
new file mode 100644
index 000..508f5a1
--- /dev/null
+++ b/meta/recipes-extended/libaio/libaio/libaio_fix_for_x32.patch
@@ -0,0 +1,61 @@
+Upstream-Status: Pending
+
+Properly load arguments 5 an 6 for x86-64 syscall
+Use asm (r10) and asm (r8) to load arguments 5 an 6 for x86-64
+syscall so that it works with both x32 and x86-64.
+
+Received this patch from H.J. Lu hjl.to...@gmail.com
+
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com
+2011/12/02
+
+--- libaio-0.3.109/src/syscall-x86_64.h.x322009-10-09 11:17:02.0
-0700
libaio-0.3.109/src/syscall-x86_64.h2011-12-02 09:09:07.537603224
-0800
+@@ -1,8 +1,18 @@
++#ifndef __NR_io_setup
+ #define __NR_io_setup 206
++#endif
++#ifndef __NR_io_destroy
+ #define __NR_io_destroy 207
++#endif
++#ifndef __NR_io_getevents
+ #define __NR_io_getevents 208
++#endif
++#ifndef __NR_io_submit
+ #define __NR_io_submit209
++#endif
++#ifndef __NR_io_cancel
+ #define __NR_io_cancel210
++#endif
+
+ #define __syscall_clobber r11,rcx,memory
+ #define __syscall syscall
+@@ -42,10 +52,11 @@ return __res;
\
+ type fname (type1 arg1, type2 arg2, type3 arg3, type4 arg4) \
+ { \
+ long __res; \
+-__asm__ volatile (movq %5,%%r10 ; __syscall \
++register long __a4 asm (r10) = (long) arg4; \
++__asm__ volatile (__syscall \
+ : =a (__res) \
+ : 0 (__NR_##sname),D ((long)(arg1)),S ((long)(arg2)), \
+-d ((long)(arg3)),g ((long)(arg4)) : __syscall_clobber,r10 ); \
++d ((long)(arg3)),r (__a4)); \
+ return __res; \
+ }
+
+@@ -54,10 +65,11 @@ return __res;
\
+ type fname (type1 arg1,type2 arg2,type3 arg3,type4 arg4,type5 arg5) \
+ { \
+ long __res; \
+-__asm__ volatile (movq %5,%%r10 ; movq %6,%%r8 ; __syscall \
++register long __a4 asm (r10) = (long) arg4; \
++register long __a5 asm (r8) = (long) arg5; \
++__asm__ volatile ( __syscall \
+ : =a (__res) \
+ : 0 (__NR_##sname),D ((long)(arg1)),S ((long)(arg2)), \
+-d ((long)(arg3)),g ((long)(arg4)),g ((long)(arg5)) :\
+- __syscall_clobber,r8,r10 ); \
++d ((long)(arg3)),r (__a4),r (__a5));\
+ return __res; \
+ }
diff --git a/meta/recipes-extended/libaio/libaio_0.3.109.bb
b/meta/recipes-extended/libaio/libaio_0.3.109.bb
index 869b2da..161b712 100644
--- a/meta/recipes-extended/libaio/libaio_0.3.109.bb
+++ b/meta/recipes-extended/libaio/libaio_0.3.109.bb
@@ -5,12 +5,13 @@ HOMEPAGE = http://lse.sourceforge.net/io/aio.html;
LICENSE = LGPLv2.1+
LIC_FILES_CHKSUM = file://COPYING;md5=d8045f3b8f929c1cb29a1e3fd737b499
-PR = r0
+PR = r1
SRC_URI = ${DEBIAN_MIRROR}/main/liba/libaio/libaio_${PV}.orig.tar.gz \
file://00_arches.patch \
file://toolchain.patch \
- file://destdir.patch
+ file://destdir.patch \
+ file://libaio_fix_for_x32.patch
SRC_URI[md5sum] = 435a5b16ca6198eaf01155263d855756
SRC_URI[sha256sum] =
bf4a457253cbaab215aea75cb6e18dc8d95bbd507e9920661ff9bdd288c8778d
--
1.7.6.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 03/11] openssl-1.0.0e: fix to wotk with x32 toolchain
From: Nitin A Kamble nitin.a.kam...@intel.com
Add BN_ADDR for address type instead of using BN_ULONG or unsigned long:
1. For W64, address type is unsigned long long, not unsigned long.
2. For x32, address type is unsigned long , not BN_ULONG.
Added a new targetlinux-x32 in the config file
The do_install() code to move lib/* to lib64 is not needed now with the
enhanced multilib support.
Make the x86-64 assembly syntax compatible with x32 compiler.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
Signed-off-by: H.J. Lu hjl.to...@gmail.com
---
.../openssl-1.0.0e/openssl_fix_for_x32.patch | 90
meta/recipes-connectivity/openssl/openssl.inc | 15 ++--
.../recipes-connectivity/openssl/openssl_1.0.0e.bb |3 +-
3 files changed, 98 insertions(+), 10 deletions(-)
create mode 100644
meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl_fix_for_x32.patch
diff --git
a/meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl_fix_for_x32.patch
b/meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl_fix_for_x32.patch
new file mode 100644
index 000..10de986
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl-1.0.0e/openssl_fix_for_x32.patch
@@ -0,0 +1,90 @@
+UpstreamStatus: Pending
+
+Received from H J Liu @ Intel
+Make the assembly syntax compatible with x32 gcc. Othewise x32 gcc throws
errors.
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com 2011/07/13
+
+ported the patch to the 1.0.0e version
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com 2011/12/01
+Index: openssl-1.0.0e/Configure
+===
+--- openssl-1.0.0e.orig/Configure
openssl-1.0.0e/Configure
+@@ -393,6 +393,7 @@ my %table=(
+ linux-ia64-ecc,ecc:-DL_ENDIAN -DTERMIO -O2 -Wall
-no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
DES_INT:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+ linux-ia64-icc,icc:-DL_ENDIAN -DTERMIO -O2 -Wall
-no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1
DES_INT:${ia64_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+ linux-x86_64, gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wall
-DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64,
++linux-x32, gcc:-DL_ENDIAN -DTERMIO -O2 -pipe -g
-feliminate-unused-debug-types -Wall -DHAVE_CRYPTODEV
-DUSE_CRYPTODEV_DIGESTS::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-mx32:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+ linux-s390x,gcc:-m64 -DB_ENDIAN -DTERMIO -O3
-Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT
DES_UNROLL:${s390x_asm}:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64,
+ SPARC Linux setups
+ # Ray Miller ray.mil...@computing-services.oxford.ac.uk has patiently
+Index: openssl-1.0.0e/crypto/bn/asm/x86_64-gcc.c
+===
+--- openssl-1.0.0e.orig/crypto/bn/asm/x86_64-gcc.c
openssl-1.0.0e/crypto/bn/asm/x86_64-gcc.c
+@@ -55,7 +55,7 @@
+ *machine.
+ */
+
+-#ifdef _WIN64
++#if defined _WIN64 || !defined __LP64__
+ #define BN_ULONG unsigned long long
+ #else
+ #define BN_ULONG unsigned long
+@@ -192,9 +192,9 @@ BN_ULONG bn_add_words (BN_ULONG *rp, con
+ asm (
+ subq%2,%2 \n
+ .p2align 4 \n
+- 1: movq(%4,%2,8),%0\n
+- adcq(%5,%2,8),%0\n
+- movq%0,(%3,%2,8)\n
++ 1: movq(%q4,%2,8),%0 \n
++ adcq(%q5,%2,8),%0 \n
++ movq%0,(%q3,%2,8) \n
+ leaq1(%2),%2\n
+ loop1b \n
+ sbbq%0,%0 \n
+@@ -215,9 +215,9 @@ BN_ULONG bn_sub_words (BN_ULONG *rp, con
+ asm (
+ subq%2,%2 \n
+ .p2align 4 \n
+- 1: movq(%4,%2,8),%0\n
+- sbbq(%5,%2,8),%0\n
+- movq%0,(%3,%2,8)\n
++ 1: movq(%q4,%2,8),%0 \n
++ sbbq(%q5,%2,8),%0 \n
++ movq%0,(%q3,%2,8) \n
+ leaq1(%2),%2\n
+ loop1b \n
+ sbbq%0,%0 \n
+Index: openssl-1.0.0e/crypto/bn/bn.h
+===
+--- openssl-1.0.0e.orig/crypto/bn/bn.h
openssl-1.0.0e/crypto/bn/bn.h
+@@ -172,6 +172,13 @@ extern C {
+ # endif
+ #endif
+
++/* Address type. */
++#ifdef _WIN64
++#define BN_ADDR unsigned long long
++#else
++#define BN_ADDR unsigned long
++#endif
++
+ /* assuming long is 64bit - this is the DEC Alpha
+ * unsigned long long is only 64 bits :-(, don't define
+ * BN_LLONG for the DEC Alpha
Re: [OE-core] Feedback on building openembedded-core for qemuarm. Excerpts from buildlog
On 2011-12-02 10:49, Koen Kooi wrote: Op 1 dec. 2011, om 17:31 heeft Ulf Samuelsson het volgende geschreven: 2011-12-01 16:37, Koen Kooi skrev: Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven: On 11/29/2011 03:06 PM, Koen Kooi wrote: Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven: On 2011-11-29 16:03, Richard Purdie wrote: 2.ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz; is no longer available. tzdata , same problem. The recipe is located in two places. meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the problem This is what the build uses. This is something to raise with the meta-oe maintainers. I think there isn't a problem in OECore. Since we now have a large number of layers, maybe it is a good idea to define in each layer, how the git send email should behave in by providing a better .git/config file in the trunk? I.E: [sendemail] to = openembedded-core@lists.openembedded.org or meta-angstrom/.git/config [sendemail] to = angstrom-distro-de...@linuxtogo.org [format] subjectprefix = [meta-angstrom] No need to look in the README file with this. That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers Even if it is not the preferred way, it would direct the discussion to the appropriate list. This would reduce the number of mis-directed emails to this list. You can't fix stupid, sadly. Tend to disagree. The whole purpose of OE is to make it possible for people, stupid or not, to go off and make things which they would not be able to do on their own. As I see it, it is no real drawback of adding this, and at least some benefit. The drawback is that people will postpone reading the README even longer. Why are you so dead against having people read the README? I am against that every layer should *appear to* have their own way of treating feedback. There should be a common README on how to provide a patch, and any difference in where it ends up should be hidden in the system. This will make it easy for the causal user of a layer. If you want stuff to be pulled, then there are ways of handling this. Instead of directing the email to a list, you could direct the mail to a special address, which bounces back a message saying that the recommended thing is to pull. It could of course forward to the real list as well. As mentioned before by me, and by Frans right now, If I have to set up a git mirror for something I dont use (like meta-ti right now), just because this has a problem which affects my builds, I won't do that. As I dig deeper into openembedded-core, I will probably get to setting up git mirrors for the layers I use. OTOH , If I am bored and pull up my Beagleboard from a drawer, again I would probably do a git mirror for meta-ti. Some further study shows that the idea will not work as intended fully. meta-openembedded and meta-handhelds have meta-* subdirectories which each have their own README with different instructions for the same git tree. Seems kind of strange to me. BR Ulf Samuelsson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Best Regards Ulf Samuelsson eMagii ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Coordinating inter-layer dependencies
From: openembedded-core-boun...@lists.openembedded.org [openembedded-core-boun...@lists.openembedded.org] on behalf of Martin Jansa [martin.ja...@gmail.com] Sent: Friday, December 02, 2011 5:18 PM To: Patches and discussions about the oe-core layer Subject: Re: [OE-core] Coordinating inter-layer dependencies ...cut... As I understand it, the PRINC increases the PR of the appended recipe. Then the resulting package will have a version that is the same as the next version of the base recipe. Since many people (me included) hardly remember what they did a month ago, isn't there a big risk of confusion in your deployed systems if packages are upgraded there? I do something like PR .= .local0 where local is the name of the layer containing the .bbappend. Of course this will create extensive version strings if multiple .bbappends are applied but the alternative is that you have no idea what layers that appended and what the the base version of the recipe really was. So if you have some layer adding layerB: PR .= .b0 and other layerA: PR .= .a0 and PR appends are evaluated in this order, then you will break upgrade patch forever if you have to remove layerB for some reason and you cannot even fix it by bumping numbers in your layerA unless you rename all PR appends as .c0 right? That's why I prefer to use PRINC. I don't really see what is breaking but I'm guessing that the problem you describe has to do with feed based upgrades and automatic evaluation of which version is latest (?). I don't do things that way but instead explicitly download and replace packages and then I prefer to be able to see exactly what was built. Of course you can achieve that also by some external procedure to make sure that you always no matter what produce increasing PR numbers on your packages but if you fail there is no telling... Yes it increases PR of desired number, but every time.. so if upper layer increments PR your .bbappend will again increment it so you still get always increasing sequence. Unless, again, I remove a layer, then I'll have to extra-bump another innocent layer to keep the numbers up. BR // Mats ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Parse error with empty builddir
Hi
after pulling latest sources (angstrom environment) I get:
Pseudo is not present but is required, building this first before the main build
NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv
library is used
| ETA: 00:01:10
NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv
library is used
ERROR: Failure expanding variable PRINC[:=], expression was ${@int(PRINC) + 1}
which triggered exception NameError: name 'PRINC' is not defined
| ETA: 00:00:44
ERROR: Command execution failed: Exited with 1
[Superandy@localhost oe-core]$ grep -r PRINC *
It seems contstructs like ${@int(PRINC) + 1} are common and found in several
recipes (outside of oe-core). I was out last week and still checking mails: did
I miss something?
Andreas
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: You have been unsubscribed from the Openembedded-core mailing list
On Fri, 2011-12-02 at 12:02 +0100, Frans Meulenbroeks wrote: Why have I been unsubscribed from the list?? Are we censoring users that voice opinions that for whatever reason do not meet the list maintainer ?? Or did I say something that violates the list etiquette? If so I would have appreciated a message about that (and perhaps a warning upfront). Not that I can recall having said something wrong Frans, we're sorry you were unsubscribed unexpectedly. This wasn't for any justified reason so we can only apologise and assure you that the circumstances this occurred under can no longer occur. We gather you have resubscribed, sorry for the inconvenience. Richard (On behalf of the OE board and TSC) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Parse error with empty builddir
On Sat, Dec 03, 2011 at 01:11:03AM +0100, Andreas Müller wrote:
Hi
after pulling latest sources (angstrom environment) I get:
Pseudo is not present but is required, building this first before the main
build
NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv
library is used
| ETA: 00:01:10
NOTE: angstrom DOES NOT support libiconv because the eglibc provided iconv
library is used
ERROR: Failure expanding variable PRINC[:=], expression was ${@int(PRINC) +
1}
which triggered exception NameError: name 'PRINC' is not defined
| ETA: 00:00:44
ERROR: Command execution failed: Exited with 1
[Superandy@localhost oe-core]$ grep -r PRINC *
It seems contstructs like ${@int(PRINC) + 1} are common and found in several
recipes (outside of oe-core). I was out last week and still checking mails:
did
I miss something?
Apply this:
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/013779.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
