[OE-core] [PATCH 3/4] linux-libc-headers: update to 4.1

2015-07-21 Thread Bruce Ashfield 
Updating the libc-headers to match the 4.1 LTSI kernel version.

We also tweak the logic in linux-libc-headers.inc to look in the
4.x subdirectory if a 4.x kernel is specified as the header source.

Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
 meta/conf/distro/include/tcmode-default.inc   | 2 +-
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 2 ++
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb | 7 ---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb  | 7 +++
 4 files changed, 10 insertions(+), 8 deletions(-)
 delete mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb
 create mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index 096bec9fd623..84ecd7248021 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -28,7 +28,7 @@ BINUVERSION ?= 2.25
 GDBVERSION ?= 7.9%
 GLIBCVERSION ?= 2.21
 UCLIBCVERSION ?= 0.9.33+git%
-LINUXLIBCVERSION ?= 3.19
+LINUXLIBCVERSION ?= 4.1
 
 PREFERRED_VERSION_gcc ?= ${GCCVERSION}
 PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= ${GCCVERSION}
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index b18d09fd6c3e..566bc1e6154b 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -35,6 +35,8 @@ python __anonymous () {
 major = d.getVar(PV,True).split('.')[0]
 if major == 3:
 d.setVar(HEADER_FETCH_VER, 3.0)
+elif major == 4:
+d.setVar(HEADER_FETCH_VER, 4.x)
 else:
 d.setVar(HEADER_FETCH_VER, 2.6)
 }
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb
deleted file mode 100644
index 078df4512ba1..
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-KORG_ARCHIVE_COMPRESSION = xz
-
-require linux-libc-headers.inc
-
-SRC_URI[md5sum] = d3fc8316d4d4d04b65cbc2d70799e763
-SRC_URI[sha256sum] = 
be42511fe5321012bb4a2009167ce56a9e5fe362b4af43e8c371b3666859806c
-
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb
new file mode 100644
index ..d816e5e7845e
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb
@@ -0,0 +1,7 @@
+KORG_ARCHIVE_COMPRESSION = xz
+
+require linux-libc-headers.inc
+
+SRC_URI[md5sum] = fe9dc0f6729f36400ea81aa41d614c37
+SRC_URI[sha256sum] = 
caf51f085aac1e1cea4d00dbbf3093ead07b551fc07b31b2a989c05f8ea72d9f
+
-- 
2.1.0

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

Re: [OE-core] [PATCH v2 1/2] kernel: Define KERNEL_IMAGETYPE as a list

2015-07-21 Thread Christopher Larson 
On Tue, Jul 21, 2015 at 12:23 AM, zhe...@windriver.com wrote:

 From: He Zhe zhe...@windriver.com

 To support building packaging and installing multi types of kernel
 images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
 as a list.
 Modify wherever reference KERNEL_IMAGETYPE accordingly.

 Fixes [YOCTO #6945].

 Signed-off-by: He Zhe zhe...@windriver.com


Question, why not add KERNEL_IMAGETYPES, and make KERNEL_IMAGETYPE equal to
your new KERNEL_IMAGETYPE_0?
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/4] linux-yocto: split meta data from kernel repository

2015-07-21 Thread Bruce Ashfield 
The linux-yocto tree has always been a combined set of kernel changes
and configuration (meta) data carried in a single tree. While this
format is effective at keeping kernel configuration and source
modifications synchronized, it isn't always obvious to developers on
how to manipulate the meta data versus the source.

With this change, we remove the meta data processing from the
kernel-yocto class and use the external meta-data repository that
has always been used to seed the linux-yocto meta branch.

After this change, linux-yocto can no longer process combined trees,
and is simplified as a result.

Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
 meta/classes/kernel-yocto.bbclass  | 76 ++
 meta/recipes-kernel/linux/linux-yocto-dev.bb   |  5 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb   |  7 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |  7 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb |  7 +-
 meta/recipes-kernel/linux/linux-yocto_3.14.bb  |  7 +-
 meta/recipes-kernel/linux/linux-yocto_3.19.bb  |  7 +-
 7 files changed, 28 insertions(+), 88 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 2f9a41f34d0f..231e08deba68 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -33,6 +33,7 @@ def find_kernel_feature_dirs(d):
 for url in fetch.urls:
 urldata = fetch.ud[url]
 parm = urldata.parm
+type=
 if type in parm:
 type = parm[type]
 if destsuffix in parm:
