from:"Quentin Schulz"

Re: [OE-core] [kirkstone][PATCH v3] kmscube: Add patch to fix -int-conversion build error

2024-10-01 Thread Quentin Schulz via lists.openembedded.org


Hi Purushottam,

On 10/1/24 7:01 AM, Purushottam Kumar wrote:

Hi Quentin,

Shall I update the SRCREV to latest and revert below commit change as patch
would be fine for kirstone?
https://gitlab.freedesktop.org/mesa/kmscube/-/
commit/4961a04b4a434aefbd412eb24fb76998036eaaf6 

Or shall I push specific change as a patch instead of updating SRCREV for
master, scarthgap and kirkstone?Please suggest. Thanks, Purushottam



Let's wait for maintainers' opinion on this :) (Steve is the LTS 
maintainer hence why I mentioned him in my previous answer)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205149): 
https://lists.openembedded.org/g/openembedded-core/message/205149
Mute This Topic: https://lists.openembedded.org/mt/108734161/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] [kirkstone][PATCH v3] kmscube: Add patch to fix -int-conversion build error

2024-09-30 Thread Quentin Schulz via lists.openembedded.org


Hi Purushottam,

On 9/30/24 1:53 PM, Purushottam Choudhary via lists.openembedded.org wrote:

On some platforms, `EGLNativeDisplayType` is an int instead of
a pointer, in which case the void pointer will raise
a `-Wint-conversion`.

Add change as a patch instead of updating SRCREV .
if we update SRCREV might will get compatiblity issue
with current gstreamer 1.20.7 version because SRCREV brings changes
which resolves negotiation issues encountered with V4L2 stateless
hardware video decoders when using kmscube video playback option
which has gstreamer dependency requirement to 1.22.0



@Steve for some context: 
https://gitlab.freedesktop.org/mesa/kmscube/-/commit/4961a04b4a434aefbd412eb24fb76998036eaaf6 
this is the problematic commit not allowing us to bump kmscube further 
than d12ba659695631e7a22dce8fa5d0bc576a9c2241 (or we do, and revert that 
patch instead).



Signed-off-by: Purushottam Choudhary 


Reviewed-by: Quentin Schulz 

Thanks!
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205119): 
https://lists.openembedded.org/g/openembedded-core/message/205119
Mute This Topic: https://lists.openembedded.org/mt/108734161/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 scarthgap RFC] bitbake.conf: Add truncate to HOSTTOOLS

2024-09-30 Thread Quentin Schulz

From: Richard Purdie 

Some wic images need this command. Since it is part of coreutils, it doesn't 
really
cost anything to have in HOSTTOOLS and it avoids signifiant build dependencies 
on
coreutils-native.

[YOCTO #15571]

(cherry picked from commit 522000ce5c4f0201cbe42d7826b6a8489ed10117)
[necessary for building Linux kernel >= 6.11 with CONFIG_KALLSYMS, c.f.
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1472464c6248575bf2d01c7f076b94704bb32c95]

Signed-off-by: Richard Purdie 
Signed-off-by: Quentin Schulz 
---
The Linux kernel in its 6.11 release or later, with KALLSYMS config
enabled, will now fail to build because truncate host tools is
required, c.f.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1472464c6248575bf2d01c7f076b94704bb32c95

but the kernel recipe doesn't depend on coreutils-native, which is too
big of a dependency for what it brings according to Richard (for the
original patch destined to wic) and Bruce (as discussed over mailing
list for the linux-yocto recipe).

Let's backport a patch that was implemented for something else (wic)
from styhead/master as truncate is pretty much guaranteed to be present
on the host with hopefully no compatibility issues between
implementation.

Marked as RFC because it's a "big" change and I don't want the ML to
just gloss over it without questioning it :)

Note: I'm currently NOT building that kernel in my layer, but it'll come
at some point next year, though I did hit this issue when doing a very
quick test with a local tree.
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index ba8bd5f975..78f15b76ae 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -521,7 +521,7 @@ HOSTTOOLS += " \
 mktemp mv nm objcopy objdump od patch perl pr printf pwd \
 python3 pzstd ranlib readelf readlink realpath rm rmdir rpcgen sed seq sh \
 sha1sum sha224sum sha256sum sha384sum sha512sum \
-sleep sort split stat strings strip tail tar tee test touch tr true uname \
+sleep sort split stat strings strip tail tar tee test touch tr true 
truncate uname \
 uniq unzstd wc wget which xargs zstd \
 "
 

---
base-commit: f888dd911529a828820799a7a1b75dfd3a44847c
change-id: 20240930-6-11-kallsyms-truncate-d8d4d9f16d41

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205115): 
https://lists.openembedded.org/g/openembedded-core/message/205115
Mute This Topic: https://lists.openembedded.org/mt/108733316/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] [kirkstone][PATCH v2] kmscube: Add patch to fix -int-conversion build error

2024-09-30 Thread Quentin Schulz via lists.openembedded.org


Hi Purushottam,

On 9/30/24 12:11 PM, Purushottam Kumar wrote:

Hi Quentin,

You are correct.
As discussed earlier,
In my opinion, Updating SRCREV instead of adding as patch will be a better
option for Master and scarthgap branch.But for kirskstone, might will get
compatiblity issue with gstreamer version. so focusing to address the patch.



Correct, but it would better to have this in the commit log in my 
opinion. Steve (the maintainer) may have a different opinion but that 
would help him understand if this patch is ok to backport without doing 
the work by himself.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205114): 
https://lists.openembedded.org/g/openembedded-core/message/205114
Mute This Topic: https://lists.openembedded.org/mt/108732594/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/5] linux-yocto-dev: bump to v6.11

2024-09-30 Thread Quentin Schulz via lists.openembedded.org


Hi Bruce,

On 9/25/24 4:23 PM, Bruce Ashfield wrote:

On Wed, Sep 25, 2024 at 10:07 AM Quentin Schulz 
wrote:


Hi Bruce,

On 9/25/24 3:57 PM, Bruce Ashfield wrote:

On Wed, Sep 25, 2024 at 9:37 AM Quentin Schulz 
Hi Bruce,

On 9/24/24 4:11 PM, Bruce Ashfield wrote:

On Tue, Sep 24, 2024 at 9:02 AM Quentin Schulz <

quentin.sch...@cherry.de


wrote:


Hi Bruce,

On 8/11/24 8:04 PM, Bruce Ashfield via lists.openembedded.org wrote:

From: Bruce Ashfield 

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb

b/meta/recipes-kernel/linux/linux-yocto-dev.bb

index 0097fec7b2..292897ce43 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -14,7 +14,7 @@ require recipes-kernel/linux/linux-yocto.inc
 # provide this .inc to set specific revisions
 include recipes-kernel/linux/linux-yocto-dev-revisions.inc

-KBRANCH = "v6.10/standard/base"
+KBRANCH = "v6.11/standard/base"
 KMETA = "kernel-meta"

 SRC_URI = "git://





git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;protocol=https
<http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https>

<

http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https



<



http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https



\

@@ -28,7 +28,7 @@ SRC_URI = "git://

git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name

<http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name>

<

http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name



<



http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name



 SRCREV_machine ?=

'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}",
"29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'

 SRCREV_meta ?=

'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}",
"29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'


-LINUX_VERSION ?= "6.10"
+LINUX_VERSION ?= "6.11"
 LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
 PV = "${LINUX_VERSION}+git"



I haven't tried to compile linux-yocto-dev but I have my own v6.11-rc6
based kernel recipe.

It failed to build on Scarthgap because I was missing coreutils-native
(specifically truncate binary) because CONFIG_KALLSYMS was enabled.

This

comes from





https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1472464c6248575bf2d01c7f076b94704bb32c95


It seems there are some config fragments in linux-yocto-cache
(ktypes/base/base.cfg) with it, so maybe we want to always add the
dependency (or is there a way to add a build time dependency from an
.scc file?).




Interesting!

I build linux-yocto-dev nightly, so I can confidently say that this

isn't

being seen with the reference recipe.

I also do have KALLSYMS in the default .config, so I've worked through

the

same new commit and enabling option.

I get truncate in my kernel builds via hosttools, so the dependency
wasn't/isn't needed.



truncate isn't in HOSTTOOLS in any release yet, just master.

c.f.



https://git.openembedded.org/openembedded-core/commit/?id=522000ce5c4f0201cbe42d7826b6a8489ed10117


This means people won't be able to build 6.11 and later with
CONFIG_KALLSYMS enabled in Scarthgap and earlier releases...

... unless we backport this patch to still supported releases?

BTW, I could reproduce on Scarthgap by checking out poky in its
scarthgap branch, then running `git checkout origin/master --
meta/recipes-kernel/linux/linux-yocto-dev.bb`, then adding
`PREFERRED_PROVIDER_virtual/kernel="linux-yocto-dev"` to conf/local.conf
and then running `MACHINE=qemuarm64 bitbake linux-yocto-dev` from either
a kas-container (4.3.2) or Debian Bullseye.



Right. I only target linux-yocto-dev at the latest master where we do all
our testing. The support matrix of ever newer kernels against the older
releases can get complicated, but we can at least say a given release
supports the reference kernels + the reference -dev kernel version.

Anything more we do on a case by case basis.



Oh for sure! I wasn't implying we aren't testing appropriately or that
we need to increase the number of kernels to support per release. Just
that **some** people (likely me :) ) may want to support 6.12 on
Scarthgap whenever it's out and that will be an issue. The answer to
that issue could very well be "upstream isn't interested

Re: [OE-core] [PATCH v3] default-distrovars: Have KERNEL_CONSOLE reference SERIAL_CONSOLES

2024-09-30 Thread Quentin Schulz via lists.openembedded.org


Hi Ross,

On 9/24/24 1:35 PM, Ross Burton via lists.openembedded.org wrote:




On 20 Sep 2024, at 19:41, Jon Mason via lists.openembedded.org 
 wrote:

--- a/scripts/lib/wic/canned-wks/mkefidisk.wks
+++ b/scripts/lib/wic/canned-wks/mkefidisk.wks
@@ -8,4 +8,4 @@ part / --source rootfs --ondisk sda --fstype=ext4 --label 
platform --align 1024

part swap --ondisk sda --size 44 --label swap1 --fstype=swap

-bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 
console=tty0"
+bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 
console=${KERNEL_CONSOLE} console=tty0”


My understanding was the .wks files had to be .wks.in for variable expansion to 
happen.  Can you confirm that this is actually just an idiom and the expansions 
happen always?



meta-rockchip also does variable expansion for wic and only has 
rockchip.wks (and not wks.in), so that's one more that works with this 
(though if that is a missed corner case that we aren't supposed to 
support is another question).


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205106): 
https://lists.openembedded.org/g/openembedded-core/message/205106
Mute This Topic: https://lists.openembedded.org/mt/108564893/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] [kirkstone][PATCH v2] kmscube: Add patch to fix -int-conversion build error

2024-09-30 Thread Quentin Schulz via lists.openembedded.org


Hi Purushottam,

On 9/30/24 11:23 AM, Purushottam Choudhary via lists.openembedded.org wrote:

On some platforms, `EGLNativeDisplayType` is an int instead of
a pointer, in which case the void pointer will raise
a `-Wint-conversion`.



Please provide an explanation as to why this isn't first contributed to 
master and then backported to kirkstone (the reason we discussed in the 
patch for master branch is enough in my opinion).


Looking good otherwise,
Cheers,
Quentin


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205109): 
https://lists.openembedded.org/g/openembedded-core/message/205109
Mute This Topic: https://lists.openembedded.org/mt/108732594/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] default-distrovars: Have KERNEL_CONSOLE reference SERIAL_CONSOLES

2024-09-30 Thread Quentin Schulz via lists.openembedded.org


Hi Jon,

On 9/20/24 8:41 PM, Jon Mason via lists.openembedded.org wrote:

Currently, KERNEL_CONSOLE has a default value of "ttyS0".  However, Arm
machines and those using virtio serial prefer to use "ttyAMA0" or "hvc0"
(or something else).  These are usually defined by the machine config
file as SERIAL_CONSOLES, which has one or more entries.  Take the first
one of those instead of ttyS0, but default back to ttyS0 if nothing is
set.

Also, use this variable in the efi wic file instead of "ttyS0".

This includes revisions suggested by Quentin Schulz.

Signed-off-by: Jon Mason 
---
  meta/classes-recipe/image_types_wic.bbclass | 1 +
  meta/conf/distro/include/default-distrovars.inc | 3 ++-
  scripts/lib/wic/canned-wks/mkefidisk.wks| 2 +-
  3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/image_types_wic.bbclass 
b/meta/classes-recipe/image_types_wic.bbclass
index 86f40633ebcb..db598e874ad7 100644
--- a/meta/classes-recipe/image_types_wic.bbclass
+++ b/meta/classes-recipe/image_types_wic.bbclass
@@ -26,6 +26,7 @@ WICVARS ?= "\
INITRD \
INITRD_LIVE \
ISODIR \
+KERNEL_CONSOLE \
KERNEL_IMAGETYPE \
MACHINE \
PSEUDO_IGNORE_PATHS \
diff --git a/meta/conf/distro/include/default-distrovars.inc 
b/meta/conf/distro/include/default-distrovars.inc
index 7554081e8b1a..4d6ddc45b3de 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -1,7 +1,8 @@
  QA_LOGFILE = "${TMPDIR}/qa.log"
  
  OEINCLUDELOGS ?= "yes"

-KERNEL_CONSOLE ?= "ttyS0"
+# if SERIAL_CONSOLES is set, take the first device entry.  Otherwise use ttyS0 
as the default
+KERNEL_CONSOLE ?= "${@','.join(d.getVar('SERIAL_CONSOLES').split(' 
')[0].split(';')[::-1]) or 'ttyS0'}"


Here we removed ",115200" from the default value we used to have in the 
bootloader section of the mkefidisk WKS, is this expected? Are there 
possible side effects from that change?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205108): 
https://lists.openembedded.org/g/openembedded-core/message/205108
Mute This Topic: https://lists.openembedded.org/mt/108564893/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][kirkstone][PATCHv2] kmscube: Add patch to fix -int-conversion build error

2024-09-30 Thread Quentin Schulz via lists.openembedded.org


Hi Purushottam,

This triggers Patchtest because you have "meta-oe" in the mail subject I 
believe. meta-oe patches are not handled on openembedded-core mailing 
list. That patch is for openembedded-core though as it's in OE-Core 
repo, c.f. 
https://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/kmscube.


So I believe removing [meta-oe] from the mail subject will make 
Patchtest happy.


Also, you probably want to have [PATCH v2] and not [PATCHv2] there, I 
don't know if this can trip tools or not. git send-email and 
git-format-patch should be putting this correctly with `-v 2` I believe.


On 9/30/24 9:31 AM, Purushottam Choudhary via lists.openembedded.org wrote:

On some platforms, `EGLNativeDisplayType` is an int instead of
a pointer, in which case the void pointer will raise
a `-Wint-conversion`.



Please provide an explanation as to why this isn't first contributed to 
master and then backported to kirkstone (the reason we discussed in the 
patch for master branch is enough in my opinion).


Looking good otherwise,
Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205099): 
https://lists.openembedded.org/g/openembedded-core/message/205099
Mute This Topic: https://lists.openembedded.org/mt/108731681/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] kmscube: Upgrade to latest revision

2024-09-27 Thread Quentin Schulz via lists.openembedded.org


Hi Purushottam,

On 9/27/24 4:17 PM, Purushottam Kumar wrote:

Hi,

Thanks for the quick response.
Yes, for kirkstone branch need a separate commit but there gstreamer version is
1.20.7.
Please ignore this patch i will share specific change commit for kmscube for
master and kirskstone.



I think this patch is fine for master and scarthgap? Is ther

For kirkstone, we probably want to bump + revert the patch that 
introduces a dependency version we cannot meet, or simply backport only 
the patches you're interested in in kirkstone?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205026): 
https://lists.openembedded.org/g/openembedded-core/message/205026
Mute This Topic: https://lists.openembedded.org/mt/108683960/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] kmscube: Upgrade to latest revision

2024-09-27 Thread Quentin Schulz via lists.openembedded.org


Hi,

On 9/27/24 12:53 PM, Purushottam Choudhary via lists.openembedded.org wrote:

[You don't often get email from 
purushottam27.kumar=lge@lists.openembedded.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

Upgrade to the latest kmscube revision.

Signed-off-by: Purushottam Choudhary 
---
  meta/recipes-graphics/kmscube/kmscube_git.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/kmscube/kmscube_git.bb 
b/meta/recipes-graphics/kmscube/kmscube_git.bb
index 34d5a7d71d..01ea80a142 100644
--- a/meta/recipes-graphics/kmscube/kmscube_git.bb
+++ b/meta/recipes-graphics/kmscube/kmscube_git.bb
@@ -10,7 +10,7 @@ DEPENDS = "virtual/libgles3 virtual/libgles2 virtual/egl libdrm 
virtual/libgbm"

  LIC_FILES_CHKSUM = 
"file://kmscube.c;beginline=1;endline=23;md5=8b309d4ee67b7315ff7381270dd631fb"

-SRCREV = "467e86c5cbeb2a2051b31ce2c240d6ddf5bc3112"
+SRCREV = "b2f97f53e01e07a920761e5d3e3ba22898b794a4"


This seems to bump the gstreamer dependency requirement to 1.22.0 and 
later, which is only supported on mickledore and later so backporting 
(if there is) should only go to scarthgap and not kirkstone.


We may want to do the backporting, c.f.:
https://gitlab.freedesktop.org/mesa/kmscube/-/commit/4961a04b4a434aefbd412eb24fb76998036eaaf6

"""
This solves negotiation issues encountered with V4L2 stateless hardware
video decoders when using kmscube video playback option.
"""

Reviewed-by: Quentin Schulz 

Thanks!
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#205016): 
https://lists.openembedded.org/g/openembedded-core/message/205016
Mute This Topic: https://lists.openembedded.org/mt/108683960/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/5] linux-yocto-dev: bump to v6.11

2024-09-25 Thread Quentin Schulz via lists.openembedded.org


Hi Bruce,

On 9/25/24 3:57 PM, Bruce Ashfield wrote:

On Wed, Sep 25, 2024 at 9:37 AM Quentin Schulz 
wrote:


Hi Bruce,

On 9/24/24 4:11 PM, Bruce Ashfield wrote:

On Tue, Sep 24, 2024 at 9:02 AM Quentin Schulz 
Hi Bruce,

On 8/11/24 8:04 PM, Bruce Ashfield via lists.openembedded.org wrote:

From: Bruce Ashfield 

Signed-off-by: Bruce Ashfield 
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb

b/meta/recipes-kernel/linux/linux-yocto-dev.bb

index 0097fec7b2..292897ce43 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -14,7 +14,7 @@ require recipes-kernel/linux/linux-yocto.inc
# provide this .inc to set specific revisions
include recipes-kernel/linux/linux-yocto-dev-revisions.inc

-KBRANCH = "v6.10/standard/base"
+KBRANCH = "v6.11/standard/base"
KMETA = "kernel-meta"

SRC_URI = "git://



git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;protocol=https
<http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https>

<

http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https



\

@@ -28,7 +28,7 @@ SRC_URI = "git://

git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name

<http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name>

<

http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name



SRCREV_machine ?=

'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}",
"29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'

SRCREV_meta ?=

'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}",
"29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'


-LINUX_VERSION ?= "6.10"
+LINUX_VERSION ?= "6.11"
LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
PV = "${LINUX_VERSION}+git"



I haven't tried to compile linux-yocto-dev but I have my own v6.11-rc6
based kernel recipe.

It failed to build on Scarthgap because I was missing coreutils-native
(specifically truncate binary) because CONFIG_KALLSYMS was enabled. This
comes from



https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1472464c6248575bf2d01c7f076b94704bb32c95


It seems there are some config fragments in linux-yocto-cache
(ktypes/base/base.cfg) with it, so maybe we want to always add the
dependency (or is there a way to add a build time dependency from an
.scc file?).




Interesting!

I build linux-yocto-dev nightly, so I can confidently say that this isn't
being seen with the reference recipe.

I also do have KALLSYMS in the default .config, so I've worked through

the

same new commit and enabling option.

I get truncate in my kernel builds via hosttools, so the dependency
wasn't/isn't needed.



truncate isn't in HOSTTOOLS in any release yet, just master.

c.f.

https://git.openembedded.org/openembedded-core/commit/?id=522000ce5c4f0201cbe42d7826b6a8489ed10117

This means people won't be able to build 6.11 and later with
CONFIG_KALLSYMS enabled in Scarthgap and earlier releases...

... unless we backport this patch to still supported releases?

BTW, I could reproduce on Scarthgap by checking out poky in its
scarthgap branch, then running `git checkout origin/master --
meta/recipes-kernel/linux/linux-yocto-dev.bb`, then adding
`PREFERRED_PROVIDER_virtual/kernel="linux-yocto-dev"` to conf/local.conf
and then running `MACHINE=qemuarm64 bitbake linux-yocto-dev` from either
a kas-container (4.3.2) or Debian Bullseye.



Right. I only target linux-yocto-dev at the latest master where we do all
our testing. The support matrix of ever newer kernels against the older
releases can get complicated, but we can at least say a given release
supports the reference kernels + the reference -dev kernel version.

Anything more we do on a case by case basis.



Oh for sure! I wasn't implying we aren't testing appropriately or that 
we need to increase the number of kernels to support per release. Just 
that **some** people (likely me :) ) may want to support 6.12 on 
Scarthgap whenever it's out and that will be an issue. The answer to 
that issue could very well be "upstream isn't interested in supporting 
this for already-released versions, just handle this in your layer".


I assume one could simply add HOSTTOOLS += "truncate" in the kernel 
recipe and be done with it? I would be worried to add it globally as it 
could then break/change other stuff since the host's tool would be used 
instead of the one in recipe-sysroot

Re: [OE-core] [PATCH 1/5] linux-yocto-dev: bump to v6.11

2024-09-25 Thread Quentin Schulz via lists.openembedded.org


Hi Bruce,

On 9/24/24 4:11 PM, Bruce Ashfield wrote:

On Tue, Sep 24, 2024 at 9:02 AM Quentin Schulz 
wrote:


Hi Bruce,

On 8/11/24 8:04 PM, Bruce Ashfield via lists.openembedded.org wrote:

From: Bruce Ashfield 

Signed-off-by: Bruce Ashfield 
---
   meta/recipes-kernel/linux/linux-yocto-dev.bb | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb

b/meta/recipes-kernel/linux/linux-yocto-dev.bb

index 0097fec7b2..292897ce43 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -14,7 +14,7 @@ require recipes-kernel/linux/linux-yocto.inc
   # provide this .inc to set specific revisions
   include recipes-kernel/linux/linux-yocto-dev-revisions.inc

-KBRANCH = "v6.10/standard/base"
+KBRANCH = "v6.11/standard/base"
   KMETA = "kernel-meta"

   SRC_URI = "git://

git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;protocol=https
<http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https>
\

@@ -28,7 +28,7 @@ SRC_URI = "git://

git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name
<http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name>

   SRCREV_machine ?=

'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}",
"29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'

   SRCREV_meta ?=

'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel",
"linux-yocto-dev", "${AUTOREV}",
"29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'


-LINUX_VERSION ?= "6.10"
+LINUX_VERSION ?= "6.11"
   LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
   PV = "${LINUX_VERSION}+git"



I haven't tried to compile linux-yocto-dev but I have my own v6.11-rc6
based kernel recipe.

It failed to build on Scarthgap because I was missing coreutils-native
(specifically truncate binary) because CONFIG_KALLSYMS was enabled. This
comes from

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1472464c6248575bf2d01c7f076b94704bb32c95

It seems there are some config fragments in linux-yocto-cache
(ktypes/base/base.cfg) with it, so maybe we want to always add the
dependency (or is there a way to add a build time dependency from an
.scc file?).




Interesting!

I build linux-yocto-dev nightly, so I can confidently say that this isn't
being seen with the reference recipe.

I also do have KALLSYMS in the default .config, so I've worked through the
same new commit and enabling option.

I get truncate in my kernel builds via hosttools, so the dependency
wasn't/isn't needed.



truncate isn't in HOSTTOOLS in any release yet, just master.

c.f. 
https://git.openembedded.org/openembedded-core/commit/?id=522000ce5c4f0201cbe42d7826b6a8489ed10117


This means people won't be able to build 6.11 and later with 
CONFIG_KALLSYMS enabled in Scarthgap and earlier releases...


... unless we backport this patch to still supported releases?

BTW, I could reproduce on Scarthgap by checking out poky in its 
scarthgap branch, then running `git checkout origin/master -- 
meta/recipes-kernel/linux/linux-yocto-dev.bb`, then adding 
`PREFERRED_PROVIDER_virtual/kernel="linux-yocto-dev"` to conf/local.conf 
and then running `MACHINE=qemuarm64 bitbake linux-yocto-dev` from either 
a kas-container (4.3.2) or Debian Bullseye.



If we do add the dependency, it is best done in the kernel recipes
themselves, as they are versioned and we'll only pull it in when needed.
Eventually, it migrates to a common dependency as all kernels gain the
requirement over time.

That being said, I'd rather not add coreutils as a dependency until I know
it is really required.

If you try building linux-yocto-dev on that same build machine, can you see
if truncate is present in devshell ? I'm not seeing an obvious path through


Sadly, kas-container doesn't allow me to run -c devshell :/ (well it 
does, but then does nothing :) ).


truncate is available within the container though.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204957): 
https://lists.openembedded.org/g/openembedded-core/message/204957
Mute This Topic: https://lists.openembedded.org/mt/107843657/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/5] linux-yocto-dev: bump to v6.11

2024-09-24 Thread Quentin Schulz via lists.openembedded.org


Hi Bruce,

On 8/11/24 8:04 PM, Bruce Ashfield via lists.openembedded.org wrote:

From: Bruce Ashfield 

Signed-off-by: Bruce Ashfield 
---
  meta/recipes-kernel/linux/linux-yocto-dev.bb | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 0097fec7b2..292897ce43 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -14,7 +14,7 @@ require recipes-kernel/linux/linux-yocto.inc
  # provide this .inc to set specific revisions
  include recipes-kernel/linux/linux-yocto-dev-revisions.inc
  
-KBRANCH = "v6.10/standard/base"

+KBRANCH = "v6.11/standard/base"
  KMETA = "kernel-meta"
  
  SRC_URI = "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;protocol=https \

@@ -28,7 +28,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name
  SRCREV_machine ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", 
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
  SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-yocto-dev", 
"${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
  
-LINUX_VERSION ?= "6.10"

+LINUX_VERSION ?= "6.11"
  LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
  PV = "${LINUX_VERSION}+git"
  


I haven't tried to compile linux-yocto-dev but I have my own v6.11-rc6 
based kernel recipe.


It failed to build on Scarthgap because I was missing coreutils-native 
(specifically truncate binary) because CONFIG_KALLSYMS was enabled. This 
comes from 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1472464c6248575bf2d01c7f076b94704bb32c95


It seems there are some config fragments in linux-yocto-cache 
(ktypes/base/base.cfg) with it, so maybe we want to always add the 
dependency (or is there a way to add a build time dependency from an 
.scc file?).


Is there anything I can help with?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204861): 
https://lists.openembedded.org/g/openembedded-core/message/204861
Mute This Topic: https://lists.openembedded.org/mt/107843657/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] default-distrovars: Have KERNEL_CONSOLE reference SERIAL_CONSOLES

2024-08-30 Thread Quentin Schulz via lists.openembedded.org


Hi Jon,

On 8/29/24 11:41 PM, Jon Mason via lists.openembedded.org wrote:

Currently, KERNEL_CONSOLE has a default value of "ttyS0".  However, Arm
machines and those using virtio serial prefer to use "ttyAMA0" or "hvc0"
(or something else).  These are usually defined by the machine config
file as SERIAL_CONSOLES, which has one or more entries.  Take the first
one of those instead of ttyS0, but default back to ttyS0 if nothing is
set.

Also, use this variable in the efi wic file instead of "ttyS0".

Signed-off-by: Jon Mason 
---
  meta/conf/distro/include/default-distrovars.inc | 3 ++-
  scripts/lib/wic/canned-wks/mkefidisk.wks| 2 +-
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/conf/distro/include/default-distrovars.inc 
b/meta/conf/distro/include/default-distrovars.inc
index 7554081e8b1a..976ff4adc526 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -1,7 +1,8 @@
  QA_LOGFILE = "${TMPDIR}/qa.log"
  
  OEINCLUDELOGS ?= "yes"

-KERNEL_CONSOLE ?= "ttyS0"
+# if SERIAL_CONSOLES is set, take the first device entry.  Otherwise use ttyS0 
as the default
+KERNEL_CONSOLE ?= "${@d.getVar('SERIAL_CONSOLES').split(' 
')[0].split(';')[1]},${@d.getVar('SERIAL_CONSOLES').split(' ')[0].split(';')[0] or 
'ttyS0'}"


I believe this won't work if SERIAL_CONSOLES is the empty string (which 
is the default value in bitbake.conf). I believe we need to check if 
SERIAL_CONSOLES is not empty. I assume we don't need to check if a ';' 
character is present and can be assumed present if non-empty?


Also, because I was curious, the following may work too:

",".join(d.getVar('SERIAL_CONSOLES').split(' ')[0].split(';')[::-1])

would construct the same string with only one d.getVar call, and added 
bonus it works if SERIAL_CONSOLES is empty.



  KEEPUIMAGE ??= "yes"
  
  DEFAULT_IMAGE_LINGUAS = "en-us en-gb"

