date:20170807

Re: [yocto] extensible SDK build failure

2017-08-07 Thread Russell Peterson

Thanks, Paul.

That helped, however, I still see some of the same “unexpected” errors for perf 
tasks as well as my virtual/kernel tasks.  

I presume SDK_INHERIT_BLACKLIST excludes the use of the class for the SDK… but 
I am unclear as to why I see these errors with my linux-yocto-xxx.bb 
recipe/tasks.

Thanks again.

Russell


> On Aug 7, 2017, at 2:49 AM, Paul Eggleton  
> wrote:
> 
> Hi Russell,
> 
> On Wednesday, 2 August 2017 8:34:11 PM CEST RUSSELL PETERSON wrote:
>> Frustrating in that I can't get the eSDK to fully build. I'm past the issue
>> with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
>> below. Anyone seen this before? From what I can tell these tasks are being
>> executed out of the run queue.  Not all the messages are from cve-check but
>> most.
> 
> So there are certain classes that will interfere with the ability of the eSDK 
> to lock down the configuration, I wasn't aware of it but cve-check.bbclass is 
> apparently one of them. Try adding this to your configuration:
> 
> SDK_INHERIT_BLACKLIST = "buildhistory icecc cve-check"
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-alexa-demo][PATCH 1/3] Moved meta-alexa-demo top level to meta-alexapi

2017-08-07 Thread Amanda Brindle

From: Matthew Hansen 

---
 COPYING.MIT => meta-alexapi/COPYING.MIT   | 0
 LICENSE => meta-alexapi/LICENSE   | 0
 README => meta-alexapi/README | 0
 {conf => meta-alexapi/conf}/layer.conf| 0
 .../recipes-connectivity}/libmtp/libmtp_1.1.5.bbappend| 0
 .../alexapi/alexapi/0001-common.sh-Get-rid-of-grep-perl-regex.patch   | 0
 .../0002-setup.sh-Change-some-things-that-don-t-make-sense-fo.patch   | 0
 .../0003-src.config.template.yaml-Set-default-input-to-defaul.patch   | 0
 {recipes-core => meta-alexapi/recipes-core}/alexapi/alexapi_git.bb| 0
 .../recipes-devtools}/python/python-cheroot_5.1.0.bb  | 0
 .../recipes-devtools}/python/python-cherrypy_10.1.1.bb| 0
 .../recipes-devtools}/python/python-memcached_1.58.bb | 0
 .../recipes-devtools}/python/python-pocketsphinx_0.1.3.bb | 0
 .../recipes-devtools}/python/python-portend_1.8.bb| 0
 .../recipes-devtools}/python/python-py-getch_1.0.1.bb | 0
 .../recipes-devtools}/python/python-tempora_1.6.1.bb  | 0
 .../recipes-devtools}/python/python-vlc_1.1.2.bb  | 0
 .../recipes-devtools}/python/python-wave_0.0.2.bb | 0
 .../recipes-devtools}/python/python-webrtcvad_2.0.10.bb   | 0
 .../recipes-multimedia}/vlc/vlc_2.2.2.bbappend| 0
 20 files changed, 0 insertions(+), 0 deletions(-)
 rename COPYING.MIT => meta-alexapi/COPYING.MIT (100%)
 rename LICENSE => meta-alexapi/LICENSE (100%)
 rename README => meta-alexapi/README (100%)
 rename {conf => meta-alexapi/conf}/layer.conf (100%)
 rename {recipes-connectivity => 
meta-alexapi/recipes-connectivity}/libmtp/libmtp_1.1.5.bbappend (100%)
 rename {recipes-core => 
meta-alexapi/recipes-core}/alexapi/alexapi/0001-common.sh-Get-rid-of-grep-perl-regex.patch
 (100%)
 rename {recipes-core => 
meta-alexapi/recipes-core}/alexapi/alexapi/0002-setup.sh-Change-some-things-that-don-t-make-sense-fo.patch
 (100%)
 rename {recipes-core => 
meta-alexapi/recipes-core}/alexapi/alexapi/0003-src.config.template.yaml-Set-default-input-to-defaul.patch
 (100%)
 rename {recipes-core => meta-alexapi/recipes-core}/alexapi/alexapi_git.bb 
