[PATCH 01/10] core-image-sato-sdk-ptest: do not pull in ptest-pkgs

[PATCH 01/10] core-image-sato-sdk-ptest: do not pull in ptest-pkgs

[Alexander Kanavin]

The lists of ptests are defined via PTESTS_FAST and PTESTS_SLOW;
specifying 'ptests-pkgs' also pulls in additional ptests that
are specifically excluded from those lists due to causing issues with
ptesting. (particularly bash-ptest is one such item)

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
index 85b5adbc69..58c257c49f 100644
--- a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
+++ b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
@@ -3,8 +3,6 @@ require conf/distro/include/ptest-packagelists.inc
 
 DESCRIPTION += "Also includes ptest packages."
 
-IMAGE_FEATURES += "ptest-pkgs"
-
 PROVIDES += "core-image-sato-ptest"
 
 # Also include ptests which may not otherwise be included in a sato image
-- 
2.25.0

[PATCH 02/10] procps: upstream has switched to gitlab

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-extended/procps/procps_3.3.16.bb | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-extended/procps/procps_3.3.16.bb b/meta/recipes-extended/procps/procps_3.3.16.bb
index 60f90976bb..2810ebd285 100644
--- a/meta/recipes-extended/procps/procps_3.3.16.bb
+++ b/meta/recipes-extended/procps/procps_3.3.16.bb
@@ -12,14 +12,19 @@ DEPENDS = "ncurses"
 
 inherit autotools gettext pkgconfig update-alternatives
 
-SRC_URI = "http://downloads.sourceforge.net/project/procps-ng/Production/procps-ng-${PV}.tar.xz \
+SRC_URI = "git://gitlab.com/procps-ng/procps.git;protocol=https \
            file://sysctl.conf \
            "
+SRCREV = "59c88e18f29000ceaf7e5f98181b07be443cf12f"
 
-SRC_URI[md5sum] = "e8dc8455e573bdc40b8381d572bbb89b"
-SRC_URI[sha256sum] = "925eacd65dedcf9c98eb94e8978bbfb63f5de37294cc1047d81462ed477a20af"
+S = "${WORKDIR}/git"
 
-S = "${WORKDIR}/procps-ng-${PV}"
+# Upstream has a custom autogen.sh which invokes po/update-potfiles as they
+# don't ship a po/POTFILES.in (which is silly).  Without that file gettext
+# doesn't believe po/ is a gettext directory and won't generate po/Makefile.
+do_configure_prepend() {
+    ( cd ${S} && po/update-potfiles )
+}
 
 EXTRA_OECONF = "--enable-skill --disable-modern-top"
 
-- 
2.25.0

[PATCH 03/10] qemux86: do not add vga=0 to kernel parameters

[Alexander Kanavin]

This was added ages ago to enable GL passthrough with
vmware driver, and is no longer relevant, as std or virgl is used
instead nowadays.

Original commit:

commit 072545b1111c5efb66289a4866897429f5fcd969
Author: Richard Purdie <rpurdie@linux.intel.com>
Date:   Wed Jan 21 17:40:51 2009 +0000

    scripts/poky-qemu-internal: Add support for GL passthrough in qemux86 images

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/conf/machine/include/qemuboot-x86.inc        | 2 +-
 scripts/lib/wic/canned-wks/qemux86-directdisk.wks | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-x86.inc b/meta/conf/machine/include/qemuboot-x86.inc
index 495418fa04..049681b27d 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -8,7 +8,7 @@ QB_CPU_KVM_x86-64 = "-cpu core2duo"
 
 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"
-QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=${UVESA_MODE} oprofile.timer=1 uvesafb.task_timeout=-1"
+QB_KERNEL_CMDLINE_APPEND = "uvesafb.mode_option=${UVESA_MODE} oprofile.timer=1 uvesafb.task_timeout=-1"
 QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0"
diff --git a/scripts/lib/wic/canned-wks/qemux86-directdisk.wks b/scripts/lib/wic/canned-wks/qemux86-directdisk.wks
index c8d9f121b5..22b45217f1 100644
--- a/scripts/lib/wic/canned-wks/qemux86-directdisk.wks
+++ b/scripts/lib/wic/canned-wks/qemux86-directdisk.wks
@@ -4,5 +4,5 @@
 
 include common.wks.inc
 
-bootloader  --timeout=0  --append="vga=0 rw oprofile.timer=1 rootfstype=ext4 "
+bootloader  --timeout=0  --append="rw oprofile.timer=1 rootfstype=ext4 "
 
-- 
2.25.0

[PATCH 04/10] qemux86: drop resolution setting via uvesafb

[Alexander Kanavin]

I am not sure if this has ever worked, but uvesafb is a really
outdated (VBE from the 1990s), awkward (needs v86d) and limited
(no support for high resolutions) way to do it.

The specific reason 640x480-32 was introduced (ages ago) was
to force 32 bit mode with vmware driver, as 16bit had rendering issues.

The modern, supported option is video=... kernel parameter documented here:
https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID
https://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst
which can be passed directly to runqemu and doesn't require special
kernel modules.

Sato under X will continue to use 640x480 as that is hardcoded into
xorg.conf under qemu.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/conf/machine/include/qemuboot-x86.inc | 3 +--
 meta/conf/machine/qemux86-64.conf          | 4 ----
 meta/conf/machine/qemux86.conf             | 4 ----
 meta/lib/oeqa/runtime/cases/parselogs.py   | 4 ----
 4 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-x86.inc b/meta/conf/machine/include/qemuboot-x86.inc
index 049681b27d..5dcc8b6f6b 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -8,9 +8,8 @@ QB_CPU_KVM_x86-64 = "-cpu core2duo"
 
 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"
-QB_KERNEL_CMDLINE_APPEND = "uvesafb.mode_option=${UVESA_MODE} oprofile.timer=1 uvesafb.task_timeout=-1"
+QB_KERNEL_CMDLINE_APPEND = "oprofile.timer=1"
 QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0"
 
-UVESA_MODE ?= "640x480-32"
diff --git a/meta/conf/machine/qemux86-64.conf b/meta/conf/machine/qemux86-64.conf
index 648cf2fe8f..db9004ee32 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -37,10 +37,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
 
 MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370 kernel-module-snd-rawmidi"
 
-KERNEL_MODULE_AUTOLOAD += "uvesafb"
-KERNEL_MODULE_PROBECONF += "uvesafb"
-module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
-
 WKS_FILE ?= "qemux86-directdisk.wks"
 do_image_wic[depends] += "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
 
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index 8e0da82076..7e6723b880 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -34,10 +34,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
 
 MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370 kernel-module-snd-rawmidi"
 
-KERNEL_MODULE_AUTOLOAD += "uvesafb"
-KERNEL_MODULE_PROBECONF += "uvesafb"
-module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
-
 WKS_FILE ?= "qemux86-directdisk.wks"
 do_image_wic[depends] += "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
 
diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py
index 9dafb89b03..3cad0709a1 100644
--- a/meta/lib/oeqa/runtime/cases/parselogs.py
+++ b/meta/lib/oeqa/runtime/cases/parselogs.py
@@ -60,7 +60,6 @@ common_errors = [
     ]
 
 video_related = [
-    "uvesafb",
 ]
 
 x86_common = [
@@ -82,11 +81,8 @@ qemux86_common = [
     "fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.",
     "can't claim BAR ",
     'amd_nb: Cannot enumerate AMD northbridges',
-    'uvesafb: 5000 ms task timeout, infinitely waiting',
     'tsc: HPET/PMTIMER calibration failed',
     "modeset(0): Failed to initialize the DRI2 extension",
-    "uvesafb: cannot reserve video memory at",
-    "uvesafb: probe of uvesafb.0 failed with error",
     "glamor initialization failed",
 ] + common_errors
 
-- 
2.25.0

[PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

The fbdev backend is not documented, and not the default;
as the emulated hardware in qemu now supports DRM/KMS
(both std and virtio), we should align with upstream default
and vast majority of users.

Note that 3D acceleration is not required; the backend
renders fine via the software driver in mesa.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini | 2 --
 1 file changed, 2 deletions(-)
 delete mode 100644 meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini

diff --git a/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini b/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
deleted file mode 100644
index 17ebd7fdab..0000000000
--- a/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
+++ /dev/null
@@ -1,2 +0,0 @@
-[core]
-backend=fbdev-backend.so
-- 
2.25.0

[PATCH 06/10] webkitgtk: x11 and wayland are not mutually exclusive

[Alexander Kanavin]

Also enabling wayland if x11 is not enabled is not necessarily
the correct decision.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-sato/webkit/webkitgtk_2.26.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
index c7f0d5e983..4aa8533b42 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
@@ -38,7 +38,7 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt libidn libgcrypt \
 	   gettext-native glib-2.0 glib-2.0-native libtasn1 \
           "
 
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'wayland' ,d)} \
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl opengl', '' ,d)} \
                    enchant \
                    libsecret \
-- 
2.25.0

[PATCH 07/10] weston: add a basic runtime test

[Alexander Kanavin]

The test is checking that weston is able to start.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/classes/testimage.bbclass        |  2 +-
 meta/lib/oeqa/runtime/cases/weston.py | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 meta/lib/oeqa/runtime/cases/weston.py

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 75f0f2c3e3..9588f2c4f8 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -57,7 +57,7 @@ BASICTESTSUITE = "\
     ping date df ssh scp python perl gi ptest parselogs \
     logrotate connman systemd oe_syslog pam stap ldd xorg \
     kernelmodule gcc buildcpio buildlzip buildgalculator \
-    dnf rpm opkg apt"
+    dnf rpm opkg apt weston"
 
 DEFAULT_TEST_SUITES = "${BASICTESTSUITE}"
 
diff --git a/meta/lib/oeqa/runtime/cases/weston.py b/meta/lib/oeqa/runtime/cases/weston.py
new file mode 100644
index 0000000000..f32599afc3
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/weston.py
@@ -0,0 +1,19 @@
+#
+# SPDX-License-Identifier: MIT
+#
+
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.core.decorator.data import skipIfNotFeature
+from oeqa.runtime.decorator.package import OEHasPackage
+
+class WestonTest(OERuntimeTestCase):
+
+    @OETestDepends(['ssh.SSHTest.test_ssh'])
+    @OEHasPackage(['weston'])
+    def test_weston_running(self):
+        cmd ='%s | grep [w]eston-desktop-shell' % self.tc.target_cmds['ps']
+        status, output = self.target.run(cmd)
+        msg = ('Weston does not appear to be running %s' %
+              self.target.run(self.tc.target_cmds['ps'])[1])
+        self.assertEqual(status, 0, msg=msg)
-- 
2.25.0

[PATCH 08/10] webkitgtk: unbreak wayland build

[Alexander Kanavin]

webkit nowadays requires a couple of supplementary libraries for this,
so bring them in (courtesy of meta-browser, which will hopefully
adjust without a lot of trouble).

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-sato/webkit/libwpe_1.4.0.1.bb    | 19 +++++++++++++++++++
 meta/recipes-sato/webkit/webkitgtk_2.26.4.bb  |  2 +-
 .../webkit/wpebackend-fdo_1.4.1.bb            | 19 +++++++++++++++++++
 3 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
 create mode 100644 meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb

diff --git a/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
new file mode 100644
index 0000000000..b9c71f9dc5
--- /dev/null
+++ b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
@@ -0,0 +1,19 @@
+SUMMARY = "General-purpose library specifically developed for the WPE-flavored port of WebKit."
+HOMEPAGE = "https://github.com/WebPlatformForEmbedded/libwpe"
+BUGTRACKER = "https://github.com/WebPlatformForEmbedded/libwpe/issues"
+
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://COPYING;md5=371a616eb4903c6cb79e9893a5f615cc"
+DEPENDS = "virtual/egl libxkbcommon"
+
+# Workaround build issue with RPi userland EGL libraries.
+CFLAGS_append_rpi = " ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', '-D_GNU_SOURCE', d)}"
+
+inherit cmake
+
+SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
+SRC_URI[md5sum] = "1d4d38413ee0d0043f74d0445cab906f"
+SRC_URI[sha256sum] = "09849dfb34877354f34f318e138971cf22e677b2179e1f0a8ea00ab0b7bd8e9b"
+SRC_URI[sha1sum] = "a41480a0a85cfa11b3f87f801b7c37bc3410e060"
+SRC_URI[sha384sum] = "30488e375d956809a84b0d8af7b386a332541c77dcbd53496a896f894dbf39ac34534e935d6bc7a75c1b536f04f7f0a0"
+SRC_URI[sha512sum] = "cbbe6b8e9bbb864d7f96bbdb56db262bbd341c86bc7bedfcc51be8077c0ea58a4e88c61b7b7bec937d5476e6cb81c093229bf80e3ee99452829287bd26175670"
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
index 4aa8533b42..8d87ad49a3 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
@@ -44,7 +44,7 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
                    libsecret \
                   "
 
-PACKAGECONFIG[wayland] = "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland"
+PACKAGECONFIG[wayland] = "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe wpebackend-fdo wayland-native"
 PACKAGECONFIG[x11] = "-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/libx11"
 PACKAGECONFIG[geoclue] = "-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
 PACKAGECONFIG[enchant] = "-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
diff --git a/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
new file mode 100644
index 0000000000..84df0c2535
--- /dev/null
+++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
@@ -0,0 +1,19 @@
+SUMMARY = "WPE's backend based on a freedesktop.org stack."
+HOMEPAGE = "https://github.com/Igalia/WPEBackend-fdo"
+BUGTRACKER = "https://github.com/Igalia/WPEBackend-fdo/issues"
+
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://COPYING;md5=1f62cef2e3645e3e74eb05fd389d7a66"
+DEPENDS = "glib-2.0 libxkbcommon wayland virtual/egl libwpe"
+
+DEPENDS_append_class-target = " wayland-native"
+
+inherit cmake
+
+SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
+SRC_URI[md5sum] = "c6362491a4a38ddac42b66f140e1cff2"
+SRC_URI[sha256sum] = "6249a0b7cbfa662206a8d2fa24e2c574e75c681ad0e93468091f1dc68ddb299d"
+SRC_URI[sha1sum] = "9217c8a5511bc53544b42cb23390256580ac4b0c"
+SRC_URI[sha384sum] = "79f3a28bc8e0a8240dc9962a6a245276d39dd8112a753d5ada39e98332d857eb9fc9c2879a702060807a10ea60be796d"
+SRC_URI[sha512sum] = "8fdd13843c77b95b96b3feffea463bce565620997680e209a0cdcc09314a1469f2f1cb4744dceb2cf6c8d6ce5cb2bbdb4c7fbaf0451a687640c3f63bbdbfc4d4"
+
-- 
2.25.0

[PATCH 09/10] wayland: convert to meson build

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 ...-the-native-wayland-scanner-directly.patch | 27 +++++++++++++++++++
 .../wayland/wayland_1.18.0.bb                 |  9 ++++---
 2 files changed, 32 insertions(+), 4 deletions(-)
 create mode 100644 meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch

diff --git a/meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch b/meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch
new file mode 100644
index 0000000000..f98037a850
--- /dev/null
+++ b/meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch
@@ -0,0 +1,27 @@
+From 2582d2653ba80917d7bc47088e1a5f49530fddaa Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin <alex.kanavin@gmail.com>
+Date: Sun, 16 Feb 2020 16:29:53 +0100
+Subject: [PATCH] meson.build: find the native wayland-scanner directly in PATH
+
+Otherwise, meson attempts to use the target pkg-config and fails.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
+---
+ src/meson.build | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/src/meson.build b/src/meson.build
+index 3e8c9bf..294aee0 100644
+--- a/src/meson.build
++++ b/src/meson.build
+@@ -55,8 +55,7 @@ pkgconfig.generate(
+ )
+ 
+ if meson.is_cross_build()
+-	scanner_dep = dependency('wayland-scanner', native: true, version: '>=1.14.0')
+-	wayland_scanner_for_build = find_program(scanner_dep.get_pkgconfig_variable('wayland_scanner'))
++	wayland_scanner_for_build = find_program('wayland-scanner')
+ else
+ 	wayland_scanner_for_build = wayland_scanner
+ endif
diff --git a/meta/recipes-graphics/wayland/wayland_1.18.0.bb b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
index 7a3f075552..21a848ff5a 100644
--- a/meta/recipes-graphics/wayland/wayland_1.18.0.bb
+++ b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
@@ -14,19 +14,20 @@ DEPENDS = "expat libffi wayland-native"
 
 SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
            file://fixpathinpcfiles.patch \
+           file://0002-meson.build-find-the-native-wayland-scanner-directly.patch \
            "
 SRC_URI[md5sum] = "23317697b6e3ff2e1ac8c5ba3ed57b65"
 SRC_URI[sha256sum] = "4675a79f091020817a98fd0484e7208c8762242266967f55a67776936c2e294d"
 
 UPSTREAM_CHECK_URI = "https://wayland.freedesktop.org/releases.html"
 
-inherit autotools pkgconfig
+inherit meson pkgconfig
 
 PACKAGECONFIG ??= "dtd-validation"
-PACKAGECONFIG[dtd-validation] = "--enable-dtd-validation,--disable-dtd-validation,libxml2,,"
+PACKAGECONFIG[dtd-validation] = "-Ddtd_validation=true,-Ddtd_validation=false,libxml2,,"
 
-EXTRA_OECONF = "--disable-documentation --with-host-scanner"
-EXTRA_OECONF_class-native = "--disable-documentation --disable-libraries"
+EXTRA_OEMESON = "-Ddocumentation=false"
+EXTRA_OECONF_class-native = "-Ddocumentation=false -Dlibraries=false"
 
 # Wayland installs a M4 macro for other projects to use, which uses the target
 # pkg-config to find files.  Replace pkg-config with pkg-config-native.
-- 
2.25.0

[PATCH 10/10] ptest-packagelists: mention ifupdown ptest in a comment

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/conf/distro/include/ptest-packagelists.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/ptest-packagelists.inc b/meta/conf/distro/include/ptest-packagelists.inc
index 0a13bf0a6c..23865ac3e1 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -57,6 +57,7 @@ PTESTS_FAST = "\
 #    lz4-ptest \ # Needs a rewrite
 #    rt-tests-ptest \ # Needs to be checked whether it runs at all
 #    bash-ptest \ # Test outcomes are non-deterministic by design
+#    ifupdown-ptest \ # Tested separately in lib/oeqa/selftest/cases/imagefeatures.py
 #"
 
 PTESTS_SLOW = "\
-- 
2.25.0

Re: [PATCH 04/10] qemux86: drop resolution setting via uvesafb

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 4784 bytes --]

Why you think it doesn't support higher resolution? We were using it with
fullHD in VirtualBox until recently.

On Sun, Feb 16, 2020 at 4:52 PM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> I am not sure if this has ever worked, but uvesafb is a really
> outdated (VBE from the 1990s), awkward (needs v86d) and limited
> (no support for high resolutions) way to do it.
>
> The specific reason 640x480-32 was introduced (ages ago) was
> to force 32 bit mode with vmware driver, as 16bit had rendering issues.
>
> The modern, supported option is video=... kernel parameter documented here:
>
> https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID
> https://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst
> which can be passed directly to runqemu and doesn't require special
> kernel modules.
>
> Sato under X will continue to use 640x480 as that is hardcoded into
> xorg.conf under qemu.
>
> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
>  meta/conf/machine/include/qemuboot-x86.inc | 3 +--
>  meta/conf/machine/qemux86-64.conf          | 4 ----
>  meta/conf/machine/qemux86.conf             | 4 ----
>  meta/lib/oeqa/runtime/cases/parselogs.py   | 4 ----
>  4 files changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/meta/conf/machine/include/qemuboot-x86.inc
> b/meta/conf/machine/include/qemuboot-x86.inc
> index 049681b27d..5dcc8b6f6b 100644
> --- a/meta/conf/machine/include/qemuboot-x86.inc
> +++ b/meta/conf/machine/include/qemuboot-x86.inc
> @@ -8,9 +8,8 @@ QB_CPU_KVM_x86-64 = "-cpu core2duo"
>
>  QB_AUDIO_DRV = "alsa"
>  QB_AUDIO_OPT = "-soundhw ac97,es1370"
> -QB_KERNEL_CMDLINE_APPEND = "uvesafb.mode_option=${UVESA_MODE}
> oprofile.timer=1 uvesafb.task_timeout=-1"
> +QB_KERNEL_CMDLINE_APPEND = "oprofile.timer=1"
>  QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
>  # Add the 'virtio-rng-pci' device otherwise the guest may run out of
> entropy
>  QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0
> -device virtio-rng-pci,rng=rng0"
>
> -UVESA_MODE ?= "640x480-32"
> diff --git a/meta/conf/machine/qemux86-64.conf
> b/meta/conf/machine/qemux86-64.conf
> index 648cf2fe8f..db9004ee32 100644
> --- a/meta/conf/machine/qemux86-64.conf
> +++ b/meta/conf/machine/qemux86-64.conf
> @@ -37,10 +37,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>
>  MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370
> kernel-module-snd-rawmidi"
>
> -KERNEL_MODULE_AUTOLOAD += "uvesafb"
> -KERNEL_MODULE_PROBECONF += "uvesafb"
> -module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
> -
>  WKS_FILE ?= "qemux86-directdisk.wks"
>  do_image_wic[depends] += "syslinux:do_populate_sysroot
> syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot
> dosfstools-native:do_populate_sysroot"
>
> diff --git a/meta/conf/machine/qemux86.conf
> b/meta/conf/machine/qemux86.conf
> index 8e0da82076..7e6723b880 100644
> --- a/meta/conf/machine/qemux86.conf
> +++ b/meta/conf/machine/qemux86.conf
> @@ -34,10 +34,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>
>  MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370
> kernel-module-snd-rawmidi"
>
> -KERNEL_MODULE_AUTOLOAD += "uvesafb"
> -KERNEL_MODULE_PROBECONF += "uvesafb"
> -module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
> -
>  WKS_FILE ?= "qemux86-directdisk.wks"
>  do_image_wic[depends] += "syslinux:do_populate_sysroot
> syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot
> dosfstools-native:do_populate_sysroot"
>
> diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py
> b/meta/lib/oeqa/runtime/cases/parselogs.py
> index 9dafb89b03..3cad0709a1 100644
> --- a/meta/lib/oeqa/runtime/cases/parselogs.py
> +++ b/meta/lib/oeqa/runtime/cases/parselogs.py
> @@ -60,7 +60,6 @@ common_errors = [
>      ]
>
>  video_related = [
> -    "uvesafb",
>  ]
>
>  x86_common = [
> @@ -82,11 +81,8 @@ qemux86_common = [
>      "fail to add MMCONFIG information, can't access extended PCI
> configuration space under this bridge.",
>      "can't claim BAR ",
>      'amd_nb: Cannot enumerate AMD northbridges',
> -    'uvesafb: 5000 ms task timeout, infinitely waiting',
>      'tsc: HPET/PMTIMER calibration failed',
>      "modeset(0): Failed to initialize the DRI2 extension",
> -    "uvesafb: cannot reserve video memory at",
> -    "uvesafb: probe of uvesafb.0 failed with error",
>      "glamor initialization failed",
>  ] + common_errors
>
> --
> 2.25.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 6138 bytes --]

Re: [PATCH 08/10] webkitgtk: unbreak wayland build

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 4683 bytes --]

Do we need sha384sum, sha512sum, sha1sum checksums for these 2 for whatever
reason?

