[OE-core] [PATCH] librsvg: 2.40.17 -> 2.40.18

[Huang Qiyu]

Upgrade librsvg from 2.40.17 to 2.40.18.

Signed-off-by: Huang Qiyu 
---
 meta/recipes-gnome/librsvg/{librsvg_2.40.17.bb => librsvg_2.40.18.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-gnome/librsvg/{librsvg_2.40.17.bb => librsvg_2.40.18.bb} 
(91%)

diff --git a/meta/recipes-gnome/librsvg/librsvg_2.40.17.bb 
b/meta/recipes-gnome/librsvg/librsvg_2.40.18.bb
similarity index 91%
rename from meta/recipes-gnome/librsvg/librsvg_2.40.17.bb
rename to meta/recipes-gnome/librsvg/librsvg_2.40.18.bb
index 74777e9..21a0dc2 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.40.17.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.40.18.bb
@@ -14,8 +14,8 @@ inherit autotools pkgconfig gnomebase gtk-doc pixbufcache 
upstream-version-is-ev
 
 SRC_URI += "file://gtk-option.patch"
 
-SRC_URI[archive.md5sum] = "d6fcedf86c5c271abb36da5acc7eb987"
-SRC_URI[archive.sha256sum] = 
"e6f6c5cbecc405bb945c7cd15061276035ae3173bbb3bb25e8a916779c7f69cc"
+SRC_URI[archive.md5sum] = "eaa5c8a8bbe2600ab5194c0d3b1b621b"
+SRC_URI[archive.sha256sum] = 
"bfc8c488c89c1e7212c478beb95c41b44701636125a3e6dab41187f1485b564c"
 
 CACHED_CONFIGUREVARS = 
"ac_cv_path_GDK_PIXBUF_QUERYLOADERS=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders"
 
-- 
2.7.4



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

Re: [OE-core] [PATCH V2] tclibc-musl.inc: fix bfd "cannot make copy relocation for protected symbol" issues

[Ming Liu]

Hi, Khem:

Just tried, but the error still could be observed with the patch
applied, for instance:

| 
/home/peter-liu/opensource/poky-upstream/build/tmp/work/cortexa8hf-neon-poky-linux-musleabi/m4/1.4.18-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-musleabi/../../libexec/arm-poky-linux-musleabi/gcc/arm-poky-linux-musleabi/7.1.0/ld:
error: ../lib/libm4.a(progname.o): cannot make copy relocation for
protected symbol 'program_invocation_name', defined in
/home/peter-liu/opensource/poky-upstream/build/tmp/work/cortexa8hf-neon-poky-linux-musleabi/m4/1.4.18-r0/recipe-sysroot/usr/lib/libc.so
| collect2: error: ld returned 1 exit status
| Makefile:1554: recipe for target 'm4' failed

//Ming Liu


2017-07-31 23:56 GMT+02:00 Khem Raj :

> On Tue, Jul 25, 2017 at 1:07 AM, Ming Liu  wrote:
> > Hi, Burton:
> >
> > I also agree with you, your suggestion is better.
> >
> > Hi, Khem:
> >
> > But is this a bug of binutils? Or musl libc? Since I had only observed
> this
> > error with musl libc only, it did not occur with glibc.
> >
>
> Please try out a tentative patch here
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=11679#c4
>
> > //Ming Liu
> >
> > 2017-07-24 15:39 GMT+02:00 Khem Raj :
> >>
> >> On Mon, Jul 24, 2017 at 6:18 AM, Burton, Ross 
> >> wrote:
> >> > If we're going to silently change the linker to bfd under musl if
> >> > ld-is-gold
> >> > is selected, wouldn't it be better just to throw an exception if both
> >> > musl
> >> > and ld-is-gold are selected?  Better to tell the user so they can not
> do
> >> > that than silently ignore what they asked.
> >>
> >> yes, that would be better but I am skeptical of disabling it
> >> completely, we should
> >> create testcase and report it to binutils bugzilla
> >>
> >>
> >> >
> >> > Ross
> >> >
> >> > On 22 July 2017 at 14:30,  wrote:
> >> >>
> >> >> From: Ming Liu 
> >> >>
> >> >> Quite a few such compiling issues were found when I was building with
> >> >> following configs:
> >> >> ...
> >> >> MACHINE = "beaglebone"
> >> >> TCLIBC = "musl"
> >> >> DISTRO_FEATURES_append = " ld-is-gold"
> >> >> ...
> >> >>
> >> >> fixed by adding bfd binding now ldflags.
> >> >>
> >> >> Signed-off-by: Ming Liu 
> >> >> ---
> >> >>  meta/conf/distro/include/tclibc-musl.inc | 4 
> >> >>  1 file changed, 4 insertions(+)
> >> >>
> >> >> diff --git a/meta/conf/distro/include/tclibc-musl.inc
> >> >> b/meta/conf/distro/include/tclibc-musl.inc
> >> >> index 3d3f6ac..99d52a1 100644
> >> >> --- a/meta/conf/distro/include/tclibc-musl.inc
> >> >> +++ b/meta/conf/distro/include/tclibc-musl.inc
> >> >> @@ -18,6 +18,10 @@ PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?=
> >> >> "nativesdk-glibc"
> >> >>
> >> >>  CXXFLAGS += "-fvisibility-inlines-hidden"
> >> >>
> >> >> +# Workaround for musl libc does not support bfd lazy binding well
> >> >> +# Refer to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11679
> >> >> +LDFLAGS += "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold',
> >> >> '-Wl,-z,relro,-z,now -fuse-ld=bfd', '', d)}"
> >> >> +
> >> >>  IMAGE_LINGUAS = ""
> >> >>
> >> >>  LIBC_DEPENDENCIES = "\
> >> >> --
> >> >> 2.7.4
> >> >>
> >> >
> >> >
> >> > --
> >> > ___
> >> > Openembedded-core mailing list
> >> > Openembedded-core@lists.openembedded.org
> >> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >> >
> >
> >
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 02/10] runtime/cases/_ptest.py: revive it

[Robert Yang]

On 07/31/2017 09:38 PM, Paul Eggleton wrote:

On Monday, 31 July 2017 11:50:02 AM CEST Robert Yang wrote:

* Will write a tool to make regression check


This commit doesn't do this and it's not completely covered by the rest of the
series. I think you could say perhaps more appropriately "This provides data
that could be used to detect regressions in ptest results" or similar assuming
you need to mention it at all.


Sorry, I will update it, it was written when I didn't plan to use buildhistory,
now I save the data into buildhistory, so the tool is not needed any more.

// Robert



Cheers,
Paul


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

Re: [OE-core] [PATCH 09/10] buildhistory.bbclass: add ptest_log

[Robert Yang]

On 07/31/2017 09:30 PM, Paul Eggleton wrote:

Hi Robert,

A few minor comments below.

On Monday, 31 July 2017 11:50:09 AM CEST Robert Yang wrote:

The ptest log will be saved to buildhistory/ptest_log, we can easily get
the regression result between builds by:
$ git show HEAD ptest_log/pass.fail.skip.*

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/classes/buildhistory.bbclass | 28 
 1 file changed, 28 insertions(+)

diff --git a/meta/classes/buildhistory.bbclass b/meta/classes/

buildhistory.bbclass

index a3e4c7a734a..26430a63d31 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -912,3 +912,31 @@ def write_latest_srcrev(d, pkghistdir):
 else:
 if os.path.exists(srcrevfile):
 os.remove(srcrevfile)
+
+do_testimage[postfuncs] += "write_ptest_result"
+do_testimage[vardepsexclude] += "write_ptest_result"
+
+python write_ptest_result() {
+write_latest_ptest_result(d, d.getVar('BUILDHISTORY_DIR'))
+}
+
+def write_latest_ptest_result(d, histdir):
+import glob
+import subprocess
+test_log_dir = d.getVar('TEST_LOG_DIR')
+input_ptest_log = os.path.join(test_log_dir, 'ptest_log')
+output_ptest_log = os.path.join(histdir, 'ptest_log')


Would it be reasonable for this to just be "ptest"? To ask the question a
different way, would you expect to save other types of ptest information into
buildhistory, or is this likely to be it?


I'm not sure atm, so use "ptest" sounds reasonable. I will update it.




+if os.path.exists(input_ptest_log):
+# Lock it avoid race issue
+lock = bb.utils.lockfile(output_ptest_log + "/ptest_log.lock")
+bb.utils.mkdirhier(output_ptest_log)
+oe.path.copytree(input_ptest_log, output_ptest_log)
+# Sort test result
+for result in glob.glob('%s/pass.fail.*' % output_ptest_log):
+bb.debug(1, 'Processing %s' % result)
+cmd = "sort %s -o %s" % (result, result)
+bb.debug(1, 'Running %s' % cmd)
+ret = subprocess.call(cmd, shell=True)


As a matter of good practice and since it's easy to do here I'd suggest not
using shell=True and passing the command as a list instead, that way there
can't be any issues with spaces or other shell interpretations.


Thanks, I will update it.




+if ret != 0:
+bb.error('Failed to run %s!' % cmd)
+bb.utils.unlockfile(lock)


Shouldn't you be using try...finally here to ensure the lockfile gets unlocked
in the case of exceptions?


Yes, good idea.

// Robert



Cheers,
Paul



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

[OE-core] [oe-core][PATCH] powertop: update to v2.9

[Tim Orling]

* Upstream filename added "v" before version:
  - Add UPSTREAM_CHECK_REGEX
  - Update SRC_URI to include the "v"
  - Point ${S} to proper directory

* Patch for required headers no longer needed in current upstream

Signed-off-by: Tim Orling 
---
 ...0001-include-rquired-headers-for-typedefs.patch | 47 --
 .../powertop/{powertop_2.8.bb => powertop_2.9.bb}  | 10 +++--
 2 files changed, 6 insertions(+), 51 deletions(-)
 delete mode 100644 
meta/recipes-kernel/powertop/powertop/0001-include-rquired-headers-for-typedefs.patch
 rename meta/recipes-kernel/powertop/{powertop_2.8.bb => powertop_2.9.bb} (77%)

diff --git 
a/meta/recipes-kernel/powertop/powertop/0001-include-rquired-headers-for-typedefs.patch
 
b/meta/recipes-kernel/powertop/powertop/0001-include-rquired-headers-for-typedefs.patch
deleted file mode 100644
index 0fd6310..000
--- 
a/meta/recipes-kernel/powertop/powertop/0001-include-rquired-headers-for-typedefs.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-From 0856d8145d187a7e5a49625247abe43a13f95acc Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Tue, 15 Sep 2015 19:36:28 +
-Subject: [PATCH] include rquired headers for typedefs
-
-timeval struct needs to include sys/time.h and sprintf() usage requires
-to include stdio.h headers from system
-
-Fixes
-src/perf/perf_bundle.cpp:141:2: error: use of undeclared identifier 'sprintf'; 
did you mean 'vswprintf'?
-src/devices/devfreq.h:35:18: error: field has incomplete type 'struct timeval'
-
-Signed-off-by: Khem Raj 

-Upstream-Status: Pending
-
- src/devices/devfreq.h| 1 +
- src/perf/perf_bundle.cpp | 1 +
- 2 files changed, 2 insertions(+)
-
-diff --git a/src/devices/devfreq.h b/src/devices/devfreq.h
-index 16a60fb..4bede7c 100644
 a/src/devices/devfreq.h
-+++ b/src/devices/devfreq.h
-@@ -25,6 +25,7 @@
- #ifndef _INCLUDE_GUARD_DEVFREQ_H
- #define _INCLUDE_GUARD_DEVFREQ_H
- 
-+#include 
- #include "device.h"
- #include "../parameters/parameters.h"
- 
-diff --git a/src/perf/perf_bundle.cpp b/src/perf/perf_bundle.cpp
-index cf1ae11..232f894 100644
 a/src/perf/perf_bundle.cpp
-+++ b/src/perf/perf_bundle.cpp
-@@ -27,6 +27,7 @@
- #include 
- #include 
- #include 
-+#include 
- #include 
- #include 
- #include 
--- 
-2.5.2
-
diff --git a/meta/recipes-kernel/powertop/powertop_2.8.bb 
b/meta/recipes-kernel/powertop/powertop_2.9.bb
similarity index 77%
rename from meta/recipes-kernel/powertop/powertop_2.8.bb
rename to meta/recipes-kernel/powertop/powertop_2.9.bb
index 4d7a3e7..93ed5ba 100644
--- a/meta/recipes-kernel/powertop/powertop_2.8.bb
+++ b/meta/recipes-kernel/powertop/powertop_2.9.bb
@@ -6,17 +6,19 @@ DEPENDS = "ncurses libnl pciutils"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
 
-SRC_URI = 
"http://01.org/sites/default/files/downloads/powertop/powertop-${PV}.tar.gz \
-   file://0001-include-rquired-headers-for-typedefs.patch \
+SRC_URI = 
"http://01.org/sites/default/files/downloads/powertop/powertop-v${PV}.tar.gz \
 "
 
-SRC_URI[md5sum] = "c55fedb69203e480801b18bd7b886241"
-SRC_URI[sha256sum] = 
"a87b563f73106babfa3e74dcf92f252938c061e309ace20a361358bbfa579c5a"
+SRC_URI[md5sum] = "583518c5c4434c6e9b9c58c3920950b6"
+SRC_URI[sha256sum] = 
"aa7fb7d8e9a00f05e7d8a7a2866d85929741e0d03a5bf40cab22d2021c959250"
 
 UPSTREAM_CHECK_URI = "https://01.org/powertop/downloads;
+UPSTREAM_CHECK_REGEX = "powertop-[v]?(?P\d+(\.\d+)+)\.tar"
 
 inherit autotools gettext pkgconfig
 
