Re: [OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

To me, the purpose of buildhistory's metadata-revs is to enable someone 
else (or myself in the future) to recreate a specific build, that's why 
I always save this file with any build artifacts. Simply saying "meta" 
isn't good enough because it doesn't specify which repository's "meta". 
So the purpose of this patch is to try to clarify which repositories 
we're talking about.



Before:
meta  = master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-oe   = master:a1e135a48add7575682bf53db5e02e753580
meta-gnome= master:a1e135a48add7575682bf53db5e02e753580
meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro-toolchain = 
master:367f784b831938dc508b7d472342d2d0d6ed9769

meta  = master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

After:
openembedded-core/meta = 
master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-openembedded/meta-oe = 
master:a1e135a48add7575682bf53db5e02e753580
meta-openembedded/meta-gnome = 
master:a1e135a48add7575682bf53db5e02e753580

meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro/meta-linaro-toolchain = 
master:367f784b831938dc508b7d472342d2d0d6ed9769

meta-poky/meta= master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c


I have a second patch, now, that will generate the following output, 
which I think is even better:


git://git.openembedded.org/openembedded-core.git
openembedded-core/meta = 
master:00d3fd571a8d261d065b43f5cf3076a381843984


git://git.openembedded.org/meta-openembedded
meta-openembedded/meta-oe = 
master:a1e135a48add7575682bf53db5e02e753580


git://git.openembedded.org/meta-openembedded
meta-openembedded/meta-gnome = 
master:a1e135a48add7575682bf53db5e02e753580


git://github.com/96boards/meta-rpb.git
meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9

https://github.com/96boards/meta-96boards.git
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649

https://github.com/ndechesne/meta-qcom.git
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d

git://github.com/OSSystems/meta-browser.git
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919

git://git.linaro.org/openembedded/meta-linaro.git
meta-linaro/meta-linaro-toolchain = 
master:367f784b831938dc508b7d472342d2d0d6ed9769


git://git.yoctoproject.org/poky
meta-poky/meta= master:37b61b059031e3c272a929b834e12fd83f46598c

git://git.yoctoproject.org/poky
meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

Frankly, there are too many forks and clones. There are too many 
meta-beaglebone or meta-odroid or meta-raspberrypi repositories. If six 
months from now I want to recreate a build I've done today, I'll need to 
know the repository, where it's from, and which commit was checked out. 
My latest patch provides that information.


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

Re: [OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

On 03/11/16 22:59, Khem Raj wrote:



On Mar 12, 2016 9:50 AM, "Trevor Woerner" > wrote:

>
> Currently my build shows two "meta" repositories: one from meta-poky 
and one

> from openembedded-core. Have the code which prints the repositories into
> metadata-revs show the parent directories when repositories with 
multiple

> sub-layers are used.

Meta-poky is a leaf layer. So how is it offering conflicting meta layer ?



There's no conflict, I'm just trying to generate output the 
differentiates amongst leaf layers in its output.


Before:
meta  = master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-oe   = master:a1e135a48add7575682bf53db5e02e753580
meta-gnome= master:a1e135a48add7575682bf53db5e02e753580
meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro-toolchain = master:367f784b831938dc508b7d472342d2d0d6ed9769
meta  = master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

After:
openembedded-core/meta = 
master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-openembedded/meta-oe = 
master:a1e135a48add7575682bf53db5e02e753580
meta-openembedded/meta-gnome = 
master:a1e135a48add7575682bf53db5e02e753580

meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro/meta-linaro-toolchain = 
master:367f784b831938dc508b7d472342d2d0d6ed9769

meta-poky/meta= master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

So you see how it prints the parent layer for any leaf layers, which is 
more descriptive (and better?).







>
> Signed-off-by: Trevor Woerner >

> ---
>  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 fac7fed..b6b4324 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -616,7 +616,7 @@ def buildhistory_get_build_id(d):
>  def buildhistory_get_metadata_revs(d):
>  # We want an easily machine-readable format here, so 
get_layers_branch_rev isn't quite what we want

>  layers = (d.getVar("BBLAYERS", True) or "").split()
> -medadata_revs = ["%-17s = %s:%s" % (os.path.basename(i), \
> +medadata_revs = ["%-17s = %s:%s" % (os.path.relpath(i, 
d.getVar('BBLAYERS_FETCH_DIR', True)), \

>  base_get_metadata_git_branch(i, None).strip(), \
>  base_get_metadata_git_revision(i, None)) \
>  for i in layers]
> --
> 2.7.0.rc3
>
> --
> ___
> 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] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Khem Raj]

On Mar 12, 2016 9:50 AM, "Trevor Woerner"  wrote:
>
> Currently my build shows two "meta" repositories: one from meta-poky and
one
> from openembedded-core. Have the code which prints the repositories into
> metadata-revs show the parent directories when repositories with multiple
> sub-layers are used.

Meta-poky is a leaf layer. So how is it offering conflicting meta layer ?
>
> Signed-off-by: Trevor Woerner 
> ---
>  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 fac7fed..b6b4324 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -616,7 +616,7 @@ def buildhistory_get_build_id(d):
>  def buildhistory_get_metadata_revs(d):
>  # We want an easily machine-readable format here, so
get_layers_branch_rev isn't quite what we want
>  layers = (d.getVar("BBLAYERS", True) or "").split()
> -medadata_revs = ["%-17s = %s:%s" % (os.path.basename(i), \
> +medadata_revs = ["%-17s = %s:%s" % (os.path.relpath(i,
d.getVar('BBLAYERS_FETCH_DIR', True)), \
>  base_get_metadata_git_branch(i, None).strip(), \
>  base_get_metadata_git_revision(i, None)) \
>  for i in layers]
> --
> 2.7.0.rc3
>
> --
> ___
> 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] [PATCH][jethro][RFC 1/2] libsdl: expand PACKAGECONFIG and enable native builds

[Trevor Woerner]

On 03/11/16 18:16, Richard Purdie wrote:

On Fri, 2016-03-11 at 16:36 -0500, Trevor Woerner wrote:

Hi Ross,

On 03/11/16 15:49, Burton, Ross wrote:

On 11 March 2016 at 20:20, Trevor Woerner > wrote:

 ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11'
(but
 virtual:nativesdk:/z/dragon410c-repo/dragon410c-tw
-jethro/layers/openembedded-core/meta/recipes
-graphics/libsdl/libsdl_1.2.15.bb
  DEPENDS on or otherwise requires it).
 Close matches:


That's an awesome comment.  Clearly my testing wasn't optimal,
there's
another patch required.

Can you verify that
cherry-picking 55ca1fb8f0e81ff739b3c46897e43356d1f760c3 solves
this?

Yes, verified. Cherry-picking 55ca1fb8 solves the problem.

Thanks! :-)

I just merged the fix to the branch, thanks for testing.



Thank _you_ people for being so fast to respond to the issues your users 
find!

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

[OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

Currently my build shows two "meta" repositories: one from meta-poky and one
from openembedded-core. Have the code which prints the repositories into
metadata-revs show the parent directories when repositories with multiple
sub-layers are used.

Signed-off-by: Trevor Woerner 
---
 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 fac7fed..b6b4324 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -616,7 +616,7 @@ def buildhistory_get_build_id(d):
 def buildhistory_get_metadata_revs(d):
 # We want an easily machine-readable format here, so get_layers_branch_rev 
isn't quite what we want
 layers = (d.getVar("BBLAYERS", True) or "").split()
-medadata_revs = ["%-17s = %s:%s" % (os.path.basename(i), \
+medadata_revs = ["%-17s = %s:%s" % (os.path.relpath(i, 
d.getVar('BBLAYERS_FETCH_DIR', True)), \
 base_get_metadata_git_branch(i, None).strip(), \
 base_get_metadata_git_revision(i, None)) \
 for i in layers]
-- 
2.7.0.rc3

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

Re: [OE-core] [PATCHv2][master] arch-armv8a.inc: Add tune for 32-bit ARMv8a

[Khem Raj]

> On Mar 12, 2016, at 12:58 AM, Daniel Dragomir  
> wrote:
> 
> This patch adds tunes for 32-bit armv8a platforms. The user can select
> little or big endian, hard or soft float, the vector floating-point
> instruction set: vfpv4 or fp-armv8 and the thumb, neon, crc and crypto
> extensions.

This does not feel right to me. Look at how thunderX looks like
ARMv8 is the time to fix this tune explodes on arm, this patch is not helping
it.

Do we need the hf/neon/vfp/thumb2 variants?

Only crc, crypto probably are needed.

It is not leveraging existing arm64 tune includes as well. I would rather have
no further tunes for aarch64 at this point.

choose a sane default and lets live with it.
> 
> Signed-off-by: Daniel Dragomir 
> ---
> meta/conf/machine/include/arm/arch-armv8a.inc  | 382 +
> .../conf/machine/include/arm/feature-arm-thumb.inc |   1 +
> 2 files changed, 383 insertions(+)
> create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
> 
> diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
> b/meta/conf/machine/include/arm/arch-armv8a.inc
> new file mode 100644
> index 000..6544f50
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
> @@ -0,0 +1,382 @@
> +DEFAULTTUNE ?= "armv8a"
> +
> +TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
> +TUNECONFLICTS[armv8a] = "armv4 armv5 armv6 armv7 armv7a armv7ve"
> +
> +TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "crc", "-crc", "", 
> d)}"
> +
> +TUNEVALID[crypto] = "Enable ARMv8 crypto extension."
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "crypto", "-crypto", 
> "", d)}"
> +
> +TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
> +ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fp-armv8", 
> "-fp-armv8", "", d)}"
> +
> +TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "armv8a", 
> bb.utils.contains("TUNE_FEATURES", "crc", " -march=armv8-a+crc", " 
> -march=armv8-a", d), "", d)}"
> +
> +TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "fp-armv8", 
> bb.utils.contains("TUNE_FEATURES", "neon", bb.utils.contains("TUNE_FEATURES", 
> "crypto", " -mfpu=crypto-neon-fp-armv8", " -mfpu=neon-fp-armv8", d), " 
> -mfpu=fp-armv8", d), "", d)}"
> +
> +MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "armv8a", 
> "armv8a:", "" ,d)}"
> +
> +require conf/machine/include/arm/arch-armv7ve.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv8a armv8at armv8a-neon armv8at-neon armv8a-vfpv4 
> armv8at-vfpv4 armv8a-vfpv4-neon armv8at-vfpv4-neon armv8a-fp-armv8 
> armv8at-fp-armv8 armv8a-fp-armv8-neon armv8at-fp-armv8-neon 
> armv8a-crypto-fp-armv8-neon armv8at-crypto-fp-armv8-neon"
> +ARMPKGARCH_tune-armv8a   ?= "armv8a"
> +ARMPKGARCH_tune-armv8at  ?= "armv8a"
> +ARMPKGARCH_tune-armv8a-neon  ?= "armv8a"
> +ARMPKGARCH_tune-armv8at-neon ?= "armv8a"
> +ARMPKGARCH_tune-armv8a-vfpv4 ?= "armv8a"
> +ARMPKGARCH_tune-armv8at-vfpv4?= "armv8a"
> +ARMPKGARCH_tune-armv8a-vfpv4-neon?= "armv8a"
> +ARMPKGARCH_tune-armv8at-vfpv4-neon   ?= "armv8a"
> +ARMPKGARCH_tune-armv8a-fp-armv8  ?= "armv8a"
> +ARMPKGARCH_tune-armv8at-fp-armv8 ?= "armv8a"
> +ARMPKGARCH_tune-armv8a-fp-armv8-neon ?= "armv8a"
> +ARMPKGARCH_tune-armv8at-fp-armv8-neon?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crypto-fp-armv8-neon  ?= "armv8a"
> +ARMPKGARCH_tune-armv8at-crypto-fp-armv8-neon ?= "armv8a"
> +TUNE_FEATURES_tune-armv8a   = "arm armv8a"
> +TUNE_FEATURES_tune-armv8at  = 
> "${TUNE_FEATURES_tune-armv8a} thumb"
> +TUNE_FEATURES_tune-armv8a-neon  = 
> "${TUNE_FEATURES_tune-armv8a} neon"
> +TUNE_FEATURES_tune-armv8at-neon = 
> "${TUNE_FEATURES_tune-armv8at} neon"
> +TUNE_FEATURES_tune-armv8a-vfpv4 = 
> "${TUNE_FEATURES_tune-armv8a} vfpv4"
> +TUNE_FEATURES_tune-armv8at-vfpv4= 
> "${TUNE_FEATURES_tune-armv8at} vfpv4"
> +TUNE_FEATURES_tune-armv8a-vfpv4-neon= 
> "${TUNE_FEATURES_tune-armv8a-neon} vfpv4"
> +TUNE_FEATURES_tune-armv8at-vfpv4-neon   = 
> "${TUNE_FEATURES_tune-armv8at-neon} vfpv4"
> +TUNE_FEATURES_tune-armv8a-fp-armv8  = 
> "${TUNE_FEATURES_tune-armv8a} fp-armv8"
> +TUNE_FEATURES_tune-armv8at-fp-armv8 = 
> "${TUNE_FEATURES_tune-armv8at} fp-armv8"
> +TUNE_FEATURES_tune-armv8a-fp-armv8-neon = 
> "${TUNE_FEATURES_tune-armv8a-neon} fp-armv8"
> +TUNE_FEATURES_tune-armv8at-fp-armv8-neon= 
> "${TUNE_FEATURES_tune-armv8at-neon} fp-armv8"
> +TUNE_FEATURES_tune-armv8a-crypto-fp-armv8-neon  = 
> "${TUNE_FEATURES_tune-armv8a-fp-armv8-neon} crypto"
> +TUNE_FEATURES_tune-armv8at-crypto-fp-armv8-neon = 
> "${TUNE_FEATURES_tune-armv8at-fp-armv8-neon} crypto"
> 

Re: [OE-core] [PATCH][jethro][RFC 1/2] libsdl: expand PACKAGECONFIG and enable native builds

[Richard Purdie]

On Fri, 2016-03-11 at 16:36 -0500, Trevor Woerner wrote:
> Hi Ross,
> 
> On 03/11/16 15:49, Burton, Ross wrote:
> > 
> > On 11 March 2016 at 20:20, Trevor Woerner  > > wrote:
> > 
> > ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11'
> > (but
> > virtual:nativesdk:/z/dragon410c-repo/dragon410c-tw
> > -jethro/layers/openembedded-core/meta/recipes
> > -graphics/libsdl/libsdl_1.2.15.bb
> >  DEPENDS on or otherwise requires it).
> > Close matches:
> > 
> > 
> > That's an awesome comment.  Clearly my testing wasn't optimal,
> > there's 
> > another patch required.
> > 
> > Can you verify that 
> > cherry-picking 55ca1fb8f0e81ff739b3c46897e43356d1f760c3 solves
> > this?
> 
> Yes, verified. Cherry-picking 55ca1fb8 solves the problem.
> 
> Thanks! :-)

I just merged the fix to the branch, thanks for testing.

Cheers,

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

Re: [OE-core] [PATCH][jethro][RFC 1/2] libsdl: expand PACKAGECONFIG and enable native builds

[Trevor Woerner]

Hi Ross,

On 03/11/16 15:49, Burton, Ross wrote:


On 11 March 2016 at 20:20, Trevor Woerner > wrote:


ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11' (but

virtual:nativesdk:/z/dragon410c-repo/dragon410c-tw-jethro/layers/openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
 DEPENDS on or otherwise requires it).
Close matches:


That's an awesome comment.  Clearly my testing wasn't optimal, there's 
another patch required.


Can you verify that 
cherry-picking 55ca1fb8f0e81ff739b3c46897e43356d1f760c3 solves this?


Yes, verified. Cherry-picking 55ca1fb8 solves the problem.

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

Re: [OE-core] [RFC PATCH 00/12] Sato desktop upgrade (Gtk3 etc.)

[Burton, Ross]

On 11 March 2016 at 19:09, Otavio Salvador  wrote:

> All them; we might use GNOME (MATE or other WM) and write just a GTK+3
> demo like app for test the desired stuff.
>

The full GNOME DE is *huge* and until the g-i branch is merged is literally
impossible to build.  Something smaller like LXDE is possible but still
fairly large in comparison and massively fails when you try to use it on
hardware with a touchscreen: at least Matchbox+desktop+panel has always
(and will continue to) support a touchscreen+fingers for basic use.

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

[OE-core] [PATCH][jethro] base: check for existing prefix when expanding names in PACKAGECONFIG

[Ross Burton]

When the DEPENDS are added as part of the PACKAGECONFIG logic the list of
packages are expanded so that any required nativesdk-/-native/multilib prefixes
and suffixes are added.

However the special handling of virtual/foo names doesn't check that the prefix
already exists, which breaks under nativesdk as in that situation there's an
explicit nativesdk- prefix *and* MLPREFIX is set to nativesdk-.  This results in
the same prefix being applied twice, and virtual packages such as virtual/libx11
ending up as virtual/nativesdk-nativesdk-libx11.

Signed-off-by: Ross Burton 
---
 meta/classes/base.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 9bd5499..38b69db 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -363,7 +363,10 @@ python () {
 newappends.append(a)
 elif a.startswith("virtual/"):
 subs = a.split("/", 1)[1]
-newappends.append("virtual/" + prefix + subs + extension)
+if subs.startswith(prefix):
+newappends.append(a + extension)
+else:
+newappends.append("virtual/" + prefix + subs + 
extension)
 else:
 if a.startswith(prefix):
 newappends.append(a + extension)
-- 
2.7.0

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

Re: [OE-core] [PATCH][jethro][RFC 1/2] libsdl: expand PACKAGECONFIG and enable native builds

[Burton, Ross]

On 11 March 2016 at 20:20, Trevor Woerner  wrote:

> ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11' (but
> virtual:nativesdk:/z/dragon410c-repo/dragon410c-tw-jethro/layers/openembedded-core/meta/recipes-graphics/libsdl/
> libsdl_1.2.15.bb DEPENDS on or otherwise requires it). Close matches:
>

That's an awesome comment.  Clearly my testing wasn't optimal, there's
another patch required.

Can you verify that cherry-picking 55ca1fb8f0e81ff739b3c46897e43356d1f760c3
solves this?

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

Re: [OE-core] [PATCH][jethro][RFC 1/2] libsdl: expand PACKAGECONFIG and enable native builds

[Trevor Woerner]

This patch causes my jethro build to now fail with:

ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11' (but 
virtual:nativesdk:/z/dragon410c-repo/dragon410c-tw-jethro/layers/openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb 
DEPENDS on or otherwise requires it). Close matches:

  virtual/nativesdk-libx11
  virtual/nativesdk-libc
  virtual/nativesdk-db



On 02/29/16 11:02, Ross Burton wrote:

Use PACKAGECONFIG instead of using logic in DEPENDS and EXTRA_OECONF, adding new
options for PulseAudio, tslib, DirectFB, OpenGL and X11.  Pass
--disable-x11-shared so that it links to the X libraries instead of using
dlopen().

Disable tslib by default as the kernel event input subsystem is generally used.

SDL's OpenGL support requires X11 so check for both x11 and opengl, and merge
the dependencies.

Finally enable native builds, with a minimal PACKAGECONFIG that will build from
oe-core for native and nativesdk.

(From OE-Core rev: 3d6c31c3a4ff34376e17005a981bb55fc6f7a38f)

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
---
  meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 35 ++-
  1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb 
b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
index c0d5c6a..1cf3c39 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
@@ -12,13 +12,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4"
  
  PROVIDES = "virtual/libsdl"
  
-DEPENDS = "${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} \

-   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', 
'', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 
libxext libxrandr libxrender', '', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'libglu', '', 
d)} \
-   tslib"
-DEPENDS_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender nativesdk-libxext', 
'', d)}"
-
  PR = "r3"
  
  SRC_URI = "http://www.libsdl.org/release/SDL-${PV}.tar.gz \

@@ -38,21 +31,29 @@ inherit autotools lib_package binconfig-disabled pkgconfig
  
  EXTRA_OECONF = "--disable-static --enable-cdrom --enable-threads --enable-timers \

  --enable-file --disable-oss --disable-esd --disable-arts \
---disable-diskaudio --disable-nas --disable-esd-shared 
--disable-esdtest \
+--disable-diskaudio --disable-nas \
  --disable-mintaudio --disable-nasm --disable-video-dga \
  --disable-video-fbcon --disable-video-ps2gs 
--disable-video-ps3 \
  --disable-xbios --disable-gem --disable-video-dummy \
---enable-input-events --enable-input-tslib --enable-pthreads \
-${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 
'--enable-video-directfb', '--disable-video-directfb', d)} \
-${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'--enable-video-opengl', '--disable-video-opengl', d)} \
-${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
'--enable-video-x11', '--disable-video-x11', d)} \
+--enable-input-events --enable-pthreads \
  --disable-video-svga \
  --disable-video-picogui --disable-video-qtopia 
--enable-sdl-dlopen \
---disable-rpath \
---disable-pulseaudio"
+--disable-rpath"
+
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', 
d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 
'pulseaudio', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 
'directfb', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'opengl', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', 
d)}"
+PACKAGECONFIG_class-native = "x11"
+PACKAGECONFIG_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
'x11', '', d)}"
  
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}"

-PACKAGECONFIG[alsa] = "--enable-alsa 
--disable-alsatest,--disable-alsa,alsa-lib,"
+PACKAGECONFIG[alsa] = "--enable-alsa 
--disable-alsatest,--disable-alsa,alsa-lib"
+PACKAGECONFIG[pulseaudio] = 
"--enable-pulseaudio,--disable-pulseaudio,pulseaudio"
+PACKAGECONFIG[tslib] = "--enable-input-tslib, --disable-input-tslib, tslib"
+PACKAGECONFIG[directfb] = "--enable-video-directfb, --disable-video-directfb, 
directfb"
+PACKAGECONFIG[opengl] = "--enable-video-opengl, --disable-video-opengl, 
virtual/libgl libglu"
+PACKAGECONFIG[x11] = "--enable-video-x11 --disable-x11-shared, --disable-video-x11, 
virtual/libx11 libxext libxrandr libxrender"
  
  

