Re: [OE-core] [PATCH] pypi: set SRC_URI with =, not with +=

2021-06-23 Thread Peter Kjellerstedt 
I suggest you use =+ instead of _prepend to maintain expansion order. I.e., if 
someone does:

inherit pypi

SRC_URI = "http://some_url ${PYPI_SRC_URI}"

However, any way you change it, you risk breaking someone’s use case, but I 
believe using =+ instead of += should be the least invasive change compared to 
the current version.

//Peter

From: openembedded-core@lists.openembedded.org 
 On Behalf Of Alexander Kanavin
Sent: den 23 juni 2021 10:34
To: Konrad Weihmann 
Cc: OE-core 
Subject: Re: [OE-core] [PATCH] pypi: set SRC_URI with =, not with +=

Right, I sent an updated patch.

Alex

On Wed, 23 Jun 2021 at 09:01, Konrad Weihmann 
mailto:kweihm...@outlook.com>> wrote:

That doesn't look completely right to me.

You're absolutely right about devtool expecting the tarball in as the 1st item, 
but this patch here breaks existing recipes like

SRC_URI += "file://some.patch"

inherit pypi

as the patch will now be dropped.



I would suggest to go for SRC_URI_prepend = "${PYPI_SRC_URI} " which fixes the 
issue *and* doesn't break exisiting setups



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153232): 
https://lists.openembedded.org/g/openembedded-core/message/153232
Mute This Topic: https://lists.openembedded.org/mt/83721889/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] cve-check: Add allowlist that is same function of whitelist.

2021-06-23 Thread ito-yui...@fujitsu.com 
The Linux team plan to removed references to racially-charged jargon from
their code for more neutral and inclusive language.
So replace use of "whitelist" with "allowlist" in cve-check.

First, we add CVE_CHECK_ALLOWLIST and it is considered patched as well as
CVE_CHECK_WHITELIST.
We plan to replace about other word later and eventualy, replace all
"whitelist" to "allowlist".

Signed-off-by: Yuichi Ito 
---
 meta/classes/cve-check.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 112ee3379d..5e3441a783 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -52,6 +52,7 @@ CVE_CHECK_PN_WHITELIST ?= ""
 # CVE_CHECK_WHITELIST = 'CVE-2014-2524 CVE-2018-1234'
 #
 CVE_CHECK_WHITELIST ?= ""
+CVE_CHECK_ALLOWLIST ?= ""
 
 # Layers to be excluded
 CVE_CHECK_LAYER_EXCLUDELIST ??= ""
@@ -238,7 +239,7 @@ def check_cves(d, patched_cves):
 old_cve_whitelist =  d.getVar("CVE_CHECK_CVE_WHITELIST")
 if old_cve_whitelist:
 bb.warn("CVE_CHECK_CVE_WHITELIST is deprecated, please use 
CVE_CHECK_WHITELIST.")
-cve_whitelist = d.getVar("CVE_CHECK_WHITELIST").split()
+cve_whitelist = d.getVar("CVE_CHECK_ALLOWLIST").split() + 
d.getVar("CVE_CHECK_WHITELIST").split()
 
 import sqlite3
 db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153231): 
https://lists.openembedded.org/g/openembedded-core/message/153231
Mute This Topic: https://lists.openembedded.org/mt/83733796/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] pypi: set SRC_URI with =, not with +=

2021-06-23 Thread Konrad Weihmann 
That doesn't look completely right to me.

You're absolutely right about devtool expecting the tarball in as the 1st item, 
but this patch here breaks existing recipes like

SRC_URI += "file://some.patch"

inherit pypi

as the patch will now be dropped.

I would suggest to go for SRC_URI_prepend = "${PYPI_SRC_URI} " which fixes the 
issue *and* doesn't break exisiting setups

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153228): 
https://lists.openembedded.org/g/openembedded-core/message/153228
Mute This Topic: https://lists.openembedded.org/mt/83721889/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] pypi: set SRC_URI with _prepend, not with +=

2021-06-23 Thread Alexander Kanavin 
This did not cause problems in builds, but broke some devtool
workflows such as version upgrades or checking the latest version
from upstream. Tarballs should come first, not the patches.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/pypi.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/pypi.bbclass b/meta/classes/pypi.bbclass
index 87b4c85fc0..384a209874 100644
--- a/meta/classes/pypi.bbclass
+++ b/meta/classes/pypi.bbclass
@@ -19,7 +19,7 @@ PYPI_SRC_URI ?= "${@pypi_src_uri(d)}"
 
 HOMEPAGE ?= "https://pypi.python.org/pypi/${PYPI_PACKAGE}/;
 SECTION = "devel/python"
-SRC_URI += "${PYPI_SRC_URI}"
+SRC_URI_prepend = "${PYPI_SRC_URI} "
 S = "${WORKDIR}/${PYPI_PACKAGE}-${PV}"
 
 UPSTREAM_CHECK_URI ?= "https://pypi.org/project/${PYPI_PACKAGE}/;
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153229): 
https://lists.openembedded.org/g/openembedded-core/message/153229
Mute This Topic: https://lists.openembedded.org/mt/83733641/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] pypi: set SRC_URI with =, not with +=

2021-06-23 Thread Alexander Kanavin 
Right, I sent an updated patch.

Alex

On Wed, 23 Jun 2021 at 09:01, Konrad Weihmann  wrote:

> That doesn't look completely right to me.
>
> You're absolutely right about devtool expecting the tarball in as the 1st
> item, but this patch here breaks existing recipes like
>
> SRC_URI += "file://some.patch"
>
> inherit pypi
>
> as the patch will now be dropped.
>
>
>
> I would suggest to go for SRC_URI_prepend = "${PYPI_SRC_URI} " which fixes
> the issue *and* doesn't break exisiting setups
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153230): 
https://lists.openembedded.org/g/openembedded-core/message/153230
Mute This Topic: https://lists.openembedded.org/mt/83721889/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 2/2] kernel.bbclass: inherit kernel_devicetree only if KERNEL_DEVICETREE is set

2021-06-23 Thread Peter Kjellerstedt 
> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Andrea Adami
> Sent: den 23 juni 2021 00:18
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core][PATCH 2/2] kernel.bbclass: inherit kernel_devicetree
> only if KERNEL_DEVICETREE is set
> 
> Now it unconditionally tries to create package kernel-devicetre even for
> legacy devices w/out DT.
> 
> Signed-off-by: Andrea Adami 
> ---
>  meta/classes/kernel.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 06e6446a08..68369e3791 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -779,4 +779,4 @@ addtask deploy after do_populate_sysroot
> do_packagedata
>  EXPORT_FUNCTIONS do_deploy
> 
>  # Add using Device Tree support
> -inherit kernel-devicetree
> +inherit ${@ "" if d.getVar("KERNEL_DEVICETREE" == "") else 
> "kernel-devicetree" }

That doesn't look correct. Don't you mean something like this:

inherit ${@ "kernel-devicetree" if d.getVar("KERNEL_DEVICETREE") else "" }

