[yocto] Icecc configuration on mpich ?

2017-07-27 Thread Riko Ho 

Dear Yocto Team Member,

I read about,

https://lists.yoctoproject.org/pipermail/yocto/2012-August/008757.html,

How can I port it to MPICH ?
Thanks
--
*

/***/
Sent by Ubuntu LTS 16.04,
Kind regards,
Riko Ho
/***/

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

Re: [yocto] Crosscompile packages (ipk) based on SDK

2017-07-27 Thread Josef Holzmayr 

On 27.07.2017 18:55, Manuel Geeler wrote:
I only got the standard SDK. Are the information I need for building my 
own yocto installation matching the target somewhere hidden in the SDK?


Nope, the standard SDK is actually only little more than a compiler 
toolchain plus sysroot. You have to ask whomever supplied the hardware 
to you for proper build instructions respectively sources.


Greetz
--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

[yocto] [meta-cgl][PATCH 3/3] ocfs2-tools: disable stack user support explicitly in init script

2017-07-27 Thread jackie.huang 
From: Jackie Huang 

Disable stack user support explicitly and only support
stack 'o2cb' in init script o2cb.

Signed-off-by: Kai Kang 
Signed-off-by: Jackie Huang 
---
 .../disable-ocfs2-stack-user-support.patch | 42 ++
 .../recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb   |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/disable-ocfs2-stack-user-support.patch

diff --git 
a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/disable-ocfs2-stack-user-support.patch
 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/disable-ocfs2-stack-user-support.patch
new file mode 100644
index 000..8d92f0c
--- /dev/null
+++ 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/disable-ocfs2-stack-user-support.patch
@@ -0,0 +1,42 @@
+Only support stack 'o2cb' in init script o2cb.
+
+Source file /etc/init.d/functions rather than /lib/lsb/init-functions which
+doesn't exist in wrlinux.  /etc/init.d/functions provides functions killproc
+and pidofproc, and doesn't provides function start_daemon. It doesn't matter
+that start_daemon is used by stack 'user' only.
+
+Upstream-Status: Pending
+
+Signed-off-by: Kai Kang 
+---
+diff --git a/vendor/common/o2cb.init.sh b/vendor/common/o2cb.init.sh
+index 2e73108..926e61e 100755
+--- a/vendor/common/o2cb.init.sh
 b/vendor/common/o2cb.init.sh
+@@ -18,11 +18,11 @@
+ # Force LC_ALL=C
+ export LC_ALL=C
+ 
+-# Let's try to use the LSB functions
+-. /lib/lsb/init-functions
++# Let's try to use the init scripts functions
++. /etc/init.d/functions
+ if [ $? != 0 ]
+ then
+-echo "Unable to load LSB init functions" >&2
++echo "Unable to load init scripts functions" >&2
+ exit 1
+ fi
+ 
+@@ -72,6 +72,11 @@ VERSION=@@VERSION@@
+ # Need this default
+ [ -z "$O2CB_STACK" ] && O2CB_STACK=o2cb
+ 
++if [ "$O2CB_STACK" != "o2cb" ]; then
++echo "Invalid cluster stack name \"$O2CB_STACK\""
++exit 1
++fi
++
+ configfs_path()
+ {
+ # Note that this is only valid *after* configfs is loaded
diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
index be9a505..6e5b1fd 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
@@ -14,6 +14,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
 SRC_URI = "git://oss.oracle.com/git/ocfs2-tools.git \
 file://0003-vendor-common-o2cb.ocf-add-new-conf-file.patch \
+file://disable-ocfs2-stack-user-support.patch \
 file://o2cb.service \
 file://ocfs2.service \
 "
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 2/3] ocfs2-tools: fix the installation and systemd services

2017-07-27 Thread jackie.huang 
From: Jackie Huang 

* use _append for do_install so that autotools_do_install
  will be run first.
* add -m for the install commands.
* add ${S} for install source files instead of relative path.
* remove cluster.conf.sample and use the sample conf file
  in source code instead.
* Disable systemd services by default since it won't
  work before the conf file is changed according to
  the actual network settings.
* Fix the services to use the correct helper scripts

Signed-off-by: Jackie Huang 
---
 .../ocfs2-tools/ocfs2-tools/cluster.conf.sample| 10 -
 .../ocfs2-tools/ocfs2-tools/o2cb.service   |  4 +-
 .../ocfs2-tools/ocfs2-tools/ocfs2.service  |  4 +-
 .../recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb   | 46 +-
 4 files changed, 31 insertions(+), 33 deletions(-)
 delete mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/cluster.conf.sample

diff --git 
a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/cluster.conf.sample 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/cluster.conf.sample
deleted file mode 100644
index d7252b5..000
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/cluster.conf.sample
+++ /dev/null
@@ -1,10 +0,0 @@
-node:
-   ip_port = 
-   ip_address = 192.168.246.100
-   number = 0
-   name = localhost.localdomain
-   cluster = ocfs2
-
-cluster:
-   node_count = 1
-   name = ocfs2
diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/o2cb.service 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/o2cb.service
index 520b530..c49b547 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/o2cb.service
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/o2cb.service
@@ -5,8 +5,8 @@ After=network.target
 [Service]
 Type=oneshot
 RemainAfterExit=yes
-ExecStart=/usr/lib/ocfs2-tools/o2cb-helper start
-ExecStop=/usr/lib/ocfs2-tools/o2cb-helper stop
+ExecStart=@LIBDIR@/o2cb-helper start
+ExecStop=@LIBDIR@/o2cb-helper stop
 
 [Install]
 WantedBy=multi-user.target
diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/ocfs2.service 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/ocfs2.service
index afcbbb9..d64da6c 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/ocfs2.service
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/ocfs2.service
@@ -6,8 +6,8 @@ After=network.target o2cb.service
 [Service]
 Type=oneshot
 RemainAfterExit=yes
-ExecStart=/bin/mount -at ocfs2
-ExecStop=/bin/umount -a -t ocfs2
+ExecStart=@LIBDIR@/ocfs2-helper start
+ExecStop=@LIBDIR@/ocfs2-helper stop
 
 [Install]
 WantedBy=multi-user.target
diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
index 3074525..be9a505 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
@@ -14,7 +14,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
 SRC_URI = "git://oss.oracle.com/git/ocfs2-tools.git \
 file://0003-vendor-common-o2cb.ocf-add-new-conf-file.patch \
-file://cluster.conf.sample \
 file://o2cb.service \
 file://ocfs2.service \
 "
@@ -62,32 +61,41 @@ do_compile_prepend() {
 }
 
 SYSTEMD_SERVICE_${PN} = "o2cb.service ocfs2.service"
