date:20130531

On 31 May 2013 03:26, Christopher Larson kerg...@gmail.com wrote:
 This makes rpcbind, quota, systemd, portmap, and nfs-utils obey the same tcp
 wrappers PACKAGECONFIG which xinetd obeys.

If many packages have the same packageconfig option, should this be a
distro feature?

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

[OE-core] [PATCH] buildhistory: record removals with Git 2.0 and later

There is a behavior change with Git 2.0 where git add . will no
longer record removals by default unless -A (--all) is specified.
Change to git add -A . so removals are recorded with Git 2.0 and
later.

Signed-off-by: Jonathan Liu net...@gmail.com
---
 meta/classes/buildhistory.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index d39408b..b12da4a 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -510,7 +510,7 @@ END
repostatus=`git status --porcelain | grep -v  metadata-revs$`
HOSTNAME=`hostname 2/dev/null || echo unknown`
if [ $repostatus !=  ] ; then
-   git add .
+   git add -A .
# porcelain output looks like ?? packages/foo/bar
# Ensure we commit metadata-revs with the first commit
for entry in `echo $repostatus | awk '{print $2}' | 
awk -F/ '{print $1}' | sort | uniq` ; do
-- 
1.8.3

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

Re: [OE-core] [PATCH] xf86-video-modesetting: update to git revision cba29fd8c2

On 31 May 2013 06:40, Jonathan Liu net...@gmail.com wrote:
 This adds support for 32 bpp pixmaps when 24 bpp framebuffer is used
 which fixes graphics corruption in some cases.

Instead of grabbing a random git revision, can the patch be backported?

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

Re: [OE-core] [PATCH 0/4] Mesa and Wayland updates

On 31 May 2013 08:18, Koen Kooi k...@dominion.thruhere.net wrote:
 We talked about weston off-list a few weeks ago and this seems a good time to 
 bring it back on list :)

 I'd like to get the framebuffer backend supported, so I upgraded weston to 
 1.0.90 and added:

 + --enable-fbdev-compositor \

 +# Needed for weston-launch
 +WESTONBACKEND ??= fbdev-backend.so
 +
 +export WESTON_NATIVE_BACKEND = ${WESTONBACKEND}

 At the time of writing that weston didn't support runtime detection or config 
 files entries for selecting the backend, only commandline arguments. So 
 whatever is getting picked at build time, you're stuck with that. Does 1.1.x 
 address that situation?

Sadly, not as far as I'm aware.  I have 1.1 in another branch but it
totally broke GTK+ 3 applications (which didn't repaint after the
initial creation), which is pretty sad.  Relevant developers harassed.
:)

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

Re: [OE-core] [PATCH 0/4] Mesa and Wayland updates

On 31 May 2013 10:30, Burton, Ross ross.bur...@intel.com wrote:
 At the time of writing that weston didn't support runtime detection or 
 config files entries for selecting the backend, only commandline arguments. 
 So whatever is getting picked at build time, you're stuck with that. Does 
 1.1.x address that situation?

 Sadly, not as far as I'm aware.  I have 1.1 in another branch but it
 totally broke GTK+ 3 applications (which didn't repaint after the
 initial creation), which is pretty sad.  Relevant developers harassed.

In a massive shock, the weston man page is actually useful.  Sadly
it's clear that the backend choice is either x11 if DISPLAY is set,
wayland-over-wayland if WAYLAND_DISPLAY is set, otherwise the command
line argument finally falling back to the default (drm out of the
box).

So if we want a single binary that supports both DRM and fbdev, then
we need to use command-line options.   I guess our startup script
should handle this and we can add another optional machine-specific
config file.

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

[OE-core] [PATCH] xf86-video-modesetting: backport fix for graphics corruption

This fixes graphics corruption that can occur when using 32 bpp pixmaps
with 24 bpp framebuffer.

Signed-off-by: Jonathan Liu net...@gmail.com
---
 ...ort-32-bpp-pixmaps-when-24-bpp-fb-is-used.patch | 31 ++
 .../xorg-driver/xf86-video-modesetting_0.7.0.bb|  2 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-modesetting/support-32-bpp-pixmaps-when-24-bpp-fb-is-used.patch

diff --git 
a/meta/recipes-graphics/xorg-driver/xf86-video-modesetting/support-32-bpp-pixmaps-when-24-bpp-fb-is-used.patch
 
b/meta/recipes-graphics/xorg-driver/xf86-video-modesetting/support-32-bpp-pixmaps-when-24-bpp-fb-is-used.patch
new file mode 100644
index 000..c351757
--- /dev/null
+++ 
b/meta/recipes-graphics/xorg-driver/xf86-video-modesetting/support-32-bpp-pixmaps-when-24-bpp-fb-is-used.patch
@@ -0,0 +1,31 @@
+Upstream-Status: Backport
+Signed-off-by: Jonathan Liu net...@gmail.com
+
+From cba29fd8c2f605ed66718aa3a6b5833deb5d4cf9 Mon Sep 17 00:00:00 2001
+From: Maarten Lankhorst maarten.lankho...@canonical.com
+Date: Wed, 3 Apr 2013 12:08:44 +0200
+Subject: [PATCH] support 32 bpp pixmaps when 24 bpp fb is used.
+
+Fixes background corruption in ubuntu.
+
+Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
+---
+ src/driver.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/driver.c b/src/driver.c
+index 06d6d53..742aadd 100644
+--- a/src/driver.c
 b/src/driver.c
+@@ -650,7 +650,7 @@ PreInit(ScrnInfoPtr pScrn, int flags)
+ #endif
+ drmmode_get_default_bpp(pScrn, ms-drmmode, defaultdepth, defaultbpp);
+ if (defaultdepth == 24  defaultbpp == 24)
+-  bppflags = Support24bppFb;
++  bppflags = SupportConvert32to24 | Support24bppFb;
+ else
+   bppflags = PreferConvert24to32 | SupportConvert24to32 | 
Support32bppFb;
+ 
+-- 
+1.8.3
+
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.7.0.bb 
b/meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.7.0.bb
index e45703f..9f43402 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.7.0.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-modesetting_0.7.0.bb
@@ -3,5 +3,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=5e53d3fcadb1c23d122ad63cb099a918
 
 DESCRIPTION = X.Org X server -- modesetting display driver
 
+SRC_URI += file://support-32-bpp-pixmaps-when-24-bpp-fb-is-used.patch
+
 SRC_URI[md5sum] = 38e64eb09cef9bdf1de400bbe9818321
 SRC_URI[sha256sum] = 
2bc55f776eaee7b4e13df13238d36c4facf1cdca095a11519baf2376f5c996ac
-- 
1.8.3

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

Re: [OE-core] [PATCH] xf86-video-modesetting: update to git revision cba29fd8c2


On 31/05/2013 7:28 PM, Burton, Ross wrote:

On 31 May 2013 06:40, Jonathan Liu net...@gmail.com wrote:

This adds support for 32 bpp pixmaps when 24 bpp framebuffer is used
which fixes graphics corruption in some cases.

Instead of grabbing a random git revision, can the patch be backported?

Ross

Done.

Regards,
Jonathan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] xf86-video-modesetting: backport fix for graphics corruption

On 31 May 2013 11:07, Jonathan Liu net...@gmail.com wrote:
 This fixes graphics corruption that can occur when using 32 bpp pixmaps
 with 24 bpp framebuffer.

 Signed-off-by: Jonathan Liu net...@gmail.com

Signed-off-by: Ross Burton ross.bur...@intel.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] buildhistory: record removals with Git 2.0 and later


On 31/05/2013 7:42 PM, Jonathan Liu wrote:

There is a behavior change with Git 2.0 where git add . will no
longer record removals by default unless -A (--all) is specified.
Change to git add -A . so removals are recorded with Git 2.0 and
later.

Signed-off-by: Jonathan Liu net...@gmail.com
---
  meta/classes/buildhistory.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
Hmm... looks like I interpreted the Git warning incorrectly. Maybe I 
need to look into this a bit more and perhaps change the commit message.


The following appears after a build with buildhistory enabled:
warning: You ran 'git add' with neither '-A (--all)' or '--ignore-removal',
whose behaviour will change in Git 2.0 with respect to paths you removed.
Paths like 'test.txt' that are
removed from your working tree are ignored with this version of Git.

* 'git add --ignore-removal pathspec', which is the current default,
  ignores paths you removed from your working tree.

* 'git add --all pathspec' will let you also record the removals.

Run 'git status' to check the paths you removed from your working tree.

Regards,
Jonathan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] buildhistory: record removals with Git 2.0 and later


On 31/05/2013 8:29 PM, Jonathan Liu wrote:

On 31/05/2013 7:42 PM, Jonathan Liu wrote:

There is a behavior change with Git 2.0 where git add . will no
longer record removals by default unless -A (--all) is specified.
Change to git add -A . so removals are recorded with Git 2.0 and
later.

Signed-off-by: Jonathan Liu net...@gmail.com
---
  meta/classes/buildhistory.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
Hmm... looks like I interpreted the Git warning incorrectly. Maybe I 
need to look into this a bit more and perhaps change the commit message.


The following appears after a build with buildhistory enabled:
warning: You ran 'git add' with neither '-A (--all)' or 
'--ignore-removal',

whose behaviour will change in Git 2.0 with respect to paths you removed.
Paths like 'test.txt' that are
removed from your working tree are ignored with this version of Git.

* 'git add --ignore-removal pathspec', which is the current default,
  ignores paths you removed from your working tree.

* 'git add --all pathspec' will let you also record the removals.

Run 'git status' to check the paths you removed from your working tree.

Regards,
Jonathan
The warning appears in Git 1.8.3. The path removed was the package 
information for a kernel module after updating from 3.8.11 to 3.8.13.


Regards,
Jonathan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] buildhistory: record removals with Git 2.0 and later

On Friday 31 May 2013 20:29:19 Jonathan Liu wrote:
 On 31/05/2013 7:42 PM, Jonathan Liu wrote:
  There is a behavior change with Git 2.0 where git add . will no
  longer record removals by default unless -A (--all) is specified.
  Change to git add -A . so removals are recorded with Git 2.0 and
  later.
  
  Signed-off-by: Jonathan Liu net...@gmail.com
  ---
  
meta/classes/buildhistory.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
 Hmm... looks like I interpreted the Git warning incorrectly. Maybe I
 need to look into this a bit more and perhaps change the commit message.
 
 The following appears after a build with buildhistory enabled:
 warning: You ran 'git add' with neither '-A (--all)' or '--ignore-removal',
 whose behaviour will change in Git 2.0 with respect to paths you removed.
 Paths like 'test.txt' that are
 removed from your working tree are ignored with this version of Git.
 
 * 'git add --ignore-removal pathspec', which is the current default,
ignores paths you removed from your working tree.
 
 * 'git add --all pathspec' will let you also record the removals.
 
 Run 'git status' to check the paths you removed from your working tree.

So it seems the change is reasonable but yes perhaps the commit message should 
change to mention that it also avoids a warning with 1.8.3.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] buildhistory: record removals with Git 2.0 and later

On Friday 31 May 2013 11:42:27 Paul Eggleton wrote:
 On Friday 31 May 2013 20:29:19 Jonathan Liu wrote:
  On 31/05/2013 7:42 PM, Jonathan Liu wrote:
   There is a behavior change with Git 2.0 where git add . will no
   longer record removals by default unless -A (--all) is specified.
   Change to git add -A . so removals are recorded with Git 2.0 and
   later.
   
   Signed-off-by: Jonathan Liu net...@gmail.com
   ---
   
 meta/classes/buildhistory.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  
  Hmm... looks like I interpreted the Git warning incorrectly. Maybe I
  need to look into this a bit more and perhaps change the commit message.
  
  The following appears after a build with buildhistory enabled:
  warning: You ran 'git add' with neither '-A (--all)' or
  '--ignore-removal',
  whose behaviour will change in Git 2.0 with respect to paths you removed.
  Paths like 'test.txt' that are
  removed from your working tree are ignored with this version of Git.
  
  * 'git add --ignore-removal pathspec', which is the current default,
  
 ignores paths you removed from your working tree.
  
  * 'git add --all pathspec' will let you also record the removals.
  
  Run 'git status' to check the paths you removed from your working tree.
 
 So it seems the change is reasonable but yes perhaps the commit message
 should change to mention that it also avoids a warning with 1.8.3.

Hmm, I misread - looks like we should be using -A or --all right now since we 
do want deleted files to be recorded.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] mesa: update git recipe to 9.1.3 release

It's not bleeding edge but it's better than the previous pre-9.1 commit.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-graphics/mesa/mesa-git.inc |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-git.inc 
b/meta/recipes-graphics/mesa/mesa-git.inc
index ee9a552..aa2f2c3 100644
--- a/meta/recipes-graphics/mesa/mesa-git.inc
+++ b/meta/recipes-graphics/mesa/mesa-git.inc
@@ -1,11 +1,12 @@
-# Current pre-9.1 commit
-SRCREV = 1665af3066f3d58c42e9d5b13098f13615a7672c
-PV = 9.1~git${SRCPV}
+# 9.1.3 commit
+SRCREV = f32ec82a8cfcabc5b7596796f36afe7986651f02
+PV = 9.1.3~git${SRCPV}
 
 LIC_FILES_CHKSUM = 
file://docs/license.html;md5=42d77d95cba529a3637129be87d6555d
 
 SRC_URI = git://anongit.freedesktop.org/git/mesa/mesa;protocol=git \
-   file://0002-cross-compile.patch \
+   file://EGL-Mutate-NativeDisplayType-depending-on-config.patch \
+   file://fix-glsl-cross.patch \

 
 S = ${WORKDIR}/git
-- 
1.7.10.4

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

[OE-core] [PATCH] classes/buildhistory: record removals in buildhistory directory

git add . does not record files that were removed in the buildhistory
directory. Specify the -A flag to also record removals.

This was discovered by the following warning added in Git 1.8.3:
warning: You ran 'git add' with neither '-A (--all)' or '--ignore-removal',
whose behaviour will change in Git 2.0 with respect to paths you removed.

Signed-off-by: Jonathan Liu net...@gmail.com
---
 meta/classes/buildhistory.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index d39408b..b12da4a 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -510,7 +510,7 @@ END
repostatus=`git status --porcelain | grep -v  metadata-revs$`
HOSTNAME=`hostname 2/dev/null || echo unknown`
if [ $repostatus !=  ] ; then
-   git add .
+   git add -A .
# porcelain output looks like ?? packages/foo/bar
# Ensure we commit metadata-revs with the first commit
for entry in `echo $repostatus | awk '{print $2}' | 
awk -F/ '{print $1}' | sort | uniq` ; do
-- 
1.8.2.3

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

Re: [OE-core] [PATCH] buildhistory: record removals with Git 2.0 and later


On 31/05/2013 8:50 PM, Paul Eggleton wrote:

On Friday 31 May 2013 11:42:27 Paul Eggleton wrote:

On Friday 31 May 2013 20:29:19 Jonathan Liu wrote:

On 31/05/2013 7:42 PM, Jonathan Liu wrote:

There is a behavior change with Git 2.0 where git add . will no
longer record removals by default unless -A (--all) is specified.
Change to git add -A . so removals are recorded with Git 2.0 and
later.

Signed-off-by: Jonathan Liu net...@gmail.com
---

   meta/classes/buildhistory.bbclass | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

Hmm... looks like I interpreted the Git warning incorrectly. Maybe I
need to look into this a bit more and perhaps change the commit message.

The following appears after a build with buildhistory enabled:
warning: You ran 'git add' with neither '-A (--all)' or
'--ignore-removal',
whose behaviour will change in Git 2.0 with respect to paths you removed.
Paths like 'test.txt' that are
removed from your working tree are ignored with this version of Git.

* 'git add --ignore-removal pathspec', which is the current default,

ignores paths you removed from your working tree.

* 'git add --all pathspec' will let you also record the removals.

Run 'git status' to check the paths you removed from your working tree.

So it seems the change is reasonable but yes perhaps the commit message
should change to mention that it also avoids a warning with 1.8.3.

Hmm, I misread - looks like we should be using -A or --all right now since we
do want deleted files to be recorded.

Cheers,
Paul


Updated patch submitted.

Regards,
Jonathan
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] mesa: update git recipe to 9.1.3 release

2013-05-31 Thread Martin Jansa

On Fri, May 31, 2013 at 11:49:51AM +0100, Ross Burton wrote:
 It's not bleeding edge but it's better than the previous pre-9.1 commit.
 
 Signed-off-by: Ross Burton ross.bur...@intel.com
 ---
  meta/recipes-graphics/mesa/mesa-git.inc |9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/meta/recipes-graphics/mesa/mesa-git.inc 
 b/meta/recipes-graphics/mesa/mesa-git.inc
 index ee9a552..aa2f2c3 100644
 --- a/meta/recipes-graphics/mesa/mesa-git.inc
 +++ b/meta/recipes-graphics/mesa/mesa-git.inc
 @@ -1,11 +1,12 @@
 -# Current pre-9.1 commit
 -SRCREV = 1665af3066f3d58c42e9d5b13098f13615a7672c
 -PV = 9.1~git${SRCPV}
 +# 9.1.3 commit
 +SRCREV = f32ec82a8cfcabc5b7596796f36afe7986651f02
 +PV = 9.1.3~git${SRCPV}

Why '~' and not '+' like other git recipes? Maybe it matches 9.1.3 now
but with first SRCREV bump or with AUTOREV used '+' would be more
appropriate.