> --
> 2.17.1

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153233): 
https://lists.openembedded.org/g/openembedded-core/message/153233
Mute This Topic: https://lists.openembedded.org/mt/83725509/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] libva: upgrade 2.11.0 -> 2.12.0

2021-06-23 Thread wangmy 
Signed-off-by: Wang Mingyu 
---
 .../libva/{libva-initial_2.11.0.bb => libva-initial_2.12.0.bb}  | 0
 .../libva/{libva-utils_2.11.1.bb => libva-utils_2.12.0.bb}  | 0
 meta/recipes-graphics/libva/libva.inc   | 2 +-
 .../recipes-graphics/libva/{libva_2.11.0.bb => libva_2.12.0.bb} | 0
 4 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/libva/{libva-initial_2.11.0.bb => 
libva-initial_2.12.0.bb} (100%)
 rename meta/recipes-graphics/libva/{libva-utils_2.11.1.bb => 
libva-utils_2.12.0.bb} (100%)
 rename meta/recipes-graphics/libva/{libva_2.11.0.bb => libva_2.12.0.bb} (100%)

diff --git a/meta/recipes-graphics/libva/libva-initial_2.11.0.bb 
b/meta/recipes-graphics/libva/libva-initial_2.12.0.bb
similarity index 100%
rename from meta/recipes-graphics/libva/libva-initial_2.11.0.bb
rename to meta/recipes-graphics/libva/libva-initial_2.12.0.bb
diff --git a/meta/recipes-graphics/libva/libva-utils_2.11.1.bb 
b/meta/recipes-graphics/libva/libva-utils_2.12.0.bb
similarity index 100%
rename from meta/recipes-graphics/libva/libva-utils_2.11.1.bb
rename to meta/recipes-graphics/libva/libva-utils_2.12.0.bb
diff --git a/meta/recipes-graphics/libva/libva.inc 
b/meta/recipes-graphics/libva/libva.inc
index 43d916cd1c..3d65ac501e 100644
--- a/meta/recipes-graphics/libva/libva.inc
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -18,7 +18,7 @@ LICENSE = "MIT"
 
 SRC_URI = 
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2;
 LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
-SRC_URI[sha256sum] = 
"6e361117038b571ad4741d38c9280db8c140b17e76e8c01fc7a4d608d3ed7d5d"
+SRC_URI[sha256sum] = 
"d3f4873715077a8c969c9bfe4ba8455a133353176be0ffe0c41ffd4155c9a8c8"
 
 S = "${WORKDIR}/libva-${PV}"
 
diff --git a/meta/recipes-graphics/libva/libva_2.11.0.bb 
b/meta/recipes-graphics/libva/libva_2.12.0.bb
similarity index 100%
rename from meta/recipes-graphics/libva/libva_2.11.0.bb
rename to meta/recipes-graphics/libva/libva_2.12.0.bb
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153227): 
https://lists.openembedded.org/g/openembedded-core/message/153227
Mute This Topic: https://lists.openembedded.org/mt/83732232/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] libxcrypt: upgrade 4.4.22 -> 4.4.23

2021-06-23 Thread wangmy 
Signed-off-by: Wang Mingyu 
---
 .../{libxcrypt-compat_4.4.22.bb => libxcrypt-compat_4.4.23.bb}  | 0
 meta/recipes-core/libxcrypt/libxcrypt.inc   | 2 +-
 .../libxcrypt/{libxcrypt_4.4.22.bb => libxcrypt_4.4.23.bb}  | 0
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-core/libxcrypt/{libxcrypt-compat_4.4.22.bb => 
libxcrypt-compat_4.4.23.bb} (100%)
 rename meta/recipes-core/libxcrypt/{libxcrypt_4.4.22.bb => 
libxcrypt_4.4.23.bb} (100%)

diff --git a/meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.22.bb 
b/meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.23.bb
similarity index 100%
rename from meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.22.bb
rename to meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.23.bb
diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc 
b/meta/recipes-core/libxcrypt/libxcrypt.inc
index e4505a666d..79a2aa49d6 100644
--- a/meta/recipes-core/libxcrypt/libxcrypt.inc
+++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSING;md5=afed27a72ae2a8075978299eebaa1f5d \
 inherit autotools pkgconfig
 
 SRC_URI = "git://github.com/besser82/libxcrypt.git;branch=${SRCBRANCH}"
-SRCREV = "3df9620d08db207367c0c5152148665b5ce422e1"
+SRCREV = "5dcc36aeeb053654659e898fd3de7f365c1c4df5"
 SRCBRANCH ?= "develop"
 
 SRC_URI += "file://fix_cflags_handling.patch"
diff --git a/meta/recipes-core/libxcrypt/libxcrypt_4.4.22.bb 
b/meta/recipes-core/libxcrypt/libxcrypt_4.4.23.bb
similarity index 100%
rename from meta/recipes-core/libxcrypt/libxcrypt_4.4.22.bb
rename to meta/recipes-core/libxcrypt/libxcrypt_4.4.23.bb
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153226): 
https://lists.openembedded.org/g/openembedded-core/message/153226
Mute This Topic: https://lists.openembedded.org/mt/83732231/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] python3-numpy: upgrade 1.20.3 -> 1.21.0

2021-06-23 Thread wangmy 
refresh 0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch

License-Updage: Copyright year updated to 2021

Signed-off-by: Wang Mingyu 
---
 ...-and-so-on-for-libraries-by-default-.patch | 19 +--
 ...umpy_1.20.3.bb => python3-numpy_1.21.0.bb} |  4 ++--
 2 files changed, 11 insertions(+), 12 deletions(-)
 rename meta/recipes-devtools/python-numpy/{python3-numpy_1.20.3.bb => 
python3-numpy_1.21.0.bb} (92%)

diff --git 
a/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
 
b/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
index cdb6a473d2..9f5f25f9b5 100644
--- 
a/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
+++ 
b/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
@@ -8,16 +8,15 @@ Subject: [PATCH] Don't search /usr and so on for libraries by 
default to
 Upstream-Status: Inappropriate (As the code stands, this is a hack)
 Signed-off-by: Ross Burton 
 Signed-off-by: Alexander Kanavin 
-
 ---
- numpy/distutils/system_info.py | 42 --
- 1 file changed, 5 insertions(+), 37 deletions(-)
+ numpy/distutils/system_info.py | 42 +-
+ 1 file changed, 6 insertions(+), 36 deletions(-)
 
 diff --git a/numpy/distutils/system_info.py b/numpy/distutils/system_info.py
-index 3a6a7b2..6c2c3da 100644
+index 82e864a..135246d 100644
 --- a/numpy/distutils/system_info.py
 +++ b/numpy/distutils/system_info.py
-@@ -309,45 +309,13 @@ if sys.platform == 'win32':
+@@ -323,44 +323,14 @@ if sys.platform == 'win32':
  add_system_root(os.path.join(conda_dir, 'Library'))
  
  else:
@@ -25,7 +24,7 @@ index 3a6a7b2..6c2c3da 100644
 - '/opt/local/lib', '/sw/lib'], platform_bits)
  default_runtime_dirs = []
 -default_include_dirs = ['/usr/local/include',
--'/opt/include', '/usr/include',
+-'/opt/include',
 -# path of umfpack under macports
 -'/opt/local/include/ufsparse',
 -'/opt/local/include', '/sw/include',
@@ -34,8 +33,7 @@ index 3a6a7b2..6c2c3da 100644
 -
 -default_x11_lib_dirs = libpaths(['/usr/X11R6/lib', '/usr/X11/lib',
 - '/usr/lib'], platform_bits)
--default_x11_include_dirs = ['/usr/X11R6/include', '/usr/X11/include',
--'/usr/include']
+-default_x11_include_dirs = ['/usr/X11R6/include', '/usr/X11/include']
 -
 -if os.path.exists('/usr/lib/X11'):
 -globbed_x11_dir = glob('/usr/lib/*/libX11.so')
@@ -59,15 +57,16 @@ index 3a6a7b2..6c2c3da 100644
 -# gcc supports the "-print-multiarch" option
 -default_x11_lib_dirs += [os.path.join("/usr/lib/", triplet)]
 -default_lib_dirs += [os.path.join("/usr/lib/", triplet)]
+ 
 +default_lib_dirs = libpaths(['/deadir/lib'], platform_bits)
 +default_include_dirs = ['/deaddir/include']
 +default_src_dirs = ['.', '/deaddir/src']
- 
++
 +default_x11_lib_dirs = libpaths(['/deaddir/lib'], platform_bits)
 +default_x11_include_dirs = ['/deaddir/include']
  
  if os.path.join(sys.prefix, 'lib') not in default_lib_dirs:
  default_lib_dirs.insert(0, os.path.join(sys.prefix, 'lib'))
 -- 
-2.17.1
+2.25.1
 
diff --git a/meta/recipes-devtools/python-numpy/python3-numpy_1.20.3.bb 
b/meta/recipes-devtools/python-numpy/python3-numpy_1.21.0.bb
similarity index 92%
rename from meta/recipes-devtools/python-numpy/python3-numpy_1.20.3.bb
rename to meta/recipes-devtools/python-numpy/python3-numpy_1.21.0.bb
index d160fd655b..7ad2f061bf 100644
--- a/meta/recipes-devtools/python-numpy/python3-numpy_1.20.3.bb
+++ b/meta/recipes-devtools/python-numpy/python3-numpy_1.21.0.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "https://numpy.org/;
 DESCRIPTION = "NumPy is the fundamental package needed for scientific 
computing with Python."
 SECTION = "devel/python"
 LICENSE = "BSD-3-Clause & BSD-2-Clause & PSF & Apache-2.0 & BSD & MIT"
-LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=aa1ecaef18152f75bfae546b29c49d3c"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=b076ad374a7d311ba3126a22b2d52596"
 
 SRCNAME = "numpy"
 
@@ -12,7 +12,7 @@ SRC_URI = 
"https://github.com/${SRCNAME}/${SRCNAME}/releases/download/v${PV}/${S
file://0001-numpy-core-Define-RISCV-32-support.patch \
file://run-ptest \
 "
-SRC_URI[sha256sum] = 
"b7340f0628ce1823c151e3d2a2a8cba2a3ff1357fba4475a24b1816e75c21f90"
+SRC_URI[sha256sum] = 
"b662c841b29848c04d9134f31dbaa7d4c8e673f45bb3a5f28d02f49c424d558a"
 
 UPSTREAM_CHECK_URI = "https://github.com/numpy/numpy/releases;
 UPSTREAM_CHECK_REGEX = "(?P\d+(\.\d+)+)\.tar"
-- 
2.25.1


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

Re: [OE-core][PATCH 2/2] kernel.bbclass: inherit kernel_devicetree only if KERNEL_DEVICETREE is set

2021-06-23 Thread Andrey Zhizhikin 
Hello Andrea,

On Wed, Jun 23, 2021 at 3:16 PM Andrea Adami  wrote:
>
> On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
>  wrote:
> >
> > > -Original Message-
> > > From: openembedded-core@lists.openembedded.org  > > c...@lists.openembedded.org> On Behalf Of Andrea Adami
> > > Sent: den 23 juni 2021 00:18
> > > To: openembedded-core@lists.openembedded.org
> > > Subject: [OE-core][PATCH 2/2] kernel.bbclass: inherit kernel_devicetree
> > > only if KERNEL_DEVICETREE is set
> > >
> > > Now it unconditionally tries to create package kernel-devicetre even for
> > > legacy devices w/out DT.
> > >
> > > Signed-off-by: Andrea Adami 
> > > ---
> > >  meta/classes/kernel.bbclass | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > index 06e6446a08..68369e3791 100644
> > > --- a/meta/classes/kernel.bbclass
> > > +++ b/meta/classes/kernel.bbclass
> > > @@ -779,4 +779,4 @@ addtask deploy after do_populate_sysroot
> > > do_packagedata
> > >  EXPORT_FUNCTIONS do_deploy
> > >
> > >  # Add using Device Tree support
> > > -inherit kernel-devicetree
> > > +inherit ${@ "" if d.getVar("KERNEL_DEVICETREE" == "") else 
> > > "kernel-devicetree" }
> >
> > That doesn't look correct. Don't you mean something like this:
> >
> > inherit ${@ "kernel-devicetree" if d.getVar("KERNEL_DEVICETREE") else "" }
> >
>
> As you prefer, I don't think bitbake has likely/unlikely optimization.
> I took the style-example from line 6 where it reads
>
> KERNEL_DEPLOYSUBDIR ??= "${@ "" if (d.getVar("KERNEL_PACKAGE_NAME") ==
> "kernel") else d.getVar("KERNEL_PACKAGE_NAME") }"
>
> I am for any option providing a guard.

I guess you've missed the closing bracket in your statement, please
take a look at the comparison operator.

As yet another option, maybe even something like this:
inherit ${@oe.utils.ifelse(d.getVar('KERNEL_DEVICETREE') == '', '',
'kernel-devicetree')}

However, I'm not sure what would happened if KERNEL_DEVICETREE is
undefined, as in this case bitbake should return "None" according to
the documentation.

>
> Cheers
> A.A.
>
>
> > > --
> > > 2.17.1
> >
> > //Peter
> >
>
> 
>


-- 
Regards,
Andrey.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153241): 
https://lists.openembedded.org/g/openembedded-core/message/153241
Mute This Topic: https://lists.openembedded.org/mt/83725509/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 2/2] kernel.bbclass: inherit kernel_devicetree only if KERNEL_DEVICETREE is set

