date:20200513

[OE-core] ✗ patchtest: failure for "tune-cortexa55.inc: crc and cr..." and 5 more

2020-05-13 Thread Patchwork

== Series Details ==

Series: "tune-cortexa55.inc: crc and cr..." and 5 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/24139/
State : failure

== Summary ==


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



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



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

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138248): 
https://lists.openembedded.org/g/openembedded-core/message/138248
Mute This Topic: https://lists.openembedded.org/mt/74199242/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 4/6] gcc: Do not set -march for arm64 for libatomic

2020-05-13 Thread Khem Raj

libatomic has mind of its own when it comes to setting -march for arm64
which conflicts with -mcpu option we pass from environment in some cases
since we always pass -march/-mcpu in OE, its safe to remove this option

mcpu removal from cortex-a55 is no longer needed since the option
conflict is now removed from libatomic instead

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-10.1.inc|  1 +
 ...omic-Do-not-enforce-march-on-aarch64.patch | 42 +++
 meta/recipes-devtools/gcc/gcc-runtime.inc |  4 --
 3 files changed, 43 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-10.1/0039-libatomic-Do-not-enforce-march-on-aarch64.patch

diff --git a/meta/recipes-devtools/gcc/gcc-10.1.inc 
b/meta/recipes-devtools/gcc/gcc-10.1.inc
index 245f0a6fdb..82b5a20a42 100644
--- a/meta/recipes-devtools/gcc/gcc-10.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-10.1.inc
@@ -66,6 +66,7 @@ SRC_URI = "\
file://0036-Enable-CET-in-cross-compiler-if-possible.patch \
file://0037-mingw32-Enable-operation_not_supported.patch \

file://0038-Revert-AArch64-Use-__getauxval-instead-of-getauxval-.patch \
+   file://0039-libatomic-Do-not-enforce-march-on-aarch64.patch \
 "
 SRC_URI[sha256sum] = 
"b6898a23844b656f1b68691c5c012036c2e694ac4b53a8918d4712ad876e7ea2"
 
diff --git 
a/meta/recipes-devtools/gcc/gcc-10.1/0039-libatomic-Do-not-enforce-march-on-aarch64.patch
 
b/meta/recipes-devtools/gcc/gcc-10.1/0039-libatomic-Do-not-enforce-march-on-aarch64.patch
new file mode 100644
index 00..fecb562f51
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-10.1/0039-libatomic-Do-not-enforce-march-on-aarch64.patch
@@ -0,0 +1,42 @@
+From 411fc85c14bb14b07c0db807c55d25ce3f3e507f Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Wed, 13 May 2020 15:10:38 -0700
+Subject: [PATCH] libatomic: Do not enforce march on aarch64
+
+OE passes the right options via gcc compiler cmdline via TUNE_CCARGS
+this can conflict between -mcpu settings and -march setting here, since
+-mcpu will translate into an appropriate -march, lets depend on that
+instead of setting it explicitly
+
+Upstream-Status: Inappropriate [OE-Specific]
+
+Signed-off-by: Khem Raj 
+---
+ libatomic/Makefile.am | 1 -
+ libatomic/Makefile.in | 1 -
+ 2 files changed, 2 deletions(-)
+
+diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am
+index 133fbbca77e..ac1ca645876 100644
+--- a/libatomic/Makefile.am
 b/libatomic/Makefile.am
+@@ -125,7 +125,6 @@ libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix 
_$(s)_.lo,$(SIZEOBJS)))
+ ## On a target-specific basis, include alternates to be selected by IFUNC.
+ if HAVE_IFUNC
+ if ARCH_AARCH64_LINUX
+-IFUNC_OPTIONS  = -march=armv8-a+lse
+ libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix 
_$(s)_1_.lo,$(SIZEOBJS)))
+ endif
+ if ARCH_ARM_LINUX
+diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in
+index a51807e95c9..97df2d7ff03 100644
+--- a/libatomic/Makefile.in
 b/libatomic/Makefile.in
+@@ -431,7 +431,6 @@ M_SRC = $(firstword $(filter %/$(M_FILE), $(all_c_files)))
+ libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix \
+   _$(s)_.lo,$(SIZEOBJS))) $(am__append_1) $(am__append_2) \
+   $(am__append_3) $(am__append_4)
+-@ARCH_AARCH64_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv8-a+lse
+ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a+fp 
-DHAVE_KERNEL64
+ @ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=i586
+ @ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -mcx16
diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index 38c1672876..e12c74613f 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -18,10 +18,6 @@ EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
 EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
 EXTRA_OECONF_append_libc-newlib = " --with-newlib"
 
-# cortex-a55 is ARMv8.2-a based but libatomic explicitly asks for 
-march=armv8.1-a
-# which caused -march conflicts in gcc
-TUNE_CCARGS_remove = "-mcpu=cortex-a55+crc -mcpu=cortex-a55 
-mcpu=cortex-a55+crc+crypto"
-
 # Disable ifuncs for libatomic on arm conflicts -march/-mcpu
 EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
 EXTRA_OECONF_append_armeb = " libat_cv_have_ifunc=no "
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138245): 
https://lists.openembedded.org/g/openembedded-core/message/138245
Mute This Topic: https://lists.openembedded.org/mt/74199030/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 6/6] armv8/tunes: Define TUNE_PKGARCH

2020-05-13 Thread Khem Raj

Now that they uses -mcpu, its better to have tune specific build
directories, since aarch64 wont be appropriate any longer

Signed-off-by: Khem Raj 
---
 meta/conf/machine/include/tune-cortexa53.inc   | 4 
 meta/conf/machine/include/tune-cortexa55.inc   | 1 +
 meta/conf/machine/include/tune-cortexa57-cortexa53.inc | 1 +
 meta/conf/machine/include/tune-cortexa57.inc   | 2 ++
 meta/conf/machine/include/tune-cortexa72-cortexa53.inc | 2 ++
 meta/conf/machine/include/tune-cortexa72.inc   | 1 +
 meta/conf/machine/include/tune-cortexa73-cortexa53.inc | 2 ++
 7 files changed, 13 insertions(+)

diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
index 6c0b443eaf..b7327d00c4 100644
--- a/meta/conf/machine/include/tune-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -13,5 +13,9 @@ TUNE_FEATURES_tune-cortexa53  = "aarch64 cortexa53 
crc"
 TUNE_FEATURES_tune-cortexa53-crypto   = "aarch64 cortexa53 crc crypto"
 PACKAGE_EXTRA_ARCHS_tune-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa53 cortexa53-crypto"
+
+TUNE_PKGARCH_tune-cortexa53 = "cortexa53"
+TUNE_PKGARCH_tune-cortexa53-crypto = "cortexa53-crypto"
+
 BASE_LIB_tune-cortexa53   = "lib64"
 BASE_LIB_tune-cortexa53-crypto= "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa55.inc 
b/meta/conf/machine/include/tune-cortexa55.inc
index 89032b59ec..274944819e 100644
--- a/meta/conf/machine/include/tune-cortexa55.inc
+++ b/meta/conf/machine/include/tune-cortexa55.inc
@@ -9,5 +9,6 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa55"
 ARMPKGARCH_tune-cortexa55 = "cortexa55"
 TUNE_FEATURES_tune-cortexa55  = "aarch64 cortexa55 crc crypto"
+TUNE_PKGARCH_tune-cortexa55   = "cortexa55"
 PACKAGE_EXTRA_ARCHS_tune-cortexa55= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55"
 BASE_LIB_tune-cortexa55   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
index ba4b073852..b95d63e86b 100644
--- a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
@@ -11,5 +11,6 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa57-cortexa53"
 ARMPKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
 TUNE_FEATURES_tune-cortexa57-cortexa53 = "aarch64 cortexa57-cortexa53"
+TUNE_PKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa57-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa57-cortexa53"
 BASE_LIB_tune-cortexa57-cortexa53 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa57.inc 
b/meta/conf/machine/include/tune-cortexa57.inc
index 645a5a7ef6..e8ddeb5786 100644
--- a/meta/conf/machine/include/tune-cortexa57.inc
+++ b/meta/conf/machine/include/tune-cortexa57.inc
@@ -13,5 +13,7 @@ TUNE_FEATURES_tune-cortexa57  = "aarch64 cortexa57 
crc"
 TUNE_FEATURES_tune-cortexa57-crypto   = "aarch64 cortexa57 crc crypto"
 PACKAGE_EXTRA_ARCHS_tune-cortexa57 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa57"
 PACKAGE_EXTRA_ARCHS_tune-cortexa57-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa57 cortexa57-crypto"
+TUNE_PKGARCH_tune-cortexa57 = "cortexa57"
+TUNE_PKGARCH_tune-cortexa57-crypto = "cortexa57-crypto"
 BASE_LIB_tune-cortexa57   = "lib64"
 BASE_LIB_tune-cortexa57-crypto= "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
index 5c54aa33ea..fd1ffeb177 100644
--- a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
@@ -15,6 +15,8 @@ TUNE_FEATURES_tune-cortexa72-cortexa53   = 
"aarch64 crc cortexa72-co
 TUNE_FEATURES_tune-cortexa72-cortexa53-crypto= "aarch64 crc crypto 
cortexa72-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc}cortexa72-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72-cortexa53 
cortexa72-cortexa53-crypto"
+TUNE_PKGARCH_tune-cortexa72-cortexa53= "cortexa72-cortexa53"
+TUNE_PKGARCH_tune-cortexa72-cortexa53-crypto = 
"cortexa72-cortexa53-crypto"
 BASE_LIB_tune-cortexa72-cortexa53= "lib64"
 BASE_LIB_tune-cortexa72-cortexa53-crypto = "lib64"
 
diff --git a/meta/conf/machine/include/tune-cortexa72.inc 
b/meta/conf/machine/include/tune-cortexa72.inc
index 00f7745a22..23640d5c1f 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -10,4 +10,5 @@

[OE-core] [PATCH 2/6] tune-cortexa57.inc: Add new tune file

2020-05-13 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 meta/conf/machine/include/tune-cortexa57.inc | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa57.inc

diff --git a/meta/conf/machine/include/tune-cortexa57.inc 
b/meta/conf/machine/include/tune-cortexa57.inc
new file mode 100644
index 00..645a5a7ef6
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa57.inc
@@ -0,0 +1,17 @@
+DEFAULTTUNE ?= "cortexa57"
+
+TUNEVALID[cortexa57] = "Enable Cortex-A57 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa57', ' 
-mcpu=cortex-a57', '', d)}"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+# Little Endian base configs
+AVAILTUNES += "cortexa57 cortexa57-crypto"
+ARMPKGARCH_tune-cortexa57 = "cortexa57"
+ARMPKGARCH_tune-cortexa57-crypto  = "cortexa57"
+TUNE_FEATURES_tune-cortexa57  = "aarch64 cortexa57 crc"
+TUNE_FEATURES_tune-cortexa57-crypto   = "aarch64 cortexa57 crc crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa57 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa57"
+PACKAGE_EXTRA_ARCHS_tune-cortexa57-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa57 cortexa57-crypto"
+BASE_LIB_tune-cortexa57   = "lib64"
+BASE_LIB_tune-cortexa57-crypto= "lib64"
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138243): 
https://lists.openembedded.org/g/openembedded-core/message/138243
Mute This Topic: https://lists.openembedded.org/mt/74199028/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 5/6] aarch64: Adjust big.LITTLE tune files to use -mcpu

2020-05-13 Thread Khem Raj

mcpu is more appropriate on aarch64 and generates more optimized code
forr a given SOC, unlike -march/-mtune combination as decribed here [1]

[1] 
https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu

Signed-off-by: Khem Raj 
---
 .../conf/machine/include/tune-cortexa57-cortexa53.inc |  9 +++--
 .../conf/machine/include/tune-cortexa72-cortexa53.inc | 11 ---
 .../conf/machine/include/tune-cortexa73-cortexa53.inc | 11 ---
 3 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
index d05e93f51e..ba4b073852 100644
--- a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
@@ -1,18 +1,15 @@
 DEFAULTTUNE ?= "cortexa57-cortexa53"
-require conf/machine/include/arm/arch-armv8a.inc
 
 TUNEVALID[cortexa57-cortexa53] = "Enable big.LITTLE Cortex-A57.Cortex-A53 
specific processor optimizations"
 TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
-
-TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "aarch64", " 
-march=armv8-a", "" ,d)}"
-
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa57-cortexa53", " 
-mcpu=cortex-a57.cortex-a53", "", d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", 
"cortexa57-cortexa53", "cortexa57-cortexa53:", "" ,d)}"
 
-TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa57-cortexa53", " 
-mtune=cortex-a57.cortex-a53", "", d)}"
+require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
 AVAILTUNES += "cortexa57-cortexa53"
 ARMPKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
-TUNE_FEATURES_tune-cortexa57-cortexa53 = "${TUNE_FEATURES_tune-aarch64} 
cortexa57-cortexa53"
+TUNE_FEATURES_tune-cortexa57-cortexa53 = "aarch64 cortexa57-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa57-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa57-cortexa53"
 BASE_LIB_tune-cortexa57-cortexa53 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
index f208b98e3e..5c54aa33ea 100644
--- a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
@@ -1,21 +1,18 @@
 DEFAULTTUNE ?= "cortexa72-cortexa53"
 
-require conf/machine/include/arm/arch-armv8a.inc
-
 TUNEVALID[cortexa72-cortexa53] = "Enable big.LITTLE Cortex-A72.Cortex-A53 