diff --git a/scripts/lib/wic/canned-wks/mkefidisk.wks 
b/scripts/lib/wic/canned-wks/mkefidisk.wks
index 9f534fe18471..5fa6682a9e10 100644
--- a/scripts/lib/wic/canned-wks/mkefidisk.wks
+++ b/scripts/lib/wic/canned-wks/mkefidisk.wks
@@ -8,4 +8,4 @@ part / --source rootfs --ondisk sda --fstype=ext4 --label 
platform --align 1024
  
  part swap --ondisk sda --size 44 --label swap1 --fstype=swap
  
-bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0"

+bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 
console=${KERNEL_CONSOLE} console=tty0"



I think we need to add this variable to WICVARS?

c.f. 
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image_types_wic.bbclass#n7

https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image_types_wic.bbclass#n99
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/image_types_wic.bbclass#n207

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203969): 
https://lists.openembedded.org/g/openembedded-core/message/203969
Mute This Topic: https://lists.openembedded.org/mt/108169885/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] linux-firmware: package qcom-vpu firmware

2024-08-27 Thread Quentin Schulz via lists.openembedded.org


Hi Dmitry,

On 8/27/24 3:18 PM, Dmitry Baryshkov wrote:
[...]

It's also not necessarily required to merge those together as we could
probably still have two different packages to avoid bringing in files we
don't need (I assume the same SoC doesn't have both a VPU 1.0 and a VPU
2.0 ?).


First of all, the original naming seems to be incorrect as
demonstrated by the new file names:

   qcom/{vpu-1.0/venus.mbn => vpu/vpu20_p4.mbn}| Bin
   qcom/{vpu-2.0/venus.mbn => vpu/vpu20_p1.mbn}| Bin
qcom/{vpu-3.0/vpu30_4v.mbn => vpu/vpu30_p4.mbn} | Bin

It is possible to split one file per package and let users pick up
packages one by one, but granted that the whole size of the directory
(4 different firmware files) is 4.3 MiB, it doesn't seem to make sense
to me.



4.3MiB is quite a lot if you want to be able to have a tiny filesystem :)


Well, these devices come with 64 GiB or 128 GiB UFS storage, so no
need to be that picky.



4MiB here, 4MiB there and your image is unnecessarily tens of MiB bigger 
and your OTA update image is that much bigger, the initrafms/suqashfs 
take that much more space in RAM, to load, to verify, etc... It's also 
not because one of the devices based on this SoC has a lot of UFS 
storage that all of them would.




Ok so, if this
(https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=36db650dae038be945fb04def591fc726255b09f)
is the commit doing the change, we have an issue. We also need to
maintain backward compatibility, not between different versions of
Yocto/OE but between different versions of the kernel (I assume to be
the reason of the need for backward compatibility).

See that they mention in the commit log that they provide
backwards-compatible links, we need those as well. Otherwise we may
broke older kernels we were compatible with in the past.

I did something similar to that in a previous update, c.f.
cdcfdc1dc545fe381764795ed502a3fa0a48b87a in poky.

I would suggest the following:
- keep the packages split
- add the new file in qcom/vpu for each package
- keep the venus.mbn path (which is now a symlink)


I did a simpler thing. I think it's easier and matches the intended usage.



If VPU 1.0 and VPU 2.0 FW packages are self-sufficient, I personally see 
this as a regression rather than making things easier. We have split 
packages, and I don't see a reason for merging them.


I'm no maintainer, so this isn't a decision I should make. Though the 
symlinks absolutely need to be part of the package(s), aside from that 
it's just "policy" or preference :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203845): 
https://lists.openembedded.org/g/openembedded-core/message/203845
Mute This Topic: https://lists.openembedded.org/mt/108120531/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] linux-firmware: package qcom-vpu firmware

2024-08-27 Thread Quentin Schulz via lists.openembedded.org


Hi Dmitry,

On 8/27/24 1:35 PM, Dmitry Baryshkov wrote:

Hi Quentin,

Excuse me, I missed your review before sending v2.

On Tue, 27 Aug 2024 at 13:25, Quentin Schulz  wrote:


Hi Dmitry,

On 8/27/24 12:09 PM, Dmitry Baryshkov via lists.openembedded.org wrote:

Release 20240811 has restructured the locations of Qualcomm VPU
firmware. Follow those changes and implement a single
linux-firmware-qcom-vpu package holding all VPU firmware files. Use
RPROVIDES to provide previously defined names.



It'd be nice to hint at the commits in linux-firmware that do this reorg
for reference?


Ack



It's also not necessarily required to merge those together as we could
probably still have two different packages to avoid bringing in files we
don't need (I assume the same SoC doesn't have both a VPU 1.0 and a VPU
2.0 ?).


First of all, the original naming seems to be incorrect as
demonstrated by the new file names:

  qcom/{vpu-1.0/venus.mbn => vpu/vpu20_p4.mbn}| Bin
  qcom/{vpu-2.0/venus.mbn => vpu/vpu20_p1.mbn}| Bin
qcom/{vpu-3.0/vpu30_4v.mbn => vpu/vpu30_p4.mbn} | Bin

It is possible to split one file per package and let users pick up
packages one by one, but granted that the whole size of the directory
(4 different firmware files) is 4.3 MiB, it doesn't seem to make sense
to me.



4.3MiB is quite a lot if you want to be able to have a tiny filesystem :)

Ok so, if this 
(https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=36db650dae038be945fb04def591fc726255b09f) 
is the commit doing the change, we have an issue. We also need to 
maintain backward compatibility, not between different versions of 
Yocto/OE but between different versions of the kernel (I assume to be 
the reason of the need for backward compatibility).


See that they mention in the commit log that they provide 
backwards-compatible links, we need those as well. Otherwise we may 
broke older kernels we were compatible with in the past.


I did something similar to that in a previous update, c.f. 
cdcfdc1dc545fe381764795ed502a3fa0a48b87a in poky.


I would suggest the following:
- keep the packages split
- add the new file in qcom/vpu for each package
- keep the venus.mbn path (which is now a symlink)

Basically matching what I did for qcom-{qcm2290,qrb4210}-wifi?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203835): 
https://lists.openembedded.org/g/openembedded-core/message/203835
Mute This Topic: https://lists.openembedded.org/mt/108120531/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] [scarthgap][PATCH v2] linux-firmware: add a package for ath12k firmware

2024-08-27 Thread Quentin Schulz via lists.openembedded.org


Hi Dmitry,

On 8/27/24 1:37 PM, Dmitry Baryshkov wrote:

On Tue, 27 Aug 2024 at 14:32, Quentin Schulz  wrote:


Hi Dmitry,

On 8/27/24 12:03 PM, Dmitry Baryshkov via lists.openembedded.org wrote:

From: Bartosz Golaszewski 

Add the firmware package for the ATH12K module.

Signed-off-by: Bartosz Golaszewski 
[DB: added rdepends from PN to PN-ath12k]
Signed-off-by: Dmitry Baryshkov 
---

Changes since v1:
   - Added PN-ath12k to RDEPENDS:PN as not to break users expecting ath12k
 from linux-firmware (Quentin Schulz)



Was it really part of the linux-firmware package? I hadn't checked
myself, it was an assumption.


Yes, it wasn't split to any of the packages, so it was in ${PN}.



ACK.

Reviewed-by: Quentin Schulz 

Thanks!
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203834): 
https://lists.openembedded.org/g/openembedded-core/message/203834
Mute This Topic: https://lists.openembedded.org/mt/108120478/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] [scarthgap][PATCH v2] linux-firmware: add a package for ath12k firmware

2024-08-27 Thread Quentin Schulz via lists.openembedded.org


Hi Dmitry,

On 8/27/24 12:03 PM, Dmitry Baryshkov via lists.openembedded.org wrote:

From: Bartosz Golaszewski 

Add the firmware package for the ATH12K module.

Signed-off-by: Bartosz Golaszewski 
[DB: added rdepends from PN to PN-ath12k]
Signed-off-by: Dmitry Baryshkov 
---

Changes since v1:
  - Added PN-ath12k to RDEPENDS:PN as not to break users expecting ath12k
from linux-firmware (Quentin Schulz)



Was it really part of the linux-firmware package? I hadn't checked 
myself, it was an assumption.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203831): 
https://lists.openembedded.org/g/openembedded-core/message/203831
Mute This Topic: https://lists.openembedded.org/mt/108120478/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/2] linux-firmware: make qcom-sc8280xp-lenovo-x13s-audio install Linaro licence

2024-08-27 Thread Quentin Schulz via lists.openembedded.org


Hi Dmitry,

On 8/27/24 12:12 PM, Dmitry Baryshkov via lists.openembedded.org wrote:

The linux-firmware-qcom-sc8280xp-lenovo-x13s-audio package includes
audio topology file which has separate licensing terms. Make this
package RDEPEND on the corresponding licence package.

Fixes: 958d6a209edf ("linux-firmware: package audio topology for Lenovo X13s")


Reviewed-by: Quentin Schulz 

Thanks!
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203830): 
https://lists.openembedded.org/g/openembedded-core/message/203830
Mute This Topic: https://lists.openembedded.org/mt/108120634/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] linux-firmware: package qcom-vpu firmware

2024-08-27 Thread Quentin Schulz via lists.openembedded.org


Hi Dmitry,

On 8/27/24 12:09 PM, Dmitry Baryshkov via lists.openembedded.org wrote:

Release 20240811 has restructured the locations of Qualcomm VPU
firmware. Follow those changes and implement a single
linux-firmware-qcom-vpu package holding all VPU firmware files. Use
RPROVIDES to provide previously defined names.



It'd be nice to hint at the commits in linux-firmware that do this reorg 
for reference?


It's also not necessarily required to merge those together as we could 
probably still have two different packages to avoid bringing in files we 
don't need (I assume the same SoC doesn't have both a VPU 1.0 and a VPU 
2.0 ?).



Signed-off-by: Dmitry Baryshkov 
---

Changes since v1:
  - Dropped unrelated (audio topology) change.

---
  .../linux-firmware/linux-firmware_20240811.bb| 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb
index b6fb0f9a4560..d55ac9267d8f 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb
@@ -382,7 +382,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
   ${PN}-qed \
   ${PN}-qcom-license ${PN}-qcom-yamato-license \
   ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 ${PN}-qcom-venus-5.2 
${PN}-qcom-venus-5.4 ${PN}-qcom-venus-6.0 \
- ${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0 \
+ ${PN}-qcom-vpu \
   ${PN}-qcom-adreno-a2xx ${PN}-qcom-adreno-a3xx 
${PN}-qcom-adreno-a4xx ${PN}-qcom-adreno-a530 \
   ${PN}-qcom-adreno-a630 ${PN}-qcom-adreno-a650 
${PN}-qcom-adreno-a660 ${PN}-qcom-adreno-a702 \
   ${PN}-qcom-apq8016-modem ${PN}-qcom-apq8016-wifi \
@@ -1368,8 +1368,7 @@ LICENSE:${PN}-qcom-venus-4.2 = "Firmware-qcom"
  LICENSE:${PN}-qcom-venus-5.2 = "Firmware-qcom"
  LICENSE:${PN}-qcom-venus-5.4 = "Firmware-qcom"
  LICENSE:${PN}-qcom-venus-6.0 = "Firmware-qcom"
-LICENSE:${PN}-qcom-vpu-1.0 = "Firmware-qcom"
-LICENSE:${PN}-qcom-vpu-2.0 = "Firmware-qcom"
+LICENSE:${PN}-qcom-vpu = "Firmware-qcom"
  LICENSE:${PN}-qcom-adreno-a2xx = "Firmware-qcom Firmware-qcom-yamato"
  LICENSE:${PN}-qcom-adreno-a3xx = "Firmware-qcom"
  LICENSE:${PN}-qcom-adreno-a4xx = "Firmware-qcom"
@@ -1413,7 +1412,11 @@ FILES:${PN}-qcom-venus-4.2 = 
"${nonarch_base_libdir}/firmware/qcom/venus-4.2/*"
  FILES:${PN}-qcom-venus-5.2 = 
"${nonarch_base_libdir}/firmware/qcom/venus-5.2/*"
  FILES:${PN}-qcom-venus-5.4 = 
"${nonarch_base_libdir}/firmware/qcom/venus-5.4/*"
  FILES:${PN}-qcom-venus-6.0 = 
"${nonarch_base_libdir}/firmware/qcom/venus-6.0/*"
-FILES:${PN}-qcom-vpu-1.0 = "${nonarch_base_libdir}/firmware/qcom/vpu-1.0/*"
+FILES:${PN}-qcom-vpu = " \
+${nonarch_base_libdir}/firmware/qcom/vpu/* \
+${nonarch_base_libdir}/firmware/qcom/vpu-1.0/* \
+${nonarch_base_libdir}/firmware/qcom/vpu-2.0/* \
+"
  FILES:${PN}-qcom-vpu-2.0 = "${nonarch_base_libdir}/firmware/qcom/vpu-2.0/*"


If we're deleting qcom-vpu-* PACKAGES, then you missed this one line to 
delete.



  FILES:${PN}-qcom-adreno-a2xx = "${nonarch_base_libdir}/firmware/qcom/leia_*.fw 
${nonarch_base_libdir}/firmware/qcom/yamato_*.fw"
  FILES:${PN}-qcom-adreno-a3xx = "${nonarch_base_libdir}/firmware/qcom/a3*_*.fw 
${nonarch_base_libdir}/firmware/a300_*.fw"
@@ -1458,8 +1461,7 @@ RDEPENDS:${PN}-qcom-venus-4.2 = "${PN}-qcom-license"
  RDEPENDS:${PN}-qcom-venus-5.2 = "${PN}-qcom-license"
  RDEPENDS:${PN}-qcom-venus-5.4 = "${PN}-qcom-license"
  RDEPENDS:${PN}-qcom-venus-6.0 = "${PN}-qcom-license"
-RDEPENDS:${PN}-qcom-vpu-1.0 = "${PN}-qcom-license"
-RDEPENDS:${PN}-qcom-vpu-2.0 = "${PN}-qcom-license"
+RDEPENDS:${PN}-qcom-vpu = "${PN}-qcom-license"
  RDEPENDS:${PN}-qcom-adreno-a2xx = "${PN}-qcom-license 
${PN}-qcom-yamato-license"
  RDEPENDS:${PN}-qcom-adreno-a3xx = "${PN}-qcom-license"
  RDEPENDS:${PN}-qcom-adreno-a4xx = "${PN}-qcom-license"
@@ -1503,6 +1505,8 @@ RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-adreno = 
"${PN}-qcom-sc8280xp-lenovo
  RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-compute = 
"${PN}-qcom-sc8280xp-lenovo-x13s-compat"
  RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-sensors = 
"${PN}-qcom-sc8280xp-lenovo-x13s-compat"
  
+RPROVIDES:${PN}-qcom-vpu = "${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0"

+


I'm of the opinion this does not make sense in master branch, backward 
compatibility is not required in master branch so we can just not have 
this line and let people update their dependencies if needed. I'll let 
maintainers decide here what's best :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203826): 
https://lists.openembedded.org/g/openembedded-core/message/203826
Mute This Topic: https://lists.openembedded.org/mt/108120531/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org

[OE-core] [PATCH scarthgap] weston-init: fix weston not starting when xwayland is enabled

2024-08-26 Thread Quentin Schulz

From: Quentin Schulz 

When xwayland PACKAGECONFIG option is set, xwayland is enabled in
weston.ini. However, if the xwayland module isn't installed, weston will
refuse to start with the following error message:
Failed to load module: /usr/lib/libweston-13/xwayland.so: cannot open shared 
object file: No such file or directory

Therefore, whenever the xwayland PACKAGECONFIG is set, weston-init
should depend on weston-xwayland to bring this module in.

(cherry picked from commit fa2314125318634108452af4e40c9260767c)

Fixes: fdbe559c66c9 ("weston.init: enabled xwayland")
Signed-off-by: Quentin Schulz 
Signed-off-by: Richard Purdie 
Signed-off-by: Quentin Schulz 
---
 meta/recipes-graphics/wayland/weston-init.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/wayland/weston-init.bb 
b/meta/recipes-graphics/wayland/weston-init.bb
index 024e400665..34b7eb78d2 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -83,7 +83,7 @@ USERADD_PACKAGES = "${PN}"
 #
 require ${THISDIR}/required-distro-features.inc
 
-RDEPENDS:${PN} = "weston kbd"
+RDEPENDS:${PN} = "weston kbd ${@bb.utils.contains('PACKAGECONFIG', 'xwayland', 
'weston-xwayland', '', d)}"
 
 INITSCRIPT_NAME = "weston"
 INITSCRIPT_PARAMS = "start 9 5 2 . stop 20 0 1 6 ."

---
base-commit: 0795169be206f1d4d140fe378e2476a44d0ce02b
change-id: 20240826-weston-init-xwayland-scarthgap-9923eeaef8cd

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203756): 
https://lists.openembedded.org/g/openembedded-core/message/203756
Mute This Topic: https://lists.openembedded.org/mt/108105573/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] [scarthgap][PATCH] linux-firmware: add a package for ath12k firmware

2024-08-26 Thread Quentin Schulz via lists.openembedded.org


Hi Dmitry,

On 8/26/24 3:39 AM, Dmitry Baryshkov via lists.openembedded.org wrote:

From: Bartosz Golaszewski 

Add the firmware package for the ATH12K module.

Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Dmitry Baryshkov 
---
  .../linux-firmware/linux-firmware_20240312.bb  | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
index ff79bb9b33c6..53851b58fede 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
@@ -322,7 +322,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
   ${PN}-cnm-license ${PN}-cnm \
   ${PN}-atheros-license ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k 
${PN}-ath9k ${PN}-ath3k \
   ${PN}-carl9170 \
- ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
${PN}-ath11k ${PN}-qca \
+ ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
${PN}-ath11k ${PN}-ath12k ${PN}-qca \
   \
   ${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d 
\
   \
@@ -487,6 +487,10 @@ FILES:${PN}-ath11k = " \
${nonarch_base_libdir}/firmware/ath11k \
  "
  
+FILES:${PN}-ath12k = " \

+  ${nonarch_base_libdir}/firmware/ath12k \
+"
+
  FILES:${PN}-qca = " \
${nonarch_base_libdir}/firmware/qca \
  "
@@ -494,6 +498,7 @@ FILES:${PN}-qca = " \
  RDEPENDS:${PN}-ar3k += "${PN}-ar3k-license ${PN}-atheros-license"
  RDEPENDS:${PN}-ath10k += "${PN}-ath10k-license"
  RDEPENDS:${PN}-ath11k += "${PN}-ath10k-license"
+RDEPENDS:${PN}-ath12k += "${PN}-ath10k-license"


I don't think this is appropriate for a release branch.

This would break existing users by moving the same file to a different 
package. This is fine for the master branch, not release branches.


Since I cannot see any firmware/ath12k paths in any FILES aside from the 
one added in this commit, I believe this directory was caught by the 
catch-all linux-firmware mega-package? If that is the case, then to 
still allow for backward compatibility, add the following:


RDEPENDS:${PN] += "${PN}-ath12k"

so that anyone installing/depending on linux-firmware package for this 
directory will still have it after updating.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203755): 
https://lists.openembedded.org/g/openembedded-core/message/203755
Mute This Topic: https://lists.openembedded.org/mt/108097108/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] weston-init: fix weston not starting when xwayland is enabled

2024-08-21 Thread Quentin Schulz

From: Quentin Schulz 

When xwayland PACKAGECONFIG option is set, xwayland is enabled in
weston.ini. However, if the xwayland module isn't installed, weston will
refuse to start with the following error message:
Failed to load module: /usr/lib/libweston-13/xwayland.so: cannot open shared 
object file: No such file or directory

Therefore, whenever the xwayland PACKAGECONFIG is set, weston-init
should depend on weston-xwayland to bring this module in.

Fixes: fdbe559c66c9 ("weston.init: enabled xwayland")
Signed-off-by: Quentin Schulz 
---
This should also be backported to scarthgap (kirkstone is not impacted
as the commit which introduced the bug isn't part of kirkstone).
---
 meta/recipes-graphics/wayland/weston-init.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/wayland/weston-init.bb 
b/meta/recipes-graphics/wayland/weston-init.bb
index 83f0cea49c..3de697ec34 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -84,7 +84,7 @@ USERADD_PACKAGES = "${PN}"
 #
 require ${THISDIR}/required-distro-features.inc
 
-RDEPENDS:${PN} = "weston kbd"
+RDEPENDS:${PN} = "weston kbd ${@bb.utils.contains('PACKAGECONFIG', 'xwayland', 
'weston-xwayland', '', d)}"
 
 INITSCRIPT_NAME = "weston"
 INITSCRIPT_PARAMS = "start 9 5 2 . stop 20 0 1 6 ."

---
base-commit: 30ee6edc57ff7629a72606d1005f92d43a5d14f9
change-id: 20240821-weston-init-xwayland-4dba6e694321

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203580): 
https://lists.openembedded.org/g/openembedded-core/message/203580
Mute This Topic: https://lists.openembedded.org/mt/108016483/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][scarthgap][PATCH] rust: Add new varaible RUST_ENABLE_EXTRA_TOOLS

2024-08-01 Thread Quentin Schulz via lists.openembedded.org


Hi Ranjitsinh,

Is this not compatible with master? If so, why? If not, please send the 
patch for the master branch (just remove the [scarthgap] prefix) first, 
then we can backport it to still-maintained branches once merged in master.


The rule is basically: master first then backport or master not 
compatible thus only impacted branches.


Cheers,
Quentin

On 8/1/24 2:54 PM, Ranjitsinh Rathod via lists.openembedded.org wrote:

[You don't often get email from 
ranjitsinh.rathod=kpit@lists.openembedded.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

There is a need to enable some extra tools from the rust for the build
and so this new variable will help for that

This varaible then we can use during do_configure task to add overall
values as per json format in build -> tools

Signed-off-by: Ranjitsinh Rathod 
---
  meta/recipes-devtools/rust/rust_1.75.0.bb | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/rust/rust_1.75.0.bb 
b/meta/recipes-devtools/rust/rust_1.75.0.bb
index 76e1fe2d84..c33f31d261 100644
--- a/meta/recipes-devtools/rust/rust_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.75.0.bb
@@ -70,6 +70,10 @@ addtask do_test_compile after do_configure 
do_rust_gen_targets
  do_rust_setup_snapshot[dirs] += "${WORKDIR}/rust-snapshot"
  do_rust_setup_snapshot[vardepsexclude] += "UNINATIVE_LOADER"

+# there is a need to enable some more rust tools for the project
+# We can extend a list of more tools via this variable
+RUST_ENABLE_EXTRA_TOOLS ?= "rust-demangler"
+
  python do_configure() {
  import json
  import configparser
@@ -141,7 +145,7 @@ python do_configure() {
  config.add_section("build")
  config.set("build", "submodules", e(False))
  config.set("build", "docs", e(False))
-config.set("build", "tools", ["rust-demangler",])
+config.set("build", "tools", 
e(d.getVar("RUST_ENABLE_EXTRA_TOOLS").split()))

  rustc = d.expand("${WORKDIR}/rust-snapshot/bin/rustc")
  config.set("build", "rustc", e(rustc))
--
2.25.1

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#202731): 
https://lists.openembedded.org/g/openembedded-core/message/202731
Mute This Topic: https://lists.openembedded.org/mt/107665271/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] How to contribute in meta-lts-mixins layer?

2024-07-29 Thread Quentin Schulz via lists.openembedded.org


Hi Ranjitsinh,

On 7/29/24 3:52 PM, Ranjitsinh Rathod via lists.openembedded.org wrote:

You don't often get email from ranjitsinh.rathod=kpit@lists.openembedded.org. 
Learn why this is important
Hello all,

I want to contribute for the layer meta-lts-mixins for kirkstone/rust branch. 
Does anyone suggest which email and labels to use to do contribution for this 
layer? I did not find any specific contribute guide or details in the 
repository. Any help is appreciated.



I think yocto-patches is the appropriate ML?

https://lists.yoctoproject.org/g/yocto-patches/message/8 is a patch for 
meta-lts-mixins scarthgap/u-boot branch I think.


Adding the maintainer in Cc, they would/should know :)

Here's to hoping on of your first patch is adding this information to 
the different branches' README :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#202653): 
https://lists.openembedded.org/g/openembedded-core/message/202653
Mute This Topic: https://lists.openembedded.org/mt/107608903/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][PATCHv3] mesa: update 24.0.7 -> 24.1.4

2024-07-22 Thread Quentin Schulz via lists.openembedded.org


Hi Markus,

On 7/20/24 3:36 PM, Markus Volk via lists.openembedded.org wrote:

  - Remove two patches that have been merged upstream
  - Remove 0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
Upstream managed to fix this:

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson.build?ref_type=heads#L839
  - Drop OPENCL_NATIVE since the according option has been removed from 
meson_options.txt
  - Update 0001-freedreno-don-t-encode-build-path-into-binaries.patch
  - gallium-iris and intel-vulkan both require libclc. Make them dependent opn 
opencl
PACKAGECONFIG

Signed-off-by: Markus Volk 
---
  ...-meson-do-not-pull-in-clc-for-clover.patch | 53 --
  .../0001-drisw-fix-build-without-dri3.patch   | 58 ---
  ...on-t-encode-build-path-into-binaries.patch | 71 +++
  ...on-t-try-zink-if-not-enabled-in-mesa.patch | 42 ---
  .../{mesa-gl_24.0.7.bb => mesa-gl_24.1.4.bb}  |  0
  meta/recipes-graphics/mesa/mesa.inc   | 23 +++---
  .../mesa/{mesa_24.0.7.bb => mesa_24.1.4.bb}   |  0
  7 files changed, 68 insertions(+), 179 deletions(-)
  delete mode 100644 
meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
  delete mode 100644 
meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch
  delete mode 100644 
meta/recipes-graphics/mesa/files/0002-glxext-don-t-try-zink-if-not-enabled-in-mesa.patch
  rename meta/recipes-graphics/mesa/{mesa-gl_24.0.7.bb => mesa-gl_24.1.4.bb} 
(100%)
  rename meta/recipes-graphics/mesa/{mesa_24.0.7.bb => mesa_24.1.4.bb} (100%)

diff --git 
a/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
 
b/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
deleted file mode 100644
index 1711e22585..00
--- 
a/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-From 051f41beda540f0ae77b341db01a6de83c9e938a Mon Sep 17 00:00:00 2001
-From: Markus Volk 
-Date: Fri, 8 Mar 2024 15:53:11 +0100
-Subject: [PATCH] Revert "meson: do not pull in clc for clover"
-
-This reverts commit 815a6647eb1383e9dc704ffcc266d85f3b13338a.
-Upstream-Status: Inappropriate 
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27783/diffs?commit_id=a976f2c9f0c07f9e06cc9affd9124b45bc60c2bd]
-
-Once the merge request above was added, it will only be possible to provide 
opencl spir-v with gallium-rusticl=true. This is not yet supported in the mesa 
recipe.
-For now reverting this commit allows to still use clover with opencl-spirv, 
which would otherwise be broken starting from mesa 24.0.2.
-
-After it was merged, this patch needs to be removed and rusticl support will 
be required
-
-Signed-off-by: Markus Volk 

- meson.build  | 3 ++-
- src/compiler/meson.build | 2 +-
- 2 files changed, 3 insertions(+), 2 deletions(-)
-
-diff --git a/meson.build b/meson.build
-index 2db6185..741b5d1 100644
 a/meson.build
-+++ b/meson.build
-@@ -813,6 +813,7 @@ if _opencl != 'disabled'
- error('The Clover OpenCL state tracker requires rtti')
-   endif
-
-+  with_clc = true
-   with_gallium_opencl = true
-   with_opencl_icd = _opencl == 'icd'
- else
-@@ -837,7 +838,7 @@ if with_gallium_rusticl
- endif
-
- dep_clc = null_dep
--if with_gallium_opencl or with_clc
-+if with_clc
-   dep_clc = dependency('libclc')
- endif
-
-diff --git a/src/compiler/meson.build b/src/compiler/meson.build
-index 8d73544..1dae56d 100644
 a/src/compiler/meson.build
-+++ b/src/compiler/meson.build
-@@ -79,7 +79,7 @@ subdir('nir')
-
- subdir('spirv')
-
--if with_clc
-+if with_opencl_spirv
-   subdir('clc')
- endif
- if with_gallium
diff --git 
a/meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch 
b/meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch
deleted file mode 100644
index ab16152090..00
--- a/meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From 4bd15a419e892da843489c374c58c5b29c40b5d6 Mon Sep 17 00:00:00 2001
-From: Romain Naour 
-Date: Tue, 6 Feb 2024 09:47:09 +0100
-Subject: [PATCH 1/2] drisw: fix build without dri3
-
-commit 1887368df41 ("glx/sw: check for modifier support in the kopper path")
-added dri3_priv.h header and dri3_check_multibuffer() function in drisw that
-can be build without dri3.
-
-  i686-buildroot-linux-gnu/bin/ld: src/glx/libglx.a.p/drisw_glx.c.o: in 
function `driswCreateScreenDriver':
-  drisw_glx.c:(.text.driswCreateScreenDriver+0x3a0): undefined reference to 
`dri3_check_multibuffer'
-  collect2: error: ld returned 1 exit status
-
-Add HAVE_DRI3 guard around dri3_priv.h header and the zink code using
-dri3_check_multibuffer().
-
-Fixes: 1887368df41 ("glx/sw: check for modifier support in the kopper path")
-
-Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27478]
-Signed-off-by: Romain Naour 
-Si