(100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-cheroot_5.1.0.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-cherrypy_10.1.1.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-memcached_1.58.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-pocketsphinx_0.1.3.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-portend_1.8.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-py-getch_1.0.1.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-tempora_1.6.1.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-vlc_1.1.2.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-wave_0.0.2.bb (100%)
 rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-webrtcvad_2.0.10.bb (100%)
 rename {recipes-multimedia => 
meta-alexapi/recipes-multimedia}/vlc/vlc_2.2.2.bbappend (100%)

diff --git a/COPYING.MIT b/meta-alexapi/COPYING.MIT
similarity index 100%
rename from COPYING.MIT
rename to meta-alexapi/COPYING.MIT
diff --git a/LICENSE b/meta-alexapi/LICENSE
similarity index 100%
rename from LICENSE
rename to meta-alexapi/LICENSE
diff --git a/README b/meta-alexapi/README
similarity index 100%
rename from README
rename to meta-alexapi/README
diff --git a/conf/layer.conf b/meta-alexapi/conf/layer.conf
similarity index 100%
rename from conf/layer.conf
rename to meta-alexapi/conf/layer.conf
diff --git a/recipes-connectivity/libmtp/libmtp_1.1.5.bbappend 
b/meta-alexapi/recipes-connectivity/libmtp/libmtp_1.1.5.bbappend
similarity index 100%
rename from recipes-connectivity/libmtp/libmtp_1.1.5.bbappend
rename to meta-alexapi/recipes-connectivity/libmtp/libmtp_1.1.5.bbappend
diff --git 
a/recipes-core/alexapi/alexapi/0001-common.sh-Get-rid-of-grep-perl-regex.patch 
b/meta-alexapi/recipes-core/alexapi/alexapi/0001-common.sh-Get-rid-of-grep-perl-regex.patch
similarity index 100%
rename from 
recipes-core/alexapi/alexapi/0001-common.sh-Get-rid-of-grep-perl-regex.patch
rename to 
meta-alexapi/recipes-core/alexapi/alexapi/0001-common.sh-Get-rid-of-grep-perl-regex.patch
diff --git 
a/recipes-core/alexapi/alexapi/0002-setup.sh-Change-some-things-that-don-t-make-sense-fo.patch
 
b/meta-alexapi/recipes-core/alexapi/alexapi/0002-setup.sh-Change-some-things-that-don-t-make-sense-fo.patch
similarity

[yocto] [meta-alexa-demo][PATCH 2/3] Added meta-alexa-led for demo files

2017-08-07 Thread Amanda Brindle

From: Matthew Hansen 

---
 meta-alexa-led/COPYING.MIT |  17 +++
 meta-alexa-led/LICENSE |   2 +
 meta-alexa-led/README  |  64 ++
 meta-alexa-led/conf/layer.conf |  10 ++
 meta-alexa-led/recipes-demo/alexa-led/alexa-led.bb |  16 +++
 .../recipes-demo/alexa-led/files/COPYING.MIT   |  17 +++
 .../recipes-demo/alexa-led/files/LICENSE   |   2 +
 .../recipes-demo/alexa-led/files/index.js  | 142 +
 .../recipes-demo/alexa-led/files/main.js   |  89 +
 9 files changed, 359 insertions(+)
 create mode 100644 meta-alexa-led/COPYING.MIT
 create mode 100644 meta-alexa-led/LICENSE
 create mode 100644 meta-alexa-led/README
 create mode 100644 meta-alexa-led/conf/layer.conf
 create mode 100644 meta-alexa-led/recipes-demo/alexa-led/alexa-led.bb
 create mode 100644 meta-alexa-led/recipes-demo/alexa-led/files/COPYING.MIT
 create mode 100644 meta-alexa-led/recipes-demo/alexa-led/files/LICENSE
 create mode 100644 meta-alexa-led/recipes-demo/alexa-led/files/index.js
 create mode 100755 meta-alexa-led/recipes-demo/alexa-led/files/main.js

diff --git a/meta-alexa-led/COPYING.MIT b/meta-alexa-led/COPYING.MIT
new file mode 100644
index 000..89de354
--- /dev/null
+++ b/meta-alexa-led/COPYING.MIT
@@ -0,0 +1,17 @@
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
diff --git a/meta-alexa-led/LICENSE b/meta-alexa-led/LICENSE
new file mode 100644
index 000..5190d8e
--- /dev/null
+++ b/meta-alexa-led/LICENSE
@@ -0,0 +1,2 @@
+All files in this layer are under the MIT license unless a file specifically 
notes otherwise.
+See COPYING.MIT for license details.
diff --git a/meta-alexa-led/README b/meta-alexa-led/README
new file mode 100644
index 000..c671cfe
--- /dev/null
+++ b/meta-alexa-led/README
@@ -0,0 +1,64 @@
+This README file contains information on the contents of the
+alexa-led layer.
+
+Please see the corresponding sections below for details.
+
+
+Dependencies
+
+
+This layer depends on:
+
+  URI: git://git.openembedded.org/bitbake
+  branch: master
+
+  URI: git://git.openembedded.org/openembedded-core
+  layers: meta
+  branch: master
+
+  URI: git://git.yoctoproject.org/
+  layers: 
+  branch: master
+
+
+Patches
+===
+
+Please submit any patches against the alexa-led layer to the
+ mailing list (x...@.org) and cc: the maintainer:
+
+Maintainer: XXX YY 
+
+
+Table of Contents
+=
+
+  I. Adding the alexa-led layer to your build
+ II. Misc
+
+
+I. Adding the alexa-led layer to your build
+=
+
+--- replace with specific instructions for the alexa-led layer ---
+
+In order to use this layer, you need to make the build system aware of
+it.
+
+Assuming the alexa-led layer exists at the top-level of your
+yocto build tree, you can add it to the build system by adding the
+location of the alexa-led layer to bblayers.conf, along with any
+other layers needed. e.g.:
+
+  BBLAYERS ?= " \
+/path/to/yocto/meta \
+/path/to/yocto/meta-poky \
+/path/to/yocto/meta-yocto-bsp \
+/path/to/yocto/meta-alexa-led \
+"
+
+
+II. Misc
+
+
+--- replace with specific information about the alexa-led layer ---
diff --git a/meta-alexa-led/conf/layer.conf b/meta-alexa-led/conf/layer.conf
new file mode 100644
index 000..d469d0a
--- /dev/null
+++ b/meta-alexa-led/conf/layer.conf
@@ -0,0 +1,10 @@
+# We have a conf and classes directory, add to BBPATH
+BBPATH .= ":${LAYERDIR}"
+
+# We have recipes-* directories, add to BBFILES
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+   ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+BBFILE_COLLECTIONS += "alexa-led"
+BBFILE_PATTERN_alexa-led = "^${LAYERDIR}/"
+BBFILE_PRIORITY_alexa-led = "6"
diff --git a/meta-alexa-led/recipes-demo/alexa-led/alexa-led.bb 
b/meta-alexa-led/recipes-demo/alexa-led/alexa-led.bb

Re: [yocto] Perforce fetcher ignores module and label

2017-08-07 Thread Andrew Bradford

Hi Katu,

Sorry for the delay in my reply, I was on holiday.

On 08/02 10:28, Paul Eggleton wrote:
> Andrew Bradford (on CC) was the last person to make significant changes to 
> that module.
>
> On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:
> > I'm still having problems fetching from Perforce. Is there any
> > documentation based on the latest implementation of the
> > poky/bitbake/lib/bb/fetch2/perforce.py file?

There's some documentation now in the official Yocto Project
documentation location for bitbake fetchers [1].  Prior to my changes
there was very little if any documentation, afaik.

[1]: 
http://www.yoctoproject.org/docs/2.3.1/bitbake-user-manual/bitbake-user-manual.html#perforce-fetcher

> > 2017-07-25 10:05 GMT+01:00 Katu Txakur :
> > 
> > > Hi,
> > >
> > > I'm upgrading a recipe that fetches the source code from Perforce.
> > >
> > > The old recipe was:
> > >
> > > SRC_URI = " \
> > >   p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/pe
> > > rforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST} \
> > >   "
> > >
> > > With the new version of /lib/bb/fetch2/perforce.py, I had to set P4PORT
> > > outside SRC_URI, leaving the recipe with:
> > >
> > > SRC_URI = " \
> > >   p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> > > local/path/relativeto/p4;label=${P4CHANGELIST} \
> > >   "
> > >
> > > The Perforce fetcher kind of works, but it seems to be ignoring the
> > > "module" and the "label" attributes. After reading the Python script I can
> > > see that after the "@", only the substring before the first ";" is used.

