[OE-core] [PATCH] stress-ng: Fix build on musl

2020-06-09 Thread Khem Raj
Define daddr_t if not provided by system headers
Fixes
./stress-ng.h:3755:2: error: unknown type name 'daddr_t'; did you mean 
'caddr_t'?
daddr_t f_tfree;
^~~

Signed-off-by: Khem Raj 
---
 .../stress-ng/stress-ng/no_daddr_t.patch  | 22 +++
 .../stress-ng/stress-ng_0.11.12.bb|  2 +-
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/stress-ng/stress-ng/no_daddr_t.patch

diff --git a/meta/recipes-extended/stress-ng/stress-ng/no_daddr_t.patch 
b/meta/recipes-extended/stress-ng/stress-ng/no_daddr_t.patch
new file mode 100644
index 00..877f4f0624
--- /dev/null
+++ b/meta/recipes-extended/stress-ng/stress-ng/no_daddr_t.patch
@@ -0,0 +1,22 @@
+Define daddr_t if __DADDR_T_TYPE is not defined
+
+glibc defined daddr_t but musl does not, ideally it should not be used
+and simple int type is enough. However, its better to leave glibc behavior
+as it is and only define it to int if daddr_t is not provided by libc
+
+Upstream-Status: Pending
+
+Signed-off-by: Khem Raj 
+--- a/stress-ng.h
 b/stress-ng.h
