[OE-core] npm thoughts

[Trevor Woerner]

Hi,

I was trying out devtool+npm with the electron quick-start node stuff and
noticed some interesting results. This simple app can be found at
https://github.com/electron/electron-quick-start

According to https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM there are
two ways to create a recipe for a node app using The Yocto Project's devtool:
1) by pointing devtool at the npm registry
2) by pointing devtool at the project's source code
It is also possible to:
3) point to a tarball of the project's source

Preparation for 2) is as follows:
$ git clone git://github.com/electron/electron-quick-start

Further preparation for 3) continues:
$ tar -c electron-quick-start/ > electron-quick-start.tar
$ gzip electron-quick-start.tar

It is important to note that the following assumes morty. Master is messed up
right now with the introduction of per-recipe sysroots (but is expected to get
fixed eventually). The layers used are openembedded-core:morty, bitbake:1.32,
and meta-openembedded:morty.

This app's package.json is:

{
  "name": "electron-quick-start",
  "version": "1.0.0",
  "description": "A minimal Electron application",
  "main": "main.js",
  "scripts": {
"start": "electron ."
  },  
  "repository": "https://github.com/electron/electron-quick-start;,
  "keywords": [
"Electron",
"quick",
"start",
"tutorial",
"demo"
  ],  
  "author": "GitHub",
  "license": "CC0-1.0",
  "devDependencies": {
"electron": "^1.4.1"
  }
}


Testing 3)
$ . layers/openembedded-core/oe-init-build-env tarball layers/bitbake
edit conf/bblayers.conf to add meta-openembedded/meta-oe
$ devtool add electron-quick-start 
~/npm/source/electron-quick-start.tar.gz

Here is the recipe devtool creates:
# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in 
order to be fully functional.
# (Feel free to remove these comments when editing.)

SUMMARY = "A minimal Electron application"
# WARNING: the following LICENSE and LIC_FILES_CHKSUM values 
are best guesses - it is
# your responsibility to verify that the values are complete 
and correct.
#
# The following license files were not able to be identified 
and are
# represented as "Unknown" below, you will need to check them 
yourself:
#   LICENSE.md
#
LICENSE = "CC0-1.0"
LIC_FILES_CHKSUM = 
"file://LICENSE.md;md5=c4bb4655ae0c8ab590a1aa591e3a80c5"

SRC_URI = "file:///z/npm/source/electron-quick-start.tar.gz"

NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"

inherit npm 

# Must be set after inherit npm since that itself sets S
S = "${WORKDIR}/electron-quick-start.git"
LICENSE_${PN} = "CC0-1.0"

$ bitbake electron-quick-start
$ tree 
tmp-glibc/work/i586-oe-linux/electron-quick-start/1.0.0-r0/packages-split/electron-quick-start
electron-quick-start
└── usr
└── lib
└── node_modules
└── electron-quick-start
├── index.html
├── LICENSE.md
├── main.js
├── package.json
├── README.md
└── renderer.js


Testing 2)
$ . layers/openembedded-core/oe-init-build-env clone layers/bitbake
edit conf/bblayers.conf to add meta-openembedded/meta-oe
$ devtool add electron-quick-start ~/npm/source/electron-quick-start.git

Here is the recipe:
# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in 
order to be fully functional.
# (Feel free to remove these comments when editing.)

SUMMARY = "A minimal Electron application"
# WARNING: the following LICENSE and LIC_FILES_CHKSUM values 
are best guesses - it is
# your responsibility to verify that the values are complete 
and correct.
#
# The following license files were not able to be identified 
and are
# represented as "Unknown" below, you will need to check them 
yourself:
#   LICENSE.md
#
LICENSE = "CC0-1.0"
LIC_FILES_CHKSUM = 
"file://LICENSE.md;md5=c4bb4655ae0c8ab590a1aa591e3a80c5"

SRC_URI = "git://github.com/electron/electron-quick-start.git"

# Modify these as desired
PV = "1.0.0+git${SRCPV}"

Re: [OE-core] Yocto Project Status WW09’17

[akuster808]

On 02/27/2017 08:59 AM, Jolley, Stephen K wrote:


Current Dev Position: YP 2.3 M3

Next Deadline: YP 2.3 M3 by Feb. 27, 2017

*** FEATURE FREEZE for 2.3 is now in effect. ***

SWAT team rotation: Anibal -> Todor on Feb. 24, 2017.

SWAT team rotation: Todor -> Tracy on Mar. 4, 2017.

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

Key Status/Updates:

·We’re now into feature freeze for 2.3.

·We need to decide which recently submitted items should be merged. 
Some major items In particular:


orpm v4/dnf to replace rpm v5/smart?

IMHO, we should include dnf in 2.3 so folks can start playing with it 
and remove smart in 2.4.



oMerging go into OE-Core?

oSeparate out elderly GPLv2 into a separate layer?


yes, but maybe not for 2.3 if its a large effort.


oGraphics stack vulkan changes?

The "Go" changes hit before the vulkan. Both should have the same rules 
applied which ever way the decision goes.




oLarge queue of wic changes?

I am leaning towards trying to take these even if they do delay the M3 
release slightly as we do have some time left in M4 to stabilize.


·Unfortunately we continue to have stability issues in testing. There 
appear to be some intermittent failures which have crept into master 
and M3 merging will likely be delayed until those issues have been 
tracked down. They seem to affect sdk image size, breaking the 4GB 
limit and eSDKs stopping containing libxml2 under unknown 
circumstances, possibly amongst other issues.


·YP 2.2.1 has been released



thanks to all that help.


Proposed upcoming dot releases:

YP 2.1.3 Cut off May 15, 2017

YP 2.1.3 Release by May 26, 2017

YP 2.2.2 Cut off May 29, 2017

YP 2.2.2 Release by June 9, 2017



I like the dot release schedule. Helps me focus.

kind regards,
Armin


Key YP 2.3 Dates:

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.3 M4 Cutoff is April 10, 2017

YP 2.3 M4 Release is May 5, 2017

Tracking Metrics:

WDD 2747 (last week 2682)

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

Key Status Links for YP:

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

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

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


