Date   

Re: Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #linux #yocto #kernel

Ross Burton
 

The first question is why. It sounds like you want Ubuntu but the
bootloader and kernel built by Yocto. I'm struggling to see what this
would achieve.

On Fri, 12 Feb 2021 at 11:49, <poornesh.g@phytecembedded.in> wrote:

Greetings !

I am trying to integrate the ubuntu 20.04 Root file system with the yocto build . Ultimately my final image should consists of :

Bootloader and Kernel : From default yocto build system.

Rootfile system : Should be taken the ubuntu 20.04 RFS.

I am adding the ubuntu 20.04 rfs as a recipe in yocto, but I am failing to integrate this ubuntu RFS over the default yocto root file system.

Requesting your solutions and steps .

Thanks in advance




Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #linux #yocto #kernel

poornesh.g@...
 

Greetings !

I am trying to integrate the ubuntu 20.04 Root file system with the yocto build . Ultimately my final image should consists of :

Bootloader and Kernel : From default yocto build system.

Rootfile system : Should be taken the ubuntu 20.04 RFS.

I am adding the ubuntu 20.04 rfs as a recipe in yocto, but I am failing to integrate this ubuntu RFS over the default yocto root file system.

Requesting your solutions and steps .

Thanks in advance


Re: How to get packages version from an image recipe #yocto #linux

Nicolas Jeker
 

Hi Zakaria

On Thu, 2021-02-11 at 03:47 -0800, zakaria.zidouh@smile.fr wrote:
Hello,
 
I want to get the version of the packages generated by a recipe from
the image recipe (or by a python script that runs outside of the
package generating recipe). (like the output of the bitbake -s
command)
 
Do you have any ideas please? 
Probably the image manifest is what you are looking for?

From
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#image-generation-dev-environment
:

The manifest file (.manifest) resides in the same directory as the root
filesystem image. This file lists out, line-by-line, the installed
packages.

The file contents look like this:

...
dropbear armv7at2hf-neon 2019.78-r0
dtc armv7at2hf-neon 1.6.0-r0
e2fsprogs armv7at2hf-neon 1.45.4-r0
...

Thank you


Re: Dunfell, nodejs and typescript - short experience report

Simon Vogl
 

Hi,


Am 12.02.21 um 11:12 schrieb Josef Holzmayr:
Howdy!

Thanks for sharing, a few comments inline.

Am Fr., 12. Feb. 2021 um 11:03 Uhr schrieb Simon Vogl <simon@...>:
I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few small issues.

Firstly, the do_configure() task takes quite some time to complete. After a quick analysis, I saw that most of the time is being spent in creating the npmrc files while packing the dependent packages. I wrote a small workaround to directly create the file instead of calling 'npm config', which results in a 3x-4x speedup:

Signed-off-by: Simon Vogl <simon@...>
---
 lib/bb/fetch2/npm.py | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/bb/fetch2/npm.py b/lib/bb/fetch2/npm.py
index 4789850..2720d87 100644
--- a/lib/bb/fetch2/npm.py
+++ b/lib/bb/fetch2/npm.py
@@ -97,13 +97,18 @@ class NpmEnvironment(object):
                 cmd = "NPM_CONFIG_GLOBALCONFIG=%s " % cfgfile + cmd
                 return runfetchcmd(cmd, d, workdir=workdir)

+            cfg = open(cfgfile, "a")
             if self.configs:
                 for key, value in self.configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    #_run("npm config set %s %s" % (key, shlex.quote(value)))

             if configs:
                 for key, value in configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    # _run("npm config set %s %s" % (key, shlex.quote(value)))
+
+            cfg.close()

             if args:
                 for key, value in args:
--
2.7.4

Are there any side effects that I did not stumble over yet? And I'd LOVE to have these calls running in a thread-pool for better performance...
The main side effect is that you're effectively patching poky, which
is bad for maintenance.
I know, that's why I'm asking in the first place. But performance here is really really improvable.

      
Secondly, our projects are based on typescript, so a native compile step is necessary to create a compiled version for packing. We experimented with a separate release branch to check in compiled versions, but this is not easy to handle. I played around with npm.bbclass and found a way to extend configure (!) with a call to our build script before packaging:

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 068032a1e5..31535098cf 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -170,6 +170,11 @@ python npm_do_configure() {

     # Configure the main package
     with tempfile.TemporaryDirectory() as tmpdir:
+        # install all (native) build dependencies, overrides npm cache:
+        ret = os.system("npm i")
+        # run build step:
+        env.run("npm run build", args=[], workdir=d.getVar("S"))
+
         tarball = npm_pack(env, d.getVar("S"), tmpdir)
         npm_unpack(tarball, d.getVar("NPM_PACKAGE"), d)

As we have plain JS packages as well, I put the modified configure() in a subclass and this works for us, but it does not look like a clean solution to me. How do you other IoT'ers address this situation?
Again, patching poky is a bad idea. Creating custom bbclasses is much
neater: you could create a base include, and pull that together with
npm.bbclass into two final bbclasses of yours, like npm-js-voxel and
npm-ts-voxel. The former would not have the compilation step. And,
putting the typescript/webpack invocation into configure is also not
exactly how things are meant to work. I know that the dependency
tracking of npm is not easily compatible with bitbake, but the aim
should be to
1) have a recipe that provides typescript-native
2) DEPEND on typescript-native in the recipe which you need to compile
3) add a do_compile stage that does the work.

Agreed, and I have a patched configure in my own subclass without changing the official codebase -- I just wanted to point where the modification needs to take place.