@@ -112,17 +113,6 @@ do_kernel_metadata() {
fi
fi
 
-   # if we have a defined/set meta branch we should not be generating
-   # any meta data. The passed branch has what we need.
-   if [ -n ${KMETA} ]; then
-   createme_flags=--disable-meta-gen --meta ${KMETA}
-   fi
-
-   createme -v -v ${createme_flags} ${ARCH} ${machine_branch}
-   if [ $? -ne 0 ]; then
-   bbfatal_log Could not create ${machine_branch}
-   fi
-
sccs=$sccs ${@ .join(find_sccs(d))}
patches=${@ .join(find_patches(d))}
feat_dirs=${@ .join(find_kernel_feature_dirs(d))}
@@ -189,34 +179,18 @@ do_patch() {
 do_kernel_checkout() {
set +e
 
-   # A linux yocto SRC_URI should use the bareclone option. That
-   # ensures that all the branches are available in the WORKDIR version
-   # of the repository.
source_dir=`echo ${S} | sed 's%/$%%'`
source_workdir=${WORKDIR}/git
-   if [ -d ${WORKDIR}/git/ ]  [ -d ${WORKDIR}/git/.git ]; then
-   # case2: the repository is a non-bare clone
-
+   if [ -d ${WORKDIR}/git/ ]; then
+   # case: git repository (bare or non-bare)
# if S is WORKDIR/git, then we shouldn't be moving or deleting 
the tree.
if [ ${source_dir} != ${source_workdir} ]; then
rm -rf ${S}
mv ${WORKDIR}/git ${S}
fi
cd ${S}
-   elif [ -d ${WORKDIR}/git/ ]  [ ! -d ${WORKDIR}/git/.git ]; then
-   # case2: the repository is a bare clone
-
-   # if S is WORKDIR/git, then we shouldn't be moving or deleting 
the tree.
-   if [ ${source_dir} != ${source_workdir} ]; then
-   rm -rf ${S}
-   mkdir -p ${S}/.git
-   mv ${WORKDIR}/git/* ${S}/.git
-   rm -rf ${WORKDIR}/git/
-   fi
-   cd ${S} 
-   git config core.bare false
else
-   # case 3: we have no git repository at all. 
+   # case: we have no git repository at all. 
# To support low bandwidth options for building the kernel, 
we'll just 
# convert the tree to a git repo and let the rest of the 
process work unchanged

@@ -235,7 +209,6 @@ do_kernel_checkout() {
git commit -q -m baseline commit: creating repo for 
${PN}-${PV}
git clean -d -f
fi
-   # end debare
 
# convert any remote branches to local tracking ones
for i in `git branch -a --no-color | grep remotes | grep -v HEAD`; do
@@ -246,24 +219,8 @@ do_kernel_checkout() {
fi
done
 
-   # If KMETA is defined, the branch must exist, but a machine 
branch
-   # can be missing since it may be created later by the tools.
-   if [ -n ${KMETA} ]; then
-   git show-ref --quiet --verify -- refs/heads/${KMETA}
-   if [ $? -eq 1 ]; then
-   bberror The branch '${KMETA}' is required and was not 
found
-   bberror Ensure that the SRC_URI points to a valid 
linux-yocto
-   bbfatal_log kernel repository
-   fi
-   fi
-   
-
# Create a working tree copy of the

[OE-core] [PATCH 2/4] kern-tools: standalone tree configuration

2015-07-21 Thread Bruce Ashfield 
Updating the kern-tools SRCREV to import the following changes:

  cbd4b7102668 patchme/updateme: unify meta directory handling
  b65075997152 configme: standalone operation

The change of note is [configme: standalone operation], which makes the
kernel configuration script free from dependencies on other parts of the
kern-tools.

With this change, we set the stage to extend kernel configuration
fragments and auditing to arbitrary trees.

Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb 
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index e83f195a5393..4753094aa40c 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = 
file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
 
 DEPENDS = git-native
 
-SRCREV = 79bc82453c26d426d3d8fd05d5da37cf5fc4068c
+SRCREV = bd144d43ca5b1eaf9e727bced4ce3b61b642297c
 PR = r12
 PV = 0.2+git${SRCPV}
 
-- 
2.1.0

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

[OE-core] [PATCH 0/4] linux-yocto: build changes, 4.1 and libc-headers

2015-07-21 Thread Bruce Ashfield 
Hi all,

This series absolutely needs some more testing and runs through the
autobuilder, but I've done pretty much all I can do with it here.

I have more changes to the build process that will follow this, but 
these changes need to show that they are stable, so here's the first
blast.

With this series:

  - I create the 4.1, and 4.1-rt linux-yocto content. This will be
the new LTSI kernel. Deletion of 3.14 and 3.19 will follow once
all machines have been moved forward.

  - libc-headers updated to match the 4.1 kernel version.

And the one that could cause some issues/compatibility issues is the
split of the kernel configuration data from the kernel tree itself.

From the commit log:

  The linux-yocto tree has always been a combined set of kernel changes
  and configuration (meta) data carried in a single tree. While this
  format is effective at keeping kernel configuration and source
  modifications synchronized, it isn't always obvious to developers on
  how to manipulate the meta data versus the source.

  With this change, we remove the meta data processing from the
  kernel-yocto class and use the external meta-data repository that
  has always been used to seed the linux-yocto meta branch.

  After this change, linux-yocto can no longer process combined trees,
  and is simplified as a result.

I'm interested to find out if we get any breakages or severe compability
issues with the change. I don't want to support both variants of the
meta data (in and out of tree), since the goal is to reduce complexity
in the code. Once this change lands, I'll further streamline things.

I've built core-image-kernel-dev and boot tested the qemu* machines.
qemuppc continues to show a boot failure with systemd, but we have a
bugzilla to track that.

I'm now doing graphical testing, but wanted to get this out and soaking
for other images types while I wait for builds to churn.

Cheers,

Bruce

The following changes since commit 0f8d89ce66cfffccc9911d6c61470a585173b79d:

  core-image-lsb-sdk: use kernel-devsrc to ensure kernel module builds work 
(2015-07-20 10:40:42 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (4):
  linux-yocto: split meta data from kernel repository
  kern-tools: standalone tree configuration
  linux-libc-headers: update to 4.1
  linux-yocto: introduce 4.1 versioned recipes

 meta/classes/kernel-yocto.bbclass  | 76 ++
 meta/conf/distro/include/tcmode-default.inc|  2 +-
 .../kern-tools/kern-tools-native_git.bb|  2 +-
 .../linux-libc-headers/linux-libc-headers.inc  |  2 +
 .../linux-libc-headers/linux-libc-headers_3.19.bb  |  7 --
 .../linux-libc-headers/linux-libc-headers_4.1.bb   |  7 ++
 meta/recipes-kernel/linux/linux-yocto-dev.bb   |  5 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb   |  7 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb| 26 
 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |  7 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb |  7 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb  | 23 +++
 meta/recipes-kernel/linux/linux-yocto_3.14.bb  |  7 +-
 meta/recipes-kernel/linux/linux-yocto_3.19.bb  |  7 +-
 meta/recipes-kernel/linux/linux-yocto_4.1.bb   | 41 
 15 files changed, 129 insertions(+), 97 deletions(-)
 delete mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb
 create mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.1.bb

-- 
2.1.0

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

[OE-core] [PATCH 4/4] linux-yocto: introduce 4.1 versioned recipes

2015-07-21 Thread Bruce Ashfield 
Updating the linux-yocto kernel recipes to include a named/versioned 4.1
recipe. This will be the LTSI kernel, and the 3.14 and 3.19 kernels will
be removed in subsequent commites (once reference boards have transitioned).

Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   | 26 ++
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 23 +
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 41 +++
 3 files changed, 90 insertions(+)
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.1.bb

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
new file mode 100644
index ..1cefff871440
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -0,0 +1,26 @@
+KBRANCH ?= standard/preempt-rt
+
+require recipes-kernel/linux/linux-yocto.inc
+
+SRCREV_machine ?= fe1ee443489d4ab5ce04c903b0362ae565547bd1
+SRCREV_meta ?= 45393dd54f5ad77d43014c407c2b3520da42f427
+
+SRC_URI = 
git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \
+   
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}
+
+LINUX_VERSION ?= 4.1.2
+
+PV = ${LINUX_VERSION}+git${SRCPV}
+
+KMETA = kernel-meta
+KCONF_BSP_AUDIT_LEVEL = 2
+
+LINUX_KERNEL_TYPE = preempt-rt
+
+COMPATIBLE_MACHINE = (qemux86|qemux86-64|qemuarm|qemuppc|qemumips)
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc
+KERNEL_FEATURES_append =  ${KERNEL_EXTRA_FEATURES}
+KERNEL_FEATURES_append_qemux86= cfg/sound.scc cfg/paravirt_kvm.scc
+KERNEL_FEATURES_append_qemux86-64= cfg/sound.scc
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
new file mode 100644
index ..38167cc2e85e
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -0,0 +1,23 @@
+KBRANCH ?= standard/tiny/base
+LINUX_KERNEL_TYPE = tiny
+KCONFIG_MODE = --allnoconfig
+
+require recipes-kernel/linux/linux-yocto.inc
+
+LINUX_VERSION ?= 4.1.2
+
+KMETA = kernel-meta
+KCONF_BSP_AUDIT_LEVEL = 2
+
+SRCREV_machine ?= 4e30e64c44df9e59bd13239951bb8d2b5b276e6f
+SRCREV_meta ?= 45393dd54f5ad77d43014c407c2b3520da42f427
+
+PV = ${LINUX_VERSION}+git${SRCPV}
+
+SRC_URI = 
git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \
+   
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}
+
+COMPATIBLE_MACHINE = (qemux86)
+
+# Functionality flags
+KERNEL_FEATURES = 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
new file mode 100644
index ..a7a52cb62762
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -0,0 +1,41 @@
+KBRANCH ?= standard/base
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# board specific branches
+KBRANCH_qemuarm  ?= standard/arm-versatile-926ejs
+KBRANCH_qemuarm64 ?= standard/qemuarm64
+KBRANCH_qemumips ?= standard/mti-malta32
+KBRANCH_qemuppc  ?= standard/qemuppc
+KBRANCH_qemux86  ?= standard/base
+KBRANCH_qemux86-64 ?= standard/base
+KBRANCH_qemumips64 ?= standard/mti-malta64
+
+SRCREV_machine_qemuarm ?= c4df99c91fc947afb7010a11eceeef0e05bf964f
+SRCREV_machine_qemuarm64 ?= 4e30e64c44df9e59bd13239951bb8d2b5b276e6f
+SRCREV_machine_qemumips ?= 6a24f7e60b9b2ecc1579f5f767be5845086533e1
+SRCREV_machine_qemuppc ?= 4e30e64c44df9e59bd13239951bb8d2b5b276e6f
+SRCREV_machine_qemux86 ?= 4e30e64c44df9e59bd13239951bb8d2b5b276e6f
+SRCREV_machine_qemux86-64 ?= 4e30e64c44df9e59bd13239951bb8d2b5b276e6f
+SRCREV_machine_qemumips64 ?= 5c2b3697082a4ec6641aa5a8eca3974ca609cecf
+SRCREV_machine ?= 4e30e64c44df9e59bd13239951bb8d2b5b276e6f
+SRCREV_meta ?= 45393dd54f5ad77d43014c407c2b3520da42f427
+
+SRC_URI = 
git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; 
\
+   
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}
+
+LINUX_VERSION ?= 4.1.2
+
+PV = ${LINUX_VERSION}+git${SRCPV}
+
+KMETA = kernel-meta
+KCONF_BSP_AUDIT_LEVEL = 2
+
+COMPATIBLE_MACHINE = 
qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= features/netfilter/netfilter.scc
+KERNEL_FEATURES_append =  ${KERNEL_EXTRA_FEATURES}
+KERNEL_FEATURES_append_qemux86= cfg/sound.scc cfg/paravirt_kvm.scc
+KERNEL_FEATURES_append_qemux86-64= cfg/sound.scc cfg/paravirt_kvm.scc
+KERNEL_FEATURES_append =  ${@bb.utils.contains(TUNE_FEATURES, mx32,  
cfg/x32.scc,  ,d)}
-- 
2.1.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32

2015-07-21 Thread Mark Hatle 
On 7/21/15 9:31 AM, Mark Hatle wrote:
 On 7/21/15 3:23 AM, Dmitry Eremin-Solenikov wrote:
 Hello,

 2015-07-20 18:47 GMT+03:00 Mark Hatle mark.ha...@windriver.com:
 Between customer escalations, other work and vacation.. I didn't happen.

 No problem, really. I just wanted to be sure that the patches aren't going
 to be lost.


 I've started testing it this morning and should have results tomorrow.. (US 
 time).

 Thank you very much!
 
 With master and the four patches I got an error trying to construct the SDK.
 
 I'm still investigating the error:
 
 Collected errors:
  * satisfy_dependencies_for: Cannot satisfy the following dependencies for
 packagegroup-cross-canadian-qemumips64:
  *  gcc-cross-canadian-mips *   binutils-cross-canadian-mips *
 gdb-cross-canadian-mips *
  * opkg_install_cmd: Cannot install package 
 packagegroup-cross-canadian-qemumips64.
 
 
 My configuration for this particular test was:
 
 (oe-init-build-env stock w/ the following changes)

I've narrowed down the reproducer to just:

MACHINE = qemumips64
require conf/multilib.conf
DEFAULTTUNE = mips64-n32
MULTILIBS = 

(If you remove the require conf/multilib.conf then things work.)

I'm going to continue to investigate.

--Mark

 MACHINE = qemumips64
 
 require conf/multilib.conf
 DEFAULTTUNE = mips64-n32
 MULTILIBS = multilib:lib64 multilib:lib32
 DEFAULTTUNE_virtclass-multilib-lib64 = mips64
 DEFAULTTUNE_virtclass-multilib-lib32 = mips32r2
 
 # Set RPM_PREFER_ELF_ARCH to configure preferred ABI when using rpm packaging
 # backend to generate a rootfs, choices are:
 # 1: ELF32 wins
 # 2: ELF64 wins
 # 4: ELF64 N32 wins (for mips64 or mips64el only)
 RPM_PREFER_ELF_ARCH = 4
 
 

 --Mark

 On 7/20/15 7:11 AM, Dmitry Eremin-Solenikov wrote:
 2015-07-08 15:42 GMT+03:00 Mark Hatle mark.ha...@windriver.com:
 On 7/8/15 7:00 AM, Dmitry Eremin-Solenikov wrote:
 Hello,

 2015-07-01 17:02 GMT+03:00 Dmitry Eremin-Solenikov 
 dbarysh...@gmail.com:
 Quite simple configuration (MIPS64 N32 image) fails to build (see 
 below).
 I have verified these patches in both single lib and in multilib cases.
 Tri-lib images and SDK for MIPS build fine with these patches.

 Any comments on this patchset? It would be nice to have N32 ubroken in
 the current
 master tree.

 Sorry, I'm traveling right now and haven't had time to review this.  I 
 should be
 able to get back to the office and test it by the end of the week.

 I visually reviewed the patches and I don't object to them going in -- 
 but I'm
 still not sure they are all correct.

 Re-ping. I'd like to receive a confirmation from you (and thus get the
 patches merged)
 or to discuss, what seems wrong to you.


 --Mark


 Current situation:

 lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base
 NOTE: Started PRServer with DBfile:
 /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID:
 15895
 Loading cache: 100%
 ||
 ETA:  00:00:00
 Loaded 1302 entries from dependency cache.
 NOTE: Resolving any missing task queue dependencies
 ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but
 /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
 RDEPENDS on or otherwise requires it)
 NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable,
 removing...
 Missing or unbuildable dependency chain was: 
 ['binutils-cross-canadian-mips64']
 NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is
 unbuildable, removing...
 Missing or unbuildable dependency chain was:
 ['packagegroup-cross-canadian-qemumips64n32',
 'binutils-cross-canadian-mips64']
 ERROR: Required build target 'core-image-base' has no buildable 
 providers.
 Missing or unbuildable dependency chain was: ['core-image-base',
 'packagegroup-cross-canadian-qemumips64n32',
 'binutils-cross-canadian-mips64']












 

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

Re: [OE-core] [PATCH v2 1/2] kernel: Define KERNEL_IMAGETYPE as a list

2015-07-21 Thread He Zhe 
On 07/21/2015 10:53 PM, Christopher Larson wrote:

 On Tue, Jul 21, 2015 at 12:23 AM, zhe...@windriver.com 
 mailto:zhe...@windriver.comwrote:

 From: He Zhe zhe...@windriver.com mailto:zhe...@windriver.com

 To support building packaging and installing multi types of kernel
 images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
 as a list.
 Modify wherever reference KERNEL_IMAGETYPE accordingly.

 Fixes [YOCTO #6945].

 Signed-off-by: He Zhe zhe...@windriver.com mailto:zhe...@windriver.com


 Question, why not add KERNEL_IMAGETYPES, and make KERNEL_IMAGETYPE equal to 
 your new KERNEL_IMAGETYPE_0?

Adding a new KERNEL_IMAGETYPES will also work. But it should be better not to 
change the name of KERNEL_IMAGETYPE, so that those who have used it don't have 
to change their code.

Thank you for reviewing.

Zhe

 -- 
 Christopher Larson
 clarson at kergoth dot com
 Founder - BitBake, OpenEmbedded, OpenZaurus
 Maintainer - Tslib
 Senior Software Engineer, Mentor Graphics

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

[OE-core] [PATCH] mesa: fix sed for MESA_EGL_NO_X11_HEADERS in fido

2015-07-21 Thread Tobias Olausson 
In 10.4 versions of mesa, the check for MESA_EGL_NO_X11_HEADERS uses an #ifdef,
not an #if define().

Also, this backports commit 9c746017af381884cc20c7cd563fc429c2c66112
to fido from master.

Signed-off-by: Tobias Olausson tobias.olaus...@pelagicore.com
---
 meta/recipes-graphics/mesa/mesa_10.4.4.bb | 2 +-
 meta/recipes-graphics/mesa/mesa_git.bb| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa_10.4.4.bb 
b/meta/recipes-graphics/mesa/mesa_10.4.4.bb
index 90cccbe..a5f510d 100644
--- a/meta/recipes-graphics/mesa/mesa_10.4.4.bb
+++ b/meta/recipes-graphics/mesa/mesa_10.4.4.bb
@@ -11,6 +11,6 @@ S = ${WORKDIR}/Mesa-${PV}
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
 do_install_append() {
 if ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)}; then
-sed -i -e 's/^#if defined(MESA_EGL_NO_X11_HEADERS)/#if 
${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' 
${D}${includedir}/EGL/eglplatform.h
+sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if 
defined(MESA_EGL_NO_X11_HEADERS) || ${@bb.utils.contains('PACKAGECONFIG', 
'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h
 fi
 }
diff --git a/meta/recipes-graphics/mesa/mesa_git.bb 
b/meta/recipes-graphics/mesa/mesa_git.bb
index 1598019..269ae1e 100644
--- a/meta/recipes-graphics/mesa/mesa_git.bb
+++ b/meta/recipes-graphics/mesa/mesa_git.bb
@@ -13,6 +13,6 @@ S = ${WORKDIR}/git
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
 do_install_append() {
 if ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)}; then
-sed -i -e 's/^#if defined(MESA_EGL_NO_X11_HEADERS)/#if 
${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' 
${D}${includedir}/EGL/eglplatform.h
+sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if 
defined(MESA_EGL_NO_X11_HEADERS) || ${@bb.utils.contains('PACKAGECONFIG', 
'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h
 fi
 }
-- 
2.1.4

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

[OE-core] [oe-core][PATCH 1/1] common-glibc: define bash_cv_getcwd_malloc

2015-07-21 Thread Joe Slater 
We do not want bash to use internal code for getcwd() because
it can fail in certain filesystem types.  Trust that the function
in glibc is not broken.

Signed-off-by: Joe Slater jsla...@windriver.com
---
 meta/site/common-glibc |1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/site/common-glibc b/meta/site/common-glibc
index 8329bb3..1443f8e 100644
--- a/meta/site/common-glibc
+++ b/meta/site/common-glibc
@@ -18,6 +18,7 @@ ac_cv_func_getaddrinfo=${ac_cv_func_getaddrinfo=yes}
 # bash
 bash_cv_under_sys_siglist=${bash_cv_under_sys_siglist=yes}
 bash_cv_sys_siglist=${bash_cv_sys_siglist=yes}
+bash_cv_getcwd_malloc=${bash_cv_getcwd_malloc=yes}
 
 # clamav
 
clamav_av_func_working_snprintf_long=${clamav_av_func_working_snprintf_long=yes}
-- 
1.7.9.5

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

Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32

2015-07-21 Thread Dmitry Eremin-Solenikov 
Hello,

2015-07-20 18:47 GMT+03:00 Mark Hatle mark.ha...@windriver.com:
 Between customer escalations, other work and vacation.. I didn't happen.

No problem, really. I just wanted to be sure that the patches aren't going
to be lost.


 I've started testing it this morning and should have results tomorrow.. (US 
 time).

Thank you very much!


 --Mark

 On 7/20/15 7:11 AM, Dmitry Eremin-Solenikov wrote:
 2015-07-08 15:42 GMT+03:00 Mark Hatle mark.ha...@windriver.com:
 On 7/8/15 7:00 AM, Dmitry Eremin-Solenikov wrote:
 Hello,

 2015-07-01 17:02 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com:
 Quite simple configuration (MIPS64 N32 image) fails to build (see below).
 I have verified these patches in both single lib and in multilib cases.
 Tri-lib images and SDK for MIPS build fine with these patches.

 Any comments on this patchset? It would be nice to have N32 ubroken in
 the current
 master tree.

 Sorry, I'm traveling right now and haven't had time to review this.  I 
 should be
 able to get back to the office and test it by the end of the week.

 I visually reviewed the patches and I don't object to them going in -- but 
 I'm
 still not sure they are all correct.

 Re-ping. I'd like to receive a confirmation from you (and thus get the
 patches merged)
 or to discuss, what seems wrong to you.


 --Mark


 Current situation:

 lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base
 NOTE: Started PRServer with DBfile:
 /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID:
 15895
 Loading cache: 100%
 ||
 ETA:  00:00:00
 Loaded 1302 entries from dependency cache.
 NOTE: Resolving any missing task queue dependencies
 ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but
 /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
 RDEPENDS on or otherwise requires it)
 NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable,
 removing...
 Missing or unbuildable dependency chain was: 
 ['binutils-cross-canadian-mips64']
 NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is
 unbuildable, removing...
 Missing or unbuildable dependency chain was:
 ['packagegroup-cross-canadian-qemumips64n32',
 'binutils-cross-canadian-mips64']
 ERROR: Required build target 'core-image-base' has no buildable providers.
 Missing or unbuildable dependency chain was: ['core-image-base',
 'packagegroup-cross-canadian-qemumips64n32',
 'binutils-cross-canadian-mips64']












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

Re: [OE-core] dbus-test no longer built for dbus-ptest after last bitbake changes

2015-07-21 Thread Richard Purdie 
On Fri, 2015-07-17 at 13:01 +0100, Richard Purdie wrote:
 On Thu, 2015-07-16 at 23:22 +0100, Burton, Ross wrote:
  
  On 16 July 2015 at 22:29, Martin Jansa martin.ja...@gmail.com wrote:
  ERROR: Nothing PROVIDES 'gtk+-native' (but
  
  virtual:native:/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/libwmf/libwmf_0.2.8.4.bb
   DEPENDS on or otherwise requires it). Close matches:
 
  So libwmf does this:
 
  DEPENDS_virtclass-native = freetype-native libpng-native jpeg-native
  DEPENDS = freetype libpng jpeg expat gtk+
 
  Interestingly changing this to _class-native fixes the problem.
 
 Strangely, the answer as to what might be wrong occurred to me in the
 shower this morning. We should try changing:
 
 native.bbclass:e.data.setVar(OVERRIDES, e.data.getVar(OVERRIDES, 
 False) + :virtclass-native)
 
 to
 
 e.data.setVar(FOO, virtclass-native)
 e.data.setVar(OVERRIDES, e.data.getVar(OVERRIDES, False) + :${FOO})
 
 and if that makes things work, its the override caching mechanism that
 is bust for direct changes to OVERRIDES which don't use variable
 indirection (most do).
 
 If that is the case, a fix shouldn't be hard.

Its actually much simpler than this. DEPENDS is evaluated in
native_virtclass_handler(e):28 [map_dependencies] which is before
virtclass-native is added to OVERRIDES. The act of setting the DEPENDS
variable wipes out any other overrides which may not have been applied
to that point. The fixes are:

a) Move the virtclass-native addition to OVERRIDES to earlier in the
function
b) Change meta-oe use of virtclass - class
c) Drop use of virtclass-native and virtclass-nativesdk entirely (only
multilib really makes sense now).

Cheers,

Richard



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

Re: [OE-core] [PATCH 5/5] file: 5.23 - 5.24

2015-07-21 Thread Burton, Ross 
On 17 July 2015 at 03:31, Robert Yang liezhi.y...@windriver.com wrote:

 * Use git repo rather than tarball, rename file_5.23.bb - file_git.bb


Why?

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

Re: [OE-core] [PATCH] mesa: respect MESA_EGL_NO_X11_HEADERS even with x11 in PACKAGECONFIG

2015-07-21 Thread Burton, Ross 
On 20 July 2015 at 22:27, Tobias Olausson tobias.olaus...@pelagicore.com
wrote:

 I like this patch. I would like a similar patch to be made available in
 the fido branch, but changing #if defined() to #ifdef The defines seems
 to have been changed between mesa 10.4 and 10.5, so the current patch only
 works for 10.5 - in 10.4 ifdef is used instead so the sed does nothing.
 Should I submit another patch for that?


Yes, please do.

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

[OE-core] [PATCH] gtk+: require either x11 or directfb DISTRO_FEATURES to be set

2015-07-21 Thread Ross Burton 
GTK+ needs either X11 or DirectFB, and fails with obscure errors if neither are 
present.

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

diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
index 1c0558c..be5273d 100644
--- a/meta/recipes-gnome/gtk+/gtk+.inc
+++ b/meta/recipes-gnome/gtk+/gtk+.inc
@@ -10,6 +10,9 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7
 
 SECTION = libs
 
+inherit distro_features_check
+ANY_OF_DISTRO_FEATURES = directfb x11
+
 X11DEPENDS = virtual/libx11 libxext libxcursor libxrandr libxdamage 
libxrender libxcomposite
 DEPENDS = glib-2.0 pango atk jpeg libpng gdk-pixbuf-native 
docbook-utils-native \
  cairo gdk-pixbuf
-- 
2.1.4

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

Re: [OE-core] dbus-test no longer built for dbus-ptest after last bitbake changes

2015-07-21 Thread Richard Purdie 
On Tue, 2015-07-14 at 16:21 +0200, Martin Jansa wrote:
 I'm not 100% sure it's related to recent bitbake variable expansion
 changes, but my recent builds are failing with errors about
 dbus-ptest cannot be installed because dbus-test-ptest doesn't exist
 
 ERROR: 
 Collected errors:
 
  * satisfy_dependencies_for: Cannot satisfy the following dependencies
  * for dbus-ptest:
 
  *dbus-test-ptest * 
 
  * opkg_install_cmd: Cannot install package dbus-ptest.
 
 It's using a bit strange construct to add it to RDEPENDS:
 meta/recipes-core/dbus/dbus.inc:RDEPENDS_dbus-ptest_class-target =
 dbus-test-ptest
 
 but checking cooker log shows that dbus-test
 (meta/recipes-core/dbus/dbus-test_1.8.18.bb) wasn't built at all, only
 dbus-test message is from opkg error and this QA error from dbus itself:
 
 NOTE: recipe dbus-1.8.18-r0: task do_package_write_ipk: Started
 WARNING: QA Issue: dbus-ptest rdepends on dbus-test-ptest, but it isn't
 a build dependency? [build-deps]
 
 Any ideas?

I've confirmed this is a bug in the bitbake data store changes. The fix
is to replace a copy.copy() with a copy.deepcopy(). I'll sort out
patches as soon as I can although I'm travelling a bit this week. Also
need to write a testcase for it.

Cheers,

Richard

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

[OE-core] [PATCH v3] mesa-demos: Fix building demos which require GLU.

2015-07-21 Thread Drew Moseley 
Set glu_enabled when pkg-config detects GLU.  This is needed so
that HAVE_GLU is properly set to enable the GLU based demos.

Signed-off-by: Drew Moseley drew_mose...@mentor.com
---
 .../0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-graphics/mesa/mesa-demos/0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch
 
b/meta/recipes-graphics/mesa/mesa-demos/0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch
index 4b07193..6b58c2b 100644
--- 
a/meta/recipes-graphics/mesa/mesa-demos/0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch
+++ 
b/meta/recipes-graphics/mesa/mesa-demos/0003-configure-Allow-to-disable-demos-which-require-GLEW-.patch
@@ -66,7 +66,7 @@ index 9445424..bc4c8d1 100644
 -DEMO_CFLAGS=$DEMO_CFLAGS $GLU_CFLAGS
 -DEMO_LIBS=$DEMO_LIBS $GLU_LIBS
 +if test x$enable_glu = xyes; then
-+PKG_CHECK_MODULES(GLU, [glu], [],
++PKG_CHECK_MODULES(GLU, [glu], [glu_enabled=yes],
 + [AC_CHECK_HEADER([GL/glu.h],
 +  [],
 +  AC_MSG_ERROR([GLU not found]))
-- 
1.9.1

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

[OE-core] [PATCH] native: Move virtclass override to earlier so DEPENDS is handled correctly

2015-07-21 Thread Richard Purdie 
Currently the virtclass override is added too late to be taken into
account when DEPENDS and other variables are processed by the virtclass
extension code. This sets the overrides in a more optimal place, meaning
they are accounted for in variables like DEPENDS.

Recipes in meta-oe like libwmf-native showed the issue.

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

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 71b0572..bcbcd61 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -142,6 +142,8 @@ python native_virtclass_handler () {
 newdeps.append(dep)
 d.setVar(varname,  .join(newdeps))
 
+e.data.setVar(OVERRIDES, e.data.getVar(OVERRIDES, False) + 
:virtclass-native)
+
 map_dependencies(DEPENDS, e.data)
 for pkg in [e.data.getVar(PN, True), , ${PN}]:
 map_dependencies(RDEPENDS, e.data, pkg)
@@ -161,7 +163,7 @@ python native_virtclass_handler () {
 nprovides.append(prov)
 e.data.setVar(PROVIDES, ' '.join(nprovides))
 
-e.data.setVar(OVERRIDES, e.data.getVar(OVERRIDES, False) + 
:virtclass-native)
+
 }
 
 addhandler native_virtclass_handler


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

[OE-core] [PATCH] gtk+3: fix Wayland-only builds

2015-07-21 Thread Ross Burton 
When configured with just the Wayland backend (no X11), not enough
Pango headers were included.

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

diff --git a/meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch 
b/meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch
new file mode 100644
index 000..1d6f12b
--- /dev/null
+++ b/meta/recipes-gnome/gtk+/gtk+3/wayland-pango.patch
@@ -0,0 +1,28 @@
+Upstream-Status: Backport
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+From 802b006b3768ddc8c8cdf0af27428e7042c36509 Mon Sep 17 00:00:00 2001
+From: nick oavc-fu...@yandex.com
+Date: Mon, 29 Jun 2015 20:37:26 +0100
+Subject: settings: Include pangofc-fontmap.h header on Wayland
+
+In case the X11 backend is not enabled, we still need to include the
+pangofc-fontmap.h header file, as we use the Pango/FontConfig API in
+both the X11 and Wayland case.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=751625
+
+diff --git a/gtk/gtksettings.c b/gtk/gtksettings.c
+index 327faf5..a40cb84 100644
+--- a/gtk/gtksettings.c
 b/gtk/gtksettings.c
+@@ -41,6 +41,7 @@
+ 
+ #ifdef GDK_WINDOWING_WAYLAND
+ #include wayland/gdkwayland.h
++#include pango/pangofc-fontmap.h
+ #endif
+ 
+ #ifdef GDK_WINDOWING_BROADWAY
+-- 
+cgit v0.10.2
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.16.4.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.16.4.bb
index 3a45afc..4bb6b0c 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.16.4.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.16.4.bb
@@ -5,6 +5,7 @@ MAJ_VER = ${@oe.utils.trim_version(${PV}, 2)}
 SRC_URI = 
http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz \
file://hardcoded_libtool.patch \
file://Dont-force-csd.patch \
+   file://wayland-pango.patch \
   
 
 SRC_URI[md5sum] = c7497aaf6730524a127597b768a73bd7
-- 
2.1.4

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

[OE-core] [meta-oe][dizzy][PATCH] cherry picked from master branch to dizzy branch

2015-07-21 Thread chia . chuan . wu 
From: WU CHIA CHUAN chia.chuan...@intel.com

Dear maintainer,

This patch provided libxml2-python package which is widely used.

Currently this patch only limited to master branch,please consider to

bring this patch to dizzy branch as well.

Thank you,
Chia Chuan

Robert Yang (1):
  libxml2: fix python path and add libxml2-python

 meta/recipes-core/libxml/libxml2.inc |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

-- 
1.7.9.5

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

[OE-core] [meta-oe][dizzy][PATCH] libxml2: fix python path and add libxml2-python

2015-07-21 Thread chia . chuan . wu 
From: Robert Yang liezhi.y...@windriver.com

We have libxml2-python for native and nativesdk, but don't have it for
target, and can't find the reason from the git log, libxml2-python is
widely used, after looked into it's configure.in, we can add it
by PACKAGECONFIG.

The previous --with-python=${STAGING_BINDIR}/python is incorrect, it
acted as work becase it's conigure can check automatically, python is in
${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}, as known as
${PYTHON}.

Add python to PACKAGECONFIG, since createrepo rdepends on
libxml2-python, otherwise the target createrepo can't work.

(From OE-Core rev: ed72e123724599e70eb4d283f06fca3e56a8b50a)

Signed-off-by: Robert Yang liezhi.y...@windriver.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
(cherry picked from commit 212d9d4245cef2343f21d65fa1ee7cfd537432a3)

Signed-off-by: WU CHIA CHUAN chia.chuan...@intel.com
---
 meta/recipes-core/libxml/libxml2.inc |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-core/libxml/libxml2.inc 
b/meta/recipes-core/libxml/libxml2.inc
index c729c19..6f01128 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -9,8 +9,6 @@ LIC_FILES_CHKSUM = 
file://Copyright;md5=2044417e2e5006b65a8b9067b683fcf1 \
 
file://list.c;beginline=4;endline=13;md5=cdbfa3dee51c099edb04e39f762ee907 \
 
file://trio.c;beginline=5;endline=14;md5=6c025753c86d958722ec76e94cae932e
 
-DEPENDS_class-nativesdk = nativesdk-python
-DEPENDS_class-native = python-native
 DEPENDS =+ zlib
 
 SRC_URI = ftp://xmlsoft.org/libxml2/libxml2-${PV}.tar.gz;name=libtar \
@@ -30,6 +28,8 @@ inherit autotools pkgconfig binconfig-disabled pythonnative 
ptest
 
 RDEPENDS_${PN}-ptest += python-core
 
+RDEPENDS_${PN}-python += python-core
+
 RDEPENDS_${PN}-ptest_append_libc-glibc += glibc-gconv-ebcdic-us 
glibc-gconv-ibm1141
 
 # We don't DEPEND on binutils for ansidecl.h so ensure we don't use the header
@@ -37,16 +37,16 @@ do_configure_prepend () {
sed -i -e '/.*ansidecl.h.*/d' ${S}/configure.in
 }
 
-do_configure_prepend_class-nativesdk () {
-   # Ensure we get the correct site-packages path
-   export PYTHON_SITE_PACKAGES=${PYTHON_SITEPACKAGES_DIR}
-}
+export PYTHON_SITE_PACKAGES=${PYTHON_SITEPACKAGES_DIR}
+
+PACKAGECONFIG ??= python
 
+PACKAGECONFIG[python] = --with-python=${PYTHON},--without-python,python
 # WARNING: zlib is require for RPM use
-EXTRA_OECONF = --without-python --without-debug --without-legacy 
--with-catalog --without-docbook --with-c14n --without-lzma --with-fexceptions
-EXTRA_OECONF_class-native = --with-python=${STAGING_BINDIR}/python 
--without-legacy --without-docbook --with-c14n --without-lzma --with-zlib
-EXTRA_OECONF_class-nativesdk = --with-python=${STAGING_BINDIR}/python 
--without-legacy --without-docbook --with-c14n --without-lzma --with-zlib
-EXTRA_OECONF_linuxstdbase = --without-python --with-debug --with-legacy 
--with-docbook --with-c14n --without-lzma --with-zlib
+EXTRA_OECONF = --without-debug --without-legacy --with-catalog 
--without-docbook --with-c14n --without-lzma --with-fexceptions
+EXTRA_OECONF_class-native = --without-legacy --without-docbook --with-c14n 
--without-lzma --with-zlib
+EXTRA_OECONF_class-nativesdk = --without-legacy --without-docbook --with-c14n 
--without-lzma --with-zlib
+EXTRA_OECONF_linuxstdbase = --with-debug --with-legacy --with-docbook 
--with-c14n --without-lzma --with-zlib
 
 # required for pythong binding
 export HOST_SYS
-- 
1.7.9.5

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

[OE-core] [PATCH v2 1/2] kernel: Define KERNEL_IMAGETYPE as a list

2015-07-21 Thread zhe.he 
From: He Zhe zhe...@windriver.com

To support building packaging and installing multi types of kernel
images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
as a list.
Modify wherever reference KERNEL_IMAGETYPE accordingly.

Fixes [YOCTO #6945].

Signed-off-by: He Zhe zhe...@windriver.com
---
 meta/classes/image_types.bbclass |   6 +-
 meta/classes/kernel-fitimage.bbclass |  22 +++---
 meta/classes/kernel-grub.bbclass |  47 
 meta/classes/kernel-uimage.bbclass   |  31 +---
 meta/classes/kernel.bbclass  | 125 ++-
 meta/conf/documentation.conf |   2 +-
 meta/lib/oeqa/controllers/masterimage.py |   2 +-
 meta/lib/oeqa/targetcontrol.py   |   2 +-
 meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
 scripts/test-remote-image|   2 +-
 10 files changed, 174 insertions(+), 80 deletions(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 588a474..b04470f 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -4,6 +4,10 @@
 # set this value to 2048 (2MiB alignment).
 IMAGE_ROOTFS_ALIGNMENT ?= 1
 
+python __anonymous () {
+   d.setVar('KERNEL_IMAGETYPE_0', d.getVar('KERNEL_IMAGETYPE', 
True).strip().split(' ')[0])
+}
+
 def imagetypes_getdepends(d):
 def adddep(depstr, deps):
 for i in (depstr or ).split():
@@ -86,7 +90,7 @@ IMAGE_CMD_cpio () {
fi
 }
 
-ELF_KERNEL ?= ${STAGING_DIR_HOST}/usr/src/kernel/${KERNEL_IMAGETYPE}
+ELF_KERNEL ?= ${STAGING_DIR_HOST}/usr/src/kernel/${KERNEL_IMAGETYPE_0}
 ELF_APPEND ?= ramdisk_size=32768 root=/dev/ram0 rw console=
 
 IMAGE_CMD_elf () {
diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 2a56a54..7d097b4 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -1,8 +1,8 @@
 inherit kernel-uboot
 
 python __anonymous () {
-kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
-if kerneltype == 'fitImage':
+kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or 
+if 'fitImage' in kerneltype.strip().split(' '):
 depends = d.getVar(DEPENDS, True)
 depends = %s u-boot-mkimage-native dtc-native % depends
 d.setVar(DEPENDS, depends)
@@ -10,7 +10,11 @@ python __anonymous () {
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
# (at least for now) into the fitImage .
-d.setVar(KERNEL_IMAGETYPE_FOR_MAKE, zImage)
+typeformake = d.getVar(KERNEL_IMAGETYPE_FOR_MAKE, True) or 
+list = typeformake.strip().split(' ')
+if 'fitImage' in list:
+list.remove('fitImage')
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', ' '.join(list))
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
@@ -154,7 +158,7 @@ EOF
 }
 
 do_assemble_fitimage() {
-   if test x${KERNEL_IMAGETYPE} = xfitImage ; then
+   if test x${KERNEL_IMAGETYPE} != x${KERNEL_IMAGETYPE//fitImage/} ; 
then
kernelcount=1
dtbcount=
rm -f fit-image.its
@@ -217,14 +221,14 @@ addtask assemble_fitimage before do_install after 
do_compile
 
 kernel_do_deploy_append() {
# Update deploy directory
-   if test x${KERNEL_IMAGETYPE} = xfitImage ; then
+   if test x${KERNEL_IMAGETYPE} != x${KERNEL_IMAGETYPE//fitImage/} ; 
then
cd ${B}
echo Copying fit-image.its source file...
-   
its_base_name=${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}
-   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
+   its_base_name=fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}
+   its_symlink_name=fitImage-its-${MACHINE}
install -m 0644 fit-image.its ${DEPLOYDIR}/${its_base_name}.its
-   
linux_bin_base_name=${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}
-   linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
+   
linux_bin_base_name=fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}
+   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
install -m 0644 linux.bin 
${DEPLOYDIR}/${linux_bin_base_name}.bin
 
cd ${DEPLOYDIR}
diff --git a/meta/classes/kernel-grub.bbclass b/meta/classes/kernel-grub.bbclass
index a63f482..ceb0fa1 100644
--- a/meta/classes/kernel-grub.bbclass
+++ b/meta/classes/kernel-grub.bbclass
@@ -10,41 +10,44 @@
 #   updates the new kernel as the boot priority.
 #
 
-pkg_preinst_kernel-image_append () {
+python __anonymous () {
+import re
+
+preinst = '''
# Parsing confliction
[ -f $D/boot/grub/menu.list ]  grubcfg=$D/boot/grub/menu.list
[ -f $D/boot/grub/grub.cfg ]  grubcfg=$D/boot/grub/grub.cfg
if [ -n $grubcfg ]; then

[OE-core] [PATCH v2 2/2] kernel: Pass sysroot mkimage to kernel makefile

2015-07-21 Thread zhe.he 
From: He Zhe zhe...@windriver.com

Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
depending on build machine's when KEEPUIMAGE is yes.

Fixes [YOCTO #6945].

Signed-off-by: He Zhe zhe...@windriver.com
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 86ed28f..1d7fa48 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -141,7 +141,7 @@ UBOOT_ENTRYPOINT ?= 20008000
 UBOOT_LOADADDRESS ?= ${UBOOT_ENTRYPOINT}
 
 # Some Linux kernel configurations need additional parameters on the command 
line
-KERNEL_EXTRA_ARGS ?= 
+KERNEL_EXTRA_ARGS ?= NATIVE_MKIMAGE=${STAGING_BINDIR_NATIVE}/mkimage
 
 # For the kernel, we don't want the '-e MAKEFLAGS=' in EXTRA_OEMAKE.
 # We don't want to override kernel Makefile variables from the environment
-- 
2.1.0

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

[OE-core] [PATCH v2 0/2] Yocto Bug #6945

2015-07-21 Thread zhe.he 
From: He Zhe zhe...@windriver.com

 - To support building packaging and installing multi types of kernel
   images, such as zImage uImage, at one time define KERNEL_IMAGETYPE
   as a list.
 - Modify wherever reference KERNEL_IMAGETYPE accordingly.
 - Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid
   depending on build machine's, when KEEPUIMAGE is yes.
 - v2: update with the latest oe-core

He Zhe (2):
  kernel: Define KERNEL_IMAGETYPE as a list
  kernel: Pass sysroot mkimage to kernel makefile

 meta/classes/image_types.bbclass |   6 +-
 meta/classes/kernel-fitimage.bbclass |  22 +++---
 meta/classes/kernel-grub.bbclass |  47 
 meta/classes/kernel-uimage.bbclass   |  31 +---
 meta/classes/kernel.bbclass  | 127 ++-
 meta/conf/documentation.conf |   2 +-
 meta/lib/oeqa/controllers/masterimage.py |   2 +-
 meta/lib/oeqa/targetcontrol.py   |   2 +-
 meta/recipes-kernel/linux/linux-dtb.inc  |  15 ++--
 scripts/test-remote-image|   2 +-
 10 files changed, 175 insertions(+), 81 deletions(-)

-- 
2.1.0

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

[OE-core] [PATCH] oeqa/selftest: Fix imagefeature testcases not to interfere with testimage on AB

2015-07-21 Thread Daniel Istrate 
[YOCTO #8017] - selftest does not use pkill qemu
[YOCTO #7976] - tests do not touch .ssh/known_hosts
  - don't hardcode qemu IP
[YOCTO #8027] - use qemu nographic
Extra: removed unnecessary assert for bitbake and runCmd status

Signed-off-by: Daniel Istrate daniel.alexandrux.istr...@intel.com
---
 meta/lib/oeqa/selftest/imagefeatures.py | 148 +++-
 1 file changed, 48 insertions(+), 100 deletions(-)

diff --git a/meta/lib/oeqa/selftest/imagefeatures.py 
b/meta/lib/oeqa/selftest/imagefeatures.py
index e0e424d..70ebbe4 100644
--- a/meta/lib/oeqa/selftest/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/imagefeatures.py
@@ -2,13 +2,20 @@ from oeqa.selftest.base import oeSelfTest
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var
 from oeqa.utils.decorators import testcase
 import pexpect
-from os.path import expanduser, isfile
-from os import system
+from os.path import isfile
+from os import system, killpg
 import glob
+import signal
 
 
 class ImageFeatures(oeSelfTest):
 
+test_user = 'tester'
+root_user = 'root'
+prompt = r'qemux86:\S+[$#]\s+'
+ssh_cmd = ssh {} -l {} -o UserKnownHostsFile=/dev/null -o 
StrictHostKeyChecking=no
+get_ip_patt = r'\s+ip=(?Pqemu_ip(\d+.){3}\d+)::'
+
 @testcase(1107)
 def test_non_root_user_can_connect_via_ssh_without_password(self):
 
@@ -20,69 +27,45 @@ class ImageFeatures(oeSelfTest):
 AutomatedBy: Daniel Istrate daniel.alexandrux.istr...@intel.com
 
 
-test_user = 'tester'
-root_user = 'root'
-prompt = r'qemux86:\S+[$#]\s+'
-tap_inf_ip = '192.168.7.2'
-
 features = 'EXTRA_IMAGE_FEATURES += ssh-server-openssh 
empty-root-password\n'
 features += 'INHERIT += extrausers\n'
-features += 'EXTRA_USERS_PARAMS = useradd -p \'\' {}; usermod -s 
/bin/sh {};'.format(test_user, test_user)
+features += 'EXTRA_USERS_PARAMS = useradd -p \'\' {}; usermod -s 
/bin/sh {};'.format(self.test_user, self.test_user)
 
 # Append 'features' to local.conf
 self.append_config(features)
 
 # Build a core-image-minimal
-ret = bitbake('core-image-minimal')
-self.assertEqual(0, ret.status, 'Failed to build a core-image-minimal')
-
-rm_ssh_keys_cmd = 'ssh-keygen -f {}/.ssh/known_hosts -R 
{}'.format(expanduser('~'), tap_inf_ip)
-# Delete the ssh keys for 192.168.7.2 (qemu)
-ret = runCmd(rm_ssh_keys_cmd)
-self.assertEqual(0, ret.status, 'Failed to delete ssh keys for qemu 
host.')
+bitbake('core-image-minimal')
 
 # Boot qemu image
 proc_qemu = pexpect.spawn('runqemu qemux86 nographic')
 try:
+proc_qemu.expect(self.get_ip_patt, timeout=100)
+qemu_ip = proc_qemu.match.group('qemu_ip')
 proc_qemu.expect('qemux86 login:', timeout=100)
 except:
-system('pkill qemu')
-proc_qemu.close()
+killpg(proc_qemu.pid, signal.SIGTERM)
 self.fail('Failed to start qemu.')
 
 # Attempt to ssh with each user into qemu with empty password
-for user in [root_user, test_user]:
-proc_ssh = pexpect.spawn('ssh {} -l {}'.format(tap_inf_ip, user))
-index = proc_ssh.expect(['Are you sure you want to continue 
connecting', prompt, pexpect.TIMEOUT, pexpect.EOF])
+for user in [self.root_user, self.test_user]:
+proc_ssh = pexpect.spawn(self.ssh_cmd.format(qemu_ip, user))
+index = proc_ssh.expect([self.prompt, pexpect.TIMEOUT, 
pexpect.EOF])
 if index == 0:
-proc_ssh.sendline('yes')
-try:
-proc_ssh.expect(prompt)
-except:
-system('pkill qemu')
-proc_qemu.close()
-proc_ssh.terminate()
-self.fail('Failed to ssh with {} user into 
qemu.'.format(user))
-elif index == 1:
 # user successfully logged in with empty password
 pass
-elif index == 2:
-system('pkill qemu')
-proc_qemu.close()
+elif index == 1:
+killpg(proc_qemu.pid, signal.SIGTERM)
 proc_ssh.terminate()
 self.fail('Failed to ssh with {} user into qemu 
(timeout).'.format(user))
 else:
-system('pkill qemu')
-proc_qemu.close()
+killpg(proc_qemu.pid, signal.SIGTERM)
 proc_ssh.terminate()
 self.fail('Failed to ssh with {} user into qemu 
(eof).'.format(user))
+proc_ssh.terminate()
 
 # Cleanup
-system('pkill qemu')
-proc_qemu.close()
-proc_ssh.terminate()
-ret = runCmd(rm_ssh_keys_cmd)
-self.assertEqual(0, ret.status, 'Failed to delete ssh keys for qemu 
host (at cleanup).')
+killpg(proc_qemu.pid,

Re: [OE-core] [PATCH 0/4] Fix builds for MIPS64 N32

2015-07-21 Thread Mark Hatle 
On 7/21/15 3:23 AM, Dmitry Eremin-Solenikov wrote:
 Hello,
 
 2015-07-20 18:47 GMT+03:00 Mark Hatle mark.ha...@windriver.com:
 Between customer escalations, other work and vacation.. I didn't happen.
 
 No problem, really. I just wanted to be sure that the patches aren't going
 to be lost.
 

 I've started testing it this morning and should have results tomorrow.. (US 
 time).
 
 Thank you very much!

With master and the four patches I got an error trying to construct the SDK.

I'm still investigating the error:

Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for
packagegroup-cross-canadian-qemumips64:
 *  gcc-cross-canadian-mips *   binutils-cross-canadian-mips *
gdb-cross-canadian-mips *
 * opkg_install_cmd: Cannot install package 
packagegroup-cross-canadian-qemumips64.


My configuration for this particular test was:

(oe-init-build-env stock w/ the following changes)

MACHINE = qemumips64

require conf/multilib.conf
DEFAULTTUNE = mips64-n32
MULTILIBS = multilib:lib64 multilib:lib32
DEFAULTTUNE_virtclass-multilib-lib64 = mips64
DEFAULTTUNE_virtclass-multilib-lib32 = mips32r2

# Set RPM_PREFER_ELF_ARCH to configure preferred ABI when using rpm packaging
# backend to generate a rootfs, choices are:
# 1: ELF32 wins
# 2: ELF64 wins
# 4: ELF64 N32 wins (for mips64 or mips64el only)
RPM_PREFER_ELF_ARCH = 4



 --Mark

 On 7/20/15 7:11 AM, Dmitry Eremin-Solenikov wrote:
 2015-07-08 15:42 GMT+03:00 Mark Hatle mark.ha...@windriver.com:
 On 7/8/15 7:00 AM, Dmitry Eremin-Solenikov wrote:
 Hello,

 2015-07-01 17:02 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com:
 Quite simple configuration (MIPS64 N32 image) fails to build (see below).
 I have verified these patches in both single lib and in multilib cases.
 Tri-lib images and SDK for MIPS build fine with these patches.

 Any comments on this patchset? It would be nice to have N32 ubroken in
 the current
 master tree.

 Sorry, I'm traveling right now and haven't had time to review this.  I 
 should be
 able to get back to the office and test it by the end of the week.

 I visually reviewed the patches and I don't object to them going in -- but 
 I'm
 still not sure they are all correct.

 Re-ping. I'd like to receive a confirmation from you (and thus get the
 patches merged)
 or to discuss, what seems wrong to you.


 --Mark


 Current situation:

 lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base
 NOTE: Started PRServer with DBfile:
 /home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID:
 15895
 Loading cache: 100%
 ||
 ETA:  00:00:00
 Loaded 1302 entries from dependency cache.
 NOTE: Resolving any missing task queue dependencies
 ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but
 /home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
 RDEPENDS on or otherwise requires it)
 NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable,
 removing...
 Missing or unbuildable dependency chain was: 
 ['binutils-cross-canadian-mips64']
 NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is
 unbuildable, removing...
 Missing or unbuildable dependency chain was:
 ['packagegroup-cross-canadian-qemumips64n32',
 'binutils-cross-canadian-mips64']
 ERROR: Required build target 'core-image-base' has no buildable 
 providers.
 Missing or unbuildable dependency chain was: ['core-image-base',
 'packagegroup-cross-canadian-qemumips64n32',
 'binutils-cross-canadian-mips64']









 
 
 

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