Re: [OE-core] [RFC PATCH 00/12] Sato desktop upgrade (Gtk3 etc.)

[Otavio Salvador]

On Fri, Mar 11, 2016 at 4:06 PM, Burton, Ross  wrote:
>
> On 11 March 2016 at 18:53, Otavio Salvador
>  wrote:
>>
>> Is matchbox still the way to go? To test OE-Core maybe a custom GTK3
>> app might be better.
>
>
> Do you mean desktop or window manager?  Window managers are very non-trivial
> and matchbox is a known quantity, and the desktop is a custom GTK+ 3
> application.
>
> To expand the functionality of Sato as a test harness I agree that we need
> more custom applications, there's a bug for this already. You'll notice that
> over time the PIM applications have been removed leaving tools for testing
> only (such as gtk-player).

All them; we might use GNOME (MATE or other WM) and write just a GTK+3
demo like app for test the desired stuff.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 00/12] Sato desktop upgrade (Gtk3 etc.)

[Burton, Ross]

On 11 March 2016 at 18:53, Otavio Salvador  wrote:

> Is matchbox still the way to go? To test OE-Core maybe a custom GTK3
> app might be better.
>

Do you mean desktop or window manager?  Window managers are very
non-trivial and matchbox is a known quantity, and the desktop is a custom
GTK+ 3 application.

To expand the functionality of Sato as a test harness I agree that we need
more custom applications, there's a bug for this already. You'll notice
that over time the PIM applications have been removed leaving tools for
testing only (such as gtk-player).

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

Re: [OE-core] [RFC PATCH 00/12] Sato desktop upgrade (Gtk3 etc.)

[Otavio Salvador]

On Fri, Mar 11, 2016 at 10:12 AM, Jussi Kukkonen
 wrote:
> Here's a snapshot of the Sato upgrade I've been working on (YOCTO
>  #3169). It's based on Ross' work from 2.5 years back. The bigger
> changes currently live as my forks of the upstream projects (gtk3
> branches of various projects at https://github.com/jku), and the
> patchset here modifies recipes to temporarily use those forks:
> this is intended to make testing and review possible but also
> means this is just an RFC: once the upstream changes are merged,
> I'll update this patchset.
>
>
> For those not familiar with it, the goal of the exercise is to
>  1. Bring Sato desktop closer to this decade (Don't depend on
> ancient components, remove deprecated code)
>  2. Focus more on delivering an environment for validating and
> testing oe-core, less on building a DE for mobile devices
>
>
> Major changes:
>  * Ports to GTK3: matchbox-desktop, matchbox-panel-2,
>connman-gnome, sato-screenshot, xsettings-daemon
>  * GTK+ theme is Adwaita (upstream default)
>  * Matchbox WM theme modified to somewhat resemble Adwaita (boring
>gray instead of in-your-face green)
>  * Matchbox panel is no longer drawn on top of application titlebars
>because that fails badly with client side decorations. Instead
>it's a thinner panel always on top of screen, like gnome2 panel.
>  * Custom GTK theme engine is dropped
> Here's a screenshot showing the panel and window decoration:
> http://imgur.com/noqptiu
>
>
> Regressions:
>  * on-screen keyboard: I've not looked very closely but I
>believe this requires IM work for GTK3
>  * startup notification
>
>
> Questions:
>  * Schedule: this is for Yocto 2.1 in bugzilla (now M3) but got
>delayed. it's a bigger change and isn't ready to merge
>(as the upstream patches need review). Should I aim for next
>release instead?
>  * How should we do review on this? The upstreams are mostly on
>yoctoproject.org so I could send patches to some YP mailing list...
>but testing many of the patches is impossible without the patches
>for the other projects.
>  * Are the regressions listed above blockers?
>  * Anything I've missed? Theme design bikeshedding?

Is matchbox still the way to go? To test OE-Core maybe a custom GTK3
app might be better.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] linux-yocto/4.1: usb backports for Apollo Lake/Broxton

[Bruce Ashfield]

Importing a series of mainline backports to support USB on a couple of
Intel platforms:

   bbce8fe2cc42 usb: dwc3: pci: add support for Intel Broxton SOC
   e734e1d9f827 usb: dwc3: pci: Set enblslpm quirk for Synopsys platforms
   1c6bb6694d50 usb: dwc3: Add dis_enblslpm_quirk
   1c6be99e56b8 usb: dwc3: pci: trivial: Formatting
   2f2b89764b97 usb: dwc3: pci: passing forward the ACPI companion
   ea4b3c72d976 usb: dwc3: core: convert to unified device property interface
   dc670b52c69a usb: common: of_usb_get_dr_mode to usb_get_dr_mode
   586fc5174649 usb: dwc3: st: prepare the driver for generic usb_get_dr_mode 
function
   0624bd9af7ef usb: common: of_usb_get_maximum_speed to usb_get_maximum_speed
   e65bc5467e07 usb: dwc3: Add frame length adjustment quirk
   a90954c5d267 usb: musb: dsps: control musb speed based on dts setting
   b48ff160a993 usb: renesas_usbhs: Allow an OTG PHY driver to provide VBUS
   d1c59752195e usb: chipidea: set usb otg capabilities
   733eada2cdec usb: common: add API to update usb otg capabilities by device 
tree
   7ab2108dd82b usb: dwc3: core: avoid NULL pointer dereference
   1aedb48b7dc9 usb: dwc3: add ULPI interface support
   07e42a29fb7e usb: dwc3: pci: add quirk for Baytrails
   065917252622 usb: dwc3: add hsphy_interface property
   b2bb32a363a3 usb: dwc3: setup phys earlier
   bf6bb0a6ebb5 usb: dwc3: soft reset to it's own function
   d481da949476 usb: dwc3: cache hwparams earlier
   9ac66262a201 usb: dwc3: store driver data earlier
   5f940588938c usb: dwc3: ULPI or UTMI+ select
   04fdce097f83 usb: dwc3: USB2 PHY register access bits
   b7209213cc05 usb: add bus type for USB ULPI

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 18 +-
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index 4a6928a7d1fe..438e8bd866ea 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -2,8 +2,8 @@ KBRANCH ?= "standard/preempt-rt/base"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-SRCREV_machine ?= "2a4c22b03d434f7695e607b6ad30f77671985a6d"
-SRCREV_meta ?= "56dcb623ebf5e83d65fdb4eb270f23676bb000a5"
+SRCREV_machine ?= "3df00817776c649f6b9518a3d12cf8a01cecfbfa"
+SRCREV_meta ?= "b9023d4c8fbbb854c26f158a079a5f54dd61964d"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index 41a79f17b7f1..1148b99c2f04 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "4.1.18"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "ec18b0b3bd6befd416078e81d775dab37b3f9124"
-SRCREV_meta ?= "56dcb623ebf5e83d65fdb4eb270f23676bb000a5"
+SRCREV_machine ?= "bbce8fe2cc42c3f8424d42f50b537833897b6d53"
+SRCREV_meta ?= "b9023d4c8fbbb854c26f158a079a5f54dd61964d"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index 9663966d8e17..9bd6c0f0788c 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "96b21aab2adf2c9396f8cf579420a2e497923eae"
-SRCREV_machine_qemuarm64 ?= "ec18b0b3bd6befd416078e81d775dab37b3f9124"
-SRCREV_machine_qemumips ?= "e0a6ffb62a4d28659e0e1be7b1a42a8ef499aa3b"
-SRCREV_machine_qemuppc ?= "ec18b0b3bd6befd416078e81d775dab37b3f9124"
-SRCREV_machine_qemux86 ?= "ec18b0b3bd6befd416078e81d775dab37b3f9124"
-SRCREV_machine_qemux86-64 ?= "ec18b0b3bd6befd416078e81d775dab37b3f9124"
-SRCREV_machine_qemumips64 ?= "1b1349ca5a642086d4b92347fb9d1de1c6eab742"
-SRCREV_machine ?= "ec18b0b3bd6befd416078e81d775dab37b3f9124"
-SRCREV_meta ?= "56dcb623ebf5e83d65fdb4eb270f23676bb000a5"
+SRCREV_machine_qemuarm ?= "f8452287eab4c1d11d38a831f0d13ce09c314888"
+SRCREV_machine_qemuarm64 ?= "bbce8fe2cc42c3f8424d42f50b537833897b6d53"
+SRCREV_machine_qemumips ?= "0919df9a4a3b3fc23682605631ba4f32ac177f52"
+SRCREV_machine_qemuppc ?= "bbce8fe2cc42c3f8424d42f50b537833897b6d53"
+SRCREV_machine_qemux86 ?= "bbce8fe2cc42c3f8424d42f50b537833897b6d53"
+SRCREV_machine_qemux86-64 ?= "bbce8fe2cc42c3f8424d42f50b537833897b6d53"
+SRCREV_machine_qemumips64 ?= "8c34d0644c7cb0140c4ff010a8a59af2cde2d9a2"
+SRCREV_machine ?= 

Re: [OE-core] [PATCHv2][master] arch-armv8a.inc: Add tune for 32-bit ARMv8a

[Otavio Salvador]

On Fri, Mar 11, 2016 at 2:58 PM, Daniel Dragomir
 wrote:
>
> This patch adds tunes for 32-bit armv8a platforms. The user can select
> little or big endian, hard or soft float, the vector floating-point
> instruction set: vfpv4 or fp-armv8 and the thumb, neon, crc and crypto
> extensions.
>
> Signed-off-by: Daniel Dragomir 

As we were in touch and testing this together I am confortable to give:

Signed-off-by: Otavio Salvador 
Tested-by: Otavio Salvador 

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv2][master] arch-armv8a.inc: Add tune for 32-bit ARMv8a

[Daniel Dragomir]

This patch adds tunes for 32-bit armv8a platforms. The user can select
little or big endian, hard or soft float, the vector floating-point
instruction set: vfpv4 or fp-armv8 and the thumb, neon, crc and crypto
extensions.

Signed-off-by: Daniel Dragomir 
---
 meta/conf/machine/include/arm/arch-armv8a.inc  | 382 +
 .../conf/machine/include/arm/feature-arm-thumb.inc |   1 +
 2 files changed, 383 insertions(+)
 create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc

diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
b/meta/conf/machine/include/arm/arch-armv8a.inc
new file mode 100644
index 000..6544f50
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -0,0 +1,382 @@
+DEFAULTTUNE ?= "armv8a"
+
+TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
+TUNECONFLICTS[armv8a] = "armv4 armv5 armv6 armv7 armv7a armv7ve"
+
+TUNEVALID[crc] = "Enable CRC instructions for ARMv8-a"
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "crc", "-crc", "", d)}"
+
+TUNEVALID[crypto] = "Enable ARMv8 crypto extension."
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "crypto", "-crypto", 
"", d)}"
+
+TUNEVALID[fp-armv8] = "Enable ARMv8 Vector Floating Point unit."
+ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fp-armv8", 
"-fp-armv8", "", d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "armv8a", 
bb.utils.contains("TUNE_FEATURES", "crc", " -march=armv8-a+crc", " 
-march=armv8-a", d), "", d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "fp-armv8", 
bb.utils.contains("TUNE_FEATURES", "neon", bb.utils.contains("TUNE_FEATURES", 
"crypto", " -mfpu=crypto-neon-fp-armv8", " -mfpu=neon-fp-armv8", d), " 
-mfpu=fp-armv8", d), "", d)}"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "armv8a", 
"armv8a:", "" ,d)}"
+
+require conf/machine/include/arm/arch-armv7ve.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv8a armv8at armv8a-neon armv8at-neon armv8a-vfpv4 
armv8at-vfpv4 armv8a-vfpv4-neon armv8at-vfpv4-neon armv8a-fp-armv8 
armv8at-fp-armv8 armv8a-fp-armv8-neon armv8at-fp-armv8-neon 
armv8a-crypto-fp-armv8-neon armv8at-crypto-fp-armv8-neon"
+ARMPKGARCH_tune-armv8a   ?= "armv8a"
+ARMPKGARCH_tune-armv8at  ?= "armv8a"
+ARMPKGARCH_tune-armv8a-neon  ?= "armv8a"
+ARMPKGARCH_tune-armv8at-neon ?= "armv8a"
+ARMPKGARCH_tune-armv8a-vfpv4 ?= "armv8a"
+ARMPKGARCH_tune-armv8at-vfpv4?= "armv8a"
+ARMPKGARCH_tune-armv8a-vfpv4-neon?= "armv8a"
+ARMPKGARCH_tune-armv8at-vfpv4-neon   ?= "armv8a"
+ARMPKGARCH_tune-armv8a-fp-armv8  ?= "armv8a"
+ARMPKGARCH_tune-armv8at-fp-armv8 ?= "armv8a"
+ARMPKGARCH_tune-armv8a-fp-armv8-neon ?= "armv8a"
+ARMPKGARCH_tune-armv8at-fp-armv8-neon?= "armv8a"
+ARMPKGARCH_tune-armv8a-crypto-fp-armv8-neon  ?= "armv8a"
+ARMPKGARCH_tune-armv8at-crypto-fp-armv8-neon ?= "armv8a"
+TUNE_FEATURES_tune-armv8a   = "arm armv8a"
+TUNE_FEATURES_tune-armv8at  = 
"${TUNE_FEATURES_tune-armv8a} thumb"
+TUNE_FEATURES_tune-armv8a-neon  = 
"${TUNE_FEATURES_tune-armv8a} neon"
+TUNE_FEATURES_tune-armv8at-neon = 
"${TUNE_FEATURES_tune-armv8at} neon"
+TUNE_FEATURES_tune-armv8a-vfpv4 = 
"${TUNE_FEATURES_tune-armv8a} vfpv4"
+TUNE_FEATURES_tune-armv8at-vfpv4= 
"${TUNE_FEATURES_tune-armv8at} vfpv4"
+TUNE_FEATURES_tune-armv8a-vfpv4-neon= 
"${TUNE_FEATURES_tune-armv8a-neon} vfpv4"
+TUNE_FEATURES_tune-armv8at-vfpv4-neon   = 
"${TUNE_FEATURES_tune-armv8at-neon} vfpv4"
+TUNE_FEATURES_tune-armv8a-fp-armv8  = 
"${TUNE_FEATURES_tune-armv8a} fp-armv8"
+TUNE_FEATURES_tune-armv8at-fp-armv8 = 
"${TUNE_FEATURES_tune-armv8at} fp-armv8"
+TUNE_FEATURES_tune-armv8a-fp-armv8-neon = 
"${TUNE_FEATURES_tune-armv8a-neon} fp-armv8"
+TUNE_FEATURES_tune-armv8at-fp-armv8-neon= 
"${TUNE_FEATURES_tune-armv8at-neon} fp-armv8"
+TUNE_FEATURES_tune-armv8a-crypto-fp-armv8-neon  = 
"${TUNE_FEATURES_tune-armv8a-fp-armv8-neon} crypto"
+TUNE_FEATURES_tune-armv8at-crypto-fp-armv8-neon = 
"${TUNE_FEATURES_tune-armv8at-fp-armv8-neon} crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a   = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve} armv8a"
+PACKAGE_EXTRA_ARCHS_tune-armv8at  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet} armv8a"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-neon  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} armv8a-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv8at-neon = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8at} armv8a-neon armv8at2-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-vfpv4 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} armv8a-vfpv4"
+PACKAGE_EXTRA_ARCHS_tune-armv8at-vfpv4= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8at} armv8a-vfpv4 armv8at2-vfpv4"

[OE-core] [master][PATCH] ARMv8 32-bit & 64-bit compiler tunings

[Daniel Dragomir]

Hello!

This is a second version for the patch for 32-bit, against MASTER branch.

@Martin, I tested all the new tunes with your script, and I got no errors.

About 64-bit tunes, I need some guidance about the approach for adding 
specific tunes for aarch64.
I tried to inherit the ones from 32-bit and to add the aarch64 feature, but 
I got those errors when building libgcc-initial:

| aarch64_be-oe-linux-gcc: error: unrecognized command line option 
'-mfpu=crypto-neon-fp-armv8'
| aarch64_be-oe-linux-gcc: error: unrecognized command line option '-marm'
| aarch64_be-oe-linux-gcc: error: unrecognized command line option '-mfpu=neon'
| aarch64_be-oe-linux-gcc: error: unrecognized command line option 
'-mfloat-abi=hard'

I searched and I found that aarch64 didn't support thumb or neon options:
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
It seems that AArch64 and ARM backends are completely separate in gcc.
  
For aarch64 I found just those options:
‘crc’
Enable CRC extension. This is on by default for -march=armv8.1-a.
‘crypto’
Enable Crypto extension. This also enables Advanced SIMD and floating-point 
instructions.
‘fp’
Enable floating-point instructions. This is on by default for all possible 
values for options 
-march and -mcpu.
‘simd’
Enable Advanced SIMD instructions. This also enables floating-point 
instructions. 
This is on by default for all possible values for options -march and -mcpu.
‘lse’
Enable Large System Extension instructions. This is on by default for 
-march=armv8.1-a.

Any help will be highly appreciated!

Thanks,
Daniel

Daniel Dragomir (1):
  arch-armv8a.inc: Add tune for 32-bit ARMv8a

 meta/conf/machine/include/arm/arch-armv8a.inc  | 382 +
 .../conf/machine/include/arm/feature-arm-thumb.inc |   1 +
 2 files changed, 383 insertions(+)
 create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc

-- 
1.9.1

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

Re: [OE-core] [RFC PATCH 0/3] Remove RPM 4

[Richard Purdie]

On Fri, 2016-03-11 at 14:07 +, Joshua Lock wrote:
> This series removes RPM 4 and code to support it from OE Core. There
> are
> several known issues with using RPM 4 and it seems better to
> acknowledge it's
> unsupported by removing it from OE-Core than to leave  it in a non
> -functional
> state.
> 
> Please review the following changes for suitability for inclusion. If
> you have
> any objections or suggestions for improvement, please respond to the
> patches. If
> you agree with the changes, please provide your Acked-by.

I think I'm in favour of removing it at this point as its not getting
much attention.

I'd note that we need to remove the QA test for it:

selftest/imagefeatures.py:def test_rpm_version_4_support_on_image(self):

Cheers,

Richard


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

[OE-core] [PATCH] gobject-introspection: stop GLib linking to GConf

[Ross Burton]

If gconf is installed in the sysroot then GLib will use it by default for the
GSettings backend.  This will pull a lot more libraries into the scanner
processes and expands the potential for bad linking through the imperfect qemu
user-mode emulation.

Set GSETTINGS_BACKEND=memory to force it to use the stub backend.  It's possible
that other fixes (such as glib relocation) have mitigated the damage that this
causes but right now it's better to be safe than sorry.

Signed-off-by: Ross Burton 
---
 meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