Re: [OE-core] [kirkstone][PATCH] uboot-sign: Fix index error in concat_dtb_helper() with multiple configs

2024-07-02 Thread Quentin Schulz via lists.openembedded.org


Hi Florian,

On 7/2/24 10:14 AM, Florian Amstutz via lists.openembedded.org wrote:

You don't often get email from florian.amstutz=scs...@lists.openembedded.org. Learn 
why this is important
Since j is not unset after the inner loop, the image will only be copied
for the first configuration.


Signed-off-by: Florian Amstutz 
---
  meta/classes/uboot-sign.bbclass | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 6bb4ddc600..5b75c8a3b0 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -137,8 +137,7 @@ concat_dtb_helper() {

 if [ -n "${UBOOT_CONFIG}" ]
 then
-   i=0
-   j=0
+   unset i j


What about only unsetting i and j wherever actually needed?

I.e.

unset i

here


 for config in ${UBOOT_MACHINE}; do
 i=$(expr $i + 1);


unset j

here


 for type in ${UBOOT_CONFIG}; do
@@ -148,7 +147,9 @@ concat_dtb_helper() {
 cp ${UBOOT_IMAGE} 
${B}/${CONFIG_B_PATH}/u-boot-$type.${UBOOT_SUFFIX}


Breaking here would make a lot of (/more?) sense, we're otherwise 
looping unnecessarily.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201426): 
https://lists.openembedded.org/g/openembedded-core/message/201426
Mute This Topic: https://lists.openembedded.org/mt/106996337/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] u-boot: Fix potential index error issues in do_deploy with multiple u-boot configurations

2024-07-02 Thread Quentin Schulz via lists.openembedded.org


Hi Florian,

On 7/2/24 10:16 AM, Florian Amstutz via lists.openembedded.org wrote:

You don't often get email from florian.amstutz=scs...@lists.openembedded.org. Learn 
why this is important
If i or j have not been unset in do_deploy:prepend functions, images are not 
correctly
copied to DEPLOYDIR.

Signed-off-by: Florian Amstutz 
---
  meta/recipes-bsp/u-boot/u-boot.inc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 54ea2e9e50..70fb192d6e 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -209,6 +209,7 @@ RDEPENDS:${PN} += "${PN}-env"
  do_deploy () {
  if [ -n "${UBOOT_CONFIG}" ]
  then
+unset i j


There are a LOT more of those missing in do_install, do_deploy, etc... 
could you please fix all of them? I imagine that we can also remove the 
`unset` after the for-loops if they are done before the for-loop?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201425): 
https://lists.openembedded.org/g/openembedded-core/message/201425
Mute This Topic: https://lists.openembedded.org/mt/106996344/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/2] librsvg: don't try to run target code at build time

2024-07-01 Thread Quentin Schulz via lists.openembedded.org


Hi Ross,

On 6/27/24 7:23 PM, Ross Burton via lists.openembedded.org wrote:

The rsvg-loader test binary isn't installed but building it causes a mix
of build host and target code to be executed.  As we don't install the
test, don't build it.

Signed-off-by: Ross Burton 
---
  .../librsvg/disable-rsvg-loader-test.patch| 40 +++
  meta/recipes-gnome/librsvg/librsvg_2.57.1.bb  |  1 +
  2 files changed, 41 insertions(+)
  create mode 100644 
meta/recipes-gnome/librsvg/librsvg/disable-rsvg-loader-test.patch

diff --git a/meta/recipes-gnome/librsvg/librsvg/disable-rsvg-loader-test.patch 
b/meta/recipes-gnome/librsvg/librsvg/disable-rsvg-loader-test.patch
new file mode 100644
index 000..e56772a7e2f
--- /dev/null
+++ b/meta/recipes-gnome/librsvg/librsvg/disable-rsvg-loader-test.patch
@@ -0,0 +1,40 @@
+From df94cfa4a637c229fef32c349b5c2dfee2dca3fc Mon Sep 17 00:00:00 2001
+From: Ross Burton 
+Date: Thu, 27 Jun 2024 17:09:11 +0100
+Subject: [PATCH] Don't build rsvg-loader in cross builds
+
+This binary is a non-installed test binary that isn't any use in cross builds, 
and
+causes problems because it generates a gdk-pixbuf loader cache at build time 
using
+a mix of host and target libraries.
+
+As we don't install the binary, we can just not build it.
+
+Upstream-Status: Inappropriate [upstream has moved to Meson]


Will we have the same issue once we bump librsvg to a version that uses 
Meson? If yes, it would be a good opportunity to fix it now in Meson too 
so that we can benefit from the moment we migrate to the Meson-able release?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201282): 
https://lists.openembedded.org/g/openembedded-core/message/201282
Mute This Topic: https://lists.openembedded.org/mt/106913110/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] u-boot.inc: WORKDIR -> UNPACKDIR transition

2024-06-26 Thread Quentin Schulz via lists.openembedded.org


Hi Richard,

On 6/26/24 3:20 PM, Richard Purdie via lists.openembedded.org wrote:

On Mon, 2024-06-24 at 00:32 +0300, Leon Anavi via lists.openembedded.org wrote:

Replace references of WORKDIR with UNPACKDIR for U-Boot script
and variable UBOOT_ENV_BINARY, for example for boot.scr.

Signed-off-by: Leon Anavi 
---
  meta/recipes-bsp/u-boot/u-boot.inc | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 45d700fbdd..9a91a0e3d8 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -92,7 +92,7 @@ do_compile () {
  
  if [ -n "${UBOOT_ENV}" ] && [ "${UBOOT_ENV_SUFFIX}" = "scr" ]

  then
-    ${UBOOT_MKIMAGE} -C none -A ${UBOOT_ARCH} -T script -d 
${WORKDIR}/${UBOOT_ENV_SRC} ${WORKDIR}/${UBOOT_ENV_BINARY}
+    ${UBOOT_MKIMAGE} -C none -A ${UBOOT_ARCH} -T script -d 
${UNPACKDIR}/${UBOOT_ENV_SRC} ${UNPACKDIR}/${UBOOT_ENV_BINARY}
  fi
  }



If that command is writing a file, the written file should remain in
WORKDIR, not UNPACKDIR. I suspect the SRC should probably therefore be
changed but not the BINARY?


WORKDIR still isn't cleaned between builds of a recipe I assume? While 
migrating to UNPACKDIR gets rid of patches that were once in SRC_URI but 
aren't anymore (or other files for that matter), using WORKDIR as a 
temporary directory between tasks is going to be an issue depending on 
how the other tasks are going to behave. If the logic using the file is 
the same as the logic for creating the file then it shouldn't be an 
issue. But if the logic using the file is just checking whether the file 
exists, then using WORKDIR is an issue since it won't be cleaned between 
builds of the same recipe.


Maybe we should go for ${B} instead?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201163): 
https://lists.openembedded.org/g/openembedded-core/message/201163
Mute This Topic: https://lists.openembedded.org/mt/106839442/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] mesa: build failure in CI, dependency not found

2024-06-05 Thread Quentin Schulz via lists.openembedded.org


Hi Alex, Markus,

On 6/5/24 1:35 PM, Alexander Kanavin wrote:

I think we could ask Markus to look at this update to 24.1, as he's
done work with libclc  dependency previously (and authored the patch
for it, which should preferably be dropped).



Yeah, I'm hitting a lot of issues right now :/

I can provide the following info already though (patches not tested):

"""
commit 9d03be215762c45ad547446a29865c20c9ed4c2c
Author: Quentin Schulz 
Date:   Wed Jun 5 13:31:29 2024 +0200

mesa: enable RayTracing by default on intel if clc is enabled

This was the default before 012489e55ce3c88615c5fb2667e10e9cfd7b7edb

    Signed-off-by: Quentin Schulz 

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc

index cb1c9b7b349..a2314a6f22e 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -73,7 +73,7 @@ EXTRA_OEMESON = " \
 "

 EXTRA_OEMESON:append:class-target = " 
${@bb.utils.contains('PACKAGECONFIG', 'opencl', '-Dintel-clc=system', 
'', d)}"
-EXTRA_OEMESON:append:class-native = " 
${@bb.utils.contains('PACKAGECONFIG', 'opencl', '-Dintel-clc=enabled', 
'', d)}"
+EXTRA_OEMESON:append:class-native = " 
${@bb.utils.contains('PACKAGECONFIG', 'opencl', '-Dintel-clc=enabled 
-Dintel-rt=enabled', '', d)}"


 def strip_comma(s):
 return s.strip(',')
"""
"""
commit d0fbbca90047248d97ddcc90e3699dfb998f3fad
Author: Quentin Schulz 
Date:   Wed Jun 5 13:54:16 2024 +0200

mesa: use new option for installing intel_clc binary

Comes from 1e31fd5f4268b134b26cd9d82d76d406332a3d8d

Signed-off-by: Quentin Schulz 

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc

index cbd2a11b6ef..3b32ff635a1 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -73,7 +73,7 @@ EXTRA_OEMESON = " \
 "

 EXTRA_OEMESON:append:class-target = " 
${@bb.utils.contains('PACKAGECONFIG', 'opencl', '-Dintel-clc=system', 
'', d)}"
-EXTRA_OEMESON:append:class-native = " 
${@bb.utils.contains('PACKAGECONFIG', 'opencl', '-Dintel-clc=enabled 
-Dintel-rt=enabled', '', d)}"
+EXTRA_OEMESON:append:class-native = " 
${@bb.utils.contains('PACKAGECONFIG', 'opencl', '-Dintel-clc=enabled 
-Dintel-rt=enabled -Dinstall-intel-clc=true', '', d)}"


 def strip_comma(s):
 return s.strip(',')
@@ -254,13 +254,6 @@ do_install:append () {
 rm -f ${D}${libdir}/pkgconfig/wayland-egl.pc
 }

-do_install:append:class-native () {
-if ${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'true', 'false', 
d)}; then

-install -d ${D}${bindir}
-install -m0755 ${B}/src/intel/compiler/intel_clc ${D}${bindir}
-fi
-}
-
 # For the packages that make up the OpenGL interfaces, inject 
variables so that

 # they don't get Debian-renamed (which would remove the -mesa suffix), and
 # RPROVIDEs/RCONFLICTs on the generic libgl name.
"""

Additionally, Intel Vulkan driver forces libclc dependency if intel-clc 
option is not "system" (so either "enabled" or "disabled" or "auto"), 
since commit b52e25d3a8eee702ff5d21e4cdb9a4dc0736282a.


Moreover, Intel Iris Gallium driver forces libclc dependency if 
intel-clc option is not "system", since commit 
5438b1910464e4b17fe0248a96a6ed98f0280a20.


Now, if I add libclc to the dependencies, I need meta-clang for this but 
then llvm + libclc as DEPENDS is not working, I get the following error:

"""
Exception: FileExistsError: [Errno 17] File exists: 
'/hdd5tb/qschulz/work/upstream/yocto/build/tmp/sysroots-components/x86_64/clang-native/usr/lib/libLLVMPasses.a' 
-> 
'/hdd5tb/qschulz/work/upstream/yocto/build/tmp/work/x86_64-linux/mesa-native/24.1.0/recipe-sysroot-native/usr/lib/libLLVMPasses.a'

"""

We probably also should migrate to rusticl instead of keeping Markus's 
patch but I have no idea how to do that properly.


Finally, I have no clue how to test any of this so even if it passes the 
build, I wouldn't be able to trust it works :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200362): 
https://lists.openembedded.org/g/openembedded-core/message/200362
Mute This Topic: https://lists.openembedded.org/mt/106464279/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 3/3] mesa: add new package for Mali CSFFW Valhall firmware

2024-06-04 Thread Quentin Schulz via lists.openembedded.org


Hi Richard,

On 6/4/24 4:59 PM, Richard Purdie wrote:

On Tue, 2024-06-04 at 16:23 +0200, Quentin Schulz via
lists.openembedded.org wrote:

Hi all,

The title is misleading, this isn't for mesa but for linux-firmware.

I know this has been reverted in master-next


has it? :/

I don't see that...



Well, I should have said "removed" and not from master-next but from 
abelloni/master-next in poky-contrib. It used to be there (got a mail in 
the ML from the SWAT team complaining about broken mesa build recently).


I'm trying to figure out the changes needed for this mesa update (the 
patch 2 in this series), but this getting quite difficult as I have no 
experience with mesa nor meson and the changes aren't trivial to me 
reading the git log of all meson files in the repo.


What I can say already is that it seems the iris Gallium driver now 
requires libclc as well, which means mesa-native as built on x86 hosts 
will require that, which means bringing in meta-clang... I'll continue 
to investigate a bit more to at least get something to compile (if I can 
manage to) on my x86 build machine, both mesa and mesa-native in its 
default PACKAGECONFIG config from current master, and then hopefully 
send an RFC and we can discuss there. The whole migration from clc to 
rusticl for some drivers is also confusing me, so will probably need 
some help there, especially since we have this commit already in the 
last (few?) release(s): 
https://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200341): 
https://lists.openembedded.org/g/openembedded-core/message/200341
Mute This Topic: https://lists.openembedded.org/mt/106406257/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 3/3] mesa: add new package for Mali CSFFW Valhall firmware

2024-06-04 Thread Quentin Schulz via lists.openembedded.org


Hi all,

The title is misleading, this isn't for mesa but for linux-firmware.

I know this has been reverted in master-next but I think we should be 
able to take it in, even if the mesa changes don't make it just yet as 
they aren't really dependent on each other except if someone wants to 
use open-source mesa on RK3588(S).


Cheers,
Quentin

On 5/31/24 1:53 PM, Quentin Schulz wrote:

From: Quentin Schulz 

This firmware is necessary for closed-source mali blob + drivers and
open-source Panthor (via Mesa + Linux kernel) drivers.

Signed-off-by: Quentin Schulz 
---
  meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
index 026e5dba00..4a87105d98 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
@@ -39,6 +39,7 @@ LICENSE = "\
  & Firmware-kaweth \
  & Firmware-linaro \
  & Firmware-Lontium \
+& Firmware-mali_csffw \
  & Firmware-Marvell \
  & Firmware-mediatek \
  & Firmware-microchip \
@@ -113,6 +114,7 @@ LIC_FILES_CHKSUM = 
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
  
file://LICENCE.kaweth;md5=b1d876e562f4b3b8d391ad8395dfe03f \
  
file://LICENCE.linaro;md5=936d91e71cf9cd30e733db4bf11661cc \
  
file://LICENSE.Lontium;md5=4ec8dc582ff7295f39e2ca6a7b0be2b6 \
+
file://LICENCE.mali_csffw;md5=e064aaec4d21ef856e1b76a6f5dc435f \
  
file://LICENCE.Marvell;md5=28b6ed8bd04ba105af6e4dcd6e997772 \
  
file://LICENCE.mediatek;md5=7c1976b63217d76ce47d0a11d8a79cf2 \
  
file://LICENCE.microchip;md5=db753b00305675dfbf120e3f24a47277 \
@@ -192,6 +194,7 @@ NO_GENERIC_LICENSE[Firmware-iwlwifi_firmware] = 
"LICENCE.iwlwifi_firmware"
  NO_GENERIC_LICENSE[Firmware-kaweth] = "LICENCE.kaweth"
  NO_GENERIC_LICENSE[Firmware-linaro] = "LICENCE.linaro"
  NO_GENERIC_LICENSE[Firmware-Lontium] = "LICENSE.Lontium"
+NO_GENERIC_LICENSE[Firmware-mali_csffw] = "LICENCE.mali_csffw"
  NO_GENERIC_LICENSE[Firmware-Marvell] = "LICENCE.Marvell"
  NO_GENERIC_LICENSE[Firmware-mediatek] = "LICENCE.mediatek"
  NO_GENERIC_LICENSE[Firmware-microchip] = "LICENCE.microchip"
@@ -354,6 +357,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
   ${PN}-bnx2 \
   ${PN}-bnx2x \
   ${PN}-liquidio \
+ ${PN}-mali-csffw-arch108 ${PN}-mali-csffw-license \
   ${PN}-mellanox \
   ${PN}-nvidia-license \
   ${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \
@@ -608,6 +612,13 @@ LICENSE:${PN}-lt9611uxc = "Firmware-Lontium"
  FILES:${PN}-lontium-license = 
"${nonarch_base_libdir}/firmware/LICENSE.Lontium"
  FILES:${PN}-lt9611uxc = "${nonarch_base_libdir}/firmware/lt9611uxc_fw.bin"
  
+# For Arm Mali

+LICENSE:${PN}-mali-csffw-arch108 = "Firmware-mali_csffw"
+FILES:${PN}-mali-csffw-license = 
"${nonarch_base_libdir}/firmware/LICENCE.mali_csffw"
+FILES:${PN}-mali-csffw-arch108 = 
"${nonarch_base_libdir}/firmware/arm/mali/arch10.8/mali_csffw.bin"
+
+RDEPENDS:${PN}-mali-csffw-arch108 += "${PN}-mali-csffw-license"
+
  # For marvell
  LICENSE:${PN}-pcie8897 = "Firmware-Marvell"
  LICENSE:${PN}-pcie8997 = "Firmware-Marvell"


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200338): 
https://lists.openembedded.org/g/openembedded-core/message/200338
Mute This Topic: https://lists.openembedded.org/mt/106406257/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] mesa: build failure in CI, dependency not found

2024-06-04 Thread Quentin Schulz via lists.openembedded.org


Hi Joao,

On 6/3/24 5:39 PM, Joao Marcos Costa via lists.openembedded.org wrote:

Hello,

The following error was raised in Swat's CI:

| Run-time dependency libclc found: NO (tried pkgconfig)
|
| ../mesa-24.1.0/meson.build:852:12: ERROR: Dependency "libclc" not 
found, tried pkgconfig

|
| A full log can be found at 
/home/pokybuild/yocto-worker/qemux86-64-ptest/build/build/tmp/work/core2-64-poky-linux/mesa/24.1.0/build/meson-logs/meson-log.txt

| ERROR: meson failed
| WARNING: 
/home/pokybuild/yocto-worker/qemux86-64-ptest/build/build/tmp/work/core2-64-poky-linux/mesa/24.1.0/temp/run.do_configure.47874:171 exit 1 from 'exit 1'

| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log, 
/home/pokybuild/yocto-worker/qemux86-64-ptest/build/build/tmp/work/core2-64-poky-linux/mesa/24.1.0/temp/run.do_configure.47874, line 171
|     #2: meson_do_configure, 
/home/pokybuild/yocto-worker/qemux86-64-ptest/build/build/tmp/work/core2-64-poky-linux/mesa/24.1.0/temp/run.do_configure.47874, line 160
|     #3: do_configure, 
/home/pokybuild/yocto-worker/qemux86-64-ptest/build/build/tmp/work/core2-64-poky-linux/mesa/24.1.0/temp/run.do_configure.47874, line 149
|     #4: main, 
/home/pokybuild/yocto-worker/qemux86-64-ptest/build/build/tmp/work/core2-64-poky-linux/mesa/24.1.0/temp/run.do_configure.47874, line 184

NOTE: recipe mesa-2_24.1.0-r0: task do_configure: Failed

https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6680/steps/12/logs/stdio

Mesa was upgraded a few days ago. Could it be related to this error?



Likely yes, can you provide some info on how I can reproduce this 
locally so I don't have to hunt this?


Maybe you also have access to the full log somewhere?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200321): 
https://lists.openembedded.org/g/openembedded-core/message/200321
Mute This Topic: https://lists.openembedded.org/mt/106464279/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 v4 2/2] image-bootfiles.bbclass: new class, copy boot files to root filesystem

2024-05-31 Thread Quentin Schulz via lists.openembedded.org


Hi Marcus,

On 5/30/24 11:53 AM, Marcus Folkesson wrote:

image-bootfiles class copy files listed in IMAGE_BOOT_FILES
to the IMAGE_BOOT_FILES_DIR directory of the root filesystem.

This is useful when there is no explicit boot partition but all boot
files should instead reside inside the root filesystem.

Signed-off-by: Marcus Folkesson 


Reviewed-by: Quentin Schulz 

Thanks!
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200068): 
https://lists.openembedded.org/g/openembedded-core/message/200068
Mute This Topic: https://lists.openembedded.org/mt/106385581/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/3] mesa: upgrade 24.0.7 -> 24.1.0

2024-05-31 Thread Quentin Schulz

From: Quentin Schulz 

Changelog:
 https://docs.mesa3d.org/relnotes/24.1.0.html

0001-drisw-fix-build-without-dri3.patch was merged in
https://gitlab.freedesktop.org/mesa/mesa/-/commit/bdb59a3941c9dadfcbe1b9b6569f5c8a994e139f

0002-glxext-don-t-try-zink-if-not-enabled-in-mesa.patch was merged in
https://gitlab.freedesktop.org/mesa/mesa/-/commit/d7b877598f1838c58c6367817e83832c230f7e0b

Signed-off-by: Quentin Schulz 
---
 .../files/0001-drisw-fix-build-without-dri3.patch  | 58 --
 ...ext-don-t-try-zink-if-not-enabled-in-mesa.patch | 42 
 .../mesa/{mesa-gl_24.0.7.bb => mesa-gl_24.1.0.bb}  |  0
 meta/recipes-graphics/mesa/mesa.inc|  4 +-
 .../mesa/{mesa_24.0.7.bb => mesa_24.1.0.bb}|  0
 5 files changed, 1 insertion(+), 103 deletions(-)

diff --git 
a/meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch 
b/meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch
deleted file mode 100644
index ab16152090..00
--- a/meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From 4bd15a419e892da843489c374c58c5b29c40b5d6 Mon Sep 17 00:00:00 2001
-From: Romain Naour 
-Date: Tue, 6 Feb 2024 09:47:09 +0100
-Subject: [PATCH 1/2] drisw: fix build without dri3
-
-commit 1887368df41 ("glx/sw: check for modifier support in the kopper path")
-added dri3_priv.h header and dri3_check_multibuffer() function in drisw that
-can be build without dri3.
-
-  i686-buildroot-linux-gnu/bin/ld: src/glx/libglx.a.p/drisw_glx.c.o: in 
function `driswCreateScreenDriver':
-  drisw_glx.c:(.text.driswCreateScreenDriver+0x3a0): undefined reference to 
`dri3_check_multibuffer'
-  collect2: error: ld returned 1 exit status
-
-Add HAVE_DRI3 guard around dri3_priv.h header and the zink code using
-dri3_check_multibuffer().
-
-Fixes: 1887368df41 ("glx/sw: check for modifier support in the kopper path")
-
-Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27478]
-Signed-off-by: Romain Naour 
-Signed-off-by: Khem Raj 

- src/glx/drisw_glx.c | 4 
- 1 file changed, 4 insertions(+)
-
-diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
-index 3d3f752..4b19e2d 100644
 a/src/glx/drisw_glx.c
-+++ b/src/glx/drisw_glx.c
-@@ -32,7 +32,9 @@
- #include 
- #include "dri_common.h"
- #include "drisw_priv.h"
-+#ifdef HAVE_DRI3
- #include "dri3_priv.h"
-+#endif
- #include 
- #include 
- #include 
-@@ -995,6 +997,7 @@ driswCreateScreenDriver(int screen, struct glx_display 
*priv,
-goto handle_error;
-}
- 
-+#ifdef HAVE_DRI3
-if (pdpyp->zink) {
-   bool err;
-   psc->has_multibuffer = dri3_check_multibuffer(priv->dpy, &err);
-@@ -1005,6 +1008,7 @@ driswCreateScreenDriver(int screen, struct glx_display 
*priv,
-  goto handle_error;
-   }
-}
-+#endif
- 
-glx_config_destroy_list(psc->base.configs);
-psc->base.configs = configs;
--- 
-2.44.0
-
diff --git 
a/meta/recipes-graphics/mesa/files/0002-glxext-don-t-try-zink-if-not-enabled-in-mesa.patch
 
b/meta/recipes-graphics/mesa/files/0002-glxext-don-t-try-zink-if-not-enabled-in-mesa.patch
deleted file mode 100644
index 036a0b4945..00
--- 
a/meta/recipes-graphics/mesa/files/0002-glxext-don-t-try-zink-if-not-enabled-in-mesa.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From 62495ebb977866c52d5bed8499a547c49f0d9bc1 Mon Sep 17 00:00:00 2001
-From: Romain Naour 
-Date: Tue, 6 Feb 2024 09:47:10 +0100
-Subject: [PATCH 2/2] glxext: don't try zink if not enabled in mesa
-
-Commit 7d9ea77b459 ("glx: add automatic zink fallback loading between hw and 
sw drivers")
-added an automatic zink fallback even when the zink gallium is not
-enabled at build time.
-
-It leads to unexpected error log while loading drisw driver and
-zink is not installed on the rootfs:
-
-  MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so
-
-Fixes: 7d9ea77b459 ("glx: add automatic zink fallback loading between hw and 
sw drivers")
-
-Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27478]
-Signed-off-by: Romain Naour 
-Signed-off-by: Khem Raj 

- src/glx/glxext.c | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/src/glx/glxext.c b/src/glx/glxext.c
-index 05c825a..7a06aa9 100644
 a/src/glx/glxext.c
-+++ b/src/glx/glxext.c
-@@ -908,9 +908,11 @@ __glXInitialize(Display * dpy)
- #endif /* HAVE_DRI3 */
-   if (!debug_get_bool_option("LIBGL_DRI2_DISABLE", false))
-  dpyPriv->dri2Display = dri2CreateDisplay(dpy);
-+#if defined(HAVE_ZINK)
-   if (!dpyPriv->dri3Display && !dpyPriv->dri2Display)
-  try_zink = !debug_get_bool_option("LIBGL_KOPPER_DISABLE", false) &&
- !getenv("GALLIUM_DRIVER");
-+#endif /* HAVE_ZINK */
-}
- #endif /* GLX_USE_DRM */
-

[OE-core] [PATCH 3/3] mesa: add new package for Mali CSFFW Valhall firmware

2024-05-31 Thread Quentin Schulz

From: Quentin Schulz 

This firmware is necessary for closed-source mali blob + drivers and
open-source Panthor (via Mesa + Linux kernel) drivers.

Signed-off-by: Quentin Schulz 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
index 026e5dba00..4a87105d98 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
@@ -39,6 +39,7 @@ LICENSE = "\
 & Firmware-kaweth \
 & Firmware-linaro \
 & Firmware-Lontium \
+& Firmware-mali_csffw \
 & Firmware-Marvell \
 & Firmware-mediatek \
 & Firmware-microchip \
@@ -113,6 +114,7 @@ LIC_FILES_CHKSUM = 
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
 file://LICENCE.kaweth;md5=b1d876e562f4b3b8d391ad8395dfe03f 
\
 file://LICENCE.linaro;md5=936d91e71cf9cd30e733db4bf11661cc 
\
 
file://LICENSE.Lontium;md5=4ec8dc582ff7295f39e2ca6a7b0be2b6 \
+
file://LICENCE.mali_csffw;md5=e064aaec4d21ef856e1b76a6f5dc435f \
 
file://LICENCE.Marvell;md5=28b6ed8bd04ba105af6e4dcd6e997772 \
 
file://LICENCE.mediatek;md5=7c1976b63217d76ce47d0a11d8a79cf2 \
 
file://LICENCE.microchip;md5=db753b00305675dfbf120e3f24a47277 \
@@ -192,6 +194,7 @@ NO_GENERIC_LICENSE[Firmware-iwlwifi_firmware] = 
"LICENCE.iwlwifi_firmware"
 NO_GENERIC_LICENSE[Firmware-kaweth] = "LICENCE.kaweth"
 NO_GENERIC_LICENSE[Firmware-linaro] = "LICENCE.linaro"
 NO_GENERIC_LICENSE[Firmware-Lontium] = "LICENSE.Lontium"
+NO_GENERIC_LICENSE[Firmware-mali_csffw] = "LICENCE.mali_csffw"
 NO_GENERIC_LICENSE[Firmware-Marvell] = "LICENCE.Marvell"
 NO_GENERIC_LICENSE[Firmware-mediatek] = "LICENCE.mediatek"
 NO_GENERIC_LICENSE[Firmware-microchip] = "LICENCE.microchip"
@@ -354,6 +357,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-bnx2 \
  ${PN}-bnx2x \
  ${PN}-liquidio \
+ ${PN}-mali-csffw-arch108 ${PN}-mali-csffw-license \
  ${PN}-mellanox \
  ${PN}-nvidia-license \
  ${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \
@@ -608,6 +612,13 @@ LICENSE:${PN}-lt9611uxc = "Firmware-Lontium"
 FILES:${PN}-lontium-license = "${nonarch_base_libdir}/firmware/LICENSE.Lontium"
 FILES:${PN}-lt9611uxc = "${nonarch_base_libdir}/firmware/lt9611uxc_fw.bin"
 
+# For Arm Mali
+LICENSE:${PN}-mali-csffw-arch108 = "Firmware-mali_csffw"
+FILES:${PN}-mali-csffw-license = 
"${nonarch_base_libdir}/firmware/LICENCE.mali_csffw"
+FILES:${PN}-mali-csffw-arch108 = 
"${nonarch_base_libdir}/firmware/arm/mali/arch10.8/mali_csffw.bin"
+
+RDEPENDS:${PN}-mali-csffw-arch108 += "${PN}-mali-csffw-license"
+
 # For marvell
 LICENSE:${PN}-pcie8897 = "Firmware-Marvell"
 LICENSE:${PN}-pcie8997 = "Firmware-Marvell"

-- 
2.45.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200067): 
https://lists.openembedded.org/g/openembedded-core/message/200067
Mute This Topic: https://lists.openembedded.org/mt/106406257/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 0/3] prepare Panthor (open-source) support for Arm GPU

