[OE-core] [PATCH v3][0/2] Yocto Bug #6149
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
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
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
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
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
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
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__
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
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
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)
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)
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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'
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