Date   

Re: [meta-mingw] [PATCH] grpc: use the new PACKAGECONFIG to disable shared

Joshua Watt
 

On 8/24/21 11:48 AM, Sinan Kaya wrote:
There is a new PACKAGECONFIG for grpc to allows us
to selectively enable/disable shared builds.

Signed-off-by: Sinan Kaya <okaya@...>
---
.../openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
index dc0ea42..4cbd1a4 100644
--- a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
+++ b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
@@ -1,5 +1,4 @@
# doesn't build and not required
DEPENDS:remove:mingw32 = "libnsl2"
-EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON"
-EXTRA_OECMAKE:append:mingw32 = " -DBUILD_SHARED_LIBS=OFF"
+PACKAGECONFIG:remove:mingw32 = "shared"
This is good, thanks. Is the libnsl2 also tied to some feature? Perhaps you can explain why it needs to be removed from MinGW


Re: [PATCH v2 ptest-runner 2/2] main: Do not return number of failed tests when calling ptest-runner

?ukasz Majewski
 

Hi Anibal,

Up till now ptest-runner2 returns number of failed tests with its
exit status code. Such use case is not recommended [1] and may cause
issues when there are more than 256 tests to be executed.

To alleviate this issue the number of total tests with number of
failed ones is printed before exit. To be more specific - failure of
tests (one or more) causes ptest-runner to provide exit code of 1.

One can test this change with executing:
./ptest-runner -d tests/data fail
Gentle ping on this patch.


Links:
[1] -
https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html

Signed-off-by: Lukasz Majewski <lukma@...>
---
Changes for v2:
- When number of failed tests is N, the ptest-runner returns value of
1 to indicate error in the execution
---
main.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/main.c b/main.c
index 890bc6a..bcec844 100644
--- a/main.c
+++ b/main.c
@@ -220,6 +220,9 @@ main(int argc, char *argv[])
ptest_list_remove(run, opts.exclude[i], 1);

rc = run_ptests(run, opts, argv[0], stdout, stderr);
+ fprintf(stdout, "TOTAL: %d FAIL: %d\n",
ptest_list_length(run), rc);
+ if (rc > 0)
+ rc = 1;

ptest_list_free_all(&run);



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...


Re: building mbpoll

Josef Holzmayr
 

(re-adding list)

Am 27.08.2021 um 11:17 schrieb Ivan Riabtsov:
maybe mbpoll is not cloned? I found the custom-rts.c file on the
mbpoll website and try to search for it in the build directory, but I
can't find anything
my mbpoll_1.4.11.bb file:
SUMMARY = "bitbake-layers recipe"
DESCRIPTION = "mbpoll recipe"
LICENSE = "CLOSED"
SRC_URI = "git://github.com/epsilonrt/mbpoll"
SRCREV = "2bf602817370000e69221eb50c4ece813d10c0b4"
DEPENDS = "libmodbus"
S = "${WORKDIR}/git"
inherit pkgconfig cmake
again, any particular reason why you're poking the recipe by hand instead of just using devtool (which perfectly works in this case)? it would even give you a good start on the licenses, as well as not having missed the inherits.

Greetz


Re: building mbpoll

Josef Holzmayr
 

Howdy!

Am 27.08.2021 um 10:10 schrieb Ivan Riabtsov:
Hi All. i need to build mbpoll git://github.com/epsilonrt/mbpoll
I was created layer:
ivr@home-machine:~/work/yocto_orig/sources/meta-mbpoll/recipes-mbpoll/mbpoll
$ cat mbpoll_1.4.11.bb
SUMMARY = "bitbake-layers recipe"
DESCRIPTION = "mbpoll recipe"
LICENSE = "CLOSED"
SRC_URI = "git://github.com/epsilonrt/mbpoll"
SRCREV = "2b385d85d919138cefe79870c87c60eaa8b0d19c"
DEPENDS = "libmodbus"
if thats all of the recipe, then nothing will be built. you probably want to include at least the class for the buildsystem that you need, for example autotools, cmake, meson...