2024-05-31 Thread Quentin Schulz

Panthor is the open-source implementation for the Arm GPU Valhall series
both in the Linux kernel and Mesa userspace. In the latter, the panfrost
"driver" is actually handling this version of the Arm GPU. One therefore
needs to enable kmsro and panfrost in PACKAGECONFIG to be able to use
this open-source implementation.

The open-source implementation still requires a proprietary blob which
is running on the GPU: mali_csffw.bin. Note that the closed-source
implementation (libmali and vendor kernel drivers) also require this
blob.

Right now, we're still missing a linux-yocto v6.10+ to be able to test
this with everything upstream in Yocto/OE, but I was able to
successfully test this with kmscube on a downstream kernel (6.6 +
backported patches for GPU and custom patches for DSI support) on an
RK3588 Tiger.

Signed-off-by: Quentin Schulz 
---
Quentin Schulz (3):
  linux-firmware: update to 20240513
  mesa: upgrade 24.0.7 -> 24.1.0
  mesa: add new package for Mali CSFFW Valhall firmware

 .../files/0001-drisw-fix-build-without-dri3.patch  | 58 --
 ...ext-don-t-try-zink-if-not-enabled-in-mesa.patch | 42 
 .../mesa/{mesa-gl_24.0.7.bb => mesa-gl_24.1.0.bb}  |  0
 meta/recipes-graphics/mesa/mesa.inc|  4 +-
 .../mesa/{mesa_24.0.7.bb => mesa_24.1.0.bb}|  0
 ...ware_20240312.bb => linux-firmware_20240513.bb} | 33 
 6 files changed, 25 insertions(+), 112 deletions(-)
---
base-commit: 99ff46cc9bb12619af55c892452cee3b90a545f0
change-id: 20240529-panthor-600520083b6b

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200064): 
https://lists.openembedded.org/g/openembedded-core/message/200064
Mute This Topic: https://lists.openembedded.org/mt/106406254/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/3] linux-firmware: update to 20240513

2024-05-31 Thread Quentin Schulz

From: Quentin Schulz 

Update the linux-firmware recipe to the most recent upstream tag.

LICENSE.amdgpu md5 checksum changed because they bumped the Copyright
year[1].

Some of qcom-sdm845-modem files got replaced by a symlink to their
counterpart in ath10k/WCN3990/hw1.0/. The same happened to files in
qcom-qcm2290-wifi, but to ath10k/WCN3990/hw1.0/qcm2290/. Finally,
qcom-qrb4210-wifi also got its file symlinked to
ath10k/WCN3990/hw1.0/qrb4210/ which in turn is a symlink to
ath10k/WCN3990/hw1.0/qcm2290/.[2] This meant that qrb4210-wifi now
RDEPENDS on qcm2290-wifi for the target of the links to be present when
installing it, and also that sdm845-modem and qcm2290-wifi packages have
to be before the ath10k catch-all package.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=9442c72e361c1e1130a19248598ad6ab5282ba09
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=650e88378e76d5fad3997a5398f1ade47a74d924
Signed-off-by: Quentin Schulz 
---
 ...ware_20240312.bb => linux-firmware_20240513.bb} | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
similarity index 98%
rename from meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
rename to meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
index 13538afede..026e5dba00 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240513.bb
@@ -82,7 +82,7 @@ LICENSE = "\
 LIC_FILES_CHKSUM = "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc 
\
 
file://LICENCE.adsp_sst;md5=615c45b91a5a4a9fe046d6ab9a2df728 \
 file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \
-file://LICENSE.amdgpu;md5=a2589a05ea5b6bd2b7f4f623c7e7a649 
\
+file://LICENSE.amdgpu;md5=1433dfea38c97a2e563a248a863dcb94 
\
 
file://LICENSE.amd-ucode;md5=6ca90c57f7b248de1e25c7f68ffc4698 \
 
file://LICENSE.amlogic_vdec;md5=dc44f59bf64a81643e500ad3f39a468a \
 
file://LICENSE.amphion_vpu;md5=2bcdc00527b2d0542bd92b52aaec2b60 \
@@ -154,7 +154,7 @@ LIC_FILES_CHKSUM = 
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
 "
 # WHENCE checksum is defined separately to ease overriding it if
 # class-devupstream is selected.
-WHENCE_CHKSUM  = "514da1cd8b363373030f0c16749feb8d"
+WHENCE_CHKSUM  = "ae024b46fd393d199f66bbe1f3ff5254"
 
 # These are not common licenses, set NO_GENERIC_LICENSE for them
 # so that the license files will be copied from fetched source
@@ -241,7 +241,7 @@ SRC_URI:class-devupstream = 
"git://git.kernel.org/pub/scm/linux/kernel/git/firmw
 # Pin this to the 20220509 release, override this in local.conf
 SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
 
-SRC_URI[sha256sum] = 
"b2327a54ad1897c828008caf63af5ee15469ba723a5016be58f2b44f07bd4b94"
+SRC_URI[sha256sum] = 
"9f05edb99668135d37cedc4fdd18aac2802dc9e4566e086e6c6c2e321f3ecc4e"
 
 inherit allarch
 
@@ -322,6 +322,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-cnm-license ${PN}-cnm \
  ${PN}-atheros-license ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k 
${PN}-ath9k ${PN}-ath3k \
  ${PN}-carl9170 \
+ ${PN}-qcom-qrb4210-wifi ${PN}-qcom-sdm845-modem \
  ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
${PN}-ath11k ${PN}-ath12k ${PN}-qca \
  \
  ${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
@@ -384,13 +385,13 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-qcom-apq8096-adreno ${PN}-qcom-apq8096-audio 
${PN}-qcom-apq8096-modem \
  ${PN}-qcom-qcm2290-adreno ${PN}-qcom-qcm2290-audio 
${PN}-qcom-qcm2290-modem ${PN}-qcom-qcm2290-wifi  \
  ${PN}-qcom-qrb4210-adreno ${PN}-qcom-qrb4210-audio 
${PN}-qcom-qrb4210-compute \
- ${PN}-qcom-qrb4210-modem ${PN}-qcom-qrb4210-wifi  \
+ ${PN}-qcom-qrb4210-modem \
  ${PN}-qcom-sc8280xp-lenovo-x13s-compat \
  ${PN}-qcom-sc8280xp-lenovo-x13s-audio \
  ${PN}-qcom-sc8280xp-lenovo-x13s-adreno \
  ${PN}-qcom-sc8280xp-lenovo-x13s-compute \
  ${PN}-qcom-sc8280xp-lenovo-x13s-sensors \
- ${PN}-qcom-sdm845-adreno ${PN}-qcom-sdm845-audio 
${PN}-qcom-sdm845-compute ${PN}-qcom-sdm845-modem \
+ ${PN}-qcom-sdm845-adreno ${PN}-qcom-sdm845-audio 
${PN}-qcom-sdm845-compute \
  ${PN}-qcom-sdm845-thundercomm-db845c-sensors \
  ${PN}-qcom-sm8250-adreno ${PN}-qcom-sm8250-audio 
${PN}-qco

[OE-core] [PATCH] kernel-yocto: fix incorrect debug message for defconfig in WORKDIR

2024-05-28 Thread Quentin Schulz

From: Quentin Schulz 

Right before this message is printed, the in-tree defconfig is checked
against the one in WORKDIR. If it is different, and therefore either
provided through SRC_URI or patched, then the message is printed.
Therefore, the debug message is incorrect and should say that a patched
defconfig was detected and overwritten.

Fixes: 004da4c6c602 ("kernel-yocto: split meta data gathering into patch and 
config phases")
Cc: Bruce Ashfield 
Signed-off-by: Quentin Schulz 
---
 meta/classes-recipe/kernel-yocto.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel-yocto.bbclass 
b/meta/classes-recipe/kernel-yocto.bbclass
index f741a342d4..6d5c3b6327 100644
--- a/meta/classes-recipe/kernel-yocto.bbclass
+++ b/meta/classes-recipe/kernel-yocto.bbclass
@@ -158,7 +158,7 @@ do_kernel_metadata() {
# one already placed in UNPACKDIR
cmp "${UNPACKDIR}/defconfig" 
"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
if [ $? -ne 0 ]; then
-   bbdebug 1 "detected SRC_URI or 
unpatched defconfig in UNPACKDIR. ${KBUILD_DEFCONFIG} copied over it"
+   bbdebug 1 "detected SRC_URI or patched 
defconfig in UNPACKDIR. ${KBUILD_DEFCONFIG} copied over it"
fi
cp -f 
${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${UNPACKDIR}/defconfig
else

---
base-commit: 51aa0217e595939f15bd3ffd7625907aef142c05
change-id: 20240528-kernel-yocto-unpatched-bbdebug-dc378b55ea22

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199973): 
https://lists.openembedded.org/g/openembedded-core/message/199973
Mute This Topic: https://lists.openembedded.org/mt/106348998/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 2/2] image-bootfiles.bbclass: new class, copy boot files to root filesystem

2024-05-28 Thread Quentin Schulz via lists.openembedded.org

Hi Marcus,

On 5/28/24 11:08 AM, Marcus Folkesson wrote:

image-bootfiles class copy files listed in IMAGE_BOOT_FILES
to the IMAGE_BOOT_FILES_DIR directory of the root filesystem.

This is useful when there is no explicit boot partition but all boot
files should instead reside inside the root filesystem.

Signed-off-by: Marcus Folkesson 
---

Notes:
 v3:
 - Skip the intermediate bootfiles() function
 - Rename variable names to be consistent
 - Various python optimizations

  meta/classes/image-bootfiles.bbclass | 38 
  1 file changed, 38 insertions(+)
  create mode 100644 meta/classes/image-bootfiles.bbclass

diff --git a/meta/classes/image-bootfiles.bbclass 
b/meta/classes/image-bootfiles.bbclass
new file mode 100644
index 00..79c58f414a
--- /dev/null
+++ b/meta/classes/image-bootfiles.bbclass
@@ -0,0 +1,38 @@
+#
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2024 Marcus Folkesson
+# Author: Marcus Folkesson 
+#
+# Writes IMAGE_BOOT_FILES to the IMAGE_BOOT_FILES_DIR directory
+#
+#
+# Usage: add inherit += "image-bootfiles" to your image
+#

Simply

inherit image-bootfiles

c.f. 
https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#inherit-directive

since you put this class into meta/classes/ and not 
meta/classes-recipes/, it could be included both with

INHERIT += "image-bootfiles"

and

inherit image-bootfiles

The former is to be included from configuration files (e.g. a distro, 
local.conf, machine conf file, etc.). The latter inside the image recipe 
directly.

I am wondering if we shouldn't make this a recipes-only bbclass? so 
moving it to meta/classes-recipes/? This means that we won't be able to 
use the INHERIT += "image-bootfiles" anymore but should we? On one 
side, we have something that only applies to images, on the other hand, 
it's probably something close to a policy, so rather part of a distro. 
So just wondering, not asking for a change :)

Cheers,
Quentin

+
+IMAGE_BOOT_FILES_DIR ?= "boot"
+
+python bootfiles_populate() {
+import shutil
+from oe.bootfiles import get_boot_files
+
+deploy_image_dir = d.getVar("DEPLOY_DIR_IMAGE")
+boot_dir = os.path.join(d.getVar("IMAGE_ROOTFS"), 
d.getVar("IMAGE_BOOT_FILES_DIR"))
+
+boot_files = d.getVar("IMAGE_BOOT_FILES")
+if boot_files is None:
+return
+
+install_files = get_boot_files(deploy_image_dir, boot_files)
+if install_files is None:
+bb.warn("Could not find any boot files to install even though 
IMAGE_BOOT_FILES is not empty")
+return
+
+os.makedirs(boot_dir, exist_ok=True)
+for src, dst  in install_files:
+image_src = os.path.join(deploy_image_dir, src)
+image_dst = os.path.join(boot_dir, dst)
+shutil.copyfile(image_src, image_dst)

This won't work if the parent directory of image_dst doesn't exist yet.

"""
>>> import shutil
>>> shutil.copyfile('plep', 'thisisatest/alsothis/test')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.12/shutil.py", line 262, in copyfile
with open(dst, 'wb') as fdst:
 ^^^
FileNotFoundError: [Errno 2] No such file or directory: 
'thisisatest/alsothis/test'

"""

So I think we need to run:

os.makedirs(os.path.dirname(image_dst), exist_ok=True)

before calling shutil.copyfile?

In the bootimg-partition wic plugin, the following is done to install files:

install -m 0644 -D  

which creates all directories leading to . Additionally it makes it 
rw for owner, r for group and others. It seems that shutil.copyfile does 
this automatically (doesn't seem documented but it did this on a test in 
the python interpreter).

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199969): 
https://lists.openembedded.org/g/openembedded-core/message/199969
Mute This Topic: https://lists.openembedded.org/mt/106345350/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 1/2] bootimg-partition: break out code to a common library.

2024-05-28 Thread Quentin Schulz via lists.openembedded.org


Hi Marcus,

On 5/28/24 11:08 AM, Marcus Folkesson wrote:

Break out the code that parse IMAGE_BOOT_FILES to a common library.

Signed-off-by: Marcus Folkesson 
Reviewed-by: Quentin Schulz 
---

Notes:
 v3:
- Removed unnecessary "import glob"


Ah, there was a misunderstanding here, the "wrong" import glob got 
removed :)



- Explicitely tell that bootfiles_populate() returns a tuple

  meta/lib/oe/bootfiles.py  | 56 +++
  .../wic/plugins/source/bootimg-partition.py   | 39 +
  2 files changed, 59 insertions(+), 36 deletions(-)
  create mode 100644 meta/lib/oe/bootfiles.py

diff --git a/meta/lib/oe/bootfiles.py b/meta/lib/oe/bootfiles.py
new file mode 100644
index 00..666141df4e
--- /dev/null
+++ b/meta/lib/oe/bootfiles.py
@@ -0,0 +1,56 @@
+#
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2024 Marcus Folkesson
+# Author: Marcus Folkesson 
+#
+# Utility functions handling boot files
+#
+# Look into deploy_dir and search for boot_files.
+# Returns a list of tuples with (original filepath relative to
+# deploy_dir, desired filepath renaming)
+#
+# Heavily inspired of bootimg-partition.py
+#
+def get_boot_files(deploy_dir, boot_files):
+import re
+import os
+


We need from glob import glob here


+if boot_files is None:
+return None
+
+# list of tuples (src_name, dst_name)
+deploy_files = []
+for src_entry in re.findall(r'[\w;\-\./\*]+', boot_files):
+if ';' in src_entry:
+dst_entry = tuple(src_entry.split(';'))
+if not dst_entry[0] or not dst_entry[1]:
+raise ValueError('Malformed boot file entry: %s' % src_entry)
+else:
+dst_entry = (src_entry, src_entry)
+
+deploy_files.append(dst_entry)
+
+install_files = []
+for deploy_entry in deploy_files:
+src, dst = deploy_entry
+if '*' in src:
+# by default install files under their basename
+entry_name_fn = os.path.basename
+if dst != src:
+# unless a target name was given, then treat name
+# as a directory and append a basename
+entry_name_fn = lambda name: \
+os.path.join(dst,
+ os.path.basename(name))
+
+srcs = glob(os.path.join(deploy_dir, src))
+


 otherwise this won't work (it'll I believe but only if the python 
module that calls it imports glob itself).



+for entry in srcs:
+src = os.path.relpath(entry, deploy_dir)
+entry_dst_name = entry_name_fn(entry)
+install_files.append((src, entry_dst_name))
+else:
+install_files.append((src, dst))
+
+return install_files
diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py 
b/scripts/lib/wic/plugins/source/bootimg-partition.py
index 1071d1af3f..b22a448b65 100644
--- a/scripts/lib/wic/plugins/source/bootimg-partition.py
+++ b/scripts/lib/wic/plugins/source/bootimg-partition.py
@@ -18,6 +18,8 @@ import re
  
  from glob import glob
  


It's this glob we don't need anymore, because it would then be imported 
by the python lib added in this very patch.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199968): 
https://lists.openembedded.org/g/openembedded-core/message/199968
Mute This Topic: https://lists.openembedded.org/mt/106345349/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] meta: uboot-config: Fix broken menuconfig for "fitImage" kernel

2024-05-28 Thread Quentin Schulz via lists.openembedded.org


Hi Mike,

On 5/28/24 7:20 AM, mike.looijm...@topic.nl wrote:
[You don't often get email from mike.looijm...@topic.nl. Learn why this 
is important at https://aka.ms/LearnAboutSenderIdentification ]


On 24-05-2024 12:22, Richard Purdie wrote:

On Thu, 2024-05-23 at 15:43 +0200, Quentin Schulz wrote:

I was about to comment on the v2 that this should rather be a class :)
Do we have some information on how/why this is the direction the project
should move towards? What are the pitfalls we're trying to avoid, or
benefits we want to gain? Or is this just some better/best practice we
want to go for?

There was a post from me a while back complaining about repeatedly
splitting class files into smaller less manageable ones so that people
could access some variables without the task/function side effects.

I have a belief that more configuration files would help this kind of
problem and make classes more specific/focused and usable.


Okay, so what is now the way forward? v1 or v2?



Go for what Richard asked, he's the maintainer after all :) I was merely 
trying to understand the position of the project, not suggesting we do 
something else.


I think you've already sent a v2, so just wait for reviews or for it to 
be merged. If it isn't merged in the next few weeks, then send a 
reminder as an answer to your v2 asking for feedback.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199966): 
https://lists.openembedded.org/g/openembedded-core/message/199966
Mute This Topic: https://lists.openembedded.org/mt/106223409/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 2/2] image-bootfiles.bbclass: new class, copy boot files to root filesystem

2024-05-27 Thread Quentin Schulz via lists.openembedded.org


Hi Marcus,

On 5/25/24 10:50 AM, Marcus Folkesson wrote:

image-bootfiles class copy files listed in IMAGE_BOOT_FILES
to the IMAGE_BOOTFILES_DIR directory of the root filesystem.

This is useful when there is no explicit boot partition but all boot
files should instead reside inside the root filesystem.

Signed-off-by: Marcus Folkesson 
---
  meta/classes/image-bootfiles.bbclass | 38 
  1 file changed, 38 insertions(+)
  create mode 100644 meta/classes/image-bootfiles.bbclass

diff --git a/meta/classes/image-bootfiles.bbclass 
b/meta/classes/image-bootfiles.bbclass
new file mode 100644
index 00..29a38ac631
--- /dev/null
+++ b/meta/classes/image-bootfiles.bbclass
@@ -0,0 +1,38 @@
+#
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2024 Marcus Folkesson
+# Author: Marcus Folkesson 
+#
+# Writes IMAGE_BOOT_FILES to the IMAGE_BOOTFILES_DIR directory
+#
+#
+# Usage: add INHERIT += "image-bootfiles" to your image
+#


One is supposed to use inherit image-bootfiles inside recipes. INHERIT 
is for global inherit, from configuration files, e.g. INHERIT += "rm_work".



+
+IMAGE_BOOTFILES_DIR ?= "/boot"
+


I would really suggest to have the exact same prefix as for the 
IMAGE_BOOT_FILES variable since they are related. I would like to avoid 
the DEPLOYDIR, DEPLOY_DIR confusion for example :)



+def bootfiles_populate(d):
+import shutil
+from oe.bootfiles import get_boot_files
+
+boot_files = d.getVar("IMAGE_BOOT_FILES")
+deploy_image_dir = d.getVar("DEPLOY_DIR_IMAGE")
+boot_dir = d.getVar("IMAGE_ROOTFS") + d.getVar("IMAGE_BOOTFILES_DIR")
+


I would suggest to use
os.path.join(d.getVar("IMAGE_ROOTFS"), d.getVar("IMAGE_BOOTFILES_DIR"))
here to make it a tiny bit more robust to missing/redundant slashes (/) 
for example.



+install_files = get_boot_files(deploy_image_dir, boot_files)
+if install_files is None:
+return
+


I'm wondering if we shouldn't print a warning or at the very least a 
note if boot_files is not empty but install_files is, this seems like 
there could be an issue no?



+os.makedirs(boot_dir, exist_ok=True)
+for entry in install_files:
+src, dst = entry


Those two lines could be merged into:

for src, dst in install_files:

I believe.


+image_src = os.path.join(deploy_image_dir, src)
+image_dst = os.path.join(boot_dir, dst)
+shutil.copyfile(image_src, image_dst)
+
+python bootfiles () {
+   bootfiles_populate(d),


I'm surprised by the comma at the end of the line, is this required 
somehow? What does this do?


I'm also not entirely sure we need to have this additional indirection? Is
"""
python bootfiles_populate() {

}
IMAGE_PREPROCESS_COMMAND += "bootfiles_populate;"
"""

not working somehow (I don't know if it should, so just asking)? 
tinyinitrd in meta/recipes-core/images/core-image-tiny-initramfs.bb 
seems to be doing it, so should/could be possible?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199905): 
https://lists.openembedded.org/g/openembedded-core/message/199905
Mute This Topic: https://lists.openembedded.org/mt/106295832/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 1/2] bootimg-partition: break out code to a common library.

2024-05-27 Thread Quentin Schulz via lists.openembedded.org


Hi Marcus,

On 5/25/24 10:50 AM, Marcus Folkesson wrote:

Break out the code that parse IMAGE_BOOT_FILES to a common library.

Signed-off-by: Marcus Folkesson 
---
  meta/lib/oe/bootfiles.py  | 56 +++
  .../wic/plugins/source/bootimg-partition.py   | 39 +
  2 files changed, 59 insertions(+), 36 deletions(-)
  create mode 100644 meta/lib/oe/bootfiles.py

diff --git a/meta/lib/oe/bootfiles.py b/meta/lib/oe/bootfiles.py
new file mode 100644
index 00..81e09f138e
--- /dev/null
+++ b/meta/lib/oe/bootfiles.py
@@ -0,0 +1,56 @@
+#
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2024 Marcus Folkesson
+# Author: Marcus Folkesson 
+#
+# Utility functions handling boot files
+
+# Look into deploy_dir and search for boot_files.
+# Returns a list with files to copy.
+#


It returns a list of tuples with (original filepath relative to 
deploy_dir, desired filepath renaming) if I read the code properly, I 
think this is really important information.



+# Heavily inspired of bootimg-partition.py
+#
+def get_boot_files(deploy_dir, boot_files):
+import re
+import os
+from glob import glob
+
+if boot_files is None:
+return None
+
+# list of tuples (src_name, dst_name)
+deploy_files = []
+for src_entry in re.findall(r'[\w;\-\./\*]+', boot_files):
+if ';' in src_entry:
+dst_entry = tuple(src_entry.split(';'))
+if not dst_entry[0] or not dst_entry[1]:
+raise ValueError('Malformed boot file entry: %s' % src_entry)
+else:
+dst_entry = (src_entry, src_entry)
+
+deploy_files.append(dst_entry)
+
+install_files = []
+for deploy_entry in deploy_files:
+src, dst = deploy_entry
+if '*' in src:
+# by default install files under their basename
+entry_name_fn = os.path.basename
+if dst != src:
+# unless a target name was given, then treat name
+# as a directory and append a basename
+entry_name_fn = lambda name: \
+os.path.join(dst,
+ os.path.basename(name))
+
+srcs = glob(os.path.join(deploy_dir, src))
+
+for entry in srcs:
+src = os.path.relpath(entry, deploy_dir)
+entry_dst_name = entry_name_fn(entry)
+install_files.append((src, entry_dst_name))
+else:
+install_files.append((src, dst))
+
+return install_files
diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py 
b/scripts/lib/wic/plugins/source/bootimg-partition.py
index 1071d1af3f..b22a448b65 100644
--- a/scripts/lib/wic/plugins/source/bootimg-partition.py
+++ b/scripts/lib/wic/plugins/source/bootimg-partition.py
@@ -18,6 +18,8 @@ import re
  
  from glob import glob
  


You should be able to remove this import as it was only used in the code 
that is now moved to the lib.


Otherwise looks good to me, so

Reviewed-by: Quentin Schulz 

Thanks,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199904): 
https://lists.openembedded.org/g/openembedded-core/message/199904
Mute This Topic: https://lists.openembedded.org/mt/106295831/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] scarthgap backports

2024-05-24 Thread Quentin Schulz via lists.openembedded.org

Hi Peter,

On 5/23/24 11:33 PM, Marko, Peter wrote:

-Original Message-
From: Steve Sakoman 
Sent: Thursday, May 23, 2024 15:59
To: quentin.sch...@cherry.de
Cc: Marko, Peter (ADV D EU SK BFS1) ; 
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] scarthgap backports

On Thu, May 23, 2024 at 6:46 AM Quentin Schulz via lists.openembedded.org 
 wrote:

Hi Peter,

On 5/22/24 11:10 PM, Peter Marko via lists.openembedded.org wrote:

Hello,

I'd like to request following backports from master to scarthgap

To match versions in scarthgap branches between oe-core and meta-clang:
adc2651a8e902af24fee6ff30a72f4b7c63bef6f llvm: Upgrade to 18.1.4
02df2fc6241ac8fb0e78f2fdff97a04e5c561d54 llvm: Upgrade to 18.1.5

Fix CVEs:
bdf7b7460a4816e3d447264730a2814209667fb0 ncurses: Fix CVE-2023-50495
6573995adf4cfd48b036f8463b39f3864fcfd85b ncurses: Fix CVE-2023-45918

Version correction:
c94e46019a7d443ccc4763ba16d87e7e97abe977 update-rc.d: add +git to PV

I think the most efficient way may be to send patches with [scarthgap]
in the mail subject (see --prefix) to the ML :)

Yes, please! I use patchworks to keep track of things, so patches sent to the 
list are much less likely to get lost than an email request.

It also gives the community an opportunity to comment.

Thanks!

Steve

OK, I'll do that during weekend, although it feels like sending patches on 
behalf of someone else.

Which is what every maintainer is doing :) The backports are still going 
through the mailing list, even if it's done by the maintainer(s), nobody 
has a work-around this, all public :)

What's going to happen is that you'll be the sender of the mail, but the 
commit will have the authorship of the original author (git send-email 
does that automagically already, it'll add a From: at the top of the 
mail). You usually need to add your Signed-off-by to the commit as well 
and provide information of the commit hash from master you backported, 
but not sure we enforce this in Yocto/OE/Bitbake somehow.

Looking forward to your patches, thanks!

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199834): 
https://lists.openembedded.org/g/openembedded-core/message/199834
Mute This Topic: https://lists.openembedded.org/mt/106251437/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/2] image-bootfiles.bbclass: new class, copy boot files to /boot on rfs

2024-05-23 Thread Quentin Schulz via lists.openembedded.org


Hi Marcus,

(First, sorry for the typo I made in your name)

On 5/23/24 3:49 PM, Marcus Folkesson wrote:

Hello Quentin,

First, thank you for your feedback.

On Thu, May 23, 2024 at 03:26:36PM +0200, Quentin Schulz wrote:

Hi Markus,

On 5/21/24 7:33 PM, Marcus Folkesson via lists.openembedded.org wrote:

[You don't often get email from 
marcus.folkesson=gmail@lists.openembedded.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

image-bootfiles class copy files listed IMAGE_BOOT_FILES
to the /boot directory of the root filesystem.

This is useful when there is no explicit boot partition but all boot
files should instead reside inside the root filesystem.

Signed-off-by: Marcus Folkesson 
---
   meta/classes/image-bootfiles.bbclass | 69 
   1 file changed, 69 insertions(+)
   create mode 100644 meta/classes/image-bootfiles.bbclass

diff --git a/meta/classes/image-bootfiles.bbclass 
b/meta/classes/image-bootfiles.bbclass
new file mode 100644
index 00..850e14e4bb
--- /dev/null
+++ b/meta/classes/image-bootfiles.bbclass
@@ -0,0 +1,69 @@
+#
+# Writes IMAGE_BOOT_FILES to the /boot directory
+#
+# Copyright (C) 2024 Marcus Folkesson
+# Author: Marcus Folkesson 
+#
+# Licensed under the MIT license, see COPYING.MIT for details
+# Inspired of bootimg-partition.py
+#
+# Usage: add INHERIT += "image-bootfiles" to your conf file
+#


Since it's in meta/classes, I assume we can also inherit image-bootfiles in
an image recipe?


Yes, that is how I do it right now.



Would be nice to add this to the comment as well then, so people know 
their options?


[...]




+if ';' in src_entry:
+dst_entry = tuple(src_entry.split(';'))
+if not dst_entry[0] or not dst_entry[1]:
+raise bb.parse.SkipRecipe('Malformed boot file entry: %s' % 
src_entry)
+else:
+dst_entry = (src_entry, src_entry)
+
+deploy_files.append(dst_entry)
+
+for deploy_entry in deploy_files:
+src, dst = deploy_entry
+if '*' in src:
+# by default install files under their basename
+entry_name_fn = os.path.basename
+if dst != src:
+# unless a target name was given, then treat name
+# as a directory and append a basename
+entry_name_fn = lambda name: \
+os.path.join(dst,
+ os.path.basename(name))
+
+
+srcs = glob(os.path.join(deploy_image_dir, src))
+for entry in srcs:
+src = os.path.relpath(entry, deploy_mage_dir)
+entry_dst_name = entry_name_fn(entry)
+install_files.append((src, entry_dst_name))
+else:
+install_files.append((src, dst))
+
+for entry in install_files:
+src, dst = entry
+image_src = os.path.join(deploy_image_dir, src)
+image_dst = os.path.join(boot_dir, dst)
+shutil.copyfile(image_src, image_dst)
+


We literally iterate three times over the same files, I don't see a reason
for not merging those three for loops into one?


Yes, that is probably better.



The code already exists, it's probably robust thanks to the test of 
time, so maybe not worth refactoring until someone complains about it. I 
assume we shouldn't have hundreds/thousands of entries in that variable 
so the cost is probably fine.




Also, I now realize that this was heavily inspired from what's in
scripts/lib/wic/plugins/source/bootimg-partition.py, would have been nice to
say so ;)


