date:20130212



On 02/12/2013 01:22 AM, Jason Wessel wrote:
 Now that I have had to debug the SDK relocator on multiple occasions
 I figure it might be nice to get the patches upstreamed.
But, before that, did you see my comments on the previous patchset? It
looks like they went unnoticed as they were not addressed.

Here is what I replied to your previous patches:
http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/034868.html
http://lists.linuxtogo.org/pipermail/openembedded-core/2013-January/034869.html

Thanks,
Laurentiu

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] qemu: upgrade to 1.3.1

2013-02-12 Thread Constantin Musca


On 02/11/2013 07:46 PM, Saul Wold wrote:


qhat kind of testing have you done with this update, since qemu is 
core to our BSPs I want to make sure we have tested it well.

I have tested core-image-sato on all qemu archs.

Cheers,
Constantin


Thanks
Sau!


On 02/11/2013 05:01 AM, Constantin Musca wrote:

Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
  meta/recipes-devtools/qemu/{qemu_1.3.0.bb = qemu_1.3.1.bb} | 4 ++--
  meta/recipes-devtools/qemu/qemu_git.bb  | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)
  rename meta/recipes-devtools/qemu/{qemu_1.3.0.bb = qemu_1.3.1.bb} 
(64%)


diff --git a/meta/recipes-devtools/qemu/qemu_1.3.0.bb 
b/meta/recipes-devtools/qemu/qemu_1.3.1.bb

similarity index 64%
rename from meta/recipes-devtools/qemu/qemu_1.3.0.bb
rename to meta/recipes-devtools/qemu/qemu_1.3.1.bb
index 7d007ea..c04b2be 100644
--- a/meta/recipes-devtools/qemu/qemu_1.3.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_1.3.1.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \

file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913

  SRC_URI_prepend = http://wiki.qemu.org/download/qemu-${PV}.tar.bz2;
-SRC_URI[md5sum] = a4030ddd2ba324152a97d65d3c0b247d
-SRC_URI[sha256sum] = 
878055ec05bc28fecfe2da97eb8bc992e8635575b67cebdfc5ca1ede171140a8

+SRC_URI[md5sum] = 5dbc6c22f47efca71dfaae0dd80dcf9e
+SRC_URI[sha256sum] = 
3772e7ef0c9b4178195edcf90e711f12ba123f465fcf09fb43b56bdacaca0eaf


  PR = r0
diff --git a/meta/recipes-devtools/qemu/qemu_git.bb 
b/meta/recipes-devtools/qemu/qemu_git.bb

index 9465203..328e3bf 100644
--- a/meta/recipes-devtools/qemu/qemu_git.bb
+++ b/meta/recipes-devtools/qemu/qemu_git.bb
@@ -1,6 +1,6 @@
  require qemu.inc

-SRCREV = 6d6c9f59ca1b1a76ade7ad868bef191818f58819
+SRCREV = 04024dea2674861fcf13582a77b58130c67fccd8

  LIC_FILES_CHKSUM = 
file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \

file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [OE-Core][PATCH] systemd: Add systemd package to PACKAGE var

If someone defines SYSTEMD_PACKAGES to be different
then ${PN} then we need to make sure that they get
added to PACKAGES variable

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 meta/classes/systemd.bbclass |7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index 32cc5c2..672f304 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -46,6 +46,12 @@ def systemd_populate_packages(d):
 val = (d.getVar(var, True) or ).strip()
 return val
 
+# prepend systemd-packages not already included
+def systemd_create_package(pkg_systemd):
+packages = d.getVar('PACKAGES', True)
+if not pkg_systemd in packages:
+d.appendVar('PACKAGES',   + pkg_systemd)
+
 
 # Add a runtime dependency on systemd to pkg
 def systemd_add_rdepends(pkg):
@@ -144,6 +150,7 @@ def systemd_populate_packages(d):
 # Run all modifications once when creating package
 if os.path.exists(d.getVar(D, True)):
 for pkg in d.getVar('SYSTEMD_PACKAGES', True).split():
+systemd_create_package(pkg)
 if d.getVar('SYSTEMD_SERVICE_' + pkg, True):
 systemd_generate_package_scripts(pkg)
 systemd_add_rdepends(pkg)
-- 
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] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Anders Darander

* Otavio Salvador ota...@ossystems.com.br [130211 18:50]:

 On Mon, Feb 11, 2013 at 3:09 PM, Paul Eggleton
 paul.eggle...@linux.intel.com wrote:
 ...
  * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
  * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
  These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this
  as a distro policy decision; these should move to the layers for whichever
  distros want this. FWIW, this is particularly egregious if you've already
  built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

 Yes; I think I agree also because *most* people won't use these
 backends so better to handle this in the specific
 layers/distros/whatever needs it.

Definitely in favour of this.

That would simplify my own bbappends a lot, by letting me remove quite a
few oe_filter_out's...

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd: Add systemd package to PACKAGE var

On Tuesday, 12 February 2013 at 08:22, Khem Raj wrote:
 If someone defines SYSTEMD_PACKAGES to be different
 then ${PN} then we need to make sure that they get
 added to PACKAGES variable

The only case it won't already be in PACKAGES is if you're creating a package 
which contains just the service file, which as I've said before isn't 
recommended - package the service files along with the binaries that they are 
executing.

Or is there another use-case I'm missing?

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/8] busybox: add ifup's ifstate dir to package

2013-02-12 Thread Bernhard Reutner-Fischer

On Mon, Feb 11, 2013 at 09:46:31PM -0800, Saul Wold wrote:
On 02/05/2013 07:55 AM, Bernhard Reutner-Fischer wrote:
ifupdown stores its ifstate into CONFIG_IFIPDOWN_IFSTATE_PATH.
Fixes:
ifup: can't open '/var/run/ifstate': No such file or directory

Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
---
  meta/recipes-core/busybox/busybox.inc |4 
  1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 972e7d0..972df6d 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -199,6 +199,10 @@ do_install () {
 install -m 644 ${WORKDIR}/mdev.conf 
 ${D}${sysconfdir}/mdev.conf
 fi
  fi
+ IFUPDOWN_IFSTATE_PATH=`awk 
'/^CONFIG_IFUPDOWN_IFSTATE_PATH/{split($0,x,/=/);p=x[2];gsub(\,,p);print 
p;}' ${WORKDIR}/defconfig`
+ if test -n $IFUPDOWN_IFSTATE_PATH; then
Should this also be ${D} in the test, other wise you might be testing
the host!

WORKDIR is correct, see meta/conf/bitbake.conf setting WORKDIR.
thanks,


Sau!

+ install -m 0755 -d ${D}/$IFUPDOWN_IFSTATE_PATH
+ fi
  install -m 0644 ${S}/busybox.links ${D}${sysconfdir}
  }



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: meta-oe appends and overlayed recipes

On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
 On Mon, 2013-02-11 at 17:09 +, Paul Eggleton wrote:
  *
  meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappe
  nd This is adding qwt to the qte toolchain. As far as I am concerned this
  is a distro policy decision - Qwt is a third-party library that is not
  part of Qt. I believe this should be moved to the layers for whichever
  distros want this.
  
  * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
  * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
  These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see
  this as a distro policy decision; these should move to the layers for
  whichever distros want this. FWIW, this is particularly egregious if
  you've already built Qt, then add meta-oe and find Qt is being
  unexpectedly rebuilt.
 If these were implemented as PACKAGECONFIG options, then distros would
 just need to set the appropriate PACKAGECONFIG for the package in the
 distro config and we wouldn't even need the appends...

The thing is the Qt configure options are a little more complicated - many of 
them are three-state switches (enable built-in, enable as a plugin or 
disabled). Thus we've opted to split the configuration options into variables 
for each type. We don't get PACKAGECONFIG's DEPENDS handling, but if we used 
PACKAGECONFIG we'd lose some flexibility.

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] [denzil] qt 4.8.0 is not available from source anymore

2013-02-12 Thread Michael Halstead


On 02/11/2013 06:57 AM, Andrei Gherzan wrote:



 On Mon, Feb 11, 2013 at 4:43 PM, Paul Eggleton
 paul.eggle...@linux.intel.com mailto:paul.eggle...@linux.intel.com
 wrote:

 On Monday 11 February 2013 16:01:10 Andrei Gherzan wrote:
  On Mon, Feb 11, 2013 at 3:10 PM, Sarbu, Florin-Ionut (Florin) 
  florin.sa...@windriver.com mailto:florin.sa...@windriver.com
 wrote:
   On Monday, February 11, 2013 02:51 AM Andrei Gherzan wrote:
   
In denzil SRC_URI for qt4.8.0 uses:
   
 http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.tar.g
 
 http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-$%7BPV%7D.tar.g
z
   
 This source seems to be outdated and replaced by:
http://releases.qt-project.org/qt4/source/
   
 The problem is that the new location doesn't include the
 4.8.0 release.
 qt-everywhere-opensource-src-4.6.4.tar.gz
 qt-everywhere-opensource-src-4.8.1.tar.gz
 qt-everywhere-opensource-src-4.8.2.tar.gz
 qt-everywhere-opensource-src-4.8.3.tar.gz
 qt-everywhere-opensource-src-4.8.4.tar.gz
   
 So right now qt4 in denzil is not fetch-able anymore.
  
Use git
 
  We are not talking about switching of sources. I want to know
 why 4.8.0 is
  not on yocto mirror.

 It should be there, not sure why it isn't.

 Michael, could you please upload qt 4.8.0 and anything else
 downloaded by
 bitbake -c fetchall world for the denzil-7.0.2 release into the
 mirror?

I ran fetchall world and poky 7.0.2 uses
qt-everywhere-opensource-src-4.7.4.tar.gz which was already present at
http://downloads.yoctoproject.org/mirror/sources/. Every file downloaded
was already present on the mirror.

I downloaded qt-everywhere-opensource-src-4.8.0.tar.gz from a Fedora
Project mirror and added it to
http://downloads.yoctoproject.org/mirror/sources/ so we'd have it.

Michael Halstead
Yocto Project / System Administrator




 Thank you.

 -- 
 *Andrei Gherzan*
 m: +40.744.478.414 |  f: +40.31.816.28.12



smime.p7s
Description: S/MIME Cryptographic Signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

On 11 February 2013 17:09, Paul Eggleton paul.eggle...@linux.intel.com wrote:
 I'd like to make an attempt to remove all appends and overlayed recipes from
 the meta-oe layer. As I've said previously, I don't believe meta-oe - as a
 collection of very useful additional recipes that many wish to be able to use
 on top of their OE-Core based build configurations - should be making any
 possibly unexpected changes to those configurations. Any such changes ought to
 be the province of distro layers alone.

Hear hear!

 * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe that is
 ahead of 1.0; the OE-Core version has two patches not in the meta-oe version
 but that both have been merged upstream in the git revision being used in the
 meta-oe version. There is no newer stable release. What do we do here? Should
 we ask upstream (Chris) for a new stable release?

Is anyone actually using tslib these days?  oe-core dropped kdrive,
and we don't package the apparently unmaintained input driver for
Xorg.  I guess a new upstream would be good, and then move to meta-oe.

 * xserver-nodm-init: the two versions are quite distinct. Not sure I
 understand the full history here but perhaps someone else can fill in the
 blanks...?

I don't understand the full history either yet, but this is clearly
something that needs to be sorted.

 * meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
 As far as I can tell this just adds an /etc/busybox-syslog.default file
 containing OPTIONS=-C64 and seems to have been added for systemd support.
 I'm not sure why this wasn't moved to meta-systemd, but I assume it needs to
 be merged into OE-Core now that systemd support is being added there... ?

When it's understood *what* that does, then we can evaluate it for oe-core.

 * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
 Another bbappend apparently for systemd support. Again, this should have been
 moved to meta-systemd; do we now need to merge it into OE-Core?

Yes, half of it has been merged to master already. The rest should be
in Radu's branch, we can sort that today.

 * meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
 Builds against external libav instead of using the builtin copy of ffmpeg,
 apparently for better performance on ARM (and presumably that is not the only
 benefit). It's less clear to me what should be done with this, but I'd still
 rather it could be eliminated. OE-Core does not have ffmpeg/libav; one wonders
 if it should or not.

libav/gst-ffmpeg/gst-av (as it's called in gst1.0) has interesting
legal issues, but I do think it should be in oe-core.

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [denzil] qt 4.8.0 is not available from source anymore

On Tuesday 12 February 2013 02:20:29 Michael Halstead wrote:
 On 02/11/2013 06:57 AM, Andrei Gherzan wrote:
  On Mon, Feb 11, 2013 at 4:43 PM, Paul Eggleton
  paul.eggle...@linux.intel.com mailto:paul.eggle...@linux.intel.com
  
  wrote:
  On Monday 11 February 2013 16:01:10 Andrei Gherzan wrote:
   On Mon, Feb 11, 2013 at 3:10 PM, Sarbu, Florin-Ionut (Florin) 
   florin.sa...@windriver.com mailto:florin.sa...@windriver.com
  
  wrote:
On Monday, February 11, 2013 02:51 AM Andrei Gherzan wrote:
 In denzil SRC_URI for qt4.8.0 uses:
  http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.t
  ar.g
  http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-$%7BPV
  %7D.tar.g 
 z
 
  This source seems to be outdated and replaced by:
 http://releases.qt-project.org/qt4/source/
 
  The problem is that the new location doesn't include the
  
  4.8.0 release.
  
  qt-everywhere-opensource-src-4.6.4.tar.gz
  qt-everywhere-opensource-src-4.8.1.tar.gz
  qt-everywhere-opensource-src-4.8.2.tar.gz
  qt-everywhere-opensource-src-4.8.3.tar.gz
  qt-everywhere-opensource-src-4.8.4.tar.gz
  
  So right now qt4 in denzil is not fetch-able anymore.
 
 Use git
   
   We are not talking about switching of sources. I want to know
  
  why 4.8.0 is
  
   not on yocto mirror.
  
  It should be there, not sure why it isn't.
  
  Michael, could you please upload qt 4.8.0 and anything else
  downloaded by
  bitbake -c fetchall world for the denzil-7.0.2 release into the
  mirror?
 
 I ran fetchall world and poky 7.0.2 uses
 qt-everywhere-opensource-src-4.7.4.tar.gz which was already present at
 http://downloads.yoctoproject.org/mirror/sources/. Every file downloaded
 was already present on the mirror.

Ah, now I remember - with denzil, Qt 4.7.4 was the default and 4.8.0 was an 
option.

 I downloaded qt-everywhere-opensource-src-4.8.0.tar.gz from a Fedora
 Project mirror and added it to
 http://downloads.yoctoproject.org/mirror/sources/ so we'd have it.

Thanks!

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] [denzil] qt 4.8.0 is not available from source anymore

2013-02-12 Thread Andrei Gherzan

On Tue, Feb 12, 2013 at 12:20 PM, Michael Halstead mich...@yoctoproject.org
 wrote:


  On 02/11/2013 06:57 AM, Andrei Gherzan wrote:




 On Mon, Feb 11, 2013 at 4:43 PM, Paul Eggleton 
 paul.eggle...@linux.intel.com wrote:

 On Monday 11 February 2013 16:01:10 Andrei Gherzan wrote:
  On Mon, Feb 11, 2013 at 3:10 PM, Sarbu, Florin-Ionut (Florin) 
  florin.sa...@windriver.com wrote:
On Monday, February 11, 2013 02:51 AM Andrei Gherzan wrote:
   
In denzil SRC_URI for qt4.8.0 uses:
   
 http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.tar.g
z
   
 This source seems to be outdated and replaced by:
http://releases.qt-project.org/qt4/source/
   
 The problem is that the new location doesn't include the 4.8.0
 release.
 qt-everywhere-opensource-src-4.6.4.tar.gz
 qt-everywhere-opensource-src-4.8.1.tar.gz
 qt-everywhere-opensource-src-4.8.2.tar.gz
 qt-everywhere-opensource-src-4.8.3.tar.gz
 qt-everywhere-opensource-src-4.8.4.tar.gz
   
 So right now qt4 in denzil is not fetch-able anymore.
  
 Use git
 
  We are not talking about switching of sources. I want to know why 4.8.0
 is
  not on yocto mirror.

  It should be there, not sure why it isn't.

 Michael, could you please upload qt 4.8.0 and anything else downloaded by
 bitbake -c fetchall world for the denzil-7.0.2 release into the mirror?

   I ran fetchall world and poky 7.0.2 uses
 qt-everywhere-opensource-src-4.7.4.tar.gz which was already present at
 http://downloads.yoctoproject.org/mirror/sources/. Every file downloaded
 was already present on the mirror.

 I downloaded qt-everywhere-opensource-src-4.8.0.tar.gz from a Fedora
 Project mirror and added it to
 http://downloads.yoctoproject.org/mirror/sources/ so we'd have it.


Thank you. 4.8.0 had default preferrence -1.

-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

On Tuesday 12 February 2013 10:24:50 Burton, Ross wrote:
* tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
that is ahead of 1.0; the OE-Core version has two patches not in the
meta-oe version but that both have been merged upstream in the git
revision being used in the meta-oe version. There is no newer stable
release. What do we do here? Should we ask upstream (Chris) for a new
stable release?

Is anyone actually using tslib these days? oe-core dropped kdrive,
and we don't package the apparently unmaintained input driver for
Xorg. I guess a new upstream would be good, and then move to meta-oe.

Qt Embedded as we build it is currently configured to use tslib, as is
SDL. If the alternative (evdev?) is supported they could presumably be
switched over though. I don't know how practical that is however.

* xserver-nodm-init: the two versions are quite distinct. Not sure I
understand the full history here but perhaps someone else can fill in the
blanks...?

I don't understand the full history either yet, but this is clearly
something that needs to be sorted.

* meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
As far as I can tell this just adds an /etc/busybox-syslog.default file
containing OPTIONS=-C64 and seems to have been added for systemd
support.
I'm not sure why this wasn't moved to meta-systemd, but I assume it needs
to be merged into OE-Core now that systemd support is being added
there... ?
When it's understood *what* that does, then we can evaluate it for oe-core.