Sorry for not making the label change more clear, but you should be able
to simply set SRCREV="labelname" and have the functionality you desire.
However, we don't use labels very often internally, so the use of labels
in SRCREV isn't tested that often by me.

This change to using labels, changelist numbers, and allowing the use of
AUTOREV was made so that the perforce fetcher would act more like the
other source code control system fetchers.  Prior to my changes to the
p4 fetcher, the way that recipes using p4 had to be written seemed
rather awkward to me.  The way it is now isn't perfect, but it's closer
to how the other fetchers act, I think (and hope).

> > > Is there a way to set module and label/changelist? I have several folders
> > > per recipe that I need to map to different subfolders and with the current
> > > script some of the folders don't get fetched.

I'm not sure I understand enough about how you use perforce and what you
mean by mapping different subfolders.  Can you explain this in a more
expanded way to me?  Maybe with some examples?

Thanks,
Andrew
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW32’17

2017-08-07 Thread Jolley, Stephen K

Current Dev Position: YP 2.4 M3 is in QA, patches are being merged for M3

Next Deadline: YP 2.4 M3 Cut off is Aug. 21, 2017


SWAT team rotation: Ross -> Leo on Aug. 4, 2017.

SWAT team rotation: Leo -> Juro on Aug. 11, 2017.

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


