date:20191002

[OE-core] [PATCH] [thud] wget: Security fixes CVE-2018-20483

2019-10-02 Thread Aviraj CJ via Openembedded-core

Source: http://git.savannah.gnu.org/cgit/wget.git/
Type: Security Fix
Disposition: Backport from http://git.savannah.gnu.org/cgit/wget.git/
Description:

Fixes CVE-2018-20483

Signed-off-by: Aviraj CJ 
---
 .../wget/wget/CVE-2018-20483_p1.patch |  73 ++
 .../wget/wget/CVE-2018-20483_p2.patch | 127 ++
 meta/recipes-extended/wget/wget_1.19.5.bb |   2 +
 3 files changed, 202 insertions(+)
 create mode 100644 meta/recipes-extended/wget/wget/CVE-2018-20483_p1.patch
 create mode 100644 meta/recipes-extended/wget/wget/CVE-2018-20483_p2.patch

diff --git a/meta/recipes-extended/wget/wget/CVE-2018-20483_p1.patch 
b/meta/recipes-extended/wget/wget/CVE-2018-20483_p1.patch
new file mode 100644
index 00..cbc4a127a8
--- /dev/null
+++ b/meta/recipes-extended/wget/wget/CVE-2018-20483_p1.patch
@@ -0,0 +1,73 @@
+From 6c5471e4834aebd7359d88b760b087136473bac8 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tim=20R=C3=BChsen?= 
+Date: Wed, 26 Dec 2018 13:51:48 +0100
+Subject: [PATCH 1/2] Don't use extended attributes (--xattr) by default
+
+* src/init.c (defaults): Set enable_xattr to false by default
+* src/main.c (print_help): Reverse option logic of --xattr
+* doc/wget.texi: Add description for --xattr
+
+Users may not be aware that the origin URL and Referer are saved
+including credentials, and possibly access tokens within
+the urls.
+
+CVE: CVE-2018-20483 patch 1
+Upstream-Status: Backport 
[http://git.savannah.gnu.org/cgit/wget.git/commit/?id=c125d24762962d91050d925fbbd9e6f30b2302f8]
+Signed-off-by: Aviraj CJ 
+---
+ doc/wget.texi | 8 
+ src/init.c| 4 
+ src/main.c| 2 +-
+ 3 files changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/doc/wget.texi b/doc/wget.texi
+index eaf6b380..3f9d7c1c 100644
+--- a/doc/wget.texi
 b/doc/wget.texi
+@@ -540,6 +540,14 @@ right NUMBER.
+ Set preferred location for Metalink resources. This has effect if multiple
+ resources with same priority are available.
+ 
++@cindex xattr
++@item --xattr
++Enable use of file system's extended attributes to save the
++original URL and the Referer HTTP header value if used.
++
++Be aware that the URL might contain private information like
++access tokens or credentials.
++
+ 
+ @cindex force html
+ @item -F
+diff --git a/src/init.c b/src/init.c
+index eb81ab47..800970c5 100644
+--- a/src/init.c
 b/src/init.c
+@@ -509,11 +509,7 @@ defaults (void)
+   opt.hsts = true;
+ #endif
+ 
+-#ifdef ENABLE_XATTR
+-  opt.enable_xattr = true;
+-#else
+   opt.enable_xattr = false;
+-#endif
+ }
+ 
+ /* Return the user's home directory (strdup-ed), or NULL if none is
+diff --git a/src/main.c b/src/main.c
+index 81db9319..6ac1621b 100644
+--- a/src/main.c
 b/src/main.c
+@@ -754,7 +754,7 @@ Download:\n"),
+ #endif
+ #ifdef ENABLE_XATTR
+ N_("\
+-   --no-xattr  turn off storage of metadata in extended 
file attributes\n"),
++   --xattr turn on storage of metadata in extended 
file attributes\n"),
+ #endif
+ "\n",
+ 
+-- 
+2.19.1
+
diff --git a/meta/recipes-extended/wget/wget/CVE-2018-20483_p2.patch 
b/meta/recipes-extended/wget/wget/CVE-2018-20483_p2.patch
new file mode 100644
index 00..72ce8a0b33
--- /dev/null
+++ b/meta/recipes-extended/wget/wget/CVE-2018-20483_p2.patch
@@ -0,0 +1,127 @@
+From 5a4ee4f3c07cc5dc7ef5f7244fcf51fd2fa3bc67 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Tim=20R=C3=BChsen?= 
+Date: Wed, 26 Dec 2018 14:38:18 +0100
+Subject: [PATCH 2/2] Don't save user/pw with --xattr
+
+Also the Referer info is reduced to scheme+host+port.
+
+* src/ftp.c (getftp): Change params of set_file_metadata()
+* src/http.c (gethttp): Change params of set_file_metadata()
+* src/xattr.c (set_file_metadata): Remove user/password from origin URL,
+  reduce Referer value to scheme/host/port.
+* src/xattr.h: Change prototype of set_file_metadata()
+
+CVE: CVE-2018-20483 patch 2
+Upstream-Status: Backport 
[http://git.savannah.gnu.org/cgit/wget.git/commit/?id=3cdfb594cf75f11cdbb9702ac5e856c332ccacfa]
+Signed-off-by: Aviraj CJ 
+---
+ src/ftp.c   |  2 +-
+ src/http.c  |  4 ++--
+ src/xattr.c | 24 
+ src/xattr.h |  3 ++-
+ 4 files changed, 25 insertions(+), 8 deletions(-)
+
+diff --git a/src/ftp.c b/src/ftp.c
+index 69148936..db8a6267 100644
+--- a/src/ftp.c
 b/src/ftp.c
+@@ -1580,7 +1580,7 @@ Error in server response, closing control 
connection.\n"));
+ 
+ #ifdef ENABLE_XATTR
+   if (opt.enable_xattr)
+-set_file_metadata (u->url, NULL, fp);
++set_file_metadata (u, NULL, fp);
+ #endif
+ 
+   fd_close (local_sock);
+diff --git a/src/http.c b/src/http.c
+index 77bdbbed..472c328f 100644
+--- a/src/http.c
 b/src/http.c
+@@ -4120,9 +4120,9 @@ gethttp (const struct url *u, struct url *original_url, 
struct http_stat *hs,
+   if (opt.enable_xattr)
+ {
+   if (original_url != u)
+-set_file_metadata (u->url, original_url->url, fp);
++set_file_metadata (u, original_url, fp);
+   else
+-

[OE-core] [PATCH 1/2] musl: Update to latest

2019-10-02 Thread Khem Raj

Drop upstream'ed patch
Fix libgcc build with musl

Detailed ChangeLog [1]

[1] 
https://git.musl-libc.org/cgit/musl/log/?qt=range&q=1f0e9f9cc2e3fa354f94e18b3b362de5f1ec7272..2c2477da9a553c0b9b2fa18073a5dcdbe6d395af

Signed-off-by: Khem Raj 
---
 ...-for-riscv-floating-point-state-to-_.patch | 67 ---
 ...and-specifiers-in-the-riscv64-CAS-ro.patch | 55 ---
 .../0001-riscv-Define-sigcontext-again.patch  | 48 +
 meta/recipes-core/musl/musl_git.bb|  5 +-
 4 files changed, 50 insertions(+), 125 deletions(-)
 delete mode 100644 
meta/recipes-core/musl/musl/0001-Change-container-for-riscv-floating-point-state-to-_.patch
 delete mode 100644 
meta/recipes-core/musl/musl/0001-correct-the-operand-specifiers-in-the-riscv64-CAS-ro.patch
 create mode 100644 
meta/recipes-core/musl/musl/0001-riscv-Define-sigcontext-again.patch

diff --git 
a/meta/recipes-core/musl/musl/0001-Change-container-for-riscv-floating-point-state-to-_.patch
 
b/meta/recipes-core/musl/musl/0001-Change-container-for-riscv-floating-point-state-to-_.patch
deleted file mode 100644
index a9abb18726..00
--- 
a/meta/recipes-core/musl/musl/0001-Change-container-for-riscv-floating-point-state-to-_.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-From 52a37610650e7366a398dd07393d3902d2f3faa3 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Sat, 28 Sep 2019 12:19:57 -0700
-Subject: [PATCH] Change container for riscv floating-point state to 
__riscv_mc_fp_state
-
-Match the struct elements with glibc
-glibc also uses __riscv_mc prefix, some packages like gdb uses that
-
-Upstream-Status: Submitted [https://www.openwall.com/lists/musl/2019/09/28/1]
-Signed-off-by: Khem Raj 

- arch/riscv64/bits/signal.h | 18 +-
- arch/riscv64/bits/user.h   |  2 +-
- 2 files changed, 10 insertions(+), 10 deletions(-)
-
-diff --git a/arch/riscv64/bits/signal.h b/arch/riscv64/bits/signal.h
-index 76d7ad80..aba7ab00 100644
 a/arch/riscv64/bits/signal.h
-+++ b/arch/riscv64/bits/signal.h
-@@ -13,25 +13,25 @@ typedef unsigned long greg_t;
- typedef unsigned long gregset_t[32];
- 
- struct __riscv_mc_f_ext_state {
--  unsigned int f[32];
--  unsigned int fcsr;
-+  unsigned int __f[32];
-+  unsigned int __fcsr;
- };
- 
- struct __riscv_mc_d_ext_state {
--  unsigned long long f[32];
--  unsigned int fcsr;
-+  unsigned long long __f[32];
-+  unsigned int __fcsr;
- };
- 
- struct __riscv_mc_q_ext_state {
--  unsigned long long f[64] __attribute__((aligned(16)));
--  unsigned int fcsr;
-+  unsigned long long __f[64] __attribute__((aligned(16)));
-+  unsigned int __fcsr;
-   unsigned int reserved[3];
- };
- 
- union __riscv_mc_fp_state {
--  struct __riscv_mc_f_ext_state f;
--  struct __riscv_mc_d_ext_state d;
--  struct __riscv_mc_q_ext_state q;
-+  struct __riscv_mc_f_ext_state __f;
-+  struct __riscv_mc_d_ext_state __d;
-+  struct __riscv_mc_q_ext_state __q;
- };
- 
- typedef union __riscv_mc_fp_state fpregset_t;
-diff --git a/arch/riscv64/bits/user.h b/arch/riscv64/bits/user.h
-index d2e383b2..9918a2fe 100644
 a/arch/riscv64/bits/user.h
-+++ b/arch/riscv64/bits/user.h
-@@ -5,4 +5,4 @@ struct user_fpregs_struct {
- 
- #define ELF_NGREG 32
- typedef unsigned long elf_greg_t, elf_gregset_t[ELF_NGREG];
--typedef struct user_fpregs_struct elf_fpregset_t;
-+typedef union __riscv_mc_fp_state elf_fpregset_t;
--- 
-2.23.0
-
diff --git 
a/meta/recipes-core/musl/musl/0001-correct-the-operand-specifiers-in-the-riscv64-CAS-ro.patch
 
b/meta/recipes-core/musl/musl/0001-correct-the-operand-specifiers-in-the-riscv64-CAS-ro.patch
deleted file mode 100644
index 09b71cb299..00
--- 
a/meta/recipes-core/musl/musl/0001-correct-the-operand-specifiers-in-the-riscv64-CAS-ro.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-From 59f2954fcaacd9426827c69a729e2647cb9977e5 Mon Sep 17 00:00:00 2001
-From: Palmer Dabbelt 
-Date: Tue, 24 Sep 2019 20:30:15 -0700
-Subject: [PATCH] correct the operand specifiers in the riscv64 CAS routines
-
-The operand sepcifiers in a_cas and a_casp for riscv64 were incorrect:
-there's a backwards branch in the routine, so despite tmp being written
-at the end of the assembly fragment it cannot be allocated in one of the
-input registers because the input values may be needed for another trip
-around the loop.
-
-For code that follows the guarnteed forward progress requirements, he
-backwards branch is rarely taken: SiFive's hardware only fails a store
-conditional on execptional cases (ie, instruction cache misses inside
-the loop), and until recently a bug in QEMU allowed back-to-back
-store conditionals to succeed.  The bug has been fixed in the latest
-QEMU release, but it turns out that the fix caused this latent bug in
-musl to manifest.
-
-Full disclosure: I haven't actually even compiled musl.  I just guessed
-this would fix a bug introducted by the new QEMU behavior, Alistair
-(CC'd) actually checked it fixes the problem.  The rest

[OE-core] [PATCH 2/2] qemu: Add ppc64 to QEMU_TARGETS

2019-10-02 Thread Khem Raj

helps with qemuppc target

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/qemu/qemu.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index de21d30732..551b49ac0a 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -53,7 +53,7 @@ do_install_ptest() {
 }
 
 # QEMU_TARGETS is overridable variable
-QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc riscv32 
riscv64 sh4 x86_64"
+QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc ppc64 
riscv32 riscv64 sh4 x86_64"
 
 EXTRA_OECONF = " \
 --prefix=${prefix} \
-- 
2.23.0

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

Re: [OE-core] [PATCH] watchdog: fix service PIDFile in do_install_append

2019-10-02 Thread Trevor Gamblin


On 10/2/19 2:28 PM, Trevor Gamblin wrote:


From: Trevor Gamblin 

systemd requests an update to the unit file for watchdog.service
due to the contents of PIDFile:

   systemd[1]: /usr/lib/systemd/system/watchdog.service:11: PIDFile=
 references a path below legacy directory /var/run/, updating
 /var/run/watchdog.pid → /run/watchdog.pid; please update the
 unit file accordingly.

Use sed in do_install_append to fix the path from
/var/run/watchdog.pid to /run/watchdog.pid. This change is
recommended in services with the "forking" type (see commit
a9353a5c5b in systemd source).

Signed-off-by: Trevor Gamblin 
---
  meta/recipes-extended/watchdog/watchdog_5.15.bb | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/watchdog/watchdog_5.15.bb 
b/meta/recipes-extended/watchdog/watchdog_5.15.bb
index 1acab2e9e7..83a4ef27cf 100644
--- a/meta/recipes-extended/watchdog/watchdog_5.15.bb
+++ b/meta/recipes-extended/watchdog/watchdog_5.15.bb
@@ -51,8 +51,12 @@ do_install_append() {
  
  	install -Dm 0755 ${WORKDIR}/watchdog.init ${D}/${sysconfdir}/init.d/watchdog

install -Dm 0755 ${WORKDIR}/wd_keepalive.init 
${D}${sysconfdir}/init.d/wd_keepalive
+
+# watchdog is of type "forking", so fix PIDFile to avoid warnings from
+# systemd
+sed -i 's@/var/run@/run@g' ${D}${systemd_system_unitdir}/watchdog.service
  
-	# watchdog.conf is provided by the watchdog-config recipe

+# watchdog.conf is provided by the watchdog-config recipe
rm ${D}${sysconfdir}/watchdog.conf
  }
  


There are other instances of this warning regarding unit files. For 
example, during core-image-minimal boot for qemux86-64:


|[    3.845927] systemd[1]: /lib/systemd/system/dbus.socket:5: 
ListenStream= references a path below legacy directory /var/run/, 
updating /var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket|



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

Re: [OE-core] [PATCH] layer.conf: Add xserver-nodm-init to SIGGEN_EXCLUDERECIPES_ABISAFE

2019-10-02 Thread Khem Raj

On Wed, Oct 2, 2019 at 6:21 AM Richard Purdie
 wrote:
>
> On Mon, 2019-09-30 at 14:37 -0700, Khem Raj wrote:
> > Found signature differences when same machine is used as a copy
> > see
> >
> > ERROR: xscreensaver different signature for task
> > do_package_write_ipk.sigdata between qemux86copy and qemux86
> > Hash for dependent task x11-common/xserver-nodm-
> > init_3.0.bb:do_packagedata changed from
> > de0944d4fcaeed0efdb143a18cc406bd043469ae291de1704a999bc878a7691c to
> > ba7bdaf35860ba5bf5a5f4ce06379a77c88eb9806e09a1fc5373933888a46507
> >
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/conf/layer.conf | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> > index 27893b633e..a13c8dc9b2 100644
> > --- a/meta/conf/layer.conf
> > +++ b/meta/conf/layer.conf
> > @@ -44,6 +44,7 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \
> >opkg-utils \
> >gstreamer1.0-meta-base \
> >ca-certificates \
> > +  xserver-nodm-init \
> >  "
> >
> >  SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
>
> This seems odd, why is xscreensaver depending on xserver-nodm-init?
>

yeah indeed, please drop this one. Its better to fix the dependency

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

[OE-core] [master][PATCH] devtool: ccmake: Pulling in available ccmake functionality to devtool

2019-10-02 Thread Jaewon Lee

Pulling in available ccmake functionality to devtool.  Running devtool
ccmake ${PN} will call bitbake -c ccmake which will pull up an ncurses
menu where the user can modify config options. After the menu is exited
it will use the same logic available in ccmake.bbclass to generate
configuration.inc and site-file.cmake file and place into
oe-local-files.

The changes can be tested, then committed using:

devtool finish ${PN} /pathtolayer -f

The '-f' is needed as ${B}/CMakeCache.txt is soft linked to
${S}/CMakeCache.txt.new as devtool is not able to access ${B} because
it ignores the bbappends in build/workspace and this is the only way to
reflect the changes from bitbake -c ccmake.

Multiple devtool ccmake calls will create the diff between the
original CMakeCache.txt file (when calling devtool modify) and final
configuration.

Signed-off-by: Jaewon Lee 
---
 scripts/lib/devtool/ccmake.py   | 73 +
 scripts/lib/devtool/standard.py | 68 ++
 2 files changed, 141 insertions(+)
 create mode 100644 scripts/lib/devtool/ccmake.py

diff --git a/scripts/lib/devtool/ccmake.py b/scripts/lib/devtool/ccmake.py
new file mode 100644
index 000..c9597c3
--- /dev/null
+++ b/scripts/lib/devtool/ccmake.py
@@ -0,0 +1,73 @@
+# OpenEmbedded Development tool - ccmake command plugin
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# 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.
+
+"""Devtool ccmake plugin"""
+
+import os
+import bb
+import logging
+import argparse
+import re
+import glob
+from devtool import setup_tinfoil, parse_recipe, DevtoolError, standard, 
exec_build_env_command
+
+logger = logging.getLogger('devtool')
+
+def ccmake(args, config, basepath, workspace):
+"""Entry point for the devtool 'ccmake' subcommand"""
+
+rd = ""
+localfilesdir = ""
+
+tinfoil = setup_tinfoil(basepath=basepath)
+try:
+  rd = parse_recipe(config, tinfoil, args.component, appends=True, 
filter_workspace=False)
+  if not rd:
+ return 1
+
+  pn =  rd.getVar('PN', True)
+  if pn not in workspace:
+ raise DevtoolError("Run devtool modify before calling ccmake for %s" 
%pn)
+
+  if not rd.getVarFlag('do_ccmake','task'):
+ raise DevtoolError("This package does not support ccmake option")
+
+  srctree=rd.getVar('S',True)
+
+  #add check to see if oe_local_files exists or not
+  localfilesdir = os.path.join(srctree,'oe-local-files')
+  if not os.path.exists(localfilesdir):
+  bb.utils.mkdirhier(localfilesdir)
+  #Add gitignore to ensure source tree is clean
+  gitignorefile = os.path.join(localfilesdir,'.gitignore')
+  with open(gitignorefile, 'w') as f:
+  f.write('# Ignore local files, by default. Remove this file 
if you want to commit the directory to Git\n')
+  f.write('*\n')
+
+finally:
+  tinfoil.shutdown()
+
+logger.info('Launching ccmake')
+exec_build_env_command(config.init_path, basepath, 'bitbake -c ccmake %s' 
% pn, watch=True)
+
+standard._create_cmake_diff(srctree,rd)
+
+return 0
+
+def register_commands(subparsers, context):
+"""register devtool subcommands from this plugin"""
+parser_ccmake = subparsers.add_parser('ccmake',help='HELP', 
description='Launches the make ccmake command(for recipes where do_ccmake is 
available), allowing users to make changes to the build-time configuration. 
Creates a config fragment corresponding to changes made.', group='advanced')
+parser_ccmake.add_argument('component', help='component to alter config')
+parser_ccmake.set_defaults(func=ccmake,fixed_setup=context.fixed_setup)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 60c9a04..c942798 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -943,6 +943,11 @@ def modify(args, config, basepath, workspace):
 'cp ${B}/.config ${S}/.config.baseline\n'
 'ln -sfT ${B}/.config ${S}/.config.new\n'
 '}\n')
+if rd.getVarFlag('do_ccmake','task'):
+f.write('\ndo_configure_append() {\n'
+'cp ${B}/CMakeCache.txt ${S}/CMakeCache.txt.orig\n'
+'ln -sfT ${B}/CMakeCache.txt ${S}/CMakeCache.txt.new\n'
+'}\n')
 if initial_rev:

[OE-core] [PATCH] testimage.bbclass: Add kernel provider and version to testresult

2019-10-02 Thread Yeoh Ee Peng

In running QA testing, we sometime need to select custom  provider for
virtual/kernel and version. To track the selected virtual/kernel provider
and version used during test, we need to add these information to
testresult.

This patch add the virtual/kernel and version into the testresult
configuration section.

Example of virtual/kernel and version added to testresult configuration:
   - "KERNEL_PROVIDER_VERSION": "linux-intel_4.19"

Signed-off-by: Yeoh Ee Peng 
---
 meta/classes/testimage.bbclass | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 525c5a6..194d549 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -129,14 +129,30 @@ def testimage_sanity(d):
 def get_testimage_configuration(d, test_type, machine):
 import platform
 from oeqa.utils.metadata import get_layers
+distro = d.getVar("DISTRO")
+distrooverride = d.getVar("DISTROOVERRIDES")
+
+kernel_provider = d.getVar("PREFERRED_PROVIDER_virtual/kernel")
+for o in distrooverride.split(":"):
+kernel_provider_override = 
d.getVar("PREFERRED_PROVIDER_virtual/kernel_%s" % o)
+if kernel_provider_override:
+kernel_provider = kernel_provider_override
+
+kernel_provider_version = d.getVar("PREFERRED_VERSION_%s" % 
kernel_provider).replace('%', '')
+for o in distrooverride.split(":"):
+kernel_provider_version_override = d.getVar("PREFERRED_VERSION_%s_%s" 
% (kernel_provider, o))
+if kernel_provider_version_override:
+kernel_provider_version = 
kernel_provider_version_override.replace('%', '')
+
 configuration = {'TEST_TYPE': test_type,
 'MACHINE': machine,
-'DISTRO': d.getVar("DISTRO"),
+'DISTRO': distro,
 'IMAGE_BASENAME': d.getVar("IMAGE_BASENAME"),
 'IMAGE_PKGTYPE': d.getVar("IMAGE_PKGTYPE"),
 'STARTTIME': d.getVar("DATETIME"),
 'HOST_DISTRO': oe.lsb.distro_identifier().replace(' ', 
'-'),
-'LAYERS': get_layers(d.getVar("BBLAYERS"))}
+'LAYERS': get_layers(d.getVar("BBLAYERS")),
+'KERNEL_PROVIDER_VERSION': '%s_%s' % (kernel_provider, 
kernel_provider_version)}
 return configuration
 get_testimage_configuration[vardepsexclude] = "DATETIME"
 
-- 
2.7.4

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

Re: [OE-core] 3.0 release notes / migration guide

2019-10-02 Thread akuster808



On 10/2/19 3:57 PM, Paul Eggleton wrote:
> On Thursday, 3 October 2019 11:44:53 AM NZDT akuster808 wrote:
>> On 10/2/19 3:20 PM, Paul Eggleton wrote:
>>> So it's that time again - we need to start building up the raw material for 
>>> the release notes and migration guide for the upcoming 3.0 release, and I'd 
>>> like to request some help with some parts of it - read on for details.
>>>
>>> For the migration guide we have a wiki page serving as a staging area:
>>>
>>>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
>> Thanks for putting this together.
> No problem!
>
>>> Things that should go in the migration guide: *anything* in the release 
>>> that 
>>> would require someone who is upgrading to take some form of action (i.e. 
>>> change their configuration / recipes / etc.) Help with this from people who 
>>> implemented the changes or have already thought about / dealt with their 
>>> impact would be much appreciated.
>>>
>>> There is a process where I look through all the commits since the last 
>>> release 
>>> and pull out the ones that need to be mentioned in some form - other than 
>>> the 
>>> migration guide items, the following needs to be gathered for the release 
>>> notes:
>>>
>>> 1) Features - new functionality. We need to capture what the feature is and 
>>> hopefully express the impact to the user succinctly.
>> We remove LSB support.
> Thanks - I've just added that to the migration guide and will note it in the 
> release notes.
>
>>> 2) Recipe upgrades - straightforward
>>>
>>> 3) CVE fixes - fairly straightforward, I just look for commits that 
>>> explicitly 
>>> mention "CVE". If I can easily do so I'll also note where a recipe upgrade 
>>> fixes a CVE, but that isn't often readily available information.
>> So how can the community help in this case? Better commit messages?
> That would be great - but it does require the person doing the upgrade to look
> upstream, and of course every upstream is different. Unfortunately with some
> upstreams finding fixed CVE information is quite difficult indeed.
>
>> Well, aren't open defects not fixed by the time we release time but we
>> intend on fixing after release a form of known issues ?
> Yes, that's true - I will say we haven't been particularly systematic about 
> the
> known issues in past releases so perhaps we should drive the list from
> bugzilla. I would want the list to be kept as short as possible though and 
> each
> item should succinctly describe the issue. 

Maybe something the Yocto Bug triage team could possible assist in.   I
will bring it up tomorrow morning.

- armin

> Cheers
> Paul
>

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

Re: [OE-core] [master][PATCH] standard.py: Not filtering devtool workspace for devtool finish

2019-10-02 Thread Jaewon Lee

ping

> -Original Message-
> From: Jaewon Lee 
> Sent: Thursday, September 19, 2019 5:13 PM
> To: openembedded-core@lists.openembedded.org;
> paul.eggle...@linux.intel.com; Manjukumar Harthikote Matha
> ; Alejandro Enedino Hernandez Samaniego
> 
> Cc: Jaewon Lee 
> Subject: [OE-core][master][PATCH] standard.py: Not filtering devtool
> workspace for devtool finish
> 
> All devtool commands right now are filtering out the devtool workspace
> bbappends in build/workspace/appends when calling parse_recipe. While
> this may make sense for devtool add and modify, we need devtool finish to
> include those appends.
> 
> A specific breakage that is caused because devtool finish filters devtool
> appends is the cmake/cml1 flow where a file is created in the WORKDIR that
> finish needs access to, to commit those files. Particularly for git packages 
> with
> SRCPV in PV, SRCPV is only changed to 999 when using external source,
> hence when creating the cfg or cmake config files using for instance bitbake -
> c diffconfig, these files are created in the
> git999 workdir correctly (as in the devtool bbapends, we are inheriting
> externalsrc class). But when devtool finish is run, the devtool appends are
> not parsed, hence SRCPV is not changed to 999 and devtool is looking for the
> fragment files in the wrong WORKDIR.
> 
> Changing the parse_recipe call just in devtool finish to not filter out the
> devtool workspace.
> 
> Fixes [YOCTO #13533]
> 
> Signed-off-by: Jaewon Lee 
> ---
>  scripts/lib/devtool/standard.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
> index 9eeaefb..e87b433 100644
> --- a/scripts/lib/devtool/standard.py
> +++ b/scripts/lib/devtool/standard.py
> @@ -2011,7 +2011,7 @@ def finish(args, config, basepath, workspace):
>  no_clean = False
>  tinfoil = setup_tinfoil(basepath=basepath, tracking=True)
>  try:
> -rd = parse_recipe(config, tinfoil, args.recipename, True)
> +rd = parse_recipe(config, tinfoil, args.recipename, True,
> + False)
>  if not rd:
>  return 1
> 
> --
> 2.7.4

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

Re: [OE-core] 3.0 release notes / migration guide

2019-10-02 Thread Paul Eggleton

On Thursday, 3 October 2019 11:44:53 AM NZDT akuster808 wrote:
> On 10/2/19 3:20 PM, Paul Eggleton wrote:
> > So it's that time again - we need to start building up the raw material for 
> > the release notes and migration guide for the upcoming 3.0 release, and I'd 
> > like to request some help with some parts of it - read on for details.
> >
> > For the migration guide we have a wiki page serving as a staging area:
> >
> >   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
> 
> Thanks for putting this together.

No problem!

> > Things that should go in the migration guide: *anything* in the release 
> > that 
> > would require someone who is upgrading to take some form of action (i.e. 
> > change their configuration / recipes / etc.) Help with this from people who 
> > implemented the changes or have already thought about / dealt with their 
> > impact would be much appreciated.
> >
> > There is a process where I look through all the commits since the last 
> > release 
> > and pull out the ones that need to be mentioned in some form - other than 
> > the 
> > migration guide items, the following needs to be gathered for the release 
> > notes:
> >
> > 1) Features - new functionality. We need to capture what the feature is and 
> > hopefully express the impact to the user succinctly.
>
> We remove LSB support.

Thanks - I've just added that to the migration guide and will note it in the 
release notes.

> > 2) Recipe upgrades - straightforward
> >
> > 3) CVE fixes - fairly straightforward, I just look for commits that 
> > explicitly 
> > mention "CVE". If I can easily do so I'll also note where a recipe upgrade 
> > fixes a CVE, but that isn't often readily available information.
>
> So how can the community help in this case? Better commit messages?

That would be great - but it does require the person doing the upgrade to look
upstream, and of course every upstream is different. Unfortunately with some
upstreams finding fixed CVE information is quite difficult indeed.

> Well, aren't open defects not fixed by the time we release time but we
> intend on fixing after release a form of known issues ?

Yes, that's true - I will say we haven't been particularly systematic about the
known issues in past releases so perhaps we should drive the list from
bugzilla. I would want the list to be kept as short as possible though and each
item should succinctly describe the issue. 

Cheers
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [OE-core] 3.0 release notes / migration guide

2019-10-02 Thread akuster808



Paul,

On 10/2/19 3:20 PM, Paul Eggleton wrote:
> Hi folks
>
> So it's that time again - we need to start building up the raw material for 
> the release notes and migration guide for the upcoming 3.0 release, and I'd 
> like to request some help with some parts of it - read on for details.
>
> For the migration guide we have a wiki page serving as a staging area:
>
>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide

Thanks for putting this together.

>
> Things that should go in the migration guide: *anything* in the release that 
> would require someone who is upgrading to take some form of action (i.e. 
> change their configuration / recipes / etc.) Help with this from people who 
> implemented the changes or have already thought about / dealt with their 
> impact would be much appreciated.
>
> There is a process where I look through all the commits since the last 
> release 
> and pull out the ones that need to be mentioned in some form - other than the 
> migration guide items, the following needs to be gathered for the release 
> notes:
>
> 1) Features - new functionality. We need to capture what the feature is and 
> hopefully express the impact to the user succinctly.
We remove LSB support.

> 2) Recipe upgrades - straightforward
>
> 3) CVE fixes - fairly straightforward, I just look for commits that 
> explicitly 
> mention "CVE". If I can easily do so I'll also note where a recipe upgrade 
> fixes a CVE, but that isn't often readily available information.
So how can the community help in this case? Better commit messages?

>
> 4) Known issues - generally this is difficult to get from the commits since 
> we 
> either find out about them after the commit that introduced the issue, or we 
> don't know that they aren't addressed until right at the end of the release. 
> We don't want to note *all* open bugs, but if there's something that the user 
> is likely to hit that wasn't an issue in the previous release then we should 
> note it.

Well, aren't open defects not fixed by the time we release time but we
intend on fixing after release a form of known issues ?

- armin


> For the release notes I need help with #4 and #1 in particular, so if you 
> know 
> about anything in this release that falls into these categories then let me 
> know - just a pointer to the commit and any extra comments that you would 
> want 
> to make would be helpful. In the mean time I will start the process of 
> looking 
> through the commits and will add things to the migration guide page, but bear 
> in mind I don't always have all of the context for every change.
>
> Thanks!
> Paul
>


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

[OE-core] 3.0 release notes / migration guide

2019-10-02 Thread Paul Eggleton

Hi folks

So it's that time again - we need to start building up the raw material for 
the release notes and migration guide for the upcoming 3.0 release, and I'd 
like to request some help with some parts of it - read on for details.

For the migration guide we have a wiki page serving as a staging area:

  https://wiki.yoctoproject.org/wiki/FutureMigrationGuide

Things that should go in the migration guide: *anything* in the release that 
would require someone who is upgrading to take some form of action (i.e. 
change their configuration / recipes / etc.) Help with this from people who 
implemented the changes or have already thought about / dealt with their 
impact would be much appreciated.

There is a process where I look through all the commits since the last release 
and pull out the ones that need to be mentioned in some form - other than the 
migration guide items, the following needs to be gathered for the release 
notes:

1) Features - new functionality. We need to capture what the feature is and 
hopefully express the impact to the user succinctly.

2) Recipe upgrades - straightforward

3) CVE fixes - fairly straightforward, I just look for commits that explicitly 
mention "CVE". If I can easily do so I'll also note where a recipe upgrade 
fixes a CVE, but that isn't often readily available information.

4) Known issues - generally this is difficult to get from the commits since we 
either find out about them after the commit that introduced the issue, or we 
don't know that they aren't addressed until right at the end of the release. 
We don't want to note *all* open bugs, but if there's something that the user 
is likely to hit that wasn't an issue in the previous release then we should 
note it.

For the release notes I need help with #4 and #1 in particular, so if you know 
about anything in this release that falls into these categories then let me 
know - just a pointer to the commit and any extra comments that you would want 
to make would be helpful. In the mean time I will start the process of looking 
through the commits and will add things to the migration guide page, but bear 
in mind I don't always have all of the context for every change.

Thanks!
Paul

-- 
Paul Eggleton
Intel Open Source Technology Centre


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

[OE-core] [PATCH] meta: add missing some description in devtools

2019-10-02 Thread Maxime Roussin-Bélanger

Signed-off-by: Maxime Roussin-Bélanger 
---
 meta/recipes-devtools/apt/apt.inc  | 3 +++
 meta/recipes-devtools/cmake/cmake.inc  | 6 ++
 meta/recipes-devtools/dejagnu/dejagnu_1.6.2.bb | 2 ++
 meta/recipes-devtools/dnf/dnf_4.2.2.bb | 5 -
 meta/recipes-devtools/meson/meson.inc  | 3 +++
 meta/recipes-devtools/qemu/qemu.inc| 4 
 meta/recipes-devtools/quilt/quilt.inc  | 4 
 meta/recipes-devtools/swig/swig.inc| 3 +++
 meta/recipes-devtools/unfs3/unfs3_git.bb   | 3 +++
 9 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/apt/apt.inc 
b/meta/recipes-devtools/apt/apt.inc
index b855099e52..6883ac865a 100644
--- a/meta/recipes-devtools/apt/apt.inc
+++ b/meta/recipes-devtools/apt/apt.inc
@@ -1,4 +1,7 @@
 SUMMARY = "Advanced front-end for dpkg"
+DESCRIPTION = "Provides commandline tools for searching and managing as well \
+as querying information about packages as a low-level access to all features \
+of the libapt-pkg library."
 LICENSE = "GPLv2.0+"
 SECTION = "base"
 
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index 3711f18db6..35d78eea17 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -2,6 +2,12 @@
 # Released under the MIT license (see packages/COPYING)
 
 SUMMARY = "Cross-platform, open-source make system"
+DESCRIPTION = "CMake is used to control the software compilation process \
+using simple platform and compiler independent configuration files. CMake \
+generates native makefiles and workspaces that can be used in the compiler \
+environment of your choice. CMake is quite sophisticated: it is possible to \
+support complex environments requiring system configuration, pre-processor \
+generation, code generation, and template instantiation."
 HOMEPAGE = "http://www.cmake.org/";
 BUGTRACKER = "http://public.kitware.com/Bug/my_view_page.php";
 SECTION = "console/utils"
diff --git a/meta/recipes-devtools/dejagnu/dejagnu_1.6.2.bb 
b/meta/recipes-devtools/dejagnu/dejagnu_1.6.2.bb
index 7dc4e417f6..10220ebc91 100644
--- a/meta/recipes-devtools/dejagnu/dejagnu_1.6.2.bb
+++ b/meta/recipes-devtools/dejagnu/dejagnu_1.6.2.bb
@@ -1,4 +1,6 @@
 SUMMARY = "GNU unit testing framework, written in Expect and Tcl"
+DESCRIPTION = "DejaGnu is a framework for testing other programs. Its purpose \
+is to provide a single front end for all tests."
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 SECTION = "devel"
diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb 
b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
index c3332c..f38167f1ad 100644
--- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
+++ b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
@@ -1,4 +1,7 @@
 SUMMARY = "Package manager forked from Yum, using libsolv as a dependency 
resolver"
+DESCRIPTION = "Software package manager that installs, updates, and removes \
+packages on RPM-based Linux distributions. It automatically computes \
+dependencies and determines the actions required to install packages."
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
 
file://PACKAGE-LICENSING;md5=4a0548e303dbc77f067335b4d688e745 \
@@ -71,7 +74,7 @@ do_install_append_class-native() {
 do_install_append_class-nativesdk() {
 create_wrapper ${D}/${bindir}/dnf \
 RPM_CONFIGDIR=${SDKPATHNATIVE}${libdir_nativesdk}/rpm \
-RPM_NO_CHROOT_FOR_SCRIPTS=1 
+RPM_NO_CHROOT_FOR_SCRIPTS=1
 }
 
 SYSTEMD_SERVICE_${PN} = "dnf-makecache.service dnf-makecache.timer \
diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index 6de109de7f..2958a2a8de 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -1,5 +1,8 @@
 HOMEPAGE = "http://mesonbuild.com";
 SUMMARY = "A high performance build system"
+DESCRIPTION = "Meson is a build system designed to increase programmer \
+productivity. It does this by providing a fast, simple and easy to use \
+interface for modern software development tools and practices."
 
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://COPYING;md5=3b83ef96387f14655fc854ddc3c6bd57"
diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index de21d30732..11783eaca5 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -1,4 +1,8 @@
 SUMMARY = "Fast open source processor emulator"
+DESCRIPTION = "QEMU is a hosted virtual machine monitor: it emulates the \
+machine's processor through dynamic binary translation and provides a set \
+of different hardware and device models for the machine, enabling it to run \
+a variety of guest operating systems"
 HOMEPAGE = "http://qemu.org";
 LICENSE = "GPLv2 & LGPLv2.1"
 
diff --git a/meta/recipes-devtools/quilt/quilt.inc 
b/meta/recipes-devtoo

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

2019-10-02 Thread Adrian Bunk

On Wed, Oct 02, 2019 at 08:27:55PM +0200, Alexander Kanavin wrote:
> On Wed, 2 Oct 2019 at 20:18, Adrian Bunk  wrote:
> 
> > On Wed, Oct 02, 2019 at 08:08:08PM +0200, Alexander Kanavin wrote:
> > > On Wed, 2 Oct 2019 at 19:51, Adrian Bunk  wrote:
> > >
> > > > Works for me without your patch:
> > >
> > > I am not sure what this may mean; but for me the patch definitely solves
> > > the problem.
> >
> > It means that even without your patch devtool is able to tell me that
> > there is a new upstream version of ethtool available.
> >
> > I was originally wondering whether there is a problem that also affects
> > other users of KERNELORG_MIRROR, and was then surprised that it worked
> > for me without the change the way I tried.
> >
> > How are you reproducing the problem?
> 
> The same way. I am getting the following on my home computer and on both of
> my work computers (which are on two different networks). Note the IP
> address is different, and the file size is smaller, as it's gzip-compressed:
>...

I am able to reproduce your problem from a machine located elsewhere, 
and there is no difference in the headers sent that can change the 
behaviour to either make both work or both break.

My guess would be that this is a temporary problem on some part of the
Fastly network,
  wget --debug http://www.kernel.org/pub/software/network/ethtool/
says the cache that is broken for me is HHN in Frankfurt:
  Content-Encoding: gzip
  X-Served-By: cache-hhn4065-HHN

I'd be surprised if this affects only 2 recipes, the big hammer would be
  -KERNELORG_MIRROR = "https://cdn.kernel.org/pub";
  +KERNELORG_MIRROR = "https://www.kernel.org/pub";

But so far it looks to me that it might only be a temporary hiccup 
(and affecting only functionality not usually used by users).

I sent an email to Fastly support, let's see if they will answer.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[OE-core] [PATCH] watchdog: fix service PIDFile in do_install_append

2019-10-02 Thread Trevor Gamblin

From: Trevor Gamblin 

systemd requests an update to the unit file for watchdog.service
due to the contents of PIDFile:

  systemd[1]: /usr/lib/systemd/system/watchdog.service:11: PIDFile=
references a path below legacy directory /var/run/, updating
/var/run/watchdog.pid → /run/watchdog.pid; please update the
unit file accordingly.

Use sed in do_install_append to fix the path from
/var/run/watchdog.pid to /run/watchdog.pid. This change is
recommended in services with the "forking" type (see commit
a9353a5c5b in systemd source).

Signed-off-by: Trevor Gamblin 
---
 meta/recipes-extended/watchdog/watchdog_5.15.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/watchdog/watchdog_5.15.bb 
b/meta/recipes-extended/watchdog/watchdog_5.15.bb
index 1acab2e9e7..83a4ef27cf 100644
--- a/meta/recipes-extended/watchdog/watchdog_5.15.bb
+++ b/meta/recipes-extended/watchdog/watchdog_5.15.bb
@@ -51,8 +51,12 @@ do_install_append() {
 
install -Dm 0755 ${WORKDIR}/watchdog.init 
${D}/${sysconfdir}/init.d/watchdog
install -Dm 0755 ${WORKDIR}/wd_keepalive.init 
${D}${sysconfdir}/init.d/wd_keepalive
+
+# watchdog is of type "forking", so fix PIDFile to avoid warnings from
+# systemd
+sed -i 's@/var/run@/run@g' ${D}${systemd_system_unitdir}/watchdog.service
 
-   # watchdog.conf is provided by the watchdog-config recipe
+# watchdog.conf is provided by the watchdog-config recipe
rm ${D}${sysconfdir}/watchdog.conf
 }
 
-- 
2.21.0

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

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

2019-10-02 Thread Alexander Kanavin

On Wed, 2 Oct 2019 at 20:18, Adrian Bunk  wrote:

> On Wed, Oct 02, 2019 at 08:08:08PM +0200, Alexander Kanavin wrote:
> > On Wed, 2 Oct 2019 at 19:51, Adrian Bunk  wrote:
> >
> > > Works for me without your patch:
> >
> > I am not sure what this may mean; but for me the patch definitely solves
> > the problem.
>
> It means that even without your patch devtool is able to tell me that
> there is a new upstream version of ethtool available.
>
> I was originally wondering whether there is a problem that also affects
> other users of KERNELORG_MIRROR, and was then surprised that it worked
> for me without the change the way I tried.
>
> How are you reproducing the problem?
>

The same way. I am getting the following on my home computer and on both of
my work computers (which are on two different networks). Note the IP
address is different, and the file size is smaller, as it's gzip-compressed:

ak@linux-f9zs:~/development/poky/build> devtool check-upgrade-status ethtool
NOTE: Starting bitbake server...
NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)...
NOTE: Reconnecting to bitbake server...
NOTE: Previous bitbake instance shutting down?, waiting to retry...
NOTE: Retrying server connection (#2)...
Loading cache: 100%
|#|
Time: 0:00:00
Loaded 1301 entries from dependency cache.
--2019-10-02 20:25:30--
https://cdn.kernel.org/pub/software/network/ethtool/
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.113.176
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.113.176|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2155 (2.1K) [text/html]
Saving to: ‘/tmp/wget-index-l2jg_z9r/wget-listing-mo7c995y’


2019-10-02 20:25:30 (89.5 MB/s) -
‘/tmp/wget-index-l2jg_z9r/wget-listing-mo7c995y’ saved [2155/2155]

WARNING:root:Some characters could not be decoded, and were replaced with
REPLACEMENT CHARACTER.
INFO: ethtool   5.2 UNKNOWN_BROKEN  Changhyeok
Bae 

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

[OE-core] [PATCH] rootfs-postcommands: Replace an hard-coded value

2019-10-02 Thread Alessio Igor Bogani

Replace an hard-coded value ".rootfs" with the appropriate bitbake
variable IMAGE_NAME_SUFFIX.

Signed-off-by: Alessio Igor Bogani 
---
 meta/classes/rootfs-postcommands.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 88f75d0f44..2f171836fa 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -29,7 +29,7 @@ APPEND_append = '${@bb.utils.contains("IMAGE_FEATURES", 
"read-only-rootfs", " ro
 ROOTFS_POSTPROCESS_COMMAND += "write_image_test_data ; "
 
 # Write manifest
-IMAGE_MANIFEST = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.manifest"
+IMAGE_MANIFEST = "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.manifest"
 ROOTFS_POSTUNINSTALL_COMMAND =+ "write_image_manifest ; "
 # Set default postinst log file
 POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
-- 
2.17.1

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

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

2019-10-02 Thread Adrian Bunk

On Wed, Oct 02, 2019 at 08:08:08PM +0200, Alexander Kanavin wrote:
> On Wed, 2 Oct 2019 at 19:51, Adrian Bunk  wrote:
> 
> > Works for me without your patch:
> 
> I am not sure what this may mean; but for me the patch definitely solves
> the problem.

It means that even without your patch devtool is able to tell me that 
there is a new upstream version of ethtool available.

I was originally wondering whether there is a problem that also affects 
other users of KERNELORG_MIRROR, and was then surprised that it worked 
for me without the change the way I tried.

How are you reproducing the problem?

> Alex

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

2019-10-02 Thread Alexander Kanavin

On Wed, 2 Oct 2019 at 19:51, Adrian Bunk  wrote:

> Works for me without your patch:
>

I am not sure what this may mean; but for me the patch definitely solves
the problem.

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

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

2019-10-02 Thread Adrian Bunk

On Wed, Oct 02, 2019 at 02:00:27PM +0200, Alexander Kanavin wrote:
> The default URI returns a gzip-compressed index page
> which browsers can auto-detect, but we can't.
>...

Works for me without your patch:

$ devtool check-upgrade-status ethtool 
NOTE: Starting bitbake server...
NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)...
Loading cache: 100% 
|###|
 Time: 0:00:00
Loaded 3386 entries from dependency cache.
--2019-10-02 20:48:43--  https://cdn.kernel.org/pub/software/network/ethtool/
Resolving cdn.kernel.org (cdn.kernel.org)... 151.101.245.176, 2a04:4e42:3a::432
Connecting to cdn.kernel.org (cdn.kernel.org)|151.101.245.176|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12157 (12K) [text/html]
Saving to: ‘/tmp/wget-index-68s3yqp8/wget-listing-0s5soh5t’


2019-10-02 20:48:43 (4.08 MB/s) - 
‘/tmp/wget-index-68s3yqp8/wget-listing-0s5soh5t’ saved [12157/12157]

INFO: ethtool   5.2 5.3 Changhyeok Bae 
  
$ 

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] [master][PATCH] gen-lockedsig-cache: Replace glob lookup with hash to filename lookup

2019-10-02 Thread richard . purdie

On Wed, 2019-10-02 at 10:56 -0400, Konrad Scherer wrote:
> On 10/2/19 6:17 AM, Richard Purdie wrote:
> > My benchmark before was seeing it spend over 30 minutes in bitbake
> > core-image-minimal:do_populate_sdk_ext on an otherwise idle
> > autobuilder
> > cluster/NAS (35 minutes from a clean tmpdir).
> > 
> > With the patch applied and my above tweak, I saw:
> > 
> > real6m58.120s
> > 
> > and I'd note this was with a full build running on the other
> > workers so
> > the NAS was under load. I could try and get an exact time for the
> > above
> > but didn't really see the point in spending another 30 minutes on
> > it.
> > 
> > This is the time for the whole SDK image, not just the time this
> > script
> > takes but its enough for me to say its a vast improvement! :)
> 
> Great! It was frustrating to develop the code without a good
> reproducer.

Unfortunately I think we may be celebrating prematurely. On an
otherwise unloaded system this looked ok however in real world builds
the sdk creation is still excruciatingly slow.

We don't even need to use the script to understand why:

pokybuild@debian9-ty-2:~$ time ls 
/srv/autobuilder/autobuilder.yoctoproject.org/pub/sstate/c6

real9m3.140s
user0m4.432s
sys 0m5.164s

So we'd expect the script to take 2*9*255 minutes :(

(214054 files in there incidentally, I got 1m49 the second try)

I've cc'd our sysadmin.

> > Konrad: Mind if I squash in the above tweaks?
> 
> Not at all. Sorry that you had to spend time debugging my code. That
> sha extraction code should have been more robust.
> 
> > Also, the new code is a bit too chatty and leads to a lot of log
> > output, we'll need to tweak that too.
> 
> Please do.

I've queued such a patch in master-next and am testing, its an
improvement but I'm worried its not resolving the problem.

Options are to prune the sstate cache, or to teach the code to generate
the full filenames (would mean refactoring)...

We could give you access to the autobuilder to help reproduce the
problem but I think its clear where the delays are...

Cheers,

Richard



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

Re: [OE-core] [master][PATCH] gen-lockedsig-cache: Replace glob lookup with hash to filename lookup

2019-10-02 Thread Konrad Scherer


On 10/2/19 6:17 AM, Richard Purdie wrote:

On Fri, 2019-09-27 at 14:56 -0400, Konrad Scherer wrote:

From: Konrad Scherer 

Using the glob function to map signatures to sstate files is very
slow
when the sstate is large and accessed over nfs. The lookup now only
loads the necessary prefixes and doesn't use glob as all.

Unfortunately I don't have access to the systems where the
performance
isse was noticed and on my test system the glob is fast enough that
the performance numbers aren't useful. I could verify that file list
returned by the new code is the same.

[YOCTO #13539]

Signed-off-by: Konrad Scherer 
---
  meta/lib/oe/copy_buildsystem.py |  3 ++-
  scripts/gen-lockedsig-cache | 44 +

  2 files changed, 41 insertions(+), 6 deletions(-)


Thanks for this, its hugely appreciated!

I aimed to do some profile measurements to show the difference in speed
but when testing it failed with:

Filtering out gdb-cross-x86_64:do_patch
Filtering out gdb-cross-x86_64:do_prepare_recipe_sysroot
Filtering out gdb-cross-x86_64:do_unpack
Gathering file list
Traceback (most recent call last):
   File "/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 77, in 
 sstate_content_cache[prefix] = build_sha_cache(prefix)
   File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 39, in build_sha_cache
 map_sha_to_files(sstate_dir, prefix, sha_map)
   File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 29, in map_sha_to_files
 sha = extract_sha(f)
   File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 21, in extract_sha
 return filename.split(':')[7].split('_')[0]
IndexError: list index out of range

and then when I fixed that by ignoring files which don't match the pattern:

Gathering file list
Traceback (most recent call last):
   File "/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 80, in 
 sstate_content_cache[prefix] = build_sha_cache(prefix)
   File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 45, in build_sha_cache
 map_sha_to_files(native_sstate_dir, prefix, sha_map)
   File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 27, in map_sha_to_files
 sstate_files = os.listdir(sstate_prefix_path)
FileNotFoundError: [Errno 2] No such file or directory: 
'/srv/autobuilder/autobuilder.yoctoproject.org/pub/sstateuniversal/b6/'


I therefore added:

diff --git a/scripts/gen-lockedsig-cache b/scripts/gen-lockedsig-cache
index ae5e09d89f..48cb67112f 100755
--- a/scripts/gen-lockedsig-cache
+++ b/scripts/gen-lockedsig-cache
@@ -26,10 +26,13 @@ def map_sha_to_files(dir_, prefix, sha_map):
  sstate_prefix_path = dir_ + '/' + prefix + '/'
  sstate_files = os.listdir(sstate_prefix_path)
  for f in sstate_files:
-sha = extract_sha(f)
-if sha not in sha_map:
-sha_map[sha] = []
-sha_map[sha].append(sstate_prefix_path + f)
+try:
+sha = extract_sha(f)
+if sha not in sha_map:
+sha_map[sha] = []
+sha_map[sha].append(sstate_prefix_path + f)
+except IndexError:
+continue
  
  # given a prefix build a map of hash to list of files

  def build_sha_cache(prefix):
@@ -38,7 +41,7 @@ def build_sha_cache(prefix):
  sstate_dir = sys.argv[2]
  map_sha_to_files(sstate_dir, prefix, sha_map)
  
-native_sstate_dir = sys.argv[2] + sys.argv[4]

+native_sstate_dir = sys.argv[2] + '/' + sys.argv[4]
  map_sha_to_files(native_sstate_dir, prefix, sha_map)
  
  return sha_map



My benchmark before was seeing it spend over 30 minutes in bitbake
core-image-minimal:do_populate_sdk_ext on an otherwise idle autobuilder
cluster/NAS (35 minutes from a clean tmpdir).

With the patch applied and my above tweak, I saw:

real6m58.120s

and I'd note this was with a full build running on the other workers so
the NAS was under load. I could try and get an exact time for the above
but didn't really see the point in spending another 30 minutes on it.

This is the time for the whole SDK image, not just the time this script
takes but its enough for me to say its a vast improvement! :)


Great! It was frustrating to develop the code without a good reproducer.


Konrad: Mind if I squash in the above tweaks?


Not at all. Sorry that you had to spend time debugging my code. That sha 
extraction code should have been more robust.


Also, the new code is a bit too chatty and leads to a lot of log
output, we'll need to tweak that too.


Please do.

--
Konrad Scherer, MTS, Linux Products Group, Wind River
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] sanity.conf: Bump minimum bitbake version

2019-10-02 Thread Richard Purdie

We need SignatureGeneratorUniHashMixIn from newer bitbake so bump the minimum
version.

Signed-off-by: Richard Purdie 
---
 meta/conf/sanity.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/sanity.conf b/meta/conf/sanity.conf
index 92e1886990f..8b2f6553949 100644
--- a/meta/conf/sanity.conf
+++ b/meta/conf/sanity.conf
@@ -3,7 +3,7 @@
 # See sanity.bbclass
 #
 # Expert users can confirm their sanity with "touch conf/sanity.conf"
-BB_MIN_VERSION = "1.43.1"
+BB_MIN_VERSION = "1.43.2"
 
 SANITY_ABIFILE = "${TMPDIR}/abi_version"
 
-- 
2.20.1

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

[OE-core] [PATCH 1/2] base: Improve module import error message

2019-10-02 Thread Richard Purdie

Turn:

ERROR: Unable to parse Var 
Traceback (most recent call last):
  File "Var ", line 1, in 
  File "/media/build1/poky/meta/classes/base.bbclass", line 35, in 
oe_import(d=):
 for toimport in oe.data.typed_value("OE_IMPORTS", d):
>imported = __import__(toimport)
 inject(toimport.split(".", 1)[0], imported)
  File "/media/build1/poky/meta/lib/oe/sstatesig.py", line 267, in :

>class SignatureGeneratorOEEquivHash(SignatureGeneratorOEBasicHashMixIn, 
bb.siggen.SignatureGeneratorUniHashMixIn, 
bb.siggen.SignatureGeneratorBasicHash):
 name = "OEEquivHash"
bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], 
expression was ${@oe_import(d)} which triggered exception AttributeError: 
module 'bb.siggen' has no attribute 'SignatureGeneratorUniHashMixIn'

into:
ERROR: Error importing OE modules: module 'bb.siggen' has no attribute 
'SignatureGeneratorUniHashMixIn'

which can then trigger a version mismatch error message.

Signed-off-by: Richard Purdie 
---
 meta/classes/base.bbclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 0c8a4b28629..d3184ecf7bb 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -32,9 +32,11 @@ def oe_import(d):
 
 import oe.data
 for toimport in oe.data.typed_value("OE_IMPORTS", d):
-imported = __import__(toimport)
-inject(toimport.split(".", 1)[0], imported)
-
+try:
+imported = __import__(toimport)
+inject(toimport.split(".", 1)[0], imported)
+except AttributeError as e:
+bb.error("Error importing OE modules: %s" % str(e))
 return ""
 
 # We need the oe module name space early (before INHERITs get added)
-- 
2.20.1

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

Re: [OE-core] [PATCH] layer.conf: Add xserver-nodm-init to SIGGEN_EXCLUDERECIPES_ABISAFE

2019-10-02 Thread Richard Purdie

On Mon, 2019-09-30 at 14:37 -0700, Khem Raj wrote:
> Found signature differences when same machine is used as a copy
> see
> 
> ERROR: xscreensaver different signature for task
> do_package_write_ipk.sigdata between qemux86copy and qemux86
> Hash for dependent task x11-common/xserver-nodm-
> init_3.0.bb:do_packagedata changed from
> de0944d4fcaeed0efdb143a18cc406bd043469ae291de1704a999bc878a7691c to
> ba7bdaf35860ba5bf5a5f4ce06379a77c88eb9806e09a1fc5373933888a46507
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/conf/layer.conf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index 27893b633e..a13c8dc9b2 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -44,6 +44,7 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \
>opkg-utils \
>gstreamer1.0-meta-base \
>ca-certificates \
> +  xserver-nodm-init \
>  "
>  
>  SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \

This seems odd, why is xscreensaver depending on xserver-nodm-init?

Cheers,

Richard

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

Re: [OE-core] [kernel-cache][PATCH] bug 13333 Add SPDX license headers to all source files for yocto-kernel-cache

2019-10-02 Thread Richard Purdie

diff --git a/staging/small-ck-stage.scc b/staging/small-ck-stage.scc
index 0508194..328de6e 100644
--- a/staging/small-ck-stage.scc
+++ b/staging/small-ck-stage.scc
@@ -1 +1,2 @@
-include small/small-ck.scc
+# SPDX-License-Identifier: MIT
+include small/small-ck.scc
\ No newline at end of file

It looks very like your patch has stripped all the newlines off the
last lines in the files. I suspect we probably don't want to do that.

Also, please follow the section in the README, "Submitting Patches" as
the mailing list is incorrect.

Cheers,

Richard

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

[OE-core] [PATCH] systemd: Expose resolv-conf alternative only when resolved is built

2019-10-02 Thread Alexandre Bard

When systemd is built without internal resolver, it does not make
sense to expose it as a resolv-conf alternative and can even break
images where this alternative would be chosen, because of an
invalid symlink.

Signed-off-by: Alexandre Bard 
---
 meta/recipes-core/systemd/systemd_243.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_243.bb 
b/meta/recipes-core/systemd/systemd_243.bb
index eaa12ed107..b9097593f1 100644
--- a/meta/recipes-core/systemd/systemd_243.bb
+++ b/meta/recipes-core/systemd/systemd_243.bb
@@ -637,7 +637,7 @@ python do_warn_musl() {
 }
 addtask warn_musl before do_configure
 
-ALTERNATIVE_${PN} = "halt reboot shutdown poweroff runlevel resolv-conf"
+ALTERNATIVE_${PN} = "halt reboot shutdown poweroff runlevel 
${@bb.utils.contains('PACKAGECONFIG', 'resolved', 'resolv-conf', '', d)}"
 
 ALTERNATIVE_TARGET[resolv-conf] = "${sysconfdir}/resolv-conf.systemd"
 ALTERNATIVE_LINK_NAME[resolv-conf] = "${sysconfdir}/resolv.conf"
-- 
2.20.1

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

[OE-core] ✗ patchtest: failure for bug 13333 Add SPDX license headers to all source files for yocto-kernel-cache

2019-10-02 Thread Patchwork

== Series Details ==

Series: bug 1 Add SPDX license headers to all source files for 
yocto-kernel-cache
Revision: 1
URL   : https://patchwork.openembedded.org/series/20267/
State : failure

== Summary ==


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



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

* Patch[kernel-cache] bug 1 Add SPDX license headers to all 
source files for yocto-kernel-cache
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



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 2/2] ethtool, libcap: fix upstream version check

2019-10-02 Thread Alexander Kanavin

The default URI returns a gzip-compressed index page
which browsers can auto-detect, but we can't.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-extended/ethtool/ethtool_5.2.bb | 2 ++
 meta/recipes-support/libcap/libcap_2.27.bb   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/meta/recipes-extended/ethtool/ethtool_5.2.bb 
b/meta/recipes-extended/ethtool/ethtool_5.2.bb
index e9759bd21bd..67e7fadee0c 100644
--- a/meta/recipes-extended/ethtool/ethtool_5.2.bb
+++ b/meta/recipes-extended/ethtool/ethtool_5.2.bb
@@ -14,6 +14,8 @@ SRC_URI = 
"${KERNELORG_MIRROR}/software/network/ethtool/ethtool-${PV}.tar.gz \
 SRC_URI[md5sum] = "79cff0d4af62b030ad28be90414b5c4a"
 SRC_URI[sha256sum] = 
"8ad6cb30f6e1767d9d23a5cb5f606f3b51f83e85ebf0153c1506194f6709e90b"
 
+UPSTREAM_CHECK_URI = "https://www.kernel.org/pub/software/network/ethtool/";
+
 inherit autotools ptest bash-completion
 
 RDEPENDS_${PN}-ptest += "make"
diff --git a/meta/recipes-support/libcap/libcap_2.27.bb 
b/meta/recipes-support/libcap/libcap_2.27.bb
index 4f3bac84909..3f64ff76364 100644
--- a/meta/recipes-support/libcap/libcap_2.27.bb
+++ b/meta/recipes-support/libcap/libcap_2.27.bb
@@ -13,6 +13,8 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/libs/security/linux-privs/${BPN}2/${BPN}-${
 SRC_URI[md5sum] = "2e8f9fab32eb5ccb37969fe317fd17aa"
 SRC_URI[sha256sum] = 
"dac1792d0118bee6aae6ba7fb93ff1602c6a9bda812fd63916eee1435b9c486a"
 
+UPSTREAM_CHECK_URI = 
"https://www.kernel.org/pub/linux/libs/security/linux-privs/${BPN}2/";
+
 inherit lib_package
 
 # do NOT pass target cflags to host compilations
-- 
2.17.1

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

[OE-core] [PATCH 1/2] binutils: drop UPSTREAM_VERSION_UNKNOWN

2019-10-02 Thread Alexander Kanavin

As there is now a new version of binutils,
upstream version check works again.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/binutils/binutils-2.32.inc | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc 
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index d3c52936d16..19baf8a8839 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -14,11 +14,8 @@ def binutils_branch_version(d):
 pvsplit = d.getVar('PV').split('.')
 return pvsplit[0] + "_" + pvsplit[1]
 
-# Actual upstream version is 2.32 (without the .0), so we have to set
-# UPSTREAM_VERSION_UNKNOWN to avoid the version check failure. The line can
-# be removed when a new version of binutils is released (if the PV is then
-# correctly set to match the upstream version tag).
-UPSTREAM_VERSION_UNKNOWN = "1"
+# When upgrading to 2.33, please make sure there is no trailing .0, so
+# that upstream version check can work correctly.
 PV = "2.32.0"
 CVE_VERSION = "2.32"
 BINUPV = "${@binutils_branch_version(d)}"
-- 
2.17.1

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

Re: [OE-core] [warrior][PATCH] python: update to 3.7.3

2019-10-02 Thread Adrian Bunk

On Tue, Oct 01, 2019 at 04:10:54PM -0700, akuster808 wrote:
> On 10/1/19 12:58 PM, Adrian Bunk wrote:
> > From: Alexander Kanavin 
> >
> > License-update: copyright years
> is this a bugfix only? its not mentioned.

Yes, this is a maintenance release on the 3.7 branch.

> - armin
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] [master][PATCH] gen-lockedsig-cache: Replace glob lookup with hash to filename lookup

2019-10-02 Thread Richard Purdie

On Fri, 2019-09-27 at 14:56 -0400, Konrad Scherer wrote:
> From: Konrad Scherer 
> 
> Using the glob function to map signatures to sstate files is very
> slow
> when the sstate is large and accessed over nfs. The lookup now only
> loads the necessary prefixes and doesn't use glob as all.
> 
> Unfortunately I don't have access to the systems where the
> performance
> isse was noticed and on my test system the glob is fast enough that
> the performance numbers aren't useful. I could verify that file list
> returned by the new code is the same.
> 
> [YOCTO #13539]
> 
> Signed-off-by: Konrad Scherer 
> ---
>  meta/lib/oe/copy_buildsystem.py |  3 ++-
>  scripts/gen-lockedsig-cache | 44 +
> 
>  2 files changed, 41 insertions(+), 6 deletions(-)

Thanks for this, its hugely appreciated!

I aimed to do some profile measurements to show the difference in speed
but when testing it failed with:

Filtering out gdb-cross-x86_64:do_patch
Filtering out gdb-cross-x86_64:do_prepare_recipe_sysroot
Filtering out gdb-cross-x86_64:do_unpack
Gathering file list
Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 77, in 
sstate_content_cache[prefix] = build_sha_cache(prefix)
  File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 39, in build_sha_cache
map_sha_to_files(sstate_dir, prefix, sha_map)
  File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 29, in map_sha_to_files
sha = extract_sha(f)
  File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 21, in extract_sha
return filename.split(':')[7].split('_')[0]
IndexError: list index out of range

and then when I fixed that by ignoring files which don't match the pattern:

Gathering file list
Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 80, in 
sstate_content_cache[prefix] = build_sha_cache(prefix)
  File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 45, in build_sha_cache
map_sha_to_files(native_sstate_dir, prefix, sha_map)
  File 
"/home/pokybuild/yocto-worker/qa-extras/build/scripts/gen-lockedsig-cache", 
line 27, in map_sha_to_files
sstate_files = os.listdir(sstate_prefix_path)
FileNotFoundError: [Errno 2] No such file or directory: 
'/srv/autobuilder/autobuilder.yoctoproject.org/pub/sstateuniversal/b6/'


I therefore added:

diff --git a/scripts/gen-lockedsig-cache b/scripts/gen-lockedsig-cache
index ae5e09d89f..48cb67112f 100755
--- a/scripts/gen-lockedsig-cache
+++ b/scripts/gen-lockedsig-cache
@@ -26,10 +26,13 @@ def map_sha_to_files(dir_, prefix, sha_map):
 sstate_prefix_path = dir_ + '/' + prefix + '/'
 sstate_files = os.listdir(sstate_prefix_path)
 for f in sstate_files:
-sha = extract_sha(f)
-if sha not in sha_map:
-sha_map[sha] = []
-sha_map[sha].append(sstate_prefix_path + f)
+try:
+sha = extract_sha(f)
+if sha not in sha_map:
+sha_map[sha] = []
+sha_map[sha].append(sstate_prefix_path + f)
+except IndexError:
+continue
 
 # given a prefix build a map of hash to list of files
 def build_sha_cache(prefix):
@@ -38,7 +41,7 @@ def build_sha_cache(prefix):
 sstate_dir = sys.argv[2]
 map_sha_to_files(sstate_dir, prefix, sha_map)
 
-native_sstate_dir = sys.argv[2] + sys.argv[4]
+native_sstate_dir = sys.argv[2] + '/' + sys.argv[4]
 map_sha_to_files(native_sstate_dir, prefix, sha_map)
 
 return sha_map


My benchmark before was seeing it spend over 30 minutes in bitbake
core-image-minimal:do_populate_sdk_ext on an otherwise idle autobuilder
cluster/NAS (35 minutes from a clean tmpdir).

With the patch applied and my above tweak, I saw:

real6m58.120s

and I'd note this was with a full build running on the other workers so
the NAS was under load. I could try and get an exact time for the above
but didn't really see the point in spending another 30 minutes on it.

This is the time for the whole SDK image, not just the time this script
takes but its enough for me to say its a vast improvement! :)

Konrad: Mind if I squash in the above tweaks?

Also, the new code is a bit too chatty and leads to a lot of log
output, we'll need to tweak that too.

Cheers,

Richard


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

Re: [OE-core] [PATCH v4] rpm: make rpm work in toolchain.

2019-10-02 Thread Richard Purdie

On Wed, 2019-09-25 at 07:45 +0800, Zheng Ruoqin wrote:
> We need to configure rpm to use package architecture from yocto build
> system.
> 
> Install rpmrc and rpm/platform to ${SDKTARGETSYSROOT} because config
> file in host-sysroot as /opt/poky/2.7+snapshot/sysroots/x86_64-
> pokysdk-linux will be covered by another ARCH which result in
> previous config settings inefficacy.
> 
> To resolve it, put config file in target-sysroot like
> /opt/poky/2.7+snapshot/sysroots/core2-64-poky-linux. As each ARCH has
> its own target-sysroot, config file will not be covered.
> 
> Signed-off-by: Zheng Ruoqin 
> ---
>  meta/recipes-devtools/rpm/files/rpm-setup.py | 27
> 
>  meta/recipes-devtools/rpm/rpm_4.14.2.1.bb| 19 ++
>  2 files changed, 46 insertions(+)
>  create mode 100644 meta/recipes-devtools/rpm/files/rpm-setup.py
> 
> diff --git a/meta/recipes-devtools/rpm/files/rpm-setup.py
> b/meta/recipes-devtools/rpm/files/rpm-setup.py
> new file mode 100644
> index 00..b3e8a1198c
> --- /dev/null
> +++ b/meta/recipes-devtools/rpm/files/rpm-setup.py
> @@ -0,0 +1,27 @@
> +#!/usr/bin/env python3
> +
> +import os
> +import sys
> +import shutil
> +
> +try:
> +native_sysroot = os.environ['OECORE_NATIVE_SYSROOT']
> +sdktarget_sysroot = os.environ['SDKTARGETSYSROOT']
> +except KeyError:
> +print("Not in environment setup, bailing")
> +sys.exit(1)
> +
> +target_etc_dir = os.path.join(sdktarget_sysroot, 'etc/rpm')
> +
> +if not os.path.exists(target_etc_dir):
> +os.makedirs(target_etc_dir)
> +
> +template_file = os.path.join(native_sysroot, 'usr/share/rpm/rpmrc')
> +cross_file = os.path.join(sdktarget_sysroot, 'etc/rpmrc')
> +shutil.copy(template_file, cross_file)
> +
> +template_file = os.path.join(native_sysroot,
> 'usr/share/rpm/platform')
> +cross_file = os.path.join(sdktarget_sysroot, 'etc/rpm/platform')
> +shutil.copy(template_file, cross_file)
> +
> +
> diff --git a/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
> b/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
> index c37330eb4c..e1d1951d74 100644
> --- a/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
> +++ b/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
> @@ -44,6 +44,9 @@ SRC_URI = "git://github.com/rpm-software-
> management/rpm;branch=rpm-4.14.x \
> file://0001-mono-find-provides-requires-do-not-use-
> monodis-from-.patch \
> "
>  
> +SRC_URI_append_class-nativesdk = "file://rpm-setup.py \
> + "
> +
>  PE = "1"
>  SRCREV = "4a9440006398646583f0d9ae1837dad2875013aa"
>  
> @@ -113,6 +116,20 @@ do_install_append_class-nativesdk() {
>  done
>  
>  rm -rf ${D}/var
> +install -d ${D}${datadir}/rpm
> +
> +cat >${D}/${datadir}/rpm/rpmrc < +arch_compat: ${MACHINE_ARCH}: all any noarch ${PACKAGE_EXTRA_ARCHS}
> +EOF
> +
> +# Arch Info should be fixed as '-' is instead of '_'.
> +sed -i 's/-/_/' ${D}${datadir}/rpm/rpmrc
> +cat >${D}/${datadir}/rpm/platform < +${MACHINE_ARCH}-pc-linux
> +EOF

This is heading in the right direction but this patch still makes the
nativesdk-rpm recipe machine specific and we can't do that.

Cheers,

Richard



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

[OE-core] ✗ patchtest: failure for Avoid use of an hard-coded value

2019-10-02 Thread Patchwork

== Series Details ==

Series: Avoid use of an hard-coded value
Revision: 1
URL   : https://patchwork.openembedded.org/series/20265/
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:



* PatchAvoid use of an hard-coded value
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



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] [thud] wget: Security fixes CVE-2018-20483

[OE-core] [PATCH 1/2] musl: Update to latest

[OE-core] [PATCH 2/2] qemu: Add ppc64 to QEMU_TARGETS

Re: [OE-core] [PATCH] watchdog: fix service PIDFile in do_install_append

Re: [OE-core] [PATCH] layer.conf: Add xserver-nodm-init to SIGGEN_EXCLUDERECIPES_ABISAFE

[OE-core] [master][PATCH] devtool: ccmake: Pulling in available ccmake functionality to devtool

[OE-core] [PATCH] testimage.bbclass: Add kernel provider and version to testresult

Re: [OE-core] 3.0 release notes / migration guide

Re: [OE-core] [master][PATCH] standard.py: Not filtering devtool workspace for devtool finish

Re: [OE-core] 3.0 release notes / migration guide

Re: [OE-core] 3.0 release notes / migration guide

[OE-core] 3.0 release notes / migration guide

[OE-core] [PATCH] meta: add missing some description in devtools

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

[OE-core] [PATCH] watchdog: fix service PIDFile in do_install_append

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

[OE-core] [PATCH] rootfs-postcommands: Replace an hard-coded value

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

Re: [OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

Re: [OE-core] [master][PATCH] gen-lockedsig-cache: Replace glob lookup with hash to filename lookup

Re: [OE-core] [master][PATCH] gen-lockedsig-cache: Replace glob lookup with hash to filename lookup

[OE-core] [PATCH 2/2] sanity.conf: Bump minimum bitbake version

[OE-core] [PATCH 1/2] base: Improve module import error message

Re: [OE-core] [PATCH] layer.conf: Add xserver-nodm-init to SIGGEN_EXCLUDERECIPES_ABISAFE

Re: [OE-core] [kernel-cache][PATCH] bug 13333 Add SPDX license headers to all source files for yocto-kernel-cache

[OE-core] [PATCH] systemd: Expose resolv-conf alternative only when resolved is built

[OE-core] ✗ patchtest: failure for bug 13333 Add SPDX license headers to all source files for yocto-kernel-cache

[OE-core] [PATCH 2/2] ethtool, libcap: fix upstream version check

[OE-core] [PATCH 1/2] binutils: drop UPSTREAM_VERSION_UNKNOWN

Re: [OE-core] [warrior][PATCH] python: update to 3.7.3

Re: [OE-core] [master][PATCH] gen-lockedsig-cache: Replace glob lookup with hash to filename lookup

Re: [OE-core] [PATCH v4] rpm: make rpm work in toolchain.

[OE-core] ✗ patchtest: failure for Avoid use of an hard-coded value

34 matches

Site Navigation

Mail list logo

Footer information