I actually tried the approach that you propose by playing around with configure_append / compile_prepend tasks, but these build steps are called after the package has already been packed --> the compiled data is not being  installed, I'd have to re-pack things.

Agreed, a typescript-native package would be nice, on the other hand this is where the npm-version-chaos comes in again: Many packages use different tsc versions,...

Simon


Greetz



-- 
VoXel Interaction Design  |  www.voxel.at
DI Dr.techn. Simon Vogl   |  simon@...
Tomaschekweg 46           |  +43 650 2323 555
A-4040 Linz - Austria     |
Office address: Industriezeile 35, 4020 Linz (2nd floor)


Re: Dunfell, nodejs and typescript - short experience report

Josef Holzmayr
 

Howdy!

Thanks for sharing, a few comments inline.

Am Fr., 12. Feb. 2021 um 11:03 Uhr schrieb Simon Vogl <simon@voxel.at>:

I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few small issues.

Firstly, the do_configure() task takes quite some time to complete. After a quick analysis, I saw that most of the time is being spent in creating the npmrc files while packing the dependent packages. I wrote a small workaround to directly create the file instead of calling 'npm config', which results in a 3x-4x speedup:

Signed-off-by: Simon Vogl <simon@voxel.at>
---
lib/bb/fetch2/npm.py | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/bb/fetch2/npm.py b/lib/bb/fetch2/npm.py
index 4789850..2720d87 100644
--- a/lib/bb/fetch2/npm.py
+++ b/lib/bb/fetch2/npm.py
@@ -97,13 +97,18 @@ class NpmEnvironment(object):
cmd = "NPM_CONFIG_GLOBALCONFIG=%s " % cfgfile + cmd
return runfetchcmd(cmd, d, workdir=workdir)

+ cfg = open(cfgfile, "a")
if self.configs:
for key, value in self.configs:
- _run("npm config set %s %s" % (key, shlex.quote(value)))
+ cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+ #_run("npm config set %s %s" % (key, shlex.quote(value)))

if configs:
for key, value in configs:
- _run("npm config set %s %s" % (key, shlex.quote(value)))
+ cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+ # _run("npm config set %s %s" % (key, shlex.quote(value)))
+
+ cfg.close()

if args:
for key, value in args:
--
2.7.4

Are there any side effects that I did not stumble over yet? And I'd LOVE to have these calls running in a thread-pool for better performance...
The main side effect is that you're effectively patching poky, which
is bad for maintenance.

Secondly, our projects are based on typescript, so a native compile step is necessary to create a compiled version for packing. We experimented with a separate release branch to check in compiled versions, but this is not easy to handle. I played around with npm.bbclass and found a way to extend configure (!) with a call to our build script before packaging:

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 068032a1e5..31535098cf 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -170,6 +170,11 @@ python npm_do_configure() {

# Configure the main package
with tempfile.TemporaryDirectory() as tmpdir:
+ # install all (native) build dependencies, overrides npm cache:
+ ret = os.system("npm i")
+ # run build step:
+ env.run("npm run build", args=[], workdir=d.getVar("S"))
+
tarball = npm_pack(env, d.getVar("S"), tmpdir)
npm_unpack(tarball, d.getVar("NPM_PACKAGE"), d)

As we have plain JS packages as well, I put the modified configure() in a subclass and this works for us, but it does not look like a clean solution to me. How do you other IoT'ers address this situation?
Again, patching poky is a bad idea. Creating custom bbclasses is much
neater: you could create a base include, and pull that together with
npm.bbclass into two final bbclasses of yours, like npm-js-voxel and
npm-ts-voxel. The former would not have the compilation step. And,
putting the typescript/webpack invocation into configure is also not
exactly how things are meant to work. I know that the dependency
tracking of npm is not easily compatible with bitbake, but the aim
should be to
1) have a recipe that provides typescript-native
2) DEPEND on typescript-native in the recipe which you need to compile
3) add a do_compile stage that does the work.

Greetz


Dunfell, nodejs and typescript - short experience report

Simon Vogl
 

I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few small issues.

Firstly, the do_configure() task takes quite some time to complete. After a quick analysis, I saw that most of the time is being spent in creating the npmrc files while packing the dependent packages. I wrote a small workaround to directly create the file instead of calling 'npm config', which results in a 3x-4x speedup:

Signed-off-by: Simon Vogl <simon@...>
---
 lib/bb/fetch2/npm.py | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/bb/fetch2/npm.py b/lib/bb/fetch2/npm.py
index 4789850..2720d87 100644
--- a/lib/bb/fetch2/npm.py
+++ b/lib/bb/fetch2/npm.py
@@ -97,13 +97,18 @@ class NpmEnvironment(object):
                 cmd = "NPM_CONFIG_GLOBALCONFIG=%s " % cfgfile + cmd
                 return runfetchcmd(cmd, d, workdir=workdir)
 
+            cfg = open(cfgfile, "a")
             if self.configs:
                 for key, value in self.configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    #_run("npm config set %s %s" % (key, shlex.quote(value)))
 
             if configs:
                 for key, value in configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    # _run("npm config set %s %s" % (key, shlex.quote(value)))
+
+            cfg.close()
 
             if args:
                 for key, value in args:
-- 2.7.4

Are there any side effects that I did not stumble over yet? And I'd LOVE to have these calls running in a thread-pool for better performance...