2021-06-23 Thread Andrea Adami 
On Wed, Jun 23, 2021 at 3:51 PM Andrey Zhizhikin  wrote:
>
> Hello Andrea,
>
> On Wed, Jun 23, 2021 at 3:16 PM Andrea Adami  wrote:
> >
> > On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
> >  wrote:
> > >
> > > > -Original Message-
> > > > From: openembedded-core@lists.openembedded.org  > > > c...@lists.openembedded.org> On Behalf Of Andrea Adami
> > > > Sent: den 23 juni 2021 00:18
> > > > To: openembedded-core@lists.openembedded.org
> > > > Subject: [OE-core][PATCH 2/2] kernel.bbclass: inherit kernel_devicetree
> > > > only if KERNEL_DEVICETREE is set
> > > >
> > > > Now it unconditionally tries to create package kernel-devicetre even for
> > > > legacy devices w/out DT.
> > > >
> > > > Signed-off-by: Andrea Adami 
> > > > ---
> > > >  meta/classes/kernel.bbclass | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > > index 06e6446a08..68369e3791 100644
> > > > --- a/meta/classes/kernel.bbclass
> > > > +++ b/meta/classes/kernel.bbclass
> > > > @@ -779,4 +779,4 @@ addtask deploy after do_populate_sysroot
> > > > do_packagedata
> > > >  EXPORT_FUNCTIONS do_deploy
> > > >
> > > >  # Add using Device Tree support
> > > > -inherit kernel-devicetree
> > > > +inherit ${@ "" if d.getVar("KERNEL_DEVICETREE" == "") else 
> > > > "kernel-devicetree" }
> > >
> > > That doesn't look correct. Don't you mean something like this:
> > >
> > > inherit ${@ "kernel-devicetree" if d.getVar("KERNEL_DEVICETREE") else "" }
> > >
> >
> > As you prefer, I don't think bitbake has likely/unlikely optimization.
> > I took the style-example from line 6 where it reads
> >
> > KERNEL_DEPLOYSUBDIR ??= "${@ "" if (d.getVar("KERNEL_PACKAGE_NAME") ==
> > "kernel") else d.getVar("KERNEL_PACKAGE_NAME") }"
> >
> > I am for any option providing a guard.
>
> I guess you've missed the closing bracket in your statement, please
> take a look at the comparison operator.

The code as it is doesn't raise any parse error.
There is opening bracket and closing bracket, what more?

We can discuss about the form, someone suggested anonymous python for
both patches.

Thanks for reviewing
A.A.

>
> As yet another option, maybe even something like this:
> inherit ${@oe.utils.ifelse(d.getVar('KERNEL_DEVICETREE') == '', '',
> 'kernel-devicetree')}
>
> However, I'm not sure what would happened if KERNEL_DEVICETREE is
> undefined, as in this case bitbake should return "None" according to
> the documentation.
>
> >
> > Cheers
> > A.A.
> >
> >
> > > > --
> > > > 2.17.1
> > >
> > > //Peter
> > >
> >
> > 
> >
>
>
> --
> Regards,
> Andrey.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153242): 
https://lists.openembedded.org/g/openembedded-core/message/153242
Mute This Topic: https://lists.openembedded.org/mt/83725509/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 2/2] kernel.bbclass: inherit kernel_devicetree only if KERNEL_DEVICETREE is set

2021-06-23 Thread Andrea Adami 
On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Andrea Adami
> > Sent: den 23 juni 2021 00:18
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core][PATCH 2/2] kernel.bbclass: inherit kernel_devicetree
> > only if KERNEL_DEVICETREE is set
> >
> > Now it unconditionally tries to create package kernel-devicetre even for
> > legacy devices w/out DT.
> >
> > Signed-off-by: Andrea Adami 
> > ---
> >  meta/classes/kernel.bbclass | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index 06e6446a08..68369e3791 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -779,4 +779,4 @@ addtask deploy after do_populate_sysroot
> > do_packagedata
> >  EXPORT_FUNCTIONS do_deploy
> >
> >  # Add using Device Tree support
> > -inherit kernel-devicetree
> > +inherit ${@ "" if d.getVar("KERNEL_DEVICETREE" == "") else 
> > "kernel-devicetree" }
>
> That doesn't look correct. Don't you mean something like this:
>
> inherit ${@ "kernel-devicetree" if d.getVar("KERNEL_DEVICETREE") else "" }
>

As you prefer, I don't think bitbake has likely/unlikely optimization.
I took the style-example from line 6 where it reads

KERNEL_DEPLOYSUBDIR ??= "${@ "" if (d.getVar("KERNEL_PACKAGE_NAME") ==
"kernel") else d.getVar("KERNEL_PACKAGE_NAME") }"

I am for any option providing a guard.

Cheers
A.A.


> > --
> > 2.17.1
>
> //Peter
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153239): 
https://lists.openembedded.org/g/openembedded-core/message/153239
Mute This Topic: https://lists.openembedded.org/mt/83725509/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] should a layer supply its own "local.conf" file?

2021-06-23 Thread Robert P. J. Day 

  long story short -- was having trouble figuring out why basic
settings i was adding to my build directory's conf/local.conf were
being ignored, and traced it back to the internal layer i was using
having its own "local.conf" file (in its conf directory, sitting
quietly next to the layer's "layer.conf" file).

  argh.

  i'm assuming that it was *that* local.conf that was being consulted
by the config process (overriding mine). is there some rationale for
that? that doesn't strike me as proper design, but i'm willing to be
educated.

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153235): 
https://lists.openembedded.org/g/openembedded-core/message/153235
Mute This Topic: https://lists.openembedded.org/mt/83734978/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 2/2] package.bbclass: manage external sources for debug source file packaging

2021-06-23 Thread Frederic Martinsons 
Hello, I would like to add a link to a yocto mail where I expose my
problematic that led to this patch series:
https://lists.yoctoproject.org/g/yocto/topic/83622035?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,83622035

After further research, I think these patch can be simplified by modified
only WORKDIR variable to be os.path.dirname(EXTERNALSRC) but I fear of
consequence to have WORKDIR outside of TMPDIR so I didn't take this path.

On Wed, 23 Jun 2021 at 15:06, Frederic Martinsons <
frederic.martins...@gmail.com> wrote:

> Signed-off-by: Frederic Martinsons 
> ---
>  meta/classes/package.bbclass | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index cf30f33f3d..38e9065f25 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -560,13 +560,20 @@ def copydebugsources(debugsrcdir, sources, d):
>  strip = d.getVar("STRIP")
>  objcopy = d.getVar("OBJCOPY")
>  workdir = d.getVar("WORKDIR")
> -workparentdir = os.path.dirname(os.path.dirname(workdir))
> +externalsrc = d.getVar('EXTERNALSRC')
> +if externalsrc:
> +workparentdir = os.path.dirname(externalsrc)
> +else:
> +workparentdir = os.path.dirname(os.path.dirname(workdir))
> +
>  workbasedir = os.path.basename(os.path.dirname(workdir)) + "/" +
> os.path.basename(workdir)
>
>  # If build path exists in sourcefile, it means toolchain did not
> use
>  # -fdebug-prefix-map to compile
>  if checkbuildpath(sourcefile, d):
>  localsrc_prefix = workparentdir + "/"
> +elif externalsrc:
> +localsrc_prefix = os.path.join("/usr/src/debug/",
> workbasedir) + "/"
>  else:
>  localsrc_prefix = "/usr/src/debug/"
>
> --
> 2.25.1
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153238): 
https://lists.openembedded.org/g/openembedded-core/message/153238
Mute This Topic: https://lists.openembedded.org/mt/83737160/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Using RDEPENDS or RRECOMMENDS inside a kernel module recipe

