[OE-core] [PATCH v3][0/2] Yocto Bug #6149

2015-07-23 Thread Jate Sujjavanich
These patches add code to handle a PREFERRED_PROVIDER for a runtime item.

The providers.py code chooses a recipe based on a runtime package to
resolve the multiple providers warning.

Then during package generation, the new image.bbclass code substitutes the
package into PACKAGE_INSTALL that RPROVIDES the runtime item if the
PREFERRED_PROVIDER is defined.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [fido][PATCH 2/2] wic: Make sure file exists before removing it

2015-07-23 Thread Ash Charles
From: Ed Bartosh ed.bart...@linux.intel.com

Bunch of os.remove calls were added to the partition.py lately.
They're causing wic to fail with OSError: [Errno 2] No such file or directory
if file doesn't exist.

Added check for file existence to all recently added calls of
os.remove. That should fix this regression.

Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
 scripts/lib/wic/kickstart/custom_commands/partition.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/scripts/lib/wic/kickstart/custom_commands/partition.py 
b/scripts/lib/wic/kickstart/custom_commands/partition.py
index 654c380..7cfeec4 100644
--- a/scripts/lib/wic/kickstart/custom_commands/partition.py
+++ b/scripts/lib/wic/kickstart/custom_commands/partition.py
@@ -231,7 +231,7 @@ class Wic_PartData(Mic_PartData):
 image_rootfs = rootfs_dir
 rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label ,self.fstype)
 
-os.remove(rootfs)
+os.path.isfile(rootfs) and os.remove(rootfs)
 du_cmd = du -ks %s % image_rootfs
 out = exec_cmd(du_cmd)
 actual_rootfs_size = int(out.split()[0])
@@ -283,7 +283,7 @@ class Wic_PartData(Mic_PartData):
 image_rootfs = rootfs_dir
 rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label, self.fstype)
 
-os.remove(rootfs)
+os.path.isfile(rootfs) and os.remove(rootfs)
 du_cmd = du -ks %s % image_rootfs
 out = exec_cmd(du_cmd)
 actual_rootfs_size = int(out.split()[0])
@@ -328,7 +328,7 @@ class Wic_PartData(Mic_PartData):
 image_rootfs = rootfs_dir
 rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label, self.fstype)
 
-os.remove(rootfs)
+os.path.isfile(rootfs) and os.remove(rootfs)
 du_cmd = du -bks %s % image_rootfs
 out = exec_cmd(du_cmd)
 blocks = int(out.split()[0])
@@ -381,7 +381,7 @@ class Wic_PartData(Mic_PartData):
 image_rootfs = rootfs_dir
 rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label ,self.fstype)
 
-os.remove(rootfs)
+os.path.isfile(rootfs) and os.remove(rootfs)
 squashfs_cmd = mksquashfs %s %s -noappend % \
(image_rootfs, rootfs)
 exec_native_cmd(pseudo + squashfs_cmd, native_sysroot)
@@ -420,7 +420,7 @@ class Wic_PartData(Mic_PartData):
 
 fs = %s/fs_%s.%s % (cr_workdir, self.label, self.fstype)
 
-os.remove(fs)
+os.path.isfile(fs) and os.remove(fs)
 dd_cmd = dd if=/dev/zero of=%s bs=1k seek=%d count=0 % \
 (fs, self.size)
 exec_cmd(dd_cmd)
@@ -448,7 +448,7 @@ class Wic_PartData(Mic_PartData):
 
 fs = %s/fs_%s.%s % (cr_workdir, self.label, self.fstype)
 
-os.remove(fs)
+os.path.isfile(fs) and os.remove(fs)
 dd_cmd = dd if=/dev/zero of=%s bs=1k seek=%d count=0 % \
 (fs, self.size)
 exec_cmd(dd_cmd)
@@ -473,7 +473,7 @@ class Wic_PartData(Mic_PartData):
 Prepare an empty vfat partition.
 
 fs = %s/fs_%s.%s % (cr_workdir, self.label, self.fstype)
-os.remove(fs)
+os.path.isfile(fs) and os.remove(fs)
 
 blocks = self.size
 
@@ -500,7 +500,7 @@ class Wic_PartData(Mic_PartData):
   Proceeding as requested. % self.mountpoint)
 
 fs = %s/fs_%s.%s % (cr_workdir, self.label, self.fstype)
-os.remove(fs)
+os.path.isfile(fs) and os.remove(fs)
 
 # it is not possible to create a squashfs without source data,
 # thus prepare an empty temp dir that is used as source
-- 
2.1.4

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


Re: [OE-core] [meta-oe][PATCH] libical: Upgrade v1.0.0 - v1.0.1

2015-07-23 Thread Burton, Ross
On 23 July 2015 at 12:17, Amarnath Valluri amarnath.vall...@intel.com
wrote:

 - Build system changed from autotools to cmake.
 - Perl dependency added.


We had almost exactly this patch a week or so ago from Cristian (CC'd) who
promptly retracted it with the comment that he hadn't done enough testing.

Cristian, was there something wrong with the 1.0.1 upgrade, or were you
being cautious and the patch is fine?

 SRC_URI = https://github.com/${BPN}/${BPN}/archive/v${PV}.tar.gz;


Until the people at github confirm that tarballs generated with archive/
are static I don't trust them.  Luckily the libical maintainers actually
released a tarball of 1.0.1 so the recipe should use that.

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


Re: [OE-core] [PATCH] libepoxy: Use native python3

2015-07-23 Thread Gary Thomas

On 2015-07-23 17:06, Richard Purdie wrote:

On Thu, 2015-07-23 at 17:00 -0600, Gary Thomas wrote:

It's an old host (Fedora 13) that I am unable to upgrade, but it still
works quite well.  I get around most of the Yocto/bitbake worries by
using a Yocto-built meta-toolchain to fill in the blanks (correct make,
python2, etc), but python3 is not part of the meta-toolchain :-(


You could likely build a customised meta-toolchain which did contain
python3 though?


Do you know how I would make that happen?  For me, meta-toolchain is
a black box - I know very little of the internals.

Question about policy: it seems that a good many native packages
are built, many just to level the playing field.   I just checked
and one of my average builds has 148 native packages sitting there.
For example, why build bison-native when my host's bison is even the
same vintage and hence just as adequate?  Why then, draw the line
over python3 in this one recipe?  (Just asking, I'll figure out how
to fix this anyway)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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


[OE-core] [PATCH v3][2/2] image.bbclass: Add support for runtime PREFERRED_PROVIDER

2015-07-23 Thread Jate Sujjavanich
The following changes since commit 5f248526ae5f15a2e6f3a6da88a96aba976bb28e:

  providers.py: Add support for preferred runtime item (2015-07-23 17:28:31
-0400)

are available in the git repository at:

  https://jate...@github.com/jatedev/poky preferred-provider-runtime-3

for you to fetch changes up to 6ade6807288ad318355bb77e43df87dfc15a9e90:

  image.bbclass: Add support for runtime PREFERRED_PROVIDER (2015-07-23
17:29:04 -0400)


Jate Sujjavanich (1):
  image.bbclass: Add support for runtime PREFERRED_PROVIDER

 meta/classes/image.bbclass |   49

 1 file changed, 49 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 01f8b3f..2276897 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -132,6 +132,25 @@ inherit ${IMAGE_TYPE_live}
 IMAGE_TYPE_vmdk = '${@bb.utils.contains(IMAGE_FSTYPES, vmdk,
image-vmdk, , d)}'
 inherit ${IMAGE_TYPE_vmdk}

