Date   

[meta-rockchip][PATCH] layer.conf: Add hardknott to compatible release branches

Khem Raj
 

Signed-off-by: Khem Raj <raj.khem@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 8eecdc5..db9961c 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,5 +14,5 @@ BBFILE_PRIORITY_rockchip =3D "1"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_rockchip =3D "1"
-LAYERSERIES_COMPAT_rockchip =3D "gatesgarth"
+LAYERSERIES_COMPAT_rockchip =3D "gatesgarth hardknott"
LAYERDEPENDS_rockchip =3D "core meta-arm"
--=20
2.31.0


Re: Recipes and meta-data directory tree

Tim Orling
 



On Wed, Mar 17, 2021 at 6:16 PM Khem Raj <raj.khem@...> wrote:
On Wed, Mar 17, 2021 at 9:43 AM keydi <krzysztof.dudziak@...> wrote:
>
> Two projects are given. They use different YP release each.
> Projects use also different target platform each.
>
> I wonder if differences in structuring metadata- and recipes- directory tree between
> these two projects result solely from different YP releases in use.
> Or if these can be a result also of modifications conducted by platform vendors.
>
> Any hints in what extend these result from different YP release numbers in use?
>
> project A (YP release 2.6)
> xxxx /yocto/
> xxxx/yocto/downloads
> xxxx/yocto/meta
> xxxx/yocto/sstate-cache
> xxxx/yocto/build
> xxxx/yocto/.repo
> xxxx/yocto/src
> xxxx/yocto/prebuilt
> xxxx/yocto/meta/
> xxxx/yocto/meta/poky
> xxxx/yocto/meta/meta-security
> xxxx/yocto/meta/meta-clang
> xxxx/yocto/meta/meta-openembedded
> xxxx/yocto/meta/poky/
> xxxx/yocto/meta/poky/meta
> xxxx/yocto/meta/poky/documentation
> xxxx/yocto/meta/poky/meta-poky
> xxxx/yocto/meta/poky/meta-selftest
> xxxx/yocto/meta/poky/bitbake
> xxxx/yocto/meta/poky/.git
> xxxx/yocto/meta/poky/meta-yocto-bsp
> xxxx/yocto/meta/poky/meta-skeleton
> xxxx/yocto/meta/poky/scripts
> + a set of layers value chain specific, meta-... subdirectories with meta/  as root-point.
>
> project B (YP release 2.0, actually backport of some later release
> which unfortunately is not reflected in poky.conf)
> yyyy/poky/
> yyyy/poky/meta-yocto
> yyyy/poky/meta
> yyyy/poky/documentation
> yyyy/poky/meta-selftest
> yyyy/poky/meta-selinux
> yyyy/poky/build
> yyyy/poky/meta-cust-installer
> yyyy/poky/bitbake
> yyyy/poky/meta-yocto-bsp
> yyyy/poky/meta-skeleton
> yyyy/poky/scripts
> + a set of layers value chain specific, meta-... subdirectories with poky/  as root-point.
>
> I mean mainly following differences:
> * Project A places a set of value-chain specific layers/meta-... directories at same
> directory level as poky.
> * meta-yocto apparently not present in project A tree
> * meta-poky apparently not present in project B tree

OE allows you to build own distributions, so what you are looking at
is two different distributions based on different
different releases but using same build system ( OpenEmbedded ) over
major releases the build system gets changed
too in terms of its metadata as well new features and some old cruft
removed like usual projects. so you have different
releases, and different machines and different distro all contributing
to the differences.

and meta-yocto was renamed to meta-poky in one of those changes at the request of the members and community.


>
>
>




Re: Recipes and meta-data directory tree

Khem Raj
 

On Wed, Mar 17, 2021 at 9:43 AM keydi <krzysztof.dudziak@...> wrote:

Two projects are given. They use different YP release each.
Projects use also different target platform each.

I wonder if differences in structuring metadata- and recipes- directory tree between
these two projects result solely from different YP releases in use.
Or if these can be a result also of modifications conducted by platform vendors.

Any hints in what extend these result from different YP release numbers in use?