2021-06-23 Thread Mike Looijmans 
Simple question: How can I make an external kernel module depend on its 
firmware?


Suppose I have a recipe "kernel-module-something.bb"

Now this module needs firmware to work so the recipe basically contains 
this:


inherit module

SRC_URI = "..."

RRECOMMENDS_${PN} += "something-firmware"


What I would expect is that if I add "kernel-module-something" to the 
image, that "something-firmware" also gets installed. This however does 
not happen.


The "something-firmware" package is being built, but not installed, even 
though "kernel-module-something" is present.


I think the reason is that there are two packages created, one meta 
packages called "kernel-module-something" that indeed contains the 
dependency on the "something-firmware" but does not contain the actual 
kernel module.


There's a second package named "kernel-module-something-5.4.0-blabla"  
(where 5.4.0-blabla appears to be the kernel version) that contains the 
actual kernel module, but there's no recommendation in this package at all.



How do I properly make it so that installing "kernel-module-something" 
will also install "something-firmware"?



--
Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153240): 
https://lists.openembedded.org/g/openembedded-core/message/153240
Mute This Topic: https://lists.openembedded.org/mt/83737518/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] pypi: set SRC_URI with =, not with +=

2021-06-23 Thread Alexander Kanavin 
Frankly guys, I think maybe we should just break stuff in this case, and
have it fixed up properly, then try to guess what workaround might work.

>From that perspective the original patch is the most clear.

Alex

On Wed, 23 Jun 2021 at 11:26, Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> I suggest you use =+ instead of _prepend to maintain expansion order.
> I.e., if someone does:
>
>
>
> inherit pypi
>
>
>
> SRC_URI = "http://some_url ${PYPI_SRC_URI}"
>
>
>
> However, any way you change it, you risk breaking someone’s use case, but
> I believe using =+ instead of += should be the least invasive change
> compared to the current version.
>
>
>
> //Peter
>
>
>
> *From:* openembedded-core@lists.openembedded.org <
> openembedded-core@lists.openembedded.org> *On Behalf Of *Alexander Kanavin
> *Sent:* den 23 juni 2021 10:34
> *To:* Konrad Weihmann 
> *Cc:* OE-core 
> *Subject:* Re: [OE-core] [PATCH] pypi: set SRC_URI with =, not with +=
>
>
>
> Right, I sent an updated patch.
>
>
>
> Alex
>
>
>
> On Wed, 23 Jun 2021 at 09:01, Konrad Weihmann 
> wrote:
>
> That doesn't look completely right to me.
>
> You're absolutely right about devtool expecting the tarball in as the 1st
> item, but this patch here breaks existing recipes like
>
> SRC_URI += "file://some.patch"
>
> inherit pypi
>
> as the patch will now be dropped.
>
>
>
> I would suggest to go for SRC_URI_prepend = "${PYPI_SRC_URI} " which fixes
> the issue *and* doesn't break exisiting setups
>
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153234): 
https://lists.openembedded.org/g/openembedded-core/message/153234
Mute This Topic: https://lists.openembedded.org/mt/83721889/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 2/2] package.bbclass: manage external sources for debug source file packaging

2021-06-23 Thread Frederic Martinsons 
Signed-off-by: Frederic Martinsons 
---
 meta/classes/package.bbclass | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index cf30f33f3d..38e9065f25 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -560,13 +560,20 @@ def copydebugsources(debugsrcdir, sources, d):
 strip = d.getVar("STRIP")
 objcopy = d.getVar("OBJCOPY")
 workdir = d.getVar("WORKDIR")
-workparentdir = os.path.dirname(os.path.dirname(workdir))
+externalsrc = d.getVar('EXTERNALSRC')
+if externalsrc:
+workparentdir = os.path.dirname(externalsrc)
+else:
+workparentdir = os.path.dirname(os.path.dirname(workdir))
+
 workbasedir = os.path.basename(os.path.dirname(workdir)) + "/" + 
os.path.basename(workdir)
 
 # If build path exists in sourcefile, it means toolchain did not use
 # -fdebug-prefix-map to compile
 if checkbuildpath(sourcefile, d):
 localsrc_prefix = workparentdir + "/"
+elif externalsrc:
+localsrc_prefix = os.path.join("/usr/src/debug/", workbasedir) + 
"/"
 else:
 localsrc_prefix = "/usr/src/debug/"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153237): 
https://lists.openembedded.org/g/openembedded-core/message/153237
Mute This Topic: https://lists.openembedded.org/mt/83737160/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 1/2] externalsrc.bbclass: dynamical change of DEBUG_PREFIX_MAP

2021-06-23 Thread Frederic Martinsons 
When using external source manager (devtool), the debug symbol generated
by the compilation doesn't point to the right directory.
This is normally handled by gcc options that are defined
in DEBUG_PREFIX_MAP in conf/bitbake.conf.

But the path in it are hardcoded and point to WORKDIR which is
not overloaded by devtool.

This patch takes the parent directory of external source directory
and prepend correct path to DEBUG_PREFIX_MAP.

Moreover, to avoid wrong path resolution during dwarfsrcfiles step
in splitdebuginfo, it make B variable point to the same
structure as EXTERNALSRC (if EXTERNALSRC_BUILD is not defined).

Signed-off-by: Frederic Martinsons 
---
 meta/classes/externalsrc.bbclass | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 3d6b80bee2..de5ef714b4 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -53,14 +53,26 @@ python () {
 d.setVar('BB_DONT_CACHE', '1')
 
 if externalsrc:
+import os
 import oe.recipeutils
 import oe.path
 
+pn = d.getVar('PN')
+# taken from bitbake.conf
+debugsrcdir = "/usr/src/debug/%s/%s%s-%s" % (pn, d.getVar('EXTENDPE'), 
d.getVar('PV'), d.getVar('PR'))
+externalsrc_parentdir = os.path.dirname(externalsrc)
+
+debug_prefix_map_ext = "-fmacro-prefix-map=%s=%s " % 
(externalsrc_parentdir, debugsrcdir)
+macro_prefix_map_ext = "-fdebug-prefix-map=%s=%s " % 
(externalsrc_parentdir, debugsrcdir)
+d.prependVar('DEBUG_PREFIX_MAP', debug_prefix_map_ext)
+d.prependVar('DEBUG_PREFIX_MAP', macro_prefix_map_ext)
+
 d.setVar('S', externalsrc)
 if externalsrcbuild:
 d.setVar('B', externalsrcbuild)
 else:
-d.setVar('B', '${WORKDIR}/${BPN}-${PV}/')
+builddir = os.path.join(externalsrc_parentdir, "%s-build" % pn)
+d.setVar('B', builddir)
 
 local_srcuri = []
 fetch = bb.fetch2.Fetch((d.getVar('SRC_URI') or '').split(), d)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153236): 
https://lists.openembedded.org/g/openembedded-core/message/153236
Mute This Topic: https://lists.openembedded.org/mt/83737158/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] should a layer supply its own "local.conf" file?

2021-06-23 Thread Khem Raj 