On Sun, Feb 16, 2020 at 4:52 PM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> webkit nowadays requires a couple of supplementary libraries for this,
> so bring them in (courtesy of meta-browser, which will hopefully
> adjust without a lot of trouble).
>
> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
>  meta/recipes-sato/webkit/libwpe_1.4.0.1.bb    | 19 +++++++++++++++++++
>  meta/recipes-sato/webkit/webkitgtk_2.26.4.bb  |  2 +-
>  .../webkit/wpebackend-fdo_1.4.1.bb            | 19 +++++++++++++++++++
>  3 files changed, 39 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>  create mode 100644 meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>
> diff --git a/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> new file mode 100644
> index 0000000000..b9c71f9dc5
> --- /dev/null
> +++ b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> @@ -0,0 +1,19 @@
> +SUMMARY = "General-purpose library specifically developed for the
> WPE-flavored port of WebKit."
> +HOMEPAGE = "https://github.com/WebPlatformForEmbedded/libwpe"
> +BUGTRACKER = "https://github.com/WebPlatformForEmbedded/libwpe/issues"
> +
> +LICENSE = "BSD"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=371a616eb4903c6cb79e9893a5f615cc"
> +DEPENDS = "virtual/egl libxkbcommon"
> +
> +# Workaround build issue with RPi userland EGL libraries.
> +CFLAGS_append_rpi = " ${@bb.utils.contains('MACHINE_FEATURES',
> 'vc4graphics', '', '-D_GNU_SOURCE', d)}"
> +
> +inherit cmake
> +
> +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
> +SRC_URI[md5sum] = "1d4d38413ee0d0043f74d0445cab906f"
> +SRC_URI[sha256sum] =
> "09849dfb34877354f34f318e138971cf22e677b2179e1f0a8ea00ab0b7bd8e9b"
> +SRC_URI[sha1sum] = "a41480a0a85cfa11b3f87f801b7c37bc3410e060"
> +SRC_URI[sha384sum] =
> "30488e375d956809a84b0d8af7b386a332541c77dcbd53496a896f894dbf39ac34534e935d6bc7a75c1b536f04f7f0a0"
> +SRC_URI[sha512sum] =
> "cbbe6b8e9bbb864d7f96bbdb56db262bbd341c86bc7bedfcc51be8077c0ea58a4e88c61b7b7bec937d5476e6cb81c093229bf80e3ee99452829287bd26175670"
> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> index 4aa8533b42..8d87ad49a3 100644
> --- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> +++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> @@ -44,7 +44,7 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES',
> 'wayland x11', d)} \
>                     libsecret \
>                    "
>
> -PACKAGECONFIG[wayland] =
> "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland"
> +PACKAGECONFIG[wayland] =
> "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe
> wpebackend-fdo wayland-native"
>  PACKAGECONFIG[x11] =
> "-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/libx11"
>  PACKAGECONFIG[geoclue] =
> "-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
>  PACKAGECONFIG[enchant] =
> "-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
> diff --git a/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> new file mode 100644
> index 0000000000..84df0c2535
> --- /dev/null
> +++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> @@ -0,0 +1,19 @@
> +SUMMARY = "WPE's backend based on a freedesktop.org stack."
> +HOMEPAGE = "https://github.com/Igalia/WPEBackend-fdo"
> +BUGTRACKER = "https://github.com/Igalia/WPEBackend-fdo/issues"
> +
> +LICENSE = "BSD"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=1f62cef2e3645e3e74eb05fd389d7a66"
> +DEPENDS = "glib-2.0 libxkbcommon wayland virtual/egl libwpe"
> +
> +DEPENDS_append_class-target = " wayland-native"
> +
> +inherit cmake
> +
> +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
> +SRC_URI[md5sum] = "c6362491a4a38ddac42b66f140e1cff2"
> +SRC_URI[sha256sum] =
> "6249a0b7cbfa662206a8d2fa24e2c574e75c681ad0e93468091f1dc68ddb299d"
> +SRC_URI[sha1sum] = "9217c8a5511bc53544b42cb23390256580ac4b0c"
> +SRC_URI[sha384sum] =
> "79f3a28bc8e0a8240dc9962a6a245276d39dd8112a753d5ada39e98332d857eb9fc9c2879a702060807a10ea60be796d"
> +SRC_URI[sha512sum] =
> "8fdd13843c77b95b96b3feffea463bce565620997680e209a0cdcc09314a1469f2f1cb4744dceb2cf6c8d6ce5cb2bbdb4c7fbaf0451a687640c3f63bbdbfc4d4"
> +
> --
> 2.25.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 7527 bytes --]

Re: [PATCH 04/10] qemux86: drop resolution setting via uvesafb

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 5038 bytes --]

What about higher than fullHD?

Alex

On Sun, 16 Feb 2020 at 17:01, Martin Jansa <martin.jansa@gmail.com> wrote:

> Why you think it doesn't support higher resolution? We were using it with
> fullHD in VirtualBox until recently.
>
> On Sun, Feb 16, 2020 at 4:52 PM Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
>
>> I am not sure if this has ever worked, but uvesafb is a really
>> outdated (VBE from the 1990s), awkward (needs v86d) and limited
>> (no support for high resolutions) way to do it.
>>
>> The specific reason 640x480-32 was introduced (ages ago) was
>> to force 32 bit mode with vmware driver, as 16bit had rendering issues.
>>
>> The modern, supported option is video=... kernel parameter documented
>> here:
>>
>> https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID
>> https://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst
>> which can be passed directly to runqemu and doesn't require special
>> kernel modules.
>>
>> Sato under X will continue to use 640x480 as that is hardcoded into
>> xorg.conf under qemu.
>>
>> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
>> ---
>>  meta/conf/machine/include/qemuboot-x86.inc | 3 +--
>>  meta/conf/machine/qemux86-64.conf          | 4 ----
>>  meta/conf/machine/qemux86.conf             | 4 ----
>>  meta/lib/oeqa/runtime/cases/parselogs.py   | 4 ----
>>  4 files changed, 1 insertion(+), 14 deletions(-)
>>
>> diff --git a/meta/conf/machine/include/qemuboot-x86.inc
>> b/meta/conf/machine/include/qemuboot-x86.inc
>> index 049681b27d..5dcc8b6f6b 100644
>> --- a/meta/conf/machine/include/qemuboot-x86.inc
>> +++ b/meta/conf/machine/include/qemuboot-x86.inc
>> @@ -8,9 +8,8 @@ QB_CPU_KVM_x86-64 = "-cpu core2duo"
>>
>>  QB_AUDIO_DRV = "alsa"
>>  QB_AUDIO_OPT = "-soundhw ac97,es1370"
>> -QB_KERNEL_CMDLINE_APPEND = "uvesafb.mode_option=${UVESA_MODE}
>> oprofile.timer=1 uvesafb.task_timeout=-1"
>> +QB_KERNEL_CMDLINE_APPEND = "oprofile.timer=1"
>>  QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
>>  # Add the 'virtio-rng-pci' device otherwise the guest may run out of
>> entropy
>>  QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0
>> -device virtio-rng-pci,rng=rng0"
>>
>> -UVESA_MODE ?= "640x480-32"
>> diff --git a/meta/conf/machine/qemux86-64.conf
>> b/meta/conf/machine/qemux86-64.conf
>> index 648cf2fe8f..db9004ee32 100644
>> --- a/meta/conf/machine/qemux86-64.conf
>> +++ b/meta/conf/machine/qemux86-64.conf
>> @@ -37,10 +37,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>>
>>  MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370
>> kernel-module-snd-rawmidi"
>>
>> -KERNEL_MODULE_AUTOLOAD += "uvesafb"
>> -KERNEL_MODULE_PROBECONF += "uvesafb"
>> -module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
>> -
>>  WKS_FILE ?= "qemux86-directdisk.wks"
>>  do_image_wic[depends] += "syslinux:do_populate_sysroot
>> syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot
>> dosfstools-native:do_populate_sysroot"
>>
>> diff --git a/meta/conf/machine/qemux86.conf
>> b/meta/conf/machine/qemux86.conf
>> index 8e0da82076..7e6723b880 100644
>> --- a/meta/conf/machine/qemux86.conf
>> +++ b/meta/conf/machine/qemux86.conf
>> @@ -34,10 +34,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>>
>>  MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370
>> kernel-module-snd-rawmidi"
>>
>> -KERNEL_MODULE_AUTOLOAD += "uvesafb"
>> -KERNEL_MODULE_PROBECONF += "uvesafb"
>> -module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
>> -
>>  WKS_FILE ?= "qemux86-directdisk.wks"
>>  do_image_wic[depends] += "syslinux:do_populate_sysroot
>> syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot
>> dosfstools-native:do_populate_sysroot"
>>
>> diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py
>> b/meta/lib/oeqa/runtime/cases/parselogs.py
>> index 9dafb89b03..3cad0709a1 100644
>> --- a/meta/lib/oeqa/runtime/cases/parselogs.py
>> +++ b/meta/lib/oeqa/runtime/cases/parselogs.py
>> @@ -60,7 +60,6 @@ common_errors = [
>>      ]
>>
>>  video_related = [
>> -    "uvesafb",
>>  ]
>>
>>  x86_common = [
>> @@ -82,11 +81,8 @@ qemux86_common = [
>>      "fail to add MMCONFIG information, can't access extended PCI
>> configuration space under this bridge.",
>>      "can't claim BAR ",
>>      'amd_nb: Cannot enumerate AMD northbridges',
>> -    'uvesafb: 5000 ms task timeout, infinitely waiting',
>>      'tsc: HPET/PMTIMER calibration failed',
>>      "modeset(0): Failed to initialize the DRI2 extension",
>> -    "uvesafb: cannot reserve video memory at",
>> -    "uvesafb: probe of uvesafb.0 failed with error",
>>      "glamor initialization failed",
>>  ] + common_errors
>>
>> --
>> 2.25.0
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>

[-- Attachment #2: Type: text/html, Size: 6589 bytes --]

Re: [PATCH 08/10] webkitgtk: unbreak wayland build

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 4995 bytes --]

bitbake told me to add them (when the existing md5/sha256 checksums were
deemed incorrect), and so I did.

Alex

On Sun, 16 Feb 2020 at 17:09, Martin Jansa <martin.jansa@gmail.com> wrote:

> Do we need sha384sum, sha512sum, sha1sum checksums for these 2 for
> whatever reason?
>
> On Sun, Feb 16, 2020 at 4:52 PM Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
>
>> webkit nowadays requires a couple of supplementary libraries for this,
>> so bring them in (courtesy of meta-browser, which will hopefully
>> adjust without a lot of trouble).
>>
>> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
>> ---
>>  meta/recipes-sato/webkit/libwpe_1.4.0.1.bb    | 19 +++++++++++++++++++
>>  meta/recipes-sato/webkit/webkitgtk_2.26.4.bb  |  2 +-
>>  .../webkit/wpebackend-fdo_1.4.1.bb            | 19 +++++++++++++++++++
>>  3 files changed, 39 insertions(+), 1 deletion(-)
>>  create mode 100644 meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>>  create mode 100644 meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>>
>> diff --git a/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>> b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>> new file mode 100644
>> index 0000000000..b9c71f9dc5
>> --- /dev/null
>> +++ b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>> @@ -0,0 +1,19 @@
>> +SUMMARY = "General-purpose library specifically developed for the
>> WPE-flavored port of WebKit."
>> +HOMEPAGE = "https://github.com/WebPlatformForEmbedded/libwpe"
>> +BUGTRACKER = "https://github.com/WebPlatformForEmbedded/libwpe/issues"
>> +
>> +LICENSE = "BSD"
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=371a616eb4903c6cb79e9893a5f615cc"
>> +DEPENDS = "virtual/egl libxkbcommon"
>> +
>> +# Workaround build issue with RPi userland EGL libraries.
>> +CFLAGS_append_rpi = " ${@bb.utils.contains('MACHINE_FEATURES',
>> 'vc4graphics', '', '-D_GNU_SOURCE', d)}"
>> +
>> +inherit cmake
>> +
>> +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
>> +SRC_URI[md5sum] = "1d4d38413ee0d0043f74d0445cab906f"
>> +SRC_URI[sha256sum] =
>> "09849dfb34877354f34f318e138971cf22e677b2179e1f0a8ea00ab0b7bd8e9b"
>> +SRC_URI[sha1sum] = "a41480a0a85cfa11b3f87f801b7c37bc3410e060"
>> +SRC_URI[sha384sum] =
>> "30488e375d956809a84b0d8af7b386a332541c77dcbd53496a896f894dbf39ac34534e935d6bc7a75c1b536f04f7f0a0"
>> +SRC_URI[sha512sum] =
>> "cbbe6b8e9bbb864d7f96bbdb56db262bbd341c86bc7bedfcc51be8077c0ea58a4e88c61b7b7bec937d5476e6cb81c093229bf80e3ee99452829287bd26175670"
>> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
>> b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
>> index 4aa8533b42..8d87ad49a3 100644
>> --- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
>> +++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
>> @@ -44,7 +44,7 @@ PACKAGECONFIG ??=
>> "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
>>                     libsecret \
>>                    "
>>
>> -PACKAGECONFIG[wayland] =
>> "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland"
>> +PACKAGECONFIG[wayland] =
>> "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe
>> wpebackend-fdo wayland-native"
>>  PACKAGECONFIG[x11] =
>> "-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/libx11"
>>  PACKAGECONFIG[geoclue] =
>> "-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
>>  PACKAGECONFIG[enchant] =
>> "-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
>> diff --git a/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>> b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>> new file mode 100644
>> index 0000000000..84df0c2535
>> --- /dev/null
>> +++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>> @@ -0,0 +1,19 @@
>> +SUMMARY = "WPE's backend based on a freedesktop.org stack."
>> +HOMEPAGE = "https://github.com/Igalia/WPEBackend-fdo"
>> +BUGTRACKER = "https://github.com/Igalia/WPEBackend-fdo/issues"
>> +
>> +LICENSE = "BSD"
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=1f62cef2e3645e3e74eb05fd389d7a66"
>> +DEPENDS = "glib-2.0 libxkbcommon wayland virtual/egl libwpe"
>> +
>> +DEPENDS_append_class-target = " wayland-native"
>> +
>> +inherit cmake
>> +
>> +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
>> +SRC_URI[md5sum] = "c6362491a4a38ddac42b66f140e1cff2"
>> +SRC_URI[sha256sum] =
>> "6249a0b7cbfa662206a8d2fa24e2c574e75c681ad0e93468091f1dc68ddb299d"
>> +SRC_URI[sha1sum] = "9217c8a5511bc53544b42cb23390256580ac4b0c"
>> +SRC_URI[sha384sum] =
>> "79f3a28bc8e0a8240dc9962a6a245276d39dd8112a753d5ada39e98332d857eb9fc9c2879a702060807a10ea60be796d"
>> +SRC_URI[sha512sum] =
>> "8fdd13843c77b95b96b3feffea463bce565620997680e209a0cdcc09314a1469f2f1cb4744dceb2cf6c8d6ce5cb2bbdb4c7fbaf0451a687640c3f63bbdbfc4d4"
>> +
>> --
>> 2.25.0
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>