index 684d7cf..384204c 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
@@ -54,6 +54,7 @@ do_configure_prepend_class-target() {
 cat > ${B}/g-ir-scanner-qemuwrapper << EOF
 #!/bin/sh
 export GIO_MODULE_DIR=${STAGING_LIBDIR}/gio/modules
+export GSETTINGS_BACKEND=memory
 
 $qemu_binary "\$@"
 if [ \$? -ne 0 ]; then
-- 
2.7.0

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

Re: [OE-core] what is the precise search path for resolving "include" or "require" .inc files?

[Robert P. J. Day]

Quoting Christopher Larson :


On Fri, Mar 11, 2016 at 5:08 AM Robert P. J. Day 
wrote:


   not sure why i never noticed this before, but what is the search order
or precedence or priority for resolving recipe file directives "include"
or "require"? i was just perusing the bitbake user manual, and noticed
the explanation that those directives use BBPATH to track down the first
include file by a given name.

   but AIUI, BBPATH is supposed to represent an ordered set of *layers*
(i just examined BBPATH for a current [wind river linux] build, and that
is exactly what it seems to contain). so when a recipe file like
busybox.whatever.bb contains the line:

   require busybox.inc

i always just assumed the search would look in the current busybox
directory, but that directory is not technically a layer directory --
it's not a directory specified on the alleged BBPATH search path.

   i never thought about this until i noticed some .bbappend files
specifically using directives like:

   require recipes-bsp/u-boot/u-boot.inc

where that file reference *does* refer to a file relative to some
actual layer directory somewhere.

   what am i missing here?



BBPATH is temporarily prepended to include the directory the recipe lives
in, as a special case.


  i *assumed* that must have been what was happening, i just didn't see
that explicitly mentioned in the bitbake user manual. and while we're
talking about the bitbake user manual here:

http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html

this can't be right, can it?

"3.3.1. Locating Include and Class Files¶

"BitBake uses the BBPATH variable to locate needed include and class files.
The BBPATH variable is analogous to the environment variable PATH.

"In order for include and class files to be found by BitBake, they need to
be located in a "classes" subdirectory that can be found in BBPATH."

  while that statement might be true for class files, pretty sure it
isn't true for *include* files, as it suggests.

rday

p.s. i should probably submit another proofreading patch, to tweak stuff
like this in section 3.3.2:

"In this case, BitBake would search for the directory [sic]  
classes/autotools.bbclass in BBPATH."




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

Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[Burton, Ross]

On 11 March 2016 at 16:24, Helio Chissini De Castro <
helio.cas...@bmw-carit.de> wrote:

> If i change recipe scope, need to be on each gcc_${PV}.inc.
> But they include gcc-common.inc on top, which states LICENSE = "GPL"
>
> So, gcc_${PV}.inc is already overriding the original license. If you think
> is ok, i can do that on gcc_${PV}.inc
>

No,you're right - your v2 is the best patch.

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

[OE-core] [PATCH] scripts/oe-selftest: Add short names to most common options

[humberto . ibarra . lopez]

From: Humberto Ibarra 

Add short names to most common options in oe-selftest. The options
changed were --run-tests, --run-all-tests, --list-tests and
--list-modules.

[Yocto #9079]

Signed-off-by: Humberto Ibarra 
---
 scripts/oe-selftest | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/oe-selftest b/scripts/oe-selftest
index de98a6c..f13b1bd 100755
--- a/scripts/oe-selftest
+++ b/scripts/oe-selftest
@@ -73,9 +73,9 @@ def get_args_parser():
 description = "Script that runs unit tests agains bitbake and other Yocto 
related tools. The goal is to validate tools functionality and metadata 
integrity. Refer to https://wiki.yoctoproject.org/wiki/Oe-selftest for more 
information."
 parser = argparse_oe.ArgumentParser(description=description)
 group = parser.add_mutually_exclusive_group(required=True)
-group.add_argument('--run-tests', required=False, action='store', 
nargs='*', dest="run_tests", default=None, help='Select what tests to run 
(modules, classes or test methods). Format should be: 
..')
-group.add_argument('--run-all-tests', required=False, action="store_true", 
dest="run_all_tests", default=False, help='Run all (unhidden) tests')
-group.add_argument('--list-modules', required=False, action="store_true", 
dest="list_modules", default=False, help='List all available test modules.')
+group.add_argument('-r', '--run-tests', required=False, action='store', 
nargs='*', dest="run_tests", default=None, help='Select what tests to run 
(modules, classes or test methods). Format should be: 
..')
+group.add_argument('-a', '--run-all-tests', required=False, 
action="store_true", dest="run_all_tests", default=False, help='Run all 
(unhidden) tests')
+group.add_argument('-m', '--list-modules', required=False, 
action="store_true", dest="list_modules", default=False, help='List all 
available test modules.')
 group.add_argument('--list-classes', required=False, action="store_true", 
dest="list_allclasses", default=False, help='List all available test classes.')
 parser.add_argument('--coverage', action="store_true", help="Run code 
coverage when testing")
 parser.add_argument('--coverage-source', dest="coverage_source", 
nargs="+", help="Specifiy the directories to take coverage from")
@@ -85,7 +85,7 @@ def get_args_parser():
help='run-tests-by  ')
 group.add_argument('--list-tests-by', required=False, 
dest='list_tests_by', default=False, nargs='*',
help='list-tests-by  ')
-group.add_argument('--list-tests', required=False,  action="store_true", 
dest="list_tests", default=False,
+group.add_argument('-l', '--list-tests', required=False,  
action="store_true", dest="list_tests", default=False,
help='List all available tests.')
 group.add_argument('--list-tags', required=False, dest='list_tags', 
default=False, action="store_true",
help='List all tags that have been set to test cases.')
-- 
1.9.1

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

[OE-core] [PATCH v2][fido] dhcp: CVE-2015-8605

[mariano . lopez]

From: Mariano Lopez 

ISC DHCP allows remote attackers to cause a denial of
service (application crash) via an invalid length field
in a UDP IPv4 packet.

Signed-off-by: Mariano Lopez 
---
 .../dhcp/dhcp/CVE-2015-8605.patch  | 101 
 .../dhcp/dhcp/CVE-2015-8605_1.patch| 131 +
 meta/recipes-connectivity/dhcp/dhcp_4.3.1.bb   |   2 +
 3 files changed, 234 insertions(+)
 create mode 100644 meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
 create mode 100644 meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605_1.patch

diff --git a/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch 
b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
new file mode 100644
index 000..05f1fa9
--- /dev/null
+++ b/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605.patch
@@ -0,0 +1,101 @@
+Solves CVE-2015-8605 that caused DoS when an invalid length field in IPv4 UDP
+was received by the server.
+
+Upstream-Status: Backport (v4.3.3p1)
+CVE: CVE-2015-8605
+
+From: 
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commit;h=4ce21cb6301d665de01c1a6209e40f5f35072c0c
+
+Signed-off-by: Mariano Lopez 
+
+===
+diff --git a/common/packet.c b/common/packet.c
+index b530432..e600e37 100644
+--- a/common/packet.c
 b/common/packet.c
+@@ -220,7 +220,28 @@ ssize_t decode_hw_header (interface, buf, bufix, from)
+   }
+ }
+ 
+-/* UDP header and IP header decoded together for convenience. */
++/*!
++ *
++ * \brief UDP header and IP header decoded together for convenience.
++ *
++ * Attempt to decode the UDP and IP headers and, if necessary, checksum
++ * the packet.
++ *
++ * \param inteface - the interface on which the packet was recevied
++ * \param buf - a pointer to the buffer for the received packet
++ * \param bufix - where to start processing the buffer, previous
++ *routines may have processed parts of the buffer already
++ * \param from - space to return the address of the packet sender
++ * \param buflen - remaining length of the buffer, this will have been
++ * decremented by bufix by the caller
++ * \param rbuflen - space to return the length of the payload from the udp
++ *  header
++ * \param csum_ready - indication if the checksum is valid for use
++ * non-zero indicates the checksum should be validated
++ *
++ * \return - the index to the first byte of the udp payload (that is the
++ *   start of the DHCP packet
++ */
+ 
+ ssize_t
+ decode_udp_ip_header(struct interface_info *interface,
+@@ -231,7 +252,7 @@ decode_udp_ip_header(struct interface_info *interface,
+   unsigned char *data;
+   struct ip ip;
+   struct udphdr udp;
+-  unsigned char *upp, *endbuf;
++  unsigned char *upp;
+   u_int32_t ip_len, ulen, pkt_len;
+   static unsigned int ip_packets_seen = 0;
+   static unsigned int ip_packets_bad_checksum = 0;
+@@ -241,11 +262,8 @@ decode_udp_ip_header(struct interface_info *interface,
+   static unsigned int udp_packets_length_overflow = 0;
+   unsigned len;
+ 
+-  /* Designate the end of the input buffer for bounds checks. */
+-  endbuf = buf + bufix + buflen;
+-
+   /* Assure there is at least an IP header there. */
+-  if ((buf + bufix + sizeof(ip)) > endbuf)
++  if (sizeof(ip) > buflen)
+ return -1;
+ 
+   /* Copy the IP header into a stack aligned structure for inspection.
+@@ -257,13 +275,17 @@ decode_udp_ip_header(struct interface_info *interface,
+   ip_len = (*upp & 0x0f) << 2;
+   upp += ip_len;
+ 
+-  /* Check the IP packet length. */
++  /* Check packet lengths are within the buffer:
++   * first the ip header (ip_len)
++   * then the packet length from the ip header (pkt_len)
++   * then the udp header (ip_len + sizeof(udp)
++   * We are liberal in what we accept, the udp payload should fit within
++   * pkt_len, but we only check against the full buffer size.
++   */
+   pkt_len = ntohs(ip.ip_len);
+-  if (pkt_len > buflen)
+-  return -1;
+-
+-  /* Assure after ip_len bytes that there is enough room for a UDP header. */
+-  if ((upp + sizeof(udp)) > endbuf)
++  if ((ip_len > buflen) ||
++  (pkt_len > buflen) ||
++  ((ip_len + sizeof(udp)) > buflen))
+ return -1;
+ 
+   /* Copy the UDP header into a stack aligned structure for inspection. */
+@@ -284,7 +306,8 @@ decode_udp_ip_header(struct interface_info *interface,
+   return -1;
+ 
+   udp_packets_length_checked++;
+-  if ((upp + ulen) > endbuf) {
++  /* verify that the payload length from the udp packet fits in the buffer */
++  if ((ip_len + ulen) > buflen) {
+   udp_packets_length_overflow++;
+   if (((udp_packets_length_checked > 4) &&
+(udp_packets_length_overflow != 0)) &&
diff --git a/meta/recipes-connectivity/dhcp/dhcp/CVE-2015-8605_1.patch 

Re: [OE-core] [PATCH 1/1] ncurses_6: Fix an install race condition

[Bystricky, Juro]

The patch patches an .awk file that is used to create several Makefiles.
The original code looks something like this:

install install.libs install.includes ::
   install files

So we see that install.libs and install.includes do exactly the same thing.

Given our ncurses recipe installs explicitly both targets:

“make install.libs install.includes “ the race is obvious.

So one way to fix it would be to prepend
.NOTPARALLEL install.libs install.includes

This would solve the race, but some files would be installed twice.
The other way, (the one implemented by the patch) is to create Makefiles 
containing:

install.libs :: ;

install install.includes::
   install files

This way the files are installed only once, and we can use parallel make.
So as long as we install explicitly install.libs and install.includes (and we 
do) , ncurses should
install the way they were meant to.
I believe there would be no race if we used a simple  “ make install”, but this 
would
probably install additional components we don’t care about.
Yes, ncurses is weird. They rely heavily on the ‘::’ rules, so rules for each 
target
are scattered in various places so it is not obvious to see the big picture 
when it comes to
dependencies.




From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, March 11, 2016 1:36 AM
To: Bystricky, Juro 
Cc: OE-core ; Juro Bystricky 

Subject: Re: [OE-core] [PATCH 1/1] ncurses_6: Fix an install race condition

Hi Juro,

On 11 March 2016 at 02:07, Juro Bystricky 
> wrote:
+As both targets install identical files. The remedy is to either prevent
+parallel make of install.libs and install.includes, or ensure only one
+target installs the files.
+The second approch will only work if we always install both libs and
+includes (which we do).

Wouldn't an upstreamable fix be to make install.includes the target that 
actually does something, and then have install depend on that?  Considering 
install.libs and install.includes are separate rules, surely install.libs in 
the header makefile should do nothing?  (ncurses is weird...)

Have you checked the other makefiles for the same problem?

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

[OE-core] Yocto Project Status WW11

[Jolley, Stephen K]

Current Dev Position: YP 2.1 M4 (Stabilization only milestone.)

Next Deadline: YP 2.1 M3 Target release date is March 18, 2016 (Will be late, 
see status)


SWAT team rotation: Jussi -> Maxin

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

*The good news first, uninative is now default in poky and this has 
improved build performance on the autobuilders. The rpm upgrade patch set 
finally passed testing and also merged along with many other smaller patches.

*The bad news is that gobject-introspection still possibly has some 
issues we don't understand although the past couple of builds have been clean. 
We also still don't understand exactly how/why prelink is breaking glib linked 
binaries using fork() although its related to the IFUNC shadow function in 
libpthread.

*There continue to be a number of niggling issues with various patches 
(e.g. the xcursor-transparent patch broke various selftests and the source 
archiver selftest is still broken).  There are some parallelism races which are 
still being worked on (perf for example, ncurses patches under discussion).

*Hob has finally been removed. The functionality of Hob has been 
replaced by Toaster.

*The removal of Hob has broken build-appliance and I may take patches 
in M4 to replace this with something better, likely container based and 
including toaster instead.

*I've been made aware there were a number of QA patches which were 
blocked on review, these may also be taken in M4 as it was on the fault of the 
reviewers that they were blocked.

*2.0.1 was finally released.

*The mitigation plan would be to merge gobject-introspection and hope 
we've resolved the issues, disable prelink and get a build into QA for M3 ASAP 
but it depends on the other smaller details also getting resolved.


Key YP 2.1 Dates:

YP 2.1 M3 Target release date is March 18, 2016 (Will be late, see status)

YP 2.1 M4 / Final Cutoff: March 28, 2016 noon GMT - Stabilization only 
milestone.

YP 2.1 Final Release Target: April 29, 2016


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.1_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.1_Features


Tracking Metrics:

WDD 2628 (last week 2577 )

(https://wiki.yoctoproject.org/charts/combo.html)


[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:stephen.k.jol...@intel.com

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

[OE-core] [PATCH] scripts/oe-selftest: Add search expression matching to run/list options

[humberto . ibarra . lopez]

From: Humberto Ibarra 

The oe-selftest script required an exact matching for the parameters
passed to its run-tests-by and list-tests-by options. Many tests
can be retrieved here and filtering is a must.

This patch add this filtering functionality by enabling the use
of wildcards such as "*".

[Yocto #8916]

Signed-off-by: Humberto Ibarra 
---
 scripts/oe-selftest | 108 +---
 1 file changed, 44 insertions(+), 64 deletions(-)

diff --git a/scripts/oe-selftest b/scripts/oe-selftest
index de98a6c..4c92f6d 100755
--- a/scripts/oe-selftest
+++ b/scripts/oe-selftest
@@ -243,93 +243,73 @@ def get_all_tests():
 testlist += get_tests_from_module(tmod)
 return testlist
 
-
-def create_testsuite_by(criteria, keyword):
-# Create a testsuite based on 'keyword'
-# criteria: name, class, module, id, tag
-# keyword: a list of tests, classes, modules, ids, tags
-# NOTE: globing would be nice?
-
-ts = set()
-all_tests = get_all_tests()
-
-if criteria == 'name':
-for tc in all_tests:
-if tc.tcname in keyword:
-ts.add(tc.fullpath)
-
-elif criteria == 'class':
-for tc in all_tests:
-if tc.tcclass in keyword:
-ts.add(tc.fullpath)
-
-elif criteria == 'module':
-for tc in all_tests:
-if tc.tcmodule in keyword:
-ts.add(tc.fullpath)
-elif criteria == 'id':
-for tc in all_tests:
-if str(tc.tcid) in keyword:
-ts.add(tc.fullpath)
-elif criteria == 'tag':
-for tc in all_tests:
-# tc can have multiple tags (as list or tuple) otherwise as str
-if isinstance(tc.tctag, (list, tuple)):
-for tag in tc.tctag:
-if str(tag) in keyword:
-ts.add(tc.fullpath)
-elif tc.tctag in keyword:
-ts.add(tc.fullpath)
-
-return sorted(list(ts))
-
-
 def get_testsuite_by(criteria, keyword):
 # Get a testsuite based on 'keyword'
 # criteria: name, class, module, id, tag
 # keyword: a list of tests, classes, modules, ids, tags
-# NOTE: globing would be nice?
-ts = set()
+
+import re
+import fnmatch
+
+ts = []
 all_tests = get_all_tests()
 
+def get_matches(values):
+# Get a items and return the ones that match with keyword(s)
+# values: the list of items (names, modules, classes...)
+result = []
+remaining = values[:]
+for key in keyword:
+if key in remaining:
+# Regular matching of exact item
+result.append(key)
+remaining.remove(key)
+else:
+# Wildcard matching
+pattern = re.compile(fnmatch.translate(r"%s" % key))
+added = [ x for x in remaining if pattern.match(x) ]
+result.extend(added)
+remaining = [ x for x in remaining if not x in added ]
+
+return result
+
 if criteria == 'name':
-for tc in all_tests:
-if tc.tcname in keyword:
-ts.add((tc.tcid, tc.tctag, tc.tcname, tc.tcclass, tc.tcmodule))
+names = get_matches([ tc.tcname for tc in all_tests ])
+ts = [ tc for tc in all_tests if tc.tcname in names ]
 
 elif criteria == 'class':
-for tc in all_tests:
-if tc.tcclass in keyword:
-ts.add((tc.tcid, tc.tctag, tc.tcname, tc.tcclass, tc.tcmodule))
+classes = get_matches([ tc.tcclass for tc in all_tests ])
+ts = [ tc for tc in all_tests if tc.tcclass in classes ]
 
 elif criteria == 'module':
-for tc in all_tests:
-if tc.tcmodule in keyword:
-ts.add((tc.tcid, tc.tctag, tc.tcname, tc.tcclass, tc.tcmodule))
+modules = get_matches([ tc.tcmodule for tc in all_tests ])
+ts = [ tc for tc in all_tests if tc.tcmodule in modules ]
+
 elif criteria == 'id':
-for tc in all_tests:
-if str(tc.tcid) in keyword:
-ts.add((tc.tcid, tc.tctag, tc.tcname, tc.tcclass, tc.tcmodule))
+ids = get_matches([ str(tc.tcid) for tc in all_tests ])
+ts = [ tc for tc in all_tests if str(tc.tcid) in ids ]
+
 elif criteria == 'tag':
+values = set()
 for tc in all_tests:
 # tc can have multiple tags (as list or tuple) otherwise as str
 if isinstance(tc.tctag, (list, tuple)):
-for tag in tc.tctag:
-if str(tag) in keyword:
-ts.add((tc.tcid, tc.tctag, tc.tcname, tc.tcclass, 
tc.tcmodule))
-elif str(tc.tctag) in keyword:
-ts.add((tc.tcid, tc.tctag, tc.tcname, tc.tcclass, tc.tcmodule))
+values |= { str(tag) for tag in tc.tctag }
+else:
+

Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[Helio Chissini De Castro]

If i change recipe scope, need to be on each gcc_${PV}.inc.
But they include gcc-common.inc on top, which states LICENSE = "GPL"

So, gcc_${PV}.inc is already overriding the original license. If you think is 
ok, i can do that on gcc_${PV}.inc

[]'s

--
BMW Car IT GmbH
Helio Chissini de Castro
Systems Integrator Engineer
Lise-Meitner-Str.14
89081 Ulm
Mobil: +49 176 25435150
Mail: helio.cas...@bmw-carit.de
Web: http://www.bmw-carit.de

From: Khem Raj [raj.k...@gmail.com]
Sent: Friday, March 11, 2016 5:11 PM
To: Burton, Ross
Cc: Helio Chissini De Castro; OE-core
Subject: Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP


On Mar 11, 2016, at 11:02 PM, Burton, Ross 
> wrote:


2016-03-11 15:58 GMT+00:00 Khem Raj 
>:
-BEGIN PGP MESSAGE-
Comment: GPGTools - https://gpgtools.org

hQQOA1XJCHN89ZWPEA//byr/rrxGxNNYYivYsGFBs4h6XrUzdqBCsw2FuyseGKJ1
XkZUtuH7f39QYY63OoqFhFdVmy3Hil3wscxe38L6/DA8hQV9Csn4cOxEfp9UF5jj
+3QJg/xqk7cgXTLuoUen9JZQHZgnG6+IfBg6jJARCKTmcs8aCT8WU2DYWycGCGg5

Can you send it non-encrypted? :)

patch is ok. It was an oversight that its fixing.


Ross

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

Re: [OE-core] State of bitbake world, Failed tasks 2016-03-09

[Bruce Ashfield]

On Fri, Mar 11, 2016 at 11:13 AM, Martin Jansa 
wrote:

> On Fri, Mar 11, 2016 at 10:52:14AM -0500, Bruce Ashfield wrote:
> > On Fri, Mar 11, 2016 at 10:41 AM, Mark Hatle 
> > wrote:
> >
> > > On 3/10/16 5:53 AM, Martin Jansa wrote:
> > > > Aggressive PNBLACKLISTing continues. But linux-yocto (and modules
> > > depending on it)
> > > > are still broken :/.
> > > >
> > > > I'll look at cef3 and chromium issue, my recent patch for
> meta-browser
> > > > fixed the build for armv7a MACHINEs, so it probably needs to be
> extended
> > > > a bit to cover warnings in x86 and then duplicate the same to cef3.
> > > > This issue is there for so long, slowing down the builds
> significantly
> > > > (and causing logs to be much bigger) - I don't use these recipes but
> I
> > > > hate the failures even more.
> > > >
> > >
> > > Is see the reported log failure, but I've been building with the
> oe-core
> > > and
> > > poky linux-yocto head of master for the last couple weeks, all arches
> > > includes
> > > qemux86.
> > >
> >
> >
> > I don't know what to say about those failures either. I've been chasing
> > perf build
> > races for the past week, and that includes building linux-yocto hundreds
> of
> > times,
> > and I've never seen the uapi headers not be in place like the logs show.
>
> My guess (and supported by Andrea) is that it's caused by
> linux-yocto-tiny which is built as part of bitbake world and probably
> not included in your tests when you build the same linux-yocto.
>
>
Aha. Thanks, I'm working those problems as well and did reproduce a variant
when rm_work is enabled. So I do have a thread to tug on for the failure.

With that, plus your description below, I've got a better chance of seeing
it.

Cheers,

Bruce


> That would also explain why these issues break almost every qemux86 and
> I haven't seen them for qemuarm, linux-yocto-tiny has:
>   COMPATIBLE_MACHINE = "(qemux86)"
>
> Try to run
> "bitbake linux-yocto linux-yocto-tiny" couple times and maybe you'll be
> able to reproduce it.
>
> For next runs I've PNBLACKLISTED linux-yocto-tiny and
> linux-yocto-tiny-kexecboot:
>
> https://github.com/shr-project/jenkins-jobs/commit/c168b7824c2c68bd5894532fc122929d2d9df9a7
>
> > The Yocto AB is also not showing it to me.
> >
> > Unless I can get access to a broken build, I'm at a loss to actually
> debug
> > and
> > fix it.
> >
> > Bruce
> >
> >
> > >
> > > I don't see the error on my builder.  Is something changing the default
> > > recipe/kernel configuration triggering the fault?
> > >
> > > --Mark
> > >
> > > > === qemux86 (2) ===
> > > > * /meta-openembedded/meta-python/recipes-devtools/python/
> > > python-m2crypto_0.23.0.bb, do_compile
> > > > * /openembedded-core/meta/recipes-kernel/linux/
> linux-yocto_4.4.bb,
> > > do_compile
> > >
> > >
> > > --
> > > ___
> > > 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"
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>



-- 
"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

Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[Khem Raj]

> On Mar 11, 2016, at 11:02 PM, Burton, Ross  wrote:
> 
> 
> 2016-03-11 15:58 GMT+00:00 Khem Raj  >:
> -BEGIN PGP MESSAGE-
> Comment: GPGTools - https://gpgtools.org 
> 
> hQQOA1XJCHN89ZWPEA//byr/rrxGxNNYYivYsGFBs4h6XrUzdqBCsw2FuyseGKJ1
> XkZUtuH7f39QYY63OoqFhFdVmy3Hil3wscxe38L6/DA8hQV9Csn4cOxEfp9UF5jj
> +3QJg/xqk7cgXTLuoUen9JZQHZgnG6+IfBg6jJARCKTmcs8aCT8WU2DYWycGCGg5
> 
> Can you send it non-encrypted? :)

patch is ok. It was an oversight that its fixing.

> 
> Ross



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] State of bitbake world, Failed tasks 2016-03-09

[Martin Jansa]

On Fri, Mar 11, 2016 at 10:52:14AM -0500, Bruce Ashfield wrote:
> On Fri, Mar 11, 2016 at 10:41 AM, Mark Hatle 
> wrote:
> 
> > On 3/10/16 5:53 AM, Martin Jansa wrote:
> > > Aggressive PNBLACKLISTing continues. But linux-yocto (and modules
> > depending on it)
> > > are still broken :/.
> > >
> > > I'll look at cef3 and chromium issue, my recent patch for meta-browser
> > > fixed the build for armv7a MACHINEs, so it probably needs to be extended
> > > a bit to cover warnings in x86 and then duplicate the same to cef3.
> > > This issue is there for so long, slowing down the builds significantly
> > > (and causing logs to be much bigger) - I don't use these recipes but I
> > > hate the failures even more.
> > >
> >
> > Is see the reported log failure, but I've been building with the oe-core
> > and
> > poky linux-yocto head of master for the last couple weeks, all arches
> > includes
> > qemux86.
> >
> 
> 
> I don't know what to say about those failures either. I've been chasing
> perf build
> races for the past week, and that includes building linux-yocto hundreds of
> times,
> and I've never seen the uapi headers not be in place like the logs show.

My guess (and supported by Andrea) is that it's caused by
linux-yocto-tiny which is built as part of bitbake world and probably
not included in your tests when you build the same linux-yocto.

That would also explain why these issues break almost every qemux86 and
I haven't seen them for qemuarm, linux-yocto-tiny has:
  COMPATIBLE_MACHINE = "(qemux86)"

Try to run
"bitbake linux-yocto linux-yocto-tiny" couple times and maybe you'll be
able to reproduce it.

For next runs I've PNBLACKLISTED linux-yocto-tiny and
linux-yocto-tiny-kexecboot:
https://github.com/shr-project/jenkins-jobs/commit/c168b7824c2c68bd5894532fc122929d2d9df9a7

> The Yocto AB is also not showing it to me.
> 
> Unless I can get access to a broken build, I'm at a loss to actually debug
> and
> fix it.
> 
> Bruce
> 
> 
> >
> > I don't see the error on my builder.  Is something changing the default
> > recipe/kernel configuration triggering the fault?
> >
> > --Mark
> >
> > > === qemux86 (2) ===
> > > * /meta-openembedded/meta-python/recipes-devtools/python/
> > python-m2crypto_0.23.0.bb, do_compile
> > > * /openembedded-core/meta/recipes-kernel/linux/linux-yocto_4.4.bb,
> > do_compile
> >
> >
> > --
> > ___
> > 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"

-- 
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] [PATCH] gcc: Fix the license on GNU OpenMP

[Burton, Ross]

On 11 March 2016 at 15:55, Burton, Ross  wrote:

> On 11 March 2016 at 15:53, Helio Chissini De Castro <
> helio.cas...@bmw-carit.de> wrote:
>
>> Since all the packages now share exactly the same license, there's no
>> reason anymore to specify each one of then, unless wanted to keep the names
>> to know which packages are related to this recipe.
>>
>
> That's a good point, thanks.
>

Follow up question - why not just set the recipe-scope LICENSE to
GPL3-with-gcc-exception and remove all package-specific license assignments.

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

Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[Burton, Ross]

2016-03-11 15:58 GMT+00:00 Khem Raj :

> -BEGIN PGP MESSAGE-
> Comment: GPGTools - https://gpgtools.org
>
> hQQOA1XJCHN89ZWPEA//byr/rrxGxNNYYivYsGFBs4h6XrUzdqBCsw2FuyseGKJ1
> XkZUtuH7f39QYY63OoqFhFdVmy3Hil3wscxe38L6/DA8hQV9Csn4cOxEfp9UF5jj
> +3QJg/xqk7cgXTLuoUen9JZQHZgnG6+IfBg6jJARCKTmcs8aCT8WU2DYWycGCGg5
>

Can you send it non-encrypted? :)

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

Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[Helio Chissini De Castro]

Hello Ross

The previous lines existed just because the unique statement on thelibgomp that 
was GPLv3 alone

Since all the packages now share exactly the same license, there's no reason 
anymore to specify each one of then, unless wanted to keep the names to know 
which packages are related to this recipe.

[]'s

--
BMW Car IT GmbH
Helio Chissini de Castro
Systems Integrator Engineer
Lise-Meitner-Str.14
89081 Ulm
Mobil: +49 176 25435150
Mail: helio.cas...@bmw-carit.de
Web: http://www.bmw-carit.de

--
BMW Car IT GmbH
Helio Chissini de Castro
Systems Integrator Engineer
Lise-Meitner-Str.14
89081 Ulm
Mobil: +49 176 25435150
Mail: helio.cas...@bmw-carit.de
Web: http://www.bmw-carit.de

From: Burton, Ross [ross.bur...@intel.com]
Sent: Friday, March 11, 2016 4:39 PM
To: Helio Chissini De Castro
Cc: OE-core
Subject: Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP


On 11 March 2016 at 14:24, 
> wrote:
-# Most libraries are licensed with the exception, but
-# one library is really GPLv3.
-#
-LICENSE_${PN}-dbg = "GPL-3.0-with-GCC-exception & GPLv3"
-LICENSE_libstdc++ = "GPL-3.0-with-GCC-exception"
-LICENSE_libstdc++-precompile-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libstdc++-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libstdc++-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libg2c = "GPL-3.0-with-GCC-exception"
-LICENSE_libg2c-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libssp = "GPL-3.0-with-GCC-exception"
-LICENSE_libssp-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libssp-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libgfortran = "GPL-3.0-with-GCC-exception"
-LICENSE_libgfortran-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libgfortran-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libmudflap = "GPL-3.0-with-GCC-exception"
-LICENSE_libmudflap-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libmudflap-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libquadmath = "GPL-3.0-with-GCC-exception"
-LICENSE_libquadmath-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libquadmath-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libatomic = "GPL-3.0-with-GCC-exception"
-LICENSE_libatomic-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libatomic-staticdev = "GPL-3.0-with-GCC-exception"
-
-LICENSE_libgomp = "GPLv3"
-LICENSE_libgomp-dev = "GPLv3"
-LICENSE_libgomp-staticdev = "GPLv3"
+LICENSE_${PN}-dbg = "GPL-3.0-with-GCC-exception"
+LICENSE_${PN} = "GPL-3.0-with-GCC-exception"
+LICENSE_${PN}-dev = "GPL-3.0-with-GCC-exception"
+LICENSE_${PN}-staticdev = "GPL-3.0-with-GCC-exception"

This patch doesn't look right...

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

Re: [OE-core] State of bitbake world, Failed tasks 2016-03-09

[Bruce Ashfield]

On Fri, Mar 11, 2016 at 10:41 AM, Mark Hatle 
wrote:

> On 3/10/16 5:53 AM, Martin Jansa wrote:
> > Aggressive PNBLACKLISTing continues. But linux-yocto (and modules
> depending on it)
> > are still broken :/.
> >
> > I'll look at cef3 and chromium issue, my recent patch for meta-browser
> > fixed the build for armv7a MACHINEs, so it probably needs to be extended
> > a bit to cover warnings in x86 and then duplicate the same to cef3.
> > This issue is there for so long, slowing down the builds significantly
> > (and causing logs to be much bigger) - I don't use these recipes but I
> > hate the failures even more.
> >
>
> Is see the reported log failure, but I've been building with the oe-core
> and
> poky linux-yocto head of master for the last couple weeks, all arches
> includes
> qemux86.
>


I don't know what to say about those failures either. I've been chasing
perf build
races for the past week, and that includes building linux-yocto hundreds of
times,
and I've never seen the uapi headers not be in place like the logs show.

The Yocto AB is also not showing it to me.

Unless I can get access to a broken build, I'm at a loss to actually debug
and
fix it.

Bruce


>
> I don't see the error on my builder.  Is something changing the default
> recipe/kernel configuration triggering the fault?
>
> --Mark
>
> > === qemux86 (2) ===
> > * /meta-openembedded/meta-python/recipes-devtools/python/
> python-m2crypto_0.23.0.bb, do_compile
> > * /openembedded-core/meta/recipes-kernel/linux/linux-yocto_4.4.bb,
> do_compile
>
>
> --
> ___
> 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

Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[Khem Raj]

binXmwsx5UEju.bin
Description: PGP/MIME Versions Identification


encrypted.asc
Description: OpenPGP encrypted message
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[Burton, Ross]

On 11 March 2016 at 15:53, Helio Chissini De Castro <
helio.cas...@bmw-carit.de> wrote:

> Since all the packages now share exactly the same license, there's no
> reason anymore to specify each one of then, unless wanted to keep the names
> to know which packages are related to this recipe.
>

That's a good point, thanks.

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

Re: [OE-core] State of bitbake world, Failed tasks 2016-03-09

[Mark Hatle]

On 3/10/16 5:53 AM, Martin Jansa wrote:
> Aggressive PNBLACKLISTing continues. But linux-yocto (and modules depending 
> on it)
> are still broken :/.
> 
> I'll look at cef3 and chromium issue, my recent patch for meta-browser
> fixed the build for armv7a MACHINEs, so it probably needs to be extended
> a bit to cover warnings in x86 and then duplicate the same to cef3.
> This issue is there for so long, slowing down the builds significantly
> (and causing logs to be much bigger) - I don't use these recipes but I
> hate the failures even more.
> 

Is see the reported log failure, but I've been building with the oe-core and
poky linux-yocto head of master for the last couple weeks, all arches includes
qemux86.

I don't see the error on my builder.  Is something changing the default
recipe/kernel configuration triggering the fault?

--Mark

> === qemux86 (2) ===
> * 
> /meta-openembedded/meta-python/recipes-devtools/python/python-m2crypto_0.23.0.bb,
>  do_compile
> * /openembedded-core/meta/recipes-kernel/linux/linux-yocto_4.4.bb, 
> do_compile


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

Re: [OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[Burton, Ross]

On 11 March 2016 at 14:24,  wrote:

> -# Most libraries are licensed with the exception, but
> -# one library is really GPLv3.
> -#
> -LICENSE_${PN}-dbg = "GPL-3.0-with-GCC-exception & GPLv3"
> -LICENSE_libstdc++ = "GPL-3.0-with-GCC-exception"
> -LICENSE_libstdc++-precompile-dev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libstdc++-dev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libstdc++-staticdev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libg2c = "GPL-3.0-with-GCC-exception"
> -LICENSE_libg2c-dev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libssp = "GPL-3.0-with-GCC-exception"
> -LICENSE_libssp-dev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libssp-staticdev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libgfortran = "GPL-3.0-with-GCC-exception"
> -LICENSE_libgfortran-dev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libgfortran-staticdev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libmudflap = "GPL-3.0-with-GCC-exception"
> -LICENSE_libmudflap-dev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libmudflap-staticdev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libquadmath = "GPL-3.0-with-GCC-exception"
> -LICENSE_libquadmath-dev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libquadmath-staticdev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libatomic = "GPL-3.0-with-GCC-exception"
> -LICENSE_libatomic-dev = "GPL-3.0-with-GCC-exception"
> -LICENSE_libatomic-staticdev = "GPL-3.0-with-GCC-exception"
> -
> -LICENSE_libgomp = "GPLv3"
> -LICENSE_libgomp-dev = "GPLv3"
> -LICENSE_libgomp-staticdev = "GPLv3"
> +LICENSE_${PN}-dbg = "GPL-3.0-with-GCC-exception"
> +LICENSE_${PN} = "GPL-3.0-with-GCC-exception"
> +LICENSE_${PN}-dev = "GPL-3.0-with-GCC-exception"
> +LICENSE_${PN}-staticdev = "GPL-3.0-with-GCC-exception"
>

This patch doesn't look right...

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

[OE-core] [PATCH] glib-2.0: relocate the GIO module directory for native builds

[Ross Burton]

Glib hard-codes the install path in search path for GIO modules, which causes
problems when glib-2.0-native is restored from sstate with a different build
directory.

In the future we should relocate symbols directly using the same system that the
eSDK uses, but for now use dladdr() to look up where the library was loaded from
to build the search path.

Signed-off-by: Ross Burton 
---
 .../glib-2.0/glib-2.0/relocate-modules.patch   | 49 ++
 meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb  |  3 +-
 2 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch 
b/meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch
new file mode 100644
index 000..f9e3f3d
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch
@@ -0,0 +1,49 @@
+Instead of hard-coding GIO_MODULE_PATH when glib is built, use dladdr() to
+determine where libglib.so is and use that path to calculate GIO_MODULES_DIR.
+
+This solves relocation problems with GIOModule for native builds of glib.
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton 
+
+diff --git a/gio/giomodule.c b/gio/giomodule.c
+index 56c498c..a2e32b7 100644
+--- a/gio/giomodule.c
 b/gio/giomodule.c
+@@ -47,6 +47,27 @@
+ #include "gdesktopappinfo.h"
+ #endif
+ 
++#include 
++
++/*
++ * Generate a GIO module directory based on where glib is installed
++ */
++static const char *
++_get_gio_module_dir (void)
++{
++  Dl_info info;
++
++  if (dladdr (g_io_module_new, )) {
++char *libdir = g_path_get_dirname (info.dli_fname);
++char *dir = g_build_filename (libdir, "gio", "modules", NULL);
++g_free (libdir);
++return dir;
++  } else {
++return GIO_MODULE_DIR;
++  }
++}
++
++
+ /**
+  * SECTION:giomodule
+  * @short_description: Loadable GIO Modules
+@@ -1057,7 +1078,7 @@ _g_io_modules_ensure_loaded (void)
+   /* Then load the compiled in path */
+   module_dir = g_getenv ("GIO_MODULE_DIR");
+   if (module_dir == NULL)
+-module_dir = GIO_MODULE_DIR;
++module_dir = _get_gio_module_dir ();
+ 
+   g_io_modules_scan_all_in_directory_with_scope (module_dir, scope);
+ 
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb 
b/meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb
index bf3cade..2a2efae 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.46.2.bb
@@ -18,7 +18,8 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz 
\
file://gi-exclude.patch \
   "
 
-SRC_URI_append_class-native = " file://glib-gettextize-dir.patch"
+SRC_URI_append_class-native = " file://glib-gettextize-dir.patch \
+file://relocate-modules.patch"
 
 SRC_URI[md5sum] = "7f815d6e46df68e070cb421ed7f1139e"
 SRC_URI[sha256sum] = 
"5031722e37036719c1a09163cc6cf7c326e4c4f1f1e074b433c156862bd733db"
-- 
2.7.0

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

[OE-core] [PATCH 1/1] package_manager.py: Fix race condition in OpkgIndexer.write_index()

[mariano . lopez]

From: Mariano Lopez 

When writing the index using ipk packages there could be a race condition
when populate the index. This happens because the architectures
are repeated (specially all) and the commands generated to write the index
run in parallel.

This change avoid the duplication of commands using a set instead of a list.

[YOCTO #8924]

Signed-off-by: Mariano Lopez 
---
 meta/lib/oe/package_manager.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index b701b8c..fe3f8c5 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -157,7 +157,7 @@ class OpkgIndexer(Indexer):
 if not os.path.exists(os.path.join(self.deploy_dir, "Packages")):
 open(os.path.join(self.deploy_dir, "Packages"), "w").close()
 
-index_cmds = []
+index_cmds = set()
 for arch_var in arch_vars:
 archs = self.d.getVar(arch_var, True)
 if archs is None:
@@ -173,7 +173,7 @@ class OpkgIndexer(Indexer):
 if not os.path.exists(pkgs_file):
 open(pkgs_file, "w").close()
 
-index_cmds.append('%s -r %s -p %s -m %s' %
+index_cmds.add('%s -r %s -p %s -m %s' %
   (opkg_index_cmd, pkgs_file, pkgs_file, 
pkgs_dir))
 
 if len(index_cmds) == 0:
-- 
2.6.2

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

[OE-core] [oe-core][PATCH] python3: fix configure issue for powerpc-spe target

[Zhenhua Luo]

When confiure for powerpc-spe target, the following check will fail due to
PLATFORM_TRIPLET and MULTIARCH is not identical. PLATFORM_TRIPLET is set to
"powerpc-linux-gnuspe", MULTIARCH is "powerpc-linux-gnuspev1" which is returned
by $CC --print-multiarch. So set PLATFORM_TRIPLET to empty for powerpc-spe
target to skip the check.

Signed-off-by: Zhenhua Luo 
---
 ...ython3-fix-configure-issue-of-powerpc-spe.patch | 26 ++
 meta/recipes-devtools/python/python3_3.5.1.bb  |  1 +
 2 files changed, 27 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3/python3-fix-configure-issue-of-powerpc-spe.patch

diff --git 
a/meta/recipes-devtools/python/python3/python3-fix-configure-issue-of-powerpc-spe.patch
 
b/meta/recipes-devtools/python/python3/python3-fix-configure-issue-of-powerpc-spe.patch
new file mode 100644
index 000..c18a3e6
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/python3-fix-configure-issue-of-powerpc-spe.patch
@@ -0,0 +1,26 @@
+configure.ac: fix configure issue for powerpc-spe target
+
+When confiure for powerpc-spe target, the following check will fail due to
+PLATFORM_TRIPLET and MULTIARCH is not identical. PLATFORM_TRIPLET is set to
+"powerpc-linux-gnuspe", MULTIARCH is "powerpc-linux-gnuspev1" which is returned
+by $CC --print-multiarch. So set PLATFORM_TRIPLET to empty for powerpc-spe
+target to skip the check.
+
+if test x$PLATFORM_TRIPLET != x$MULTIARCH; then
+as_fn_error "..."
+
+Upstream-Status: Pending
+
+Signed-off-by: Zhenhua Luo 
+
+--- Python-3.5.1/configure.ac.orig 2016-03-11 06:02:38.955270329 -0600
 Python-3.5.1/configure.ac  2016-03-11 06:03:05.491269382 -0600
+@@ -801,7 +801,7 @@
+ # elif defined(__or1k__)
+ or1k-linux-gnu
+ # elif defined(__powerpc__) && defined(__SPE__)
+-powerpc-linux-gnuspe
++
+ # elif defined(__powerpc64__)
+ #  if defined(__LITTLE_ENDIAN__)
+ powerpc64le-linux-gnu
diff --git a/meta/recipes-devtools/python/python3_3.5.1.bb 
b/meta/recipes-devtools/python/python3_3.5.1.bb
index 11f959b..3eb938a 100644
--- a/meta/recipes-devtools/python/python3_3.5.1.bb
+++ b/meta/recipes-devtools/python/python3_3.5.1.bb
@@ -37,6 +37,7 @@ SRC_URI += "\
 file://setup.py-find-libraries-in-staging-dirs.patch \
 file://use_packed_importlib.patch \
 file://configure.ac-fix-LIBPL.patch \
+file://python3-fix-configure-issue-of-powerpc-spe.patch \
"
 SRC_URI[md5sum] = "e9ea6f2623fffcdd871b7b19113fde80"
 SRC_URI[sha256sum] = 
"c6d57c0c366d9060ab6c0cdf889ebf3d92711d466cc0119c441dbf2746f725c9"
-- 
2.4.3

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

[OE-core] [PATCH v2] image-buildinfo.bbclass: fix performance problems

[Patrick Ohly]

Inheriting image-buildinfo.bbclass primarily slowed down image
building for two reasons:
1. The content of the shell command "buildinfo" gets expanded
   multiple times, each time again checking the state of all
   layers.
2. When expanded as part of the actual image creation, git
   is invoked under pseudo, which makes the check quite a bit
   slower (from a few seconds to a minute with many layers).

To fix this, buildinfo now is a Python method which calls the checks
only when really executed. Pseudo is told to unload itself when
starting git.

In addition, "git diff" is invoked with "--quiet", which avoids
producing output that is just getting thrown away. As before, any kind
of problem or output causes the layer to be marked as "modified".

[Revision 2 of the change with some dead code removed]

Signed-off-by: Patrick Ohly 
---
 meta/classes/image-buildinfo.bbclass | 35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

diff --git a/meta/classes/image-buildinfo.bbclass 
b/meta/classes/image-buildinfo.bbclass
index 5b738ae..197b242 100644
--- a/meta/classes/image-buildinfo.bbclass
+++ b/meta/classes/image-buildinfo.bbclass
@@ -26,12 +26,17 @@ def image_buildinfo_outputvars(vars, listvars, d):
 
 # Gets git branch's status (clean or dirty)
 def get_layer_git_status(path):
-f = os.popen("cd %s; git diff --stat 2>&1 | tail -n 1" % path)
-data = f.read()
-if f.close() is None:
-if len(data) != 0:
-return "-- modified"
-return ""
+import subprocess
+try:
+subprocess.check_output("cd %s; PSEUDO_UNLOAD=1 git diff --quiet 
--no-ext-diff" % path,
+shell=True,
+stderr=subprocess.STDOUT)
+return ""
+except subprocess.CalledProcessError, ex:
+# Silently treat errors as "modified", without checking for the
+# (expected) return code 1 in a modified git repo. For example, we get
+# output and a 129 return code when a layer isn't a git repo at all.
+return "-- modified"
 
 # Returns layer revisions along with their respective status
 def get_layer_revs(d):
@@ -53,17 +58,21 @@ def buildinfo_target(d):
 return image_buildinfo_outputvars(vars, listvars, d)
 
 # Write build information to target filesystem
-buildinfo () {
-cat > ${IMAGE_ROOTFS}${sysconfdir}/build << END

+python buildinfo () {
+with open(d.expand('${IMAGE_ROOTFS}${sysconfdir}/build'), 'w') as build:
+build.writelines((
+'''---
 Build Configuration:  |
 ---
-${@buildinfo_target(d)}
+''',
+buildinfo_target(d),
+'''
 ---
-Layer Revisions:  |   
+Layer Revisions:  |
 ---
-${@get_layer_revs(d)}
-END
+''',
+get_layer_revs(d)
+   ))
 }
 
 IMAGE_PREPROCESS_COMMAND += "buildinfo;"
-- 
2.1.4

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

[OE-core] [PATCH] image-buildinfo.bbclass: fix performance problems

[Patrick Ohly]

Inheriting image-buildinfo.bbclass primarily slowed down image
building for two reasons:
1. The content of the shell command "buildinfo" gets expanded
   multiple times, each time again checking the state of all
   layers.
2. When expanded as part of the actual image creation, git
   is invoked under pseudo, which makes the check quite a bit
   slower (from a few seconds to a minute with many layers).

To fix this, buildinfo now is a Python method which calls the checks
only when really executed. Pseudo is told to unload itself when
starting git.

In addition, "git diff" is invoked with "--quiet", which avoids
producing output that is just getting thrown away. As before, any kind
of problem or output causes the layer to be marked as "modified".

Signed-off-by: Patrick Ohly 
---
 meta/classes/image-buildinfo.bbclass | 39 
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/meta/classes/image-buildinfo.bbclass 
b/meta/classes/image-buildinfo.bbclass
index 5b738ae..408b5b8 100644
--- a/meta/classes/image-buildinfo.bbclass
+++ b/meta/classes/image-buildinfo.bbclass
@@ -26,12 +26,21 @@ def image_buildinfo_outputvars(vars, listvars, d):
 
 # Gets git branch's status (clean or dirty)
 def get_layer_git_status(path):
-f = os.popen("cd %s; git diff --stat 2>&1 | tail -n 1" % path)
-data = f.read()
-if f.close() is None:
-if len(data) != 0:
-return "-- modified"
-return ""
+import subprocess
+import copy
+import os
+try:
+env = copy.deepcopy(os.environ)
+subprocess.check_output("cd %s; PSEUDO_UNLOAD=1 git diff --quiet 
--no-ext-diff" % path,
+shell=True,
+stderr=subprocess.STDOUT,
+env=env)
+return ""
+except subprocess.CalledProcessError, ex:
+# Silently treat errors as "modified", without checking for the
+# (expected) return code 1 in a modified git repo. For example, we get
+# output and a 129 return code when a layer isn't a git repo at all.
+return "-- modified"
 
 # Returns layer revisions along with their respective status
 def get_layer_revs(d):
@@ -53,17 +62,21 @@ def buildinfo_target(d):
 return image_buildinfo_outputvars(vars, listvars, d)
 
 # Write build information to target filesystem
-buildinfo () {
-cat > ${IMAGE_ROOTFS}${sysconfdir}/build << END

+python buildinfo () {
+with open(d.expand('${IMAGE_ROOTFS}${sysconfdir}/build'), 'w') as build:
+build.writelines((
+'''---
 Build Configuration:  |
 ---
-${@buildinfo_target(d)}
+''',
+buildinfo_target(d),
+'''
 ---
-Layer Revisions:  |   
+Layer Revisions:  |
 ---
-${@get_layer_revs(d)}
-END
+''',
+get_layer_revs(d)
+   ))
 }
 
 IMAGE_PREPROCESS_COMMAND += "buildinfo;"
-- 
2.1.4

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

Re: [OE-core] State of bitbake world, Failed tasks 2016-03-09

[Trevor Woerner]

On 03/10/16 06:53, Martin Jansa wrote:

I'll look at cef3 and chromium issue, my recent patch for meta-browser
fixed the build for armv7a MACHINEs, so it probably needs to be extended
a bit to cover warnings in x86 and then duplicate the same to cef3.
This issue is there for so long, slowing down the builds significantly
(and causing logs to be much bigger) - I don't use these recipes but I
hate the failures even more.


Working with the chromium recipe is painful! Each build takes _hours_, 
of just this one recipe alone, even on beefy build hardware. There are 
several PACKAGECONFIG options which affect the build (component build, 
lost context, side painting). There are multiple MACHINEs. You can 
perform a 'Release' or a 'Debug' build. Plus there are two rendering 
systems to support (x11 and wayland). Simply switching between x11 and 
wayland isn't just a matter of setting some build flags, you have to add 
another entire repository to your build from which you have to apply 
dozens of huge patches in order to add an Ozone layer underneath 
chromium so it can talk to wayland/weston.


The matrix of builds to perform and test explodes, not to mention the 
number of days it would take to build all these permutations.


I think one way to help contain this situation would be to split the 
chromium recipe into two: one for x11 and one for wayland. Another thing 
we should consider is wether or not all those permutations are really 
necessary. Is anyone actively using/needing Debug builds? Do we really 
need a component build?

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

Re: [OE-core] what is the precise search path for resolving "include" or "require" .inc files?

[Christopher Larson]

On Fri, Mar 11, 2016 at 5:08 AM Robert P. J. Day 
wrote:

>not sure why i never noticed this before, but what is the search order
> or precedence or priority for resolving recipe file directives "include"
> or "require"? i was just perusing the bitbake user manual, and noticed
> the explanation that those directives use BBPATH to track down the first
> include file by a given name.
>
>but AIUI, BBPATH is supposed to represent an ordered set of *layers*
> (i just examined BBPATH for a current [wind river linux] build, and that
> is exactly what it seems to contain). so when a recipe file like
> busybox.whatever.bb contains the line:
>
>require busybox.inc
>
> i always just assumed the search would look in the current busybox
> directory, but that directory is not technically a layer directory --
> it's not a directory specified on the alleged BBPATH search path.
>
>i never thought about this until i noticed some .bbappend files
> specifically using directives like:
>
>require recipes-bsp/u-boot/u-boot.inc
>
> where that file reference *does* refer to a file relative to some
> actual layer directory somewhere.
>
>what am i missing here?
>

BBPATH is temporarily prepended to include the directory the recipe lives
in, as a special case.

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

[OE-core] [PATCH] gcc: Fix the license on GNU OpenMP

[helio.castro]

From: Helio Chissini de Castro 

Poky jethro has libgomp ( GNU OpenMP ) license marked as GPL-3.0,
where's in fact the correct is GPL-3.0 with GCC Library Runtime Exception

As stated on https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h
header license:
 ...
   Under Section 7 of GPL version 3, you are granted additional
   permissions described in the GCC Runtime Library Exception, version
   3.1, as published by the Free Software Foundation.
 ...

Signed-off-by: Helio Chissini de Castro 
---
 meta/recipes-devtools/gcc/gcc-runtime.inc | 33 ---
 1 file changed, 4 insertions(+), 29 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index 690d780..98cc4b6 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -93,35 +93,10 @@ PACKAGES = "\
 libatomic-staticdev \
 "
 
-# Most libraries are licensed with the exception, but
-# one library is really GPLv3.
-#
-LICENSE_${PN}-dbg = "GPL-3.0-with-GCC-exception & GPLv3"
-LICENSE_libstdc++ = "GPL-3.0-with-GCC-exception"
-LICENSE_libstdc++-precompile-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libstdc++-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libstdc++-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libg2c = "GPL-3.0-with-GCC-exception"
-LICENSE_libg2c-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libssp = "GPL-3.0-with-GCC-exception"
-LICENSE_libssp-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libssp-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libgfortran = "GPL-3.0-with-GCC-exception"
-LICENSE_libgfortran-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libgfortran-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libmudflap = "GPL-3.0-with-GCC-exception"
-LICENSE_libmudflap-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libmudflap-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libquadmath = "GPL-3.0-with-GCC-exception"
-LICENSE_libquadmath-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libquadmath-staticdev = "GPL-3.0-with-GCC-exception"
-LICENSE_libatomic = "GPL-3.0-with-GCC-exception"
-LICENSE_libatomic-dev = "GPL-3.0-with-GCC-exception"
-LICENSE_libatomic-staticdev = "GPL-3.0-with-GCC-exception"
-
-LICENSE_libgomp = "GPLv3"
-LICENSE_libgomp-dev = "GPLv3"
-LICENSE_libgomp-staticdev = "GPLv3"
+LICENSE_${PN}-dbg = "GPL-3.0-with-GCC-exception"
+LICENSE_${PN} = "GPL-3.0-with-GCC-exception"
+LICENSE_${PN}-dev = "GPL-3.0-with-GCC-exception"
+LICENSE_${PN}-staticdev = "GPL-3.0-with-GCC-exception"
 
 # The base package doesn't exist, so we clear the recommends.
 RRECOMMENDS_${PN}-dbg = ""
-- 
2.5.0

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

[OE-core] [RFC PATCH 2/3] smartpm: remove rpm4 patch

[Joshua Lock]

The RPM4 support we added to SMART doesn't appear to work, remove
it as part of the removal of RPM4 from OE-Core.

Refresh the smart-add-for-rpm-ignoresize-check.patch which was
applied after smart-rpm4-fixes.patch and doesn't apply cleanly once
that patch is removed.

Signed-off-by: Joshua Lock 
---
 .../smart-add-for-rpm-ignoresize-check.patch   | 20 -
 .../python/python-smartpm/smart-rpm4-fixes.patch   | 49 --
 meta/recipes-devtools/python/python-smartpm_git.bb |  1 -
 3 files changed, 9 insertions(+), 61 deletions(-)
 delete mode 100644 
meta/recipes-devtools/python/python-smartpm/smart-rpm4-fixes.patch

diff --git 
a/meta/recipes-devtools/python/python-smartpm/smart-add-for-rpm-ignoresize-check.patch
 
b/meta/recipes-devtools/python/python-smartpm/smart-add-for-rpm-ignoresize-check.patch
index 8a27f25..fe98d07 100644
--- 
a/meta/recipes-devtools/python/python-smartpm/smart-add-for-rpm-ignoresize-check.patch
+++ 
b/meta/recipes-devtools/python/python-smartpm/smart-add-for-rpm-ignoresize-check.patch
@@ -17,14 +17,15 @@ Signed-off-by: Chong Lu 
  smart/backends/rpm/pm.py | 4 
  1 file changed, 4 insertions(+)
 
-diff --git a/smart/backends/rpm/pm.py b/smart/backends/rpm/pm.py
-index 5da9ee6..f0488ec 100644
 a/smart/backends/rpm/pm.py
-+++ b/smart/backends/rpm/pm.py
-@@ -241,6 +241,10 @@ class RPMPackageManager(PackageManager):
- except AttributeError:
- probfilter |= rpm.RPMPROB_FILTER_IGNOREARCH
- 
+Index: git/smart/backends/rpm/pm.py
+===
+--- git.orig/smart/backends/rpm/pm.py
 git/smart/backends/rpm/pm.py
+@@ -233,6 +233,11 @@ class RPMPackageManager(PackageManager):
+ if sysconf.get("rpm-order"):
+ ts.order()
+ probfilter = rpm.RPMPROB_FILTER_OLDPACKAGE
++
 +if sysconf.get("rpm-ignoresize", False):
 +probfilter |= rpm.RPMPROB_FILTER_DISKNODES
 +probfilter |= rpm.RPMPROB_FILTER_DISKSPACE
@@ -32,6 +33,3 @@ index 5da9ee6..f0488ec 100644
  if force or reinstall:
  probfilter |= rpm.RPMPROB_FILTER_REPLACEPKG
  probfilter |= rpm.RPMPROB_FILTER_REPLACEOLDFILES
--- 
-1.9.1
-
diff --git a/meta/recipes-devtools/python/python-smartpm/smart-rpm4-fixes.patch 
b/meta/recipes-devtools/python/python-smartpm/smart-rpm4-fixes.patch
deleted file mode 100644
index 708ffe6..000
--- a/meta/recipes-devtools/python/python-smartpm/smart-rpm4-fixes.patch
+++ /dev/null
@@ -1,49 +0,0 @@
-
-This patch checks for rpm5 related functions in order to allow rpm4 
-to work correctly. Currently the rpm4 archscore and filter work
-differently enough that they need to be changed.
-
-Upstream-Status: Inappropriate [OE-Core Specific]
-
-Signed-off-by: Saul Wold 
-
-Index: smart-1.4.1/smart/backends/rpm/base.py
-===
 smart-1.4.1.orig/smart/backends/rpm/base.py
-+++ smart-1.4.1/smart/backends/rpm/base.py
-@@ -338,10 +338,14 @@ class RPMObsoletes(Depends):
- 
- _SCOREMAP = {}
- def getArchScore(arch, _sm=_SCOREMAP):
--if arch not in _sm:
--score = rpm.archscore(arch)
--_sm[arch] = score
--return _sm.get(arch, 0)
-+try:
-+rpm.platformscore(arch)
-+if arch not in _sm:
-+score = rpm.archscore(arch)
-+_sm[arch] = score
-+return _sm.get(arch, 0)
-+except AttributeError:
-+return 1
- 
- # TODO: Embed color into nameprovides and obsoletes relations.
- _COLORMAP = {"noarch": 0, "x86_64": 2, "ppc64": 2, "s390x": 2, "sparc64": 2}
-Index: smart-1.4.1/smart/backends/rpm/pm.py
-===
 smart-1.4.1.orig/smart/backends/rpm/pm.py
-+++ smart-1.4.1/smart/backends/rpm/pm.py
-@@ -235,6 +235,12 @@ class RPMPackageManager(PackageManager):
- if sysconf.get("rpm-order"):
- ts.order()
- probfilter = rpm.RPMPROB_FILTER_OLDPACKAGE
-+try:
-+# Test for RPM5 function
-+rpm.platformscore("")
-+except AttributeError:
-+probfilter |= rpm.RPMPROB_FILTER_IGNOREARCH
-+
- if force or reinstall:
- probfilter |= rpm.RPMPROB_FILTER_REPLACEPKG
- probfilter |= rpm.RPMPROB_FILTER_REPLACEOLDFILES
diff --git a/meta/recipes-devtools/python/python-smartpm_git.bb 
b/meta/recipes-devtools/python/python-smartpm_git.bb
index 139bfd5..d9a908d 100644
--- a/meta/recipes-devtools/python/python-smartpm_git.bb
+++ b/meta/recipes-devtools/python/python-smartpm_git.bb
@@ -19,7 +19,6 @@ SRC_URI = "\
   file://smart-channelsdir.patch \
   file://smart-attempt.patch \
   file://smart-attempt-fix.patch \
-  file://smart-rpm4-fixes.patch \
   file://smart-add-for-rpm-ignoresize-check.patch \
   file://smart-already-installed-message.patch \
 

[OE-core] [RFC PATCH 3/3] lib/package_manager: remove RPM4 support code

[Joshua Lock]

Simplify the RPM code by removing support for RPM 4 now that we've
dropped the RPM 4 recipe.

Signed-off-by: Joshua Lock 
---
 meta/lib/oe/package_manager.py | 94 +-
 1 file changed, 38 insertions(+), 56 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index b701b8c..239ae4e 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -345,7 +345,6 @@ class RpmPkgsList(PkgsList):
 except subprocess.CalledProcessError as e:
 bb.fatal("Getting rpm version failed. Command '%s' "
  "returned %d:\n%s" % (cmd, e.returncode, e.output))
-self.rpm_version = int(output.split()[-1].split('.')[0])
 
 '''
 Translate the RPM/Smart format names to the OE multilib format names
@@ -396,10 +395,7 @@ class RpmPkgsList(PkgsList):
 def list_pkgs(self):
 cmd = self.rpm_cmd + ' --root ' + self.rootfs_dir
 cmd += ' -D "_dbpath /var/lib/rpm" -qa'
-if self.rpm_version == 4:
-cmd += " --qf '[%{NAME} %{ARCH} %{VERSION}\n]'"
-else:
-cmd += " --qf '[%{NAME} %{ARCH} %{VERSION} %{PACKAGEORIGIN}\n]'"
+cmd += " --qf '[%{NAME} %{ARCH} %{VERSION} %{PACKAGEORIGIN}\n]'"
 
 try:
 # bb.note(cmd)
@@ -410,11 +406,7 @@ class RpmPkgsList(PkgsList):
 
 output = dict()
 deps = dict()
-if self.rpm_version == 4:
-bb.warn("Dependency listings are not supported with rpm 4 since 
rpmresolve does not work")
-dependencies = ""
-else:
-dependencies = self._list_pkg_deps()
+dependencies = self._list_pkg_deps()
 
 # Populate deps dictionary for better manipulation
 for line in dependencies.splitlines():
@@ -439,10 +431,8 @@ class RpmPkgsList(PkgsList):
 # Skip GPG keys
 if pkg == 'gpg-pubkey':
 continue
-if self.rpm_version == 4:
-pkgorigin = "unknown"
-else:
-pkgorigin = line.split()[3]
+
+pkgorigin = line.split()[3]
 new_pkg, new_arch = self._pkg_translate_smart_to_oe(pkg, arch)
 
 output[new_pkg] = {"arch":new_arch, "ver":ver,
@@ -675,7 +665,6 @@ class RpmPM(PackageManager):
 
 self.indexer = RpmIndexer(self.d, self.deploy_dir)
 self.pkgs_list = RpmPkgsList(self.d, self.target_rootfs, arch_var, 
os_var)
-self.rpm_version = self.pkgs_list.rpm_version
 
 self.ml_prefix_list, self.ml_os_list = 
self.indexer.get_ml_prefix_and_os_list(arch_var, os_var)
 
@@ -897,44 +886,41 @@ class RpmPM(PackageManager):
 # After change the __db.* cache size, log file will not be
 # generated automatically, that will raise some warnings,
 # so touch a bare log for rpm write into it.
-if self.rpm_version == 5:
-rpmlib_log = os.path.join(self.image_rpmlib, 'log', 
'log.01')
-if not os.path.exists(rpmlib_log):
-bb.utils.mkdirhier(os.path.join(self.image_rpmlib, 'log'))
-open(rpmlib_log, 'w+').close()
-
-DB_CONFIG_CONTENT = "#  Environment\n" \
-"set_data_dir .\n" \
-"set_create_dir .\n" \
-"set_lg_dir ./log\n" \
-"set_tmp_dir ./tmp\n" \
-"set_flags db_log_autoremove on\n" \
-"\n" \
-"# -- thread_count must be >= 8\n" \
-"set_thread_count 64\n" \
-"\n" \
-"#  Logging\n" \
-"\n" \
-"#  Memory Pool\n" \
-"set_cachesize 0 1048576 0\n" \
-"set_mp_mmapsize 268435456\n" \
-"\n" \
-"#  Locking\n" \
-"set_lk_max_locks 16384\n" \
-"set_lk_max_lockers 16384\n" \
-"set_lk_max_objects 16384\n" \
-"mutex_set_max 163840\n" \
-"\n" \
-"#  Replication\n"
-
-db_config_dir = os.path.join(self.image_rpmlib, 'DB_CONFIG')
-if not os.path.exists(db_config_dir):
-open(db_config_dir, 'w+').write(DB_CONFIG_CONTENT)
+rpmlib_log = os.path.join(self.image_rpmlib, 'log', 'log.01')
+if not os.path.exists(rpmlib_log):
+bb.utils.mkdirhier(os.path.join(self.image_rpmlib, 'log'))
+open(rpmlib_log, 'w+').close()
+
+DB_CONFIG_CONTENT = "#  Environment\n" \
+"set_data_dir .\n" \
+"set_create_dir .\n" \
+"set_lg_dir ./log\n" \
+"set_tmp_dir ./tmp\n" \
+"set_flags db_log_autoremove on\n" \
+"\n" \
+"# -- thread_count must be >= 8\n" \
+"set_thread_count 64\n" \
+  

[OE-core] [RFC PATCH 0/3] Remove RPM 4

[Joshua Lock]

This series removes RPM 4 and code to support it from OE Core. There are
several known issues with using RPM 4 and it seems better to acknowledge it's
unsupported by removing it from OE-Core than to leave  it in a non-functional
state.

Please review the following changes for suitability for inclusion. If you have
any objections or suggestions for improvement, please respond to the patches. If
you agree with the changes, please provide your Acked-by.

Regards,

Joshua

The following changes since commit 00d3fd571a8d261d065b43f5cf3076a381843984:

  siteinfo: Add ppc64le support. (2016-03-10 23:06:46 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib joshuagl/rmrpm
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/rmrpm

Joshua Lock (3):
  rpm: remove RPM 4
  smartpm: remove rpm4 patch
  lib/package_manager: remove RPM4 support code

 meta/lib/oe/package_manager.py |  94 ++---
 .../smart-add-for-rpm-ignoresize-check.patch   |  20 +-
 .../python/python-smartpm/smart-rpm4-fixes.patch   |  49 ---
 meta/recipes-devtools/python/python-smartpm_git.bb |   1 -
 .../add_RPMSENSE_MISSINGOK_to_rpmmodule.patch  |  20 --
 .../rpm/rpm-4.11.2/disable_shortcircuited.patch|  23 --
 .../rpm/rpm-4.11.2/fix_libdir.patch|  19 -
 meta/recipes-devtools/rpm/rpm-4.11.2/pythondeps.sh |  16 -
 .../rpm/rpm-4.11.2/remove-db3-from-configure.patch |  26 --
 .../rpm/rpm-4.11.2/remove-dir-check.patch  |  23 --
 .../rpm/rpm-4.11.2/rpm-scriptetexechelp.patch  | 194 ---
 .../rpm/rpm-4.11.2/support-suggests-tag.patch  | 384 -
 .../rpm/rpm-4.11.2/use-pkgconfig-for-python.patch  |  38 --
 meta/recipes-devtools/rpm/rpm_4.11.2.bb| 132 ---
 14 files changed, 47 insertions(+), 992 deletions(-)
 delete mode 100644 
meta/recipes-devtools/python/python-smartpm/smart-rpm4-fixes.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/add_RPMSENSE_MISSINGOK_to_rpmmodule.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/disable_shortcircuited.patch
 delete mode 100644 meta/recipes-devtools/rpm/rpm-4.11.2/fix_libdir.patch
 delete mode 100755 meta/recipes-devtools/rpm/rpm-4.11.2/pythondeps.sh
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/remove-db3-from-configure.patch
 delete mode 100644 meta/recipes-devtools/rpm/rpm-4.11.2/remove-dir-check.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/rpm-scriptetexechelp.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/support-suggests-tag.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/use-pkgconfig-for-python.patch
 delete mode 100644 meta/recipes-devtools/rpm/rpm_4.11.2.bb

-- 
2.5.0

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

[OE-core] [RFC PATCH 1/3] rpm: remove RPM 4

[Joshua Lock]

RPM4 support is buggy and incomplete. As we don't have the
resources or interest to maintain it this patch removes it.

Signed-off-by: Joshua Lock 
---
 .../add_RPMSENSE_MISSINGOK_to_rpmmodule.patch  |  20 --
 .../rpm/rpm-4.11.2/disable_shortcircuited.patch|  23 --
 .../rpm/rpm-4.11.2/fix_libdir.patch|  19 -
 meta/recipes-devtools/rpm/rpm-4.11.2/pythondeps.sh |  16 -
 .../rpm/rpm-4.11.2/remove-db3-from-configure.patch |  26 --
 .../rpm/rpm-4.11.2/remove-dir-check.patch  |  23 --
 .../rpm/rpm-4.11.2/rpm-scriptetexechelp.patch  | 194 ---
 .../rpm/rpm-4.11.2/support-suggests-tag.patch  | 384 -
 .../rpm/rpm-4.11.2/use-pkgconfig-for-python.patch  |  38 --
 meta/recipes-devtools/rpm/rpm_4.11.2.bb| 132 ---
 10 files changed, 875 deletions(-)
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/add_RPMSENSE_MISSINGOK_to_rpmmodule.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/disable_shortcircuited.patch
 delete mode 100644 meta/recipes-devtools/rpm/rpm-4.11.2/fix_libdir.patch
 delete mode 100755 meta/recipes-devtools/rpm/rpm-4.11.2/pythondeps.sh
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/remove-db3-from-configure.patch
 delete mode 100644 meta/recipes-devtools/rpm/rpm-4.11.2/remove-dir-check.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/rpm-scriptetexechelp.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/support-suggests-tag.patch
 delete mode 100644 
meta/recipes-devtools/rpm/rpm-4.11.2/use-pkgconfig-for-python.patch
 delete mode 100644 meta/recipes-devtools/rpm/rpm_4.11.2.bb

diff --git 
a/meta/recipes-devtools/rpm/rpm-4.11.2/add_RPMSENSE_MISSINGOK_to_rpmmodule.patch
 
b/meta/recipes-devtools/rpm/rpm-4.11.2/add_RPMSENSE_MISSINGOK_to_rpmmodule.patch
deleted file mode 100644
index b877870..000
--- 
a/meta/recipes-devtools/rpm/rpm-4.11.2/add_RPMSENSE_MISSINGOK_to_rpmmodule.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Upstream-Status: Inappropriate [OE-Specific]
-
-Signed-off-by: Saul Wold 
-Signed-off-by: Ronan Le Martret  
-
-diff --git a/python/rpmmodule.c b/python/rpmmodule.c
-index a4fe217..728c66c 100644
 a/python/rpmmodule.c
-+++ b/python/rpmmodule.c
-@@ -396,6 +396,10 @@ static int initModule(PyObject *m)
- REGISTER_ENUM(RPMSENSE_STRONG);
- REGISTER_ENUM(RPMSENSE_CONFIG);
- 
-+#if defined(RPM_VENDOR_OE)
-+REGISTER_ENUM(RPMSENSE_MISSINGOK);
-+#endif
-+
- REGISTER_ENUM(RPMTRANS_FLAG_TEST);
- REGISTER_ENUM(RPMTRANS_FLAG_BUILD_PROBS);
- REGISTER_ENUM(RPMTRANS_FLAG_NOSCRIPTS);
diff --git a/meta/recipes-devtools/rpm/rpm-4.11.2/disable_shortcircuited.patch 
b/meta/recipes-devtools/rpm/rpm-4.11.2/disable_shortcircuited.patch
deleted file mode 100644
index 7a646de..000
--- a/meta/recipes-devtools/rpm/rpm-4.11.2/disable_shortcircuited.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-Upstream-Status: Pending
-
-Signed-off-by: Saul Wold 
-Signed-off-by: Ronan Le Martret 
-
-
-Index: rpm-4.11.2/build/pack.c
-===
 rpm-4.11.2.orig/build/pack.c
-+++ rpm-4.11.2/build/pack.c
-@@ -571,9 +571,9 @@ rpmRC packageBinaries(rpmSpec spec, cons
-   headerPutBin(pkg->header, RPMTAG_SOURCEPKGID, spec->sourcePkgId,16);
-   }
- 
--  if (cheating) {
--  (void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
--  }
-+//if (cheating) {
-+//(void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
-+//}
-   
-   {   char *binFormat = rpmGetPath("%{_rpmfilename}", NULL);
-   char *binRpm, *binDir;
diff --git a/meta/recipes-devtools/rpm/rpm-4.11.2/fix_libdir.patch 
b/meta/recipes-devtools/rpm/rpm-4.11.2/fix_libdir.patch
deleted file mode 100644
index be0626c..000
--- a/meta/recipes-devtools/rpm/rpm-4.11.2/fix_libdir.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-Upstream-Status: Inappropriate [OE-Core specific]
-
-Signed-off-by: Saul Wold 
-Signed-off-by: Ronan Le Martret 
-
-
-diff --git a/installplatform b/installplatform
-index 8c3eba0..fa15e91 100755
 a/installplatform
-+++ b/installplatform
-@@ -112,7 +112,7 @@ for ARCH in noarch `grep ^arch_canon $RPMRC | cut -d: 
-f2`; do
-   [ -z "$CANONARCH" ] && continue
- 
-   if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
--  LIB=${LIB}64
-+  LIB=${LIB}
-   fi
- 
-   PPD="${DESTDIR}/${platformdir}/${ARCH}-${OS}"
diff --git a/meta/recipes-devtools/rpm/rpm-4.11.2/pythondeps.sh 
b/meta/recipes-devtools/rpm/rpm-4.11.2/pythondeps.sh
deleted file mode 100755
index 083b174..000
--- a/meta/recipes-devtools/rpm/rpm-4.11.2/pythondeps.sh
+++ /dev/null
@@ -1,16 +0,0 @@
-#!/bin/sh
-
-[ $# -ge 1 ] || {
-cat > /dev/null
-exit 0
-}
-
-case $1 in
--R|--requires)
-shift
-grep 

Re: [OE-core] [dizzy][PATCH 3/4] glibc: CVE-2015-9761

[Martin Jansa]

On Thu, Mar 03, 2016 at 09:47:11PM +0100, Martin Jansa wrote:
> I was asking you about the CVE number (but I realize it was already merged
> in other branches with wrong number so maybe it will be less confusing use
> the same in Dizzy)
> 
> And "please merge" was informal
> Acked-by: Martin Jansa 
> 
> after testing this series in our Dizzy based builds.

Any ETA on getting these in dizzy branch?

I know that everybody is busy with Mx release, I just need the ETA to
decide if
1) we'll upgrade oe-core now with only the first security fix
   and upgrade again later when these are merged
2) we'll upgrade oe-core now with only the first security fix
   and backport other 4 fixes in our internal layer - and remove these
   backports in next oe-core upgrade when these are merged
3) we'll wait a bit more to get all 5 fixes in one oe-core upgrade

I've already tested all 5 in our builds, only issue I've noticed
is incorrect CVE number used in patches as reported.
 
> On Thu, Mar 3, 2016 at 9:35 PM, akuster@mvista  wrote:
> 
> > On 3/3/16 12:16 AM, Martin Jansa wrote:
> > > On Sun, Feb 28, 2016 at 10:53:34AM -0800, Armin Kuster wrote:
> > >> From: Armin Kuster 
> > >
> > > I think this is 2014-9761 not 2015-9761
> > >
> > > But other than that please merge this series.
> >
> > Are you asking me? I don't have write perms.
> >
> > - armin
> > >
> > >> A stack overflow vulnerability was found in nan* functions that could
> > cause
> > >> applications which process long strings with the nan function to crash
> > or,
> > >> potentially, execute arbitrary code.
> > >>
> > >> (From OE-Core rev: fd3da8178c8c06b549dbc19ecec40e98ab934d49)
> > >>
> > >> Signed-off-by: Armin Kuster 
> > >> Signed-off-by: Robert Yang 
> > >> Signed-off-by: Richard Purdie 
> > >> Signed-off-by: Armin Kuster 
> > >> Signed-off-by: Richard Purdie 
> > >> Signed-off-by: Armin Kuster 
> > >> ---
> > >>  .../recipes-core/glibc/glibc/CVE-2015-9761_1.patch | 1039
> > 
> > >>  .../recipes-core/glibc/glibc/CVE-2015-9761_2.patch |  388 
> > >>  meta/recipes-core/glibc/glibc_2.20.bb  |2 +
> > >>  3 files changed, 1429 insertions(+)
> > >>  create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-9761_1.patch
> > >>  create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-9761_2.patch
> > >>
> > >> diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-9761_1.patch
> > b/meta/recipes-core/glibc/glibc/CVE-2015-9761_1.patch
> > >> new file mode 100644
> > >> index 000..3aca913
> > >> --- /dev/null
> > >> +++ b/meta/recipes-core/glibc/glibc/CVE-2015-9761_1.patch
> > >> @@ -0,0 +1,1039 @@
> > >> +From e02cabecf0d025ec4f4ddee290bdf7aadb873bb3 Mon Sep 17 00:00:00 2001
> > >> +From: Joseph Myers 
> > >> +Date: Tue, 24 Nov 2015 22:24:52 +
> > >> +Subject: [PATCH] Refactor strtod parsing of NaN payloads.
> > >> +
> > >> +The nan* functions handle their string argument by constructing a
> > >> +NAN(...) string on the stack as a VLA and passing it to strtod
> > >> +functions.
> > >> +
> > >> +This approach has problems discussed in bug 16961 and bug 16962: the
> > >> +stack usage is unbounded, and it gives incorrect results in certain
> > >> +cases where the argument is not a valid n-char-sequence.
> > >> +
> > >> +The natural fix for both issues is to refactor the NaN payload parsing
> > >> +out of strtod into a separate function that the nan* functions can
> > >> +call directly, so that no temporary string needs constructing on the
> > >> +stack at all.  This patch does that refactoring in preparation for
> > >> +fixing those bugs (but without actually using the new functions from
> > >> +nan* - which will also require exporting them from libc at version
> > >> +GLIBC_PRIVATE).  This patch is not intended to change any user-visible
> > >> +behavior, so no tests are added (fixes for the above bugs will of
> > >> +course add tests for them).
> > >> +
> > >> +This patch builds on my recent fixes for strtol and strtod issues in
> > >> +Turkish locales.  Given those fixes, the parsing of NaN payloads is
> > >> +locale-independent; thus, the new functions do not need to take a
> > >> +locale_t argument.
> > >> +
> > >> +Tested for x86_64, x86, mips64 and powerpc.
> > >> +
> > >> +* stdlib/strtod_nan.c: New file.
> > >> +* stdlib/strtod_nan_double.h: Likewise.
> > >> +* stdlib/strtod_nan_float.h: Likewise.
> > >> +* stdlib/strtod_nan_main.c: Likewise.
> > >> +* stdlib/strtod_nan_narrow.h: Likewise.
> > >> +* stdlib/strtod_nan_wide.h: Likewise.
> > >> +* stdlib/strtof_nan.c: Likewise.
> > >> +* stdlib/strtold_nan.c: Likewise.
> > >> +* sysdeps/ieee754/ldbl-128/strtod_nan_ldouble.h: Likewise.
> > >> +* 

Re: [OE-core] [RFC PATCH 00/12] Sato desktop upgrade (Gtk3 etc.)

[Jussi Kukkonen]

On 11 March 2016 at 15:12, Jussi Kukkonen  wrote:

>   matchbox-theme-sato: Upgrade to JKU
>

As I was already asked about it: the commit message title is just a keyword
for me so I remember to modify them to whatever the upstream versions end
up as in the final patchset.

Jussi


>   matchbox-desktop: Ugrade to JKU
>   matchbox-panel-2: Upgrade to JKU
>   matchbox-session-sato: Update session startup
>   sato-screenshot: Upgrade to JKU
>   settings-daemon: Upgrade to JKU
>   gtk-sato-engine: Remove as unused
>   matchbox-wm: Upgrade to JKU
>   connman-gnome: Upgrade to JKU
>   matchbox-panel-2: Depend on dbus-glib-native for binding-tool
>
>  .../connman-gnome-fix-dbus-interface-name.patch| 187
> -
>  .../connman-gnome/images/connman-signal-01.png | Bin 490 -> 0 bytes
>  .../connman-gnome/images/connman-signal-02.png | Bin 496 -> 0 bytes
>  .../connman-gnome/images/connman-signal-03.png | Bin 492 -> 0 bytes
>  .../connman-gnome/images/connman-signal-04.png | Bin 470 -> 0 bytes
>  .../connman-gnome/images/connman-signal-05.png | Bin 419 -> 0 bytes
>  .../connman/connman-gnome_0.7.bb   |  12 +-
>  .../gnome/gnome-themes-standard_3.18.0.bb  |  37 
>  .../matchbox-wm/matchbox-wm_git.bb |   4 +-
>  meta/recipes-sato/gtk-engines/gtk-sato-engine.inc  |  25 ---
>  .../gtk-engines/gtk-sato-engine_git.bb |  14 --
>  .../matchbox-desktop/matchbox-desktop_git.bb   |   7 +-
>  .../matchbox-panel-2/files/silence-warnings.patch  |  64 ---
>  .../matchbox-panel-2/matchbox-panel-2_git.bb   |  12 +-
>  .../matchbox-sato/matchbox-session-sato/session|   9 +-
>  .../matchbox-sato/matchbox-session-sato_0.1.bb |   4 +-
>  .../matchbox-theme-sato/matchbox-theme-sato_0.1.bb |   8 -
>  .../matchbox-theme-sato/matchbox-theme-sato_git.bb |   8 +-
>  .../packagegroups/packagegroup-core-x11-sato.bb|   6 +-
>  .../sato-screenshot/sato-screenshot_git.bb |   6 +-
>  .../files/dso_linking_change_build_fix.patch   |  31 
>  .../settings-daemon/settings-daemon_git.bb |   8 +-
>  22 files changed, 65 insertions(+), 377 deletions(-)
>  delete mode 100644
> meta/recipes-connectivity/connman/connman-gnome/connman-gnome-fix-dbus-interface-name.patch
>  delete mode 100644
> meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
>  delete mode 100644
> meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
>  delete mode 100644
> meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
>  delete mode 100644
> meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
>  delete mode 100644
> meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-05.png
>  create mode 100644 meta/recipes-gnome/gnome/
> gnome-themes-standard_3.18.0.bb
>  delete mode 100644 meta/recipes-sato/gtk-engines/gtk-sato-engine.inc
>  delete mode 100644 meta/recipes-sato/gtk-engines/gtk-sato-engine_git.bb
>  delete mode 100644
> meta/recipes-sato/matchbox-panel-2/files/silence-warnings.patch
>  delete mode 100644 meta/recipes-sato/matchbox-theme-sato/
> matchbox-theme-sato_0.1.bb
>  delete mode 100644
> meta/recipes-sato/settings-daemon/files/dso_linking_change_build_fix.patch
>
> --
> 2.1.4
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC PATCH 11/12] connman-gnome: Upgrade to JKU

[Jussi Kukkonen]

This is the GTK3 version.

Drop patches and images that are now included upstream.

Signed-off-by: Jussi Kukkonen 
---
 .../connman-gnome-fix-dbus-interface-name.patch| 187 -
 .../connman-gnome/images/connman-signal-01.png | Bin 490 -> 0 bytes
 .../connman-gnome/images/connman-signal-02.png | Bin 496 -> 0 bytes
 .../connman-gnome/images/connman-signal-03.png | Bin 492 -> 0 bytes
 .../connman-gnome/images/connman-signal-04.png | Bin 470 -> 0 bytes
 .../connman-gnome/images/connman-signal-05.png | Bin 419 -> 0 bytes
 .../connman/connman-gnome_0.7.bb   |  12 +-
 7 files changed, 3 insertions(+), 196 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/connman-gnome-fix-dbus-interface-name.patch
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-05.png

diff --git 
a/meta/recipes-connectivity/connman/connman-gnome/connman-gnome-fix-dbus-interface-name.patch
 
b/meta/recipes-connectivity/connman/connman-gnome/connman-gnome-fix-dbus-interface-name.patch
deleted file mode 100644
index f4049fa..000
--- 
a/meta/recipes-connectivity/connman/connman-gnome/connman-gnome-fix-dbus-interface-name.patch
+++ /dev/null
@@ -1,187 +0,0 @@
-connman-gnome: fix dbus interface name
-
-This patch resolves following error:
-
-"connman-dbus.xml": "connman" is not a valid D-Bus interface name
-
-https://502552.bugs.gentoo.org/attachment.cgi?id=380652
-
-Upstream-Status: Backport
-
-Signed-off-by: Chong Lu 

- common/connman-client.c | 24 
- common/connman-client.h |  4 ++--
- common/connman-dbus.c   |  6 +++---
- common/connman-dbus.xml |  2 +-
- 4 files changed, 18 insertions(+), 18 deletions(-)
-
-diff --git a/common/connman-client.c b/common/connman-client.c
-index c55e25c..9d818b2 100644
 a/common/connman-client.c
-+++ b/common/connman-client.c
-@@ -289,7 +289,7 @@ gboolean connman_client_set_ipv4(ConnmanClient *client, 
const gchar *device,
- 
-   g_value_init(, DBUS_TYPE_G_DICTIONARY);
-   g_value_set_boxed(, ipv4);
--  ret = connman_set_property(proxy, "IPv4.Configuration", , NULL);
-+  ret = net_connman_set_property(proxy, "IPv4.Configuration", , 
NULL);
- 
-   g_object_unref(proxy);
- 
-@@ -317,7 +317,7 @@ void connman_client_set_powered(ConnmanClient *client, 
const gchar *device,
-   g_value_set_boolean(, powered);
- 
-   error = NULL;
--  connman_set_property(proxy, "Powered", , );
-+  net_connman_set_property(proxy, "Powered", , );
-   if( error )
-   fprintf (stderr, "error: %s\n", error->message);
- 
-@@ -325,7 +325,7 @@ void connman_client_set_powered(ConnmanClient *client, 
const gchar *device,
- }
- 
- void connman_client_scan(ConnmanClient *client, const gchar *device,
--  connman_scan_reply callback, 
gpointer user_data)
-+  net_connman_scan_reply 
callback, gpointer user_data)
- {
-   ConnmanClientPrivate *priv = CONNMAN_CLIENT_GET_PRIVATE(client);
-   DBusGProxy *proxy;
-@@ -339,7 +339,7 @@ void connman_client_scan(ConnmanClient *client, const 
gchar *device,
-   if (proxy == NULL)
-   return;
- 
--  connman_scan_async(proxy, callback, user_data);
-+  net_connman_scan_async(proxy, callback, user_data);
- 
-   g_object_unref(proxy);
- }
-@@ -353,7 +353,7 @@ gboolean connman_client_get_offline_status(ConnmanClient 
*client)
- 
-   DBG("client %p", client);
- 
--  ret = connman_get_properties(priv->manager, , NULL);
-+  ret = net_connman_get_properties(priv->manager, , NULL);
- 
-   if (ret == FALSE)
-   goto done;
-@@ -375,7 +375,7 @@ void connman_client_set_offlinemode(ConnmanClient *client, 
gboolean status)
-   g_value_init(, G_TYPE_BOOLEAN);
-   g_value_set_boolean(, status);
- 
--  connman_set_property(priv->manager, "OfflineMode", , NULL);
-+  net_connman_set_property(priv->manager, "OfflineMode", , NULL);
- }
- 
- static gboolean network_disconnect(GtkTreeModel *model, GtkTreePath *path,
-@@ -398,7 +398,7 @@ static gboolean network_disconnect(GtkTreeModel *model, 
GtkTreePath *path,
-   return TRUE;
- 
-   if (type == CONNMAN_TYPE_WIFI)
--  connman_disconnect(proxy, NULL);
-+  net_connman_disconnect(proxy, NULL);
- 
-   g_object_unref(proxy);
- 
-@@ -422,13 +422,13 @@ void connman_client_connect(ConnmanClient *client, const 
gchar *network)
-   if 

[OE-core] [RFC PATCH 12/12] matchbox-panel-2: Depend on dbus-glib-native for binding-tool

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb 
b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
index 5bd629f..5c9de46 100644
--- a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
+++ b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
file://matchbox-panel/mb-panel.h;endline=10;md5=0b7db28f4b6863fb853d0467e590019a
 \
 
file://applets/startup/startup.c;endline=22;md5=7cbcea60b667f609495222faf3e07917"
 
-DEPENDS = "gnome-common gtk+3 startup-notification dbus dbus-glib"
+DEPENDS = "gnome-common gtk+3 startup-notification dbus dbus-glib 
dbus-glib-native"
 DEPENDS += " ${@bb.utils.contains("MACHINE_FEATURES", "acpi", "libacpi", 
"",d)}"
 DEPENDS += " ${@bb.utils.contains("MACHINE_FEATURES", "apm", "apmd", "",d)}"
 
-- 
2.1.4

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

[OE-core] [RFC PATCH 03/12] matchbox-theme-sato: Upgrade to JKU

[Jussi Kukkonen]

Modify the WM theme to more resemble Adwaita (titlebar is thinner,
colors are mostly uniform gray instead of green ).

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_0.1.bb | 8 
 meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_git.bb | 8 ++--
 2 files changed, 2 insertions(+), 14 deletions(-)
 delete mode 100644 
meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_0.1.bb

diff --git a/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_0.1.bb 
b/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_0.1.bb
deleted file mode 100644
index f6786dd..000
--- a/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_0.1.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require matchbox-theme-sato.inc
-
-PR = "r1"
-
-SRC_URI = "http://pokylinux.org/releases/sato/matchbox-theme-sato-0.1.tar.gz;
-
-SRC_URI[md5sum] = "72ae272ef7803141a3dcb69e670cff97"
-SRC_URI[sha256sum] = 
"5b59f9646edbfb907a309332db3bd6fa7080dc1fe24df549480cfae7d974a3fb"
diff --git a/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_git.bb 
b/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_git.bb
index 0d3569d..d251f0c 100644
--- a/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_git.bb
+++ b/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_git.bb
@@ -1,12 +1,8 @@
 require matchbox-theme-sato.inc
 
-SRCREV = "f72cf4ed7d71ad9e47b0f2d3dbc593bc2f3e76f8"
+SRCREV = "0405ea2e5f5ea3fab12434886c97c592a7e1ce43"
 PV = "0.2+git${SRCPV}"
 
-DEFAULT_PREFERENCE = "-1"
-
-SRC_URI = "git://git.yoctoproject.org/matchbox-sato"
-
-EXTRA_OECONF += "${@bb.utils.contains('MACHINE_FEATURES', 'qvga', 
'--with-mode=qvga', '',d)}"
+SRC_URI = "git://github.com/jku/matchbox-sato;branch=gtk3"
 
 S = "${WORKDIR}/git"
-- 
2.1.4

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

[OE-core] [RFC PATCH 06/12] matchbox-session-sato: Update session startup

[Jussi Kukkonen]

* Use Adwaita Gtk+ theme
* sato-gtk-engine is no longer needed with Adwaita
* GTK_CSD tricks are no longer needed since the panel
  does not draw on top windows

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-sato/matchbox-sato/matchbox-session-sato/session | 9 ++---
 meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb  | 4 ++--
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-sato/matchbox-sato/matchbox-session-sato/session 
b/meta/recipes-sato/matchbox-sato/matchbox-session-sato/session
index 42ce483..f6313bd 100644
--- a/meta/recipes-sato/matchbox-sato/matchbox-session-sato/session
+++ b/meta/recipes-sato/matchbox-sato/matchbox-session-sato/session
@@ -14,11 +14,6 @@ else
 KEYBOARD_APPLET="keyboard"
 fi
 
-# Tell GTK+3 we really want server side decorations, even with
-# GtkHeaderBar using applications: Without that mb-panel will render
-# on top of the client side decorations.
-export GTK_CSD=0
-
 matchbox-desktop &
 
 # Lines containing feature-[foo] are removed at build time if the machine
@@ -28,6 +23,6 @@ START_APPLETS=showdesktop,windowselector
 END_APPLETS=clock,battery,$KEYBOARD_APPLET,systray,startup-notify,notify
 END_APPLETS=openmoko-panel-gsm,$END_APPLETS # feature-phone
 
-matchbox-panel --titlebar --start-applets $START_APPLETS --end-applets 
$END_APPLETS &
+matchbox-panel --start-applets $START_APPLETS --end-applets $END_APPLETS &
 
-exec matchbox-window-manager -theme Sato -use_desktop_mode decorated 
-use_cursor $SHOWCURSOR $@
+exec matchbox-window-manager -theme Sato -use_cursor $SHOWCURSOR $@
diff --git a/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb 
b/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
index 76de18a..d5bdd19 100644
--- a/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
+++ b/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://session;endline=3;md5=f8a5c5b9c279e52dc094d10e11c2be6
 
 SECTION = "x11"
 DEPENDS = "gconf-native"
-RDEPENDS_${PN} = "formfactor gtk-sato-engine matchbox-theme-sato 
gtk-theme-sato matchbox-panel-2 matchbox-desktop-sato matchbox-session gconf"
+RDEPENDS_${PN} = "formfactor matchbox-theme-sato matchbox-panel-2 
matchbox-desktop-sato matchbox-session gconf"
 PR = "r30"
 
 # This package is architecture specific because the session script is modified
@@ -44,7 +44,7 @@ pkg_postinst_${PN} () {
#type, name, value
gconftool-2 
--config-source=xml::$D${sysconfdir}/gconf/gconf.xml.defaults --direct --type 
$1 --set /desktop/poky/interface/$2 "$3"
}
-   set_value string theme Sato
+   set_value string theme Adwaita
set_value string icon_theme Sato
set_value bool touchscreen true
set_value string font_name "Sans 9"
-- 
2.1.4

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

[OE-core] [RFC PATCH 02/12] packagegroup-core-x11-sato: Update for GTK3 changes

[Jussi Kukkonen]

The keyboard/IM is not yet ported, not including it in packagegroup.

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb 
b/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb
index 8ba4923..3dfe55c 100644
--- a/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb
+++ b/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb
@@ -26,14 +26,10 @@ SUMMARY_${PN}-base = "Sato desktop - base packages"
 RDEPENDS_${PN}-base = "\
 matchbox-desktop \
 matchbox-session-sato \
-matchbox-keyboard \
-matchbox-keyboard-applet \
-matchbox-keyboard-im \
-matchbox-config-gtk \
 xcursor-transparent-theme \
 sato-icon-theme \
+gnome-theme-adwaita \
 settings-daemon \
-gtk-sato-engine \
 shutdown-desktop \
 libsdl \
 ${NETWORK_MANAGER} \
-- 
2.1.4

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

[OE-core] [RFC PATCH 08/12] settings-daemon: Upgrade to JKU

[Jussi Kukkonen]

Remove patch that's already upstream.

Signed-off-by: Jussi Kukkonen 
---
 .../files/dso_linking_change_build_fix.patch   | 31 --
 .../settings-daemon/settings-daemon_git.bb |  8 +++---
 2 files changed, 4 insertions(+), 35 deletions(-)
 delete mode 100644 
meta/recipes-sato/settings-daemon/files/dso_linking_change_build_fix.patch

diff --git 
a/meta/recipes-sato/settings-daemon/files/dso_linking_change_build_fix.patch 
b/meta/recipes-sato/settings-daemon/files/dso_linking_change_build_fix.patch
deleted file mode 100644
index 5943744..000
--- a/meta/recipes-sato/settings-daemon/files/dso_linking_change_build_fix.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-after gcc linking has changed, all the libraries must be explicitely specified 
to for linking. 
-This patch avoids this linking error:
-
-| make  all-am^M
-| make[1]: Entering directory 
`/disk0/pokybuild/build1/tmp/work/i586-poky-linux/settings-daemon-0.0+svnr2059-r3/settings-daemon'^M
-| ccache i586-poky-linux-gcc -march=i586 
--sysroot=/disk0/pokybuild/build1/tmp/sysroots/i586-poky-linux -Wall 
-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb 
-feliminate-unused-debug-types  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o 
settings-daemon settings_daemon-xsettings-common.o 
settings_daemon-xsettings-manager.o settings_daemon-settings-daemon.o -pthread 
-lgconf-2 -ldbus-glib-1 -ldbus-1 -lpthread -lgdk-x11-2.0 -lgdk_pixbuf-2.0 
-lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 
-lrt -lglib-2.0^M
-| 
/disk0/pokybuild/build1/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.5.1/ld:
 *^A: invalid DSO for symbol `XCreateSimpleWindow' definition^M
-| /disk0/pokybuild/build1/tmp/sysroots/i586-poky-linux/usr/lib/libX11.so.6: 
could not read symbols: Bad value^M
-| collect2: ld returned 1 exit status^M
-| make[1]: *** [settings-daemon] Error 1^M
-| make[1]: Leaving directory 
`/disk0/pokybuild/build1/tmp/work/i586-poky-linux/settings-daemon-0.0+svnr2059-r3/settings-daemon'^M
-| make: *** [all] Error 2^M
-
-Nitin A Kamble 
-Date: 2011/01/11
-
-Index: settings-daemon/configure.ac
-===
 settings-daemon.orig/configure.ac
-+++ settings-daemon/configure.ac
-@@ -14,7 +14,7 @@ AC_PROG_CC
- 
- 
- dnl TODO: make gconf optional
--PKG_CHECK_MODULES(APP, [gconf-2.0 gdk-x11-2.0])
-+PKG_CHECK_MODULES(APP, [gconf-2.0 gdk-x11-2.0 x11])
- 
- 
- AC_SUBST(APP_CFLAGS)
diff --git a/meta/recipes-sato/settings-daemon/settings-daemon_git.bb 
b/meta/recipes-sato/settings-daemon/settings-daemon_git.bb
index c061553..28035e9 100644
--- a/meta/recipes-sato/settings-daemon/settings-daemon_git.bb
+++ b/meta/recipes-sato/settings-daemon/settings-daemon_git.bb
@@ -4,16 +4,16 @@ BUGTRACKER = "http://bugzilla.yoctoproject.org/;
 LICENSE = "MIT-style"
 LIC_FILES_CHKSUM = 
"file://xsettings-manager.h;endline=22;md5=7cfac9d2d4dc3694cc7eb605cf32a69b \
 
file://xsettings-common.h;endline=22;md5=7cfac9d2d4dc3694cc7eb605cf32a69b"
-DEPENDS = "gconf glib-2.0 gtk+"
+DEPENDS = "gconf glib-2.0 gtk+3"
 SECTION = "x11"
-SRCREV = "9a99528b02255450db81176abd9bbcc1dab9a4c1"
+SRCREV = "4a06d2169cf1fdcb4427c105fdc54fc80c3f334b"
 PV = "0.0+git${SRCPV}"
 
 
-SRC_URI = "git://git.yoctoproject.org/xsettings-daemon \
+SRC_URI = "git://github.com/jku/xsettings-daemon.git;branch=gtk3 \
file://addsoundkeys.patch;apply=yes \
file://70settings-daemon.sh \
-   file://dso_linking_change_build_fix.patch"
+   "
 
 S = "${WORKDIR}/git"
 
-- 
2.1.4

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

[OE-core] [RFC PATCH 05/12] matchbox-panel-2: Upgrade to JKU

[Jussi Kukkonen]

This is the GTK3 version.

Signed-off-by: Jussi Kukkonen 
---
 .../matchbox-panel-2/files/silence-warnings.patch  | 64 --
 .../matchbox-panel-2/matchbox-panel-2_git.bb   | 12 ++--
 2 files changed, 6 insertions(+), 70 deletions(-)
 delete mode 100644 
meta/recipes-sato/matchbox-panel-2/files/silence-warnings.patch

diff --git a/meta/recipes-sato/matchbox-panel-2/files/silence-warnings.patch 
b/meta/recipes-sato/matchbox-panel-2/files/silence-warnings.patch
deleted file mode 100644
index 45ba9a0..000
--- a/meta/recipes-sato/matchbox-panel-2/files/silence-warnings.patch
+++ /dev/null
@@ -1,64 +0,0 @@
-Don't warn if the machine doesn't actually have a battery, or if the applets
-string contains consecutive separators.
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-diff --git a/applets/battery/battery-acpi.c b/applets/battery/battery-acpi.c
-index 6515cb0..c44dd12 100644
 a/applets/battery/battery-acpi.c
-+++ b/applets/battery/battery-acpi.c
-@@ -14,8 +14,6 @@ int batt_state, ac_state;
- int pm_support(void)
- {
-   if(check_acpi_support() == NOT_SUPPORTED){
--  g_warning("No ACPI support\n");
--
-   return 0;
-   }
- 
-@@ -32,8 +30,9 @@ const char* pm_battery_icon(void)
-   const char *icon;
-   battery_t *binfo;
- 
-+/* No battery available (not present, disabled, or something
-+   else. Silently do nothing. */
-   if (batt_state != SUCCESS) {
--  g_warning("Couldnt initialize ACPI battery\n");
-   return NULL;
-   }
- 
-diff --git a/applets/battery/battery-apm.c b/applets/battery/battery-apm.c
-index 5467438..2f39cb6 100644
 a/applets/battery/battery-apm.c
-+++ b/applets/battery/battery-apm.c
-@@ -10,8 +10,6 @@
- int pm_support(void)
- {
-   if (1 == apm_exists ()) {
--g_warning ("No APM support");
--
- return 0;
- }
- 
-diff --git a/matchbox-panel/mb-panel.c b/matchbox-panel/mb-panel.c
-index 2d8cafd..828a36d 100644
 a/matchbox-panel/mb-panel.c
-+++ b/matchbox-panel/mb-panel.c
-@@ -110,10 +110,15 @@ load_applets (const char*applets_desc,
- applets = g_strsplit (applets_desc, ",", -1);
- 
- for (i = 0; applets[i]; i++) {
-+char *s;
- char **bits;
- GtkWidget *applet;
- 
--bits = g_strsplit (applets[i], ":", 2);
-+s = applets[i];
-+if (s == NULL || s[0] == '\0')
-+continue;
-+
-+bits = g_strsplit (s, ":", 2);
- 
- applet = load_applet (bits[0],
-   bits[1],
diff --git a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb 
b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
index 61d9e30..5bd629f 100644
--- a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
+++ b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
@@ -5,24 +5,23 @@ BUGTRACKER = "http://bugzilla.yoctoproject.org/;
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
file://matchbox-panel/mb-panel.h;endline=10;md5=0b7db28f4b6863fb853d0467e590019a
 \
-
file://applets/startup/startup.c;endline=22;md5=b0a64fbef3097d79f8264e6907a98f03"
+
file://applets/startup/startup.c;endline=22;md5=7cbcea60b667f609495222faf3e07917"
 
-DEPENDS = "gnome-common gtk+ startup-notification dbus dbus-glib"
+DEPENDS = "gnome-common gtk+3 startup-notification dbus dbus-glib"
 DEPENDS += " ${@bb.utils.contains("MACHINE_FEATURES", "acpi", "libacpi", 
"",d)}"
 DEPENDS += " ${@bb.utils.contains("MACHINE_FEATURES", "apm", "apmd", "",d)}"
 
 # The startup-notification requires x11 in DISTRO_FEATURES
 REQUIRED_DISTRO_FEATURES = "x11"
 
-SRCREV = "26a3a67b41c50e0ae163d8fe86ccf7a0f0a671ae"
+SRCREV = "96c8a89b264a9c19faaa70750c40f3448beb4df2"
 PV = "2.0+git${SRCPV}"
 
 RPROVIDES_${PN} = "matchbox-panel"
 RREPLACES_${PN} = "matchbox-panel"
 RCONFLICTS_${PN} = "matchbox-panel"
 
-SRC_URI = "git://git.yoctoproject.org/${BPN} \
-   file://silence-warnings.patch"
+SRC_URI = "git://github.com/jku/matchbox-panel-2.git;branch=gtk3"
 
 EXTRA_OECONF = "--enable-startup-notification --enable-dbus"
 EXTRA_OECONF += " ${@bb.utils.contains("MACHINE_FEATURES", "acpi", 
"--with-battery=acpi", "",d)}"
@@ -32,7 +31,8 @@ S = "${WORKDIR}/git"
 
 FILES_${PN} += "${libdir}/matchbox-panel/*.so \
 ${datadir}/matchbox-panel/brightness/*.png \
-${datadir}/matchbox-panel/startup/*.png "
+${datadir}/matchbox-panel/startup/*.png \
+${datadir}/icons/"
 FILES_${PN}-dev += "${libdir}/matchbox-panel/*.la"
 
 inherit autotools pkgconfig distro_features_check
-- 
2.1.4

-- 
___
Openembedded-core mailing list

[OE-core] [RFC PATCH 10/12] matchbox-wm: Upgrade to JKU

[Jussi Kukkonen]

This version does not change MBWM theme when the Gtk+ theme
is changed using Net/ThemeName X property.

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb 
b/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb
index 422d255..a7e15a6 100644
--- a/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb
+++ b/meta/recipes-graphics/matchbox-wm/matchbox-wm_git.bb
@@ -10,10 +10,10 @@ LIC_FILES_CHKSUM = 
"file://src/wm.h;endline=21;md5=a7e844465edbcf79c282369f93caa
 SECTION = "x11/wm"
 DEPENDS = "libmatchbox virtual/libx11 libxext libxrender startup-notification 
expat gconf libxcursor libxfixes"
 
-SRCREV = "29544f0e61cc281fc60061443a537271e1081b78"
+SRCREV = "d261f6ff6e9f66da4012d2f9e9d56232b40c68a1"
 PV = "1.2+git${SRCPV}"
 
-SRC_URI = "git://git.yoctoproject.org/matchbox-window-manager \
+SRC_URI = "git://github.com/jku/matchbox-window-manager.git;branch=gtk3 \
file://kbdconfig"
 
 S = "${WORKDIR}/git"
-- 
2.1.4

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

[OE-core] [RFC PATCH 07/12] sato-screenshot: Upgrade to JKU

[Jussi Kukkonen]

This is the GTK3 version

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb 
b/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
index 1b2b65d..b745726 100644
--- a/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
+++ b/meta/recipes-sato/sato-screenshot/sato-screenshot_git.bb
@@ -7,12 +7,12 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
file://main.c;endline=9;md5=023e14d6404d0a961eb97cbd011fc141 \
 
file://screenshot-ui.h;endline=9;md5=638d9ffa83e9325a36df224166ed6ad0"
 
-DEPENDS = "matchbox-panel-2"
-SRCREV = "3a9688e8a01b63a78f402b4e7c0b8b005fcdfa29"
+DEPENDS = "matchbox-panel-2 gtk+3"
+SRCREV = "50e502ee999733a064eb5b45ba87450648485929"
 PV = "0.1+git${SRCPV}"
 PR = "r2"
 
-SRC_URI = "git://git.yoctoproject.org/screenshot"
+SRC_URI = "git://github.com/jku/sato-screenshot.git;branch=gtk3"
 
 S = "${WORKDIR}/git"
 
-- 
2.1.4

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

[OE-core] [RFC PATCH 09/12] gtk-sato-engine: Remove as unused

[Jussi Kukkonen]

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-sato/gtk-engines/gtk-sato-engine.inc  | 25 --
 .../gtk-engines/gtk-sato-engine_git.bb | 14 
 2 files changed, 39 deletions(-)
 delete mode 100644 meta/recipes-sato/gtk-engines/gtk-sato-engine.inc
 delete mode 100644 meta/recipes-sato/gtk-engines/gtk-sato-engine_git.bb

diff --git a/meta/recipes-sato/gtk-engines/gtk-sato-engine.inc 
b/meta/recipes-sato/gtk-engines/gtk-sato-engine.inc
deleted file mode 100644
index 93538ed..000
--- a/meta/recipes-sato/gtk-engines/gtk-sato-engine.inc
+++ /dev/null
@@ -1,25 +0,0 @@
-SUMMARY = "Sato theme engine for GTK+"
-HOMEPAGE = "http://www.o-hand.com;
-BUGTRACKER = "http://bugzilla.yoctoproject.org/;
-
-LICENSE = "LGPLv2.1 & LGPLv2+"
-
-SECTION = "x11/base"
-DEPENDS = "gtk+"
-RDEPENDS_gtk-theme-sato = "gtk-sato-engine"
-
-inherit distro_features_check
-ANY_OF_DISTRO_FEATURES = "${GTK2DISTROFEATURES}"
-
-PACKAGES += "gtk-theme-sato"
-FILES_${PN} = "${libdir}/gtk-2.0/*/engines/*.so "
-FILES_${PN}-dev = "${libdir}/gtk-2.0/*/engines/*.la"
-FILES_gtk-theme-sato = "${datadir}/icons ${datadir}/themes"
-
-inherit autotools-brokensep pkgconfig
-
-do_configure_prepend() {
-   for i in `ls gtk-common`; do
-   ln -sf ../gtk-common/$i gtk2-engine/$i
-   done
-}
diff --git a/meta/recipes-sato/gtk-engines/gtk-sato-engine_git.bb 
b/meta/recipes-sato/gtk-engines/gtk-sato-engine_git.bb
deleted file mode 100644
index da4d98a..000
--- a/meta/recipes-sato/gtk-engines/gtk-sato-engine_git.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-require gtk-sato-engine.inc
-
-LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
-
file://src/sato-utils.h;endline=24;md5=708f28cfe7fe028d497aaf4389b80b62 \
-
file://src/sato-main.c;endline=24;md5=b5e5dddebca570275becb51b526e4c5a"
-
-SRCREV = "4740ad8d53aba4368ce3e03b06cfdc69eb86dcdc"
-PV = "0.3.3+git${SRCPV}"
-
-SRC_URI = "git://git.yoctoproject.org/${BPN}"
-
-S = "${WORKDIR}/git"
-
-EXTRA_OECONF += "${@bb.utils.contains('MACHINE_FEATURES', 'qvga', 
'--with-mode=qvga', '',d)}"
-- 
2.1.4

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

[OE-core] [RFC PATCH 04/12] matchbox-desktop: Ugrade to JKU

[Jussi Kukkonen]

This is the GTK+3 version.

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb 
b/meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb
index 318d2e0..76a041a 100644
--- a/meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb
+++ b/meta/recipes-sato/matchbox-desktop/matchbox-desktop_git.bb
@@ -4,16 +4,15 @@ BUGTRACKER = "http://bugzilla.yoctoproject.org/;
 
 LICENSE = "GPLv2+ & LGPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-
file://libtaku/eggsequence.h;endline=20;md5=b91f68f7642a1459fa1f4c9df94a8f15 \
 
file://src/desktop.c;endline=20;md5=36c9bf295e6007f3423095f405af5a2d \
 
file://src/main.c;endline=19;md5=2044244f97a195c25b7dc602ac7e9a00"
 
-DEPENDS = "gtk+ startup-notification dbus"
+DEPENDS = "gtk+3 startup-notification dbus"
 SECTION = "x11/wm"
-SRCREV = "71e3e6e04271e9d5a14f1c231ef100c7f320134d"
+SRCREV = "4972177fc5c7ce15d4f9c1c98787a98e633a758e"
 PV = "2.0+git${SRCPV}"
 
-SRC_URI = "git://git.yoctoproject.org/${BPN}-2"
+SRC_URI = "git://github.com/jku/matchbox-desktop-2.git;branch=gtk3"
 
 EXTRA_OECONF = "--enable-startup-notification --with-dbus"
 
-- 
2.1.4

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

[OE-core] [RFC PATCH 01/12] gnome-themes-standard: Add new recipe

[Jussi Kukkonen]

Only Adwaita (default GTK+ theme) currently gets installed.

Signed-off-by: Jussi Kukkonen 
---
 .../gnome/gnome-themes-standard_3.18.0.bb  | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 meta/recipes-gnome/gnome/gnome-themes-standard_3.18.0.bb

diff --git a/meta/recipes-gnome/gnome/gnome-themes-standard_3.18.0.bb 
b/meta/recipes-gnome/gnome/gnome-themes-standard_3.18.0.bb
new file mode 100644
index 000..06135e0
--- /dev/null
+++ b/meta/recipes-gnome/gnome/gnome-themes-standard_3.18.0.bb
@@ -0,0 +1,37 @@
+SUMMARY = "GTK+2 standard themes"
+HOMEPAGE = "http://ftp.gnome.org/pub/GNOME/sources/gnome-themes-standard/;
+BUGTRACKER = "https://bugzilla.gnome.org/;
+SECTION = "x11/gnome"
+
+LICENSE = "LGPL-2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1"
+
+inherit autotools pkgconfig gettext gtk-icon-cache upstream-version-is-even
+
+DEPENDS += "intltool-native gtk+"
+
+MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
+SRC_URI = "${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
+  "
+
+SRC_URI[md5sum] = "4d17bc62e4d0c5440fc4eda3d9271367"
+SRC_URI[sha256sum] = 
"e646eb04c225282b7df7fff65741adaad4cf9ed2c12616b7310e7edd27d2bacb"
+
+EXTRA_OECONF = "--disable-gtk3-engine"
+
+do_install_append() {
+# Only building Adwaita, remove highcontrast files
+rm -rf ${D}${prefix}/share/themes/HighContrast \
+   ${D}${prefix}/share/icons
+}
+
+# There could be gnome-theme-highcontrast as well but that requires
+# gtk+3 and includes lots of icons (is also broken with B != S).
+PACKAGES += "gnome-theme-adwaita \
+ gnome-theme-adwaita-dbg \
+ gnome-theme-adwaita-dev"
+
+FILES_gnome-theme-adwaita = "${prefix}/share/themes/Adwaita \
+  ${libdir}/gtk-2.0/2.10.0/engines/libadwaita.so"
+FILES_gnome-theme-adwaita-dev = 
"${libdir}/gtk-2.0/2.10.0/engines/libadwaita.la"
+FILES_gnome-theme-adwaita-dbg = 
"${libdir}/gtk-2.0/2.10.0/engines/.debug/libadwaita.so"
-- 
2.1.4

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

[OE-core] [RFC PATCH 00/12] Sato desktop upgrade (Gtk3 etc.)

[Jussi Kukkonen]

Here's a snapshot of the Sato upgrade I've been working on (YOCTO
 #3169). It's based on Ross' work from 2.5 years back. The bigger
changes currently live as my forks of the upstream projects (gtk3
branches of various projects at https://github.com/jku), and the
patchset here modifies recipes to temporarily use those forks:
this is intended to make testing and review possible but also
means this is just an RFC: once the upstream changes are merged,
I'll update this patchset.


For those not familiar with it, the goal of the exercise is to
 1. Bring Sato desktop closer to this decade (Don't depend on
ancient components, remove deprecated code)
 2. Focus more on delivering an environment for validating and
testing oe-core, less on building a DE for mobile devices


Major changes:
 * Ports to GTK3: matchbox-desktop, matchbox-panel-2,
   connman-gnome, sato-screenshot, xsettings-daemon
 * GTK+ theme is Adwaita (upstream default)
 * Matchbox WM theme modified to somewhat resemble Adwaita (boring
   gray instead of in-your-face green)
 * Matchbox panel is no longer drawn on top of application titlebars
   because that fails badly with client side decorations. Instead
   it's a thinner panel always on top of screen, like gnome2 panel.
 * Custom GTK theme engine is dropped
Here's a screenshot showing the panel and window decoration:
http://imgur.com/noqptiu


Regressions:
 * on-screen keyboard: I've not looked very closely but I
   believe this requires IM work for GTK3
 * startup notification


Questions:
 * Schedule: this is for Yocto 2.1 in bugzilla (now M3) but got
   delayed. it's a bigger change and isn't ready to merge
   (as the upstream patches need review). Should I aim for next
   release instead?
 * How should we do review on this? The upstreams are mostly on
   yoctoproject.org so I could send patches to some YP mailing list...
   but testing many of the patches is impossible without the patches
   for the other projects.
 * Are the regressions listed above blockers?
 * Anything I've missed? Theme design bikeshedding?


Cheers,
  Jussi


The following changes since commit 37b61b059031e3c272a929b834e12fd83f46598c:

  siteinfo: Add ppc64le support. (2016-03-10 23:13:55 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jku/matchbox-wip
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/matchbox-wip

Jussi Kukkonen (12):
  gnome-themes-standard: Add new recipe
  packagegroup-core-x11-sato: Update for GTK3 changes
  matchbox-theme-sato: Upgrade to JKU
  matchbox-desktop: Ugrade to JKU
  matchbox-panel-2: Upgrade to JKU
  matchbox-session-sato: Update session startup
  sato-screenshot: Upgrade to JKU
  settings-daemon: Upgrade to JKU
  gtk-sato-engine: Remove as unused
  matchbox-wm: Upgrade to JKU
  connman-gnome: Upgrade to JKU
  matchbox-panel-2: Depend on dbus-glib-native for binding-tool

 .../connman-gnome-fix-dbus-interface-name.patch| 187 -
 .../connman-gnome/images/connman-signal-01.png | Bin 490 -> 0 bytes
 .../connman-gnome/images/connman-signal-02.png | Bin 496 -> 0 bytes
 .../connman-gnome/images/connman-signal-03.png | Bin 492 -> 0 bytes
 .../connman-gnome/images/connman-signal-04.png | Bin 470 -> 0 bytes
 .../connman-gnome/images/connman-signal-05.png | Bin 419 -> 0 bytes
 .../connman/connman-gnome_0.7.bb   |  12 +-
 .../gnome/gnome-themes-standard_3.18.0.bb  |  37 
 .../matchbox-wm/matchbox-wm_git.bb |   4 +-
 meta/recipes-sato/gtk-engines/gtk-sato-engine.inc  |  25 ---
 .../gtk-engines/gtk-sato-engine_git.bb |  14 --
 .../matchbox-desktop/matchbox-desktop_git.bb   |   7 +-
 .../matchbox-panel-2/files/silence-warnings.patch  |  64 ---
 .../matchbox-panel-2/matchbox-panel-2_git.bb   |  12 +-
 .../matchbox-sato/matchbox-session-sato/session|   9 +-
 .../matchbox-sato/matchbox-session-sato_0.1.bb |   4 +-
 .../matchbox-theme-sato/matchbox-theme-sato_0.1.bb |   8 -
 .../matchbox-theme-sato/matchbox-theme-sato_git.bb |   8 +-
 .../packagegroups/packagegroup-core-x11-sato.bb|   6 +-
 .../sato-screenshot/sato-screenshot_git.bb |   6 +-
 .../files/dso_linking_change_build_fix.patch   |  31 
 .../settings-daemon/settings-daemon_git.bb |   8 +-
 22 files changed, 65 insertions(+), 377 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/connman-gnome-fix-dbus-interface-name.patch
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
 delete mode 100644 
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-05.png
 

[OE-core] [PATCH 2/2] build-appliance: make the inclusion of downloaded sources optional

[Joshua Lock]

Including the entirety of DL_DIR in the generated build appliance
image adds a significant amount of space and makes the build
appliance image more awkward to distribute. Add a configuration
option to make the inclusion of sources option and default to
disabling this functionality.

Signed-off-by: Joshua Lock 
---
 meta/recipes-core/images/build-appliance-image_14.0.0.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/images/build-appliance-image_14.0.0.bb 
b/meta/recipes-core/images/build-appliance-image_14.0.0.bb
index 8f9ce1b..61f69f4 100644
--- a/meta/recipes-core/images/build-appliance-image_14.0.0.bb
+++ b/meta/recipes-core/images/build-appliance-image_14.0.0.bb
@@ -26,6 +26,7 @@ SRC_URI = "git://git.yoctoproject.org/poky \
file://Yocto_Build_Appliance.vmx \
file://Yocto_Build_Appliance.vmxf \
   "
+BA_INCLUDE_SOURCES ??= "0"
 
 IMAGE_CMD_ext4_append () {
# We don't need to reserve much space for root, 0.5% is more than enough
@@ -42,7 +43,9 @@ fakeroot do_populate_poky_src () {
 
mkdir -p ${IMAGE_ROOTFS}/home/builder/poky/build/conf
mkdir -p ${IMAGE_ROOTFS}/home/builder/poky/build/downloads
-   cp -RpL ${DL_DIR}/* ${IMAGE_ROOTFS}/home/builder/poky/build/downloads/
+   if [ ${BA_INCLUDE_SOURCES} != 0 ]; then
+   cp -RpL ${DL_DIR}/* 
${IMAGE_ROOTFS}/home/builder/poky/build/downloads/
+   fi
 
# Remove the git2_* tarballs -- this is ok since we still have the 
git2/.
rm -rf ${IMAGE_ROOTFS}/home/builder/poky/build/downloads/git2_*
-- 
2.5.0

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

[OE-core] [PATCH 1/2] builder: remove hob from autostart

[Joshua Lock]

hob has been removed so don't try and autostart it with the mini-x
session in the build appliance.

Remove the please_wait_dialog program which informed the user to
wait for Hob to start.

Rename the mini-x autostart file to reflect the removal of hob, we
now just start a matchbox-terminal with the environment configured.

Signed-off-by: Joshua Lock 
---
 meta/recipes-graphics/builder/builder_0.1.bb   | 10 +++---
 .../builder/files/builder_hob_start.sh | 37 --
 .../builder/files/builder_session.sh   | 33 +++
 .../builder/files/please_wait_dialog.py| 28 
 4 files changed, 37 insertions(+), 71 deletions(-)
 delete mode 100644 meta/recipes-graphics/builder/files/builder_hob_start.sh
 create mode 100644 meta/recipes-graphics/builder/files/builder_session.sh
 delete mode 100644 meta/recipes-graphics/builder/files/please_wait_dialog.py

diff --git a/meta/recipes-graphics/builder/builder_0.1.bb 
b/meta/recipes-graphics/builder/builder_0.1.bb
index bb729fc..0a64c31 100644
--- a/meta/recipes-graphics/builder/builder_0.1.bb
+++ b/meta/recipes-graphics/builder/builder_0.1.bb
@@ -3,10 +3,9 @@ DESCRIPTION = "This recipe create a new user named ${PN}, who 
is used for specif
 SECTION = "x11"
 PR = "r6"
 LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://builder_hob_start.sh;endline=5;md5=84796c3c41785d86100fdabcbdade00e"
+LIC_FILES_CHKSUM = 
"file://builder_session.sh;endline=5;md5=84796c3c41785d86100fdabcbdade00e"
 
-SRC_URI = "file://builder_hob_start.sh \
-   file://please_wait_dialog.py \
+SRC_URI = "file://builder_session.sh \
   "
 
 S = "${WORKDIR}"
@@ -25,9 +24,8 @@ USERADD_PARAM_${PN} = "--system --create-home \
 
 do_install () {
install -d -m 755 ${D}${sysconfdir}/mini_x/session.d
-   install -p -m 755 builder_hob_start.sh 
${D}${sysconfdir}/mini_x/session.d/
+   install -p -m 755 builder_session.sh ${D}${sysconfdir}/mini_x/session.d/
 
-   chown  builder.builder 
${D}${sysconfdir}/mini_x/session.d/builder_hob_start.sh
-install -p -m 755 please_wait_dialog.py ${D}${sysconfdir}/mini_x
+   chown  builder.builder 
${D}${sysconfdir}/mini_x/session.d/builder_session.sh
 }
 
diff --git a/meta/recipes-graphics/builder/files/builder_hob_start.sh 
b/meta/recipes-graphics/builder/files/builder_hob_start.sh
deleted file mode 100644
index b394b09..000
--- a/meta/recipes-graphics/builder/files/builder_hob_start.sh
+++ /dev/null
@@ -1,37 +0,0 @@
-#!/bin/sh
-#This script will be called via mini X session on behalf of file owner, after
-#installed in /etc/mini_x/session.d/. Any auto start jobs including X apps can
-#be put here
-
-# start hob here
-export PSEUDO_PREFIX=/usr
-export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
-export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
-export GIT_PROXY_COMMAND=/home/builder/poky/scripts/oe-git-proxy
-
-#start pcmanfm in daemon mode to allow asynchronous launch
-pcmanfm -d&
-
-#register handlers for some file types
-if [ ! -d /home/builder/.local/share/applications ]; then
-mkdir -p /home/builder/.local/share/applications/
-#register folders to open with PCManFM filemanager
-xdg-mime default pcmanfm.desktop inode/directory
-
-#register html links and files with epiphany
-xdg-mime default epiphany.desktop x-scheme-handler/http
-xdg-mime default epiphany.desktop x-scheme-handler/https
-xdg-mime default epiphany.desktop text/html
-
-#register text files with leafpad text editor
-xdg-mime default leafpad.desktop text/plain
-fi
-
-cd /home/builder/poky
-. ./oe-init-build-env
-
-hob &
-
-matchbox-terminal&
-
-/etc/mini_x/please_wait_dialog.py &
diff --git a/meta/recipes-graphics/builder/files/builder_session.sh 
b/meta/recipes-graphics/builder/files/builder_session.sh
new file mode 100644
index 000..001a033
--- /dev/null
+++ b/meta/recipes-graphics/builder/files/builder_session.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+#This script will be called via mini X session on behalf of file owner, after
+#installed in /etc/mini_x/session.d/. Any auto start jobs including X apps can
+#be put here
+
+# start hob here
+export PSEUDO_PREFIX=/usr
+export PSEUDO_LOCALSTATEDIR=/home/builder/pseudo
+export PSEUDO_LIBDIR=/usr/lib/pseudo/lib64
+export GIT_PROXY_COMMAND=/home/builder/poky/scripts/oe-git-proxy
+
+#start pcmanfm in daemon mode to allow asynchronous launch
+pcmanfm -d&
+
+#register handlers for some file types
+if [ ! -d /home/builder/.local/share/applications ]; then
+mkdir -p /home/builder/.local/share/applications/
+#register folders to open with PCManFM filemanager
+xdg-mime default pcmanfm.desktop inode/directory
+
+#register html links and files with epiphany
+xdg-mime default epiphany.desktop x-scheme-handler/http
+xdg-mime default epiphany.desktop x-scheme-handler/https
+xdg-mime default epiphany.desktop text/html
+
+#register text files with leafpad text editor
+xdg-mime 

[OE-core] what is the precise search path for resolving "include" or "require" .inc files?

[Robert P. J. Day]

  not sure why i never noticed this before, but what is the search order
or precedence or priority for resolving recipe file directives "include"
or "require"? i was just perusing the bitbake user manual, and noticed
the explanation that those directives use BBPATH to track down the first
include file by a given name.

  but AIUI, BBPATH is supposed to represent an ordered set of *layers*
(i just examined BBPATH for a current [wind river linux] build, and that
is exactly what it seems to contain). so when a recipe file like
busybox.whatever.bb contains the line:

  require busybox.inc

i always just assumed the search would look in the current busybox
directory, but that directory is not technically a layer directory --
it's not a directory specified on the alleged BBPATH search path.

  i never thought about this until i noticed some .bbappend files
specifically using directives like:

  require recipes-bsp/u-boot/u-boot.inc

where that file reference *does* refer to a file relative to some
actual layer directory somewhere.

  what am i missing here?

rday


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

Re: [OE-core] [meta-oe][PATCH v2] nettle: The variable named p in the patch file was incorrectly named.

[Joshua G Lock]

On Wed, 2016-03-09 at 09:17 -0700, ngutzmann wrote:
> The variable in question should have been called ecc->p. The patch
> has been updated
> so that the compilation of the nettle recipe would complete
> successfully. The backport
> originated from this commit
> https://git.lysator.liu.se/nettle/nettle/commit/c71d2c9d20eeebb985e38
> 72e4550137209e3ce4d

Thanks a lot for this patch, I've just proposed it for inclusion in the
Fido branch.

I missed this originally because it's not tagged fido, for future it's
worth pointing out that in order to be sure patches for stable branches
are noticed by the maintainers we request the subject is prefixed with
[branchname].

Thanks again for your contribution.

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

[OE-core] [Fido][PATCH 0/1] Fido pull request

[Joshua Lock]

The single patch fixes nettle which was broken by a recent security fix.
Please merge it as soon as is convenient.

Regards,

Joshua

The following changes since commit 6c06c42594539bec4c360c8cc28ebee8a338e6b4:

  openssl: Security fix CVE-2016-0800 (2016-03-03 10:42:51 +)

are available in the git repository at:

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

ngutzmann (1):
  nettle: The variable named p in the patch file was incorrectly named.

 meta/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.5.0

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

[OE-core] [PATCH 1/1] init-live : make it easier to add custom boot targets

[Jérémy Rosen]

When booting from the live image, the label from the bootloader is passed
to init.sh. init.sh uses the label to either boot a live image or call a
script to take over and install the system.

It is possible to add new labels to the bootloader via the LABELS family of
variables, but the names in init.sh were hardcoded to install and
install-efi

this patch checks if a shell script with the same name as the label is
available instead of using a hardcoded list. Any recipe can add such file
and this provide a new boot target to the live image

Signed-off-by: Jérémy Rosen 
---
 meta/recipes-core/initrdscripts/files/init-live.sh | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh 
b/meta/recipes-core/initrdscripts/files/init-live.sh
index d852c57..f698535 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -214,11 +214,7 @@ mount_and_boot() {
 boot_live_root
 }
 
-case $label in
-boot)
-   mount_and_boot
-   ;;
-install|install-efi)
+if [ "$label" != "boot" -a -f $label.sh ] ; then
if [ -f /run/media/$i/$ISOLINUX/$ROOT_IMAGE ] ; then
./$label.sh $i/$ISOLINUX $ROOT_IMAGE $video_mode $vga_mode 
$console_params
else
@@ -226,10 +222,8 @@ case $label in
fi
 
# If we're getting here, we failed...
-   fatal "Installation image failed"
-   ;;
-*)
-   # Not sure what boot label is provided.  Try to boot to avoid locking 
up.
-   mount_and_boot
-   ;;
-esac
+   fatal "Target $label failed"
+fi
+
+mount_and_boot
+
-- 
2.7.0

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

[OE-core] [PATCH] perl: fix missing dependency for perl-misc

[Catalin Enache]

"perl-misc" package is adding tens of perl utilities which have
depencies on perl-modules.

For example, in order for "prove" to work correctly following modules
are needed:

RDEPENDS_perl-misc += "perl perl-module-app-prove
perl-module-overloading perl-module-tap-base perl-module-file-glob
perl-module-tap-formatter-console perl-module-tap-formatter-base
perl-module-tap-formatter-file perl-module-tap-formatter-session
perl-module-tap-parser perl-module-tap-parser-aggregator
perl-module-tap-parser-scheduler"

If we compile a list of modules needed by the utilities added by
"perl-misc" we may end up having to add hundreds of modules to
RDEPENDS_perl-misc.

Rather than adding hundreds of dependencies only perl-modules was added.

Signed-off-by: Catalin Enache 
---
 meta/recipes-devtools/perl/perl-rdepends_5.22.1.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/perl/perl-rdepends_5.22.1.inc 
b/meta/recipes-devtools/perl/perl-rdepends_5.22.1.inc
index 033d4e3..830ecce 100644
--- a/meta/recipes-devtools/perl/perl-rdepends_5.22.1.inc
+++ b/meta/recipes-devtools/perl/perl-rdepends_5.22.1.inc
@@ -13,7 +13,7 @@
 #| sed 
's/^/RDEPENDS_/;s/perl-module-/${PN}-module-/g;s/module-\(module-\)/\1/g;s/\(module-load\)-conditional/\1/g;s/encode-configlocal/&-pm/;'
 
 #| egrep -wv 
'=>|module-a|module-apache.?|module-apr|module-authen-sasl|module-b-asmdata|module-convert-ebcdic|module-devel-size|module-digest-perl-md5|module-dumpvalue|module-extutils-constant-aaargh56hash|module-extutils-xssymset|module-file-bsdglob|module-for|module-it|module-io-string|module-ipc-system-simple|module-lexical|module-local-lib|metadata|module-modperl-util|module-pluggable-object|module-test-builder-io-scalar|module-text-unidecode|module-win32|objects\sload|syscall.ph|systeminfo.ph|%s'
 > /tmp/perl-rdepends
 
-RDEPENDS_perl-misc += "perl"
+RDEPENDS_perl-misc += "perl perl-modules"
 RDEPENDS_${PN}-pod += "perl"
 
 # Some additional dependencies that the above doesn't manage to figure out
-- 
1.9.1

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

Re: [OE-core] [PATCH 1/1] ncurses_6: Fix an install race condition

[Burton, Ross]

Hi Juro,

On 11 March 2016 at 02:07, Juro Bystricky  wrote:

> +As both targets install identical files. The remedy is to either prevent
> +parallel make of install.libs and install.includes, or ensure only one
> +target installs the files.
> +The second approch will only work if we always install both libs and
> +includes (which we do).
>

Wouldn't an upstreamable fix be to make install.includes the target that
actually does something, and then have install depend on that?  Considering
install.libs and install.includes are separate rules, surely install.libs
in the header makefile should do nothing?  (ncurses is weird...)

Have you checked the other makefiles for the same problem?

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

Re: [OE-core] [PATCH 1/1] python3: fix do_configure check platform triplet error

[Richard Purdie]

On Fri, 2016-03-11 at 09:04 +, Burton, Ross wrote:
> 
> On 11 March 2016 at 07:40, Hongxu Jia 
> wrote:
> > For p1022ds bsp, the MULTIARCH is powerpc-linux-gnuspev1 and
> > python3 did not recognize the extra 'v1' which caused python3
> > configure error for the platform triplet.
> > 
> Forgive me for dry-by commenting without a lot of clue about this,
> but doesn't that suggest instead that the C function to emit the
> triplets is in fact wrong?

Following the links does give more context. The "bad" triplet is
actually coming from gcc and Hongxu's original patch did change gcc to
"fix" it. Unfortunately it does so at the risk of other problems to
gcc.

The gcc-cross recipes aren't working entirely correctly at the moment
and its just good luck (and sstate) which are meaning things do
actually work out.

The trouble is that changing gcc right now to fix this properly isn't
something we can easily do. So this patch might be the right short term
workaround.

Cheers,

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

Re: [OE-core] [PATCH 1/1] python3: fix do_configure check platform triplet error

[Burton, Ross]

On 11 March 2016 at 07:40, Hongxu Jia  wrote:

> For p1022ds bsp, the MULTIARCH is powerpc-linux-gnuspev1 and
> python3 did not recognize the extra 'v1' which caused python3
> configure error for the platform triplet.
>

Forgive me for dry-by commenting without a lot of clue about this, but
doesn't that suggest instead that the C function to emit the triplets is in
fact wrong?

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