The following commit introduced this:

http://cgit.openembedded.org/meta-openembedded/commit/?id=c48a6a605c6d8d38cfbc5df39b3dc310bffc07c1

Otavio can you explain further?

* meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
Another bbappend apparently for systemd support. Again, this should have
been moved to meta-systemd; do we now need to merge it into OE-Core?

Yes, half of it has been merged to master already. The rest should be
in Radu's branch, we can sort that today.

OK, great.

* meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
Builds against external libav instead of using the builtin copy of ffmpeg,
apparently for better performance on ARM (and presumably that is not the
only benefit). It's less clear to me what should be done with this, but
I'd still rather it could be eliminated. OE-Core does not have
ffmpeg/libav; one wonders if it should or not.

libav/gst-ffmpeg/gst-av (as it's called in gst1.0) has interesting
legal issues, but I do think it should be in oe-core.

Well, we already have gst-ffmpeg in OE-Core so I can't imagine libav
would be any worse as long as it is similarly protected with
LICENSE_FLAGS.

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 v2 0/3] relocate_sdk.py: improvements

On 02/12/2013 04:24 AM, Laurentiu Palcu wrote:

 On 02/12/2013 12:19 PM, Jason Wessel wrote:
 For what ever reason I never received the original mails, else I absolutely 
 would have responded.  This is the first response I have received from the 
 oe-core list in months in fact.
 I believe you... It happened to me too not to receive replies to my own
 patches. :/

Hard to say where the mail went other than the black hole.   We too have had 
black hole issues, but I had always assumed it was on anti-spam filter side 
with our local mail server.

As a side point it occurred to me that I never answered your other question, 
which was about what qemu we were using.   At the time I hit the problem with 
the silent .interp corruption it was the qemu from denzil.  Silent corruption 
is never fun to find or deal with, we had just ended up with binary that 
segmentation faulted some of the time.  One time through trying to figure out 
what the root of the problem was more than enough.  I figured I never wanted 
anyone else to have to debug that problem again, which the origin of these 
patches. ;-)

Cheers,
Jason.

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 1/3] relocate_sdk.py: Fix corruption of sdk binaries

There are two cases of corruption that the relocate_sdk.py was not correctly
dealing with.

1) SDK Extras should be left alone
   Extra external binaries included in an SDK that were linked against the
   host's version of /usr/lib/ld-so.so should not get a relocation applied.
   In the case that was discovered these were LSB compliant binaries that
   already worked on many hosts.

2) If the interp section is too small generate an error
   In the case of the qemu user code, it was using its own .ld file
   to link the executables which overrides the default in the nativesdk
   binutils.  This generated host executables which had a interp section
   that was too small to relocate.

   Now the relocate_sdk.py will print an error and continue on such that
   the error can be fixed by a developer without having to do the
   difficult task of debugging why it is crashing or not loading correctly.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 scripts/relocate_sdk.py |   13 +++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py
index 74bb7a5..45d2c24 100755
--- a/scripts/relocate_sdk.py
+++ b/scripts/relocate_sdk.py
@@ -66,7 +66,7 @@ def parse_elf_header():
 e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\
 hdr_struct.unpack(elf_header[16:hdr_size])
 
-def change_interpreter():
+def change_interpreter(elf_file_name):
 if arch == 32:
 ph_struct = struct.Struct()
 else:
@@ -89,7 +89,16 @@ def change_interpreter():
 if p_type == 3:
 # PT_INTERP section
 f.seek(p_offset)
+# External SDKs with mixed pre-compiled binaries should not get
+# relocated so look for some variant of /lib
+fname = f.read(11)
+if fname.startswith(/lib/) or fname.startswith(/lib64/) or 
fname.startswith(/lib32/) or fname.startswith(/usr/lib32/) or 
fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib64/):
+break
+if (len(new_dl_path) = p_filesz):
+print ERROR: could not relocate %s, interp size = %i and %i 
is needed. % (elf_file_name, p_memsz, len(new_dl_path) + 1)
+break
 dl_path = new_dl_path + \0 * (p_filesz - len(new_dl_path))
+f.seek(p_offset)
 f.write(dl_path)
 break
 
@@ -199,7 +208,7 @@ for e in executables_list:
 arch = get_arch()
 if arch:
 parse_elf_header()
-change_interpreter()
+change_interpreter(e)
 change_dl_sysdirs()
 
  change permissions back 
-- 
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 v3 3/3] relocate_sdk.py: allow relocate_sdk.py to work with python 2.4.x

Avoid the chicken / egg problem of an SDK that provides a working
python but requires that version of python to extract itself.  The
RHEL 5.x systems and some other enterprise Linux systems ship with
python 2.4.x as the default python.  We need to at least be able to
extract work executables even if we never use the the host provided
python again.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 scripts/relocate_sdk.py |   26 +-
 1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py
index 45d2c24..1d7bbb3 100755
--- a/scripts/relocate_sdk.py
+++ b/scripts/relocate_sdk.py
@@ -55,22 +55,22 @@ def parse_elf_header():
 
 if arch == 32:
 # 32bit
-hdr_struct = struct.Struct(HHILLLIHH)
+hdr_fmt = HHILLLIHH
 hdr_size = 52
 else:
 # 64bit
-hdr_struct = struct.Struct(HHIQQQIHH)
+hdr_fmt = HHIQQQIHH
 hdr_size = 64
 
 e_type, e_machine, e_version, e_entry, e_phoff, e_shoff, e_flags,\
 e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\
-hdr_struct.unpack(elf_header[16:hdr_size])
+struct.unpack(hdr_fmt, elf_header[16:hdr_size])
 
 def change_interpreter(elf_file_name):
 if arch == 32:
-ph_struct = struct.Struct()
+ph_fmt = 
 else:
-ph_struct = struct.Struct(IIQQ)
+ph_fmt = IIQQ
 
  look for PT_INTERP section 
 for i in range(0,e_phnum):
@@ -79,11 +79,11 @@ def change_interpreter(elf_file_name):
 if arch == 32:
 # 32bit
 p_type, p_offset, p_vaddr, p_paddr, p_filesz,\
-p_memsz, p_flags, p_align = ph_struct.unpack(ph_hdr)
+p_memsz, p_flags, p_align = struct.unpack(ph_fmt, ph_hdr)
 else:
 # 64bit
 p_type, p_flags, p_offset, p_vaddr, p_paddr, \
-p_filesz, p_memsz, p_align = ph_struct.unpack(ph_hdr)
+p_filesz, p_memsz, p_align = struct.unpack(ph_fmt, ph_hdr)
 
  change interpreter 
 if p_type == 3:
@@ -104,9 +104,9 @@ def change_interpreter(elf_file_name):
 
 def change_dl_sysdirs():
 if arch == 32:
-sh_struct = struct.Struct(II)
+sh_fmt = II
 else:
-sh_struct = struct.Struct(IIIIQQ)
+sh_fmt = IIIIQQ
 
  read section string table 
 f.seek(e_shoff + e_shstrndx * e_shentsize)
@@ -127,7 +127,7 @@ def change_dl_sysdirs():
 sh_hdr = f.read(e_shentsize)
 
 sh_name, sh_type, sh_flags, sh_addr, sh_offset, sh_size, sh_link,\
-sh_info, sh_addralign, sh_entsize = sh_struct.unpack(sh_hdr)
+sh_info, sh_addralign, sh_entsize = struct.unpack(sh_fmt, sh_hdr)
 
 name = sh_strtab[sh_name:sh_strtab.find(\0, sh_name)]
 
@@ -181,7 +181,7 @@ def change_dl_sysdirs():
 
 # MAIN
 if len(sys.argv)  4:
-exit(-1)
+sys.exit(-1)
 
 new_prefix = sys.argv[1]
 new_dl_path = sys.argv[2]
@@ -196,14 +196,14 @@ for e in executables_list:
 
 try:
 f = open(e, r+b)
-except IOError as ioex:
+except IOError, ioex:
 if ioex.errno == errno.ETXTBSY:
 print(Could not open %s. File used by another process.\nPlease \
   make sure you exit all processes that might use any SDK \
   binaries. % e)
 else:
 print(Could not open %s: %s(%d) % (e, ioex.strerror, ioex.errno))
-exit(-1)
+sys.exit(-1)
 
 arch = get_arch()
 if arch:
-- 
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 v3 2/3] populate_sdk_base.bbclass: Improve debugging capabilities for SDK installer

After having to debug the SDK installer a few times in
addition to the relocation code the following patch was created
to improve the capabilities around debugging the SDK installer.

1) Add a verbose mode -D which set a set -x to see what
   the SDK installer is doing.

2) Add a mode -S to save the relocation scripts for the purpose
   of debugging them in conjunction with -D

3) Add a mode -R to not execute the relocation scripts for the
   purpose of debugging the relocations.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 meta/classes/populate_sdk_base.bbclass |   48 
 1 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index c025d40..923f925 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -136,7 +136,10 @@ DEFAULT_INSTALL_DIR=${SDKPATH}
 SUDO_EXEC=
 target_sdk_dir=
 answer=
-while getopts :yd: OPT; do
+relocate=1
+savescripts=0
+verbose=0
+while getopts :yd:DRS OPT; do
case $OPT in
y)
answer=Y
@@ -145,15 +148,33 @@ while getopts :yd: OPT; do
d)
target_sdk_dir=$OPTARG
;;
+   D)
+   verbose=1
+   ;;
+   R)
+   relocate=0
+   savescripts=1
+   ;;
+   S)
+   savescripts=1
+   ;;
*)
echo Usage: $(basename $0) [-y] [-d dir]
echo   -y Automatic yes to all prompts
echo   -d dir   Install the SDK to dir
+   echo  Advanced DEBUGGING ONLY OPTIONS 
+   echo   -S Save relocation scripts
+   echo   -R Do not relocate executables
+   echo   -D use set -x to see what is going on
exit 1
;;
esac
 done
 
+if [ $verbose = 1 ] ; then
+   set -x
+fi
+
 printf Enter target directory for SDK (default: $DEFAULT_INSTALL_DIR): 
 if [ $target_sdk_dir =  ]; then
read target_sdk_dir
@@ -231,10 +252,23 @@ if [ $dl_path =  ] ; then
exit 1
 fi
 executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm +111)