[-- Attachment #2: Type: text/html, Size: 8053 bytes --]

Re: [PATCH 04/10] qemux86: drop resolution setting via uvesafb

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 5481 bytes --]

Specifically, this page does indicate that Linux kernel stops at 1920x1200,
and even that is entirely non-standard. VBE is a 90s relic.
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers

Alex

On Sun, 16 Feb 2020 at 17:10, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> What about higher than fullHD?
>
> Alex
>
> On Sun, 16 Feb 2020 at 17:01, Martin Jansa <martin.jansa@gmail.com> wrote:
>
>> Why you think it doesn't support higher resolution? We were using it with
>> fullHD in VirtualBox until recently.
>>
>> On Sun, Feb 16, 2020 at 4:52 PM Alexander Kanavin <alex.kanavin@gmail.com>
>> wrote:
>>
>>> I am not sure if this has ever worked, but uvesafb is a really
>>> outdated (VBE from the 1990s), awkward (needs v86d) and limited
>>> (no support for high resolutions) way to do it.
>>>
>>> The specific reason 640x480-32 was introduced (ages ago) was
>>> to force 32 bit mode with vmware driver, as 16bit had rendering issues.
>>>
>>> The modern, supported option is video=... kernel parameter documented
>>> here:
>>>
>>> https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID
>>> https://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst
>>> which can be passed directly to runqemu and doesn't require special
>>> kernel modules.
>>>
>>> Sato under X will continue to use 640x480 as that is hardcoded into
>>> xorg.conf under qemu.
>>>
>>> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
>>> ---
>>>  meta/conf/machine/include/qemuboot-x86.inc | 3 +--
>>>  meta/conf/machine/qemux86-64.conf          | 4 ----
>>>  meta/conf/machine/qemux86.conf             | 4 ----
>>>  meta/lib/oeqa/runtime/cases/parselogs.py   | 4 ----
>>>  4 files changed, 1 insertion(+), 14 deletions(-)
>>>
>>> diff --git a/meta/conf/machine/include/qemuboot-x86.inc
>>> b/meta/conf/machine/include/qemuboot-x86.inc
>>> index 049681b27d..5dcc8b6f6b 100644
>>> --- a/meta/conf/machine/include/qemuboot-x86.inc
>>> +++ b/meta/conf/machine/include/qemuboot-x86.inc
>>> @@ -8,9 +8,8 @@ QB_CPU_KVM_x86-64 = "-cpu core2duo"
>>>
>>>  QB_AUDIO_DRV = "alsa"
>>>  QB_AUDIO_OPT = "-soundhw ac97,es1370"
>>> -QB_KERNEL_CMDLINE_APPEND = "uvesafb.mode_option=${UVESA_MODE}
>>> oprofile.timer=1 uvesafb.task_timeout=-1"
>>> +QB_KERNEL_CMDLINE_APPEND = "oprofile.timer=1"
>>>  QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
>>>  # Add the 'virtio-rng-pci' device otherwise the guest may run out of
>>> entropy
>>>  QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0
>>> -device virtio-rng-pci,rng=rng0"
>>>
>>> -UVESA_MODE ?= "640x480-32"
>>> diff --git a/meta/conf/machine/qemux86-64.conf
>>> b/meta/conf/machine/qemux86-64.conf
>>> index 648cf2fe8f..db9004ee32 100644
>>> --- a/meta/conf/machine/qemux86-64.conf
>>> +++ b/meta/conf/machine/qemux86-64.conf
>>> @@ -37,10 +37,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>>>
>>>  MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370
>>> kernel-module-snd-rawmidi"
>>>
>>> -KERNEL_MODULE_AUTOLOAD += "uvesafb"
>>> -KERNEL_MODULE_PROBECONF += "uvesafb"
>>> -module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
>>> -
>>>  WKS_FILE ?= "qemux86-directdisk.wks"
>>>  do_image_wic[depends] += "syslinux:do_populate_sysroot
>>> syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot
>>> dosfstools-native:do_populate_sysroot"
>>>
>>> diff --git a/meta/conf/machine/qemux86.conf
>>> b/meta/conf/machine/qemux86.conf
>>> index 8e0da82076..7e6723b880 100644
>>> --- a/meta/conf/machine/qemux86.conf
>>> +++ b/meta/conf/machine/qemux86.conf
>>> @@ -34,10 +34,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>>>
>>>  MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370
>>> kernel-module-snd-rawmidi"
>>>
>>> -KERNEL_MODULE_AUTOLOAD += "uvesafb"
>>> -KERNEL_MODULE_PROBECONF += "uvesafb"
>>> -module_conf_uvesafb = "options uvesafb mode_option=${UVESA_MODE}"
>>> -
>>>  WKS_FILE ?= "qemux86-directdisk.wks"
>>>  do_image_wic[depends] += "syslinux:do_populate_sysroot
>>> syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot
>>> dosfstools-native:do_populate_sysroot"
>>>
>>> diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py
>>> b/meta/lib/oeqa/runtime/cases/parselogs.py
>>> index 9dafb89b03..3cad0709a1 100644
>>> --- a/meta/lib/oeqa/runtime/cases/parselogs.py
>>> +++ b/meta/lib/oeqa/runtime/cases/parselogs.py
>>> @@ -60,7 +60,6 @@ common_errors = [
>>>      ]
>>>
>>>  video_related = [
>>> -    "uvesafb",
>>>  ]
>>>
>>>  x86_common = [
>>> @@ -82,11 +81,8 @@ qemux86_common = [
>>>      "fail to add MMCONFIG information, can't access extended PCI
>>> configuration space under this bridge.",
>>>      "can't claim BAR ",
>>>      'amd_nb: Cannot enumerate AMD northbridges',
>>> -    'uvesafb: 5000 ms task timeout, infinitely waiting',
>>>      'tsc: HPET/PMTIMER calibration failed',
>>>      "modeset(0): Failed to initialize the DRI2 extension",
>>> -    "uvesafb: cannot reserve video memory at",
>>> -    "uvesafb: probe of uvesafb.0 failed with error",
>>>      "glamor initialization failed",
>>>  ] + common_errors
>>>
>>> --
>>> 2.25.0
>>>
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>

[-- Attachment #2: Type: text/html, Size: 7326 bytes --]

Re: [PATCH 02/10] procps: upstream has switched to gitlab

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On Sun, Feb 16, 2020 at 7:51 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
>  meta/recipes-extended/procps/procps_3.3.16.bb | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-extended/procps/procps_3.3.16.bb
> b/meta/recipes-extended/procps/procps_3.3.16.bb
> index 60f90976bb..2810ebd285 100644
> --- a/meta/recipes-extended/procps/procps_3.3.16.bb
> +++ b/meta/recipes-extended/procps/procps_3.3.16.bb
> @@ -12,14 +12,19 @@ DEPENDS = "ncurses"
>
>  inherit autotools gettext pkgconfig update-alternatives
>
> -SRC_URI = "
> http://downloads.sourceforge.net/project/procps-ng/Production/procps-ng-${PV}.tar.xz
> \
> +SRC_URI = "git://gitlab.com/procps-ng/procps.git;protocol=https \
>             file://sysctl.conf \
>             "
> +SRCREV = "59c88e18f29000ceaf7e5f98181b07be443cf12f"
>
> -SRC_URI[md5sum] = "e8dc8455e573bdc40b8381d572bbb89b"
> -SRC_URI[sha256sum] =
> "925eacd65dedcf9c98eb94e8978bbfb63f5de37294cc1047d81462ed477a20af"
> +S = "${WORKDIR}/git"
>
> -S = "${WORKDIR}/procps-ng-${PV}"
> +# Upstream has a custom autogen.sh which invokes po/update-potfiles as
> they
> +# don't ship a po/POTFILES.in (which is silly).  Without that file gettext
> +# doesn't believe po/ is a gettext directory and won't generate
> po/Makefile.

Do we miss .in file from tarball ? Or is it missing in a git checkout
This is expected when building in a maintainer mode
Tarballs are produced by maintainers for users
Who wants to build from source

>
> +do_configure_prepend() {
> +    ( cd ${S} && po/update-potfiles )
> +}
>
>  EXTRA_OECONF = "--enable-skill --disable-modern-top"
>
> --
> 2.25.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 3480 bytes --]

Re: [PATCH 02/10] procps: upstream has switched to gitlab

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

On Sun, 16 Feb 2020 at 17:54, Khem Raj <raj.khem@gmail.com> wrote:

>
> -S = "${WORKDIR}/procps-ng-${PV}"
>> +# Upstream has a custom autogen.sh which invokes po/update-potfiles as
>> they
>> +# don't ship a po/POTFILES.in (which is silly).  Without that file
>> gettext
>> +# doesn't believe po/ is a gettext directory and won't generate
>> po/Makefile.
>
> Do we miss .in file from tarball ? Or is it missing in a git checkout
> This is expected when building in a maintainer mode
> Tarballs are produced by maintainers for users
> Who wants to build from source
>

The .in is available in tarballs, but not in git repo. It's generated as
explained above.

Alex

[-- Attachment #2: Type: text/html, Size: 1249 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Khem Raj]

On Sun, Feb 16, 2020 at 7:52 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> The fbdev backend is not documented, and not the default;
> as the emulated hardware in qemu now supports DRM/KMS
> (both std and virtio), we should align with upstream default
> and vast majority of users.
>
> Note that 3D acceleration is not required; the backend
> renders fine via the software driver in mesa.
>

Please specify what all qemu machines have been tested, since we do
not test weston images
runtime, this will silently break untested qemu machines.

> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
>  meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini | 2 --
>  1 file changed, 2 deletions(-)
>  delete mode 100644 meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
>
> diff --git a/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini b/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
> deleted file mode 100644
> index 17ebd7fdab..0000000000
> --- a/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -[core]
> -backend=fbdev-backend.so
> --
> 2.25.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Sun, 16 Feb 2020 at 18:00, Khem Raj <raj.khem@gmail.com> wrote:

> Please specify what all qemu machines have been tested, since we do
> not test weston images
> runtime, this will silently break untested qemu machines.
>

Autobuilder does test core-image-weston on qemux86_64 and that's where I
verified the change.

Alex


> > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > ---
> >  meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini | 2 --
> >  1 file changed, 2 deletions(-)
> >  delete mode 100644
> meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
> >
> > diff --git
> a/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
> b/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
> > deleted file mode 100644
> > index 17ebd7fdab..0000000000
> > --- a/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
> > +++ /dev/null
> > @@ -1,2 +0,0 @@
> > -[core]
> > -backend=fbdev-backend.so
> > --
> > 2.25.0
> >
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2049 bytes --]

Re: [PATCH 08/10] webkitgtk: unbreak wayland build

[Richard Purdie]

On Sun, 2020-02-16 at 17:14 +0100, Alexander Kanavin wrote:
> bitbake told me to add them (when the existing md5/sha256 checksums
> were deemed incorrect), and so I did.

I think that is an unintended side effect of some new changes to
bitbake to support the other forms.

I think at this point we should fix it to print the sha256 and not
anything else? We can then slowly drop the md5sums.

Cheers,

Richard

Re: [PATCH 02/10] procps: upstream has switched to gitlab

[Khem Raj]

On Sun, Feb 16, 2020 at 8:56 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Sun, 16 Feb 2020 at 17:54, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>
>>> -S = "${WORKDIR}/procps-ng-${PV}"
>>> +# Upstream has a custom autogen.sh which invokes po/update-potfiles as they
>>> +# don't ship a po/POTFILES.in (which is silly).  Without that file gettext
>>> +# doesn't believe po/ is a gettext directory and won't generate po/Makefile.
>>
>> Do we miss .in file from tarball ? Or is it missing in a git checkout
>> This is expected when building in a maintainer mode
>> Tarballs are produced by maintainers for users
>> Who wants to build from source
>
>
> The .in is available in tarballs, but not in git repo. It's generated as explained above.

right. Then revise the comment, since its expected to be absent when
we are building from
git sources.

>
> Alex

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Khem Raj]

