Re: [OE-core] Yocto Project Status WW07'20

[Jain, Sangeeta]

Planned upcoming dot releases:

  *   YP 2.7.3 built and in QA

I didn't see any notification for this build. Am I missing something?

Thanks,
Sangeeta

From: openembedded-core-boun...@lists.openembedded.org 
 On Behalf Of 
sjolley.yp...@gmail.com
Sent: Wednesday, 19 February, 2020 12:10 AM
To: yo...@yoctoproject.org; openembedded-core@lists.openembedded.org
Subject: [OE-core] Yocto Project Status WW07'20


Current Dev Position: YP 3.1 M3

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


Next Team Meetings:

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


Key Status/Updates:

  *   The project recently updated its git hosting infrastructure and there 
were some issues encountered with the cgit http/https repository sharing. Those 
issues should now be resolved, apologies if they caused issues for anyone. The 
git:// protocol sharing was unaffected.
  *   YP 3.0.2 rc2 is in QA with the report due soon.
  *   We continue to see a small number of reproducibility issues with master 
which need resolving for green builds (in particular gstreamer and perl).
  *   A significant memory usage issue was identified during bitbake parsing 
where memory usage would grow in each parser thread linearly per number of 
recipes parsed. This would therefore particularly affect large numbers of 
layers, multilibs and multiconfig. The fix has merged into bitbake along with 
the corresponding zeus and warrior branches. For one test case it reduced peak 
memory usage during parsing for 5 multiconfigs from 20GB to 2GB.
  *   Warrior patches for 2.7.3 are out for review.
  *   With the git infrastructure issue updated, we now have centos8 workers 
added to the autobuilder.
  *   We are making various queued changes to the autobuilder configuration to 
fix bugs, improve efficiency and test coverage but this may result in some test 
result instability as we test and resolve issues.
  *   We're collecting a list of companies, products and projects which use the 
Yocto Project on the wiki: https://wiki.yoctoproject.org/wiki/Project_Users 
Please add any you know are missing (or email Richard/Stephen who can add).
  *   The triage team is worried about attendance at triage meetings and the 
project is finding it hard to find people to help fix bugs. If anyone is 
willing to work on bugs, assistance would be greatly appreciated.


YP 3.1 Milestone Dates:

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


Planned upcoming dot releases:

  *   YP 2.7.3 built and in QA
  *   YP 2.7.3 release date 2/21/2020
  *   YP 3.0.2 build date  2/3/2020
  *   YP 3.0.2 release date 2/14/2020


Tracking Metrics:

  *   WDD 2710 (last week 2728) 
(https://wiki.yoctoproject.org/charts/combo.html)
  *   Poky Patch Metrics

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


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

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


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


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

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
*Cell:(208) 244-4460
* Email:  sjolley.yp...@gmail.com

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

[OE-core] [PATCH v2] babeltrace: added ptest

[Anders Wallin]

Signed-off-by: Anders Wallin 
---
 .../distro/include/ptest-packagelists.inc |  1 +
 .../recipes-kernel/lttng/babeltrace/run-ptest |  9 ++
 meta/recipes-kernel/lttng/babeltrace_1.5.8.bb | 82 ++-
 3 files changed, 90 insertions(+), 2 deletions(-)
 create mode 100755 meta/recipes-kernel/lttng/babeltrace/run-ptest

diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
b/meta/conf/distro/include/ptest-packagelists.inc
index 23865ac3e1..752a0882dc 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -61,6 +61,7 @@ PTESTS_FAST = "\
 #"
 
 PTESTS_SLOW = "\
+babeltrace-ptest \
 busybox-ptest \
 dbus-test-ptest \
 e2fsprogs-ptest \
diff --git a/meta/recipes-kernel/lttng/babeltrace/run-ptest 
b/meta/recipes-kernel/lttng/babeltrace/run-ptest
new file mode 100755
index 00..f4b7ce11e2
--- /dev/null
+++ b/meta/recipes-kernel/lttng/babeltrace/run-ptest
@@ -0,0 +1,9 @@
+#!/bin/sh
+# use target=recheck if you want to recheck failing tests
+[ "$target" = "" ] && target=check
+
+# Without --ignore-exit, the tap harness causes any FAILs within a
+# test plan to raise ERRORs; this is just noise.
+makeargs="LOG_DRIVER_FLAGS=--ignore-exit top_srcdir=$PWD top_builddir=$PWD"
+
+exec make -C tests -k -s $makeargs $target 2>/dev/null
diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb 
b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb
index b6b7653037..c050dc674d 100644
--- a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb
+++ b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb
@@ -7,14 +7,92 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=76ba15dd76a248e1dd526bca0e2125fa"
 
 DEPENDS = "glib-2.0 util-linux popt bison-native flex-native"
 
-SRC_URI = 
"git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-1.5"
+SRC_URI = 
"git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-1.5 \
+  file://run-ptest \
+ "
 SRCREV = "054a54ae10b01a271afc4f19496c041b10fb414c"
 UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)$"
 
 S = "${WORKDIR}/git"
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig ptest
 
 EXTRA_OECONF = "--disable-debug-info"
 
 ASNEEDED = ""