-$SUDO_EXEC ${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir $dl_path 
$executable_files
-if [ $? -ne 0 ]; then
-   echo SDK could not be set up. Relocate script failed. Abort!
-   exit 1
+
+tdir=`mktemp -d`
+if [ x$tdir = x ] ; then
+   echo SDK relocate failed, could not create a temporary directory
+   exit 1
+fi
+echo #!/bin/bash  $tdir/relocate_sdk.sh
+echo exec ${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir $dl_path 
$executable_files  $tdir/relocate_sdk.sh
+$SUDO_EXEC mv $tdir/relocate_sdk.sh ${env_setup_script%/*}/relocate_sdk.sh
+$SUDO_EXEC chmod 755 ${env_setup_script%/*}/relocate_sdk.sh
+rm -rf $tdir
+if [ $relocate = 1 ] ; then
+   $SUDO_EXEC ${env_setup_script%/*}/relocate_sdk.sh
+   if [ $? -ne 0 ]; then
+   echo SDK could not be set up. Relocate script failed. Abort!
+   exit 1
+   fi
 fi
 
 # replace ${SDKPATH} with the new prefix in all text files: configs/scripts/etc
@@ -249,7 +283,9 @@ echo done
 
 # delete the relocating script, so that user is forced to re-run the installer
 # if he/she wants another location for the sdk
-$SUDO_EXEC rm ${env_setup_script%/*}/relocate_sdk.py
+if [ $savescripts = 0 ] ; then
+   $SUDO_EXEC rm ${env_setup_script%/*}/relocate_sdk.py 
${env_setup_script%/*}/relocate_sdk.sh
+fi
 
 echo SDK has been successfully set up and is ready to be used.
 
-- 
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 v3 0/3] relocate_sdk.py: improvements

New in v3 are all the fixes recommended by Laurentiu Palcu
  * Fix sudo exec problem
  * Preserve padding in the .interp section

---

Now that I have had to debug the SDK relocator on multiple occasions
I figure it might be nice to get the patches upstreamed.  This last
time through fixing the python 2.4.x compatibility was very easy
using the prior two patches to allow me to do so.

The idea here is to increase the portability of the relocator because
once the SDK is installed/relocated, generally speaking it is working
well on old and new hosts.

Thanks,
Jason.

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: meta-oe appends and overlayed recipes

On Tue, 2013-02-12 at 09:24 +, Paul Eggleton wrote:
 On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
  On Mon, 2013-02-11 at 17:09 +, Paul Eggleton wrote:
   *
   meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappe
   nd This is adding qwt to the qte toolchain. As far as I am concerned this
   is a distro policy decision - Qwt is a third-party library that is not
   part of Qt. I believe this should be moved to the layers for whichever
   distros want this.
   
   * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
   * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
   These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see
   this as a distro policy decision; these should move to the layers for
   whichever distros want this. FWIW, this is particularly egregious if
   you've already built Qt, then add meta-oe and find Qt is being
   unexpectedly rebuilt.
  If these were implemented as PACKAGECONFIG options, then distros would
  just need to set the appropriate PACKAGECONFIG for the package in the
  distro config and we wouldn't even need the appends...
 
 The thing is the Qt configure options are a little more complicated - many of 
 them are three-state switches (enable built-in, enable as a plugin or 
 disabled). Thus we've opted to split the configuration options into variables 
 for each type. We don't get PACKAGECONFIG's DEPENDS handling, but if we used 
 PACKAGECONFIG we'd lose some flexibility.

Is there a way we can at least have it behave in a similar way to
PACKAGECONFIG? Can those configuration variables be set from the
distro? 

My main point is that I'd like to not need bbappend files just for
configuration.

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 1/1] busybox: add config fragments

On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
On Tue, Feb 5, 2013 at 1:42 AM, ChenQi qi.c...@windriver.com wrote:
On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold
s...@linux.intel.com wrote:
On 02/01/2013 06:18 AM, Bruce Ashfield wrote:
On Fri, Feb 1, 2013 at 4:00 AM,
qi.c...@windriver.com
mailto:qi.c...@windriver.com wrote:
mailto:qi.c...@windriver.com
Both the implementation and the use case
are similar to yocto kernel's
configuration fragments.
I can fairly easily tweak the configuration
parts of the kern-tools to
handle this
use case as well. That would allow us to
re-use the kernel's merge_config.sh
script (with a minor dependency change) and
save some duplicated code. It
also gets you the advantage that you can
consolidate configuration fragments
outside of any build system, which isn't as
critical here, but something
that
is used quite a bit during kernel testing.
Bruce,

Where is the merge_config.sh script today? Would
you propose moving it to the scripts dir and have
the busybox recipe call it?

It's part of the mainline kernel, hence why grabbing the
guts out of it reproducing
it here isn't the best idea, we'll have a need to keep them
in sync. In fact, I have
2 or 3 pending patches for it in the kern-tools repository
that I need to get upstream
(as an example).

I'd propose either creating a separate recipe for it (i.e.
like kconfig-frontends) or I could
keep it in kern-tools (badly named, but we can work on
that ;) and maintain / coordinate
changes to it.

I just don't want to see the effort happen twice, we are
busy enough!

What would be your timing on making such a change,
ie hold this patch until your get it merge or merge
this and then fix it when you merge your changes?

I could feasibly get it done in the next few weeks, the
changes aren't bug, I just
have to avoid regressions on either side (kernel or busy
box).

That being said, the interface to the SRC_URI is the same
for the two, so if we are
ok with me arriving and removing the in-recipe support, I
guess I can't object too
much :) The only risk is that if anyone starts using this
first support immediately,
I do risk regressing their use case, where if it never goes
in, that won't happen.

Cheers,
Bruce

Hi Bruce,

I just tried to reuse the kernel's merge_config.sh script, and
it turned out well.
The patch is in attachment.

Is it enough for now?

Yep, this is enough for now. It re-uses the significant part of the
infrastructure, which
is the important part. Once it is in tree, I can refine the dependency
and some other
minor modifications.

Feel free to add my Signed-off-by: to the patch as well.

This patch triggers a failure on the autobuilder:

http://autobuilder.yoctoproject.org:8010/builders/p1022ds/builds/246/steps/shell_59/logs/stdio

(its reproducible, this is the second one now)

I suspect there is a missing DEPENDS += kern-tools-native.

You'd be able to reproduce this with a:

bitbake busybox kern-tools-native; bitbake busybox kern-tools-native -c clean;
bitbake busybox

Cheers,

Richard

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: meta-oe appends and overlayed recipes

On Tuesday 12 February 2013 13:10:05 Richard Purdie wrote:
 On Tue, 2013-02-12 at 09:24 +, Paul Eggleton wrote:
  On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
   On Mon, 2013-02-11 at 17:09 +, Paul Eggleton wrote:
*
meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bba
ppe
nd This is adding qwt to the qte toolchain. As far as I am concerned
this
is a distro policy decision - Qwt is a third-party library that is not
part of Qt. I believe this should be moved to the layers for whichever
distros want this.

* meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
* meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I
see
this as a distro policy decision; these should move to the layers for
whichever distros want this. FWIW, this is particularly egregious if
you've already built Qt, then add meta-oe and find Qt is being
unexpectedly rebuilt.
   
   If these were implemented as PACKAGECONFIG options, then distros would
   just need to set the appropriate PACKAGECONFIG for the package in the
   distro config and we wouldn't even need the appends...
  
  The thing is the Qt configure options are a little more complicated - many
  of them are three-state switches (enable built-in, enable as a plugin or
  disabled). Thus we've opted to split the configuration options into
  variables for each type. We don't get PACKAGECONFIG's DEPENDS handling,
  but if we used PACKAGECONFIG we'd lose some flexibility.
 
 Is there a way we can at least have it behave in a similar way to
 PACKAGECONFIG? Can those configuration variables be set from the
 distro?

Well, the default values are set using ?= in qt4.inc, so there's nothing 
stopping them from being set from the distro config.

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 1/1] busybox: add config fragments

2013-02-12 Thread Bruce Ashfield

On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
On Tue, Feb 5, 2013 at 1:42 AM, ChenQi qi.c...@windriver.com wrote:
On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold
s...@linux.intel.com wrote:
On 02/01/2013 06:18 AM, Bruce Ashfield wrote:
On Fri, Feb 1, 2013 at 4:00 AM,
qi.c...@windriver.com
mailto:qi.c...@windriver.com wrote:
mailto:qi.c...@windriver.com
Both the implementation and the use case
are similar to yocto kernel's
configuration fragments.
I can fairly easily tweak the configuration
parts of the kern-tools to
handle this
use case as well. That would allow us to
re-use the kernel's merge_config.sh
script (with a minor dependency change) and
save some duplicated code. It
also gets you the advantage that you can
consolidate configuration fragments
outside of any build system, which isn't as
critical here, but something
that
is used quite a bit during kernel testing.
Bruce,

Where is the merge_config.sh script today? Would
you propose moving it to the scripts dir and have
the busybox recipe call it?

I'd propose either creating a separate recipe for it (i.e.
like kconfig-frontends) or I could
keep it in kern-tools (badly named, but we can work on
that ;) and maintain / coordinate
changes to it.

I just don't want to see the effort happen twice, we are
busy enough!

What would be your timing on making such a change,
ie hold this patch until your get it merge or merge
this and then fix it when you merge your changes?

I could feasibly get it done in the next few weeks, the
changes aren't bug, I just
have to avoid regressions on either side (kernel or busy
box).

Cheers,
Bruce

Hi Bruce,

I just tried to reuse the kernel's merge_config.sh script, and
it turned out well.
The patch is in attachment.

Is it enough for now?

Yep, this is enough for now. It re-uses the significant part of the
infrastructure, which
is the important part. Once it is in tree, I can refine the dependency
and some other
minor modifications.

Feel free to add my Signed-off-by: to the patch as well.

This patch triggers a failure on the autobuilder:

Hmmm. I didn't realize this had been picked up yet, I was waiting for
a repost with the Sign-offs. I assume this is master under test ? I can
pick up the patch from there and send an updated patch, since Chen Qi
won't be around to look into this for a few days.

Cheers,

Bruce

http://autobuilder.yoctoproject.org:8010/builders/p1022ds/builds/246/steps/shell_59/logs/stdio

(its reproducible, this is the second one now)

I suspect there is a missing DEPENDS += kern-tools-native.

You'd be able to reproduce this with a:

bitbake busybox kern-tools-native; bitbake busybox kern-tools-native -c
clean; bitbake busybox

Cheers,

Richard

--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tclibc-eglibc: use glibc-thread-db as eglibc-thread-db does not exist(?)

2013-02-12 Thread Marcin Juszkiewicz

| Collected errors:
|  * satisfy_dependencies_for: Cannot satisfy the following dependencies for 
packagegroup-core-standalone-hhvm-sdk-target:
|  *eglibc-thread-db *

eglibc-thread-db is listed in LIBC_DEPENDENCIES and used by SDK. Package
ends as libthread-db1 and provides glibc-thread-db.

Signed-off-by: Marcin Juszkiewicz marcin.juszkiew...@linaro.org
---
 meta/conf/distro/include/tclibc-eglibc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/tclibc-eglibc.inc 
b/meta/conf/distro/include/tclibc-eglibc.inc
index 15f5ee5..88bfd40 100644
--- a/meta/conf/distro/include/tclibc-eglibc.inc
+++ b/meta/conf/distro/include/tclibc-eglibc.inc
@@ -23,7 +23,7 @@ LIBC_DEPENDENCIES = libsegfault \
 eglibc-dbg \
 eglibc-dev \
 eglibc-utils \
-eglibc-thread-db \
+glibc-thread-db \
 ${@get_libc_locales_dependencies(d)}
 
 LIBC_LOCALE_DEPENDENCIES = \
-- 
1.8.1.2


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd: Add systemd package to PACKAGE var

2013-02-12 Thread Anders Darander

* Ross Burton ross.bur...@intel.com [130212 10:09]:

 On Tuesday, 12 February 2013 at 08:22, Khem Raj wrote:
  If someone defines SYSTEMD_PACKAGES to be different
  then ${PN} then we need to make sure that they get
  added to PACKAGES variable

 The only case it won't already be in PACKAGES is if you're creating a package 
 which contains just the service file, which as I've said before isn't 
 recommended - package the service files along with the binaries that they are 
 executing.

 Or is there another use-case I'm missing?

Well, there is always the possibillity that the install is split into
multiple packages, with binaries also in some sub-packages. I can't
recall right now if we have such packages, where the binaries in the
sub-packages should be started by init, though.

Still, I'd say that it might be a valid use case for some applications.

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd: Add systemd package to PACKAGE var

On Tuesday, 12 February 2013 at 15:01, Anders Darander wrote:
  Or is there another use-case I'm missing?
 
 Well, there is always the possibillity that the install is split into
 multiple packages, with binaries also in some sub-packages. I can't
 recall right now if we have such packages, where the binaries in the
 sub-packages should be started by init, though.

And those sub-packages are obviously already in PACKAGES, so this isn't 
required again.  I'm just trying to keep the amount of magic in the class to a 
minimum unless it's required.

Ross 



___
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] busybox: add config fragments

On Tue, 2013-02-12 at 09:06 -0500, Bruce Ashfield wrote:
 On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
  On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
  On Tue, Feb 5, 2013 at 1:42 AM, ChenQi qi.c...@windriver.com wrote:
  On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
   On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold
   s...@linux.intel.com wrote:
   On 02/01/2013 06:18 AM, Bruce Ashfield wrote:
   On Fri, Feb 1, 2013 at 4:00 AM,
   qi.c...@windriver.com
   mailto:qi.c...@windriver.com wrote:
   mailto:qi.c...@windriver.com
   Both the implementation and the use case
   are similar to yocto kernel's
   configuration fragments.
   I can fairly easily tweak the configuration
   parts of the kern-tools to
   handle this
   use case as well. That would allow us to
   re-use the kernel's merge_config.sh
   script (with a minor dependency change) and
   save some duplicated code. It
   also gets you the advantage that you can
   consolidate configuration fragments
   outside of any build system, which isn't as
   critical here, but something
   that
   is used quite a bit during kernel testing.
   Bruce,
  
   Where is the merge_config.sh script today?  Would
   you propose moving it to the scripts dir and have
   the busybox recipe call it?
  
  
   It's part of the mainline kernel, hence why grabbing the
   guts out of it reproducing
   it here isn't the best idea, we'll have a need to keep them
   in sync. In fact, I have
   2 or 3 pending patches for it in the kern-tools repository
   that I need to get upstream
   (as an example).
  
  
   I'd propose either creating a separate recipe for it (i.e.
   like kconfig-frontends) or I could
   keep it in kern-tools (badly named, but we can work on
   that ;) and maintain / coordinate
   changes to it.
  
  
   I just don't want to see the effort happen twice, we are
   busy enough!
  
  
   What would be your timing on making such a change,
   ie hold this patch until your get it merge or merge
   this and then fix it when you merge your changes?
 
   I could feasibly get it done in the next few weeks, the
   changes aren't bug, I just
   have to avoid regressions on either side (kernel or busy
   box).
 
   That being said, the interface to the SRC_URI is the same
   for the two, so if we are
   ok with me arriving and removing the in-recipe support, I
   guess I can't object too
   much :) The only risk is that if anyone starts using this
   first support immediately,
   I do risk regressing their use case, where if it never goes
   in, that won't happen.
 
   Cheers,
   Bruce
 
  Hi Bruce,
 
  I just tried to reuse the kernel's merge_config.sh script, and
  it turned out well.
  The patch is in attachment.
 
  Is it enough for now?
 
  Yep, this is enough for now. It re-uses the significant part of the
  infrastructure, which
  is the important part. Once it is in tree, I can refine the dependency
  and some other
  minor modifications.
 
  Feel free to add my Signed-off-by: to the patch as well.
 
  This patch triggers a failure on the autobuilder:
 
 Hmmm. I didn't realize this had been picked up yet, I was waiting for
 a repost with the Sign-offs. I assume this is master under test ? I can
 pick up the patch from there and send an updated patch, since Chen Qi
 won't be around to look into this for a few days.

It was master under test, it won't make master until it works :)

I don't mind who sends me the working version.

Cheers,

Richard




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
  * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
  Another bbappend apparently for systemd support. Again, this should have 
  been
  moved to meta-systemd; do we now need to merge it into OE-Core?
 
 
 Yes, half of it has been merged to master already. The rest should be
 in Radu's branch, we can sort that today.

I take that back - polkit in oe-core supports systemd if enabled, so this 
append can be removed. 

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 02/11] image.bbclass: add fall-back functionality when running intercepts

If an intercept script fails, it would be helpful to fall-back to
running the postinstall on target's first boot. In order to achieve
that, the postinstalls that install a host intercept hook will have to
return 1, so that the postinstall is marked as unpacked only. If the
intercept hook fails, then we're ok, the postinstalls will be run on
target anyway. If it succeeds, then mark the packages as installed.

This logic was chosen mainly because of rpm backend which saves the
failed postinstalls in /etc/rpm-postinsts. Hence, in order to mark the
packages as installed, all we have to do is delete the scriptlets from
there.

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/classes/image.bbclass |   43 +--
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 84ddc38..dd78acb 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -194,13 +194,41 @@ run_intercept_scriptlets () {
cd ${WORKDIR}/intercept_scripts
echo Running intercept scripts:
for script in *; do
-   if [ $script = * ]; then break; fi
+   [ $script = * ]  break
+   [ $script = postinst_intercept ] || [ ! -x 
$script ]  continue
echo  Executing $script
-   chmod +x $script
-   ./$script
-   if [ $? -ne 0 ]; then
-   echo ERROR: intercept script \$script\ 
failed!
-   fi
+   ./$script || (echo WARNING: intercept script 
\$script\ failed, falling back to running postinstalls at first boot  
continue)
+   #
+   # If we got here, than the intercept was successful. 
Next, we must
+   # mark the postinstalls as installed. For rpm is a 
little bit
+   # different, we just have to delete the saved 
postinstalls from
+   # /etc/rpm-postinsts
+   #
+   pkgs=$(cat ./$script|grep ^##PKGS|cut -d':' -f2) || 
continue
+   case ${IMAGE_PKGTYPE} in
+   rpm)
+   for pi in 
${IMAGE_ROOTFS}${sysconfdir}/rpm-postinsts/*; do
+   pkg_name=$(cat $pi|sed -n -e 
s/^.*postinst_intercept $script \([^ ]*\).*/\1/p)
+   if [ -n $pkg_name -a -n 
$(echo $pkgs|grep  $pkg_name ) ]; then
+   rm $pi
+   fi
+   done
+   # move to the next intercept script
+   continue
+   ;;
+   ipk)
+   
status_file=${IMAGE_ROOTFS}${OPKGLIBDIR}/opkg/status
+   ;;
+   deb)
+   
status_file=${IMAGE_ROOTFS}/var/lib/dpkg/status
+   ;;
+   esac
+   # the next piece of code is run only for ipk/dpkg
+   sed_expr=
+   for p in $pkgs; do
+   sed_expr=$sed_expr -e \/^Package: 
${p}$/,/^Status: install.* unpacked$/ {s/unpacked/installed/}\
+   done
+   eval sed -i $sed_expr $status_file
done
fi
 }
@@ -223,6 +251,9 @@ fakeroot do_rootfs () {
 
cp ${COREBASE}/meta/files/deploydir_readme.txt 
${DEPLOY_DIR_IMAGE}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt || true
 
+   # copy the intercept scripts
+   cp ${COREBASE}/scripts/postinst-intercepts/* 
${WORKDIR}/intercept_scripts/
+
# If ${IMAGE_ROOTFS}/dev exists, then the device had been made by
# the previous build
if [ ${USE_DEVFS} != 1 -a ! -r ${IMAGE_ROOTFS}/dev ]; then
-- 
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 00/11] Postinstall intercept fall-back solution + leftover patches with postinstall fixes

Hi all,

This patchset adds the fall-back solution to intercept hooks. That is, if
intercept hooks fail than the postinstalls will run on target, at first boot.
This way we will avoid unwanted situations when the intercept hooks fail and
the build cannot complete. The previous solution had some issue with adding the
final package names to the intercept hook. So, after having a discussion with
Richard, we agreed to use a separate directory in scripts/ where we can put
all the intercept hooks. This solution also avoids adding extra, unnecesary
code (from the target point of view), to the postinstall scriptlets.

Besides this, there are other postinstall fixes from a previous patchset that I
adviced not to be merged so I can resend them with the latest changes in place.

Thanks,
Laurentiu

The following changes since commit 02d2a5e68cab490cb83db6e4f2f0802221efe8a2:

  distro_check: Remove creation of empty Meego filelist. (2013-02-12 13:22:44 
+)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib lpalcu/intercept
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/intercept

Laurentiu Palcu (11):
  Add separate directory for postinstall intercepts
  image.bbclass: add fall-back functionality when running intercepts
  rootfs_(ipk|deb|rpm).bbclass: check package installation status after
ROOTFS_POSTPROCESS_COMMAND
  gtk-icon-cache.bbclass: use postinst_intercept script
  fontcache.bbclass: use the postinst_intercept script
  Add pixbufcache class
  gdk-pixbuf: use the new pixbufcache class
  librsvg: use the new pixbufcache class
  gnome-keyring: compile schemas on host
  gtk-immodules-cache: add weak asignment for GTKIMMODULES_PACKAGES
  gtk+: use gtk-immodules-cache class

 meta/classes/fontcache.bbclass |   20 +++-
 meta/classes/gtk-icon-cache.bbclass|   39 ---
 meta/classes/gtk-immodules-cache.bbclass   |2 +
 meta/classes/image.bbclass |   43 ++---
 meta/classes/pixbufcache.bbclass   |   50 
 meta/classes/rootfs_deb.bbclass|   14 +++---
 meta/classes/rootfs_ipk.bbclass|   13 +++--
 meta/classes/rootfs_rpm.bbclass|   20 
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb |   48 ++-
 meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb   |   12 +
 meta/recipes-gnome/gtk+/gtk+.inc   |8 +---
 meta/recipes-gnome/gtk+/gtk+3_3.4.4.bb |   12 +
 meta/recipes-gnome/gtk+/gtk+_2.24.14.bb|4 +-
 meta/recipes-gnome/librsvg/librsvg_2.32.1.bb   |   21 ++--
 scripts/postinst-intercepts/postinst_intercept |   37 +++
 scripts/postinst-intercepts/update_font_cache  |7 +++
 scripts/postinst-intercepts/update_icon_cache  |   12 +
 scripts/postinst-intercepts/update_pixbuf_cache|   10 
 18 files changed, 207 insertions(+), 165 deletions(-)
 create mode 100644 meta/classes/pixbufcache.bbclass
 create mode 100755 scripts/postinst-intercepts/postinst_intercept
 create mode 100644 scripts/postinst-intercepts/update_font_cache
 create mode 100644 scripts/postinst-intercepts/update_icon_cache
 create mode 100644 scripts/postinst-intercepts/update_pixbuf_cache

-- 
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 04/11] gtk-icon-cache.bbclass: use postinst_intercept script

Since the hook has been made a standalone script, use postinst_intercept
script in order to link the package to the hook.

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/classes/gtk-icon-cache.bbclass |   39 ---
 1 file changed, 9 insertions(+), 30 deletions(-)

diff --git a/meta/classes/gtk-icon-cache.bbclass 
b/meta/classes/gtk-icon-cache.bbclass
index cf33efd..2ca99ac 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -2,23 +2,15 @@ FILES_${PN} += ${datadir}/icons/hicolor
 
 DEPENDS += ${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} 
gtk+-native
 
+#
+# On host, the postinstall MUST return 1 because we do not know if the 
intercept
+# hook will succeed. If it does succeed, than the packages will be marked as
+# installed.
+#
 gtk_icon_cache_postinst() {
 if [ x$D != x ]; then
-if [ ! -f $INTERCEPT_DIR/update_icon_cache ]; then
-cat  EOF  $INTERCEPT_DIR/update_icon_cache
-#!/bin/sh
-
-# update native pixbuf loaders
-gdk-pixbuf-query-loaders --update-cache
-
-for icondir in $D/usr/share/icons/*/ ; do
-if [ -d $icondir ] ; then
-gtk-update-icon-cache -fqt  $icondir
-fi
-done
-EOF
-fi
-exit 0
+$INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG}
+exit 1
 fi
 
 # Update the pixbuf loaders in case they haven't been registered yet