On 6/23/21 3:48 AM, Robert P. J. Day wrote:


   long story short -- was having trouble figuring out why basic
settings i was adding to my build directory's conf/local.conf were
being ignored, and traced it back to the internal layer i was using
having its own "local.conf" file (in its conf directory, sitting
quietly next to the layer's "layer.conf" file).

   argh.

   i'm assuming that it was *that* local.conf that was being consulted
by the config process (overriding mine). is there some rationale for
that? that doesn't strike me as proper design, but i'm willing to be
educated.


you can check output of bitbake -e  and see which 
local.conf is being picked up and also trace the history of it

sometimes it could be included by layer.conf from particular layer etc.
there are multiple ways it can come into mix.



rday






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153243): 
https://lists.openembedded.org/g/openembedded-core/message/153243
Mute This Topic: https://lists.openembedded.org/mt/83734978/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 2/2] kernel.bbclass: inherit kernel_devicetree only if KERNEL_DEVICETREE is set

2021-06-23 Thread Martin Jansa 
On Wed, Jun 23, 2021 at 05:22:21PM +0200, Andrea Adami wrote:
> On Wed, Jun 23, 2021 at 3:51 PM Andrey Zhizhikin  wrote:
> >
> > Hello Andrea,
> >
> > On Wed, Jun 23, 2021 at 3:16 PM Andrea Adami  wrote:
> > >
> > > On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
> > >  wrote:
> > > >
> > > > > -Original Message-
> > > > > From: openembedded-core@lists.openembedded.org  > > > > c...@lists.openembedded.org> On Behalf Of Andrea Adami
> > > > > Sent: den 23 juni 2021 00:18
> > > > > To: openembedded-core@lists.openembedded.org
> > > > > Subject: [OE-core][PATCH 2/2] kernel.bbclass: inherit 
> > > > > kernel_devicetree
> > > > > only if KERNEL_DEVICETREE is set
> > > > >
> > > > > Now it unconditionally tries to create package kernel-devicetre even 
> > > > > for
> > > > > legacy devices w/out DT.
> > > > >
> > > > > Signed-off-by: Andrea Adami 
> > > > > ---
> > > > >  meta/classes/kernel.bbclass | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > > > index 06e6446a08..68369e3791 100644
> > > > > --- a/meta/classes/kernel.bbclass
> > > > > +++ b/meta/classes/kernel.bbclass
> > > > > @@ -779,4 +779,4 @@ addtask deploy after do_populate_sysroot
> > > > > do_packagedata
> > > > >  EXPORT_FUNCTIONS do_deploy
> > > > >
> > > > >  # Add using Device Tree support
> > > > > -inherit kernel-devicetree
> > > > > +inherit ${@ "" if d.getVar("KERNEL_DEVICETREE" == "") else 
> > > > > "kernel-devicetree" }
> > > >
> > > > That doesn't look correct. Don't you mean something like this:
> > > >
> > > > inherit ${@ "kernel-devicetree" if d.getVar("KERNEL_DEVICETREE") else 
> > > > "" }
> > > >
> > >
> > > As you prefer, I don't think bitbake has likely/unlikely optimization.
> > > I took the style-example from line 6 where it reads
> > >
> > > KERNEL_DEPLOYSUBDIR ??= "${@ "" if (d.getVar("KERNEL_PACKAGE_NAME") ==
> > > "kernel") else d.getVar("KERNEL_PACKAGE_NAME") }"
> > >
> > > I am for any option providing a guard.
> >
> > I guess you've missed the closing bracket in your statement, please
> > take a look at the comparison operator.
> 
> The code as it is doesn't raise any parse error.
> There is opening bracket and closing bracket, what more?

d.getVar("KERNEL_DEVICETREE" == "")
vs
d.getVar("KERNEL_DEVICETREE") == ""

> We can discuss about the form, someone suggested anonymous python for
> both patches.
> 
> Thanks for reviewing
> A.A.
> 
> >
> > As yet another option, maybe even something like this:
> > inherit ${@oe.utils.ifelse(d.getVar('KERNEL_DEVICETREE') == '', '',
> > 'kernel-devicetree')}
> >
> > However, I'm not sure what would happened if KERNEL_DEVICETREE is
> > undefined, as in this case bitbake should return "None" according to
> > the documentation.
> >
> > >
> > > Cheers
> > > A.A.
> > >
> > >
> > > > > --
> > > > > 2.17.1
> > > >
> > > > //Peter
> > > >
> > >
> > > 
> > >
> >
> >
> > --
> > Regards,
> > Andrey.

> 
> 
> 



signature.asc
Description: PGP signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153244): 
https://lists.openembedded.org/g/openembedded-core/message/153244
Mute This Topic: https://lists.openembedded.org/mt/83725509/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] uninative: allow PREMIRRORS to use versioned url subpath

2021-06-23 Thread bkylerussell 
This allows users running their own mirrors to store uninative tarballs
under versioned paths just like the default UNINATIVE_URL without having
to completely override UNINATIVE_URL in their distro configuration and
manually update the versioned URL on each upgrade.

The hashed subpath is left for compatibility, but not practical for
mirror management.