project A (YP release 2.6)
xxxx /yocto/
xxxx/yocto/downloads
xxxx/yocto/meta
xxxx/yocto/sstate-cache
xxxx/yocto/build
xxxx/yocto/.repo
xxxx/yocto/src
xxxx/yocto/prebuilt
xxxx/yocto/meta/
xxxx/yocto/meta/poky
xxxx/yocto/meta/meta-security
xxxx/yocto/meta/meta-clang
xxxx/yocto/meta/meta-openembedded
xxxx/yocto/meta/poky/
xxxx/yocto/meta/poky/meta
xxxx/yocto/meta/poky/documentation
xxxx/yocto/meta/poky/meta-poky
xxxx/yocto/meta/poky/meta-selftest
xxxx/yocto/meta/poky/bitbake
xxxx/yocto/meta/poky/.git
xxxx/yocto/meta/poky/meta-yocto-bsp
xxxx/yocto/meta/poky/meta-skeleton
xxxx/yocto/meta/poky/scripts
+ a set of layers value chain specific, meta-... subdirectories with meta/ as root-point.

project B (YP release 2.0, actually backport of some later release
which unfortunately is not reflected in poky.conf)
yyyy/poky/
yyyy/poky/meta-yocto
yyyy/poky/meta
yyyy/poky/documentation
yyyy/poky/meta-selftest
yyyy/poky/meta-selinux
yyyy/poky/build
yyyy/poky/meta-cust-installer
yyyy/poky/bitbake
yyyy/poky/meta-yocto-bsp
yyyy/poky/meta-skeleton
yyyy/poky/scripts
+ a set of layers value chain specific, meta-... subdirectories with poky/ as root-point.

I mean mainly following differences:
* Project A places a set of value-chain specific layers/meta-... directories at same
directory level as poky.
* meta-yocto apparently not present in project A tree
* meta-poky apparently not present in project B tree
OE allows you to build own distributions, so what you are looking at
is two different distributions based on different
different releases but using same build system ( OpenEmbedded ) over
major releases the build system gets changed
too in terms of its metadata as well new features and some old cruft
removed like usual projects. so you have different
releases, and different machines and different distro all contributing
to the differences.




Re: subtree …/tmp/deploy/… , files named Packages

Khem Raj
 

On Tue, Mar 16, 2021 at 8:53 AM keydi <krzysztof.dudziak@...> wrote:

Hello,

This is about two projects Projects A and B. Both use Yocto to build embedded-Linux distribution. However different Yocto release each. Also different target platform each. One puts Linux software packages to RPM, another one to IPK. For only one of those two Yocto generates plain-text files named 'Packages' and places it to image subdirectories of /tmp/deploy/rpm or /tmp/deploy/ipk subtree. The another one doesn't. Is this (files 'Packages' to be generated or not) any configuration point platform vendor can had set for its code-base to non-standard setting? Any means available for project Packages files (as of time being) not being generated to activate these files generation?

Background: Tool-chain used here to generate software bill of materials and all artifacts needed for fulfillment of used software license terms processes these files. Might it be good/bad idea to use files addressed in this message for software composition evaluation?
what you are looking at is feeds area, where the format will vary
depending upon which online package management is in use. So you will
have to make that differentiation. Packages file is used when opkg is
used and not by rpm/dnf
for SCA perhaps you want to look at content of the packages. or maybe
use the manifests that yocto generates e.g. license manifest in images
have info on all packages that go into that image, it may not be
formatted as per your expectation
but its somewhere to start






Re: Avahi in yocto #yocto

Randy MacLeod
 

On 2021-03-16 3:20 a.m., lavkhush2208@... wrote:
I am getting issue in Avahi
*Issue- trying to remove PID file.(/run/avahi-daemon/ /pid)
*Due to this issue, i am not able to get "Service name" on host machine. please help me.
Hello,

It's a bit hard to know where to start without more information.

Can you tell us what release, layers and hardware you are using?
Are you able to reproduce the problem using runqemu ?
Are you able to reproduce the problem in poky/master or
a supported branch:
https://wiki.yoctoproject.org/wiki/Releases ?

What conf/local.conf changes have you made?

What steps and commands do you run to see the error?

../Randy


--
# Randy MacLeod
# Wind River Linux


Re: subtree …/tmp/deploy/… , files named Packages

keydi <krzysztof.dudziak@...>
 

One more question: plain-text files named 'Packages' and placed during distribution build in subtrees tmp/deploy/rpm, .../ipk, ... are these artifacts supported YP releases can still build? 


do_populate_cve_db CERTIFICATE_VERIFY_FAILED

Darcy Watkins
 

Hi,

 

Anyone else encounter this?

 

