[OE-core] [PATCH] linux-yocto-dev: Add paravirt_kvm support for qemux86-64

[zhe.he]

From: He Zhe 

This feature includes paravirtualized KVM guest support, including
KVMCLOCK for enhancing clock accuracy of guest OS. With it we can prevent
the following error.

"clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as
unstable because the skew is too large"

Signed-off-by: He Zhe 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index afda849..c364a97 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -48,7 +48,7 @@ KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/ta
 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
 KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc 
features/drm-bochs/drm-bochs.scc"
 KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
-KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
+KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " 
cfg/x32.scc", "" ,d)}"
 
 KERNEL_VERSION_SANITY_SKIP = "1"
-- 
2.7.4

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

Re: [OE-core] [OE-Core][PATCH] systemd: upgrade v244.1 -> v244.2

[Alexander Kanavin]

I think 244.3 is latest?

Alex

On Wed 12. Feb 2020 at 8.15, Alex Kiernan  wrote:

> Commits from v244-stable:
>
>   77c04ce5c270 hwdb: update to v245-rc1
>   b4eb8848240c Fix typo in function name
>   e2d4cb9843c5 polkit: when authorizing via PK let's re-resolve
> callback/userdata instead of caching it
>   83bfc0d8dd02 sd-bus: introduce API for re-enqueuing incoming messages
>   5926f9f1723f polkit: use structured initialization
>   0697d0d972c8 polkit: on async pk requests, re-validate action/details
>   2589995acdb2 polkit: reuse some common bus message appending code
>   5b2442d5c3ec bus-polkit: rename return error parameter to ret_error
>   0a19ff7004e4 shared: split out polkit stuff from bus-util.c →
> bus-polkit.c
>   1325dfb5778d test: adapt to the new capsh format
>   3538fafb4714 meson: update efi path detection to gnu-efi-3.0.11
>   3034855a5b62 presets: "disable" all passive targets by default
>   c2e304681929 shared/sysctl-util: normalize repeated slashes or dots to a
> single value
>   6f4364046f90 dhcp6: do not use T1 and T2 longer than one provided by the
> lease
>   0ed6cda28dff network: fix implicit type conversion warning by GCC-10
>   f6a5c02d26b1 bootspec: parse random-seed-mode line in loader.conf
>   ddc5dca8a73b sd-boot: fix typo
>   2bbbe9ae41ab test: Synchronize journal before reading from it
>   072485d661d7 sd-bus: fix introspection bug in signal parameter names
>   80af3cf5e36b efi: fix build.
>   d7ede1ade564 generator: order growfs for the root fs after
> systemd-remount-fs
>   e9904998213d loginctl: use /org/freedesktop/login1/session/auto when
> "lock-session" is called without argument
>   82dd4caf014c Documentation update for x-systemd.{before,after}
>   a60459764d9d man: fix typo in systemd.netdev Xfrm example
>   fc053e2dfb3f timesyncd: log louder when we refuse a server due to root
> distance
>   af0e630693fa resolved: drop DNSSEC root key that is not valid anymore
>   ae59f1666ca6 journal: don't use startswith() on something that is not a
> NUL-terminated string
>   536ef6d72bc6 test: add test for
> https://github.com/systemd/systemd/issues/14560
>   b78fe3c1b1a8 core: make sure StandardInput=file: doesn't get dup'ed to
> stdout/stderr by default
>   a1561a08f2d5 pkgconf: add full generator paths
>   e5f2d11489ec tree-wide: we forgot to destroy some bus errors
>   ea67fd42067b mount: make checks on perpetual mount units more lax
>   2f23c648bce4 core: never allow perpetual units to be masked
>   9ba11dffb09a typo: "May modify to" -> "May modify"
>   84c048799a78 Disable reading SystemdOptions EFI Var when in SecureBoot
> mode
>   4c2d72b53091 sysctl: downgrade message when we have no permission
>   c001a285a3a2 Clarify journald.conf MaxLevelStore documentation
>   45d52c7615fd logind: refuse overriding idle hint on tty sessions
>   b1a0be45b4ee cgroup: update only siblings that got realized once
>   e6d694254fe1 mount: mark an existing "mounting" unit from
> /proc/self/mountinfo as "just_mounted"
>   d8fd38769c36 journalctl: Correctly handle combination of --reverse and
> --lines (fixes #1596)
>   cd19bd31d808 journalctl: Correctly handle --show-cursor in combination
> with --until or --since and --reverse
>   1320aa92dc0a core: fix re-realization of cgroup siblings
>   14164ec6bc77 core: propagate service state to socket in more load states
>   c22bf6b31a45 man: describe "symlink" and "systemctl link" explicitly in
> UNIT FILE LOAD PATH
>   26f3a534f1ab core: be more restrictive on the dependency types we allow
> to be created transiently
>   377cc5d91ea5 udev: don't import parent ID_FS_ data on partitions
>   7d5060d53994 man: fix option name
>   98c03090274a Support Plugable UD-PRO8 dock
>   e9687d09dccf gpt-auto: don't assume XBOOTLDR is vfat
>   7057fe863007 man: fix documentation of IBM VIO device naming
>   f8d1df1045be man: slightly extend documentation on difference between
> ID_NET_NAME_ONBOARD and ID_NET_LABEL_ONBOARD
>   1faf5dde4d4a boot: fix osrel parser
>   65d247af1786 udev: do not use exact match of file permission
>   6da978f89b48 network: lower the log-level of harmless message
>   5d8a614f926c hwdb: ignore keys added in kernel 5.5
>   8b1bd1746989 systemctl: skip non-existent units in the 'cat' verb
>   b2f342f92b54 systemd.exec: document the file system for EnvironmentFile
> paths
>   945f3a231f6f systemd-analyze: fixed typo in documentation
>   2c8ae283b0ee test-condition: fix group check condition
>   6b48479f4582 umount: show correct error message
>   faba5b2ba8c9 Revert "Drop dbus activation stub service"
>   3dd98f1998f9 man: add section about user manager units
>   1c80a8ced006 man: add remote-*.targets to the bootup sequence
>   9afd65f15e93 time-util: also use 32bit hack on EOVERFLOW
>   561923291383 [man] note which UID ranges will get user journals
>   588a23ef2684 [man] fix URL
>   0130a03179f6 analyze: badness if neither of RootImage and RootDirectory
> exists
>   93074c962e3a network: introduce AddPrefixRoute= and deprecate
> PrefixR

[OE-core] [OE-Core][PATCH] systemd: upgrade v244.1 -> v244.2

[Alex Kiernan]

Commits from v244-stable:

  77c04ce5c270 hwdb: update to v245-rc1
  b4eb8848240c Fix typo in function name
  e2d4cb9843c5 polkit: when authorizing via PK let's re-resolve 
callback/userdata instead of caching it
  83bfc0d8dd02 sd-bus: introduce API for re-enqueuing incoming messages
  5926f9f1723f polkit: use structured initialization
  0697d0d972c8 polkit: on async pk requests, re-validate action/details
  2589995acdb2 polkit: reuse some common bus message appending code
  5b2442d5c3ec bus-polkit: rename return error parameter to ret_error
  0a19ff7004e4 shared: split out polkit stuff from bus-util.c → bus-polkit.c
  1325dfb5778d test: adapt to the new capsh format
  3538fafb4714 meson: update efi path detection to gnu-efi-3.0.11
  3034855a5b62 presets: "disable" all passive targets by default
  c2e304681929 shared/sysctl-util: normalize repeated slashes or dots to a 
single value
  6f4364046f90 dhcp6: do not use T1 and T2 longer than one provided by the lease
  0ed6cda28dff network: fix implicit type conversion warning by GCC-10
  f6a5c02d26b1 bootspec: parse random-seed-mode line in loader.conf
  ddc5dca8a73b sd-boot: fix typo
  2bbbe9ae41ab test: Synchronize journal before reading from it
  072485d661d7 sd-bus: fix introspection bug in signal parameter names
  80af3cf5e36b efi: fix build.
  d7ede1ade564 generator: order growfs for the root fs after systemd-remount-fs
  e9904998213d loginctl: use /org/freedesktop/login1/session/auto when 
"lock-session" is called without argument
  82dd4caf014c Documentation update for x-systemd.{before,after}
  a60459764d9d man: fix typo in systemd.netdev Xfrm example
  fc053e2dfb3f timesyncd: log louder when we refuse a server due to root 
distance
  af0e630693fa resolved: drop DNSSEC root key that is not valid anymore
  ae59f1666ca6 journal: don't use startswith() on something that is not a 
NUL-terminated string
  536ef6d72bc6 test: add test for 
https://github.com/systemd/systemd/issues/14560
  b78fe3c1b1a8 core: make sure StandardInput=file: doesn't get dup'ed to 
stdout/stderr by default
  a1561a08f2d5 pkgconf: add full generator paths
  e5f2d11489ec tree-wide: we forgot to destroy some bus errors
  ea67fd42067b mount: make checks on perpetual mount units more lax
  2f23c648bce4 core: never allow perpetual units to be masked
  9ba11dffb09a typo: "May modify to" -> "May modify"
  84c048799a78 Disable reading SystemdOptions EFI Var when in SecureBoot mode
  4c2d72b53091 sysctl: downgrade message when we have no permission
  c001a285a3a2 Clarify journald.conf MaxLevelStore documentation
  45d52c7615fd logind: refuse overriding idle hint on tty sessions
  b1a0be45b4ee cgroup: update only siblings that got realized once
  e6d694254fe1 mount: mark an existing "mounting" unit from 
/proc/self/mountinfo as "just_mounted"
  d8fd38769c36 journalctl: Correctly handle combination of --reverse and 
--lines (fixes #1596)
  cd19bd31d808 journalctl: Correctly handle --show-cursor in combination with 
--until or --since and --reverse
  1320aa92dc0a core: fix re-realization of cgroup siblings
  14164ec6bc77 core: propagate service state to socket in more load states
  c22bf6b31a45 man: describe "symlink" and "systemctl link" explicitly in UNIT 
FILE LOAD PATH
  26f3a534f1ab core: be more restrictive on the dependency types we allow to be 
created transiently
  377cc5d91ea5 udev: don't import parent ID_FS_ data on partitions
  7d5060d53994 man: fix option name
  98c03090274a Support Plugable UD-PRO8 dock
  e9687d09dccf gpt-auto: don't assume XBOOTLDR is vfat
  7057fe863007 man: fix documentation of IBM VIO device naming
  f8d1df1045be man: slightly extend documentation on difference between 
ID_NET_NAME_ONBOARD and ID_NET_LABEL_ONBOARD
  1faf5dde4d4a boot: fix osrel parser
  65d247af1786 udev: do not use exact match of file permission
  6da978f89b48 network: lower the log-level of harmless message
  5d8a614f926c hwdb: ignore keys added in kernel 5.5
  8b1bd1746989 systemctl: skip non-existent units in the 'cat' verb
  b2f342f92b54 systemd.exec: document the file system for EnvironmentFile paths
  945f3a231f6f systemd-analyze: fixed typo in documentation
  2c8ae283b0ee test-condition: fix group check condition
  6b48479f4582 umount: show correct error message
  faba5b2ba8c9 Revert "Drop dbus activation stub service"
  3dd98f1998f9 man: add section about user manager units
  1c80a8ced006 man: add remote-*.targets to the bootup sequence
  9afd65f15e93 time-util: also use 32bit hack on EOVERFLOW
  561923291383 [man] note which UID ranges will get user journals
  588a23ef2684 [man] fix URL
  0130a03179f6 analyze: badness if neither of RootImage and RootDirectory exists
  93074c962e3a network: introduce AddPrefixRoute= and deprecate PrefixRoute=
  a8ad020ea0ba shared/dropin: fix assert for invalid drop-in
  946cdba156dd initrd: make udev cleanup service confict trigger and settle too
  c0a8a92e6027 man: we support growing xfs too these days
  608d88273494 time-util: deal with systems wh

Re: [OE-core] [PATCH] dnf, libdnf: Ignore if PACKAGE_CLASSES does not have rpm

[Alexander Kanavin]

Please let’s try to avoid anonymous python. What problem does this solve?
If package_rpm is not enabled, then there should not be a dependency chain
that builds these anyway.

Alex

On Wed 12. Feb 2020 at 6.20, Khem Raj  wrote:

> dnf does not work with opkg or dpkg/apt anyway
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/dnf/dnf_4.2.2.bb| 8 
>  meta/recipes-devtools/libdnf/libdnf_0.28.1.bb | 7 +++
>  2 files changed, 15 insertions(+)
>
> diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> index f38167f1ad..9e6d5741af 100644
> --- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> +++ b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> @@ -84,3 +84,11 @@ SYSTEMD_SERVICE_${PN} = "dnf-makecache.service
> dnf-makecache.timer \
>   dnf-automatic-notifyonly.service
> dnf-automatic-notifyonly.timer \
>  "
>  SYSTEMD_AUTO_ENABLE ?= "disable"
> +
> +python () {
> +pkgb = d.getVar("PACKAGE_CLASSES")
> +pkgn = d.getVar("PN")
> +pkgv = d.getVar("PV")
> +if "package_rpm" not in pkgb:
> +raise bb.parse.SkipPackage("%s-%s Needs rpmdb support in libsolv"
> % (pkgn, pkgv))
> +}
> diff --git a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
> b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
> index 882c435b32..5c9326ca64 100644
> --- a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
> +++ b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
> @@ -27,3 +27,10 @@ EXTRA_OECMAKE_append_class-nativesdk = " -DWITH_GIR=OFF"
>
>  BBCLASSEXTEND = "native nativesdk"
>
> +python () {
> +pkgb = d.getVar("PACKAGE_CLASSES")
> +pkgn = d.getVar("PN")
> +pkgv = d.getVar("PV")
> +if "package_rpm" not in pkgb:
> +raise bb.parse.SkipPackage("%s-%s Needs rpmdb support in libsolv"
> % (pkgn, pkgv))
> +}
> --
> 2.25.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] python3: install _tkinter.*.so to python3-tkinter package

[Yi Zhao]

When enable PACKAGECONFIG[tk], we should install _tkinter.*.so to
python3-tkinter package rather than python3-misc package.

Fixes:
ERROR: python3-3.8.1-r0 do_package_qa: QA Issue:
/usr/lib/python3.8/lib-dynload/_tkinter.cpython-38-x86_64-linux-gnu.so
contained in package python3-misc requires libtk8.6.so()(64bit), but no
providers found in RDEPENDS_python3-misc? [file-rdeps]

Signed-off-by: Yi Zhao 
---
 meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index cbfa8d59d3..251271cb84 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -1127,6 +1127,7 @@
 "core"
 ],
 "files": [
+"${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_tkinter.*.so",
 "${libdir}/python${PYTHON_MAJMIN}/tkinter"
 ],
 "cached": []
-- 
2.17.1

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

[OE-core] [PATCH] dnf, libdnf: Ignore if PACKAGE_CLASSES does not have rpm

[Khem Raj]

