date:20171026

[OE-core] ✗ patchtest: failure for libnl: 3.2.29 -> 3.4.0 (rev4)

2017-10-26 Thread Patchwork

== Series Details ==

Series: libnl: 3.2.29 -> 3.4.0 (rev4)
Revision: 4
URL   : https://patchwork.openembedded.org/series/9397/
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 Upstream-Status is in incorrect format 
[test_upstream_status_presence_format] 
  Suggested fixFix Upstream-Status format in 
0001-PATCH-fix-libnl-3.4.0-musl-compile-problem.patch
  Current  Upstream-Status:: Pending
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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 v4] libnl: 3.2.29 -> 3.4.0

2017-10-26 Thread Huang Qiyu

1) Upgrade libnl from 3.2.29 to 3.4.0.
2) Add one patch "0001-PATCH-fix-libnl-3.4.0-musl-compile-problem.patch", for 
musl compile.
3) Delete one patch "fix-pktloc_syntax_h-race.patch", since upstream has 
refactored the makefiles, and the problematic code is now absent.

Signed-off-by: Huang Qiyu 
---
 ...ATCH-fix-libnl-3.4.0-musl-compile-problem.patch | 38 ++
 .../libnl/libnl/fix-pktloc_syntax_h-race.patch | 36 
 .../libnl/{libnl_3.2.29.bb => libnl_3.4.0.bb}  |  7 ++--
 3 files changed, 42 insertions(+), 39 deletions(-)
 create mode 100644 
meta/recipes-support/libnl/libnl/0001-PATCH-fix-libnl-3.4.0-musl-compile-problem.patch
 delete mode 100644 
meta/recipes-support/libnl/libnl/fix-pktloc_syntax_h-race.patch
 rename meta/recipes-support/libnl/{libnl_3.2.29.bb => libnl_3.4.0.bb} (87%)

diff --git 
a/meta/recipes-support/libnl/libnl/0001-PATCH-fix-libnl-3.4.0-musl-compile-problem.patch
 
b/meta/recipes-support/libnl/libnl/0001-PATCH-fix-libnl-3.4.0-musl-compile-problem.patch
new file mode 100644
index 000..d0e2ead
--- /dev/null
+++ 
b/meta/recipes-support/libnl/libnl/0001-PATCH-fix-libnl-3.4.0-musl-compile-problem.patch
@@ -0,0 +1,38 @@
+Subject: [PATCH] fix libnl-3.4.0 musl compile problem  
+Avoid in6_addr redefinition
+
+Upstream-Status:: Pending
+
+Signed-off-by: Huang Qiyu 
+---
+ include/linux-private/linux/if_bridge.h | 1 -
+ include/linux-private/linux/ipv6.h  | 1 -
+ 2 files changed, 2 deletions(-)
+
+diff --git a/include/linux-private/linux/if_bridge.h 
b/include/linux-private/linux/if_bridge.h
+index f24050b..8f7490c 100644
+--- a/include/linux-private/linux/if_bridge.h
 b/include/linux-private/linux/if_bridge.h
+@@ -15,7 +15,6 @@
+ 
+ #include 
+ #include 
+-#include 
+ 
+ #define SYSFS_BRIDGE_ATTR "bridge"
+ #define SYSFS_BRIDGE_FDB  "brforward"
+diff --git a/include/linux-private/linux/ipv6.h 
b/include/linux-private/linux/ipv6.h
+index e05e684..f16349d 100644
+--- a/include/linux-private/linux/ipv6.h
 b/include/linux-private/linux/ipv6.h
+@@ -2,7 +2,6 @@
+ #define _IPV6_H
+ 
+ #include 
+-#include 
+ 
+ /* The latest drafts declared increase in minimal mtu up to 1280. */
+ 
+-- 
+2.7.4
+
diff --git a/meta/recipes-support/libnl/libnl/fix-pktloc_syntax_h-race.patch 
b/meta/recipes-support/libnl/libnl/fix-pktloc_syntax_h-race.patch
deleted file mode 100644
index 79aa0bd..000
--- a/meta/recipes-support/libnl/libnl/fix-pktloc_syntax_h-race.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-libnl has progressed to 0.3.2 and there does not appear to be any
-"make -j" issues with this build after my limited testing on that
-newer version so we can assume this issue is fixed upstream
-
-Signed-off-by: Martin Jansa 
-
-Index: libnl-3.2.25/lib/Makefile.am
-===
 libnl-3.2.25.orig/lib/Makefile.am
-+++ libnl-3.2.25/lib/Makefile.am
-@@ -46,9 +46,12 @@ CLEANFILES = \
- 
- # Hack to avoid using ylwrap. It does not function correctly in combination
- # with --header-file=
-+route/pktloc.lo: route/pktloc_syntax.h route/pktloc_grammar.h
-+route/pktloc_grammar.h: route/pktloc_grammar.c
- route/pktloc_grammar.c: route/pktloc_grammar.l
-   $(AM_V_GEN) $(MKDIR_P) route; $(FLEX) 
--header-file=route/pktloc_grammar.h $(LFLAGS) -o $@ $^
- 
-+route/pktloc_syntax.h: route/pktloc_syntax.c
- route/pktloc_syntax.c: route/pktloc_syntax.y
-   $(AM_V_GEN) $(MKDIR_P) route; $(YACC) -d $(YFLAGS) -o $@ $^
- 
-@@ -102,7 +105,9 @@ BUILT_SOURCES = \
-   route/cls/ematch_grammar.c \
-   route/cls/ematch_syntax.c \
-   route/pktloc_grammar.c \
--  route/pktloc_syntax.c
-+   route/pktloc_syntax.c \
-+   route/pktloc_syntax.h \
-+   route/pktloc_grammar.h
- 
- EXTRA_DIST = \
-   route/pktloc_grammar.l \
diff --git a/meta/recipes-support/libnl/libnl_3.2.29.bb 
b/meta/recipes-support/libnl/libnl_3.4.0.bb
similarity index 87%
rename from meta/recipes-support/libnl/libnl_3.2.29.bb
rename to meta/recipes-support/libnl/libnl_3.4.0.bb
index 7d4839b..90dc644 100644
--- a/meta/recipes-support/libnl/libnl_3.2.29.bb
+++ b/meta/recipes-support/libnl/libnl_3.4.0.bb
@@ -10,13 +10,14 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 DEPENDS = "flex-native bison-native"
 
 SRC_URI = 
"https://github.com/thom311/${BPN}/releases/download/${BPN}${@d.getVar('PV').replace('.','_')}/${BP}.tar.gz
 \
-   file://fix-pktloc_syntax_h-race.patch \
file://fix-pc-file.patch \
+   file://0001-PATCH-fix-libnl-3.4.0-musl-compile-problem.patch \
 "
+
 UPSTREAM_CHECK_URI = "https://github.com/thom311/${BPN}/releases;
 
-SRC_URI[md5sum] = "a8ba62a5c4f883f4e493a46d1f3733fe"
-SRC_URI[sha256sum] = 
"0beb593dc6abfffa18a5c787b27884979c1b7e7f1fd468c801e3cc938a685922"
+SRC_URI[md5sum] = "8f71910c03db363b41e2ea62057a4311"

[OE-core] [PATCH] systemd: Fix build on musl

2017-10-26 Thread Khem Raj

Add needed patches for portability across glibc/musl
enable systemd on musl too

Disable utmp,ldconfig,nss,resolved,localed for musl
which is not supported on musl

Signed-off-by: Khem Raj 
---
 ...PATH_WTMPX-and-_PATH_UTMPX-if-not-defined.patch |  43 ++
 ...llback-parse_printf_format-implementation.patch | 433 +
 ...asic-missing.h-check-for-missing-strndupa.patch | 104 +
 ...if-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch | 157 
 ...issing.h-check-for-missing-__compar_fn_t-.patch |  47 +++
 .../systemd/0006-Include-netinet-if_ether.h.patch  |  86 
 ...-check-for-missing-canonicalize_file_name.patch |  63 +++
 .../systemd/0008-Do-not-enable-nss-tests.patch |  35 ++
 ...xdecoct.c-Include-missing.h-form-strndupa.patch |  27 ++
 c-Disable-tests-for-missing-typedefs-in-.patch |  49 +++
 .../0011-don-t-use-glibc-specific-qsort_r.patch| 105 +
 ...ass-AT_SYMLINK_NOFOLLOW-flag-to-faccessat.patch |  99 +
 ...fn_t-is-glibc-specific-use-raw-signature-.patch |  31 ++
 meta/recipes-core/systemd/systemd_234.bb   |  28 +-
 14 files changed, 1300 insertions(+), 7 deletions(-)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-Define-_PATH_WTMPX-and-_PATH_UTMPX-if-not-defined.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-add-fallback-parse_printf_format-implementation.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0002-src-basic-missing.h-check-for-missing-strndupa.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0003-don-t-fail-if-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0004-src-basic-missing.h-check-for-missing-__compar_fn_t-.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0006-Include-netinet-if_ether.h.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0007-check-for-missing-canonicalize_file_name.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0008-Do-not-enable-nss-tests.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0009-test-hexdecoct.c-Include-missing.h-form-strndupa.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0010-test-sizeof.c-Disable-tests-for-missing-typedefs-in-.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0011-don-t-use-glibc-specific-qsort_r.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0012-don-t-pass-AT_SYMLINK_NOFOLLOW-flag-to-faccessat.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0013-comparison_fn_t-is-glibc-specific-use-raw-signature-.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-Define-_PATH_WTMPX-and-_PATH_UTMPX-if-not-defined.patch
 
b/meta/recipes-core/systemd/systemd/0001-Define-_PATH_WTMPX-and-_PATH_UTMPX-if-not-defined.patch
new file mode 100644
index 00..35599d44c2
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-Define-_PATH_WTMPX-and-_PATH_UTMPX-if-not-defined.patch
@@ -0,0 +1,43 @@
+From 3ca5326485cb19e775af6de615c17be66e44e472 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 24 Oct 2017 23:08:24 -0700
+Subject: [PATCH] Define _PATH_WTMPX and _PATH_UTMPX if not defined
+
+Musl needs these defines
+
+Signed-off-by: Khem Raj 
+---
+Upstream-Status: Pending
+
+ src/shared/utmp-wtmp.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/src/shared/utmp-wtmp.c b/src/shared/utmp-wtmp.c
+index 9750dcd81..bd55d74a1 100644
+--- a/src/shared/utmp-wtmp.c
 b/src/shared/utmp-wtmp.c
