[OE-core] [PATCH 2/3] packagegroup-core-tools-profile: Do not remove lttng-ust for musl and risc-v

[Khem Raj]

Signed-off-by: Khem Raj 
Cc: Jonathan Rajotte-Julien 
---
v2: Rebased

 .../packagegroups/packagegroup-core-tools-profile.bb   | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index 762c046636..3d8e0c2ed7 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -39,16 +39,13 @@ SYSTEMTAP_riscv64 = ""
 LTTNGUST = "lttng-ust"
 LTTNGUST_libc-musl = ""
 LTTNGUST_arc = ""
-LTTNGUST_riscv64 = ""
 
 LTTNGTOOLS = "lttng-tools"
 LTTNGTOOLS_libc-musl = ""
 LTTNGTOOLS_arc = ""
-LTTNGTOOLS_riscv64 = ""
 
 LTTNGMODULES = "lttng-modules"
 LTTNGMODULES_arc = ""
-LTTNGMODULES_riscv64 = ""
 
 BABELTRACE = "babeltrace"
 
-- 
2.21.0

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

[OE-core] [PATCH 3/3] gdb: Do not disable lttng-ust on risc-v

[Khem Raj]

Signed-off-by: Khem Raj 
Cc: Jonathan Rajotte-Julien 
---
v2: Rebased

 meta/recipes-devtools/gdb/gdb-common.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-devtools/gdb/gdb-common.inc 
b/meta/recipes-devtools/gdb/gdb-common.inc
index 57bc0dc773..a07625bb8d 100644
--- a/meta/recipes-devtools/gdb/gdb-common.inc
+++ b/meta/recipes-devtools/gdb/gdb-common.inc
@@ -6,7 +6,6 @@ DEPENDS = "expat zlib ncurses virtual/libiconv ${LTTNGUST} 
bison-native"
 LTTNGUST = "lttng-ust"
 LTTNGUST_arc = ""
 LTTNGUST_aarch64 = ""
-LTTNGUST_riscv64 = ""
 LTTNGUST_mipsarch = ""
 LTTNGUST_sh4 = ""
 LTTNGUST_libc-musl = ""
-- 
2.21.0

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

[OE-core] [PATCH V2 1/3] lttng: Enable tools and modules on riscv

[Khem Raj]

Latest version compiles on risv64 now

Signed-off-by: Khem Raj 
Cc: Jonathan Rajotte-Julien 
---
v2: Keep it disabled on musl for now

 meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb | 2 +-
 meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb   | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb 
b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
index 086254d3d3..15e75e51c9 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=c4613d1f8a9587bd7b366191830364b3 \
 
 inherit module
 
-COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm).*-linux'
+COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
 
 #https://lttng.org/files/lttng-modules/lttng-modules-2.10.7.tar.bz2
 SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
index 151e35e3c3..86418f14c0 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
@@ -28,7 +28,6 @@ PACKAGECONFIG[kmod] = "--with-kmod, --without-kmod, kmod"
 PACKAGECONFIG[manpages] = "--enable-man-pages, --disable-man-pages, 
asciidoc-native xmlto-native libxslt-native"
 PACKAGECONFIG_remove_libc-musl = "lttng-ust"
 PACKAGECONFIG_remove_arc = "lttng-ust"
-PACKAGECONFIG_remove_riscv64 = "lttng-ust"
 
 SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://x32.patch \
-- 
2.21.0

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

Re: [OE-core] [thud][PATCH] yocto-uninative: Correct sha256sum for aarch64

[Robert Joslyn]

On Mon, 2019-03-18 at 16:53 +, Manjukumar Harthikote Matha wrote:
> Hi,
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> > Of
> > Robert Joslyn
> > Sent: Tuesday, March 12, 2019 9:04 PM
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [thud][PATCH] yocto-uninative: Correct sha256sum
> > for aarch64
> > 
> > From: Michael Halstead 
> > 
> > Avoid uninative checksum warnings when building on aarch64
> > hardware.
> > 
> 
> On what machines does it fail? Should be backport this to thud
> v2.6.1?

It fails when building on an aarch64 build machine when uninative is
enabled. I realize that building on ARM hardware is probably uncommon,
but it'd be nice to fix the wrong checksum for the few of us that do.
For reference, the patch is a backport from master: https://git.openemb
edded.org/openembedded-
core/commit/meta/conf/distro/include?id=3ccc2de5f08fb2023abeeed39e23c68
dbc75725b

This is the error:

Build Configuration:
BB_VERSION   = "1.40.0"
BUILD_SYS= "aarch64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "qemux86-64"
DISTRO   = "poky"
DISTRO_VERSION   = "2.6.1"
TUNE_FEATURES= "m64 core2"
TARGET_FPU   = ""
meta 
meta-poky
meta-yocto-bsp   = "thud:f5a57e939e626a5b7c6de5b51799ca602ed355ed"

NOTE: Fetching uninative binary shim from http://downloads.yoctoproject
.org/releases/uninative/2.3/aarch64-nativesdk-
libc.tar.bz2;sha256sum=b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685ea
ed
WARNING: Checksum mismatch for local file
/home/robert/yocto/downloads/uninative/b7fbbaad1ec86d76eca84d83098f5052
5b8a4124cc8685eaed/aarch64-nativesdk-libc.tar.bz2
Cleaning and trying again.
WARNING: Renaming
/home/robert/yocto/downloads/uninative/b7fbbaad1ec86d76eca84d83098f5052
5b8a4124cc8685eaed/aarch64-nativesdk-libc.tar.bz2 to
/home/robert/yocto/downloads/uninative/b7fbbaad1ec86d76eca84d83098f5052
5b8a4124cc8685eaed/aarch64-nativesdk-libc.tar.bz2_bad-
checksum_69c5fd8458995457e9f655b8548b242c
WARNING: Checksum failure encountered with download of http://downloads
.yoctoproject.org/releases/uninative/2.3/aarch64-nativesdk-
libc.tar.bz2;sha256sum=b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685ea
ed - will attempt other sources if available
ERROR: Fetcher failure for URL: 'http://downloads.yoctoproject.org/rele
ases/uninative/2.3/aarch64-nativesdk-
libc.tar.bz2;sha256sum=b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685ea
ed'. Checksum mismatch!
File:
'/home/robert/yocto/downloads/uninative/b7fbbaad1ec86d76eca84d83098f505
25b8a4124cc8685eaed/aarch64-nativesdk-libc.tar.bz2' has sha256 checksum
e495046969c796b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed when
b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed was expected
If this change is expected (e.g. you have upgraded to a new version
without updating the checksums) then you can use these lines within the
recipe:
SRC_URI[md5sum] = "69c5fd8458995457e9f655b8548b242c"
SRC_URI[sha256sum] =
"e495046969c796b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
Otherwise you should retry the download and/or check with upstream to
determine if the file has become corrupted or otherwise unexpectedly
modified.


Thanks,
Robert

> 
> Thanks,
> Manju
> 
> 
> > Signed-off-by: Michael Halstead 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/conf/distro/include/yocto-uninative.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/conf/distro/include/yocto-uninative.inc
> > b/meta/conf/distro/include/yocto-uninative.inc
> > index c9d502ba4f..0d484f6c3c 100644
> > --- a/meta/conf/distro/include/yocto-uninative.inc
> > +++ b/meta/conf/distro/include/yocto-uninative.inc
> > @@ -9,7 +9,7 @@
> >  UNINATIVE_MAXGLIBCVERSION = "2.28"
> > 
> >  UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/unina
> > tive/2.3/"
> > -UNINATIVE_CHECKSUM[aarch64] ?=
> > "b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
> > +UNINATIVE_CHECKSUM[aarch64] ?=
> > "e495046969c796b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
> >  UNINATIVE_CHECKSUM[i686] ?=
> > "44253cddbf629082568cea4fff59419106871a0cf81b4845b5d34e7014887b20"
> >  UNINATIVE_CHECKSUM[x86_64] ?=
> > "c6954563dad3c95608117c6fc328099036c832bbd924ebf5fdccb622fc0a8684"
> > 
> > --
> > 2.19.2
> > 
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[OE-core] [PATCH 00/26] thud patch review

[Armin Kuster]

Responses should be made by Wed March 20th 22:00:00 UTC 2019

The following changes since commit f5a57e939e626a5b7c6de5b51799ca602ed355ed:

  mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib stable/thud-next
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next

Alexander Kanavin (1):
  ca-certificates: upgrade 20180409 -> 20190110

André Draszik (1):
  systemd: RDEPENDS on util-linux-umount

Changqing Li (1):
  libsndfile1: Security fix CVE-2018-19432

Chen Qi (1):
  target-sdk-provides-dummy: add more perl modules to avoid populate_sdk
failure

Douglas Royds (1):
  libpam: libpamc is licensed under its own BSD-style licence

George McCollister (1):
  systemd: fix CVE-2019-6454

Jonathan Rajotte-Julien (3):
  lttng-ust: update to 2.10.3
  lttng-modules: update to 2.10.9
  lttng-tools: update to 2.9.11

Mark Hatle (10):
  gitsm.py: Fix when a submodule is defined, but not initialized
  gitsm.py: Add support for alternative URL formats from submodule files
  tests/fetch.py: Add alternative gitsm test case
  gitsm.py: Optimize code and attempt to resolve locking issue
  gitsm.py: revise unpack
  gitsm.py: Rework the shallow fetcher and test case
  gitsm.py: Refactor the functions and simplify the class
  gitsm.py: Fix relative URLs
  gitsmy.py: Fix unpack of submodules of submodules
  gitsm: The fetcher did not process some recursive submodules properly.

Ming Liu (1):
  rm_work: sort the value of do_build dependencies

Oleksandr Kravchuk (1):
  target-sdk-provides-dummy: add perl-module-overload

Richard Purdie (3):
  target-sdk-provides-dummy: Extend to -dev and -src packages
  systemd: Update recent CVE patches
  kernel: Ensure an initramfs is added if configured

Robert Yang (1):
  send-error-report: Add --no-ssl to use http protocol

Ross Burton (1):
  libpng: fix CVE-2019-7317

 bitbake/lib/bb/fetch2/gitsm.py | 253 +
 bitbake/lib/bb/tests/fetch.py  |  70 +-
 meta/classes/kernel.bbclass|   4 +-
 meta/classes/rm_work.bbclass   |   3 +-
 .../recipes-core/meta/target-sdk-provides-dummy.bb |  14 ++
 ...-not-store-the-iovec-entry-for-process-co.patch |   6 +-
 ...ld-set-a-limit-on-the-number-of-fields-1k.patch |  56 -
 ...nald-set-a-limit-on-the-number-of-fields.patch} |  93 ++--
 ...nal-fix-out-of-bounds-read-CVE-2018-16866.patch |  49 
 .../0027-journal-fix-syslog_parse_identifier.patch |  77 ---
 ...not-remove-multiple-spaces-after-identifi.patch |  84 ---
 .../systemd/systemd/CVE-2019-6454.patch| 210 +
 ...e-receive-an-invalid-dbus-message-ignore-.patch |  61 +
 meta/recipes-core/systemd/systemd_239.bb   |  10 +-
 meta/recipes-extended/pam/libpam_1.3.0.bb  |   4 +-
 ...ose-sk-wmem-in-sock_exceed_buf_limit-trac.patch |  67 --
 ...g-modules_2.10.7.bb => lttng-modules_2.10.9.bb} |   5 +-
 ...ow-multiple-attempts-to-connect-to-relayd.patch |  17 +-
 ...{lttng-tools_2.9.5.bb => lttng-tools_2.9.11.bb} |   4 +-
 .../{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}   |   4 +-
 .../libpng/libpng/CVE-2019-7317.patch  |  20 ++
 meta/recipes-multimedia/libpng/libpng_1.6.36.bb|   3 +-
 .../libsndfile/libsndfile1/CVE-2018-19432.patch| 115 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |   1 +
 ...tes_20180409.bb => ca-certificates_20190110.bb} |   2 +-
 scripts/send-error-report  |  11 +-
 26 files changed, 758 insertions(+), 485 deletions(-)
 delete mode 100644 
meta/recipes-core/systemd/systemd/0025-journald-set-a-limit-on-the-number-of-fields-1k.patch
 rename 
meta/recipes-core/systemd/systemd/{0026-journal-remote-set-a-limit-on-the-number-of-fields-i.patch
 => 0025-journald-set-a-limit-on-the-number-of-fields.patch} (47%)
 create mode 100644 
meta/recipes-core/systemd/systemd/0026-journal-fix-out-of-bounds-read-CVE-2018-16866.patch
 delete mode 100644 
meta/recipes-core/systemd/systemd/0027-journal-fix-syslog_parse_identifier.patch
 delete mode 100644 
meta/recipes-core/systemd/systemd/0028-journal-do-not-remove-multiple-spaces-after-identifi.patch
 create mode 100644 meta/recipes-core/systemd/systemd/CVE-2019-6454.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/sd-bus-if-we-receive-an-invalid-dbus-message-ignore-.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-Fix-net-expose-sk-wmem-in-sock_exceed_buf_limit-trac.patch
 rename meta/recipes-kernel/lttng/{lttng-modules_2.10.7.bb => 
lttng-modules_2.10.9.bb} (85%)
 rename meta/recipes-kernel/lttng/{lttng-tools_2.9.5.bb => 
lttng-tools_2.9.11.bb} (97%)
 rename meta/recipes-kernel/lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb} 
(90%)
 create mode 100644 meta/recipes-multimedia/libpng/libpng/CVE-2019-7317.patch
 create mode 100644 
meta/recipes-multimedia/libsndfile/libs

[OE-core] [PATCH] oeqa/manual/toaster: updated test id naming

[Yeoh Ee Peng]

All test id (eg. @alias) inside manual testcase file shall follow the same
test id naming convention from oeqa automated tests (eg. selftest,
runtime, sdk, etc), where the test id consists of
... Furthermore, there shall be
only 1 unique test_module per each manual testcases file, where
test_module match the file name itself.

This file was using test_module name that does not match the file name
itself. Fixed test_module name as well as the test_suite name.

Signed-off-by: Yeoh Ee Peng 
---
 meta/lib/oeqa/manual/toaster-managed-mode.json   | 130 +++
 meta/lib/oeqa/manual/toaster-unmanaged-mode.json |  56 +-
 2 files changed, 93 insertions(+), 93 deletions(-)