WARNING: cve-update-db-native-1.0-r0 do_populate_cve_db: Failed to fetch CVE data ([SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1108))

 

I am not sure how to resolve this.  After googling on the subject, I found nothing really helpful.  Most hits suggest that the certificates are out of date.  I tried various suggested ways to resolve it, but nothing works.

 

Furthermore, as I dig into this, it becomes apparent that this could be confused by the different python3 that are on the system.  ‘which python3’ points to a python3 that is in the buildtools.  So I have a python3 from my CentOS 7 distro, there appears to be one as part of the buildtools (needed when you use CentOS).  Then there is python3-native and finally the python3 that is built for the target.

 

I suspect that this may be related to the python3 in the buildtools.  Anyone using a newer distro not requiring buildtools may not be affected.

 

I am using CentOS7, Yocto ‘dunfell’ (including the buildtools) and building for an NXP Layerscape target.  This particular build adds meta-security and the meta-security-isafw sub-layer (along with prerequisites).

 

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[M4]

dwatkins@... :: www.sierrawireless.com


spidev.c ?

jchludzinski
 

In the YOCTO/Linux source tree there's drivers/spi/ which has all the source for SPI drivers. There's only 1 file, spidev.c, which has:
 


Recipes and meta-data directory tree

keydi <krzysztof.dudziak@...>
 

Two projects are given. They use different YP release each.
Projects use also different target platform each.

I wonder if differences in structuring metadata- and recipes- directory tree between
these two projects result solely from different YP releases in use.
Or if these can be a result also of modifications conducted by platform vendors.

Any hints in what extend these result from different YP release numbers in use?

project A (YP release 2.6)
xxxx /yocto/
xxxx/yocto/downloads
xxxx/yocto/meta
xxxx/yocto/sstate-cache
xxxx/yocto/build
xxxx/yocto/.repo
xxxx/yocto/src
xxxx/yocto/prebuilt
xxxx/yocto/meta/
xxxx/yocto/meta/poky
xxxx/yocto/meta/meta-security
xxxx/yocto/meta/meta-clang
xxxx/yocto/meta/meta-openembedded
xxxx/yocto/meta/poky/
xxxx/yocto/meta/poky/meta
xxxx/yocto/meta/poky/documentation
xxxx/yocto/meta/poky/meta-poky
xxxx/yocto/meta/poky/meta-selftest
xxxx/yocto/meta/poky/bitbake
xxxx/yocto/meta/poky/.git
xxxx/yocto/meta/poky/meta-yocto-bsp
xxxx/yocto/meta/poky/meta-skeleton
xxxx/yocto/meta/poky/scripts
+ a set of layers value chain specific, meta-... subdirectories with meta/ as root-point.

project B (YP release 2.0, actually backport of some later release
which unfortunately is not reflected in poky.conf)
yyyy/poky/
yyyy/poky/meta-yocto
yyyy/poky/meta
yyyy/poky/documentation
yyyy/poky/meta-selftest
yyyy/poky/meta-selinux
yyyy/poky/build
yyyy/poky/meta-cust-installer
yyyy/poky/bitbake
yyyy/poky/meta-yocto-bsp
yyyy/poky/meta-skeleton
yyyy/poky/scripts
+ a set of layers value chain specific, meta-... subdirectories with poky/ as root-point.

I mean mainly following differences:
* Project A places a set of value-chain specific layers/meta-... directories at same
directory level as poky.
* meta-yocto apparently not present in project A tree
* meta-poky apparently not present in project B tree


Re: Recipes and meta-data directory tree

Robert P. J. Day
 

On Wed, 17 Mar 2021, keydi wrote:

Two projects are given. They use different YP release each.
Projects use also different target platform each.
... snip ...