specific processor optimizations"
-
 TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
-
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa72-cortexa53", " 
-mcpu=cortex-a72.cortex-a53", "", d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", 
"cortexa72-cortexa53", "cortexa72-cortexa53:", "" ,d)}"
 
-TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa72-cortexa53", " 
-mtune=cortex-a72.cortex-a53", "", d)}"
+require conf/machine/include/arm/arch-armv8a.inc
 
 # cortexa72.cortexa53 implies crc support
 AVAILTUNES += "cortexa72-cortexa53 cortexa72-cortexa53-crypto"
 ARMPKGARCH_tune-cortexa72-cortexa53  = "cortexa72-cortexa53"
 ARMPKGARCH_tune-cortexa72-cortexa53-crypto   = "cortexa72-cortexa53"
-TUNE_FEATURES_tune-cortexa72-cortexa53   = 
"${TUNE_FEATURES_tune-armv8a-crc} cortexa72-cortexa53"
-TUNE_FEATURES_tune-cortexa72-cortexa53-crypto= 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72-cortexa53"
+TUNE_FEATURES_tune-cortexa72-cortexa53   = "aarch64 crc 
cortexa72-cortexa53"
+TUNE_FEATURES_tune-cortexa72-cortexa53-crypto= "aarch64 crc crypto 
cortexa72-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc}cortexa72-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72-cortexa53 
cortexa72-cortexa53-crypto"
 BASE_LIB_tune-cortexa72-cortexa53= "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa73-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
index 8df418227f..431d244fe2 100644
--- a/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
@@ -1,21 +1,18 @@
 DEFAULTTUNE ?= "cortexa73-cortexa53"
 
-require conf/machine/include/arm/arch-armv8a.inc
-
 TUNEVALID[cortexa73-cortexa53] = "Enable big.LITTLE Cortex-A73.Cortex-A53 
specific processor optimizations"
-
 TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
-
 MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", 
"cortexa73-cortexa53", "cortexa73-cortexa53:", "" ,d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53", " 
-mcpu=cortex-a73.cortex-a53", "", d)}"
 
-TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53",

[OE-core] [PATCH 3/6] qemuarm64.conf: Use cortext-a57 as default tune

2020-05-13 Thread Khem Raj

This is more appropriate for the machine we are emulating

Signed-off-by: Khem Raj 
---
 meta/conf/machine/qemuarm64.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index 1e2d4f018d..92da16888a 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -2,7 +2,7 @@
 #@NAME: QEMU ARMv8 machine
 #@DESCRIPTION: Machine configuration for running an ARMv8 system on QEMU
 
-require conf/machine/include/arm/arch-armv8a.inc
+require conf/machine/include/tune-cortexa55.inc
 require conf/machine/include/qemu.inc
 
 KERNEL_IMAGETYPE = "Image"
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138244): 
https://lists.openembedded.org/g/openembedded-core/message/138244
Mute This Topic: https://lists.openembedded.org/mt/74199029/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/6] tune-cortexa55.inc: crc and crypto extentions are default on cortex-a55

2020-05-13 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 meta/conf/machine/include/tune-cortexa55.inc | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa55.inc 
b/meta/conf/machine/include/tune-cortexa55.inc
index 8242cc9cef..89032b59ec 100644
--- a/meta/conf/machine/include/tune-cortexa55.inc
+++ b/meta/conf/machine/include/tune-cortexa55.inc
@@ -6,12 +6,8 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 
'cortexa55', ' -mcpu=corte
 require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
-AVAILTUNES += "cortexa55 cortexa55-crypto"
+AVAILTUNES += "cortexa55"
 ARMPKGARCH_tune-cortexa55 = "cortexa55"
-ARMPKGARCH_tune-cortexa55-crypto  = "cortexa55"
-TUNE_FEATURES_tune-cortexa55  = "aarch64 cortexa55 crc"
-TUNE_FEATURES_tune-cortexa55-crypto   = "aarch64 cortexa55 crc crypto"
-PACKAGE_EXTRA_ARCHS_tune-cortexa55 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa55"
-PACKAGE_EXTRA_ARCHS_tune-cortexa55-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55 cortexa55-crypto"
+TUNE_FEATURES_tune-cortexa55  = "aarch64 cortexa55 crc crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa55= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55"
 BASE_LIB_tune-cortexa55   = "lib64"
-BASE_LIB_tune-cortexa55-crypto= "lib64"
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138242): 
https://lists.openembedded.org/g/openembedded-core/message/138242
Mute This Topic: https://lists.openembedded.org/mt/74199027/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/2] libva: upgrade 2.6.1 -> 2.7.1

2020-05-13 Thread Naveen Saini

Hi Richard,

These patches apply on top of current master.

Regards,
Naveen

-Original Message-
From: Richard Purdie  
Sent: Thursday, May 14, 2020 5:35 AM
To: Saini, Naveen Kumar ; 
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 1/2] libva: upgrade 2.6.1 -> 2.7.1

On Wed, 2020-05-13 at 01:14 +, Naveen Saini wrote:
> Ping

Needs rebasing against master please as there were other libva changes recently.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138241): 
https://lists.openembedded.org/g/openembedded-core/message/138241
Mute This Topic: https://lists.openembedded.org/mt/74070041/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] gcr: depends on gnupg-native

2020-05-13 Thread kai


On 2020/5/11 下午5:23, kai.k...@windriver.com wrote:

From: Kai Kang 

It fails to build gcr if no commmand gpg on build host:

| meson.build:44:0: ERROR: Program(s) ['gpg2', 'gpg'] not found or not 
executable

Add dependency gnupg-native to fix the error.

Signed-off-by: Kai Kang 
---
  meta/recipes-gnome/gcr/gcr_3.36.0.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/gcr/gcr_3.36.0.bb 
b/meta/recipes-gnome/gcr/gcr_3.36.0.bb
index 4fe3b2fff3..458dc8e6c4 100644
--- a/meta/recipes-gnome/gcr/gcr_3.36.0.bb
+++ b/meta/recipes-gnome/gcr/gcr_3.36.0.bb
@@ -8,7 +8,7 @@ BUGTRACKER = "https://gitlab.gnome.org/GNOME/gcr/issues;
  LICENSE = "GPLv2"
  LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605"
  
-DEPENDS = "gtk+3 p11-kit glib-2.0 libgcrypt \

+DEPENDS = "gtk+3 p11-kit glib-2.0 libgcrypt gnupg-native \
 ${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'libxslt-native', '', 
d)}"
  
  GNOMEBASEBUILDCLASS = "meson"


Any comment, please?

--
Kai Kang
Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138240): 
https://lists.openembedded.org/g/openembedded-core/message/138240
Mute This Topic: https://lists.openembedded.org/mt/74132108/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] file: Remove unneccessary override of PACKAGECONFIG for native

2020-05-13 Thread Andre McCurdy

On Wed, May 13, 2020 at 2:31 PM Richard Purdie
 wrote:
> On Wed, 2020-05-13 at 12:30 -0700, Andre McCurdy wrote:
> > Yes. Unfortunately making recipes robust for users who want to change
> > PACKAGECONFIG values doesn't seem to be a high priority for oe-core.
> > Why else would default PACKAGECONFIG values be assigned with ??=
> > instead of ?= other than as a trap for new users?
>
> I'm not sure I understand that, equally I'm tired so I'll assume I'm
> just missing something.
>
> I will say that there is no intention to make OE-Core hard to use or
> not robust, its only as good a the people contributing make it. In this
> case I'm not sure I understand/see the problem.
>
> If we should be using ?= instead of ??= then I'm open to an explanation
> why and patches to improve things.

If the default is assigned with ??= then trying to add to it with +=
results in the default value being lost. If the default is assigned
with ?= then adding to it with += works as expected.

To robustly enable a new PACKAGECONFIG option, users need to learn to
use PACKAGECONFIG_append (and obviously learn about the leading space
requirement there too) and not to try PACKAGECONFIG +=.

The reference manual does at least have an example which uses _append.
However it doesn't mention that += isn't safe or that _append will
affect native(sdk) and therefore _append_class-target is the safest
approach.

> Unfortunately we do have quite some legacy and ??= vs ?= has been
> troublesome in the many different contexts we have (recipe, class,
> conf, inc and so on).
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138239): 
https://lists.openembedded.org/g/openembedded-core/message/138239
Mute This Topic: https://lists.openembedded.org/mt/74169167/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH] apt: The C.UTF-8 locale is not portable

2020-05-13 Thread Adrian Bunk

Signed-off-by: Adrian Bunk 
---
 meta/recipes-devtools/apt/apt.inc |  1 +
 ...le-is-not-portable-use-std-locale-cl.patch | 27 +++
 2 files changed, 28 insertions(+)
 create mode 100644 
meta/recipes-devtools/apt/apt/0001-The-C.UTF-8-locale-is-not-portable-use-std-locale-cl.patch

diff --git a/meta/recipes-devtools/apt/apt.inc 
b/meta/recipes-devtools/apt/apt.inc
index 13f5969f86..87d533782f 100644
--- a/meta/recipes-devtools/apt/apt.inc
+++ b/meta/recipes-devtools/apt/apt.inc
@@ -17,6 +17,7 @@ SRC_URI = 
"https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/${BPN}/${P

file://0001-environment.mak-musl-based-systems-can-generate-shar.patch \
file://0001-apt-1.2.12-Fix-musl-build.patch \
file://0001-Include-array.h-for-std-array.patch \
+   
file://0001-The-C.UTF-8-locale-is-not-portable-use-std-locale-cl.patch \
"
 SRC_URI[md5sum] = "d30eed9304e82ea8238c854b5c5a34d9"
 SRC_URI[sha256sum] = 
"03ded4f5e9b8d43ecec083704b2dcabf20c182ed382db9ac7251da0b0b038059"
diff --git 
a/meta/recipes-devtools/apt/apt/0001-The-C.UTF-8-locale-is-not-portable-use-std-locale-cl.patch
 
b/meta/recipes-devtools/apt/apt/0001-The-C.UTF-8-locale-is-not-portable-use-std-locale-cl.patch
new file mode 100644
index 00..ce5c005086
--- /dev/null
+++ 
b/meta/recipes-devtools/apt/apt/0001-The-C.UTF-8-locale-is-not-portable-use-std-locale-cl.patch
@@ -0,0 +1,27 @@
+From 7e8839731ae3fdf7502b91643aa6b252f6c5eaa6 Mon Sep 17 00:00:00 2001
+From: Adrian Bunk 
+Date: Thu, 14 May 2020 00:08:21 +0300
+Subject: The C.UTF-8 locale is not portable, use std::locale::classic()
+
+Upstream-Status: Inappropriate [Similar fix already in apt >= 1.3]
+Signed-off-by: Adrian Bunk 
+---
+ ftparchive/writer.cc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/ftparchive/writer.cc b/ftparchive/writer.cc
+index 25963820a..6ad571d2a 100644
+--- a/ftparchive/writer.cc
 b/ftparchive/writer.cc
+@@ -984,7 +984,7 @@ ReleaseWriter::ReleaseWriter(FileFd * const GivenOutput, 
string const &/*DB*/) :
+AddPatterns(_config->FindVector("APT::FTPArchive::Release::Patterns"));
+ 
+time_t const now = time(NULL);
+-   auto const posix = std::locale("C.UTF-8");
++   auto const posix = std::locale::classic();
+ 
+// FIXME: use TimeRFC1123 here? But that uses GMT to satisfy HTTP/1.1
+std::ostringstream datestr;
+-- 
+2.20.1
+
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138238): 
https://lists.openembedded.org/g/openembedded-core/message/138238
Mute This Topic: https://lists.openembedded.org/mt/74192539/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/2] libva: upgrade 2.6.1 -> 2.7.1

2020-05-13 Thread Richard Purdie

On Wed, 2020-05-13 at 01:14 +, Naveen Saini wrote:
> Ping

Needs rebasing against master please as there were other libva changes
recently.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138237): 
https://lists.openembedded.org/g/openembedded-core/message/138237
Mute This Topic: https://lists.openembedded.org/mt/74070041/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] file: Remove unneccessary override of PACKAGECONFIG for native

2020-05-13 Thread Richard Purdie

On Wed, 2020-05-13 at 12:30 -0700, Andre McCurdy wrote:
> Yes. Unfortunately making recipes robust for users who want to change
> PACKAGECONFIG values doesn't seem to be a high priority for oe-core.
> Why else would default PACKAGECONFIG values be assigned with ??=
> instead of ?= other than as a trap for new users?

I'm not sure I understand that, equally I'm tired so I'll assume I'm
just missing something.

I will say that there is no intention to make OE-Core hard to use or
not robust, its only as good a the people contributing make it. In this
case I'm not sure I understand/see the problem.

If we should be using ?= instead of ??= then I'm open to an explanation
why and patches to improve things.

Unfortunately we do have quite some legacy and ??= vs ?= has been
troublesome in the many different contexts we have (recipe, class,
conf, inc and so on).

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138236): 
https://lists.openembedded.org/g/openembedded-core/message/138236
Mute This Topic: https://lists.openembedded.org/mt/74169167/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH] apt: Remove workarounds for host gcc < 5

2020-05-13 Thread Adrian Bunk