Signed-off-by: Kyle Russell 
---
 meta/classes/uninative.bbclass   | 1 +
 meta/conf/distro/include/yocto-uninative.inc | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 1e19917a97..543f747358 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -64,6 +64,7 @@ python uninative_event_fetchloader() {
 continue
 if find.startswith("http"):
 localdata.appendVar("PREMIRRORS", " 
${UNINATIVE_URL}${UNINATIVE_TARBALL} %s/uninative/%s/${UNINATIVE_TARBALL}" % 
(replace, chksum))
+localdata.appendVar("PREMIRRORS", " 
${UNINATIVE_URL}${UNINATIVE_TARBALL} 
%s/uninative/${UNINATIVE_VERSION}/${UNINATIVE_TARBALL}" % replace)
 
 srcuri = 
d.expand("${UNINATIVE_URL}${UNINATIVE_TARBALL};sha256sum=%s" % chksum)
 bb.note("Fetching uninative binary shim %s (will check PREMIRRORS 
first)" % srcuri)
diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index 740cca0ecf..d7d1e2cb59 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -7,8 +7,9 @@
 #
 
 UNINATIVE_MAXGLIBCVERSION = "2.33"
+UNINATIVE_VERSION = "3.2"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/3.2/;
+UNINATIVE_URL ?= 
"http://downloads.yoctoproject.org/releases/uninative/${UNINATIVE_VERSION}/;
 UNINATIVE_CHECKSUM[aarch64] ?= 
"4f0872cdca2775b637a8a99815ca5c8dd42146abe903a24a50ee0448358c764b"
 UNINATIVE_CHECKSUM[i686] ?= 
"e2eeab92e67263db37d9bb6d4c58579abd1f47ff4cded3171bde572fece124b2"
 UNINATIVE_CHECKSUM[x86_64] ?= 
"3ee8c7d55e2d4c7ae3887cddb97219f97b94efddfeee2e24923c0cb0e8ce84c6"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153245): 
https://lists.openembedded.org/g/openembedded-core/message/153245
Mute This Topic: https://lists.openembedded.org/mt/83744822/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 2/2] kernel.bbclass: inherit kernel_devicetree only if KERNEL_DEVICETREE is set

2021-06-23 Thread Andrea Adami 
Thank you, I'll send v2.
I am waiting RP comments about the other patch of the series for
kernel.bbclass which exposed this one issue.

Martin, I tried to remove the patch from patchwork but all stops end 2020.
Am I missing something? New links?
Thanks all
A.A.

On Wed, Jun 23, 2021 at 6:02 PM Martin Jansa  wrote:
>
> On Wed, Jun 23, 2021 at 05:22:21PM +0200, Andrea Adami wrote:
> > On Wed, Jun 23, 2021 at 3:51 PM Andrey Zhizhikin  wrote:
> > >
> > > Hello Andrea,
> > >
> > > On Wed, Jun 23, 2021 at 3:16 PM Andrea Adami  
> > > wrote:
> > > >
> > > > On Wed, Jun 23, 2021 at 11:32 AM Peter Kjellerstedt
> > > >  wrote:
> > > > >
> > > > > > -Original Message-
> > > > > > From: openembedded-core@lists.openembedded.org  > > > > > c...@lists.openembedded.org> On Behalf Of Andrea Adami
> > > > > > Sent: den 23 juni 2021 00:18
> > > > > > To: openembedded-core@lists.openembedded.org
> > > > > > Subject: [OE-core][PATCH 2/2] kernel.bbclass: inherit 
> > > > > > kernel_devicetree
> > > > > > only if KERNEL_DEVICETREE is set
> > > > > >
> > > > > > Now it unconditionally tries to create package kernel-devicetre 
> > > > > > even for
> > > > > > legacy devices w/out DT.
> > > > > >
> > > > > > Signed-off-by: Andrea Adami 
> > > > > > ---
> > > > > >  meta/classes/kernel.bbclass | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/meta/classes/kernel.bbclass 
> > > > > > b/meta/classes/kernel.bbclass
> > > > > > index 06e6446a08..68369e3791 100644
> > > > > > --- a/meta/classes/kernel.bbclass
> > > > > > +++ b/meta/classes/kernel.bbclass
> > > > > > @@ -779,4 +779,4 @@ addtask deploy after do_populate_sysroot
> > > > > > do_packagedata
> > > > > >  EXPORT_FUNCTIONS do_deploy
> > > > > >
> > > > > >  # Add using Device Tree support
> > > > > > -inherit kernel-devicetree
> > > > > > +inherit ${@ "" if d.getVar("KERNEL_DEVICETREE" == "") else 
> > > > > > "kernel-devicetree" }
> > > > >
> > > > > That doesn't look correct. Don't you mean something like this:
> > > > >
> > > > > inherit ${@ "kernel-devicetree" if d.getVar("KERNEL_DEVICETREE") else 
> > > > > "" }
> > > > >
> > > >
> > > > As you prefer, I don't think bitbake has likely/unlikely optimization.
> > > > I took the style-example from line 6 where it reads
> > > >
> > > > KERNEL_DEPLOYSUBDIR ??= "${@ "" if (d.getVar("KERNEL_PACKAGE_NAME") ==
> > > > "kernel") else d.getVar("KERNEL_PACKAGE_NAME") }"
> > > >
> > > > I am for any option providing a guard.
> > >
> > > I guess you've missed the closing bracket in your statement, please
> > > take a look at the comparison operator.
> >
> > The code as it is doesn't raise any parse error.
> > There is opening bracket and closing bracket, what more?
>
> d.getVar("KERNEL_DEVICETREE" == "")
> vs
> d.getVar("KERNEL_DEVICETREE") == ""
>
> > We can discuss about the form, someone suggested anonymous python for
> > both patches.
> >
> > Thanks for reviewing
> > A.A.
> >
> > >
> > > As yet another option, maybe even something like this:
> > > inherit ${@oe.utils.ifelse(d.getVar('KERNEL_DEVICETREE') == '', '',
> > > 'kernel-devicetree')}
> > >
> > > However, I'm not sure what would happened if KERNEL_DEVICETREE is
> > > undefined, as in this case bitbake should return "None" according to
> > > the documentation.
> > >
> > > >
> > > > Cheers
> > > > A.A.
> > > >
> > > >
> > > > > > --
> > > > > > 2.17.1
> > > > >
> > > > > //Peter
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Andrey.
>
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153246): 
https://lists.openembedded.org/g/openembedded-core/message/153246
Mute This Topic: https://lists.openembedded.org/mt/83725509/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] README.skeleton: add readme to meta-skeleton layer

2021-06-23 Thread Richard Purdie 
On Tue, 2021-06-22 at 17:50 -0400, Scott Weaver wrote:
> I didn't see that this patch was picked up (but maybe I'm looking in the 
> wrong place) and I received the email
> from Stephen that the issue should be moved to 3.4 M2.
> Did I send this to the wrong mailing list or is it not the solution you're 
> looking for?
> 
> I elaborated in bugzilla on why I think just adding the readme file to close 
> this issue is enough but you may
> not have seen that comment or agree. :)
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13612
> 
> Scott 
> 
> On Tue, Jun 8, 2021 at 9:46 PM Scott Weaver via lists.openembedded.org <
> weaverjs=gmail@lists.openembedded.org> wrote:
> > Added to satisfy the yocto-check-layer tool readme file test.
> > 
> > [YOCTO #13612]
> > 
> > Signed-off-by: Scott Weaver 
> > ---
> >  meta-skeleton/README.skeleton | 7 +++
> >  1 file changed, 7 insertions(+)
> >  create mode 100644 meta-skeleton/README.skeleton
> > 
> > diff --git a/meta-skeleton/README.skeleton b/meta-skeleton/README.skeleton
> > new file mode 100644
> > index 00..25468dc87a
> > --- /dev/null
> > +++ b/meta-skeleton/README.skeleton
> > @@ -0,0 +1,7 @@
> > +meta-skeleton
> > +=
> > +
> > +The meta-skeleton layer contains example recipes and configuration files.
> > +
> > +This layer is not intended to demonstrate a Yocto Project Compatible 
> > software layer.
> > +Disable the signature check when testing this layer using the 
> > yocto-check-layer tool.

Sorry, it takes time to page in the context for this.

I think we should fix meta-skeleton to work with yocto-check-layer. I think this
may be relatively simple, we can change the busybox bbappend that is causing the
signature failure to be 'distro' specific, e.g. something like:

-SRC_URI += " \
+SRC_URI_append_mydistro = " \

and then an example is still there but it doesn't break the checks (and isn't
enabled by default). We could add a comment about it being enabled by a custom
distro called 'mydistro'.

That change, along with your README addition should allow the layer tests to 
pass.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153247): 
https://lists.openembedded.org/g/openembedded-core/message/153247
Mute This Topic: https://lists.openembedded.org/mt/83411485/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] README.skeleton: add readme to meta-skeleton layer

