Re: [OE-core] [PATCH 06/19] vala: update to 0.44.3

2019-04-16 Thread Khem Raj
This means we need to update xfce4-vala recipe at same time
see
https://errors.yoctoproject.org/Errors/Details/237659/

On Mon, Apr 15, 2019 at 3:56 AM Alexander Kanavin
 wrote:
>
> Remove valadoc-related patches, as upstream added an option to disable it;
> adjust the recipe accordingly.
>
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/recipes-devtools/vala/vala.inc   |   2 +-
>  .../vala/vala/0001-Disable-valadoc.patch  |  32 ---
>  .../vala/vala/disable-graphviz.patch  | 226 --
>  meta/recipes-devtools/vala/vala_0.42.5.bb |  10 -
>  meta/recipes-devtools/vala/vala_0.44.3.bb |   8 +
>  5 files changed, 9 insertions(+), 269 deletions(-)
>  delete mode 100644 meta/recipes-devtools/vala/vala/0001-Disable-valadoc.patch
>  delete mode 100644 meta/recipes-devtools/vala/vala/disable-graphviz.patch
>  delete mode 100644 meta/recipes-devtools/vala/vala_0.42.5.bb
>  create mode 100644 meta/recipes-devtools/vala/vala_0.44.3.bb
>
> diff --git a/meta/recipes-devtools/vala/vala.inc 
> b/meta/recipes-devtools/vala/vala.inc
> index f680640ca68..703ed1aa8d0 100644
> --- a/meta/recipes-devtools/vala/vala.inc
> +++ b/meta/recipes-devtools/vala/vala.inc
> @@ -37,7 +37,7 @@ EOF
>  chmod +x ${B}/vapigen-wrapper
>  }
>
> -EXTRA_OECONF += " --disable-graphviz"
> +EXTRA_OECONF += " --disable-valadoc"
>
>  # Vapigen wrapper needs to be available system-wide, because it will be used
>  # to build vapi files from all other packages with vala support
> diff --git a/meta/recipes-devtools/vala/vala/0001-Disable-valadoc.patch 
> b/meta/recipes-devtools/vala/vala/0001-Disable-valadoc.patch
> deleted file mode 100644
> index 9b27b7fd14a..000
> --- a/meta/recipes-devtools/vala/vala/0001-Disable-valadoc.patch
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -From b6ca3876e233c724fd460c1579abc4ab63c8d01e Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Wed, 4 Oct 2017 15:23:08 +0300
> -Subject: [PATCH] Disable valadoc
> -
> -Valadoc is a documentation generator for Vala sources, which was
> -recently merged into the main vala source tree. Unsurprisingly,
> -it's broken in cross-compile environment in multiple ways,
> -so let's fix it some other time.
> -
> -Upstream-Status: Inappropriate [oe-core specific]
> -Signed-off-by: Alexander Kanavin 
> 
> - Makefile.am | 2 --
> - 1 file changed, 2 deletions(-)
> -
> -diff --git a/Makefile.am b/Makefile.am
> -index e5dc0cc..813b3fc 100644
>  a/Makefile.am
> -+++ b/Makefile.am
> -@@ -13,8 +13,6 @@ SUBDIRS = \
> -   doc \
> -   gobject-introspection \
> -   vapigen \
> --  libvaladoc \
> --  valadoc \
> -   $(NULL)
> -
> - if ENABLE_UNVERSIONED
> ---
> -2.14.1
> -
> diff --git a/meta/recipes-devtools/vala/vala/disable-graphviz.patch 
> b/meta/recipes-devtools/vala/vala/disable-graphviz.patch
> deleted file mode 100644
> index e521bc854b3..000
> --- a/meta/recipes-devtools/vala/vala/disable-graphviz.patch
> +++ /dev/null
> @@ -1,226 +0,0 @@
> -From b2723ff18b70c67c8a7fab5375a7f3c442d49790 Mon Sep 17 00:00:00 2001
> -From: Rico Tzschichholz 
> -Date: Wed, 6 Sep 2017 18:52:55 +0200
> -Subject: [PATCH] libvaladoc: Allow disabling the graphviz dependency of
> -
> - valadoc
> -
> -https://bugzilla.gnome.org/show_bug.cgi?id=787375
> -Signed-off-by: Alexander Kanavin 
> -Upstream-Status: Submitted [bugzilla link above]
> -
> 
> - configure.ac  | 60 ++-
> - libvaladoc/Makefile.am| 25 ---
> - libvaladoc/html/basicdoclet.vala  |  8 
> - libvaladoc/html/htmlmarkupwriter.vala |  4 ++
> - 4 files changed, 63 insertions(+), 34 deletions(-)
> -
> -diff --git a/configure.ac b/configure.ac
> -index 730c72d..af81986 100644
>  a/configure.ac
> -+++ b/configure.ac
> -@@ -119,34 +119,38 @@ PKG_CHECK_MODULES(GMODULE, gmodule-2.0 >= 
> $GLIB_REQUIRED)
> - AC_SUBST(GMODULE_CFLAGS)
> - AC_SUBST(GMODULE_LIBS)
> -
> --PKG_CHECK_MODULES(LIBGVC, libgvc >= $LIBGVC_REQUIRED)
> --AC_MSG_CHECKING([for CGRAPH])
> --cgraph_tmp_LIBADD="$LIBADD"
> --cgraph_tmp_CFLAGS="$CFLAGS"
> --LIBADD="$LIBADD $LIBGVC_LIBS"
> --CFLAGS="$CFLAGS $LIBGVC_CFLAGS"
> --AC_RUN_IFELSE(
> --  [AC_LANG_SOURCE([
> --  #include 
> --
> --  int main(void) {
> --  #ifdef WITH_CGRAPH
> --  return 0;
> --  #else
> --  return -1;
> --  #endif
> --  }
> --  ])], [
> --  AC_MSG_RESULT([yes])
> --  VALAFLAGS="$VALAFLAGS -D WITH_CGRAPH"
> --  have_cgraph=yes
> --  ], [
> --  AC_MSG_RESULT([no])
> --  have_cgraph=no
> --  ]
> --)
> --LIBADD="$cgraph_tmp_LIBADD"
> --CFLAGS="$cgraph_tmp_CFLAGS"
> -+AC_ARG_ENABLE(graphviz, AS_HELP_STRING([--disable-graphviz], [Disable 
> graphviz usage for valadoc]), enable_graphviz=$enableval, enable_graphviz=yes)
> -+if test 

[OE-core] [PATCH 1/1] busybox: fix ptest failure about 'dc'

2019-04-16 Thread Chen Qi
Fix the following two failure of busybox ptest:

  FAIL: dc read
  FAIL: dc read string

These two test cases relies on the functionalities enabled by
CONFIG_FEATURE_DC_BIG.

Signed-off-by: Chen Qi 
---
 ...ix-two-test-case-to-also-depend-on-DC_BIG.patch | 39 ++
 meta/recipes-core/busybox/busybox_1.30.1.bb|  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-dc.tests-fix-two-test-case-to-also-depend-on-DC_BIG.patch

diff --git 
a/meta/recipes-core/busybox/busybox/0001-dc.tests-fix-two-test-case-to-also-depend-on-DC_BIG.patch
 