On Wed, May 13, 2020 at 05:30:13PM +0100, Richard Purdie wrote:
> On Tue, 2020-05-12 at 23:37 +0300, Adrian Bunk wrote:
> > Signed-off-by: Adrian Bunk 
> > ---
> >  .../recipes-devtools/apt/apt-native_1.2.31.bb |  4 +-
> >  ...nging-the-global-LC_TIME-for-Release.patch | 80 ---
> >  ...caled-std-put_time-instead-rolling-o.patch | 46 ---
> >  ...ntrib-strutl.cc-Include-array-header.patch | 33 
> >  4 files changed, 1 insertion(+), 162 deletions(-)
> >  delete mode 100644 
> > meta/recipes-devtools/apt/apt/gcc_4.x_Revert-avoid-changing-the-global-LC_TIME-for-Release.patch
> >  delete mode 100644 
> > meta/recipes-devtools/apt/apt/gcc_4.x_Revert-use-de-localed-std-put_time-instead-rolling-o.patch
> >  delete mode 100644 
> > meta/recipes-devtools/apt/apt/gcc_4.x_apt-pkg-contrib-strutl.cc-Include-array-header.patch
> > 
> > diff --git a/meta/recipes-devtools/apt/apt-native_1.2.31.bb 
> > b/meta/recipes-devtools/apt/apt-native_1.2.31.bb
> > index 5b16b503d5..2952c21017 100644
> > --- a/meta/recipes-devtools/apt/apt-native_1.2.31.bb
> > +++ b/meta/recipes-devtools/apt/apt-native_1.2.31.bb
> > @@ -2,6 +2,4 @@ require apt-native.inc
> >  
> >  SRC_URI += "file://noconfigure.patch \
> >  file://no-curl.patch \
> > -
> > file://gcc_4.x_apt-pkg-contrib-strutl.cc-Include-array-header.patch \
> > -
> > file://gcc_4.x_Revert-avoid-changing-the-global-LC_TIME-for-Release.patch \
> > -
> > file://gcc_4.x_Revert-use-de-localed-std-put_time-instead-rolling-o.patch"
> > +"
> 
> I think part of this is causing:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/1892
> 
> ?
>...

I cannot reproduce it, but I can see what is likely causing it.
Patch will come in a few minutes.

> Cheers,
> 
> Richard

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138235): 
https://lists.openembedded.org/g/openembedded-core/message/138235
Mute This Topic: https://lists.openembedded.org/mt/74167843/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] file: Remove unneccessary override of PACKAGECONFIG for native

2020-05-13 Thread Andre McCurdy

On Wed, May 13, 2020 at 10:14 AM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: Andre McCurdy 
> > Sent: den 13 maj 2020 00:20
> > To: Peter Kjellerstedt 
> > Cc: OE Core mailing list 
> > Subject: Re: [OE-core] [PATCH] file: Remove unneccessary override of
> > PACKAGECONFIG for native
> >
> > On Tue, May 12, 2020 at 2:43 PM Peter Kjellerstedt
> >  wrote:
> > >
> > > There is no reason to set PACKAGECONFIG_class-native to the same value
> > > as the default PACKAGECONFIG.
> >
> > End users often don't know how to safely change PACKAGECONFIG from a
> > .bbappend and might try PACKAGECONFIG += "foo" or PACKAGECONFIG_append
> > = " foo" without realising that it could affect more than just the
> > target build.
> >
> > Have an explicit PACKAGECONFIG_class-native keeps the native config
> > stable for users who haven't yet learning through experience that the
> > safe way to change PACKAGECONFIG is PACKAGECONFIG_append_class-target
> > = " foo".
> >
> > So although this PACKAGECONFIG_class-native may seem redundant to the
> > experts, it helps make OE more robust for regular users.
>
> I have to disagree with this. Having just PACKAGECONFIG ??= "zlib"
> makes for a more consistent behavior between the different classes.

I don't see why a consistent configuration between the different
classes is a goal. We should instead try to keep them independent so
that changes to one don't accidentally affect the others. The
configuration for the target is determined by the functionality
required in the final image (ie something determined by the user) and
the configuration for native and nativesdk is mostly determined by the
requirements of the build environment. The requirements for the build
environment are fairly static and not something a typical user would
want to mess with.

> E.g., if someone would add a .bbappend with PACKAGECONFIG = "zlib
> bz2", with the current recipe the behavior would be different when
> building file and nativesdk-file compared to file-native (or actually
> file-replacement-native as file-native is in ASSUME_PROVIDED). With
> only the default PACKAGECONFIG, the result would be the same also
> for file-native.

Having an over-ride for native but not considering nativesdk is
certainly an issue which seems to affect many recipes in oe-core. But
the fix should be adding an over-ride for nativesdk rather than
removing the over-ride for native.

(I don't know why this problem doesn't come up more often. Perhaps
because while there are users who like to change PACKAGECONFIG values
and users who build for nativesdk the overlap between them is actually
quite small?).

> A quick grep through OE-Core also seems to agree with me. There are
> a couple of other recipes that sets PACKAGECONFIG_class- defaults,
> but then it's due to the default for, e.g., native being different
> from target. The only other recipe I could find that sets multiple
> identical PACKAGECONFIG defaults is openssl.

Yes. Unfortunately making recipes robust for users who want to change
PACKAGECONFIG values doesn't seem to be a high priority for oe-core.
Why else would default PACKAGECONFIG values be assigned with ??=
instead of ?= other than as a trap for new users?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138234): 
https://lists.openembedded.org/g/openembedded-core/message/138234
Mute This Topic: https://lists.openembedded.org/mt/74169167/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

2020-05-13 Thread Rahul Kumar

Hi Trevor,

It will be really helpful to me.But I don't have a Fedora system with me.
I have only Ubuntu System.

I am available on #oe IRC Channels.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rah...@mvista.com



On Wed, May 13, 2020 at 7:58 PM Trevor Gamblin 
wrote:

>
> On 5/12/20 7:22 PM, Randy MacLeod wrote:
> > On 2020-05-12 12:58 a.m., Rahul Kumar wrote:
> >> Hi,
> >>
> >> Can any one please help me to figure out how to deal with the GPLv3+
> >> issue.
> >>
> >> you can see my Patch at below link
> >> https://patchwork.openembedded.org/patch/172134/
> >>
> >> *Issue:*
> >> the new license (GPLv3) causes problems:
> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814
> >> *
> >> *
> >
> > Hi Rahul,
> >
> > I'm having some email problems with the oe-core list so apologies
> > if this is redundant.
> >
> > What happens if you split the license info into two parts like:
> >
> > $ grep "^LICENSE" recipes-extended/libvirt/libvirt_6.1.0.bb
> > LICENSE = "LGPLv2.1+ & GPLv2+"
> > LICENSE_${PN}-ptest = "GPLv2+ & LGPLv2.1+"
> > except of course with GPLv3.
> >
> > I might try that tomorrow on our local instance of the YP autobuilder.
> > If you'd like to set one up @ mvista, I hear from Trevor that it doesn't
> > take all that much time. As others have explained, you can also dig
> > through the yocto-autobuilder2/yocto-autobuilder-helper git repos.
>
> Hi Rahul, I can definitely help you get an autobuilder instance running
> locally, if you'd like. At the moment I'd suggest doing so on a host
> that's running Fedora, as that's where I've had the most success
> (Richard has explained to me how they run it on Ubuntu, but I haven't
> gotten it fully functional there yet).
>
> Are you on either the #yocto and/or #oe IRC channels?
>
> >
> > ../Randy
> >
> >> Thanks & Regards,
> >> Rahul Kumar
> >> Software Engineer,Linux Solutions Engineering
> >> Group,Montavista Software LLC
> >> Email Id: rah...@mvista.com 
> >> 
> >>
> >>
> >> On Wed, May 6, 2020 at 4:47 PM Rahul Kumar via lists.openembedded.org
> >> 
> >>  >> > wrote:
> >>
> >> Hi Randy,
> >>
> >> As per your suggestion I did some progress.
> >>
> >> Issue 1:
> >> 
> >>
> >> Configuration for this issue:
> >> =
> >>MACHINE = "edgerouter"
> >>DISTRO = "poky"
> >>SDKMACHINE = "i686"
> >>PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
> >>INHERIT += 'image-buildinfo'
> >>IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'
> >>QEMU_USE_KVM = 'True'
> >>INHERIT += 'report-error'
> >>PREMIRRORS = ''
> >>BB_GENERATE_MIRROR_TARBALLS = '1'
> >>BB_NUMBER_THREADS = '16'
> >>PARALLEL_MAKE = '-j 16'
> >>BB_TASK_NICE_LEVEL = '5'
> >>BB_TASK_NICE_LEVEL_task-testimage = '0'
> >>BB_TASK_IONICE_LEVEL = '2.7'
> >>BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
> >>INHERIT += 'testimage'
> >>TEST_QEMUBOOT_TIMEOUT = '1500'
> >>SANITY_TESTED_DISTROS = ''
> >>SDK_EXT_TYPE = 'minimal'
> >>SDK_INCLUDE_TOOLCHAIN = '1'
> >> Command:
> >> 
> >> bitbake core-image-sato core-image-sato-dev core-image-sato-sdk
> >> core-image-minimal core-image-minimal-dev core-image-sato-ptest
> >> core-image-sato:do_populate_sdk -k
> >>
> >> but could not reproduce the issue.
> >>
> >> work-around to reproduce this issue.
> >> 
> >> I am observing since bzip2-tests is a git repo and
> >> fsmonitor-watchman.sample (.git/hooks/fsmonitor-watchman.sample) is
> >> perl script.
> >> that's why I got this error.
> >>   so manually I copied fsmonitor-watchman.sample file into the
> >> bzip2-tests/.git/hooks and able to reproduce the issue.
> >> Error:
> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
> >> step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
> >> /usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample
> >> contained
> >> in package bzip2-ptest requires /usr/bin/perl, but no providers
> >> found in RDEPENDS_bzip2-ptest? [file-rdeps]
> >> step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal
> >> errors. Please consider fixing them.
> >>
> >> I find out the solution by appending RDEPENDS_${PN}-ptest with perl.
> >> RDEPENDS_${PN}-ptest += "make bash perl"
> >>
> >> so this issue got resolved.
> >>
> >> Issue2:
> >> ===
> >> Configuration for this issue
> >> 
> >>MACHINE = "qemux86"
> >>DISTRO = "poky"
> >>SDKMACHINE = "i686"
> >>

Re: [OE-core] [PATCH] file: Remove unneccessary override of PACKAGECONFIG for native

2020-05-13 Thread Peter Kjellerstedt

> -Original Message-
> From: Andre McCurdy 
> Sent: den 13 maj 2020 00:20
> To: Peter Kjellerstedt 
> Cc: OE Core mailing list 
> Subject: Re: [OE-core] [PATCH] file: Remove unneccessary override of
> PACKAGECONFIG for native
> 
> On Tue, May 12, 2020 at 2:43 PM Peter Kjellerstedt
>  wrote:
> >
> > There is no reason to set PACKAGECONFIG_class-native to the same value
> > as the default PACKAGECONFIG.
> 
> End users often don't know how to safely change PACKAGECONFIG from a
> .bbappend and might try PACKAGECONFIG += "foo" or PACKAGECONFIG_append
> = " foo" without realising that it could affect more than just the
> target build.
> 
> Have an explicit PACKAGECONFIG_class-native keeps the native config
> stable for users who haven't yet learning through experience that the
> safe way to change PACKAGECONFIG is PACKAGECONFIG_append_class-target
> = " foo".
> 
> So although this PACKAGECONFIG_class-native may seem redundant to the
> experts, it helps make OE more robust for regular users.

I have to disagree with this. Having just PACKAGECONFIG ??= "zlib" 
makes for a more consistent behavior between the different classes. 
E.g., if someone would add a .bbappend with PACKAGECONFIG = "zlib 
bz2", with the current recipe the behavior would be different when 
building file and nativesdk-file compared to file-native (or actually 
file-replacement-native as file-native is in ASSUME_PROVIDED). With 
only the default PACKAGECONFIG, the result would be the same also 
for file-native. 

A quick grep through OE-Core also seems to agree with me. There are 
a couple of other recipes that sets PACKAGECONFIG_class- defaults, 
but then it's due to the default for, e.g., native being different 
from target. The only other recipe I could find that sets multiple 
identical PACKAGECONFIG defaults is openssl.

//Peter

> > Signed-off-by: Peter Kjellerstedt 
> > ---
> >  meta/recipes-devtools/file/file_5.38.bb | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/file/file_5.38.bb 
> > b/meta/recipes-devtools/file/file_5.38.bb
> > index f5ad568936..007db4790d 100644
> > --- a/meta/recipes-devtools/file/file_5.38.bb
> > +++ b/meta/recipes-devtools/file/file_5.38.bb
> > @@ -19,7 +19,6 @@ S = "${WORKDIR}/git"
> >  inherit autotools update-alternatives
> >
> >  PACKAGECONFIG ??= "zlib"
> > -PACKAGECONFIG_class-native ??= "zlib"
> >  PACKAGECONFIG[bz2] = "--enable-bzlib, --disable-bzlib, bzip2"
> >  PACKAGECONFIG[lzma] = "--enable-xzlib, --disable-xzlib, xz"
> >  PACKAGECONFIG[zlib] = "--enable-zlib, --disable-zlib, zlib"
> > --
> > 2.21.3
> >
> > 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138232): 
https://lists.openembedded.org/g/openembedded-core/message/138232
Mute This Topic: https://lists.openembedded.org/mt/74169167/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH] apt: Remove workarounds for host gcc < 5