+
+RDEPENDS_${PN}-ptest += "bash gawk"
+
+addtask do_patch_ptest_path after do_patch before do_configure
+do_patch_ptest_path () {
+for f in $(grep -l -r abs_top_srcdir ${S}/tests); do
+   sed -i 's:\@abs_top_srcdir\@:${PTEST_PATH}:' ${f}
+done
+
+for f in $(grep -l -r abs_top_builddir ${S}/tests); do
+   sed -i 's:\@abs_top_builddir\@:${PTEST_PATH}:' ${f}
+done
+for f in $(grep -l -r GREP ${S}/tests); do
+   sed -i 's:\@GREP\@:grep:' ${f}
+done
+
+for f in $(grep -l -r SED ${S}/tests); do
+   sed -i 's:\@SED\@:sed:' ${f}
+done
+}
+
+do_compile_ptest () {
+make -C tests all
+}
+
+do_install_ptest () {
+# Copy required files from source directory
+for f in config/tap-driver.sh config/test-driver; do
+   install -D "${S}/$f" "${D}${PTEST_PATH}/$f"
+done
+install -d "$f" "${D}${PTEST_PATH}/tests/ctf-traces/"
+cp -a ${S}/tests/ctf-traces/* ${D}${PTEST_PATH}/tests/ctf-traces/
+
+# Copy the tests directory tree and the executables and
+# Makefiles found within.
+install -D "${B}/tests/Makefile" "${D}${PTEST_PATH}/tests/"
+for d in $(find "${B}/tests" -type d -not -name .libs -printf '%P ') ; do
+   install -d "${D}${PTEST_PATH}/tests/$d"
+   find "${B}/tests/$d" -maxdepth 1 -executable -type f \
+-exec install -t "${D}${PTEST_PATH}/tests/$d" {} +
+   test -r "${B}/tests/$d/Makefile" && \
+   install -t "${D}${PTEST_PATH}/tests/$d" "${B}/tests/$d/Makefile"
+   find "${B}/tests/$d" -maxdepth 1 -name *.sh \
+-exec install -t "${D}${PTEST_PATH}/tests/$d" {} \;
+done
+
+for d in $(find "${B}/tests" -type d -name .libs -printf '%P ') ; do
+   for f in $(find "${B}/tests/$d" -maxdepth 1 -executable -type f -printf 
'%P ') ; do
+   cp ${B}/tests/$d/$f ${D}${PTEST_PATH}/tests/`dirname $d`/$f
+   done
+done
+
+install -D ${B}/formats/ctf/metadata/.libs/ctf-parser-test \
+   ${D}${PTEST_PATH}/formats/ctf/metadata/ctf-parser-test
+
+# Prevent attempts to update Makefiles during test runs, and
+# silence "Making check in $SUBDIR" messages.
+find "${D}${PTEST_PATH}" -name Makefile -type f -exec \
+sed -i \
+-e '/Makefile:/,/^$/d' \
+-e '/$(check_SCRIPTS)/s/^/#/' \
+-e '/%: %.in/,/^$/d' \
+-e '/echo "Making $$target in $$subdir"; \\/d' \
+-e 's/^srcdir = \(.*\)/srcdir = ./' \
+-e 's/^builddir = \(.*\)/builddir = ./' \
+-e 's/^all-am:.*/all-am:/' \
+{} +
+
+# Remove path to babeltrace.
+for f in $(grep -l -r "^BABELTRACE_BIN" ${D}${PTEST_PATH}); do
+   sed -i 's:^BABELTRACE_BIN.*:BABELTRACE_BIN=/usr/bin/babeltrace:' ${f}
+done
+for f in $(grep -l -r "^BTBIN" ${D}${PTEST_PATH}); d

[OE-core] [PATCH] mc: upgrade 4.8.23 -> 4.8.24

[Wang Mingyu]

0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch
0001-Add-option-to-control-configure-args.patch
Removed since they are included in 4.8.24.

Signed-off-by: Wang Mingyu 
---
 ...Add-option-to-control-configure-args.patch |  99 
 ...29-configure.ac-drop-bundled-gettext.patch | 110 --
 .../mc/{mc_4.8.23.bb => mc_4.8.24.bb} |   6 +-
 3 files changed, 2 insertions(+), 213 deletions(-)
 delete mode 100644 
meta/recipes-extended/mc/files/0001-Add-option-to-control-configure-args.patch
 delete mode 100644 
meta/recipes-extended/mc/files/0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch
 rename meta/recipes-extended/mc/{mc_4.8.23.bb => mc_4.8.24.bb} (88%)

diff --git 
a/meta/recipes-extended/mc/files/0001-Add-option-to-control-configure-args.patch
 
b/meta/recipes-extended/mc/files/0001-Add-option-to-control-configure-args.patch
deleted file mode 100644
index e76aac8161..00
--- 
a/meta/recipes-extended/mc/files/0001-Add-option-to-control-configure-args.patch
+++ /dev/null
@@ -1,99 +0,0 @@
-From a54501d3c9541bc8600225aa2d42531f93c6def7 Mon Sep 17 00:00:00 2001
-From: Joshua Watt 
-Date: Sat, 9 Nov 2019 20:01:48 -0600
-Subject: [PATCH] Add option to control configure args
-
-Embedding the configure time options into the executable can lead to
-non-reproducible builds, since configure options often have embedded
-paths. Add a configure time option to control if the configure args are
-embedded so this can be disabled.
-
-Upstream-Status: Submitted [https://midnight-commander.org/ticket/4031]
-Signed-off-by: Joshua Watt 

- configure.ac   | 6 ++
- src/args.c | 6 ++
- src/textconf.c | 2 ++
- 3 files changed, 14 insertions(+)
-
-diff --git a/configure.ac b/configure.ac
-index 19d1a76be..a1948f6b9 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -544,6 +544,12 @@ dnl Clarify do we really need GModule
- AM_CONDITIONAL([HAVE_GMODULE], [test -n "$g_module_supported" && \
- test x"$textmode_x11_support" = x"yes" -o 
x"$enable_aspell" = x"yes"])
- 
-+AC_ARG_ENABLE([configure-args],
-+AS_HELP_STRING([--enable-configure-args], [Handle all compiler warnings 
as errors]))
-+if test "x$enable_configure_args" != xno; then
-+AC_DEFINE([ENABLE_CONFIGURE_ARGS], 1, [Define to enable showing configure 
arguments in help])
-+fi
-+
- AC_DEFINE_UNQUOTED([MC_CONFIGURE_ARGS], ["$ac_configure_args"], [MC configure 
arguments])
- 
- AC_CONFIG_FILES(
-diff --git a/src/args.c b/src/args.c
-index baef1a1c8..f8dc24020 100644
 a/src/args.c
-+++ b/src/args.c
-@@ -95,7 +95,9 @@ static gboolean mc_args__nouse_subshell = FALSE;
- #endif /* ENABLE_SUBSHELL */
- static gboolean mc_args__show_datadirs = FALSE;
- static gboolean mc_args__show_datadirs_extended = FALSE;
-+#ifdef ENABLE_CONFIGURE_ARGS
- static gboolean mc_args__show_configure_opts = FALSE;
-+#endif
- 
- static GOptionGroup *main_group;
- 
-@@ -125,6 +127,7 @@ static const GOptionEntry argument_main_table[] = {
-  NULL
- },
- 
-+#ifdef ENABLE_CONFIGURE_ARGS
- /* show configure options */
- {
-  "configure-options", '\0', G_OPTION_FLAG_IN_MAIN, G_OPTION_ARG_NONE,
-@@ -132,6 +135,7 @@ static const GOptionEntry argument_main_table[] = {
-  N_("Print configure options"),
-  NULL
- },
-+#endif
- 
- {
-  "printwd", 'P', G_OPTION_FLAG_IN_MAIN, G_OPTION_ARG_STRING,
-@@ -758,11 +762,13 @@ mc_args_show_info (void)
- return FALSE;
- }
- 
-+#ifdef ENABLE_CONFIGURE_ARGS
- if (mc_args__show_configure_opts)
- {
- show_configure_options ();
- return FALSE;
- }
-+#endif
- 
- return TRUE;
- }
-diff --git a/src/textconf.c b/src/textconf.c
-index 1e0613e58..f39b9e028 100644
 a/src/textconf.c
-+++ b/src/textconf.c
-@@ -232,10 +232,12 @@ show_datadirs_extended (void)
- 
- /* 
-
 */
- 
-+#ifdef ENABLE_CONFIGURE_ARGS
- void
- show_configure_options (void)
- {
- (void) printf ("%s\n", MC_CONFIGURE_ARGS);
- }
-+#endif
- 
- /* 
-
 */
--- 
-2.23.0
-
diff --git 
a/meta/recipes-extended/mc/files/0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch
 
b/meta/recipes-extended/mc/files/0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch
deleted file mode 100644
index 8f357378d0..00
--- 
a/meta/recipes-extended/mc/files/0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch
+++ /dev/null
@@ -1,110 +0,0 @@
-From 0d677a014a87b968d79eea2353ac4e342b0fd4ca Mon Sep 17 00:00:00 2001
-From: Sergei Trofimovich 
-Date: Wed, 11 Sep 2019 22:58:18 +0100
-Subject: [PATCH] Ticket #3629: configure.ac: drop bundled gettext
-
-Bundled libintl did not support linking to internal static
-libraries (libmc in our case): directly specified static
-libraries are not pulled by libtool and are not usable for
-dynamic libraries as PIC-related

[OE-core] [PATCH 1/1] util-linux: fix hwclock settimeofday error

[Liwei Song]

The change of settimeofday() systemcall since Glibc 2.31
will cause "hwclock -s" doesn't work with error:
"hwclock: settimeofday() failed: Invalid argument"
Backport a upstream patch to fix this issue.

Signed-off-by: Liwei Song 
---
 ...lock-fix-for-glibc-2.31-settimeofday.patch | 112 ++
 .../util-linux/util-linux_2.34.bb |   1 +
 2 files changed, 113 insertions(+)
 create mode 100644 
meta/recipes-core/util-linux/util-linux/0001-hwclock-fix-for-glibc-2.31-settimeofday.patch

diff --git 
a/meta/recipes-core/util-linux/util-linux/0001-hwclock-fix-for-glibc-2.31-settimeofday.patch
 
b/meta/recipes-core/util-linux/util-linux/0001-hwclock-fix-for-glibc-2.31-settimeofday.patch
new file mode 100644
index ..0672c3546ae6
--- /dev/null
+++ 
b/meta/recipes-core/util-linux/util-linux/0001-hwclock-fix-for-glibc-2.31-settimeofday.patch
@@ -0,0 +1,112 @@
+From ee85d3967ea09b215fcea5efdd90bbbf5e74a681 Mon Sep 17 00:00:00 2001
+From: Karel Zak 
+Date: Wed, 19 Feb 2020 15:50:47 +0100
+Subject: [PATCH] hwclock: fix for glibc 2.31 settimeofday()
+
+glibc announce:
+  ... settimeofday can no longer be used to set the time and the offset
+  simultaneously. If both of its two arguments are non-null, the call
+  will fail (setting errno to EINVAL).
+
+It means we need to call settimeofday(NULL, tz) and settimeofday(tv, NULL).
+
+Unfortunately, settimeofday(NULL, tz) has very special warp-clock
+semantic if used as the very first settimeofday() call. It means we
+have to be sure that we do not touch warp-clock if we need only need
+to modify system TZ. So, let's always call settimeofday(NULL, 0)
+before settimeofday(NULL, tz) for UTC rtc mode when modify system TZ.
+
+Upstream-Status: Backport 
[https://github.com/karelzak/util-linux/commit/ee85d3967ea09b215fcea5efdd90bbbf5e74a681]
+
+CC: J William Piggott 
+Signed-off-by: Karel Zak 
+Addresses: https://github.com/karelzak/util-linux/issues/957
+Signed-off-by: Liwei Song 
+---
+ sys-utils/hwclock.c | 49 ++---
+ 1 file changed, 28 insertions(+), 21 deletions(-)
+
+diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
+index e736da7179f8..16576bc186ff 100644
+--- a/sys-utils/hwclock.c
 b/sys-utils/hwclock.c
+@@ -658,6 +658,9 @@ display_time(struct timeval hwctime)
+  * PCIL: persistent_clock_is_local, sets the "11 minute mode" timescale.
+  * firsttime: locks the warp_clock function (initialized to 1 at boot).
+  *
++ * Note that very first settimeofday(NULL, tz) modifies warp-clock as well as
++ * system TZ.
++ *
+  * 
+---+
+  * |  op | RTC scale | settimeofday calls 
 |
+  * 
|-|---|-|
+@@ -675,41 +678,45 @@ set_system_clock(const struct hwclock_control *ctl,
+   struct tm broken;
+   int minuteswest;
+   int rc = 0;
+-  const struct timezone tz_utc = { 0 };
+ 
+   localtime_r(&newtime.tv_sec, &broken);
+   minuteswest = -get_gmtoff(&broken) / 60;
+ 
+   if (ctl->verbose) {
+-  if (ctl->hctosys && !ctl->universal)
+-  printf(_("Calling settimeofday(NULL, %d) to set "
+-   "persistent_clock_is_local.\n"), minuteswest);
+-  if (ctl->systz && ctl->universal)
++  if (ctl->universal)
+   puts(_("Calling settimeofday(NULL, 0) "
+-  "to lock the warp function."));
++ "to lock the warp function."));
++  else
++  printf(_("Calling settimeofday(NULL, %d) to set "
++   "persistent_clock_is_local and "
++   "the kernel timezone.\n"), minuteswest);
++
++  if (ctl->universal && minuteswest)
++  printf(_("Calling settimeofday(NULL, %d) to set "
++   "the kernel timezone.\n"), minuteswest);
++
+   if (ctl->hctosys)
+-  printf(_("Calling settimeofday(%ld.%06ld, %d)\n"),
+- newtime.tv_sec, newtime.tv_usec, minuteswest);
+-  else {
+-  printf(_("Calling settimeofday(NULL, %d) "), 
minuteswest);
+-  if (ctl->universal)
+-   puts(_("to set the kernel timezone."));
+-  else
+-   puts(_("to warp System time."));
+-  }
++  printf(_("Calling settimeofday(%ld.%06ld, 0) to set "
++   "the kernel time.\n"), newtime.tv_sec, 
newtime.tv_usec);
+   }
+ 
+   if (!ctl->testing) {
++  const struct timezone tz_utc = { 0 };
+   const struct timezone tz = { minuteswest };
+ 
+-  if (ctl->hctosys && !ctl->universal)/* set PCIL */
++   

[OE-core] [PATCH] mesa: upgrade 19.3.3 -> 19.3.4

[Wang Mingyu]

Signed-off-by: Wang Mingyu 
---
 .../mesa/{mesa-gl_19.3.3.bb => mesa-gl_19.3.4.bb} | 0
 meta/recipes-graphics/mesa/{mesa_19.3.3.bb => mesa_19.3.4.bb} | 4 ++--
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_19.3.3.bb => mesa-gl_19.3.4.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_19.3.3.bb => mesa_19.3.4.bb} (88%)

diff --git a/meta/recipes-graphics/mesa/mesa-gl_19.3.3.bb 
b/meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_19.3.3.bb
rename to meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb
diff --git a/meta/recipes-graphics/mesa/mesa_19.3.3.bb 
b/meta/recipes-graphics/mesa/mesa_19.3.4.bb
similarity index 88%
rename from meta/recipes-graphics/mesa/mesa_19.3.3.bb
rename to meta/recipes-graphics/mesa/mesa_19.3.4.bb
index 7e0c5d6500..5f456c2429 100644
--- a/meta/recipes-graphics/mesa/mesa_19.3.3.bb
+++ b/meta/recipes-graphics/mesa/mesa_19.3.4.bb
@@ -9,8 +9,8 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
"
 
-SRC_URI[md5sum] = "00010e0bb8f6641276ff6cb3e9386114"
-SRC_URI[sha256sum] = 
"81ce4810bb25d61300f8104856461f4d49cf7cb794aa70cb572312e370c39f09"
+SRC_URI[md5sum] = "09e7700d9af511384d131fb77b5802cb"
+SRC_URI[sha256sum] = 
"1da467e6ae2799a517e242462331eafd29ae77d9872f3a845df81f7c308e8fe4"
 
 UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
 
-- 
2.17.1



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

[OE-core] [PATCH] libxkbcommon: upgrade 0.9.1 -> 0.10.0

[Wang Mingyu]

Signed-off-by: Wang Mingyu 
---
 .../{libxkbcommon_0.9.1.bb => libxkbcommon_0.10.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-lib/{libxkbcommon_0.9.1.bb => 
libxkbcommon_0.10.0.bb} (88%)

diff --git a/meta/recipes-graphics/xorg-lib/libxkbcommon_0.9.1.bb 
b/meta/recipes-graphics/xorg-lib/libxkbcommon_0.10.0.bb
similarity index 88%
rename from meta/recipes-graphics/xorg-lib/libxkbcommon_0.9.1.bb
rename to meta/recipes-graphics/xorg-lib/libxkbcommon_0.10.0.bb
index c147428a14..16d9c36eae 100644
--- a/meta/recipes-graphics/xorg-lib/libxkbcommon_0.9.1.bb
+++ b/meta/recipes-graphics/xorg-lib/libxkbcommon_0.10.0.bb
@@ -9,8 +9,8 @@ DEPENDS = "util-macros flex-native bison-native"
 
 SRC_URI = "http://xkbcommon.org/download/${BPN}-${PV}.tar.xz";
 
-SRC_URI[md5sum] = "4662756fd73ab0ac9e32efdad8f807f6"
-SRC_URI[sha256sum] = 
"d4c6aabf0a5c1fc616f8a6a65c8a818c03773b9a87da9fbc434da5acd1199be0"
+SRC_URI[md5sum] = "2d9ad3a46b317138b5e72a91cf105451"
+SRC_URI[sha256sum] = 
"57c3630cdc38fb4734cd57fa349e92244f5ae3862813e533cedbd86721a0b6f2"
 
 UPSTREAM_CHECK_URI = "http://xkbcommon.org/";
 
-- 
2.17.1



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

[OE-core] [PATCH] nfs-utils: upgrade 2.4.2 -> 2.4.3

[Wang Mingyu]

0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
Removed since it is included in 2.4.3.

refresh the following patch:
0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch

Signed-off-by: Wang Mingyu 
---
 ...-Don-t-build-tools-with-CC_FOR_BUILD.patch | 40 ---
 ...-fix-undefined-function-for-libnsm.a.patch | 12 --
 ...{nfs-utils_2.4.2.bb => nfs-utils_2.4.3.bb} |  5 +--
 3 files changed, 10 insertions(+), 47 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
 rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.4.2.bb => 
nfs-utils_2.4.3.bb} (96%)

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
deleted file mode 100644
index 23bc3eaf72..00
--- 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From 79019d976584c598f8d0a9d8de43c989946f974b Mon Sep 17 00:00:00 2001
-From: Pascal Bach 
-Date: Wed, 13 Feb 2019 09:28:07 +0100
-Subject: [PATCH] Don't build tools with CC_FOR_BUILD
-
-The tools are intended for the target not for the host.
-
-Upstream-Status: Pending
-
-Signed-off-by: Pascal Bach 

- tools/locktest/Makefile.am | 1 -
- tools/rpcgen/Makefile.am   | 1 -
- 2 files changed, 2 deletions(-)
-
-diff --git a/tools/locktest/Makefile.am b/tools/locktest/Makefile.am
-index 3156815..87d0bac 100644
 a/tools/locktest/Makefile.am
-+++ b/tools/locktest/Makefile.am
-@@ -1,6 +1,5 @@
- ## Process this file with automake to produce Makefile.in
- 
--CC=$(CC_FOR_BUILD)
- LIBTOOL = @LIBTOOL@ --tag=CC
- 
- noinst_PROGRAMS = testlk
-diff --git a/tools/rpcgen/Makefile.am b/tools/rpcgen/Makefile.am
-index 8a9ec89..3e092c9 100644
 a/tools/rpcgen/Makefile.am
-+++ b/tools/rpcgen/Makefile.am
-@@ -1,6 +1,5 @@
- ## Process this file with automake to produce Makefile.in
- 
--CC=$(CC_FOR_BUILD)
- LIBTOOL = @LIBTOOL@ --tag=CC
- 
- noinst_PROGRAMS = rpcgen
--- 
-2.11.0
-
diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
index fcb0e99b33..bd350144e3 100644
--- 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
+++ 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
@@ -28,10 +28,10 @@ Rebase it.
 Signed-off-by: Robert Yang 
 ---
  support/misc/Makefile.am |   2 +-
- support/misc/file.c  | 111 
---
+ support/misc/file.c  | 115 
---
  support/misc/misc.c  | 111 
+++
  support/nsm/Makefile.am  |   2 +-
- 4 files changed, 113 insertions(+), 113 deletions(-)
+ 4 files changed, 113 insertions(+), 117 deletions(-)
 
 diff --git a/support/misc/Makefile.am b/support/misc/Makefile.am
 index f9993e3..8b0e9db 100644
@@ -48,10 +48,10 @@ index f9993e3..8b0e9db 100644
  MAINTAINERCLEANFILES = Makefile.in
 diff --git a/support/misc/file.c b/support/misc/file.c
 deleted file mode 100644
-index e7c3819..000
+index 06f6bb2..000
 --- a/support/misc/file.c
 +++ /dev/null
-@@ -1,111 +0,0 @@
+@@ -1,115 +0,0 @@
 -/*
 - * Copyright 2009 Oracle.  All rights reserved.
 - * Copyright 2017 Red Hat, Inc.  All rights reserved.
@@ -72,6 +72,10 @@ index e7c3819..000
 - * along with nfs-utils.  If not, see .
 - */
 -
+-#ifdef HAVE_CONFIG_H
+-#include 
+-#endif
+-
 -#include 
 -
 -#include 
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.2.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb
similarity index 96%
rename from meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.2.bb
rename to meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb
index 6647d3428b..42a4ba3dbd 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.2.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb
@@ -30,11 +30,10 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
file://bugfix-adjust-statd-service-name.patch \
file://0001-cacheio-use-intmax_t-for-formatted-IO.patch \
file://0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch \
-   file://0001-Don-t-build-tools-with-CC_FOR_BUILD.patch \
file://clang-warnings.patch \
"
-SRC_URI[md5sum] = "d427c6b3014e9a04e8498f0598b1c1b9"
-SRC_URI[sha256sum] = 
"4464737a03d5f73ded2ffefe19d5543ed7b1d6c5419

[OE-core] [PATCH] man-pages: upgrade 5.04 -> 5.05

[Wang Mingyu]

Signed-off-by: Wang Mingyu 
---
 .../man-pages/{man-pages_5.04.bb => man-pages_5.05.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/man-pages/{man-pages_5.04.bb => 
man-pages_5.05.bb} (87%)

diff --git a/meta/recipes-extended/man-pages/man-pages_5.04.bb 
b/meta/recipes-extended/man-pages/man-pages_5.05.bb
similarity index 87%
rename from meta/recipes-extended/man-pages/man-pages_5.04.bb
rename to meta/recipes-extended/man-pages/man-pages_5.05.bb
index be456759fc..b95872eb4d 100644
--- a/meta/recipes-extended/man-pages/man-pages_5.04.bb
+++ b/meta/recipes-extended/man-pages/man-pages_5.05.bb
@@ -7,8 +7,8 @@ LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://README;md5=794f701617cc03fe50c53257660d8ec4"
 SRC_URI = "${KERNELORG_MIRROR}/linux/docs/${BPN}/${BP}.tar.gz"
 
-SRC_URI[md5sum] = "14d33d3fe02577a33aab26eb75df39cb"
-SRC_URI[sha256sum] = 
"8c6ab56b654a6dd00e3759279954a25fc68b258b8f493a75af55ea7b6401fdb2"
+SRC_URI[md5sum] = "cdad5deb15117e60a6d9e3a6bdc035b5"
+SRC_URI[sha256sum] = 
"43c33d2eea9ba989c18eef90298cf6d5521ff038deb51cda0ecd0fdc3cec2b7d"
 
 inherit manpages
 
-- 
2.17.1



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

[OE-core] [PATCH] libsolv: upgrade 0.7.10 -> 0.7.11

[Wang Mingyu]

Signed-off-by: Wang Mingyu 
---
 .../libsolv/{libsolv_0.7.10.bb => libsolv_0.7.11.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-extended/libsolv/{libsolv_0.7.10.bb => libsolv_0.7.11.bb} 
(93%)

diff --git a/meta/recipes-extended/libsolv/libsolv_0.7.10.bb 
b/meta/recipes-extended/libsolv/libsolv_0.7.11.bb
similarity index 93%
rename from meta/recipes-extended/libsolv/libsolv_0.7.10.bb
rename to meta/recipes-extended/libsolv/libsolv_0.7.11.bb
index 502f4e0e85..84349606f1 100644
--- a/meta/recipes-extended/libsolv/libsolv_0.7.10.bb
+++ b/meta/recipes-extended/libsolv/libsolv_0.7.11.bb
@@ -10,7 +10,7 @@ DEPENDS = "expat zlib"
 SRC_URI = "git://github.com/openSUSE/libsolv.git \
 "
 
-SRCREV = "605dd2645ef899e2b7c95709476fb51e28d7e378"
+SRCREV = "102ac552669181d3e43731aa275bdbbc7ddcb94c"
 
 UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+)"
 
-- 
2.17.1



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

[OE-core] [PATCH] lttng-modules: Check the pid_ns before using it because it may be NULL

[Li Zhou]

Check the pid_ns before using it because it may be NULL to fix below
issue:
<1>[ 22.637196] Unable to handle kernel NULL pointer dereference at
virtual address 0080
<1>[ 22.645982] Mem abort info:
<1>[ 22.648769] ESR = 0x9607
<1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits
<1>[ 22.657730] SET = 0, FnV = 0
<1>[ 22.660777] EA = 0, S1PTW = 0
<1>[ 22.663910] Data abort info:
<1>[ 22.666784] ISV = 0, ISS = 0x0007
<1>[ 22.670611] CM = 0, WnR = 0
<1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp =
12378f78
<1>[ 22.680180] [0080] pgd=7f023003,
pud=7f023003, pmd=7f01f003, pte=
<0>[ 22.690794] Internal error: Oops: 9607 [#1] PREEMPT SMP
<4>[ 22.690797] Modules linked in: adkNetD ncp
lttng_ring_buffer_client_overwrite(C)
lttng_ring_buffer_metadata_client(C) lttng_ring_buffer_client_discard(C)
lttng_ring_buffer_client_mmap_overwrite(C)
lttng_ring_buffer_client_mmap_discard(C)
lttng_ring_buffer_metadata_mmap_client(C) lttng_probe_signal(C)
lttng_probe_printk(C) lttng_probe_sched(C) lttng_probe_irq(C)
lttng_tracer(C) lttng_statedump(C) lttng_ftrace(C)
lttng_lib_ring_buffer(C) lttng_clock_plugin_arm_cntpct(C) lttng_clock(C)
<0>[ 22.690823] Process lttng-sessiond (pid: 3093, stack limit =
0x5d27910f)
<4>[ 22.690828] CPU: 1 PID: 3093 Comm: lttng-sessiond Tainted: G C
4.18.37-rt820-custom #1
<4>[ 22.690830] Hardware name: DUS33 (CPM2-20) (DT)
<4>[ 22.690833] pstate: 6005 (nZCv daif -PAN -UAO)
<4>[ 22.690845] pc : do_lttng_statedump+0xcc/0x8a8 [lttng_statedump]
<4>[ 22.690849] lr : do_lttng_statedump+0xc4/0x8a8 [lttng_statedump]
<4>[ 22.690851] sp : ffc07fe57ad0
<4>[ 22.690852] x29: ffc07fe57ad0 x28: ffc008ae2700
<4>[ 22.690856] x27: ff8000724000 x26: 0001
<4>[ 22.690859] x25: ff80089c9620 x24: 
<4>[ 22.690862] x23: ffc008ae2e10 x22: ff80089d3380
<4>[ 22.690865] x21: ffc07f45 x20: ffc008ae2700
<4>[ 22.690869] x19: 0007 x18: fffe
<4>[ 22.690871] x17:  x16: ff800824b980
<4>[ 22.690874] x15:  x14: 736162203b656e6f
<4>[ 22.690877] x13: 6e203d20676e6964 x12: 
<4>[ 22.690880] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
<4>[ 22.690882] x9 : 3c1f647968721eff x8 : ffc0877504c8
<4>[ 22.690886] x7 : 09093a7c093a7c08 x6 : ff8010c4b317
<4>[ 22.690888] x5 :  x4 : 0040a7575000
<4>[ 22.690891] x3 : ffc008ae2e28 x2 : 
<4>[ 22.690894] x1 :  x0 : 
<4>[ 22.690896] Call trace:
<4>[ 22.690902] do_lttng_statedump+0xcc/0x8a8 [lttng_statedump]
<4>[ 22.690905] lttng_statedump_start+0x20/0x30 [lttng_statedump]
<4>[ 22.690981] lttng_session_enable+0xf0/0x120 [lttng_tracer]
<4>[ 22.691018] lttng_session_ioctl+0x22c/0x328 [lttng_tracer]
<4>[ 22.691026] compat_sys_ioctl+0x110/0x778

Signed-off-by: Li Zhou 
---
 ...es-Check-the-pid_ns-before-using-it-becau.patch | 86 ++
 meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb  |  2 +
 2 files changed, 88 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch
new file mode 100644
index 000..5306c79
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch
@@ -0,0 +1,86 @@
+From 0c0072e005ce9d591518d1819a39264859132561 Mon Sep 17 00:00:00 2001
+From: Li Zhou 
+Date: Wed, 19 Feb 2020 11:14:38 +0800
+Subject: [PATCH] lttng-modules: Check the pid_ns before using it because it
+ may be NULL
+
+<1>[ 22.637196] Unable to handle kernel NULL pointer dereference at
+virtual address 0080
+<1>[ 22.645982] Mem abort info:
+<1>[ 22.648769] ESR = 0x9607
+<1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits
+<1>[ 22.657730] SET = 0, FnV = 0
+<1>[ 22.660777] EA = 0, S1PTW = 0
+<1>[ 22.663910] Data abort info:
+<1>[ 22.666784] ISV = 0, ISS = 0x0007
+<1>[ 22.670611] CM = 0, WnR = 0
+<1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp =
+12378f78
+<1>[ 22.680180] [0080] pgd=7f023003,
+pud=7f023003, pmd=7f01f003, pte=
+<0>[ 22.690794] Internal error: Oops: 9607 [#1] PREEMPT SMP
+<4>[ 22.690797] Modules linked in: adkNetD ncp
+lttng_ring_buffer_client_overwrite(C)
+lttng_ring_buffer_metadata_client(C) lttng_ring_buffer_client_discard(C)
+lttng_ring_buffer_client_mmap_overwrite(C)
+lttng_ring_buffer_client_mmap_discard(C)
+lttng_ring_buffer_metadata_mmap_client(C) lttng_probe_signal(C)
+lttng_probe_printk(C) lttng_probe_sched(C) lttng_probe_irq(C)
+lttng_tracer(C) lttng_statedump(C) lttng_ftrace(C)
+ltt

Re: [OE-core] You advice to append environment set up to local root shell profile

[JH]

May be I should append to shells script.

On 2/20/20, JH  wrote:
> Hi,
>
> I want to setup export LD_LIBRARY_PATH and export PATH to the
> /home/root shell profile, the oe-core base-files has a profile file,
> is it a right way to copy that file to my application layer, to extend
> it and to add new path to export LD_LIBRARY_PATH and export PATH? I'll
> handle it by a base-files_%.bbappend in my application layer.
>
> Thank you.
>
> Kind regards,
>
> - jh
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] You advice to append environment set up to local root shell profile

[JH]

Hi,

I want to setup export LD_LIBRARY_PATH and export PATH to the
/home/root shell profile, the oe-core base-files has a profile file,
is it a right way to copy that file to my application layer, to extend
it and to add new path to export LD_LIBRARY_PATH and export PATH? I'll
handle it by a base-files_%.bbappend in my application layer.

Thank you.

Kind regards,

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

[OE-core] [PATCH][master-next] webkitgtk: add PACKAGECONFIG gobject-introspection

[Andreas Müller]

Enable if 'gobject-introspection-data' is in DISTRO_FEATURES. This is what
gobject-introspection.bbclass does automatically for projects build with
autotools and meson.

It was checked: there are webkitgtk and libdnf inheriting gobject-introspection
and cmake. Since libdnf cannot configure gir, webkitgtk seems the only project
requiring gir-auto-enabling. So handle at recipe / no common magic at
gobject-introspection.bbclass required.

Signed-off-by: Andreas Müller 
---

This patch applies on top of master-next/Alex's patches sent

 meta/recipes-sato/webkit/webkitgtk_2.26.4.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
index 585723772e..d5085620d2 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
@@ -39,6 +39,7 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt 
libidn libgcrypt \
   "
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 
'gobject-introspection-data', 'gobject-introspection', '' ,d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl 
opengl', '' ,d)} \
enchant \
libsecret \
@@ -46,6 +47,7 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 
'wayland x11', d)} \
 
 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[gobject-introspection] = 
"-DENABLE_INTROSPECTION=ON,-DENABLE_INTROSPECTION=OFF"
 PACKAGECONFIG[geoclue] = 
"-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
 PACKAGECONFIG[enchant] = 
"-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
 PACKAGECONFIG[gtk2] = 
"-DENABLE_PLUGIN_PROCESS_GTK2=ON,-DENABLE_PLUGIN_PROCESS_GTK2=OFF,gtk+"
-- 
2.21.0

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

Re: [OE-core] [PATCH] local.conf.sample.extended: Document how to limit parallel fetch tasks

[Andre McCurdy]

On Wed, Feb 19, 2020 at 3:16 PM Richard Purdie
 wrote:
>
> On Wed, 2020-02-19 at 14:05 -0800, Andre McCurdy wrote:
> > On Wed, Feb 19, 2020 at 1:43 PM Richard Purdie
> >  wrote:
> > > [YOCTO #13235]
> > >
> > > Signed-off-by: Richard Purdie 
> > > ---
> > >  meta/conf/local.conf.sample.extended | 8 
> > >  1 file changed, 8 insertions(+)
> > >
> > > diff --git a/meta/conf/local.conf.sample.extended
> > > b/meta/conf/local.conf.sample.extended
> > > index fcf4a9b7c1a..443b4e83f9a 100644
> > > --- a/meta/conf/local.conf.sample.extended
> > > +++ b/meta/conf/local.conf.sample.extended
> > > @@ -23,6 +23,14 @@
> > >  #
> > >  # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE
> > > = "-j 4" would
> > >  # be appropriate for example.
> > > +#
> > > +# Some users are behind firewalls or use servers where the number
> > > of parallel connections
> > > +# is limited. In such cases you can limit the number of fetch
> > > tasks which run in parallel by
> > > +# setting the option below, in this case limiting to a maximum of
> > > 4 fetch tasks in parallel:
> > > +#
> > > +#do_fetch[number_threads] = "4"
> >
> > How does this interact with BB_NUMBER_THREADS? If, for example, both
> > are set to 4 does it mean there could be 4 fetch threads and 4
> > compile threads running in parallel?
>
> BB_NUMBER_THREADS is an upper limit which includes fetch tasks.
>
> > A related issue when the number of parallel connections is limited is
> > parsing a large number of AUTOREV recipes. From what I remember the
> > workaround for that was to set BB_NUMBER_PARSE_THREADS. Maybe that
> > should be documented in local.conf.sample.extended too? Perhaps even
> > better would be to define a single new variable which limits the
> > number of parallel connections in both cases?
>
> I don't know how you'd implement a total number of connections limit
> from a code perspective :/.

A single variable such as BB_MAX_CONNECTION_THREADS which, if defined,
would set the limit for both do_fetch[number_threads] and
BB_NUMBER_PARSE_THREADS ?

> You'd probably need something like a make job server where you obtained
> tokens before making connections and I can see this becoming "fun"
> since you'd have to markup every code section where a network
> connection was made.
>
> We have a conflict between code complexity, maintainability,
> performance and functionality and I'm not sure the use case here
> warrants the complexity...

Of course. I just wanted to share it since it is a real world problem
(I've seen a development team stumped for a few days before finding
BB_NUMBER_PARSE_THREADS, which isn't nearly as well documented as
BB_NUMBER_THREADS and PARALLEL_MAKE). A comment for
BB_NUMBER_PARSE_THREADS in local.conf.sample.extended might have sped
up that debugging process.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 03/13] webkitgtk: unbreak wayland build

[Richard Purdie]

On Wed, 2020-02-19 at 20:47 +0100, Alexander Kanavin wrote:
> webkit nowadays requires a couple of supplementary libraries for
> this,
> so bring them in (courtesy of meta-webkit[1], which will hopefully
> adjust without a lot of trouble).
> 
> [1] https://github.com/Igalia/meta-webkit/
> 
> Signed-off-by: Alexander Kanavin 

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

(missing MAINTAINERs)

Cheers,

Richard

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

Re: [OE-core] [PATCH] local.conf.sample.extended: Document how to limit parallel fetch tasks

[Richard Purdie]

On Wed, 2020-02-19 at 14:05 -0800, Andre McCurdy wrote:
> On Wed, Feb 19, 2020 at 1:43 PM Richard Purdie
>  wrote:
> > [YOCTO #13235]
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/conf/local.conf.sample.extended | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/meta/conf/local.conf.sample.extended
> > b/meta/conf/local.conf.sample.extended
> > index fcf4a9b7c1a..443b4e83f9a 100644
> > --- a/meta/conf/local.conf.sample.extended
> > +++ b/meta/conf/local.conf.sample.extended
> > @@ -23,6 +23,14 @@
> >  #
> >  # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE
> > = "-j 4" would
> >  # be appropriate for example.
> > +#
> > +# Some users are behind firewalls or use servers where the number
> > of parallel connections
> > +# is limited. In such cases you can limit the number of fetch
> > tasks which run in parallel by
> > +# setting the option below, in this case limiting to a maximum of
> > 4 fetch tasks in parallel:
> > +#
> > +#do_fetch[number_threads] = "4"
> 
> How does this interact with BB_NUMBER_THREADS? If, for example, both
> are set to 4 does it mean there could be 4 fetch threads and 4
> compile threads running in parallel?

BB_NUMBER_THREADS is an upper limit which includes fetch tasks.

> A related issue when the number of parallel connections is limited is
> parsing a large number of AUTOREV recipes. From what I remember the
> workaround for that was to set BB_NUMBER_PARSE_THREADS. Maybe that
> should be documented in local.conf.sample.extended too? Perhaps even
> better would be to define a single new variable which limits the
> number of parallel connections in both cases?

I don't know how you'd implement a total number of connections limit
from a code perspective :/.

You'd probably need something like a make job server where you obtained
tokens before making connections and I can see this becoming "fun"
since you'd have to markup every code section where a network
connection was made.

We have a conflict between code complexity, maintainability,
performance and functionality and I'm not sure the use case here
warrants the complexity...

Cheers,

Richard





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

[OE-core] [PATCH] scripts/combo-layer: Fix deprecation warning

[Richard Purdie]

Resolve:
combo-layer:83: DeprecationWarning: This method will be removed in future 
versions.  Use 'parser.read_file()' instead.

Signed-off-by: Richard Purdie 
---
 scripts/combo-layer | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/combo-layer b/scripts/combo-layer
index 9b50e9873da..a634dd69d2a 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -80,7 +80,7 @@ class Configuration(object):
 logger.debug("Loading config file %s" % self.conffile)
 self.parser = configparser.ConfigParser()
 with open(self.conffile) as f:
-self.parser.readfp(f)
+self.parser.read_file(f)
 
 # initialize default values
 self.commit_msg_template = "Automatic commit to update last_revision"
-- 
2.25.0

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

[OE-core] ✗ patchtest: failure for distro_alias: Fix typos

[Patchwork]

== Series Details ==

Series: distro_alias: Fix typos
Revision: 1
URL   : https://patchwork.openembedded.org/series/22770/
State : failure

== Summary ==


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



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



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

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

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

[OE-core] ✗ patchtest: failure for local.conf.sample.extended: Document how to limit parallel fetch tasks (rev2)

[Patchwork]

== Series Details ==

Series: local.conf.sample.extended: Document how to limit parallel fetch tasks 
(rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/22768/
State : failure

== Summary ==


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



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



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

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

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

Re: [OE-core] [PATCH 3/3] oeqa/selftest: Drop 'backup' code and SIGTERM handler

[Richard Purdie]

On Wed, 2020-02-19 at 22:26 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org <
> > openembedded-core-boun...@lists.openembedded.org> On Behalf Of
> > Richard Purdie
> > Sent: den 19 februari 2020 19:38
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH 3/3] oeqa/selftest: Drop 'backup' code
> > and SIGTERM handler
> > 
> > Now selftest is using its own copied build directory, we can stop
> > worrying about
> > copying files around as backup, and drop the SIGTERM handler to try
> > and restore
> > them, simplifying the code.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/lib/oeqa/selftest/case.py| 30 +---
> >  meta/lib/oeqa/selftest/context.py | 47 ++-
> > 
> >  2 files changed, 4 insertions(+), 73 deletions(-)
> 
> [cut]
> 
> > @@ -329,18 +311,9 @@ class
> > OESelftestTestContextExecutor(OETestContextExecutor):
> > 
> >  return rc
> > 
> > -def _signal_clean_handler(self, signum, frame):
> > -if self.ourpid == os.getpid():
> > -sys.exit(1)
> > -
> >  def run(self, logger, args):
> >  self._process_args(logger, args)
> > 
> > -# Setup a SIGTERM handler to allow restoration of files
> > like local.conf and bblayers.conf
> > -# but don't interfer with other processes
> > -self.ourpid = os.getpid()
> > -signal.signal(signal.SIGTERM, self._signal_clean_handler)
> > -
> 
> What's the point of the first patch in this series, when you just 
> remove it all again here in the third patch?

The bug affects stable series builds as well as master. We're probably
unlikely to accept 2/3 or 3/3 into stable builds? I therefore wrote it
as a series, just in case the stable maintainers do pick up 1/3 which
I'd figured out before writing 2/3 and 3/3.

Cheers,

Richard


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

Re: [OE-core] [PATCH 3/3] oeqa/selftest: Drop 'backup' code and SIGTERM handler

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
>  On Behalf Of Richard Purdie
> Sent: den 19 februari 2020 19:38
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 3/3] oeqa/selftest: Drop 'backup' code and SIGTERM 
> handler
> 
> Now selftest is using its own copied build directory, we can stop worrying 
> about
> copying files around as backup, and drop the SIGTERM handler to try and 
> restore
> them, simplifying the code.
> 
> Signed-off-by: Richard Purdie 
> ---
>  meta/lib/oeqa/selftest/case.py| 30 +---
>  meta/lib/oeqa/selftest/context.py | 47 ++-
>  2 files changed, 4 insertions(+), 73 deletions(-)

[cut]

> @@ -329,18 +311,9 @@ class
> OESelftestTestContextExecutor(OETestContextExecutor):
> 
>  return rc
> 
> -def _signal_clean_handler(self, signum, frame):
> -if self.ourpid == os.getpid():
> -sys.exit(1)
> -
>  def run(self, logger, args):
>  self._process_args(logger, args)
> 
> -# Setup a SIGTERM handler to allow restoration of files like 
> local.conf and bblayers.conf
> -# but don't interfer with other processes
> -self.ourpid = os.getpid()
> -signal.signal(signal.SIGTERM, self._signal_clean_handler)
> -

What's the point of the first patch in this series, when you just 
remove it all again here in the third patch?

>  rc = None
>  try:
>  if args.machine:

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

[OE-core] [PATCH] distro_alias: Fix typos

[Richard Purdie]

[YOCTO #13433]

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/include/distro_alias.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/distro/include/distro_alias.inc 
b/meta/conf/distro/include/distro_alias.inc
index e314642b9c3..79ebcaee299 100644
--- a/meta/conf/distro/include/distro_alias.inc
+++ b/meta/conf/distro/include/distro_alias.inc
@@ -15,7 +15,7 @@ DISTRO_PN_ALIAS_pn-alsa-utils-scripts = "OE-Core"
 DISTRO_PN_ALIAS_pn-atk = "Fedora=atk OpenSuSE=atk"
 DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover"
 DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT"
-DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debina=bjam"
+DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debian=bjam"
 DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool"
 DISTRO_PN_ALIAS_pn-bluez5 = "Fedora=bluez  Opensuse=bluez"
 DISTRO_PN_ALIAS_pn-bootchart2 = "Fedora=bootchart2 Opensuse=bootchart"
@@ -130,7 +130,7 @@ DISTRO_PN_ALIAS_pn-initramfs-live-install = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install-efi = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install-efi-testfs = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install-testfs = "OE-Core"
-DISTRO_PN_ALIAS_pn-initscripts = "Fedora=initscripts Mandravia=initscripts"
+DISTRO_PN_ALIAS_pn-initscripts = "Fedora=initscripts Mandriva=initscripts"
 DISTRO_PN_ALIAS_pn-iproute2 = "OSPDT"
 DISTRO_PN_ALIAS_pn-jpeg = "OpenSuSE=libjpeg Ubuntu=libjpeg62"
 DISTRO_PN_ALIAS_pn-kernel-devsrc = "Debian=linux-base Ubuntu=linux"
-- 
2.25.0

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

[OE-core] [PATCH] local.conf.sample.extended: Document how to limit parallel fetch tasks

[Richard Purdie]

[YOCTO #13235]

Signed-off-by: Richard Purdie 
---
 meta/conf/local.conf.sample.extended | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/conf/local.conf.sample.extended 
b/meta/conf/local.conf.sample.extended
index fcf4a9b7c1a..443b4e83f9a 100644
--- a/meta/conf/local.conf.sample.extended
+++ b/meta/conf/local.conf.sample.extended
@@ -23,6 +23,14 @@
 #
 # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" 
would
 # be appropriate for example.
+#
+# Some users are behind firewalls or use servers where the number of parallel 
connections
+# is limited. In such cases you can limit the number of fetch tasks which run 
in parallel by
+# setting the option below, in this case limiting to a maximum of 4 fetch 
tasks in parallel:
+#
+#do_fetch[number_threads] = "4"
+#
+
 
 #DISTRO_FEATURES = "alsa bluetooth ext2 irda ipv4 ipv6 pcmcia usbgadget 
usbhost wifi nfs zeroconf pci"
 
-- 
2.25.0

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

Re: [OE-core] [PATCH] local.conf.sample.extended: Document how to limit parallel fetch tasks

[Andre McCurdy]

On Wed, Feb 19, 2020 at 1:43 PM Richard Purdie
 wrote:
>
> [YOCTO #13235]
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/conf/local.conf.sample.extended | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/meta/conf/local.conf.sample.extended 
> b/meta/conf/local.conf.sample.extended
> index fcf4a9b7c1a..443b4e83f9a 100644
> --- a/meta/conf/local.conf.sample.extended
> +++ b/meta/conf/local.conf.sample.extended
> @@ -23,6 +23,14 @@
>  #
>  # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" 
> would
>  # be appropriate for example.
> +#
> +# Some users are behind firewalls or use servers where the number of 
> parallel connections
> +# is limited. In such cases you can limit the number of fetch tasks which 
> run in parallel by
> +# setting the option below, in this case limiting to a maximum of 4 fetch 
> tasks in parallel:
> +#
> +#do_fetch[number_threads] = "4"

How does this interact with BB_NUMBER_THREADS? If, for example, both
are set to 4 does it mean there could be 4 fetch threads and 4 compile
threads running in parallel?

A related issue when the number of parallel connections is limited is
parsing a large number of AUTOREV recipes. From what I remember the
workaround for that was to set BB_NUMBER_PARSE_THREADS. Maybe that
should be documented in local.conf.sample.extended too? Perhaps even
better would be to define a single new variable which limits the
number of parallel connections in both cases?

> +#
> +
>
>  #DISTRO_FEATURES = "alsa bluetooth ext2 irda ipv4 ipv6 pcmcia usbgadget 
> usbhost wifi nfs zeroconf pci"
>
> --
> 2.25.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] local.conf.sample.extended: Document how to limit parallel fetch tasks

[Richard Purdie]

[YOCTO #13235]

Signed-off-by: Richard Purdie 
---
 meta/conf/local.conf.sample.extended | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/conf/local.conf.sample.extended 
b/meta/conf/local.conf.sample.extended
index fcf4a9b7c1a..443b4e83f9a 100644
--- a/meta/conf/local.conf.sample.extended
+++ b/meta/conf/local.conf.sample.extended
@@ -23,6 +23,14 @@
 #
 # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" 
would
 # be appropriate for example.
+#
+# Some users are behind firewalls or use servers where the number of parallel 
connections
+# is limited. In such cases you can limit the number of fetch tasks which run 
in parallel by
+# setting the option below, in this case limiting to a maximum of 4 fetch 
tasks in parallel:
+#
+#do_fetch[number_threads] = "4"
+#
+
 
 #DISTRO_FEATURES = "alsa bluetooth ext2 irda ipv4 ipv6 pcmcia usbgadget 
usbhost wifi nfs zeroconf pci"
 
-- 
2.25.0

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

[OE-core] [PATCH v2] libubootenv: bump to revision ba952d0

[Pierre-Jean Texier via Openembedded-core]

This includes following changes:

ba952d0 BUG: variable lists not released in close()
690f868 Variables are not removed when loading from file
9e3586a Make sure there's no file descriptor leakage in case of error
03647c4 Check config file defines a non-zero Sector size
3b2d4f1 Check environment size from fw_env.config

Signed-off-by: Pierre-Jean Texier 
Acked-by: Stefano Babic 
---
changes v1 -> v2
- introduce PV variable (suggested by Alexander Kanavin)

 meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
index f5b6059..7a7ec4c 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -11,8 +11,9 @@ LICENSE = "LGPL-2.1"
 LIC_FILES_CHKSUM = 
"file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b364516c"
 SECTION = "libs"
 
+PV = "0.2+git${SRCPV}"
 SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
-SRCREV = "879c0731fa0725785b9fa4499bbf6aacd04ee4c2"
+SRCREV = "ba952d05ec9ab16029816a06d956bac7fb4e9832"
 
 S = "${WORKDIR}/git"
 
-- 
2.7.4

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

Re: [OE-core] [PATCH] libubootenv: bump to revision ba952d0

[Pierre-Jean Texier via Openembedded-core]

Hi Alex,

Le 19/02/2020 à 22:17, Alexander Kanavin a écrit :

If PV doesn't change, package managers will not be able to update this
properly. You need to set it to something like 0.2+git${SRCPV}


Sure, you're indeed right.
I will send a v2.

Thanks !
--
Pierre-Jean Texier
Embedded Linux Engineer
https://koncepto.io
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] lttng-tools: upgrade 2.11.0 -> 2.11.2

[Richard Purdie]

Signed-off-by: Richard Purdie 
---
 .../lttng/{lttng-tools_2.11.0.bb => lttng-tools_2.11.2.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-kernel/lttng/{lttng-tools_2.11.0.bb => 
lttng-tools_2.11.2.bb} (98%)

diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.11.0.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb
similarity index 98%
rename from meta/recipes-kernel/lttng/lttng-tools_2.11.0.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb
index 9cb896314b8..36a19ec18d8 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.11.0.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb
@@ -36,8 +36,8 @@ SRC_URI = 
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://0001-tests-regression-disable-the-tools-live-tests.patch \
"
 
-SRC_URI[md5sum] = "e6c23244a36e2a09783d03a362eb63cb"
-SRC_URI[sha256sum] = 
"dce493c82db673c96049b5fad155a760fa449fab3d92467a69fcb0ddaf3f0fbc"
+SRC_URI[md5sum] = "68ed78f7fa4235477ea577e48b3cd245"
+SRC_URI[sha256sum] = 
"936477305b25f65c5dd22db9161287d30a309ce868b6180857b1fd1fb5e6a56b"
 
 inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
 
-- 
2.25.0

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

Re: [OE-core] [PATCH] libubootenv: bump to revision ba952d0

[Stefano Babic]

Hallo Jean-Pierre,

On 19/02/20 22:08, Pierre-Jean Texier wrote:
> This includes following changes:
> 
> ba952d0 BUG: variable lists not released in close()
> 690f868 Variables are not removed when loading from file
> 9e3586a Make sure there's no file descriptor leakage in case of error
> 03647c4 Check config file defines a non-zero Sector size
> 3b2d4f1 Check environment size from fw_env.config
> 
> Signed-off-by: Pierre-Jean Texier 
> ---
>  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
> b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> index f5b6059..ac49b68 100644
> --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> @@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = 
> "file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b36
>  SECTION = "libs"
>  
>  SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
> -SRCREV = "879c0731fa0725785b9fa4499bbf6aacd04ee4c2"
> +SRCREV = "ba952d05ec9ab16029816a06d956bac7fb4e9832"
>  
>  S = "${WORKDIR}/git"
>  
> 

Acked-by: Stefano Babic 

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libubootenv: bump to revision ba952d0

[Alexander Kanavin]

If PV doesn't change, package managers will not be able to update this
properly. You need to set it to something like 0.2+git${SRCPV}

Alex

On Wed, 19 Feb 2020 at 22:08, Pierre-Jean Texier via Openembedded-core <
openembedded-core@lists.openembedded.org> wrote:

> This includes following changes:
>
> ba952d0 BUG: variable lists not released in close()
> 690f868 Variables are not removed when loading from file
> 9e3586a Make sure there's no file descriptor leakage in case of error
> 03647c4 Check config file defines a non-zero Sector size
> 3b2d4f1 Check environment size from fw_env.config
>
> Signed-off-by: Pierre-Jean Texier 
> ---
>  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> index f5b6059..ac49b68 100644
> --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> @@ -12,7 +12,7 @@ LIC_FILES_CHKSUM =
> "file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b36
>  SECTION = "libs"
>
>  SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
> -SRCREV = "879c0731fa0725785b9fa4499bbf6aacd04ee4c2"
> +SRCREV = "ba952d05ec9ab16029816a06d956bac7fb4e9832"
>
>  S = "${WORKDIR}/git"
>
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libubootenv: bump to revision ba952d0

[Pierre-Jean Texier via Openembedded-core]

This includes following changes:

ba952d0 BUG: variable lists not released in close()
690f868 Variables are not removed when loading from file
9e3586a Make sure there's no file descriptor leakage in case of error
03647c4 Check config file defines a non-zero Sector size
3b2d4f1 Check environment size from fw_env.config

Signed-off-by: Pierre-Jean Texier 
---
 meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
index f5b6059..ac49b68 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = 
"file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b36
 SECTION = "libs"
 
 SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
-SRCREV = "879c0731fa0725785b9fa4499bbf6aacd04ee4c2"
+SRCREV = "ba952d05ec9ab16029816a06d956bac7fb4e9832"
 
 S = "${WORKDIR}/git"
 
-- 
2.7.4

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

[OE-core] [meta-oe][PATCH v4] iproute2: add devlink support to iproute2

[Scott Branden via Openembedded-core]

Add devlink support to iproute2 recipe.

Signed-off-by: Scott Branden 
---
 .../iproute2/iproute2.inc | 34 +--
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/meta/recipes-connectivity/iproute2/iproute2.inc 
b/meta/recipes-connectivity/iproute2/iproute2.inc
index fc31b8444e..403d264308 100644
--- a/meta/recipes-connectivity/iproute2/iproute2.inc
+++ b/meta/recipes-connectivity/iproute2/iproute2.inc
@@ -15,12 +15,19 @@ inherit update-alternatives bash-completion pkgconfig
 
 CLEANBROKEN = "1"
 
-PACKAGECONFIG ??= "tipc elf"
+PACKAGECONFIG ??= "tipc elf devlink"
 PACKAGECONFIG[tipc] = ",,libmnl,"
 PACKAGECONFIG[elf] = ",,elfutils,"
+PACKAGECONFIG[devlink] = ",,libmnl,"
 
-EXTRA_OEMAKE = "CC='${CC}' KERNEL_INCLUDE=${STAGING_INCDIR} 
DOCDIR=${docdir}/iproute2 SUBDIRS='lib tc ip bridge misc genl \
-${@bb.utils.contains('PACKAGECONFIG', 'tipc', 'tipc', '', d)}' 
SBINDIR='${base_sbindir}' LIBDIR='${libdir}'"
+EXTRA_OEMAKE = "\
+CC='${CC}' \
+KERNEL_INCLUDE=${STAGING_INCDIR} \
+DOCDIR=${docdir}/iproute2 \
+SUBDIRS='lib tc ip bridge misc genl ${@bb.utils.filter('PACKAGECONFIG', 
'devlink tipc', d)}' \
+SBINDIR='${base_sbindir}' \
+LIBDIR='${libdir}' \
+"
 
 do_configure_append () {
 sh configure ${STAGING_INCDIR}
@@ -39,14 +46,18 @@ do_install () {
 # The .so files in iproute2-tc are modules, not traditional libraries
 INSANE_SKIP_${PN}-tc = "dev-so"
 
-PACKAGES =+ "${PN}-tc \
- ${PN}-lnstat \
- ${PN}-ifstat \
- ${PN}-genl \
- ${PN}-rtacct \
- ${PN}-nstat \
- ${PN}-ss \
- ${@bb.utils.contains('PACKAGECONFIG', 'tipc', '${PN}-tipc', '', 
d)}"
+PACKAGES =+ "\
+${PN}-devlink \
+${PN}-genl \
+${PN}-ifstat \
+${PN}-lnstat \
+${PN}-nstat \
+${PN}-rtacct \
+${PN}-ss \
+${PN}-tc \
+${PN}-tipc \
+"
+
 FILES_${PN}-tc = "${base_sbindir}/tc* \
   ${libdir}/tc/*.so"
 FILES_${PN}-lnstat = "${base_sbindir}/lnstat \
@@ -58,6 +69,7 @@ FILES_${PN}-rtacct = "${base_sbindir}/rtacct"
 FILES_${PN}-nstat = "${base_sbindir}/nstat"
 FILES_${PN}-ss = "${base_sbindir}/ss"
 FILES_${PN}-tipc = "${base_sbindir}/tipc"
+FILES_${PN}-devlink = "${base_sbindir}/devlink"
 
 ALTERNATIVE_${PN} = "ip"
 ALTERNATIVE_TARGET[ip] = "${base_sbindir}/ip.${BPN}"
-- 
2.17.1

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

Re: [OE-core] [meta-oe][PATCH v3] iproute2: add devlink support to iproute2

[Scott Branden via Openembedded-core]

Sorry,  I will compile test when making simple changes suggested by 
others from now.

New version being submitted.

On 2020-02-19 8:30 a.m., Richard Purdie wrote:

On Tue, 2020-02-18 at 16:38 -0800, Scott Branden via Openembedded-core wrote:

Add devlink support to iproute2 recipe.

Signed-off-by: Scott Branden 
---
  .../iproute2/iproute2.inc | 34 +--
  1 file changed, 23 insertions(+), 11 deletions(-)


Doesn't build:

https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1822

(and a ton more)

Cheers,

Richard



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

[OE-core] [PATCH 11/13] p11-kit: upgrade 0.23.18.1 -> 0.23.20

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 .../p11-kit/{p11-kit_0.23.18.1.bb => p11-kit_0.23.20.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-support/p11-kit/{p11-kit_0.23.18.1.bb => 
p11-kit_0.23.20.bb} (93%)

diff --git a/meta/recipes-support/p11-kit/p11-kit_0.23.18.1.bb 
b/meta/recipes-support/p11-kit/p11-kit_0.23.20.bb
similarity index 93%
rename from meta/recipes-support/p11-kit/p11-kit_0.23.18.1.bb
rename to meta/recipes-support/p11-kit/p11-kit_0.23.20.bb
index 19895ec269..26833ef431 100644
--- a/meta/recipes-support/p11-kit/p11-kit_0.23.18.1.bb
+++ b/meta/recipes-support/p11-kit/p11-kit_0.23.20.bb
@@ -9,7 +9,7 @@ DEPENDS = "libtasn1 libtasn1-native libffi"
 DEPENDS_append = "${@' glib-2.0' if d.getVar('GTKDOC_ENABLED') == 'True' else 
''}"
 
 SRC_URI = "git://github.com/p11-glue/p11-kit"
-SRCREV = "b0ebe7555c291808db29377ba79cb8326301f0a6"
+SRCREV = "762cdaa2cd5c5ec09cc844f9a6bdc551c7f6c8ed"
 S = "${WORKDIR}/git"
 
 PACKAGECONFIG ??= ""
-- 
2.25.0

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

[OE-core] [PATCH 13/13] virglrenderer: upgrade 0.8.1 -> 0.8.2

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 .../{virglrenderer_0.8.1.bb => virglrenderer_0.8.2.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/virglrenderer/{virglrenderer_0.8.1.bb => 
virglrenderer_0.8.2.bb} (94%)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.1.bb 
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
similarity index 94%
rename from meta/recipes-graphics/virglrenderer/virglrenderer_0.8.1.bb
rename to meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 133618844a..1046b8504f 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -9,7 +9,7 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
 DEPENDS = "libdrm mesa libepoxy"
-SRCREV = "66c57963aaf09a1c41056bd2a001da1d51957a14"
+SRCREV = "7d204f3927be65fb3365dce01dbcd04d447a4985"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch 
\
file://0001-meson.build-use-python3-directly-for-python.patch \
-- 
2.25.0

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

[OE-core] [PATCH 08/13] epiphany: upgrade 3.34.3.1 -> 3.34.4

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 .../epiphany/{epiphany_3.34.3.1.bb => epiphany_3.34.4.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-gnome/epiphany/{epiphany_3.34.3.1.bb => 
epiphany_3.34.4.bb} (85%)

diff --git a/meta/recipes-gnome/epiphany/epiphany_3.34.3.1.bb 
b/meta/recipes-gnome/epiphany/epiphany_3.34.4.bb
similarity index 85%
rename from meta/recipes-gnome/epiphany/epiphany_3.34.3.1.bb
rename to meta/recipes-gnome/epiphany/epiphany_3.34.4.bb
index 7e1573348e..ddb4c2794f 100644
--- a/meta/recipes-gnome/epiphany/epiphany_3.34.3.1.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_3.34.4.bb
@@ -14,8 +14,8 @@ REQUIRED_DISTRO_FEATURES = "x11 opengl"
 SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive
 \
file://0002-help-meson.build-disable-the-use-of-yelp.patch \
"
-SRC_URI[archive.md5sum] = "c8010e7ef1b0fd2da1e613e17445062a"
-SRC_URI[archive.sha256sum] = 
"00e479fba108f44b1830370780b98116d87fc277eb1a4eed8e229dcdf04aea6d"
+SRC_URI[archive.md5sum] = "a559f164bb7d6cbeceb348648076830b"
+SRC_URI[archive.sha256sum] = 
"60e190fc07ec7e33472e60c7e633e04004f7e277a0ffc5e9cd413706881e598d"
 
 FILES_${PN} += "${datadir}/dbus-1 ${datadir}/gnome-shell/search-providers 
${datadir}/metainfo"
 RDEPENDS_${PN} = "iso-codes adwaita-icon-theme gsettings-desktop-schemas"
-- 
2.25.0

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

[OE-core] [PATCH 10/13] meson: upgrade 0.53.0 -> 0.53.1

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/meson/meson.inc|  4 ++--
 .../meson/0001-Make-CPU-family-warnings-fatal.patch  |  2 +-
 ...0002-Support-building-allarch-recipes-again.patch |  2 +-
 .../meson/meson/0003-native_bindir.patch | 12 ++--
 .../meson/{meson_0.53.0.bb => meson_0.53.1.bb}   |  0
 ...sdk-meson_0.53.0.bb => nativesdk-meson_0.53.1.bb} |  0
 6 files changed, 10 insertions(+), 10 deletions(-)
 rename meta/recipes-devtools/meson/{meson_0.53.0.bb => meson_0.53.1.bb} (100%)
 rename meta/recipes-devtools/meson/{nativesdk-meson_0.53.0.bb => 
nativesdk-meson_0.53.1.bb} (100%)

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index c0ce7d338b..d391c9cf29 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -17,8 +17,8 @@ SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P

file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \

file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
"
-SRC_URI[sha256sum] = 
"035e75993ab6fa6c9ebf902b835c64cf397a763eb8e65c9bb6e1cc9730a9d3f6"
-SRC_URI[md5sum] = "3a0313d040ded973d84cbec368c2e1d3"
+SRC_URI[sha256sum] = 
"ec1ba33eea701baca2c1607dac458152dc8323364a51fdef6babda2623413b04"
+SRC_URI[md5sum] = "9bf73f7b5a2426a7c8674a809bb8cae2"
 
 SRC_URI_append_class-native = " \
 file://0001-Make-CPU-family-warnings-fatal.patch \
diff --git 
a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch 
b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
index 74d5b4ca66..9ce31e5489 100644
--- 
a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
+++ 
b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
@@ -1,4 +1,4 @@
-From 8ce7a1ddbc9b7775568a98fcd50e39a01513c902 Mon Sep 17 00:00:00 2001
+From ee638fd4a299bfc53a2238e9f71ae310c8d97460 Mon Sep 17 00:00:00 2001
 From: Ross Burton 
 Date: Tue, 3 Jul 2018 13:59:09 +0100
 Subject: [PATCH] Make CPU family warnings fatal
diff --git 
a/meta/recipes-devtools/meson/meson/0002-Support-building-allarch-recipes-again.patch
 
b/meta/recipes-devtools/meson/meson/0002-Support-building-allarch-recipes-again.patch
index 1529ebe9fe..ce18660756 100644
--- 
a/meta/recipes-devtools/meson/meson/0002-Support-building-allarch-recipes-again.patch
+++ 
b/meta/recipes-devtools/meson/meson/0002-Support-building-allarch-recipes-again.patch
@@ -1,4 +1,4 @@
-From cc6e47da801ce3c274485775c62784416fd22977 Mon Sep 17 00:00:00 2001
+From 9c221c74bd306dfa6fec22c8f156eb9d4e4f7fcb Mon Sep 17 00:00:00 2001
 From: Peter Kjellerstedt 
 Date: Thu, 26 Jul 2018 16:32:49 +0200
 Subject: [PATCH] Support building allarch recipes again
diff --git a/meta/recipes-devtools/meson/meson/0003-native_bindir.patch 
b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
index 76c1aa9ac1..dc822fb1fc 100644
--- a/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
+++ b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
@@ -1,4 +1,4 @@
-From af2554b9b08af973181b4e4181bd1cb936fdbb8f Mon Sep 17 00:00:00 2001
+From e76726321067748362b39937bd1e663a1a948ad5 Mon Sep 17 00:00:00 2001
 From: Ricardo Ribalda Delgado 
 Date: Wed, 15 Nov 2017 15:05:01 +0100
 Subject: [PATCH] native_bindir
@@ -22,7 +22,7 @@ Signed-off-by: Ricardo Ribalda Delgado 

  2 files changed, 14 insertions(+), 11 deletions(-)
 
 diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
-index f17b9f2..b5c9c92 100644
+index 40e304c..4b687df 100644
 --- a/mesonbuild/dependencies/base.py
 +++ b/mesonbuild/dependencies/base.py
 @@ -184,7 +184,7 @@ class Dependency:
@@ -73,7 +73,7 @@ index f17b9f2..b5c9c92 100644
 +cache[(self.pkgbin, targs, fenv)] = self._call_pkgbin_real(args, 
env, use_native)
  return cache[(self.pkgbin, targs, fenv)]
  
- def _convert_mingw_paths(self, args: List[str]) -> List[str]:
+ def _convert_mingw_paths(self, args: T.List[str]) -> T.List[str]:
 @@ -907,7 +910,7 @@ class PkgConfigDependency(ExternalDependency):
(self.name, out_raw))
  self.link_args, self.raw_link_args = self._search_libs(out, out_raw)
@@ -93,7 +93,7 @@ index f17b9f2..b5c9c92 100644
  if ret != 0:
  if self.required:
 diff --git a/mesonbuild/dependencies/ui.py b/mesonbuild/dependencies/ui.py
-index bdcc4a7..e2de847 100644
+index da411ef..856506a 100644
 --- a/mesonbuild/dependencies/ui.py
 +++ b/mesonbuild/dependencies/ui.py
 @@ -330,7 +330,7 @@ class QtBaseDependency(ExternalDependency):
@@ -105,7 +105,7 @@ index bdcc4a7..e2de847 100644
  if prefix:
  self.bindir = os.path.join(prefix, 'bin')
  
-@@ -507,7 +507,7 @@ class Qt4Dependency(QtBaseDependency):
+@@ -508,7 +508,7 @@ class Qt4Dependency(QtBaseDependency):
  applicati

[OE-core] [PATCH 09/13] libsecret: upgrade 0.20.0 -> 0.20.1

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 ...ection-Rename-internal-functions-to-.patch | 144 --
 ...ibsecret_0.20.0.bb => libsecret_0.20.1.bb} |   5 +-
 2 files changed, 2 insertions(+), 147 deletions(-)
 delete mode 100644 
meta/recipes-gnome/libsecret/libsecret/0001-secret-file-collection-Rename-internal-functions-to-.patch
 rename meta/recipes-gnome/libsecret/{libsecret_0.20.0.bb => 
libsecret_0.20.1.bb} (81%)

diff --git 
a/meta/recipes-gnome/libsecret/libsecret/0001-secret-file-collection-Rename-internal-functions-to-.patch
 
b/meta/recipes-gnome/libsecret/libsecret/0001-secret-file-collection-Rename-internal-functions-to-.patch
deleted file mode 100644
index 269c12b010..00
--- 
a/meta/recipes-gnome/libsecret/libsecret/0001-secret-file-collection-Rename-internal-functions-to-.patch
+++ /dev/null
@@ -1,144 +0,0 @@
-From 59bcb169c4777bb3b1a50fee2ae20e4e8574b749 Mon Sep 17 00:00:00 2001
-From: Daiki Ueno 
-Date: Tue, 14 Jan 2020 10:09:29 +0100
-Subject: [PATCH] secret-file-collection: Rename internal functions to avoid
- conflicts
-
-As encrypt() is a standard POSIX function, its declaration had
-conflict with our own.  Let's be more verbose about naming of the
-internal crypto functions.
-
-Fixes #35.
-
-Upstream-Status: Backport 
[https://github.com/GNOME/libsecret/commit/cf21ad50b62f7c8e4b22ef374f0a73290a99bdb8]
-Signed-off-by: Alexander Kanavin 

- libsecret/secret-file-collection.c | 38 +++---
- 1 file changed, 19 insertions(+), 19 deletions(-)
-
-diff --git a/libsecret/secret-file-collection.c 
b/libsecret/secret-file-collection.c
-index 79863ea..8ffb542 100644
 a/libsecret/secret-file-collection.c
-+++ b/libsecret/secret-file-collection.c
-@@ -68,7 +68,7 @@ enum {
- };
- 
- static gboolean
--derive (SecretFileCollection *self)
-+do_derive_key (SecretFileCollection *self)
- {
-   const gchar *password;
-   gsize n_password;
-@@ -93,9 +93,9 @@ derive (SecretFileCollection *self)
- }
- 
- static gboolean
--calculate_mac (SecretFileCollection *self,
-- const guint8 *value, gsize n_value,
-- guint8 *buffer)
-+do_calculate_mac (SecretFileCollection *self,
-+const guint8 *value, gsize n_value,
-+guint8 *buffer)
- {
-   gcry_mac_hd_t hd;
-   gcry_error_t gcry;
-@@ -130,9 +130,9 @@ calculate_mac (SecretFileCollection *self,
- }
- 
- static gboolean
--decrypt (SecretFileCollection *self,
--   guint8 *data,
--   gsize n_data)
-+do_decrypt (SecretFileCollection *self,
-+  guint8 *data,
-+  gsize n_data)
- {
-   gcry_cipher_hd_t hd;
-   gcry_error_t gcry;
-@@ -164,9 +164,9 @@ decrypt (SecretFileCollection *self,
- }
- 
- static gboolean
--encrypt (SecretFileCollection *self,
--   guint8 *data,
--   gsize n_data)
-+do_encrypt (SecretFileCollection *self,
-+  guint8 *data,
-+  gsize n_data)
- {
-   gcry_cipher_hd_t hd;
-   gcry_error_t gcry;
-@@ -311,7 +311,7 @@ on_load_contents (GObject *source_object,
-   self->modified = g_date_time_new_now_utc ();
-   self->usage_count = 0;
- 
--  if (!derive (self)) {
-+  if (!do_derive_key (self)) {
-   g_task_return_new_error (task,
-SECRET_ERROR,
-SECRET_ERROR_PROTOCOL,
-@@ -375,7 +375,7 @@ on_load_contents (GObject *source_object,
-   g_assert (n_data == salt_size);
- 
-   self->salt = g_bytes_new (data, n_data);
--  if (!derive (self)) {
-+  if (!do_derive_key (self)) {
-   g_task_return_new_error (task,
-SECRET_ERROR,
-SECRET_ERROR_PROTOCOL,
-@@ -442,7 +442,7 @@ hash_attributes (SecretFileCollection *self,
-   GVariant *variant;
- 
-   value = g_hash_table_lookup (attributes, l->data);
--  if (!calculate_mac (self, (guint8 *)value, strlen (value), 
buffer)) {
-+  if (!do_calculate_mac (self, (guint8 *)value, strlen (value), 
buffer)) {
-   g_list_free (keys);
-   return NULL;
-   }
-@@ -485,7 +485,7 @@ hashed_attributes_match (SecretFileCollection *self,
-   return FALSE;
-   }
- 
--  if (!calculate_mac (self, value, strlen ((char *)value), 
buffer)) {
-+  if (!do_calculate_mac (self, value, strlen ((char *)value), 
buffer)) {
-   g_variant_unref (hashed_attribute);
-   return FALSE;
-   }
-@@ -584,7 +584,7 @@ secret_file_collection_replace (SecretFileCollection *self,
-   g_variant_store (serialized_item, data);
-   g_variant_unref (serialized_item);
-   memset (data + n_data, n_padded - n_data, n_padded - n_data);
--  if (!encrypt (self, 

[OE-core] [PATCH 05/13] weston-init: use the drm/kms backend rather than fbdev one for qemux86 machines

[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. Empty init file will cause
weston to default to the KMS backend.

Note that 3D acceleration via virgl is not required; the backend
renders fine via the software driver in mesa. However, kvm
is more or less required to keep the UI responsive.

Also, other qemu targets (mips and arm in particular) continue
to use the fbdev backend, as in the absence of kvm, the performance
of software GL paths falls to unacceptable level.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-graphics/wayland/weston-init/qemux86-64/weston.ini | 0
 meta/recipes-graphics/wayland/weston-init/qemux86/weston.ini| 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 
meta/recipes-graphics/wayland/weston-init/qemux86-64/weston.ini
 create mode 100644 meta/recipes-graphics/wayland/weston-init/qemux86/weston.ini

diff --git a/meta/recipes-graphics/wayland/weston-init/qemux86-64/weston.ini 
b/meta/recipes-graphics/wayland/weston-init/qemux86-64/weston.ini
new file mode 100644
index 00..e69de29bb2
diff --git a/meta/recipes-graphics/wayland/weston-init/qemux86/weston.ini 
b/meta/recipes-graphics/wayland/weston-init/qemux86/weston.ini
new file mode 100644
index 00..e69de29bb2
-- 
2.25.0

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

[OE-core] [PATCH 07/13] createrepo-c: upgrade 0.15.5 -> 0.15.7

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 .../{createrepo-c_0.15.5.bb => createrepo-c_0.15.7.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/createrepo-c/{createrepo-c_0.15.5.bb => 
createrepo-c_0.15.7.bb} (95%)

diff --git a/meta/recipes-devtools/createrepo-c/createrepo-c_0.15.5.bb 
b/meta/recipes-devtools/createrepo-c/createrepo-c_0.15.7.bb
similarity index 95%
rename from meta/recipes-devtools/createrepo-c/createrepo-c_0.15.5.bb
rename to meta/recipes-devtools/createrepo-c/createrepo-c_0.15.7.bb
index 9b6c89c348..c6a53ffece 100644
--- a/meta/recipes-devtools/createrepo-c/createrepo-c_0.15.5.bb
+++ b/meta/recipes-devtools/createrepo-c/createrepo-c_0.15.7.bb
@@ -8,7 +8,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/createrepo_c \
file://0001-Do-not-set-PYTHON_INSTALL_DIR-by-running-python.patch \
"
 
-SRCREV = "db3a2da68842efd8a8f69c40a222dfb15bb1f4fe"
+SRCREV = "4ab6b56b8b718396386982afba4ade297c14d91a"
 
 S = "${WORKDIR}/git"
 
-- 
2.25.0

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

[OE-core] [PATCH 12/13] vala: upgrade 0.46.5 -> 0.46.6

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/vala/{vala_0.46.5.bb => vala_0.46.6.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/vala/{vala_0.46.5.bb => vala_0.46.6.bb} (57%)

diff --git a/meta/recipes-devtools/vala/vala_0.46.5.bb 
b/meta/recipes-devtools/vala/vala_0.46.6.bb
similarity index 57%
rename from meta/recipes-devtools/vala/vala_0.46.5.bb
rename to meta/recipes-devtools/vala/vala_0.46.6.bb
index 9233d109dd..66f620384c 100644
--- a/meta/recipes-devtools/vala/vala_0.46.5.bb
+++ b/meta/recipes-devtools/vala/vala_0.46.6.bb
@@ -4,5 +4,5 @@ SRC_URI += 
"file://0001-git-version-gen-don-t-append-dirty-if-we-re-not-in-g.pat
file://0001-vapigen.m4-use-PKG_CONFIG_SYSROOT_DIR.patch \
"
 
-SRC_URI[md5sum] = "a0a2eb8babb72c1b4e81c4f1b98429df"
-SRC_URI[sha256sum] = 
"1a7847d2599d902c805a58b95b72b69e64c0223c2f6220163998a7ab4b42db1d"
+SRC_URI[md5sum] = "d9af125648505503b139ebc2d2c9eee5"
+SRC_URI[sha256sum] = 
"ef31649932872f094971d46453b21c60a41661670f98afa334062425b4aec47a"
-- 
2.25.0

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

[OE-core] [PATCH 06/13] qemumips: use std vga instead of cirrus vga

[Alexander Kanavin]

This is what the upstream recommends nowadays:
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/

I have verified that both X and weston continue to boot and look
right; however xorg.conf file needs to be removed as it is cirrus
specific and doesn't work and isn't needed with std vga.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/machine/include/qemuboot-mips.inc   |  2 +-
 .../xserver-xf86-config/qemumips/xorg.conf| 39 ---
 .../xserver-xf86-config/qemumips64/xorg.conf  | 39 ---
 3 files changed, 1 insertion(+), 79 deletions(-)
 delete mode 100644 
meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips/xorg.conf
 delete mode 100644 
meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips64/xorg.conf

diff --git a/meta/conf/machine/include/qemuboot-mips.inc 
b/meta/conf/machine/include/qemuboot-mips.inc
index d44b96c18c..f1f7c2ae20 100644
--- a/meta/conf/machine/include/qemuboot-mips.inc
+++ b/meta/conf/machine/include/qemuboot-mips.inc
@@ -7,4 +7,4 @@ QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
 
 # For graphics to work we need to define the VGA device as well as the 
necessary USB devices
-QB_OPT_APPEND += "-device cirrus-vga"
+QB_OPT_APPEND += "-vga std"
diff --git 
a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips/xorg.conf 
b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips/xorg.conf
deleted file mode 100644
index 1d3c64f620..00
--- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips/xorg.conf
+++ /dev/null
@@ -1,39 +0,0 @@
-
-Section "Files"
-EndSection
-
-Section "Device"
-Identifier"Graphics Controller"
-Driver"fbdev"
-EndSection
-
-Section "Monitor"
-Identifier"Generic Monitor"
-Option"DPMS"
-# 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz
-Modeline "1024x600_60.00"   49.00  1024 1072 1168 1312  600 603 613 624 
-hsync +vsync
-# 640x480 @ 60Hz (Industry standard) hsync: 31.5kHz
-ModeLine "640x480"25.2  640  656  752  800480  490  492  525 
-hsync -vsync
-# 640x480 @ 72Hz (VESA) hsync: 37.9kHz
-ModeLine "640x480"31.5  640  664  704  832480  489  491  520 
-hsync -vsync
-# 640x480 @ 75Hz (VESA) hsync: 37.5kHz
-ModeLine "640x480"31.5  640  656  720  840480  481  484  500 
-hsync -vsync
-# 640x480 @ 85Hz (VESA) hsync: 43.3kHz
-ModeLine "640x480"36.0  640  696  752  832480  481  484  509 
-hsync -vsync
-EndSection
-
-Section "Screen"
-Identifier"Default Screen"
-Device"Graphics Controller"
-Monitor"Generic Monitor"
-DefaultDepth  16
-SubSection "Display"
-Modes "640x480"
-EndSubSection
-EndSection
-
-Section "ServerLayout"
-Identifier"Default Layout"
-Screen"Default Screen"
-Option "AllowEmptyInput" "no"
-EndSection
diff --git 
a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips64/xorg.conf 
b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips64/xorg.conf
deleted file mode 100644
index 03b94dc3af..00
--- 
a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config/qemumips64/xorg.conf
+++ /dev/null
@@ -1,39 +0,0 @@
-
-Section "Files"
-EndSection
-
-Section "Device"
-Identifier"Graphics Controller"
-Driver"fbdev"
-EndSection
-
-Section "Monitor"
-Identifier"Generic Monitor"
-Option"DPMS"
-# 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz
-Modeline "1024x600_60.00"   49.00  1024 1072 1168 1312  600 603 613 624 
-hsync +vsync
-# 640x480 @ 60Hz (Industry standard) hsync: 31.5kHz
-ModeLine "640x480"25.2  640  656  752  800480  490  492  525 
-hsync -vsync
-# 640x480 @ 72Hz (VESA) hsync: 37.9kHz
-ModeLine "640x480"31.5  640  664  704  832480  489  491  520 
-hsync -vsync
-# 640x480 @ 75Hz (VESA) hsync: 37.5kHz
-ModeLine "640x480"31.5  640  656  720  840480  481  484  500 
-hsync -vsync
-# 640x480 @ 85Hz (VESA) hsync: 43.3kHz
-ModeLine "640x480"36.0  640  696  752  832480  481  484  509 
-hsync -vsync
-EndSection
-
-Section "Screen"
-Identifier"Default Screen"
-Device"Graphics Controller"
-Monitor"Generic Monitor"
-DefaultDepth16
-SubSection "Display"
-Modes "640x480"
-EndSubSection
-EndSection
-
-Section "ServerLayout"
-Identifier"Default Layout"
-Screen"Default Screen"
-Option "AllowEmptyInput" "no"
-EndSection
-- 
2.25.0

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

[OE-core] [PATCH 03/13] webkitgtk: unbreak wayland build

[Alexander Kanavin]

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

[1] https://github.com/Igalia/meta-webkit/

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-sato/webkit/libwpe_1.4.0.1.bb   | 15 +++
 meta/recipes-sato/webkit/webkitgtk_2.26.4.bb |  2 +-
 meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb | 15 +++
 3 files changed, 31 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 00..346ca9b1d8
--- /dev/null
+++ b/meta/recipes-sato/webkit/libwpe_1.4.0.1.bb
@@ -0,0 +1,15 @@
+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[sha256sum] = 
"09849dfb34877354f34f318e138971cf22e677b2179e1f0a8ea00ab0b7bd8e9b"
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
index 153bc8db11..585723772e 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 00..7db5806d9d
--- /dev/null
+++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb
@@ -0,0 +1,15 @@
+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[sha256sum] = 
"6249a0b7cbfa662206a8d2fa24e2c574e75c681ad0e93468091f1dc68ddb299d"
+
-- 
2.25.0

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

[OE-core] [PATCH 04/13] wayland: convert to meson build

[Alexander Kanavin]

Replace an autotools-specific .pc adjustment patch with a meson-specific one.

Signed-off-by: Alexander Kanavin 
---
 ...hardcode-the-path-to-wayland-scanner.patch | 26 +++
 ...-the-native-wayland-scanner-directly.patch | 27 
 .../wayland/wayland/fixpathinpcfiles.patch| 32 ---
 .../wayland/wayland_1.18.0.bb | 11 ---
 4 files changed, 59 insertions(+), 37 deletions(-)
 create mode 100644 
meta/recipes-graphics/wayland/wayland/0002-Do-not-hardcode-the-path-to-wayland-scanner.patch
 create mode 100644 
meta/recipes-graphics/wayland/wayland/0002-meson.build-find-the-native-wayland-scanner-directly.patch
 delete mode 100644 meta/recipes-graphics/wayland/wayland/fixpathinpcfiles.patch

diff --git 
a/meta/recipes-graphics/wayland/wayland/0002-Do-not-hardcode-the-path-to-wayland-scanner.patch
 
b/meta/recipes-graphics/wayland/wayland/0002-Do-not-hardcode-the-path-to-wayland-scanner.patch
new file mode 100644
index 00..2199548bdf
--- /dev/null
+++ 
b/meta/recipes-graphics/wayland/wayland/0002-Do-not-hardcode-the-path-to-wayland-scanner.patch
@@ -0,0 +1,26 @@
+From cbb28635a1079d68e62dbaa1e21791a20dbbbaf4 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Mon, 17 Feb 2020 21:46:18 +0100
+Subject: [PATCH] Do not hardcode the path to wayland-scanner
+
+This results in host contamination during builds.
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Alexander Kanavin 
+---
+ src/meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/meson.build b/src/meson.build
+index 294aee0..7e410fa 100644
+--- a/src/meson.build
 b/src/meson.build
+@@ -49,7 +49,7 @@ pkgconfig.generate(
+   'datarootdir=' + join_paths('${prefix}', get_option('datadir')),
+   'pkgdatadir=' + join_paths('${datarootdir}', 
meson.project_name()),
+   'bindir=' + join_paths('${prefix}', get_option('bindir')),
+-  'wayland_scanner=${bindir}/wayland-scanner'
++  'wayland_scanner=wayland-scanner'
+   ],
+   filebase: 'wayland-scanner'
+ )
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 00..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 
+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 
+---
+ 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/fixpathinpcfiles.patch 
b/meta/recipes-graphics/wayland/wayland/fixpathinpcfiles.patch
deleted file mode 100644
index ad3526d984..00
--- a/meta/recipes-graphics/wayland/wayland/fixpathinpcfiles.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-Fix wayland-client and wayland-scanner pc files
-
-Upstream-Status: Pending
-
-Signed-off-by: Fabien Lahoudere 
-
-Index: wayland-1.14.0/src/wayland-client.pc.in
-===
 wayland-1.14.0.orig/src/wayland-client.pc.in
-+++ wayland-1.14.0/src/wayland-client.pc.in
-@@ -1,7 +1,7 @@
- prefix=@prefix@
- exec_prefix=@exec_prefix@
- datarootdir=@datarootdir@
--pkgdatadir=@datadir@/@PACKAGE@
-+pkgdatadir=${pc_sysrootdir}@datadir@/@PACKAGE@
- libdir=@libdir@
- includedir=@includedir@
- 
-Index: wayland-1.14.0/src/wayland-scanner.pc.in
-===
 wayland-1.14.0.orig/src/wayland-scanner.pc.in
-+++ wayland-1.14.0/src/wayland-scanner.pc.in
-@@ -2,7 +2,7 @@ prefix=@prefix@
- exec_prefix=@exec_prefix@
- datarootdir=@datarootdir@
- pkgdatadir=@datadir@/@PACKAGE@
--wayland_scanner=@bindir@/wayland-scanner
-+wayland_scanner=wayland-scanner
- 
- Name: Wayland Scanner
- Description: Wayland scanner
diff --git a/meta/recipes-graphics/wayland/wayland_1.18.0.bb 
b/meta/recipes-graphics/wayland/wayland_1.18.0.bb
index 7a3f075552..a702b3f6cc 100644
--- a/meta/recipes-graphics/wayland/wayland_

[OE-core] [PATCH 02/13] 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 
---
 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 3eb27a1550..153bc8db11 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

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

[OE-core] [PATCH 01/13] 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 
---
 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

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

[OE-core] ✗ patchtest: failure for binutils: Upgrade to 2.34 release (rev2)

[Patchwork]

== Series Details ==

Series: binutils: Upgrade to 2.34 release (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/22759/
State : failure

== Summary ==


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



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



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

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

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

Re: [OE-core] bash: Fix CVE-2019-18276

[Richard Purdie]

On Wed, 2020-02-19 at 07:46 -0800, akuster808 wrote:
> 
> On 2/18/20 7:49 AM, Richard Purdie wrote:
> > On Tue, 2020-02-18 at 15:43 +, Mittal, Anuj wrote:
> > > On Tue, 2020-02-18 at 15:35 +, Richard Purdie wrote:
> > > > 
> > > > Someone just needs to remove that section of the patch.
> > > There are other issues with this patch which should also be fixed
> > > I
> > > think. It has been marked as a Backport while it is not one. The
> > > patch
> > > includes changes that are irrelevant to the CVE. And, it should
> > > have
> > > gone to master first.
> > I shall await guidance from you/Armin then.
> 
> We should revert the commit. Ill send a patch.

Anuj sent it, I've merged it to zeus. Open questions:

Should we ship 3.0.2 rc2?
Did this patch cause this regression:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13795

Cheers,

Richard

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

[OE-core] [PATCH 3/3] oeqa/selftest: Drop 'backup' code and SIGTERM handler

[Richard Purdie]

Now selftest is using its own copied build directory, we can stop worrying about
copying files around as backup, and drop the SIGTERM handler to try and restore
them, simplifying the code.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/case.py| 30 +---
 meta/lib/oeqa/selftest/context.py | 47 ++-
 2 files changed, 4 insertions(+), 73 deletions(-)

diff --git a/meta/lib/oeqa/selftest/case.py b/meta/lib/oeqa/selftest/case.py
index ac3308d8a44..dcad4f76ecd 100644
--- a/meta/lib/oeqa/selftest/case.py
+++ b/meta/lib/oeqa/selftest/case.py
@@ -6,7 +6,6 @@
 
 import sys
 import os
-import shutil
 import glob
 import errno
 from unittest.util import safe_repr
@@ -30,9 +29,7 @@ class OESelftestTestCase(OETestCase):
 cls.builddir = cls.tc.config_paths['builddir']
 
 cls.localconf_path = cls.tc.config_paths['localconf']
-cls.localconf_backup = cls.tc.config_paths['localconf_class_backup']
 cls.local_bblayers_path = cls.tc.config_paths['bblayers']
-cls.local_bblayers_backup = 
cls.tc.config_paths['bblayers_class_backup']
 
 cls.testinc_path = os.path.join(cls.tc.config_paths['builddir'],
 "conf/selftest.inc")
@@ -43,8 +40,7 @@ class OESelftestTestCase(OETestCase):
 
 cls._track_for_cleanup = [
 cls.testinc_path, cls.testinc_bblayers_path,
-cls.machineinc_path, cls.localconf_backup,
-cls.local_bblayers_backup]
+cls.machineinc_path]
 
 cls.add_include()
 
@@ -102,30 +98,6 @@ class OESelftestTestCase(OETestCase):
 def setUp(self):
 super(OESelftestTestCase, self).setUp()
 os.chdir(self.builddir)
-# Check if local.conf or bblayers.conf files backup exists
-# from a previous failed test and restore them
-if os.path.isfile(self.localconf_backup) or os.path.isfile(
-self.local_bblayers_backup):
-self.logger.debug("\
-Found a local.conf and/or bblayers.conf backup from a previously aborted test.\
-Restoring these files now, but tests should be re-executed from a clean 
environment\
-to ensure accurate results.")
-try:
-shutil.copyfile(self.localconf_backup, self.localconf_path)
-except OSError as e:
-if e.errno != errno.ENOENT:
-raise
-try:
-shutil.copyfile(self.local_bblayers_backup,
-self.local_bblayers_path)
-except OSError as e:
-if e.errno != errno.ENOENT:
-raise
-else:
-# backup local.conf and bblayers.conf
-shutil.copyfile(self.localconf_path, self.localconf_backup)
-shutil.copyfile(self.local_bblayers_path, 
self.local_bblayers_backup)
-self.logger.debug("Creating local.conf and bblayers.conf backups.")
 # we don't know what the previous test left around in config or inc 
files
 # if it failed so we need a fresh start
 try:
diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index 2cb6c763852..0ab6462bbf8 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -9,9 +9,7 @@ import time
 import glob
 import sys
 import importlib
-import signal
 import subprocess
-from shutil import copyfile
 from random import choice
 
 import oeqa
@@ -185,26 +183,10 @@ class 
OESelftestTestContextExecutor(OETestContextExecutor):
 
 builddir = os.environ.get("BUILDDIR")
 self.tc_kwargs['init']['config_paths'] = {}
-self.tc_kwargs['init']['config_paths']['testlayer_path'] = \
-get_test_layer()
+self.tc_kwargs['init']['config_paths']['testlayer_path'] = 
get_test_layer()
 self.tc_kwargs['init']['config_paths']['builddir'] = builddir
-self.tc_kwargs['init']['config_paths']['localconf'] = \
-os.path.join(builddir, "conf/local.conf")
-self.tc_kwargs['init']['config_paths']['localconf_backup'] = \
-os.path.join(builddir, "conf/local.conf.orig")
-self.tc_kwargs['init']['config_paths']['localconf_class_backup'] = \
-os.path.join(builddir, "conf/local.conf.bk")
-self.tc_kwargs['init']['config_paths']['bblayers'] = \
-os.path.join(builddir, "conf/bblayers.conf")
-self.tc_kwargs['init']['config_paths']['bblayers_backup'] = \
-os.path.join(builddir, "conf/bblayers.conf.orig")
-self.tc_kwargs['init']['config_paths']['bblayers_class_backup'] = \
-os.path.join(builddir, "conf/bblayers.conf.bk")
-
-copyfile(self.tc_kwargs['init']['config_paths']['localconf'],
-self.tc_kwargs['init']['config_paths']['localconf_backup'])
-copyfile(self.tc_kwargs['init']['config_paths']['bblayers'], 
-self.tc_kwargs['init']['config_paths']['bblayers_b

[OE-core] [PATCH 2/3] oeqa/selftest: Startardise seperate builddir for concurrent and non-concurrent selftest

[Richard Purdie]

Currently oe-selftest reuses the current build directory and the concurrent
version run with -j does not.

Standardise and use a separate new build directory in both cases. This will lead
to simpler code and more reliable user run tests.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/core/context.py   | 12 +++--
 meta/lib/oeqa/core/utils/concurrencytest.py | 35 ++-
 meta/lib/oeqa/selftest/context.py   | 50 +
 3 files changed, 58 insertions(+), 39 deletions(-)

diff --git a/meta/lib/oeqa/core/context.py b/meta/lib/oeqa/core/context.py
index 14fc6a54f4b..16320af1157 100644
--- a/meta/lib/oeqa/core/context.py
+++ b/meta/lib/oeqa/core/context.py
@@ -72,6 +72,9 @@ class OETestContext(object):
 modules_required, **kwargs)
 self.suites = self.loader.discover()
 
+def prepareSuite(self, suites, processes):
+return suites
+
 def runTests(self, processes=None, skips=[]):
 self.runner = self.runnerClass(self, descriptions=False, verbosity=2)
 
@@ -79,14 +82,9 @@ class OETestContext(object):
 self.skipTests(skips)
 
 self._run_start_time = time.time()
-if processes:
-from oeqa.core.utils.concurrencytest import ConcurrentTestSuite
-
-concurrent_suite = ConcurrentTestSuite(self.suites, processes)
-result = self.runner.run(concurrent_suite)
-else:
+if not processes:
 self.runner.buffer = True
-result = self.runner.run(self.suites)
+result = self.runner.run(self.prepareSuite(self.suites, processes))
 self._run_end_time = time.time()
 
 return result
diff --git a/meta/lib/oeqa/core/utils/concurrencytest.py 
b/meta/lib/oeqa/core/utils/concurrencytest.py
index 0d9c01e6d45..fac59f765ac 100644
--- a/meta/lib/oeqa/core/utils/concurrencytest.py
+++ b/meta/lib/oeqa/core/utils/concurrencytest.py
@@ -177,9 +177,10 @@ class dummybuf(object):
 #
 class ConcurrentTestSuite(unittest.TestSuite):
 
-def __init__(self, suite, processes):
+def __init__(self, suite, processes, setupfunc):
 super(ConcurrentTestSuite, self).__init__([suite])
 self.processes = processes
+self.setupfunc = setupfunc
 
 def run(self, result):
 tests, totaltests = fork_for_tests(self.processes, self)
@@ -272,37 +273,7 @@ def fork_for_tests(concurrency_num, suite):
 stream = os.fdopen(c2pwrite, 'wb', 1)
 os.close(c2pread)
 
-# Create a new separate BUILDDIR for each group of tests
-if 'BUILDDIR' in os.environ:
-builddir = os.environ['BUILDDIR']
-newbuilddir = builddir + "-st-" + str(ourpid)
-newselftestdir = newbuilddir + "/meta-selftest"
-
-bb.utils.mkdirhier(newbuilddir)
-oe.path.copytree(builddir + "/conf", newbuilddir + "/conf")
-oe.path.copytree(builddir + "/cache", newbuilddir + 
"/cache")
-oe.path.copytree(selftestdir, newselftestdir)
-
-for e in os.environ:
-if builddir in os.environ[e]:
-os.environ[e] = os.environ[e].replace(builddir, 
newbuilddir)
-
-subprocess.check_output("git init; git add *; git commit 
-a -m 'initial'", cwd=newselftestdir, shell=True)
-
-# Tried to used bitbake-layers add/remove but it requires 
recipe parsing and hence is too slow
-subprocess.check_output("sed %s/conf/bblayers.conf -i -e 
's#%s#%s#g'" % (newbuilddir, selftestdir, newselftestdir), cwd=newbuilddir, 
shell=True)
-
-os.chdir(newbuilddir)
-
-for t in process_suite:
-if not hasattr(t, "tc"):
-continue
-cp = t.tc.config_paths
-for p in cp:
-if selftestdir in cp[p] and newselftestdir not in 
cp[p]:
-cp[p] = cp[p].replace(selftestdir, 
newselftestdir)
-if builddir in cp[p] and newbuilddir not in cp[p]:
-cp[p] = cp[p].replace(builddir, newbuilddir)
+(builddir, newbuilddir) = suite.setupfunc("-st-" + 
str(ourpid), selftestdir, process_suite)
 
 # Leave stderr and stdout open so we can see test noise
 # Close stdin so that the child goes away if it decides to
diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index 3d3b19c6e80..2cb6c763852 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -10,11 +10,13 @@ import glob
 import sys
 import importlib
 import signal
+import subprocess
 from shutil import copyfile
 from random import choice
 
 import oeqa
 import oe
+import bb.utils
 
 from oeqa.core.context impor

[OE-core] [PATCH 1/3] selftest/context: Avoid tracebacks from tests using multiprocessing

[Richard Purdie]

We can see tracebacks where the SIGTERM handler catches things
it shouldn't. Avoid exit(1) unless we're the process that
it was intended for.

[YOCTO #13664]

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/context.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index c4eb5d614eb..3d3b19c6e80 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -280,11 +280,15 @@ class 
OESelftestTestContextExecutor(OETestContextExecutor):
 return rc
 
 def _signal_clean_handler(self, signum, frame):
-sys.exit(1)
+if self.ourpid == os.getpid():
+sys.exit(1)
 
 def run(self, logger, args):
 self._process_args(logger, args)
 
+# Setup a SIGTERM handler to allow restoration of files like 
local.conf and bblayers.conf
+# but don't interfer with other processes
+self.ourpid = os.getpid()
 signal.signal(signal.SIGTERM, self._signal_clean_handler)
 
 rc = None
-- 
2.25.0

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

Re: [OE-core] [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 > wrote:


On Wed, Feb 19, 2020 at 1:45 AM Alexander Kanavin
mailto:alex.kana...@gmail.com>> wrote:
 >
 > On Tue, 18 Feb 2020 at 02:56, Khem Raj mailto:raj.k...@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


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

[OE-core] ✗ patchtest: failure for binutils: Upgrade to 2.34 release

[Patchwork]

== Series Details ==

Series: binutils: Upgrade to 2.34 release
Revision: 1
URL   : https://patchwork.openembedded.org/series/22759/
State : failure

== Summary ==


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



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



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

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

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

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

[Alexander Kanavin]

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  wrote:

> On Wed, Feb 19, 2020 at 1:45 AM Alexander Kanavin
>  wrote:
> >
> > On Tue, 18 Feb 2020 at 02:56, Khem Raj  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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [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
 wrote:
>
> On Tue, 18 Feb 2020 at 02:56, Khem Raj  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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-oe][PATCH v3] iproute2: add devlink support to iproute2

[Richard Purdie]

On Tue, 2020-02-18 at 16:38 -0800, Scott Branden via Openembedded-core wrote:
> Add devlink support to iproute2 recipe.
> 
> Signed-off-by: Scott Branden 
> ---
>  .../iproute2/iproute2.inc | 34 +--
>  1 file changed, 23 insertions(+), 11 deletions(-)
> 

Doesn't build:

https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1822

(and a ton more)

Cheers,

Richard

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

Re: [OE-core] [PATCH] babeltrace2: added 2.0.1

[Alexander Kanavin]

On Wed, 19 Feb 2020 at 16:56, Jonathan Rajotte-Julien <
jonathan.rajotte-jul...@efficios.com> wrote:

> > There are some things where the namespaces are quite specific (python
> > vs python3, gtk(+) 2/3/4, qt) but they're fairly few and far between.
> >
> > If babeltrace2 will replace babeltrace and become babeltrace, we
> > probably want to keep PN as babeltrace. If it will be known as
> > babeltrace2 always, we probably change PN.
>
> Babeltrace 2 executable will be forever named babeltrace2.
>
> Hope this clear up this part a bit.
>

Right, then I'm fine with naming the recipe babeltrace2.

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

Re: [OE-core] [PATCH] babeltrace2: added 2.0.1

[Jonathan Rajotte-Julien]

> Let me try a different question. What is the ultimate intent here?
> 
> Will babeltrace and babeltrace2 coexist in the future or do you plan to
> rename babeltrace2 -> babeltrace at some point?

We plan on deprecating Babeltrace 1.X in the long term but Babeltrace 2 and
Babeltrace 1 will always co-exist.

> 
> There are some things where the namespaces are quite specific (python
> vs python3, gtk(+) 2/3/4, qt) but they're fairly few and far between.
> 
> If babeltrace2 will replace babeltrace and become babeltrace, we
> probably want to keep PN as babeltrace. If it will be known as
> babeltrace2 always, we probably change PN.

Babeltrace 2 executable will be forever named babeltrace2.

Hope this clear up this part a bit.

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

Re: [OE-core] oe-core recipe for defining directories in /

[Mark Hatle]

On 2/19/20 4:29 AM, Quentin Schulz wrote:
> Hi JH,
> 
> On Wed, Feb 19, 2020 at 09:12:08PM +1100, JH wrote:
>> Hi,
>>
>> Which recipe defines all directories in "/"? I need to make a bbapand
>> to add directories to /.
>>
> 
> None. Or all of them, depends on how one sees it.

He is correct, this is shared between all package users.  But with that said,
there is a base filesystem package and an associated 'syncing' file for all
other users.

The is a recipe called 'base-files', it builds up the core filesystem
infrastructure, as well as puts down a few basic files that all filesystems 
need.

The 'syncing' file is a corresponding file to used to coordinate permissions
between all recipes: meta/files/fs-perms.txt.  fs-perms.txt is always consulted
when building any recipe to ensure that all common directory, permissions,
owners and groups get a common configuration.

If you are going to bbappend to base-files then you should also to add to
fs-perms.txt (you can do this, like a bbappend, by adding your own file to your
own layer and updating the variable 'FILESYSTEM_PERMS_TABLES' in one of your
global configuration files (usually your distro configuration file.)

but, this isn't the recommended way...

If the directories you are adding are custom to your product, I would recommend
creating a new package to manage this, as well as a custom
fs-perms.txt/FILESYSTEM_PERMS_TABLE entry to coordinate it between recipes that
use this new custom directory structure.

(If only one recipe uses that directory, then all of the overhead is simply not
needed!  You only need this if multiple recipes are sharing a common directory
structure.)

--Mark

> You just create a directory in do_install of a recipe.
> 
> You then make sure this directory is part of a package by checking it's
> in one of the recipe's generated packages's FILES_.
> 
> Quentin
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] bash: Fix CVE-2019-18276

[akuster808]

On 2/18/20 7:49 AM, Richard Purdie wrote:
> On Tue, 2020-02-18 at 15:43 +, Mittal, Anuj wrote:
>> On Tue, 2020-02-18 at 15:35 +, Richard Purdie wrote:
>>> On Tue, 2020-02-18 at 10:28 -0500, Chet Ramey wrote:
 On 2/17/20 9:46 PM, Huo, De wrote:
>  I applied the patch to fix CVE defect CVE-2019-18276.
 That's not exactly an answer to the question of who produced the
 patch.
 If that patch is the one causing failures when it's applied,
 doesn't it
 make sense to go back to the person who produced it and ask them
 to
 update it if necessary?
>>> Its likely a general CVE patch where both configure and
>>> configure.ac
>>> are patched. For OE, we can drop the configure part since we
>>> reautoconf
>>> the code. Its therefore the OE port of the patch which is likely at
>>> fault.
>>>
>>> Someone just needs to remove that section of the patch.
>> There are other issues with this patch which should also be fixed I
>> think. It has been marked as a Backport while it is not one. The
>> patch
>> includes changes that are irrelevant to the CVE. And, it should have
>> gone to master first.
> I shall await guidance from you/Armin then.

We should revert the commit. Ill send a patch.

- Armin
>
> Cheers,
>
> Richard
>

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

Re: [OE-core] [PATCH] gstreamer: Fix reproducibility issue around libcap

[Richard Purdie]

On Wed, 2020-02-19 at 16:41 +0100, Alexander Kanavin wrote:
> On Wed, 19 Feb 2020 at 16:24, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> > +PACKAGECONFIG[setcap] = "-Dsetcap=enabled,-
> > Dsetcap=disabled,libcap"
> 
> I think this should also depend on whatever native recipe provides
> the setcap binary, so we don't depend on host setcap at all?

Right, it needs libcap-native too, good point. I'll tweak.

Cheers,

Richard

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

Re: [OE-core] [PATCH] gstreamer: Fix reproducibility issue around libcap

[Alexander Kanavin]

On Wed, 19 Feb 2020 at 16:24, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> +PACKAGECONFIG[setcap] = "-Dsetcap=enabled,-Dsetcap=disabled,libcap"
>

I think this should also depend on whatever native recipe provides the
setcap binary, so we don't depend on host setcap at all?

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

Re: [OE-core] [PATCH] babeltrace2: added 2.0.1

[Richard Purdie]

On Wed, 2020-02-19 at 10:27 -0500, Jonathan Rajotte-Julien wrote:
> On Wed, Feb 19, 2020 at 11:06:12AM +0100, Anders Wallin wrote:
> > Hi Alex,
> > 
> > I think it's better to use babeltrace2 since it's a new version of
> > babeltrace.
> > The dist packages uses babeltrace2 and the main application/program
> > is
> > called babeltrace2.
> > 
> > Jonatan; Do you have any comment on the naming?
> 
> Me?
> 
> Don't care much about the naming. The major issue here is the
> dependency for
> ptest of lttng-tools that depends on a "babeltrace" executable and
> not on the
> "babeltrace2" executable. Currently on our CI we create a symlink
> from
> "babeltrace2" to "babeltrace". This is something we plan on
> addressing shortly.

Let me try a different question. What is the ultimate intent here?

Will babeltrace and babeltrace2 coexist in the future or do you plan to
rename babeltrace2 -> babeltrace at some point?

There are some things where the namespaces are quite specific (python
vs python3, gtk(+) 2/3/4, qt) but they're fairly few and far between.

If babeltrace2 will replace babeltrace and become babeltrace, we
probably want to keep PN as babeltrace. If it will be known as
babeltrace2 always, we probably change PN.

Cheers,

Richard

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

Re: [OE-core] [PATCH] babeltrace2: added 2.0.1

[Jonathan Rajotte-Julien]

On Wed, Feb 19, 2020 at 11:06:12AM +0100, Anders Wallin wrote:
> Hi Alex,
> 
> I think it's better to use babeltrace2 since it's a new version of
> babeltrace.
> The dist packages uses babeltrace2 and the main application/program is
> called babeltrace2.
> 
> Jonatan; Do you have any comment on the naming?

Me?

Don't care much about the naming. The major issue here is the dependency for
ptest of lttng-tools that depends on a "babeltrace" executable and not on the
"babeltrace2" executable. Currently on our CI we create a symlink from
"babeltrace2" to "babeltrace". This is something we plan on addressing shortly.

Cheers

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

[OE-core] [PATCH] gstreamer: Fix reproducibility issue around libcap

[Richard Purdie]

Add an option to avoid builds depending on the presence of setcap
from the host system.

Signed-off-by: Richard Purdie 
---
 .../gstreamer/gstreamer1.0/capfix.patch   | 37 +++
 .../gstreamer/gstreamer1.0_1.16.1.bb  |  2 +
 2 files changed, 39 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
new file mode 100644
index 000..7ca3d5ad4a6
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
@@ -0,0 +1,37 @@
+Currently gstreamer configuration depends on whether setcap is found on the 
host
+system. Turn this into a configure option to make builds deterinistic.
+
+RP 2020/2/19
+Signed-off-by: Richard Purdie 
+Upstream-Status: Pending
+
+Index: gstreamer-1.16.1/libs/gst/helpers/meson.build
+===
+--- gstreamer-1.16.1.orig/libs/gst/helpers/meson.build
 gstreamer-1.16.1/libs/gst/helpers/meson.build
+@@ -73,7 +73,12 @@ if have_ptp
+ endif
+   endif
+ 
+-  setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', 
required : false)
++  setcap_feature = get_option('setcap')
++  if setcap_feature.disabled()
++setcap = find_program('dontexist', required : false)
++  else
++setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', 
required : false)
++  endif
+ 
+   # user/group to change to in gst-ptp-helper
+   ptp_helper_setuid_user = get_option('ptp-helper-setuid-user')
+Index: gstreamer-1.16.1/meson_options.txt
+===
+--- gstreamer-1.16.1.orig/meson_options.txt
 gstreamer-1.16.1/meson_options.txt
+@@ -26,6 +26,7 @@ option('libunwind', type : 'feature', va
+ option('libdw', type : 'feature', value : 'auto', description : 'Use libdw to 
generate better backtraces from libunwind')
+ option('dbghelp', type : 'feature', value : 'auto', description : 'Use 
dbghelp to generate backtraces')
+ option('bash-completion', type : 'feature', value : 'auto', description : 
'Install bash completion files')
++option('setcap', type : 'feature', value : 'auto', description : 'Use setcap')
+ 
+ # Common feature options
+ option('examples', type : 'feature', value : 'auto', yield : true)
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
index 6b8a5a0eb01..68f5ca649fe 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
@@ -21,6 +21,7 @@ SRC_URI = " \
 file://0002-meson-build-gir-even-when-cross-compiling-if-introsp.patch \
 file://0003-meson-Add-valgrind-feature.patch \
 file://0004-meson-Add-option-for-installed-tests.patch \
+file://capfix.patch \
 "
 SRC_URI[md5sum] = "c505fb818b36988daaa846e9e63eabe8"
 SRC_URI[sha256sum] = 
"02211c3447c4daa55919c5c0f43a82a6fbb51740d57fc3af0639d46f1cf4377d"
@@ -39,6 +40,7 @@ PACKAGECONFIG[unwind] = 
"-Dlibunwind=enabled,-Dlibunwind=disabled,libunwind"
 PACKAGECONFIG[dw] = "-Dlibdw=enabled,-Dlibdw=disabled,elfutils"
 PACKAGECONFIG[bash-completion] = 
"-Dbash-completion=enabled,-Dbash-completion=disabled,bash-completion"
 PACKAGECONFIG[tools] = "-Dtools=enabled,-Dtools=disabled"
+PACKAGECONFIG[setcap] = "-Dsetcap=enabled,-Dsetcap=disabled,libcap"
 
 # TODO: put this in a gettext.bbclass patch
 def gettext_oemeson(d):
-- 
2.25.0

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

[OE-core] [AUH] Upgrade status: 2020-02-19

[auh]

Recipe upgrade statistics:

* Succeeded: 50
gstreamer1.0-plugins-good, 1.16.2, Anuj Mittal 
libsolv, 0.7.11, Anuj Mittal 
libcap, 2.32, Yi Zhao 
bison, 3.5.2, Chen Qi 
nss, 3.50, Armin Kuster 
meson, 0.53.1, Alexander Kanavin 
screen, 4.8.0, Anuj Mittal 
libmodule-build-perl, 0.4231, Tim Orling 

gstreamer1.0-plugins-base, 1.16.2, Anuj Mittal 
libarchive, 3.4.2, Otavio Salvador 
vala, 0.46.6, Alexander Kanavin 
python3-git, 3.0.7, Oleksandr Kravchuk 

libpcre, 8.44, Yi Zhao 
p11-kit, 0.23.20, Alexander Kanavin 
stress-ng, 0.11.00, Anuj Mittal 
util-linux, 2.35.1, Chen Qi 
bluez5, 5.53, Anuj Mittal 
liberror-perl, 0.17029, Tim Orling 
epiphany, 3.34.4, Alexander Kanavin 
gstreamer1.0-omx, 1.16.2, Anuj Mittal 
gstreamer1.0-rtsp-server, 1.16.2, Anuj Mittal 
lttng-tools, 2.11.2, Richard Purdie 
ncurses, 6.2, Hongxu Jia 
python3-docutils, 0.16, Oleksandr Kravchuk 

gstreamer1.0-libav, 1.16.2, Anuj Mittal 
gstreamer1.0-plugins-ugly, 1.16.2, Anuj Mittal 
bind, 9.11.15, Armin Kuster 
piglit, 1.0-new-commits-available, Ross Burton 
gstreamer1.0-python, 1.16.2, Anuj Mittal 
virglrenderer, 0.8.2, Alexander Kanavin 
dnf, 4.2.18, Alexander Kanavin 
vulkan-headers, 1.2.131.1, Anuj Mittal 
python3-gitdb, 3.0.0, Oleksandr Kravchuk 

gstreamer1.0-plugins-bad, 1.16.2, Anuj Mittal 
libxkbcommon, 0.10.0, Armin Kuster 
linux-firmware, 20200117-new-commits-available, Otavio Salvador 

python3-mako, 1.1.1, Oleksandr Kravchuk 

gnutls, 3.6.12, Armin Kuster 
unifdef, 2.12, Ross Burton 
libsecret, 0.20.1, Alexander Kanavin 
at-spi2-core, 2.34.0, Anuj Mittal 
python3-setuptools, 45.2.0, Oleksandr Kravchuk 

asciidoc, 8.6.10, Yi Zhao 
libgpg-error, 1.37, Hongxu Jia 
libxcrypt-compat, 4.4.13, Khem Raj 
createrepo-c, 0.15.7, Alexander Kanavin 
ninja, 1.10.0, Khem Raj 
gstreamer1.0, 1.16.2, Anuj Mittal 
man-pages, 5.05, Hongxu Jia 
gstreamer1.0-vaapi, 1.16.2, Anuj Mittal 
* Failed (devtool error): 16
binutils, 2.34, Khem Raj 
rpm, 4.15.1, Mark Hatle 
nfs-utils, 2.4.3, Robert Yang 
apt, 1.9.9, Aníbal Limón 
make, 4.3, Robert Yang 
mc, 4.8.24, Ross Burton 
sysklogd, 2.1.1, Chen Qi 
atk, 2.34.1, Anuj Mittal 
build-compare, 2019.08.14-new-commits-available, Paul Eggleton 

systemd-boot, 244.3, Chen Qi 
babeltrace, 2.0.1, Alexander Kanavin 
e2fsprogs, 1.45.5, Robert Yang 
ltp, 20200120, Yi Zhao 
libinput, 1.15.1, Ross Burton 
gmp, 6.2.0, Khem Raj 
nspr, 4.25, Armin Kuster 
* Failed(do_compile): 20
acpica, 20200214, Ross Burton 
cmake, 3.16.4, Pascal Bach 
python3-numpy, 1.18.1, Oleksandr Kravchuk 

mesa, 19.3.4, Otavio Salvador 
vulkan-demos, git-new-commits-available, Ross Burton 

xkeyboard-config, 2.29, Armin Kuster 
vulkan-tools, 1.2.131.1, Anuj Mittal 
pulseaudio, 13.99.1, Tanu Kaskinen 
psplash, 0.1-new-commits-available, Yi Zhao 
vulkan-loader, 1.2.131.2, Anuj Mittal 
connman, 1.38, Changhyeok Bae 
git, 2.25.0, Robert Yang 
gst-validate, 1.16.2, Anuj Mittal 
libxcrypt, 4.4.13, Khem Raj 
shadow, 4.8.1, Chen Qi 
at-spi2-atk, 2.34.1, Anuj Mittal 
go, 1.13.8, Khem Raj 
python3-scons, 3.1.2, Tim Orling 
libdnf, 0.43.1, Alexander Kanavin 
go-runtime, 1.13.8, Khem Raj 

TOTAL: attempted=86 succeeded=50(58.14%) failed=36(41.86%)

Recipe upgrade statistics per Maintainer:

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

[OE-core] [PATCH] perl: Fix makefile race causing configuration differences

[Richard Purdie]

Add a missing makefile dependency which can cause differences in
configuration (submitted upstream).

Signed-off-by: Richard Purdie 
---
 .../recipes-devtools/perl/files/racefix.patch | 24 +++
 meta/recipes-devtools/perl/perl_5.30.1.bb |  1 +
 2 files changed, 25 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/files/racefix.patch

diff --git a/meta/recipes-devtools/perl/files/racefix.patch 
b/meta/recipes-devtools/perl/files/racefix.patch
new file mode 100644
index 000..bac42d26ae0
--- /dev/null
+++ b/meta/recipes-devtools/perl/files/racefix.patch
@@ -0,0 +1,24 @@
+In our builds Config_heavy.pl sometimes has lines:
+cwarnflags=XXX
+ccstdflags=XXX
+and sometimes does not.
+The reason is that this information is pulled from cflags by configpm and yet
+there is no dependency in the Makefile. Add one to fix this.
+
+Upstream-Status: Submitted [https://github.com/arsv/perl-cross/pull/89]
+RP 2020/2/19
+Signed-off-by: Richard Purdie 
+
+Index: perl-5.30.1/Makefile
+===
+--- perl-5.30.1.orig/Makefile
 perl-5.30.1/Makefile
+@@ -204,7 +204,7 @@ configpod: $(CONFIGPOD)
+ git_version.h lib/Config_git.pl: make_patchnum.pl | miniperl$X
+   ./miniperl_top make_patchnum.pl
+ 
+-lib/Config.pm lib/Config_heavy.pl lib/Config.pod: config.sh \
++lib/Config.pm lib/Config_heavy.pl lib/Config.pod: config.sh cflags \
+   lib/Config_git.pl Porting/Glossary | miniperl$X
+   ./miniperl_top configpm
+ 
diff --git a/meta/recipes-devtools/perl/perl_5.30.1.bb 
b/meta/recipes-devtools/perl/perl_5.30.1.bb
index b37f175f973..4869012b1a2 100644
--- a/meta/recipes-devtools/perl/perl_5.30.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.30.1.bb
@@ -22,6 +22,7 @@ SRC_URI = 
"https://www.cpan.org/src/5.0/perl-${PV}.tar.gz;name=perl \
file://0002-Constant-Fix-up-shebang.patch \

file://0001-tests-adjust-to-correctly-exclude-unbuilt-extensions.patch \
file://determinism.patch  \
+   file://racefix.patch \
"
 SRC_URI_append_class-native = " \
file://perl-configpm-switch.patch \
-- 
2.25.0

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

Re: [OE-core] [PATCH] babeltrace2: added 2.0.1

[Alexander Kanavin]

Basically I would like to maintain the principle that a recipe without a
version number is the 'latest' version, and staying on an older version has
to be an opt-in decision. There are already things like python3 and
gstreamer10 in core, and I would want to have less of that.

Alex

On Wed, 19 Feb 2020 at 11:06, Anders Wallin  wrote:

> Hi Alex,
>
> I think it's better to use babeltrace2 since it's a new version of
> babeltrace.
> The dist packages uses babeltrace2 and the main application/program is
> called babeltrace2.
>
> Jonatan; Do you have any comment on the naming?
>
> Regards
> Anders Wallin
>
>
> On Tue, Feb 18, 2020 at 2:56 PM Alexander Kanavin 
> wrote:
>
>> Thanks. May I request that this recipe is named babletrace, while
>> babeltrace 1.x recipe is at the same time renamed to babeltrace1? I'd like
>> to avoid adding version numbers to the 'latest' version. Lttng should at
>> the same time be adjusted to use babeltrace1, as advised by upstream.
>>
>> Alex
>>
>> On Tue, 18 Feb 2020 at 14:21, Anders Wallin  wrote:
>>
>>> Babeltrace 1 vs. Babeltrace 2
>>>
>>> The Babeltrace project exists since 2010. In 2020, Babeltrace 2 was
>>> released.
>>> Babeltrace 2 is a complete rewrite of the library, Python bindings, and
>>> CLI. It
>>> is plugin based and offers much more features and potential than
>>> Babeltrace 1.
>>>
>>> Because Babeltrace 2 is still a young released project, some
>>> distributions still
>>> provide packages for the Babeltrace 1 project. Both projects can coexist
>>> on the
>>> same system as there are no common installed files.
>>>
>>> Signed-off-by: Anders Wallin 
>>> ---
>>>  .../recipes-kernel/lttng/babeltrace2_2.0.1.bb | 26 +++
>>>  1 file changed, 26 insertions(+)
>>>  create mode 100644 meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
>>>
>>> diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
>>> b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
>>> new file mode 100644
>>> index 00..d49a96faff
>>> --- /dev/null
>>> +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
>>> @@ -0,0 +1,26 @@
>>> +SUMMARY = "Babeltrace2 - Trace Format Babel Tower"
>>> +DESCRIPTION = "Babeltrace provides trace read and write libraries in
>>> host side, as well as a trace converter, which used to convert LTTng 2.0
>>> traces into human-readable log."
>>> +HOMEPAGE = "http://babeltrace.org/";
>>> +BUGTRACKER = "https://bugs.lttng.org/projects/babeltrace";
>>> +LICENSE = "MIT & GPLv2 & LGPLv2.1 & BSD-2-Clause"
>>> +LIC_FILES_CHKSUM = "file://LICENSE;md5=a6a458c13f18385b7bc5069a6d7b176e"
>>> +
>>> +DEPENDS = "glib-2.0 util-linux popt bison-native flex-native"
>>> +
>>> +SRC_URI = "git://
>>> git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0"
>>> +SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910"
>>> +UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)$"
>>> +
>>> +S = "${WORKDIR}/git"
>>> +
>>> +inherit autotools pkgconfig
>>> +
>>> +EXTRA_OECONF = "--disable-debug-info"
>>> +
>>> +PACKAGECONFIG ??= "manpages"
>>> +PACKAGECONFIG[manpages] = ", --disable-man-pages, asciidoc-native
>>> xmlto-native"
>>> +
>>> +FILES_${PN}-staticdev += "${libdir}/babeltrace2/plugins/*.a"
>>> +FILES_${PN} += "${libdir}/babeltrace2/plugins/*.so"
>>> +
>>> +ASNEEDED = ""
>>> --
>>> 2.25.0
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Zeus failed DHCP

[JH]

Hi,

My build connman on Thud works on WiFi, but Zeus does not work, the
connman could not get WiFi DHCP response, it puts a local IP address
169.254.24.188 to my WiFi interface. Has anyone found that the problem
in Zeus or it just me may be miss some packages or configuration?

What are packages could cause DHCP not working?

Here is Thud working log:

# systemctl status connman -l
��● connman.service - Connection service
   Loaded: loaded
(8;;file://solar/lib/systemd/system/connman.service/lib/systemd/system/connman.service8;;;
enabl)
   Active: active (running) since Thu 2020-02-13 03:18:51 UTC; 6 days ago
 Main PID: 131 (connmand)
   CGroup: /system.slice/connman.service
   ��└��─131 /usr/sbin/connmand -n

Feb 18 22:37:16 solar connmand[131]: rp_filter set to 2 (loose mode
routing), old value was 1
Feb 18 22:37:16 solar connmand[131]: mlan0 {add} address
192.168.0.100/24 label mlan0 family 2
Feb 18 22:37:16 solar connmand[131]: mlan0 {add} route 192.168.0.0 gw
0.0.0.0 scope 253 
Feb 18 22:37:16 solar connmand[131]: mlan0 {add} route 192.168.0.1 gw
0.0.0.0 scope 253 
Feb 18 22:37:16 solar connmand[131]: mlan0 {add} route 212.227.81.55
gw 192.168.0.1 scope 0 
Feb 18 22:37:17 solar connmand[131]: mlan0 {del} route 212.227.81.55
gw 192.168.0.1 scope 0 
Feb 18 22:37:17 solar connmand[131]: wwan0 {del} route 0.0.0.0 gw
10.114.57.126 scope 0 
Feb 18 22:37:17 solar connmand[131]: mlan0 {add} route 0.0.0.0 gw
192.168.0.1 scope 0 
Feb 18 22:37:17 solar connmand[131]: mlan0 {add} route 212.227.81.55
gw 192.168.0.1 scope 0 
Feb 18 22:37:17 solar connmand[131]: mlan0 {del} route 212.227.81.55
gw 192.168.0.1 scope 0 

# systemctl status wpa_supplicant -l
��● wpa_supplicant.service - WPA supplicant
   Loaded: loaded
(8;;file://solar/lib/systemd/system/wpa_supplicant.service/lib/systemd/system/wpa_supplicant.service8;;;
disabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-02-13 03:18:53 UTC; 6 days ago
 Main PID: 503 (wpa_supplicant)
   CGroup: /system.slice/wpa_supplicant.service
   ��└��─503 /usr/sbin/wpa_supplicant -u

Feb 19 07:37:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 07:47:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 07:57:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:07:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:17:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:19:01 solar wpa_supplicant[503]: mlan0:
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-85 noise=-97 txrate=1000
Feb 19 08:27:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:37:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:47:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]
Feb 19 08:57:29 solar wpa_supplicant[503]: mlan0: WPA: Group rekeying
completed with 34:08:04:12:b1:a2 [GTK=TKIP]

Here is Zenu build did not work:

# systemctl status connman -l
* connman.service - Connection service
   Loaded: loaded
(8;;file://solar/lib/systemd/system/connman.service/lib/systemd/system/connman.service8;;;
enabled; vendor preset: enabled)
   Active: active (running) since Tue 2020-02-18 00:47:43 UTC; 1 day 9h ago
 Main PID: 184 (connmand)
   CGroup: /system.slice/connman.service
   `-184 /usr/sbin/connmand -n

Feb 19 10:27:33 solar connmand[184]: mlan0 {newlink} index 3 operstate
5 
Feb 19 10:27:33 solar connmand[184]: mlan0 {add} route ff00:: gw ::
scope 0 
Feb 19 10:27:33 solar connmand[184]: mlan0 {add} route fe80:: gw ::
scope 0 
Feb 19 10:27:33 solar connmand[184]: mlan0 {RX} 10 packets 1650 bytes
Feb 19 10:27:33 solar connmand[184]: mlan0 {TX} 256 packets 96668 bytes
Feb 19 10:27:33 solar connmand[184]: mlan0 {update} flags 102467

Feb 19 10:27:33 solar connmand[184]: mlan0 {newlink} index 3 address
D4:CA:6E:9A:7E:29 mtu 1500
Feb 19 10:27:33 solar connmand[184]: mlan0 {newlink} index 3 operstate 6 
Feb 19 10:28:13 solar connmand[184]: mlan0 {add} address
169.254.241.106/16 label mlan0 family 2
Feb 19 10:28:14 solar connmand[184]: mlan0 {add} route 169.254.0.0 gw
0.0.0.0 scope 253 


# systemctl status wpa_supplicant -l
* wpa_supplicant.service - WPA supplicant
   Loaded: loaded
(8;;file://solar/lib/systemd/system/wpa_supplicant.service/lib/systemd/system/wpa_supplicant.service8;;;
disabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-02-18 00:47:48 UTC; 1 day 9h ago
 Main PID: 263 (wpa_supplicant)
   CGroup: /system.slice/wpa_supplicant.service
   `-263 /usr/sbin/wpa_supplicant -u

Feb 19 09:57:33 solar wpa_supplicant[263]: mlan0:
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-47 noise=-92 txrat

Re: [OE-core] oe-core recipe for defining directories in /

[Quentin Schulz]

Hi JH,

On Wed, Feb 19, 2020 at 09:12:08PM +1100, JH wrote:
> Hi,
> 
> Which recipe defines all directories in "/"? I need to make a bbapand
> to add directories to /.
> 

None. Or all of them, depends on how one sees it.

You just create a directory in do_install of a recipe.

You then make sure this directory is part of a package by checking it's
in one of the recipe's generated packages's FILES_.

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

[OE-core] oe-core recipe for defining directories in /

[JH]

Hi,

Which recipe defines all directories in "/"? I need to make a bbapand
to add directories to /.

Thank you.

Kind regards,

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

Re: [OE-core] [PATCH] babeltrace2: added 2.0.1

[Anders Wallin]

Hi Alex,

I think it's better to use babeltrace2 since it's a new version of
babeltrace.
The dist packages uses babeltrace2 and the main application/program is
called babeltrace2.

Jonatan; Do you have any comment on the naming?

Regards
Anders Wallin


On Tue, Feb 18, 2020 at 2:56 PM Alexander Kanavin 
wrote:

> Thanks. May I request that this recipe is named babletrace, while
> babeltrace 1.x recipe is at the same time renamed to babeltrace1? I'd like
> to avoid adding version numbers to the 'latest' version. Lttng should at
> the same time be adjusted to use babeltrace1, as advised by upstream.
>
> Alex
>
> On Tue, 18 Feb 2020 at 14:21, Anders Wallin  wrote:
>
>> Babeltrace 1 vs. Babeltrace 2
>>
>> The Babeltrace project exists since 2010. In 2020, Babeltrace 2 was
>> released.
>> Babeltrace 2 is a complete rewrite of the library, Python bindings, and
>> CLI. It
>> is plugin based and offers much more features and potential than
>> Babeltrace 1.
>>
>> Because Babeltrace 2 is still a young released project, some
>> distributions still
>> provide packages for the Babeltrace 1 project. Both projects can coexist
>> on the
>> same system as there are no common installed files.
>>
>> Signed-off-by: Anders Wallin 
>> ---
>>  .../recipes-kernel/lttng/babeltrace2_2.0.1.bb | 26 +++
>>  1 file changed, 26 insertions(+)
>>  create mode 100644 meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
>>
>> diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
>> b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
>> new file mode 100644
>> index 00..d49a96faff
>> --- /dev/null
>> +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
>> @@ -0,0 +1,26 @@
>> +SUMMARY = "Babeltrace2 - Trace Format Babel Tower"
>> +DESCRIPTION = "Babeltrace provides trace read and write libraries in
>> host side, as well as a trace converter, which used to convert LTTng 2.0
>> traces into human-readable log."
>> +HOMEPAGE = "http://babeltrace.org/";
>> +BUGTRACKER = "https://bugs.lttng.org/projects/babeltrace";
>> +LICENSE = "MIT & GPLv2 & LGPLv2.1 & BSD-2-Clause"
>> +LIC_FILES_CHKSUM = "file://LICENSE;md5=a6a458c13f18385b7bc5069a6d7b176e"
>> +
>> +DEPENDS = "glib-2.0 util-linux popt bison-native flex-native"
>> +
>> +SRC_URI = "git://
>> git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0"
>> +SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910"
>> +UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)$"
>> +
>> +S = "${WORKDIR}/git"
>> +
>> +inherit autotools pkgconfig
>> +
>> +EXTRA_OECONF = "--disable-debug-info"
>> +
>> +PACKAGECONFIG ??= "manpages"
>> +PACKAGECONFIG[manpages] = ", --disable-man-pages, asciidoc-native
>> xmlto-native"
>> +
>> +FILES_${PN}-staticdev += "${libdir}/babeltrace2/plugins/*.a"
>> +FILES_${PN} += "${libdir}/babeltrace2/plugins/*.so"
>> +
>> +ASNEEDED = ""
>> --
>> 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: [OE-core] [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

On Tue, 18 Feb 2020 at 02:56, Khem Raj  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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core