Key Status/Updates:

·Based on the 2.4 M2 rc2 QA report we decided to build an rc3 based on 
master as there were many different issues found, many of which were fixed post 
rc2 in master.

·2.4 M2 rc3 is in QA and about 15% complete: 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status

·A new uninative version was released which allows the system to work 
with newer distros with newer gcc and glibc versions.

·Much of the key maintainers time is being taken up with patch review, 
testing and tracking down which patch was responsible for which build failure. 
It does sometimes feel that people expect others to test their patches which 
isn’t the case. Test failures mean batches have to be retested and slow the 
merge of code into master so we’d appreciate people’s attention to detail when 
they do send changes.

·2.2 is struggling due to build issues right now. We need to get these 
resolved in order to be able to merge patches and unblock this release series.


Planned upcoming dot releases:

YP 2.2.2 Cut off June 5, 2017 - Not ready to do an rc2 yet.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Sept. 1, 2017

YP 2.3.2 Release by Sept. 15, 2017


Key YP 2.4 Dates are:

YP 2.4 M2 Cut off is July 17, 2017 - In QA now.

YP 2.4 M2 Release by July 28, 2017

YP 2.4 M3 Cut off is Aug. 21, 2017

YP 2.4 M3 Release by Sept. 1, 2017

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017


Tracking Metrics:

WDD 2433 (last week 2556)

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


Key Status Links for YP:

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

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

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


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

Thanks,

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

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] GPG signed package feeds and packages: opkg update fails with "No public key"

2017-08-07 Thread Andersen, Christian

Hello,

I am trying to sign our ipk-packages and the package feed using GPG. As far as 
I can tell the signatures are correctly generated using this in the local.conf:

INHERIT += "sign_package_feed sign_ipk"
PACKAGE_FEED_GPG_NAME ?= "73CE8000"
PACKAGE_FEED_GPG_PASSPHRASE_FILE ?= "/var/lib/jenkins/.gnupg/passwd.txt"
IPK_GPG_NAME ?= "73CE8000"
IPK_GPG_PASSPHRASE_FILE ?= "/var/lib/jenkins/.gnupg/passwd.txt"
GPG_PATH ?= "/var/lib/jenkins/.gnupg"

The public key is installed using opkg-keyrings and this config:

OPKG_KEYRING_KEYS = "73CE8000"

On the target I am able to verify that the public key is available:

root@scb-anders05:~# opkg-key list
/etc/opkg/trusted.gpg
-
pub   rsa2048 2017-08-04 [SC]
  B104E37136084E68203BB2CD5676B9F373CE8000
uid   [unknown] Company 
sub   rsa2048 2017-08-04 [E]

The opkg.conf contains:

option check_signature 1
#option check_pkg_signature 1
option signature_type gpg-asc

But when I try opkg update I get:

root@scb-anders05:~# opkg update
Downloading http://internalhost:8000/puck/pyro-develop/ipk/all/Packages.gz.
Downloading http://internalhost:8000/puck/pyro-develop/ipk/all/Packages.asc.
Downloading 
http://internalhost:8000/puck/pyro-develop/ipk/cortexa8hf-neon/Packages.gz.
Downloading 
http://internalhost:8000/puck/pyro-develop/ipk/cortexa8hf-neon/Packages.asc.
Downloading http://internalhost:8000/puck/pyro-develop/ipk/scb/Packages.gz.
Downloading http://internalhost:8000/puck/pyro-develop/ipk/scb/Packages.asc.
Collected errors:
* opkg_verify_gpg_signature: Signature status returned error: No public key
* pkg_src_verify: Signature verification failed for all.
* opkg_verify_gpg_signature: Signature status returned error: No public key
* pkg_src_verify: Signature verification failed for cortexa8hf-neon.
* opkg_verify_gpg_signature: Signature status returned error: No public key
* pkg_src_verify: Signature verification failed for scb.

When manually loading the Packages and Packages.asc and verify the signature on 
the target it seems to work:

root@scb-anders05:~# opkg-key adv --verify Packages.asc Packages
Executing: gpg --no-options --no-default-keyring --keyring 
/etc/opkg/trusted.gpg --secret-keyring /etc/opkg/secring.gpg --trustdb-name 
/etc/opkg/trustdb.gpg --verify Packages.asc Packages
gpg: Signature made Fri Aug  4 17:00:52 2017 CEST
gpg:using RSA key 5676B9F373CE8000
gpg: Good signature from "Company " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: B104 E371 3608 4E68 203B  B2CD 5676 B9F3 73CE 8000

Even after changing the trust-level for the public key to 5 (ultimate), opkg 
update does not accept the signature.

Does anybody have an idea what's going on and how I can fix this?

Regards
Christian

KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn HRB 
3924 - USt-Id-Nr./Vat No.: DE 813742170
Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  2351 
16-0 * Telefax: +49  2351 16-2400
Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax +49 
2331 8040-602
Geschäftsführung: Dr.-Ing. Dipl.-Wirt.Ing. Manfred Gerhard, Dipl.-Ing. Marwin 
Kinzl, Dipl.-Oec. Andreas Kostal

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Custom FIT image: circular dependencies issue

2017-08-07 Thread Yegor Yefremov

I've switched to Yocto's master branch from Krogoth and get now
circular dependencies for my kernel recipe:

ERROR: 502 unbuildable tasks were
found.#

  | ETA:  0:00:08
These are usually caused by circular dependencies and any circular
dependency chains found will be printed below. Increase the debug
level to see a list of unbuildable tasks.

Identifying dependency loops (this may take a short while)...

ERROR:
Dependency loop #1 found:
  Task 