Yes it is, I have this text in the header

+#
+# Licensed under the MIT license, see COPYING.MIT for details
+# Inspired of bootimg-partition.py

Maybe I should make it more clear?



No, I should rather learn to not skip whatever looks like a license to 
me at the top of the file :) Sorry for the misplaced complaint.





+python bootfiles () {
+   bootfiles_populate(d),


Not entirely convinced we should have a comma after bootfiles_populate here?

More general question:
1) how does this work if one has a boot partition created by wic (via the
plugin bootimg-partition?


The images will be copied to both the partition and /boot.


2) shouldn't we factor out this code here and bootimg-partition's? or make
bootimg-partition somehow call bootfiles IMAGE_PREPROCESS_COMMAND to avoid
code duplication?


I would love that. Not sure where to but it though, I'm still learning
the structure of poky.



This probably should be another python lib or something like that, maybe 
in meta/lib/ ? It's a bit trickier since the wic plugins are not really 
any part of a recipe, rather pure python stuff, so a bit different than 
the usual way of plugging stuff in it the proepr way?



I'm preparing a v2 with an indentation error and tha

Re: [docs] [OE-core] [PATCH 1/2] image-bootfiles.bbclass: new class, copy boot files to /boot on rfs

2024-05-23 Thread Quentin Schulz via lists.openembedded.org


Hi Alex,

On 5/23/24 3:38 PM, Alexander Kanavin wrote:

I also have to repeat what I said in docs@ list: why do we need a
special mechanism for placing files into /boot? If /boot is not a
special partition, then it's just a folder in / and can be populated
from packages like any other folder.



There's renaming logic here. Which provides much more flexibility than a 
package would. You could have a different name for each image recipe for 
example, instead of having to use a distro, packageconfig, bbappend to 
modify it. Is it a valid use-case we want to support /me shrugs, be we 
already do support it in wic, so maybe that ship has sailed already.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199800): 
https://lists.openembedded.org/g/openembedded-core/message/199800
Mute This Topic: https://lists.openembedded.org/mt/106262364/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] scarthgap backports

2024-05-23 Thread Quentin Schulz via lists.openembedded.org


Hi Peter,

On 5/22/24 11:10 PM, Peter Marko via lists.openembedded.org wrote:

Hello,

I'd like to request following backports from master to scarthgap

To match versions in scarthgap branches between oe-core and meta-clang:
adc2651a8e902af24fee6ff30a72f4b7c63bef6f llvm: Upgrade to 18.1.4
02df2fc6241ac8fb0e78f2fdff97a04e5c561d54 llvm: Upgrade to 18.1.5

Fix CVEs:
bdf7b7460a4816e3d447264730a2814209667fb0 ncurses: Fix CVE-2023-50495
6573995adf4cfd48b036f8463b39f3864fcfd85b ncurses: Fix CVE-2023-45918

Version correction:
c94e46019a7d443ccc4763ba16d87e7e97abe977 update-rc.d: add +git to PV



I think the most efficient way may be to send patches with [scarthgap] 
in the mail subject (see --prefix) to the ML :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199799): 
https://lists.openembedded.org/g/openembedded-core/message/199799
Mute This Topic: https://lists.openembedded.org/mt/106251437/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] meta: uboot-config: Fix broken menuconfig for "fitImage" kernel

2024-05-23 Thread Quentin Schulz via lists.openembedded.org


Hi Mike,

On 5/22/24 8:43 AM, Mike Looijmans via lists.openembedded.org wrote:

On 22-05-2024 07:39, Richard Purdie wrote:

On Wed, 2024-05-22 at 07:28 +0200, mike.looijm...@topic.nl wrote:

On 21-05-2024 16:51, Richard Purdie wrote:

On Tue, 2024-05-21 at 15:57 +0200, Mike Looijmans via
lists.openembedded.org wrote:

kernel-fitimage inherited uboot-config, which resulted in failure
to
run "menuconfig" on a system that has both multiple u-boot
configs and
wants a fitImage kernel.

Fix the issue by splitting up uboot-config into uboot-config-vars
that
only contains the "harmless" variable settings, and inherit that
in a
new uboot-config class which contains the Python code to do the
U-boot
specific settings. Inherit only uboot-config-vars in kernel-
fitimage
so that it has what it needs but doesn't break.

Fixes: f9e834e31788 "meta: introduce
KCONFIG_CONFIG_ENABLE_MENUCONFIG"
Signed-off-by: Mike Looijmans 
---
   meta/classes-recipe/kernel-fitimage.bbclass   |  2 +-
   meta/classes-recipe/uboot-config-vars.bbclass | 95
+++
   meta/classes-recipe/uboot-config.bbclass  | 80 +---

   3 files changed, 97 insertions(+), 80 deletions(-)
   create mode 100644 meta/classes-recipe/uboot-config-
vars.bbclass


This looks like it might be a good candidate to move to a file in
meta/conf rather than a new class file?


What does "this" refer to exactly?


The variable definitions you're placing into a separate class file. I'm
saying they look more suited to a shared conf file, which is a
direction I think the project needs to move in generally.


a "uboot.conf" then, okay.



I was about to comment on the v2 that this should rather be a class :) 
Do we have some information on how/why this is the direction the project 
should move towards? What are the pitfalls we're trying to avoid, or 
benefits we want to gain? Or is this just some better/best practice we 
want to go for?


On a slightly different topic, I've been bothered by KERNEL_DEVICETREE 
being defined both in machine conf files and kernel recipes (in my own 
BSP layer, I'm not saying I'm doing things right :) ). I did this 
because I wanted to make a switch between kernel recipes as easy as 
possible while having some kind of common DTB in the machine conf file 
(e.g. upstream doesn't have all our Device Trees/Device Tree Overlays 
yet, sometimes the names slightly change between recipes...). If 
everything was in machine conf file, 
PREFERRED_PROVIDER_virtual/kernel/PREFERRED_VERSION_virtual/kernel would 
be only a part of the switch). Also, I use KERNEL_DEVICETREE in the 
machine conf file because I need to extract the default device tree to 
do some logic on it (namely, modify U-Boot at build time so those half 
broken ancient vendor U-Boot could boot my image). Not sure this is 
relevant, but had it in my mind so just putting it out there.





Note that this patch just moves code, it doesn't introduce anything
new.


We could add any functions needed to lib/oe/ if they can be made
suitably generic.


What "functions" would that be?


removesuffix is the one I saw that was needed in the new class file and
wouldn't work in a conf file.


Interestingly, "removesuffix" is a built-in Python function since 3.8:

 >>> 'hello.all'.removesuffix('.all')
'hello'

And 3.8 is the minimum required version for Yocto anyway.



If we need to backport this to earlier releases, 3.8 might not be the 
minimum supported version of Python anymore, making this harder to backport.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199798): 
https://lists.openembedded.org/g/openembedded-core/message/199798
Mute This Topic: https://lists.openembedded.org/mt/106223409/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] ref-manual: classes: add new image-bootfiles class

2024-05-23 Thread Quentin Schulz via lists.openembedded.org


Hi Markus,

On 5/21/24 7:33 PM, Marcus Folkesson via lists.openembedded.org wrote:

[You don't often get email from 
marcus.folkesson=gmail@lists.openembedded.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

Describe the newly introduced image-bootfiles class.

Signed-off-by: Marcus Folkesson 
---
  documentation/ref-manual/classes.rst | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/documentation/ref-manual/classes.rst 
b/documentation/ref-manual/classes.rst
index 9520d0bf7c..53b3697bee 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -1169,6 +1169,20 @@ Yocto Project Overview and Concepts Manual.

  .. _ref-classes-image-buildinfo:



This isn't the appropriate name for the reflink, we should ave

.. _ref-classes-image-bootfiles:

instead, to match the actual name of the class.


+``image-bootfiles``
+===
+
+The :ref:`ref-classes-image-buildinfo` class copies over files listed


That's not the appropriate name, it should be 
ref-classes-image-bootfiles (it currently renders properly because the 
reflink is incorrect).



+in :ref:`IMAGE_BOOT_FILES` to the /boot directory of the root filesystem.
+


Tick quote /boot:
`/boot`
it;'s not meant to be understood as an English word.


+This can be useful if no separate boot partition is used but all boot files


Replace "all" with "some", it depends on the content of 
IMAGE_BOOT_FILES, so we cannot say "all" here, it is misleading.



+should be included into the rootfs image.
+
+:ref:`IMAGE_BOOT_FILES` is the same space-separated list of files used
+by the ``bootimg-partition`` source plugin to populate the boot partition.
+


I would not mention this here, rather edit the variables glossary entry 
for IMAGE_BOOT_FILES to mention that this is also used by image-bootfiles.

Also, it seems bootimg-efi plugin uses it, according to the glossary entry.


+.. _ref-classes-image_types:


This isn't the appropriate name for the reflink, we should have

.. _ref-classes-image-buildinfo:

instead.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199794): 
https://lists.openembedded.org/g/openembedded-core/message/199794
Mute This Topic: https://lists.openembedded.org/mt/106227726/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/2] image-bootfiles.bbclass: new class, copy boot files to /boot on rfs

2024-05-23 Thread Quentin Schulz via lists.openembedded.org

Hi Markus,

On 5/21/24 7:33 PM, Marcus Folkesson via lists.openembedded.org wrote:

[You don't often get email from 
marcus.folkesson=gmail@lists.openembedded.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

image-bootfiles class copy files listed IMAGE_BOOT_FILES
to the /boot directory of the root filesystem.

This is useful when there is no explicit boot partition but all boot
files should instead reside inside the root filesystem.

Signed-off-by: Marcus Folkesson 
---
  meta/classes/image-bootfiles.bbclass | 69 
  1 file changed, 69 insertions(+)
  create mode 100644 meta/classes/image-bootfiles.bbclass

diff --git a/meta/classes/image-bootfiles.bbclass 
b/meta/classes/image-bootfiles.bbclass
new file mode 100644
index 00..850e14e4bb
--- /dev/null
+++ b/meta/classes/image-bootfiles.bbclass
@@ -0,0 +1,69 @@
+#
+# Writes IMAGE_BOOT_FILES to the /boot directory
+#
+# Copyright (C) 2024 Marcus Folkesson
+# Author: Marcus Folkesson 
+#
+# Licensed under the MIT license, see COPYING.MIT for details
+# Inspired of bootimg-partition.py
+#
+# Usage: add INHERIT += "image-bootfiles" to your conf file
+#

Since it's in meta/classes, I assume we can also inherit image-bootfiles 
in an image recipe?

+
+def bootfiles_populate(d):
+import re
+from glob import glob
+import shutil
+
+boot_files = d.getVar("IMAGE_BOOT_FILES")
+deploy_image_dir = d.getVar("DEPLOY_DIR_IMAGE")
+boot_dir = d.getVar("IMAGE_ROOTFS") + "/boot"
+install_files = []
+
+if boot_files is None:
+return
+
+# list of tuples (src_name, dst_name)
+deploy_files = []
+for src_entry in re.findall(r'[\w;\-\./\*]+', boot_files):

Isn't this a more complex boot_files.split()? What do we gain from using 
this regex? If we have malformed IMAGE_BOOT_FILES, this would actually 
introduce some logic error:

>>> s="plop\\plip;plep plop;plap"
>>> re.findall(r'[\w;\-\./\*]+', s)
['plop', 'plip;plep', 'plop;plap']

I'm pretty sure we don't want that. Instead, I would suggest to use 
split() and iterate over that, split(';'), check for each if there's 1 
or 2 entries, add one if it's one.

+if ';' in src_entry:
+dst_entry = tuple(src_entry.split(';'))
+if not dst_entry[0] or not dst_entry[1]:
+raise bb.parse.SkipRecipe('Malformed boot file entry: %s' % 
src_entry)
+else:
+dst_entry = (src_entry, src_entry)
+
+deploy_files.append(dst_entry)
+
+for deploy_entry in deploy_files:
+src, dst = deploy_entry
+if '*' in src:
+# by default install files under their basename
+entry_name_fn = os.path.basename
+if dst != src:
+# unless a target name was given, then treat name
+# as a directory and append a basename
+entry_name_fn = lambda name: \
+os.path.join(dst,
+ os.path.basename(name))
+
+
+srcs = glob(os.path.join(deploy_image_dir, src))
+for entry in srcs:
+src = os.path.relpath(entry, deploy_mage_dir)
+entry_dst_name = entry_name_fn(entry)
+install_files.append((src, entry_dst_name))
+else:
+install_files.append((src, dst))
+
+for entry in install_files:
+src, dst = entry
+image_src = os.path.join(deploy_image_dir, src)
+image_dst = os.path.join(boot_dir, dst)
+shutil.copyfile(image_src, image_dst)
+

We literally iterate three times over the same files, I don't see a 
reason for not merging those three for loops into one?

Also, I now realize that this was heavily inspired from what's in 
scripts/lib/wic/plugins/source/bootimg-partition.py, would have been 
nice to say so ;)

+python bootfiles () {
+   bootfiles_populate(d),

Not entirely convinced we should have a comma after bootfiles_populate here?

More general question:
1) how does this work if one has a boot partition created by wic (via 
the plugin bootimg-partition?
2) shouldn't we factor out this code here and bootimg-partition's? or 
make bootimg-partition somehow call bootfiles IMAGE_PREPROCESS_COMMAND 
to avoid code duplication?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199793): 
https://lists.openembedded.org/g/openembedded-core/message/199793
Mute This Topic: https://lists.openembedded.org/mt/106227725/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] mmc-utils: fix URL

2024-05-22 Thread Quentin Schulz

From: Quentin Schulz 

The current mmc-utils git URL still (for now?) redirects to the URL in
this patch, but the homepage doesn't, so let's just migrate both to the
new URL.

Signed-off-by: Quentin Schulz 
---
 meta/recipes-devtools/mmc/mmc-utils_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/mmc/mmc-utils_git.bb 
b/meta/recipes-devtools/mmc/mmc-utils_git.bb
index 7c6be93a9c..0bfd5c1cc8 100644
--- a/meta/recipes-devtools/mmc/mmc-utils_git.bb
+++ b/meta/recipes-devtools/mmc/mmc-utils_git.bb
@@ -1,5 +1,5 @@
 SUMMARY = "Userspace tools for MMC/SD devices"
-HOMEPAGE = "http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/";
+HOMEPAGE = "https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git/";
 DESCRIPTION = "${SUMMARY}"
 LICENSE = "GPL-2.0-only"
 LIC_FILES_CHKSUM = 
"file://mmc.c;beginline=1;endline=20;md5=fae32792e20f4d27ade1c5a762d16b7d"
@@ -9,7 +9,7 @@ SRCREV = "f757f413dea4a143ad7c3b48b8264176f0499a82"
 
 PV = "0.1+git"
 
-SRC_URI = 
"git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git;branch=${SRCBRANCH};protocol=https"
+SRC_URI = 
"git://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git;branch=${SRCBRANCH};protocol=https"
 UPSTREAM_CHECK_COMMITS = "1"
 
 S = "${WORKDIR}/git"

---
base-commit: 094273bd7d1768e14fbdcd2f239bee14c630a625
change-id: 20240522-mmc-utils-new-repo-4a4916557266

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199747): 
https://lists.openembedded.org/g/openembedded-core/message/199747
Mute This Topic: https://lists.openembedded.org/mt/106240866/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/3] linux-yocto: Avoid QA check

2024-05-21 Thread Quentin Schulz via lists.openembedded.org


Hi Richard,

On 5/21/24 12:36 PM, Richard Purdie via lists.openembedded.org wrote:

The kernel has special handling of ${S} and it is therefore expected to be empty
at do_unpack time. For now, ignore this QA check until the kernel unpack process
can be more standardised.

Signed-off-by: Richard Purdie 
---
  meta/classes-recipe/kernel-yocto.bbclass | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/classes-recipe/kernel-yocto.bbclass 
b/meta/classes-recipe/kernel-yocto.bbclass
index e8ff7311c32..f741a342d40 100644
--- a/meta/classes-recipe/kernel-yocto.bbclass
+++ b/meta/classes-recipe/kernel-yocto.bbclass
@@ -440,6 +440,11 @@ do_kernel_metadata[depends] = 
"kern-tools-native:do_populate_sysroot"
  do_kernel_metadata[file-checksums] = " ${@get_dirs_with_fragments(d)}"
  do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot"
  
+# ${S} doesn't exist for us at unpack

+do_qa_unpack() {
+return
+}
+


Shouldn't this rather be for all kernels?

meta/classes-recipe/kernelsrc.bbclass

sets S to STAGING_KERNEL_DIR which is in work-shared.

Won't we have an issue for other kernel recipes outside of kernel-yocto 
that we should fix?


For example, my kernel recipes do not inherit kernel-yocto, so I 
wouldn't benefit from this fix.


Basically, I'm suggesting we add do_qa_unpack() { return } to 
kernelsrc.bbclass instead.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199617): 
https://lists.openembedded.org/g/openembedded-core/message/199617
Mute This Topic: https://lists.openembedded.org/mt/106220744/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] uboot-sign: fix loop in do_uboot_assemble_fitimage

2024-05-03 Thread Quentin Schulz via lists.openembedded.org


Hi Ralph,

On 5/3/24 5:18 PM, Ralph Siemsen via lists.openembedded.org wrote:

[You don't often get email from 
ralph.siemsen=linaro@lists.openembedded.org. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

When using multiple u-boot configurations in UBOOT_CONFIG, the helper
function uboot_assemble_fitimage_helper() was not called with all
combinations of type & binary, due to a copy-n-paste indexing error.

Signed-off-by: Ralph Siemsen 


Reviewed-by: Quentin Schulz 

This likely fulfills the conditions for backporting to older branches, 
so adding Steve in Cc.


Thanks!
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199006): 
https://lists.openembedded.org/g/openembedded-core/message/199006
Mute This Topic: https://lists.openembedded.org/mt/105890177/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] ipk: Do not hardcode payload compression algorithm

2024-05-03 Thread Quentin Schulz via lists.openembedded.org


Hi Philip,

On 5/2/24 8:00 PM, Philip Lorenz wrote:

Hi Quentin,

On 02.05.24 19:19, Quentin Schulz wrote:
Sent from outside the BMW organization  - be CAUTIOUS, particularly 
with links and attachments.
Absender außerhalb der BMW Organisation - Bitte VORSICHT beim Öffnen 
von Links und Anhängen.

---

Hi Philip,

On 5/2/24 4:27 PM, Philip Lorenz via lists.openembedded.org wrote:
[You don't often get email from 
philip.lorenz=bmw...@lists.openembedded.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]


The chosen payload compression algorithm can be changed by overriding
`OPKGBUILDCMD`. Ensure that package extraction deals with this by
globbing for "data.tar.*" to select the actual payload tarball.

Signed-off-by: Philip Lorenz 
---
  meta/lib/oe/package_manager/ipk/__init__.py | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager/ipk/__init__.py 
b/meta/lib/oe/package_manager/ipk/__init__.py

index 8cc9953a027..0f0038d00d9 100644
--- a/meta/lib/oe/package_manager/ipk/__init__.py
+++ b/meta/lib/oe/package_manager/ipk/__init__.py
@@ -4,6 +4,7 @@
  # SPDX-License-Identifier: GPL-2.0-only
  #

+import glob
  import re
  import shutil
  import subprocess
@@ -134,11 +135,16 @@ class OpkgDpkgPM(PackageManager):
  tmp_dir = tempfile.mkdtemp()
  current_dir = os.getcwd()
  os.chdir(tmp_dir)
-    data_tar = 'data.tar.zst'

  try:
  cmd = [ar_cmd, 'x', pkg_path]
  output = subprocess.check_output(cmd, 
stderr=subprocess.STDOUT)

+    data_tar = glob.glob("data.tar.*")


What happens if we have two consecutive builds with the same build 
directory but different compression algorithms? Would we have two 
data.tar.* matches?


Each call to extract() creates a new temporary directory into which the 
content of that particular IPK are extracted. IPKs should contain only 
one data tarball and as such the described scenario should never occur 
(and the length check I added is a merely a safety measure).




This makes sense, thanks for taking the time to explain.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199003): 
https://lists.openembedded.org/g/openembedded-core/message/199003
Mute This Topic: https://lists.openembedded.org/mt/105863603/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] ipk: Do not hardcode payload compression algorithm

2024-05-02 Thread Quentin Schulz via lists.openembedded.org


Hi Philip,

On 5/2/24 4:27 PM, Philip Lorenz via lists.openembedded.org wrote:

[You don't often get email from philip.lorenz=bmw...@lists.openembedded.org. 
Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

The chosen payload compression algorithm can be changed by overriding
`OPKGBUILDCMD`. Ensure that package extraction deals with this by
globbing for "data.tar.*" to select the actual payload tarball.

Signed-off-by: Philip Lorenz 
---
  meta/lib/oe/package_manager/ipk/__init__.py | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager/ipk/__init__.py 
b/meta/lib/oe/package_manager/ipk/__init__.py
index 8cc9953a027..0f0038d00d9 100644
--- a/meta/lib/oe/package_manager/ipk/__init__.py
+++ b/meta/lib/oe/package_manager/ipk/__init__.py
@@ -4,6 +4,7 @@
  # SPDX-License-Identifier: GPL-2.0-only
  #

+import glob
  import re
  import shutil
  import subprocess
@@ -134,11 +135,16 @@ class OpkgDpkgPM(PackageManager):
  tmp_dir = tempfile.mkdtemp()
  current_dir = os.getcwd()
  os.chdir(tmp_dir)
-data_tar = 'data.tar.zst'

  try:
  cmd = [ar_cmd, 'x', pkg_path]
  output = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
+data_tar = glob.glob("data.tar.*")


What happens if we have two consecutive builds with the same build 
directory but different compression algorithms? Would we have two 
data.tar.* matches?


Basically, I'm wondering here if we shouldn't have a way to extract the 
compression algorithm from a variable instead of trying to guess?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198929): 
https://lists.openembedded.org/g/openembedded-core/message/198929
Mute This Topic: https://lists.openembedded.org/mt/105863603/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] linux-firmware: Move Intel AC 9260 bluetooth firmware to a separate package

2024-04-23 Thread Quentin Schulz via lists.openembedded.org


Hi Iskander,

On 4/23/24 16:18, Iskander Amara wrote:

In order to use Bluetooth on Intel AC 9260, we need to select
linux-firmware-ibt-misc package that brings a lot of fimw-
ares that are, in most cases, irrelevant for the used hardware.

This adds a new package linux-firmware-ibt-18 that only includes
the corresponding firmware for Intel AC 9260 bluetooth chips.

Below, the link to the commit that adds Intel AC 9260 firmwares in linux-
firmware:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?h=20220610&id=97339b3a1d3bf3e4c40d679896a27a25fa83765f

Reported-by: Quentin Schulz 


Reviewed-by: Quentin Schulz 

Thanks!
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198627): 
https://lists.openembedded.org/g/openembedded-core/message/198627
Mute This Topic: https://lists.openembedded.org/mt/105690180/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] linux-firmware: Move 9260 bluetooth firmware to a separate package

2024-04-23 Thread Quentin Schulz via lists.openembedded.org


Hi Iskander,

linux-firmware storing all firmwware, can you add "Intel AC 9260" in the 
commit title so we know what we're talking about :) ?


On 4/23/24 14:02, Iskander Amara wrote:

In order to use the Intel bluetooth 9260 firmware, we need to


"""
In order to use Bluetooth on Intel 9260,
"""

is probably a better wording here?


select linux-firmware-ibt-misc package that brings a lot of fi-
mwares that are, in most cases, irrelevant for the used hardware.
 > This adds a new package linux-firmware-ibt-9260 that only inclu-
des Intel 9260 bluetooth chip's firmware.



Would be nice to give the commit in linux-firmware that added the 
firmware for the Bluetooth part of the Intel AC 9260 to justify this 
change, c.f.:


https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?h=20220610&id=97339b3a1d3bf3e4c40d679896a27a25fa83765f


Reported-by: Quentin Schulz 
Signed-off-by: Iskander Amara 
---
  meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
index ff79bb9b33..dfa387ec11 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240312.bb
@@ -344,6 +344,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
   ${PN}-ibt-11-5 ${PN}-ibt-12-16 ${PN}-ibt-hw-37-7 
${PN}-ibt-hw-37-8 \
   ${PN}-ibt-17 \
   ${PN}-ibt-20 \
+ ${PN}-ibt-9260 \
   ${PN}-ibt-misc \
   ${PN}-i915-license ${PN}-i915 \
   ${PN}-ice-license ${PN}-ice \
@@ -1273,6 +1274,7 @@ LICENSE:${PN}-ibt-11-5= "Firmware-ibt_firmware"
  LICENSE:${PN}-ibt-12-16   = "Firmware-ibt_firmware"
  LICENSE:${PN}-ibt-17 = "Firmware-ibt_firmware"
  LICENSE:${PN}-ibt-20 = "Firmware-ibt_firmware"
+LICENSE:${PN}-ibt-9260= "Firmware-ibt_firmware"


I think we should rather name this ${PN}-ibt-18 to match what seems to 
be the naming scheme for those packages.


If you do, please order everything alphabetically (so above ibt-20 for 
example).


Looking good otherwise.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198625): 
https://lists.openembedded.org/g/openembedded-core/message/198625
Mute This Topic: https://lists.openembedded.org/mt/105687932/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] [kirkstone][PATCH] kernel.bbclass: check, if directory exists before removing empty module directory

2024-04-11 Thread Quentin Schulz via lists.openembedded.org


Hi Heiko,

On 4/11/24 10:05, Heiko via lists.openembedded.org wrote:

[You don't often get email from 
heiko.thole=entwicklung.eq-3...@lists.openembedded.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

If the kernel folder does not exist, find will result in an error.
This can occur if the kernel has no modules but, for example, custom modules 
are created.

Add check before deleting.

Signed-off-by: Heiko Thole 
---
  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 dbd89057f3..988a489396 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -452,7 +452,7 @@ kernel_do_install() {
 rm -f 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
 rm -f 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
 # Remove empty module directories to prevent QA issues
-   find 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d -empty 
-delete
+   [ -d "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" ] && 
find "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d -empty -delete


What about using

rm --dir --force 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel"


instead?

   -f, --force
  ignore nonexistent files and arguments, never prompt

   -d, --dir
  remove empty directories

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198119): 
https://lists.openembedded.org/g/openembedded-core/message/198119
Mute This Topic: https://lists.openembedded.org/mt/105458549/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] [yocto-patches] [PATCH 1/2] README: Switch to yocto-patches mailing list

2024-04-10 Thread Quentin Schulz via lists.openembedded.org


Hi Richard,

On 4/10/24 11:29, Richard Purdie via lists.yoctoproject.org wrote:

We're trying to align the various components so tweak pseudo to match our
other projects a little more and use the yocto-patches mailing list for
submissions.

Signed-off-by: Richard Purdie 
---
  README | 17 -
  1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/README b/README
index 468cf66..425ee6e 100644
--- a/README
+++ b/README
@@ -1,17 +1,9 @@
  pseudo -- an analogue to sudo
  
-IMPORTANT NOTE:

+The official home for pseudo's git repository is:
  
-As of this writing, the official home for pseudo's git repository has

-changed to:
git://git.yoctoproject.org/pseudo
  


Maybe we could use https here?

https://git.yoctoproject.org/pseudo

for example?


-The old site at:
-   https://github.com/wrpseudo/pseudo
-
-is no longer the "real" master, although I'll probably try to keep it in
-sync.
-
  OVERVIEW:
  
  The pseudo utility offers a way to run commands in a virtualized "root"

@@ -88,7 +80,6 @@ available for other people to look at.
  
  CONTACT:
  
-Discussions and patches should be directed at the openembedded-core mailing

-list at openembedded-core at lists.openembedded.org. More information at
-https://www.openembedded.org/wiki/Mailing_lists. Bugs should be filed with
-the Yocto project at https://bugzilla.yoctoproject.org/.
+Patches should be directed at the yocto-patches mailing list at yocto-patches
+at lists.yoctoproject.org.  Bugs should be filed with the Yocto project
+at https://bugzilla.yoctoproject.org/.


Maybe we want to add a prefix here too so we can identify easily for 
which project this is for?


e.g. for meta-rockchip we have:

"""
git config format.subjectprefix "meta-rockchip] [PATCH"
"""

maybe we want

"""
git config format.subjectprefix "pseudo] [PATCH"
"""

?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198091): 
https://lists.openembedded.org/g/openembedded-core/message/198091
Mute This Topic: https://lists.openembedded.org/mt/105440467/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][dunfell][PATCH v2] Backport missing licenses