diff --git a/meta/lib/oeqa/manual/toaster-managed-mode.json 
b/meta/lib/oeqa/manual/toaster-managed-mode.json
index ba0658f..812f57d 100644
--- a/meta/lib/oeqa/manual/toaster-managed-mode.json
+++ b/meta/lib/oeqa/manual/toaster-managed-mode.json
@@ -1,7 +1,7 @@
 [
   {
 "test": {
-  "@alias": "toaster.toaster.All_layers:_default_view",
+  "@alias": 
"toaster-managed-mode.toaster-managed.All_layers:_default_view",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -47,7 +47,7 @@
   },
   {
 "test": {
-  "@alias": "toaster.toaster.All_layers:_Add/delete_layers",
+  "@alias": 
"toaster-managed-mode.toaster-managed.All_layers:_Add/delete_layers",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -85,7 +85,7 @@
   },
   {
 "test": {
-  "@alias": "toaster.toaster.All_targets:_Default_view",
+  "@alias": 
"toaster-managed-mode.toaster-managed.All_targets:_Default_view",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -119,7 +119,7 @@
   },
   {
 "test": {
-  "@alias": "toaster.toaster.Configuration_variables:_default_view",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Configuration_variables:_default_view",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -153,7 +153,7 @@
   },
   {
 "test": {
-  "@alias": "toaster.toaster.Configuration_variables:_Test_UI_elements",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Configuration_variables:_Test_UI_elements",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -215,7 +215,7 @@
   },
   {
 "test": {
-  "@alias": "toaster.toaster.Project_builds:_Default_view",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Project_builds:_Default_view",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -249,7 +249,7 @@
   },
   {
 "test": {
-  "@alias": 
"toaster.toaster.Project_builds:_Sorting_the_project_builds_table",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Project_builds:_Sorting_the_project_builds_table",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -287,7 +287,7 @@
   },
   {
 "test": {
-  "@alias": 
"toaster.toaster.Project_builds:_customize_the_columns_of_the_table",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Project_builds:_customize_the_columns_of_the_table",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -321,7 +321,7 @@
   },
   {
 "test": {
-  "@alias": 
"toaster.toaster.Project_builds:_filter_the_contents_of_the_table",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Project_builds:_filter_the_contents_of_the_table",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -355,7 +355,7 @@
   },
   {
 "test": {
-  "@alias": 
"toaster.toaster.Project_builds:_search_the_contents_of_the_table",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Project_builds:_search_the_contents_of_the_table",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -393,7 +393,7 @@
   },
   {
 "test": {
-  "@alias": "toaster.toaster.Layer_details_page:_Default_view",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Layer_details_page:_Default_view",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -471,7 +471,7 @@
   },
   {
 "test": {
-  "@alias": "toaster.toaster.Layer_details_page:_UI_functionality",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Layer_details_page:_UI_functionality",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -517,7 +517,7 @@
   },
   {
 "test": {
-  "@alias": "toaster.toaster.Importing_new_layers",
+  "@alias": "toaster-managed-mode.toaster-managed.Importing_new_layers",
   "author": [
 {
   "email": "stanciux.mih...@intel.com",
@@ -547,7 +547,7 @@
   },
   {
 "test": {
-  "@alias": 
"toaster.toaster.Layer_details_page:_UI_functionality_for_imported_layers",
+  "@alias": 
"toaster-managed-mode.toaster-managed.Layer_details_page:_UI_functionality_for_imported_layers",

[OE-core] [PATCH 00/13] Sumo patch review

[Armin Kuster]

Responses should be made by Wed March 20th 21:00:00 UTC 2019

The following changes since commit b28f5672ab55ea303727e9f03bc594c7774d597e:

  bitbake: COW: Fix StopIteration warning (2019-03-13 14:38:56 -0700)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib stable/sumo-next
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/sumo-next

Bruce Ashfield (1):
  linux-yocto/4.14: configuration cleanups

Chen Qi (2):
  systemd: fix CVE-2018-15686
  systemd: fix CVE-2018-15688

George McCollister (5):
  systemd: fix CVE-2018-15687
  systemd: Security fix CVE-2018-16864
  systemd: Security fix CVE-2018-16865
  systemd: fix CVE-2018-6954
  systemd: fix CVE-2019-6454

Marcus Cooper (1):
  systemd: Security fix CVE-2018-16866

Mingli Yu (1):
  logrotate.py: restore /etc/logrotate.d/wtmp

ROGEZ Matthieu (1):
  systemd: Fix typo in root home variable.

Richard Purdie (1):
  oeqa/runtime/dnf: Fix test error when static libs are enabled

Stefan Agner (1):
  run-postinsts: for dpkg/opkg, do not rely on /etc/*-postinsts

 meta/lib/oeqa/runtime/cases/dnf.py |2 +-
 meta/lib/oeqa/runtime/cases/logrotate.py   |6 +-
 ...sive-let-s-rework-the-recursive-logic-to-.patch |  252 +++
 ...eserializing-state-always-use-read_line-L.patch |  250 +++
 ...sure-we-have-enough-space-for-the-DHCP6-o.patch |   39 +
 ...n-t-resolve-pathnames-when-traversing-rec.patch |  643 +++
 .../systemd/systemd/0002-Make-tmpfiles-safe.patch  | 1828 
 ...-not-store-the-iovec-entry-for-process-co.patch |  193 +++
 ...ld-set-a-limit-on-the-number-of-fields-1k.patch |   60 +
 ...ote-set-a-limit-on-the-number-of-fields-i.patch |   79 +
 ...nal-fix-out-of-bounds-read-CVE-2018-16866.patch |   49 +
 .../systemd/systemd/CVE-2019-6454.patch|  210 +++
 ...e-receive-an-invalid-dbus-message-ignore-.patch |   61 +
 meta/recipes-core/systemd/systemd_237.bb   |   13 +-
 .../run-postinsts/run-postinsts/run-postinsts  |   21 +-
 .../run-postinsts/run-postinsts.service|1 -
 meta/recipes-kernel/linux/linux-yocto-rt_4.14.bb   |2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.14.bb |2 +-
 meta/recipes-kernel/linux/linux-yocto_4.14.bb  |2 +-
 19 files changed, 3697 insertions(+), 16 deletions(-)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-chown-recursive-let-s-rework-the-recursive-logic-to-.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-core-when-deserializing-state-always-use-read_line-L.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-dhcp6-make-sure-we-have-enough-space-for-the-DHCP6-o.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-tmpfiles-don-t-resolve-pathnames-when-traversing-rec.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0002-Make-tmpfiles-safe.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0024-journald-do-not-store-the-iovec-entry-for-process-co.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0025-journald-set-a-limit-on-the-number-of-fields-1k.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0026-journal-remote-set-a-limit-on-the-number-of-fields-i.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0027-journal-fix-out-of-bounds-read-CVE-2018-16866.patch
 create mode 100644 meta/recipes-core/systemd/systemd/CVE-2019-6454.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/sd-bus-if-we-receive-an-invalid-dbus-message-ignore-.patch

-- 
2.7.4

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

[OE-core] [PATCH] [PATCH] ofono: upgrade to 1.28

[Hong Liu]

1.Upgrade ofono from 1.25 to 1.28.

2.use-python3.patch has been merged.

Signed-off-by: Hong Liu 
---
 .../ofono/ofono/use-python3.patch | 27 ---
 meta/recipes-connectivity/ofono/ofono_1.25.bb |  9 ---
 meta/recipes-connectivity/ofono/ofono_1.28.bb |  8 ++
 3 files changed, 8 insertions(+), 36 deletions(-)
 delete mode 100644 meta/recipes-connectivity/ofono/ofono/use-python3.patch
 delete mode 100644 meta/recipes-connectivity/ofono/ofono_1.25.bb
 create mode 100644 meta/recipes-connectivity/ofono/ofono_1.28.bb

diff --git a/meta/recipes-connectivity/ofono/ofono/use-python3.patch 
b/meta/recipes-connectivity/ofono/ofono/use-python3.patch
deleted file mode 100644
index 7b84075257..00
--- a/meta/recipes-connectivity/ofono/ofono/use-python3.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-set-ddr should use Python3 like all the other tests.
-
-Upstream-Status: Submitted
-Signed-off-by: Ross Burton 
-
-From 17b69cd1da4c5c5f732acb38ca1602446c567ee7 Mon Sep 17 00:00:00 2001
-From: Ross Burton 
-Date: Mon, 29 Jan 2018 11:31:25 +
-Subject: [PATCH] test/setddr: use Python 3
-
-All the other tests use Python 3, so this should to.

- test/set-ddr | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/test/set-ddr b/test/set-ddr
-index 5d061b95..33631f31 100755
 a/test/set-ddr
-+++ b/test/set-ddr
-@@ -1,4 +1,4 @@
--#!/usr/bin/python
-+#!/usr/bin/python3
- 
- import sys
- import dbus
--- 
-2.11.0
diff --git a/meta/recipes-connectivity/ofono/ofono_1.25.bb 
b/meta/recipes-connectivity/ofono/ofono_1.25.bb
deleted file mode 100644
index 3688b9d2fc..00
--- a/meta/recipes-connectivity/ofono/ofono_1.25.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-require ofono.inc
-
-SRC_URI  = "\
-  ${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
-  file://ofono \
-  file://use-python3.patch \
-"
-SRC_URI[md5sum] = "31450cabdd8dbbf3f808ea2f2f066863"
-SRC_URI[sha256sum] = 
"eb011fcd3080e93f3a56f96be60350b6595a8b5f36b61646312ba41b0bcb0d75"
diff --git a/meta/recipes-connectivity/ofono/ofono_1.28.bb 
b/meta/recipes-connectivity/ofono/ofono_1.28.bb
new file mode 100644
index 00..48bf2d3edc
--- /dev/null
+++ b/meta/recipes-connectivity/ofono/ofono_1.28.bb
@@ -0,0 +1,8 @@
+require ofono.inc
+
+SRC_URI  = "\
+  ${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
+  file://ofono \
+"
+SRC_URI[md5sum] = "3a5406565b552b16602610619b034967"
+SRC_URI[sha256sum] = 
"93bb2cedef54f897dd5200e22b072a6e38b5d9b44be57eebbbe8d513f0beb0e4"
-- 
2.20.1



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

Re: [OE-core] [PATCH v3] openssl: Remove the c_rehash shell re-implementation

[Martin Jansa]

Just FYI:

This won't work if someone uses only openssl10 in the image (a bit
difficult to do with current master, but still some people have to do it),
in case someone needs it as well, here is how Gentoo makes ca-certificate
backwards compatible with old openssl:
https://github.com/gentoo/gentoo/commit/03f9b674ca3315198c72849e8dd77583974759c2#diff-1801ddca78e57240592ef16b1c5262e7
more details in:
https://bugs.gentoo.org/653382

Basically using (good old) shell c_rehash implementation from separate
recipe:
https://github.com/gentoo/gentoo/blob/master/app-misc/c_rehash/c_rehash-1.7-r1.ebuild
instead of "openssl rehash" in update-ca-certificates script.

Cheers,

On Tue, Mar 19, 2019 at 1:41 AM Otavio Salvador 
wrote:

> We had a c_rehash shell re-implementation being used for the native
> package however the ca-certificates now uses the openssl rehash
> internal application so there is no use for the c_rehash anymore.
>
> Signed-off-by: Otavio Salvador 
> ---
>
> Changes in v3:
> - remove c_rehash completely
> - fix ca-certificates recipe comment
>
> Changes in v2:
> - updated commit log
>
>  .../openssl/openssl/openssl-c_rehash.sh   | 222 --
>  .../openssl/openssl_1.1.1a.bb |  13 +-
>  .../ca-certificates_20190110.bb   |   2 +-
>  3 files changed, 2 insertions(+), 235 deletions(-)
>  delete mode 100644
> meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
>
> diff --git a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> deleted file mode 100644
> index 6620fdcb53..00
> --- a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> +++ /dev/null
> @@ -1,222 +0,0 @@
> -#!/bin/sh
> -#
> -# Ben Secrest 
> -#
> -# sh c_rehash script, scan all files in a directory
> -# and add symbolic links to their hash values.
> -#
> -# based on the c_rehash perl script distributed with openssl
> -#
> -# LICENSE: See OpenSSL license
> -# ^^acceptable?^^
> -#
> -
> -# default certificate location
> -DIR=/etc/openssl
> -
> -# for filetype bitfield
> -IS_CERT=$(( 1 << 0 ))
> -IS_CRL=$(( 1 << 1 ))
> -
> -
> -# check to see if a file is a certificate file or a CRL file
> -# arguments:
> -#   1. the filename to be scanned
> -# returns:
> -#   bitfield of file type; uses ${IS_CERT} and ${IS_CRL}
> -#
> -check_file()
> -{
> -local IS_TYPE=0
> -
> -# make IFS a newline so we can process grep output line by line
> -local OLDIFS=${IFS}
> -IFS=$( printf "\n" )
> -
> -# XXX: could be more efficient to have two 'grep -m' but is -m
> portable?
> -for LINE in $( grep '^-BEGIN .*-' ${1} )
> -do
> -   if echo ${LINE} \
> -   | grep -q -E '^-BEGIN (X509 |TRUSTED )?CERTIFICATE-'
> -   then
> -   IS_TYPE=$(( ${IS_TYPE} | ${IS_CERT} ))
> -
> -   if [ $(( ${IS_TYPE} & ${IS_CRL} )) -ne 0 ]
> -   then
> -   break
> -   fi
> -   elif echo ${LINE} | grep -q '^-BEGIN X509 CRL-'
> -   then
> -   IS_TYPE=$(( ${IS_TYPE} | ${IS_CRL} ))
> -
> -   if [ $(( ${IS_TYPE} & ${IS_CERT} )) -ne 0 ]
> -   then
> -   break
> -   fi
> -   fi
> -done
> -
> -# restore IFS
> -IFS=${OLDIFS}
> -
> -return ${IS_TYPE}
> -}
> -
> -
> -#
> -# use openssl to fingerprint a file
> -#arguments:
> -#  1. the filename to fingerprint
> -#  2. the method to use (x509, crl)
> -#returns:
> -#  none
> -#assumptions:
> -#  user will capture output from last stage of pipeline
> -#
> -fingerprint()
> -{
> -${SSL_CMD} ${2} -fingerprint -noout -in ${1} | sed 's/^.*=//' | tr -d
> ':'
> -}
> -
> -
> -#
> -# link_hash - create links to certificate files
> -#arguments:
> -#   1. the filename to create a link for
> -#  2. the type of certificate being linked (x509, crl)
> -#returns:
> -#  0 on success, 1 otherwise
> -#
> -link_hash()
> -{
> -local FINGERPRINT=$( fingerprint ${1} ${2} )
> -local HASH=$( ${SSL_CMD} ${2} -hash -noout -in ${1} )
> -local SUFFIX=0
> -local LINKFILE=''
> -local TAG=''
> -
> -if [ ${2} = "crl" ]
> -then
> -   TAG='r'
> -fi
> -
> -LINKFILE=${HASH}.${TAG}${SUFFIX}
> -
> -while [ -f ${LINKFILE} ]
> -do
> -   if [ ${FINGERPRINT} = $( fingerprint ${LINKFILE} ${2} ) ]
> -   then
> -   echo "NOTE: Skipping duplicate file ${1}" >&2
> -   return 1
> -   fi
> -
> -   SUFFIX=$(( ${SUFFIX} + 1 ))
> -   LINKFILE=${HASH}.${TAG}${SUFFIX}
> -done
> -
> -echo "${3} => ${LINKFILE}"
> -
> -# assume any system with a POSIX shell will either support symlinks or
> -# do something to handle this gracefully
> -ln -s ${3} ${LINKFILE}
> -
> -return 0
> -}
> -
> -
> -# hash_dir create hash links in a given directory
> -hash_dir()
> -{
> -echo "Doing ${1}"
> -
> -cd ${1}
> -
> -ls -1 * 2>/de

[OE-core] [PATCH v3] openssl: Remove the c_rehash shell re-implementation

[Otavio Salvador]

We had a c_rehash shell re-implementation being used for the native
package however the ca-certificates now uses the openssl rehash
internal application so there is no use for the c_rehash anymore.

Signed-off-by: Otavio Salvador 
---

Changes in v3:
- remove c_rehash completely
- fix ca-certificates recipe comment

Changes in v2:
- updated commit log

 .../openssl/openssl/openssl-c_rehash.sh   | 222 --
 .../openssl/openssl_1.1.1a.bb |  13 +-
 .../ca-certificates_20190110.bb   |   2 +-
 3 files changed, 2 insertions(+), 235 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh

diff --git a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh 
b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
deleted file mode 100644
index 6620fdcb53..00
--- a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
+++ /dev/null
@@ -1,222 +0,0 @@
-#!/bin/sh
-#
-# Ben Secrest 
-#
-# sh c_rehash script, scan all files in a directory
-# and add symbolic links to their hash values.
-#
-# based on the c_rehash perl script distributed with openssl
-#
-# LICENSE: See OpenSSL license
-# ^^acceptable?^^
-#
-
-# default certificate location
-DIR=/etc/openssl
-
-# for filetype bitfield
-IS_CERT=$(( 1 << 0 ))
-IS_CRL=$(( 1 << 1 ))
-
-
-# check to see if a file is a certificate file or a CRL file
-# arguments:
-#   1. the filename to be scanned
-# returns:
-#   bitfield of file type; uses ${IS_CERT} and ${IS_CRL}
-#
-check_file()
-{
-local IS_TYPE=0
-
-# make IFS a newline so we can process grep output line by line
-local OLDIFS=${IFS}
-IFS=$( printf "\n" )
-
-# XXX: could be more efficient to have two 'grep -m' but is -m portable?
-for LINE in $( grep '^-BEGIN .*-' ${1} )
-do
-   if echo ${LINE} \
-   | grep -q -E '^-BEGIN (X509 |TRUSTED )?CERTIFICATE-'
-   then
-   IS_TYPE=$(( ${IS_TYPE} | ${IS_CERT} ))
-
-   if [ $(( ${IS_TYPE} & ${IS_CRL} )) -ne 0 ]
-   then
-   break
-   fi
-   elif echo ${LINE} | grep -q '^-BEGIN X509 CRL-'
-   then
-   IS_TYPE=$(( ${IS_TYPE} | ${IS_CRL} ))
-
-   if [ $(( ${IS_TYPE} & ${IS_CERT} )) -ne 0 ]
-   then
-   break
-   fi
-   fi
-done
-
-# restore IFS
-IFS=${OLDIFS}
-
-return ${IS_TYPE}
-}
-
-
-#
-# use openssl to fingerprint a file
-#arguments:
-#  1. the filename to fingerprint
-#  2. the method to use (x509, crl)
-#returns:
-#  none
-#assumptions:
-#  user will capture output from last stage of pipeline
-#
-fingerprint()
-{
-${SSL_CMD} ${2} -fingerprint -noout -in ${1} | sed 's/^.*=//' | tr -d ':'
-}
-
-
-#
-# link_hash - create links to certificate files
-#arguments:
-#   1. the filename to create a link for
-#  2. the type of certificate being linked (x509, crl)
-#returns:
-#  0 on success, 1 otherwise
-#
-link_hash()
-{
-local FINGERPRINT=$( fingerprint ${1} ${2} )
-local HASH=$( ${SSL_CMD} ${2} -hash -noout -in ${1} )
-local SUFFIX=0
-local LINKFILE=''
-local TAG=''
-
-if [ ${2} = "crl" ]
-then
-   TAG='r'
-fi
-
-LINKFILE=${HASH}.${TAG}${SUFFIX}
-
-while [ -f ${LINKFILE} ]
-do
-   if [ ${FINGERPRINT} = $( fingerprint ${LINKFILE} ${2} ) ]
-   then
-   echo "NOTE: Skipping duplicate file ${1}" >&2
-   return 1
-   fi  
-
-   SUFFIX=$(( ${SUFFIX} + 1 ))
-   LINKFILE=${HASH}.${TAG}${SUFFIX}
-done
-
-echo "${3} => ${LINKFILE}"
-
-# assume any system with a POSIX shell will either support symlinks or
-# do something to handle this gracefully
-ln -s ${3} ${LINKFILE}
-
-return 0
-}
-
-
-# hash_dir create hash links in a given directory
-hash_dir()
-{
-echo "Doing ${1}"
-
-cd ${1}
-
-ls -1 * 2>/dev/null | while read FILE
-do
-if echo ${FILE} | grep -q -E '^[[:xdigit:]]{8}\.r?[[:digit:]]+$' \
-   && [ -h "${FILE}" ]
-then
-rm ${FILE}
-fi
-done
-
-ls -1 *.pem *.cer *.crt *.crl 2>/dev/null | while read FILE
-do
-   REAL_FILE=${FILE}
-   # if we run on build host then get to the real files in rootfs
-   if [ -n "${SYSROOT}" -a -h ${FILE} ]
-   then
-   FILE=$( readlink ${FILE} )
-   # check the symlink is absolute (or dangling in other word)
-   if [ "x/" = "x$( echo ${FILE} | cut -c1 -)" ]
-   then
-   REAL_FILE=${SYSROOT}/${FILE}
-   fi
-   fi
-
-   check_file ${REAL_FILE}
-local FILE_TYPE=${?}
-   local TYPE_STR=''
-
-if [ $(( ${FILE_TYPE} & ${IS_CERT} )) -ne 0 ]
-then
-TYPE_STR='x509'
-elif [ $(( ${FILE_TYPE} & ${IS_CRL} )) -ne 0 ]
-then
-TYPE_STR='crl'
-else
-echo "NOTE: ${FILE} does not contain

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Otavio Salvador]

On Mon, Mar 18, 2019 at 8:56 PM Richard Purdie
 wrote:
> On Mon, 2019-03-18 at 16:52 -0700, Andre McCurdy wrote:
> > On Mon, Mar 18, 2019 at 4:35 PM Richard Purdie
> >  wrote:
> > > I went to have a look at how this upstream C utility was going and
> > > found that they've moved to github issues and there is no such
> > > issue
> > > open.
> >
> > It's already been implemented and is present in openssl 1.1.0:
> >
> >   https://www.openssl.org/docs/man1.1.0/man1/rehash.html
>
> Great, it felt like I was missing something!
>
> Otavio: Why do we need c_rehash on target at all, can we use rehash?

Likely, I am checking what would take to rework it all to use it. Will
reply soon...

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Richard Purdie]

On Mon, 2019-03-18 at 16:52 -0700, Andre McCurdy wrote:
> On Mon, Mar 18, 2019 at 4:35 PM Richard Purdie
>  wrote:
> > I went to have a look at how this upstream C utility was going and
> > found that they've moved to github issues and there is no such
> > issue
> > open.
> 
> It's already been implemented and is present in openssl 1.1.0:
> 
>   https://www.openssl.org/docs/man1.1.0/man1/rehash.html

Great, it felt like I was missing something!

Otavio: Why do we need c_rehash on target at all, can we use rehash?

Cheers,

Richard

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

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Andre McCurdy]

On Mon, Mar 18, 2019 at 4:35 PM Richard Purdie
 wrote:
>
> I went to have a look at how this upstream C utility was going and
> found that they've moved to github issues and there is no such issue
> open.

It's already been implemented and is present in openssl 1.1.0:

  https://www.openssl.org/docs/man1.1.0/man1/rehash.html
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Richard Purdie]

On Mon, 2019-03-18 at 10:36 -0300, Otavio Salvador wrote:
> We had a c_rehash shell re-implementation being used for the native
> package and there is no reason to not use it as well for the
> target. This allows it to be available without the need of perl being
> installed.
> 
> This partially reverts OE-Core:d2b1a889ef (openssl: move c_rehash pkg
> to avoid perl dep) but still allows the removal of perl
> dependency.
> 
> The respective re-implementation was already in use here at OE-Core
> by
> the OpenSSL 1.0 recipe (since 2016) and were removed from the target
> recipe during the upgrade to the 1.1 release. So it now aligns the
> native and target recipes.
> 
> ,
> > Author: Otavio Salvador 
> > Date:   Mon May 23 17:45:25 2016 -0300
> > 
> > openssl: Add Shell-Script based c_rehash utility
> > 
> > The PLD Linux distribution has ported the c_rehash[1] utility
> > from
> > Perl to Shell-Script, allowing it to be shipped by default.
> > 
> > 1. 
> > https://git.pld-linux.org/?p=packages/openssl.git;a=blob;f=openssl-c_rehash.sh;h=0ea22637ee6dbce845a9e2caf62540aaaf5d0761
> > 
> > The OpenSSL upstream intends[2] to convert the utility for C
> > however did not yet finished the conversion.
> > 
> > 2. https://rt.openssl.org/Ticket/Display.html?id=2324
> > 
> > This patch adds this script and thus removed the Perl
> > requirement
> > for it.
> > 
> > Signed-off-by: Otavio Salvador 
> > Signed-off-by: Richard Purdie <
> > richard.pur...@linuxfoundation.org>
> `

I went to have a look at how this upstream C utility was going and
found that they've moved to github issues and there is no such issue
open.

The closest I could get to patches was 
http://openssl.6102.n7.nabble.com/openssl-org-3505-rewrite-c-rehash-in-C-td53069.html

Could you open a github issue asking if they can move to a C or shell
util as some projects don't want a perl dependency like that? I'd like
to understand upstream's intentions in this area. Do they have a reason
for using perl here that we're missing?

Cheers,

Richard

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

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Otavio Salvador]

Hello Richard,

On Mon, Mar 18, 2019 at 8:18 PM Richard Purdie
 wrote:
...
> I think the commit message could use some work but IMO this patch
> probably is worth it for OE.

What do you think I could improve on it?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Richard Purdie]

I was asked for my views on this thread.

OE is primarily targeting embedded systems and removing a perl
dependency from target is something we do care about and a significant
win. 

As such I'm tempted to merge this patch in for that reason. The fact
we're successfully using it at rootfs time is a good sign.

I was also made aware that on target ca-certificates is currently
broken by the last change in this area and this patch does in fact fix
that again. This tells us nobody uses it that heavily on target as
nobody noticed. It also means we could do with some better tests :/.

I think the commit message could use some work but IMO this patch
probably is worth it for OE.

I also note with interest that upstream are writing a C version as that
would solve much of this debate once and for all meaning we might not
have to carry this change forever. It would be good if the new upstream
version cared about sysroot style usage...

Cheers,

Richard


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

Re: [OE-core] [PATCH] tzdata: Add tzdata-all package

[Paul Barker]

On Mon, 18 Mar 2019, at 21:30, Burton, Ross wrote:
> On Mon, 18 Mar 2019 at 17:10, Paul Barker  wrote:
> > That is a good argument. I just checked the difference in image sizes 
> > though (from buildhistory):
> >
> > core-image-minimal + tzdata = 8,868 kB
> > core-image-minimal + tzdata-all = 15,788 kB
> >
> > So it's probably not an appropriate change for everyone.
> 
> Agreed, and I didn't suggest that we switch to installing all of the
> tzdata by default for that reason.
> 

My concern is for recipes defined outside oe-core that pull in "tzdata". Do we 
just mention this in the release notes and leave people to manually update 
their dependencies if they require a minimal image size?

If we go this route we should define a new "tzdata-minimal" package which 
contains what's currently in "tzdata".

I also think Otavio has the right idea on calculating the dependency list 
dynamically so we don't have to update it for any future change to PACKAGES in 
this recipe.

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tzdata: Add tzdata-all package

[Burton, Ross]

On Mon, 18 Mar 2019 at 17:10, Paul Barker  wrote:
> That is a good argument. I just checked the difference in image sizes though 
> (from buildhistory):
>
> core-image-minimal + tzdata = 8,868 kB
> core-image-minimal + tzdata-all = 15,788 kB
>
> So it's probably not an appropriate change for everyone.

Agreed, and I didn't suggest that we switch to installing all of the
tzdata by default for that reason.

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

Re: [OE-core] [PATCH 1/2] mesa: Update 18.3.4 -> 19.0.0

[Fabio Berton]

I sent a v2 adding python3-mako-native to DEPENDS.

On Mon, Mar 18, 2019 at 5:58 PM Otavio Salvador
 wrote:
>
> Hello Richard,
>
> On Mon, Mar 18, 2019 at 11:00 AM Richard Purdie
>  wrote:
> > On Fri, 2019-03-15 at 18:21 -0300, Fabio Berton wrote:
> > >   - Patch 0005-egl-add-missing-include-stddef.h-in-egldevice.h.patch
> > > was applied on commit e68777c87ceed02ab199b32f941778c3cf97c794.
> > >   - Refresh all patches
> > >   - mesa 19.0.0 deprecated the use of autotools and we need to add
> > > --enable-autotools flag. For details see mesa commit:
> > > e68777c87ceed02ab199b32f941778c3cf97c794
> > >
> > >   The complete change log can be found here:
> > > https://www.mesa3d.org/relnotes/19.0.0.html
> >
> > This failed pretty much everywhere, e.g.:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/407
> >
> > I think it will be too late to get this into 2.7.
>
> We are looking at this here; we intend to have it working anyway so we
> can decide if it goes on 2.7 or not.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 2/2] mesa: Convert recipe to use meson build system

[Fabio Berton]

  - Remove all non related meson patches
  - Change radeon driver to r100
  - Add python3-mako-native to DEPENDS

Based on https://patchwork.openembedded.org/patch/158748/

Signed-off-by: Fabio Berton 
---
 ...0001-Simplify-wayland-scanner-lookup.patch | 44 --
 ...k-for-all-linux-host_os-combinations.patch | 41 +
 ...-winsys-svga-drm-Include-sys-types.h.patch | 35 ---
 ...M-version-when-using-LLVM-Git-releas.patch | 45 --
 ...R-for-defining-WAYLAND_PROTOCOLS_DAT.patch | 38 
 meta/recipes-graphics/mesa/mesa.inc   | 59 +--
 meta/recipes-graphics/mesa/mesa_19.0.0.bb |  5 +-
 7 files changed, 69 insertions(+), 198 deletions(-)
 delete mode 100644 
meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
 create mode 100644 
meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
 delete mode 100644 
meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
 delete mode 100644 
meta/recipes-graphics/mesa/files/0003-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch
 delete mode 100644 
meta/recipes-graphics/mesa/files/0004-use-PKG_CHECK_VAR-for-defining-WAYLAND_PROTOCOLS_DAT.patch

diff --git 
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch 
b/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
deleted file mode 100644
index d065e2285c..00
--- 
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-From e53837ad7b01364f34a533b95f4817c1795789de Mon Sep 17 00:00:00 2001
-From: Fabio Berton 
-Date: Wed, 20 Feb 2019 16:17:00 -0300
-Subject: [PATCH 1/4] Simplify wayland-scanner lookup
-Organization: O.S. Systems Software LTDA.
-
-Don't use pkg-config to lookup the path of a binary that's in the path.
-
-Alternatively we'd have to prefix the path returned by pkg-config with
-PKG_CONFIG_SYSROOT_DIR.
-
-Upstream-Status: Pending
-Signed-off-by: Jussi Kukkonen 
-Signed-off-by: Otavio Salvador 
-Signed-off-by: Fabio Berton 

- configure.ac | 7 +--
- 1 file changed, 1 insertion(+), 6 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 1ef68fe68e6..1816a4cd475 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -1854,16 +1854,11 @@ for plat in $platforms; do
- fi
- WAYLAND_PROTOCOLS_DATADIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`
- 
--PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
--  WAYLAND_SCANNER=`$PKG_CONFIG 
--variable=wayland_scanner wayland-scanner`,
--  WAYLAND_SCANNER='')
- PKG_CHECK_EXISTS([wayland-scanner >= 1.15],
-   AC_SUBST(SCANNER_ARG, 'private-code'),
-   AC_SUBST(SCANNER_ARG, 'code'))
- 
--if test "x$WAYLAND_SCANNER" = x; then
--AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
--fi
-+AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
- 
- if test "x$WAYLAND_SCANNER" = "x:"; then
- AC_MSG_ERROR([wayland-scanner is needed to compile the 
wayland platform])
--- 
-2.21.0
-
diff --git 
a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
 
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
new file mode 100644
index 00..23e207aebf
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
@@ -0,0 +1,41 @@
+From 021c24931367c83b62c550d1a296b0e9676726c0 Mon Sep 17 00:00:00 2001
+From: Fabio Berton 
+Date: Fri, 15 Mar 2019 17:42:50 -0300
+Subject: [PATCH] meson.build: check for all linux host_os combinations
+Organization: O.S. Systems Software LTDA.
+
+Make sure that we are also looking for our host_os combinations like
+linux-musl etc. when assuming support for DRM/KMS.
+
+Also delete a duplicate line.
+
+Signed-off-by: Anuj Mittal 
+---
+ meson.build | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/meson.build b/meson.build
+index 9272590201d..56465513da9 100644
+--- a/meson.build
 b/meson.build
+@@ -89,7 +89,7 @@ if (with_gles1 or with_gles2) and not with_opengl
+   error('building OpenGL ES without OpenGL is not supported.')
+ endif
+ 
+-system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'dragonfly', 
'linux'].contains(host_machine.system())
++system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 
'dragonfly'].contains(host_machine.system()) or 
host_machine.system().startswith('linux')
+ 
+ _drivers = get_option('dri-drivers')
+ if _drivers.contains('auto')
+@@ -792,7 +792,7 @@ if cc.compiles('int foo(void) 
__attribute__((__noreturn__));',
+ endif
+ 
+ # TODO: this is very incomplete
+-if ['linux', 'cygwin', 'gnu'].contains(host_machine.system())
++if ['cygwin', 'gnu'].contains(host_machine.s

[OE-core] [PATCH v2 1/2] mesa: Update 18.3.4 -> 19.0.0

[Fabio Berton]

  - Patch 0005-egl-add-missing-include-stddef.h-in-egldevice.h.patch
was applied on commit e68777c87ceed02ab199b32f941778c3cf97c794.
  - Refresh all patches
  - mesa 19.0.0 deprecated the use of autotools and we need to add
--enable-autotools flag. For details see mesa commit:
e68777c87ceed02ab199b32f941778c3cf97c794

  The complete change log can be found here:
https://www.mesa3d.org/relnotes/19.0.0.html

Signed-off-by: Fabio Berton 
---
 ...0001-Simplify-wayland-scanner-lookup.patch | 20 
 ...-winsys-svga-drm-Include-sys-types.h.patch |  7 +--
 ...M-version-when-using-LLVM-Git-releas.patch | 13 ++---
 ...R-for-defining-WAYLAND_PROTOCOLS_DAT.patch | 11 +++--
 ...sing-include-stddef.h-in-egldevice.h.patch | 49 ---
 .../{mesa-gl_18.3.4.bb => mesa-gl_19.0.0.bb}  |  0
 meta/recipes-graphics/mesa/mesa.inc   |  4 +-
 .../mesa/{mesa_18.3.4.bb => mesa_19.0.0.bb}   |  5 +-
 8 files changed, 34 insertions(+), 75 deletions(-)
 delete mode 100644 
meta/recipes-graphics/mesa/files/0005-egl-add-missing-include-stddef.h-in-egldevice.h.patch
 rename meta/recipes-graphics/mesa/{mesa-gl_18.3.4.bb => mesa-gl_19.0.0.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_18.3.4.bb => mesa_19.0.0.bb} (78%)

diff --git 
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch 
b/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
index 1c2ded0e60..d065e2285c 100644
--- 
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
+++ 
b/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
@@ -1,7 +1,7 @@
-From 81bcaa1aeecf1e66b4d94181e9a827d68e970b03 Mon Sep 17 00:00:00 2001
+From e53837ad7b01364f34a533b95f4817c1795789de Mon Sep 17 00:00:00 2001
 From: Fabio Berton 
 Date: Wed, 20 Feb 2019 16:17:00 -0300
-Subject: [PATCH 1/5] Simplify wayland-scanner lookup
+Subject: [PATCH 1/4] Simplify wayland-scanner lookup
 Organization: O.S. Systems Software LTDA.
 
 Don't use pkg-config to lookup the path of a binary that's in the path.
@@ -12,31 +12,33 @@ PKG_CONFIG_SYSROOT_DIR.
 Upstream-Status: Pending
 Signed-off-by: Jussi Kukkonen 
 Signed-off-by: Otavio Salvador 
+Signed-off-by: Fabio Berton 
 ---
  configure.ac | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index cd9ff259fad..402b4a91946 100644
+index 1ef68fe68e6..1816a4cd475 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -1841,16 +1841,11 @@ for plat in $platforms; do
+@@ -1854,16 +1854,11 @@ for plat in $platforms; do
  fi
  WAYLAND_PROTOCOLS_DATADIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`
-
+ 
 -PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
 -  WAYLAND_SCANNER=`$PKG_CONFIG 
--variable=wayland_scanner wayland-scanner`,
 -  WAYLAND_SCANNER='')
  PKG_CHECK_EXISTS([wayland-scanner >= 1.15],
AC_SUBST(SCANNER_ARG, 'private-code'),
AC_SUBST(SCANNER_ARG, 'code'))
-
+ 
 -if test "x$WAYLAND_SCANNER" = x; then
 -AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
 -fi
 +AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
-
+ 
  if test "x$WAYLAND_SCANNER" = "x:"; then
  AC_MSG_ERROR([wayland-scanner is needed to compile the 
wayland platform])
---
-2.20.1
+-- 
+2.21.0
+
diff --git 
a/meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
 
b/meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
index 12dca61e19..aaeb0f11ba 100644
--- 
a/meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
+++ 
b/meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
@@ -1,7 +1,7 @@
-From 34c3d07b67e6c08f555473a86ff158951abb6000 Mon Sep 17 00:00:00 2001
+From f212b6bed4bf265aec069c21cdc4b7c2d9cb32df Mon Sep 17 00:00:00 2001
 From: Khem Raj 
 Date: Wed, 16 Aug 2017 18:58:20 -0700
-Subject: [PATCH 2/5] winsys/svga/drm: Include sys/types.h
+Subject: [PATCH 2/4] winsys/svga/drm: Include sys/types.h
 Organization: O.S. Systems Software LTDA.
 
 vmw_screen.h uses dev_t which is defines in sys/types.h
@@ -13,6 +13,7 @@ system headers
 Signed-off-by: Khem Raj 
 Upstream-Status: Backport [7dfdfbf8c37e52e7b9b09f7d1d434edad3ebc864]
 Signed-off-by: Otavio Salvador 
+Signed-off-by: Fabio Berton 
 ---
  src/gallium/winsys/svga/drm/vmw_screen.h | 1 +
  1 file changed, 1 insertion(+)
@@ -30,5 +31,5 @@ index a87c087d9c5..cb34fec48e7 100644
  #define VMW_GMR_POOL_SIZE (16*1024*1024)
  #define VMW_QUERY_POOL_SIZE (8192)
 -- 
-2.20.1
+2.21.0
 
diff --git 
a/meta/recipes-graphics/mesa/files/0003-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch
 
b/meta/recipes-graphics/mesa/files/0003-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch
index 59b118d9f4..96edc2172b 100644
--- 
a/meta/recipes-grap

Re: [OE-core] [PATCH] tzdata: Add tzdata-all package

[Otavio Salvador]

On Mon, Mar 18, 2019 at 2:10 PM Paul Barker  wrote:
> On Mon, 18 Mar 2019, at 17:02, Burton, Ross wrote:
> > I'd prefer that installing 'tzdata' installed everything, and then
> > there were other pieces for subsets.  We learnt this the hard way from
> > people installing "python" and wondering why bits of the standard
> > library were missing.
>
> That is a good argument. I just checked the difference in image sizes though 
> (from buildhistory):
>
> core-image-minimal + tzdata = 8,868 kB
> core-image-minimal + tzdata-all = 15,788 kB
>
> So it's probably not an appropriate change for everyone.

Just, to align with other recipes, name the package tzdata-meta and
use a python function to generate the package runtime dependencies, so
it does not need manual updates.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] mesa: Update 18.3.4 -> 19.0.0

[Otavio Salvador]

Hello Richard,

On Mon, Mar 18, 2019 at 11:00 AM Richard Purdie
 wrote:
> On Fri, 2019-03-15 at 18:21 -0300, Fabio Berton wrote:
> >   - Patch 0005-egl-add-missing-include-stddef.h-in-egldevice.h.patch
> > was applied on commit e68777c87ceed02ab199b32f941778c3cf97c794.
> >   - Refresh all patches
> >   - mesa 19.0.0 deprecated the use of autotools and we need to add
> > --enable-autotools flag. For details see mesa commit:
> > e68777c87ceed02ab199b32f941778c3cf97c794
> >
> >   The complete change log can be found here:
> > https://www.mesa3d.org/relnotes/19.0.0.html
>
> This failed pretty much everywhere, e.g.:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/407
>
> I think it will be too late to get this into 2.7.

We are looking at this here; we intend to have it working anyway so we
can decide if it goes on 2.7 or not.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] systemd: Update to systemd-stable v241-stable release

[Otavio Salvador]

This changes the repository to use the systemd-stable, and update to
the latest release from v241-stable branch.

Following changes are included:

c1f8ff8d0d login: mark nomodeset fb devices as master-of-seat
59f2213e45 login: HyperV requires master-of-seat to be set
a09c170122 Allocate temporary strings to hold dbus paths on the heap
4f54afd5a1 Refuse dbus message paths longer than BUS_PATH_SIZE_MAX limit.
b22a96ef2f NEWS: add entry about 'udevadm trigger --wait-daemon'
bada94eb3e NEWS: fix release date
e9f930b2f5 udev-event: make subst_format_var() always provide null-terminated 
string on success
66320aec80 sd-device: also store properties read from udev database to 
sd_device::properties_db
dffc22c833 udev-rules: update log messages about OWNER= or GROUP= settings on 
--resolve=names=never

Signed-off-by: Otavio Salvador 
---

 meta/recipes-core/systemd/systemd.inc |   8 +-
 .../systemd/systemd/CVE-2019-6454.patch   | 216 --
 meta/recipes-core/systemd/systemd_241.bb  |   1 -
 3 files changed, 5 insertions(+), 220 deletions(-)
 delete mode 100644 meta/recipes-core/systemd/systemd/CVE-2019-6454.patch

diff --git a/meta/recipes-core/systemd/systemd.inc 
b/meta/recipes-core/systemd/systemd.inc
index 8ca3ece441..5bd88ed6ed 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -14,8 +14,10 @@ LICENSE = "GPLv2 & LGPLv2.1"
 LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
 
file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c"
 
-SRCREV = "e62a7fea757f259eb330da5b6d3ab4ede46400a2"
-
-SRC_URI = "git://github.com/systemd/systemd.git;protocol=git"
+SRCREV = "c1f8ff8d0de7e303b8004b02a0a47d4cc103a7f8"
+SRCBRANCH = "v241-stable"
+SRC_URI = 
"git://github.com/systemd/systemd-stable.git;protocol=git;branch=${SRCBRANCH}"
 
 S = "${WORKDIR}/git"
+
+PV_append = "+${SRCPV}"
diff --git a/meta/recipes-core/systemd/systemd/CVE-2019-6454.patch 
b/meta/recipes-core/systemd/systemd/CVE-2019-6454.patch
deleted file mode 100644
index b84809ef17..00
--- a/meta/recipes-core/systemd/systemd/CVE-2019-6454.patch
+++ /dev/null
@@ -1,216 +0,0 @@
-Description: sd-bus: enforce a size limit for dbus paths, and don't allocate
- them on the stacka
-Forwarded: no
-
-Patch from: systemd_239-7ubuntu10.8
-
-For information see:
-https://usn.ubuntu.com/3891-1/
-https://git.launchpad.net/ubuntu/+source/systemd/commit/?id=f8e75d5634904c8e672658856508c3a02f349adb
-
-CVE: CVE-2019-6454
-Upstream-Status: Backport
-
-Signed-off-by: George McCollister 
-
-diff --git a/src/libsystemd/sd-bus/bus-internal.c 
b/src/libsystemd/sd-bus/bus-internal.c
-index 40acae2133..598b7f110c 100644
 a/src/libsystemd/sd-bus/bus-internal.c
-+++ b/src/libsystemd/sd-bus/bus-internal.c
-@@ -43,7 +43,7 @@ bool object_path_is_valid(const char *p) {
- if (slash)
- return false;
- 
--return true;
-+return (q - p) <= BUS_PATH_SIZE_MAX;
- }
- 
- char* object_path_startswith(const char *a, const char *b) {
-diff --git a/src/libsystemd/sd-bus/bus-internal.h 
b/src/libsystemd/sd-bus/bus-internal.h
-index f208b294d8..a8d61bf72a 100644
 a/src/libsystemd/sd-bus/bus-internal.h
-+++ b/src/libsystemd/sd-bus/bus-internal.h
-@@ -332,6 +332,10 @@ struct sd_bus {
- 
- #define BUS_MESSAGE_SIZE_MAX (128*1024*1024)
- #define BUS_AUTH_SIZE_MAX (64*1024)
-+/* Note that the D-Bus specification states that bus paths shall have no size 
limit. We enforce here one
-+ * anyway, since truly unbounded strings are a security problem. The limit we 
pick is relatively large however,
-+ * to not clash unnecessarily with real-life applications. */
-+#define BUS_PATH_SIZE_MAX (64*1024)
- 
- #define BUS_CONTAINER_DEPTH 128
- 
-diff --git a/src/libsystemd/sd-bus/bus-objects.c 
b/src/libsystemd/sd-bus/bus-objects.c
-index 58329f3fe7..54b977418e 100644
 a/src/libsystemd/sd-bus/bus-objects.c
-+++ b/src/libsystemd/sd-bus/bus-objects.c
-@@ -1133,7 +1133,8 @@ static int object_manager_serialize_path_and_fallbacks(
- const char *path,
- sd_bus_error *error) {
- 
--char *prefix;
-+_cleanup_free_ char *prefix = NULL;
-+size_t pl;
- int r;
- 
- assert(bus);
-@@ -1149,7 +1150,12 @@ static int object_manager_serialize_path_and_fallbacks(
- return 0;
- 
- /* Second, add fallback vtables registered for any of the prefixes */
--prefix = newa(char, strlen(path) + 1);
-+pl = strlen(path);
-+assert(pl <= BUS_PATH_SIZE_MAX);
-+prefix = new(char, pl + 1);
-+if (!prefix)
-+return -ENOMEM;
-+
- OBJECT_PATH_FOREACH_PREFIX(prefix, path) {
- r = object_manager_serialize_path(bus, reply, prefix, path, 
true, error);
- if (r < 0)
-@@ -1345,6 +1351,7 @@ static int object_find_and_run(
- }
- 
- int bus_process_object(sd_bus *bus, sd_bus_message *m) {
-+_clea

[OE-core] Yocto Project Unassigned Bugs - Help Needed

[sjolley.yp.pm]

All,

 

The triage team meets weekly and does its best to handle the bugs reported
into the Bugzilla. The number of people attending that meeting has fallen,
as have the number of people available to help fix bugs. One of the things
we hear users report is they don't know how to help. We (the triage team)
are therefore going to start reporting out the currently 296 unassigned
bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.

 

Bugs are split into two types, "true bugs" where things don't work as they
should and "enhancements" which are features we'd want to add to the system.

 

There are also roughly four different "priority" classes right now, "2.7",
"2.8", "2.99" and "Future", the more pressing/urgent issues being in "2.7"
and then "2.8".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me
(stephen.k.jol...@intel.com  ) an e-mail
with the bug number you would like and I will assign it to you (please make
sure you have a Bugzilla account).

 

The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

 

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

Re: [OE-core] [v3][PATCH 2/2] goarch.bbclass: use MACHINEOVERRIDES and simplify go_map_arm()

[Mark Asselstine]

On Monday, March 18, 2019 12:40:28 PM EDT Martin Jansa wrote:
> On Mon, Mar 18, 2019 at 11:21:53AM -0400, Mark Asselstine wrote:
> > Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
> > cross building for ARMv5, ARMv6 and ARMv7. The current approach of
> > using TUNE_FEATURES can be error prone, as we can see today when
> > attempting to build for Cortex-A7 which results in GOARM=''.
> > 
> > Since the value of MACHINEOVERRIDES already consolidates the values of
> > TUNE_FEATURES into something more consistent we can use the overrides
> > mechanism to set GOARM, leaving just a little bit of logic in
> > go_map_arm() to trigger off the arch (basically target vs host)
> > for the setting of GOARM.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > V2
> > * Cover all ARMv7 Cortex* variants
> > 
> > V3
> > * Switch to using MACHINEOVERRIDES/overrides mechanism
> > 
> >  meta/classes/goarch.bbclass | 19 +++
> >  1 file changed, 11 insertions(+), 8 deletions(-)
> > 
> > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > index 39fea5e..8fdb443 100644
> > --- a/meta/classes/goarch.bbclass
> > +++ b/meta/classes/goarch.bbclass
> > @@ -3,18 +3,26 @@ BUILD_GOARCH = "${@go_map_arch(d.getVar('BUILD_ARCH'),
> > d)}"> 
> >  BUILD_GOTUPLE = "${BUILD_GOOS}_${BUILD_GOARCH}"
> >  HOST_GOOS = "${@go_map_os(d.getVar('HOST_OS'), d)}"
> >  HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH'), d)}"
> > 
> > -HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'),
> > d.getVar('TUNE_FEATURES'), d)}" +HOST_GOARM =
> > "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('BASE_GOARM'), d)}"> 
> >  HOST_GO386 = "${@go_map_386(d.getVar('HOST_ARCH'),
> >  d.getVar('TUNE_FEATURES'), d)}" HOST_GOMIPS =
> >  "${@go_map_mips(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
> >  HOST_GOTUPLE = "${HOST_GOOS}_${HOST_GOARCH}"
> >  TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS'), d)}"
> >  TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH'), d)}"
> > 
> > -TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'),
> > d.getVar('TUNE_FEATURES'), d)}" +TARGET_GOARM =
> > "${@go_map_arm(d.getVar('TARGET_ARCH'), d.getVar('BASE_GOARM'), d)}"> 
> >  TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'),
> >  d.getVar('TUNE_FEATURES'), d)}" TARGET_GOMIPS =
> >  "${@go_map_mips(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
> >  TARGET_GOTUPLE = "${TARGET_GOOS}_${TARGET_GOARCH}"
> >  GO_BUILD_BINDIR =
> >  "${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE') ==
> >  d.getVar('HOST_GOTUPLE')]}"> 
> > +# Use the MACHINEOVERRIDES to map ARM CPU architecture passed to GO via
> > GOARM. +# This is combined with *_ARCH to set HOST_GOARM and
> > TARGET_GOARM. +BASE_GOARM = ''
> > +BASE_GOARM_armv7ve = '7'
> > +BASE_GOARM_armv7a = '7'
> > +BASE_GOARM_armv6 = '6'
> > +BASE_GOARM_armv5 = '5'
> > +
> > 
> >  # Go supports dynamic linking on a limited set of architectures.
> >  # See the supportsDynlink function in
> >  go/src/cmd/compile/internal/gc/main.go GO_DYNLINK = ""
> > 
> > @@ -74,12 +82,7 @@ def go_map_arch(a, d):
> >  def go_map_arm(a, f, d):
> >  import re
> > 
> >  if re.match('arm.*', a):
> > -if 'armv7' in f:
> > -return '7'
> > -elif 'armv6' in f:
> > -return '6'
> > -elif 'armv5' in f:
> > -return '5'
> > +return f
> > 
> >  return ''
> 
> Is this function still useful? Cannot you set TARGET_GOARM and
> HOST_GOARM with arm override (to simulate the effect of "re.match('arm.*',
> a)")?

No. Attempting to use the override will not result in the same result for 
HOST_GOARM. The overrides will represent the target and not the host. Unless 
you have an implementation to backup your suggestion and I am just not seeing 
it.

MarkA

> 
> Regards,
> 
> >  def go_map_386(a, f, d):




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

Re: [OE-core] [PATCH 1/2] lttng-tools ptest: add missing dependencies

[Richard Purdie]

On Mon, 2019-03-18 at 12:47 -0400, Jonathan Rajotte-Julien wrote:
> > Since the patches with a couple of fixes were passing the tests,
> > I've
> > merged the patches with the glibc/muslc tweak and also a tweak to
> > make
> > disabled ust work. I'd normally wait for v2 resubmission but I
> > wanted
> > to get this fix into M3 and the M3 build is already behind
> > schedule.
> 
> Sounds good.

I should have done this before merging but for various reasons I
didn't. Your patches sounded good and fixed various problematic things
so wouldn't seem to make anything worse.

We have some ptest results numbers from a build and it shows before:

Recipe | Passed  | Failed   | Skipped   | Time(s)   
lttng-tools| 4431| 7| 391   | 549

After recent patches:

Recipe | Passed  | Failed   | Skipped   | Time(s)   
lttng-tools| 3994| 5| 0 | 684 T

So we're down on failures but its now not running all the tests and the
"T" means the ptest timed out and was killed.

I'm comparing:

https://autobuilder.yocto.io/pub/non-release/20190228-9/testresults/
testresult-report.txt 

with the report that will appear at:

https://autobuilder.yocto.io/pub/non-release/20190318-7/testresults/

Any idea what happened?

> Well lttng-ust does work on musl as long as users do not fiddle with
> sched_affinity... I cc'ed you on the musl thread about this [1].
> 
> [1] https://www.openwall.com/lists/musl/2019/03/15/5
> 
> For now we can leave the disable statement there. We will revisit
> when musl is fixed and/or when lttng-ust have a fallback (most likely
> to happen) when using musl.

Thanks, this is the discussion I was referring to before and I was
assuming it was leading to some of the problem you were seeing.

> > > Side note, gdb simply segfault (at start) for me on a core-image-
> > > minirmnal build using musl.
> > > How would someone open the corefile generated on the build system
> > > with the proper libs and all?
> > 
> > I saw other discussion about this so it looks like you're making
> > progress on this front. If not, Khem would be the person to ask
> > about
> > this as our musl expert...
> 
> Do you have a link to said discussion? I ended up debugging using
> print
> statement since even on Alpine gdb is "broken" (not working as
> expected). 
> I'm not sure how much time I can use on this. Will let you know if
> any progress
> is made to at least get a backtrace for the gdb coredump.

Khem is the one to talk to about this. I'm a little worried that gdb is
broken, that is something we need to investigate and clearly better
test too...

Cheers,

Richard



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

Re: [OE-core] [PATCH 1/3] lttng: Enable on musl and riscv

[Khem Raj]

On Mon, Mar 18, 2019 at 10:08 AM Jonathan Rajotte-Julien
 wrote:
>
> Hi Khem,
>
> This looks good, still please take some moment to read this thread from musl
> mailing list regarding lttng-ust usage of _SC_NPROCESSORS_CONF. For now I 
> would
> maintain the disabling of lttng-ust when musl is used. I should have CC'ed 
> you,
> I forgot.

I think thats right, I should keep this pull just to riscv for now. I
will send a v2 soonish

>
> The modification for riscv64 seems good to me. We do support lttng-* for
> riscv64 [2] on debian.
>
> [1] https://www.openwall.com/lists/musl/2019/03/15/5
> [2] https://packages.debian.org/sid/utils/lttng-tools
>
>
> On Mon, Mar 18, 2019 at 09:58:01AM -0700, Khem Raj wrote:
> > Latest version compiles on musl as well as on risv64 now
> >
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb | 2 +-
> >  meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb   | 2 --
> >  2 files changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb 
> > b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> > index 086254d3d3..15e75e51c9 100644
> > --- a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> > +++ b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> > @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
> > "file://LICENSE;md5=c4613d1f8a9587bd7b366191830364b3 \
> >
> >  inherit module
> >
> > -COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm).*-linux'
> > +COMPATIBLE_HOST = 
> > '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
> >
> >  #https://lttng.org/files/lttng-modules/lttng-modules-2.10.7.tar.bz2
> >  SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
> > diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb 
> > b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> > index 151e35e3c3..d544f8e206 100644
> > --- a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> > +++ b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> > @@ -26,9 +26,7 @@ PACKAGECONFIG[python] = "--enable-python-bindings 
> > ${PYTHON_OPTION},,python3 swig
> >  PACKAGECONFIG[lttng-ust] = "--with-lttng-ust, --without-lttng-ust, 
> > lttng-ust"
> >  PACKAGECONFIG[kmod] = "--with-kmod, --without-kmod, kmod"
> >  PACKAGECONFIG[manpages] = "--enable-man-pages, --disable-man-pages, 
> > asciidoc-native xmlto-native libxslt-native"
> > -PACKAGECONFIG_remove_libc-musl = "lttng-ust"
> >  PACKAGECONFIG_remove_arc = "lttng-ust"
> > -PACKAGECONFIG_remove_riscv64 = "lttng-ust"
> >
> >  SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
> > file://x32.patch \
> > --
> > 2.21.0
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> Jonathan Rajotte-Julien
> EfficiOS
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/3] packagegroup-core-tools-profile: Do not remove lttng-ust for musl and risc-v

[Jonathan Rajotte-Julien]

On Mon, Mar 18, 2019 at 09:58:02AM -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj 
> ---
>  .../packagegroups/packagegroup-core-tools-profile.bb   | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git 
> a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb 
> b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> index 762c046636..3d8e0c2ed7 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> @@ -39,16 +39,13 @@ SYSTEMTAP_riscv64 = ""
>  LTTNGUST = "lttng-ust"
>  LTTNGUST_libc-musl = ""

Looks like you missed this, based on the commit msg.

>  LTTNGUST_arc = ""
> -LTTNGUST_riscv64 = ""
>  
>  LTTNGTOOLS = "lttng-tools"
>  LTTNGTOOLS_libc-musl = ""

Looks like you missed this, based on the commit msg.

>  LTTNGTOOLS_arc = ""
> -LTTNGTOOLS_riscv64 = ""
>  
>  LTTNGMODULES = "lttng-modules"
>  LTTNGMODULES_arc = ""
> -LTTNGMODULES_riscv64 = ""
>  
>  BABELTRACE = "babeltrace"
>  
> -- 
> 2.21.0
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 3/3] gdb: Do not disable lttng-ust on risc-v

[Jonathan Rajotte-Julien]

On Mon, Mar 18, 2019 at 09:58:03AM -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/gdb/gdb-common.inc | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/gdb/gdb-common.inc 
> b/meta/recipes-devtools/gdb/gdb-common.inc
> index 57bc0dc773..a07625bb8d 100644
> --- a/meta/recipes-devtools/gdb/gdb-common.inc
> +++ b/meta/recipes-devtools/gdb/gdb-common.inc
> @@ -6,7 +6,6 @@ DEPENDS = "expat zlib ncurses virtual/libiconv ${LTTNGUST} 
> bison-native"
>  LTTNGUST = "lttng-ust"

I did not know that gdb depends on lttng-ust, I know gdb can depend on
libbabeltrace*. I'll check that a bit more.

Cheers.

>  LTTNGUST_arc = ""
>  LTTNGUST_aarch64 = ""
> -LTTNGUST_riscv64 = ""
>  LTTNGUST_mipsarch = ""
>  LTTNGUST_sh4 = ""
>  LTTNGUST_libc-musl = ""
> -- 
> 2.21.0
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH] tzdata: Add tzdata-all package

[Paul Barker]

On Mon, 18 Mar 2019, at 17:02, Burton, Ross wrote:
> I'd prefer that installing 'tzdata' installed everything, and then
> there were other pieces for subsets.  We learnt this the hard way from
> people installing "python" and wondering why bits of the standard
> library were missing.

That is a good argument. I just checked the difference in image sizes though 
(from buildhistory):

core-image-minimal + tzdata = 8,868 kB
core-image-minimal + tzdata-all = 15,788 kB

So it's probably not an appropriate change for everyone.

> 
> Ross
> 
> On Mon, 18 Mar 2019 at 17:01, Paul Barker  wrote:
> >
> > The tzdata-all package provides a simple way of ensuring all timezones
> > are supported in an image.
> >
> > Signed-off-by: Paul Barker 
> > ---
> >  meta/recipes-extended/timezone/tzdata.bb | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-extended/timezone/tzdata.bb 
> > b/meta/recipes-extended/timezone/tzdata.bb
> > index 7542ce52d2..e419296530 100644
> > --- a/meta/recipes-extended/timezone/tzdata.bb
> > +++ b/meta/recipes-extended/timezone/tzdata.bb
> > @@ -82,7 +82,14 @@ pkg_postinst_${PN} () {
> >
> >  PACKAGES = "tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
> >  tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
> > -tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific"
> > +tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific 
> > tzdata-all"
> > +
> > +ALLOW_EMPTY_tzdata-all = "1"
> > +RDEPENDS_tzdata-all = " \
> > +tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
> > +tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
> > +tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific \
> > +"
> >
> >  FILES_tzdata-africa += "${datadir}/zoneinfo/Africa/*"
> >  RPROVIDES_tzdata-africa = "tzdata-africa"
> > --
> > 2.17.1
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

-- 
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] lttng: Enable on musl and riscv

[Jonathan Rajotte-Julien]

Hi Khem,

This looks good, still please take some moment to read this thread from musl
mailing list regarding lttng-ust usage of _SC_NPROCESSORS_CONF. For now I would
maintain the disabling of lttng-ust when musl is used. I should have CC'ed you,
I forgot.

The modification for riscv64 seems good to me. We do support lttng-* for
riscv64 [2] on debian.

[1] https://www.openwall.com/lists/musl/2019/03/15/5
[2] https://packages.debian.org/sid/utils/lttng-tools


On Mon, Mar 18, 2019 at 09:58:01AM -0700, Khem Raj wrote:
> Latest version compiles on musl as well as on risv64 now
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb | 2 +-
>  meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb   | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb 
> b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> index 086254d3d3..15e75e51c9 100644
> --- a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
> "file://LICENSE;md5=c4613d1f8a9587bd7b366191830364b3 \
>  
>  inherit module
>  
> -COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm).*-linux'
> +COMPATIBLE_HOST = 
> '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
>  
>  #https://lttng.org/files/lttng-modules/lttng-modules-2.10.7.tar.bz2
>  SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
> diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb 
> b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> index 151e35e3c3..d544f8e206 100644
> --- a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> +++ b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> @@ -26,9 +26,7 @@ PACKAGECONFIG[python] = "--enable-python-bindings 
> ${PYTHON_OPTION},,python3 swig
>  PACKAGECONFIG[lttng-ust] = "--with-lttng-ust, --without-lttng-ust, lttng-ust"
>  PACKAGECONFIG[kmod] = "--with-kmod, --without-kmod, kmod"
>  PACKAGECONFIG[manpages] = "--enable-man-pages, --disable-man-pages, 
> asciidoc-native xmlto-native libxslt-native"
> -PACKAGECONFIG_remove_libc-musl = "lttng-ust"
>  PACKAGECONFIG_remove_arc = "lttng-ust"
> -PACKAGECONFIG_remove_riscv64 = "lttng-ust"
>  
>  SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
> file://x32.patch \
> -- 
> 2.21.0
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

Re: [OE-core] [thud][PATCH] Revert "boost: update to 1.69.0"

[Andreas Müller]

On Mon, Mar 18, 2019 at 5:45 PM Armin Kuster  wrote:
>
> This reverts commit a384248938ea9db096866bf4ec8678d35ca62a12.
>
> This package update slipped in doing the maint process. Removing it.
>
> Signed-off-by: Armin Kuster 
> ---
>  ...bjam-native_1.69.0.bb => bjam-native_1.68.0.bb} |   0
>  .../boost/{boost-1.69.0.inc => boost-1.68.0.inc}   |   4 +-
>  meta/recipes-support/boost/boost.inc   |   1 +
>  ...-arch-instruction-set-flags-we-do-that-o.patch} |  23 +-
>  ...ucibility-add-file-directive-to-assembler.patch | 243 
> +
>  .../boost/{boost_1.69.0.bb => boost_1.68.0.bb} |   6 +-
>  6 files changed, 263 insertions(+), 14 deletions(-)
>  rename meta/recipes-support/boost/{bjam-native_1.69.0.bb => 
> bjam-native_1.68.0.bb} (100%)
>  rename meta/recipes-support/boost/{boost-1.69.0.inc => boost-1.68.0.inc} 
> (85%)
>  rename 
> meta/recipes-support/boost/boost/{0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
>  => 0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch} (93%)
>  create mode 100644 
> meta/recipes-support/boost/boost/reproducibility-add-file-directive-to-assembler.patch
>  rename meta/recipes-support/boost/{boost_1.69.0.bb => boost_1.68.0.bb} (56%)
>
> diff --git a/meta/recipes-support/boost/bjam-native_1.69.0.bb 
> b/meta/recipes-support/boost/bjam-native_1.68.0.bb
> similarity index 100%
> rename from meta/recipes-support/boost/bjam-native_1.69.0.bb
> rename to meta/recipes-support/boost/bjam-native_1.68.0.bb
> diff --git a/meta/recipes-support/boost/boost-1.69.0.inc 
> b/meta/recipes-support/boost/boost-1.68.0.inc
> similarity index 85%
> rename from meta/recipes-support/boost/boost-1.69.0.inc
> rename to meta/recipes-support/boost/boost-1.68.0.inc
> index 923436b..b367a80 100644
> --- a/meta/recipes-support/boost/boost-1.69.0.inc
> +++ b/meta/recipes-support/boost/boost-1.68.0.inc
> @@ -12,8 +12,8 @@ BOOST_MAJ = "${@"_".join(d.getVar("PV").split(".")[0:2])}"
>  BOOST_P = "boost_${BOOST_VER}"
>
>  SRC_URI = 
> "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2"
> -SRC_URI[md5sum] = "a1332494397bf48332cb152abfefcec2"
> -SRC_URI[sha256sum] = 
> "8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406"
> +SRC_URI[md5sum] = "7fbd1890f571051f2a209681d57d486a"
> +SRC_URI[sha256sum] = 
> "7f6130bc3cf65f56a61ce9d5ea704fa10b462be126ad053e80e553d6d8b7"
>
>  UPSTREAM_CHECK_URI = "http://www.boost.org/users/download/";
>  UPSTREAM_CHECK_REGEX = "boostorg/release/(?P.*)/source/"
> diff --git a/meta/recipes-support/boost/boost.inc 
> b/meta/recipes-support/boost/boost.inc
> index 9be3717..c4faea2 100644
> --- a/meta/recipes-support/boost/boost.inc
> +++ b/meta/recipes-support/boost/boost.inc
> @@ -21,6 +21,7 @@ BOOST_LIBS = "\
> random \
> regex \
> serialization \
> +   signals \
> system \
> timer \
> test \
> diff --git 
> a/meta/recipes-support/boost/boost/0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
>  
> b/meta/recipes-support/boost/boost/0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
> similarity index 93%
> rename from 
> meta/recipes-support/boost/boost/0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
> rename to 
> meta/recipes-support/boost/boost/0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
> index 8944cb3..fb6d971 100644
> --- 
> a/meta/recipes-support/boost/boost/0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
> +++ 
> b/meta/recipes-support/boost/boost/0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
> @@ -1,20 +1,21 @@
> -From 3e4eb02eb5951058bc6f8dffbf049eb189df8291 Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Tue, 18 Dec 2018 15:42:57 +0100
> -Subject: [PATCH] Don't set up arch/instruction-set flags, we do that 
> ourselves
> +From 0868761e7d2d75d472090e3ef96f3d2f9ced27f3 Mon Sep 17 00:00:00 2001
> +From: Christopher Larson 
> +Date: Tue, 13 Dec 2016 10:29:32 -0700
> +Subject: [PATCH 5/6] Don't set up arch/instruction-set flags, we do that
> + ourselves
>
>  Upstream-Status: Inappropriate
>  Signed-off-by: Christopher Larson 
> -Signed-off-by: Alexander Kanavin 
> +
>  ---
> - tools/build/src/tools/gcc.jam | 128 --
> - 1 file changed, 128 deletions(-)
> + tools/build/src/tools/gcc.jam | 127 
> --
> + 1 file changed, 127 deletions(-)
>
>  diff --git a/tools/build/src/tools/gcc.jam b/tools/build/src/tools/gcc.jam
> -index c57c773f..28618fb1 100644
> +index e3b1b952..e4fc6c32 100644
>  --- a/tools/build/src/tools/gcc.jam
>  +++ b/tools/build/src/tools/gcc.jam
> -@@ -1152,131 +1152,3 @@ local rule cpu-flags ( toolset variable : 
> architecture : instruction-set + :
> +@@ -1276,130 +1276,3 @@ local rule cpu-flags ( toolset variable : 
> architecture : instruction-set + :
>   $(architecture)/$(instruction-set)
>   : $(values) ;
>   }
> @@ -64,7 +65,

Re: [OE-core] [PATCH] tzdata: Add tzdata-all package

[Burton, Ross]

I'd prefer that installing 'tzdata' installed everything, and then
there were other pieces for subsets.  We learnt this the hard way from
people installing "python" and wondering why bits of the standard
library were missing.

Ross

On Mon, 18 Mar 2019 at 17:01, Paul Barker  wrote:
>
> The tzdata-all package provides a simple way of ensuring all timezones
> are supported in an image.
>
> Signed-off-by: Paul Barker 
> ---
>  meta/recipes-extended/timezone/tzdata.bb | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-extended/timezone/tzdata.bb 
> b/meta/recipes-extended/timezone/tzdata.bb
> index 7542ce52d2..e419296530 100644
> --- a/meta/recipes-extended/timezone/tzdata.bb
> +++ b/meta/recipes-extended/timezone/tzdata.bb
> @@ -82,7 +82,14 @@ pkg_postinst_${PN} () {
>
>  PACKAGES = "tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
>  tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
> -tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific"
> +tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific tzdata-all"
> +
> +ALLOW_EMPTY_tzdata-all = "1"
> +RDEPENDS_tzdata-all = " \
> +tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
> +tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
> +tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific \
> +"
>
>  FILES_tzdata-africa += "${datadir}/zoneinfo/Africa/*"
>  RPROVIDES_tzdata-africa = "tzdata-africa"
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tzdata: Add tzdata-all package

[Paul Barker]

The tzdata-all package provides a simple way of ensuring all timezones
are supported in an image.

Signed-off-by: Paul Barker 
---
 meta/recipes-extended/timezone/tzdata.bb | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/timezone/tzdata.bb 
b/meta/recipes-extended/timezone/tzdata.bb
index 7542ce52d2..e419296530 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -82,7 +82,14 @@ pkg_postinst_${PN} () {
 
 PACKAGES = "tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
 tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
-tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific"
+tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific tzdata-all"
+
+ALLOW_EMPTY_tzdata-all = "1"
+RDEPENDS_tzdata-all = " \
+tzdata tzdata-misc tzdata-posix tzdata-right tzdata-africa \
+tzdata-americas tzdata-antarctica tzdata-arctic tzdata-asia \
+tzdata-atlantic tzdata-australia tzdata-europe tzdata-pacific \
+"
 
 FILES_tzdata-africa += "${datadir}/zoneinfo/Africa/*"
 RPROVIDES_tzdata-africa = "tzdata-africa"
-- 
2.17.1

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

[OE-core] [PATCH 3/3] gdb: Do not disable lttng-ust on risc-v

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gdb/gdb-common.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-devtools/gdb/gdb-common.inc 
b/meta/recipes-devtools/gdb/gdb-common.inc
index 57bc0dc773..a07625bb8d 100644
--- a/meta/recipes-devtools/gdb/gdb-common.inc
+++ b/meta/recipes-devtools/gdb/gdb-common.inc
@@ -6,7 +6,6 @@ DEPENDS = "expat zlib ncurses virtual/libiconv ${LTTNGUST} 
bison-native"
 LTTNGUST = "lttng-ust"
 LTTNGUST_arc = ""
 LTTNGUST_aarch64 = ""
-LTTNGUST_riscv64 = ""
 LTTNGUST_mipsarch = ""
 LTTNGUST_sh4 = ""
 LTTNGUST_libc-musl = ""
-- 
2.21.0

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

[OE-core] [PATCH 2/3] packagegroup-core-tools-profile: Do not remove lttng-ust for musl and risc-v

[Khem Raj]

Signed-off-by: Khem Raj 
---
 .../packagegroups/packagegroup-core-tools-profile.bb   | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index 762c046636..3d8e0c2ed7 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -39,16 +39,13 @@ SYSTEMTAP_riscv64 = ""
 LTTNGUST = "lttng-ust"
 LTTNGUST_libc-musl = ""
 LTTNGUST_arc = ""
-LTTNGUST_riscv64 = ""
 
 LTTNGTOOLS = "lttng-tools"
 LTTNGTOOLS_libc-musl = ""
 LTTNGTOOLS_arc = ""
-LTTNGTOOLS_riscv64 = ""
 
 LTTNGMODULES = "lttng-modules"
 LTTNGMODULES_arc = ""
-LTTNGMODULES_riscv64 = ""
 
 BABELTRACE = "babeltrace"
 
-- 
2.21.0

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

[OE-core] [PATCH 1/3] lttng: Enable on musl and riscv

[Khem Raj]

Latest version compiles on musl as well as on risv64 now

Signed-off-by: Khem Raj 
---
 meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb | 2 +-
 meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb   | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb 
b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
index 086254d3d3..15e75e51c9 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=c4613d1f8a9587bd7b366191830364b3 \
 
 inherit module
 
-COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm).*-linux'
+COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
 
 #https://lttng.org/files/lttng-modules/lttng-modules-2.10.7.tar.bz2
 SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
index 151e35e3c3..d544f8e206 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
@@ -26,9 +26,7 @@ PACKAGECONFIG[python] = "--enable-python-bindings 
${PYTHON_OPTION},,python3 swig
 PACKAGECONFIG[lttng-ust] = "--with-lttng-ust, --without-lttng-ust, lttng-ust"
 PACKAGECONFIG[kmod] = "--with-kmod, --without-kmod, kmod"
 PACKAGECONFIG[manpages] = "--enable-man-pages, --disable-man-pages, 
asciidoc-native xmlto-native libxslt-native"
-PACKAGECONFIG_remove_libc-musl = "lttng-ust"
 PACKAGECONFIG_remove_arc = "lttng-ust"
-PACKAGECONFIG_remove_riscv64 = "lttng-ust"
 
 SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://x32.patch \
-- 
2.21.0

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

Re: [OE-core] [PATCH 1/2] lttng-tools ptest: add missing dependencies

[Jonathan Rajotte-Julien]

> Since the patches with a couple of fixes were passing the tests, I've
> merged the patches with the glibc/muslc tweak and also a tweak to make
> disabled ust work. I'd normally wait for v2 resubmission but I wanted
> to get this fix into M3 and the M3 build is already behind schedule.

Sounds good.

> 
> I was at a conference last week so a bit distracted, just catching up
> now.
> 
> > Also, I saw that lttng-ust is removed from PACKAGECONFIG when using
> > musl, not sure why the commit history is not particularly verbose
> > regarding why it was a problem. Still, it seems to build fine but we
> > are seeing issue regarding musl.
> 
> I think when we originally merged musl, lttng didn't build with it or
> there were some kind of issues. I suspect lttng-ust still doesn't work
> on all the architectures we build for so we likely need to be able to
> optionally disable it. I'd be happy to see patches enabling it where it
> does work though.

Well lttng-ust does work on musl as long as users do not fiddle with
sched_affinity... I cc'ed you on the musl thread about this [1].

[1] https://www.openwall.com/lists/musl/2019/03/15/5

For now we can leave the disable statement there. We will revisit when musl is
fixed and/or when lttng-ust have a fallback (most likely to happen) when using
musl.

> 
> 
> > We checked with Alpine since they also use musl and see similar
> > problem. I'm investigating on that front. I'll let you know what I
> > find.

See [1].

We also found a dynamic linker problem on our side for the notification test.
We will upstream it in the following weeks.

> > 
> > Side note, gdb simply segfault (at start) for me on a core-image-
> > minirmnal build using musl.
> > How would someone open the corefile generated on the build system
> > with the proper libs and all?
> 
> I saw other discussion about this so it looks like you're making
> progress on this front. If not, Khem would be the person to ask about
> this as our musl expert...

Do you have a link to said discussion? I ended up debugging using print
statement since even on Alpine gdb is "broken" (not working as expected). 
I'm not sure how much time I can use on this. Will let you know if any progress
is made to at least get a backtrace for the gdb coredump.

Thanks again!

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

[OE-core] [thud][PATCH] Revert "boost: update to 1.69.0"

[Armin Kuster]

This reverts commit a384248938ea9db096866bf4ec8678d35ca62a12.

This package update slipped in doing the maint process. Removing it.

Signed-off-by: Armin Kuster 
---
 ...bjam-native_1.69.0.bb => bjam-native_1.68.0.bb} |   0
 .../boost/{boost-1.69.0.inc => boost-1.68.0.inc}   |   4 +-
 meta/recipes-support/boost/boost.inc   |   1 +
 ...-arch-instruction-set-flags-we-do-that-o.patch} |  23 +-
 ...ucibility-add-file-directive-to-assembler.patch | 243 +
 .../boost/{boost_1.69.0.bb => boost_1.68.0.bb} |   6 +-
 6 files changed, 263 insertions(+), 14 deletions(-)
 rename meta/recipes-support/boost/{bjam-native_1.69.0.bb => 
bjam-native_1.68.0.bb} (100%)
 rename meta/recipes-support/boost/{boost-1.69.0.inc => boost-1.68.0.inc} (85%)
 rename 
meta/recipes-support/boost/boost/{0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
 => 0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch} (93%)
 create mode 100644 
meta/recipes-support/boost/boost/reproducibility-add-file-directive-to-assembler.patch
 rename meta/recipes-support/boost/{boost_1.69.0.bb => boost_1.68.0.bb} (56%)

diff --git a/meta/recipes-support/boost/bjam-native_1.69.0.bb 
b/meta/recipes-support/boost/bjam-native_1.68.0.bb
similarity index 100%
rename from meta/recipes-support/boost/bjam-native_1.69.0.bb
rename to meta/recipes-support/boost/bjam-native_1.68.0.bb
diff --git a/meta/recipes-support/boost/boost-1.69.0.inc 
b/meta/recipes-support/boost/boost-1.68.0.inc
similarity index 85%
rename from meta/recipes-support/boost/boost-1.69.0.inc
rename to meta/recipes-support/boost/boost-1.68.0.inc
index 923436b..b367a80 100644
--- a/meta/recipes-support/boost/boost-1.69.0.inc
+++ b/meta/recipes-support/boost/boost-1.68.0.inc
@@ -12,8 +12,8 @@ BOOST_MAJ = "${@"_".join(d.getVar("PV").split(".")[0:2])}"
 BOOST_P = "boost_${BOOST_VER}"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2"
-SRC_URI[md5sum] = "a1332494397bf48332cb152abfefcec2"
-SRC_URI[sha256sum] = 
"8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406"
+SRC_URI[md5sum] = "7fbd1890f571051f2a209681d57d486a"
+SRC_URI[sha256sum] = 
"7f6130bc3cf65f56a61ce9d5ea704fa10b462be126ad053e80e553d6d8b7"
 
 UPSTREAM_CHECK_URI = "http://www.boost.org/users/download/";
 UPSTREAM_CHECK_REGEX = "boostorg/release/(?P.*)/source/"
diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 9be3717..c4faea2 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -21,6 +21,7 @@ BOOST_LIBS = "\
random \
regex \
serialization \
+   signals \
system \
timer \
test \
diff --git 
a/meta/recipes-support/boost/boost/0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
 
b/meta/recipes-support/boost/boost/0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
similarity index 93%
rename from 
meta/recipes-support/boost/boost/0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
rename to 
meta/recipes-support/boost/boost/0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
index 8944cb3..fb6d971 100644
--- 
a/meta/recipes-support/boost/boost/0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
+++ 
b/meta/recipes-support/boost/boost/0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
@@ -1,20 +1,21 @@
-From 3e4eb02eb5951058bc6f8dffbf049eb189df8291 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin 
-Date: Tue, 18 Dec 2018 15:42:57 +0100
-Subject: [PATCH] Don't set up arch/instruction-set flags, we do that ourselves
+From 0868761e7d2d75d472090e3ef96f3d2f9ced27f3 Mon Sep 17 00:00:00 2001
+From: Christopher Larson 
+Date: Tue, 13 Dec 2016 10:29:32 -0700
+Subject: [PATCH 5/6] Don't set up arch/instruction-set flags, we do that
+ ourselves
 
 Upstream-Status: Inappropriate
 Signed-off-by: Christopher Larson 
-Signed-off-by: Alexander Kanavin 
+
 ---
- tools/build/src/tools/gcc.jam | 128 --
- 1 file changed, 128 deletions(-)
+ tools/build/src/tools/gcc.jam | 127 --
+ 1 file changed, 127 deletions(-)
 
 diff --git a/tools/build/src/tools/gcc.jam b/tools/build/src/tools/gcc.jam
-index c57c773f..28618fb1 100644
+index e3b1b952..e4fc6c32 100644
 --- a/tools/build/src/tools/gcc.jam
 +++ b/tools/build/src/tools/gcc.jam
-@@ -1152,131 +1152,3 @@ local rule cpu-flags ( toolset variable : architecture 
: instruction-set + :
+@@ -1276,130 +1276,3 @@ local rule cpu-flags ( toolset variable : architecture 
: instruction-set + :
  $(architecture)/$(instruction-set)
  : $(values) ;
  }
@@ -64,7 +65,6 @@ index c57c773f..28618fb1 100644
 -cpu-flags gcc OPTIONS : x86 : skylake : -march=skylake ;
 -cpu-flags gcc OPTIONS : x86 : skylake-avx512 : -march=skylake-avx512 ;
 -cpu-flags gcc OPTIONS : x86 : cannonlake : -march=skylake-avx512 -mavx512vbmi 
-mavx512ifma -msha ;
--cpu-fl

Re: [OE-core] [v3][PATCH 2/2] goarch.bbclass: use MACHINEOVERRIDES and simplify go_map_arm()

[Martin Jansa]

On Mon, Mar 18, 2019 at 11:21:53AM -0400, Mark Asselstine wrote:
> Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
> cross building for ARMv5, ARMv6 and ARMv7. The current approach of
> using TUNE_FEATURES can be error prone, as we can see today when
> attempting to build for Cortex-A7 which results in GOARM=''.
> 
> Since the value of MACHINEOVERRIDES already consolidates the values of
> TUNE_FEATURES into something more consistent we can use the overrides
> mechanism to set GOARM, leaving just a little bit of logic in
> go_map_arm() to trigger off the arch (basically target vs host)
> for the setting of GOARM.
> 
> Signed-off-by: Mark Asselstine 
> ---
> 
> V2
> * Cover all ARMv7 Cortex* variants
> 
> V3
> * Switch to using MACHINEOVERRIDES/overrides mechanism
> 
>  meta/classes/goarch.bbclass | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> index 39fea5e..8fdb443 100644
> --- a/meta/classes/goarch.bbclass
> +++ b/meta/classes/goarch.bbclass
> @@ -3,18 +3,26 @@ BUILD_GOARCH = "${@go_map_arch(d.getVar('BUILD_ARCH'), d)}"
>  BUILD_GOTUPLE = "${BUILD_GOOS}_${BUILD_GOARCH}"
>  HOST_GOOS = "${@go_map_os(d.getVar('HOST_OS'), d)}"
>  HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH'), d)}"
> -HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), 
> d.getVar('TUNE_FEATURES'), d)}"
> +HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('BASE_GOARM'), 
> d)}"
>  HOST_GO386 = "${@go_map_386(d.getVar('HOST_ARCH'), 
> d.getVar('TUNE_FEATURES'), d)}"
>  HOST_GOMIPS = "${@go_map_mips(d.getVar('HOST_ARCH'), 
> d.getVar('TUNE_FEATURES'), d)}"
>  HOST_GOTUPLE = "${HOST_GOOS}_${HOST_GOARCH}"
>  TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS'), d)}"
>  TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH'), d)}"
> -TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), 
> d.getVar('TUNE_FEATURES'), d)}"
> +TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), 
> d.getVar('BASE_GOARM'), d)}"
>  TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'), 
> d.getVar('TUNE_FEATURES'), d)}"
>  TARGET_GOMIPS = "${@go_map_mips(d.getVar('TARGET_ARCH'), 
> d.getVar('TUNE_FEATURES'), d)}"
>  TARGET_GOTUPLE = "${TARGET_GOOS}_${TARGET_GOARCH}"
>  GO_BUILD_BINDIR = 
> "${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE') == 
> d.getVar('HOST_GOTUPLE')]}"
>  
> +# Use the MACHINEOVERRIDES to map ARM CPU architecture passed to GO via 
> GOARM.
> +# This is combined with *_ARCH to set HOST_GOARM and TARGET_GOARM.
> +BASE_GOARM = ''
> +BASE_GOARM_armv7ve = '7'
> +BASE_GOARM_armv7a = '7'
> +BASE_GOARM_armv6 = '6'
> +BASE_GOARM_armv5 = '5'
> +
>  # Go supports dynamic linking on a limited set of architectures.
>  # See the supportsDynlink function in go/src/cmd/compile/internal/gc/main.go
>  GO_DYNLINK = ""
> @@ -74,12 +82,7 @@ def go_map_arch(a, d):
>  def go_map_arm(a, f, d):
>  import re
>  if re.match('arm.*', a):
> -if 'armv7' in f:
> -return '7'
> -elif 'armv6' in f:
> -return '6'
> -elif 'armv5' in f:
> -return '5'
> +return f
>  return ''