On Sun, Feb 16, 2020 at 9:07 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Sun, 16 Feb 2020 at 18:00, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> Please specify what all qemu machines have been tested, since we do
>> not test weston images
>> runtime, this will silently break untested qemu machines.
>
>
> Autobuilder does test core-image-weston on qemux86_64 and that's where I verified the change.
>

qemuall, applies to other qemu machines for arm/aarch64/mips/ppc/riscv
as well, in recent past I knew
this change was needed for qemumips and qemuarm to boot
core-image-weston, I am not sure if
anything has changed since then. I think this change would need some
more testing.

> Alex
>
>>
>> > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
>> > ---
>> >  meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini | 2 --
>> >  1 file changed, 2 deletions(-)
>> >  delete mode 100644 meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
>> >
>> > diff --git a/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini b/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
>> > deleted file mode 100644
>> > index 17ebd7fdab..0000000000
>> > --- a/meta/recipes-graphics/wayland/weston-init/qemuall/weston.ini
>> > +++ /dev/null
>> > @@ -1,2 +0,0 @@
>> > -[core]
>> > -backend=fbdev-backend.so
>> > --
>> > 2.25.0
>> >
>> > --
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 08/10] webkitgtk: unbreak wayland build

[Khem Raj]

On Sun, Feb 16, 2020 at 7:52 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> webkit nowadays requires a couple of supplementary libraries for this,
> so bring them in (courtesy of meta-browser, which will hopefully
> adjust without a lot of trouble).

its not meta-browser, I guess you should credit meta-wpe here [1]
and perhaps Cc the meta-wpe maintainer as a courtesy.

[1] https://github.com/WebPlatformForEmbedded/meta-wpe/tree/master/recipes-wpe/libwpe
>
> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
>  meta/recipes-sato/webkit/libwpe_1.4.0.1.bb    | 19 +++++++++++++++++++
>  meta/recipes-sato/webkit/webkitgtk_2.26.4.bb  |  2 +-
>  .../webkit/wpebackend-fdo_1.4.1.bb            | 19 +++++++++++++++++++
>  3 files changed, 39 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>  create mode 100644 meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>
> diff --git a/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> new file mode 100644
> index 0000000000..b9c71f9dc5
> --- /dev/null
> +++ b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> @@ -0,0 +1,19 @@
> +SUMMARY = "General-purpose library specifically developed for the WPE-flavored port of WebKit."
> +HOMEPAGE = "https://github.com/WebPlatformForEmbedded/libwpe"
> +BUGTRACKER = "https://github.com/WebPlatformForEmbedded/libwpe/issues"
> +
> +LICENSE = "BSD"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=371a616eb4903c6cb79e9893a5f615cc"
> +DEPENDS = "virtual/egl libxkbcommon"
> +
> +# Workaround build issue with RPi userland EGL libraries.
> +CFLAGS_append_rpi = " ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', '-D_GNU_SOURCE', d)}"
> +
> +inherit cmake
> +
> +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
> +SRC_URI[md5sum] = "1d4d38413ee0d0043f74d0445cab906f"
> +SRC_URI[sha256sum] = "09849dfb34877354f34f318e138971cf22e677b2179e1f0a8ea00ab0b7bd8e9b"
> +SRC_URI[sha1sum] = "a41480a0a85cfa11b3f87f801b7c37bc3410e060"
> +SRC_URI[sha384sum] = "30488e375d956809a84b0d8af7b386a332541c77dcbd53496a896f894dbf39ac34534e935d6bc7a75c1b536f04f7f0a0"
> +SRC_URI[sha512sum] = "cbbe6b8e9bbb864d7f96bbdb56db262bbd341c86bc7bedfcc51be8077c0ea58a4e88c61b7b7bec937d5476e6cb81c093229bf80e3ee99452829287bd26175670"
> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> index 4aa8533b42..8d87ad49a3 100644
> --- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> +++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> @@ -44,7 +44,7 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
>                     libsecret \
>                    "
>
> -PACKAGECONFIG[wayland] = "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland"
> +PACKAGECONFIG[wayland] = "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe wpebackend-fdo wayland-native"
>  PACKAGECONFIG[x11] = "-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/libx11"
>  PACKAGECONFIG[geoclue] = "-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
>  PACKAGECONFIG[enchant] = "-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
> diff --git a/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> new file mode 100644
> index 0000000000..84df0c2535
> --- /dev/null
> +++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> @@ -0,0 +1,19 @@
> +SUMMARY = "WPE's backend based on a freedesktop.org stack."
> +HOMEPAGE = "https://github.com/Igalia/WPEBackend-fdo"
> +BUGTRACKER = "https://github.com/Igalia/WPEBackend-fdo/issues"
> +
> +LICENSE = "BSD"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=1f62cef2e3645e3e74eb05fd389d7a66"
> +DEPENDS = "glib-2.0 libxkbcommon wayland virtual/egl libwpe"
> +
> +DEPENDS_append_class-target = " wayland-native"
> +
> +inherit cmake
> +
> +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
> +SRC_URI[md5sum] = "c6362491a4a38ddac42b66f140e1cff2"
> +SRC_URI[sha256sum] = "6249a0b7cbfa662206a8d2fa24e2c574e75c681ad0e93468091f1dc68ddb299d"
> +SRC_URI[sha1sum] = "9217c8a5511bc53544b42cb23390256580ac4b0c"
> +SRC_URI[sha384sum] = "79f3a28bc8e0a8240dc9962a6a245276d39dd8112a753d5ada39e98332d857eb9fc9c2879a702060807a10ea60be796d"
> +SRC_URI[sha512sum] = "8fdd13843c77b95b96b3feffea463bce565620997680e209a0cdcc09314a1469f2f1cb4744dceb2cf6c8d6ce5cb2bbdb4c7fbaf0451a687640c3f63bbdbfc4d4"
> +
> --
> 2.25.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 02/10] procps: upstream has switched to gitlab

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Sun, 16 Feb 2020 at 21:07, Khem Raj <raj.khem@gmail.com> wrote:

> >>> -S = "${WORKDIR}/procps-ng-${PV}"
> >>> +# Upstream has a custom autogen.sh which invokes po/update-potfiles
> as they
> >>> +# don't ship a po/POTFILES.in (which is silly).  Without that file
> gettext
> >>> +# doesn't believe po/ is a gettext directory and won't generate
> po/Makefile.
> >>
> >> Do we miss .in file from tarball ? Or is it missing in a git checkout
> >> This is expected when building in a maintainer mode
> >> Tarballs are produced by maintainers for users
> >> Who wants to build from source
> >
> >
> > The .in is available in tarballs, but not in git repo. It's generated as
> explained above.
>
> right. Then revise the comment, since its expected to be absent when
> we are building from
> git sources.
>

The fix and the comment were copied wholesale and were originally written
by Ross. How is POTFILES.in normally generated (i.e. without involving
custom autogen.sh)?

Alex

[-- Attachment #2: Type: text/html, Size: 1430 bytes --]

Re: [PATCH 08/10] webkitgtk: unbreak wayland build

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 5287 bytes --]

On Sun, 16 Feb 2020 at 21:15, Khem Raj <raj.khem@gmail.com> wrote:

> On Sun, Feb 16, 2020 at 7:52 AM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
> >
> > webkit nowadays requires a couple of supplementary libraries for this,
> > so bring them in (courtesy of meta-browser, which will hopefully
> > adjust without a lot of trouble).
>
> its not meta-browser, I guess you should credit meta-wpe here [1]
> and perhaps Cc the meta-wpe maintainer as a courtesy.
>

Actually, it's copied from meta-webkit
https://github.com/Igalia/meta-webkit/
which does not say in the readme who the maintainer is, so I am not sure
whom to CC.
I can adjust the commit msg though.

Alex



