Re: [OE-core] [PATCH] gcc-cross-canadian.inc: add INSANE_SKIP_ to avoid build warning

[Yu, Mingli]

Please ignore this patch.

Verified gcc-5.4 and gcc-6.1 and it proves that no same warning exist.

Thanks,
Grace

On 2016年07月26日 16:22, mingli...@windriver.com wrote:

WARNING: QA Issue: gcc-cross-canadian-i586-dbg: found library in wrong location:
/PATH/sysroots/x86_64-oesdk-linux/usr/libexec/i586-oe-linux/gcc/
i586-oe-linux/5.2.0/.debug/libcc1.so.0.0.0

This warning is introduced by commit f6e47aa(gcc-target 5.1: fix for libcc1)

Signed-off-by: Li Xin <lixin.f...@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
(From OE-Core jethro rev: 62c51c4178fb66341498c71c74ce42652568c7fa)
Signed-off-by: Yue Tao <yue@windriver.com>
Signed-off-by: Mingli Yu <mingli...@windriver.com>
---
  meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc 
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index ec1d281..1286179 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -83,6 +83,8 @@ FILES_${PN} = "\
  ${prefix}/${TARGET_SYS}/usr/include/* \
  "
  INSANE_SKIP_${PN} += "dev-so"
+INSANE_SKIP_${PN} += "libdir"
+INSANE_SKIP_${PN}-dbg += "libdir"

  FILES_${PN}-doc = "\
  ${infodir} \


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

Re: [OE-core] [PATCH] grub-efi: run autogen.sh before configure

[Yu, Mingli]

On 2016年07月11日 18:22, Burton, Ross wrote:


On 6 May 2016 at 13:13, Catalin Enache > wrote:

  DEPENDS_class-target = "grub-efi-native"
  RDEPENDS_${PN}_class-target = "diffutils freetype"
+DEPENDS += "autogen-native"


Because += happens after overrides this results in autogen-native only a
dependency in native builds, so you can't be sure it will be present for
target builds.


Thanks Ross! Will update the line as:
DEPENDS_append = " autogen-native"


Should the configure_prepend and autogen-native be added to grub2.inc so
that every recipe has that dependency?


Hi Catalin,
Could you help to confirm if the three recipes (grub-efi_2.00.bb, 
grub_2.00.bb, grub_git.bb) all need configure_prepend and 
autogen-native? if yes, I will resent the patch to add configure_prepend 
and autogen-native to grub2.inc, if not, then we still let it stay in 
grub-efi recipe.


Thanks,
Grace


Ross



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

Re: [OE-core] [PATCH] grub-efi: run autogen.sh before configure

[Yu, Mingli]

ping

Thanks,
Grace

On 2016年05月06日 20:13, Catalin Enache wrote:

When adding new source files from upstream the autogen.sh
script needs to be run.

Signed-off-by: Catalin Enache 
---
  meta/recipes-bsp/grub/grub-efi_2.00.bb | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/meta/recipes-bsp/grub/grub-efi_2.00.bb 
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
index 5a0dc95..62ded6e 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -2,6 +2,7 @@ require grub2.inc

  DEPENDS_class-target = "grub-efi-native"
  RDEPENDS_${PN}_class-target = "diffutils freetype"
+DEPENDS += "autogen-native"
  PR = "r3"

  SRC_URI += " \
@@ -39,6 +40,11 @@ EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 
'largefile', '--enable-
  # and many other places in the grub code when compiled with some native gcc 
compilers (specifically, gentoo)
  CFLAGS_append_class-native = " -Wno-error=trampolines"

+do_configure_prepend() {
+( cd ${S}
+${S}/autogen.sh )
+}
+
  do_install_class-native() {
install -d ${D}${bindir}
install -m 755 grub-mkimage ${D}${bindir}


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

Re: [OE-core] [PATCH] at: add libselinux to PACKAGECONFIG

[Yu, Mingli]

//ping

Thanks,
Grace

On 2016年07月21日 10:40, mingli...@windriver.com wrote:

* add libselinux to PACKAGECONFIG for at

Signed-off-by: Mingli Yu <mingli...@windriver.com>
---
  meta/recipes-extended/at/at_3.1.20.bb | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/meta/recipes-extended/at/at_3.1.20.bb 
b/meta/recipes-extended/at/at_3.1.20.bb
index 1c3eefc..ce5ff53 100644
--- a/meta/recipes-extended/at/at_3.1.20.bb
+++ b/meta/recipes-extended/at/at_3.1.20.bb
@@ -7,6 +7,12 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=4325afd396febcb659c36b49533135d4"
  DEPENDS = "flex flex-native \
 ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"

+PACKAGECONFIG ?= "\
+${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)} \
+"
+
+PACKAGECONFIG[selinux] = "--with-selinux,--without-selinux,libselinux,"
+
  RDEPENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
'${PAM_DEPS}', '', d)} \
  "



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

Re: [OE-core] [PATCH] grub2.inc: run autogen.sh before configure

[Yu, Mingli]

On 2016年08月02日 03:22, Burton, Ross wrote:


On 1 August 2016 at 02:54, > wrote:

When adding new source files from upstream the autogen.sh
script needs to be run


This results in this change:

packages/corei7-64-poky-linux/grub-efi/grub-efi: PKGSIZE changed from
6787555 to 7524227 (+10%)
   * FILELIST: added "/usr/sbin/grub-sparc64-setup"
packages/corei7-64-poky-linux/grub-efi/grub-efi: FILELIST: added
"/usr/sbin/grub-sparc64-setup"
packages/corei7-64-poky-linux/grub/grub-dbg: PKGSIZE changed from
26159624 to 28829025 (+10%)
packages/corei7-64-poky-linux/grub/grub: PKGSIZE changed from 5942339 to
6679011 (+12%)
   * FILELIST: added "/usr/sbin/grub-sparc64-setup"
packages/corei7-64-poky-linux/grub/grub: FILELIST: added
"/usr/sbin/grub-sparc64-setup"

Is this intentional?


Thanks Ross! This is unintentional, adding autogen.sh in 
do_configure_prepend in grub2.inc results this issue, it is because:


* before add autogen.sh in grub2.inc, there is a patch
./meta/recipes-bsp/grub/files/grub2-remove-sparc64-setup-from-x86-builds.patch
  used to remove grub-sparc64-setup in Makefile.util.am for x86 builds.

* After add autogen.sh in grub2.inc, the previous patch logic to remove
  grub-sparc64-setup in Makefile.util.am for x86 builds is overwritten 
 by autogen.sh (Which will regenerate Makefile.util.am) in do_configure 
phase.


Anyway, resend the V2 patch to remove the side effect.

Thanks,
Grace

Ross

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

Re: [OE-core] [PATCH 0/4] groff: add file-homedir-perl to RDEPENDS

[Yu, Mingli]

ping

Thanks,

On 2016年08月26日 17:28, Yu, Mingli wrote:



On 2016年08月26日 16:55, Burton, Ross wrote:


On 26 August 2016 at 03:25, <mingli...@windriver.com
<mailto:mingli...@windriver.com>> wrote:

The series add file-homedir-perl to RDEPENDS for groff as
glilypond rdepends on File/HomeDir.pm provided by file-homedir-perl


Isn't lilypond the music score layout tool?


glilypond which is provided by groff transforms sheet music written in
the lilypond language into the groff language using the .PSPIC request,
such that groff can transform it into a format that can be displayed
directly.

  This seems very

specialist.  I suggest adding the new recipes to meta-perl, and then if
someone does want to use it then the requirements are available.

Unless you're only hitting this because of testing, in which case I'd
suggest skipping this test.


The command glilypond needs File::HomeDir perl module which is provided
by file-homedir-perl

Thanks,
Grace



Ross

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

Re: [OE-core] [PATCH 0/4] groff: add file-homedir-perl to RDEPENDS

[Yu, Mingli]

On 2016年09月02日 19:41, Richard Purdie wrote:

On Fri, 2016-09-02 at 09:54 +0800, Yu, Mingli wrote:

ping


I'm with Ross here. We don't often have need for sheet music conversion
in groff in embedded or IoT devices. I'd prefer to have configuration
to disable this.


Okay, thanks Richard for respond!

Thanks,



Cheers,

Richard


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

Re: [OE-core] Review request 0/21: ltp: add libwww-perl-perl to RDEPENDS

[Yu, Mingli]

On 2016年08月29日 19:52, Alexander Kanavin wrote:

On 08/29/2016 05:16 AM, mingli...@windriver.com wrote:

The series add libwww-perl-perl to RDEPENDS for ltp as
STPfailure_report.pl provided by ltp depends
on LWP/Simple.pm which is provided by libwww-perl-perl


You are adding 20 new recipes, just to support something in a single
perl script in a single project. Please investigate, what is that
something, is it truly needed in oe-core context, and can it be
disabled, patched out or rewritten so that it doesn't pull in this
massive list of dependencies.