Is this function still useful? Cannot you set TARGET_GOARM and
HOST_GOARM with arm override (to simulate the effect of "re.match('arm.*', a)")?

Regards,

>  
>  def go_map_386(a, f, d):
> -- 
> 2.7.4
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Alexander Kanavin]

It’s fine to use the shell rewrite in the native case, as it’s only used from 
one place under our control. This is not the case for the target where we have 
no idea where and how the script can be used. So you can’t argue that native 
has the same issues as target does, and therefore they must be the same. The 
reason we use shell rewrite for native is that it handles sysroots properly 
from what I remember.

If something is broken, please describe the steps to reproduce and I can look 
into it

Alex

> On 18 Mar 2019, at 17.00, Otavio Salvador  
> wrote:
> 
> Hello Alexander,
> 
> On Mon, Mar 18, 2019 at 11:53 AM Alexander Kanavin
>  wrote:
>> 
>> Apologies, but I still have to veto this. The concerns I expressed 
>> previously still stand.
>> 
>> The best course of action would be to work with the OpenSSL upstream to 
>> replace the utility with either C or shell version.
> 
> I understand your concerns about this however, those also stands for
> the native recipe. So we have two possible routes which seem to align
> with those concerns:
> 
> 1) assume the c_rehash in shell script is good enough and adopt it
> 2) drop c_rehash from openssl recipe
> 
> either work. The use of a different version for target and native does
> not seem consistent either correct.
> 
> As mentioned, this has been in use in multiple devices for years
> without concerns and this has been changed under the hood when moving
> to OpenSSL 1.1. Also, the ca-certificate is broken for installation on
> target now (as it uses c_rehash) and this is still unnoticed.
> 
> So I know your view on this. I'd like to know the view of other team
> members as well...
> 
> 
> -- 
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Otavio Salvador]