2020-05-13 Thread Richard Purdie

On Tue, 2020-05-12 at 23:37 +0300, Adrian Bunk wrote:
> Signed-off-by: Adrian Bunk 
> ---
>  .../recipes-devtools/apt/apt-native_1.2.31.bb |  4 +-
>  ...nging-the-global-LC_TIME-for-Release.patch | 80 ---
>  ...caled-std-put_time-instead-rolling-o.patch | 46 ---
>  ...ntrib-strutl.cc-Include-array-header.patch | 33 
>  4 files changed, 1 insertion(+), 162 deletions(-)
>  delete mode 100644 
> meta/recipes-devtools/apt/apt/gcc_4.x_Revert-avoid-changing-the-global-LC_TIME-for-Release.patch
>  delete mode 100644 
> meta/recipes-devtools/apt/apt/gcc_4.x_Revert-use-de-localed-std-put_time-instead-rolling-o.patch
>  delete mode 100644 
> meta/recipes-devtools/apt/apt/gcc_4.x_apt-pkg-contrib-strutl.cc-Include-array-header.patch
> 
> diff --git a/meta/recipes-devtools/apt/apt-native_1.2.31.bb 
> b/meta/recipes-devtools/apt/apt-native_1.2.31.bb
> index 5b16b503d5..2952c21017 100644
> --- a/meta/recipes-devtools/apt/apt-native_1.2.31.bb
> +++ b/meta/recipes-devtools/apt/apt-native_1.2.31.bb
> @@ -2,6 +2,4 @@ require apt-native.inc
>  
>  SRC_URI += "file://noconfigure.patch \
>  file://no-curl.patch \
> -
> file://gcc_4.x_apt-pkg-contrib-strutl.cc-Include-array-header.patch \
> -
> file://gcc_4.x_Revert-avoid-changing-the-global-LC_TIME-for-Release.patch \
> -
> file://gcc_4.x_Revert-use-de-localed-std-put_time-instead-rolling-o.patch"
> +"

I think part of this is causing:

https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/1892

?

(the selftests in that build run also saw it)

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138231): 
https://lists.openembedded.org/g/openembedded-core/message/138231
Mute This Topic: https://lists.openembedded.org/mt/74167843/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH v2] wic: Add --offset argument for partitions

2020-05-13 Thread Richard Purdie

On Mon, 2020-05-11 at 14:48 -0500, Joshua Watt wrote:
> Add support for an --offset argument when defining a partition. Many
> SoCs require that boot partitions be located at specific offsets.
> Prior
> to this argument, most WKS files were using the --align attribute to
> specify the location of these fixed partitions but this is not ideal
> because in the event that the partition couldn't be placed in the
> specified location, wic would move it to the next sector with that
> alignment, often preventing the device from booting. Unlike the --
> align
> argument, wic will fail if a partition cannot be placed at the exact
> offset specified with --offset.
> 
> Changes in V2:
> * Fixed a small typo that prevented test_fixed_size_error from
> passing

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/934

(and the other selftests failed too)

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138230): 
https://lists.openembedded.org/g/openembedded-core/message/138230
Mute This Topic: https://lists.openembedded.org/mt/74144197/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2] sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors

2020-05-13 Thread Mark Hatle

From: Mark Hatle 

Prior to fetching, the system checks if the sstate file is present
either locally or on the mirror.  If it is, then it goes to the fetch
stage.  Up to three files can be fetched, sstate, sstate.siginfo and
sstate.sig (if signature validation is enabled).

The previous pstaging_fetch function would iterate over these, and if
a download error occurred would spew forth a great amount of fetcher
failure messages as well as stop fetching the next item in the set.

This was resolved by adding a fetcher.checkstatus() call prior to
the download.  If the file isn't present, then the exception will
be triggered, and no fetcher failure messages will reach the user.

The exception handler is then modified to be a pass so that it will
loop and pull the rest of the files that that are requested.

Additionally, a check for the existance of the .sig file was added
to the sstate_installpkg to avoid an error trying to load the .sig
if it wasn't downloaded.

Signed-off-by: Mark Hatle 
Signed-off-by: Mark Hatle 
---

v2 - fix a typo in the error message about signature not being
 present.

 meta/classes/sstate.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index aa9c30b4e1..375196ef21 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -355,6 +355,9 @@ def sstate_installpkg(ss, d):
 d.setVar('SSTATE_INSTDIR', sstateinst)
 
 if bb.utils.to_boolean(d.getVar("SSTATE_VERIFY_SIG"), False):
+if not os.path.isfile(sstatepkg + '.sig'):
+bb.warn("No signature file for sstate package %s, skipping 
acceleration..." % sstatepkg)
+return False
 signer = get_signer(d, 'local')
 if not signer.verify(sstatepkg + '.sig'):
 bb.warn("Cannot verify signature on sstate package %s, skipping 
acceleration..." % sstatepkg)
@@ -733,10 +736,11 @@ def pstaging_fetch(sstatefetch, d):
 localdata.setVar('SRC_URI', srcuri)
 try:
 fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
+fetcher.checkstatus()
 fetcher.download()
 
 except bb.fetch2.BBFetchException:
-break
+pass
 
 def sstate_setscene(d):
 shared_state = sstate_state_fromvars(d)
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138229): 
https://lists.openembedded.org/g/openembedded-core/message/138229
Mute This Topic: https://lists.openembedded.org/mt/74185410/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [zeus][ 1/2] sstatesig: Optimise get_taskhash for hashequiv

2020-05-13 Thread Mark Hatle

From: Richard Purdie 

With hashequiv the get_taskhash function is called much more regularly
and contains expensive operations. This these don't change based upon
hash in a given build, improve the caching within the function to
reduce overhead.

(From OE-Core rev: de98cfe3cde4b8d5f4b163b5fba3f129651ef06a)

Signed-off-by: Richard Purdie 
Signed-off-by: Mark Hatle 
---
 meta/lib/oe/sstatesig.py | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index b2316b12b8..f1abff0c45 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -151,6 +151,13 @@ class SignatureGeneratorOEBasicHashMixIn(object):
 
 def get_taskhash(self, tid, deps, dataCache):
 h = super(bb.siggen.SignatureGeneratorBasicHash, 
self).get_taskhash(tid, deps, dataCache)
+if tid in self.lockedhashes:
+if self.lockedhashes[tid]:
+return self.lockedhashes[tid]
+else:
+return h
+
+h = super(bb.siggen.SignatureGeneratorBasicHash, 
self).get_taskhash(tid, deps, dataCache)
 
 (mc, _, task, fn) = bb.runqueue.split_tid_mcfn(tid)
 
@@ -187,17 +194,19 @@ class SignatureGeneratorOEBasicHashMixIn(object):
   % (recipename, task, h, h_locked, 
var))
 
 return h_locked
+
+self.lockedhashes[tid] = False
 #bb.warn("%s %s %s" % (recipename, task, h))
 return h
 
 def get_unihash(self, tid):
-if tid in self.lockedhashes:
+if tid in self.lockedhashes and self.lockedhashes[tid]:
 return self.lockedhashes[tid]
 return super().get_unihash(tid)
 
 def dump_sigtask(self, fn, task, stampbase, runtime):
 tid = fn + ":" + task
-if tid in self.lockedhashes:
+if tid in self.lockedhashes and self.lockedhashes[tid]:
 return
 super(bb.siggen.SignatureGeneratorBasicHash, self).dump_sigtask(fn, 
task, stampbase, runtime)
 
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138227): 
https://lists.openembedded.org/g/openembedded-core/message/138227
Mute This Topic: https://lists.openembedded.org/mt/74184220/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [zeus][ 0/2] Fix for two issues related to sstate-cache

2020-05-13 Thread Mark Hatle

Patch 1 is a backport from master (it's already in Dunfell).  If you have a
locked-sigs file, and the sstate for that item isn't available the .siginfo and
sigdata files were not being written.  Patch 1/2 resolved that with the
fragment in "dump_sigtask".

Patch 2 was sent for master as well, and this is just to get it applied to
Zeus.  Due to problem #1, we were generating sstate-cache that did not have
siginfo files.  Due to this we were getting failures later on using that
sstate-cache in a subsequent build.  This patch ensures if this happens
again (of if someone intentionally strips those) it won't fail.

Mark Hatle (1):
  sstate.bbclass: When siginfo or sig files are missing, stop fetcher
errors

Richard Purdie (1):
  sstatesig: Optimise get_taskhash for hashequiv

 meta/classes/sstate.bbclass |  6 +-
 meta/lib/oe/sstatesig.py| 13 +++--
 2 files changed, 16 insertions(+), 3 deletions(-)

-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138226): 
https://lists.openembedded.org/g/openembedded-core/message/138226
Mute This Topic: https://lists.openembedded.org/mt/74184219/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [zeus][ 2/2] sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors

2020-05-13 Thread Mark Hatle

From: Mark Hatle 

Prior to fetching, the system checks if the sstate file is present
either locally or on the mirror.  If it is, then it goes to the fetch
stage.  Up to three files can be fetched, sstate, sstate.siginfo and
sstate.sig (if signature validation is enabled).

The previous pstaging_fetch function would iterate over these, and if
a download error occurred would spew forth a great amount of fetcher
failure messages as well as stop fetching the next item in the set.

This was resolved by adding a fetcher.checkstatus() call prior to
the download.  If the file isn't present, then the exception will
be triggered, and no fetcher failure messages will reach the user.

The exception handler is then modified to be a pass so that it will
loop and pull the rest of the files that that are requested.

Additionally, a check for the existance of the .sig file was added
to the sstate_installpkg to avoid an error trying to load the .sig
if it wasn't downloaded.

Signed-off-by: Mark Hatle 
---
 meta/classes/sstate.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index c0329cd5d1..3528908727 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -333,6 +333,9 @@ def sstate_installpkg(ss, d):
 d.setVar('SSTATE_INSTDIR', sstateinst)
 
 if bb.utils.to_boolean(d.getVar("SSTATE_VERIFY_SIG"), False):
+if not os.path.isfile(sstatepkg + '.sig'):
+bb.warn("Not signature file for sstate package %s, skipping 
acceleration..." % sstatepkg)
+return False
 signer = get_signer(d, 'local')
 if not signer.verify(sstatepkg + '.sig'):
 bb.warn("Cannot verify signature on sstate package %s, skipping 
acceleration..." % sstatepkg)
@@ -703,10 +706,11 @@ def pstaging_fetch(sstatefetch, d):
 localdata.setVar('SRC_URI', srcuri)
 try:
 fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
+fetcher.checkstatus()
 fetcher.download()
 
 except bb.fetch2.BBFetchException:
-break
+pass
 
 def sstate_setscene(d):
 shared_state = sstate_state_fromvars(d)
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138228): 
https://lists.openembedded.org/g/openembedded-core/message/138228
Mute This Topic: https://lists.openembedded.org/mt/74184221/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] sstate.bbclass: When siginfo or sig files are missing, stop fetcher errors

2020-05-13 Thread Mark Hatle

From: Mark Hatle 

Prior to fetching, the system checks if the sstate file is present
either locally or on the mirror.  If it is, then it goes to the fetch
stage.  Up to three files can be fetched, sstate, sstate.siginfo and
sstate.sig (if signature validation is enabled).

The previous pstaging_fetch function would iterate over these, and if
a download error occurred would spew forth a great amount of fetcher
failure messages as well as stop fetching the next item in the set.

This was resolved by adding a fetcher.checkstatus() call prior to
the download.  If the file isn't present, then the exception will
be triggered, and no fetcher failure messages will reach the user.

The exception handler is then modified to be a pass so that it will
loop and pull the rest of the files that that are requested.

Additionally, a check for the existance of the .sig file was added
to the sstate_installpkg to avoid an error trying to load the .sig
if it wasn't downloaded.

Signed-off-by: Mark Hatle 
Signed-off-by: Mark Hatle 
---
 meta/classes/sstate.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index aa9c30b4e1..da8d5e78f4 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -355,6 +355,9 @@ def sstate_installpkg(ss, d):
 d.setVar('SSTATE_INSTDIR', sstateinst)
 
 if bb.utils.to_boolean(d.getVar("SSTATE_VERIFY_SIG"), False):
+if not os.path.isfile(sstatepkg + '.sig'):
+bb.warn("Not signature file for sstate package %s, skipping 
acceleration..." % sstatepkg)
+return False
 signer = get_signer(d, 'local')
 if not signer.verify(sstatepkg + '.sig'):
 bb.warn("Cannot verify signature on sstate package %s, skipping 
acceleration..." % sstatepkg)
@@ -733,10 +736,11 @@ def pstaging_fetch(sstatefetch, d):
 localdata.setVar('SRC_URI', srcuri)
 try:
 fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
+fetcher.checkstatus()
 fetcher.download()
 
 except bb.fetch2.BBFetchException:
-break
+pass
 
 def sstate_setscene(d):
 shared_state = sstate_state_fromvars(d)
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138225): 
https://lists.openembedded.org/g/openembedded-core/message/138225
Mute This Topic: https://lists.openembedded.org/mt/74184073/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for kernel/reproducibility: use specified environment settings

2020-05-13 Thread Patchwork

== Series Details ==

Series: kernel/reproducibility: use specified environment settings
Revision: 1
URL   : https://patchwork.openembedded.org/series/24133/
State : failure

== Summary ==


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



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



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

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138224): 
https://lists.openembedded.org/g/openembedded-core/message/138224
Mute This Topic: https://lists.openembedded.org/mt/74183633/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] kernel/reproducibility: use specified environment settings

2020-05-13 Thread Bruce Ashfield

From: Bruce Ashfield 

The routine to get the timestamp of the kernel commits should
specify LC_ALL to ensure consistent behaviour. We were making
a copy of the env, adding the setting .. and then not using it
on the call.

We specifiy the env in the subprocess call to ensure the
variable is available.

Signed-off-by: Bruce Ashfield 
---

This is the incremental patch to my previous series. Squash as required!

Bruce

 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f31084948f..3ac91fbd4f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -164,7 +164,7 @@ def get_kernel_source_date_epoch(d):
 
 env = os.environ.copy()
 env['LC_ALL'] = 'C'
-ts = subprocess.check_output(['date', '-d @%s' % s_d_e]).decode('utf-8')
+ts = subprocess.check_output(['date', '-d @%s' % s_d_e], 
env=env).decode('utf-8')
 
 return ts
 
-- 
2.19.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138223): 
https://lists.openembedded.org/g/openembedded-core/message/138223
Mute This Topic: https://lists.openembedded.org/mt/74182998/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

