Re: [OE-core] [meta-clang][PATCH] conf/nonclangable.conf: Always build mesa with gcc

[Khem Raj]

Can you send it via github pull request please

On Wed, Feb 26, 2020 at 10:21 PM Böszörményi Zoltán via
Openembedded-core  wrote:
>
> Ignore this, the patch is against the zeus branch.
> Re-sent with the proper subject.
>
> 2020. 02. 27. 7:16 keltezéssel, Böszörményi Zoltán írta:
> > Building mesa (at least version 19.3.4) with clang 9.0.1 leads
> > to linker errors on x86/x86-64:
> >
> > "undefined reference to `typeinfo for llvm::raw_pwrite_stream'"
> > in libvulkan_radeon.so
> >
> > and
> >
> > "undefined reference to `typeinfo for llvm::RTDyldMemoryManager'"
> > in libgallium.a.
> >
> > It was reported at https://gitlab.freedesktop.org/mesa/mesa/issues/2533
> >
> > It seems it is related to rtti not being enabled, at least reports
> > from a few years ago on forums lead to that conclusion.
> > But enabling rtti for clang in PACKAGECONFIG doesn't help.
> >
> > Just build mesa with gcc, it fixes the linker errors.
> >
> > Signed-off-by: Böszörményi Zoltán 
> > ---
> >   conf/nonclangable.conf | 7 +++
> >   1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/conf/nonclangable.conf b/conf/nonclangable.conf
> > index 70336bb..91b9965 100644
> > --- a/conf/nonclangable.conf
> > +++ b/conf/nonclangable.conf
> > @@ -45,10 +45,9 @@ TOOLCHAIN_pn-libssp-nonshared = "gcc"
> >   TOOLCHAIN_pn-libstd-rs = "gcc"
> >   TOOLCHAIN_pn-m4_powerpc = "gcc"
> >   # clang does not have 64bit atomics on mips32
> > -TOOLCHAIN_pn-mesa_mips = "gcc"
> > -TOOLCHAIN_pn-mesa_mipsel = "gcc"
> > -TOOLCHAIN_pn-mesa_riscv64 = "gcc"
> > -TOOLCHAIN_pn-mesa_powerpc = "gcc"
> > +# building Mesa 19.3.x with clang causes linker errors on x86/x86-64
> > +# See https://gitlab.freedesktop.org/mesa/mesa/issues/2533
> > +TOOLCHAIN_pn-mesa = "gcc"
> >   # multiple definition of 'mongo::error_details::isNamedCode<0>'
> >   TOOLCHAIN_pn-mongodb = "gcc"
> >   # variant-impl.hpp:309:36: error: 'is_variant' does not name a template 
> > but is followed by template arguments
> >
>
> --
> ___
> 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] ✗ patchtest: failure for conf/nonclangable.conf: Always build mesa with gcc (rev2)

[Patchwork]

== Series Details ==

Series: conf/nonclangable.conf: Always build mesa with gcc (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/22979/
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:



* Patch[meta-clang,zeus] conf/nonclangable.conf: Always build mesa 
with gcc
 Issue Series sent to the wrong mailing list 
[test_target_mailing_list] 
  Suggested fixCheck the project's README (meta-clang,zeus) and send the 
patch to the indicated list

* 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  zeus (currently at f39285bb82)



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 conf/nonclangable.conf: Always build mesa with gcc

[Patchwork]

== Series Details ==

Series: conf/nonclangable.conf: Always build mesa with gcc
Revision: 1
URL   : https://patchwork.openembedded.org/series/22979/
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:



* Patch[meta-clang] conf/nonclangable.conf: Always build mesa with 
gcc
 Issue Series sent to the wrong mailing list 
[test_target_mailing_list] 
  Suggested fixCheck the project's README (meta-clang) and send the patch 
to the indicated list

* 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 23ad05b98a)



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] [meta-clang][PATCH] conf/nonclangable.conf: Always build mesa with gcc

[Böszörményi Zoltán via Openembedded-core]

Ignore this, the patch is against the zeus branch.
Re-sent with the proper subject.

2020. 02. 27. 7:16 keltezéssel, Böszörményi Zoltán írta:

Building mesa (at least version 19.3.4) with clang 9.0.1 leads
to linker errors on x86/x86-64:

"undefined reference to `typeinfo for llvm::raw_pwrite_stream'"
in libvulkan_radeon.so

and

"undefined reference to `typeinfo for llvm::RTDyldMemoryManager'"
in libgallium.a.

It was reported at https://gitlab.freedesktop.org/mesa/mesa/issues/2533

It seems it is related to rtti not being enabled, at least reports
from a few years ago on forums lead to that conclusion.
But enabling rtti for clang in PACKAGECONFIG doesn't help.

Just build mesa with gcc, it fixes the linker errors.

Signed-off-by: Böszörményi Zoltán 
---
  conf/nonclangable.conf | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/conf/nonclangable.conf b/conf/nonclangable.conf
index 70336bb..91b9965 100644
--- a/conf/nonclangable.conf
+++ b/conf/nonclangable.conf
@@ -45,10 +45,9 @@ TOOLCHAIN_pn-libssp-nonshared = "gcc"
  TOOLCHAIN_pn-libstd-rs = "gcc"
  TOOLCHAIN_pn-m4_powerpc = "gcc"
  # clang does not have 64bit atomics on mips32
-TOOLCHAIN_pn-mesa_mips = "gcc"
-TOOLCHAIN_pn-mesa_mipsel = "gcc"
-TOOLCHAIN_pn-mesa_riscv64 = "gcc"
-TOOLCHAIN_pn-mesa_powerpc = "gcc"
+# building Mesa 19.3.x with clang causes linker errors on x86/x86-64
+# See https://gitlab.freedesktop.org/mesa/mesa/issues/2533
+TOOLCHAIN_pn-mesa = "gcc"
  # multiple definition of 'mongo::error_details::isNamedCode<0>'
  TOOLCHAIN_pn-mongodb = "gcc"
  # variant-impl.hpp:309:36: error: 'is_variant' does not name a template but 
is followed by template arguments



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

[OE-core] [meta-clang][zeus][PATCH] conf/nonclangable.conf: Always build mesa with gcc

[Böszörményi Zoltán via Openembedded-core]

Building mesa (at least version 19.3.4) with clang 9.0.1 leads
to linker errors on x86/x86-64:

"undefined reference to `typeinfo for llvm::raw_pwrite_stream'"
in libvulkan_radeon.so

and

"undefined reference to `typeinfo for llvm::RTDyldMemoryManager'"
in libgallium.a.

It was reported at https://gitlab.freedesktop.org/mesa/mesa/issues/2533

It seems it is related to rtti not being enabled, at least reports
from a few years ago on forums lead to that conclusion.
But enabling rtti for clang in PACKAGECONFIG doesn't help.

Just build mesa with gcc, it fixes the linker errors.

Signed-off-by: Böszörményi Zoltán 
---
 conf/nonclangable.conf | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/conf/nonclangable.conf b/conf/nonclangable.conf
index 70336bb..91b9965 100644
--- a/conf/nonclangable.conf
+++ b/conf/nonclangable.conf
@@ -45,10 +45,9 @@ TOOLCHAIN_pn-libssp-nonshared = "gcc"
 TOOLCHAIN_pn-libstd-rs = "gcc"
 TOOLCHAIN_pn-m4_powerpc = "gcc"
 # clang does not have 64bit atomics on mips32
-TOOLCHAIN_pn-mesa_mips = "gcc"
-TOOLCHAIN_pn-mesa_mipsel = "gcc"
-TOOLCHAIN_pn-mesa_riscv64 = "gcc"
-TOOLCHAIN_pn-mesa_powerpc = "gcc"
+# building Mesa 19.3.x with clang causes linker errors on x86/x86-64
+# See https://gitlab.freedesktop.org/mesa/mesa/issues/2533
+TOOLCHAIN_pn-mesa = "gcc"
 # multiple definition of 'mongo::error_details::isNamedCode<0>'
 TOOLCHAIN_pn-mongodb = "gcc"
 # variant-impl.hpp:309:36: error: 'is_variant' does not name a template but is 
followed by template arguments
-- 
2.24.1

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

[OE-core] [meta-clang][PATCH] conf/nonclangable.conf: Always build mesa with gcc

[Böszörményi Zoltán via Openembedded-core]

Building mesa (at least version 19.3.4) with clang 9.0.1 leads
to linker errors on x86/x86-64:

"undefined reference to `typeinfo for llvm::raw_pwrite_stream'"
in libvulkan_radeon.so

and

"undefined reference to `typeinfo for llvm::RTDyldMemoryManager'"
in libgallium.a.

It was reported at https://gitlab.freedesktop.org/mesa/mesa/issues/2533

It seems it is related to rtti not being enabled, at least reports
from a few years ago on forums lead to that conclusion.
But enabling rtti for clang in PACKAGECONFIG doesn't help.

Just build mesa with gcc, it fixes the linker errors.

Signed-off-by: Böszörményi Zoltán 
---
 conf/nonclangable.conf | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/conf/nonclangable.conf b/conf/nonclangable.conf
index 70336bb..91b9965 100644
--- a/conf/nonclangable.conf
+++ b/conf/nonclangable.conf
@@ -45,10 +45,9 @@ TOOLCHAIN_pn-libssp-nonshared = "gcc"
 TOOLCHAIN_pn-libstd-rs = "gcc"
 TOOLCHAIN_pn-m4_powerpc = "gcc"
 # clang does not have 64bit atomics on mips32
-TOOLCHAIN_pn-mesa_mips = "gcc"
-TOOLCHAIN_pn-mesa_mipsel = "gcc"
-TOOLCHAIN_pn-mesa_riscv64 = "gcc"
-TOOLCHAIN_pn-mesa_powerpc = "gcc"
+# building Mesa 19.3.x with clang causes linker errors on x86/x86-64
+# See https://gitlab.freedesktop.org/mesa/mesa/issues/2533
+TOOLCHAIN_pn-mesa = "gcc"
 # multiple definition of 'mongo::error_details::isNamedCode<0>'
 TOOLCHAIN_pn-mongodb = "gcc"
 # variant-impl.hpp:309:36: error: 'is_variant' does not name a template but is 
followed by template arguments
-- 
2.24.1

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

Re: [OE-core] Overriding SDE_FILE

[Douglas Royds via Openembedded-core]

On 26/02/20 4:53 am, Jacob Kroon wrote:


On 2/24/20 8:25 AM, Jacob Kroon wrote:

Hi Douglas,

You updated a comment in reproducible_build.bbclass, commit 
e7b891b76954c784f5a93bd0a1c91315673ce40d:


-# Once the value of SOURCE_DATE_EPOCH is determined, it is stored 
in the recipe's ${SDE_FILE}.
+# Once the value of SOURCE_DATE_EPOCH is determined, it is stored 
in the recipe's SDE_FILE.
+# If none of these mechanisms are suitable, replace the 
do_deploy_source_date_epoch task
+# with recipe-specific functionality to write the appropriate 
SOURCE_DATE_EPOCH into the SDE_FILE.

+#


But I can't really get this to work. What did work for me was to 
replace "do_create_source_date_epoch_stamp()" in my recipe:


do_create_source_date_epoch_stamp() {
 mkdir -p ${SDE_DIR}
 date -d "1981-03-03" "+%s" > ${SDE_FILE}
}

What is the intended way to achieve the thing I'm trying to do here ?



FYI, JPEW has a proposed patch here

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible=d091d2aa53ea417f70c10f5ce89151820c3db9ce 



for allowing a recipe to just set SOURCE_DATE_EPOCH directly.

But maybe that currently is at odds with SOURCE_DATE_EPOCH being in 
BB_HASHBASE_WHITELIST ?


/Jacob



On the surface of it, my comment appears to be just wrong: It does make 
sense to replace do_create_source_date_epoch_stamp() as you suggest.


Joshua's proposed patch looks promising:

 * Should the new function not be called first, so that it takes
   priority over the git, known files, and youngest file functions? If
   someone has explicitly set SOURCE_DATE_EPOCH, then they want it to
   take priority.
 * As you observe, SOURCE_DATE_EPOCH would need to be removed from
   BB_HASHBASE_WHITELIST. I'm not sure why it was in the whitelist in
   the first place.

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

[OE-core] [PATCH] qemu: fix CVE-2020-7039

[changqing.li]

From: Changqing Li 

Signed-off-by: Changqing Li 
---
 meta/recipes-devtools/qemu/qemu.inc|  3 +
 .../qemu/qemu/CVE-2020-7039-1.patch| 44 +++
 .../qemu/qemu/CVE-2020-7039-2.patch| 59 
 .../qemu/qemu/CVE-2020-7039-3.patch| 64 ++
 4 files changed, 170 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-7039-1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-7039-2.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-7039-3.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index a557e74..a9d5278 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -29,6 +29,9 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0010-configure-Add-pkg-config-handling-for-libgcrypt.patch \