+SYSTEMD_AUTO_ENABLE = "disable"
+
+do_install_append() {
+install -d ${D}${sysconfdir}/init.d
+install -m 0755 ${S}/vendor/common/o2cb.init ${D}${sysconfdir}/init.d/o2cb
+install -m 0755 ${S}/vendor/common/ocfs2.init 
${D}${sysconfdir}/init.d/ocfs2
+
+install -d ${D}${sysconfdir}/sysconfig
+install -m 0644 ${S}/vendor/common/o2cb.sysconfig 
${D}${sysconfdir}/sysconfig/o2cb
+
+install -d ${D}${sysconfdir}/udev/rules.d
+install -m 0644 ${S}/vendor/common/51-ocfs2.rules 
${D}${sysconfdir}/udev/rules.d/51-ocfs2.rules
 
-do_install() {
-install -d ${D}/etc/init.d
-install vendor/common/o2cb.init ${D}/etc/init.d/o2cb
-install vendor/common/ocfs2.init ${D}/etc/init.d/ocfs2
-install -d ${D}/etc/sysconfig
-install vendor/common/o2cb.sysconfig ${D}/etc/sysconfig/o2cb
-install -d ${D}/etc/udev/rules.d
-install vendor/common/51-ocfs2.rules ${D}/etc/udev/rules.d/51-ocfs2.rules
 install -d ${D}/${libdir}/ocf/resource.d/ocfs2
-install  -m 0755 vendor/common/o2cb.ocf 
${D}/${libdir}/ocf/resource.d/ocfs2/o2cb
-oe_runmake DESTDIR="${D}" install
+install  -m 0755 ${S}/vendor/common/o2cb.ocf 
${D}/${libdir}/ocf/resource.d/ocfs2/o2cb
 chmod 644 ${D}/${libdir}/*.a
-install -dm 0755  ${D}/etc/ocfs2
-install -m 0644 ${WORKDIR}/cluster.conf.sample 
${D}/etc/ocfs2/cluster.conf.sample
+
+install -dm 0755  ${D}${sysconfdir}/ocfs2
+install -m 0644 ${S}/documentation/samples/cluster.conf 
${D}${sysconfdir}/ocfs2/cluster.conf.sample
+
 rm -rf ${D}/${libdir}/ocf
 rm -rf

[yocto] [meta-cgl][PATCH 1/3] ocfs2-tools: fix dependencies

2017-07-27 Thread jackie.huang 
From: Jackie Huang 

* Remove the duplicated RDEPENDS_${PN}
* Add dependency on e2fsprogs-native to fix:
  | compile_et o2dlm_err.et
  | /bin/bash: compile_et: command not found

Signed-off-by: Jackie Huang 
---
 meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb 
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
index d6a24e5..3074525 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb
@@ -23,8 +23,11 @@ S = "${WORKDIR}/git"
 
 inherit autotools-brokensep pkgconfig systemd
 
-DEPENDS = "corosync openais cluster-glue pacemaker libxml2 linux-libc-headers 
e2fsprogs libaio"
-RDEPENDS_${PN} = "bash coreutils net-tools module-init-tools e2fsprogs 
chkconfig glib-2.0"
+DEPENDS = "corosync cluster-glue openais pacemaker \
+libxml2 linux-libc-headers libaio \
+e2fsprogs e2fsprogs-native \
+"
+
 ASNEEDED_pn-${PN} = ""
 PARALLEL_MAKE = ""
 INSANE_SKIP_${PN} = "unsafe-references-in-binaries"
@@ -88,4 +91,4 @@ do_install() {
 fi
 }
 
-RDEPENDS_${PN} = "bash"
+RDEPENDS_${PN} = "bash coreutils net-tools module-init-tools e2fsprogs 
chkconfig glib-2.0"
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 0/3] ocfs2-tools: several fixes

2017-07-27 Thread jackie.huang 
From: Jackie Huang 

---
The following changes since commit 0d22147d06626923f5e7b1dd5f02cb21ea7a3bcb:

  pacemaker: update to 1.1.16 (2017-06-20 10:28:35 +0200)

are available in the git repository at:

  https://github.com/jackiehjm/meta-cgl.git jhuang0/up_ocfs2-tools_170728_0
  https://github.com//tree/jhuang0/up_ocfs2-tools_170728_0

Jackie Huang (3):
  ocfs2-tools: fix dependencies
  ocfs2-tools: fix the installation and systemd services
  ocfs2-tools: disable stack user support explicitly in init script

 .../ocfs2-tools/ocfs2-tools/cluster.conf.sample| 10 
 .../disable-ocfs2-stack-user-support.patch | 42 
 .../ocfs2-tools/ocfs2-tools/o2cb.service   |  4 +-
 .../ocfs2-tools/ocfs2-tools/ocfs2.service  |  4 +-
 .../recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.4.bb   | 56 +-
 5 files changed, 80 insertions(+), 36 deletions(-)
 delete mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/cluster.conf.sample
 create mode 100644 
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools/disable-ocfs2-stack-user-support.patch

-- 
2.11.0

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

[yocto] [meta-security][PATCH 2/2] libmhash: add new recipe

2017-07-27 Thread jackie.huang 
From: Jackie Huang 

Mhash is a free (under GNU Lesser GPL) library which provides
a uniform interface to a large number of hash algorithms.
These algorithms can be used to compute checksums, message
digests, and other signatures.

Signed-off-by: Jackie Huang 
---
 recipes-security/libmhash/files/Makefile.test | 13 ++
 recipes-security/libmhash/files/mhash.c   | 32 +++
 recipes-security/libmhash/files/run-ptest | 12 +
 recipes-security/libmhash/libmhash_0.9.9.9.bb | 37 +++
 4 files changed, 94 insertions(+)
 create mode 100644 recipes-security/libmhash/files/Makefile.test
 create mode 100644 recipes-security/libmhash/files/mhash.c
 create mode 100644 recipes-security/libmhash/files/run-ptest
 create mode 100644 recipes-security/libmhash/libmhash_0.9.9.9.bb

diff --git a/recipes-security/libmhash/files/Makefile.test 
b/recipes-security/libmhash/files/Makefile.test
new file mode 100644
index 000..2e32626
--- /dev/null
+++ b/recipes-security/libmhash/files/Makefile.test
@@ -0,0 +1,13 @@
+#
+# Makefile for compiling mhash tests
+#
+
+ALL = mhash
+
+all: $(ALL)
+
+mhash: mhash.c
+   $(CC) $(CFLAGS) $(LDFLAGS) -o mhash mhash.c -lmhash
+
+clean:
+   rm -f *.debug $(ALL)
diff --git a/recipes-security/libmhash/files/mhash.c 
b/recipes-security/libmhash/files/mhash.c
new file mode 100644
index 000..5d123cc
--- /dev/null
+++ b/recipes-security/libmhash/files/mhash.c
@@ -0,0 +1,32 @@
+#include 
+#include 
+
+int main()
+{
+
+   char password[] = "Jefe";
+   int keylen = 4;
+   char data[] = "what do ya want for nothing?";
+   int datalen = 28;
+   MHASH td;
+   unsigned char mac[16];
+   int j;
+
+   td = mhash_hmac_init(MHASH_MD5, password, keylen, 
mhash_get_hash_pblock(MHASH_MD5));
+
+   mhash(td, data, datalen);
+   mhash_hmac_deinit(td, mac);
+
+/*
+ * The output should be 0x750c783e6ab0b503eaa86e310a5db738
+ * according to RFC 2104.
+ */
+
+   printf("0x");
+   for (j = 0; j < mhash_get_block_size(MHASH_MD5); j++) {
+   printf("%.2x", mac[j]);
+   }
+   printf("\n");
+
+   exit(0);
+}
diff --git a/recipes-security/libmhash/files/run-ptest 
b/recipes-security/libmhash/files/run-ptest
new file mode 100644
index 000..2b0b94a
--- /dev/null
+++ b/recipes-security/libmhash/files/run-ptest
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+OUTPUT=$($(dirname $0)/mhash)
+MHASH_MD5="0x750c783e6ab0b503eaa86e310a5db738"
+
+if [ x"$OUTPUT" = x"$MHASH_MD5" ]; then
+echo "PASS: mhash ptest"
+exit 0
+else
+echo "FAIL: mhash ptest"
+exit 1
+fi
diff --git a/recipes-security/libmhash/libmhash_0.9.9.9.bb 
b/recipes-security/libmhash/libmhash_0.9.9.9.bb
new file mode 100644
index 000..9b34cb1
--- /dev/null
+++ b/recipes-security/libmhash/libmhash_0.9.9.9.bb
@@ -0,0 +1,37 @@
+SUMMARY = "Library of hashing algorithms."
+DESCRIPTION = "\
+  Mhash is a free (under GNU Lesser GPL) library \
+  which provides a uniform interface to a large number of hash \
+  algorithms. These algorithms can be used to compute checksums, \
+  message digests, and other signatures. \
+  "
+HOMEPAGE = "http://mhash.sourceforge.net/;
+
+LICENSE = "LGPLv2.0"
+LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
+
+S = "${WORKDIR}/mhash-${PV}"
+
+SECTION = "libs"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/mhash/mhash-${PV}.tar.bz2 \
+file://Makefile.test \
+file://mhash.c \
+file://run-ptest \
+"
+
+SRC_URI[md5sum] = "f91c74f9ccab2b574a98be5bc31eb280"
+SRC_URI[sha256sum] = 
"56521c52a9033779154432d0ae47ad7198914785265e1f570cee21ab248dfef0"
+
+inherit autotools-brokensep ptest
+
+do_compile_ptest() {
+if [ ! -d ${S}/demo ]; then mkdir ${S}/demo; fi
+cp ${WORKDIR}/Makefile.test ${S}/demo/Makefile
+cp ${WORKDIR}/mhash.c ${S}/demo/
+make -C ${S}/demo CFLAGS="${CFLAGS} -I${S}/include/" LDFLAGS="${LDFLAGS} 
-L${S}/lib/.libs"
+}
+
+do_install_ptest() {
+install -m 0755 ${S}/demo/mhash ${D}${PTEST_PATH}
+}
-- 
2.11.0

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

[yocto] [meta-security][PATCH 1/2] libgssglue: add new recipe

2017-07-27 Thread jackie.huang 
From: Jackie Huang 

libgssglue exports a gssapi interface which calls
other gssapi libraries.

Signed-off-by: Jackie Huang 
---
 .../libgssglue/files/libgssglue-canon-name.patch   | 60 ++
 .../files/libgssglue-fix-CVE-2011-2709.patch   | 43 
 .../libgssglue/files/libgssglue-g-initialize.patch | 21 
 .../libgssglue/files/libgssglue-gss-inq-cred.patch | 27 ++
 .../libgssglue/files/libgssglue-mglueP.patch   | 21 
 recipes-security/libgssglue/libgssglue_0.4.bb  | 51 ++
 6 files changed, 223 insertions(+)
 create mode 100644 
recipes-security/libgssglue/files/libgssglue-canon-name.patch
 create mode 100644 
recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch
 create mode 100644 
recipes-security/libgssglue/files/libgssglue-g-initialize.patch
 create mode 100644 
recipes-security/libgssglue/files/libgssglue-gss-inq-cred.patch
 create mode 100644 recipes-security/libgssglue/files/libgssglue-mglueP.patch
 create mode 100644 recipes-security/libgssglue/libgssglue_0.4.bb

diff --git a/recipes-security/libgssglue/files/libgssglue-canon-name.patch 
b/recipes-security/libgssglue/files/libgssglue-canon-name.patch
new file mode 100644
index 000..cb7c47b
--- /dev/null
+++ b/recipes-security/libgssglue/files/libgssglue-canon-name.patch
@@ -0,0 +1,60 @@
+fix the bug:
+g_canon_name.c:125:5: warning: passing argument 2 of '__gss_copy_namebuf' from 
incompatible pointer type [enabled by default]
+
+the 2nd argument of __gss_copy_namebuf should be address of *gss_buffer_t, \
+but a *gss_buffer_t is assigned.
+
+what __gss_copy_namebuf does is to alloc memory for a gss_buffer_desc and \
+copy from src and return its address.
+
+if following code failed, gss_release_name will free \
+union_canon_name->external_name.value if it is not NULL.
+
+OM_uint32 __gss_copy_namebuf(src, dest)
+gss_buffer_t   src;
+gss_buffer_t   *dest;
+
+typedef struct gss_union_name_t {
+   gss_mechanism   gss_mech;
+   gss_OID name_type;
+   gss_buffer_desc external_name;
+   /*
+* These last two fields are only filled in for mechanism
+* names.
+*/
+   gss_OID mech_type;
+   gss_name_t  mech_name;
+} gss_union_name_desc, *gss_union_name_t;
+
+typedef struct gss_buffer_desc_struct {
+  size_t length;
+  void FAR *value;
+} gss_buffer_desc, FAR *gss_buffer_t;
+
+Upstream-Status: Pending
+Signed-off-by: Yao Zhao 
+
+--- a/src/g_canon_name.c
 b/src/g_canon_name.c
+@@ -121,11 +121,17 @@ gss_canonicalize_name (OM_uint32 *minor_
+ 
+ union_canon_name->mech_name = mech_name;
+ 
+-status = __gss_copy_namebuf(_input_name->external_name,
+-  _canon_name->external_name);
+-if (status != GSS_S_COMPLETE)
+-  goto failure;
++union_canon_name->external_name.value = (void*) malloc(
++  union_input_name->external_name.length + 1);
++if (!union_canon_name->external_name.value)
++goto failure;
+ 
++memcpy(union_canon_name->external_name.value, 
++   union_input_name->external_name.value, 
++   union_input_name->external_name.length);
++union_canon_name->external_name.length = 
++  union_input_name->external_name.length; 
++   
+ if (union_input_name->name_type != GSS_C_NO_OID) {
+   status = generic_gss_copy_oid(minor_status,
+ union_input_name->name_type,
diff --git 
a/recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch 
b/recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch
new file mode 100644
index 000..6aa1a65
--- /dev/null
+++ b/recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch
@@ -0,0 +1,43 @@
+Use secure_getenv instead of getenv for setuid programs
+
+(bnc#694598 CVE-2011-2709 bnc#831805)
+
+import from:
+https://build.opensuse.org/package/view_file/openSUSE:Factory/libgssglue/secure-getenv.patch
+
+Upstream-Status: Pending
+
+Signed-off-by: Jackie Huang 
+
+diff --git a/src/g_initialize.c b/src/g_initialize.c
+index 200f173..935a9fa 100644
+--- a/src/g_initialize.c
 b/src/g_initialize.c
+@@ -26,6 +26,7 @@
+  * This function will initialize the gssapi mechglue library
+  */
+ 
++#define _GNU_SOURCE
+ #include "mglueP.h"
+ #include 
+ 
+@@ -197,8 +198,7 @@ static void solaris_initialize ()
+ void *dl;
+ gss_mechanism (*sym)(void), mech;
+ 
+-if ((getuid() != geteuid()) ||
+-((filename = getenv("GSSAPI_MECH_CONF")) == NULL))
++if ((filename = secure_getenv("GSSAPI_MECH_CONF")) == NULL)
+   filename = MECH_CONF;
+ 
+ if ((conffile = fopen(filename, "r")) == NULL) {
+@@ -274,8 +274,7 @@ static void linux_initialize ()
+ void *dl;
+ gss_mechanism (*sym)(void), mech;

[yocto] [meta-security][PATCH 0/2] libmhash and libgssglue: add new recipe

2017-07-27 Thread jackie.huang 
From: Jackie Huang 

---
The following changes since commit 89683b4fee4616a08d249bc7afd7be55f3fa71a3:

  apparmor: fix python packaging issue (2017-06-01 08:01:34 -0700)

are available in the git repository at:

  https://github.com/jackiehjm/meta-security.git 
jhuang0/r_up_libmhash_libgssglue_170728_1
  https://github.com//tree/jhuang0/r_up_libmhash_libgssglue_170728_1

Jackie Huang (2):
  libgssglue: add new recipe
  libmhash: add new recipe

 .../libgssglue/files/libgssglue-canon-name.patch   | 60 ++
 .../files/libgssglue-fix-CVE-2011-2709.patch   | 43 
 .../libgssglue/files/libgssglue-g-initialize.patch | 21 
 .../libgssglue/files/libgssglue-gss-inq-cred.patch | 27 ++
 .../libgssglue/files/libgssglue-mglueP.patch   | 21 
 recipes-security/libgssglue/libgssglue_0.4.bb  | 51 ++
 recipes-security/libmhash/files/Makefile.test  | 13 +
 recipes-security/libmhash/files/mhash.c| 32 
 recipes-security/libmhash/files/run-ptest  | 12 +
 recipes-security/libmhash/libmhash_0.9.9.9.bb  | 37 +
 10 files changed, 317 insertions(+)
 create mode 100644 
recipes-security/libgssglue/files/libgssglue-canon-name.patch
 create mode 100644 
recipes-security/libgssglue/files/libgssglue-fix-CVE-2011-2709.patch
 create mode 100644 
recipes-security/libgssglue/files/libgssglue-g-initialize.patch
 create mode 100644 
recipes-security/libgssglue/files/libgssglue-gss-inq-cred.patch
 create mode 100644 recipes-security/libgssglue/files/libgssglue-mglueP.patch
 create mode 100644 recipes-security/libgssglue/libgssglue_0.4.bb
 create mode 100644 recipes-security/libmhash/files/Makefile.test
 create mode 100644 recipes-security/libmhash/files/mhash.c
 create mode 100644 recipes-security/libmhash/files/run-ptest
 create mode 100644 recipes-security/libmhash/libmhash_0.9.9.9.bb

-- 
2.11.0

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

Re: [yocto] Mpich and yocto ?

2017-07-27 Thread Riko Ho 

Dear Yocto Team Member,

I tried to compile icecream on the master node, but here's the messages 
I got, any ideas ?


=

Making install in services
make[1]: Entering directory '/home/bianchi77/icecream/services'
make[2]: Entering directory '/home/bianchi77/icecream/services'
 /bin/mkdir -p '/usr/local/lib'
 /bin/bash ../libtool   --mode=install /usr/bin/install -c libicecc.la 
'/usr/local/lib'
libtool: install: /usr/bin/install -c .libs/libicecc.lai 
/usr/local/lib/libicecc.la
/usr/bin/install: cannot create regular file 
'/usr/local/lib/libicecc.la': Permission denied

Makefile:428: recipe for target 'install-libLTLIBRARIES' failed
make[2]: *** [install-libLTLIBRARIES] Error 1
make[2]: Leaving directory '/home/bianchi77/icecream/services'
Makefile:721: recipe for target 'install-am' failed
make[1]: *** [install-am] Error 2
make[1]: Leaving directory '/home/bianchi77/icecream/services'
Makefile:421: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1

==

Thanks


On 27/07/17 09:10, Randy MacLeod wrote:

On 2017-07-26 08:08 PM, Riko Ho wrote:

Dear Yocto Team Member,

The cluster is using Ubuntu.
I haven't checked all the packages on the other computer. I will.

My goal is getting more hardrive space and compiling speed.

How can I relate bitbake with mpicc or other compilers needed by 
yocto (arm-linux-gcc, gcc, etc)?


Do you mean that you want to do part of the build using each node in 
the cluster? That's possible now using distcc/icecream

(https://github.com/icecc/icecream ) but I haven't done it in years
as explained below.

Oh, there's a Stack Overflow entry for YP+distcc/icecream:

https://stackoverflow.com/questions/14472175/distributed-compile-with-bitbake 



and distcc is mentioned in the docs:
   http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html


Anyway, this just distributes the compilation so:
 - build management,
 - recipe download, unpack, patch, configuring and packaging,
 - linking, etc
are still done centrally.

There are plans to improve the bitbake task manager so that, with
the recipe specific sysroot work that has been done in 2.2, we'd be
able to farm out all of the stages of a package's build to individual
nodes in a cluster:
   https://bugzilla.yoctoproject.org/show_bug.cgi?id=10684
I don't know if that work is a priority for the fall 2.4 release.

Note that depending on your workload, inter-recipe dependencies and
the long time taken to run configure for autotools-based packages is
the bottleneck. Therefore, buying a high-end ( >= 16+16 core )
system with lots (64GB+) RAM and a good IO sub-system results
in core-image-minimal building quickly, certainly under 40 minutes.
   https://wiki.yoctoproject.org/wiki/Build_Performance

Also for repeated builds by one or more developers, sstate-cache is
a huge speed-up with some cost in scripts and people to manage it.


I've wondered if anyone has played with bitbake on an OS that is
known as a single-system image:
   https://en.wikipedia.org/wiki/Single_system_image
On these systems, jobs are transparently moved from the master-node
to idle nodes in the cluster by the operating system. That would be
an interesting academic exercise but it wouldn't be useful in
practice since such OSs are not generally used as far as I know at
least.

I look forward to hearing what your goals and plans are.

../Randy




I have tested a small code with mpicc and the cluster do the job.

Thanks for the attention.

On Jul 27, 2017 3:23 AM, "Randy MacLeod" > wrote:

 >
 > On 2017-07-26 02:09 AM, Riko Ho wrote:
 >>
 >> How can we do that ?
 >>
 >> bitbake in which node ? I don't understand ?
 >>
 >>
 >> On 26/07/17 13:57, Josef Holzmayr wrote:
 >>>
 >>> Hi
 >>>
 >>> On 26.07.2017 05:12, Riko Ho wrote:
 
  Does anyone know on how to run poky on mpich cluster ?
 >
 >
 > That's a rather ambiguous question.
 >
 > What OS/Distro is the mpich cluster running?
 > Have you installed the packages that are required on the host:
 >see: "The Build Host Packages" here:
 >
 > 
http://www.yoctoproject.org/docs/2.3/yocto-project-qs/yocto-project-qs.html

 >
 > What do you hope to achieve using bitbake?
 >
 >
 >>>
 >>> As far as I can see, MPICH is a userland library, basically. So 
it would be the other way round, you could probably run a mpich 
application on a number of nodes that run some OE/Poky thing.

 >>>
 >>> Greetz
 >
 >
 > There is an mpich recipe here:
 > http://layers.openembedded.org/layerindex/recipe/33348/
 >
 > but again, it's not clear what your ultimate goal is.
 >
 > ../Randy
 >
 >>
 >> --
 >> *
 >>
 >>
 >> /***/
 >> Sent by Ubuntu LTS 16.04,
 >> Kind regards,
 >> Riko Ho
 >> /***/
 >>
 >> *
 >>
 >>
 >
 >
 > --
 > # Randy MacLeod. SMTS, Linux, Wind River
 > Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5







--
*

/***/
Sent by Ubuntu LTS 16.04,
Kind regards,
Riko Ho

Re: [linux-yocto] [PATCH 2/3][kernel-cache] common-pc-64: Adds usb-net configs to genericx86-64 builds

2017-07-27 Thread Alejandro Hernandez 


On 07/27/2017 12:02 PM, Bruce Ashfield wrote:

On 07/26/2017 06:21 PM, Alejandro Hernandez wrote:

Hey Bruce,

So I completely agree with you, and I think we should keep them 
modules/kernel size as small as we can,


but I just had a meeting with the QA team and discussed this, it does 
look like it'd be necessary to have those


modules built for everyone, since they are not building images 
specifically for QA, they take their images straight


from the public Autobuilder.


The meta-intel images would be unaffected anyway, since they already 
include these modules via another scc,


but after chatting with Saul, we agreed we wanted them anyway, in 
case something changes on the other scc.



I can live with that.

The next question is ... what kernel versions ? 4.9, 4.10, master (aka 
linux-yocto-dev) ?


Bruce


At least on master (4.10), they say that eventually they'd like to 
extend their testing to pyro and morty, but I suppose 4.10 for now, and 
if required we can backport it.





Alejandro



On 07/25/2017 08:45 AM, Bruce Ashfield wrote:

No real objections to the series, but it will of course increase the
amount of modules/kernel size out of the box. I'm continually
balancing the built-in convenience versus the size of the kernel
and need to always ask the following question:

This sort of thing can be added via KERNEL_FEATURES when a QA build
is being done.

I assume that route was considered and rejected ?

Bruce

On 2017-07-24 2:58 PM, Alejandro Hernandez wrote:

QA needs USB OTG to automate some of the testing processes,
this patch adds it to genericx86-64 builds

[YOCTO #11740]

Signed-off-by: Alejandro Hernandez 


---
  bsp/common-pc-64/common-pc-64.scc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/bsp/common-pc-64/common-pc-64.scc 
b/bsp/common-pc-64/common-pc-64.scc

index 6ceee53e..d9d41c1c 100644
--- a/bsp/common-pc-64/common-pc-64.scc
+++ b/bsp/common-pc-64/common-pc-64.scc
@@ -17,6 +17,7 @@ include features/usb/uhci-hcd.scc
  include features/usb/ohci-hcd.scc
  include features/usb/xhci-hcd.scc
  include features/usb/touchscreen-composite.scc
+include features/usb-net/usb-net.scc
  include features/intel-e1/intel-e100.scc
  include features/intel-e1/intel-e1.scc
  include features/scsi/cdrom.scc









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

Re: [linux-yocto] [kernel-cache][PATCH] leafhill: update branch for leafhill

2017-07-27 Thread Bruce Ashfield 

On 07/26/2017 12:13 PM, chong.yi.c...@intel.com wrote:

From: Chong Yi Chai 

Update branch to standard/intel/base for kernel 4.1.42 upgrade.



merged. Update your SRCREV to pull in the change.

Bruce



Signed-off-by: Chong Yi Chai 
---
  bsp/leafhill/leafhill-standard.scc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsp/leafhill/leafhill-standard.scc 
b/bsp/leafhill/leafhill-standard.scc
index 8318a57..0fa1b53 100644
--- a/bsp/leafhill/leafhill-standard.scc
+++ b/bsp/leafhill/leafhill-standard.scc
@@ -10,4 +10,4 @@ define KTYPE standard
  include ktypes/standard/standard.scc
  include leafhill.scc
  
-branch intel/4.1.27/leaf-hill

+branch intel/base



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

Re: [linux-yocto] v4.8.x - stable updates comprising v4.8.25

2017-07-27 Thread Bruce Ashfield 

On 07/24/2017 04:05 AM, Paul Gortmaker wrote:

Bruce, Yocto kernel folks:

Here is another 4.8.x stable update.  Continuing on top of the
previously released v4.8.24 kernel, we now have the appropriate content
from 4.9.22 to 4.9.24 (inclusive) applied on top of our latest 4.8
baseline.  Once again, I've combined several 4.9.x which results in
just under 200 backported commits out of that original 4.9.x range.

Of note, it includes the stack/heap CVE fixes backported from the
4.9.x stable release which were outside of the above range, but they
seemed worthy of jumping ahead in the 4.9.x queue that remains.

As usual, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with yocto .config and toolchains
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.24 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.


Thanks Paul.

This is now merged to the linux-yocto 4.8 repo.

Bruce



Paul.
--



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

Re: [linux-yocto] [PATCH 2/3][kernel-cache] common-pc-64: Adds usb-net configs to genericx86-64 builds

2017-07-27 Thread Bruce Ashfield 

On 07/26/2017 06:21 PM, Alejandro Hernandez wrote:

Hey Bruce,

So I completely agree with you, and I think we should keep them 
modules/kernel size as small as we can,


but I just had a meeting with the QA team and discussed this, it does 
look like it'd be necessary to have those


modules built for everyone, since they are not building images 
specifically for QA, they take their images straight


from the public Autobuilder.


The meta-intel images would be unaffected anyway, since they already 
include these modules via another scc,


but after chatting with Saul, we agreed we wanted them anyway, in case 
something changes on the other scc.



I can live with that.

The next question is ... what kernel versions ? 4.9, 4.10, master (aka 
linux-yocto-dev) ?


Bruce




Alejandro



On 07/25/2017 08:45 AM, Bruce Ashfield wrote:

No real objections to the series, but it will of course increase the
amount of modules/kernel size out of the box. I'm continually
balancing the built-in convenience versus the size of the kernel
and need to always ask the following question:

This sort of thing can be added via KERNEL_FEATURES when a QA build
is being done.

I assume that route was considered and rejected ?

Bruce

On 2017-07-24 2:58 PM, Alejandro Hernandez wrote:

QA needs USB OTG to automate some of the testing processes,
this patch adds it to genericx86-64 builds

[YOCTO #11740]

Signed-off-by: Alejandro Hernandez 
---
  bsp/common-pc-64/common-pc-64.scc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/bsp/common-pc-64/common-pc-64.scc 
b/bsp/common-pc-64/common-pc-64.scc

index 6ceee53e..d9d41c1c 100644
--- a/bsp/common-pc-64/common-pc-64.scc
+++ b/bsp/common-pc-64/common-pc-64.scc
@@ -17,6 +17,7 @@ include features/usb/uhci-hcd.scc
  include features/usb/ohci-hcd.scc
  include features/usb/xhci-hcd.scc
  include features/usb/touchscreen-composite.scc
+include features/usb-net/usb-net.scc
  include features/intel-e1/intel-e100.scc
  include features/intel-e1/intel-e1.scc
  include features/scsi/cdrom.scc







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

[yocto] Understanding dtb generation wrt uboot (with signing)

2017-07-27 Thread colin.helliwell 
I'm working on 2.2/Morty, with a custom board.
Ultimate goal is to create a FIT image with a signed configuration. But I'm
trying to just work through step by step and understand the relationships
between u-boot, kernel, dtb, and the fit image - would appreciate any
guidance!
So far, I've built and booted a fitImage. 

It seems, however, that I need to program my modified dtb into the Flash
(i.MX6 cpu) - if I program in the manufacturer's default then the kernel
doesn't get my modified one. May be a problem for another time - I can
program mine into Flash if need be.

First thing I'm puzzled by is that the dtb *is* in
tmp/deploy/images/mymachine/ , but is called
"zImage--4.4-r0-mymachine-20170727160613.dtb". Also with a symlink
"zImage-mymachine.dtb".  (If I'm understanding things right, this is because
the fitImage contains a compressed kernel...?)

Then I set UBOOT_SIGN_ENABLE = "1", and re-bitbake the u-boot target. It
only gets as far as re-building the kernel, which fails on the
do_assemble_fitimage  stage because uboot-mkimage  is being told to use
"u-boot.dtb"

So I'm unsure what setting(s) I need to tweak to pull things into line. Why
'zImage... .dtb' being built yet 'u-boot.dtb' being looked for?



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

[yocto] [yocto-autobuilder][PATCH] buildset-config/nightly-refkit: add modify bblayers step

2017-07-27 Thread Stephano Cetola 
Add the new modification step, and remove the second buildimages
test. The second buildimages test aims to change the distro to
"nodistro" and rerun the build. In order to do that we'll need to add
some functionality. For now, we will simply do one buildimage step
until the second step has been flushed out.

Signed-off-by: Stephano Cetola 
---
 buildset-config.controller/nightly-refkit.conf | 53 +-
 1 file changed, 1 insertion(+), 52 deletions(-)

diff --git a/buildset-config.controller/nightly-refkit.conf 
b/buildset-config.controller/nightly-refkit.conf
index 1d2487da6..eb120eded 100644
--- a/buildset-config.controller/nightly-refkit.conf
+++ b/buildset-config.controller/nightly-refkit.conf
@@ -18,29 +18,7 @@ steps: [{'SetDest':{}},
 'prserv': False, 'nosstate': True,
 'SDKMACHINE' : 'x86_64',
 'atextappend': '\nrequire 
conf/distro/include/refkit-ci.inc\n'}},
-{'CreateBBLayersConf': {'buildprovider' : 'oe',
-'layerdirs': ['refkit/meta-intel',
-  'refkit/meta-refkit',
-  'meta-selftest',
-  'refkit/meta-refkit-gateway',
-  
'refkit/meta-refkit-computervision',
-  'refkit/meta-oic',
-  'refkit/meta-iot-web',
-  'refkit/meta-iotqa',
-  'refkit/meta-security',
-  'refkit/meta-security-isafw',
-  'refkit/meta-intel-realsense',
-  'refkit/meta-clang',
-  'refkit/meta-flatpak',
-  'refkit/meta-refkit-industrial',
-  'refkit/meta-ros',
-  
'refkit/meta-openembedded/meta-filesystems',
-  
'refkit/meta-openembedded/meta-gnome',
-  
'refkit/meta-openembedded/meta-networking',
-  
'refkit/meta-openembedded/meta-oe',
-  
'refkit/meta-openembedded/meta-perl',
-  
'refkit/meta-openembedded/meta-python',
-  'refkit/meta-refkit-core']}},
+{'ModBBLayersConf': {}},
 {'ScrapeTargets': {'source': 
'refkit/meta-refkit/conf/distro/include/refkit-ci.inc',
'targetsvar': 'REFKIT_CI_BUILD_TARGETS'}},
 {'BuildImages': {'images': '#SCRAPEDTARGETS',
@@ -50,35 +28,6 @@ steps: [{'SetDest':{}},
'targetsvar': 'REFKIT_CI_POSTBUILD_SELFTESTS'}},
 {'RunOeSelftest': {'tests': '#SCRAPEDTARGETS'}},
 {'RemoveTmpFiles': {'files': 'build/conf'}},
-{'RunPreamble': {}},
-{'CreateAutoConf': {'machine': 'qemux86-64', 'packages': 'ipk',
-'distro': 'poky', 'buildhistory' : False,
-'prserv': False, 'nosstate': True,
-'SDKMACHINE' : 'x86_64', 'tmpdir': 'tmp-poky'}},
-{'CreateBBLayersConf': {'buildprovider' : 'yocto',
-'layerdirs': ['refkit/meta-intel',
-  'meta-selftest',
-  'refkit/meta-refkit',
-  'refkit/meta-refkit-gateway',
-  
'refkit/meta-refkit-computervision',
-  'refkit/meta-oic',
-  'refkit/meta-iot-web',
-  'refkit/meta-iotqa',
-  'refkit/meta-security',
-  'refkit/meta-security-isafw',
-  'refkit/meta-intel-realsense',
-  'refkit/meta-clang',
-  'refkit/meta-flatpak',
-  'refkit/meta-refkit-industrial',
-  'refkit/meta-ros',
-  
'refkit/meta-openembedded/meta-filesystems',
-  
'refkit/meta-openembedded/meta-gnome',
-  
'refkit/meta-openembedded/meta-networking',
-

[yocto] [yocto-autobuilder][PATCH] buildsteps: add bblayers modification step

2017-07-27 Thread Stephano Cetola 
This step is currently only applicable to refkit. It allows us to
replace oe-core and oe-selftest layers in their bblayers.conf with
those layers that we are currently testing.

In the future, we may be able to improve this to replace layer "x"
with layer "y" dynamically, however that presents several challenges
outside the scope of this work.

[YOCTO #11745 ]

Signed-off-by: Stephano Cetola 
---
 .../autobuilder/buildsteps/ModBBLayersConf.py  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/ModBBLayersConf.py

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/ModBBLayersConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/ModBBLayersConf.py
new file mode 100644
index 0..513e8a15a
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/ModBBLayersConf.py
@@ -0,0 +1,35 @@
+'''
+Created on July 24, 2017
+
+__author__ = "Stephano Cetola"
+__copyright__ = "Copyright 2017, Intel Corp."
+__credits__ = ["Stephano Cetola"]
+__license__ = "GPL"
+__version__ = "2.0"
+__maintainer__ = "Stephano Cetola"
+__email__ = "stephano.cet...@linux.intel.com"
+'''
+
+from buildbot.steps.shell import ShellCommand
+from twisted.python import log
+
+class ModBBLayersConf(ShellCommand):
+haltOnFailure = True
+flunkOnFailure = True
+name = "Modify BBLayers Configuration"
+def __init__(self, factory, argdict=None, **kwargs):
+self.factory = factory
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+self.description = "Modify BBLayers Configuration"
+ShellCommand.__init__(self, **kwargs)
+
+def start(self):
+workdir = self.getProperty("workdir")
+bblayers = "%s/build/build/conf/bblayers.conf" % workdir
+yoctodir = "%s/build/meta " % workdir 
+selftestdir = "%s/build/meta-selftest " % workdir
+cmd1 = "sed -i 's|.*openembedded-core/meta .*|%s|' %s" % (yoctodir, 
bblayers)
+cmd2 = "sed -i 's|.*openembedded-core/meta-selftest.*|%s|' %s" % 
(selftestdir, bblayers)
+self.command = "%s;%s" % (cmd1, cmd2)
+ShellCommand.start(self)
-- 
2.13.3

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

Re: [yocto] Crosscompile packages (ipk) based on SDK

2017-07-27 Thread Khem Raj 
On Thu, Jul 27, 2017 at 9:05 AM, Manuel Geeler  wrote:
> Hello Raj,
>
> thank you for your input. This solves the problem of bringing the packages
> to the target once I havt the packages. But I'm still challenged with how to
> create the packages in the first place.
>
> Do I need to have my own yocto installation to setup along the SDK? Will
> such a setup be able to build me *ipk packages without knowing the original
> settings for the image in the first place? Are the information to build the
> buildsystem somwhere hidden in the SDK?

if you are using extensible SDK then it should be able to build ipks. You might
have to ask the SDK provider on that. Otherwise you will need full yocto build
system to generate ipks is the easiest way.

>
> Thank you
>
> Manuel
>
> Khem Raj  hat am 27. Juli 2017 um 17:57 geschrieben:
>
> On Thu, Jul 27, 2017 at 7:43 AM, Manuel Geeler  wrote:
>
> Hello community,
>
> I got an image and the corresponding SDK for a hardware based on an iMX6
> processor. With this setup I was able to crosscompile a simple "Hello World"
> program on the development machine (Ubuntu 16.04.2 LTS), install and run it
> on the target.
>
> I then started to look deeper into yocto and realized that there's the opkg
> package manager available in the image.
>
> Now comes my question, how can I build *.ipk packages on my development
> machine, which will then run on my target?
>
> yes you can. you can setup a feedserver pointing to tmp/deploy/ipk in
> your workspace
>
> something as simple as cd tmp/deploy/ipk && python3 -m http.server 8000
>
> will do it. Once you have it then setup the feed on your device to
> point to this server
> something like
>
> https://github.com/cbrake/oe-build/blob/master/envsetup.sh#L480-L489
>
> then you can do normal opkg operations
>
> if you are able to rebuild the whole image then step to edit feed
> confs is not needed
> you can add
>
> PACKAGE_FEED_URIS = "http://:/" in local.conf
>
> where ip is the local address of your build machine and port is the
> port on which you
> are starting the http server.
>
>>
>
> The image is based on poky 2.1.
>
> My endgoal is to run node.js and node red on the target.
>
> Can someone please point me to the right direction?
>
> Thanks a lot in advance.
>
> regards
>
> Manuel
>
> Manuel Geeler
> Technischer Leiter
>
> Identech AG
> Lagerstrasse 14, CH-8600 Dübendorf
> Tel.: +41 (0) 44 885 22 26
> Mobil: +41 (0) 76 323 65 44
> gee...@identech.ch
> www.identech.ch
>
> --
>
> ___
> 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] Crosscompile packages (ipk) based on SDK

2017-07-27 Thread Manuel Geeler 
Hello Raj, 

thank you for your input. This solves the problem of bringing the packages to 
the target once I havt the packages. But I'm still challenged with how to 
create the packages in the first place. 

Do I need to have my own yocto installation to setup along the SDK? Will such a 
setup be able to build me *ipk packages without knowing the original settings 
for the image in the first place? Are the information to build the buildsystem 
somwhere hidden in the SDK? 

Thank you 

Manuel

> 
> Khem Raj  hat am 27. Juli 2017 um 17:57 geschrieben:
> 
> On Thu, Jul 27, 2017 at 7:43 AM, Manuel Geeler  wrote:
> 
> > > 
> > Hello community,
> > 
> > I got an image and the corresponding SDK for a hardware based on an 
> > iMX6
> > processor. With this setup I was able to crosscompile a simple 
> > "Hello World"
> > program on the development machine (Ubuntu 16.04.2 LTS), install 
> > and run it
> > on the target.
> > 
> > I then started to look deeper into yocto and realized that there's 
> > the opkg
> > package manager available in the image.
> > 
> > Now comes my question, how can I build *.ipk packages on my 
> > development
> > machine, which will then run on my target?
> > 
> > > 
> yes you can. you can setup a feedserver pointing to tmp/deploy/ipk in
> your workspace
> 
> something as simple as cd tmp/deploy/ipk && python3 -m http.server 8000
> 
> will do it. Once you have it then setup the feed on your device to
> point to this server
> something like
> 
> https://github.com/cbrake/oe-build/blob/master/envsetup.sh#L480-L489
> 
> then you can do normal opkg operations
> 
> if you are able to rebuild the whole image then step to edit feed
> confs is not needed
> you can add
> 
> PACKAGE_FEED_URIS = "http://:/" in local.conf
> 
> where ip is the local address of your build machine and port is the
> port on which you
> are starting the http server.
> 
> >
> 
> > > 
> > The image is based on poky 2.1.
> > 
> > My endgoal is to run node.js and node red on the target.
> > 
> > Can someone please point me to the right direction?
> > 
> > Thanks a lot in advance.
> > 
> > regards
> > 
> > Manuel
> > 
> > Manuel Geeler
> > Technischer Leiter
> > 
> > Identech AG
> > Lagerstrasse 14, CH-8600 Dübendorf
> > Tel.: +41 (0) 44 885 22 26
> > Mobil: +41 (0) 76 323 65 44
> > gee...@identech.ch
> > www.identech.ch
> > 
> > --
> > 
> > ___
> > 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] Crosscompile packages (ipk) based on SDK

2017-07-27 Thread Khem Raj 
On Thu, Jul 27, 2017 at 7:43 AM, Manuel Geeler  wrote:
> Hello community,
>
> I got an image and the corresponding SDK for a hardware based on an iMX6
> processor. With this setup I was able to crosscompile a simple "Hello World"
> program on the development machine (Ubuntu 16.04.2 LTS), install and run it
> on the target.
>
> I then started to look deeper into yocto and realized that there's the opkg
> package manager available in the image.
>
> Now comes my question, how can I build *.ipk packages on my development
> machine, which will then run on my target?

yes you can. you can setup a feedserver pointing to tmp/deploy/ipk in
your workspace

something as simple as cd tmp/deploy/ipk && python3 -m http.server 8000

will do it. Once you have it then setup the feed on your device to
point to this server
something like

https://github.com/cbrake/oe-build/blob/master/envsetup.sh#L480-L489

then you can do normal opkg operations

if you are able to rebuild the whole image then step to edit feed
confs is not needed
you can add

PACKAGE_FEED_URIS = "http://:/" in local.conf

where ip is the local address of your build machine and port is the
port on which you
are starting the http server.

>
> The image is based on poky 2.1.
>
> My endgoal is to run node.js and node red on the target.
>
> Can someone please point me to the right direction?
>
> Thanks a lot in advance.
>
> regards
>
> Manuel
>
> Manuel Geeler
> Technischer Leiter
>
> Identech AG
> Lagerstrasse 14, CH-8600 Dübendorf
> Tel.: +41 (0) 44 885 22 26
> Mobil: +41 (0) 76 323 65 44
> gee...@identech.ch
> www.identech.ch
>
>
> --
> ___
> 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] Crosscompile packages (ipk) based on SDK

2017-07-27 Thread Manuel Geeler 
Hello community, 

I got an image and the corresponding SDK for a hardware based on an iMX6 
processor. With this setup I was able to crosscompile a simple "Hello World" 
program on the development machine (Ubuntu 16.04.2 LTS), install and run it on 
the target. 

I then started to look deeper into yocto and realized that there's the opkg 
package manager available in the image. 

Now comes my question, how can I build *.ipk packages on my development 
machine, which will then run on my target?

The image is based on poky 2.1. 

My endgoal is to run node.js and node red on the target. 

Can someone please point me to the right direction? 

Thanks a lot in advance. 

regards

Manuel

Manuel Geeler
Technischer Leiter


Identech AG
Lagerstrasse 14, CH-8600 Dübendorf
Tel.: +41 (0) 44 885 22 26
Mobil: +41 (0) 76 323 65 44
gee...@identech.ch
mailto:geeler@identech.chhttp://www.identech.ch/-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to build a same package twice with different configurations for same MACHINE?

2017-07-27 Thread Ngọc Thi Huỳnh 
Hi Dennis,

I've tried what you suggested, the problem is the busybox recipe uses some
files in its original directory so the bitbake complained about the missing
files.
My current solution is duplicating the busybox recipe and its related files
& directories.

Thanks anyway.

Best Regards,
Thi Huynh

Best Regards,
Thi Huynh

On Wed, Jul 26, 2017 at 4:18 AM, Dennis Menschel 
wrote:

> Hi,
>
> Am 18.07.2017 um 15:24 schrieb Ngọc Thi Huỳnh:
> > [...]
> >
> > Both images use busybox package but in different ways. The main-image
> > can use several busybox' tools but the initial-flasher-image only uses
> > one or two of them just to complete the flashing goal.
> >
> > My question is, is there a way to build busybox for main-image with one
> > defconfig, then build the busybox for initial-flasher-image with a
> > different defconfig when I issue "bitbake initial-flasher-image" command?
> >
> > [...]
> I'm not aware of such a feature in BitBake. As for your situation I'd
> suggest creating a secondary recipe (e.g. "busybox-flasher") in your own
> layer which includes the original busybox recipe and adapts its feature
> set with a configuration fragment.
>
> Example: busybox-flasher_1.24.1.bb
>
> require recipes-core/busybox/busybox_${PV}.bb
> SRC_URI += "file://flasher-options.cfg"
>
> That way you can easily distinguish busybox and busybox-flasher in your
> images and you can minimize the redundancies between the recipes.
>
> Hope it helps!
>
> Best regards,
> Dennis Menschel
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I write a yocto/bitbake recipe to replace the default vsftpd.conf file with my own filE?

2017-07-27 Thread Vineeth Chowdary Karumanchi 

Hi,


On 7/27/2017 1:13 PM, Bacheh Karaji wrote:

Ok, thanks very much  ...


On Tuesday, July 25, 2017, 11:18:13 PM GMT+4:30, Ayoub Zaki 
 wrote:



On 24.07.2017 07:18, Mohammad Nouri wrote:

Hi,
I want to replace the default vsftpd.conf file with my own file!
My bitbake file looks following:

bbexample_1.0.bb
   DESCRIPTION = "Configuration and extra files for TX28"
   LICENSE = "CLOSED"
   LIC_FILES_CHKSUM = ""

   S = "${WORKDIR}"

   SRC_URI += " \
   file://ld.so.conf \
   file://vsftpd.conf \
   file://nginx/nginx.conf \
   file://init.d/myscript.sh"

   inherit allarch

   do_install () {
   install -d ${D}${sysconfdir}
   install -d ${D}${sysconfdir}/nginx
   install -d ${D}${sysconfdir}/init.d
   rm -f ${D}${sysconfdir}/ld.so.conf
   rm -f ${D}${sysconfdir}/vsftpd.conf
   install -m 0755 ${WORKDIR}/ld.so.conf ${D}${sysconfdir}
   install -m 0755 ${WORKDIR}/vsftpd.conf ${D}${sysconfdir}
   install -m 0755 ${WORKDIR}/nginx/nginx.conf ${D}${sysconfdir}/nginx/
   install -m 0755 ${WORKDIR}/init.d/myscript.sh 
${D}${sysconfdir}/init.d/
   }

   But, the file could not be replaced!
   What is wrong?

you should add to your recipe :

FILES_${PN} += " list of files you installed"


On what basis we have to use FILES ?
Is it required for all prebuilt binaries/libraries/regular files ?
It works for me without FILES for a prebuilt app.

Thanks
VIneeth



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

Re: [yocto] RPi fails when build is with deb packages works okay with rpm packages.

2017-07-27 Thread Paul Barker 
On Wed, Jul 12, 2017 at 7:10 PM, Edward Vidal  wrote:
> Hello All,
> Does anyone know if recipes are available for
> gcc-arm-none-eabi & binutils-arm-none-eabi?
>
>
> My build works okay when I use package_rpm and fails with package_deb.
> My bblayers.conf & local.conf are at
> https://github.com/develone/raspberrypi2_yocto/tree/master/poky2.2/raspberrypi2/conf_files
> Any and all help is appreciated.
>
>
> Parsing recipes: 100% |##| Time:
> 0:00:46
> ~/wkg/yocto/RaspberryPi2/poky/build$ diff conf/local.conf
> ~/wkg/raspberrypi2_yocto/poky2.2/raspberrypi2/conf_files/local.conf
> 124c124
> < PACKAGE_CLASSES ?= "package_deb"
> ---
>> PACKAGE_CLASSES ?= "package_rpm"
>
> Parsing of 1931 .bb files complete (0 cached, 1931 parsed). 2616 targets,
> 170 skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-16.04"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "raspberrypi2"
> DISTRO= "poky"
> DISTRO_VERSION= "2.2"
> TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard
> cortexa7"
> TARGET_FPU= "hard"
> meta
> meta-poky
> meta-yocto-bsp= "morty:5aa481dfedfd089f0d6e8a3bae1b84134d5dff4c"
> meta-raspberrypi  = "master:6bd1bfe472ea491c0edeb7c854d1c0cc5192afeb"
> meta-oe
> meta-python
> meta-multimedia
> meta-gnome= "morty:5aa481dfedfd089f0d6e8a3bae1b84134d5dff4c"
> meta-browser  = "master:1edcce7791b4cee9a515c1f11b351753a4f8b12e"

It looks like you're mixing branches here. All your layers should
typically be on the same branch - so either all on morty or all on
master here. Could you align these and re-try your build?

Thanks,

-- 
Paul Barker
Co-Founder & Principal Engineer
Togán Labs Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] nmap: upgrade to 7.50

2017-07-27 Thread jackie.huang 
From: Jackie Huang 

- Add a patch to fix python library install dir for multilib.

- Add a patch to fix race condition with mkdir command.

- Inherit pythonnative instead of python-dir and install
  python modules for ndiff to fix the following errors:

  """
  root@qemux86-64:~# ndiff --help
  -sh: /usr/bin/ndiff: /path_to_build/tmp/hosttools/python: bad interpreter: No 
such file or directory
  root@qemux86-64:~# python /usr/bin/ndiff
  Could not import the ndiff module: 'No module named ndiff'.
  """

Signed-off-by: Jackie Huang 
---
 .../nmap-redefine-the-python-library-dir.patch | 37 +
 ...shtool-mkdir-with-coreutils-mkdir-command.patch | 48 ++
 .../nmap/{nmap_7.31.bb => nmap_7.50.bb}| 23 ++-
 3 files changed, 97 insertions(+), 11 deletions(-)
 create mode 100644 
recipes-security/nmap/files/nmap-redefine-the-python-library-dir.patch
 create mode 100644 
recipes-security/nmap/files/nmap-replace-shtool-mkdir-with-coreutils-mkdir-command.patch
 rename recipes-security/nmap/{nmap_7.31.bb => nmap_7.50.bb} (75%)

diff --git 
a/recipes-security/nmap/files/nmap-redefine-the-python-library-dir.patch 
b/recipes-security/nmap/files/nmap-redefine-the-python-library-dir.patch
new file mode 100644
index 000..356b507
--- /dev/null
+++ b/recipes-security/nmap/files/nmap-redefine-the-python-library-dir.patch
@@ -0,0 +1,37 @@
+[PATCH] redefine the python library install dir
+
+Upstream-Status: Pending
+
+If install-lib is not defined, it is always /usr/lib/, but it
+maybe /usr/lib64 for multilib
+
+Signed-off-by: Roy Li 
+---
+ Makefile.in | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index 1bb062c..cced2fb 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -311,7 +311,7 @@ build-zenmap: $(ZENMAPDIR)/setup.py 
$(ZENMAPDIR)/zenmapCore/Version.py
+ 
+ install-zenmap: $(ZENMAPDIR)/setup.py
+   $(INSTALL) -d $(DESTDIR)$(bindir) $(DESTDIR)$(mandir)/man1
+-  cd $(ZENMAPDIR) && $(PYTHON) setup.py --quiet install --prefix 
"$(prefix)" --force $(if $(DESTDIR),--root "$(DESTDIR)")
++  cd $(ZENMAPDIR) && $(PYTHON) setup.py --quiet install --prefix 
"$(prefix)" --install-lib="${PYTHON_SITEPACKAGES_DIR}" --force $(if 
$(DESTDIR),--root "$(DESTDIR)")
+   $(INSTALL) -c -m 644 docs/zenmap.1 $(DESTDIR)$(mandir)/man1/
+ # Create a symlink from nmapfe to zenmap if nmapfe doesn't exist or is
+ # already a link.
+@@ -328,7 +328,7 @@ build-nping: $(NPINGDIR)/Makefile nbase_build nsock_build 
netutil_build $(NPINGD
+   @cd $(NPINGDIR) && $(MAKE)
+ 
+ install-ndiff:
+-  cd $(NDIFFDIR) && $(PYTHON) setup.py install --prefix "$(prefix)" $(if 
$(DESTDIR),--root "$(DESTDIR)")
++  cd $(NDIFFDIR) && $(PYTHON) setup.py install --prefix "$(prefix)" 
--install-lib="${PYTHON_SITEPACKAGES_DIR}" $(if $(DESTDIR),--root "$(DESTDIR)")
+ 
+ NSE_FILES = scripts/script.db scripts/*.nse
+ NSE_LIB_LUA_FILES = nselib/*.lua nselib/*.luadoc
+-- 
+1.9.1
+
diff --git 
a/recipes-security/nmap/files/nmap-replace-shtool-mkdir-with-coreutils-mkdir-command.patch
 
b/recipes-security/nmap/files/nmap-replace-shtool-mkdir-with-coreutils-mkdir-command.patch
new file mode 100644
index 000..cfe043a
--- /dev/null
+++ 
b/recipes-security/nmap/files/nmap-replace-shtool-mkdir-with-coreutils-mkdir-command.patch
@@ -0,0 +1,48 @@
+[PATCH] replace "./shtool mkdir" with coreutils mkdir command
+
+Upstream-Status: Pending
+
+"./shtool mkdir" is used when mkdir has not -p parameter, but mkdir in today
+most release has supportted the -p parameter, not need to use shtool, and it
+can not fix the race if two process are running mkdir to create same dir
+
+Signed-off-by: Roy Li 
+---
+ ncat/Makefile.in| 4 ++--
+ nmap-update/Makefile.in | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/ncat/Makefile.in b/ncat/Makefile.in
+index cfd306d..2166e08 100644
+--- a/ncat/Makefile.in
 b/ncat/Makefile.in
+@@ -163,11 +163,11 @@ $(NSOCKDIR)/libnsock.a: $(NSOCKDIR)/Makefile
+ 
+ install: $(TARGET)
+   @echo Installing Ncat;
+-  $(SHTOOL) mkdir -f -p -m 755 $(DESTDIR)$(bindir) 
$(DESTDIR)$(mandir)/man1
++  mkdir -p -m 755 $(DESTDIR)$(bindir) $(DESTDIR)$(mandir)/man1
+   $(INSTALL) -c -m 755 ncat $(DESTDIR)$(bindir)/ncat
+   $(STRIP) -x $(DESTDIR)$(bindir)/ncat
+   if [ -n "$(DATAFILES)" ]; then \
+-  $(SHTOOL) mkdir -f -p -m 755 $(DESTDIR)$(pkgdatadir); \
++  mkdir -p -m 755 $(DESTDIR)$(pkgdatadir); \
+   $(INSTALL) -c -m 644 $(DATAFILES) $(DESTDIR)$(pkgdatadir)/; \
+   fi
+   $(INSTALL) -c -m 644 docs/$(TARGET).1 
$(DESTDIR)$(mandir)/man1/$(TARGET).1
+diff --git a/nmap-update/Makefile.in b/nmap-update/Makefile.in
+index 89ff928..93f48d8 100644
+--- a/nmap-update/Makefile.in
 b/nmap-update/Makefile.in
+@@ -37,7 +37,7 @@ $(NBASELIB):
+