/home/user/MyProjects/oss/yocto/poky/meta-baltos/recipes-kernel/linux/linux-yocto-custom.bb:do_create_fitimage
(dependent Tasks ['linux-yocto-custom.bb:do_deploy'])
  Task 
/home/user/MyProjects/oss/yocto/poky/meta-baltos/recipes-kernel/linux/linux-yocto-custom.bb:do_packagedata
(dependent Tasks ['linux-yocto-custom.bb:do_package',
'linux-yocto-custom.bb:do_create_fitimage'])
  Task 
/home/user/MyProjects/oss/yocto/poky/meta-baltos/recipes-kernel/linux/linux-yocto-custom.bb:do_deploy
(dependent Tasks ['linux-yocto-custom.bb:do_bundle_initramfs',
'depmodwrapper-cross_1.0.bb:do_populate_sysroot',
'linux-yocto-custom.bb:do_populate_sysroot',
'linux-yocto-custom.bb:do_packagedata'])


ERROR: Command execution failed: 1

My kernel recipe:

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

python __anonymous () {
depends = d.getVar("DEPENDS", True)
depends = "%s u-boot-mkimage-native dtc-native" % depends
d.setVar("DEPENDS", depends)
}

do_create_fitimage() {
cp ${THISDIR}/linux-yocto-custom/kernel-fit.its ${DEPLOY_DIR_IMAGE}
uboot-mkimage -f ${DEPLOY_DIR_IMAGE}/kernel-fit.its
${DEPLOY_DIR_IMAGE}/kernel-fit.itb
}

addtask create_fitimage before do_packagedata after do_deploy

KBRANCH = "linux-3.18.y"
KCONFIG_MODE = "--alldefconfig"

SRC_URI = 
"git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;bareclone=1;branch=${KBRANCH}"
SRC_URI += "file://defconfig"
SRC_URI += "file://baltos.scc \
   "

LINUX_VERSION ?= "3.18"
LINUX_VERSION_EXTENSION ?= ""

SRCREV="v3.18.32"

PV = "${LINUX_VERSION}+git${SRCPV}"

COMPATIBLE_MACHINE_baltos = "baltos"

Any idea?

Regards,
Yegor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] extensible SDK build failure

2017-08-07 Thread Paul Eggleton

Hi Russell,

On Wednesday, 2 August 2017 8:34:11 PM CEST RUSSELL PETERSON wrote:
> Frustrating in that I can't get the eSDK to fully build. I'm past the issue
> with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
> below. Anyone seen this before? From what I can tell these tasks are being
> executed out of the run queue.  Not all the messages are from cve-check but
> most.

So there are certain classes that will interfere with the ability of the eSDK 
to lock down the configuration, I wasn't aware of it but cve-check.bbclass is 
apparently one of them. Try adding this to your configuration:

SDK_INHERIT_BLACKLIST = "buildhistory icecc cve-check"

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH] pacemaker: Ship missing resource.d directory in ${PN}

2017-08-07 Thread Jagadeesh Krishnanjanappa

Fix below warning when ${libdir} is other than '/usr/lib',

-- snip --
WARNING: pacemaker-1.1.16-r0 do_package: QA Issue: pacemaker: Files/directories 
were installed but not shipped in any package:
  /usr/lib
  /usr/lib/ocf
  /usr/lib/ocf/resource.d
  /usr/lib/ocf/resource.d/.isolation
  /usr/lib/ocf/resource.d/pacemaker
  /usr/lib/ocf/resource.d/.isolation/docker-wrapper
  /usr/lib/ocf/resource.d/pacemaker/SystemHealth
  /usr/lib/ocf/resource.d/pacemaker/HealthCPU
  /usr/lib/ocf/resource.d/pacemaker/ClusterMon
  /usr/lib/ocf/resource.d/pacemaker/pingd
  /usr/lib/ocf/resource.d/pacemaker/HealthSMART
  /usr/lib/ocf/resource.d/pacemaker/controld
  /usr/lib/ocf/resource.d/pacemaker/Stateful
  /usr/lib/ocf/resource.d/pacemaker/ping
  /usr/lib/ocf/resource.d/pacemaker/o2cb
  /usr/lib/ocf/resource.d/pacemaker/remote
  /usr/lib/ocf/resource.d/pacemaker/Dummy
  /usr/lib/ocf/resource.d/pacemaker/SysInfo