@@ -33,21 +25,8 @@ done
 
 gtk_icon_cache_postrm() {
 if [ x$D != x ]; then
-if [ ! -f $INTERCEPT_DIR/update_icon_cache ]; then
-cat  EOF  $INTERCEPT_DIR/update_icon_cache
-#!/bin/sh
-
-# update native pixbuf loaders
-gdk-pixbuf-query-loaders --update-cache
-
-for icondir in $D/usr/share/icons/*/ ; do
-if [ -d $icondir ] ; then
-gtk-update-icon-cache -fqt  $icondir
-fi
-done
-EOF
-fi
-exit 0
+$INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG}
+exit 1
 fi
 
 for icondir in /usr/share/icons/* ; do
-- 
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 05/11] fontcache.bbclass: use the postinst_intercept script

Link the package to the postinstall hook by running the
postinst_intercept script.

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/classes/fontcache.bbclass |   20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/meta/classes/fontcache.bbclass b/meta/classes/fontcache.bbclass
index 8381735..d3c1562 100644
--- a/meta/classes/fontcache.bbclass
+++ b/meta/classes/fontcache.bbclass
@@ -8,21 +8,15 @@ inherit qemu
 
 FONT_PACKAGES ??= ${PN}
 
+#
+# On host, the postinstall MUST return 1 because we do not know if the 
intercept
+# hook will succeed. If it does succeed, than the packages will be marked as
+# installed.
+#
 fontcache_common() {
 if [ x$D != x ] ; then
-   if [ ! -f $INTERCEPT_DIR/update_font_cache ]; then
-   cat  EOF  $INTERCEPT_DIR/update_font_cache
-#!/bin/sh
-
-${@qemu_run_binary(d, '$D', '/usr/bin/fc-cache')} --sysroot=$D /dev/null 21
-
-if [ $? -ne 0 ]; then
-exit 1
-fi
-
-EOF
-   fi
-   exit 0
+   $INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} 
bindir=${bindir}
+   exit 1
 fi
 
 fc-cache
-- 
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 03/11] rootfs_(ipk|deb|rpm).bbclass: check package installation status after ROOTFS_POSTPROCESS_COMMAND

Since the intercept fall-back procedure will change the package
installation status, do the checking after ROOTFS_POSTPROCESS_COMMAND
ends.

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/classes/rootfs_deb.bbclass |   14 +++---
 meta/classes/rootfs_ipk.bbclass |   13 ++---
 meta/classes/rootfs_rpm.bbclass |   20 ++--
 3 files changed, 23 insertions(+), 24 deletions(-)

diff --git a/meta/classes/rootfs_deb.bbclass b/meta/classes/rootfs_deb.bbclass
index 9997996..92a6579 100644
--- a/meta/classes/rootfs_deb.bbclass
+++ b/meta/classes/rootfs_deb.bbclass
@@ -70,13 +70,6 @@ fakeroot rootfs_deb_do_rootfs () {
 
set -e
 
-   if ${@base_contains(IMAGE_FEATURES, read-only-rootfs, true, 
false ,d)}; then
-   if grep Status:.install.ok.unpacked 
${IMAGE_ROOTFS}/var/lib/dpkg/status; then
-   bberror Some packages could not be configured offline 
and rootfs is read-only.
-   exit 1
-   fi
-   fi
-
install -d ${IMAGE_ROOTFS}/${sysconfdir}
echo ${BUILDNAME}  ${IMAGE_ROOTFS}/${sysconfdir}/version
 
@@ -91,6 +84,13 @@ fakeroot rootfs_deb_do_rootfs () {
 
${ROOTFS_POSTPROCESS_COMMAND}
 
+   if ${@base_contains(IMAGE_FEATURES, read-only-rootfs, true, 
false ,d)}; then
+   if grep Status:.install.ok.unpacked 
${IMAGE_ROOTFS}/var/lib/dpkg/status; then
+   bberror Some packages could not be configured offline 
and rootfs is read-only.
+   exit 1
+   fi
+   fi
+
log_check rootfs
 }
 
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index fadec4d..135bb60 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -80,7 +80,12 @@ fakeroot rootfs_ipk_do_rootfs () {
 
${OPKG_POSTPROCESS_COMMANDS}
${ROOTFS_POSTINSTALL_COMMAND}
-   
+
+   install -d ${IMAGE_ROOTFS}/${sysconfdir}
+   echo ${BUILDNAME}  ${IMAGE_ROOTFS}/${sysconfdir}/version
+
+   ${ROOTFS_POSTPROCESS_COMMAND}
+
if ${@base_contains(IMAGE_FEATURES, read-only-rootfs, true, 
false ,d)}; then
if grep Status:.install.ok.unpacked ${STATUS}; then
bberror Some packages could not be configured offline 
and rootfs is read-only.
@@ -88,11 +93,6 @@ fakeroot rootfs_ipk_do_rootfs () {
fi
fi
 
-   install -d ${IMAGE_ROOTFS}/${sysconfdir}
-   echo ${BUILDNAME}  ${IMAGE_ROOTFS}/${sysconfdir}/version
-
-   ${ROOTFS_POSTPROCESS_COMMAND}
-   
rm -f ${IMAGE_ROOTFS}${OPKGLIBDIR}/opkg/lists/*
if ${@base_contains(IMAGE_FEATURES, package-management, false, 
true, d)}; then
if ! grep Status:.install.ok.unpacked ${STATUS}; then
@@ -114,7 +114,6 @@ fakeroot rootfs_ipk_do_rootfs () {
remove_packaging_data_files
fi
fi
-   set +x
log_check rootfs
 }
 
diff --git a/meta/classes/rootfs_rpm.bbclass b/meta/classes/rootfs_rpm.bbclass
index 119bf92..5651243 100644
--- a/meta/classes/rootfs_rpm.bbclass
+++ b/meta/classes/rootfs_rpm.bbclass
@@ -87,15 +87,6 @@ fakeroot rootfs_rpm_do_rootfs () {
 
${ROOTFS_POSTINSTALL_COMMAND}
 
-   if ${@base_contains(IMAGE_FEATURES, read-only-rootfs, true, 
false ,d)}; then
-   if [ -d ${IMAGE_ROOTFS}/etc/rpm-postinsts ] ; then
-   if [ `ls -A ${IMAGE_ROOTFS}/etc/rpm-postinsts` !=  
] ; then
-   bberror Some packages could not be configured 
offline and rootfs is read-only.
-   exit 1
-   fi
-   fi
-   fi
-
# Report delayed package scriptlets
for i in ${IMAGE_ROOTFS}/etc/rpm-postinsts/*; do
if [ -f $i ]; then
@@ -126,7 +117,16 @@ EOF
 
${RPM_POSTPROCESS_COMMANDS}
${ROOTFS_POSTPROCESS_COMMAND}
-   
+
+   if ${@base_contains(IMAGE_FEATURES, read-only-rootfs, true, 
false ,d)}; then
+   if [ -d ${IMAGE_ROOTFS}/etc/rpm-postinsts ] ; then
+   if [ `ls -A ${IMAGE_ROOTFS}/etc/rpm-postinsts` !=  
] ; then
+   bberror Some packages could not be configured 
offline and rootfs is read-only.
+   exit 1
+   fi
+   fi
+   fi
+
rm -rf ${IMAGE_ROOTFS}/var/cache2/
rm -rf ${IMAGE_ROOTFS}/var/run2/
rm -rf ${IMAGE_ROOTFS}/var/log2/
-- 
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 06/11] Add pixbufcache class

All packages exporting pixbuf loaders should inherit this class in order
to generate the correct postinst/postrm scriptlets.

[YOCTO #3852]

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/classes/pixbufcache.bbclass |   50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 meta/classes/pixbufcache.bbclass

diff --git a/meta/classes/pixbufcache.bbclass b/meta/classes/pixbufcache.bbclass
new file mode 100644
index 000..fc749de
--- /dev/null
+++ b/meta/classes/pixbufcache.bbclass
@@ -0,0 +1,50 @@
+#
+# This class will generate the proper postinst/postrm scriptlets for pixbuf
+# packages.
+#
+
+DEPENDS += qemu-native
+inherit qemu
+
+PIXBUF_PACKAGES ??= ${PN}
+
+#
+# On host, the postinstall MUST return 1 because we do not know if the 
intercept
+# hook will succeed. If it does succeed, than the packages will be marked as
+# installed.
+#
+pixbufcache_common() {
+if [ x$D != x ]; then
+   $INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} 
libdir=${libdir} bindir=${bindir}
+   exit 1
+fi
+
+# Update the pixbuf loaders in case they haven't been registered yet
+GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders 
gdk-pixbuf-query-loaders --update-cache
+
+if [ -x ${bindir}/gtk-update-icon-cache ]  [ -d ${datadir}/icons ]; then
+for icondir in /usr/share/icons/*; do
+if [ -d ${icondir} ]; then
+gtk-update-icon-cache -t -q ${icondir}
+fi
+done
+fi
+}
+
+python populate_packages_append() {
+pixbuf_pkgs = d.getVar('PIXBUF_PACKAGES', True).split()
+
+for pkg in pixbuf_pkgs:
+bb.note(adding pixbuf postinst and postrm scripts to %s % pkg)
+postinst = d.getVar('pkg_postinst_%s' % pkg, True) or 
d.getVar('pkg_postinst', True)
+if not postinst:
+postinst = '#!/bin/sh\n'
+postinst += d.getVar('pixbufcache_common', True)
+d.setVar('pkg_postinst_%s' % pkg, postinst)
+
+postrm = d.getVar('pkg_postrm_%s' % pkg, True) or 
d.getVar('pkg_postrm', True)
+if not postrm:
+postrm = '#!/bin/sh\n'
+postrm += d.getVar('pixbufcache_common', True)
+d.setVar('pkg_postrm_%s' % pkg, postrm)
+}
-- 
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 09/11] gnome-keyring: compile schemas on host

gsettings.bbclass offers just that.

[YOCTO #3854]

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb |   12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb 
b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
index 92e0e1b..a1cd8f9 100644
--- a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
+++ b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
@@ -11,9 +11,9 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
 SECTION = x11/gnome
 
-PR = r10
+PR = r11
 
-inherit autotools gnome gtk-doc pkgconfig
+inherit autotools gnome gtk-doc pkgconfig gsettings
 
 DEPENDS = gtk+ libgcrypt libtasn1 libtasn1-native gconf 
${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}
 RDEPENDS_${PN} = libgnome-keyring glib-2.0-utils
@@ -30,14 +30,6 @@ do_install_append () {
install -m 0644 ${WORKDIR}/org.gnome.keyring.service 
${D}${datadir}/dbus-1/services
 }
 
-pkg_postinst_${PN} () {
-   if [ x$D != x ]; then
-   exit 1
-   fi
-
-   test -x ${bindir}/glib-compile-schemas  glib-compile-schemas  
${datadir}/glib-2.0/schemas
-}
-
 FILES_${PN} += ${datadir}/dbus-1/services ${datadir}/gcr
 
 
-- 
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 07/11] gdk-pixbuf: use the new pixbufcache class

[YOCTO #3582]

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb |   48 ++--
 1 file changed, 3 insertions(+), 45 deletions(-)

diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
index 64f1450..cc2ea50 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
@@ -20,9 +20,9 @@ SRC_URI = 
http://ftp.acc.umu.se/pub/GNOME/sources/gdk-pixbuf/2.26/gdk-pixbuf-${
 SRC_URI[md5sum] = 339329e6d619ee3e1cb93979111b04c0
 SRC_URI[sha256sum] = 
77696fd163bca95a130a1883dbd78d0ae4d782de2fc85a9a38556d13681f5c84
 
-PR = r0
+PR = r1
 
-inherit autotools pkgconfig gettext
+inherit autotools pkgconfig gettext pixbufcache
 
 LIBV = 2.10.0
 
@@ -56,48 +56,6 @@ FILES_${PN}-dbg +=  \
${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders/.debug/* \
 
 
-postinst_pixbufloader () {
-if [ x$D != x ]; then
-# Update the target's pixbuf loader's cache. Since the native binary will
-# throw an error if the shared objects do not belong to the same ELF class,
-# we trick the gdk-pixbuf-query-loaders into scanning the native shared
-# objects and then we remove the NATIVE_ROOT prefix from the paths in
-# loaders.cache.
-gdk-pixbuf-query-loaders $(ls -d -1 
$D/${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders/*.so |\
-sed -e s:$D:$NATIVE_ROOT:g)  \
-$D/${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders.cache \
-2$D/${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders.err
-
-# gdk-pixbuf-query-loaders always returns 0, so we need to check if loaders.err
-# has anything in it
-if [ -s $D/${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders.err ]; then
-   echo ${PN} postinstall scriptlet failed:
-   cat $D/${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders.err
-   rm $D/${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders.err
-   # we've got errors, postpone postinstall for first boot
-   exit 1
-fi
-
-sed -i -e s:$NATIVE_ROOT:/:g 
$D/${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders.cache
-
-# remove the empty loaders.err
-rm $D/${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders.err
-
-exit 0
-fi
-
-# Update the pixbuf loaders in case they haven't been registered yet
-GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders 
gdk-pixbuf-query-loaders --update-cache
-
-if [ -x ${bindir}/gtk-update-icon-cache ]  [ -d ${datadir}/icons ]; then
-for icondir in /usr/share/icons/*; do
-if [ -d ${icondir} ]; then
-gtk-update-icon-cache -t -q ${icondir}
-fi
-done
-fi
-}
-
 PACKAGES_DYNAMIC += ^gdk-pixbuf-loader-.*
 PACKAGES_DYNAMIC_class-native = 
 
@@ -106,7 +64,7 @@ python populate_packages_prepend () {
 
 loaders_root = d.expand('${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders')
 
-do_split_packages(d, loaders_root, '^libpixbufloader-(.*)\.so$', 
'gdk-pixbuf-loader-%s', 'GDK pixbuf loader for %s', postinst_pixbufloader)
+d.setVar('PIXBUF_PACKAGES', ' '.join(do_split_packages(d, loaders_root, 
'^libpixbufloader-(.*)\.so$', 'gdk-pixbuf-loader-%s', 'GDK pixbuf loader for 
%s')))
 }
 
 do_install_append_class-native() {
-- 
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 11/11] gtk+: use gtk-immodules-cache class

In order to have the proper postinst/postrm scriptlets generated for
gtk+ immodules packages, use the already existing class.

[YOCTO #3853]

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+.inc|8 +---
 meta/recipes-gnome/gtk+/gtk+3_3.4.4.bb  |   12 ++--
 meta/recipes-gnome/gtk+/gtk+_2.24.14.bb |4 +---
 3 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
index d8adc11..8c2b977 100644
--- a/meta/recipes-gnome/gtk+/gtk+.inc
+++ b/meta/recipes-gnome/gtk+/gtk+.inc
@@ -18,7 +18,7 @@ PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'x11', 
'x11', '', d)}
 
 PACKAGECONFIG[x11] = --with-x=yes 
--with-gdktarget=x11,--with-x=no,${X11DEPENDS}
 
-inherit autotools gtk-doc pkgconfig update-alternatives
+inherit autotools gtk-doc pkgconfig update-alternatives gtk-immodules-cache
 
 PACKAGES += libgail gtk-demo
 
@@ -94,9 +94,3 @@ gtk_sysroot_preprocess () {
fi
 }
 
-postinst_prologue() {
-if [ x$D != x ]; then
-  exit 1
-fi
-
-}
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.4.4.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.4.4.bb
index e624387..e2a7ef7 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.4.4.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.4.4.bb
@@ -21,7 +21,7 @@ SRC_URI = 
http://download.gnome.org/sources/gtk+/3.4/gtk+-${PV}.tar.xz \
 SRC_URI[md5sum] = 1b2cf29502a6394e8d4b30f7f5bb9131
 SRC_URI[sha256sum] = 
f154e460075034da4c0ce89c320025dcd459da2a1fdf32d92a09522eaca242c7
 
-inherit autotools pkgconfig gtk-doc update-alternatives
+inherit autotools pkgconfig gtk-doc update-alternatives gtk-immodules-cache
 
 S = ${WORKDIR}/gtk+-${PV}
 
@@ -90,22 +90,14 @@ ALTERNATIVE_TARGET[gtk-update-icon-cache] = 
${bindir}/gtk-update-icon-cache-3.0
 python populate_packages_prepend () {
 import os.path
 
-prologue = d.getVar(postinst_prologue, 1)
-
 gtk_libdir = d.expand('${libdir}/gtk-3.0/${LIBV}')
 immodules_root = os.path.join(gtk_libdir, 'immodules')
 printmodules_root = os.path.join(gtk_libdir, 'printbackends');
 
-do_split_packages(d, immodules_root, '^im-(.*)\.so$', 'gtk3-immodule-%s', 
'GTK input module for %s', prologue + 'gtk-query-immodules-3.0  
/etc/gtk-3.0/gtk.immodules')
+d.setVar('GTKIMMODULES_PACKAGES', ' '.join(do_split_packages(d, 
immodules_root, '^im-(.*)\.so$', 'gtk3-immodule-%s', 'GTK input module for 
%s')))
 do_split_packages(d, printmodules_root, '^libprintbackend-(.*)\.so$', 
'gtk3-printbackend-%s', 'GTK printbackend module for %s')
 
 if (d.getVar('DEBIAN_NAMES', 1)):
 d.setVar('PKG_${PN}', 'libgtk-3.0')
 }
 
-postinst_prologue() {
-if [ x$D != x ]; then
-  exit 1
-fi
-
-}
diff --git a/meta/recipes-gnome/gtk+/gtk+_2.24.14.bb 
b/meta/recipes-gnome/gtk+/gtk+_2.24.14.bb
index fab360d..1520720 100644
--- a/meta/recipes-gnome/gtk+/gtk+_2.24.14.bb
+++ b/meta/recipes-gnome/gtk+/gtk+_2.24.14.bb
@@ -49,13 +49,11 @@ do_install_append_class-native () {
 }
 
 python populate_packages_prepend () {
-prologue = d.getVar(postinst_prologue, True)
-
 gtk_libdir = d.expand('${libdir}/gtk-2.0/${LIBV}')
 immodules_root = os.path.join(gtk_libdir, 'immodules')
 printmodules_root = os.path.join(gtk_libdir, 'printbackends');
 
-do_split_packages(d, immodules_root, '^im-(.*)\.so$', 'gtk-immodule-%s', 
'GTK input module for %s', prologue + 'gtk-query-immodules-2.0  
/etc/gtk-2.0/gtk.immodules')
+d.setVar('GTKIMMODULES_PACKAGES', ' '.join(do_split_packages(d, 
immodules_root, '^im-(.*)\.so$', 'gtk-immodule-%s', 'GTK input module for %s')))
 do_split_packages(d, printmodules_root, '^libprintbackend-(.*)\.so$', 
'gtk-printbackend-%s', 'GTK printbackend module for %s')
 
 if (d.getVar('DEBIAN_NAMES', True)):
-- 
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 10/11] gtk-immodules-cache: add weak asignment for GTKIMMODULES_PACKAGES

This is needed if the GTKIMMODULES_PACKAGES is changed later, in
do_populate_packages for example. This way, we don't have to add another
dumb asignment in the recipe inheriting this.

[YOCTO #3853]

Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
 meta/classes/gtk-immodules-cache.bbclass |2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/gtk-immodules-cache.bbclass 
b/meta/classes/gtk-immodules-cache.bbclass
index a8855af..6a5bc19 100644
--- a/meta/classes/gtk-immodules-cache.bbclass
+++ b/meta/classes/gtk-immodules-cache.bbclass
@@ -6,6 +6,8 @@ DEPENDS =+ qemu-native
 
 inherit qemu
 
+GTKIMMODULES_PACKAGES ?= ${PN}
+
 gtk_immodule_cache_postinst() {
 if [ x$D != x ]; then
 for maj_ver in 2 3; do
-- 
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] tclibc-eglibc: use glibc-thread-db as eglibc-thread-db does not exist(?)

On Tue, 2013-02-12 at 15:25 +0100, Marcin Juszkiewicz wrote:
 | Collected errors:
 |  * satisfy_dependencies_for: Cannot satisfy the following dependencies for 
 packagegroup-core-standalone-hhvm-sdk-target:
 |  *eglibc-thread-db *
 
 eglibc-thread-db is listed in LIBC_DEPENDENCIES and used by SDK. Package
 ends as libthread-db1 and provides glibc-thread-db.
 
 Signed-off-by: Marcin Juszkiewicz marcin.juszkiew...@linaro.org
 ---
  meta/conf/distro/include/tclibc-eglibc.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Package renaming should take care of this. If it doesn't happen, that is
a bug in the package renaming. This just hacks around it.

How do we reproduce this?

Cheers,

Richard

 diff --git a/meta/conf/distro/include/tclibc-eglibc.inc 
 b/meta/conf/distro/include/tclibc-eglibc.inc
 index 15f5ee5..88bfd40 100644
 --- a/meta/conf/distro/include/tclibc-eglibc.inc
 +++ b/meta/conf/distro/include/tclibc-eglibc.inc
 @@ -23,7 +23,7 @@ LIBC_DEPENDENCIES = libsegfault \
eglibc-dbg \
eglibc-dev \
eglibc-utils \
 -  eglibc-thread-db \
 +  glibc-thread-db \
${@get_libc_locales_dependencies(d)}
  
  LIBC_LOCALE_DEPENDENCIES = \



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Otavio Salvador

On Tue, Feb 12, 2013 at 8:38 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Tuesday 12 February 2013 10:24:50 Burton, Ross wrote:
* tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
that is ahead of 1.0; the OE-Core version has two patches not in the
meta-oe version but that both have been merged upstream in the git
revision being used in the meta-oe version. There is no newer stable
release. What do we do here? Should we ask upstream (Chris) for a new
stable release?

Yes Qt Embedded uses it; not sure evdev is an alternative here.

* xserver-nodm-init: the two versions are quite distinct. Not sure I
understand the full history here but perhaps someone else can fill in the
blanks...?

I don't understand the full history either yet, but this is clearly
something that needs to be sorted.

The following commit introduced this:

http://cgit.openembedded.org/meta-openembedded/commit/?id=c48a6a605c6d8d38cfbc5df39b3dc310bffc07c1

Otavio can you explain further?

This was to make the service to use the /etc/default/busybox-syslog to
configure syslog. Today with the availability of journald I not sure
it still has an use. It might be dropped I think.

* meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
Another bbappend apparently for systemd support. Again, this should have
been moved to meta-systemd; do we now need to merge it into OE-Core?

Yes, half of it has been merged to master already. The rest should be
in Radu's branch, we can sort that today.

OK, great.

libav/gst-ffmpeg/gst-av (as it's called in gst1.0) has interesting
legal issues, but I do think it should be in oe-core.

Well, we already have gst-ffmpeg in OE-Core so I can't imagine libav
would be any worse as long as it is similarly protected with
LICENSE_FLAGS.

Cheers,
Paul

Paul Eggleton
Intel Open Source Technology Centre

--
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] [oe] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Otavio Salvador

On Tue, Feb 12, 2013 at 1:50 PM, Ross Burton ross.bur...@intel.com wrote:
 On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
  * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
  Another bbappend apparently for systemd support. Again, this should have 
  been
  moved to meta-systemd; do we now need to merge it into OE-Core?


 Yes, half of it has been merged to master already. The rest should be
 in Radu's branch, we can sort that today.

 I take that back - polkit in oe-core supports systemd if enabled, so this 
 append can be removed.

In fact we cannot drop the bbappend or we break the upgrade path
(except if we bump PR in OE-Core to keep it).

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd: Add systemd package to PACKAGE var

2013-02-12 Thread Anders Darander

* Ross Burton ross.bur...@intel.com [130212 16:07]:

 On Tuesday, 12 February 2013 at 15:01, Anders Darander wrote:
   Or is there another use-case I'm missing?

  Well, there is always the possibillity that the install is split into
  multiple packages, with binaries also in some sub-packages. I can't
  recall right now if we have such packages, where the binaries in the
  sub-packages should be started by init, though.

 And those sub-packages are obviously already in PACKAGES, so this
 isn't required again.  I'm just trying to keep the amount of magic in
 the class to a minimum unless it's required.

Ah, of course they are...

I completely mis-read the patch... As the patch only was concerned with
adding packages to PACKAGES, I completely agree with you. Lets get rid
of that extra magic.

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

___
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] busybox: add config fragments

2013-02-12 Thread Bruce Ashfield

On Tue, Feb 12, 2013 at 10:32 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Tue, 2013-02-12 at 09:06 -0500, Bruce Ashfield wrote:
 On Tue, Feb 12, 2013 at 8:21 AM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
  On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
  On Tue, Feb 5, 2013 at 1:42 AM, ChenQi qi.c...@windriver.com wrote:
  On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
   On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold
   s...@linux.intel.com wrote:
   On 02/01/2013 06:18 AM, Bruce Ashfield wrote:
   On Fri, Feb 1, 2013 at 4:00 AM,
   qi.c...@windriver.com
   mailto:qi.c...@windriver.com wrote:
   mailto:qi.c...@windriver.com
   Both the implementation and the use case
   are similar to yocto kernel's
   configuration fragments.
   I can fairly easily tweak the configuration
   parts of the kern-tools to
   handle this
   use case as well. That would allow us to
   re-use the kernel's merge_config.sh
   script (with a minor dependency change) and
   save some duplicated code. It
   also gets you the advantage that you can
   consolidate configuration fragments
   outside of any build system, which isn't as
   critical here, but something
   that
   is used quite a bit during kernel testing.
   Bruce,
  
   Where is the merge_config.sh script today?  Would
   you propose moving it to the scripts dir and have
   the busybox recipe call it?
  
  
   It's part of the mainline kernel, hence why grabbing the
   guts out of it reproducing
   it here isn't the best idea, we'll have a need to keep them
   in sync. In fact, I have
   2 or 3 pending patches for it in the kern-tools repository
   that I need to get upstream
   (as an example).
  
  
   I'd propose either creating a separate recipe for it (i.e.
   like kconfig-frontends) or I could
   keep it in kern-tools (badly named, but we can work on
   that ;) and maintain / coordinate
   changes to it.
  
  
   I just don't want to see the effort happen twice, we are
   busy enough!
  
  
   What would be your timing on making such a change,
   ie hold this patch until your get it merge or merge
   this and then fix it when you merge your changes?
 
   I could feasibly get it done in the next few weeks, the
   changes aren't bug, I just
   have to avoid regressions on either side (kernel or busy
   box).
 
   That being said, the interface to the SRC_URI is the same
   for the two, so if we are
   ok with me arriving and removing the in-recipe support, I
   guess I can't object too
   much :) The only risk is that if anyone starts using this
   first support immediately,
   I do risk regressing their use case, where if it never goes
   in, that won't happen.
 
   Cheers,
   Bruce
 
  Hi Bruce,
 
  I just tried to reuse the kernel's merge_config.sh script, and
  it turned out well.
  The patch is in attachment.
 
  Is it enough for now?
 
  Yep, this is enough for now. It re-uses the significant part of the
  infrastructure, which
  is the important part. Once it is in tree, I can refine the dependency
  and some other
  minor modifications.
 
  Feel free to add my Signed-off-by: to the patch as well.
 
  This patch triggers a failure on the autobuilder:

 Hmmm. I didn't realize this had been picked up yet, I was waiting for
 a repost with the Sign-offs. I assume this is master under test ? I can
 pick up the patch from there and send an updated patch, since Chen Qi
 won't be around to look into this for a few days.

 It was master under test, it won't make master until it works :)

 I don't mind who sends me the working version.

Attached is the fixed up patch with DEPENDS, the existing one had a typo
in:

  do_config[depends] = kern-tools-native:do_populate_sysroot

I've gone ahead and replaced it with a DEPENDS and tested the failure case
here.

This is a complete patch replacement, let me know if you'd prefer something
incremental.

Cheers,

Bruce


 Cheers,

 Richard






--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

On Tuesday 12 February 2013 14:44:58 Otavio Salvador wrote:
 On Tue, Feb 12, 2013 at 1:50 PM, Ross Burton ross.bur...@intel.com wrote:
  On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
   * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
   Another bbappend apparently for systemd support. Again, this should
   have been moved to meta-systemd; do we now need to merge it into
   OE-Core?
  
  Yes, half of it has been merged to master already. The rest should be
  in Radu's branch, we can sort that today.
  
  I take that back - polkit in oe-core supports systemd if enabled, so this
  append can be removed.

 In fact we cannot drop the bbappend or we break the upgrade path
 (except if we bump PR in OE-Core to keep it).

These do need to be dropped; if bumping PR in OE-Core is what has to happen to 
achieve that then so be it.

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] tclibc-eglibc: use glibc-thread-db as eglibc-thread-db does not exist(?)

2013-02-12 Thread Marcin Juszkiewicz

W dniu 12.02.2013 17:30, Richard Purdie pisze:
 On Tue, 2013-02-12 at 15:25 +0100, Marcin Juszkiewicz wrote:
 | Collected errors:
 |  * satisfy_dependencies_for: Cannot satisfy the following dependencies for 
 packagegroup-core-standalone-hhvm-sdk-target:
 |  *eglibc-thread-db *

 eglibc-thread-db is listed in LIBC_DEPENDENCIES and used by SDK. Package
 ends as libthread-db1 and provides glibc-thread-db.

 Signed-off-by: Marcin Juszkiewicz marcin.juszkiew...@linaro.org
 ---
  meta/conf/distro/include/tclibc-eglibc.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 Package renaming should take care of this. If it doesn't happen, that is
 a bug in the package renaming. This just hacks around it.
 
 How do we reproduce this?

In my case bitbake meta-toolchain was enough as most of things went
from sstate-cache. Will do clean build during night.


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpfm4: exclude from world

2013-02-12 Thread McClintock Matthew-B29882

On Thu, Feb 7, 2013 at 4:43 PM, Saul Wold s...@linux.intel.com wrote:
 On 02/07/2013 06:33 AM, Martin Jansa wrote:

 Signed-off-by: Martin Jansa martin.ja...@gmail.com
 ---
   meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb | 3 +++
   1 file changed, 3 insertions(+)

 diff --git a/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
 b/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
 index 460029f..438dbc3 100644
 --- a/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
 +++ b/meta/recipes-kernel/libpfm/libpfm4_4.3.0.bb
 @@ -24,3 +24,6 @@ S = ${WORKDIR}/libpfm-${PV}
   do_install () {
 oe_runmake install
   }
 +
 +# oprofile depends on it only for ppc* and it fails to build on arm
 +EXCLUDE_FROM_WORLD = 1


 Should it be EXCLUDE_FROM_WORLD or

 COMPATIBLE_MACHINE= (*ppc*|mpc*)

 Since for a ppc world build it would be valid.

We really need COMPATIBLE_ARCH here...

Actually I've found since I tried to upstream my last patches that
libpfm is only a req for ppc64. I'm going to submit some follow up
patches once I hear back from the oprofile person I've been chatting
with

-M

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpfm4: exclude from world

2013-02-12 Thread Phil Blundell

On Tue, 2013-02-12 at 17:14 +, McClintock Matthew-B29882 wrote:
 We really need COMPATIBLE_ARCH here...

Why can't you use COMPATIBLE_HOST?

p.



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpfm4: exclude from world

2013-02-12 Thread McClintock Matthew-B29882

On Tue, Feb 12, 2013 at 11:19 AM, Phil Blundell p...@pbcl.net wrote:
 On Tue, 2013-02-12 at 17:14 +, McClintock Matthew-B29882 wrote:
 We really need COMPATIBLE_ARCH here...

 Why can't you use COMPATIBLE_HOST?

Yes, that's what it's called ;)

-M

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] web: remove gtkhtml2 version

The gtkhtml2 version of Web is even older than the webkitgtk port, remove it.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-sato/web/web/fix_makefile.patch|   20 -
 meta/recipes-sato/web/web/owl-window-menu.patch |   98 ---
 meta/recipes-sato/web/web_git.bb|   28 ---
 3 files changed, 146 deletions(-)
 delete mode 100644 meta/recipes-sato/web/web/fix_makefile.patch
 delete mode 100644 meta/recipes-sato/web/web/owl-window-menu.patch
 delete mode 100644 meta/recipes-sato/web/web_git.bb

diff --git a/meta/recipes-sato/web/web/fix_makefile.patch 
b/meta/recipes-sato/web/web/fix_makefile.patch
deleted file mode 100644
index 3dd3b15..000
--- a/meta/recipes-sato/web/web/fix_makefile.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Upstream-Status: Pending
-
-Nitin A Kamble nitin.a.kam...@intel.com 2011/05/10
-Fix following build error:
-
-| NOTE: make -j 16
-| Makefile:719: *** missing separator (did you mean TAB instead of 8 spaces?). 
 Stop.
-| ERROR: oe_runmake failed
-
-Index: git/Makefile.am
-===
 git.orig/Makefile.am
-+++ git/Makefile.am
-@@ -5,5 +5,5 @@ SUBDIRS = src data
- MAINTAINERCLEANFILES = aclocal.m4 compile config.guess config.sub configure 
depcomp install-sh ltmain.sh Makefile.in missing
- 
- snapshot:
--$(MAKE) dist distdir=$(PACKAGE)-snap`date +%Y%m%d`
-+  $(MAKE) dist distdir=$(PACKAGE)-snap`date +%Y%m%d`
- 
diff --git a/meta/recipes-sato/web/web/owl-window-menu.patch 
b/meta/recipes-sato/web/web/owl-window-menu.patch
deleted file mode 100644
index 1e5916a..000
--- a/meta/recipes-sato/web/web/owl-window-menu.patch
+++ /dev/null
@@ -1,98 +0,0 @@
-Upstream-Status: Inappropriate [enable feature]
-
-Index: trunk/src/web_main.c
-===
 trunk.orig/src/web_main.c  2007-12-18 15:04:13.0 -0800
-+++ trunk/src/web_main.c   2010-11-15 11:40:44.762994000 -0800
-@@ -20,6 +20,8 @@
- #include web_bookmarks.h
- #include web_request.h
- 
-+#include libowl/owlwindowmenu.h
-+
- static void
- copy_cb (GtkWindow *main_window)
- {
-@@ -833,10 +835,8 @@
- main (int argc, char **argv)
- {
-   GtkWidget *widget;
--#ifdef WITH_HILDON
-   GList *children, *c;
-   GtkMenu *menu;
--#endif
-   WebPages pages;
-   GConfClient *client;
-   GModule *module;
-@@ -889,33 +889,12 @@
-   WEB_API_VERSION, pages.backend-api_version);
-   pages.backend-init ((pages.backend_data), pages);
- 
--#ifdef WITH_HILDON
--  osso_initialize (web, 0.0, FALSE, NULL);
--  pages.appview = hildon_appview_new ();
--  pages.window = hildon_app_new_with_appview (pages.appview);
--  hildon_app_set_title (pages.window, Web);
--  gtk_widget_show (pages.appview);
--  
--  /* Reparent widgets to hildon appview */
--  widget = glade_xml_get_widget (pages.xml, main_vbox);
--  gtk_container_remove (
--  GTK_CONTAINER (gtk_widget_get_parent (widget)),
--  g_object_ref (widget));
--  gtk_container_add (GTK_CONTAINER (pages.appview), widget);
--  
--  widget = glade_xml_get_widget (pages.xml, main_toolbar);
--  gtk_container_remove (
--  GTK_CONTAINER (gtk_widget_get_parent (widget)),
--  g_object_ref (widget));
--  gtk_box_pack_end (GTK_BOX (pages.appview-vbox),
--  widget, TRUE, TRUE, 0);
--  gtk_widget_show_all (GTK_WIDGET (pages.appview-vbox));
--  
--  gtk_widget_destroy (glade_xml_get_widget (pages.xml, main_window));
-+  pages.window = glade_xml_get_widget (pages.xml, main_window);
-   
-   /* Reparent menu items */
-   widget = glade_xml_get_widget (pages.xml, main_menubar);
--  menu = hildon_appview_get_menu (pages.appview);
-+  menu = gtk_menu_new ();
-+
-   children = gtk_container_get_children (GTK_CONTAINER (widget));
-   for (c = children; c; c = c-next) {
-   GtkWidget *menuitem = GTK_WIDGET (c-data);
-@@ -926,12 +905,6 @@
-   gtk_widget_destroy (widget);
-   g_list_free (children); 
-   
--  g_signal_connect (G_OBJECT (pages.window),
--  key_press_event, G_CALLBACK (web_key_press_cb), pages);
--#else
--  pages.window = glade_xml_get_widget (pages.xml, main_window);
--#endif
--
-   web_bookmarks_init (pages);
-   
-   /* Set history menus */
-@@ -1064,6 +1037,8 @@
-   
-   gtk_widget_show (pages.window);
- 
-+  owl_set_window_menu (GTK_WINDOW(pages.window), GTK_MENU(menu));
-+
-   gtk_main ();
-   
-   g_module_close (module);
-Index: trunk/src/Makefile.am
-===
 trunk.orig/src/Makefile.am 2007-12-18 15:04:13.0 -0800
-+++ trunk/src/Makefile.am  2010-11-15 11:41:15.754994000 -0800
-@@ -18,7 +18,7 @@
- web.h web_history.h web_bookmarks.h web_request.h \
-

[OE-core] [PATCH 2/2] gtkhtml2: remove, nothing depends on it

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb |   38 ---
 1 file changed, 38 deletions(-)
 delete mode 100644 meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb

diff --git a/meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb 
b/meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb
deleted file mode 100644
index 2fafcec..000
--- a/meta/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb
+++ /dev/null
@@ -1,38 +0,0 @@
-SECTION = libs
-DEPENDS = gtk+ glib-2.0 libxml2
-DESCRIPTION = A GTK+ HTML rendering library.
-LICENSE = LGPLv2
-LIC_FILES_CHKSUM = file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605
-
-SRCREV = 1161
-PV = 2.11.0+svnr${SRCPV}
-PR = r4
-
-SRC_URI = svn://svn.gnome.org/svn/gtkhtml2/;module=trunk;protocol=http \
-   
http://git.yoctoproject.org/cgit/cgit.cgi/web-patches/plain/css-stylesheet-user.patch;striplevel=0;name=patch2
 \
-   
http://git.yoctoproject.org/cgit/cgit.cgi/web-patches/plain/css-media.patch;striplevel=0;name=patch3
 \
-   
http://git.yoctoproject.org/cgit/cgit.cgi/web-patches/plain/add-end-element-signal.patch;striplevel=0;name=patch4
 \
-   
http://git.yoctoproject.org/cgit/cgit.cgi/web-patches/plain/add-dom-functions.patch;striplevel=0;name=patch5
 \
-   
http://git.yoctoproject.org/cgit/cgit.cgi/web-patches/plain/iain-mem-leak.patch;striplevel=0;name=patch6
 \
-  
-
-SRC_URI[patch2.md5sum] = 05fc3627ca364095702dc804f41c8391
-SRC_URI[patch2.sha256sum] = 
df5cca50a8f95333505d7920929fea251daea3be25be6834a1c50a742d9eb674
-
-SRC_URI[patch3.md5sum] = d3fe4cda3545f3e4718f1acc186608ab
-SRC_URI[patch3.sha256sum] = 
3aefaa17ffa38143bf5df1161c51ab402d35bfbee41ab4643c313edf569165d5
-
-SRC_URI[patch4.md5sum] = 651b1601d8a1b21c8a3040fadb729043
-SRC_URI[patch4.sha256sum] = 
d067e8331bf9c6851f1c6067d991a7f54327f532900b405ebdf8e149c071f381
-
-SRC_URI[patch5.md5sum] = 041be9711a16e629d01487664ba97152
-SRC_URI[patch5.sha256sum] = 
42956fb41341cf82ae8bce18b4cf96a7e2aa631b1b60657afb6d7e9be7cd138c
-
-SRC_URI[patch6.md5sum] = 4e11dc7899d68f2be2e06ccee01d296d
-SRC_URI[patch6.sha256sum] = 
1e2cc080e654c1839c5cb4b4adf4c62a23e7da208427f3ba0b16cfed9e5cfa98
-
-S = ${WORKDIR}/trunk
-
-inherit pkgconfig autotools
-
-EXTRA_OECONF =  --disable-accessibility
-- 
1.7.10.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd: Add systemd package to PACKAGE var

On Tue, Feb 12, 2013 at 1:08 AM, Ross Burton ross.bur...@intel.com wrote:
 On Tuesday, 12 February 2013 at 08:22, Khem Raj wrote:
 If someone defines SYSTEMD_PACKAGES to be different
 then ${PN} then we need to make sure that they get
 added to PACKAGES variable

 The only case it won't already be in PACKAGES is if you're creating a package 
 which contains just the service file, which as I've said before isn't 
 recommended - package the service files along with the binaries that they are 
 executing.

 Or is there another use-case I'm missing?


Thinking about it from different perspective, I agree that probably
adding an extra package is not right and having unitfiles as part of
package proper is fine. but we should definitely have a check where if
SYSTEMD_PACKAGES dont exist in PACKAGES then it should error out or
warn about it.


 Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [OE-Core][PATCH] systemd.bbclass: Introduce do_install_append and use systemd unitdir

systemd always uses /lib and /usr/lib to store unit files
so using libdir and base_libdir is incorrect. It will work
where libdir is usr/lib and base_libdir is /lib but wont work
when say its /lib64

Additionally introduce the install append from meta-oe
lot of recipe appends in meta-systemd depend on that

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 meta/classes/systemd.bbclass |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index e0ea65c..32cc5c2 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -115,11 +115,9 @@ def systemd_populate_packages(d):
 
 # Check service-files and call systemd_add_files_and_parse for each entry
 def systemd_check_services():
-base_libdir = d.getVar('base_libdir', True)
-searchpaths = [oe.path.join(d.getVar(sysconfdir, True), systemd, 
system),]
-searchpaths.append(oe.path.join(d.getVar(base_libdir, True), 
systemd, system))
-searchpaths.append(oe.path.join(d.getVar(libdir, True), systemd, 
system))
-searchpaths.append(oe.path.join(d.getVar(libdir, True), systemd, 
user))
+searchpaths = '/etc/systemd/system/' + ' '
+searchpaths += '/lib/systemd/system/' + ' '
+searchpaths += '/usr/lib/systemd/system/' + ' '
 systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
 has_exactly_one_service = len(systemd_packages.split()) == 1
 if has_exactly_one_service:
@@ -133,7 +131,7 @@ def systemd_populate_packages(d):
 for pkg_systemd in systemd_packages.split():
 for service in get_package_var(d, 'SYSTEMD_SERVICE', 
pkg_systemd).split():
 path_found = ''
-for path in searchpaths:
+for path in searchpaths.split():
 if os.path.exists(oe.path.join(d.getVar(D, True), path, 
service)):
 path_found = path
 break
@@ -156,3 +154,14 @@ python populate_packages_prepend () {
 if oe.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
 systemd_populate_packages (d)
 }
+# automatically install all *.service and *.socket supplied in recipe's SRC_URI
+do_install_append() {
+   for service in `find ${WORKDIR} -maxdepth 1 -name '*.service' -o -name 
'*.socket'` ; do
+   # ensure installing systemd-files only (e.g not avahi *.service)
+   if grep -q '\[Unit\]' $service ; then
+   install -d ${D}${systemd_unitdir}/system
+   install -m 644 $service ${D}${systemd_unitdir}/system
+   fi
+   done
+}
+
-- 
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] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Martin Jansa

On Mon, Feb 11, 2013 at 05:09:01PM +, Paul Eggleton wrote:
 Hi all,
 
 I'd like to make an attempt to remove all appends and overlayed recipes from 
 the meta-oe layer. As I've said previously, I don't believe meta-oe - as a 
 collection of very useful additional recipes that many wish to be able to use 
 on top of their OE-Core based build configurations - should be making any 
 possibly unexpected changes to those configurations. Any such changes ought 
 to 
 be the province of distro layers alone.
 
 We've already removed all of the obvious overlayed recipes and the meta-
 systemd split removed most of the pieces that were there for systemd support; 
 there are just a few remaining recipes and appends that need to be dealt 
 with. 
 I'll catalogue these below with my comments.
 
 Currently we have the following overlayed recipes:
 
 * icon-naming-utils: meta-oe has a newer version (0.8.90 vs OE-Core's 0.8.7) 
 and it uses BBCLASSEXTEND rather than OE-Core's native recipe. I would 
 propose 
 to just move the meta-oe version to OE-Core since it appears to be superior.
 
 * libmad: both layers have the same version. The meta-oe version has some 
 slightly different versions of the MIPS compiler flag fix and -fforce-mem 
 removal 
 patches but I think these can be ignored, since the OE-Core versions of these 
 patches have proper headers and are presumably working. The OE-Core version 
 has LICENSE_FLAGS that the meta-oe one doesn't, but is missing an avr32-
 specific optimisation patch that is in the meta-oe version. What would we do 
 with the latter? Is it appropriate to add to the OE-Core recipe?
 
 * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe that 
 is 
 ahead of 1.0; the OE-Core version has two patches not in the meta-oe version 
 but that both have been merged upstream in the git revision being used in the 
 meta-oe version. There is no newer stable release. What do we do here? Should 
 we ask upstream (Chris) for a new stable release?

tslib is also requested on devices where kernel driver returns too much
noise, tslib can filter that, evdev needs separate filter like 
http://atrey.karlin.mff.cuni.cz/~metan/evfilter/
but that isn't integrated in OE.

 * xserver-nodm-init: the two versions are quite distinct. Not sure I 
 understand the full history here but perhaps someone else can fill in the 
 blanks...?

The biggest difference is integrated xinput-calibrator and use of
xserver-common_1.34.bb

 As far as bbappends go we have:
 
 * meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
 As far as I can tell this just adds an /etc/busybox-syslog.default file 
 containing OPTIONS=-C64 and seems to have been added for systemd support. 
 I'm not sure why this wasn't moved to meta-systemd, but I assume it needs to 
 be merged into OE-Core now that systemd support is being added there... ?
 
 * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
 Another bbappend apparently for systemd support. Again, this should have been 
 moved to meta-systemd; do we now need to merge it into OE-Core?
 
 * meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappend
 This is adding qwt to the qte toolchain. As far as I am concerned this is a 
 distro policy decision - Qwt is a third-party library that is not part of Qt. 
 I believe this should be moved to the layers for whichever distros want this.
 
 * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
 * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
 These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this 
 as a distro policy decision; these should move to the layers for whichever 
 distros want this. FWIW, this is particularly egregious if you've already 
 built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

MySQL and PostgreSQL are not in oe-core so it cannot be replaced with
simple PACKAGECONFIG option in oe-core recipe, but I also prefer to
share such .bbappend somewhere instead of every distribution reinventing
the wheel when trying to enable something as simple as db in qt.

 * meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
 Builds against external libav instead of using the builtin copy of ffmpeg, 
 apparently for better performance on ARM (and presumably that is not the only 
 benefit). It's less clear to me what should be done with this, but I'd still 
 rather it could be eliminated. OE-Core does not have ffmpeg/libav; one 
 wonders 
 if it should or not.

-- 
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] [oe] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Chris Larson

On Tue, Feb 12, 2013 at 12:19 PM, Martin Jansa martin.ja...@gmail.comwrote:

  * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
  * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
  These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see
 this
  as a distro policy decision; these should move to the layers for
 whichever
  distros want this. FWIW, this is particularly egregious if you've already
  built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

 MySQL and PostgreSQL are not in oe-core so it cannot be replaced with
 simple PACKAGECONFIG option in oe-core recipe, but I also prefer to
 share such .bbappend somewhere instead of every distribution reinventing
 the wheel when trying to enable something as simple as db in qt.


I don't see any reason the oe-core recipe couldn't provide the
packageconfig options, even missing the dependencies. They are valid
package configuration options, so they should exist in PACKAGECONFIG. If a
distro wants to enable one of them, however, they'd better include the
layers that provide the deps :)
-- 
Christopher Larson
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