Cheers,

  
  LIC_FILES_CHKSUM = 
 file://docs/license.html;md5=42d77d95cba529a3637129be87d6555d
  
  SRC_URI = git://anongit.freedesktop.org/git/mesa/mesa;protocol=git \
 -   file://0002-cross-compile.patch \
 +   file://EGL-Mutate-NativeDisplayType-depending-on-config.patch \
 +   file://fix-glsl-cross.patch \
 
  
  S = ${WORKDIR}/git
 -- 
 1.7.10.4
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] alsa-tools: Fix configure race

2013-05-31 Thread Cristian Iorga

From: Richard Purdie richard.pur...@linuxfoundation.org

aclocal is being called here directly,
not called by autotools.bbclass wrapper.
aclocal files are installed in sysroot,
and are removed while build is still running.
This translates to a possible race condition during the build.

Fixes [YOCTO #4358].

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
 meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb 
b/meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb
index 81ad55a..24af545 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.0.26.1.bb
@@ -20,14 +20,20 @@ SRC_URI[sha256sum] = 
553338693707fe6ddfc430b9edc4cd2677390e200c9e38de82ede3394e
 
 inherit autotools
 
-EXTRA_OEMAKE += GITCOMPILE_ARGS='--host=${HOST_SYS} --build=${BUILD_SYS} 
--target=${TARGET_SYS} --with-libtool-sysroot=${STAGING_DIR_HOST} 
--prefix=${prefix}' ACLOCAL_FLAGS='-I ${STAGING_DATADIR}/aclocal'
+EXTRA_OEMAKE += GITCOMPILE_ARGS='--host=${HOST_SYS} --build=${BUILD_SYS} 
--target=${TARGET_SYS} --with-libtool-sysroot=${STAGING_DIR_HOST} 
--prefix=${prefix}'
 
 PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'x11', 'gtk+', '', d)}
 PACKAGECONFIG[gtk+] = ,,gtk+,
 
+do_configure () {
+autotools_do_configure
+autotools_copy_aclocal
+}
+
 do_compile_prepend () {
 #Automake dir is not correctly detected in cross compilation case
 export AUTOMAKE_DIR=${STAGING_DATADIR_NATIVE}/$(ls 
${STAGING_DATADIR_NATIVE} | grep automake)
+export ACLOCAL=aclocal --system-acdir=${ACLOCALDIR}/
 }
 
 FILES_${PN} += ${datadir}/ld10k1
-- 
1.7.10.4

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

[OE-core] [PATCH] rpm: remove .real hacks in argument parsing

The argument parser in RPM was patched to look for binary.real, but since the
wrapper now fakes the right argv[0] rpm wasn't able to parse any options.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-devtools/rpm/rpm_5.4.9.bb |4 
 1 file changed, 4 deletions(-)

diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb 
b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
index 2dbdca6..25ec23e 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
@@ -478,10 +478,6 @@ do_install_append_class-native() {
RPM_ETCRPM='$'{RPM_ETCRPM-'`dirname 
$''realpath`'/${@os.path.relpath(d.getVar('sysconfdir', True), 
d.getVar('bindir', True))}/rpm} \
RPM_LOCALEDIRRPM='`dirname 
$''realpath`'/${@os.path.relpath(d.getVar('datadir', True), d.getVar('bindir', 
True))}/locale
done
-
-   # Adjust popt macros to match...
-   cat ${D}/${libdir}/rpm/rpmpopt | sed -e s,^\(rpm[^ ]*\)\([ 
]\),\1.real\2,  ${D}/${libdir}/rpm/rpmpopt.new
-   mv ${D}/${libdir}/rpm/rpmpopt.new ${D}/${libdir}/rpm/rpmpopt
 }
 
 BBCLASSEXTEND = native
-- 
1.7.10.4

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

Re: [OE-core] [PATCH 2/2] mesa: update git recipe to 9.1.3 release

On 31 May 2013 12:01, Martin Jansa martin.ja...@gmail.com wrote:
 Why '~' and not '+' like other git recipes? Maybe it matches 9.1.3 now
 but with first SRCREV bump or with AUTOREV used '+' would be more
 appropriate.

Yes, ~ would be wrong.  Didn't spot this, thanks.

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

[OE-core] [PATCH][V2] mesa: update git recipe to 9.1.3 release

It's not bleeding edge but it's better than the previous pre-9.1 commit.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-graphics/mesa/mesa-git.inc |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-git.inc 
b/meta/recipes-graphics/mesa/mesa-git.inc
index ee9a552..c5507ce 100644
--- a/meta/recipes-graphics/mesa/mesa-git.inc
+++ b/meta/recipes-graphics/mesa/mesa-git.inc
@@ -1,11 +1,12 @@
-# Current pre-9.1 commit
-SRCREV = 1665af3066f3d58c42e9d5b13098f13615a7672c
-PV = 9.1~git${SRCPV}
+# 9.1.3 commit
+SRCREV = f32ec82a8cfcabc5b7596796f36afe7986651f02
+PV = 9.1.3+git${SRCPV}
 
 LIC_FILES_CHKSUM = 
file://docs/license.html;md5=42d77d95cba529a3637129be87d6555d
 
 SRC_URI = git://anongit.freedesktop.org/git/mesa/mesa;protocol=git \
-   file://0002-cross-compile.patch \
+   file://EGL-Mutate-NativeDisplayType-depending-on-config.patch \
+   file://fix-glsl-cross.patch \

 
 S = ${WORKDIR}/git
-- 
1.7.10.4

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

[OE-core] [PATCH][V2] rpm: remove .real hacks in argument parsing

The argument parser in RPM was patched to look for binary.real, but since the
wrapper now fakes the right argv[0] rpm wasn't able to parse any options.

[YOCTO #4581]

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-devtools/rpm/rpm_5.4.9.bb |4 
 1 file changed, 4 deletions(-)

diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb 
b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
index 2dbdca6..25ec23e 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
@@ -478,10 +478,6 @@ do_install_append_class-native() {
RPM_ETCRPM='$'{RPM_ETCRPM-'`dirname 
$''realpath`'/${@os.path.relpath(d.getVar('sysconfdir', True), 
d.getVar('bindir', True))}/rpm} \
RPM_LOCALEDIRRPM='`dirname 
$''realpath`'/${@os.path.relpath(d.getVar('datadir', True), d.getVar('bindir', 
True))}/locale
done
-
-   # Adjust popt macros to match...
-   cat ${D}/${libdir}/rpm/rpmpopt | sed -e s,^\(rpm[^ ]*\)\([ 
]\),\1.real\2,  ${D}/${libdir}/rpm/rpmpopt.new
-   mv ${D}/${libdir}/rpm/rpmpopt.new ${D}/${libdir}/rpm/rpmpopt
 }
 
 BBCLASSEXTEND = native
-- 
1.7.10.4

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

[OE-core] [PATCH v4 0/5] Fixes for makedevs

2013-05-31 Thread Peter Kjellerstedt

When I wanted to create devices from a package I stumbled upon a couple
of problems with the makedevs program. Most notable was that it failed
to set the correct uid/gid for devices created as part of a block (i.e.,
with a count  0).

PATCH v2: And now with Signed-off-by lines, as requested.

PATCH v3: Also made count for blocks of devices behave as a count rather
than the end (noticed after looking a makedevs.c from BusyBox).

PATCH v4: Added a Signed-off-by to the fifth patch. Will only resend it
as the other patches have already been accepted.
The following changes since commit efb8a460d2a977dbd481a0650fba8eb637c65bec:

  package.bbclass: Fix sources contents (2013-05-14 08:52:47 +0300)

are available in the git repository at:

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

Peter Kjellerstedt (5):
  makedevs: Create blocks of devices with the correct uid/gid
  makedevs: Correct the device number calculation for blocks of devices
  makedevs: Make the mode number readable in debug messages
  makedevs: Avoid unnecessary timestamp calculation
  makedevs: Make count actually behave as a count for device blocks

 meta/files/device_table-minimal.txt   |  2 +-
 .../makedevs/makedevs-1.0.0/makedevs.c| 19 +--
 2 files changed, 10 insertions(+), 11 deletions(-)

-- 
1.8.2.1

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

[OE-core] [PATCH v4 5/5] makedevs: Make count actually behave as a count for device blocks

2013-05-31 Thread Peter Kjellerstedt

Previously count actually behaved as end, and did not take start into
account.

Signed-off-by: Peter Kjellerstedt peter.kjellerst...@axis.com
---
 meta/files/device_table-minimal.txt  | 2 +-
 meta/recipes-devtools/makedevs/makedevs-1.0.0/makedevs.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/files/device_table-minimal.txt 
b/meta/files/device_table-minimal.txt
index c6e5463..02ed534 100644
--- a/meta/files/device_table-minimal.txt
+++ b/meta/files/device_table-minimal.txt
@@ -13,7 +13,7 @@
 /dev/apm_bios  c   660 0   46  10  134 -   -   
-
 /dev/fb0   c   600 0   0   29  0   -   -   
-
 /dev/hda   b   660 0   6   3   0   -   -   
-
-/dev/hda   b   660 0   6   3   1   1   1   
20
+/dev/hda   b   660 0   6   3   1   1   1   
19
 /dev/kmem  c   640 0   15  1   2   -   -   
-
 /dev/kmsg  c   600 0   0   1   11  -   -   
-
 /dev/mem   c   640 0   15  1   1   -   -   
-
diff --git a/meta/recipes-devtools/makedevs/makedevs-1.0.0/makedevs.c 
b/meta/recipes-devtools/makedevs/makedevs-1.0.0/makedevs.c
index 4bb316b..6c1f2fb 100644
--- a/meta/recipes-devtools/makedevs/makedevs-1.0.0/makedevs.c
+++ b/meta/recipes-devtools/makedevs/makedevs-1.0.0/makedevs.c
@@ -219,7 +219,7 @@ static int interpret_table_entry(char *line)
dev_t rdev;
char buf[80];
 
-   for (i = start; i  count; i++) {
+   for (i = start; i  start + count; i++) {
sprintf(buf, %s%d, name, i);
sprintf(path, %s/%s%d, rootdir, name, i);
/* FIXME:  MKDEV uses illicit insider knowledge 
of kernel 
-- 
1.8.2.1

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

Re: [OE-core] [PATCH v3 5/5] makedevs: Make count actually behave as a count for device blocks

2013-05-31 Thread Peter Kjellerstedt

 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: den 30 maj 2013 21:58
 To: Peter Kjellerstedt
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH v3 5/5] makedevs: Make count actually
 behave as a count for device blocks
 
 On Thu, 2013-05-30 at 14:18 +0200, Peter Kjellerstedt wrote:
  Previously count actually behaved as end, and did not take start into
  account.
  ---
   meta/files/device_table-minimal.txt  | 2 +-
   meta/recipes-devtools/makedevs/makedevs-1.0.0/makedevs.c | 2 +-
   2 files changed, 2 insertions(+), 2 deletions(-)
 
 No signed-off-by line :(
 
 I merged the others.
 
 Cheers,
 
 Richard

Argh. The fact that we are not using Signed-off-by lines internally 
is not helping me...

I have sent an updated version of the fifth patch.

//Peter

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

Re: [OE-core] [PATCH v2 1/2] hicolor-icon-theme: keep inherited dependencies and switch to gnomebase

Signed-off-by: Ross Burton ross.bur...@intel.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] kernel-yocto: consolidated pull request

2013-05-31 Thread Bruce Ashfield

On Fri, May 31, 2013 at 3:07 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Fri, 2013-05-31 at 15:14 +0900, Saul Wold wrote:
 On 05/31/2013 12:28 PM, Bruce Ashfield wrote:
  Richard/Saul,
 
  While I continue to battle with gcc 4.8, I've got a collection of other 
  fixes
  that don't need to wait. Here's part of those pending changes.
 
- Remove the yocto 3.2 kernel, early in the Yocto 1.5 cycle as promised

 Did I miss a request to remove the .bbappend from meta-yocto-bsp?  There
 seems to be a 3.2 bbappend still.

 In the interests of getting roughly caught up with patches, I've added a
 patch to delete this as well...

Argh. yes. That's sitting on my oe-core branch and I managed to not send
it out.

Thanks for fixing it up.

Bruce


 Cheers,

 Richard

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



--
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.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libpng : upgrade to 1.6.2

2013-05-31 Thread Andrei Dinu

upgrade from 1.6.1 - 1.6.2

- removed patch contained upstream
- minor changes in png.h and LICENSE file ( changes
regarding the date )

Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com
---
 .../libpng/libpng/transform.patch  |   46 
 .../libpng/{libpng_1.6.1.bb = libpng_1.6.2.bb}|9 ++--
 2 files changed, 4 insertions(+), 51 deletions(-)
 delete mode 100644 meta/recipes-multimedia/libpng/libpng/transform.patch
 rename meta/recipes-multimedia/libpng/{libpng_1.6.1.bb = libpng_1.6.2.bb} 
(61%)

diff --git a/meta/recipes-multimedia/libpng/libpng/transform.patch 
b/meta/recipes-multimedia/libpng/libpng/transform.patch
deleted file mode 100644
index 369a2c0..000
--- a/meta/recipes-multimedia/libpng/libpng/transform.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-Corrected the test on user transform changes on read. It was in the png_set of
-the transform function, but that doesn't matter unless the transform function
-changes the rowbuf size, and that is only valid if transform_info is called.
-
-Upstream-Status: Backport (will be in 1.6.2)
- - b44cd59ad9747069b90c6ff0f76558157a61e26a
- - a8715cabd11354da9650dff7c0770686a217b550
-Signed-off-by: Ross Burton ross.bur...@intel.com
-
-
-diff --git a/pngrtran.c b/pngrtran.c
-index 626f3b0..4485e40 100644
 a/pngrtran.c
-+++ b/pngrtran.c
-@@ -1056,9 +1056,6 @@ png_set_read_user_transform_fn(png_structrp png_ptr, 
png_user_transform_ptr
- {
-png_debug(1, in png_set_read_user_transform_fn);
- 
--   if (!png_rtran_ok(png_ptr, 0))
--  return;
--
- #ifdef PNG_READ_USER_TRANSFORM_SUPPORTED
-png_ptr-transformations |= PNG_USER_TRANSFORM;
-png_ptr-read_user_transform_fn = read_user_transform_fn;
-diff --git a/pngtrans.c b/pngtrans.c
-index b532172..f822324 100644
 a/pngtrans.c
-+++ b/pngtrans.c
-@@ -782,6 +782,17 @@ png_set_user_transform_info(png_structrp png_ptr, 
png_voidp
- 
-if (png_ptr == NULL)
-   return;
-+
-+#ifdef PNG_READ_USER_TRANSFORM_SUPPORTED
-+   if ((png_ptr-mode  PNG_IS_READ_STRUCT) != 0 
-+  (png_ptr-flags  PNG_FLAG_ROW_INIT) != 0)
-+   {
-+  png_app_error(png_ptr,
-+info change after png_start_read_image or png_read_update_info);
-+  return;
-+   }
-+#endif
-+
-png_ptr-user_transform_ptr = user_transform_ptr;
-png_ptr-user_transform_depth = (png_byte)user_transform_depth;
-png_ptr-user_transform_channels = (png_byte)user_transform_channels;
diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.1.bb 
b/meta/recipes-multimedia/libpng/libpng_1.6.2.bb
similarity index 61%
rename from meta/recipes-multimedia/libpng/libpng_1.6.1.bb
rename to meta/recipes-multimedia/libpng/libpng_1.6.2.bb
index 6f9fb09..7a19313 100644
--- a/meta/recipes-multimedia/libpng/libpng_1.6.1.bb
+++ b/meta/recipes-multimedia/libpng/libpng_1.6.2.bb
@@ -3,17 +3,16 @@ DESCRIPTION = PNG Library
 HOMEPAGE = http://www.libpng.org/;
 SECTION = libs
 LICENSE = Libpng
-LIC_FILES_CHKSUM = file://LICENSE;md5=8273188b2e21c831f5a09fd9285db62f \
-
file://png.h;beginline=207;endline=321;md5=de107fb61766e9d826943f3b6a354fc9
+LIC_FILES_CHKSUM = file://LICENSE;md5=b7c6b3f443bd29d45da5575f36293606 \
+
file://png.h;beginline=207;endline=321;md5=f8e34d28a077eca674b739ded0de063c
 DEPENDS = zlib
 LIBV = 16
 
 SRC_URI = 
${SOURCEFORGE_MIRROR}/project/libpng/libpng${LIBV}/${PV}/libpng-${PV}.tar.xz \
file://0001-configure-lower-automake-requirement.patch \
-   file://transform.patch \
   
-SRC_URI[md5sum] = 93fc0b0841ce2db0e6756673e22dafc3
-SRC_URI[sha256sum] = 
5ef57f8b9ef591c8504e2a8f78d31779f0c8f2b34b34d01d533360d2483c8946
+SRC_URI[md5sum] = 9d838f6fca9948a9f360a0cc1b516d5f
+SRC_URI[sha256sum] = 
1c97a90bc22107e50f04f77a0115f4ec890d5c6a373ac4c560e8fb87259e92de
 
 inherit autotools binconfig pkgconfig
 
-- 
1.7.9.5

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

Re: [OE-core] [PATCH 0/5] Add 'tcp-wrappers' PACKAGECONFIG

2013-05-31 Thread Chris Larson

On Fri, May 31, 2013 at 2:26 AM, Burton, Ross ross.bur...@intel.com wrote:

 On 31 May 2013 03:26, Christopher Larson kerg...@gmail.com wrote:
  This makes rpcbind, quota, systemd, portmap, and nfs-utils obey the same
 tcp
  wrappers PACKAGECONFIG which xinetd obeys.

 If many packages have the same packageconfig option, should this be a
 distro feature?


It's a good point. At first I thought to avoid that due to feature
proliferation, but as you say, it would probably be a good idea.
-- 
Christopher Larson
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC] get minimal rootfs to be even smaller

I build core-image-minimal today and got 5.1MB image (AArch64/eglibc).
Looked inside the image and found some extra files which can be dropped.

First hit: pci.ids.gz and usb.ids.gz ~350KB in total.

Normally they are needed for lspci/lsusb but they are brought by udev
which does not need them.

Next one can be ldconfig which is ~600KB.

What do you think?

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

[OE-core] [PATCH] udev: do not recommend pciutils/usbutils ids

udev does not require those files to be operational and they add ~350KB
to rootfs

Signed-off-by: Marcin Juszkiewicz mar...@juszkiewicz.com.pl
---
 meta/recipes-core/udev/udev.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index 769d861..ee05ad0 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -14,7 +14,6 @@ LDFLAGS += -lrt
 
 DEPENDS = acl glib-2.0 libusb usbutils pciutils gperf-native libxslt-native 
util-linux
 RPROVIDES_${PN} = hotplug
-RRECOMMENDS_${PN} += usbutils-ids pciutils-ids
 
 SRC_URI = ${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \

file://0001-Fixing-keyboard_force_release.sh-shell-script-path.patch \
-- 
1.8.1.2

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

Re: [OE-core] [RFC] get minimal rootfs to be even smaller

2013-05-31 Thread Phil Blundell

On Fri, 2013-05-31 at 16:11 +0200, Marcin Juszkiewicz wrote:
 Next one can be ldconfig which is ~600KB.

There's already an option to turn that off: you can set USE_LDCONFIG=0
in your distro configuration (which micro does, for example).
Converting that to be a modern DISTRO_FEATURE would be a fine thing.

On the udev thing I guess my initial reaction would be that if you want
the smallest rootfs you probably don't want to be using udev at all.
But if it's installing files that are totally unnecessary then that does
seem a bit extravagant and I agree that it should be curtailed.

p.


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

Re: [OE-core] [PATCH] udev: do not recommend pciutils/usbutils ids

On 31 May 2013 15:11, Marcin Juszkiewicz mar...@juszkiewicz.com.pl wrote:
 udev does not require those files to be operational and they add ~350KB
 to rootfs

 Signed-off-by: Marcin Juszkiewicz mar...@juszkiewicz.com.pl

Well spotted.

Signed-off-by: Ross Burton ross.bur...@intel.com

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

[OE-core] [PATCH 00/11] GTK+ 3 updates

Hi,

Another revision of my GTK+ 3 branch, minus the test changes that need Python
2.7 and with some more fixes, mainly backports to ensure the Wayland backend
works under Weston 1.1.

Ross

The following changes since commit ea281d3b8e5f2ae21b37ea2ad4d440bf9c6427ff:

  bitbake: Added distroy signal to information dialogs (2013-05-31 08:25:40 
+0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ross/gtk

for you to fetch changes up to 125c91479244db72a603b9857949645bdaf5c5e0:

  gtk+3: fix repainting under Weston 1.1 (2013-05-31 16:04:27 +0100)


Ross Burton (11):
  gdk-pixbuf: upgrade to 2.28.1
  at-spi2: add -core and -atk, for GTK+ 3.8
  gtk+3: update to 3.8.2
  gtk+3: explicitly disable introspection
  gtk+3: respect x11 and wayland DISTRO_FEATURES
  gtk+3: add dependencies for gtk+3-demo
  gtk+: remove spurious libgcrypt dependency
  gtk+3: register GSetting schemas
  gtk+3: split into .bb/.inc
  gtk+3: clean up libtool link creation to avoid errors in configure log
  gtk+3: fix repainting under Weston 1.1

 .../gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch  |   23 --
 .../configure_fix.patch|0
 .../extending-libinstall-dependencies.patch|0
 .../hardcoded_libtool.patch|0
 .../{gdk-pixbuf_2.26.5.bb = gdk-pixbuf_2.28.1.bb} |   11 +-
 meta/recipes-gnome/gtk+/gtk+.inc   |2 +-
 .../gtk+/{gtk+3_3.4.4.bb = gtk+3.inc} |   33 ++-
 meta/recipes-gnome/gtk+/gtk+3/cross.patch  |  293 
 .../gtk+/gtk+3/no-x11-in-wayland.patch |   32 +++
 meta/recipes-gnome/gtk+/gtk+3/wayland-attach.patch |   42 +++
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |   17 ++
 meta/recipes-support/atk/at-spi2-atk_2.8.1.bb  |   19 ++
 meta/recipes-support/atk/at-spi2-core_2.8.0.bb |   17 ++
 13 files changed, 149 insertions(+), 340 deletions(-)
 delete mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/configure_fix.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/extending-libinstall-dependencies.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/hardcoded_libtool.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf_2.26.5.bb = 
gdk-pixbuf_2.28.1.bb} (89%)
 rename meta/recipes-gnome/gtk+/{gtk+3_3.4.4.bb = gtk+3.inc} (79%)
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+3/cross.patch
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3/no-x11-in-wayland.patch
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3/wayland-attach.patch
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
 create mode 100644 meta/recipes-support/atk/at-spi2-atk_2.8.1.bb
 create mode 100644 meta/recipes-support/atk/at-spi2-core_2.8.0.bb

Ross Burton (11):
  gdk-pixbuf: upgrade to 2.28.1
  at-spi2: add -core and -atk, for GTK+ 3.8
  gtk+3: update to 3.8.2
  gtk+3: explicitly disable introspection
  gtk+3: respect x11 and wayland DISTRO_FEATURES
  gtk+3: add dependencies for gtk+3-demo
  gtk+: remove spurious libgcrypt dependency
  gtk+3: register GSetting schemas
  gtk+3: split into .bb/.inc
  gtk+3: clean up libtool link creation to avoid errors in configure
log
  gtk+3: fix repainting under Weston 1.1

 .../gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch  |   23 --
 .../configure_fix.patch|0
 .../extending-libinstall-dependencies.patch|0
 .../hardcoded_libtool.patch|0
 .../{gdk-pixbuf_2.26.5.bb = gdk-pixbuf_2.28.1.bb} |   11 +-
 meta/recipes-gnome/gtk+/gtk+.inc   |2 +-
 .../gtk+/{gtk+3_3.4.4.bb = gtk+3.inc} |   33 ++-
 meta/recipes-gnome/gtk+/gtk+3/cross.patch  |  293 
 .../gtk+/gtk+3/no-x11-in-wayland.patch |   32 +++
 meta/recipes-gnome/gtk+/gtk+3/wayland-attach.patch |   42 +++
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |   17 ++
 meta/recipes-support/atk/at-spi2-atk_2.8.1.bb  |   19 ++
 meta/recipes-support/atk/at-spi2-core_2.8.0.bb |   17 ++
 13 files changed, 149 insertions(+), 340 deletions(-)
 delete mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/configure_fix.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/extending-libinstall-dependencies.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/hardcoded_libtool.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf_2.26.5.bb = 
gdk-pixbuf_2.28.1.bb} (89%)
 rename meta/recipes-gnome/gtk+/{gtk+3_3.4.4.bb = gtk+3.inc} (79%)
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+3/cross.patch
 create

[OE-core] [PATCH 01/11] gdk-pixbuf: upgrade to 2.28.1

Something along the lines of pngversion.patch was merged upstream, so drop that
patch.

Also use the new trim_version() function for a future-proof SRC_URI.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 .../gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch  |   23 
 .../configure_fix.patch|0
 .../extending-libinstall-dependencies.patch|0
 .../hardcoded_libtool.patch|0
 .../{gdk-pixbuf_2.26.5.bb = gdk-pixbuf_2.28.1.bb} |   11 +-
 5 files changed, 5 insertions(+), 29 deletions(-)
 delete mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/configure_fix.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/extending-libinstall-dependencies.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf-2.26.5 = 
gdk-pixbuf}/hardcoded_libtool.patch (100%)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf_2.26.5.bb = 
gdk-pixbuf_2.28.1.bb} (89%)

diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch
deleted file mode 100644
index 2e7d5af..000
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-We now have libpng 1.6. If we build libpng12 as well as libpng 1.6, the 1.2 
version gets 
-preferred which is not desirable and does not give deterministic builds.
-
-We really do want to use libpng since the item in DEPENDS will provide this so
-manipulate the search list so the one we DEPEND on gets chosen.
-
-RP 2013/4/13
-
-Upstream-Status: Pending [worth discussing at least]
-
-Index: gdk-pixbuf-2.26.5/configure.ac
-===
 gdk-pixbuf-2.26.5.orig/configure.ac2013-03-26 15:45:16.594820303 
+
-+++ gdk-pixbuf-2.26.5/configure.ac 2013-04-13 10:15:19.241433789 +
-@@ -588,7 +588,7 @@
- 
- dnl Test for libpng
-   if test x$with_libpng != xno  test -z $LIBPNG; then
--for l in libpng15 libpng14 libpng12 libpng13 libpng10 libpng ; do
-+for l in libpng libpng15 libpng14 libpng12 libpng13 libpng10 ; do
-   AC_MSG_CHECKING(for $l)
-   if $PKG_CONFIG --exists $l ; then
- AC_MSG_RESULT(yes)
diff --git 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/configure_fix.patch 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/configure_fix.patch
similarity index 100%
rename from meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/configure_fix.patch
rename to meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/configure_fix.patch
diff --git 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/extending-libinstall-dependencies.patch
 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/extending-libinstall-dependencies.patch
similarity index 100%
rename from 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/extending-libinstall-dependencies.patch
rename to 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/extending-libinstall-dependencies.patch
diff --git 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/hardcoded_libtool.patch 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/hardcoded_libtool.patch
similarity index 100%
rename from 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/hardcoded_libtool.patch
rename to meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/hardcoded_libtool.patch
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.28.1.bb
similarity index 89%
rename from meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
rename to meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.28.1.bb
index b85bbaf..4bf2eb6 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.28.1.bb
@@ -11,17 +11,16 @@ SECTION = libs
 DEPENDS = libpng glib-2.0 jpeg
 DEPENDS_append_linuxstdbase =  virtual/libx11
 
-SRC_URI = 
http://ftp.acc.umu.se/pub/GNOME/sources/gdk-pixbuf/2.26/gdk-pixbuf-${PV}.tar.xz
 \
+MAJ_VER = ${@oe.utils.trim_version(${PV}, 2)}
+
+SRC_URI = ${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
file://hardcoded_libtool.patch \
file://configure_fix.patch \
file://extending-libinstall-dependencies.patch \
-   file://pngversion.patch \

 
-SRC_URI[md5sum] = 339329e6d619ee3e1cb93979111b04c0
-SRC_URI[sha256sum] = 
77696fd163bca95a130a1883dbd78d0ae4d782de2fc85a9a38556d13681f5c84
-
-PR = r1
+SRC_URI[md5sum] = 5c71cce316d08c559fc5970aa60754ab
+SRC_URI[sha256sum] = 
bea0b743fdb5c3c8e23210f73623ec5f18f9ead2522942897fe739d80b50c2bb
 
 inherit autotools pkgconfig gettext pixbufcache
 
-- 
1.7.10.4

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

[OE-core] [PATCH 02/11] at-spi2: add -core and -atk, for GTK+ 3.8

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-support/atk/at-spi2-atk_2.8.1.bb  |   19 +++
 meta/recipes-support/atk/at-spi2-core_2.8.0.bb |   17 +
 2 files changed, 36 insertions(+)
 create mode 100644 meta/recipes-support/atk/at-spi2-atk_2.8.1.bb
 create mode 100644 meta/recipes-support/atk/at-spi2-core_2.8.0.bb

diff --git a/meta/recipes-support/atk/at-spi2-atk_2.8.1.bb 
b/meta/recipes-support/atk/at-spi2-atk_2.8.1.bb
new file mode 100644
index 000..32cbe3b
--- /dev/null
+++ b/meta/recipes-support/atk/at-spi2-atk_2.8.1.bb
@@ -0,0 +1,19 @@
+SUMMARY = AT-SPI 2 Toolkit Bridge
+LICENSE = LGPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=e9f288ba982d60518f375b5898283886
+
+MAJ_VER = ${@oe.utils.trim_version(${PV}, 2)}
+
+SRC_URI = ${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz
+SRC_URI[md5sum] = 854e36a2538bea50bc08d33aa9499bb2
+SRC_URI[sha256sum] = 
eb659b94fde6dc0a2f584c9121a5e6d39a4c8aa297d21d8f9032f7a8a775fd06
+
+DEPENDS = dbus glib-2.0 atk at-spi2-core
+
+inherit autotools
+
+PACKAGES =+ ${PN}-gnome ${PN}-gtk2
+
+FILES_${PN}-gnome = ${libdir}/gnome-settings-daemon-3.0/gtk-modules
+FILES_${PN}-gtk2 = ${libdir}/gtk-2.0/modules/libatk-bridge.*
+FILES_${PN}-dbg += ${libdir}/gtk-2.0/modules/.debug
diff --git a/meta/recipes-support/atk/at-spi2-core_2.8.0.bb 
b/meta/recipes-support/atk/at-spi2-core_2.8.0.bb
new file mode 100644
index 000..29851bb
--- /dev/null
+++ b/meta/recipes-support/atk/at-spi2-core_2.8.0.bb
@@ -0,0 +1,17 @@
+SUMMARY = Assistive Technology Service Provider Interface (dbus core)
+LICENSE = LGPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=e9f288ba982d60518f375b5898283886
+
+MAJ_VER = ${@oe.utils.trim_version(${PV}, 2)}
+
+SRC_URI = ${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz
+SRC_URI[md5sum] = 93b57d5d56d15d1222ddf2386e2f869f
+SRC_URI[sha256sum] = 
1861a30fc7f583d5a567a0ba547db67ce9bd294f0d1c9f7403c96a10a481c458
+
+DEPENDS = dbus glib-2.0 virtual/libx11 libxi
+
+inherit autotools gtk-doc
+
+EXTRA_OECONF = --disable-introspection --disable-xevie
+
+FILES_${PN} += ${datadir}/dbus-1/services/*.service
-- 
1.7.10.4

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

[OE-core] [PATCH 03/11] gtk+3: update to 3.8.2

Drop cross.patch as it was a backport and is integrated upstream.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+3/cross.patch  |  293 
 .../gtk+/{gtk+3_3.4.4.bb = gtk+3_3.8.2.bb}|9 +-
 2 files changed, 5 insertions(+), 297 deletions(-)
 delete mode 100644 meta/recipes-gnome/gtk+/gtk+3/cross.patch
 rename meta/recipes-gnome/gtk+/{gtk+3_3.4.4.bb = gtk+3_3.8.2.bb} (93%)

diff --git a/meta/recipes-gnome/gtk+/gtk+3/cross.patch 
b/meta/recipes-gnome/gtk+/gtk+3/cross.patch
deleted file mode 100644
index f2ea99b..000
--- a/meta/recipes-gnome/gtk+/gtk+3/cross.patch
+++ /dev/null
@@ -1,293 +0,0 @@
-Upstream-Status: Backport [SHA 53083ea7b423482b203372f02d097edbef894a7d]
-Signed-off-by: Ross Burton ross.bur...@intel.com
-
-From b670abe861e8dde067f544b9131edc28575d63ab Mon Sep 17 00:00:00 2001
-From: Ross Burton ross.bur...@intel.com
-Date: Mon, 7 Jan 2013 12:49:27 +
-Subject: [PATCH] build: support cross-compilation by natively building
- gtk-update-icon-cache
-
-When cross-compiling, instead of depending on a natively built GTK+ (which 
means
-building Glib, ATK, Pango, gdk-pixbuf, libX11...) for gtk-update-icon-cache,
-find the host compiler and gdk-pixbuf, and build another gtk-update-icon-cache
-with that.
-
-This uses AX_PROG_CC_FOR_BUILD from autostars to find the host compiler, and
-assumes that you'd set PKG_CONFIG_FOR_BUILD to a host pkg-config binary.
-
-https://bugzilla.gnome.org/show_bug.cgi?id=691301

- configure.ac   |   39 ++
- gtk/Makefile.am|   12 -
- gtk/native/Makefile.am |   12 +
- m4/ax_prog_cc_for_build.m4 |  125 
- 4 files changed, 177 insertions(+), 11 deletions(-)
- create mode 100644 gtk/native/Makefile.am
- create mode 100644 m4/ax_prog_cc_for_build.m4
-
-diff --git a/configure.ac b/configure.ac
-index 0069a9f..f502e06 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -29,6 +29,9 @@ AC_CONFIG_SRCDIR([gdk/gdktypes.h])
- AC_CONFIG_MACRO_DIR([m4])
- AC_CONFIG_AUX_DIR([build-aux])
- 
-+AC_CANONICAL_HOST
-+AC_CANONICAL_TARGET
-+
- # Define a string for the earliest version that this release has
- # backwards binary compatibility with for all interfaces a module
- # might. Unless we add module-only API with lower stability
-@@ -123,6 +126,7 @@ 
AC_SUBST([GAIL_LT_CURRENT_MINUS_AGE],[gail_lt_current_minus_age])
- 
- # Checks for programs.
- AC_PROG_CC
-+AX_PROG_CC_FOR_BUILD
- AC_PROG_CC_C_O
- AC_PROG_CC_STDC
- AC_PROG_MKDIR_P
-@@ -135,8 +139,6 @@ AC_SUBST(GETTEXT_PACKAGE)
- AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, $GETTEXT_PACKAGE,
-[The prefix for our gettext translation domains.])
- 
--AC_CANONICAL_HOST
--
- MATH_LIB=-lm
- AC_MSG_CHECKING([for native Win32])
- LIB_EXE_MACHINE_FLAG=X86
-@@ -868,14 +870,32 @@ dnl Look for a host system's gdk-pixbuf-csource if we 
are cross-compiling
- 
- AM_CONDITIONAL(CROSS_COMPILING, test $cross_compiling = yes)
- 
--if test x$cross_compiling = xyes || test x$enable_gtk2_dependency = xyes; 
then
--  AC_PATH_PROG(GTK_UPDATE_ICON_CACHE, gtk-update-icon-cache, no)
--  if test x$GTK_UPDATE_ICON_CACHE = xno; then
--REBUILD_PNGS=#
--  fi
--fi
-+AS_IF([test x$enable_gtk2_dependency = xyes],
-+  [AC_PATH_PROG(GTK_UPDATE_ICON_CACHE, gtk-update-icon-cache, no)
-+   if test x$GTK_UPDATE_ICON_CACHE = xno; then
-+ REBUILD_PNGS=#
-+   fi],
-+
-+  [test x$cross_compiling = xyes],
-+  [# If no GTK+2 dependency and cross compiling, we need to find a host 
gdk-pixbuf.
-+   # pkg.m4 blocks all variable starting with PKG, so allow this one
-+   m4_pattern_allow([PKG_CONFIG_FOR_BUILD])
-+
-+   AS_IF([test x$PKG_CONFIG_FOR_BUILD = x],
-+ [AC_MSG_ERROR([You must define PKG_CONFIG_FOR_BUILD when cross 
compiling])])
-+
-+   AC_MSG_CHECKING([for native gdk-pixbuf])
-+   AS_IF([AC_RUN_LOG([$PKG_CONFIG_FOR_BUILD --exists --print-errors 
gdk-pixbuf-2.0])],
-+ [AC_MSG_RESULT([yes])],
-+ [AC_MSG_ERROR([native gdk-pixbuf not found])])
-+
-+   NATIVE_GDKPIXBUF_CFLAGS=`$PKG_CONFIG_FOR_BUILD --cflags gdk-pixbuf-2.0`
-+   NATIVE_GDKPIXBUF_LIBS=`$PKG_CONFIG_FOR_BUILD --libs gdk-pixbuf-2.0`
-+   AC_SUBST(NATIVE_GDKPIXBUF_CFLAGS)
-+   AC_SUBST(NATIVE_GDKPIXBUF_LIBS)]
-+)
- 
--AM_CONDITIONAL(USE_EXTERNAL_ICON_CACHE, [test x$cross_compiling = xyes || 
test x$enable_gtk2_dependency = xyes])
-+AM_CONDITIONAL(USE_EXTERNAL_ICON_CACHE, [test x$enable_gtk2_dependency = 
xyes])
- 
- AC_PATH_PROG(GDK_PIXBUF_CSOURCE, gdk-pixbuf-csource, no)
- 
-@@ -1742,6 +1762,7 @@ gtk/makefile.msc
- gtk/gtkversion.h
- gtk/gtk-win32.rc
- gtk/a11y/Makefile
-+gtk/native/Makefile
- gtk/tests/Makefile
- libgail-util/Makefile
- modules/Makefile
-diff --git a/gtk/Makefile.am b/gtk/Makefile.am
-index e763ca8..6b1ec65 100644
 a/gtk/Makefile.am
-+++ b/gtk/Makefile.am
-@@ -16,7 +16,7 @@ else
- GTK_PRINT_PREVIEW_COMMAND=evince

[OE-core] [PATCH 05/11] gtk+3: respect x11 and wayland DISTRO_FEATURES

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 .../gtk+/gtk+3/no-x11-in-wayland.patch |   32 
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |   15 ++---
 2 files changed, 43 insertions(+), 4 deletions(-)
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3/no-x11-in-wayland.patch

diff --git a/meta/recipes-gnome/gtk+/gtk+3/no-x11-in-wayland.patch 
b/meta/recipes-gnome/gtk+/gtk+3/no-x11-in-wayland.patch
new file mode 100644
index 000..df0921a
--- /dev/null
+++ b/meta/recipes-gnome/gtk+/gtk+3/no-x11-in-wayland.patch
@@ -0,0 +1,32 @@
+The Wayland backend was including X11 headers, which won't work in a no-X11
+distro.
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+From 875b1d07ded377b20acbf1a10cae847f56de05b4 Mon Sep 17 00:00:00 2001
+From: Matthias Clasen mcla...@redhat.com
+Date: Thu, 23 May 2013 12:26:26 -0400
+Subject: [PATCH] Don't include X11 headers in wayland
+
+The include of X11/keysyms.h in gdkdevice-wayland.c was just
+a leftover.
+---
+ gdk/wayland/gdkdevice-wayland.c |1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/gdk/wayland/gdkdevice-wayland.c b/gdk/wayland/gdkdevice-wayland.c
+index c258be3..cd4a695 100644
+--- a/gdk/wayland/gdkdevice-wayland.c
 b/gdk/wayland/gdkdevice-wayland.c
+@@ -32,7 +32,6 @@
+ #include gdkdevicemanagerprivate.h
+ 
+ #include xkbcommon/xkbcommon.h
+-#include X11/keysym.h
+ 
+ #include sys/time.h
+ #include sys/mman.h
+-- 
+1.7.10.4
+
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
index 9bd5b9d..1e0fed2 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
@@ -5,9 +5,8 @@ HOMEPAGE = http://www.gtk.org;
 BUGTRACKER = https://bugzilla.gnome.org/;
 SECTION = libs
 
-DEPENDS = glib-2.0 pango atk jpeg libpng libxext libxcursor \
-   docbook-utils-native libxrandr libgcrypt \
-   libxdamage libxrender libxcomposite libxi cairo gdk-pixbuf 
gdk-pixbuf-native
+DEPENDS = glib-2.0 cairo pango atk jpeg libpng gdk-pixbuf libgcrypt \
+   docbook-utils-native gdk-pixbuf-native
 
 LICENSE = LGPLv2  LGPLv2+  LGPLv2.1+
 
@@ -18,7 +17,9 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2 \
 
 MAJ_VER = ${@oe.utils.trim_version(${PV}, 2)}
 
-SRC_URI = http://download.gnome.org/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz;
+SRC_URI = http://download.gnome.org/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz 
\
+   file://no-x11-in-wayland.patch
+
 SRC_URI[md5sum] = 8e878e18fc385f2b813419dc7b40a968
 SRC_URI[sha256sum] = 
1ca80c9c15a1df95d74cefb8c2afe4682ba272a4b489106f04877be2a7aff297
 
@@ -46,6 +47,12 @@ EXTRA_OECONF +=  \
  --disable-introspection \
 
 
+PACKAGECONFIG ??= ${@base_contains(DISTRO_FEATURES, x11, x11, , d)} \
+   ${@base_contains(DISTRO_FEATURES, wayland, wayland, 
, d)}
+
+PACKAGECONFIG[x11] = --enable-x11-backend,--disable-x11-backend,at-spi2-atk 
fontconfig libx11 libxext libxcursor libxi libxdamage libxrandr libxrender 
libxcomposite libxfixes
+PACKAGECONFIG[wayland] = 
--enable-wayland-backend,--disable-wayland-backend,wayland libxkbcommon
+
 do_install_append() {
mv ${D}${bindir}/gtk-update-icon-cache 
${D}${bindir}/gtk-update-icon-cache-3.0
 }
-- 
1.7.10.4

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

[OE-core] [PATCH 06/11] gtk+3: add dependencies for gtk+3-demo

The demo loads PNG files and sniffs mime types, so ensure that these
dependencies are present so the demo actually works.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
index 1e0fed2..cc51fcd 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
@@ -65,6 +65,10 @@ FILES_${PN}-demo = ${bindir}/gtk3-demo \
 ${bindir}/gtk3-widget-factory \
 ${datadir}/gtk-3.0/demo
 
+# The demo uses PNG files and mime type sniffing, so ensure that these
+# dependencies are present.
+RDEPENDS_${PN}-demo += gdk-pixbuf-loader-png shared-mime-info
+
 FILES_${PN} = ${bindir}/gtk-update-icon-cache-3.0 \
${bindir}/gtk-query-immodules-3.0 \
${bindir}/gtk-launch \
-- 
1.7.10.4

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

[OE-core] [PATCH 07/11] gtk+: remove spurious libgcrypt dependency

This dependency was for the display migration patch set, which was finally
dropped entirely in 2007.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+.inc   |2 +-
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
index 84edaf3..73d624c 100644
--- a/meta/recipes-gnome/gtk+/gtk+.inc
+++ b/meta/recipes-gnome/gtk+/gtk+.inc
@@ -12,7 +12,7 @@ SECTION = libs
 
 X11DEPENDS = virtual/libx11 libxext libxcursor libxrandr libxdamage 
libxrender libxcomposite
 DEPENDS = glib-2.0 pango atk jpeg libpng gdk-pixbuf-native 
docbook-utils-native \
- libgcrypt cairo gdk-pixbuf
+ cairo gdk-pixbuf
 
 PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}
 
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
index cc51fcd..9dff4a5 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
@@ -5,7 +5,7 @@ HOMEPAGE = http://www.gtk.org;
 BUGTRACKER = https://bugzilla.gnome.org/;
 SECTION = libs
 
-DEPENDS = glib-2.0 cairo pango atk jpeg libpng gdk-pixbuf libgcrypt \
+DEPENDS = glib-2.0 cairo pango atk jpeg libpng gdk-pixbuf \
docbook-utils-native gdk-pixbuf-native
 
 LICENSE = LGPLv2  LGPLv2+  LGPLv2.1+
-- 
1.7.10.4

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

[OE-core] [PATCH 08/11] gtk+3: register GSetting schemas

The schemas were not being registered, which resulted in a crash when using the
file chooser or colour picker widgets.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
index 9dff4a5..8f254fb 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
@@ -23,7 +23,7 @@ SRC_URI = 
http://download.gnome.org/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz \
 SRC_URI[md5sum] = 8e878e18fc385f2b813419dc7b40a968
 SRC_URI[sha256sum] = 
1ca80c9c15a1df95d74cefb8c2afe4682ba272a4b489106f04877be2a7aff297
 
-inherit autotools pkgconfig gtk-doc update-alternatives gtk-immodules-cache
+inherit autotools pkgconfig gtk-doc update-alternatives gtk-immodules-cache 
gsettings
 
 S = ${WORKDIR}/gtk+-${PV}
 
-- 
1.7.10.4

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

[OE-core] [PATCH 09/11] gtk+3: split into .bb/.inc

I plan on introducing a git master version for automatically testing upstream
development, so this split makes things a lot easier.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+3.inc  |  102 +
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |  111 ++--
 2 files changed, 107 insertions(+), 106 deletions(-)
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3.inc

diff --git a/meta/recipes-gnome/gtk+/gtk+3.inc 
b/meta/recipes-gnome/gtk+/gtk+3.inc
new file mode 100644
index 000..4742eb9
--- /dev/null
+++ b/meta/recipes-gnome/gtk+/gtk+3.inc
@@ -0,0 +1,102 @@
+SUMMARY = Multi-platform toolkit for creating GUIs
+DESCRIPTION = GTK+ is a multi-platform toolkit for creating graphical user 
interfaces. Offering a complete \
+set of widgets, GTK+ is suitable for projects ranging from small one-off 
projects to complete application suites.
+HOMEPAGE = http://www.gtk.org;
+BUGTRACKER = https://bugzilla.gnome.org/;
+SECTION = libs
+
+DEPENDS = glib-2.0 cairo pango atk jpeg libpng gdk-pixbuf \
+   docbook-utils-native gdk-pixbuf-native
+
+LICENSE = LGPLv2  LGPLv2+  LGPLv2.1+
+
+inherit autotools pkgconfig gtk-doc update-alternatives gtk-immodules-cache 
gsettings
+
+# This should be in autotools.bbclass, but until something elses uses it 
putting
+# it here avoids rebuilding everything.
+export PKG_CONFIG_FOR_BUILD = ${STAGING_BINDIR_NATIVE}/pkg-config-native
+
+do_configure_prepend() {
+# Do this because the configure script is running ./libtool directly
+ln -s ${TARGET_PREFIX}libtool libtool || true
+}
+
+# Forcibly disable the GTK+ 2 dependency as we don't want to natively build the
+# entire GTK+ stack, or need GTK+ 2 for gtk-update-icon-cache.
+EXTRA_OECONF +=  \
+ --disable-gtk2-dependency \
+ --disable-glibtest \
+ --disable-xinerama \
+ --enable-modules \
+ --disable-cups \
+ --disable-introspection \
+
+
+PACKAGECONFIG ??= ${@base_contains(DISTRO_FEATURES, x11, x11, , d)} \
+   ${@base_contains(DISTRO_FEATURES, wayland, wayland, 
, d)}
+
+PACKAGECONFIG[x11] = --enable-x11-backend,--disable-x11-backend,at-spi2-atk 
fontconfig libx11 libxext libxcursor libxi libxdamage libxrandr libxrender 
libxcomposite libxfixes
+PACKAGECONFIG[wayland] = 
--enable-wayland-backend,--disable-wayland-backend,wayland libxkbcommon
+
+do_install_append() {
+   mv ${D}${bindir}/gtk-update-icon-cache 
${D}${bindir}/gtk-update-icon-cache-3.0
+}
+
+PACKAGES =+ ${PN}-demo
+LIBV = 3.0.0
+
+FILES_${PN}-demo = ${bindir}/gtk3-demo \
+${bindir}/gtk3-demo-application \
+${bindir}/gtk3-widget-factory \
+${datadir}/gtk-3.0/demo
+
+# The demo uses PNG files and mime type sniffing, so ensure that these
+# dependencies are present.
+RDEPENDS_${PN}-demo += gdk-pixbuf-loader-png shared-mime-info
+
+FILES_${PN} = ${bindir}/gtk-update-icon-cache-3.0 \
+   ${bindir}/gtk-query-immodules-3.0 \
+   ${bindir}/gtk-launch \
+   ${libdir}/lib*${SOLIBS} \
+   ${datadir}/themes ${sysconfdir} ${datadir}/glib-2.0/schemas/ \
+   ${libdir}/gtk-3.0/${LIBV}/engines/libpixmap.so \
+   ${libdir}/gtk-3.0/modules/*.so
+
+FILES_${PN}-dev +=  \
+${datadir}/gtk-3.0/gtkbuilder.rng \
+${datadir}/gtk-3.0/include \
+${libdir}/gtk-3.0/include \
+${libdir}/gtk-3.0/${LIBV}/loaders/*.la \
+${libdir}/gtk-3.0/${LIBV}/immodules/*.la \
+${libdir}/gtk-3.0/3.0.0/printbackends/*.la \
+${libdir}/gtk-3.0/${LIBV}/engines/*.la \
+${libdir}/gtk-3.0/modules/*.la \
+${bindir}/gtk-builder-convert
+
+FILES_${PN}-dbg +=  \
+${libdir}/gtk-3.0/${LIBV}/loaders/.debug \
+${libdir}/gtk-3.0/${LIBV}/immodules/.debug \
+${libdir}/gtk-3.0/${LIBV}/engines/.debug \
+${libdir}/gtk-3.0/${LIBV}/printbackends/.debug \
+${libdir}/gtk-3.0/modules/.debug
+
+
+PACKAGES_DYNAMIC += ^gtk3-immodule-.* ^gtk3-printbackend-.*
+
+ALTERNATIVE_${PN} = gtk-update-icon-cache
+ALTERNATIVE_TARGET[gtk-update-icon-cache] = 
${bindir}/gtk-update-icon-cache-3.0
+
+python populate_packages_prepend () {
+import os.path
+
+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');
+
+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

[OE-core] [PATCH 10/11] gtk+3: clean up libtool link creation to avoid errors in configure log


Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+3.inc |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/gtk+/gtk+3.inc 
b/meta/recipes-gnome/gtk+/gtk+3.inc
index 4742eb9..f4d5254 100644
--- a/meta/recipes-gnome/gtk+/gtk+3.inc
+++ b/meta/recipes-gnome/gtk+/gtk+3.inc
@@ -18,7 +18,8 @@ export PKG_CONFIG_FOR_BUILD = 
${STAGING_BINDIR_NATIVE}/pkg-config-native
 
 do_configure_prepend() {
 # Do this because the configure script is running ./libtool directly
-ln -s ${TARGET_PREFIX}libtool libtool || true
+rm -f libtool
+ln -s ${TARGET_PREFIX}libtool libtool
 }
 
 # Forcibly disable the GTK+ 2 dependency as we don't want to natively build the
-- 
1.7.10.4

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

[OE-core] [PATCH 11/11] gtk+3: fix repainting under Weston 1.1

Weston 1.1 is stricter with the protocol, so fix the behaviour in GTK+.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+3/wayland-attach.patch |   42 
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |3 +-
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3/wayland-attach.patch

diff --git a/meta/recipes-gnome/gtk+/gtk+3/wayland-attach.patch 
b/meta/recipes-gnome/gtk+/gtk+3/wayland-attach.patch
new file mode 100644
index 000..fa0d0e6
--- /dev/null
+++ b/meta/recipes-gnome/gtk+/gtk+3/wayland-attach.patch
@@ -0,0 +1,42 @@
+Wayland 1.1 is enforcing the protocol whereas 1.0 was lenient.  Backport a 
patch
+from git to fix repainting.
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+
+From 0d2c4617203c8fe907c722c9cb53c0345e0405e7 Mon Sep 17 00:00:00 2001
+From: Scott Moreau ore...@gmail.com
+Date: Sun, 10 Mar 2013 10:51:01 -0600
+Subject: [PATCH] wayland: Always attach buffer before committing
+
+With recent changes in attach semantics, we always need to attach before
+committing. Without this changes to the window contents to not get reflected
+in the content of the surface.
+
+Signed-off-by: Rob Bradford r...@linux.intel.com
+---
+ gdk/wayland/gdkwindow-wayland.c |7 ---
+ 1 file changed, 7 deletions(-)
+
+diff --git a/gdk/wayland/gdkwindow-wayland.c b/gdk/wayland/gdkwindow-wayland.c
+index 112a1f4..fa01e90 100644
+--- a/gdk/wayland/gdkwindow-wayland.c
 b/gdk/wayland/gdkwindow-wayland.c
+@@ -327,13 +327,6 @@ gdk_wayland_window_attach_image (GdkWindow *window)
+   if (GDK_WINDOW_DESTROYED (window))
+ return;
+ 
+-  /* The drawn to Cairo surface is the same as the Cairo surface from which
+-   * we are driving the buffer for the Wayland surface. Therefore we don't
+-   * need to do anything here
+-   */
+-  if (impl-server_surface == impl-cairo_surface)
+-return;
+-
+   /* The wayland surface is attached to a buffer that is from the old drawn
+* to surface. Unref the surface and restore the state.
+*/
+-- 
+1.7.10.4
+
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
index b9d4091..d92d8f3 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
@@ -3,7 +3,8 @@ require gtk+3.inc
 MAJ_VER = ${@oe.utils.trim_version(${PV}, 2)}
 
 SRC_URI = http://download.gnome.org/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz 
\
-   file://no-x11-in-wayland.patch
+   file://no-x11-in-wayland.patch \
+   file://wayland-attach.patch
 
 SRC_URI[md5sum] = 8e878e18fc385f2b813419dc7b40a968
 SRC_URI[sha256sum] = 
1ca80c9c15a1df95d74cefb8c2afe4682ba272a4b489106f04877be2a7aff297
-- 
1.7.10.4

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

[OE-core] [PATCH 0/7] Wayland updates

Hi,

Another revision of this branch with more improvements and Weston 1.1 (now that
the GTK+ issue was resolved).

Ross

The following changes since commit ea281d3b8e5f2ae21b37ea2ad4d440bf9c6427ff:

  bitbake: Added distroy signal to information dialogs (2013-05-31 08:25:40 
+0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ross/wayland

for you to fetch changes up to 299fde808fbdca44b396fc35f0df196cad73dec9:

  weston: update to 1.1.0 (2013-05-31 16:02:43 +0100)


Ross Burton (7):
  mesa: upgrade to 9.1.3
  mesa: update git recipe to 9.1.3 release
  wayland: update to 1.1.0
  weston: install the examples into weston-examples
  weston: add a weston-launch group
  weston: clean up and add comments
  weston: update to 1.1.0

 meta/recipes-graphics/mesa/mesa-9.0.2.inc  |   13 -
 meta/recipes-graphics/mesa/mesa-git.inc|9 +-
 .../mesa/mesa/0002-cross-compile.patch |   94 ---
 ...ate-NativeDisplayType-depending-on-config.patch |  358 +++
 meta/recipes-graphics/mesa/mesa/cross-glsl.patch   |  632 
 .../mesa/dont-fail-if-libX11-isnt-installed.patch  |   36 --
 .../fix-egl-compilation-without-x11-headers.patch  |   32 -
 .../mesa/mesa/fix-glsl-cross.patch |   43 ++
 meta/recipes-graphics/mesa/mesa_9.0.2.bb   |4 -
 meta/recipes-graphics/mesa/mesa_9.1.3.bb   |   14 +
 .../wayland/{wayland_1.0.6.bb = wayland_1.1.0.bb} |6 +-
 .../wayland/weston/install-examples.patch  |   18 +
 .../wayland/{weston_1.0.6.bb = weston_1.1.0.bb}   |   38 +-
 13 files changed, 471 insertions(+), 826 deletions(-)
 delete mode 100644 meta/recipes-graphics/mesa/mesa-9.0.2.inc
 delete mode 100644 meta/recipes-graphics/mesa/mesa/0002-cross-compile.patch
 create mode 100644 
meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
 delete mode 100644 meta/recipes-graphics/mesa/mesa/cross-glsl.patch
 delete mode 100644 
meta/recipes-graphics/mesa/mesa/dont-fail-if-libX11-isnt-installed.patch
 delete mode 100644 
meta/recipes-graphics/mesa/mesa/fix-egl-compilation-without-x11-headers.patch
 create mode 100644 meta/recipes-graphics/mesa/mesa/fix-glsl-cross.patch
 delete mode 100644 meta/recipes-graphics/mesa/mesa_9.0.2.bb
 create mode 100644 meta/recipes-graphics/mesa/mesa_9.1.3.bb
 rename meta/recipes-graphics/wayland/{wayland_1.0.6.bb = wayland_1.1.0.bb} 
(91%)
 create mode 100644 meta/recipes-graphics/wayland/weston/install-examples.patch
 rename meta/recipes-graphics/wayland/{weston_1.0.6.bb = weston_1.1.0.bb} (63%)

Ross Burton (7):
  mesa: upgrade to 9.1.3
  mesa: update git recipe to 9.1.3 release
  wayland: update to 1.1.0
  weston: install the examples into weston-examples
  weston: add a weston-launch group
  weston: clean up and add comments
  weston: update to 1.1.0

 meta/recipes-graphics/mesa/mesa-9.0.2.inc  |   13 -
 meta/recipes-graphics/mesa/mesa-git.inc|9 +-
 .../mesa/mesa/0002-cross-compile.patch |   94 ---
 ...ate-NativeDisplayType-depending-on-config.patch |  358 +++
 meta/recipes-graphics/mesa/mesa/cross-glsl.patch   |  632 
 .../mesa/dont-fail-if-libX11-isnt-installed.patch  |   36 --
 .../fix-egl-compilation-without-x11-headers.patch  |   32 -
 .../mesa/mesa/fix-glsl-cross.patch |   43 ++
 meta/recipes-graphics/mesa/mesa_9.0.2.bb   |4 -
 meta/recipes-graphics/mesa/mesa_9.1.3.bb   |   14 +
 .../wayland/{wayland_1.0.6.bb = wayland_1.1.0.bb} |6 +-
 .../wayland/weston/install-examples.patch  |   18 +
 .../wayland/{weston_1.0.6.bb = weston_1.1.0.bb}   |   38 +-
 13 files changed, 471 insertions(+), 826 deletions(-)
 delete mode 100644 meta/recipes-graphics/mesa/mesa-9.0.2.inc
 delete mode 100644 meta/recipes-graphics/mesa/mesa/0002-cross-compile.patch
 create mode 100644 
meta/recipes-graphics/mesa/mesa/EGL-Mutate-NativeDisplayType-depending-on-config.patch
 delete mode 100644 meta/recipes-graphics/mesa/mesa/cross-glsl.patch
 delete mode 100644 
meta/recipes-graphics/mesa/mesa/dont-fail-if-libX11-isnt-installed.patch
 delete mode 100644 
meta/recipes-graphics/mesa/mesa/fix-egl-compilation-without-x11-headers.patch
 create mode 100644 meta/recipes-graphics/mesa/mesa/fix-glsl-cross.patch
 delete mode 100644 meta/recipes-graphics/mesa/mesa_9.0.2.bb
 create mode 100644 meta/recipes-graphics/mesa/mesa_9.1.3.bb
 rename meta/recipes-graphics/wayland/{wayland_1.0.6.bb = wayland_1.1.0.bb} 
(91%)
 create mode 100644 meta/recipes-graphics/wayland/weston/install-examples.patch
 rename meta/recipes-graphics/wayland/{weston_1.0.6.bb = weston_1.1.0.bb} (63%)

-- 
1.7.10.4

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

[OE-core] [PATCH 2/7] mesa: update git recipe to 9.1.3 release

It's not bleeding edge but it's better than the previous pre-9.1 commit.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-graphics/mesa/mesa-git.inc |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-git.inc 
b/meta/recipes-graphics/mesa/mesa-git.inc
index ee9a552..c5507ce 100644
--- a/meta/recipes-graphics/mesa/mesa-git.inc
+++ b/meta/recipes-graphics/mesa/mesa-git.inc
@@ -1,11 +1,12 @@
-# Current pre-9.1 commit
-SRCREV = 1665af3066f3d58c42e9d5b13098f13615a7672c
-PV = 9.1~git${SRCPV}
+# 9.1.3 commit
+SRCREV = f32ec82a8cfcabc5b7596796f36afe7986651f02
+PV = 9.1.3+git${SRCPV}
 
 LIC_FILES_CHKSUM = 
file://docs/license.html;md5=42d77d95cba529a3637129be87d6555d
 
 SRC_URI = git://anongit.freedesktop.org/git/mesa/mesa;protocol=git \
-   file://0002-cross-compile.patch \
+   file://EGL-Mutate-NativeDisplayType-depending-on-config.patch \
+   file://fix-glsl-cross.patch \

 
 S = ${WORKDIR}/git
-- 
1.7.10.4

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

[OE-core] [PATCH 3/7] wayland: update to 1.1.0

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 .../wayland/{wayland_1.0.6.bb = wayland_1.1.0.bb}   |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)
 rename meta/recipes-graphics/wayland/{wayland_1.0.6.bb = wayland_1.1.0.bb} 
(91%)

diff --git a/meta/recipes-graphics/wayland/wayland_1.0.6.bb 
b/meta/recipes-graphics/wayland/wayland_1.1.0.bb
similarity index 91%
rename from meta/recipes-graphics/wayland/wayland_1.0.6.bb
rename to meta/recipes-graphics/wayland/wayland_1.1.0.bb
index 7c18979..a71402e 100644
--- a/meta/recipes-graphics/wayland/wayland_1.0.6.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.1.0.bb
@@ -10,11 +10,9 @@ LICENSE = MIT
 LIC_FILES_CHKSUM = file://COPYING;md5=1d4476a7d98dd5691c53d4d43a510c72 \
 
file://src/wayland-server.c;endline=21;md5=079ae21dbf98ada52ec23744851b0a5c
 
-PR = r1
-
 SRC_URI = http://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz;
-SRC_URI[md5sum] = 936a2590aea69fa3c0cf234d54b9137c
-SRC_URI[sha256sum] = 
f52a012df699eff434b0f49e56000d6978b5f781048402ca8e0232242970fc49
+SRC_URI[md5sum] = d2dc9398a83692cafc16eba6e45f85d8
+SRC_URI[sha256sum] = 
2ef587cf1a0e52b6dee44eeb9c288110e8180819abf4e419d247dfe234867a5c
 
 SRC_URI_append_class-native =  file://just-scanner.patch
 
-- 
1.7.10.4

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

[OE-core] [PATCH 4/7] weston: install the examples into weston-examples

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 .../wayland/weston/install-examples.patch|   18 ++
 meta/recipes-graphics/wayland/weston_1.0.6.bb|6 +-
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-graphics/wayland/weston/install-examples.patch

diff --git a/meta/recipes-graphics/wayland/weston/install-examples.patch 
b/meta/recipes-graphics/wayland/weston/install-examples.patch
new file mode 100644
index 000..3e2852c
--- /dev/null
+++ b/meta/recipes-graphics/wayland/weston/install-examples.patch
@@ -0,0 +1,18 @@
+Install the examples so we can package them.
+
+Upstream-Status: Pending
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+diff --git a/clients/Makefile.am b/clients/Makefile.am
+index 621c7c3..749ef20 100644
+--- a/clients/Makefile.am
 b/clients/Makefile.am
+@@ -2,7 +2,7 @@ bin_PROGRAMS = \
+   weston-info \
+   $(terminal)
+ 
+-noinst_PROGRAMS = \
++bin_PROGRAMS +=   \
+   $(clients_programs) \
+   $(poppler_programs) \
+   $(simple_clients_programs)  \
diff --git a/meta/recipes-graphics/wayland/weston_1.0.6.bb 
b/meta/recipes-graphics/wayland/weston_1.0.6.bb
index cb41e05..dd17c03 100644
--- a/meta/recipes-graphics/wayland/weston_1.0.6.bb
+++ b/meta/recipes-graphics/wayland/weston_1.0.6.bb
@@ -6,6 +6,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=275efac2559a224527bd4fd593d38466 \
 
file://src/compositor.c;endline=23;md5=aa98a8db03480fe7d500d0b1f4b8850c
 
 SRC_URI = http://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
+   file://install-examples.patch \
file://weston.png \
file://weston.desktop
 SRC_URI[md5sum] = 63202129d66d5514e572814da5dfa1f7
@@ -49,7 +50,10 @@ do_install_append() {
done
 }
 
-FILES_${PN} += ${datadir}/applications ${datadir}/icons
+PACKAGES += ${PN}-examples
+
+FILES_${PN} = ${bindir}/weston* ${bindir}/wcap-decode ${libexecdir} 
${datadir}
+FILES_${PN}-examples = ${bindir}/*
 
 RDEPENDS_${PN} += xkeyboard-config
 RRECOMMENDS_${PN} = liberation-fonts
-- 
1.7.10.4

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

[OE-core] [dylan][PATCH 00/15] Stable branch cherry-picks (cover letter only)

These are cherry-picks from master to be applied to the dylan branch for
inclusion in the next 1.4 stable release (1.4.1). They have been tested
on my build machine locally.

Please review this series for suitability for inclusion into the stable
branch.

The following changes since commit f24b4c3daeba43b352977fcdb807f1ed45c1c694:

  kern-tools: refresh and make dash compliant (2013-05-22 11:57:46 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/dylan-next
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/dylan-next

Bogdan Marinescu (1):
  guile: added runtime dependency on glibc-gconv-iso8859-1

Bruce Ashfield (1):
  qemu*: restrict NFSD to linux-yocto only

Jackie Huang (1):
  guile: don't search for libreadline in host libdir

Jesse Zhang (2):
  dbus-glib: use BPN instead of PN
  initscripts: let status return 0 when proc is running well

Jessica Zhang (1):
  Make toolchain output name using SDK_VERSION instead of DISTRO_VERSION
to be consistent [yocto #2342]

Jonathan Liu (3):
  systemd: fix ordering for machineid and run-postinsts services
  findutils: backport fixes for documentation build errors
  findutils: backport more fixes for documentation build errors

Ming Liu (1):
  dpkg-native: Fix native perl path

Nitin A Kamble (1):
  dropbear: a fix for hang in dropbearkey, built for x32

Paul Eggleton (1):
  python-smartpm: add gettext-native to DEPENDS

Richard Purdie (1):
  dpkg: Be deterministic about lzma dependency

Samuli Piippo (1):
  gdb-cross-canadian: use correct exec-prefix path for python

Xin Ouyang (1):
  qmake_base.bbclass: Add linux-gnun32-oe-g++ to QMAKESPEC

 meta/classes/populate_sdk_base.bbclass |   2 +-
 meta/classes/qmake_base.bbclass|   2 +-
 meta/conf/machine/include/qemu.inc |   2 +-
 meta/recipes-core/dbus/dbus-glib.inc   |   8 +-
 .../0007-dropbear-fix-for-x32-abi.patch| 140 +
 meta/recipes-core/dropbear/dropbear.inc|   1 +
 .../initscripts/initscripts-1.0/functions  |   1 +
 .../systemd/systemd-compat-units/machineid.service |   2 +-
 .../systemd-compat-units/run-postinsts.service |   2 +-
 meta/recipes-devtools/dpkg/dpkg.inc|   4 +
 meta/recipes-devtools/gdb/gdb-cross-canadian.inc   |   2 +-
 meta/recipes-devtools/guile/guile_2.0.7.bb |   4 +-
 .../python/python-smartpm_1.4.1.bb |   2 +-
 .../findutils-4.4.2/findutils_fix_doc.patch|  84 +
 meta/recipes-extended/findutils/findutils_4.4.2.bb |   1 +
 15 files changed, 245 insertions(+), 12 deletions(-)
 create mode 100644 
meta/recipes-core/dropbear/dropbear-2012.55/0007-dropbear-fix-for-x32-abi.patch
 create mode 100644 
meta/recipes-extended/findutils/findutils-4.4.2/findutils_fix_doc.patch

-- 
1.8.1.2

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

[OE-core] [PATCH 5/7] weston: add a weston-launch group

For weston-launch to be used by a non-root user, the user either needs to be a
member of the weston-launch group or own an active systemd user session.  Create
this group so users can be members of it.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-graphics/wayland/weston_1.0.6.bb |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/wayland/weston_1.0.6.bb 
b/meta/recipes-graphics/wayland/weston_1.0.6.bb
index dd17c03..07811f2 100644
--- a/meta/recipes-graphics/wayland/weston_1.0.6.bb
+++ b/meta/recipes-graphics/wayland/weston_1.0.6.bb
@@ -12,7 +12,7 @@ SRC_URI = 
http://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
 SRC_URI[md5sum] = 63202129d66d5514e572814da5dfa1f7
 SRC_URI[sha256sum] = 
c833bc4dc8667561d2639b57220541531c039aa9332ce2a7022a3c466eb894f1
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig useradd
 
 DEPENDS = libxkbcommon gdk-pixbuf pixman cairo glib-2.0 mtdev jpeg
 DEPENDS += wayland mesa virtual/egl
@@ -57,3 +57,6 @@ FILES_${PN}-examples = ${bindir}/*
 
 RDEPENDS_${PN} += xkeyboard-config
 RRECOMMENDS_${PN} = liberation-fonts
+
+USERADD_PACKAGES = ${PN}
+GROUPADD_PARAM_${PN} = --system weston-launch
-- 
1.7.10.4

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

[OE-core] [PATCH 6/7] weston: clean up and add comments

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-graphics/wayland/weston_1.0.6.bb |   14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/wayland/weston_1.0.6.bb 
b/meta/recipes-graphics/wayland/weston_1.0.6.bb
index 07811f2..9d5d626 100644
--- a/meta/recipes-graphics/wayland/weston_1.0.6.bb
+++ b/meta/recipes-graphics/wayland/weston_1.0.6.bb
@@ -17,14 +17,21 @@ inherit autotools pkgconfig useradd
 DEPENDS = libxkbcommon gdk-pixbuf pixman cairo glib-2.0 mtdev jpeg
 DEPENDS += wayland mesa virtual/egl
 
-EXTRA_OECONF  = --disable-android-compositor --enable-setuid-install
-EXTRA_OECONF += --disable-tablet-shell --disable-xwayland
-EXTRA_OECONF += --enable-simple-clients --enable-clients 
--disable-simple-egl-clients
+EXTRA_OECONF = --disable-android-compositor \
+--enable-setuid-install \
+--disable-tablet-shell \
+--disable-xwayland \
+--enable-simple-clients \
+--enable-clients \
+--disable-simple-egl-clients
 
 PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms 
wayland', '', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} \
${@base_contains('DISTRO_FEATURES', 'opengles2', 'gles', 
'', d)} \
   
+#
+# Compositor choices
+#
 # Weston on KMS
 PACKAGECONFIG[kms] = --enable-drm-compositor 
--enable-weston-launch,--disable-drm-compositor --disable-weston-launch,drm 
udev mesa libpam
 # Weston on Wayland (nested Weston)
@@ -32,6 +39,7 @@ PACKAGECONFIG[wayland] = 
--enable-wayland-compositor,--disable-wayland-composit
 # Weston on X11
 PACKAGECONFIG[x11] = 
--enable-x11-compositor,--disable-x11-compositor,virtual/libx11 libxcb libxcb 
libxcursor cairo
 
+# Use cairo-gl or cairo-glesv2
 PACKAGECONFIG[gles] = --with-cairo-glesv2,,virtual/libgles2
 
 do_install_append() {
-- 
1.7.10.4

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

[OE-core] [PATCH 7/7] weston: update to 1.1.0

Upgrade to 1.1.0, and disable the RaspberryPi and RDP compositors.  Hopefully
the RPi community can send a patch to add a PACKAGECONFIG for them.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 .../wayland/{weston_1.0.6.bb = weston_1.1.0.bb}|   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)
 rename meta/recipes-graphics/wayland/{weston_1.0.6.bb = weston_1.1.0.bb} (82%)

diff --git a/meta/recipes-graphics/wayland/weston_1.0.6.bb 
b/meta/recipes-graphics/wayland/weston_1.1.0.bb
similarity index 82%
rename from meta/recipes-graphics/wayland/weston_1.0.6.bb
rename to meta/recipes-graphics/wayland/weston_1.1.0.bb
index 9d5d626..026f136 100644
--- a/meta/recipes-graphics/wayland/weston_1.0.6.bb
+++ b/meta/recipes-graphics/wayland/weston_1.1.0.bb
@@ -9,8 +9,9 @@ SRC_URI = 
http://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
file://install-examples.patch \
file://weston.png \
file://weston.desktop
-SRC_URI[md5sum] = 63202129d66d5514e572814da5dfa1f7
-SRC_URI[sha256sum] = 
c833bc4dc8667561d2639b57220541531c039aa9332ce2a7022a3c466eb894f1
+SRC_URI[md5sum] = dd9f3043fc5228c6bc4e99873fae2254
+SRC_URI[sha256sum] = 
e7715d2c731f77a729c994a599ffdaebac1307b2dd9336136706869fa53618b4
+
 
 inherit autotools pkgconfig useradd
 
@@ -23,7 +24,11 @@ EXTRA_OECONF = --disable-android-compositor \
 --disable-xwayland \
 --enable-simple-clients \
 --enable-clients \
---disable-simple-egl-clients
+--disable-simple-egl-clients \
+--disable-libunwind \
+--disable-rpi-compositor \
+--disable-rdp-compositor
+
 
 PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'wayland', 'kms 
wayland', '', d)} \
${@base_contains('DISTRO_FEATURES', 'x11', 'x11', '', d)} \
@@ -38,6 +43,10 @@ PACKAGECONFIG[kms] = --enable-drm-compositor 
--enable-weston-launch,--disable-d
 PACKAGECONFIG[wayland] = 
--enable-wayland-compositor,--disable-wayland-compositor,mesa
 # Weston on X11
 PACKAGECONFIG[x11] = 
--enable-x11-compositor,--disable-x11-compositor,virtual/libx11 libxcb libxcb 
libxcursor cairo
+# Headless Weston
+PACKAGECONFIG[headless] = 
--enable-headless-compositor,--disable-headless-compositor
+# Weston on framebuffer
+PACKAGECONFIG[fbdev] = 
--enable-fbdev-compositor,--disable-fbdev-compositor,udev mtdev
 
 # Use cairo-gl or cairo-glesv2
 PACKAGECONFIG[gles] = --with-cairo-glesv2,,virtual/libgles2
-- 
1.7.10.4

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

Re: [OE-core] Issues with gcc 4.8 sstate contamination on the autobuilder


On 5/30/13 12:22 PM, Marcin Juszkiewicz wrote:

W dniu 30.05.2013 18:45, Richard Purdie pisze:

I want to make people aware we're seeing some issues with gcc 4.8 on the
autobuilder.


When we are at sstate and gcc...

I noticed recently that libunwind may break gcc builds:

https://bugs.launchpad.net/linaro-oe/+bug/1183087

The issue exists only when libunwind was built before gcc was started.

To reproduce:

bitbake -ccleansstate gcc libunwind
bitbake libunwind
bitbake gcc

Did not yet found proper working solution.


Just an FYI -- I've reproduced the same issue here for an qemux86_64 machine 
using stock oe-core.


(Similarly, I don't have a solution either.)


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



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

Re: [OE-core] Issues with gcc 4.8 sstate contamination on the autobuilder


On 5/31/13 10:12 AM, Mark Hatle wrote:

On 5/30/13 12:22 PM, Marcin Juszkiewicz wrote:

W dniu 30.05.2013 18:45, Richard Purdie pisze:

I want to make people aware we're seeing some issues with gcc 4.8 on the
autobuilder.


When we are at sstate and gcc...

I noticed recently that libunwind may break gcc builds:

https://bugs.launchpad.net/linaro-oe/+bug/1183087

The issue exists only when libunwind was built before gcc was started.

To reproduce:

bitbake -ccleansstate gcc libunwind
bitbake libunwind
bitbake gcc

Did not yet found proper working solution.


Just an FYI -- I've reproduced the same issue here for an qemux86_64 machine
using stock oe-core.

(Similarly, I don't have a solution either.)


Forgot to add in my case the sstate cache had nothing to do with it.  If 
libunwind is built first, then gcc appears to fail.  Cleaning both and 
rebuilding gcc caused it to work.


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

[OE-core] [RFC PATCH] gcc: Workaround for compiler flag mismatch

When cross compiling the target compiler, both the cross-compiler
and the host compiler are used.  However, the -W options used were
discovered from the cross-compiler and may be incompatible with the
host compiler.

Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
 meta/recipes-devtools/gcc/gcc-4.8.inc  |  1 +
 .../gcc/gcc-4.8/gcc-4.8-build-args.patch   | 51 ++
 2 files changed, 52 insertions(+)
 create mode 100644 meta/recipes-devtools/gcc/gcc-4.8/gcc-4.8-build-args.patch

diff --git a/meta/recipes-devtools/gcc/gcc-4.8.inc 
b/meta/recipes-devtools/gcc/gcc-4.8.inc
index a9786da..80bd02c 100644
--- a/meta/recipes-devtools/gcc/gcc-4.8.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.8.inc
@@ -66,6 +66,7 @@ SRC_URI = ${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
   
file://0034-Use-the-multilib-config-files-from-B-instead-of-usin.patch \
   file://0035-wcast-qual-PR-55383.patch \
   file://gcc-4.8-PR56797.patch \
+  file://gcc-4.8-build-args.patch \
  
 SRC_URI[md5sum] = e6040024eb9e761c3bea348d1fa5abb0
 SRC_URI[sha256sum] = 
b037fe5132b71ecad2ea7141ec92292b5d32427bf90fd90cde432b1d5abacc2c
diff --git a/meta/recipes-devtools/gcc/gcc-4.8/gcc-4.8-build-args.patch 
b/meta/recipes-devtools/gcc/gcc-4.8/gcc-4.8-build-args.patch
new file mode 100644
index 000..95f39bb
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.8/gcc-4.8-build-args.patch
@@ -0,0 +1,51 @@
+When cross compiling a target gcc, target flags may be used on the host
+
+Configure identifies a number of warning flags (WARN_CFLAGS and 
+WARN_CXXFLAGS) from the $CC value.  The cross compiler may be different
+from the host compiler and may not support the same set of flags.  This
+leads to problems such as:
+
+cc1plus: error: unrecognized command line option -Wno-narrowing
+cc1plus: error: unrecognized command line option -Wno-overlength-strings
+
+Work around this problem by removing the warning flags from the
+BUILD_*FLAGS values.
+
+Upstream-Status: Pending
+
+Signed-off-by: Mark Hatle mark.ha...@windriver.com
+
+diff -ur gcc-4.8.0.orig/gcc/configure.ac gcc-4.8.0/gcc/configure.ac
+--- gcc-4.8.0.orig/gcc/configure.ac2013-05-29 14:44:24.960853593 -0500
 gcc-4.8.0/gcc/configure.ac 2013-05-31 01:34:09.518775962 -0500
+@@ -1892,8 +1892,8 @@
+ # These are the normal (build=host) settings:
+ CC_FOR_BUILD='$(CC)'  AC_SUBST(CC_FOR_BUILD)
+ CXX_FOR_BUILD='$(CXX)'AC_SUBST(CXX_FOR_BUILD)
+-BUILD_CFLAGS='$(ALL_CFLAGS)'  AC_SUBST(BUILD_CFLAGS)
+-BUILD_CXXFLAGS='$(ALL_CXXFLAGS)' AC_SUBST(BUILD_CXXFLAGS)
++BUILD_CFLAGS='$(ALL_BUILD_CFLAGS)'AC_SUBST(BUILD_CFLAGS)
++BUILD_CXXFLAGS='$(ALL_BUILD_CXXFLAGS)' AC_SUBST(BUILD_CXXFLAGS)
+ BUILD_LDFLAGS='$(LDFLAGS)'AC_SUBST(BUILD_LDFLAGS)
+ STMP_FIXINC=stmp-fixinc   AC_SUBST(STMP_FIXINC)
+ 
+diff -ur gcc-4.8.0.orig/gcc/Makefile.in gcc-4.8.0/gcc/Makefile.in
+--- gcc-4.8.0.orig/gcc/Makefile.in 2013-05-29 14:44:24.369853593 -0500
 gcc-4.8.0/gcc/Makefile.in  2013-05-31 01:34:30.360776427 -0500
+@@ -989,10 +989,16 @@
+ ALL_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \
+   $(CFLAGS) $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS) @DEFS@
+ 
++ALL_BUILD_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \
++  $(CFLAGS) $(INTERNAL_CFLAGS) @DEFS@
++
+ # The C++ version.
+ ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \
+   $(COVERAGE_FLAGS) $(NOEXCEPTION_FLAGS) $(WARN_CXXFLAGS) @DEFS@
+ 
++ALL_BUILD_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \
++  $(NOEXCEPTION_FLAGS) @DEFS@
++
+ # Likewise.  Put INCLUDES at the beginning: this way, if some autoconf macro
+ # puts -I options in CPPFLAGS, our include files in the srcdir will always
+ # win against random include files in /usr/include.
-- 
1.8.3.rc1.25.g423ecb0

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

[OE-core] [PATCH] util-linux: Add support for older hosts

Older hosts don't support some of the features required by
the latet util-linux.  Add workarounds or revert changes to older
versions to make it work.

Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
 .../util-linux/util-linux/util-linux-native.patch  | 210 +
 meta/recipes-core/util-linux/util-linux_2.23.bb|   6 +
 2 files changed, 216 insertions(+)
 create mode 100644 
meta/recipes-core/util-linux/util-linux/util-linux-native.patch

diff --git a/meta/recipes-core/util-linux/util-linux/util-linux-native.patch 
b/meta/recipes-core/util-linux/util-linux/util-linux-native.patch
new file mode 100644
index 000..9f34497
--- /dev/null
+++ b/meta/recipes-core/util-linux/util-linux/util-linux-native.patch
@@ -0,0 +1,210 @@
+Support older hosts with latest util-linux-native
+
+mkostemp is not defined on older machines.  So we detect this and
+provide a define that uses mkstemp instead.
+
+O_CLOEXEC is not defined on older machines.  It is however defined
+in the 'c.h' header.  Fix up the users to include 'c.h'.
+
+fdisks/fdisksunlabel.c was modified to use qsort_r, however
+this is not defined on older hosts.  Revert:
+  commit c69bbca9c1f6645097bd20fe3a21f5a99a2a0698
+  fdisk: (sun): use ask API, remove global variable
+
+Upstream-status: Inappropriate [other]
+Patches revert upstream changes in order to support older
+machines.
+
+Signed-off-by: Mark Hatle mark.ha...@windriver.com
+
+diff -ur util-linux-2.23/configure.ac 
/home/lmhatle/util-linux-2.23-fixed/configure.ac
+--- util-linux-2.23/configure.ac   2013-05-29 14:44:35.147853585 -0500
 /home/lmhatle/util-linux-2.23-fixed/configure.ac   2013-05-30 
14:56:15.050799650 -0500
+@@ -323,6 +323,7 @@
+   llseek \
+   lseek64 \
+   mempcpy \
++  mkostemp \
+   nanosleep \
+   personality \
+   posix_fadvise \
+diff -ur util-linux-2.23/include/c.h 
/home/lmhatle/util-linux-2.23-fixed/include/c.h
+--- util-linux-2.23/include/c.h2013-04-12 04:25:46.852156874 -0500
 /home/lmhatle/util-linux-2.23-fixed/include/c.h2013-05-30 
14:56:11.310799488 -0500
+@@ -236,6 +236,13 @@
+ #endif
+ 
+ /*
++ * mkostemp replacement
++ */
++#ifndef HAVE_MKOSTEMP
++#define mkostemp(template, flags) mkstemp(template)
++#endif
++
++/*
+  * MAXHOSTNAMELEN replacement
+  */
+ static inline size_t get_hostname_max(void)
+diff -ur util-linux-2.23/lib/randutils.c 
/home/lmhatle/util-linux-2.23-fixed/lib/randutils.c
+--- util-linux-2.23/lib/randutils.c2013-04-12 04:25:46.855156901 -0500
 /home/lmhatle/util-linux-2.23-fixed/lib/randutils.c2013-05-30 
14:55:26.622799644 -0500
+@@ -16,6 +16,7 @@
+ #include sys/syscall.h
+ 
+ #include randutils.h
++#include c.h
+ 
+ #ifdef HAVE_TLS
+ #define THREAD_LOCAL static __thread
+diff -ur util-linux-2.23/lib/wholedisk.c 
/home/lmhatle/util-linux-2.23-fixed/lib/wholedisk.c
+--- util-linux-2.23/lib/wholedisk.c2013-04-12 04:25:46.855156901 -0500
 /home/lmhatle/util-linux-2.23-fixed/lib/wholedisk.c2013-05-30 
14:55:31.182799350 -0500
+@@ -10,6 +10,7 @@
+ 
+ #include blkdev.h
+ #include wholedisk.h
++#include c.h
+ 
+ int is_whole_disk_fd(int fd, const char *name)
+ {
+diff -ur util-linux-2.23/fdisks/fdisksunlabel.c 
/home/lmhatle/util-linux-2.23-fixed/fdisks/fdisksunlabel.c
+--- util-linux-2.23/fdisks/fdisksunlabel.c 2013-04-23 09:14:19.229015244 
-0500
 /home/lmhatle/util-linux-2.23-fixed/fdisks/fdisksunlabel.c 2013-05-30 
14:54:55.978799735 -0500
+@@ -383,10 +383,10 @@
+   }
+ }
+ 
+-static int verify_sun_cmp(int *a, int *b, void *data)
+-{
+-unsigned int *verify_sun_starts = (unsigned int *) data;
++static unsigned int *verify_sun_starts;
+ 
++static int verify_sun_cmp(int *a, int *b)
++{
+ if (*a == -1)
+   return 1;
+ if (*b == -1)
+@@ -401,7 +401,6 @@
+ uint32_t starts[SUN_MAXPARTITIONS], lens[SUN_MAXPARTITIONS], start, stop;
+ uint32_t i,j,k,starto,endo;
+ int array[SUN_MAXPARTITIONS];
+-unsigned int *verify_sun_starts;
+ 
+ assert(cxt);
+ assert(cxt-label);
+@@ -442,16 +441,14 @@
+   }
+   }
+ }
+-
+ for (i = 0; i  SUN_MAXPARTITIONS; i++) {
+ if (lens[i])
+ array[i] = i;
+ else
+ array[i] = -1;
+ }
+-qsort_r(array,ARRAY_SIZE(array),sizeof(array[0]),
+-(int (*)(const void *,const void *,void *)) verify_sun_cmp,
+-verify_sun_starts);
++qsort(array,ARRAY_SIZE(array),sizeof(array[0]),
++(int (*)(const void *,const void *)) verify_sun_cmp);
+ 
+ if (array[0] == -1) {
+   fdisk_info(cxt, _(No partitions defined));
+@@ -468,6 +465,7 @@
+ start = (starts[array[i]] + lens[array[i]]);
+ if (start  stop)
+ fdisk_warnx(cxt, _(Unused gap - sectors %d-%d), start, stop);
++
+ return 0;
+ }
+ 
+@@ -746,18 +744,12 @@
+   }
+ }
+ 
+-
+ void fdisk_sun_set_alt_cyl(struct fdisk_context *cxt)
+ {
+   struct sun_disklabel *sunlabel = self_disklabel(cxt);
+-  uintmax_t res;
+-

[OE-core] [PATCH 04/11] gtk+3: explicitly disable introspection

If someone is/has been using meta-gir then it's possible for this floating
option to become enabled.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb |1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
index 3c03add..9bd5b9d 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.8.2.bb
@@ -43,6 +43,7 @@ EXTRA_OECONF +=  \
  --disable-xinerama \
  --enable-modules \
  --disable-cups \
+ --disable-introspection \
 
 
 do_install_append() {
-- 
1.7.10.4

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

Re: [OE-core] [RFC] get minimal rootfs to be even smaller

W dniu 31.05.2013 16:41, Phil Blundell pisze:
 On Fri, 2013-05-31 at 16:11 +0200, Marcin Juszkiewicz wrote:
 Next one can be ldconfig which is ~600KB.
 
 There's already an option to turn that off: you can set 
 USE_LDCONFIG=0 in your distro configuration (which micro does, for 
 example). Converting that to be a modern DISTRO_FEATURE would be a 
 fine thing.

Thanks for hint - may look at it next week.

 On the udev thing I guess my initial reaction would be that if you 
 want the smallest rootfs you probably don't want to be using udev at 
 all.

I just wanted to have smallest possible image without doing any distro
config changes. Think minimal image for testing KVM where KVM host
rootfs can be built with same setup.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] gcc 4.7/gcc 4.8 fails when libunwind is built first

Recently Marcin Juszkiewicz reported an issues w/ gcc 4.8 when libunwind
was built first.  This sounded familar when I encountered the same problem.

Back in February Roy Li found the same problem w/ gcc_4.7 and submitted a
fix for the issue.  I've updated this fix for both gcc 4.7 and gcc 4.8.

I tested this and it does resolve the issue for me.

Roy.Li (1):
  gcc: add build directory to include directories

 meta/recipes-devtools/gcc/gcc_4.7.bb | 2 +-
 meta/recipes-devtools/gcc/gcc_4.8.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.8.3.rc1.25.g423ecb0

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

[OE-core] [PATCH] gcc: add build directory to include directories

From: Roy.Li rongqing...@windriver.com

[ CQID: WIND00386962 ]

Add build directory to include directories by -I${B}/include which will
be searched before standard system include directories.

Both libunwind and gcc supply unwind.h, once gcc use libunwind's unwind.h,
the compiling will fail.

This patch is generally not applicable to the upstream as they do not
use libunwind.

(LOCAL REV: NOT UPSTREAM)

Signed-off-by: Roy.Li rongqing...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
 meta/recipes-devtools/gcc/gcc_4.7.bb | 2 +-
 meta/recipes-devtools/gcc/gcc_4.8.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc_4.7.bb 
b/meta/recipes-devtools/gcc/gcc_4.7.bb
index 9954375..f68c67a 100644
--- a/meta/recipes-devtools/gcc/gcc_4.7.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.7.bb
@@ -2,4 +2,4 @@ require recipes-devtools/gcc/gcc-${PV}.inc
 require gcc-configure-target.inc
 require gcc-package-target.inc
 
-ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR}
+ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR} -I${B}/gcc/include/ 
diff --git a/meta/recipes-devtools/gcc/gcc_4.8.bb 
b/meta/recipes-devtools/gcc/gcc_4.8.bb
index 9954375..f68c67a 100644
--- a/meta/recipes-devtools/gcc/gcc_4.8.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.8.bb
@@ -2,4 +2,4 @@ require recipes-devtools/gcc/gcc-${PV}.inc
 require gcc-configure-target.inc
 require gcc-package-target.inc
 
-ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR}
+ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR} -I${B}/gcc/include/ 
-- 
1.8.3.rc1.25.g423ecb0

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

[OE-core] [PATCH v2] gcc: add build directory to include directories

From: Roy.Li rongqing...@windriver.com

Add build directory to include directories by -I${B}/include which will
be searched before standard system include directories.

Both libunwind and gcc supply unwind.h, once gcc use libunwind's unwind.h,
the compiling will fail.

This patch is generally not applicable to the upstream as they do not
use libunwind.

Signed-off-by: Roy.Li rongqing...@windriver.com
Signed-off-by: Jeff Polk jeff.p...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
 meta/recipes-devtools/gcc/gcc_4.7.bb | 2 +-
 meta/recipes-devtools/gcc/gcc_4.8.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc_4.7.bb 
b/meta/recipes-devtools/gcc/gcc_4.7.bb
index 9954375..f68c67a 100644
--- a/meta/recipes-devtools/gcc/gcc_4.7.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.7.bb
@@ -2,4 +2,4 @@ require recipes-devtools/gcc/gcc-${PV}.inc
 require gcc-configure-target.inc
 require gcc-package-target.inc
 
-ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR}
+ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR} -I${B}/gcc/include/ 
diff --git a/meta/recipes-devtools/gcc/gcc_4.8.bb 
b/meta/recipes-devtools/gcc/gcc_4.8.bb
index 9954375..f68c67a 100644
--- a/meta/recipes-devtools/gcc/gcc_4.8.bb
+++ b/meta/recipes-devtools/gcc/gcc_4.8.bb
@@ -2,4 +2,4 @@ require recipes-devtools/gcc/gcc-${PV}.inc
 require gcc-configure-target.inc
 require gcc-package-target.inc
 
-ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR}
+ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR} -I${B}/gcc/include/ 
-- 
1.8.3.rc1.25.g423ecb0

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

[OE-core] [PATCH 1/1 V2] lrzsz: check locale.h in configure

From: Jackie Huang jackie.hu...@windriver.com

fix the build failure:
lrz.c:284:13: error: 'LC_ALL' undeclared (first use in this function)

Signed-off-by: Jackie Huang jackie.hu...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
 .../lrzsz/lrzsz-0.12.20/lrzsz-check-locale.h.patch | 32 ++
 meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb|  3 +-
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-bsp/lrzsz/lrzsz-0.12.20/lrzsz-check-locale.h.patch

diff --git a/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/lrzsz-check-locale.h.patch 
b/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/lrzsz-check-locale.h.patch
new file mode 100644
index 000..9e46dfa
--- /dev/null
+++ b/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/lrzsz-check-locale.h.patch
@@ -0,0 +1,32 @@
+From 28b473c3c96682a820e292cc1be006e19aee11bc Mon Sep 17 00:00:00 2001
+From: Jackie Huang jackie.hu...@windriver.com
+Date: Fri, 24 May 2013 01:07:24 -0400
+Subject: [PATCH] lrzsz check locale.h
+
+fix the build failure when using -O0 in a debug build:
+lrz.c:284:13: error: 'LC_ALL' undeclared (first use in this function)
+
+Upstream-Status: Submitted [u...@ohse.de]
+
+Signed-off-by: Jackie Huang jackie.hu...@windriver.com
+Signed-off-by: Mark Hatle mark.ha...@windriver.com
+---
+ configure.in |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.in b/configure.in
+index 6e2064c..c10460c 100644
+--- a/configure.in
 b/configure.in
+@@ -130,7 +130,7 @@ AC_CHECK_HEADERS(fcntl.h limits.h sys/ioctl.h sys/time.h 
unistd.h sys/times.h)
+ LRZSZ_HEADERS_TERM_IO
+ AC_CHECK_HEADERS(termios.h sys/termios.h termio.h sys/termio.h sgtty.h)
+ AC_CHECK_HEADERS(sys/mman.h utime.h syslog.h sys/syslog.h sys/param.h)
+-AC_CHECK_HEADERS(sys/select.h strings.h arpa/inet.h)
++AC_CHECK_HEADERS(sys/select.h strings.h locale.h arpa/inet.h)
+ 
+ dnl Checks for typedefs, structures, and compiler characteristics.
+ AC_TYPE_SIZE_T
+-- 
+1.7.9.5
+
diff --git a/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb 
b/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
index 83a75e3..0147b3d 100644
--- a/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
+++ b/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
@@ -10,13 +10,14 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \

file://src/lrz.c;beginline=1;endline=10;md5=5276956373ff7d8758837f6399a1045f
 SECTION = console/network
 DEPENDS = 
-PR = r5
+PR = r6
 
 SRC_URI = http://www.ohse.de/uwe/releases/lrzsz-${PV}.tar.gz \
   file://autotools.patch \
   file://makefile.patch \
   file://gettext.patch \
   file://lrzsz_fix_for_automake-1.12.patch \
+   file://lrzsz-check-locale.h.patch \

 
 SRC_URI[md5sum] = b5ce6a74abc9b9eb2af94dffdfd372a4
-- 
1.8.3.rc1.25.g423ecb0

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

Re: [OE-core] [PATCH] gcc: add build directory to include directories

W dniu 31.05.2013 17:54, Mark Hatle pisze:
 From: Roy.Li rongqing...@windriver.com
 
 [ CQID: WIND00386962 ]
 
 Add build directory to include directories by -I${B}/include which will
 be searched before standard system include directories.
 
 Both libunwind and gcc supply unwind.h, once gcc use libunwind's unwind.h,
 the compiling will fail.
 
 This patch is generally not applicable to the upstream as they do not
 use libunwind.
 
 (LOCAL REV: NOT UPSTREAM)
 
 Signed-off-by: Roy.Li rongqing...@windriver.com
 Signed-off-by: Jeff Polk jeff.p...@windriver.com
 Signed-off-by: Mark Hatle mark.ha...@windriver.com

Acked-by: Marcin Juszkiewicz mar...@juszkiewicz.com.pl

It works! Thanks a lot guys.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Stable Release Process

Hi Darren,

Sorry it's taken me so long to reply to this.

On Wednesday 24 April 2013 10:32:54 Darren Hart wrote:
 As the stable releases become first class citizens, we should probably
 look at streamlining the process of getting patches to them.
 
 The maintainer for the stable release currently changes by release,
 which undoubtedly creates some confusion of where to send patches and
 who to CC. These maintainers currently attempt to track these
 patches via email filters searching for release branch names and such,
 which is proving tedious and prone to missing patches.
 
 Other projects have seen good results using a stable list for this
 purpose. This would both make it obvious when a patch is intended for a
 stable release as well as remove any confusion about who to Cc as it
 would be the same list for all releases. Perhaps something like
 openembedded-core-sta...@lists.openembedded.org?

In the OE-Classic days we used to have an openembedded-stablebranch mailing 
list for the same purpose. I don't recall anyone complaining about that when 
we had it, so this sounds like it could help with the aforementioned issues.

The downside I can see is that it's one more mailing list with the associated 
problems of not everyone monitoring it (that patch of mine shouldn't have 
been backported! or you backported one of my patches but missed an 
associated one), and new users erroneously emailing it with requests for help 
that should have gone to the normal mailing list. That could however be 
outweighed by the advantage of stable branch patches not being drowned out by 
the rest of the patches as they currently can be.

 In addition to the list, some policy would need to be documented on how
 to use the list. For example, it should always be Cc'd, and never
 emailed with patches directly that don't go first to the master branch.
 Backports being the exception. A policy could also be put in place to
 aid in automatic processing, such as that employed by the Linux kernel
 stable project. The following would request that the patch be applied to
 the denzil and danny stable releases:
 
 Cc: openembedded-core-sta...@lists.openembedded.org # denzil
 Cc: openembedded-core-sta...@lists.openembedded.org # danny
 Signed-off-by: Darren Hart dvh...@linux.intel.com
 
 The advantage here over something like a subject tag, [danny] is that
 it scales a bit better to sending a patch for multiple releases.
 
 There are certainly other approaches, I mention this one as it has a
 proven track record and I don't have a reason to deviate from it.

I'm not familiar with this, but I've never had any direct contact with the 
kernel patch submission process so that might explain it. I have to say I'm 
not unhappy with the existing convention we have of marking it in the title of 
the email though.

I'd like to hear more opinions from others, particularly submitters of stable 
branch patches and other stable branch maintainers who have been doing it 
longer than I have. Ping...?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Stable Release Process

2013-05-31 Thread Darren Hart

On 05/31/2013 09:34 AM, Paul Eggleton wrote:
Hi Darren,

Sorry it's taken me so long to reply to this.

On Wednesday 24 April 2013 10:32:54 Darren Hart wrote:
As the stable releases become first class citizens, we should probably
look at streamlining the process of getting patches to them.

The maintainer for the stable release currently changes by release,
which undoubtedly creates some confusion of where to send patches and
who to CC. These maintainers currently attempt to track these
patches via email filters searching for release branch names and such,
which is proving tedious and prone to missing patches.

Other projects have seen good results using a stable list for this
purpose. This would both make it obvious when a patch is intended for a
stable release as well as remove any confusion about who to Cc as it
would be the same list for all releases. Perhaps something like
openembedded-core-sta...@lists.openembedded.org?

In the OE-Classic days we used to have an openembedded-stablebranch mailing
list for the same purpose. I don't recall anyone complaining about that when
we had it, so this sounds like it could help with the aforementioned issues.

The downside I can see is that it's one more mailing list with the associated
problems of not everyone monitoring it (that patch of mine shouldn't have
been backported! or you backported one of my patches but missed an
associated one),

This is a very valid concern. The Linux Kernel stable tree maintainer
sends out email to the author of all patches he has queued for a stable
update before they hit the tree. This provides a reliable mechanism for
authors to provide feedback.

and new users erroneously emailing it with requests for help
that should have gone to the normal mailing list. That could however be
outweighed by the advantage of stable branch patches not being drowned out by
the rest of the patches as they currently can be.

In addition to the list, some policy would need to be documented on how
to use the list. For example, it should always be Cc'd, and never
emailed with patches directly that don't go first to the master branch.
Backports being the exception. A policy could also be put in place to
aid in automatic processing, such as that employed by the Linux kernel
stable project. The following would request that the patch be applied to
the denzil and danny stable releases:

Cc: openembedded-core-sta...@lists.openembedded.org # denzil
Cc: openembedded-core-sta...@lists.openembedded.org # danny
Signed-off-by: Darren Hart dvh...@linux.intel.com

The advantage here over something like a subject tag, [danny] is that
it scales a bit better to sending a patch for multiple releases.

There are certainly other approaches, I mention this one as it has a
proven track record and I don't have a reason to deviate from it.

I'm not familiar with this, but I've never had any direct contact with the
kernel patch submission process so that might explain it. I have to say I'm

I understand we are not the Linux kernel community and we need to take
our own priorities and needs into account when definining our process.
However, just for reference (learn from history or be doomed to repeat
it and all that), here are the Linux kernel stable rules:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/stable_kernel_rules.txt?id=refs/tags/v3.10-rc3

Personally, I believe it to be a fairly sound process.

not unhappy with the existing convention we have of marking it in the title
of
the email though.

I'd like to hear more opinions from others, particularly submitters of stable
branch patches and other stable branch maintainers who have been doing it
longer than I have. Ping...?

Agreed.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Stable Release Process

2013-05-31 Thread Martin Jansa

On Fri, May 31, 2013 at 05:34:51PM +0100, Paul Eggleton wrote:
 Hi Darren,
 
 Sorry it's taken me so long to reply to this.
 
 On Wednesday 24 April 2013 10:32:54 Darren Hart wrote:
  As the stable releases become first class citizens, we should probably
  look at streamlining the process of getting patches to them.
  
  The maintainer for the stable release currently changes by release,
  which undoubtedly creates some confusion of where to send patches and
  who to CC. These maintainers currently attempt to track these
  patches via email filters searching for release branch names and such,
  which is proving tedious and prone to missing patches.
  
  Other projects have seen good results using a stable list for this
  purpose. This would both make it obvious when a patch is intended for a
  stable release as well as remove any confusion about who to Cc as it
  would be the same list for all releases. Perhaps something like
  openembedded-core-sta...@lists.openembedded.org?
 
 In the OE-Classic days we used to have an openembedded-stablebranch mailing 
 list for the same purpose. I don't recall anyone complaining about that when 
 we had it, so this sounds like it could help with the aforementioned issues.
 
 The downside I can see is that it's one more mailing list with the associated 
 problems of not everyone monitoring it (that patch of mine shouldn't have 
 been backported! or you backported one of my patches but missed an 
 associated one), and new users erroneously emailing it with requests for 
 help 
 that should have gone to the normal mailing list. That could however be 
 outweighed by the advantage of stable branch patches not being drowned out by 
 the rest of the patches as they currently can be.
 
  In addition to the list, some policy would need to be documented on how
  to use the list. For example, it should always be Cc'd, and never
  emailed with patches directly that don't go first to the master branch.
  Backports being the exception. A policy could also be put in place to
  aid in automatic processing, such as that employed by the Linux kernel
  stable project. The following would request that the patch be applied to
  the denzil and danny stable releases:
  
  Cc: openembedded-core-sta...@lists.openembedded.org # denzil
  Cc: openembedded-core-sta...@lists.openembedded.org # danny
  Signed-off-by: Darren Hart dvh...@linux.intel.com
  
  The advantage here over something like a subject tag, [danny] is that
  it scales a bit better to sending a patch for multiple releases.
  
  There are certainly other approaches, I mention this one as it has a
  proven track record and I don't have a reason to deviate from it.
 
 I'm not familiar with this, but I've never had any direct contact with the 
 kernel patch submission process so that might explain it. I have to say I'm 
 not unhappy with the existing convention we have of marking it in the title 
 of 
 the email though.
 
 I'd like to hear more opinions from others, particularly submitters of stable 
 branch patches and other stable branch maintainers who have been doing it 
 longer than I have. Ping...?

I like subject tags, at least because they are nicely shown in patchwork
subject, so I can easily sort incoming patches to right bundles.

And this problem with scaling when sending a patch for multiple
releases we already have when tagging multiple affected layers (which happens
more often for meta-oe layers then multiple releases).

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Stable Release Process

2013-05-31 Thread Darren Hart

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 05/31/2013 10:34 AM, Martin Jansa wrote:
 On Fri, May 31, 2013 at 05:34:51PM +0100, Paul Eggleton wrote:
 Hi Darren,
 
 Sorry it's taken me so long to reply to this.
 
 On Wednesday 24 April 2013 10:32:54 Darren Hart wrote:
 As the stable releases become first class citizens, we should
 probably look at streamlining the process of getting patches to
 them.
 
 The maintainer for the stable release currently changes by
 release, which undoubtedly creates some confusion of where to
 send patches and who to CC. These maintainers currently attempt
 to track these patches via email filters searching for release
 branch names and such, which is proving tedious and prone to
 missing patches.
 
 Other projects have seen good results using a stable list for
 this purpose. This would both make it obvious when a patch is
 intended for a stable release as well as remove any confusion
 about who to Cc as it would be the same list for all releases.
 Perhaps something like 
 openembedded-core-sta...@lists.openembedded.org?
 
 In the OE-Classic days we used to have an
 openembedded-stablebranch mailing list for the same purpose. I
 don't recall anyone complaining about that when we had it, so
 this sounds like it could help with the aforementioned issues.
 
 The downside I can see is that it's one more mailing list with
 the associated problems of not everyone monitoring it (that
 patch of mine shouldn't have been backported! or you backported
 one of my patches but missed an associated one), and new users
 erroneously emailing it with requests for help that should have
 gone to the normal mailing list. That could however be outweighed
 by the advantage of stable branch patches not being drowned out
 by the rest of the patches as they currently can be.
 
 In addition to the list, some policy would need to be
 documented on how to use the list. For example, it should
 always be Cc'd, and never emailed with patches directly that
 don't go first to the master branch. Backports being the
 exception. A policy could also be put in place to aid in
 automatic processing, such as that employed by the Linux
 kernel stable project. The following would request that the
 patch be applied to the denzil and danny stable releases:
 
 Cc: openembedded-core-sta...@lists.openembedded.org # denzil 
 Cc: openembedded-core-sta...@lists.openembedded.org # danny 
 Signed-off-by: Darren Hart dvh...@linux.intel.com
 
 The advantage here over something like a subject tag, [danny]
 is that it scales a bit better to sending a patch for multiple
 releases.
 
 There are certainly other approaches, I mention this one as it
 has a proven track record and I don't have a reason to deviate
 from it.
 
 I'm not familiar with this, but I've never had any direct contact
 with the kernel patch submission process so that might explain
 it. I have to say I'm not unhappy with the existing convention we
 have of marking it in the title of the email though.
 
 I'd like to hear more opinions from others, particularly
 submitters of stable branch patches and other stable branch
 maintainers who have been doing it longer than I have. Ping...?
 
 I like subject tags, at least because they are nicely shown in
 patchwork subject, so I can easily sort incoming patches to right
 bundles.
 
 And this problem with scaling when sending a patch for multiple 
 releases we already have when tagging multiple affected layers
 (which happens more often for meta-oe layers then multiple
 releases).

It has been expressed that this has been challenging to enforce
(anything that is freeform is). Do you have any suggestions on how we
could address that? Documentation? Firm maintainer policy of willfully
ignoring non-tagged patches?

Thanks,

- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRqOGFAAoJEKbMaAwKp364WjEH/2ppNgSD1sM2uqLAIkLRM842
K+zJKOOrkm2+UI9VUp9NM5mJi5Egm9cfpBymeQS8wetvQEhSCY6epw1/55epzKY/
nG9JOGFpJu4Lnujqun3vAUw0cctfw7re+osGYZ2Dx6icig+6umNOSbeS6vrOT/hp
9bsN8bMBwOUx24iHEU+rQ30KTniGL3jsqCYXHHVO5+hP1TZ50cie5w2rYQ0VHHYf
doncbiR+lFa8X8GkgnsfsDy/qn3DePfgD9NSoSJsKYe0ZExHY53csWi6xUgMF+J6
LjVIfs+eMbOD3ZLTkHPDbDe/M9xirem/7lxudfwqFEPOpiRGmGm4fdp+ycjqS0c=
=H+iu
-END PGP SIGNATURE-
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] gstreamer: moved LIBV out of gst-plugins-package.inc file

Since gst-plugins-package.inc is going to be used by the following
GStreamer 1.0 recipes as well, LIBV has to be set outside of the .inc file.

Signed-off-by: Carlos Rafael Giani d...@pseudoterminal.org
---
 meta/recipes-multimedia/gstreamer/gst-plugins-package.inc | 1 -
 meta/recipes-multimedia/gstreamer/gst-plugins.inc | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc 
b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
index 5962e4b..0503b34 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
@@ -1,6 +1,5 @@
 PACKAGESPLITFUNCS_prepend =  split_gstreamer10_packages 
 PACKAGESPLITFUNCS_append =  set_metapkg_rdepends 
-LIBV = 0.10
 
 python split_gstreamer10_packages () {
 gst_libdir = d.expand('${libdir}/gstreamer-${LIBV}')
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins.inc 
b/meta/recipes-multimedia/gstreamer/gst-plugins.inc
index fc9567a..4c9716d 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins.inc
@@ -15,6 +15,7 @@ EXTRA_OECONF = --disable-valgrind ${GSTREAMER_DEBUG} 
--disable-examples 
 
 acpaths = -I ${S}/common/m4 -I ${S}/m4
 
+LIBV = 0.10
 require gst-plugins-package.inc
 
 PACKAGES_DYNAMIC += ^${PN}-.*
-- 
1.8.3

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

[OE-core] [PATCH 0/3] GStreamer 1.0 recipes

These patches introduce recipes for GStreamer 1.0 . They
are copied over from my gstreamer 1.0 layer at
https://github.com/dv1/meta-gstreamer1.0 . All files except
gstreamer1.0-plugins-package.inc were copied; gst-plugins-package.inc
was patched to fix a problem with -meta packages and can be used for
both 0.10 and 1.0 now (the only difference is the value of the LIBV
variable).

Some open questions:
* Is it OK to add _git versions of the recipes to OE core?
* The gstreamer1.0-omx recipe sets itself to be machine specific if
  this is explicitely requested. This is necessary, since gst-omx has
  machine specific codepaths (currently for the Raspberry Pi). By
  default, it is not machine specific, and uses the Bellagio OpenMAX
  implementation that is supported by OE core. Is it OK to include
  options for machine specific support which can be set by BSP layers?

Carlos Rafael Giani (3):
  gstreamer: fixed -meta package rdepends
  gstreamer: moved LIBV out of gst-plugins-package.inc file
  gstreamer: added GStreamer 1.0 recipes

 .../gstreamer/gst-plugins-package.inc  |  28 --
 meta/recipes-multimedia/gstreamer/gst-plugins.inc  |   1 +
 .../gstreamer/gstreamer1.0-libav.inc   |  34 +++
 ...-Disable-yasm-for-libav-when-disable-yasm.patch |  33 +++
 .../gstreamer1.0-libav/libav_e500mc.patch  |  21 +
 .../gstreamer/gstreamer1.0-libav_1.0.7.bb  |  27 ++
 .../gstreamer/gstreamer1.0-libav_git.bb|  27 ++
 .../gstreamer/gstreamer1.0-omx.inc |  42 +
 .../0001-omx-fixed-type-error-in-printf-call.patch |  30 ++
 .../gstreamer/gstreamer1.0-omx_1.0.0.bb|  12 +++
 .../gstreamer/gstreamer1.0-omx_git.bb  |  22 +
 .../gstreamer/gstreamer1.0-plugins-bad.inc | 105 +
 .../gstreamer/gstreamer1.0-plugins-bad_1.0.7.bb|  12 +++
 .../gstreamer/gstreamer1.0-plugins-bad_git.bb  |  26 +
 .../gstreamer/gstreamer1.0-plugins-base.inc|  42 +
 .../gstreamer/gstreamer1.0-plugins-base_1.0.7.bb   |  11 +++
 .../gstreamer/gstreamer1.0-plugins-base_git.bb |  18 
 .../gstreamer/gstreamer1.0-plugins-good.inc|  55 +++
 .../gstreamer/gstreamer1.0-plugins-good_1.0.7.bb   |  11 +++
 .../gstreamer/gstreamer1.0-plugins-good_git.bb |  17 
 .../gstreamer/gstreamer1.0-plugins-ugly.inc|  33 +++
 .../gstreamer/gstreamer1.0-plugins-ugly_1.0.7.bb   |  10 ++
 .../gstreamer/gstreamer1.0-plugins-ugly_git.bb |  16 
 .../gstreamer/gstreamer1.0-plugins.inc |  57 +++
 meta/recipes-multimedia/gstreamer/gstreamer1.0.inc |  23 +
 .../0001-Fix-crash-with-gst-inspect.patch  |  28 ++
 .../gstreamer/gstreamer1.0_1.0.7.bb|  13 +++
 .../gstreamer/gstreamer1.0_git.bb  |  17 
 28 files changed, 765 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/0001-Disable-yasm-for-libav-when-disable-yasm.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/libav_e500mc.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.0.7.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-omx/0001-omx-fixed-type-error-in-printf-call.patch
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.0.7.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.0.7.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.0.7.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.0.7.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_git.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
 create mode 100644

[OE-core] [PATCH 1/3] gstreamer: fixed -meta package rdepends

The -meta packages were depending on non-existing packages,
like -glib and -apps. The fix checks if packages in the PACKAGES list
are empty. If so, they are omitted from the rdepends list.

Signed-off-by: Carlos Rafael Giani d...@pseudoterminal.org
---
 .../gstreamer/gst-plugins-package.inc  | 27 ++
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc 
b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
index 7ae3ef6..5962e4b 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
@@ -1,6 +1,8 @@
+PACKAGESPLITFUNCS_prepend =  split_gstreamer10_packages 
+PACKAGESPLITFUNCS_append =  set_metapkg_rdepends 
 LIBV = 0.10
 
-python populate_packages_prepend () {
+python split_gstreamer10_packages () {
 gst_libdir = d.expand('${libdir}/gstreamer-${LIBV}')
 postinst = d.getVar('plugin_postinst', True)
 glibdir = d.getVar('libdir', True)
@@ -9,23 +11,38 @@ python populate_packages_prepend () {
 do_split_packages(d, gst_libdir, 'libgst(.*)\.so$', d.expand('${PN}-%s'), 
'GStreamer plugin for %s', postinst=postinst, extra_depends=d.expand('${PN}'))
 do_split_packages(d, gst_libdir, 'libgst(.*)\.la$', 
d.expand('${PN}-%s-dev'), 'GStreamer plugin for %s (development files)', 
extra_depends=d.expand('${PN}-dev'))
 do_split_packages(d, gst_libdir, 'libgst(.*)\.a$', 
d.expand('${PN}-%s-staticdev'), 'GStreamer plugin for %s (static development 
files)', extra_depends=d.expand('${PN}-staticdev'))
-
+}
+
+python set_metapkg_rdepends () {
+import os
+
 pn = d.getVar('PN', True)
 metapkg =  pn + '-meta'
 d.setVar('ALLOW_EMPTY_' + metapkg, 1)
 d.setVar('FILES_' + metapkg, )
-blacklist = [ pn + '-locale', pn + '-dev', pn + '-dbg', pn + '-doc' ]
+blacklist = [ pn, pn + '-locale', pn + '-dev', pn + '-dbg', pn + '-doc', 
pn + '-meta' ]
 metapkg_rdepends = []
 packages = d.getVar('PACKAGES', True).split()
+pkgdest = d.getVar('PKGDEST', True)
 for pkg in packages[1:]:
 if not pkg in blacklist and not pkg in metapkg_rdepends and not 
pkg.endswith('-dev') and not pkg.endswith('-dbg') and not pkg.count('locale') 
and not pkg.count('-staticdev'):
-metapkg_rdepends.append(pkg)
+# See if the package is empty by looking at the contents of its 
PKGDEST subdirectory. 
+# If this subdirectory is empty, then the package is.
+# Empty packages do not get added to the meta package's RDEPENDS
+pkgdir = os.path.join(pkgdest, pkg)
+if os.path.exists(pkgdir):
+dir_contents = os.listdir(pkgdir) or []
+else:
+dir_contents = []
+is_empty = len(dir_contents) == 0
+if not is_empty:
+metapkg_rdepends.append(pkg)
 d.setVar('RDEPENDS_' + metapkg, ' '.join(metapkg_rdepends))
 d.setVar('DESCRIPTION_' + metapkg, pn + ' meta package')
 }
 
 # metapkg has runtime dependency on PN
-# each plugin depends on PN, plugin-dev on PN-dev and plugin-staticdev on 
PN-staticdev
+# each plugin depends on PN, plugin-dev on PN-dev, plugin-staticdev on 
PN-staticdev
 # so we need them even when empty (like in gst-plugins-good case)
 ALLOW_EMPTY_${PN} = 1
 ALLOW_EMPTY_${PN}-dev = 1
-- 
1.8.3

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

[OE-core] [PATCH 3/3] gstreamer: added GStreamer 1.0 recipes

Originally from the https://github.com/dv1/meta-gstreamer1.0 repository,
the patches were copied with only one change:
gstreamer1.0-plugins-package.inc was removed, since gst-plugins-package.inc
is identical except for the LIBV variable.

Signed-off-by: Carlos Rafael Giani d...@pseudoterminal.org
---
 .../gstreamer/gstreamer1.0-libav.inc   |  34 +++
 ...-Disable-yasm-for-libav-when-disable-yasm.patch |  33 +++
 .../gstreamer1.0-libav/libav_e500mc.patch  |  21 +
 .../gstreamer/gstreamer1.0-libav_1.0.7.bb  |  27 ++
 .../gstreamer/gstreamer1.0-libav_git.bb|  27 ++
 .../gstreamer/gstreamer1.0-omx.inc |  42 +
 .../0001-omx-fixed-type-error-in-printf-call.patch |  30 ++
 .../gstreamer/gstreamer1.0-omx_1.0.0.bb|  12 +++
 .../gstreamer/gstreamer1.0-omx_git.bb  |  22 +
 .../gstreamer/gstreamer1.0-plugins-bad.inc | 105 +
 .../gstreamer/gstreamer1.0-plugins-bad_1.0.7.bb|  12 +++
 .../gstreamer/gstreamer1.0-plugins-bad_git.bb  |  26 +
 .../gstreamer/gstreamer1.0-plugins-base.inc|  42 +
 .../gstreamer/gstreamer1.0-plugins-base_1.0.7.bb   |  11 +++
 .../gstreamer/gstreamer1.0-plugins-base_git.bb |  18 
 .../gstreamer/gstreamer1.0-plugins-good.inc|  55 +++
 .../gstreamer/gstreamer1.0-plugins-good_1.0.7.bb   |  11 +++
 .../gstreamer/gstreamer1.0-plugins-good_git.bb |  17 
 .../gstreamer/gstreamer1.0-plugins-ugly.inc|  33 +++
 .../gstreamer/gstreamer1.0-plugins-ugly_1.0.7.bb   |  10 ++
 .../gstreamer/gstreamer1.0-plugins-ugly_git.bb |  16 
 .../gstreamer/gstreamer1.0-plugins.inc |  57 +++
 meta/recipes-multimedia/gstreamer/gstreamer1.0.inc |  23 +
 .../0001-Fix-crash-with-gst-inspect.patch  |  28 ++
 .../gstreamer/gstreamer1.0_1.0.7.bb|  13 +++
 .../gstreamer/gstreamer1.0_git.bb  |  17 
 26 files changed, 742 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/0001-Disable-yasm-for-libav-when-disable-yasm.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/libav_e500mc.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.0.7.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-omx/0001-omx-fixed-type-error-in-printf-call.patch
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.0.0.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.0.7.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.0.7.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.0.7.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.0.7.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_git.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins.inc
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-Fix-crash-with-gst-inspect.patch
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0_1.0.7.bb
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0_git.bb

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
new file mode 100644
index 000..c77a085
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
@@ -0,0 +1,34 @@
+DESCRIPTION = Libav-based GStreamer 1.x plugin
+SECTION = multimedia
+LICENSE = GPLv2+  LGPLv2+  ( (GPLv2+  LGPLv2.1+) | (GPLv3+  LGPLv3+) )
+LICENSE_FLAGS = commercial
+HOMEPAGE = http://www.gstreamer.net/;
+DEPENDS = gstreamer1.0 gstreamer1.0-plugins-base zlib bzip2
+
+inherit autotools pkgconfig
+
+PR = r1
+
+
+# CAUTION: Using the system libav is not recommended. Since the libav API is 
changing all the time,
+#

[OE-core] gcc 4.8 - ICE