Secondly, our projects are based on typescript, so a native compile step is necessary to create a compiled version for packing. We experimented with a separate release branch to check in compiled versions, but this is not easy to handle. I played around with npm.bbclass and found a way to extend configure (!) with a call to our build script before packaging: 

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 068032a1e5..31535098cf 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -170,6 +170,11 @@ python npm_do_configure() {
 
     # Configure the main package
     with tempfile.TemporaryDirectory() as tmpdir:
+        # install all (native) build dependencies, overrides npm cache:
+        ret = os.system("npm i")
+        # run build step:
+        env.run("npm run build", args=[], workdir=d.getVar("S"))
+
         tarball = npm_pack(env, d.getVar("S"), tmpdir)
         npm_unpack(tarball, d.getVar("NPM_PACKAGE"), d)

As we have plain JS packages as well, I put the modified configure() in a subclass and this works for us, but it does not look like a clean solution to me. How do you other IoT'ers address this situation?

Simon


-- 
VoXel Interaction Design  |  www.voxel.at
DI Dr.techn. Simon Vogl   |  simon@...
Tomaschekweg 46           |  +43 650 2323 555
A-4040 Linz - Austria     |  
Office address: Industriezeile 35, 4020 Linz (2nd floor)


[error-report-web][PATCH] parser: make contains_tag ignore non-str fields

Yi Fan Yu
 

if `MACHINE` is set to False (in a selftest build),
contains_tags should skip that field instead of
searching for the character '<'.

[YOCTO #14208]

Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
---
Post/parser.py | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/Post/parser.py b/Post/parser.py
index ed65d4f..f54482a 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -21,10 +21,14 @@ class Parser:

# returns true if the values contain '<' char
# Ignore the failures field (which is an array anyway)
+ # Ignore any non-str fields too [YOCTO #14208]
def contains_tags (self, data):
for key,val in data.items():
if key == 'failures':
continue
+
+ if not isinstance(val, str):
+ continue

if '<' in val:
return True
--
2.25.1


Yocto Technical Team Minutes, Engineering Sync, for Feb 9 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for June 9 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolly, Ross Burton, Saul Wold, Joshua Watt, Richard
Purdie, Alejandro H, Will, Jan-Simon Möller, John Kaldas, Jon Mason, Bruce
Ashfield, Michael Halstead, Scott Murray, Steve Sakoman, Tim Orling, Trevor
Gamblin, Peter Kjellerstedt, Randy MacLeod

== notes ==
- uninative 2.3.2 with upstream fixes (might be issues with 2.3.3, please
have a look)
- swatbot has found some interesting things

== general ==
Randy: rebasing meta-rust into oe-core. it’s working, sdk needs work and
libsvg needs work
RP: have you seen the patches on the mailing list? (Jan-Simon, PaulB)
Randy: yes, haven’t looked at them yet
RP: do you know how they relate?
Randy: not yet, i’ll reply to the thread. is it needed for the next release?
RP: i’m not going to hold up the release for it, but it’d be nice


RP: there’s been a lot of churn in the versions (glibc, kernel, etc). if
anyone sees anything please raise a flag
Ross: yes, I’ve seen some issues, not always 100% reproducible
RP: x86 host?
Ross: not always
TimO: ubuntu host?
Ross: 20.04
RP: glibc-2.33 does have some interesting things, so i’m not surprised there
are issues
Randy: what are you seeing?
Ross: issues building the kernel (“dangerous relocations”)
RP: for dunfell we did a glibc-2.32 update but we’ll hold off on glibc-2.33
(thanks Michael!)
Ross: turning off uninative makes it go away
TimO: is that a Xen kernel?
Ross: no, just defconfig


TimO: (for Bruce) interested in kubernetes or k3s
Bruce: i upgraded pretty much everything in meta-virt over the weekend, k3s is
broken but everything else is good


TimO: how was FOSDEM?
Bruce: best platform so far, better than ELC/E
TimO: their own, or same as Plumbers?
ScottM: their own, something with matrix and jitsi
Bruce: not a lot of OE stuff, specifically, but mentioned in a bunch
(embedded, license, distros, virtualization)

JPEW: was going to give a talk at ELC, (virtual, labgrid, etc)
TrevorG + TimO: we should talk
TrevorG: we’ve got interesting things working, so we were going to give a
talk (kube-virt tekton stuff)
ScottM: for AGL there’s a project to do drm stuff on the host (wayland) from
within a virt machine (virgl)


Randy: is x11 really dead?
Ross: yes, no upstream maintainer
JPEW: i’ve been looking for a good Weston compositor that would be a good
replacement for Sato. even if it just listed out the .desktop files that
could be clicked
Ross: there are some
JPEW: but they’re not great on a 5” screen. there is the IVI shell, but
any apps have to use the IVI shell extensions
ScottM: AGL just migrated away from it. i’ll have to look it up, but there
is a compositor that uses libweston
Ross: i looked at matchbox to see if the sato bits could be converted to
weston. it should be possible, the hooks are there, but i haven’t gone
any further
TimO: the problems with the compositors that i looked at needed QT
JPEW: sway is a good tiling compositor, but we need something that would be
good for an embedded demo
ScottM: maynard is the one from colabora, it was dead, but i think it’s
going to be picked up again. another one would be to use wlroots or
libweston to piece something together
TimO: libweston would be a good one
ScottM: the AGL one targets libweston, libweston had updates to support this
use-case
TimO: also need to consider testability, worked with dogtail but it was
“hacky”
Ross: gtk4 has a re-written accessibility module


RP: there is a layer that RedHat has been working on called meta-rpm,
they’ve been making noises about automotive stuff. it’s completely
beta software so far, native only, they’re repackaging their binaries to
look like yocto packages
TimO: it looks like something similar to what Siemens is doing (isar)
RP: they’re looking at re-writing pseudo
ScottM: is that public?
J-S: it’s on a gitlab: https://gitlab.com/fedora-iot/meta-rpm
JPEW: the idea is “you can run Fedora and put stuff from your own layers on
top”
J-S: it works for a test build they’re doing, it’s actually CentOS8
ScottM: it would be interesting for commercial folks if it was RHEL
JPEW: the idea is “i have this recipe from OE that i want to run on CentOS”
RP: my fear is RedHat is pretty large
Alejandro: my fear is that all distros might take up this path
RP: from a public perception point of view we need to make sure people realize
this isn’t how Yocto is supposed to be done
Randy: the repo started in Nov 2020, the 90% developer on the project seems
like someone we’re linked to (LinkedIn)
RP: both Ross and I have reached out the project
Alejandro: our DNF is quite old, is that good or bad?
RP: don’t think it matters, they’re using DNF in native mode to run
the post-installs which runs into problems with pseudo (we don’t use
chroot). it has a lot of constraints (like isar)
Randy: we’re on the DNF from Dec 2020, and the latest was just released 12
days ago, so we’re not that far behind
TimO: AlexK did quite a lot of work on updates recently, and DNF was not one
of the easy ones


JPEW: (for Michael) any updates on the reproducibility page?
MH: i haven’t had a look at it yet
JPEW: I was hoping it would be hosted on the YP page, is that what you were
thinking?
MH: i thought we were pulling from your site (the JSON) and we’d pull from
there
JPEW: i was putting it up so you could see the HTML, but i wanted it to be
hosted on the YP page, it doesn’t work on mine due to x-site-scripting
checks in browser, so it needs to all be hosted on the same site. if
x-site-scripting is turned off in browser it works, but we can’t expect
that


TimO: i was trying to share the 3.3 release schedule with an intern but we
don’t have one
SJ: probably my fault
RP: as part of the automation there were questions about what we needed and
what was not being used


TrevorW: ELC has been cancelled, should we do something? especially the
training (devday)
RP: need to bring it up with the people who would normally organize it


Re: Enabling Serial console via uart1(serial1) in cm3(rpi3) kernel 5.4. #cm3 #dunfell

Zoran
 

Hello Prashant,

Can you telnet to the target? And issue the following: cat /proc/cmdline

And post it here?

In the meantime, you can verify the issue with:
https://www.raspberrypi.org/documentation/configuration/cmdline-txt.md

Hope this helps,
Zee
_______

On Thu, Feb 11, 2021 at 2:24 PM <prashantsingh@dialtronics.com> wrote:

Dear Team,

I'm using poky-dunfell to get os for my raspberrypi-cm3.
I need to get the stdout data to serial console via uart1(serial1).

I given change in my cmdline.txt as: dwc_otg.lpm_enable=0 console=serial1,115200 consol=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait kgdboc=serial0,115200
and in config.txt as:

dtoverlay=pi3-disable-bt
dtparam=uart1=on
# Enable UART
enable_uart=1
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
core_freq=250
force_turbo=1

then also I'm not getting the serial output in my serial1.

Please help to resolve this issue.

Thanks & Regards.


Enabling Serial console via uart1(serial1) in cm3(rpi3) kernel 5.4. #cm3 #dunfell

@prashant2314
 

Dear Team,

I'm using poky-dunfell  to get os for my raspberrypi-cm3.
I need to get the stdout data to serial console via uart1(serial1).

I given change in my cmdline.txt as:   dwc_otg.lpm_enable=0 console=serial1,115200 consol=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait kgdboc=serial0,115200
and in  config.txt  as:
                                
dtoverlay=pi3-disable-bt
dtparam=uart1=on
# Enable UART
enable_uart=1
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
core_freq=250
force_turbo=1

then also I'm not getting the serial output in my serial1.

Please help to resolve this issue.

Thanks & Regards.


how to copy NTP parser files verbatim from 4.2.8p10 to 4.2.8p13?

Robert P. J. Day
 

here's hoping someone has gone through this and can summarize what i
need to do; i'll try to keep it short.

migrating all sorts of stuff from (effectively) morty project to
(effectively) zeus, and currently moving from ntp_4.2.8p10 to
ntp_4.2.8p13, the only complication being that, way back when, the p10
parser was extended to recognize two new (proprietary) command-line
options; thus, at the time, it's clear that yacc was run to generate
new parser files, which have worked just fine all this time, so i have
a solution for p10.

so far, i've added all the underlying support code for these
additional options, and all of that compiles just fine, so everything
needed to *support* the two new options is in place -- new structures
have been added, existing structures have been extended, new functions
are in place, etc etc etc. all that looks good.

the only thing missing is the final bit to support the two new
run-time options, but i've been told that there is no need to re-run
yacc to re-generate the parser files, as i can just take them verbatim
from the old p10 recipe (and i don't think i have a choice since i
can't get [b]yacc to run anyway, as it simply generates a usage
error).

so all i'm after is, needing to avoid running yacc again, to know
what i need to steal from the p10 patches. i have patches touching all
of (and more):

* keyword-gen.c
* ntp_keyword.h
* ntp_parser.[chy]

i've tried to selectively copy what look like the appropriate files
into the appropriate locations but, no matter what i do, the build
process insists on running byacc again, and chokes.

so focusing exclusively on the parser component, is there a simple
list of what i need to copy in/patch verbatim to effect the same
changes without the build trying to regenerate the parser files? once
i have that, i can obviously add the final support code that
recognizes the new parser tokens.

thoughts? am i even looking at this the right way?

rday


How to get packages version from an image recipe #yocto #linux

zakaria.zidouh@...
 

Hello,
 
I want to get the version of the packages generated by a recipe from the image recipe (or by a python script that runs outside of the package generating recipe). (like the output of the bitbake -s command)
 
Do you have any ideas please?
 
Thank you


[Meta-Java] Error while installing jamvm #yocto #dunfell

Vijay Rakesh Munganda
 

Hi,

I have download meta-java layer and added to the conf/bblayer.conf file, then added jamvm to conf/local.conf file and ran bitbake command, but I got this error as "Nothing RPROVIDES 'jamvm' (but /home/bl-docker/rity/src/poky/../meta-mediatek-bsp/recipes-core/images/mtk-image.bb RDEPENDS on or otherwise requires it) jamvm was skipped: incompatible with machine i500-pumpkin (not in COMPATIBLE_MACHINE)"

Recipe file path is under /src/meta-java/recipes-core/jamvm/jamvm_git.bb. Did I miss anything or does my target board has any compatibility issue? 

Thanks & Regards,
Vijay Rakesh


Building U-Boot 2014.10 in Poky Thud 2.6 do_compile failing tools/mkimage #uboot #yocto

Jeff Schuler
 

Hello!

I've recently started porting my recipes from Poky Jethro 2.0 to Poky Thud 2.6, and am having an issue building U-Boot. I've read through each stage of the migration guide https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release and made several changes, but can't seem to figure this one out. 

do_compile is failing target tools, something to do with dtc-native is my theory. Command I'm running: bitbake -fc compile virtual/bootloader

Here's a snippet of the failure:

| In file included from /home/jschuler/yocto/poky-thud-2.6/builds/board-sensor-chevy/tmp/work/board_sensor_chevy-poky-linux-gnueabi/u-boot-custom-socfpga/2014.10.20-r0/git/tools/fdt_host.h:11:0,
|                  from /home/jschuler/yocto/poky-thud-2.6/builds/board-sensor-chevy/tmp/work/board_sensor_chevy-poky-linux-gnueabi/u-boot-custom-socfpga/2014.10.20-r0/git/tools/mkimage.h:22,
|                  from /home/jschuler/yocto/poky-thud-2.6/builds/board-sensor-chevy/tmp/work/board_sensor_chevy-poky-linux-gnueabi/u-boot-custom-socfpga/2014.10.20-r0/git/tools/mkimage.c:11:
| /home/jschuler/yocto/poky-thud-2.6/builds/board-sensor-chevy/tmp/work/board_sensor_chevy-poky-linux-gnueabi/u-boot-custom-socfpga/2014.10.20-r0/git/tools/../include/libfdt.h:1442:19: note: previous definition of 'fdt_appendprop_cell' was here
|  static inline int fdt_appendprop_cell(void *fdt, int nodeoffset,
|                    ^~~~~~~~~~~~~~~~~~~
| scripts/Makefile.host:134: recipe for target 'tools/mkimage.o' failed
| make[2]: *** [tools/mkimage.o] Error 1
| /home/jschuler/yocto/poky-thud-2.6/builds/board-sensor-chevy/tmp/work/board_sensor_chevy-poky-linux-gnueabi/u-boot-custom-socfpga/2014.10.20-r0/git/Makefile:1038: recipe for target 'tools' failed
| make[1]: *** [tools] Error 2
| Makefile:134: recipe for target 'sub-make' failed
| make: *** [sub-make] Error 2
| make: Leaving directory '/home/jschuler/yocto/poky-thud-2.6/builds/board-sensor-chevy/tmp/work/board_sensor_chevy-poky-linux-gnueabi/u-boot-custom-socfpga/2014.10.20-r0/git'
| ERROR: oe_runmake failed
Does anyone know what the problem may be here? Please let me know if I should include complete recipes or logs, happy to do so!

U-Boot recipe:  recipes-bsp/u-boot/u-boot-custom-socfpga_2014.10.20.bb

require u-boot-custom-socfpga.inc
 
SRC_URI = " \
    git://github.com/altera-opensource/u-boot-socfpga.git;tag=rel_socfpga_v2014.10_arria10_bringup_20.07.02_pr;nobranch=1 \
"
 
SRC_URI_append_board-sensor-chevy = " \
      file://board-sensor-chevy/0001-chevy-sensor-support-files-2021.patch \
      file://board-sensor-chevy/0002-Add-environment-overrride-for-F2H-SDRAM2-bridge-init.patch \
"
 
S = "${WORKDIR}/git"
LIC_FILES_CHKSUM = "file://Licenses/README;md5=c7383a594871c03da76b3707929d2919"
COMPATIBLE_MACHINE = "(board-sensor-chevy)"
The .inc file that recipe includes has this in it:

# Leverage Yocto's existing U-Boot support
require recipes-bsp/u-boot/u-boot.inc
 
# Apply patches with Git to make it easier to make updates from within a
# devshell and bring them back into this recipe as properly-formatted patches
PATCHTOOL = "git"
 
DEPENDS += "dtc-native"
PROVIDES += "u-boot"
 
COMPATIBLE_MACHINE ?= "(board-sensor-chevy)"
UBOOT_SUFFIX ?= "img"
LICENSE = "GPLv2 & LGPLv2 & BSD & MIT"
Plus a couple do_compile_append() and do_deploy_append() operations.

Here is a snippet from the meta u-boot.inc that the recipe is leveraging via include:

SUMMARY = "Universal Boot Loader for embedded devices"
PROVIDES = "virtual/bootloader"
 
B = "${WORKDIR}/build"
 
PACKAGE_ARCH = "${MACHINE_ARCH}"
 
inherit uboot-config uboot-extlinux-config uboot-sign deploy
 
DEPENDS += "swig-native python-native"
 
EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}" V=1'
EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
EXTRA_OEMAKE += 'PYTHON=nativepython STAGING_INCDIR=${STAGING_INCDIR_NATIVE} STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}'


Build info:

Poky Thud Commit: e52122a3e6912575ff401a4af6ac1bf3070092bc
Target OS: 32b ARM Arria 10 SoC
Build Host OS: Ubuntu 18.04.4 x86

Build Host OS python versions present:
jschuler@kuro2:~/yocto/poky-thud-2.6$ python --version
Python 2.7.17
jschuler@kuro2:~/yocto/poky-thud-2.6$ python3 --version
Python 3.6.9
jschuler@kuro2:~/yocto/poky-thud-2.6$ python3.8 --version
Python 3.8.0
I've tried every combination of messing with the DEPENDS += values and feel like this has something to do with dtc-native?

xxxxxx:~/yocto/poky-thud-2.6/builds/board-sensor-chevy/tmp/work/board-sensor-chevy-poky-linux-gnueabi/u-boot-custom-socfpga/2014.10.20-r0$ l
board-sensor-chevy/  build/  configure.sstate  git/  recipe-sysroot/  recipe-sysroot-native/  temp/
The two directories shown above recipe-sysroot and recipe-sysroot-native seem to be present in this build's workdir but were not present when I was building this in Jethro, so perhaps there's something there. 

Does anyone know what might be causing my bitbake tools to be referencing two different fdt tool header files?

Thank you very much for your thoughts.


Re: #yocto #kernel "yocto-check-layer" #yocto #kernel

Monsees, Steven C (US)
 

 

I have gotten much closer with Yocto-check-layer, down to the same error for both layers, all other tests passing…

 

Can someone explain what the error means, and what might be causing it  ?

 

Meta-intel-bsp now showing:

 

INFO: Ran 10 tests in 341.168s

INFO: FAILED

INFO:  (failures=1, skipped=3)

INFO:

INFO: Summary of results:

INFO:

INFO: meta-intel-bsp ... FAIL

 

INFO: ======================================================================

INFO: FAIL: test_signatures (common.CommonCheckLayer)

INFO: ----------------------------------------------------------------------

INFO: Traceback (most recent call last):

  File "/disk0/scratch/smonsees/yocto/workspace_3/poky/scripts/lib/checklayer/cases/common.py", line 55, in test_signatures

    self.fail('Adding layer %s changed signatures.\n%s' % (self.tc.layer['name'], msg))

AssertionError: Adding layer meta-intel-bsp changed signatures.

 

Meta-intel-distro now showing:

 

INFO: Ran 8 tests in 352.407s

INFO: FAILED

INFO:  (failures=1, skipped=1)

INFO:

INFO: Summary of results:

INFO:

INFO: meta-intel-distro ... FAIL

 

INFO: ======================================================================

INFO: FAIL: test_signatures (common.CommonCheckLayer)

INFO: ----------------------------------------------------------------------

INFO: Traceback (most recent call last):

  File "/disk0/scratch/smonsees/yocto/workspace_3/poky/scripts/lib/checklayer/cases/common.py", line 55, in test_signatures

    self.fail('Adding layer %s changed signatures.\n%s' % (self.tc.layer['name'], msg))

AssertionError: Adding layer meta-intel-distro changed signatures.

 

Thanks,

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, February 10, 2021 10:17 AM
To: yocto@...
Subject: Re: [yocto] #yocto #kernel "yocto-check-layer"

 

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.

 

 

Is there documentation on the yocto-check-layer script thtat goes over proper use of command line options ?

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, February 10, 2021 8:55 AM
To: yocto@...
Subject: [yocto] #yocto #kernel "yocto-check-layer"

 

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.

 

 

Mb build was setup and done under one layer, with “distro” and “bsp“ at the same layer, I wanted to split them up into separate layers inorder to better conform to the Yocto standard…. (Note my kernel builds and runs correctly when split or not split)

 

When not split “Yocto-check-layer” calls me out for having “distro” and “bsp” in same layer, when I split them I am seeing the following for each new layer:

 

Can someone explain the errors the script is reporting and how to resolve (these are not seen build the split or non-split images) ?

 

08:43 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>yocto-check-layer /disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO: Detected layers:

INFO: meta-intel-bsp: LayerType.BSP, /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO:

INFO: Setting up for meta-intel-bsp(LayerType.BSP), /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO: Getting initial bitbake variables ...

INFO: Getting initial signatures ...

INFO: Generating signatures failed. This might be due to some parse error and/or general layer incompatibilities.

Command: BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE BB_SIGNATURE_HANDLER" BB_SIGNATURE_HANDLER="OEBasicHash" bitbake -S none world

Output:

Parsing recipes...done.

Parsing of 2450 .bb files complete (0 cached, 2450 parsed). 3645 targets, 91 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

ERROR: Nothing RPROVIDES 'shim' (but /disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-core/packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it)

NOTE: Runtime target 'shim' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['shim']

ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'packagegroup-base', 'shim']

 

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

 

INFO:

INFO: Summary of results:

INFO:

INFO: meta-intel-bsp ... FAIL (Generating world signatures)

08:44 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>yocto-check-layer /disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO: Detected layers:

INFO: meta-intel-distro: LayerType.DISTRO, /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO:

INFO: Setting up for meta-intel-distro(LayerType.DISTRO), /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO: Getting initial bitbake variables ...

INFO: Getting initial signatures ...

INFO: Generating signatures failed. This might be due to some parse error and/or general layer incompatibilities.

Command: BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE BB_SIGNATURE_HANDLER" BB_SIGNATURE_HANDLER="OEBasicHash" bitbake -S none world

Output:

Loading cache...done.

Loaded 3645 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

ERROR: Nothing RPROVIDES 'seloader' (but /disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-core/packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it)

NOTE: Runtime target 'seloader' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['seloader']

ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'packagegroup-base', 'seloader']

 

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

 