usually devtool is quite good at guessing that, so i'd suggest to start out with "devtool add"

Greetz

i was run:
rm -rf ./build/tmp ./build/sstate-cache ./build/deploy
and
bitbake mbpoll
i am trying to search for a package
ivr@home-machine:~/work/yocto_orig/build
$ find . -name 'mbpoll*.ipk'
./tmp/work/cortexa7t2hf-neon-vfpv4-phytec-linux-gnueabi/mbpoll/1.4.11-r0/deploy-ipks/cortexa7t2hf-neon-vfpv4/mbpoll-dev_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./tmp/work/cortexa7t2hf-neon-vfpv4-phytec-linux-gnueabi/mbpoll/1.4.11-r0/deploy-ipks/cortexa7t2hf-neon-vfpv4/mbpoll-dbg_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./deploy/ipk/cortexa7t2hf-neon-vfpv4/mbpoll-dev_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./deploy/ipk/cortexa7t2hf-neon-vfpv4/mbpoll-dbg_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
but i have only debug and dev packages, not simple mbpoll_version.ipk
i try to run:
bitbake -c clean mbpoll --force
and
bitbake mbpoll --force
but the task is done in a 1 second and
$ find . -name 'mbpoll*.ipk'
./tmp/work/cortexa7t2hf-neon-vfpv4-phytec-linux-gnueabi/mbpoll/1.4.11-r0/deploy-ipks/cortexa7t2hf-neon-vfpv4/mbpoll-dev_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./tmp/work/cortexa7t2hf-neon-vfpv4-phytec-linux-gnueabi/mbpoll/1.4.11-r0/deploy-ipks/cortexa7t2hf-neon-vfpv4/mbpoll-dbg_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./deploy/ipk/cortexa7t2hf-neon-vfpv4/mbpoll-dev_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./deploy/ipk/cortexa7t2hf-neon-vfpv4/mbpoll-dbg_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
found nothing
please tell me what am I doing wrong? Maybe I created the layer incorrectly?


building mbpoll

Ivan Riabtsov <ivriabtsov@...>
 

Hi All. i need to build mbpoll git://github.com/epsilonrt/mbpoll
I was created layer:

ivr@home-machine:~/work/yocto_orig/sources/meta-mbpoll/recipes-mbpoll/mbpoll
$ cat mbpoll_1.4.11.bb
SUMMARY = "bitbake-layers recipe"
DESCRIPTION = "mbpoll recipe"
LICENSE = "CLOSED"

SRC_URI = "git://github.com/epsilonrt/mbpoll"
SRCREV = "2b385d85d919138cefe79870c87c60eaa8b0d19c"

DEPENDS = "libmodbus"

i was run:
rm -rf ./build/tmp ./build/sstate-cache ./build/deploy
and
bitbake mbpoll

i am trying to search for a package

ivr@home-machine:~/work/yocto_orig/build
$ find . -name 'mbpoll*.ipk'
./tmp/work/cortexa7t2hf-neon-vfpv4-phytec-linux-gnueabi/mbpoll/1.4.11-r0/deploy-ipks/cortexa7t2hf-neon-vfpv4/mbpoll-dev_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./tmp/work/cortexa7t2hf-neon-vfpv4-phytec-linux-gnueabi/mbpoll/1.4.11-r0/deploy-ipks/cortexa7t2hf-neon-vfpv4/mbpoll-dbg_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./deploy/ipk/cortexa7t2hf-neon-vfpv4/mbpoll-dev_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./deploy/ipk/cortexa7t2hf-neon-vfpv4/mbpoll-dbg_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk

but i have only debug and dev packages, not simple mbpoll_version.ipk

i try to run:
bitbake -c clean mbpoll --force
and
bitbake mbpoll --force
but the task is done in a 1 second and