2021-06-23 Thread Scott Weaver 
Thanks, Richard.
The issue noted that the distro specific update wasn't working but it's
because they tried SRC_URI_append_poky (which correctly failed) so I didn't
even think to try anything else.
My mistake. I'll make the changes you suggested.

Thanks again for your time!
Scott


On Wed, Jun 23, 2021 at 5:12 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Tue, 2021-06-22 at 17:50 -0400, Scott Weaver wrote:
> > I didn't see that this patch was picked up (but maybe I'm looking in the
> wrong place) and I received the email
> > from Stephen that the issue should be moved to 3.4 M2.
> > Did I send this to the wrong mailing list or is it not the solution
> you're looking for?
> >
> > I elaborated in bugzilla on why I think just adding the readme file to
> close this issue is enough but you may
> > not have seen that comment or agree. :)
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13612
> >
> > Scott
> >
> > On Tue, Jun 8, 2021 at 9:46 PM Scott Weaver via lists.openembedded.org <
> > weaverjs=gmail@lists.openembedded.org> wrote:
> > > Added to satisfy the yocto-check-layer tool readme file test.
> > >
> > > [YOCTO #13612]
> > >
> > > Signed-off-by: Scott Weaver 
> > > ---
> > >  meta-skeleton/README.skeleton | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >  create mode 100644 meta-skeleton/README.skeleton
> > >
> > > diff --git a/meta-skeleton/README.skeleton
> b/meta-skeleton/README.skeleton
> > > new file mode 100644
> > > index 00..25468dc87a
> > > --- /dev/null
> > > +++ b/meta-skeleton/README.skeleton
> > > @@ -0,0 +1,7 @@
> > > +meta-skeleton
> > > +=
> > > +
> > > +The meta-skeleton layer contains example recipes and configuration
> files.
> > > +
> > > +This layer is not intended to demonstrate a Yocto Project Compatible
> software layer.
> > > +Disable the signature check when testing this layer using the
> yocto-check-layer tool.
>
> Sorry, it takes time to page in the context for this.
>
> I think we should fix meta-skeleton to work with yocto-check-layer. I
> think this
> may be relatively simple, we can change the busybox bbappend that is
> causing the
> signature failure to be 'distro' specific, e.g. something like:
>
> -SRC_URI += " \
> +SRC_URI_append_mydistro = " \
>
> and then an example is still there but it doesn't break the checks (and
> isn't
> enabled by default). We could add a comment about it being enabled by a
> custom
> distro called 'mydistro'.
>
> That change, along with your README addition should allow the layer tests
> to pass.
>
> Cheers,
>
> Richard
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153248): 
https://lists.openembedded.org/g/openembedded-core/message/153248
Mute This Topic: https://lists.openembedded.org/mt/83411485/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] perl: avoid the source file patched twice

2021-06-23 Thread Yu, Mingli 



On 6/21/21 4:48 PM, Richard Purdie wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

On Fri, 2021-06-18 at 10:30 +0800, Yu, Mingli wrote:

From: Mingli Yu 

After the commit(60dcb230f6 perl: split perl-cross into its own recipe)
introduced, the source files mainly come from two parts, one is from
SRI_URI during do_fetch and the other with below means during do_configure.
do_configure_prepend() {
 cp -rfp ${STAGING_DATADIR_NATIVE}/perl-cross/* ${S}
}

And the source files will be changed during do_compile with below
logic in Makefile.
$(CROSSPATCHED): %.applied: %.patch
 patch -p1 -i $< && touch $@

And there comes build failure with below steps:
  $ bitbake perl-native

Make a change as below
  $ git diff
  diff --git a/meta/recipes-devtools/perl-cross/perlcross_1.3.6.bb 
b/meta/recipes-devtools/perl-cross/perlcross_1.3.6.bb
  index b77bbd1fd4..4c5e35ab80 100644
  --- a/meta/recipes-devtools/perl-cross/perlcross_1.3.6.bb
  +++ b/meta/recipes-devtools/perl-cross/perlcross_1.3.6.bb
  @@ -33,6 +33,7 @@ do_compile () {
   do_install_class-native() {
   mkdir -p ${D}/${datadir}/perl-cross/
   cp -rf ${S}/* ${D}/${datadir}/perl-cross/
  +echo "test" > ${D}/${datadir}/perl-cross/testfile
  }

  $ bitbake perl-native
  | NOTE: make -j 48
  | make crosspatch
  | make[1]: Entering directory 
'/buildarea1/myu2/wr_build/wr1021_20210616_perl/build/tmp-glibc/work/x86_64-linux/perl-native/5.34.0-r0/perl-5.34.0'
  | patch -p1 -i cnf/diffs/perl5-5.34.0/time-hires.patch && touch 
cnf/diffs/perl5-5.34.0/time-hires.applied
  | patch -p1 -i cnf/diffs/perl5-5.34.0/xconfig.patch && touch 
cnf/diffs/perl5-5.34.0/xconfig.applied
  | patch -p1 -i cnf/diffs/perl5-5.34.0/posix-makefile.patch && touch 
cnf/diffs/perl5-5.34.0/posix-makefile.applied
  | File dist/Time-HiRes/Makefile.PL is read-only; trying to patch anyway
  | patching file dist/Time-HiRes/Makefile.PL
  | Reversed (or previously applied) patch detected!  Assume -R? [n]
  | Apply anyway? [n]
  | Skipping patch.
  | 4 out of 4 hunks ignored -- saving rejects to file 
dist/Time-HiRes/Makefile.PL.rej
  | patch -p1 -i cnf/diffs/perl5-5.34.0/test-commonsense.patch && touch 
cnf/diffs/perl5-5.34.0/test-commonsense.applied
  | File perl.h is read-only; trying to patch anyway
  | patching file perl.h
  | Reversed (or previously applied) patch detected!  Assume -R? [n]
  | Apply anyway? [n]
  | Skipping patch.
  | 1 out of 1 hunk ignored -- saving rejects to file perl.h.rej
  | make[1]: *** [Makefile:64: cnf/diffs/perl5-5.34.0/time-hires.applied] Error 
1
  [snip]

It's because the source files patched twice, so let do_fetch always
executed to make sure the source files which come from SRC_URI brand
new in each build to avoid the source files patched twice to fix the
build failure as above.

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/perl/perl_5.34.0.bb | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb 
b/meta/recipes-devtools/perl/perl_5.34.0.bb
index 7935a58723..2e48110d2b 100644
--- a/meta/recipes-devtools/perl/perl_5.34.0.bb
+++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
@@ -382,3 +382,5 @@ EOF
 chmod 0755 ${SYSROOT_DESTDIR}${bindir}/nativeperl
 cat ${SYSROOT_DESTDIR}${bindir}/nativeperl
  }
+
+do_fetch[nostamp] = "1"


This patch is incorrect, it would cause tasks to rerun all the time and is not
the correct way to solve this problem. We don't use nostamp tasks in mid tree
tasks.


Hi RP,

Any suggestion to solve the issue? I'm also researching a better solution.

Thanks,



Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153249): 
https://lists.openembedded.org/g/openembedded-core/message/153249
Mute This Topic: https://lists.openembedded.org/mt/83620027/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-