2020-05-13 Thread Trevor Gamblin



On 5/12/20 7:22 PM, Randy MacLeod wrote:

On 2020-05-12 12:58 a.m., Rahul Kumar wrote:

Hi,

Can any one please help me to figure out how to deal with the GPLv3+ 
issue.


you can see my Patch at below link
https://patchwork.openembedded.org/patch/172134/

*Issue:*
the new license (GPLv3) causes problems:
https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1814
*
*


Hi Rahul,

I'm having some email problems with the oe-core list so apologies
if this is redundant.

What happens if you split the license info into two parts like:

$ grep "^LICENSE" recipes-extended/libvirt/libvirt_6.1.0.bb
LICENSE = "LGPLv2.1+ & GPLv2+"
LICENSE_${PN}-ptest = "GPLv2+ & LGPLv2.1+"
except of course with GPLv3.

I might try that tomorrow on our local instance of the YP autobuilder.
If you'd like to set one up @ mvista, I hear from Trevor that it doesn't
take all that much time. As others have explained, you can also dig
through the yocto-autobuilder2/yocto-autobuilder-helper git repos.


Hi Rahul, I can definitely help you get an autobuilder instance running 
locally, if you'd like. At the moment I'd suggest doing so on a host 
that's running Fedora, as that's where I've had the most success 
(Richard has explained to me how they run it on Ubuntu, but I haven't 
gotten it fully functional there yet).


Are you on either the #yocto and/or #oe IRC channels?



../Randy


Thanks & Regards,
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rah...@mvista.com 



On Wed, May 6, 2020 at 4:47 PM Rahul Kumar via lists.openembedded.org 
 
> wrote:


    Hi Randy,

    As per your suggestion I did some progress.

    Issue 1:
    

    Configuration for this issue:
    =
   MACHINE = "edgerouter"
   DISTRO = "poky"
   SDKMACHINE = "i686"
   PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
   INHERIT += 'image-buildinfo'
   IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'
   QEMU_USE_KVM = 'True'
   INHERIT += 'report-error'
   PREMIRRORS = ''
   BB_GENERATE_MIRROR_TARBALLS = '1'
   BB_NUMBER_THREADS = '16'
   PARALLEL_MAKE = '-j 16'
   BB_TASK_NICE_LEVEL = '5'
   BB_TASK_NICE_LEVEL_task-testimage = '0'
   BB_TASK_IONICE_LEVEL = '2.7'
   BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
   INHERIT += 'testimage'
   TEST_QEMUBOOT_TIMEOUT = '1500'
   SANITY_TESTED_DISTROS = ''
   SDK_EXT_TYPE = 'minimal'
   SDK_INCLUDE_TOOLCHAIN = '1'
    Command:
    
    bitbake core-image-sato core-image-sato-dev core-image-sato-sdk
    core-image-minimal core-image-minimal-dev core-image-sato-ptest
    core-image-sato:do_populate_sdk -k

    but could not reproduce the issue.

    work-around to reproduce this issue.
    
    I am observing since bzip2-tests is a git repo and
    fsmonitor-watchman.sample (.git/hooks/fsmonitor-watchman.sample) is
    perl script.
    that's why I got this error.
  so manually I copied fsmonitor-watchman.sample file into the
    bzip2-tests/.git/hooks and able to reproduce the issue.
    Error:
https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/1816
    step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA Issue:
/usr/lib/bzip2/ptest/bzip2-tests/.git/hooks/fsmonitor-watchman.sample 
contained

    in package bzip2-ptest requires /usr/bin/perl, but no providers
    found in RDEPENDS_bzip2-ptest? [file-rdeps]
    step1b: ERROR: bzip2-1.0.8-r0 do_package_qa: QA run found fatal
    errors. Please consider fixing them.

    I find out the solution by appending RDEPENDS_${PN}-ptest with perl.
    RDEPENDS_${PN}-ptest += "make bash perl"

    so this issue got resolved.

    Issue2:
    ===
    Configuration for this issue
    
   MACHINE = "qemux86"
   DISTRO = "poky"
   SDKMACHINE = "i686"
   PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
   INCOMPATIBLE_LICENSE = '*GPLv3'
   WARN_QA_remove = 'incompatible-license'
   QEMU_USE_KVM = 'True'
   INHERIT += 'report-error'
   PREMIRRORS = ''
   BB_GENERATE_MIRROR_TARBALLS = '1'
   BB_NUMBER_THREADS = '16'
   PARALLEL_MAKE = '-j 16'
   BB_TASK_NICE_LEVEL = '5'
   BB_TASK_NICE_LEVEL_task-testimage = '0'
   BB_TASK_IONICE_LEVEL = '2.7'
   BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
   INHERIT += 'testimage'
   TEST_QEMUBOOT_TIMEOUT = '1500'
   SANITY_TESTED_DISTROS = ''
   SDK_EXT_TYPE = 'minimal'
   SDK_INCLUDE_TOOLCHAIN = '1'
    Command
    ===
    bitbake core-image-minimal core-image-full-cmdline -k


    INCOMPATIBLE_LICENSE = '*GPLv3'
    WARN_QA_remove = 'incompatible-license'
    My doubt is since above configuration is using during build and we
    are using

[OE-core][dunfell][PATCH] git: Upgrade 2.24.1 -> 2.24.3

2020-05-13 Thread Adrian Bunk

This includes the fixes for CVE-2020-5260 and CVE-2020-11008.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-devtools/git/git_2.24.1.bb | 11 ---
 meta/recipes-devtools/git/git_2.24.3.bb |  9 +
 2 files changed, 9 insertions(+), 11 deletions(-)
 delete mode 100644 meta/recipes-devtools/git/git_2.24.1.bb
 create mode 100644 meta/recipes-devtools/git/git_2.24.3.bb

diff --git a/meta/recipes-devtools/git/git_2.24.1.bb 
b/meta/recipes-devtools/git/git_2.24.1.bb
deleted file mode 100644
index daea31eab2..00
--- a/meta/recipes-devtools/git/git_2.24.1.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require git.inc
-
-EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
- 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
- "
-EXTRA_OEMAKE += "NO_GETTEXT=1"
-
-SRC_URI[tarball.md5sum] = "166bde96adbbc11c8843d4f8f4f9811b"
-SRC_URI[tarball.sha256sum] = 
"ad5334956301c86841eb1e5b1bb20884a6bad89a10a6762c958220c7cf64da02"
-SRC_URI[manpages.md5sum] = "31c2272a8979022497ba3d4202df145d"
-SRC_URI[manpages.sha256sum] = 
"9a7ae3a093bea39770eb96ca3e5b40bff7af0b9f6123f089d7821d0e5b8e1230"
diff --git a/meta/recipes-devtools/git/git_2.24.3.bb 
b/meta/recipes-devtools/git/git_2.24.3.bb
new file mode 100644
index 00..ddd875f07b
--- /dev/null
+++ b/meta/recipes-devtools/git/git_2.24.3.bb
@@ -0,0 +1,9 @@
+require git.inc
+
+EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
+ 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
+ "
+EXTRA_OEMAKE += "NO_GETTEXT=1"
+
+SRC_URI[tarball.sha256sum] = 
"ef6d1d1de1d7921a54d23d07479bd2766f050d6435cea5d3b5322aa4897cb3d7"
+SRC_URI[manpages.sha256sum] = 
"325795ba33c0be02370de79636f32ad3b447665c1f2b5b4de65181fa804bed31"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138219): 
https://lists.openembedded.org/g/openembedded-core/message/138219
Mute This Topic: https://lists.openembedded.org/mt/74182793/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 4/4] kernel/reproducibility: factor kernel source epoch for common use

2020-05-13 Thread Bruce Ashfield

On Wed, May 13, 2020 at 10:24 AM  wrote:
>
> From: Bruce Ashfield 
>
> Rather than duplicating the code to generate the kbuild environment
> variable: KBUILD_BUILD_TIMESTAMP, we can factor the checks into a
> python function and call it from the main image and kernel module
> do_compile routines.
>
> All paths have been checked and the timestamp is identical to the
> previous shell variant.
>
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/classes/kernel.bbclass | 43 -
>  1 file changed, 19 insertions(+), 24 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index a3990aaf59..de63e1c0f6 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -153,6 +153,21 @@ python do_symlink_kernsrc () {
>  }
>  addtask symlink_kernsrc before do_configure after do_unpack
>
> +def get_kernel_source_date_epoch(d):
> +import subprocess
> +
> +s_d_e = d.getVar("SOURCE_DATE_EPOCH")
> +if not s_d_e:
> +s_d_e = subprocess.check_output(['git', '--git-dir=%s/.git' % 
> d.getVar('S'), 'log', '-1', '--pretty=%ct']).decode('utf-8')
> +if not s_d_e:
> +s_d_e = d.getVar("REPRODUCIBLE_TIMESTAMP_ROOTFS")
> +
> +env = os.environ.copy()
> +env['LC_ALL'] = 'C'

Hah.

Of course after my send, I see that I'm not actually *using* the env.
I'll do an incremental patch to use env while this sits on the list.

Bruce

> +ts = subprocess.check_output(['date', '-d @%s' % s_d_e]).decode('utf-8')
> +
> +return ts
> +
>  inherit kernel-arch deploy
>
>  PACKAGES_DYNAMIC += "^${KERNEL_PACKAGE_NAME}-module-.*"
> @@ -291,19 +306,9 @@ get_cc_option () {
>  kernel_do_compile() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
> if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
> -   # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH 
> may not
> -   # be set
> -   if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = 
> "0" ]; then
> -   # The source directory is not necessarily a git 
> repository, so we
> -   # specify the git-dir to ensure that git does not 
> query a
> -   # repository in any parent directory.
> -   SOURCE_DATE_EPOCH=`git --git-dir="${S}/.git" log -1 
> --pretty=%ct 2>/dev/null || echo "${REPRODUCIBLE_TIMESTAMP_ROOTFS}"`
> -   fi
> -
> -   ts=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH`
> -   export KBUILD_BUILD_TIMESTAMP="$ts"
> +   export KBUILD_BUILD_TIMESTAMP="${@ 
> get_kernel_source_date_epoch(d)}"
> export KCONFIG_NOTIMESTAMP=1
> -   bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
> +   bbnote "KBUILD_BUILD_TIMESTAMP: $KBUILD_BUILD_TIMESTAMP"
> fi
> # The $use_alternate_initrd is only set from
> # do_bundle_initramfs() This variable is specifically for the
> @@ -332,19 +337,9 @@ kernel_do_compile() {
>  do_compile_kernelmodules() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
> if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
> -   # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH 
> may not
> -   # be set
> -   if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = 
> "0" ]; then
> -   # The source directory is not necessarily a git 
> repository, so we
> -   # specify the git-dir to ensure that git does not 
> query a
> -   # repository in any parent directory.
> -   SOURCE_DATE_EPOCH=`git --git-dir="${S}/.git" log -1 
> --pretty=%ct 2>/dev/null || echo "${REPRODUCIBLE_TIMESTAMP_ROOTFS}"`
> -   fi
> -
> -   ts=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH`
> -   export KBUILD_BUILD_TIMESTAMP="$ts"
> +   export KBUILD_BUILD_TIMESTAMP="${@ 
> get_kernel_source_date_epoch(d)}"
> export KCONFIG_NOTIMESTAMP=1
> -   bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
> +   bbnote "KBUILD_BUILD_TIMESTAMP: $KBUILD_BUILD_TIMESTAMP"
> fi
> if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
> cc_extra=$(get_cc_option)
> --
> 2.19.1
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138221): 
https://lists.openembedded.org/g/openembedded-core/message/138221
Mute This Topic: https://lists.openembedded.org/mt/74182751/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][warrior][PATCH] git: Upgrade 2.20.1 -> 2.20.4

2020-05-13 Thread Adrian Bunk

This includes the fixes for CVE-2020-5260 and CVE-2020-11008.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-devtools/git/git_2.20.1.bb | 11 ---
 meta/recipes-devtools/git/git_2.20.4.bb | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)
 delete mode 100644 meta/recipes-devtools/git/git_2.20.1.bb
 create mode 100644 meta/recipes-devtools/git/git_2.20.4.bb

