date:20171221

[yocto] [meta-oic][PATCH 1/5] iotivity_1.2.1: Hotfix: Add ORIGIN rpath for binutils-2.29

2017-12-21 Thread Philippe Coval

Set RPATH to ORIGIN as supported by gcc/ld (-rpath=\$ORIGIN)

Observed issue on poky master was:

  ld: warning: libconnectivity_abstraction.so, \
  needed by out/yocto/x86_64/release/liboctbstack.so,
  not found (try using -rpath or -rpath-link)
  out/yocto/x86_64/release/liboctbstack.so: \
  undefined reference to `coap_write_block_opt'

Note that problem is also about
to be fixed upstream directly in scons files.

Bug: https://jira.iotivity.org/browse/IOT-2651
Relate-to: https://gerrit.iotivity.org/gerrit/#/c/22355/
Thanks-to: Mikko Ylinen 
Signed-off-by: Philippe Coval 
---
 recipes-core/iotivity/iotivity_1.2.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-core/iotivity/iotivity_1.2.1.bb 
b/recipes-core/iotivity/iotivity_1.2.1.bb
index c8fb8fd..33adb9a 100644
--- a/recipes-core/iotivity/iotivity_1.2.1.bb
+++ b/recipes-core/iotivity/iotivity_1.2.1.bb
@@ -53,6 +53,7 @@ python () {
 
 IOTIVITY_BIN_DIR = "/opt/${PN}"
 IOTIVITY_BIN_DIR_D = "${D}${IOTIVITY_BIN_DIR}"
+LDFLAGS_append = " -Wl,-rpath-link=\\$$ORIGIN"
 
 do_compile_prepend() {
 export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
-- 
1.9.1

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

[yocto] [meta-oic][PATCH 3/5] iotivity-simple-client: Support pkg-config

2017-12-21 Thread Philippe Coval

Since IoTivity-1.3.0

Signed-off-by: Philippe Coval 
---
 .../files/0002-build-Use-pkg-config.patch  | 43 ++
 .../iotivity-simple-client_1.1.0.bb|  8 +++-
 2 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 
recipes-apps/iotivity-simple-client/files/0002-build-Use-pkg-config.patch

diff --git 
a/recipes-apps/iotivity-simple-client/files/0002-build-Use-pkg-config.patch 
b/recipes-apps/iotivity-simple-client/files/0002-build-Use-pkg-config.patch
new file mode 100644
index 000..026f68f
--- /dev/null
+++ b/recipes-apps/iotivity-simple-client/files/0002-build-Use-pkg-config.patch
@@ -0,0 +1,43 @@
+From 0a1f2273605ce775aede46ab3ec31bd73814f8b2 Mon Sep 17 00:00:00 2001
+From: Philippe Coval 
+Date: Tue, 6 Jun 2017 17:14:39 +0200
+Subject: [PATCH 2/2] build: Use pkg-config
+
+
+Bug: https://jira.iotivity.org/browse/IOT-
+Origin: https://github.com/TizenTeam/meta-oic
+Signed-off-by: Philippe Coval 
+---
+ Makefile | 17 -
+ 1 file changed, 4 insertions(+), 13 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 2389f43..ac34940 100644
+--- a/Makefile
 b/Makefile
+@@ -1,18 +1,9 @@
+-YOCTOCXXFLAGS=-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/ 
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/stack 
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/ocrandom 
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/logger 
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/oc_logger
+-
+-YOCTOLDFLAGS=-loc -loctbstack -loc_logger 
++PKG_CONFIG?=pkg-config
++override CPPFLAGS+=$(shell ${PKG_CONFIG} iotivity --cflags)
++override LDLIBS+=$(shell ${PKG_CONFIG} iotivity --libs)
++override CXXFLAGS+=-std=c++0x
+ 
+ all: simpleclient
+ 
+-simpleclient.o: simpleclient.cpp
+-ifeq ($(PKG_CONFIG_SYSROOT_DIR),)
+-  echo "Error: Yocto cross-toolchain environment not initialized"
+-  exit 1 
+-endif
+-  $(CXX) -std=c++0x -c -o $@ $< $(YOCTOCXXFLAGS)
+-
+-simpleclient: simpleclient.o
+-  $(CXX) -o $@ $^ $(LDFLAGS) $(YOCTOLDFLAGS)
+-
+ clean:
+   rm -rf simpleclient *.o
+-- 
+1.9.1
+
diff --git 
a/recipes-apps/iotivity-simple-client/iotivity-simple-client_1.1.0.bb 
b/recipes-apps/iotivity-simple-client/iotivity-simple-client_1.1.0.bb
index caf02f8..ea3bd64 100644
--- a/recipes-apps/iotivity-simple-client/iotivity-simple-client_1.1.0.bb
+++ b/recipes-apps/iotivity-simple-client/iotivity-simple-client_1.1.0.bb
@@ -1,3 +1,6 @@
+#TODO
+PR = "r1" 
+
 SUMMARY = "Iotivity Simple Client"
 DESCRIPTION = "Iotivity Simple Client example which talks to the Simple Server 
example."
 HOMEPAGE = "https://www.iotivity.org/";
@@ -8,17 +11,20 @@ LIC_FILES_CHKSUM = 
"file://simpleclient.cpp;beginline=1;endline=19;md5=fc5a615cf
 
 SRC_URI = "file://iotivity-simple-client.tar.bz2 \
 file://0001-build-Use-LDFLAGS-variable-from-env.patch \
+file://0002-build-Use-pkg-config.patch \
 "
 
 S = "${WORKDIR}/iotivity-simple-client"
 
 IOTIVITY_BIN_DIR = "/opt/iotivity"
 IOTIVITY_BIN_DIR_D = "${D}${IOTIVITY_BIN_DIR}"
+inherit pkgconfig
 
 do_install() {
 install -d ${IOTIVITY_BIN_DIR_D}/apps/iotivity-simple-client
 install -c -m 555 ${S}/simpleclient 
${IOTIVITY_BIN_DIR_D}/apps/iotivity-simple-client
 install -c -m 444 ${S}/oic_svr_db_client.dat 
${IOTIVITY_BIN_DIR_D}/apps/iotivity-simple-client
+rm -rf ${D}/usr/src/debug/${PN}
 }
 
 FILES_${PN} = "${IOTIVITY_BIN_DIR}/apps/iotivity-simple-client/simpleclient \
@@ -26,4 +32,4 @@ FILES_${PN} = 
"${IOTIVITY_BIN_DIR}/apps/iotivity-simple-client/simpleclient \
 FILES_${PN}-dbg = "${IOTIVITY_BIN_DIR}/apps/iotivity-simple-client/.debug"
 RDEPENDS_${PN} += "iotivity-resource"
 BBCLASSEXTEND = "native nativesdk"
-
+PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
-- 
1.9.1

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

[yocto] [meta-oic][PATCH 4/5] iotivity-sensorboard: Support pkg-config

2017-12-21 Thread Philippe Coval

Since IoTivity-1.3.0

Signed-off-by: Philippe Coval 
---
 .../files/0003-server-Port-to-iotivity-1.2.0.patch | 68 ++
 .../files/0004-build-Use-pkg-config.patch  | 48 +++
 .../iotivity-sensorboard_1.0.0.bb  | 11 
 3 files changed, 127 insertions(+)
 create mode 100644 
recipes-apps/iotivity-sensorboard/files/0003-server-Port-to-iotivity-1.2.0.patch
 create mode 100644 
recipes-apps/iotivity-sensorboard/files/0004-build-Use-pkg-config.patch

diff --git 
a/recipes-apps/iotivity-sensorboard/files/0003-server-Port-to-iotivity-1.2.0.patch
 
b/recipes-apps/iotivity-sensorboard/files/0003-server-Port-to-iotivity-1.2.0.patch
new file mode 100644
index 000..6f59e6a
--- /dev/null
+++ 
b/recipes-apps/iotivity-sensorboard/files/0003-server-Port-to-iotivity-1.2.0.patch
@@ -0,0 +1,68 @@
+From dcc5e1fd4204f08126ff940232283347b4963b15 Mon Sep 17 00:00:00 2001
+From: Philippe Coval 
+Date: Thu, 20 Jul 2017 15:33:36 +0200
+Subject: [PATCH 3/4] server: Port to iotivity-1.2.0+
+
+Bug: https://jira.iotivity.org/browse/IOT-
+
+Origin: https://github.com/TizenTeam/meta-oic/tree/iotivity-sensorboard/master
+Signed-off-by: Philippe Coval 
+---
+ server.cpp | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/server.cpp b/server.cpp
+index 8308577..5cb3215 100644
+--- a/server.cpp
 b/server.cpp
+@@ -107,7 +107,6 @@ void IoTServer::temperatureObserverLoop()
+ usleep(150);
+ cout << "Temperature Observer Callback" << endl;
+ shared_ptr resourceResponse(new OCResourceResponse());
+-resourceResponse->setErrorCode(200);
+ 
resourceResponse->setResourceRepresentation(getTemperatureRepresentation(),
+ EDISON_RESOURCE_INTERFACE);
+ OCStackResult result = 
OCPlatform::notifyListOfObservers(m_temperatureResource,
+@@ -125,7 +124,6 @@ void IoTServer::lightObserverLoop()
+ usleep(150);
+ cout << "Light Observer Callback" << endl;
+ shared_ptr resourceResponse(new OCResourceResponse());
+-resourceResponse->setErrorCode(200);
+ resourceResponse->setResourceRepresentation(getLightRepresentation(),
+ EDISON_RESOURCE_INTERFACE);
+ OCStackResult result = 
OCPlatform::notifyListOfObservers(m_ambientLightResource,
+@@ -167,7 +165,6 @@ OCEntityHandlerResult 
IoTServer::lightEntityHandler(shared_ptrsetErrorCode(200);
+ Response->setResponseResult(OC_EH_OK);
+ 
Response->setResourceRepresentation(getLightRepresentation());
+ if (OCPlatform::sendResponse(Response) == OC_STACK_OK)
+@@ -224,7 +221,6 @@ OCEntityHandlerResult 
IoTServer::temperatureEntityHandler(shared_ptrsetErrorCode(200);
+ Response->setResponseResult(OC_EH_OK);
+ 
Response->setResourceRepresentation(getTemperatureRepresentation());
+ if (OCPlatform::sendResponse(Response) == OC_STACK_OK)
+@@ -305,7 +301,6 @@ OCEntityHandlerResult 
IoTServer::LEDEntityHandler(shared_ptr
+ putLEDRepresentation();
+ if (Response)
+ {
+-Response->setErrorCode(200);
+ 
Response->setResourceRepresentation(getLEDRepresentation());
+ Response->setResponseResult(OC_EH_OK);
+ if (OCPlatform::sendResponse(Response) == OC_STACK_OK)
+@@ -319,7 +314,6 @@ OCEntityHandlerResult 
IoTServer::LEDEntityHandler(shared_ptr
+ cout << "GET request for platform LED" << endl;
+ if (Response)
+ {
+-Response->setErrorCode(200);
+ 
Response->setResourceRepresentation(getLEDRepresentation());
+ Response->setResponseResult(OC_EH_OK);
+ if (OCPlatform::sendResponse(Response) == OC_STACK_OK)
+-- 
+1.9.1
+
diff --git 
a/recipes-apps/iotivity-sensorboard/files/0004-build-Use-pkg-config.patch 
b/recipes-apps/iotivity-sensorboard/files/0004-build-Use-pkg-config.patch
new file mode 100644
index 000..12f9323
--- /dev/null
+++ b/recipes-apps/iotivity-sensorboard/files/0004-build-Use-pkg-config.patch
@@ -0,0 +1,48 @@
+From eace0b8280eda68aacbc396b9fe6756298af81b1 Mon Sep 17 00:00:00 2001
+From: Philippe Coval 
+Date: Thu, 20 Jul 2017 15:22:56 +0200
+Subject: [PATCH 4/4] build: Use pkg-config
+
+Bug: https://jira.iotivity.org/browse/IOT-
+Origin: https://github.com/TizenTeam/meta-oic/tree/iotivity-sensorboard/master
+
+Signed-off-by: Philippe Coval 
+---
+ Makefile | 17 -
+ 1 file changed, 8 insertions(+), 9 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 5d09cc1..ab3d632 100644
+--- a/Makefile
 b/Makefile
+@@ -1,19 +1,18 @@
+-YOCTOCXXFLAGS=-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/ 
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/stack 
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/ocrandom 
-I$(PKG_CONFIG_SYSROOT_DIR)/usr/include/iotivity/resource/logger 
-I$(PKG_C

[yocto] [meta-oic][PATCH 5/5] Add recipe for IoTivity 1.3.1

2017-12-21 Thread Philippe Coval

Note that fail on warning flag has been added,
and can be used in .bbappend if needed after reporting bugs:
http://wiki.iotivity.org/report

Bug: https://jira.iotivity.org/browse/IOT-2651
Signed-off-by: Philippe Coval 
---
 README  |   2 +-
 recipes-core/iotivity/iotivity_1.3.1.bb | 469 
 2 files changed, 470 insertions(+), 1 deletion(-)
 create mode 100644 recipes-core/iotivity/iotivity_1.3.1.bb

diff --git a/README b/README
index 085dbdc..ca0c762 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
 meta-oic
 
-This layer contains recipes for the IoTivity Project (v1.3.0)
+This layer contains recipes for the IoTivity Project (v1.3.1)
 , sample applications and related components for any Yocto target.
 
 Contents
diff --git a/recipes-core/iotivity/iotivity_1.3.1.bb 
b/recipes-core/iotivity/iotivity_1.3.1.bb
new file mode 100644
index 000..c7b9163
--- /dev/null
+++ b/recipes-core/iotivity/iotivity_1.3.1.bb
@@ -0,0 +1,469 @@
+SUMMARY = "IoTivity framework and SDK sponsored by the Open Connectivity 
Foundation."
+DESCRIPTION = "IoTivity is an open source software framework enabling seamless 
device-to-device connectivity to address the emerging needs of the Internet of 
Things."
+HOMEPAGE = "https://www.iotivity.org/";
+DEPENDS = "boost virtual/gettext chrpath-replacement-native expat openssl 
util-linux curl glib-2.0 glib-2.0-native"
+DEPENDS += "sqlite3"
+
+EXTRANATIVEPATH += "chrpath-native"
+SECTION = "libs"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=22bf216f3077c279aed7b36b1fa9e6d1"
+
+branch_iotivity ?= "1.3-rel"
+SRCREV ?= "633dc231b8d9967520627528a92506efca7cebcd"
+url_iotivity ?= 
"git://github.com/iotivity/iotivity.git;destsuffix=${S};branch=${branch_iotivity};protocol=http"
+SRC_URI += "${url_iotivity}"
+
+url_tinycbor = "git://github.com/01org/tinycbor.git"
+SRCREV_tinycbor = "31c7f81d45d115d2007b1c881cbbd3a19618465c"
+SRC_URI += 
"${url_tinycbor};name=tinycbor;destsuffix=${S}/extlibs/tinycbor/tinycbor;protocol=http"
+
+url_gtest = "https://github.com/google/googletest/archive/release-1.7.0.zip";
+SRC_URI[gtest.md5sum] = "ef5e700c8a0f3ee123e2e0209b8b4961"
+SRC_URI[gtest.sha256sum] = 
"b58cb7547a28b2c718d1e38aee18a3659c9e3ff52440297e965f5edffe34b6d0"
+SRC_URI += "${url_gtest};name=gtest;subdir=${BP}/extlibs/gtest"
+
+url_hippomocks = "git://github.com/dascandy/hippomocks.git"
+SRCREV_hippomocks = "dca4725496abb0e41f8b582dec21d124f830a8e5"
+SRC_URI += 
"${url_hippomocks};name=hippomocks;destsuffix=${S}/extlibs/hippomocks/hippomocks;protocol=http"
+SRC_URI += "file://hippomocks_mips_patch"
+
+SRCREV_mbedtls = "85c2a928ed352845793db000e78e2b42c8dcf055"
+url_mbedtls="git://github.com/ARMmbed/mbedtls.git"
+SRC_URI += 
"${url_mbedtls};name=mbedtls;destsuffix=${S}/extlibs/mbedtls/mbedtls;protocol=http"
+
+url_rapidjson = "git://github.com/miloyip/rapidjson.git"
+SRCREV_rapidjson = "3d5848a7cd3367c5cb451c6493165b7745948308"
+SRC_URI += 
"${url_rapidjson};name=rapidjson;;nobranch=1;destsuffix=${S}/extlibs/rapidjson/rapidjson;protocol=http"
+
+
+inherit pkgconfig scons
+
+
+python () {
+IOTIVITY_TARGET_ARCH = d.getVar("TARGET_ARCH", True)
+d.setVar("IOTIVITY_TARGET_ARCH", IOTIVITY_TARGET_ARCH)
+EXTRA_OESCONS = d.getVar("EXTRA_OESCONS", True)
+EXTRA_OESCONS += " TARGET_OS=yocto TARGET_ARCH=" + IOTIVITY_TARGET_ARCH + 
" RELEASE=1"
+EXTRA_OESCONS += " VERBOSE=1"
+# Aligned to default configuration, but features can be changed here (at 
your own risk):
+#   EXTRA_OESCONS += " ERROR_ON_WARN=False"
+# EXTRA_OESCONS += " ROUTING=GW"
+# EXTRA_OESCONS += " SECURED=0"
+# EXTRA_OESCONS += " TCP=1"
+d.setVar("EXTRA_OESCONS", EXTRA_OESCONS)
+}
+
+
+IOTIVITY_BIN_DIR = "/opt/${PN}"
+IOTIVITY_BIN_DIR_D = "${D}${IOTIVITY_BIN_DIR}"
+
+
+do_compile_prepend() {
+export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}"
+export PKG_CONFIG="PKG_CONFIG_SYSROOT_DIR=\"${PKG_CONFIG_SYSROOT_DIR}\" 
pkg-config"
+export LD_FLAGS="${LD_FLAGS}"
+}
+
+make_dir() {
+install -d $1
+}
+
+copy_file() {
+install -c -m 444 $1 $2
+}
+
+copy_exec() {
+install -c -m 555 $1 $2
+}
+
+copy_file_recursive() {
+cd $1 && find . -type d -exec install -d $2/"{}" \;
+cd $1 && find . -type f -exec install -c -m 444 "{}" $2/"{}" \;
+}
+
+copy_exec_recursive() {
+cd $1 && find . -executable -exec install -c -m 555 "{}" $2/"{}" \;
+}
+
+do_install_append() {
+make_dir ${D}${libdir}
+#Resource
+#C++ APIs
+copy_file ${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/liboc.so 
${D}${libdir}
+if ${@bb.utils.contains('EXTRA_OESCONS', 'SECURED=0', 'false', 'true', 
d)}; then
+copy_file 
${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/libocprovision.so ${D}${libdir}
+copy_file ${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/libocpmapi.so 
${D}${libdir}
+fi
+
+#Logger
+copy_file ${S}/out/yocto/${IOTIVITY_TARGET_ARCH}/release/liboc_logger.so 
${D}${libdir}
+copy_file

[yocto] [meta-oic][PATCH 2/5] Add recipe for IoTivity 1.3.0

2017-12-21 Thread Philippe Coval

Note that SECURITY is now enabled but might cause issues on some examples.

Bug: https://jira.iotivity.org/browse/IOT-2651
Signed-off-by: Philippe Coval 
---
 README |   2 +-
 ...ging-Return-false-boolean-instead-of-enum.patch |  40 ++
 recipes-core/iotivity/iotivity_1.3.0.bb| 471 +
 3 files changed, 512 insertions(+), 1 deletion(-)
 create mode 100644 
recipes-core/iotivity/files/0099-bridging-Return-false-boolean-instead-of-enum.patch
 create mode 100644 recipes-core/iotivity/iotivity_1.3.0.bb

diff --git a/README b/README
index ef202dd..085dbdc 100644
--- a/README
+++ b/README
@@ -1,6 +1,6 @@
 meta-oic
 
-This layer contains recipes for the IoTivity Project (v1.2.1)
+This layer contains recipes for the IoTivity Project (v1.3.0)
 , sample applications and related components for any Yocto target.
 
 Contents
diff --git 
a/recipes-core/iotivity/files/0099-bridging-Return-false-boolean-instead-of-enum.patch
 
b/recipes-core/iotivity/files/0099-bridging-Return-false-boolean-instead-of-enum.patch
new file mode 100644
index 000..101588d
--- /dev/null
+++ 
b/recipes-core/iotivity/files/0099-bridging-Return-false-boolean-instead-of-enum.patch
@@ -0,0 +1,40 @@
+From 45a915954650b0c2f5752ae9e958a194d2483852 Mon Sep 17 00:00:00 2001
+From: Philippe Coval 
+Date: Wed, 28 Jun 2017 04:54:05 +0200
+Subject: [PATCH 099/169] bridging: Return false boolean instead of enum
+
+Small Fix to support g++-7.1.0
+
+It was tested on yocto poky master on iotivity-1.3.0 (and later):
+
+  bridging/plugins/nest_plugin/nest_objects/nest.cpp: \
+  In member function 'bool Nest::isAuthorized()':
+  bridging/plugins/nest_plugin/nest_objects/nest.cpp:95:16: \
+  error: enum constant in boolean context [-Werror=int-in-bool-context]
+
+
+Signed-off-by: Philippe Coval 
+Reviewed-on: https://gerrit.iotivity.org/gerrit/21071
+Tested-by: jenkins-iotivity 
+Reviewed-by: Dan Mihai 
+Reviewed-by: Todd Malsbary 
+---
+ bridging/plugins/nest_plugin/nest_objects/nest.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bridging/plugins/nest_plugin/nest_objects/nest.cpp 
b/bridging/plugins/nest_plugin/nest_objects/nest.cpp
+index 780d6e9..8b40848 100644
+--- a/bridging/plugins/nest_plugin/nest_objects/nest.cpp
 b/bridging/plugins/nest_plugin/nest_objects/nest.cpp
+@@ -92,7 +92,7 @@ bool Nest::isAuthorized()
+ if (curlCode != MPM_RESULT_OK)
+ {
+ OIC_LOG_V(ERROR, TAG, "Curl GET Request operation failed. Error code 
%d", curlCode);
+-return MPM_RESULT_INTERNAL_ERROR;
++return false;
+ }
+ 
+ if (MPM_RESULT_OK != parseStructureJsonResponse(response, m_metaInfo))
+-- 
+1.9.1
+
diff --git a/recipes-core/iotivity/iotivity_1.3.0.bb 
b/recipes-core/iotivity/iotivity_1.3.0.bb
new file mode 100644
index 000..b1490dd
--- /dev/null
+++ b/recipes-core/iotivity/iotivity_1.3.0.bb
@@ -0,0 +1,471 @@
+SUMMARY = "IoTivity framework and SDK sponsored by the Open Connectivity 
Foundation."
+DESCRIPTION = "IoTivity is an open source software framework enabling seamless 
device-to-device connectivity to address the emerging needs of the Internet of 
Things."
+HOMEPAGE = "https://www.iotivity.org/";
+DEPENDS = "boost virtual/gettext chrpath-replacement-native expat openssl 
util-linux curl glib-2.0 glib-2.0-native"
+DEPENDS += "sqlite3"
+
+EXTRANATIVEPATH += "chrpath-native"
+SECTION = "libs"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=22bf216f3077c279aed7b36b1fa9e6d1"
+
+branch_iotivity ?= "1.3-rel"
+SRCREV ?= "443b33a031f275380d1a50ac8c2ac20b80292fb1"
+url_iotivity ?= 
"git://github.com/iotivity/iotivity.git;destsuffix=${S};branch=${branch_iotivity};protocol=http"
+SRC_URI += "${url_iotivity}"
+SRC_URI += "file://0189-resource-Include-functional-header-for-g-7.1.0.patch"
+SRC_URI += "file://0099-bridging-Return-false-boolean-instead-of-enum.patch"
+
+url_tinycbor = "git://github.com/01org/tinycbor.git"
+SRCREV_tinycbor = "31c7f81d45d115d2007b1c881cbbd3a19618465c"
+SRC_URI += 
"${url_tinycbor};name=tinycbor;destsuffix=${S}/extlibs/tinycbor/tinycbor;protocol=http"
+
+url_gtest = "https://github.com/google/googletest/archive/release-1.7.0.zip";
+SRC_URI[gtest.md5sum] = "ef5e700c8a0f3ee123e2e0209b8b4961"
+SRC_URI[gtest.sha256sum] = 
"b58cb7547a28b2c718d1e38aee18a3659c9e3ff52440297e965f5edffe34b6d0"
+SRC_URI += "${url_gtest};name=gtest;subdir=${BP}/extlibs/gtest"
+
+url_hippomocks = "git://github.com/dascandy/hippomocks.git"
+SRCREV_hippomocks = "dca4725496abb0e41f8b582dec21d124f830a8e5"
+SRC_URI += 
"${url_hippomocks};name=hippomocks;destsuffix=${S}/extlibs/hippomocks/hippomocks;protocol=http"
+SRC_URI += "file://hippomocks_mips_patch"
+
+SRCREV_mbedtls = "85c2a928ed352845793db000e78e2b42c8dcf055"
+url_mbedtls="git://github.com/ARMmbed/mbedtls.git"
+SRC_URI += 
"${url_mbedtls};name=mbedtls;destsuffix=${S}/extlibs/mbedtls/mbedtls;protocol=http"
+
+url_rapidjson = "git://github.com/miloyip/rapidjson.g

Re: [yocto] add kernel modules & dtbo's for Raspberry Pi3

2017-12-21 Thread Trevor Woerner

On Wed 2017-12-20 @ 11:40:50 PM, Greg Wilson-Lindberg wrote:
> I'm building an image for the Raspberry Pi 3 and I'm trying to add some
> modules to the kernel and I need to add some device tree overlays. The
> modules and overlays are part of the kernel, just not built by default.
> 
> For the kernel modules I've added a linux-raspberrypi_4.4.bbappend file in
> the path .../recipes-bsp/linux. The file consists of:
> 
> # Scribe additions to Kernel configuration
> 
> FILESEXTRAPATHS_prepend += "$(THISDIR)/files"
> SRC_URI += "file://Scribe.cfg"
> 
> Whether I use "+=" or ":=" as suggested in "Embedded Linux Systems withe
> the Yocto Project", I get an error that "file://0001-fix-dtbo-rules.patch"
> cannot be found. I don't get this error if my .bbappend file is not being
> used.

You're missing a colon at the end of the path definition, and you should use
the ':=' operator:

FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

The path you're introducing is getting added to a bunch of other paths, and
therefore needs the separator. The := operator causes your change to this
variable to be immediately expanded by bitbake, which is what you want.

> Also, if there are any quick tips on how to add dtbo's to the kernel build I
> would appreciate them.

If you look through the raspberry pi kernel sources

($TMPDIR/work/raspberrypi3-*/linux-raspberrypi/${VERSION}/linux-raspberrypi3-standard-build/source)
at
arch/arm/boot/dts/overlays

and find an overlay you like (e.g. spi1-3cs-overlay.dts) then to have it added
to your image and applied at boot time:

1. edit local.conf to add it to the kernel's device tree (but add it as a dtbo
without the "-overlay"):

KERNEL_DEVICETREE_append = " overlays/spi1-3cs.dtbo"

2. extend rpi-config to include it in the image's config.txt file:

rpi-config_%.bbappend:
do_deploy_append() {
echo "dtoverlay=spi1-3cs" 
>>${DEPLOYDIR}/bcm2835-bootfiles/config.txt"
}
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Some trivial question about git update-ref refs/heads/rocko ...

2017-12-21 Thread Zoran Stojsavljevic

Hello Andre,

> To switch from rocko to master, try:
>
>  git fetch origin
>  git checkout -B master origin/master

This did the trick... Thank you!

I always thought that I actually initially fetched master release, but it
appears that I fetched rocko as genesis release.

The conclusion/fact given above sustains, because of the following info in
the: .../.git/refs/heads/ (CLI transcript follows):

[user@localhost poky]$ pwd
/home/user/YOCTO/oe_core_embedded/poky
[user@localhost poky]$* cd .git/refs/heads*
[user@localhost heads]$ ls -al
total 16
drwxrwxr-x. 2 user user 4096 Dec 21 06:10 .
drwxrwxr-x. 5 user user 4096 Oct 18 12:49 ..
-rw-rw-r--. 1 user user   41 *Dec 21 06:10 master*
-rw-rw-r--. 1 user user   41 *Oct 18 12:49 rocko*
[user@localhost heads]$ cat rocko
65d23bd7986615fdfb0f1717b615534a2a14ab80
[user@localhost heads]$ cat master
*370483fce1c2429c81b19dcf8a36394dc3fc3d92 <<= MASTER current HEAD!*
[user@localhost heads]$

Genesis was on October 18th, 2018 (git clone -b rocko git://
git.yoctoproject.org/poky.git), so the command:
git checkout -B master origin/master created today (Dec 21st, 2018) master
HEAD file in .../.git/refs/heads .

Then I again bitbake core-image-sato, worked as a charm.

Thank you again,
Zoran

On Wed, Dec 20, 2017 at 11:45 PM, Andre McCurdy  wrote:

> On Wed, Dec 20, 2017 at 8:32 AM, Zoran Stojsavljevic
>  wrote:
> > I am trying to upgrade my poky distro with current HEAD:
> > 65d23bd7986615fdfb0f1717b615534a2a14ab80
> >
> > It is ~ one month old.
> >
> > And to the latest HEAD:370483fce1c2429c81b19dcf8a36394dc3fc3d92
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=
> 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> >
> > The transcript what I do is below:
> > [user@localhost poky]$ pwd
> > /home/user/YOCTO/oe_core_embedded/poky
> > [user@localhost poky]$ git update-ref refs/heads/rocko
> > 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> > fatal: update_ref failed for ref 'refs/heads/rocko': cannot update ref
> > 'refs/heads/rocko': trying to write ref 'refs/heads/rocko' with
> nonexistent
> > object 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> > [user@localhost poky]$ git update-ref refs/heads/rocko HEAD
> > 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> > fatal: update_ref failed for ref 'refs/heads/rocko': cannot lock ref
> > 'refs/heads/rocko': is at 65d23bd7986615fdfb0f1717b615534a2a14ab80 but
> > expected 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> > [user@localhost poky]$
> >
> > What I am doing wrong?!
>
> To switch from rocko to master, try:
>
>   git fetch origin
>   git checkout -B master origin/master
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.3.3 RC1

2017-12-21 Thread Richard Purdie

On Wed, 2017-12-20 at 20:25 -0800, Cruz, Libertad wrote:
> Hello All,
> Enjoy viewing the full Report for 2.3.3 RC1:  https://wiki.yoctoproje
> ct.org/wiki/WW51_-_2017-12-20-_Full_Test_Cycle_-_2.3.3_rc1
> 
> === Summary 
> 
> The QA cycle for release 2.3.3 RC1 is complete.  There are 4 new bugs
> from which so far none of them are high. QA has two big concerns:
> 
> 1.  Performance report shows an increase of 30% build time on
> the eSDK in fedora 23, bug has not been created until further
> investigation with setup outside of the GDC environment. 

Could you confirm when the performance test machines were last
rebooted? We've had issues before where the benchmarks drift with
machine uptime. If the've been running for more than about 3 weeks I'd
like to run the benchmarks again after a reboot.

Thanks!

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

Re: [yocto] Layer documentation for meta-raspberrypi

2017-12-21 Thread Andrei Gherzan

Nice. Good job.

--
Andrei Gherzan

On Mon, Dec 18, 2017 at 9:57 PM, Mirza Krak  wrote:

> On Dec 18, 2017 20:50, "Paul Barker"  wrote:
>
> On Mon, Dec 11, 2017 at 12:20 PM, Paul Barker 
> wrote:
> > On Mon, Dec 11, 2017 at 12:08 PM, Mirza Krak 
> wrote:
> >> 2017-12-11 12:55 GMT+01:00 Paul Barker :
> >>> Hi all,
> >>>
> >>> As a quick announcement, the layer documentation for meta-raspberrypi
> >>> is now available on Read the Docs:
> >>> http://meta-raspberrypi.readthedocs.io/en/latest/
> >>>
>
> >>
> >> One little thing though, the current "theme" used which I assume is
> >> the default Sphinx theme is not optimal IMO.
> >>
>
> >
> > Thanks for the feedback. The conf.py file we're using is just what was
> > generated by sphinx-quickstart with minimal tweaks. It sets html_theme
> > which is obviously overriding the default for read the docs.
> >
> > I think I should be able to get the right behaviour by commenting out
> > the html_theme setting completely. I'll give that a go and see what
> > happens.
> >
>
> That worked. Looks much better!
> http://meta-raspberrypi.readthedocs.io/en/latest/index.html
>
>
> Great job. Agree that it looks much better.
>
> Best Regards
> Mirza
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] How to modify KERNEL_DEVICETREE?

2017-12-21 Thread Andrei Gherzan

Hi,

You need to make that variable available in both sdcard generation code
which resides in the image recipe and in the kernel recipe. You can do this
by modifying that variable from local.conf (distro would work too I think
but it doesn't sounds like the right place to be).

--
Andrei Gherzan

On Sun, Dec 17, 2017 at 6:36 PM, Drew Moseley  wrote:

> I'm trying to figure out how to properly modify the KERNEL_DEVICETREE
> variable.  It seems that the meta-raspberrypi layer uses that variable
> in the sdcard_image-rpi.bbclass and defines it in the machine conf
> layer.  In poky, the variable is set and appended to in the various
> linux-yocto recipes. If I make a similar change in a linux-raspberrypi
> bbappend file, it works fine for the build of the linux-raspberrypi
> recipe but when it is trying to package up the rpi-sdimg file, the
> changes from the kernel recipe are not available and generally the build
> will fail since the files expected during the image creation will not
> have been created during the kernel build.
>
> I can envision several different workarounds here but I'm struggling to
> come up with a solid fix. Does anyone have any suggestions?
>
> It also looks like the meta-freescale layer will have a similar issue.
>
> Drew
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to config kernel in my own meta layer?

2017-12-21 Thread Fan Zhang


Greetings,

I have a recipes that requires 128MB of CMA allocation for DMA. I 
followed the instruction in 
http://www.yoctoproject.org/docs/1.6/kernel-dev/kernel-dev.html#changing-the-configuration 
and did the following:


My recipes structure:

meta-mylayer\recipes-my\uio-test\

1. Then in uio-test folder, I have uio-test.bb that created by 
recipetool (in general) with some modification. uio-test.bb looks like 
this:


#--

# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to 
be fully functional.

# (Feel free to remove these comments when editing.)

# Unable to find any files that looked like license statements. Check 
the accompanying
# documentation and source headers and set LICENSE and LIC_FILES_CHKSUM 
accordingly.

#
# NOTE: LICENSE is being set to "CLOSED" to allow you to at least start 
building - if
# this is not accurate with respect to the licensing of the software 
being built (it
# will not be in most cases) you must specify the correct value before 
using this

# recipe for anything other than initial testing/development!
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

# No information for SRC_URI yet (only an external source tree was 
specified)

PV = "2.0.2"
SRC_URI = "file://src"

# NOTE: this is a Makefile-only piece of software, so we cannot generate 
much of the
# recipe automatically - you will need to examine the Makefile yourself 
and ensure

# that the appropriate arguments are passed in.

do_configure () {
    # Specify any needed configure commands here
    :
}

do_compile () {
    # You will almost certainly need to add additional arguments here
    cd ${WORKDIR}/src
    oe_runmake
}

FILES_${PN} = "/www/pages /etc/lighttpd.d"
do_install () {
    # This is a guess; additional arguments may be required
    cd ${WORKDIR}/src
    oe_runmake install 'DESTDIR=${D}'
}

DEPENDS = "libgcc boost"
RDEPENDS_${PN} = "libgcc boost-thread boost-system lighttpd 
lighttpd-module-cgi"

#--

2. Also in uio-test folder, I have uio-test.bbappend file with these 
contents:


#--

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://uio-test.cfg"

#--^^^-

3. In uio-test/files folder, I have uio-test.cfg with the following 
contents:



#--

CONFIG_CMA_ALIGNMENT=8
CONFIG_CMA=y
CONFIG_CMA_AREAS=7
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=128
CONFIG_CMA_SIZE_SEL_MBYTES=y
CONFIG_DMADEVICES=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_OF=y
CONFIG_XILINX_DMA_ENGINES=y
CONFIG_XILINX_DMA=y
CONFIG_DMA_API_DEBUG=y
CONFIG_HAS_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ZONE_DMA_FLAG=0
#--^^^-

My question: I think the cfg file is being parsed because if I change 
the folder name files to something else, bitbake will complaint about 
not being able to find uio-test.cfg. However, the final .config in built 
do not have the CMA allocated. My meta layer does have a priority higher 
than the upstream layers. What else can cause the problem here? Any 
suggestions? Thanks.


Fan Zhang

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

Re: [yocto] [meta-raspberrypi] linux kernel rt

2017-12-21 Thread Andrei Gherzan

Hi all,

On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller 
wrote:

> On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak  wrote:
>
>> 2017-12-14 9:41 GMT+01:00 Andreas Müller :
>> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <
>> sherifomran2...@gmail.com>
>> > wrote:
>> >>
>> >> hey guys,
>> >>
>> >> any body tried the real time kernel? I get an error, it is snot in the
>> >> compatibility list.
>> >> can we skip it?
>> >>
>> >> thanks
>> >>
>> >> --
>> >
>> > Good news: I use RT kernel only together with VC4 graphics and have
>> lots of
>> > fun on PI2/3.
>> > Bad news: As far as I know it is not in meta-raspberrypi but in my fork
>> [1].
>> > There were attempts to land the RT-patches in meta-raspberrypi but that
>> was
>> > denied for huge patch size :(
>>
>> If the patch size was the only problem one can pull it by doing the
>> following in the recipe:
>>
>> SRC_URI += " \
>> https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patc
>> h-4.9.65-rt56.patch.gz;name=rt-patch
>> \
>> "
>>
>> SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
>> SRC_URI[rt-patch.sha256sum] =
>> "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"
>>
>> Note that above sums are "random" and not the for the actually file
>> but are there for reference.
>>
>> That way you do not need to keep a copy of it in meta-raspberrypi.
>>
>> --
>>
> Hi Mirza,
>
> Problem is that patches need alignments sometimes either caused by
> Raspberry-Pi-specific adjustments or versions not matching exactly - RT
> kernel patch updates are less frequent than kernel updates. Anyway: git is
> very good at maintaining huge text content and this should not be a problem
> these days. Another discussion about RT kernel was to have an extra kernel
> for it and I never understood why. To me that seems nothing but an extra
> maintenance burden.
>
> However - just wrote to Paul: I plan to be at FOSDEM and we can discuss
> there how to get back to one layer only (not mine!) making everybody happy
> :)
>
>
I remember the discussion. Indeed that was the reason and the
recommendation was to maintain a separate linux-raspberry fork where
whoever has interest in this will maintain on top of linux-raspberrypi this
patch. Obviously that didn't happen but I'd like to see it landing.

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

[yocto] FW: QA cycle report for 2.3.3 RC1

2017-12-21 Thread Cruz, Libertad

Machine was rebooted

last week 12/12

-$ who -b
  system boot  2017-12-12 09:18

-$ uptime -s
  2017-12-12 09:19:28



-Original Message-
From: Perez Carranza, Jose 
Sent: Thursday, December 21, 2017 8:57 AM
To: Purdie, Richard ; Cruz, Libertad 
; yocto@yoctoproject.org; Lock, Joshua G 
; Jolley, Stephen K ; 
Zhang, Jessica 
Cc: Sangal, Apoorv ; Yeoh, Ee Peng 

Subject: Re: QA cycle report for 2.3.3 RC1


On 12/21/2017 08:43 AM, Richard Purdie wrote:
> On Wed, 2017-12-20 at 20:25 -0800, Cruz, Libertad wrote:
>> Hello All,
>> Enjoy viewing the full Report for 2.3.3 RC1:  https://wiki.yoctoproje
>> ct.org/wiki/WW51_-_2017-12-20-_Full_Test_Cycle_-_2.3.3_rc1
>>
>> === Summary 
>>
>> The QA cycle for release 2.3.3 RC1 is complete.  There are 4 new bugs 
>> from which so far none of them are high. QA has two big concerns:
>>
>>  1.  Performance report shows an increase of 30% build time 
>> on the eSDK in fedora 23, bug has not been created until further 
>> investigation with setup outside of the GDC environment.
> Could you confirm when the performance test machines were last 
> rebooted? We've had issues before where the benchmarks drift with 
> machine uptime. If the've been running for more than about 3 weeks I'd 
> like to run the benchmarks again after a reboot.
It was last week 12/12

-$ who -b
  system boot  2017-12-12 09:18

-$ uptime -s
  2017-12-12 09:19:28

> Thanks!
>
> Richard

--
Saludos
José

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

[yocto] [auh][PATCH 00/21] Further enhancements to automatic upgrade helper

2017-12-21 Thread Alexander Kanavin

Particularly:
1) Rebase and integrate (most of) Robert's patches
2) Add musl testing support (a notorious source of failures)
3) Rework testimage support to be more straigtforward and usable locally
by maintainers
4) Other things :)

The following changes since commit fbccfa00967305bb3866d0f610cd4b83b8b7a28c:

  upgradehelper.py: revert commits that failed to build (2017-12-14 18:13:11 
+0200)

are available in the Git repository at:

  git://git.yoctoproject.org/auto-upgrade-helper devel
  http://git.yoctoproject.org/cgit.cgi/auto-upgrade-helper/log/?h=devel

Alexander Kanavin (13):
  upgradehelper.py: drop automatic mode
  upgradehelper.py: replace the confusing 'maintainer' command line
option
  weeklyjob.sh: set up a temporary branch and clean up afterwards
  Add support for compiling against non-default C libraries
  Add protection measures and information against running with existing
build directories.
  upgradehelper.py: do not include absolute paths in the generated
tarball
  Do not require configuration options that aren't necessary for running
ptests
  upgradehelper.py: do not include testimage information in maintainer
email messages
  testimage.py: clarify what arguments are passed to class constructor
  testimage.py: run even if no packages were upgraded
  testimage.py: remove all iterations (over machines, over failing
recipes)
  testimage.py: rewrite the logic for building and running testimages
  testimage.py: collect and write out logs from bitbake and testimage

Robert Yang (8):
  upgradehelper.py: fix checking for do_checkpkg
  upgradehelper.py: support upgrade multiple recipes
  upgradehelper.py: use UniverseUpdater for all cases
  modules/steps.py: fix warn when skip compilation
  upgradehelper.py: only check email settings when -e is specified
  upgradehelper.py: always do upgrade when recipes are specified
  upgradehelper.py: print info when recipe is skipped to upgrade
  upgradehelper.py: don't build gcc-runtime when --skip-compilation

 README   |  40 +---
 modules/steps.py |   2 +-
 modules/testimage.py | 256 ---
 modules/utils/bitbake.py |   7 +-
 upgradehelper.py | 144 +++---
 weeklyjob.sh |  16 ++-
 6 files changed, 142 insertions(+), 323 deletions(-)

-- 
2.15.1

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

[yocto] [auh][PATCH 01/21] upgradehelper.py: fix checking for do_checkpkg

2017-12-21 Thread Alexander Kanavin

From: Robert Yang 

The error message in the log is:
Initialising tasks...ERROR: Task do_checkpkg does not exist for target strace 
[snip]

So line.find("ERROR: Task do_checkpkg does not exist") == 0 doesn't
work, use != -1 to fix the problem.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 71ee0b0..4797fd8 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -646,7 +646,7 @@ class UniverseUpdater(Updater):
 self.bb.checkpkg(recipe)
 except Error as e:
 for line in e.stdout.split('\n'):
-if line.find("ERROR: Task do_checkpkg does not exist") == 0:
+if line.find("ERROR: Task do_checkpkg does not exist") != -1:
 C(" \"distrodata.bbclass\" not inherited. Consider adding "
   "the following to your local.conf:\n\n"
   "INHERIT =+ \"distrodata\"\n")
-- 
2.15.1

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

[yocto] [auh][PATCH 02/21] upgradehelper.py: support upgrade multiple recipes

2017-12-21 Thread Alexander Kanavin

From: Robert Yang 

Now we can use:
$ upgradehelper.py recipe1 recipe2

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 4797fd8..c81e748 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -75,7 +75,7 @@ def parse_cmdline():
 parser = argparse.ArgumentParser(description='Package Upgrade Helper',
  
formatter_class=argparse.RawTextHelpFormatter,
  epilog=help_text)
-parser.add_argument("recipe", help="recipe to be upgraded")
+parser.add_argument("recipe", nargs = '+', action='store', default='', 
help="recipe to be upgraded")
 
 parser.add_argument("-t", "--to_version",
 help="version to upgrade the recipe to")
@@ -792,7 +792,7 @@ if __name__ == "__main__":
 level=debug_levels[args.debug_level - 1])
 settings, maintainer_override = parse_config_file(args.config_file)
 
-recipes = args.recipe.split()
+recipes = args.recipe
 
 if len(recipes) == 1 and recipes[0] == "all":
 updater = UniverseUpdater()
@@ -806,9 +806,12 @@ if __name__ == "__main__":
 args.maintainer = "Upgrade Helper <%s>" % \
 settings.get('from', 'u...@not.set')
 
-pkg_list = [(args.recipe, args.to_version, args.maintainer)]
+pkg_list = [(recipes[0], args.to_version, args.maintainer)]
 updater = Updater(args.auto_mode, args.send_emails, 
args.skip_compilation)
 updater.run(pkg_list)
+elif len(recipes) > 1 and args.to_version:
+E(" -t is only supported when upgrade one recipe\n")
+exit(1)
 else:
 updater = UniverseUpdater(recipes)
 updater.run()
-- 
2.15.1

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

[yocto] [auh][PATCH 03/21] upgradehelper.py: use UniverseUpdater for all cases

2017-12-21 Thread Alexander Kanavin

From: Robert Yang 

* Use UniverseUpdater() for the following 3 cases:
  + Upgrade all recipes
  + Upgrade 1 recipe
- '--maintainer' is not a must when any more when use --send-emails, the
  maintainer be got from distrodata.
  + Upgrade multiple recipes

* Use "args" as the parameter of UniverseUpdater() and Updater(), this can make
  the parameters simple, and easy for extending.

* Make upgrade "all" recipes respect the args, it didn't care --send-emails or
  --maintainer which would suprise the user.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 68 +---
 1 file changed, 30 insertions(+), 38 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index c81e748..e884597 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -129,11 +129,12 @@ def parse_config_file(config_file):
 return (settings, maintainer_override)
 
 class Updater(object):
-def __init__(self, auto_mode=False, send_email=False, 
skip_compilation=False):
+def __init__(self, args):
 build_dir = get_build_dir()
 
 self.bb = Bitbake(build_dir)
 self.devtool = Devtool()
+self.args = args
 
 try:
 self.base_env = self.bb.env()
@@ -143,7 +144,7 @@ class Updater(object):
 E( " Bitbake output:\n%s" % (e.stdout))
 exit(1)
 
-self._set_options(auto_mode, send_email, skip_compilation)
+self._set_options()
 
 self._make_dirs(build_dir)
 
@@ -152,7 +153,7 @@ class Updater(object):
 self.email_handler = Email(settings)
 self.statistics = Statistics()
 
-def _set_options(self, auto_mode, send_email, skip_compilation):
+def _set_options(self):
 self.opts = {}
 self.opts['layer_mode'] = settings.get('layer_mode', '')
 if self.opts['layer_mode'] == 'yes':
@@ -176,11 +177,11 @@ class Updater(object):
 self.opts['machines'] = settings.get('machines',
 'qemux86 qemux86-64 qemuarm qemumips qemuppc').split()
 
-self.opts['interactive'] = not auto_mode
-self.opts['send_email'] = send_email
+self.opts['interactive'] = not self.args.auto_mode
+self.opts['send_email'] = self.args.send_emails
 self.opts['author'] = "Upgrade Helper <%s>" % \
 settings.get('from', 'u...@not.set')
-self.opts['skip_compilation'] = skip_compilation
+self.opts['skip_compilation'] = self.args.skip_compilation
 self.opts['buildhistory'] = self._buildhistory_is_enabled()
 self.opts['testimage'] = self._testimage_is_enabled()
 
@@ -576,17 +577,25 @@ class Updater(object):
 self.send_status_mail(statistics_summary)
 
 class UniverseUpdater(Updater):
-def __init__(self, recipes=None):
-Updater.__init__(self, True, True)
+def __init__(self, args):
+Updater.__init__(self, args)
+
+if len(args.recipe) == 1 and args.recipe[0] == "all":
+self.recipes = []
+else:
+self.recipes = args.recipe
 
 # to filter recipes in upgrade
-if not recipes and self.opts['layer_mode'] == 'yes':
+if not self.recipes and self.opts['layer_mode'] == 'yes':
 # when layer mode is enabled and no recipes are specified
 # we need to figure out what recipes are provided by the
 # layer to try upgrade
 self.recipes = self._get_recipes_by_layer()
-else:
-self.recipes = recipes
+
+if args.to_version:
+if len(self.recipes) != 1:
+E(" -t is only supported when upgrade one recipe\n")
+exit(1)
 
 # read history file
 self.history_file = os.path.join(get_build_dir(), "upgrade-helper", 
"history.uh")
@@ -665,10 +674,16 @@ class UniverseUpdater(Updater):
 
 pn = row[0]
 cur_ver = row[1]
-next_ver = row[2]
+if self.args.to_version:
+next_ver = self.args.to_version
+else:
+next_ver = row[2]
 status = row[11]
 revision = row[12]
-maintainer = row[14]
+if self.args.maintainer:
+maintainer = self.args.maintainer
+else:
+maintainer = row[14]
 no_upgrade_reason = row[15]
 
 if status == 'UPDATE' and not no_upgrade_reason:
@@ -792,28 +807,5 @@ if __name__ == "__main__":
 level=debug_levels[args.debug_level - 1])
 settings, maintainer_override = parse_config_file(args.config_file)
 
-recipes = args.recipe
-
-if len(recipes) == 1 and recipes[0] == "all":
-updater = UniverseUpdater()
-updater.run()
-elif len(recipes) == 1 and args.to_version:
-if not args.maintainer and args.send_emails:
-E(" For upgrade one recipe and send email

[yocto] [auh][PATCH 05/21] upgradehelper.py: only check email settings when -e is specified

2017-12-21 Thread Alexander Kanavin

From: Robert Yang 

Fixed:
$ upgradehelper.py less
ERROR: smtp host not set! Sending emails disabled!
ERROR: 'From' address not set! Sending emails disabled!

Only check email settings when "-e" is specified can fix the problem.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index e884597..2061bfb 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -150,7 +150,8 @@ class Updater(object):
 
 self._add_file_logger()
 
-self.email_handler = Email(settings)
+if self.args.send_emails:
+self.email_handler = Email(settings)
 self.statistics = Statistics()
 
 def _set_options(self):
-- 
2.15.1

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

[yocto] [auh][PATCH 04/21] modules/steps.py: fix warn when skip compilation

2017-12-21 Thread Alexander Kanavin

From: Robert Yang 

Signed-off-by: Robert Yang 
---
 modules/steps.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/steps.py b/modules/steps.py
index 63f43c8..5bbe38e 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -113,7 +113,7 @@ def _compile(bb, pkg, machine, workdir):
 
 def compile(devtool, bb, git, opts, pkg_ctx):
 if opts['skip_compilation']:
-W(" %s: Compilation was skipped by user choice!")
+W(" %s: Compilation was skipped by user choice!" % pkg_ctx['PN'])
 return
 
 for machine in opts['machines']:
-- 
2.15.1

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

[yocto] [auh][PATCH 06/21] upgradehelper.py: always do upgrade when recipes are specified

2017-12-21 Thread Alexander Kanavin

From: Robert Yang 

For example, first run:
$ upgradehelper.py less -d 5
It did the upgrade

Second run:
$ upgradehelper.py less -d 5
DEBUG: Skipping upgrade of less: is in history and not 30 days passed

Let it always do the upgrade makes it easier to use when do upgrade locally.
It will still do the check when the recipe is all.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 2061bfb..3c40918 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -756,7 +756,10 @@ class UniverseUpdater(Updater):
 
 pkgs_list = []
 for pkg in self._parse_checkpkg_file(last_checkpkg_file):
-if self._pkg_upgradable(pkg[0], pkg[1], pkg[2]):
+# Always do the upgrade if recipes are specified
+if self.recipes and pkg[0] in self.recipes:
+pkgs_list.append(pkg)
+elif self._pkg_upgradable(pkg[0], pkg[1], pkg[2]):
 pkgs_list.append(pkg)
 
 return pkgs_list
-- 
2.15.1

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

[yocto] [auh][PATCH 07/21] upgradehelper.py: print info when recipe is skipped to upgrade

2017-12-21 Thread Alexander Kanavin

From: Robert Yang 

This makes debug easier.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 3c40918..80ea4f4 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -691,11 +691,11 @@ class UniverseUpdater(Updater):
 pkgs_list.append((pn, cur_ver, next_ver, maintainer, 
revision))
 else:
 if no_upgrade_reason:
-D(" Skip package %s (status = %s, current version = 
%s," \
+I(" Skip package %s (status = %s, current version = 
%s," \
 " next version = %s, no upgrade reason = %s)" %
 (pn, status, cur_ver, next_ver, no_upgrade_reason))
 else:
-D(" Skip package %s (status = %s, current version = 
%s," \
+I(" Skip package %s (status = %s, current version = 
%s," \
 " next version = %s)" %
 (pn, status, cur_ver, next_ver))
 return pkgs_list
-- 
2.15.1

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

[yocto] [auh][PATCH 08/21] upgradehelper.py: don't build gcc-runtime when --skip-compilation

2017-12-21 Thread Alexander Kanavin

From: Robert Yang 

It doesn't make any sense to build it when skip compile.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 80ea4f4..711d3b3 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -468,7 +468,7 @@ class Updater(object):
 pkgs_ctx[p]['base_dir'] = self.uh_recipes_all_dir
 I(" ")
 
-if pkgs_to_upgrade:
+if pkgs_to_upgrade and not self.args.skip_compilation:
 I(" Building gcc runtimes ...")
 for machine in self.opts['machines']:
 I("  building gcc runtime for %s" % machine)
-- 
2.15.1

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

[yocto] [auh][PATCH 09/21] upgradehelper.py: drop automatic mode

2017-12-21 Thread Alexander Kanavin

No longer used since migration to devtool: all upgrades are automatic

Signed-off-by: Alexander Kanavin 
---
 README   | 6 ++
 upgradehelper.py | 6 +-
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/README b/README
index 60dbef9..00a390a 100644
--- a/README
+++ b/README
@@ -134,12 +134,10 @@ Usage
 
 Some manual usage examples:
 
-* To upgrade the xmodmap recipe to the latest available version,
-  interactively:
+* To upgrade the xmodmap recipe to the latest available version:
 $ upgrade-helper.py xmodmap
 
-* To upgrade the xmodmap recipe to a user specified version,
-  interactively:
+* To upgrade the xmodmap recipe to a user specified version:
 $ upgrade-helper.py xmodmap -t 1.2.3
 
 * To attempt to upgrade all recipes and automatically send email
diff --git a/upgradehelper.py b/upgradehelper.py
index 711d3b3..d5a7112 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -60,7 +60,7 @@ from steps import upgrade_steps
 from testimage import TestImage
 
 help_text = """Usage examples:
-* To upgrade xmodmap recipe to the latest available version, interactively:
+* To upgrade xmodmap recipe to the latest available version:
 $ upgrade-helper.py xmodmap
 
 * To attempt to upgrade all recipes and automatically send email messages
@@ -82,9 +82,6 @@ def parse_cmdline():
 parser.add_argument("-m", "--maintainer",
 help="maintainer of the recipe")
 
-parser.add_argument("-a", "--auto-mode", action="store_true", 
default=False,
-help="disable interactive mode")
-
 parser.add_argument("-d", "--debug-level", type=int, default=4, 
choices=range(1, 6),
 help="set the debug level: CRITICAL=1, ERROR=2, 
WARNING=3, INFO=4, DEBUG=5")
 parser.add_argument("-e", "--send-emails", action="store_true", 
default=False,
@@ -178,7 +175,6 @@ class Updater(object):
 self.opts['machines'] = settings.get('machines',
 'qemux86 qemux86-64 qemuarm qemumips qemuppc').split()
 
-self.opts['interactive'] = not self.args.auto_mode
 self.opts['send_email'] = self.args.send_emails
 self.opts['author'] = "Upgrade Helper <%s>" % \
 settings.get('from', 'u...@not.set')
-- 
2.15.1

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

[yocto] [auh][PATCH 10/21] upgradehelper.py: replace the confusing 'maintainer' command line option

2017-12-21 Thread Alexander Kanavin

It wasn't clear what the option does, and why it need to be on the command line,
so the replacement is a 'global_maintainer_override' config file setting which
does the same thing, in a cleaner fashion.

Signed-off-by: Alexander Kanavin 
---
 README   | 7 ++-
 upgradehelper.py | 9 +++--
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/README b/README
index 00a390a..20b2e5d 100644
--- a/README
+++ b/README
@@ -28,6 +28,7 @@ Setup
 --- snip ---
 [maintainer_override]
 # mails for recipe upgrades will go to john.doe instead of jane.doe, etc
+# see also the global_maintainer_override option
 jane@doe.com=john@doe.com
 johhny.br...@bravo.com=john@doe.com
 
@@ -38,6 +39,10 @@ blacklist=python glibc gcc
 # only recipes belonging to maintainers in whitelist will be attempted
 maintainers_whitelist=jane@doe.com john@doe.com johhny.br...@bravo.com
 
+# email for all recipe upgrades will go to john.doe, except those listed
+# in specific maintainer_override entries above
+global_maintainer_override=john@doe.com
+
 # SMTP server
 smtp=smtp.my-server.com:25
 
@@ -84,7 +89,7 @@ INHERIT =+ "distrodata"
 
 WARNING: if you are using the default maintainers.inc file supplied
  with Poky (in meta-yocto) and you don't set a
- maintainers_whitelist or maintainer_override in the
+ maintainers_whitelist or (global_)maintainer_override in the
  upgrade-helper configuration as above, and you specify "all"
  on the command line, the script will automatically send out
  emails to the default maintainers. Please be careful not to
diff --git a/upgradehelper.py b/upgradehelper.py
index d5a7112..4623199 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -79,8 +79,6 @@ def parse_cmdline():
 
 parser.add_argument("-t", "--to_version",
 help="version to upgrade the recipe to")
-parser.add_argument("-m", "--maintainer",
-help="maintainer of the recipe")
 
 parser.add_argument("-d", "--debug-level", type=int, default=4, 
choices=range(1, 6),
 help="set the debug level: CRITICAL=1, ERROR=2, 
WARNING=3, INFO=4, DEBUG=5")
@@ -325,6 +323,8 @@ class Updater(object):
 
 if pkg_ctx['MAINTAINER'] in maintainer_override:
 to_addr = maintainer_override[pkg_ctx['MAINTAINER']]
+elif 'global_maintainer_override' in settings:
+to_addr = settings['global_maintainer_override']
 else:
 to_addr = pkg_ctx['MAINTAINER']
 
@@ -677,10 +677,7 @@ class UniverseUpdater(Updater):
 next_ver = row[2]
 status = row[11]
 revision = row[12]
-if self.args.maintainer:
-maintainer = self.args.maintainer
-else:
-maintainer = row[14]
+maintainer = row[14]
 no_upgrade_reason = row[15]
 
 if status == 'UPDATE' and not no_upgrade_reason:
-- 
2.15.1

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

[yocto] [auh][PATCH 11/21] weeklyjob.sh: set up a temporary branch and clean up afterwards

2017-12-21 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 weeklyjob.sh | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/weeklyjob.sh b/weeklyjob.sh
index e2c4b1a..8dd0a1c 100755
--- a/weeklyjob.sh
+++ b/weeklyjob.sh
@@ -7,11 +7,23 @@
 #
 # 00 8   * * 6   auh  /home/auh/bin/weeklyjob.sh
 
+# Re-assign these to match your setup!
 auh_dir=~/auto-upgrade-helper
 poky_dir=~/poky
 build_dir=~/build
+sstate_dir=~/sstate-cache
+
+pushd $poky_dir
+
+# Base the upgrades on poky master
+git fetch origin
+git checkout -B tmp-auh-upgrades origin/master
 
 source $poky_dir/oe-init-build-env $build_dir
 $auh_dir/upgradehelper.py all
 
-#/usr/bin/rsync --delete --password-file /home/auh/rsync.passwd 
--copy-unsafe-links -zaHS /home/auh/work/ a...@downloads.yoctoproject.org::auh/
+# clean up to avoid the disk filling up
+rm -rf $build_dir/tmp/
+find $sstate_dir -atime +10 -delete
+
+popd
-- 
2.15.1

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

[yocto] [auh][PATCH 12/21] Add support for compiling against non-default C libraries

2017-12-21 Thread Alexander Kanavin

Particularly, musl is a notorious source of failures and so it's
very useful to do at least one build against it by default.

Signed-off-by: Alexander Kanavin 
---
 README   | 4 +++-
 modules/utils/bitbake.py | 7 ++-
 upgradehelper.py | 2 +-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/README b/README
index 20b2e5d..fabde5c 100644
--- a/README
+++ b/README
@@ -65,7 +65,9 @@ clean_sstate=yes
 clean_tmp=yes
 
 # machines to test build with
-machines=qemux86 qemux86-64 qemuarm qemumips qemuppc
+# append _libc-name to test with alternative C library implementations
+# e.g. qemux86_musl
+machines=qemux86 qemux86_musl qemux86-64 qemuarm qemumips qemuppc
 
 # optional features
 buildhistory=no
diff --git a/modules/utils/bitbake.py b/modules/utils/bitbake.py
index 8b7c5ed..2ae3a1c 100644
--- a/modules/utils/bitbake.py
+++ b/modules/utils/bitbake.py
@@ -121,7 +121,12 @@ class Bitbake(object):
 return self._cmd(recipe, "-c cleansstate")
 
 def complete(self, recipe, machine):
-return self._cmd(recipe, env_var="MACHINE=" + machine)
+if "_" in machine:
+machine, libc = machine.split("_")
+env = "MACHINE={} TCLIBC={}".format(machine, libc)
+else:
+env = "MACHINE={}".format(machine)
+return self._cmd(recipe, env_var=env)
 
 def dependency_graph(self, package_list):
 return self._cmd(package_list, "-g")
diff --git a/upgradehelper.py b/upgradehelper.py
index 4623199..a33a3bf 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -171,7 +171,7 @@ class Updater(object):
 self.git = Git(os.path.dirname(os.getenv('PATH', 
False).split(':')[0]))
 self.poky_git = None
 self.opts['machines'] = settings.get('machines',
-'qemux86 qemux86-64 qemuarm qemumips qemuppc').split()
+'qemux86 qemux86-64 qemuarm qemumips qemuppc 
qemux86_musl').split()
 
 self.opts['send_email'] = self.args.send_emails
 self.opts['author'] = "Upgrade Helper <%s>" % \
-- 
2.15.1

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

[yocto] [auh][PATCH 13/21] Add protection measures and information against running with existing build directories.

2017-12-21 Thread Alexander Kanavin

This should help e.g. with the following issue:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7174

Signed-off-by: Alexander Kanavin 
---
 README   | 12 
 upgradehelper.py | 14 ++
 weeklyjob.sh |  2 +-
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/README b/README
index fabde5c..27b0977 100644
--- a/README
+++ b/README
@@ -17,10 +17,14 @@ Setup
$ git config --global user.name "Some Name"
$ git config --global user.email "somen...@somedomain.com"
 
-1. Ensure you have a working copy of the build system that is configured
-   and ready to run, i.e. you've run the oe-init-build-env script to
-   create a build directory and edited local.conf / bblayers.conf as
-   desired.
+1. Run the oe-init-build-env script to create a fresh build directory, solely
+   for the purpose of running AUH:
+
+   $ . ./oe-init-build-env build-auh
+
+   Re-using existing build directories and configurations is not recommended
+   as they may contains tweaks that will break AUH or make it behave in
+   undesirable ways.
 
 2. Prepare a configuration file, by default in $BUILDDIR/upgrade-helper/
upgrade-helper.conf, as below:
diff --git a/upgradehelper.py b/upgradehelper.py
index a33a3bf..9110efc 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -788,6 +788,8 @@ if __name__ == "__main__":
 
 if not os.getenv('BUILDDIR', False):
 E(" You must source oe-init-build-env before running this script!\n")
+E(" It is recommended to create a fresh build directory with it:\n")
+E(" $ . oe-init-build-env build-auh\n")
 exit(1)
 
 devnull = open(os.devnull, 'wb')
@@ -796,6 +798,18 @@ if __name__ == "__main__":
 E(" Git isn't configured please configure user name and email\n")
 exit(1)
 
+with open(os.getenv('BUILDDIR')+"/conf/local.conf") as f:
+import re
+for line in f.readlines():
+if re.match(r"^MACHINE\s*=", line):
+E(" The following line found in local.conf - please use ?= or 
?== instead as otherwise AUH will not be able to set the desired target 
machine\n")
+E(" {}".format(line))
+exit(1)
+if re.match(r"^TCLIBC\s*=", line):
+E(" The following line found in local.conf - please use ?= or 
?== instead as otherwise AUH will not be able to set the desired C library\n")
+E(" {}".format(line))
+exit(1)
+
 signal.signal(signal.SIGINT, close_child_processes)
 
 debug_levels = [log.CRITICAL, log.ERROR, log.WARNING, log.INFO, log.DEBUG]
diff --git a/weeklyjob.sh b/weeklyjob.sh
index 8dd0a1c..ac50461 100755
--- a/weeklyjob.sh
+++ b/weeklyjob.sh
@@ -10,7 +10,7 @@
 # Re-assign these to match your setup!
 auh_dir=~/auto-upgrade-helper
 poky_dir=~/poky
-build_dir=~/build
+build_dir=~/build-tmp-auh-upgrades
 sstate_dir=~/sstate-cache
 
 pushd $poky_dir
-- 
2.15.1

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

[yocto] [auh][PATCH 15/21] Do not require configuration options that aren't necessary for running ptests

2017-12-21 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 README   |  6 ++
 upgradehelper.py | 15 ---
 2 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/README b/README
index 27b0977..acb22ac 100644
--- a/README
+++ b/README
@@ -122,10 +122,8 @@ file:
 --- snip ---
 INHERIT += "testimage"
 
-DISTRO_FEATURES_append = " ptest"
-EXTRA_IMAGE_FEATURES = "debug-tweaks package-management ptest-pkgs"
-# testimage/ptest only work with rpm
-PACKAGE_CLASSES = "package_rpm"
+# Add the following if your distro does not enable by default (poky does)
+#DISTRO_FEATURES_append = " ptest"
 --- snip ---
 
 Also if you are running in a server without X11 session, you need to start
diff --git a/upgradehelper.py b/upgradehelper.py
index cb48c47..5659735 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -251,21 +251,6 @@ class Updater(object):
   " conf/local.conf.")
 exit(1)
 
-if not "package-management" in 
self.base_env['EXTRA_IMAGE_FEATURES']:
-E(" testimage requires package-management in 
EXTRA_IMAGE_FEATURES"\
-  " please add to conf/local.conf.")
-exit(1)
-
-if not "ptest-pkgs" in self.base_env['EXTRA_IMAGE_FEATURES']:
-E(" testimage/ptest requires ptest-pkgs in 
EXTRA_IMAGE_FEATURES"\
-  " please add to conf/local.conf.")
-exit(1)
-
-if not "package_rpm" == self.base_env["PACKAGE_CLASSES"]:
-E(" testimage/ptest requires PACKAGE_CLASSES set to 
package_rpm"\
-  " please add to conf/local.conf.")
-exit(1)
-
 enabled = True
 else:
 E(" testimage was enabled in upgrade-helper.conf"\
-- 
2.15.1

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

[yocto] [auh][PATCH 14/21] upgradehelper.py: do not include absolute paths in the generated tarball

2017-12-21 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 9110efc..cb48c47 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -555,9 +555,11 @@ class Updater(object):
 os.path.basename(self.uh_work_dir) + '.tar.gz')
 if publish_work_url:
 I(" Generating work tarball in %s ..." % work_tarball)
+tar_cmd = ["tar", "-chzf", work_tarball, "-C", 
self.uh_base_work_dir, os.path.basename(self.uh_work_dir)]
 import subprocess
-if subprocess.call(["tar", "-chzf", work_tarball, 
self.uh_work_dir]):
+if subprocess.call(tar_cmd):
 E(" Work tarball (%s) generation failed..." % 
(work_tarball))
+E(" Tar command: %s" % (" ".join(tar_cmd)))
 publish_work_url = ''
 
 statistics_summary = self.statistics.get_summary(
-- 
2.15.1

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

[yocto] [auh][PATCH 16/21] upgradehelper.py: do not include testimage information in maintainer email messages

2017-12-21 Thread Alexander Kanavin

There's some logic to ascribe failures to specific recipe upgrade commits; it's 
prone
to mismatches and is lacking context about what else was upgraded. Let's make 
testimage
support available for local maintainer use only - unattended mass-upgrades will 
not
try to run testimages.

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 5659735..1170ca5 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -290,17 +290,6 @@ class Updater(object):
 "you can fill RECIPE_NO_UPDATE_REASON in respective recipe file so 
that\n" \
 "automatic upgrades would no longer be attempted.\n\n"
 
-testimage_integration_error = \
-"The recipe *FAILED* in testimage integration. Attached is the log 
file.\n\n"
-
-testimage_ptest_info = \
-"The recipe has ptest enabled and has been tested with 
core-image-minimal/ptest \n" \
-"with the next machines %s. Attached is the log file.\n\n"
-
-testimage_info = \
-"The recipe has been tested using %s testimage and succeeded with 
\n" \
-"the next machines %s. Attached is the log file.\n\n" \
-
 mail_footer = \
 "Please review the attached files for further information and 
build/update failures.\n" \
 "Any problem please file a bug at 
https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Automated%20Update%20Handler\n\n";
 \
@@ -342,18 +331,6 @@ class Updater(object):
 if 'patch_file' in pkg_ctx and pkg_ctx['patch_file'] != None:
 msg_body += next_steps_info % 
(os.path.basename(pkg_ctx['patch_file']))
 
-if self.opts['testimage']:
-if 'integration_error' in pkg_ctx:
-msg_body += testimage_integration_error
-else:
-if 'ptest' in pkg_ctx:
-machines = pkg_ctx['ptest'].keys()
-msg_body += testimage_ptest_info % machines
-if 'testimage' in pkg_ctx:
-machines = pkg_ctx['testimage'].keys()
-msg_body += testimage_info % 
(settings.get('testimage_name', \
-DEFAULT_TESTIMAGE), machines)
-
 msg_body += mail_footer
 
 # Add possible attachments to email
-- 
2.15.1

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

[yocto] [auh][PATCH 17/21] testimage.py: clarify what arguments are passed to class constructor

2017-12-21 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 modules/testimage.py | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/modules/testimage.py b/modules/testimage.py
index 6c4ed2b..86e817c 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -1,4 +1,3 @@
-#!/usr/bin/env python
 # vim: set ts=4 sw=4 et:
 #
 # Copyright (c) 2015 Intel Corporation
@@ -42,13 +41,13 @@ def _pn_in_pkgs_ctx(pn, pkgs_ctx):
 return None
 
 class TestImage():
-def __init__(self, bb, git, uh_work_dir, opts, *args, **kwargs):
+def __init__(self, bb, git, uh_work_dir, opts, packages, image):
 self.bb = bb
 self.git = git
 self.uh_work_dir = uh_work_dir
 self.opts = opts
-self.pkgs_ctx = args[0]['succeeded'][:]
-self.image = args[1]
+self.pkgs_ctx = packages['succeeded']
+self.image = image
 
 os.environ['BB_ENV_EXTRAWHITE'] = os.environ['BB_ENV_EXTRAWHITE'] + \
 " TEST_SUITES CORE_IMAGE_EXTRA_INSTALL"
-- 
2.15.1

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

[yocto] [auh][PATCH 18/21] testimage.py: run even if no packages were upgraded

2017-12-21 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 modules/testimage.py | 4 
 1 file changed, 4 deletions(-)

diff --git a/modules/testimage.py b/modules/testimage.py
index 86e817c..1195916 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -256,10 +256,6 @@ class TestImage():
 return handled
 
 def run(self):
-if len(self.pkgs_ctx) <= 0:
-I(" Testimage was enabled but any upgrade was successful.")
-return
-
 I(" Images will test for %s." % ', '.join(self.opts['machines']))
 for machine in self.opts['machines']:
 I("  Testing images for %s ..." % machine)
-- 
2.15.1

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

[yocto] [auh][PATCH 19/21] testimage.py: remove all iterations (over machines, over failing recipes)

2017-12-21 Thread Alexander Kanavin

This adds enormously to run time, and is not particularly necessary
when running locally. If something fails, it's best to let the maintainer sort
it out as soon as possible, rather than try to guess what needs to be excluded.

Also, do not build a separate ptest image; ptests will be added
to the standard integration testimage.

Signed-off-by: Alexander Kanavin 
---
 README   |   9 +++--
 modules/testimage.py | 107 ++-
 2 files changed, 9 insertions(+), 107 deletions(-)

diff --git a/README b/README
index acb22ac..84e140f 100644
--- a/README
+++ b/README
@@ -68,9 +68,12 @@ clean_sstate=yes
 # clean tmp directory before upgrading
 clean_tmp=yes
 
-# machines to test build with
-# append _libc-name to test with alternative C library implementations
-# e.g. qemux86_musl
+# Machines to test build with.
+# Append _libc-name to test with alternative C library implementations
+# e.g. qemux86_musl.
+#
+# Buildhistory and testimages will be created only for the first
+# machine in the list, as otherwise it adds enormously to AUH run time.
 machines=qemux86 qemux86_musl qemux86-64 qemuarm qemumips qemuppc
 
 # optional features
diff --git a/modules/testimage.py b/modules/testimage.py
index 1195916..d2479f5 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -139,46 +139,6 @@ class TestImage():
 raise IntegrationError(e.stdout, pkg_ctx)
 raise e
 
-def ptest(self, pkgs_ctx, machine):
-image = 'core-image-minimal'
-# should use bitbake API here to trim down the list to only the 
recipes that inherit ptest
-ptest_pkgs = pkgs_ctx
-
-os.environ['CORE_IMAGE_EXTRA_INSTALL'] = \
-self._get_pkgs_to_install(ptest_pkgs, ptest=True)
-I( "   building %s for %s ..." % (image, machine))
-try:
-self.bb.complete(image, machine)
-except Error as e:
-self._handle_image_build_error(image, pkgs_ctx, e)
-
-os.environ['TEST_SUITES'] = "ping ssh _ptest"
-I( "   running %s/ptest for %s ..." % (image, machine))
-self.bb.complete("%s -c testimage" % image, machine)
-
-ptest_log_file = self._find_log("ptest.log", machine)
-shutil.copyfile(ptest_log_file,
-os.path.join(self.uh_work_dir, "ptest_%s.log" % machine))
-
-ptest_result = self._parse_ptest_log(ptest_log_file)
-for pn in ptest_result:
-for pkg_ctx in pkgs_ctx:
-if not pn == pkg_ctx['PN']:
-continue 
-
-if not 'ptest' in pkg_ctx:
-pkg_ctx['ptest'] = {}
-if not 'ptest_log' in pkg_ctx:
-pkg_ctx['ptest_log'] = os.path.join(pkg_ctx['workdir'],
-"ptest.log")
-
-pkg_ctx['ptest'][machine] = True
-with open(pkg_ctx['ptest_log'], "a+") as f:
-f.write("BEGIN: PTEST for %s\n" % machine)
-for line in ptest_result[pn]:
-f.write(line)
-f.write("END: PTEST for %s\n" % machine)
-
 def testimage(self, pkgs_ctx, machine, image):
 os.environ['CORE_IMAGE_EXTRA_INSTALL'] = \
 self._get_pkgs_to_install(pkgs_ctx)
@@ -213,68 +173,7 @@ class TestImage():
 of.write(line)
 of.write("END: TESTIMAGE for %s\n" % machine)
 
-def _log_error(self, e):
-if isinstance(e, Error):
-E(" %s" % e.stdout)
-else:
-import traceback
-tb = traceback.format_exc()
-E("%s" % tb)
-
-def _handle_error(self, e, machine):
-handled = True
-
-if isinstance(e, IntegrationError):
-pkg_ctx = e.pkg_ctx
-
-E("   %s on machine %s failed in integration, removing..."
-% (pkg_ctx['PN'], machine))
-
-with open(os.path.join(pkg_ctx['workdir'],
-'integration_error.log'), 'a+') as f:
-f.write(e.stdout)
-
-if not pkg_ctx in self.pkgs_ctx:
-E("   Infinite loop IntegrationError trying to " \
-   "remove %s twice, see logs.", pkg_ctx['PN'])
-handled = False
-else:
-pkg_ctx['integration_error'] = e
-
-# remove previous build tmp, sstate to avoid QA errors
-# on lower versions
-I(" removing sstate directory ...")
-shutil.rmtree(os.path.join(get_build_dir(), "sstate-cache"))
-I(" removing tmp directory ...")
-shutil.rmtree(os.path.join(get_build_dir(), "tmp"))
-
-self.pkgs_ctx.remove(pkg_ctx)
-
-else:
-handled = False
-
-return handled
-
 def run(self):
-I(" Images will test for %s." % ', '.join(self.opts['machines']))
-for machine in self.opts['machi

[yocto] [auh][PATCH 20/21] testimage.py: rewrite the logic for building and running testimages

2017-12-21 Thread Alexander Kanavin

Particularly:
1) determine per-package if ptest is supported, and add to the list
of packages to install accordingly
2) remove broken code that finds image logs in the build directory;
this will be replaced in the following commit
3) remove code that parses said logs for specific package failures;
this is prone to mistmatches and is best left to a human.

Signed-off-by: Alexander Kanavin 
---
 modules/testimage.py | 115 +--
 1 file changed, 10 insertions(+), 105 deletions(-)

diff --git a/modules/testimage.py b/modules/testimage.py
index d2479f5..699d619 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -50,129 +50,34 @@ class TestImage():
 self.image = image
 
 os.environ['BB_ENV_EXTRAWHITE'] = os.environ['BB_ENV_EXTRAWHITE'] + \
-" TEST_SUITES CORE_IMAGE_EXTRA_INSTALL"
+" CORE_IMAGE_EXTRA_INSTALL"
 
-def _get_pkgs_to_install(self, pkgs, ptest=False):
+def _get_pkgs_to_install(self, pkgs):
 pkgs_out = []
 
-# for provide access to the target
-if ptest:
-pkgs_out.append("dropbear")
-pkgs_out.append("ptest-runner")
-
 for c in pkgs:
 pkgs_out.append(c['PN'])
 
-return ' '.join(pkgs_out)
-
-def _parse_ptest_log(self, log_file):
-ptest_results = {}
-
-with open(log_file, "r") as f:
-pn = None
-processing = False
-
-for line in f:
-if not processing:
-m = re.search("^BEGIN: /usr/lib/(.*)/ptest$", line)
-if m:
-pn = m.group(1)
-ptest_results[pn] = []
-processing = True
-else:
-m = re.search("^END: $", line)
-if m:
-pn = None
-processing = False
-else:
-ptest_results[pn].append(line)
-
-return ptest_results
-
-def _find_log(self, name, machine):
-result = []
-
-base_dir = os.path.join(os.getenv('BUILDDIR'), 'tmp', 'work')
-for root, dirs, files in os.walk(base_dir):
-if name in files:
-result.append(os.path.join(root, name))
-
-D("Found logs named %s for machine %s: %s" %(name, machine, result))
-for ptest_log in result:
-if machine in ptest_log:
-D("Picked log: %s" %(ptest_log))
-return ptest_log
-
-def _get_failed_recipe(self, log):
-pn = None
-
-for line in log.splitlines():
-m = re.match("ERROR: QA Issue: ([^ :]*): (.*) not shipped", line)
-if m:
-pn = m.group(1)
-break
-
-m = re.match("ERROR: Logfile of failure stored in: " \
-"(.*/([^/]*)/[^/]*/temp/log\.(.*)\.[0-9]*)", line)
-if m:
-pn = m.group(2)
-break
-
-return pn
-
-def _handle_image_build_error(self, image, pkgs_ctx, e):
-pn = self._get_failed_recipe(e.stdout)
-if pn and pn != image:
-pkg_ctx = _pn_in_pkgs_ctx(pn, pkgs_ctx)
-if pkg_ctx:
-raise IntegrationError(e.stdout, pkg_ctx)
+I(" Checking if package {} has ptests...".format(c['PN']))
+if 'PTEST_ENABLED' in self.bb.env(c['PN']):
+I("  ...yes")
+pkgs_out.append((c['PN']) + '-ptest')
 else:
-pn_env = self.bb.env(pn)
-
-depends = pn_env['DEPENDS'].split()
-rdepends = pn_env['RDEPENDS'].split()
-deps = depends + rdepends
+I("  ...no")
 
-for d in deps:
-pkg_ctx = _pn_in_pkgs_ctx(d, pkgs_ctx)
-if pkg_ctx:
-raise IntegrationError(e.stdout, pkg_ctx)
-raise e
+return ' '.join(pkgs_out)
 
 def testimage(self, pkgs_ctx, machine, image):
 os.environ['CORE_IMAGE_EXTRA_INSTALL'] = \
 self._get_pkgs_to_install(pkgs_ctx)
-
-if 'TEST_SUITES' in os.environ:
-del os.environ['TEST_SUITES']
+I( " Installing additional packages to the image: 
{}".format(os.environ['CORE_IMAGE_EXTRA_INSTALL']))
 
 I( "   building %s for %s ..." % (image, machine))
-try:
-self.bb.complete(image, machine)
-except Error as e:
-self._handle_image_build_error(image, pkgs_ctx, e)
+self.bb.complete(image, machine)
 
 I( "   running %s/testimage for %s ..." % (image, machine))
 self.bb.complete("%s -c testimage" % image, machine)
 
-log_file = self._find_log("log.do_testimage", machine)
-shutil.copyfile(log_file,
-os.path.join(self.uh_work_dir, "log_%s.do_testimage" % 
machine))
-for pkg_ctx in pkgs_c

[yocto] [auh][PATCH 21/21] testimage.py: collect and write out logs from bitbake and testimage

2017-12-21 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 modules/testimage.py | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/modules/testimage.py b/modules/testimage.py
index 699d619..35e23c9 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -49,8 +49,11 @@ class TestImage():
 self.pkgs_ctx = packages['succeeded']
 self.image = image
 
+self.logdir = os.path.join(uh_work_dir, "testimage-logs")
+os.mkdir(self.logdir)
+
 os.environ['BB_ENV_EXTRAWHITE'] = os.environ['BB_ENV_EXTRAWHITE'] + \
-" CORE_IMAGE_EXTRA_INSTALL"
+" CORE_IMAGE_EXTRA_INSTALL TEST_LOG_DIR TESTIMAGE_UPDATE_VARS"
 
 def _get_pkgs_to_install(self, pkgs):
 pkgs_out = []
@@ -70,13 +73,33 @@ class TestImage():
 def testimage(self, pkgs_ctx, machine, image):
 os.environ['CORE_IMAGE_EXTRA_INSTALL'] = \
 self._get_pkgs_to_install(pkgs_ctx)
+os.environ['TEST_LOG_DIR'] = self.logdir
+os.environ['TESTIMAGE_UPDATE_VARS'] = 'TEST_LOG_DIR'
 I( " Installing additional packages to the image: 
{}".format(os.environ['CORE_IMAGE_EXTRA_INSTALL']))
 
 I( "   building %s for %s ..." % (image, machine))
-self.bb.complete(image, machine)
+bitbake_create_output = ""
+bitbake_run_output = ""
+try:
+bitbake_create_output = self.bb.complete(image, machine)
+except Error as e:
+I( "   building the testimage failed! Collecting logs...")
+bitbake_create_output = e.stdout
+else:
+I( "   running %s/testimage for %s ..." % (image, machine))
+try:
+bitbake_run_output = self.bb.complete("%s -c testimage" % 
image, machine)
+except Error as e:
+I( "   running the testimage failed! Collecting logs...")
+bitbake_run_output = e.stdout
 
-I( "   running %s/testimage for %s ..." % (image, machine))
-self.bb.complete("%s -c testimage" % image, machine)
+if bitbake_create_output:
+with open(os.path.join(self.logdir, 
"bitbake-create-testimage.log"), 'w') as f:
+f.write(bitbake_create_output)
+if bitbake_run_output:
+with open(os.path.join(self.logdir, "bitbake-run-testimage.log"), 
'w') as f:
+f.write(bitbake_run_output)
+I(" All done! Testimage/ptest/qemu logs are collected to 
{}".format(self.logdir))
 
 def run(self):
 machine = self.opts['machines'][0]
-- 
2.15.1

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

Re: [yocto] libgfortran or cross compiling a fortran application

2017-12-21 Thread Matthias Schöpfer

Hi!

Just in case, someone (else) stumbles across this:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12394
http://cgit.openembedded.org/openembedded-core/commit/?id=2c2f20a9756eccafac776e45e319af7666e6da96

fixes the issue on rocko for me.

Regards,

Matthias

On 12/20/2017 11:30 AM, Matthias Schöpfer wrote:
> Hi there,
> 
> I am trying to cross compile a fortran library (lapack), which fails
> because it cannot find libgfortran.
> 
> So I am trying to build libgfortran. I added:
> 
> FORTRAN_forcevariable = ",fortran"
> 
> to enable support for fortran cross compile in local conf. Anyhow,
> bitbake libgfortran still fails:
> 
> | /bin/sh ./libtool  --tag=CC   --mode=compile x86_64-idp-linux-gcc
> -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
> --sysroot=/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/recipe-sysroot
> -DHAVE_CONFIG_H -I.
> -I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran
>  
> -iquote../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/io
>  
> -I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/../gcc
>  
> -I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/../gcc/config
>   
> -I/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/gcc-7.2.0/build.x86_64-idp-linux.x86_64-idp-linux/x86_64-idp-linux/libgfortran/../.././gcc
>  
> -I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/../libgcc
>  
> -I/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/gcc-7.2.0/build.x86_64-idp-linux.x86_64-idp-linux/x86_64-idp-linux/libgfortran/../libgcc
>  
> -I../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/../libbacktrace
>  
> -I/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/gcc-7.2.0/build.x86_64-idp-linux.x86_64-idp-linux/x86_64-idp-linux/libgfortran/../libbacktrace
>  -I../libbacktrace  -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes 
> -Wold-style-definition -Wextra -Wwrite-strings 
> -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules 
> -ffunction-sections -fdata-sections   -std=gnu11  -O2 -pipe -g 
> -feliminate-unused-debug-types 
> -fdebug-prefix-map=/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0=/usr/src/debug/libgfortran/7.2.0-r0
>  
> -fdebug-prefix-map=/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/recipe-sysroot-native=
>  
> -fdebug-prefix-map=/home/mschoepf/identpro/yocto/ros-devel/tmp/work/core2-64-idp-linux/libgfortran/7.2.0-r0/recipe-sysroot=
>   -Wunknown-pragmas -c -o main.lo `test -f 'runtime/main.c' || echo 
> '../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/'`runtime/main.c
> |
> ../../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/libgfortran/runtime/backtrace.c:36:10:
> fatal error: backtrace-supported.h: No such file or directory
> |  #include "backtrace-supported.h"
> |   ^~~
> | compilation terminated.
> 
> Any help, hints and wild guesses are welcome.
> 
> Regards,
> 
>   Matthias
> 


-- 
Dr.-Ing. Matthias Schöpfer

Softwareentwicklung



IdentPro GmbH
Camp-Spich-Str. 4
53842 Troisdorf

Tel:   +49 (0)2241 / 866 392 46
Fax:   +49 (0)2241 / 866 392 99
eMail: matthias.schoep...@identpro.de

http://www.identpro.de

identplus® – Das 3D Staplerleitsystem mit enormen Sparpotenzial: z. B.
über 67.000 EUR pro Jahr bei 500 Transporten täglich! Berechnen Sie das
Einsparpotenzial für Ihr Lager mit dem identplus® Potenzialrechner.

identplus® live erleben: Vereinbaren Sie jetzt einen Termin!

-
IdentPro GmbH
Member of Dr. Wack Holding GmbH & Co.KG
Sitz und Registergericht: St. Augustin, HRB 9770 Siegburg
Geschäftsführer: Michael Wack
Umsatzsteuer-ID-Nr.: DE 254 824 945
WEEE-Reg.-Nr. DE 79026890
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Python cryptography failing due to undefined symbol: pthread_atfork

2017-12-21 Thread Alan Martinovic

Hi there,
just did a migration to Rocko and am witnessing"

root@device:~# python3
Python 3.5.3 (default, Dec 20 2017, 02:02:22)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from cryptography.hazmat.bindings._openssl import ffi, lib
Traceback (most recent call last):
  File "", line 1, in 
ImportError:
/usr/lib/python3.5/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so:
undefined symbol: pthread_atfork


Have tried both the recipe that comes with Rocko
and master of meta-openembedded.

Seems to be the same bug as this one:

https://bugs.gentoo.org/630578

resolved with this patch:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c824d1c44fcf4556de21d2c8b8ae3732b0fc0c5b

Can someone provide hints on what would that translate to
 for the python cryptography recipe?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] linux kernel rt

2017-12-21 Thread Andreas Müller

On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan  wrote:

> Hi all,
>
> On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller 
> wrote:
>
>> On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak 
>> wrote:
>>
>>> 2017-12-14 9:41 GMT+01:00 Andreas Müller :
>>> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <
>>> sherifomran2...@gmail.com>
>>> > wrote:
>>> >>
>>> >> hey guys,
>>> >>
>>> >> any body tried the real time kernel? I get an error, it is snot in the
>>> >> compatibility list.
>>> >> can we skip it?
>>> >>
>>> >> thanks
>>> >>
>>> >> --
>>> >
>>> > Good news: I use RT kernel only together with VC4 graphics and have
>>> lots of
>>> > fun on PI2/3.
>>> > Bad news: As far as I know it is not in meta-raspberrypi but in my
>>> fork [1].
>>> > There were attempts to land the RT-patches in meta-raspberrypi but
>>> that was
>>> > denied for huge patch size :(
>>>
>>> If the patch size was the only problem one can pull it by doing the
>>> following in the recipe:
>>>
>>> SRC_URI += " \
>>> https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patc
>>> h-4.9.65-rt56.patch.gz;name=rt-patch
>>> \
>>> "
>>>
>>> SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
>>> SRC_URI[rt-patch.sha256sum] =
>>> "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"
>>>
>>> Note that above sums are "random" and not the for the actually file
>>> but are there for reference.
>>>
>>> That way you do not need to keep a copy of it in meta-raspberrypi.
>>>
>>> --
>>>
>> Hi Mirza,
>>
>> Problem is that patches need alignments sometimes either caused by
>> Raspberry-Pi-specific adjustments or versions not matching exactly - RT
>> kernel patch updates are less frequent than kernel updates. Anyway: git is
>> very good at maintaining huge text content and this should not be a problem
>> these days. Another discussion about RT kernel was to have an extra kernel
>> for it and I never understood why. To me that seems nothing but an extra
>> maintenance burden.
>>
>> However - just wrote to Paul: I plan to be at FOSDEM and we can discuss
>> there how to get back to one layer only (not mine!) making everybody happy
>> :)
>>
>>
> I remember the discussion. Indeed that was the reason and the
> recommendation was to maintain a separate linux-raspberry fork where
> whoever has interest in this will maintain on top of linux-raspberrypi this
> patch. Obviously that didn't happen but I'd like to see it landing.
>
> Yes that was one of the suggestions which made me say 'Thanks - this is
just additional maintenance burden and will not work for long time - I do
my own'. FWIW: That suggestion came at a time when you (Andrei) seemed
overworked totally (just to mention - PLEASE don't take it as criticism - I
know what I am talking of when it comes to 'overworked').

Why not simply one stable kernel with RT-patches applied if user decides by
an option? That is what I am doing for >1 year now and meta-raspi-light is
the one which caused me least efforts/headaches of all. And yes I know I
made life easy here by removing userland completely and taking care for
RPi2/3 only.

Cheers,

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

Re: [yocto] add kernel modules & dtbo's for Raspberry Pi3

2017-12-21 Thread Greg Wilson-Lindberg

Hi Trevor,

Other than the fact that I was using '()' instead of '{}' for the file name, 
your catch of the missing ':' got the file include fixed. And your suggestion 
for including the Device Tree Overlays was perfect. Thanks,

I seem to have something still messed up in the kernel configs though, it looks 
like my file is getting included, or at least the path is not blowing up, but 
the config elements are not being set.

Here is my Scribe.cfg file:

# Enable MAX9768
CONFIG_SND_SOC_MAX9768=m

# Enable MAX11606
CONFIG_MAX1363=m

The 'CONFIG_SND_SOC_MAX9768' is not showing up at all in the .config file, and 
the 'CONFIG_MAX1363' is not set. They both are found in the appropriate Kconfig 
files.

Is there something else that I'm missing?

Regards,

Greg

From: Trevor Woerner 
Sent: Thursday, December 21, 2017 4:30:20 AM
To: Greg Wilson-Lindberg
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] add kernel modules & dtbo's for Raspberry Pi3

On Wed 2017-12-20 @ 11:40:50 PM, Greg Wilson-Lindberg wrote:
> I'm building an image for the Raspberry Pi 3 and I'm trying to add some
> modules to the kernel and I need to add some device tree overlays. The
> modules and overlays are part of the kernel, just not built by default.
>
> For the kernel modules I've added a linux-raspberrypi_4.4.bbappend file in
> the path .../recipes-bsp/linux. The file consists of:
>
> # Scribe additions to Kernel configuration
>
> FILESEXTRAPATHS_prepend += "$(THISDIR)/files"
> SRC_URI += "file://Scribe.cfg"
>
> Whether I use "+=" or ":=" as suggested in "Embedded Linux Systems withe
> the Yocto Project", I get an error that "file://0001-fix-dtbo-rules.patch"
> cannot be found. I don't get this error if my .bbappend file is not being
> used.

You're missing a colon at the end of the path definition, and you should use
the ':=' operator:

FILESEXTRAPATHS_prepend := "$(THISDIR)/files:"

The path you're introducing is getting added to a bunch of other paths, and
therefore needs the separator. The := operator causes your change to this
variable to be immediately expanded by bitbake, which is what you want.

> Also, if there are any quick tips on how to add dtbo's to the kernel build I
> would appreciate them.

If you look through the raspberry pi kernel sources

($TMPDIR/work/raspberrypi3-*/linux-raspberrypi/${VERSION}/linux-raspberrypi3-standard-build/source)
at
arch/arm/boot/dts/overlays

and find an overlay you like (e.g. spi1-3cs-overlay.dts) then to have it added
to your image and applied at boot time:

1. edit local.conf to add it to the kernel's device tree (but add it as a dtbo
without the "-overlay"):

KERNEL_DEVICETREE_append = " overlays/spi1-3cs.dtbo"

2. extend rpi-config to include it in the image's config.txt file:

rpi-config_%.bbappend:
do_deploy_append() {
echo "dtoverlay=spi1-3cs" 
>>${DEPLOYDIR}/bcm2835-bootfiles/config.txt"
}
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] how to deal with the dependency explosion caused by enabling x11vnc

2017-12-21 Thread Davis Roman

Hello,

 I'd like to put a vnc server on my target.

My embedded target has an onboard display and runs an application that
drives the display directly via the framebuffer. ( no xorg onboard )

I would like to use x11vnc ( with the --rawfb option ) however I'm
having a hard time justifying the load of dependencies that it brings
along with it. (Almost 100MB.)

With the --rawfb option, x11vnc does not require a X server ( just
libX11) to be onboard however I'm required to add x11 to
DISTRO_FEATURES otherwise x11vnc won't compile.

(x11vnc even drags gtk3 along with it which seems unnecessary.)

My goal is to only add the minimum number of x11vnc depencies.

Any advice on how to slim this down would be appreciated.

Thank you,

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

Re: [yocto] [meta-raspberrypi] linux kernel rt

2017-12-21 Thread Sherif Omran

hi Andreas,

so i need to integrate it now into my meta layer. Because i am using the
meta-raspberry pi.
To put it into my local meta-layer:
should i copy the recipies-kernel->linux-raspberrypi4.9 only
is there some other files i need to copy?

I will be working with audio/wlan/bluetooth, no need for other tools.
what should i add to the local.conf, is it the following only?

#PREFERRED_PROVIDER_virtual/kernel = "linux-raspberrypi"
#PREFERRED_VERSION_linux-raspberrypi ?= "4.9%"

Do we need to add something to the kernel configuration?

thank you

On Thu, Dec 21, 2017 at 9:59 PM, Andreas Müller 
wrote:

> On Thu, Dec 21, 2017 at 5:08 PM, Andrei Gherzan  wrote:
>
>> Hi all,
>>
>> On Thu, Dec 14, 2017 at 12:09 PM, Andreas Müller > > wrote:
>>
>>> On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak 
>>> wrote:
>>>
 2017-12-14 9:41 GMT+01:00 Andreas Müller :
 > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran <
 sherifomran2...@gmail.com>
 > wrote:
 >>
 >> hey guys,
 >>
 >> any body tried the real time kernel? I get an error, it is snot in
 the
 >> compatibility list.
 >> can we skip it?
 >>
 >> thanks
 >>
 >> --
 >
 > Good news: I use RT kernel only together with VC4 graphics and have
 lots of
 > fun on PI2/3.
 > Bad news: As far as I know it is not in meta-raspberrypi but in my
 fork [1].
 > There were attempts to land the RT-patches in meta-raspberrypi but
 that was
 > denied for huge patch size :(

 If the patch size was the only problem one can pull it by doing the
 following in the recipe:

 SRC_URI += " \
 https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patc
 h-4.9.65-rt56.patch.gz;name=rt-patch
 \
 "

 SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
 SRC_URI[rt-patch.sha256sum] =
 "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

 Note that above sums are "random" and not the for the actually file
 but are there for reference.

 That way you do not need to keep a copy of it in meta-raspberrypi.

 --

>>> Hi Mirza,
>>>
>>> Problem is that patches need alignments sometimes either caused by
>>> Raspberry-Pi-specific adjustments or versions not matching exactly - RT
>>> kernel patch updates are less frequent than kernel updates. Anyway: git is
>>> very good at maintaining huge text content and this should not be a problem
>>> these days. Another discussion about RT kernel was to have an extra kernel
>>> for it and I never understood why. To me that seems nothing but an extra
>>> maintenance burden.
>>>
>>> However - just wrote to Paul: I plan to be at FOSDEM and we can discuss
>>> there how to get back to one layer only (not mine!) making everybody happy
>>> :)
>>>
>>>
>> I remember the discussion. Indeed that was the reason and the
>> recommendation was to maintain a separate linux-raspberry fork where
>> whoever has interest in this will maintain on top of linux-raspberrypi this
>> patch. Obviously that didn't happen but I'd like to see it landing.
>>
>> Yes that was one of the suggestions which made me say 'Thanks - this is
> just additional maintenance burden and will not work for long time - I do
> my own'. FWIW: That suggestion came at a time when you (Andrei) seemed
> overworked totally (just to mention - PLEASE don't take it as criticism - I
> know what I am talking of when it comes to 'overworked').
>
> Why not simply one stable kernel with RT-patches applied if user decides
> by an option? That is what I am doing for >1 year now and meta-raspi-light
> is the one which caused me least efforts/headaches of all. And yes I know I
> made life easy here by removing userland completely and taking care for
> RPi2/3 only.
>
> Cheers,
>
> Andreas
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

41 matches

Mail list logo