INFO:

INFO: Summary of results:

INFO:

INFO: meta-intel-distro ... FAIL (Generating world signatures)

08:46 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>

 

Thanks,

Steve


Re: #yocto #kernel "yocto-check-layer" #yocto #kernel

Anuj Mittal
 

On Wed, 2021-02-10 at 13:55 +0000, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
 
Mb build was setup and done under one layer, with “distro” and “bsp“
at the same layer, I wanted to split them up into separate layers
inorder to better conform to the Yocto standard…. (Note my kernel
builds and runs correctly when split or not split)
 
When not split “Yocto-check-layer” calls me out for having “distro”
and “bsp” in same layer, when I split them I am seeing the following
for each new layer:
 
Can someone explain the errors the script is reporting and how to
resolve (these are not seen build the split or non-split images) ?
 
08:43 smonsees@yix490031
/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-
limws/builds/sbcb-default>yocto-check-layer
/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-
limws/meta-intel/meta-intel-bsp
INFO: Detected layers:
INFO: meta-intel-bsp: LayerType.BSP,
/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-
intel/meta-intel-bsp
INFO:
INFO: Setting up for meta-intel-bsp(LayerType.BSP),
/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-
intel/meta-intel-bsp
INFO: Getting initial bitbake variables ...
INFO: Getting initial signatures ...
INFO: Generating signatures failed. This might be due to some parse
error and/or general layer incompatibilities.
Command: BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE BB_SIGNATURE_HANDLER"
BB_SIGNATURE_HANDLER="OEBasicHash" bitbake -S none world
Output:
Parsing recipes...done.
Parsing of 2450 .bb files complete (0 cached, 2450 parsed). 3645
targets, 91 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'shim' (but
/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-
core/packagegroups/packagegroup-base.bb RDEPENDS on or otherwise
requires it)
NOTE: Runtime target 'shim' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['shim']
ERROR: Required build target 'meta-world-pkgdata' has no buildable
providers.
Missing or unbuildable dependency chain was: ['meta-world-pkgdata',
'packagegroup-base', 'shim']
It looks like this packagegroup has a RDEPENDS on "shim" while the code
can't find the recipe. If that RDEPENDS is correct, this layer probably
needs to add a LAYERDEPENDS on a layer that has this recipe in
layer.conf.