diff --git a/meta/recipes-devtools/git/git_2.20.1.bb 
b/meta/recipes-devtools/git/git_2.20.1.bb
deleted file mode 100644
index 877fb05e58..00
--- a/meta/recipes-devtools/git/git_2.20.1.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require git.inc
-
-EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
- 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
- "
-EXTRA_OEMAKE += "NO_GETTEXT=1"
-
-SRC_URI[tarball.md5sum] = "7a7769e5c957364ed0aed89e6e67c254"
-SRC_URI[tarball.sha256sum] = 
"edc3bc1495b69179ba4e272e97eff93334a20decb1d8db6ec3c19c16417738fd"
-SRC_URI[manpages.md5sum] = "78c6e54a61a167dab5e8ae07036293ab"
-SRC_URI[manpages.sha256sum] = 
"e9c123463abd05e142defe44a8060ce6e9853dfd8c83b2542e38b7deac4e6d4c"
diff --git a/meta/recipes-devtools/git/git_2.20.4.bb 
b/meta/recipes-devtools/git/git_2.20.4.bb
new file mode 100644
index 00..e44da452ad
--- /dev/null
+++ b/meta/recipes-devtools/git/git_2.20.4.bb
@@ -0,0 +1,11 @@
+require git.inc
+
+EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
+ 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
+ "
+EXTRA_OEMAKE += "NO_GETTEXT=1"
+
+SRC_URI[tarball.md5sum] = "6f524e37186a79848a716e2a91330868"
+SRC_URI[tarball.sha256sum] = 
"92719084d7648b69038ea617a3bc45ec74f60ed7eef753ae2ad84b6f0b268e9a"
+SRC_URI[manpages.md5sum] = "dceabcda244042a06ed4cabd754627a5"
+SRC_URI[manpages.sha256sum] = 
"72fdd1799756b1240921d10eb5c67de9a651b44d429ba7293929c9d5344ad3e0"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138220): 
https://lists.openembedded.org/g/openembedded-core/message/138220
Mute This Topic: https://lists.openembedded.org/mt/74182798/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 0/4] kernel/kernel-yocto: consolidated pull request

2020-05-13 Thread Bruce Ashfield

From: Bruce Ashfield 

Hi all,

This is a resend of the v5.4 stable bump to v5.4.38, plus a new -stable
bump to v5.4.40.

The extra changes to make these pass the AB tests are the kernel
reproducibility commits.

The issue we had on the last submission was that IKHEADERS was switched
to a module, and hence was failing reproducibility tests as we didn't
have the timestamp variables exported for the module build. It has
always been a problem, just one we hadn't hit.

I've left the fix as two commits on purpose, since the copy of the
reproducibility export fixes the problem, and is definitely safe for dunfell,
and the second commit is my effort to remove the duplication of logic and
create a common python routine they can call. I've used the techniques for
subprocess running that I've done in other kernel build elements, but if they
aren't the right ones to use, point me in the right direction.

All said, these are green on the AB and should be ok for master and
dunfell.

Cheers,

Bruce

The following changes since commit b5763b2f480a9b994103debf02f1d11a92c27238:

  bitbake: lib/bs4/testing.py: fix bs4 testing (2020-05-05 13:22:29 +0100)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (4):
  linux-yocto/5.4: update to v5.4.38
  linux-yocto/5.4: update to v5.4.40
  kernel/reproducibility: kernel modules need SOURCE_DATE_EPOCH export
  kernel/reproducibility: factor kernel source epoch for common use

 meta/classes/kernel.bbclass   | 34 ---
 .../linux/linux-yocto-rt_5.4.bb   |  6 ++--
 .../linux/linux-yocto-tiny_5.4.bb |  8 ++---
 meta/recipes-kernel/linux/linux-yocto_5.4.bb  | 22 ++--
 4 files changed, 40 insertions(+), 30 deletions(-)

-- 
2.19.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138214): 
https://lists.openembedded.org/g/openembedded-core/message/138214
Mute This Topic: https://lists.openembedded.org/mt/74182743/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 4/4] kernel/reproducibility: factor kernel source epoch for common use

2020-05-13 Thread Bruce Ashfield

From: Bruce Ashfield 

Rather than duplicating the code to generate the kbuild environment
variable: KBUILD_BUILD_TIMESTAMP, we can factor the checks into a
python function and call it from the main image and kernel module
do_compile routines.

All paths have been checked and the timestamp is identical to the
previous shell variant.

Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel.bbclass | 43 -
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a3990aaf59..de63e1c0f6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -153,6 +153,21 @@ python do_symlink_kernsrc () {
 }
 addtask symlink_kernsrc before do_configure after do_unpack
 
+def get_kernel_source_date_epoch(d):
+import subprocess
+
+s_d_e = d.getVar("SOURCE_DATE_EPOCH")
+if not s_d_e:
+s_d_e = subprocess.check_output(['git', '--git-dir=%s/.git' % 
d.getVar('S'), 'log', '-1', '--pretty=%ct']).decode('utf-8')
+if not s_d_e:
+s_d_e = d.getVar("REPRODUCIBLE_TIMESTAMP_ROOTFS")
+
+env = os.environ.copy()
+env['LC_ALL'] = 'C'
+ts = subprocess.check_output(['date', '-d @%s' % s_d_e]).decode('utf-8')
+
+return ts
+
 inherit kernel-arch deploy
 
 PACKAGES_DYNAMIC += "^${KERNEL_PACKAGE_NAME}-module-.*"
@@ -291,19 +306,9 @@ get_cc_option () {
 kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
-   # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may 
not
-   # be set
-   if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = 
"0" ]; then
-   # The source directory is not necessarily a git 
repository, so we
-   # specify the git-dir to ensure that git does not query 
a
-   # repository in any parent directory.
-   SOURCE_DATE_EPOCH=`git --git-dir="${S}/.git" log -1 
--pretty=%ct 2>/dev/null || echo "${REPRODUCIBLE_TIMESTAMP_ROOTFS}"`
-   fi
-
-   ts=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH`
-   export KBUILD_BUILD_TIMESTAMP="$ts"
+   export KBUILD_BUILD_TIMESTAMP="${@ 
get_kernel_source_date_epoch(d)}"
export KCONFIG_NOTIMESTAMP=1
-   bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
+   bbnote "KBUILD_BUILD_TIMESTAMP: $KBUILD_BUILD_TIMESTAMP"
fi
# The $use_alternate_initrd is only set from
# do_bundle_initramfs() This variable is specifically for the
@@ -332,19 +337,9 @@ kernel_do_compile() {
 do_compile_kernelmodules() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
-   # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may 
not
-   # be set
-   if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = 
"0" ]; then
-   # The source directory is not necessarily a git 
repository, so we
-   # specify the git-dir to ensure that git does not query 
a
-   # repository in any parent directory.
-   SOURCE_DATE_EPOCH=`git --git-dir="${S}/.git" log -1 
--pretty=%ct 2>/dev/null || echo "${REPRODUCIBLE_TIMESTAMP_ROOTFS}"`
-   fi
-
-   ts=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH`
-   export KBUILD_BUILD_TIMESTAMP="$ts"
+   export KBUILD_BUILD_TIMESTAMP="${@ 
get_kernel_source_date_epoch(d)}"
export KCONFIG_NOTIMESTAMP=1
-   bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
+   bbnote "KBUILD_BUILD_TIMESTAMP: $KBUILD_BUILD_TIMESTAMP"
fi
if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
cc_extra=$(get_cc_option)
-- 
2.19.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138218): 
https://lists.openembedded.org/g/openembedded-core/message/138218
Mute This Topic: https://lists.openembedded.org/mt/74182751/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/4] linux-yocto/5.4: update to v5.4.40

2020-05-13 Thread Bruce Ashfield

From: Bruce Ashfield 

Updating linux-yocto/5.4 to the latest korg -stable release that comprises
the following commits:

f015b86259a5 Linux 5.4.40
2852b559afdf PM / devfreq: Add missing locking while setting suspend_freq
8e054bd6dfc4 udp: document udp_rcv_segment special case for looped packets
2a03c23b2015 tools headers UAPI: Sync copy of arm64's asm/unistd.h with the 
kernel sources
f11664da13b9 Revert "drm/amd/display: setting the DIG_MODE to the correct 
value."
c365ff781540 mm/mremap: Add comment explaining the untagging behaviour of 
mremap()
8f30c3687f09 libbpf: Fix readelf output parsing for Fedora
88348bd1f696 cgroup, netclassid: remove double cond_resched
702d710ffd83 mac80211: add ieee80211_is_any_nullfunc()
468465fdef4d ACPI: PM: s2idle: Fix comment in acpi_s2idle_prepare_late()
da283f9be924 platform/x86: GPD pocket fan: Fix error message when 
temp-limits are out of range
03f235a5bd3a x86/kvm: fix a missing-prototypes "vmread_error"
85701f4768a1 ALSA: hda: Match both PCI ID and SSID for driver blacklist
b8b42c8dcf44 hexagon: define ioremap_uc
f31c9e904f1d hexagon: clean up ioremap
1bc508b2d16d mfd: intel-lpss: Use devm_ioremap_uc for MMIO
78b19f56b952 lib: devres: add a helper function for ioremap_uc
7a9b738c7511 Revert "software node: Simplify software_node_release() 
function"
b8bb9c3192f9 drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event
3fb4c93dc761 sctp: Fix SHUTDOWN CTSN Ack in the peer restart case
9da07c4aeaf7 drm/i915: Extend WaDisableDARBFClkGating to icl,ehl,tgl
d8e0b58fa471 net: systemport: suppress warnings on failed Rx SKB allocations
5c065ee4a07d net: bcmgenet: suppress warnings on failed Rx SKB allocations
fd2c9e605269 mac80211: sta_info: Add lockdep condition for RCU list usage
07fea3d3ef88 lib/mpi: Fix building for powerpc with clang
bacf98ee0003 tracing: Fix memory leaks in trace_events_hist.c
c46330d4dabf cifs: do not share tcons with DFS
84778248e013 scripts/config: allow colons in option strings for sed
b31e0bd4a97a cifs: protect updating server->dstaddr with a spinlock
0560b7c3ba48 ASoC: rsnd: Fix "status check failed" spam for multi-SSI
883d34cdefea ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent
15de2df38652 net: stmmac: Fix sub-second increment
8d5a1ddaa9bb net: stmmac: fix enabling socfpga's ptp_ref_clock
d3539ea43a37 wimax/i2400m: Fix potential urb refcnt leak
f0d6b056bc18 drm/amdgpu: Correctly initialize thermal controller for GPUs 
with Powerplay table v0 (e.g Hawaii)
a09ba140db2f remoteproc: qcom_q6v5_mss: fix a bug in q6v5_probe()
b2978c307696 ASoC: codecs: hdac_hdmi: Fix incorrect use of 
list_for_each_entry
f9c3a17786fd ASoC: rsnd: Fix HDMI channel mapping for multi-SSI mode
26500b980bf8 ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode
5087c7f4e7f2 usb: dwc3: gadget: Properly set maxpacket limit
ab182c06fc22 ASoC: topology: Fix endianness issue
ae975c8e1062 ASoC: sgtl5000: Fix VAG power-on handling
3ea62d49613b selftests/ipc: Fix test failure seen after initial test run
a5dec15686e9 ASoC: topology: Check return value of soc_tplg_dai_config
fd8f4a3be50b ASoC: topology: Check return value of pcm_new_ver
0d452c7e309c ASoC: topology: Check soc_tplg_add_route return value
76336d4fa881 ASoC: topology: Check return value of soc_tplg_*_create
db80b7cb17d9 ASoC: topology: Check return value of soc_tplg_create_tlv
04da88c86c2e drm/bridge: analogix_dp: Split bind() into probe() and real 
bind()
336c7260a788 vhost: vsock: kick send_pkt worker once device is started
592465e6a54b Linux 5.4.39
eeef0d9fd40d selinux: properly handle multiple messages in 
selinux_netlink_send()
1de07eb54ab7 arm64: vdso: Add -fasynchronous-unwind-tables to cflags
73162ca8156f dmaengine: dmatest: Fix process hang when reading 'wait' 
parameter
c753a12c88e8 dmaengine: dmatest: Fix iteration non-stop logic
d458565e3c02 nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl
779f155811eb nvme: prevent double free in nvme_alloc_ns() error handling
57165a241302 Fix use after free in get_tree_bdev()
c0be115eb22d ALSA: opti9xx: shut up gcc-10 range warning
3af9be5f5c66 i2c: aspeed: Avoid i2c interrupt status clear race condition.
501ecc8fc9e5 iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled 
system
ad228dd3 scsi: target/iblock: fix WRITE SAME zeroing
de59f2fbe6ca iommu/qcom: Fix local_base status check
205757f476e8 vfio/type1: Fix VA->PA translation for PFNMAP VMAs in 
vaddr_get_pfn()
08e90b299d4e vfio: avoid possible overflow in vfio_iommu_type1_pin_pages
44e2a98e2b58 i2c: iproc: generate stop event for slave writes
92c99197815d RDMA/cm: Fix an error check in cm_alloc_id_priv()
4c499dafdd63 RDMA/cm: Fix ordering of xa_alloc_cyclic() in ib_create_cm_id()
169b8b62717a RDMA/core: Fix

[OE-core] [PATCH 3/4] kernel/reproducibility: kernel modules need SOURCE_DATE_EPOCH export

2020-05-13 Thread Bruce Ashfield

From: Bruce Ashfield 