>
> [1]
> https://github.com/WebPlatformForEmbedded/meta-wpe/tree/master/recipes-wpe/libwpe
> >
> > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > ---
> >  meta/recipes-sato/webkit/libwpe_1.4.0.1.bb    | 19 +++++++++++++++++++
> >  meta/recipes-sato/webkit/webkitgtk_2.26.4.bb  |  2 +-
> >  .../webkit/wpebackend-fdo_1.4.1.bb            | 19 +++++++++++++++++++
> >  3 files changed, 39 insertions(+), 1 deletion(-)
> >  create mode 100644 meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> >  create mode 100644 meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> >
> > diff --git a/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> > new file mode 100644
> > index 0000000000..b9c71f9dc5
> > --- /dev/null
> > +++ b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
> > @@ -0,0 +1,19 @@
> > +SUMMARY = "General-purpose library specifically developed for the
> WPE-flavored port of WebKit."
> > +HOMEPAGE = "https://github.com/WebPlatformForEmbedded/libwpe"
> > +BUGTRACKER = "https://github.com/WebPlatformForEmbedded/libwpe/issues"
> > +
> > +LICENSE = "BSD"
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=371a616eb4903c6cb79e9893a5f615cc"
> > +DEPENDS = "virtual/egl libxkbcommon"
> > +
> > +# Workaround build issue with RPi userland EGL libraries.
> > +CFLAGS_append_rpi = " ${@bb.utils.contains('MACHINE_FEATURES',
> 'vc4graphics', '', '-D_GNU_SOURCE', d)}"
> > +
> > +inherit cmake
> > +
> > +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
> > +SRC_URI[md5sum] = "1d4d38413ee0d0043f74d0445cab906f"
> > +SRC_URI[sha256sum] =
> "09849dfb34877354f34f318e138971cf22e677b2179e1f0a8ea00ab0b7bd8e9b"
> > +SRC_URI[sha1sum] = "a41480a0a85cfa11b3f87f801b7c37bc3410e060"
> > +SRC_URI[sha384sum] =
> "30488e375d956809a84b0d8af7b386a332541c77dcbd53496a896f894dbf39ac34534e935d6bc7a75c1b536f04f7f0a0"
> > +SRC_URI[sha512sum] =
> "cbbe6b8e9bbb864d7f96bbdb56db262bbd341c86bc7bedfcc51be8077c0ea58a4e88c61b7b7bec937d5476e6cb81c093229bf80e3ee99452829287bd26175670"
> > diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> > index 4aa8533b42..8d87ad49a3 100644
> > --- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> > +++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
> > @@ -44,7 +44,7 @@ PACKAGECONFIG ??=
> "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
> >                     libsecret \
> >                    "
> >
> > -PACKAGECONFIG[wayland] =
> "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland"
> > +PACKAGECONFIG[wayland] =
> "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe
> wpebackend-fdo wayland-native"
> >  PACKAGECONFIG[x11] =
> "-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/libx11"
> >  PACKAGECONFIG[geoclue] =
> "-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
> >  PACKAGECONFIG[enchant] =
> "-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
> > diff --git a/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> > new file mode 100644
> > index 0000000000..84df0c2535
> > --- /dev/null
> > +++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
> > @@ -0,0 +1,19 @@
> > +SUMMARY = "WPE's backend based on a freedesktop.org stack."
> > +HOMEPAGE = "https://github.com/Igalia/WPEBackend-fdo"
> > +BUGTRACKER = "https://github.com/Igalia/WPEBackend-fdo/issues"
> > +
> > +LICENSE = "BSD"
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=1f62cef2e3645e3e74eb05fd389d7a66"
> > +DEPENDS = "glib-2.0 libxkbcommon wayland virtual/egl libwpe"
> > +
> > +DEPENDS_append_class-target = " wayland-native"
> > +
> > +inherit cmake
> > +
> > +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
> > +SRC_URI[md5sum] = "c6362491a4a38ddac42b66f140e1cff2"
> > +SRC_URI[sha256sum] =
> "6249a0b7cbfa662206a8d2fa24e2c574e75c681ad0e93468091f1dc68ddb299d"
> > +SRC_URI[sha1sum] = "9217c8a5511bc53544b42cb23390256580ac4b0c"
> > +SRC_URI[sha384sum] =
> "79f3a28bc8e0a8240dc9962a6a245276d39dd8112a753d5ada39e98332d857eb9fc9c2879a702060807a10ea60be796d"
> > +SRC_URI[sha512sum] =
> "8fdd13843c77b95b96b3feffea463bce565620997680e209a0cdcc09314a1469f2f1cb4744dceb2cf6c8d6ce5cb2bbdb4c7fbaf0451a687640c3f63bbdbfc4d4"
> > +
> > --
> > 2.25.0
> >
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 8854 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

On Sun, 16 Feb 2020 at 21:10, Khem Raj <raj.khem@gmail.com> wrote:

> qemuall, applies to other qemu machines for arm/aarch64/mips/ppc/riscv
> as well, in recent past I knew
> this change was needed for qemumips and qemuarm to boot
> core-image-weston, I am not sure if
> anything has changed since then. I think this change would need some
> more testing.
>

Sure, but the testing should be done by people who need those other
machines to be able to boot weston; I would want to draw the line at what
is currently covered by the autobuilder (which is just qemux86_64).

We can then use the fallback in a more targeted way, although the proper
fix would be to look into why the default backend isn't working.

Alex