Hello Alexander,

On Mon, Mar 18, 2019 at 11:53 AM Alexander Kanavin
 wrote:
>
> Apologies, but I still have to veto this. The concerns I expressed previously 
> still stand.
>
> The best course of action would be to work with the OpenSSL upstream to 
> replace the utility with either C or shell version.

I understand your concerns about this however, those also stands for
the native recipe. So we have two possible routes which seem to align
with those concerns:

1) assume the c_rehash in shell script is good enough and adopt it
2) drop c_rehash from openssl recipe

either work. The use of a different version for target and native does
not seem consistent either correct.

As mentioned, this has been in use in multiple devices for years
without concerns and this has been changed under the hood when moving
to OpenSSL 1.1. Also, the ca-certificate is broken for installation on
target now (as it uses c_rehash) and this is still unnoticed.

So I know your view on this. I'd like to know the view of other team
members as well...


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [v3][PATCH 1/2] go.bbclass: Export more GO* environment variables

[Mark Asselstine]

Currently we are not doing a good job of consolidating GO environment
variables used by the go build system in the go.bbclass, instead we
are relying on the individual GO recipe authors to perform the
exports. This can result in inconsistent build results and often
binaries that are not properly cross compiled, resulting in segfaults
when the applications are run on the target.

For example the GO documentation recommends that the environment
include a value assigned to GOARM when cross building for ARMv5, ARMv6
and ARMv7 (https://github.com/golang/go/wiki/GoArm).

In order to avoid polluting the build scripts with unnecessary
exports, such as run.do_compile, we attempt to only export variables
when they apply to a specific arch.

Signed-off-by: Mark Asselstine 
---

V2
* Avoid potential undefined situations

V3
* Add more exports to cover the basics
* Tested on all qemu* variants, -native and build test other BSPs

 meta/classes/go.bbclass | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index 7069c5f..78c2d68 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -8,6 +8,25 @@ GOROOT = "${STAGING_LIBDIR}/go"
 export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
 
+export GOARCH = "${TARGET_GOARCH}"
+export GOOS = "${TARGET_GOOS}"
+export GOHOSTARCH="${BUILD_GOARCH}"
+export GOHOSTOS="${BUILD_GOOS}"
+
+GOARM[export] = "0"
+GOARM_arm_class-target = "${TARGET_GOARM}"
+GOARM_arm_class-target[export] = "1"
+
+GO386[export] = "0"
+GO386_x86_class-target = "${TARGET_GO386}"
+GO386_x86_class-target[export] = "1"
+GO386_i586_class-target = "${TARGET_GO386}"
+GO386_i586_class-target[export] = "1"
+
+GOMIPS[export] = "0"
+GOMIPS_mips_class-target = "${TARGET_GOMIPS}"
+GOMIPS_mips_class-target[export] = "1"
+
 DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go 
virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
 DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk 
virtual/${TARGET_PREFIX}go-runtime"
-- 
2.7.4

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

[OE-core] [v3][PATCH 2/2] goarch.bbclass: use MACHINEOVERRIDES and simplify go_map_arm()

[Mark Asselstine]

Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
cross building for ARMv5, ARMv6 and ARMv7. The current approach of
using TUNE_FEATURES can be error prone, as we can see today when
attempting to build for Cortex-A7 which results in GOARM=''.

Since the value of MACHINEOVERRIDES already consolidates the values of
TUNE_FEATURES into something more consistent we can use the overrides
mechanism to set GOARM, leaving just a little bit of logic in
go_map_arm() to trigger off the arch (basically target vs host)
for the setting of GOARM.

Signed-off-by: Mark Asselstine 
---

V2
* Cover all ARMv7 Cortex* variants

V3
* Switch to using MACHINEOVERRIDES/overrides mechanism

 meta/classes/goarch.bbclass | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 39fea5e..8fdb443 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -3,18 +3,26 @@ BUILD_GOARCH = "${@go_map_arch(d.getVar('BUILD_ARCH'), d)}"
 BUILD_GOTUPLE = "${BUILD_GOOS}_${BUILD_GOARCH}"
 HOST_GOOS = "${@go_map_os(d.getVar('HOST_OS'), d)}"
 HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH'), d)}"
-HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
+HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('BASE_GOARM'), d)}"
 HOST_GO386 = "${@go_map_386(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
 HOST_GOMIPS = "${@go_map_mips(d.getVar('HOST_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 HOST_GOTUPLE = "${HOST_GOOS}_${HOST_GOARCH}"
 TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS'), d)}"
 TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH'), d)}"
-TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
+TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), d.getVar('BASE_GOARM'), 
d)}"
 TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOMIPS = "${@go_map_mips(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOTUPLE = "${TARGET_GOOS}_${TARGET_GOARCH}"
 GO_BUILD_BINDIR = "${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE') 
== d.getVar('HOST_GOTUPLE')]}"
 
+# Use the MACHINEOVERRIDES to map ARM CPU architecture passed to GO via GOARM.
+# This is combined with *_ARCH to set HOST_GOARM and TARGET_GOARM.
+BASE_GOARM = ''
+BASE_GOARM_armv7ve = '7'
+BASE_GOARM_armv7a = '7'
+BASE_GOARM_armv6 = '6'
+BASE_GOARM_armv5 = '5'
+
 # Go supports dynamic linking on a limited set of architectures.
 # See the supportsDynlink function in go/src/cmd/compile/internal/gc/main.go
 GO_DYNLINK = ""
@@ -74,12 +82,7 @@ def go_map_arch(a, d):
 def go_map_arm(a, f, d):
 import re
 if re.match('arm.*', a):
-if 'armv7' in f:
-return '7'
-elif 'armv6' in f:
-return '6'
-elif 'armv5' in f:
-return '5'
+return f
 return ''
 
 def go_map_386(a, f, d):