$ find . -name 'mbpoll*.ipk'
./tmp/work/cortexa7t2hf-neon-vfpv4-phytec-linux-gnueabi/mbpoll/1.4.11-r0/deploy-ipks/cortexa7t2hf-neon-vfpv4/mbpoll-dev_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./tmp/work/cortexa7t2hf-neon-vfpv4-phytec-linux-gnueabi/mbpoll/1.4.11-r0/deploy-ipks/cortexa7t2hf-neon-vfpv4/mbpoll-dbg_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./deploy/ipk/cortexa7t2hf-neon-vfpv4/mbpoll-dev_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk
./deploy/ipk/cortexa7t2hf-neon-vfpv4/mbpoll-dbg_1.4.11-r0_cortexa7t2hf-neon-vfpv4.ipk

found nothing

please tell me what am I doing wrong? Maybe I created the layer incorrectly?


[PATCH] meta-integrity: kernel-modsign: Change weak default value

Daiane Angolini
 

Assign a weak default value for MODSIGN_KEY_DIR so the other layers can
set a default value for them as well.

Signed-off-by: Daiane Angolini <daiane.angolini@...>
---
meta-integrity/classes/kernel-modsign.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-integrity/classes/kernel-modsign.bbclass b/meta-integrity/classes/kernel-modsign.bbclass
index cf5d3eb..093c358 100644
--- a/meta-integrity/classes/kernel-modsign.bbclass
+++ b/meta-integrity/classes/kernel-modsign.bbclass
@@ -2,7 +2,7 @@
# set explicitly in a local.conf before activating kernel-modsign.
# To use the insecure (because public) example keys, use
# MODSIGN_KEY_DIR = "${INTEGRITY_BASE}/data/debug-keys"
-MODSIGN_KEY_DIR ?= "MODSIGN_KEY_DIR_NOT_SET"
+MODSIGN_KEY_DIR ??= "MODSIGN_KEY_DIR_NOT_SET"

# Private key for modules signing. The default is okay when
# using the example key directory.
--
2.30.2


[PATCH] parselogs.py: ignore intermittent CD/DVDROM identification failure

Bruce Ashfield
 

From: Bruce Ashfield <bruce.ashfield@...>

We don't use the CD/DVD ROM drive in any of our tests, but it
periodically fails discovery and that leads to a QA error:

[ 6.403477] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)

The only way to disable the optical ROM drive in qemu is to use
the '-nodefaults' option, which disables the CDROM (among other things).
We can't be sure that none of our tests, or extended users are relying
on default devices, so using that option is more of a risk than adding
the message to our ignore list.

To date, no one has sent a patch to just disable the optical drive
(either in qemu or the BIOS), but that is something we could consider
in the future.