dnf does not work with opkg or dpkg/apt anyway

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/dnf/dnf_4.2.2.bb| 8 
 meta/recipes-devtools/libdnf/libdnf_0.28.1.bb | 7 +++
 2 files changed, 15 insertions(+)

diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb 
b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
index f38167f1ad..9e6d5741af 100644
--- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
+++ b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
@@ -84,3 +84,11 @@ SYSTEMD_SERVICE_${PN} = "dnf-makecache.service 
dnf-makecache.timer \
  dnf-automatic-notifyonly.service 
dnf-automatic-notifyonly.timer \
 "
 SYSTEMD_AUTO_ENABLE ?= "disable"
+
+python () {
+pkgb = d.getVar("PACKAGE_CLASSES")
+pkgn = d.getVar("PN")
+pkgv = d.getVar("PV")
+if "package_rpm" not in pkgb:
+raise bb.parse.SkipPackage("%s-%s Needs rpmdb support in libsolv" % 
(pkgn, pkgv))
+}
diff --git a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb 
b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
index 882c435b32..5c9326ca64 100644
--- a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
+++ b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
@@ -27,3 +27,10 @@ EXTRA_OECMAKE_append_class-nativesdk = " -DWITH_GIR=OFF"
 
 BBCLASSEXTEND = "native nativesdk"
 
+python () {
+pkgb = d.getVar("PACKAGE_CLASSES")
+pkgn = d.getVar("PN")
+pkgv = d.getVar("PV")
+if "package_rpm" not in pkgb:
+raise bb.parse.SkipPackage("%s-%s Needs rpmdb support in libsolv" % 
(pkgn, pkgv))
+}
-- 
2.25.0

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

Re: [OE-core] [PATCH 0/4] oeqa: Run diffoscop on saved output

[akuster808]

On 2/11/20 7:14 PM, Joshua Watt wrote:
> Adds recipes to build the diffoscope tool and run it when the OEQA
> reproducible build test saves output to a local path. This should make
> it much easier to debug reproducible build issues from the autobuilder,
> since the published output can be easily viewed on the website.\

Thanks
>
> Joshua Watt (4):
>   python: Add libarchive-c recipe
>   python: Add magic recipe
>   recipes-support: Add diffoscope recipe
>   oeqa: reproducible: Run diffoscope on saved output
>
>  meta/conf/distro/include/maintainers.inc  |  3 +++
>  meta/lib/oeqa/selftest/cases/reproducible.py  | 24 +--
>  .../python/python3-libarchive-c_2.9.bb| 17 +
>  .../python/python3-magic_0.4.15.bb| 19 +++
>  .../diffoscope/diffoscope_136.bb  | 15 
>  5 files changed, 71 insertions(+), 7 deletions(-)
>  create mode 100644 meta/recipes-devtools/python/python3-libarchive-c_2.9.bb
>  create mode 100644 meta/recipes-devtools/python/python3-magic_0.4.15.bb
>  create mode 100644 meta/recipes-support/diffoscope/diffoscope_136.bb
>

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

[OE-core] [PATCH 3/4] recipes-support: Add diffoscope recipe

[Joshua Watt]

Diffoscope is the universal diff tool, capable of comparing many
different formats.

Signed-off-by: Joshua Watt 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 meta/recipes-support/diffoscope/diffoscope_136.bb | 15 +++
 2 files changed, 16 insertions(+)
 create mode 100644 meta/recipes-support/diffoscope/diffoscope_136.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 171a43615e3..4a267faabce 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -146,6 +146,7 @@ RECIPE_MAINTAINER_pn-dejagnu = "Nathan Rossi 
"
 RECIPE_MAINTAINER_pn-depmodwrapper-cross = "Mark Hatle 
"
 RECIPE_MAINTAINER_pn-desktop-file-utils = "Alexander Kanavin 
"
 RECIPE_MAINTAINER_pn-dhcp = "Hongxu Jia "
+RECIPE_MAINTAINER_pn-diffoscope = "Joshua Watt "
 RECIPE_MAINTAINER_pn-diffstat = "Chen Qi "
 RECIPE_MAINTAINER_pn-diffutils = "Chen Qi "
 RECIPE_MAINTAINER_pn-distcc = "Hongxu Jia "
diff --git a/meta/recipes-support/diffoscope/diffoscope_136.bb 
b/meta/recipes-support/diffoscope/diffoscope_136.bb
new file mode 100644
index 000..a00f281deb0
--- /dev/null
+++ b/meta/recipes-support/diffoscope/diffoscope_136.bb
@@ -0,0 +1,15 @@
+SUMMARY = "in-depth comparison of files, archives, and directories"
+HOMEPAGE = "https://diffoscope.org/";
+LICENSE = "GPL-3.0+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
+
+PYPI_PACKAGE = "diffoscope"
+
+inherit pypi setuptools3
+
+SRC_URI[md5sum] = "c84d8d308a40176ba2f5dc4abdbf6f73"
+SRC_URI[sha256sum] = 
"0d6486d6eb6e0445ba21fee2e8bdd3a366ce786bfac98e00e5a95038b7815f15"
+
+RDEPENDS_${PN} += "binutils vim squashfs-tools python3-libarchive-c 
python3-magic"
+
+BBCLASSEXTEND = "native"
-- 
2.23.0

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

[OE-core] [PATCH 4/4] oeqa: reproducible: Run diffoscope on saved output

[Joshua Watt]

If there are differing packages and they are being saved for review,
automatically run diffoscope on them and include the output in the saved
output. The output is currently done in HTML format since these are
typically published on a webpage by the autobuilder.

Signed-off-by: Joshua Watt 
---
 meta/lib/oeqa/selftest/cases/reproducible.py | 24 ++--
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py 
b/meta/lib/oeqa/selftest/cases/reproducible.py
index f6433c9a02b..d3fd8c392b8 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -1,7 +1,7 @@
 #
 # SPDX-License-Identifier: MIT
 #
-# Copyright 2019 by Garmin Ltd. or its subsidiaries
+# Copyright 2019-2020 by Garmin Ltd. or its subsidiaries
 
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars
@@ -167,10 +167,16 @@ class ReproducibleTests(OESelftestTestCase):
 return d
 
 def test_reproducible_builds(self):
+def strip_topdir(s):
+if s.startswith(self.topdir):
+return s[len(self.topdir):]
+return s
+
 # Build native utilities
 self.write_config('')
-bitbake("diffutils-native -c addto_recipe_sysroot")
+bitbake("diffoscope-native diffutils-native -c addto_recipe_sysroot")
 diffutils_sysroot = get_bb_var("RECIPE_SYSROOT_NATIVE", 
"diffutils-native")
+diffoscope_sysroot = get_bb_var("RECIPE_SYSROOT_NATIVE", 
"diffoscope-native")
 
 if self.save_results:
 os.makedirs(self.save_results, exist_ok=True)
@@ -206,18 +212,22 @@ class ReproducibleTests(OESelftestTestCase):
 
 if self.save_results:
 for d in result.different:
-self.copy_file(d.reference, '/'.join([save_dir, 
d.reference]))
-self.copy_file(d.test, '/'.join([save_dir, d.test]))
+self.copy_file(d.reference, '/'.join([save_dir, 
'packages', strip_topdir(d.reference)]))
+self.copy_file(d.test, '/'.join([save_dir, 'packages', 
strip_topdir(d.test)]))
 
 if result.missing or result.different:
 fails.append("The following %s packages are missing or 
different: %s" %
 (c, '\n'.join(r.test for r in (result.missing + 
result.different
 
-if fails:
-self.fail('\n'.join(fails))
-
 # Clean up empty directories
 if self.save_results:
 if not os.listdir(save_dir):
 os.rmdir(save_dir)
+else:
+self.logger.info('Running diffoscope')
+runCmd(['diffoscope', '--no-default-limits', 
'--exclude-directory-metadata', '--html-dir', 'diff-html', 'reproducibleA', 
'reproducibleB'],
+native_sysroot=diffoscope_sysroot, ignore_status=True, 
cwd=os.path.join(save_dir, 'packages'))
+
+if fails:
+self.fail('\n'.join(fails))
 
-- 
2.23.0

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

[OE-core] [PATCH 1/4] python: Add libarchive-c recipe

[Joshua Watt]

The libarchive python module is used by diffoscope tool to
make build comparisons.

Signed-off-by: Joshua Watt 
---
 meta/conf/distro/include/maintainers.inc|  1 +
 .../python/python3-libarchive-c_2.9.bb  | 17 +
 2 files changed, 18 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3-libarchive-c_2.9.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c68e9edf634..abbdb74a0d3 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -579,6 +579,7 @@ RECIPE_MAINTAINER_pn-python3-extras = "Oleksandr Kravchuk 
https://github.com/Changaco/python-libarchive-c";
+LICENSE = "CC0-1.0"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=bcab380227a83bc147350b40a81e6ffc"
+
+PYPI_PACKAGE = "libarchive-c"
+
+inherit pypi setuptools3
+
+SRC_URI[md5sum] = "083bd2cb0043c1e22a52cb9a05e31532"
+SRC_URI[sha256sum] = 
"9919344cec203f5db6596a29b5bc26b07ba9662925a05e24980b84709232ef60"
+
+RDEPENDS_${PN} += "libarchive"
+
+BBCLASSEXTEND = "native"
-- 
2.23.0

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

[OE-core] [PATCH 2/4] python: Add magic recipe

[Joshua Watt]

The python-magic module is used by diffoscope tool to make
build comparisons.

Signed-off-by: Joshua Watt 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../python/python3-magic_0.4.15.bb| 19 +++
 2 files changed, 20 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3-magic_0.4.15.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index abbdb74a0d3..171a43615e3 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -580,6 +580,7 @@ RECIPE_MAINTAINER_pn-python3-git = "Oleksandr Kravchuk 
http://github.com/ahupp/python-magic";
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=16a934f165e8c3245f241e77d401bb88"
+
+PYPI_PACKAGE = "python-magic"
+
+inherit pypi setuptools3
+
+SRC_URI[md5sum] = "e384c95a47218f66c6501cd6dd45ff59"
+SRC_URI[sha256sum] = 
"f3765c0f582d2dfc72c15f3b5a82aecfae9498bd29ca840d72f37d7bd38bfcd5"
+
+RDEPENDS_${PN} += "file"
+
+BBCLASSEXTEND = "native"
-- 
2.23.0

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

[OE-core] [PATCH 0/4] oeqa: Run diffoscop on saved output

[Joshua Watt]

Adds recipes to build the diffoscope tool and run it when the OEQA
reproducible build test saves output to a local path. This should make
it much easier to debug reproducible build issues from the autobuilder,
since the published output can be easily viewed on the website.

Joshua Watt (4):
  python: Add libarchive-c recipe
  python: Add magic recipe
  recipes-support: Add diffoscope recipe
  oeqa: reproducible: Run diffoscope on saved output

 meta/conf/distro/include/maintainers.inc  |  3 +++
 meta/lib/oeqa/selftest/cases/reproducible.py  | 24 +--
 .../python/python3-libarchive-c_2.9.bb| 17 +
 .../python/python3-magic_0.4.15.bb| 19 +++
 .../diffoscope/diffoscope_136.bb  | 15 
 5 files changed, 71 insertions(+), 7 deletions(-)
 create mode 100644 meta/recipes-devtools/python/python3-libarchive-c_2.9.bb
 create mode 100644 meta/recipes-devtools/python/python3-magic_0.4.15.bb
 create mode 100644 meta/recipes-support/diffoscope/diffoscope_136.bb

-- 
2.23.0

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

[OE-core] [PATCH] buildall-qemu: automate build testing for qemu MACHINEs

[Trevor Gamblin]

buildall-qemu simplifies the process of build testing an upgraded or
patched recipe by cycling through the build steps for each available qemu
target, with desired LIBC specified by the user as an option (defaulting
to both glibc and musl if no option is provided). While building, a log
file with the name "-buildall.log" is written, containing a PASS
or FAIL line upon completion of the build for each architecture. For now,
qemu targets are not selectable (i.e. the recipe is built for all qemu
targets found in meta/conf/machine), but this functionality can be added
in the future along with other useful options.

The log file created by buildall-qemu also includes some basic system
info (e.g. build start time, hostname, host OS, host kernel). Since it is
not guaranteed that tools such as lsb_release will be available on the
host (it isn't by default on my Fedora machine), this information is
collected manually. Additionally, the previous run's log is retained for
comparison by renaming it in the format -buildall.log.old once a
new set of builds is triggered for the same recipe.

Sample log output:

BUILDALL-QEMU LOG FOR aspell
START TIME: 2020-02-11_19:50:02
HOSTNAME: yow-tgamblin-fedora2
HOST OS: Fedora 31 (Server Edition)
HOST KERNEL: 5.4.10-200.fc31.x86_64
===
BUILD RESULTS:
[glibc]
PASS: qemuarmv5
PASS: qemux86
PASS: qemuppc
PASS: qemumips64
PASS: qemux86-64
PASS: qemumips
PASS: qemuarm
PASS: qemuarm64
PASS: qemuriscv64
[musl]
PASS: qemuarmv5
PASS: qemux86
PASS: qemuppc
PASS: qemumips64
PASS: qemux86-64
FAIL: qemumips
FAIL: qemuarm
FAIL: qemuarm64
FAIL: qemuriscv64
===
PASSED: 14
FAILED: 4

Signed-off-by: Trevor Gamblin 
---
 scripts/buildall-qemu | 120 ++
 1 file changed, 120 insertions(+)
 create mode 100755 scripts/buildall-qemu

diff --git a/scripts/buildall-qemu b/scripts/buildall-qemu
new file mode 100755
index 00..a5a626d2a2
--- /dev/null
+++ b/scripts/buildall-qemu
@@ -0,0 +1,120 @@
+#!/bin/sh
+#  Copyright (c) 2020 Wind River Systems, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# buildall-qemu: a tool for automating build testing of recipes
+# TODO: Add support for selecting which qemu architectures to build
+# TODO: Add support for queueing up multiple recipe builds
+# TODO: Add more logging options (e.g. local.conf info, bitbake env info)
+
+usage ()
+{
+base=$(basename "$0")
+echo "Usage: $base [options] [recipename/target]"
+echo "Executes a build of a given target for selected LIBCs. With no 
options, default to both libc and musl."
+echo "Options:"
+echo "-l, --libcSpecify one of \"libc\" or \"musl\""
+}
+
+
+buildall ()
+{
+# Get path to oe-core directory. Since oe-init-build-env prepends $PATH 
with
+# the path to the scripts directory, get it from there
+SCRIPTS_PATH="$(echo "$PATH" | cut -d ":" -f 1)"
+OE_CORE_PATH=$(echo "$SCRIPTS_PATH" | sed 's|\(.*\)/.*|\1|') 
+
+# Get target list and host machine information
+TARGET_LIST=$(find "$OE_CORE_PATH"/meta/conf/machine -maxdepth 1 -type f | 
grep qemu | sed 's|.*/||' | sed -e 's/\.conf//')
+
+# Set LIBC value to use for the builds based on options provided by the 
user
+if [ -n "$2" ]
+then
+   LIBC_LIST="$2"
+   echo "$LIBC_LIST"
+else
+   LIBC_LIST="glibc musl"
+   echo "$LIBC_LIST"
+fi
+
+START_TIME=$(date "+%Y-%m-%d_%H:%M:%S")
+LOG_FILE="$1-buildall.log"
+OS_INFO=$(grep "PRETTY_NAME=" /etc/os-release | awk -F "=" '{print $2}' | 
sed -e 's/^"//' -e 's/"$//')
+
+# Append an existing log file for this build with .old if one exists
+if [ -f "${LOG_FILE}" ] 
+then
+   mv "${LOG_FILE}" "${LOG_FILE}.old"
+else
+  touch "${LOG_FILE}"
+fi
+
+# Fill the log file with build and host info
+echo "BUILDALL-QEMU LOG FOR $1" >> "${LOG_FILE}"
+echo "START TIME: ${START_TIME}" >> "${LOG_FILE}"
+echo "HOSTNAME: $(uname -n)" >> "${LOG_FILE}"
+echo "HOST OS: ${OS_INFO}" >> "${LOG_FILE}"
+echo "HOST KERNEL: $(uname -r)" >> "${LOG_FILE}"
+echo "===" >> "${LOG_FILE}"
+echo "BUILD RESULTS:" >> "${LOG_FILE}"
+
+# start the builds for each MACHINE and TCLIBC
+for j in ${LIBC_LIST} 
+do
+   echo "[$j]" >> "${LOG_FILE}"
+   for i in ${TARGET_LIST} 
+   do
+   echo "$i" "$j"; \
+   TCLIBC=$j MACHINE=$i bitbake "$1" && echo "PASS: $i" >> 
"${LOG_FILE}" || echo "FAIL: $i" >> "${LOG_FILE}"
+   done
+done
+
+# Get pass/fail totals and add them to the end of the log
+PASSED=$(grep "PASS:" "${LOG_FILE}" | wc -l)
+FAILED=$(grep "FAIL:" "${LOG_FILE}" | wc -l)
+
+echo "===" >> "${LOG_FILE}"
+echo "PASSED: ${PASSED}" >> "${LOG_FILE}"
+echo "FAILED: ${FAILED}" >> "${LOG_FILE}"
+}
+
+
+# fail entire script if any command fails
+set -e
+
+# print usage and exit if not enough args given
+[ $# -eq 0 ] && usage && exit 1
+
+# handle arguments

[OE-core] [PATCH] libsolv: Enable rpm packageconfig by default only if rpm O_P_M is enabled

[Khem Raj]

opkg also depends on libsolv and can needlessly pull in rpm even if
the O_P_M does not desire to use rpm

Signed-off-by: Khem Raj 
---
 meta/recipes-extended/libsolv/libsolv_0.7.10.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/libsolv/libsolv_0.7.10.bb 
b/meta/recipes-extended/libsolv/libsolv_0.7.10.bb
index 502f4e0e85..265a27c00d 100644
--- a/meta/recipes-extended/libsolv/libsolv_0.7.10.bb
+++ b/meta/recipes-extended/libsolv/libsolv_0.7.10.bb
@@ -18,7 +18,7 @@ S = "${WORKDIR}/git"
 
 inherit cmake
 
-PACKAGECONFIG ??= "rpm"
+PACKAGECONFIG ??= 
"${@bb.utils.contains('PACKAGE_CLASSES','package_rpm','rpm','',d)}"
 PACKAGECONFIG[rpm] = "-DENABLE_RPMMD=ON -DENABLE_RPMDB=ON,,rpm"
 
 EXTRA_OECMAKE = "-DMULTI_SEMANTICS=ON -DENABLE_COMPLEX_DEPS=ON"
-- 
2.25.0

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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Alexander Kanavin]

On Tue, 11 Feb 2020 at 18:53, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

>
> I still strongly believe we need something in core which pulls together
> all our pieces into a UI where you can test key elements of what we
> build. If we don't have sato how do we actually test the core or demo
> it?
>

See my other email I just wrote; I think epiphany/webkit under weston is
able to replace sato more or less fully in this aspect, and actually do
more when it comes to modern embedded UI use cases which involve video and
3D.


> I think we shouldn't rush into things here. We should ramp up our
> wayland testing and make the wayland images more useful/comprehensive
> and then look at moving more of our tests from sato to the wayland
> images.
>

Certainly no rush here and this transition will proceed carefully and will
take years, but then I am famous for mercilessly removing things from
oe-core, and X with sato would be the biggest one yet! :)

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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Martin Jansa]

On Tue, Feb 11, 2020 at 05:53:38PM +, Richard Purdie wrote:
> I still strongly believe we need something in core which pulls together
> all our pieces into a UI where you can test key elements of what we
> build. If we don't have sato how do we actually test the core or demo
> it?
> 
> I think we shouldn't rush into things here. We should ramp up our
> wayland testing and make the wayland images more useful/comprehensive
> and then look at moving more of our tests from sato to the wayland
> images.
> 
> So in summary, yes, I think we do retarget our testing over time and
> strengthen when were testing under wayland. I probably don't see that
> needing to happen quite as quickly as you do though!

Agreed,

it might be nicer to have x11 separated in some meta-x11 layer and
meta-sato in another layer as well, but as long as there is no clear
replacement and x11 in oe-core doesn't cause too much work I think that
dropping x11 from DISTRO_FEATURES is working quite nicely for people
who don't care about x11 at all already.

Maybe it would make sense to remove x11 from default DISTRO_FEATURES
and/or include opengl+wayland instead?

Cheers,


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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Richard Purdie]

Hi Alex,

Thanks for bringing this up.

On Tue, 2020-02-11 at 13:49 +0100, Alexander Kanavin wrote:
> I'd like to lay out a few ideas/thoughts on what should be done with
> sato (matchbox bits) and X going forward. The inputs are:
> 
> - Red Hat is the only company doing X maintenance anymore, and
> they're transitioning it to 'hard maintenance mode'
> https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
> "Once we are done with this [xwayland gaining missing features] we
> expect X.org to go into hard maintenance mode fairly quickly. The
> reality is that X.org is basically maintained by us and thus once we
> stop paying attention to it there is unlikely to be any major new
> releases coming out and there might even be some bitrot setting in
> over time. We will keep an eye on it as we will want to ensure X.org
> stays supportable until the end of the RHEL8 lifecycle at a minimum,
> but let this be a friendly notice for everyone who rely the work we
> do maintaining the Linux graphics stack, get onto Wayland, that is
> where the future is.
> "

X.Org is definitely going to be shrinking market share going forwards.
That said its going to take a few years for this to happen, its not
going to be gone in 6 or 12 months. I'd hope that it should be a
relatively low maintenance burden over the next couple of years as it
won't change much, it will mainly be things like gcc changes that will
affect it.

> - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year),
> and does not have a Wayland compositor. Yocto project does not have
> the resources to do the gtk4 port, or add a compositor.

Whilst gtk4 will come out, gtk3 will continue for a while yet, it feels
like we only just got rid of gtk2+! :)