If you never use sstate and always build everything from scratch you
will never see this problem.  However, if you use sstate and build
directories that last a long time eventually you can end up with the
scenario where libtool gets a hard coded path in it for sed, and sed
may not exist.  The reason you don't see this problem to often if you
generally build from scratch is that libtool builds before sed and
will pickup the host's /bin/sed.

The way to reproduce the issue is:

bitbake some_image
bitbake -c cleansstate libtool-native
bitbake sed-native
bitbake libtool-native
bitbake -c clean sed-native
bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE

In my case I used modphp, which doesn't exist in the oe-core. You will
end up with a strange looking error like:

| make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
| 
/opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
 line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: No such 
file or directory

The solution is to always use /bin/sed for libtool-native.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 .../libtool/libtool-native_2.4.2.bb|3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb 
b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
index f12e6a1..18188ef 100644
--- a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
+++ b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
@@ -2,12 +2,13 @@ require libtool-${PV}.inc
 
 DEPENDS = 
 
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
 SRC_URI += file://prefix.patch
 
 inherit native
 
 EXTRA_OECONF =  --with-libtool-sysroot=${STAGING_DIR_NATIVE}
+CACHED_CONFIGUREVARS += ac_cv_path_SED=/bin/sed
 
 do_configure_prepend () {
# Remove any existing libtool m4 since old stale versions would break
-- 
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] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Martin Jansa