+@@ -3750,6 +3750,10 @@ struct shim_statx {
+   uint64_t __spare2[14];
+ };
+ 
++#ifndef __DADDR_T_TYPE
++typedef int daddr_t;
++#endif
++
+ /* old ustat struct */
+ struct shim_ustat {
+   daddr_t f_tfree;
diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.11.12.bb 
b/meta/recipes-extended/stress-ng/stress-ng_0.11.12.bb
index 45f4bb41ad..c00086c095 100644
--- a/meta/recipes-extended/stress-ng/stress-ng_0.11.12.bb
+++ b/meta/recipes-extended/stress-ng/stress-ng_0.11.12.bb
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
 SRC_URI = "https://kernel.ubuntu.com/~cking/tarballs/${BPN}/${BP}.tar.xz \

file://0001-Do-not-preserve-ownership-when-installing-example-jo.patch \
+   file://no_daddr_t.patch \
"
 SRC_URI[sha256sum] = 
"0ccf437ca1876a3e8a55986c6481697045203a17f5994cb2f5096cd461d18031"
 
@@ -23,4 +24,3 @@ do_install() {
 oe_runmake DESTDIR=${D} install
 }
 
-COMPATIBLE_HOST_libc-musl = 'null'
-- 
2.27.0

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

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


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

2020-06-09 Thread Yu, Mingli

Hi Joshua,

I encounter below error when use the libarchive module, could you help 
to take a look?


# python3
Python 3.8.2 (default, Jun  8 2020, 06:35:32)
[GCC 10.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import libarchive
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.8/site-packages/libarchive/__init__.py", 
line 1, in 

from .entry import ArchiveEntry
  File "/usr/lib64/python3.8/site-packages/libarchive/entry.py", line 
6, in 

from . import ffi
  File "/usr/lib64/python3.8/site-packages/libarchive/ffi.py", line 
109, in 

errno = ffi('errno', [c_archive_p], c_int)
  File "/usr/lib64/python3.8/site-packages/libarchive/ffi.py", line 96, 
in ffi

f = getattr(libarchive, 'archive_'+name)
  File "/usr/lib64/python3.8/ctypes/__init__.py", line 386, in __getattr__
func = self.__getitem__(name)
  File "/usr/lib64/python3.8/ctypes/__init__.py", line 391, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: python3: undefined symbol: archive_errno
>>>

Thanks,


On 2/12/20 11:14 AM, Joshua Watt wrote:

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

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

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

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

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


Re: [OE-core] The change pointed to by a .scc file not detected when compile kernel

2020-06-09 Thread Yu, Mingli

Hi Bruce,

On 6/8/20 8:49 PM, Bruce Ashfield wrote:

On Mon, Jun 8, 2020 at 1:39 AM Yu, Mingli  wrote:


Hi Bruce,

On 6/4/20 9:04 PM, Bruce Ashfield wrote:

On Thu, Jun 4, 2020 at 12:52 AM Yu, Mingli  wrote:


Hi Bruce,

Currently, the change pointed to by a .scc file not detected when
compile kernel, for example:

1, add DISTRO_FEATURES_append = " virtualization" to conf/local.conf to
enable virtualization DISTRO_FEATURES and also add meta-virtualization
layer to conf/bblayers.conf

2, bitbake -cconfigure linux-yocto

3,
$ grep -Rn CONFIG_IO_DELAY_0XED
tmp/work/qemux86_64-wrs-linux/linux-yocto/5.4.43+gitAUTOINC+aafb8f095e_9e1b13d7f9-r0/linux-qemux86_64-standard-build/.config
5367:# CONFIG_IO_DELAY_0XED is not set

4, modify the lxc.cfg which introduced by lxc.scc under
meta-virtualization layer
$ git diff
diff --git a/recipes-kernel/linux/linux-yocto/lxc.cfg
b/recipes-kernel/linux/linux-yocto/lxc.cfg
index 3fefc03..b7a19a8 100644
--- a/recipes-kernel/linux/linux-yocto/lxc.cfg
+++ b/recipes-kernel/linux/linux-yocto/lxc.cfg
@@ -1,3 +1,4 @@
+CONFIG_IO_DELAY_0XED=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y


5, bitbake -cconfigure linux-yocto

6,
$ grep -Rn CONFIG_IO_DELAY_0XED
tmp-glibc/work/qemux86_64-wrs-linux/linux-yocto/5.4.43+gitAUTOINC+aafb8f095e_9e1b13d7f9-r0/linux-qemux86_64-standard-build/.config
5367:# CONFIG_IO_DELAY_0XED is not set

The change for CONFIG_IO_DELAY_0XED doesn't take effect.


Does the same thing happen with a cleanall ? There's an open bug about
the checksuming of those SRC_URI elements, and you are likely hitting
it if there's no cleansstate or cleanall happening.


No, it works if execute a cleanall before the step 6. But it should work
even if we don't execute cleanall.

BTW, what's the status of the bug you mentioned?


It's waiting on some input from Richard, its on the fix list for the
coming release though.


Thanks for your respond, waiting for your update for the fix.

Thanks,
Mingli



Cheers,

Bruce



Thanks,
Mingli



Also, you've confirmed that CONFIG_IO_DELAY_0XED isn't missing any
config options that it has as dependencies ?

Bruce



Thanks,
Mingli








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

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


Re: [OE-core] [PATCH] virglrenderer: correct REQUIRED_DISTRO_FEATURES

2020-06-09 Thread Yu, Mingli

Hi Alex and Denys,

On 6/10/20 5:50 AM, Denys Dmytriyenko wrote:

+1

The commit message should explain "why" and not "what", as "what" can be
easily understood from the code itself.


In fact, the DISTRO_FEATURES setting shouldn't affect native build.

Initially this patch is used to fix below error when opengl not defined 
in DISTRO_FEATURES in my build environment.

$ bitbake virglrenderer-native
virglrenderer-native was skipped: missing required distro feature 
'opengl' (not in DISTRO_FEATURES)


And the value defined in DISTRO_FEATURES is only translated to the 
appropriate option supplied to the configure script during the 
do_configure task for recipes built for the target.


Thanks,
Mingli




Sometimes "why" is obvious - e.g. version update of CVE fix, but in many cases
it's not at all clear why do you want everyone to be affected by your change.

PS. https://xkcd.com/1296/




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

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


Re: [OE-core][PATCH] Modied the license to GPLv2.1+ to keep with LICENSE file.

2020-06-09 Thread zhengruoqin
Hi Richard

> No, you simply cannot just do that.
> 
> If upstream takes the patch we can apply as a backport but until they accept a
> license change we can and will not.
> 

> Just because the license file says something doesn't mean every file is under
> that license if that file's header says differently.
> 
OK, I got it.

> I suspect upstream won't accept this patch either.
I'm sorry, but I don't know if you noticed 
https://gitlab.com/gnutls/gnutls/-/issues/1018 . 
Our team have dicussed this issue in gnutls's gitlab, and the community has 
recognized this modify.


--
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
   Nanjing, 210012, China
MAIL : zhengrq.f...@cn.fujistu.com



> -Original Message-
> From: Richard Purdie 
> Sent: Monday, June 8, 2020 5:33 PM
> To: Zheng, Ruoqin/郑 若钦 ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core][PATCH] Modied the license to GPLv2.1+ to keep with
> LICENSE file.
> 
> On Tue, 2020-06-09 at 01:54 +0800, zhengruoqin wrote:
> > Please reference to https://gitlab.com/gnutls/gnutls/-/issues/1018.
> >
> > Upstream-Status: Submitted
> > [https://gitlab.com/gnutls/gnutls/-/merge_requests/1285].
> >
> > Signed-off-by: Zheng Ruoqin 
> > ---
> >  ...license-to-GPLv2.1-to-keep-with-LICENSE-f.patch | 88
> > ++
> >  meta/recipes-support/gnutls/gnutls_3.6.13.bb   |  1 +
> >  2 files changed, 89 insertions(+)
> >  create mode 100644 meta/recipes-support/gnutls/gnutls/0001-Modied-
> > the-license-to-GPLv2.1-to-keep-with-LICENSE-f.patch
> 
> No, you simply cannot just do that.
> 
> If upstream takes the patch we can apply as a backport but until they accept a
> license change we can and will not.
> 
> Just because the license file says something doesn't mean every file is under
> that license if that file's header says differently.
> 
> I suspect upstream won't accept this patch either.
> 
> Cheers,
> 
> Richard
> 
> 



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

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


Re: [V2][oe-core][PATCH 1/1] vim: _FORTIFY_SOURCE=2 be gone

2020-06-09 Thread Joe Slater
Yes, as to lcl_maybe_fortify() being visible, but why the "?=" ?  Maybe, the 
security flags
Should have a pn-vim entry.  I don't like that.  Maybe the vim recipe should 
modify lcl_maybe_fortify()
but I really don't like that either.  Still, vim should be useable.  What I do 
not understand is why
this has not been reported.  Is everybody using the vi provided by busybox?

Joe

-Original Message-
From: Andre McCurdy  
Sent: Tuesday, June 9, 2020 3:59 PM
To: Slater, Joseph 
Cc: OE Core mailing list ; MacLeod, 
Randy 
Subject: Re: [V2][oe-core][PATCH 1/1] vim: _FORTIFY_SOURCE=2 be gone

On Tue, Jun 9, 2020 at 3:46 PM Joe Slater  wrote:
>
> vim will abort in many places with this setting.  Replace it with the 
> benign _FORTIFY_SOURCE=1.
>
> Signed-off-by: Joe Slater 
> ---
>  meta/recipes-support/vim/vim_8.2.bb | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/meta/recipes-support/vim/vim_8.2.bb 
> b/meta/recipes-support/vim/vim_8.2.bb
> index 60946a181f..709b6ddb55 100644
> --- a/meta/recipes-support/vim/vim_8.2.bb
> +++ b/meta/recipes-support/vim/vim_8.2.bb
> @@ -8,3 +8,8 @@ BBCLASSEXTEND = "native"
>  ALTERNATIVE_${PN}_append = " xxd"
>  ALTERNATIVE_TARGET[xxd] = "${bindir}/xxd"
>  ALTERNATIVE_LINK_NAME[xxd] = "${bindir}/xxd"
> +
> +# We override the default in security_flags.inc because vim (not 
> +vim-tiny!) will abort # in many places for _FORTIFY_SOURCE=2.  Security 
> flags become part of CC.
> +#
> +lcl_maybe_fortify = 
> "${@oe.utils.conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=1',d)}"

"lcl_maybe_fortify" was supposed to be a private local variable in 
security_flags.inc. If it's now a documented global variable which recipes are 
allowed to mess with, it should be renamed (e.g.
capitalised and the lcl_ prefix removed).
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


[OE-core] ✗ patchtest: failure for [V2] vim: _FORTIFY_SOURCE=2 be gone (rev2)

2020-06-09 Thread Patchwork
== Series Details ==

Series: [V2] vim: _FORTIFY_SOURCE=2 be gone (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/24510/
State : failure

== Summary ==


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



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



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

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

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

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


Re: [V2][oe-core][PATCH 1/1] vim: _FORTIFY_SOURCE=2 be gone

2020-06-09 Thread Andre McCurdy
On Tue, Jun 9, 2020 at 3:46 PM Joe Slater  wrote:
>
> vim will abort in many places with this setting.  Replace
> it with the benign _FORTIFY_SOURCE=1.
>
> Signed-off-by: Joe Slater 
> ---
>  meta/recipes-support/vim/vim_8.2.bb | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/meta/recipes-support/vim/vim_8.2.bb 
> b/meta/recipes-support/vim/vim_8.2.bb
> index 60946a181f..709b6ddb55 100644
> --- a/meta/recipes-support/vim/vim_8.2.bb
> +++ b/meta/recipes-support/vim/vim_8.2.bb
> @@ -8,3 +8,8 @@ BBCLASSEXTEND = "native"
>  ALTERNATIVE_${PN}_append = " xxd"
>  ALTERNATIVE_TARGET[xxd] = "${bindir}/xxd"
>  ALTERNATIVE_LINK_NAME[xxd] = "${bindir}/xxd"
> +
> +# We override the default in security_flags.inc because vim (not vim-tiny!) 
> will abort
> +# in many places for _FORTIFY_SOURCE=2.  Security flags become part of CC.
> +#
> +lcl_maybe_fortify = 
> "${@oe.utils.conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=1',d)}"

"lcl_maybe_fortify" was supposed to be a private local variable in
security_flags.inc. If it's now a documented global variable which
recipes are allowed to mess with, it should be renamed (e.g.
capitalised and the lcl_ prefix removed).
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


[V2][oe-core][PATCH 1/1] vim: _FORTIFY_SOURCE=2 be gone

2020-06-09 Thread Joe Slater
vim will abort in many places with this setting.  Replace
it with the benign _FORTIFY_SOURCE=1.

Signed-off-by: Joe Slater 
---
 meta/recipes-support/vim/vim_8.2.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-support/vim/vim_8.2.bb 
b/meta/recipes-support/vim/vim_8.2.bb
index 60946a181f..709b6ddb55 100644
--- a/meta/recipes-support/vim/vim_8.2.bb
+++ b/meta/recipes-support/vim/vim_8.2.bb
@@ -8,3 +8,8 @@ BBCLASSEXTEND = "native"
 ALTERNATIVE_${PN}_append = " xxd"
 ALTERNATIVE_TARGET[xxd] = "${bindir}/xxd"
 ALTERNATIVE_LINK_NAME[xxd] = "${bindir}/xxd"
+
+# We override the default in security_flags.inc because vim (not vim-tiny!) 
will abort
+# in many places for _FORTIFY_SOURCE=2.  Security flags become part of CC.
+#
+lcl_maybe_fortify = 
"${@oe.utils.conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=1',d)}"
-- 
2.17.1

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

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


Re: [OE-core] [PATCH] virglrenderer: correct REQUIRED_DISTRO_FEATURES

2020-06-09 Thread Denys Dmytriyenko
+1

The commit message should explain "why" and not "what", as "what" can be 
easily understood from the code itself.

Sometimes "why" is obvious - e.g. version update of CVE fix, but in many cases 
it's not at all clear why do you want everyone to be affected by your change.

PS. https://xkcd.com/1296/

-- 
Denys


On Tue, Jun 09, 2020 at 09:40:42AM +0200, Alexander Kanavin wrote:
> Please explain why?
> 
> Alex
> 
> On Tue 9. Jun 2020 at 9.17, Yu, Mingli  wrote:
> 
> > From: Mingli Yu 
> >
> > Add opengl to REQUIRED_DISTRO_FEATURES only for target build.
> >
> > Signed-off-by: Mingli Yu 
> > ---
> >  meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
> > b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
> > index 29b12628d0..d97f0e78f1 100644
> > --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
> > +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
> > @@ -21,4 +21,4 @@ inherit meson pkgconfig features_check
> >
> >  BBCLASSEXTEND = "native nativesdk"
> >
> > -REQUIRED_DISTRO_FEATURES = "opengl"
> > +REQUIRED_DISTRO_FEATURES_class-target = "opengl"
> > --
> > 2.24.1
> >
> > 
> >

> 

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

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


Re: [OE-core][PATCH] wic: Fix --extra-space argument handling

2020-06-09 Thread Denys Dmytriyenko
On Tue, Jun 09, 2020 at 12:16:31PM -0500, Joshua Watt wrote:
> 467f84e12b ("wic: Add --offset argument for partitions") broke the
> --extra-space argument handling in wic. Fix the option and add a unit
> test for the argument.
> 
> Signed-off-by: Joshua Watt 

Tested-by: Denys Dmytriyenko 


> ---
>  meta/lib/oeqa/selftest/cases/wic.py | 15 +++
>  scripts/lib/wic/ksparser.py |  2 +-
>  2 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
> b/meta/lib/oeqa/selftest/cases/wic.py
> index 9e7be6168e..8b58285c32 100644
> --- a/meta/lib/oeqa/selftest/cases/wic.py
> +++ b/meta/lib/oeqa/selftest/cases/wic.py
> @@ -908,6 +908,21 @@ class Wic2(WicTestCase):
>  p, _ = self._get_wic_partitions(tempf.name, ignore_status=True)
>  self.assertNotEqual(p.status, 0, "wic exited successfully when 
> an error was expected:\n%s" % p.output)
>  
> +def test_extra_space(self):
> +native_sysroot = get_bb_var("RECIPE_SYSROOT_NATIVE", "wic-tools")
> +
> +with NamedTemporaryFile("w", suffix=".wks") as tempf:
> +tempf.write("bootloader --ptable gpt\n" \
> +"part / --source rootfs --ondisk hda 
> --extra-space 200M --fstype=ext4\n")
> +tempf.flush()
> +
> +_, partlns = self._get_wic_partitions(tempf.name, native_sysroot)
> +self.assertEqual(len(partlns), 1)
> +size = partlns[0].split(':')[3]
> +self.assertRegex(size, r'^[0-9]+kiB$')
> +size = int(size[:-3])
> +self.assertGreaterEqual(size, 204800)
> +
>  @only_for_arch(['i586', 'i686', 'x86_64'])
>  def test_rawcopy_plugin_qemu(self):
>  """Test rawcopy plugin in qemu"""
> diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
> index 05ae292ef5..3453d9cb9d 100644
> --- a/scripts/lib/wic/ksparser.py
> +++ b/scripts/lib/wic/ksparser.py
> @@ -145,7 +145,7 @@ class KickStart():
>  part.add_argument('--exclude-path', nargs='+')
>  part.add_argument('--include-path', nargs='+', action='append')
>  part.add_argument('--change-directory')
> -part.add_argument("--extra-space", type=sizetype)
> +part.add_argument("--extra-space", type=sizetype("M"))
>  part.add_argument('--fsoptions', dest='fsopts')
>  part.add_argument('--fstype', default='vfat',
>choices=('ext2', 'ext3', 'ext4', 'btrfs',
> -- 
> 2.26.2
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


Re: [OE-core] [PATCH 34/42] lttng-modules: update to 2.12.1

2020-06-09 Thread Alexander Kanavin
On Tue, 9 Jun 2020 at 18:24, Peter Kjellerstedt 
wrote:

> > devupstream variant was incorrectly updated in a059fc67da4
> > (changed to 2.12, but without updating SRCREV), so revert it back
> > to 2.11.2.
>
> I don't understand this. If you update the recipe to 2.12.1, why do
> you not update the devupstream variant to match?
>

Because I have no interest in that variant, other than making sure it is
not misleading; it was added and is (supposedly) maintained by others who
use it to test the bleeding edge.

Generally those 'development' variants tend to bit rot quickly due to lack
of regular updates and testing, oe-core used to have plenty of them and
they were all dropped, except this one.

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

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


[OE-core][PATCH] wic: Fix --extra-space argument handling

2020-06-09 Thread Joshua Watt
467f84e12b ("wic: Add --offset argument for partitions") broke the
--extra-space argument handling in wic. Fix the option and add a unit
test for the argument.

Signed-off-by: Joshua Watt 
---
 meta/lib/oeqa/selftest/cases/wic.py | 15 +++
 scripts/lib/wic/ksparser.py |  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index 9e7be6168e..8b58285c32 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -908,6 +908,21 @@ class Wic2(WicTestCase):
 p, _ = self._get_wic_partitions(tempf.name, ignore_status=True)
 self.assertNotEqual(p.status, 0, "wic exited successfully when an 
error was expected:\n%s" % p.output)
 
+def test_extra_space(self):
+native_sysroot = get_bb_var("RECIPE_SYSROOT_NATIVE", "wic-tools")
+
+with NamedTemporaryFile("w", suffix=".wks") as tempf:
+tempf.write("bootloader --ptable gpt\n" \
+"part / --source rootfs --ondisk hda --extra-space 
200M --fstype=ext4\n")
+tempf.flush()
+
+_, partlns = self._get_wic_partitions(tempf.name, native_sysroot)
+self.assertEqual(len(partlns), 1)
+size = partlns[0].split(':')[3]
+self.assertRegex(size, r'^[0-9]+kiB$')
+size = int(size[:-3])
+self.assertGreaterEqual(size, 204800)
+
 @only_for_arch(['i586', 'i686', 'x86_64'])
 def test_rawcopy_plugin_qemu(self):
 """Test rawcopy plugin in qemu"""
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index 05ae292ef5..3453d9cb9d 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -145,7 +145,7 @@ class KickStart():
 part.add_argument('--exclude-path', nargs='+')
 part.add_argument('--include-path', nargs='+', action='append')
 part.add_argument('--change-directory')
-part.add_argument("--extra-space", type=sizetype)
+part.add_argument("--extra-space", type=sizetype("M"))
 part.add_argument('--fsoptions', dest='fsopts')
 part.add_argument('--fstype', default='vfat',
   choices=('ext2', 'ext3', 'ext4', 'btrfs',
-- 
2.26.2

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

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


Re: [OE-core] [PATCH 34/42] lttng-modules: update to 2.12.1

2020-06-09 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Alexander Kanavin
> Sent: den 8 juni 2020 09:47
> To: openembedded-core@lists.openembedded.org
> Cc: Alexander Kanavin 
> Subject: [OE-core] [PATCH 34/42] lttng-modules: update to 2.12.1
> 
> Drop backports.
> 
> devupstream variant was incorrectly updated in a059fc67da4
> (changed to 2.12, but without updating SRCREV), so revert it back
> to 2.11.2.

I don't understand this. If you update the recipe to 2.12.1, why do 
you not update the devupstream variant to match?

> Signed-off-by: Alexander Kanavin 
> ---
>  ...l-5.7-use-vmalloc_sync_mappings-on-k.patch | 853 --
>  ...per-rename-to-wrapper_vmalloc_sync_m.patch |  32 -
>  ..._sync_mappings-on-kernel-5.6-as-well.patch |  88 --
>  ...loc_sync_mappings-for-stable-kernels.patch |  67 --
>  ...ules_2.12.0.bb => lttng-modules_2.12.1.bb} |  11 +-
>  5 files changed, 3 insertions(+), 1048 deletions(-)
>  delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/0001-Update-
> for-kernel-5.7-use-vmalloc_sync_mappings-on-k.patch
>  delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/0002-Fix-
> missing-wrapper-rename-to-wrapper_vmalloc_sync_m.patch
>  delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/0003-Fix-Use-
> vmalloc_sync_mappings-on-kernel-5.6-as-well.patch
>  delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/0004-Update-
> Use-vmalloc_sync_mappings-for-stable-kernels.patch
>  rename meta/recipes-kernel/lttng/{lttng-modules_2.12.0.bb => lttng-
> modules_2.12.1.bb} (75%)

[snip]

> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.12.0.bb 
> b/meta/recipes-kernel/lttng/lttng-modules_2.12.1.bb
> similarity index 75%
> rename from meta/recipes-kernel/lttng/lttng-modules_2.12.0.bb
> rename to meta/recipes-kernel/lttng/lttng-modules_2.12.1.bb
> index 4a6c42e3bf..8d3fb475c0 100644
> --- a/meta/recipes-kernel/lttng/lttng-modules_2.12.0.bb
> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.12.1.bb
> @@ -11,14 +11,9 @@ COMPATIBLE_HOST = 
> '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
>  SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
> file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch 
> \
> file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
> -   
> file://0001-Update-for-kernel-5.7-use-vmalloc_sync_mappings-on-k.patch \
> -   
> file://0002-Fix-missing-wrapper-rename-to-wrapper_vmalloc_sync_m.patch \
> -   
> file://0003-Fix-Use-vmalloc_sync_mappings-on-kernel-5.6-as-well.patch \
> -   
> file://0004-Update-Use-vmalloc_sync_mappings-for-stable-kernels.patch \
> "
> 
> -SRC_URI[md5sum] = "be252df5013ea03894921d0b493c7b6c"
> -SRC_URI[sha256sum] = 
> "efeb2ae60e96dbe9a9b342d3a80dfc7642f06a8c09686089d491ad696bb98f4d"
> +SRC_URI[sha256sum] = 
> "639c03bf8f0e920567f45c96cc7ef749a8fc29ff7fb3fb97263d67f66fb71aef"
> 
>  export INSTALL_MOD_DIR="kernel/lttng-modules"
> 
> @@ -37,11 +32,11 @@ python do_package_prepend() {
>  BBCLASSEXTEND = "devupstream:target"
>  LIC_FILES_CHKSUM_class-devupstream = 
> "file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
>  DEFAULT_PREFERENCE_class-devupstream = "-1"
> -SRC_URI_class-devupstream = 
> "git://git.lttng.org/lttng-modules;branch=stable-2.12 \
> +SRC_URI_class-devupstream = 
> "git://git.lttng.org/lttng-modules;branch=stable-2.11 \
> file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch 
> \
> file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
> "
>  SRCREV_class-devupstream = "17c413953603f063f2a9d6c3788bec914ce6f955"
> -PV_class-devupstream = "2.12.0+git${SRCPV}"
> +PV_class-devupstream = "2.11.2+git${SRCPV}"
>  S_class-devupstream = "${WORKDIR}/git"
>  SRCREV_FORMAT ?= "lttng_git"
> --
> 2.26.2

//Peter

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

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


Re: [OE-core] [RFC][PATCH 1/2] features_check: Warn if not used

2020-06-09 Thread Jacob Kroon

On 6/9/20 5:44 PM, Richard Purdie wrote:

On Tue, 2020-06-09 at 16:11 +0200, Jacob Kroon wrote:

Signed-off-by: Jacob Kroon 
---
  meta/classes/features_check.bbclass | 20 
  1 file changed, 20 insertions(+)

diff --git a/meta/classes/features_check.bbclass
b/meta/classes/features_check.bbclass
index 4ba827d4ab..31ce600374 100644
--- a/meta/classes/features_check.bbclass
+++ b/meta/classes/features_check.bbclass
@@ -12,11 +12,25 @@
  # Copyright 2019 (C) Texas Instruments Inc.
  # Copyright 2013 (C) O.S. Systems Software LTDA.
  
+FEATURES_CHECK_INCLUDE_STACK := "${BBINCLUDESTACK}"


This looks like a rather heavy hit to want to take on every recipe
being parsed everywhere (I also really don't like seeing := needing to
be used).



Maybe I misunderstood you, but the check is only done in recipes that 
inherit the class. If you are referring to the accompanied change in 
BitBake for keeping track of the include stack, yeah that might be worse.


The direct assignment is needed in order to suppress false positives, 
for instance when an .inc/.bbclass contains the inherit directive. Not 
sure how to work around that without this.



I'd much rather this were some kind of test we could run periodically,
maybe on the infrastructure rather than the hit being taken all the
time.

Could we add something which just ran these tests? Maybe a class which
the autobuilder could inherit to enable these kinds of tests?



Maybe that is a better approach. autobuilder could send a summary report 
periodically to the ml so that the warnings would be visible.


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

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


Re: [OE-core] [RFC][PATCH 1/2] features_check: Warn if not used

2020-06-09 Thread Jacob Kroon

On 6/9/20 4:34 PM, Martin Jansa wrote:
Seeing how many cases like this exist(ed), this look very useful, but it 
would be even better if we can catch the opposite case when e.g. 
REQUIRED_DISTRO_FEATURES are set in recipe, but doesn't do anything 
because of missing features_check inherit.




Yes, that would be a good test for insane.

But I understand that such check might be more controversial as it would 
need to be checked globally (outside this bbclass), maybe something in 
insane.bbclass catching both cases as QA issue?


I didn't want to add this check to insane since I like that you only pay 
for the check if you actually use the class.


Not sure if that is worth pushing for, but I think I recall someone 
saying that a large part of the parsing time is spent running the 
anonyous python(?).


Jacob



On Tue, Jun 9, 2020 at 4:11 PM Jacob Kroon > wrote:


Signed-off-by: Jacob Kroon mailto:jacob.kr...@gmail.com>>
---
  meta/classes/features_check.bbclass | 20 
  1 file changed, 20 insertions(+)

diff --git a/meta/classes/features_check.bbclass
b/meta/classes/features_check.bbclass
index 4ba827d4ab..31ce600374 100644
--- a/meta/classes/features_check.bbclass
+++ b/meta/classes/features_check.bbclass
@@ -12,11 +12,25 @@
  # Copyright 2019 (C) Texas Instruments Inc.
  # Copyright 2013 (C) O.S. Systems Software LTDA.

+FEATURES_CHECK_INCLUDE_STACK := "${BBINCLUDESTACK}"
+
  python () {
      if d.getVar('PARSE_ALL_RECIPES', False):
          return

+    unused = True
+
      for kind in ['DISTRO', 'MACHINE', 'COMBINED']:
+        if d.getVar('ANY_OF_' + kind + '_FEATURES') is None and \
+           d.overridedata.get('ANY_OF_' + kind + '_FEATURES') is
None and \
+           d.getVar('REQUIRED_' + kind + '_FEATURES') is None and \
+           d.overridedata.get('REQUIRED_' + kind + '_FEATURES') is
None and \
+           d.getVar('CONFLICT_' + kind + '_FEATURES') is None and \
+           d.overridedata.get('CONFLICT_' + kind + '_FEATURES') is
None:
+            continue
+
+        unused = False
+
          # Assume at least one var is set.
          features = set((d.getVar(kind + '_FEATURES') or '').split())

@@ -39,4 +53,10 @@ python () {
              if conflicts:
                  raise bb.parse.SkipRecipe("conflicting %s
feature%s '%s' (in %s_FEATURES)"
                      % (kind.lower(), 's' if len(conflicts) > 1
else '', ' '.join(conflicts), kind))
+
+    # Only warn if inherited directly in a .bb-file; if the class
is inherited
+    # via an .inc/.bbclass it could be a false positive
+    inherited_from_bb =
d.getVar('FEATURES_CHECK_INCLUDE_STACK').split()[-1].endswith('.bb')
+    if unused and inherited_from_bb:
+        bb.warn("Recipe inherits features_check but doesn't use it")
  }


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

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


Re: [OE-core] [RFC][PATCH 1/2] features_check: Warn if not used

2020-06-09 Thread Richard Purdie
On Tue, 2020-06-09 at 16:11 +0200, Jacob Kroon wrote:
> Signed-off-by: Jacob Kroon 
> ---
>  meta/classes/features_check.bbclass | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/meta/classes/features_check.bbclass
> b/meta/classes/features_check.bbclass
> index 4ba827d4ab..31ce600374 100644
> --- a/meta/classes/features_check.bbclass
> +++ b/meta/classes/features_check.bbclass
> @@ -12,11 +12,25 @@
>  # Copyright 2019 (C) Texas Instruments Inc.
>  # Copyright 2013 (C) O.S. Systems Software LTDA.
>  
> +FEATURES_CHECK_INCLUDE_STACK := "${BBINCLUDESTACK}"

This looks like a rather heavy hit to want to take on every recipe
being parsed everywhere (I also really don't like seeing := needing to
be used).

I'd much rather this were some kind of test we could run periodically,
maybe on the infrastructure rather than the hit being taken all the
time.

Could we add something which just ran these tests? Maybe a class which
the autobuilder could inherit to enable these kinds of tests?

Cheers,

Richard

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

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


Re: [OE-core] [OE-Core][PATCH 2/2] rootfs-postcommands: Enable rootfs_check_host_user_contaminated

2020-06-09 Thread Alex Kiernan
On Thu, May 21, 2020 at 3:14 PM Alex Kiernan via
lists.openembedded.org 
wrote:
>
> Hi Ross
>
> On Thu, Jan 2, 2020 at 11:20 PM Ross Burton  wrote:
> >
> > On 19/12/2019 22:17, Alex Kiernan wrote:
> > > Enable rootfs_check_host_user_contaminated by default
> >
> > Useful check!
> >
> > WARNING: Paths in the rootfs are owned by the same user or group as the
> > user running bitbake. See the logfile for the specific paths.
> >
> > /data/poky-tmp/master/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/usr/share/fonts/.uuid
> >
> > /data/poky-tmp/master/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/usr/share/fonts/ttf/.uuid
> >
> > (patch incoming)
> >
>
> Did you manage to get a patch for this out? I've had a couple of goes
> at reproducing it and failed, but I suspect I'm not including the
> right things. It would be good to get this check enabled early in the
> release cycle, if we can?
>

Ping?

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

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


[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2020-06-09 Thread Stephen Jolley
All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 366
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "3.1", "3.2, "3.99" and "Future", the more pressing/urgent issues
being in "3.1" and then "3.2".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 

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

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


[OE-core] Yocto Project Status WW23'20

2020-06-09 Thread Stephen Jolley
Current Dev Position: YP 3.2 M1

Next Deadline: YP 3.2 M1 build date 2020/6/16

 

Next Team Meetings:

*   Bug Triage meeting Thursday June 11th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday July 7th at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday June 9th  at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See http://www.twitch.tv/letoatreidesthe2nd

 

Key Status/Updates:

*   YP 2.7.4 was released
*   YP 3.1.1 has been built with two issues being investigated before it
enters QA
*   A significant number of upgrades have merged into master and we are
up to date with a majority of recipes, particularly due work from Alex,
thanks! One which isn't and is looking slightly more problematic is the qemu
upgrade to 5.0.0, help would be welcome there.
*   YP 3.2 M1 is due to build next week so patches for M1 need to be
sent for review now in order to make it in.
*   We are struggling with maintainers for some key components of the
system/infrastructure such as devtool, wic, buildhistory and
patchwork/patchtest. If anyone can help in these areas please contact
Richard.
*   There remain a large number of bugs that we'd ideally like to fix in
3.2 M1 (or M2) but they are "unassigned", there is nobody to work on them.
If anyone has time, looking at these bugs would be a great way to help us.
See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs

 

YP 3.2 Milestone Dates:

*   YP 3.2 M1 build date 2020/6/16
*   YP 3.2 M1 Release date 2020/6/26
*   YP 3.2 M2 build date 2020/7/27
*   YP 3.2 M2 Release date 2020/8/7
*   YP 3.2 M3 build date 2020/8/31
*   YP 3.2 M3 Release date 2020/9/11
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 2.7.4 has been released
*   YP 3.1.1 build date 2020/6/09
*   YP 3.1.1 release date 2020/6/20
*   YP 3.0.4 build date 2020/8/10
*   YP 3.0.4 release date 2020/8/21
*   YP 3.1.2 build date 2020/9/14
*   YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

*   WDD 2577 (last week 2577) (

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

*   Total patches found: 1301 (last week 1343)
*   Patches in the Pending State: 517 (40%) [last week 535 (40%)]

 

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

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

 

The Status reports are now stored on the wiki at:

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 

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

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


Re: [OE-core] [RFC][PATCH 1/2] features_check: Warn if not used

2020-06-09 Thread Martin Jansa
Seeing how many cases like this exist(ed), this look very useful, but it
would be even better if we can catch the opposite case when e.g.
REQUIRED_DISTRO_FEATURES are set in recipe, but doesn't do anything because
of missing features_check inherit.

But I understand that such check might be more controversial as it would
need to be checked globally (outside this bbclass), maybe something in
insane.bbclass catching both cases as QA issue?

On Tue, Jun 9, 2020 at 4:11 PM Jacob Kroon  wrote:

> Signed-off-by: Jacob Kroon 
> ---
>  meta/classes/features_check.bbclass | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/meta/classes/features_check.bbclass
> b/meta/classes/features_check.bbclass
> index 4ba827d4ab..31ce600374 100644
> --- a/meta/classes/features_check.bbclass
> +++ b/meta/classes/features_check.bbclass
> @@ -12,11 +12,25 @@
>  # Copyright 2019 (C) Texas Instruments Inc.
>  # Copyright 2013 (C) O.S. Systems Software LTDA.
>
> +FEATURES_CHECK_INCLUDE_STACK := "${BBINCLUDESTACK}"
> +
>  python () {
>  if d.getVar('PARSE_ALL_RECIPES', False):
>  return
>
> +unused = True
> +
>  for kind in ['DISTRO', 'MACHINE', 'COMBINED']:
> +if d.getVar('ANY_OF_' + kind + '_FEATURES') is None and \
> +   d.overridedata.get('ANY_OF_' + kind + '_FEATURES') is None and
> \
> +   d.getVar('REQUIRED_' + kind + '_FEATURES') is None and \
> +   d.overridedata.get('REQUIRED_' + kind + '_FEATURES') is None
> and \
> +   d.getVar('CONFLICT_' + kind + '_FEATURES') is None and \
> +   d.overridedata.get('CONFLICT_' + kind + '_FEATURES') is None:
> +continue
> +
> +unused = False
> +
>  # Assume at least one var is set.
>  features = set((d.getVar(kind + '_FEATURES') or '').split())
>
> @@ -39,4 +53,10 @@ python () {
>  if conflicts:
>  raise bb.parse.SkipRecipe("conflicting %s feature%s '%s'
> (in %s_FEATURES)"
>  % (kind.lower(), 's' if len(conflicts) > 1 else '', '
> '.join(conflicts), kind))
> +
> +# Only warn if inherited directly in a .bb-file; if the class is
> inherited
> +# via an .inc/.bbclass it could be a false positive
> +inherited_from_bb =
> d.getVar('FEATURES_CHECK_INCLUDE_STACK').split()[-1].endswith('.bb')
> +if unused and inherited_from_bb:
> +bb.warn("Recipe inherits features_check but doesn't use it")
>  }
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


Re: [OE-core] [PATCH] remove unused DEPLOY_DIR_TOOLS variable from bitbake.conf

2020-06-09 Thread Robert P. J. Day
On Tue, 9 Jun 2020, Richard Purdie wrote:

> On Tue, 2020-06-09 at 14:33 +0100, Ross Burton wrote:
> > On Mon, 8 Jun 2020 at 21:15, Enrico J?rns  wrote:
> >
> > > What is the now suggested way of placing these kind of binaries?
> > > Simply in DEPLOY_DIR_IMAGES as the above-mentioned commit does
> > > (silently)?
> > > Or is there maybe still some motivation to keep DEPLOY_DIR_TOOLS?
> >
> > FWIW, meta-arm is also using DEPLOY_DIR_TOOLS and to fix builds with
> > master is now manually using DEPLOY_DIR/tools because having a
> > separate directory does help introduce some structure.
> >
> > Basically, I'd actually like to see this reverted.
>
> I'm tempted to agree. It was only merged on the basis that it was
> unused which isn't true.

  in my defense, i almost immediately admitted i hadn't noticed it in
meta-openembedded.

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

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


[OE-core] ✗ patchtest: failure for "[RFC] features_check: Warn if ..." and 1 more

2020-06-09 Thread Patchwork
== Series Details ==

Series: "[RFC] features_check: Warn if ..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/24558/
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[RFC, 2/2] Don't inherit 'features_check' in recipes that 
don't utilize it
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



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

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

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

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


Re: [OE-core] [PATCH] remove unused DEPLOY_DIR_TOOLS variable from bitbake.conf

2020-06-09 Thread Richard Purdie
On Tue, 2020-06-09 at 14:33 +0100, Ross Burton wrote:
> On Mon, 8 Jun 2020 at 21:15, Enrico J?rns  wrote:
> 
> > What is the now suggested way of placing these kind of binaries?
> > Simply in DEPLOY_DIR_IMAGES as the above-mentioned commit does
> > (silently)?
> > Or is there maybe still some motivation to keep DEPLOY_DIR_TOOLS?
> 
> FWIW, meta-arm is also using DEPLOY_DIR_TOOLS and to fix builds with
> master is now manually using DEPLOY_DIR/tools because having a
> separate directory does help introduce some structure.
> 
> Basically, I'd actually like to see this reverted.

I'm tempted to agree. It was only merged on the basis that it was
unused which isn't true.

Cheers,

Richard

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

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


[OE-core] [RFC][PATCH 1/2] features_check: Warn if not used

2020-06-09 Thread Jacob Kroon
Signed-off-by: Jacob Kroon 
---
 meta/classes/features_check.bbclass | 20 
 1 file changed, 20 insertions(+)

diff --git a/meta/classes/features_check.bbclass 
b/meta/classes/features_check.bbclass
index 4ba827d4ab..31ce600374 100644
--- a/meta/classes/features_check.bbclass
+++ b/meta/classes/features_check.bbclass
@@ -12,11 +12,25 @@
 # Copyright 2019 (C) Texas Instruments Inc.
 # Copyright 2013 (C) O.S. Systems Software LTDA.
 
+FEATURES_CHECK_INCLUDE_STACK := "${BBINCLUDESTACK}"
+
 python () {
 if d.getVar('PARSE_ALL_RECIPES', False):
 return
 
+unused = True
+
 for kind in ['DISTRO', 'MACHINE', 'COMBINED']:
+if d.getVar('ANY_OF_' + kind + '_FEATURES') is None and \
+   d.overridedata.get('ANY_OF_' + kind + '_FEATURES') is None and \
+   d.getVar('REQUIRED_' + kind + '_FEATURES') is None and \
+   d.overridedata.get('REQUIRED_' + kind + '_FEATURES') is None and \
+   d.getVar('CONFLICT_' + kind + '_FEATURES') is None and \
+   d.overridedata.get('CONFLICT_' + kind + '_FEATURES') is None:
+continue
+
+unused = False
+
 # Assume at least one var is set.
 features = set((d.getVar(kind + '_FEATURES') or '').split())
 
@@ -39,4 +53,10 @@ python () {
 if conflicts:
 raise bb.parse.SkipRecipe("conflicting %s feature%s '%s' (in 
%s_FEATURES)"
 % (kind.lower(), 's' if len(conflicts) > 1 else '', ' 
'.join(conflicts), kind))
+
+# Only warn if inherited directly in a .bb-file; if the class is inherited
+# via an .inc/.bbclass it could be a false positive
+inherited_from_bb = 
d.getVar('FEATURES_CHECK_INCLUDE_STACK').split()[-1].endswith('.bb')
+if unused and inherited_from_bb:
+bb.warn("Recipe inherits features_check but doesn't use it")
 }
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


[OE-core] [RFC][PATCH 2/2] Don't inherit 'features_check' in recipes that don't utilize it

2020-06-09 Thread Jacob Kroon
Signed-off-by: Jacob Kroon 
---
 meta/recipes-bsp/usbutils/usbutils_012.bb | 2 +-
 meta/recipes-core/libxml/libxml2_2.9.10.bb| 2 +-
 meta/recipes-devtools/mtools/mtools_4.0.24.bb | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-bsp/usbutils/usbutils_012.bb 
b/meta/recipes-bsp/usbutils/usbutils_012.bb
index b670fa4ab6..28031e72a7 100644
--- a/meta/recipes-bsp/usbutils/usbutils_012.bb
+++ b/meta/recipes-bsp/usbutils/usbutils_012.bb
@@ -15,7 +15,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/usb/usbutils/usbutils-${PV}.tar.gz \
 SRC_URI[md5sum] = "7484445cbcf04b3eacac892fe58f8d9f"
 SRC_URI[sha256sum] = 
"ae2e10aad530d95839b6f4d46cd41715eae6f0f1789310d793e9be21b3e7ae20"
 
-inherit autotools pkgconfig features_check update-alternatives
+inherit autotools pkgconfig update-alternatives
 
 ALTERNATIVE_${PN} = "lsusb"
 ALTERNATIVE_PRIORITY = "100"
diff --git a/meta/recipes-core/libxml/libxml2_2.9.10.bb 
b/meta/recipes-core/libxml/libxml2_2.9.10.bb
index 097aceb2c0..d11b083e8b 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.10.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.10.bb
@@ -37,7 +37,7 @@ PACKAGECONFIG ??= "python \
 PACKAGECONFIG[python] = "--with-python=${PYTHON},--without-python,python3"
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
 
-inherit autotools pkgconfig binconfig-disabled ptest features_check
+inherit autotools pkgconfig binconfig-disabled ptest
 
 inherit ${@bb.utils.contains('PACKAGECONFIG', 'python', 'python3native', '', 
d)}
 
diff --git a/meta/recipes-devtools/mtools/mtools_4.0.24.bb 
b/meta/recipes-devtools/mtools/mtools_4.0.24.bb
index d7cc72d172..f11cdad37a 100644
--- a/meta/recipes-devtools/mtools/mtools_4.0.24.bb
+++ b/meta/recipes-devtools/mtools/mtools_4.0.24.bb
@@ -35,7 +35,7 @@ SRC_URI = "${GNU_MIRROR}/mtools/mtools-${PV}.tar.bz2 \
 
 SRC_URI_append_class-native = " file://disable-hardcoded-configs.patch"
 
-inherit autotools texinfo features_check
+inherit autotools texinfo
 
 EXTRA_OECONF = "--without-x"
 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


[OE-core] ✗ patchtest: failure for glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: add nativesdk support (rev2)

2020-06-09 Thread Patchwork
== Series Details ==

Series: glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: 
add nativesdk support (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/24546/
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[V2] 
glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: add 
nativesdk support
 Issue Commit shortlog is too long [test_shortlog_length] 
  Suggested fixEdit shortlog so that it is 90 characters or less (currently 
91 characters)



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

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

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

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


[OE-core] [PATCH V2] glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: add nativesdk support

2020-06-09 Thread hongxu
In order to make wic tool work in sdk which is out of an
existed Yocto build, it needs to port wic tool as a nativesdk
recipe.

First, make these runtime depends recipes to support nativesdk

Signed-off-by: Hongxu Jia 
---
 meta/recipes-core/glib-networking/glib-networking_2.64.3.bb | 2 +-
 meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb  | 2 +-
 meta/recipes-devtools/dosfstools/dosfstools_4.1.bb  | 2 +-
 meta/recipes-extended/parted/parted_3.3.bb  | 2 +-
 meta/recipes-support/bmap-tools/bmap-tools_3.5.bb   | 2 +-
 meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb  | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-core/glib-networking/glib-networking_2.64.3.bb 
b/meta/recipes-core/glib-networking/glib-networking_2.64.3.bb
index a79e0e4988..c34ae508f6 100644
--- a/meta/recipes-core/glib-networking/glib-networking_2.64.3.bb
+++ b/meta/recipes-core/glib-networking/glib-networking_2.64.3.bb
@@ -31,4 +31,4 @@ FILES_${PN} += "\
 FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la"
 FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb 
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb
index 885d79dcdc..29f14d9077 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb
@@ -49,4 +49,4 @@ do_install_append() {
 fi
 }
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb 
b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
index 23b8836670..97ce449954 100644
--- a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
+++ b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
@@ -22,7 +22,7 @@ EXTRA_OECONF = "--without-udev --enable-compat-symlinks"
 
 CFLAGS += "-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
 
 # Add codepage437 to avoid error from `dosfsck -l`
 RRECOMMENDS_${PN}_append_libc-glibc = " glibc-gconv-ibm437"
diff --git a/meta/recipes-extended/parted/parted_3.3.bb 
b/meta/recipes-extended/parted/parted_3.3.bb
index 1cfd9ec264..aa4d8042cf 100644
--- a/meta/recipes-extended/parted/parted_3.3.bb
+++ b/meta/recipes-extended/parted/parted_3.3.bb
@@ -22,7 +22,7 @@ EXTRA_OECONF = "--disable-device-mapper"
 
 inherit autotools pkgconfig gettext texinfo ptest
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
 
 do_compile_ptest() {
oe_runmake -C tests print-align print-max dup-clobber duplicate 
fs-resize print-flags
diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb 
b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
index 694c5f09be..fd57f8f7f0 100644
--- a/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
+++ b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
@@ -22,4 +22,4 @@ RDEPENDS_${PN} = "python3-core python3-compression 
python3-mmap python3-setuptoo
 inherit python3native
 inherit setuptools3
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb 
b/meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb
index d10db7940a..d6425bd941 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb
@@ -40,4 +40,4 @@ DEBIAN_NOAUTONAME_${PN} = "1"
 # glib-networking is needed for SSL, proxies, etc.
 RRECOMMENDS_${PN} = "glib-networking"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
2.18.2

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

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


Re: [OE-core] [PATCH] remove unused DEPLOY_DIR_TOOLS variable from bitbake.conf

2020-06-09 Thread Ross Burton
On Mon, 8 Jun 2020 at 21:15, Enrico J?rns  wrote:

> What is the now suggested way of placing these kind of binaries? Simply in 
> DEPLOY_DIR_IMAGES as the above-mentioned commit does (silently)?
> Or is there maybe still some motivation to keep DEPLOY_DIR_TOOLS?

FWIW, meta-arm is also using DEPLOY_DIR_TOOLS and to fix builds with
master is now manually using DEPLOY_DIR/tools because having a
separate directory does help introduce some structure.

Basically, I'd actually like to see this reverted.

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

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


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

2020-06-09 Thread Joshua Watt


On 6/8/20 6:11 PM, Denys Dmytriyenko wrote:

Not sure if it's related to this change, but I've been seeing this error
across the platforms in master past few days:

WARNING: bootloader config not specified, using defaults

Traceback (most recent call last):
   File "/OE/poky-master-build/sources/poky/scripts/wic", line 540, in 
 sys.exit(main(sys.argv[1:]))
   File "/OE/poky-master-build/sources/poky/scripts/wic", line 535, in main
 return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage, subcommands)
   File "/OE/poky-master-build/sources/poky/scripts/lib/wic/help.py", line 83, 
in invoke_subcommand
 subcmd[0](args, usage)
   File "/OE/poky-master-build/sources/poky/scripts/wic", line 219, in 
wic_create_subcommand
 engine.wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
   File "/OE/poky-master-build/sources/poky/scripts/lib/wic/engine.py", line 
190, in wic_create
 plugin.do_create()
   File 
"/OE/poky-master-build/sources/poky/scripts/lib/wic/plugins/imager/direct.py", 
line 86, in do_create
 self.create()
   File 
"/OE/poky-master-build/sources/poky/scripts/lib/wic/plugins/imager/direct.py", 
line 179, in create
 self._image.prepare(self)
   File 
"/OE/poky-master-build/sources/poky/scripts/lib/wic/plugins/imager/direct.py", 
line 352, in prepare
 part.prepare(imager, imager.workdir, imager.oe_builddir,
   File "/OE/poky-master-build/sources/poky/scripts/lib/wic/partition.py", line 
175, in prepare
 plugin.do_prepare_partition(self, srcparams_dict, creator,
   File 
"/OE/poky-master-build/sources/poky/scripts/lib/wic/plugins/source/bootimg-partition.py",
 line 193, in do_prepare_partition
 part.prepare_rootfs(cr_workdir, oe_builddir, hdddir,
   File "/OE/poky-master-build/sources/poky/scripts/lib/wic/partition.py", line 
238, in prepare_rootfs
 method(rootfs, oe_builddir, rootfs_dir, native_sysroot, pseudo)
   File "/OE/poky-master-build/sources/poky/scripts/lib/wic/partition.py", line 
305, in prepare_rootfs_msdos
 rootfs_size = self.get_rootfs_size(blocks)
   File "/OE/poky-master-build/sources/poky/scripts/lib/wic/partition.py", line 
100, in get_rootfs_size
 if extra_blocks < self.extra_space:
TypeError: '<' not supported between instances of 'int' and 'function'
WARNING: 
/OE/poky-master-build/build-CORTEX_1/arago-tmp/work/am335x_evm-poky-linux-gnueabi/core-image-base/1.0-r0/temp/run.do_image_wic.3266:1
 exit 1 from 'BUILDDIR="/OE/poky-master-build/build-CORTEX_1" PSEUDO_UNLOAD=1 wic create "$wks" --vars 
"/OE/poky-master-build/build-CORTEX_1/arago-tmp/sysroots/am335x-evm/imgdata/" -e "core-image-base" -o 
"$build_wic/"'
ERROR: Execution of 
'/OE/poky-master-build/build-CORTEX_1/arago-tmp/work/am335x_evm-poky-linux-gnueabi/core-image-base/1.0-r0/temp/run.do_image_wic.3266'
 failed with exit code 1:

Any clues? Has anyone seen anything like that?


Yes, this is because of my change to add --offset support. I'm not sure 
how that slipped past, but I'm working on a patch to fix it.




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

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


Re: [OE-core] [PATCH] qemu: fix CVE-2020-13361

2020-06-09 Thread Lee Chee Yang
Ping 

-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Lee Chee Yang
Sent: Monday, June 1, 2020 9:41 PM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] qemu: fix CVE-2020-13361

From: Lee Chee Yang 

Signed-off-by: Lee Chee Yang 
---
 meta/recipes-devtools/qemu/qemu.inc|  1 +
 .../qemu/qemu/CVE-2020-13361.patch | 61 ++
 2 files changed, 62 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13361.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 126e7d4..3e50069 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -38,6 +38,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
   file://0001-qemu-Do-not-include-file-if-not-exists.patch \
file://CVE-2020-11102.patch \
   file://CVE-2020-11869.patch \
+  file://CVE-2020-13361.patch \
   "
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13361.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-13361.patch
new file mode 100644
index 000..e0acc70
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-13361.patch
@@ -0,0 +1,61 @@
+From 369ff955a8497988d079c4e3fa1e93c2570c1c69 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Fri, 15 May 2020 01:36:08 +0530
+Subject: [PATCH] es1370: check total frame count against current frame
+
+A guest user may set channel frame count via es1370_write() such that, 
+in es1370_transfer_audio(), total frame count 'size' is lesser than the 
+number of frames that are processed 'cnt'.
+
+int cnt = d->frame_cnt >> 16;
+int size = d->frame_cnt & 0x;
+
+if (size < cnt), it results in incorrect calculations leading to OOB 
+access issue(s). Add check to avoid it.
+
+Reported-by: Ren Ding 
+Reported-by: Hanqing Zhao 
+Signed-off-by: Prasad J Pandit 
+Message-id: 20200514200608.1744203-1-ppan...@redhat.com
+Signed-off-by: Gerd Hoffmann 
+
+Upstream-Status: Backport 
+[https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg03983.html]
+CVE: CVE-2020-13361
+Signed-off-by: Chee Yang Lee 
+---
+ hw/audio/es1370.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/hw/audio/es1370.c b/hw/audio/es1370.c index 
+89c4dabcd44..5f8a83ff562 100644
+--- a/hw/audio/es1370.c
 b/hw/audio/es1370.c
+@@ -643,6 +643,9 @@ static void es1370_transfer_audio (ES1370State *s, struct 
chan *d, int loop_sel,
+ int csc_bytes = (csc + 1) << d->shift;
+ int cnt = d->frame_cnt >> 16;
+ int size = d->frame_cnt & 0x;
++if (size < cnt) {
++return;
++}
+ int left = ((size - cnt + 1) << 2) + d->leftover;
+ int transferred = 0;
+ int temp = MIN (max, MIN (left, csc_bytes)); @@ -651,7 +654,7 @@ 
+static void es1370_transfer_audio (ES1370State *s, struct chan *d, int 
loop_sel,
+ addr += (cnt << 2) + d->leftover;
+ 
+ if (index == ADC_CHANNEL) {
+-while (temp) {
++while (temp > 0) {
+ int acquired, to_copy;
+ 
+ to_copy = MIN ((size_t) temp, sizeof (tmpbuf)); @@ -669,7 
++672,7 @@ static void es1370_transfer_audio (ES1370State *s, struct chan *d, 
int loop_sel,
+ else {
+ SWVoiceOut *voice = s->dac_voice[index];
+ 
+-while (temp) {
++while (temp > 0) {
+ int copied, to_copy;
+ 
+ to_copy = MIN ((size_t) temp, sizeof (tmpbuf));
--
2.7.4

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

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


Re: [OE-core] [master][dunfell] Revert "prservice.py: fix do_package with newer Python in Ubuntu 20.04"

2020-06-09 Thread Richard Purdie
On Tue, 2020-06-09 at 13:22 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Fri, 2020-06-05 at 17:50 +0200, Peter Kjellerstedt wrote:
> > This reverts commit 4b26eaf7152fb712aba47a0c746333578f58ee8d.
> > 
> > Since the problem occurred while importing prserv, the solution has
> > been moved into it instead so it is solved for all cases where
> > prserv
> > is imported, most notably when using devtool.
> > 
> > Signed-off-by: Peter Kjellerstedt 
> 
> I can see why you've done this however it really is a bit of a hack
> :(.
> 
> At least in this code its all together with the OE code which uses
> it.
> With it moved into bitbake, its moving "OE" knowledge over there and
> that worries me a lot as people won't find it when changing OE-Core.
> 
> Chris did have some ideas about this which seemed on the right track:
> 
> https://lists.yoctoproject.org/g/yocto/message/49571
> 
> although it seems that solution didn't work.
> 
> I'd like to better understand this issue before we merge things to
> bitbake.

btw, the better question to ask is why is python3-native being used to
execute bitbake code? 

I think the wrong PATH is being used somewhere in devtool. The real fix
is to track down where that is.

Cheers,

Richard

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

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


Re: [OE-core] [master][dunfell] Revert "prservice.py: fix do_package with newer Python in Ubuntu 20.04"

2020-06-09 Thread Richard Purdie
On Fri, 2020-06-05 at 17:50 +0200, Peter Kjellerstedt wrote:
> This reverts commit 4b26eaf7152fb712aba47a0c746333578f58ee8d.
> 
> Since the problem occurred while importing prserv, the solution has
> been moved into it instead so it is solved for all cases where prserv
> is imported, most notably when using devtool.
> 
> Signed-off-by: Peter Kjellerstedt 

I can see why you've done this however it really is a bit of a hack :(.

At least in this code its all together with the OE code which uses it.
With it moved into bitbake, its moving "OE" knowledge over there and
that worries me a lot as people won't find it when changing OE-Core.

Chris did have some ideas about this which seemed on the right track:

https://lists.yoctoproject.org/g/yocto/message/49571

although it seems that solution didn't work.

I'd like to better understand this issue before we merge things to
bitbake.

Cheers,

Richard

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

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


[OE-core] [PATCH] mesa: use x11 as egl_native_platform when the configure argument "platforms" contains x11

2020-06-09 Thread quanyang.wang
From: Quanyang Wang 

This fixes an issue that the mesa egl library detecting the wrong
platform type.

Signed-off-by: Quanyang Wang 
---
When mesa update from 19.1 to 20.0, there is an issue that the mesa egl
will detect the wrong platform type, this issue results that in the sato
X11 window system all opengl/opengles apps by using egl run into
"Segmentation fault".

I have filed a bug to mesa community:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3075#note_519060
Until now there is no response from the developers.

There are several solutions to resolve it:
1) When running an openg/opengles app in sato, export
EGL_PLATFORM="x11".
2) Adjust the configure argument order in mesa.inc to make 
"-Dplatforms=wayland,x11,drm,surfaceless"
to be "-Dplatforms=x11,wayland,drm,surfaceless" to dodge this issue.
3) Apply this patch for a workaround then waiting for mesa development
community to work out a perfect solution.

 ...-egl_native_platform-when-the-config.patch | 57 +++
 meta/recipes-graphics/mesa/mesa.inc   |  1 +
 2 files changed, 58 insertions(+)
 create mode 100644 
meta/recipes-graphics/mesa/files/0001-meson-use-x11-as-egl_native_platform-when-the-config.patch

diff --git 
a/meta/recipes-graphics/mesa/files/0001-meson-use-x11-as-egl_native_platform-when-the-config.patch
 
b/meta/recipes-graphics/mesa/files/0001-meson-use-x11-as-egl_native_platform-when-the-config.patch
new file mode 100644
index 00..825dc988a0
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/files/0001-meson-use-x11-as-egl_native_platform-when-the-config.patch
@@ -0,0 +1,57 @@
+From 8fe9af6ba8477f6a3d7a85168bb47e7d953d090c Mon Sep 17 00:00:00 2001
+From: Quanyang Wang 
+Date: Tue, 9 Jun 2020 10:59:47 +0800
+Subject: [PATCH] meson: use x11 as egl_native_platform when the configure
+ argument "platforms" contains x11
+
+When mesa is configured with argument 
"-Dplatforms=wayland,x11,drm,surfaceless",
+in meson.build, the "wayland" is the first element of "platforms" and the
+"egl_native_platform" will be "wayland", then in src/egl/meson.build,
+_EGL_NATIVE_PLATFORM will be assigned to be _EGL_NATIVE_WAYLAND. And in the
+commit 86d3a346 ("egl: fix _EGL_NATIVE_PLATFORM fallback"), the function
+_eglNativePlatformDetectNativeDisplay delete the return value _EGL_PLATFORM_X11
+when detecting "wayland" and "gbm" failed, this will result that in 
_eglGetNativePlatform
+the platform type will be _EGL_NATIVE_PLATFORM which is equal to be 
_EGL_NATIVE_WAYLAND
+even if the app runs at a "X11" platform.
+
+So when an X11 app using egl:
+x_dpy = XOpenDisplay(NULL);
+...
+dpy = eglGetDisplay((EGLNativeDisplayType) x_dpy);
+eglGetDisplay will run into crash because libEGL.so detected the wrong 
platform type.
+
+root@genericx86-64:~# export DISPLAY=:0
+root@genericx86-64:~# eglgears_x11
+Segmentation fault
+
+When apps run at wayland or gbm platform, eglGetDisplay can detect the 
platform type
+automatically, but x11 can't. So use x11 as egl_native_platform when the 
configure
+argument "platforms" contains x11.
+
+Upstream-Status: Pending
+
+Signed-off-by: Quanyang Wang 
+---
+ meson.build | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index b25fa19..ae95e73 100644
+--- a/meson.build
 b/meson.build
+@@ -307,7 +307,11 @@ if _platforms.length() != 0 and _platforms != ['']
+ error('Invalid argument list given to -Dplatforms, please fix.')
+   endif
+   with_platforms = true
+-  egl_native_platform = _platforms[0]
++  if with_platform_x11
++egl_native_platform = 'x11'
++  else
++egl_native_platform = _platforms[0]
++  endif
+ endif
+ 
+ _xlib_lease = get_option('xlib-lease')
+-- 
+2.17.1
+
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 965e12d17e..ccaf42f9ad 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -21,6 +21,7 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \

file://0004-Revert-mesa-Enable-asm-unconditionally-now-that-gen_.patch \

file://0005-vc4-use-intmax_t-for-formatted-output-of-timespec-me.patch \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
+   
file://0001-meson-use-x11-as-egl_native_platform-when-the-config.patch \
"
 
 SRC_URI[md5sum] = "609cb7664204e031d4c65c602c652a28"
-- 
2.17.1

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

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


[OE-core] kernel: update rpm failed for the vfat

2020-06-09 Thread Xu, Yanfei

Hi Bruce,

I encountered an issue that updating kernel rpm package will fail when 
the /boot dir was mount with vfat filesystem. The root cause is vfat 
don't support symlink.

cut here--
error: unpacking of archive failed on file /boot/Image;5eda8385: cpio: 
symlink failed - Resource temporarily unavailable
error: 
kernel-image-image-5.4.43-yocto-standard-5.4.x+git0+f8c88c4331_9961cc8b79-r0.bcm_2xxx_rpi4: 
install failed

root@bcm-2xxx-rpi4:/boot#

Currently I have two ideas to fix it:
1. we use 'install' cmd instead of 'ln -sf' in kernel_do_install to 
avoid generating symlink in kernel-image-image*.rpm. And then add an 
postinstall to this rpm. It will check if the /boot dir is vfat, if not, 
we remove the copy image* and make a softlink for the image.
2. we specially add an package type which doesn't contain symlink for 
the vfat filesystem.


For the first idea, I met an problem when I try to add 
pkg_postinst_packagename function in kernel.bbclass file. Due to there 
are not package name variables defined for the kernel-image-image.gz 
kernel-image-image or other type kernel images. So I can not add 
postinst functions statically why that how many packages and packages' 
name are not certainly.


Do you have any opinions about these?


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

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


Re: [OE-core] devtool and multiconfig: Bug or feature?

2020-06-09 Thread Richard Purdie
On Mon, 2020-06-08 at 16:40 +0200, Ricardo Ribalda wrote:
> Hi
> 
> I am trying to use devtool in combination with multiconfig for the
> first time, so probably I am doing something wrong.
> 
> I have created a very simple multiconfig
> 
> cat build/conf/multiconfig/arm.conf
> MACHINE = "qemuarm"
> 
> And then I want to modify bash:
> devtool modify multiconfig:arm:bash
> 
> If then I try to run:
> devtool build multiconfig:arm:bash
> NOTE: Starting bitbake server...
> ERROR: No recipe named 'multiconfig:arm:bash' in your workspace
> 
> So I run:
> devtool build bash
> 
> But that builds for x86 instead of for arm...
> 
> Simply patching check_workspace_recipe does not do the trick:
> @@ -145,6 +145,8 @@ def check_workspace_recipe(workspace, pn,
> checksrc=True, bbclassextend=False):
>  is present.
>  """
> 
> +pn = pn.split(":")[-1]
> +
>  workspacepn = pn
> 
>  for recipe, value in workspace.items():
> 
> 
> Any idea or documentation to follow?

I think this is something which hasn't been tested before. Its a bug
but nobody has probably tested or fixed devtool to work with
multiconfig.

Cheers,

Richard

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

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


[OE-core] ✗ patchtest: failure for glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: add nativesdk support

2020-06-09 Thread Patchwork
== Series Details ==

Series: glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: 
add nativesdk support
Revision: 1
URL   : https://patchwork.openembedded.org/series/24546/
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
glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: add 
nativesdk support
 Issue Commit shortlog is too long [test_shortlog_length] 
  Suggested fixEdit shortlog so that it is 90 characters or less (currently 
91 characters)



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

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

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

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


[OE-core] [PATCH] glib-networking/btrfs-tools/dosfstools/parted/bmap-tools/libsoup-2.4: add nativesdk support

2020-06-09 Thread hongxu
Signed-off-by: Hongxu Jia 
---
 meta/recipes-core/glib-networking/glib-networking_2.64.3.bb | 2 +-
 meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb  | 2 +-
 meta/recipes-devtools/dosfstools/dosfstools_4.1.bb  | 2 +-
 meta/recipes-extended/parted/parted_3.3.bb  | 2 +-
 meta/recipes-support/bmap-tools/bmap-tools_3.5.bb   | 2 +-
 meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb  | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-core/glib-networking/glib-networking_2.64.3.bb 
b/meta/recipes-core/glib-networking/glib-networking_2.64.3.bb
index a79e0e4988..c34ae508f6 100644
--- a/meta/recipes-core/glib-networking/glib-networking_2.64.3.bb
+++ b/meta/recipes-core/glib-networking/glib-networking_2.64.3.bb
@@ -31,4 +31,4 @@ FILES_${PN} += "\
 FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la"
 FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb 
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb
index 885d79dcdc..29f14d9077 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_5.6.1.bb
@@ -49,4 +49,4 @@ do_install_append() {
 fi
 }
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb 
b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
index 23b8836670..97ce449954 100644
--- a/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
+++ b/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb
@@ -22,7 +22,7 @@ EXTRA_OECONF = "--without-udev --enable-compat-symlinks"
 
 CFLAGS += "-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
 
 # Add codepage437 to avoid error from `dosfsck -l`
 RRECOMMENDS_${PN}_append_libc-glibc = " glibc-gconv-ibm437"
diff --git a/meta/recipes-extended/parted/parted_3.3.bb 
b/meta/recipes-extended/parted/parted_3.3.bb
index 1cfd9ec264..aa4d8042cf 100644
--- a/meta/recipes-extended/parted/parted_3.3.bb
+++ b/meta/recipes-extended/parted/parted_3.3.bb
@@ -22,7 +22,7 @@ EXTRA_OECONF = "--disable-device-mapper"
 
 inherit autotools pkgconfig gettext texinfo ptest
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
 
 do_compile_ptest() {
oe_runmake -C tests print-align print-max dup-clobber duplicate 
fs-resize print-flags
diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb 
b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
index 694c5f09be..fd57f8f7f0 100644
--- a/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
+++ b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
@@ -22,4 +22,4 @@ RDEPENDS_${PN} = "python3-core python3-compression 
python3-mmap python3-setuptoo
 inherit python3native
 inherit setuptools3
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb 
b/meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb
index d10db7940a..d6425bd941 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.70.0.bb
@@ -40,4 +40,4 @@ DEBIAN_NOAUTONAME_${PN} = "1"
 # glib-networking is needed for SSL, proxies, etc.
 RRECOMMENDS_${PN} = "glib-networking"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
2.18.2

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

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


Re: [OE-core] [meta-oe][PATCH] igt-gpu-tools: add new package

2020-06-09 Thread Alexander Kanavin
This should be sent to oe-devel list.

Alex

On Tue 9. Jun 2020 at 7.43, Arthur She  wrote:

> igt-gpu-tools is a collection of tools for development and testing of the
> DRM
> drivers. (https://gitlab.freedesktop.org/drm/igt-gpu-tools)
>
> Signed-off-by: Arthur She 
> ---
>  .../igt-gpu-tools/igt-gpu-tools_git.bb| 46 +++
>  1 file changed, 46 insertions(+)
>  create mode 100644 meta-oe/recipes-graphics/igt-gpu-tools/
> igt-gpu-tools_git.bb
>
> diff --git a/meta-oe/recipes-graphics/igt-gpu-tools/igt-gpu-tools_git.bb
> b/meta-oe/recipes-graphics/igt-gpu-tools/igt-gpu-tools_git.bb
> new file mode 100644
> index 0..761df1cbb
> --- /dev/null
> +++ b/meta-oe/recipes-graphics/igt-gpu-tools/igt-gpu-tools_git.bb
> @@ -0,0 +1,46 @@
> +SUMMARY = "IGT GPU Tools"
> +DESCRIPTION = "IGT GPU Tools is a collection of tools for development and
> testing of the DRM drivers"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=67bfee4df38fa6ecbe3a675c552d4c08"
> +
> +LICENSE_append = " & ISC"
> +
> +inherit meson gtk-doc
> +
> +SRCREV = "${AUTOREV}"
> +
> +SRC_URI = "git://
> gitlab.freedesktop.org/drm/igt-gpu-tools.git;protocol=https"
> +
> +S = "${WORKDIR}/git"
> +
> +DEPENDS += "libdrm libpciaccess cairo udev glib-2.0 procps libunwind kmod
> openssl xmlrpc-c gsl elfutils alsa-lib json-c bison-native"
> +RDEPENDS_${PN} += "bash python3-mako python3-six git net-snmp"
> +
> +PACKAGE_BEFORE_PN = "${PN}-benchmarks"
> +
> +EXTRA_OEMESON = "-Ddocs=disabled -Drunner=enabled -Dchamelium=enabled"
> +COMPATIBLE_HOST = "(x86_64.*|i.86.*|arm.*|aarch64).*-linux"
> +COMPATIBLE_HOST_libc-musl_class-target = "null"
> +
> +gputools_sysroot_preprocess() {
> +   rm -f ${SYSROOT_DESTDIR}${libdir}/pkgconfig/intel-gen4asm.pc
> +}
> +SYSROOT_PREPROCESS_FUNCS += "gputools_sysroot_preprocess"
> +
> +do_install_append() {
> +install -d ${D}/usr/share/${BPN}/scripts
> +install ${S}/scripts/run-tests.sh ${D}/usr/share/${BPN}/scripts
> +install -d ${D}/usr/share/${BPN}/runner
> +install -D ${B}/runner/igt_runner ${D}/usr/share/${BPN}/runner
> +install -D ${B}/runner/igt_resume ${D}/usr/share/${BPN}/runner
> +}
> +
> +FILES_${PN} += "\
> +${libexecdir}/${BPN}/*\
> +${libdir}/intel_aubdump.so \
> +${datadir}/${BPN}/1080p-right.png \
> +${datadir}/${BPN}/1080p-left.png \
> +${datadir}/${BPN}/pass.png \
> +${datadir}/${BPN}/test-list.txt \
> +${libexecdir}/${BPN}/benchmarks \
> +"
> --
> 2.25.1
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


Re: [OE-core] [PATCH] virglrenderer: correct REQUIRED_DISTRO_FEATURES

2020-06-09 Thread Alexander Kanavin
Please explain why?

Alex

On Tue 9. Jun 2020 at 9.17, Yu, Mingli  wrote:

> From: Mingli Yu 
>
> Add opengl to REQUIRED_DISTRO_FEATURES only for target build.
>
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
> b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
> index 29b12628d0..d97f0e78f1 100644
> --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
> +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
> @@ -21,4 +21,4 @@ inherit meson pkgconfig features_check
>
>  BBCLASSEXTEND = "native nativesdk"
>
> -REQUIRED_DISTRO_FEATURES = "opengl"
> +REQUIRED_DISTRO_FEATURES_class-target = "opengl"
> --
> 2.24.1
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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


Re: [OE-core] [PATCH V2] armv8/tunes: Set TUNE_PKGARCH_64 based on ARMPKGARCH

2020-06-09 Thread Alejandro Hernandez
Hello Khem,


On Tue, 26 May 2020 at 16:10, Khem Raj  wrote:

> The setting is to modify TUNE_PKGARCH which is filled with
> TUNE_PKGARCH_64 or TUNE_PKGARCH_32 in arm-arch64.inc
> This lets higher up tune files for arm64 SOCs override them if needed,
> this can help building multiple armv8 machines with different tunes in
> same workspace.
>
> No need to set TUNE_PKGARCH in tune files as it is synthesized from
> ARMPKGARCH
>
> Add ARMPKGARCH for aarch64 tunes
>
> Signed-off-by: Khem Raj 
> Signed-off-by: Richard Purdie 
> ---
> v2: Differentiate triplet for crypto feature
>
>  meta/conf/machine/include/arm/arch-arm64.inc   | 4 +++-
>  meta/conf/machine/include/tune-cortexa53.inc   | 5 +
>  meta/conf/machine/include/tune-cortexa55.inc   | 1 -
>  meta/conf/machine/include/tune-cortexa57-cortexa53.inc | 1 -
>  meta/conf/machine/include/tune-cortexa57.inc   | 4 +---
>  meta/conf/machine/include/tune-cortexa72-cortexa53.inc | 4 +---
>  meta/conf/machine/include/tune-cortexa72.inc   | 1 -
>  meta/conf/machine/include/tune-cortexa73-cortexa53.inc | 4 +---
>  8 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc
> b/meta/conf/machine/include/arm/arch-arm64.inc
> index 53f4566815..6d5b22fff0 100644
> --- a/meta/conf/machine/include/arm/arch-arm64.inc
> +++ b/meta/conf/machine/include/arm/arch-arm64.inc
> @@ -12,6 +12,8 @@ ARMPKGARCH_tune-aarch64 ?= "aarch64"
>  ARMPKGARCH_tune-aarch64_be ?= "aarch64_be"
>  TUNE_FEATURES_tune-aarch64 = "aarch64"
>  TUNE_FEATURES_tune-aarch64_be = "${TUNE_FEATURES_tune-aarch64} bigendian"
> +TUNE_PKGARCH_64_tune-aarch64 = "aarch64"
> +TUNE_PKGARCH_64_tune-aarch64_be = "aarch64_be"
>


I'm trying to accommodate my machines to the TUNE_PKGARCH changes and I'm a
bit confused by looking at the way these variables are now set.

The way these overrides are behaving, is this meant to be desired behavior?

# $TUNE_PKGARCH [9 operations]
...
override[64_tune-aarch64]:set
/poky/meta/conf/machine/include/arm/arch-arm64.inc:15
# "aarch64"
#   override[64_tune-aarch64_be]:set
/oky/meta/conf/machine/include/arm/arch-arm64.inc:16
# "aarch64_be"

Is the 64_tune_aarch64 meant to be an override for TUNE_PKGARCH or is that
supposed to be set for the TUNE_PKGARCH_64 variable instead?

Cheers,

Alejandro





>  BASE_LIB_tune-aarch64 = "lib64"
>  BASE_LIB_tune-aarch64_be = "lib64"
>
> @@ -20,7 +22,7 @@ PACKAGE_EXTRA_ARCHS_tune-aarch64_be = "aarch64_be"
>
>  ARMPKGSFX_ENDIAN_64 = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian',
> '_be', '', d)}"
>  TUNE_ARCH_64 = "aarch64${ARMPKGSFX_ENDIAN_64}"
> -TUNE_PKGARCH_64 = "aarch64${ARMPKGSFX_ENDIAN_64}"
> +TUNE_PKGARCH_64 = "${ARMPKGARCH}${ARMPKGSFX_ENDIAN_64}"
>  ABIEXTENSION_64 = ""
>  TARGET_FPU_64 = ""
>
> diff --git a/meta/conf/machine/include/tune-cortexa53.inc
> b/meta/conf/machine/include/tune-cortexa53.inc
> index b7327d00c4..c0bb28a19e 100644
> --- a/meta/conf/machine/include/tune-cortexa53.inc
> +++ b/meta/conf/machine/include/tune-cortexa53.inc
> @@ -8,14 +8,11 @@ require conf/machine/include/arm/arch-armv8a.inc
>  # Little Endian base configs
>  AVAILTUNES += "cortexa53 cortexa53-crypto"
>  ARMPKGARCH_tune-cortexa53 = "cortexa53"
> -ARMPKGARCH_tune-cortexa53-crypto  = "cortexa53"
> +ARMPKGARCH_tune-cortexa53-crypto  = "cortexa53-crypto"
>  TUNE_FEATURES_tune-cortexa53  = "aarch64 cortexa53 crc"
>  TUNE_FEATURES_tune-cortexa53-crypto   = "aarch64 cortexa53 crc crypto"
>  PACKAGE_EXTRA_ARCHS_tune-cortexa53 =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa53"
>  PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto  =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa53 cortexa53-crypto"
>
> -TUNE_PKGARCH_tune-cortexa53 = "cortexa53"
> -TUNE_PKGARCH_tune-cortexa53-crypto = "cortexa53-crypto"
> -
>  BASE_LIB_tune-cortexa53   = "lib64"
>  BASE_LIB_tune-cortexa53-crypto= "lib64"
> diff --git a/meta/conf/machine/include/tune-cortexa55.inc
> b/meta/conf/machine/include/tune-cortexa55.inc
> index 274944819e..89032b59ec 100644
> --- a/meta/conf/machine/include/tune-cortexa55.inc
> +++ b/meta/conf/machine/include/tune-cortexa55.inc
> @@ -9,6 +9,5 @@ require conf/machine/include/arm/arch-armv8a.inc
>  AVAILTUNES += "cortexa55"
>  ARMPKGARCH_tune-cortexa55 = "cortexa55"
>  TUNE_FEATURES_tune-cortexa55  = "aarch64 cortexa55 crc crypto"
> -TUNE_PKGARCH_tune-cortexa55   = "cortexa55"
>  PACKAGE_EXTRA_ARCHS_tune-cortexa55=
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55"
>  BASE_LIB_tune-cortexa55   = "lib64"
> diff --git a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
> b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
> index b95d63e86b..ba4b073852 100644
> --- a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
> +++ b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
> @@ -11,6 +11,5 @@ require 

[OE-core] [PATCH] python3-setuptools: add missing rdepends for python3-pkg-resources

2020-06-09 Thread Yu, Mingli
From: Mingli Yu 

Add missing rdepends for python3-pkg-resources to fix below error:
 # python3
 [snip]
 import pkg_resources
 [snip]
 ModuleNotFoundError: No module named 'plistlib'
 ModuleNotFoundError: No module named 'email'

Signed-off-by: Mingli Yu 
---
 meta/recipes-devtools/python/python-setuptools.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/python/python-setuptools.inc 
b/meta/recipes-devtools/python/python-setuptools.inc
index c91cca9f06..032d337424 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -48,6 +48,12 @@ BBCLASSEXTEND = "native nativesdk"
 # minimal distributions.
 PACKAGES =+ "${PYTHON_PN}-pkg-resources "
 FILES_${PYTHON_PN}-pkg-resources = "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
+RDEPENDS_${PYTHON_PN}-pkg-resources = "\
+  ${PYTHON_PN}-compression \
+  ${PYTHON_PN}-email \
+  ${PYTHON_PN}-plistlib \
+  ${PYTHON_PN}-pprint \
+"
 # Due to the way OE-Core implemented native recipes, the native class cannot
 # have a dependency on something that is not a recipe name. Work around that by
 # manually setting RPROVIDES.
-- 
2.24.1

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

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


[OE-core] [PATCH] virglrenderer: correct REQUIRED_DISTRO_FEATURES

2020-06-09 Thread Yu, Mingli
From: Mingli Yu 

Add opengl to REQUIRED_DISTRO_FEATURES only for target build.

Signed-off-by: Mingli Yu 
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb 
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 29b12628d0..d97f0e78f1 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -21,4 +21,4 @@ inherit meson pkgconfig features_check
 
 BBCLASSEXTEND = "native nativesdk"
 
-REQUIRED_DISTRO_FEATURES = "opengl"
+REQUIRED_DISTRO_FEATURES_class-target = "opengl"
-- 
2.24.1

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

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