Thanks,

Anuj


Re: #yocto #kernel "yocto-check-layer" #yocto #kernel

Monsees, Steven C (US)
 

 

Is there documentation on the yocto-check-layer script thtat goes over proper use of command line options ?

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, February 10, 2021 8:55 AM
To: yocto@...
Subject: [yocto] #yocto #kernel "yocto-check-layer"

 

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.

 

 

Mb build was setup and done under one layer, with “distro” and “bsp“ at the same layer, I wanted to split them up into separate layers inorder to better conform to the Yocto standard…. (Note my kernel builds and runs correctly when split or not split)

 

When not split “Yocto-check-layer” calls me out for having “distro” and “bsp” in same layer, when I split them I am seeing the following for each new layer:

 

Can someone explain the errors the script is reporting and how to resolve (these are not seen build the split or non-split images) ?

 

08:43 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>yocto-check-layer /disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO: Detected layers:

INFO: meta-intel-bsp: LayerType.BSP, /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO:

INFO: Setting up for meta-intel-bsp(LayerType.BSP), /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO: Getting initial bitbake variables ...

INFO: Getting initial signatures ...

INFO: Generating signatures failed. This might be due to some parse error and/or general layer incompatibilities.

Command: BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE BB_SIGNATURE_HANDLER" BB_SIGNATURE_HANDLER="OEBasicHash" bitbake -S none world