On Tue, Feb 12, 2013 at 07:32:33PM +, Paul Eggleton wrote:
 On Tuesday 12 February 2013 20:19:02 Martin Jansa wrote:
  On Mon, Feb 11, 2013 at 05:09:01PM +, Paul Eggleton wrote:
   * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
   that is ahead of 1.0; the OE-Core version has two patches not in the
   meta-oe version but that both have been merged upstream in the git
   revision being used in the meta-oe version. There is no newer stable
   release. What do we do here? Should we ask upstream (Chris) for a new
   stable release?
  
  tslib is also requested on devices where kernel driver returns too much
  noise, tslib can filter that, evdev needs separate filter like
  http://atrey.karlin.mff.cuni.cz/~metan/evfilter/
  but that isn't integrated in OE.
 
 OK. I think the best course of action is to petition upstream for a stable 
 release and then update OE-Core to that, then we can drop the recipe from 
 meta-oe without ill effect.

Agreed,
 
   * xserver-nodm-init: the two versions are quite distinct. Not sure I
   understand the full history here but perhaps someone else can fill in the
   blanks...?
  
  The biggest difference is integrated xinput-calibrator and use of
  xserver-common_1.34.bb
 
 So can you see a means for us to move this into OE-Core? Where are the points 
 of conflict?

xinput-calibrator is now being reworked by Andreas so we should at least
wait for this rework to settle down and xserver-common is similar to
formfactor, a bit more flexible but a lot worse to maintain for new
MACHINES (FWIW all local patches are waiting in florian mbox).

-- 
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] [oe] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Mark Hatle


On 2/12/13 1:32 PM, Chris Larson wrote:


On Tue, Feb 12, 2013 at 12:19 PM, Martin Jansa martin.ja...@gmail.com
mailto:martin.ja...@gmail.com wrote:

  * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
  * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
  These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see 
this
  as a distro policy decision; these should move to the layers for 
whichever
  distros want this. FWIW, this is particularly egregious if you've already
  built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

MySQL and PostgreSQL are not in oe-core so it cannot be replaced with
simple PACKAGECONFIG option in oe-core recipe, but I also prefer to
share such .bbappend somewhere instead of every distribution reinventing
the wheel when trying to enable something as simple as db in qt.


I don't see any reason the oe-core recipe couldn't provide the packageconfig
options, even missing the dependencies. They are valid package configuration
options, so they should exist in PACKAGECONFIG. If a distro wants to enable one
of them, however, they'd better include the layers that provide the deps :)


RPM and Smart integrations both have configuration options that are invalid for 
most configurations or sometimes need additional software provided via a layer. 
 I think this is acceptable, as long as the configuration selects the proper 
DEPENDS/RDEPENDS to ensure the items work properly in the end.


--Mark


--
Christopher Larson


___
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] [PATCH] - squashfs add missing SQUASHFS_FILE_MAX_LOG define in squashfs_fs.h file to fix unsquashfs build.

2013-02-12 Thread Pete Kolcsar

--- a/squashfs_fs.h 2011-02-11 17:49:24.0 +0200
+++ b/squashfs_fs.h 2013-02-12 15:53:04.360256607 +0200
@@ -36,9 +36,9 @@
 
 /* default size of data blocks */
 #define SQUASHFS_FILE_SIZE 131072
-#define SQUASHFS_FILE_LOG  17
 
 #define SQUASHFS_FILE_MAX_SIZE 1048576
+#define SQUASHFS_FILE_MAX_LOG  20
 
 /* Max number of uids and gids */
 #define SQUASHFS_IDS   65536



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] - squashfs add missing SQUASHFS_FILE_MAX_LOG define in squashfs_fs.h file to fix unsquashfs build.

2013-02-12 Thread Saul Wold



This seems to be an incomplete patch and will not patch anything in 
OE-Core directly, maybe you really mean to patch the Squashfs-tools recipe.


Sau!


On 02/12/2013 08:31 AM, Pete Kolcsar wrote:

--- a/squashfs_fs.h 2011-02-11 17:49:24.0 +0200
+++ b/squashfs_fs.h 2013-02-12 15:53:04.360256607 +0200
@@ -36,9 +36,9 @@

  /* default size of data blocks */
  #define SQUASHFS_FILE_SIZE131072
-#define SQUASHFS_FILE_LOG  17

  #define SQUASHFS_FILE_MAX_SIZE1048576
+#define SQUASHFS_FILE_MAX_LOG  20

  /* Max number of uids and gids */
  #define SQUASHFS_IDS  65536



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Marcin Juszkiewicz

W dniu 12.02.2013 20:51, Martin Jansa pisze:

 xserver-common is similar to formfactor, a bit more flexible but a
 lot worse to maintain for new MACHINES

IIRC xserver-common allows to set all MACHINE related variables in
/etc/default/something file. I added that years ago when merged
xserver-common with xserver-kdrive-common with all OE/Poky patches etc.


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

On 12 February 2013 16:43, Otavio Salvador ota...@ossystems.com.br wrote:
 Qt Embedded as we build it is currently configured to use tslib, as is
 SDL. If the alternative (evdev?) is supported they could presumably be
 switched over though. I don't know how practical that is however.

 Yes Qt Embedded uses it; not sure evdev is an alternative here.