+@@ -27,6 +27,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #include "alloc-util.h"
+@@ -41,6 +42,13 @@
+ #include "util.h"
+ #include "utmp-wtmp.h"
+ 
++#if defined _PATH_UTMP && !defined _PATH_UTMPX
++# define _PATH_UTMPX _PATH_UTMP
++#endif
++#if defined _PATH_WTMP && !defined _PATH_WTMPX
++# define _PATH_WTMPX _PATH_WTMP
++#endif
++
+ int utmp_get_runlevel(int *runlevel, int *previous) {
+ struct utmpx *found, lookup = { .ut_type = RUN_LVL };
+ int r;
+-- 
+2.14.3
+
diff --git 
a/meta/recipes-core/systemd/systemd/0001-add-fallback-parse_printf_format-implementation.patch
 
b/meta/recipes-core/systemd/systemd/0001-add-fallback-parse_printf_format-implementation.patch
new file mode 100644
index 00..e2f7458abe
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-add-fallback-parse_printf_format-implementation.patch
@@ -0,0 +1,433 @@
+From 0933ca6251808f856b92b0ce8da8696d5febc333 Mon Sep 17 00:00:00 2001
+From: Emil Renner Berthing 
+Date: Mon, 23 Oct 2017 10:41:39 -0700
+Subject: [PATCH 01/12] add fallback parse_printf_format implementation
+
+Signed-off-by: Emil Renner Berthing 
+Signed-off-by: Khem Raj 
+---
+Upstream-Status: Pending
+
+ Makefile.am |   4 +
+ configure.ac|   2 +
+ src/basic/parse-printf-format.c | 273 
+

[OE-core] [PATCH] coreutils: upgrade to 8.28

2017-10-26 Thread Fan Xin

Signed-off-by: Fan Xin 
---
 .../coreutils/{coreutils_8.27.bb => coreutils_8.28.bb}| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-core/coreutils/{coreutils_8.27.bb => coreutils_8.28.bb} 
(95%)

diff --git a/meta/recipes-core/coreutils/coreutils_8.27.bb 
b/meta/recipes-core/coreutils/coreutils_8.28.bb
similarity index 95%
rename from meta/recipes-core/coreutils/coreutils_8.27.bb
rename to meta/recipes-core/coreutils/coreutils_8.28.bb
index ea8740a..0543ceb 100644
--- a/meta/recipes-core/coreutils/coreutils_8.27.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.28.bb
@@ -23,10 +23,10 @@ SRC_URI = 
"${GNU_MIRROR}/coreutils/${BP}.tar.xz;name=tarball \
file://0001-local.mk-fix-cross-compiling-problem.patch \
   "
 
-SRC_URI[tarball.md5sum] = "502795792c212932365e077946d353ae"
-SRC_URI[tarball.sha256sum] = 
"8891d349ee87b9ff7870f52b6d9312a9db672d2439d289bc57084771ca21656b"
-SRC_URI[manpages.md5sum] = "1b31a688d06764e0e94aa20b7ea08222"
-SRC_URI[manpages.sha256sum] = 
"1f615819e9167646c731636b6c5ecbe79837e82a18666bacc82c3fb1dfcfaea3"
+SRC_URI[tarball.md5sum] = "e7cb20d0572cc40d9f47ede6454406d1"
+SRC_URI[tarball.sha256sum] = 
"1117b1a16039ddd84d51a9923948307cfa28c2cea03d1a2438742253df0a0c65"
+SRC_URI[manpages.md5sum] = "3a7c626aad1c9077f254e5c2553a2f60"
+SRC_URI[manpages.sha256sum] = 
"d72c3fa79ae328a4fd1107102e8946755aa2e908044e1efcf1e71ef206dca042"
 
 EXTRA_OECONF_class-native = "--without-gmp"
 EXTRA_OECONF_class-target = "--enable-install-program=arch 
--libexecdir=${libdir}"
-- 
2.7.4


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

[OE-core] [PATCH] curl: update to 7.56.1

2017-10-26 Thread Fan Xin

1. Update the md5sum and sha256sum for curl 7.56.1
2. Delete the following patchs which have been applied in curl 7.56.1
CVE-2017-199.patch
CVE-2017-1000100.patch
CVE-2017-1000101.patch
3. Delete the do_install_append() due to the curl/curlbuild.h have been removed.

Signed-off-by: Fan Xin 
---
 .../curl/curl/CVE-2017-199.patch   | 41 -
 .../curl/curl/CVE-2017-1000100.patch   | 51 ---
 .../curl/curl/CVE-2017-1000101.patch   | 99 --
 .../curl/{curl_7.54.1.bb => curl_7.56.1.bb}| 11 +--
 4 files changed, 2 insertions(+), 200 deletions(-)
 delete mode 100644 meta/recipes-support/curl/curl/CVE-2017-199.patch
 delete mode 100644 meta/recipes-support/curl/curl/CVE-2017-1000100.patch
 delete mode 100644 meta/recipes-support/curl/curl/CVE-2017-1000101.patch
 rename meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.56.1.bb} (89%)

diff --git a/meta/recipes-support/curl/curl/CVE-2017-199.patch 
b/meta/recipes-support/curl/curl/CVE-2017-199.patch
deleted file mode 100644
index 96ff1b0..000
--- a/meta/recipes-support/curl/curl/CVE-2017-199.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-From c9332fa5e84f24da300b42b1a931ade929d3e27d Mon Sep 17 00:00:00 2001
-From: Even Rouault 
-Date: Tue, 1 Aug 2017 17:17:06 +0200
-Subject: [PATCH] file: output the correct buffer to the user
-
-Regression brought by 7c312f84ea930d8 (April 2017)
-
-CVE: CVE-2017-199
-
-Bug: https://curl.haxx.se/docs/adv_20170809C.html
-
-Credit to OSS-Fuzz for the discovery
-
-Upstream-Status: Backport
-https://github.com/curl/curl/commit/c9332fa5e84f24da300b42b1a931ade929d3e27d
-
-Signed-off-by: Wenzong Fan 

- lib/file.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/lib/file.c b/lib/file.c
-index bd426eac2..666cbe75b 100644
 a/lib/file.c
-+++ b/lib/file.c
-@@ -499,11 +499,11 @@ static CURLcode file_do(struct connectdata *conn, bool 
*done)
-  Curl_month[tm->tm_mon],
-  tm->tm_year + 1900,
-  tm->tm_hour,
-  tm->tm_min,
-  tm->tm_sec);
--result = Curl_client_write(conn, CLIENTWRITE_BOTH, buf, 0);
-+result = Curl_client_write(conn, CLIENTWRITE_BOTH, header, 0);
- if(!result)
-   /* set the file size to make it available post transfer */
-   Curl_pgrsSetDownloadSize(data, expected_size);
- return result;
-   }
--- 
-2.13.3
-
diff --git a/meta/recipes-support/curl/curl/CVE-2017-1000100.patch 
b/meta/recipes-support/curl/curl/CVE-2017-1000100.patch
deleted file mode 100644
index f74f1dd..000
--- a/meta/recipes-support/curl/curl/CVE-2017-1000100.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 358b2b131ad6c095696f20dcfa62b8305263f898 Mon Sep 17 00:00:00 2001
-From: Daniel Stenberg 
-Date: Tue, 1 Aug 2017 17:16:46 +0200
-Subject: [PATCH] tftp: reject file name lengths that don't fit
-
-... and thereby avoid telling send() to send off more bytes than the
-size of the buffer!
-
-CVE: CVE-2017-1000100
-
-Bug: https://curl.haxx.se/docs/adv_20170809B.html
-Reported-by: Even Rouault
-
-Credit to OSS-Fuzz for the discovery
-
-Upstream-Status: Backport
-https://github.com/curl/curl/commit/358b2b131ad6c095696f20dcfa62b8305263f898
-
-Signed-off-by: Wenzong Fan 

- lib/tftp.c |7 ++-
- 1 file changed, 6 insertions(+), 1 deletion(-)
-
-diff --git a/lib/tftp.c b/lib/tftp.c
-index 02bd842..f6f4bce 100644
 a/lib/tftp.c
-+++ b/lib/tftp.c
-@@ -5,7 +5,7 @@
-  *| (__| |_| |  _ <| |___
-  * \___|\___/|_| \_\_|
-  *
-- * Copyright (C) 1998 - 2016, Daniel Stenberg, , et al.
-+ * Copyright (C) 1998 - 2017, Daniel Stenberg, , et al.
-  *
-  * This software is licensed as described in the file COPYING, which
-  * you should have received as part of this distribution. The terms
-@@ -491,6 +491,11 @@ static CURLcode tftp_send_first(tftp_state_data_t *state, 
tftp_event_t event)
- if(result)
-   return result;
- 
-+if(strlen(filename) > (state->blksize - strlen(mode) - 4)) {
-+  failf(data, "TFTP file name too long\n");
-+  return CURLE_TFTP_ILLEGAL; /* too long file name field */
-+}
-+
- snprintf((char *)state->spacket.data+2,
-  state->blksize,
-  "%s%c%s%c", filename, '\0',  mode, '\0');
--- 
-1.7.9.5
-
diff --git a/meta/recipes-support/curl/curl/CVE-2017-1000101.patch 
b/meta/recipes-support/curl/curl/CVE-2017-1000101.patch
deleted file mode 100644
index c300fff..000
--- a/meta/recipes-support/curl/curl/CVE-2017-1000101.patch
+++ /dev/null
@@ -1,99 +0,0 @@
-From 453e7a7a03a2cec749abd3878a48e728c515cca7 Mon Sep 17 00:00:00 2001
-From: Daniel Stenberg 
-Date: Tue, 1 Aug 2017 17:16:07 +0200
-Subject: [PATCH] glob: do not continue parsing after a

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

2017-10-26 Thread Andre McCurdy

On Thu, Oct 26, 2017 at 1:51 PM, Slater, Joseph
 wrote:
> I think values for the BACKFILL_CONSIDERED can be used, but only if they are 
> literals.  I don't think any variable expansion occurs when getVar() is used 
> at the point of backfilling.

Maybe the assumption is that MACHINE_FEATURES_BACKFILL_CONSIDERED will
only be set from the machine config and
DISTRO_FEATURES_BACKFILL_CONSIDERED will only be set from the distro
config. Don't they work even in that case?

> I think the a better way of setting MACHINE or DISTRO_FEATURES would be to 
> directly append/remove  using overrides.

Yes, of course. If you want to control machine or distro features
directly that that's the way it should be done. The BACKFILL
infrastructure is there for a very special case - to try to keep a
consistent behaviour for users who set fixed values for machine or
distro features and don't keep those definitions up to date with
changes in oe-core.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

2017-10-26 Thread Slater, Joseph

I think values for the BACKFILL_CONSIDERED can be used, but only if they are 
literals.  I don't think any variable expansion occurs when getVar() is used at 
the point of backfilling.  I think the a better way of setting MACHINE or 
DISTRO_FEATURES would be to directly append/remove  using overrides.  In any 
case, I do not believe any of the CONSIDERED definitions work.

Joe

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com] 
Sent: Thursday, October 26, 2017 11:09 AM
To: Slater, Joseph
Cc: Alexander Kanavin; OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On Thu, Oct 26, 2017 at 10:15 AM, Slater, Joseph  
wrote:
> Okay, I don't know why, but at the time of backfilling the CONSIDERED list is 
> empty!  This is not true if I use "=" to set it unconditionally in 
> arch-mips.inc, but it IS true if I try to set it via anything involving an 
> override (including append).
>
> Isn't getVar() supposed to expand the variable?  Put print msg's in 
> meta/lib/oe/utils.py to see this behavior.