Output:

Parsing recipes...done.

Parsing of 2450 .bb files complete (0 cached, 2450 parsed). 3645 targets, 91 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

ERROR: Nothing RPROVIDES 'shim' (but /disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-core/packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it)

NOTE: Runtime target 'shim' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['shim']

ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'packagegroup-base', 'shim']

 

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

 

INFO:

INFO: Summary of results:

INFO:

INFO: meta-intel-bsp ... FAIL (Generating world signatures)

08:44 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>yocto-check-layer /disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO: Detected layers:

INFO: meta-intel-distro: LayerType.DISTRO, /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO:

INFO: Setting up for meta-intel-distro(LayerType.DISTRO), /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO: Getting initial bitbake variables ...

INFO: Getting initial signatures ...

INFO: Generating signatures failed. This might be due to some parse error and/or general layer incompatibilities.

Command: BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE BB_SIGNATURE_HANDLER" BB_SIGNATURE_HANDLER="OEBasicHash" bitbake -S none world

Output:

Loading cache...done.

Loaded 3645 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

ERROR: Nothing RPROVIDES 'seloader' (but /disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-core/packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it)

NOTE: Runtime target 'seloader' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['seloader']

ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'packagegroup-base', 'seloader']

 

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

 

INFO:

INFO: Summary of results:

INFO:

INFO: meta-intel-distro ... FAIL (Generating world signatures)

08:46 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>

 

Thanks,

Steve


Re: curl certificate error

Mauro Ziliani
 

Thank you.

I have included the dependencies, but curl miss the CAfile.

I have to fix the right full path by CURL_CA_BUNDLE in the recipe which uses curl-native


I have changed TMP variabile in conf/local.conf

Now TMP:=mytmp  (the default value was tmp)


curl looks for CAFile in

/home/mauro/yocto/krogoth/bin/tmp/sysroot/x86_64/etc/ssl/certs/ca-certificates.crt

while the file i in

/home/mauro/yocto/krogoth/bin/mytmp/sysroot/x86_64/etc/ssl/certs/ca-certificates.crt


In the recipe I put


CURL_CA_BUNDLE=${STAGING_DIR_NATIVE}/etc/ssl/certs/ca-certificates.crt

export CURL_CA_BUNDLE


Now curl works fine


Thanks again

  MZ


Il 10/02/21 13:15, Quentin Schulz ha scritto:

Hi Mauro,

On Wed, Feb 10, 2021 at 01:11:07PM +0100, Mauro Ziliani wrote:
Hi all
I try to download the file

https://github.com/google/googletest/archive/release-1.8.0.tar.gz