-- 
2.7.4

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

Re: [OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Alexander Kanavin]

Apologies, but I still have to veto this. The concerns I expressed previously 
still stand.

The best course of action would be to work with the OpenSSL upstream to replace 
the utility with either C or shell version.

Alex

> On 18 Mar 2019, at 14.36, Otavio Salvador  wrote:
> 
> We had a c_rehash shell re-implementation being used for the native
> package and there is no reason to not use it as well for the
> target. This allows it to be available without the need of perl being
> installed.
> 
> This partially reverts OE-Core:d2b1a889ef (openssl: move c_rehash pkg
> to avoid perl dep) but still allows the removal of perl
> dependency.
> 
> The respective re-implementation was already in use here at OE-Core by
> the OpenSSL 1.0 recipe (since 2016) and were removed from the target
> recipe during the upgrade to the 1.1 release. So it now aligns the
> native and target recipes.
> 
> ,
> | Author: Otavio Salvador 
> | Date:   Mon May 23 17:45:25 2016 -0300
> |
> | openssl: Add Shell-Script based c_rehash utility
> |
> | The PLD Linux distribution has ported the c_rehash[1] utility from
> | Perl to Shell-Script, allowing it to be shipped by default.
> |
> | 1. 
> https://git.pld-linux.org/?p=packages/openssl.git;a=blob;f=openssl-c_rehash.sh;h=0ea22637ee6dbce845a9e2caf62540aaaf5d0761
> |
> | The OpenSSL upstream intends[2] to convert the utility for C
> | however did not yet finished the conversion.
> |
> | 2. https://rt.openssl.org/Ticket/Display.html?id=2324
> |
> | This patch adds this script and thus removed the Perl requirement
> | for it.
> |
> | Signed-off-by: Otavio Salvador 
> | Signed-off-by: Richard Purdie 
> `
> 
> Signed-off-by: Otavio Salvador 
> ---
> 
> Changes in v2:
> - updated commit log
> 
> .../openssl/openssl_1.1.1a.bb| 16 
> 1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> index 4a626a4fcd..a6f920e15b 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> @@ -128,7 +128,13 @@ do_install () {
> 
>oe_multilib_header openssl/opensslconf.h
> 
> -# Create SSL structure for packages such as ca-certificates which
> +# Install a custom version of c_rehash that can handle sysroots properly.
> +# This version is used for example when installing ca-certificates during
> +# image creation.
> +install -Dm 0755 ${WORKDIR}/openssl-c_rehash.sh ${D}${bindir}/c_rehash
> +sed -i -e 's,/etc/openssl,${sysconfdir}/ssl,g' ${D}${bindir}/c_rehash
> +
> +# Create SSL structure for packages such as ca-certificates which
># contain hard-coded paths to /etc/ssl. Debian does the same.
>install -d ${D}${sysconfdir}/ssl
>mv ${D}${libdir}/ssl-1.1/certs \
> @@ -149,12 +155,6 @@ do_install_append_class-native () {
>SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
>SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
>OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> -
> -# Install a custom version of c_rehash that can handle sysroots properly.
> -# This version is used for example when installing ca-certificates during
> -# image creation.
> -install -Dm 0755 ${WORKDIR}/openssl-c_rehash.sh ${D}${bindir}/c_rehash
> -sed -i -e 's,/etc/openssl,${sysconfdir}/ssl,g' ${D}${bindir}/c_rehash
> }
> 
> do_install_append_class-nativesdk () {
> @@ -196,7 +196,7 @@ FILES_libcrypto = "${libdir}/libcrypto${SOLIBS}"
> FILES_libssl = "${libdir}/libssl${SOLIBS}"
> FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
> FILES_${PN}-engines = "${libdir}/engines-1.1"
> -FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
> +FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
> FILES_${PN} =+ "${libdir}/ssl-1.1/*"
> FILES_${PN}_append_class-nativesdk = " 
> ${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
> 
> -- 
> 2.21.0
> 
> -- 
> ___
> 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] cross-canadian.bbclass: Do not override LIBCOVERRIDE with SDK libc override

[Richard Purdie]

On Thu, 2019-03-14 at 23:29 -0700, Khem Raj wrote:
> cross-canadian tools are supposed to generate code for target and if
> we
> override the libc override then needed overrides do not get applied
> when
> building gcc cross canadian e.g. for baremetal, which causes build
> failures during compile
> 
> e.g. https://github.com/riscv/meta-riscv/issues/117
> 
> Not override libc override helps us fix this issue
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/classes/cross-canadian.bbclass | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/meta/classes/cross-canadian.bbclass
> b/meta/classes/cross-canadian.bbclass
> index f5c9f61595..ee53faad79 100644
> --- a/meta/classes/cross-canadian.bbclass
> +++ b/meta/classes/cross-canadian.bbclass
> @@ -9,7 +9,6 @@
>  # or indirectly via dependency.  No need to be in 'world'.
>  EXCLUDE_FROM_WORLD = "1"
>  NATIVESDKLIBC ?= "libc-glibc"
> -LIBCOVERRIDE = ":${NATIVESDKLIBC}"
>  CLASSOVERRIDE = "class-cross-canadian"
>  STAGING_BINDIR_TOOLCHAIN =
> "${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${SDK_VENDOR}-
> ${SDK_OS}:${STAGING_DIR_NATIVE}${bindir_native}/${TARGET_ARCH}${TARGE
> T_VENDOR}-${TARGET_OS}"

Whilst I understand the problem, we need to be cautious here.

*-cross-canadian-* runs on nativesdk and for example often use glibc
even when the target uses musl. This change is partly reverting fixes
made to ensure that nativesdk worked as glibc (and glibc overrides were
applied correctly) even when the target system used musl.

I think this issue may need more investigation unfortunately...

Cheers,

Richard

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

Re: [OE-core] [PATCH 1/2] mesa: Update 18.3.4 -> 19.0.0

[Richard Purdie]

On Fri, 2019-03-15 at 18:21 -0300, Fabio Berton wrote:
>   - Patch 0005-egl-add-missing-include-stddef.h-in-egldevice.h.patch
> was applied on commit e68777c87ceed02ab199b32f941778c3cf97c794.
>   - Refresh all patches
>   - mesa 19.0.0 deprecated the use of autotools and we need to add
> --enable-autotools flag. For details see mesa commit:
> e68777c87ceed02ab199b32f941778c3cf97c794
> 
>   The complete change log can be found here:
> https://www.mesa3d.org/relnotes/19.0.0.html

This failed pretty much everywhere, e.g.:

https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/407

I think it will be too late to get this into 2.7.

Cheers,

Richard



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

[OE-core] Error in compiling meta-toolchain-qt5

[Mohammad Ali Boroumand]

Hi
I tried to compile meta-toolchain-qt5 for Raspberry Pi Zero since I need Qt
SDK for app developing, but I saw This error:

me@MAB-PC:~/Programs/poky/Builds/RP0$ bitbake meta-toolchain-qt5
Parsing recipes: 100%
|#|
Time: 0:00:23
Parsing of 2296 .bb files complete (0 cached, 2296 parsed). 3358 targets,
124 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.40.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "ubuntu-18.04"
TARGET_SYS   = "arm-poky-linux-gnueabi"
MACHINE  = "raspberrypi0"
DISTRO   = "poky"
DISTRO_VERSION   = "2.6+snapshot-20190318"
TUNE_FEATURES= "arm armv6 vfp arm1176jzfs callconvention-hard"
TARGET_FPU   = "hard"
meta
meta-poky
meta-yocto-bsp   = "master:47eb3d00e9d6a66aee1283dab29af8117a006d6d"
meta-oe
meta-multimedia
meta-networking
meta-python  = "master:423828d894a5c78ebe5fc527e9aeca66ac1838b1"
meta-raspberrypi = "master:09c00164d6ad978d444749a89e0a0a3d77a1735e"
meta-qt5 = "master:fb71293f257c6fd02ccc06765a96dbf11d4569a0"

Initialising tasks: 100%
|##|
Time: 0:00:01
Sstate summary: Wanted 1902 Found 0 Missed 1902 Current 0 (0% match, 0%
complete)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: qtwayland-5.12.0+gitAUTOINC+1dc85b95ab-r0 do_prepare_recipe_sysroot:
The file /usr/lib/libGLESv2.so.2.0.0 is installed by both mesa-gl and
userland, aborting
ERROR: qtwayland-5.12.0+gitAUTOINC+1dc85b95ab-r0 do_prepare_recipe_sysroot:
ERROR: qtwayland-5.12.0+gitAUTOINC+1dc85b95ab-r0 do_prepare_recipe_sysroot:
Function failed: extend_recipe_sysroot
ERROR: Logfile of failure stored in:
/home/me/Programs/poky/Builds/RP0/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/qtwayland/5.12.0+gitAUTOINC+1dc85b95ab-r0/temp/log.do_prepare_recipe_sysroot.690
ERROR: Task
(/home/me/Programs/poky/meta-qt5/recipes-qt/qt5/qtwayland_git.bb:do_prepare_recipe_sysroot)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 5085 tasks of which 0 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:
  /home/me/Programs/poky/meta-qt5/recipes-qt/qt5/qtwayland_git.bb:
do_prepare_recipe_sysroot
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.

I don't know how to solve this error. Could anyone have an Idea?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] openssl: Use the c_rehash shell re-implementation for target

[Otavio Salvador]

We had a c_rehash shell re-implementation being used for the native
package and there is no reason to not use it as well for the
target. This allows it to be available without the need of perl being
installed.

This partially reverts OE-Core:d2b1a889ef (openssl: move c_rehash pkg
to avoid perl dep) but still allows the removal of perl
dependency.

The respective re-implementation was already in use here at OE-Core by
the OpenSSL 1.0 recipe (since 2016) and were removed from the target
recipe during the upgrade to the 1.1 release. So it now aligns the
native and target recipes.

,
| Author: Otavio Salvador 
| Date:   Mon May 23 17:45:25 2016 -0300
|
| openssl: Add Shell-Script based c_rehash utility
|
| The PLD Linux distribution has ported the c_rehash[1] utility from
| Perl to Shell-Script, allowing it to be shipped by default.
|
| 1. 
https://git.pld-linux.org/?p=packages/openssl.git;a=blob;f=openssl-c_rehash.sh;h=0ea22637ee6dbce845a9e2caf62540aaaf5d0761
|
| The OpenSSL upstream intends[2] to convert the utility for C
| however did not yet finished the conversion.
|
| 2. https://rt.openssl.org/Ticket/Display.html?id=2324
|
| This patch adds this script and thus removed the Perl requirement
| for it.
|
| Signed-off-by: Otavio Salvador 
| Signed-off-by: Richard Purdie 
`

