Date   

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

Trevor Woerner
 

Applied. Thank you! :-)


Re: spidev.c ?

Zoran
 

I am guessing here.... But what do you have while executing the
following command being in /sys
as root?

root@arm:/sys# find . -name spi*

Zee
_______

On Wed, Mar 17, 2021 at 5:41 PM jchludzinski via
lists.yoctoproject.org
<jchludzinski=vivaldi.net@...> wrote:


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:

static int __init spidev_init(void)
{
int status;

/* Claim our 256 reserved device numbers. Then register a class
* that will key udev/mdev to add/remove /dev nodes. Last, register
* the driver which manages those device numbers.
*/
BUILD_BUG_ON(N_SPI_MINORS > 256);
status = register_chrdev(SPIDEV_MAJOR, "spi", &spidev_fops);
if (status < 0)
return status;

spidev_class = class_create(THIS_MODULE, "spidev");
if (IS_ERR(spidev_class)) {
unregister_chrdev(SPIDEV_MAJOR, spidev_spi_driver.driver.name);
return PTR_ERR(spidev_class);
}

status = spi_register_driver(&spidev_spi_driver);
if (status < 0) {
class_destroy(spidev_class);
unregister_chrdev(SPIDEV_MAJOR, spidev_spi_driver.driver.name);
}
return status;
}
module_init(spidev_init);

... for creating device files in udev.

So when I use 'make nconfig' to specifiy that I want a loadable module for the ALTERA SPI driver, why don't I see a spidev.o file in drivers/spi/ ?

How does spi-altera.ko create device files without a call to register_chrdev(...).

How is it a loadable module without module_init(...)?

When I separately build spidev.c as an .ko and try loading it, I get: "Device or resourse busy"

---John



Re: Recipes and meta-data directory tree

keydi <krzysztof.dudziak@...>
 

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.
Thanks for input from you.
Does this mean shown differences in directory tree is result, a mix of
these all listed parameters?
I am aware of these are two different distributions.
I am aware of these are based on different releases.
I am aware of these are two different machines.
I am aware of release to release to get several classes of modifications.
Actually asked question means how much show differences result from
usage of different YP releases.


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

keydi <krzysztof.dudziak@...>
 


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

Thanks for helpful input. This matches my own observation.
Tool-chain used in project requires additionally license.manifest file on its input.
For some reason it also takes a look into files named Packages.
Actually it can be clear why it does this: Packages file specifies among others each package source code address/path.

Despite the question files named Packages generated for .ipk YES, for .rpm NO,
is it legitimate to use these files in external tool-chain for software composition analysis?
I mean these files might be Yocto internal interface not intended for purpose pointed out here. May this be true?


Re: QA notification for completed autobuilder build (yocto-3.3_M3.rc1)

Sangeeta Jain
 

Hi All,

This is the full report for yocto-3.3_M3.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

new issue found:

BUG id:14306 - [3.3 M3 rc1] beaglebone poky-alt wic image can not bootup

Bugs verified:

BUG id:14203 - [QA 3.3 M2 RC1] failure in ptest : gstreamer1.0.gstreamer-1.0/pipelines_seek.test
Verified Fixed.


======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14306
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14203



Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Pokybuild User
Sent: Tuesday, 16 March, 2021 6:16 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.3_M3.rc1)


A build flagged for QA (yocto-3.3_M3.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3_M3.rc1


Build hash information:

bitbake: 53c30efec4099035d19e6717059dfceff8ff88fd
meta-arm: a949ebfd06dcae26ca3c625195e1a3ed703b2c6e
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 850940e3e5ebc75328fa75e718235342cb6c2172
meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
oecore: fa1e1fbc082e82e41ccfeae58af97fe048c9aac7
poky: 9fbbf40317743beacd8ac9d3f602765ed9d9fa6f



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...



[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

4681 - 4700 of 57410