[OE-core] [PATCH 1/1] coreutils: upgrade to 8.29

[Chen Qi]

* ls.c license checksum is changed, but the license remains the same.

* The new version provides native manual page support, there's no
  need to download extra manual page from gentoo site.

* man-decouple-manpages-from-build.patch is removed, as new version
  has manual page support in environment lacking of perl.

* hostname is explicitly enabled to keep the same with previous recipe's
  behaviour.

* ALTERNATIVE_XXX settings for lbracket.1 are removed as there's no such
  file.

Signed-off-by: Chen Qi 
---
 .../man-decouple-manpages-from-build.patch | 27 --
 .../{coreutils_8.28.bb => coreutils_8.29.bb}   | 24 +--
 2 files changed, 6 insertions(+), 45 deletions(-)
 delete mode 100644 
meta/recipes-core/coreutils/coreutils/man-decouple-manpages-from-build.patch
 rename meta/recipes-core/coreutils/{coreutils_8.28.bb => coreutils_8.29.bb} 
(80%)

diff --git 
a/meta/recipes-core/coreutils/coreutils/man-decouple-manpages-from-build.patch 
b/meta/recipes-core/coreutils/coreutils/man-decouple-manpages-from-build.patch
deleted file mode 100644
index 3c896a1..000
--- 
a/meta/recipes-core/coreutils/coreutils/man-decouple-manpages-from-build.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From b4d258629f090066783c3b4c91b40f63b9d0a296 Mon Sep 17 00:00:00 2001
-From: Paul Gortmaker 
-Date: Sun, 8 Feb 2015 16:51:57 -0500
-Subject: [PATCH] man: decouple manpages from build
-
-The use of "help2man" doesn't work at all for cross compile, in
-addition to the extra requirement of perl it adds.
-
-Just decouple the manpages from the build in order to pave the way for
-importing prebuilt manpages that can be used in a cross build situation.
-
-Upstream-Status: Inappropriate [upstream doesn't care about x-compile case.]
-Signed-off-by: Paul Gortmaker 
-
-diff --git a/Makefile.am b/Makefile.am
-index fb4af27..7576b2c 100644
 a/Makefile.am
-+++ b/Makefile.am
-@@ -214,5 +214,4 @@ AM_CPPFLAGS = -Ilib -I$(top_srcdir)/lib -Isrc 
-I$(top_srcdir)/src
- include $(top_srcdir)/lib/local.mk
- include $(top_srcdir)/src/local.mk
- include $(top_srcdir)/doc/local.mk
--include $(top_srcdir)/man/local.mk
- include $(top_srcdir)/tests/local.mk
--- 
-2.2.2
-
diff --git a/meta/recipes-core/coreutils/coreutils_8.28.bb 
b/meta/recipes-core/coreutils/coreutils_8.29.bb
similarity index 80%
rename from meta/recipes-core/coreutils/coreutils_8.28.bb
rename to meta/recipes-core/coreutils/coreutils_8.29.bb
index 8a9e80c..bdb7a42 100644
--- a/meta/recipes-core/coreutils/coreutils_8.28.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.29.bb
@@ -6,15 +6,13 @@ HOMEPAGE = "http://www.gnu.org/software/coreutils/;
 BUGTRACKER = "http://debbugs.gnu.org/coreutils;
 LICENSE = "GPLv3+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504\
-
file://src/ls.c;beginline=5;endline=16;md5=38b79785ca88537b75871782a2a3c6b8"
+
file://src/ls.c;beginline=1;endline=15;md5=1c3f9411e1842a062ce5ce9210beee0e"
 DEPENDS = "gmp libcap"
 DEPENDS_class-native = ""
 
 inherit autotools gettext texinfo
 
-SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.xz;name=tarball \
-   
http://distfiles.gentoo.org/distfiles/${BP}-man.tar.xz;name=manpages \
-   file://man-decouple-manpages-from-build.patch \
+SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.xz \
file://remove-usr-local-lib-from-m4.patch \
file://fix-selinux-flask.patch \
file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
@@ -24,13 +22,11 @@ SRC_URI = 
"${GNU_MIRROR}/coreutils/${BP}.tar.xz;name=tarball \
file://0001-doc-fix-Up-field-of-realpath-usage-examples.patch \
   "
 
-SRC_URI[tarball.md5sum] = "e7cb20d0572cc40d9f47ede6454406d1"
-SRC_URI[tarball.sha256sum] = 
"1117b1a16039ddd84d51a9923948307cfa28c2cea03d1a2438742253df0a0c65"
-SRC_URI[manpages.md5sum] = "3a7c626aad1c9077f254e5c2553a2f60"
-SRC_URI[manpages.sha256sum] = 
"d72c3fa79ae328a4fd1107102e8946755aa2e908044e1efcf1e71ef206dca042"
+SRC_URI[md5sum] = "960cfe75a42c9907c71439f8eb436303"
+SRC_URI[sha256sum] = 
"92d0fa1c311cacefa89853bdb53c62f4110cdfda3820346b59cbd098f40f955e"
 
 EXTRA_OECONF_class-native = "--without-gmp"
-EXTRA_OECONF_class-target = "--enable-install-program=arch 
--libexecdir=${libdir}"
+EXTRA_OECONF_class-target = "--enable-install-program=arch,hostname 
--libexecdir=${libdir}"
 EXTRA_OECONF_class-nativesdk = "--enable-install-program=arch"
 
 # acl and xattr are not default features
@@ -95,20 +91,13 @@ do_install_append() {
# in update-alternatives to fail, therefore use lbracket - the name used
# for the actual source file.
mv ${D}${bindir}/[ ${D}${bindir}/lbracket.${BPN}
-
-   # prebuilt man pages
-   install -d ${D}/${mandir}/man1
-   install -t ${D}/${mandir}/man1 ${S}/man/*.1
-   # prebuilt man pages don't do a separate man page for [ vs test.
-   

[OE-core] [PATCH 0/1] coreutils: upgrade to 8.29

[Chen Qi]

The following changes since commit 433ef0f8e9e63e4459934a06a42b56989c885e44:

  u-boot: Add Upstream-Status line missed from merged patch (2018-01-03 
09:26:38 +)

are available in the git repository at:

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

Chen Qi (1):
  coreutils: upgrade to 8.29

 .../man-decouple-manpages-from-build.patch | 27 --
 .../{coreutils_8.28.bb => coreutils_8.29.bb}   | 24 +--
 2 files changed, 6 insertions(+), 45 deletions(-)
 delete mode 100644 
meta/recipes-core/coreutils/coreutils/man-decouple-manpages-from-build.patch
 rename meta/recipes-core/coreutils/{coreutils_8.28.bb => coreutils_8.29.bb} 
(80%)

-- 
1.9.1

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

[OE-core] [PATCH] systemd: fix udev-hwdb warning

[mingli.yu]

From: Mingli Yu 

* Add qemu usermode checking for udev-hwdb as
  udev-hwdb uses quemu usermode by default, but
  some architecture such as Intel skylake doesn't
  support qemu usermode and can result a build
  warning as below:
  | warning: %post(udev-hwdb-1:234-r0.skylake_64) scriptlet failed, exit status 
1

Signed-off-by: Mingli Yu 
---
 meta/recipes-core/systemd/systemd_234.bb | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_234.bb 
b/meta/recipes-core/systemd/systemd_234.bb
index 9a10a31881..64596b7563 100644
--- a/meta/recipes-core/systemd/systemd_234.bb
+++ b/meta/recipes-core/systemd/systemd_234.bb
@@ -619,9 +619,13 @@ pkg_prerm_${PN} () {
 PACKAGE_WRITE_DEPS += "qemu-native"
 pkg_postinst_udev-hwdb () {
if test -n "$D"; then
-   ${@qemu_run_binary(d, '$D', '${base_bindir}/udevadm')} hwdb 
--update \
+   if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 
'true','false', d)}; then
+   ${@qemu_run_binary(d, '$D', '${base_bindir}/udevadm')} 
hwdb --update \
--root $D
-   chown root:root $D${sysconfdir}/udev/hwdb.bin
+   chown root:root $D${sysconfdir}/udev/hwdb.bin
+   else
+   exit 1
+   fi
else
udevadm hwdb --update
fi
-- 
2.11.0

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

Re: [OE-core] MS Windows machine?

[Steffen Sledz]

On 21.12.2017 14:00, Steffen Sledz wrote:
> On 21.12.2017 12:39, Burton, Ross wrote:
>> If you want to build for a Windows target then that should be possible but
>> nobody as far as I'm aware has made the work public.  meta-mingw will
>> contain most of the changes needed as that does build Windows binaries.
> 
> That's exactly what we like to to.
> 
> So has anyone tried this before?
> 
> What else would be needed to build e.g. for MACHINE=i686-mingw32?

Is someone able to create a machine definition for this? I'm not really 
familiar with this job.

Steffen

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

[OE-core] [pyro] [PATCH 2/2] diffstat: use HTTP mirror for SRC_URI

[Chang Rebecca Swee Fun]

From: Ross Burton 

The Invisible Mirror FTP service is currently down, and FTP is horrible, so
switch to the HTTP mirror.

(cherry picked from commit f31461f8ea11e82dbe14454a1149d9ec2120404d)

[YOCTO #12455]

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Chang Rebecca Swee Fun 
---
 meta/recipes-devtools/diffstat/diffstat_1.61.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/diffstat/diffstat_1.61.bb 
b/meta/recipes-devtools/diffstat/diffstat_1.61.bb
index 0ec41c3..583b387 100644
--- a/meta/recipes-devtools/diffstat/diffstat_1.61.bb
+++ b/meta/recipes-devtools/diffstat/diffstat_1.61.bb
@@ -7,7 +7,7 @@ SECTION = "devel"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://install-sh;endline=42;md5=b3549726c1022bee09c174c72a0ca4a5"
 
-SRC_URI = "ftp://invisible-island.net/diffstat/diffstat-${PV}.tgz \
+SRC_URI = "http://invisible-mirror.net/archives/${BPN}/${BP}.tgz \
file://run-ptest \
 "
 
-- 
2.7.4

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

[OE-core] [pyro] [PATCH 1/2] liburi-perl: update SRC_URI to yoctoproject mirror

[Chang Rebecca Swee Fun]

Upstream has removed the 1.71 release from www.cpan.org and
moved to the latest 1.72. Since we don't want to upgrade at
this point of time, temporarily move the SRC_URI to yoctoproject
source mirror.

[YOCTO #12454]

Signed-off-by: Chang Rebecca Swee Fun 
---
 meta/recipes-devtools/perl/liburi-perl_1.71.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/perl/liburi-perl_1.71.bb 
b/meta/recipes-devtools/perl/liburi-perl_1.71.bb
index a800198..432803c 100644
--- a/meta/recipes-devtools/perl/liburi-perl_1.71.bb
+++ b/meta/recipes-devtools/perl/liburi-perl_1.71.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=c453e94fae672800f83bc1bd7a38b53f"
 
 DEPENDS += "perl"
 
-SRC_URI = "http://www.cpan.org/authors/id/E/ET/ETHER/URI-${PV}.tar.gz;
+SRC_URI = "https://downloads.yoctoproject.org/mirror/sources/URI-${PV}.tar.gz;
 
 SRC_URI[md5sum] = "247c3da29a794f72730e01aa5a715daf"
 SRC_URI[sha256sum] = 
"9c8eca0d7f39e74bbc14706293e653b699238eeb1a7690cc9c136fb8c2644115"
-- 
2.7.4

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

[OE-core] [pyro] [PATCH 0/2] Fix for fetcher failure on SRC_URI

[Chang Rebecca Swee Fun]

We encountered a few fetcher failures on pyro branch.
A further investigation has been done and verified that
it is not a transient network issue.

Chang Rebecca Swee Fun (1):
  liburi-perl: update SRC_URI to yoctoproject mirror

Ross Burton (1):
  diffstat: use HTTP mirror for SRC_URI

 meta/recipes-devtools/diffstat/diffstat_1.61.bb | 2 +-
 meta/recipes-devtools/perl/liburi-perl_1.71.bb  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.7.4

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

[OE-core] [PATCH v2] gdb: fix build with x32

[Anuj Mittal]

When compiling gdb for x32, it fails with errors:

|../../../gdb-8.0/gdb/gdbserver/linux-amd64-ipa.c: In function 'const 
target_desc* get_ipa_tdesc(int)':
|../../../gdb-8.0/gdb/gdbserver/linux-amd64-ipa.c:184:10: error: 
'X86_TDESC_AVX512' was not declared in this scope
| case X86_TDESC_AVX512:
|  ^~~~
|../../../gdb-8.0/gdb/gdbserver/linux-amd64-ipa.c:184:10: note: suggested 
alternative: 'X86_TDESC_AVX'
| case X86_TDESC_AVX512:
|  ^~~~
|  X86_TDESC_AVX
|../../../gdb-8.0/gdb/gdbserver/linux-amd64-ipa.c:185:14: error: 
'tdesc_x32_avx512_linux' was not declared in this scope
|   return tdesc_x32_avx512_linux;
|  ^~
|../../../gdb-8.0/gdb/gdbserver/linux-amd64-ipa.c:185:14: note: suggested 
alternative: 'tdesc_x32_avx_linux'
|   return tdesc_x32_avx512_linux;
|  ^~
|  tdesc_x32_avx_linux
|../../../gdb-8.0/gdb/gdbserver/linux-amd64-ipa.c: In function 'void 
initialize_low_tracepoint()':
|../../../gdb-8.0/gdb/gdbserver/linux-amd64-ipa.c:282:3: error: 
'init_registers_x32_avx512_linux' was not declared in this scope
|   init_registers_x32_avx512_linux ();
|   ^~~
|../../../gdb-8.0/gdb/gdbserver/linux-amd64-ipa.c:282:3: note: suggested 
alternative: 'init_registers_x32_avx_linux'
|   init_registers_x32_avx512_linux ();
|   ^~~
|   init_registers_x32_avx_linux

Backport:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=f02fd7745d003d65fd3b981618e07b874b721d79

Fixes [YOCTO #12120]

Signed-off-by: Anuj Mittal 
---
 meta/recipes-devtools/gdb/gdb-8.0.1.inc|   1 +
 .../gdb/0012-Unbreak-GDBserver-build-for-x32.patch | 101 +
 2 files changed, 102 insertions(+)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/0012-Unbreak-GDBserver-build-for-x32.patch

diff --git a/meta/recipes-devtools/gdb/gdb-8.0.1.inc 
b/meta/recipes-devtools/gdb/gdb-8.0.1.inc
index 04a1c80..83c08e5 100644
--- a/meta/recipes-devtools/gdb/gdb-8.0.1.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.0.1.inc
@@ -16,6 +16,7 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://0009-Change-order-of-CFLAGS.patch \
file://0010-resolve-restrict-keyword-conflict.patch \
file://package_devel_gdb_patches_120-sigprocmask-invalid-call.patch 
\
+   file://0012-Unbreak-GDBserver-build-for-x32.patch \
 "
 SRC_URI[md5sum] = "48cac527e6f3018b865ece021e9723ac"
 SRC_URI[sha256sum] = 
"3dbd5f93e36ba2815ad0efab030dcd0c7b211d7b353a40a53f4c02d7d56295e3"
diff --git 
a/meta/recipes-devtools/gdb/gdb/0012-Unbreak-GDBserver-build-for-x32.patch 
b/meta/recipes-devtools/gdb/gdb/0012-Unbreak-GDBserver-build-for-x32.patch
new file mode 100644
index 000..18a3ce3
--- /dev/null
+++ b/meta/recipes-devtools/gdb/gdb/0012-Unbreak-GDBserver-build-for-x32.patch
@@ -0,0 +1,101 @@
+From 3e1e401053ea5f02a9e9c65abddd31a03baa1bd1 Mon Sep 17 00:00:00 2001
+From: Yao Qi 
+Date: Fri, 29 Dec 2017 12:57:25 +0800
+Subject: [PATCH] Unbreak GDBserver build for x32
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When I verify my target description changes, I build GDB and GDBserver for
+x32, but it failed.
+
+/../../binutils-gdb/gdb/gdbserver/linux-amd64-ipa.c
+../../../binutils-gdb/gdb/gdbserver/linux-amd64-ipa.c: In function ‘const 
target_desc* get_ipa_tdesc(int)’:
+../../../binutils-gdb/gdb/gdbserver/linux-amd64-ipa.c:184:10: error: 
‘X86_TDESC_AVX512’ was not declared in this scope
+ case X86_TDESC_AVX512:
+  ^
+../../../binutils-gdb/gdb/gdbserver/linux-amd64-ipa.c:185:14: error: 
‘tdesc_x32_avx512_linux’ was not declared in this scope
+   return tdesc_x32_avx512_linux;
+  ^
+../../../binutils-gdb/gdb/gdbserver/linux-amd64-ipa.c: In function ‘void 
initialize_low_tracepoint()’:
+../../../binutils-gdb/gdb/gdbserver/linux-amd64-ipa.c:282:36: error: 
‘init_registers_x32_avx512_linux’ was not declared in this scope
+   init_registers_x32_avx512_linux ();
+^
+
+ipa_x32_linux_regobj use to be there, but removed by
+22049425ce40324139be82d9a6ec518c46b65815 by mistake.
+
+gdb/gdbserver:
+
+2017-08-04  Yao Qi  
+
+* configure.srv (ipa_x32_linux_regobj): New.
+* linux-amd64-ipa.c (get_ipa_tdesc): Use X86_TDESC_AVX_AVX512
+instead of X86_TDESC_AVX512.
+(initialize_low_tracepoint): Call
+init_registers_x32_avx_avx512_linux.
+
+Upstream-Status: Backport 
[https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=f02fd7745d003d65fd3b981618e07b874b721d79]
+
+Signed-off-by: Anuj Mittal 
+---
+ ChangeLog   | 8 
+ gdb/gdbserver/configure.srv | 1 +
+ gdb/gdbserver/linux-amd64-ipa.c | 6 +++---
+ 3 files changed, 12 insertions(+), 3 deletions(-)

Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db

[Huang, Jie (Jackie)]

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Wednesday, January 03, 2018 21:54
> To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db
> 
> On Fri, 2017-12-22 at 02:08 +, Huang, Jie (Jackie) wrote:
> > Ping, I didn't see any objection on this, but it's not merged yet, do
> > I miss anything?
> 
> When we test it we see:
> 
> WARNING: glibc-2.26-r0 do_package: glibc-extra-nss-2.26 was registered as
> shlib provider for libnss_db.so.2, changing it to libnss-db-2.26 because it 
> was
> built later

Sorry, but I haven't seen this warning in our builds after this patch merged in 
our 
local branch for two weeks. Maybe we missed some cases in our test builds, so
could you show me how to reproduce it? Thanks!

This patch is simply re-package libnss_db.so* from glibc-extra-nss into 
libnss-db,
I don't understand why libnss_db.so* is still provided by both of them, did I 
miss
anything when I do a re-packaging for a recipe?

Thanks,
Jackie

> 
> so it looks like you swapped one race for another?
> 
> Cheers,
> 
> Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

[Richard Purdie]

On Wed, 2018-01-03 at 21:46 +, Slater, Joseph wrote:
> Currently, we do have to provide qemuwrapper with
> LD_LIBRARY_PATH.  We could hard-code all possible paths into that and
> not use ${libdir} and ${base_libdir}.  (I tried it and it works.)  We
> could also create a couple of new variables, like
> original_base_libdir, that don't get clobbered by allarch.   Maybe
> qemuwrapper should be smart enough to compute LD_LIBRARY_PATH...

I suspect somehow we therefore need to decouple qemuwrapper from the
target packages and just ensure that a separate script is available in
PATH when the rootfs is generated?

The rootfs should know which multilibs are enabled and be able to
generate the wrapper correctly?

Cheers,

Richard

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

Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

[Richard Purdie]

On Wed, 2018-01-03 at 10:43 +0200, Alexander Kanavin wrote:
> On 01/03/2018 12:45 AM, Richard Purdie wrote:
> > 
> > Sorry, but I don't think this can work :/.
> > 
> > Do the sstate sig selftests pass with this change?
> > 
> > I appreciate this will make some things "work" but it will mean
> > that
> > allarch packages rebuild for each architecture or multilib and that
> > isn't right either.
> > 
> > So we need a better solution here. Why do we need libdir paths to
> > run
> > binaries anyway? Is this a libexec issue? Perhaps the things in
> > question shouldn't be allarch?
>
> I think Ross has spent some time developing a fix for this same
> issue, perhaps he can chime in?

I think he did, I think I also pointed him at the sstate signature
tests and that caused some problems. Ross may be able to elaborate
more...

Cheers,

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

Re: [OE-core] [PATCH] gmp: depends on flex-native to fix parallel building issue

[Richard Purdie]

On Wed, 2018-01-03 at 16:35 -0500, Randy MacLeod wrote:
> I expect I'm missing an undocumented recipe rule here but...
> 
> 
> Yes, the race seems to only occur on morty and earlier, but
> the dependency is real and not yet listed explicitly in the recipe.
> 
>   $ grep flex tmp/work/i586-poky-linux/gmp/6.1.2-
> r0/temp/log.do_configure
> checking for flex... flex
> 
> It's resolved transitively through:
> gmp -> something -> binutils-cross-foo -> flex-native

I think it can happily build without flex by not re-generating certain
files. Whilst on target gmp does seem to have an indirect dependency,
our cross compiler does not:

$ grep flex tmp/work/x86_64-linux/gmp-native/6.1.2-r0/temp/log.do_configure
checking for flex... no

due to recipe specific sysroots and HOSTTOOLS, this is all at least
deterministic and it either builds with or without it deterministically
in all cases.

> I was on the fence about whether to be explicit or to rely on
> most/all recipes pulling in binutils-cross-foo via default
> rules. In looking at the guidance in 4.3.9 Dependencies:
>  
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#n
> ew-dependencies
> and briefly checking out LLVM's lld loader recipe where it seems
> that flex-native might not be needed so it's best to be explicit.
> 
> Unless there's an objection, Bai will re-submit the simple
> fix with an updated commit log. If anyone has time, they
> can check if the LLVM lld build really does NOT pull in flex-native
> and if not, then add explicit dependencies as required.

Actually, I do strongly object to adding in a flex-native dependency to
gmp-native and lengthening an already long/cumbersome toolchain
bootstrap process.

Cheers,

Richard


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

Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

[Slater, Joseph]

Currently, we do have to provide qemuwrapper with LD_LIBRARY_PATH.  We could 
hard-code all possible paths into that and not use ${libdir} and 
${base_libdir}.  (I tried it and it works.)  We could also create a couple of 
new variables, like original_base_libdir, that don't get clobbered by allarch.  
 Maybe qemuwrapper should be smart enough to compute LD_LIBRARY_PATH...

Joe

-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Sent: Wednesday, January 03, 2018 12:43 AM
To: Richard Purdie; Slater, Joseph; openembedded-core@lists.openembedded.org; 
BURTON, ROSS
Subject: Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

On 01/03/2018 12:45 AM, Richard Purdie wrote:
> Sorry, but I don't think this can work :/.
> 
> Do the sstate sig selftests pass with this change?
> 
> I appreciate this will make some things "work" but it will mean that 
> allarch packages rebuild for each architecture or multilib and that 
> isn't right either.
> 
> So we need a better solution here. Why do we need libdir paths to run 
> binaries anyway? Is this a libexec issue? Perhaps the things in 
> question shouldn't be allarch?

I think Ross has spent some time developing a fix for this same issue, perhaps 
he can chime in?

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

Re: [OE-core] [PATCH] gmp: depends on flex-native to fix parallel building issue

[Randy MacLeod]

On 2017-12-12 04:22 AM, Richard Purdie wrote:

Let me make this simpler. Which release of the project did you see this
issue with?

I believe this issue would only occur with morty and early, pyro, rocko
and master are not affected.


I expect I'm missing an undocumented recipe rule here but...


Yes, the race seems to only occur on morty and earlier, but
the dependency is real and not yet listed explicitly in the recipe.

 $ grep flex tmp/work/i586-poky-linux/gmp/6.1.2-r0/temp/log.do_configure
   checking for flex... flex

It's resolved transitively through:
   gmp -> something -> binutils-cross-foo -> flex-native

I was on the fence about whether to be explicit or to rely on
most/all recipes pulling in binutils-cross-foo via default
rules. In looking at the guidance in 4.3.9 Dependencies:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-dependencies
and briefly checking out LLVM's lld loader recipe where it seems
that flex-native might not be needed so it's best to be explicit.

Unless there's an objection, Bai will re-submit the simple
fix with an updated commit log. If anyone has time, they
can check if the LLVM lld build really does NOT pull in flex-native
and if not, then add explicit dependencies as required.

../Randy




Cheers,

Richard

On Tue, 2017-12-12 at 07:13 +, Bai, Haiqing wrote:

Comments below. thanks

-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: 2017年12月11日 6:48
To: Bai, Haiqing; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] gmp: depends on flex-native to fix
parallel building issue

On Wed, 2017-11-29 at 14:54 +0800, Haiqing Bai wrote:


fix below parallel building issue:
configure:27365: result: flex
configure:27403: flex conftest.l
.../sysroots/x86_64-linux/usr/bin/flex.real: No such file or
directory
configure:27407: $? = 127
configure:27409: checking lex output file root
configure:27420: error: cannot find output from flex; giving up

Signed-off-by: Haiqing Bai 
---
  meta/recipes-support/gmp/gmp.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-
support/gmp/gmp.inc index abac8cf..1b35eaa 100644
--- a/meta/recipes-support/gmp/gmp.inc
+++ b/meta/recipes-support/gmp/gmp.inc
@@ -10,3 +10,5 @@ PACKAGECONFIG[readline] = "--with-readline=yes,
--with-readline=no,readline"
  
  ARM_INSTRUCTION_SET_armv4 = "arm"

  ARM_INSTRUCTION_SET_armv5 = "arm"
+
+DEPENDS = "flex-native"

With recipe specific sysroots this should now be deterministic. The
log above suggests you were not using recipe specific sysroots? This
would therefore only be applicable to morty and earlier?
[This issue is founded on x86-64 building,  but it does not mean it
is only related with x86.  Actually this is caused by the defect of
the traditional probe mechanism of 'configure',  the package
configure
script try to probe whether has package 'flex' , then some optional
actions will be done by it.  In this issue,  when this probe
happens,   /usr/bin/flex exists but '/usr/bin/flex.real' has not
created for the
parallel building,  then configure reports the error and exits from
building.   Since there are no atomic guarantee for the package
output during parallel building, so here add this depends]

Cheers,

Richard




--
# Randy MacLeod.  WR Linux
# Wind River an Intel Company
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] glibc update

[Richard Purdie]

On Wed, 2018-01-03 at 12:17 -0800, akuster808 wrote:
> I noticed all but the glibc updates where merged from Khem's
> toolchain-update branch. Is there an issue with the glibc update, 
> was it just missed or pending more testing?
> 
> I have some patches I need to submit but I don't want to chase a
> moving target.

I'm trying to test things in batches without too many moving pieces and
I'm deferring the most risky things.

Given the number of glibc upgrade issues we've had recently (think
uninative) I'm apprehensive about the glibc patches and we had a queue
of other patches which conflict. I therefore have deferred that
particular patch until I have others sorted out. We are missing the
corresponding uninative upgrade to match the glibc upgrade which is
another factor. It may all turn out to be an unfounded worry or it may
not.

We will get there but I'm also kind of enjoying greenish builds ;-)

Cheers,

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

Re: [OE-core] [PATCHv2 1/3] runtime/cases/ptest.py: do not require ptest-pkgs in IMAGE_FEATURES

[Cal Sullivan]

Looks like it doesn't skip the test correctly:

| NOTE: test_ptestrunner (ptest.PtestRunnerTest) | DEBUG: Checking if 
ptest is in DISTRO_FEATURES or IMAGE_FEATURES | DEBUG: [Running]$ ssh -l 
root -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o 
LogLevel=ERROR 192.168.7.2 export PATH=/usr/sbin:/sbin:/usr/bin:/bin; 
which ptest-runner | DEBUG: Data from SSH call: which: no ptest-runner 
in (/usr/sbin:/sbin:/usr/bin:/bin) | DEBUG: [Command returned '1' after 
0.10 seconds] | DEBUG: Command: which ptest-runner | Output: which: no 
ptest-runner in (/usr/sbin:/sbin:/usr/bin:/bin) | | DEBUG: [Running]$ 
ssh -l root -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no 
-o LogLevel=ERROR 192.168.7.2 export PATH=/usr/sbin:/sbin:/usr/bin:/bin; 
ptest-runner | DEBUG: Data from SSH call: sh: ptest-runner: command not 
found | DEBUG: [Command returned '127' after 0.10 seconds] | DEBUG: 
Command: ptest-runner | Output: sh: ptest-runner: command not found | | 
NOTE: ... FAIL 
https://autobuilder.yocto.io/builders/nightly-deb-non-deb/builds/673/steps/Running%20Sanity%20Tests/logs/stdio 
Thanks, Cal


On 12/21/2017 04:44 AM, Alexander Kanavin wrote:

Doing so means that all available ptests for packages in the image
will be installed and run; some of them may be broken, never finish,
take a very long time or simply irrelevant to the user who wants to
check ptests of only a few specific packages, and does so by listing
them explicitly via IMAGE_INSTALL_append or similar.

Conversely, do not run the test if ptest-runner is not installed
(which means there are no ptests available, as they pull it in via a
dependency).

Signed-off-by: Alexander Kanavin 
---
  meta/lib/oeqa/runtime/cases/ptest.py | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/runtime/cases/ptest.py 
b/meta/lib/oeqa/runtime/cases/ptest.py
index ec8c038a566..63e119530dc 100644
--- a/meta/lib/oeqa/runtime/cases/ptest.py
+++ b/meta/lib/oeqa/runtime/cases/ptest.py
@@ -48,9 +48,12 @@ class PtestRunnerTest(OERuntimeTestCase):
  
  @OETestID(1600)

  @skipIfNotFeature('ptest', 'Test requires ptest to be in DISTRO_FEATURES')
-@skipIfNotFeature('ptest-pkgs', 'Test requires ptest-pkgs to be in 
IMAGE_FEATURES')
  @OETestDepends(['ssh.SSHTest.test_ssh'])
  def test_ptestrunner(self):
+status, output = self.target.run('which ptest-runner', 0)
+if len(output) == 0:
+self.skipTest("No -ptest packages are installed in the image")
+
  import datetime
  
  test_log_dir = self.td.get('TEST_LOG_DIR', '')


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

[OE-core] glibc update

[akuster808]

Hello,

I noticed all but the glibc updates where merged from Khem's
toolchain-update branch. Is there an issue with the glibc update,  was
it just missed or pending more testing?

I have some patches I need to submit but I don't want to chase a moving
target.

kind regards,

Armin

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

[OE-core] [PATCH v2] glib-2.0: Remove python3 modules when building for mingw

[Alistair Francis]

Commit "glib-2.0: Add python3 modules required by gdbus-codegen"
(26af3b4b33a34d7e53059b07236f9d5aae5e004a) broke the MinGW build of
QEMU. To fix the build remove the python3 RDEPENDS for gdbus-codegen
when targeting mingw.

Signed-off-by: Alistair Francis 
---
v2:
 - Don't duplicate code as reported by Richard

 meta/recipes-core/glib-2.0/glib.inc | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index fbc655a012..cfeb48a536 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -115,11 +115,10 @@ do_install_append_class-target () {
fi
 }
 
-RDEPENDS_${PN}-codegen += "\
-python3 \
-python3-distutils \
-python3-xml \
-   "
+CODEGEN_PYTHON_RDEPENDS = "python3 python3-distutils python3-xml"
+CODEGEN_PYTHON_RDEPENDS_mingw32 = ""
+
+RDEPENDS_${PN}-codegen += "${CODEGEN_PYTHON_RDEPENDS}"
 
 RDEPENDS_${PN}-ptest += "\
 dbus \
-- 
2.14.1

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

Re: [OE-core] [PATCH] glib-2.0: Remove python3 modules when building for mingw

[Alistair Francis]

On Wed, Jan 3, 2018 at 2:54 AM, Richard Purdie
 wrote:
> On Tue, 2018-01-02 at 14:49 -0800, Alistair Francis wrote:
>> Commit "glib-2.0: Add python3 modules required by gdbus-codegen"
>> (26af3b4b33a34d7e53059b07236f9d5aae5e004a) broke the MinGW build of
>> QEMU. To fix the build remove the python3 RDEPENDS for gdbus-codegen
>> when targeting mingw.
>>
>> Signed-off-by: Alistair Francis 
>> ---
>>  meta/recipes-core/glib-2.0/glib.inc | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-
>> core/glib-2.0/glib.inc
>> index fbc655a012..f8e803a90a 100644
>> --- a/meta/recipes-core/glib-2.0/glib.inc
>> +++ b/meta/recipes-core/glib-2.0/glib.inc
>> @@ -121,6 +121,12 @@ RDEPENDS_${PN}-codegen += "\
>>  python3-xml \
>> "
>>
>> +RDEPENDS_${PN}-codegen_remove_mingw32 = "\
>> +python3 \
>> +python3-distutils \
>> +python3-xml \
>> +   "
>> +
>>  RDEPENDS_${PN}-ptest += "\
>>  dbus \
>>  gnome-desktop-testing \
>
> I have pretty strong feelings that we shouldn't be using remove like
> this, or duplicating data. Its susceptible to breakage when one value
> changes and the other does not. Can you rework this so it doesn't use
> remove, or duplicate data?
>
> In case its not clear, you can do something like:
>
> CODEGEN_PYTHON_RDEPENDS = "python3 python3-distutils python3-xml"
> CODEGEN_PYTHON_RDEPENDS_mingw32 = ""
>
> RDEPENDS_${PN}-codegen += "${CODEGEN_PYTHON_RDEPENDS}"
>
> which is much more maintainable.

Looks good to me, I'll send a v2.

Alistair

>
> Cheers,
>
> Richard
> --
> ___
> 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] Slideshow for FOSDEM

[Philip Balister]

On 01/03/2018 09:47 AM, Paul Barker wrote:
> Hi all,
> 
> As we've only got one table at FOSDEM this year we're not going to
> have space for as many bits of hardware as usual. I'd still like us to
> show off the project and what people are building with OpenEmbedded &
> Yocto Project though. Given the limited space I think the best way to
> do this would be to put a slideshow on my laptop.
> 
> I've made a start on this here:
> https://docs.google.com/presentation/d/1KYxhsxO-8GxhAreE0GKnTOCPdY6_4uXYIEp6Lc55MB8/edit?usp=sharing
> 
> I've made this publicly editable so please feel free to add slides for
> any OE features you want to show off and any projects (professional or
> hobbyist) built with OE. If anyone can add a slide on project history
> that would also be great. I'd also like a slide on the latest release
> and the new features added. Photos of hardware projects using OE and
> features like Toaster would be especially welcome!
> 
> I'll give this a final edit before FOSDEM and the put it on rotation
> on a laptop at the stand. Hopefully it will be useful for future
> events as well.

Can we build a small board with a largish screen so we can run the show
on a device running an image built by OpenEmbedded?

Philip

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

Re: [OE-core] [PATCH 1/1] rpm_4.14.0: clamp timestamps by default

[Bystricky, Juro]

> I'm not sure I understand the necessity of this. What matters for
> reproducibility is that rpms install the same files; why is it important
> that the rpm file itself has exactly same build time and is otherwise
> identical bit by bit?
> 

There is actually a demand for binary reproducible packages.
See for example https://wiki.debian.org/ReproducibleBuilds/About
Debian packages already clamp timestamps by default. I am not even sure you can 
disable this 
(short of unsetting SOURCE_CODE_EPOCH). The same functionality exists for RPM 
packages,
except it is not the default behavior.

> A technicality: do not patch mnacros.in, set the macro directly from
> package_rpm.bbclass.
>

Yes, I considered this (see the [patch 0/1]). I chose to patch macros.in in the 
recipe rpm_4.14.0 instead because the new macro is introduced in RPM 4.14.0. 
I assumed we did not want to have RPM version dependencies in 
package_rpm.bbclass. 
But I have no strong feelings regarding this, I am pretty sure the new macro is 
here
to stay in the future and it is unlikely anyone would want to use a pre-4.14.0 
version of RPM either. If you think patching package_rpm.bbclass makes more 
sense,
I can send in another patch.
 
Juro
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] gobject-introspection: do not export LD_LIBRARY_PATH prior to running qemu

[Alexander Kanavin]

Latest g-i upstream adds target paths to this variable which breaks
qemu in various confusing ways.

Instead, the list of target library paths is exported to GIR_EXTRA_LIBS_PATH,
so that it can be picked up automatically by the qemu wrapper script
and given to qemu (manually setting this variable from various recipes
will be removed in a different patch).

Also, re-enable parts of g-i on mips64, as it is the same issue.

Signed-off-by: Alexander Kanavin 
---
 ...01-giscanner-add-a-lib-dirs-envvar-option.patch | 73 ++
 .../gobject-introspection_1.54.1.bb|  3 +-
 meta/recipes-graphics/clutter/clutter-gst-3.0.inc  |  4 --
 .../gstreamer/gstreamer1.0-plugins.inc |  3 -
 .../gstreamer/gstreamer1.0-rtsp-server.inc |  2 -
 5 files changed, 75 insertions(+), 10 deletions(-)
 create mode 100644 
meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-giscanner-add-a-lib-dirs-envvar-option.patch

diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-giscanner-add-a-lib-dirs-envvar-option.patch
 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-giscanner-add-a-lib-dirs-envvar-option.patch
new file mode 100644
index 000..e1776bc9b40
--- /dev/null
+++ 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-giscanner-add-a-lib-dirs-envvar-option.patch
@@ -0,0 +1,73 @@
+From a02076fe916ade6c3f78f6d35072ec53482e9446 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Wed, 3 Jan 2018 17:02:01 +0200
+Subject: [PATCH] giscanner: add a --lib-dirs-envvar option
+
+By default LD_LIBRARY_PATH is set to the list of target library paths;
+this breaks down in cross-compilation environment, as we need to run a
+native emulation wrapper rather than the target binary itself. This patch
+allows exporting those paths to a different environment variable
+which can be picked up and used by the wrapper.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+---
+ giscanner/ccompiler.py   | 6 --
+ giscanner/dumper.py  | 3 ++-
+ giscanner/scannermain.py | 3 +++
+ 3 files changed, 9 insertions(+), 3 deletions(-)
+
+diff --git a/giscanner/ccompiler.py b/giscanner/ccompiler.py
+index 29de0ee..e969337 100644
+--- a/giscanner/ccompiler.py
 b/giscanner/ccompiler.py
+@@ -109,14 +109,16 @@ class CCompiler(object):
+ 
+ self._cflags_no_deprecation_warnings = 
"-Wno-deprecated-declarations"
+ 
+-def get_internal_link_flags(self, args, libtool, libraries, 
extra_libraries, libpaths):
++def get_internal_link_flags(self, args, libtool, libraries, 
extra_libraries, libpaths, lib_dirs_envvar):
+ # An "internal" link is where the library to be introspected
+ # is being built in the current directory.
+ 
+ runtime_path_envvar = []
+ runtime_paths = []
+ 
+-if self.check_is_msvc():
++if lib_dirs_envvar:
++runtime_path_envvar = [lib_dirs_envvar]
++elif self.check_is_msvc():
+ runtime_path_envvar = ['LIB', 'PATH']
+ else:
+ runtime_path_envvar = ['LD_LIBRARY_PATH']
+diff --git a/giscanner/dumper.py b/giscanner/dumper.py
+index 7f77bd2..db96df6 100644
+--- a/giscanner/dumper.py
 b/giscanner/dumper.py
+@@ -259,7 +259,8 @@ class DumpCompiler(object):
+libtool,
+self._options.libraries,
+
self._options.extra_libraries,
+-   
self._options.library_paths)
++   
self._options.library_paths,
++   
self._options.lib_dirs_envvar)
+ args.extend(pkg_config_libs)
+ 
+ else:
+diff --git a/giscanner/scannermain.py b/giscanner/scannermain.py
+index 38a45c1..b603850 100755
+--- a/giscanner/scannermain.py
 b/giscanner/scannermain.py
+@@ -130,6 +130,9 @@ def _get_option_parser():
+ parser.add_option("", "--use-ldd-wrapper",
+   action="store", dest="ldd_wrapper", default=None,
+   help="wrapper to use instead of ldd (useful when 
cross-compiling)")
++parser.add_option("", "--lib-dirs-envvar",
++  action="store", dest="lib_dirs_envvar", default=None,
++  help="environment variable to write a list of library 
directories to (for running the transient binary), instead of standard 
LD_LIBRARY_PATH")
+ parser.add_option("", "--program-arg",
+   action="append", dest="program_args", default=[],
+   help="extra arguments to program")
+-- 
+2.15.1
+
diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb 

[OE-core] Slideshow for FOSDEM

[Paul Barker]

Hi all,

As we've only got one table at FOSDEM this year we're not going to
have space for as many bits of hardware as usual. I'd still like us to
show off the project and what people are building with OpenEmbedded &
Yocto Project though. Given the limited space I think the best way to
do this would be to put a slideshow on my laptop.

I've made a start on this here:
https://docs.google.com/presentation/d/1KYxhsxO-8GxhAreE0GKnTOCPdY6_4uXYIEp6Lc55MB8/edit?usp=sharing

I've made this publicly editable so please feel free to add slides for
any OE features you want to show off and any projects (professional or
hobbyist) built with OE. If anyone can add a slide on project history
that would also be great. I'd also like a slide on the latest release
and the new features added. Photos of hardware projects using OE and
features like Toaster would be especially welcome!

I'll give this a final edit before FOSDEM and the put it on rotation
on a laptop at the stand. Hopefully it will be useful for future
events as well.

Thanks all,

-- 
Paul Barker
Togán Labs Ltd
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux

[Richard Purdie]

On Wed, 2018-01-03 at 21:56 +0800, Robert Yang wrote:
> > Also, there are some things which never make sense as a multilib,
> > the
> > kernel is one example and I'm starting to wonder if syslinux would
> > be
> > another. In the kernel (and kernel module) case we'd provide all
> > the
> > libX variants from the same recipe, we may want to do that for
> > syslinux.
> I think that syslinux is different from kernel, 64bit kernel can
> provide 32bit kernel via kernel config, but syslinux can't (except
> these non arch files).

Think about this differently. The system can ever only boot one single
kernel. The image can have several different multilibs running at once
in different userspace processes but there can only ever be one running
kernel.

How that kernel is configured is obviously important but the key thing
is there can only be one running.

The bootloader is similar in that you likely only ever want one and I
suspect syslinux is similar.

Also, don't confuse this with multi-boot or multi partition systems
where there could be a "main" and a "backup" kernel. In those cases
there would only ever be one running at once.

> > It may be we can't avoid the multiple compiler issue and the
> > current
> > codebase may not do so, I think currently we can avoid multiple
> > glibc
> > though.
> I'm not sure about a problem on this, should lib32-image can run
> 64bit programs or not ? If yes, then kernel should be 64bit, and we
> can't avoid building 64bit compilers. And I'm leaning to yes since we
> call it multilib, the pure 32bit image which can't run 64bit programs
> can't be called multilib.

That is a configuration issue for the multilib you select. In general,
yes you'd want a 64 bit kernel.

> I did a rough search on why glibc is built, when bitbake lib32-image, 
> it is because:
> 
> 64 bit kernel -> gcc-cross-x86_64 -> virtual/${TARGET_PREFIX}libc-
> for-gcc,
> and the TARGET_PREFIX is x86_64 when building gcc-cross-x86_64,
> While the virtual/x86_64-poky-linux-libc-for-gcc is provided by
> glibc.
> 
> I tried to remove the depends, both "bitbake gcc-cross-x86_64" and
> "bitbake linux-yocto" can be built, but other recipes such as quilt
> would be failed:

I find it interesting that gcc-cross-x86_64 would build without glibc.
If that really is the case we may be able to speed up our compiler
bootstrap so that could be worth investigating further.

Its not surprising that libgcc won't build without glibc though.
Perhaps gcc-cross works since we split out the build of libgcc?

> > collect2: error: ld returned 1 exit status
> > Makefile:978: recipe for target 'libgcc_s.so' failed
> And move virtual/${TARGET_PREFIX}libc-for-gcc to BASE_DEFAULT_DEPS
> can't make it work either, so it seems that we can't avoid building
> glibc.

No, I'd forgotten that gcc-cross depends on glibc. Based on the above
there may still be some optimisation we can make here.

In the back of my mind, I'm concious that one x86 cross compiler should
be able to work for 32 and 64 bit too, its just the compiler options
and libgcc etc. would need to be generated for both...

> > Regardless, I do think this needs a little more thought, we also
> > need
> > better multiple test cases as we're not catching issues like this. 
> > think this needs to be revisited along with your outstanding
> > multilib
> > patch series which I haven't found the time to review yet (sorry).
> That's all right, I'm very glad to make mutilib work well, including
> adding test cases for them. It is nearly broken after changed from
> smart + rpm5 to dnf + rpm4, those patches fixed the problem.

Agreed, its important and on my list of things to review, I've just had
to focus on getting build testing working properly and now I can try
and clear some of the patch backlog.

Cheers,

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

Re: [OE-core] [PATCHv2 2/3] testimage.bbclass: add ptest to the list of runtime tests whenever possible

[Richard Purdie]

On Thu, 2017-12-21 at 14:44 +0200, Alexander Kanavin wrote:
> If no ptest packages are installed in the image, the test does
> nothing;
> if ptest packages are installed in the image, then they should be
> run without user having to enable that manually.
> 
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/classes/testimage.bbclass | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

https://autobuilder.yocto.io/builders/nightly-deb-non-deb/builds/673/steps/Running%20Sanity%20Tests/logs/stdio

Cheers,

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

Re: [OE-core] [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux

[Robert Yang]

On 01/03/2018 08:43 PM, Richard Purdie wrote:

On Wed, 2017-12-13 at 10:45 +0800, Robert Yang wrote:

Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
IMAGE_FSTYPES += "iso"

$ bitbake lib32-core-image-minimal
ERROR: lib32-core-image-minimal-1.0-r0 do_bootimg: The file
/usr/include/printf.h is installed by both glibc and lib32-glibc,
aborting

This was because:
lib32-syslinux -> lib32-glibc
virtual/kernel -> glibc

We can build 64bit syslinux (only build, not install) to fix the
problem, the
do_bootimg only needs several data files of syslinux such as
vesamenu.c32,
these files are not arch related.


Hi Robert,


Hi RP,

Thanks for the reply.



I've been thinking about this one and I'm not 100% convinced this is
the right thing to do.

When we build "lib32-core-image-minimal", one of the things we want to
avoid is building two different toolchains, there should only be one
needed for this image.

If there is a dependency on "syslinux", that will need the non-multilib
toolchain. I suspect that is why libX-syslinux was used as a
dependency.

Also, there are some things which never make sense as a multilib, the
kernel is one example and I'm starting to wonder if syslinux would be
another. In the kernel (and kernel module) case we'd provide all the
libX variants from the same recipe, we may want to do that for
syslinux.


I think that syslinux is different from kernel, 64bit kernel can provide
32bit kernel via kernel config, but syslinux can't (except these non
arch files).



It may be we can't avoid the multiple compiler issue and the current
codebase may not do so, I think currently we can avoid multiple glibc
though.


I'm not sure about a problem on this, should lib32-image can run 64bit
programs or not ? If yes, then kernel should be 64bit, and we can't avoid
building 64bit compilers. And I'm leaning to yes since we call it multilib,
the pure 32bit image which can't run 64bit programs can't be called multilib.

I did a rough search on why glibc is built, when bitbake lib32-image, it
is because:

64 bit kernel -> gcc-cross-x86_64 -> virtual/${TARGET_PREFIX}libc-for-gcc,
and the TARGET_PREFIX is x86_64 when building gcc-cross-x86_64,
While the virtual/x86_64-poky-linux-libc-for-gcc is provided by glibc.

I tried to remove the depends, both "bitbake gcc-cross-x86_64" and
"bitbake linux-yocto" can be built, but other recipes such as quilt would
be failed:

| 
/workspace1/lyang1/test_1/tmp/work/core2-64-poky-linux/libgcc/7.2.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.2.0/ld: 
cannot find crti.o: No such file or directory
| 
/workspace1/lyang1/test_1/tmp/work/core2-64-poky-linux/libgcc/7.2.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.2.0/ld: 
cannot find -lc
| 
/workspace1/lyang1/test_1/tmp/work/core2-64-poky-linux/libgcc/7.2.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.2.0/ld: 
cannot find crtn.o: No such file or directory

| collect2: error: ld returned 1 exit status
| Makefile:978: recipe for target 'libgcc_s.so' failed

And move virtual/${TARGET_PREFIX}libc-for-gcc to BASE_DEFAULT_DEPS can't make
it work either, so it seems that we can't avoid building glibc.



Regardless, I do think this needs a little more thought, we also need
better multiple test cases as we're not catching issues like this. 
think this needs to be revisited along with your outstanding multilib

patch series which I haven't found the time to review yet (sorry).


That's all right, I'm very glad to make mutilib work well, including
adding test cases for them. It is nearly broken after changed from
smart + rpm5 to dnf + rpm4, those patches fixed the problem.

// Robert



Cheers,

Richard


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

Re: [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db

[Richard Purdie]

On Fri, 2017-12-22 at 02:08 +, Huang, Jie (Jackie) wrote:
> Ping, I didn't see any objection on this, but it's not merged yet, do
> I miss anything?

When we test it we see:

WARNING: glibc-2.26-r0 do_package: glibc-extra-nss-2.26 was registered as shlib 
provider for libnss_db.so.2, changing it to libnss-db-2.26 because it was built 
later

so it looks like you swapped one race for another?

Cheers,

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

Re: [OE-core] [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux

[Richard Purdie]

On Wed, 2017-12-13 at 10:45 +0800, Robert Yang wrote:
> Fixed:
> MACHINE = "qemux86-64"
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> IMAGE_FSTYPES += "iso"
> 
> $ bitbake lib32-core-image-minimal
> ERROR: lib32-core-image-minimal-1.0-r0 do_bootimg: The file
> /usr/include/printf.h is installed by both glibc and lib32-glibc,
> aborting
> 
> This was because:
> lib32-syslinux -> lib32-glibc
> virtual/kernel -> glibc
> 
> We can build 64bit syslinux (only build, not install) to fix the
> problem, the
> do_bootimg only needs several data files of syslinux such as
> vesamenu.c32,
> these files are not arch related.

Hi Robert,

I've been thinking about this one and I'm not 100% convinced this is
the right thing to do.

When we build "lib32-core-image-minimal", one of the things we want to
avoid is building two different toolchains, there should only be one
needed for this image.

If there is a dependency on "syslinux", that will need the non-multilib 
toolchain. I suspect that is why libX-syslinux was used as a
dependency.

Also, there are some things which never make sense as a multilib, the
kernel is one example and I'm starting to wonder if syslinux would be
another. In the kernel (and kernel module) case we'd provide all the
libX variants from the same recipe, we may want to do that for
syslinux.

It may be we can't avoid the multiple compiler issue and the current
codebase may not do so, I think currently we can avoid multiple glibc
though.

Regardless, I do think this needs a little more thought, we also need
better multiple test cases as we're not catching issues like this. I
think this needs to be revisited along with your outstanding multilib
patch series which I haven't found the time to review yet (sorry).

Cheers,

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

Re: [OE-core] [PATCH] atk: 2.26.0 -> 2.27.1

[Richard Purdie]

On Wed, 2017-12-27 at 19:19 +0800, Huang Qiyu wrote:
> Upgrade atk from 2.26.0 to 2.27.1.
> 
> Signed-off-by: Huang Qiyu 
> ---
>  meta/recipes-support/atk/{atk_2.26.0.bb => atk_2.27.1.bb} | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-support/atk/{atk_2.26.0.bb => atk_2.27.1.bb}
> (78%)
> 
> diff --git a/meta/recipes-support/atk/atk_2.26.0.bb b/meta/recipes-
> support/atk/atk_2.27.1.bb
> similarity index 78%
> rename from meta/recipes-support/atk/atk_2.26.0.bb
> rename to meta/recipes-support/atk/atk_2.27.1.bb
> index e014ba0..3ac40cc 100644
> --- a/meta/recipes-support/atk/atk_2.26.0.bb
> +++ b/meta/recipes-support/atk/atk_2.27.1.bb
> @@ -12,8 +12,8 @@ DEPENDS = "glib-2.0"
>  
>  inherit gnomebase gtk-doc gettext upstream-version-is-even gobject-
> introspection

Isn't 2.27 a development version and not a stable one? The upstream-
version-is-even suggests that too...

Cheers,

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

Re: [OE-core] [PATCH 2/9] gnomebase.bbclass: split into autotools and meson versions

[Richard Purdie]

On Thu, 2017-12-21 at 15:04 +0200, Alexander Kanavin wrote:
> gnomebase.bbclass unfortunately hardcodes the autotools inherit,
> so we have to introduce gnomebase-nobuildsystem.bbclass where
> the common bits between autotools and meson classes can be placed.

In the interests of trying to avoid a ton more class files, could you
tweak this to do something like:

GNOMEBASEBUILDCLASS ??= "autotools"

inherit ${GNOMEBASEBUILDCLASS}

and then 

GNOMEBASEBUILDCLASS = "meson"
inherit gnomebase-autotools

(or the other way around but you get the idea)

Cheers,

Richard

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

Re: [OE-core] Yocto Project Status WW51’17

[Richard Purdie]

On Fri, 2017-12-22 at 13:23 -0500, Randy MacLeod wrote:
> On 2017-12-18 10:52 AM, Jolley, Stephen K wrote:
> > ·We have identified further intermittent bugs in various releases
> > which 
> > we’re continuing to look into (including gpg memory allocation
> > issues on 
> > pyro, sstate writing races in morty, further occurrences of the
> > inode 
> > count issues with our NAS on the autobuilder).
> If any of the new problems prove to be difficult to debug, please
> reply with the defect ID so that people can read the background
> and perhaps help out in some way.

Thanks, I'm catching up after the holidays. The morty sstate writing
issue was resolved with a backport:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=morty=e3ff03599e55fd2abcaa33e29779c388cdbed94e

The gpg issue is:

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

I've only just realised that I appear to be the one assigned to fix it
:/. So that one remains open and in need of help. We put a single
threaded workaround into master/rocko I think but its slowing down
selftest and really needs a better fix.

> WR used to use a single large NAS for our build cluster 3+ years ago.
> While it worked to first order, there was a background of mysterious
> errors. We switch to local disks and pushing logs/status to
> a centralized git repo and we've been happy with that choice.

In this case we have it working quite well, except for one oddity where
the NFS client free inode counts go a bit crazy. We've decided to stop
checking the free inode count on the NAS for now whilst we continue to
see if we can figure it out which means builds should be working again
and not hitting this. The bug is:

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

So the gpg one is the one I could use help with.

Cheers,

Richard


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

Re: [OE-core] [PATCH] glib-2.0: Remove python3 modules when building for mingw

[Richard Purdie]

On Tue, 2018-01-02 at 14:49 -0800, Alistair Francis wrote:
> Commit "glib-2.0: Add python3 modules required by gdbus-codegen"
> (26af3b4b33a34d7e53059b07236f9d5aae5e004a) broke the MinGW build of
> QEMU. To fix the build remove the python3 RDEPENDS for gdbus-codegen
> when targeting mingw.
> 
> Signed-off-by: Alistair Francis 
> ---
>  meta/recipes-core/glib-2.0/glib.inc | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-
> core/glib-2.0/glib.inc
> index fbc655a012..f8e803a90a 100644
> --- a/meta/recipes-core/glib-2.0/glib.inc
> +++ b/meta/recipes-core/glib-2.0/glib.inc
> @@ -121,6 +121,12 @@ RDEPENDS_${PN}-codegen += "\
>  python3-xml \
> "
>  
> +RDEPENDS_${PN}-codegen_remove_mingw32 = "\
> +python3 \
> +python3-distutils \
> +python3-xml \
> +   "
> +
>  RDEPENDS_${PN}-ptest += "\
>  dbus \
>  gnome-desktop-testing \

I have pretty strong feelings that we shouldn't be using remove like
this, or duplicating data. Its susceptible to breakage when one value
changes and the other does not. Can you rework this so it doesn't use
remove, or duplicate data?

In case its not clear, you can do something like:

CODEGEN_PYTHON_RDEPENDS = "python3 python3-distutils python3-xml"
CODEGEN_PYTHON_RDEPENDS_mingw32 = ""

RDEPENDS_${PN}-codegen += "${CODEGEN_PYTHON_RDEPENDS}"

which is much more maintainable.

Cheers,

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

Re: [OE-core] [PATCH] gdb: fix build with x32

[Richard Purdie]

On Fri, 2017-12-29 at 13:43 +0800, Anuj Mittal wrote:
> When compiling gdb for x32, it fails with errors:

Sorry, I merged a gdb minor version change and this no longer applies.
Was the patch included in gdb 8.0.1 or do we still need this patch? If
so could you rebase please?

Cheers,

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

Re: [OE-core] [PATCH 1/1] rpm_4.14.0: clamp timestamps by default

[Richard Purdie]

On Wed, 2018-01-03 at 10:47 +0200, Alexander Kanavin wrote:
> On 01/03/2018 01:16 AM, Juro Bystricky wrote:
> > 
> > Improve reproducibility by making sure that timestamps
> > in built rpms are not later than the value of SOURCE_DATE_EPOCH as
> > found in the environment.
> > Timestamps as usual when SOURCE_DATE_EPOCH is not set.
> I'm not sure I understand the necessity of this. What matters for 
> reproducibility is that rpms install the same files; why is it
> important that the rpm file itself has exactly same build time and is
> otherwise identical bit by bit?

People have different definitions of reproducibility. For some its the
end binaries on the target system, for others its identical rpms.

Its certainly true that producing binaries that are more similar does
help us in a number of ways (e.g. churn in package feeds) so if we can
improve that without causing serious complexity issues, I'm broadly in
favour of it.

Cheers,

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

Re: [OE-core] [PATCH] fontcache : fix build warning when using quemu usermode

[Alexander Kanavin]

On 01/03/2018 05:27 AM, Jibin Xu wrote:



On 2018年01月02日 20:00, Alexander Kanavin wrote:

On 12/28/2017 04:21 AM, Jibin Xu wrote:

fontcache uses quemu usermode by default, but some architecture
such as Intel skylake does not support qemu usermode, this can
lead to a build warning as below:
"WARNING: The postinstall intercept hook 'update_font_cache' failed".

Add a judgement of qemu usermode to fix the build warning.


You also need to fix this in pixbufcache.bbclass. Squash all changes 
into a single patch.
Do you mean that change gio-module-cache.bbclass pixbufcache.bbclass and 
fontcache.bbclass,

then Squash all changes into a single patch?


I mean this, yes. I thought there were four places to fix this, but one 
of the postinsts does not actually call into qemu, and just runs the 
native binary for some reason.


Alex


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

Re: [OE-core] [PATCH 1/1] rpm_4.14.0: clamp timestamps by default

[Alexander Kanavin]

On 01/03/2018 01:16 AM, Juro Bystricky wrote:

Improve reproducibility by making sure that timestamps
in built rpms are not later than the value of SOURCE_DATE_EPOCH as
found in the environment.
Timestamps as usual when SOURCE_DATE_EPOCH is not set.


I'm not sure I understand the necessity of this. What matters for 
reproducibility is that rpms install the same files; why is it important 
that the rpm file itself has exactly same build time and is otherwise 
identical bit by bit?


A technicality: do not patch mnacros.in, set the macro directly from 
package_rpm.bbclass.


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

Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

[Alexander Kanavin]

On 01/03/2018 12:45 AM, Richard Purdie wrote:

Sorry, but I don't think this can work :/.

Do the sstate sig selftests pass with this change?

I appreciate this will make some things "work" but it will mean that
allarch packages rebuild for each architecture or multilib and that
isn't right either.

So we need a better solution here. Why do we need libdir paths to run
binaries anyway? Is this a libexec issue? Perhaps the things in
question shouldn't be allarch?


I think Ross has spent some time developing a fix for this same issue, 
perhaps he can chime in?


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

Re: [OE-core] [PATCH] gobject-introspection: unset LD_LIBRARY_PATH prior to running qemu

[Alexander Kanavin]

On 01/02/2018 06:04 PM, Alexander Kanavin wrote:

Latest g-i upstream adds target paths to this variable which breaks
qemu in various confusing ways.

Also, re-enable parts of g-i on mips64, as it is the same issue.


Please discard this patch; the shell binary that runs the script that 
executes qemu is susceptible to the same issue and so the varibable 
needs to be unset even earlier. I'll send a better fix today.


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