I'd be surprised if QtE doesn't support evdev, but I've been surprised
a lot recently.  Can you investigate quickly to see if QtE supports
evdev?

As far as X and oe-core is concerned, tslib isn't involve at all
anymore.  There are xorg-input-tslib drivers in Debian but they've not
been touched for years, the upstream source URL doesn't exist any
more, and I'd actually be somewhat surprised if they worked.  Xorg is
all about evdev + xinput for touchscreens.

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd.bbclass: Introduce do_install_append and use systemd unitdir

On 12 February 2013 17:42, Khem Raj raj.k...@gmail.com wrote:
 systemd always uses /lib and /usr/lib to store unit files
 so using libdir and base_libdir is incorrect. It will work
 where libdir is usr/lib and base_libdir is /lib but wont work
 when say its /lib64

That's interesting, wasn't aware of that.  Why doesn't systemd respect
the configure options?

 Additionally introduce the install append from meta-oe
 lot of recipe appends in meta-systemd depend on that

This was removed on purpose because it should never be used.  It was
used in meta-systemd because the service files in SRC_URI had
hard-coded /usr/bin, /usr/sbin, etc.  Hard-coding these paths is
wrong, you'll need e.g. run a service.in through a
s/@sbindir@/${sbindir} and if you're doing this you can just do that
in do_install_append() and drop it directly into ${D}.

Radu's work at merging the rest of the changes in meta-systemd to
oe-core does this, for example:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rmoisan/systemd-rossid=08d9095b31955eca862d6702dddeaf155ac8c987

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd: Add systemd package to PACKAGE var

On 12 February 2013 17:35, Khem Raj raj.k...@gmail.com wrote:
 Thinking about it from different perspective, I agree that probably
 adding an extra package is not right and having unitfiles as part of
 package proper is fine. but we should definitely have a check where if
 SYSTEMD_PACKAGES dont exist in PACKAGES then it should error out or
 warn about it.

Yes, throwing an error/warning does make sense, as the alternative
would be files mysteriously disappearing.  Can you send a patch for
that?

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Martin Jansa

On Tue, Feb 12, 2013 at 08:51:25PM +, Burton, Ross wrote:
 On 12 February 2013 16:43, Otavio Salvador ota...@ossystems.com.br wrote:
  Qt Embedded as we build it is currently configured to use tslib, as is
  SDL. If the alternative (evdev?) is supported they could presumably be
  switched over though. I don't know how practical that is however.
 
  Yes Qt Embedded uses it; not sure evdev is an alternative here.
 
 I'd be surprised if QtE doesn't support evdev, but I've been surprised
 a lot recently.  Can you investigate quickly to see if QtE supports
 evdev?
 
 As far as X and oe-core is concerned, tslib isn't involve at all
 anymore.  There are xorg-input-tslib drivers in Debian but they've not
 been touched for years, the upstream source URL doesn't exist any
 more, and I'd actually be somewhat surprised if they worked.  Xorg is
 all about evdev + xinput for touchscreens.

Yes, xf86-input-tslib works
http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8

-- 
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] [OE-Core][PATCH] systemd.bbclass: Introduce do_install_append and use systemd unitdir

On Tue, 2013-02-12 at 09:42 -0800, Khem Raj wrote:
 systemd always uses /lib and /usr/lib to store unit files
 so using libdir and base_libdir is incorrect. It will work
 where libdir is usr/lib and base_libdir is /lib but wont work
 when say its /lib64
 
 Additionally introduce the install append from meta-oe
 lot of recipe appends in meta-systemd depend on that
 
 Signed-off-by: Khem Raj raj.k...@gmail.com
 ---
  meta/classes/systemd.bbclass |   21 +++--
  1 file changed, 15 insertions(+), 6 deletions(-)
 
 diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
 index e0ea65c..32cc5c2 100644
 --- a/meta/classes/systemd.bbclass
 +++ b/meta/classes/systemd.bbclass
 @@ -115,11 +115,9 @@ def systemd_populate_packages(d):
  
  # Check service-files and call systemd_add_files_and_parse for each entry
  def systemd_check_services():
 -base_libdir = d.getVar('base_libdir', True)
 -searchpaths = [oe.path.join(d.getVar(sysconfdir, True), systemd, 
 system),]
 -searchpaths.append(oe.path.join(d.getVar(base_libdir, True), 
 systemd, system))
 -searchpaths.append(oe.path.join(d.getVar(libdir, True), systemd, 
 system))
 -searchpaths.append(oe.path.join(d.getVar(libdir, True), systemd, 
 user))
 +searchpaths = '/etc/systemd/system/' + ' '

Why remove sysconfdir? 

Also, lets standardise on one variable please. We have
${nonarch_base_libdir} and ${systemd_unitdir} so do we need to
hardcode /lib and /usr/lib?

I'd suggest we add ${nonarch_libdir}, standardise on those and drop
systemd_unitdir. We use the nonarch for other non-systemd multilib work.

 +searchpaths += '/lib/systemd/system/' + ' '
 +searchpaths += '/usr/lib/systemd/system/' + ' '
  systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
  has_exactly_one_service = len(systemd_packages.split()) == 1
  if has_exactly_one_service:
 @@ -133,7 +131,7 @@ def systemd_populate_packages(d):
  for pkg_systemd in systemd_packages.split():
  for service in get_package_var(d, 'SYSTEMD_SERVICE', 
 pkg_systemd).split():
  path_found = ''
 -for path in searchpaths:
 +for path in searchpaths.split():
  if os.path.exists(oe.path.join(d.getVar(D, True), 
 path, service)):
  path_found = path
  break
 @@ -156,3 +154,14 @@ python populate_packages_prepend () {
  if oe.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
  systemd_populate_packages (d)
  }
 +# automatically install all *.service and *.socket supplied in recipe's 
 SRC_URI
 +do_install_append() {
 + for service in `find ${WORKDIR} -maxdepth 1 -name '*.service' -o -name 
 '*.socket'` ; do
 + # ensure installing systemd-files only (e.g not avahi *.service)
 + if grep -q '\[Unit\]' $service ; then
 + install -d ${D}${systemd_unitdir}/system
 + install -m 644 $service ${D}${systemd_unitdir}/system
 + fi
 + done
 +}
 +

Please no. We have this kind of mess from the binconfig class and its
horrible to maintain. I'm looking forward to ripping that class out
someday.

Lets just write proper do_install functions in the recipes and make them
conditional on systemd being enabled.

Cheers,

Richard



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

On 12 February 2013 21:22, Martin Jansa martin.ja...@gmail.com wrote:
 Yes, xf86-input-tslib works
 http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8

[ surprised face ]

You totally should push those tarballs to a git repo on fd.o,
pengutronix has clearly abandoned it.

In a harsh mood (its 2130 and I'm working) I'm leaning towards making
tslib a packageconfig for qte, and moving tslib into meta-oe...

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
 If you never use sstate and always build everything from scratch you
 will never see this problem.  However, if you use sstate and build
 directories that last a long time eventually you can end up with the
 scenario where libtool gets a hard coded path in it for sed, and sed
 may not exist.  The reason you don't see this problem to often if you
 generally build from scratch is that libtool builds before sed and
 will pickup the host's /bin/sed.
 
 The way to reproduce the issue is:
 
 bitbake some_image
 bitbake -c cleansstate libtool-native
 bitbake sed-native
 bitbake libtool-native
 bitbake -c clean sed-native
 bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE
 
 In my case I used modphp, which doesn't exist in the oe-core. You will
 end up with a strange looking error like:
 
 | make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
 | 
 /opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
  line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: No 
 such file or directory
 
 The solution is to always use /bin/sed for libtool-native.
 
 Signed-off-by: Jason Wessel jason.wes...@windriver.com
 ---
  .../libtool/libtool-native_2.4.2.bb|3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb 
 b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
 index f12e6a1..18188ef 100644
 --- a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
 +++ b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
 @@ -2,12 +2,13 @@ require libtool-${PV}.inc
  
  DEPENDS = 
  
 -PR = ${INC_PR}.0
 +PR = ${INC_PR}.1
  SRC_URI += file://prefix.patch
  
  inherit native
  
  EXTRA_OECONF =  --with-libtool-sysroot=${STAGING_DIR_NATIVE}
 +CACHED_CONFIGUREVARS += ac_cv_path_SED=/bin/sed

Do we have to set a path for it? Can't we rely on PATH being sane? I'm
wondering if we should actually set this in the core site files.
Hardcoding a path to utilities never usually ends well and this is just
the tip of an iceberg.

If we have to use a path, ${bindir}/env sed?

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Otavio Salvador

On Tue, Feb 12, 2013 at 7:36 PM, Burton, Ross ross.bur...@intel.com wrote:
 On 12 February 2013 21:22, Martin Jansa martin.ja...@gmail.com wrote:
 Yes, xf86-input-tslib works
 http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8

 [ surprised face ]

 You totally should push those tarballs to a git repo on fd.o,
 pengutronix has clearly abandoned it.

 In a harsh mood (its 2130 and I'm working) I'm leaning towards making
 tslib a packageconfig for qte, and moving tslib into meta-oe...

Not if qte does not support evdev; this needs to be checked first or
it'll be a regression.

-- 
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] [oe] RFC: meta-oe appends and overlayed recipes

2013-02-12 Thread Eric Bénard

Hi Ross,

Le Tue, 12 Feb 2013 21:36:16 +,
Burton, Ross ross.bur...@intel.com a écrit :

 On 12 February 2013 21:22, Martin Jansa martin.ja...@gmail.com wrote:
  Yes, xf86-input-tslib works
  http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8
 
 [ surprised face ]
 
 You totally should push those tarballs to a git repo on fd.o,
 pengutronix has clearly abandoned it.
 
 In a harsh mood (its 2130 and I'm working) I'm leaning towards making
 tslib a packageconfig for qte, and moving tslib into meta-oe...
 
if you have a how-to to get Qt/E 4.x working with evdev, please send it
before removing tslib so that we can test it on several boards which
are actually running with Qt/E+tslib.

Thanks
Eric

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] RFC: meta-oe appends and overlayed recipes

On 12 February 2013 21:53, Eric Bénard e...@eukrea.com wrote:
 if you have a how-to to get Qt/E 4.x working with evdev, please send it
 before removing tslib so that we can test it on several boards which
 are actually running with Qt/E+tslib.

Totally, not regressing badly is a prerequisite.

Ross

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] libc-common.bbclass: DEBIAN_NAMES expansion

DEBIAN_NAMES ought to work for multilibs, and it ought to handle all
the libc packages, not just the base, -dev, and -dbg packages.

I do have one concern about this: The last three lines of the function,
setting up PROVIDE for libc-dbg... I do not know whether we still need
or want those.  The comment about compatibility with old libc makes
me think this may be obsolete.

Testing: Built for multilibs, confirmed that various things seem to
work.  The specific motivation was that the -doc packages weren't
getting installed by the doc-pkgs feature.

The following changes since commit c58e6cf352774e147038e6543ac95ab0060f2327:
  Anders Roxell (1):
distro_check: Remove creation of empty Meego filelist.

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib seebs/debiannames
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/debiannames

Peter Seebach (1):
  libc-common.bbclass: rename ALL the packages

 meta/classes/libc-common.bbclass |   19 +--
 1 files changed, 13 insertions(+), 6 deletions(-)


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] libc-common.bbclass: rename ALL the packages

The DEBIAN_NAMES feature renames some of the libc packages to
libc6* names --but only some. A previous patch added the -dbg
package. However, this doesn't cover other packages (such as
the -doc package), and it didn't take multilibs into account.

Signed-off-by: Peter Seebach peter.seeb...@windriver.com
---
 meta/classes/libc-common.bbclass |   19 +--
 1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/meta/classes/libc-common.bbclass b/meta/classes/libc-common.bbclass
index 67b018b..0d77a2d 100644
--- a/meta/classes/libc-common.bbclass
+++ b/meta/classes/libc-common.bbclass
@@ -25,12 +25,19 @@ def get_libc_fpu_setting(bb, d):
 
 python populate_packages_prepend () {
 if d.getVar('DEBIAN_NAMES', True):
+pkgs = d.getVar('PACKAGES', True).split()
 bpn = d.getVar('BPN', True)
-d.setVar('PKG_'+bpn, 'libc6')
-d.setVar('PKG_'+bpn+'-dev', 'libc6-dev')
-d.setVar('PKG_'+bpn+'-dbg', 'libc6-dbg')
+prefix = d.getVar('MLPREFIX', True) or 
+# Set the base package...
+d.setVar('PKG_' + prefix + bpn, prefix + 'libc6')
+initial = prefix + bpn + '-'
+for p in pkgs:
+# And all the subpackages.
+if p.startswith(initial):
+renamed = p.replace(bpn, 'libc6', 1)
+d.setVar('PKG_' + p, renamed)
 # For backward compatibility with old -dbg package
-d.appendVar('RPROVIDES_' + bpn + '-dbg', ' libc-dbg')
-d.appendVar('RCONFLICTS_' + bpn + '-dbg', ' libc-dbg')
-d.appendVar('RREPLACES_' + bpn + '-dbg', ' libc-dbg')
+d.appendVar('RPROVIDES_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
+d.appendVar('RCONFLICTS_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
+d.appendVar('RREPLACES_' + initial + 'dbg', ' ' + prefix + 'libc-dbg')
 }
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd: Add systemd package to PACKAGE var

On Tue, Feb 12, 2013 at 1:06 PM, Burton, Ross ross.bur...@intel.com wrote:

 Yes, throwing an error/warning does make sense, as the alternative
 would be files mysteriously disappearing.  Can you send a patch for
 that?

I have something for test.

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] pseudo 1.4.4

So, about two days AFTER pseudo 1.4.3 goes in, I finally hit the fairly
obvious bug in the link/linkat() changes. Summary: In general, if parameter
names end in 'path' pseudo tries to do automatic path fixups for them.
This doesn't work well for the *at() functions, because they can need
magic done with their corresponding file descriptors. So linkat() doesn't
take already-converted names.

link(), however, was using fully-expanded names. And when I converted it
to just call linkat(), it preserved this behavior. The obvious failure
is that in a chroot() environment, link() would prepend the chroot path
twice; once in link(), and once in linkat() which it called.

Fixed in pseudo 1.4.4, retested against the test case. Due to the
slightly-too-magical way pseudo works, the only actual changes are to
the names of the parameters of link().


The following changes since commit c58e6cf352774e147038e6543ac95ab0060f2327:
  Anders Roxell (1):
distro_check: Remove creation of empty Meego filelist.

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib seebs/pseudo144
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/pseudo144

Peter Seebach (1):
  pseudo_git.bb: Bump to pseudo 1.4.4.

 .../pseudo/{pseudo_1.4.3.bb = pseudo_1.4.4.bb}|4 ++--
 meta/recipes-devtools/pseudo/pseudo_git.bb |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/pseudo/{pseudo_1.4.3.bb = pseudo_1.4.4.bb} (43%)


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] pseudo_git.bb: Bump to pseudo 1.4.4.

The pseudo 1.4.2 linkat() implementation had a broken edge case
in which you could end up with chroot paths being doubled when
using plain link() calls instead of linkat() calls.

Signed-off-by: Peter Seebach peter.seeb...@windriver.com
---
 .../pseudo/{pseudo_1.4.3.bb = pseudo_1.4.4.bb}|4 ++--
 meta/recipes-devtools/pseudo/pseudo_git.bb |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/pseudo/{pseudo_1.4.3.bb = pseudo_1.4.4.bb} (43%)

diff --git a/meta/recipes-devtools/pseudo/pseudo_1.4.3.bb 
b/meta/recipes-devtools/pseudo/pseudo_1.4.4.bb
similarity index 43%
rename from meta/recipes-devtools/pseudo/pseudo_1.4.3.bb
rename to meta/recipes-devtools/pseudo/pseudo_1.4.4.bb
index 8f25bd0..dea607c 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.4.3.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.4.4.bb
@@ -4,5 +4,5 @@ PR = r0
 
 SRC_URI = http://www.yoctoproject.org/downloads/${BPN}/${BPN}-${PV}.tar.bz2;
 
-SRC_URI[md5sum] = ac943153aa78e210e2d0db7c85845db3
-SRC_URI[sha256sum] = 
0ca12a319c0ee87d1c8b2a4310c36a6d68d8d4b8c9c7dba00bace1773baf18e8
+SRC_URI[md5sum] = ae18a1388c032ac910adbf8c3111fdc4
+SRC_URI[sha256sum] = 
e72cb188fd8efb9eadfb5ce571a45a99245ae312eb9830cb9a9726bb25e47c17
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index bbdba43..efffc95 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -1,7 +1,7 @@
 require pseudo.inc
 
-SRCREV = a01d7884e5f3acba1460cf6b500d28390e7af9f8
-PV = 1.4.3+git${SRCPV}
+SRCREV = 363a94bb851046f62648d7c96c749e899bd0648e
+PV = 1.4.4+git${SRCPV}
 PR = r0
 
 DEFAULT_PREFERENCE = -1
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