[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.jolley@intel.com_





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

[OE-core] [PATCH 1/1] recipes-extended: Move efivar from meta-openembedded to oe-core

[California Sullivan]

BSPs for platforms using UEFI, such as meta-intel, would like to have
this more widely available for future support enhancements.

This is a direct copy of the recipe from meta-openembedded/meta-oe.

Signed-off-by: California Sullivan 
---
We are aware that this was recently blacklisted in meta-oe, but we were
unable to reproduce the issue under any circumstances.

 .../efivar/0001-efivar-fix-for-cross-compile.patch | 35 +
 .../efivar/efivar/0002-disable-static-build.patch  | 33 
 .../efivar/0003-efivar-fix-for-cross-compile.patch | 44 +
 .../0004-fix-unknow-option-for-gold-linker.patch   | 38 ++
 .../allow-multi-definitions-for-native.patch   | 23 +++
 .../fix-compile-failure-with-host-gcc-4.6.patch| 45 ++
 meta/recipes-extended/efivar/efivar_0.24.bb| 43 +
 7 files changed, 261 insertions(+)
 create mode 100644 
meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
 create mode 100644 
meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch
 create mode 100644 
meta/recipes-extended/efivar/efivar/0003-efivar-fix-for-cross-compile.patch
 create mode 100644 
meta/recipes-extended/efivar/efivar/0004-fix-unknow-option-for-gold-linker.patch
 create mode 100644 
meta/recipes-extended/efivar/efivar/allow-multi-definitions-for-native.patch
 create mode 100644 
meta/recipes-extended/efivar/efivar/fix-compile-failure-with-host-gcc-4.6.patch
 create mode 100644 meta/recipes-extended/efivar/efivar_0.24.bb

diff --git 
a/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch 
b/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
new file mode 100644
index 000..6f6ca64
--- /dev/null
+++ 
b/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
@@ -0,0 +1,35 @@
+From 9a3c480af653b37e62d1be04d49fe7a60a80168f Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Fri, 25 Sep 2015 18:14:31 +0800
+Subject: [PATCH 1/2] efivar: fix for cross compile
+
+It builds and calls elf file makeguids to generate a header file which
+doesn't work for cross compile. Fix it.
+
+Signed-off-by: Kai Kang 
+
+Upstream-Status: Pending
+Signed-off-by: Hongxu Jia 
+
+---
+ src/Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/Makefile b/src/Makefile
+index 5fc7887..1829d22 100644
+--- a/src/Makefile
 b/src/Makefile
+@@ -29,8 +29,8 @@ all : deps $(TARGETS)
+ ./guid-symbols.c : include/efivar/efivar-guids.h
+ ./guids.bin : include/efivar/efivar-guids.h
+ ./names.bin : include/efivar/efivar-guids.h
+-include/efivar/efivar-guids.h : makeguids guids.txt
+-  ./makeguids guids.txt guids.bin names.bin \
++include/efivar/efivar-guids.h : guids.txt
++  makeguids guids.txt guids.bin names.bin \
+   guid-symbols.c include/efivar/efivar-guids.h
+ 
+ makeguids : CPPFLAGS+=-DEFIVAR_BUILD_ENVIRONMENT
+-- 
+2.4.3
+
diff --git 
a/meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch 
b/meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch
new file mode 100644
index 000..951b159
--- /dev/null
+++ b/meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch
@@ -0,0 +1,33 @@
+From 126e0d3c1ad74cf5b0abe9e98ec444bcc3c83159 Mon Sep 17 00:00:00 2001
+From: Koen Kooi 
+Date: Fri, 4 Mar 2016 14:53:55 +0100
+Subject: [PATCH 2/2] disable static build
+
+Signed-off-by: Koen Kooi 
+
+Upstream-Status: Inappropriate [meta-oe specific]
+Signed-off-by: Hongxu Jia 
+
+---
+ src/Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/Makefile b/src/Makefile
+index 1829d22..c7a0ca3 100644
+--- a/src/Makefile
 b/src/Makefile
+@@ -8,9 +8,9 @@ include $(TOPDIR)/Make.defaults
+ 
+ LIBTARGETS=libefivar.so libefiboot.so
+ STATICLIBTARGETS=libefivar.a libefiboot.a
+-BINTARGETS=efivar efivar-static
++BINTARGETS=efivar
+ PCTARGETS=efivar.pc efiboot.pc
+-TARGETS=$(LIBTARGETS) $(STATICLIBTARGETS) $(BINTARGETS) $(PCTARGETS)
++TARGETS=$(LIBTARGETS) $(BINTARGETS) $(PCTARGETS)
+ 
+ LIBEFIBOOT_SOURCES = crc32.c creator.c disk.c gpt.c linux.c loadopt.c
+ LIBEFIBOOT_OBJECTS = $(patsubst %.c,%.o,$(LIBEFIBOOT_SOURCES))
+-- 
+2.4.3
+
diff --git 
a/meta/recipes-extended/efivar/efivar/0003-efivar-fix-for-cross-compile.patch 
b/meta/recipes-extended/efivar/efivar/0003-efivar-fix-for-cross-compile.patch
new file mode 100644
index 000..3f43f2a
--- /dev/null
+++ 
b/meta/recipes-extended/efivar/efivar/0003-efivar-fix-for-cross-compile.patch
@@ -0,0 +1,44 @@
+From 7ead29ca6bb5e280ae07551cc3521281ecf73682 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia 
+Date: Sat, 7 May 2016 02:06:47 -0400
+Subject: [PATCH] Makefile: fix efivar.pc not found
+
+It 

[OE-core] [PATCH v3 1/1] kernel.bbclass: Give sanity check function an opt-out variable

[California Sullivan]

Having no opt-out method and adding the task to linux-yocto.inc was
causing issues. For example, linux-yocto-dev would often fail because
it uses AUTOREV with no way to dynamically change the PV.

Add a variable to turn off the sanity check, allowing an easy opt out,
and set the opt-out variable in linux-yocto-dev, fixing the issue with
AUTOREV.

v2 changes:
 * Update commit message, removing typos and highlighting the patch will
   effect all kernels.

v3 changes:
 * It was decided the change was too invasive, so move function back to
   linux-yocto.inc so that what it doesn't affect all kernels. Remove
   note about effecting all kernels.

Signed-off-by: California Sullivan 
---
 meta/classes/kernel.bbclass  | 6 +-
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 97cba92..1fa33e2 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -325,6 +325,10 @@ do_install[prefuncs] += "package_get_auto_pr"
 
 # Must be ran no earlier than after do_kernel_checkout or else Makefile won't 
be in ${S}/Makefile
 do_kernel_version_sanity_check() {
+   if [ "x${KERNEL_VERSION_SANITY_SKIP}" = "x1" ]; then
+   exit 0
+   fi
+
# The Makefile determines the kernel version shown at runtime
# Don't use KERNEL_VERSION because the headers it grabs the version 
from aren't generated until do_compile
VERSION=$(grep "^VERSION =" ${S}/Makefile | sed s/.*=\ *//)
@@ -348,7 +352,7 @@ do_kernel_version_sanity_check() {
reg="${reg}${EXTRAVERSION}"
 
if [ -z `echo ${PV} | grep -E "${reg}"` ]; then
-   bbfatal "Package Version (${PV}) does not match of kernel being 
built (${vers}). Please update the PV variable to match the kernel source."
+   bbfatal "Package Version (${PV}) does not match of kernel being 
built (${vers}). Please update the PV variable to match the kernel source or 
set KERNEL_VERSION_SANITY_SKIP=\"1\" in your recipe."
fi
exit 0
 }
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index a4e02db..d5579b2 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -43,3 +43,4 @@ KERNEL_FEATURES_append_qemux86=" cfg/sound.scc 
cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
 KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " 
cfg/x32.scc", "" ,d)}"
 
+KERNEL_VERSION_SANITY_SKIP = "1"
-- 
2.5.5

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

Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)

[Joe MacDonald]

[Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED 
variable for recipes (rev3)] On 17.02.27 (Mon 14:25) Leonardo Sandoval wrote:

> On Mon, 2017-02-27 at 15:06 -0500, Joe MacDonald wrote:
> > [✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable 
> > for recipes (rev3)] On 17.02.27 (Mon 18:33) Patchwork wrote:
> > 
> > > == Series Details ==
> > > 
> > > Series: deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
> > > Revision: 3
> > > URL   : https://patchwork.openembedded.org/series/5489/
> > > State : failure
> > > 
> > > == Summary ==
> > > 
> > > 
> > > Thank you for submitting this patch series to OpenEmbedded Core. This is
> > > an automated response. Several tests have been executed on the proposed
> > > series by patchtest resulting in the following failures:
> > > 
> > > 
> > > 
> > > * Issue Series does not apply on top of target branch 
> > > [test_series_merge_on_head] 
> > >   Suggested fixRebase your series on top of targeted branch
> > >   Targeted branch  master (currently at 65cfc8aca3)
> > 
> > I had been out of date, but this time I'm reasonably confident v3 is
> > still directly on top of master.
> > 
> > yocto-mainline> git config --local --get-regexp '^remote'
> > remote.yocto.url git://git.yoctoproject.org/poky
> > remote.yocto.projectname poky
> > remote.yocto.fetch +refs/heads/*:refs/remotes/yocto/*
> > yocto-mainline> git pull
> > Already up-to-date.
> > yocto-mainline> git status
> > On branch master
> > Your branch is ahead of 'yocto/master' by 1 commit.
> >   (use "git push" to publish your local commits)
> > 
> > nothing to commit, working directory clean
> > 
> > Is patchtest having a bad day?
> 
> yes,  there were some issues with the cron job running patchtest but
> that is now solved. The problem is that your patch is a documentation
> patch, not a oe-core patch, so it does not apply into oe-core. Send it
> to the correct list (yo...@yoctoproject.org) if necessary.

It's actually both a change to oe-core and the accompanying
documentation.  I wasn't aware that they needed to be sent to separate
lists when introducing a change to meta/ and documentation/ (to document
the change in meta/, obviously).  Seems like an odd thing to do, but
I'll break them up into separate commits, I guess.

-J.

> 
> 
> 
> 
> 
> > 
> > > If you believe any of these test results are incorrect, please reply to 
> > > the
> > > mailing list (openembedded-core@lists.openembedded.org) raising your 
> > > concerns.
> > > Otherwise we would appreciate you correcting the issues and submitting a 
> > > new
> > > version of the patchset if applicable. Please ensure you add/increment the
> > > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> > > [PATCH v3] -> ...).
> > > 
> > > ---
> > > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> > > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> > > 
> > 
> > -- 
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 

-- 
-Joe MacDonald.
:wq


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] LICENSE: Clarify what is meant by 'metadata'

[Burton, Ross]

On 27 February 2017 at 16:24, Saul Wold  wrote:

> The term metadata in the LICENSE text is unclear and recently
> garnered some questions at ELC, so clarify metadata to include
> bbclasses, which is and has been metadata as well as code.
>
> Signed-off-by: Saul Wold 
>

This breaks other layers (including meta-intel and meta-qt), do you have
corresponding patches?

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

Re: [OE-core] [PATCH 2/6] weston: Upgrade 1.11.1 -> 2.0.0, separate libweston

[Burton, Ross]

On 26 February 2017 at 16:50, Jussi Kukkonen 
wrote:
>
> * Drop two patches that are upstream. Rebase other patches.
> * Separate libweston into its own package, modify the recipe
>   as needed because files have changed location.
> * Remove "--disable-rpi-compositor": the backend does not exist
>   anymore.
>
> Libweston is already at version 2 and is likely to have new major
> versions. The versions should be parallel installable (but weston
> itself will not be).
>
> Signed-off-by: Jussi Kukkonen 


Breaks the no-x11 builds:

ERROR: Nothing RPROVIDES 'xserver-xorg-xwayland' (but
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-no-x11/build/meta/recipes-graphics/wayland/
weston_2.0.0.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'xserver-xorg-xwayland' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['xserver-xorg-xwayland']
NOTE: Runtime target 'weston-dev' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['weston-dev',
'xserver-xorg-xwayland']
NOTE: Runtime target 'weston' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['weston',
'xserver-xorg-xwayland']
ERROR: Nothing RPROVIDES 'weston-init' (but
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-no-x11/build/meta/recipes-graphics/images/
core-image-weston.bb,
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-no-x11/build/meta/recipes-graphics/wayland/
weston-init.bb RDEPENDS on or otherwise requires it)
ERROR: No eligible RPROVIDERs exist for 'weston-init'
NOTE: Runtime target 'weston-init' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['weston-init']
ERROR: Nothing RPROVIDES 'weston-examples' (but
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-no-x11/build/meta/recipes-graphics/images/
core-image-weston.bb RDEPENDS on or otherwise requires it)
ERROR: No eligible RPROVIDERs exist for 'weston-examples'
NOTE: Runtime target 'weston-examples' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['weston-examples']
ERROR: Nothing RPROVIDES 'core-image-weston'
ERROR: No eligible RPROVIDERs exist for 'core-image-weston'
NOTE: Runtime target 'core-image-weston' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['core-image-weston']
ERROR: Nothing RPROVIDES 'weston-init-dev' (but
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-no-x11/build/meta/recipes-graphics/wayland/
weston-init.bb RDEPENDS on or otherwise requires it)
ERROR: No eligible RPROVIDERs exist for 'weston-init-dev'
NOTE: Runtime target 'weston-init-dev' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['weston-init-dev']

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

Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)

[Leonardo Sandoval]

On Mon, 2017-02-27 at 15:06 -0500, Joe MacDonald wrote:
> [✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for 
> recipes (rev3)] On 17.02.27 (Mon 18:33) Patchwork wrote:
> 
> > == Series Details ==
> > 
> > Series: deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
> > Revision: 3
> > URL   : https://patchwork.openembedded.org/series/5489/
> > State : failure
> > 
> > == Summary ==
> > 
> > 
> > Thank you for submitting this patch series to OpenEmbedded Core. This is
> > an automated response. Several tests have been executed on the proposed
> > series by patchtest resulting in the following failures:
> > 
> > 
> > 
> > * Issue Series does not apply on top of target branch 
> > [test_series_merge_on_head] 
> >   Suggested fixRebase your series on top of targeted branch
> >   Targeted branch  master (currently at 65cfc8aca3)
> 
> I had been out of date, but this time I'm reasonably confident v3 is
> still directly on top of master.
> 
> yocto-mainline> git config --local --get-regexp '^remote'
> remote.yocto.url git://git.yoctoproject.org/poky
> remote.yocto.projectname poky
> remote.yocto.fetch +refs/heads/*:refs/remotes/yocto/*
> yocto-mainline> git pull
> Already up-to-date.
> yocto-mainline> git status
> On branch master
> Your branch is ahead of 'yocto/master' by 1 commit.
>   (use "git push" to publish your local commits)
> 
> nothing to commit, working directory clean
> 
> Is patchtest having a bad day?

yes,  there were some issues with the cron job running patchtest but
that is now solved. The problem is that your patch is a documentation
patch, not a oe-core patch, so it does not apply into oe-core. Send it
to the correct list (yo...@yoctoproject.org) if necessary.





> 
> > If you believe any of these test results are incorrect, please reply to the
> > mailing list (openembedded-core@lists.openembedded.org) raising your 
> > concerns.
> > Otherwise we would appreciate you correcting the issues and submitting a new
> > version of the patchset if applicable. Please ensure you add/increment the
> > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> > [PATCH v3] -> ...).
> > 
> > ---
> > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> > 
> 
> -- 
> ___
> 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

[OE-core] [PATCH V2] go: Add recipes for golang compilers and tools

[Khem Raj]

* This is converging the recipes for go from
  meta-virtualization and oe-meta-go

* Add recipes for go 1.7

* go.bbclass is added to ease out writing
  recipes for go packages

* go-examples: Add an example, helloworld written in go
  This should serve as temlate for writing go recipes

Signed-off-by: Khem Raj 
---
 meta/classes/go.bbclass|  72 +++
 meta/classes/goarch.bbclass|  46 +
 meta/recipes-devtools/go/go-1.4.inc|  15 ++
 .../go/go-1.4/016-armhf-elf-header.patch   |  24 +++
 ...ckport-cmd-link-support-new-386-amd64-rel.patch | 225 +
 meta/recipes-devtools/go/go-1.4/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.6.inc|  19 ++
 .../go/go-1.6/armhf-elf-header.patch   |  23 +++
 .../go/go-1.6/fix-cc-handling.patch|  50 +
 .../go/go-1.6/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.6/gotooldir.patch|  30 +++
 .../go/go-1.6/split-host-and-target-build.patch|  63 ++
 meta/recipes-devtools/go/go-1.6/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-1.7.inc|  19 ++
 .../go/go-1.7/armhf-elf-header.patch   |  23 +++
 .../go/go-1.7/fix-cc-handling.patch|  50 +
 .../go/go-1.7/fix-target-cc-for-build.patch|  17 ++
 meta/recipes-devtools/go/go-1.7/gotooldir.patch|  30 +++
 .../go/go-1.7/split-host-and-target-build.patch|  62 ++
 meta/recipes-devtools/go/go-1.7/syslog.patch   |  62 ++
 meta/recipes-devtools/go/go-common.inc |  22 ++
 meta/recipes-devtools/go/go-cross.inc  |  10 +
 meta/recipes-devtools/go/go-cross_1.7.bb   |   5 +
 meta/recipes-devtools/go/go-native.inc |  54 +
 meta/recipes-devtools/go/go-native_1.4.bb  |   2 +
 meta/recipes-devtools/go/go.inc|  76 +++
 meta/recipes-devtools/go/go_1.6.bb |   4 +
 meta/recipes-devtools/go/go_1.7.bb |   2 +
 .../go-examples/files/helloworld.go|  10 +
 meta/recipes-extended/go-examples/go-examples.inc  |  10 +
 .../go-examples/go-helloworld_0.1.bb   |  15 ++
 31 files changed, 1181 insertions(+)
 create mode 100644 meta/classes/go.bbclass
 create mode 100644 meta/classes/goarch.bbclass
 create mode 100644 meta/recipes-devtools/go/go-1.4.inc
 create mode 100644 meta/recipes-devtools/go/go-1.4/016-armhf-elf-header.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.4/go-cross-backport-cmd-link-support-new-386-amd64-rel.patch
 create mode 100644 meta/recipes-devtools/go/go-1.4/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6.inc
 create mode 100644 meta/recipes-devtools/go/go-1.6/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.6/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.6/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7.inc
 create mode 100644 meta/recipes-devtools/go/go-1.7/armhf-elf-header.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/fix-cc-handling.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/fix-target-cc-for-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/gotooldir.patch
 create mode 100644 
meta/recipes-devtools/go/go-1.7/split-host-and-target-build.patch
 create mode 100644 meta/recipes-devtools/go/go-1.7/syslog.patch
 create mode 100644 meta/recipes-devtools/go/go-common.inc
 create mode 100644 meta/recipes-devtools/go/go-cross.inc
 create mode 100644 meta/recipes-devtools/go/go-cross_1.7.bb
 create mode 100644 meta/recipes-devtools/go/go-native.inc
 create mode 100644 meta/recipes-devtools/go/go-native_1.4.bb
 create mode 100644 meta/recipes-devtools/go/go.inc
 create mode 100644 meta/recipes-devtools/go/go_1.6.bb
 create mode 100644 meta/recipes-devtools/go/go_1.7.bb
 create mode 100644 meta/recipes-extended/go-examples/files/helloworld.go
 create mode 100644 meta/recipes-extended/go-examples/go-examples.inc
 create mode 100644 meta/recipes-extended/go-examples/go-helloworld_0.1.bb

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
new file mode 100644
index 00..e6ea996e9d
--- /dev/null
+++ b/meta/classes/go.bbclass
@@ -0,0 +1,72 @@
+inherit goarch
+
+GOROOT_class-native = "${STAGING_LIBDIR_NATIVE}/go"
+GOROOT = "${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
+GOBIN_FINAL_class-native = "${GOROOT_FINAL}/bin"
+GOBIN_FINAL = "${GOROOT_FINAL}/bin/${GOOS}_${GOARCH}"
+
+export GOOS = "${TARGET_GOOS}"
+export GOARCH = "${TARGET_GOARCH}"
+export GOARM = "${TARGET_GOARM}"
+export CGO_ENABLED = "1"
+export GOROOT
+export GOROOT_FINAL = 

Re: [OE-core] ✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)

[Joe MacDonald]

[✗ patchtest: failure for deprecated.bbclass: Add a PNDEPRECATED variable for 
recipes (rev3)] On 17.02.27 (Mon 18:33) Patchwork wrote:

> == Series Details ==
> 
> Series: deprecated.bbclass: Add a PNDEPRECATED variable for recipes (rev3)
> Revision: 3
> URL   : https://patchwork.openembedded.org/series/5489/
> State : failure
> 
> == Summary ==
> 
> 
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
> 
> 
> 
> * Issue Series does not apply on top of target branch 
> [test_series_merge_on_head] 
>   Suggested fixRebase your series on top of targeted branch
>   Targeted branch  master (currently at 65cfc8aca3)

I had been out of date, but this time I'm reasonably confident v3 is
still directly on top of master.

yocto-mainline> git config --local --get-regexp '^remote'
remote.yocto.url git://git.yoctoproject.org/poky
remote.yocto.projectname poky
remote.yocto.fetch +refs/heads/*:refs/remotes/yocto/*
yocto-mainline> git pull
Already up-to-date.
yocto-mainline> git status
On branch master
Your branch is ahead of 'yocto/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working directory clean

Is patchtest having a bad day?

> If you believe any of these test results are incorrect, please reply to the
> mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
> Otherwise we would appreciate you correcting the issues and submitting a new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
> 
> ---
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> 

-- 
-Joe MacDonald.
:wq


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] a few more picky questions about COMPATIBLE_MACHINE usage

[Andre McCurdy]

On Mon, Feb 27, 2017 at 10:53 AM, Robert P. J. Day
 wrote:
> On Mon, 27 Feb 2017, Phil Blundell wrote:
>
>> On Mon, 2017-02-27 at 09:09 -0500, Robert P. J. Day wrote:
>> >  # webkit-efl isn't available for < armv7a
>> >  COMPATIBLE_MACHINE = "(-)"
>> >   COMPATIBLE_MACHINE_x86 = "(.*)"
>> >   COMPATIBLE_MACHINE_x86-64 = "(.*)"
>> >   COMPATIBLE_MACHINE_armv7a = "(.*)"
>> >
>> >   first, that comment seems out of date as it makes no mention of
>> > MIPS
>> > or ppc, but that's just being picky.
>> >
>> >   next, i assume the line:
>> >
>> >   COMPATIBLE_MACHINE = "(-)"
>> >
>> > is to initialize the set of compatible machines to the empty set,
>> > yes?
>>
>> I think the intent is to set it to a string that "can't possibly
>> ever match".
>
>   right, that's what i suspected.
>
>> >
>>   i next assume that lines of the form:
>> >
>> >   COMPATIBLE_MACHINE_x86 = "(.*)"
>> >
>> > are meant to indicate that if that MACHINE_OVERRIDES comparison
>> > succeeds, then all possible targets are compatible, is that right?
>> > however, given precisely those lines above, is it not equivalent to
>> > just write:
>> >
>> >   COMPATIBLE_MACHINE = "(x86|x86-64|armv7a)"
>>
>> No, because "armv7a" is not a MACHINE.  It would be more equivalent
>> to write
>>
>> COMPATIBLE_HOST = "armv7a-.*"
>>
>> but even this would not be quite the same because it would fail to
>> match "cortexa15-linux" for example.  Actually that's not a very
>> good example because cortexa15 is armv7ve not armv7a, but you get
>> the idea.
>
>   i'm going to disagree here, i never suggested "armv7a" was a
> "machine" (in the sense of having a defining armv7a.conf file). i said
> it was part of MACHINE_OVERRIDES, and therefore *would* be considered
> a matching "machine" for the purposes of COMPATIBLE_MACHINE.
>
>   as another example, there is no such machine as a "qoriq", but that
> is considered a valid choice for COMPATIBLE_MACHINE since several
> actual machine definition files do this:
>
>   MACHINEOVERRIDES =. "qoriq:"
>
> am i making sense?

I think so. However, note that ARM is somewhat of a special case in
that it includes over-rides derived from TUNE_FEATURES in
MACHINEOVERRIDES (although MIPS has recently started to do so too). In
the general case (and especially in the context of COMPATIBLE_MACHINE)
it's probably better to think of MACHINEOVERRIDES as containing just
the machine name and perhaps a SOC family.

(Maybe it would be clearer if over-rides derived from TUNE_FEATURES
were placed in a dedicated variable, e.g. TUNINGOVERRIDES, rather than
being crammed into MACHINEOVERRIDES?).

> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
> --
> ___
> 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

[OE-core] [PATCH v3] zlib: Upgrade 1.2.8 -> 1.2.11

[Peter Marko]

Licence updated by removing its first line which was containing
copyright notice including year, which could change quite often.
Additional empty line was deleted, too.

Signed-off-by: Peter Marko 
Signed-off-by: Andrej Valek 
Signed-off-by: Pascal Bach 
---
 1.2.11  | 0
 .../zlib/{zlib-1.2.8 => zlib-1.2.11}/Makefile-runtests.patch| 0
 .../zlib/{zlib-1.2.8 => zlib-1.2.11}/ldflags-tests.patch| 0
 .../zlib/{zlib-1.2.8 => zlib-1.2.11}/remove.ldconfig.call.patch | 0
 meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/run-ptest| 0
 meta/recipes-core/zlib/{zlib_1.2.8.bb => zlib_1.2.11.bb}| 6 +++---
 6 files changed, 3 insertions(+), 3 deletions(-)
 create mode 100644 1.2.11
 rename meta/recipes-core/zlib/{zlib-1.2.8 => 
zlib-1.2.11}/Makefile-runtests.patch (100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/ldflags-tests.patch 
(100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => 
zlib-1.2.11}/remove.ldconfig.call.patch (100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/run-ptest (100%)
 rename meta/recipes-core/zlib/{zlib_1.2.8.bb => zlib_1.2.11.bb} (86%)

diff --git a/1.2.11 b/1.2.11
new file mode 100644
index 000..e69de29
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/Makefile-runtests.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/Makefile-runtests.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/Makefile-runtests.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/Makefile-runtests.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/ldflags-tests.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/ldflags-tests.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/remove.ldconfig.call.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/remove.ldconfig.call.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/run-ptest 
b/meta/recipes-core/zlib/zlib-1.2.11/run-ptest
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/run-ptest
rename to meta/recipes-core/zlib/zlib-1.2.11/run-ptest
diff --git a/meta/recipes-core/zlib/zlib_1.2.8.bb 
b/meta/recipes-core/zlib/zlib_1.2.11.bb
similarity index 86%
rename from meta/recipes-core/zlib/zlib_1.2.8.bb
rename to meta/recipes-core/zlib/zlib_1.2.11.bb
index 913c703..2018e7b 100644
--- a/meta/recipes-core/zlib/zlib_1.2.8.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.11.bb
@@ -4,7 +4,7 @@ library which is used by many different programs."
 HOMEPAGE = "http://zlib.net/;
 SECTION = "libs"
 LICENSE = "Zlib"
-LIC_FILES_CHKSUM = 
"file://zlib.h;beginline=4;endline=23;md5=fde612df1e5933c428b73844a0c494fd"
+LIC_FILES_CHKSUM = 
"file://zlib.h;beginline=6;endline=23;md5=5377232268e952e9ef63bc555f7aa6c0"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/${BPN}/${PV}/${BPN}-${PV}.tar.xz \
file://remove.ldconfig.call.patch \
@@ -13,8 +13,8 @@ SRC_URI = 
"${SOURCEFORGE_MIRROR}/libpng/${BPN}/${PV}/${BPN}-${PV}.tar.xz \
file://run-ptest \
"
 
-SRC_URI[md5sum] = "28f1205d8dd2001f26fec1e8c2cebe37"
-SRC_URI[sha256sum] = 
"831df043236df8e9a7667b9e3bb37e1fcb1220a0f163b6de2626774b9590d057"
+SRC_URI[md5sum] = "85adef240c5f370b308da8c938951a68"
+SRC_URI[sha256sum] = 
"4ff941449631ace0d4d203e3483be9dbc9da454084111f97ea0a2114e19bf066"
 
 RDEPENDS_${PN}-ptest += "make"
 
-- 
2.1.4

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

Re: [OE-core] a few more picky questions about COMPATIBLE_MACHINE usage

[Robert P. J. Day]

On Mon, 27 Feb 2017, Phil Blundell wrote:

> On Mon, 2017-02-27 at 09:09 -0500, Robert P. J. Day wrote:
> >  # webkit-efl isn't available for < armv7a
> >  COMPATIBLE_MACHINE = "(-)"
> >   COMPATIBLE_MACHINE_x86 = "(.*)"
> >   COMPATIBLE_MACHINE_x86-64 = "(.*)"
> >   COMPATIBLE_MACHINE_armv7a = "(.*)"
> >
> >   first, that comment seems out of date as it makes no mention of
> > MIPS
> > or ppc, but that's just being picky.
> >
> >   next, i assume the line:
> >
> >   COMPATIBLE_MACHINE = "(-)"
> >
> > is to initialize the set of compatible machines to the empty set,
> > yes?
>
> I think the intent is to set it to a string that "can't possibly
> ever match".

  right, that's what i suspected.

> >
>   i next assume that lines of the form:
> >
> >   COMPATIBLE_MACHINE_x86 = "(.*)"
> >
> > are meant to indicate that if that MACHINE_OVERRIDES comparison
> > succeeds, then all possible targets are compatible, is that right?
> > however, given precisely those lines above, is it not equivalent to
> > just write:
> >
> >   COMPATIBLE_MACHINE = "(x86|x86-64|armv7a)"
>
> No, because "armv7a" is not a MACHINE.  It would be more equivalent
> to write
>
> COMPATIBLE_HOST = "armv7a-.*"
>
> but even this would not be quite the same because it would fail to
> match "cortexa15-linux" for example.  Actually that's not a very
> good example because cortexa15 is armv7ve not armv7a, but you get
> the idea.

  i'm going to disagree here, i never suggested "armv7a" was a
"machine" (in the sense of having a defining armv7a.conf file). i said
it was part of MACHINE_OVERRIDES, and therefore *would* be considered
a matching "machine" for the purposes of COMPATIBLE_MACHINE.

  as another example, there is no such machine as a "qoriq", but that
is considered a valid choice for COMPATIBLE_MACHINE since several
actual machine definition files do this:

  MACHINEOVERRIDES =. "qoriq:"

am i making sense?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] zlib: Upgrade 1.2.8 -> 1.2.11

[Burton, Ross]

On 27 February 2017 at 17:18, Peter Marko  wrote:

> -LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=
> fde612df1e5933c428b73844a0c494fd"
> +LIC_FILES_CHKSUM = "file://zlib.h;beginline=6;endline=23;md5=
> 5377232268e952e9ef63bc555f7aa6c0"
>

To demonstrate that you haven't just updated the checksum without checking
the license changes, can you sent a v3 with an explanation of this change
in the commit log?  Something along the lines of "copyright dates changed"
is fine, we just need to know that the change isn't "relicensed under
GPLv3". :)

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

Re: [OE-core] a few more picky questions about COMPATIBLE_MACHINE usage

[Phil Blundell]

On Mon, 2017-02-27 at 09:09 -0500, Robert P. J. Day wrote:
>  # webkit-efl isn't available for < armv7a
>  COMPATIBLE_MACHINE = "(-)"
>   COMPATIBLE_MACHINE_x86 = "(.*)"
>   COMPATIBLE_MACHINE_x86-64 = "(.*)"
>   COMPATIBLE_MACHINE_armv7a = "(.*)"
> 
>   first, that comment seems out of date as it makes no mention of
> MIPS
> or ppc, but that's just being picky.
> 
>   next, i assume the line:
> 
>   COMPATIBLE_MACHINE = "(-)"
> 
> is to initialize the set of compatible machines to the empty set,
> yes?

I think the intent is to set it to a string that "can't possibly ever
match". 

> 
  i next assume that lines of the form:
> 
>   COMPATIBLE_MACHINE_x86 = "(.*)"
> 
> are meant to indicate that if that MACHINE_OVERRIDES comparison
> succeeds, then all possible targets are compatible, is that right?
> however, given precisely those lines above, is it not equivalent to
> just write:
> 
>   COMPATIBLE_MACHINE = "(x86|x86-64|armv7a)"

No, because "armv7a" is not a MACHINE.  It would be more equivalent to
write

COMPATIBLE_HOST = "armv7a-.*"

but even this would not be quite the same because it would fail to
match "cortexa15-linux" for example.  Actually that's not a very good
example because cortexa15 is armv7ve not armv7a, but you get the idea.

> oddly, there is another recipe that seems to do the same thing, but
> in
> a very different way, meta-oe/recipes-support/ne10/ne10_1.2.1.bb:
> 
>   COMPATIBLE_MACHINE_aarch64 = "(.*)"
>   COMPATIBLE_MACHINE_armv7a = "(.*)"
> 
>   python () {
> if any(t.startswith('armv7') for t in
> d.getVar('TUNE_FEATURES').split()):
> d.setVar('NE10_TARGET_ARCH', 'armv7')
> bb.debug(2, 'Building Ne10 for armv7')
> elif any(t.startswith('aarch64') for t in
> d.getVar('TUNE_FEATURES').split()):
> d.setVar('NE10_TARGET_ARCH', 'aarch64')
> bb.debug(2, 'Building Ne10 for aarch64')
> else:
> raise bb.parse.SkipPackage("Incompatible with archs other
> than armv7 and aarch64")
>   }

The COMPATIBLE_MACHINE declarations there do seem completely useless
and redundant.  I can only assume that the author of this recipe tried
to use COMPATIBLE_MACHINE to get what they wanted, found they couldn't
(which is true, the COMPATIBLE_MACHINE semantics are full of suck, and
even COMPATIBLE_HOST has a fairly high suckage quotient) and resorted
to writing python to express their requirements.

> now, i can see that that anonymous python routine refines the
> machine compatibility even further but, to speed things up, why not
> first start with just:
> 
>   COMPATIBLE_MACHINE = "(aarch64|armv7a)"
> 
> or (once again), am i misunderstanding something?

No, that will lose unless your MACHINE happens to be literally named
"aarch64", which it probably isn't.  But in any case there is no magic
associated with COMPATIBLE_MACHINE, it is just processed by a piece of
anonymous python which is not entirely dissimilar to that bit you
quoted above.

p.

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

[OE-core] [PATCH] zlib: Upgrade 1.2.8 -> 1.2.11

[Peter Marko]

Signed-off-by: Peter Marko 
Signed-off-by: Andrej Valek 
Signed-off-by: Pascal Bach 
---
 1.2.11  | 0
 .../zlib/{zlib-1.2.8 => zlib-1.2.11}/Makefile-runtests.patch| 0
 .../zlib/{zlib-1.2.8 => zlib-1.2.11}/ldflags-tests.patch| 0
 .../zlib/{zlib-1.2.8 => zlib-1.2.11}/remove.ldconfig.call.patch | 0
 meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/run-ptest| 0
 meta/recipes-core/zlib/{zlib_1.2.8.bb => zlib_1.2.11.bb}| 6 +++---
 6 files changed, 3 insertions(+), 3 deletions(-)
 create mode 100644 1.2.11
 rename meta/recipes-core/zlib/{zlib-1.2.8 => 
zlib-1.2.11}/Makefile-runtests.patch (100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/ldflags-tests.patch 
(100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => 
zlib-1.2.11}/remove.ldconfig.call.patch (100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/run-ptest (100%)
 rename meta/recipes-core/zlib/{zlib_1.2.8.bb => zlib_1.2.11.bb} (86%)

diff --git a/1.2.11 b/1.2.11
new file mode 100644
index 000..e69de29
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/Makefile-runtests.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/Makefile-runtests.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/Makefile-runtests.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/Makefile-runtests.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/ldflags-tests.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/ldflags-tests.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/remove.ldconfig.call.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/remove.ldconfig.call.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/run-ptest 
b/meta/recipes-core/zlib/zlib-1.2.11/run-ptest
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/run-ptest
rename to meta/recipes-core/zlib/zlib-1.2.11/run-ptest
diff --git a/meta/recipes-core/zlib/zlib_1.2.8.bb 
b/meta/recipes-core/zlib/zlib_1.2.11.bb
similarity index 86%
rename from meta/recipes-core/zlib/zlib_1.2.8.bb
rename to meta/recipes-core/zlib/zlib_1.2.11.bb
index 913c703..2018e7b 100644
--- a/meta/recipes-core/zlib/zlib_1.2.8.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.11.bb
@@ -4,7 +4,7 @@ library which is used by many different programs."
 HOMEPAGE = "http://zlib.net/;
 SECTION = "libs"
 LICENSE = "Zlib"
-LIC_FILES_CHKSUM = 
"file://zlib.h;beginline=4;endline=23;md5=fde612df1e5933c428b73844a0c494fd"
+LIC_FILES_CHKSUM = 
"file://zlib.h;beginline=6;endline=23;md5=5377232268e952e9ef63bc555f7aa6c0"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/${BPN}/${PV}/${BPN}-${PV}.tar.xz \
file://remove.ldconfig.call.patch \
@@ -13,8 +13,8 @@ SRC_URI = 
"${SOURCEFORGE_MIRROR}/libpng/${BPN}/${PV}/${BPN}-${PV}.tar.xz \
file://run-ptest \
"
 
-SRC_URI[md5sum] = "28f1205d8dd2001f26fec1e8c2cebe37"
-SRC_URI[sha256sum] = 
"831df043236df8e9a7667b9e3bb37e1fcb1220a0f163b6de2626774b9590d057"
+SRC_URI[md5sum] = "85adef240c5f370b308da8c938951a68"
+SRC_URI[sha256sum] = 
"4ff941449631ace0d4d203e3483be9dbc9da454084111f97ea0a2114e19bf066"
 
 RDEPENDS_${PN}-ptest += "make"
 
-- 
2.1.4

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

[OE-core] Yocto Project Status WW09’17

[Jolley, Stephen K]

Current Dev Position: YP 2.3 M3

Next Deadline: YP 2.3 M3 by Feb. 27, 2017


*** FEATURE FREEZE for 2.3 is now in effect. ***


SWAT team rotation: Anibal -> Todor on Feb. 24, 2017.

SWAT team rotation: Todor -> Tracy on Mar. 4, 2017.

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


Key Status/Updates:

·We’re now into feature freeze for 2.3.

·We need to decide which recently submitted items should be merged. 
Some major items In particular:

o   rpm v4/dnf to replace rpm v5/smart?

o   Merging go into OE-Core?

o   Separate out elderly GPLv2 into a separate layer?

o   Graphics stack vulkan changes?

o   Large queue of wic changes?

I am leaning towards trying to take these even if they do delay the M3 release 
slightly as we do have some time left in M4 to stabilize.

·Unfortunately we continue to have stability issues in testing. There 
appear to be some intermittent failures which have crept into master and M3 
merging will likely be delayed until those issues have been tracked down. They 
seem to affect sdk image size, breaking the 4GB limit and eSDKs stopping 
containing libxml2 under unknown circumstances, possibly amongst other issues.

·YP 2.2.1 has been released


Proposed upcoming dot releases:

YP 2.1.3 Cut off May 15, 2017

YP 2.1.3 Release by May 26, 2017

YP 2.2.2 Cut off May 29, 2017

YP 2.2.2 Release by June 9, 2017


Key YP 2.3 Dates:

YP 2.3 M3 Cutoff is Feb 27, 2017

YP 2.3 M3 Release is Mar. 10, 2017

YP 2.3 M4 Cutoff is April 10, 2017

YP 2.3 M4 Release is May 5, 2017


Tracking Metrics:

WDD 2747 (last week 2682)

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


Key Status Links for YP:

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

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

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

[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 v2 1/1] oelib/buildhistory.py: Add unittest for buildhistory_analysis

[Humberto Ibarra]

The buildhistory_analysis module (in which buildhistory-diff is
based) was lacking unittest for its functions. Created selftest
module for this and a few testcases to cover basic cases.

[YOCTO #10727]

Signed-off-by: Humberto Ibarra 
---
 meta/lib/oeqa/selftest/oelib/buildhistory.py | 88 
 1 file changed, 88 insertions(+)
 create mode 100644 meta/lib/oeqa/selftest/oelib/buildhistory.py

diff --git a/meta/lib/oeqa/selftest/oelib/buildhistory.py 
b/meta/lib/oeqa/selftest/oelib/buildhistory.py
new file mode 100644
index 000..5ed4b02
--- /dev/null
+++ b/meta/lib/oeqa/selftest/oelib/buildhistory.py
@@ -0,0 +1,88 @@
+import os
+import unittest
+import tempfile
+from git import Repo
+from oeqa.utils.commands import get_bb_var
+from oe.buildhistory_analysis import blob_to_dict, compare_dict_blobs
+
+class TestBlobParsing(unittest.TestCase):
+
+def setUp(self):
+import time
+self.repo_path = tempfile.mkdtemp(prefix='selftest-buildhistory',
+dir=get_bb_var('TOPDIR'))
+
+self.repo = Repo.init(self.repo_path)
+self.test_file = "test"
+self.var_map = {}
+
+def tearDown(self):
+import shutil
+shutil.rmtree(self.repo_path)
+
+def commit_vars(self, to_add={}, to_remove = [], msg="A commit message"):
+if len(to_add) == 0 and len(to_remove) == 0:
+return
+
+for k in to_remove:
+self.var_map.pop(x,None)
+for k in to_add:
+self.var_map[k] = to_add[k]
+
+with open(os.path.join(self.repo_path, self.test_file), 'w') as 
repo_file:
+for k in self.var_map:
+repo_file.write("%s = %s\n" % (k, self.var_map[k]))
+
+self.repo.git.add("--all")
+self.repo.git.commit(message=msg)
+
+def test_blob_to_dict(self):
+"""
+Test convertion of git blobs to dictionary
+"""
+valuesmap = { "foo" : "1", "bar" : "2" }
+self.commit_vars(to_add = valuesmap)
+
+blob = self.repo.head.commit.tree.blobs[0]
+self.assertEqual(valuesmap, blob_to_dict(blob),
+"commit was not translated correctly to dictionary")
+
+def test_compare_dict_blobs(self):
+"""
+Test comparisson of dictionaries extracted from git blobs
+"""
+changesmap = { "foo-2" : ("2", "8"), "bar" : ("","4"), "bar-2" : 
("","5")}
+
+self.commit_vars(to_add = { "foo" : "1", "foo-2" : "2", "foo-3" : "3" 
})
+blob1 = self.repo.heads.master.commit.tree.blobs[0]
+
+self.commit_vars(to_add = { "foo-2" : "8", "bar" : "4", "bar-2" : "5" 
})
+blob2 = self.repo.heads.master.commit.tree.blobs[0]
+
+change_records = compare_dict_blobs(os.path.join(self.repo_path, 
self.test_file),
+blob1, blob2, False, False)
+
+var_changes = { x.fieldname : (x.oldvalue, x.newvalue) for x in 
change_records}
+self.assertEqual(changesmap, var_changes, "Changes not reported 
correctly")
+
+def test_compare_dict_blobs_default(self):
+"""
+Test default values for comparisson of git blob dictionaries
+"""
+defaultmap = { x : ("default", "1")  for x in ["PKG", "PKGE", "PKGV", 
"PKGR"]}
+
+self.commit_vars(to_add = { "foo" : "1" })
+blob1 = self.repo.heads.master.commit.tree.blobs[0]
+
+self.commit_vars(to_add = { "PKG" : "1", "PKGE" : "1", "PKGV" : "1", 
"PKGR" : "1" })
+blob2 = self.repo.heads.master.commit.tree.blobs[0]
+
+change_records = compare_dict_blobs(os.path.join(self.repo_path, 
self.test_file),
+blob1, blob2, False, False)
+
+var_changes = {}
+for x in change_records:
+oldvalue = "default" if ("default" in x.oldvalue) else x.oldvalue
+var_changes[x.fieldname] = (oldvalue, x.newvalue)
+
+self.assertEqual(defaultmap, var_changes, "Defaults not set properly")
-- 
2.7.4

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

[OE-core] [PATCH] LICENSE: Clarify what is meant by 'metadata'

[Saul Wold]

The term metadata in the LICENSE text is unclear and recently
garnered some questions at ELC, so clarify metadata to include
bbclasses, which is and has been metadata as well as code.

Signed-off-by: Saul Wold 
---
 LICENSE | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/LICENSE b/LICENSE
index 21fa6e6..9783ee5 100644
--- a/LICENSE
+++ b/LICENSE
@@ -6,9 +6,11 @@ meta/COPYING.MIT (MIT)
 meta-selftest/COPYING.MIT (MIT)
 meta-skeleton/COPYING.MIT (MIT)
 
-All metadata is MIT licensed unless otherwise stated. Source code
-included in tree for individual recipes is under the LICENSE stated in
-the associated recipe (.bb file) unless otherwise stated.
+All metadata files (including, but not limited to bb, bbappend,
+bbclass, inc and conf files) are MIT licensed unless otherwise stated.
+Source code included in tree for individual recipes is under the
+LICENSE stated in the associated recipe (.bb file) unless otherwise
+stated.
 
 License information for any other files is either explicitly stated 
 or defaults to GPL version 2.
-- 
2.7.4

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

[OE-core] [PATCHv2 0/2] OEQA loader improvment

[mariano . lopez]

From: Mariano Lopez 

The first adds more verbosity when a class doesn't inherit
from the expected test class.

The second patch raises an error when trying to import a test
with the same module name as a built-in module.

Change in v2:

- Rebased to current master

The following changes since commit 3c83b56309ab419f8cda72c0711479f60f61439a:

  bitbake: fetch2/svn: change 'rsh' parameter to 'ssh' (2017-02-23 12:50:17 
-0800)

are available in the git repository at:

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

Mariano Lopez (2):
  oeqa/core/loader.py: Give meaningful error when failed to load classes
  oeqa/core/loader.py: Avoid importing tests with built-ins name

 meta/lib/oeqa/core/loader.py | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

-- 
2.6.6

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

[OE-core] [PATCHv2 2/2] oeqa/core/loader.py: Avoid importing tests with built-ins name

[mariano . lopez]

From: Mariano Lopez 

If importing a test with the same name as a built-in module,
it will silently import the built-in and check for tests in
built-in module. This happened with syslog module in debian
based machines, so add a raise to avoid this behavior.

[YOCTO #10978]

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/core/loader.py | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/meta/lib/oeqa/core/loader.py b/meta/lib/oeqa/core/loader.py
index b9ba923..74f1117 100644
--- a/meta/lib/oeqa/core/loader.py
+++ b/meta/lib/oeqa/core/loader.py
@@ -216,6 +216,13 @@ class OETestLoader(unittest.TestLoader):
 # use_load_tests deprecation via *args and **kws.  See issue 16662.
 if sys.version_info >= (3,5):
 def loadTestsFromModule(self, module, *args, pattern=None, **kws):
+"""
+Returns a suite of all tests cases contained in module.
+"""
+if module.__name__ in sys.builtin_module_names:
+msg = 'Tried to import %s test module but is a built-in'
+raise ImportError(msg % module.__name__)
+
 if not self.modules or "all" in self.modules or \
 module.__name__ in self.modules:
 return super(OETestLoader, self).loadTestsFromModule(
@@ -227,6 +234,10 @@ class OETestLoader(unittest.TestLoader):
 """
 Returns a suite of all tests cases contained in module.
 """
+if module.__name__ in sys.builtin_module_names:
+msg = 'Tried to import %s test module but is a built-in'
+raise ImportError(msg % module.__name__)
+
 if not self.modules or "all" in self.modules or \
 module.__name__ in self.modules:
 return super(OETestLoader, self).loadTestsFromModule(
-- 
2.6.6

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

[OE-core] [PATCHv2 1/2] oeqa/core/loader.py: Give meaningful error when failed to load classes

[mariano . lopez]

From: Mariano Lopez 

With this we get the class that is actually having the problem,
not just a TypeError with an unknown class causing the error.

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/core/loader.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oeqa/core/loader.py b/meta/lib/oeqa/core/loader.py
index a380325..b9ba923 100644
--- a/meta/lib/oeqa/core/loader.py
+++ b/meta/lib/oeqa/core/loader.py
@@ -171,11 +171,11 @@ class OETestLoader(unittest.TestLoader):
 """
 if issubclass(testCaseClass, unittest.suite.TestSuite):
 raise TypeError("Test cases should not be derived from TestSuite." 
\
-" Maybe you meant to derive from TestCase?")
+" Maybe you meant to derive %s from TestCase?" 
\
+% testCaseClass.__name__)
 if not issubclass(testCaseClass, self.caseClass):
-raise TypeError("Test cases need to be derived from %s" % \
-self.caseClass.__name__)
-
+raise TypeError("Test %s is not derived from %s" % \
+(testCaseClass.__name__, self.caseClass.__name__))
 
 testCaseNames = self.getTestCaseNames(testCaseClass)
 if not testCaseNames and hasattr(testCaseClass, 'runTest'):
-- 
2.6.6

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

Re: [OE-core] [PATCH] lz4: upgrade to v1.7.5

[Burton, Ross]

On 27 February 2017 at 15:05, Andreas Horsthemke 
wrote:

> -LICENSE = "BSD"
> -LIC_FILES_CHKSUM = "file://lib/LICENSE;md5=0b0d063f37a4477b54af2459477dca
> fd"
> +# The source includes GPLv2 and BSD licensed files.
> +# The library in the `lib` directory is under BSD 2-Clause license.
> +# The CLI tools are GPLv2 licensed.
> +LICENSE = "GPLv2 & BSD"
> +LIC_FILES_CHKSUM = "file://lib/LICENSE;md5=ebc2ea4814a64de7708f1571904b32cc
> \
> +file://programs/COPYING;md5=
> b234ee4d69f5fce4486a80fdaf4a4263"
>

If you split the package into a library and binaries then the respective
licenses can be on the right parts.


> -PV = "131+git${SRCPV}"
> +PV = "1.7.5+git${SRCPV}"
>

131 > 1.7.5, so you'll need to add PE="1" to ensure upgrades happen.

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

[OE-core] [PATCH] lz4: upgrade to v1.7.5

[Andreas Horsthemke]

upgrade from r131. The version numbering changed to a new style.
The licsense is BSD for the library and GPLv2 for the CLI tools.

Signed-off-by: Andreas Horsthemke 
---
 meta/recipes-support/lz4/lz4.bb | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-support/lz4/lz4.bb b/meta/recipes-support/lz4/lz4.bb
index 18e56d04c6..6c77aa1536 100644
--- a/meta/recipes-support/lz4/lz4.bb
+++ b/meta/recipes-support/lz4/lz4.bb
@@ -1,12 +1,16 @@
 SUMMARY = "Extremely Fast Compression algorithm"
 DESCRIPTION = "LZ4 is a very fast lossless compression algorithm, providing 
compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also 
features an extremely fast decoder, with speed in multiple GB/s per core, 
typically reaching RAM speed limits on multi-core systems."
 
-LICENSE = "BSD"
-LIC_FILES_CHKSUM = "file://lib/LICENSE;md5=0b0d063f37a4477b54af2459477dcafd"
+# The source includes GPLv2 and BSD licensed files.
+# The library in the `lib` directory is under BSD 2-Clause license.
+# The CLI tools are GPLv2 licensed.
+LICENSE = "GPLv2 & BSD"
+LIC_FILES_CHKSUM = "file://lib/LICENSE;md5=ebc2ea4814a64de7708f1571904b32cc \
+
file://programs/COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
-SRCREV = "d86dc916771c126afb797637dda9f6421c0cb998"
+SRCREV = "7bb64ff2b69a9f8367de9ab483cdadf42b4c1b65"
 
-PV = "131+git${SRCPV}"
+PV = "1.7.5+git${SRCPV}"
 
 SRC_URI = "git://github.com/Cyan4973/lz4.git"
 
-- 
2.11.0

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

[OE-core] what means COMPATIBLE_MACHINE_armv4 = "(!.*armv4).*" ???

[Robert P. J. Day]

  ok, last question about COMPATIBLE_MACHINE, i promise. i
notice in
meta-oe/recipes-support/mongodb/mongodb_git.bb the snippet:

  #std::current_exception is undefined for arm < v6
  COMPATIBLE_MACHINE_armv4 = "(!.*armv4).*"
  COMPATIBLE_MACHINE_armv5 = "(!.*armv5).*"
  COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
  COMPATIBLE_MACHINE_powerpc = "(!.*ppc).*"

consider just the first assignment:

  COMPATIBLE_MACHINE_armv4 = "(!.*armv4).*"

which i interpret as, "if the machine override 'armv4' is in play,
then the list of compatible machines are all those which do *not*
contain the string 'armv4'. isn't that just a way of saying, "no
variation of armv4 is compatible"?

  this just looks weird, what am i missing? oh, and given the
behaviour of re.match(), could not one write that same line
equivalently as:

  COMPATIBLE_MACHINE_armv4 = "(!.*armv4)"

  i suspect i'm just confused about what's happening here.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [OE-core] [PATCH 6/6] vkcube: Add recipe for minimal vulkan demo

[Jussi Kukkonen]

On 26 February 2017 at 20:15, Martin Jansa  wrote:
>
> > +PV = "0+git${SRCPV}"
>
> https://github.com/krh/vkcube/blob/master/configure.ac#L1
>
> says 0.1 since the very first commit, why not use that as base version
instead of just "0"?

I've fixed this in the branch on poky-contrib.

I also added a source file to vulkan LIC_FILES_CHECKSUM (since there were
none).

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

Re: [OE-core] [PATCH 1/1] oelib/buildhistory.py: Add unittest for buildhistory_analysis

[Burton, Ross]

On 24 February 2017 at 21:57, Humberto Ibarra <
humberto.ibarra.lo...@intel.com> wrote:

> +tmp_repo = "bhrepo_%s" % time.strftime("%Y%m%d%H%M%S")
> +self.repo_path = os.path.join(get_bb_var('TOPDIR'), tmp_repo)
> +os.mkdir(self.repo_path)
>

Instead of hoping for the best, can this just use
mktempd(prefix='selftest-buildhistory', dir=get_bb_bar(TOPDIR))

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

Re: [OE-core] [PATCH] zlib: Upgrade 1.2.8 -> 1.2.11

[Alexander Kanavin]

On 02/27/2017 04:41 PM, Burton, Ross wrote:

 beginline=4 v
  Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler



^ endline=23 ^
zlib: Check if the license information has changed in
/data/poky-master/tmp/work/corei7-64-poky-linux/zlib/1.2.11-r0/zlib-1.2.11/zlib.h
(lines 4 through to 23) to verify that the LICENSE value "Zlib" remains
valid [license-checksum]


It's probably just the year changing to 2017, in which case the 
beginline can be changed to 5.


Alex

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

Re: [OE-core] [PATCH] zlib: Upgrade 1.2.8 -> 1.2.11

[Burton, Ross]

On 27 February 2017 at 14:05, Peter Marko  wrote:

> Signed-off-by: Peter Marko 
> Signed-off-by: Andrej Valek 
> Signed-off-by: Pascal Bach 
>

ERROR: zlib-1.2.11-r0 do_populate_lic: QA Issue: zlib: The LIC_FILES_CHKSUM
does not match for
file://zlib.h;beginline=4;endline=23;md5=fde612df1e5933c428b73844a0c494fd
zlib: The new md5 checksum is 627e6ecababe008a45c70e318ae7014e
zlib: Here is the selected license text:
 beginline=4 v
  Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.

  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:

...
  1. The origin of this software must not be misrepresented; you must not
 claim that you wrote the original software. If you use this software
 in a product, an acknowledgment in the product documentation would be
 appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
 misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.

  Jean-loup GaillyMark Adler
  jl...@gzip.org  mad...@alumni.caltech.edu
^ endline=23 ^
zlib: Check if the license information has changed in
/data/poky-master/tmp/work/corei7-64-poky-linux/zlib/1.2.11-r0/zlib-1.2.11/zlib.h
(lines 4 through to 23) to verify that the LICENSE value "Zlib" remains
valid [license-checksum]

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

[OE-core] [PATCH] zlib: Upgrade 1.2.8 -> 1.2.11

[Peter Marko]

Signed-off-by: Peter Marko 
Signed-off-by: Andrej Valek 
Signed-off-by: Pascal Bach 
---
 .../zlib/{zlib-1.2.8 => zlib-1.2.11}/Makefile-runtests.patch  | 0
 .../recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/ldflags-tests.patch | 0
 .../zlib/{zlib-1.2.8 => zlib-1.2.11}/remove.ldconfig.call.patch   | 0
 meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/run-ptest  | 0
 meta/recipes-core/zlib/{zlib_1.2.8.bb => zlib_1.2.11.bb}  | 4 ++--
 5 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => 
zlib-1.2.11}/Makefile-runtests.patch (100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/ldflags-tests.patch 
(100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => 
zlib-1.2.11}/remove.ldconfig.call.patch (100%)
 rename meta/recipes-core/zlib/{zlib-1.2.8 => zlib-1.2.11}/run-ptest (100%)
 rename meta/recipes-core/zlib/{zlib_1.2.8.bb => zlib_1.2.11.bb} (91%)

diff --git a/meta/recipes-core/zlib/zlib-1.2.8/Makefile-runtests.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/Makefile-runtests.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/Makefile-runtests.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/Makefile-runtests.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/ldflags-tests.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/ldflags-tests.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/ldflags-tests.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/remove.ldconfig.call.patch 
b/meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/remove.ldconfig.call.patch
rename to meta/recipes-core/zlib/zlib-1.2.11/remove.ldconfig.call.patch
diff --git a/meta/recipes-core/zlib/zlib-1.2.8/run-ptest 
b/meta/recipes-core/zlib/zlib-1.2.11/run-ptest
similarity index 100%
rename from meta/recipes-core/zlib/zlib-1.2.8/run-ptest
rename to meta/recipes-core/zlib/zlib-1.2.11/run-ptest
diff --git a/meta/recipes-core/zlib/zlib_1.2.8.bb 
b/meta/recipes-core/zlib/zlib_1.2.11.bb
similarity index 91%
rename from meta/recipes-core/zlib/zlib_1.2.8.bb
rename to meta/recipes-core/zlib/zlib_1.2.11.bb
index 913c703..939be68 100644
--- a/meta/recipes-core/zlib/zlib_1.2.8.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.11.bb
@@ -13,8 +13,8 @@ SRC_URI = 
"${SOURCEFORGE_MIRROR}/libpng/${BPN}/${PV}/${BPN}-${PV}.tar.xz \
file://run-ptest \
"
 
-SRC_URI[md5sum] = "28f1205d8dd2001f26fec1e8c2cebe37"
-SRC_URI[sha256sum] = 
"831df043236df8e9a7667b9e3bb37e1fcb1220a0f163b6de2626774b9590d057"
+SRC_URI[md5sum] = "85adef240c5f370b308da8c938951a68"
+SRC_URI[sha256sum] = 
"4ff941449631ace0d4d203e3483be9dbc9da454084111f97ea0a2114e19bf066"
 
 RDEPENDS_${PN}-ptest += "make"
 
-- 
2.1.4

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

[OE-core] [PATCH] wireless-tools: Update URLs

[Jussi Kukkonen]

wireless-tools is now hosted on
https://hewlettpackard.github.io/wireless-tools/Tools.html

Signed-off-by: Jussi Kukkonen 
---
 meta/recipes-connectivity/wireless-tools/wireless-tools_30.pre9.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-connectivity/wireless-tools/wireless-tools_30.pre9.bb 
b/meta/recipes-connectivity/wireless-tools/wireless-tools_30.pre9.bb
index c3b8f66..0a34207 100644
--- a/meta/recipes-connectivity/wireless-tools/wireless-tools_30.pre9.bb
+++ b/meta/recipes-connectivity/wireless-tools/wireless-tools_30.pre9.bb
@@ -1,5 +1,5 @@
 SUMMARY = "Tools for the Linux Standard Wireless Extension Subsystem"
-HOMEPAGE = "http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html;
+HOMEPAGE = "https://hewlettpackard.github.io/wireless-tools/Tools.html;
 LICENSE = "GPLv2 & (LGPLv2.1 | MPL-1.1 | BSD)"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \

file://iwconfig.c;beginline=1;endline=12;md5=cf710eb1795c376eb10ea4ff04649caf \
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 SECTION = "base"
 PE = "1"
 
-SRC_URI = 
"http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/wireless_tools.${PV}.tar.gz
 \
+SRC_URI = 
"https://hewlettpackard.github.io/wireless-tools/wireless_tools.${PV}.tar.gz \
file://remove.ldconfig.call.patch \
file://man.patch \
file://avoid_strip.patch \
@@ -17,7 +17,7 @@ SRC_URI = 
"http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/wireless_tools.$
 SRC_URI[md5sum] = "ca91ba7c7eff9bfff6926b1a34a4697d"
 SRC_URI[sha256sum] = 
"abd9c5c98abf1fdd11892ac2f8a56737544fe101e1be27c6241a564948f34c63"
 
-UPSTREAM_CHECK_URI = 
"http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html;
+UPSTREAM_CHECK_URI = 
"https://hewlettpackard.github.io/wireless-tools/Tools.html;
 UPSTREAM_CHECK_REGEX = "wireless_tools\.(?P(\d+)(\..*|))\.tar\.gz"
 
 S = "${WORKDIR}/wireless_tools.30"
-- 
2.1.4

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

[OE-core] a few more picky questions about COMPATIBLE_MACHINE usage

[Robert P. J. Day]

  (i apologize for beating this issue to death, but i want to
understand it and, more often than not, what i'm puzzled about always
seems simple but i end up wondering, "ok, is that just sloppily coded,
or is there some subtle property that i'm missing?". anyway ...)

  from examples under meta-openembedded, let's first look at the
recipe meta-efl/recipes-efl/e17/elbow_git.bb, which opens with:

  # webkit-efl isn't available for < armv7a
  COMPATIBLE_MACHINE = "(-)"
  COMPATIBLE_MACHINE_x86 = "(.*)"
  COMPATIBLE_MACHINE_x86-64 = "(.*)"
  COMPATIBLE_MACHINE_armv7a = "(.*)"

  first, that comment seems out of date as it makes no mention of MIPS
or ppc, but that's just being picky.

  next, i assume the line:

  COMPATIBLE_MACHINE = "(-)"

is to initialize the set of compatible machines to the empty set, yes?
i'm more familiar with the construct:

  COMPATIBLE_MACHINE = "(^$)"

to do that, but i'm assuming setting that variable to any unmatchable
value from MACHINE_OVERRIDES will work just as well. (it would be nice
if that were consistent, unless there is something magic about the RE
"-").

  i next assume that lines of the form:

  COMPATIBLE_MACHINE_x86 = "(.*)"

are meant to indicate that if that MACHINE_OVERRIDES comparison
succeeds, then all possible targets are compatible, is that right?
however, given precisely those lines above, is it not equivalent to
just write:

  COMPATIBLE_MACHINE = "(x86|x86-64|armv7a)"

oddly, there is another recipe that seems to do the same thing, but in
a very different way, meta-oe/recipes-support/ne10/ne10_1.2.1.bb:

  COMPATIBLE_MACHINE_aarch64 = "(.*)"
  COMPATIBLE_MACHINE_armv7a = "(.*)"

  python () {
if any(t.startswith('armv7') for t in d.getVar('TUNE_FEATURES').split()):
d.setVar('NE10_TARGET_ARCH', 'armv7')
bb.debug(2, 'Building Ne10 for armv7')
elif any(t.startswith('aarch64') for t in 
d.getVar('TUNE_FEATURES').split()):
d.setVar('NE10_TARGET_ARCH', 'aarch64')
bb.debug(2, 'Building Ne10 for aarch64')
else:
raise bb.parse.SkipPackage("Incompatible with archs other than armv7 
and aarch64")
  }

i'm confused ... what is the point of defining these compatibilites:

  COMPATIBLE_MACHINE_aarch64 = "(.*)"
  COMPATIBLE_MACHINE_armv7a = "(.*)"

without first starting with:

  COMPATIBLE_MACHINE = "(-)"

as is stands, isn't the above just saying this recipe is compatible
with everything?

  now, i can see that that anonymous python routine refines the
machine compatibility even further but, to speed things up, why not
first start with just:

  COMPATIBLE_MACHINE = "(aarch64|armv7a)"

or (once again), am i misunderstanding something?

  one more question coming on this, but i want to study it a bit more
carefully first.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[OE-core] [PATCH v3] deprecated.bbclass: Add a PNDEPRECATED variable for recipes

[Joe MacDonald]

Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.

Signed-off-by: Joe MacDonald 
---

v2: Included documentation for new variable

v3: Refreshed to address patchwork scolding

 documentation/ref-manual/ref-classes.xml   | 28 
 documentation/ref-manual/ref-variables.xml | 28 
 meta/classes/deprecated.bbclass| 16 
 meta/conf/distro/defaultsetup.conf |  3 ++-
 4 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 meta/classes/deprecated.bbclass

diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index f7b1126..6088b44 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -632,6 +632,34 @@
 
 
 
+
+deprecated.bbclass
+
+
+The deprecated class identifies recipes
+that for one reason or another are being considered for removal
+from their current layer. It may be due to persistent, known
+issues with the package, that there are newer, more feature-rich
+alternatives available in the same layer or that the recipe is
+no longer needed.  The recipe should provide a reason for the
+depercation and a suggestion to consumers of the recipe as to how
+to proceed.
+To use this class, inherit the class globally and set
+PNDEPRECATED
+for each recipe you intend to deprecate.
+Specify the PN
+value as a variable flag (varflag) and provide a reason, which is
+reported, if the package is requested to be built as the value.
+For example, if you want to deprecate a recipe called "exoticware",
+you add the following to your local.conf
+or distribution configuration:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[exoticware] = "'exoticware' is considered obsolete and has 
been replaced by 'standardware'.  'exoticware' may not appear in future 
releases."
+
+
+
+
 
 devshell.bbclass
 
diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index f79cdd2..629d167 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -9920,6 +9920,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = 
"${INC_PR}.3"
 
 
 
+PNDEPRECATED
+
+PNDEPRECATED[doc] = "Lists recipes that may be removed in a 
future release or have more actively maintained alternatives."
+
+
+
+
+Lists recipes that may be removed in a future release or
+have more actively maintained alternatives.
+This variable works in conjunction with the
+deprecated
+class, which the recipe must inherit globally.
+
+
+
+To identify a recipe as deprecated, inherit the class
+globally and use the variable in your
+local.conf file.
+Here is an example that will show a warning when
+myrecipe is included in a project:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[myrecipe] = "Recipe is no longer actively maintained, you 
should consider using 'mynewrecipe' as an alternative."
+
+
+
+
+
 POPULATE_SDK_POST_HOST_COMMAND
 
 POPULATE_SDK_POST_HOST_COMMAND[doc] = "Specifies a list of 
functions to call once the OpenEmbedded build system has created host part of 
the SDK."
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+#   PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+if deprecated:
+bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf 
b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + 
str(d.getVar('MACHINE'
 USER_CLASSES ?= ""
 PACKAGE_CLASSES ?= "package_ipk"
 INHERIT_BLACKLIST = "blacklist"
+INHERIT_DEPRECATED = "deprecated"
 

Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes

[Joe MacDonald]

[Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for 
recipes] On 17.02.24 (Fri 21:51) Martin Jansa wrote:

> OK, should I update all currently PNBLACKLISTed recipes to add " - the
> recipe will be removed on 2017-09-01 unless the issue is fixed" in the
> PNBLACKLIST value, so that we can delete all blacklisted recipes
> before 2.4 release?

I haven't seen any additional discussion on this yet but my personal
opinion on this is it seems reasonable to draw a line in the sand and
one that's quite far out.  I also expect that there'll be a flurry of
activity as the deadline draws close, so there's room for flexibility in
the drop-dead date, but that'd be a discretionary thing.  If we wanted
to be slightly less contentious, the wording could be 'may' rather than
'will' and then the message is "if it isn't fixed by this date, it's
fair game to be removed whenever someone gets around to it".

-J.

> 
> On Fri, Feb 24, 2017 at 9:39 PM, Philip Balister  wrote:
> 
> On 02/24/2017 01:16 AM, Martin Jansa wrote:
> >> If nobody speaks up within some
> > amount of time the maintainer considers reasonable (I'm thinking a Yocto
> > release
> > cycle) then it's fair game to remove the recipe in question.
> >
> > Maybe this is different case with at least some PNBLACKLIST entries we
> > currently have, but
> > I don't remove PNBLACKLISTed recipes, because as we discussed it's 
> always
> > easier to unblacklist
> > recipe from e.g. DISTRO config if the issue doesn't affect you for
> whatever
> > reason and causes
> > less churn in the metadata when it gets unblacklisted.
> >
> > And many PNBLACKLISTed recipes are also abandonware.
> >
> 
> I think we need to use a different "flag" for recipes that need
> updating, and have maintained upstreams from recipes that have upstreams
> that are abandoned.
> 
> So blacklist broken recipes with good upstreams and deprecate recipes
> with dead upstreams.
>
> Philip
>
> 
> 
> > So my question is, if we will remove PNDEPRECATed recipes after one
> cycle,
> > should we start
> > removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both
> > cases it might backfire
> > when someone will fail to find recipe for his favorite abandonware and
> will
> > try to add completely
> > new recipe for it, or we see someone restoring these recipes (e.g. in 
> own
> > layers instead of fixing
> > the PNBLACKLIST/PNDEPRECATED reasons in original layer).
> >
> > On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj  wrote:
> >
> >>
> >> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald 
> 
> >> wrote:
> >>
> >>> Based on the blacklist behaviour, recipes can be tagged as deprecated.
> >>> Such recipes will produce a warning message when included in a build
> but
> >>> unlike blacklisted recipes, the build will continue.
> >>
> >>
> >> Perhaps this should also be documented in manuals
> >>
> >>>
> >>>
> >>> Signed-off-by: Joe MacDonald 
> >>> ---
> >>>
> >>> I threw this together a long time ago and never got around to sending
> it
> >>> out for
> >>> consideration, but after the excitement last week and this, I got
> >>> thinking about
> >>> it again and thought it might be useful.  My specific use-case for 
> this
> is
> >>> recipes I see in meta-networking that I know are largely abandonware
> but
> >>> that I
> >>> don't want to completely throw out without giving some kind of heads
> up.
> >>> Obviously this is purely informational, there's no mechanism set up 
> for
> >>> purging
> >>> deprecated recipes, that's intended to be a maintainer activity, but
> the
> >>> idea
> >>> would be that the maintainer would flag a recipe as deprecated
> (probably
> >>> when
> >>> it's become more trouble than it seems to be worth) and thereafter
> users
> >>> would
> >>> have fair warning that this thing is on notice.  If nobody speaks up
> >>> within some
> >>> amount of time the maintainer considers reasonable (I'm thinking a
> Yocto
> >>> release
> >>> cycle) then it's fair game to remove the recipe in question.
> >>>
> >>>  meta/classes/deprecated.bbclass| 16 
> >>>  meta/conf/distro/defaultsetup.conf |  3 ++-
> >>>  2 files changed, 18 insertions(+), 1 deletion(-)
> >>>  create mode 100644 meta/classes/deprecated.bbclass
> >>>
> >>> diff --git a/meta/classes/deprecated.bbclass 
> b/meta/classes/deprecated.
> >>> bbclass
> >>> new file mode 100644
> >>> index 000..3dcdadb
> >>> --- /dev/null
> >>> +++ b/meta/classes/deprecated.bbclass
> >>> @@ -0,0 +1,16 @@
> >>> +# To use the deprecated 

[OE-core] [PATCH 1/1] recipes: Make use of the new bb.utils.filter() function

[Peter Kjellerstedt]

From: Peter Kjellerstedt 

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/testimage.bbclass  | 2 +-
 meta/conf/machine/include/mips/arch-mips.inc| 4 ++--
 meta/conf/machine/include/tune-ppce500.inc  | 2 +-
 meta/conf/machine/include/tune-ppce500v2.inc| 2 +-
 meta/recipes-bsp/u-boot/u-boot.inc  | 2 +-
 meta/recipes-connectivity/connman/connman.inc   | 4 +---
 meta/recipes-connectivity/libpcap/libpcap.inc   | 2 +-
 meta/recipes-connectivity/neard/neard_0.16.bb   | 2 +-
 meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.4.bb  | 2 +-
 meta/recipes-connectivity/ofono/ofono.inc   | 2 +-
 meta/recipes-connectivity/openssh/openssh_7.4p1.bb  | 4 ++--
 meta/recipes-connectivity/openssl/openssl.inc   | 4 ++--
 meta/recipes-core/coreutils/coreutils_6.9.bb| 2 +-
 meta/recipes-core/coreutils/coreutils_8.26.bb   | 3 +--
 meta/recipes-core/dbus/dbus_1.10.14.bb  | 4 +---
 meta/recipes-core/dropbear/dropbear.inc | 6 +++---
 meta/recipes-core/kbd/kbd_2.0.3.bb  | 2 +-
 meta/recipes-core/libxml/libxml2_2.9.4.bb   | 2 +-
 meta/recipes-core/systemd/systemd_232.bb| 4 +---
 meta/recipes-core/util-linux/util-linux.inc | 4 ++--
 meta/recipes-devtools/gdb/gdb_7.12.1.bb | 2 +-
 meta/recipes-devtools/mtd/mtd-utils_git.bb  | 2 +-
 meta/recipes-devtools/patch/patch_2.7.5.bb  | 2 +-
 meta/recipes-devtools/pax-utils/pax-utils_1.2.2.bb  | 2 +-
 meta/recipes-devtools/python/python-smartpm_git.bb  | 4 ++--
 meta/recipes-devtools/qemu/qemu.inc | 3 +--
 meta/recipes-devtools/rsync/rsync_2.6.9.bb  | 2 +-
 meta/recipes-devtools/rsync/rsync_3.1.2.bb  | 2 +-
 meta/recipes-devtools/ruby/ruby_2.3.3.bb| 2 +-
 meta/recipes-extended/at/at_3.1.20.bb   | 2 +-
 meta/recipes-extended/cronie/cronie_1.5.1.bb| 2 +-
 meta/recipes-extended/cups/cups.inc | 3 +--
 meta/recipes-extended/iptables/iptables_1.6.1.bb| 3 +--
 meta/recipes-extended/libarchive/libarchive_3.2.2.bb| 4 +---
 meta/recipes-extended/lighttpd/lighttpd_1.4.45.bb   | 2 +-
 meta/recipes-extended/logrotate/logrotate_3.9.1.bb  | 5 +
 meta/recipes-extended/psmisc/psmisc.inc | 2 +-
 meta/recipes-extended/rpcbind/rpcbind_0.2.4.bb  | 2 +-
 meta/recipes-extended/screen/screen_4.4.0.bb| 2 +-
 meta/recipes-extended/shadow/shadow.inc | 2 +-
 meta/recipes-extended/sudo/sudo_1.8.18p1.bb | 2 +-
 meta/recipes-extended/wget/wget.inc | 2 +-
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.36.1.bb  | 2 +-
 meta/recipes-gnome/gtk+/gtk+.inc| 4 +---
 meta/recipes-gnome/gtk+/gtk+3.inc   | 6 ++
 meta/recipes-graphics/cairo/cairo.inc   | 2 +-
 meta/recipes-graphics/clutter/clutter-1.0.inc   | 2 +-
 meta/recipes-graphics/libepoxy/libepoxy_1.4.0.bb| 2 +-
 meta/recipes-graphics/libsdl/libsdl_1.2.15.bb   | 9 +++--
 meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb  | 7 ++-
 meta/recipes-graphics/libva/libva_1.7.3.bb  | 3 +--
 meta/recipes-graphics/mesa/mesa-demos_8.3.0.bb  | 2 +-
 meta/recipes-graphics/mesa/mesa-gl_13.0.4.bb| 2 +-
 meta/recipes-graphics/mesa/mesa.inc | 3 +--
 meta/recipes-graphics/pango/pango_1.40.3.bb | 2 +-
 meta/recipes-graphics/wayland/weston_1.11.1.bb  | 6 ++
 meta/recipes-graphics/xorg-app/xauth_1.0.10.bb  | 2 +-
 meta/recipes-graphics/xorg-app/xhost_1.0.7.bb   | 2 +-
 meta/recipes-graphics/xorg-lib/libice_1.0.9.bb  | 2 +-
 meta/recipes-graphics/xorg-lib/libsm_1.2.2.bb   | 2 +-
 meta/recipes-graphics/xorg-lib/libxfont2_2.0.1.bb   | 2 +-
 meta/recipes-graphics/xorg-lib/libxfont_1.5.2.bb| 2 +-
 meta/recipes-graphics/xorg-lib/libxkbcommon_0.7.1.bb| 2 +-
 meta/recipes-graphics/xorg-lib/libxmu_1.1.2.bb  | 2 +-
 meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 4 ++--
 meta/recipes-kernel/latencytop/latencytop_0.5.bb| 2 +-
 meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb  | 

Re: [OE-core] [PATCH 1/4] go: Add recipes for golang compilers and tools

[Burton, Ross]

On 25 February 2017 at 18:13, Khem Raj  wrote:

> This is converging the recipes for go from
> meta-virtualization and oe-meta-go
>

ERROR: go-cross-x86_64-1.7.4-r0 do_compile: Function failed: do_compile
(log file is located at
/data/poky-master/tmp/work/x86_64-linux/go-cross-x86_64/1.7.4-r0/temp/log.do_compile.21270)
ERROR: Logfile of failure stored in:
/data/poky-master/tmp/work/x86_64-linux/go-cross-x86_64/1.7.4-r0/temp/log.do_compile.21270
Log data follows:
| DEBUG: Executing shell function do_compile
| # Building Go bootstrap tool.
| cmd/dist
| #
_/data/poky-master/tmp/work/x86_64-linux/go-cross-x86_64/1.7.4-r0/go/src/cmd/dist
|
/data/poky-master/tmp/work/x86_64-linux/go-cross-x86_64/1.7.4-r0/recipe-sysroot-native/usr/lib/go/pkg/tool/linux_amd64/6l:
readsym out of sync

Also, can you squash the fixing up patches so we just have a single commit
that actually works.

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

[OE-core] [PATCH 0/1] Make use of bb.utils.filter()

[Peter Kjellerstedt]

This is an updated version of my patch that was previously sent to the
bitbake-devel list accompanying my change to introduce the new
bb.utils.filter() function. It is intended to replace b754cb5bf1 on
master-next.

Compared to what is on master-next now it:

* updates iptables abd xauth that were skipped due to conflicts,
* adds a couple of uses for bb.utils.filter() with TUNE_FEATURES and
  PACKAGECONFIG that I had previously missed, and
* simplifies a couple of if statements in shell code that use the
  result of bb.utils.filter().

//Peter

The following changes since commit 653283be9a5060f7bf5589a92bb3748606996eef:

  sanity: Require bitbake 1.33.2 (2017-02-24 13:20:39 -0800)

are available in the git repository at:

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

Peter Kjellerstedt (1):
  recipes: Make use of the new bb.utils.filter() function

 meta/classes/testimage.bbclass  | 2 +-
 meta/conf/machine/include/mips/arch-mips.inc| 4 ++--
 meta/conf/machine/include/tune-ppce500.inc  | 2 +-
 meta/conf/machine/include/tune-ppce500v2.inc| 2 +-
 meta/recipes-bsp/u-boot/u-boot.inc  | 2 +-
 meta/recipes-connectivity/connman/connman.inc   | 4 +---
 meta/recipes-connectivity/libpcap/libpcap.inc   | 2 +-
 meta/recipes-connectivity/neard/neard_0.16.bb   | 2 +-
 meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.4.bb  | 2 +-
 meta/recipes-connectivity/ofono/ofono.inc   | 2 +-
 meta/recipes-connectivity/openssh/openssh_7.4p1.bb  | 4 ++--
 meta/recipes-connectivity/openssl/openssl.inc   | 4 ++--
 meta/recipes-core/coreutils/coreutils_6.9.bb| 2 +-
 meta/recipes-core/coreutils/coreutils_8.26.bb   | 3 +--
 meta/recipes-core/dbus/dbus_1.10.14.bb  | 4 +---
 meta/recipes-core/dropbear/dropbear.inc | 6 +++---
 meta/recipes-core/kbd/kbd_2.0.3.bb  | 2 +-
 meta/recipes-core/libxml/libxml2_2.9.4.bb   | 2 +-
 meta/recipes-core/systemd/systemd_232.bb| 4 +---
 meta/recipes-core/util-linux/util-linux.inc | 4 ++--
 meta/recipes-devtools/gdb/gdb_7.12.1.bb | 2 +-
 meta/recipes-devtools/mtd/mtd-utils_git.bb  | 2 +-
 meta/recipes-devtools/patch/patch_2.7.5.bb  | 2 +-
 meta/recipes-devtools/pax-utils/pax-utils_1.2.2.bb  | 2 +-
 meta/recipes-devtools/python/python-smartpm_git.bb  | 4 ++--
 meta/recipes-devtools/qemu/qemu.inc | 3 +--
 meta/recipes-devtools/rsync/rsync_2.6.9.bb  | 2 +-
 meta/recipes-devtools/rsync/rsync_3.1.2.bb  | 2 +-
 meta/recipes-devtools/ruby/ruby_2.3.3.bb| 2 +-
 meta/recipes-extended/at/at_3.1.20.bb   | 2 +-
 meta/recipes-extended/cronie/cronie_1.5.1.bb| 2 +-
 meta/recipes-extended/cups/cups.inc | 3 +--
 meta/recipes-extended/iptables/iptables_1.6.1.bb| 3 +--
 meta/recipes-extended/libarchive/libarchive_3.2.2.bb| 4 +---
 meta/recipes-extended/lighttpd/lighttpd_1.4.45.bb   | 2 +-
 meta/recipes-extended/logrotate/logrotate_3.9.1.bb  | 5 +
 meta/recipes-extended/psmisc/psmisc.inc | 2 +-
 meta/recipes-extended/rpcbind/rpcbind_0.2.4.bb  | 2 +-
 meta/recipes-extended/screen/screen_4.4.0.bb| 2 +-
 meta/recipes-extended/shadow/shadow.inc | 2 +-
 meta/recipes-extended/sudo/sudo_1.8.18p1.bb | 2 +-
 meta/recipes-extended/wget/wget.inc | 2 +-
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.36.1.bb  | 2 +-
 meta/recipes-gnome/gtk+/gtk+.inc| 4 +---
 meta/recipes-gnome/gtk+/gtk+3.inc   | 6 ++
 meta/recipes-graphics/cairo/cairo.inc   | 2 +-
 meta/recipes-graphics/clutter/clutter-1.0.inc   | 2 +-
 meta/recipes-graphics/libepoxy/libepoxy_1.4.0.bb| 2 +-
 meta/recipes-graphics/libsdl/libsdl_1.2.15.bb   | 9 +++--
 meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb  | 7 ++-
 meta/recipes-graphics/libva/libva_1.7.3.bb  | 3 +--
 meta/recipes-graphics/mesa/mesa-demos_8.3.0.bb  | 2 +-
 meta/recipes-graphics/mesa/mesa-gl_13.0.4.bb| 2 +-
 meta/recipes-graphics/mesa/mesa.inc | 3 +--
 meta/recipes-graphics/pango/pango_1.40.3.bb | 2 +-
 

Re: [OE-core] State of bitbake world, Failed tasks 2017-02-23

[Martin Jansa]

Yes, it is reproduced only when ld-is-gold and ptest are used in
DISTRO_FEATURES.

On Mon, Feb 27, 2017 at 12:50 PM, Burton, Ross 
wrote:

>
> On 23 February 2017 at 22:20, Martin Jansa  wrote:
>
>> === common (2) ===
>> * openembedded-core/meta/recipes-extended/parted/parted_3.2.
>> bb:do_compile_ptest_base
>> * openembedded-core/meta/recipes-support/apr/apr_1.5.2.bb:do_
>> compile_ptest_base
>>
>
> FWIW neither me nor the yocto autobuilder sees these, so I suspect they're
> ld-is-gold related.
>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] in meta-yocto-bsp kernel recipes, why individual settings for COMPATIBLE_MACHINE?

[Robert P. J. Day]

On Mon, 27 Feb 2017, Robert P. J. Day wrote:

>
>   more nitpicky pedantry ... under
> meta-yocto-bsp/recipes-kernel/linux, i see a number of
> COMPATIBLE_MACHINE settings:
>
>   COMPATIBLE_MACHINE_genericx86 = "genericx86"
>   COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
>   COMPATIBLE_MACHINE_edgerouter = "edgerouter"
>   COMPATIBLE_MACHINE_beaglebone = "beaglebone"
>   COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
>
> given that every one of those conditional assignments match *exactly*
> the respective target system, how does that effectively differ from
> just writing (issues with RE matching aside):
>
>   COMPATIBLE_MACHINE = 
> "(genericx86|genericx86-64|edgerouter|beaglebone|mpc8315e-rdb)"
>
> i can certainly see how one might need to use conditional assignments
> for COMPATIBLE_MACHINE if one has, say, extended the definition of
> MACHINEOVERRIDES to classify target systems into compatible subgroups,
> but that's not what's happening above. is there something more subtle
> going on there that i'm missing?

  never mind, it just dawned on me that those override-based
assignments will leave any earlier assignments in place, rather than
wiping them out. but in the cases where you really just want to
hardcode a set of compatible machines, using that single like still
looks perfectly acceptable.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
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 2017-02-23

[Burton, Ross]

On 23 February 2017 at 22:20, Martin Jansa  wrote:

> === common (2) ===
> * openembedded-core/meta/recipes-extended/parted/parted_3.2.bb:
> do_compile_ptest_base
> * openembedded-core/meta/recipes-support/apr/apr_1.5.2.
> bb:do_compile_ptest_base
>

FWIW neither me nor the yocto autobuilder sees these, so I suspect they're
ld-is-gold related.

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

Re: [OE-core] [PATCH] pulseaudio: 9.0 -> 10.0

[Burton, Ross]

On 25 February 2017 at 15:30, Tanu Kaskinen  wrote:

> I couldn't reproduce the problem. I don't get the warning, and "readelf
> -d tmp/work/corei7-64-poky-linux/pulseaudio/10.0-r0/packages-
> split/pulseaudio-server/usr/bin/pulseaudio | grep TEXT" returns
> nothing.
>
> My test was performed on a fresh poky clone with default configuration,
> using command "bitbake pulseaudio". In addition to the default qemux86,
> I tried with genericx86-64 and also intel-corei7-64 from meta-intel,
> since your error message seemed to be from a corei7 build.
>

Typical. :/  Thanks for trying, I must have something locally that triggers
it.

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

[OE-core] in meta-yocto-bsp kernel recipes, why individual settings for COMPATIBLE_MACHINE?

[Robert P. J. Day]

  more nitpicky pedantry ... under
meta-yocto-bsp/recipes-kernel/linux, i see a number of
COMPATIBLE_MACHINE settings:

  COMPATIBLE_MACHINE_genericx86 = "genericx86"
  COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
  COMPATIBLE_MACHINE_edgerouter = "edgerouter"
  COMPATIBLE_MACHINE_beaglebone = "beaglebone"
  COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"

given that every one of those conditional assignments match *exactly*
the respective target system, how does that effectively differ from
just writing (issues with RE matching aside):

  COMPATIBLE_MACHINE = 
"(genericx86|genericx86-64|edgerouter|beaglebone|mpc8315e-rdb)"

i can certainly see how one might need to use conditional assignments
for COMPATIBLE_MACHINE if one has, say, extended the definition of
MACHINEOVERRIDES to classify target systems into compatible subgroups,
but that's not what's happening above. is there something more subtle
going on there that i'm missing?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[OE-core] style suggestions for that whole "_append" and leading space thing

[Robert P. J. Day]

  getting pedantic (as i am wont to do), occasionally i run across
things like this, from meta/conf/distro/include/no-static-libs.inc:

  EXTRA_OECONF_append = "${DISABLE_STATIC}"

which, at first glance, simply seems wrong given the lack of a leading
space, until one looks higher up in that same file to read:

  DISABLE_STATIC = " --disable-static"

where one finds the leading space as part of the variable itself. i
find this potentially *really* confusing; consistent style suggests
variables should be assigned their values without regard as to how
they might be used later. subsequent references or usages of those
variables should be responsible for making sure they're included
properly, no?

  and the last line in that same file also suggests potential misuse:

  EXTRA_OECMAKE_append_pn-libical = "-DSHARED_ONLY=True"

rday

p.s. would the same logic hold with lines like this?

meta/conf/machine/include/tune-ppce6500.inc:

  MACHINE_FEATURES_BACKFILL_CONSIDERED_append =
 "${@bb.utils.contains('TUNE_FEATURES', 'e6500', ' qemu-usermode', '', d)}"

would it not be clearer if one were to write:

  MACHINE_FEATURES_BACKFILL_CONSIDERED_append =
 " ${@bb.utils.contains('TUNE_FEATURES', 'e6500', 'qemu-usermode', '', d)}"


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

[OE-core] what's with "SRC_URI_append +=" in meta/lib/oeqa/selftest/layerappend.py?

[Robert P. J. Day]

  every so often, i run a style-checking script against OE, and i just
noticed this in meta/lib/oeqa/selftest/layerappend.py:


  ... snip ...
  SRC_URI_append = " file://appendtest.txt"   <---

  sysroot_stage_all_append() {
install -m 644 ${WORKDIR}/appendtest.txt ${SYSROOT_DESTDIR}/
  }

  """

append2 = """
  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

  SRC_URI_append += "file://appendtest.txt"   <---
  """
  ... snip ...


i'm not sure what's going on in that file, should that second
instance be written with just "=", or is there something more subtle
happening there such that that construct is deliberate?

rday

p.s. i recall from some time back asking about this and while the
initial reaction to writing "..._append += ..." was, "yes, it's
superfluous, but it doesn't hurt," a later comment suggested it
*might* make a difference, in that (i think) using "_append" would
*not* add that leading space, but "+=" *would* add it, so there might
actually be some weird conflict in trying to mix the two.

  thoughts?

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

Re: [OE-core] [PATCH] python3: fix failure to run python3 in a multilib env or when BASELIB != lib

[Jagadeesh Krishnanjanappa]

Ping.

Could not see the patch included in
https://patchwork.openembedded.org/project/oe/series/?ordering=-last_updated,
do I need to resend it?

Regards,
Jagadeesh

On Sat, Feb 18, 2017 at 10:29 AM, Jagadeesh Krishnanjanappa <
jkrishnanjana...@mvista.com> wrote:

> Having hard coded "lib" string in lib_python path, searches for modules
> under /usr/lib/python3.x directory. This would result in an error on
> multilib environment, where BASELIB is other than lib.
>
> Example: On qemux86-64 with base_libdir and libdir as /lib64 and /usr/lib64
> respectively, would result in below error when python3 is executed:
> -- snip --
> root@qemux86-64:~# python3
> Could not find platform independent libraries 
> Could not find platform dependent libraries 
> Consider setting $PYTHONHOME to [:]
> Fatal Python error: Py_Initialize: Unable to get the locale encoding
> ImportError: No module named 'encodings'
>
> Current thread 0x7f65dbb53700 (most recent call first):
> Aborted
> root@qemux86-64:~#
> -- snip --
>
> Similar issue observed at:
> https://knowledge.windriver.com/en-us/000_Products/000/
> 010/040/040/000_LIN8-4040_%3A_python3_does_not_work_in_a_
> multilib_environment
>
> Signed-off-by: Jagadeesh Krishnanjanappa 
> ---
>  ...remove-hard-coded-lib-string-for-multilib.patch | 37
> ++
>  meta/recipes-devtools/python/python3_3.5.2.bb  |  1 +
>  2 files changed, 38 insertions(+)
>  create mode 100644 meta/recipes-devtools/python/
> python3/python-3.5.2-remove-hard-coded-lib-string-for-multilib.patch
>
> diff --git a/meta/recipes-devtools/python/python3/python-3.5.2-
> remove-hard-coded-lib-string-for-multilib.patch b/meta/recipes-devtools/
> python/python3/python-3.5.2-remove-hard-coded-lib-string-
> for-multilib.patch
> new file mode 100644
> index 000..786f086
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3/python-3.5.2-
> remove-hard-coded-lib-string-for-multilib.patch
> @@ -0,0 +1,37 @@
> +Having hard coded "lib" string in lib_python path, searches for modules
> +under /usr/lib/python3.x directory. This would result in an error on
> +multilib environment, where BASELIB is other than lib.
> +
> +Example: On qemux86-64 with base_libdir and libdir as /lib64 and
> /usr/lib64
> +respectively, would result in below error when python3 is executed:
> +-- snip --
> +root@qemux86-64:~# python3
> +Could not find platform independent libraries 
> +Could not find platform dependent libraries 
> +Consider setting $PYTHONHOME to [:]
> +Fatal Python error: Py_Initialize: Unable to get the locale encoding
> +ImportError: No module named 'encodings'
> +
> +Current thread 0x7f65dbb53700 (most recent call first):
> +Aborted
> +root@qemux86-64:~#
> +-- snip --
> +
> +Note: LIB is defined with actual base_libdir used via -DLIB during
> +compilation.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Jagadeesh Krishnanjanappa 
> +diff -Naurp Python-3.5.2_org/Modules/getpath.c
> Python-3.5.2/Modules/getpath.c
> +--- Python-3.5.2_org/Modules/getpath.c 2017-02-17 00:58:28.312583182
> +0530
>  Python-3.5.2/Modules/getpath.c 2017-02-17 01:01:58.984805492 +0530
> +@@ -502,7 +502,7 @@ calculate_path(void)
> + _pythonpath = Py_DecodeLocale(PYTHONPATH, NULL);
> + _prefix = Py_DecodeLocale(PREFIX, NULL);
> + _exec_prefix = Py_DecodeLocale(EXEC_PREFIX, NULL);
> +-lib_python = Py_DecodeLocale("lib/python" VERSION, NULL);
> ++lib_python = Py_DecodeLocale(LIB "/python" VERSION, NULL);
> +
> + if (!_pythonpath || !_prefix || !_exec_prefix || !lib_python) {
> + Py_FatalError(
> diff --git a/meta/recipes-devtools/python/python3_3.5.2.bb
> b/meta/recipes-devtools/python/python3_3.5.2.bb
> index 2ff7c9e..26f49f6 100644
> --- a/meta/recipes-devtools/python/python3_3.5.2.bb
> +++ b/meta/recipes-devtools/python/python3_3.5.2.bb
> @@ -37,6 +37,7 @@ SRC_URI += "\
>  file://configure.ac-fix-LIBPL.patch \
>  file://python3-fix-CVE-2016-1000110.patch \
>  file://upstream-random-fixes.patch \
> +
> file://python-3.5.2-remove-hard-coded-lib-string-for-multilib.patch
> \
> "
>  SRC_URI[md5sum] = "8906efbacfcdc7c3c9198aeefafd159e"
>  SRC_URI[sha256sum] = "0010f56100b9b74259ebcd5d4b295a
> 32324b58b517403a10d1a2aa7cb22bca40"
> --
> 2.7.4
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core