Signed-off-by: Otavio Salvador 
---

Changes in v2:
- updated commit log

 .../openssl/openssl_1.1.1a.bb| 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
index 4a626a4fcd..a6f920e15b 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
@@ -128,7 +128,13 @@ do_install () {
 
oe_multilib_header openssl/opensslconf.h
 
-   # Create SSL structure for packages such as ca-certificates which
+   # Install a custom version of c_rehash that can handle sysroots 
properly.
+   # This version is used for example when installing ca-certificates 
during
+   # image creation.
+   install -Dm 0755 ${WORKDIR}/openssl-c_rehash.sh ${D}${bindir}/c_rehash
+   sed -i -e 's,/etc/openssl,${sysconfdir}/ssl,g' ${D}${bindir}/c_rehash
+
+# Create SSL structure for packages such as ca-certificates which
# contain hard-coded paths to /etc/ssl. Debian does the same.
install -d ${D}${sysconfdir}/ssl
mv ${D}${libdir}/ssl-1.1/certs \
@@ -149,12 +155,6 @@ do_install_append_class-native () {
SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
-
-   # Install a custom version of c_rehash that can handle sysroots 
properly.
-   # This version is used for example when installing ca-certificates 
during
-   # image creation.
-   install -Dm 0755 ${WORKDIR}/openssl-c_rehash.sh ${D}${bindir}/c_rehash
-   sed -i -e 's,/etc/openssl,${sysconfdir}/ssl,g' ${D}${bindir}/c_rehash
 }
 
 do_install_append_class-nativesdk () {
@@ -196,7 +196,7 @@ FILES_libcrypto = "${libdir}/libcrypto${SOLIBS}"
 FILES_libssl = "${libdir}/libssl${SOLIBS}"
 FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
 FILES_${PN}-engines = "${libdir}/engines-1.1"
-FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
+FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
 FILES_${PN} =+ "${libdir}/ssl-1.1/*"
 FILES_${PN}_append_class-nativesdk = " 
${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
 
-- 
2.21.0

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

Re: [OE-core] [PATCH 1/2] lttng-tools ptest: add missing dependencies

[Richard Purdie]

On Fri, 2019-03-15 at 10:40 -0400, Jonathan Rajotte-Julien wrote:
> > Firstly, I wanted to say thanks for looking at this, there are some
> > really great fixes in here.
> > 
> > It failed in automated testing as glibc-utils is glibc specific and
> > musl builds couldn't cope with that.
> > 
> > We can certainly do:
> > 
> > RDEPENDS_${PN}-ptest_append_libc-glibc = " glibc-utils"
> 
> Sure, since we mostly need getconf from glibc-utils, we can use musl-
> utils to provide it when building with musl.
> 
> RDEPENDS_${PN}-ptest_append_libc-musl = " musl-utils"

Thanks for confirmation of that.

Since the patches with a couple of fixes were passing the tests, I've
merged the patches with the glibc/muslc tweak and also a tweak to make
disabled ust work. I'd normally wait for v2 resubmission but I wanted
to get this fix into M3 and the M3 build is already behind schedule.

I was at a conference last week so a bit distracted, just catching up
now.

> Also, I saw that lttng-ust is removed from PACKAGECONFIG when using
> musl, not sure why the commit history is not particularly verbose
> regarding why it was a problem. Still, it seems to build fine but we
> are seeing issue regarding musl.

I think when we originally merged musl, lttng didn't build with it or
there were some kind of issues. I suspect lttng-ust still doesn't work
on all the architectures we build for so we likely need to be able to
optionally disable it. I'd be happy to see patches enabling it where it
does work though.


> We checked with Alpine since they also use musl and see similar
> problem. I'm investigating on that front. I'll let you know what I
> find.
> 
> Side note, gdb simply segfault (at start) for me on a core-image-
> minirmnal build using musl.
> How would someone open the corefile generated on the build system
> with the proper libs and all?

I saw other discussion about this so it looks like you're making
progress on this front. If not, Khem would be the person to ask about
this as our musl expert...

Cheers,

Richard

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

Re: [OE-core] Cannot get bitbake multiconfig to work

[Richard Purdie]

On Wed, 2019-03-13 at 10:03 +, Mike Looijmans wrote:
> I think I've done everything, but cannot figure out what step I
> missed.
> 
> I am using yesterday's "thud" branches:
> 
> BB_VERSION   = "1.40.0"
> BUILD_SYS= "x86_64-linux"
> meta =
> "HEAD:fbb688ab3eeca1bbfbffd8c81fd8052bcc68"
> meta-oe
> meta-multimedia
> meta-networking
> meta-python  =
> "HEAD:6ef9657068492d4644079c88f2adee9c3cac9543"
> 
> 
> I created a conf/multiconf directory with a "pmu.conf" file (and
> others)
> 
> $ cat conf/multiconfig/pmu.conf
> MACHINE="zynqmp-pmu"
> DISTRO="xilinx-standalone"
> GCCVERSION="7.%"
> TMPDIR="${TOPDIR}/pmutmp"
> 
> I added to my local.conf (and removed the MACHINE setting there):
> 
> BBMULTICONFIG = "pmu ..."
> 
> Now when I invoke bitbake with the multiconfig syntax, it completely
> ignores that:
> 
> $ bitbake multiconfig:pmu:pmu-firmware
> ERROR:  OE-core's config sanity checker detected a potential
> misconfiguration.
>  Either fix the cause of this error or at your own risk disable
> the 
> checker (see sanity.conf).
>  Following is the list of potential problems / advisories:
> 
>  Please set a MACHINE in your local.conf or environment
> 
> 
> Apparently, bitbake doesn't even care about the "multiconfig:"
> syntax, I get 
> the same response when I type:
> $ bitbake multiconfig:blah:pmu-firmware
> $ bitbake multiconfig:blah:blah
> $ bitbake blah:blah:blah
> 
> I can add a "MACHINE?=" to local.conf, which results in a build for
> that 
> machine and nothing from the pmu.conf gets ever used at all.
> 
> So what step did I miss?


The piece most people miss when thinking about multiconfig is that
local.conf still needs to be valid as one of the configurations. Did
you try setting MACHINE to something valid in local.conf and then
building the pmu multiconfig?

Cheers,

Richard

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

Re: [OE-core] Where are the mails from patchwork (was: RE: [PATCH] [PATCH] openssl:upgrade to 1.1.1b)

[Richard Purdie]

On Mon, 2019-03-18 at 10:52 +0100, Alexander Kanavin wrote:
> Sorry, Leonardo is the correct person, and if not him, then Paul.

I did notice this had gone missing a while ago and asked Michael to
look into it. It appears the system is running and sending out mails
but those mails don't arrive back to the mailing lists or patch
senders. Michael has other distractions right now which have priority
over this.

Anibal/Leo no longer work on this and we're struggling for maintainers
for various subsections of the project, this is one of them which
compounds the problem. Having tests of this would be ideal but those
take time investment to develop.

Its not a good situation but we will get to figuring this out, I
suspect just not as soon as would be ideal.

Cheers,

Richard


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

Re: [OE-core] Where are the mails from patchwork (was: RE: [PATCH] [PATCH] openssl:upgrade to 1.1.1b)

[Alexander Kanavin]

Sorry, Leonardo is the correct person, and if not him, then Paul.

Alex


On Mon, 18 Mar 2019 at 10:45, Alexander Kanavin  wrote:
>
> On Mon, 18 Mar 2019 at 10:37, Peter Kjellerstedt
>  wrote:
>
> > Whatever happened to the mails from patchwork that used to
> > automatically complain about things like this with:
> >
> > * Issue LIC_FILES_CHKSUM changed on target openssl but there is 
> > no "License-Update" tag in commit message 
> > [test_lic_files_chksum_modified_not_mentioned]
> >   Suggested fixInclude "License-Update: " into the commit 
> > message with a brief description
> >   Current checksum file://LICENCE;md5=d57d511030c9d66ef5f5966bee5a7eff
> >   New checksum file://LICENCE;md5=d343e62fc9c833710bbbed25f27364c8
>
> Anibal, can you check this please?
>
> 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] Where are the mails from patchwork (was: RE: [PATCH] [PATCH] openssl:upgrade to 1.1.1b)

[Alexander Kanavin]

On Mon, 18 Mar 2019 at 10:37, Peter Kjellerstedt
 wrote:

> Whatever happened to the mails from patchwork that used to
> automatically complain about things like this with:
>
> * Issue LIC_FILES_CHKSUM changed on target openssl but there is 
> no "License-Update" tag in commit message 
> [test_lic_files_chksum_modified_not_mentioned]
>   Suggested fixInclude "License-Update: " into the commit 
> message with a brief description
>   Current checksum file://LICENCE;md5=d57d511030c9d66ef5f5966bee5a7eff
>   New checksum file://LICENCE;md5=d343e62fc9c833710bbbed25f27364c8

Anibal, can you check this please?

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

[OE-core] Where are the mails from patchwork (was: RE: [PATCH] [PATCH] openssl:upgrade to 1.1.1b)

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Alexander Kanavin
> Sent: den 18 mars 2019 09:52
> To: Hong Liu 
> Cc: OE-core 
> Subject: Re: [OE-core] [PATCH] [PATCH] openssl:upgrade to 1.1.1b
> 
> On Mon, 18 Mar 2019 at 02:20, Hong Liu 
> wrote:
> > -LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
> > +LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
> 
> You need to explain what changed (in the commit message).
> Try 'devtool upgrade openssl', it will make a diff of the two licenses
> for you.
> 
> Also, openssl10 needs a similar upgrade.
> 
> Alex

Whatever happened to the mails from patchwork that used to 
automatically complain about things like this with:

* Issue LIC_FILES_CHKSUM changed on target openssl but there is no 
"License-Update" tag in commit message 
[test_lic_files_chksum_modified_not_mentioned] 
  Suggested fixInclude "License-Update: " into the commit 
message with a brief description
  Current checksum file://LICENCE;md5=d57d511030c9d66ef5f5966bee5a7eff
  New checksum file://LICENCE;md5=d343e62fc9c833710bbbed25f27364c8

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

Re: [OE-core] [PATCH] [PATCH] openssl:upgrade to 1.1.1b

[Alexander Kanavin]

On Mon, 18 Mar 2019 at 02:20, Hong Liu  wrote:
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"

You need to explain what changed (in the commit message).
Try 'devtool upgrade openssl', it will make a diff of the two licenses for you.

Also, openssl10 needs a similar upgrade.

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