2024-04-02 Thread Quentin Schulz via lists.openembedded.org


Hi all,

I would recommend to identify the patches to backport from the master 
branch and backport those instead of sending one huge patch, lowering 
the risk of forgetting some changes, forgetting to fix some git 
conflicts, etc...


Also considering that Dunfell is soon (this month) EoL, not sure it's 
worth the contributor's effort? But that's up to Colin to decide :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197869): 
https://lists.openembedded.org/g/openembedded-core/message/197869
Mute This Topic: https://lists.openembedded.org/mt/105265076/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] u-boot: fix externalsrc not triggering do_configure on defconfig changes

2024-03-22 Thread Quentin Schulz via lists.openembedded.org


Adding Steve as Cc since he's maintaining the stable branches.

I've tested this on Kirkstone as well (in downstream u-boot recipes 
including u-boot-configure.inc and have that new line themselves), so if 
this gets merged into master, I suggest we backport it to stable 
branches too?


Cheers,
Quentin

On 3/21/24 18:17, Quentin Schulz wrote:

From: Quentin Schulz 

externalsrc only monitors files listed in CONFIGURE_FILES environment
variable to know if it should trigger a rebuild of do_configure. By
default it is unset, but the defconfig from U-Boot should be listed
otherwise an old defconfig may be used even though the change is
technically detected by the do_compile logic later in the process.

Because U-Boot recipe uses `make oldconfig` when no defconfig is passed,
monitor .config for that special case.

This fixes U-Boot recipes not detecting defconfig changes when
devtool'ed.

Reported-by: Iskander Amara 
Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
Tested by running:

MACHINE=qemuarm devtool modify u-boot
MACHINE=qemuarm devtool build u-boot
[modify configs/qemu_arm_defconfig]
MACHINE=qemuarm devtool build u-boot
MACHINE=qemuarm bitbake-diffsigs -t u-boot compile
[Checksum for file oe-devtool-tree-sha1-u-boot changed]

Apply the patch, then run:

MACHINE=qemuarm devtool build u-boot
[modify configs/qemu_arm_defconfig]
MACHINE=qemuarm devtool build u-boot
MACHINE=qemuarm bitbake-diffsigs -t u-boot compile
[Hash for task dependency u-boot:do_configure changed
 Checksum for file qemu_arm_defconfig changed]
---
  meta/recipes-bsp/u-boot/u-boot-configure.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-bsp/u-boot/u-boot-configure.inc 
b/meta/recipes-bsp/u-boot/u-boot-configure.inc
index 235623d25a..378d675364 100644
--- a/meta/recipes-bsp/u-boot/u-boot-configure.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-configure.inc
@@ -8,6 +8,8 @@ inherit uboot-config cml1
  
  DEPENDS += "kern-tools-native"
  
+CONFIGURE_FILES = "${@d.getVar('UBOOT_MACHINE') or '.config'}"

+
  do_configure () {
  if [ -n "${UBOOT_CONFIG}" ]; then
  unset i j

---
base-commit: 94f99434eff15a92cfdc2dce423d32a1b74aab39
change-id: 20240321-u-boot-defconfig-devtool-905683a1bedc

Best regards,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197442): 
https://lists.openembedded.org/g/openembedded-core/message/197442
Mute This Topic: https://lists.openembedded.org/mt/105069918/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] u-boot: fix externalsrc not triggering do_configure on defconfig changes

2024-03-21 Thread Quentin Schulz

From: Quentin Schulz 

externalsrc only monitors files listed in CONFIGURE_FILES environment
variable to know if it should trigger a rebuild of do_configure. By
default it is unset, but the defconfig from U-Boot should be listed
otherwise an old defconfig may be used even though the change is
technically detected by the do_compile logic later in the process.

Because U-Boot recipe uses `make oldconfig` when no defconfig is passed,
monitor .config for that special case.

This fixes U-Boot recipes not detecting defconfig changes when
devtool'ed.

Reported-by: Iskander Amara 
Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
Tested by running:

MACHINE=qemuarm devtool modify u-boot
MACHINE=qemuarm devtool build u-boot
[modify configs/qemu_arm_defconfig]
MACHINE=qemuarm devtool build u-boot
MACHINE=qemuarm bitbake-diffsigs -t u-boot compile
[Checksum for file oe-devtool-tree-sha1-u-boot changed]

Apply the patch, then run:

MACHINE=qemuarm devtool build u-boot
[modify configs/qemu_arm_defconfig]
MACHINE=qemuarm devtool build u-boot
MACHINE=qemuarm bitbake-diffsigs -t u-boot compile
[Hash for task dependency u-boot:do_configure changed
Checksum for file qemu_arm_defconfig changed]
---
 meta/recipes-bsp/u-boot/u-boot-configure.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-bsp/u-boot/u-boot-configure.inc 
b/meta/recipes-bsp/u-boot/u-boot-configure.inc
index 235623d25a..378d675364 100644
--- a/meta/recipes-bsp/u-boot/u-boot-configure.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-configure.inc
@@ -8,6 +8,8 @@ inherit uboot-config cml1
 
 DEPENDS += "kern-tools-native"
 
+CONFIGURE_FILES = "${@d.getVar('UBOOT_MACHINE') or '.config'}"
+
 do_configure () {
 if [ -n "${UBOOT_CONFIG}" ]; then
 unset i j

---
base-commit: 94f99434eff15a92cfdc2dce423d32a1b74aab39
change-id: 20240321-u-boot-defconfig-devtool-905683a1bedc

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197422): 
https://lists.openembedded.org/g/openembedded-core/message/197422
Mute This Topic: https://lists.openembedded.org/mt/105069918/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] python3-gpiod: add recipe

2024-03-18 Thread Quentin Schulz via lists.openembedded.org


Hi Xiangyu Chen,

On 3/18/24 10:35, Xiangyu Chen via lists.openembedded.org wrote:

From: Xiangyu Chen 

python3-gpiod is a python library for interacting with the linux GPIO
character device, it provides a simple way to control a GPIO in less code.

Signed-off-by: Xiangyu Chen 
---
  meta/recipes-devtools/python/python3-gpiod_1.5.4.bb | 12 
  1 file changed, 12 insertions(+)
  create mode 100644 meta/recipes-devtools/python/python3-gpiod_1.5.4.bb

diff --git a/meta/recipes-devtools/python/python3-gpiod_1.5.4.bb 
b/meta/recipes-devtools/python/python3-gpiod_1.5.4.bb
new file mode 100644
index 00..21f0f35cbb
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-gpiod_1.5.4.bb
@@ -0,0 +1,12 @@
+SUMMARY = "Python library for interacting with GPIO"
+DESCRIPTION = "Python library for interacting with the linux GPIO \
+character device. It is a pure Python library and has no dependencies on \
+other packages."
+HOMEPAGE = "https://github.com/hhk7734/python3-gpiod";
+BUGTRACKER = "https://github.com/hhk7734/python3-gpiod/issues";
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=fc4e57275d8c245894e576844466f725"
+
+inherit pypi python_setuptools_build_meta
+
+SRC_URI[sha256sum] = 
"d8e4daa655dee75c33a49f5859b2e36c72385021c06c5552968294b1ad5c2dd0"



I would highly recommend to use the newer version of gpiod.

From the pypi package[1]

"""
Versions 1.5.4 and prior are the deprecated, unofficial, pure-Python 
bindings.

"""

To give a bit more feedback, the same gpiod PyPi package comes from two 
different git repos. Before (and including) v1.5.4, it comes from 
https://github.com/hhk7734/python3-gpiod. Any version after that comes 
from https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/.


The latter is maintained by one of the Linux kernel GPIO subsystem 
maintainer and the former has been abandoned as far as I remember.


c.f. https://github.com/hhk7734/python3-gpiod/issues/39 for more info on 
gpiod package in PyPi.


Cheers,
Quentin

[1] https://pypi.org/project/gpiod/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197298): 
https://lists.openembedded.org/g/openembedded-core/message/197298
Mute This Topic: https://lists.openembedded.org/mt/104999059/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/1] linux-firmware : Add firmaware for Intel 9260 wifi modules.

2024-03-13 Thread Quentin Schulz via lists.openembedded.org


Hi Yannick,

On 3/13/24 17:29, RODRIGUEZ Yannick wrote:

Hi Quentin,

Thanks for your review.

Should i resend a patch with the modification your sugest . It's possible to 
just amend m'y patch ?



For the bluetooth part of the suggestion, a separate patch would be 
welcome. Though it's a suggestion, just a "would be nice to have", 
you're not required per-se to do it for the wifi part to be merged (at 
least that's my opinion as a contributor).


I think it'd be good to send a new version of the patch with the small 
changes in the wording in the commit title and commit log, so you don't 
have to wait for the maintainers to confirm this is a required change.


Don't forget to add the v2 (well it's now v3 technically ;) ) to the 
patch, c.f. 
https://docs.yoctoproject.org/contributor-guide/submit-changes.html#taking-patch-review-into-account 
for how to do it.



It's m'y first patch.



Congratulations :) Wishing you (and us) many more to come!

https://docs.yoctoproject.org/contributor-guide/index.html should help 
you get started. If something isn't clear there (or wrong, or 
misleading, or outdated, etc...), let us know (or send a patch for the 
documentation :) ).


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197051): 
https://lists.openembedded.org/g/openembedded-core/message/197051
Mute This Topic: https://lists.openembedded.org/mt/104908041/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/1] linux-firmware : Add firmaware for Intel 9260 wifi modules.

2024-03-13 Thread Quentin Schulz via lists.openembedded.org


Hi Yannick,

Thanks for the patch.

Typo in the commit title: firmware and not firmaware.

Also, to be pedantic, you're not adding firmware for Intel 9260 modules, 
you're moving the different pieces of firmware to a separate package.


On 3/13/24 16:39, Yannick Rodriguez via lists.openembedded.org wrote:

[You don't often get email from 
yannickrodriguez22=gmail@lists.openembedded.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

From: Yannick Rodriguez 


Intel 9260 wifi modules  is a serie of wireless modules that need firmwares to 
function correctly. The linux firmware recipe does not have a package of these 
firmwares, and this commit add them.



Just to be pedantic, but linux-firmware has a package for it, it's just 
happen to be a package where all the files that didn't match make it. 
Which means it's several dozens of MB big, which isn't really nice :)


Also the commit log is usually wrapped at 72 characters, but I cannot 
find where we put this in the contributor guide... if we even did put it 
there.


Since this 9260 is a combo chip with both Bluetooth and WiFi, what about 
adding a separate package for the bluetooth part as well?


https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?h=20220610&id=97339b3a1d3bf3e4c40d679896a27a25fa83765f

seems to indicate that we can have a
${PN}-ibt-18 package with all firmware/intel/ibt-18-*.ddc and 
firmware/intel/ibt-18-*.sfi?


Looks good otherwise,
Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197050): 
https://lists.openembedded.org/g/openembedded-core/message/197050
Mute This Topic: https://lists.openembedded.org/mt/104908041/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] more pedantry: observation on PACKAGES ordering and bash-completion.bbclass

2024-03-09 Thread Quentin Schulz

Hi,

On March 9, 2024 10:38:18 AM GMT+01:00, "Robert P. J. Day" 
 wrote:
>
>  currently perusing countless recipes to choose really good
>pedagogical examples of "ptest" usage, and i began running across a
>number of recipes that (unrelated to ptest) included snippets toward
>the end of their recipe files that added content to FILES:${PN}.
>here's an example from fwupd:
>
>https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/recipes-bsp/fwupd/fwupd_1.8.9.bb#L130
>
>FILES:${PN} += "${libdir}/fwupd-plugins-* \
>${libdir}/fwupd-${PV} \
>${systemd_unitdir} \
>${datadir}/fish \
>${datadir}/metainfo \
>${datadir}/icons \
>${datadir}/dbus-1 \
>${datadir}/polkit-1 \
>${nonarch_libdir}/modules-load.d"
>
>  since i knew(?) that the default PACKAGES list is processed left to
>right, and that the PN package is left until the end to gather what
>remains, i couldn't understand why so many recipes insisted on adding

"to gather what remains," is not entirely correct. FILES:${PN} is not a 
grab-all variable, it still only takes files matching the globs inside the 
variable, which defaults to:

"""
FILES:${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} 
\ ${sysconfdir} ${sharedstatedir} ${localstatedir} \ ${base_bindir}/* 
${base_sbindir}/* \ ${base_libdir}/*${SOLIBS} \ ${base_prefix}/lib/udev 
${prefix}/lib/udev \ ${base_libdir}/udev ${libdir}/udev \ ${datadir}/${BPN} 
${libdir}/${BPN}/* \ ${datadir}/pixmaps ${datadir}/applications \ 
${datadir}/idl ${datadir}/omf ${datadir}/sounds \ ${libdir}/bonobo/servers"
"""

And you can see that the paths added to fwupd aren't matched by those default 
globs, hence why they are added.

>extra content to FILES:${PN} when the default processing would have
>collected it anyway, unless ... there was something that had been
>appended to PACKAGES that required that.
>
>  sure enough, bash-completion.bbclass:
>
>PACKAGES += "${PN}-bash-completion"
>FILES:${PN}-bash-completion = "${datadir}/bash-completion 
> ${sysconfdir}/bash_completion.d"
>
>  my understanding is that the "proper" ordering of PACKAGES is to
>start with the most focused and specific packages, define their
>content, then move on until, at the end, whatever remains goes into
>PN. which makes that definition of bash-completion.bbclass a bit
>puzzling -- why was it not *prepended* to the PACKAGES list given its
>specificity? and making all that subsequent addition to FILES:${PN}
>unnecessary?
>

If a file is matched only by one glob, then it doesn't matter much in which 
order the packages are listed, which is very likely the case here.

One reason could simply be that += is more natural than =+ and seeing that += 
worked, the contributor didn't think twice about it.

FWIW, one can also do PACKAGE_BEFORE_PN += "${PN}-bash-completion" to have 
bash-completion done right before PN instead of first if using =+.

Moving bash-completion package somewhere else in the PACKAGES list likely 
wouldn't change anything of the globs in FILES:${PN} though.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196874): 
https://lists.openembedded.org/g/openembedded-core/message/196874
Mute This Topic: https://lists.openembedded.org/mt/104825042/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] u-boot: add missing dependency on pyelftools-native

2024-01-24 Thread Quentin Schulz

From: Quentin Schulz 

When TF-A is necessary in U-Boot binary, binman requires elftools to be
installed to be able to generate that U-boot ITB image.

TF-A is necessary for at least all Aarch64 machines, so that is a
non-negligible amount of boards that have this requirement.

As a side note, Rockchip-based machines didn't need this until commit
12c3e948eeab ("rockchip: Drop the FIT generator script") (v2023.04-rc1).

This is already in meta-rockchip, c.f.
https://git.yoctoproject.org/meta-rockchip/commit/recipes-bsp/u-boot?id=6127d169acf239a53df989f34a6b825fa182cc0c
but I feel like this makes more sense to be present in OE-Core.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---

I'm also wondering what are the criteria for having the DEPENDS in
u-boot_.bb instead of u-boot.inc?

 meta/recipes-bsp/u-boot/u-boot_2024.01.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot_2024.01.bb 
b/meta/recipes-bsp/u-boot/u-boot_2024.01.bb
index 4f5b3e5dfd..b15bcaa818 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2024.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2024.01.bb
@@ -1,5 +1,5 @@
 require u-boot-common.inc
 require u-boot.inc
 
-DEPENDS += "bc-native dtc-native"
+DEPENDS += "bc-native dtc-native python3-pyelftools-native"
 

---
base-commit: 999bcf990b1b1357dda0636090561659336cc0bf
change-id: 20240124-u-boot-elftools-native-baa0d2cabff8

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194272): 
https://lists.openembedded.org/g/openembedded-core/message/194272
Mute This Topic: https://lists.openembedded.org/mt/103931554/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 v8 8/8] docs: cover devtool ide

2023-11-02 Thread Quentin Schulz via lists.openembedded.org


Hi Adrian,

Please at least Cc the docs mailing list :) The docs is actually handled 
in a separate repo (well the yocto docs, for bitbake it's in the bitbake 
mono-repo along side the code), by different people.


Cc'ing docs.

First, thanks for sending documentation related to a new feature while 
it's being developed, this is very much appreciated.


As an overall comment, I feel like the documentation about the internal 
working is not necessary. The user shouldn't care about what the tools 
does internally, only how to use it and configure it. If somehow it is 
broken, not supporting a specific use-case or feature, then a look at 
the code is warranted, where the documentation of the internals is desired.

The part I'm talking about is the one between
+   Here is what it does for a recipe which inherits the 
:ref:`ref-classes-cmake` class:

and
+   It's possible to pass multiple recipes to the ``devtool ide`` command.

Other comments inline, only typos. I have never used VSCode and I'm not 
knowledgeable in Meson nor Cmake nor SDKs so that all i could contribute 
to this patch review :)


On 11/1/23 12:01, Adrian Freihofer via lists.openembedded.org wrote:

Cover the new devtool ide plugin in the extensible sdk section.

Many thanks to Enguerrand de Ribaucourt for his re-view and
contributions.

Signed-off-by: Adrian Freihofer 
---
  documentation/sdk-manual/extensible.rst | 153 +++-
  1 file changed, 152 insertions(+), 1 deletion(-)

diff --git a/documentation/sdk-manual/extensible.rst 
b/documentation/sdk-manual/extensible.rst
index 355c6cb0e4a..51d9fff2638 100644
--- a/documentation/sdk-manual/extensible.rst
+++ b/documentation/sdk-manual/extensible.rst
@@ -63,6 +63,8 @@ their own pros and cons:
 need to provide a well-functioning binary artefact cache over the network
 for developers with underpowered laptops.
  
+.. _setting_up_ext_sdk_in_build:

+
  Setting up the Extensible SDK environment directly in a Yocto build
  ---
  
@@ -230,13 +232,15 @@ all the commands.

 See the ":doc:`/ref-manual/devtool-reference`"
 section in the Yocto Project Reference Manual.
  
-Three ``devtool`` subcommands provide entry-points into development:

+Four ``devtool`` subcommands provide entry-points into development:
  


Just remove the number so we don't have to maintain it.


  -  *devtool add*: Assists in adding new software to be built.
  
  -  *devtool modify*: Sets up an environment to enable you to modify

 the source of an existing component.
  
+-  *devtool ide*: Generates a configuration for an IDE.

+
  -  *devtool upgrade*: Updates an existing recipe so that you can
 build it for an updated set of source files.
  
@@ -614,6 +618,153 @@ command:

decide you do not want to proceed with your work. If you do use this
command, realize that the source tree is preserved.
  
+Use ``devtool ide`` to generate a configuration for the IDE

+---
+
+``devtool ide`` automatically configures IDEs for cross-compiling and remote 
debugging.
+
+Two different use cases are supported:
+


Ditto.


+#. *Recipe mode*: Generate the IDE configuration for a workspace created by 
``devtool modify``.
+
+   In order to use the tool, a few settings must be made.
+   As a starting example, the following lines of code can be added to the 
``local.conf`` file::
+
+  # Build the companion debug file system
+  IMAGE_GEN_DEBUGFS = "1"
+  # Optimize build time: with devtool ide the dbg tar is not needed
+  IMAGE_FSTYPES_DEBUGFS = ""
+
+  # ssh is mandatory, no password simplifies the usage
+  EXTRA_IMAGE_FEATURES += "\
+ ssh-server-openssh \
+ debug-tweaks \
+  "
+
+  # Remote debugging needs the gdbserver on the target device
+  IMAGE_INSTALL:append = " gdbserver"
+
+   Assuming the development environment is set up correctly and a workspace 
has been created
+   for the recipe using ``devtool modify recipe``, the following command can 
create the
+   configuration for VSCode in the recipe workspace::
+
+  $ devtool ide recipe core-image-minimal --target root@192.168.7.2
+
+   What this command does exactly depends on the recipe or the build tool used 
by the recipe.
+   Currently, only CMake and Meson are supported natively.
+   Here is what it does for a recipe which inherits the 
:ref:`ref-classes-cmake` class:
+
+   - Prepare the SDK by calling ``bitbake core-image-minimal``, ``gdb-cross``, 
``qemu-native``...
+
+   - Generate a CMake preset with configures CMake to use exactly the same 
environent and


s/with/which/

s/environent/environment/


+ the same CMmake cache configuration as used by ``bitbake recipe``. The 
CMake preset referres


s/referres/refers/


+ to the per-recipe-sysroot of the recipe.
+


s/per-recipe-sysroot/per-recipe sysroot/


+ Currently Configure, Build and Tes

Re: [OE-core] [PATCH 1/3] scripts/patchreview: rework patch detection

2023-11-02 Thread Quentin Schulz via lists.openembedded.org


Hi Ross,

On 10/27/23 17:29, Ross Burton via lists.openembedded.org wrote:

From: Ross Burton 

A previous patch[1] added the ability to allow the search pattern for
patches to be changed, so that patchreview can be used across the entire
meta-oe repository by changing the patterns.

However, this means the caller needs to write long patterns when calling
patchreview.

Instead, we can see if the specified directory contains a layer by
checking if conf/layer.conf exists.  If it does, then search for patches
inside this directory.  If it doesn't, assume that the specified
directory is a repository that contains sublayers (such as
meta-openembedded) and look through each of the directories that match
the pattern meta-*.

This means patchreview can both scan either a single layer (eg
.../poky/meta) or a repository of sublayers (eg .../meta-openembedded).

[1] oe-core 599046ea9302af0cf856d3fcd827f6a2be75b7e1

Signed-off-by: Ross Burton 
---
  scripts/contrib/patchreview.py | 36 +-
  1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/scripts/contrib/patchreview.py b/scripts/contrib/patchreview.py
index 43de105adc2..af66e32e02e 100755
--- a/scripts/contrib/patchreview.py
+++ b/scripts/contrib/patchreview.py
@@ -41,7 +41,7 @@ def blame_patch(patch):
  "--format=%s (%aN <%aE>)",
  "--", patch)).decode("utf-8").splitlines()
  
-def patchreview(path, patches):

+def patchreview(patches):
  import re, os.path
  
  # General pattern: start of line, optional whitespace, tag with optional

@@ -56,11 +56,10 @@ def patchreview(path, patches):
  
  for patch in patches:
  
-fullpath = os.path.join(path, patch)

  result = Result()
-results[fullpath] = result
+results[patch] = result
  
-content = open(fullpath, encoding='ascii', errors='ignore').read()

+content = open(patch, encoding='ascii', errors='ignore').read()
  
  # Find the Signed-off-by tag

  match = sob_re.search(content)
@@ -198,21 +197,40 @@ def histogram(results):
  for k in bars:
  print("%-20s %s (%d)" % (k.capitalize() if k else "No status", 
bars[k], counts[k]))
  
+def gather_patches(candidate):

+# candidate can either be the path to a layer directly (eg meta-intel), or 
a
+# repository that contains other layers (meta-arm). We can determine what 
by
+# looking for a conf/layer.conf file. If that file exists then it's a 
layer,
+# otherwise its a repository of layers and we can assume they're called
+# meta-*.
+


Maybe mention that this expects a pathlib.Path object?


+if (candidate / "conf" / "layer.conf").exists():
+print(f"{candidate} is a layer")
+scan = [candidate]
+else:
+print(f"{candidate} is not a layer, checking for sub-layers")
+scan = [d for d in candidate.iterdir() if d.is_dir() and (d.name == "meta" or 
d.name.startswith("meta-"))]
+print(f"Found layers {' '.join((d.name for d in scan))}")
+


What about just looking for all layer.conf files recursively instead?

e.g.:

scan = [l.parents[1].name for l in candidate.glob('**/conf/layer.conf')

This assumes a layer root directory is the parent of `conf` directory in 
which a layer.conf file is, which I think is a good assumption.


But this does not make any assumption that the layer should be prefixed 
with meta- or be meta, as opposed to the current implementation.



+patches = []
+for directory in scan:
+filenames = subprocess.check_output(("git", "-C", directory, "ls-files", 
"recipes-*/**/*.patch", "recipes-*/**/*.diff"), universal_newlines=True).split()


FWIW, recipes- prefix is NOT enforced, it is derived from BBFILES 
variable in each layer.conf. (I have used layers where a typo was there, 
with recipe- or sometimes just recipes/). I am not saying we need to 
support those, but just merely raising this as a potential shortcoming.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190071): 
https://lists.openembedded.org/g/openembedded-core/message/190071
Mute This Topic: https://lists.openembedded.org/mt/102223656/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] uboot-extlinux-config.bbclass: fix missed override syntax migration

2023-10-16 Thread Quentin Schulz via lists.openembedded.org


Hi Steve,

I think this is appropriate for backporting to earlier branches. 
Considering that dunfell supports both old and new syntax, I don't think 
it matters for that branch.


https://git.openembedded.org/openembedded-core/commit/meta/classes-recipe/uboot-extlinux-config.bbclass?id=b4dd9d873508128adbbf5ff6cf0a3df3d2ffbcf6 
is the URL to the merged commit.


Lemme know how I can help,
Cheers,
Quentin

On 10/5/23 15:39, Quentin Schulz wrote:

From: Quentin Schulz 

uboot-extlinux-config allows to specify multiple "labels" (entries in a
menu, à-la grub) and each of them have their own values for some fields.
Each "base" variable, e.g. UBOOT_EXTLINUX_FDT can be overridden for each
label. This is done via the OVERRIDES mechanism based on the label name,
e.g. UBOOT_EXTLINUX_FDT:linux if linux is a label.

However, OVERRIDES doesn't contain the label globally because it's only
necessary in one task. Therefore, the OVERRIDES itself is modified
within the task. This means that the sigdata will not be told the
dependency on UBOOT_EXTLINUX_FDT:linux, because it cannot know about it.

For this reason, we need to explicitly specify which variables this task
depends on via vardeps varflag for the task.

This was done in the past, but we missed updating it during the override
syntax migration so the cache wouldn't get invalidated if someone
modifies UBOOT_EXTLINUX_FDT:linux from a configuration file or a
bbappend for example.

Let's fix this by migrating it to the new syntax.

Signed-off-by: Quentin Schulz 
---
Cc'ing Steve Sakoman for backporting to stable releases:
- kirkstone
- mickledore

Dunfell should be unnecessary since we support both syntaxes there.
---
  meta/classes-recipe/uboot-extlinux-config.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/uboot-extlinux-config.bbclass 
b/meta/classes-recipe/uboot-extlinux-config.bbclass
index 30bbea57de..0413e760bd 100644
--- a/meta/classes-recipe/uboot-extlinux-config.bbclass
+++ b/meta/classes-recipe/uboot-extlinux-config.bbclass
@@ -159,7 +159,7 @@ python do_create_extlinux_config() {
  bb.fatal('Unable to open %s' % (cfile))
  }
  UBOOT_EXTLINUX_VARS = "CONSOLE MENU_DESCRIPTION ROOT KERNEL_IMAGE FDTDIR FDT 
KERNEL_ARGS INITRD"
-do_create_extlinux_config[vardeps] += "${@' '.join(['UBOOT_EXTLINUX_%s_%s' % (v, l) 
for v in d.getVar('UBOOT_EXTLINUX_VARS').split() for l in 
d.getVar('UBOOT_EXTLINUX_LABELS').split()])}"
+do_create_extlinux_config[vardeps] += "${@' '.join(['UBOOT_EXTLINUX_%s:%s' % (v, l) 
for v in d.getVar('UBOOT_EXTLINUX_VARS').split() for l in 
d.getVar('UBOOT_EXTLINUX_LABELS').split()])}"
  do_create_extlinux_config[vardepsexclude] += "OVERRIDES"
  
  addtask create_extlinux_config before do_install do_deploy after do_compile


---
base-commit: 2b9044361f2855866eed831f8bdb770f2c7d42dc
change-id: 20231005-dev-uboot-extlinux-config-sstate-invalidate-c464136a168b

Best regards,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189304): 
https://lists.openembedded.org/g/openembedded-core/message/189304
Mute This Topic: https://lists.openembedded.org/mt/101776557/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] recipes-rt: update README to match newer override syntax

2023-10-16 Thread Quentin Schulz

From: Quentin Schulz 

The override syntax uses colon (':') instead of underscore ('_') since
Honister (3.4), so let's update the README to use that new syntax.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 meta/recipes-rt/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-rt/README b/meta/recipes-rt/README
index 7d7558de49..0144d68b70 100644
--- a/meta/recipes-rt/README
+++ b/meta/recipes-rt/README
@@ -10,4 +10,4 @@ If you are creating a new BSP which should use linux-yocto-rt 
by default,
 use the line above in the $MACHINE.conf in your BSP layer, and specify the
 following in a linux-yocto-rt bbappend recipe:
 
-COMPATIBLE_MACHINE_$MACHINE = $MACHINE
+COMPATIBLE_MACHINE:$MACHINE = $MACHINE

---
base-commit: 9dc27f922f7a1eae448b9a0ffa35a85f71e58735
change-id: 20231016-dev-compatible_machine-dfa2e1a9700e

Best regards,
-- 
Quentin Schulz 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189284): 
https://lists.openembedded.org/g/openembedded-core/message/189284
Mute This Topic: https://lists.openembedded.org/mt/101992936/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 a typo in help output

2023-10-10 Thread Quentin Schulz via lists.openembedded.org


Hi André,

On 10/10/23 13:30, André Draszik via lists.openembedded.org wrote:

[You don't often get email from git=andred@lists.openembedded.org. Learn 
why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Signed-off-by: André Draszik 


Reviewed-by: Quentin Schulz 

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188913): 
https://lists.openembedded.org/g/openembedded-core/message/188913
Mute This Topic: https://lists.openembedded.org/mt/101872864/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] uboot-extlinux-config.bbclass: fix missed override syntax migration

2023-10-05 Thread Quentin Schulz

From: Quentin Schulz 

uboot-extlinux-config allows to specify multiple "labels" (entries in a
menu, à-la grub) and each of them have their own values for some fields.
Each "base" variable, e.g. UBOOT_EXTLINUX_FDT can be overridden for each
label. This is done via the OVERRIDES mechanism based on the label name,
e.g. UBOOT_EXTLINUX_FDT:linux if linux is a label.

However, OVERRIDES doesn't contain the label globally because it's only
necessary in one task. Therefore, the OVERRIDES itself is modified
within the task. This means that the sigdata will not be told the
dependency on UBOOT_EXTLINUX_FDT:linux, because it cannot know about it.

For this reason, we need to explicitly specify which variables this task
depends on via vardeps varflag for the task.

This was done in the past, but we missed updating it during the override
syntax migration so the cache wouldn't get invalidated if someone
modifies UBOOT_EXTLINUX_FDT:linux from a configuration file or a
bbappend for example.

Let's fix this by migrating it to the new syntax.

Signed-off-by: Quentin Schulz 
---
Cc'ing Steve Sakoman for backporting to stable releases:
- kirkstone
- mickledore

Dunfell should be unnecessary since we support both syntaxes there.
---
 meta/classes-recipe/uboot-extlinux-config.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/uboot-extlinux-config.bbclass 
b/meta/classes-recipe/uboot-extlinux-config.bbclass
index 30bbea57de..0413e760bd 100644
--- a/meta/classes-recipe/uboot-extlinux-config.bbclass
+++ b/meta/classes-recipe/uboot-extlinux-config.bbclass
@@ -159,7 +159,7 @@ python do_create_extlinux_config() {
 bb.fatal('Unable to open %s' % (cfile))
 }
 UBOOT_EXTLINUX_VARS = "CONSOLE MENU_DESCRIPTION ROOT KERNEL_IMAGE FDTDIR FDT 
KERNEL_ARGS INITRD"
-do_create_extlinux_config[vardeps] += "${@' '.join(['UBOOT_EXTLINUX_%s_%s' % 
(v, l) for v in d.getVar('UBOOT_EXTLINUX_VARS').split() for l in 
d.getVar('UBOOT_EXTLINUX_LABELS').split()])}"
+do_create_extlinux_config[vardeps] += "${@' '.join(['UBOOT_EXTLINUX_%s:%s' % 
(v, l) for v in d.getVar('UBOOT_EXTLINUX_VARS').split() for l in 
d.getVar('UBOOT_EXTLINUX_LABELS').split()])}"
 do_create_extlinux_config[vardepsexclude] += "OVERRIDES"
 
 addtask create_extlinux_config before do_install do_deploy after do_compile

---
base-commit: 2b9044361f2855866eed831f8bdb770f2c7d42dc
change-id: 20231005-dev-uboot-extlinux-config-sstate-invalidate-c464136a168b

Best regards,
-- 
Quentin Schulz 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188720): 
https://lists.openembedded.org/g/openembedded-core/message/188720
Mute This Topic: https://lists.openembedded.org/mt/101776557/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] uboot-extlinux-config.bbclass: fix old override syntax in comment

2023-06-26 Thread Quentin Schulz

From: Quentin Schulz 

The comment specifies how to use the variables but uses the older and
now unsupported override syntax. Let's update to match the newer syntax.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
This was NOT tested, only looked weird and the code seems to indicate it
can use the new syntax (which is not always guaranteed, see
PREFERRED_PROVIDER).
---
 meta/classes-recipe/uboot-extlinux-config.bbclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes-recipe/uboot-extlinux-config.bbclass 
b/meta/classes-recipe/uboot-extlinux-config.bbclass
index 86a7d30ca0..653e583663 100644
--- a/meta/classes-recipe/uboot-extlinux-config.bbclass
+++ b/meta/classes-recipe/uboot-extlinux-config.bbclass
@@ -33,11 +33,11 @@
 # UBOOT_EXTLINUX_DEFAULT_LABEL ??= "Linux Default"
 # UBOOT_EXTLINUX_TIMEOUT ??= "30"
 #
-# UBOOT_EXTLINUX_KERNEL_IMAGE_default ??= "../zImage"
-# UBOOT_EXTLINUX_MENU_DESCRIPTION_default ??= "Linux Default"
+# UBOOT_EXTLINUX_KERNEL_IMAGE:default ??= "../zImage"
+# UBOOT_EXTLINUX_MENU_DESCRIPTION:default ??= "Linux Default"
 #
-# UBOOT_EXTLINUX_KERNEL_IMAGE_fallback ??= "../zImage-fallback"
-# UBOOT_EXTLINUX_MENU_DESCRIPTION_fallback ??= "Linux Fallback"
+# UBOOT_EXTLINUX_KERNEL_IMAGE:fallback ??= "../zImage-fallback"
+# UBOOT_EXTLINUX_MENU_DESCRIPTION:fallback ??= "Linux Fallback"
 #
 # Results:
 #

---
base-commit: 13b646c0e167ca52f69c91be5538049b172015ac
change-id: 20230626-dev-uboot-extlinux-config-comment-new-syntax-82396af30935

Best regards,
-- 
Quentin Schulz 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183421): 
https://lists.openembedded.org/g/openembedded-core/message/183421
Mute This Topic: https://lists.openembedded.org/mt/99788280/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] ref-manual: Fix invalid feature name

2023-02-20 Thread Quentin Schulz via lists.openembedded.org


Hi Niko,

This should be sent to the docs mailing list instead 
(d...@lists.yoctoproject.org). Cc'ing now.


On 2/19/23 15:31, Niko Mauno via lists.openembedded.org wrote:

Replace the invalid feature name with correct one which helps to avoid
following bitbake error

   ERROR: Nothing PROVIDES 'core-image-minimal'
   core-image-minimal was skipped: 'empty-root-passwd' in IMAGE_FEATURES (added 
via EXTRA_IMAGE_FEATURES) is not a valid image feature.

Signed-off-by: Niko Mauno 


Reviewed-by: Quentin Schulz 

@Michael, this typo seems to have landed in langdale too so probably a 
candidate for backport.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177398): 
https://lists.openembedded.org/g/openembedded-core/message/177398
Mute This Topic: https://lists.openembedded.org/mt/97066768/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 1/4] dtc: version bump and add python wrapper

2023-02-16 Thread Quentin Schulz via lists.openembedded.org


Hi Trevor,

On 2/14/23 19:30, Trevor Woerner wrote:

Bump the version of dtc from 1.6.1 to to 1.7.0.

Add support for building the python wrapper around libfdt.

Signed-off-by: Trevor Woerner 
---
  ...tdump-fix-Werror-int-to-pointer-cast.patch | 40 ---
  meta/recipes-kernel/dtc/dtc/0001-meson.patch  | 37 +
  .../dtc/{dtc_1.6.1.bb => dtc_1.7.0.bb}| 18 +
  3 files changed, 48 insertions(+), 47 deletions(-)
  delete mode 100644 
meta/recipes-kernel/dtc/dtc/0001-fdtdump-fix-Werror-int-to-pointer-cast.patch
  create mode 100644 meta/recipes-kernel/dtc/dtc/0001-meson.patch
  rename meta/recipes-kernel/dtc/{dtc_1.6.1.bb => dtc_1.7.0.bb} (51%)

diff --git 
a/meta/recipes-kernel/dtc/dtc/0001-fdtdump-fix-Werror-int-to-pointer-cast.patch 
b/meta/recipes-kernel/dtc/dtc/0001-fdtdump-fix-Werror-int-to-pointer-cast.patch
deleted file mode 100644
index 4c3e34b1ffd2..
--- 
a/meta/recipes-kernel/dtc/dtc/0001-fdtdump-fix-Werror-int-to-pointer-cast.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-Fix the build of fdtdump with mingw.
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From ae0ce1fa7f4d679b5f8df1fc0e797246e43547fe Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= 
-Date: Wed, 25 Aug 2021 16:13:50 +0400
-Subject: [PATCH] fdtdump: fix -Werror=int-to-pointer-cast
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-With mingw64-gcc, the compiler complains with various warnings:
-error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
-
-Signed-off-by: Marc-André Lureau 
-Message-Id: <20210825121350.213551-1-marcandre.lur...@redhat.com>
-Acked-by: Rob Herring 
-Signed-off-by: David Gibson 

- fdtdump.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/fdtdump.c b/fdtdump.c
-index d9fb374..483f367 100644
 a/fdtdump.c
-+++ b/fdtdump.c
-@@ -21,7 +21,7 @@
- #define MAX_VERSION 17
-
- #define ALIGN(x, a)   (((x) + ((a) - 1)) & ~((a) - 1))
--#define PALIGN(p, a)  ((void *)(ALIGN((unsigned long)(p), (a
-+#define PALIGN(p, a)  ((void *)(ALIGN((uintptr_t)(p), (a
- #define GET_CELL(p)   (p += 4, *((const fdt32_t *)(p-4)))
-
- static const char *tagname(uint32_t tag)
---
-2.25.1
-
diff --git a/meta/recipes-kernel/dtc/dtc/0001-meson.patch 
b/meta/recipes-kernel/dtc/dtc/0001-meson.patch
new file mode 100644
index ..10c4f8706194
--- /dev/null
+++ b/meta/recipes-kernel/dtc/dtc/0001-meson.patch
@@ -0,0 +1,37 @@
+From faa02d4a60859089017bf92e0e3f49d600c44d73 Mon Sep 17 00:00:00 2001
+From: Trevor Woerner 
+Date: Sun, 12 Feb 2023 14:37:04 -0500
+Subject: [PATCH] allow pylibfdt in cross
+
+Allow pylibfdt to be built even in cross-development scenarios.
+
+Upstream-Status: Inappropriate [embedded specific]
+


Is this really inappropriate? Cross-compilation is not THAT niche 
anymore that people aren't open to support it? What about opening an 
issue/ticket upstream and see what they tell us? Or do you already have 
such info, in which case can you give a link to this justification here?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177279): 
https://lists.openembedded.org/g/openembedded-core/message/177279
Mute This Topic: https://lists.openembedded.org/mt/96966808/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] Use zImage instead of linux.bin in fitImage

2023-01-27 Thread Quentin Schulz via lists.openembedded.org


Hi Dave,

On 1/25/23 18:24, dowens via lists.openembedded.org wrote:

I'm trying to build a fit image for an ARM target and am struggling to 
configure kernel-fitimage in such a way that it includes zImage as the fitImage 
kernel instead of linux.bin.  zImage is significantly smaller than linux.bin 
and can be used on my system without needing to modify u-boot's 
CONFIG_SYS_BOOTM_LEN due to the large kernel size.

I've tried several permutations of the following settings in my machine.conf 
file without success:
KERNEL_CLASSES += "kernel-fitimage"
KERNEL_IMAGETYPE = "fitImage"
KERNEL_IMAGETYPES += "zImage"
KERNEL_IMAGETYPE_REPLACEMENT = "zImage"

I've also tried patterning my config on 
oe-core/meta/lib/oeqa/selftest/cases/fitimage.py which uses several 
combinations of the settings above.  In every case, linux.bin is the kernel 
included in the resulting fitImage.  Is there some combination of settings that 
will enable zImage in my fit image?



I believe the issue is this line here:
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/kernel-fitimage.bbclass#n572

I would naively suggest to replace linux.bin with 
${KERNEL_IMAGETYPE_REPLACEMENT} and see where this leads you?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176443): 
https://lists.openembedded.org/g/openembedded-core/message/176443
Mute This Topic: https://lists.openembedded.org/mt/96525244/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] curl: don't enable debug builds

2023-01-11 Thread Quentin Schulz via lists.openembedded.org


Hi Ross,

On 1/11/23 15:17, Ross Burton wrote:

In oe-core 27824261 --enable-debug was added to the configure arguments
to turn on debugging symbols.  However, enabling debug mode does more
than turn on debugging symbols and introduces some codepaths that can be
controlled with environment variables.  Bluntly, the curl maintainer
says that --enable-debug should not be used in production:

https://urldefense.com/v3/__https://curl.se/mail/lib-2023-01/0039.html__;!!OOPJP91ZZw!jMBUWN09d9qh5ERXzeSectyn9T7uX0vl50AFyD3lmFEPTECVwbRqWi6LWeV2NdnKZMWF2rZtDMtAe08Lsb_e3phBQgWpikZIzA$

I did a build and verified that the curl-dbg package doesn't massively
shrink, so the debug symbols are still being built.

Remove the debug options and hide them behind a PACKAGECONFIG, with a
comment that it should not be used in production.

Signed-off-by: Ross Burton 
---
  meta/recipes-support/curl/curl_7.87.0.bb | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/curl/curl_7.87.0.bb 
b/meta/recipes-support/curl/curl_7.87.0.bb
index a3ad66f1aa3..9956a284228 100644
--- a/meta/recipes-support/curl/curl_7.87.0.bb
+++ b/meta/recipes-support/curl/curl_7.87.0.bb
@@ -32,6 +32,8 @@ PACKAGECONFIG:class-nativesdk = "ipv6 openssl proxy random 
threaded-resolver ver
  PACKAGECONFIG[ares] = 
"--enable-ares,--disable-ares,c-ares,,,threaded-resolver"
  PACKAGECONFIG[brotli] = "--with-brotli,--without-brotli,brotli"
  PACKAGECONFIG[builtinmanual] = "--enable-manual,--disable-manual"
+# Don't use this in production
+PACKAGECONFIG[debug] = "--enable-debug,--disable-debug"


Should we have --disable-curldebug in the enable path here? I see you 
remove it further down but it's not here.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175750): 
https://lists.openembedded.org/g/openembedded-core/message/175750
Mute This Topic: https://lists.openembedded.org/mt/96200338/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] packagegroup-core-boot: make init-ifupdown package a recommendation

2023-01-09 Thread Quentin Schulz

From: Quentin Schulz 

init-ifupdown provides an /etc/network/interfaces, which disables
interface management with networkmanager for example. If a network
manager (such as networkmanager) is provided, there may not be a need
for network related init scripts provided by init-ifupdown, so let's
make it a recommendation so it can be easily removed in image recipes
via the NO_RECOMMENDATIONS/BAD_RECOMMENDATIONS mechanism.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
Signed-off-by: Quentin Schulz 
---
 meta/recipes-core/packagegroups/packagegroup-core-boot.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
index faf7bc0026..a7bad81023 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
@@ -18,7 +18,6 @@ EFI_PROVIDER ??= "grub-efi"
 
 SYSVINIT_SCRIPTS = "${@bb.utils.contains('MACHINE_FEATURES', 'rtc', 
'${VIRTUAL-RUNTIME_base-utils-hwclock}', '', d)} \
 modutils-initscripts \
-init-ifupdown \
 ${VIRTUAL-RUNTIME_initscripts} \
"
 
@@ -38,4 +37,5 @@ RDEPENDS:${PN} = "\
 
 RRECOMMENDS:${PN} = "\
 ${VIRTUAL-RUNTIME_base-utils-syslog} \
-${MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS}"
+${MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS} \
+${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "init-ifupdown", "", 
d)}"

---
base-commit: a134a7186b2266378bc0b08c134e169a943eedde
change-id: 20230109-optional-ifupdown-f25f75924f58

Best regards,
-- 
Quentin Schulz 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175692): 
https://lists.openembedded.org/g/openembedded-core/message/175692
Mute This Topic: https://lists.openembedded.org/mt/96155140/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] [poky] [PATCH] oe-depends-dot: Handle new format for task-depends.dot

2023-01-09 Thread Quentin Schulz via lists.openembedded.org


Hi Steve,

On 5/30/22 01:27, Steve Sakoman wrote:

On Tue, May 24, 2022 at 11:03 AM Rusty Howell  wrote:


From: Rusty Howell 

The .dot file created by `bitbake -g` changed formats a while ago, which
broke oe-depends-dot.


Should this patch be taken for kirkstone too?



I believe so, without:

$ oe-depends-dot -k init-ifupdown:do_compile -w task-depends.dot
ERROR: Can't find key init-ifupdown:do_compile in task-depends.dot

with:

$ oe-depends-dot -k init-ifupdown -w task-depends.dot
Because: packagegroup-core-boot theobroma-demo-image
theobroma-demo-image -> packagegroup-core-boot -> init-ifupdown

Tested on Kirkstone 4.0.6.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175682): 
https://lists.openembedded.org/g/openembedded-core/message/175682
Mute This Topic: https://lists.openembedded.org/mt/91421054/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-fitimage: Allow user to select dtb when multiple dtb exists

2023-01-04 Thread Quentin Schulz via lists.openembedded.org




On 1/4/23 03:53, Sandeep Gundlupet Raju via lists.openembedded.org wrote:

Allow user to select the default DTB for FIT image when multiple
dtb's exists.

 From machine.conf or local.conf user can specify the default dtb
for FIT image as shown below.

FIT_CONF_DEFAULT_DTB = "board-default.dtb"

Signed-off-by: Sandeep Gundlupet Raju 
---
  meta/classes-recipe/kernel-fitimage.bbclass | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel-fitimage.bbclass 
b/meta/classes-recipe/kernel-fitimage.bbclass
index cb6635a673..6cdb0e0174 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -89,6 +89,9 @@ FIT_CONF_PREFIX[doc] = "Prefix to use for FIT configuration node 
name"
  
  FIT_SUPPORTED_INITRAMFS_FSTYPES ?= "cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.zst cpio.gz ext2.gz cpio"
  
+# Allow user to select the default DTB for FIT image when multiple dtb's exists.

+FIT_CONF_DEFAULT_DTB ?= ""
+
  # Keys used to sign individually image nodes.
  # The keys to sign image nodes must be different from those used to sign
  # configuration nodes, otherwise the "required" property, from
@@ -412,6 +415,7 @@ fitimage_emit_section_config() {
bootscr_line=""
setup_line=""
default_line=""
+   default_dtb_image="${FIT_CONF_DEFAULT_DTB}"
  
  	dtb_image_sect=$(symlink_points_below $dtb_image "${EXTERNAL_KERNEL_DEVICETREE}")

if [ -z "$dtb_image_sect" ]; then
@@ -462,7 +466,13 @@ fitimage_emit_section_config() {
# default node is selected based on dtb ID if it is present,
# otherwise its selected based on kernel ID
if [ -n "$dtb_image" ]; then
-   default_line="default = 
\"${FIT_CONF_PREFIX}$dtb_image\";"
+   # Select default node as user specified dtb when
+   # multiple dtb exists.
+   if [ -n "$default_dtb_image" ]; then
+   default_line="default = 
\"${FIT_CONF_PREFIX}$default_dtb_image\";"


Shouldn't we error out if the requested device tree does not exist here 
so that we don't create an invalid fitimage?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175464): 
https://lists.openembedded.org/g/openembedded-core/message/175464
Mute This Topic: https://lists.openembedded.org/mt/96043774/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/2] kernel-fitimage: Adjust order of dtb/dtbo files

2023-01-04 Thread Quentin Schulz via lists.openembedded.org


Hi Sandeep,

On 1/4/23 03:53, Sandeep Gundlupet Raju via lists.openembedded.org wrote:

The dtb files must be before the dtbo files, otherwise the overlays may
not be applied correctly.

 From Bruce Ashfield:

   We can split between dtbs and dtbos, they just need to be sorted
   for reproducibility reasons. Two loops versus one, would be
   fine, with not too much duplicated code.

   Of course, this was only working by luck previously (before the
   sort), since it has always been gathering dtbs and dtbo's with
   find, depending on filesystem ordering for the order in the
   fitimage).

Signed-off-by: Sandeep Gundlupet Raju 
---
  meta/classes-recipe/kernel-fitimage.bbclass | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel-fitimage.bbclass 
b/meta/classes-recipe/kernel-fitimage.bbclass
index 7980910aa8..cb6635a673 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -590,7 +590,7 @@ fitimage_assemble() {
  
  	if [ -n "${EXTERNAL_KERNEL_DEVICETREE}" ]; then

dtbcount=1
-   for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" \( -name 
'*.dtb' -o -name '*.dtbo' \) -printf '%P\n' | sort); do
+   for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtb' 
-printf '%P\n' | sort); do


I believe you could have

for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtb' -printf 
'%P\n' | sort) $(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtbo' 
-printf '%P\n' | sort); do


would make sure dtbs appear before dtbos in the fitimage sections but 
still use the same logic within the loop without going for code duplication.


I believe the issue is the content of the DTBS variable, which might 
start with a dtbo file.
When this happens, the default configuration for the fitimage takes the 
dtbo only and I guess this is your bug.


We could also decide to have the original loop but have two variables:
DTBS for dtbs only, matched on file extension
and DTBOS for dtbos only

Then you'd iterate over DTBS for fitimage_emit_section_config first and 
then DTBOS.


I'm also not sure we need to create fit configuration nodes for dtbos 
only? but maybe there's something specific to security here?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175463): 
https://lists.openembedded.org/g/openembedded-core/message/175463
Mute This Topic: https://lists.openembedded.org/mt/96043776/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] cairo: fix CVE patches assigned wrong CVE number

2023-01-02 Thread Quentin Schulz

From: Quentin Schulz 

CVE-2019-6461 and CVE-2019-6462 are fixed, but the reporting is
incorrect as the patch for CVE-2019-6461 is actually for CVE-2019-6462
and vice-versa.

This swaps both files and edit the CVE field to report the correct
identifier.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
Changes in v2:
- Rebased on top of master
- Link to v1: 
https://lore.kernel.org/r/20221214-cairo-cve-typo-v1-1-8ecb1bf8f...@theobroma-systems.com
---
 .../cairo/cairo/CVE-2019-6461.patch| 46 ++
 .../cairo/cairo/CVE-2019-6462.patch| 46 --
 2 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
index 0b7d9a0c36..a2dba6cb20 100644
--- a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
@@ -1,40 +1,20 @@
-CVE: CVE-2019-6461
-Upstream-Status: Backport
-Signed-off-by: Quentin Schulz 
-
-From ab2c5ee21e5f3d3ee4b3f67cfcd5811a4f99c3a0 Mon Sep 17 00:00:00 2001
-From: Heiko Lewin 
-Date: Sun, 1 Aug 2021 11:16:03 +
-Subject: [PATCH] _arc_max_angle_for_tolerance_normalized: fix infinite loop
+There is an assertion in function _cairo_arc_in_direction().
 

- src/cairo-arc.c | 4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
+CVE: CVE-2019-6461
+Upstream-Status: Pending
+Signed-off-by: Ross Burton 
 
 diff --git a/src/cairo-arc.c b/src/cairo-arc.c
-index 390397bae..1c891d1a0 100644
+index 390397bae..1bde774a4 100644
 --- a/src/cairo-arc.c
 +++ b/src/cairo-arc.c
-@@ -90,16 +90,18 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
-   { M_PI / 11.0,  9.81410988043554039085e-09 },
- };
- int table_size = ARRAY_LENGTH (table);
-+const int max_segments = 1000; /* this value is chosen arbitrarily. this 
gives an error of about 1.74909e-20 */
+@@ -186,7 +186,8 @@ _cairo_arc_in_direction (cairo_t *cr,
+ if (cairo_status (cr))
+ return;
  
- for (i = 0; i < table_size; i++)
-   if (table[i].error < tolerance)
-   return table[i].angle;
+-assert (angle_max >= angle_min);
++if (angle_max < angle_min)
++   return;
  
- ++i;
-+
- do {
-   angle = M_PI / i++;
-   error = _arc_error_normalized (angle);
--} while (error > tolerance);
-+} while (error > tolerance && i < max_segments);
- 
- return angle;
- }
--- 
-2.38.1
-
+ if (angle_max - angle_min > 2 * M_PI * MAX_FULL_CIRCLES) {
+   angle_max = fmod (angle_max - angle_min, 2 * M_PI);
diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
index 4e4598c5b5..7c3209291b 100644
--- a/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
@@ -1,20 +1,40 @@
-There is an assertion in function _cairo_arc_in_direction().
-
 CVE: CVE-2019-6462
-Upstream-Status: Pending
-Signed-off-by: Ross Burton 
+Upstream-Status: Backport
+Signed-off-by: Quentin Schulz 
+
+From ab2c5ee21e5f3d3ee4b3f67cfcd5811a4f99c3a0 Mon Sep 17 00:00:00 2001
+From: Heiko Lewin 
+Date: Sun, 1 Aug 2021 11:16:03 +
+Subject: [PATCH] _arc_max_angle_for_tolerance_normalized: fix infinite loop
+
+---
+ src/cairo-arc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/cairo-arc.c b/src/cairo-arc.c
-index 390397bae..1bde774a4 100644
+index 390397bae..1c891d1a0 100644
 --- a/src/cairo-arc.c
 +++ b/src/cairo-arc.c
-@@ -186,7 +186,8 @@ _cairo_arc_in_direction (cairo_t *cr,
- if (cairo_status (cr))
- return;
+@@ -90,16 +90,18 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
+   { M_PI / 11.0,  9.81410988043554039085e-09 },
+ };
+ int table_size = ARRAY_LENGTH (table);
++const int max_segments = 1000; /* this value is chosen arbitrarily. this 
gives an error of about 1.74909e-20 */
  
--assert (angle_max >= angle_min);
-+if (angle_max < angle_min)
-+   return;
+ for (i = 0; i < table_size; i++)
+   if (table[i].error < tolerance)
+   return table[i].angle;
  
- if (angle_max - angle_min > 2 * M_PI * MAX_FULL_CIRCLES) {
-   angle_max = fmod (angle_max - angle_min, 2 * M_PI);
+ ++i;
++
+ do {
+   angle = M_PI / i++;
+   error = _arc_error_normalized (angle);
+-} while (error > tolerance);
++} while (error > tolerance && i < max_segments);
+ 
+ return angle;
+ }
+-- 
+2.38.1
+

---
base-commit: 3a8654b860fa98f94e80c3c3fff359ffed14bbe7
change-id: 20221214-cairo-cve-typo-fd0d89835d77

Best regards,
-- 
Quentin Schulz 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175316): 
https://lists.openembedded.org/g/openembedded-core/message/175316
Mute This Topic: https://lists.open

[OE-core] [PATCH] cairo: fix CVE patches assigned wrong CVE number

2022-12-14 Thread Quentin Schulz

From: Quentin Schulz 

CVE-2019-6461 and CVE-2019-6462 are fixed, but the reporting is
incorrect as the patch for CVE-2019-6461 is actually for CVE-2019-6462
and vice-versa.

This swaps both files and edit the CVE field to report the correct
identifier.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
 .../cairo/cairo/CVE-2019-6461.patch | 21 +++--
 .../cairo/cairo/CVE-2019-6462.patch | 21 ++---
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
index 5232cf70c6..a2dba6cb20 100644
--- a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
@@ -1,19 +1,20 @@
-There is a potential infinite-loop in function _arc_error_normalized().
+There is an assertion in function _cairo_arc_in_direction().
 
 CVE: CVE-2019-6461
 Upstream-Status: Pending
 Signed-off-by: Ross Burton 
 
 diff --git a/src/cairo-arc.c b/src/cairo-arc.c
-index 390397bae..f9249dbeb 100644
+index 390397bae..1bde774a4 100644
 --- a/src/cairo-arc.c
 +++ b/src/cairo-arc.c
-@@ -99,7 +99,7 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
- do {
-   angle = M_PI / i++;
-   error = _arc_error_normalized (angle);
--} while (error > tolerance);
-+} while (error > tolerance && error > __DBL_EPSILON__);
+@@ -186,7 +186,8 @@ _cairo_arc_in_direction (cairo_t *cr,
+ if (cairo_status (cr))
+ return;
  
- return angle;
- }
+-assert (angle_max >= angle_min);
++if (angle_max < angle_min)
++   return;
+ 
+ if (angle_max - angle_min > 2 * M_PI * MAX_FULL_CIRCLES) {
+   angle_max = fmod (angle_max - angle_min, 2 * M_PI);
diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
index 4e4598c5b5..e3a8d5a219 100644
--- a/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
@@ -1,20 +1,19 @@
-There is an assertion in function _cairo_arc_in_direction().
+There is a potential infinite-loop in function _arc_error_normalized().
 
 CVE: CVE-2019-6462
 Upstream-Status: Pending
 Signed-off-by: Ross Burton 
 
 diff --git a/src/cairo-arc.c b/src/cairo-arc.c
-index 390397bae..1bde774a4 100644
+index 390397bae..f9249dbeb 100644
 --- a/src/cairo-arc.c
 +++ b/src/cairo-arc.c
-@@ -186,7 +186,8 @@ _cairo_arc_in_direction (cairo_t *cr,
- if (cairo_status (cr))
- return;
+@@ -99,7 +99,7 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
+ do {
+   angle = M_PI / i++;
+   error = _arc_error_normalized (angle);
+-} while (error > tolerance);
++} while (error > tolerance && error > __DBL_EPSILON__);
  
--assert (angle_max >= angle_min);
-+if (angle_max < angle_min)
-+   return;
- 
- if (angle_max - angle_min > 2 * M_PI * MAX_FULL_CIRCLES) {
-   angle_max = fmod (angle_max - angle_min, 2 * M_PI);
+ return angle;
+ }

---
base-commit: a89bea9fed0005bc7d820a1fc6a9d6dd7c246c22
change-id: 20221214-cairo-cve-typo-fd0d89835d77

Best regards,
-- 
Quentin Schulz 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174552): 
https://lists.openembedded.org/g/openembedded-core/message/174552
Mute This Topic: https://lists.openembedded.org/mt/95663780/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] cairo: update patch for CVE-2019-6461 with upstream solution