[YOCTO #14528]

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
meta/lib/oeqa/runtime/cases/parselogs.py | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py
index af8a8d67bd..5db0216597 100644
--- a/meta/lib/oeqa/runtime/cases/parselogs.py
+++ b/meta/lib/oeqa/runtime/cases/parselogs.py
@@ -98,6 +98,7 @@ ignore_errors = {
'qemux86' : [
'Failed to access perfctr msr (MSR',
'pci 0000:00:00.0: [Firmware Bug]: reg 0x..: invalid BAR (can\'t size)',
+ 'failed to IDENTIFY (I/O error, err_mask=0x4)',
] + qemux86_common,
'qemux86-64' : qemux86_common,
'qemumips' : [
--
2.19.1


Minutes: Yocto Project Weekly Triage Meeting 8/26/2021

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alex, Armin, Bruce, Joshua, Randy, Richard, Saul, Stephen, Steve, Tim, Trevor

ARs:

N/A

Notes:

- (carried over) Steve encountered build failures such as the one in https://errors.yoctoproject.org/Errors/Details/593109/ when attempting to run dunfell builds with the PARALLEL_MAKE load averaging added. WR is testing/investigating on internal Autobuilder instance - Trevor is still planning on looking into this!

Medium+ 3.4 Unassigned Enhancements/Bugs: 77 (Last week 76)

Medium+ 3.99 Unassigned Enhancements/Bugs: 38 (Last week 36)

AB-INT Bugs: 48 (Last week 46)


Re: Run an executable script on the yocto image

Konrad Weihmann <kweihmann@...>
 

If you're sure you only use standard python libs it's fairly easy.

make a recipe (name it how ever you like)

SCR_URI = "file://<your script>.py"

do_install() {
install -m 0755 <your script>.py ${bindir}/<your script>.py
}

RDEPENDS:${PN} += "python3-core"

in the image

IMAGE_INSTALL += "<your recipe name>"

---

if your script needs further libraries, reference them in the recipe with

RDEPENDS:${PN} += "python3-core dependency1 dependency2 dependency3..."

Then you call the result on your device with <your script>.py from any console

Maybe add a "#!/usr/bin/env python3" shebang as a first line to your script

On 26.08.21 17:14, yasminebenghozzi6@... wrote:
Hello,
Can anyone suggest how to make a python script executable on the yocto image? I 've been trying with the pyinstaller but didn't work, I made it executable on my laptop and transfer it to yocto image but didn't work also,
Has any one tried it before? are there other alternatives?


Run an executable script on the yocto image

yasminebenghozzi6@...
 

Hello, 

Can anyone suggest how to make a python script executable on the yocto image? I 've been trying with the pyinstaller but didn't work, I made it executable on my laptop and transfer it to yocto image but didn't work also, 
Has any one tried it before? are there other alternatives? 


Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: Aug 26, 2021

Randy MacLeod
 

YP AB Intermittent failures meeting
===================================
Aug 26, 2021, 9 AM ET
https://windriver.zoom.us/j/3696693975

Attendees: Tony, Richard, Trevor, Randy, Alex, Saul, Sakib!


Summary:
========

It was a rough week for testing due to glibc-2.34 and rust
problems so we'll see if the next week let's us return to:
ptest results continue to improve but there's still room
for even more improvement.

The make/ninja load average limit is in but it's not clear
if it's effective yet and it breaks dunfell. Trevor investigating
(Aug 26!).

There's not much new this week, I've commented on a few existing
activities below and added "Aug 26" in most cases.


If anyone wants to help, we could use more eyes on the logs,
particularly the summary logs and understanding iostat #
when the dd test times out.



Plans for the week:
===================

Richard: biking and wait for QA results for M3.
Alex: SWAT plans. September email, training. libevent monotonic fix!
Sakib: hook more responsive load average in to latency test. (v3)
Trevor: patch to set PARALLEL_MAKE : -l 50
-> dunfell, gatesgarth, hardknott (Aug 5 - it's a priority)
Investigate dunfell which failed with this change.
- data on WR AB load average.
Saul: none
Randy: Gather more iostat data, graph it!

Meeting Notes:
==============

1. job server

- ninja could be patched with make's more responsive algorithm
next or is this good enough?

Aug 26:
Randy made some graphs that show that the -l NUM results
in the number of compile jobs oscillates *wildly* between 0 and 200
on a 192 core builder compiling chromium. What I did was:
$ bitbake -c cleansstate chromium-x11
$ bitbake -c configure chromium-x11
$ bitbake -c compile chromium-x11
and while that compile was running:
$ while [ ! -f /tmp/compiling-chromium-is-done ]; do \
cat /proc/loadavg >> procs-load.log ; sleep 0.5 ;
done
Results so far:
https://postimg.cc/gallery/3hjfYfG/f8f46c97
Next step is either:
a. collect data as above for an image build and see if the sub-optimal
ninja behaviour makes a difference
and/or
b. patch ninja with make's more responsive load avg
algorithm:
https://git.savannah.gnu.org/cgit/make.git/commit/?id=d8728efc8


- Richard suggested that we extract make's code for measuring the load
average to a separate binary and run it in the periodic io latency
test. Also can we translate it to python?
- Trevor is working on this and had some problems so next week.
(Aug 19 - Trevor is back from vaction so maybe next week.)

- Trevor to see if the load average change really did reduce load
on WR build systems. (Aug 19)

2. AB status

Trevor is learning about buildbot and working on a scheduling bug
(CentOS worker?)

bitbake layer setup tool should allow multiple backends:
eg: kas, a y-a-helper.

ptest cases are improving, we may be close to done!
Let's wait a week to see how things go.
(July29, Aug 5, Aug 19, we're not done...)

- lttng-tools ptest is failing. RP is working on it with upstream.
The timeout (done on Aug 5) increase hasn't helped.


3. Sakib's improvements to the logging are merged.

Sakib generated a summary of all high latency 'top' logs from
~July 23->July 29 by just running his summary script on the
merged raw top logs.

More analysis required....


Still relevant parts of
Previous Meeting Notes:
=======================


4. bitbake server timeout ( no change july 29, Aug 19)

"Timeout while waiting for a reply from the bitbake server (60s)"

5. io stalls (no update: July 29)

Richard said that it would make sense to write an ftrace utility
/ script to monitor io latency and we could install it with sudo
Ch^W mentioned ftrace on IRC.
Sakib and Randy will work on that but not for a week or two
or longer! (Aug 19).

Randy collected iostat data on 3 build server:
https://postimg.cc/gallery/8cN6LYB
We agreed that having -ty-2 be ~ 100 utilization for many hours
in a row is not acceptable and that a threshold of ~ 10 minutes
at 100% utilization may be a reasonable limt. I need to figure out
if I can get data on the fraction of IO done per IO clas since
we do use ionice to do clean-up and other activities.


../Randy


Re: Parserror while building the image #yocto

Martin Jansa
 

Update bitbake to support new overrides syntax.


On Thu, Aug 26, 2021 at 3:28 PM <yasminebenghozzi6@...> wrote:
I got this error while trying to build the image after checking out the timo/python3-pyinstaller.
ERROR: ParseError at /home/yasmine/yocto/poky/meta-openembedded/meta-oe/conf/layer.conf:106: unparsed line: 'DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = "${PTESTTESTSUITE}"'
 




Parserror while building the image #yocto

yasminebenghozzi6@...
 

I got this error while trying to build the image after checking out the timo/python3-pyinstaller.
ERROR: ParseError at /home/yasmine/yocto/poky/meta-openembedded/meta-oe/conf/layer.conf:106: unparsed line: 'DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = "${PTESTTESTSUITE}"'
 


Re: Dependencies are not resolved correctly when building the SDK

asconcepcion
 

Please post the exact error that you're getting.
Sorry, I haven't posted the exact error because I thought it is quite specific to the recipe I'm building. My first question was also too vague, sorry for that. The problem is that it fails in building that package because of a missing file that should be populated by that dependency.

The error happens in the do_compile task:

| make[1]: *** No rule to make target 'm4_image.bin', needed by 'flash_linux_m40'.  Stop.                                                                                                                             
| make: *** [Makefile:23: flash_linux_m40] Error 2                                                                                                                                                                    
| WARNING: exit code 2 from a shell command.
So, the package expects that the file 'm4_image.bin' exists, and this file is generated by the dependency (it works well when building the yocto image, but not when building the SDK from scratch).

Thanks,
Alejandro


Re: Dependencies are not resolved correctly when building the SDK

Anuj Mittal
 

On Thu, 2021-08-26 at 00:44 -0700, asconcepcion wrote:
Hi Anuj,

Thanks for the tip. I added "BBCLASSEXTEND += "nativesdk"" to the
recipe of the dependency package, but I still get the same error. Do
you know if I could be missing something else?
Please post the exact error that you're getting.

Thanks,

Anuj


Re: Dependencies are not resolved correctly when building the SDK

asconcepcion
 

Hi Anuj,

Thanks for the tip. I added "BBCLASSEXTEND += "nativesdk"" to the recipe of the dependency package, but I still get the same error. Do you know if I could be missing something else?

Thanks.
Alejandro.


Re: Dependencies are not resolved correctly when building the SDK

Anuj Mittal
 

On Wed, 2021-08-25 at 23:54 -0700, asconcepcion wrote:
Hello,

We have a custom package recipe that has a build dependency with
another one (defined in yocto with the DEPENDS variable). If we build
an image that includes that package, bitbake will build the
dependency
before building the package, as expected. However, if we build the
SDK
associated to that image (with bitbake <image> -c populate_sdk), it
will fail in building that package because of a missing dependency.
Does anyone know what could be causing this behavior?
Can that recipe for dependency package actually be built for nativesdk?

Thanks,

Anuj


Dependencies are not resolved correctly when building the SDK

asconcepcion
 

Hello,

We have a custom package recipe that has a build dependency with another one (defined in yocto with the DEPENDS variable). If we build an image that includes that package, bitbake will build the dependency before building the package, as expected. However, if we build the SDK associated to that image (with bitbake <image> -c populate_sdk), it will fail in building that package because of a missing dependency. Does anyone know what could be causing this behavior?

Thanks.


Re: # yocto Fatal QA error (LIC_FILES_CHKSUM) [license-checksum]

Monsees, Steven C (US)
 

 

Never mind this, I worked it out…  thanks anyway.

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, August 25, 2021 12:25 PM
To: yocto@...
Subject: [yocto] # yocto Fatal QA error (LIC_FILES_CHKSUM) [license-checksum]

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

Using zeus, and I am build an image with no issues...

 

I then want to tweak the configuration by pulling in an a ".cfg" file to be able to tweak options depending on use…

 

I add the following to the image ".bb" file:

 

FILESEXTRAPATHS_prepend := "$THISDIR:"

SRC_URI += "file://sbcb-defaultfs-swdebug.cfg"

 

 

sbcb-defaultfs-swdebug.cfg consists of three lines:

 

CONFIG_KPROBES=y

CONFIG_KPROBES_ON_FTRACE=y

CONFIG_DEBUG_INFO=y

 

When I add the above I see the following build issue, how do I relove this ?

 

ERROR: sbcb-defaultfs-swdebug-1.0-r0 do_populate_lic: QA Issue: sbcb-defaultfs-swdebug: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]

ERROR: sbcb-defaultfs-swdebug-1.0-r0 do_populate_lic: Fatal QA errors found, failing task.

ERROR: Logfile of failure stored in: /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-swdebug/1.0-r0/temp/log.do_populate_lic.29324

ERROR: Task (/disk0/scratch/smonsees/yocto/workspace_1/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-swdebug.bb:do_populate_lic) failed with exit code '1'

 

Thanks,

Steve


# yocto Fatal QA error (LIC_FILES_CHKSUM) [license-checksum]

Monsees, Steven C (US)
 

 

Using zeus, and I am build an image with no issues...

 

I then want to tweak the configuration by pulling in an a ".cfg" file to be able to tweak options depending on use…

 

I add the following to the image ".bb" file:

 

FILESEXTRAPATHS_prepend := "$THISDIR:"

SRC_URI += "file://sbcb-defaultfs-swdebug.cfg"

 

 

sbcb-defaultfs-swdebug.cfg consists of three lines:

 

CONFIG_KPROBES=y

CONFIG_KPROBES_ON_FTRACE=y

CONFIG_DEBUG_INFO=y

 

When I add the above I see the following build issue, how do I relove this ?

 

ERROR: sbcb-defaultfs-swdebug-1.0-r0 do_populate_lic: QA Issue: sbcb-defaultfs-swdebug: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]

ERROR: sbcb-defaultfs-swdebug-1.0-r0 do_populate_lic: Fatal QA errors found, failing task.

ERROR: Logfile of failure stored in: /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-swdebug/1.0-r0/temp/log.do_populate_lic.29324

ERROR: Task (/disk0/scratch/smonsees/yocto/workspace_1/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-swdebug.bb:do_populate_lic) failed with exit code '1'

 

Thanks,

Steve