file://0011-hw-i386-pc-fix-regression-in-parsing-vga-cmdline-par.patch \
file://CVE-2019-15890.patch \
+   file://CVE-2020-7039-1.patch \
+   file://CVE-2020-7039-2.patch \
+   file://CVE-2020-7039-3.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-7039-1.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-7039-1.patch
new file mode 100644
index 000..df6bca6
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-7039-1.patch
@@ -0,0 +1,44 @@
+From b2663d527a1992ba98c0266458b21ada3b9d0d2e Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Thu, 27 Feb 2020 12:07:35 +0800
+Subject: [PATCH] tcp_emu: Fix oob access
+
+The main loop only checks for one available byte, while we sometimes
+need two bytes.
+
+CVE: CVE-2020-7039
+Upstream-Status: Backport
+[https://gitlab.freedesktop.org/slirp/libslirp/commit/2655fffed7a9e765bcb4701dd876e9dab975f289]
+
+Signed-off-by: Changqing Li 
+---
+ slirp/src/tcp_subr.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/slirp/src/tcp_subr.c b/slirp/src/tcp_subr.c
+index d6dd133..4bea2d4 100644
+--- a/slirp/src/tcp_subr.c
 b/slirp/src/tcp_subr.c
+@@ -886,6 +886,8 @@ int tcp_emu(struct socket *so, struct mbuf *m)
+ break;
+ 
+ case 5:
++if (bptr == m->m_data + m->m_len - 1)
++return 1; /* We need two bytes */
+ /*
+  * The difference between versions 1.0 and
+  * 2.0 is here. For future versions of
+@@ -901,6 +903,10 @@ int tcp_emu(struct socket *so, struct mbuf *m)
+ /* This is the field containing the port
+  * number that RA-player is listening to.
+  */
++
++if (bptr == m->m_data + m->m_len - 1)
++return 1; /* We need two bytes */
++
+ lport = (((uint8_t *)bptr)[0] << 8) + ((uint8_t *)bptr)[1];
+ if (lport < 6970)
+ lport += 256; /* don't know why */
+-- 
+2.7.4
+
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-7039-2.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-7039-2.patch
new file mode 100644
index 000..4a00fa2
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-7039-2.patch
@@ -0,0 +1,59 @@
+From 8f67e76e4148e37f3d8d2bcbdee7417fdedb7669 Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Thu, 27 Feb 2020 12:10:34 +0800
+Subject: [PATCH] slirp: use correct size while emulating commands
+
+While emulating services in tcp_emu(), it uses 'mbuf' size
+'m->m_size' to write commands via snprintf(3). Use M_FREEROOM(m)
+size to avoid possible OOB access.
+Signed-off-by: default avatarPrasad J Pandit 
+Signed-off-by: Samuel Thibault's avatarSamuel Thibault
+
+Message-Id: <20200109094228.79764-3-ppan...@redhat.com>
+
+CVE: CVE-2020-7039
+Upstream-Status: Backport
+[https://gitlab.freedesktop.org/slirp/libslirp/commit/82ebe9c370a0e2970fb5695aa19aa5214a6a1c80]
+
+Signed-off-by: Changqing Li 
+---
+ slirp/src/tcp_subr.c | 9 -
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+diff --git a/slirp/src/tcp_subr.c b/slirp/src/tcp_subr.c
+index 4bea2d4..e8ed4ef 100644
+--- a/slirp/src/tcp_subr.c
 b/slirp/src/tcp_subr.c
+@@ -696,7 +696,7 @@ int tcp_emu(struct socket *so, struct mbuf *m)
+ n4 = (laddr & 0xff);
+ 
+ m->m_len = bptr - m->m_data; /* Adjust length */
+-m->m_len += snprintf(bptr, m->m_size - m->m_len,
++m->m_len += snprintf(bptr, M_FREEROOM(m),
+  "ORT %d,%d,%d,%d,%d,%d\r\n%s", n1, n2, n3, 
n4,
+  n5, n6, x == 7 ? buff : "");
+ return 1;
+@@ -731,8 +731,7 @@ int tcp_emu(struct socket *so, struct mbuf *m)
+ n4 = (laddr & 0xff);
+ 
+ m->m_len = bptr - m->m_data; /* Adjust length */
+-m->m_len +=
+-snprintf(bptr, m->m_size - 

[OE-core] [PATCH v2 4/4] mesa: Add PACKAGECONFIG knob to enable VDPAU state tracker and drivers

[Böszörményi Zoltán via Openembedded-core]

Signed-off-by: Böszörményi Zoltán 
---
v2: Replaced FILES_${PN}-vdpau-drivers with FILES_mesa-vdpau-drivers
to match the name in PACKAGES.

 meta/recipes-graphics/mesa/mesa.inc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 479d3223fa..800e8813c7 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -144,6 +144,8 @@ PACKAGECONFIG[gallium-llvm] = "-Dllvm=true 
-Dshared-llvm=true, -Dllvm=false, llv
 PACKAGECONFIG[xa]  = "-Dgallium-xa=true, -Dgallium-xa=false"
 PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
 
+PACKAGECONFIG[vdpau] = "-Dgallium-vdpau=true,-Dgallium-vdpau=false,libvdpau"
+
 PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', 
'', d)}"
 
@@ -179,6 +181,7 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
  libgles3-mesa libgles3-mesa-dev \
  libxatracker libxatracker-dev \
  mesa-megadriver mesa-vulkan-drivers \
+ mesa-vdpau-drivers \
 "
 
 do_install_append () {
@@ -256,6 +259,7 @@ PACKAGES_DYNAMIC += "^mesa-driver-.*"
 
 FILES_mesa-megadriver = "${libdir}/dri/* 
${datadir}/drirc.d/00-mesa-defaults.conf"
 FILES_mesa-vulkan-drivers = "${libdir}/libvulkan_*.so ${datadir}/vulkan"
+FILES_mesa-vdpau-drivers = "${libdir}/vdpau/*.so.*"
 FILES_libegl-mesa = "${libdir}/libEGL.so.*"
 FILES_libgbm = "${libdir}/libgbm.so.*"
 FILES_libgles1-mesa = "${libdir}/libGLESv1*.so.*"
@@ -265,7 +269,7 @@ FILES_libglapi = "${libdir}/libglapi.so.*"
 FILES_libosmesa = "${libdir}/libOSMesa.so.*"
 FILES_libxatracker = "${libdir}/libxatracker.so.*"
 
-FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan"
+FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan 
${libdir}/vdpau/*.so"
 FILES_libegl-mesa-dev = "${libdir}/libEGL.* ${includedir}/EGL 
${includedir}/KHR ${libdir}/pkgconfig/egl.pc"
 FILES_libgbm-dev = "${libdir}/libgbm.* ${libdir}/pkgconfig/gbm.pc 
${includedir}/gbm.h"
 FILES_libgl-mesa-dev = "${libdir}/libGL.* ${includedir}/GL 
${libdir}/pkgconfig/gl.pc"
-- 
2.24.1

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

[OE-core] [PATCH v2 2/4] libva-initial: New bootstrap recipe

[Böszörményi Zoltán via Openembedded-core]

Mesa needs libva.pc and libva headers to enable the VAAPI
state tracker and drivers.

This recipe is a variant of the full libva package build as in:
* it only depends on libdrm to build so it doesn't introduce
  the circular dependency between mesa and libva, and
* it doesn't include the libraries in the final package.

However, there is another issue with build dependency handling
in Yocto. libva depends on mesa and mesa depends on this package.
Any package that depends on libva therefore would pull in libva
and this package resulting in an error in the prepare-sysroot
phase because they would install identical files into the
per-recipe sysroot.

Using the package name "*-initial" avoids this because of the
interaction between sstate.bbclass and staging.bbclass: any
package with the pattern "*-initial" in the name is excluded
from the dependency list unless explicitly added to DEPENDS.

Signed-off-by: Böszörményi Zoltán 
---
v2: The include file is not versioned, more verbose commit message

 meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 9 +
 meta/recipes-graphics/libva/libva.inc  | 4 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..a3b04eb02a
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,9 @@
+require libva.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
+SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
+SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
diff --git a/meta/recipes-graphics/libva/libva.inc 
b/meta/recipes-graphics/libva/libva.inc
index 058581f7d1..6a3427b5b1 100644
--- a/meta/recipes-graphics/libva/libva.inc
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -16,7 +16,9 @@ BUGTRACKER = "https://github.com/intel/libva/issues;
 SECTION = "x11"
 LICENSE = "MIT"
 
-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
+
+S = "${WORKDIR}/libva-${PV}"
 
 UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
 
-- 
2.24.1

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

[OE-core] [PATCH v2 0/4] Enable VAAPI and VDPAU video drivers in Mesa

[Böszörményi Zoltán via Openembedded-core]

Mesa needs libva to enable VAAPI state tracker and drivers.
libva needs Mesa to enable its GLX part.

This is a circular dependency that can be solved by introducing
a new libva recipe variant that doesn't enable GLX.

Actually, the presence of Mesa/OpenGL headers is autodetected
in libva so it's enough to leave out Mesa from DEPENDS in the
new libva recipe variant.

With magic already existing in sstate.bbclass and staging.bbclass,
naming the new libva recipe variant "libva-initial" avoids an
error for every other recipe that pulls in libva as dependency,
including libva-utils and intel-vaapi-driver.

The error (if not naming the recipe as "*-initial") is that
the prepare-sysroot phase of a package would pull in the files 
rom both libva build variants that would obviously install identical
files.

Enabling the VDPAU state tracker and libraries is trivial,
it was just missing from the recipe.

[PATCH v2 1/4] libva: Factor out base parts into an include file
[PATCH v2 2/4] libva-initial: New bootstrap recipe
[PATCH v2 3/4] mesa: Add PACKAGECONFIG knob to enable VAAPI
[PATCH v2 4/4] mesa: Add PACKAGECONFIG knob to enable VDPAU state

Signed-off-by: Böszörményi Zoltán 


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

[OE-core] [PATCH v2 1/4] libva: Factor out base parts into an include file

[Böszörményi Zoltán via Openembedded-core]

To enable the VAAPI state tracker and drivers in mesa, it needs
libva.pc and the libva headers. At the recipe level, this would
create a circular dependency between libva and mesa.

This is a preparation step before introducing a new libva recipe
variant to break the circular dependency.

Signed-off-by: Böszörményi Zoltán 
---
v2: The include file is not versioned, verbose commit message

 meta/recipes-graphics/libva/libva.inc  | 27 ++
 meta/recipes-graphics/libva/libva_2.6.1.bb | 27 ++
 2 files changed, 29 insertions(+), 25 deletions(-)
 create mode 100644 meta/recipes-graphics/libva/libva.inc

diff --git a/meta/recipes-graphics/libva/libva.inc 
b/meta/recipes-graphics/libva/libva.inc
new file mode 100644
index 00..058581f7d1
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -0,0 +1,27 @@
+SUMMARY = "Video Acceleration (VA) API for Linux"
+DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
+and API specification which enables and provides access to graphics \
+hardware (GPU) acceleration for video processing on Linux and UNIX \
+based operating systems. Accelerated processing includes video \
+decoding, video encoding, subpicture blending and rendering. The \
+specification was originally designed by Intel for its GMA (Graphics \
+Media Accelerator) series of GPU hardware, the API is however not \
+limited to GPUs or Intel specific hardware, as other hardware and \
+manufacturers can also freely use this API for hardware accelerated \
+video decoding."
+
+HOMEPAGE = "https://01.org/linuxmedia/vaapi;
+BUGTRACKER = "https://github.com/intel/libva/issues;
+
+SECTION = "x11"
+LICENSE = "MIT"
+
+SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+
+UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
+
+DEPENDS = "libdrm"
+
+inherit meson pkgconfig features_check
+
+REQUIRED_DISTRO_FEATURES = "opengl"
diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb 
b/meta/recipes-graphics/libva/libva_2.6.1.bb
index 92cea83bc1..b68fb27136 100644
--- a/meta/recipes-graphics/libva/libva_2.6.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -1,33 +1,10 @@
-SUMMARY = "Video Acceleration (VA) API for Linux"
-DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
-and API specification which enables and provides access to graphics \
-hardware (GPU) acceleration for video processing on Linux and UNIX \
-based operating systems. Accelerated processing includes video \
-decoding, video encoding, subpicture blending and rendering. The \
-specification was originally designed by Intel for its GMA (Graphics \
-Media Accelerator) series of GPU hardware, the API is however not \
-limited to GPUs or Intel specific hardware, as other hardware and \
-manufacturers can also freely use this API for hardware accelerated \
-video decoding."
+require libva.inc
 
-HOMEPAGE = "https://01.org/linuxmedia/vaapi;
-BUGTRACKER = "https://github.com/intel/libva/issues;
-
-SECTION = "x11"
-LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
-
-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
 SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
 SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
 
-UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
-
-DEPENDS = "libdrm virtual/mesa"
-
-inherit meson pkgconfig features_check
-
-REQUIRED_DISTRO_FEATURES = "opengl"
+DEPENDS += "virtual/mesa"
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)}"
 PACKAGECONFIG[x11] = "-Dwith_x11=yes, -Dwith_x11=no,virtual/libx11 libxext 
libxfixes"
-- 
2.24.1

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

[OE-core] [PATCH v2 3/4] mesa: Add PACKAGECONFIG knob to enable VAAPI

[Böszörményi Zoltán via Openembedded-core]

The previously added libva-initial recipe makes it possible and
trivial.

Signed-off-by: Böszörményi Zoltán 
---
v2: Small explanation in the commit message

 meta/recipes-graphics/mesa/mesa.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 87f167c507..479d3223fa 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -142,6 +142,7 @@ PACKAGECONFIG[gallium] = 
"-Dgallium-drivers=${GALLIUMDRIVERS}, -Dgallium-drivers
 PACKAGECONFIG[gallium-llvm] = "-Dllvm=true -Dshared-llvm=true, -Dllvm=false, 
llvm${MESA_LLVM_RELEASE} llvm-native \
${@'elfutils' if 
${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
 PACKAGECONFIG[xa]  = "-Dgallium-xa=true, -Dgallium-xa=false"
+PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
 
 PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', 
'', d)}"
-- 
2.24.1

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

[OE-core] [PATCH] wic: Add include-dir option

[Armin Kuster]

This option allows for the inclusion of a single directory
for a partition.

Signed-off-by: Armin Kuster 
---
 scripts/lib/wic/help.py  |  3 +++
 scripts/lib/wic/ksparser.py  |  1 +
 scripts/lib/wic/partition.py |  1 +
 scripts/lib/wic/plugins/source/rootfs.py | 10 --
 4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index 4d342fcf05..517f68e11e 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -979,6 +979,9 @@ DESCRIPTION
  copies. This option only has an effect with the rootfs
  source plugin.
 
+ --include-dir: This option is specific to wic. It adds the contents
+of the given directory to the resulting partition. 
+
  --extra-space: This option is specific to wic. It adds extra
 space after the space filled by the content
 of the partition. The final size can go
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index 650b976223..b8abc33c87 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -138,6 +138,7 @@ class KickStart():
 part.add_argument('--align', type=int)
 part.add_argument('--exclude-path', nargs='+')
 part.add_argument('--include-path', nargs='+')
+part.add_argument('--include-dir')
 part.add_argument("--extra-space", type=sizetype)
 part.add_argument('--fsoptions', dest='fsopts')
 part.add_argument('--fstype', default='vfat',
diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 2d95f78439..0b735fffd9 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -31,6 +31,7 @@ class Partition():
 self.extra_space = args.extra_space
 self.exclude_path = args.exclude_path
 self.include_path = args.include_path
+self.include_dir = args.include_dir
 self.fsopts = args.fsopts
 self.fstype = args.fstype
 self.label = args.label
diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
b/scripts/lib/wic/plugins/source/rootfs.py
index 705aeb5563..d1c59cab8a 100644
--- a/scripts/lib/wic/plugins/source/rootfs.py
+++ b/scripts/lib/wic/plugins/source/rootfs.py
@@ -71,7 +71,7 @@ class RootfsPlugin(SourcePlugin):
 
 new_rootfs = None
 # Handle excluded paths.
-if part.exclude_path or part.include_path:
+if part.exclude_path or part.include_path or part.include_dir:
 # We need a new rootfs directory we can delete files from. Copy to
 # workdir.
 new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" 
% part.lineno))
@@ -79,7 +79,13 @@ class RootfsPlugin(SourcePlugin):
 if os.path.lexists(new_rootfs):
 shutil.rmtree(os.path.join(new_rootfs))
 
-copyhardlinktree(part.rootfs_dir, new_rootfs)
+if part.include_dir:
+src = os.path.realpath(os.path.join(part.rootfs_dir, 
part.include_dir))
+dst = os.path.realpath(os.path.join(new_rootfs, 
part.include_dir))
+copyhardlinktree(src, dst)
+
+else:
+copyhardlinktree(part.rootfs_dir, new_rootfs)
 
 for path in part.include_path or []:
 copyhardlinktree(path, new_rootfs)
-- 
2.17.1

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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 21:31 keltezéssel, Khem Raj írta:



On 2/26/20 12:21 PM, Böszörményi Zoltán wrote:

2020. 02. 26. 20:44 keltezéssel, Khem Raj írta:



On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:

2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:



On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán 
wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.


don't assume things


Understood.


http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html




I am trying to make us thing if -dev package can be used somehow to
avoid this
or have we exhausted all possibilities.


Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?


it is not a problem, however, it is a work to keep such setup going and
also it has to be considered always in dependencies etc.


Surely it's not reserved for libgcc-initial and friends.



they are different usecases, libgcc-initial is a veneer/trampoline used
to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.


It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
    circular dependency is avoided. mesa needs a crippled libva
(pkgconfig + headers)
    to build its VAAPI state tracker and the VAAPI drivers


I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE


Fedora also uses the full libva.

However, the chicken-and-egg circular dependency is broken by history
for these distros.

Koji and Mock build one package at a time with all their dependencies
already available from the staging package repository and the results
will be eventually uploaded to the same repository.

Bitbake doesn't have have this loophole to download pre-built dependencies.


Also, somewhere on 01.org or in the libva sources the same solution
I presented in this patchset is suggested:

1. build libva with --disable-glx (it is needed when Mesa SDK is present)
    but it's not needed by not depending on mesa in libva-initial
2. build mesa with libva build in (1) as it only needs the pkgconfig files
    and the headers
3. build libva with --enable-glx. It's autodetected, set to on with
    depending on mesa in the full libva recipe.


looking at the nature of the problem, it might be the way to unbreak the catch-22, does 
anything else needs this bootstrap header package ?


Besides DEPENDS="libdrm", no.


Sorry, I misread the question, it was too late after a workday.
Nothing else uses this bootstrap package just Mesa.




do we need to ensure that content of libva-dev and the bootstrap packages do 
not overlap.


I don't think so.
Apparently, the mesa-dev package built from this patchset
doesn't depend on libva-initial-dev and this latter package
doesn't get included into an image either. I guess the
sstate.bbclass internals deal with this properly.



OK, I guess, we should give it a test.







Obviusly the same libva recipe can't be used to build mesa that depends on mesa.








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

[OE-core] [PATCH v2] libarchive: Fix CVE-2020-9308

[Wenlin Kang]

Fix CVE-2020-9308

Signed-off-by: Wenlin Kang 
---
 ...ct-files-that-declare-invalid-header.patch | 124 ++
 .../libarchive/libarchive_3.4.1.bb|   4 +-
 2 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch

diff --git 
a/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
 
b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
new file mode 100644
index 00..2b37d68d82
--- /dev/null
+++ 
b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
@@ -0,0 +1,124 @@
+From 94821008d6eea81e315c5881cdf739202961040a Mon Sep 17 00:00:00 2001
+From: Grzegorz Antoniak 
+Date: Sun, 2 Feb 2020 08:04:41 +0100
+Subject: [PATCH] RAR5 reader: reject files that declare invalid header flags
+
+One of the fields in RAR5's base block structure is the size of the
+header. Some invalid files declare a 0 header size setting, which can
+confuse the unpacker. Minimum header size for RAR5 base blocks is 7
+bytes (4 bytes for CRC, and 3 bytes for the rest), so block size of 0
+bytes should be rejected at header parsing stage.
+
+The fix adds an error condition if header size of 0 bytes is detected.
+In this case, the unpacker will not attempt to unpack the file, as the
+header is corrupted.
+
+The commit also adds OSSFuzz #20459 sample to test further regressions
+in this area.
+
+Upstream-Status: 
Backport[https://github.com/libarchive/libarchive/commit/94821008d6eea81e315c5881cdf739202961040a]
+CVE: CVE-2020-9308
+
+Signed-off-by: Wenlin Kang 
+---
+ Makefile.am |  1 +
+ libarchive/archive_read_support_format_rar5.c   | 17 +++--
+ libarchive/test/test_read_format_rar5.c | 15 +++
+ ...test_read_format_rar5_block_size_is_too_small.rar.uu |  8 
+ 4 files changed, 39 insertions(+), 2 deletions(-)
+ create mode 100644 
libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu
+
+diff --git a/Makefile.am b/Makefile.am
+index 06c2644..c65e243 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -877,6 +877,7 @@ libarchive_test_EXTRA_DIST=\
+   libarchive/test/test_read_format_rar5_win32.rar.uu \
+   
libarchive/test/test_read_format_rar5_arm_filter_on_window_boundary.rar.uu \
+   libarchive/test/test_read_format_rar5_different_winsize_on_merge.rar.uu 
\
++  libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu \
+   libarchive/test/test_read_format_raw.bufr.uu \
+   libarchive/test/test_read_format_raw.data.gz.uu \
+   libarchive/test/test_read_format_raw.data.Z.uu \
+diff --git a/libarchive/archive_read_support_format_rar5.c 
b/libarchive/archive_read_support_format_rar5.c
+index ff1d6f8..f7c163e 100644
+--- a/libarchive/archive_read_support_format_rar5.c
 b/libarchive/archive_read_support_format_rar5.c
+@@ -2085,6 +2085,8 @@ static int scan_for_signature(struct archive_read* a);
+ static int process_base_block(struct archive_read* a,
+ struct archive_entry* entry)
+ {
++  const size_t SMALLEST_RAR5_BLOCK_SIZE = 3;
++
+   struct rar5* rar = get_context(a);
+   uint32_t hdr_crc, computed_crc;
+   size_t raw_hdr_size = 0, hdr_size_len, hdr_size;
+@@ -2114,15 +2116,26 @@ static int process_base_block(struct archive_read* a,
+   return ARCHIVE_EOF;
+   }
+ 
++  hdr_size = raw_hdr_size + hdr_size_len;
++
+   /* Sanity check, maximum header size for RAR5 is 2MB. */
+-  if(raw_hdr_size > (2 * 1024 * 1024)) {
++  if(hdr_size > (2 * 1024 * 1024)) {
+   archive_set_error(>archive, ARCHIVE_ERRNO_FILE_FORMAT,
+   "Base block header is too large");
+ 
+   return ARCHIVE_FATAL;
+   }
+ 
+-  hdr_size = raw_hdr_size + hdr_size_len;
++  /* Additional sanity checks to weed out invalid files. */
++  if(raw_hdr_size == 0 || hdr_size_len == 0 ||
++  hdr_size < SMALLEST_RAR5_BLOCK_SIZE)
++  {
++  archive_set_error(>archive, ARCHIVE_ERRNO_FILE_FORMAT,
++  "Too small block encountered (%ld bytes)",
++  raw_hdr_size);
++
++  return ARCHIVE_FATAL;
++  }
+ 
+   /* Read the whole header data into memory, maximum memory use here is
+* 2MB. */
+diff --git a/libarchive/test/test_read_format_rar5.c 
b/libarchive/test/test_read_format_rar5.c
+index bb94d4e..f91521e 100644
+--- a/libarchive/test/test_read_format_rar5.c
 b/libarchive/test/test_read_format_rar5.c
+@@ -1256,3 +1256,18 @@ 
DEFINE_TEST(test_read_format_rar5_different_winsize_on_merge)
+ 
+   EPILOGUE();
+ }
++
++DEFINE_TEST(test_read_format_rar5_block_size_is_too_small)
++{
++  char buf[4096];
++  

Re: [OE-core] [PATCH] libarchive: Fix CVE-2020-9308

[Wenlin Kang]

On 2/26/20 11:11 PM, Wenlin Kang wrote:


Please ignore it.


Fix CVE-2020-9308

Signed-off-by: Wenlin Kang 
---
  ...ct-files-that-declare-invalid-header.patch | 124 ++
  .../libarchive/libarchive_3.4.1.bb|   4 +-
  2 files changed, 127 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch

diff --git 
a/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
 
b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
new file mode 100644
index 00..c3e0af571e
--- /dev/null
+++ 
b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
@@ -0,0 +1,124 @@
+From 94821008d6eea81e315c5881cdf739202961040a Mon Sep 17 00:00:00 2001
+From: Grzegorz Antoniak 
+Date: Sun, 2 Feb 2020 08:04:41 +0100
+Subject: [PATCH] RAR5 reader: reject files that declare invalid header flags
+
+One of the fields in RAR5's base block structure is the size of the
+header. Some invalid files declare a 0 header size setting, which can
+confuse the unpacker. Minimum header size for RAR5 base blocks is 7
+bytes (4 bytes for CRC, and 3 bytes for the rest), so block size of 0
+bytes should be rejected at header parsing stage.
+
+The fix adds an error condition if header size of 0 bytes is detected.
+In this case, the unpacker will not attempt to unpack the file, as the
+header is corrupted.
+
+The commit also adds OSSFuzz #20459 sample to test further regressions
+in this area.
+
+Upstream-Status: 
Backport[https://github.com/libarchive/libarchive/commit/94821008d6eea81e315c5881cdf739202961040a]
+CVE-2020-9308
+
+Signed-off-by: Wenlin Kang 
+---
+ Makefile.am |  1 +
+ libarchive/archive_read_support_format_rar5.c   | 17 +++--
+ libarchive/test/test_read_format_rar5.c | 15 +++
+ ...test_read_format_rar5_block_size_is_too_small.rar.uu |  8 
+ 4 files changed, 39 insertions(+), 2 deletions(-)
+ create mode 100644 
libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu
+
+diff --git a/Makefile.am b/Makefile.am
+index 06c2644..c65e243 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -877,6 +877,7 @@ libarchive_test_EXTRA_DIST=\
+   libarchive/test/test_read_format_rar5_win32.rar.uu \
+   
libarchive/test/test_read_format_rar5_arm_filter_on_window_boundary.rar.uu \
+   libarchive/test/test_read_format_rar5_different_winsize_on_merge.rar.uu 
\
++  libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu \
+   libarchive/test/test_read_format_raw.bufr.uu \
+   libarchive/test/test_read_format_raw.data.gz.uu \
+   libarchive/test/test_read_format_raw.data.Z.uu \
+diff --git a/libarchive/archive_read_support_format_rar5.c 
b/libarchive/archive_read_support_format_rar5.c
+index ff1d6f8..f7c163e 100644
+--- a/libarchive/archive_read_support_format_rar5.c
 b/libarchive/archive_read_support_format_rar5.c
+@@ -2085,6 +2085,8 @@ static int scan_for_signature(struct archive_read* a);
+ static int process_base_block(struct archive_read* a,
+ struct archive_entry* entry)
+ {
++  const size_t SMALLEST_RAR5_BLOCK_SIZE = 3;
++
+   struct rar5* rar = get_context(a);
+   uint32_t hdr_crc, computed_crc;
+   size_t raw_hdr_size = 0, hdr_size_len, hdr_size;
+@@ -2114,15 +2116,26 @@ static int process_base_block(struct archive_read* a,
+   return ARCHIVE_EOF;
+   }
+
++  hdr_size = raw_hdr_size + hdr_size_len;
++
+   /* Sanity check, maximum header size for RAR5 is 2MB. */
+-  if(raw_hdr_size > (2 * 1024 * 1024)) {
++  if(hdr_size > (2 * 1024 * 1024)) {
+   archive_set_error(>archive, ARCHIVE_ERRNO_FILE_FORMAT,
+   "Base block header is too large");
+
+   return ARCHIVE_FATAL;
+   }
+
+-  hdr_size = raw_hdr_size + hdr_size_len;
++  /* Additional sanity checks to weed out invalid files. */
++  if(raw_hdr_size == 0 || hdr_size_len == 0 ||
++  hdr_size < SMALLEST_RAR5_BLOCK_SIZE)
++  {
++  archive_set_error(>archive, ARCHIVE_ERRNO_FILE_FORMAT,
++  "Too small block encountered (%ld bytes)",
++  raw_hdr_size);
++
++  return ARCHIVE_FATAL;
++  }
+
+   /* Read the whole header data into memory, maximum memory use here is
+* 2MB. */
+diff --git a/libarchive/test/test_read_format_rar5.c 
b/libarchive/test/test_read_format_rar5.c
+index bb94d4e..f91521e 100644
+--- a/libarchive/test/test_read_format_rar5.c
 b/libarchive/test/test_read_format_rar5.c
+@@ -1256,3 +1256,18 @@ 
DEFINE_TEST(test_read_format_rar5_different_winsize_on_merge)
+
+   EPILOGUE();
+ }
++
++DEFINE_TEST(test_read_format_rar5_block_size_is_too_small)
++{
++  

[OE-core] [oe-core][PATCH 1/1] python3: change two shebangs to python3

[Joe Slater]

cgi.py and rot_13.py have outdated shebangs.

Signed-off-by: Joe Slater 
---
 .../recipes-devtools/python/python3/shebang3.patch | 22 ++
 meta/recipes-devtools/python/python3_3.8.1.bb  |  2 ++
 2 files changed, 24 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3/shebang3.patch

diff --git a/meta/recipes-devtools/python/python3/shebang3.patch 
b/meta/recipes-devtools/python/python3/shebang3.patch
new file mode 100644
index 000..c4fde05
--- /dev/null
+++ b/meta/recipes-devtools/python/python3/shebang3.patch
@@ -0,0 +1,22 @@
+python3: change two shebangs to python3
+
+Upstream-Status: Inappropriate [distribution]
+
+Signed-off-by: Joe Slater 
+
+--- a/Lib/cgi.py
 b/Lib/cgi.py
+@@ -1,4 +1,4 @@
+-#! /usr/bin/env python
++#! /usr/bin/env python3
+ 
+ """Support module for CGI (Common Gateway Interface) scripts.
+ 
+--- a/Lib/encodings/rot_13.py
 b/Lib/encodings/rot_13.py
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env python
++#!/usr/bin/env python3
+ """ Python Character Mapping Codec for ROT13.
+ 
+ This codec de/encodes from str to str.
diff --git a/meta/recipes-devtools/python/python3_3.8.1.bb 
b/meta/recipes-devtools/python/python3_3.8.1.bb
index 7796852..c1983d8 100644
--- a/meta/recipes-devtools/python/python3_3.8.1.bb
+++ b/meta/recipes-devtools/python/python3_3.8.1.bb
@@ -32,7 +32,9 @@ SRC_URI = 
"http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
file://0001-configure.ac-fix-LIBPL.patch \
file://0001-python3-Do-not-hardcode-lib-for-distutils.patch \

file://0020-configure.ac-setup.py-do-not-add-a-curses-include-pa.patch \
+   file://shebang3.patch \
"
+  
 
 SRC_URI_append_class-native = " \

file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
-- 
2.7.4

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

[OE-core] [PATCH 4/4] maintainers.inc: add self for atk, at-spi2-core, at-spi2-atk

[Tim Orling]

For GUI automation purposes, strong motivation for accessibility (a11y)
via python3-dogtail and python3-pyatspi2, so taking over from Anuj.

Signed-off-by: Tim Orling 
---
 meta/conf/distro/include/maintainers.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 8f612ace39..10095ffe76 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -49,9 +49,9 @@ RECIPE_MAINTAINER_pn-asciidoc = "Yi Zhao 
"
 RECIPE_MAINTAINER_pn-aspell = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-assimp = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-at = "Chen Qi "
-RECIPE_MAINTAINER_pn-at-spi2-atk = "Anuj Mittal "
-RECIPE_MAINTAINER_pn-at-spi2-core = "Anuj Mittal "
-RECIPE_MAINTAINER_pn-atk = "Anuj Mittal "
+RECIPE_MAINTAINER_pn-at-spi2-atk = "Tim Orling 
"
+RECIPE_MAINTAINER_pn-at-spi2-core = "Tim Orling 
"
+RECIPE_MAINTAINER_pn-atk = "Tim Orling "
 RECIPE_MAINTAINER_pn-attr = "Chen Qi "
 RECIPE_MAINTAINER_pn-autoconf = "Robert Yang "
 RECIPE_MAINTAINER_pn-autoconf-archive = "Robert Yang 
"
-- 
2.24.0

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

[OE-core] [PATCH 3/4] at-spi2-atk: upgrade 2.32.0 -> 2.34.1

[Tim Orling]

Release notes:
https://gitlab.gnome.org/GNOME/at-spi2-atk/-/raw/043b793de2161a0548835424f4d087ac90d1172d/NEWS

License-Update: Changed to LGPL-2.1+

Signed-off-by: Tim Orling 
---
 .../atk/{at-spi2-atk_2.32.0.bb => at-spi2-atk_2.34.1.bb}  | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-support/atk/{at-spi2-atk_2.32.0.bb => 
at-spi2-atk_2.34.1.bb} (66%)

diff --git a/meta/recipes-support/atk/at-spi2-atk_2.32.0.bb 
b/meta/recipes-support/atk/at-spi2-atk_2.34.1.bb
similarity index 66%
rename from meta/recipes-support/atk/at-spi2-atk_2.32.0.bb
rename to meta/recipes-support/atk/at-spi2-atk_2.34.1.bb
index b717a9c7f7..b09cb6a392 100644
--- a/meta/recipes-support/atk/at-spi2-atk_2.32.0.bb
+++ b/meta/recipes-support/atk/at-spi2-atk_2.34.1.bb
@@ -1,10 +1,10 @@
 SUMMARY = "AT-SPI 2 Toolkit Bridge"
 HOMEPAGE = "https://wiki.linuxfoundation.org/accessibility/d-bus;
-LICENSE = "LGPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=e9f288ba982d60518f375b5898283886"
+LICENSE = "LGPL-2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 
-SRC_URI[archive.md5sum] = "6a4b27bace3b9352721ed462b95f6291"
-SRC_URI[archive.sha256sum] = 
"0b51e6d339fa2bcca3a3e3159ccea574c67b107f1ac8b00047fa60e34ce7a45c"
+SRC_URI[archive.md5sum] = "e0f99641c5a403041c4214be04722e15"
+SRC_URI[archive.sha256sum] = 
"776df930748fde71c128be6c366a987b98b6ee66d508ed9c8db2355bf4b9cc16"
 
 DEPENDS = "dbus glib-2.0 glib-2.0-native atk at-spi2-core libxml2"
 
-- 
2.24.0

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

[OE-core] [PATCH 2/4] at-spi2-core: upgrade 2.32.1 -> 2.34.0

[Tim Orling]

Release notes:
https://gitlab.gnome.org/GNOME/at-spi2-core/-/raw/6da122f1e8d6b02dda0f368610ab72fc3d1720cf/NEWS

License-Update: Changed to LPGL-2.1+

Signed-off-by: Tim Orling 
---
 .../{at-spi2-core_2.32.1.bb => at-spi2-core_2.34.0.bb}| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-support/atk/{at-spi2-core_2.32.1.bb => 
at-spi2-core_2.34.0.bb} (83%)

diff --git a/meta/recipes-support/atk/at-spi2-core_2.32.1.bb 
b/meta/recipes-support/atk/at-spi2-core_2.34.0.bb
similarity index 83%
rename from meta/recipes-support/atk/at-spi2-core_2.32.1.bb
rename to meta/recipes-support/atk/at-spi2-core_2.34.0.bb
index 18b5de2d58..84e05e77fc 100644
--- a/meta/recipes-support/atk/at-spi2-core_2.32.1.bb
+++ b/meta/recipes-support/atk/at-spi2-core_2.34.0.bb
@@ -1,15 +1,15 @@
 SUMMARY = "Assistive Technology Service Provider Interface (dbus core)"
 HOMEPAGE = "https://wiki.linuxfoundation.org/accessibility/d-bus;
-LICENSE = "LGPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=e9f288ba982d60518f375b5898283886"
+LICENSE = "LGPL-2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 
 MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 
 SRC_URI = "${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
file://0001-Fix-source-reproducibility.patch"
 
-SRC_URI[md5sum] = "998fd9d858f8fa22c4c8c15567bf6254"
-SRC_URI[sha256sum] = 
"3c2aa937ebfaca2c86569bce9b16a34fbe20d69ef0c58846313b1c42f53b0d53"
+SRC_URI[md5sum] = "53c21565507105fb68031cd9c21a559b"
+SRC_URI[sha256sum] = 
"d629cdbd674e539f8912028512af583990938c7b49e25184c126b00121ef11c6"
 
 X11DEPENDS = "virtual/libx11 libxi libxtst"
 
-- 
2.24.0

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

[OE-core] [PATCH 1/4] atk: upgrade 2.32.0 -> 2.34.1

[Tim Orling]

From: Tim Orling 

Patch no longer applies (nor is needed) upstream.

Release notes:
https://gitlab.gnome.org/GNOME/atk/-/raw/633bde11f93ee971ba8902c6fadbc29c121f71af/NEWS

Signed-off-by: Tim Orling 
---
 ...able-introspection-for-cross-compile.patch | 29 ---
 .../atk/{atk_2.32.0.bb => atk_2.34.1.bb}  |  5 ++--
 2 files changed, 2 insertions(+), 32 deletions(-)
 delete mode 100644 
meta/recipes-support/atk/atk/0001-meson.build-enable-introspection-for-cross-compile.patch
 rename meta/recipes-support/atk/{atk_2.32.0.bb => atk_2.34.1.bb} (73%)

diff --git 
a/meta/recipes-support/atk/atk/0001-meson.build-enable-introspection-for-cross-compile.patch
 
b/meta/recipes-support/atk/atk/0001-meson.build-enable-introspection-for-cross-compile.patch
deleted file mode 100644
index d1b08bc04b..00
--- 
a/meta/recipes-support/atk/atk/0001-meson.build-enable-introspection-for-cross-compile.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From 44d46baa5e1519c6c3df7e4d34fb333e247b5bc8 Mon Sep 17 00:00:00 2001
-From: Anuj Mittal 
-Date: Fri, 6 Apr 2018 12:04:00 +0800
-Subject: [PATCH] meson.build: enable introspection for cross-compile
-
-It works fine in OE-core and doesn't need to be disabled. Let the user decide
-if it should be disabled or not.
-
-Upstream-Status: Pending
-
-Signed-off-by: Anuj Mittal 
-

- atk/meson.build | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/atk/meson.build b/atk/meson.build
-index 0ad67e5..1d2a49c 100644
 a/atk/meson.build
-+++ b/atk/meson.build
-@@ -137,7 +137,7 @@ libatk_dep = declare_dependency(link_with: libatk,
- dependencies: glib_dep,
- sources: atk_enum_h)
- 
--if not meson.is_cross_build() and get_option('introspection')
-+if get_option('introspection')
-   gnome.generate_gir(libatk,
-  sources: atk_sources + atk_headers + [ atk_enum_h ] + [ 
atk_version_h ],
-  namespace: 'Atk',
diff --git a/meta/recipes-support/atk/atk_2.32.0.bb 
b/meta/recipes-support/atk/atk_2.34.1.bb
similarity index 73%
rename from meta/recipes-support/atk/atk_2.32.0.bb
rename to meta/recipes-support/atk/atk_2.34.1.bb
index 67223729e9..277397c694 100644
--- a/meta/recipes-support/atk/atk_2.32.0.bb
+++ b/meta/recipes-support/atk/atk_2.34.1.bb
@@ -14,9 +14,8 @@ DEPENDS = "gettext-native glib-2.0"
 GNOMEBASEBUILDCLASS = "meson"
 inherit gnomebase gtk-doc gettext upstream-version-is-even 
gobject-introspection
 
-SRC_URI += " 
file://0001-meson.build-enable-introspection-for-cross-compile.patch"
-SRC_URI[archive.md5sum] = "c10b0b2af3c199e42caa6275b845c49d"
-SRC_URI[archive.sha256sum] = 
"cb41feda7fe4ef0daa024471438ea0219592baf7c291347e5a858bb64e4091cc"
+SRC_URI[archive.md5sum] = "f60bbaf8bdd08b93d98736b54b2fc8e9"
+SRC_URI[archive.sha256sum] = 
"d4f0e3b3d21265fcf2bc371e117da51c42ede1a71f6db1c834e6976bb20997cb"
 
 BBCLASSEXTEND = "native nativesdk"
 
-- 
2.24.0

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

[OE-core] [PATCH 0/4] Upgrade accessibility (a11y) atk packages

[Tim Orling]

This series updates to the latest stable (even) release of the
accessibility (a11y) toolkit and related. These are one of the
ways we can automated GUI testing in gtk and Qt applications.

One notable improvement in this release is that accessibility
is launched automatically in a GUI environment.

Tested on core-image-sato-sdk for qemux86_64 and qemux86-musl.

[PATCH 1/4] atk: upgrade 2.32.0 -> 2.34.1
[PATCH 2/4] at-spi2-core: upgrade 2.32.1 -> 2.34.0
[PATCH 3/4] at-spi2-atk: upgrade 2.32.0 -> 2.34.1
[PATCH 4/4] maintainers.inc: add self for atk, at-spi2-core,

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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On 2/26/20 12:21 PM, Böszörményi Zoltán wrote:

2020. 02. 26. 20:44 keltezéssel, Khem Raj írta:



On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:

2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:



On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán 
 wrote:


2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán 
wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  
wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to 
core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that 
instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.


don't assume things


Understood.

http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html 






I am trying to make us thing if -dev package can be used somehow to
avoid this
or have we exhausted all possibilities.


Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?


it is not a problem, however, it is a work to keep such setup going 
and

also it has to be considered always in dependencies etc.


Surely it's not reserved for libgcc-initial and friends.



they are different usecases, libgcc-initial is a veneer/trampoline 
used

to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.


It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
    circular dependency is avoided. mesa needs a crippled libva
(pkgconfig + headers)
    to build its VAAPI state tracker and the VAAPI drivers


I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE


Fedora also uses the full libva.

However, the chicken-and-egg circular dependency is broken by history
for these distros.

Koji and Mock build one package at a time with all their dependencies
already available from the staging package repository and the results
will be eventually uploaded to the same repository.

Bitbake doesn't have have this loophole to download pre-built 
dependencies.


Also, somewhere on 01.org or in the libva sources the same solution
I presented in this patchset is suggested:

1. build libva with --disable-glx (it is needed when Mesa SDK is 
present)

    but it's not needed by not depending on mesa in libva-initial
2. build mesa with libva build in (1) as it only needs the pkgconfig 
files

    and the headers
3. build libva with --enable-glx. It's autodetected, set to on with
    depending on mesa in the full libva recipe.


looking at the nature of the problem, it might be the way to unbreak 
the catch-22, does anything else needs this bootstrap header package ?


Besides DEPENDS="libdrm", no.

do we need to ensure that content of libva-dev and the bootstrap 
packages do not overlap.


I don't think so.
Apparently, the mesa-dev package built from this patchset
doesn't depend on libva-initial-dev and this latter package
doesn't get included into an image either. I guess the
sstate.bbclass internals deal with this properly.



OK, I guess, we should give it a test.







Obviusly the same libva recipe can't be used to build mesa that 
depends on mesa.








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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 20:44 keltezéssel, Khem Raj írta:



On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:

2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:



On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán 
wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.


don't assume things


Understood.


http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html




I am trying to make us thing if -dev package can be used somehow to
avoid this
or have we exhausted all possibilities.


Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?


it is not a problem, however, it is a work to keep such setup going and
also it has to be considered always in dependencies etc.


Surely it's not reserved for libgcc-initial and friends.



they are different usecases, libgcc-initial is a veneer/trampoline used
to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.


It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
    circular dependency is avoided. mesa needs a crippled libva
(pkgconfig + headers)
    to build its VAAPI state tracker and the VAAPI drivers


I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE


Fedora also uses the full libva.

However, the chicken-and-egg circular dependency is broken by history
for these distros.

Koji and Mock build one package at a time with all their dependencies
already available from the staging package repository and the results
will be eventually uploaded to the same repository.

Bitbake doesn't have have this loophole to download pre-built dependencies.


Also, somewhere on 01.org or in the libva sources the same solution
I presented in this patchset is suggested:

1. build libva with --disable-glx (it is needed when Mesa SDK is present)
    but it's not needed by not depending on mesa in libva-initial
2. build mesa with libva build in (1) as it only needs the pkgconfig files
    and the headers
3. build libva with --enable-glx. It's autodetected, set to on with
    depending on mesa in the full libva recipe.


looking at the nature of the problem, it might be the way to unbreak the catch-22, does 
anything else needs this bootstrap header package ?


Besides DEPENDS="libdrm", no.


do we need to ensure that content of libva-dev and the bootstrap packages do 
not overlap.


I don't think so.
Apparently, the mesa-dev package built from this patchset
doesn't depend on libva-initial-dev and this latter package
doesn't get included into an image either. I guess the
sstate.bbclass internals deal with this properly.






Obviusly the same libva recipe can't be used to build mesa that depends on mesa.






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

Re: [OE-core] [PATCH] utils.bbclass: Avoid recursive symlink in oe_soinstall

[Andre McCurdy]

On Tue, Feb 25, 2020 at 6:17 AM Yevhenii Shchehlov
 wrote:
>
> This patch fixes an issue when oe_soinstall function creates
> non-functional recursive symlinks in case library soname is equal
> to library real (file) name.
>
> Signed-off-by: Yevhenii Shchehlov 
> ---
>  meta/classes/utils.bbclass | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
> index cd3d05709e..dea824f54f 100644
> --- a/meta/classes/utils.bbclass
> +++ b/meta/classes/utils.bbclass
> @@ -25,7 +25,7 @@ oe_soinstall() {
> libname=`basename $1`
> case "$libname" in
> *.so)
> -   bbfatal "oe_soinstall: Shared library must haved versioned 
> filename (e.g. libfoo.so.1.2.3)"
> +   bbfatal "oe_soinstall: Shared library must haved versioned 
> filename (e.g. libfoo.so.1.2.3 instead of libfoo.so)"

This patch look OK but it might be nice to also clean up this error
message (and the Example comment a few lines above it) to drop the 3
levels of version number. There should only be 2, ie the fully
versioned filename would be libfoo.so.1.2 instead of libfoo.so.1.2.3

> ;;
> esac
> install -m 755 $1 $2/$libname
> @@ -33,8 +33,12 @@ oe_soinstall() {
> if [ -z $sonamelink ]; then
> bbfatal "oe_soinstall: $libname is missing ELF tag 'SONAME'."
> fi
> +   if [ "$sonamelink" == "$libname" ]; then
> +   bbwarn "oe_soinstall: $libname soname is equal to real (file) 
> name. Minor version should be added to a real name (e.g. libfoo.so.1.2 
> instead of libfoo.so.1)"

It might be clearer to say:

"oe_soinstall: $libname soname is equal to fully versioned real (file)
name. The soname should include the major version only (e.g.
libfoo.so.1 instead of libfoo.so.1.2)"

> +   else
> +   ln -sf $libname $2/$sonamelink
> +   fi
> solink=`echo $libname | sed -e 's/\.so\..*/.so/'`
> -   ln -sf $libname $2/$sonamelink
> ln -sf $libname $2/$solink
>  }
>
> --
> 2.25.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:

2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:



On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán  
wrote:


2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán 
wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  
wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to 
core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.


don't assume things


Understood.

http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html 






I am trying to make us thing if -dev package can be used somehow to
avoid this
or have we exhausted all possibilities.


Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?


it is not a problem, however, it is a work to keep such setup going and
also it has to be considered always in dependencies etc.


Surely it's not reserved for libgcc-initial and friends.



they are different usecases, libgcc-initial is a veneer/trampoline used
to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.


It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
    circular dependency is avoided. mesa needs a crippled libva
(pkgconfig + headers)
    to build its VAAPI state tracker and the VAAPI drivers


I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE


Fedora also uses the full libva.

However, the chicken-and-egg circular dependency is broken by history
for these distros.

Koji and Mock build one package at a time with all their dependencies
already available from the staging package repository and the results
will be eventually uploaded to the same repository.

Bitbake doesn't have have this loophole to download pre-built 
dependencies.


Also, somewhere on 01.org or in the libva sources the same solution
I presented in this patchset is suggested:

1. build libva with --disable-glx (it is needed when Mesa SDK is present)
    but it's not needed by not depending on mesa in libva-initial
2. build mesa with libva build in (1) as it only needs the pkgconfig files
    and the headers
3. build libva with --enable-glx. It's autodetected, set to on with
    depending on mesa in the full libva recipe.


looking at the nature of the problem, it might be the way to unbreak the 
catch-22, does anything else needs this bootstrap header package ?
do we need to ensure that content of libva-dev and the bootstrap 
packages do not overlap.




Obviusly the same libva recipe can't be used to build mesa that depends 
on mesa.





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

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

[Jonathan Rajotte-Julien]

Hi,

We released patch level release for our stable branch [1].

These release includes the fix proposed here.

Please validate that it fixes your issues.

[1] 
https://lists.linuxfoundation.org/pipermail/diamon-discuss/2020-February/000196.html

Cheers

- Original Message -
> From: "Li Zhou" 
> To: "Jonathan Rajotte-Julien" 
> Cc: "openembedded-core" 
> Sent: Tuesday, February 25, 2020 3:41:58 AM
> Subject: Re: [OE-core] [PATCH] lttng-modules: Check the pid_ns before using 
> it because it may be NULL

> On 2/20/20 10:47 PM, Jonathan Rajotte-Julien wrote:
>> Hi,
>>
>> Can we get more info on the kernel version and config?
>>
>> Did you submit this on our mailing list?(lttng-dev). If not I would highly
>> recommend that you do so in the future so we can eliminate *custom* patches 
>> and
>> get to the bottom of the issue at hand so that the whole community benefit 
>> from
>> it.
> 
> 
> Hi, Jonathan:
> 
>     Thank you for you help and suggestion on this. This issue is
> seen on linux 4.18 + lttng-modules 2.10.
> 
> 
>>
>> Cheers
>>
>> - Li Zhou  wrote:
>>> 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
>>> +++
>>> 

[OE-core] [PATCH] libgpg-error: upgrade 1.36 -> 1.37

[Trevor Gamblin]

https://dev.gnupg.org/T4459 was fixed in 1.37, so the backported
patch is removed.

Signed-off-by: Trevor Gamblin 
---
 .../libgpg-error-1.36-gawk5-support.patch | 144 --
 ...gpg-error_1.36.bb => libgpg-error_1.37.bb} |   5 +-
 2 files changed, 2 insertions(+), 147 deletions(-)
 delete mode 100644 
meta/recipes-support/libgpg-error/libgpg-error/libgpg-error-1.36-gawk5-support.patch
 rename meta/recipes-support/libgpg-error/{libgpg-error_1.36.bb => 
libgpg-error_1.37.bb} (92%)

diff --git 
a/meta/recipes-support/libgpg-error/libgpg-error/libgpg-error-1.36-gawk5-support.patch
 
b/meta/recipes-support/libgpg-error/libgpg-error/libgpg-error-1.36-gawk5-support.patch
deleted file mode 100644
index b936d1143b..00
--- 
a/meta/recipes-support/libgpg-error/libgpg-error/libgpg-error-1.36-gawk5-support.patch
+++ /dev/null
@@ -1,144 +0,0 @@
-Upstream-Status: Backport [https://dev.gnupg.org/T4459]
-Signed-off-by: Khem Raj 
-
-From 7865041c77f4f7005282f10f9bb19072fbdf Mon Sep 17 00:00:00 2001
-From: NIIBE Yutaka 
-Date: Mon, 15 Apr 2019 15:10:44 +0900
-Subject: [PATCH] awk: Prepare for Gawk 5.0.
-
-* src/Makefile.am: Use pkg_namespace (instead of namespace).
-* src/mkerrnos.awk: Likewise.
-* lang/cl/mkerrcodes.awk: Don't escape # in regexp.
-* src/mkerrcodes.awk, src/mkerrcodes1.awk, src/mkerrcodes2.awk: Ditto.
-
---
-
-In Gawk 5.0, regexp routines are replaced by Gnulib implementation,
-which only allows escaping specific characters.
-
-GnuPG-bug-id: 4459
-Reported-by: Marius Schamschula
-Signed-off-by: NIIBE Yutaka 

- lang/cl/mkerrcodes.awk |  2 +-
- src/Makefile.am|  2 +-
- src/mkerrcodes.awk |  2 +-
- src/mkerrcodes1.awk|  2 +-
- src/mkerrcodes2.awk|  2 +-
- src/mkerrnos.awk   |  2 +-
- src/mkstrtable.awk | 10 +-
- 7 files changed, 11 insertions(+), 11 deletions(-)
-
 a/lang/cl/mkerrcodes.awk
-+++ b/lang/cl/mkerrcodes.awk
-@@ -122,7 +122,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/Makefile.am
-+++ b/src/Makefile.am
-@@ -293,7 +293,7 @@ code-from-errno.h: mkerrcodes$(EXEEXT_FO
- 
- errnos-sym.h: Makefile mkstrtable.awk errnos.in
-   $(AWK) -f $(srcdir)/mkstrtable.awk -v textidx=2 -v nogettext=1 \
--  -v prefix=GPG_ERR_ -v namespace=errnos_ \
-+  -v prefix=GPG_ERR_ -v pkg_namespace=errnos_ \
-   $(srcdir)/errnos.in >$@
- 
- 
 a/src/mkerrcodes.awk
-+++ b/src/mkerrcodes.awk
-@@ -85,7 +85,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/mkerrcodes1.awk
-+++ b/src/mkerrcodes1.awk
-@@ -81,7 +81,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/mkerrcodes2.awk
-+++ b/src/mkerrcodes2.awk
-@@ -91,7 +91,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/mkerrnos.awk
-+++ b/src/mkerrnos.awk
-@@ -83,7 +83,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/mkstrtable.awk
-+++ b/src/mkstrtable.awk
-@@ -77,7 +77,7 @@
- #
- # The variable prefix can be used to prepend a string to each message.
- #
--# The variable namespace can be used to prepend a string to each
-+# The variable pkg_namespace can be used to prepend a string to each
- # variable and macro name.
- 
- BEGIN {
-@@ -102,7 +102,7 @@ header {
-   print "/* The purpose of this complex string table is to produce";
-   print "   optimal code with a minimum of relocations.  */";
-   print "";
--  print "static const char " namespace "msgstr[] = ";
-+  print "static const char " pkg_namespace "msgstr[] = ";
-   header = 0;
- }
-   else
-@@ -110,7 +110,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
-@@ -150,7 +150,7 @@ END {
-   else
- print "  gettext_noop (\"" last_msgstr "\");";
-   print "";
--  print "static const int " namespace "msgidx[] =";
-+  print "static const int " pkg_namespace "msgidx[] =";
-   print "  {";
-   for (i = 0; i < coded_msgs; i++)
- print "" pos[i] ",";
-@@ -158,7 +158,7 @@ END {
-   print "  };";
-   print "";
-   print "static GPG_ERR_INLINE int";
--  print namespace "msgidxof (int code)";
-+  print pkg_namespace "msgidxof (int code)";
-   print "{";
-   print "  return (0 ? 0";
- 
diff --git a/meta/recipes-support/libgpg-error/libgpg-error_1.36.bb 
b/meta/recipes-support/libgpg-error/libgpg-error_1.37.bb
similarity index 92%
rename from 

Re: [OE-core] [PATCH 1/2 v3] coreutils: add ptest

[Alexander Kanavin]

valgrind, gdb and strace are already pulled into core-image-sato-sdk-ptest
(the one that runs the slow ptests on the AB), so there is no harm in
adding them here as well.

Alex

On Wed, 26 Feb 2020 at 19:08, Trevor Gamblin 
wrote:

> coreutils has a large number of tests, including some added by the
> Makefile flags RUN_EXPENSIVE_TESTS and RUN_VERY_EXPENSIVE_TESTS that
> significantly increase runtime (and which have been disabled). Note
> that the coreutils ptest directory is given blanket permissions at
> runtime with chmod -R 777, to ensure that the user created for the
> tests will be able to run the test scripts and create the necessary
> files in the process without being impeded by permissions issues.
>
> There is still room to improve the results of this ptest without
> the aforementioned additions. Of the tests marked SKIP, there are
> 30 tests that are currently counted as SKIP because they require
> sudo permissions, and another 21 that require membership in
> multiple user groups. It is important to know that coreutils has
> tests for both root and non-root users. Testing showed that 42
> tests are skipped when running as root versus 30 when running as a
> non-root user, so the decision was made to run the suite as the
> latter. Additionally, gdb, valgrind, and strace could be included
> in the RDEPENDS list to increase pass rate, but their total
> contribution is 13 tests, so they were omitted to reduce image size.
>
> Finally, note that at least one ptest (misc/head-write-error.sh) is
> prone to ERROR on builds of core-image-minimal if extra space is
> not provided with IMAGE_ROOTFS_EXTRA_SPACE.
>
> Signed-off-by: Trevor Gamblin 
> ---
>  .../coreutils/coreutils/run-ptest | 17 +
>  meta/recipes-core/coreutils/coreutils_8.31.bb | 37 +++
>  2 files changed, 54 insertions(+)
>  create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest
>
> diff --git a/meta/recipes-core/coreutils/coreutils/run-ptest
> b/meta/recipes-core/coreutils/coreutils/run-ptest
> new file mode 100755
> index 00..6d4a7b365d
> --- /dev/null
> +++ b/meta/recipes-core/coreutils/coreutils/run-ptest
> @@ -0,0 +1,17 @@
> +#!/bin/sh
> +
> +# remove any stale lock files so that the calls to groupadd/useradd don't
> stop
> +# the ptest if re-using the same image
> +rm -rf /etc/passwd.lock /etc/group.lock /etc/gshadow.lock
> +
> +COREUTILSLIB=@libdir@/coreutils
> +LOG="${COREUTILSLIB}/ptest/coreutils_ptest_$(date +%Y%m%d-%H%M%S).log"
> +USERNAME="tester"
> +groupadd ugroup1
> +groupadd ugroup2
> +useradd -G ugroup1,ugroup2 $USERNAME || echo "user $USERNAME already
> exists"
> +
> +su tester -c "cd ${COREUTILSLIB}/ptest && make check-TESTS top_srcdir=.
> srcdir=." 2>&1 | tee -a ${LOG}
> +userdel $USERNAME
> +groupdel ugroup1
> +groupdel ugroup2
> diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb
> b/meta/recipes-core/coreutils/coreutils_8.31.bb
> index 57b2c1bdba..8bec4e0f3c 100644
> --- a/meta/recipes-core/coreutils/coreutils_8.31.bb
> +++ b/meta/recipes-core/coreutils/coreutils_8.31.bb
> @@ -18,6 +18,7 @@ SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.xz \
>
> file://0001-uname-report-processor-and-hardware-correctly.patch \
> file://disable-ls-output-quoting.patch \
> file://0001-local.mk-fix-cross-compiling-problem.patch \
> +   file://run-ptest \
>"
>
>  SRC_URI_append_libc-musl = "file://strtod_fix_clash_with_strtold.patch"
> @@ -143,3 +144,39 @@ python __anonymous() {
>  }
>
>  BBCLASSEXTEND = "native nativesdk"
> +
> +inherit ptest
> +
> +RDEPENDS_${PN}-ptest += "bash findutils gawk liberror-perl
> libmodule-build-perl make perl perl-module-file-stat python3-core sed
> shadow"
> +
> +do_install_ptest () {
> +install -d ${D}${PTEST_PATH}/tests
> +cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests
> +sed -i 's/ginstall/install/g'  `grep -R ginstall
> ${D}${PTEST_PATH}/tests | awk -F: '{print $1}' | uniq`
> +install -d ${D}${PTEST_PATH}/build-aux
> +install ${S}/build-aux/test-driver ${D}${PTEST_PATH}/build-aux/
> +cp ${B}/Makefile ${D}${PTEST_PATH}/
> +cp ${S}/init.cfg ${D}${PTEST_PATH}/
> +cp -r ${B}/src ${D}${PTEST_PATH}/
> +cp -r ${S}/src/*.c ${D}${PTEST_PATH}/src
> +sed -i '/^VPATH/s/= .*$/= ./g' ${D}${PTEST_PATH}/Makefile
> +sed -i '/^PROGRAMS/s/^/#/g' ${D}${PTEST_PATH}/Makefile
> +sed -i '/^Makefile: /s/^.*$/Makefile:/g' ${D}${PTEST_PATH}/Makefile
> +sed -i '/^abs_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile
> +sed -i '/^abs_top_builddir/s/= .*$/= \$\{PWD\}/g'
> ${D}${PTEST_PATH}/Makefile
> +sed -i '/^abs_top_srcdir/s/= .*$/= \$\{PWD\}/g'
> ${D}${PTEST_PATH}/Makefile
> +sed -i '/^built_programs/s/ginstall/install/g'
> ${D}${PTEST_PATH}/Makefile
> +chmod -R 777 ${D}${PTEST_PATH}
> +
> +# Disable subcase stty-pairs.sh, it will cause test framework hang
> +sed -i '/stty-pairs.sh/d' ${D}${PTEST_PATH}/Makefile
> +
> +# Tweak test d_type-check 

[OE-core] [PATCH 2/2 v3] ptest-packagelists.inc: add coreutils to SLOW list

[Trevor Gamblin]

Signed-off-by: Trevor Gamblin 
---
 meta/conf/distro/include/ptest-packagelists.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
b/meta/conf/distro/include/ptest-packagelists.inc
index 4afac58e3a..54ace39d53 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -65,6 +65,7 @@ PTESTS_FAST = "\
 PTESTS_SLOW = "\
 babeltrace-ptest \
 busybox-ptest \
+coreutils-ptest \
 dbus-test-ptest \
 e2fsprogs-ptest \
 glib-2.0-ptest \
-- 
2.24.1

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

[OE-core] [PATCH 1/2 v3] coreutils: add ptest

[Trevor Gamblin]

coreutils has a large number of tests, including some added by the
Makefile flags RUN_EXPENSIVE_TESTS and RUN_VERY_EXPENSIVE_TESTS that
significantly increase runtime (and which have been disabled). Note
that the coreutils ptest directory is given blanket permissions at
runtime with chmod -R 777, to ensure that the user created for the
tests will be able to run the test scripts and create the necessary
files in the process without being impeded by permissions issues.

There is still room to improve the results of this ptest without
the aforementioned additions. Of the tests marked SKIP, there are
30 tests that are currently counted as SKIP because they require
sudo permissions, and another 21 that require membership in
multiple user groups. It is important to know that coreutils has
tests for both root and non-root users. Testing showed that 42
tests are skipped when running as root versus 30 when running as a
non-root user, so the decision was made to run the suite as the
latter. Additionally, gdb, valgrind, and strace could be included
in the RDEPENDS list to increase pass rate, but their total
contribution is 13 tests, so they were omitted to reduce image size.

Finally, note that at least one ptest (misc/head-write-error.sh) is
prone to ERROR on builds of core-image-minimal if extra space is
not provided with IMAGE_ROOTFS_EXTRA_SPACE.

Signed-off-by: Trevor Gamblin 
---
 .../coreutils/coreutils/run-ptest | 17 +
 meta/recipes-core/coreutils/coreutils_8.31.bb | 37 +++
 2 files changed, 54 insertions(+)
 create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest

diff --git a/meta/recipes-core/coreutils/coreutils/run-ptest 
b/meta/recipes-core/coreutils/coreutils/run-ptest
new file mode 100755
index 00..6d4a7b365d
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils/run-ptest
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+# remove any stale lock files so that the calls to groupadd/useradd don't stop
+# the ptest if re-using the same image
+rm -rf /etc/passwd.lock /etc/group.lock /etc/gshadow.lock
+
+COREUTILSLIB=@libdir@/coreutils
+LOG="${COREUTILSLIB}/ptest/coreutils_ptest_$(date +%Y%m%d-%H%M%S).log"
+USERNAME="tester"
+groupadd ugroup1
+groupadd ugroup2
+useradd -G ugroup1,ugroup2 $USERNAME || echo "user $USERNAME already exists"
+
+su tester -c "cd ${COREUTILSLIB}/ptest && make check-TESTS top_srcdir=. 
srcdir=." 2>&1 | tee -a ${LOG}
+userdel $USERNAME 
+groupdel ugroup1
+groupdel ugroup2
diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb 
b/meta/recipes-core/coreutils/coreutils_8.31.bb
index 57b2c1bdba..8bec4e0f3c 100644
--- a/meta/recipes-core/coreutils/coreutils_8.31.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.31.bb
@@ -18,6 +18,7 @@ SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.xz \
file://0001-uname-report-processor-and-hardware-correctly.patch \
file://disable-ls-output-quoting.patch \
file://0001-local.mk-fix-cross-compiling-problem.patch \
+   file://run-ptest \
   "
 
 SRC_URI_append_libc-musl = "file://strtod_fix_clash_with_strtold.patch"
@@ -143,3 +144,39 @@ python __anonymous() {
 }
 
 BBCLASSEXTEND = "native nativesdk"
+
+inherit ptest
+
+RDEPENDS_${PN}-ptest += "bash findutils gawk liberror-perl 
libmodule-build-perl make perl perl-module-file-stat python3-core sed shadow"
+
+do_install_ptest () {
+install -d ${D}${PTEST_PATH}/tests
+cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests
+sed -i 's/ginstall/install/g'  `grep -R ginstall ${D}${PTEST_PATH}/tests | 
awk -F: '{print $1}' | uniq`
+install -d ${D}${PTEST_PATH}/build-aux
+install ${S}/build-aux/test-driver ${D}${PTEST_PATH}/build-aux/
+cp ${B}/Makefile ${D}${PTEST_PATH}/
+cp ${S}/init.cfg ${D}${PTEST_PATH}/
+cp -r ${B}/src ${D}${PTEST_PATH}/
+cp -r ${S}/src/*.c ${D}${PTEST_PATH}/src
+sed -i '/^VPATH/s/= .*$/= ./g' ${D}${PTEST_PATH}/Makefile
+sed -i '/^PROGRAMS/s/^/#/g' ${D}${PTEST_PATH}/Makefile
+sed -i '/^Makefile: /s/^.*$/Makefile:/g' ${D}${PTEST_PATH}/Makefile
+sed -i '/^abs_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile
+sed -i '/^abs_top_builddir/s/= .*$/= \$\{PWD\}/g' 
${D}${PTEST_PATH}/Makefile
+sed -i '/^abs_top_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile
+sed -i '/^built_programs/s/ginstall/install/g' ${D}${PTEST_PATH}/Makefile
+chmod -R 777 ${D}${PTEST_PATH}
+
+# Disable subcase stty-pairs.sh, it will cause test framework hang
+sed -i '/stty-pairs.sh/d' ${D}${PTEST_PATH}/Makefile
+
+# Tweak test d_type-check to use python3 instead of python
+sed -i "1s@.*@#!/usr/bin/python3@" 
${WORKDIR}/image/usr/lib/coreutils/ptest/tests/d_type-check
+install ${B}/src/getlimits ${D}/${bindir}
+
+# handle multilib
+sed -i s:@libdir@:${libdir}:g ${D}${PTEST_PATH}/run-ptest
+}
+
+FILES_${PN}-ptest += "${bindir}/getlimits"
-- 
2.24.1

-- 
___
Openembedded-core mailing list

[OE-core] [PATCH 0/2 v3] Add ptest support for coreutils

[Trevor Gamblin]

Sample test results:

core-image-minimal:
MACHINE| PASS | FAIL | SKIP | TOTAL | TIME (m) |
qemux86-64 |  472 |0 |  143 |   615 |  2.5 |
qemuarm64  |  472 |0 |  143 |   615 |   51 |

core-image-sato:
MACHINE| PASS | FAIL | SKIP | TOTAL | Time (m) |
qemux86-64 |  472 |0 |  143 |   615 |  2.4 |
qemuarm64  |  472 |0 |  143 |   615 |   52 |


Trevor Gamblin (2):
  coreutils: add ptest
  ptest-packagelists.inc: add coreutils to SLOW list

 .../distro/include/ptest-packagelists.inc |  1 +
 .../coreutils/coreutils/run-ptest | 17 +
 meta/recipes-core/coreutils/coreutils_8.31.bb | 37 +++
 3 files changed, 55 insertions(+)
 create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest

-- 
2.24.1

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

Re: [OE-core] [PATCH] linux-yocto/5.2: update to v5.2.32

[Bruce Ashfield]

On Wed, Feb 26, 2020 at 8:26 AM Bruce Ashfield  wrote:
>
> On Tue, Feb 25, 2020 at 11:47 PM Richard Purdie
>  wrote:
> >
> > On Mon, 2020-02-24 at 15:02 -0500, bruce.ashfi...@gmail.com wrote:
> > > From: Bruce Ashfield 
> > >
> > > Updating linux-yocto/5.2 to the latest korg -stable release that
> > > comprises
> > > the following commits:
> >
> > This was included in testing on the autobuilder and we saw:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/1612
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/315
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/1616
> >
> > and I'm not sure if they're from this?
>
> Me either.
>
> Hopefully one of the Wind River guys can have a look, otherwise, I'll
> poke at it next week.

I did spin up a patch of master + my version bump patch, and I am able
to complete the test locally (core-image-sato-sdk).

That permission denied error is very strange. I'll check the commits
to see if any of the scripts/Make* changed in that stable version, but
otherwise, I'm not seeing it and only have guesses as to how the
version bump could trigger that.

Cheers,

Bruce

>
> Cheers,
>
> Bruce
>
> >
> > Cheers,
> >
> > Richard
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 18:16 keltezéssel, Alexander Kanavin írta:
Right, then I am okay with this, as long as there are proper commit messages, and no 
version in .inc filename.


Alex


Thank you, I'll send a v2 patchset with proper commit messages and a cover mail 
tomorrow.



On Wed, 26 Feb 2020 at 17:37, Böszörményi Zoltán mailto:zbos...@pr.hu>> wrote:

2020. 02. 26. 17:35 keltezéssel, Böszörményi Zoltán via Openembedded-core 
írta:
 > 2020. 02. 26. 17:12 keltezéssel, Alexander Kanavin írta:
 >> The 'circular dependency' thing must be explained in the commits, and 
not in a
 >> discussion link to some email elsewhere.
 >>
 >> I still don't get why this is needed. The -initial recipe is identical 
to the
eventual
 >> 'real' recipe, so where is the circularity coming from?
 >
 > libva -> mesa -> libva

And the -initial recipe is NOT identical to the real one.
The real one always had DEPENDS = "virtual/mesa"

 >
 >>
 >> Alex
 >>
 >> On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core
 >> mailto:openembedded-core@lists.openembedded.org>
 >> >> wrote:
 >>
 >>     The package name exploits sstate.bbclass so it's not added as
 >>     implicit dependency to packages.
 >>
 >>     Signed-off-by: Böszörményi Zoltán mailto:zbos...@pr.hu>
>>
 >>     ---
 >>   meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
 >>   meta/recipes-graphics/libva/libva-initial_2.6.1.bb
  |
 >>     5 +
 >>   2 files changed, 8 insertions(+), 1 deletion(-)
 >>   create mode 100644 
meta/recipes-graphics/libva/libva-initial_2.6.1.bb

 >>     
 >>
 >>     diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
 >>     b/meta/recipes-graphics/libva/libva-2.6.1.inc
 >>     index ca1386d80b..5b1cdee7e3 100644
 >>     --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
 >>     +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
 >>     @@ -17,10 +17,12 @@ SECTION = "x11"
 >>   LICENSE = "MIT"
 >>   LIC_FILES_CHKSUM = 
"file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
 >>
 >>     -SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2


 >>
"

 >>     +SRC_URI =
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2


 >>
"

 >>   SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
 >>   SRC_URI[sha256sum] =
 >> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
 >>
 >>     +S = "${WORKDIR}/libva-${PV}"
 >>     +
 >>   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
 >>
 >>   DEPENDS = "libdrm"
 >>     diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb

 >>     
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 

 >>     
 >>     new file mode 100644
 >>     index 00..828ef6fbca
 >>     --- /dev/null
 >>     +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb

 >> 
 >>     @@ -0,0 +1,5 @@
 >>     +require libva-${PV}.inc
 >>     +
 >>     +do_install_append () {
 >>     +       rm -f ${D}${libdir}/*.so*
 >>     +}
 >>     --     2.24.1
 >>
 >>     --     ___
 >>     Openembedded-core mailing list
 >> Openembedded-core@lists.openembedded.org

 >> >
 >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
 >>
 >



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

[OE-core] [PATCH v2] util-linux: upgrade 2.34 -> 2.35.1

[Pierre-Jean Texier via Openembedded-core]

License-Update: add GPLv3 text in README.licensing

Also:
 - Drop upstreamed patch
 - Use 'disable-hwclock-gplv3' explicitly.

Since commit 7a3000f7ba548cf7d74ac77cc63fe8de228a669e ("hwclock: use parse_date 
function") hwclock is linked
with parse_date.y from gnullib. This gnulib code is distributed with GPLv3.
So, we have to use '--disable-hwclock-gplv3' to exclude this code.

See full changelog 
https://lore.kernel.org/util-linux/20200131095846.ogjtqrs7ai774...@ws.net.home/T/#u

Signed-off-by: Pierre-Jean Texier 
---
Changes v1 -> v2
 - bump to 2.35.1 instead of 2.35
 - use disable-hwclock-gplv3 option to not use datetime parsing GPLv3 code
 
FYI, hwclock will be made GPLv2-only again in v2.36, see:

 - 
https://lore.kernel.org/util-linux/20200127202152.4jh2w4chch37w...@ws.net.home/T/#e0c176440ca3f7b10693ff8f0afaf114b4b94405d

 meta/recipes-core/util-linux/util-linux.inc|  3 +-
 ...lsblk-force-to-print-PKNAME-for-partition.patch | 36 --
 meta/recipes-core/util-linux/util-linux_2.34.bb| 14 -
 meta/recipes-core/util-linux/util-linux_2.35.1.bb  | 13 
 4 files changed, 15 insertions(+), 51 deletions(-)
 delete mode 100644 
meta/recipes-core/util-linux/util-linux/0001-lsblk-force-to-print-PKNAME-for-partition.patch
 delete mode 100644 meta/recipes-core/util-linux/util-linux_2.34.bb
 create mode 100644 meta/recipes-core/util-linux/util-linux_2.35.1.bb

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 179cb3d..0566569 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -8,7 +8,7 @@ SECTION = "base"
 
 LICENSE = "GPLv2+ & LGPLv2.1+ & BSD-3-Clause & BSD-4-Clause"
 
-LIC_FILES_CHKSUM = 
"file://README.licensing;md5=972a134f1e14b2b060e365df2fab0099 \
+LIC_FILES_CHKSUM = 
"file://README.licensing;md5=0fd5c050c6187d2bf0a4492b7f4e33da \
 file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
 
file://Documentation/licenses/COPYING.GPL-2.0-or-later;md5=b234ee4d69f5fce4486a80fdaf4a4263
 \
 
file://Documentation/licenses/COPYING.LGPL-2.1-or-later;md5=4fbd65380cdd255951079008b364516c
 \
@@ -105,6 +105,7 @@ EXTRA_OECONF = "\
 EXTRA_OECONF_append_class-target = " --enable-setpriv"
 EXTRA_OECONF_append_class-native = " --without-cap-ng --disable-setpriv"
 EXTRA_OECONF_append_class-nativesdk = " --without-cap-ng --disable-setpriv"
+EXTRA_OECONF_append = " --disable-hwclock-gplv3"
 
 # enable pcre2 for native/nativesdk to match host distros
 # this helps to keep same expectations when using the SDK or
diff --git 
a/meta/recipes-core/util-linux/util-linux/0001-lsblk-force-to-print-PKNAME-for-partition.patch
 
b/meta/recipes-core/util-linux/util-linux/0001-lsblk-force-to-print-PKNAME-for-partition.patch
deleted file mode 100644
index 5d4c148..000
--- 
a/meta/recipes-core/util-linux/util-linux/0001-lsblk-force-to-print-PKNAME-for-partition.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From e3bb9bfb76c17b1d05814436ced62c05c4011f48 Mon Sep 17 00:00:00 2001
-From: Karel Zak 
-Date: Thu, 27 Jun 2019 09:22:18 +0200
-Subject: [PATCH] lsblk: force to print PKNAME for partition
-
-PKNAME (parent kernel device name) is based on printed tree according
-to parent -> child relationship. The tree is optional and not printed
-if partition specified (.e.g "lsblk -o+PKNAME /dev/sda1"), but old
-versions print the PKNAME also in this case.
-
-Upstream-Status: Backport 
[https://github.com/karelzak/util-linux/commit/e3bb9bfb76c17b1d05814436ced62c05c4011f48]
-
-Addresses: https://github.com/karelzak/util-linux/issues/813
-Signed-off-by: Karel Zak 
-Signed-off-by: Liwei Song 

- misc-utils/lsblk.c | 3 +++
- 1 file changed, 3 insertions(+)
-
-diff --git a/misc-utils/lsblk.c b/misc-utils/lsblk.c
-index e95af7af0256..3ce6da730264 100644
 a/misc-utils/lsblk.c
-+++ b/misc-utils/lsblk.c
-@@ -1019,6 +1019,9 @@ static void device_to_scols(
-   DBG(DEV, ul_debugobj(dev, "add '%s' to scols", dev->name));
-   ON_DBG(DEV, if (ul_path_isopen_dirfd(dev->sysfs)) ul_debugobj(dev, " %s 
---> is open!", dev->name));
- 
-+  if (!parent && dev->wholedisk)
-+  parent = dev->wholedisk;
-+
-   /* Do not print device more than one in --list mode */
-   if (!(lsblk->flags & LSBLK_TREE) && dev->is_printed)
-   return;
--- 
-2.17.1
-
diff --git a/meta/recipes-core/util-linux/util-linux_2.34.bb 
b/meta/recipes-core/util-linux/util-linux_2.34.bb
deleted file mode 100644
index 557449d..000
--- a/meta/recipes-core/util-linux/util-linux_2.34.bb
+++ /dev/null
@@ -1,14 +0,0 @@
-require util-linux.inc
-
-SRC_URI += "file://configure-sbindir.patch \
-file://runuser.pamd \
-file://runuser-l.pamd \
-file://ptest.patch \
-file://run-ptest \
-file://display_testname_for_subtest.patch \
-file://avoid_parallel_tests.patch \
-

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Alexander Kanavin]

Right, then I am okay with this, as long as there are proper commit
messages, and no version in .inc filename.

Alex

On Wed, 26 Feb 2020 at 17:37, Böszörményi Zoltán  wrote:

> 2020. 02. 26. 17:35 keltezéssel, Böszörményi Zoltán via Openembedded-core
> írta:
> > 2020. 02. 26. 17:12 keltezéssel, Alexander Kanavin írta:
> >> The 'circular dependency' thing must be explained in the commits, and
> not in a
> >> discussion link to some email elsewhere.
> >>
> >> I still don't get why this is needed. The -initial recipe is identical
> to the eventual
> >> 'real' recipe, so where is the circularity coming from?
> >
> > libva -> mesa -> libva
>
> And the -initial recipe is NOT identical to the real one.
> The real one always had DEPENDS = "virtual/mesa"
>
> >
> >>
> >> Alex
> >>
> >> On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core
> >>  >> > wrote:
> >>
> >> The package name exploits sstate.bbclass so it's not added as
> >> implicit dependency to packages.
> >>
> >> Signed-off-by: Böszörményi Zoltán  zbos...@pr.hu>>
> >> ---
> >>   meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
> >>   meta/recipes-graphics/libva/libva-initial_2.6.1.bb <
> http://libva-initial_2.6.1.bb> |
> >> 5 +
> >>   2 files changed, 8 insertions(+), 1 deletion(-)
> >>   create mode 100644 meta/recipes-graphics/libva/
> libva-initial_2.6.1.bb
> >> 
> >>
> >> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> index ca1386d80b..5b1cdee7e3 100644
> >> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> @@ -17,10 +17,12 @@ SECTION = "x11"
> >>   LICENSE = "MIT"
> >>   LIC_FILES_CHKSUM =
> "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> >>
> >> -SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2
> >> <
> https://github.com/intel/$%7BBPN%7D/releases/download/$%7BPV%7D/$%7BBP%7D.tar.bz2
> >"
> >> +SRC_URI = "
> https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2
> >> <
> https://github.com/intel/libva/releases/download/$%7BPV%7D/libva-$%7BPV%7D.tar.bz2
> >"
> >>   SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> >>   SRC_URI[sha256sum] =
> >> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> >>
> >> +S = "${WORKDIR}/libva-${PV}"
> >> +
> >>   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
> >>
> >>   DEPENDS = "libdrm"
> >> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >>  b/meta/recipes-graphics/libva/
> libva-initial_2.6.1.bb
> >> 
> >> new file mode 100644
> >> index 00..828ef6fbca
> >> --- /dev/null
> >> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >> 
> >> @@ -0,0 +1,5 @@
> >> +require libva-${PV}.inc
> >> +
> >> +do_install_append () {
> >> +   rm -f ${D}${libdir}/*.so*
> >> +}
> >> -- 2.24.1
> >>
> >> -- ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> 
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>
> >
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:

2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:



On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán 
wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.


don't assume things


Understood.


http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html




I am trying to make us thing if -dev package can be used somehow to
avoid this
or have we exhausted all possibilities.


Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?


it is not a problem, however, it is a work to keep such setup going and
also it has to be considered always in dependencies etc.


Surely it's not reserved for libgcc-initial and friends.



they are different usecases, libgcc-initial is a veneer/trampoline used
to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.


It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
    circular dependency is avoided. mesa needs a crippled libva
(pkgconfig + headers)
    to build its VAAPI state tracker and the VAAPI drivers


I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE


Fedora also uses the full libva.

However, the chicken-and-egg circular dependency is broken by history
for these distros.

Koji and Mock build one package at a time with all their dependencies
already available from the staging package repository and the results
will be eventually uploaded to the same repository.

Bitbake doesn't have have this loophole to download pre-built dependencies.


Also, somewhere on 01.org or in the libva sources the same solution
I presented in this patchset is suggested:

1. build libva with --disable-glx (it is needed when Mesa SDK is present)
   but it's not needed by not depending on mesa in libva-initial
2. build mesa with libva build in (1) as it only needs the pkgconfig files
   and the headers
3. build libva with --enable-glx. It's autodetected, set to on with
   depending on mesa in the full libva recipe.

Obviusly the same libva recipe can't be used to build mesa that depends on mesa.






2. by using libva-initial as the package name, the per-recipe sysroot issue
    is avoided where prepare-sysroot for a 3rd package like
intel-vaapi-driver
    would fail because the real libva the crippled variant would install
    identical files



right, this is the problem I am afraid of creating almost duplicate packages








Signed-off-by: Böszörményi Zoltán 
---
 meta/recipes-graphics/libva/libva-2.6.1.inc    | 4 +++-
 meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
 2 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644
meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM =
"file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

-SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;

+SRC_URI =
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;

 SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
 SRC_URI[sha256sum] =
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"

+S = "${WORKDIR}/libva-${PV}"
+
 UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

 DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
--
2.24.1

--
___
Openembedded-core mailing list

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:



On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:

2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán 
wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.


don't assume things


Understood.


http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html




I am trying to make us thing if -dev package can be used somehow to
avoid this
or have we exhausted all possibilities.


Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?


it is not a problem, however, it is a work to keep such setup going and
also it has to be considered always in dependencies etc.


Surely it's not reserved for libgcc-initial and friends.



they are different usecases, libgcc-initial is a veneer/trampoline used
to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.


It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
    circular dependency is avoided. mesa needs a crippled libva
(pkgconfig + headers)
    to build its VAAPI state tracker and the VAAPI drivers


I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE


Fedora also uses the full libva.

However, the chicken-and-egg circular dependency is broken by history
for these distros.

Koji and Mock build one package at a time with all their dependencies
already available from the staging package repository and the results
will be eventually uploaded to the same repository.

Bitbake doesn't have have this loophole to download pre-built dependencies.




2. by using libva-initial as the package name, the per-recipe sysroot issue
    is avoided where prepare-sysroot for a 3rd package like
intel-vaapi-driver
    would fail because the real libva the crippled variant would install
    identical files



right, this is the problem I am afraid of creating almost duplicate packages








Signed-off-by: Böszörményi Zoltán 
---
     meta/recipes-graphics/libva/libva-2.6.1.inc    | 4 +++-
     meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
     2 files changed, 8 insertions(+), 1 deletion(-)
     create mode 100644
meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
     LICENSE = "MIT"
     LIC_FILES_CHKSUM =
"file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

-SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;

+SRC_URI =
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;

     SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
     SRC_URI[sha256sum] =
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"

+S = "${WORKDIR}/libva-${PV}"
+
     UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

     DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
--
2.24.1

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








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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán  wrote:
>>>
>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
 On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán 
 wrote:
>
> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>> Openembedded-core  wrote:
>>>
>>> The package name exploits sstate.bbclass so it's not added as
>>> implicit dependency to packages.
>>>
>>
>> what is the use of this recipe and why should it be added to core ?
>
> I should have added a cover letter, shouldn't I?
> See patch 3/5 in the series for enabling gallium-va in Mesa.
>

 recipe seems to build full libva, so why not just use that instead.
>>>
>>> You don't seem to be reading mails from openembedded-devel that
>>> you were cc-ed on.
>>
>> don't assume things
> 
> Understood.
> 
>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>>>
>>>
>>
>> I am trying to make us thing if -dev package can be used somehow to
>> avoid this
>> or have we exhausted all possibilities.
> 
> Why is it a problem to exploit sstate.bbclass internals implicitly
> by using a *-initial package name for an arbitrary package?

it is not a problem, however, it is a work to keep such setup going and
also it has to be considered always in dependencies etc.

> Surely it's not reserved for libgcc-initial and friends.
> 

they are different usecases, libgcc-initial is a veneer/trampoline used
to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.

> It solves two problems nicely in one go:
> 1. by using a different package than libva, the libva-vs-mesa
>    circular dependency is avoided. mesa needs a crippled libva
> (pkgconfig + headers)
>    to build its VAAPI state tracker and the VAAPI drivers

I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE

> 2. by using libva-initial as the package name, the per-recipe sysroot issue
>    is avoided where prepare-sysroot for a 3rd package like
> intel-vaapi-driver
>    would fail because the real libva the crippled variant would install
>    identical files
> 

right, this is the problem I am afraid of creating almost duplicate packages

>>

>>
>>> Signed-off-by: Böszörményi Zoltán 
>>> ---
>>>     meta/recipes-graphics/libva/libva-2.6.1.inc    | 4 +++-
>>>     meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
>>>     2 files changed, 8 insertions(+), 1 deletion(-)
>>>     create mode 100644
>>> meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>
>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>> b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>> index ca1386d80b..5b1cdee7e3 100644
>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>>     LICENSE = "MIT"
>>>     LIC_FILES_CHKSUM =
>>> "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>>
>>> -SRC_URI =
>>> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
>>>
>>> +SRC_URI =
>>> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
>>>
>>>     SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>>     SRC_URI[sha256sum] =
>>> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>>
>>> +S = "${WORKDIR}/libva-${PV}"
>>> +
>>>     UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
>>>
>>>     DEPENDS = "libdrm"
>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>> new file mode 100644
>>> index 00..828ef6fbca
>>> --- /dev/null
>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>> @@ -0,0 +1,5 @@
>>> +require libva-${PV}.inc
>>> +
>>> +do_install_append () {
>>> +   rm -f ${D}${libdir}/*.so*
>>> +}
>>> -- 
>>> 2.24.1
>>>
>>> -- 
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>>>
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 17:35 keltezéssel, Böszörményi Zoltán via Openembedded-core írta:

2020. 02. 26. 17:12 keltezéssel, Alexander Kanavin írta:
The 'circular dependency' thing must be explained in the commits, and not in a 
discussion link to some email elsewhere.


I still don't get why this is needed. The -initial recipe is identical to the eventual 
'real' recipe, so where is the circularity coming from?


libva -> mesa -> libva


And the -initial recipe is NOT identical to the real one.
The real one always had DEPENDS = "virtual/mesa"





Alex

On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core 
> wrote:


    The package name exploits sstate.bbclass so it's not added as
    implicit dependency to packages.

    Signed-off-by: Böszörményi Zoltán mailto:zbos...@pr.hu>>
    ---
  meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
  meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
 |
    5 +
  2 files changed, 8 insertions(+), 1 deletion(-)
  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
    

    diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
    b/meta/recipes-graphics/libva/libva-2.6.1.inc
    index ca1386d80b..5b1cdee7e3 100644
    --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
    +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
    @@ -17,10 +17,12 @@ SECTION = "x11"
  LICENSE = "MIT"
  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

    -SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2
    
"
    +SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2
    
"
  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
  SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"


    +S = "${WORKDIR}/libva-${PV}"
    +
  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

  DEPENDS = "libdrm"
    diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
     
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
    
    new file mode 100644
    index 00..828ef6fbca
    --- /dev/null
    +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 


    @@ -0,0 +1,5 @@
    +require libva-${PV}.inc
    +
    +do_install_append () {
    +       rm -f ${D}${libdir}/*.so*
    +}
    --     2.24.1

    --     ___
    Openembedded-core mailing list
    Openembedded-core@lists.openembedded.org 


    http://lists.openembedded.org/mailman/listinfo/openembedded-core





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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 17:12 keltezéssel, Alexander Kanavin írta:
The 'circular dependency' thing must be explained in the commits, and not in a discussion 
link to some email elsewhere.


I still don't get why this is needed. The -initial recipe is identical to the eventual 
'real' recipe, so where is the circularity coming from?


libva -> mesa -> libva



Alex

On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core 
> wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.

Signed-off-by: Böszörményi Zoltán mailto:zbos...@pr.hu>>
---
  meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
  meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
 |
5 +
  2 files changed, 8 insertions(+), 1 deletion(-)
  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb


diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
  LICENSE = "MIT"
  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2

"
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2

"
  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
  SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"

+S = "${WORKDIR}/libva-${PV}"
+
  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

  DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb

new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 

@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+       rm -f ${D}${libdir}/*.so*
+}
-- 
2.24.1


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org 

http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Alexander Kanavin]

The 'circular dependency' thing must be explained in the commits, and not
in a discussion link to some email elsewhere.

I still don't get why this is needed. The -initial recipe is identical to
the eventual 'real' recipe, so where is the circularity coming from?

Alex

On Wed, 26 Feb 2020 at 15:05, Böszörményi Zoltán via Openembedded-core <
openembedded-core@lists.openembedded.org> wrote:

> The package name exploits sstate.bbclass so it's not added as
> implicit dependency to packages.
>
> Signed-off-by: Böszörményi Zoltán 
> ---
>  meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
>  meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
>  2 files changed, 8 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>
> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
> b/meta/recipes-graphics/libva/libva-2.6.1.inc
> index ca1386d80b..5b1cdee7e3 100644
> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> @@ -17,10 +17,12 @@ SECTION = "x11"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>
> -SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
> +SRC_URI = "
> https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2
> "
>  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>  SRC_URI[sha256sum] =
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>
> +S = "${WORKDIR}/libva-${PV}"
> +
>  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
>
>  DEPENDS = "libdrm"
> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> new file mode 100644
> index 00..828ef6fbca
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> @@ -0,0 +1,5 @@
> +require libva-${PV}.inc
> +
> +do_install_append () {
> +   rm -f ${D}${libdir}/*.so*
> +}
> --
> 2.24.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] libva: Split out the base parts into an include file

[Alexander Kanavin]

Don't version the .inc please, this will break automated version updates.

Alex

On Wed, 26 Feb 2020 at 15:08, Böszörményi Zoltán via Openembedded-core <
openembedded-core@lists.openembedded.org> wrote:

> Signed-off-by: Böszörményi Zoltán 
> ---
>  meta/recipes-graphics/libva/libva-2.6.1.inc | 30 
>  meta/recipes-graphics/libva/libva_2.6.1.bb  | 31 ++---
>  2 files changed, 32 insertions(+), 29 deletions(-)
>  create mode 100644 meta/recipes-graphics/libva/libva-2.6.1.inc
>
> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
> b/meta/recipes-graphics/libva/libva-2.6.1.inc
> new file mode 100644
> index 00..ca1386d80b
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> @@ -0,0 +1,30 @@
> +SUMMARY = "Video Acceleration (VA) API for Linux"
> +DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
> +and API specification which enables and provides access to graphics \
> +hardware (GPU) acceleration for video processing on Linux and UNIX \
> +based operating systems. Accelerated processing includes video \
> +decoding, video encoding, subpicture blending and rendering. The \
> +specification was originally designed by Intel for its GMA (Graphics \
> +Media Accelerator) series of GPU hardware, the API is however not \
> +limited to GPUs or Intel specific hardware, as other hardware and \
> +manufacturers can also freely use this API for hardware accelerated \
> +video decoding."
> +
> +HOMEPAGE = "https://01.org/linuxmedia/vaapi;
> +BUGTRACKER = "https://github.com/intel/libva/issues;
> +
> +SECTION = "x11"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> +
> +SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
> +SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> +SRC_URI[sha256sum] =
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> +
> +UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
> +
> +DEPENDS = "libdrm"
> +
> +inherit meson pkgconfig features_check
> +
> +REQUIRED_DISTRO_FEATURES = "opengl"
> diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb
> b/meta/recipes-graphics/libva/libva_2.6.1.bb
> index 92cea83bc1..af4c1c98ab 100644
> --- a/meta/recipes-graphics/libva/libva_2.6.1.bb
> +++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
> @@ -1,33 +1,6 @@
> -SUMMARY = "Video Acceleration (VA) API for Linux"
> -DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
> -and API specification which enables and provides access to graphics \
> -hardware (GPU) acceleration for video processing on Linux and UNIX \
> -based operating systems. Accelerated processing includes video \
> -decoding, video encoding, subpicture blending and rendering. The \
> -specification was originally designed by Intel for its GMA (Graphics \
> -Media Accelerator) series of GPU hardware, the API is however not \
> -limited to GPUs or Intel specific hardware, as other hardware and \
> -manufacturers can also freely use this API for hardware accelerated \
> -video decoding."
> +require libva-${PV}.inc
>
> -HOMEPAGE = "https://01.org/linuxmedia/vaapi;
> -BUGTRACKER = "https://github.com/intel/libva/issues;
> -
> -SECTION = "x11"
> -LICENSE = "MIT"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> -
> -SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
> -SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> -SRC_URI[sha256sum] =
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> -
> -UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
> -
> -DEPENDS = "libdrm virtual/mesa"
> -
> -inherit meson pkgconfig features_check
> -
> -REQUIRED_DISTRO_FEATURES = "opengl"
> +DEPENDS += "virtual/mesa"
>
>  PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11',
> d)}"
>  PACKAGECONFIG[x11] = "-Dwith_x11=yes, -Dwith_x11=no,virtual/libx11
> libxext libxfixes"
> --
> 2.24.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 16:15 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:14 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 16:00 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:08 AM Böszörményi Zoltán via
Openembedded-core  wrote:


When meta-clang is used, for example to build chromium-x11 from
meta-browser, a linker error occurs in Zeus.

See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533

Signed-off-by: Böszörményi Zoltán 
---
   meta/recipes-graphics/mesa/mesa.inc | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 800e8813c7..b8f09a2ed3 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -24,6 +24,8 @@ PROVIDES = " \
   virtual/mesa \
   "

+TOOLCHAIN = "gcc"


lets fix the linker error instead.


The linker errors were similar to reports I found on some forums
from a couple of years ago and they all pointed to RTTI needed
to be enabled in LLVM/CLANG. But it didn't help.

This is a good workaround until meta-clang is fixed to build Mesa.



workaround  is needed to be applied in meta-clang not in core


This is why this patch has RFC in the title.
I'll send another patch against meta-clang.






+
   inherit meson pkgconfig python3native gettext features_check

   # Unset these to stop python trying to report the target Python setup
--
2.24.1

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




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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.


don't assume things


Understood.


http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html



I am trying to make us thing if -dev package can be used somehow to avoid this
or have we exhausted all possibilities.


Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?
Surely it's not reserved for libgcc-initial and friends.

It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
   circular dependency is avoided. mesa needs a crippled libva (pkgconfig + 
headers)
   to build its VAAPI state tracker and the VAAPI drivers
2. by using libva-initial as the package name, the per-recipe sysroot issue
   is avoided where prepare-sysroot for a 3rd package like intel-vaapi-driver
   would fail because the real libva the crippled variant would install
   identical files








Signed-off-by: Böszörményi Zoltán 
---
meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
2 files changed, 8 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"

+S = "${WORKDIR}/libva-${PV}"
+
UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
--
2.24.1

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






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

[OE-core] ✗ patchtest: failure for libarchive: Fix CVE-2020-9308

[Patchwork]

== Series Details ==

Series: libarchive: Fix CVE-2020-9308
Revision: 1
URL   : https://patchwork.openembedded.org/series/22958/
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:



* Patchlibarchive: Fix CVE-2020-9308
 Issue Missing or incorrectly formatted CVE tag in included patch 
file [test_cve_tag_format] 
  Suggested fixCorrect or include the CVE tag on cve patch with format: 
"CVE: CVE--"



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 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán  wrote:
>
> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
> > On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán  wrote:
> >>
> >> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
> >>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
> >>> Openembedded-core  wrote:
> 
>  The package name exploits sstate.bbclass so it's not added as
>  implicit dependency to packages.
> 
> >>>
> >>> what is the use of this recipe and why should it be added to core ?
> >>
> >> I should have added a cover letter, shouldn't I?
> >> See patch 3/5 in the series for enabling gallium-va in Mesa.
> >>
> >
> > recipe seems to build full libva, so why not just use that instead.
>
> You don't seem to be reading mails from openembedded-devel that
> you were cc-ed on.

don't assume things

> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>

I am trying to make us thing if -dev package can be used somehow to avoid this
or have we exhausted all possibilities.

> >
> >>>
>  Signed-off-by: Böszörményi Zoltán 
>  ---
> meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
> meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
> 2 files changed, 8 insertions(+), 1 deletion(-)
> create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> 
>  diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
>  b/meta/recipes-graphics/libva/libva-2.6.1.inc
>  index ca1386d80b..5b1cdee7e3 100644
>  --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>  +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>  @@ -17,10 +17,12 @@ SECTION = "x11"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = 
>  "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> 
>  -SRC_URI = 
>  "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
>  +SRC_URI = 
>  "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
> SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> SRC_URI[sha256sum] = 
>  "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> 
>  +S = "${WORKDIR}/libva-${PV}"
>  +
> UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
> 
> DEPENDS = "libdrm"
>  diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
>  b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>  new file mode 100644
>  index 00..828ef6fbca
>  --- /dev/null
>  +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>  @@ -0,0 +1,5 @@
>  +require libva-${PV}.inc
>  +
>  +do_install_append () {
>  +   rm -f ${D}${libdir}/*.so*
>  +}
>  --
>  2.24.1
> 
>  --
>  ___
>  Openembedded-core mailing list
>  Openembedded-core@lists.openembedded.org
>  http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] xz threads / memlimit behaviour (was: Re: [PATCH v2] bitbake.conf: omit XZ threads and RAM from sstate signatures)

[André Draszik]

On Mon, 2020-02-24 at 16:44 +, Richard Purdie wrote:
> On Mon, 2020-02-24 at 15:40 +0200, Adrian Bunk wrote:
> > On Mon, Feb 24, 2020 at 12:59:55PM +, André Draszik wrote:
> > > The number of threads used, and the amount of memory allowed
> > > to be used, should not affect sstate signatures, as they
> > > don't affect the result.
> > 
> > Unfortunately they can affect the result.
> 
> I looked into this a bit and its complicated. The threads are used to
> compress chunks and their compression should be deterministic whether
> done serially or in parallel.
> 
> I did some tests and:
> 
> xz 
> gave equivalent output to:
> xz  --threads=1
> 
> and
> 
> xz  --threads=2
> xz  --threads=5
> xz  --threads=50
> 
> all give different identical output.
> 
> So if we force --threads >=2 we should have determinism?

I did another test...

Even single threaded compression gives the same result as multi-threaded,
if single threaded is a result of xz scaling down the memory usage due
to --memlimit, ie:

xz -f -c -9 --threads=2 --memlimit=2000M --keep --verbose --verbose xztest > 
xztest2_down_to_1.xz
  xz: Filter chain: 
--lzma2=dict=64MiB,lc=3,lp=0,pb=2,mode=normal,nice=64,mf=bt4,depth=0
  xz: Using up to 2 threads.
  xz: 2499 MiB of memory is required. The limit is 2000 MiB.
  xz: Decompression will need 65 MiB of memory.
  xz: Adjusted the number of threads from 2 to 1 to not exceed the memory usage 
limit of 2000 MiB

is different from

xz -f -c -9 --threads=1 --memlimit=2000M --verbose --verbose xztest > xztest1.xz
  xz: Filter chain: 
--lzma2=dict=64MiB,lc=3,lp=0,pb=2,mode=normal,nice=64,mf=bt4,depth=0
  xz: 674 MiB of memory is required. The limit is 2000 MiB.
  xz: Decompression will need 65 MiB of memory.


There even is a comment in the xz sources about this. This simplifies things a 
bit...


> > > Otherwise, it becomes impossible to re-use sstate from
> > > automated builders on developer's machines (as the former
> > > might execute bitbake with certain constraints different
> > > compared to developer's machines).
> > > ...
> > > -XZ_DEFAULTS ?= "--memlimit=50% --threads=${@oe.utils.cpu_count()}"
> > > ...
> > 
> > Threaded compression can result in slightly worse compression
> > than single-threaded compression.
> > 
> > With memlimit the problem is actually the opposite way,
> > and worse than what you were trying to fix:
> > 
> > When a developer hits memlimit during compression, the documented
> > behavour of xz is to scale down the compression level.

This is not what is actually happening - it appears the documentation only
talks about single-threaded mode.
If you look at the code and look at command output, xz only ever
tries to reduce the number of threads if multi-threading was enabled. In
that case, it will *never* even attempt to change the compression level.

If it can't satisfy the memory limit by reducing the number of threads,
it just errors out.

So as long as all builders have at least 2 cores, i.e. --threads >= 2, memlimit
doesn't ever affect the outcome (except that it can make the operation fail as
a whole).


Cheers,
Andre'


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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 16:20 keltezéssel, Böszörményi Zoltán írta:

2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.
http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html


TL;DR: Making mesa depend on libva would introduce a circular dependency.








Signed-off-by: Böszörményi Zoltán 
---
   meta/recipes-graphics/libva/libva-2.6.1.inc    | 4 +++-
   meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
   2 files changed, 8 insertions(+), 1 deletion(-)
   create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
b/meta/recipes-graphics/libva/libva-2.6.1.inc

index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
   LICENSE = "MIT"
   LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
   SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
   SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"


+S = "${WORKDIR}/libva-${PV}"
+
   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

   DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb

new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
--
2.24.1

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






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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán  wrote:


2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.



recipe seems to build full libva, so why not just use that instead.


You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.
http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html






Signed-off-by: Böszörményi Zoltán 
---
   meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
   meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
   2 files changed, 8 insertions(+), 1 deletion(-)
   create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
   LICENSE = "MIT"
   LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
   SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
   SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"

+S = "${WORKDIR}/libva-${PV}"
+
   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

   DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
--
2.24.1

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




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

Re: [OE-core] [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Khem Raj]

On Wed, Feb 26, 2020 at 7:14 AM Böszörményi Zoltán  wrote:
>
> 2020. 02. 26. 16:00 keltezéssel, Khem Raj írta:
> > On Wed, Feb 26, 2020 at 6:08 AM Böszörményi Zoltán via
> > Openembedded-core  wrote:
> >>
> >> When meta-clang is used, for example to build chromium-x11 from
> >> meta-browser, a linker error occurs in Zeus.
> >>
> >> See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533
> >>
> >> Signed-off-by: Böszörményi Zoltán 
> >> ---
> >>   meta/recipes-graphics/mesa/mesa.inc | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/meta/recipes-graphics/mesa/mesa.inc 
> >> b/meta/recipes-graphics/mesa/mesa.inc
> >> index 800e8813c7..b8f09a2ed3 100644
> >> --- a/meta/recipes-graphics/mesa/mesa.inc
> >> +++ b/meta/recipes-graphics/mesa/mesa.inc
> >> @@ -24,6 +24,8 @@ PROVIDES = " \
> >>   virtual/mesa \
> >>   "
> >>
> >> +TOOLCHAIN = "gcc"
> >
> > lets fix the linker error instead.
>
> The linker errors were similar to reports I found on some forums
> from a couple of years ago and they all pointed to RTTI needed
> to be enabled in LLVM/CLANG. But it didn't help.
>
> This is a good workaround until meta-clang is fixed to build Mesa.
>

workaround  is needed to be applied in meta-clang not in core

> >
> >> +
> >>   inherit meson pkgconfig python3native gettext features_check
> >>
> >>   # Unset these to stop python trying to report the target Python setup
> >> --
> >> 2.24.1
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 16:00 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:08 AM Böszörményi Zoltán via
Openembedded-core  wrote:


When meta-clang is used, for example to build chromium-x11 from
meta-browser, a linker error occurs in Zeus.

See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533

Signed-off-by: Böszörményi Zoltán 
---
  meta/recipes-graphics/mesa/mesa.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 800e8813c7..b8f09a2ed3 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -24,6 +24,8 @@ PROVIDES = " \
  virtual/mesa \
  "

+TOOLCHAIN = "gcc"


lets fix the linker error instead.


The linker errors were similar to reports I found on some forums
from a couple of years ago and they all pointed to RTTI needed
to be enabled in LLVM/CLANG. But it didn't help.

This is a good workaround until meta-clang is fixed to build Mesa.




+
  inherit meson pkgconfig python3native gettext features_check

  # Unset these to stop python trying to report the target Python setup
--
2.24.1

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


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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán  wrote:
>
> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
> > On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
> > Openembedded-core  wrote:
> >>
> >> The package name exploits sstate.bbclass so it's not added as
> >> implicit dependency to packages.
> >>
> >
> > what is the use of this recipe and why should it be added to core ?
>
> I should have added a cover letter, shouldn't I?
> See patch 3/5 in the series for enabling gallium-va in Mesa.
>

recipe seems to build full libva, so why not just use that instead.

> >
> >> Signed-off-by: Böszörményi Zoltán 
> >> ---
> >>   meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
> >>   meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
> >>   2 files changed, 8 insertions(+), 1 deletion(-)
> >>   create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >>
> >> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
> >> b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> index ca1386d80b..5b1cdee7e3 100644
> >> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> >> @@ -17,10 +17,12 @@ SECTION = "x11"
> >>   LICENSE = "MIT"
> >>   LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> >>
> >> -SRC_URI = 
> >> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
> >> +SRC_URI = 
> >> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
> >>   SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> >>   SRC_URI[sha256sum] = 
> >> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> >>
> >> +S = "${WORKDIR}/libva-${PV}"
> >> +
> >>   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
> >>
> >>   DEPENDS = "libdrm"
> >> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
> >> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >> new file mode 100644
> >> index 00..828ef6fbca
> >> --- /dev/null
> >> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> >> @@ -0,0 +1,5 @@
> >> +require libva-${PV}.inc
> >> +
> >> +do_install_append () {
> >> +   rm -f ${D}${libdir}/*.so*
> >> +}
> >> --
> >> 2.24.1
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.



what is the use of this recipe and why should it be added to core ?


I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.




Signed-off-by: Böszörményi Zoltán 
---
  meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
  meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
  2 files changed, 8 insertions(+), 1 deletion(-)
  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
  LICENSE = "MIT"
  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
  SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"

+S = "${WORKDIR}/libva-${PV}"
+
  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

  DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
--
2.24.1

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


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

[OE-core] [PATCH] libarchive: Fix CVE-2020-9308

[Wenlin Kang]

Fix CVE-2020-9308

Signed-off-by: Wenlin Kang 
---
 ...ct-files-that-declare-invalid-header.patch | 124 ++
 .../libarchive/libarchive_3.4.1.bb|   4 +-
 2 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch

diff --git 
a/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
 
b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
new file mode 100644
index 00..c3e0af571e
--- /dev/null
+++ 
b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch
@@ -0,0 +1,124 @@
+From 94821008d6eea81e315c5881cdf739202961040a Mon Sep 17 00:00:00 2001
+From: Grzegorz Antoniak 
+Date: Sun, 2 Feb 2020 08:04:41 +0100
+Subject: [PATCH] RAR5 reader: reject files that declare invalid header flags
+
+One of the fields in RAR5's base block structure is the size of the
+header. Some invalid files declare a 0 header size setting, which can
+confuse the unpacker. Minimum header size for RAR5 base blocks is 7
+bytes (4 bytes for CRC, and 3 bytes for the rest), so block size of 0
+bytes should be rejected at header parsing stage.
+
+The fix adds an error condition if header size of 0 bytes is detected.
+In this case, the unpacker will not attempt to unpack the file, as the
+header is corrupted.
+
+The commit also adds OSSFuzz #20459 sample to test further regressions
+in this area.
+
+Upstream-Status: 
Backport[https://github.com/libarchive/libarchive/commit/94821008d6eea81e315c5881cdf739202961040a]
+CVE-2020-9308
+
+Signed-off-by: Wenlin Kang 
+---
+ Makefile.am |  1 +
+ libarchive/archive_read_support_format_rar5.c   | 17 +++--
+ libarchive/test/test_read_format_rar5.c | 15 +++
+ ...test_read_format_rar5_block_size_is_too_small.rar.uu |  8 
+ 4 files changed, 39 insertions(+), 2 deletions(-)
+ create mode 100644 
libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu
+
+diff --git a/Makefile.am b/Makefile.am
+index 06c2644..c65e243 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -877,6 +877,7 @@ libarchive_test_EXTRA_DIST=\
+   libarchive/test/test_read_format_rar5_win32.rar.uu \
+   
libarchive/test/test_read_format_rar5_arm_filter_on_window_boundary.rar.uu \
+   libarchive/test/test_read_format_rar5_different_winsize_on_merge.rar.uu 
\
++  libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu \
+   libarchive/test/test_read_format_raw.bufr.uu \
+   libarchive/test/test_read_format_raw.data.gz.uu \
+   libarchive/test/test_read_format_raw.data.Z.uu \
+diff --git a/libarchive/archive_read_support_format_rar5.c 
b/libarchive/archive_read_support_format_rar5.c
+index ff1d6f8..f7c163e 100644
+--- a/libarchive/archive_read_support_format_rar5.c
 b/libarchive/archive_read_support_format_rar5.c
+@@ -2085,6 +2085,8 @@ static int scan_for_signature(struct archive_read* a);
+ static int process_base_block(struct archive_read* a,
+ struct archive_entry* entry)
+ {
++  const size_t SMALLEST_RAR5_BLOCK_SIZE = 3;
++
+   struct rar5* rar = get_context(a);
+   uint32_t hdr_crc, computed_crc;
+   size_t raw_hdr_size = 0, hdr_size_len, hdr_size;
+@@ -2114,15 +2116,26 @@ static int process_base_block(struct archive_read* a,
+   return ARCHIVE_EOF;
+   }
+ 
++  hdr_size = raw_hdr_size + hdr_size_len;
++
+   /* Sanity check, maximum header size for RAR5 is 2MB. */
+-  if(raw_hdr_size > (2 * 1024 * 1024)) {
++  if(hdr_size > (2 * 1024 * 1024)) {
+   archive_set_error(>archive, ARCHIVE_ERRNO_FILE_FORMAT,
+   "Base block header is too large");
+ 
+   return ARCHIVE_FATAL;
+   }
+ 
+-  hdr_size = raw_hdr_size + hdr_size_len;
++  /* Additional sanity checks to weed out invalid files. */
++  if(raw_hdr_size == 0 || hdr_size_len == 0 ||
++  hdr_size < SMALLEST_RAR5_BLOCK_SIZE)
++  {
++  archive_set_error(>archive, ARCHIVE_ERRNO_FILE_FORMAT,
++  "Too small block encountered (%ld bytes)",
++  raw_hdr_size);
++
++  return ARCHIVE_FATAL;
++  }
+ 
+   /* Read the whole header data into memory, maximum memory use here is
+* 2MB. */
+diff --git a/libarchive/test/test_read_format_rar5.c 
b/libarchive/test/test_read_format_rar5.c
+index bb94d4e..f91521e 100644
+--- a/libarchive/test/test_read_format_rar5.c
 b/libarchive/test/test_read_format_rar5.c
+@@ -1256,3 +1256,18 @@ 
DEFINE_TEST(test_read_format_rar5_different_winsize_on_merge)
+ 
+   EPILOGUE();
+ }
++
++DEFINE_TEST(test_read_format_rar5_block_size_is_too_small)
++{
++  char buf[4096];
++  

Re: [OE-core] [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Khem Raj]

On Wed, Feb 26, 2020 at 6:08 AM Böszörményi Zoltán via
Openembedded-core  wrote:
>
> When meta-clang is used, for example to build chromium-x11 from
> meta-browser, a linker error occurs in Zeus.
>
> See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533
>
> Signed-off-by: Böszörményi Zoltán 
> ---
>  meta/recipes-graphics/mesa/mesa.inc | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc 
> b/meta/recipes-graphics/mesa/mesa.inc
> index 800e8813c7..b8f09a2ed3 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -24,6 +24,8 @@ PROVIDES = " \
>  virtual/mesa \
>  "
>
> +TOOLCHAIN = "gcc"

lets fix the linker error instead.

> +
>  inherit meson pkgconfig python3native gettext features_check
>
>  # Unset these to stop python trying to report the target Python setup
> --
> 2.24.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] util-linux: upgrade 2.34 -> 2.35

[Pierre-Jean Texier via Openembedded-core]

Hello Randy,

Le 26/02/2020 à 15:10, Randy MacLeod a écrit :


It would be nice to get util-linux updated for 3.1.

Pierre-Jean do you have time to address the GPLv3/hwclock licensing
and re-submit (2.35.1?) this week?


Sure, no problem, I will send a v2 with the 2.35.1 version
with '--disable-hwclock-gplv3' enabled, option available since:

https://github.com/karelzak/util-linux/commit/e8c21c894e69ba0c72ecf69e8297cb20ec5f9c1e

Regards,
--
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

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Khem Raj]

On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core  wrote:
>
> The package name exploits sstate.bbclass so it's not added as
> implicit dependency to packages.
>

what is the use of this recipe and why should it be added to core ?

> Signed-off-by: Böszörményi Zoltán 
> ---
>  meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
>  meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
>  2 files changed, 8 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>
> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
> b/meta/recipes-graphics/libva/libva-2.6.1.inc
> index ca1386d80b..5b1cdee7e3 100644
> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> @@ -17,10 +17,12 @@ SECTION = "x11"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>
> -SRC_URI = 
> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
> +SRC_URI = 
> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
>  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>  SRC_URI[sha256sum] = 
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>
> +S = "${WORKDIR}/libva-${PV}"
> +
>  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
>
>  DEPENDS = "libdrm"
> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> new file mode 100644
> index 00..828ef6fbca
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> @@ -0,0 +1,5 @@
> +require libva-${PV}.inc
> +
> +do_install_append () {
> +   rm -f ${D}${libdir}/*.so*
> +}
> --
> 2.24.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

2020. 02. 26. 15:13 keltezéssel, Paul Barker írta:

On Wed, 26 Feb 2020 at 14:04, Böszörményi Zoltán via Openembedded-core
 wrote:


The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.

Signed-off-by: Böszörményi Zoltán 
---
  meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
  meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
  2 files changed, 8 insertions(+), 1 deletion(-)
  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
  LICENSE = "MIT"
  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"

-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
  SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"

+S = "${WORKDIR}/libva-${PV}"
+
  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;

  DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}


Can you avoid building libva in the -initial recipe and still get the
headers and pkgconfig files?


Not really, as "make install" would still build and install the libraries.

I haven't found a set of "make -C ... install" commands to only install
the headers and the pkgconfig files. I also wanted to avoid adding patches
to keep the recipe minimal.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Paul Barker]

On Wed, 26 Feb 2020 at 14:04, Böszörményi Zoltán via Openembedded-core
 wrote:
>
> The package name exploits sstate.bbclass so it's not added as
> implicit dependency to packages.
>
> Signed-off-by: Böszörményi Zoltán 
> ---
>  meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
>  meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
>  2 files changed, 8 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>
> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
> b/meta/recipes-graphics/libva/libva-2.6.1.inc
> index ca1386d80b..5b1cdee7e3 100644
> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
> @@ -17,10 +17,12 @@ SECTION = "x11"
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>
> -SRC_URI = 
> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
> +SRC_URI = 
> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
>  SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>  SRC_URI[sha256sum] = 
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>
> +S = "${WORKDIR}/libva-${PV}"
> +
>  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
>
>  DEPENDS = "libdrm"
> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> new file mode 100644
> index 00..828ef6fbca
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> @@ -0,0 +1,5 @@
> +require libva-${PV}.inc
> +
> +do_install_append () {
> +   rm -f ${D}${libdir}/*.so*
> +}

Can you avoid building libva in the -initial recipe and still get the
headers and pkgconfig files?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/5] mesa: Add PACKAGECONFIG knob to enable VAAPI state tracker and drivers

[Böszörményi Zoltán via Openembedded-core]

Signed-off-by: Böszörményi Zoltán 
---
 meta/recipes-graphics/mesa/mesa.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 87f167c507..479d3223fa 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -142,6 +142,7 @@ PACKAGECONFIG[gallium] = 
"-Dgallium-drivers=${GALLIUMDRIVERS}, -Dgallium-drivers
 PACKAGECONFIG[gallium-llvm] = "-Dllvm=true -Dshared-llvm=true, -Dllvm=false, 
llvm${MESA_LLVM_RELEASE} llvm-native \
${@'elfutils' if 
${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
 PACKAGECONFIG[xa]  = "-Dgallium-xa=true, -Dgallium-xa=false"
+PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
 
 PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', 
'', d)}"
-- 
2.24.1

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

Re: [OE-core] [PATCH] util-linux: upgrade 2.34 -> 2.35

[Randy MacLeod]

On 1/22/20 1:06 PM, Pierre-Jean Texier via Openembedded-core wrote:

Hi Mikko,

Le 22/01/2020 à 10:28, mikko.rap...@bmw.de a écrit :

Which parts of util-linux are now licensed with GPLv3?


As said by Peter previously, it's only for hwclock. In fact
since commit 7a3000f7ba548cf7d74ac77cc63fe8de228a669e ("hwclock: use 
parse_date function ") so the version 2.30,

hwclock is linked with parse_date.y from gnullib.
And gnulib code is distributed with GPLv3

Regards


It would be nice to get util-linux updated for 3.1.

Pierre-Jean do you have time to address the GPLv3/hwclock licensing
and re-submit (2.35.1?) this week?

--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/5] mesa: Add PACKAGECONFIG knob to enable VDPAU state tracker and drivers

[Böszörményi Zoltán via Openembedded-core]

Signed-off-by: Böszörményi Zoltán 
---
 meta/recipes-graphics/mesa/mesa.inc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 479d3223fa..800e8813c7 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -144,6 +144,8 @@ PACKAGECONFIG[gallium-llvm] = "-Dllvm=true 
-Dshared-llvm=true, -Dllvm=false, llv
 PACKAGECONFIG[xa]  = "-Dgallium-xa=true, -Dgallium-xa=false"
 PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
 
+PACKAGECONFIG[vdpau] = "-Dgallium-vdpau=true,-Dgallium-vdpau=false,libvdpau"
+
 PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', 
'', d)}"
 
@@ -179,6 +181,7 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
  libgles3-mesa libgles3-mesa-dev \
  libxatracker libxatracker-dev \
  mesa-megadriver mesa-vulkan-drivers \
+ mesa-vdpau-drivers \
 "
 
 do_install_append () {
@@ -256,6 +259,7 @@ PACKAGES_DYNAMIC += "^mesa-driver-.*"
 
 FILES_mesa-megadriver = "${libdir}/dri/* 
${datadir}/drirc.d/00-mesa-defaults.conf"
 FILES_mesa-vulkan-drivers = "${libdir}/libvulkan_*.so ${datadir}/vulkan"
+FILES_${PN}-vdpau-drivers = "${libdir}/vdpau/*.so.*"
 FILES_libegl-mesa = "${libdir}/libEGL.so.*"
 FILES_libgbm = "${libdir}/libgbm.so.*"
 FILES_libgles1-mesa = "${libdir}/libGLESv1*.so.*"
@@ -265,7 +269,7 @@ FILES_libglapi = "${libdir}/libglapi.so.*"
 FILES_libosmesa = "${libdir}/libOSMesa.so.*"
 FILES_libxatracker = "${libdir}/libxatracker.so.*"
 
-FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan"
+FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan 
${libdir}/vdpau/*.so"
 FILES_libegl-mesa-dev = "${libdir}/libEGL.* ${includedir}/EGL 
${includedir}/KHR ${libdir}/pkgconfig/egl.pc"
 FILES_libgbm-dev = "${libdir}/libgbm.* ${libdir}/pkgconfig/gbm.pc 
${includedir}/gbm.h"
 FILES_libgl-mesa-dev = "${libdir}/libGL.* ${includedir}/GL 
${libdir}/pkgconfig/gl.pc"
-- 
2.24.1

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

[OE-core] [RFC PATCH 5/5] mesa: Enforce TOOLCHAIN="gcc"

[Böszörményi Zoltán via Openembedded-core]

When meta-clang is used, for example to build chromium-x11 from
meta-browser, a linker error occurs in Zeus.

See: https://gitlab.freedesktop.org/mesa/mesa/issues/2533

Signed-off-by: Böszörményi Zoltán 
---
 meta/recipes-graphics/mesa/mesa.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 800e8813c7..b8f09a2ed3 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -24,6 +24,8 @@ PROVIDES = " \
 virtual/mesa \
 "
 
+TOOLCHAIN = "gcc"
+
 inherit meson pkgconfig python3native gettext features_check
 
 # Unset these to stop python trying to report the target Python setup
-- 
2.24.1

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

[OE-core] [PATCH 1/5] libva: Split out the base parts into an include file

[Böszörményi Zoltán via Openembedded-core]

Signed-off-by: Böszörményi Zoltán 
---
 meta/recipes-graphics/libva/libva-2.6.1.inc | 30 
 meta/recipes-graphics/libva/libva_2.6.1.bb  | 31 ++---
 2 files changed, 32 insertions(+), 29 deletions(-)
 create mode 100644 meta/recipes-graphics/libva/libva-2.6.1.inc

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
b/meta/recipes-graphics/libva/libva-2.6.1.inc
new file mode 100644
index 00..ca1386d80b
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -0,0 +1,30 @@
+SUMMARY = "Video Acceleration (VA) API for Linux"
+DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
+and API specification which enables and provides access to graphics \
+hardware (GPU) acceleration for video processing on Linux and UNIX \
+based operating systems. Accelerated processing includes video \
+decoding, video encoding, subpicture blending and rendering. The \
+specification was originally designed by Intel for its GMA (Graphics \
+Media Accelerator) series of GPU hardware, the API is however not \
+limited to GPUs or Intel specific hardware, as other hardware and \
+manufacturers can also freely use this API for hardware accelerated \
+video decoding."
+
+HOMEPAGE = "https://01.org/linuxmedia/vaapi;
+BUGTRACKER = "https://github.com/intel/libva/issues;
+
+SECTION = "x11"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
+
+SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
+SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
+
+UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
+
+DEPENDS = "libdrm"
+
+inherit meson pkgconfig features_check
+
+REQUIRED_DISTRO_FEATURES = "opengl"
diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb 
b/meta/recipes-graphics/libva/libva_2.6.1.bb
index 92cea83bc1..af4c1c98ab 100644
--- a/meta/recipes-graphics/libva/libva_2.6.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -1,33 +1,6 @@
-SUMMARY = "Video Acceleration (VA) API for Linux"
-DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
-and API specification which enables and provides access to graphics \
-hardware (GPU) acceleration for video processing on Linux and UNIX \
-based operating systems. Accelerated processing includes video \
-decoding, video encoding, subpicture blending and rendering. The \
-specification was originally designed by Intel for its GMA (Graphics \
-Media Accelerator) series of GPU hardware, the API is however not \
-limited to GPUs or Intel specific hardware, as other hardware and \
-manufacturers can also freely use this API for hardware accelerated \
-video decoding."
+require libva-${PV}.inc
 
-HOMEPAGE = "https://01.org/linuxmedia/vaapi;
-BUGTRACKER = "https://github.com/intel/libva/issues;
-
-SECTION = "x11"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
-
-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
-SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
-SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
-
-UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
-
-DEPENDS = "libdrm virtual/mesa"
-
-inherit meson pkgconfig features_check
-
-REQUIRED_DISTRO_FEATURES = "opengl"
+DEPENDS += "virtual/mesa"
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)}"
 PACKAGECONFIG[x11] = "-Dwith_x11=yes, -Dwith_x11=no,virtual/libx11 libxext 
libxfixes"
-- 
2.24.1

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

[OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

[Böszörményi Zoltán via Openembedded-core]

The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.

Signed-off-by: Böszörményi Zoltán 
---
 meta/recipes-graphics/libva/libva-2.6.1.inc| 4 +++-
 meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +
 2 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb

diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc 
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
 
-SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2;
+SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
 SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
 SRC_URI[sha256sum] = 
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
 
+S = "${WORKDIR}/libva-${PV}"
+
 UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases;
 
 DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb 
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+   rm -f ${D}${libdir}/*.so*
+}
-- 
2.24.1

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

Re: [OE-core] [PATCH] linux-yocto/5.2: update to v5.2.32

[Bruce Ashfield]

On Tue, Feb 25, 2020 at 11:47 PM Richard Purdie
 wrote:
>
> On Mon, 2020-02-24 at 15:02 -0500, bruce.ashfi...@gmail.com wrote:
> > From: Bruce Ashfield 
> >
> > Updating linux-yocto/5.2 to the latest korg -stable release that
> > comprises
> > the following commits:
>
> This was included in testing on the autobuilder and we saw:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/1612
> https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/315
> https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/1616
>
> and I'm not sure if they're from this?

Me either.

Hopefully one of the Wind River guys can have a look, otherwise, I'll
poke at it next week.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 2/2] webkitgtk: Remove unnecessary REQUIRED_DISTRO_FEATURES requirements

[Adrian Bunk]

x11 can be replaced with wayland.
opengl is mandatory only with wayland.
Without x11, use gles2 for opengl.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-sato/webkit/webkitgtk_2.26.4.bb | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
index 1a0b504a51..0a5ecace02 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
@@ -26,7 +26,8 @@ SRC_URI[sha256sum] = 
"4386900713dfadf9741177210b32623cab22562a79ffd0d446b6656993
 
 inherit cmake pkgconfig gobject-introspection perlnative features_check 
upstream-version-is-even gtk-doc
 
-REQUIRED_DISTRO_FEATURES = "x11 opengl"
+ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
+REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 
'opengl', '', d)}"
 
 CVE_PRODUCT = "webkitgtk webkitgtk\+"
 
@@ -39,7 +40,8 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt 
libgcrypt \
   "
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland x11', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl 
opengl', '' ,d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'webgl opengl', '' ,d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', 'webgl 
gles2' ,d)} \
enchant \
libsecret \
   "
-- 
2.17.1

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

[OE-core] [PATCH v3 1/2] webkitgtk: Move X library DEPENDS to the x11 PACKAGECONFIG

[Adrian Bunk]

Also adjust them to what OptionsGTK currently checks.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-sato/webkit/webkitgtk_2.26.4.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
index 2e923991e9..1a0b504a51 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
@@ -30,10 +30,10 @@ REQUIRED_DISTRO_FEATURES = "x11 opengl"
 
 CVE_PRODUCT = "webkitgtk webkitgtk\+"
 
-DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt libgcrypt \
+DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libgcrypt \
gtk+3 gstreamer1.0 gstreamer1.0-plugins-base flex-native 
gperf-native sqlite3 \
   pango icu bison-native gawk intltool-native libwebp \
-  atk udev harfbuzz jpeg libpng librsvg libtheora libvorbis 
libxcomposite libxtst \
+  atk udev harfbuzz jpeg libpng librsvg libtheora libvorbis \
   ruby-native libnotify gstreamer1.0-plugins-bad \
   gettext-native glib-2.0 glib-2.0-native libtasn1 \
   "
@@ -45,7 +45,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[x11] = 
"-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/libx11 libxcomposite 
libxdamage libxrender libxt"
 PACKAGECONFIG[geoclue] = 
"-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
 PACKAGECONFIG[enchant] = 
"-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant2"
 PACKAGECONFIG[gles2] = "-DENABLE_GLES2=ON,-DENABLE_GLES2=OFF,virtual/libgles2"
-- 
2.17.1

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

Re: [OE-core] [PATCH v2 1/6] webkitgtk: Remove unnecessary REQUIRED_DISTRO_FEATURES requirements

[Adrian Bunk]

On Tue, Feb 25, 2020 at 01:46:27PM +0100, Martin Jansa wrote:
> On Tue, Feb 25, 2020 at 02:38:07PM +0200, Adrian Bunk wrote:
> > On Tue, Feb 25, 2020 at 12:32:55PM +0100, Alexander Kanavin wrote:
> > > I would probably look into how
> > > REQUIRED_DISTRO_FEATURE/ANY_OF_DISTRO_FEATURS is actually implemented, and
> > > see if you can convince it to do the right thing, or maybe write a custom
> > > re-implementation.
> > 
> > I did already check meta/classes/features_check.bbclass, there is no 
> > obvious simple way for expressing more complicated dependencies.
> 
> Doesn't this do what you wanted?
> 
> REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('DISTRO_FEATURES', 
> 'wayland', 'wayland opengl', 'x11', d)}"

Thanks, I now have a v3.

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

[OE-core] [PATCH] webkitgtk: Remove obsolete woff2 comment

[Adrian Bunk]

woff2 is now available in meta-webkit.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-sato/webkit/webkitgtk_2.26.4.bb | 1 -
 1 file changed, 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 b40699f4d1..2e923991e9 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.26.4.bb
@@ -53,7 +53,6 @@ PACKAGECONFIG[webgl] = 
"-DENABLE_WEBGL=ON,-DENABLE_WEBGL=OFF,virtual/libgl"
 PACKAGECONFIG[opengl] = "-DENABLE_OPENGL=ON,-DENABLE_OPENGL=OFF,virtual/libgl"
 PACKAGECONFIG[libsecret] = "-DUSE_LIBSECRET=ON,-DUSE_LIBSECRET=OFF,libsecret"
 PACKAGECONFIG[libhyphen] = "-DUSE_LIBHYPHEN=ON,-DUSE_LIBHYPHEN=OFF,libhyphen"
-# Source is at https://github.com/google/woff2
 PACKAGECONFIG[woff2] = "-DUSE_WOFF2=ON,-DUSE_WOFF2=OFF,woff2"
 PACKAGECONFIG[openjpeg] = "-DUSE_OPENJPEG=ON,-DUSE_OPENJPEG=OFF,openjpeg"
 
-- 
2.17.1

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