2022-12-13 Thread Quentin Schulz via lists.openembedded.org

Upstream went with something slightly different so let's update the
patch so we don't have to carry a patch that isn't going to be merged.

This patch is part of snapshot 1.17.6.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
---
 .../cairo/cairo/CVE-2019-6461.patch| 35 +-
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
index 5232cf70c6..0b7d9a0c36 100644
--- a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
@@ -1,19 +1,40 @@
-There is a potential infinite-loop in function _arc_error_normalized().
-
 CVE: CVE-2019-6461
-Upstream-Status: Pending
-Signed-off-by: Ross Burton 
+Upstream-Status: Backport
+Signed-off-by: Quentin Schulz 
+
+From ab2c5ee21e5f3d3ee4b3f67cfcd5811a4f99c3a0 Mon Sep 17 00:00:00 2001
+From: Heiko Lewin 
+Date: Sun, 1 Aug 2021 11:16:03 +
+Subject: [PATCH] _arc_max_angle_for_tolerance_normalized: fix infinite loop
+
+---
+ src/cairo-arc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/cairo-arc.c b/src/cairo-arc.c
-index 390397bae..f9249dbeb 100644
+index 390397bae..1c891d1a0 100644
 --- a/src/cairo-arc.c
 +++ b/src/cairo-arc.c
-@@ -99,7 +99,7 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
+@@ -90,16 +90,18 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
+   { M_PI / 11.0,  9.81410988043554039085e-09 },
+ };
+ int table_size = ARRAY_LENGTH (table);
++const int max_segments = 1000; /* this value is chosen arbitrarily. this 
gives an error of about 1.74909e-20 */
+ 
+ for (i = 0; i < table_size; i++)
+   if (table[i].error < tolerance)
+   return table[i].angle;
+ 
+ ++i;
++
  do {
angle = M_PI / i++;
error = _arc_error_normalized (angle);
 -} while (error > tolerance);
-+} while (error > tolerance && error > __DBL_EPSILON__);
++} while (error > tolerance && i < max_segments);
  
  return angle;
  }
+-- 
+2.38.1
+

---
base-commit: cc05bc04156122fd6f918191a9cec7bc0392415e
change-id: 20221213-cairo-cve-2019-6461-77eaa8fdeb06

Best regards,
-- 
Quentin Schulz 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174538): 
https://lists.openembedded.org/g/openembedded-core/message/174538
Mute This Topic: https://lists.openembedded.org/mt/95647179/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] lib/sstatesig: Drop OEBasic siggen

2022-12-12 Thread Quentin Schulz via lists.openembedded.org


Hi Richard,

"Forwarding" this to Michael as a docs update requirement notice 
(yocto-docs and bitbake).


Cheers,
Quentin

On 12/11/22 17:12, Richard Purdie wrote:

We're now used to using hashes as part of the task hashes and the sstate code
relies on this. The older OEBasic hash approach therefore wouldn't work and
can be removed.

Signed-off-by: Richard Purdie 
---
  meta/lib/oe/sstatesig.py | 10 --
  1 file changed, 10 deletions(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index bf48aed7e11..f0224454c93 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -101,15 +101,6 @@ def sstate_lockedsigs(d):
  sigs[pn][task] = [h, siggen_lockedsigs_var]
  return sigs
  
-class SignatureGeneratorOEBasic(bb.siggen.SignatureGeneratorBasic):

-name = "OEBasic"
-def init_rundepcheck(self, data):
-self.abisaferecipes = (data.getVar("SIGGEN_EXCLUDERECIPES_ABISAFE") or 
"").split()
-self.saferecipedeps = (data.getVar("SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS") or 
"").split()
-pass
-def rundep_check(self, fn, recipename, task, dep, depname, dataCaches = 
None):
-return sstate_rundepfilter(self, fn, recipename, task, dep, depname, 
dataCaches)
-
  class SignatureGeneratorOEBasicHashMixIn(object):
  supports_multiconfig_datacaches = True
  
@@ -326,7 +317,6 @@ class SignatureGeneratorOEEquivHash(SignatureGeneratorOEBasicHashMixIn, bb.sigge

  bb.fatal("OEEquivHash requires SSTATE_HASHEQUIV_METHOD to be set")
  
  # Insert these classes into siggen's namespace so it can see and select them

-bb.siggen.SignatureGeneratorOEBasic = SignatureGeneratorOEBasic
  bb.siggen.SignatureGeneratorOEBasicHash = SignatureGeneratorOEBasicHash
  bb.siggen.SignatureGeneratorOEEquivHash = SignatureGeneratorOEEquivHash
  







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174489): 
https://lists.openembedded.org/g/openembedded-core/message/174489
Mute This Topic: https://lists.openembedded.org/mt/95602001/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 1/2] qemurunner.py: support setting slirp host IP address

2022-11-18 Thread Quentin Schulz via lists.openembedded.org


Hi Mikko,

On 11/18/22 17:08, Mikko Rapeli wrote:

By default host side IP address is not set and qemu listens
on all IP addresses on the host machine which is not a good
idea when images have root login enabled without password.
It make sense to listen only on localhost IP address 127.0.0.1 using
config change like:

QB_SLIRP_OPT = "-netdev user,id=net0,hostfwd=tcp:127.0.0.1:-:22"

This config works for qemu itself, but breaks runqemu which tries to
parse the host side port number from qemu process command line arguments.
So change the runqemu side hostfwd parsing for port number to ignore
the host IP address field.

Reviewed-by: Quentin Schulz 
Signed-off-by: Mikko Rapeli 
---
  meta/lib/oeqa/utils/qemurunner.py | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

v3: use IP address from command line too

v2: improved commit message, 
https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/message/173250__;!!OOPJP91ZZw!nc5rsa_z35-LR56OMU2tL-KBM9kWHZcqgS1SrAHixpNlYyMcTmapd_Lpj3I943ZmEYiGYf7HvBu8YBNgFBnHoWtOuAEQkgIHwtaHDQ$

v1: 
https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/topic/95016024*173234__;Iw!!OOPJP91ZZw!nc5rsa_z35-LR56OMU2tL-KBM9kWHZcqgS1SrAHixpNlYyMcTmapd_Lpj3I943ZmEYiGYf7HvBu8YBNgFBnHoWtOuAEQkgKJOx__4Q$

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index e602399232..c285f30c0a 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -401,9 +401,10 @@ class QemuRunner:
  cmdline = re_control_char.sub(' ', cmdline)
  try:
  if self.use_slirp:
-tcp_ports = cmdline.split("hostfwd=tcp::")[1]
+tcp_ports = cmdline.split("hostfwd=tcp:")[1]
+ip, tcp_ports = tcp_ports.split(":")[:2]
  host_port = tcp_ports[:tcp_ports.find('-')]
-self.ip = "localhost:%s" % host_port
+self.ip = "%s:%s" % (ip, host_port)


Now there is the question of what we should print in the event hostfwd 
is set to tcp::hostport-:port ?


Should we have it return localhost:hostport even though it is not 
entirely true since any interface of the host can be used (provided the 
firewall is properly set up) but at least it shows one way to reach the 
QEMU target and it also keeps the current behavior? or should we keep it 
like this in which case it prints :hostport only?


A ternary ip if ip else "localhost" would be enough.

I'm picking nits now, so up to you/the maintainer on this :)

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173477): 
https://lists.openembedded.org/g/openembedded-core/message/173477
Mute This Topic: https://lists.openembedded.org/mt/95114891/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] runqemu: limit slirp host port forwarding to localhost 127.0.0.1

2022-11-17 Thread Quentin Schulz via lists.openembedded.org


Hi Mikko,

On 11/14/22 16:50, Mikko Rapeli wrote:

With default slirp port forwarding config qemu listens on TCP ports
 and 2323 on all IP addresses available on the build host. Most
use cases with runqemu only need it for localhost and it is not
safe to run qemu images with root login without password enabled
and listening on all available, possibly Internet reachable network
interfaces. Limit qemu port forwarding to localhost 127.0.0.1 IP
address. Now qemu machine SSH and telnet ports are only
reachable from the build host machine, not full Internet.

If qemu machine needs to be reachable from network, then it can
be enabled via local.conf or machine config variable QB_SLIRP_OPT:

QB_SLIRP_OPT = "-netdev user,id=net0,hostfwd=tcp::-:22"

Signed-off-by: Mikko Rapeli 
---
  scripts/runqemu | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index a6ea578564..7bd9465593 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1071,7 +1071,7 @@ class BaseConfig(object):
  logger.info("Network configuration:%s", netconf)
  self.kernel_cmdline_script += netconf
  # Port mapping
-hostfwd = ",hostfwd=tcp::-:22,hostfwd=tcp::2323-:23"
+hostfwd = 
",hostfwd=tcp:127.0.0.1:-:22,hostfwd=tcp:127.0.0.1:2323-:23"


With the additional knowledge we gathered in the last patches, I believe 
it would be a good thing to say a few words/update the documentation.


See 
https://lore.kernel.org/yocto-docs/fedb4cc0-44d6-d7d8-bc26-c8de5bee0...@theobroma-systems.com/T/#t 
for a patch I believe might make it to master soon? I think we should 
say what the default value entails (even if this patch isnt' taken) and 
maybe point/refer to the QEMU documentation for the meaning of options 
in QB_SLIRP_OPT. I believe some/all of options listed 
https://www.qemu.org/docs/master/system/invocation.html are possible?


What do you think?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173422): 
https://lists.openembedded.org/g/openembedded-core/message/173422
Mute This Topic: https://lists.openembedded.org/mt/95021917/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 1/2] qemurunner.py: support setting slirp host IP address

2022-11-17 Thread Quentin Schulz via lists.openembedded.org


Hi Mikko,

On 11/14/22 16:50, Mikko Rapeli wrote:

By default host side IP address is not set and qemu listens
on all IP addresses on the host machine which is not a good
idea when images have root login enabled without password.
It make sense to listen only on localhost IP address 127.0.0.1 using
config change like:

QB_SLIRP_OPT = "-netdev user,id=net0,hostfwd=tcp:127.0.0.1:-:22"

This config works for qemu itself, but breaks runqemu which tries to
parse the host side port number from qemu process command line arguments.
So change the runqemu side hostfwd parsing for port number to ignore
the host IP address field.

Reviewed-by: Quentin Schulz 
Signed-off-by: Mikko Rapeli 
---
  meta/lib/oeqa/utils/qemurunner.py | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

v2: improved commit message

v1: 
https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/topic/95016024*173234__;Iw!!OOPJP91ZZw!lmurd9F5r43EHopuJkrpTJZMlC93fI8sXSNgnxmfVSRyTvP6unwa8Wn4-wxgjS9UM6EQUnGK5X8gzyVSyfm3WExF4pLQQuHl0L_BlQ$

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index e602399232..f175f8a1de 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -401,7 +401,8 @@ class QemuRunner:
  cmdline = re_control_char.sub(' ', cmdline)
  try:
  if self.use_slirp:
-tcp_ports = cmdline.split("hostfwd=tcp::")[1]
+tcp_ports = cmdline.split("hostfwd=tcp:")[1]
+tcp_ports = tcp_ports.split(":")[1]
  host_port = tcp_ports[:tcp_ports.find('-')]
  self.ip = "localhost:%s" % host_port


Wondering if we shouldn't also update the self.ip here to display the 
actual ip to use? I assume we just need to extract it from the first 
tcp_ports. I think it should just be tcp_ports.split(":")[0] ? and just 
need to check if it's empty/None in which case we set it to localhost?


What do you think?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173420): 
https://lists.openembedded.org/g/openembedded-core/message/173420
Mute This Topic: https://lists.openembedded.org/mt/95021915/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] qemurunner.py: support setting slirp host ip address

2022-11-14 Thread Quentin Schulz via lists.openembedded.org


Hi Mikko,

On 11/14/22 11:59, Mikko Rapeli wrote:

Hi,

On Mon, Nov 14, 2022 at 11:31:11AM +0100, Quentin Schulz wrote:

Hi Mikko,

On 11/14/22 11:19, Mikko Rapeli wrote:

By default host side IP address is not set and qemu listens
on all IP addresses on the host machine which is not a good
idea when images have root login enabled without password.
It make sense to listen only on localhost IP address 127.0.0.1 using
config:

QB_SLIRP_OPT = "-netdev user,id=net0,hostfwd=tcp:127.0.0.1:-:22"

Support detecting port number from this too.

Signed-off-by: Mikko Rapeli 
---
   meta/lib/oeqa/utils/qemurunner.py | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index e602399232..f175f8a1de 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -401,7 +401,8 @@ class QemuRunner:
   cmdline = re_control_char.sub(' ', cmdline)
   try:
   if self.use_slirp:
-tcp_ports = cmdline.split("hostfwd=tcp::")[1]
+tcp_ports = cmdline.split("hostfwd=tcp:")[1]
+tcp_ports = tcp_ports.split(":")[1]
   host_port = tcp_ports[:tcp_ports.find('-')]
   self.ip = "localhost:%s" % host_port


But localhost is enforced here?


Is it really? Where?



I clearly misunderstood the code only glancing at it. QB_SLIRP_OPT will 
be passed to QEMU before that, and then we read the kernel cli from QEMU 
PID to print something nice.


Therefore, the printed message will always mention localhost: 
as being the "Target IP" (see a few lines below in the code), which, if 
I'm not mistaken, might be incorrect depending on what you pick in the 
hostaddr field, but that's another topic.



With default "-netdev user,id=net0,hostfwd=tcp::-:22" I am able
to login using all local IP addresses:

$ nc 192.168.1.103 
SSH-2.0-OpenSSH_8.9
^C

$ nc -v -v -v 127.0.0.1 
Connection to 127.0.0.1  port [tcp/*] succeeded!
SSH-2.0-OpenSSH_8.9
^C

The open port  show on the build machine with:

$ lsof -i|grep qemu | grep 
qemu-syst  170445 builder   12u  IPv4 45057952  0t0  TCP *: (LISTEN)

By using "hostfwd=tcp:127.0.0.1:-:22" this reduces to the more safe:

$ lsof -i|grep qemu
qemu-syst  127592 builder   12u  IPv4 44993375  0t0  TCP localhost: 
(LISTEN)

I don't dare to make that the new default so just enabling
runqemu to work when user configures the host IP address like this.



Maybe we could make it the default if it's more secure but that would be 
a different commit anyways :)



This patch basically allows to pass
hostfwd=tcp:127.0.0.1:-:22
instead of
hostfwd=tcp::-:22
but with the exact same result (which is, localhost: will be used?)


Nope, now the other non-local IP addresses are not open for the port
 on the machine running qemu. The localhost: works in both
cases.


Also, this could be migrated to using re instead of doing manual lookups.


Yes, but re is more resource consuming.


I'm not sure the commit log matches what the commit is actually doing?


How could I improve that? If I manually start the qemu machine with
hostfwd=tcp:127.0.0.1:-:22 the machine works but with runqemu it
fails due to a confusing error about detecting IP address. I could add that
if it helps. With this patch runqemu doesn't care how the IP address
is configured when looking for the port number, and also doesn't fail
when it's set.



Yes that was exactly what was missing for me to understand this patch. I 
thought the code section I was looking at was the one handling your 
parameters, and there you can see that the hostaddr isn't actually being 
read, directly assumed to be localhost, hence my confusion.


The issue is not that it's not possible, since QEMU actually supports 
that, like you rightfully mentioned. It's that our code parsing this 
QEMU kernel cli argument fails.


I think the important part here is something like:
"""
hostfwd QEMU option in QB_SLIRP_OPT currently only supports *not* 
passing any hostaddr, otherwise failing to parse the option and thus 
fails runqemu.


While the default is to not pass any hostaddr, binding all interfaces on 
the host, it is not secure so it should be allowed to pass a hostaddr in 
hostfwd via QB_SLIRP_OPT QEMU option. e.g. QB_SLIRP_OPT = "-netdev 
user,id=net0,hostfwd=tcp:127.0.0.1:-:22" to bind to the loopback 
interface only.

"""

but this is just how *I* would have written it and I guess there will 
always be someone for whom a git commit log won't make much sense on 
first read.


I realize this is because I didn't take the time to understand the code 
properly, sorry to have

Re: [OE-core] [PATCH] qemurunner.py: support setting slirp host ip address

2022-11-14 Thread Quentin Schulz via lists.openembedded.org


Hi Mikko,

On 11/14/22 11:19, Mikko Rapeli wrote:

By default host side IP address is not set and qemu listens
on all IP addresses on the host machine which is not a good
idea when images have root login enabled without password.
It make sense to listen only on localhost IP address 127.0.0.1 using
config:

QB_SLIRP_OPT = "-netdev user,id=net0,hostfwd=tcp:127.0.0.1:-:22"

Support detecting port number from this too.

Signed-off-by: Mikko Rapeli 
---
  meta/lib/oeqa/utils/qemurunner.py | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index e602399232..f175f8a1de 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -401,7 +401,8 @@ class QemuRunner:
  cmdline = re_control_char.sub(' ', cmdline)
  try:
  if self.use_slirp:
-tcp_ports = cmdline.split("hostfwd=tcp::")[1]
+tcp_ports = cmdline.split("hostfwd=tcp:")[1]
+tcp_ports = tcp_ports.split(":")[1]
  host_port = tcp_ports[:tcp_ports.find('-')]
  self.ip = "localhost:%s" % host_port


But localhost is enforced here?

This patch basically allows to pass
hostfwd=tcp:127.0.0.1:-:22
instead of
hostfwd=tcp::-:22
but with the exact same result (which is, localhost: will be used?)

Also, this could be migrated to using re instead of doing manual lookups.

I'm not sure the commit log matches what the commit is actually doing?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173235): 
https://lists.openembedded.org/g/openembedded-core/message/173235
Mute This Topic: https://lists.openembedded.org/mt/95016024/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] How to use linux-firmware to install single firmware package? #kirkstone

2022-11-07 Thread Quentin Schulz via lists.openembedded.org


Hi,

On 11/4/22 19:44, Livius wrote:

What should i check in buildhistory? In my buildhistory folder linux-firmware 
folder contains all packages as a subfolders, like was in my 
tmp/deploy/rpm/noarch. Following content is in my 
linux-firmware/linux-firmware-imx-sdma-imx7d/latest text file.

PE = 1
PV = 20220913
PR = r0
RPROVIDES =
RDEPENDS = linux-firmware-imx-sdma-license
RRECOMMENDS =
PKGSIZE = 2862
FILES = /lib/firmware/imx/sdma/sdma-imx7d.bin
FILELIST = /lib/firmware/imx/sdma/sdma-imx7d.bin



The installed-packages.txt would probably list all linux-firmware 
packages I assume?


Could you also check the 
linux-firmware/linux-firmware-imx-sdma-license/latest text file and tell 
us what it contains? Because the content of 
linux-firmware/linux-firmware-imx-sdma-imx7d/latest seems to be fine.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172840): 
https://lists.openembedded.org/g/openembedded-core/message/172840
Mute This Topic: https://lists.openembedded.org/mt/94795411/21656
Mute 
#kirkstone:https://lists.openembedded.org/g/openembedded-core/mutehashtag/kirkstone
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][PATCH v2 2/2] image_types: Set .7z extension for 7-Zip conversion command

2022-11-07 Thread Quentin Schulz via lists.openembedded.org


Hi Benjamin,

On 11/7/22 13:37, Livius wrote:

From: Benjamin Szőke 

Signed-off-by: Benjamin Szőke 
---
  meta/classes-recipe/image_types.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/image_types.bbclass 
b/meta/classes-recipe/image_types.bbclass
index f70c71b9d4..ae00728a74 100644
--- a/meta/classes-recipe/image_types.bbclass
+++ b/meta/classes-recipe/image_types.bbclass
@@ -61,7 +61,7 @@ ZIP_COMPRESSION_LEVEL ?= "-9"
  
  7ZIP_COMPRESSION_LEVEL ?= "9"

  7ZIP_COMPRESSION_METHOD ?= "BZip2"
-7ZIP_EXTENSION ?= "zip"
+7ZIP_EXTENSION ?= "7z"
  


We're almost there :)

There's no need for a second commit since the issue is introduced in 
your first commit. Instead, you should squash them together so the issue 
does not exist in the first place.


You can do so by doing:
git reset --soft HEAD^
git commit --amend --no-edit

This can also be done via git rebase:
git rebase --interactive HEAD^^

then modify "pick" for "squash" for the last commit, save and exit. 
You'll be prompted for commit log modification while rebasing, save and 
exit after your changes have been made (if any necessary).


You should only have one commit left, the first one, with the 
7ZIP_EXTENSION fix applied.


Don't forget to send as a v3.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172839): 
https://lists.openembedded.org/g/openembedded-core/message/172839
Mute This Topic: https://lists.openembedded.org/mt/94864715/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][PATCH v2] image_types: Add 7-Zip support in conversion types and commands

2022-11-07 Thread Quentin Schulz via lists.openembedded.org


Hi Benjamin,

On 11/7/22 12:33, Livius wrote:

Good point for this zip extension conflict, you are right. If somebody is a overzealous 
developer can use IMAGE_TYPES = "wic.zip wic.7zip" then sure there will be an 
extension conflict after the compression in deploy time. This escaped my notice this 
because this use case is not so realistic (normaly enough only one zip pack for wic 
image) but can be a real issue. 100% sure 7ZIP_EXTENSION ?= 7z can be better for default 
value, then it can be overridable to .zip extension in users's local.conf if needed (for 
example for me it .zip will be better).

Do i need to resend again the patch in a new thread/topic if i like to solve 
the missing signed-off issue?



Yes, please make it a v2 also (git format-patch -v 2 when creating the 
patch before sending it with git-send-email).


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172836): 
https://lists.openembedded.org/g/openembedded-core/message/172836
Mute This Topic: https://lists.openembedded.org/mt/94843929/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][PATCH v2] image_types: Add 7-Zip support in conversion types and commands

2022-11-07 Thread Quentin Schulz via lists.openembedded.org


Hi Benjamin,

On 11/6/22 14:31, Livius wrote:

From: Benjamin Szőke 

Add 7-Zip support in conversion types and commands. Default arguments of 7-Zip 
are compression level: 9, method: BZip2, extension: zip. All these are 
overridable from local.con for any other use case in user side. First goal was 
to make an alternative zip conversion which can operate faster in multi-thread 
systems (on many CPU core), normal zip is just a single thread compression. 
7-Zip can do a zip compression in multi-thread processing, so it is fine to use 
and speed up it.


Your signed-off-by is missing here, it is usually added when you run
git commit --signoff
git commit -s

You can add your signature to your patch locally with
git commit --signoff --amend --no-edit


---
  meta/classes-recipe/image_types.bbclass | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/image_types.bbclass 
b/meta/classes-recipe/image_types.bbclass
index 764e6a5574..f70c71b9d4 100644
--- a/meta/classes-recipe/image_types.bbclass
+++ b/meta/classes-recipe/image_types.bbclass
@@ -59,6 +59,10 @@ XZ_INTEGRITY_CHECK ?= "crc32"
  
  ZIP_COMPRESSION_LEVEL ?= "-9"
  
+7ZIP_COMPRESSION_LEVEL ?= "9"

+7ZIP_COMPRESSION_METHOD ?= "BZip2"
+7ZIP_EXTENSION ?= "zip"


Wouldn't this conflict with the output of the zip compression? 
Basically, if I have 7zip and zip for an archive, they will overwrite 
each other un-deterministically. Maybe the default .7z extension is better?



+
  ZSTD_COMPRESSION_LEVEL ?= "-3"
  
  JFFS2_SUM_EXTRA_ARGS ?= ""

@@ -304,7 +308,7 @@ IMAGE_TYPES:append:x86-64 = " hddimg iso"
  # CONVERSION_CMD/DEPENDS.
  COMPRESSIONTYPES ?= ""
  
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 gzsync zsync ${COMPRESSIONTYPES}"

+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip 7zip zst sum md5sum sha1sum sha224sum 
sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 gzsync zsync 
${COMPRESSIONTYPES}"
  CONVERSION_CMD:lzma = "lzma -k -f -7 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
  CONVERSION_CMD:gz = "gzip -f -9 -n -c --rsyncable 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
  CONVERSION_CMD:bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -312,6 +316,7 @@ CONVERSION_CMD:xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} 
${XZ_DEFAULTS} --check=
  CONVERSION_CMD:lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
  CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
  CONVERSION_CMD:zip = "zip ${ZIP_COMPRESSION_LEVEL} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD:7zip = "7za a -mx=${7ZIP_COMPRESSION_LEVEL} 
-mm=${7ZIP_COMPRESSION_METHOD} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.${7ZIP_EXTENSION} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
  CONVERSION_CMD:zst = "zstd -f -k -T0 -c ${ZSTD_COMPRESSION_LEVEL} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zst"
  CONVERSION_CMD:sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
  CONVERSION_CMD:md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
@@ -337,6 +342,7 @@ CONVERSION_DEPENDS_xz = "xz-native"
  CONVERSION_DEPENDS_lz4 = "lz4-native"
  CONVERSION_DEPENDS_lzo = "lzop-native"
  CONVERSION_DEPENDS_zip = "zip-native"
+CONVERSION_DEPENDS_7zip = "p7zip-native"


This tool is in meta-openembedded/meta-oe and not openembedded-core, 
should we actually move the recipe into oe-core?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172828): 
https://lists.openembedded.org/g/openembedded-core/message/172828
Mute This Topic: https://lists.openembedded.org/mt/94843929/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] How to use linux-firmware to install single firmware package? #kirkstone

2022-11-04 Thread Quentin Schulz via lists.openembedded.org


Hi Livius,

On 11/4/22 13:42, Livius wrote:

In my tmp/deploy/rpm/noarch folder i can see many-many other firmware .rpm 
files like linux-firmware-bcm43xx, linux-firmware-nvidia-tegra and so on, these 
were not planed to be installed. It seems to me, the full linux-firmware 
package was deployed somehow.


Yes, that's normal. When a recipe is built, all its packages are created 
and put into that directory. It's not because the package is created 
that it's installed in the final rootfs.


> I think i am using poky now, this is my path for linux-firmware: 
PROJECT/sources/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20220913.bb


So, my poky come from git.yoctoproject.org ( 
https://urldefense.com/v3/__https://git.yoctoproject.org/poky/log/?h=kirkstone__;!!OOPJP91ZZw!iE35Nh5nRc3nFT6cCWMcIbXJsRTSva3-k0ELYN7qrnPobvaTVmufMXyu6PTsr_2phXtEqT4WAHAyDmU3tfm0A0o7KOuVycOZZMX2Wg$
  ) , i use latest kirkstone commit ( 
https://urldefense.com/v3/__https://git.yoctoproject.org/poky/commit/?h=kirkstone&id=2e79b199114b25d81bfaa029ccfb17676946d20d__;!!OOPJP91ZZw!iE35Nh5nRc3nFT6cCWMcIbXJsRTSva3-k0ELYN7qrnPobvaTVmufMXyu6PTsr_2phXtEqT4WAHAyDmU3tfm0A0o7KOuVycMxLdUTqg$
  ).



And there's no bbappend for linux-firmware anywhere?
Run:
bitbake-layers show-appends linux-firmware


In pn-buildlist and task-depends.dot i can see only linux-firmware, i have no 
any listed single package like should be linux-firmware-imx-sdma-imx7d.



Mmm indeed, less helpful than I had imagined. I think you can figure out 
which packages are installed by adding INHERIT += "buildhistory". It 
should create an installed-packages.txt file after a build.


Cheers,
Quentin

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

Re: [OE-core] How to use linux-firmware to install single firmware package? #kirkstone

2022-11-04 Thread Quentin Schulz via lists.openembedded.org


Hi Livius,

On 11/4/22 00:07, Livius wrote:

Hi,

I would like to install linux-firmware-ath10k and linux-firmware-imx-sdma-imx7d 
firmware package to my image recipe in kirkstone release but when i append them 
to IMAGE_INSTALL somewhy each pack from linux-firmware recipe installs itself. 
It is extramly large in size about 500 MB, it is totaly not accaptable for me, 
it is too large.

I am using the following syntax to install them:

IMAGE_INSTALL:append = " linux-firmware-imx-sdma-imx7d linux-firmware-ath10k"



This seems correct to me.


If i remove them, there are no any linux-firmware in my deployed image, it 
means somehow they trigger to install the full linux-firmware pack, how can i 
use it to install only some single linux-firmware?



There might be an issue somewhere, we need to debug this. Can you 
reproduce this with only poky?


Which version of oe-core/yocto are you using?

Can you run bitbake -g ? Check that only your 
linux-firmwasre packages are installed in the image. You can also check 
that the linux-firmware packages don't contain more files than they 
should (either look into the .rpm/.deb/.ipk packages in tmp/deploy or in 
WORKDIR/packages/ of linux-firmware). Also look at the .dot files with 
your favorite text editor and check what does linux-firmware-ath10k 
bring in as a dependency, maybe there's a bad dependency somewhere that 
brings some other packages in.


Cheers,
Quentin

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

1 2 3 >

1 - 100 of 275 matches

Mail list logo