with curl -L inside a devshell of a recipe


I get this error


curl: (77) error setting certificate verify locations:
  CAfile: /Sources/softfx/krogoth/softfx-build/tmp/sysroots/x86_64-linux/etc/ssl/certs/ca-certificates.crt
  CApath: none

Missing ca-certificates-native somewhere in the dependency chain. I
honestly thought curl-native would bring it, but does not seem so. I
personally added ca-certificates-native to the DEPENDS of the recipe
needing curl-native for a quick fix since I'm in the middle of an
upgrade and will not use krogoth anymore.

Cheers,
Quentin


#yocto #kernel "yocto-check-layer" #yocto #kernel

Monsees, Steven C (US)
 

 

Mb build was setup and done under one layer, with “distro” and “bsp“ at the same layer, I wanted to split them up into separate layers inorder to better conform to the Yocto standard…. (Note my kernel builds and runs correctly when split or not split)

 

When not split “Yocto-check-layer” calls me out for having “distro” and “bsp” in same layer, when I split them I am seeing the following for each new layer:

 

Can someone explain the errors the script is reporting and how to resolve (these are not seen build the split or non-split images) ?

 

08:43 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>yocto-check-layer /disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO: Detected layers:

INFO: meta-intel-bsp: LayerType.BSP, /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO:

INFO: Setting up for meta-intel-bsp(LayerType.BSP), /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-bsp

INFO: Getting initial bitbake variables ...

INFO: Getting initial signatures ...

INFO: Generating signatures failed. This might be due to some parse error and/or general layer incompatibilities.

Command: BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE BB_SIGNATURE_HANDLER" BB_SIGNATURE_HANDLER="OEBasicHash" bitbake -S none world

Output:

Parsing recipes...done.

Parsing of 2450 .bb files complete (0 cached, 2450 parsed). 3645 targets, 91 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

ERROR: Nothing RPROVIDES 'shim' (but /disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-core/packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it)

NOTE: Runtime target 'shim' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['shim']

ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'packagegroup-base', 'shim']

 

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

 

INFO:

INFO: Summary of results:

INFO:

INFO: meta-intel-bsp ... FAIL (Generating world signatures)

08:44 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>yocto-check-layer /disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO: Detected layers:

INFO: meta-intel-distro: LayerType.DISTRO, /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO:

INFO: Setting up for meta-intel-distro(LayerType.DISTRO), /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/meta-intel-distro

INFO: Getting initial bitbake variables ...

INFO: Getting initial signatures ...

INFO: Generating signatures failed. This might be due to some parse error and/or general layer incompatibilities.

Command: BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE BB_SIGNATURE_HANDLER" BB_SIGNATURE_HANDLER="OEBasicHash" bitbake -S none world

Output:

Loading cache...done.

Loaded 3645 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

ERROR: Nothing RPROVIDES 'seloader' (but /disk0/scratch/smonsees/yocto/workspace_3/poky/meta/recipes-core/packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it)

NOTE: Runtime target 'seloader' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['seloader']

ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'packagegroup-base', 'seloader']

 

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

 

INFO:

INFO: Summary of results:

INFO:

INFO: meta-intel-distro ... FAIL (Generating world signatures)

08:46 smonsees@yix490031 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>

 

Thanks,

Steve


Re: Duplictae files gets created on opening any file in yocto for rpi cm3 #cm3 #dunfell

Nicolas Jeker
 

On Tue, 2021-02-09 at 21:22 -0800, prashantsingh@dialtronics.com wrote:
Dear team,

I'm using yocto-dunfell for generating for my rpi-cm3.
it is working fine, but one issue I'm facing that when ever I'm
trying to open any file, that gets duplicated with it's name and then
~ sign.
e.g. I'm open hello.sh file, then on saving this file one file will
be automatically generated with the name hello.sh~ .
This thing unnecessarily consuming memory in my file-system.
Are you using vim to edit the files? If yes, then take a look at
"backup files":

https://vimhelp.org/editing.txt.html#backup
Be aware that vim possibly creates swap and undo files, too.
https://vimhelp.org/recover.txt.html#swap-file
https://vimhelp.org/undo.txt.html#undo-persistence

Please assist me some method to get rid with this.

Thanks and Regards.
Prashant Singh


1641 - 1660 of 53914