[-- Attachment #2: Type: text/html, Size: 1130 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Khem Raj]

On Sun, Feb 16, 2020 at 1:03 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Sun, 16 Feb 2020 at 21:10, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> qemuall, applies to other qemu machines for arm/aarch64/mips/ppc/riscv
>> as well, in recent past I knew
>> this change was needed for qemumips and qemuarm to boot
>> core-image-weston, I am not sure if
>> anything has changed since then. I think this change would need some
>> more testing.
>
>
> Sure, but the testing should be done by people who need those other machines to be able to boot weston; I would want to draw the line at what is currently covered by the autobuilder (which is just qemux86_64).
>

perhaps then make this chage such thst it only affects the
architecture you have tested.

> We can then use the fallback in a more targeted way, although the proper fix would be to look into why the default backend isn't working.
>
> Alex

Re: [PATCH 02/10] procps: upstream has switched to gitlab

[Khem Raj]

On Sun, Feb 16, 2020 at 12:45 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Sun, 16 Feb 2020 at 21:07, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> >>> -S = "${WORKDIR}/procps-ng-${PV}"
>> >>> +# Upstream has a custom autogen.sh which invokes po/update-potfiles as they
>> >>> +# don't ship a po/POTFILES.in (which is silly).  Without that file gettext
>> >>> +# doesn't believe po/ is a gettext directory and won't generate po/Makefile.
>> >>
>> >> Do we miss .in file from tarball ? Or is it missing in a git checkout
>> >> This is expected when building in a maintainer mode
>> >> Tarballs are produced by maintainers for users
>> >> Who wants to build from source
>> >
>> >
>> > The .in is available in tarballs, but not in git repo. It's generated as explained above.
>>
>> right. Then revise the comment, since its expected to be absent when
>> we are building from
>> git sources.
>
>
> The fix and the comment were copied wholesale and were originally written by Ross. How is POTFILES.in normally generated (i.e. without involving custom autogen.sh)?

any .in file is usually generated by maintainer into source tarball
since the build is not consuming source tar anymore
this comment perhaps should be deleted.

>
> Alex

Re: [PATCH 02/10] procps: upstream has switched to gitlab

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

I looked it up. Actually, potfiles.in is typically not a generated file,
and should be placed under version control. The comment is valid.

Alex

On Mon 17. Feb 2020 at 3.36, Khem Raj <raj.khem@gmail.com> wrote:

> On Sun, Feb 16, 2020 at 12:45 PM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
> >
> > On Sun, 16 Feb 2020 at 21:07, Khem Raj <raj.khem@gmail.com> wrote:
> >>
> >> >>> -S = "${WORKDIR}/procps-ng-${PV}"
> >> >>> +# Upstream has a custom autogen.sh which invokes
> po/update-potfiles as they
> >> >>> +# don't ship a po/POTFILES.in (which is silly).  Without that file
> gettext
> >> >>> +# doesn't believe po/ is a gettext directory and won't generate
> po/Makefile.
> >> >>
> >> >> Do we miss .in file from tarball ? Or is it missing in a git checkout
> >> >> This is expected when building in a maintainer mode
> >> >> Tarballs are produced by maintainers for users
> >> >> Who wants to build from source
> >> >
> >> >
> >> > The .in is available in tarballs, but not in git repo. It's generated
> as explained above.
> >>
> >> right. Then revise the comment, since its expected to be absent when
> >> we are building from
> >> git sources.
> >
> >
> > The fix and the comment were copied wholesale and were originally
> written by Ross. How is POTFILES.in normally generated (i.e. without
> involving custom autogen.sh)?
>
> any .in file is usually generated by maintainer into source tarball
> since the build is not consuming source tar anymore
> this comment perhaps should be deleted.
>
> >
> > Alex
>

[-- Attachment #2: Type: text/html, Size: 2324 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

On Mon 17. Feb 2020 at 3.30, Khem Raj <raj.khem@gmail.com> wrote:

>
> > Sure, but the testing should be done by people who need those other
> machines to be able to boot weston; I would want to draw the line at what
> is currently covered by the autobuilder (which is just qemux86_64).
> >
>
> perhaps then make this chage such thst it only affects the
> architecture you have tested.


Fbdev backend is not documented, and there is no guarantee by upstream that
it will work. You wouldn’t want to use it on actual targets either as it
has no hw acceleration support. I think the change should apply to all, we
should test standard drm/kms code paths everywhere and fix/report issues as
needed.

Alex

[-- Attachment #2: Type: text/html, Size: 1073 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On Mon, 17 Feb 2020 at 09:22, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> \perhaps then make this chage such thst it only affects the
>> architecture you have tested.
>
>
> Fbdev backend is not documented, and there is no guarantee by upstream
> that it will work. You wouldn’t want to use it on actual targets either as
> it has no hw acceleration support. I think the change should apply to all,
> we should test standard drm/kms code paths everywhere and fix/report issues
> as needed.
>

The issue with qemumips in particular is that it is still using cirrus for
the graphics card, which has been superseded by '-vga std' for a long time:
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/

If that is switched, then fbdev backend should be no longer necessary just
like in qemux86_64.

Alex

[-- Attachment #2: Type: text/html, Size: 1585 bytes --]

Re: [PATCH 09/10] wayland: convert to meson build

[Richard Purdie]

On Sun, 2020-02-16 at 16:50 +0100, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
>  ...-the-native-wayland-scanner-directly.patch | 27
> +++++++++++++++++++
>  .../wayland/wayland_1.18.0.bb                 |  9 ++++---
>  2 files changed, 32 insertions(+), 4 deletions(-)
>  create mode 100644 meta/recipes-graphics/wayland/wayland/0002-
> meson.build-find-the-native-wayland-scanner-directly.patch

I pulled some of your patches into -next:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/718

I think the failures are related to this patch?

Cheers,

Richard

Re: [PATCH 09/10] wayland: convert to meson build

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

On Mon, 17 Feb 2020 at 15:35, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Sun, 2020-02-16 at 16:50 +0100, Alexander Kanavin wrote:
> > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > ---
> >  ...-the-native-wayland-scanner-directly.patch | 27
> > +++++++++++++++++++
> >  .../wayland/wayland_1.18.0.bb                 |  9 ++++---
> >  2 files changed, 32 insertions(+), 4 deletions(-)
> >  create mode 100644 meta/recipes-graphics/wayland/wayland/0002-
> > meson.build-find-the-native-wayland-scanner-directly.patch
>
> I pulled some of your patches into -next:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/718
>
> I think the failures are related to this patch?
>

Going slightly mad here:
https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/1581/steps/8/logs/step1b
<https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/1581/steps/8/logs/step1b>libxkbcommon
and mesa have failed in do_configure, but I am not seeing the tasks being
run?

Alex

[-- Attachment #2: Type: text/html, Size: 1894 bytes --]

Re: [PATCH 09/10] wayland: convert to meson build

[Richard Purdie]

On Mon, 2020-02-17 at 15:50 +0100, Alexander Kanavin wrote:
> On Mon, 17 Feb 2020 at 15:35, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
> > On Sun, 2020-02-16 at 16:50 +0100, Alexander Kanavin wrote:
> > > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > > ---
> > >  ...-the-native-wayland-scanner-directly.patch | 27
> > > +++++++++++++++++++
> > >  .../wayland/wayland_1.18.0.bb                 |  9 ++++---
> > >  2 files changed, 32 insertions(+), 4 deletions(-)
> > >  create mode 100644 meta/recipes-graphics/wayland/wayland/0002-
> > > meson.build-find-the-native-wayland-scanner-directly.patch
> > 
> > I pulled some of your patches into -next:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/718
> > 
> > I think the failures are related to this patch?
> 
> Going slightly mad here:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/1581/steps/8/logs/step1b
> libxkbcommon and mesa have failed in do_configure, but I am not
> seeing the tasks being run?

If I click the "download log" button there and download them I do see
the failing tasks in the log?

Cheers,

Richard

Re: [PATCH 09/10] wayland: convert to meson build

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Nevermind, found it. Forgot to click on the magnifying glass, before
starting a search.

Alex

On Mon, 17 Feb 2020 at 15:50, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Mon, 17 Feb 2020 at 15:35, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
>
>> On Sun, 2020-02-16 at 16:50 +0100, Alexander Kanavin wrote:
>> > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
>> > ---
>> >  ...-the-native-wayland-scanner-directly.patch | 27
>> > +++++++++++++++++++
>> >  .../wayland/wayland_1.18.0.bb                 |  9 ++++---
>> >  2 files changed, 32 insertions(+), 4 deletions(-)
>> >  create mode 100644 meta/recipes-graphics/wayland/wayland/0002-
>> > meson.build-find-the-native-wayland-scanner-directly.patch
>>
>> I pulled some of your patches into -next:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/718
>>
>> I think the failures are related to this patch?
>>
>
> Going slightly mad here:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/1581/steps/8/logs/step1b
>
> <https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/1581/steps/8/logs/step1b>libxkbcommon
> and mesa have failed in do_configure, but I am not seeing the tasks being
> run?
>
> Alex
>

[-- Attachment #2: Type: text/html, Size: 2466 bytes --]

Re: [PATCH 02/10] procps: upstream has switched to gitlab

[Khem Raj]

Ok, thanks. for confirmation

On Mon, Feb 17, 2020 at 12:12 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> I looked it up. Actually, potfiles.in is typically not a generated file, and should be placed under version control. The comment is valid.
>
> Alex
>
> On Mon 17. Feb 2020 at 3.36, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> On Sun, Feb 16, 2020 at 12:45 PM Alexander Kanavin
>> <alex.kanavin@gmail.com> wrote:
>> >
>> > On Sun, 16 Feb 2020 at 21:07, Khem Raj <raj.khem@gmail.com> wrote:
>> >>
>> >> >>> -S = "${WORKDIR}/procps-ng-${PV}"
>> >> >>> +# Upstream has a custom autogen.sh which invokes po/update-potfiles as they
>> >> >>> +# don't ship a po/POTFILES.in (which is silly).  Without that file gettext
>> >> >>> +# doesn't believe po/ is a gettext directory and won't generate po/Makefile.
>> >> >>
>> >> >> Do we miss .in file from tarball ? Or is it missing in a git checkout
>> >> >> This is expected when building in a maintainer mode
>> >> >> Tarballs are produced by maintainers for users
>> >> >> Who wants to build from source
>> >> >
>> >> >
>> >> > The .in is available in tarballs, but not in git repo. It's generated as explained above.
>> >>
>> >> right. Then revise the comment, since its expected to be absent when
>> >> we are building from
>> >> git sources.
>> >
>> >
>> > The fix and the comment were copied wholesale and were originally written by Ross. How is POTFILES.in normally generated (i.e. without involving custom autogen.sh)?
>>
>> any .in file is usually generated by maintainer into source tarball
>> since the build is not consuming source tar anymore
>> this comment perhaps should be deleted.
>>
>> >
>> > Alex

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Khem Raj]

On Mon, Feb 17, 2020 at 5:15 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Mon, 17 Feb 2020 at 09:22, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>>>
>>> \perhaps then make this chage such thst it only affects the
>>> architecture you have tested.
>>
>>
>> Fbdev backend is not documented, and there is no guarantee by upstream that it will work. You wouldn’t want to use it on actual targets either as it has no hw acceleration support. I think the change should apply to all, we should test standard drm/kms code paths everywhere and fix/report issues as needed.

hw acceleration is not going to work for non-x86 qemus, while other
qemus should be fixed but not
by breaking them first. As suggested limit this change to tested
architectures and it would be fine.
then if interested to fix it globally make changes to fix rest of
qemus and then instrument global change
after that

>
>
> The issue with qemumips in particular is that it is still using cirrus for the graphics card, which has been superseded by '-vga std' for a long time:
> https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
>
> If that is switched, then fbdev backend should be no longer necessary just like in qemux86_64.
>

this is interesting, I will try it out on mips.

> Alex

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

On Mon, 17 Feb 2020 at 19:45, Khem Raj <raj.khem@gmail.com> wrote:

>
> hw acceleration is not going to work for non-x86 qemus, while other
> qemus should be fixed but not
> by breaking them first. As suggested limit this change to tested
> architectures and it would be fine.
> then if interested to fix it globally make changes to fix rest of
> qemus and then instrument global change
> after that
>

arm64 qemu should work, as it is using the same video hardware as x86_64.
My computing resources are severely limited right now, so I cannot try it
out immediately unfortunately, but I'll get to it, or you are welcome to
try and report.
Mips can be either fixed like suggested, or be a specific exception.

For the rest of the targets, I see that you have extended the fbdev
fallback to qemuall only on Jan 9 this year. So it's very unlikely anyone
is using them to run weston (not to mention how painfully slow that would
be), and so it would just be wasteful to test or fix them.

Alex

[-- Attachment #2: Type: text/html, Size: 1383 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Mon, Feb 17, 2020 at 11:29 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Mon, 17 Feb 2020 at 19:45, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> hw acceleration is not going to work for non-x86 qemus, while other
>> qemus should be fixed but not
>> by breaking them first. As suggested limit this change to tested
>> architectures and it would be fine.
>> then if interested to fix it globally make changes to fix rest of
>> qemus and then instrument global change
>> after that
>>
>
> arm64 qemu should work, as it is using the same video hardware as x86_64.
> My computing resources are severely limited right now, so I cannot try it
> out immediately unfortunately,
>

Ok then resend it later


but I'll get to it, or you are welcome to try and report.
> Mips can be either fixed like suggested, or be a specific exception.
>
> For the rest of the targets, I see that you have extended the fbdev
> fallback to qemuall only on Jan 9 this year. So it's very unlikely anyone
> is using them to run weston (not to mention how painfully slow that would
> be), and so it would just be wasteful to test or fix them.
>

We should be only applying tested part debugging these breakages is very
hard so when we know it will break we should be careful as with this patch



>
> Alex
>

[-- Attachment #2: Type: text/html, Size: 2481 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

On Tue, 18 Feb 2020 at 02:56, Khem Raj <raj.khem@gmail.com> wrote:

>
> but I'll get to it, or you are welcome to try and report.
>> Mips can be either fixed like suggested, or be a specific exception.
>>
>> For the rest of the targets, I see that you have extended the fbdev
>> fallback to qemuall only on Jan 9 this year. So it's very unlikely anyone
>> is using them to run weston (not to mention how painfully slow that would
>> be), and so it would just be wasteful to test or fix them.
>>
>
> We should be only applying tested part debugging these breakages is very
> hard so when we know it will break we should be careful as with this patch
>

I have tested these things now:

1. Switching mips from cirrus to std vga works fine, as long as xorg.conf
is also deleted (it's written specifically for cirrus and isn't working or
needed with std vga). Both weston and sato boot and look right. I'll send a
patch for it.

2. Switching weston to kms backend degrades performance to unusable level,
as neither kvm nor virtio/virgl are available for non-x86 qemu, and kms
backend is using software renderer in mesa. So fbdev is the only realistic
option there. But for x86 qemu kms is still viable. I'm not sure how to
best configure it though.

Alex

[-- Attachment #2: Type: text/html, Size: 1960 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Khem Raj]

On Wed, Feb 19, 2020 at 1:45 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Tue, 18 Feb 2020 at 02:56, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>
>>> but I'll get to it, or you are welcome to try and report.
>>> Mips can be either fixed like suggested, or be a specific exception.
>>>
>>> For the rest of the targets, I see that you have extended the fbdev fallback to qemuall only on Jan 9 this year. So it's very unlikely anyone is using them to run weston (not to mention how painfully slow that would be), and so it would just be wasteful to test or fix them.
>>
>>
>> We should be only applying tested part debugging these breakages is very hard so when we know it will break we should be careful as with this patch
>
>
> I have tested these things now:
>
> 1. Switching mips from cirrus to std vga works fine, as long as xorg.conf is also deleted (it's written specifically for cirrus and isn't working or needed with std vga). Both weston and sato boot and look right. I'll send a patch for it.
>
> 2. Switching weston to kms backend degrades performance to unusable level, as neither kvm nor virtio/virgl are available for non-x86 qemu, and kms backend is using software renderer in mesa. So fbdev is the only realistic option there. But for x86 qemu kms is still viable. I'm not sure how to best configure it though.

copy qemuall/weston.ini new folders qemux86 and qemux86-64 and point
to backend it should be using.

>
> Alex

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

Will that take precedence over qemuall though? Sounds brittle. Another
option is to make the fbdev configuration specific to mips and arm, as
using kms does not need a configuration at all.

Alex

On Wed 19. Feb 2020 at 18.21, Khem Raj <raj.khem@gmail.com> wrote:

> On Wed, Feb 19, 2020 at 1:45 AM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
> >
> > On Tue, 18 Feb 2020 at 02:56, Khem Raj <raj.khem@gmail.com> wrote:
> >>
> >>
> >>> but I'll get to it, or you are welcome to try and report.
> >>> Mips can be either fixed like suggested, or be a specific exception.
> >>>
> >>> For the rest of the targets, I see that you have extended the fbdev
> fallback to qemuall only on Jan 9 this year. So it's very unlikely anyone
> is using them to run weston (not to mention how painfully slow that would
> be), and so it would just be wasteful to test or fix them.
> >>
> >>
> >> We should be only applying tested part debugging these breakages is
> very hard so when we know it will break we should be careful as with this
> patch
> >
> >
> > I have tested these things now:
> >
> > 1. Switching mips from cirrus to std vga works fine, as long as
> xorg.conf is also deleted (it's written specifically for cirrus and isn't
> working or needed with std vga). Both weston and sato boot and look right.
> I'll send a patch for it.
> >
> > 2. Switching weston to kms backend degrades performance to unusable
> level, as neither kvm nor virtio/virgl are available for non-x86 qemu, and
> kms backend is using software renderer in mesa. So fbdev is the only
> realistic option there. But for x86 qemu kms is still viable. I'm not sure
> how to best configure it though.
>
> copy qemuall/weston.ini new folders qemux86 and qemux86-64 and point
> to backend it should be using.
>
> >
> > Alex
>

[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

Re: [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Khem Raj]

On 2/19/20 10:06 AM, Alexander Kanavin wrote:
> Will that take precedence over qemuall though? Sounds brittle. Another 
> option is to make the fbdev configuration specific to mips and arm, as 
> using kms does not need a configuration at all.
> 

I think it will. arch specific overrides should come before generic ones.

> Alex
> 
> On Wed 19. Feb 2020 at 18.21, Khem Raj <raj.khem@gmail.com 
> <mailto:raj.khem@gmail.com>> wrote:
> 
>     On Wed, Feb 19, 2020 at 1:45 AM Alexander Kanavin
>     <alex.kanavin@gmail.com <mailto:alex.kanavin@gmail.com>> wrote:
>      >
>      > On Tue, 18 Feb 2020 at 02:56, Khem Raj <raj.khem@gmail.com
>     <mailto:raj.khem@gmail.com>> wrote:
>      >>
>      >>
>      >>> but I'll get to it, or you are welcome to try and report.
>      >>> Mips can be either fixed like suggested, or be a specific
>     exception.
>      >>>
>      >>> For the rest of the targets, I see that you have extended the
>     fbdev fallback to qemuall only on Jan 9 this year. So it's very
>     unlikely anyone is using them to run weston (not to mention how
>     painfully slow that would be), and so it would just be wasteful to
>     test or fix them.
>      >>
>      >>
>      >> We should be only applying tested part debugging these breakages
>     is very hard so when we know it will break we should be careful as
>     with this patch
>      >
>      >
>      > I have tested these things now:
>      >
>      > 1. Switching mips from cirrus to std vga works fine, as long as
>     xorg.conf is also deleted (it's written specifically for cirrus and
>     isn't working or needed with std vga). Both weston and sato boot and
>     look right. I'll send a patch for it.
>      >
>      > 2. Switching weston to kms backend degrades performance to
>     unusable level, as neither kvm nor virtio/virgl are available for
>     non-x86 qemu, and kms backend is using software renderer in mesa. So
>     fbdev is the only realistic option there. But for x86 qemu kms is
>     still viable. I'm not sure how to best configure it though.
> 
>     copy qemuall/weston.ini new folders qemux86 and qemux86-64 and point
>     to backend it should be using.
> 
>      >
>      > Alex
> 

Re: [PATCH 08/10] webkitgtk: unbreak wayland build

[Joshua Watt]

On Sun, Feb 16, 2020 at 2:52 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Sun, 16 Feb 2020 at 21:15, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> On Sun, Feb 16, 2020 at 7:52 AM Alexander Kanavin
>> <alex.kanavin@gmail.com> wrote:
>> >
>> > webkit nowadays requires a couple of supplementary libraries for this,
>> > so bring them in (courtesy of meta-browser, which will hopefully
>> > adjust without a lot of trouble).
>>
>> its not meta-browser, I guess you should credit meta-wpe here [1]
>> and perhaps Cc the meta-wpe maintainer as a courtesy.
>
>
> Actually, it's copied from meta-webkit
> https://github.com/Igalia/meta-webkit/
> which does not say in the readme who the maintainer is, so I am not sure whom to CC.
> I can adjust the commit msg though.

I've CC'd the WPE mailing list.

OE-core now has libwpe and wpebackend-fdo recipes. They should
possibly be removed from meta-webkit to prevent duplication.

>
> Alex
>
>
>>
>>
>> [1] https://github.com/WebPlatformForEmbedded/meta-wpe/tree/master/recipes-wpe/libwpe
>> >
>> > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
>> > ---
>> >  meta/recipes-sato/webkit/libwpe_1.4.0.1.bb    | 19 +++++++++++++++++++
>> >  meta/recipes-sato/webkit/webkitgtk_2.26.4.bb  |  2 +-
>> >  .../webkit/wpebackend-fdo_1.4.1.bb            | 19 +++++++++++++++++++
>> >  3 files changed, 39 insertions(+), 1 deletion(-)
>> >  create mode 100644 meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>> >  create mode 100644 meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>> >
>> > diff --git a/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>> > new file mode 100644
>> > index 0000000000..b9c71f9dc5
>> > --- /dev/null
>> > +++ b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
>> > @@ -0,0 +1,19 @@
>> > +SUMMARY = "General-purpose library specifically developed for the WPE-flavored port of WebKit."
>> > +HOMEPAGE = "https://github.com/WebPlatformForEmbedded/libwpe"
>> > +BUGTRACKER = "https://github.com/WebPlatformForEmbedded/libwpe/issues"
>> > +
>> > +LICENSE = "BSD"
>> > +LIC_FILES_CHKSUM = "file://COPYING;md5=371a616eb4903c6cb79e9893a5f615cc"
>> > +DEPENDS = "virtual/egl libxkbcommon"
>> > +
>> > +# Workaround build issue with RPi userland EGL libraries.
>> > +CFLAGS_append_rpi = " ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', '-D_GNU_SOURCE', d)}"
>> > +
>> > +inherit cmake
>> > +
>> > +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
>> > +SRC_URI[md5sum] = "1d4d38413ee0d0043f74d0445cab906f"
>> > +SRC_URI[sha256sum] = "09849dfb34877354f34f318e138971cf22e677b2179e1f0a8ea00ab0b7bd8e9b"
>> > +SRC_URI[sha1sum] = "a41480a0a85cfa11b3f87f801b7c37bc3410e060"
>> > +SRC_URI[sha384sum] = "30488e375d956809a84b0d8af7b386a332541c77dcbd53496a896f894dbf39ac34534e935d6bc7a75c1b536f04f7f0a0"
>> > +SRC_URI[sha512sum] = "cbbe6b8e9bbb864d7f96bbdb56db262bbd341c86bc7bedfcc51be8077c0ea58a4e88c61b7b7bec937d5476e6cb81c093229bf80e3ee99452829287bd26175670"
>> > diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
>> > index 4aa8533b42..8d87ad49a3 100644
>> > --- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
>> > +++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
>> > @@ -44,7 +44,7 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
>> >                     libsecret \
>> >                    "
>> >
>> > -PACKAGECONFIG[wayland] = "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland"
>> > +PACKAGECONFIG[wayland] = "-DENABLE_WAYLAND_TARGET=ON,-DENABLE_WAYLAND_TARGET=OFF,wayland libwpe wpebackend-fdo wayland-native"
>> >  PACKAGECONFIG[x11] = "-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/libx11"
>> >  PACKAGECONFIG[geoclue] = "-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
>> >  PACKAGECONFIG[enchant] = "-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
>> > diff --git a/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>> > new file mode 100644
>> > index 0000000000..84df0c2535
>> > --- /dev/null
>> > +++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
>> > @@ -0,0 +1,19 @@
>> > +SUMMARY = "WPE's backend based on a freedesktop.org stack."
>> > +HOMEPAGE = "https://github.com/Igalia/WPEBackend-fdo"
>> > +BUGTRACKER = "https://github.com/Igalia/WPEBackend-fdo/issues"
>> > +
>> > +LICENSE = "BSD"
>> > +LIC_FILES_CHKSUM = "file://COPYING;md5=1f62cef2e3645e3e74eb05fd389d7a66"
>> > +DEPENDS = "glib-2.0 libxkbcommon wayland virtual/egl libwpe"
>> > +
>> > +DEPENDS_append_class-target = " wayland-native"
>> > +
>> > +inherit cmake
>> > +
>> > +SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz"
>> > +SRC_URI[md5sum] = "c6362491a4a38ddac42b66f140e1cff2"
>> > +SRC_URI[sha256sum] = "6249a0b7cbfa662206a8d2fa24e2c574e75c681ad0e93468091f1dc68ddb299d"
>> > +SRC_URI[sha1sum] = "9217c8a5511bc53544b42cb23390256580ac4b0c"
>> > +SRC_URI[sha384sum] = "79f3a28bc8e0a8240dc9962a6a245276d39dd8112a753d5ada39e98332d857eb9fc9c2879a702060807a10ea60be796d"
>> > +SRC_URI[sha512sum] = "8fdd13843c77b95b96b3feffea463bce565620997680e209a0cdcc09314a1469f2f1cb4744dceb2cf6c8d6ce5cb2bbdb4c7fbaf0451a687640c3f63bbdbfc4d4"
>> > +
>> > --
>> > 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

Re: [wpe-webkit] [PATCH 08/10] webkitgtk: unbreak wayland build

[Carlos Alberto Lopez Perez]

[-- Attachment #1.1: Type: text/plain, Size: 1822 bytes --]

On 23/02/2020 15:33, Joshua Watt wrote:
> On Sun, Feb 16, 2020 at 2:52 PM Alexander Kanavin
> <alex.kanavin@gmail.com> wrote:
>>
>> On Sun, 16 Feb 2020 at 21:15, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>> On Sun, Feb 16, 2020 at 7:52 AM Alexander Kanavin
>>> <alex.kanavin@gmail.com> wrote:
>>>>
>>>> webkit nowadays requires a couple of supplementary libraries for this,
>>>> so bring them in (courtesy of meta-browser, which will hopefully
>>>> adjust without a lot of trouble).
>>>
>>> its not meta-browser, I guess you should credit meta-wpe here [1]
>>> and perhaps Cc the meta-wpe maintainer as a courtesy.
>>
>>
>> Actually, it's copied from meta-webkit
>> https://github.com/Igalia/meta-webkit/
>> which does not say in the readme who the maintainer is, so I am not sure whom to CC.
>> I can adjust the commit msg though.
> 
> I've CC'd the WPE mailing list.
> 
> OE-core now has libwpe and wpebackend-fdo recipes. They should
> possibly be removed from meta-webkit to prevent duplication.
> 


Thanks for the notification. Its great that those recipes are shipped
now on the oe-core layer.

But I don't want to remove those recipes from meta-webkit, even if they
are shipped now there.

That recipes are an essential part of meta-webkit, so I want to be able
to raise the version or change them without depending on oe-core.
For example: sometimes we need to use older versions of yocto, but we
still want to use the last stable version of wpe/libwpe/wpebackend-fdo.
So I find pretty useful to have all the core WPE related recipes on the
meta-webkit layer and not depend on whatever oe-core ships.

There should be no conflict between the recipes as long as the name used
for them its the same, bitbake should simply pick the last version by
default.

Regards.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 914 bytes --]

Re: [wpe-webkit] [PATCH 08/10] webkitgtk: unbreak wayland build

[Joshua Watt]

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]

On Thu, Feb 27, 2020, 9:49 AM Carlos Alberto Lopez Perez <clopez@igalia.com>
wrote:

> On 23/02/2020 15:33, Joshua Watt wrote:
> > On Sun, Feb 16, 2020 at 2:52 PM Alexander Kanavin
> > <alex.kanavin@gmail.com> wrote:
> >>
> >> On Sun, 16 Feb 2020 at 21:15, Khem Raj <raj.khem@gmail.com> wrote:
> >>>
> >>> On Sun, Feb 16, 2020 at 7:52 AM Alexander Kanavin
> >>> <alex.kanavin@gmail.com> wrote:
> >>>>
> >>>> webkit nowadays requires a couple of supplementary libraries for this,
> >>>> so bring them in (courtesy of meta-browser, which will hopefully
> >>>> adjust without a lot of trouble).
> >>>
> >>> its not meta-browser, I guess you should credit meta-wpe here [1]
> >>> and perhaps Cc the meta-wpe maintainer as a courtesy.
> >>
> >>
> >> Actually, it's copied from meta-webkit
> >> https://github.com/Igalia/meta-webkit/
> >> which does not say in the readme who the maintainer is, so I am not
> sure whom to CC.
> >> I can adjust the commit msg though.
> >
> > I've CC'd the WPE mailing list.
> >
> > OE-core now has libwpe and wpebackend-fdo recipes. They should
> > possibly be removed from meta-webkit to prevent duplication.
> >
>
>
> Thanks for the notification. Its great that those recipes are shipped
> now on the oe-core layer.
>
> But I don't want to remove those recipes from meta-webkit, even if they
> are shipped now there.
>
> That recipes are an essential part of meta-webkit, so I want to be able
> to raise the version or change them without depending on oe-core.
> For example: sometimes we need to use older versions of yocto, but we
> still want to use the last stable version of wpe/libwpe/wpebackend-fdo.
> So I find pretty useful to have all the core WPE related recipes on the
> meta-webkit layer and not depend on whatever oe-core ships.
>
> There should be no conflict between the recipes as long as the name used
> for them its the same, bitbake should simply pick the last version by
> default.
>

The version compare actually only matters for recipes in the same layer; if
multiple layers provide the same recipe, the priority of the layers is what
determines which one gets chosen (even if that means an older version in a
higher priority layer would be chosen over a newer version in a lower
priority layer).

Anyway, you should be fine because meta-webkit has a priority of 7 and
oe-core is priority 5, so it will always choose the meta-webkit version, if
that layer is present.


>
> Regards.
>
>

[-- Attachment #2: Type: text/html, Size: 3660 bytes --]