+S = "${WORKDIR}/${PN}-v${PV}"
+
 # we do not want libncursesw if we can
 do_configure_prepend() {
 # configure.ac checks for delwin() in "ncursesw ncurses" so let's drop 
first one
-- 
2.9.4

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

[OE-core] [PATCH V2] mesa,llvm: Use native version of llvm-config

[Khem Raj]

We have a variable YOCTO_ALTERNATE_EXE_PATH to point to
target sysroot, utilize this in mesa to use native version
of llvm-config to report values from target sysroot.

Its in a way similar to --sysroot option

strip out rpath since its absolute path and incorrect thusly

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/llvm/llvm_git.bb | 12 +++-
 meta/recipes-graphics/mesa/mesa.inc| 13 +++--
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/meta/recipes-devtools/llvm/llvm_git.bb 
b/meta/recipes-devtools/llvm/llvm_git.bb
index 5dcb508c23..5e754e45dc 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -87,12 +87,12 @@ do_compile() {
 }
 
 do_compile_class-native() {
-   NINJA_STATUS="[%p] " ninja -v ${PARALLEL_MAKE} llvm-tblgen
+   NINJA_STATUS="[%p] " ninja -v ${PARALLEL_MAKE} llvm-config llvm-tblgen
 }
 
 do_install() {
NINJA_STATUS="[%p] " DESTDIR=${LLVM_INSTALL_DIR} ninja -v install
-   install -D -m 0755 ${B}/NATIVE/bin/llvm-config 
${D}${libdir}/${LLVM_DIR}/llvm-config-host
+   install -D -m 0755 ${B}/bin/llvm-config 
${D}${libdir}/${LLVM_DIR}/llvm-config
 
install -d ${D}${bindir}/${LLVM_DIR}
cp -r ${LLVM_INSTALL_DIR}${bindir}/* ${D}${bindir}/${LLVM_DIR}/
@@ -121,7 +121,9 @@ do_install() {
rm -rf ${D}${libdir}/${LLVM_DIR}/libLTO.so
 }
 do_install_class-native() {
-   install -D -m 0755 ${B}/bin/llvm-tblgen ${D}${bindir}/llvm-tblgen
+   install -D -m 0755 ${B}/bin/llvm-tblgen ${D}${bindir}/llvm-tblgen-5.0
+   install -D -m 0755 ${B}/bin/llvm-config ${D}${bindir}/llvm-config-5.0
+   install -D -m 0755 ${B}/lib/libLLVM-5.0.so ${D}${libdir}/libLLVM-5.0.so
 }
 
 PACKAGES += "${PN}-bugpointpasses ${PN}-llvmhello"
@@ -134,14 +136,14 @@ FILES_${PN}-dbg = " \
 ${libdir}/${LLVM_DIR}/.debug/BugpointPasses.so \
 ${libdir}/${LLVM_DIR}/.debug/LLVMHello.so \
 ${libdir}/${LLVM_DIR}/.debug/libLTO.so* \
-${libdir}/${LLVM_DIR}/.debug/llvm-config-host \
+${libdir}/${LLVM_DIR}/.debug/llvm-config \
 /usr/src/debug \
 "
 
 FILES_${PN}-dev = " \
 ${bindir}/${LLVM_DIR} \
 ${includedir}/${LLVM_DIR} \
-${libdir}/${LLVM_DIR}/llvm-config-host \
+${libdir}/${LLVM_DIR}/llvm-config \
 "
 
 RRECOMMENDS_${PN}-dev += "${PN}-bugpointpasses ${PN}-llvmhello"
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index c9b67d4966..5c1957fdc6 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -14,8 +14,8 @@ LIC_FILES_CHKSUM = 
"file://docs/license.html;md5=725f991a1cc322aa7a0cd3a2016621c
 
 PE = "2"
 
-DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native 
zlib"
-
+DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native 
zlib chrpath-replacement-native"
+EXTRANATIVEPATH += "chrpath-native"
 PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl 
virtual/mesa"
 
 inherit autotools pkgconfig gettext distro_features_check
@@ -25,8 +25,8 @@ REQUIRED_DISTRO_FEATURES = "opengl"
 PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'drm', '', d)}"
 
-export LLVM_CONFIG = 
"${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}/llvm-config-host"
-
+export LLVM_CONFIG = 
"${STAGING_BINDIR_NATIVE}/llvm-config-${MESA_LLVM_RELEASE}"
+export YOCTO_ALTERNATE_EXE_PATH = 
"${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}/llvm-config"
 EXTRA_OECONF = "--enable-shared-glapi \
 --disable-opencl \
 --with-llvm-prefix=${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE} \
@@ -75,7 +75,7 @@ GALLIUMDRIVERS_append_x86-64 = 
"${@bb.utils.contains('PACKAGECONFIG', 'gallium-l
 # keep --with-gallium-drivers separate, because when only one of gallium 
versions is enabled, other 2 were adding --without-gallium-drivers
 PACKAGECONFIG[gallium]  = "--enable-texture-float 
--with-gallium-drivers=${GALLIUMDRIVERS}, --without-gallium-drivers"
 MESA_LLVM_RELEASE ?= "5.0"
-PACKAGECONFIG[gallium-llvm] = "--enable-llvm --enable-llvm-shared-libs, 
--disable-llvm, llvm${MESA_LLVM_RELEASE} \
+PACKAGECONFIG[gallium-llvm] = "--enable-llvm --enable-llvm-shared-libs, 
--disable-llvm, llvm${MESA_LLVM_RELEASE} llvm-native \
${@'elfutils' if 
${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
 export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"
 PACKAGECONFIG[xa]  = "--enable-xa, --disable-xa"
@@ -118,9 +118,10 @@ do_install_append () {
 rm -f ${D}${libdir}/egl/*.la
 rm -f ${D}${libdir}/gallium-pipe/*.la
 rm -f ${D}${libdir}/gbm/*.la
-
+
 # it was packaged in libdricore9.1.3-1 and preventing upgrades when 
debian.bbclass was used 
 rm -f ${D}${sysconfdir}/drirc
+chrpath --delete ${D}${libdir}/dri/*_dri.so
 }
 
 # For the packages that make up the OpenGL interfaces, inject variables so that
-- 
2.13.3

-- 

[OE-core] [PATCH] mesa,llvm: Use native version of llvm-config

[Khem Raj]

We have a variable YOCTO_ALTERNATE_EXE_PATH to point to
target sysroot, utilize this in mesa to use native version
of llvm-config to report values from target sysroot.

Its in a way similar to --sysroot option

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/llvm/llvm_git.bb | 12 +++-
 meta/recipes-graphics/mesa/mesa.inc|  6 +++---
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-devtools/llvm/llvm_git.bb 
b/meta/recipes-devtools/llvm/llvm_git.bb
index 5dcb508c23..5e754e45dc 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -87,12 +87,12 @@ do_compile() {
 }
 
 do_compile_class-native() {
-   NINJA_STATUS="[%p] " ninja -v ${PARALLEL_MAKE} llvm-tblgen
+   NINJA_STATUS="[%p] " ninja -v ${PARALLEL_MAKE} llvm-config llvm-tblgen
 }
 
 do_install() {
NINJA_STATUS="[%p] " DESTDIR=${LLVM_INSTALL_DIR} ninja -v install
-   install -D -m 0755 ${B}/NATIVE/bin/llvm-config 
${D}${libdir}/${LLVM_DIR}/llvm-config-host
+   install -D -m 0755 ${B}/bin/llvm-config 
${D}${libdir}/${LLVM_DIR}/llvm-config
 
install -d ${D}${bindir}/${LLVM_DIR}
cp -r ${LLVM_INSTALL_DIR}${bindir}/* ${D}${bindir}/${LLVM_DIR}/
@@ -121,7 +121,9 @@ do_install() {
rm -rf ${D}${libdir}/${LLVM_DIR}/libLTO.so
 }
 do_install_class-native() {
-   install -D -m 0755 ${B}/bin/llvm-tblgen ${D}${bindir}/llvm-tblgen
+   install -D -m 0755 ${B}/bin/llvm-tblgen ${D}${bindir}/llvm-tblgen-5.0
+   install -D -m 0755 ${B}/bin/llvm-config ${D}${bindir}/llvm-config-5.0
+   install -D -m 0755 ${B}/lib/libLLVM-5.0.so ${D}${libdir}/libLLVM-5.0.so
 }
 
 PACKAGES += "${PN}-bugpointpasses ${PN}-llvmhello"
@@ -134,14 +136,14 @@ FILES_${PN}-dbg = " \
 ${libdir}/${LLVM_DIR}/.debug/BugpointPasses.so \
 ${libdir}/${LLVM_DIR}/.debug/LLVMHello.so \
 ${libdir}/${LLVM_DIR}/.debug/libLTO.so* \
-${libdir}/${LLVM_DIR}/.debug/llvm-config-host \
+${libdir}/${LLVM_DIR}/.debug/llvm-config \
 /usr/src/debug \
 "
 
 FILES_${PN}-dev = " \
 ${bindir}/${LLVM_DIR} \
 ${includedir}/${LLVM_DIR} \
-${libdir}/${LLVM_DIR}/llvm-config-host \
+${libdir}/${LLVM_DIR}/llvm-config \
 "
 
 RRECOMMENDS_${PN}-dev += "${PN}-bugpointpasses ${PN}-llvmhello"
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index c9b67d4966..b0f9410e36 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -25,8 +25,8 @@ REQUIRED_DISTRO_FEATURES = "opengl"
 PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'drm', '', d)}"
 
-export LLVM_CONFIG = 
"${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}/llvm-config-host"
-
+export LLVM_CONFIG = 
"${STAGING_BINDIR_NATIVE}/llvm-config-${MESA_LLVM_RELEASE}"
+export YOCTO_ALTERNATE_EXE_PATH = 
"${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}/llvm-config"
 EXTRA_OECONF = "--enable-shared-glapi \
 --disable-opencl \
 --with-llvm-prefix=${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE} \
@@ -75,7 +75,7 @@ GALLIUMDRIVERS_append_x86-64 = 
"${@bb.utils.contains('PACKAGECONFIG', 'gallium-l
 # keep --with-gallium-drivers separate, because when only one of gallium 
versions is enabled, other 2 were adding --without-gallium-drivers
 PACKAGECONFIG[gallium]  = "--enable-texture-float 
--with-gallium-drivers=${GALLIUMDRIVERS}, --without-gallium-drivers"
 MESA_LLVM_RELEASE ?= "5.0"
-PACKAGECONFIG[gallium-llvm] = "--enable-llvm --enable-llvm-shared-libs, 
--disable-llvm, llvm${MESA_LLVM_RELEASE} \
+PACKAGECONFIG[gallium-llvm] = "--enable-llvm --enable-llvm-shared-libs, 
--disable-llvm, llvm${MESA_LLVM_RELEASE} llvm-native \
${@'elfutils' if 
${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
 export WANT_LLVM_RELEASE = "${MESA_LLVM_RELEASE}"
 PACKAGECONFIG[xa]  = "--enable-xa, --disable-xa"
-- 
2.13.3

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

Re: [OE-core] [PATCH V2] tclibc-musl.inc: fix bfd "cannot make copy relocation for protected symbol" issues

[Khem Raj]

On Tue, Jul 25, 2017 at 1:07 AM, Ming Liu  wrote:
> Hi, Burton:
>
> I also agree with you, your suggestion is better.
>
> Hi, Khem:
>
> But is this a bug of binutils? Or musl libc? Since I had only observed this
> error with musl libc only, it did not occur with glibc.
>

Please try out a tentative patch here
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11679#c4

> //Ming Liu
>
> 2017-07-24 15:39 GMT+02:00 Khem Raj :
>>
>> On Mon, Jul 24, 2017 at 6:18 AM, Burton, Ross 
>> wrote:
>> > If we're going to silently change the linker to bfd under musl if
>> > ld-is-gold
>> > is selected, wouldn't it be better just to throw an exception if both
>> > musl
>> > and ld-is-gold are selected?  Better to tell the user so they can not do
>> > that than silently ignore what they asked.
>>
>> yes, that would be better but I am skeptical of disabling it
>> completely, we should
>> create testcase and report it to binutils bugzilla
>>
>>
>> >
>> > Ross
>> >
>> > On 22 July 2017 at 14:30,  wrote:
>> >>
>> >> From: Ming Liu 
>> >>
>> >> Quite a few such compiling issues were found when I was building with
>> >> following configs:
>> >> ...
>> >> MACHINE = "beaglebone"
>> >> TCLIBC = "musl"
>> >> DISTRO_FEATURES_append = " ld-is-gold"
>> >> ...
>> >>
>> >> fixed by adding bfd binding now ldflags.
>> >>
>> >> Signed-off-by: Ming Liu 
>> >> ---
>> >>  meta/conf/distro/include/tclibc-musl.inc | 4 
>> >>  1 file changed, 4 insertions(+)
>> >>
>> >> diff --git a/meta/conf/distro/include/tclibc-musl.inc
>> >> b/meta/conf/distro/include/tclibc-musl.inc
>> >> index 3d3f6ac..99d52a1 100644
>> >> --- a/meta/conf/distro/include/tclibc-musl.inc
>> >> +++ b/meta/conf/distro/include/tclibc-musl.inc
>> >> @@ -18,6 +18,10 @@ PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?=
>> >> "nativesdk-glibc"
>> >>
>> >>  CXXFLAGS += "-fvisibility-inlines-hidden"
>> >>
>> >> +# Workaround for musl libc does not support bfd lazy binding well
>> >> +# Refer to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11679
>> >> +LDFLAGS += "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold',
>> >> '-Wl,-z,relro,-z,now -fuse-ld=bfd', '', d)}"
>> >> +
>> >>  IMAGE_LINGUAS = ""
>> >>
>> >>  LIBC_DEPENDENCIES = "\
>> >> --
>> >> 2.7.4
>> >>
>> >
>> >
>> > --
>> > ___
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> >
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] local.conf.sample.extended: remove references to image_types_uboot

[Tom Rini]

On Mon, Jul 31, 2017 at 04:16:24PM -0400, drew.mose...@northern.tech wrote:

> From: Drew Moseley 
> 
> This class was removed with commit:
> OE-Core rev: 65f27122950a35a67ce39ae4cfe93d0dca6b0dab
> 
> Signed-off-by: Drew Moseley 

Reviewed-by: Tom Rini 

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

Re: [OE-core] [PATCH v6 1/1] initramfs-framework: module to support boot live image

[Patrick Ohly]

On Wed, 2017-07-12 at 12:29 -0700, wei.tee...@intel.com wrote:
> +SUMMARY_initramfs-module-setup-live = "initramfs support for setup
> live"
> +RDEPENDS_initramfs-module-setup-live = "${PN}-base udev-extraconf"
> +FILES_initramfs-module-setup-live = "/init.d/80-setup-live"

Same problem as with install-efi: this RDEPENDS in initramfs-framework
makes building the recipe more complicated than strictly necessary.

Please move setup-live to its own recipe.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


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

Re: [OE-core] [PATCH] go-dep: Add 0.2.0 release

[Otavio Salvador]

On Mon, Jul 31, 2017 at 4:20 PM, Khem Raj  wrote:
>
>
> On 7/31/17 12:12 PM, Otavio Salvador wrote:
>> Hello Ross,
>> Hello Khem,
>>
>> On Sat, Jul 29, 2017 at 3:28 PM, Burton, Ross  wrote:
>>> Failed in the no-x11 builder at least so far:
>>>
>>> ERROR: go-dep-0.2.0-r0 do_package: QA Issue: go-dep: Files/directories were
>>> installed but not shipped in any package:
>>>   /usr/lib/x86_64-poky-linux/go/bin/dep
>>> Please set FILES such that these items are packaged. Alternatively if they
>>> are unneeded, avoid installing them or delete them within do_install.
>>>
>>> https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/builds/537
>>
>> I did reproduce this; I could only reproduce it if I built it with a
>> machine which matches the architecture of host, in my case x86-64.
>> When building for other arch (e.g: ARM) it works as expected.
>>
>> The problem seems to be a generic problem and I am not experienced
>> enough on the Golang toolchain to look at this. Khem could you take a
>> look and see if you find the root cause?
>
> Delete this file, its building it on x86_64 because it can. We only need
> cross version.

I am not sure I follow you here.

Using qemux86-64 as target it does NOT install on ${bindir} and
surprisingly the installation path does also not match GOBIN_FINAL
value.

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

Re: [OE-core] [PATCH 2/3] initramfs-framework: include install-efi module in recipe for installation

[Patrick Ohly]

On Sun, 2017-07-23 at 16:51 -0700, wei.tee...@intel.com wrote:
> +
> +SUMMARY_initramfs-module-install-efi = "initramfs support for installation 
> option"
> +RDEPENDS_initramfs-module-install-efi = "${PN}-base parted e2fsprogs-mke2fs 
> dosfstools util-linux-blkid"
> +FILES_initramfs-module-install-efi = "/init.d/install-efi.sh"

By making the install-efi module a part of initramfs-module that is
enabled unconditionally, parted now needs to be built for the target
even when only the rest of initramfs-module is used.

Can the module please be split out into its own recipe?

Alternatively one could add a PACKAGECONFIG for it, but that's less
flexible.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


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

Re: [OE-core] [PATCH] go-dep: Add 0.2.0 release

[Khem Raj]

On 7/31/17 12:12 PM, Otavio Salvador wrote:
> Hello Ross,
> Hello Khem,
> 
> On Sat, Jul 29, 2017 at 3:28 PM, Burton, Ross  wrote:
>> Failed in the no-x11 builder at least so far:
>>
>> ERROR: go-dep-0.2.0-r0 do_package: QA Issue: go-dep: Files/directories were
>> installed but not shipped in any package:
>>   /usr/lib/x86_64-poky-linux/go/bin/dep
>> Please set FILES such that these items are packaged. Alternatively if they
>> are unneeded, avoid installing them or delete them within do_install.
>>
>> https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/builds/537
> 
> I did reproduce this; I could only reproduce it if I built it with a
> machine which matches the architecture of host, in my case x86-64.
> When building for other arch (e.g: ARM) it works as expected.
> 
> The problem seems to be a generic problem and I am not experienced
> enough on the Golang toolchain to look at this. Khem could you take a
> look and see if you find the root cause?

Delete this file, its building it on x86_64 because it can. We only need
cross version.

> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[Andre McCurdy]

On Mon, Jul 31, 2017 at 5:50 AM, Maxin B. John  wrote:
> Hi,
>
> On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpj...@crashcourse.ca wrote:
>>
>> Quoting Richard Purdie :
>>
>> >On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
>> >>On 07/31/2017 01:41 PM, rpj...@crashcourse.ca wrote:
>> >>>
>> >>>
>> >>>given that some significant changes have been made to i2c-tools
>> >>> since
>> >>> version 3.1.2, is it worth adding a git-versioned recipe of that
>> >>> to
>> >>> oe-core,
>> >>> and using DEFAULT_PREFERENCE to force people to select it if they
>> >>> want it?
>> >>> in particular, the code base has been restructured, and a new
>> >>> utility,
>> >>> "i2ctransfer", has been added.
>> >>It's better to ask the upstream to make a new release.
>> >>
>> >>We've had dual git/release recipes in the past, and they were all an
>> >>utter failure. In the sense, that only one version of the recipe was
>> >>maintained, and the other was completely neglected.
>> >
>> >Going forward we may accept patches using this instead:
>> >
>> >http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass
>> >
>> >Cheers,
>> >
>> >Richard
>>
>>   well, here's a possible conundrum ... in that same package (i2c-tools),
>> there appears to be an *obvious* flaw in that the "eeprog" utility uses a
>> sleep that is far too short for proper operation, as described here:
>>
>> https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html
>>
>> there is a link to a patch on that page that simply cranks up a few sleep
>> calls from 10usec to 5msec, which apparently solves the problem. i've been
>> involved in a discussion on the i2c-tools mailing list about this very
>> issue after i tripped over it, but there seems to be little enthusiasm on
>> that list for "fixing" this -- i was told that people use the kernel driver
>> instead and access via /sys rather than calling "eeprog".
>
> dl.lm-sensors.org has been down for a while and doesn't show any positive 
> signs that
> it will be back in near future. One possibility will be to use the unofficial 
> mirrors
> listed below and upgrade to version 3.1.2
>
> 1. https://fossies.org/linux/misc/
> 2. http://jdelvare.nerim.net/mirror/i2c-tools/
>
>>   so, from my perspective, this should definitely be fixed so that "eeprog"
>> functions properly, but it's not clear upstream is all that interested in it.
>> what would the protocol be here?
>
> Since this genuinely fixes an error, we should be able to include this patch 
> with:
> "Inappropriate [bug workaround]" status.

If upstream isn't interesting in a fix then "Inappropriate [upstream
not interested in fix]" or "Inappropriate [upstream is dead]" would be
better tags.

>> rday
>
> Best Regards,
> Maxin
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] go-dep: Add 0.2.0 release

[Otavio Salvador]

Hello Ross,
Hello Khem,

On Sat, Jul 29, 2017 at 3:28 PM, Burton, Ross  wrote:
> Failed in the no-x11 builder at least so far:
>
> ERROR: go-dep-0.2.0-r0 do_package: QA Issue: go-dep: Files/directories were
> installed but not shipped in any package:
>   /usr/lib/x86_64-poky-linux/go/bin/dep
> Please set FILES such that these items are packaged. Alternatively if they
> are unneeded, avoid installing them or delete them within do_install.
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/builds/537

I did reproduce this; I could only reproduce it if I built it with a
machine which matches the architecture of host, in my case x86-64.
When building for other arch (e.g: ARM) it works as expected.

The problem seems to be a generic problem and I am not experienced
enough on the Golang toolchain to look at this. Khem could you take a
look and see if you find the root cause?

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

Re: [OE-core] [PATCH 1/2] armv8: update to use armv8-a tune

[Khem Raj]

On 7/31/17 10:51 AM, Mark Hatle wrote:
> On 7/31/17 12:40 PM, akuster808 wrote:
>>
>>
>> On 07/31/2017 10:31 AM, Mark Hatle wrote:
>>> On 7/31/17 12:16 PM, Armin Kuster wrote:
 Signed-off-by: Armin Kuster 
 ---
  meta/conf/machine/include/arm/arch-armv8.inc | 25 
 +
  1 file changed, 25 insertions(+)

 diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
 b/meta/conf/machine/include/arm/arch-armv8.inc
 index 5e832fa..dc1ba5e 100644
 --- a/meta/conf/machine/include/arm/arch-armv8.inc
 +++ b/meta/conf/machine/include/arm/arch-armv8.inc
 @@ -1 +1,26 @@
 +DEFAULTTUNE ?= "armv8-a"
>>> do we want the '-a'?  The other arm (7) are of the format armv7a (no '-').
>> works for me either way.
>>
>> While we are at it. How would we want ‘armv8.1-a’, ‘armv8.2-a’, ‘armv8.3-a'
>> formated as?
> 
> My preference is to drop the '-'.  As for the '.', I'm not sure.. not 
> something
> we've run across before.
> 
> We could just drop it (the '.'), but it really depends on if armv81a would
> confuse someone (familiar with arm) or not.

I would suggest to also sync  with other distros and ensure that we dont
do something different. Its very costly later. Since applications get
ported to most common combination

> 
> --Mark
> 
>> - armin
>>>
>>> --Mark
>>>
 +
 +TUNEVALID[armv8-a] = "Enable instructions for ARMv8-a"
 +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', ' 
 -march=armv8-a', '', d)}"
 +
 +TUNEVALID[crypto] = "Enable crypto instructions for ARMv8-a"
 +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', 
 '+crypto', '', d)}"
 +
 +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', 
 'armv8a:', '' ,d)}"
 +
  require conf/machine/include/arm/arch-arm64.inc
 +
 +AVAILTUNES += "armv8-a armv8-a-crypto"
 +ARMPKGARCH_tune-armv8-a ?= "armv8-a"
 +
 +# Enable Crypto extension. This also enables Advanced SIMD and 
 floating-point instructions
 +ARMPKGARCH_tune-armv8-a-crypto ?= "armv8-a"
 +
 +TUNE_FEATURES_tune-armv8-a = "aarch64 armv8-a"
 +TUNE_FEATURES_tune-armv8-a-crypto = "${TUNE_FEATURES_tune-armv8-a} crypto"
 +
 +PACKAGE_EXTRA_ARCHS_tune-armv8-a = "aarch64 armv8-a"
 +PACKAGE_EXTRA_ARCHS_tune-armv8-a-crypto = 
 "${PACKAGE_EXTRA_ARCHS_tune-armv8-a} armv8-a-crypto"
 +
 +BASE_LIB_tune-armv8-a = "${BASE_LIB_tune-aarch64}"
 +BASE_LIB_tune-armv8-a-crypto = "${BASE_LIB_tune-aarch64}"

>>
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[Khem Raj]

On 7/31/17 4:15 AM, rpj...@crashcourse.ca wrote:
> 
> Quoting Richard Purdie :
> 
>> On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
>>> On 07/31/2017 01:41 PM, rpj...@crashcourse.ca wrote:
>>> >
>>> >
>>> >    given that some significant changes have been made to i2c-tools
>>> > since
>>> > version 3.1.2, is it worth adding a git-versioned recipe of that
>>> > to 
>>> > oe-core,
>>> > and using DEFAULT_PREFERENCE to force people to select it if they
>>> > want it?
>>> > in particular, the code base has been restructured, and a new
>>> > utility,
>>> > "i2ctransfer", has been added.
>>> It's better to ask the upstream to make a new release.
>>>
>>> We've had dual git/release recipes in the past, and they were all an 
>>> utter failure. In the sense, that only one version of the recipe was 
>>> maintained, and the other was completely neglected.
>>
>> Going forward we may accept patches using this instead:
>>
>> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass
>>
>>
>> Cheers,
>>
>> Richard
> 
>   well, here's a possible conundrum ... in that same package (i2c-tools),
> there appears to be an *obvious* flaw in that the "eeprog" utility uses a
> sleep that is far too short for proper operation, as described here:
> 
> https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html
> 
> 
> there is a link to a patch on that page that simply cranks up a few sleep
> calls from 10usec to 5msec, which apparently solves the problem. i've been
> involved in a discussion on the i2c-tools mailing list about this very
> issue after i tripped over it, but there seems to be little enthusiasm on
> that list for "fixing" this -- i was told that people use the kernel driver
> instead and access via /sys rather than calling "eeprog"
> 
>   so, from my perspective, this should definitely be fixed so that "eeprog"
> functions properly, but it's not clear upstream is all that interested
> in it.
> what would the protocol be here?

usually, sending it upstream at same time when its proposed here for OE
is best. Then you can discuss it with upstream on sides, if upstream
does not want a patch, that creates some maintenance debt for future
upgrades but such is life.

> 
> rday
> 
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] autoconf-archive: GPLv3 + autoconf exception

[Patrick Ohly]

The COPYING file specifies pure GPLv3, not GPLv2 & GPLv3, with the
autoconf exception in COPYING.EXCEPTION. OE-core currently has
GPL-3.0-with-GCC-exception for this in meta/conf/licenses.conf, so
this is used here despite the deprecation note for that license
identifier in https://spdx.org/licenses/GPL-3.0-with-autoconf-exception.

Signed-off-by: Patrick Ohly 
---
 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb 
b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
index d77c37d..104dc38 100644
--- a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
+++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
@@ -1,8 +1,9 @@
 SUMMARY = "a collection of freely re-usable Autoconf macros"
 HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/;
 SECTION = "devel"
-LICENSE = "GPLv3"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
+LICENSE = "GPL-3.0-with-autoconf-exception"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.EXCEPTION;md5=fdef168ebff3bc2f13664c365a5fb515"
 
 SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
 SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"

base-commit: da29bc17e4dd748f50b054c5e3afaf8d41bf4077
-- 
git-series 0.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] armv8: update to use armv8-a tune

[Mark Hatle]

On 7/31/17 12:40 PM, akuster808 wrote:
> 
> 
> On 07/31/2017 10:31 AM, Mark Hatle wrote:
>> On 7/31/17 12:16 PM, Armin Kuster wrote:
>>> Signed-off-by: Armin Kuster 
>>> ---
>>>  meta/conf/machine/include/arm/arch-armv8.inc | 25 +
>>>  1 file changed, 25 insertions(+)
>>>
>>> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
>>> b/meta/conf/machine/include/arm/arch-armv8.inc
>>> index 5e832fa..dc1ba5e 100644
>>> --- a/meta/conf/machine/include/arm/arch-armv8.inc
>>> +++ b/meta/conf/machine/include/arm/arch-armv8.inc
>>> @@ -1 +1,26 @@
>>> +DEFAULTTUNE ?= "armv8-a"
>> do we want the '-a'?  The other arm (7) are of the format armv7a (no '-').
> works for me either way.
> 
> While we are at it. How would we want ‘armv8.1-a’, ‘armv8.2-a’, ‘armv8.3-a'
> formated as?

My preference is to drop the '-'.  As for the '.', I'm not sure.. not something
we've run across before.

We could just drop it (the '.'), but it really depends on if armv81a would
confuse someone (familiar with arm) or not.

--Mark

> - armin
>>
>> --Mark
>>
>>> +
>>> +TUNEVALID[armv8-a] = "Enable instructions for ARMv8-a"
>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', ' 
>>> -march=armv8-a', '', d)}"
>>> +
>>> +TUNEVALID[crypto] = "Enable crypto instructions for ARMv8-a"
>>> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto', 
>>> '', d)}"
>>> +
>>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', 
>>> 'armv8a:', '' ,d)}"
>>> +
>>>  require conf/machine/include/arm/arch-arm64.inc
>>> +
>>> +AVAILTUNES += "armv8-a armv8-a-crypto"
>>> +ARMPKGARCH_tune-armv8-a ?= "armv8-a"
>>> +
>>> +# Enable Crypto extension. This also enables Advanced SIMD and 
>>> floating-point instructions
>>> +ARMPKGARCH_tune-armv8-a-crypto ?= "armv8-a"
>>> +
>>> +TUNE_FEATURES_tune-armv8-a = "aarch64 armv8-a"
>>> +TUNE_FEATURES_tune-armv8-a-crypto = "${TUNE_FEATURES_tune-armv8-a} crypto"
>>> +
>>> +PACKAGE_EXTRA_ARCHS_tune-armv8-a = "aarch64 armv8-a"
>>> +PACKAGE_EXTRA_ARCHS_tune-armv8-a-crypto = 
>>> "${PACKAGE_EXTRA_ARCHS_tune-armv8-a} armv8-a-crypto"
>>> +
>>> +BASE_LIB_tune-armv8-a = "${BASE_LIB_tune-aarch64}"
>>> +BASE_LIB_tune-armv8-a-crypto = "${BASE_LIB_tune-aarch64}"
>>>
> 

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

Re: [OE-core] [PATCH v2] autoconf: fix mistakes in SUMMARY and DESCRIPTION

[Denys Dmytriyenko]

On Fri, Jul 28, 2017 at 04:47:40PM -0700, Andre McCurdy wrote:
> On Fri, Jul 28, 2017 at 1:26 PM, Denys Dmytriyenko  wrote:
> > From: Denys Dmytriyenko 
> >
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> > v1 - procude -> produce
> > v2 - produce -> produces
> >
> >  meta/recipes-devtools/autoconf/autoconf.inc | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/autoconf/autoconf.inc 
> > b/meta/recipes-devtools/autoconf/autoconf.inc
> > index f1b2dfc..17ee50f 100644
> > --- a/meta/recipes-devtools/autoconf/autoconf.inc
> > +++ b/meta/recipes-devtools/autoconf/autoconf.inc
> > @@ -1,5 +1,5 @@
> > -SUMMARY = "A GNU tool that procude shell scripts to automatically 
> > configure software"
> > -DESCRIPTION = "Autoconf is an extensible package of M4 macros that produce 
> > shell scripts to automatically \
> > +SUMMARY = "A GNU tool that produces shell scripts to automatically 
> > configure software"
> > +DESCRIPTION = "Autoconf is an extensible package of M4 macros that 
> > produces shell scripts to automatically \
> 
> The DESCRIPTION was correct originally (since it's the M4 macros which
> produce the shell scripts, not the extensible package).
> 
> https://www.gnu.org/software/autoconf/autoconf.html

Good thing Richard picked up v1 of the patch then! :)


> >  configure software source code packages. Autoconf creates a configuration 
> > script for a package from a template \
> >  file that lists the operating system features that the package can use, in 
> > the form of M4 macro calls."
> >  LICENSE = "GPLv3"
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] armv8: update to use armv8-a tune

[akuster808]

On 07/31/2017 10:31 AM, Mark Hatle wrote:

On 7/31/17 12:16 PM, Armin Kuster wrote:

Signed-off-by: Armin Kuster 
---
  meta/conf/machine/include/arm/arch-armv8.inc | 25 +
  1 file changed, 25 insertions(+)

diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
b/meta/conf/machine/include/arm/arch-armv8.inc
index 5e832fa..dc1ba5e 100644
--- a/meta/conf/machine/include/arm/arch-armv8.inc
+++ b/meta/conf/machine/include/arm/arch-armv8.inc
@@ -1 +1,26 @@
+DEFAULTTUNE ?= "armv8-a"

do we want the '-a'?  The other arm (7) are of the format armv7a (no '-').

works for me either way.

While we are at it. How would we want ‘armv8.1-a’, ‘armv8.2-a’, 
‘armv8.3-a' formated as?


- armin


--Mark


+
+TUNEVALID[armv8-a] = "Enable instructions for ARMv8-a"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', ' -march=armv8-a', 
'', d)}"
+
+TUNEVALID[crypto] = "Enable crypto instructions for ARMv8-a"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto', '', 
d)}"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', 'armv8a:', '' 
,d)}"
+
  require conf/machine/include/arm/arch-arm64.inc
+
+AVAILTUNES += "armv8-a armv8-a-crypto"
+ARMPKGARCH_tune-armv8-a ?= "armv8-a"
+
+# Enable Crypto extension. This also enables Advanced SIMD and floating-point 
instructions
+ARMPKGARCH_tune-armv8-a-crypto ?= "armv8-a"
+
+TUNE_FEATURES_tune-armv8-a = "aarch64 armv8-a"
+TUNE_FEATURES_tune-armv8-a-crypto = "${TUNE_FEATURES_tune-armv8-a} crypto"
+
+PACKAGE_EXTRA_ARCHS_tune-armv8-a = "aarch64 armv8-a"
+PACKAGE_EXTRA_ARCHS_tune-armv8-a-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8-a} 
armv8-a-crypto"
+
+BASE_LIB_tune-armv8-a = "${BASE_LIB_tune-aarch64}"
+BASE_LIB_tune-armv8-a-crypto = "${BASE_LIB_tune-aarch64}"



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

Re: [OE-core] [PATCH 1/2] armv8: update to use armv8-a tune

[Mark Hatle]

On 7/31/17 12:16 PM, Armin Kuster wrote:
> Signed-off-by: Armin Kuster 
> ---
>  meta/conf/machine/include/arm/arch-armv8.inc | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
> b/meta/conf/machine/include/arm/arch-armv8.inc
> index 5e832fa..dc1ba5e 100644
> --- a/meta/conf/machine/include/arm/arch-armv8.inc
> +++ b/meta/conf/machine/include/arm/arch-armv8.inc
> @@ -1 +1,26 @@
> +DEFAULTTUNE ?= "armv8-a"

do we want the '-a'?  The other arm (7) are of the format armv7a (no '-').

--Mark

> +
> +TUNEVALID[armv8-a] = "Enable instructions for ARMv8-a"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', ' 
> -march=armv8-a', '', d)}"
> +
> +TUNEVALID[crypto] = "Enable crypto instructions for ARMv8-a"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto', 
> '', d)}"
> +
> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', 
> 'armv8a:', '' ,d)}"
> +
>  require conf/machine/include/arm/arch-arm64.inc
> +
> +AVAILTUNES += "armv8-a armv8-a-crypto"
> +ARMPKGARCH_tune-armv8-a ?= "armv8-a"
> +
> +# Enable Crypto extension. This also enables Advanced SIMD and 
> floating-point instructions
> +ARMPKGARCH_tune-armv8-a-crypto ?= "armv8-a"
> +
> +TUNE_FEATURES_tune-armv8-a = "aarch64 armv8-a"
> +TUNE_FEATURES_tune-armv8-a-crypto = "${TUNE_FEATURES_tune-armv8-a} crypto"
> +
> +PACKAGE_EXTRA_ARCHS_tune-armv8-a = "aarch64 armv8-a"
> +PACKAGE_EXTRA_ARCHS_tune-armv8-a-crypto = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8-a} armv8-a-crypto"
> +
> +BASE_LIB_tune-armv8-a = "${BASE_LIB_tune-aarch64}"
> +BASE_LIB_tune-armv8-a-crypto = "${BASE_LIB_tune-aarch64}"
> 

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

[OE-core] ✗ patchtest: failure for Update armv8 tune file

[Patchwork]

== Series Details ==

Series: Update armv8 tune file
Revision: 1
URL   : https://patchwork.openembedded.org/series/8041/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[2/2] new tune: add base cortexa53 support
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH 2/2] new tune: add base cortexa53 support

[Armin Kuster]

---
 meta/conf/machine/include/tune-cortexa53.inc | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
new file mode 100644
index 000..557f43d
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -0,0 +1,18 @@
+DEFAULTTUNE ?= "armv8-a"
+
+TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' 
-mcpu=cortex-a53', '', d)}"
+
+require conf/machine/include/arm/arch-armv8.inc
+
+ARMPKGARCH_tune-cortexa53  = "cortexa53"
+ARMPKGARCH_tune-cortexa53-crypto   = "cortexa53"
+
+TUNE_FEATURES_tune-cortexa53   = "aarch64 armv8-a cortexa53"
+TUNE_FEATURES_tune-cortexa53-crypto= "${TUNE_FEATURES_tune-cortexa53} 
crypto"
+
+PACKAGE_EXTRA_ARCHS_tune-cortexa53 = "aarch64 armv8-a cortexa53"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-cortexa53} cortexa53-crypto"
+
+BASE_LIB_tune-cortexa53 = "${BASE_LIB_tune-aarch64}"
+BASE_LIB_tune-cortexa53-crypto = "${BASE_LIB_tune-aarch64}"
-- 
2.5.0

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

[OE-core] [PATCH 1/2] armv8: update to use armv8-a tune

[Armin Kuster]

Signed-off-by: Armin Kuster 
---
 meta/conf/machine/include/arm/arch-armv8.inc | 25 +
 1 file changed, 25 insertions(+)

diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
b/meta/conf/machine/include/arm/arch-armv8.inc
index 5e832fa..dc1ba5e 100644
--- a/meta/conf/machine/include/arm/arch-armv8.inc
+++ b/meta/conf/machine/include/arm/arch-armv8.inc
@@ -1 +1,26 @@
+DEFAULTTUNE ?= "armv8-a"
+
+TUNEVALID[armv8-a] = "Enable instructions for ARMv8-a"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', ' 
-march=armv8-a', '', d)}"
+
+TUNEVALID[crypto] = "Enable crypto instructions for ARMv8-a"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto', '', 
d)}"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8-a', 
'armv8a:', '' ,d)}"
+
 require conf/machine/include/arm/arch-arm64.inc
+
+AVAILTUNES += "armv8-a armv8-a-crypto"
+ARMPKGARCH_tune-armv8-a ?= "armv8-a"
+
+# Enable Crypto extension. This also enables Advanced SIMD and floating-point 
instructions
+ARMPKGARCH_tune-armv8-a-crypto ?= "armv8-a"
+
+TUNE_FEATURES_tune-armv8-a = "aarch64 armv8-a"
+TUNE_FEATURES_tune-armv8-a-crypto = "${TUNE_FEATURES_tune-armv8-a} crypto"
+
+PACKAGE_EXTRA_ARCHS_tune-armv8-a = "aarch64 armv8-a"
+PACKAGE_EXTRA_ARCHS_tune-armv8-a-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8-a} 
armv8-a-crypto"
+
+BASE_LIB_tune-armv8-a = "${BASE_LIB_tune-aarch64}"
+BASE_LIB_tune-armv8-a-crypto = "${BASE_LIB_tune-aarch64}"
-- 
2.5.0

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

[OE-core] [PATCH 0/2] Update armv8 tune file

[Armin Kuster]

This extends arch-armv8 support to enable armv8-a and crypto.

Add cortexa53 framework.

Boot tested on Odroid-c2 (cortexa53)

Armin Kuster (2):
  armv8: update to use armv8-a tune
  new tune: add base cortexa53 support

 meta/conf/machine/include/arm/arch-armv8.inc | 25 +
 meta/conf/machine/include/tune-cortexa53.inc | 18 ++
 2 files changed, 43 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.5.0

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

Re: [OE-core] [PATCH] cml1.bbclass: wait until menuconfig terminal finishes

[Saul Wold]

On Thu, 2017-07-27 at 18:54 -0700,
leonardo.sandoval.gonza...@linux.intel.com wrote:
> From: Leonardo Sandoval 
> 
> There are at least two terminals types (gnome and tmux) that when
> launched to show the kernel's menuconfig, we lost track of the
> corresponding
> process ID, thus there is no way to see when they finish, yielding
> identical
> timestamps before and after menuconfig thus compile's task
> is never tainted. This commit takes the solution from [1] but now in
> the menuconfig's
> context.
> 
I am not sure that this should be specific to the menuconfig code, as
this will affect devshell also or if you enable dropping into shell for
patch fixing.

Please generalize the code in meta/lib/oe/terminal.py that gnome uses
to be useful by any terminal type.

Sau!


> [1]
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c706bfbabbf
> 9f7caf2cf509eb91381fb49aa44cb
> 
> [YOCTO #11146]
> 
> Signed-off-by: Leonardo Sandoval  tel.com>
> ---
>  meta/classes/cml1.bbclass | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
> index 38e6613c48..1e84795aa2 100644
> --- a/meta/classes/cml1.bbclass
> +++ b/meta/classes/cml1.bbclass
> @@ -26,8 +26,28 @@ python do_menuconfig() {
>  except OSError:
>  mtime = 0
>  
> -oe_terminal("${SHELL} -c \"make %s; if [ \$? -ne 0 ]; then echo
> 'Command failed.'; printf 'Press any key to continue... '; read r;
> fi\"" % d.getVar('KCONFIG_CONFIG_COMMAND'),
> +# We need to know when the command completes but some terminals
> (including gnome-terminal
> +# and tmux) gives us no way to do this. We therefore write the
> pid to a temporal file
> +# then monitor the pid until it exits.
> +import tempfile
> +pidfile = tempfile.NamedTemporaryFile(delete = False).name
> +try:
> +oe_terminal("${SHELL} -c \"echo $$ > %s; make %s; if [ \$?
> -ne 0 ]; then echo 'Command failed.'; printf 'Press any key to
> continue... '; read r; fi\"" % (pidfile,
> d.getVar('KCONFIG_CONFIG_COMMAND')),
>  d.getVar('PN') + ' Configuration', d)
> +while os.stat(pidfile).st_size <= 0:
> +continue
> +with open(pidfile, "r") as f:
> +pid = int(f.readline())
> +finally:
> +os.unlink(pidfile)
> +
> +import time
> +while True:
> +try:
> +os.kill(pid, 0)
> +time.sleep(0.1)
> +except OSError:
> +break
>  
>  # FIXME this check can be removed when the minimum bitbake
> version has been bumped
>  if hasattr(bb.build, 'write_taint'):
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] multiconfig.py: added testsuite for multiconfig

[Ibarra Lopez, Humberto]

This patch does not consider current multiconfig settings. I talked with Anibal 
about this and he said this wouldn't be an issue after #11429, which he is 
working on. Just checked that bug and is still in implementation, so I could 
put 11429 as a dependency for 11612?

Regards,

Humberto 

-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] 
Sent: Thursday, July 27, 2017 4:12 PM
To: Ibarra Lopez, Humberto ; 
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 1/1] multiconfig.py: added testsuite for 
multiconfig

On Thu, 2017-07-27 at 15:18 -0500, Humberto Ibarra wrote:
> Multiconfig was not being tested at all. This adds a few basic tests 
> for multiconfig, including globbing.
> 
> [Yocto #11612]
> 
> Signed-off-by: Humberto Ibarra 

If I run this selftest and I have some multiconfigs already in my build 
directory, what happens to them?

Cheers,

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

Re: [OE-core] [PATCH v3 1/2] autoconf-archive: move from meta-oe to OE-core

[Burton, Ross]

v2 made it into master, can you send just the fix?

Ross

On 31 July 2017 at 15:56, Patrick Ohly  wrote:

> Having common macros in OE-core that are needed by autotools based
> projects makes sense. For example, tpm2.0-tools in meta-measured
> depended on meta-oe only because of autoconf-archive.
>
> This is a verbatim copy of the autoconf-archive recipe in
> meta-openembedded rev 1cbd1bc1, with just one change: the patch which
> disabled the installation of ax_code_coverage.m4 and
> ax_check_enable_debug.m4 and the dependency on gnome-common were
> removed.
>
> So now autoconf-archive in OE-core provides them. gnome-common in
> meta-oe will be changed to not install them and instead depend on
> autoconf-archive.
>
> Signed-off-by: Patrick Ohly 
> ---
>  meta/recipes-devtools/autoconf-archive/autoconf-archive.inc   |
> 13 +
>  meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb |
> 13 +
>  2 files changed, 26 insertions(+)
>  create mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-
> archive.inc
>  create mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-
> archive_2016.09.16.bb
>
> diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
> b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
> new file mode 100644
> index 000..4f63e0f
> --- /dev/null
> +++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
> @@ -0,0 +1,13 @@
> +LICENSE = "GPLv3"
> +HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/;
> +SECTION = "devel"
> +
> +DEPENDS += "m4-native"
> +DEPENDS_class-native = "m4-native gnu-config-native"
> +DEPENDS_class-nativesdk = "m4-nativesdk gnu-config-nativesdk"
> +
> +RDEPENDS_${PN} = "m4 gnu-config"
> +
> +SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
> +
> +inherit autotools
> diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-
> archive_2016.09.16.bb b/meta/recipes-devtools/autoconf-archive/autoconf-
> archive_2016.09.16.bb
> new file mode 100644
> index 000..0a1a771
> --- /dev/null
> +++ b/meta/recipes-devtools/autoconf-archive/autoconf-
> archive_2016.09.16.bb
> @@ -0,0 +1,13 @@
> +require autoconf-archive.inc
> +
> +
> +PARALLEL_MAKE = ""
> +
> +LICENSE = "GPLv2 & GPLv3"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> +
> +SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
> +SRC_URI[sha256sum] = "e8f2efd235f842bad2f6938bf4a722
> 40a5e5fcd248e8444335e63beb60fabd82"
> +
> +EXTRA_OECONF += "ac_cv_path_M4=m4"
> +BBCLASSEXTEND = "native nativesdk"
> --
> git-series 0.9.1
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 05/11] gperf: upgrade to 3.1

[Burton, Ross]

On 31 July 2017 at 10:43, Richard Purdie  wrote:

> It does feel like upstream screwed up and should really sort this out.
> Do you know what upstream plan to do (if anything)?
>

Upstream fixed a problem and whilst it was way to big a change for a point
release the code is probably "better" now.  It just breaks everything, and
you can't even be compatible with both versions.

For what its worth, systemd added a check for the argument type in
configure.ac[1] (and now meson) but also just demands 3.1, presumably for
the new options.

Ross

[1]
https://github.com/systemd/systemd/commit/c9f7b4d356a453a01aa77a6bb74ca7ef49732c08
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for move autoconf-archive into OE-core (rev2)

[Patchwork]

== Series Details ==

Series: move autoconf-archive into OE-core (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/8001/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at da29bc17e4)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

Re: [OE-core] [PATCH 05/11] gperf: upgrade to 3.1

[Khem Raj]

On Mon, Jul 31, 2017 at 7:55 AM, Burton, Ross  wrote:
> Neither Debian not Fedora rebuild dependencies, you'll see a lot of
> "rebuild" changelog entries where API changes demanded it to happen.
>
> Our builds take longer but you know the build always works.  Their builds
> may be broken without anyone noticing for a while.
>
> Ross
>
> On 31 July 2017 at 11:18, Alexander Kanavin
>  wrote:
>>
>> On 07/31/2017 12:53 PM, Alexander Kanavin wrote:
>>>
>>> The only thing I found was this email:
>>> http://lists.gnu.org/archive/html/bug-gperf/2017-01/msg4.html
>>> which was ignored by upstream.
>>>
>>> However, both debian testing and fedora rawhide have gperf 3.1, so I'm
>>> not sure how they made it work. I'm running debian here, so can look into
>>> this.
>>
>>
>> Right. Debian dropped the updated gperf package into repositories, but did
>> not rebuild anything that relies on it. When I tried that with libcap, I got
>> the exact same error as we've seen.

they do mass rebuilds but thats not like us where we build it daily.

>>
>> Not sure what's going to happen when they discover the incompatibility.
>> I'm a bit surprised they don't do such dependency rebuilds when changes are
>> introduced.
>>
>> Alex
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 1/2] autoconf-archive: move from meta-oe to OE-core

[Patrick Ohly]

Having common macros in OE-core that are needed by autotools based
projects makes sense. For example, tpm2.0-tools in meta-measured
depended on meta-oe only because of autoconf-archive.

This is a verbatim copy of the autoconf-archive recipe in
meta-openembedded rev 1cbd1bc1, with just one change: the patch which
disabled the installation of ax_code_coverage.m4 and
ax_check_enable_debug.m4 and the dependency on gnome-common were
removed.

So now autoconf-archive in OE-core provides them. gnome-common in
meta-oe will be changed to not install them and instead depend on
autoconf-archive.

Signed-off-by: Patrick Ohly 
---
 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc   | 13 
+
 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 13 
+
 2 files changed, 26 insertions(+)
 create mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
 create mode 100644 
meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb

diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc 
b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
new file mode 100644
index 000..4f63e0f
--- /dev/null
+++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
@@ -0,0 +1,13 @@
+LICENSE = "GPLv3"
+HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/;
+SECTION = "devel"
+
+DEPENDS += "m4-native"
+DEPENDS_class-native = "m4-native gnu-config-native"
+DEPENDS_class-nativesdk = "m4-nativesdk gnu-config-nativesdk"
+
+RDEPENDS_${PN} = "m4 gnu-config"
+
+SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
+
+inherit autotools
diff --git 
a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb 
b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
new file mode 100644
index 000..0a1a771
--- /dev/null
+++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
@@ -0,0 +1,13 @@
+require autoconf-archive.inc
+
+
+PARALLEL_MAKE = ""
+
+LICENSE = "GPLv2 & GPLv3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
+
+SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
+SRC_URI[sha256sum] = 
"e8f2efd235f842bad2f6938bf4a72240a5e5fcd248e8444335e63beb60fabd82"
+
+EXTRA_OECONF += "ac_cv_path_M4=m4"
+BBCLASSEXTEND = "native nativesdk"
-- 
git-series 0.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 2/2] autoconf-archive: simplify and fix recipe

[Patrick Ohly]

The COPYING file specifies pure GPLv3, not GPLv2 & GPLv3, with the
autoconf exception in COPYING.EXCEPTION. OE-core currently has
GPL-3.0-with-GCC-exception for this in meta/conf/licenses.conf, so
this is used here despite the deprecation note for that license
identifier in https://spdx.org/licenses/GPL-3.0-with-autoconf-exception.

All of the explicit dependencies seem unnecessary, and RDEPENDS_${PN}
doesn't do anything for native recipes either, so all of that gets
removed.

It also built fine without the m4 and parallel build workarounds.

There's no need to have a separate .inc file.

Signed-off-by: Patrick Ohly 
---
 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc   | 13 
-
 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 19 
++-
 2 files changed, 10 insertions(+), 22 deletions(-)
 delete mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc

diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc 
b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
deleted file mode 100644
index 4f63e0f..000
--- a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
+++ /dev/null
@@ -1,13 +0,0 @@
-LICENSE = "GPLv3"
-HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/;
-SECTION = "devel"
-
-DEPENDS += "m4-native"
-DEPENDS_class-native = "m4-native gnu-config-native"
-DEPENDS_class-nativesdk = "m4-nativesdk gnu-config-nativesdk"
-
-RDEPENDS_${PN} = "m4 gnu-config"
-
-SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
-
-inherit autotools
diff --git 
a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb 
b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
index 0a1a771..104dc38 100644
--- a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
+++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
@@ -1,13 +1,14 @@
-require autoconf-archive.inc
-
-
-PARALLEL_MAKE = ""
-
-LICENSE = "GPLv2 & GPLv3"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
-
+SUMMARY = "a collection of freely re-usable Autoconf macros"
+HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/;
+SECTION = "devel"
+LICENSE = "GPL-3.0-with-autoconf-exception"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.EXCEPTION;md5=fdef168ebff3bc2f13664c365a5fb515"
+
+SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
 SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
 SRC_URI[sha256sum] = 
"e8f2efd235f842bad2f6938bf4a72240a5e5fcd248e8444335e63beb60fabd82"
 
-EXTRA_OECONF += "ac_cv_path_M4=m4"
+inherit autotools
+
 BBCLASSEXTEND = "native nativesdk"
-- 
git-series 0.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 0/2] move autoconf-archive into OE-core

[Patrick Ohly]

V2:
 - removed the gnome-common dependency that was still in V1
 - merged the .inc file into the .bb file and cleaned up the recipe

V3:
 - LICENSE = "GPL-3.0-with-autoconf-exception"

Patrick Ohly (2):
  autoconf-archive: move from meta-oe to OE-core
  autoconf-archive: simplify and fix recipe

 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 14 
++
 1 file changed, 14 insertions(+)
 create mode 100644 
meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb

base-commit: d3a41fbd94462efc8c6f1b55f6fb54001b447c45
-- 
git-series 0.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 05/11] gperf: upgrade to 3.1

[Burton, Ross]

Neither Debian not Fedora rebuild dependencies, you'll see a lot of
"rebuild" changelog entries where API changes demanded it to happen.

Our builds take longer but you know the build always works.  Their builds
may be broken without anyone noticing for a while.

Ross

On 31 July 2017 at 11:18, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 07/31/2017 12:53 PM, Alexander Kanavin wrote:
>
>> The only thing I found was this email:
>> http://lists.gnu.org/archive/html/bug-gperf/2017-01/msg4.html
>> which was ignored by upstream.
>>
>> However, both debian testing and fedora rawhide have gperf 3.1, so I'm
>> not sure how they made it work. I'm running debian here, so can look into
>> this.
>>
>
> Right. Debian dropped the updated gperf package into repositories, but did
> not rebuild anything that relies on it. When I tried that with libcap, I
> got the exact same error as we've seen.
>
> Not sure what's going to happen when they discover the incompatibility.
> I'm a bit surprised they don't do such dependency rebuilds when changes are
> introduced.
>
> Alex
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] re2c: fix build race

[Ross Burton]

Signed-off-by: Ross Burton 
---
 meta/recipes-support/re2c/re2c/mkdir.patch | 28 
 meta/recipes-support/re2c/re2c_0.16.bb |  2 +-
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-support/re2c/re2c/mkdir.patch

diff --git a/meta/recipes-support/re2c/re2c/mkdir.patch 
b/meta/recipes-support/re2c/re2c/mkdir.patch
new file mode 100644
index 000..da582942dd7
--- /dev/null
+++ b/meta/recipes-support/re2c/re2c/mkdir.patch
@@ -0,0 +1,28 @@
+Upstream-Status: Submitted (https://github.com/skvadrik/re2c/pull/191)
+Signed-off-by: Ross Burton 
+
+From bccc10c60523f88c8f81413151cdcd612eb16198 Mon Sep 17 00:00:00 2001
+From: Ross Burton 
+Date: Mon, 31 Jul 2017 15:43:41 +0100
+Subject: [PATCH] Makefile.am: create target directory before writing into it
+
+In some situations src/parse/ may not exist before a file is copied into the
+directory. Ensure that this doesn't happen by creating the directory first.
+---
+ re2c/Makefile.am | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/re2c/Makefile.am b/re2c/Makefile.am
+index 3b3b2c5e..2ff58c19 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -211,6 +211,7 @@ $(BOOTSTRAP_PARSER): $(CUSTOM_PARSER)
+   $(top_srcdir)/$(CUSTOM_PARSER);
+ 
+ .re.cc:
++  $(AM_V_at)$(MKDIR_P) $(dir $@)
+   $(AM_V_GEN) if test -x $(RE2C); \
+   then \
+   $(top_builddir)/$(RE2C) $(RE2CFLAGS) -o $@ $< && \
+-- 
+2.11.0
diff --git a/meta/recipes-support/re2c/re2c_0.16.bb 
b/meta/recipes-support/re2c/re2c_0.16.bb
index e82502c5f2d..50dd7b7d261 100644
--- a/meta/recipes-support/re2c/re2c_0.16.bb
+++ b/meta/recipes-support/re2c/re2c_0.16.bb
@@ -6,7 +6,7 @@ LICENSE = "PD"
 LIC_FILES_CHKSUM = 
"file://README;beginline=146;md5=881056c9add17f8019ccd8c382ba963a"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz \
-"
+   file://mkdir.patch"
 SRC_URI[md5sum] = "3bf508fabd52ed7334647d0ccb956e8d"
 SRC_URI[sha256sum] = 
"48c12564297641cceb5ff05aead57f28118db6277f31e2262437feba89069e84"
 
-- 
2.11.0

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

[OE-core] Yocto Project Status WW31’17

[Jolley, Stephen K]

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

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


SWAT team rotation: Armin -> Saul on July 28, 2017.

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

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


Key Status/Updates:

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

·A good set of updates have been merged into pyro in preparation for 
2.3.2 (thanks Armin!)

·Some key bugfixes for the bitbake server rework were merged. These 
should handle cases where the server errors early on in startup much better in 
ways where the user can see what the issue is. Cleanups to various timeout 
loops and messages were also made. If people are seeing issues with the bitbake 
server rework please do report them as the currently known issues have all be 
fixed as of master today.

·Llvm merged into OE-Core along with mesa support for llvmpipe. The 
mesa support is not currently enabled by default.

·There have been some good changes to the image vm generation and 
compression chaining code which significantly cleaned up the code (and improved 
test coverage, thanks!). These may have some user visible effects so it's worth 
being aware of.

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


Planned upcoming dot releases:

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

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Aug 28, 2017

YP 2.3.2 Release by Sept. 8, 2017


Key YP 2.4 Dates are:

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

YP 2.4 M2 Release by July 28, 2017

YP 2.4 M3 Cut off is Aug. 21, 2017

YP 2.4 M3 Release by Sept. 1, 2017

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

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


Tracking Metrics:

WDD 2556 (last week 2488)

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


Key Status Links for YP:

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

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

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


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

Thanks,

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

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

Re: [OE-core] [PATCH 0/1] python-3.5-manifest: move python3.5-config script into the dev package

[Sandoval Gonzalez, Leonardo]

El 7/29/2017 a las 8:48 AM, Burton, Ross escribió:

The first line of the python-3.5-manifest.inc:

# WARNING: This file is AUTO GENERATED: Manual edits will be lost next 
time I regenerate the file.


You'll need to edit the script and then regenerate the manifest.

Auch, right.

I will send a v2 including the line truncation fix.

Leo


Might be worth patching the script to wrap long lines instead of 
writing 1000 character lines to save the line length problem in the 
future too.


Ross

On 24 July 2017 at 17:44, > wrote:


From: Leonardo Sandoval
>

The following changes since commit
a4f2bf37b7eac888f37f11cd4d4606436909c507:

  mpc8315e-rdb: add wic.bmap to IMAGE_FSTYPES (2017-07-17 15:14:27
+0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib

lsandov1/python3-config-multilib

http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lsandov1/python3-config-multilib



Leonardo Sandoval (1):
  python-3.5-manifest: move python3.5-config script into the dev
package

 meta/recipes-devtools/python/python-3.5-manifest.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--
2.12.3

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core





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

Re: [OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[Maxin B. John]

Hi,
On Mon, Jul 31, 2017 at 03:50:17PM +0300, Maxin B. John wrote:
> Hi,
> 
> On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpj...@crashcourse.ca wrote:
> > 

> > 
> >   well, here's a possible conundrum ... in that same package (i2c-tools),
> > there appears to be an *obvious* flaw in that the "eeprog" utility uses a
> > sleep that is far too short for proper operation, as described here:
> > 
> > https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html
> > 
> > there is a link to a patch on that page that simply cranks up a few sleep
> > calls from 10usec to 5msec, which apparently solves the problem. i've been
> > involved in a discussion on the i2c-tools mailing list about this very
> > issue after i tripped over it, but there seems to be little enthusiasm on
> > that list for "fixing" this -- i was told that people use the kernel driver
> > instead and access via /sys rather than calling "eeprog".
> 
> dl.lm-sensors.org has been down for a while and doesn't show any positive 
> signs that
> it will be back in near future. One possibility will be to use the unofficial 
> mirrors
> listed below and upgrade to version 3.1.2

Sorry, I meant to use the most recent version (we already have the latest 
released verion - 3.1.2) 

> 1. https://fossies.org/linux/misc/
> 2. http://jdelvare.nerim.net/mirror/i2c-tools/
> 
> >   so, from my perspective, this should definitely be fixed so that "eeprog"
> > functions properly, but it's not clear upstream is all that interested in 
> > it.
> > what would the protocol be here?
> 
> Since this genuinely fixes an error, we should be able to include this patch 
> with:
> "Inappropriate [bug workaround]" status. 
> 
> > rday
> 
> Best Regards,
> Maxin
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Chaining compression support fixes for morty / pyro

[Tom Rini]

Hi Armin,

The following changes in master are relevant to both morty and pyro:

commit 0a7ce0b971a208956cb895ba5a869ec8c5d94703
Author: Tom Rini 
Date:   Fri Jul 21 18:06:33 2017 -0400

image.bbclass: Correct chaining compression support

commit 98a2afeb3a53bec7a72a4a9846e1dba636cc6f3d
Author: Tom Rini 
Date:   Tue Jul 25 15:58:09 2017 -0400

image: Fix "metadata is not deterministic" when chaining 2+ CONVERSION_CMDs

And fix the problem where you cannot make arbitrary combinations of say
"ext4", "u-boot" and "xz" images.  In the interest of full disclosure,
it is entirely possible that there are image types introduces in other
layers that have the same problem that the "u-boot" type had which lead
to 46bc438374de being done in the first place, which is to say a new
IMAGE_CMD that also cleaned up the intermediate files on its own.  This
may make this too risky to pull into stable branches and that's fine.
Thanks for your consideration!

-- 
Tom


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

Re: [OE-core] [PATCH 00/10] Revive ptest and add result to buildhistory

[Paul Eggleton]

On Monday, 31 July 2017 11:50:00 AM CEST Robert Yang wrote:
> We can get the regression result by:
> $ git show HEAD ptest_log/pass.fail.skip.*
> 
> Can we add ptest to default TEST_SUITES, please ?

Is it possible to get an idea of the time impact if we did so?

Cheers,
Paul

-- 

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

Re: [OE-core] [PATCH 02/10] runtime/cases/_ptest.py: revive it

[Paul Eggleton]

On Monday, 31 July 2017 11:50:02 AM CEST Robert Yang wrote:
> * Will write a tool to make regression check

This commit doesn't do this and it's not completely covered by the rest of the 
series. I think you could say perhaps more appropriately "This provides data 
that could be used to detect regressions in ptest results" or similar assuming 
you need to mention it at all.

Cheers,
Paul

-- 

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

Re: [OE-core] [PATCH 09/10] buildhistory.bbclass: add ptest_log

[Paul Eggleton]

Hi Robert,

A few minor comments below.

On Monday, 31 July 2017 11:50:09 AM CEST Robert Yang wrote:
> The ptest log will be saved to buildhistory/ptest_log, we can easily get
> the regression result between builds by:
> $ git show HEAD ptest_log/pass.fail.skip.*
> 
> [YOCTO #11547]
> 
> Signed-off-by: Robert Yang 
> ---
>  meta/classes/buildhistory.bbclass | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/meta/classes/buildhistory.bbclass b/meta/classes/
buildhistory.bbclass
> index a3e4c7a734a..26430a63d31 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -912,3 +912,31 @@ def write_latest_srcrev(d, pkghistdir):
>  else:
>  if os.path.exists(srcrevfile):
>  os.remove(srcrevfile)
> +
> +do_testimage[postfuncs] += "write_ptest_result"
> +do_testimage[vardepsexclude] += "write_ptest_result"
> +
> +python write_ptest_result() {
> +write_latest_ptest_result(d, d.getVar('BUILDHISTORY_DIR'))
> +}
> +
> +def write_latest_ptest_result(d, histdir):
> +import glob
> +import subprocess
> +test_log_dir = d.getVar('TEST_LOG_DIR')
> +input_ptest_log = os.path.join(test_log_dir, 'ptest_log')
> +output_ptest_log = os.path.join(histdir, 'ptest_log')

Would it be reasonable for this to just be "ptest"? To ask the question a 
different way, would you expect to save other types of ptest information into 
buildhistory, or is this likely to be it?

> +if os.path.exists(input_ptest_log):
> +# Lock it avoid race issue
> +lock = bb.utils.lockfile(output_ptest_log + "/ptest_log.lock")
> +bb.utils.mkdirhier(output_ptest_log)
> +oe.path.copytree(input_ptest_log, output_ptest_log)
> +# Sort test result
> +for result in glob.glob('%s/pass.fail.*' % output_ptest_log):
> +bb.debug(1, 'Processing %s' % result)
> +cmd = "sort %s -o %s" % (result, result)
> +bb.debug(1, 'Running %s' % cmd)
> +ret = subprocess.call(cmd, shell=True)

As a matter of good practice and since it's easy to do here I'd suggest not 
using shell=True and passing the command as a list instead, that way there 
can't be any issues with spaces or other shell interpretations.

> +if ret != 0:
> +bb.error('Failed to run %s!' % cmd)
> +bb.utils.unlockfile(lock)

Shouldn't you be using try...finally here to ensure the lockfile gets unlocked 
in the case of exceptions?

Cheers,
Paul


-- 

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

[OE-core] [PATCH] qemux86 qemux86-64: Enable pci

[zhe.he]

From: He Zhe 

lspci and some other software require "pci" in MACHINE_FEATURES and PCI
is valid in the qemux86* context.

Signed-off-by: He Zhe 
---
 meta/conf/machine/qemux86-64.conf | 2 +-
 meta/conf/machine/qemux86.conf| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/qemux86-64.conf 
b/meta/conf/machine/qemux86-64.conf
index 4f30033..9f78191 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -28,7 +28,7 @@ XSERVER = "xserver-xorg \
xserver-xorg-module-libint10 \
"
 
-MACHINE_FEATURES += "x86"
+MACHINE_FEATURES += "x86 pci"
 
 MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
 
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index e232947..d778fa7 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -27,7 +27,7 @@ XSERVER = "xserver-xorg \
xserver-xorg-module-libint10 \
"
 
-MACHINE_FEATURES += "x86"
+MACHINE_FEATURES += "x86 pci"
 
 MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
 
-- 
2.8.1

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

Re: [OE-core] [PATCH] documentation: Remove documentation of image_types_uboot.

[Burton, Ross]

On 30 July 2017 at 01:17, Tom Rini  wrote:

> > diff --git a/meta-poky/conf/local.conf.sample.extended
> b/meta-poky/conf/local.conf.sample.extended
> > index 0560de8..331fdd1 100644
> > --- a/meta-poky/conf/local.conf.sample.extended
> > +++ b/meta-poky/conf/local.conf.sample.extended
> > @@ -168,9 +168,6 @@
> >
> >  # Additional image generation features
> >  #
> > -# The following is a list of classes to import to use in the generation
> of images
> > -# currently an example class is image_types_uboot
> > -# IMAGE_CLASSES = " image_types_uboot"
> >
> >  # The following options will build a companion 'debug filesystem' in
> addition
> >  # to the normal deployable filesystem.  This companion system allows a
>
> This is poky-centric and still applicable however.  Thanks!


 Can you resend this fragment to the poky list with a suitable commit
message please?

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

Re: [OE-core] [PATCH V2] meta: drop do_bootdirectdisk do_vmimg references

[Ming Liu]

> And there's no references to image_type_uboot.bbclass left, either, yes?

Yes, just double checked, there is no references to image_type_uboot.

//Ming Liu

2017-07-31 14:50 GMT+02:00 Tom Rini :

> On Mon, Jul 31, 2017 at 10:56:28AM +0200, liu.min...@gmail.com wrote:
>
> > From: Ming Liu 
> >
> > do_bootdirectdisk and do_vmimg had been dropped by commit 929ba563:
> > [ image: Convert vmdk/vdi/qcow2 to strict CONVERSION_CMD types ]
> >
> > Also drop the references to them and image-vm.
> >
> > Signed-off-by: Ming Liu 
>
> And there's no references to image_type_uboot.bbclass left, either, yes?
> If so:
>
> Reviewed-by: Tom Rini 
>
> Thanks!
>
> --
> Tom
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[Maxin B. John]

Hi,

On Mon, Jul 31, 2017 at 07:15:23AM -0400, rpj...@crashcourse.ca wrote:
> 
> Quoting Richard Purdie :
> 
> >On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
> >>On 07/31/2017 01:41 PM, rpj...@crashcourse.ca wrote:
> >>>
> >>>
> >>>    given that some significant changes have been made to i2c-tools
> >>> since
> >>> version 3.1.2, is it worth adding a git-versioned recipe of that
> >>> to 
> >>> oe-core,
> >>> and using DEFAULT_PREFERENCE to force people to select it if they
> >>> want it?
> >>> in particular, the code base has been restructured, and a new
> >>> utility,
> >>> "i2ctransfer", has been added.
> >>It's better to ask the upstream to make a new release.
> >>
> >>We've had dual git/release recipes in the past, and they were all an 
> >>utter failure. In the sense, that only one version of the recipe was 
> >>maintained, and the other was completely neglected.
> >
> >Going forward we may accept patches using this instead:
> >
> >http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass
> >
> >Cheers,
> >
> >Richard
> 
>   well, here's a possible conundrum ... in that same package (i2c-tools),
> there appears to be an *obvious* flaw in that the "eeprog" utility uses a
> sleep that is far too short for proper operation, as described here:
> 
> https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html
> 
> there is a link to a patch on that page that simply cranks up a few sleep
> calls from 10usec to 5msec, which apparently solves the problem. i've been
> involved in a discussion on the i2c-tools mailing list about this very
> issue after i tripped over it, but there seems to be little enthusiasm on
> that list for "fixing" this -- i was told that people use the kernel driver
> instead and access via /sys rather than calling "eeprog".

dl.lm-sensors.org has been down for a while and doesn't show any positive signs 
that
it will be back in near future. One possibility will be to use the unofficial 
mirrors
listed below and upgrade to version 3.1.2

1. https://fossies.org/linux/misc/
2. http://jdelvare.nerim.net/mirror/i2c-tools/

>   so, from my perspective, this should definitely be fixed so that "eeprog"
> functions properly, but it's not clear upstream is all that interested in it.
> what would the protocol be here?

Since this genuinely fixes an error, we should be able to include this patch 
with:
"Inappropriate [bug workaround]" status. 

> rday

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

Re: [OE-core] [PATCH V2] meta: drop do_bootdirectdisk do_vmimg references

[Tom Rini]

On Mon, Jul 31, 2017 at 10:56:28AM +0200, liu.min...@gmail.com wrote:

> From: Ming Liu 
> 
> do_bootdirectdisk and do_vmimg had been dropped by commit 929ba563:
> [ image: Convert vmdk/vdi/qcow2 to strict CONVERSION_CMD types ]
> 
> Also drop the references to them and image-vm.
> 
> Signed-off-by: Ming Liu 

And there's no references to image_type_uboot.bbclass left, either, yes?
If so:

Reviewed-by: Tom Rini 

Thanks!

-- 
Tom


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

Re: [OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[rpjday]

Quoting Richard Purdie :


On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:

On 07/31/2017 01:41 PM, rpj...@crashcourse.ca wrote:
>
>
>    given that some significant changes have been made to i2c-tools
> since
> version 3.1.2, is it worth adding a git-versioned recipe of that
> to 
> oe-core,
> and using DEFAULT_PREFERENCE to force people to select it if they
> want it?
> in particular, the code base has been restructured, and a new
> utility,
> "i2ctransfer", has been added.
It's better to ask the upstream to make a new release.

We've had dual git/release recipes in the past, and they were all an 
utter failure. In the sense, that only one version of the recipe was 
maintained, and the other was completely neglected.


Going forward we may accept patches using this instead:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass

Cheers,

Richard


  well, here's a possible conundrum ... in that same package (i2c-tools),
there appears to be an *obvious* flaw in that the "eeprog" utility uses a
sleep that is far too short for proper operation, as described here:

https://www.toradex.com/community/questions/10243/write-issue-with-eeprog-in-eeprom.html

there is a link to a patch on that page that simply cranks up a few sleep
calls from 10usec to 5msec, which apparently solves the problem. i've been
involved in a discussion on the i2c-tools mailing list about this very
issue after i tripped over it, but there seems to be little enthusiasm on
that list for "fixing" this -- i was told that people use the kernel driver
instead and access via /sys rather than calling "eeprog".

  so, from my perspective, this should definitely be fixed so that "eeprog"
functions properly, but it's not clear upstream is all that interested in it.
what would the protocol be here?

rday


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

Re: [OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[Richard Purdie]

On Mon, 2017-07-31 at 13:41 +0300, Alexander Kanavin wrote:
> On 07/31/2017 01:41 PM, rpj...@crashcourse.ca wrote:
> > 
> > 
> >    given that some significant changes have been made to i2c-tools
> > since
> > version 3.1.2, is it worth adding a git-versioned recipe of that
> > to 
> > oe-core,
> > and using DEFAULT_PREFERENCE to force people to select it if they
> > want it?
> > in particular, the code base has been restructured, and a new
> > utility,
> > "i2ctransfer", has been added.
> It's better to ask the upstream to make a new release.
> 
> We've had dual git/release recipes in the past, and they were all an 
> utter failure. In the sense, that only one version of the recipe was 
> maintained, and the other was completely neglected.

Going forward we may accept patches using this instead:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/devupstream.bbclass

Cheers,

Richard


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

[OE-core] [PATCH] wic: improve generating disk system identifier

[Jonathan Liu]

This should reduce the chance of generating 0x as the disk
system identifier.

Signed-off-by: Jonathan Liu 
---
 scripts/lib/wic/plugins/imager/direct.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index 51bdd3a984..5765bbb527 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -26,6 +26,7 @@
 
 import logging
 import os
+import random
 import shutil
 import tempfile
 import uuid
@@ -303,7 +304,7 @@ class PartitionedImage():
   # all partitions (in bytes)
 self.ptable_format = ptable_format  # Partition table format
 # Disk system identifier
-self.identifier = int.from_bytes(os.urandom(4), 'little') or 0x
+self.identifier = random.SystemRandom().randint(1, 0x)
 
 self.partitions = partitions
 self.partimages = []
-- 
2.13.2

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

Re: [OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[Alexander Kanavin]

On 07/31/2017 01:41 PM, rpj...@crashcourse.ca wrote:


   given that some significant changes have been made to i2c-tools since
version 3.1.2, is it worth adding a git-versioned recipe of that to 
oe-core,

and using DEFAULT_PREFERENCE to force people to select it if they want it?
in particular, the code base has been restructured, and a new utility,
"i2ctransfer", has been added.


It's better to ask the upstream to make a new release.

We've had dual git/release recipes in the past, and they were all an 
utter failure. In the sense, that only one version of the recipe was 
maintained, and the other was completely neglected.


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

[OE-core] worth adding a "git"-versioned of i2c-tools to oe-core?

[rpjday]

  given that some significant changes have been made to i2c-tools since
version 3.1.2, is it worth adding a git-versioned recipe of that to oe-core,
and using DEFAULT_PREFERENCE to force people to select it if they want it?
in particular, the code base has been restructured, and a new utility,
"i2ctransfer", has been added.

rday

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

Re: [OE-core] [PATCH 05/11] gperf: upgrade to 3.1

[Alexander Kanavin]

On 07/31/2017 12:53 PM, Alexander Kanavin wrote:

The only thing I found was this email:
http://lists.gnu.org/archive/html/bug-gperf/2017-01/msg4.html
which was ignored by upstream.

However, both debian testing and fedora rawhide have gperf 3.1, so I'm 
not sure how they made it work. I'm running debian here, so can look 
into this.


Right. Debian dropped the updated gperf package into repositories, but 
did not rebuild anything that relies on it. When I tried that with 
libcap, I got the exact same error as we've seen.


Not sure what's going to happen when they discover the incompatibility. 
I'm a bit surprised they don't do such dependency rebuilds when changes 
are introduced.


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

Re: [OE-core] [PATCH 05/11] gperf: upgrade to 3.1

[Alexander Kanavin]

On 07/31/2017 12:43 PM, Richard Purdie wrote:


Right. Should we just stop fighting with this, and put a
RECIPE_NO_UPDATE_REASON into gperf? I'd rather not update gperf with
this change reverted.


It does feel like upstream screwed up and should really sort this out.
Do you know what upstream plan to do (if anything)?


The only thing I found was this email:
http://lists.gnu.org/archive/html/bug-gperf/2017-01/msg4.html
which was ignored by upstream.

However, both debian testing and fedora rawhide have gperf 3.1, so I'm 
not sure how they made it work. I'm running debian here, so can look 
into this.


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

[OE-core] [PATCH 10/10] testimage.bbclass: update comments

[Robert Yang]

It's very important to add IMAGE_CLASSES += "testimage" in local.conf firstly,
otherwise the var like TEST_LOG_DIR (defined in testimage.bbclass) will not be
in testdata.json.

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/classes/testimage.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 0c4a84e1119..6a435604222 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -7,8 +7,8 @@
 # Most of the tests are commands run on target image over ssh.
 # To use it add testimage to global inherit and call your target image with -c 
testimage
 # You can try it out like this:
-# - first build a qemu core-image-sato
-# - add IMAGE_CLASSES += "testimage" in local.conf
+# - first add IMAGE_CLASSES += "testimage" in local.conf
+# - build a qemu core-image-sato
 # - then bitbake core-image-sato -c testimage. That will run a standard suite 
of tests.
 
 # You can set (or append to) TEST_SUITES in local.conf to select the tests
-- 
2.11.0

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

[OE-core] [PATCH 09/10] buildhistory.bbclass: add ptest_log

[Robert Yang]

The ptest log will be saved to buildhistory/ptest_log, we can easily get
the regression result between builds by:
$ git show HEAD ptest_log/pass.fail.skip.*

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/classes/buildhistory.bbclass | 28 
 1 file changed, 28 insertions(+)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index a3e4c7a734a..26430a63d31 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -912,3 +912,31 @@ def write_latest_srcrev(d, pkghistdir):
 else:
 if os.path.exists(srcrevfile):
 os.remove(srcrevfile)
+
+do_testimage[postfuncs] += "write_ptest_result"
+do_testimage[vardepsexclude] += "write_ptest_result"
+
+python write_ptest_result() {
+write_latest_ptest_result(d, d.getVar('BUILDHISTORY_DIR'))
+}
+
+def write_latest_ptest_result(d, histdir):
+import glob
+import subprocess
+test_log_dir = d.getVar('TEST_LOG_DIR')
+input_ptest_log = os.path.join(test_log_dir, 'ptest_log')
+output_ptest_log = os.path.join(histdir, 'ptest_log')
+if os.path.exists(input_ptest_log):
+# Lock it avoid race issue
+lock = bb.utils.lockfile(output_ptest_log + "/ptest_log.lock")
+bb.utils.mkdirhier(output_ptest_log)
+oe.path.copytree(input_ptest_log, output_ptest_log)
+# Sort test result
+for result in glob.glob('%s/pass.fail.*' % output_ptest_log):
+bb.debug(1, 'Processing %s' % result)
+cmd = "sort %s -o %s" % (result, result)
+bb.debug(1, 'Running %s' % cmd)
+ret = subprocess.call(cmd, shell=True)
+if ret != 0:
+bb.error('Failed to run %s!' % cmd)
+bb.utils.unlockfile(lock)
-- 
2.11.0

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

[OE-core] [PATCH 08/10] buildhistory.bbclass: print message when no commit

[Robert Yang]

This makes the user easier to know how to make commit in buildhistory.

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/classes/buildhistory.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 81784eef216..a3e4c7a734a 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -824,6 +824,8 @@ python buildhistory_eventhandler() {
 interrupted = getattr(e, '_interrupted', 0)
 localdata.setVar('BUILDHISTORY_BUILD_INTERRUPTED', 
str(interrupted))
 bb.build.exec_func("buildhistory_commit", localdata)
+else:
+bb.note("No commit since BUILDHISTORY_COMMIT != '1'")
 }
 
 addhandler buildhistory_eventhandler
-- 
2.11.0

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

[OE-core] [PATCH 06/10] utils/logparser.py: fix section check

[Robert Yang]

The section might be None or '', so use "if section" for it.

Fixed:
File "/buildarea/lyang1/poky/meta/lib/oeqa/utils/logparser.py", line 113, in 
log_as_files
prefix += section
TypeError: Can't convert 'NoneType' object to str implicitly

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/utils/logparser.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/logparser.py b/meta/lib/oeqa/utils/logparser.py
index 4355ce0b767..0670627c3c0 100644
--- a/meta/lib/oeqa/utils/logparser.py
+++ b/meta/lib/oeqa/utils/logparser.py
@@ -109,7 +109,7 @@ class Result(object):
 prefix = ''
 for x in test_status:
 prefix +=x+'.'
-if (section != ''):
+if section:
 prefix += section
 section_file = os.path.join(target_dir, prefix)
 # purge the file contents if it exists
-- 
2.11.0

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

[OE-core] [PATCH 07/10] core/target/ssh.py: replace decode errors

[Robert Yang]

There might be wild strings when read from target (especially when
reading ptest results), replace the errors to avoid breaking the test.

Fixed: (Not always happen)
$ bitbake core-image-sato -ctestimage
[snip]
status, output = self.target.run('ptest-runner', 0)
  File "/buildarea/lyang1/poky/meta/lib/oeqa/core/target/ssh.py", line 84, in 
run
status, output = self._run(sshCmd, processTimeout, True)
  File "/buildarea/lyang1/poky/meta/lib/oeqa/core/target/ssh.py", line 55, in 
_run
status, output = SSHCall(command, self.logger, timeout)
  File "/buildarea/lyang1/poky/meta/lib/oeqa/core/target/ssh.py", line 258, in 
SSHCall
run()
  File "/buildarea/lyang1/poky/meta/lib/oeqa/core/target/ssh.py", line 236, in 
run
output = process.communicate()[0].decode("utf-8")
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 4906: 
invalid continuation byte

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/core/target/ssh.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/core/target/ssh.py b/meta/lib/oeqa/core/target/ssh.py
index b80939c0e51..a2eafcd6f2a 100644
--- a/meta/lib/oeqa/core/target/ssh.py
+++ b/meta/lib/oeqa/core/target/ssh.py
@@ -211,7 +211,7 @@ def SSHCall(command, logger, timeout=None, **opts):
 process.stdout.close()
 eof = True
 else:
-data = data.decode("utf-8")
+data = data.decode("utf-8", errors='replace')
 output += data
 logger.debug('Partial data from SSH call: %s' % 
data)
 endtime = time.time() + timeout
@@ -233,7 +233,7 @@ def SSHCall(command, logger, timeout=None, **opts):
 output += lastline
 
 else:
-output = process.communicate()[0].decode("utf-8")
+output = process.communicate()[0].decode("utf-8", errors='replace')
 logger.debug('Data from SSH call: %s' % output.rstrip())
 
 options = {
-- 
2.11.0

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

[OE-core] [PATCH 01/10] oeqa/targetcontrol.py: simplify checking for qemu_use_kvm

[Robert Yang]

The "if qemu_use_kvm" is not needed.

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/targetcontrol.py | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index 3255e3a5c63..11e6c820e85 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -132,9 +132,8 @@ class QemuTarget(BaseTarget):
 dump_host_cmds = d.getVar("testimage_dump_host")
 dump_dir = d.getVar("TESTIMAGE_DUMP_DIR")
 qemu_use_kvm = d.getVar("QEMU_USE_KVM")
-if qemu_use_kvm and \
-   (qemu_use_kvm == "True" and "x86" in d.getVar("MACHINE") or \
-d.getVar("MACHINE") in qemu_use_kvm.split()):
+if qemu_use_kvm == "True" and "x86" in d.getVar("MACHINE") or \
+d.getVar("MACHINE") in qemu_use_kvm.split():
 use_kvm = True
 else:
 use_kvm = False
-- 
2.11.0

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

[OE-core] [PATCH 04/10] runtime/cases/_ptest.py: add skip status

[Robert Yang]

The packages' test cases maybe skipped, check and save them.

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/runtime/cases/_ptest.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/runtime/cases/_ptest.py 
b/meta/lib/oeqa/runtime/cases/_ptest.py
index 6d239494b88..ec8c038a566 100644
--- a/meta/lib/oeqa/runtime/cases/_ptest.py
+++ b/meta/lib/oeqa/runtime/cases/_ptest.py
@@ -10,6 +10,7 @@ class PtestRunnerTest(OERuntimeTestCase):
 def parse_ptest(self, logfile):
 parser = Lparser(test_0_pass_regex="^PASS:(.+)",
  test_0_fail_regex="^FAIL:(.+)",
+ test_0_skip_regex="^SKIP:(.+)",
  section_0_begin_regex="^BEGIN: .*/(.+)/ptest",
  section_0_end_regex="^END: .*/(.+)/ptest")
 parser.init()
@@ -38,6 +39,10 @@ class PtestRunnerTest(OERuntimeTestCase):
 result.store(current_section, name, status)
 continue
 
+if line_type == 'test' and status == 'skip':
+result.store(current_section, name, status)
+continue
+
 result.sort_tests()
 return result
 
@@ -70,7 +75,7 @@ class PtestRunnerTest(OERuntimeTestCase):
 
 # Parse and save results
 parse_result = self.parse_ptest(ptest_runner_log)
-parse_result.log_as_files(ptest_log_dir, test_status = ['pass','fail'])
+parse_result.log_as_files(ptest_log_dir, test_status = ['pass','fail', 
'skip'])
 if os.path.exists(ptest_log_dir_link):
 # Remove the old link to create a new one
 os.remove(ptest_log_dir_link)
-- 
2.11.0

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

[OE-core] [PATCH 02/10] runtime/cases/_ptest.py: revive it

[Robert Yang]

* Make it work with current oeqa
* Skip the test if ptest is not in DISTRO_FEATURES
* Skip the test if ptest-pkgs is not in IMAGE_FEATURES
* The logs are saved to:
  testimage/ptest_log -> testimage/ptest_log.
* Will write a tool to make regression check

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/runtime/cases/_ptest.py | 96 +--
 1 file changed, 35 insertions(+), 61 deletions(-)

diff --git a/meta/lib/oeqa/runtime/cases/_ptest.py 
b/meta/lib/oeqa/runtime/cases/_ptest.py
index aaed9a5352f..6d239494b88 100644
--- a/meta/lib/oeqa/runtime/cases/_ptest.py
+++ b/meta/lib/oeqa/runtime/cases/_ptest.py
@@ -1,28 +1,10 @@
-import os
-import shutil
-import subprocess
-
 from oeqa.runtime.case import OERuntimeTestCase
 from oeqa.core.decorator.depends import OETestDepends
 from oeqa.core.decorator.oeid import OETestID
-from oeqa.core.decorator.data import skipIfNotDataVar, skipIfNotFeature
-from oeqa.runtime.decorator.package import OEHasPackage
-
-from oeqa.runtime.cases.dnf import DnfTest
-from oeqa.utils.logparser import *
-from oeqa.utils.httpserver import HTTPService
-
-class PtestRunnerTest(DnfTest):
+from oeqa.core.decorator.data import skipIfNotFeature
+from oeqa.utils.logparser import Lparser, Result
 
-@classmethod
-def setUpClass(cls):
-rpm_deploy = os.path.join(cls.tc.td['DEPLOY_DIR'], 'rpm')
-cls.repo_server = HTTPService(rpm_deploy, cls.tc.target.server_ip)
-cls.repo_server.start()
-
-@classmethod
-def tearDownClass(cls):
-cls.repo_server.stop()
+class PtestRunnerTest(OERuntimeTestCase):
 
 # a ptest log parser
 def parse_ptest(self, logfile):
@@ -59,45 +41,37 @@ class PtestRunnerTest(DnfTest):
 result.sort_tests()
 return result
 
-def _install_ptest_packages(self):
-# Get ptest packages that can be installed in the image.
-packages_dir = os.path.join(self.tc.td['DEPLOY_DIR'], 'rpm')
-ptest_pkgs = [pkg[:pkg.find('-ptest')+6]
-  for _, _, filenames in os.walk(packages_dir)
-  for pkg in filenames
-  if 'ptest' in pkg
-  and pkg[:pkg.find('-ptest')] in 
self.tc.image_packages]
-
-repo_url = 'http://%s:%s' % (self.target.server_ip,
- self.repo_server.port)
-dnf_options = ('--repofrompath=oe-ptest-repo,%s '
-   '--nogpgcheck '
-   'install -y' % repo_url)
-self.dnf('%s %s ptest-runner' % (dnf_options, ' '.join(ptest_pkgs)))
-
-@skipIfNotFeature('package-management',
-  'Test requires package-management to be in 
DISTRO_FEATURES')
-@skipIfNotFeature('ptest',
-  'Test requires package-management to be in 
DISTRO_FEATURES')
-@skipIfNotDataVar('IMAGE_PKGTYPE', 'rpm',
-  'RPM is not the primary package manager')
-@OEHasPackage(['dnf'])
+@OETestID(1600)
+@skipIfNotFeature('ptest', 'Test requires ptest to be in DISTRO_FEATURES')
+@skipIfNotFeature('ptest-pkgs', 'Test requires ptest-pkgs to be in 
IMAGE_FEATURES')
 @OETestDepends(['ssh.SSHTest.test_ssh'])
 def test_ptestrunner(self):
-self.ptest_log = os.path.join(self.tc.td['TEST_LOG_DIR'],
-  'ptest-%s.log' % self.tc.td['DATETIME'])
-self._install_ptest_packages()
-
-(runnerstatus, result) = self.target.run('/usr/bin/ptest-runner > 
/tmp/ptest.log 2>&1', 0)
-#exit code is !=0 even if ptest-runner executes because some ptest 
tests fail.
-self.assertTrue(runnerstatus != 127, msg="Cannot execute 
ptest-runner!")
-self.target.copyFrom('/tmp/ptest.log', self.ptest_log)
-shutil.copyfile(self.ptest_log, "ptest.log")
-
-result = self.parse_ptest("ptest.log")
-log_results_to_location = "./results"
-if os.path.exists(log_results_to_location):
-shutil.rmtree(log_results_to_location)
-os.makedirs(log_results_to_location)
-
-result.log_as_files(log_results_to_location, test_status = 
['pass','fail'])
+import datetime
+
+test_log_dir = self.td.get('TEST_LOG_DIR', '')
+# The TEST_LOG_DIR maybe NULL when testimage is added after
+# testdata.json is generated.
+if not test_log_dir:
+test_log_dir = os.path.join(self.td.get('WORKDIR', ''), 
'testimage')
+# Don't use self.td.get('DATETIME'), it's from testdata.json, not
+# up-to-date, and may cause "File exists" when re-reun.
+datetime = datetime.datetime.now().strftime('%Y%m%d%H%M%S')
+ptest_log_dir_link = os.path.join(test_log_dir, 'ptest_log')
+ptest_log_dir = '%s.%s' % (ptest_log_dir_link, datetime)
+ptest_runner_log = os.path.join(ptest_log_dir, 'ptest-runner.log')
+
+status, output = self.target.run('ptest-runner', 

[OE-core] [PATCH 05/10] runtime/cases/_ptest.py: rename it to ptest.py

[Robert Yang]

It works now.

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/runtime/cases/{_ptest.py => ptest.py} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename meta/lib/oeqa/runtime/cases/{_ptest.py => ptest.py} (100%)

diff --git a/meta/lib/oeqa/runtime/cases/_ptest.py 
b/meta/lib/oeqa/runtime/cases/ptest.py
similarity index 100%
rename from meta/lib/oeqa/runtime/cases/_ptest.py
rename to meta/lib/oeqa/runtime/cases/ptest.py
-- 
2.11.0

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

[OE-core] [PATCH 00/10] Revive ptest and add result to buildhistory

[Robert Yang]

We can get the regression result by:
$ git show HEAD ptest_log/pass.fail.skip.*

Can we add ptest to default TEST_SUITES, please ?

// Robert

The following changes since commit a2ab288bd002ebb6e64d46e941fb122e1157ff49:

  uninative: Update to 1.7 uninative release (2017-07-30 08:45:49 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/ptest
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/ptest

Robert Yang (10):
  oeqa/targetcontrol.py: simplify checking for qemu_use_kvm
  runtime/cases/_ptest.py: revive it
  oeqa/utils/logparser.py: add skip status
  runtime/cases/_ptest.py: add skip status
  runtime/cases/_ptest.py: rename it to ptest.py
  utils/logparser.py: fix section check
  core/target/ssh.py: replace decode errors
  buildhistory.bbclass: print message when no commit
  buildhistory.bbclass: add ptest_log
  testimage.bbclass: update comments

 meta/classes/buildhistory.bbclass |  30 ++
 meta/classes/testimage.bbclass|   4 +-
 meta/lib/oeqa/core/target/ssh.py  |   4 +-
 meta/lib/oeqa/runtime/cases/_ptest.py | 103 --
 meta/lib/oeqa/runtime/cases/ptest.py  |  82 +++
 meta/lib/oeqa/targetcontrol.py|   5 +-
 meta/lib/oeqa/utils/logparser.py  |   7 ++-
 7 files changed, 122 insertions(+), 113 deletions(-)
 delete mode 100644 meta/lib/oeqa/runtime/cases/_ptest.py
 create mode 100644 meta/lib/oeqa/runtime/cases/ptest.py

-- 
2.11.0

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

[OE-core] [PATCH 03/10] oeqa/utils/logparser.py: add skip status

[Robert Yang]

Some test cases maybe skipped, let's parse it.

[YOCTO #11547]

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/utils/logparser.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/utils/logparser.py b/meta/lib/oeqa/utils/logparser.py
index b377dcd2716..4355ce0b767 100644
--- a/meta/lib/oeqa/utils/logparser.py
+++ b/meta/lib/oeqa/utils/logparser.py
@@ -9,7 +9,7 @@ from . import ftools
 # A parser that can be used to identify weather a line is a test result or a 
section statement.
 class Lparser(object):
 
-def __init__(self, test_0_pass_regex, test_0_fail_regex, 
section_0_begin_regex=None, section_0_end_regex=None, **kwargs):
+def __init__(self, test_0_pass_regex, test_0_fail_regex, 
test_0_skip_regex, section_0_begin_regex=None, section_0_end_regex=None, 
**kwargs):
 # Initialize the arguments dictionary
 if kwargs:
 self.args = kwargs
@@ -19,12 +19,13 @@ class Lparser(object):
 # Add the default args to the dictionary
 self.args['test_0_pass_regex'] = test_0_pass_regex
 self.args['test_0_fail_regex'] = test_0_fail_regex
+self.args['test_0_skip_regex'] = test_0_skip_regex
 if section_0_begin_regex:
 self.args['section_0_begin_regex'] = section_0_begin_regex
 if section_0_end_regex:
 self.args['section_0_end_regex'] = section_0_end_regex
 
-self.test_possible_status = ['pass', 'fail', 'error']
+self.test_possible_status = ['pass', 'fail', 'error', 'skip']
 self.section_possible_status = ['begin', 'end']
 
 self.initialized = False
-- 
2.11.0

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

Re: [OE-core] [PATCH 05/11] gperf: upgrade to 3.1

[Richard Purdie]

On Mon, 2017-07-31 at 12:35 +0300, Alexander Kanavin wrote:
> On 07/28/2017 05:50 PM, Burton, Ross wrote:
> > 
> > And libid3tag:
> > 
> > > 
> > > compat.gperf:116:1: error: conflicting types for
> > > 'id3_compat_lookup' | 
> > In file included from compat.gperf:37:0: | 
> > ../libid3tag-0.15.1b/compat.h:36:26: note: previous declaration of 
> > 'id3_compat_lookup' was here | struct id3_compat const 
> > *id3_compat_lookup(register char const *, | ^
> > 
> > http://git.savannah.gnu.org/cgit/gperf.git/commit/?id=d519d1a821511
> > eaa22eae6d9019a548aea21e6d3 
> > is the upstream commit that breaks everything, because the API of
> > the 
> > generated files has changed.
> Right. Should we just stop fighting with this, and put a 
> RECIPE_NO_UPDATE_REASON into gperf? I'd rather not update gperf with 
> this change reverted.

It does feel like upstream screwed up and should really sort this out.
Do you know what upstream plan to do (if anything)?

Cheers,

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

Re: [OE-core] [PATCH 05/11] gperf: upgrade to 3.1

[Alexander Kanavin]

On 07/28/2017 05:50 PM, Burton, Ross wrote:

And libid3tag:

| compat.gperf:116:1: error: conflicting types for 'id3_compat_lookup' | 
In file included from compat.gperf:37:0: | 
../libid3tag-0.15.1b/compat.h:36:26: note: previous declaration of 
'id3_compat_lookup' was here | struct id3_compat const 
*id3_compat_lookup(register char const *, | ^


http://git.savannah.gnu.org/cgit/gperf.git/commit/?id=d519d1a821511eaa22eae6d9019a548aea21e6d3 
is the upstream commit that breaks everything, because the API of the 
generated files has changed.


Right. Should we just stop fighting with this, and put a 
RECIPE_NO_UPDATE_REASON into gperf? I'd rather not update gperf with 
this change reverted.


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

[OE-core] [PATCH 2/2] scripts/oe-publish-sdk: use hook to call git update-server-info

[Andrea Galbusera]

The author's initial intent was to use a git hook to automatically call
update-server-info, but the wrong hook type was chosen (post-update). A
post-commit one will do the job, hence allowing to drop the explicit call to
update-server-info.

Signed-off-by: Andrea Galbusera 
---
 scripts/oe-publish-sdk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/oe-publish-sdk b/scripts/oe-publish-sdk
index 9f7963c..ee33acf 100755
--- a/scripts/oe-publish-sdk
+++ b/scripts/oe-publish-sdk
@@ -114,9 +114,9 @@ def publish(args):
 
 # Setting up the git repo
 if not is_remote:
-cmd = 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e .git ]; 
then git init .; mv .git/hooks/post-update.sample .git/hooks/post-update; echo 
"*.pyc\n*.pyo\npyshtables.py" > .gitignore; fi; git add -A .; git config 
user.email "o...@oe.oe" && git config user.name "OE" && git commit -q -m "init 
repo" || true; git update-server-info' % (destination, destination)
+cmd = 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e .git ]; 
then git init .; cp .git/hooks/post-update.sample .git/hooks/post-commit; echo 
"*.pyc\n*.pyo\npyshtables.py" > .gitignore; fi; git add -A .; git config 
user.email "o...@oe.oe" && git config user.name "OE" && git commit -q -m "init 
repo" || true' % (destination, destination)
 else:
-cmd = "ssh %s 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e 
.git ]; then git init .; mv .git/hooks/post-update.sample 
.git/hooks/post-update; echo '*.pyc\n*.pyo\npyshtables.py' > .gitignore; fi; 
git add -A .; git config user.email 'o...@oe.oe' && git config user.name 'OE' 
&& git commit -q -m \"init repo\" || true; git update-server-info'" % (host, 
destdir, destdir)
+cmd = "ssh %s 'set -e; mkdir -p %s/layers; cd %s/layers; if [ ! -e 
.git ]; then git init .; cp .git/hooks/post-update.sample 
.git/hooks/post-commit; echo '*.pyc\n*.pyo\npyshtables.py' > .gitignore; fi; 
git add -A .; git config user.email 'o...@oe.oe' && git config user.name 'OE' 
&& git commit -q -m \"init repo\" || true'" % (host, destdir, destdir)
 ret = subprocess.call(cmd, shell=True)
 if ret == 0:
 logger.info('SDK published successfully')
-- 
2.7.4

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

[OE-core] [PATCH 1/2] devtool: sdk-update: fix pulling updates from git

[Andrea Galbusera]

Commit 4657bc9d165e51981e034e73e7b92552e873eef7 replaced the git pull logic with
the git fetch + git reset --hard combo, but resetting to HEAD does not really
pull in new commits from remote... Replace with resetting to the upstream branch
instead.

Signed-off-by: Andrea Galbusera 
---
 scripts/lib/devtool/sdk.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/sdk.py b/scripts/lib/devtool/sdk.py
index e8bf0ad..f46577c 100644
--- a/scripts/lib/devtool/sdk.py
+++ b/scripts/lib/devtool/sdk.py
@@ -155,7 +155,7 @@ def sdk_update(args, config, basepath, workspace):
 if os.path.exists(os.path.join(basepath, 'layers/.git')):
 out = subprocess.check_output("git status --porcelain", 
shell=True, cwd=layers_dir)
 if not out:
-ret = subprocess.call("git fetch --all; git reset --hard", 
shell=True, cwd=layers_dir)
+ret = subprocess.call("git fetch --all; git reset --hard 
@{u}", shell=True, cwd=layers_dir)
 else:
 logger.error("Failed to update metadata as there have been 
changes made to it. Aborting.");
 logger.error("Changed files:\n%s" % out);
-- 
2.7.4

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

Re: [OE-core] [PATCH V2] meta: drop do_bootdirectdisk do_vmimg references

[Ming Liu]

Changes in V2:

1 Also drop the reference to image-vm.bbclass.

//Ming Liu

2017-07-31 10:56 GMT+02:00 :

> From: Ming Liu 
>
> do_bootdirectdisk and do_vmimg had been dropped by commit 929ba563:
> [ image: Convert vmdk/vdi/qcow2 to strict CONVERSION_CMD types ]
>
> Also drop the references to them and image-vm.
>
> Signed-off-by: Ming Liu 
> ---
>  meta/classes/grub-efi.bbclass | 1 -
>  meta/classes/license.bbclass  | 9 ++---
>  meta/classes/rm_work.bbclass  | 2 +-
>  meta/classes/systemd-boot.bbclass | 3 +--
>  meta/conf/documentation.conf  | 1 -
>  5 files changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
> index df7fe18..610479b 100644
> --- a/meta/classes/grub-efi.bbclass
> +++ b/meta/classes/grub-efi.bbclass
> @@ -17,7 +17,6 @@
>  # ${GRUB_ROOT} - grub's root device.
>
>  do_bootimg[depends] += "${MLPREFIX}grub-efi:do_deploy"
> -do_bootdirectdisk[depends] += "${MLPREFIX}grub-efi:do_deploy"
>
>  GRUB_SERIAL ?= "console=ttyS0,115200"
>  GRUB_CFG_VM = "${S}/grub_vm.cfg"
> diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
> index d4be478..4f7842c 100644
> --- a/meta/classes/license.bbclass
> +++ b/meta/classes/license.bbclass
> @@ -255,14 +255,9 @@ def get_boot_dependencies(d):
>  """
>
>  depends = []
> -boot_depends_string = ""
>  taskdepdata = d.getVar("BB_TASKDEPDATA", False)
> -# Only bootimg and bootdirectdisk include the depends flag
> -boot_tasks = ["do_bootimg", "do_bootdirectdisk",]
> -
> -for task in boot_tasks:
> -boot_depends_string = "%s %s" % (boot_depends_string,
> -d.getVarFlag(task, "depends") or "")
> +# Only bootimg includes the depends flag
> +boot_depends_string = d.getVarFlag("do_bootimg", "depends") or ""
>  boot_depends = [dep.split(":")[0] for dep
>  in boot_depends_string.split()
>  if not dep.split(":")[0].endswith("-native")]
> diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
> index badeaeb..0faa4a6 100644
> --- a/meta/classes/rm_work.bbclass
> +++ b/meta/classes/rm_work.bbclass
> @@ -71,7 +71,7 @@ do_rm_work () {
>  i=dummy
>  break
>  ;;
> -*do_rootfs*|*do_image*|*do_bootimg*|*do_bootdirectdisk*|*
> do_vmimg*|*do_write_qemuboot_conf*)
> +*do_rootfs*|*do_image*|*do_bootimg*|*do_write_qemuboot_conf*)
>  i=dummy
>  break
>  ;;
> diff --git a/meta/classes/systemd-boot.bbclass
> b/meta/classes/systemd-boot.bbclass
> index 9f8f75e..9373070 100644
> --- a/meta/classes/systemd-boot.bbclass
> +++ b/meta/classes/systemd-boot.bbclass
> @@ -7,10 +7,9 @@
>  #maintenance.
>  #
>  # Set EFI_PROVIDER = "systemd-boot" to use systemd-boot on your live
> images instead of grub-efi
> -# (images built by image-live.bbclass or image-vm.bbclass)
> +# (images built by image-live.bbclass)
>
>  do_bootimg[depends] += "${MLPREFIX}systemd-boot:do_deploy"
> -do_bootdirectdisk[depends] += "${MLPREFIX}systemd-boot:do_deploy"
>
>  EFIDIR = "/EFI/BOOT"
>
> diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
> index 35b9103..a55e283 100644
> --- a/meta/conf/documentation.conf
> +++ b/meta/conf/documentation.conf
> @@ -56,7 +56,6 @@ do_testsdk[doc] = "Installs an SDK and performs runtime
> tests on the tools insta
>  do_uboot_mkimage[doc] = "Creates a uImage file from the kernel for the
> U-Boot bootloader"
>  do_unpack[doc] = "Unpacks the source code into a working directory"
>  do_validate_branches[doc] = "Ensures that the source/meta branches are on
> the locations specified by their SRCREV values for a linux-yocto style
> kernel"
> -do_vmimg[doc] = "Creates an image for use with VMware or VirtualBox
> compatible virtual machine hosts (based on IMAGE_FSTYPES either .vmdk or
> .vdi)"
>
>  # DESCRIPTIONS FOR VARIABLES #
>
> --
> 2.7.4
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] meta: drop do_bootdirectdisk do_vmimg references

[liu . ming50]

From: Ming Liu 

do_bootdirectdisk and do_vmimg had been dropped by commit 929ba563:
[ image: Convert vmdk/vdi/qcow2 to strict CONVERSION_CMD types ]

Also drop the references to them and image-vm.

Signed-off-by: Ming Liu 
---
 meta/classes/grub-efi.bbclass | 1 -
 meta/classes/license.bbclass  | 9 ++---
 meta/classes/rm_work.bbclass  | 2 +-
 meta/classes/systemd-boot.bbclass | 3 +--
 meta/conf/documentation.conf  | 1 -
 5 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index df7fe18..610479b 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -17,7 +17,6 @@
 # ${GRUB_ROOT} - grub's root device.
 
 do_bootimg[depends] += "${MLPREFIX}grub-efi:do_deploy"
-do_bootdirectdisk[depends] += "${MLPREFIX}grub-efi:do_deploy"
 
 GRUB_SERIAL ?= "console=ttyS0,115200"
 GRUB_CFG_VM = "${S}/grub_vm.cfg"
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index d4be478..4f7842c 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -255,14 +255,9 @@ def get_boot_dependencies(d):
 """
 
 depends = []
-boot_depends_string = ""
 taskdepdata = d.getVar("BB_TASKDEPDATA", False)
-# Only bootimg and bootdirectdisk include the depends flag
-boot_tasks = ["do_bootimg", "do_bootdirectdisk",]
-
-for task in boot_tasks:
-boot_depends_string = "%s %s" % (boot_depends_string,
-d.getVarFlag(task, "depends") or "")
+# Only bootimg includes the depends flag
+boot_depends_string = d.getVarFlag("do_bootimg", "depends") or ""
 boot_depends = [dep.split(":")[0] for dep
 in boot_depends_string.split()
 if not dep.split(":")[0].endswith("-native")]
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index badeaeb..0faa4a6 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -71,7 +71,7 @@ do_rm_work () {
 i=dummy
 break
 ;;
-
*do_rootfs*|*do_image*|*do_bootimg*|*do_bootdirectdisk*|*do_vmimg*|*do_write_qemuboot_conf*)
+*do_rootfs*|*do_image*|*do_bootimg*|*do_write_qemuboot_conf*)
 i=dummy
 break
 ;;
diff --git a/meta/classes/systemd-boot.bbclass 
b/meta/classes/systemd-boot.bbclass
index 9f8f75e..9373070 100644
--- a/meta/classes/systemd-boot.bbclass
+++ b/meta/classes/systemd-boot.bbclass
@@ -7,10 +7,9 @@
 #maintenance.
 #
 # Set EFI_PROVIDER = "systemd-boot" to use systemd-boot on your live images 
instead of grub-efi
-# (images built by image-live.bbclass or image-vm.bbclass)
+# (images built by image-live.bbclass)
 
 do_bootimg[depends] += "${MLPREFIX}systemd-boot:do_deploy"
-do_bootdirectdisk[depends] += "${MLPREFIX}systemd-boot:do_deploy"
 
 EFIDIR = "/EFI/BOOT"
 
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 35b9103..a55e283 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -56,7 +56,6 @@ do_testsdk[doc] = "Installs an SDK and performs runtime tests 
on the tools insta
 do_uboot_mkimage[doc] = "Creates a uImage file from the kernel for the U-Boot 
bootloader"
 do_unpack[doc] = "Unpacks the source code into a working directory"
 do_validate_branches[doc] = "Ensures that the source/meta branches are on the 
locations specified by their SRCREV values for a linux-yocto style kernel"
-do_vmimg[doc] = "Creates an image for use with VMware or VirtualBox compatible 
virtual machine hosts (based on IMAGE_FSTYPES either .vmdk or .vdi)"
 
 # DESCRIPTIONS FOR VARIABLES #
 
-- 
2.7.4

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

[OE-core] [PATCH] meta: drop do_bootdirectdisk do_vmimg references

[liu . ming50]

From: Ming Liu 

do_bootdirectdisk and do_vmimg had been dropped by commit 929ba563:
[ image: Convert vmdk/vdi/qcow2 to strict CONVERSION_CMD types ]

Also need drop their references.

Signed-off-by: Ming Liu 
---
 meta/classes/grub-efi.bbclass | 1 -
 meta/classes/license.bbclass  | 9 ++---
 meta/classes/rm_work.bbclass  | 2 +-
 meta/classes/systemd-boot.bbclass | 1 -
 meta/conf/documentation.conf  | 1 -
 5 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index df7fe18..610479b 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -17,7 +17,6 @@
 # ${GRUB_ROOT} - grub's root device.
 
 do_bootimg[depends] += "${MLPREFIX}grub-efi:do_deploy"
-do_bootdirectdisk[depends] += "${MLPREFIX}grub-efi:do_deploy"
 
 GRUB_SERIAL ?= "console=ttyS0,115200"
 GRUB_CFG_VM = "${S}/grub_vm.cfg"
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index d4be478..4f7842c 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -255,14 +255,9 @@ def get_boot_dependencies(d):
 """
 
 depends = []
-boot_depends_string = ""
 taskdepdata = d.getVar("BB_TASKDEPDATA", False)
-# Only bootimg and bootdirectdisk include the depends flag
-boot_tasks = ["do_bootimg", "do_bootdirectdisk",]
-
-for task in boot_tasks:
-boot_depends_string = "%s %s" % (boot_depends_string,
-d.getVarFlag(task, "depends") or "")
+# Only bootimg includes the depends flag
+boot_depends_string = d.getVarFlag("do_bootimg", "depends") or ""
 boot_depends = [dep.split(":")[0] for dep
 in boot_depends_string.split()
 if not dep.split(":")[0].endswith("-native")]
diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index badeaeb..0faa4a6 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -71,7 +71,7 @@ do_rm_work () {
 i=dummy
 break
 ;;
-
*do_rootfs*|*do_image*|*do_bootimg*|*do_bootdirectdisk*|*do_vmimg*|*do_write_qemuboot_conf*)
+*do_rootfs*|*do_image*|*do_bootimg*|*do_write_qemuboot_conf*)
 i=dummy
 break
 ;;
diff --git a/meta/classes/systemd-boot.bbclass 
b/meta/classes/systemd-boot.bbclass
index 9f8f75e..733d380 100644
--- a/meta/classes/systemd-boot.bbclass
+++ b/meta/classes/systemd-boot.bbclass
@@ -10,7 +10,6 @@
 # (images built by image-live.bbclass or image-vm.bbclass)
 
 do_bootimg[depends] += "${MLPREFIX}systemd-boot:do_deploy"
-do_bootdirectdisk[depends] += "${MLPREFIX}systemd-boot:do_deploy"
 
 EFIDIR = "/EFI/BOOT"
 
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 35b9103..a55e283 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -56,7 +56,6 @@ do_testsdk[doc] = "Installs an SDK and performs runtime tests 
on the tools insta
 do_uboot_mkimage[doc] = "Creates a uImage file from the kernel for the U-Boot 
bootloader"
 do_unpack[doc] = "Unpacks the source code into a working directory"
 do_validate_branches[doc] = "Ensures that the source/meta branches are on the 
locations specified by their SRCREV values for a linux-yocto style kernel"
-do_vmimg[doc] = "Creates an image for use with VMware or VirtualBox compatible 
virtual machine hosts (based on IMAGE_FSTYPES either .vmdk or .vdi)"
 
 # DESCRIPTIONS FOR VARIABLES #
 
-- 
2.7.4

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

Re: [OE-core] [PATCH v3] wic: ensure generated disk system identifier is non-zero

[Ed Bartosh]

On Mon, Jul 31, 2017 at 06:04:47PM +1000, Jonathan Liu wrote:
> >
> > How about random.SystemRandom().randrange(1, 0x) ?
> >
> 
> random.SystemRandom().randint(1, 0x) actually
> 

This looks ok to me. Thanks.

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

Re: [OE-core] [PATCH v3] wic: ensure generated disk system identifier is non-zero

[Jonathan Liu]

On 31 July 2017 at 17:58, Jonathan Liu  wrote:
> Hi Ed,
>
> On 31 July 2017 at 17:28, Ed Bartosh  wrote:
>> On Sun, Jul 30, 2017 at 08:37:26PM +1000, Jonathan Liu wrote:
>>> Hi Ed,
>>>
>>> On 30 July 2017 at 20:02, Ed Bartosh  wrote:
>>> > On Sat, Jul 29, 2017 at 12:45:27AM +1000, Jonathan Liu wrote:
>>> >> Zero may be interpreted as no MBR signature present and another
>>> >> partitioning program might install a new MBR signature.
>>> >>
>>> >> Signed-off-by: Jonathan Liu 
>>> >> ---
>>> >>  scripts/lib/wic/plugins/imager/direct.py | 2 +-
>>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/scripts/lib/wic/plugins/imager/direct.py 
>>> >> b/scripts/lib/wic/plugins/imager/direct.py
>>> >> index f20d8433f1..fe9b688ab0 100644
>>> >> --- a/scripts/lib/wic/plugins/imager/direct.py
>>> >> +++ b/scripts/lib/wic/plugins/imager/direct.py
>>> >> @@ -297,7 +297,7 @@ class PartitionedImage():
>>> >># all partitions (in bytes)
>>> >>  self.ptable_format = ptable_format  # Partition table format
>>> >>  # Disk system identifier
>>> >> -self.identifier = int.from_bytes(os.urandom(4), 'little')
>>> >> +self.identifier = int.from_bytes(os.urandom(4), 'little') or 
>>> >> 0x
>>> >>
>>> >
>>> > Can we generate random identifier by calling os.urandom again if
>>> > self.identifier is zero? Something like this, may be?
>>> >
>>> > while True:
>>> > self.identifier = int.from_bytes(os.urandom(4), 'little')
>>> > if self.identifier:
>>> > break
>>> >
>>> > Assigning constant 0x can potentially create nonunique 
>>> > identifiers.
>>> >
>>>
>>> There is no guarantee that urandom will create unique identifiers.
>> We can't have a guarantee with urandom, true. My point was that if you
>> need random value it's better to call urandom again than using a constant 
>> value.
>>
>>> Infinite loop needs a timeout and error in the case it is unable to
>>> generate a suitable identifier.
>> I'm not sure it's needed, but it's not a big deal to add this. I really
>> doubt os.urandom can generate long enough sequence of zeros.
>>
>>> It is only 0x if it is 0. That
>>> means 0x is twice as likely to occur (2 in 4294967296 instead
>>> of 1 in 4294967296) so there is tiny bias. Note that this is how it is
>>> implemented for the DISK_SIGNATURE variable in OE and in GNU Parted as
>>> well.
>> Does this mean we shouldn't do better?
>>
>
> How about random.SystemRandom().randrange(1, 0x) ?
>

random.SystemRandom().randint(1, 0x) actually

>>> >>  self.partitions = partitions
>>> >>  self.partimages = []
>>> >> --
>>> >> 2.13.2
>>> >>
>>> >> --
>>> >> ___
>>> >> Openembedded-core mailing list
>>> >> Openembedded-core@lists.openembedded.org
>>> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>> Regards,
>>> Jonathan
>>
>> --
>> Regards,
>> Ed
>
> Regards,
> Jonathan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] wic: ensure generated disk system identifier is non-zero

[Jonathan Liu]

Hi Ed,

On 31 July 2017 at 17:28, Ed Bartosh  wrote:
> On Sun, Jul 30, 2017 at 08:37:26PM +1000, Jonathan Liu wrote:
>> Hi Ed,
>>
>> On 30 July 2017 at 20:02, Ed Bartosh  wrote:
>> > On Sat, Jul 29, 2017 at 12:45:27AM +1000, Jonathan Liu wrote:
>> >> Zero may be interpreted as no MBR signature present and another
>> >> partitioning program might install a new MBR signature.
>> >>
>> >> Signed-off-by: Jonathan Liu 
>> >> ---
>> >>  scripts/lib/wic/plugins/imager/direct.py | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/scripts/lib/wic/plugins/imager/direct.py 
>> >> b/scripts/lib/wic/plugins/imager/direct.py
>> >> index f20d8433f1..fe9b688ab0 100644
>> >> --- a/scripts/lib/wic/plugins/imager/direct.py
>> >> +++ b/scripts/lib/wic/plugins/imager/direct.py
>> >> @@ -297,7 +297,7 @@ class PartitionedImage():
>> >># all partitions (in bytes)
>> >>  self.ptable_format = ptable_format  # Partition table format
>> >>  # Disk system identifier
>> >> -self.identifier = int.from_bytes(os.urandom(4), 'little')
>> >> +self.identifier = int.from_bytes(os.urandom(4), 'little') or 
>> >> 0x
>> >>
>> >
>> > Can we generate random identifier by calling os.urandom again if
>> > self.identifier is zero? Something like this, may be?
>> >
>> > while True:
>> > self.identifier = int.from_bytes(os.urandom(4), 'little')
>> > if self.identifier:
>> > break
>> >
>> > Assigning constant 0x can potentially create nonunique identifiers.
>> >
>>
>> There is no guarantee that urandom will create unique identifiers.
> We can't have a guarantee with urandom, true. My point was that if you
> need random value it's better to call urandom again than using a constant 
> value.
>
>> Infinite loop needs a timeout and error in the case it is unable to
>> generate a suitable identifier.
> I'm not sure it's needed, but it's not a big deal to add this. I really
> doubt os.urandom can generate long enough sequence of zeros.
>
>> It is only 0x if it is 0. That
>> means 0x is twice as likely to occur (2 in 4294967296 instead
>> of 1 in 4294967296) so there is tiny bias. Note that this is how it is
>> implemented for the DISK_SIGNATURE variable in OE and in GNU Parted as
>> well.
> Does this mean we shouldn't do better?
>

How about random.SystemRandom().randrange(1, 0x) ?

>> >>  self.partitions = partitions
>> >>  self.partimages = []
>> >> --
>> >> 2.13.2
>> >>
>> >> --
>> >> ___
>> >> Openembedded-core mailing list
>> >> Openembedded-core@lists.openembedded.org
>> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>> Regards,
>> Jonathan
>
> --
> Regards,
> Ed

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

Re: [OE-core] [PATCH v3] wic: ensure generated disk system identifier is non-zero

[Ed Bartosh]

On Sun, Jul 30, 2017 at 08:37:26PM +1000, Jonathan Liu wrote:
> Hi Ed,
> 
> On 30 July 2017 at 20:02, Ed Bartosh  wrote:
> > On Sat, Jul 29, 2017 at 12:45:27AM +1000, Jonathan Liu wrote:
> >> Zero may be interpreted as no MBR signature present and another
> >> partitioning program might install a new MBR signature.
> >>
> >> Signed-off-by: Jonathan Liu 
> >> ---
> >>  scripts/lib/wic/plugins/imager/direct.py | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/scripts/lib/wic/plugins/imager/direct.py 
> >> b/scripts/lib/wic/plugins/imager/direct.py
> >> index f20d8433f1..fe9b688ab0 100644
> >> --- a/scripts/lib/wic/plugins/imager/direct.py
> >> +++ b/scripts/lib/wic/plugins/imager/direct.py
> >> @@ -297,7 +297,7 @@ class PartitionedImage():
> >># all partitions (in bytes)
> >>  self.ptable_format = ptable_format  # Partition table format
> >>  # Disk system identifier
> >> -self.identifier = int.from_bytes(os.urandom(4), 'little')
> >> +self.identifier = int.from_bytes(os.urandom(4), 'little') or 
> >> 0x
> >>
> >
> > Can we generate random identifier by calling os.urandom again if
> > self.identifier is zero? Something like this, may be?
> >
> > while True:
> > self.identifier = int.from_bytes(os.urandom(4), 'little')
> > if self.identifier:
> > break
> >
> > Assigning constant 0x can potentially create nonunique identifiers.
> >
>
> There is no guarantee that urandom will create unique identifiers.
We can't have a guarantee with urandom, true. My point was that if you
need random value it's better to call urandom again than using a constant value.

> Infinite loop needs a timeout and error in the case it is unable to
> generate a suitable identifier.
I'm not sure it's needed, but it's not a big deal to add this. I really
doubt os.urandom can generate long enough sequence of zeros.

> It is only 0x if it is 0. That
> means 0x is twice as likely to occur (2 in 4294967296 instead
> of 1 in 4294967296) so there is tiny bias. Note that this is how it is
> implemented for the DISK_SIGNATURE variable in OE and in GNU Parted as
> well.
Does this mean we shouldn't do better?

> >>  self.partitions = partitions
> >>  self.partimages = []
> >> --
> >> 2.13.2
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> Regards,
> Jonathan

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