+def packageinfo(d):
+import oe.packagedata
+pkginfolist = []
+
+pkgdata_dir = d.getVar(PKGDATA_DIR, True) + '/runtime/'
+if os.path.exists(pkgdata_dir):
+for root, dirs, files in os.walk(pkgdata_dir):
+for pkgname in files:
+if pkgname.endswith('.packaged'):
+pkgname = pkgname[:-9]
+pkgdatafile = root + pkgname
+try:
+sdata =
oe.packagedata.read_pkgdatafile(pkgdatafile)
+sdata['PKG'] = pkgname
+pkginfolist.append(sdata)
+except Exception as e:
+bb.warn(Failed to read pkgdata file %s: %s: %s %
(pkgdatafile, e.__class__, str(e)))
+return pkginfolist
+
 python () {
 deps =   + imagetypes_getdepends(d)
 d.appendVarFlag('do_rootfs', 'depends', deps)
@@ -283,6 +302,36 @@ python rootfs_process_ignore() {
 }
 do_rootfs[prefuncs] += rootfs_process_ignore

+python rootfs_process_prefer() {
+packageinfolist = packageinfo(d)
+
+inst_pkgs = d.getVar(PACKAGE_INSTALL, True).split()
+pref_pkgs = list()
+for pkg in inst_pkgs:
+prefer_var = d.getVar(PREFERRED_PROVIDER_%s % pkg, True)
+if prefer_var:
+bb.note(%s rprovided by recipe %s % (pkg, prefer_var))
+# Find preferred package which provides item
+for p in packageinfolist:
+# First Look for PN and RPROVIDES_${PN}
+if p['PN'] == prefer_var:
+var = 'RPROVIDES_%s' % p['PKG']
+try:
+val = p[var]
+except KeyError:
+continue
+rprovides_split = val.split(' ')
+if pkg in rprovides_split:
+bb.note('%s in %s. Will substitute in
PACKAGE_INSTALL' % (pkg, var))
+inst_pkgs.remove(pkg)
+pref_pkgs.append(p['PKG'])
+inst_pkgs.extend(pref_pkgs)
+for p in inst_pkgs:
+bb.note(%s  % p)
+d.setVar(PACKAGE_INSTALL, ' '.join(inst_pkgs))
+}
+do_rootfs[prefuncs] += rootfs_process_prefer
+
 # We have to delay the runtime_mapping_rename until just before rootfs runs
 # otherwise, the multilib renaming could step in and squash any fixups that
 # may have occurred.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v3][0/2] Yocto Bug #6149

2015-07-23 Thread Richard Purdie
On Thu, 2015-07-23 at 17:32 -0400, Jate Sujjavanich wrote:
 These patches add code to handle a PREFERRED_PROVIDER for a runtime
 item.

 The providers.py code chooses a recipe based on a runtime package to
 resolve the multiple providers warning.

 Then during package generation, the new image.bbclass code substitutes
 the package into PACKAGE_INSTALL that RPROVIDES the runtime item if
 the PREFERRED_PROVIDER is defined.
 
What this doesn't do is fix the problem where one of these names is used
in a packagegroup or some other place than PACKAGE_INSTALL. I believe I
mentioned this the last time you sent patches as well.

Due to that, it would lead to gross inconsistencies in the way the
system would behave and it can't be merged as is, sorry.

Cheers,

Richard
 


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


[OE-core] [PATCH v3] tcf-agent: Update to version 1.3

2015-07-23 Thread Randy Witt
According to the Eclipse tcf team, 1.3 tcf is required for the newest
Eclipse release mars.

[YOCTO #7886]

Signed-off-by: Randy Witt randy.e.w...@linux.intel.com
---
 meta/recipes-devtools/tcf-agent/tcf-agent_git.bb | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb 
b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
index 616a6a7..f8fd390 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -5,11 +5,10 @@ BUGTRACKER = https://bugs.eclipse.org/bugs/;
 LICENSE = EPL-1.0 | EDL-1.0
 LIC_FILES_CHKSUM = file://edl-v10.html;md5=522a390a83dc186513f0500543ad3679
 
-SRCREV = 4ef94ecb927a8912c3d79ce137182247786cff8f
-PV = 0.4.0+git${SRCPV}
-PR = r2
+SRCREV = b9a735e9c7cf82f80d412b7ab15d08b89d5a4ccc
+PV = 1.3.0+git${SRCPV}
 
-SRC_URI = git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git \
+SRC_URI = 
git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git;branch=1.3_mars_bugfix
 \
file://fix_ranlib.patch \
file://tcf-agent.init \
file://tcf-agent.service \
@@ -18,7 +17,7 @@ SRC_URI = 
git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git \
 DEPENDS = util-linux openssl
 RDEPENDS_${PN} = bash
 
-S = ${WORKDIR}/git
+S = ${WORKDIR}/git/agent
 
 inherit update-rc.d systemd
 
@@ -39,10 +38,6 @@ CFLAGS += -DSERVICE_RunControl=0 -DSERVICE_Breakpoints=0 \
 -DSERVICE_StackTrace=0 -DSERVICE_Symbols=0 -DSERVICE_LineNumbers=0 \
 -DSERVICE_Expressions=0
 
-do_compile() {
-   oe_runmake
-}
-
 do_install() {
oe_runmake install INSTALLROOT=${D}
install -d ${D}${sysconfdir}/init.d/
-- 
2.4.3

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


[OE-core] [PATCH 1/5] oeqa/runtime: remove dmesg test

2015-07-23 Thread Ross Burton
This has been obsoleted by parselogs.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/lib/oeqa/runtime/dmesg.py | 12 
 1 file changed, 12 deletions(-)
 delete mode 100644 meta/lib/oeqa/runtime/dmesg.py

diff --git a/meta/lib/oeqa/runtime/dmesg.py b/meta/lib/oeqa/runtime/dmesg.py
deleted file mode 100644
index 5831471..000
--- a/meta/lib/oeqa/runtime/dmesg.py
+++ /dev/null
@@ -1,12 +0,0 @@
-import unittest
-from oeqa.oetest import oeRuntimeTest
-from oeqa.utils.decorators import *
-
-
-class DmesgTest(oeRuntimeTest):
-
-@testcase(215)
-@skipUnlessPassed('test_ssh')
-def test_dmesg(self):
-(status, output) = self.target.run('dmesg | grep -v mmci-pl18x | grep 
-v error changing net interface name | grep -iv dma timeout | grep -v 
usbhid | grep -i error')
-self.assertEqual(status, 1, msg = Error messages in dmesg log: %s % 
output)
-- 
2.1.4

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


[OE-core] [PATCH 2/5] oeqa/runtime/parselogs: add more x86 log exceptions

2015-07-23 Thread Ross Burton
Move fail to add MMCONFIG... to qemux86_common as we started to also see it on
x86-64 with Linux 4.1.

Add can't claim BAR... to qemux86_common.

Generalise Failed to access perfctr MSR as the MSR number can change.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/lib/oeqa/runtime/parselogs.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/runtime/parselogs.py 
b/meta/lib/oeqa/runtime/parselogs.py
index 8d0a1db..ce9c162 100644
--- a/meta/lib/oeqa/runtime/parselogs.py
+++ b/meta/lib/oeqa/runtime/parselogs.py
@@ -46,13 +46,14 @@ x86_common = [
 qemux86_common = [
 'Fast TSC calibration', 
 'wrong ELF class',
+fail to add MMCONFIG information, can't access extended PCI configuration 
space under this bridge.,
+can't claim BAR ,
 ] + common_errors
 
 ignore_errors = { 
 'default' : common_errors,
 'qemux86' : [
-'Failed to access perfctr msr (MSR c1 is 0)',
-fail to add MMCONFIG information, can't access extended PCI 
configuration space under this bridge.,
+'Failed to access perfctr msr (MSR',
 ] + qemux86_common,
 'qemux86-64' : qemux86_common,
 'qemumips' : [
@@ -248,4 +249,4 @@ class ParseLogsTest(oeRuntimeTest):
 self.msg +=  result[str(log)][str(error)]+\n
 self.msg +=  ***\n
 self.msg += %s errors found in logs. % errcount
-self.assertEqual(errcount, 0, msg=self.msg)
\ No newline at end of file
+self.assertEqual(errcount, 0, msg=self.msg)
-- 
2.1.4

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


[OE-core] [PATCH 4/5] oeqa/runtime/parselogs: don't use uname to get MACHINE

2015-07-23 Thread Ross Burton
Instead of running uname -n on the target (which actually returns the
hostname) to get something approximating the hostname (or not, if that has been
overriden), simply fetch MACHINE from the datastore.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/lib/oeqa/runtime/parselogs.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/runtime/parselogs.py 
b/meta/lib/oeqa/runtime/parselogs.py
index ce9c162..ed43510 100644
--- a/meta/lib/oeqa/runtime/parselogs.py
+++ b/meta/lib/oeqa/runtime/parselogs.py
@@ -124,8 +124,7 @@ class ParseLogsTest(oeRuntimeTest):
 self.msg = 
 
 def getMachine(self):
-(status, output) = self.target.run(uname -n)
-return output
+return oeRuntimeTest.tc.d.getVar(MACHINE, True)
 
 #get some information on the CPU of the machine to display at the 
beginning of the output. This info might be useful in some cases.
 def getHardwareInfo(self):
-- 
2.1.4

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


[OE-core] [PATCH 3/5] oeqa/selftest/imagefeatures: handle killpg victim not existing

2015-07-23 Thread Ross Burton
If Pexpect throws an exception it may be because the child has already died, in
which case killpg will fail.  Catch the latter exception silently, and output
the exception from Pexpect.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/lib/oeqa/selftest/imagefeatures.py | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/meta/lib/oeqa/selftest/imagefeatures.py 
b/meta/lib/oeqa/selftest/imagefeatures.py
index 70ebbe4..82ea164 100644
--- a/meta/lib/oeqa/selftest/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/imagefeatures.py
@@ -43,9 +43,12 @@ class ImageFeatures(oeSelfTest):
 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:
-killpg(proc_qemu.pid, signal.SIGTERM)
-self.fail('Failed to start qemu.')
+except Exception as e:
+try:
+killpg(proc_qemu.pid, signal.SIGTERM)
+except:
+pass
+self.fail('Failed to start qemu: %s' % e)
 
 # Attempt to ssh with each user into qemu with empty password
 for user in [self.root_user, self.test_user]:
@@ -93,9 +96,12 @@ class ImageFeatures(oeSelfTest):
 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:
-killpg(proc_qemu.pid, signal.SIGTERM)
-self.fail('Failed to start qemu.')
+except Exception as e:
+try:
+killpg(proc_qemu.pid, signal.SIGTERM)
+except:
+pass
+self.fail('Failed to start qemu: %s' % e)
 
 # Attempt to ssh with each user into qemu with empty password
 for user in [self.root_user, self.test_user]:
@@ -147,9 +153,12 @@ class ImageFeatures(oeSelfTest):
 proc_qemu.expect(self.prompt)
 proc_qemu.sendline('rpm --version')
 proc_qemu.expect(self.prompt)
-except:
-killpg(proc_qemu.pid, signal.SIGTERM)
-self.fail('Failed to boot qemu.')
+except Exception as e:
+try:
+killpg(proc_qemu.pid, signal.SIGTERM)
+except:
+pass
+self.fail('Failed to start qemu: %s' % e)
 
 found_rpm_version = proc_qemu.before
 
-- 
2.1.4

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


[OE-core] [PATCH 5/5] oeqa/qemurunner: don't assume hostname starts with qemu

2015-07-23 Thread Ross Burton
It's possible to customise the hostname trivially so don't assume that the
hostname hasn't been configured.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/lib/oeqa/utils/qemurunner.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index a15990e..59c9934 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -137,7 +137,7 @@ class QemuRunner:
 if data:
 self.log(data)
 self.bootlog += data
-if re.search(qemu.* login:, self.bootlog):
+if re.search(.* login:, self.bootlog):
 stopread = True
 reachedlogin = True
 logging.info(Reached login banner)
-- 
2.1.4

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


[OE-core] [fido][PATCH 1/2] wic: remove intermediate partitions

2015-07-23 Thread Ash Charles
From: Alexandre Belloni alexandre.bell...@free-electrons.com

Remove intermediate partitions that may have been created by a previous
wic invocation. Those partitions are causing issues on some systems. In
particular vfat partition creation is hanging on mcopy execution on
Fedora.

Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
 scripts/lib/wic/kickstart/custom_commands/partition.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/lib/wic/kickstart/custom_commands/partition.py 
b/scripts/lib/wic/kickstart/custom_commands/partition.py
index f3d553b..654c380 100644
--- a/scripts/lib/wic/kickstart/custom_commands/partition.py
+++ b/scripts/lib/wic/kickstart/custom_commands/partition.py
@@ -231,6 +231,7 @@ class Wic_PartData(Mic_PartData):
 image_rootfs = rootfs_dir
 rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label ,self.fstype)
 
+os.remove(rootfs)
 du_cmd = du -ks %s % image_rootfs
 out = exec_cmd(du_cmd)
 actual_rootfs_size = int(out.split()[0])
@@ -282,6 +283,7 @@ class Wic_PartData(Mic_PartData):
 image_rootfs = rootfs_dir
 rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label, self.fstype)
 
+os.remove(rootfs)
 du_cmd = du -ks %s % image_rootfs
 out = exec_cmd(du_cmd)
 actual_rootfs_size = int(out.split()[0])
@@ -326,6 +328,7 @@ class Wic_PartData(Mic_PartData):
 image_rootfs = rootfs_dir
 rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label, self.fstype)
 
+os.remove(rootfs)
 du_cmd = du -bks %s % image_rootfs
 out = exec_cmd(du_cmd)
 blocks = int(out.split()[0])
@@ -378,6 +381,7 @@ class Wic_PartData(Mic_PartData):
 image_rootfs = rootfs_dir
 rootfs = %s/rootfs_%s.%s % (cr_workdir, self.label ,self.fstype)
 
+os.remove(rootfs)
 squashfs_cmd = mksquashfs %s %s -noappend % \
(image_rootfs, rootfs)
 exec_native_cmd(pseudo + squashfs_cmd, native_sysroot)
@@ -416,6 +420,7 @@ class Wic_PartData(Mic_PartData):
 
 fs = %s/fs_%s.%s % (cr_workdir, self.label, self.fstype)
 
+os.remove(fs)
 dd_cmd = dd if=/dev/zero of=%s bs=1k seek=%d count=0 % \
 (fs, self.size)
 exec_cmd(dd_cmd)
@@ -443,6 +448,7 @@ class Wic_PartData(Mic_PartData):
 
 fs = %s/fs_%s.%s % (cr_workdir, self.label, self.fstype)
 
+os.remove(fs)
 dd_cmd = dd if=/dev/zero of=%s bs=1k seek=%d count=0 % \
 (fs, self.size)
 exec_cmd(dd_cmd)
@@ -467,6 +473,7 @@ class Wic_PartData(Mic_PartData):
 Prepare an empty vfat partition.
 
 fs = %s/fs_%s.%s % (cr_workdir, self.label, self.fstype)
+os.remove(fs)
 
 blocks = self.size
 
@@ -493,6 +500,7 @@ class Wic_PartData(Mic_PartData):
   Proceeding as requested. % self.mountpoint)
 
 fs = %s/fs_%s.%s % (cr_workdir, self.label, self.fstype)
+os.remove(fs)
 
 # it is not possible to create a squashfs without source data,
 # thus prepare an empty temp dir that is used as source
-- 
2.1.4

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


[OE-core] [fido][PATCH 0/2] Backports for WIC

2015-07-23 Thread Ash Charles
In order to use the wic tool multiple times (Ubuntu 15.04 host), I need
to cherry-pick these two patches onto the fido branch.  Otherwise, wic
just hangs on the second invocation.  Can these two patches be applied
as backports to Fido?

Alexandre Belloni (1):
  wic: remove intermediate partitions

Ed Bartosh (1):
  wic: Make sure file exists before removing it

 scripts/lib/wic/kickstart/custom_commands/partition.py | 8 
 1 file changed, 8 insertions(+)

-- 
2.1.4

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


Re: [OE-core] [PATCH] libepoxy: Use native python3

2015-07-23 Thread Gary Thomas

On 2015-07-23 16:33, Burton, Ross wrote:


On 23 July 2015 at 01:22, Gary Thomas g...@mlbassoc.com 
mailto:g...@mlbassoc.com wrote:

This recipe needs python3.  This patch arranges to use the bitbake-built
version, not the host version (which may be missing or not work...)


Needs is a strong word.  The configure script does this:

AC_CHECK_PROGS([PYTHON], [python3 python2 python])


What's actually happening as a patch to simply remove python3 from that list 
will also solve most problems - we obviously depend on a fully working host 
python 2.


Well for me, the configure script ended up chosing python3,
even when I used 'pythonnative' (i.e. python2) in the recipe.
I could not get it to build any other way.

Since python3-native will most likely already be built, what's
the harm in doing it this way?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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


Re: [OE-core] [PATCH v2] qemu: CVE-2014-3689

2015-07-23 Thread Burton, Ross
On 23 July 2015 at 02:53, Huang, Jie (Jackie) jackie.hu...@windriver.com
wrote:

 Ping.


We're now at 2.4.0-rc1 in master and a patch for rc2 is on the list.  Does
this still need to be applied?

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


Re: [OE-core] [PATCH] libepoxy: Use native python3

2015-07-23 Thread Burton, Ross
On 23 July 2015 at 23:38, Gary Thomas g...@mlbassoc.com wrote:

 Well for me, the configure script ended up chosing python3,
 even when I used 'pythonnative' (i.e. python2) in the recipe.
 I could not get it to build any other way.

 Since python3-native will most likely already be built, what's
 the harm in doing it this way?


Why will it be build?  I certainly don't have a python3 build here.

Inheriting pythonnative is also the wrong thing to do - the pythonnative
classes are solely for when you need to run Python and use non-standard
classes that you've already built natively.  If you just want to run the
host Python, let it find the host python.

Why was the configure script choosing python3 on your host the wrong thing
to do?

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


Re: [OE-core] [PATCH] libepoxy: Use native python3

2015-07-23 Thread Richard Purdie
On Thu, 2015-07-23 at 17:00 -0600, Gary Thomas wrote:
 It's an old host (Fedora 13) that I am unable to upgrade, but it still
 works quite well.  I get around most of the Yocto/bitbake worries by
 using a Yocto-built meta-toolchain to fill in the blanks (correct make,
 python2, etc), but python3 is not part of the meta-toolchain :-(

You could likely build a customised meta-toolchain which did contain
python3 though?

Cheers,

Richard

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


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

2015-07-23 Thread Burton, Ross
On 23 July 2015 at 16:01, Bruce Ashfield bruce.ashfi...@gmail.com wrote:

  a) should be straightfoward to fix, its just updating the message
  whitelists (again).

 I'm building a fresh qemux86-64 now, I'm going to see if the warnings
 are something
 I should fix, versus the whitelist. I should know tomorrow on this one.


Patch sent to update the whitelists.

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


Re: [OE-core] [PATCH] tcf-agent: Update to version 1.3

2015-07-23 Thread Burton, Ross
Hi Randy,

On 23 July 2015 at 00:13, Randy Witt randy.e.w...@linux.intel.com wrote:

 According to the Eclipse tcf team, 1.3 tcf is required for the newest
 Eclipse release mars.

 [Yocto #7886]


Yocto should be uppercase, and you're missing your Signed-off-by.


  do_compile() {
 -   oe_runmake
 +   oe_runmake -C agent
  }


If you do everything inside the agent/ directory, consider setting S to
take that into account.

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


Re: [OE-core] [PATCH] libepoxy: Use native python3

2015-07-23 Thread Gary Thomas

On 2015-07-23 16:42, Burton, Ross wrote:


On 23 July 2015 at 23:38, Gary Thomas g...@mlbassoc.com 
mailto:g...@mlbassoc.com wrote:

Well for me, the configure script ended up chosing python3,
even when I used 'pythonnative' (i.e. python2) in the recipe.
I could not get it to build any other way.

Since python3-native will most likely already be built, what's
the harm in doing it this way?


Why will it be build?  I certainly don't have a python3 build here.


I almost always seem to end up with it being built...



Inheriting pythonnative is also the wrong thing to do - the pythonnative 
classes are solely for when you need to run Python and use non-standard classes 
that you've already built
natively.  If you just want to run the host Python, let it find the host python.

Why was the configure script choosing python3 on your host the wrong thing to 
do?


It seems that my host python3 is broken and doesn't have a working 'argparse'
  $ python3
  Python 3.1.2 (r312:79147, Aug 23 2010, 05:17:13)
  [GCC 4.4.4 20100630 (Red Hat 4.4.4-10)] on linux2
  Type help, copyright, credits or license for more information.
   import argparse
  Traceback (most recent call last):
File stdin, line 1, in module
  ImportError: No module named argparse
It's an old host (Fedora 13) that I am unable to upgrade, but it still
works quite well.  I get around most of the Yocto/bitbake worries by
using a Yocto-built meta-toolchain to fill in the blanks (correct make,
python2, etc), but python3 is not part of the meta-toolchain :-(

If this is not the correct way to get libepoxy to build, fair enough,
I'll figure out how to make my host functional.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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


Re: [OE-core] [PATCH 2/3] byacc: upgrade to 20150711

2015-07-23 Thread Burton, Ross
On 23 July 2015 at 03:10, Chen Qi qi.c...@windriver.com wrote:

 -LIC_FILES_CHKSUM =
 file://package/debian/copyright;md5=f186cf0d59bac042b75830396ec389a3
 +LIC_FILES_CHKSUM =
 file://package/debian/copyright;md5=c52fb2d1b3f75b3b7534927807a1b714


Please explain in the commit log why the license checksums have changed.

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


Re: [OE-core] [PATCH] libepoxy: Use native python3

2015-07-23 Thread Burton, Ross
On 23 July 2015 at 01:22, Gary Thomas g...@mlbassoc.com wrote:

 This recipe needs python3.  This patch arranges to use the bitbake-built
 version, not the host version (which may be missing or not work...)


Needs is a strong word.  The configure script does this:

AC_CHECK_PROGS([PYTHON], [python3 python2 python])

What's actually happening as a patch to simply remove python3 from that
list will also solve most problems - we obviously depend on a fully working
host python 2.

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


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

2015-07-23 Thread Bruce Ashfield
On Thu, Jul 23, 2015 at 3:56 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Wed, 2015-07-22 at 15:48 -0400, Bruce Ashfield wrote:
 On Wed, Jul 22, 2015 at 10:03 AM, Bruce Ashfield
 bruce.ashfi...@gmail.com wrote:
  On Tue, Jul 21, 2015 at 11:21 AM, Bruce Ashfield
  bruce.ashfi...@windriver.com wrote:
  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.
 
  As a follow up, my qemuarm boots that worked on Friday, are now hanging.
  I'm bisecting to find out what happened.

 And a final follow up.

 qemuarm (console and graphics) works fine .. but only if you use gcc
 4.9.x, gcc 5.1
 is doing something evil.

 We've looked into this in the past, so it is a known issue, but I need
 to handle these
 separately.

 We got the results of a run of those changes through the autobuilder
 without the noise of other failures. The error reporting system shows:

 http://errors.yoctoproject.org/Errors/Search/?items=10query=d687cdfd04f3d97923c93239ea902bb38e2ea336

 and I believe we have the following issues:

 a) qemux86/qemux86-64 are throwing warnings about errors in logs
 b) perf has some weird make race
 c) the qemuarm build looks like qemu either segfaulted or was killed
 d) we're occasionally seeing 3.19 and 3.14 fetch failures:
 https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
 https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio

I explained to Ross that dependent layers need to be updated if they set
their own SRCREV_meta, since the repository is completely different. I
sent a patch for meta-intel to deal with it. Obviously, I only built with the
core BSPs during testing.



I'll definitely need help on these, since I wasn't seeing any of these issues
during my testing. Otherwise, this won't be done until September (vacation
and other issues to deal with).

But I'll see what I can do.

I unfortunately can't merge anything but critical kernel patches until
these go in as well
since the meta branch is gone in the new scripts, which means SRCREV_meta is
a constant conflict.

Cheers,

Bruce

 To try and promote more sstate cache reuse whilst we sort the remaining
 issues, I merged the linux-libc-header part, we need to get the above
 fixed before the other pieces can merge.

 Cheers,

 Richard






-- 
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [meta-oe][PATCH] libical: Upgrade v1.0.0 - v1.0.1

2015-07-23 Thread Amarnath Valluri
- Build system changed from autotools to cmake.
- Perl dependency added.

Signed-off-by: Amarnath Valluri amarnath.vall...@intel.com
---
 .../libical/{libical_1.0.0.bb = libical_1.0.1.bb}| 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)
 rename meta/recipes-support/libical/{libical_1.0.0.bb = libical_1.0.1.bb} 