Thanks Alex for your comments!
1, Have double checked the script STPfailure_report.pl history from the 
ltp repo(git://github.com/linux-test-project/ltp.git), it is added as
a tool to analyze failures from LTP runs on the OSDL's Scaleable Test 
Platform (STP) as below:


commit f0573facbbbf14798cc5b7d4653a5e46b4b95fa5
Author: robbiew 
Date:   Wed Apr 28 19:21:39 2004 +

Added tool for analyzing failures from LTP runs on the OSDL's 
Scaleable Test Platform (STP)


2, And go through the contents of the script STPfailure_report.pl and it 
mainly needs to access http://khack.osdl.org to retrieve ltp test 
results run on OSDL's Scaleable Test Platform (STP) and print the 
reports, and now the website http://khack.osdl.org not accessible.


So we don't need to add so many new recipes for dependencies for this 
script STPfailure_report.pl.


Sorry for noise, please ignore it.

And will reorganize the logic to resend another patch not deploy this 
script to our system to avoid confusing about this script fails to run.


Thanks,
Grace



Alex


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

Re: [OE-core] [PATCH v2] groff: not ship /usr/bin/glilypond

[Yu, Mingli]

Any update?

Thanks,


On 2016年09月06日 10:39, mingli...@windriver.com wrote:

From: Mingli Yu <mingli...@windriver.com>

Not ship /usr/bin/glilypond and related files such
as man file /usr/share/man/man1/glilypond.1 and other
three files related to glilypond under
/usr/lib/groff/glilypond in embedded system, it is because:

- Remove the confusion about glilypond fails to run
   because it lacks dependency on File::HomeDir perl
   module

- We don't often have need for sheet music conversion
   in groff in embedded or IoT devices (glilypond
   transforms sheet music written in the lilypond language
   into the groff language using the .PSPIC request, such
   that groff can transform it into a format that can be
   displayed directly).

Signed-off-by: Mingli Yu <mingli...@windriver.com>
---
  meta/recipes-extended/groff/groff_1.22.3.bb | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-extended/groff/groff_1.22.3.bb 
b/meta/recipes-extended/groff/groff_1.22.3.bb
index af5acbe..dd241f3 100644
--- a/meta/recipes-extended/groff/groff_1.22.3.bb
+++ b/meta/recipes-extended/groff/groff_1.22.3.bb
@@ -62,6 +62,11 @@ do_install_append() {
if [ -f ${SPECIAL_AWK} ]; then
sed -i -e 's:#!.*awk:#! ${USRBINPATH}/awk:' ${SPECIAL_AWK}
fi
+
+   # not ship /usr/bin/glilypond and its releated files in embedded target 
system
+   rm -rf ${D}${bindir}/glilypond
+   rm -rf ${D}${libdir}/groff/glilypond
+   rm -rf ${D}${mandir}/man1/glilypond*
  }

  do_install_append_class-native() {


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

Re: [OE-core] [PATCH 1/2] perl: fix CVE-2016-6185

[Yu, Mingli]

On 2016年09月21日 17:21, Burton, Ross wrote:


On 21 September 2016 at 06:38, <mingli...@windriver.com
<mailto:mingli...@windriver.com>> wrote:

From: Mingli Yu <mingli...@windriver.com
<mailto:mingli...@windriver.com>>

Backport patch to fix CVE-2016-6185 from perl upstream:
http://perl5.git.perl.org/perl.git/commitdiff/08e3451d7
<http://perl5.git.perl.org/perl.git/commitdiff/08e3451d7>

Signed-off-by: Mingli Yu <mingli...@windriver.com
<mailto:mingli...@windriver.com>>


Can you please add CVE: tags to the patches alongside the
upstream-status and s-o-b, so that the automated CVE tooling can work?


Will resend the v2 patch to add CVE tags.

Thanks,
Mingli



Ross

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

Re: [OE-core] [PATCH] openssh: fix potential signed overflow to enable compilation with -ftrapv

[Yu, Mingli]

ping

Thanks,

On 2016年08月26日 09:57, Yuanjie Huang wrote:

From: Yuanjie Huang 

Pointer arithmatic results in implementation defined signed integer
type, so that 's - src' in strlcpy and others may trigger signed overflow.
In case of compilation by gcc or clang with -ftrapv option, the overflow
would lead to program abort.

Upstream-status: Submitted [https://bugzilla.mindrot.org/show_bug.cgi?id=2608]

Signed-off-by: Yuanjie Huang 
---
  ...ial-signed-overflow-in-pointer-arithmatic.patch | 99 ++
  meta/recipes-connectivity/openssh/openssh_7.3p1.bb |  1 +
  2 files changed, 100 insertions(+)
  create mode 100644 
meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch

diff --git 
a/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch
 
b/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch
new file mode 100644
index 000..df64a14
--- /dev/null
+++ 
b/meta/recipes-connectivity/openssh/openssh/fix-potential-signed-overflow-in-pointer-arithmatic.patch
@@ -0,0 +1,99 @@
+From 3328e98bcbf2930cd7eea3e6c92ad5dcbdf4794f Mon Sep 17 00:00:00 2001
+From: Yuanjie Huang 
+Date: Wed, 24 Aug 2016 03:15:43 +
+Subject: [PATCH] Fix potential signed overflow in pointer arithmatic
+
+Pointer arithmatic results in implementation defined signed integer
+type, so that 's - src' in strlcpy and others may trigger signed overflow.
+In case of compilation by gcc or clang with -ftrapv option, the overflow
+would lead to program abort.
+
+Upstream-status: Submitted [http://bugzilla.mindrot.org/show_bug.cgi?id=2608]
+
+Signed-off-by: Yuanjie Huang 
+---
+ openbsd-compat/strlcat.c | 8 ++--
+ openbsd-compat/strlcpy.c | 8 ++--
+ openbsd-compat/strnlen.c | 8 ++--
+ 3 files changed, 18 insertions(+), 6 deletions(-)
+
+diff --git a/openbsd-compat/strlcat.c b/openbsd-compat/strlcat.c
+index bcc1b61..e758ebf 100644
+--- a/openbsd-compat/strlcat.c
 b/openbsd-compat/strlcat.c
+@@ -23,6 +23,7 @@
+
+ #include 
+ #include 
++#include 
+
+ /*
+  * Appends src to string dst of size siz (unlike strncat, siz is the
+@@ -55,8 +56,11 @@ strlcat(char *dst, const char *src, size_t siz)
+   s++;
+   }
+   *d = '\0';
+-
+-  return(dlen + (s - src));   /* count does not include NUL */
++/*
++   * Cast pointers to unsigned type before calculation, to avoid signed
++   * overflow when the string ends where the MSB has changed.
++   */
++  return (dlen + ((uintptr_t)s - (uintptr_t)src));/* count does 
not include NUL */
+ }
+
+ #endif /* !HAVE_STRLCAT */
+diff --git a/openbsd-compat/strlcpy.c b/openbsd-compat/strlcpy.c
+index b4b1b60..b06f374 100644
+--- a/openbsd-compat/strlcpy.c
 b/openbsd-compat/strlcpy.c
+@@ -23,6 +23,7 @@
+
+ #include 
+ #include 
++#include 
+
+ /*
+  * Copy src to string dst of size siz.  At most siz-1 characters
+@@ -51,8 +52,11 @@ strlcpy(char *dst, const char *src, size_t siz)
+   while (*s++)
+   ;
+   }
+-
+-  return(s - src - 1);/* count does not include NUL */
++/*
++   * Cast pointers to unsigned type before calculation, to avoid signed
++   * overflow when the string ends where the MSB has changed.
++   */
++  return ((uintptr_t)s - (uintptr_t)src - 1); /* count does not 
include NUL */
+ }
+
+ #endif /* !HAVE_STRLCPY */
+diff --git a/openbsd-compat/strnlen.c b/openbsd-compat/strnlen.c
+index 93d5155..9b8de5d 100644
+--- a/openbsd-compat/strnlen.c
 b/openbsd-compat/strnlen.c
+@@ -23,6 +23,7 @@
+ #include 
+
+ #include 
++#include 
+
+ size_t
+ strnlen(const char *str, size_t maxlen)
+@@ -31,7 +32,10 @@ strnlen(const char *str, size_t maxlen)
+
+   for (cp = str; maxlen != 0 && *cp != '\0'; cp++, maxlen--)
+   ;
+-
+-  return (size_t)(cp - str);
++/*
++   * Cast pointers to unsigned type before calculation, to avoid signed
++   * overflow when the string ends where the MSB has changed.
++   */
++  return (size_t)((uintptr_t)cp - (uintptr_t)str);
+ }
+ #endif
+--
+1.9.1
+
diff --git a/meta/recipes-connectivity/openssh/openssh_7.3p1.bb 
b/meta/recipes-connectivity/openssh/openssh_7.3p1.bb
index b319726..039b0ff 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.3p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.3p1.bb
@@ -24,6 +24,7 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
 file://run-ptest \
 file://openssh-7.1p1-conditional-compile-des-in-cipher.patch \
 file://openssh-7.1p1-conditional-compile-des-in-pkcs11.patch \
+   file://fix-potential-signed-overflow-in-pointer-arithmatic.patch \
 "

  PAM_SRC_URI = "file://sshd"


--

Re: [OE-core] [PATCH 0/4] groff: add file-homedir-perl to RDEPENDS

[Yu, Mingli]

On 2016年08月26日 16:55, Burton, Ross wrote:


On 26 August 2016 at 03:25, > wrote:

The series add file-homedir-perl to RDEPENDS for groff as
glilypond rdepends on File/HomeDir.pm provided by file-homedir-perl


Isn't lilypond the music score layout tool?


glilypond which is provided by groff transforms sheet music written in 
the lilypond language into the groff language using the .PSPIC request, 
such that groff can transform it into a format that can be displayed 
directly.


 This seems very

specialist.  I suggest adding the new recipes to meta-perl, and then if
someone does want to use it then the requirements are available.

Unless you're only hitting this because of testing, in which case I'd
suggest skipping this test.


The command glilypond needs File::HomeDir perl module which is provided 
by file-homedir-perl


Thanks,
Grace



Ross

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

Re: [OE-core] Review request 0/21: ltp: add libwww-perl-perl to RDEPENDS

[Yu, Mingli]

On 2016年08月29日 10:16, mingli...@windriver.com wrote:

The series add libwww-perl-perl to RDEPENDS for ltp as
STPfailure_report.pl provided by ltp depends
on LWP/Simple.pm which is provided by libwww-perl-perl

Add new recipe libwww-perl-perl as lftp rdepends
on libwww-perl-perl


Sorry for the typo, s/lftp/ltp/

Thanks,
Grace



Add encode-locale-perl recipe as libwww-perl-perl
rdepends on encode-locale-perl

Add new recipe file-listing-perl as libwww-perl-perl
rdepends on file-listing-perl

Add new recipe html-parser-perl as libwww-perl-perl
rdepends on html-parser-perl

Add new recipe http-cookies-perl as libwww-perl-perl
rdepends on http-cookies-perl

Add new recipe http-daemon-perl as libwww-perl-perl
rdepends on http-daemon-perl

Add new recipe http-date-perl as libwww-perl-perl
rdepends on http-date-perl

Add new recipe http-message-perl as libwww-perl-perl
rdepends on http-message-perl

Add new recipe http-negotiate-perl as libwww-perl-perl
rdepends on http-negotiate-perl

Add new recipe lwp-mediatypes-perl as libwww-perl-perl
rdepends on lwp-mediatypes-perl

Add new recipe net-http-perl as libwww-perl-perl
rdepends on net-http-perl

Add new recipe uri-perl as libwww-perl-perl
rdepends on uri-perl

Add new recipe www-robotrules-perl as libwww-perl-perl
rdepends on www-robotrules-perl

Add new recipe io-html-perl as http-message-perl
rdepends on io-html-perl

Add new recipe io-compress-perl as net-http-perl
rdepends on io-compress-perl

Add new recipe io-socket-ssl-perl as net-http-perl
rdepends on io-socket-ssl-perl

Add new recipe html-tagset-perl as html-parser-perl
rdepends on html-tagset-perl

Add new recipe compress-raw-bzip2-perl as io-compress-perl
rdepends on compress-raw-bzip2-perl

Add new recipe compress-raw-zlib-perl as io-compress-perl
rdepends on compress-raw-zlib-perl

Add new recipe net-ssleay-perl as io-socket-ssl-perl
rdepends on net-ssleay-perl


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

Re: [OE-core] [PATCH] gpgme: add GPGME_STATUS_KEY_CONSIDERED

[Yu, Mingli]

On 2016年12月21日 20:25, Alexander Kanavin wrote:

On 12/21/2016 01:14 PM, Burton, Ross wrote:


https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=315fb73d4a774e2c699ac1804f5377559b4d0027






Can you explain *why* we should cherry pick a patch from upstream?


Because someone didn't check RRS, which would suggest an update to gpgme
1.8.0 should be done instead.

http://recipes.yoctoproject.org/rrs/recipedetail/834/



Thanks Alex!
Actually I ever tried to upgrade gpgme to 1.8.0 before send out this 
patch, but there comes other ptest failed issues for python-pygpgme 
which not exist on current gpgme 1.6.0 if we simply update gpgme to 1.8.0.


Anyway I prefer to wait for more update for python-pygpgme from 
https://pagure.io/pygpgme/commits/master before we move forward to gpgme 
1.8.0.


Thanks,
Mingli



Alex



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

Re: [OE-core] [PATCH] gpgme: add GPGME_STATUS_KEY_CONSIDERED

[Yu, Mingli]

On 2016年12月21日 19:14, Burton, Ross wrote:


On 21 December 2016 at 08:19, <mingli...@windriver.com
<mailto:mingli...@windriver.com>> wrote:

From: Mingli Yu <mingli...@windriver.com
<mailto:mingli...@windriver.com>>

* src/gpgme.h.in <http://gpgme.h.in> (GPGME_STATUS_KEY_CONSIDERED): New.
* src/status-table.c (KEY_CONSIDERED): New.
* src/op-support.c (_gpgme_parse_inv_recp): Add argc KC_FPR and
   KC_FLAGS.  Use calloc.
   (_gpgme_parse_key_considered): New.
* src/sign.c (op_data_t): Add fields KC_FPR and KC_FLAGS.
   (release_op_data): Free KC_FPR.
   (_gpgme_sign_status_handler): Handle STATUS_KEY_CONSIDERED.
* src/encrypt.c (op_data_t): Add fields KC_FPR and KC_FLAGS.
   (release_op_data): Free KC_FPR.
   (_gpgme_encrypt_status_handler): Handle STATUS_KEY_CONSIDERED.

Reference:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=315fb73d4a774e2c699ac1804f5377559b4d0027

<https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=315fb73d4a774e2c699ac1804f5377559b4d0027>


Can you explain *why* we should cherry pick a patch from upstream?


Thanks Ross!
The reason why I cherry pick this patch as there are three failed ptest 
cases as below for python-pygpgme which depends on gpgme.

FAIL: test_edit_ownertrust (tests.test_editkey.EditKeyTestCase)
FAIL: test_edit_quit (tests.test_editkey.EditKeyTestCase)
FAIL: test_edit_sign (tests.test_editkey.EditKeyTestCase)

And also found the solution from 
https://pagure.io/pygpgme/c/f14699792622715c9cec372400f9dc38f1122f63?branch=master 
to fix the failed ptest cases for python-pygpgme, and this solution for 
python-pygpgme also needs we update accordingly for gpgme.


Thanks,
Mingli



Ross

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

Re: [OE-core] [PATCH] glibc/gcc/libgcc-initial: Reimplement "deltask do_build"

[Yu, Mingli]

Please ignore this patch as the indentation is TAB, will send V2 to use 
four space as indentation.


Thanks,
Mingli

On 2017年11月21日 16:00, mingli...@windriver.com wrote:

From: Mingli Yu <mingli...@windriver.com>

Previously, "deltask do_build" can result in the
dependency of do_build lost and can trigger a
race condition error as below when do_rm_work
is enabled.
=
NOTE: recipe glibc-initial-2.26-r0: task do_fetch: Failed
ERROR: glibc-initial-2.26-r0 do_fetch: Function failed: extend_recipe_sysroot
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:extend_recipe_sysroot(d)
  0003:
File: '$Prj/layers/oe-core/meta/classes/staging.bbclass', lineno: 410, 
function: extend_recipe_sysroot
  0406:manifests = {}
  0407:# All files that we're going to be installing, to find conflicts.
  0408:fileset = {}
  0409:
  *** 0410:for f in os.listdir(depdir):
  0411:if not f.endswith(".complete"):
  0412:continue
  0413:f = depdir + "/" + f
  0414:if os.path.islink(f) and not os.path.exists(f):
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'$Prj/build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/glibc-initial/2.26-r0/recipe-sysroot-native/installeddeps'
=

Rewrite the implementation of "deltask do_build" to save
the dependency before deleting do_build task to avoid the
race condition.

[YOCTO #12365]

Signed-off-by: Mingli Yu <mingli...@windriver.com>
---
  meta/recipes-core/glibc/glibc-initial.inc   | 6 +-
  meta/recipes-devtools/gcc/gcc-cross-initial.inc | 6 +-
  meta/recipes-devtools/gcc/libgcc-initial.inc| 6 +-
  3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-initial.inc 
b/meta/recipes-core/glibc/glibc-initial.inc
index b86e2fb2db..4390b6dfca 100644
--- a/meta/recipes-core/glibc/glibc-initial.inc
+++ b/meta/recipes-core/glibc/glibc-initial.inc
@@ -54,4 +54,8 @@ do_siteconfig () {
  inherit nopackages

  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/gcc-cross-initial.inc 
b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
index 892b1dbf2f..6c0b2eff86 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
@@ -86,4 +86,8 @@ COMPILERINITIAL = "-initial"


  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/libgcc-initial.inc 
b/meta/recipes-devtools/gcc/libgcc-initial.inc
index 950ad861e7..cef8257052 100644
--- a/meta/recipes-devtools/gcc/libgcc-initial.inc
+++ b/meta/recipes-devtools/gcc/libgcc-initial.inc
@@ -17,4 +17,8 @@ COMPILERINITIAL = "-initial"
  inherit nopackages

  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}


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

Re: [OE-core] [PATCH] glibc/gcc/libgcc-initial: Reimplement "deltask do_build"

[Yu, Mingli]

Ping.

Thanks,
Mingli

On 2017年11月21日 16:27, mingli...@windriver.com wrote:

From: Mingli Yu <mingli...@windriver.com>

Previously, "deltask do_build" can result in the
dependency of do_build lost and can trigger a
race condition error as below when do_rm_work
is enabled.
=
NOTE: recipe glibc-initial-2.26-r0: task do_fetch: Failed
ERROR: glibc-initial-2.26-r0 do_fetch: Function failed: extend_recipe_sysroot
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:extend_recipe_sysroot(d)
  0003:
File: '$Prj/layers/oe-core/meta/classes/staging.bbclass', lineno: 410, 
function: extend_recipe_sysroot
  0406:manifests = {}
  0407:# All files that we're going to be installing, to find conflicts.
  0408:fileset = {}
  0409:
  *** 0410:for f in os.listdir(depdir):
  0411:if not f.endswith(".complete"):
  0412:continue
  0413:f = depdir + "/" + f
  0414:if os.path.islink(f) and not os.path.exists(f):
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'$Prj/build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/glibc-initial/2.26-r0/recipe-sysroot-native/installeddeps'
=

Rewrite the implementation of "deltask do_build" to save
the dependency before deleting do_build task to avoid the
race condition.

[YOCTO #12365]

Signed-off-by: Mingli Yu <mingli...@windriver.com>
---
  meta/recipes-core/glibc/glibc-initial.inc   | 6 +-
  meta/recipes-devtools/gcc/gcc-cross-initial.inc | 6 +-
  meta/recipes-devtools/gcc/libgcc-initial.inc| 6 +-
  3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-initial.inc 
b/meta/recipes-core/glibc/glibc-initial.inc
index b86e2fb2db..0dc32092a9 100644
--- a/meta/recipes-core/glibc/glibc-initial.inc
+++ b/meta/recipes-core/glibc/glibc-initial.inc
@@ -54,4 +54,8 @@ do_siteconfig () {
  inherit nopackages

  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+if bb.data.inherits_class('rm_work', d):
+bb.build.exec_func("inject_rm_work", d)
+bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/gcc-cross-initial.inc 
b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
index 892b1dbf2f..55e22f62d3 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
@@ -86,4 +86,8 @@ COMPILERINITIAL = "-initial"


  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+if bb.data.inherits_class('rm_work', d):
+bb.build.exec_func("inject_rm_work", d)
+bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/libgcc-initial.inc 
b/meta/recipes-devtools/gcc/libgcc-initial.inc
index 950ad861e7..4c45b9a801 100644
--- a/meta/recipes-devtools/gcc/libgcc-initial.inc
+++ b/meta/recipes-devtools/gcc/libgcc-initial.inc
@@ -17,4 +17,8 @@ COMPILERINITIAL = "-initial"
  inherit nopackages

  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+if bb.data.inherits_class('rm_work', d):
+bb.build.exec_func("inject_rm_work", d)
+bb.build.deltask('do_build', d)
+}


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

Re: [OE-core] [PATCH] boost: add contract lib

[Yu, Mingli]

Please ignore this patch.

Thanks,

On 2018年05月11日 11:34, mingli...@windriver.com wrote:

From: Mingli Yu <mingli...@windriver.com>

Add the contract lib

Signed-off-by: Mingli Yu <mingli...@windriver.com>
---
  meta/recipes-support/boost/boost.inc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index b447897a0c..6984bee777 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -9,6 +9,7 @@ BOOST_LIBS = "\
atomic \
chrono \
container \
+   contract \
date_time \
exception \
filesystem \


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

Re: [OE-core] [PATCH] boost: add contract lib

[Yu, Mingli]

On 2018年05月16日 12:37, Randy MacLeod wrote:

On 2018-05-11 02:23 AM, mingli...@windriver.com wrote:

From: Mingli Yu <mingli...@windriver.com>

Add the contract lib which implements contract
programming (a.k.a., Design by Contract or DbC) [1]
for the C++ programming language.


Please clean up the long log.
You should write something like:

Add the contract lib which implements contract programming
(a.k.a., Design by Contract) for the C++ programming language.

I don't know what the [1] was about.
Ah, it's a reference from this documentation:
   https://www.boost.org/doc/libs/develop/libs/contract/doc/html/index.html

For anyone reading, but not following links:

[1] Design by Contract (DbC) is a registered trademark of the Eiffel
Software company and it was first introduced by the Eiffel programming
language (see [Meyer97]).


Good catch!
Thanks Randy! I will update the commit message altogether with some 
other changes next time as it has been already merged.


Thanks,




../Randy



Signed-off-by: Mingli Yu <mingli...@windriver.com>
---
  meta/recipes-support/boost/boost.inc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/boost/boost.inc
b/meta/recipes-support/boost/boost.inc
index b447897a0c..6984bee777 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -9,6 +9,7 @@ BOOST_LIBS = "\
  atomic \
  chrono \
  container \
+contract \
  date_time \
  exception \
  filesystem \





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

Re: [OE-core] [PATCH V2] boost: Improve reproducibility

[Yu, Mingli]

On 2018年06月17日 22:04, Khem Raj wrote:



On Sun, Jun 17, 2018 at 2:17 AM Richard Purdie
mailto:richard.pur...@linuxfoundation.org>> wrote:

On Fri, 2018-06-15 at 16:35 +0800, mingli...@windriver.com
 wrote:
 > From: Mingli Yu mailto:mingli...@windriver.com>>
 >
 > Set .file section explicitly for .S files to avoid
 > the linker introduces the host path in symbols for
 > object files whose source file is .S
 > Otherwise, there is a host path in the symbols as
 > below:
 > $ readelf --wide --symbols /my-build/boost/1.67.0-
 > r0/boost_1_67_0/x86_64-poky-
 > linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38e
 > d/libboost_context.so.1.67.0
 > 42:  0 FILE LOCAL DEFAULT ABS /my-build/boost/1.67.0-
 > r0/boost_1_67_0/x86_64-poky-
 > linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38e
 > d/asm/make_x86_64_sysv_elf_gas.o
 >
 > [YOCTO #12708]
 >
 > Signed-off-by: Mingli Yu mailto:mingli...@windriver.com>>
 >
Thanks for working through this, the final result is a much better fix!


If we add this directive to all the .S files there
Then it can be up streamed too


Yes, I did try to send the related fix to upstream.
Thanks Khem's help!

Thanks,





Cheers,

Richard


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

Re: [OE-core] [PATCH] boost: Improve reproducibility

[Yu, Mingli]

On 2018年06月15日 14:54, Alexander Kanavin wrote:

Thanks! Mingli, can you try this please?


Sure,



Alex

2018-06-15 9:44 GMT+03:00 Khem Raj :



On 6/1/18 12:34 PM, Alexander Kanavin wrote:


On 06/01/2018 09:33 PM, Khem Raj wrote:


The .s file is not generated and it does not contain any .file
directives. The .o file also does not contain the path. It appears in
the final .so library at linking stage.



Can you share the linker cmdline ?



https://pastebin.com/WK9GVDfj

Note that of the three assembly-generated object files, only the path to
the first shows up in the .so - because of assembly labels I believe.



Thanks for sharing this. If there is a no file directive in an object file
then linker will use whatever is specified on linker cmdline so thats what
we see, We should define FILE symbol explicitly for .S files here, for C/C++
files compiler does that automatically.

Other files dont make a claim in final symbol table since this one file
alone has cross referencing to symbols from other objects.

Something like this will help


Thanks Khem very much!

Have set .file section in .S file as you suggested, it works.

Thanks,



Index: boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S
===
--- boost_1_67_0.orig/libs/context/src/asm/make_i386_sysv_elf_gas.S
+++ boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S
@@ -23,7 +23,7 @@
   *
--
*
   *  *

/
-
+.file "make_i386_sysv_elf_gas.S"
  .text
  .globl make_fcontext
  .align 2
Index: boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
===
--- boost_1_67_0.orig/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
+++ boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
@@ -23,7 +23,7 @@
   *
--
*
   *  *

/
-
+.file "make_x86_64_sysv_elf_gas.S"
  .text
  .globl make_fcontext
  .type make_fcontext,@function



Alex


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



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

Re: [OE-core] [PATCH] ltp: set -fomit-frame-pointer explicitly

[Yu, Mingli]

On 2018年06月15日 03:20, Andre McCurdy wrote:

On Thu, Jun 14, 2018 at 9:38 AM, Khem Raj  wrote:

On 6/14/18 2:35 AM, mingli...@windriver.com wrote:

From: Mingli Yu 

When build ltp with -fno-omit-frame-pointer,
it will trigger below error:
| cve-2015-3290.c: In function 'child_thread':
| cve-2015-3290.c:416:1: error: bp cannot be used in asm here

And there is also some comment as below in the source
file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
* Build with -O2.  Don't use -fno-omit-frame-pointer.

So explicitly set -fomit-frame-pointer for compiler
to fix the above build error.

Signed-off-by: Mingli Yu 
---
  meta/recipes-extended/ltp/ltp_20180515.bb | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb 
b/meta/recipes-extended/ltp/ltp_20180515.bb
index b07c1b9..5ec25ed 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -19,6 +19,10 @@ LIC_FILES_CHKSUM = "\
  DEPENDS = "attr libaio libcap acl openssl zip-native"
  DEPENDS_append_libc-musl = " fts "
  EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
+
+# -fomit-frame-pointer to handle cases where optimisation is set to -O0 or 
frame
+# pointers have been enabled by -fno-omit-frame-pointer earlier in CFLAGS, etc.
+CFLAGS_append = " ${@bb.utils.contains('SELECTED_OPTIMIZATION', 
'-fno-omit-frame-pointer', '-fomit-frame-pointer', '', d)}"


This doesn't cover all cases - there may be times when the compiler
chooses to enable frame pointers without being called with
-fno-omit-frame-pointer.

You could make the append conditional on x86 though (based on the
error message, it's the x86 frame pointer register which is being used
by inline assembler).


Thanks Khem and Andre!

Considering it's x86-64 specific(x86 actually not affected), I will 
update the logic unconditionally in V2 as below only for x86-64 to cover 
some cases when the compiler enables frame pointers without being called 
with -fno-omit-frame-pointer.


CFLAGS_append_x86-64 = " -fomit-frame-pointer"

Thanks,




may be just append it unconditionally, what do we lose ?
CFLAGS += "-fomit-frame-pointer"


  CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
  CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
  SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"





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


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

Re: [OE-core] [PATCH V2] ltp: set -fomit-frame-pointer explicitly for x86-64

[Yu, Mingli]

On 2018年06月15日 17:16, Richard Purdie wrote:

On Fri, 2018-06-15 at 17:01 +0800, mingli...@windriver.com wrote:

From: Mingli Yu 

When build ltp with -fno-omit-frame-pointer on
x86-64, it will trigger below error:

cve-2015-3290.c: In function 'child_thread':
cve-2015-3290.c:416:1: error: bp cannot be used in asm here


And there is also some comment as below in the source
file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
* Build with -O2.  Don't use -fno-omit-frame-pointer.

So explicitly set -fomit-frame-pointer on x86-64 for
compiler to fix the above build error.

Signed-off-by: Mingli Yu 
---
  meta/recipes-extended/ltp/ltp_20180515.bb | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb
b/meta/recipes-extended/ltp/ltp_20180515.bb
index b07c1b9..7fd8565 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -19,6 +19,11 @@ LIC_FILES_CHKSUM = "\
  DEPENDS = "attr libaio libcap acl openssl zip-native"
  DEPENDS_append_libc-musl = " fts "
  EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
+
+# set -fomit-frame-pointer to handle cases where optimisation is set
to -O0 or frame
+# pointers have been enabled by -fno-omit-frame-pointer earlier in
CFLAGS, etc.
+CFLAGS_append_x86-64 = " -fomit-frame-pointer"
+
  CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
  CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
  SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"


Can you extend the comment to include:

"since ltp contains x86-64 assembler which uses the frame-pointer
register"

so that the comment doesn't just say what you're doing but why its
necessary only for x86-64


Thanks Richard!

It makes sense, will send out V3 to explain more why it's only necessary 
only for x86-64.


Thanks,



Cheers,

Richard




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

Re: [OE-core] [PATCH] boost: add ptest support

[Yu, Mingli]

Ping.

Thanks,


On 2018年05月18日 16:55, mingli...@windriver.com wrote:

From: Mingli Yu 

* Add a patch to remove rpath when compiling tests.

* The rules for tests don't work in cross-compiling,
   they try to run the executable after compiling and
   linking the test program, so add a patch to hack
   the rules, and add the running logic in run-ptest

* There are 2000+ test cases for 26 added libs, I'm
   not able to make all of them work for now and I think
   ptest is not necessary to cover all of them, so add
   a patch to remove some of the tests, which include:

   - those require extra dependencies
   - those require specific target hardware
   - those require input data or config files
   - those compile fail with unknown reason
   - those require command parameters/options when running

Signed-off-by: Jackie Huang 
Signed-off-by: Mingli Yu 
---
  meta/recipes-support/boost/boost.inc   |   66 +
  .../boost/boost/0001-test-remove-some-tests.patch  | 1728 
  .../boost/boost/boost-remove-rpath.patch   |   28 +
  .../boost-testing-hack-the-rules-for-ptest.patch   |   53 +
  meta/recipes-support/boost/boost/run-ptest |   41 +
  5 files changed, 1916 insertions(+)
  create mode 100644 
meta/recipes-support/boost/boost/0001-test-remove-some-tests.patch
  create mode 100644 meta/recipes-support/boost/boost/boost-remove-rpath.patch
  create mode 100644 
meta/recipes-support/boost/boost/boost-testing-hack-the-rules-for-ptest.patch
  create mode 100644 meta/recipes-support/boost/boost/run-ptest

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 6984bee777..cf9a5d41e2 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -69,6 +69,27 @@ python __anonymous () {
  d.setVar("BJAM_EXTRA", " ".join(extras))
  }

+inherit ptest
+
+SRC_URI_append = " \
+file://run-ptest \
+file://boost-remove-rpath.patch \
+file://boost-testing-hack-the-rules-for-ptest.patch \
+file://0001-test-remove-some-tests.patch \
+"
+# Required by some of the tests
+FILES_${PN}-ptest += " \
+   ${libdir}/libboost_regex_extra.so.* \
+   ${libdir}/libboost_regex_recursive.so.* \
+   ${libdir}/liba.so.* \
+   ${libdir}/libsingle_instance_lib2.so.* \
+   ${libdir}/libsingle_instance_lib1.so.* \
+   ${libdir}/libdisable-lib_*.so.* \
+   ${libdir}/libdll_*.so.* \
+   ${libdir}/libthrow_test.so.* \
+"
+RDEPENDS_${PN}-ptest = "coreutils"
+
  # Override the contents of specific packages
  FILES_${PN}-graph_parallel = "${libdir}/libboost_graph_parallel.so.*"
  FILES_${PN}-locale = "${libdir}/libboost_locale.so.*"
@@ -181,6 +202,51 @@ do_compile() {
--debug-configuration
  }

+do_compile_ptest() {
+   for lib in ${BOOST_LIBS}; do
+   # ignore python3 since there is no such
+   # sub-dir in libs
+   [ ${lib} = "python3" ] && continue
+
+   cd ${S}/libs/${lib}/test
+   [ -f build/Jamfile.v2 ] && cd build
+   bjam ${BJAM_OPTS} --prefix=${prefix} \
+   --exec-prefix=${exec_prefix} \
+   --libdir=${libdir} \
+   --includedir=${includedir}
+   done
+}
+
+do_install_ptest() {
+   build_bin="${S}/${TARGET_SYS}/boost/bin.v2"
+
+   for lib in ${BOOST_LIBS}; do
+   # ignore python3 since there is no such
+   # sub-dir in libs
+   [ "${lib}" = "python3" ] && continue
+
+   install -d ${D}/${PTEST_PATH}/${lib}
+   lib_test_dir="${build_bin}/libs/${lib}/test"
+   for testdir in `ls -d ${lib_test_dir}/*.test 
${lib_test_dir}/build/*.test 2>/dev/null`; do
+   testname=`basename ${testdir%.test}`
+   testfile=`find ${testdir} -name ${testname}`
+   if [ -n "${testfile}" -a -f "${testfile}" ]; then
+   install -m 0755 ${testfile} 
${D}${PTEST_PATH}/${lib}
+   fi
+   done
+   done
+
+   extra_ptest_libs="libboost_regex_extra.so* libboost_regex_recursive.so.* 
liba.so.* libsingle_instance_lib2.so.* libsingle_instance_lib1.so.* libdisable-lib_*.so.* 
libdll_*.so* libthrow_test.so*"
+   for lib in ${extra_ptest_libs}; do
+   f=`find ${build_bin}/libs -name ${lib}`
+   if [ -n "${f}" ]; then
+   install -m 0755 ${f} ${D}${libdir}
+   fi
+   done
+
+   sed -i 's/@BOOST_LIBS@/${BOOST_LIBS}/' ${D}${PTEST_PATH}/run-ptest
+}
+
  do_install() {
bjam ${BJAM_OPTS} \
--libdir=${D}${libdir} \
diff --git a/meta/recipes-support/boost/boost/0001-test-remove-some-tests.patch 
b/meta/recipes-support/boost/boost/0001-test-remove-some-tests.patch
new file mode 100644
index 00..7d2f916822
--- /dev/null
+++ 

Re: [OE-core] [PATCH] boost: Improve reproducibility

[Yu, Mingli]

On 2018年05月31日 21:13, Richard Purdie wrote:

On Wed, 2018-05-30 at 23:20 -0700, mingli...@windriver.com wrote:

From: Mingli Yu 

boost_context includes some assembly source
files and will export the assembly object file
make_x86_64_sysv_elf_gas.o which contains host
path as below:
$ readelf --wide --symbols /my-build/boost/1.67.0-
r0/boost_1_67_0/x86_64-poky-
linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38e
d/libboost_context.so.1.67
42:  0 FILE LOCAL DEFAULT ABS /my-build/boost/1.67.0-
r0/boost_1_67_0/x86_64-poky-
linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38e
d/asm/make_x86_64_sysv_elf_gas.o

Enable stirp for boost_context to hidden the
symbols

[YOCTO #12708]

Signed-off-by: Mingli Yu 


This looks very unlikely to ever make it upstream. Rather than carrying
a patch to boost forever would we want to just strip the file in
question with a custom command?


Thanks very much Richard for your respond!
I did try to strip only file which in question, but not find out the 
solution and then turn to strip the context library.


Alex,
Do you have any suggestion?

Thanks,



Alternatively, can we stop this path being injected into the binary in
the first place?

Cheers,

Richard


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

Re: [OE-core] [PATCH] boost: Improve reproducibility

[Yu, Mingli]

On 2018年06月01日 13:08, Alexander Kanavin wrote:

2018-06-01 4:39 GMT+03:00 Yu, Mingli :


This looks very unlikely to ever make it upstream. Rather than carrying
a patch to boost forever would we want to just strip the file in
question with a custom command?



Thanks very much Richard for your respond!
I did try to strip only file which in question, but not find out the
solution and then turn to strip the context library.

Alex,
Do you have any suggestion?


Yes - as RP said, please investigate how the path gets into this
specific file (but not other files) in the first place, and whether we
can disable or make it not happen, rather than strip the path after
the fact.


Hi Alex,

Thanks for your respond!
I did investigate the path a lot before send out the patch, but didn't 
figure out why it introduce the path for make_x86_64_sysv_elf_gas.o 
whose source file is make_x86_64_sysv_elf_gas.S.


Anyway, I will try to dig more.

If you have any ideas, welcome to help provide some hint.

Thanks,




Alex


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

Re: [OE-core] [PATCH] boost: Improve reproducibility

[Yu, Mingli]

On 2018年06月01日 16:36, Alexander Kanavin wrote:

2018-06-01 8:38 GMT+03:00 Yu, Mingli :


I did investigate the path a lot before send out the patch, but didn't
figure out why it introduce the path for make_x86_64_sysv_elf_gas.o whose
source file is make_x86_64_sysv_elf_gas.S.

Anyway, I will try to dig more.

If you have any ideas, welcome to help provide some hint.


I'm not an expert in symbol tables and what goes into them, but I
strongly suspect the full path is introduced by linker because that .S
file has two assembly labels (trampoline, finish). The other two
assembly files have no such labels, and so their file paths are not
added to the .so. I'm also not sure why there needs to be a full path,


Thanks Alex very much for your comments!
I think the full path is introduced by linker and I'm also confused why 
other two assembly files' o file not introduced in the final .so.




as opposed to just the file name, as is the case for .c files (maybe
to avoid clashes with labels of the same name in different files?).


I'm also concerned about that maybe it's necessary to have the full path.

Thanks,




We should probably just strip that one specific .o file before it's
linked into the library. Or if there is a way to prevent the labels
from being written into the symbol table by the assembler, we can use
that too. Sadly boost has its own build system, so doing such custom
tweaks may be tricky.

Alex


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

Re: [OE-core] [PATCH] nfs-utils: fix build error under tests folder

[Yu, Mingli]

Ping.

Thanks,

On 2018年07月12日 16:46, mingli...@windriver.com wrote:

From: Mingli Yu 

* When enable the test as below in nfs-utils recipe,
   do_compile_append_class-target () {
 oe_runmake -C tests statdb_dump
 oe_runmake -C tests/nsm_client nsm_client
   }

   There comes some build error as:
   1,
   | make: *** No rule to make target '../support/nfs/libnfs.a', needed by 
'statdb_dump'.  Stop.
   | make: *** No rule to make target '../../support/nfs/libnfs.a', needed by 
'nsm_client'.  Stop.

   2,
   | ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | ../support/nsm/libnsm.a(file.o): In function `nsm_setup_pathnames':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:280: 
undefined reference to `generic_setup_basedir'
   | collect2: error: ld returned 1 exit status

* Redefine the reference path of libnfs.a to
  ../support/nfs/.libs/libnfs.a to fix the error 1 as
   above

* The function generic_make_pathname is introduced in
   nfs-utils 2.3.1
   Add the source file which defines function generic_make_pathname to
   libnsm_a_SOURCES of libnsm.a to fix the undefined reference
   error 2 as above

Signed-off-by: Mingli Yu 
---
  ...efile.am-update-the-path-of-libnfs.a.patch |  49 +++
  .../0001-fix-undefined-for-libnsm.a.patch | 293 ++
  .../nfs-utils/nfs-utils_2.3.1.bb  |   2 +
  3 files changed, 344 insertions(+)
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-fix-undefined-for-libnsm.a.patch

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
new file mode 100644
index 00..b756ef6c5a
--- /dev/null
+++ 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
@@ -0,0 +1,49 @@
+From fcece65d1b713eaeef41706898440302f8ce92d9 Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Thu, 12 Jul 2018 15:19:41 +0800
+Subject: [PATCH] Makefile.am: update the path of libnfs.a
+
+The libnfs.a is under ../support/nfs/.libs/ now,
+update the reference path accordingly to fix below
+build error:
+| make: *** No rule to make target '../support/nfs/libnfs.a', needed by 
'statdb_dump'.  Stop.
+
+| make: *** No rule to make target '../../support/nfs/libnfs.a', needed by 
'nsm_client'.  Stop.
+
+Upstream-Status: Pending
+
+Signed-off-by: Mingli Yu 
+---
+ tests/Makefile.am| 2 +-
+ tests/nsm_client/Makefile.am | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 1f96264..74aa629 100644
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -3,7 +3,7 @@
+ check_PROGRAMS = statdb_dump
+ statdb_dump_SOURCES = statdb_dump.c
+
+-statdb_dump_LDADD = ../support/nfs/libnfs.a \
++statdb_dump_LDADD = ../support/nfs/.libs/libnfs.a \
+   ../support/nsm/libnsm.a $(LIBCAP)
+
+ SUBDIRS = nsm_client
+diff --git a/tests/nsm_client/Makefile.am b/tests/nsm_client/Makefile.am
+index a8fc131..43db9c2 100644
+--- a/tests/nsm_client/Makefile.am
 b/tests/nsm_client/Makefile.am
+@@ -13,7 +13,7 @@ check_PROGRAMS   = nsm_client
+ nsm_client_SOURCES = $(GENFILES) nsm_client.c
+
+ BUILT_SOURCES = $(GENFILES)
+-nsm_client_LDADD = ../../support/nfs/libnfs.a \
++nsm_client_LDADD = ../../support/nfs/.libs/libnfs.a \
+  ../../support/nsm/libnsm.a $(LIBCAP) $(LIBTIRPC)
+
+ if CONFIG_RPCGEN
+--
+2.7.4
+
diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-fix-undefined-for-libnsm.a.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-fix-undefined-for-libnsm.a.patch
new file mode 100644
index 00..bb210dbd1b
--- /dev/null
+++ 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-fix-undefined-for-libnsm.a.patch
@@ -0,0 +1,293 @@
+From 7b945c3498b5f88640947c187460f8029a09751e Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Thu, 12 Jul 2018 14:57:53 +0800
+Subject: [PATCH] fix undefined function for libnsm.a
+
+The source file file.c of libnsm.a uses some function
+in ../support/misc/file.c, add ../support/misc/file.c
+to libnsm_a_SOURCES to fix build error:
+| ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
+| /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| 

Re: [OE-core] ✗ patchtest: failure for bluez5: Fix ptest hang

[Yu, Mingli]

Will resend V2 to update the typo from Upsteam-Status to Upstream-Status.

Thanks,

On 2018年08月24日 14:33, Patchwork wrote:

== Series Details ==

Series: bluez5: Fix ptest hang
Revision: 1
URL   : https://patchwork.openembedded.org/series/13703/
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 Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format]
   Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-connectivity/bluez5/bluez5/0001-test-gatt-Fix-hung-issue.patch
   Standard format  Upstream-Status: 
   Valid status Pending, Accepted, Backport, Denied, Inappropriate 
[reason], Submitted [where]



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe



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

Re: [OE-core] [PATCH 1/2] mdadm: fix usrmerge install path

[Yu, Mingli]

Ping.

Thanks,

On 2018年08月17日 14:27, mingli...@windriver.com wrote:

From: Mingli Yu 

Update /lib to $nonarch_base_libdir to fix
the below error when usrmerge enabled in
DISTRO_FEATURES.

ERROR: mdadm-4.0-r0 do_package_qa: QA Issue: mdadm package is not obeying 
usrmerge distro feature. /lib should be relocated to /usr. [usrmerge]

Signed-off-by: Mingli Yu 
---
  meta/recipes-extended/mdadm/mdadm_4.0.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/mdadm/mdadm_4.0.bb 
b/meta/recipes-extended/mdadm/mdadm_4.0.bb
index 226b974..2c4d88a 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.0.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.0.bb
@@ -42,7 +42,7 @@ CFLAGS_append_mipsarchn32 = ' -D__SANE_USERSPACE_TYPES__'

  do_compile() {
# Point to right sbindir
-   sed -i -e "s;BINDIR  = /sbin;BINDIR = $base_sbindir;" ${S}/Makefile
+   sed -i -e "s;BINDIR  = /sbin;BINDIR = $base_sbindir;" -e "s;UDEVDIR = 
/lib;UDEVDIR = $nonarch_base_libdir;" ${S}/Makefile
oe_runmake SYSROOT="${STAGING_DIR_TARGET}"
  }



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

Re: [OE-core] [PATCH] kexec-tools: fix for "Unhandled rela relocation: R_X86_64_PLT32" error

[Yu, Mingli]

Ping.

Thanks,

On 2018年09月03日 09:26, Yu, Mingli wrote:



On 2018年08月31日 22:07, Andrea Adami wrote:

On Fri, Aug 31, 2018 at 8:34 AM Yu, Mingli 
wrote:


Ping.


Hi,
FYI it is in master upstream as of  b9de21ef51a7 so you could just
upgrade the recipe.
Cheers
Andrea


Thanks Andrea! But the current kexec-tools version is already 2.0.17
which is the latest version.

Thanks,






On 2018年08月30日 16:36, mingli...@windriver.com wrote:

From: Mingli Yu 

In response to a change in binutils, commit b21ebf2fb4c
(x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
the linux kernel during the 4.16 development cycle and has
since been backported to earlier stable kernel series. The
change results in the failure message as below when rebooting
via kexec.
   # kexec -l /boot/bzImage --append="console=ttyS0,115200
root=/dev/sda1"
   Unhandled rela relocation: R_X86_64_PLT32

Fix this by replicating the change in kexec.

Signed-off-by: Mingli Yu 
---
   ...or-Unhandled-rela-relocation-R_X86_64_PLT.patch | 41
++
   meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb|  1 +
   2 files changed, 42 insertions(+)
   create mode 100644
meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch


diff --git
a/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch
b/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch

new file mode 100644
index 000..e0cced5
--- /dev/null
+++
b/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch

@@ -0,0 +1,41 @@
+From b9de21ef51a7ceab7122a707c188602eae22c4ee Mon Sep 17 00:00:00 2001
+From: Chris Clayton 
+Date: Mon, 20 Aug 2018 12:00:31 +0100
+Subject: [PATCH] kexec: fix for "Unhandled rela relocation:
R_X86_64_PLT32" error
+
+In response to a change in binutils, commit b21ebf2fb4c
+(x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
+the linux kernel during the 4.16 development cycle and has
+since been backported to earlier stable kernel series. The
+change results in the failure message in $SUBJECT when
+rebooting via kexec.
+
+Fix this by replicating the change in kexec.
+
+Upstream-Status:
Backport[https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=b9de21ef51a7ceab7122a707c188602eae22c4ee]

+
+Signed-off-by: Chris Clayton 
+Acked-by: Baoquan He 
+Tested-by: Bhupesh Sharma 
+Acked-by: Bhupesh Sharma 
+Signed-off-by: Simon Horman 
+Signed-off-by: Mingli Yu 
+---
+ kexec/arch/x86_64/kexec-elf-rel-x86_64.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
b/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
+index 7fdde73..db85b44 100644
+--- a/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
 b/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
+@@ -79,6 +79,7 @@ void machine_apply_elf_rel(struct mem_ehdr
*UNUSED(ehdr),
+ goto overflow;
+ break;
+ case R_X86_64_PC32:
++case R_X86_64_PLT32:
+ *(uint32_t *)location = value - address;
+ break;
+ default:
+--
+2.7.4
+
diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
b/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
index f4ec586..dd46901 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
@@ -18,6 +18,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz

file://0010-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch \
  file://kexec-x32.patch \
  file://0001-Disable-PIE-during-link.patch \
+
file://0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch
\
  "

   SRC_URI[md5sum] = "8e071ca473694a71e4ae60ed7ef6f377"


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



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

Re: [OE-core] [PATCH] kexec-tools: fix for "Unhandled rela relocation: R_X86_64_PLT32" error

[Yu, Mingli]

Ping.

On 2018年08月30日 16:36, mingli...@windriver.com wrote:

From: Mingli Yu 

In response to a change in binutils, commit b21ebf2fb4c
(x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
the linux kernel during the 4.16 development cycle and has
since been backported to earlier stable kernel series. The
change results in the failure message as below when rebooting
via kexec.
  # kexec -l /boot/bzImage --append="console=ttyS0,115200 root=/dev/sda1"
  Unhandled rela relocation: R_X86_64_PLT32

Fix this by replicating the change in kexec.

Signed-off-by: Mingli Yu 
---
  ...or-Unhandled-rela-relocation-R_X86_64_PLT.patch | 41 ++
  meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb|  1 +
  2 files changed, 42 insertions(+)
  create mode 100644 
meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch

diff --git 
a/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch
 
b/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch
new file mode 100644
index 000..e0cced5
--- /dev/null
+++ 
b/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch
@@ -0,0 +1,41 @@
+From b9de21ef51a7ceab7122a707c188602eae22c4ee Mon Sep 17 00:00:00 2001
+From: Chris Clayton 
+Date: Mon, 20 Aug 2018 12:00:31 +0100
+Subject: [PATCH] kexec: fix for "Unhandled rela relocation: R_X86_64_PLT32" 
error
+
+In response to a change in binutils, commit b21ebf2fb4c
+(x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
+the linux kernel during the 4.16 development cycle and has
+since been backported to earlier stable kernel series. The
+change results in the failure message in $SUBJECT when
+rebooting via kexec.
+
+Fix this by replicating the change in kexec.
+
+Upstream-Status: 
Backport[https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=b9de21ef51a7ceab7122a707c188602eae22c4ee]
+
+Signed-off-by: Chris Clayton 
+Acked-by: Baoquan He 
+Tested-by: Bhupesh Sharma 
+Acked-by: Bhupesh Sharma 
+Signed-off-by: Simon Horman 
+Signed-off-by: Mingli Yu 
+---
+ kexec/arch/x86_64/kexec-elf-rel-x86_64.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/kexec/arch/x86_64/kexec-elf-rel-x86_64.c 
b/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
+index 7fdde73..db85b44 100644
+--- a/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
 b/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
+@@ -79,6 +79,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr),
+   goto overflow;
+   break;
+   case R_X86_64_PC32:
++  case R_X86_64_PLT32:
+   *(uint32_t *)location = value - address;
+   break;
+   default:
+--
+2.7.4
+
diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb 
b/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
index f4ec586..dd46901 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
@@ -18,6 +18,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz
 file://0010-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch \
 file://kexec-x32.patch \
 file://0001-Disable-PIE-during-link.patch \
+   
file://0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch \
 "

  SRC_URI[md5sum] = "8e071ca473694a71e4ae60ed7ef6f377"


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

Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available

[Yu, Mingli]

On 2018年10月16日 20:05, Burton, Ross wrote:

On Tue, 16 Oct 2018 at 12:18, Burton, Ross  wrote:

OpenCV has a patch to "fix" (bodge) the Py2 build:

https://github.com/ros-perception/vision_opencv/pull/239

But this doesn't work for Py3.


This was just pushed:
https://github.com/ros-perception/vision_opencv/commit/b57fd5b


Thanks Ross!
I'm fine not add the the hack fix from boost side, but as I know there 
is another package camera-calibration-parsers which has the same problem 
as below apart from cv-bridge. BTW, there may some other package also 
has this kind of problem. This to say we need to fix the issue for the 
this kind of packages one by one.


meta-ros/recipes-ros/image-common/camera-calibration-parsers_1.11.13.bb:do_configure 
failed
| CMake Error at 
/$Prj/camera-calibration-parsers/1.11.13-r0/recipe-sysroot-native/usr/share/cmake-3.12/Modules/FindBoost.cmake:2048 
(message):

|   Unable to find the requested Boost libraries.
|
|   Boost version: 1.68.0
|
|   Boost include path:
|   /$Prj/camera-calibration-parsers/1.11.13-r0/recipe-sysroot/usr/include
|
|
|   Could not find the following Boost libraries:
|
|   boost_python3
|
|   Some (but not all) of the required Boost libraries were found.  You may
|   need to install these additional Boost libraries.  Alternatively, set
|   BOOST_LIBRARYDIR to the directory containing Boost libraries or 
BOOST_ROOT

|   to the location of Boost.
| Call Stack (most recent call first):
|   CMakeLists.txt:10 (find_package)

Thanks,



Ross


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

Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available

[Yu, Mingli]

On 2018年10月17日 17:39, Burton, Ross wrote:

On Wed, 17 Oct 2018 at 06:48, Yu, Mingli  wrote:

I'm fine not add the the hack fix from boost side, but as I know there
is another package camera-calibration-parsers which has the same problem
as below apart from cv-bridge. BTW, there may some other package also
has this kind of problem. This to say we need to fix the issue for the
this kind of packages one by one.


Yes, it will need to be fixed one by one, but everyone will have to do
this because this is what Boost is now doing.  This isn't a change to
boost that we introduced, upstream changed the library names so
everyone who uses boost will be fixing their code.


Many thanks for Ross's clarification!
If we need to fix the packages one by one, but not add the hack at boost 
side, then https://bugzilla.yoctoproject.org/show_bug.cgi?id=12833 
should be invalid.


Thanks,



Ross


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

Re: [OE-core] [PATCH v2] package_manager.py: correct the deploydir when packagefeed-stability inherited

[Yu, Mingli]

On 2018年10月24日 18:35, mingli...@windriver.com wrote:

From: Mingli Yu 

After create_packages_dir added in below commit:
85e72e1 package_manager: Filter to only rpms we depend upon

When add below line into conf/local.conf
INHERIT += "packagefeed-stability"

There comes below error when do_rootfs
Exception: FileExistsError: [Errno 17] File exists: 
'/$Prj/tmp/deploy/rpm-prediff/i586/initscripts-1.0-r155.i586.rpm' -> 
'/$Prj/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo/rpm-prediff/i586/initscripts-1.0-r155.i586.rpm'

In create_packages_dir function, there is a logic
as bb.utils.remove(subrepo_dir, recurse=True) to
clean subrepo_dir which is actually as example is
/$Prj/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo/rpm.

But currently when inherit packagefeed-stability class,
the parameter deploydir passed to create_packages_dir is
still /$Prj/tmp/deploy/rpm as example, it should be
/$Prj/tmp/deploy/rpm-diff. Otherwise, there is a logic
os.link(l, dest) in create_packages_dir function will
result in below logic:
os.link("/$Prj/tmp/deploy/rpm-prediff/i586/initscripts-1.0-r155.i586.rpm", 
"/$Prj/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo/rpm-prediff/i586/initscripts-1.0-r155.i586.rpm")

Actually doesn't clean 
/$Prj/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo/rpm-prediff
, need to update the deploydir to make the
logic changed as below to fix the do_rootfs failure
s.link("/$Prj/tmp/deploy/rpm-prediff/i586/initscripts-1.0-r155.i586.rpm", 
"/$Prj/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo/rpm/i586/initscripts-1.0-r155.i586.rpm")


A typo here, resend out V3.

Thanks,



Signed-off-by: Mingli Yu 
---
  meta/lib/oe/package_manager.py | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 2cc1c752b3..032d0d811b 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -733,8 +733,10 @@ class RpmPM(PackageManager):
  self.primary_arch = self.d.getVar('MACHINE_ARCH')

  self.rpm_repo_dir = oe.path.join(self.d.getVar('WORKDIR'), 
rpm_repo_workdir)
-create_packages_dir(self.d, oe.path.join(self.rpm_repo_dir, "rpm"), 
d.getVar("DEPLOY_DIR_RPM"), "package_write_rpm", filterbydependencies)
-
+deploy_prepath = d.getVar("DEPLOY_DIR_RPM")
+if bb.data.inherits_class('packagefeed-stability', d):
+deploy_prepath = deploy_prepath + "-prediff"
+create_packages_dir(self.d, oe.path.join(self.rpm_repo_dir, "rpm"), 
deploy_prepath, "package_write_rpm", filterbydependencies)
  self.saved_packaging_data = 
self.d.expand('${T}/saved_packaging_data/%s' % self.task_name)
  if not os.path.exists(self.d.expand('${T}/saved_packaging_data')):
  bb.utils.mkdirhier(self.d.expand('${T}/saved_packaging_data'))
@@ -1147,9 +1149,12 @@ class OpkgPM(OpkgDpkgPM):
  self.opkg_cmd = bb.utils.which(os.getenv('PATH'), "opkg")
  self.opkg_args = "--volatile-cache -f %s -t %s -o %s " % 
(self.config_file, self.d.expand('${T}/ipktemp/') ,target_rootfs)
  self.opkg_args += self.d.getVar("OPKG_ARGS")
+deploy_prepath = d.getVar("DEPLOY_DIR_IPK")
+if bb.data.inherits_class('packagefeed-stability', d):
+deploy_prepath = deploy_prepath + "-prediff"

  if prepare_index:
-create_packages_dir(self.d, self.deploy_dir, d.getVar("DEPLOY_DIR_IPK"), 
"package_write_ipk", filterbydependencies)
+create_packages_dir(self.d, self.deploy_dir, deploy_prepath, 
"package_write_ipk", filterbydependencies)

  opkg_lib_dir = self.d.getVar('OPKGLIBDIR')
  if opkg_lib_dir[0] == "/":
@@ -1526,7 +1531,10 @@ class DpkgPM(OpkgDpkgPM):
  super(DpkgPM, self).__init__(d, target_rootfs)
  self.deploy_dir = oe.path.join(self.d.getVar('WORKDIR'), 
deb_repo_workdir)

-create_packages_dir(self.d, self.deploy_dir, d.getVar("DEPLOY_DIR_DEB"), 
"package_write_deb", filterbydependencies)
+deploy_prepath = d.getVar("DEPLOY_DIR_DEB")
+if bb.data.inherits_class('packagefeed-stability', d):
+deploy_prepath = deploy_prepath + "-prediff"
+create_packages_dir(self.d, self.deploy_dir, deploy_prepath, 
"package_write_deb", filterbydependencies)

  if apt_conf_dir is None:
  self.apt_conf_dir = self.d.expand("${APTCONF_TARGET}/apt")


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

Re: [OE-core] [PATCH] mtd-utils: Update SRC_URI

[Yu, Mingli]

On 2018年10月31日 03:51, Burton, Ross wrote:

It's back now.


Got it, thanks Ross!

Thanks,



Ross
On Tue, 30 Oct 2018 at 12:13, Burton, Ross  wrote:


The machine is only down temporarily and should be back soon.  I don't
think we should merge this as we'll be reverting shortly.

Ross
On Tue, 30 Oct 2018 at 07:53,  wrote:


From: Mingli Yu 

The official repo for mtd-utils is git://git.infradead.org/mtd-utils.git,
however there comes below error:
$ git ls-remote git://git.infradead.org/mtd-utils.git
fatal: unable to connect to git.infradead.org:
git.infradead.org[0: 198.137.202.133]: errno=Connection timed out
git.infradead.org[1: 2607:7c80:54:e::133]: errno=Network is unreachable

Use the alternative one instead currently.

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/mtd/mtd-utils_git.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/mtd/mtd-utils_git.bb 
b/meta/recipes-devtools/mtd/mtd-utils_git.bb
index f53c6c1..b71c997 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_git.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_git.bb
@@ -13,7 +13,7 @@ RDEPENDS_mtd-utils-tests += "bash"
  PV = "2.0.2+${SRCPV}"

  SRCREV = "bc63d36e39f389c8c17f6a8e9db47f2acc884659"
-SRC_URI = "git://git.infradead.org/mtd-utils.git \
+SRC_URI = "git://github.com/sigma-star/mtd-utils.git \
 file://add-exclusion-to-mkfs-jffs2-git-2.patch \
 
file://0001-Revert-Return-correct-error-number-in-ubi_get_vol_in.patch \
  "
--
2.7.4

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



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

Re: [OE-core] [oe-core][PATCH 0/2] python: add tk support

[Yu, Mingli]

On 2018年10月30日 12:52, Randy MacLeod wrote:

On 10/29/18 8:51 AM, Burton, Ross wrote:

Terrified to ask, but why?
On Thu, 25 Oct 2018 at 09:39,  wrote:


1, move tk recipe from meta-oe
2, enable tk to add tk support


Well, tcl and tk do go together and Khem's comment from 2013
suggested that it might be pulled into oe-core some day.

I think what started us down this path is a FACE [1] compliance test.
If there's resistance to moving the package to oe-core, can we
enable python-tk even if tk stayed in meta-oe, Grace?
Also, this should be done using using PACKAGECONFIG?
Finally, what about python3-tk ?


Will send out v2 to use PACKAGECONFIG for tk and add tk support for 
python3 altogether.


Thanks,



../Randy

[1] https://en.wikipedia.org/wiki/Future_Airborne_Capability_Environment

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




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

Re: [OE-core] [PATCH 2/7] python3: add tk support

[Yu, Mingli]

On 2018年11月08日 21:49, Burton, Ross wrote:

On Thu, 8 Nov 2018 at 06:09,  wrote:

+if "tkinter" in pypackage and "tk" in pkgconfig:
+d.appendVar('FILES_' + pypackage, ' ' + 
"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter*.so")
+if "tkinter" in pypackage and "tk" in pkgconfig:
+d.appendVar('RDEPENDS_' + pypackage, ' ' + 'tk')


Why is this here and not in the manifest?



It's because we can optionally enable or disable tk via PACKAGECONFIG, 
if add it to manifest then we need to always enable tk which is also the 
implement in v1.


Thanks,
Grace



Ross


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

Re: [OE-core] [PATCH 2/7] python3: add tk support

[Yu, Mingli]

Hi Alejandro,

Many thanks for your comments, please check my comments inline.

On 2018年11月12日 23:28, Alejandro Hernandez wrote:

Hey Yu,


On 11/11/2018 6:28 PM, Yu, Mingli wrote:



On 2018年11月09日 21:02, Burton, Ross wrote:

On Fri, 9 Nov 2018 at 01:39, Yu, Mingli  wrote:

Why is this here and not in the manifest?


It's because we can optionally enable or disable tk via PACKAGECONFIG,
if add it to manifest then we need to always enable tk which is also
the
implement in v1.


Are you sure?  As I understand it there won't be any errors if the
contents don't exist.  And to be honest if there are, then the
manifest tooling should handle that neatly without special-casing.


Hi Ross,

Thanks for your feedback!

I didn't quite understand what you mean. As I know, if we add the the
setting in manifest as below:
diff --git
a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index f922561..09c9199 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1056,10 +1056,12 @@
 "tkinter": {
 "summary": "Python Tcl/Tk bindings",
 "rdepends": [
-"core"
+"core",
+"tk"



This error is happening because you are trying to add python3-tk on
RDEPENDS, and that package doesn't exist, when you specify "foo" on the
"rdepends" section of the manifest it is translated to ${PN}-foo.


Yes, that's why I point out that we need to add extra logic in python3 
recipe to make it rdepends on tk after add the logic as below:


diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json

index f922561..09c9199 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1056,10 +1056,12 @@
 "tkinter": {
 "summary": "Python Tcl/Tk bindings",
 "rdepends": [
-"core"
+"core",
+"tk"
 ],
 "files": [
-"${libdir}/python${PYTHON_MAJMIN}/tkinter"
+"${libdir}/python${PYTHON_MAJMIN}/tkinter",
+"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter*.so"
 ],
 "cached": []
 },



So two things:

1. The manifest can have the _tkinter.*.so on the "files section of
tkinter (please note that this is _tkinter.*.so and not _tkinter*.so,
the wildcard should be after a "." this is to keep a standard which the
tooling can handle more easily.


Got it, thanks!



When the PACKAGECONFIG is enabled, the files for tkinter will be picked
up correctly.

2. You should not manually add "rdepends" to the manifest, the tool
itself should populate those automatically, this is better because we
would avoid this kind of errors.

Please add the package to the manifest, populate the "files" and
"summary" section and then run $ bitbake python3 -c create_manifest to
populate the rdepends section automatically, also keep in mind that you
should run this when the PACKAGECONFIG is enabled for the native package
as well (thats how it will pick up the dependencies).


No new package needed to add to manifest, we only need to update the 
items for the existed package tkinter and per your suggestion not 
manually add "rdepends" to the manifest, so I only add files to manifest 
as below in manifest file,


diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json

index f922561..09c9199 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1056,10 +1056,12 @@
"tkinter": {
"summary": "Python Tcl/Tk bindings",
"rdepends": [
"core"
],
"files": [
- "${libdir}/python${PYTHON_MAJMIN}/tkinter"
+ "${libdir}/python${PYTHON_MAJMIN}/tkinter",
+ "${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter*.so"
],
"cached": []
},

And also the update the python3 recipe,

diff --git a/meta/recipes-devtools/python/python3_3.5.6.bb 
b/meta/recipes-devtools/python/python3_3.5.6.bb

index 2a45476..e50e7dc 100644
--- a/meta/recipes-devtools/python/python3_3.5.6.bb
+++ b/meta/recipes-devtools/python/python3_3.5.6.bb
@@ -78,10 +78,11 @@ export CCSHARED = "-fPIC"
 # Fix cross compilation of different modules
 export CROSSPYTHONPATH = 
"${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dynload/:${B}/build/lib.linux-${TARGET_ARCH}-${PYTHON_MAJMIN}:${S}/Lib:${S}/Lib/plat-linux"


-P

Re: [OE-core] [PATCH 2/7] python3: add tk support

[Yu, Mingli]

On 2018年11月09日 21:02, Burton, Ross wrote:

On Fri, 9 Nov 2018 at 01:39, Yu, Mingli  wrote:

Why is this here and not in the manifest?


It's because we can optionally enable or disable tk via PACKAGECONFIG,
if add it to manifest then we need to always enable tk which is also the
implement in v1.


Are you sure?  As I understand it there won't be any errors if the
contents don't exist.  And to be honest if there are, then the
manifest tooling should handle that neatly without special-casing.


Hi Ross,

Thanks for your feedback!

I didn't quite understand what you mean. As I know, if we add the the 
setting in manifest as below:
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json

index f922561..09c9199 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1056,10 +1056,12 @@
 "tkinter": {
 "summary": "Python Tcl/Tk bindings",
 "rdepends": [
-"core"
+"core",
+"tk"
 ],
 "files": [
-"${libdir}/python${PYTHON_MAJMIN}/tkinter"
+"${libdir}/python${PYTHON_MAJMIN}/tkinter",
+"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter*.so"
 ],
 "cached": []
 },

There comes below error:
ERROR: Nothing RPROVIDES 'python3-tk' (but 
/mybuild/layers/oe-core/meta/recipes-devtools/python/python3_3.5.6.bb 
RDEPENDS on or otherwise requires it)

NOTE: Runtime target 'python3-tk' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['python3-tk']
ERROR: Required build target 'python3' has no buildable providers.
Missing or unbuildable dependency chain was: ['python3', 'python3-tk']

That's to say, we still need to add some fix in 
meta/recipes-devtools/python/python3_3.5.6.bb. If so, it may be flexible 
and clear to directly to make the implement just as what I send in the RR.


Thanks,



Ross


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

Re: [OE-core] [PATCH 2/7] python3: add tk support

[Yu, Mingli]

On 2018年11月13日 16:25, Alejandro Hernandez wrote:

On 11/12/2018 7:03 PM, Yu, Mingli wrote:

Hi Alejandro,

Many thanks for your comments, please check my comments inline.

On 2018年11月12日 23:28, Alejandro Hernandez wrote:

Hey Yu,


On 11/11/2018 6:28 PM, Yu, Mingli wrote:



On 2018年11月09日 21:02, Burton, Ross wrote:

On Fri, 9 Nov 2018 at 01:39, Yu, Mingli 
wrote:

Why is this here and not in the manifest?


It's because we can optionally enable or disable tk via
PACKAGECONFIG,
if add it to manifest then we need to always enable tk which is also
the
implement in v1.


Are you sure?  As I understand it there won't be any errors if the
contents don't exist.  And to be honest if there are, then the
manifest tooling should handle that neatly without special-casing.


Hi Ross,

Thanks for your feedback!

I didn't quite understand what you mean. As I know, if we add the the
setting in manifest as below:
diff --git
a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index f922561..09c9199 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1056,10 +1056,12 @@
 "tkinter": {
 "summary": "Python Tcl/Tk bindings",
 "rdepends": [
-"core"
+"core",
+"tk"



This error is happening because you are trying to add python3-tk on
RDEPENDS, and that package doesn't exist, when you specify "foo" on the
"rdepends" section of the manifest it is translated to ${PN}-foo.


Yes, that's why I point out that we need to add extra logic in python3
recipe to make it rdepends on tk after add the logic as below:

diff --git
a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index f922561..09c9199 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1056,10 +1056,12 @@
 "tkinter": {
 "summary": "Python Tcl/Tk bindings",
 "rdepends": [
-"core"
+"core",
+"tk"
 ],
 "files": [
-"${libdir}/python${PYTHON_MAJMIN}/tkinter"
+"${libdir}/python${PYTHON_MAJMIN}/tkinter",
+ "${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter*.so"
 ],
 "cached": []
 },



So two things:

1. The manifest can have the _tkinter.*.so on the "files section of
tkinter (please note that this is _tkinter.*.so and not _tkinter*.so,
the wildcard should be after a "." this is to keep a standard which the
tooling can handle more easily.


Got it, thanks!



When the PACKAGECONFIG is enabled, the files for tkinter will be picked
up correctly.

2. You should not manually add "rdepends" to the manifest, the tool
itself should populate those automatically, this is better because we
would avoid this kind of errors.

Please add the package to the manifest, populate the "files" and
"summary" section and then run $ bitbake python3 -c create_manifest to
populate the rdepends section automatically, also keep in mind that you
should run this when the PACKAGECONFIG is enabled for the native package
as well (thats how it will pick up the dependencies).


No new package needed to add to manifest, we only need to update the
items for the existed package tkinter and per your suggestion not
manually add "rdepends" to the manifest, so I only add files to
manifest as below in manifest file,



My mistake  I thought you were adding a new package.

Anyway, as a matter of fact, all you need to do is to add the same
PACKAGECONFIG on the python3 native recipe and enable it, once its


Many thanks for Alejandro's hints!

I still failed to let the files(_tkinter.*.so) automatically added to 
manifest though I run $ bitbake python3 -c create_manifest altogether 
with below logic. Could you help to take a look is there anything I miss?


$ git diff
diff --git a/meta/recipes-devtools/python/python3-native_3.5.6.bb 
b/meta/recipes-devtools/python/python3-native_3.5.6.bb

index d5953cf..80f9678 100644
--- a/meta/recipes-devtools/python/python3-native_3.5.6.bb
+++ b/meta/recipes-devtools/python/python3-native_3.5.6.bb
@@ -28,6 +28,8 @@ 
file://0003-bpo-32947-Fixes-for-TLS-1.3-and-OpenSSL-1.1.1-GH-876.patch \

 file://0004-bpo-33570-TLS-1.3-ciphers-for-OpenSSL-1.1.1-GH-6976.patch \
 file://0005-bpo-30714-ALPN-changes-for-OpenSSL-1.1.0f-2305.patch \
 "
+PACKAGECONFIG ??= "tkinter"
+PACKAGECONFIG[tkinter] = ",,tk,tk"

 EXTRANATIVEPATH += "bzip2-native"
 DEPENDS = "openssl-native bzip2-replacement-native zlib-native 
readline

Re: [OE-core] [PATCH 2/7] python3: add tk support

[Yu, Mingli]

On 2018年11月14日 05:26, Alejandro Hernandez wrote:

On 11/13/2018 1:10 AM, Yu, Mingli wrote:



On 2018年11月13日 16:25, Alejandro Hernandez wrote:

On 11/12/2018 7:03 PM, Yu, Mingli wrote:

Hi Alejandro,

Many thanks for your comments, please check my comments inline.

On 2018年11月12日 23:28, Alejandro Hernandez wrote:

Hey Yu,


On 11/11/2018 6:28 PM, Yu, Mingli wrote:



On 2018年11月09日 21:02, Burton, Ross wrote:

On Fri, 9 Nov 2018 at 01:39, Yu, Mingli 
wrote:

Why is this here and not in the manifest?


It's because we can optionally enable or disable tk via
PACKAGECONFIG,
if add it to manifest then we need to always enable tk which is
also
the
implement in v1.


Are you sure?  As I understand it there won't be any errors if the
contents don't exist.  And to be honest if there are, then the
manifest tooling should handle that neatly without special-casing.


Hi Ross,

Thanks for your feedback!

I didn't quite understand what you mean. As I know, if we add the the
setting in manifest as below:
diff --git
a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index f922561..09c9199 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1056,10 +1056,12 @@
 "tkinter": {
 "summary": "Python Tcl/Tk bindings",
 "rdepends": [
-"core"
+"core",
+"tk"



This error is happening because you are trying to add python3-tk on
RDEPENDS, and that package doesn't exist, when you specify "foo" on
the
"rdepends" section of the manifest it is translated to ${PN}-foo.


Yes, that's why I point out that we need to add extra logic in python3
recipe to make it rdepends on tk after add the logic as below:

diff --git
a/meta/recipes-devtools/python/python3/python3-manifest.json
b/meta/recipes-devtools/python/python3/python3-manifest.json
index f922561..09c9199 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1056,10 +1056,12 @@
 "tkinter": {
 "summary": "Python Tcl/Tk bindings",
 "rdepends": [
-"core"
+"core",
+"tk"
 ],
 "files": [
-"${libdir}/python${PYTHON_MAJMIN}/tkinter"
+"${libdir}/python${PYTHON_MAJMIN}/tkinter",
+ "${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter*.so"
 ],
 "cached": []
 },



So two things:

1. The manifest can have the _tkinter.*.so on the "files section of
tkinter (please note that this is _tkinter.*.so and not _tkinter*.so,
the wildcard should be after a "." this is to keep a standard which
the
tooling can handle more easily.


Got it, thanks!



When the PACKAGECONFIG is enabled, the files for tkinter will be
picked
up correctly.

2. You should not manually add "rdepends" to the manifest, the tool
itself should populate those automatically, this is better because we
would avoid this kind of errors.

Please add the package to the manifest, populate the "files" and
"summary" section and then run $ bitbake python3 -c create_manifest to
populate the rdepends section automatically, also keep in mind that
you
should run this when the PACKAGECONFIG is enabled for the native
package
as well (thats how it will pick up the dependencies).


No new package needed to add to manifest, we only need to update the
items for the existed package tkinter and per your suggestion not
manually add "rdepends" to the manifest, so I only add files to
manifest as below in manifest file,



My mistake  I thought you were adding a new package.

Anyway, as a matter of fact, all you need to do is to add the same
PACKAGECONFIG on the python3 native recipe and enable it, once its


Many thanks for Alejandro's hints!

I still failed to let the files(_tkinter.*.so) automatically added to
manifest though I run $ bitbake python3 -c create_manifest altogether
with below logic. Could you help to take a look is there anything I miss?

$ git diff
diff --git a/meta/recipes-devtools/python/python3-native_3.5.6.bb
b/meta/recipes-devtools/python/python3-native_3.5.6.bb
index d5953cf..80f9678 100644
--- a/meta/recipes-devtools/python/python3-native_3.5.6.bb
+++ b/meta/recipes-devtools/python/python3-native_3.5.6.bb
@@ -28,6 +28,8 @@
file://0003-bpo-32947-Fixes-for-TLS-1.3-and-OpenSSL-1.1.1-GH-876.patch \
 file://0004-bpo-33570-TLS-1.3-ciphers-for-OpenSSL-1.1.1-GH-6976.patch \
 file://0005-bpo-30714-ALPN-changes-for-OpenSSL-1.1.0f-2305.patch \
 "
+PACKAGECONFIG ??= "tkinter"
+PACKAGECONFIG[tkinter] = ",,tk,tk"


Wouldn't you have to DEPEND on

Re: [OE-core] [PATCH] kexec-tools: fix for "Unhandled rela relocation: R_X86_64_PLT32" error

[Yu, Mingli]

On 2018年08月31日 22:07, Andrea Adami wrote:

On Fri, Aug 31, 2018 at 8:34 AM Yu, Mingli  wrote:


Ping.


Hi,
FYI it is in master upstream as of  b9de21ef51a7 so you could just
upgrade the recipe.
Cheers
Andrea


Thanks Andrea! But the current kexec-tools version is already 2.0.17 
which is the latest version.


Thanks,






On 2018年08月30日 16:36, mingli...@windriver.com wrote:

From: Mingli Yu 

In response to a change in binutils, commit b21ebf2fb4c
(x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
the linux kernel during the 4.16 development cycle and has
since been backported to earlier stable kernel series. The
change results in the failure message as below when rebooting
via kexec.
   # kexec -l /boot/bzImage --append="console=ttyS0,115200 root=/dev/sda1"
   Unhandled rela relocation: R_X86_64_PLT32

Fix this by replicating the change in kexec.

Signed-off-by: Mingli Yu 
---
   ...or-Unhandled-rela-relocation-R_X86_64_PLT.patch | 41 
++
   meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb|  1 +
   2 files changed, 42 insertions(+)
   create mode 100644 
meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch

diff --git 
a/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch
 
b/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch
new file mode 100644
index 000..e0cced5
--- /dev/null
+++ 
b/meta/recipes-kernel/kexec/kexec-tools/0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch
@@ -0,0 +1,41 @@
+From b9de21ef51a7ceab7122a707c188602eae22c4ee Mon Sep 17 00:00:00 2001
+From: Chris Clayton 
+Date: Mon, 20 Aug 2018 12:00:31 +0100
+Subject: [PATCH] kexec: fix for "Unhandled rela relocation: R_X86_64_PLT32" 
error
+
+In response to a change in binutils, commit b21ebf2fb4c
+(x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
+the linux kernel during the 4.16 development cycle and has
+since been backported to earlier stable kernel series. The
+change results in the failure message in $SUBJECT when
+rebooting via kexec.
+
+Fix this by replicating the change in kexec.
+
+Upstream-Status: 
Backport[https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=b9de21ef51a7ceab7122a707c188602eae22c4ee]
+
+Signed-off-by: Chris Clayton 
+Acked-by: Baoquan He 
+Tested-by: Bhupesh Sharma 
+Acked-by: Bhupesh Sharma 
+Signed-off-by: Simon Horman 
+Signed-off-by: Mingli Yu 
+---
+ kexec/arch/x86_64/kexec-elf-rel-x86_64.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/kexec/arch/x86_64/kexec-elf-rel-x86_64.c 
b/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
+index 7fdde73..db85b44 100644
+--- a/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
 b/kexec/arch/x86_64/kexec-elf-rel-x86_64.c
+@@ -79,6 +79,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr),
+ goto overflow;
+ break;
+ case R_X86_64_PC32:
++case R_X86_64_PLT32:
+ *(uint32_t *)location = value - address;
+ break;
+ default:
+--
+2.7.4
+
diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb 
b/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
index f4ec586..dd46901 100644
--- a/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
+++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.17.bb
@@ -18,6 +18,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz
  file://0010-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch \
  file://kexec-x32.patch \
  file://0001-Disable-PIE-during-link.patch \
+   
file://0001-kexec-fix-for-Unhandled-rela-relocation-R_X86_64_PLT.patch \
  "

   SRC_URI[md5sum] = "8e071ca473694a71e4ae60ed7ef6f377"


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



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

Re: [OE-core] [PATCH v2] glibc: fix Segmentation fault in gethostid.c

[Yu, Mingli]

Will send out v3 with the update from glibc upstream.

Thanks,

On 2018年09月18日 17:47, mingli...@windriver.com wrote:

From: Mingli Yu 

When run test program hostid, it encounters
Segmentation fault as hp is NULL.

  # cat /mybuild/hostid.c
  #include 
  #include 

  int
  main(int argc, char *argv[])
  {
 long hostid;
 hostid = gethostid();
 printf("the hostid is %ld\n", hostid);

  }

  # gcc -o /mybuild/hostid /mybuild/hostid.c
  # /mybuild/hostid
  Segmentation fault
  # gdb /mybuild/hostid
  GNU gdb (GDB) 8.2
  Copyright (C) 2018 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-wrs-linux".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
 .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from /mybuild/hostid...done.
  (gdb) r
  Starting program: /mybuild/hostid

  Program received signal SIGSEGV, Segmentation fault.
  0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
  125 memcpy (, hp->h_addr,
  (gdb) bt
  #0  0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
  #1  0x5159 in main ()

Signed-off-by: Mingli Yu 
---
  .../0001-gethostid.c-check-the-value-of-hp.patch   | 75 ++
  meta/recipes-core/glibc/glibc_2.28.bb  |  1 +
  2 files changed, 76 insertions(+)
  create mode 100644 
meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch 
b/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch
new file mode 100644
index 00..04d1662361
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch
@@ -0,0 +1,75 @@
+From 84cc79a003cf1a29e0a45ee76b67a3800d9e412e Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Tue, 18 Sep 2018 07:29:27 +
+Subject: [PATCH] gethostid.c: check the value of hp
+
+Fix Segmentation fault in gethostid.c
+
+When run test program hostid, it encounters
+Segmentation fault as hp is NULL.
+
+  # cat /mybuild/hostid.c
+  #include 
+  #include 
+
+  int
+  main(int argc, char *argv[])
+  {
+long hostid;
+hostid = gethostid();
+printf("the hostid is %ld\n", hostid);
+  }
+
+  # gcc -o /mybuild/hostid /mybuild/hostid.c
+  # /mybuild/hostid
+  Segmentation fault
+  # gdb /mybuild/hostid
+  GNU gdb (GDB) 8.2
+  Copyright (C) 2018 Free Software Foundation, Inc.
+  License GPLv3+: GNU GPL version 3 or later 
+  This is free software: you are free to change and redistribute it.
+  There is NO WARRANTY, to the extent permitted by law.
+  Type "show copying" and "show warranty" for details.
+  This GDB was configured as "x86_64-wrs-linux".
+  Type "show configuration" for configuration details.
+  For bug reporting instructions, please see:
+  .
+  Find the GDB manual and other documentation resources online at:
+  .
+
+   For help, type "help".
+   Type "apropos word" to search for commands related to "word"...
+   Reading symbols from /mybuild/hostid...done.
+   (gdb) r
+   Starting program: /mybuild/hostid
+
+   Program received signal SIGSEGV, Segmentation fault.
+   0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
+   125  memcpy (, hp->h_addr,
+   (gdb) bt
+#0  0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
+#1  0x5159 in main ()
+
+Upstream-Status: 
Submitted[https://sourceware.org/bugzilla/show_bug.cgi?id=23679]
+
+Signed-off-by: Mingli Yu 
+---
+ sysdeps/unix/sysv/linux/gethostid.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sysdeps/unix/sysv/linux/gethostid.c 
b/sysdeps/unix/sysv/linux/gethostid.c
+index 2e20f034dc..5904b61c40 100644
+--- a/sysdeps/unix/sysv/linux/gethostid.c
 b/sysdeps/unix/sysv/linux/gethostid.c
+@@ -102,7 +102,7 @@ gethostid (void)
+ {
+   int ret = __gethostbyname_r (hostname, ,
+  tmpbuf.data, tmpbuf.length, , );
+-  if (ret == 0)
++  if (ret == 0 && hp != NULL)
+   break;
+   else
+   {
+--
+2.13.3
+
diff --git a/meta/recipes-core/glibc/glibc_2.28.bb 
b/meta/recipes-core/glibc/glibc_2.28.bb
index 0ebbaf9610..0a8fa0c25f 100644
--- a/meta/recipes-core/glibc/glibc_2.28.bb
+++ b/meta/recipes-core/glibc/glibc_2.28.bb

Re: [OE-core] [PATCH v2] nfs-utils: fix build error under tests folder

[Yu, Mingli]

Ping.

On 2018年12月18日 13:21, mingli...@windriver.com wrote:

From: Mingli Yu 

* Redefine the reference path of libnfs.a to
   ../support/nfs/.libs/libnfs.a to fix below
   error when run "make -C tests statdb_dump".
   | make: *** No rule to make target '../support/nfs/libnfs.a', needed by 
'statdb_dump'.  Stop.
   | make: *** No rule to make target '../../support/nfs/libnfs.a', needed by 
'nsm_client'.  Stop.

* The function generic_make_pathname is introduced in
   nfs-utils 2.3.1.
   Add the source file which defines function generic_make_pathname to
   libnsm_a_SOURCES of libnsm.a to fix the undefined reference
   when run "make -C tests statdb_dump"
   | ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | ../support/nsm/libnsm.a(file.o): In function `nsm_setup_pathnames':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:280: 
undefined reference to `generic_setup_basedir'
   | collect2: error: ld returned 1 exit status

* After the logic of commit[dbb643e Removed missing-prototypes warnings.]
   introduced, there comes below error when run
   "make -C tests/nsm_client nsm_client"
   | nlm_sm_inter_svc.c:20:1: error: no previous prototype for 'nlm_sm_prog_3' 
[-Werror=missing-prototypes]

   It is because rpcgen doesn't generate -Wmissing-prototypes
   free code for nlm_sm_inter_svc.c with below logic
   in tests/nsm_client/Makefile.am
   [snip]
   GENFILES_SVC= nlm_sm_inter_svc.c
   [snip]
   $(GENFILES_SVC): %_svc.c: %.x $(RPCGEN)
 test -f $@ && rm -rf $@ || true
 $(RPCGEN) -m -o $@ $<
  So add the patch to not fatalize -Wmissing-prototypes.

Signed-off-by: Mingli Yu 
---
  ...-fix-undefined-function-for-libnsm.a.patch | 295 ++
  ...efile.am-update-the-path-of-libnfs.a.patch |  50 +++
  ...-Do-not-fatalize-Wmissing-prototypes.patch |  43 +++
  .../nfs-utils/nfs-utils_2.3.3.bb  |   3 +
  4 files changed, 391 insertions(+)
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-Do-not-fatalize-Wmissing-prototypes.patch

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
new file mode 100644
index 000..aa551ebd191
--- /dev/null
+++ 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
@@ -0,0 +1,295 @@
+From 690a90a5b7786e40b5447ad7c5f19a7657d27405 Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Fri, 14 Dec 2018 17:44:32 +0800
+Subject: [PATCH] Makefile.am: fix undefined function for libnsm.a
+
+The source file of libnsm.a uses some function
+in ../support/misc/file.c, add ../support/misc/file.c
+to libnsm_a_SOURCES to fix build error when run
+"make -C tests statdb_dump":
+| ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| ../support/nsm/libnsm.a(file.o): In function `nsm_setup_pathnames':
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:280: 
undefined reference to `generic_setup_basedir'
+| collect2: error: ld returned 1 exit status
+
+As there is already one source file named file.c
+as support/nsm/file.c in support/nsm/Makefile.am,
+so rename ../support/misc/file.c to ../support/misc/misc.c.
+
+Upstream-Status: 
Submitted[https://marc.info/?l=linux-nfs=154502780423058=2]
+
+Signed-off-by: Mingli Yu 
+---
+ support/misc/Makefile.am |   2 +-
+ support/misc/file.c  | 111 ---
+ support/misc/misc.c  | 111 +++
+ support/nsm/Makefile.am  |   2 +-
+ 4 files changed, 113 insertions(+), 113 deletions(-)
+ delete mode 100644 support/misc/file.c
+ create mode 100644 support/misc/misc.c
+
+diff --git a/support/misc/Makefile.am b/support/misc/Makefile.am
+index 8936b0d..d4c1f76 100644
+--- a/support/misc/Makefile.am
 

Re: [OE-core] [PATCH 1/2] python2-manifest.json: add logging to rdepends

[Yu, Mingli]

Ping.

On 2019年01月17日 10:26, mingli...@windriver.com wrote:

From: Mingli Yu 

Add loggging to rdepends for python-2to3
and python-multiprocessing.

before patch:
  # python
  Python 2.7.15 (default, Jan 15 2019, 03:09:01)
  [GCC 8.2.0] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from multiprocessing import util
  >>> util.get_logger()
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python2.7/multiprocessing/util.py", line 89, in get_logger
  import logging, atexit
  ImportError: No module named logging
  >>>

After patch:
  # python
  Python 2.7.15 (default, Jan 15 2019, 09:05:49)
  [GCC 8.2.0] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from multiprocessing import util
  >>> util.get_logger()
  
  >>>

  Steps to reproduce:
  1, add below line to local.conf
  IMAGE_INSTALL_append += " python-multiprocessing"
  2, bitbake core-image-base
  3, runqemu qemux86 slirp nographic core-image-base

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/python/python/python2-manifest.json | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python/python2-manifest.json 
b/meta/recipes-devtools/python/python/python2-manifest.json
index 4fff54a95bf..abaa10dbd2e 100644
--- a/meta/recipes-devtools/python/python/python2-manifest.json
+++ b/meta/recipes-devtools/python/python/python2-manifest.json
@@ -106,7 +106,8 @@
  "2to3": {
  "summary": "Python automated Python 2 to 3 code translator",
  "rdepends": [
-"core"
+"core",
+"logging"
  ],
  "files": [
  "${bindir}/2to3",
@@ -728,6 +729,7 @@
  "core",
  "fcntl",
  "io",
+"logging",
  "pickle",
  "subprocess",
  "threading"


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

Re: [OE-core] [PATCH] nfs-utils: fix build error under tests folder

[Yu, Mingli]

On 2018年12月18日 01:16, richard.pur...@linuxfoundation.org wrote:

On Mon, 2018-12-17 at 00:47 -0800, mingli...@windriver.com wrote:

From: Mingli Yu 

* Redefine the reference path of libnfs.a to
   ../support/nfs/.libs/libnfs.a to fix below
   error when run "make -C tests statdb_dump".
   | make: *** No rule to make target '../support/nfs/libnfs.a',
needed by 'statdb_dump'.  Stop.
   | make: *** No rule to make target '../../support/nfs/libnfs.a',
needed by 'nsm_client'.  Stop.

* The function generic_make_pathname is introduced in
   nfs-utils 2.3.1.
   Add the source file which defines function generic_make_pathname to
   libnsm_a_SOURCES of libnsm.a to fix the undefined reference
   when run "make -C tests statdb_dump"
   | ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-
2.3.1/support/nsm/file.c:175: undefined reference to
`generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-
2.3.1/support/nsm/file.c:175: undefined reference to
`generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-
2.3.1/support/nsm/file.c:175: undefined reference to
`generic_make_pathname'
   | ../support/nsm/libnsm.a(file.o): In function
`nsm_setup_pathnames':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-
2.3.1/support/nsm/file.c:280: undefined reference to
`generic_setup_basedir'
   | collect2: error: ld returned 1 exit status

* After the logic of commit[dbb643e Removed missing-prototypes
warnings.]
   introduced, there comes below error when run
   "make -C tests/nsm_client nsm_client"
   | nlm_sm_inter_svc.c:20:1: error: no previous prototype for
'nlm_sm_prog_3' [-Werror=missing-prototypes]

   It is because rpcgen doesn't generate -Wmissing-prototypes
   free code for nlm_sm_inter_svc.c with below logic
   in tests/nsm_client/Makefile.am
   [snip]
   GENFILES_SVC= nlm_sm_inter_svc.c
   [snip]
   $(GENFILES_SVC): %_svc.c: %.x $(RPCGEN)
 test -f $@ && rm -rf $@ || true
 $(RPCGEN) -m -o $@ $<
  So add the patch to not fatalize -Wmissing-prototypes.


Fails on musl:


Will send out V2 to fix it.



https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/104

Cheers,

Richard



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

Re: [OE-core] [PATCH v2] nfs-utils: fix build error under tests folder

[Yu, Mingli]

Ping.

On 2018年12月18日 13:21, mingli...@windriver.com wrote:

From: Mingli Yu 

* Redefine the reference path of libnfs.a to
   ../support/nfs/.libs/libnfs.a to fix below
   error when run "make -C tests statdb_dump".
   | make: *** No rule to make target '../support/nfs/libnfs.a', needed by 
'statdb_dump'.  Stop.
   | make: *** No rule to make target '../../support/nfs/libnfs.a', needed by 
'nsm_client'.  Stop.

* The function generic_make_pathname is introduced in
   nfs-utils 2.3.1.
   Add the source file which defines function generic_make_pathname to
   libnsm_a_SOURCES of libnsm.a to fix the undefined reference
   when run "make -C tests statdb_dump"
   | ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | ../support/nsm/libnsm.a(file.o): In function `nsm_setup_pathnames':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:280: 
undefined reference to `generic_setup_basedir'
   | collect2: error: ld returned 1 exit status

* After the logic of commit[dbb643e Removed missing-prototypes warnings.]
   introduced, there comes below error when run
   "make -C tests/nsm_client nsm_client"
   | nlm_sm_inter_svc.c:20:1: error: no previous prototype for 'nlm_sm_prog_3' 
[-Werror=missing-prototypes]

   It is because rpcgen doesn't generate -Wmissing-prototypes
   free code for nlm_sm_inter_svc.c with below logic
   in tests/nsm_client/Makefile.am
   [snip]
   GENFILES_SVC= nlm_sm_inter_svc.c
   [snip]
   $(GENFILES_SVC): %_svc.c: %.x $(RPCGEN)
 test -f $@ && rm -rf $@ || true
 $(RPCGEN) -m -o $@ $<
  So add the patch to not fatalize -Wmissing-prototypes.

Signed-off-by: Mingli Yu 
---
  ...-fix-undefined-function-for-libnsm.a.patch | 295 ++
  ...efile.am-update-the-path-of-libnfs.a.patch |  50 +++
  ...-Do-not-fatalize-Wmissing-prototypes.patch |  43 +++
  .../nfs-utils/nfs-utils_2.3.3.bb  |   3 +
  4 files changed, 391 insertions(+)
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-Do-not-fatalize-Wmissing-prototypes.patch

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
new file mode 100644
index 000..aa551ebd191
--- /dev/null
+++ 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
@@ -0,0 +1,295 @@
+From 690a90a5b7786e40b5447ad7c5f19a7657d27405 Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Fri, 14 Dec 2018 17:44:32 +0800
+Subject: [PATCH] Makefile.am: fix undefined function for libnsm.a
+
+The source file of libnsm.a uses some function
+in ../support/misc/file.c, add ../support/misc/file.c
+to libnsm_a_SOURCES to fix build error when run
+"make -C tests statdb_dump":
+| ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| ../support/nsm/libnsm.a(file.o): In function `nsm_setup_pathnames':
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:280: 
undefined reference to `generic_setup_basedir'
+| collect2: error: ld returned 1 exit status
+
+As there is already one source file named file.c
+as support/nsm/file.c in support/nsm/Makefile.am,
+so rename ../support/misc/file.c to ../support/misc/misc.c.
+
+Upstream-Status: 
Submitted[https://marc.info/?l=linux-nfs=154502780423058=2]
+
+Signed-off-by: Mingli Yu 
+---
+ support/misc/Makefile.am |   2 +-
+ support/misc/file.c  | 111 ---
+ support/misc/misc.c  | 111 +++
+ support/nsm/Makefile.am  |   2 +-
+ 4 files changed, 113 insertions(+), 113 deletions(-)
+ delete mode 100644 support/misc/file.c
+ create mode 100644 support/misc/misc.c
+
+diff --git a/support/misc/Makefile.am b/support/misc/Makefile.am
+index 8936b0d..d4c1f76 100644
+--- a/support/misc/Makefile.am
 

Re: [OE-core] [PATCH] nspr: improve reproducibility

[Yu, Mingli]

Ping.

Thanks,

On 2018年11月16日 15:09, mingli...@windriver.com wrote:

From: Mingli Yu 

Remove _BUILD_STRING and _BUILD_TIME in _pl_bld.h
to avoid introducing timestamp in the .so library
such as libnspr4.so as below:
  $ readelf --wide --decompress --hex-dump=.rodata libnspr4.so
  [snip]
   0x4000 32303138 2d31312d 31352030 353a3439 2018-11-15 05:49
  [snip]

[YOCTO #12639]

Signed-off-by: Mingli Yu 
---
  ...remove-_BUILD_STRING-and-_BUILD_TIME.patch | 103 ++
  meta/recipes-support/nspr/nspr_4.20.bb|   1 +
  2 files changed, 104 insertions(+)
  create mode 100644 
meta/recipes-support/nspr/nspr/Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch

diff --git 
a/meta/recipes-support/nspr/nspr/Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch
 
b/meta/recipes-support/nspr/nspr/Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch
new file mode 100644
index 00..90fe45f34d
--- /dev/null
+++ 
b/meta/recipes-support/nspr/nspr/Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch
@@ -0,0 +1,103 @@
+From 8a592e4ead4ed6befe6044da3dd2dc7523c33905 Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Fri, 16 Nov 2018 13:52:49 +0800
+Subject: [PATCH] Makefile.in: remove _BUILD_STRING and _BUILD_TIME
+
+Remove _BUILD_STRING and _BUILD_TIME to avoid
+adding timestamp to _pl_bld.h which can result
+in adding timestamp in library file such as
+libnspr4.so.
+ $ readelf --wide --decompress --hex-dump=.rodata libnspr4.so
+ [snip]
+  0x4000 32303138 2d31312d 31352030 353a3439 2018-11-15 05:49
+ [snip]
+
+Upstream-Status: Pending
+
+Signed-off-by: Mingli Yu 
+---
+ lib/ds/Makefile.in| 8 +---
+ lib/libc/src/Makefile.in  | 8 +---
+ lib/prstreams/Makefile.in | 8 +---
+ pr/src/Makefile.in| 8 +---
+ 4 files changed, 4 insertions(+), 28 deletions(-)
+
+diff --git a/lib/ds/Makefile.in b/lib/ds/Makefile.in
+index e737791..b578476 100644
+--- a/lib/ds/Makefile.in
 b/lib/ds/Makefile.in
+@@ -114,13 +114,7 @@ GARBAGE += $(TINC)
+
+ $(TINC):
+   @$(MAKE_OBJDIR)
+-  @$(ECHO) '#define _BUILD_STRING "$(SH_DATE)"' > $(TINC)
+-  @if test ! -z "$(SH_NOW)"; then \
+-  $(ECHO) '#define _BUILD_TIME $(SH_NOW)$(SUF)' >> $(TINC); \
+-  else \
+-  true; \
+-  fi
+-  @$(ECHO) '#define _PRODUCTION "$(PROD)"' >> $(TINC)
++  @$(ECHO) '#define _PRODUCTION "$(PROD)"' > $(TINC)
+
+
+ $(OBJDIR)/plvrsion.$(OBJ_SUFFIX): plvrsion.c $(TINC)
+diff --git a/lib/libc/src/Makefile.in b/lib/libc/src/Makefile.in
+index e8a6d9f..978ed28 100644
+--- a/lib/libc/src/Makefile.in
 b/lib/libc/src/Makefile.in
+@@ -116,13 +116,7 @@ GARBAGE += $(TINC)
+
+ $(TINC):
+   @$(MAKE_OBJDIR)
+-  @$(ECHO) '#define _BUILD_STRING "$(SH_DATE)"' > $(TINC)
+-  @if test ! -z "$(SH_NOW)"; then \
+-  $(ECHO) '#define _BUILD_TIME $(SH_NOW)$(SUF)' >> $(TINC); \
+-  else \
+-  true; \
+-  fi
+-  @$(ECHO) '#define _PRODUCTION "$(PROD)"' >> $(TINC)
++  @$(ECHO) '#define _PRODUCTION "$(PROD)"' > $(TINC)
+
+
+ $(OBJDIR)/plvrsion.$(OBJ_SUFFIX): plvrsion.c $(TINC)
+diff --git a/lib/prstreams/Makefile.in b/lib/prstreams/Makefile.in
+index aeb2944..f318097 100644
+--- a/lib/prstreams/Makefile.in
 b/lib/prstreams/Makefile.in
+@@ -116,13 +116,7 @@ endif
+
+ $(TINC):
+   @$(MAKE_OBJDIR)
+-  @$(ECHO) '#define _BUILD_STRING "$(SH_DATE)"' > $(TINC)
+-  @if test ! -z "$(SH_NOW)"; then \
+-  $(ECHO) '#define _BUILD_TIME $(SH_NOW)$(SUF)' >> $(TINC); \
+-  else \
+-  true; \
+-  fi
+-  @$(ECHO) '#define _PRODUCTION "$(PROD)"' >> $(TINC)
++  @$(ECHO) '#define _PRODUCTION "$(PROD)"' > $(TINC)
+
+
+ $(OBJDIR)/plvrsion.$(OBJ_SUFFIX): plvrsion.c $(TINC)
+diff --git a/pr/src/Makefile.in b/pr/src/Makefile.in
+index 19c5a69..b4ac31c 100644
+--- a/pr/src/Makefile.in
 b/pr/src/Makefile.in
+@@ -326,13 +326,7 @@ GARBAGE += $(TINC)
+
+ $(TINC):
+   @$(MAKE_OBJDIR)
+-  @$(ECHO) '#define _BUILD_STRING "$(SH_DATE)"' > $(TINC)
+-  @if test ! -z "$(SH_NOW)"; then \
+-  $(ECHO) '#define _BUILD_TIME $(SH_NOW)$(SUF)' >> $(TINC); \
+-  else \
+-  true; \
+-  fi
+-  @$(ECHO) '#define _PRODUCTION "$(PROD)"' >> $(TINC)
++  @$(ECHO) '#define _PRODUCTION "$(PROD)"' > $(TINC)
+
+
+ $(OBJDIR)/prvrsion.$(OBJ_SUFFIX): prvrsion.c $(TINC)
+--
+2.7.4
+
diff --git a/meta/recipes-support/nspr/nspr_4.20.bb 
b/meta/recipes-support/nspr/nspr_4.20.bb
index fe3b4bd2ed..98ca909631 100644
--- a/meta/recipes-support/nspr/nspr_4.20.bb
+++ b/meta/recipes-support/nspr/nspr_4.20.bb
@@ -12,6 +12,7 @@ SRC_URI = 
"http://ftp.mozilla.org/pub/nspr/releases/v${PV}/src/nspr-${PV}.tar.gz
 file://0002-Add-nios2-support.patch \
 file://0001-md-Fix-build-with-musl.patch \
 file://0004-Add-ARC-support.patch \
+   file://Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch \
 file://nspr.pc.in \
  "



--
___

Re: [OE-core] [PATCH v3] python: add tk support

[Yu, Mingli]

Ping.

Thanks,

On 2018年11月14日 17:38, mingli...@windriver.com wrote:

From: Mingli Yu 

Add support to enable tk via PACKGECONFIG.
before the patch:
  # python
  Python 2.7.15 (default, Nov  8 2018, 04:53:50)
  [GCC 8.2.0] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import Tkinter
  Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 39, in 
 import _tkinter # If this fails your Python may not be configured for Tk
  ImportError: No module named _tkinter
  >>>

After the patch, if enable tk in PACKGECONFIG, then
  # python
  Python 2.7.15 (default, Oct 25 2018, 08:12:45)
  [GCC 8.2.0] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import Tkinter
  >>>

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/python/python/python2-manifest.json | 3 ++-
  meta/recipes-devtools/python/python_2.7.15.bb | 5 +++--
  2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python/python2-manifest.json 
b/meta/recipes-devtools/python/python/python2-manifest.json
index 260fa6f..a9f3924 100644
--- a/meta/recipes-devtools/python/python/python2-manifest.json
+++ b/meta/recipes-devtools/python/python/python2-manifest.json
@@ -966,6 +966,7 @@
  "core"
  ],
  "files": [
+"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter.so",
  "${libdir}/python2.7/lib-tk"
  ]
  },
@@ -1043,4 +1044,4 @@
  "${libdir}/python2.7/lib-dynload/zlib.so"
  ]
  }
-}
\ No newline at end of file
+}
diff --git a/meta/recipes-devtools/python/python_2.7.15.bb 
b/meta/recipes-devtools/python/python_2.7.15.bb
index dd969d8..6a60aa7 100644
--- a/meta/recipes-devtools/python/python_2.7.15.bb
+++ b/meta/recipes-devtools/python/python_2.7.15.bb
@@ -21,7 +21,7 @@ SRC_URI += "\
file://setuptweaks.patch \
file://check-if-target-is-64b-not-host.patch \
file://search_db_h_in_inc_dirs_and_avoid_warning.patch \
-  file://avoid_warning_about_tkinter.patch \
+  ${@bb.utils.contains('PACKAGECONFIG', 'tk', '', 
'file://avoid_warning_about_tkinter.patch', d)} \
file://avoid_warning_for_sunos_specific_module.patch \
file://python-2.7.3-remove-bsdb-rpath.patch \
file://run-ptest \
@@ -45,6 +45,7 @@ EXTRA_OECONF += "ac_cv_file__dev_ptmx=yes 
ac_cv_file__dev_ptc=no"

  PACKAGECONFIG ??= "bdb"
  PACKAGECONFIG[bdb] = ",,db"
+PACKAGECONFIG[tk] = ",,tk"

  do_configure_append() {
rm -f ${S}/Makefile.orig
@@ -172,7 +173,7 @@ RDEPENDS_${PN}-modules += "${PN}-misc"

  # ptest
  RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip"
-
+RDEPENDS_${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 'tk', '', 
d)}"
  # catch manpage
  PACKAGES += "${PN}-man"
  FILES_${PN}-man = "${datadir}/man"


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

Re: [OE-core] [PATCH v2] python3: add tk support

[Yu, Mingli]

Ping.

Thanks,

On 2018年11月14日 17:36, mingli...@windriver.com wrote:

From: Mingli Yu 

Add support to enable tk via PACKAGECONFIG.
before this patch:
  # python3
  Python 3.5.6 (default, Nov  8 2018, 04:53:45)
  [GCC 8.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import tkinter
  Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib64/python3.5/tkinter/__init__.py", line 35, in 
 import _tkinter # If this fails your Python may not be configured for Tk
  ImportError: No module named '_tkinter'
  >>>

After this patch, if enable tk in PACKAGECONFIG, then
  # python3
  Python 3.5.6 (default, Nov  8 2018, 03:15:52)
  [GCC 8.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import tkinter
  >>>

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/python/python3-native_3.5.6.bb   | 3 ++-
  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
  meta/recipes-devtools/python/python3_3.5.6.bb  | 5 +++--
  3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-native_3.5.6.bb 
b/meta/recipes-devtools/python/python3-native_3.5.6.bb
index d5953cf..1e98c03 100644
--- a/meta/recipes-devtools/python/python3-native_3.5.6.bb
+++ b/meta/recipes-devtools/python/python3-native_3.5.6.bb
@@ -12,7 +12,7 @@ file://130-readline-setup.patch \
  file://150-fix-setupterm.patch \
  file://python-3.3-multilib.patch \
  file://03-fix-tkinter-detection.patch \
-file://avoid_warning_about_tkinter.patch \
+${@bb.utils.contains('PACKAGECONFIG', 'tk', '', 
'file://avoid_warning_about_tkinter.patch', d)} \
  file://0001-h2py-Fix-issue-13032-where-it-fails-with-UnicodeDeco.patch \
  file://sysroot-include-headers.patch \
  file://unixccompiler.patch \
@@ -28,6 +28,7 @@ 
file://0003-bpo-32947-Fixes-for-TLS-1.3-and-OpenSSL-1.1.1-GH-876.patch \
  file://0004-bpo-33570-TLS-1.3-ciphers-for-OpenSSL-1.1.1-GH-6976.patch \
  file://0005-bpo-30714-ALPN-changes-for-OpenSSL-1.1.0f-2305.patch \
  "
+PACKAGECONFIG[tk] = ",,tk-native"

  EXTRANATIVEPATH += "bzip2-native"
  DEPENDS = "openssl-native bzip2-replacement-native zlib-native readline-native 
sqlite3-native gdbm-native"
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 5329bf7..617256a 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1060,6 +1060,7 @@
  "core"
  ],
  "files": [
+"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter.*.so",
  "${libdir}/python${PYTHON_MAJMIN}/tkinter"
  ],
  "cached": []
diff --git a/meta/recipes-devtools/python/python3_3.5.6.bb 
b/meta/recipes-devtools/python/python3_3.5.6.bb
index 31f8ead..5c80421 100644
--- a/meta/recipes-devtools/python/python3_3.5.6.bb
+++ b/meta/recipes-devtools/python/python3_3.5.6.bb
@@ -21,7 +21,7 @@ ${DISTRO_SRC_URI} \

  SRC_URI += "\
  file://03-fix-tkinter-detection.patch \
-file://avoid_warning_about_tkinter.patch \
+${@bb.utils.contains('PACKAGECONFIG', 'tk', '', 
'file://avoid_warning_about_tkinter.patch', d)} \
  file://cgi_py.patch \
  file://host_include_contamination.patch \
  file://python-3.3-multilib.patch \
@@ -82,6 +82,7 @@ PACKAGECONFIG ??= "readline 
${@bb.utils.contains('MACHINE_FEATURES', 'qemu-userm
  PACKAGECONFIG[readline] = ",,readline"
  # Use profile guided optimisation by running PyBench inside qemu-user
  PACKAGECONFIG[pgo] = "--enable-optimizations"
+PACKAGECONFIG[tk] = ",,tk"

  do_configure_append() {
rm -f ${S}/Makefile.orig
@@ -246,7 +247,7 @@ PACKAGES += "${PN}-man"
  FILES_${PN}-man = "${datadir}/man"

  RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2"
-
+RDEPENDS_${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 'tk', '', 
d)}"
  RDEPENDS_${PN}-dev = ""

  BBCLASSEXTEND = "nativesdk"


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

Re: [OE-core] [PATCH v2] python3: add tk support

[Yu, Mingli]

Ping.

Thanks,

On 2018年11月14日 17:36, mingli...@windriver.com wrote:

From: Mingli Yu 

Add support to enable tk via PACKAGECONFIG.
before this patch:
  # python3
  Python 3.5.6 (default, Nov  8 2018, 04:53:45)
  [GCC 8.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import tkinter
  Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib64/python3.5/tkinter/__init__.py", line 35, in 
 import _tkinter # If this fails your Python may not be configured for Tk
  ImportError: No module named '_tkinter'
  >>>

After this patch, if enable tk in PACKAGECONFIG, then
  # python3
  Python 3.5.6 (default, Nov  8 2018, 03:15:52)
  [GCC 8.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import tkinter
  >>>

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/python/python3-native_3.5.6.bb   | 3 ++-
  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
  meta/recipes-devtools/python/python3_3.5.6.bb  | 5 +++--
  3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-native_3.5.6.bb 
b/meta/recipes-devtools/python/python3-native_3.5.6.bb
index d5953cf..1e98c03 100644
--- a/meta/recipes-devtools/python/python3-native_3.5.6.bb
+++ b/meta/recipes-devtools/python/python3-native_3.5.6.bb
@@ -12,7 +12,7 @@ file://130-readline-setup.patch \
  file://150-fix-setupterm.patch \
  file://python-3.3-multilib.patch \
  file://03-fix-tkinter-detection.patch \
-file://avoid_warning_about_tkinter.patch \
+${@bb.utils.contains('PACKAGECONFIG', 'tk', '', 
'file://avoid_warning_about_tkinter.patch', d)} \
  file://0001-h2py-Fix-issue-13032-where-it-fails-with-UnicodeDeco.patch \
  file://sysroot-include-headers.patch \
  file://unixccompiler.patch \
@@ -28,6 +28,7 @@ 
file://0003-bpo-32947-Fixes-for-TLS-1.3-and-OpenSSL-1.1.1-GH-876.patch \
  file://0004-bpo-33570-TLS-1.3-ciphers-for-OpenSSL-1.1.1-GH-6976.patch \
  file://0005-bpo-30714-ALPN-changes-for-OpenSSL-1.1.0f-2305.patch \
  "
+PACKAGECONFIG[tk] = ",,tk-native"

  EXTRANATIVEPATH += "bzip2-native"
  DEPENDS = "openssl-native bzip2-replacement-native zlib-native readline-native 
sqlite3-native gdbm-native"
diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 5329bf7..617256a 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1060,6 +1060,7 @@
  "core"
  ],
  "files": [
+"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter.*.so",
  "${libdir}/python${PYTHON_MAJMIN}/tkinter"
  ],
  "cached": []
diff --git a/meta/recipes-devtools/python/python3_3.5.6.bb 
b/meta/recipes-devtools/python/python3_3.5.6.bb
index 31f8ead..5c80421 100644
--- a/meta/recipes-devtools/python/python3_3.5.6.bb
+++ b/meta/recipes-devtools/python/python3_3.5.6.bb
@@ -21,7 +21,7 @@ ${DISTRO_SRC_URI} \

  SRC_URI += "\
  file://03-fix-tkinter-detection.patch \
-file://avoid_warning_about_tkinter.patch \
+${@bb.utils.contains('PACKAGECONFIG', 'tk', '', 
'file://avoid_warning_about_tkinter.patch', d)} \
  file://cgi_py.patch \
  file://host_include_contamination.patch \
  file://python-3.3-multilib.patch \
@@ -82,6 +82,7 @@ PACKAGECONFIG ??= "readline 
${@bb.utils.contains('MACHINE_FEATURES', 'qemu-userm
  PACKAGECONFIG[readline] = ",,readline"
  # Use profile guided optimisation by running PyBench inside qemu-user
  PACKAGECONFIG[pgo] = "--enable-optimizations"
+PACKAGECONFIG[tk] = ",,tk"

  do_configure_append() {
rm -f ${S}/Makefile.orig
@@ -246,7 +247,7 @@ PACKAGES += "${PN}-man"
  FILES_${PN}-man = "${datadir}/man"

  RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip bzip2"
-
+RDEPENDS_${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 'tk', '', 
d)}"
  RDEPENDS_${PN}-dev = ""

  BBCLASSEXTEND = "nativesdk"


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

Re: [OE-core] [PATCH v3] python: add tk support

[Yu, Mingli]

Ping.

Thanks,

On 2018年11月14日 17:38, mingli...@windriver.com wrote:

From: Mingli Yu 

Add support to enable tk via PACKGECONFIG.
before the patch:
  # python
  Python 2.7.15 (default, Nov  8 2018, 04:53:50)
  [GCC 8.2.0] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import Tkinter
  Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 39, in 
 import _tkinter # If this fails your Python may not be configured for Tk
  ImportError: No module named _tkinter
  >>>

After the patch, if enable tk in PACKGECONFIG, then
  # python
  Python 2.7.15 (default, Oct 25 2018, 08:12:45)
  [GCC 8.2.0] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import Tkinter
  >>>

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/python/python/python2-manifest.json | 3 ++-
  meta/recipes-devtools/python/python_2.7.15.bb | 5 +++--
  2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python/python2-manifest.json 
b/meta/recipes-devtools/python/python/python2-manifest.json
index 260fa6f..a9f3924 100644
--- a/meta/recipes-devtools/python/python/python2-manifest.json
+++ b/meta/recipes-devtools/python/python/python2-manifest.json
@@ -966,6 +966,7 @@
  "core"
  ],
  "files": [
+"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter.so",
  "${libdir}/python2.7/lib-tk"
  ]
  },
@@ -1043,4 +1044,4 @@
  "${libdir}/python2.7/lib-dynload/zlib.so"
  ]
  }
-}
\ No newline at end of file
+}
diff --git a/meta/recipes-devtools/python/python_2.7.15.bb 
b/meta/recipes-devtools/python/python_2.7.15.bb
index dd969d8..6a60aa7 100644
--- a/meta/recipes-devtools/python/python_2.7.15.bb
+++ b/meta/recipes-devtools/python/python_2.7.15.bb
@@ -21,7 +21,7 @@ SRC_URI += "\
file://setuptweaks.patch \
file://check-if-target-is-64b-not-host.patch \
file://search_db_h_in_inc_dirs_and_avoid_warning.patch \
-  file://avoid_warning_about_tkinter.patch \
+  ${@bb.utils.contains('PACKAGECONFIG', 'tk', '', 
'file://avoid_warning_about_tkinter.patch', d)} \
file://avoid_warning_for_sunos_specific_module.patch \
file://python-2.7.3-remove-bsdb-rpath.patch \
file://run-ptest \
@@ -45,6 +45,7 @@ EXTRA_OECONF += "ac_cv_file__dev_ptmx=yes 
ac_cv_file__dev_ptc=no"

  PACKAGECONFIG ??= "bdb"
  PACKAGECONFIG[bdb] = ",,db"
+PACKAGECONFIG[tk] = ",,tk"

  do_configure_append() {
rm -f ${S}/Makefile.orig
@@ -172,7 +173,7 @@ RDEPENDS_${PN}-modules += "${PN}-misc"

  # ptest
  RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests unzip"
-
+RDEPENDS_${PN}-tkinter += "${@bb.utils.contains('PACKAGECONFIG', 'tk', 'tk', '', 
d)}"
  # catch manpage
  PACKAGES += "${PN}-man"
  FILES_${PN}-man = "${datadir}/man"


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

Re: [OE-core] [PATCH v2] nfs-utils: fix build error under tests folder

[Yu, Mingli]

Ping.

On 2018年12月18日 13:21, mingli...@windriver.com wrote:

From: Mingli Yu 

* Redefine the reference path of libnfs.a to
   ../support/nfs/.libs/libnfs.a to fix below
   error when run "make -C tests statdb_dump".
   | make: *** No rule to make target '../support/nfs/libnfs.a', needed by 
'statdb_dump'.  Stop.
   | make: *** No rule to make target '../../support/nfs/libnfs.a', needed by 
'nsm_client'.  Stop.

* The function generic_make_pathname is introduced in
   nfs-utils 2.3.1.
   Add the source file which defines function generic_make_pathname to
   libnsm_a_SOURCES of libnsm.a to fix the undefined reference
   when run "make -C tests statdb_dump"
   | ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
   | ../support/nsm/libnsm.a(file.o): In function `nsm_setup_pathnames':
   | /usr/src/debug/nfs-utils/2.3.1-r0/nfs-utils-2.3.1/support/nsm/file.c:280: 
undefined reference to `generic_setup_basedir'
   | collect2: error: ld returned 1 exit status

* After the logic of commit[dbb643e Removed missing-prototypes warnings.]
   introduced, there comes below error when run
   "make -C tests/nsm_client nsm_client"
   | nlm_sm_inter_svc.c:20:1: error: no previous prototype for 'nlm_sm_prog_3' 
[-Werror=missing-prototypes]

   It is because rpcgen doesn't generate -Wmissing-prototypes
   free code for nlm_sm_inter_svc.c with below logic
   in tests/nsm_client/Makefile.am
   [snip]
   GENFILES_SVC= nlm_sm_inter_svc.c
   [snip]
   $(GENFILES_SVC): %_svc.c: %.x $(RPCGEN)
 test -f $@ && rm -rf $@ || true
 $(RPCGEN) -m -o $@ $<
  So add the patch to not fatalize -Wmissing-prototypes.

Signed-off-by: Mingli Yu 
---
  ...-fix-undefined-function-for-libnsm.a.patch | 295 ++
  ...efile.am-update-the-path-of-libnfs.a.patch |  50 +++
  ...-Do-not-fatalize-Wmissing-prototypes.patch |  43 +++
  .../nfs-utils/nfs-utils_2.3.3.bb  |   3 +
  4 files changed, 391 insertions(+)
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
  create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-Do-not-fatalize-Wmissing-prototypes.patch

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
new file mode 100644
index 000..aa551ebd191
--- /dev/null
+++ 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
@@ -0,0 +1,295 @@
+From 690a90a5b7786e40b5447ad7c5f19a7657d27405 Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Fri, 14 Dec 2018 17:44:32 +0800
+Subject: [PATCH] Makefile.am: fix undefined function for libnsm.a
+
+The source file of libnsm.a uses some function
+in ../support/misc/file.c, add ../support/misc/file.c
+to libnsm_a_SOURCES to fix build error when run
+"make -C tests statdb_dump":
+| ../support/nsm/libnsm.a(file.o): In function `nsm_make_pathname':
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:175: 
undefined reference to `generic_make_pathname'
+| ../support/nsm/libnsm.a(file.o): In function `nsm_setup_pathnames':
+| /usr/src/debug/nfs-utils/2.3.3-r0/nfs-utils-2.3.3/support/nsm/file.c:280: 
undefined reference to `generic_setup_basedir'
+| collect2: error: ld returned 1 exit status
+
+As there is already one source file named file.c
+as support/nsm/file.c in support/nsm/Makefile.am,
+so rename ../support/misc/file.c to ../support/misc/misc.c.
+
+Upstream-Status: 
Submitted[https://marc.info/?l=linux-nfs=154502780423058=2]
+
+Signed-off-by: Mingli Yu 
+---
+ support/misc/Makefile.am |   2 +-
+ support/misc/file.c  | 111 ---
+ support/misc/misc.c  | 111 +++
+ support/nsm/Makefile.am  |   2 +-
+ 4 files changed, 113 insertions(+), 113 deletions(-)
+ delete mode 100644 support/misc/file.c
+ create mode 100644 support/misc/misc.c
+
+diff --git a/support/misc/Makefile.am b/support/misc/Makefile.am
+index 8936b0d..d4c1f76 100644
+--- a/support/misc/Makefile.am
 

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

[Yu, Mingli]

Ping.

Thanks,

On 2019年03月19日 16:44, mingli...@windriver.com wrote:

From: Mingli Yu 

When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| 
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
 In function 'elf_is_symlink':
| 
../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
 error: 'st.st_mode' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
|   return S_ISLNK (st.st_mode);

Initialize st_mode member to fix the above issue.

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/gcc/gcc-8.3.inc  |  1 +
  .../0041-elf.c-initialize-st_mode-member.patch | 33 ++
  2 files changed, 34 insertions(+)
  create mode 100644 
meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch

diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc 
b/meta/recipes-devtools/gcc/gcc-8.3.inc
index f7bf257..3501325 100644
--- a/meta/recipes-devtools/gcc/gcc-8.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
@@ -71,6 +71,7 @@ SRC_URI = "\
 file://0038-Re-introduce-spe-commandline-options.patch \
 file://0039-riscv-Disable-multilib-for-OE.patch \
 file://0040-powerpc-powerpc64-Add-support-for-musl-ldso.patch \
+   file://0041-elf.c-initialize-st_mode-member.patch \
  "
  SRC_URI[md5sum] = "65b210b4bfe7e060051f799e0f994896"
  SRC_URI[sha256sum] = 
"64baadfe6cc0f4947a84cb12d7f0dfaf45bb58b7e92461639596c21e02d97d2c"
diff --git 
a/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch 
b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
new file mode 100644
index 000..8e80c4e
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
@@ -0,0 +1,33 @@
+From 960f3e1f104192ceb80a97e665fadffda5285aab Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Tue, 19 Mar 2019 16:23:04 +0800
+Subject: [PATCH] elf.c: initialize st_mode member
+
+Initialize st_mode member to fix the below
+build failure when -Og included in compiler flag.
+| 
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
 In function 'elf_is_symlink':
+| 
../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
 error: 'st.st_mode' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
+   return S_ISLNK (st.st_mode);
+
+Upstream-Status: 
Submitted[https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00900.html]
+
+Signed-off-by: Mingli Yu 
+---
+ libbacktrace/elf.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
+index f4863f0..561bdc2 100644
+--- a/libbacktrace/elf.c
 b/libbacktrace/elf.c
+@@ -766,6 +766,7 @@ static int
+ elf_is_symlink (const char *filename)
+ {
+   struct stat st;
++  st.st_mode = 0;
+
+   if (lstat (filename, ) < 0)
+ return 0;
+--
+2.7.4
+


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

Re: [OE-core] [PATCH] asciidoc: disable xmllint check

[Yu, Mingli]

On 2019年04月04日 16:02, Burton, Ross wrote:

Some further context (note to self: don't reply to mails during
breakfast): the problem which lead to xmllint failing also leads to
the XSL stylesheets in the sysroot not being used, so xsltproc
downloads them.  On my machine, asciidoc should execute do_compile in
about a second, but with the broken catalogues this was taking almost
a minute.


Thanks Ross's reminding.

Thanks,



Ross

On Thu, 4 Apr 2019 at 08:30, Burton, Ross  wrote:


I've submitted fixes for this already.

Ross

On Thu, 4 Apr 2019 at 07:12,  wrote:


From: Mingli Yu 

asciidoc-native build with below error when
there is no xmllint program located on build
host:
| python3 a2x.py -f manpage doc/asciidoc.1.txt
| a2x: ERROR: "xmllint" --nonet --noout --valid 
"/build/tmp/work/x86_64-linux/asciidoc-native/8.6.9+py3-gitAUTOINC+618f6e6f6b-r0/git/doc/asciidoc.1.xml"
 returned non-zero exit status 4
|
| Makefile:110: recipe for target 'doc/asciidoc.1' failed

Considering it's only used to check the xml format
of the doc file as doc/asciidoc.1.txt, so disable
xmllint check to fix the above issue.

Signed-off-by: Mingli Yu 
---
  meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb   |  4 ++-
  .../0001-Makefile.in-disable-xmllint-check.patch   | 38 ++
  2 files changed, 41 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-extended/asciidoc/files/0001-Makefile.in-disable-xmllint-check.patch

diff --git a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb 
b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
index d0d1517..7e00b34 100644
--- a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
+++ b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
@@ -8,7 +8,9 @@ LICENSE = "GPLv2"
  LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
  file://COPYRIGHT;md5=029ad5428ba5efa20176b396222d4069"

-SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https"
+SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https \
+   file://0001-Makefile.in-disable-xmllint-check.patch \
+"
  SRCREV = "618f6e6f6b558ed1e5f2588cd60a5a6b4f881ca0"
  PV .= "+py3-git${SRCPV}"

diff --git 
a/meta/recipes-extended/asciidoc/files/0001-Makefile.in-disable-xmllint-check.patch
 
b/meta/recipes-extended/asciidoc/files/0001-Makefile.in-disable-xmllint-check.patch
new file mode 100644
index 000..4c0dd6d
--- /dev/null
+++ 
b/meta/recipes-extended/asciidoc/files/0001-Makefile.in-disable-xmllint-check.patch
@@ -0,0 +1,38 @@
+From 242e58f16c129f5983d6b32d493619cc4f87703e Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Thu, 4 Apr 2019 13:38:10 +0800
+Subject: [PATCH] Makefile.in: disable xmllint check
+
+asciidoc-native build with below error when
+there is no xmllint program located on build
+host:
+| python3 a2x.py -f manpage doc/asciidoc.1.txt
+| a2x: ERROR: "xmllint" --nonet --noout --valid 
"/build/tmp/work/x86_64-linux/asciidoc-native/8.6.9+py3-gitAUTOINC+618f6e6f6b-r0/git/doc/asciidoc.1.xml"
 returned non-zero exit status 4
+|
+| Makefile:110: recipe for target 'doc/asciidoc.1' failed
+
+So disable xmllint check to fix the above issue.
+
+Upstream-Status: Inappropriate [oe build specific]
+
+Signed-off-by: Mingli Yu 
+---
+ Makefile.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index ffba3b5..fb95fab 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -107,7 +107,7 @@ $(DATATARGETS): % : %dir
+   $(INSTALL_DATA) $($@) $(DESTDIR)/$($<)/
+
+ $(manp): %.1 : %.1.txt
+-  python3 a2x.py -f manpage $<
++  python3 a2x.py -L -f manpage $<
+
+ docs:
+   $(INSTALL) -d $(DESTDIR)/$(docdir)
+--
+2.7.4
+
--
2.7.4

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



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

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

[Yu, Mingli]

Ping.

Any comments here?

Thanks,

On 2019年03月19日 16:44, mingli...@windriver.com wrote:

From: Mingli Yu 

When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| 
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
 In function 'elf_is_symlink':
| 
../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
 error: 'st.st_mode' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
|   return S_ISLNK (st.st_mode);

Initialize st_mode member to fix the above issue.

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/gcc/gcc-8.3.inc  |  1 +
  .../0041-elf.c-initialize-st_mode-member.patch | 33 ++
  2 files changed, 34 insertions(+)
  create mode 100644 
meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch

diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc 
b/meta/recipes-devtools/gcc/gcc-8.3.inc
index f7bf257..3501325 100644
--- a/meta/recipes-devtools/gcc/gcc-8.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
@@ -71,6 +71,7 @@ SRC_URI = "\
 file://0038-Re-introduce-spe-commandline-options.patch \
 file://0039-riscv-Disable-multilib-for-OE.patch \
 file://0040-powerpc-powerpc64-Add-support-for-musl-ldso.patch \
+   file://0041-elf.c-initialize-st_mode-member.patch \
  "
  SRC_URI[md5sum] = "65b210b4bfe7e060051f799e0f994896"
  SRC_URI[sha256sum] = 
"64baadfe6cc0f4947a84cb12d7f0dfaf45bb58b7e92461639596c21e02d97d2c"
diff --git 
a/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch 
b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
new file mode 100644
index 000..8e80c4e
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
@@ -0,0 +1,33 @@
+From 960f3e1f104192ceb80a97e665fadffda5285aab Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Tue, 19 Mar 2019 16:23:04 +0800
+Subject: [PATCH] elf.c: initialize st_mode member
+
+Initialize st_mode member to fix the below
+build failure when -Og included in compiler flag.
+| 
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
 In function 'elf_is_symlink':
+| 
../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
 error: 'st.st_mode' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
+   return S_ISLNK (st.st_mode);
+
+Upstream-Status: 
Submitted[https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00900.html]
+
+Signed-off-by: Mingli Yu 
+---
+ libbacktrace/elf.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
+index f4863f0..561bdc2 100644
+--- a/libbacktrace/elf.c
 b/libbacktrace/elf.c
+@@ -766,6 +766,7 @@ static int
+ elf_is_symlink (const char *filename)
+ {
+   struct stat st;
++  st.st_mode = 0;
+
+   if (lstat (filename, ) < 0)
+ return 0;
+--
+2.7.4
+


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

Re: [OE-core] [PATCH] logrotate.py: restore /etc/logrotate.d/wtmp

[Yu, Mingli]

Ping.

This patch is used to fix the incomplete cleanup for logrotate test in oeqa.

Thanks,

On 2019年02月13日 13:43, mingli...@windriver.com wrote:

From: Mingli Yu 

During the test logrotate.LogrotateTest.test_1_logrotate_setup,
there is below logic:
  # mkdir $HOME/logrotate_dir
  # sed -i "s#wtmp {#wtmp {\nolddir $HOME/logrotate_dir#" 
/etc/logrotate.d/wtmp

After all logrotate.LogrotateTest finished, only cleanup
$HOME/logrotate_dir as below, but don't restore
the config file /etc/logrotate.d/wtmp.
[snip]
def tearDownClass(cls):
 cls.tc.target.run('rm -rf $HOME/logrotate_dir')
[snip]

That's to say, there is one additional line added
to /etc/logrotate.d/wtmp and will make the logrotate
service start failed when run systemd.SystemdBasicTests.test_systemd_failed

Take an example as below when run test as root:
  # cat /etc/logrotate.d/wtmp
  # no packages own wtmp -- we'll rotate it here
  /var/log/wtmp {
 olddir /root/logrotate_dir
 missingok
 monthly
 create 0664 root utmp
 minsize 1M
 rotate 1
  }

  # ls /root/logrotate_dir
  ls: cannot access '/root/logrotate_dir': No such file or directory

  # systemctl start logrotate
  Job for logrotate.service failed because the control process exited with 
error code.
  See "systemctl status logrotate.service" and "journalctl -xe" for details.

  # systemctl status logrotate
   logrotate.service - Rotate log files
Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor 
preset>
Active: failed (Result: exit-code) since Wed 2019-02-13 03:35:19 UTC; 7s ago
  Docs: man:logrotate(8)
man:logrotate.conf(5)
Process: 540 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf 
(code=exited, status=1/FAILURE)
Main PID: 540 (code=exited, status=1/FAILURE)

   Feb 13 03:35:18 qemumips systemd[1]: Starting Rotate log files...
   Feb 13 03:35:19 qemumips logrotate[540]: error: wtmp:9 error verifying 
olddir path /root/logrotate_dir: No such file or directory
   Feb 13 03:35:19 qemumips logrotate[540]: error: found error in file wtmp, 
skipping
   Feb 13 03:35:19 qemumips systemd[1]: logrotate.service: Main process exited, 
code=exited, status=1/FAILURE
   Feb 13 03:35:19 qemumips systemd[1]: logrotate.service: Failed with result 
'exit-code'.
   Feb 13 03:35:19 qemumips systemd[1]: Failed to start Rotate log files.

Add the logic to restore /etc/logrotate.d/wtmp to
make the cleanup complete to fix the above issue.

Signed-off-by: Mingli Yu 
---
  meta/lib/oeqa/runtime/cases/logrotate.py | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/runtime/cases/logrotate.py 
b/meta/lib/oeqa/runtime/cases/logrotate.py
index db6e695..d266644 100644
--- a/meta/lib/oeqa/runtime/cases/logrotate.py
+++ b/meta/lib/oeqa/runtime/cases/logrotate.py
@@ -9,8 +9,12 @@ from oeqa.runtime.decorator.package import OEHasPackage
  class LogrotateTest(OERuntimeTestCase):

  @classmethod
+def setUpClass(cls):
+cls.tc.target.run('cp /etc/logrotate.d/wtmp $HOME/wtmp.oeqabak')
+
+@classmethod
  def tearDownClass(cls):
-cls.tc.target.run('rm -rf $HOME/logrotate_dir')
+cls.tc.target.run('mv -f $HOME/wtmp.oeqabak /etc/logrotate.d/wtmp && 
rm -rf $HOME/logrotate_dir')

  @OETestID(1544)
  @OETestDepends(['ssh.SSHTest.test_ssh'])


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

Re: [OE-core] [PATCH] gcc-sanitizers: fix the build with -fno-omit-frame-pointer

[Yu, Mingli]

On 2019年03月06日 13:34, Khem Raj wrote:

On Tue, Mar 5, 2019 at 8:24 PM  wrote:


From: Mingli Yu 

Fix the below build issue for gcc-sanitizers when
both -mthumb and -fno-omit-frame-pointer configured
for arm.
| ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 
'sanitizer::uptr sanitizer::internal_clone(int (*)(void*), void*, int, void*, 
int*, void*, int*)':
| ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1540:1: error: 
r7 cannot be used in asm here
}

Reference: https://reviews.llvm.org/D50180

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb 
b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
index f3c7058..2f89c86 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
@@ -5,3 +5,4 @@ require gcc-sanitizers.inc
  # sanitizer_linux.s:5749: Error: lo register required -- `ldr ip,[sp],#8'
  ARM_INSTRUCTION_SET_armv4 = "arm"
  ARM_INSTRUCTION_SET_armv5 = "arm"
+TARGET_CFLAGS_remove_arm = "${@bb.utils.contains('TUNE_CCARGS', '-mthumb', 
'-fno-omit-frame-pointer', '', d)}"


what target does it happen with ? since we set arm ISA for armv5 and
v4 it must be something else


It is armv7vethf.




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

Re: [OE-core] [PATCH] libdazzle: add check for GTK3DISTROFEATURES

[Yu, Mingli]

Ping.

Thanks,

On 2019年02月26日 10:50, mingli...@windriver.com wrote:

From: Mingli Yu 

When do world buid, there comes below error:
| ERROR: Nothing PROVIDES 'gtk+3' (but 
/build/layers/oe-core/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb DEPENDS 
on or otherwise requires it)
| gtk+3 was skipped: one of 'x11 wayland' needs to be in DISTRO_FEATURES

Add the check for GTK3DISTROFEATURES to make
the world build work even without GTK3DISTROFEATURES.

Signed-off-by: Mingli Yu 
---
  meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb 
b/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb
index 5441c10..3779b15 100644
--- a/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb
+++ b/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb
@@ -3,7 +3,7 @@ LICENSE = "GPLv3+"
  LIC_FILES_CHKSUM = "file://COPYING;md5=8f0e2cd40e05189ec81232da84bd6e1a"

  GNOMEBASEBUILDCLASS = "meson"
-inherit gnomebase upstream-version-is-even vala gobject-introspection
+inherit gnomebase upstream-version-is-even vala distro_features_check 
gobject-introspection

  DEPENDS = "glib-2.0-native glib-2.0 gtk+3"

@@ -14,5 +14,7 @@ SRC_URI[archive.sha256sum] = 
"78770eae9fa15ac5acb9c733d29459330b2540affbf7293311
  GI_ENABLE_FLAG = "-Dwith_introspection=true"
  GI_DISABLE_FLAG = "-Dwith_introspection=false"

+ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
+
  EXTRA_OEMESON_append_class-target = " ${@bb.utils.contains('GI_DATA_ENABLED', 
'True', '${GI_ENABLE_FLAG}', \
 
'${GI_DISABLE_FLAG}', d)} "


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

Re: [OE-core] [PATCH] gcc-sanitizers: fix the build with -fno-omit-frame-pointer

[Yu, Mingli]

Ping.

Thanks,

On 2019年03月06日 12:24, mingli...@windriver.com wrote:

From: Mingli Yu 

Fix the below build issue for gcc-sanitizers when
both -mthumb and -fno-omit-frame-pointer configured
for arm.
| ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 
'sanitizer::uptr sanitizer::internal_clone(int (*)(void*), void*, int, void*, 
int*, void*, int*)':
| ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1540:1: error: 
r7 cannot be used in asm here
}

Reference: https://reviews.llvm.org/D50180

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb 
b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
index f3c7058..2f89c86 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers_8.2.bb
@@ -5,3 +5,4 @@ require gcc-sanitizers.inc
  # sanitizer_linux.s:5749: Error: lo register required -- `ldr ip,[sp],#8'
  ARM_INSTRUCTION_SET_armv4 = "arm"
  ARM_INSTRUCTION_SET_armv5 = "arm"
+TARGET_CFLAGS_remove_arm = "${@bb.utils.contains('TUNE_CCARGS', '-mthumb', 
'-fno-omit-frame-pointer', '', d)}"


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

Re: [OE-core] [PATCH] systemd: improve reproducibility

[Yu, Mingli]

Ping.

On 2019年02月01日 16:40, mingli...@windriver.com wrote:

From: Mingli Yu 

Considering it's meanlingness to get test dir in
compiled env, remove ABS_BUILD_DIR and ABS_SRC_DIR
lines in src/shared/tests.c to improve reproducibility
to fix below issue:
WARNING: systemd-1_239-r0 do_package_qa: QA Issue: File 
/work/core2-64-wrs-linux/systemd/1_239-r0/packages-split/systemd/lib/systemd/libsystemd-shared-239.so
 in package contained reference to tmpdir [buildpaths]

Signed-off-by: Mingli Yu 
---
  .../0001-test-improve-reproducibility.patch   | 40 +++
  meta/recipes-core/systemd/systemd_239.bb  |  1 +
  2 files changed, 41 insertions(+)
  create mode 100644 
meta/recipes-core/systemd/systemd/0001-test-improve-reproducibility.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-test-improve-reproducibility.patch 
b/meta/recipes-core/systemd/systemd/0001-test-improve-reproducibility.patch
new file mode 100644
index 000..3d7aa7fc238
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0001-test-improve-reproducibility.patch
@@ -0,0 +1,40 @@
+From f28a0e2a5f6a9ace858219c6f2513a5280acab48 Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Fri, 1 Feb 2019 00:18:04 -0800
+Subject: [PATCH] test.c: improve reproducibility
+
+It's meanlingness to run test in compiled env,
+so uncoment the lines to avoid introducing
+ABS_BUILD_DIR and ABS_SRC_DIR to improve
+reproducibility to fix below issue:
+WARNING: systemd-1_239-r0 do_package_qa: QA Issue: File 
/work/core2-64-wrs-linux/systemd/1_239-r0/packages-split/systemd/lib/systemd/libsystemd-shared-239.so
 in package contained reference to tmpdir [buildpaths]
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Mingli Yu 
+---
+ src/shared/tests.c | 8 ++--
+ 1 file changed, 2 insertions(+), 6 deletions(-)
+
+diff --git a/src/shared/tests.c b/src/shared/tests.c
+index 6b3df0aa07..7ac25eefea 100644
+--- a/src/shared/tests.c
 b/src/shared/tests.c
+@@ -37,12 +37,8 @@ const char* get_testdata_dir(const char *suffix) {
+ _cleanup_free_ char *exedir = NULL;
+ assert_se(readlink_and_make_absolute("/proc/self/exe", ) 
>= 0);
+
+-/* Check if we're running from the builddir. If so, use the 
compiled in path. */
+-if (path_startswith(exedir, ABS_BUILD_DIR))
+-assert_se(snprintf(testdir, sizeof(testdir), "%s/test", 
ABS_SRC_DIR) > 0);
+-else
+-/* Try relative path, according to the install-test 
layout */
+-assert_se(snprintf(testdir, sizeof(testdir), 
"%s/testdata", dirname(exedir)) > 0);
++  /* Try relative path, according to the install-test layout 
*/
++  assert_se(snprintf(testdir, sizeof(testdir), "%s/testdata", 
dirname(exedir)) > 0);
+
+ /* test this without the suffix, as it may contain a glob */
+ if (access(testdir, F_OK) < 0) {
+--
+2.17.1
+
diff --git a/meta/recipes-core/systemd/systemd_239.bb 
b/meta/recipes-core/systemd/systemd_239.bb
index f843f588bdb..62ca9b146e7 100644
--- a/meta/recipes-core/systemd/systemd_239.bb
+++ b/meta/recipes-core/systemd/systemd_239.bb
@@ -41,6 +41,7 @@ SRC_URI += "file://touchscreen.rules \
 
file://0024-journald-do-not-store-the-iovec-entry-for-process-co.patch \
 file://0025-journald-set-a-limit-on-the-number-of-fields.patch \
 file://0026-journal-fix-out-of-bounds-read-CVE-2018-16866.patch \
+   file://0001-test-improve-reproducibility.patch \
 "

  # patches made for musl are only applied on TCLIBC is musl


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

Re: [OE-core] [PATCH] nettle: fix ptest failure

[Yu, Mingli]

On 2019年04月13日 05:57, Richard Purdie wrote:

On Fri, 2019-04-12 at 11:27 +0800, mingli...@windriver.com wrote:

From: Mingli Yu 

Remove dlopen-test.patch which originally used
to fix the test dlopen-test, but autually the
patch didn't resolve the issue as dlopen-test.patch
supposes the file /usr/lib/libnettle.so exists.
Instead deploy ${D}${PTEST_PATH}/libnettle.so to
fix the dlopen-test failure.

Update the initialization for the salt to fix
below Segmentation fault and also nettle-pbkdf2-test
failure.
  # echo -n passwd| nettle-pbkdf2 -i 1 -l 16 salt
  [65534.886509] nettle-pbkdf2[708]: segfault at 1f594260 ip
7f3332256998 sp 7fff60d44410 error 4 in
libnettle.so.6.5[7f3332244000+1d00]
  [65534.887525] Code: e8 6d db fe ff 44 01 6d 68 48 83 c4 08 5b 5d 41
5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 49 89 dc e9 68
ff f
  Segmentation fault

Signed-off-by: Mingli Yu 
---
  ...kdf2.c-change-the-initialization-for-salt.patch | 39
++
  .../nettle/nettle-3.4.1/dlopen-test.patch  | 20 ---
  meta/recipes-support/nettle/nettle_3.4.1.bb|  9 ++---
  3 files changed, 44 insertions(+), 24 deletions(-)
  create mode 100644 meta/recipes-support/nettle/nettle-3.4.1/0001-
nettle-pbkdf2.c-change-the-initialization-for-salt.patch
  delete mode 100644 meta/recipes-support/nettle/nettle-3.4.1/dlopen-
test.patch

diff --git a/meta/recipes-support/nettle/nettle-3.4.1/0001-nettle-
pbkdf2.c-change-the-initialization-for-salt.patch b/meta/recipes-
support/nettle/nettle-3.4.1/0001-nettle-pbkdf2.c-change-the-
initialization-for-salt.patch
new file mode 100644
index 000..713823e
--- /dev/null
+++ b/meta/recipes-support/nettle/nettle-3.4.1/0001-nettle-pbkdf2.c-
change-the-initialization-for-salt.patch
@@ -0,0 +1,39 @@
+From 7510ee2877368464ecce7de515ce056e08c75245 Mon Sep 17 00:00:00
2001
+From: Mingli Yu 
+Date: Fri, 12 Apr 2019 10:30:14 +0800
+Subject: [PATCH] nettle-pbkdf2.c: change the initialization for salt
+
+use malloc and strncpy altogether to replace
+strdup for salt initialization to fix below
+Segmentation fault:
+ # echo -n passwd| nettle-pbkdf2 -i 1 -l 16 salt
+ [65534.886509] nettle-pbkdf2[708]: segfault at 1f594260 ip
7f3332256998 sp 7fff60d44410 error 4 in
libnettle.so.6.5[7f3332244000+1d00]
+ [65534.887525] Code: e8 6d db fe ff 44 01 6d 68 48 83 c4 08 5b 5d
41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 49 89 dc e9
68 ff f
+ Segmentation fault
+
+Upstream-Status: Submitted[
http://lists.lysator.liu.se/pipermail/nettle-bugs/2019/007467.html]
+
+Signed-off-by: Mingli Yu 
+---
+ tools/nettle-pbkdf2.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/tools/nettle-pbkdf2.c b/tools/nettle-pbkdf2.c
+index 1f0a301..000acd3 100644
+--- a/tools/nettle-pbkdf2.c
 b/tools/nettle-pbkdf2.c
+@@ -141,7 +141,10 @@ main (int argc, char **argv)
+   return EXIT_FAILURE;
+ }
+
+-  salt = strdup (argv[0]);
++  salt = malloc (strlen(argv[0]) + 1);
++  if (! salt)
++ die ("Failed to allocate memory for salt\n");
++  strncpy(salt, argv[0], sizeof(salt) - 1);
+   salt_length = strlen(argv[0]);
+
+   if (hex_salt)
+--
+2.7.4
+
diff --git a/meta/recipes-support/nettle/nettle-3.4.1/dlopen-
test.patch b/meta/recipes-support/nettle/nettle-3.4.1/dlopen-
test.patch
deleted file mode 100644
index c4f0b7e..000
--- a/meta/recipes-support/nettle/nettle-3.4.1/dlopen-test.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Replace relative path of libnettle.so with absolute path so the test
-program can find it.
-Relative paths are not suitable, as the folder strucure for ptest
-is different from the one expected by the nettle testsuite.
-
-Upstream-Status: Inappropriate [embedded specific]
-
-Signed-off-by: Juro Bystricky 
-
 a/testsuite/dlopen-test.c  2016-10-01 00:28:38.0
-0700
-+++ b/testsuite/dlopen-test.c  2017-10-13 11:08:57.227572860
-0700
-@@ -9,7 +9,7 @@
- main (int argc UNUSED, char **argv UNUSED)
- {
- #if HAVE_LIBDL
--  void *handle = dlopen ("../libnettle.so", RTLD_NOW);
-+  void *handle = dlopen ("/usr/lib/libnettle.so", RTLD_NOW);
-   int (*get_version)(void);
-   if (!handle)
- {
diff --git a/meta/recipes-support/nettle/nettle_3.4.1.bb
b/meta/recipes-support/nettle/nettle_3.4.1.bb
index dd49c30..612e058 100644
--- a/meta/recipes-support/nettle/nettle_3.4.1.bb
+++ b/meta/recipes-support/nettle/nettle_3.4.1.bb
@@ -14,12 +14,9 @@ SRC_URI = "${GNU_MIRROR}/${BPN}/${BP}.tar.gz \
 file://Add-target-to-only-build-tests-not-run-them.patch
\
 file://run-ptest \
 file://check-header-files-of-openssl-only-if-
enable_.patch \
+   file://0001-nettle-pbkdf2.c-change-the-initialization-
for-salt.patch \
 "

-SRC_URI_append_class-target = "\
-file://dlopen-test.patch \
-"
-
  SRC_URI[md5sum] = "9bdebb0e2f638d3b9d91f7fc264b70c1"
  SRC_URI[sha256sum] =
"f941cf1535cd5d1819be5ccae5babef01f6db611f9b5a777bae9c7604b8a92ad"

@@ -47,6 +44,10 @@ 

Re: [OE-core] [PATCH v2] nettle: fix ptest failure

[Yu, Mingli]

On 2019年04月15日 15:59, richard.pur...@linuxfoundation.org wrote:

On Mon, 2019-04-15 at 15:40 +0800, mingli...@windriver.com wrote:

 a/testsuite/dlopen-test.c  2016-10-01 00:28:38.0
-0700
-+++ b/testsuite/dlopen-test.c  2017-10-13 11:08:57.227572860
-0700
-@@ -9,7 +9,7 @@
+diff --git a/testsuite/dlopen-test.c b/testsuite/dlopen-test.c
+index 99d3535..92de9f8 100644
+--- a/testsuite/dlopen-test.c
 b/testsuite/dlopen-test.c
+@@ -9,7 +9,9 @@ int
   main (int argc UNUSED, char **argv UNUSED)
   {
   #if HAVE_LIBDL
  -  void *handle = dlopen ("../libnettle.so", RTLD_NOW);
  +  void *handle = dlopen ("/usr/lib/libnettle.so", RTLD_NOW);
++  if (!handle)
++ handle = dlopen ("/usr/lib64/libnettle.so", RTLD_NOW);
 int (*get_version)(void);
 if (!handle)
   {


What happens on a 32 bit system?

You can't hardcode a specific libdir like that!


I just rework the patch dlopen-test.patch which Juro Bystricky generated 
before, the previous patch only check /usr/lib/libnettle.so and I 
updated it also to check /usr/lib64/libnettle.so if no 
/usr/lib/libnettle.so exist.

 -  void *handle = dlopen ("../libnettle.so", RTLD_NOW);
 +  void *handle = dlopen ("/usr/lib/libnettle.so", RTLD_NOW);
++  if (!handle)
++ handle = dlopen ("/usr/lib64/libnettle.so", RTLD_NOW);


Thanks,



Cheers,

Richard



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

[Yu, Mingli]

On 2019年04月09日 11:53, Khem Raj wrote:

On Mon, Apr 8, 2019 at 7:32 PM  wrote:


From: Mingli Yu 

When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| 
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
 In function 'elf_is_symlink':
| 
../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
 error: 'st.st_mode' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
|   return S_ISLNK (st.st_mode);

Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html,
the gcc upstream thinks the warning is a false
positive and suggests to use -O2 rather than -Og
or -O1 when compiling that file, so pass -Wno-error
to compiler when -Og is used to silence the error.



Not particular to this change but in general if a package says that it
does not support -Og
then we are just going to get into more and more untested grounds
especially during runtime
so I wonder how useful it will be to use -Og for such packages or any
other non supported
combination for that matter.


Hi Khem,

Any other suggestion to silence the gcc-sanitizers build error when 
DEBUG_BUILD is enabled?


Or just keep the logic DEBUG_OPTIMIZATION_append = " -Wno-error" as my 
patch stated?


Thanks,




Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/gcc/gcc-sanitizers.inc | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc 
b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
index e5e8452..8b1d1c9 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
@@ -45,6 +45,9 @@ INHIBIT_DEFAULT_DEPS = "1"
  ALLOW_EMPTY_${PN} = "1"
  DEPENDS = "gcc-runtime virtual/${TARGET_PREFIX}gcc"

+# used to fix 
../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
 error: 'st.st_mode' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
+DEBUG_OPTIMIZATION_append = " -Wno-error"
+
  BBCLASSEXTEND = "nativesdk"

  PACKAGES = "${PN} ${PN}-dbg"
--
2.7.4




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

Re: [OE-core] [v2][PATCH] nettle: update to 3.4.1

[Yu, Mingli]

On 2019年01月06日 06:05, Armin Kuster wrote:

Bug fix only release

Include:

   CVE-2018-16868 gnutls: Bleichenbacher-like side channel leakage in
   PKCS#1 1.5 verification and padding oracle verification

   CVE-2018-16869 nettle: Leaky data conversion exposing a manager oracle

For full details see:
http://lists.lysator.liu.se/pipermail/nettle-bugs/2018/007369.html

[V2]
Add -std=c99 to cflags


When -std=c99 explicitly via cflags, there comes below Segmentation 
fault in runtime.

# echo -n passwd| nettle-pbkdf2 -i 1 -l 16 salt
[65534.886509] nettle-pbkdf2[708]: segfault at 1f594260 ip 
7f3332256998 sp 7fff60d44410 error 4 in 
libnettle.so.6.5[7f3332244000+1d00]
[65534.887525] Code: e8 6d db fe ff 44 01 6d 68 48 83 c4 08 5b 5d 41 5c 
41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 49 89 dc e9 68 ff f

Segmentation fault

# echo -n passwd > /tmp/passwd
# gdb nettle-pbkdf2
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-wrs-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from nettle-pbkdf2...Reading symbols from 
/usr/bin/.debug/nettle-pbkdf2...done.

done.
(gdb) run -i 1 -l 16 salt < /tmp/passwd
Starting program: /usr/bin/nettle-pbkdf2 -i 1 -l 16 salt < /tmp/passwd

Program received signal SIGSEGV, Segmentation fault.
nettle_sha256_update (ctx=0x7fffe5c0, length=,
data=0x9260 )
at ../nettle-3.4.1/sha256.c:99
99  ../nettle-3.4.1/sha256.c: No such file or directory.
(gdb) bt
#0  nettle_sha256_update (ctx=0x7fffe5c0, length=,
data=0x9260 )
at ../nettle-3.4.1/sha256.c:99
#1  0x77fa9bb6 in nettle_pbkdf2 
(mac_ctx=mac_ctx@entry=0x7fffe4e0,

update=0x77fa7cb0 ,
digest=0x77fa7cc0 ,
digest_size=digest_size@entry=32, iterations=iterations@entry=1,
salt_length=salt_length@entry=4,
salt=0x9260 ,
length=16, dst=0xa290 "") at ../nettle-3.4.1/pbkdf2.c:78
#2  0x77fa9dd3 in nettle_pbkdf2_hmac_sha256 (
key_length=, key=, iterations=1,
salt_length=4,
salt=0x9260 ,
length=16, dst=0xa290 "")
at ../nettle-3.4.1/pbkdf2-hmac-sha256.c:51
#3  0x544c in main (argc=, argv=)
at ../../nettle-3.4.1/tools/nettle-pbkdf2.c:167
(gdb)


After some investigation, it seems "salt = strdup (argv[0]);" doesn't 
works as expected in tools/nettle-pbkdf2.c when -std=c99 specified.
BTW, it works well if update salt = strdup (argv[0]); to the below logic 
even -std=c99 specified.


salt = malloc (strlen(argv[0]) + 1);
if (! salt)
   die ("Failed to allocate memory for salt\n");
strncpy(salt, argv[0], sizeof(salt) - 1);


And "salt = strdup (argv[0]);" works well if no -std=c99 specified.

Thanks,



Signed-off-by: Armin Kuster 
---
  .../Add-target-to-only-build-tests-not-run-them.patch| 0
  .../check-header-files-of-openssl-only-if-enable_.patch  | 0
  .../nettle/{nettle-3.4 => nettle-3.4.1}/dlopen-test.patch| 0
  meta/recipes-support/nettle/{nettle-3.4 => nettle-3.4.1}/run-ptest   | 0
  meta/recipes-support/nettle/{nettle_3.4.bb => nettle_3.4.1.bb}   | 5 +++--
  5 files changed, 3 insertions(+), 2 deletions(-)
  rename meta/recipes-support/nettle/{nettle-3.4 => 
nettle-3.4.1}/Add-target-to-only-build-tests-not-run-them.patch (100%)
  rename meta/recipes-support/nettle/{nettle-3.4 => 
nettle-3.4.1}/check-header-files-of-openssl-only-if-enable_.patch (100%)
  rename meta/recipes-support/nettle/{nettle-3.4 => 
nettle-3.4.1}/dlopen-test.patch (100%)
  rename meta/recipes-support/nettle/{nettle-3.4 => nettle-3.4.1}/run-ptest 
(100%)
  rename meta/recipes-support/nettle/{nettle_3.4.bb => nettle_3.4.1.bb} (90%)

diff --git 
a/meta/recipes-support/nettle/nettle-3.4/Add-target-to-only-build-tests-not-run-them.patch
 
b/meta/recipes-support/nettle/nettle-3.4.1/Add-target-to-only-build-tests-not-run-them.patch
similarity index 100%
rename from 
meta/recipes-support/nettle/nettle-3.4/Add-target-to-only-build-tests-not-run-them.patch
rename to 
meta/recipes-support/nettle/nettle-3.4.1/Add-target-to-only-build-tests-not-run-them.patch
diff --git 
a/meta/recipes-support/nettle/nettle-3.4/check-header-files-of-openssl-only-if-enable_.patch
 
b/meta/recipes-support/nettle/nettle-3.4.1/check-header-files-of-openssl-only-if-enable_.patch
similarity index 100%
rename from 

Re: [OE-core] [PATCH v2] nettle: fix ptest failure

[Yu, Mingli]

On 2019年04月15日 16:06, richard.pur...@linuxfoundation.org wrote:

On Mon, 2019-04-15 at 16:09 +0800, Yu, Mingli wrote:


On 2019年04月15日 15:59, richard.pur...@linuxfoundation.org wrote:

On Mon, 2019-04-15 at 15:40 +0800, mingli...@windriver.com wrote:

 a/testsuite/dlopen-test.c  2016-10-01 00:28:38.0
-0700
-+++ b/testsuite/dlopen-test.c  2017-10-13 11:08:57.227572860
-0700
-@@ -9,7 +9,7 @@
+diff --git a/testsuite/dlopen-test.c b/testsuite/dlopen-test.c
+index 99d3535..92de9f8 100644
+--- a/testsuite/dlopen-test.c
 b/testsuite/dlopen-test.c
+@@ -9,7 +9,9 @@ int
main (int argc UNUSED, char **argv UNUSED)
{
#if HAVE_LIBDL
   -  void *handle = dlopen ("../libnettle.so", RTLD_NOW);
   +  void *handle = dlopen ("/usr/lib/libnettle.so", RTLD_NOW);
++  if (!handle)
++ handle = dlopen ("/usr/lib64/libnettle.so", RTLD_NOW);
  int (*get_version)(void);
  if (!handle)
{


What happens on a 32 bit system?

You can't hardcode a specific libdir like that!


I just rework the patch dlopen-test.patch which Juro Bystricky
generated
before, the previous patch only check /usr/lib/libnettle.so and I
updated it also to check /usr/lib64/libnettle.so if no
/usr/lib/libnettle.so exist.
   -  void *handle = dlopen ("../libnettle.so", RTLD_NOW);
   +  void *handle = dlopen ("/usr/lib/libnettle.so", RTLD_NOW);
++  if (!handle)
++ handle = dlopen ("/usr/lib64/libnettle.so", RTLD_NOW);


What happens on x32? n32? or if I set libdir to lib32?


Got it! V3 is coming.



Cheers,

Richard





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

Re: [OE-core] [PATCH v3] nettle: fix ptest failure

[Yu, Mingli]

On 2019年04月15日 19:08, richard.pur...@linuxfoundation.org wrote:

On Mon, 2019-04-15 at 17:05 +0800, mingli...@windriver.com wrote:

@@ -33,6 +29,8 @@ EXTRA_OECONF = "--disable-openssl"
  CFLAGS_append = " -std=c99"

  do_compile_ptest() {
+# fix dlopen-test failure as cannot locate libnettle.so
+sed -i 's;dlopen ("../libnettle.so", RTLD_NOW);dlopen
("${libdir}/libnettle.so", RTLD_NOW);g' ${S}/testsuite/dlopen-test.c
  oe_runmake buildtest
  }

@@ -49,4 +47,7 @@ do_install_ptest() {
  install ${B}/testsuite/*-test ${D}${PTEST_PATH}/testsuite/
  }

+RDEPENDS_${PN}-ptest += "${PN}-dev"
+INSANE_SKIP_${PN}-ptest += "dev-deps"
+
  BBCLASSEXTEND = "native nativesdk"


Does Adrian's suggestion of removing the "../" work? Also, can we


Yes, the Adrian's suggestion works. But I think it's also okay to update 
the actual libnettle.so path in do_compile_ptest phase as we still need 
an extra patch if use Adrian's suggestion.



install a symlink in do_install_ptest which this code would find? That


Install a symlink? Does it means nettle-ptest will provide libnettle.so?
@@ -45,6 +49,7 @@ do_install_ptest() {
 # tools can be found in PATH, not in ../tools/
 sed -i -e 's|../tools/||' ${D}${PTEST_PATH}/testsuite/*-test
 install ${B}/testsuite/*-test ${D}${PTEST_PATH}/testsuite/
+ln -s ${libdir}/libnettle.so.6.5 ${D}${PTEST_PATH}/libnettle.so
 }



would be less invasive and we could potentially remove the -dev package
dependency which would be good from an image perspective.


Just nettle-ptest rdepends on nettle-dev.



Cheers,

Richard



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

Re: [OE-core] [PATCH v3] nettle: fix ptest failure

[Yu, Mingli]

Hi RP,

Any comments here?

Thanks,

On 2019年04月16日 11:14, Yu, Mingli wrote:



On 2019年04月15日 19:08, richard.pur...@linuxfoundation.org wrote:

On Mon, 2019-04-15 at 17:05 +0800, mingli...@windriver.com wrote:

@@ -33,6 +29,8 @@ EXTRA_OECONF = "--disable-openssl"
  CFLAGS_append = " -std=c99"

  do_compile_ptest() {
+# fix dlopen-test failure as cannot locate libnettle.so
+sed -i 's;dlopen ("../libnettle.so", RTLD_NOW);dlopen
("${libdir}/libnettle.so", RTLD_NOW);g' ${S}/testsuite/dlopen-test.c
  oe_runmake buildtest
  }

@@ -49,4 +47,7 @@ do_install_ptest() {
  install ${B}/testsuite/*-test ${D}${PTEST_PATH}/testsuite/
  }

+RDEPENDS_${PN}-ptest += "${PN}-dev"
+INSANE_SKIP_${PN}-ptest += "dev-deps"
+
  BBCLASSEXTEND = "native nativesdk"


Does Adrian's suggestion of removing the "../" work? Also, can we


Yes, the Adrian's suggestion works. But I think it's also okay to update
the actual libnettle.so path in do_compile_ptest phase as we still need
an extra patch if use Adrian's suggestion.


install a symlink in do_install_ptest which this code would find? That


Install a symlink? Does it means nettle-ptest will provide libnettle.so?
@@ -45,6 +49,7 @@ do_install_ptest() {
  # tools can be found in PATH, not in ../tools/
  sed -i -e 's|../tools/||' ${D}${PTEST_PATH}/testsuite/*-test
  install ${B}/testsuite/*-test ${D}${PTEST_PATH}/testsuite/
+ln -s ${libdir}/libnettle.so.6.5 ${D}${PTEST_PATH}/libnettle.so
  }



would be less invasive and we could potentially remove the -dev package
dependency which would be good from an image perspective.


Just nettle-ptest rdepends on nettle-dev.



Cheers,

Richard



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

[Yu, Mingli]

On 2019年04月17日 02:00, Khem Raj wrote:

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.


Hi Khem,

I don't quite get what you mean. Disable warning as errors?

As https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html, gcc 
upstream thinks the build error is meaningless when compile 
gcc-sanitizers with -Og and suggests not use -Og to compile for 
gcc-sanitizers.


So I send out the patch to add the workaround [DEBUG_OPTIMIZATION_append 
= " -Wno-error"] to silence the error when debug build is enabled for 
gcc-sanitizers.
If the workaround isn't suitable, then how to silence the 
-Werror=maybe-uninitialized issue build error when debug build enabled?


Thanks,





cu
Adrian




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

Re: [OE-core] [PATCH] elfutils: fix ptest failures

[Yu, Mingli]

On 2019年05月26日 04:16, richard.pur...@linuxfoundation.org wrote:

On Wed, 2019-05-22 at 17:11 +0800, mingli...@windriver.com wrote:

From: Mingli Yu 

* Add missing -ptest package dependencies (needs
   ${PN}-dbg)

* Add missing files which needed by ptest test
   to fix below failures:
   | ./run-ar.sh: line 23: cd:
/usr/lib64/elfutils/ptest/tests/..//src: No such file or directory
   | FAIL: run-ar.sh

   | sh: ../src/elflint: No such file or directory
   | FAIL: asm-tst4

* Rework 0001-skip-the-test-when-gcc-not-deployed.patch
   to skip the tests which depend on gcc

Before:

Recipe   | Passed| Failed   | Skipped

elfutils | 176   | 23   | 4


After:

Recipe   | Passed| Failed   | Skipped

elfutils | 184   | 15   | 4




Unfortunately if I add this to the build we see failures due to core-
image-sato-sdk-ptest becomming too large for generix86-64 as the image
exceeds the 4GB limit its FSTYPE allows.

I tried reducing the amount of free space in the image but then the
strace and until-linux ptests fail:

https://autobuilder.yocto.io/pub/non-release/20190524-8/testresults/testresult-report.txt

We do plan to change the hddimg format and use wic to avoid the 4GB
limit sometime in 2.8 but those patches aren't ready yet. I'm therefore
not quite sure what to do here. Is there any way we can save space in
the images so we could merge this?


It will be better if any space can be saved.



Wth regard to the src/ directory, I did wonder if there needed to be a
patch to one of the other scripts to use installed files (similar to
how I fixed some of these last time)?


Have checked your patch about new target oecheck. Anyway, I have 
narrowed down a little to copy only the needed files to src/ dir.


And I also send out v2 patch then which updated to fix all the tests.

Thanks,



Cheers,

Richard



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

Re: [OE-core] [PATCH v2] elfutils: fix ptest failures

[Yu, Mingli]

On 2019年05月28日 18:01, richard.pur...@linuxfoundation.org wrote:

On Tue, 2019-05-28 at 17:40 +0800, mingli...@windriver.com wrote:

From: Mingli Yu 

* Add missing -ptest package dependencies (needs
   ${PN}-dev)

* Add missing files which needed by ptest test
   to fix the ptest failures such as:
   | sh: ../src/elflint: No such file or directory
   | FAIL: asm-tst4

* Rework 0001-skip-the-test-when-gcc-not-deployed.patch
   to skip the tests which depend on gcc

* Don't split the -debug package for elfutils as
   most cases needs the binary to have .symtab.


Can you provide more details on what this last item means?


That means elfutils tests need the binary not stripped, so we need below 
logic:


INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"



Do you mean elfutils is generally broken without the symtab section?
That seems unusual? Or do you mean the tests need it to be present?


Not sure whether elfutils is broken, but at least it is broken with 
regard to test part. If strip the binary, the test result:


Recipe   | Passed| Failed   | Skipped

elfutils | 184   | 15| 4


And all the failed case as below is because the binary is stripped.


FAIL: test-nlist
FAIL: run-strip-reloc.sh
FAIL: run-strip-strmerge.sh
FAIL: run-nm-self.sh
FAIL: run-readelf-self.sh
FAIL: run-varlocs-self.sh
FAIL: run-exprlocs-self.sh
FAIL: run-backtrace-native.sh
FAIL: run-backtrace-data.sh
FAIL: run-backtrace-native-core.sh
FAIL: run-deleted.sh
FAIL: run-dwarf-die-addr-die.sh
FAIL: run-get-units-invalid.sh
FAIL: run-get-units-split.sh
FAIL: run-unit-info.sh

For the test-nlist, the upstream also said the binary cannot be stripped 
to guarantee the test pass as 
https://sourceware.org/ml/elfutils-devel/2019-q2/msg00098.html and 
https://sourceware.org/ml/elfutils-devel/2019-q2/msg00103.html



So to fix this kind of below failures, we need to make the binary not 
stripped.


runtest /usr/lib64/elfutils/ptest/tests/..//src/strip
/usr/bin/eu-readelf: cannot get debug context descriptor: No DWARF 
information found
*** failure readelf -w debugfile1 
/usr/lib64/elfutils/ptest/tests/..//src/strip
/usr/bin/eu-readelf: cannot get debug context descriptor: No DWARF 
information found
*** failure readelf -w debugfile2 
/usr/lib64/elfutils/ptest/tests/..//src/strip

runtest /usr/lib64/elfutils/ptest/tests/..//src/strip.o
runtest strip-uncompressed.o
runtest strip-compressed.o
runtest testfile-debug-rel-ppc64.o
runtest testfile-debug-rel-ppc64-z.o
runtest testfile-debug-rel-ppc64-g.o
FAIL: run-strip-reloc.sh

/usr/lib64/elfutils/ptest/tests/..//tests/elfstrmerge: 
/usr/lib64/elfutils/ptest/tests/..//tests/elfstrmerge: couldn't get 
symtab data: no error

FAIL: run-strip-strmerge.sh

/usr/bin/eu-nm: /usr/lib64/elfutils/ptest/tests/..//src/nm: no symbols
FAIL: run-nm-self.sh



Not striping the binary at all is likely to cause a significant size
increase for elfutils and we want to avoid that, particularly if its
only to fix tests. We will probably have to find a different solution
(e.g. second copy with the symtab section in the ptest package, added
to PATH in the runner?)


During my test, if we strip the debug info to elfutils-dbg, first we 
need to make elfutils-ptest rdepends on elfutils-dbg and second the test 
still fails as above even the elfutils-dbg package deployed as below:

# pwd
/usr/lib64/elfutils/ptest
root@qemux86-64:/usr/lib64/elfutils/ptest# ls src/strip
src/strip
root@qemux86-64:/usr/lib64/elfutils/ptest# ls src/.debug/strip
src/.debug/strip
/.debug/strip64:/usr/lib64/elfutils/ptest# rpm -qf 
/usr/lib64/elfutils/ptest/src/.debug/strip

elfutils-dbg-0.176-r0.core2_64

Thanks,



Cheers,

Richard





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

Re: [OE-core] [PATCH v4] elfutils: fix ptest failures

[Yu, Mingli]

On 2019年05月31日 04:49, richard.pur...@linuxfoundation.org wrote:

On Thu, 2019-05-30 at 14:11 +0800, mingli...@windriver.com wrote:

From: Mingli Yu 

* Add missing files which needed by ptest test
   to fix the ptest failures such as:
   | sh: ../src/elflint: No such file or directory
   | FAIL: asm-tst4

* Rework 0001-skip-the-test-when-gcc-not-deployed.patch
   to skip the tests which depend on gcc

* Define INHIBIT_PACKAGE_STRIP_FILES for elfutils to
   avoid stripping some generated binaries otherwise
   some of the tests such as test-nlist, run-strip-reloc.sh,
   run-strip-strmerge.sh and so on will fail

Before:

Recipe   | Passed| Failed   | Skipped

elfutils | 176   | 23   | 4


After:

Recipe   | Passed| Failed   | Skipped

elfutils | 199   | 0   | 4



Thanks, this is better again. We do still have a musl issue:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/648

Error:
  Problem: package packagegroup-core-full-cmdline-extended-1.0-r6.0.noarch 
requires iproute2, but none of the providers can be installed
   - package packagegroup-core-full-cmdline-1.0-r6.0.noarch requires 
packagegroup-core-full-cmdline-extended, but none of the providers can be 
installed
   - package iproute2-5.1.0-r0.0.core2_32 requires elfutils-ptest >= 0.176, but 
none of the providers can be installed
   - conflicting requests
   - nothing provides elfutils-binutils needed by 
elfutils-ptest-0.176-r0.0.core2_32
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)


I didn't encounter the failure during do_rootfs when "bitbake 
core-image-sato-sdk" with musl on qemux86.


Could you help to provide your local.conf?

Thanks,



Cheers,

Richard



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

Re: [OE-core] [PATCH v3] elfutils: fix ptest failures

[Yu, Mingli]

On 2019年05月30日 02:40, richard.pur...@linuxfoundation.org wrote:

On Wed, 2019-05-29 at 16:55 +0800, mingli...@windriver.com wrote:

From: Mingli Yu 

* Add missing -ptest package dependency (needs
   ${PN}-dev)

* Add missing files which needed by ptest test
   to fix the ptest failures such as:
   | sh: ../src/elflint: No such file or directory
   | FAIL: asm-tst4

* Rework 0001-skip-the-test-when-gcc-not-deployed.patch
   to skip the tests which depend on gcc

* Define INHIBIT_PACKAGE_STRIP_FILES for elfutils to
   avoid stripping some generated binaries otherwise
   some of the tests such as test-nlist, run-strip-reloc.sh,
   run-strip-strmerge.sh and so on will fail

Before:

Recipe   | Passed| Failed   | Skipped

elfutils | 176   | 23   | 4


After:

Recipe   | Passed| Failed   | Skipped

elfutils | 199   | 0   | 4


Signed-off-by: Mingli Yu 


I tested this without the libdir strip lines and it fails on musl:

https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/645


Will send out v4 to fix it.

Thanks,



Cheers,

Richard



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

Re: [OE-core] [PATCH v3] elfutils: fix ptest failures

[Yu, Mingli]

On 2019年05月29日 18:13, richard.pur...@linuxfoundation.org wrote:

On Wed, 2019-05-29 at 16:55 +0800, mingli...@windriver.com wrote:

From: Mingli Yu 

* Add missing -ptest package dependency (needs
   ${PN}-dev)

* Add missing files which needed by ptest test
   to fix the ptest failures such as:
   | sh: ../src/elflint: No such file or directory
   | FAIL: asm-tst4

* Rework 0001-skip-the-test-when-gcc-not-deployed.patch
   to skip the tests which depend on gcc

* Define INHIBIT_PACKAGE_STRIP_FILES for elfutils to
   avoid stripping some generated binaries otherwise
   some of the tests such as test-nlist, run-strip-reloc.sh,
   run-strip-strmerge.sh and so on will fail

Before:

Recipe   | Passed| Failed   | Skipped

elfutils | 176   | 23   | 4


After:

Recipe   | Passed| Failed   | Skipped

elfutils | 199   | 0   | 4


Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/elfutils/elfutils_0.176.bb   | 34 ++-
  .../0001-skip-the-test-when-gcc-not-deployed.patch | 38 +++---
  2 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
index 157551e..93d0c78 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
@@ -44,7 +44,7 @@ inherit autotools gettext ptest

  EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
  EXTRA_OECONF_append_class-native = " --without-bzlib"
-RDEPENDS_${PN}-ptest = "libasm libelf bash make coreutils ${PN}-binutils ${PN}"
+RDEPENDS_${PN}-ptest = "libasm libelf bash make coreutils ${PN}-binutils ${PN} 
${PN}-dev"

  EXTRA_OECONF_append_class-target += "--disable-tests-rpath"

@@ -61,6 +61,16 @@ do_compile_ptest() {

  do_install_ptest() {
if [ ${PTEST_ENABLED} = "1" ]; then
+   # copy the files which needed by the cases
+   TEST_FILES="strip strip.o addr2line elfcmp objdump readelf size.o 
nm.o nm elflint"
+   install -d -m 755   ${D}${PTEST_PATH}/src
+   install -d -m 755   ${D}${PTEST_PATH}/libelf
+   install -d -m 755   ${D}${PTEST_PATH}/libdw
+   for test_file in ${TEST_FILES}; do
+   cp -r ${B}/src/${test_file} ${D}${PTEST_PATH}/src
+   done
+   ln -s ${libdir}/libelf.so ${D}${PTEST_PATH}/libelf/libelf.so
+   ln -s ${libdir}/libdw.so ${D}${PTEST_PATH}/libdw/libdw.so
cp -r ${S}/tests/   ${D}${PTEST_PATH}
cp -r ${B}/tests/*  ${D}${PTEST_PATH}/tests
cp -r ${B}/config.h ${D}${PTEST_PATH}
@@ -109,3 +119,25 @@ FILES_libdw  = "${libdir}/libdw-${PV}.so 
${libdir}/libdw.so.* ${libdir}/elfutils

  # The package contains symlinks that trip up insane
  INSANE_SKIP_${MLPREFIX}libdw = "dev-so"
+INSANE_SKIP_${PN}-ptest += "dev-deps"
+
+# avoid stripping some generated binaries otherwise some of the tests such as 
test-nlist,
+# run-strip-reloc.sh, run-strip-strmerge.sh and so on will fail
+INHIBIT_PACKAGE_STRIP_FILES = "\
+${PKGD}${PTEST_PATH}/tests/test-nlist \
+${PKGD}${PTEST_PATH}/tests/elfstrmerge \
+${PKGD}${PTEST_PATH}/tests/backtrace-child \
+${PKGD}${PTEST_PATH}/tests/backtrace-data \
+${PKGD}${PTEST_PATH}/tests/deleted \
+${PKGD}${PTEST_PATH}/src/strip \
+${PKGD}${PTEST_PATH}/src/addr2line \
+${PKGD}${PTEST_PATH}/src/elfcmp \
+${PKGD}${PTEST_PATH}/src/objdump \
+${PKGD}${PTEST_PATH}/src/readelf \
+${PKGD}${PTEST_PATH}/src/nm \
+${PKGD}${PTEST_PATH}/src/elflint \
+${PKGD}${libdir}/libelf-${PV}.so \
+${PKGD}${libdir}/libdw-${PV}.so \


This looks better, except for the two libdir lines above. This will
inflate main image sizes just to make tests work :(.




We're going to need to fine another way to handle this as I'd imagine
the size increase is substancial.

It may be worth asking upstream whether they'd accept the tests using
the debug link mechanism we use to find extra symbol information?


Without the two libdir lines, most cases will fail. And even upstream 
changes to the debug link mechanism, we still need to make -ptest 
rdepends on -dbg. But I'm not sure upstream can make some move.


BTW, How about use the below solution? if so, all tests pass and we 
don't need -ptest rdepends on -dev and -dbg anyway. Will send out V4.


+ cp ${D}${libdir}/libelf-${PV}.so ${D}${PTEST_PATH}/libelf/libelf.so
+ cp ${D}${libdir}/libdw-${PV}.so ${D}${PTEST_PATH}/libdw/libdw.so

Thanks,



Cheers,

Richard



--

Re: [OE-core] OE-Core status with gcc9

[Yu, Mingli]

On 2019年05月27日 15:53, Khem Raj wrote:

On Sun, May 26, 2019 at 10:17 AM Khem Raj  wrote:


On Mon, May 13, 2019 at 8:39 PM Khem Raj  wrote:


On Sun, May 12, 2019 at 1:14 PM Khem Raj  wrote:


On Sun, May 12, 2019 at 6:21 AM Richard Purdie
 wrote:


I've run some tests and think we're now down to one remaining issue
with gcc 9:

https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/579
https://autobuilder.yoctoproject.org/typhoon/#/builders/55/builds/145



Assembler is not liking what gcc9 is generating

HOSTCC scripts/kconfig/conf.o
/tmp/ccnMW5be.s: Assembler messages:
/tmp/ccnMW5be.s: Internal error (Segmentation fault).

I wonder if its a common case or specific here?
I will try to reproduce it as well



I am able to get a .s file which crashes assembler on
qemu. Same file assembles ok with mips cross assembler
so next I want to get hold of a mips hardware and try
it on the real h/w, meanwhile if someone has easy access
to mips and can load core-image-sato-sdk on it then I can
provide the asm file which crashes assembler


got some more time to narrow it down.
works with musl+gcc-9
works with glibc+clang-8
works with musl+Clang-8

so only glibc+gcc-9 combo is one which exhibits the issue



I have sent a workaound for this which we can try out.
https://patchwork.openembedded.org/patch/161674/


Failed to build llvm with gcc9 for qemuppc as below:
| collect2: fatal error: ld terminated with signal 11 [Segmentation 
fault], core dumped


Thanks,




which is a kernel "make scripts" segfaulting on target on mips and
hence failing to build kernel modules. If we can get that one fixed
we're good from an OE-Core perspective to move to gcc 9.

I have to recognise the work Khem has put in getting us this close!

Cheers,

Richard


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

Re: [OE-core] [PATCH v5 06/13] go.bbclass: ptest cleanup and improvements

[Yu, Mingli]

Hi Matt,

I noticed your commit is the latest update for go-dep ptest. But the 
go-dep ptest doesn't work in my environment. I'm trying to figure out 
what's wrong is here though I didn't know much about go.


BTW, Could you help to check?

root@qemux86-64:~# cd /usr/lib64/go-dep/ptest/
root@qemux86-64:/usr/lib64/go-dep/ptest# cat run-ptest
#!/bin/sh
RC=0
run_test() (
cd "$1"
./$2 ; echo $? >&3) | sed -r -e"s,^(PASS|SKIP|FAIL)$,\1: 
$1/$2," >&4) 3>&1) | (read rc; exit $rc)) 4>&1

exit $?)
run_test github.com/golang/dep/cmd/dep dep.test || RC=1
exit $RC
root@qemux86-64:/usr/lib64/go-dep/ptest# ./run-ptest
building testdep failed: exit status 1
can't load package: package .: no Go files in 
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep

root@qemux86-64:/usr/lib64/go-dep/ptest#

Thanks,

On 2018年03月05日 05:09, Matt Madison wrote:

* Don't enable verbose test output (-test.v)
   by default, as it generates too much noise
   for automated results parsing

* Override do_install_ptest_base in the bbclass,
   so recipes can provide their own modifications
   with do_install_ptest.

* Improve the generated run-ptest script to better
   handle large numbers of tests, and to generate
   'status: test name' output similar to Automake
   tests.

* Install all non-vendored 'testdata' directories
   from the source into the ptest package, as some
   packages share test data among multiple tests.

Signed-off-by: Matt Madison 
---
  meta/classes/go.bbclass | 87 +
  1 file changed, 51 insertions(+), 36 deletions(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index afd68b5951..a51ba3e9f0 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -26,7 +26,7 @@ GO_LDFLAGS ?= '-ldflags="${GO_RPATH} ${GO_LINKMODE} 
-extldflags '${GO_EXTLDFLAGS
  export GOBUILDFLAGS ?= "-v ${GO_LDFLAGS}"
  export GOPATH_OMIT_IN_ACTIONID ?= "1"
  export GOPTESTBUILDFLAGS ?= "${GOBUILDFLAGS} -c"
-export GOPTESTFLAGS ?= "-test.v"
+export GOPTESTFLAGS ?= ""
  GOBUILDFLAGS_prepend_task-compile = "${GO_PARALLEL_BUILD} "

  export GO = "${HOST_PREFIX}go"
@@ -76,7 +76,7 @@ go_list_packages() {
  }

  go_list_package_tests() {
-${GO} list -f '{{.ImportPath}} {{.TestGoFiles}}' ${GOBUILDFLAGS} 
${GO_INSTALL} | \
+   ${GO} list -f '{{.ImportPath}} {{.TestGoFiles}}' ${GOBUILDFLAGS} 
${GO_INSTALL} | \
grep -v '\[\]$' | \
egrep -v '${GO_INSTALL_FILTEROUT}' | \
awk '{ print $1 }'
@@ -100,15 +100,16 @@ go_do_compile() {
  do_compile[dirs] =+ "${GOTMPDIR}"
  do_compile[cleandirs] = "${B}/bin ${B}/pkg"

-do_compile_ptest() {
+do_compile_ptest_base() {
export TMPDIR="${GOTMPDIR}"
-rm -f ${B}/.go_compiled_tests.list
+   rm -f ${B}/.go_compiled_tests.list
go_list_package_tests | while read pkg; do
cd ${B}/src/$pkg
${GO} test ${GOPTESTBUILDFLAGS} $pkg
find . -mindepth 1 -maxdepth 1 -type f -name '*.test' -exec 
echo $pkg/{} \; | \
sed -e's,/\./,/,'>> ${B}/.go_compiled_tests.list
done
+   do_compile_ptest
  }
  do_compile_ptest_base[dirs] =+ "${GOTMPDIR}"

@@ -124,40 +125,54 @@ go_do_install() {
fi
  }

-do_install_ptest_base() {
-test -f "${B}/.go_compiled_tests.list" || exit 0
-tests=""
-while read test; do
-tests="$tests${tests:+ }${test%.test}"
-testdir=`dirname $test`
-install -d ${D}${PTEST_PATH}/$testdir
-install -m 0755 ${B}/src/$test ${D}${PTEST_PATH}/$test
-if [ -d "${B}/src/$testdir/testdata" ]; then
-cp --preserve=mode,timestamps -R "${B}/src/$testdir/testdata" 
${D}${PTEST_PATH}/$testdir
-fi
-done < ${B}/.go_compiled_tests.list
-if [ -n "$tests" ]; then
-install -d ${D}${PTEST_PATH}
-cat >${D}${PTEST_PATH}/run-ptest <${D}${PTEST_PATH}/run-ptest <&1; then
-ANYFAILED=1
-fi
-done
-if [ \$ANYFAILED -ne 0 ]; then
-echo "FAIL: ${PN}"
-exit 1
-fi
-echo "PASS: ${PN}"
-exit 0
+RC=0
+run_test() (
+cd "\$1"
+./\$2 ${GOPTESTFLAGS}; echo \$? >&3) | sed -r -e"s,^(PASS|SKIP|FAIL)\$,\\1: \$1/\$2," 
>&4) 3>&1) | (read rc; exit \$rc)) 4>&1
+exit \$?)
  EOF
-chmod +x ${D}${PTEST_PATH}/run-ptest
-else
-rm -rf ${D}${PTEST_PATH}
-fi
+
+}
+
+go_stage_testdata() {
+   oldwd="$PWD"
+   cd ${S}/src
+   find ${GO_IMPORT} -depth -type d -name testdata | while read d; do
+   if echo "$d" | grep -q '/vendor/'; then
+   continue
+   fi
+   parent=`dirname $d`
+   install -d ${D}${PTEST_PATH}/$parent
+   cp --preserve=mode,timestamps -R $d ${D}${PTEST_PATH}/$parent/
+   done
+   cd "$oldwd"
+}
+
+do_install_ptest_base() {
+   test -f "${B}/.go_compiled_tests.list" || exit 0
+   install -d ${D}${PTEST_PATH}
+   go_stage_testdata
+   

Re: [OE-core] [PATCH v3] glib-2.0: fix ptest failures

[Yu, Mingli]

On 2019年05月08日 20:25, richard.pur...@linuxfoundation.org wrote:

On Wed, 2019-05-08 at 12:54 +0100, Burton, Ross wrote:

On Wed, 8 May 2019 at 04:06,  wrote:

* Increase the timeout to 15 minutes as the default
   timeout which is 5 minutes is not enough to fix below error:
   | Executing: glib/actions.test
   | Test timed out after 300 seconds
   | cleaning up pid 13050
   | FAIL: glib/actions.test (Child process killed by signal 9)


My Debian machine runs that test in 20 seconds.

Maybe we're missing dependencies to get a working session dbus up?


That seems likely. I'd note that we see:

https://autobuilder.yocto.io/pub/non-release/20190502-12/testresults/testresult-report.txt


Recipe   | Passed  | Failed   | Skipped   | Time(s)
glib-2.0 | 290 | 1| 0 | 427

and the failing test is:

 ptestresult.glib-2.0.glib/gdatetime.test__Child_process_killed_by_signal_6_

so it would seem this is working on our autobuilder tests? That would
seem to back up Ross' comments.


Thanks Ross and RP's comments!

It's weird! Seems it succeeds in autobuilder, but I can reproduce the 
glib/actions.test failure steadily in my env as below:

# time; /usr/libexec/installed-tests/glib/actions -p;time
user0m0.13s
sys 0m0.07s
/actions/dbus/threaded: OK
user6m29.03s
sys 0m50.46s

Thanks,



Cheers,

Richard



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

Re: [OE-core] [PATCH v3] glib-2.0: fix ptest failures

[Yu, Mingli]

On 2019年05月13日 17:40, richard.pur...@linuxfoundation.org wrote:

On Mon, 2019-05-13 at 17:25 +0800, Yu, Mingli wrote:


On 2019年05月08日 20:25, richard.pur...@linuxfoundation.org wrote:

On Wed, 2019-05-08 at 12:54 +0100, Burton, Ross wrote:

On Wed, 8 May 2019 at 04:06,  wrote:

* Increase the timeout to 15 minutes as the default
timeout which is 5 minutes is not enough to fix below error:
| Executing: glib/actions.test
| Test timed out after 300 seconds
| cleaning up pid 13050
| FAIL: glib/actions.test (Child process killed by signal 9)


My Debian machine runs that test in 20 seconds.

Maybe we're missing dependencies to get a working session dbus
up?


That seems likely. I'd note that we see:

https://autobuilder.yocto.io/pub/non-release/20190502-12/testresults/testresult-report.txt


Recipe   | Passed  | Failed   | Skipped   |
Time(s)
glib-2.0 | 290 | 1| 0 |
427

and the failing test is:

  ptestresult.glib-
2.0.glib/gdatetime.test__Child_process_killed_by_signal_6_

so it would seem this is working on our autobuilder tests? That
would
seem to back up Ross' comments.


Thanks Ross and RP's comments!

It's weird! Seems it succeeds in autobuilder, but I can reproduce
the
glib/actions.test failure steadily in my env as below:
# time; /usr/libexec/installed-tests/glib/actions -p;time
user0m0.13s
sys 0m0.07s
/actions/dbus/threaded: OK
user6m29.03s
sys 0m50.46s


I suspect its a dependency such as the dbus session Ross mentioned.
Which image are you running this test in? Have you tried testing in
something like a core-image-sato for comparison?


Use core-image-sato to test in my env as below and still 
/actions/dbus/threaded takes most of the time.


# time; /usr/libexec/installed-tests/glib/actions -p;time
user0m0.20s
sys 0m0.09s
/actions/basic: OK
/actions/name: OK
/actions/simplegroup: OK
/actions/stateful: OK
/actions/default-activate: OK
/actions/entries: OK
/actions/parse-detailed: OK
/actions/property: OK
/actions/dbus/export: OK
/actions/dbus/threaded: OK
/actions/dbus/bug679509: OK
user6m29.77s
sys 0m48.97s

Thanks,



It would be good to narrow down the missing dependency.

Cheers,

Richard



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

Re: [OE-core] [PATCH v4 1/2] nettle: fix the Segmentation fault

[Yu, Mingli]

Ping.

Thanks,

On 2019年04月24日 16:41, mingli...@windriver.com wrote:

From: Mingli Yu 

The commit[8ac8fa8ee1 nettle: update to 3.4.1]
add CFLAGS_append = " -std=c99" to silence the
below error for native build:
| ../nettle-3.4.1/rsa-sign-tr.c: In function 'sec_equal':
| ../nettle-3.4.1/rsa-sign-tr.c:243:3: error: 'for' loop initial declarations 
are only allowed in C99 mode
for (size_t i = 0; i < limbs; i++)
^
| ../nettle-3.4.1/rsa-sign-tr.c:243:3: note: use option -std=c99 or -std=gnu99 
to compile your code
| Makefile:263: recipe for target 'rsa-sign-tr.o' failed

But the above change will trigger below Segmentation
fault:
  # echo -n passwd| nettle-pbkdf2 -i 1 -l 16 salt
  [65534.886509] nettle-pbkdf2[708]: segfault at 1f594260 ip 7f3332256998 
sp 7fff60d44410 error 4 in libnettle.so.6.5[7f3332244000+1d00]
  [65534.887525] Code: e8 6d db fe ff 44 01 6d 68 48 83 c4 08 5b 5d 41 5c 41 5d 
41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 49 89 dc e9 68 ff f
  Segmentation fault

So update the logic to CFLAGS_append = " -std=gnu99"
to fix the issue.

Signed-off-by: Mingli Yu 
---
  meta/recipes-support/nettle/nettle_3.4.1.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/nettle/nettle_3.4.1.bb 
b/meta/recipes-support/nettle/nettle_3.4.1.bb
index dd49c30..8375fcf 100644
--- a/meta/recipes-support/nettle/nettle_3.4.1.bb
+++ b/meta/recipes-support/nettle/nettle_3.4.1.bb
@@ -30,7 +30,7 @@ inherit autotools ptest multilib_header
  EXTRA_AUTORECONF += "--exclude=aclocal"

  EXTRA_OECONF = "--disable-openssl"
-CFLAGS_append = " -std=c99"
+CFLAGS_append = " -std=gnu99"

  do_compile_ptest() {
  oe_runmake buildtest


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

Re: [OE-core] [PATCH v2] glib-2.0: fix ptest failures

[Yu, Mingli]

On 2019年05月06日 17:50, Adrian Bunk wrote:

On Sun, May 05, 2019 at 02:09:49PM +0800, Yu, Mingli wrote:

On 2019年04月30日 21:16, Burton, Ross wrote:

On Tue, 30 Apr 2019 at 08:45,  wrote:

...

* Increase the timeout to 15 minutes as the default
timeout which is 5 minutes is not enough to fix below error:
| Executing: glib/actions.test
| Test timed out after 300 seconds
| cleaning up pid 13050
| FAIL: glib/actions.test (Child process killed by signal 9)


Looks like we're working around a test case that is going to fail
because it is timing out.  Let's investigate why it is taking so long
instead.


The sub-case named test_dbus_threaded[/actions/dbus/threaded] of
glib/actions.test takes almost most of the time, the more details as below.
...


On what hardware it this?



Hi Adrian,

I run the test in qemu and the resource info for the qemu target as below:

# time; /usr/libexec/installed-tests/glib/actions -p;time
user0m0.11s
sys 0m0.03s
/actions/dbus/threaded: OK
user6m21.03s
sys 0m45.91s


# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz
stepping: 11
cpu MHz : 3192.391
cache size  : 16384 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 clflush acpi mmx fxsr sse sse2 ss syscall nx lm constant_tsc rep_gi

bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips: 6384.78
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:


# cat /proc/meminfo
MemTotal:3071748 kB
MemFree: 2899224 kB
MemAvailable:2917468 kB
Buffers:5044 kB
Cached:49976 kB
SwapCached:0 kB
Active:94872 kB
Inactive:  35160 kB
Active(anon):  75484 kB
Inactive(anon): 8428 kB
Active(file):  19388 kB
Inactive(file):26732 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal: 0 kB
SwapFree:  0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 75008 kB
Mapped:23808 kB
Shmem:  8904 kB
KReclaimable:  14436 kB
Slab:  27836 kB
SReclaimable:  14436 kB
SUnreclaim:13400 kB
KernelStack:1360 kB
PageTables:  976 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 1535872 kB
Committed_AS: 181504 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
Percpu:  296 kB
DirectMap4k:   30576 kB
DirectMap2M: 3115008 kB

Thanks,



cu
Adrian


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

Re: [OE-core] [PATCH v2] bjam-native: do not search all PATHs variable

[Yu, Mingli]

On 2019年04月28日 18:55, Richard Purdie wrote:

On Sun, 2019-04-28 at 11:38 +0200, Alexander Kanavin wrote:

Wait, why is this a problem for specifically bjam, but not the other
tools that also look into PATH? Shouldn’t you fix the nfs instead?


I have to agree that you really don't want invalids NFS paths in PATH.
We're not carrying a patch for that.



Thanks RP and Alex's comments!

It makes sense, the patch is inappropriate.

Thanks,



Cheers,

Richard


Alex


On 28 Apr 2019, at 9.02,  <
mingli...@windriver.com> wrote:

From: Li Wang 

By default, it searches all paths specified by $PATH.

But if the directory of the $PATH variable on
build host includes nfs(build host as nfs client),
it causes the build hung when the nfs server is
unavailable.

Signed-off-by: Li Wang 
Signed-off-by: Mingli Yu 
---
meta/recipes-support/boost/bjam-native_1.69.0.bb   |  1 +
.../bjam-do-not-search-all-PATHs-varibale.patch| 53
++
2 files changed, 54 insertions(+)
create mode 100644 meta/recipes-support/boost/files/bjam-do-not-
search-all-PATHs-varibale.patch

diff --git a/meta/recipes-support/boost/bjam-native_1.69.0.bb
b/meta/recipes-support/boost/bjam-native_1.69.0.bb
index 94f96e6..395ad34 100644
--- a/meta/recipes-support/boost/bjam-native_1.69.0.bb
+++ b/meta/recipes-support/boost/bjam-native_1.69.0.bb
@@ -6,6 +6,7 @@ SECTION = "devel"
inherit native

SRC_URI += "file://bjam-native-build-bjam.debug.patch \
+file://bjam-do-not-search-all-PATHs-varibale.patch \
"

do_compile() {
diff --git a/meta/recipes-support/boost/files/bjam-do-not-search-
all-PATHs-varibale.patch b/meta/recipes-support/boost/files/bjam-
do-not-search-all-PATHs-varibale.patch
new file mode 100644
index 000..742603a
--- /dev/null
+++ b/meta/recipes-support/boost/files/bjam-do-not-search-all-
PATHs-varibale.patch
@@ -0,0 +1,53 @@
+bjam: do not search all PATHs varibale
+
+By default, it searches all paths specified by $PATH.
+But if the directory of the $PATH variable on
+build host includes nfs, it causes system hung
+when nfs server is unavailable.
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Li Wang 
+Signed-off-by: Mingli Yu 
+---
+ tools/build/src/engine/build.jam | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/tools/build/src/engine/build.jam
b/tools/build/src/engine/build.jam
+index a92b70f..f866619 100644
+--- a/tools/build/src/engine/build.jam
 b/tools/build/src/engine/build.jam
+@@ -781,8 +781,8 @@ if $(OS) = NT
+ }
+ SUFEXE ?= "" ;
+
+-yacc ?= [ GLOB $(PATH) : yacc$(SUFEXE) ] ;
+-yacc ?= [ GLOB $(PATH) : bison$(SUFEXE) ] ;
++yacc ?= [ GLOB "" : yacc$(SUFEXE) ] ;
++yacc ?= [ GLOB "" : bison$(SUFEXE) ] ;
+ yacc ?= [ GLOB "$(ProgramFiles:J= )\\GnuWin32\\bin"
+ "C:\\Program Files\\GnuWin32\\bin" : bison$(SUFEXE) ] ;
+ yacc = $(yacc[1]) ;
+@@ -966,7 +966,7 @@ if $(OS) = NT
+ }
+ if $(UNIX) = true
+ {
+-tar ?= [ GLOB $(PATH) : star bsdtar tar ] ;
++tar ?= [ GLOB "" : star bsdtar tar ] ;
+ tar = $(tar[1]) ;
+ switch $(tar:D=:S=)
+ {
+@@ -1047,8 +1047,8 @@ rule .package ( dst-dir : src-files + )
+ }
+
+ # RPM distro file.
+-rpm-tool = [ GLOB $(PATH) : "rpmbuild" ] ;
+-rpm-tool ?= [ GLOB $(PATH) : "rpm" ] ;
++rpm-tool = [ GLOB "" : "rpmbuild" ] ;
++rpm-tool ?= [ GLOB "" : "rpm" ] ;
+ rpm-tool = $(rpm-tool[1]) ;
+ rule .rpm ( name : source )
+ {
+--
+2.18.1
+
--
2.7.4

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




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

Re: [OE-core] [PATCH v2] glib-2.0: fix ptest failures

[Yu, Mingli]

On 2019年04月30日 21:16, Burton, Ross wrote:

On Tue, 30 Apr 2019 at 08:45,  wrote:

From: Mingli Yu 

* Install 7 translation packages to fix 7 ptest
   failures such as:
   | GLib:ERROR:../glib-2.58.3/glib/tests/gdatetime.c:1477:test_non_utf8_printf: assertion failed (__p == 
("10\346\234\210")): ("Oct" == "10\346\234\210")
   | GLib:ERROR:../glib-2.58.3/glib/tests/gdatetime.c:1716:test_month_names: assertion failed 
(p_casefold == (o_casefold)): ("nov" == "stu")
   | GLib:ERROR:../glib-2.58.3/glib/tests/gdatetime.c:1731:test_month_names: assertion failed 
(p_casefold == (o_casefold)): ("jul" == "liep.")


Would be better if we had a meta-package to install 'all
translations', but we don't.





* Increase the timeout to 15 minutes as the default
   timeout which is 5 minutes is not enough to fix below error:
   | Executing: glib/actions.test
   | Test timed out after 300 seconds
   | cleaning up pid 13050
   | FAIL: glib/actions.test (Child process killed by signal 9)


Looks like we're working around a test case that is going to fail
because it is timing out.  Let's investigate why it is taking so long
instead.


The sub-case named test_dbus_threaded[/actions/dbus/threaded] of 
glib/actions.test takes almost most of the time, the more details as below.


# time; /usr/libexec/installed-tests/glib/actions -p;time

user0m58.87s

sys 0m16.89s

/actions/basic: OK

/actions/name: OK

/actions/simplegroup: OK

/actions/stateful: OK

/actions/default-activate: OK

/actions/entries: OK

/actions/parse-detailed: OK

/actions/property: OK

/actions/dbus/export: OK

/actions/dbus/threaded: OK

/actions/dbus/bug679509: OK

user11m37.67
s
sys 2m20.77s



# time; /usr/libexec/installed-tests/glib/actions -p; time
user0m0.11s
sys 0m0.05s
/actions/dbus/threaded: OK
user6m32.04s
sys 0m55.54s


About the /actions/dbus/threaded,  check 
https://gitlab.gnome.org/GNOME/glib/blob/master/gio/tests/actions.c#L918 
for more details.



# gnome-desktop-testing-runner --help
Usage:
  gnome-desktop-testing-runner [OPTION?] [PREFIX...] - Run installed tests
[snip]
-t, --timeout=TIMEOUT   Cancel test after timeout seconds; defaults 
to 5 minutes

[snip]


If use gnome-desktop-testing-runner to run all the glib-2.0 test, we 
should guarantee all the tests have enough time to run and I don't think 
the below logic is a workaround, we should increase the timeout if use 
gnome-desktop-testing-runner.


-su glib2-test -c gnome-desktop-testing-runner glib
+su glib2-test -c "gnome-desktop-testing-runner glib -t 900"

Thanks,




* There are 240+ ptest cases for glib-2.0 and one
   case is gdatetime.test. And there are 53 sub-cases
   under gdatetime.test.

   Among of the 53 sub-cases of gdatetime.test, there
   is one sub-case named test_month_names.

   For test_month_names case, there are also 64 cases
   against it. Comment 2 cases of test_month_names
   as a workaround to fix the below test_month_names
   failure as the issue also exists in the latest version:
   | GLib:ERROR:../glib-2.60.1/glib/tests
   /gdatetime.c:1702:test_month_names: assertion failed (p_casefold == (o_casefold)): 
("\316\261\317\205\316\263" == "\316\261\317\215\316\263")
   | GLib:ERROR:../glib-2.60.1/glib/tests/gdatetime.c:1765:test_month_names: assertion failed 
(p_casefold == (o_casefold)): ("\320\274\320\260\321\217" == 
"\320\274\320\260\320\271")

   Have reported the above issues to upstream as
   https://gitlab.gnome.org/GNOME/glib/issues/1759
   and as the failure even exists on the latest version 2.60.1
   until now, so comment it as a workaround until the
   upstream fixs it.


The test is failing and we don't know why, so it should continue to
fail.  We don't get to 100% pass rate by disabling every test that
fails.

Can you drop the timeout and datetime test removal, leaving just the
translation additions?

Ross


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

Re: [OE-core] [PATCH v5 06/13] go.bbclass: ptest cleanup and improvements

[Yu, Mingli]

On 2019年06月25日 20:23, Matt Madison wrote:

On Fri, Jun 21, 2019 at 2:08 AM Yu, Mingli  wrote:


Hi Matt,

I noticed your commit is the latest update for go-dep ptest. But the
go-dep ptest doesn't work in my environment. I'm trying to figure out
what's wrong is here though I didn't know much about go.


I went back over the commits, and I don't think I did anything with
go-dep specifically. I can see that the tests are failing for it, and
it looks like it's because go-dep's test programs make some
assumptions about the environment.  For one thing, it needs the go
compiler installed. It also looks like it's expecting some source
files to be present... in other words, it's not really designed for a
cross-build setup, with tests run on the cross-built target. It could
be messy to work around that, and I'm not sure how useful it would be
anyway, seeing as how go-dep is more of a build tool.  Might be better
to just disable ptests for it completely.


Many thanks Matt for your information!
Did you ever run go-dep ptest?
Go through the run-ptest script for go-dep, it actually runs the 
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose 
source file is 
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go.


# pwd
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep
# ./dep.test
building testdep failed: exit status 1
can't load package: package .: no Go files in 
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep


Check the logic for 
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go, it try to 
run "go build -o testdep" at its start. And the go compiler exist on our 
target, but I don't know what go files the dep_test.go expects.


Hi Khem,

Do you have any suggestion?

Thanks,



BTW, you can have the test programs generate verbose output by setting
GOPTESTFLAGS = "-test.v" in the recipe, which will add that flag to
their invocation in the wrapper script, or by manually running the
test program on the target and passing that flag (cd into the
directory where the test program is located, then run it with
-test.v).

Regards,
-Matt



BTW, Could you help to check?

root@qemux86-64:~# cd /usr/lib64/go-dep/ptest/
root@qemux86-64:/usr/lib64/go-dep/ptest# cat run-ptest
#!/bin/sh
RC=0
run_test() (
  cd "$1"
  ./$2 ; echo $? >&3) | sed -r -e"s,^(PASS|SKIP|FAIL)$,\1:
$1/$2," >&4) 3>&1) | (read rc; exit $rc)) 4>&1
  exit $?)
run_test github.com/golang/dep/cmd/dep dep.test || RC=1
exit $RC
root@qemux86-64:/usr/lib64/go-dep/ptest# ./run-ptest
building testdep failed: exit status 1
can't load package: package .: no Go files in
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep
root@qemux86-64:/usr/lib64/go-dep/ptest#

Thanks,

On 2018年03月05日 05:09, Matt Madison wrote:

* Don't enable verbose test output (-test.v)
by default, as it generates too much noise
for automated results parsing

* Override do_install_ptest_base in the bbclass,
so recipes can provide their own modifications
with do_install_ptest.

* Improve the generated run-ptest script to better
handle large numbers of tests, and to generate
'status: test name' output similar to Automake
tests.

* Install all non-vendored 'testdata' directories
from the source into the ptest package, as some
packages share test data among multiple tests.

Signed-off-by: Matt Madison 
---
   meta/classes/go.bbclass | 87 
+
   1 file changed, 51 insertions(+), 36 deletions(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index afd68b5951..a51ba3e9f0 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -26,7 +26,7 @@ GO_LDFLAGS ?= '-ldflags="${GO_RPATH} ${GO_LINKMODE} 
-extldflags '${GO_EXTLDFLAGS
   export GOBUILDFLAGS ?= "-v ${GO_LDFLAGS}"
   export GOPATH_OMIT_IN_ACTIONID ?= "1"
   export GOPTESTBUILDFLAGS ?= "${GOBUILDFLAGS} -c"
-export GOPTESTFLAGS ?= "-test.v"
+export GOPTESTFLAGS ?= ""
   GOBUILDFLAGS_prepend_task-compile = "${GO_PARALLEL_BUILD} "

   export GO = "${HOST_PREFIX}go"
@@ -76,7 +76,7 @@ go_list_packages() {
   }

   go_list_package_tests() {
-${GO} list -f '{{.ImportPath}} {{.TestGoFiles}}' ${GOBUILDFLAGS} 
${GO_INSTALL} | \
+ ${GO} list -f '{{.ImportPath}} {{.TestGoFiles}}' ${GOBUILDFLAGS} 
${GO_INSTALL} | \
   grep -v '\[\]$' | \
   egrep -v '${GO_INSTALL_FILTEROUT}' | \
   awk '{ print $1 }'
@@ -100,15 +100,16 @@ go_do_compile() {
   do_compile[dirs] =+ "${GOTMPDIR}"
   do_compile[cleandirs] = "${B}/bin ${B}/pkg"

-do_compile_ptest() {
+do_compile_ptest_base() {
   export TMPDIR="${GOTMPDIR}"
-rm -f ${B}/.go_compiled_tests.list
+ rm -f ${B}/.go_compiled_tests.list
   go_list_package_tests | while read pkg; do
   cd ${B}/src/$pkg
  

Re: [OE-core] [PATCH v5 06/13] go.bbclass: ptest cleanup and improvements

[Yu, Mingli]

On 2019年06月27日 19:34, Matt Madison wrote:

On Wed, Jun 26, 2019 at 11:40 PM Yu, Mingli  wrote:




On 2019年06月26日 22:00, Matt Madison wrote:

On Wed, Jun 26, 2019 at 2:02 AM Yu, Mingli  wrote:




On 2019年06月25日 20:23, Matt Madison wrote:

On Fri, Jun 21, 2019 at 2:08 AM Yu, Mingli  wrote:


Hi Matt,

I noticed your commit is the latest update for go-dep ptest. But the
go-dep ptest doesn't work in my environment. I'm trying to figure out
what's wrong is here though I didn't know much about go.


I went back over the commits, and I don't think I did anything with
go-dep specifically. I can see that the tests are failing for it, and
it looks like it's because go-dep's test programs make some
assumptions about the environment.  For one thing, it needs the go
compiler installed. It also looks like it's expecting some source
files to be present... in other words, it's not really designed for a
cross-build setup, with tests run on the cross-built target. It could
be messy to work around that, and I'm not sure how useful it would be
anyway, seeing as how go-dep is more of a build tool.  Might be better
to just disable ptests for it completely.


Many thanks Matt for your information!
Did you ever run go-dep ptest?
Go through the run-ptest script for go-dep, it actually runs the
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose
source file is
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go.


Yes, I see that.  That main program starts by rebuilding the dep
program from source, then runs the tests using that copy of the
program, so it's assuming that you're still in a development
environment where you can run a full go build.  That's what I meant by
it not being designed for a cross-build setup.

I've patched the test program to create a symlink to the installed dep
program instead of rebuilding, and got further.  You'll need to
include 'go', 'git', and 'git-perltools' in the image to get the tests
to run. Some of the test cases failed until I set GOCACHE in the
environment to point to a valid path; I'm not sure why.  The tests
took a long time to run on my qemux86 build, though - at least 30
minutes.


Thanks very much for Matt's guide!

I have applied the patch you provide to create a symlink to the
installed dep program instead of rebuilding and also add go', 'git', and
'git-perltools' into the image, but there is no PASS case, all failed as
attached go-dep_ptest.log.


The device under test needs Internet access to fetch repos from
Github. From the log, it looks like perhaps yours didn't?



BTW, you said you set GOCACHE, what's the valid path do you mean?


Any directory that the user has write access to.  The default is
$HOME/.cache/go-build .


There is no difference after set GOCACHE, still all the case failed.

Thanks,



-M



Thanks,



Here's the patch I applied to use the already-built dep binary.  An
alternative approach would be to put everything in place to allow the
test program to rebuild the dep binary itself, but that would drive up
the time for the test run even further.

Regards,
-Matt

---
   cmd/dep/dep_test.go | 13 +
   1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/github.com/golang/dep/cmd/dep/dep_test.go
b/src/github.com/golang/dep/cmd/dep/dep_test.go
index 687eef3a..535ca56d 100644
--- a/src/github.com/golang/dep/cmd/dep/dep_test.go
+++ b/src/github.com/golang/dep/cmd/dep/dep_test.go
@@ -18,13 +18,18 @@ import (
   // deletes it after the tests have been run.
   // Most of this is taken from
https://github.com/golang/go/blob/master/src/cmd/go/go_test.go and
reused here.
   func TestMain(m *testing.M) {
- args := []string{"build", "-o", "testdep" + test.ExeSuffix}
- out, err := exec.Command("go", args...).CombinedOutput()
+ args := []string{"dep"}
+ out, err := exec.Command("which", args...).CombinedOutput()
if err != nil {
- fmt.Fprintf(os.Stderr, "building testdep failed: %v\n%s", err, out)
+ fmt.Fprintf(os.Stderr, "finding dep failed: %v\n%s", err, out)
+ os.Exit(2)
+ }
+ args = []string{"-s", string(out[:len(out)-1]), "testdep" + test.ExeSuffix}
+ out, err = exec.Command("ln", args...).CombinedOutput()
+ if err != nil {
+ fmt.Fprintf(os.Stderr, "symlinking dep failed: %v\n%s", err, out)
os.Exit(2)
}
-
// Don't let these environment variables confuse the test.
os.Unsetenv("GOPATH")
os.Unsetenv("GIT_ALLOW_PROTOCOL")




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

Re: [OE-core] [PATCH] go-dep: disable PTEST_ENABLED

[Yu, Mingli]

On 2019年07月01日 19:59, Matt Madison wrote:

On Sun, Jun 30, 2019 at 6:59 PM Yu, Mingli  wrote:




On 2019年06月28日 19:02, Richard Purdie wrote:

On Fri, 2019-06-28 at 00:57 -0700, mingli...@windriver.com wrote:

From: Mingli Yu 

The run-ptest logic for go-dep actually runs the
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose
source file is
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go.

That dep_test.go starts by rebuilding the dep program
from source, then runs the tests using that copy of the
program, so it's assuming that we're still in a development
environment where we can run a full go build.

Considering it not being designed for a cross-build setup,
so disable PTEST_ENABLED.

Signed-off-by: Mingli Yu 
---
   meta/recipes-devtools/go/go-dep_0.5.0.bb | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/go/go-dep_0.5.0.bb b/meta/recipes-
devtools/go/go-dep_0.5.0.bb
index a4d631f8ea..e9fc12fa5a 100644
--- a/meta/recipes-devtools/go/go-dep_0.5.0.bb
+++ b/meta/recipes-devtools/go/go-dep_0.5.0.bb
@@ -21,5 +21,6 @@ BBCLASSEXTEND = "native nativesdk"

   # For compiling ptest on mips and mips64, the current go-dep version
fails with the go 1.11 toolchain.
   # error message: vet config not found
-PTEST_ENABLED_mips = "0"
-PTEST_ENABLED_mips64 = "0"
+# disable PTEST_ENABLED as the run-ptest script for go-dep actually
runs the /usr/lib64/go-
dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose source file is
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go not
being designed for a cross-build setup.
+PTEST_ENABLED = "0"
+PTEST_ENABLED = "0"


Setting it twice looks wrong.


Sorry, it should be my typo.



If we're disabling it, why would we inherit the ptest class at all as
its not going to work anywhere?

Upstream not considering cross test usecases isn't a reason to disable
a test, we have many tests enabled where upstream haven't considered a
cross use case, we just tend to patch as needed and start a discussion
with them.

It sounds like its actually a network access problem from the image
you're running into anyway?


Hi RP,

Have discussed the ptest more with Matt in the maillist and also tried
to add the patch under the guide from Matt to make the
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go work with
cross-setup env. But seems it still doesn't work.

Hi Matt,
What's your opinion?


I was able to get the test to work in my setup, with the addition of
that patch and manually setting GOCACHE in my environment. As Richard


Thanks Matt's information!

If so, could you help to contribute your worked patch to oe-core?

I still got all cases failed even with the patch which to make 
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go 
correspondingly usable for cross-setup.



mentioned, from the failures you were getting, it looked like a
network access issue in your setup. I'm not sure why GOCACHE needs to
be set, when 'go env' shows the correct (non-'off') default; that
might be another issue in dep that needs to be addressed.

It would be good to have at least one non-trivial ptest for a go
package, and since OE-Core doesn't have much beyond the toolchain
itself, go-dep, and glide, getting this to work would provide some
much-needed coverage. Running go-dep or glide - both build tools - on
a target seems like a fairly rare use case, though.


BTW, I noticed even go doesn't have ptest support.



As for Richard's initial question, go.bbclass inherits ptest to enable
the mapping of go's built-in test builds automatically. In hindsight,
maybe this wasn't the best choice, and it was overly optimistic to
think that because go supports separate compilation and execution of
tests, that packages would generally support that by default.


How about to remove inherits ptest logic in go.bbclass and let the 
inherit ptest logic in each recipe if someone cares about go-dep ptest.


Thanks,



-Matt


Thanks,



Cheers,

Richard






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

[Yu, Mingli]

On 2019年04月18日 01:14, Khem Raj wrote:

On Wed, Apr 17, 2019 at 12:45 AM Yu, Mingli  wrote:




On 2019年04月17日 02:00, Khem Raj wrote:

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.


Hi Khem,

I don't quite get what you mean. Disable warning as errors?

As https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html, gcc
upstream thinks the build error is meaningless when compile
gcc-sanitizers with -Og and suggests not use -Og to compile for
gcc-sanitizers.

So I send out the patch to add the workaround [DEBUG_OPTIMIZATION_append
= " -Wno-error"] to silence the error when debug build is enabled for
gcc-sanitizers.
If the workaround isn't suitable, then how to silence the
-Werror=maybe-uninitialized issue build error when debug build enabled?


I was meaning to say that remove -Werror from cmdline completely


Thanks Khem! So this is what we did currently now in V3 patch.

Hi RP,
So any comments here/

Thanks,





Thanks,





cu
Adrian






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

Re: [OE-core] [PATCH] glib-2.0: fix ptest failures

[Yu, Mingli]

On 2019年04月24日 20:07, Burton, Ross wrote:

On Wed, 24 Apr 2019 at 02:51, Yu, Mingli  wrote:

Per the comments at https://gitlab.gnome.org/GNOME/glib/issues/1357, we
need to run test_non_utf8_printf under builddir to guarantee the test
passed.


Re-read the comments.  Setting that variable skips the test, as it
isn't useful without the translations being installed. So, we need to
install the translations:

root@bob:~# /usr/libexec/installed-tests/glib/gdatetime -p
/GDateTime/non_utf8_printf
/GDateTime/non_utf8_printf: **
GLib:ERROR:../glib-2.58.3/glib/tests/gdatetime.c:1477:test_non_utf8_printf:
assertion failed (__p == ("10\346\234\210")): ("Oct" ==
"10\346\234\210")
Aborted (core dumped)

root@bob:~# dnf install glib-2.0-locale-ja
[ ... ]
Installed:
   libglib-2.0-locale-ja-1:2.58.3-r0.corei7_64


Many thanks for Ross's comments!

Yes, it's true. Install libglib-2.0-locale-ja-2.58.3-r0 did silence the 
test_non_utf8_printf failure of gdatetime.test.


But once unset G_TEST_BUILDDIR, we should check the translation modules 
one by one to silence other failures such as below to guarantee 
gdatetime.test passed.


GLib:ERROR:../glib-2.58.3/glib/tests/gdatetime.c:1683:test_month_names: 
assertion failed (p_casefold == (o_casefold)): ("sep" == "sept.")
Bail out! 
GLib:ERROR:../glib-2.58.3/glib/tests/gdatetime.c:1683:test_month_names: 
assertion failed (p_casefold == (o_casefold)): ("sep" == "sept.")

FAIL: glib/gdatetime.test (Child process killed by signal 6)

Anyway, I will check the translation issues one by one and resent the patch.

Thanks,



root@bob:~# /usr/libexec/installed-tests/glib/gdatetime -p
/GDateTime/non_utf8_printf
/GDateTime/non_utf8_printf: OK

Ross


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

[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] glib-2.0: fix ptest failures

[Yu, Mingli]

On 2019年04月23日 23:52, Burton, Ross wrote:

On Fri, 19 Apr 2019 at 09:54,  wrote:

From: Mingli Yu 

* Set G_TEST_BUILDDIR to mark we run the tests
   out of builddir to make it can skip the test_non_utf8_printf
   to fix below test error as test_non_utf8_printf needed
   to run under builddir per 
https://gitlab.gnome.org/GNOME/glib/blob/master/glib/tests/gdatetime.c#L1440.
   | GLib:ERROR:../glib-2.58.3/glib/tests/gdatetime.c:1477:test_non_utf8_printf: assertion failed (__p == 
("10\346\234\210")): ("Oct" == "10\346\234\210")
   | Bail out! GLib:ERROR:../glib-2.58.3/glib/tests/gdatetime.c:1477:test_non_utf8_printf: assertion failed 
(__p == ("10\346\234\210")): ("Oct" == "10\346\234\210")
   | FAIL: glib/gdatetime.test (Child process killed by signal 6)


As per the link:

/* If running uninstalled (G_TEST_BUILDDIR is set), skip this test, since we
* need the translations to be installed. We can’t mess around with
* bindtextdomain() here, as the compiled .gmo files in po/ are not in the
* right installed directory hierarchy to be successfully loaded by
gettext. */

Setting G_TEST_BUILDDIR isn't right as we're not running uninstalled.
This is a gross hack, and not a fix.


Per the comments at https://gitlab.gnome.org/GNOME/glib/issues/1357, we 
need to run test_non_utf8_printf under builddir to guarantee the test 
passed.


Thanks,



Ross


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

Re: [OE-core] [PATCH v5 06/13] go.bbclass: ptest cleanup and improvements

[Yu, Mingli]

On 2019年06月26日 22:00, Matt Madison wrote:

On Wed, Jun 26, 2019 at 2:02 AM Yu, Mingli  wrote:




On 2019年06月25日 20:23, Matt Madison wrote:

On Fri, Jun 21, 2019 at 2:08 AM Yu, Mingli  wrote:


Hi Matt,

I noticed your commit is the latest update for go-dep ptest. But the
go-dep ptest doesn't work in my environment. I'm trying to figure out
what's wrong is here though I didn't know much about go.


I went back over the commits, and I don't think I did anything with
go-dep specifically. I can see that the tests are failing for it, and
it looks like it's because go-dep's test programs make some
assumptions about the environment.  For one thing, it needs the go
compiler installed. It also looks like it's expecting some source
files to be present... in other words, it's not really designed for a
cross-build setup, with tests run on the cross-built target. It could
be messy to work around that, and I'm not sure how useful it would be
anyway, seeing as how go-dep is more of a build tool.  Might be better
to just disable ptests for it completely.


Many thanks Matt for your information!
Did you ever run go-dep ptest?
Go through the run-ptest script for go-dep, it actually runs the
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose
source file is
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go.


Yes, I see that.  That main program starts by rebuilding the dep
program from source, then runs the tests using that copy of the
program, so it's assuming that you're still in a development
environment where you can run a full go build.  That's what I meant by
it not being designed for a cross-build setup.

I've patched the test program to create a symlink to the installed dep
program instead of rebuilding, and got further.  You'll need to
include 'go', 'git', and 'git-perltools' in the image to get the tests
to run. Some of the test cases failed until I set GOCACHE in the
environment to point to a valid path; I'm not sure why.  The tests
took a long time to run on my qemux86 build, though - at least 30
minutes.


Thanks very much for Matt's guide!

I have applied the patch you provide to create a symlink to the 
installed dep program instead of rebuilding and also add go', 'git', and 
'git-perltools' into the image, but there is no PASS case, all failed as 
attached go-dep_ptest.log.


BTW, you said you set GOCACHE, what's the valid path do you mean?

Thanks,



Here's the patch I applied to use the already-built dep binary.  An
alternative approach would be to put everything in place to allow the
test program to rebuild the dep binary itself, but that would drive up
the time for the test run even further.

Regards,
-Matt

---
  cmd/dep/dep_test.go | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/github.com/golang/dep/cmd/dep/dep_test.go
b/src/github.com/golang/dep/cmd/dep/dep_test.go
index 687eef3a..535ca56d 100644
--- a/src/github.com/golang/dep/cmd/dep/dep_test.go
+++ b/src/github.com/golang/dep/cmd/dep/dep_test.go
@@ -18,13 +18,18 @@ import (
  // deletes it after the tests have been run.
  // Most of this is taken from
https://github.com/golang/go/blob/master/src/cmd/go/go_test.go and
reused here.
  func TestMain(m *testing.M) {
- args := []string{"build", "-o", "testdep" + test.ExeSuffix}
- out, err := exec.Command("go", args...).CombinedOutput()
+ args := []string{"dep"}
+ out, err := exec.Command("which", args...).CombinedOutput()
   if err != nil {
- fmt.Fprintf(os.Stderr, "building testdep failed: %v\n%s", err, out)
+ fmt.Fprintf(os.Stderr, "finding dep failed: %v\n%s", err, out)
+ os.Exit(2)
+ }
+ args = []string{"-s", string(out[:len(out)-1]), "testdep" + test.ExeSuffix}
+ out, err = exec.Command("ln", args...).CombinedOutput()
+ if err != nil {
+ fmt.Fprintf(os.Stderr, "symlinking dep failed: %v\n%s", err, out)
   os.Exit(2)
   }
-
   // Don't let these environment variables confuse the test.
   os.Unsetenv("GOPATH")
   os.Unsetenv("GIT_ALLOW_PROTOCOL")

--- FAIL: TestIntegration (0.46s)
--- FAIL: TestIntegration/status/revision_constraint (0.00s)
--- FAIL: TestIntegration/status/revision_constraint/external (0.53s)
integration_test.go:194: cmd ensure raised an unexpected error: exit status 2
--- FAIL: TestIntegration/status/override_constraint (0.00s)
--- FAIL: TestIntegration/status/override_constraint/external (0.52s)
integration_test.go:194: cmd ensure raised an unexpected error: exit status 2
--- FAIL: TestIntegration/status/old_constraints (0.00s)
--- FAIL: TestIntegration/status/old_constraints/external (0.80s)
integration_test.go:194: cmd ensure raised an unexpected error: exit status 2
--- FAIL: TestIntegration/status/missing_pkgs_lock_mismatch (0.00s)
--- FAIL: TestIntegration/status/missing_pkgs_lock_mis

Re: [OE-core] [PATCH] go-dep: disable PTEST_ENABLED

[Yu, Mingli]

On 2019年06月28日 19:02, Richard Purdie wrote:

On Fri, 2019-06-28 at 00:57 -0700, mingli...@windriver.com wrote:

From: Mingli Yu 

The run-ptest logic for go-dep actually runs the
/usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose
source file is
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go.

That dep_test.go starts by rebuilding the dep program
from source, then runs the tests using that copy of the
program, so it's assuming that we're still in a development
environment where we can run a full go build.

Considering it not being designed for a cross-build setup,
so disable PTEST_ENABLED.

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/go/go-dep_0.5.0.bb | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/go/go-dep_0.5.0.bb b/meta/recipes-
devtools/go/go-dep_0.5.0.bb
index a4d631f8ea..e9fc12fa5a 100644
--- a/meta/recipes-devtools/go/go-dep_0.5.0.bb
+++ b/meta/recipes-devtools/go/go-dep_0.5.0.bb
@@ -21,5 +21,6 @@ BBCLASSEXTEND = "native nativesdk"

  # For compiling ptest on mips and mips64, the current go-dep version
fails with the go 1.11 toolchain.
  # error message: vet config not found
-PTEST_ENABLED_mips = "0"
-PTEST_ENABLED_mips64 = "0"
+# disable PTEST_ENABLED as the run-ptest script for go-dep actually
runs the /usr/lib64/go-
dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose source file is
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go not
being designed for a cross-build setup.
+PTEST_ENABLED = "0"
+PTEST_ENABLED = "0"


Setting it twice looks wrong.


Sorry, it should be my typo.



If we're disabling it, why would we inherit the ptest class at all as
its not going to work anywhere?

Upstream not considering cross test usecases isn't a reason to disable
a test, we have many tests enabled where upstream haven't considered a
cross use case, we just tend to patch as needed and start a discussion
with them.

It sounds like its actually a network access problem from the image
you're running into anyway?


Hi RP,

Have discussed the ptest more with Matt in the maillist and also tried 
to add the patch under the guide from Matt to make the 
https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go work with 
cross-setup env. But seems it still doesn't work.


Hi Matt,
What's your opinion?

Thanks,



Cheers,

Richard




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

Re: [OE-core] bash: Fix CVE-2019-18276

[Yu, Mingli]

Got it, thanks Anuj!

Thanks,
Mingli

From: openembedded-core-boun...@lists.openembedded.org 
[openembedded-core-boun...@lists.openembedded.org] on behalf of Mittal, Anuj 
[anuj.mit...@intel.com]
Sent: Wednesday, March 04, 2020 7:49 AM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] bash: Fix CVE-2019-18276

On Tue, 2020-03-03 at 03:11 +, Yu, Mingli wrote:
> Hi Anuj,
>
> I agree the Backport status is not accurate as the patch doesn't go
> to master branch, but why do you say the patch is irrelevant to the
> CVE-2019-18276, could you help to provide more info?

I didn't say that the patch was irrelevant to the CVE. I had said that
not all the changes were relevant. I believe the glob changes in the
patch were irrelevant. Those changes also introduced a failure in bash
ptests.

Thanks,

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

Re: [OE-core] bash: Fix CVE-2019-18276

[Yu, Mingli]

Thanks Chet very much for your confirmation!

If the commit fixs the CVE-2019-18276, why is it merged to the master branch?

Thanks,
Mingli

From: Chet Ramey [chet.ra...@case.edu]
Sent: Tuesday, March 03, 2020 9:55 PM
To: Yu, Mingli; Mittal, Anuj; richard.pur...@linuxfoundation.org; 
openembedded-core@lists.openembedded.org; Huo, De; pr...@electromag.com.au; 
akuster...@gmail.com
Cc: chet.ra...@case.edu
Subject: Re: [OE-core] bash: Fix CVE-2019-18276

On 3/2/20 10:11 PM, Yu, Mingli wrote:

> Does 
> https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=951bdaad7a18cc0dc1036bba86b18b90874d39ff
>  fix the issue reported in CVE-2019-18276? Could you help to provide some 
> info here?

Yes, the changes from 6/27 fix the issue in the CVE.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] bash: Fix CVE-2019-18276

[Yu, Mingli]

Hi Anuj,

I agree the Backport status is not accurate as the patch doesn't go to master 
branch, but why do you say the patch is irrelevant to the CVE-2019-18276, could 
you help to provide more info?

Hi Chet,
Does 
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=951bdaad7a18cc0dc1036bba86b18b90874d39ff
 fix the issue reported in CVE-2019-18276? Could you help to provide some info 
here?

Thanks,
Mingli

From: openembedded-core-boun...@lists.openembedded.org 
[openembedded-core-boun...@lists.openembedded.org] on behalf of Mittal, Anuj 
[anuj.mit...@intel.com]
Sent: Tuesday, February 18, 2020 11:43 PM
To: chet.ra...@case.edu; richard.pur...@linuxfoundation.org; 
openembedded-core@lists.openembedded.org; Huo, De; pr...@electromag.com.au; 
akuster...@gmail.com
Subject: Re: [OE-core] bash: Fix CVE-2019-18276

On Tue, 2020-02-18 at 15:35 +, Richard Purdie wrote:
> On Tue, 2020-02-18 at 10:28 -0500, Chet Ramey wrote:
> > On 2/17/20 9:46 PM, Huo, De wrote:
> > >  I applied the patch to fix CVE defect CVE-2019-18276.
> >
> > That's not exactly an answer to the question of who produced the
> > patch.
> > If that patch is the one causing failures when it's applied,
> > doesn't it
> > make sense to go back to the person who produced it and ask them to
> > update it if necessary?
>
> Its likely a general CVE patch where both configure and configure.ac
> are patched. For OE, we can drop the configure part since we
> reautoconf
> the code. Its therefore the OE port of the patch which is likely at
> fault.
>
> Someone just needs to remove that section of the patch.

There are other issues with this patch which should also be fixed I
think. It has been marked as a Backport while it is not one. The patch
includes changes that are irrelevant to the CVE. And, it should have
gone to master first.


Thanks,

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

Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

[Yu, Mingli]

On 01/19/20 13:32, Patchwork wrote:

== Series Details ==

Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/22123/
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 9d7a521971)


Have already rebased on the master branch of 
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue out 
the above issue? Any hint?


Thanks,





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

Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

[Yu, Mingli]

On 01/20/20 09:29, Paul Eggleton wrote:

Hi Mingli

On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:

On 01/19/20 13:32, Patchwork wrote:

== Series Details ==

Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/22123/
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 9d7a521971)


Have already rebased on the master branch of
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue out
the above issue? Any hint?


It's assuming that patches sent to this list are for OE-Core (which they
generally are). I wasn't aware but apparently the documented place to
send pseudo patches is this list, so I think in this case you can just ignore
patchtest.


Okay, many thanks Paul for your hint!

Thanks,



Cheers,
Paul


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

Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

[Yu, Mingli]

On 01/20/20 10:28, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org  On Behalf Of Yu, Mingli
Sent: den 20 januari 2020 02:34
To: Paul Eggleton 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC
to avoid fd leak (rev3)

On 01/20/20 09:29, Paul Eggleton wrote:

Hi Mingli

On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:

On 01/19/20 13:32, Patchwork wrote:

== Series Details ==

Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/22123/
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 9d7a521971)


Have already rebased on the master branch of
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue out
the above issue? Any hint?


It's assuming that patches sent to this list are for OE-Core (which they
generally are). I wasn't aware but apparently the documented place to
send pseudo patches is this list, so I think in this case you can just
ignore patchtest.


Okay, many thanks Paul for your hint!

Thanks,



Cheers,
Paul


But it is probably a good idea to include a "[pseudo]" tag in the subject
when sending patches related to pseudo to this list, as the expectation
otherwise is that they are for OE-Core.


Thanks Peter! And already add the "pseudo_util.c" tag in the subject in 
the v3, please check the mail with the subject "[OE-core] [PATCH v3] 
pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak".


Thanks,



//Peter


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

Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)

[Yu, Mingli]

On 01/20/20 11:15, Peter Kjellerstedt wrote:

-Original Message-
From: Yu, Mingli 
Sent: den 20 januari 2020 04:04
To: Peter Kjellerstedt ; Paul Eggleton

Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC
to avoid fd leak (rev3)

On 01/20/20 10:28, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
core-

boun...@lists.openembedded.org> On Behalf Of Yu, Mingli
Sent: den 20 januari 2020 02:34
To: Paul Eggleton 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] ✗ patchtest: failure for Open file with

O_CLOEXEC

to avoid fd leak (rev3)

On 01/20/20 09:29, Paul Eggleton wrote:

Hi Mingli

On Sunday, 19 January 2020 6:41:49 PM NZDT Yu, Mingli wrote:

On 01/19/20 13:32, Patchwork wrote:

== Series Details ==

Series: Open file with O_CLOEXEC to avoid fd leak (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/22123/
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 9d7a521971)


Have already rebased on the master branch of
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue

out

the above issue? Any hint?


It's assuming that patches sent to this list are for OE-Core (which

they

generally are). I wasn't aware but apparently the documented place to
send pseudo patches is this list, so I think in this case you can just
ignore patchtest.


Okay, many thanks Paul for your hint!

Thanks,



Cheers,
Paul


But it is probably a good idea to include a "[pseudo]" tag in the

subject

when sending patches related to pseudo to this list, as the expectation
otherwise is that they are for OE-Core.


Thanks Peter! And already add the "pseudo_util.c" tag in the subject in
the v3, please check the mail with the subject "[OE-core] [PATCH v3]
pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak".


That is not the same. The "pseudo_util.c:" is part of the commit subject
and will end up in the Git repository. A "[pseudo]" tag is for anyone
seeing the mail (possibly including patchwork and patchtest), letting
them know that this commit is about pseudo, not OE-Core (similar to the
"[PATCH v3]" tag, which is also information about the commit).


Got it! V4 is incoming.

Thanks,




Thanks,


//Peter


//Peter


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

Re: [OE-core] [PATCH] gstreamer1.0-plugins-common.inc: disable orc on mips

[Yu, Mingli]

On 01/22/20 02:36, Khem Raj wrote:

On Mon, Jan 20, 2020 at 11:19 PM  wrote:


From: Mingli Yu 

After transiton to meson build for gstreamer series,
for gstreamer1.0-plugins-base, with below two commits
introduced:
238080ed89 gstreamer: Remove unused common files and patches
20614408dc gstreamer1.0-plugins-base: Transition to meson based builds

With below config in local.conf
MACHINE ??= "qemumips64"
require conf/multilib.conf
MULTILIB_GLOBAL_VARIANTS_append = " libn32"
MULTILIBS ?= "multilib:lib32 multilib:libn32"
DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips"
DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32"

there comes below failure:
$ bitbake lib32-gstreamer1.0-plugins-base
[snip]
mips-pokymllib32-linux-gcc -meb -mabi=32 -mhard-float -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security 
--sysroot=/mybuild/tmp/work/mips-pokymllib32-linux/lib32-gstreamer1.0-plugins-base/1.16.1-r0/lib32-recipe-sysroot
 -Itests/check/7d01337@@orc_video@exe -Itests/check 
-I../gst-plugins-base-1.16.1/tests/check 
-I/mybuild/tmp/work/mips-pokymllib32-linux/lib32-gstreamer1.0-plugins-base/1.16.1-r0/lib32-recipe-sysroot/usr/include/orc-0.4
 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -fvisibility=hidden 
-fno-strict-aliasing -DG_DISABLE_CAST_CHECKS -Wmissing-declarations 
-Wredundant-decls -Wundef -Wwrite-strings -Wformat -Wformat-nonliteral 
-Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar 
-Wvla -Wpointer-arith -Wmissing-prototypes -Wdeclaration-after-statement -O2 -g 
-feliminate-unused-debug-types 
-fmacro-prefix-map=/mybuild/tmp/work/mips-pokymllib32-linux/lib32-gstreamer1.0-plugins-base/1.16.1-r!

0=/u

  sr/src/debug/lib32-gstreamer1.0-plugins-base/1.16.1-r0 
-fdebug-prefix-map=/mybuild/tmp/work/mips-pokymllib32-linux/lib32-gstreamer1.0-plugins-base/1.16.1-r0=/usr/src/debug/lib32-gstreamer1.0-plugins-base/1.16.1-r0
 
-fdebug-prefix-map=/mybuild/tmp/work/mips-pokymllib32-linux/lib32-gstreamer1.0-plugins-base/1.16.1-r0/lib32-recipe-sysroot=
 
-fdebug-prefix-map=/mybuild/tmp/work/mips-pokymllib32-linux/lib32-gstreamer1.0-plugins-base/1.16.1-r0/recipe-sysroot-native=
 -MD -MQ 'tests/check/7d01337@@orc_video@exe/meson-generated_.._orc_video.c.o' 
-MF 'tests/check/7d01337@@orc_video@exe/meson-generated_.._orc_video.c.o.d' -o 
'tests/check/7d01337@@orc_video@exe/meson-generated_.._orc_video.c.o' -c 
tests/check/orc_video.c
FAILED: tests/check/7d01337@@orc_video@exe/meson-generated_.._orc_video.c.o
{standard input}: Assembler messages:
{standard input}:46587: Error: branch out of range
{standard input}:46613: Error: branch out of range
[snip]

BTW, gstreamer1.0-plugins-good also occurs
the same build failure as above.


I think there is some difference in behavior that meson migration has
brought. It will be good to see compiler cmdline for same file on zeus
e.g. perhaps we missed some flags


Hi Khem,

Thanks your respond!

Yes, it should be some different behavior I guess after migration to 
meson. Have compared basically for the flags before I sent the patch 
actually and didn't find the apparent difference. I prefer disable the 
orc first on mips.


Hi Carlos,

Any suggestion?





Disable orc as workaround to fix the above issue

Signed-off-by: Mingli Yu 
---
  .../findutils/{findutils_4.6.0.bb => findutils_4.7.0.bb} | 0
  .../gstreamer/gstreamer1.0-plugins-common.inc| 5 -
  2 files changed, 4 insertions(+), 1 deletion(-)
  rename meta/recipes-extended/findutils/{findutils_4.6.0.bb => 
findutils_4.7.0.bb} (100%)

diff --git a/meta/recipes-extended/findutils/findutils_4.6.0.bb 
b/meta/recipes-extended/findutils/findutils_4.7.0.bb
similarity index 100%
rename from meta/recipes-extended/findutils/findutils_4.6.0.bb
rename to meta/recipes-extended/findutils/findutils_4.7.0.bb
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-common.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-common.inc
index ccf55500a9..3896424b2d 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-common.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-common.inc
@@ -18,7 +18,10 @@ require gstreamer1.0-plugins-packaging.inc
  # This value is used in the PACKAGECONFIG values for each plugin set recipe.
  # By modifying it, Orc can be enabled/disabled in all of these recipes at 
once.
  GSTREAMER_ORC ?= "orc"
-
+# workaround to disable orc on mips to fix the build failure
+# {standard input}: Assembler messages:
+# {standard input}:46587: Error: branch out of range
+GSTREAMER_ORC_remove_mips = "orc"


No need to remove set it
GSTREAMER_ORC_mips = ""


Okay, will sent v3 to include the change.

Thanks,




  PACKAGECONFIG[orc] = "-Dorc=enabled,-Dorc=disabled,orc orc-native"

  # TODO: put this in a gettext.bbclass patch (with variables to allow for
--
2.23.0

--
___
Openembedded-core mailing list