[OE-core][PATCH] perf: Fix QA error due to most recent kernel
A change in the latest kernel (next), triggers a QA error due to a
missing RDEPENDS on perl for perf-tests.
ERROR: QA Issue:
/usr/libexec/perf-core/tests/shell/common/check_no_patterns_found.pl contained
in package perf-tests requires /usr/bin/perl, but no providers found in
RDEPENDS:perf-tests? [file-rdeps]
Signed-off-by: Ryan Eatmon
---
meta/recipes-kernel/perf/perf.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 4f26813de0..ae7e24aa0c 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -382,7 +382,7 @@ RDEPENDS:${PN} += "elfutils bash"
RDEPENDS:${PN}-archive =+ "bash"
RDEPENDS:${PN}-python =+ "bash python3 python3-modules
${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '', d)}"
RDEPENDS:${PN}-perl =+ "bash perl perl-modules"
-RDEPENDS:${PN}-tests =+ "python3 bash"
+RDEPENDS:${PN}-tests =+ "python3 bash perl"
RSUGGESTS:${PN} += "${PN}-archive ${PN}-tests \
${@bb.utils.contains('PACKAGECONFIG', 'perl',
'${PN}-perl', '', d)} \
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196317):
https://lists.openembedded.org/g/openembedded-core/message/196317
Mute This Topic: https://lists.openembedded.org/mt/104616123/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 3/3] kernel: make LOCALVERSION consistent between recipes
On 2/22/2024 4:46 PM, Ryan Eatmon via lists.openembedded.org wrote: On 2/22/2024 3:56 PM, Bruce Ashfield wrote: On Thu, Feb 22, 2024 at 4:51 PM Ryan Eatmon via lists.openembedded.org wrote: On 2/22/2024 4:35 AM, Andreas Helbech Kleist wrote: From: Bruce Ashfield The initial fix for localversion setting in 6.3+ broke older recipes and also broke recipes setting localversion in a kernel recipe, as make-mod-scripts (and other locations) can trigger a regeneration of files and don't have access to the variable. Moving the setting of this variable to the global namespace doesn't make sense, so we follow the example of the kernel-abiversion and save a kernel-localversion to the build artifacts. Recipes that may regenerate scripts/dynamic files, must depend on the do_shared_workedir of the kernel and use the helper function to read the file storing the localversion. Signed-off-by: Bruce Ashfield Signed-off-by: Alexandre Belloni cherry-picked from master b378eec156998eea55ba61e59103cb34fab0d07c Signed-off-by: Andreas Helbech Kleist I'm not sure what is going on with our meta-ti testing. This set of changes causes the same issue we were seeing before. Plus, now that I'm looking into it deeper, I'm seeing a breakage in master related to these same patches on there. Not sure why the changes were not caught in our testing on master back when the patches were accepted there... Clearly I need some better checks on the images as part of our QC process... I need to figure out how to fix the issue on master and see if the same change can be applied to these patches on kirkstone. I'll try and get all this done as quickly as I can. Please make sure to copy me directly, both as the maintainer of the parts of core in question and the author of the patches. We've had no reports of issues since any of these went in, and they aren't exactly a recent change. Which obviously means there's potentially something different in the environment or the kernel recipes. If you get a set of reproducing steps with linux-yocto and core, I can lend a hand with any fixes. Bruce This may not be an issue with these patches per se. It may be an issue with our kernel recipes in meta-ti. But since kirkstone is our primary release vector right now, it is breaking us to accept these patches onto kirkstone. I fully acknowledge that this might solely a TI issue. And now that we are aware of the issue we are going to work very very hard to find a solution as quickly as we can. As soon as we have an understanding of how to recreate the issue outside of our recipe we will definitely share with this thread. Ok. My initial thinking that there was a problem was incorrect. I looked at the file system and found our value for KERNEL_LOCALVERSION was included in the modules directory name twice. /lib/modules/6.1.69-gcb84067eaf83-gcb84067eaf83 That was the symptom that caused the issue with our request for the revert last week. However, with this full patch series the problem caused by the double entry from the last series is not a problem because the double entry is everywhere in the kernel, so it all works together. It's just goofy. So with that. This bigger series can be accepted into Kirkstone. Acked-by: Ryan Eatmon Now for the second issue, and maybe this was known that it would occur, if we set KERNEL_LOCALVERSION it is placed into both the .scmversion file AND the LOCALVERSION variable. The setlocalversion script in the 6.1 kernel we are currently pointing at for our production includes both in the version string, which causes the entire kernel to be named named with a redundant string. /lib/modules/6.1.69-gcb84067eaf83-gcb84067eaf83 I guess we can live with this. It is unnecessary, but not incorrect. It is cleaned up with the next LTS kernel 6.6. This is just the hazard of only having a single class to handle kernel issues that needs to span multiple kernel versions that are changing things up in big ways. The only way I can see to fix it would be to create some new control variables that recipes can set to control the above behavior and then set defaults for them. But we can look into patches to add that if needed. Apologies for taking so much time in testing this series. We are just about to make a release and things that break the kernel cause us a lot anxiety. --- meta/classes/kernel-arch.bbclass | 8 meta/classes/kernel.bbclass | 14 ++ meta/classes/kernelsrc.bbclass | 1 + meta/classes/linux-kernel-base.bbclass | 11 +++ meta/classes/module-base.bbclass | 1 + .../make-mod-scripts/make-mod-scripts_1.0.bb | 3 +++ 6 files changed, 30 insertions(+), 8 deletions(-) diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass index 0a79dea0af..62c8211621 100644 --- a/meta/classes
Re: [OE-core] [kirkstone][PATCH 3/3] kernel: make LOCALVERSION consistent between recipes
On 2/22/2024 3:56 PM, Bruce Ashfield wrote:
On Thu, Feb 22, 2024 at 4:51 PM Ryan Eatmon via lists.openembedded.org
wrote:
On 2/22/2024 4:35 AM, Andreas Helbech Kleist wrote:
From: Bruce Ashfield
The initial fix for localversion setting in 6.3+ broke older
recipes and also broke recipes setting localversion in a kernel
recipe, as make-mod-scripts (and other locations) can trigger
a regeneration of files and don't have access to the variable.
Moving the setting of this variable to the global namespace
doesn't make sense, so we follow the example of the kernel-abiversion
and save a kernel-localversion to the build artifacts.
Recipes that may regenerate scripts/dynamic files, must
depend on the do_shared_workedir of the kernel and use the helper
function to read the file storing the localversion.
Signed-off-by: Bruce Ashfield
Signed-off-by: Alexandre Belloni
cherry-picked from master b378eec156998eea55ba61e59103cb34fab0d07c
Signed-off-by: Andreas Helbech Kleist
I'm not sure what is going on with our meta-ti testing. This set of
changes causes the same issue we were seeing before. Plus, now that I'm
looking into it deeper, I'm seeing a breakage in master related to these
same patches on there. Not sure why the changes were not caught in our
testing on master back when the patches were accepted there... Clearly
I need some better checks on the images as part of our QC process...
I need to figure out how to fix the issue on master and see if the same
change can be applied to these patches on kirkstone. I'll try and get
all this done as quickly as I can.
Please make sure to copy me directly, both as the maintainer of the
parts of core in question and the author of the patches.
We've had no reports of issues since any of these went in, and they
aren't exactly a recent change. Which obviously means there's
potentially something different in the environment or the kernel
recipes.
If you get a set of reproducing steps with linux-yocto and core, I
can lend a hand with any fixes.
Bruce
This may not be an issue with these patches per se. It may be an issue
with our kernel recipes in meta-ti. But since kirkstone is our primary
release vector right now, it is breaking us to accept these patches onto
kirkstone. I fully acknowledge that this might solely a TI issue. And
now that we are aware of the issue we are going to work very very hard
to find a solution as quickly as we can.
As soon as we have an understanding of how to recreate the issue outside
of our recipe we will definitely share with this thread.
---
meta/classes/kernel-arch.bbclass | 8
meta/classes/kernel.bbclass| 14 ++
meta/classes/kernelsrc.bbclass | 1 +
meta/classes/linux-kernel-base.bbclass | 11 +++
meta/classes/module-base.bbclass | 1 +
.../make-mod-scripts/make-mod-scripts_1.0.bb | 3 +++
6 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 0a79dea0af..62c8211621 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -65,11 +65,3 @@ KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc
${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd ${DE
KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
TOOLCHAIN ?= "gcc"
-
-# 6.3+ requires the variable LOCALVERSION to be set to not get a "+" in
-# the local version. Having it empty means nothing will be added, and any
-# value will be appended to the local kernel version. This replaces the
-# use of .scmversion file for setting a localversion without using
-# the CONFIG_LOCALVERSION option.
-KERNEL_LOCALVERSION ??= ""
-export LOCALVERSION ?= "${KERNEL_LOCALVERSION}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 940f1a3cf4..96e41b5192 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -541,6 +541,7 @@ do_shared_workdir () {
#
echo "${KERNEL_VERSION}" > $kerneldir/${KERNEL_PACKAGE_NAME}-abiversion
+ echo "${KERNEL_LOCALVERSION}" >
$kerneldir/${KERNEL_PACKAGE_NAME}-localversion
# Copy files required for module builds
cp System.map $kerneldir/System.map-${KERNEL_VERSION}
@@ -630,6 +631,19 @@ python check_oldest_kernel() {
check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
do_configure[prefuncs] += "check_oldest_kernel"
+KERNEL_LOCALVERSION ??= ""
+
+# 6.3+ requires the variable LOCALVERSION to be set to not get a "+" in
+# the local version. Having it empty means nothing will be added, and any
+# value will be appended to the local kernel version. This replaces the
+# use of .scmversion file
Re: [OE-core] [kirkstone][PATCH 3/3] kernel: make LOCALVERSION consistent between recipes
On 2/22/2024 4:35 AM, Andreas Helbech Kleist wrote:
From: Bruce Ashfield
The initial fix for localversion setting in 6.3+ broke older
recipes and also broke recipes setting localversion in a kernel
recipe, as make-mod-scripts (and other locations) can trigger
a regeneration of files and don't have access to the variable.
Moving the setting of this variable to the global namespace
doesn't make sense, so we follow the example of the kernel-abiversion
and save a kernel-localversion to the build artifacts.
Recipes that may regenerate scripts/dynamic files, must
depend on the do_shared_workedir of the kernel and use the helper
function to read the file storing the localversion.
Signed-off-by: Bruce Ashfield
Signed-off-by: Alexandre Belloni
cherry-picked from master b378eec156998eea55ba61e59103cb34fab0d07c
Signed-off-by: Andreas Helbech Kleist
I'm not sure what is going on with our meta-ti testing. This set of
changes causes the same issue we were seeing before. Plus, now that I'm
looking into it deeper, I'm seeing a breakage in master related to these
same patches on there. Not sure why the changes were not caught in our
testing on master back when the patches were accepted there... Clearly
I need some better checks on the images as part of our QC process...
I need to figure out how to fix the issue on master and see if the same
change can be applied to these patches on kirkstone. I'll try and get
all this done as quickly as I can.
---
meta/classes/kernel-arch.bbclass | 8
meta/classes/kernel.bbclass| 14 ++
meta/classes/kernelsrc.bbclass | 1 +
meta/classes/linux-kernel-base.bbclass | 11 +++
meta/classes/module-base.bbclass | 1 +
.../make-mod-scripts/make-mod-scripts_1.0.bb | 3 +++
6 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 0a79dea0af..62c8211621 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -65,11 +65,3 @@ KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc
${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd ${DE
KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
TOOLCHAIN ?= "gcc"
-
-# 6.3+ requires the variable LOCALVERSION to be set to not get a "+" in
-# the local version. Having it empty means nothing will be added, and any
-# value will be appended to the local kernel version. This replaces the
-# use of .scmversion file for setting a localversion without using
-# the CONFIG_LOCALVERSION option.
-KERNEL_LOCALVERSION ??= ""
-export LOCALVERSION ?= "${KERNEL_LOCALVERSION}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 940f1a3cf4..96e41b5192 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -541,6 +541,7 @@ do_shared_workdir () {
#
echo "${KERNEL_VERSION}" > $kerneldir/${KERNEL_PACKAGE_NAME}-abiversion
+ echo "${KERNEL_LOCALVERSION}" >
$kerneldir/${KERNEL_PACKAGE_NAME}-localversion
# Copy files required for module builds
cp System.map $kerneldir/System.map-${KERNEL_VERSION}
@@ -630,6 +631,19 @@ python check_oldest_kernel() {
check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
do_configure[prefuncs] += "check_oldest_kernel"
+KERNEL_LOCALVERSION ??= ""
+
+# 6.3+ requires the variable LOCALVERSION to be set to not get a "+" in
+# the local version. Having it empty means nothing will be added, and any
+# value will be appended to the local kernel version. This replaces the
+# use of .scmversion file for setting a localversion without using
+# the CONFIG_LOCALVERSION option.
+#
+# Note: This class saves the value of localversion to a file
+# so other recipes like make-mod-scripts can restore it via the
+# helper function get_kernellocalversion_file
+export LOCALVERSION="${KERNEL_LOCALVERSION}"
+
kernel_do_configure() {
# fixes extra + in /lib/modules/2.6.37+
# $ scripts/setlocalversion . => +
diff --git a/meta/classes/kernelsrc.bbclass b/meta/classes/kernelsrc.bbclass
index a951ba3325..a79bf18b09 100644
--- a/meta/classes/kernelsrc.bbclass
+++ b/meta/classes/kernelsrc.bbclass
@@ -5,6 +5,7 @@ do_patch[depends] += "virtual/kernel:do_shared_workdir"
do_patch[noexec] = "1"
do_package[depends] += "virtual/kernel:do_populate_sysroot"
KERNEL_VERSION = "${@get_kernelversion_file("${STAGING_KERNEL_BUILDDIR}")}"
+LOCAL_VERSION = "${@get_kernellocalversion_file("${STAGING_KERNEL_BUILDDIR}")}"
inherit linux-kernel-base
diff --git a/meta/classes/linux-kernel-base.bbclass b/meta/classes/linux-kernel-base.bbclass
index 73a6fe36d9..0e2a4a4abe 100644
--- a/meta/classes/linux-kernel-base.bbclass
+++ b/meta/classes/linux-kernel-base.bbclass
@@ -33,6 +33,17 @@ def get_kernelversion_file(p):
except IOError:
Re: [OE-core][kirkstone 7/8] kernel: fix localversion in v6.3+
On 2/22/2024 4:39 AM, Andreas Helbech Kleist wrote: On Wed, 2024-02-21 at 08:40 -0600, Ryan Eatmon wrote: On 2/16/2024 7:51 AM, Andreas Helbech Kleist wrote: On Fri, 2024-02-16 at 09:11 +0100, Andreas Helbech Kleist wrote: On Thu, 2024-02-15 at 19:45 -0600, Ryan Eatmon via lists.openembedded.org wrote: On 2/15/2024 7:43 PM, Steve Sakoman wrote: On Thu, Feb 15, 2024 at 3:20 PM Ryan Eatmon wrote: With this patch in place we are seeing a breakage on our kernel builds. This patch was cherry picked from master, but the next patch on this file in master removes the LOCALVERSION setting... https://git.openembedded.org/openembedded-core/commit/meta/classes-recipe/kernel-arch.bbclass?h=master-next=b378eec156998eea55ba61e59103cb34fab0d07c There is a disconnect here. Why did we change kirkstone, a stable LTS version with a partial patch series based on master? The original kirkstone backport request for this patch was sent to the list for review on February 9. There were no comments or objections, so I added it to the patch test queue. No issues were encountered on the autobuilder, so I sent this patch (along with the rest of the patch queue) to the list for a second review opportunity on February 12. Once again there were no comments or objections, so it was merged today February 15. I follow this process because I'm not smart enough, nor do I have time enough to thoroughly research all implications of every patch. I rely on autobuilder testing and community review to minimize breakage. This normally works quite well, but this time it didn't. I'll revert this patch and if someone would like to resubmit a proper series to deal with the issue it is trying to fix I will consider it and run it through the same process. I can appreciate that. My comment was more for the person who sent the patch in the first place. You are doing a great job. I will try and pay attention for a replacement patch coming in and review as well. I'm sorry about that. I need to use a 6.6 kernel on kirkstone, and this patch fixed my usecase. It looked like a simple bugfix, and I was not aware that there was a later fix for this change. Is there any way I can reproduce the error you saw Ryan? And would it make sense to add an automated test for this usecase? I'll test my usecase with both patches backported and re-submit. I've now looked into it and can make it work in my setup by backporting these three commits from master: kernel.bbclass: introduce KERNEL_LOCALVERSION https://git.openembedded.org/openembedded-core/commit/?h=master-next=229435a52f36ddec5f85fb6d5ccd42044b688397 kernel: fix localversion in v6.3+ https://git.openembedded.org/openembedded-core/commit/?h=master-next=765b13b7305c8d2f222cfc66d77c02e6a088c691 kernel: make LOCALVERSION consistent between recipes https://git.openembedded.org/openembedded-core/commit/?h=master-next=b378eec156998eea55ba61e59103cb34fab0d07c The cherry-pick's apply cleanly without any conflicts. Would they be appropriate for kirkstone? I'm wondering if there would be any issue with backporting the KERNEL_LOCALVERSION variable specifically. If I hear nothing before the middle of next week, I'll submit the patch series (CC'ing you Ryan). Can you send me the patch series that you want to want to send in against kirkstone? I'll apply them locally and run some tests on our setup to make sure they don't cause an issue. I don't foresee them being a problem, but I'm more than happy to verify. I send them to the list and CC'ed you, hope that is ok. Yep. I'll test them and reply to the patches. See https://lore.kernel.org/openembedded-core/20240222103545.2970387-1-andreaskle...@gmail.com/T/#t /Andreas PS: This is my first submission to oe-core, so I'm just starting to learn. I have no idea what or how the autobuilder tests, but I'm willing to learn. Steve On 2/12/2024 7:54 AM, Steve Sakoman wrote: From: Bruce Ashfield During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie Cherry-picked f
Re: [OE-core][kirkstone 7/8] kernel: fix localversion in v6.3+
On 2/16/2024 7:51 AM, Andreas Helbech Kleist wrote: On Fri, 2024-02-16 at 09:11 +0100, Andreas Helbech Kleist wrote: On Thu, 2024-02-15 at 19:45 -0600, Ryan Eatmon via lists.openembedded.org wrote: On 2/15/2024 7:43 PM, Steve Sakoman wrote: On Thu, Feb 15, 2024 at 3:20 PM Ryan Eatmon wrote: With this patch in place we are seeing a breakage on our kernel builds. This patch was cherry picked from master, but the next patch on this file in master removes the LOCALVERSION setting... https://git.openembedded.org/openembedded-core/commit/meta/classes-recipe/kernel-arch.bbclass?h=master-next=b378eec156998eea55ba61e59103cb34fab0d07c There is a disconnect here. Why did we change kirkstone, a stable LTS version with a partial patch series based on master? The original kirkstone backport request for this patch was sent to the list for review on February 9. There were no comments or objections, so I added it to the patch test queue. No issues were encountered on the autobuilder, so I sent this patch (along with the rest of the patch queue) to the list for a second review opportunity on February 12. Once again there were no comments or objections, so it was merged today February 15. I follow this process because I'm not smart enough, nor do I have time enough to thoroughly research all implications of every patch. I rely on autobuilder testing and community review to minimize breakage. This normally works quite well, but this time it didn't. I'll revert this patch and if someone would like to resubmit a proper series to deal with the issue it is trying to fix I will consider it and run it through the same process. I can appreciate that. My comment was more for the person who sent the patch in the first place. You are doing a great job. I will try and pay attention for a replacement patch coming in and review as well. I'm sorry about that. I need to use a 6.6 kernel on kirkstone, and this patch fixed my usecase. It looked like a simple bugfix, and I was not aware that there was a later fix for this change. Is there any way I can reproduce the error you saw Ryan? And would it make sense to add an automated test for this usecase? I'll test my usecase with both patches backported and re-submit. I've now looked into it and can make it work in my setup by backporting these three commits from master: kernel.bbclass: introduce KERNEL_LOCALVERSION https://git.openembedded.org/openembedded-core/commit/?h=master-next=229435a52f36ddec5f85fb6d5ccd42044b688397 kernel: fix localversion in v6.3+ https://git.openembedded.org/openembedded-core/commit/?h=master-next=765b13b7305c8d2f222cfc66d77c02e6a088c691 kernel: make LOCALVERSION consistent between recipes https://git.openembedded.org/openembedded-core/commit/?h=master-next=b378eec156998eea55ba61e59103cb34fab0d07c The cherry-pick's apply cleanly without any conflicts. Would they be appropriate for kirkstone? I'm wondering if there would be any issue with backporting the KERNEL_LOCALVERSION variable specifically. If I hear nothing before the middle of next week, I'll submit the patch series (CC'ing you Ryan). Can you send me the patch series that you want to want to send in against kirkstone? I'll apply them locally and run some tests on our setup to make sure they don't cause an issue. I don't foresee them being a problem, but I'm more than happy to verify. /Andreas PS: This is my first submission to oe-core, so I'm just starting to learn. I have no idea what or how the autobuilder tests, but I'm willing to learn. Steve On 2/12/2024 7:54 AM, Steve Sakoman wrote: From: Bruce Ashfield During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie Cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691 Signed-off-by: Andreas Helbech Kleist Signed-off-by: Steve Sakoman --- meta/classes/kernel-arch.bbclass | 7 +++ meta/classes/kernel.bbclass | 10 -- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/meta/classes/kernel-arch.bbclass b/meta/clas
Re: [OE-core][kirkstone 7/8] kernel: fix localversion in v6.3+
On 2/16/2024 2:11 AM, Andreas Helbech Kleist wrote:
On Thu, 2024-02-15 at 19:45 -0600, Ryan Eatmon via
lists.openembedded.org wrote:
On 2/15/2024 7:43 PM, Steve Sakoman wrote:
On Thu, Feb 15, 2024 at 3:20 PM Ryan Eatmon wrote:
With this patch in place we are seeing a breakage on our kernel builds.
This patch was cherry picked from master, but the next patch on this
file in master removes the LOCALVERSION setting...
https://git.openembedded.org/openembedded-core/commit/meta/classes-recipe/kernel-arch.bbclass?h=master-next=b378eec156998eea55ba61e59103cb34fab0d07c
There is a disconnect here. Why did we change kirkstone, a stable LTS
version with a partial patch series based on master?
The original kirkstone backport request for this patch was sent to the
list for review on February 9.
There were no comments or objections, so I added it to the patch test
queue. No issues were encountered on the autobuilder, so I sent this
patch (along with the rest of the patch queue) to the list for a
second review opportunity on February 12. Once again there were no
comments or objections, so it was merged today February 15.
I follow this process because I'm not smart enough, nor do I have time
enough to thoroughly research all implications of every patch. I rely
on autobuilder testing and community review to minimize breakage.
This normally works quite well, but this time it didn't. I'll revert
this patch and if someone would like to resubmit a proper series to
deal with the issue it is trying to fix I will consider it and run it
through the same process.
I can appreciate that. My comment was more for the person who sent the
patch in the first place. You are doing a great job. I will try and
pay attention for a replacement patch coming in and review as well.
I'm sorry about that. I need to use a 6.6 kernel on kirkstone, and this
patch fixed my usecase. It looked like a simple bugfix, and I was not
aware that there was a later fix for this change.
Is there any way I can reproduce the error you saw Ryan?
And would it make sense to add an automated test for this usecase?
I'll test my usecase with both patches backported and re-submit.
/Andreas
PS: This is my first submission to oe-core, so I'm just starting to
learn. I have no idea what or how the autobuilder tests, but I'm
willing to learn.
The meta-ti layer kernel recipes set KERNEL_LOCALVERSION. With this
change in place the modules directory was being name incorrectly which
means that our boot testing failed. For example, if we set:
KERNEL_LOCALVERSION=""
Then the directory was created:
/lib/modules--
One too many in the name.
We never saw this issue on master in our testing because they patched
the file and backed it out a few days later.
Steve
On 2/12/2024 7:54 AM, Steve Sakoman wrote:
From: Bruce Ashfield
During testing of the v6.4 reference kernel, it was noticed that
on-target modules no longer matched the magic value of the running
kernel.
This was due to a different localversion in the cross built kernel
and the scripts / resources created on target.
This was due to changes in the setlocalversion script introduced
in the v6.3 series.
The .scmversion file is no longer used (or packaged) to inhibit
the addition of a "+" (through querying of the git status of the
kernel) or the setting of a local version.
We recently introduced the KERNEL_LOCALVERSION variable to allow
recipes to place a value in .scmversion, so we extend the use of
that variable to kernel-arch.bbclass and use it to set the
exported variable LOCALVERSION.
We must do it at the kernel-arch level, as the variable must be
exported in any kernel build to ensure that setlocalversion always
correctly sets the localversion.
Signed-off-by: Bruce Ashfield
Signed-off-by: Richard Purdie
Cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691
Signed-off-by: Andreas Helbech Kleist
Signed-off-by: Steve Sakoman
---
meta/classes/kernel-arch.bbclass | 7 +++
meta/classes/kernel.bbclass | 10 --
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 4cd08b96fb..0a79dea0af 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -66,3 +66,10 @@ KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd
${HOST_LD_KERNEL_ARCH}"
KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
TOOLCHAIN ?= "gcc"
+# 6.3+ requires the variable LOCALVERSION to be set to not get a "+" in
+# the local version. Having it empty means nothing will be added, and any
+# value will be appended to the local kernel version. This replaces the
+# use of .scmversion file for setting a localversion without using
+# the CONFIG_LOCALVERSION option.
+KERNEL_LOCALVERSION ??= ""
+export LOCALVERSION ?= "${KERNEL_LOCALVERSION}"
diff --
Re: [OE-core][kirkstone 7/8] kernel: fix localversion in v6.3+
On 2/15/2024 7:43 PM, Steve Sakoman wrote:
On Thu, Feb 15, 2024 at 3:20 PM Ryan Eatmon wrote:
With this patch in place we are seeing a breakage on our kernel builds.
This patch was cherry picked from master, but the next patch on this
file in master removes the LOCALVERSION setting...
https://git.openembedded.org/openembedded-core/commit/meta/classes-recipe/kernel-arch.bbclass?h=master-next=b378eec156998eea55ba61e59103cb34fab0d07c
There is a disconnect here. Why did we change kirkstone, a stable LTS
version with a partial patch series based on master?
The original kirkstone backport request for this patch was sent to the
list for review on February 9.
There were no comments or objections, so I added it to the patch test
queue. No issues were encountered on the autobuilder, so I sent this
patch (along with the rest of the patch queue) to the list for a
second review opportunity on February 12. Once again there were no
comments or objections, so it was merged today February 15.
I follow this process because I'm not smart enough, nor do I have time
enough to thoroughly research all implications of every patch. I rely
on autobuilder testing and community review to minimize breakage.
This normally works quite well, but this time it didn't. I'll revert
this patch and if someone would like to resubmit a proper series to
deal with the issue it is trying to fix I will consider it and run it
through the same process.
I can appreciate that. My comment was more for the person who sent the
patch in the first place. You are doing a great job. I will try and
pay attention for a replacement patch coming in and review as well.
Steve
On 2/12/2024 7:54 AM, Steve Sakoman wrote:
From: Bruce Ashfield
During testing of the v6.4 reference kernel, it was noticed that
on-target modules no longer matched the magic value of the running
kernel.
This was due to a different localversion in the cross built kernel
and the scripts / resources created on target.
This was due to changes in the setlocalversion script introduced
in the v6.3 series.
The .scmversion file is no longer used (or packaged) to inhibit
the addition of a "+" (through querying of the git status of the
kernel) or the setting of a local version.
We recently introduced the KERNEL_LOCALVERSION variable to allow
recipes to place a value in .scmversion, so we extend the use of
that variable to kernel-arch.bbclass and use it to set the
exported variable LOCALVERSION.
We must do it at the kernel-arch level, as the variable must be
exported in any kernel build to ensure that setlocalversion always
correctly sets the localversion.
Signed-off-by: Bruce Ashfield
Signed-off-by: Richard Purdie
Cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691
Signed-off-by: Andreas Helbech Kleist
Signed-off-by: Steve Sakoman
---
meta/classes/kernel-arch.bbclass | 7 +++
meta/classes/kernel.bbclass | 10 --
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 4cd08b96fb..0a79dea0af 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -66,3 +66,10 @@ KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd
${HOST_LD_KERNEL_ARCH}"
KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
TOOLCHAIN ?= "gcc"
+# 6.3+ requires the variable LOCALVERSION to be set to not get a "+" in
+# the local version. Having it empty means nothing will be added, and any
+# value will be appended to the local kernel version. This replaces the
+# use of .scmversion file for setting a localversion without using
+# the CONFIG_LOCALVERSION option.
+KERNEL_LOCALVERSION ??= ""
+export LOCALVERSION ?= "${KERNEL_LOCALVERSION}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5951347361..940f1a3cf4 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -418,7 +418,7 @@ do_compile_kernelmodules() {
if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
oe_runmake -C ${B} ${PARALLEL_MAKE} modules ${KERNEL_EXTRA_ARGS}
- # Module.symvers gets updated during the
+ # Module.symvers gets updated during the
# building of the kernel modules. We need to
# update this in the shared workdir since some
# external kernel modules has a dependency on
@@ -635,7 +635,13 @@ kernel_do_configure() {
# $ scripts/setlocalversion . => +
# $ make kernelversion => 2.6.37
# $ make kernelrelease => 2.6.37+
- touch ${B}/.scmversion ${S}/.scmversion
+ # See kernel-arch.bbclass for post v6.3 removal of the extra
+ # + in localversion. .scmversion is no longer used, and the
+ # variable LOCALVERSION must be used
+ if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]; then
+ echo ${KERNEL_LOCALVERSION} > ${B}/.scmversion
+ echo
Re: [OE-core][kirkstone 7/8] kernel: fix localversion in v6.3+
With this patch in place we are seeing a breakage on our kernel builds.
This patch was cherry picked from master, but the next patch on this
file in master removes the LOCALVERSION setting...
https://git.openembedded.org/openembedded-core/commit/meta/classes-recipe/kernel-arch.bbclass?h=master-next=b378eec156998eea55ba61e59103cb34fab0d07c
There is a disconnect here. Why did we change kirkstone, a stable LTS
version with a partial patch series based on master?
On 2/12/2024 7:54 AM, Steve Sakoman wrote:
From: Bruce Ashfield
During testing of the v6.4 reference kernel, it was noticed that
on-target modules no longer matched the magic value of the running
kernel.
This was due to a different localversion in the cross built kernel
and the scripts / resources created on target.
This was due to changes in the setlocalversion script introduced
in the v6.3 series.
The .scmversion file is no longer used (or packaged) to inhibit
the addition of a "+" (through querying of the git status of the
kernel) or the setting of a local version.
We recently introduced the KERNEL_LOCALVERSION variable to allow
recipes to place a value in .scmversion, so we extend the use of
that variable to kernel-arch.bbclass and use it to set the
exported variable LOCALVERSION.
We must do it at the kernel-arch level, as the variable must be
exported in any kernel build to ensure that setlocalversion always
correctly sets the localversion.
Signed-off-by: Bruce Ashfield
Signed-off-by: Richard Purdie
Cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691
Signed-off-by: Andreas Helbech Kleist
Signed-off-by: Steve Sakoman
---
meta/classes/kernel-arch.bbclass | 7 +++
meta/classes/kernel.bbclass | 10 --
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 4cd08b96fb..0a79dea0af 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -66,3 +66,10 @@ KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd
${HOST_LD_KERNEL_ARCH}"
KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
TOOLCHAIN ?= "gcc"
+# 6.3+ requires the variable LOCALVERSION to be set to not get a "+" in
+# the local version. Having it empty means nothing will be added, and any
+# value will be appended to the local kernel version. This replaces the
+# use of .scmversion file for setting a localversion without using
+# the CONFIG_LOCALVERSION option.
+KERNEL_LOCALVERSION ??= ""
+export LOCALVERSION ?= "${KERNEL_LOCALVERSION}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5951347361..940f1a3cf4 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -418,7 +418,7 @@ do_compile_kernelmodules() {
if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
oe_runmake -C ${B} ${PARALLEL_MAKE} modules ${KERNEL_EXTRA_ARGS}
- # Module.symvers gets updated during the
+ # Module.symvers gets updated during the
# building of the kernel modules. We need to
# update this in the shared workdir since some
# external kernel modules has a dependency on
@@ -635,7 +635,13 @@ kernel_do_configure() {
# $ scripts/setlocalversion . => +
# $ make kernelversion => 2.6.37
# $ make kernelrelease => 2.6.37+
- touch ${B}/.scmversion ${S}/.scmversion
+ # See kernel-arch.bbclass for post v6.3 removal of the extra
+ # + in localversion. .scmversion is no longer used, and the
+ # variable LOCALVERSION must be used
+ if [ ! -e ${B}/.scmversion -a ! -e ${S}/.scmversion ]; then
+ echo ${KERNEL_LOCALVERSION} > ${B}/.scmversion
+ echo ${KERNEL_LOCALVERSION} > ${S}/.scmversion
+ fi
if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f "${B}/.config" ]; then
mv "${S}/.config" "${B}/.config"
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195734):
https://lists.openembedded.org/g/openembedded-core/message/195734
Mute This Topic: https://lists.openembedded.org/mt/104311283/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] python3-yamllint: Add recipe
Add recipe for yamllint. There is an upcoming change in u-boot where
the binman tool is now configured to call yamllint to verify the configs
during compile time.
There was a previous patch a year ago from Trevor Woerner that never
made it into oe-core. This patch is a reworking of his patch but
pointing to a newer version.
Signed-off-by: Ryan Eatmon
---
v2: Added entry in maintainers.inc
meta/conf/distro/include/maintainers.inc | 1 +
.../python/python3-yamllint_1.33.0.bb | 15 +++
2 files changed, 16 insertions(+)
create mode 100644 meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 8dc63b138e..b0625a1097 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -724,6 +724,7 @@ RECIPE_MAINTAINER:pn-python3-wcwidth = "Tim Orling
"
RECIPE_MAINTAINER:pn-python3-webcolors = "Bruce Ashfield
"
RECIPE_MAINTAINER:pn-python3-wheel = "Tim Orling "
RECIPE_MAINTAINER:pn-python3-xmltodict = "Leon Anavi "
+RECIPE_MAINTAINER:pn-python3-yamllint = "Tim Orling "
RECIPE_MAINTAINER:pn-python3-zipp = "Tim Orling "
RECIPE_MAINTAINER:pn-qemu = "Richard Purdie
"
RECIPE_MAINTAINER:pn-qemu-helper-native = "Richard Purdie
"
diff --git a/meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
b/meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
new file mode 100644
index 00..4b7bd065f9
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
@@ -0,0 +1,15 @@
+SUMMARY = "A linter for YAML files."
+HOMEPAGE = "https://github.com/adrienverge/yamllint;
+LICENSE = "GPL-3.0-only"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=1ebbd3e34237af26da5dc08a4e440464"
+
+inherit pypi setuptools3
+
+PYPI_PACKAGE = "yamllint"
+
+SRC_URI[sha256sum] =
"2dceab9ef2d99518a2fcf4ffc964d44250ac4459be1ba3ca315118e4a1a81f7d"
+
+DEPENDS += "${PYTHON_PN}-setuptools-scm-native"
+RDEPENDS:${PN} += "${PYTHON_PN}-pyyaml"
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194246):
https://lists.openembedded.org/g/openembedded-core/message/194246
Mute This Topic: https://lists.openembedded.org/mt/103913187/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-yamllint: Add recipe
On 1/22/2024 4:30 PM, Yoann Congal wrote: Hi, Le 22/01/2024 à 21:07, Ryan Eatmon via lists.openembedded.org a écrit : Add recipe for yamllint. There is an upcoming change in u-boot where the binman tool is now configured to call yamllint to verify the configs during compile time. There was a previous patch a year ago from Trevor Woerner that never made it into oe-core. This patch is a reworking of his patch but pointing to a newer version. Signed-off-by: Ryan Eatmon --- .../python/python3-yamllint_1.33.0.bb | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 meta/recipes-devtools/python/python3-yamllint_1.33.0.bb FYI, this new recipe lacks a maintainer and throw this warning : WARNING: python3-yamllint-1.33.0-r0 do_recipe_qa: QA Issue: Recipe python3-yamllint in [...]/poky/meta/recipes-devtools/python/python3-yamllint_1.33.0.bb does not have an assigned maintainer. Please add an entry into meta/conf/distro/include/maintainers.inc. [missing-maintainer] Tim, Do you mind being the maintainer for this new python recipe? You are maintainer for many other python modules including pyyaml which this module depends on. I can submit a v2 updating that file as well if you are willing. Regards, -- Ryan Eatmonreat...@ti.com - Texas Instruments, Inc. - LCPD - MGTS -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#194195): https://lists.openembedded.org/g/openembedded-core/message/194195 Mute This Topic: https://lists.openembedded.org/mt/103894761/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] python3-yamllint: Add recipe
Add recipe for yamllint. There is an upcoming change in u-boot where
the binman tool is now configured to call yamllint to verify the configs
during compile time.
There was a previous patch a year ago from Trevor Woerner that never
made it into oe-core. This patch is a reworking of his patch but
pointing to a newer version.
Signed-off-by: Ryan Eatmon
---
.../python/python3-yamllint_1.33.0.bb | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
diff --git a/meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
b/meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
new file mode 100644
index 00..4b7bd065f9
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-yamllint_1.33.0.bb
@@ -0,0 +1,15 @@
+SUMMARY = "A linter for YAML files."
+HOMEPAGE = "https://github.com/adrienverge/yamllint;
+LICENSE = "GPL-3.0-only"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=1ebbd3e34237af26da5dc08a4e440464"
+
+inherit pypi setuptools3
+
+PYPI_PACKAGE = "yamllint"
+
+SRC_URI[sha256sum] =
"2dceab9ef2d99518a2fcf4ffc964d44250ac4459be1ba3ca315118e4a1a81f7d"
+
+DEPENDS += "${PYTHON_PN}-setuptools-scm-native"
+RDEPENDS:${PN} += "${PYTHON_PN}-pyyaml"
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194192):
https://lists.openembedded.org/g/openembedded-core/message/194192
Mute This Topic: https://lists.openembedded.org/mt/103894761/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] spdx: use TOOLCHAIN_OUTPUTNAME for SDK filename prefix
On 9/22/2023 5:20 PM, Denys Dmytriyenko wrote:
Replace SDK_NAME with TOOLCHAIN_OUTPUTNAME when naming SDK host and
target SPDX archives.
In most cases TOOLCHAIN_OUTPUTNAME is almost identical to SDK_NAME,
but sometimes custom meta-toolchain recipes have some variations and
populate_sdk_base.bbclass already uses TOOLCHAIN_OUTPUTNAME to name
corresponding host and target manifests:
SDK_HOST_MANIFEST = "${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.host.manifest"
SDK_TARGET_MANIFEST = "${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.target.manifest"
To match the naming convention, also use TOOLCHAIN_OUTPUTNAME here
for naming SPDX archives as well, resulting in:
${TOOLCHAIN_OUTPUTNAME}-host.spdx.tar.zst
${TOOLCHAIN_OUTPUTNAME}-target.spdx.tar.zst
Signed-off-by: Denys Dmytriyenko
Signed-off-by: Denys Dmytriyenko
Tested-by: Ryan Eatmon
---
meta/classes/create-spdx-2.2.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/create-spdx-2.2.bbclass
b/meta/classes/create-spdx-2.2.bbclass
index a2b96da61a..885f07a1f8 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -986,7 +986,7 @@ def sdk_combine_spdx(d, sdk_type):
from pathlib import Path
from oe.sdk import sdk_list_installed_packages
-sdk_name = d.getVar("SDK_NAME") + "-" + sdk_type
+sdk_name = d.getVar("TOOLCHAIN_OUTPUTNAME") + "-" + sdk_type
sdk_deploydir = Path(d.getVar("SDKDEPLOYDIR"))
sdk_spdxid = oe.sbom.get_sdk_spdxid(sdk_name)
sdk_packages = sdk_list_installed_packages(d, sdk_type == "target")
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188156):
https://lists.openembedded.org/g/openembedded-core/message/188156
Mute This Topic: https://lists.openembedded.org/mt/101531120/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] bitbake.conf: add MACHINE to SDK_NAME
On 9/22/2023 5:20 PM, Denys Dmytriyenko wrote:
Do the same here as Poky has done 5 years ago, adding MACHINE to
SDK_NAME:
https://git.yoctoproject.org/meta-yocto/commit/?id=3614dd4aee9d19f1024edb6a36b2862c2d726c04
This avoids file conflicts in deploy/sdk/ when building multiple
machines (either manually or via multiconfig), where sdk/toolchain
installers, manifests and now SPDX archives will overlap otherwise.
Signed-off-by: Denys Dmytriyenko
Signed-off-by: Denys Dmytriyenko
Tested-by: Ryan Eatmon
---
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 67577c8fe7..3fd089cebb 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -459,7 +459,7 @@ PKGDATA_DIR_SDK = "${TMPDIR}/pkgdata/${SDK_SYS}"
##
SDK_NAME_PREFIX ?= "oecore"
-SDK_NAME = "${SDK_NAME_PREFIX}-${IMAGE_BASENAME}-${SDK_ARCH}-${TUNE_PKGARCH}"
+SDK_NAME =
"${SDK_NAME_PREFIX}-${IMAGE_BASENAME}-${SDK_ARCH}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATH = "/usr/local/oe-sdk-hardcoded-buildpath"
SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
# The path to default to installing the SDK to
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188155):
https://lists.openembedded.org/g/openembedded-core/message/188155
Mute This Topic: https://lists.openembedded.org/mt/101531119/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] classes/create-spdx-2.2: Add missing import oe.packagedata
On 9/22/2023 1:47 AM, Richard Purdie wrote:
On Wed, 2023-09-20 at 10:30 -0500, Ryan Eatmon via
lists.openembedded.org wrote:
Add missing import statement to fix build failures:
File:
'/scratch/jenkins_builds/arago-master-wip/build/sources/oe-core/meta/classes/create-spdx-2.2.bbclass',
lineno: 722, function: collect_package_providers
0718:deps.append((d.getVar("PN"), d.getVar("BB_HASHFILENAME")))
0719:
0720:for dep_pn, dep_hashfn in deps:
0721:localdata = d
*** 0722:recipe_data = oe.packagedata.read_pkgdata(dep_pn, localdata)
0723:if not recipe_data:
0724:localdata = bb.data.createCopy(d)
0725:localdata.setVar("PKGDATA_DIR", "${PKGDATA_DIR_SDK}")
0726:recipe_data = oe.packagedata.read_pkgdata(dep_pn,
localdata)
Exception: AttributeError: module 'oe' has no attribute 'packagedata'
Signed-off-by: Ryan Eatmon
---
meta/classes/create-spdx-2.2.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/create-spdx-2.2.bbclass
b/meta/classes/create-spdx-2.2.bbclass
index 9b28d124c7..ff319207f7 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -708,6 +708,7 @@ def collect_package_providers(d):
from pathlib import Path
import oe.sbom
import oe.spdx
+import oe.packagedata
import json
deploy_dir_spdx = Path(d.getVar("DEPLOY_DIR_SPDX"))
We've realised that packagedata is missing in BBIMPORTS in
meta/lib/oe/__init__.py which should fix this but also add missing
dependency information so I'm likely to go with that change and this
one shouldn't be needed. Let me know if that isn't the case.
Your fix is better as it should cover all cases and not just this one.
Cheers,
Richard
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188132):
https://lists.openembedded.org/g/openembedded-core/message/188132
Mute This Topic: https://lists.openembedded.org/mt/101480881/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] classes/create-spdx-2.2: Add missing import oe.packagedata
Add missing import statement to fix build failures:
File:
'/scratch/jenkins_builds/arago-master-wip/build/sources/oe-core/meta/classes/create-spdx-2.2.bbclass',
lineno: 722, function: collect_package_providers
0718:deps.append((d.getVar("PN"), d.getVar("BB_HASHFILENAME")))
0719:
0720:for dep_pn, dep_hashfn in deps:
0721:localdata = d
*** 0722:recipe_data = oe.packagedata.read_pkgdata(dep_pn, localdata)
0723:if not recipe_data:
0724:localdata = bb.data.createCopy(d)
0725:localdata.setVar("PKGDATA_DIR", "${PKGDATA_DIR_SDK}")
0726:recipe_data = oe.packagedata.read_pkgdata(dep_pn,
localdata)
Exception: AttributeError: module 'oe' has no attribute 'packagedata'
Signed-off-by: Ryan Eatmon
---
meta/classes/create-spdx-2.2.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/create-spdx-2.2.bbclass
b/meta/classes/create-spdx-2.2.bbclass
index 9b28d124c7..ff319207f7 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -708,6 +708,7 @@ def collect_package_providers(d):
from pathlib import Path
import oe.sbom
import oe.spdx
+import oe.packagedata
import json
deploy_dir_spdx = Path(d.getVar("DEPLOY_DIR_SPDX"))
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187930):
https://lists.openembedded.org/g/openembedded-core/message/187930
Mute This Topic: https://lists.openembedded.org/mt/101480881/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] kernel.bbclass: Add force flag to rm calls
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it. Simple fix is to add the
-f (force) flag to the call.
Signed-off-by: Ryan Eatmon
---
v2: Switch from if exists wrapper to -f flag on rm.
meta/classes-recipe/kernel.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes-recipe/kernel.bbclass
b/meta/classes-recipe/kernel.bbclass
index acb43bd4d5..2ec9ea2091 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -454,8 +454,8 @@ kernel_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
oe_runmake DEPMOD=echo
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
- rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
- rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+ 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
else
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186988):
https://lists.openembedded.org/g/openembedded-core/message/186988
Mute This Topic: https://lists.openembedded.org/mt/101083154/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] kernel.bbclass: Add file exist checks around removes
On 8/31/2023 1:26 PM, Ryan Eatmon via lists.openembedded.org wrote:
With two votes I'll send a v2.
No, I have not done that thorough of an investigation into what happened
to the source file. My thought was just to get the build working so
that our nightly upstream testing (latest kernel, uboot, optee-os,
trusted-firmeware) would not be blocked. But I can look into it deeper
and let you know.
It looks like they reworked how make modules_install worked. They moved
the logic into a files scripts/Makefile.modinst. And all they seem to
have removed was the symlink to the source tree. The symlink build is
still there.
On 8/31/2023 12:58 PM, Peter Kjellerstedt wrote:
For what it’s worth, I would also go with rm -f.
Also, have you checked so that the files have not just been
moved/renamed? I.e., are they produced in some other location where
they should now also be removed from?
//Peter
*From:*openembedded-core@lists.openembedded.org
*On Behalf Of *Frederic
Martinsons
*Sent:* den 31 augusti 2023 18:57
*To:* Ryan Eatmon
*Cc:* openembedded-core@lists.openembedded.org
*Subject:* Re: [OE-core][PATCH] kernel.bbclass: Add file exist checks
around removes
On Thu, 31 Aug 2023 at 15:49, Ryan Eatmon <mailto:reat...@ti.com>> wrote:
On 8/31/2023 8:47 AM, Frédéric Martinsons wrote:
> Hello,
>
> On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via
lists.openembedded.org <http://lists.openembedded.org>
> <http://lists.openembedded.org <http://lists.openembedded.org>>
mailto:ti@lists.openembedded.org>
> <mailto:ti@lists.openembedded.org
<mailto:ti@lists.openembedded.org>>> wrote:
>
> The latest 6.5 kernels do not appear to create the source
file in
> ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source
so the
> recipe errors out when trying to remove it. Simple fix is to
add an
> exists check around the call.
> > Signed-off-by: Ryan Eatmon <mailto:reat...@ti.com><mailto:reat...@ti.com
<mailto:reat...@ti.com>>>
> ---
> meta/classes-recipe/kernel.bbclass | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
> > diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> index acb43bd4d5..4df052061b 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -454,8 +454,12 @@ kernel_do_install() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
> if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
> oe_runmake
DEPMOD=echoMODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
> -
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> -
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> + if [
-e"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
> +
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> + fi
> + if [
-e"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
> +
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> + fi
> # Remove empty module directories to
prevent QA issues
>
find"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -typed
-empty -delete
> else
> -- > 2.17.1
> > > My 2 cents: the "-f" switch
makes rm ignore nonexistent files , and it > will make a shorter
patch ;)
If that is the group consensus I can submit a v2. Anyone else feel
that
way?
Don't know if a "group consensus" can exist here. (it is a public list
where anyone can raise remarks) and there is no "vote".
Mine was not a "cons" for you patch, what you did is completely valid,
I just wanted to say that there was a more concise way of doing it.
Feel free to send a v2 if you think my remark is relevant.
>
>
>
-- Ryan Eatmon reat...@ti.com <mailto:reat...@ti.com>
-
Texas Instruments, Inc. - LCPD - MGTS
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to th
Re: [OE-core][PATCH] kernel.bbclass: Add file exist checks around removes
With two votes I'll send a v2.
No, I have not done that thorough of an investigation into what happened
to the source file. My thought was just to get the build working so
that our nightly upstream testing (latest kernel, uboot, optee-os,
trusted-firmeware) would not be blocked. But I can look into it deeper
and let you know.
On 8/31/2023 12:58 PM, Peter Kjellerstedt wrote:
For what it’s worth, I would also go with rm -f.
Also, have you checked so that the files have not just been
moved/renamed? I.e., are they produced in some other location where they
should now also be removed from?
//Peter
*From:*openembedded-core@lists.openembedded.org
*On Behalf Of *Frederic
Martinsons
*Sent:* den 31 augusti 2023 18:57
*To:* Ryan Eatmon
*Cc:* openembedded-core@lists.openembedded.org
*Subject:* Re: [OE-core][PATCH] kernel.bbclass: Add file exist checks
around removes
On Thu, 31 Aug 2023 at 15:49, Ryan Eatmon <mailto:reat...@ti.com>> wrote:
On 8/31/2023 8:47 AM, Frédéric Martinsons wrote:
> Hello,
>
> On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via
lists.openembedded.org <http://lists.openembedded.org>
> <http://lists.openembedded.org <http://lists.openembedded.org>>
mailto:ti@lists.openembedded.org>
> <mailto:ti@lists.openembedded.org
<mailto:ti@lists.openembedded.org>>> wrote:
>
> The latest 6.5 kernels do not appear to create the source file in
> ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source
so the
> recipe errors out when trying to remove it. Simple fix is to
add an
> exists check around the call.
>
> Signed-off-by: Ryan Eatmon mailto:reat...@ti.com><mailto:reat...@ti.com
<mailto:reat...@ti.com>>>
> ---
> meta/classes-recipe/kernel.bbclass | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> index acb43bd4d5..4df052061b 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -454,8 +454,12 @@ kernel_do_install() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
> if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
> oe_runmake
DEPMOD=echoMODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware
modules_install
> -
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> -
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> + if [
-e"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
> +
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> + fi
> + if [
-e"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
> +
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> + fi
> # Remove empty module directories to prevent QA
issues
>
find"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -typed
-empty -delete
> else
> --
> 2.17.1
>
>
> My 2 cents: the "-f" switch makes rm ignore nonexistent files , and it
> will make a shorter patch ;)
If that is the group consensus I can submit a v2. Anyone else feel that
way?
Don't know if a "group consensus" can exist here. (it is a public list
where anyone can raise remarks) and there is no "vote".
Mine was not a "cons" for you patch, what you did is completely valid,
I just wanted to say that there was a more concise way of doing it.
Feel free to send a v2 if you think my remark is relevant.
>
>
>
--
Ryan Eatmon reat...@ti.com <mailto:reat...@ti.com>
-
Texas Instruments, Inc. - LCPD - MGTS
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186986):
https://lists.openembedded.org/g/openembedded-core/message/186986
Mute This Topic: https://lists.openembedded.org/mt/101073782/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] kernel.bbclass: Add file exist checks around removes
On 8/31/2023 8:47 AM, Frédéric Martinsons wrote:
Hello,
On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via lists.openembedded.org
<http://lists.openembedded.org> <mailto:ti@lists.openembedded.org>> wrote:
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it. Simple fix is to add an
exists check around the call.
Signed-off-by: Ryan Eatmon mailto:reat...@ti.com>>
---
meta/classes-recipe/kernel.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes-recipe/kernel.bbclass
b/meta/classes-recipe/kernel.bbclass
index acb43bd4d5..4df052061b 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -454,8 +454,12 @@ kernel_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
oe_runmake DEPMOD=echo
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
- rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
- rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+ if [ -e
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
+ rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
+ fi
+ if [ -e
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
+ rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+ fi
# Remove empty module directories to prevent QA issues
find
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type
d -empty -delete
else
--
2.17.1
My 2 cents: the "-f" switch makes rm ignore nonexistent files , and it
will make a shorter patch ;)
If that is the group consensus I can submit a v2. Anyone else feel that
way?
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186976):
https://lists.openembedded.org/g/openembedded-core/message/186976
Mute This Topic: https://lists.openembedded.org/mt/101073782/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] kernel.bbclass: Add file exist checks around removes
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it. Simple fix is to add an
exists check around the call.
Signed-off-by: Ryan Eatmon
---
meta/classes-recipe/kernel.bbclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes-recipe/kernel.bbclass
b/meta/classes-recipe/kernel.bbclass
index acb43bd4d5..4df052061b 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -454,8 +454,12 @@ kernel_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
oe_runmake DEPMOD=echo
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
- rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
- rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+ if [ -e
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
+ rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
+ fi
+ if [ -e
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
+ rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+ fi
# Remove empty module directories to prevent QA issues
find
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d -empty
-delete
else
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186974):
https://lists.openembedded.org/g/openembedded-core/message/186974
Mute This Topic: https://lists.openembedded.org/mt/101073782/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"
On 8/27/2023 4:23 PM, Peter Kjellerstedt wrote:
-Original Message-
From: Max Krummenacher
Sent: den 27 augusti 2023 10:10
To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
Cc: Max Krummenacher ; Randolph Sapp
Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the
default dependencies"
From: Max Krummenacher
Hi
With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
dependencies") applied I'm getting a lot of these errors, i.e. qa
does miss libc and compiler provided libs:
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found
in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
/usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-
umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers
found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
Reverting the commit makes the build pass, alternatively adding
to depends in the recipe which is using the bin_package class
fixes it too:
DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
I'd prefer reverting removing the default dependencies over fixing
each of the recipes which do use the bin_package class to actually
install binaries running in the target user space.
Any opinions?
Bummer. I guess we will have to update our recipes individually
instead. :(
Was there some issue that your patch was seeking to solve? There was
not much explanation in your patch or discussion about it on the mailing
list before it was accepted.
Or did this just seem like something to do since this class doesn't
build anything?
Just looking for background.
Your commit is also the source of another error with this the same
ti-img-rogue-umlibs recipe that I've been trying to track down all last
week. Max just beat me to finding it.
I'm voting to revert your patch unless there is compelling reason for
your patch.
Max
Max Krummenacher (1):
Revert "bin_package.bbclass: Inhibit the default dependencies"
meta/classes-recipe/bin_package.bbclass | 3 ---
1 file changed, 3 deletions(-)
--
2.35.3
//Peter
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186838):
https://lists.openembedded.org/g/openembedded-core/message/186838
Mute This Topic: https://lists.openembedded.org/mt/100987453/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] image.bbclass question
In looking at the poky tiny initramfs image, it sets:
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
Which would then make the two variable the same and make the check kick
in. But I cannot find where it manual says that you have to make them
the same value and cannot generate an initramfs image along with all
other image types.
On 8/2/2023 1:14 PM, Ryan Eatmon via lists.openembedded.org wrote:
I added some debugging to print out the various variables on interest
and got this output:
DEBUG: image_fstypes= tar.xz wic.xz wic.bmap tar.xz.md5sum cpio cpio.xz
DEBUG: initramfs_fstypes=cpio.gz cpio cpio.xz
DEBUG: initramfs_maxsize=65536.00
DEBUG: base_size=74366
So I'm not sure I agree with what you are saying. Again, I might be
missing something in how the == is supposed to work when comparing the
two variables...
On 8/2/2023 12:17 PM, Christopher Larson wrote:
Image builds obey IMAGE_FSTYPES. Initramfs images set that to
INITRAMFS_FSTYPES, so it's comparing the two as a check to see if this
is an initramfs image. It isn't making sure it matches a hardcoded
list, so intersection isn't necessary.
On Wed, Aug 2, 2023 at 9:41 AM Ryan Eatmon via lists.openembedded.org
<http://lists.openembedded.org> <mailto:ti@lists.openembedded.org>> wrote:
I am trying to add support for the INITRAMFS_MAXSIZE into the meta-ti
layer for our tiny image.
I have added the following to our tiny image file:
INITRAMFS_FSTYPES += "cpio cpio.xz"
INITRAMFS_MAXSIZE = "65536"
But I'm not seeing any errors about the image being too big being
printed.
In looking at the code in question:
# Check the initramfs size against INITRAMFS_MAXSIZE (if set)
if image_fstypes == initramfs_fstypes != '' and
initramfs_maxsize:
initramfs_maxsize_int = int(initramfs_maxsize)
if base_size > initramfs_maxsize_int:
bb.error("The initramfs size %d(K) exceeds
INITRAMFS_MAXSIZE: %d(K)" % \
(base_size, initramfs_maxsize_int))
bb.error("You can set INITRAMFS_MAXSIZE a larger value.
Usually, it should")
bb.fatal("be less than 1/2 of ram size, or you may
fail to
boot it.\n")
What is the purpose of the:
if image_fstypes == initramfs_fstypes != ''
It seems to looking for the ONLY images being built are the exact
same
as the INITRAMFS_FSTYPES... Shouldn't that be more of an
intersection
check? If any of the INITRAMFS_FSTYPES are in the IMAGE_FSTYPES,
then
check the size?
Or am I missing something?
-- Ryan Eatmon reat...@ti.com <mailto:reat...@ti.com>
-
Texas Instruments, Inc. - LCPD - MGTS
--
Christopher Larson
chris_lar...@mentor.com, chris.lar...@siemens.com, kerg...@gmail.com
Principal Software Engineer, Embedded Linux Solutions, Siemens Digital
Industries Software
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185427):
https://lists.openembedded.org/g/openembedded-core/message/185427
Mute This Topic: https://lists.openembedded.org/mt/100509426/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] image.bbclass question
I added some debugging to print out the various variables on interest
and got this output:
DEBUG: image_fstypes= tar.xz wic.xz wic.bmap tar.xz.md5sum cpio cpio.xz
DEBUG: initramfs_fstypes=cpio.gz cpio cpio.xz
DEBUG: initramfs_maxsize=65536.00
DEBUG: base_size=74366
So I'm not sure I agree with what you are saying. Again, I might be
missing something in how the == is supposed to work when comparing the
two variables...
On 8/2/2023 12:17 PM, Christopher Larson wrote:
Image builds obey IMAGE_FSTYPES. Initramfs images set that to
INITRAMFS_FSTYPES, so it's comparing the two as a check to see if this
is an initramfs image. It isn't making sure it matches a hardcoded list,
so intersection isn't necessary.
On Wed, Aug 2, 2023 at 9:41 AM Ryan Eatmon via lists.openembedded.org
<http://lists.openembedded.org> <mailto:ti@lists.openembedded.org>> wrote:
I am trying to add support for the INITRAMFS_MAXSIZE into the meta-ti
layer for our tiny image.
I have added the following to our tiny image file:
INITRAMFS_FSTYPES += "cpio cpio.xz"
INITRAMFS_MAXSIZE = "65536"
But I'm not seeing any errors about the image being too big being
printed.
In looking at the code in question:
# Check the initramfs size against INITRAMFS_MAXSIZE (if set)
if image_fstypes == initramfs_fstypes != '' and
initramfs_maxsize:
initramfs_maxsize_int = int(initramfs_maxsize)
if base_size > initramfs_maxsize_int:
bb.error("The initramfs size %d(K) exceeds
INITRAMFS_MAXSIZE: %d(K)" % \
(base_size, initramfs_maxsize_int))
bb.error("You can set INITRAMFS_MAXSIZE a larger value.
Usually, it should")
bb.fatal("be less than 1/2 of ram size, or you may
fail to
boot it.\n")
What is the purpose of the:
if image_fstypes == initramfs_fstypes != ''
It seems to looking for the ONLY images being built are the exact same
as the INITRAMFS_FSTYPES... Shouldn't that be more of an intersection
check? If any of the INITRAMFS_FSTYPES are in the IMAGE_FSTYPES, then
check the size?
Or am I missing something?
--
Ryan Eatmon reat...@ti.com <mailto:reat...@ti.com>
-
Texas Instruments, Inc. - LCPD - MGTS
--
Christopher Larson
chris_lar...@mentor.com, chris.lar...@siemens.com, kerg...@gmail.com
Principal Software Engineer, Embedded Linux Solutions, Siemens Digital
Industries Software
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185425):
https://lists.openembedded.org/g/openembedded-core/message/185425
Mute This Topic: https://lists.openembedded.org/mt/100509426/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] image.bbclass question
I am trying to add support for the INITRAMFS_MAXSIZE into the meta-ti
layer for our tiny image.
I have added the following to our tiny image file:
INITRAMFS_FSTYPES += "cpio cpio.xz"
INITRAMFS_MAXSIZE = "65536"
But I'm not seeing any errors about the image being too big being printed.
In looking at the code in question:
# Check the initramfs size against INITRAMFS_MAXSIZE (if set)
if image_fstypes == initramfs_fstypes != '' and initramfs_maxsize:
initramfs_maxsize_int = int(initramfs_maxsize)
if base_size > initramfs_maxsize_int:
bb.error("The initramfs size %d(K) exceeds
INITRAMFS_MAXSIZE: %d(K)" % \
(base_size, initramfs_maxsize_int))
bb.error("You can set INITRAMFS_MAXSIZE a larger value.
Usually, it should")
bb.fatal("be less than 1/2 of ram size, or you may fail to
boot it.\n")
What is the purpose of the:
if image_fstypes == initramfs_fstypes != ''
It seems to looking for the ONLY images being built are the exact same
as the INITRAMFS_FSTYPES... Shouldn't that be more of an intersection
check? If any of the INITRAMFS_FSTYPES are in the IMAGE_FSTYPES, then
check the size?
Or am I missing something?
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185415):
https://lists.openembedded.org/g/openembedded-core/message/185415
Mute This Topic: https://lists.openembedded.org/mt/100509426/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Parsing failure due to recent patch
I am seeing a parsing error with the meta-ti layer due to this recent
change:
https://git.openembedded.org/openembedded-core/commit/?id=93a09a05d6dde3542587735df0aa2371e79a3bb7
We have the following lines in our files:
KERNEL_LOCALVERSION =
"-g${@d.getVar('SRCPV',True).replace('AUTOINC+','')[:10]}"
UBOOT_LOCALVERSION =
"-g${@d.getVar('SRCPV',True).replace('AUTOINC+','')[:10]}"
And when that patch is in place we now get this error:
ERROR: ExpansionError during parsing
/scratch/builds/arago-master-wip/build/sources/meta-ti/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-staging_2023.04.bb
Traceback (most recent call last):
File
"/scratch/builds/arago-master-wip/build/sources/bitbake/lib/bb/data_smart.py",
line 460, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}',
varname='SRCPV'):
try:
>s =
__expand_python_regexp__.sub(varparse.python_sub, s)
except SyntaxError as e:
File
"/scratch/builds/arago-master-wip/build/sources/bitbake/lib/bb/data_smart.py",
line 150, in VariableParse.python_sub(match=27), match='${@bb.fetch2.get_srcrev(d)}'>):
self.contains[k].update(parser.contains[k])
>value = utils.better_eval(codeobj,
DataContext(self.d), {'d' : self.d})
return str(value)
File
"/scratch/builds/arago-master-wip/build/sources/bitbake/lib/bb/utils.py",
line 434, in better_eval(source= at 0x7f4978634c90,
file "Var ", line 1>, locals={'d': object at 0x7f49787dc970>}, extraglobals={'d': object at 0x7f49787dc970>}):
ctx[g] = extraglobals[g]
>return eval(source, ctx, locals)
File "Var ", line 1, in
File
"/scratch/builds/arago-master-wip/build/sources/bitbake/lib/bb/fetch2/__init__.py",
line 784, in get_srcrev(d=0x7f49787dc970>, method_name='sortable_revision'):
if not scms:
>raise FetchError("SRCREV was used yet no valid SCM was
found in SRC_URI")
bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
FetchError: Fetcher failure: SRCREV was used yet no valid SCM was found
in SRC_URI
The variable dependency chain for the failure is: SRCPV ->
UBOOT_LOCALVERSION -> do_compile
ERROR: Parsing halted due to errors, see error messages above
Any reference to SRCPV in those variables fails due to SRC_URI being
cleared by the patch.
--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181726):
https://lists.openembedded.org/g/openembedded-core/message/181726
Mute This Topic: https://lists.openembedded.org/mt/99139791/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][master] go: Update reproducibility patch to fix panic errors
This might have gotten lost in the fun of the YPS and the many
discussions around the previous versions of then patch. Was there any
more feedback or changes that folks want me to make for this patch, or
is it good to go? Just curious if there was more that you needed from me?
On 11/29/2022 8:12, Ryan Eatmon via lists.openembedded.org wrote:
Based on a discussion on the mailing list [1], there are panic
errors that occur on a few platforms caused by the patch. We
cannot simply remove the original patch due to the
reproducibility issues that it addresses, so this patch on the
original patch fixes the cause of the panic errors.
The previous version of this patch was a little too aggressive
in cleaning up the environment. Some of the variables impacted
by the filerCompilerFlags() function require at least one value
to remain in the array. In this case, the values for ccExe,
cxxExe, and fcExe require a value or later code that access
them result in a panic related to accessing a value out of range.
This updated patch adds a flag that requires keeping the first
value so that at least one thing remains and the assignments
for the Exes set that flag to true. The first item in the
array should be the executable name, so leaving it should be
safe.
I have run the oe-selftest and everything passed in my setup.
There is a bug report [2] filed for the issue that this patch
addresses.
[YOCTO #14976]
[1] https://lists.openembedded.org/g/openembedded-core/topic/94022663
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14976
Signed-off-by: Ryan Eatmon
---
v3: Added [YOCTO #14976] to commit message.
v2: Added more background and bug report link to commit message.
...ent-based-hash-generation-less-pedan.patch | 30 ++-
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
index 17fa9d9831..43be5cd2e8 100644
---
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
+++
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
@@ -74,7 +74,7 @@ index c88b315..a06455c 100644
+ cppflags, cflags, cxxflags, fflags, ldflags, _ := b.CFlags(p,
true)
- ccExe := b.ccExe()
-+ ccExe := filterCompilerFlags(b.ccExe())
++ ccExe := filterCompilerFlags(b.ccExe(), true)
fmt.Fprintf(h, "CC=%q %q %q %q\n", ccExe, cppflags, cflags,
ldflags)
// Include the C compiler tool ID so that if the C
// compiler changes we rebuild the package.
@@ -83,7 +83,7 @@ index c88b315..a06455c 100644
}
if len(p.CXXFiles)+len(p.SwigCXXFiles) > 0 {
- cxxExe := b.cxxExe()
-+ cxxExe := filterCompilerFlags(b.cxxExe())
++ cxxExe := filterCompilerFlags(b.cxxExe(), true)
fmt.Fprintf(h, "CXX=%q %q\n", cxxExe, cxxflags)
if cxxID, err := b.gccToolID(cxxExe[0], "c++"); err ==
nil {
fmt.Fprintf(h, "CXX ID=%q\n", cxxID)
@@ -91,7 +91,7 @@ index c88b315..a06455c 100644
}
if len(p.FFiles) > 0 {
- fcExe := b.fcExe()
-+ fcExe := filterCompilerFlags(b.fcExe())
++ fcExe := filterCompilerFlags(b.fcExe(), true)
fmt.Fprintf(h, "FC=%q %q\n", fcExe, fflags)
if fcID, err := b.gccToolID(fcExe[0], "f95"); err ==
nil {
fmt.Fprintf(h, "FC ID=%q\n", fcID)
@@ -104,20 +104,22 @@ index c88b315..a06455c 100644
}
// Configuration specific to compiler toolchain.
-@@ -2705,8 +2707,23 @@ func envList(key, def string) []string {
+@@ -2705,8 +2707,25 @@ func envList(key, def string) []string {
return args
}
+var filterFlags = os.Getenv("CGO_PEDANTIC") == ""
+
-+func filterCompilerFlags(flags []string) []string {
++func filterCompilerFlags(flags []string, keepfirst bool) []string {
+ var newflags []string
++ var realkeepfirst bool = keepfirst
+ if !filterFlags {
+ return flags
+ }
+ for _, flag := range flags {
-+ if strings.HasPrefix(flag, "-m") {
++ if strings.HasPrefix(flag, "-m") || realkeepfirst {
+ newflags = append(newflags, flag)
++ realkeepfirst = false
+ }
+ }
+ return newflags
@@ -129,21 +131,21 @@ index c88b315..a06455c 100644
defaults := "-g -O2"
if cppflags, err = buildFlags("CPPFLAGS", "", p.CgoCPPFLAGS, checkC
Re: [OE-core] [PATCH v2][master] go: Update reproducibility patch to fix panic errors
On 11/29/2022 8:15, Richard Purdie wrote: On Tue, 2022-11-29 at 06:23 -0600, Ryan Eatmon via lists.openembedded.org wrote: Based on a discussion on the mailing list [1], there are panic errors that occur on a few platforms caused by the patch. We cannot simply remove the original patch due to the reproducibility issues that it addresses, so this patch on the original patch fixes the cause of the panic errors. The previous version of this patch was a little too aggressive in cleaning up the environment. Some of the variables impacted by the filerCompilerFlags() function require at least one value to remain in the array. In this case, the values for ccExe, cxxExe, and fcExe require a value or later code that access them result in a panic related to accessing a value out of range. This updated patch adds a flag that requires keeping the first value so that at least one thing remains and the assignments for the Exes set that flag to true. The first item in the array should be the executable name, so leaving it should be safe. I have run the oe-selftest and everything passed in my setup. There is a bug report [2] filed for the issue that this patch addresses. [1] https://lists.openembedded.org/g/openembedded-core/topic/94022663 [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14976 Signed-off-by: Ryan Eatmon --- ...ent-based-hash-generation-less-pedan.patch | 30 ++- 1 file changed, 16 insertions(+), 14 deletions(-) If I remember rightly, the filter function removes anything starting with -m. Are you saying you found a case where the executable itself was called -m The function in the patch actually did the opposite. It only keeps values that start with -m. I think what it was trying to strip out was anything with a path. Personally I think the way the original patch was implemented is like a sledge hammer. Which may be ok with how go integrates into OE, but feels like overkill to me. Cheers, Richard -- Ryan Eatmonreat...@ti.com - Texas Instruments, Inc. - LCPD - MGTS -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173975): https://lists.openembedded.org/g/openembedded-core/message/173975 Mute This Topic: https://lists.openembedded.org/mt/95332822/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 v3][master] go: Update reproducibility patch to fix panic errors
Based on a discussion on the mailing list [1], there are panic
errors that occur on a few platforms caused by the patch. We
cannot simply remove the original patch due to the
reproducibility issues that it addresses, so this patch on the
original patch fixes the cause of the panic errors.
The previous version of this patch was a little too aggressive
in cleaning up the environment. Some of the variables impacted
by the filerCompilerFlags() function require at least one value
to remain in the array. In this case, the values for ccExe,
cxxExe, and fcExe require a value or later code that access
them result in a panic related to accessing a value out of range.
This updated patch adds a flag that requires keeping the first
value so that at least one thing remains and the assignments
for the Exes set that flag to true. The first item in the
array should be the executable name, so leaving it should be
safe.
I have run the oe-selftest and everything passed in my setup.
There is a bug report [2] filed for the issue that this patch
addresses.
[YOCTO #14976]
[1] https://lists.openembedded.org/g/openembedded-core/topic/94022663
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14976
Signed-off-by: Ryan Eatmon
---
v3: Added [YOCTO #14976] to commit message.
v2: Added more background and bug report link to commit message.
...ent-based-hash-generation-less-pedan.patch | 30 ++-
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
index 17fa9d9831..43be5cd2e8 100644
---
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
+++
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
@@ -74,7 +74,7 @@ index c88b315..a06455c 100644
+ cppflags, cflags, cxxflags, fflags, ldflags, _ := b.CFlags(p,
true)
- ccExe := b.ccExe()
-+ ccExe := filterCompilerFlags(b.ccExe())
++ ccExe := filterCompilerFlags(b.ccExe(), true)
fmt.Fprintf(h, "CC=%q %q %q %q\n", ccExe, cppflags, cflags,
ldflags)
// Include the C compiler tool ID so that if the C
// compiler changes we rebuild the package.
@@ -83,7 +83,7 @@ index c88b315..a06455c 100644
}
if len(p.CXXFiles)+len(p.SwigCXXFiles) > 0 {
- cxxExe := b.cxxExe()
-+ cxxExe := filterCompilerFlags(b.cxxExe())
++ cxxExe := filterCompilerFlags(b.cxxExe(), true)
fmt.Fprintf(h, "CXX=%q %q\n", cxxExe, cxxflags)
if cxxID, err := b.gccToolID(cxxExe[0], "c++"); err ==
nil {
fmt.Fprintf(h, "CXX ID=%q\n", cxxID)
@@ -91,7 +91,7 @@ index c88b315..a06455c 100644
}
if len(p.FFiles) > 0 {
- fcExe := b.fcExe()
-+ fcExe := filterCompilerFlags(b.fcExe())
++ fcExe := filterCompilerFlags(b.fcExe(), true)
fmt.Fprintf(h, "FC=%q %q\n", fcExe, fflags)
if fcID, err := b.gccToolID(fcExe[0], "f95"); err ==
nil {
fmt.Fprintf(h, "FC ID=%q\n", fcID)
@@ -104,20 +104,22 @@ index c88b315..a06455c 100644
}
// Configuration specific to compiler toolchain.
-@@ -2705,8 +2707,23 @@ func envList(key, def string) []string {
+@@ -2705,8 +2707,25 @@ func envList(key, def string) []string {
return args
}
+var filterFlags = os.Getenv("CGO_PEDANTIC") == ""
+
-+func filterCompilerFlags(flags []string) []string {
++func filterCompilerFlags(flags []string, keepfirst bool) []string {
+ var newflags []string
++ var realkeepfirst bool = keepfirst
+ if !filterFlags {
+ return flags
+ }
+ for _, flag := range flags {
-+ if strings.HasPrefix(flag, "-m") {
++ if strings.HasPrefix(flag, "-m") || realkeepfirst {
+ newflags = append(newflags, flag)
++ realkeepfirst = false
+ }
+ }
+ return newflags
@@ -129,21 +131,21 @@ index c88b315..a06455c 100644
defaults := "-g -O2"
if cppflags, err = buildFlags("CPPFLAGS", "", p.CgoCPPFLAGS,
checkCompilerFlags); err != nil {
-@@ -2724,6 +2741,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags,
cflags, cxxflags, fflags, l
+@@ -2724,6 +2743,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags,
cflags, cxxflags, fflags, l
if ldflags, err = buildFlags("LDFLAGS", defaults, p.CgoLDFLAGS,
checkLinkerFlags); err != nil {
return
}
+ if filtered {
-+ cppflags = filterCompilerFlags(cppflags)
-+ cflags =
Re: [OE-core] [PATCH v2][master] go: Update reproducibility patch to fix panic errors
I'll send a v3. On 11/29/2022 7:44, Alexander Kanavin wrote: On Tue, 29 Nov 2022 at 14:36, Denys Dmytriyenko wrote: Should be specified here as: [YOCTO #14976] I prefer both. Clickable links help. Alex -- Ryan Eatmonreat...@ti.com - Texas Instruments, Inc. - LCPD - MGTS -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173972): https://lists.openembedded.org/g/openembedded-core/message/173972 Mute This Topic: https://lists.openembedded.org/mt/95332822/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][master] go: Update reproducibility patch to fix panic errors
Based on a discussion on the mailing list [1], there are panic
errors that occur on a few platforms caused by the patch. We
cannot simply remove the original patch due to the
reproducibility issues that it addresses, so this patch on the
original patch fixes the cause of the panic errors.
The previous version of this patch was a little too aggressive
in cleaning up the environment. Some of the variables impacted
by the filerCompilerFlags() function require at least one value
to remain in the array. In this case, the values for ccExe,
cxxExe, and fcExe require a value or later code that access
them result in a panic related to accessing a value out of range.
This updated patch adds a flag that requires keeping the first
value so that at least one thing remains and the assignments
for the Exes set that flag to true. The first item in the
array should be the executable name, so leaving it should be
safe.
I have run the oe-selftest and everything passed in my setup.
There is a bug report [2] filed for the issue that this patch
addresses.
[1] https://lists.openembedded.org/g/openembedded-core/topic/94022663
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14976
Signed-off-by: Ryan Eatmon
---
...ent-based-hash-generation-less-pedan.patch | 30 ++-
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
index 17fa9d9831..43be5cd2e8 100644
---
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
+++
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
@@ -74,7 +74,7 @@ index c88b315..a06455c 100644
+ cppflags, cflags, cxxflags, fflags, ldflags, _ := b.CFlags(p,
true)
- ccExe := b.ccExe()
-+ ccExe := filterCompilerFlags(b.ccExe())
++ ccExe := filterCompilerFlags(b.ccExe(), true)
fmt.Fprintf(h, "CC=%q %q %q %q\n", ccExe, cppflags, cflags,
ldflags)
// Include the C compiler tool ID so that if the C
// compiler changes we rebuild the package.
@@ -83,7 +83,7 @@ index c88b315..a06455c 100644
}
if len(p.CXXFiles)+len(p.SwigCXXFiles) > 0 {
- cxxExe := b.cxxExe()
-+ cxxExe := filterCompilerFlags(b.cxxExe())
++ cxxExe := filterCompilerFlags(b.cxxExe(), true)
fmt.Fprintf(h, "CXX=%q %q\n", cxxExe, cxxflags)
if cxxID, err := b.gccToolID(cxxExe[0], "c++"); err ==
nil {
fmt.Fprintf(h, "CXX ID=%q\n", cxxID)
@@ -91,7 +91,7 @@ index c88b315..a06455c 100644
}
if len(p.FFiles) > 0 {
- fcExe := b.fcExe()
-+ fcExe := filterCompilerFlags(b.fcExe())
++ fcExe := filterCompilerFlags(b.fcExe(), true)
fmt.Fprintf(h, "FC=%q %q\n", fcExe, fflags)
if fcID, err := b.gccToolID(fcExe[0], "f95"); err ==
nil {
fmt.Fprintf(h, "FC ID=%q\n", fcID)
@@ -104,20 +104,22 @@ index c88b315..a06455c 100644
}
// Configuration specific to compiler toolchain.
-@@ -2705,8 +2707,23 @@ func envList(key, def string) []string {
+@@ -2705,8 +2707,25 @@ func envList(key, def string) []string {
return args
}
+var filterFlags = os.Getenv("CGO_PEDANTIC") == ""
+
-+func filterCompilerFlags(flags []string) []string {
++func filterCompilerFlags(flags []string, keepfirst bool) []string {
+ var newflags []string
++ var realkeepfirst bool = keepfirst
+ if !filterFlags {
+ return flags
+ }
+ for _, flag := range flags {
-+ if strings.HasPrefix(flag, "-m") {
++ if strings.HasPrefix(flag, "-m") || realkeepfirst {
+ newflags = append(newflags, flag)
++ realkeepfirst = false
+ }
+ }
+ return newflags
@@ -129,21 +131,21 @@ index c88b315..a06455c 100644
defaults := "-g -O2"
if cppflags, err = buildFlags("CPPFLAGS", "", p.CgoCPPFLAGS,
checkCompilerFlags); err != nil {
-@@ -2724,6 +2741,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags,
cflags, cxxflags, fflags, l
+@@ -2724,6 +2743,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags,
cflags, cxxflags, fflags, l
if ldflags, err = buildFlags("LDFLAGS", defaults, p.CgoLDFLAGS,
checkLinkerFlags); err != nil {
return
}
+ if filtered {
-+ cppflags = filterCompilerFlags(cppflags)
-+ cflags = filterCompilerFlags(cflags)
-+ cxxflags = filterCompilerFlags(cxxflags)
-+ fflags = filterCompilerFlags(fflags)
-+
Re: [OE-core] [PATCH][master] go: Update patch due to build errors
Will do. Thanks.
On 11/28/2022 15:26, Alexander Kanavin wrote:
Ok then you need to place all of this and the bug link into the commit
message, and then you can run the reproducibility test locally, no?
Alex
On Mon, 28 Nov 2022 at 22:22, Denys Dmytriyenko wrote:
On Mon, Nov 28, 2022 at 09:58:43PM +0100, Alexander Kanavin wrote:
What build errors is this addressing and how can they be observed?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14976
On Mon, 28 Nov 2022 at 21:46, Ryan Eatmon via lists.openembedded.org
wrote:
The previous version of this patch was a little too zealous in
cleaning up the envvironment. Some of the variable impacted
by the filerCompilerFlags() function require at least one
value to remain in the array. In this case, the values for
ccExe, cxxExe, and fcExe require a value or it results in
a panic related to accessing a value out of range.
The updated patch adds a flag that requires keeping the first
value so that at least one thing remains and the assignments
for the Exes set that flag to true. The first item in the
array should be the compiler name anyway so it should remain.
Signed-off-by: Ryan Eatmon
---
...ent-based-hash-generation-less-pedan.patch | 30 ++-
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
index 17fa9d9831..43be5cd2e8 100644
---
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
+++
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
@@ -74,7 +74,7 @@ index c88b315..a06455c 100644
+ cppflags, cflags, cxxflags, fflags, ldflags, _ := b.CFlags(p,
true)
- ccExe := b.ccExe()
-+ ccExe := filterCompilerFlags(b.ccExe())
++ ccExe := filterCompilerFlags(b.ccExe(), true)
fmt.Fprintf(h, "CC=%q %q %q %q\n", ccExe, cppflags, cflags,
ldflags)
// Include the C compiler tool ID so that if the C
// compiler changes we rebuild the package.
@@ -83,7 +83,7 @@ index c88b315..a06455c 100644
}
if len(p.CXXFiles)+len(p.SwigCXXFiles) > 0 {
- cxxExe := b.cxxExe()
-+ cxxExe := filterCompilerFlags(b.cxxExe())
++ cxxExe := filterCompilerFlags(b.cxxExe(), true)
fmt.Fprintf(h, "CXX=%q %q\n", cxxExe, cxxflags)
if cxxID, err := b.gccToolID(cxxExe[0], "c++"); err ==
nil {
fmt.Fprintf(h, "CXX ID=%q\n", cxxID)
@@ -91,7 +91,7 @@ index c88b315..a06455c 100644
}
if len(p.FFiles) > 0 {
- fcExe := b.fcExe()
-+ fcExe := filterCompilerFlags(b.fcExe())
++ fcExe := filterCompilerFlags(b.fcExe(), true)
fmt.Fprintf(h, "FC=%q %q\n", fcExe, fflags)
if fcID, err := b.gccToolID(fcExe[0], "f95"); err ==
nil {
fmt.Fprintf(h, "FC ID=%q\n", fcID)
@@ -104,20 +104,22 @@ index c88b315..a06455c 100644
}
// Configuration specific to compiler toolchain.
-@@ -2705,8 +2707,23 @@ func envList(key, def string) []string {
+@@ -2705,8 +2707,25 @@ func envList(key, def string) []string {
return args
}
+var filterFlags = os.Getenv("CGO_PEDANTIC") == ""
+
-+func filterCompilerFlags(flags []string) []string {
++func filterCompilerFlags(flags []string, keepfirst bool) []string {
+ var newflags []string
++ var realkeepfirst bool = keepfirst
+ if !filterFlags {
+ return flags
+ }
+ for _, flag := range flags {
-+ if strings.HasPrefix(flag, "-m") {
++ if strings.HasPrefix(flag, "-m") || realkeepfirst {
+ newflags = append(newflags, flag)
++ realkeepfirst = false
+ }
+ }
+ return newflags
@@ -129,21 +131,21 @@ index c88b315..a06455c 100644
defaults := "-g -O2"
if cppflags, err = buildFlags("CPPFLAGS", "", p.CgoCPPFLAGS,
checkCompilerFlags); err != nil {
-@@ -2724,6 +2741,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags,
cflags, cxxflags, fflags, l
+@@ -2724,6 +2743,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags,
cflags, cxxflags, fflags, l
if ldflags, err = buildFlags("LDFLAGS", defaults, p.CgoLDFLAGS,
checkLinkerFlags); err != nil {
return
}
+ if filtered {
-+ cppflags = filterCompilerFlags(cppflags)
-+
Re: [OE-core] [PATCH][master] go: Update patch due to build errors
Apologies. I'll happily submit a patch v2 that further explains it if
we want to move forward with this patch.
There was a discussion back in September related to some of the TI
machines and the riscv64 machine failing with a panic on recipes in
meta-virtualization that use go.
https://lists.openembedded.org/g/openembedded-core/topic/94022663
I'm seeing these panics as well as I start testing the
meta-ti/meta-arago layers against master so I need to figure it out.
That discussion was trying to just remove the offending patch but there
was a lot of concern related to the reproducibility issue that the patch
was addressing. So I took the time to understand why the panic was
occurring when this patch was in place and updated the patch to
*hopefully* address them both.
This patch needs to be tested to make sure that reproducibility issue is
still working.
On 11/28/2022 14:58, Alexander Kanavin wrote:
What build errors is this addressing and how can they be observed?
Alex
On Mon, 28 Nov 2022 at 21:46, Ryan Eatmon via lists.openembedded.org
wrote:
The previous version of this patch was a little too zealous in
cleaning up the envvironment. Some of the variable impacted
by the filerCompilerFlags() function require at least one
value to remain in the array. In this case, the values for
ccExe, cxxExe, and fcExe require a value or it results in
a panic related to accessing a value out of range.
The updated patch adds a flag that requires keeping the first
value so that at least one thing remains and the assignments
for the Exes set that flag to true. The first item in the
array should be the compiler name anyway so it should remain.
Signed-off-by: Ryan Eatmon
---
...ent-based-hash-generation-less-pedan.patch | 30 ++-
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
index 17fa9d9831..43be5cd2e8 100644
---
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
+++
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
@@ -74,7 +74,7 @@ index c88b315..a06455c 100644
+ cppflags, cflags, cxxflags, fflags, ldflags, _ := b.CFlags(p,
true)
- ccExe := b.ccExe()
-+ ccExe := filterCompilerFlags(b.ccExe())
++ ccExe := filterCompilerFlags(b.ccExe(), true)
fmt.Fprintf(h, "CC=%q %q %q %q\n", ccExe, cppflags, cflags,
ldflags)
// Include the C compiler tool ID so that if the C
// compiler changes we rebuild the package.
@@ -83,7 +83,7 @@ index c88b315..a06455c 100644
}
if len(p.CXXFiles)+len(p.SwigCXXFiles) > 0 {
- cxxExe := b.cxxExe()
-+ cxxExe := filterCompilerFlags(b.cxxExe())
++ cxxExe := filterCompilerFlags(b.cxxExe(), true)
fmt.Fprintf(h, "CXX=%q %q\n", cxxExe, cxxflags)
if cxxID, err := b.gccToolID(cxxExe[0], "c++"); err ==
nil {
fmt.Fprintf(h, "CXX ID=%q\n", cxxID)
@@ -91,7 +91,7 @@ index c88b315..a06455c 100644
}
if len(p.FFiles) > 0 {
- fcExe := b.fcExe()
-+ fcExe := filterCompilerFlags(b.fcExe())
++ fcExe := filterCompilerFlags(b.fcExe(), true)
fmt.Fprintf(h, "FC=%q %q\n", fcExe, fflags)
if fcID, err := b.gccToolID(fcExe[0], "f95"); err ==
nil {
fmt.Fprintf(h, "FC ID=%q\n", fcID)
@@ -104,20 +104,22 @@ index c88b315..a06455c 100644
}
// Configuration specific to compiler toolchain.
-@@ -2705,8 +2707,23 @@ func envList(key, def string) []string {
+@@ -2705,8 +2707,25 @@ func envList(key, def string) []string {
return args
}
+var filterFlags = os.Getenv("CGO_PEDANTIC") == ""
+
-+func filterCompilerFlags(flags []string) []string {
++func filterCompilerFlags(flags []string, keepfirst bool) []string {
+ var newflags []string
++ var realkeepfirst bool = keepfirst
+ if !filterFlags {
+ return flags
+ }
+ for _, flag := range flags {
-+ if strings.HasPrefix(flag, "-m") {
++ if strings.HasPrefix(flag, "-m") || realkeepfirst {
+ newflags = append(newflags, flag)
++ realkeepfirst = false
+ }
+ }
+ return newflags
@@ -129,21 +131,21 @@ index c88b315..a06455c 100644
defaults := "-g -O2"
if cppflags, err = buildFlags(&quo
[OE-core] [PATCH][master] go: Update patch due to build errors
The previous version of this patch was a little too zealous in
cleaning up the envvironment. Some of the variable impacted
by the filerCompilerFlags() function require at least one
value to remain in the array. In this case, the values for
ccExe, cxxExe, and fcExe require a value or it results in
a panic related to accessing a value out of range.
The updated patch adds a flag that requires keeping the first
value so that at least one thing remains and the assignments
for the Exes set that flag to true. The first item in the
array should be the compiler name anyway so it should remain.
Signed-off-by: Ryan Eatmon
---
...ent-based-hash-generation-less-pedan.patch | 30 ++-
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
index 17fa9d9831..43be5cd2e8 100644
---
a/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
+++
b/meta/recipes-devtools/go/go/0001-cmd-go-make-content-based-hash-generation-less-pedan.patch
@@ -74,7 +74,7 @@ index c88b315..a06455c 100644
+ cppflags, cflags, cxxflags, fflags, ldflags, _ := b.CFlags(p,
true)
- ccExe := b.ccExe()
-+ ccExe := filterCompilerFlags(b.ccExe())
++ ccExe := filterCompilerFlags(b.ccExe(), true)
fmt.Fprintf(h, "CC=%q %q %q %q\n", ccExe, cppflags, cflags,
ldflags)
// Include the C compiler tool ID so that if the C
// compiler changes we rebuild the package.
@@ -83,7 +83,7 @@ index c88b315..a06455c 100644
}
if len(p.CXXFiles)+len(p.SwigCXXFiles) > 0 {
- cxxExe := b.cxxExe()
-+ cxxExe := filterCompilerFlags(b.cxxExe())
++ cxxExe := filterCompilerFlags(b.cxxExe(), true)
fmt.Fprintf(h, "CXX=%q %q\n", cxxExe, cxxflags)
if cxxID, err := b.gccToolID(cxxExe[0], "c++"); err ==
nil {
fmt.Fprintf(h, "CXX ID=%q\n", cxxID)
@@ -91,7 +91,7 @@ index c88b315..a06455c 100644
}
if len(p.FFiles) > 0 {
- fcExe := b.fcExe()
-+ fcExe := filterCompilerFlags(b.fcExe())
++ fcExe := filterCompilerFlags(b.fcExe(), true)
fmt.Fprintf(h, "FC=%q %q\n", fcExe, fflags)
if fcID, err := b.gccToolID(fcExe[0], "f95"); err ==
nil {
fmt.Fprintf(h, "FC ID=%q\n", fcID)
@@ -104,20 +104,22 @@ index c88b315..a06455c 100644
}
// Configuration specific to compiler toolchain.
-@@ -2705,8 +2707,23 @@ func envList(key, def string) []string {
+@@ -2705,8 +2707,25 @@ func envList(key, def string) []string {
return args
}
+var filterFlags = os.Getenv("CGO_PEDANTIC") == ""
+
-+func filterCompilerFlags(flags []string) []string {
++func filterCompilerFlags(flags []string, keepfirst bool) []string {
+ var newflags []string
++ var realkeepfirst bool = keepfirst
+ if !filterFlags {
+ return flags
+ }
+ for _, flag := range flags {
-+ if strings.HasPrefix(flag, "-m") {
++ if strings.HasPrefix(flag, "-m") || realkeepfirst {
+ newflags = append(newflags, flag)
++ realkeepfirst = false
+ }
+ }
+ return newflags
@@ -129,21 +131,21 @@ index c88b315..a06455c 100644
defaults := "-g -O2"
if cppflags, err = buildFlags("CPPFLAGS", "", p.CgoCPPFLAGS,
checkCompilerFlags); err != nil {
-@@ -2724,6 +2741,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags,
cflags, cxxflags, fflags, l
+@@ -2724,6 +2743,13 @@ func (b *Builder) CFlags(p *load.Package) (cppflags,
cflags, cxxflags, fflags, l
if ldflags, err = buildFlags("LDFLAGS", defaults, p.CgoLDFLAGS,
checkLinkerFlags); err != nil {
return
}
+ if filtered {
-+ cppflags = filterCompilerFlags(cppflags)
-+ cflags = filterCompilerFlags(cflags)
-+ cxxflags = filterCompilerFlags(cxxflags)
-+ fflags = filterCompilerFlags(fflags)
-+ ldflags = filterCompilerFlags(ldflags)
++ cppflags = filterCompilerFlags(cppflags, false)
++ cflags = filterCompilerFlags(cflags, false)
++ cxxflags = filterCompilerFlags(cxxflags, false)
++ fflags = filterCompilerFlags(fflags, false)
++ ldflags = filterCompilerFlags(ldflags, false)
+ }
return
}
-@@ -2739,7 +2763,7 @@ var cgoRe = lazyregexp.New(`[/\\:]`)
+@@ -2739,7 +2765,7 @@ var cgoRe = lazyregexp.New(`[/\\:]`)
func (b *Builder) cgo(a *Action, cgoExe, objdir string, pcCFLAGS,