(66%)

diff --git a/meta/recipes-support/libical/libical_1.0.0.bb 
b/meta/recipes-support/libical/libical_1.0.1.bb
similarity index 66%
rename from meta/recipes-support/libical/libical_1.0.0.bb
rename to meta/recipes-support/libical/libical_1.0.1.bb
index be6b635..59ecdad 100644
--- a/meta/recipes-support/libical/libical_1.0.0.bb
+++ b/meta/recipes-support/libical/libical_1.0.1.bb
@@ -7,7 +7,9 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=d4fc58309d8ed46587ac63bb449d82f8 \
 SECTION = libs
 
 SRC_URI = https://github.com/${BPN}/${BPN}/archive/v${PV}.tar.gz;
-SRC_URI[md5sum] = f4b8e33ae5efb2f025eb43ce69682a36
-SRC_URI[sha256sum] = 
0072e83834092315772e6719b85fc8b11530b1ff53f4d108315fb38cddbce8c2
+SRC_URI[md5sum] = af91db06b22559f863869c5a382ad08a
+SRC_URI[sha256sum] = 
7d5f613454ec6c7d1bcfb441c919215be53292aa15cd1cb14249d1413d6c610c
 
-inherit autotools
+inherit cmake perlnative
+
+FILES_${PN}-dev += ${libdir}/cmake/LibIcal/*.cmake
-- 
2.1.4

-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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


Re: [OE-core] [poky][PATCH 2/3] gstreamer1.0-plugins-good: Add patch support aacparse

2015-07-23 Thread Otavio Salvador
On Thu, Jul 23, 2015 at 10:29 AM, Yuqing Zhu b54...@freescale.com wrote:
 There is no need to check channel configure in adts header.
 The channel could be output of decoder.
 No need to return fatal error here.

 Signed-off-by: Yuqing Zhu b54...@freescale.com

The Upstream-Status is wrong, as the other patches.

The bug reference needs to be update as it points to the duplicated bug[1]

1. https://bugzilla.gnome.org/show_bug.cgi?id=721697

Commit log is misleading. Please include a proper commit message.

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


[OE-core] [meta-oe][PATCH] sed: rrec on locale-base-ru-ru, not rdep

2015-07-23 Thread Abdur Rehman
This locale package isn't guaranteed to exist, depending on the value of
GLIBC_GENERATE_LOCALES.

The value of GLIBC_GENERATE_LOCALES can be specified to not contain
locale-base-ru-ru, thus resulting in unsatisfied dependency. Its better
to remove hardcoded dependency upon locale-base-ru-ru in favor of a
recommendation, as this locale isn't always available depending upon the
value of GLIBC_GENERATE_LOCALES.

Signed-off-by: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Abdur Rehman abdur_reh...@mentor.com
---
 meta/recipes-extended/sed/sed_4.2.2.bb |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sed/sed_4.2.2.bb 
b/meta/recipes-extended/sed/sed_4.2.2.bb
index a1e3483..5da3355 100644
--- a/meta/recipes-extended/sed/sed_4.2.2.bb
+++ b/meta/recipes-extended/sed/sed_4.2.2.bb
@@ -15,7 +15,8 @@ SRC_URI[md5sum] = 4111de4faa3b9848a0686b2f260c5056
 SRC_URI[sha256sum] = 
fea0a94d4b605894f3e2d5572e3f96e4413bcad3a085aae7367c2cf07908b2ff
 
 inherit autotools texinfo update-alternatives gettext ptest
-RDEPENDS_${PN}-ptest += make locale-base-ru-ru ${PN}
+RDEPENDS_${PN}-ptest += make ${PN}
+RRECOMMENDS_${PN}-ptest += locale-base-ru-ru
 
 EXTRA_OECONF = --disable-acl \
 ${@bb.utils.contains('PTEST_ENABLED', '1', 
'--enable-regex-tests', '', d)}
-- 
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 v2] oeqa/buildoptions.py: automate test case 929: check for correct GPL licenses

2015-07-23 Thread Paul Eggleton
Hi Costin,

On Thursday 23 July 2015 16:40:44 Costin Constantin wrote:
 Signed-off-by: Costin Constantin costin.c.constan...@intel.com
 ---
  meta/lib/oeqa/selftest/buildoptions.py | 30 ++
  1 file changed, 30 insertions(+)
 
 diff --git a/meta/lib/oeqa/selftest/buildoptions.py
 b/meta/lib/oeqa/selftest/buildoptions.py index e79be9e..ab009f2 100644
 --- a/meta/lib/oeqa/selftest/buildoptions.py
 +++ b/meta/lib/oeqa/selftest/buildoptions.py
 @@ -132,6 +132,36 @@ class BuildImagesTest(oeSelfTest):
  res = bitbake(core-image-directfb, ignore_status=True)
  self.assertEqual(res.status, 0, \ncoreimagedirectfb failed to
 build. Please check logs for further details.\nbitbake output %s %
 res.output)

 
 +@testcase(929)
 +def test_gpl_licenses(self):
 +
 +Test for checking that correct GPL licenses are used when
 explicitly required. 
 +
 +self.add_command_to_tearDown('cleanup-workdir')

I really don't think we should be calling cleanup-workdir here. If we have 
specific things to bitbake -c clean, by all means do that - but cleanup-workdir 
goes through and deletes everything that's not current, which is excessive for 
this one test.

Cheers,
Paul

-- 

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


Re: [OE-core] [poky][PATCH 3/3] gstreamer1.0-plugins-base: Add patch for Gstreamer 1.4.5 base

2015-07-23 Thread Otavio Salvador
On Thu, Jul 23, 2015 at 10:29 AM, Yuqing Zhu b54...@freescale.com wrote:
 Bug fix

 -[video-frame] Don't ref buffers twice when mapping

 -[video-frame] Add GST_VIDEO_FRAME_MAP_FLAG_NO_REF

 -[videofilter] Use new GST_VIDEO_FRAME_MAP_FLAG_NO_REF

 -[id3demux] Use g_utf16_to_utf8() instead of g_convert

 -[gstvideodecoder] Handle audio video decoder error

 -[gstvideopool] Update video alignment after video alignment

 -[gstvideoencoder] Keep sticky events around when doing a soft reset

 Signed-off-by: Yuqing Zhu b54...@freescale.com

Please split those so each one can be reviewed.

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


[OE-core] [PATCHv3 5/7] devtool: also load plugins from BBPATH

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

This makes it easier to extend, as a layer can add its own sub-commands.

Argument parsing is also separated into two steps, the same way it's done in
recipetool, as we need access to the global command-line arguments early,
before plugins are loaded, both for debugging arguments and for the bitbake
path (we need to load the bitbake module to get tinfoil, which is now needed
to load the plugins).

Rather than constructing tinfoil once and passing it through into sub-commands
for their use, we have to construct it for configuration metadata, use it, and
then shut it down, as some sub-commands call out to recipetool, which needs
its own tinfoil instance, and therefore needs to acquire the bitbake lock. If
we're still holding the lock at that point, that's clearly a problem.

[YOCTO #7625]

Signed-off-by: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
 scripts/devtool | 57 ++---
 scripts/lib/devtool/__init__.py |  4 +--
 2 files changed, 38 insertions(+), 23 deletions(-)

diff --git a/scripts/devtool b/scripts/devtool
index fa799f6..557a830 100755
--- a/scripts/devtool
+++ b/scripts/devtool
@@ -35,7 +35,7 @@ context = None
 scripts_path = os.path.dirname(os.path.realpath(__file__))
 lib_path = scripts_path + '/lib'
 sys.path = sys.path + [lib_path]
-from devtool import DevtoolError
+from devtool import DevtoolError, setup_tinfoil
 import scriptutils
 logger = scriptutils.logger_create('devtool')
 
@@ -186,37 +186,28 @@ def main():
 pth = os.path.dirname(pth)
 
 parser = argparse.ArgumentParser(description=OpenEmbedded development 
tool,
+ add_help=False,
  epilog=Use %(prog)s subcommand --help 
to get help on a specific command)
 parser.add_argument('--basepath', help='Base directory of SDK / build 
directory')
 parser.add_argument('-d', '--debug', help='Enable debug output', 
action='store_true')
 parser.add_argument('-q', '--quiet', help='Print only errors', 
action='store_true')
 parser.add_argument('--color', choices=['auto', 'always', 'never'], 
default='auto', help='Colorize output (where %(metavar)s is %(choices)s)', 
metavar='COLOR')
 
-subparsers = parser.add_subparsers(dest=subparser_name, 
title='subcommands', metavar='subcommand')
+global_args, unparsed_args = parser.parse_known_args()
 
-if not context.fixed_setup:
-parser_create_workspace = subparsers.add_parser('create-workspace',
-help='Set up a 
workspace',
-description='Sets up a 
new workspace. NOTE: other devtool subcommands will create a workspace 
automatically as needed, so you only need to use %(prog)s if you want to 
specify where the workspace should be located.')
-parser_create_workspace.add_argument('layerpath', nargs='?', 
help='Path in which the workspace layer should be created')
-parser_create_workspace.add_argument('--create-only', 
action=store_true, help='Only create the workspace layer, do not alter 
configuration')
-parser_create_workspace.set_defaults(func=create_workspace)
+# Help is added here rather than via add_help=True, as we don't want it to
+# be handled by parse_known_args()
+parser.add_argument('-h', '--help', action='help', 
default=argparse.SUPPRESS,
+help='show this help message and exit')
 
-scriptutils.load_plugins(logger, plugins, os.path.join(scripts_path, 
'lib', 'devtool'))
-for plugin in plugins:
-if hasattr(plugin, 'register_commands'):
-plugin.register_commands(subparsers, context)
-
-args = parser.parse_args()
-
-if args.debug:
+if global_args.debug:
 logger.setLevel(logging.DEBUG)
-elif args.quiet:
+elif global_args.quiet:
 logger.setLevel(logging.ERROR)
 
-if args.basepath:
+if global_args.basepath:
 # Override
-basepath = args.basepath
+basepath = global_args.basepath
 elif not context.fixed_setup:
 basepath = os.environ.get('BUILDDIR')
 if not basepath:
@@ -246,7 +237,31 @@ def main():
 logger.debug('Using standard bitbake path %s' % bitbakepath)
 scriptpath.add_oe_lib_path()
 
-scriptutils.logger_setup_color(logger, args.color)
+scriptutils.logger_setup_color(logger, global_args.color)
+
+tinfoil = setup_tinfoil(config_only=True)
+for path in ([scripts_path] +
+ tinfoil.config_data.getVar('BBPATH', True).split(':')):
+pluginpath = os.path.join(path, 'lib', 'devtool')
+scriptutils.load_plugins(logger, plugins, pluginpath)
+tinfoil.cooker.shutdown(force=True)
+tinfoil.cooker.unlockBitbake()
+
+subparsers = parser.add_subparsers(dest=subparser_name, 
title='subcommands', 

[OE-core] [PATCHv3 4/7] recipetool: parse global args early

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

This separates the argument parsing into two steps, which lets us apply global
settings like enabling debugging before the plugins load, so we can see the
paths where plugins are being loaded.

Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
 scripts/recipetool | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/scripts/recipetool b/scripts/recipetool
index 37c2dd3..87fb35e 100755
--- a/scripts/recipetool
+++ b/scripts/recipetool
@@ -46,12 +46,25 @@ def main():
 sys.exit(1)
 
 parser = argparse.ArgumentParser(description=OpenEmbedded recipe tool,
+ add_help=False,
  epilog=Use %(prog)s subcommand --help 
to get help on a specific command)
 parser.add_argument('-d', '--debug', help='Enable debug output', 
action='store_true')
 parser.add_argument('-q', '--quiet', help='Print only errors', 
action='store_true')
 parser.add_argument('--color', choices=['auto', 'always', 'never'], 
default='auto', help='Colorize output (where %(metavar)s is %(choices)s)', 
metavar='COLOR')
+
+global_args, unparsed_args = parser.parse_known_args()
+
+# Help is added here rather than via add_help=True, as we don't want it to
+# be handled by parse_known_args()
+parser.add_argument('-h', '--help', action='help', 
default=argparse.SUPPRESS,
+help='show this help message and exit')
 subparsers = parser.add_subparsers(title='subcommands', 
metavar='subcommand')
 
+if global_args.debug:
+logger.setLevel(logging.DEBUG)
+elif global_args.quiet:
+logger.setLevel(logging.ERROR)
+
 import scriptpath
 bitbakepath = scriptpath.add_bitbake_lib_path()
 if not bitbakepath:
@@ -59,6 +72,8 @@ def main():
 sys.exit(1)
 logger.debug('Found bitbake path: %s' % bitbakepath)
 
+scriptutils.logger_setup_color(logger, global_args.color)
+
 tinfoil = tinfoil_init(False)
 for path in ([scripts_path] +
  tinfoil.config_data.getVar('BBPATH', True).split(':')):
@@ -77,14 +92,7 @@ def main():
 logger.error(No commands registered - missing plugins?)
 sys.exit(1)
 
-args = parser.parse_args()
-
-if args.debug:
-logger.setLevel(logging.DEBUG)
-elif args.quiet:
-logger.setLevel(logging.ERROR)
-
-scriptutils.logger_setup_color(logger, args.color)
+args = parser.parse_args(unparsed_args, namespace=global_args)
 
 try:
 if getattr(args, 'parserecipes', False):
-- 
2.2.1

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


[OE-core] [PATCHv3 3/7] recipetool: also load plugins from BBPATH

2015-07-23 Thread Christopher Larson
This makes it easier to extend, as a layer can add its own sub-commands.

The bitbake path setup is moved earlier, as it has to be done before
tinfoil_init.

[YOCTO #7625]

Signed-off-by: Christopher Larson kerg...@gmail.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
 scripts/recipetool | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/scripts/recipetool b/scripts/recipetool
index 3063cf7..37c2dd3 100755
--- a/scripts/recipetool
+++ b/scripts/recipetool
@@ -36,11 +36,8 @@ def tinfoil_init(parserecipes):
 import logging
 tinfoil = bb.tinfoil.Tinfoil()
 tinfoil.prepare(not parserecipes)
-
-for plugin in plugins:
-if hasattr(plugin, 'tinfoil_init'):
-plugin.tinfoil_init(tinfoil)
 tinfoil.logger.setLevel(logger.getEffectiveLevel())
+return tinfoil
 
 def main():
 
@@ -55,12 +52,26 @@ def main():
 parser.add_argument('--color', choices=['auto', 'always', 'never'], 
default='auto', help='Colorize output (where %(metavar)s is %(choices)s)', 
metavar='COLOR')
 subparsers = parser.add_subparsers(title='subcommands', 
metavar='subcommand')
 
-scriptutils.load_plugins(logger, plugins, os.path.join(scripts_path, 
'lib', 'recipetool'))
+import scriptpath
+bitbakepath = scriptpath.add_bitbake_lib_path()
+if not bitbakepath:
+logger.error(Unable to find bitbake by searching parent directory of 
this script or PATH)
+sys.exit(1)
+logger.debug('Found bitbake path: %s' % bitbakepath)
+
+tinfoil = tinfoil_init(False)
+for path in ([scripts_path] +
+ tinfoil.config_data.getVar('BBPATH', True).split(':')):
+pluginpath = os.path.join(path, 'lib', 'recipetool')
+scriptutils.load_plugins(logger, plugins, pluginpath)
+
 registered = False
 for plugin in plugins:
 if hasattr(plugin, 'register_command'):
 registered = True
 plugin.register_command(subparsers)
+if hasattr(plugin, 'tinfoil_init'):
+plugin.tinfoil_init(tinfoil)
 
 if not registered:
 logger.error(No commands registered - missing plugins?)
@@ -73,17 +84,11 @@ def main():
 elif args.quiet:
 logger.setLevel(logging.ERROR)
 
-import scriptpath
-bitbakepath = scriptpath.add_bitbake_lib_path()
-if not bitbakepath:
-logger.error(Unable to find bitbake by searching parent directory of 
this script or PATH)
-sys.exit(1)
-logger.debug('Found bitbake path: %s' % bitbakepath)
-
 scriptutils.logger_setup_color(logger, args.color)
 
 try:
-tinfoil_init(getattr(args, 'parserecipes', False))
+if getattr(args, 'parserecipes', False):
+tinfoil.parseRecipes()
 ret = args.func(args)
 except bb.BBHandledException:
 ret = 1
-- 
2.2.1

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


[OE-core] [PATCHv3 2/7] recipetool.append: add extralines arg to appendsrc

2015-07-23 Thread Christopher Larson
This makes the function more reusable for other sub-commands.

Signed-off-by: Christopher Larson kerg...@gmail.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
 scripts/lib/recipetool/append.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/recipetool/append.py b/scripts/lib/recipetool/append.py
index 3f2f9a4..ed7d0d4 100644
--- a/scripts/lib/recipetool/append.py
+++ b/scripts/lib/recipetool/append.py
@@ -337,7 +337,7 @@ def appendfile(args):
 return 3
 
 
-def appendsrc(args, files, rd):
+def appendsrc(args, files, rd, extralines=None):
 import oe.recipeutils
 
 srcdir = rd.getVar('S', True)
@@ -352,7 +352,7 @@ def appendsrc(args, files, rd):
 simplified[str(simple_uri)] = uri
 
 copyfiles = {}
-extralines = []
+extralines = extralines or []
 for newfile, srcfile in files.iteritems():
 src_destdir = os.path.dirname(srcfile)
 if not args.use_workdir:
-- 
2.2.1

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


[OE-core] [PATCHv3 1/7] recipetool: catch BBHandledException from parsing

2015-07-23 Thread Christopher Larson
This ensures that we don't see a traceback on parsing failures.

Signed-off-by: Christopher Larson kerg...@gmail.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
 scripts/recipetool | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/scripts/recipetool b/scripts/recipetool
index c68bef4..3063cf7 100755
--- a/scripts/recipetool
+++ b/scripts/recipetool
@@ -82,9 +82,11 @@ def main():
 
 scriptutils.logger_setup_color(logger, args.color)
 
-tinfoil_init(getattr(args, 'parserecipes', False))
-
-ret = args.func(args)
+try:
+tinfoil_init(getattr(args, 'parserecipes', False))
+ret = args.func(args)
+except bb.BBHandledException:
+ret = 1
 
 return ret
 
-- 
2.2.1

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


[OE-core] [PATCHv3 0/6] recipetool/devtool/oe-selftest: pull from BBPATH

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

Ensures that recipetool and devtool pull plugins from layers, and
oe-selftest will pull tests from layers.

Unrelated to that, also prevents a traceback on parsing failure, and adds
a tiny feature to appendsrc to facilitate reuse by other sub-commands.

[v3 Update] Fixed the commit message for `devtool: also load plugins from
BBPATH` to match the implementation. Split up `recipetool: also load plugins
from BBPATH` into two commits with clear commit messages.

[v2 Update] `devtool: also load plugins from BBPATH` was fixed, so it no longer
breaks the devtool selftests.

The following changes since commit 3143920c541b55b543b9dcc12b18af4e0e4b7ae1:

  linux-libc-headers: update to 4.1 (2015-07-23 08:47:52 +0100)

are available in the git repository at:

  g...@github.com:kergoth/openembedded-core yocto-bug-7625

for you to fetch changes up to 6ac90ef048adff65b6dce1e4102156ccb365964a:

  oe-selftest: add libdirs from BBPATH to sys.path (2015-07-23 07:59:18 -0700)


Christopher Larson (7):
  recipetool: catch BBHandledException from parsing
  recipetool.append: add extralines arg to appendsrc
  recipetool: also load plugins from BBPATH
  recipetool: parse global args early
  devtool: also load plugins from BBPATH
  oe-selftest: obey oeqa.selftest.__path__
  oe-selftest: add libdirs from BBPATH to sys.path

 scripts/devtool  | 57 +---
 scripts/lib/devtool/__init__.py  |  4 +--
 scripts/lib/recipetool/append.py |  4 +--
 scripts/oe-selftest  | 18 +
 scripts/recipetool   | 57 +---
 5 files changed, 89 insertions(+), 51 deletions(-)

-- 
2.2.1

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


[OE-core] [PATCHv3 6/7] oe-selftest: obey oeqa.selftest.__path__

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

This ensures that all paths that hold selftest tests will be checked
(oeqa.selftest is a namespace package).

[YOCTO #7625]

Signed-off-by: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
 scripts/oe-selftest | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/scripts/oe-selftest b/scripts/oe-selftest
index fa6245a..c19c692 100755
--- a/scripts/oe-selftest
+++ b/scripts/oe-selftest
@@ -142,11 +142,12 @@ def get_tests(exclusive_modules=[], include_hidden=False):
 for x in exclusive_modules:
 testslist.append('oeqa.selftest.' + x)
 if not testslist:
-testpath = os.path.abspath(os.path.dirname(oeqa.selftest.__file__))
-files = sorted([f for f in os.listdir(testpath) if f.endswith('.py') 
and not (f.startswith('_') and not include_hidden) and not f.startswith('__') 
and f != 'base.py'])
-for f in files:
-module = 'oeqa.selftest.' + f[:-3]
-testslist.append(module)
+for testpath in oeqa.selftest.__path__:
+files = sorted([f for f in os.listdir(testpath) if 
f.endswith('.py') and not (f.startswith('_') and not include_hidden) and not 
f.startswith('__') and f != 'base.py'])
+for f in files:
+module = 'oeqa.selftest.' + f[:-3]
+if module not in testslist:
+testslist.append(module)
 
 return testslist
 
-- 
2.2.1

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


[OE-core] [PATCHv3 7/7] oe-selftest: add libdirs from BBPATH to sys.path

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

This ensures that oeqa.selftest.* from layers are found.

[YOCTO #7625]

Signed-off-by: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Ross Burton ross.bur...@intel.com
---
 scripts/oe-selftest | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/scripts/oe-selftest b/scripts/oe-selftest
index c19c692..60f9bb8 100755
--- a/scripts/oe-selftest
+++ b/scripts/oe-selftest
@@ -155,6 +155,13 @@ def main():
 parser = get_args_parser()
 args = parser.parse_args()
 
+# Add layer/lib to sys.path, so layers can add selftests
+log.info(Running bitbake -e to get BBPATH)
+bbpath = get_bb_var('BBPATH').split(':')
+layer_libdirs = [p for p in (os.path.join(l, 'lib') for l in bbpath) if 
os.path.exists(p)]
+sys.path.extend(layer_libdirs)
+reload(oeqa.selftest)
+
 if args.list_allclasses:
 args.list_modules = True
 
-- 
2.2.1

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


[OE-core] [PATCH 1/3] oeqa/recipetool: refactor / split out RecipetoolBase

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
 meta/lib/oeqa/selftest/recipetool.py | 52 +++-
 1 file changed, 34 insertions(+), 18 deletions(-)

diff --git a/meta/lib/oeqa/selftest/recipetool.py 
b/meta/lib/oeqa/selftest/recipetool.py
index 12c6b25..854ebfa 100644
--- a/meta/lib/oeqa/selftest/recipetool.py
+++ b/meta/lib/oeqa/selftest/recipetool.py
@@ -1,37 +1,29 @@
-import unittest
 import os
 import logging
-import re
 import tempfile
+import urlparse
 
-import oeqa.utils.ftools as ftools
-from oeqa.selftest.base import oeSelfTest
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, create_temp_layer
 from oeqa.utils.decorators import testcase
-from oeqa.selftest.devtool import DevtoolBase
+from oeqa.selftest import devtool
 
 
 templayerdir = ''
 
+
 def setUpModule():
 global templayerdir
 templayerdir = tempfile.mkdtemp(prefix='recipetoolqa')
 create_temp_layer(templayerdir, 'selftestrecipetool')
-result = runCmd('bitbake-layers add-layer %s' % templayerdir)
-# Ensure we have the right data in shlibs/pkgdata
-logger = logging.getLogger(selftest)
-logger.info('Running bitbake to generate pkgdata')
-bitbake('base-files coreutils busybox selftest-recipetool-appendfile')
+runCmd('bitbake-layers add-layer %s' % templayerdir)
+
 
 def tearDownModule():
 runCmd('bitbake-layers remove-layer %s' % templayerdir, ignore_status=True)
 runCmd('rm -rf %s' % templayerdir)
-# Shouldn't leave any traces of this artificial recipe behind
-bitbake('-c cleansstate selftest-recipetool-appendfile')
 
 
-class RecipetoolTests(DevtoolBase):
-
+class RecipetoolBase(devtool.DevtoolBase):
 def setUpLocal(self):
 self.tempdir = tempfile.mkdtemp(prefix='recipetoolqa')
 self.track_for_cleanup(self.tempdir)
@@ -42,27 +34,51 @@ class RecipetoolTests(DevtoolBase):
 def tearDownLocal(self):
 runCmd('rm -rf %s/recipes-*' % templayerdir)
 
-def _try_recipetool_appendfile(self, testrecipe, destfile, newfile, 
options, expectedlines, expectedfiles):
-result = runCmd('recipetool appendfile %s %s %s %s' % (templayerdir, 
destfile, newfile, options))
+def _try_recipetool_appendcmd(self, cmd, testrecipe, expectedfiles, 
expectedlines=None):
+result = runCmd(cmd)
 self.assertNotIn('Traceback', result.output)
+
 # Check the bbappend was created and applies properly
 recipefile = get_bb_var('FILE', testrecipe)
 bbappendfile = self._check_bbappend(testrecipe, recipefile, 
templayerdir)
+
 # Check the bbappend contents
-with open(bbappendfile, 'r') as f:
-self.assertEqual(expectedlines, f.readlines(), Expected lines are 
not present in %s % bbappendfile)
+if expectedlines is not None:
+with open(bbappendfile, 'r') as f:
+self.assertEqual(expectedlines, f.readlines(), Expected lines 
are not present in %s % bbappendfile)
+
 # Check file was copied
 filesdir = os.path.join(os.path.dirname(bbappendfile), testrecipe)
 for expectedfile in expectedfiles:
 self.assertTrue(os.path.isfile(os.path.join(filesdir, 
expectedfile)), 'Expected file %s to be copied next to bbappend, but it 
wasn\'t' % expectedfile)
+
 # Check no other files created
 createdfiles = []
 for root, _, files in os.walk(filesdir):
 for f in files:
 createdfiles.append(os.path.relpath(os.path.join(root, f), 
filesdir))
 self.assertTrue(sorted(createdfiles), sorted(expectedfiles))
+
 return bbappendfile, result.output
 
+
+class RecipetoolTests(RecipetoolBase):
+@classmethod
+def setUpClass(cls):
+# Ensure we have the right data in shlibs/pkgdata
+logger = logging.getLogger(selftest)
+logger.info('Running bitbake to generate pkgdata')
+bitbake('-c packagedata base-files coreutils busybox 
selftest-recipetool-appendfile')
+
+@classmethod
+def tearDownClass(cls):
+# Shouldn't leave any traces of this artificial recipe behind
+bitbake('-c cleansstate selftest-recipetool-appendfile')
+
+def _try_recipetool_appendfile(self, testrecipe, destfile, newfile, 
options, expectedlines, expectedfiles):
+cmd = 'recipetool appendfile %s %s %s %s' % (templayerdir, destfile, 
newfile, options)
+return self._try_recipetool_appendcmd(cmd, testrecipe, expectedfiles, 
expectedlines)
+
 def _try_recipetool_appendfile_fail(self, destfile, newfile, checkerror):
 cmd = 'recipetool appendfile %s %s %s' % (templayerdir, destfile, 
newfile)
 result = runCmd(cmd, ignore_status=True)
-- 
2.2.1

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


[OE-core] [PATCH 0/3] oeqa/recipetool: add tests for appendsrcfile(s)

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

The following changes since commit 3143920c541b55b543b9dcc12b18af4e0e4b7ae1:

  linux-libc-headers: update to 4.1 (2015-07-23 08:47:52 +0100)

are available in the git repository at:

  g...@github.com:kergoth/openembedded-core recipetool-tests

for you to fetch changes up to 97dcd3c3e44840196962b2f5a909c5a7f016b99b:

  oeqa/recipetool: allow templayerdir override (2015-07-23 08:19:15 -0700)


Christopher Larson (3):
  oeqa/recipetool: refactor / split out RecipetoolBase
  oeqa/recipetool: add tests for appendsrcfile(s)
  oeqa/recipetool: allow templayerdir override

 meta/lib/oeqa/selftest/recipetool.py | 221 ++-
 1 file changed, 195 insertions(+), 26 deletions(-)

-- 
2.2.1

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


[OE-core] [PATCH 2/3] oeqa/recipetool: add tests for appendsrcfile(s)

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
 meta/lib/oeqa/selftest/recipetool.py | 152 +++
 1 file changed, 152 insertions(+)

diff --git a/meta/lib/oeqa/selftest/recipetool.py 
b/meta/lib/oeqa/selftest/recipetool.py
index 854ebfa..bebc1d6 100644
--- a/meta/lib/oeqa/selftest/recipetool.py
+++ b/meta/lib/oeqa/selftest/recipetool.py
@@ -399,3 +399,155 @@ class RecipetoolTests(RecipetoolBase):
 checkvars['DEPENDS'] = 'libpng pango libx11 libxext jpeg'
 inherits = ['autotools', 'pkgconfig']
 self._test_recipe_contents(recipefile, checkvars, inherits)
+
+
+class RecipetoolAppendsrcBase(RecipetoolBase):
+def _try_recipetool_appendsrcfile(self, testrecipe, newfile, destfile, 
options, expectedlines, expectedfiles):
+cmd = 'recipetool appendsrcfile %s %s %s %s %s' % (options, 
templayerdir, testrecipe, newfile, destfile)
+return self._try_recipetool_appendcmd(cmd, testrecipe, expectedfiles, 
expectedlines)
+
+def _try_recipetool_appendsrcfiles(self, testrecipe, newfiles, 
expectedlines=None, expectedfiles=None, destdir=None, options=''):
+
+if destdir:
+options += ' -D %s' % destdir
+
+if expectedfiles is None:
+expectedfiles = [os.path.basename(f) for f in newfiles]
+
+cmd = 'recipetool appendsrcfiles %s %s %s %s' % (options, 
templayerdir, testrecipe, ' '.join(newfiles))
+return self._try_recipetool_appendcmd(cmd, testrecipe, expectedfiles, 
expectedlines)
+
+def _try_recipetool_appendsrcfile_fail(self, testrecipe, newfile, 
destfile, checkerror):
+cmd = 'recipetool appendsrcfile %s %s %s %s' % (templayerdir, 
testrecipe, newfile, destfile or '')
+result = runCmd(cmd, ignore_status=True)
+self.assertNotEqual(result.status, 0, 'Command %s should have failed 
but didn\'t' % cmd)
+self.assertNotIn('Traceback', result.output)
+for errorstr in checkerror:
+self.assertIn(errorstr, result.output)
+
+@staticmethod
+def _get_first_file_uri(recipe):
+'''Return the first file:// in SRC_URI for the specified recipe.'''
+src_uri = get_bb_var('SRC_URI', recipe).split()
+for uri in src_uri:
+p = urlparse.urlparse(uri)
+if p.scheme == 'file':
+return p.netloc + p.path
+
+def _test_appendsrcfile(self, testrecipe, filename=None, destdir=None, 
has_src_uri=True, srcdir=None, newfile=None, options=''):
+if newfile is None:
+newfile = self.testfile
+
+if srcdir:
+if destdir:
+expected_subdir = os.path.join(srcdir, destdir)
+else:
+expected_subdir = srcdir
+else:
+options +=  -W
+expected_subdir = destdir
+
+if filename:
+if destdir:
+destpath = os.path.join(destdir, filename)
+else:
+destpath = filename
+else:
+filename = os.path.basename(newfile)
+if destdir:
+destpath = destdir + os.sep
+else:
+destpath = '.' + os.sep
+
+expectedlines = ['FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:\n',
+ '\n']
+if has_src_uri:
+uri = 'file://%s' % filename
+if expected_subdir:
+uri += ';subdir=%s' % expected_subdir
+expectedlines[0:0] = ['SRC_URI += %s\n' % uri,
+  '\n']
+
+return self._try_recipetool_appendsrcfile(testrecipe, newfile, 
destpath, options, expectedlines, [filename])
+
+def _test_appendsrcfiles(self, testrecipe, newfiles, expectedfiles=None, 
destdir=None, options=''):
+if expectedfiles is None:
+expectedfiles = [os.path.basename(n) for n in newfiles]
+
+self._try_recipetool_appendsrcfiles(testrecipe, newfiles, 
expectedfiles=expectedfiles, destdir=destdir, options=options)
+
+src_uri = get_bb_var('SRC_URI', testrecipe).split()
+for f in expectedfiles:
+if destdir:
+self.assertIn('file://%s;subdir=%s' % (f, destdir), src_uri)
+else:
+self.assertIn('file://%s' % f, src_uri)
+
+recipefile = get_bb_var('FILE', testrecipe)
+bbappendfile = self._check_bbappend(testrecipe, recipefile, 
templayerdir)
+filesdir = os.path.join(os.path.dirname(bbappendfile), testrecipe)
+filesextrapaths = get_bb_var('FILESEXTRAPATHS', testrecipe).split(':')
+self.assertIn(filesdir, filesextrapaths)
+
+
+class RecipetoolAppendsrcTests(RecipetoolAppendsrcBase):
+def test_recipetool_appendsrcfile_basic(self):
+self._test_appendsrcfile('base-files', 'a-file')
+
+def test_recipetool_appendsrcfile_basic_wildcard(self):
+testrecipe = 'base-files'
+

[OE-core] [PATCH 3/3] oeqa/recipetool: allow templayerdir override

2015-07-23 Thread Christopher Larson
From: Christopher Larson chris_lar...@mentor.com

This is provided for use by subclasses.

Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
 meta/lib/oeqa/selftest/recipetool.py | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/meta/lib/oeqa/selftest/recipetool.py 
b/meta/lib/oeqa/selftest/recipetool.py
index bebc1d6..689d41b 100644
--- a/meta/lib/oeqa/selftest/recipetool.py
+++ b/meta/lib/oeqa/selftest/recipetool.py
@@ -8,7 +8,7 @@ from oeqa.utils.decorators import testcase
 from oeqa.selftest import devtool
 
 
-templayerdir = ''
+templayerdir = None
 
 
 def setUpModule():
@@ -25,6 +25,7 @@ def tearDownModule():
 
 class RecipetoolBase(devtool.DevtoolBase):
 def setUpLocal(self):
+self.templayerdir = templayerdir
 self.tempdir = tempfile.mkdtemp(prefix='recipetoolqa')
 self.track_for_cleanup(self.tempdir)
 self.testfile = os.path.join(self.tempdir, 'testfile')
@@ -32,7 +33,7 @@ class RecipetoolBase(devtool.DevtoolBase):
 f.write('Test file\n')
 
 def tearDownLocal(self):
-runCmd('rm -rf %s/recipes-*' % templayerdir)
+runCmd('rm -rf %s/recipes-*' % self.templayerdir)
 
 def _try_recipetool_appendcmd(self, cmd, testrecipe, expectedfiles, 
expectedlines=None):
 result = runCmd(cmd)
@@ -40,7 +41,7 @@ class RecipetoolBase(devtool.DevtoolBase):
 
 # Check the bbappend was created and applies properly
 recipefile = get_bb_var('FILE', testrecipe)
-bbappendfile = self._check_bbappend(testrecipe, recipefile, 
templayerdir)
+bbappendfile = self._check_bbappend(testrecipe, recipefile, 
self.templayerdir)
 
 # Check the bbappend contents
 if expectedlines is not None:
@@ -76,11 +77,11 @@ class RecipetoolTests(RecipetoolBase):
 bitbake('-c cleansstate selftest-recipetool-appendfile')
 
 def _try_recipetool_appendfile(self, testrecipe, destfile, newfile, 
options, expectedlines, expectedfiles):
-cmd = 'recipetool appendfile %s %s %s %s' % (templayerdir, destfile, 
newfile, options)
+cmd = 'recipetool appendfile %s %s %s %s' % (self.templayerdir, 
destfile, newfile, options)
 return self._try_recipetool_appendcmd(cmd, testrecipe, expectedfiles, 
expectedlines)
 
 def _try_recipetool_appendfile_fail(self, destfile, newfile, checkerror):
-cmd = 'recipetool appendfile %s %s %s' % (templayerdir, destfile, 
newfile)
+cmd = 'recipetool appendfile %s %s %s' % (self.templayerdir, destfile, 
newfile)
 result = runCmd(cmd, ignore_status=True)
 self.assertNotEqual(result.status, 0, 'Command %s should have failed 
but didn\'t' % cmd)
 self.assertNotIn('Traceback', result.output)
@@ -132,7 +133,7 @@ class RecipetoolTests(RecipetoolBase):
 # Try appending a binary file
 # /bin/ls can be a symlink to /usr/bin/ls
 ls = os.path.realpath(/bin/ls)
-result = runCmd('recipetool appendfile %s /bin/ls %s -r coreutils' % 
(templayerdir, ls))
+result = runCmd('recipetool appendfile %s /bin/ls %s -r coreutils' % 
(self.templayerdir, ls))
 self.assertIn('WARNING: ', result.output)
 self.assertIn('is a binary', result.output)
 
@@ -341,17 +342,17 @@ class RecipetoolTests(RecipetoolBase):
 def test_recipetool_appendfile_wildcard(self):
 
 def try_appendfile_wc(options):
-result = runCmd('recipetool appendfile %s /etc/profile %s %s' % 
(templayerdir, self.testfile, options))
+result = runCmd('recipetool appendfile %s /etc/profile %s %s' % 
(self.templayerdir, self.testfile, options))
 self.assertNotIn('Traceback', result.output)
 bbappendfile = None
-for root, _, files in os.walk(templayerdir):
+for root, _, files in os.walk(self.templayerdir):
 for f in files:
 if f.endswith('.bbappend'):
 bbappendfile = f
 break
 if not bbappendfile:
 self.assertTrue(False, 'No bbappend file created')
-runCmd('rm -rf %s/recipes-*' % templayerdir)
+runCmd('rm -rf %s/recipes-*' % self.templayerdir)
 return bbappendfile
 
 # Check without wildcard option
@@ -403,7 +404,7 @@ class RecipetoolTests(RecipetoolBase):
 
 class RecipetoolAppendsrcBase(RecipetoolBase):
 def _try_recipetool_appendsrcfile(self, testrecipe, newfile, destfile, 
options, expectedlines, expectedfiles):
-cmd = 'recipetool appendsrcfile %s %s %s %s %s' % (options, 
templayerdir, testrecipe, newfile, destfile)
+cmd = 'recipetool appendsrcfile %s %s %s %s %s' % (options, 
self.templayerdir, testrecipe, newfile, destfile)
 return self._try_recipetool_appendcmd(cmd, testrecipe, expectedfiles, 
expectedlines)
 
 def _try_recipetool_appendsrcfiles(self, testrecipe, newfiles, 
expectedlines=None, expectedfiles=None, 

[OE-core] [meta-oe][PATCH] mkefidisk.sh: Added function to wait for devices to show up

2015-07-23 Thread Oscar Andreasson
Call function to wait for device to re-appear after partitioning device,
before formatting the same device.

Signed-off-by: Oscar Andreasson oscar.andreas...@pelagicore.com
---
 scripts/contrib/mkefidisk.sh | 12 
 1 file changed, 12 insertions(+)

diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 55f72b0..133c5bc 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -83,6 +83,17 @@ debug() {
fi
 }
 
+waitfordevice() {
+counter=0
+while [ ! -e $1 ]; do
+sleep 1
+counter=$(($counter+1))
+if [ $counter -ge 10 ]; then
+die  Device $1 not showing up, something is probably wrong
+fi
+done
+}
+
 usage() {
echo Usage: $(basename $0) [-v] DEVICE HDDIMG TARGET_DEVICE
echo-v: Verbose debug
@@ -293,6 +304,7 @@ fi
 #
 unmount_device || die Failed to unmount $DEVICE partitions
 
+waitfordevice $BOOTFS
 
 #
 # Format $DEVICE partitions
-- 
2.1.4

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


[OE-core] [PATCH v2] tcf-agent: Update to version 1.3

2015-07-23 Thread Randy Witt
According to the Eclipse tcf team, 1.3 tcf is required for the newest
Eclipse release mars.

[Yocto #7886]

Signed-off-by: Randy Witt randy.e.w...@linux.intel.com
---
 meta/recipes-devtools/tcf-agent/tcf-agent_git.bb | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb 
b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
index 616a6a7..f8fd390 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -5,11 +5,10 @@ BUGTRACKER = https://bugs.eclipse.org/bugs/;
 LICENSE = EPL-1.0 | EDL-1.0
 LIC_FILES_CHKSUM = file://edl-v10.html;md5=522a390a83dc186513f0500543ad3679
 
-SRCREV = 4ef94ecb927a8912c3d79ce137182247786cff8f
-PV = 0.4.0+git${SRCPV}
-PR = r2
+SRCREV = b9a735e9c7cf82f80d412b7ab15d08b89d5a4ccc
+PV = 1.3.0+git${SRCPV}
 
-SRC_URI = git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git \
+SRC_URI = 
git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git;branch=1.3_mars_bugfix
 \
file://fix_ranlib.patch \
file://tcf-agent.init \
file://tcf-agent.service \
@@ -18,7 +17,7 @@ SRC_URI = 
git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git \
 DEPENDS = util-linux openssl
 RDEPENDS_${PN} = bash
 
-S = ${WORKDIR}/git
+S = ${WORKDIR}/git/agent
 
 inherit update-rc.d systemd
 
@@ -39,10 +38,6 @@ CFLAGS += -DSERVICE_RunControl=0 -DSERVICE_Breakpoints=0 \
 -DSERVICE_StackTrace=0 -DSERVICE_Symbols=0 -DSERVICE_LineNumbers=0 \
 -DSERVICE_Expressions=0
 
-do_compile() {
-   oe_runmake
-}
-
 do_install() {
oe_runmake install INSTALLROOT=${D}
install -d ${D}${sysconfdir}/init.d/
-- 
2.4.3

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


Re: [OE-core] [fido][PATCH 0/2] Backports for WIC

2015-07-23 Thread Philip Balister
I'd like to see this also. I've added a rm to my script to work around
this, but this change would help a lot of people.

Philip

On 07/23/2015 05:44 PM, Ash Charles wrote:
 In order to use the wic tool multiple times (Ubuntu 15.04 host), I need
 to cherry-pick these two patches onto the fido branch.  Otherwise, wic
 just hangs on the second invocation.  Can these two patches be applied
 as backports to Fido?
 
 Alexandre Belloni (1):
   wic: remove intermediate partitions
 
 Ed Bartosh (1):
   wic: Make sure file exists before removing it
 
  scripts/lib/wic/kickstart/custom_commands/partition.py | 8 
  1 file changed, 8 insertions(+)
 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [meta-oe][PATCH] sed: rrec on locale-base-ru-ru, not rdep

2015-07-23 Thread Ahsan, Noor
This should be sent to openembedded mailing list not on oe-core mailing list.

Noor

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Rehman, 
Abdur
Sent: Thursday, July 23, 2015 6:34 PM
To: openembedded-core@lists.openembedded.org
Cc: Larson, Chris
Subject: [OE-core] [meta-oe][PATCH] sed: rrec on locale-base-ru-ru, not rdep

This locale package isn't guaranteed to exist, depending on the value of 
GLIBC_GENERATE_LOCALES.

The value of GLIBC_GENERATE_LOCALES can be specified to not contain 
locale-base-ru-ru, thus resulting in unsatisfied dependency. Its better to 
remove hardcoded dependency upon locale-base-ru-ru in favor of a 
recommendation, as this locale isn't always available depending upon the value 
of GLIBC_GENERATE_LOCALES.

Signed-off-by: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Abdur Rehman abdur_reh...@mentor.com
---
 meta/recipes-extended/sed/sed_4.2.2.bb |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sed/sed_4.2.2.bb 
b/meta/recipes-extended/sed/sed_4.2.2.bb
index a1e3483..5da3355 100644
--- a/meta/recipes-extended/sed/sed_4.2.2.bb
+++ b/meta/recipes-extended/sed/sed_4.2.2.bb
@@ -15,7 +15,8 @@ SRC_URI[md5sum] = 4111de4faa3b9848a0686b2f260c5056
 SRC_URI[sha256sum] = 
fea0a94d4b605894f3e2d5572e3f96e4413bcad3a085aae7367c2cf07908b2ff
 
 inherit autotools texinfo update-alternatives gettext ptest 
-RDEPENDS_${PN}-ptest += make locale-base-ru-ru ${PN}
+RDEPENDS_${PN}-ptest += make ${PN}
+RRECOMMENDS_${PN}-ptest += locale-base-ru-ru
 
 EXTRA_OECONF = --disable-acl \
 ${@bb.utils.contains('PTEST_ENABLED', '1', 
'--enable-regex-tests', '', d)}
--
1.7.9.5

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


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

2015-07-23 Thread Richard Purdie
On Thu, 2015-07-23 at 09:10 -0400, Bruce Ashfield wrote:
 On Thu, Jul 23, 2015 at 3:56 AM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
  On Wed, 2015-07-22 at 15:48 -0400, Bruce Ashfield wrote:
  On Wed, Jul 22, 2015 at 10:03 AM, Bruce Ashfield
  bruce.ashfi...@gmail.com wrote:
   On Tue, Jul 21, 2015 at 11:21 AM, Bruce Ashfield
   bruce.ashfi...@windriver.com wrote:
   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.
  
   As a follow up, my qemuarm boots that worked on Friday, are now hanging.
   I'm bisecting to find out what happened.
 
  And a final follow up.
 
  qemuarm (console and graphics) works fine .. but only if you use gcc
  4.9.x, gcc 5.1
  is doing something evil.
 
  We've looked into this in the past, so it is a known issue, but I need
  to handle these
  separately.
 
  We got the results of a run of those changes through the autobuilder
  without the noise of other failures. The error reporting system shows:
 
  http://errors.yoctoproject.org/Errors/Search/?items=10query=d687cdfd04f3d97923c93239ea902bb38e2ea336
 
  and I believe we have the following issues:
 
  a) qemux86/qemux86-64 are throwing warnings about errors in logs
  b) perf has some weird make race
  c) the qemuarm build looks like qemu either segfaulted or was killed
  d) we're occasionally seeing 3.19 and 3.14 fetch failures:
  https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
  https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio
 
 I explained to Ross that dependent layers need to be updated if they set
 their own SRCREV_meta, since the repository is completely different. I
 sent a patch for meta-intel to deal with it. Obviously, I only built with the
 core BSPs during testing.

That could explain d). I believe c) is from the ongoing selftest issues
we're having and I we've work in progress for that. That leaves a) and
b) to look into and fix.

 I'll definitely need help on these, since I wasn't seeing any of these issues
 during my testing. Otherwise, this won't be done until September (vacation
 and other issues to deal with).
 
 But I'll see what I can do.
 
 I unfortunately can't merge anything but critical kernel patches until
 these go in as well
 since the meta branch is gone in the new scripts, which means SRCREV_meta is
 a constant conflict.

a) should be straightfoward to fix, its just updating the message
whitelists (again).

b) I'm less sure about. Are there any race fixes in mainline for perf?
Hard to believe others don't see that one.

Cheers,

Richard

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


Re: [OE-core] [meta-oe][PATCH] sed: rrec on locale-base-ru-ru, not rdep

2015-07-23 Thread Rehman, Abdur
meta-oe got included in the subject by accident.
I will update and send the patch again.

Thanks,
AbdurRehman

From: Ahsan, Noor
Sent: Thursday, July 23, 2015 7:49 PM
To: Rehman, Abdur; openembedded-core@lists.openembedded.org
Cc: Larson, Chris
Subject: RE: [OE-core] [meta-oe][PATCH] sed: rrec on locale-base-ru-ru, not rdep

This should be sent to openembedded mailing list not on oe-core mailing list.

Noor

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Rehman, 
Abdur
Sent: Thursday, July 23, 2015 6:34 PM
To: openembedded-core@lists.openembedded.org
Cc: Larson, Chris
Subject: [OE-core] [meta-oe][PATCH] sed: rrec on locale-base-ru-ru, not rdep

This locale package isn't guaranteed to exist, depending on the value of 
GLIBC_GENERATE_LOCALES.

The value of GLIBC_GENERATE_LOCALES can be specified to not contain 
locale-base-ru-ru, thus resulting in unsatisfied dependency. Its better to 
remove hardcoded dependency upon locale-base-ru-ru in favor of a 
recommendation, as this locale isn't always available depending upon the value 
of GLIBC_GENERATE_LOCALES.

Signed-off-by: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Abdur Rehman abdur_reh...@mentor.com
---
 meta/recipes-extended/sed/sed_4.2.2.bb |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sed/sed_4.2.2.bb 
b/meta/recipes-extended/sed/sed_4.2.2.bb
index a1e3483..5da3355 100644
--- a/meta/recipes-extended/sed/sed_4.2.2.bb
+++ b/meta/recipes-extended/sed/sed_4.2.2.bb
@@ -15,7 +15,8 @@ SRC_URI[md5sum] = 4111de4faa3b9848a0686b2f260c5056
 SRC_URI[sha256sum] = 
fea0a94d4b605894f3e2d5572e3f96e4413bcad3a085aae7367c2cf07908b2ff

 inherit autotools texinfo update-alternatives gettext ptest 
-RDEPENDS_${PN}-ptest += make locale-base-ru-ru ${PN}
+RDEPENDS_${PN}-ptest += make ${PN}
+RRECOMMENDS_${PN}-ptest += locale-base-ru-ru

 EXTRA_OECONF = --disable-acl \
 ${@bb.utils.contains('PTEST_ENABLED', '1', 
'--enable-regex-tests', '', d)}
--
1.7.9.5

--
___
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 1/2] image: Support for qcow2

2015-07-23 Thread Christian Ziethén
Add support for qcow2 image format. Implemented in the same way as
the previously existing vmdk and vdi solutions.

Signed-off-by: Christian Ziethén christian.ziet...@linaro.org
---
 meta/classes/boot-directdisk.bbclass |  2 +-
 meta/classes/image-vm.bbclass| 12 ++--
 meta/classes/image.bbclass   |  2 +-
 meta/classes/image_types.bbclass |  5 +++--
 meta/classes/sanity.bbclass  |  4 
 5 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/meta/classes/boot-directdisk.bbclass 
b/meta/classes/boot-directdisk.bbclass
index c576523..d256fff 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -63,7 +63,7 @@ DISK_SIGNATURE ?= ${DISK_SIGNATURE_GENERATED}
 SYSLINUX_ROOT ?= root=/dev/sda2
 SYSLINUX_TIMEOUT ?= 10
 
-IS_VM = '${@bb.utils.contains_any(IMAGE_FSTYPES, [vmdk ,vdi], true, 
false, d)}'
+IS_VM = '${@bb.utils.contains_any(IMAGE_FSTYPES, [vmdk, vdi, qcow2], 
true, false, d)}'
 
 boot_direct_populate() {
dest=$1
diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index fdfd14f..28519c8 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -14,7 +14,8 @@ inherit boot-directdisk
 
 IMAGE_TYPEDEP_vmdk = ext3
 IMAGE_TYPEDEP_vdi = ext3
-IMAGE_TYPES_MASKED += vmdk vdi
+IMAGE_TYPEDEP_qcow2 = ext3
+IMAGE_TYPES_MASKED += vmdk vdi qcow2
 
 create_vmdk_image () {
 qemu-img convert -O vmdk ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.vmdk
@@ -26,11 +27,18 @@ create_vdi_image () {
 ln -sf ${IMAGE_NAME}.vdi ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vdi
 }
 
+create_qcow2_image () {
+qemu-img convert -O qcow2 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.qcow2
+ln -sf ${IMAGE_NAME}.qcow2 ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.qcow2
+}
+
 python do_vmimg() {
 if 'vmdk' in d.getVar('IMAGE_FSTYPES', True):
 bb.build.exec_func('create_vmdk_image', d)
 if 'vdi' in d.getVar('IMAGE_FSTYPES', True):
-bb.build.exec_func('create_vdi_image', d)
+bb.build.exec_func('create_vdi_image', d)
+if 'qcow2' in d.getVar('IMAGE_FSTYPES', True):
+bb.build.exec_func('create_qcow2_image', d)
 }
 
 addtask vmimg after do_bootdirectdisk before do_build
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index e2995e2..ff2ed0d 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -132,7 +132,7 @@ def build_live(d):
 IMAGE_TYPE_live = ${@build_live(d)}
 inherit ${IMAGE_TYPE_live}
 
-IMAGE_TYPE_vm = '${@bb.utils.contains_any(IMAGE_FSTYPES, [vmdk, vdi], 
image-vm, , d)}'
+IMAGE_TYPE_vm = '${@bb.utils.contains_any(IMAGE_FSTYPES, [vmdk, vdi, 
qcow2], image-vm, , d)}'
 inherit ${IMAGE_TYPE_vm}
 
 python () {
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 588a474..cc789fc 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -13,7 +13,7 @@ def imagetypes_getdepends(d):
 deps = []
 ctypes = d.getVar('COMPRESSIONTYPES', True).split()
 for type in (d.getVar('IMAGE_FSTYPES', True) or ).split():
-if type in [vmdk, vdi, live, iso, hddimg]:
+if type in [vmdk, vdi, qcow2, live, iso, hddimg]:
 type = ext3
 basetype = type
 for ctype in ctypes:
@@ -187,6 +187,7 @@ IMAGE_TYPES =  \
 cpio cpio.gz cpio.xz cpio.lzma cpio.lz4 \
 vmdk \
 vdi \
+qcow2 \
 elf \
 
 
@@ -213,5 +214,5 @@ DEPLOYABLE_IMAGE_TYPES ?= hddimg iso
 IMAGE_EXTENSION_live = hddimg iso
 
 # The IMAGE_TYPES_MASKED variable will be used to mask out from the 
IMAGE_FSTYPES,
-# images that will not be built at do_rootfs time: vmdk, vdi, hddimg, iso, etc.
+# images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hddimg, 
iso, etc.
 IMAGE_TYPES_MASKED ?= 
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 2855941..6ad620b 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -835,6 +835,10 @@ def check_sanity_everybuild(status, d):
 if 'vdi' in d.getVar('IMAGE_FSTYPES', True) and 'live' in 
d.getVar('IMAGE_FSTYPES', True):
 status.addresult(Error, IMAGE_FSTYPES vdi and live can't be built 
together\n)
 
+# Check qcow2 and live can't be built together.
+if 'qcow2' in d.getVar('IMAGE_FSTYPES', True) and 'live' in 
d.getVar('IMAGE_FSTYPES', True):
+status.addresult(Error, IMAGE_FSTYPES qcow2 and live can't be built 
together\n)
+
 # Check /bin/sh links to dash or bash
 real_sh = os.path.realpath('/bin/sh')
 if not real_sh.endswith('/dash') and not real_sh.endswith('/bash'):
-- 
2.1.4

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


[OE-core] [PATCH 2/2] boot-directdisk: Make kernel image inclusion conditional.

2015-07-23 Thread Christian Ziethén
When building for qcow2 and a dummy kernel, avoid installing
a non existing bzImage.

Signed-off-by: Christian Ziethén christian.ziet...@linaro.org
---
 meta/classes/boot-directdisk.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/boot-directdisk.bbclass 
b/meta/classes/boot-directdisk.bbclass
index d256fff..600e21a 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -70,7 +70,9 @@ boot_direct_populate() {
install -d $dest
 
# Install bzImage, initrd, and rootfs.img in DEST for all loaders to 
use.
-   install -m 0644 ${DEPLOY_DIR_IMAGE}/bzImage $dest/vmlinuz
+   if [ -e ${DEPLOY_DIR_IMAGE}/bzImage ]; then
+   install -m 0644 ${DEPLOY_DIR_IMAGE}/bzImage $dest/vmlinuz
+   fi
 
# initrd is made of concatenation of multiple filesystem images
if [ -n ${INITRD} ]; then
-- 
2.1.4

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


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

2015-07-23 Thread Bruce Ashfield
On Thu, Jul 23, 2015 at 10:14 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Thu, 2015-07-23 at 09:10 -0400, Bruce Ashfield wrote:
 On Thu, Jul 23, 2015 at 3:56 AM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
  On Wed, 2015-07-22 at 15:48 -0400, Bruce Ashfield wrote:
  On Wed, Jul 22, 2015 at 10:03 AM, Bruce Ashfield
  bruce.ashfi...@gmail.com wrote:
   On Tue, Jul 21, 2015 at 11:21 AM, Bruce Ashfield
   bruce.ashfi...@windriver.com wrote:
   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.
  
   As a follow up, my qemuarm boots that worked on Friday, are now hanging.
   I'm bisecting to find out what happened.
 
  And a final follow up.
 
  qemuarm (console and graphics) works fine .. but only if you use gcc
  4.9.x, gcc 5.1
  is doing something evil.
 
  We've looked into this in the past, so it is a known issue, but I need
  to handle these
  separately.
 
  We got the results of a run of those changes through the autobuilder
  without the noise of other failures. The error reporting system shows:
 
  http://errors.yoctoproject.org/Errors/Search/?items=10query=d687cdfd04f3d97923c93239ea902bb38e2ea336
 
  and I believe we have the following issues:
 
  a) qemux86/qemux86-64 are throwing warnings about errors in logs
  b) perf has some weird make race
  c) the qemuarm build looks like qemu either segfaulted or was killed
  d) we're occasionally seeing 3.19 and 3.14 fetch failures:
  https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
  https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio

 I explained to Ross that dependent layers need to be updated if they set
 their own SRCREV_meta, since the repository is completely different. I
 sent a patch for meta-intel to deal with it. Obviously, I only built with the
 core BSPs during testing.

 That could explain d). I believe c) is from the ongoing selftest issues
 we're having and I we've work in progress for that. That leaves a) and
 b) to look into and fix.

 I'll definitely need help on these, since I wasn't seeing any of these issues
 during my testing. Otherwise, this won't be done until September (vacation
 and other issues to deal with).

 But I'll see what I can do.

 I unfortunately can't merge anything but critical kernel patches until
 these go in as well
 since the meta branch is gone in the new scripts, which means SRCREV_meta is
 a constant conflict.

 a) should be straightfoward to fix, its just updating the message
 whitelists (again).

I'm building a fresh qemux86-64 now, I'm going to see if the warnings
are something
I should fix, versus the whitelist. I should know tomorrow on this one.


 b) I'm less sure about. Are there any race fixes in mainline for perf?
 Hard to believe others don't see that one.

I'm searching as well. I'll share any findings ASAP.

Bruce


 Cheers,

 Richard




-- 
Thou shalt not follow the NULL pointer, for chaos 

[OE-core] [poky][PATCH 1/3] gstreamer1.0: Add patch for Gstreamer 1.4.5 including baseparse, basesink, inputselector

2015-07-23 Thread Yuqing Zhu
Bug fix

-[baseparse] Handle base parse error

-[basesink] Fix QoS/lateness checking if subclass implements 
prepare/prepare_list
vfuncs

-[inputselector] Block EOS event of inactive pad, send the event after the pad 
actived

Signed-off-by: Yuqing Zhu b54...@freescale.com
---
 .../0001-baseparse-handle-base-parse-error.patch   |  37 +
 ...x-QoS-lateness-checking-if-subclass-imple.patch |  70 +
 ...cky-events-haven-t-send-out-when-ac-1-4-1.patch | 167 +
 .../gstreamer/gstreamer1.0_1.4.5.bb|   3 +
 4 files changed, 277 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-baseparse-handle-base-parse-error.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch
 create mode 100755 
meta/recipes-multimedia/gstreamer/gstreamer1.0/inputselector-sticky-events-haven-t-send-out-when-ac-1-4-1.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-baseparse-handle-base-parse-error.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-baseparse-handle-base-parse-error.patch
new file mode 100644
index 000..28728d8
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-baseparse-handle-base-parse-error.patch
@@ -0,0 +1,37 @@
+From 430bbeee450e3fd4fc4d0ccb627de7d3f05a9736 Mon Sep 17 00:00:00 2001
+From: Lyon Wang lyon.w...@freescale.com
+Date: Thu, 23 Apr 2015 14:11:11 +0800
+Subject: [PATCH] [baseparse] handle base parse error
+
+There is no need to send GST_ELEMENT_ERROR
+becuase ohter tracks may still good to play.
+no need to end the element, just print error message is enough
+
+Bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=741542
+Upstream Status: submitted
+
+Signed-off-by: Lyon Wang lyon.w...@freescale.com
+---
+ libs/gst/base/gstbaseparse.c |6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/libs/gst/base/gstbaseparse.c b/libs/gst/base/gstbaseparse.c
+index 57e78bb..31bf0c0 100644
+--- a/libs/gst/base/gstbaseparse.c
 b/libs/gst/base/gstbaseparse.c
+@@ -1151,8 +1151,10 @@ gst_base_parse_sink_event_default (GstBaseParse * 
parse, GstEvent * event)
+ 
+   /* If we STILL have zero frames processed, fire an error */
+   if (parse-priv-framecount == 0) {
+-GST_ELEMENT_ERROR (parse, STREAM, WRONG_TYPE,
+-(No valid frames found before end of stream), (NULL));
++  /*  GST_ELEMENT_ERROR (parse, STREAM, WRONG_TYPE,
++(No valid frames found before end of stream), (NULL));*/
++GST_ERROR_OBJECT(parse, No valid frames decoded before end of 
stream);
++
+   }
+   /* newsegment and other serialized events before eos */
+   gst_base_parse_push_pending_events (parse);
+-- 
+1.7.9.5
+
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch
new file mode 100644
index 000..9cb1764
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch
@@ -0,0 +1,70 @@
+From 6914566ed6a89c96973a578aa5ecd01ee68cdcfd Mon Sep 17 00:00:00 2001
+From: Jian jian...@freescale.com
+Date: Thu, 14 May 2015 15:49:43 +0800
+Subject: [PATCH] basesink: Fix QoS/lateness checking if subclass implements
+ prepare/prepare_list vfuncs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+In basesink functions gst_base_sink_chain_unlocked(), below code is used to
+checking if buffer is late before doing prepare call to save some effort:
+if (syncable  do_sync)
+  late =
+  gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
+  GST_CLOCK_EARLY, 0, FALSE);
+
+if (G_UNLIKELY (late))
+  goto dropped;
+
+But this code has problem, it should calculate jitter based on current media
+clock, rather than just passing 0. I found it will drop all the frames when
+rewind in slow speed, such as -2X.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=749258
+
+Upstream Status: Backport
+---
+ libs/gst/base/gstbasesink.c |   26 ++
+ 1 file changed, 22 insertions(+), 4 deletions(-)
+
+diff --git a/libs/gst/base/gstbasesink.c b/libs/gst/base/gstbasesink.c
+index a505695..5fb2d6a 100644
+--- a/libs/gst/base/gstbasesink.c
 b/libs/gst/base/gstbasesink.c