> - no 'lightweight Wayland compositor with a desktop/launcher
> experience" has emerged in the open source space; I think the only
> realistic choice at the moment is the reference compositor Weston
> which provides a blank desktop with ability to open terminal windows.
> 
> So the way I think things should be going (seeking opinions/inputs of
> course):
> 
> - oe-core adopts Weston as the 'new sato'; all sato images that
> currently pull in matchbox and friends are changed to be Weston-
> based. Note that there is no requirement for 3D acceleration; Weston
> works with plain frame buffer device. However, both options should be
> supported and tested. Also, support for Xwayland should be tested.
> 
> - oe-core continues to support and runtime-test X for as long as
> possible; for this a new image (say, 'core-image-sato-xorg') is
> created which will provide matchbox under X. However, once upstream
> bitrot sets in, and pain threshold is exceeded, this will be removed
> and/or relegated to a legacy layer.
> 
> Thoughts?

I still strongly believe we need something in core which pulls together
all our pieces into a UI where you can test key elements of what we
build. If we don't have sato how do we actually test the core or demo
it?

I think we shouldn't rush into things here. We should ramp up our
wayland testing and make the wayland images more useful/comprehensive
and then look at moving more of our tests from sato to the wayland
images.

So in summary, yes, I think we do retarget our testing over time and
strengthen when were testing under wayland. I probably don't see that
needing to happen quite as quickly as you do though!

Cheers,

Richard









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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Alexander Kanavin]

On Tue, 11 Feb 2020 at 16:58, Mark Hatle 
wrote:

>
> I also don't think oe-core itself needs a 'real' UI, and as my previous
> response
> said -- we do need something though to test that the graphical framework is
> working properly.
>
> In the past this often comes back to needing a LOT of a UI in order to
> adequately test all of the components of the system.   If wayland/weston
> has a
> proper test suite that exercises all of the various parts of and pieces of
> the
> systems -- then the need for a UI drops considerably.
>
> (but we still have the need for some sort of example/demostration...)
>

Wayland/weston do have test suites, neither of which we currently use. I
don't know how much they exercise all the moving parts, but the tests do
exist.

As for the demo/examples, I think we have reached the point where we can
outsource the eye candy to the Internet and not bother with 'apps'.
Specifically, just bundle epiphany/webkit into core-image-weston-demo, and
make a nice looking landing page somewhere on yoctoproject.org that links
to various HD video sites and WebGL demonstrators. As long as both GL and
h.264/whatnot are HW accelerated, this should look and feel fine, even in
qemu with virgl and kvm acceleration to a recent x86 CPU family.

For what it's worth, with my mbition.io hat on, I do not care in the
slightest for X anymore, and wouldn't blink an eye if all of it would
disappear from oe-core tomorrow. What I wanted to gauge is whether people
still use X for *new* product development, and for what reasons, and how
much resistance there is to the idea of switching the default graphical
stack in oe-core to weston.

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

[OE-core] ✗ patchtest: failure for expat: Added ptest (rev2)

[Patchwork]

== Series Details ==