Please set FILES such that these items are packaged. Alternatively if they are 
unneeded, avoid installing them or delete them within do_install.
pacemaker: 18 installed and not shipped files. [installed-vs-shipped]
-- snip --

Signed-off-by: Jeremy Puhlman 
Signed-off-by: Jagadeesh Krishnanjanappa 
---
 meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb 
b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
index cc1dd3d..3a4a848 100755
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
@@ -82,7 +82,7 @@ RDEPENDS_${PN}-remote += "libqb bash"
 FILES_${PN} += " ${datadir}/snmp \
  ${libdir}/corosync/lcrso/pacemaker.lcrso\
  ${libdir}/${PYTHON_DIR}/dist-packages/cts/  \
- ${libdir}/ocf/resource.d/ \
+ ${nonarch_libdir}/ocf/resource.d/ \
  ${libdir}/${PYTHON_DIR}/site-packages \
"
 FILES_${PN}-dbg += "${libdir}/corosync/lcrso/.debug"
-- 
1.8.3.1
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW32’17

2017-08-07 Thread Jolley, Stephen K

Current Dev Position: YP 2.4 M2 rc3 is in QA, patches are being merged for M3

Next Deadline: YP 2.4 M3 Cut off is Aug. 21, 2017


SWAT team rotation: Ross -> Leo on Aug. 4, 2017.

SWAT team rotation: Leo -> Juro on Aug. 11, 2017.

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


Key Status/Updates:

·Based on the 2.4 M2 rc2 QA report we decided to build an rc3 based on 
master as there were many different issues found, many of which were fixed post 
rc2 in master.

·2.4 M2 rc3 is in QA and about 15% complete: 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status

·A new uninative version was released which allows the system to work 
with newer distros with newer gcc and glibc versions.

·Much of the key maintainers time is being taken up with patch review, 
testing and tracking down which patch was responsible for which build failure. 
It does sometimes feel that people expect others to test their patches which 
isn’t the case. Test failures mean batches have to be retested and slow the 
merge of code into master so we’d appreciate people’s attention to detail when 
they do send changes.

·2.2 is struggling due to build issues right now. We need to get these 
resolved in order to be able to merge patches and unblock this release series.


Planned upcoming dot releases:

YP 2.2.2 Cut off June 5, 2017 - Not ready to do an rc2 yet.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Sept. 1, 2017

YP 2.3.2 Release by Sept. 15, 2017


Key YP 2.4 Dates are:

YP 2.4 M2 Cut off is July 17, 2017 - In QA now.

YP 2.4 M2 Release by July 28, 2017

YP 2.4 M3 Cut off is Aug. 21, 2017

YP 2.4 M3 Release by Sept. 1, 2017

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017


Tracking Metrics:

WDD 2433 (last week 2556)

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


Key Status Links for YP:

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

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

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


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

Thanks,

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

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] extensible SDK build failure

[yocto] [meta-alexa-demo][PATCH 1/3] Moved meta-alexa-demo top level to meta-alexapi

[yocto] [meta-alexa-demo][PATCH 2/3] Added meta-alexa-led for demo files

Re: [yocto] Perforce fetcher ignores module and label

[yocto] Yocto Project Status WW32’17

[yocto] GPG signed package feeds and packages: opkg update fails with "No public key"

[yocto] Custom FIT image: circular dependencies issue

Re: [yocto] extensible SDK build failure

[yocto] [meta-cgl][PATCH] pacemaker: Ship missing resource.d directory in ${PN}

[yocto] Yocto Project Status WW32’17

10 matches

Site Navigation

Mail list logo

Footer information