project B (YP release 2.0, actually backport of some later release
you can't legitimately expect support for YP 2.0, which is six years
old and has been EOLed for quite some time.

rday


Re: subtree …/tmp/deploy/… , files named Packages

keydi <krzysztof.dudziak@...>
 

How are the odds for this question to get more audience on stackoverflow?
In meantime I tried to search release notes of all YP releases starting the oldest used here for related entries. Unsure if it is the right way and direction but me used word "Packages" to search notes of releases for. No helpful signs were found.
In meantime I also did one grep within OE, YP and Poky layers for search for possible significant scripts. However whole engine is too opaque to me to get fix stand in acceptable time. Is it possibly meta/lib/oe/package_manager.py which implements generation of plain-text files named "Packages" in tmp/deploy/rpm, .../ipk, ... sub-trees?


Re: Building test code?

jchludzinski
 

There are 2 git repos: openembedded-core and meta-openembedded.

openembedded-core has oe-init-build-env to create the build environment.
meta-openembedded has the recipe for spidev-test

If I use oe-init-build-env from openembedded-core to create the env vars then try:

   $ bitbake -b spidev-test.bb

I get into those licencing issues. 
 
How do I extricate myself from this conundrum? 
 
---John
 


On 2021-03-16 14:43, Robert P. J. Day wrote:
On Tue, 16 Mar 2021, jchludzinski via lists.yoctoproject.org wrote:

I tried to build spidev-test using the bitbake recipe: 

spidev-test.bb
 
I set:
ARCH=arm
BBPATH
CROSS_COMPILER=arm-linux-gnueabihf-
PATH

... and then tried to build spidev-test:

$ bitbake -b spidev-test.bb
WARNING: Buildfile specified, dependencies will not be handled. If this is not what you want, do not use -b / --buildfile.
Loading cache: 100% |################################################################| Time: 0:00:00
Loaded 1433 entries from dependency cache.

Build Configuration:
BB_VERSION           = "1.49.2"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "fedora-33"
TARGET_SYS           = "x86_64-oe-linux"
MACHINE              = "qemux86-64"
DISTRO               = "nodistro"
DISTRO_VERSION       = "nodistro.0"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta                 = "master:fa1e1fbc082e82e41ccfeae58af97fe048c9aac7"

Initialising tasks: 100% |###########################################################| Time: 0:00:00
Sstate summary: Wanted 6 Local 0 Network 0 Missed 6 Current 0 (0% match, 0% complete)
NOTE: Executing Tasks
WARNING: spidev-test-1.0-r0 do_populate_lic: Could not copy license file /home/fedora/openembedded-core/meta/files/common-lic
enses/GPL-2.0 to /home/fedora/openembedded-core/build/tmp-glibc/work/qemux86_64-oe-linux/spidev-test/1.0-r0/license-destdir/s
pidev-test/GPL-2.0: [Errno 2] No such file or directory: '/home/fedora/openembedded-core/meta/files/common-licenses/GPL-2.0'
ERROR: spidev-test-1.0-r0 do_populate_lic: QA Issue: spidev-test: LIC_FILES_CHKSUM points to an invalid file: /home/fedora/op
enembedded-core/meta/files/common-licenses/GPL-2.0 [license-checksum]
ERROR: spidev-test-1.0-r0 do_populate_lic: Fatal QA errors found, failing task.
ERROR: Logfile of failure stored in: /home/fedora/openembedded-core/build/tmp-glibc/work/qemux86_64-oe-linux/spidev-test/1.0-
r0/temp/log.do_populate_lic.281153
ERROR: Task (/home/fedora/junk/meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb:do_populate_lic) failed wi
th exit code '1'
NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/fedora/junk/meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb:do_populate_lic
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
What's this about licences?

  in current OE, there is no "GPL-2.0" license file, there is
"GPL-2.0-only" and "GPL-2.0-or-later" and a bunch of others, so i
think you need to pick one of those.

rday



make two ways to halt an embedded system #runlevel #yocto #poweroff #halt

anthony.marchand@...
 

Hello all,

I need two specific way to halt my embedded Linux system.
The first halt mode is used to halt the system while maintaining watchdog trigger.
The second halt mode is used to halt the system without maintaining watchdog trigger.

These two behavior are working fine, but actually, I test them only with poweroff (runlevel 0) and by modifing halt script.
I would have an other specific runlevel or parameter to switch these two differents halt modes. Is this possible?

So the system uses sysvinit and runlevel 0 is halt. Runlevel 6 is reboot and runlevel 5 is default (multi user).

The default runlevel 0 is called with poweroff and halt is executed.

But as I need 2 kind of halt scripts, I suppose I have to use an existent unused runlevel like runlevel 4 or
create a new one (even if it seems to be impossible).

At first, I would give a parameter to poweroff to tell it:

enter to runlevel0 but execute halt1 or halt2: like this

poweroff 1
poweroff 2

But it seems it's not at all possible so I think best idea is to use an other runlevel.

Does someone already heard about this kind of specific needs?
Maybe a better solution exists with Yocto project so I post it here.

Thanks for all, by advance, best reguards


[meta-security][PATCH] layer.conf: Add hardknott to LAYERSERIES_COMPAT

Armin Kuster
 

Thats codename for 3.3

Signed-off-by: Armin Kuster <akuster808@...>
---
conf/layer.conf | 2 +-
meta-hardening/conf/layer.conf | 2 +-
meta-integrity/conf/layer.conf | 2 +-
meta-security-compliance/conf/layer.conf | 2 +-
meta-security-isafw/conf/layer.conf | 2 +-
meta-tpm/conf/layer.conf | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 8c0254b..fd21da1 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -9,6 +9,6 @@ BBFILE_COLLECTIONS += "security"
BBFILE_PATTERN_security = "^${LAYERDIR}/"
BBFILE_PRIORITY_security = "8"

-LAYERSERIES_COMPAT_security = "gatesgarth"
+LAYERSERIES_COMPAT_security = "hardknott"

LAYERDEPENDS_security = "core openembedded-layer perl-layer networking-layer meta-python"
diff --git a/meta-hardening/conf/layer.conf b/meta-hardening/conf/layer.conf
index 22d8874..085ea45 100644
--- a/meta-hardening/conf/layer.conf
+++ b/meta-hardening/conf/layer.conf
@@ -8,6 +8,6 @@ BBFILE_COLLECTIONS += "harden-layer"
BBFILE_PATTERN_harden-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_harden-layer = "10"

-LAYERSERIES_COMPAT_harden-layer = "gatesgarth"
+LAYERSERIES_COMPAT_harden-layer = "hardknott"

LAYERDEPENDS_harden-layer = "core openembedded-layer"
diff --git a/meta-integrity/conf/layer.conf b/meta-integrity/conf/layer.conf
index 76374eb..ba028da 100644
--- a/meta-integrity/conf/layer.conf
+++ b/meta-integrity/conf/layer.conf
@@ -20,7 +20,7 @@ INTEGRITY_BASE := '${LAYERDIR}'
# interactive shell is enough.
OE_TERMINAL_EXPORTS += "INTEGRITY_BASE"

-LAYERSERIES_COMPAT_integrity = "gatesgarth"
+LAYERSERIES_COMPAT_integrity = "hardknott"
# ima-evm-utils depends on keyutils from meta-oe
LAYERDEPENDS_integrity = "core openembedded-layer"

diff --git a/meta-security-compliance/conf/layer.conf b/meta-security-compliance/conf/layer.conf
index db243f7..2024d4a 100644
--- a/meta-security-compliance/conf/layer.conf
+++ b/meta-security-compliance/conf/layer.conf
@@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "scanners-layer"
BBFILE_PATTERN_scanners-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_scanners-layer = "10"

-LAYERSERIES_COMPAT_scanners-layer = "gatesgarth"
+LAYERSERIES_COMPAT_scanners-layer = "hardknott"

LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python"

diff --git a/meta-security-isafw/conf/layer.conf b/meta-security-isafw/conf/layer.conf
index b8ee1c0..1f1095f 100644
--- a/meta-security-isafw/conf/layer.conf
+++ b/meta-security-isafw/conf/layer.conf
@@ -14,4 +14,4 @@ LAYERVERSION_security-isafw = "1"

LAYERDEPENDS_security-isafw = "core"

-LAYERSERIES_COMPAT_security-isafw = "gatesgarth"
+LAYERSERIES_COMPAT_security-isafw = "hardknott"
diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index cd62fba..65788eb 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "tpm-layer"
BBFILE_PATTERN_tpm-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_tpm-layer = "10"

-LAYERSERIES_COMPAT_tpm-layer = "gatesgarth"
+LAYERSERIES_COMPAT_tpm-layer = "hardknott"

LAYERDEPENDS_tpm-layer = " \
core \
--
2.17.1


How to create a list of source files for an Image?

Priyanshu Sharma
 

Hi,

I want to create a text file containing a list of all the source files used to build my Yocto image. Is there any mechanism to do that?

I found out that archiever.bbclass creates a sub-folder deploy/sources, with all used sources in archived form. But is there any way to directly create a list file?

Thanks!

Warm regards,
Priyanshu Sharma


Re: Building test code?

Robert P. J. Day
 

On Tue, 16 Mar 2021, jchludzinski via lists.yoctoproject.org wrote:

I tried to build spidev-test using the bitbake recipe: 

spidev-test.bb
 
I set:
ARCH=arm
BBPATH
CROSS_COMPILER=arm-linux-gnueabihf-
PATH

... and then tried to build spidev-test:

$ bitbake -b spidev-test.bb
WARNING: Buildfile specified, dependencies will not be handled. If this is not what you want, do not use -b / --buildfile.
Loading cache: 100% |################################################################| Time: 0:00:00
Loaded 1433 entries from dependency cache.

Build Configuration:
BB_VERSION = "1.49.2"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "fedora-33"
TARGET_SYS = "x86_64-oe-linux"
MACHINE = "qemux86-64"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "m64 core2"
TARGET_FPU = ""
meta = "master:fa1e1fbc082e82e41ccfeae58af97fe048c9aac7"

Initialising tasks: 100% |###########################################################| Time: 0:00:00
Sstate summary: Wanted 6 Local 0 Network 0 Missed 6 Current 0 (0% match, 0% complete)
NOTE: Executing Tasks
WARNING: spidev-test-1.0-r0 do_populate_lic: Could not copy license file /home/fedora/openembedded-core/meta/files/common-lic
enses/GPL-2.0 to /home/fedora/openembedded-core/build/tmp-glibc/work/qemux86_64-oe-linux/spidev-test/1.0-r0/license-destdir/s
pidev-test/GPL-2.0: [Errno 2] No such file or directory: '/home/fedora/openembedded-core/meta/files/common-licenses/GPL-2.0'
ERROR: spidev-test-1.0-r0 do_populate_lic: QA Issue: spidev-test: LIC_FILES_CHKSUM points to an invalid file: /home/fedora/op
enembedded-core/meta/files/common-licenses/GPL-2.0 [license-checksum]
ERROR: spidev-test-1.0-r0 do_populate_lic: Fatal QA errors found, failing task.
ERROR: Logfile of failure stored in: /home/fedora/openembedded-core/build/tmp-glibc/work/qemux86_64-oe-linux/spidev-test/1.0-
r0/temp/log.do_populate_lic.281153
ERROR: Task (/home/fedora/junk/meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb:do_populate_lic) failed wi
th exit code '1'
NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/home/fedora/junk/meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb:do_populate_lic
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
What's this about licences?
in current OE, there is no "GPL-2.0" license file, there is
"GPL-2.0-only" and "GPL-2.0-or-later" and a bunch of others, so i
think you need to pick one of those.

rday


Re: Building test code?

jchludzinski
 

I tried to build spidev-test using the bitbake recipe: 
spidev-test.bb
 
I set:
ARCH=arm
BBPATH
CROSS_COMPILER=arm-linux-gnueabihf-
PATH

... and then tried to build spidev-test:
$ bitbake -b spidev-test.bb 
WARNING: Buildfile specified, dependencies will not be handled. If this is not what you want, do not use -b / --buildfile.
Loading cache: 100% |################################################################| Time: 0:00:00
Loaded 1433 entries from dependency cache.

Build Configuration:
BB_VERSION           = "1.49.2"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "fedora-33"
TARGET_SYS           = "x86_64-oe-linux"
MACHINE              = "qemux86-64"
DISTRO               = "nodistro"
DISTRO_VERSION       = "nodistro.0"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta                 = "master:fa1e1fbc082e82e41ccfeae58af97fe048c9aac7"

Initialising tasks: 100% |###########################################################| Time: 0:00:00
Sstate summary: Wanted 6 Local 0 Network 0 Missed 6 Current 0 (0% match, 0% complete)
NOTE: Executing Tasks
WARNING: spidev-test-1.0-r0 do_populate_lic: Could not copy license file /home/fedora/openembedded-core/meta/files/common-licenses/GPL-2.0 to /home/fedora/openembedded-core/build/tmp-glibc/work/qemux86_64-oe-linux/spidev-test/1.0-r0/license-destdir/spidev-test/GPL-2.0: [Errno 2] No such file or directory: '/home/fedora/openembedded-core/meta/files/common-licenses/GPL-2.0'
ERROR: spidev-test-1.0-r0 do_populate_lic: QA Issue: spidev-test: LIC_FILES_CHKSUM points to an invalid file: /home/fedora/openembedded-core/meta/files/common-licenses/GPL-2.0 [license-checksum]
ERROR: spidev-test-1.0-r0 do_populate_lic: Fatal QA errors found, failing task.
ERROR: Logfile of failure stored in: /home/fedora/openembedded-core/build/tmp-glibc/work/qemux86_64-oe-linux/spidev-test/1.0-r0/temp/log.do_populate_lic.281153
ERROR: Task (/home/fedora/junk/meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb:do_populate_lic) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/fedora/junk/meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb:do_populate_lic
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
What's this about licences?
 
---John
 


On 2021-03-16 11:50, jchludzinski via lists.yoctoproject.org wrote:
I'm 'bitbaking' now.

On 2021-03-16 10:53, jchludzinski via lists.yoctoproject.org wrote:
Well, because time is of the essence, could you give me a little
assist here and explain how I might build spidev-test using
OpenEmbedded?

THANKS for your help!
---John


On 2021-03-16 05:58, Josef Holzmayr wrote:
Am Di., 16. März 2021 um 10:49 Uhr schrieb Nicolas Dechesne
<nicolas.dechesne@...>:

On Tue, Mar 16, 2021 at 8:07 AM jchludzinski via
lists.yoctoproject.org
<jchludzinski=vivaldi.net@...> wrote:

It certainly appears to be BUT I'm not certain what I'm looking at?

What is meta-openembedded?

Is it a GIT repo that can be cloned and built?

Short answer is yes. The whole Yocto Project / Open Embedded concept
is based around 'layers. A layer is a repository that contains recipes
(and/or machine/distro, ..). The Yocto Project releases include a
couple of common/core layers, but there are plenty of layers out there
which can be used
I am sure there are quite a bit of documentation on this topic, but
perhaps you might want to start with:
https://docs.yoctoproject.org/overview-manual/yp-intro.html#the-yocto-project-layer-model

Or grab a beer and start bingewatching
https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj

</SCNR>



How do I use this to build spidev-test?


---John


On 2021-03-15 19:54, akuster wrote:

On 3/15/21 4:11 PM, jchludzinski via lists.yoctoproject.org wrote:

I got a piece of code from github:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/spi/spidev_test.c

I'd like to add it somewhere under /*tools/testing*/ and build it there.

Not sure if this is appropriate? If so, how do I go about this?

If not, what's the best way to build this?


Is this what you are looking for?
 https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-kernel/spidev-test/spidev-test.bb

-armin





Re: Which recipes put qtwebkit in my image?

Quentin Schulz
 

Hi Mauro,

On Tue, Mar 16, 2021 at 04:50:44PM +0100, Mauro Ziliani wrote:
Hi all.I need to find which recipe installs qtwebkit in my final image.

I look in on every recipes I make but I don't find who put qtwebkit in my image.
I have the same matter with *-dev packages

I use bitbake -g but I don't find the "source" of qtwebkit.
oe-pkgdata-util lookup-recipe qtwebkit

could help. Or if you know which file you don't want in your fs and want
to know which package is installing it:

oe-pkgdata-util find-path '*qtwebkit*'
(provided the file you're looking for has qtwebkit in its filename)

Hope this helps,
Cheers,
Quentin


subtree …/tmp/deploy/… , files named Packages

keydi <krzysztof.dudziak@...>
 

Hello,

This is about two projects Projects A and B. Both use Yocto to build embedded-Linux distribution. However different Yocto release each. Also different target platform each. One puts Linux software packages to RPM, another one to IPK. For only one of those two Yocto generates plain-text files named 'Packages' and places it to image subdirectories of /tmp/deploy/rpm or /tmp/deploy/ipk subtree. The another one doesn't. Is this (files 'Packages' to be generated or not) any configuration point platform vendor can had set for its code-base to non-standard setting? Any means available for project Packages files (as of time being) not being generated to activate these files generation?

Background: Tool-chain used here to generate software bill of materials and all artifacts needed for fulfillment of used software license terms processes these files. Might it be good/bad idea to use files addressed in this message for software composition evaluation?


Which recipes put qtwebkit in my image?

Mauro Ziliani
 

Hi all.I need to find which recipe installs qtwebkit in my final image.

I look in on every recipes I make but  I don't find who put qtwebkit in my image.
I have the same matter with *-dev packages

I use bitbake -g but I don't find the "source" of qtwebkit.


Thanks all

Mz

Sent from Mailspring, the best free email app for work

4661 - 4680 of 57385