features_backfill() is called from meta/classes/base.bbclass ->
base_eventhandler() in response to bb.event.ConfigParsed (ie "when the base 
configuration; which consists of bitbake.conf, base.bbclass and any global 
INHERIT statements; has been parsed") so anything assigned to 
DISTRO_FEATURES_BACKFILL_CONSIDERED or MACHINE_FEATURES_BACKFILL_CONSIDERED 
after that event won't be seen...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] qemu: upgrade to 2.10.1

2017-10-26 Thread leonardo . sandoval . gonzalez

From: Leonardo Sandoval 

All CVE patches and the glibc one removed because these are already integrated
into 2.10.1.

Signed-off-by: Leonardo Sandoval 
---

v2: removed the glibc-2.25.patch, already into 2.10.1. At v1, I hit [YOCTO 
#10450]
where devtool upgrade complain in just one hunk, even thought the rest of 
the
hunks were already present at code. In general, the default patch fuzz 
setting
is to lenient/lax and  needs to be fix. As Patrick mentioned, double check 
is
needed when using automatic tools.

 .../qemu/qemu/CVE-2017-13672.patch | 504 -
 .../qemu/qemu/CVE-2017-13673.patch |  53 ---
 .../qemu/qemu/CVE-2017-13711.patch |  87 
 .../qemu/qemu/CVE-2017-14167.patch |  70 ---
 meta/recipes-devtools/qemu/qemu/glibc-2.25.patch   |  88 
 .../qemu/{qemu_2.10.0.bb => qemu_2.10.1.bb}|   9 +-
 6 files changed, 2 insertions(+), 809 deletions(-)
 delete mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-13672.patch
 delete mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-13673.patch
 delete mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-13711.patch
 delete mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2017-14167.patch
 delete mode 100644 meta/recipes-devtools/qemu/qemu/glibc-2.25.patch
 rename meta/recipes-devtools/qemu/{qemu_2.10.0.bb => qemu_2.10.1.bb} (84%)

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2017-13672.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2017-13672.patch
deleted file mode 100644
index ce0b1ee3ed..00
--- a/meta/recipes-devtools/qemu/qemu/CVE-2017-13672.patch
+++ /dev/null
@@ -1,504 +0,0 @@
-From 3d90c6254863693a6b13d918d2b8682e08bbc681 Mon Sep 17 00:00:00 2001
-From: Gerd Hoffmann 
-Date: Mon, 28 Aug 2017 14:29:06 +0200
-Subject: [PATCH] vga: stop passing pointers to vga_draw_line* functions
-
-Instead pass around the address (aka offset into vga memory).
-Add vga_read_* helper functions which apply vbe_size_mask to
-the address, to make sure the address stays within the valid
-range, similar to the cirrus blitter fixes (commits ffaf857778
-and 026aeffcb4).
-
-Impact:  DoS for privileged guest users.  qemu crashes with
-a segfault, when hitting the guard page after vga memory
-allocation, while reading vga memory for display updates.
-
-Fixes: CVE-2017-13672
-Cc: P J P 
-Reported-by: David Buchanan 
-Signed-off-by: Gerd Hoffmann 
-Message-id: 20170828122906.18993-1-kra...@redhat.com
-
-Upstream-Status: Backport
-[https://git.qemu.org/?p=qemu.git;a=commit;h=3d90c6254863693a6b13d918d2b8682e08bbc681]
-
-CVE: CVE-2017-13672
-
-Signed-off-by: Yi Zhao 

- hw/display/vga-helpers.h | 202 ++-
- hw/display/vga.c |   5 +-
- hw/display/vga_int.h |   1 +
- 3 files changed, 114 insertions(+), 94 deletions(-)
-
-diff --git a/hw/display/vga-helpers.h b/hw/display/vga-helpers.h
-index 94f6de2..5a752b3 100644
 a/hw/display/vga-helpers.h
-+++ b/hw/display/vga-helpers.h
-@@ -95,20 +95,46 @@ static void vga_draw_glyph9(uint8_t *d, int linesize,
- } while (--h);
- }
- 
-+static inline uint8_t vga_read_byte(VGACommonState *vga, uint32_t addr)
-+{
-+return vga->vram_ptr[addr & vga->vbe_size_mask];
-+}
-+
-+static inline uint16_t vga_read_word_le(VGACommonState *vga, uint32_t addr)
-+{
-+uint32_t offset = addr & vga->vbe_size_mask & ~1;
-+uint16_t *ptr = (uint16_t *)(vga->vram_ptr + offset);
-+return lduw_le_p(ptr);
-+}
-+
-+static inline uint16_t vga_read_word_be(VGACommonState *vga, uint32_t addr)
-+{
-+uint32_t offset = addr & vga->vbe_size_mask & ~1;
-+uint16_t *ptr = (uint16_t *)(vga->vram_ptr + offset);
-+return lduw_be_p(ptr);
-+}
-+
-+static inline uint32_t vga_read_dword_le(VGACommonState *vga, uint32_t addr)
-+{
-+uint32_t offset = addr & vga->vbe_size_mask & ~3;
-+uint32_t *ptr = (uint32_t *)(vga->vram_ptr + offset);
-+return ldl_le_p(ptr);
-+}
-+
- /*
-  * 4 color mode
-  */
--static void vga_draw_line2(VGACommonState *s1, uint8_t *d,
--   const uint8_t *s, int width)
-+static void vga_draw_line2(VGACommonState *vga, uint8_t *d,
-+   uint32_t addr, int width)
- {
- uint32_t plane_mask, *palette, data, v;
- int x;
- 
--palette = s1->last_palette;
--plane_mask = mask16[s1->ar[VGA_ATC_PLANE_ENABLE] & 0xf];
-+palette = vga->last_palette;
-+plane_mask = mask16[vga->ar[VGA_ATC_PLANE_ENABLE] & 0xf];
- width >>= 3;
- for(x = 0; x < width; x++) {
--data = ((uint32_t *)s)[0];
-+data = vga_read_dword_le(vga, addr);
- data &= plane_mask;
- v = expand2[GET_PLANE(data, 0)];
- v |= expand2[GET_PLANE(data, 2)] << 2;
-@@ -124,7 +150,7 @@ static void

Re: [OE-core] [PATCH 0/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

2017-10-26 Thread Leonardo Sandoval




On Thu, Oct 26, 2017 at 1:44 PM, Anibal Limón  
wrote:

Hi Leo,

The patch looks good at first glance, i have some comments,

- We need a way to handle the results output because with this you 
will have N results files, may be extend the shell script

to consolidate the results file.


As a proof of concept I use 'parallel' which fits nicely to this 
exercise (one job corresponds to one oe-selftest -r) and with this 
tool, logging can be stored in separate files, each corresponding to a 
job's stdout/stderr. But the important here is that the tool prints 
each job's output into the standard output  either 
first-finished-first-print-to-stdout or keeping the same input order, 
so at the end, you get the same output as running oe-selftest as a 
single job.


- With this if one selftest depends on other there is no way to now 
it and the execution will fail, i searched into the selftest cases

(OETestDepends) and now we don't have dependent cases.


Think about this approach as running oe-selftest in different build 
folders with its own metadata and build folder. Under this scenario, 
the test execution, with the corresponding dependencies will be 
fulfilled and executed correctly, right? the trade off is some extra 
work done on each oe-selftest due to dependencies but this wont hurt 
much in my opinion.


Leo



Cheers,
Anibal

On Thu, Oct 26, 2017 at 12:33 PM, 
 wrote:

From: Leonardo Sandoval 

The below is a profiling experiment, running oe-selftest -r (the 
proposed

implementation, see patch description for more info):

Procedure:

With patch 1/1, multiple oe-selftest jobs can be launched in
parallel. One tool that launch jobs in parallel is GNU Parallel [1], 
allowing
to construct a simpole pipeline to execute all tests with a pool of 
four

jobs:

$ echo $ALLTESTS | time parallel --jobs4 oe-selftest -r

where ALLTESTS is a variable containing all tests cases (modules) 
found by the

the runner (oe-selftest-internal) (i.e. ALLTESTS="$(oe-selftest -m |
awk '{ print $NF }' | grep -v ':')"). This is the result obtained 
from the

above command:

739.57user 120.48system 45:34.61elapsed 31%CPU 
(0avgtext+0avgdata 124600maxresident)k
390908inputs+15984336outputs (291major+20227951minor)pagefaults 
0swaps



The import point on the above numbers is that isolation the 
oe-selftest execution per
module and using a parallelization tool, complete oe-selftest runs 
takes less than an hour,

beating current single-job times observed at main auto-buildes.

Profiling results were obtained on a machine with 88 Intel Xeon with 
88 cores


[1] https://www.gnu.org/software/parallel/

The following changes since commit 
65d23bd7986615fdfb0f1717b615534a2a14ab80:


  README.qemu: qemuppc64 is not supported (2017-10-16 23:54:31 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib 
lsandov1/oe-selftest-own-directory
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lsandov1/oe-selftest-own-directory


Leonardo Sandoval (1):
  scripts/oe-selftest: oe-selftest-internal wrapper scripts that
isolates execution

 scripts/oe-selftest  | 102 
+++

 scripts/oe-selftest-internal |  75 +++
 2 files changed, 129 insertions(+), 48 deletions(-)
 create mode 100755 scripts/oe-selftest-internal

--
2.12.3



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

Re: [OE-core] [PATCH 0/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

2017-10-26 Thread Anibal Limón

Hi Leo,

The patch looks good at first glance, i have some comments,

- We need a way to handle the results output because with this you will
have N results files, may be extend the shell script
to consolidate the results file.
- With this if one selftest depends on other there is no way to now it and
the execution will fail, i searched into the selftest cases
(OETestDepends) and now we don't have dependent cases.

Cheers,
Anibal

On Thu, Oct 26, 2017 at 12:33 PM, <
leonardo.sandoval.gonza...@linux.intel.com> wrote:

> From: Leonardo Sandoval 
>
> The below is a profiling experiment, running oe-selftest -r (the proposed
> implementation, see patch description for more info):
>
> Procedure:
>
> With patch 1/1, multiple oe-selftest jobs can be launched in
> parallel. One tool that launch jobs in parallel is GNU Parallel [1],
> allowing
> to construct a simpole pipeline to execute all tests with a pool of four
> jobs:
>
> $ echo $ALLTESTS | time parallel --jobs4 oe-selftest -r
>
> where ALLTESTS is a variable containing all tests cases (modules) found by
> the
> the runner (oe-selftest-internal) (i.e. ALLTESTS="$(oe-selftest -m |
> awk '{ print $NF }' | grep -v ':')"). This is the result obtained from the
> above command:
>
> 739.57user 120.48system 45:34.61elapsed 31%CPU (0avgtext+0avgdata
> 124600maxresident)k
> 390908inputs+15984336outputs (291major+20227951minor)pagefaults 0swaps
>
>
> The import point on the above numbers is that isolation the oe-selftest
> execution per
> module and using a parallelization tool, complete oe-selftest runs takes
> less than an hour,
> beating current single-job times observed at main auto-buildes.
>
> Profiling results were obtained on a machine with 88 Intel Xeon with 88
> cores
>
> [1] https://www.gnu.org/software/parallel/
>
> The following changes since commit 65d23bd7986615fdfb0f1717b61553
> 4a2a14ab80:
>
>   README.qemu: qemuppc64 is not supported (2017-10-16 23:54:31 +0100)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib lsandov1/oe-selftest-own-
> directory
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=
> lsandov1/oe-selftest-own-directory
>
> Leonardo Sandoval (1):
>   scripts/oe-selftest: oe-selftest-internal wrapper scripts that
> isolates execution
>
>  scripts/oe-selftest  | 102 +++---
> -
>  scripts/oe-selftest-internal |  75 +++
>  2 files changed, 129 insertions(+), 48 deletions(-)
>  create mode 100755 scripts/oe-selftest-internal
>
> --
> 2.12.3
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

2017-10-26 Thread Andre McCurdy

On Thu, Oct 26, 2017 at 10:15 AM, Slater, Joseph
 wrote:
> Okay, I don't know why, but at the time of backfilling the CONSIDERED list is 
> empty!  This is not true if I use "=" to set it unconditionally in 
> arch-mips.inc, but it IS true if I try to set it via anything involving an 
> override (including append).
>
> Isn't getVar() supposed to expand the variable?  Put print msg's in 
> meta/lib/oe/utils.py to see this behavior.

features_backfill() is called from meta/classes/base.bbclass ->
base_eventhandler() in response to bb.event.ConfigParsed (ie "when the
base configuration; which consists of bitbake.conf, base.bbclass and
any global INHERIT statements; has been parsed") so anything assigned
to DISTRO_FEATURES_BACKFILL_CONSIDERED or
MACHINE_FEATURES_BACKFILL_CONSIDERED after that event won't be seen...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] ✗ patchtest: failure for linux-firmware: Bump to bf04291 revision

2017-10-26 Thread Leonardo Sandoval

I believe the patchtest complain is valid, some brief explanation 
should be given.


But the way  it is present need some improvement. We should not be 
listing all licenses, just the ones that change.


Leo


On Thu, Oct 26, 2017 at 11:32 AM, Patchwork 
 wrote:

== Series Details ==

Series: linux-firmware: Bump to bf04291 revision
Revision: 1
URL   : https://patchwork.openembedded.org/series/9498/
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 LIC_FILES_CHKSUM changed on target linux-firmware 
but there was no explanation as to why in the commit message 
[test_lic_files_chksum_modified_not_mentioned]
  Suggested fixProvide a reason for LIC_FILES_CHKSUM change in 
commit message
  Current checksum 
file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc 
file://LICENCE.adsp_sst;md5=615c45b91a5a4a9fe046d6ab9a2df728 
file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 
file://LICENSE.amdgpu;md5=0aa3c2f3e736af320a08a3aeeccecf29 
file://LICENSE.amd-ucode;md5=3a0de451253cc1edbf30a3c621effee3 
file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13  
   file://LICENSE.atmel;md5=aa74ac0c60595dee4d4e239107ea77a3 
file://LICENCE.broadcom_bcm43xx;md5=3160c14df7228891b868060e1951dfbc  
   file://LICENCE.ca0132;md5=209b33e66ee5be0461f13d31da392198 
file://LICENCE.cavium;md5=c37aaffb1ebe5939b2580d073a95daea 
file://LICENCE.chelsio_firmware;md5=819aa8c3fa453f1b258ed8d168a9d903  
   file://LICENCE.cw1200;md5=f0f770864e7a8444a5c5aa9d12a3a7ed 
file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 
file://LICENCE.e100;md5=ec0f84136766df159a3ae6d02acdf5a8 
file://LICENCE.ene_firmware;md5=ed67f0f62f8f798130c29
 6720b7d3921 
file://LICENCE.fw_sst_0f28;md5=6353931c988ad52818ae733ac61cd293 
file://LICENCE.go7007;md5=c0bb9f6aaaba55b0529ee9b30aa66beb 
file://GPL-2;md5=b234ee4d69f5fce4486a80fdaf4a4263 
file://LICENSE.hfi1_firmware;md5=5e7b6e586ce7339d12689e49931ad444 
file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 
file://LICENSE.i915;md5=2b0b2e0d20984affd4490ba2cba02570 
file://LICENCE.ibt_firmware;md5=fdbee1ddfe0fb7ab0b2fcd6b454a366b 
file://LICENCE.IntcSST2;md5=9e7d8bea77612d7cc7d9e9b54b623062 
file://LICENCE.it913x;md5=1fbf727bfb6a949810c4dbfa7e6ce4f8 
file://LICENCE.iwlwifi_firmware;md5=3fd842911ea93c29cd32679aa23e1c88  
   file://LICENCE.kaweth;md5=b1d876e562f4b3b8d391ad8395dfe03f 
file://LICENCE.Marvell;md5=9ddea1734a4baf3c78d845151f42a37a 
file://LICENCE.moxa;md5=1086614767d8ccf744a923289d3d4261 
file://LICENCE.myri10ge_firmware;md5=42e32fb89f6b959ca222e25ac8df8fed 
file://LICENCE.Netronome;md5=cd2a3e6effe3cdf42731575b8e9477ed
 file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07 
file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd 
file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 
file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa 
file://LICENCE.qat_firmware;md5=9e7d8bea77612d7cc7d9e9b54b623062 
file://LICENCE.qla1280;md5=d6895732e622d950609093223a2c4f5d 
file://LICENCE.qla2xxx;md5=505855e921b75f1be4a437ad9b79dff0 
file://LICENSE.QualcommAtheros_ar3k;md5=b5fe244fb2b532311de1472a3bc06da5 

file://LICENSE.QualcommAtheros_ath10k;md5=cb42b686ee5f5cb890275e4321db60a8 
file://LICENCE.r8a779x_usb3;md5=4c1671656153025d7076105a5da7e498  
   file://LICENSE.radeon;md5=68ec28bacb3613200bca44f404c69b16 
file://LICENCE.ralink_a_mediatek_company_firmware;md5=728f1a85fd53fd67fa8d7afb080bc435 

file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd 
file://LICENCE.rtlwifi_firmware.txt;md5=00d06cfd3eddd5a2698948ead2
 ad54a5 
file://LICENSE.sdma_firmware;md5=51e8c19ecc2270f4b8ea30341ad63ce9 
file://LICENCE.siano;md5=4556c1bf830067f12ca151ad953ec2a5 
file://LICENCE.tda7706-firmware.txt;md5=835997cf5e3c131d0695c7d9103e 

file://LICENCE.ti-connectivity;md5=c5e02be633f1499c109d1652514d85ec   
  file://LICENCE.ti-keystone;md5=3a86335d32864b0bef996bee26cc0f2c 
file://LICENCE.ueagle-atm4-firmware;md5=4ed7ea6b507ccc583b9d594417714118 
file://LICENCE.via_vt6656;md5=e4159694cba42d4377a912e78a6e850f
 file://LICENCE.wl1251;md5=ad3f81922bb9e197014bb187289d3b5b 
file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 
file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 
file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca 
file://WHENCE;md5=08f6d4371353cac5f6fc271d5407c63e
  New checksum 
file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc 
file://LICENCE.adsp_sst;md5=615c45b91a5a4a9fe046d6ab9a2df728 
file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31

[OE-core] [PATCH 0/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

2017-10-26 Thread leonardo . sandoval . gonzalez

From: Leonardo Sandoval 

The below is a profiling experiment, running oe-selftest -r (the proposed
implementation, see patch description for more info):

Procedure:

With patch 1/1, multiple oe-selftest jobs can be launched in
parallel. One tool that launch jobs in parallel is GNU Parallel [1], allowing
to construct a simpole pipeline to execute all tests with a pool of four
jobs:

$ echo $ALLTESTS | time parallel --jobs4 oe-selftest -r

where ALLTESTS is a variable containing all tests cases (modules) found by the
the runner (oe-selftest-internal) (i.e. ALLTESTS="$(oe-selftest -m |
awk '{ print $NF }' | grep -v ':')"). This is the result obtained from the
above command:

739.57user 120.48system 45:34.61elapsed 31%CPU (0avgtext+0avgdata 
124600maxresident)k
390908inputs+15984336outputs (291major+20227951minor)pagefaults 0swaps


The import point on the above numbers is that isolation the oe-selftest 
execution per
module and using a parallelization tool, complete oe-selftest runs takes less 
than an hour,
beating current single-job times observed at main auto-buildes.

Profiling results were obtained on a machine with 88 Intel Xeon with 88 cores

[1] https://www.gnu.org/software/parallel/

The following changes since commit 65d23bd7986615fdfb0f1717b615534a2a14ab80:

  README.qemu: qemuppc64 is not supported (2017-10-16 23:54:31 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib lsandov1/oe-selftest-own-directory
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lsandov1/oe-selftest-own-directory

Leonardo Sandoval (1):
  scripts/oe-selftest: oe-selftest-internal wrapper scripts that
isolates execution

 scripts/oe-selftest  | 102 +++
 scripts/oe-selftest-internal |  75 +++
 2 files changed, 129 insertions(+), 48 deletions(-)
 create mode 100755 scripts/oe-selftest-internal

-- 
2.12.3

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

[OE-core] [PATCH 1/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

2017-10-26 Thread leonardo . sandoval . gonzalez

From: Leonardo Sandoval 

The main idea is to isolate the oe-selftest execution so neither the current
build dir nor the configuration data is touch/polluted. This approach uses
a wrapper script (which is the one presented on this commit) which creates
a unique directory and inside it does a shallow of repo(s) (OE-Core and 
Bitbake),
re-initializes the enviroment (re-sources oe-init-build-env) and finally 
launches
the oe-selftest-internal (which used to be oe-selftest) command, passing command
arguments to the latter.

The new build directory created when re-initializing the enviroment has the
same configuration data (local.conf, auto.conf, site.conf) as the
main build directory. The latter means that one can set DL_DIR and SSTATE_DIR
into /conf/site.conf and the oe-selftest execution will use 
this.

[YOCTO #11429]

Signed-off-by: Leonardo Sandoval 
---
 scripts/oe-selftest  | 102 +++
 scripts/oe-selftest-internal |  75 +++
 2 files changed, 129 insertions(+), 48 deletions(-)
 create mode 100755 scripts/oe-selftest-internal

diff --git a/scripts/oe-selftest b/scripts/oe-selftest
index 1bf860a415..f3ce89cedb 100755
--- a/scripts/oe-selftest
+++ b/scripts/oe-selftest
@@ -1,5 +1,7 @@
-#!/usr/bin/env python3
+#!/bin/sh
 
+# scripts/oe-selftest: calls oe-selftest-internal in a isolated environment
+#
 # Copyright (c) 2013-2017 Intel Corporation
 #
 # This program is free software; you can redistribute it and/or modify
@@ -14,62 +16,66 @@
 # You should have received a copy of the GNU General Public License along
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+
+# Variable definitions
+ORIGBUILDDIR="$BUILDDIR"
+OESELFTESTSCRIPTDIR="$(which oe-selftest)"
+SCRIPTSDIR="$(dirname $OESELFTESTSCRIPTDIR)"
+OECOREDIR="$(dirname $SCRIPTSDIR)"
+
+# oe-selftest-$$ related
+OESELFTESTDIR="$ORIGBUILDDIR/oe-selftest-$$"
+OESELFTESTOECOREDIR="$OESELFTESTDIR/openembedded-core"
+OESELFTESTBUILDDIR="$OESELFTESTDIR/openembedded-core/build"
+TEMPLATEPATH="$OESELFTESTDIR/template/conf"
 
-# DESCRIPTION
-# This script runs tests defined in meta/lib/oeqa/selftest/
-# It's purpose is to automate the testing of different bitbake tools.
-# To use it you just need to source your build environment setup script and
-# add the meta-selftest layer to your BBLAYERS.
-# Call the script as: "oe-selftest -a" to run all the tests in 
meta/lib/oeqa/selftest/
-# Call the script as: "oe-selftest -r .." to run just a 
single test
-# E.g: "oe-selftest -r bblayers.BitbakeLayers" will run just the BitbakeLayers 
class from meta/lib/oeqa/selftest/bblayers.py
+# 0. Return immediately in case no test execution
+ADDTESTS="$(echo "$@" | grep -i '\-a')"
+SOMETESTS="$(echo "$@" | grep -i '\-r')"
+if [ -z "$ADDTESTS" -a -z "$SOMETESTS" ]; then
+if [ -z "$@" ]; then
+   oe-selftest-internal -h
+else
+   oe-selftest-internal "$@"
+fi
+exit 0
+fi
 
+# 1. All work will be done under OESELFTESTDIR
+mkdir $OESELFTESTDIR && cd $OESELFTESTDIR
 
+# 2.1 Shallow clone OE-Core
+git clone file://$OECOREDIR --depth 1 $OESELFTESTOECOREDIR
 
-import os
-import sys
-import argparse
-import logging
+# 2.2 Shallow clone bitbake if necessary (if OE-Core is embedded on a combo 
repo, like Poky, there is no need)
+if [ ! -d "$OESELFTESTOECOREDIR/bitbake" ]; then
+git clone file://$OECOREDIR/bitbake --depth 1 $OESELFTESTOECOREDIR/bitbake
+fi
 
-scripts_path = os.path.dirname(os.path.realpath(__file__))
-lib_path = scripts_path + '/lib'
-sys.path = sys.path + [lib_path]
-import argparse_oe
-import scriptutils
-import scriptpath
-scriptpath.add_oe_lib_path()
-scriptpath.add_bitbake_lib_path()
+# 3. Template: create template directory based on BUILDIR/conf/local.conf
+mkdir -p $TEMPLATEPATH
+cp $ORIGBUILDDIR/conf/local.conf $TEMPLATEPATH/local.conf.sample
 
-from oeqa.utils import load_test_components
-from oeqa.core.exception import OEQAPreRun
+# 4. re-initialized environment with new metadata and templateconf environement
+cd $OESELFTESTOECOREDIR
+export TEMPLATEPATH && source ./oe-init-build-env $OESELFTESTBUILDDIR
 
-logger = scriptutils.logger_create('oe-selftest', stream=sys.stdout)
+# 5. Respect any site.conf and/or auto.conf and place it into conf directory
+if [ -r "$ORIGBUILDDIR/conf/site.conf" ]; then
+cp -f $ORIGBUILDDIR/conf/site.conf $OESELFTESTBUILDDIR/conf
+fi
+if [ -r "$ORIGBUILDDIR/conf/auto.conf" ]; then
+cp -f $ORIGBUILDDIR/conf/auto.conf $OESELFTESTBUILDDIR/conf
+fi
 
-def main():
-description = "Script that runs unit tests against bitbake and other Yocto 
related tools. The goal is to validate tools functionality and metadata 
integrity. Refer to https://wiki.yoctoproject.org/wiki/Oe-selftest for more 
information."
-parser =

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

2017-10-26 Thread Slater, Joseph

Okay, I don't know why, but at the time of backfilling the CONSIDERED list is 
empty!  This is not true if I use "=" to set it unconditionally in 
arch-mips.inc, but it IS true if I try to set it via anything involving an 
override (including append).

Isn't getVar() supposed to expand the variable?  Put print msg's in 
meta/lib/oe/utils.py to see this behavior.

Joe


From: Slater, Joseph
Sent: Wednesday, October 25, 2017 11:24 AM
To: Andre McCurdy; Alexander Kanavin
Cc: OE Core mailing list
Subject: RE: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

I found that libn32-gobject-introspection would not compile without the remove, 
but I could check again.  Joe

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com]
Sent: Wednesday, October 25, 2017 10:19 AM
To: Alexander Kanavin
Cc: Slater, Joseph; OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On Wed, Oct 25, 2017 at 4:14 AM, Alexander Kanavin 
 wrote:
> On 10/25/2017 02:43 AM, Andre McCurdy wrote:
>>
>> On Tue, Oct 24, 2017 at 4:23 PM, Joe Slater  wrote:
>>>
>>> qemu-usermode is only available for mips64 and o32 code.
>>
>> Isn't that already handled by
>> meta/conf/machine/include/mips/arch-mips.inc
>>
>># user mode qemu doesn't support mips64 n32: "Invalid ELF image
>> for this architecture"
>>MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
>> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> Yes, but this is really unreadable isn't it :) I don't see how anyone
> could grasp that the above means "remove qemu-usermode from
> MACHINE_FEATURES if
> n32 is in TUNE_FEATURES" (without diving into documentation).
>
> Any better way to express this would be appreciated.

Yes, BACKFILL_CONSIDERED always has been concept which baffles a lot of users - 
especially so since we quietly redefined it to mean not only "functionality 
which used to always be enabled but is now configurable" but now also 
"functionality which was not previously enabled but is now configurable and we 
want to enable by default and make it difficult for users to accidentally leave 
disabled".
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for linux-firmware: Bump to bf04291 revision

2017-10-26 Thread Patchwork

== Series Details ==

Series: linux-firmware: Bump to bf04291 revision
Revision: 1
URL   : https://patchwork.openembedded.org/series/9498/
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 LIC_FILES_CHKSUM changed on target linux-firmware but there 
was no explanation as to why in the commit message 
[test_lic_files_chksum_modified_not_mentioned] 
  Suggested fixProvide a reason for LIC_FILES_CHKSUM change in commit 
message
  Current checksum 
file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc 
file://LICENCE.adsp_sst;md5=615c45b91a5a4a9fe046d6ab9a2df728 
file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 
file://LICENSE.amdgpu;md5=0aa3c2f3e736af320a08a3aeeccecf29 
file://LICENSE.amd-ucode;md5=3a0de451253cc1edbf30a3c621effee3 
file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 
file://LICENSE.atmel;md5=aa74ac0c60595dee4d4e239107ea77a3 
file://LICENCE.broadcom_bcm43xx;md5=3160c14df7228891b868060e1951dfbc 
file://LICENCE.ca0132;md5=209b33e66ee5be0461f13d31da392198 
file://LICENCE.cavium;md5=c37aaffb1ebe5939b2580d073a95daea 
file://LICENCE.chelsio_firmware;md5=819aa8c3fa453f1b258ed8d168a9d903 
file://LICENCE.cw1200;md5=f0f770864e7a8444a5c5aa9d12a3a7ed 
file://LICENSE.dib0700;md5=f7411825c8a555a1a3e5eab9ca773431 
file://LICENCE.e100;md5=ec0f84136766df159a3ae6d02acdf5a8 
file://LICENCE.ene_firmware;md5=ed67f0f62f8f798130c29
 6720b7d3921 
file://LICENCE.fw_sst_0f28;md5=6353931c988ad52818ae733ac61cd293 
file://LICENCE.go7007;md5=c0bb9f6aaaba55b0529ee9b30aa66beb 
file://GPL-2;md5=b234ee4d69f5fce4486a80fdaf4a4263 
file://LICENSE.hfi1_firmware;md5=5e7b6e586ce7339d12689e49931ad444 
file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 
file://LICENSE.i915;md5=2b0b2e0d20984affd4490ba2cba02570 
file://LICENCE.ibt_firmware;md5=fdbee1ddfe0fb7ab0b2fcd6b454a366b 
file://LICENCE.IntcSST2;md5=9e7d8bea77612d7cc7d9e9b54b623062 
file://LICENCE.it913x;md5=1fbf727bfb6a949810c4dbfa7e6ce4f8 
file://LICENCE.iwlwifi_firmware;md5=3fd842911ea93c29cd32679aa23e1c88 
file://LICENCE.kaweth;md5=b1d876e562f4b3b8d391ad8395dfe03f 
file://LICENCE.Marvell;md5=9ddea1734a4baf3c78d845151f42a37a 
file://LICENCE.moxa;md5=1086614767d8ccf744a923289d3d4261 
file://LICENCE.myri10ge_firmware;md5=42e32fb89f6b959ca222e25ac8df8fed 
file://LICENCE.Netronome;md5=cd2a3e6effe3cdf42731575b8e9477ed 
 file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07 
file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd 
file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 
file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa 
file://LICENCE.qat_firmware;md5=9e7d8bea77612d7cc7d9e9b54b623062 
file://LICENCE.qla1280;md5=d6895732e622d950609093223a2c4f5d 
file://LICENCE.qla2xxx;md5=505855e921b75f1be4a437ad9b79dff0 
file://LICENSE.QualcommAtheros_ar3k;md5=b5fe244fb2b532311de1472a3bc06da5 
file://LICENSE.QualcommAtheros_ath10k;md5=cb42b686ee5f5cb890275e4321db60a8 
file://LICENCE.r8a779x_usb3;md5=4c1671656153025d7076105a5da7e498 
file://LICENSE.radeon;md5=68ec28bacb3613200bca44f404c69b16 
file://LICENCE.ralink_a_mediatek_company_firmware;md5=728f1a85fd53fd67fa8d7afb080bc435
 file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd
 file://LICENCE.rtlwifi_firmware.txt;md5=00d06cfd3eddd5a2698948ead2
 ad54a5 file://LICENSE.sdma_firmware;md5=51e8c19ecc2270f4b8ea30341ad63ce9   
  file://LICENCE.siano;md5=4556c1bf830067f12ca151ad953ec2a5 
file://LICENCE.tda7706-firmware.txt;md5=835997cf5e3c131d0695c7d9103e 
file://LICENCE.ti-connectivity;md5=c5e02be633f1499c109d1652514d85ec 
file://LICENCE.ti-keystone;md5=3a86335d32864b0bef996bee26cc0f2c 
file://LICENCE.ueagle-atm4-firmware;md5=4ed7ea6b507ccc583b9d594417714118 
file://LICENCE.via_vt6656;md5=e4159694cba42d4377a912e78a6e850f 
file://LICENCE.wl1251;md5=ad3f81922bb9e197014bb187289d3b5b 
file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 
file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 
file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca 
file://WHENCE;md5=08f6d4371353cac5f6fc271d5407c63e 
  New checksum 
file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc 
file://LICENCE.adsp_sst;md5=615c45b91a5a4a9fe046d6ab9a2df728 
file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 
file://LICENSE.amdgpu;md5=0aa3c2f3e736af320a08a3aeeccecf29 
file://LICENSE.amd-ucode;md5=3a0de451253cc1edbf30a3c621effee3 
file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 
file://LICENSE.atmel;md5=aa74ac0c60595dee4d4e239107ea77a3

[OE-core] [PATCH] linux-firmware: Bump to bf04291 revision

2017-10-26 Thread Otavio Salvador

This includes following changes:

bf04291 WHENCE: Add new qed firmware
d8fc990 WHENCE: Add new radeon firmware
7245319 WHENCE: Fix syntax error for iwlwifi-8265-31.ucode entry
18d71a8 Revert "ath10k: QCA988X hw2.0: update firmware to 10.2.4.70.63-2"
4ebfab3 ath10k: QCA6174 hw3.0: update board-2.bin
96a7402 ath10k: QCA6174 hw3.0: update firmware-6.bin to 
WLAN.RM.4.4.1-00051-QCARMSWP-1
59bf7e2 cxgb4: update firmware to revision 1.16.63.0

Signed-off-by: Otavio Salvador 
---

 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 0338ba8ac2..3ea1d883b1 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -116,7 +116,7 @@ LIC_FILES_CHKSUM = "\
 file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \
 file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
 file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
-file://WHENCE;md5=08f6d4371353cac5f6fc271d5407c63e \
+file://WHENCE;md5=038edbc9e744171d8b6235e0224028ba \
 "
 
 # These are not common licenses, set NO_GENERIC_LICENSE for them
@@ -178,7 +178,7 @@ NO_GENERIC_LICENSE[Firmware-xc5000] = "LICENCE.xc5000"
 NO_GENERIC_LICENSE[Firmware-xc5000c] = "LICENCE.xc5000c"
 NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
 
-SRCREV = "a61ac5cf8374edbfe692d12f805a1b194f7fead2"
+SRCREV = "bf04291309d3169c0ad3b8db52564235bbd08e30"
 PE = "1"
 PV = "0.0+git${SRCPV}"
 
-- 
2.14.3

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

Re: [OE-core] [PATCH 1/2] qemu: upgrade to 2.10.1

2017-10-26 Thread Patrick Ohly

On Thu, 2017-10-26 at 09:37 -0500, Leonardo Sandoval wrote:
> I used devtool upgrade and the only hunk I need to remove was
> thisone, the rest were applied cleanly.

The rest was applied *silently*, but not *cleanly*. The lesson here is
basically that developers shouldn't blindly trust the tools. If
something is odd, investigate.

What was odd in this case is that it looked like a patch was partially
merged. Why would anyone do that? And indeed, it was merged completely.

-- 
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 1/2] qemu: upgrade to 2.10.1

2017-10-26 Thread Leonardo Sandoval


Hi Patrick

On Thu, Oct 26, 2017 at 4:33 AM, Patrick Ohly  
wrote:

On Thu, 2017-10-19 at 13:10 -0700,
leonardo.sandoval.gonza...@linux.intel.com wrote:

 From: Leonardo Sandoval 

 All CVE patches removed because these are already integrated in
 2.10.1.

...

  meta/recipes-devtools/qemu/qemu/glibc-2.25.patch   |  14 -

diff --git a/meta/recipes-devtools/qemu/qemu/glibc-2.25.patch

 b/meta/recipes-devtools/qemu/qemu/glibc-2.25.patch
 index a6908bdbf9..25569449e4 100644
 --- a/meta/recipes-devtools/qemu/qemu/glibc-
 2.25.patch
 +++ b/meta/recipes-devtools/qemu/qemu/glibc-2.25.patch
 @@ -72,17 +72,3 @@ diff -uNr qemu-2.8.0.orig/configure qemu-
 2.8.0/configure
   # Hold two types of flag:
   #   CONFIG_THREAD_SETNAME_BYTHREAD  - we've got a way of setting
 the name on
   # a thread we have a handle to
 -diff -uNr qemu-2.8.0.orig/include/sysemu/os-posix.h qemu-
 2.8.0/include/sysemu/os-posix.h
  qemu-2.8.0.orig/include/sysemu/os-posix.h 2016-12-20
 21:16:48.0 +0100
 -+++ qemu-2.8.0/include/sysemu/os-posix.h  2017-02-21
 19:07:18.009090381 +0100
 -@@ -34,6 +34,10 @@
 - #include 
 - #include 
 -
 -+#ifdef CONFIG_SYSMACROS
 -+#include 
 -+#endif
 -+
 - void os_set_line_buffering(void);
 - void os_set_proc_name(const char *s);
 - void os_setup_signal_handling(void);


Instead of removing just this hunk from the glibc-2.25.patch, please
remove the entire patch. It is already in 2.10.0.

I was about to send a patch doing just that when I saw your version
update. Here's the commit message for my patch:

The patch is already present in the upstream 2.10.0. Patching 
during a

build succeeds by adding the same hunks again to configure (which
seems to cause no problems during build) and skipping the one 
which it
detects as already applied, but "devtool modify qemu-native" is 
more

picky:


I used devtool upgrade and the only hunk I need to remove was this one, 
the rest were applied cleanly. Let me check again and send  a V2 asap.


Leo





ERROR: Applying 'glibc-2.25.patch' failed:
checking file configure
Hunk #1 succeeded at 4986 with fuzz 2 (offset 259 lines).
checking file configure
Hunk #1 succeeded at 6047 with fuzz 1 (offset 352 lines).
checking file include/sysemu/os-posix.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: 
.../devtooltmp-6_22hcm3/temp/log.do_patch.31897
NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to 
be rerun and 1 failed.

ERROR: Extracting source for qemu-native failed

--
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

[OE-core] [PATCH] git: bump version to 2.14.3

2017-10-26 Thread Ovidiu Panait

Bump version to 2.14.3 in order to eliminate CVE-2017-14867 vulnerability.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-14867

Upstream patches:
https://github.com/git/git/commit/9a42c03cb71eaa9d41ba67275de38c997a791c32
https://github.com/git/git/commit/fce13af5d20cad8dcb2d0e47bcf01b6960f08e55
https://github.com/git/git/commit/27dd73871f814062737c327103ee43f1eb7f30d9
https://github.com/git/git/commit/46203ac24dc7e6b5a8d4f1b024ed93591705d47b
https://github.com/git/git/commit/5b4efea666951efe0770f8d5a301f8917015315f
https://github.com/git/git/commit/8d0fad0a7a6ba34fd706c148fa7ed1f8eb2b8b26

Signed-off-by: Ovidiu Panait 
---
 meta/recipes-devtools/git/git_2.13.3.bb | 11 ---
 meta/recipes-devtools/git/git_2.14.3.bb | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)
 delete mode 100644 meta/recipes-devtools/git/git_2.13.3.bb
 create mode 100644 meta/recipes-devtools/git/git_2.14.3.bb

diff --git a/meta/recipes-devtools/git/git_2.13.3.bb 
b/meta/recipes-devtools/git/git_2.13.3.bb
deleted file mode 100644
index b3e3887..000
--- a/meta/recipes-devtools/git/git_2.13.3.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require git.inc
-
-EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
- 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
- "
-EXTRA_OEMAKE += "NO_GETTEXT=1"
-
-SRC_URI[tarball.md5sum] = "d2dc550f6693ba7e5b16212b2714f59f"
-SRC_URI[tarball.sha256sum] = 
"1497001772f630d49809e981672edfe3e3ce1a1d18e905cd539c4d2f4dbcd75a"
-SRC_URI[manpages.md5sum] = "3037d11a4f4cdd19435871c267ca48b4"
-SRC_URI[manpages.sha256sum] = 
"f9b302eeb08ce08934e7afb42280ce9294411fbf5f7b6ac3fcc236e8031f10c5"
diff --git a/meta/recipes-devtools/git/git_2.14.3.bb 
b/meta/recipes-devtools/git/git_2.14.3.bb
new file mode 100644
index 000..4628fc7
--- /dev/null
+++ b/meta/recipes-devtools/git/git_2.14.3.bb
@@ -0,0 +1,11 @@
+require git.inc
+
+EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
+ 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
+ "
+EXTRA_OEMAKE += "NO_GETTEXT=1"
+
+SRC_URI[tarball.md5sum] = "034a737e20a95194a5c274fff2333a67"
+SRC_URI[tarball.sha256sum] = 
"0236d3ba8a1bea779dfecc0ed0bb4ad68ab8601d14435dd8c08416f78d7f"
+SRC_URI[manpages.md5sum] = "b0f9be472139b978954bd0e132f1db8a"
+SRC_URI[manpages.sha256sum] = 
"d64e10b6e3b351231e7a187af038d9c87e1225a5c90eeff8dece839a8d383ca6"
-- 
2.10.2

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

Re: [OE-core] [V2][PATCH 2/2] tzdata: update 2017c

2017-10-26 Thread Denys Dmytriyenko

On Wed, Oct 25, 2017 at 05:57:16AM -0700, Armin Kuster wrote:
> LICENSE changed to to rewording

"due to"

> https://github.com/eggert/tz/commit/7097a652778d35acf747d14f8bf7b3ced479bbc0#diff-9879d6db96fd29134fc802214163b95a
> 
>   Briefly:
>   Northern Cyprus switches from +03 to +02/+03 on 2017-10-29.
>   Fiji ends DST 2018-01-14, not 2018-01-21.
>   Namibia switches from +01/+02 to +02 on 2018-04-01.
>   Sudan switches from +03 to +02 on 2017-11-01.
>   Tonga likely switches from +13/+14 to +13 on 2017-11-05.
>   Turks & Caicos switches from -04 to -05/-04 on 2018-11-04.
>   A new file tzdata.zi now holds a small text copy of all data.
>   The zic input format has been regularized slightly.
> 
>   Changes to future time stamps
> 
> Northern Cyprus has decided to resume EU rules starting
> 2017-10-29, thus reinstituting winter time.
> 
> Fiji ends DST 2018-01-14 instead of the 2018-01-21 previously
> predicted.  (Thanks to Dominic Fok.)  Adjust future predictions
> accordingly.
> 
> Namibia will switch from +01 with DST to +02 all year on
> 2017-09-03 at 02:00.  This affects UT offsets starting 2018-04-01
> at 02:00.  (Thanks to Steffen Thorsen.)
> 
> Sudan will switch from +03 to +02 on 2017-11-01.  (Thanks to Ahmed
> Atyya and Yahia Abdalla.)  South Sudan is not switching, so
> Africa/Juba is no longer a link to Africa/Khartoum.
> 
> Tonga has likely ended its experiment with DST, and will not
> adjust its clocks on 2017-11-05.  Although Tonga has not announced
> whether it will continue to observe DST, the IATA is assuming that
> it will not.  (Thanks to David Wade.)
> 
> Turks & Caicos will switch from -04 all year to -05 with US DST on
> 2018-03-11 at 03:00.  This affects UT offsets starting 2018-11-04
> at 02:00.  (Thanks to Steffen Thorsen.)
> 
>   Changes to past time stamps
> 
> Namibia switched from +02 to +01 on 1994-03-21, not 1994-04-03.
> (Thanks to Arthur David Olson.)
> 
> Detroit did not observe DST in 1967.
> 
> Use railway time for Asia/Kolkata before 1941, by switching to
> Madras local time (UT +052110) in 1870, then to IST (UT +0530) in
> 1906.  Also, treat 1941-2's +0630 as DST, like 1942-5.
> 
> Europe/Dublin's 1946 and 1947 fallback transitions occurred at
> 02:00 standard time, not 02:00 DST.  (Thanks to Michael Deckers.)
> 
> Pacific/Apia and Pacific/Pago_Pago switched from Antipodean to
> American time in 1892, not 1879.  (Thanks to Michael Deckers.)
> 
> Adjust the 1867 transition in Alaska to better reflect the
> historical record, by changing it to occur on 1867-10-18 at 15:30
> Sitka time rather than at the start of 1867-10-17 local time.
> Although strictly speaking this is accurate only for Sitka,
> the rest of Alaska's blanks need to be filled in somehow.
> 
> Fix off-by-one errors in UT offsets for Adak and Nome before 1867.
> (Thanks to Michael Deckers.)
> 
> Add 7 s to the UT offset in Asia/Yangon before 1920.
> 
>   Changes to zone names
> 
> Remove Canada/East-Saskatchewan from the 'backward' file, as it
> exceeded the 14-character limit and was an unused misnomer anyway.
> 
> Signed-off-by: Armin Kuster 
> ---
>  meta/recipes-extended/tzdata/{tzdata_2017b.bb => tzdata_2017c.bb} | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>  rename meta/recipes-extended/tzdata/{tzdata_2017b.bb => tzdata_2017c.bb} 
> (97%)
> 
> diff --git a/meta/recipes-extended/tzdata/tzdata_2017b.bb 
> b/meta/recipes-extended/tzdata/tzdata_2017c.bb
> similarity index 97%
> rename from meta/recipes-extended/tzdata/tzdata_2017b.bb
> rename to meta/recipes-extended/tzdata/tzdata_2017c.bb
> index 55e8976..9e5b929 100644
> --- a/meta/recipes-extended/tzdata/tzdata_2017b.bb
> +++ b/meta/recipes-extended/tzdata/tzdata_2017c.bb
> @@ -2,15 +2,15 @@ SUMMARY = "Timezone data"
>  HOMEPAGE = "http://www.iana.org/time-zones;
>  SECTION = "base"
>  LICENSE = "PD & BSD & BSD-3-Clause"
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=ef1a352b901ee7b75a75df8171d6aca7"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=c679c9d6b02bc2757b3eaf8f53c43fba"
>  
>  DEPENDS = "tzcode-native"
>  
>  SRC_URI = 
> "http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata;
>  UPSTREAM_CHECK_URI = "http://www.iana.org/time-zones;
>  
> -SRC_URI[tzdata.md5sum] = "50dc0dc50c68644c1f70804f2e7a1625"
> -SRC_URI[tzdata.sha256sum] = 
> "f8242a522ea3496b0ce4ff4f2e75a049178da21001a08b8e666d8cbe07d18086"
> +SRC_URI[tzdata.md5sum] = "1e751e7e08f8b68530674f04619d894d"
> +SRC_URI[tzdata.sha256sum] = 
> "d6543f92a929826318e2f44ff3a7611ce5f565a43e10250b42599d0ba4cbd90b"
>  
>  inherit allarch
>  
> -- 
> 2.7.4
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--

Re: [OE-core] GCC 4.9 and Morty

2017-10-26 Thread Denys Dmytriyenko

On Thu, Oct 26, 2017 at 08:25:00AM -0400, Denys Dmytriyenko wrote:
> On Tue, Oct 24, 2017 at 06:37:17PM +, Lee, Yong wrote:
> > Thank you.
> > I switched to internal toolchain and building GCC 5.4 (included in meta) is 
> > complete and is onto glibc.
> > 
> > In summary, TI SDK appears to be broken as the none-default GCC version 
> > included in their package (ie. Linaro 4.9 and Linaro 5.2) fails to build.
> 
> There's nothing wrong with TI SDK - the issue is often with the Linaro 
> prebuilt toolchain changing little things from version to version and 
> breaking 
> corresponding recipes. Unfortunately, external toolchain is required, hence I 
> only support 1 specific Linaro toolchain version per release - 7.x in rocko, 
> 6.x in morty, 5.x in krogoth, 4.9 in fido, etc. So, if you need a different 
> Linaro toolchain version, either switch to a corresponding release setup, or 
> try porting those recipes.
> Alternatively, you can always switch to internal toolchain by simply passing 
> TOOLCHAIN_TYPE=internal to TI SDK build. It's not the default and doesn't get 
> tested very much against TI SDK, but I try to ensure nothing is broken in 
> each 
> relesae. Though, gcc7 is still work in progress.

BTW, meta-arago has its own mailing list, as well as meta-linaro has one too. 
Complaining to OE-Core about specifics like this is like posting to LKML about 
issues with your Linux distro... As Khem said - ask your SDK provider. And 
maybe try doing that first - could probably save you a lot of headache...


> > -Original Message-
> > From: Khem Raj [mailto:raj.k...@gmail.com] 
> > Sent: Tuesday, October 24, 2017 1:46 PM
> > To: Lee, Yong 
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] GCC 4.9 and Morty
> > 
> > On Tue, Oct 24, 2017 at 10:33 AM, Lee, Yong  
> > wrote:
> > > Thanks Raj for the input. Attached the logs. Please take a look.
> > > The .diff file is based on the toolchain-linaro.inc file shipped with 
> > > TI's SDK [1].
> > >
> > 
> > Your changes look fine.
> > 
> > > I will try to configure the SDK to use the internal toolchain and see if 
> > > I can decouple myself from the external toolchain to simplify things.
> > >
> > 
> > you might have to bug your SDK provider for gcc 4.9 build issue
> > 
> > 
> > > Adam
> > >
> > > [1] 
> > > http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-dis
> > > tro/conf/distro/include/toolchain-linaro.inc;h=20a65174f269c1e1a5984c5
> > > 476a2ab4e5dfc42b5;hb=refs/heads/morty
> > >
> > > -Original Message-
> > > From: Khem Raj [mailto:raj.k...@gmail.com]
> > > Sent: Tuesday, October 24, 2017 12:26 PM
> > > To: Lee, Yong 
> > > Cc: openembedded-core@lists.openembedded.org
> > > Subject: Re: [OE-core] GCC 4.9 and Morty
> > >
> > > *EXTERNAL EMAIL*
> > >
> > >
> > > On Tue, Oct 24, 2017 at 6:56 AM, Lee, Yong  
> > > wrote:
> > >> I have a bunch of apps that require an old version of GCC (4.9 or less).
> > >>
> > >> There are a few versions of GCC available in my Morty based SDK.
> > >>
> > >>
> > >>
> > >> build@6e35408e8fa5:~/tisdk/build$ bitbake-layers show-recipes gcc
> > >>
> > >> WARNING: No recipes available for:
> > >>
> > >>
> > >> /home/build/tisdk/sources/meta-openamp/recipes-bsp/device-tree/device
> > >> -
> > >> tree-generation_%.bbappend
> > >>
> > >> Parsing recipes..done.
> > >>
> > >> === Matching recipes: ===
> > >>
> > >> gcc:
> > >>
> > >>   meta-linaro-toolchain linaro-4.9
> > >>
> > >>   meta-linaro-toolchain linaro-6.2
> > >>
> > >>   meta 6.2.0
> > >>
> > >>   meta 5.4.0
> > >>
> > >>   meta-linaro-toolchain linaro-5.3
> > >>
> > >>   meta-linaro-toolchain linaro-5.2
> > >>
> > >>
> > >>
> > >> Immediately I have set the PREFERRED_VERSION of gcc to 4.9 but 
> > >> bitbake does not go beyond configuration.
> > >>
> > >>
> > >
> > > Please post the error and change you did to enable 4.9
> > >
> > >>
> > >> I believe 4.9 + morty combination has not been tested at all. I 
> > >> understand my apps need to get updated, but that’s not my call.
> > >
> > > OE-core and yocto releases by default do not test toolchains coming 
> > > from other layers so essentially 6.2 is whats the default compiler 
> > > with morty and thats what is most tested however, others might have 
> > > tested the other combinations with morty,
> > -- 
> > ___
> > 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
-- 
___
Openembedded-core mailing list

Re: [OE-core] GCC 4.9 and Morty

2017-10-26 Thread Denys Dmytriyenko

On Tue, Oct 24, 2017 at 06:37:17PM +, Lee, Yong wrote:
> Thank you.
> I switched to internal toolchain and building GCC 5.4 (included in meta) is 
> complete and is onto glibc.
> 
> In summary, TI SDK appears to be broken as the none-default GCC version 
> included in their package (ie. Linaro 4.9 and Linaro 5.2) fails to build.

There's nothing wrong with TI SDK - the issue is often with the Linaro 
prebuilt toolchain changing little things from version to version and breaking 
corresponding recipes. Unfortunately, external toolchain is required, hence I 
only support 1 specific Linaro toolchain version per release - 7.x in rocko, 
6.x in morty, 5.x in krogoth, 4.9 in fido, etc. So, if you need a different 
Linaro toolchain version, either switch to a corresponding release setup, or 
try porting those recipes.
Alternatively, you can always switch to internal toolchain by simply passing 
TOOLCHAIN_TYPE=internal to TI SDK build. It's not the default and doesn't get 
tested very much against TI SDK, but I try to ensure nothing is broken in each 
relesae. Though, gcc7 is still work in progress.

-- 
Denys


> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com] 
> Sent: Tuesday, October 24, 2017 1:46 PM
> To: Lee, Yong 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] GCC 4.9 and Morty
> 
> On Tue, Oct 24, 2017 at 10:33 AM, Lee, Yong  
> wrote:
> > Thanks Raj for the input. Attached the logs. Please take a look.
> > The .diff file is based on the toolchain-linaro.inc file shipped with TI's 
> > SDK [1].
> >
> 
> Your changes look fine.
> 
> > I will try to configure the SDK to use the internal toolchain and see if I 
> > can decouple myself from the external toolchain to simplify things.
> >
> 
> you might have to bug your SDK provider for gcc 4.9 build issue
> 
> 
> > Adam
> >
> > [1] 
> > http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-dis
> > tro/conf/distro/include/toolchain-linaro.inc;h=20a65174f269c1e1a5984c5
> > 476a2ab4e5dfc42b5;hb=refs/heads/morty
> >
> > -Original Message-
> > From: Khem Raj [mailto:raj.k...@gmail.com]
> > Sent: Tuesday, October 24, 2017 12:26 PM
> > To: Lee, Yong 
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] GCC 4.9 and Morty
> >
> > *EXTERNAL EMAIL*
> >
> >
> > On Tue, Oct 24, 2017 at 6:56 AM, Lee, Yong  
> > wrote:
> >> I have a bunch of apps that require an old version of GCC (4.9 or less).
> >>
> >> There are a few versions of GCC available in my Morty based SDK.
> >>
> >>
> >>
> >> build@6e35408e8fa5:~/tisdk/build$ bitbake-layers show-recipes gcc
> >>
> >> WARNING: No recipes available for:
> >>
> >>
> >> /home/build/tisdk/sources/meta-openamp/recipes-bsp/device-tree/device
> >> -
> >> tree-generation_%.bbappend
> >>
> >> Parsing recipes..done.
> >>
> >> === Matching recipes: ===
> >>
> >> gcc:
> >>
> >>   meta-linaro-toolchain linaro-4.9
> >>
> >>   meta-linaro-toolchain linaro-6.2
> >>
> >>   meta 6.2.0
> >>
> >>   meta 5.4.0
> >>
> >>   meta-linaro-toolchain linaro-5.3
> >>
> >>   meta-linaro-toolchain linaro-5.2
> >>
> >>
> >>
> >> Immediately I have set the PREFERRED_VERSION of gcc to 4.9 but 
> >> bitbake does not go beyond configuration.
> >>
> >>
> >
> > Please post the error and change you did to enable 4.9
> >
> >>
> >> I believe 4.9 + morty combination has not been tested at all. I 
> >> understand my apps need to get updated, but that’s not my call.
> >
> > OE-core and yocto releases by default do not test toolchains coming 
> > from other layers so essentially 6.2 is whats the default compiler 
> > with morty and thats what is most tested however, others might have 
> > tested the other combinations with morty,
> -- 
> ___
> 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] qemu: upgrade to 2.10.1

2017-10-26 Thread Alexander Kanavin

On 10/26/2017 12:33 PM, Patrick Ohly wrote:>  The patch is already 
present in the upstream 2.10.0. Patching during a>  build succeeds 
by adding the same hunks again to configure (which>  seems to cause 
no problems during build) and skipping the one which it>  detects as 
already applied, but "devtool modify qemu-native" is more>  picky:
Seems like another instance of patch (the tool) being too permissive 
about the context by default. Git on the other hand is always strict.


When updating versions, I recommend everyone to use devtool 
upgrade/modify for this reason. There is at least one known case where 
applying a patch in an incorrect spot created a security issue:


https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450

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

Re: [OE-core] [meta][PATCH 3/3] Fix some issues in the fitImage generation

2017-10-26 Thread André Draszik

Hi Thomas,

On Wed, 2017-10-25 at 20:03 +0200, Thomas Perrot wrote:
> Avoid a circular dependency between do_concat_dtb and do_assemble_fitimage
> when UBOOT_SIGN_ENABLE is active:
> 
> Dependency loop #1 found:
>   do_concat_dtb (dependent Tasks ['linux-
> yocto_4.10.bb:do_assemble_fitimage'])
>   do_install (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot', 'u-
> boot_2017.01.bb:do_compile', 'u-boot_2017.01.bb:do_concat_dtb'])
>   do_deploy (dependent Tasks ['u-boot_2017.01.bb:do_deploy_dtb', 'u-
> boot_2017.01.bb:do_install'])
>   do_assemble_fitimage (dependent Tasks ['linux-yocto_4.10.bb:do_compile', 
> 'u-boot_2017.01.bb:do_deploy'])

Can you please re-read
http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143637.html

Have you actually tried building on master, or at least cherry-picked the
two patches that are in master to pyro locally?
I am using exactly the same two patches I keep referring to on my local pyro
without any problem.
In case you have actually tried them, I'd like to know why they don't work
for you, otherwise I'd still say that this patch is not needed.



Cheers,
Andre'

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

Re: [OE-core] [meta][PATCH 2/3] Fix some issues in the fitImage generation

2017-10-26 Thread André Draszik

Hi Thomas,

On Wed, 2017-10-25 at 20:03 +0200, Thomas Perrot wrote:
> Ignore fitImage type in do_bundle_initramfs task because the packaging is
> made by do_assemble_fitimage_initramfs

You should also follow the instructions from the patchtest email you're
receiving
http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143668.html

In particular https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Otherwise your patches won't be merged.

In this case, you should prefix your patch subject line with the ,
and it's always helpful to add some log output e.g.

---snip---
kernel.bbclass: support fitImage and INITRAMFS_IMAGE_BUNDLE together

When enabling INITRAMFS_IMAGE_BUNDLE and fitImages, the build
aborts because 

| mv: cannot stat 'arch/arm64/boot/fitImage': No such file or directory
| WARNING: .../temp/run.do_bundle_initramfs.30337:1 exit 1 from 'mv -f 
arch/arm64/boot/$type arch/arm64/boot/$type.initramfs'
| ERROR: Function failed: do_bundle_initramfs (log file is located at 
.../temp/log.do_bundle_initramfs.30337)
| ERROR: Task (kernel.bb.bb:do_bundle_initramfs) failed with exit code '1'

This is because do_bundle_initramfs incorrectly treats 'fitImage'
as a kernel make target that needs to be re-run to achieve initramfs
image bundling, which it shouldn't.

Fix by simply skipping 'fitImage' in this case.

Signed-off-by: ...
---snap---


Same for all the other patches.

We'll get there :-)


Cheers,
Andre'


> 
> Signed-off-by: Thomas Perrot 
> ---
>  meta/classes/kernel.bbclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 756707a3c2..7f8c8985f3 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -208,7 +208,9 @@ do_bundle_initramfs () {
>   # Backing up kernel image relies on its type(regular file
> or symbolic link)
>   tmp_path=""
>   for type in ${KERNEL_IMAGETYPES} ; do
> - if [ -h ${KERNEL_OUTPUT_DIR}/$type ] ; then
> + if [ "$type" = "fitImage" ] ; then
> + continue
> + elif [ -h ${KERNEL_OUTPUT_DIR}/$type ] ; then
>   linkpath=`readlink -n
> ${KERNEL_OUTPUT_DIR}/$type`
>   realpath=`readlink -fn
> ${KERNEL_OUTPUT_DIR}/$type`
>   mv -f $realpath $realpath.bak
> -- 
> 2.13.6
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] qemu: upgrade to 2.10.1

2017-10-26 Thread Patrick Ohly

On Thu, 2017-10-19 at 13:10 -0700,
leonardo.sandoval.gonza...@linux.intel.com wrote:
> From: Leonardo Sandoval 
> 
> All CVE patches removed because these are already integrated in
> 2.10.1.
...
>  meta/recipes-devtools/qemu/qemu/glibc-2.25.patch   |  14 -
diff --git a/meta/recipes-devtools/qemu/qemu/glibc-2.25.patch
> b/meta/recipes-devtools/qemu/qemu/glibc-2.25.patch
> index a6908bdbf9..25569449e4 100644
> --- a/meta/recipes-devtools/qemu/qemu/glibc-
> 2.25.patch
> +++ b/meta/recipes-devtools/qemu/qemu/glibc-2.25.patch
> @@ -72,17 +72,3 @@ diff -uNr qemu-2.8.0.orig/configure qemu-
> 2.8.0/configure
>   # Hold two types of flag:
>   #   CONFIG_THREAD_SETNAME_BYTHREAD  - we've got a way of setting
> the name on
>   # a thread we have a handle to
> -diff -uNr qemu-2.8.0.orig/include/sysemu/os-posix.h qemu-
> 2.8.0/include/sysemu/os-posix.h
>  qemu-2.8.0.orig/include/sysemu/os-posix.h2016-12-20
> 21:16:48.0 +0100
> -+++ qemu-2.8.0/include/sysemu/os-posix.h 2017-02-21
> 19:07:18.009090381 +0100
> -@@ -34,6 +34,10 @@
> - #include 
> - #include 
> - 
> -+#ifdef CONFIG_SYSMACROS
> -+#include 
> -+#endif
> -+
> - void os_set_line_buffering(void);
> - void os_set_proc_name(const char *s);
> - void os_setup_signal_handling(void);

Instead of removing just this hunk from the glibc-2.25.patch, please
remove the entire patch. It is already in 2.10.0.

I was about to send a patch doing just that when I saw your version
update. Here's the commit message for my patch:

The patch is already present in the upstream 2.10.0. Patching during a
build succeeds by adding the same hunks again to configure (which
seems to cause no problems during build) and skipping the one which it
detects as already applied, but "devtool modify qemu-native" is more
picky:

ERROR: Applying 'glibc-2.25.patch' failed:
checking file configure
Hunk #1 succeeded at 4986 with fuzz 2 (offset 259 lines).
checking file configure
Hunk #1 succeeded at 6047 with fuzz 1 (offset 352 lines).
checking file include/sysemu/os-posix.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: 
.../devtooltmp-6_22hcm3/temp/log.do_patch.31897
NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun 
and 1 failed.
ERROR: Extracting source for qemu-native failed

-- 
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] [PATCHv2] git: bump version to 2.13.6

2017-10-26 Thread Alexander Kanavin


On 10/26/2017 10:55 AM, Ovidiu Panait wrote:

Bump version to 2.13.6 in order to eliminate CVE-2017-14867 vulnerability.


The latest version is 2.14.3, can you update to that please?

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

Re: [OE-core] [PATCH v3] libnl: 3.2.29 -> 3.4.0

2017-10-26 Thread Alexander Kanavin


On 10/26/2017 10:04 AM, Huang, Qiyu wrote:

Well, from the new Makefile.am file,I can't find the related content about this 
patch.

And in the fix-pktloc_syntax_h-race.patch, the description is like this:
libnl has progressed to 0.3.2 and there does not appear to be any "make -j" 
issues with this build after my limited testing on that newer version.

so we can assume this issue is fixed upstream

So, I think deleting this patch will not cause the problem.


That's fine, thanks for looking. Can you resend once more and include 
the information into the commit message please? Something like "upstream 
has refactored the makefiles, and the problematic code is now absent".



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

Re: [OE-core] [PATCH v5 3/3] weston: Bump version to 3.0.0

2017-10-26 Thread Fabien Lahoudere

On Tue, 2017-10-17 at 18:59 -0400, Denys Dmytriyenko wrote:
> On Tue, Oct 17, 2017 at 08:31:10AM -0200, Otavio Salvador wrote:
> > Em 17 de out de 2017 6:21 AM, "Fabien Lahoudere" <
> > fabien.lahoud...@collabora.co.uk> escreveu:
> > 
> > On Mon, 2017-10-16 at 21:34 +0100, Burton, Ross wrote:
> > 
> > On 16 October 2017 at 18:30, Otavio Salvador  > com.br> wrote:
> > 
> > 
> > > +  
> > > file://weston-gl-renderer-Set-pitch-correctly-for-subsampled-textures.patch
> > 
> > \
> > > +  file://fix-missing-header.patch \
> > 
> > Those should be documented on commit log
> > 
> > 
> > 
> > Agreed.  The missing header one should say what platform causes it to be a
> > problem (in case it never gets upstreamed and someone tests it again on
> > just glibc).  And is the pitch patch sufficiently broken that we need to
> > backport it?
> > 
> > 
> > Without the pitch patch, all applications generating YUV420 will not be
> > displayed correctly. For example "gstlaunch1.0 testvideosrc ! waylandsink"
> > fail.
> > I can keep this patch in a bbappend if you don't want it. Just tell me.
> > 
> > 
> > Please keep the patch. It fixes a issue and it is not BSP specific, so it
> > belongs to core. Just explain it on commit log.
> 
> I don't have a very strong objection here, but it sounds like a corner case 
> for one of the formats. Plus what's the difference between "fail" and "not 
> displayed correctly"?
> 

"fail" means not display correctly but the issue can also lead to a weston 
crash.

> 
> > For the header patch, I will improve commit message.
> > 
> > I see there is an OVERRIDE libc-musl, should I use this patch in
> > SRC_URI_libc-musl?
> > 
> > 
> > No, just mention it on commit log...
> > 
> > 
> > 
> > Ross
> > 
> > -- 
> > 
> > Fabien
> > 
> > --
> > ___
> > 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
> 
> 
-- 
Fabien
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv2] git: bump version to 2.13.6

2017-10-26 Thread Ovidiu Panait

Bump version to 2.13.6 in order to eliminate CVE-2017-14867 vulnerability.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-14867

Upstream patches:
https://github.com/git/git/commit/9a42c03cb71eaa9d41ba67275de38c997a791c32
https://github.com/git/git/commit/fce13af5d20cad8dcb2d0e47bcf01b6960f08e55
https://github.com/git/git/commit/27dd73871f814062737c327103ee43f1eb7f30d9
https://github.com/git/git/commit/46203ac24dc7e6b5a8d4f1b024ed93591705d47b
https://github.com/git/git/commit/5b4efea666951efe0770f8d5a301f8917015315f
https://github.com/git/git/commit/8d0fad0a7a6ba34fd706c148fa7ed1f8eb2b8b26

Signed-off-by: Ovidiu Panait 
---
 meta/recipes-devtools/git/git_2.13.3.bb | 11 ---
 meta/recipes-devtools/git/git_2.13.6.bb | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)
 delete mode 100644 meta/recipes-devtools/git/git_2.13.3.bb
 create mode 100644 meta/recipes-devtools/git/git_2.13.6.bb

diff --git a/meta/recipes-devtools/git/git_2.13.3.bb 
b/meta/recipes-devtools/git/git_2.13.3.bb
deleted file mode 100644
index b3e3887319..00
--- a/meta/recipes-devtools/git/git_2.13.3.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require git.inc
-
-EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
- 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
- "
-EXTRA_OEMAKE += "NO_GETTEXT=1"
-
-SRC_URI[tarball.md5sum] = "d2dc550f6693ba7e5b16212b2714f59f"
-SRC_URI[tarball.sha256sum] = 
"1497001772f630d49809e981672edfe3e3ce1a1d18e905cd539c4d2f4dbcd75a"
-SRC_URI[manpages.md5sum] = "3037d11a4f4cdd19435871c267ca48b4"
-SRC_URI[manpages.sha256sum] = 
"f9b302eeb08ce08934e7afb42280ce9294411fbf5f7b6ac3fcc236e8031f10c5"
diff --git a/meta/recipes-devtools/git/git_2.13.6.bb 
b/meta/recipes-devtools/git/git_2.13.6.bb
new file mode 100644
index 00..c7e559c019
--- /dev/null
+++ b/meta/recipes-devtools/git/git_2.13.6.bb
@@ -0,0 +1,11 @@
+require git.inc
+
+EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
+ 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
+ "
+EXTRA_OEMAKE += "NO_GETTEXT=1"
+
+SRC_URI[tarball.md5sum] = "b7a8f9de37cc45aef96035bd27dc98c8"
+SRC_URI[tarball.sha256sum] = 
"cb53e6b388d8d19189933366c1fe5c1ca500e8b227b9e707af39c3d879e41015"
+SRC_URI[manpages.md5sum] = "c4d966309cf8d6ad18d43624bf8ebc56"
+SRC_URI[manpages.sha256sum] = 
"c76071195596887a8eb5c73478b0be6a6e237f6af5b397e4fe8900ecda70642e"
-- 
2.11.0

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

Re: [OE-core] [PATCH v3] libnl: 3.2.29 -> 3.4.0

2017-10-26 Thread Huang, Qiyu

Well, from the new Makefile.am file,I can't find the related content about this 
patch.

And in the fix-pktloc_syntax_h-race.patch, the description is like this:
libnl has progressed to 0.3.2 and there does not appear to be any "make -j" 
issues with this build after my limited testing on that newer version.

so we can assume this issue is fixed upstream 

So, I think deleting this patch will not cause the problem.

huangqy

> -Original Message-
> From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com]
> Sent: Wednesday, October 25, 2017 7:17 PM
> To: Huang, Qiyu ;
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH v3] libnl: 3.2.29 -> 3.4.0
> 
> On 10/25/2017 05:59 AM, Huang Qiyu wrote:
> > 2) Delete one patch "fix-pktloc_syntax_h-race.patch", for it is
> inappropriate,as the verion 3.4.0 has no lib/Makefile.am file.
> 
> Apologies, but this is not a satisfactory reason to remove this patch.
> Has the upstream fixed the problem that the patch is addressing? Or have they
> simply rearranged the makefiles, and moved the problematic lines to a
> different makefile? If so, you should rebase the fix onto the new location.
> 
> Alex
> 



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

Re: [OE-core] [PATCH 1/1] systemd: fix strange behaviour on qemumips64

2017-10-26 Thread ChenQi


On 10/24/2017 01:14 AM, Khem Raj wrote:

On Mon, Oct 23, 2017 at 4:41 AM, Burton, Ross  wrote:

Can we trust the mips64 compiler at all?  Is there a specific optimisation
that systemd is turning on that is causing this breakage?  Have you reported
this to the gcc bugzilla?

Ross

On 23 October 2017 at 11:44, Chen Qi  wrote:

On qemumips64, `systemctl status ' would have the output of
`systemctl show '. This is incorrect.

However, it's not the code logic that cause such problem. It's the
compilation flags.

Looking back the history, we had problem with systemd on qemumips64
which is also related to compilation flags. We solved that by using
tweaking FULL_OPTIMIZATION for mips64 to have "-fno-tree-switch-conversion
-fno-tree-tail-merge".

Now systemd has been upgraded to 234, and we don't have the above problem
any more. However, a new problem appears, and that is the output of
`systemctl
status '.

Hence, we set '-O0' flag for mips64 when building systemd to avoid
potential
strange problems.

[YOCTO #12266]

Signed-off-by: Chen Qi 
---
  meta/recipes-core/systemd/systemd_234.bb | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_234.bb
b/meta/recipes-core/systemd/systemd_234.bb
index 36fd3f8..b294604 100644
--- a/meta/recipes-core/systemd/systemd_234.bb
+++ b/meta/recipes-core/systemd/systemd_234.bb
@@ -158,8 +158,8 @@ CFLAGS .= "${@bb.utils.contains('PACKAGECONFIG',
'valgrind', ' -DVALGRIND=1', ''
  # disable problematic GCC 5.2 optimizations [YOCTO #8291]
  FULL_OPTIMIZATION_append_arm = " -fno-schedule-insns
-fno-schedule-insns2"

-# Avoid login failure on qemumips64 when pam is enabled
-FULL_OPTIMIZATION_append_mips64 = " -fno-tree-switch-conversion
-fno-tree-tail-merge"
+# Disable optimization on qemumips64 to avoid strange behaviour
+FULL_OPTIMIZATION_append_mips64 = " -O0"


I think we need a narrowed-down case may be a opt pass which is causing
the problem. reduce the opt level to -O0 will pessimise the code and impact
the performance.

Firstly, try to use normal -O2 and remove disabling tree-switch-conversion and
tail call disable.


Hi Ross & Khem,

I did some more tests today. Below is the result.

I wanted to narrow down the option, but things went strange.

With '-O0', we don't have this problem.
With '-O1', the problem could be reproduced.
The strangest thing is that when using '-O0' and other optimizations 
that O1 enables compared to O0, the problem cannot be reproduced.
In theory, as '-O1' = '-O0' + , the problem should 
be reproduced when using '-O0' + it's not reproduced.

I'm referring to https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html.

Regarding gcc flags turned on by systemd, I can confirm that when using 
'-O1' and '-O0', the options are the same.


Best Regards,
Chen Qi


  COMPILER_NM ?= "${HOST_PREFIX}gcc-nm"
  COMPILER_AR ?= "${HOST_PREFIX}gcc-ar"
--
1.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



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

[OE-core] ✗ patchtest: failure for libnl: 3.2.29 -> 3.4.0 (rev4)

[OE-core] [PATCH v4] libnl: 3.2.29 -> 3.4.0

[OE-core] [PATCH] systemd: Fix build on musl

[OE-core] [PATCH] coreutils: upgrade to 8.28

[OE-core] [PATCH] curl: update to 7.56.1

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

[OE-core] [PATCH v2] qemu: upgrade to 2.10.1

Re: [OE-core] [PATCH 0/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

Re: [OE-core] [PATCH 0/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

Re: [OE-core] ✗ patchtest: failure for linux-firmware: Bump to bf04291 revision

[OE-core] [PATCH 0/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

[OE-core] [PATCH 1/1] scripts/oe-selftest: oe-selftest-internal wrapper scripts that isolates execution

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

[OE-core] ✗ patchtest: failure for linux-firmware: Bump to bf04291 revision

[OE-core] [PATCH] linux-firmware: Bump to bf04291 revision

Re: [OE-core] [PATCH 1/2] qemu: upgrade to 2.10.1

Re: [OE-core] [PATCH 1/2] qemu: upgrade to 2.10.1

[OE-core] [PATCH] git: bump version to 2.14.3

Re: [OE-core] [V2][PATCH 2/2] tzdata: update 2017c

Re: [OE-core] GCC 4.9 and Morty

Re: [OE-core] GCC 4.9 and Morty

Re: [OE-core] [PATCH 1/2] qemu: upgrade to 2.10.1

Re: [OE-core] [meta][PATCH 3/3] Fix some issues in the fitImage generation

Re: [OE-core] [meta][PATCH 2/3] Fix some issues in the fitImage generation

Re: [OE-core] [PATCH 1/2] qemu: upgrade to 2.10.1

Re: [OE-core] [PATCHv2] git: bump version to 2.13.6

Re: [OE-core] [PATCH v3] libnl: 3.2.29 -> 3.4.0

Re: [OE-core] [PATCH v5 3/3] weston: Bump version to 3.0.0

[OE-core] [PATCHv2] git: bump version to 2.13.6

Re: [OE-core] [PATCH v3] libnl: 3.2.29 -> 3.4.0

Re: [OE-core] [PATCH 1/1] systemd: fix strange behaviour on qemumips64

33 matches

Site Navigation

Mail list logo

Footer information