b/meta/recipes-core/busybox/busybox/0001-dc.tests-fix-two-test-case-to-also-depend-on-DC_BIG.patch
new file mode 100644
index 000..d22db4a
--- /dev/null
+++ 
b/meta/recipes-core/busybox/busybox/0001-dc.tests-fix-two-test-case-to-also-depend-on-DC_BIG.patch
@@ -0,0 +1,39 @@
+From a4e03fbb4d82f91069d96005405f89c45b8fd157 Mon Sep 17 00:00:00 2001
+From: Chen Qi 
+Date: Wed, 17 Apr 2019 09:24:37 +0800
+Subject: [PATCH] dc.tests: fix two test case to also depend on DC_BIG
+
+Upstream-Status: Submitted 
[http://lists.busybox.net/pipermail/busybox/2019-April/087205.html]
+
+Signed-off-by: Chen Qi 
+---
+ testsuite/dc.tests | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/testsuite/dc.tests b/testsuite/dc.tests
+index 1708a48..8c3af41 100755
+--- a/testsuite/dc.tests
 b/testsuite/dc.tests
+@@ -41,6 +41,9 @@ testing "dc complex without spaces (multiple args)" \
+   "16\n" \
+   "" ""
+ 
++optional FEATURE_DC_BIG
++# All tests below depend on FEATURE_DC_BIG
++
+ testing "dc read" \
+   "dc -finput" \
+   "2\n9\n1\n" \
+@@ -51,9 +54,6 @@ testing "dc read string" \
+   "2\nstr\n1\n" \
+   "1?2\nf" "[str]\n"
+ 
+-optional FEATURE_DC_BIG
+-# All tests below depend on FEATURE_DC_BIG
+-
+ testing "dc '>a' (conditional execute string) 1" \
+   "dc" \
+   "1\n9\n" \
+-- 
+2.7.4
+
diff --git a/meta/recipes-core/busybox/busybox_1.30.1.bb 
b/meta/recipes-core/busybox/busybox_1.30.1.bb
index 164f3ab..ba76755 100644
--- a/meta/recipes-core/busybox/busybox_1.30.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.30.1.bb
@@ -44,6 +44,7 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://0001-testsuite-check-uudecode-before-using-it.patch \
file://0001-testsuite-use-www.example.org-for-wget-test-cases.patch 
\
file://0001-du-l-works-fix-to-use-145-instead-of-144.patch \
+   
file://0001-dc.tests-fix-two-test-case-to-also-depend-on-DC_BIG.patch \
 "
 SRC_URI_append_libc-musl = " file://musl.cfg "
 
-- 
1.9.1

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


[OE-core] [PATCH 0/1] busybox: fix ptest failure about 'dc'

2019-04-16 Thread Chen Qi
*** BLURB HERE ***
The following changes since commit c23c8ebc7f66a92110bfc9e3c4d633a432d1353b:

  core-image-sato-sdk-ptest: Try and keep image below 4GB limit (2019-04-16 
11:10:02 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/busybox-dc
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/busybox-dc

Chen Qi (1):
  busybox: fix ptest failure about 'dc'

 ...ix-two-test-case-to-also-depend-on-DC_BIG.patch | 39 ++
 meta/recipes-core/busybox/busybox_1.30.1.bb|  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-dc.tests-fix-two-test-case-to-also-depend-on-DC_BIG.patch

-- 
1.9.1

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


Re: [OE-core] [PATCH] bitbake.conf: add git-lfs to HOSTTOOLS_NONFATAL

2019-04-16 Thread Saini, Naveen Kumar




On Selasa 16 Apr 2019 06:23 , Richard Purdie wrote:

On Tue, 2019-04-16 at 13:59 +0800, Naveen Saini wrote:

This provides git large file storage (lfs) extension.

Include git-lfs conditionally. If git-lfs is present on host and repo
has lfs pointers, then git-lfs will be used. If git-lfs is not
present
on host, it will be ignored.

[YOCTO #13198]

Signed-off-by: Naveen Saini 
---
  meta/conf/bitbake.conf | 3 +++
  1 file changed, 3 insertions(+)


This sounds like we swap the current situation where things are
deterministic for a situation where the situation is not deterministic?

I'm not sure that is an improvement.


Currently, if host machine has git-lfs installed, build always fails
and if host doesn't have git-lfs installed, build passes but
does not download files pointed by lfs. So, the current behaviour
depends on whether or not git-lfs is installed.

With this patch, build will pass in both the cases and files stored
using lfs will be fetched when git-lfs is present. So this is more
deterministic than before? If git-lfs isn't present, then files won't
be fetched as before.

Should this be added to HOSTTOOLS instead so lfs files are always
fetched for packages that use it?



Cheers,

Richard



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


[OE-core] [PATCH 0/1] base-files: move hostname operations out of issue file settings

2019-04-16 Thread Chen Qi
*** BLURB HERE ***
The following changes since commit c23c8ebc7f66a92110bfc9e3c4d633a432d1353b:

  core-image-sato-sdk-ptest: Try and keep image below 4GB limit (2019-04-16 
11:10:02 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/base-files-issue
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/base-files-issue

Chen Qi (1):
  base-files: move hostname operations out of issue file settings

 meta/recipes-core/base-files/base-files_3.0.14.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

-- 
1.9.1

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


[OE-core] [PATCH 1/1] base-files: move hostname operations out of issue file settings

2019-04-16 Thread Chen Qi
The function do_install_basefilesissue is meant to deal with
/etc/issue* files and the following setting could actually be
overridden.

  BASEFILESISSUEINSTALL ?= "do_install_basefilesissue"

So move the hostname operations out of this function.

Signed-off-by: Chen Qi 
---
 meta/recipes-core/base-files/base-files_3.0.14.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb 
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index a1639db..4b4027f 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -134,15 +134,16 @@ do_install () {
install -m 0644 ${WORKDIR}/motd ${D}${sysconfdir}/motd
 
ln -sf /proc/mounts ${D}${sysconfdir}/mtab
-}
 
-DISTRO_VERSION[vardepsexclude] += "DATE"
-do_install_basefilesissue () {
+   # deal with hostname
if [ "${hostname}" ]; then
echo ${hostname} > ${D}${sysconfdir}/hostname
echo "127.0.1.1 ${hostname}" >> ${D}${sysconfdir}/hosts
fi
+}
 
+DISTRO_VERSION[vardepsexclude] += "DATE"
+do_install_basefilesissue () {
install -m 644 ${WORKDIR}/issue*  ${D}${sysconfdir}
 if [ -n "${DISTRO_NAME}" ]; then
printf "${DISTRO_NAME} " >> ${D}${sysconfdir}/issue
-- 
1.9.1

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


Re: [OE-core] [PATCH 1/2] systemd: change default locale from C.UTF-8 to C

2019-04-16 Thread Changqing Li


On 4/16/19 6:22 PM, Richard Purdie wrote:

On Tue, 2019-04-16 at 17:49 +0800, changqing...@windriver.com wrote:

From: Changqing Li 

current default locale is set to C.UTF-8, but glibc not support
locale C.UTF-8. so set to the default locale C.

[snip]
 if not meson.is_cross_build()
 choose_default_locale_sh =
find_program('tools/choose-default-locale.sh')
 default_locale =
run_command(choose_default_locale_sh).stdout().strip()
 else
 default_locale = 'C.UTF-8'
 endif

if default locale set to C.UTF-8, it will cause libpcre ptest fail:

   re> //8+L
** Failed to set locale ""

Doesn't your second patch mean we don't need this one?


1.  No ,  we need this one.

because image maybe don't  install any locale except glibc default C 
locale, like below:


root@qemux86:~# locale -a
C
POSIX

if systemd set to C.UTF-8,   any image need to install C.UTF-8 locale by 
default, but only C is default locale.


with this patch,  sysVinit and systemd both set to default C locale.


2. patch 2/2 glibc: Add a C.UTF-8 locale

This patch is not necessary, it is just for add support of C.UTF-8 
locale.  if any package depend on it in the future,  it can install


this locale.


Add this patch just because I noticed most of major distro have support 
this locale. not for fix  "** Failed to set locale "".




Cheers,

Richard



--
BRs

Sandy(Li Changqing)

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


[OE-core] [oe-core][PATCH 1/1] parted: change device manager check in ptest

2019-04-16 Thread Joe Slater
t6001-psep should check for device manager the same way as
other ptests for parted -- look for an environment variable.

Signed-off-by: Joe Slater 
---
 meta/recipes-extended/parted/files/dm_check.patch | 22 ++
 meta/recipes-extended/parted/parted_3.2.bb|  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 meta/recipes-extended/parted/files/dm_check.patch

diff --git a/meta/recipes-extended/parted/files/dm_check.patch 
b/meta/recipes-extended/parted/files/dm_check.patch
new file mode 100644
index 000..bc0e95f
--- /dev/null
+++ b/meta/recipes-extended/parted/files/dm_check.patch
@@ -0,0 +1,22 @@
+parted: change check for device-manager
+
+Other ptests use this method.
+
+Upstream-Status: Pending
+
+Signed-off-by: Joe Slater 
+
+
+--- a/tests/t6001-psep.sh
 b/tests/t6001-psep.sh
+@@ -19,7 +19,9 @@
+ . "${srcdir=.}/init.sh"; path_prepend_ ../parted
+ 
+ require_root_
+-(dmsetup --help) > /dev/null 2>&1 || skip_test_ "No dmsetup installed"
++
++test "x$ENABLE_DEVICE_MAPPER" = xyes \
++  || skip_ "no device-mapper support"
+ 
+ # Device maps names - should be random to not conflict with existing ones on
+ # the system
diff --git a/meta/recipes-extended/parted/parted_3.2.bb 
b/meta/recipes-extended/parted/parted_3.2.bb
index 6189fd2..131e14b 100644
--- a/meta/recipes-extended/parted/parted_3.2.bb
+++ b/meta/recipes-extended/parted/parted_3.2.bb
@@ -19,6 +19,7 @@ SRC_URI = "${GNU_MIRROR}/parted/parted-${PV}.tar.xz \
file://run-ptest \
file://Makefile \

file://0001-libparted-Use-read-only-when-probing-devices-on-linu.patch \
+   file://dm_check.patch \
 "
 
 SRC_URI[md5sum] = "0247b6a7b314f8edeb618159fa95f9cb"
-- 
2.7.4

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


[OE-core] [meta-oe][PATCH v2 1/3] systemd: remove 2 obsolete useradds

2019-04-16 Thread Adrian Freihofer
- Users systemd-journal-gateway and systemd-journal-upload are not used by
  systemd anymore. Systemd creates dynamic users for services without
  persistent data.
- Fix start of journal-remote

Signed-off-by: Adrian Freihofer 
---
 meta/recipes-core/systemd/systemd_241.bb | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index 3a58f44a3b..8e493d5b55 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -334,9 +334,7 @@ SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKAGECONFIG', 
'binfmt', '${PN}-binfm
 SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"
 
 USERADD_PACKAGES = "${PN} ${PN}-extra-utils \
-${@bb.utils.contains('PACKAGECONFIG', 'microhttpd', 
'${PN}-journal-gateway', '', d)} \
 ${@bb.utils.contains('PACKAGECONFIG', 'microhttpd', 
'${PN}-journal-remote', '', d)} \
-${@bb.utils.contains('PACKAGECONFIG', 'journal-upload', 
'${PN}-journal-upload', '', d)} \
 "
 GROUPADD_PARAM_${PN} = "-r systemd-journal"
 USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'coredump', 
'--system -d / -M --shell /bin/nologin systemd-coredump;', '', d)}"
@@ -345,9 +343,7 @@ USERADD_PARAM_${PN} += 
"${@bb.utils.contains('PACKAGECONFIG', 'polkit', '--syste
 USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'resolved', 
'--system -d / -M --shell /bin/nologin systemd-resolve;', '', d)}"
 USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'timesyncd', 
'--system -d / -M --shell /bin/nologin systemd-timesync;', '', d)}"
 USERADD_PARAM_${PN}-extra-utils = "--system -d / -M --shell /bin/nologin 
systemd-bus-proxy"
-USERADD_PARAM_${PN}-journal-gateway = "--system -d / -M --shell /bin/nologin 
systemd-journal-gateway"
 USERADD_PARAM_${PN}-journal-remote = "--system -d / -M --shell /bin/nologin 
systemd-journal-remote"
-USERADD_PARAM_${PN}-journal-upload = "--system -d / -M --shell /bin/nologin 
systemd-journal-upload"
 
 FILES_${PN}-analyze = "${bindir}/systemd-analyze"
 
@@ -401,7 +397,7 @@ FILES_${PN}-journal-remote = 
"${rootlibexecdir}/systemd/systemd-journal-remote \
   
${systemd_system_unitdir}/systemd-journal-remote.service \
   
${systemd_system_unitdir}/systemd-journal-remote.socket \
  "
-SYSTEMD_SERVICE_${PN}-remote = "systemd-journal-remote.socket"
+SYSTEMD_SERVICE_${PN}-journal-remote = "systemd-journal-remote.socket"
 
 
 FILES_${PN}-container = 
