|
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
toggle quoted messageShow quoted text
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:
|
|
|
|
Re: Recipes and meta-data directory tree
keydi <krzysztof.dudziak@...>
OE allows you to build own distributions, so what you are looking at is twoThanks 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@...>
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,
toggle quoted messageShow quoted text
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-----
|
|
|
|
[meta-rockchip][PATCH] layer.conf: Add hardknott to compatible release branches
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: 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
On Wed, Mar 17, 2021 at 9:43 AM keydi <krzysztof.dudziak@...> wrote:
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
On Tue, Mar 16, 2021 at 8:53 AM keydi <krzysztof.dudziak@...> wrote:
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
On 2021-03-16 3:20 a.m., lavkhush2208@... wrote:
I am getting issue in AvahiHello, 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]
|
|
|
|
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:
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
|
|
|
|
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.... snip ... project B (YP release 2.0, actually backport of some later releaseyou 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:
|
|
|
|
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
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
|
|
|