Series: expat: Added ptest (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/22559/
State : failure

== Summary ==


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



* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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

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

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

Re: [OE-core] [PATCH v5] expat: Added ptest

[Alexander Kanavin]

Upstream status should be in the patch file that you added to the recipe
(just above the signed off), not in the commit message.

On Tue 11. Feb 2020 at 17.37, Oleksandr Popovych via Openembedded-core <
openembedded-core@lists.openembedded.org> wrote:

> For ptest support for this package several additional patches and
> run-ptest script were added and recipe was changed.
>
> Upstream-Status: Submitted [openembedded-core@lists.openembedded.org]
>
> Signed-off-by: Oleksandr Popovych 
> ---
>  ...d-Makefile-targets-for-ptest-support.patch | 38 ++
>  ...ort-for-ptests-in-form-of-new-target.patch | 31 
>  ...ed-suitable-format-of-tests-in-ptest.patch | 50 +++
>  meta/recipes-core/expat/expat/run-ptest   |  3 ++
>  meta/recipes-core/expat/expat_2.2.9.bb| 12 -
>  5 files changed, 133 insertions(+), 1 deletion(-)
>  create mode 100644
> meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
>  create mode 100644
> meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
>  create mode 100644
> meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
>  create mode 100644 meta/recipes-core/expat/expat/run-ptest
>
> diff --git
> a/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
> b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
> new file mode 100644
> index 00..32488060ee
> --- /dev/null
> +++
> b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
> @@ -0,0 +1,38 @@
> +From ce803ec3d7b095cb55686f9cd5d3f01d34a31a5e Mon Sep 17 00:00:00 2001
> +From: Oleksandr Popovych 
> +Date: Thu, 6 Feb 2020 13:41:45 +0200
> +Subject: [PATCH 1/3] expat: Added Makefile targets for ptest support
> +
> +install-ptest, runtests and check tagrets are added.
> +
> +Signed-off-by: Oleksandr Popovych 
> +---
> + Makefile.am | 15 +++
> + 1 file changed, 15 insertions(+)
> +
> +diff --git a/Makefile.am b/Makefile.am
> +index 5e1d37d..c63b44a 100644
> +--- a/Makefile.am
>  b/Makefile.am
> +@@ -152,3 +152,18 @@ qa:
> +   QA_COMPILER=clang QA_SANITIZER=memory./qa.sh
> +   QA_COMPILER=clang QA_SANITIZER=undefined ./qa.sh
> +   QA_COMPILER=gcc   QA_PROCESSOR=gcov  ./qa.sh
> ++
> ++.PHONY: install-ptest
> ++install-ptest:
> ++  echo $(S)
> ++  (if [ -d tests/.libs ] ; then cd tests/.libs; fi; \
> ++  install runtests runtestspp $(DESTDIR))
> ++  cp Makefile $(DESTDIR)
> ++  sed -i -e 's|^Makefile:|_Makefile:|' $(DESTDIR)/Makefile
> ++
> ++.PHONY: runtests
> ++runtests:
> ++  @echo "C variant of tests:"
> ++  @$(CHECKER) ./runtests$(EXEEXT) -q
> ++  @echo "C++ variant of tests:"
> ++  @$(CHECKER) ./runtestspp$(EXEEXT) -q
> +--
> +2.17.1
> +
> diff --git
> a/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
> b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
> new file mode 100644
> index 00..cf8a2495e9
> --- /dev/null
> +++
> b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
> @@ -0,0 +1,31 @@
> +From 2b209a025f62fb1be7b32599aa80703ce8ecd76a Mon Sep 17 00:00:00 2001
> +From: Oleksandr Popovych 
> +Date: Thu, 6 Feb 2020 13:43:57 +0200
> +Subject: [PATCH 2/3] expat: Added support for ptests in form of new target
> +
> +configure.am file changed, according to this advice:
> +https://wiki.yoctoproject.org/wiki/Ptest#Building_the_test_suite
> +
> +Signed-off-by: Oleksandr Popovych 
> +---
> + configure.ac | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/configure.ac b/configure.ac
> +index d58ac03..8e6b41e 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -34,8 +34,8 @@ AC_CONFIG_SRCDIR([Makefile.in])
> + AC_CONFIG_AUX_DIR([conftools])
> + AC_CONFIG_MACRO_DIR([m4])
> + AC_CANONICAL_HOST
> +-AM_INIT_AUTOMAKE
> +-
> ++AM_INIT_AUTOMAKE([serial-tests])
> ++AM_EXTRA_RECURSIVE_TARGETS([buildtest-TESTS])
> +
> + dnl
> + dnl Increment LIBREVISION if source code has changed at all
> +--
> +2.17.1
> +
> diff --git
> a/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
> b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
> new file mode 100644
> index 00..5d1daefc92
> --- /dev/null
> +++
> b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
> @@ -0,0 +1,50 @@
> +From b2e236e238f8bab42651313ea198b27355945d97 Mon Sep 17 00:00:00 2001
> +From: Oleksandr Popovych 
> +Date: Thu, 6 Feb 2020 13:44:56 +0200
> +Subject: [PATCH 3/3] expat: Added suitable format of tests in ptest
> +
> +Some changes in testcases code were applied for testcase engine.
> +This was just adding of message outputs in "RESULT: TESTNAME" form...

[OE-core] [PATCH v5] expat: Added ptest

[Oleksandr Popovych via Openembedded-core]

For ptest support for this package several additional patches and
run-ptest script were added and recipe was changed.

Upstream-Status: Submitted [openembedded-core@lists.openembedded.org]

Signed-off-by: Oleksandr Popovych 
---
 ...d-Makefile-targets-for-ptest-support.patch | 38 ++
 ...ort-for-ptests-in-form-of-new-target.patch | 31 
 ...ed-suitable-format-of-tests-in-ptest.patch | 50 +++
 meta/recipes-core/expat/expat/run-ptest   |  3 ++
 meta/recipes-core/expat/expat_2.2.9.bb| 12 -
 5 files changed, 133 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
 create mode 100644 
meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
 create mode 100644 
meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
 create mode 100644 meta/recipes-core/expat/expat/run-ptest

diff --git 
a/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
 
b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
new file mode 100644
index 00..32488060ee
--- /dev/null
+++ 
b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
@@ -0,0 +1,38 @@
+From ce803ec3d7b095cb55686f9cd5d3f01d34a31a5e Mon Sep 17 00:00:00 2001
+From: Oleksandr Popovych 
+Date: Thu, 6 Feb 2020 13:41:45 +0200
+Subject: [PATCH 1/3] expat: Added Makefile targets for ptest support
+
+install-ptest, runtests and check tagrets are added.
+
+Signed-off-by: Oleksandr Popovych 
+---
+ Makefile.am | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/Makefile.am b/Makefile.am
+index 5e1d37d..c63b44a 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -152,3 +152,18 @@ qa:
+   QA_COMPILER=clang QA_SANITIZER=memory./qa.sh
+   QA_COMPILER=clang QA_SANITIZER=undefined ./qa.sh
+   QA_COMPILER=gcc   QA_PROCESSOR=gcov  ./qa.sh
++
++.PHONY: install-ptest
++install-ptest:
++  echo $(S)
++  (if [ -d tests/.libs ] ; then cd tests/.libs; fi; \
++  install runtests runtestspp $(DESTDIR))
++  cp Makefile $(DESTDIR)
++  sed -i -e 's|^Makefile:|_Makefile:|' $(DESTDIR)/Makefile
++
++.PHONY: runtests
++runtests:
++  @echo "C variant of tests:"
++  @$(CHECKER) ./runtests$(EXEEXT) -q 
++  @echo "C++ variant of tests:"
++  @$(CHECKER) ./runtestspp$(EXEEXT) -q
+-- 
+2.17.1
+
diff --git 
a/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
 
b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
new file mode 100644
index 00..cf8a2495e9
--- /dev/null
+++ 
b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
@@ -0,0 +1,31 @@
+From 2b209a025f62fb1be7b32599aa80703ce8ecd76a Mon Sep 17 00:00:00 2001
+From: Oleksandr Popovych 
+Date: Thu, 6 Feb 2020 13:43:57 +0200
+Subject: [PATCH 2/3] expat: Added support for ptests in form of new target
+
+configure.am file changed, according to this advice:
+https://wiki.yoctoproject.org/wiki/Ptest#Building_the_test_suite
+
+Signed-off-by: Oleksandr Popovych 
+---
+ configure.ac | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index d58ac03..8e6b41e 100644
+--- a/configure.ac
 b/configure.ac
+@@ -34,8 +34,8 @@ AC_CONFIG_SRCDIR([Makefile.in])
+ AC_CONFIG_AUX_DIR([conftools])
+ AC_CONFIG_MACRO_DIR([m4])
+ AC_CANONICAL_HOST
+-AM_INIT_AUTOMAKE
+-
++AM_INIT_AUTOMAKE([serial-tests])
++AM_EXTRA_RECURSIVE_TARGETS([buildtest-TESTS])
+ 
+ dnl
+ dnl Increment LIBREVISION if source code has changed at all
+-- 
+2.17.1
+
diff --git 
a/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
 
b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
new file mode 100644
index 00..5d1daefc92
--- /dev/null
+++ 
b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
@@ -0,0 +1,50 @@
+From b2e236e238f8bab42651313ea198b27355945d97 Mon Sep 17 00:00:00 2001
+From: Oleksandr Popovych 
+Date: Thu, 6 Feb 2020 13:44:56 +0200
+Subject: [PATCH 3/3] expat: Added suitable format of tests in ptest
+
+Some changes in testcases code were applied for testcase engine.
+This was just adding of message outputs in "RESULT: TESTNAME" form...
+
+Signed-off-by: Oleksandr Popovych 
+---
+ tests/minicheck.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tests/minicheck.c b/tests/minicheck.c
+index a5a1efb..b39cda9 100644
+--- a/tests/minicheck.c
 b/tests/minicheck.c
+@@ -164,6 +164,7 @@ srunner_run_all(SRunner *runner, int verbosity) {
+   if (tc->setup != NULL) {
+ /* setup */
+ if (setjmp(env)) {
++  printf("SKIP: %s\n", _check_current_function);
+   add_failure(

Re: [OE-core] [PATCH v2] bitbake-buildall: automate build testing for qemu MACHINEs

[Khem Raj]

On Tue, Feb 11, 2020 at 6:06 AM Trevor Gamblin
 wrote:
>
>
> On 2/10/20 7:28 PM, Khem Raj wrote:
> > On Mon, Feb 10, 2020 at 3:47 PM Trevor Gamblin
> >  wrote:
> >> bitbake-buildall simplifies the process of build testing an upgraded or
> >> patched recipe by cycling through the build steps for each available qemu
> >> target, with desired LIBC specified by the user as an option (defaulting
> >> to both glibc and musl if no option is provided). While building, a log
> >> file with the name "-buildall.log" is written, containing a PASS
> >> or FAIL line upon completion of the build for each architecture. For now,
> >> qemu targets are not selectable (i.e. the recipe is built for all qemu
> >> targets found in meta/conf/machine), but this functionality can be added
> >> in the future along with other useful options.
> >>
> >> The log file created by bitbake-buildall also includes some basic system
> >> info (e.g. build start time, hostname, host OS, host kernel). Since it is
> >> not guaranteed that tools such as lsb_release will be available on the
> >> host (it isn't by default on my Fedora machine), this information is
> >> collected manually. Additionally, the previous run's log is retained for
> >> comparison by renaming it in the format -buildall.log.old once a
> >> new set of builds is triggered for the same recipe.
> >>
> >> Finally, in v2, the line "set -o pipefail" has been removed to be fully
> >> POSIX-compatible.
> >>
> >> Sample log output:
> >>
> >> BITBAKE-BUILDALL LOG FOR aspell
> >> START TIME: 2020-02-05_15:57:41
> >> HOSTNAME: yow-tgamblin-fedora2
> >> HOST OS: Fedora 31 (Server Edition)
> >> HOST KERNEL: 5.4.10-200.fc31.x86_64
> >> ===
> >> BUILD RESULTS:
> >> [glibc]
> >> PASS: qemuarmv5
> >> PASS: qemux86
> >> PASS: qemuppc
> >> PASS: qemumips64
> >> FAIL: qemux86-64
> >> FAIL: qemumips
> >> FAIL: qemuarm
> >> FAIL: qemuarm64
> >> FAIL: qemuriscv64
> >> [musl]
> >> PASS: qemuarmv5
> >> PASS: qemux86
> >> PASS: qemuppc
> >> PASS: qemumips64
> >> PASS: qemux86-64
> >> PASS: qemumips
> >> PASS: qemuarm
> >> PASS: qemuarm64
> >> PASS: qemuriscv64
> >> ===
> >> PASSED: 13
> >> FAILED: 5
> >>
> >> Signed-off-by: Trevor Gamblin 
> >> ---
> >>   scripts/bitbake-buildall | 120 +++
> >>   1 file changed, 120 insertions(+)
> >>   create mode 100755 scripts/bitbake-buildall
> > if its building qemu machines only, then naming it build-qemuall.sh or
> > some such would be
> > better, I would avoid usine bitbake- prefix. That can confuse with bitbake 
> > tools
>
> The intent is that it can be extended to machines other than just qemu
> with later patches, so I'm hesitant to give it a qemu-specific name.
>

its not clear if its generic enough, its grepping into hardcoded paths
in oe-core repo which
perhaps makes it specific.

> I could rename it to something like buildall-targets.
>

since we use bitbake- for general tooling around bitbake,
this seems not fit that
bill.

> >
> >> diff --git a/scripts/bitbake-buildall b/scripts/bitbake-buildall
> >> new file mode 100755
> >> index 00..74a5994f2f
> >> --- /dev/null
> >> +++ b/scripts/bitbake-buildall
> >> @@ -0,0 +1,120 @@
> >> +#!/bin/sh
> >> +#  Copyright (c) 2020 Wind River Systems, Inc.
> >> +#
> >> +# SPDX-License-Identifier: GPL-2.0-only
> >> +#
> >> +# bitbake-buildall: a tool for automating build testing of recipes
> >> +# TODO: Add support for selecting which qemu architectures to build
> >> +# TODO: Add support for queueing up multiple recipe builds
> >> +# TODO: Add more logging options (e.g. local.conf info, bitbake env info)
> >> +
> >> +usage ()
> >> +{
> >> +base=$(basename "$0")
> >> +echo "Usage: $base [options] [recipename/target]"
> >> +echo "Executes a build of a given target for selected LIBCs. With no 
> >> options, default to both libc and musl."
> >> +echo "Options:"
> >> +echo "-l, --libcSpecify one of \"libc\" or \"musl\""
> >> +}
> >> +
> >> +
> >> +buildall ()
> >> +{
> >> +# Get path to oe-core directory. Since oe-init-build-env prepends 
> >> $PATH with
> >> +# the path to the scripts directory, get it from there
> >> +SCRIPTS_PATH="$(echo "$PATH" | cut -d ":" -f 1)"
> >> +OE_CORE_PATH=$(echo "$SCRIPTS_PATH" | sed 's|\(.*\)/.*|\1|')
> >> +
> >> +# Get target list and host machine information
> >> +TARGET_LIST=$(find "$OE_CORE_PATH"/meta/conf/machine -maxdepth 1 
> >> -type f | grep qemu | sed 's|.*/||' | sed -e 's/\.conf//')
> >> +
> >> +# Set LIBC value to use for the builds based on options provided by 
> >> the user
> >> +if [ -n "$2" ]
> >> +then
> >> +   LIBC_LIST="$2"
> >> +   echo "$LIBC_LIST"
> >> +else
> >> +   LIBC_LIST="glibc musl"
> >> +   echo "$LIBC_LIST"
> >> +fi
> >> +
> >> +START_TIME=$(date "+%Y-%m-%d_%H:%M:%S")
> >> +LOG_FILE="$1-buildall.log"
> >> +OS_INFO=$(grep "PRETTY_NAME=" /etc/os-release | awk -F "=" '{print 
> >> $2}' | sed -e 

[OE-core] ✗ patchtest: failure for expat: Added ptest

[Patchwork]

== Series Details ==

Series: expat: Added ptest
Revision: 1
URL   : https://patchwork.openembedded.org/series/22559/
State : failure

== Summary ==


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



* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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

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

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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Mark Hatle]

On 2/11/20 8:35 AM, Alexander Kanavin wrote:
> X might and likely will start to bitrot sooner for those not using RHEL 8 and
> its very conservative and never changing software stack. I can imagine Red Hat
> has no interest in supporting it on Fedora going forward for instance, they'll
> just make Xwayland work, and rip the standalone server and its drivers and
> libraries out. 

X is incredibly stable code base.  I think as long as there are no major
changes, the bitrot will be 'minor'.  I'm more worried about security response,
especially as it goes longer and longer with only a small set of maintainers of
last resort.

> Oe-core will have X for as long as the burden of fixing build errors and 
> runtime
> issues with custom patches is not too painful. The point I am trying to make 
> is
> that I am not convinced oe-core needs a 'real' ui at all, and opinion to the
> contrary should justify the need.

It's already OE's responsibility to fix build errors and integration run-time
issues.  When the burden goes beyond our resources, then we need to stop or find
a champion who will taker that burden.

I think we need to plan for that for all of the components of the system, not
just X, but X is a good starting point.

I also don't think oe-core itself needs a 'real' UI, and as my previous response
said -- we do need something though to test that the graphical framework is
working properly.

In the past this often comes back to needing a LOT of a UI in order to
adequately test all of the components of the system.   If wayland/weston has a
proper test suite that exercises all of the various parts of and pieces of the
systems -- then the need for a UI drops considerably.

(but we still have the need for some sort of example/demostration...)

--Mark

> Alex
> 
> On Tue, 11 Feb 2020 at 15:13, Adrian Bunk  > wrote:
> 
> On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote:
> > Specifically (sorry for the rapid-followup), I think the main value
> > proposition of core is integration and testing of various language
> > toolchains and core libraries. UIs in embedded space can mean pretty 
> much
> > anything, and so I'd leave that to specialised layers.
> 
> That's actually quite different from your original email.
> 
> Your original email raised the problem that X might start to bitrot
> after the end of support for RHEL 8 in the year 2029 (sic).
> 
> What functionality should be in core for users/demo/QA/...
> is not strictly related to X versus Wayland.
> 
> > Alex
> 
> cu
> Adrian
> 
> 
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v4] expat: Added ptest

[Oleksandr Popovych via Openembedded-core]

For ptest support for this package several additional patches and
run-ptest script were added and recipe was changed.

Signed-off-by: Oleksandr Popovych 
---
 ...d-Makefile-targets-for-ptest-support.patch | 38 ++
 ...ort-for-ptests-in-form-of-new-target.patch | 31 
 ...ed-suitable-format-of-tests-in-ptest.patch | 50 +++
 meta/recipes-core/expat/expat/run-ptest   |  3 ++
 meta/recipes-core/expat/expat_2.2.9.bb| 12 -
 5 files changed, 133 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
 create mode 100644 
meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
 create mode 100644 
meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
 create mode 100644 meta/recipes-core/expat/expat/run-ptest

diff --git 
a/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
 
b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
new file mode 100644
index 00..32488060ee
--- /dev/null
+++ 
b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch
@@ -0,0 +1,38 @@
+From ce803ec3d7b095cb55686f9cd5d3f01d34a31a5e Mon Sep 17 00:00:00 2001
+From: Oleksandr Popovych 
+Date: Thu, 6 Feb 2020 13:41:45 +0200
+Subject: [PATCH 1/3] expat: Added Makefile targets for ptest support
+
+install-ptest, runtests and check tagrets are added.
+
+Signed-off-by: Oleksandr Popovych 
+---
+ Makefile.am | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/Makefile.am b/Makefile.am
+index 5e1d37d..c63b44a 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -152,3 +152,18 @@ qa:
+   QA_COMPILER=clang QA_SANITIZER=memory./qa.sh
+   QA_COMPILER=clang QA_SANITIZER=undefined ./qa.sh
+   QA_COMPILER=gcc   QA_PROCESSOR=gcov  ./qa.sh
++
++.PHONY: install-ptest
++install-ptest:
++  echo $(S)
++  (if [ -d tests/.libs ] ; then cd tests/.libs; fi; \
++  install runtests runtestspp $(DESTDIR))
++  cp Makefile $(DESTDIR)
++  sed -i -e 's|^Makefile:|_Makefile:|' $(DESTDIR)/Makefile
++
++.PHONY: runtests
++runtests:
++  @echo "C variant of tests:"
++  @$(CHECKER) ./runtests$(EXEEXT) -q 
++  @echo "C++ variant of tests:"
++  @$(CHECKER) ./runtestspp$(EXEEXT) -q
+-- 
+2.17.1
+
diff --git 
a/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
 
b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
new file mode 100644
index 00..cf8a2495e9
--- /dev/null
+++ 
b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch
@@ -0,0 +1,31 @@
+From 2b209a025f62fb1be7b32599aa80703ce8ecd76a Mon Sep 17 00:00:00 2001
+From: Oleksandr Popovych 
+Date: Thu, 6 Feb 2020 13:43:57 +0200
+Subject: [PATCH 2/3] expat: Added support for ptests in form of new target
+
+configure.am file changed, according to this advice:
+https://wiki.yoctoproject.org/wiki/Ptest#Building_the_test_suite
+
+Signed-off-by: Oleksandr Popovych 
+---
+ configure.ac | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index d58ac03..8e6b41e 100644
+--- a/configure.ac
 b/configure.ac
+@@ -34,8 +34,8 @@ AC_CONFIG_SRCDIR([Makefile.in])
+ AC_CONFIG_AUX_DIR([conftools])
+ AC_CONFIG_MACRO_DIR([m4])
+ AC_CANONICAL_HOST
+-AM_INIT_AUTOMAKE
+-
++AM_INIT_AUTOMAKE([serial-tests])
++AM_EXTRA_RECURSIVE_TARGETS([buildtest-TESTS])
+ 
+ dnl
+ dnl Increment LIBREVISION if source code has changed at all
+-- 
+2.17.1
+
diff --git 
a/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
 
b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
new file mode 100644
index 00..5d1daefc92
--- /dev/null
+++ 
b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch
@@ -0,0 +1,50 @@
+From b2e236e238f8bab42651313ea198b27355945d97 Mon Sep 17 00:00:00 2001
+From: Oleksandr Popovych 
+Date: Thu, 6 Feb 2020 13:44:56 +0200
+Subject: [PATCH 3/3] expat: Added suitable format of tests in ptest
+
+Some changes in testcases code were applied for testcase engine.
+This was just adding of message outputs in "RESULT: TESTNAME" form...
+
+Signed-off-by: Oleksandr Popovych 
+---
+ tests/minicheck.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/tests/minicheck.c b/tests/minicheck.c
+index a5a1efb..b39cda9 100644
+--- a/tests/minicheck.c
 b/tests/minicheck.c
+@@ -164,6 +164,7 @@ srunner_run_all(SRunner *runner, int verbosity) {
+   if (tc->setup != NULL) {
+ /* setup */
+ if (setjmp(env)) {
++  printf("SKIP: %s\n", _check_current_function);
+   add_failure(runner, verbosity);
+   continue;
+ }
+@@ -171,6 +172,7

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Mark Hatle]

On 2/11/20 8:01 AM, Alexander Kanavin wrote:
> Specifically (sorry for the rapid-followup), I think the main value 
> proposition
> of core is integration and testing of various language toolchains and core
> libraries. UIs in embedded space can mean pretty much anything, and so I'd 
> leave
> that to specialised layers.
> 
> Alex
> 
> On Tue, 11 Feb 2020 at 14:57, Alexander Kanavin  > wrote:
> 
> The question is: what are the use cases for an 'example/reference UI'? Why
> have one at all at this point? Remember, the core project is severely
> under-staffed and we need to commit our limited resources wisely.

I don't think an example/reference UI is useful -- OTHER THEN -- we need a way
to test that the framework(s) that are provided are functional.  So lets, assume
Wayland/Weston combo..  we still need something that can use the mouse, show
that the cursor is being drawn properly, clicks are registered, etc etc etc..

I do think that we need to include a graphical framework (X.org, wayland/weston
combo, etc..) as well as a basic set of examples that can be used to verify that
they are working properly.

There is a secondary 'problem' which I see more as a business issue then a
technical one, everyone wants to have a way to 'demo the OpenEmbedded'.  It's
pretty hard to demo a build system, so they like to have a device that boots
quickly and goes to something graphical that shows it's "working".

--Mark

> Alex
> 
> On Tue, 11 Feb 2020 at 14:53, Adrian Bunk  > wrote:
> 
> On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
> >...
> > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), 
> and
> does
> > not have a Wayland compositor. Yocto project does not have the
> resources to
> > do the gtk4 port, or add a compositor.
> >
> > - no 'lightweight Wayland compositor with a desktop/launcher 
> experience"
> > has emerged in the open source space; I think the only realistic 
> choice at
> > the moment is the reference compositor Weston which provides a blank
> > desktop with ability to open terminal windows.
> >
> > So the way I think things should be going (seeking opinions/inputs 
> of
> > course):
> >...
> > - oe-core continues to support and runtime-test X for as long as 
> possible;
> > for this a new image (say, 'core-image-sato-xorg') is created which 
> will
> > provide matchbox under X. However, once upstream bitrot sets in, 
> and pain
> > threshold is exceeded, this will be removed and/or relegated to a 
> legacy
> > layer.
> >
> > Thoughts?
> 
> matchbox made sense at a time when you could go into a shop and buy an
> internet tablet with Linux running on 256 MB flash with 256 MB RAM.
> 
> Part of the problem is that the only remaining usage of this branch
> of matchbox development seems to be as example UI for Yocto.
> 
> For matchbox/sato I am wondering whether replacing it with parts of
> meta-xfce from meta-openembedded would be a good way forward.
> 
> Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
> support, but at the point where supporting X might become a problem
> this should be available.
> 
> Xfce was my first thought as replacement since it appears to be
> well-maintained in meta-openembedded, no strong opinion whether
> it is actually the best option.
> 
> > Regards,
> > Alex
> 
> cu
> Adrian
> 
> 
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Status WW06'20

[sjolley.yp.pm]

Current Dev Position: YP 3.1 M3

Next Deadline: YP 3.1 M3 build date 2/24/2020

 

Next Team Meetings:

*   Bug Triage meeting Thursday Feb. 13th  at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Mar. 3rd  at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday Feb. 11th at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch - Next event is Tuesday Feb. 11th at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   YP 3.1 M2 was released
*   We're now in a much better position with reproducibility issues
after around 20 patches merged addressing various problems. Some issues
still remain but the bulk of the issues appear to be under control now.
*   Due to the number and type of fixes found, the 3.0.2 rc1 build will
be abandoned and rc2 built with the reproducibility fixes (as well as
additional hashserv/multiconfig fixes). This delays 3.0.2 by a week but for
a reasonable set of improvements.
*   YP 3.0.2 should therefore enter QA within the next day or so.
*   Review of newly queued warrior (2.7.3) patches will happen later
this week once 3.0.2 is in QA.
*   With the new fixes and a small fix to the autobuilder code, we
managed the first green "full" build in nearly three months.
*   The incoming patch queue is roughly under control again
*   We're collecting a list of companies, products and projects which
use the Yocto Project on the wiki:

https://wiki.yoctoproject.org/wiki/Project_Users Please add any you know are
missing (or email Richard/Stephen who can add).
*   One worrying metric is that the WDD is now on level with the high of
2017 so our worst defect weighting in two years. This is sadly unsurprising
and directly correlated to a lack of participation in the triage process and
a lack of people working on general bug fixing.
*   The triage team is worried about attendance at triage meetings and
the project is finding it hard to find people to help fix bugs. If anyone is
willing to work on bugs, assistance would be greatly appreciated.

 

YP 3.1 Milestone Dates:

*   YP 3.1 M3 build date 2/24/2020
*   YP 3.1 M3 release date 3/6/2020
*   YP 3.1 M4 build date  3/30/2020
*   YP 3.1 M4 release date  4/24/2020

 

Planned upcoming dot releases:

*   YP 2.7.3 build date  2/10/2020
*   YP 2.7.3 release date 2/21/2020
*   YP 3.0.2 build date  2/3/2020
*   YP 3.0.2 release date 2/14/2020

 

Tracking Metrics:

*   WDD 2728 (last week 2767) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1361 (last week 1368)
*   Patches in the Pending State: 547 (40%) [last week 544 (40%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 

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

[OE-core] [PATCH] glibc-package.inc: fix multilib headers conflict

[kai.kang]

From: Kai Kang 

Pass bits/endianness.h and bits/struct_rwlock.h to oe_multilib_header in
glibc-package.inc to fix files conflict:

| Error: Transaction check error:
|   file /usr/include/bits/endianness.h conflicts between attempted installs of 
lib32-libc6-dev-2.31-r0.armv7vet2hf_vfp and libc6-dev-2.31-r0.aarch64
|   file /usr/include/bits/struct_rwlock.h conflicts between attempted installs 
of lib32-libc6-dev-2.31-r0.armv7vet2hf_vfp and libc6-dev-2.31-r0.aarch64

Signed-off-by: Kai Kang 
---
 meta/recipes-core/glibc/glibc-package.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 3aed7be4f8..285a9aa2f5 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -87,7 +87,7 @@ do_install() {
rmdir --ignore-fail-on-non-empty ${D}${libexecdir}
fi
 
-   oe_multilib_header bits/syscall.h bits/long-double.h bits/floatn.h
+   oe_multilib_header bits/syscall.h bits/long-double.h bits/floatn.h 
bits/endianness.h bits/struct_rwlock.h
 
if [ -f ${D}${bindir}/mtrace ]; then
sed -i -e '1s,#!.*perl,#! ${USRBINPATH}/env perl,' -e 
'2s,exec.*perl,exec ${USRBINPATH}/env perl,' ${D}${bindir}/mtrace
-- 
2.17.1

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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Adrian Bunk]

On Tue, Feb 11, 2020 at 03:35:03PM +0100, Alexander Kanavin wrote:
> X might and likely will start to bitrot sooner for those not using RHEL 8
> and its very conservative and never changing software stack. I can imagine
> Red Hat has no interest in supporting it on Fedora going forward for
> instance, they'll just make Xwayland work, and rip the standalone server
> and its drivers and libraries out.

There are plenty of other users big and small left, and most of the
hardware support already moved to the kernel.

Stale and stable is not necessarily bad for users, and X will not
suddenly stop working.

> Oe-core will have X for as long as the burden of fixing build errors and
> runtime issues with custom patches is not too painful.

If this is true, then let's revisit this topic in 10 years.

And the solution would then likely be to switch from matchbox/sato
to some desktop environment that supports wayland.

> The point I am
> trying to make is that I am not convinced oe-core needs a 'real' ui at all,
> and opinion to the contrary should justify the need.

The point I am trying to make is that this is a different discussion.

And any "no UI in oe-core" decision would not have to wait until the 
point in the distant future when X might no longer be supportable.

> Alex

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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Alexander Kanavin]

X might and likely will start to bitrot sooner for those not using RHEL 8
and its very conservative and never changing software stack. I can imagine
Red Hat has no interest in supporting it on Fedora going forward for
instance, they'll just make Xwayland work, and rip the standalone server
and its drivers and libraries out.

Oe-core will have X for as long as the burden of fixing build errors and
runtime issues with custom patches is not too painful. The point I am
trying to make is that I am not convinced oe-core needs a 'real' ui at all,
and opinion to the contrary should justify the need.

Alex

On Tue, 11 Feb 2020 at 15:13, Adrian Bunk  wrote:

> On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote:
> > Specifically (sorry for the rapid-followup), I think the main value
> > proposition of core is integration and testing of various language
> > toolchains and core libraries. UIs in embedded space can mean pretty much
> > anything, and so I'd leave that to specialised layers.
>
> That's actually quite different from your original email.
>
> Your original email raised the problem that X might start to bitrot
> after the end of support for RHEL 8 in the year 2029 (sic).
>
> What functionality should be in core for users/demo/QA/...
> is not strictly related to X versus Wayland.
>
> > Alex
>
> cu
> Adrian
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Josef Holzmayr]

Howdy!

On Tue, Feb 11, 2020 at 02:57:48PM +0100, Alexander Kanavin wrote:
> The question is: what are the use cases for an 'example/reference UI'? Why
> have one at all at this point? Remember, the core project is severely
> under-staffed and we need to commit our limited resources wisely.

My $.02 are, that while being a good test vehicle to build for us, it is
actually giving a wrong impression to newcomers. Like "here is a DE to
start off, and you can use this build like your desktop box" which is not
at all true.

So my votes are on, as long as we have something that *can* do
*something* on screen with as little effort as possible, we should go
for it. Maintaining a custom thing should be avoided.

Greetz

> 
> On Tue, 11 Feb 2020 at 14:53, Adrian Bunk  wrote:
> 
> > On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
> > >...
> > > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and
> > does
> > > not have a Wayland compositor. Yocto project does not have the resources
> > to
> > > do the gtk4 port, or add a compositor.
> > >
> > > - no 'lightweight Wayland compositor with a desktop/launcher experience"
> > > has emerged in the open source space; I think the only realistic choice
> > at
> > > the moment is the reference compositor Weston which provides a blank
> > > desktop with ability to open terminal windows.
> > >
> > > So the way I think things should be going (seeking opinions/inputs of
> > > course):
> > >...
> > > - oe-core continues to support and runtime-test X for as long as
> > possible;
> > > for this a new image (say, 'core-image-sato-xorg') is created which will
> > > provide matchbox under X. However, once upstream bitrot sets in, and pain
> > > threshold is exceeded, this will be removed and/or relegated to a legacy
> > > layer.
> > >
> > > Thoughts?
> >
> > matchbox made sense at a time when you could go into a shop and buy an
> > internet tablet with Linux running on 256 MB flash with 256 MB RAM.
> >
> > Part of the problem is that the only remaining usage of this branch
> > of matchbox development seems to be as example UI for Yocto.
> >
> > For matchbox/sato I am wondering whether replacing it with parts of
> > meta-xfce from meta-openembedded would be a good way forward.
> >
> > Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
> > support, but at the point where supporting X might become a problem
> > this should be available.
> >
> > Xfce was my first thought as replacement since it appears to be
> > well-maintained in meta-openembedded, no strong opinion whether
> > it is actually the best option.
> >
> > > Regards,
> > > Alex
> >
> > cu
> > Adrian
> >

> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


-- 
———
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Adrian Bunk]

On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote:
> Specifically (sorry for the rapid-followup), I think the main value
> proposition of core is integration and testing of various language
> toolchains and core libraries. UIs in embedded space can mean pretty much
> anything, and so I'd leave that to specialised layers.

That's actually quite different from your original email.

Your original email raised the problem that X might start to bitrot
after the end of support for RHEL 8 in the year 2029 (sic).

What functionality should be in core for users/demo/QA/...
is not strictly related to X versus Wayland.

> Alex

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

Re: [OE-core] [PATCH v2] bitbake-buildall: automate build testing for qemu MACHINEs

[Trevor Gamblin]

On 2/10/20 7:28 PM, Khem Raj wrote:

On Mon, Feb 10, 2020 at 3:47 PM Trevor Gamblin
 wrote:

bitbake-buildall simplifies the process of build testing an upgraded or
patched recipe by cycling through the build steps for each available qemu
target, with desired LIBC specified by the user as an option (defaulting
to both glibc and musl if no option is provided). While building, a log
file with the name "-buildall.log" is written, containing a PASS
or FAIL line upon completion of the build for each architecture. For now,
qemu targets are not selectable (i.e. the recipe is built for all qemu
targets found in meta/conf/machine), but this functionality can be added
in the future along with other useful options.

The log file created by bitbake-buildall also includes some basic system
info (e.g. build start time, hostname, host OS, host kernel). Since it is
not guaranteed that tools such as lsb_release will be available on the
host (it isn't by default on my Fedora machine), this information is
collected manually. Additionally, the previous run's log is retained for
comparison by renaming it in the format -buildall.log.old once a
new set of builds is triggered for the same recipe.

Finally, in v2, the line "set -o pipefail" has been removed to be fully
POSIX-compatible.

Sample log output:

BITBAKE-BUILDALL LOG FOR aspell
START TIME: 2020-02-05_15:57:41
HOSTNAME: yow-tgamblin-fedora2
HOST OS: Fedora 31 (Server Edition)
HOST KERNEL: 5.4.10-200.fc31.x86_64
===
BUILD RESULTS:
[glibc]
PASS: qemuarmv5
PASS: qemux86
PASS: qemuppc
PASS: qemumips64
FAIL: qemux86-64
FAIL: qemumips
FAIL: qemuarm
FAIL: qemuarm64
FAIL: qemuriscv64
[musl]
PASS: qemuarmv5
PASS: qemux86
PASS: qemuppc
PASS: qemumips64
PASS: qemux86-64
PASS: qemumips
PASS: qemuarm
PASS: qemuarm64
PASS: qemuriscv64
===
PASSED: 13
FAILED: 5

Signed-off-by: Trevor Gamblin 
---
  scripts/bitbake-buildall | 120 +++
  1 file changed, 120 insertions(+)
  create mode 100755 scripts/bitbake-buildall

if its building qemu machines only, then naming it build-qemuall.sh or
some such would be
better, I would avoid usine bitbake- prefix. That can confuse with bitbake tools


The intent is that it can be extended to machines other than just qemu 
with later patches, so I'm hesitant to give it a qemu-specific name.


I could rename it to something like buildall-targets.




diff --git a/scripts/bitbake-buildall b/scripts/bitbake-buildall
new file mode 100755
index 00..74a5994f2f
--- /dev/null
+++ b/scripts/bitbake-buildall
@@ -0,0 +1,120 @@
+#!/bin/sh
+#  Copyright (c) 2020 Wind River Systems, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# bitbake-buildall: a tool for automating build testing of recipes
+# TODO: Add support for selecting which qemu architectures to build
+# TODO: Add support for queueing up multiple recipe builds
+# TODO: Add more logging options (e.g. local.conf info, bitbake env info)
+
+usage ()
+{
+base=$(basename "$0")
+echo "Usage: $base [options] [recipename/target]"
+echo "Executes a build of a given target for selected LIBCs. With no options, 
default to both libc and musl."
+echo "Options:"
+echo "-l, --libcSpecify one of \"libc\" or \"musl\""
+}
+
+
+buildall ()
+{
+# Get path to oe-core directory. Since oe-init-build-env prepends $PATH 
with
+# the path to the scripts directory, get it from there
+SCRIPTS_PATH="$(echo "$PATH" | cut -d ":" -f 1)"
+OE_CORE_PATH=$(echo "$SCRIPTS_PATH" | sed 's|\(.*\)/.*|\1|')
+
+# Get target list and host machine information
+TARGET_LIST=$(find "$OE_CORE_PATH"/meta/conf/machine -maxdepth 1 -type f | 
grep qemu | sed 's|.*/||' | sed -e 's/\.conf//')
+
+# Set LIBC value to use for the builds based on options provided by the 
user
+if [ -n "$2" ]
+then
+   LIBC_LIST="$2"
+   echo "$LIBC_LIST"
+else
+   LIBC_LIST="glibc musl"
+   echo "$LIBC_LIST"
+fi
+
+START_TIME=$(date "+%Y-%m-%d_%H:%M:%S")
+LOG_FILE="$1-buildall.log"
+OS_INFO=$(grep "PRETTY_NAME=" /etc/os-release | awk -F "=" '{print $2}' | sed -e 
's/^"//' -e 's/"$//')
+
+# Append an existing log file for this build with .old if one exists
+if [ -f "${LOG_FILE}" ]
+then
+   mv "${LOG_FILE}" "${LOG_FILE}.old"
+else
+  touch "${LOG_FILE}"
+fi
+
+# Fill the log file with build and host info
+echo "BITBAKE-BUILDALL LOG FOR $1" >> "${LOG_FILE}"
+echo "START TIME: ${START_TIME}" >> "${LOG_FILE}"
+echo "HOSTNAME: $(uname -n)" >> "${LOG_FILE}"
+echo "HOST OS: ${OS_INFO}" >> "${LOG_FILE}"
+echo "HOST KERNEL: $(uname -r)" >> "${LOG_FILE}"
+echo "===" >> "${LOG_FILE}"
+echo "BUILD RESULTS:" >> "${LOG_FILE}"
+
+# start the builds for each MACHINE and TCLIBC
+for j in ${LIBC_LIST}
+do
+   echo "[$j]" >> "${LOG_FILE}"
+   for i in ${TARGET_LIST}
+   do
+   echo "$i" "$j"; \
+   TCLIBC=$j MA

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Alexander Kanavin]

Specifically (sorry for the rapid-followup), I think the main value
proposition of core is integration and testing of various language
toolchains and core libraries. UIs in embedded space can mean pretty much
anything, and so I'd leave that to specialised layers.

Alex

On Tue, 11 Feb 2020 at 14:57, Alexander Kanavin 
wrote:

> The question is: what are the use cases for an 'example/reference UI'? Why
> have one at all at this point? Remember, the core project is severely
> under-staffed and we need to commit our limited resources wisely.
>
> Alex
>
> On Tue, 11 Feb 2020 at 14:53, Adrian Bunk  wrote:
>
>> On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
>> >...
>> > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and
>> does
>> > not have a Wayland compositor. Yocto project does not have the
>> resources to
>> > do the gtk4 port, or add a compositor.
>> >
>> > - no 'lightweight Wayland compositor with a desktop/launcher experience"
>> > has emerged in the open source space; I think the only realistic choice
>> at
>> > the moment is the reference compositor Weston which provides a blank
>> > desktop with ability to open terminal windows.
>> >
>> > So the way I think things should be going (seeking opinions/inputs of
>> > course):
>> >...
>> > - oe-core continues to support and runtime-test X for as long as
>> possible;
>> > for this a new image (say, 'core-image-sato-xorg') is created which will
>> > provide matchbox under X. However, once upstream bitrot sets in, and
>> pain
>> > threshold is exceeded, this will be removed and/or relegated to a legacy
>> > layer.
>> >
>> > Thoughts?
>>
>> matchbox made sense at a time when you could go into a shop and buy an
>> internet tablet with Linux running on 256 MB flash with 256 MB RAM.
>>
>> Part of the problem is that the only remaining usage of this branch
>> of matchbox development seems to be as example UI for Yocto.
>>
>> For matchbox/sato I am wondering whether replacing it with parts of
>> meta-xfce from meta-openembedded would be a good way forward.
>>
>> Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
>> support, but at the point where supporting X might become a problem
>> this should be available.
>>
>> Xfce was my first thought as replacement since it appears to be
>> well-maintained in meta-openembedded, no strong opinion whether
>> it is actually the best option.
>>
>> > Regards,
>> > Alex
>>
>> cu
>> Adrian
>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Adrian Bunk]

On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
>...
> - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and does
> not have a Wayland compositor. Yocto project does not have the resources to
> do the gtk4 port, or add a compositor.
> 
> - no 'lightweight Wayland compositor with a desktop/launcher experience"
> has emerged in the open source space; I think the only realistic choice at
> the moment is the reference compositor Weston which provides a blank
> desktop with ability to open terminal windows.
> 
> So the way I think things should be going (seeking opinions/inputs of
> course):
>...
> - oe-core continues to support and runtime-test X for as long as possible;
> for this a new image (say, 'core-image-sato-xorg') is created which will
> provide matchbox under X. However, once upstream bitrot sets in, and pain
> threshold is exceeded, this will be removed and/or relegated to a legacy
> layer.
> 
> Thoughts?

matchbox made sense at a time when you could go into a shop and buy an
internet tablet with Linux running on 256 MB flash with 256 MB RAM.

Part of the problem is that the only remaining usage of this branch
of matchbox development seems to be as example UI for Yocto.

For matchbox/sato I am wondering whether replacing it with parts of
meta-xfce from meta-openembedded would be a good way forward.

Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland 
support, but at the point where supporting X might become a problem
this should be available.

Xfce was my first thought as replacement since it appears to be 
well-maintained in meta-openembedded, no strong opinion whether
it is actually the best option.

> Regards,
> Alex

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

Re: [OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Alexander Kanavin]

The question is: what are the use cases for an 'example/reference UI'? Why
have one at all at this point? Remember, the core project is severely
under-staffed and we need to commit our limited resources wisely.

Alex

On Tue, 11 Feb 2020 at 14:53, Adrian Bunk  wrote:

> On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
> >...
> > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and
> does
> > not have a Wayland compositor. Yocto project does not have the resources
> to
> > do the gtk4 port, or add a compositor.
> >
> > - no 'lightweight Wayland compositor with a desktop/launcher experience"
> > has emerged in the open source space; I think the only realistic choice
> at
> > the moment is the reference compositor Weston which provides a blank
> > desktop with ability to open terminal windows.
> >
> > So the way I think things should be going (seeking opinions/inputs of
> > course):
> >...
> > - oe-core continues to support and runtime-test X for as long as
> possible;
> > for this a new image (say, 'core-image-sato-xorg') is created which will
> > provide matchbox under X. However, once upstream bitrot sets in, and pain
> > threshold is exceeded, this will be removed and/or relegated to a legacy
> > layer.
> >
> > Thoughts?
>
> matchbox made sense at a time when you could go into a shop and buy an
> internet tablet with Linux running on 256 MB flash with 256 MB RAM.
>
> Part of the problem is that the only remaining usage of this branch
> of matchbox development seems to be as example UI for Yocto.
>
> For matchbox/sato I am wondering whether replacing it with parts of
> meta-xfce from meta-openembedded would be a good way forward.
>
> Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
> support, but at the point where supporting X might become a problem
> this should be available.
>
> Xfce was my first thought as replacement since it appears to be
> well-maintained in meta-openembedded, no strong opinion whether
> it is actually the best option.
>
> > Regards,
> > Alex
>
> cu
> Adrian
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [zeus][PATCH v2] ruby: fix CVE-2019-16254

[Rahul Chauhan]

Signed-off-by: Rahul Chauhan 
---
 .../ruby/ruby/fix-CVE-2019-16254.patch | 106 +
 meta/recipes-devtools/ruby/ruby_2.5.5.bb   |   1 +
 2 files changed, 107 insertions(+)
 create mode 100644 meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch

diff --git a/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch 
b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
new file mode 100644
index 000..704c850
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
@@ -0,0 +1,106 @@
+From 18d5289b4579822e391b3f5c16541e6552e9f06c Mon Sep 17 00:00:00 2001
+From: Yusuke Endoh 
+Date: Tue, 1 Oct 2019 12:29:18 +0900
+Subject: [PATCH] WEBrick: prevent response splitting and header injection
+
+This is a follow up to d9d4a28f1cdd05a0e8dabb36d747d40bbcc30f16.
+The commit prevented CRLR, but did not address an isolated CR or an
+isolated LF.
+
+Upstream-Status: Backport 
https://github.com/ruby/ruby/commit/3ce238b5f9795581eb84114dcfbdf4aa086bfecc
+CVE: CVE-2019-16254
+
+Co-Authored-By: NARUSE, Yui 
+Signed-off-by: Rahul Chauhan 
+---
+ lib/webrick/httpresponse.rb   |  3 ++-
+ test/webrick/test_httpresponse.rb | 46 +--
+ 2 files changed, 46 insertions(+), 3 deletions(-)
+
+diff --git a/lib/webrick/httpresponse.rb b/lib/webrick/httpresponse.rb
+index 6d77692..d26324c 100644
+--- a/lib/webrick/httpresponse.rb
 b/lib/webrick/httpresponse.rb
+@@ -367,7 +367,8 @@ def set_error(ex, backtrace=false)
+ private
+
+ def check_header(header_value)
+-  if header_value =~ /\r\n/
++  header_value = header_value.to_s
++  if /[\r\n]/ =~ header_value
+ raise InvalidHeader
+   else
+ header_value
+diff --git a/test/webrick/test_httpresponse.rb 
b/test/webrick/test_httpresponse.rb
+index 6263e0a..24a6968 100644
+--- a/test/webrick/test_httpresponse.rb
 b/test/webrick/test_httpresponse.rb
+@@ -29,7 +29,7 @@ def setup
+   @res.keep_alive  = true
+ end
+
+-def test_prevent_response_splitting_headers
++def test_prevent_response_splitting_headers_crlf
+   res['X-header'] = "malicious\r\nCookie: hack"
+   io = StringIO.new
+   res.send_response io
+@@ -39,7 +39,7 @@ def test_prevent_response_splitting_headers
+   refute_match 'hack', io.string
+ end
+
+-def test_prevent_response_splitting_cookie_headers
++def test_prevent_response_splitting_cookie_headers_crlf
+   user_input = "malicious\r\nCookie: hack"
+   res.cookies << WEBrick::Cookie.new('author', user_input)
+   io = StringIO.new
+@@ -50,6 +50,48 @@ def test_prevent_response_splitting_cookie_headers
+   refute_match 'hack', io.string
+ end
+
++def test_prevent_response_splitting_headers_cr
++  res['X-header'] = "malicious\rCookie: hack"
++  io = StringIO.new
++  res.send_response io
++  io.rewind
++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
++  assert_equal '500', res.code
++  refute_match 'hack', io.string
++end
++
++def test_prevent_response_splitting_cookie_headers_cr
++  user_input = "malicious\rCookie: hack"
++  res.cookies << WEBrick::Cookie.new('author', user_input)
++  io = StringIO.new
++  res.send_response io
++  io.rewind
++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
++  assert_equal '500', res.code
++  refute_match 'hack', io.string
++end
++
++def test_prevent_response_splitting_headers_lf
++  res['X-header'] = "malicious\nCookie: hack"
++  io = StringIO.new
++  res.send_response io
++  io.rewind
++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
++  assert_equal '500', res.code
++  refute_match 'hack', io.string
++end
++
++def test_prevent_response_splitting_cookie_headers_lf
++  user_input = "malicious\nCookie: hack"
++  res.cookies << WEBrick::Cookie.new('author', user_input)
++  io = StringIO.new
++  res.send_response io
++  io.rewind
++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
++  assert_equal '500', res.code
++  refute_match 'hack', io.string
++end
++
+ def test_304_does_not_log_warning
+   res.status  = 304
+   res.setup_header
+--
+2.7.4
diff --git a/meta/recipes-devtools/ruby/ruby_2.5.5.bb 
b/meta/recipes-devtools/ruby/ruby_2.5.5.bb
index 223b037..58bb97f 100644
--- a/meta/recipes-devtools/ruby/ruby_2.5.5.bb
+++ b/meta/recipes-devtools/ruby/ruby_2.5.5.bb
@@ -3,6 +3,7 @@ require ruby.inc
 SRC_URI += " \

file://0001-configure.ac-check-finite-isinf-isnan-as-macros-firs.patch \
file://run-ptest \
+   file://fix-CVE-2019-16254.patch \
"
 
 SRC_URI[md5sum] = "7e156fb526b8f4bb1b30a3dd8a7ce400"
-- 
2.7.4

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

Re: [OE-core] [PATCH] ruby: fix CVE-2019-16254

[rahul chauhan]

Ok, thanks.

On Tue, Feb 11, 2020 at 7:04 PM Alexander Kanavin 
wrote:

> Either way is fine.
>
> Alex
>
> On Tue, 11 Feb 2020 at 14:28, rahul chauhan 
> wrote:
>
>> Thanks Alexander,
>>
>> For quick response,
>> should i resubmit this patch with --subject-prefix="zeus][PATCH"
>> or
>> should i submit the next patch version.
>>
>> On Tue, Feb 11, 2020 at 6:45 PM Alexander Kanavin 
>> wrote:
>>
>>> Yes. You should always specify the target branch in the subject if it is
>>> not for master.
>>>
>>> Alex
>>>
>>> On Tue, 11 Feb 2020 at 14:06, rahul chauhan 
>>> wrote:
>>>
 Hi community members,

 This patch Fixes CVE-2019-16254 on zeus branch.
 patch test failed, since I did not use --subject-prefix="zeus][PATCH"
 at the time of patch submission to
 openembedded-core@lists.openembedded.org.

 should i resubmit this patch with --subject-prefix="zeus][PATCH"
 or
 can anyone guide me what should do next in  this situation ?

 Thanks & Regards
 Rahul Chauhan

 On Mon, Feb 10, 2020 at 11:47 PM Rahul Chauhan <
 rahulchauhanki...@gmail.com> wrote:

> Signed-off-by: Rahul Chauhan 
> ---
>  .../ruby/ruby/fix-CVE-2019-16254.patch | 106
> +
>  meta/recipes-devtools/ruby/ruby_2.5.5.bb   |   1 +
>  2 files changed, 107 insertions(+)
>  create mode 100644
> meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>
> diff --git a/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
> b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
> new file mode 100644
> index 000..704c850
> --- /dev/null
> +++ b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
> @@ -0,0 +1,106 @@
> +From 18d5289b4579822e391b3f5c16541e6552e9f06c Mon Sep 17 00:00:00 2001
> +From: Yusuke Endoh 
> +Date: Tue, 1 Oct 2019 12:29:18 +0900
> +Subject: [PATCH] WEBrick: prevent response splitting and header
> injection
> +
> +This is a follow up to d9d4a28f1cdd05a0e8dabb36d747d40bbcc30f16.
> +The commit prevented CRLR, but did not address an isolated CR or an
> +isolated LF.
> +
> +Upstream-Status: Backport
> https://github.com/ruby/ruby/commit/3ce238b5f9795581eb84114dcfbdf4aa086bfecc
> +CVE: CVE-2019-16254
> +
> +Co-Authored-By: NARUSE, Yui 
> +Signed-off-by: Rahul Chauhan 
> +---
> + lib/webrick/httpresponse.rb   |  3 ++-
> + test/webrick/test_httpresponse.rb | 46
> +--
> + 2 files changed, 46 insertions(+), 3 deletions(-)
> +
> +diff --git a/lib/webrick/httpresponse.rb b/lib/webrick/httpresponse.rb
> +index 6d77692..d26324c 100644
> +--- a/lib/webrick/httpresponse.rb
>  b/lib/webrick/httpresponse.rb
> +@@ -367,7 +367,8 @@ def set_error(ex, backtrace=false)
> + private
> +
> + def check_header(header_value)
> +-  if header_value =~ /\r\n/
> ++  header_value = header_value.to_s
> ++  if /[\r\n]/ =~ header_value
> + raise InvalidHeader
> +   else
> + header_value
> +diff --git a/test/webrick/test_httpresponse.rb
> b/test/webrick/test_httpresponse.rb
> +index 6263e0a..24a6968 100644
> +--- a/test/webrick/test_httpresponse.rb
>  b/test/webrick/test_httpresponse.rb
> +@@ -29,7 +29,7 @@ def setup
> +   @res.keep_alive  = true
> + end
> +
> +-def test_prevent_response_splitting_headers
> ++def test_prevent_response_splitting_headers_crlf
> +   res['X-header'] = "malicious\r\nCookie: hack"
> +   io = StringIO.new
> +   res.send_response io
> +@@ -39,7 +39,7 @@ def test_prevent_response_splitting_headers
> +   refute_match 'hack', io.string
> + end
> +
> +-def test_prevent_response_splitting_cookie_headers
> ++def test_prevent_response_splitting_cookie_headers_crlf
> +   user_input = "malicious\r\nCookie: hack"
> +   res.cookies << WEBrick::Cookie.new('author', user_input)
> +   io = StringIO.new
> +@@ -50,6 +50,48 @@ def test_prevent_response_splitting_cookie_headers
> +   refute_match 'hack', io.string
> + end
> +
> ++def test_prevent_response_splitting_headers_cr
> ++  res['X-header'] = "malicious\rCookie: hack"
> ++  io = StringIO.new
> ++  res.send_response io
> ++  io.rewind
> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
> ++  assert_equal '500', res.code
> ++  refute_match 'hack', io.string
> ++end
> ++
> ++def test_prevent_response_splitting_cookie_headers_cr
> ++  user_input = "malicious\rCookie: hack"
> ++  res.cookies << WEBrick::Cookie.new('author', user_input)
> ++  io = StringIO.new
> ++  res.send_response io
> ++  io.rewind

Re: [OE-core] [PATCH] ruby: fix CVE-2019-16254

[Alexander Kanavin]

Either way is fine.

Alex

On Tue, 11 Feb 2020 at 14:28, rahul chauhan 
wrote:

> Thanks Alexander,
>
> For quick response,
> should i resubmit this patch with --subject-prefix="zeus][PATCH"
> or
> should i submit the next patch version.
>
> On Tue, Feb 11, 2020 at 6:45 PM Alexander Kanavin 
> wrote:
>
>> Yes. You should always specify the target branch in the subject if it is
>> not for master.
>>
>> Alex
>>
>> On Tue, 11 Feb 2020 at 14:06, rahul chauhan 
>> wrote:
>>
>>> Hi community members,
>>>
>>> This patch Fixes CVE-2019-16254 on zeus branch.
>>> patch test failed, since I did not use --subject-prefix="zeus][PATCH" at
>>> the time of patch submission to openembedded-core@lists.openembedded.org
>>> .
>>>
>>> should i resubmit this patch with --subject-prefix="zeus][PATCH"
>>> or
>>> can anyone guide me what should do next in  this situation ?
>>>
>>> Thanks & Regards
>>> Rahul Chauhan
>>>
>>> On Mon, Feb 10, 2020 at 11:47 PM Rahul Chauhan <
>>> rahulchauhanki...@gmail.com> wrote:
>>>
 Signed-off-by: Rahul Chauhan 
 ---
  .../ruby/ruby/fix-CVE-2019-16254.patch | 106
 +
  meta/recipes-devtools/ruby/ruby_2.5.5.bb   |   1 +
  2 files changed, 107 insertions(+)
  create mode 100644
 meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch

 diff --git a/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
 b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
 new file mode 100644
 index 000..704c850
 --- /dev/null
 +++ b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
 @@ -0,0 +1,106 @@
 +From 18d5289b4579822e391b3f5c16541e6552e9f06c Mon Sep 17 00:00:00 2001
 +From: Yusuke Endoh 
 +Date: Tue, 1 Oct 2019 12:29:18 +0900
 +Subject: [PATCH] WEBrick: prevent response splitting and header
 injection
 +
 +This is a follow up to d9d4a28f1cdd05a0e8dabb36d747d40bbcc30f16.
 +The commit prevented CRLR, but did not address an isolated CR or an
 +isolated LF.
 +
 +Upstream-Status: Backport
 https://github.com/ruby/ruby/commit/3ce238b5f9795581eb84114dcfbdf4aa086bfecc
 +CVE: CVE-2019-16254
 +
 +Co-Authored-By: NARUSE, Yui 
 +Signed-off-by: Rahul Chauhan 
 +---
 + lib/webrick/httpresponse.rb   |  3 ++-
 + test/webrick/test_httpresponse.rb | 46
 +--
 + 2 files changed, 46 insertions(+), 3 deletions(-)
 +
 +diff --git a/lib/webrick/httpresponse.rb b/lib/webrick/httpresponse.rb
 +index 6d77692..d26324c 100644
 +--- a/lib/webrick/httpresponse.rb
  b/lib/webrick/httpresponse.rb
 +@@ -367,7 +367,8 @@ def set_error(ex, backtrace=false)
 + private
 +
 + def check_header(header_value)
 +-  if header_value =~ /\r\n/
 ++  header_value = header_value.to_s
 ++  if /[\r\n]/ =~ header_value
 + raise InvalidHeader
 +   else
 + header_value
 +diff --git a/test/webrick/test_httpresponse.rb
 b/test/webrick/test_httpresponse.rb
 +index 6263e0a..24a6968 100644
 +--- a/test/webrick/test_httpresponse.rb
  b/test/webrick/test_httpresponse.rb
 +@@ -29,7 +29,7 @@ def setup
 +   @res.keep_alive  = true
 + end
 +
 +-def test_prevent_response_splitting_headers
 ++def test_prevent_response_splitting_headers_crlf
 +   res['X-header'] = "malicious\r\nCookie: hack"
 +   io = StringIO.new
 +   res.send_response io
 +@@ -39,7 +39,7 @@ def test_prevent_response_splitting_headers
 +   refute_match 'hack', io.string
 + end
 +
 +-def test_prevent_response_splitting_cookie_headers
 ++def test_prevent_response_splitting_cookie_headers_crlf
 +   user_input = "malicious\r\nCookie: hack"
 +   res.cookies << WEBrick::Cookie.new('author', user_input)
 +   io = StringIO.new
 +@@ -50,6 +50,48 @@ def test_prevent_response_splitting_cookie_headers
 +   refute_match 'hack', io.string
 + end
 +
 ++def test_prevent_response_splitting_headers_cr
 ++  res['X-header'] = "malicious\rCookie: hack"
 ++  io = StringIO.new
 ++  res.send_response io
 ++  io.rewind
 ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
 ++  assert_equal '500', res.code
 ++  refute_match 'hack', io.string
 ++end
 ++
 ++def test_prevent_response_splitting_cookie_headers_cr
 ++  user_input = "malicious\rCookie: hack"
 ++  res.cookies << WEBrick::Cookie.new('author', user_input)
 ++  io = StringIO.new
 ++  res.send_response io
 ++  io.rewind
 ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
 ++  assert_equal '500', res.code
 ++  refute_match 'hack', io.string
 ++end
 ++
 ++def test_prevent_response

Re: [OE-core] [PATCH] ruby: fix CVE-2019-16254

[rahul chauhan]

Thanks Alexander,

For quick response,
should i resubmit this patch with --subject-prefix="zeus][PATCH"
or
should i submit the next patch version.

On Tue, Feb 11, 2020 at 6:45 PM Alexander Kanavin 
wrote:

> Yes. You should always specify the target branch in the subject if it is
> not for master.
>
> Alex
>
> On Tue, 11 Feb 2020 at 14:06, rahul chauhan 
> wrote:
>
>> Hi community members,
>>
>> This patch Fixes CVE-2019-16254 on zeus branch.
>> patch test failed, since I did not use --subject-prefix="zeus][PATCH" at
>> the time of patch submission to openembedded-core@lists.openembedded.org.
>>
>> should i resubmit this patch with --subject-prefix="zeus][PATCH"
>> or
>> can anyone guide me what should do next in  this situation ?
>>
>> Thanks & Regards
>> Rahul Chauhan
>>
>> On Mon, Feb 10, 2020 at 11:47 PM Rahul Chauhan <
>> rahulchauhanki...@gmail.com> wrote:
>>
>>> Signed-off-by: Rahul Chauhan 
>>> ---
>>>  .../ruby/ruby/fix-CVE-2019-16254.patch | 106
>>> +
>>>  meta/recipes-devtools/ruby/ruby_2.5.5.bb   |   1 +
>>>  2 files changed, 107 insertions(+)
>>>  create mode 100644
>>> meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>>>
>>> diff --git a/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>>> b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>>> new file mode 100644
>>> index 000..704c850
>>> --- /dev/null
>>> +++ b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>>> @@ -0,0 +1,106 @@
>>> +From 18d5289b4579822e391b3f5c16541e6552e9f06c Mon Sep 17 00:00:00 2001
>>> +From: Yusuke Endoh 
>>> +Date: Tue, 1 Oct 2019 12:29:18 +0900
>>> +Subject: [PATCH] WEBrick: prevent response splitting and header
>>> injection
>>> +
>>> +This is a follow up to d9d4a28f1cdd05a0e8dabb36d747d40bbcc30f16.
>>> +The commit prevented CRLR, but did not address an isolated CR or an
>>> +isolated LF.
>>> +
>>> +Upstream-Status: Backport
>>> https://github.com/ruby/ruby/commit/3ce238b5f9795581eb84114dcfbdf4aa086bfecc
>>> +CVE: CVE-2019-16254
>>> +
>>> +Co-Authored-By: NARUSE, Yui 
>>> +Signed-off-by: Rahul Chauhan 
>>> +---
>>> + lib/webrick/httpresponse.rb   |  3 ++-
>>> + test/webrick/test_httpresponse.rb | 46
>>> +--
>>> + 2 files changed, 46 insertions(+), 3 deletions(-)
>>> +
>>> +diff --git a/lib/webrick/httpresponse.rb b/lib/webrick/httpresponse.rb
>>> +index 6d77692..d26324c 100644
>>> +--- a/lib/webrick/httpresponse.rb
>>>  b/lib/webrick/httpresponse.rb
>>> +@@ -367,7 +367,8 @@ def set_error(ex, backtrace=false)
>>> + private
>>> +
>>> + def check_header(header_value)
>>> +-  if header_value =~ /\r\n/
>>> ++  header_value = header_value.to_s
>>> ++  if /[\r\n]/ =~ header_value
>>> + raise InvalidHeader
>>> +   else
>>> + header_value
>>> +diff --git a/test/webrick/test_httpresponse.rb
>>> b/test/webrick/test_httpresponse.rb
>>> +index 6263e0a..24a6968 100644
>>> +--- a/test/webrick/test_httpresponse.rb
>>>  b/test/webrick/test_httpresponse.rb
>>> +@@ -29,7 +29,7 @@ def setup
>>> +   @res.keep_alive  = true
>>> + end
>>> +
>>> +-def test_prevent_response_splitting_headers
>>> ++def test_prevent_response_splitting_headers_crlf
>>> +   res['X-header'] = "malicious\r\nCookie: hack"
>>> +   io = StringIO.new
>>> +   res.send_response io
>>> +@@ -39,7 +39,7 @@ def test_prevent_response_splitting_headers
>>> +   refute_match 'hack', io.string
>>> + end
>>> +
>>> +-def test_prevent_response_splitting_cookie_headers
>>> ++def test_prevent_response_splitting_cookie_headers_crlf
>>> +   user_input = "malicious\r\nCookie: hack"
>>> +   res.cookies << WEBrick::Cookie.new('author', user_input)
>>> +   io = StringIO.new
>>> +@@ -50,6 +50,48 @@ def test_prevent_response_splitting_cookie_headers
>>> +   refute_match 'hack', io.string
>>> + end
>>> +
>>> ++def test_prevent_response_splitting_headers_cr
>>> ++  res['X-header'] = "malicious\rCookie: hack"
>>> ++  io = StringIO.new
>>> ++  res.send_response io
>>> ++  io.rewind
>>> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
>>> ++  assert_equal '500', res.code
>>> ++  refute_match 'hack', io.string
>>> ++end
>>> ++
>>> ++def test_prevent_response_splitting_cookie_headers_cr
>>> ++  user_input = "malicious\rCookie: hack"
>>> ++  res.cookies << WEBrick::Cookie.new('author', user_input)
>>> ++  io = StringIO.new
>>> ++  res.send_response io
>>> ++  io.rewind
>>> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
>>> ++  assert_equal '500', res.code
>>> ++  refute_match 'hack', io.string
>>> ++end
>>> ++
>>> ++def test_prevent_response_splitting_headers_lf
>>> ++  res['X-header'] = "malicious\nCookie: hack"
>>> ++  io = StringIO.new
>>> ++  res.send_response io
>>> ++  io.rewind
>>> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new

Re: [OE-core] [PATCH] ruby: fix CVE-2019-16254

[Alexander Kanavin]

Yes. You should always specify the target branch in the subject if it is
not for master.

Alex

On Tue, 11 Feb 2020 at 14:06, rahul chauhan 
wrote:

> Hi community members,
>
> This patch Fixes CVE-2019-16254 on zeus branch.
> patch test failed, since I did not use --subject-prefix="zeus][PATCH" at
> the time of patch submission to openembedded-core@lists.openembedded.org.
>
> should i resubmit this patch with --subject-prefix="zeus][PATCH"
> or
> can anyone guide me what should do next in  this situation ?
>
> Thanks & Regards
> Rahul Chauhan
>
> On Mon, Feb 10, 2020 at 11:47 PM Rahul Chauhan <
> rahulchauhanki...@gmail.com> wrote:
>
>> Signed-off-by: Rahul Chauhan 
>> ---
>>  .../ruby/ruby/fix-CVE-2019-16254.patch | 106
>> +
>>  meta/recipes-devtools/ruby/ruby_2.5.5.bb   |   1 +
>>  2 files changed, 107 insertions(+)
>>  create mode 100644
>> meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>>
>> diff --git a/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>> b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>> new file mode 100644
>> index 000..704c850
>> --- /dev/null
>> +++ b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>> @@ -0,0 +1,106 @@
>> +From 18d5289b4579822e391b3f5c16541e6552e9f06c Mon Sep 17 00:00:00 2001
>> +From: Yusuke Endoh 
>> +Date: Tue, 1 Oct 2019 12:29:18 +0900
>> +Subject: [PATCH] WEBrick: prevent response splitting and header injection
>> +
>> +This is a follow up to d9d4a28f1cdd05a0e8dabb36d747d40bbcc30f16.
>> +The commit prevented CRLR, but did not address an isolated CR or an
>> +isolated LF.
>> +
>> +Upstream-Status: Backport
>> https://github.com/ruby/ruby/commit/3ce238b5f9795581eb84114dcfbdf4aa086bfecc
>> +CVE: CVE-2019-16254
>> +
>> +Co-Authored-By: NARUSE, Yui 
>> +Signed-off-by: Rahul Chauhan 
>> +---
>> + lib/webrick/httpresponse.rb   |  3 ++-
>> + test/webrick/test_httpresponse.rb | 46
>> +--
>> + 2 files changed, 46 insertions(+), 3 deletions(-)
>> +
>> +diff --git a/lib/webrick/httpresponse.rb b/lib/webrick/httpresponse.rb
>> +index 6d77692..d26324c 100644
>> +--- a/lib/webrick/httpresponse.rb
>>  b/lib/webrick/httpresponse.rb
>> +@@ -367,7 +367,8 @@ def set_error(ex, backtrace=false)
>> + private
>> +
>> + def check_header(header_value)
>> +-  if header_value =~ /\r\n/
>> ++  header_value = header_value.to_s
>> ++  if /[\r\n]/ =~ header_value
>> + raise InvalidHeader
>> +   else
>> + header_value
>> +diff --git a/test/webrick/test_httpresponse.rb
>> b/test/webrick/test_httpresponse.rb
>> +index 6263e0a..24a6968 100644
>> +--- a/test/webrick/test_httpresponse.rb
>>  b/test/webrick/test_httpresponse.rb
>> +@@ -29,7 +29,7 @@ def setup
>> +   @res.keep_alive  = true
>> + end
>> +
>> +-def test_prevent_response_splitting_headers
>> ++def test_prevent_response_splitting_headers_crlf
>> +   res['X-header'] = "malicious\r\nCookie: hack"
>> +   io = StringIO.new
>> +   res.send_response io
>> +@@ -39,7 +39,7 @@ def test_prevent_response_splitting_headers
>> +   refute_match 'hack', io.string
>> + end
>> +
>> +-def test_prevent_response_splitting_cookie_headers
>> ++def test_prevent_response_splitting_cookie_headers_crlf
>> +   user_input = "malicious\r\nCookie: hack"
>> +   res.cookies << WEBrick::Cookie.new('author', user_input)
>> +   io = StringIO.new
>> +@@ -50,6 +50,48 @@ def test_prevent_response_splitting_cookie_headers
>> +   refute_match 'hack', io.string
>> + end
>> +
>> ++def test_prevent_response_splitting_headers_cr
>> ++  res['X-header'] = "malicious\rCookie: hack"
>> ++  io = StringIO.new
>> ++  res.send_response io
>> ++  io.rewind
>> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
>> ++  assert_equal '500', res.code
>> ++  refute_match 'hack', io.string
>> ++end
>> ++
>> ++def test_prevent_response_splitting_cookie_headers_cr
>> ++  user_input = "malicious\rCookie: hack"
>> ++  res.cookies << WEBrick::Cookie.new('author', user_input)
>> ++  io = StringIO.new
>> ++  res.send_response io
>> ++  io.rewind
>> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
>> ++  assert_equal '500', res.code
>> ++  refute_match 'hack', io.string
>> ++end
>> ++
>> ++def test_prevent_response_splitting_headers_lf
>> ++  res['X-header'] = "malicious\nCookie: hack"
>> ++  io = StringIO.new
>> ++  res.send_response io
>> ++  io.rewind
>> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
>> ++  assert_equal '500', res.code
>> ++  refute_match 'hack', io.string
>> ++end
>> ++
>> ++def test_prevent_response_splitting_cookie_headers_lf
>> ++  user_input = "malicious\nCookie: hack"
>> ++  res.cookies << WEBrick::Cookie.new('author', user_input)
>> ++  io = StringIO.new
>> ++  res.send_response

Re: [OE-core] [PATCH] ruby: fix CVE-2019-16254

[rahul chauhan]

Hi community members,

This patch Fixes CVE-2019-16254 on zeus branch.
patch test failed, since I did not use --subject-prefix="zeus][PATCH" at
the time of patch submission to openembedded-core@lists.openembedded.org.

should i resubmit this patch with --subject-prefix="zeus][PATCH"
or
can anyone guide me what should do next in  this situation ?

Thanks & Regards
Rahul Chauhan

On Mon, Feb 10, 2020 at 11:47 PM Rahul Chauhan 
wrote:

> Signed-off-by: Rahul Chauhan 
> ---
>  .../ruby/ruby/fix-CVE-2019-16254.patch | 106
> +
>  meta/recipes-devtools/ruby/ruby_2.5.5.bb   |   1 +
>  2 files changed, 107 insertions(+)
>  create mode 100644
> meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
>
> diff --git a/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
> b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
> new file mode 100644
> index 000..704c850
> --- /dev/null
> +++ b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch
> @@ -0,0 +1,106 @@
> +From 18d5289b4579822e391b3f5c16541e6552e9f06c Mon Sep 17 00:00:00 2001
> +From: Yusuke Endoh 
> +Date: Tue, 1 Oct 2019 12:29:18 +0900
> +Subject: [PATCH] WEBrick: prevent response splitting and header injection
> +
> +This is a follow up to d9d4a28f1cdd05a0e8dabb36d747d40bbcc30f16.
> +The commit prevented CRLR, but did not address an isolated CR or an
> +isolated LF.
> +
> +Upstream-Status: Backport
> https://github.com/ruby/ruby/commit/3ce238b5f9795581eb84114dcfbdf4aa086bfecc
> +CVE: CVE-2019-16254
> +
> +Co-Authored-By: NARUSE, Yui 
> +Signed-off-by: Rahul Chauhan 
> +---
> + lib/webrick/httpresponse.rb   |  3 ++-
> + test/webrick/test_httpresponse.rb | 46
> +--
> + 2 files changed, 46 insertions(+), 3 deletions(-)
> +
> +diff --git a/lib/webrick/httpresponse.rb b/lib/webrick/httpresponse.rb
> +index 6d77692..d26324c 100644
> +--- a/lib/webrick/httpresponse.rb
>  b/lib/webrick/httpresponse.rb
> +@@ -367,7 +367,8 @@ def set_error(ex, backtrace=false)
> + private
> +
> + def check_header(header_value)
> +-  if header_value =~ /\r\n/
> ++  header_value = header_value.to_s
> ++  if /[\r\n]/ =~ header_value
> + raise InvalidHeader
> +   else
> + header_value
> +diff --git a/test/webrick/test_httpresponse.rb
> b/test/webrick/test_httpresponse.rb
> +index 6263e0a..24a6968 100644
> +--- a/test/webrick/test_httpresponse.rb
>  b/test/webrick/test_httpresponse.rb
> +@@ -29,7 +29,7 @@ def setup
> +   @res.keep_alive  = true
> + end
> +
> +-def test_prevent_response_splitting_headers
> ++def test_prevent_response_splitting_headers_crlf
> +   res['X-header'] = "malicious\r\nCookie: hack"
> +   io = StringIO.new
> +   res.send_response io
> +@@ -39,7 +39,7 @@ def test_prevent_response_splitting_headers
> +   refute_match 'hack', io.string
> + end
> +
> +-def test_prevent_response_splitting_cookie_headers
> ++def test_prevent_response_splitting_cookie_headers_crlf
> +   user_input = "malicious\r\nCookie: hack"
> +   res.cookies << WEBrick::Cookie.new('author', user_input)
> +   io = StringIO.new
> +@@ -50,6 +50,48 @@ def test_prevent_response_splitting_cookie_headers
> +   refute_match 'hack', io.string
> + end
> +
> ++def test_prevent_response_splitting_headers_cr
> ++  res['X-header'] = "malicious\rCookie: hack"
> ++  io = StringIO.new
> ++  res.send_response io
> ++  io.rewind
> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
> ++  assert_equal '500', res.code
> ++  refute_match 'hack', io.string
> ++end
> ++
> ++def test_prevent_response_splitting_cookie_headers_cr
> ++  user_input = "malicious\rCookie: hack"
> ++  res.cookies << WEBrick::Cookie.new('author', user_input)
> ++  io = StringIO.new
> ++  res.send_response io
> ++  io.rewind
> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
> ++  assert_equal '500', res.code
> ++  refute_match 'hack', io.string
> ++end
> ++
> ++def test_prevent_response_splitting_headers_lf
> ++  res['X-header'] = "malicious\nCookie: hack"
> ++  io = StringIO.new
> ++  res.send_response io
> ++  io.rewind
> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
> ++  assert_equal '500', res.code
> ++  refute_match 'hack', io.string
> ++end
> ++
> ++def test_prevent_response_splitting_cookie_headers_lf
> ++  user_input = "malicious\nCookie: hack"
> ++  res.cookies << WEBrick::Cookie.new('author', user_input)
> ++  io = StringIO.new
> ++  res.send_response io
> ++  io.rewind
> ++  res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io))
> ++  assert_equal '500', res.code
> ++  refute_match 'hack', io.string
> ++end
> ++
> + def test_304_does_not_log_warning
> +   res.status  = 304
> +   res.setup_header
> +--
> +2.7.4
> diff --git a/

[OE-core] Future of sato and X in oe-core

[Alexander Kanavin]

Hello,

I'd like to lay out a few ideas/thoughts on what should be done with sato
(matchbox bits) and X going forward. The inputs are:

- Red Hat is the only company doing X maintenance anymore, and they're
transitioning it to 'hard maintenance mode'
https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
"Once we are done with this [xwayland gaining missing features] we expect
X.org to go into hard maintenance mode fairly quickly. The reality is that
X.org is basically maintained by us and thus once we stop paying attention
to it there is unlikely to be any major new releases coming out and there
might even be some bitrot setting in over time. We will keep an eye on it
as we will want to ensure X.org stays supportable until the end of the
RHEL8 lifecycle at a minimum, but let this be a friendly notice for
everyone who rely the work we do maintaining the Linux graphics stack, get
onto Wayland, that is where the future is.
"

- matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and does
not have a Wayland compositor. Yocto project does not have the resources to
do the gtk4 port, or add a compositor.

- no 'lightweight Wayland compositor with a desktop/launcher experience"
has emerged in the open source space; I think the only realistic choice at
the moment is the reference compositor Weston which provides a blank
desktop with ability to open terminal windows.

So the way I think things should be going (seeking opinions/inputs of
course):

- oe-core adopts Weston as the 'new sato'; all sato images that currently
pull in matchbox and friends are changed to be Weston-based. Note that
there is no requirement for 3D acceleration; Weston works with plain frame
buffer device. However, both options should be supported and tested. Also,
support for Xwayland should be tested.

- oe-core continues to support and runtime-test X for as long as possible;
for this a new image (say, 'core-image-sato-xorg') is created which will
provide matchbox under X. However, once upstream bitrot sets in, and pain
threshold is exceeded, this will be removed and/or relegated to a legacy
layer.

Thoughts?

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