If CONFIG_IKHEADERS is set to =m, then reproducibility issues creep
into the modules build, since the variables we are setting for the
main kernel build are not present.

Since the source code must be available for a possibly git query
on the timestamp, there didn't seem to be an easy way to move the
environment variable setting to a common routine. As such, we
duplicate the block of code that exports the required variables for
reproducible builds. There is a maintenance risk to this, but any
issues should be easy enough to catch.

Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel.bbclass | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a724645466..a3990aaf59 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -331,6 +331,21 @@ kernel_do_compile() {
 
 do_compile_kernelmodules() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
+   if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
+   # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may 
not
+   # be set
+   if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = 
"0" ]; then
+   # The source directory is not necessarily a git 
repository, so we
+   # specify the git-dir to ensure that git does not query 
a
+   # repository in any parent directory.
+   SOURCE_DATE_EPOCH=`git --git-dir="${S}/.git" log -1 
--pretty=%ct 2>/dev/null || echo "${REPRODUCIBLE_TIMESTAMP_ROOTFS}"`
+   fi
+
+   ts=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH`
+   export KBUILD_BUILD_TIMESTAMP="$ts"
+   export KCONFIG_NOTIMESTAMP=1
+   bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
+   fi
if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
cc_extra=$(get_cc_option)
oe_runmake -C ${B} ${PARALLEL_MAKE} modules CC="${KERNEL_CC} 
$cc_extra " LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}
-- 
2.19.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138217): 
https://lists.openembedded.org/g/openembedded-core/message/138217
Mute This Topic: https://lists.openembedded.org/mt/74182746/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/4] linux-yocto/5.4: update to v5.4.38

2020-05-13 Thread Bruce Ashfield

From: Bruce Ashfield 

Updating linux-yocto/5.4 to the latest korg -stable release that comprises
the following commits:

9895e0ac338a Linux 5.4.38
5a54c69c4ef8 Revert "ASoC: meson: axg-card: fix codec-to-codec link setup"
527c60e8b7a8 Linux 5.4.37
4e7fb753e803 ASoC: stm32: spdifrx: fix regmap status check
4104faaeeda0 ASoC: soc-core: disable route checks for legacy devices
8c472abaedc7 ext4: check for non-zero journal inum in 
ext4_calculate_overhead
93af898b251f qed: Fix use after free in qed_chain_free
f1610480602a net: use indirect call wrappers for skb_copy_datagram_iter()
ec9cf8afcd64 Crypto: chelsio - Fixes a hang issue during driver registration
b0946b45b85a qed: Fix race condition between scheduling and destroying the 
slowpath workqueue
d15fc1470441 taprio: do not use BIT() in TCA_TAPRIO_ATTR_FLAG_* definitions
f37079e9ea83 hwmon: (jc42) Fix name to have no illegal characters
c7b6c51298bd blk-mq: Put driver tag in blk_mq_dispatch_rq_list() when no 
budget
3e9299c28fc5 ext4: convert BUG_ON's to WARN_ON's in mballoc.c
1e4281eba3ff ext4: increase wait time needed before reuse of deleted inode 
numbers
0fe3908e6abc ext4: use matching invalidatepage in ext4_writepage
1876e0e654b8 arm64: Delete the space separator in __emit_inst
a719f7bf5c88 mac80211: fix channel switch trigger from unknown mesh peer
9178430df3f7 net: stmmac: socfpga: Allow all RGMII modes
daafdf87b898 ALSA: hda: call runtime_allow() for all hda controllers
d9d4ea17d6d6 xen/xenbus: ensure xenbus_map_ring_valloc() returns proper 
grant status
8c627d4b15de objtool: Support Clang non-section symbols in ORC dump
820126d9a83d objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings
1cc2460dad82 scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKEN
62d350eb31d1 scsi: target: fix PR IN / READ FULL STATUS for FC
a323f69d00c6 ALSA: hda: Explicitly permit using autosuspend if runtime PM 
is supported
bd074af53cb6 ALSA: hda: Keep the controller initialization even if no 
codecs found
135e10232fb5 ALSA: hda: Release resources at error in delayed probe
535ed3f01564 xfs: fix partially uninitialized structure in 
xfs_reflink_remap_extent
ec6e5792d62d afs: Fix length of dump of bad YFSFetchStatus record
16976275b929 signal: check sig before setting info in kill_pid_usb_asyncio
f88761412b90 x86: hyperv: report value of misc_features
b5da1152f716 net: fec: set GPR bit on suspend by DT configuration.
316ad98983d9 libbpf: Initialize *nl_pid so gcc 10 is happy
3c9bbe7f44f6 bpf, x86: Fix encoding for lower 8-bit registers in BPF_STX 
BPF_B
ab6e8af64f39 xfs: clear PF_MEMALLOC before exiting xfsaild thread
e5329fcdc907 mm: shmem: disable interrupt when acquiring info->lock in 
userfaultfd_copy path
309a509dabd5 bpf, x86_32: Fix logic error in BPF_LDX zero-extension
d0b8695703f2 bpf, x86_32: Fix clobbering of dst for BPF_JSET
50c5d9146100 bpf, x86_32: Fix incorrect encoding in BPF_LDX zero-extension
ca3a2ca4cfa2 um: ensure `make ARCH=um mrproper` removes 
arch/$(SUBARCH)/include/generated/
9c5c94c5012c blk-iocost: Fix error on iocost_ioc_vrate_adj
b9c31556c37b PM: sleep: core: Switch back to async_schedule_dev()
36c436a8e46a netfilter: nat: fix error handling upon registering inet hook
9578a8c157b4 perf/core: fix parent pid/tid in task exit events
c04d01e918d8 sched/core: Fix reset-on-fork from RT with uclamp
040287785f42 net/mlx5: Fix failing fw tracer allocation on s390
a8b5611ffee3 s390/pci: do not set affinity for floating irqs
6cfb8c2ada58 cpumap: Avoid warning when CONFIG_DEBUG_PER_CPU_MAPS is enabled
05ae98547af9 ARM: dts: bcm283x: Disable dsi0 node
764a7d0a2756 PCI: Move Apex Edge TPU class quirk to fix BAR assignment
684dba87fdd7 PCI: Add ACS quirk for Zhaoxin Root/Downstream Ports
17d166e9535c PCI: Add Zhaoxin Vendor ID
d2481b5d1257 PCI: Unify ACS quirk desired vs provided checking
981fd6ad2a5a PCI: Make ACS quirk implementations more uniform
85a9e198f124 PCI: Add ACS quirk for Zhaoxin multi-function devices
d2b631a136e8 PCI: Avoid ASMedia XHCI USB PME# from D0 defect
246ff2a6f69e net/mlx5e: Get the latest values from counters in switchdev 
mode
2292e4049097 net/mlx5e: Don't trigger IRQ multiple times on XSK wakeup to 
avoid WQ overruns
b4284efb1e14 svcrdma: Fix leak of svc_rdma_recv_ctxt objects
53dbb934dd4f svcrdma: Fix trace point use-after-free race
ccd3b4bb9944 xfs: acquire superblock freeze protection on eofblocks scans
62f1cb491552 net/cxgb4: Check the return from t4_query_params properly
ce3460b90ed9 rxrpc: Fix DATA Tx to disable nofrag for UDP on AF_INET6 socket
6cdded333de6 i2c: altera: use proper variable to hold errno
db2426f86d44 bpf: Forbid XADD on spilled pointers for unprivileged users
f1317a4a2b9b nfsd: memory corruption in nfsd4_lock()
13b28f6b6778 drivers:

[OE-core] [PATCH] common-licenses: add "Unlicense" license file

2020-05-13 Thread Robert P. J. Day


Signed-off-by: Robert P. J. Day 

---

diff --git a/meta/files/common-licenses/Unlicense 
b/meta/files/common-licenses/Unlicense
new file mode 100644
index 00..68a49daad8
--- /dev/null
+++ b/meta/files/common-licenses/Unlicense
@@ -0,0 +1,24 @@
+This is free and unencumbered software released into the public domain.
+
+Anyone is free to copy, modify, publish, use, compile, sell, or
+distribute this software, either in source code form or as a compiled
+binary, for any purpose, commercial or non-commercial, and by any
+means.
+
+In jurisdictions that recognize copyright laws, the author or authors
+of this software dedicate any and all copyright interest in the
+software to the public domain. We make this dedication for the benefit
+of the public at large and to the detriment of our heirs and
+successors. We intend this dedication to be an overt act of
+relinquishment in perpetuity of all present and future rights to this
+software under copyright law.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.
+
+For more information, please refer to 

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138213): 
https://lists.openembedded.org/g/openembedded-core/message/138213
Mute This Topic: https://lists.openembedded.org/mt/74179047/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/6] fs-perms-persistent.txt: renamed from fs-perms-persistent-log.txt

2020-05-13 Thread Changqing Li

From: Changqing Li 

since we use one variable VOLATILE_DIR to control the volatile,
rename the filename to make it common

Signed-off-by: Changqing Li 
---
 .../{fs-perms-persistent-log.txt => fs-perms-persistent.txt}| 2 --
 1 file changed, 2 deletions(-)
 rename meta/files/{fs-perms-persistent-log.txt => fs-perms-persistent.txt} 
(95%)

diff --git a/meta/files/fs-perms-persistent-log.txt 
b/meta/files/fs-perms-persistent.txt
similarity index 95%
rename from meta/files/fs-perms-persistent-log.txt
rename to meta/files/fs-perms-persistent.txt
index 3a7cf3ab94..9ca9571e6e 100644
--- a/meta/files/fs-perms-persistent-log.txt
+++ b/meta/files/fs-perms-persistent.txt
@@ -47,7 +47,6 @@ ${oldincludedir}  0755rootroottrue0644
rootroot
 # Links
 ${localstatedir}/run   link/run
 ${localstatedir}/lock  link/run/lock
-${localstatedir}/tmp   linkvolatile/tmp
 
 /home  0755rootrootfalse - - -
 /srv   0755rootrootfalse - - -
@@ -57,7 +56,6 @@ ${localstatedir}/local0755rootroot
false - - -
 # Special permissions from base-files
 # Set 1777
 /tmp   01777   rootrootfalse - - -
-${localstatedir}/volatile/tmp  01777   rootrootfalse - - -
 
 # Set 0700
 ${ROOT_HOME}   0700rootrootfalse - - -
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138206): 
https://lists.openembedded.org/g/openembedded-core/message/138206
Mute This Topic: https://lists.openembedded.org/mt/74177897/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/6] base-files: respect VOLATILE_DIR

2020-05-13 Thread Changqing Li

From: Changqing Li 

respect VOLATILE_DIR to support persistent /var/tmp too

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

diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb 
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 94299431f6..0e06629bbd 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -29,7 +29,7 @@ S = "${WORKDIR}"
 INHIBIT_DEFAULT_DEPS = "1"
 
 docdir_append = "/${P}"
-dirs1777 = "/tmp ${localstatedir}/volatile/tmp"
+dirs1777 = "/tmp ${localstatedir}/${@'volatile/' if 
oe.types.boolean('${VOLATILE_DIR}') else ''}tmp"
 dirs2775 = ""
 dirs555 = "/sys /proc"
 dirs755 = "/boot /dev ${base_bindir} ${base_sbindir} ${base_libdir} \
@@ -42,7 +42,7 @@ dirs755 = "/boot /dev ${base_bindir} ${base_sbindir} 
${base_libdir} \
${localstatedir}/backups ${localstatedir}/lib \
${localstatedir}/lib/misc ${localstatedir}/spool \
${localstatedir}/volatile \
-   ${localstatedir}/${@'volatile/' if 
oe.types.boolean('${VOLATILE_LOG_DIR}') else ''}log \
+   ${localstatedir}/${@'volatile/' if 
oe.types.boolean('${VOLATILE_DIR}') else ''}log \
/home ${prefix}/src ${localstatedir}/local \
/media"
 
@@ -53,7 +53,8 @@ dirs755-lsb = "/srv  \
${prefix}/lib/locale"
 dirs2775-lsb = "/var/mail"
 
-volatiles = "${@'log' if oe.types.boolean('${VOLATILE_LOG_DIR}') else ''} tmp"
+volatiles = "${@'log' if oe.types.boolean('${VOLATILE_DIR}') else ''} \
+ ${@'tmp' if oe.types.boolean('${VOLATILE_DIR}') else ''}"
 conffiles = "${sysconfdir}/debian_version ${sysconfdir}/host.conf \
  ${sysconfdir}/issue /${sysconfdir}/issue.net \
  ${sysconfdir}/nsswitch.conf ${sysconfdir}/profile \
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138207): 
https://lists.openembedded.org/g/openembedded-core/message/138207
Mute This Topic: https://lists.openembedded.org/mt/74177898/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/6] bitbake.conf: rename VOLATILE_LOG_DIR to VOLATILE_DIR

2020-05-13 Thread Changqing Li

From: Changqing Li 

To support persistent /var/tmp, rename VOLATILE_LOG_DIR
to VOLATILE_DIR

Don't use VOLATILE_LOG_DIR/VOLATILE_TMP_DIR
to control it separately since it will make things complicated,
we need to make kinds of fs-perms*.txt for kinds of combination
of the two variables.

Signed-off-by: Changqing Li 
---
 meta/conf/bitbake.conf | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index bdade79abe..8fd688c793 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -86,9 +86,11 @@ USRBINPATH_class-nativesdk = "/usr/bin"
 # Root home directory
 ROOT_HOME ??= "/home/root"
 
-# If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log links to 
/var/volatile/log.
-# If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is on 
persistent storage.
-VOLATILE_LOG_DIR ?= "yes"
+# If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log links to
+# /var/volatile/log, /var/tmp links to /var/volatile/tmp
+# If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log and /var/tmp
+# is on persistent storage.
+VOLATILE_DIR ?= "yes"
 
 ##
 # Architecture-dependent build variables.
@@ -350,7 +352,7 @@ FILESEXTRAPATHS ?= "__default:"
 #  datadir, sysconfdir, servicedir, sharedstatedir, localstatedir, infodir,
 #  mandir, docdir, bindir, sbindir, libexecdir, libdir, includedir and
 #  oldincludedir
-FILESYSTEM_PERMS_TABLES ?= "${@'files/fs-perms.txt' if 
oe.types.boolean(d.getVar('VOLATILE_LOG_DIR')) else 
'files/fs-perms-persistent-log.txt'}"
+FILESYSTEM_PERMS_TABLES ?= "${@'files/fs-perms.txt' if 
oe.types.boolean(d.getVar('VOLATILE_DIR')) else 
'files/fs-perms-persistent.txt'}"
 
 ##
 # General work and output directories for the build system.
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138208): 
https://lists.openembedded.org/g/openembedded-core/message/138208
Mute This Topic: https://lists.openembedded.org/mt/74177900/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 6/6] eudev: respect VOLATILE_DIR

2020-05-13 Thread Changqing Li

From: Changqing Li 

respect VOLATILE_DIR to support persistent /var/tmp too

Signed-off-by: Changqing Li 
---
 meta/recipes-core/udev/eudev_3.2.9.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-core/udev/eudev_3.2.9.bb 
b/meta/recipes-core/udev/eudev_3.2.9.bb
index f96f8cbe78..fc9a73cf8f 100644
--- a/meta/recipes-core/udev/eudev_3.2.9.bb
+++ b/meta/recipes-core/udev/eudev_3.2.9.bb
@@ -41,6 +41,9 @@ do_install_append() {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
sed -i s%@UDEVD@%${base_sbindir}/udevd% ${D}${sysconfdir}/init.d/udev
+if [ ${@ oe.types.boolean('${VOLATILE_DIR}') } = False ]; then
+sed -i -e 's%mkdir -m 1777 -p /var/volatile/tmp%mkdir -m 1777 -p 
/var/tmp%g' ${D}${sysconfdir}/init.d/udev
+fi
 
install -d ${D}${sysconfdir}/udev/rules.d
install -m 0644 ${WORKDIR}/local.rules 
${D}${sysconfdir}/udev/rules.d/local.rules
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138211): 
https://lists.openembedded.org/g/openembedded-core/message/138211
Mute This Topic: https://lists.openembedded.org/mt/74177904/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 4/6] initscripts: respect VOLATILE_DIR

2020-05-13 Thread Changqing Li

From: Changqing Li 

respect VOLATILE_DIR to support persistent /var/tmp too

Signed-off-by: Changqing Li 
---
 meta/recipes-core/initscripts/initscripts-1.0/volatiles | 3 ---
 meta/recipes-core/initscripts/initscripts_1.0.bb| 8 +++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/initscripts/initscripts-1.0/volatiles 
b/meta/recipes-core/initscripts/initscripts-1.0/volatiles
index cd8a4be05f..eeeb8905da 100644
--- a/meta/recipes-core/initscripts/initscripts-1.0/volatiles
+++ b/meta/recipes-core/initscripts/initscripts-1.0/volatiles
@@ -24,11 +24,8 @@
 # a link will be created at /var/test pointing to /tmp/testfile and due to this
 # link the file defined as /var/test will actually be created as /tmp/testfile.
 d root root 1777 /run/lock none
-d root root 0755 /var/volatile/log none
-d root root 1777 /var/volatile/tmp none
 l root root 1777 /var/lock /run/lock
 l root root 0755 /var/run /run
-l root root 1777 /var/tmp /var/volatile/tmp
 l root root 1777 /tmp /var/tmp
 d root root 0755 /var/lock/subsys none
 f root root 0664 /var/log/wtmp none
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb 
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 1a59b82fbf..ba6dc068c9 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -104,8 +104,14 @@ do_install () {
install -m 0755${WORKDIR}/read-only-rootfs-hook.sh 
${D}${sysconfdir}/init.d
install -m 0755${WORKDIR}/save-rtc.sh   ${D}${sysconfdir}/init.d
install -m 0644${WORKDIR}/volatiles 
${D}${sysconfdir}/default/volatiles/00_core
-   if [ ${@ oe.types.boolean('${VOLATILE_LOG_DIR}') } = True ]; then
+   if [ ${@ oe.types.boolean('${VOLATILE_DIR}') } = True ]; then
+   echo "d root root 0755 /var/volatile/log none" >> 
${D}${sysconfdir}/default/volatiles/00_core
+   echo "d root root 1777 /var/volatile/tmp none" >> 
${D}${sysconfdir}/default/volatiles/00_core
echo "l root root 0755 /var/log /var/volatile/log" >> 
${D}${sysconfdir}/default/volatiles/00_core
+   echo "l root root 0755 /var/tmp /var/volatile/tmp" >> 
${D}${sysconfdir}/default/volatiles/00_core
+   else
+   sed -i -e 
's;TMPROOT="${ROOT_DIR}/var/volatile/tmp";TMPROOT="${ROOT_DIR}/var/tmp";g' \
+${D}${sysconfdir}/init.d/populate-volatile.sh
fi
install -m 0755${WORKDIR}/dmesg.sh  ${D}${sysconfdir}/init.d
install -m 0644${WORKDIR}/logrotate-dmesg.conf ${D}${sysconfdir}/
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138212): 
https://lists.openembedded.org/g/openembedded-core/message/138212
Mute This Topic: https://lists.openembedded.org/mt/74177905/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 5/6] systemd: respect VOLATILE_DIR

2020-05-13 Thread Changqing Li

From: Changqing Li 

respect VOLATILE_DIR to support persistent /var/tmp too

Signed-off-by: Changqing Li 
---
 meta/recipes-core/systemd/systemd_245.5.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_245.5.bb 
b/meta/recipes-core/systemd/systemd_245.5.bb
index ece4220987..a2aed13f4a 100644
--- a/meta/recipes-core/systemd/systemd_245.5.bb
+++ b/meta/recipes-core/systemd/systemd_245.5.bb
@@ -230,7 +230,9 @@ do_install() {
install -d ${D}${sysconfdir}/tmpfiles.d
install -m 0644 ${WORKDIR}/*.rules ${D}${sysconfdir}/udev/rules.d/
 
-   install -m 0644 ${WORKDIR}/00-create-volatile.conf 
${D}${sysconfdir}/tmpfiles.d/
+   if [ ${@ oe.types.boolean('${VOLATILE_DIR}') } = True ]; then
+   install -m 0644 ${WORKDIR}/00-create-volatile.conf 
${D}${sysconfdir}/tmpfiles.d/
+   fi
 
if 
${@bb.utils.contains('DISTRO_FEATURES','sysvinit','true','false',d)}; then
install -d ${D}${sysconfdir}/init.d
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138210): 
https://lists.openembedded.org/g/openembedded-core/message/138210
Mute This Topic: https://lists.openembedded.org/mt/74177903/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 0/6] support persistent /var/tmp

2020-05-13 Thread Changqing Li

From: Changqing Li 

Changqing Li (6):
  bitbake.conf: rename VOLATILE_LOG_DIR to VOLATILE_DIR
  fs-perms-persistent.txt: renamed from fs-perms-persistent-log.txt
  base-files: respect VOLATILE_DIR
  initscripts: respect VOLATILE_DIR
  systemd: respect VOLATILE_DIR
  eudev: respect VOLATILE_DIR

 meta/conf/bitbake.conf | 10 ++
 ...erms-persistent-log.txt => fs-perms-persistent.txt} |  2 --
 meta/recipes-core/base-files/base-files_3.0.14.bb  |  7 ---
 .../recipes-core/initscripts/initscripts-1.0/volatiles |  3 ---
 meta/recipes-core/initscripts/initscripts_1.0.bb   |  8 +++-
 meta/recipes-core/systemd/systemd_245.5.bb |  4 +++-
 meta/recipes-core/udev/eudev_3.2.9.bb  |  3 +++
 7 files changed, 23 insertions(+), 14 deletions(-)
 rename meta/files/{fs-perms-persistent-log.txt => fs-perms-persistent.txt} 
(95%)

-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138209): 
https://lists.openembedded.org/g/openembedded-core/message/138209
Mute This Topic: https://lists.openembedded.org/mt/74177901/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] RFC wic: Support .wks files for multiple machines

2020-05-13 Thread Ricardo Ribalda

Hi

Even if it does not cover all the use cases. Can we consider this patch?

Thanks!

On Sat, Apr 25, 2020 at 11:29 PM Ricardo Ribalda Delgado
 wrote:
>
> Hi Christopher
>
> On Fri, Apr 24, 2020 at 5:56 PM Christopher Larson  wrote:
> >
> > This will only work the way you expect if hte user's local.conf uses ?= or 
> > ??= for MACHINE, otherwise setting it in the environment will do nothing.
> >
>
> Good catch, You are right :(,
>
> Any idea of how could I fix it. I think I would have to change
> site.conf, or local.conf from wic, and I do not want to do that.
>
> Ignoring this bug we are still covering a big number of usecases:
>
> - bibake
> - wic with user provided rootfs-dir
> - wic without userprovided rootfs-dir and ?= or ??=
>
> At the end of the day this is just a RFC ;), so i am open to any
> implementation. I would love to hear your thoughts
>
> Best regards
>
>
>
> > On Fri, Apr 24, 2020 at 6:30 AM Ricardo Ribalda  
> > wrote:
> >>
> >> If you want to make a disk image containing rootfs for different
> >> machines, the only way to do it today is by calling wic and passing the
> >> different rootfs-paths.
> >>
> >> Eg:
> >> combined.wks
> >> part /export --source rootfs --rootfs-dir=target-image
> >> part / --source rootfs
> >>
> >> bitbake multiconfig:arm:target-image
> >> wic create combined --rootfs-dir 
> >> target-image=/workdir/build/tmp/work/arm-poky-linux/target-image/1.0-r0/rootfs/
> >>  -e main
> >>
> >> This has many drawbacks:
> >> 1) You need to know the folder location for the target-image
> >> 2) It is easy to forget updating the target (only running wic and not
> >>bitbake)
> >> 3) It is slow
> >> 4) It does not scale when you have multiple machines
> >>
> >> Instead, wic can be given a hint of what machine to search for:
> >>
> >> combined.wks
> >> part /export --source rootfs --rootfs-dir=arm:target-image
> >> part / --source rootfs
> >>
> >> bitbake main
> >>
> >> If we ensoure the dependency of target-image from main via
> >> do_image[mcdepends], all the dependencies are automatically
> >> handled.
> >>
> >> This patch makes wic aware of the machine to use.
> >>
> >> Signed-off-by: Ricardo Ribalda Delgado 
> >> ---
> >>  scripts/lib/wic/misc.py | 16 +---
> >>  1 file changed, 13 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/scripts/lib/wic/misc.py b/scripts/lib/wic/misc.py
> >> index 91975ba151..51b43b49aa 100644
> >> --- a/scripts/lib/wic/misc.py
> >> +++ b/scripts/lib/wic/misc.py
> >> @@ -206,7 +206,12 @@ class BitbakeVars(defaultdict):
> >>
> >>  if image not in self:
> >>  if image and self.vars_dir:
> >> -fname = os.path.join(self.vars_dir, image + '.env')
> >> +if image.find(":") != -1:
> >> +[machine, img] = image.split(":")
> >> +fname = os.path.join(self.vars_dir, "../../",
> >> + machine, "imgdata", img + '.env')
> >> +else:
> >> +fname = os.path.join(self.vars_dir, image + '.env')
> >>  if os.path.isfile(fname):
> >>  # parse .env file
> >>  with open(fname) as varsfile:
> >> @@ -220,11 +225,16 @@ class BitbakeVars(defaultdict):
> >>  # Get bitbake -e output
> >>  cmd = "bitbake -e"
> >>  if image:
> >> -cmd += " %s" % image
> >> +if image.find(":") != -1:
> >> +[machine, img] = image.split(":")
> >> +cmd = "MACHINE=%s %s" % (machine, cmd)
> >> +else:
> >> +img = image
> >> +cmd += " %s" % img
> >>
> >>  log_level = logger.getEffectiveLevel()
> >>  logger.setLevel(logging.INFO)
> >> -ret, lines = _exec_cmd(cmd)
> >> +ret, lines = _exec_cmd(cmd, as_shell=True)
> >>  logger.setLevel(log_level)
> >>
> >>  if ret:
> >> --
> >> 2.26.1
> >>
> >> 
> >
> >
> >
> > --
> > Christopher Larson
> > kergoth at gmail dot com
> > Founder - BitBake, OpenEmbedded, OpenZaurus
> > Senior Software Engineer, Mentor Graphics
>
>
>
> --
> Ricardo Ribalda



-- 
Ricardo Ribalda
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138205): 
https://lists.openembedded.org/g/openembedded-core/message/138205
Mute This Topic: https://lists.openembedded.org/mt/73241116/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

44 matches

Mail list logo