"${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.conf \
-- 
2.20.1

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


Re: [OE-core] [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

2019-04-16 Thread Khem Raj
On Tue, Apr 16, 2019 at 1:40 AM Yu, Mingli  wrote:
>
>
>
> On 2019年04月16日 00:21, Adrian Bunk wrote:
> > On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:
> >>
> >> What are you trying to convey ? That’s what I mentioned before I began my
> >> reply however to reiterate my point was if a package is not usually built
> >> and tested with this combination which is evident because it fails to build
> >> then how good would it be if we fix this error especially complex packages
> >> like compilers so is it worth to fix them or disable Og for them
> >
> > Packages that usually get built and tested with -Og should be pretty rare,
> > and these specific build failures are better at finding the rare packages
> > that use -Werror than pointing at potential miscompilations.
> >
> >>From a distribution point of view, a package build with -Werror by
> > default is arguably a bug since this frequently breaks when something
> > is changed (usually the compiler version).
> >
> > -Og is better suited than the -O that was previously used for debugging,
> > but are we talking about debug builds or production builds?
> > If users would be using DEBUG_OPTIMIZATION in production builds that
>
> Thanks Adrian and Khem's response!
> We indeed don't use DEBUG_OPTIMIZATION in production build.
>
> But still comes question: how to silence gcc-sanitizers build failure
> when debug build enabled?
>
> Thanks,
>
> > would be wrong - this will always be a mostly untested situation
> > with an increased probability of hitting bugs noone else has seen
> > before.

disable warning as errors.

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


[OE-core] [meta-oe][PATCH v3] Update ipmitool to use new active source

2019-04-16 Thread Vernon Mauery
The ipmitool project has moved from sourceforge to github and is under
new management. This updates the source so that it pulls directly from
git rather than a tarball. Eventually, once the next release is tagged,
the new SRCREV can be updated to that. But for now, the project is under
active development and could probably benefit from periodic updates
anyway.

The SRCREV and SRC_URI links point to code that already has been patched
to work with the new openssl 1.1 APIs, so the patch is no longer needed.

Signed-off-by: Vernon Mauery 
---
 .../0001-Migrate-to-openssl-1.1.patch | 152 --
 .../{ipmitool_1.8.18.bb => ipmitool_git.bb}   |  12 +-
 2 files changed, 6 insertions(+), 158 deletions(-)
 delete mode 100644 
meta-oe/recipes-kernel/ipmitool/ipmitool/0001-Migrate-to-openssl-1.1.patch
 rename meta-oe/recipes-kernel/ipmitool/{ipmitool_1.8.18.bb => ipmitool_git.bb} 
(80%)

diff --git 
a/meta-oe/recipes-kernel/ipmitool/ipmitool/0001-Migrate-to-openssl-1.1.patch 
b/meta-oe/recipes-kernel/ipmitool/ipmitool/0001-Migrate-to-openssl-1.1.patch
deleted file mode 100644
index 394aa16ad..0
--- a/meta-oe/recipes-kernel/ipmitool/ipmitool/0001-Migrate-to-openssl-1.1.patch
+++ /dev/null
@@ -1,152 +0,0 @@
-From c9dcb6afef9c343d070aaff208d11a997a45a105 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Wed, 5 Sep 2018 22:19:38 -0700
-Subject: [PATCH] Migrate to openssl 1.1
-
-Upstream-Status: Backport 
[https://sourceforge.net/p/ipmitool/source/ci/1664902525a1c3771b4d8b3ccab7ea1ba6b2bdd1/]
-
-Signed-off-by: Khem Raj 

- src/plugins/lanplus/lanplus_crypt_impl.c | 50 ++--
- 1 file changed, 29 insertions(+), 21 deletions(-)
-
-diff --git a/src/plugins/lanplus/lanplus_crypt_impl.c 
b/src/plugins/lanplus/lanplus_crypt_impl.c
-index d5fac37..9652a5e 100644
 a/src/plugins/lanplus/lanplus_crypt_impl.c
-+++ b/src/plugins/lanplus/lanplus_crypt_impl.c
-@@ -164,11 +164,7 @@ lanplus_encrypt_aes_cbc_128(const uint8_t * iv,
-   uint8_t   * output,
-   uint32_t* 
bytes_written)
- {
--  EVP_CIPHER_CTX ctx;
--  EVP_CIPHER_CTX_init();
--  EVP_EncryptInit_ex(, EVP_aes_128_cbc(), NULL, key, iv);
--  EVP_CIPHER_CTX_set_padding(, 0);
--  
-+  EVP_CIPHER_CTX *ctx = NULL;
- 
-   *bytes_written = 0;
- 
-@@ -182,6 +178,14 @@ lanplus_encrypt_aes_cbc_128(const uint8_t * iv,
-   printbuf(input, input_length, "encrypting this data");
-   }
- 
-+  ctx = EVP_CIPHER_CTX_new();
-+  if (ctx == NULL) {
-+  lprintf(LOG_DEBUG, "ERROR: EVP_CIPHER_CTX_new() failed");
-+  return;
-+  }
-+  EVP_CIPHER_CTX_init(ctx);
-+  EVP_EncryptInit_ex(ctx, EVP_aes_128_cbc(), NULL, key, iv);
-+  EVP_CIPHER_CTX_set_padding(ctx, 0);
- 
-   /*
-* The default implementation adds a whole block of padding if the input
-@@ -191,28 +195,28 @@ lanplus_encrypt_aes_cbc_128(const uint8_t * iv,
-   assert((input_length % IPMI_CRYPT_AES_CBC_128_BLOCK_SIZE) == 0);
- 
- 
--  if(!EVP_EncryptUpdate(, output, (int *)bytes_written, input, 
input_length))
-+  if(!EVP_EncryptUpdate(ctx, output, (int *)bytes_written, input, 
input_length))
-   {
-   /* Error */
-   *bytes_written = 0;
--  return;
-   }
-   else
-   {
-   uint32_t tmplen;
- 
--  if(!EVP_EncryptFinal_ex(, output + *bytes_written, (int 
*)))
-+  if(!EVP_EncryptFinal_ex(ctx, output + *bytes_written, (int 
*)))
-   {
-+  /* Error */
-   *bytes_written = 0;
--  return; /* Error */
-   }
-   else
-   {
-   /* Success */
-   *bytes_written += tmplen;
--  EVP_CIPHER_CTX_cleanup();
-   }
-   }
-+  /* performs cleanup and free */
-+  EVP_CIPHER_CTX_free(ctx);
- }
- 
- 
-@@ -239,11 +243,7 @@ lanplus_decrypt_aes_cbc_128(const uint8_t * iv,
-   uint8_t   * output,
-   uint32_t* 
bytes_written)
- {
--  EVP_CIPHER_CTX ctx;
--  EVP_CIPHER_CTX_init();
--  EVP_DecryptInit_ex(, EVP_aes_128_cbc(), NULL, key, iv);
--  EVP_CIPHER_CTX_set_padding(, 0);
--
-+  EVP_CIPHER_CTX *ctx = NULL;
- 
-   if (verbose >= 5)
-   {
-@@ -252,12 +252,20 @@ lanplus_decrypt_aes_cbc_128(const uint8_t * iv,
-   printbuf(input, input_length, "decrypting this data");
-   }
- 
--
-   *bytes_written = 0;
- 
-   if (input_length == 0)
-   return;
- 
-+  ctx = EVP_CIPHER_CTX_new();
-+  if (ctx == NULL) {
-+  lprintf(LOG_DEBUG, "ERROR: EVP_CIPHER_CTX_new() failed");
-+  return;
-+  }
-+  

[OE-core] [PATCH] kexec-tools: Fix compilation with clang

2019-04-16 Thread Oleksiy Obitotskyy via Openembedded-core
clang assembler do not understand some directives e.g.

../kexec-tools-2.0.17/purgatory/arch/i386/entry32-16.S:23:2: error: unknown 
directive
.arch i386
^ ../kexec-tools-2.0.17/purgatory/arch/i386/entry32-16.S:115:11: error: unknown 
token in expression
ljmp %cs:*(realdest - entry16)
^

Force external assembler for purgatory and tests.

Upstream-Status: Pending
Signed-off-by: Oleksiy Obitotskyy 
---
 ..._64-Makefile-fix-assemble-with-clang.patch | 23 +++
 .../kexec/kexec-tools_2.0.19.bb   |  2 ++
 2 files changed, 25 insertions(+)
 create mode 100644 
meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-x86_64-Makefile-fix-assemble-with-clang.patch

diff --git 
a/meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-x86_64-Makefile-fix-assemble-with-clang.patch
 
b/meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-x86_64-Makefile-fix-assemble-with-clang.patch
new file mode 100644
index 00..13f247982a
--- /dev/null
+++ 
b/meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-x86_64-Makefile-fix-assemble-with-clang.patch
@@ -0,0 +1,23 @@
+--- a/purgatory/Makefile   2019-03-05 07:47:03.190429822 -0800
 b/purgatory/Makefile   2019-03-05 07:42:52.167623612 -0800
+@@ -31,6 +31,9 @@ include $(srcdir)/purgatory/arch/x86_64/
+ 
+ PURGATORY_SRCS+=$($(ARCH)_PURGATORY_SRCS)
+ 
++PURGATORY_EXTRA_CFLAGS += -no-integrated-as
++$(ARCH)_PURGATORY_EXTRA_CFLAGS += -no-integrated-as
++
+ PURGATORY_OBJS = $(call objify, $(PURGATORY_SRCS)) purgatory/sha256.o
+ PURGATORY_DEPS = $(call depify, $(PURGATORY_OBJS))
+ 
+--- a/kexec_test/Makefile  2019-03-05 07:45:14.757353575 -0800
 b/kexec_test/Makefile  2019-03-05 07:45:57.567173264 -0800
+@@ -17,6 +17,8 @@ endif
+ 
+ ifeq ($(BUILD_KEXEC_TEST),yes)
+ 
++CPPFLAGS += -no-integrated-as
++
+ KEXEC_TEST_OBJS = $(call objify, $(KEXEC_TEST_SRCS))
+ KEXEC_TEST_DEPS = $(call depify, $(KEXEC_TEST_OBJS))
+ 
diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.19.bb 
b/meta/recipes-kernel/kexec/kexec-tools_2.0.19.bb
index f65cd9f106..c229097d5b 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.19.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.19.bb
@@ -20,6 +20,8 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz
file://0001-Disable-PIE-during-link.patch \
"
 
+SRC_URI_append_toolchain-clang = " 
file://0001-purgatory-x86_64-Makefile-fix-assemble-with-clang.patch"
+
 SRC_URI[md5sum] = "052458f0a35c2a3b0d2302caa3318e9f"
 SRC_URI[sha256sum] = 
"913c8dee918e5855a4ba60d609371390978144b4c8d15d6446ca0057b7bc5e58"
 
-- 
2.19.1

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


[OE-core] [meta-oe][PATCH] protobuf: Fix ptest compilation

2019-04-16 Thread Oleksiy Obitotskyy via Openembedded-core
Tests require c++11 support, so add -std=c++11
to compiler flags.

Upstream-Status: Pending
Signed-off-by: Oleksiy Obitotskyy 
---
 meta-oe/recipes-devtools/protobuf/protobuf_3.6.1.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-devtools/protobuf/protobuf_3.6.1.bb 
b/meta-oe/recipes-devtools/protobuf/protobuf_3.6.1.bb
index cf72d9ca7..4791e13ca 100644
--- a/meta-oe/recipes-devtools/protobuf/protobuf_3.6.1.bb
+++ b/meta-oe/recipes-devtools/protobuf/protobuf_3.6.1.bb
@@ -40,8 +40,8 @@ do_compile_ptest() {
# which haven't been installed yet.
cp "${B}/protobuf.pc" "${B}/${TEST_SRC_DIR}/protobuf.pc"
sed -e 's|libdir=|libdir=${PKG_CONFIG_SYSROOT_DIR}|' -i 
"${B}/${TEST_SRC_DIR}/protobuf.pc"
-   sed -e 's|Cflags:|Cflags: -I${S}/src|' -i 
"${B}/${TEST_SRC_DIR}/protobuf.pc"
-   sed -e 's|Libs:|Libs: -L${B}/src/.libs|' -i 
"${B}/${TEST_SRC_DIR}/protobuf.pc"
+   sed -e 's|Cflags:|Cflags: -std=c++11 -I${S}/src|' -i 
"${B}/${TEST_SRC_DIR}/protobuf.pc"
+   sed -e 's|Libs:|Libs: -std=c++11 -L${B}/src/.libs|' -i 
"${B}/${TEST_SRC_DIR}/protobuf.pc"
export PKG_CONFIG_PATH="${B}/${TEST_SRC_DIR}"
 
# Save the pkgcfg sysroot variable, and update it to nothing so
-- 
2.19.1

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


[OE-core] Yocto Project Status WW15'19

2019-04-16 Thread Richard Purdie
Current Dev Position: YP 2.7 M4 (2.7 rc2 is in QA)
Next Deadline: YP 2.7 Release Target April 26, 2019

SWAT Team Rotation:
SWAT lead is currently: Chen SWAT team rotation: Chen -> Armin on Apr.
19, 2019SWAT team rotation: Armin -> Anuj on Apr. 26, 2019
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Next Team Meetings:
YP 2.8 Planning meeting Tuesday April 16nd at 8am PDT (
https://zoom.us/j/990892712) Bug Triage meeting Thursday April 18th at
7:30am PDT (https://zoom.us/j/454367603)
Key Status/Updates:
Stephen is unavailable at the moment, please refer any queries to
RichardYP 2.6.2 was rebuilt as rc4 to include the boost upgrade revert
and is due to be released today. The YP 2.6.2 rc3/4 report is
summarized at 
https://lists.yoctoproject.org/pipermail/yocto/2019-April/044827.html
and the results are at https://autobuilder.yocto.io/pub/releases/yocto
-2.6.2.rc4/testresults/.YP 2.5.3 is currently going through the QA
process.We’re sad to announce that we will be removing eclipse plugin
builds from the autobuilder and will not be including the plugin in any
future project releases. This is due to a lack of anyone able to help
work on the plugin development, bug fixing or release.The key fixes
mentioned in last week’s status have been merged into 2.7.A key bug in
pseudo was identified which may be the root cause of the long standing
glibc-locale uid “host contamination” issue. Many thanks to Peter and
Otavio for the help in debugging that. A separate fix should also
ensure pseudo works with newer distro coreutils and glibc versions.YP
2.7 rc2 (warrior) was built successfully and is currently going through
the QA process after 2.5.3 is done.The ptest results in 2.7 are much
more stable than ever before with results being consistent from build
to build. At the start of 2.8 we can make some further improvements so
we take advantage of this and build upon it to reduce regressions in
the system.In an effort to keep the patch queue under control, patches
are merging to master.The list of issues from last week of worrying
things we lack resources to improve upon remains:Intermittent
autobuilder failures (fork running out of resources - which resources?,
oe-selftest intermittent issues, gpg signing resource problems,
occasional PR server failure and more)Build-appliance testing issues
(show up on each QA report across multiple releases)40% valgrind ptest
failuresKnown bitbake memory resident bugsOther ptest failuresThe 2.8
planning discussions are starting and there is a google doc summarising
the discussions so far: 
https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/If
people are planning to work on specific things in 2.8 please let us
know so we can incorporate this into our plans. If you’re interested in
working on anything in the document, please also let us know or talk
with us in one of the planning meetings.

Planned Releases for YP 2.7:
YP 2.7 M4 Cutoff was Apr. 1, 2019YP 2.7 M4 Release Target is Apr. 26,
2019
Planned upcoming dot releases:
YP 2.5.3 (Sumo) is in QA.
Tracking Metrics:
WDD 2523 (last week 2471) (
https://wiki.yoctoproject.org/charts/combo.html)Poky Patch Metrics
 Total patches found: 1553 (last week 1553)Patches in the Pending
State: 654 (42%) [last week 655 (42%)]
Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status

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


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


[OE-core] [PATCH] classes/waf: Set WAFLOCK

2019-04-16 Thread Joshua Watt
Sets the WAFLOCK environment variable. This controls the name of the
lock file that waf uses to pass the build configuration from 'configure'
to 'build' and 'install'. Using a uniquely generated name based on the
parameters passed to 'configure' ensures that the source directory can
be configured for multiple different builds without conflicting (since
the lock file is stored in ${S})

Signed-off-by: Joshua Watt 
---
 meta/classes/waf.bbclass | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/meta/classes/waf.bbclass b/meta/classes/waf.bbclass
index 8e6d754c299..900244004ec 100644
--- a/meta/classes/waf.bbclass
+++ b/meta/classes/waf.bbclass
@@ -5,6 +5,32 @@ B = "${WORKDIR}/build"
 
 EXTRA_OECONF_append = " ${PACKAGECONFIG_CONFARGS}"
 
+def waflock_hash(d):
+# Calculates the hash used for the waf lock file. This should include
+# all of the user controllable inputs passed to waf configure. Note
+# that the full paths for ${B} and ${S} are used; this is OK and desired
+# because a change to either of these should create a unique lock file
+# to prevent collisions.
+import hashlib
+h = hashlib.sha512()
+def update(name):
+val = d.getVar(name)
+if val is not None:
+h.update(val.encode('utf-8'))
+update('S')
+update('B')
+update('prefix')
+update('EXTRA_OECONF')
+return h.hexdigest()
+
+# Use WAFLOCK to specify a separate lock file. The build is already
+# sufficiently isolated by setting the output directory, this ensures that
+# bitbake won't step on toes of any other configured context in the source
+# directory (e.g. if the source is coming from externalsrc and was previously
+# configured elsewhere).
+export WAFLOCK = ".lock-waf_oe_${@waflock_hash(d)}_build"
+BB_HASHBASE_WHITELIST += "WAFLOCK"
+
 python waf_preconfigure() {
 import subprocess
 from distutils.version import StrictVersion
-- 
2.20.1

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


Re: [OE-core] [PATCH 2/2] glibc: Add a C.UTF-8 locale

2019-04-16 Thread Adrian Bunk
On Tue, Apr 16, 2019 at 05:49:44PM +0800, changqing...@windriver.com wrote:
> From: Changqing Li 
> 
> * This patch is get from fedora project, link:
> https://src.fedoraproject.org/rpms/glibc/blob/0457f649e3fe6299efe384da13dfc923bbe65707/f/glibc-c-utf8-locale.patch
> 
> * At this point, most major distro have support this locale
>...

Is there now agreement on the exact semantics of this locale?
I remember this was a problem when it was suggested for upstream
inclusion ~ 5 years ago.

E.g. the Debian definition of C.UTF-8 is very different to and
more than 10 times to size of the Fedora definition of C.UTF-8.

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] i2c-tools: Split binaries and library

2019-04-16 Thread Adrian Bunk
On Tue, Apr 16, 2019 at 12:02:04PM +, John Ernberg wrote:
>...
> --- a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
> +++ b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
>...
> -PACKAGES =+ "${PN}-misc"
> +PACKAGES =+ "${PN}-misc ${PN}-utils "
>...

i2c-tools-utils is a weird name.

It would be better to add a new package libi2c for the library instead.

This would also not break backwards compatibility for people 
already installing i2c-tools to their images.

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] i2c-tools: Split binaries and library

2019-04-16 Thread John Ernberg
From: John Ernberg 

Since the library is differently licensed, split it from the executables.

According to the README of i2c-tools the library is LGPLv2.1 while the
executables are GPLv2.

License-update: Additional license file.

Signed-off-by: John Ernberg 
---
 meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb 
b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
index 2b4563d4f0..b827a8274a 100644
--- a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
+++ b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
@@ -1,8 +1,10 @@
 SUMMARY = "Set of i2c tools for linux"
 HOMEPAGE = "https://i2c.wiki.kernel.org/index.php/I2C_Tools;
 SECTION = "base"
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
+LICENSE = "LGPLv2.1 & GPLv2+"
+LICENSE_${PN} = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
+file://COPYING.LGPL;md5=4fbd65380cdd255951079008b364516c"
 
 SRC_URI = "${KERNELORG_MIRROR}/software/utils/i2c-tools/${BP}.tar.gz \
 "
@@ -21,20 +23,23 @@ do_install() {
 oe_runmake 'DESTDIR=${D}' install
 }
 
-PACKAGES =+ "${PN}-misc"
+PACKAGES =+ "${PN}-misc ${PN}-utils "
 FILES_${PN}-misc = "${sbindir}/i2c-stub-from-dump \
 ${bindir}/ddcmon \
 ${bindir}/decode-edid \
 ${bindir}/decode-dimms \
 ${bindir}/decode-vaio \
"
+FILES_${PN}-utils = "${sbindir}"
+RRECOMMENDS_${PN}_class-target = "${PN}-utils"
+
 RDEPENDS_${PN}-misc = "${PN} perl perl-module-posix \
perl-module-constant perl-module-file-basename \
perl-module-fcntl perl-module-strict perl-module-vars \
   "
 
 ALTERNATIVE_PRIORITY = "100"
-ALTERNATIVE_${PN} = "i2cdetect i2cdump i2cget i2cset"
+ALTERNATIVE_${PN}-utils = "i2cdetect i2cdump i2cget i2cset"
 ALTERNATIVE_LINK_NAME[i2cdetect] = "${sbindir}/i2cdetect"
 ALTERNATIVE_LINK_NAME[i2cdump] = "${sbindir}/i2cdump"
 ALTERNATIVE_LINK_NAME[i2cget] = "${sbindir}/i2cget"
-- 
2.21.0
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v2] dnf: Enable nativesdk

2019-04-16 Thread Zheng, Ruoqin
Ping

--
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
   Nanjing, 210012, China
MAIL : zhengrq.f...@cn.fujistu.com


> -Original Message-
> From: Zheng, Ruoqin/郑 若钦
> Sent: Saturday, April 13, 2019 10:36 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Zheng, Ruoqin/郑 若钦 
> Subject: [OE-core] [PATCH v2] dnf: Enable nativesdk
> 
> Make dnf work on nativesdk environment.
> 
> Signed-off-by: Zheng Ruoqin 
> ---
>  meta/recipes-devtools/dnf/dnf_4.1.0.bb | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/dnf/dnf_4.1.0.bb b/meta/recipes-
> devtools/dnf/dnf_4.1.0.bb
> index d45023e..8b4291a 100644
> --- a/meta/recipes-devtools/dnf/dnf_4.1.0.bb
> +++ b/meta/recipes-devtools/dnf/dnf_4.1.0.bb
> @@ -26,7 +26,7 @@ EXTRA_OECMAKE = " -DWITH_MAN=0 -
> DPYTHON_INSTALL_DIR=${PYTHON_SITEPACKAGES_DIR} -
> 
>  BBCLASSEXTEND = "native nativesdk"
> 
> -RDEPENDS_${PN}_class-target += " \
> +RDEPENDS_${PN} += " \
>python3-core \
>python3-codecs \
>python3-netclient \
> @@ -49,6 +49,8 @@ RDEPENDS_${PN}_class-target += " \
>python3-gpg \
>"
> 
> +RDEPENDS_${PN}_class-native = ""
> +
>  RRECOMMENDS_${PN}_class-target += "gnupg"
> 
>  # Create a symlink called 'dnf' as 'make install' does not do it, but @@ 
> -66,6
> +68,12 @@ do_install_append_class-native() {
>  RPM_NO_CHROOT_FOR_SCRIPTS=1  }
> 
> +do_install_append_class-nativesdk() {
> +create_wrapper ${D}/${bindir}/dnf \
> +RPM_CONFIGDIR=${SDKPATHNATIVE}${libdir_nativesdk}/rpm \
> +RPM_NO_CHROOT_FOR_SCRIPTS=1 }
> +
>  SYSTEMD_SERVICE_${PN} = "dnf-makecache.service dnf-makecache.timer \
>   dnf-automatic.service dnf-automatic.timer \
>   dnf-automatic-download.service 
> dnf-automatic-download.timer \
> --
> 1.8.3.1



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


Re: [OE-core] [PATCH 1/2] systemd: change default locale from C.UTF-8 to C

2019-04-16 Thread Enrico Scholz via Openembedded-core
Richard Purdie

writes:

>> current default locale is set to C.UTF-8, but glibc not support
>> locale C.UTF-8. so set to the default locale C.
>
> Doesn't your second patch mean we don't need this one?

C.UTF-8 instead of plain C has runtime costs because additional files
need to be read by services.

imo, plain C should be a PACKAGE_CONFIG option which is enabled by
default.


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


Re: [OE-core] [PATCH] bitbake.conf: add git-lfs to HOSTTOOLS_NONFATAL

2019-04-16 Thread Richard Purdie
On Tue, 2019-04-16 at 13:59 +0800, Naveen Saini wrote:
> This provides git large file storage (lfs) extension.
> 
> Include git-lfs conditionally. If git-lfs is present on host and repo
> has lfs pointers, then git-lfs will be used. If git-lfs is not
> present
> on host, it will be ignored.
> 
> [YOCTO #13198]
> 
> Signed-off-by: Naveen Saini 
> ---
>  meta/conf/bitbake.conf | 3 +++
>  1 file changed, 3 insertions(+)

This sounds like we swap the current situation where things are
deterministic for a situation where the situation is not deterministic?

I'm not sure that is an improvement.

Cheers,

Richard

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


Re: [OE-core] [PATCH 1/2] systemd: change default locale from C.UTF-8 to C

2019-04-16 Thread Richard Purdie
On Tue, 2019-04-16 at 17:49 +0800, changqing...@windriver.com wrote:
> From: Changqing Li 
> 
> current default locale is set to C.UTF-8, but glibc not support
> locale C.UTF-8. so set to the default locale C.
> 
> [snip]
> if not meson.is_cross_build()
> choose_default_locale_sh =
> find_program('tools/choose-default-locale.sh')
> default_locale =
> run_command(choose_default_locale_sh).stdout().strip()
> else
> default_locale = 'C.UTF-8'
> endif
> 
> if default locale set to C.UTF-8, it will cause libpcre ptest fail:
> 
>   re> //8+L
> ** Failed to set locale ""

Doesn't your second patch mean we don't need this one?

Cheers,

Richard

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


[OE-core] [PATCH 1/2] systemd: change default locale from C.UTF-8 to C

2019-04-16 Thread changqing.li
From: Changqing Li 

current default locale is set to C.UTF-8, but glibc not support
locale C.UTF-8. so set to the default locale C.

[snip]
if not meson.is_cross_build()
choose_default_locale_sh = 
find_program('tools/choose-default-locale.sh')
default_locale = 
run_command(choose_default_locale_sh).stdout().strip()
else
default_locale = 'C.UTF-8'
endif

if default locale set to C.UTF-8, it will cause libpcre ptest fail:

  re> //8+L
** Failed to set locale ""

Signed-off-by: Changqing Li 
---
 meta/recipes-core/systemd/systemd_241.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index e61e07e..9efd06f 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -193,6 +193,7 @@ EXTRA_OEMESON += "-Dnobody-user=nobody \
   -Drootlibdir=${rootlibdir} \
   -Drootprefix=${rootprefix} \
   -Dsysvrcnd-path=${sysconfdir} \
+  -Ddefault-locale=C \
   "
 
 # Hardcode target binary paths to avoid using paths from sysroot
-- 
2.7.4

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


[OE-core] [PATCH 2/2] glibc: Add a C.UTF-8 locale

2019-04-16 Thread changqing.li
From: Changqing Li 

* This patch is get from fedora project, link:
https://src.fedoraproject.org/rpms/glibc/blob/0457f649e3fe6299efe384da13dfc923bbe65707/f/glibc-c-utf8-locale.patch

* At this point, most major distro have support this locale

* refer:
https://sourceware.org/bugzilla/show_bug.cgi?id=17318
https://sourceware.org/glibc/wiki/Proposals/C.UTF-8
https://bugs.python.org/issue19846
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636086

Signed-off-by: Changqing Li 
---
 .../glibc/glibc/Add-a-C.UTF-8-locale.patch | 270 +
 meta/recipes-core/glibc/glibc_2.29.bb  |   1 +
 2 files changed, 271 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/Add-a-C.UTF-8-locale.patch

diff --git a/meta/recipes-core/glibc/glibc/Add-a-C.UTF-8-locale.patch 
b/meta/recipes-core/glibc/glibc/Add-a-C.UTF-8-locale.patch
new file mode 100644
index 000..77b3ebd
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/Add-a-C.UTF-8-locale.patch
@@ -0,0 +1,270 @@
+>From 2eda7b462b415105f5a05c1323372d4e39d46439 Mon Sep 17 00:00:00 2001
+From: Mike FABIAN 
+Date: Mon, 10 Aug 2015 15:58:12 +0200
+Subject: [PATCH] Add a C.UTF-8 locale
+
+---
+ localedata/SUPPORTED |   1 +
+ localedata/locales/C | 238 +++
+ 2 files changed, 239 insertions(+)
+ create mode 100644 localedata/locales/C
+
+diff --git a/localedata/SUPPORTED b/localedata/SUPPORTED
+index 8ca023e..2a78391 100644
+--- a/localedata/SUPPORTED
 b/localedata/SUPPORTED
+@@ -1,6 +1,7 @@
+ # This file names the currently supported and somewhat tested locales.
+ # If you have any additions please file a glibc bug report.
+ SUPPORTED-LOCALES=\
++C.UTF-8/UTF-8 \
+ aa_DJ.UTF-8/UTF-8 \
+ aa_DJ/ISO-8859-1 \
+ aa_ER/UTF-8 \
+diff --git a/localedata/locales/C b/localedata/locales/C
+new file mode 100644
+index 000..fdf460e
+--- /dev/null
 b/localedata/locales/C
+@@ -0,0 +1,238 @@
++escape_char /
++comment_char %
++% Locale for C locale in UTF-8
++
++LC_IDENTIFICATION
++title  "C locale"
++source ""
++address""
++contact""
++email  "mfab...@redhat.com"
++tel""
++fax""
++language   "C"
++territory  ""
++revision   "1.0"
++date   "2015-08-10"
++%
++category  "C:2015";LC_IDENTIFICATION
++category  "C:2015";LC_CTYPE
++category  "C:2015";LC_COLLATE
++category  "C:2015";LC_TIME
++category  "C:2015";LC_NUMERIC
++category  "C:2015";LC_MONETARY
++category  "C:2015";LC_MESSAGES
++category  "C:2015";LC_PAPER
++category  "C:2015";LC_NAME
++category  "C:2015";LC_ADDRESS
++category  "C:2015";LC_TELEPHONE
++category  "C:2015";LC_MEASUREMENT
++END LC_IDENTIFICATION
++
++LC_CTYPE
++copy "i18n"
++
++translit_start
++include "translit_combining";""
++translit_end
++
++END LC_CTYPE
++
++LC_COLLATE
++order_start forward
++
++..
++
++
++..
++
++
++..
++
++
++..
++
++
++..
++
++
++..
++
++UNDEFINED
++order_end
++END LC_COLLATE
++
++LC_MONETARY
++% This is the 14652 i18n fdcc-set definition for
++% the LC_MONETARY category
++% (except for the int_curr_symbol and currency_symbol, they are empty in
++% the 14652 i18n fdcc-set definition and also empty in
++% glibc/locale/C-monetary.c. But localedef complains in that case).
++%
++% Using "USD" for int_curr_symbol. But maybe "XXX" would be better?
++% XXX is "No currency" (https://en.wikipedia.org/wiki/ISO_4217)
++int_curr_symbol ""
++% Using "$" for currency_symbol. But maybe  would be better?
++% U+00A4 is the "generic currency symbol"
++% (https://en.wikipedia.org/wiki/Currency_sign_%28typography%29)
++currency_symbol ""
++mon_decimal_point   ""
++mon_thousands_sep   ""
++mon_grouping-1
++positive_sign   ""
++negative_sign   ""
++int_frac_digits -1
++frac_digits -1
++p_cs_precedes   -1
++int_p_sep_by_space  -1
++p_sep_by_space  -1
++n_cs_precedes   -1
++int_n_sep_by_space  -1
++n_sep_by_space  -1
++p_sign_posn -1
++n_sign_posn -1
++%
++END LC_MONETARY
++
++LC_NUMERIC
++% This is the POSIX Locale definition for
++% the LC_NUMERIC category.
++%
++decimal_point   ""
++thousands_sep   ""
++grouping-1
++END LC_NUMERIC
++
++LC_TIME
++% This is the POSIX Locale definition for
++% the LC_TIME category.
++%
++% Abbreviated weekday names (%a)
++abday   "";"";/
++"";"";/
++"";"";/
++""
++
++% Full weekday names (%A)
++day "";/
++"";/
++"";/
++
"";/
++"";/
++"";/
++""
++
++% Abbreviated month names (%b)
++abmon   "";"";/
++"";"";/
++"";"";/
++"";"";/
++"";"";/
++"";""
++
++% Full month names (%B)
++mon "";/
++"";/
++"";/
++"";/
++"";/
++"";/
++"";/
++"";/
++
"";/
++"";/
++"";/
++""
++
++% Week description, consists of three fields:

Re: [OE-core] [PATCH] package_ipk: handle exception for subprocess command

2019-04-16 Thread Andrey Zhizhikin
On Tue, Apr 16, 2019 at 10:24 AM  wrote:
>
> On Tue, 2019-04-16 at 09:10 +0200, Andrey Zhizhikin wrote:
> > On Mon, Apr 15, 2019 at 6:45 PM Richard Purdie
> >  wrote:
> > > On Sun, 2019-04-14 at 16:21 +0200, Andrey Zhizhikin wrote:
> > > > Ping.
> > > >
> > > > On Thu, Mar 28, 2019 at 10:47 AM Andrey Zhizhikin <
> > > > andre...@gmail.com
> > > > > wrote:
> > > > > When opkg-build command fails to execute, subprocess is
> > > > > returned
> > > > > with
> > > > > exception instead of printing to stderr. This causes the error
> > > > > logging
> > > > > not to be printed out, as the "finally" statement does not
> > > > > contain
> > > > > any
> > > > > bitbake error output.
> > > > >
> > > > > One example of this behavior is when the package name contains
> > > > > uppercase
> > > > > character, which are rejected by opkg-build,
> > > > > subprocess.check_output
> > > > > would except and no error log would be produced.
> > > > >
> > > > > This commit catches the exception subprocess.CalledProcessError
> > > > > and
> > > > > produces bb.error output visible to the user.
> > > > >
> > > > > Signed-off-by: Andrey Zhizhikin 
> > > > > ---
> > > > >  meta/classes/package_ipk.bbclass | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/meta/classes/package_ipk.bbclass
> > > > > b/meta/classes/package_ipk.bbclass
> > > > > index d1b317b42b..f181f5b4fd 100644
> > > > > --- a/meta/classes/package_ipk.bbclass
> > > > > +++ b/meta/classes/package_ipk.bbclass
> > > > > @@ -234,6 +234,8 @@ def ipk_write_pkg(pkg, d):
> > > > >  ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir,
> > > > > pkgname,
> > > > > ipkver, d.getVar('PACKAGE_ARCH'))
> > > > >  sign_ipk(d, ipk_to_sign)
> > > > >
> > > > > +except subprocess.CalledProcessError as exc:
> > > > > +bb.error("OPKG Build failed: %s" % exc.output)
> > > > >  finally:
> > > > >  cleanupcontrol(root)
> > > > >  bb.utils.unlockfile(lf)
> > >
> > > My main concern is why isn't the raised exception being caught and
> > > causing its own error...
> >
> > The raised exception is actually caught by a finally: statement
> > below, and the build gracefully terminates. The problem is that
> > finally: block does not contain any valuable output to inform user
> > what actually happened.
>
> This isn't how python works. The exception should be "re-raised after
> the finally clause has been executed" to quote the python manual:
> https://docs.python.org/3/tutorial/errors.html#defining-clean-up-actions
>

Sorry, I guess my previous reply was a bit confusing.. I agree, the
exception would not be blocked by finally: statement, and this is why
the build gracefully shuts down. What the finally: block does not
contain is an bb.error() which would provide more information about
the source of error return from subprocess.check_output(). In case if
this patch is applied - exception would be handled and not propagated
further.

Can you please advise whether there would another "raise" statement be
needed after bb.error in the patch, so that in addition to the
subprocess output user would get an entire callstack (like in the case
when subprocess.CalledProcessError was not handled). Currently, with
this patch user would receive the build error with the error string
output from subprocess.check_output().

Thanks a lot!

> > subprocess.check_output() would throw this exception every time the
> > command in sub-process is terminated with the error code, and since
> > we
> > do tell it to dump stderr -> stdout - the error message would be
> > contained in the exception output.
> > This additional handling of the subprocess.check_output() exception
> > would extract the stdout from the failed process here and just shows
> > to the user the actual output from command processing, so that he is
> > aware what was wrong.
> >
> > The case where I personally needed it the most is when the package
> > name contained upper and lower case characters, which were rejected
> > by
> > the opkg-build command and until I introduced the handler - I just
> > had
> > an erroneous build failure without any additional information on what
> > went wrong.
> >
> > > This feels like a workaround rather than fixing the underlying
> > > problem
> > > which I suspect might be in the parallel execution code exception
> > > handling.
> > The exception from  subprocess.check_output() is actually expected
> > and
> > perfectly handled, so there is no problem with that. This patch would
> > just deliver a bit more information in the output for user to react
> > proper.
>
>
> See my comment above, the finally should not be blocking this exception
> from being raised...
>
> Cheers,
>
> Richard
>

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


Re: [OE-core] [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

2019-04-16 Thread Yu, Mingli



On 2019年04月16日 00:21, Adrian Bunk wrote:

On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote:


What are you trying to convey ? That’s what I mentioned before I began my
reply however to reiterate my point was if a package is not usually built
and tested with this combination which is evident because it fails to build
then how good would it be if we fix this error especially complex packages
like compilers so is it worth to fix them or disable Og for them


Packages that usually get built and tested with -Og should be pretty rare,
and these specific build failures are better at finding the rare packages
that use -Werror than pointing at potential miscompilations.


From a distribution point of view, a package build with -Werror by

default is arguably a bug since this frequently breaks when something
is changed (usually the compiler version).

-Og is better suited than the -O that was previously used for debugging,
but are we talking about debug builds or production builds?
If users would be using DEBUG_OPTIMIZATION in production builds that


Thanks Adrian and Khem's response!
We indeed don't use DEBUG_OPTIMIZATION in production build.

But still comes question: how to silence gcc-sanitizers build failure 
when debug build enabled?


Thanks,


would be wrong - this will always be a mostly untested situation
with an increased probability of hitting bugs noone else has seen
before.

cu
Adrian


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


Re: [OE-core] [PATCH] package_ipk: handle exception for subprocess command

2019-04-16 Thread richard . purdie
On Tue, 2019-04-16 at 09:10 +0200, Andrey Zhizhikin wrote:
> On Mon, Apr 15, 2019 at 6:45 PM Richard Purdie
>  wrote:
> > On Sun, 2019-04-14 at 16:21 +0200, Andrey Zhizhikin wrote:
> > > Ping.
> > > 
> > > On Thu, Mar 28, 2019 at 10:47 AM Andrey Zhizhikin <
> > > andre...@gmail.com
> > > > wrote:
> > > > When opkg-build command fails to execute, subprocess is
> > > > returned
> > > > with
> > > > exception instead of printing to stderr. This causes the error
> > > > logging
> > > > not to be printed out, as the "finally" statement does not
> > > > contain
> > > > any
> > > > bitbake error output.
> > > > 
> > > > One example of this behavior is when the package name contains
> > > > uppercase
> > > > character, which are rejected by opkg-build,
> > > > subprocess.check_output
> > > > would except and no error log would be produced.
> > > > 
> > > > This commit catches the exception subprocess.CalledProcessError
> > > > and
> > > > produces bb.error output visible to the user.
> > > > 
> > > > Signed-off-by: Andrey Zhizhikin 
> > > > ---
> > > >  meta/classes/package_ipk.bbclass | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/meta/classes/package_ipk.bbclass
> > > > b/meta/classes/package_ipk.bbclass
> > > > index d1b317b42b..f181f5b4fd 100644
> > > > --- a/meta/classes/package_ipk.bbclass
> > > > +++ b/meta/classes/package_ipk.bbclass
> > > > @@ -234,6 +234,8 @@ def ipk_write_pkg(pkg, d):
> > > >  ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir,
> > > > pkgname,
> > > > ipkver, d.getVar('PACKAGE_ARCH'))
> > > >  sign_ipk(d, ipk_to_sign)
> > > > 
> > > > +except subprocess.CalledProcessError as exc:
> > > > +bb.error("OPKG Build failed: %s" % exc.output)
> > > >  finally:
> > > >  cleanupcontrol(root)
> > > >  bb.utils.unlockfile(lf)
> > 
> > My main concern is why isn't the raised exception being caught and
> > causing its own error...
> 
> The raised exception is actually caught by a finally: statement
> below, and the build gracefully terminates. The problem is that
> finally: block does not contain any valuable output to inform user
> what actually happened.

This isn't how python works. The exception should be "re-raised after
the finally clause has been executed" to quote the python manual:
https://docs.python.org/3/tutorial/errors.html#defining-clean-up-actions

> subprocess.check_output() would throw this exception every time the
> command in sub-process is terminated with the error code, and since
> we
> do tell it to dump stderr -> stdout - the error message would be
> contained in the exception output.
> This additional handling of the subprocess.check_output() exception
> would extract the stdout from the failed process here and just shows
> to the user the actual output from command processing, so that he is
> aware what was wrong.
> 
> The case where I personally needed it the most is when the package
> name contained upper and lower case characters, which were rejected
> by
> the opkg-build command and until I introduced the handler - I just
> had
> an erroneous build failure without any additional information on what
> went wrong.
> 
> > This feels like a workaround rather than fixing the underlying
> > problem
> > which I suspect might be in the parallel execution code exception
> > handling.
> The exception from  subprocess.check_output() is actually expected
> and
> perfectly handled, so there is no problem with that. This patch would
> just deliver a bit more information in the output for user to react
> proper.


See my comment above, the finally should not be blocking this exception
from being raised...

Cheers,

Richard

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


Re: [OE-core] [PATCH 18/19] python3-pygobject: update to 3.32.0

2019-04-16 Thread Richard Purdie
On Mon, 2019-04-15 at 12:54 +0200, Alexander Kanavin wrote:
> Switch to meson build system.
> 
> Add a patch to disable tests.
> 
> Add "introspection" to unknown configure option whitelist, as
> this recipe needs g-i unconditionally.
> 
> Signed-off-by: Alexander Kanavin 
> ---
>  .../0001-Do-not-build-tests.patch | 26
> +++
>  ..._3.28.3.bb => python3-pygobject_3.32.0.bb} | 10 ---
>  2 files changed, 33 insertions(+), 3 deletions(-)
>  create mode 100644 meta/recipes-devtools/python/python3-
> pygobject/0001-Do-not-build-tests.patch
>  rename meta/recipes-devtools/python/{python3-pygobject_3.28.3.bb =>
> python3-pygobject_3.32.0.bb} (68%)

Seems to have an issue with multilib?

https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/519

Cheers,

Richard

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


[OE-core] [PATCH v2 1/2] elfutils: add ptest support

2019-04-16 Thread mingli.yu
From: Mingli Yu 

Add testsuite-ignore-elflint.diff from debian
(http://ftp.de.debian.org/debian/pool/main/e/elfutils/elfutils_0.176-1.debian.tar.xz)
to fix below ptest failure:
 | ./run-strip-strmerge.sh: line 33: testrun_on_self_skip: command not found
 | FAIL: run-strip-strmerge.sh

Add check for gcc for two test cases such as
run-strip-nothing.sh and run-strip-g.sh which
depends on gcc at run time.

Signed-off-by: Mingli Yu 
---
 meta/recipes-devtools/elfutils/elfutils_0.176.bb   | 27 ++-
 .../0001-skip-the-test-when-gcc-not-deployed.patch | 45 +++
 .../files/debian/testsuite-ignore-elflint.diff | 52 ++
 meta/recipes-devtools/elfutils/files/run-ptest |  6 +++
 .../elfutils/files/serial-tests.patch  | 28 
 5 files changed, 157 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/elfutils/files/0001-skip-the-test-when-gcc-not-deployed.patch
 create mode 100644 
meta/recipes-devtools/elfutils/files/debian/testsuite-ignore-elflint.diff
 create mode 100644 meta/recipes-devtools/elfutils/files/run-ptest
 create mode 100644 meta/recipes-devtools/elfutils/files/serial-tests.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
index fd901c9..917c296 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
@@ -27,16 +27,24 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://debian/hurd_path.patch \
file://debian/ignore_strmerge.diff \
file://debian/disable_werror.patch \
+   file://debian/testsuite-ignore-elflint.diff \
+   file://0001-skip-the-test-when-gcc-not-deployed.patch \
+   file://run-ptest \
+   file://serial-tests.patch \
"
 SRC_URI_append_libc-musl = " 
file://0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch"
 
 SRC_URI[md5sum] = "077e4f49320cad82bf17a997068b1db9"
 SRC_URI[sha256sum] = 
"eb5747c371b0af0f71e86215a5ebb88728533c3a104a43d4231963f308cd1023"
 
-inherit autotools gettext
+inherit autotools gettext ptest
 
 EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
 EXTRA_OECONF_append_class-native = " --without-bzlib"
+# gcc has been added to blacklist, we will find workaround solution
+RDEPENDS_${PN}-ptest = "libasm libelf bash"
+
+EXTRA_OECONF_append_class-target += "--enable-tests-rpath"
 
 do_install_append() {
if [ "${TARGET_ARCH}" != "x86_64" ] && [ -z `echo "${TARGET_ARCH}"|grep 
'i.86'` ];then
@@ -44,6 +52,23 @@ do_install_append() {
fi
 }
 
+do_compile_ptest() {
+   cd ${B}/tests
+   oe_runmake buildtest-TESTS
+}
+
+do_install_ptest() {
+   if [ ${PTEST_ENABLED} = "1" ]; then
+   cp -r ${S}/tests/   ${D}${PTEST_PATH}
+   cp -r ${B}/tests/*  ${D}${PTEST_PATH}/tests
+   cp -r ${B}/src  ${D}${PTEST_PATH}
+   cp -r ${B}/config.h ${D}${PTEST_PATH}
+   cp -r ${B}/backends ${D}${PTEST_PATH}
+   sed -i '/^Makefile:/c Makefile:'
${D}${PTEST_PATH}/tests/Makefile
+   find ${D}${PTEST_PATH} -type f -name *.[hoc] | xargs -i rm {}
+   fi
+}
+
 EXTRA_OEMAKE_class-native = ""
 EXTRA_OEMAKE_class-nativesdk = ""
 
diff --git 
a/meta/recipes-devtools/elfutils/files/0001-skip-the-test-when-gcc-not-deployed.patch
 
b/meta/recipes-devtools/elfutils/files/0001-skip-the-test-when-gcc-not-deployed.patch
new file mode 100644
index 000..67ca0e4
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/files/0001-skip-the-test-when-gcc-not-deployed.patch
@@ -0,0 +1,45 @@
+From 61939d2e552e7645ecd671fa01cf1c7a72caa82a Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Fri, 12 Apr 2019 16:29:58 +0800
+Subject: [PATCH] skip the test when gcc not deployed
+
+Skip the tests which depend on gcc when
+gcc not deployed.
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Mingli Yu 
+---
+ tests/run-strip-g.sh   | 2 ++
+ tests/run-strip-nothing.sh | 2 ++
+ 2 files changed, 4 insertions(+)
+
+diff --git a/tests/run-strip-g.sh b/tests/run-strip-g.sh
+index 1303819..a943dec 100755
+--- a/tests/run-strip-g.sh
 b/tests/run-strip-g.sh
+@@ -24,6 +24,8 @@
+ 
+ tempfiles a.out strip.out debug.out readelf.out
+ 
++# skip the test if gcc deployed
++which gcc || exit 77
+ echo Create debug a.out.
+ echo "int main() { return 1; }" | gcc -g -xc -
+ 
+diff --git a/tests/run-strip-nothing.sh b/tests/run-strip-nothing.sh
+index 914fdfb..d03f734 100755
+--- a/tests/run-strip-nothing.sh
 b/tests/run-strip-nothing.sh
+@@ -22,6 +22,8 @@
+ 
+ tempfiles a.out strip.out debug.out
+ 
++# skip the case if no gcc deployed
++which gcc || exit 77
+ # Create no-debug a.out.
+ echo "int main() { return 1; }" | gcc -s -xc -
+ 
+-- 
+2.7.4
+
diff --git 

[OE-core] [PATCH v2 2/2] elfutils: fix build failure with musl

2019-04-16 Thread mingli.yu
From: Mingli Yu 

Fix below build failure with musl when ptest
enabled.
| In file included from ../../elfutils-0.176/tests/dwfl-proc-attach.c:33:
| ../../elfutils-0.176/lib/system.h:63:35: error: called object 'err' is not a 
function or function pointer
|  #define error(status, errno, ...) err(status, __VA_ARGS__)
|^~~
| ../../elfutils-0.176/tests/dwfl-proc-attach.c:92:5: note: in expansion of 
macro 'error'
|  error (-1, 0, "dwfl_linux_proc_attach pid %d: %s", pid,
|  ^
| ../../elfutils-0.176/tests/dwfl-proc-attach.c:79:7: note: declared here
|int err;
|^~~

The root cause is because the conflicts between
vairable and function name, so change the variable
name to workaround it.

Signed-off-by: Mingli Yu 
---
 meta/recipes-devtools/elfutils/elfutils_0.176.bb   |  4 +-
 ...1-fix-err-variable-and-function-conflicts.patch | 62 ++
 2 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/elfutils/files/0001-fix-err-variable-and-function-conflicts.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
index 917c296..ae3d961 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
@@ -32,7 +32,9 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://run-ptest \
file://serial-tests.patch \
"
-SRC_URI_append_libc-musl = " 
file://0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch"
+SRC_URI_append_libc-musl = " 
file://0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch \
+ 
file://0001-fix-err-variable-and-function-conflicts.patch \
+"
 
 SRC_URI[md5sum] = "077e4f49320cad82bf17a997068b1db9"
 SRC_URI[sha256sum] = 
"eb5747c371b0af0f71e86215a5ebb88728533c3a104a43d4231963f308cd1023"
diff --git 
a/meta/recipes-devtools/elfutils/files/0001-fix-err-variable-and-function-conflicts.patch
 
b/meta/recipes-devtools/elfutils/files/0001-fix-err-variable-and-function-conflicts.patch
new file mode 100644
index 000..4cf5400
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/files/0001-fix-err-variable-and-function-conflicts.patch
@@ -0,0 +1,62 @@
+From 2c50fe7068bd6911958c6d851aef88179e73bb21 Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Tue, 16 Apr 2019 15:30:38 +0800
+Subject: [PATCH] fix err variable and function conflicts
+
+There comes below build failure with musl when
+ptest enabled.
+| In file included from ../../elfutils-0.176/tests/dwfl-proc-attach.c:33:
+| ../../elfutils-0.176/lib/system.h:63:35: error: called object 'err' is not a 
function or function pointer
+|  #define error(status, errno, ...) err(status, __VA_ARGS__)
+|^~~
+| ../../elfutils-0.176/tests/dwfl-proc-attach.c:92:5: note: in expansion of 
macro 'error'
+|  error (-1, 0, "dwfl_linux_proc_attach pid %d: %s", pid,
+|  ^
+| ../../elfutils-0.176/tests/dwfl-proc-attach.c:79:7: note: declared here
+|int err;
+|^~~
+
+It is because there is no error.h in musl and
+the patch 0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch
+has updated to use err.h to replace error.h
+and also added macro definiton as below when
+use musl.
+ #define error(status, errno, ...) err(status, __VA_ARGS__)
+
+And in err.h, there is below logic:
+_Noreturn void err(int, const char *, ...);
+
+But when ptest enabled, there comes below error
+as there is both variable and function defined
+to be err in tests/dwfl-proc-attach.c.
+So change the err variable's name to workaround
+the build failure with musl.
+
+Upstream-Status: Inappropriate [workaround in musl]
+
+Signed-off-by: Mingli Yu 
+---
+ tests/dwfl-proc-attach.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/tests/dwfl-proc-attach.c b/tests/dwfl-proc-attach.c
+index 102ba18..ad4208e 100644
+--- a/tests/dwfl-proc-attach.c
 b/tests/dwfl-proc-attach.c
+@@ -76,10 +76,10 @@ main (int argc __attribute__ ((unused)),
+   char **argv __attribute__ ((unused)))
+ {
+   /* Create two extra threads to iterate through.  */
+-  int err;
+-  if ((err = pthread_create (, NULL, sleeper, NULL)) != 0)
++  int err1;
++  if ((err1 = pthread_create (, NULL, sleeper, NULL)) != 0)
+ error (-1, err, "Couldn't create thread1");
+-  if ((err = pthread_create (, NULL, sleeper, NULL)) != 0)
++  if ((err1 = pthread_create (, NULL, sleeper, NULL)) != 0)
+ error (-1, err, "Couldn't create thread2");
+ 
+   Dwfl *dwfl = dwfl_begin (_callbacks);
+-- 
+2.7.4
+
-- 
2.7.4

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


Re: [OE-core] [PATCH] package_ipk: handle exception for subprocess command

2019-04-16 Thread Andrey Zhizhikin
On Mon, Apr 15, 2019 at 6:45 PM Richard Purdie
 wrote:
>
> On Sun, 2019-04-14 at 16:21 +0200, Andrey Zhizhikin wrote:
> > Ping.
> >
> > On Thu, Mar 28, 2019 at 10:47 AM Andrey Zhizhikin  > > wrote:
> > > When opkg-build command fails to execute, subprocess is returned
> > > with
> > > exception instead of printing to stderr. This causes the error
> > > logging
> > > not to be printed out, as the "finally" statement does not contain
> > > any
> > > bitbake error output.
> > >
> > > One example of this behavior is when the package name contains
> > > uppercase
> > > character, which are rejected by opkg-build,
> > > subprocess.check_output
> > > would except and no error log would be produced.
> > >
> > > This commit catches the exception subprocess.CalledProcessError and
> > > produces bb.error output visible to the user.
> > >
> > > Signed-off-by: Andrey Zhizhikin 
> > > ---
> > >  meta/classes/package_ipk.bbclass | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/meta/classes/package_ipk.bbclass
> > > b/meta/classes/package_ipk.bbclass
> > > index d1b317b42b..f181f5b4fd 100644
> > > --- a/meta/classes/package_ipk.bbclass
> > > +++ b/meta/classes/package_ipk.bbclass
> > > @@ -234,6 +234,8 @@ def ipk_write_pkg(pkg, d):
> > >  ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir, pkgname,
> > > ipkver, d.getVar('PACKAGE_ARCH'))
> > >  sign_ipk(d, ipk_to_sign)
> > >
> > > +except subprocess.CalledProcessError as exc:
> > > +bb.error("OPKG Build failed: %s" % exc.output)
> > >  finally:
> > >  cleanupcontrol(root)
> > >  bb.utils.unlockfile(lf)
>
> My main concern is why isn't the raised exception being caught and
> causing its own error...

The raised exception is actually caught by a finally: statement below,
and the build gracefully terminates. The problem is that finally:
block does not contain any valuable output to inform user what
actually happened.
subprocess.check_output() would throw this exception every time the
command in sub-process is terminated with the error code, and since we
do tell it to dump stderr -> stdout - the error message would be
contained in the exception output.
This additional handling of the subprocess.check_output() exception
would extract the stdout from the failed process here and just shows
to the user the actual output from command processing, so that he is
aware what was wrong.

The case where I personally needed it the most is when the package
name contained upper and lower case characters, which were rejected by
the opkg-build command and until I introduced the handler - I just had
an erroneous build failure without any additional information on what
went wrong.

>
> This feels like a workaround rather than fixing the underlying problem
> which I suspect might be in the parallel execution code exception
> handling.
The exception from  subprocess.check_output() is actually expected and
perfectly handled, so there is no problem with that. This patch would
just deliver a bit more information in the output for user to react
proper.
>
> Cheers,
>
> Richard
>
>

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


[OE-core] [PATCH v2] libsoup: Upgrade from 2.64.2 to 2.66.1

2019-04-16 Thread Alistair Francis
Signed-off-by: Alistair Francis 
---
 ...no-introspection-when-cross-building.patch | 20 +++
 ...up-2.4_2.64.2.bb => libsoup-2.4_2.66.1.bb} |  4 ++--
 2 files changed, 14 insertions(+), 10 deletions(-)
 rename meta/recipes-support/libsoup/{libsoup-2.4_2.64.2.bb => 
libsoup-2.4_2.66.1.bb} (92%)

diff --git 
a/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch
 
b/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch
index 72b029a80b..cd6de853e5 100644
--- 
a/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch
+++ 
b/meta/recipes-support/libsoup/libsoup-2.4/0001-Do-not-enforce-no-introspection-when-cross-building.patch
@@ -1,24 +1,28 @@
-From 921888affe66953c92a08ae440e911b016b124be Mon Sep 17 00:00:00 2001
+From 85f7b74fc602214297928afe09347c31d696173d Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Fri, 15 Feb 2019 14:21:06 +0100
 Subject: [PATCH] Do not enforce no-introspection when cross-building
 
 Upstream-Status: Pending
 Signed-off-by: Alexander Kanavin 
+Signed-off-by: Alistair Francis 
 ---
  meson.build | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/meson.build b/meson.build
-index 5a92cda..cfb3520 100644
+index 25887f9..6261a7c 100644
 --- a/meson.build
 +++ b/meson.build
-@@ -262,7 +262,7 @@ enable_gnome = get_option('gnome') and 
host_machine.system() != 'windows'
- #
- # GObject introspection #
- #
--enable_introspection = get_option('introspection') and 
find_program('g-ir-scanner', required: false).found() and not 
meson.is_cross_build()
-+enable_introspection = get_option('introspection') and 
find_program('g-ir-scanner', required: false).found()
+@@ -281,7 +281,7 @@ enable_gnome = get_option('gnome') and 
host_machine.system() != 'windows'
+ # FIXME: once we start to require meson 0.49.0+ and gnome-introspection 
1.58.1+
+ # the we can enable the introspection even for the static build. See
+ # https://github.com/mesonbuild/meson/pull/4478.
+-enable_introspection = get_option('introspection') and 
find_program('g-ir-scanner', required: false).found() and not 
meson.is_cross_build() and not is_static_library
++enable_introspection = get_option('introspection') and 
find_program('g-ir-scanner', required: false).found() and not is_static_library
  
  
  # Vala API #
+-- 
+2.20.1
+
diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb 
b/meta/recipes-support/libsoup/libsoup-2.4_2.66.1.bb
similarity index 92%
rename from meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb
rename to meta/recipes-support/libsoup/libsoup-2.4_2.66.1.bb
index b095397ec2..99fb65844e 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.66.1.bb
@@ -12,8 +12,8 @@ SHRT_VER = 
"${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}"
 SRC_URI = "${GNOME_MIRROR}/libsoup/${SHRT_VER}/libsoup-${PV}.tar.xz \

file://0001-Do-not-enforce-no-introspection-when-cross-building.patch \
"
-SRC_URI[md5sum] = "cac755dc6c6acd6e0c70007f547548f5"
-SRC_URI[sha256sum] = 
"75ddc194a5b1d6f25033bb9d355f04bfe5c03e0e1c71ed0774104457b3a786c6"
+SRC_URI[md5sum] = "5f04c09a06f6dbe4c4d3f003992145ce"
+SRC_URI[sha256sum] = 
"4a2cb6c1174540af13661636035992c2b179dfcb39f4d3fa7bee3c7e355c43ff"
 
 S = "${WORKDIR}/libsoup-${PV}"
 
-- 
2.20.1

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