+@@ -3369,10 +3369,28 @@ gst_base_sink_chain_unlocked (GstBaseSink * basesink, 
GstPad * pad,
+ if (G_UNLIKELY (stepped))
+   goto dropped;
+ 
+-if (syncable  do_sync)
+-  late =
+-  gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
+-  GST_CLOCK_EARLY, 0, FALSE);
++if (syncable  do_sync) {
++  GstClock *clock;
++
++  GST_OBJECT_LOCK (basesink);
++  clock = GST_ELEMENT_CLOCK (basesink);
++  if (clock  GST_STATE 

[OE-core] [PATCH] sed: rrec on locale-base-ru-ru, not rdep

2015-07-23 Thread Abdur Rehman
This locale package isn't guaranteed to exist, depending on the value of
GLIBC_GENERATE_LOCALES.

The value of GLIBC_GENERATE_LOCALES can be specified to not contain
locale-base-ru-ru, thus resulting in unsatisfied dependency. Its better
to remove hardcoded dependency upon locale-base-ru-ru in favor of a
recommendation, as this locale isn't always available depending upon the
value of GLIBC_GENERATE_LOCALES.

Signed-off-by: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Abdur Rehman abdur_reh...@mentor.com
---
 meta/recipes-extended/sed/sed_4.2.2.bb |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sed/sed_4.2.2.bb 
b/meta/recipes-extended/sed/sed_4.2.2.bb
index a1e3483..5da3355 100644
--- a/meta/recipes-extended/sed/sed_4.2.2.bb
+++ b/meta/recipes-extended/sed/sed_4.2.2.bb
@@ -15,7 +15,8 @@ SRC_URI[md5sum] = 4111de4faa3b9848a0686b2f260c5056
 SRC_URI[sha256sum] = 
fea0a94d4b605894f3e2d5572e3f96e4413bcad3a085aae7367c2cf07908b2ff
 
 inherit autotools texinfo update-alternatives gettext ptest
-RDEPENDS_${PN}-ptest += make locale-base-ru-ru ${PN}
+RDEPENDS_${PN}-ptest += make ${PN}
+RRECOMMENDS_${PN}-ptest += locale-base-ru-ru
 
 EXTRA_OECONF = --disable-acl \
 ${@bb.utils.contains('PTEST_ENABLED', '1', 
'--enable-regex-tests', '', d)}
-- 
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 v2 2/2] kernel: Pass sysroot mkimage to kernel makefile

2015-07-23 Thread Richard Purdie
On Tue, 2015-07-21 at 15:23 +0800, zhe...@windriver.com wrote:
 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

${STAGING_BINDIR_NATIVE} should be in PATH ahead of the usual system
paths. Why therefore is this necessary? Is something resetting PATH?

Cheers,

Richard

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


[OE-core] [PATCH] oeqa/sshcontrol: Ensure we don't trigger ssh-askpass

2015-07-23 Thread Richard Purdie
If DISPLAY is set, ssh-askpass can be triggered which is not what
we want in the middle of sanity tests. We can disable this by
unsetting DISPLAY.

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

diff --git a/meta/lib/oeqa/utils/sshcontrol.py 
b/meta/lib/oeqa/utils/sshcontrol.py
index 1c81795..4f8d3d2 100644
--- a/meta/lib/oeqa/utils/sshcontrol.py
+++ b/meta/lib/oeqa/utils/sshcontrol.py
@@ -10,6 +10,7 @@ import subprocess
 import time
 import os
 import select
+import copy
 
 
 class SSHProcess(object):
@@ -31,6 +32,12 @@ class SSHProcess(object):
 self.starttime = None
 self.logfile = None
 
+# Unset DISPLAY which means we won't trigger SSH_ASKPASS
+env = copy.copy(os.environ)
+if DISPLAY in env:
+del env['DISPLAY']
+self.options['env'] = env
+
 def log(self, msg):
 if self.logfile:
 with open(self.logfile, a) as f:


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


Re: [OE-core] [poky][PATCH 1/3] gstreamer1.0: Add patch for Gstreamer 1.4.5 including baseparse, basesink, inputselector

2015-07-23 Thread Otavio Salvador
On Thu, Jul 23, 2015 at 10:29 AM, Yuqing Zhu b54...@freescale.com wrote:
 Bug fix

 -[baseparse] Handle base parse error

This patch seems to be under discussion at GStreamer team and no
agreement has been made yet; this shouldn't be included in OE-Core.

 -[basesink] Fix QoS/lateness checking if subclass implements 
 prepare/prepare_list
 vfuncs

 -[inputselector] Block EOS event of inactive pad, send the event after the 
 pad actived

Fine. Both need fix in Upstream-Status (dash needs to be included,
plus version it has been backported from)

and finally please split it in two patches.

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


[OE-core] [PATCH v2] oeqa/buildoptions.py: automate test case 929: check for correct GPL licenses

2015-07-23 Thread Costin Constantin
Signed-off-by: Costin Constantin costin.c.constan...@intel.com
---
 meta/lib/oeqa/selftest/buildoptions.py | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/meta/lib/oeqa/selftest/buildoptions.py 
b/meta/lib/oeqa/selftest/buildoptions.py
index e79be9e..ab009f2 100644
--- a/meta/lib/oeqa/selftest/buildoptions.py
+++ b/meta/lib/oeqa/selftest/buildoptions.py
@@ -132,6 +132,36 @@ class BuildImagesTest(oeSelfTest):
 res = bitbake(core-image-directfb, ignore_status=True)
 self.assertEqual(res.status, 0, \ncoreimagedirectfb failed to build. 
Please check logs for further details.\nbitbake output %s % res.output)
 
+@testcase(929)
+def test_gpl_licenses(self):
+
+Test for checking that correct GPL licenses are used when explicitly 
required.
+
+self.add_command_to_tearDown('cleanup-workdir')
+self.write_config(MACHINE = \qemux86\\nINHERIT += 
\archiver\\nARCHIVER_MODE[src] = \original\\nCOPYLEFT_LICENSE_INCLUDE = 
\GPLv2* GPLv3*\)
+res = bitbake(core-image-minimal, ignore_status=True)
+self.remove_config(MACHINE = \qemux86\\nINHERIT += 
\archiver\\nARCHIVER_MODE[src] = \original\\nCOPYLEFT_LICENSE_INCLUDE = 
\GPLv2* GPLv3*\)
+self.assertEqual(res.status, 0, core-image-minimal didn't build. 
Please check logs for further details %s % res.output)
+built_pkgs_list = os.listdir(self.builddir + 
/tmp/deploy/sources/i586-poky-linux/)# the list containing built pkgs with 
ver.
+pkg_name_split = [i.split(-) for i in built_pkgs_list]
+pkgs = [] # this will contain the pkgs name as found in 
tmp/deploy/licenses
+for i in pkg_name_split:
+  name = 
+  for j in i:
+if i.index(j) == 0:
+  name = j
+elif j.isalpha() and i.index(j) != 0:
+  name = name + - + j
+else:
+  pkgs.append(name)
+  break
+license_dir = self.builddir + /tmp/deploy/licenses/
+for i in pkgs:
+  if os.path.isdir(license_dir + i):
+self.assertTrue(g.glob(license_dir + i + /*GPL*), couldn't find 
GPL license in  + license_dir + for package  + i)
+  else:
+self.log.info(\nNo license dir for %s % i)
+
 class ArchiverTest(oeSelfTest):
 @testcase(926)
 def test_arch_work_dir_and_export_source(self):
-- 
2.1.4

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


[OE-core] Rebuilding STAGING_KERNEL_DIR from sstate cache

2015-07-23 Thread Gamma.Dean
I have a user space application that needs to reference a header file from 
STAGING_KERNEL_DIR.  If I do a fresh build using an already populated sstate 
cache STAGING_KERNEL_DIR doesn't get populated so if I then try to rebuild my 
application the build fails.  Looking through module-base.bbclass I found the 
following line which fixes the problem:

  do_configure[depends] += virtual/kernel:do_shared_workdir

This forces STAGING_KERNEL_DIR to get built but it requires the kernel to 
completely rebuild which can take a while.  I mostly just wanted to write this 
down for anyone that finds themselves in the same situation but I was also 
wondering if there is another way to get STAGING_KERNEL_DIR assembled from 
sstate cache that wouldn't require a kernel rebuild.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2015-07-23 Thread He Zhe
Ping.

On 07/21/2015 03:23 PM, 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.
  - 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(-)


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


[OE-core] meta-toolchain-qt

2015-07-23 Thread Lukas Plazovnik
hello,

I've got a problem in the do_populate_sdk stage

compiling works fine but then i got an error of missing dependencies(almost
everything?)

NOTE:
/home/lukas/yocto/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/opkg-cl
-f
/home/lukas/yocto/openembedded-core/build/tmp-glibc/work/cortexa9-vfp-neon-oe-linux-gnueabi/meta-toolchain-qt/1.0-r7/opkg.conf
-o
/home/lukas/yocto/openembedded-core/build/tmp-glibc/work/cortexa9-vfp-neon-oe-linux-gnueabi/meta-toolchain-qt/1.0-r7/sdk/image/usr/local/oecore-x86_64/sysroots/cortexa9-vfp-neon-oe-linux-gnueabi
--force_postinstall --prefer-arch-to-version   install
packagegroup-qt-toolchain-target
ERROR: Unable to install packages. Command
'/home/lukas/yocto/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/opkg-cl
-f
/home/lukas/yocto/openembedded-core/build/tmp-glibc/work/cortexa9-vfp-neon-oe-linux-gnueabi/meta-toolchain-qt/1.0-r7/opkg.conf
-o
/home/lukas/yocto/openembedded-core/build/tmp-glibc/work/cortexa9-vfp-neon-oe-linux-gnueabi/meta-toolchain-qt/1.0-r7/sdk/image/usr/local/oecore-x86_64/sysroots/cortexa9-vfp-neon-oe-linux-gnueabi
--force_postinstall --prefer-arch-to-version   install
packagegroup-qt-toolchain-target' returned 255:
Installing packagegroup-qt-toolchain-target (1.0-r0) on root.
Downloading
file:/home/lukas/yocto/openembedded-core/build/tmp-glibc/deploy/ipk/all/packagegroup-qt-toolchain-target_1.0-r0_all.ipk.
libc6-dev: unsatisfied recommendation for glibc-extra-nss-dev
libc6-dev: unsatisfied recommendation for glibc-thread-db-dev
libc6-dev: unsatisfied recommendation for libsegfault-dev
libc6-dev: unsatisfied recommendation for libgcc-initial-dev
libc6-dev: unsatisfied recommendation for libcidn-dev
icu-dev: unsatisfied recommendation for libicuuc-dev
icu-dev: unsatisfied recommendation for libicudata-dev
icu-dev: unsatisfied recommendation for libicuio-dev
icu-dev: unsatisfied recommendation for libiculx-dev
icu-dev: unsatisfied recommendation for libicule-dev
icu-dev: unsatisfied recommendation for libicui18n-dev
icu-dev: unsatisfied recommendation for libicutu-dev
openssl-dev: unsatisfied recommendation for libcrypto-dev
openssl-dev: unsatisfied recommendation for libssl-dev
libtiff-dev: unsatisfied recommendation for liblzma-dev
libtiff-dev: unsatisfied recommendation for tiffxx-dev
xz-dev: unsatisfied recommendation for liblzma-dev
libqtdbus-dev: unsatisfied recommendation for sqlite3-dev
shadow-dev: unsatisfied recommendation for util-linux-sulogin-dev
shadow-dev: unsatisfied recommendation for update-alternatives-opkg-dev
shadow-dev: unsatisfied recommendation for shadow-base-dev
dbus-dev: unsatisfied recommendation for shadow-sysroot-dev
dbus-dev: unsatisfied recommendation for dbus-lib-dev
dbus-dev: unsatisfied recommendation for initscripts-functions-dev
libx11-dev: unsatisfied recommendation for libx11-xcb-dev
libxcb-dev: unsatisfied recommendation for libxcb-shape-dev
libxcb-dev: unsatisfied recommendation for libxcb-dpms-dev
libxcb-dev: unsatisfied recommendation for libxcb-render-dev
libxcb-dev: unsatisfied recommendation for libxcb-shm-dev
libxcb-dev: unsatisfied recommendation for libxcb-dri3-dev
libxcb-dev: unsatisfied recommendation for libxcb-damage-dev
libxcb-dev: unsatisfied recommendation for libxcb-glx-dev
libxcb-dev: unsatisfied recommendation for libxcb-composite-dev
libxcb-dev: unsatisfied recommendation for libxcb-res-dev
libxcb-dev: unsatisfied recommendation for libxcb-xvmc-dev
libxcb-dev: unsatisfied recommendation for libxcb-xkb-dev
libxcb-dev: unsatisfied recommendation for libxcb-sync-dev
libxcb-dev: unsatisfied recommendation for libxcb-xevie-dev
libxcb-dev: unsatisfied recommendation for libxcb-dri2-dev
libxcb-dev: unsatisfied recommendation for libxcb-randr-dev
libxcb-dev: unsatisfied recommendation for libxcb-record-dev
libxcb-dev: unsatisfied recommendation for libxcb-xprint-dev
libxcb-dev: unsatisfied recommendation for libxcb-xv-dev
libxcb-dev: unsatisfied recommendation for libxcb-xtest-dev
libxcb-dev: unsatisfied recommendation for libxcb-screensaver-dev
libxcb-dev: unsatisfied recommendation for libxcb-present-dev
libxcb-dev: unsatisfied recommendation for libxcb-xf86dri-dev
libxcb-dev: unsatisfied recommendation for libxcb-xinerama-dev
libxcb-dev: unsatisfied recommendation for libxcb-xfixes-dev
initscripts-dev: unsatisfied recommendation for update-alternatives-opkg-dev
initscripts-dev: unsatisfied recommendation for initscripts-functions-dev
libxrender-dev: unsatisfied recommendation for xdmcp-dev
libqtcore-dev: unsatisfied recommendation for sqlite3-dev
pulseaudio-dev: unsatisfied recommendation for
pulseaudio-module-position-event-sounds-dev
pulseaudio-dev: unsatisfied recommendation for
pulseaudio-module-card-restore-dev
pulseaudio-dev: unsatisfied recommendation for libltdl-dev
libgdbm-dev: unsatisfied recommendation for gdbm-compat-dev
package libtinfo5 suggests installing ncurses-terminfo
python-pygobject-dev: unsatisfied recommendation for python-textutils-dev

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

2015-07-23 Thread Richard Purdie
On Wed, 2015-07-22 at 15:48 -0400, Bruce Ashfield wrote:
 On Wed, Jul 22, 2015 at 10:03 AM, Bruce Ashfield
 bruce.ashfi...@gmail.com wrote:
  On Tue, Jul 21, 2015 at 11:21 AM, Bruce Ashfield
  bruce.ashfi...@windriver.com wrote:
  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.
 
  As a follow up, my qemuarm boots that worked on Friday, are now hanging.
  I'm bisecting to find out what happened.
 
 And a final follow up.
 
 qemuarm (console and graphics) works fine .. but only if you use gcc
 4.9.x, gcc 5.1
 is doing something evil.
 
 We've looked into this in the past, so it is a known issue, but I need
 to handle these
 separately.

We got the results of a run of those changes through the autobuilder
without the noise of other failures. The error reporting system shows:

http://errors.yoctoproject.org/Errors/Search/?items=10query=d687cdfd04f3d97923c93239ea902bb38e2ea336

and I believe we have the following issues:

a) qemux86/qemux86-64 are throwing warnings about errors in logs
b) perf has some weird make race
c) the qemuarm build looks like qemu either segfaulted or was killed
d) we're occasionally seeing 3.19 and 3.14 fetch failures:
https://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/394/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/87/steps/Running%20oe-selftest/logs/stdio

To try and promote more sstate cache reuse whilst we sort the remaining
issues, I merged the linux-libc-header part, we need to get the above
fixed before the other pieces can merge.

Cheers,

Richard



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


[OE-core] Fwd: meta-toolchain-qt

2015-07-23 Thread Lukas Plazovnik
additionally: If i run a qt program at the operatin system i get:

Unable to load library icui18n Cannot load library icui18n: (icui18n:
cannot open shared object file: No such file or directory)

any idea?

-- Forwarded message --
From: Lukas Plazovnik lukas.plazov...@gmail.com
Date: 2015-07-23 10:06 GMT+02:00
Subject: meta-toolchain-qt
To: openembedded-core@lists.openembedded.org


hello,

I've got a problem in the do_populate_sdk stage

compiling works fine but then i got an error of missing dependencies(almost
everything?)

NOTE:
/home/lukas/yocto/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/opkg-cl
-f
/home/lukas/yocto/openembedded-core/build/tmp-glibc/work/cortexa9-vfp-neon-oe-linux-gnueabi/meta-toolchain-qt/1.0-r7/opkg.conf
-o
/home/lukas/yocto/openembedded-core/build/tmp-glibc/work/cortexa9-vfp-neon-oe-linux-gnueabi/meta-toolchain-qt/1.0-r7/sdk/image/usr/local/oecore-x86_64/sysroots/cortexa9-vfp-neon-oe-linux-gnueabi
--force_postinstall --prefer-arch-to-version   install
packagegroup-qt-toolchain-target
ERROR: Unable to install packages. Command
'/home/lukas/yocto/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/opkg-cl
-f
/home/lukas/yocto/openembedded-core/build/tmp-glibc/work/cortexa9-vfp-neon-oe-linux-gnueabi/meta-toolchain-qt/1.0-r7/opkg.conf
-o
/home/lukas/yocto/openembedded-core/build/tmp-glibc/work/cortexa9-vfp-neon-oe-linux-gnueabi/meta-toolchain-qt/1.0-r7/sdk/image/usr/local/oecore-x86_64/sysroots/cortexa9-vfp-neon-oe-linux-gnueabi
--force_postinstall --prefer-arch-to-version   install
packagegroup-qt-toolchain-target' returned 255:
Installing packagegroup-qt-toolchain-target (1.0-r0) on root.
Downloading
file:/home/lukas/yocto/openembedded-core/build/tmp-glibc/deploy/ipk/all/packagegroup-qt-toolchain-target_1.0-r0_all.ipk.
libc6-dev: unsatisfied recommendation for glibc-extra-nss-dev
libc6-dev: unsatisfied recommendation for glibc-thread-db-dev
libc6-dev: unsatisfied recommendation for libsegfault-dev
libc6-dev: unsatisfied recommendation for libgcc-initial-dev
libc6-dev: unsatisfied recommendation for libcidn-dev
icu-dev: unsatisfied recommendation for libicuuc-dev
icu-dev: unsatisfied recommendation for libicudata-dev
icu-dev: unsatisfied recommendation for libicuio-dev
icu-dev: unsatisfied recommendation for libiculx-dev
icu-dev: unsatisfied recommendation for libicule-dev
icu-dev: unsatisfied recommendation for libicui18n-dev
icu-dev: unsatisfied recommendation for libicutu-dev
openssl-dev: unsatisfied recommendation for libcrypto-dev
openssl-dev: unsatisfied recommendation for libssl-dev
libtiff-dev: unsatisfied recommendation for liblzma-dev
libtiff-dev: unsatisfied recommendation for tiffxx-dev
xz-dev: unsatisfied recommendation for liblzma-dev
libqtdbus-dev: unsatisfied recommendation for sqlite3-dev
shadow-dev: unsatisfied recommendation for util-linux-sulogin-dev
shadow-dev: unsatisfied recommendation for update-alternatives-opkg-dev
shadow-dev: unsatisfied recommendation for shadow-base-dev
dbus-dev: unsatisfied recommendation for shadow-sysroot-dev
dbus-dev: unsatisfied recommendation for dbus-lib-dev
dbus-dev: unsatisfied recommendation for initscripts-functions-dev
libx11-dev: unsatisfied recommendation for libx11-xcb-dev
libxcb-dev: unsatisfied recommendation for libxcb-shape-dev
libxcb-dev: unsatisfied recommendation for libxcb-dpms-dev
libxcb-dev: unsatisfied recommendation for libxcb-render-dev
libxcb-dev: unsatisfied recommendation for libxcb-shm-dev
libxcb-dev: unsatisfied recommendation for libxcb-dri3-dev
libxcb-dev: unsatisfied recommendation for libxcb-damage-dev
libxcb-dev: unsatisfied recommendation for libxcb-glx-dev
libxcb-dev: unsatisfied recommendation for libxcb-composite-dev
libxcb-dev: unsatisfied recommendation for libxcb-res-dev
libxcb-dev: unsatisfied recommendation for libxcb-xvmc-dev
libxcb-dev: unsatisfied recommendation for libxcb-xkb-dev
libxcb-dev: unsatisfied recommendation for libxcb-sync-dev
libxcb-dev: unsatisfied recommendation for libxcb-xevie-dev
libxcb-dev: unsatisfied recommendation for libxcb-dri2-dev
libxcb-dev: unsatisfied recommendation for libxcb-randr-dev
libxcb-dev: unsatisfied recommendation for libxcb-record-dev
libxcb-dev: unsatisfied recommendation for libxcb-xprint-dev
libxcb-dev: unsatisfied recommendation for libxcb-xv-dev
libxcb-dev: unsatisfied recommendation for libxcb-xtest-dev
libxcb-dev: unsatisfied recommendation for libxcb-screensaver-dev
libxcb-dev: unsatisfied recommendation for libxcb-present-dev
libxcb-dev: unsatisfied recommendation for libxcb-xf86dri-dev
libxcb-dev: unsatisfied recommendation for libxcb-xinerama-dev
libxcb-dev: unsatisfied recommendation for libxcb-xfixes-dev
initscripts-dev: unsatisfied recommendation for update-alternatives-opkg-dev
initscripts-dev: unsatisfied recommendation for initscripts-functions-dev
libxrender-dev: unsatisfied recommendation for xdmcp-dev
libqtcore-dev: unsatisfied recommendation for sqlite3-dev
pulseaudio-dev: 

[OE-core] [PATCH] qemu: upgrade to 2.4.0-rc2

2015-07-23 Thread Cristian Iorga
Various bugfixes.
Ongoing upgrade en route to final 2.4.0.

Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
 meta/recipes-devtools/qemu/{qemu_2.4.0-rc1.bb = qemu_2.4.0-rc2.bb} | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/qemu/{qemu_2.4.0-rc1.bb = qemu_2.4.0-rc2.bb} 
(82%)

diff --git a/meta/recipes-devtools/qemu/qemu_2.4.0-rc1.bb 
b/meta/recipes-devtools/qemu/qemu_2.4.0-rc2.bb
similarity index 82%
rename from meta/recipes-devtools/qemu/qemu_2.4.0-rc1.bb
rename to meta/recipes-devtools/qemu/qemu_2.4.0-rc2.bb
index 7c2d782..2aea37f 100644
--- a/meta/recipes-devtools/qemu/qemu_2.4.0-rc1.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.4.0-rc2.bb
@@ -8,11 +8,11 @@ SRC_URI += 
file://configure-fix-Darwin-target-detection.patch \
 file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \

 SRC_URI_prepend = 
http://wiki.qemu-project.org/download/${BPN}-${REALPV}.tar.bz2;
-SRC_URI[md5sum] = 3c8d29abea2b61516bb7ef5b5ff62d03
-SRC_URI[sha256sum] = 
c0c6072ed9196ee17b4120f03fa9cdf9f63e893f7cb8008aa12ea1678450a481
+SRC_URI[md5sum] = f634f461acc43774025ec1876fa27ce5
+SRC_URI[sha256sum] = 
ad86df38f10ad8b5fc03a7ec32b0080c0a5ab9e01fdaa7d5ba26f8591dd9b2fe
 
 S=${WORKDIR}/${BPN}-${REALPV}
-REALPV = 2.4.0-rc1
+REALPV = 2.4.0-rc2
 PV = 2.3.99+${REALPV}
 
 COMPATIBLE_HOST_class-target_mips64 = null
-- 
2.1.4

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


Re: [OE-core] [PATCH 1/2] ptest-runner: Added timeout per tests.

2015-07-23 Thread Musat, George L
Hi Ross,

I ran the suite yesterday on a NUC with the timeout set at 10 minutes and the 
whole glib was ran:
“SUMMARY: total=215; passed=213; skipped=0; failed=2; user=105.5s; 
system=108.8s; maxrss=189256
END: /usr/lib/glib-2.0/ptest”

But feel free to modify the timeout to any value you think is better.

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Wednesday, July 22, 2015 6:52 PM
To: Musat, George L
Cc: OE-core
Subject: Re: [OE-core] [PATCH 1/2] ptest-runner: Added timeout per tests.


On 22 July 2015 at 12:58, Lucian Musat 
george.l.mu...@intel.commailto:george.l.mu...@intel.com wrote:
+timeout 10m ./run-ptest || ANYFAILED=yes

I'm pretty sure the glib test suite takes *way* longer than 10 minutes to run...

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


[OE-core] qt5 webkit Nothing RPROVIDES 'liborc-0.4'

2015-07-23 Thread Life Life
Hello,

I'm trying to build qt5 webkit. I seen this error message

Build Configuration:
BB_VERSION= 1.24.0
BUILD_SYS = x86_64-linux
NATIVELSBSTRING   = Ubuntu-14.04
TARGET_SYS= arm-poky-linux-gnueabi
MACHINE   = phyboard-wega-am335x-2
DISTRO= poky
DISTRO_VERSION= 1.7
TUNE_FEATURES = arm armv7a vfp thumb neon callconvention-hard cortexa8
TARGET_FPU= vfp-neon
meta
meta-yocto= (nobranch):9aff3a4ec058a1a1149d026ebedcc6251089fffb
meta-phytec   = (nobranch):ccf1c78f312f84933b90926e9bf4f72de59e8e94
meta-phyam335x= (nobranch):a6c488b268d0c2e506f293221703dafcc05b9610
meta-oe
meta-networking
meta-python
meta-multimedia   = (nobranch):9efaed99125b1c4324663d9a1b2d3319c74e7278
meta-qt5  = master:6d9e2a6dfc21f7d9a3a11b4bcb426b5dfe6feaeb
meta-ruby = (nobranch):9efaed99125b1c4324663d9a1b2d3319c74e7278

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 3367 tasks of which 3367 didn't need to be
rerun and all succeeded.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'liborc-0.4' (but
/home/xy/yocto/build/recipes/images/
core-image-base-edited-20150723-135844.bb RDEPENDS on or otherwise requires
it)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core