On Tue, 2013-02-12 at 16:03 -0600, Jason Wessel wrote:
 On 02/12/2013 03:39 PM, Richard Purdie wrote:
  On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
  If you never use sstate and always build everything from scratch you
  will never see this problem.  However, if you use sstate and build
  directories that last a long time eventually you can end up with the
  scenario where libtool gets a hard coded path in it for sed, and sed
  may not exist.  The reason you don't see this problem to often if you
  generally build from scratch is that libtool builds before sed and
  will pickup the host's /bin/sed.
 
  The way to reproduce the issue is:
 
  bitbake some_image
  bitbake -c cleansstate libtool-native
  bitbake sed-native
  bitbake libtool-native
  bitbake -c clean sed-native
  bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE
 
  In my case I used modphp, which doesn't exist in the oe-core. You will
  end up with a strange looking error like:
 
  | make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
  | 
  /opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
   line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: No 
  such file or directory
 
  The solution is to always use /bin/sed for libtool-native.
 
  Signed-off-by: Jason Wessel jason.wes...@windriver.com
  ---
   .../libtool/libtool-native_2.4.2.bb|3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)
 
  diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb 
  b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
  index f12e6a1..18188ef 100644
  --- a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
  +++ b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
  @@ -2,12 +2,13 @@ require libtool-${PV}.inc
   
   DEPENDS = 
   
  -PR = ${INC_PR}.0
  +PR = ${INC_PR}.1
   SRC_URI += file://prefix.patch
   
   inherit native
   
   EXTRA_OECONF =  --with-libtool-sysroot=${STAGING_DIR_NATIVE}
  +CACHED_CONFIGUREVARS += ac_cv_path_SED=/bin/sed
  Do we have to set a path for it? Can't we rely on PATH being sane? I'm
  wondering if we should actually set this in the core site files.
  Hardcoding a path to utilities never usually ends well and this is just
  the tip of an iceberg.
 
  If we have to use a path, ${bindir}/env sed?
 
 
 The libtool seems to be in a class of its own with respect to
 internally hard coding things, so I am inclined to say this is a one
 off because A) it is libtool and B) it is part of the boot strap. For
 any other packages I have not observed any kind of problem with the
 sysroot sed vs host provided sed.
 
 Unfortunately doing ${bindir}/env sed can lead to a fairly rare race
 where sed can be there an get removed later because it will prefer the
 sed in the sysroot area because it is in the path first.  I never hit
 any of these problems until recently while continuing to just randomly
 build things with the usual stream of updates from the git repository.
 
 If we want libtool-native to use something other than /bin/sed on the
 host, the bootstrap needs some kind of overhaul to make libtool depend
 correctly on sed.  Currently we end up with a circular dependency if
 you try to make libtool-native depend on sed-native.

Does it make sense for sed-native to ever be built? I know we have
issues with some others like tar, bzip/gzip and friends but no issues
with sed afaik?

Cheers,

Richard


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd.bbclass: Introduce do_install_append and use systemd unitdir

2013-02-12 Thread Andreas Müller

On Tue, Feb 12, 2013 at 10:24 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Tue, 2013-02-12 at 09:42 -0800, Khem Raj wrote:
 systemd always uses /lib and /usr/lib to store unit files
 so using libdir and base_libdir is incorrect. It will work
 where libdir is usr/lib and base_libdir is /lib but wont work
 when say its /lib64

 Additionally introduce the install append from meta-oe
 lot of recipe appends in meta-systemd depend on that

 Signed-off-by: Khem Raj raj.k...@gmail.com
 ---
  meta/classes/systemd.bbclass |   21 +++--
  1 file changed, 15 insertions(+), 6 deletions(-)

 diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
 index e0ea65c..32cc5c2 100644
 --- a/meta/classes/systemd.bbclass
 +++ b/meta/classes/systemd.bbclass
 @@ -115,11 +115,9 @@ def systemd_populate_packages(d):

  # Check service-files and call systemd_add_files_and_parse for each 
 entry
  def systemd_check_services():
 -base_libdir = d.getVar('base_libdir', True)
 -searchpaths = [oe.path.join(d.getVar(sysconfdir, True), 
 systemd, system),]
 -searchpaths.append(oe.path.join(d.getVar(base_libdir, True), 
 systemd, system))
 -searchpaths.append(oe.path.join(d.getVar(libdir, True), 
 systemd, system))
 -searchpaths.append(oe.path.join(d.getVar(libdir, True), 
 systemd, user))
 +searchpaths = '/etc/systemd/system/' + ' '

 Why remove sysconfdir?

 Also, lets standardise on one variable please. We have
 ${nonarch_base_libdir} and ${systemd_unitdir} so do we need to
 hardcode /lib and /usr/lib?

 I'd suggest we add ${nonarch_libdir}, standardise on those and drop
 systemd_unitdir. We use the nonarch for other non-systemd multilib work.

 +searchpaths += '/lib/systemd/system/' + ' '
 +searchpaths += '/usr/lib/systemd/system/' + ' '
  systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
  has_exactly_one_service = len(systemd_packages.split()) == 1
  if has_exactly_one_service:
 @@ -133,7 +131,7 @@ def systemd_populate_packages(d):
  for pkg_systemd in systemd_packages.split():
  for service in get_package_var(d, 'SYSTEMD_SERVICE', 
 pkg_systemd).split():
  path_found = ''
 -for path in searchpaths:
 +for path in searchpaths.split():
  if os.path.exists(oe.path.join(d.getVar(D, True), 
 path, service)):
  path_found = path
  break
 @@ -156,3 +154,14 @@ python populate_packages_prepend () {
  if oe.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
  systemd_populate_packages (d)
  }
 +# automatically install all *.service and *.socket supplied in recipe's 
 SRC_URI
 +do_install_append() {
 + for service in `find ${WORKDIR} -maxdepth 1 -name '*.service' -o -name 
 '*.socket'` ; do
 + # ensure installing systemd-files only (e.g not avahi *.service)
 + if grep -q '\[Unit\]' $service ; then
 + install -d ${D}${systemd_unitdir}/system
 + install -m 644 $service ${D}${systemd_unitdir}/system
 + fi
 + done
 +}
 +

 Please no. We have this kind of mess from the binconfig class and its
 horrible to maintain. I'm looking forward to ripping that class out
 someday.

 Lets just write proper do_install functions in the recipes and make them
 conditional on systemd being enabled.

Copying similar code in in tons of recipes is easier to maintain? We
had this before meta-systemd started and it was a mess. How about a
variable SYSTEMD_AUTO_INSTALL?=enable for this - since it fits in
many cases.

Andreas

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] systemd.bbclass: Introduce do_install_append and use systemd unitdir

On Wed, 2013-02-13 at 00:55 +0100, Andreas Müller wrote:
 On Tue, Feb 12, 2013 at 10:24 PM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
  On Tue, 2013-02-12 at 09:42 -0800, Khem Raj wrote:
  systemd always uses /lib and /usr/lib to store unit files
  so using libdir and base_libdir is incorrect. It will work
  where libdir is usr/lib and base_libdir is /lib but wont work
  when say its /lib64
 
  Additionally introduce the install append from meta-oe
  lot of recipe appends in meta-systemd depend on that
 
  Signed-off-by: Khem Raj raj.k...@gmail.com
  ---
   meta/classes/systemd.bbclass |   21 +++--
   1 file changed, 15 insertions(+), 6 deletions(-)
 
  diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
  index e0ea65c..32cc5c2 100644
  --- a/meta/classes/systemd.bbclass
  +++ b/meta/classes/systemd.bbclass
  @@ -115,11 +115,9 @@ def systemd_populate_packages(d):
 
   # Check service-files and call systemd_add_files_and_parse for each 
  entry
   def systemd_check_services():
  -base_libdir = d.getVar('base_libdir', True)
  -searchpaths = [oe.path.join(d.getVar(sysconfdir, True), 
  systemd, system),]
  -searchpaths.append(oe.path.join(d.getVar(base_libdir, True), 
  systemd, system))
  -searchpaths.append(oe.path.join(d.getVar(libdir, True), 
  systemd, system))
  -searchpaths.append(oe.path.join(d.getVar(libdir, True), 
  systemd, user))
  +searchpaths = '/etc/systemd/system/' + ' '
 
  Why remove sysconfdir?
 
  Also, lets standardise on one variable please. We have
  ${nonarch_base_libdir} and ${systemd_unitdir} so do we need to
  hardcode /lib and /usr/lib?
 
  I'd suggest we add ${nonarch_libdir}, standardise on those and drop
  systemd_unitdir. We use the nonarch for other non-systemd multilib work.
 
  +searchpaths += '/lib/systemd/system/' + ' '
  +searchpaths += '/usr/lib/systemd/system/' + ' '
   systemd_packages = d.getVar('SYSTEMD_PACKAGES', True)
   has_exactly_one_service = len(systemd_packages.split()) == 1
   if has_exactly_one_service:
  @@ -133,7 +131,7 @@ def systemd_populate_packages(d):
   for pkg_systemd in systemd_packages.split():
   for service in get_package_var(d, 'SYSTEMD_SERVICE', 
  pkg_systemd).split():
   path_found = ''
  -for path in searchpaths:
  +for path in searchpaths.split():
   if os.path.exists(oe.path.join(d.getVar(D, True), 
  path, service)):
   path_found = path
   break
  @@ -156,3 +154,14 @@ python populate_packages_prepend () {
   if oe.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
   systemd_populate_packages (d)
   }
  +# automatically install all *.service and *.socket supplied in recipe's 
  SRC_URI
  +do_install_append() {
  + for service in `find ${WORKDIR} -maxdepth 1 -name '*.service' -o 
  -name '*.socket'` ; do
  + # ensure installing systemd-files only (e.g not avahi *.service)
  + if grep -q '\[Unit\]' $service ; then
  + install -d ${D}${systemd_unitdir}/system
  + install -m 644 $service ${D}${systemd_unitdir}/system
  + fi
  + done
  +}
  +
 
  Please no. We have this kind of mess from the binconfig class and its
  horrible to maintain. I'm looking forward to ripping that class out
  someday.
 
  Lets just write proper do_install functions in the recipes and make them
  conditional on systemd being enabled.
 
 Copying similar code in in tons of recipes is easier to maintain?

Its dangerous and risky. This code sits silently in the class file and
copies files. Imagine some project starts installing its own service
files yet someone doesn't notice when they upgrade the recipe. All of a
sudden we start overwriting files and nobody notices. This does happen
as things get adopted by upstreams.

This is the big problem with the binconfig class, it overwrites anything
do_install does. We have so much history there we don't dare touch it
either. How did we get there? Originally packages didn't provide -config
files. Personally, I can't wait to delete the thing.

 We had this before meta-systemd started and it was a mess. How about a
 variable SYSTEMD_AUTO_INSTALL?=enable for this - since it fits in
 many cases.

At least spell out which files to install:

SYSTEMD_EXTRAINSTALL = ${WORKDIR}/.service

then the user stands a better change of spotting a conflict. Yes, I know
the files are listed in SRC_URI but I don't think its enough. We can
also throw an error if the files already exist.

There is a time and a place for magic things behind the scenes but IME
find calls in functions like this don't end well. The ignore avahi
service files issue in the code already should serve as a suitable
warning too.

Cheers,

Richard

[OE-core] site/x32-linux: Specify double alignment

Double alignment is 8 bytes on x32 but it is defaulting to 4 currently.
This leads to various issues and fontconfig fails to build due to the
mismatch triggering assert failures.

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org

diff --git a/meta/site/x32-linux b/meta/site/x32-linux
index 7ce6551..36ee68b 100644
--- a/meta/site/x32-linux
+++ b/meta/site/x32-linux
@@ -4,6 +4,7 @@ ac_cv_sizeof_off_t=${ac_cv_sizeof_off_t=8}
 ac_cv_sizeof_ino_t=${ac_cv_sizeof_ino_t=8}
 ac_cv_sizeof_dev_t=${ac_cv_sizeof_dev_t=8}
 ac_cv_sys_file_offset_bits=${ac_cv_sys_file_offset_bits=64}
+ac_cv_alignof_double=8
 
 # glib
 glib_cv_sizeof_gmutex=${glib_cv_sizeof_gmutex=32}



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH] multilib: Fix an OVERRIDES expansion order issue

There were problems where a SRC_URI with:

SRC_URI_append_powerpc =  xxx
SRC_URI_append_powerpc64 =  xxx2

would end up with *both* xxx and xxx2 being added when using a multilib
which is clearly incorrect and undesirable.

The issue is that OVERRIDES has virtclass-multilib- added to it,
this eventually changed DEFAULTTUNE which then changes
TRANSLATED_TARGET_ARCH which is in OVERRIDES meaning we then need to
re-evaluate the overides and the TRANSLATED_TARGET_ARCH gets applied
twice since once you apply an override, it doesn't get undone.

Expanding DEFAULTTUNE to the correct value in advance avoids the issue
and means only the correct overrides get applied.

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 5454b4c..d52f721 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -51,6 +51,11 @@ python multilib_virtclass_handler () {
 e.data.setVar(PN, variant + - + e.data.getVar(PN, False))
 e.data.setVar(SHLIBSDIR_virtclass-multilib- + variant ,e.data.getVar(SHL
 e.data.setVar(OVERRIDES, e.data.getVar(OVERRIDES, False) + override)
+
+# DEFAULTTUNE can change TARGET_ARCH override so expand this now before 
update_data
+newtune = e.data.getVar(DEFAULTTUNE_ + virtclass-multilib- + variant)
+if newtune:
+e.data.setVar(DEFAULTTUNE, newtune)
 }
 
 addhandler multilib_virtclass_handler


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] multilib: Fix an OVERRIDES expansion order issue

2013-02-12 Thread Mark Hatle


On 2/12/13 6:21 PM, Richard Purdie wrote:

Please add:

[ YOCTO #3874 ]

to the commit message.  (The problem is complex enough, that the bugzilla entry 
is helpful in understanding why this is needed.)




There were problems where a SRC_URI with:

SRC_URI_append_powerpc =  xxx
SRC_URI_append_powerpc64 =  xxx2

would end up with *both* xxx and xxx2 being added when using a multilib
which is clearly incorrect and undesirable.

The issue is that OVERRIDES has virtclass-multilib- added to it,
this eventually changed DEFAULTTUNE which then changes
TRANSLATED_TARGET_ARCH which is in OVERRIDES meaning we then need to
re-evaluate the overides and the TRANSLATED_TARGET_ARCH gets applied
twice since once you apply an override, it doesn't get undone.

Expanding DEFAULTTUNE to the correct value in advance avoids the issue
and means only the correct overrides get applied.

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 5454b4c..d52f721 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -51,6 +51,11 @@ python multilib_virtclass_handler () {
  e.data.setVar(PN, variant + - + e.data.getVar(PN, False))
  e.data.setVar(SHLIBSDIR_virtclass-multilib- + variant 
,e.data.getVar(SHL
  e.data.setVar(OVERRIDES, e.data.getVar(OVERRIDES, False) + override)
+
+# DEFAULTTUNE can change TARGET_ARCH override so expand this now before 
update_data
+newtune = e.data.getVar(DEFAULTTUNE_ + virtclass-multilib- + variant)
+if newtune:
+e.data.setVar(DEFAULTTUNE, newtune)
  }

  addhandler multilib_virtclass_handler


___
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] libtool-native_2.4.2.bb: Always use /bin/sed for SED

On Tue, Feb 12, 2013 at 2:53 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Tue, 2013-02-12 at 16:03 -0600, Jason Wessel wrote:
 On 02/12/2013 03:39 PM, Richard Purdie wrote:
  On Tue, 2013-02-12 at 13:36 -0600, Jason Wessel wrote:
  If you never use sstate and always build everything from scratch you
  will never see this problem.  However, if you use sstate and build
  directories that last a long time eventually you can end up with the
  scenario where libtool gets a hard coded path in it for sed, and sed
  may not exist.  The reason you don't see this problem to often if you
  generally build from scratch is that libtool builds before sed and
  will pickup the host's /bin/sed.
 
  The way to reproduce the issue is:
 
  bitbake some_image
  bitbake -c cleansstate libtool-native
  bitbake sed-native
  bitbake libtool-native
  bitbake -c clean sed-native
  bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE
 
  In my case I used modphp, which doesn't exist in the oe-core. You will
  end up with a strange looking error like:
 
  | make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
  | 
  /opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
   line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: 
  No such file or directory
 
  The solution is to always use /bin/sed for libtool-native.
 
  Signed-off-by: Jason Wessel jason.wes...@windriver.com
  ---
   .../libtool/libtool-native_2.4.2.bb|3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)
 
  diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb 
  b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
  index f12e6a1..18188ef 100644
  --- a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
  +++ b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
  @@ -2,12 +2,13 @@ require libtool-${PV}.inc
 
   DEPENDS = 
 
  -PR = ${INC_PR}.0
  +PR = ${INC_PR}.1
   SRC_URI += file://prefix.patch
 
   inherit native
 
   EXTRA_OECONF =  --with-libtool-sysroot=${STAGING_DIR_NATIVE}
  +CACHED_CONFIGUREVARS += ac_cv_path_SED=/bin/sed
  Do we have to set a path for it? Can't we rely on PATH being sane? I'm
  wondering if we should actually set this in the core site files.
  Hardcoding a path to utilities never usually ends well and this is just
  the tip of an iceberg.
 
  If we have to use a path, ${bindir}/env sed?
 

 The libtool seems to be in a class of its own with respect to
 internally hard coding things, so I am inclined to say this is a one
 off because A) it is libtool and B) it is part of the boot strap. For
 any other packages I have not observed any kind of problem with the
 sysroot sed vs host provided sed.

 Unfortunately doing ${bindir}/env sed can lead to a fairly rare race
 where sed can be there an get removed later because it will prefer the
 sed in the sysroot area because it is in the path first.  I never hit
 any of these problems until recently while continuing to just randomly
 build things with the usual stream of updates from the git repository.

 If we want libtool-native to use something other than /bin/sed on the
 host, the bootstrap needs some kind of overhaul to make libtool depend
 correctly on sed.  Currently we end up with a circular dependency if
 you try to make libtool-native depend on sed-native.

 Does it make sense for sed-native to ever be built? I know we have
 issues with some others like tar, bzip/gzip and friends but no issues
 with sed afaik?


we could if we get rid of it from following

meta/classes/populate_sdk_base.bbclass:SDK_DEPENDS =
virtual/fakeroot-native sed-native
meta/recipes-core/meta/external-python-tarball.bb:DEPENDS =
opkg-native opkg-utils-native virtual/fakeroot-native sed-native
meta/recipes-devtools/libtool/libtool-2.4.2.inc:# Don't want paths to
sed-native (or anything else) encoded
meta/recipes-gnome/packagegroups/packagegroup-toolset-native.bb:sed-native \




 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] multilib: Fix an OVERRIDES expansion order issue