Date   

Re: #yocto llvm support and meta-clang #yocto

Monsees, Steven C (US)
 

There appears to be an issue with build zeus based meta-clang under zeus platform...

I followed steps off meta-clang page, and from the work I did with meta-clang under "Rocko" about a year ago, a lot has changed under the hood...

Working under zeus 3.0.4... EXT SDK appears fully functional, I require CLANG/LLVM for future development...

Never seen this error before, did I miss a patch or possibly a step ?

Clean build area...

(1) Add meta-clang to bblayers.conf

(2) Added EXT SDK Settings for meta-clang :

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

SDK_EXTRA_TOOLS = " \
nativesdk-cmake \
nativesdk-clang \ <---Only appears to download/build llvm when present
"

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

The build is much slower due to "native-clang-9.0.1-r0 do_compile"...


EXT SDK build error seen:
=========================

10:12 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext
Parsing recipes: 100% |#################################################################################| Time: 0:01:25
Parsing of 2463 .bb files complete (0 cached, 2463 parsed). 3671 targets, 91 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "rhel-7.9"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "sbcb-default"
DISTRO = "limws"
DISTRO_VERSION = "3.0.4"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU = ""
meta
meta-poky = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
meta-perl
meta-python
meta-filesystems
meta-networking
meta-initramfs
meta-oe = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-clang = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-intel = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

NOTE: Fetching uninative binary shim from file:///ede/tms/yocto/zeus/downloads/intel/x86_64-nativesdk-libc.tar.xz;sha256sum=a09922172c3a439105e0ae6b943daad2d83505b17da0aba97961ff433b8c21ab
Initialising tasks: 100% |##############################################################################| Time: 0:00:12
Checking sstate mirror object availability: 100% |######################################################| Time: 0:00:00
Sstate summary: Wanted 2490 Found 2157 Missed 333 Current 0 (86% match, 0% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
ERROR: sbcb-defaultfs-full-1.0-r0 do_sdk_depends: Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:extend_recipe_sysroot(d)
0003:
File: '/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/staging.bbclass', lineno: 551, function: extend_recipe_sysroot
0547: dest = newmanifest[l]
0548: if l.endswith("/"):
0549: staging_copydir(l, targetdir, dest, seendirs)
0550: continue
*** 0551: staging_copyfile(l, targetdir, dest, postinsts, seendirs)
0552:
0553: bb.note("Installed into sysroot: %s" % str(msg_adding))
0554: bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
0555:
File: '/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/staging.bbclass', lineno: 144, function: staging_copyfile
0140: if os.path.islink(c):
0141: linkto = os.readlink(c)
0142: if os.path.lexists(dest):
0143: if not os.path.islink(dest):
*** 0144: raise OSError(errno.EEXIST, "Link %s already exists as a file" % dest, dest)
0145: if os.readlink(dest) == linkto:
0146: return dest
0147: raise OSError(errno.EEXIST, "Link %s already exists to a different location? (%s vs %s)" % (dest, os.readlink(dest), linkto), dest)
0148: os.symlink(linkto, dest)
Exception: FileExistsError: [Errno 17] Link /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/recipe-sysroot/lib already exists as a file: '/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/recipe-sysroot/lib'

ERROR: Logfile of failure stored in: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/temp/log.do_sdk_depends.24732
ERROR: Task (/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_sdk_depends) failed with exit code '1'
NOTE: Tasks Summary: Attempted 6892 tasks of which 5539 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_sdk_depends
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
13:01 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default>



Note: Modifying SDK_EXTRA_TOOLS by removing "nativesdk-clang", i.e.:

SDK_EXTRA_TOOLS = " \
nativesdk-cmake \
"

If I remove, the build is much faster, and it builds without the error, also appears not to require/include
"llvm" component in build.
I do not believe the full package was actually built/enabled, but no errors and image is functional.


13:09 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext
Parsing recipes: 100% |#################################################################################| Time: 0:01:26
Parsing of 2463 .bb files complete (0 cached, 2463 parsed). 3671 targets, 91 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "rhel-7.9"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "sbcb-default"
DISTRO = "limws"
DISTRO_VERSION = "3.0.4"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU = ""
meta
meta-poky = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
meta-perl
meta-python
meta-filesystems
meta-networking
meta-initramfs
meta-oe = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta-clang = "zeus:f5355ca9b86fb5de5930132ffd95a9b352d694f9"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-intel = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

NOTE: Fetching uninative binary shim from file:///ede/tms/yocto/zeus/downloads/intel/x86_64-nativesdk-libc.tar.xz;sha256sum=a09922172c3a439105e0ae6b943daad2d83505b17da0aba97961ff433b8c21ab
Initialising tasks: 100% |##############################################################################| Time: 0:00:12
Checking sstate mirror object availability: 100% |######################################################| Time: 0:00:00
Sstate summary: Wanted 2436 Found 2407 Missed 29 Current 0 (98% match, 0% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
NOTE: Tasks Summary: Attempted 6767 tasks of which 6223 didn't need to be rerun and all succeeded.
13:31 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default>

-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Tuesday, April 20, 2021 12:02 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>; Anton Antonov <anton.antonov@arm.com>; yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto llvm support

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.



On 4/20/21 7:00 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
I noticed similar behavior.

I am running zeus 3.0.4, "devtool sdk-install llvm" will get llvm
8.0.1.

When I build meta-clang, and I set TOOLCHAIN?="clang" in local.conf it
appears to grab llvm-project-source-9.0.1-9.0.1.
this is intentional, when you use meta-clang, then llvm is preferred from LLVM since them we have consistent version of llvm for clang and others.

*From:*yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On
Behalf Of *Anton Antonov
*Sent:* Tuesday, April 20, 2021 9:51 AM
*To:* yocto@lists.yoctoproject.org
*Subject:* Re: [yocto] #yocto llvm support

*_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.


Hi Steven,

  I used meta-clang in my recipes and I noticed that:
1. The current release of poky uses LLVM v11.1.0 by default
(poky/meta/recipes-devtools/llvm/llvm_git.bb)
2. Meta-clang requires LLVM v12.0.0 (meta-clang/conf/layer.conf
defines LLVMVERSION = "12.0.0")

As a result just including meta-clang into bblayers.conf will require
bitbake to build a new version of LLVM and rebuild everything which
uses it

Anton





Yocto Technical Team Minutes, Engineering Sync, for April 20, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for April 20, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== announcements ==
The upcoming Yocto Project Summit is taking place May 25-26 2021
details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
CfP: https://pretalx.com/yocto-project-summit-2021/cfp
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

== 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 Jolley, Armin Kuster, Steve Sakoman, Peter
Kjellerstedt, Alexandre Belloni, Michael Opdenacker, Scott Murray, Jon
Mason, Michael Halstead, Richard Purdie, Bruce Ashfield, Ross Burton, Randy
MacLeod, Saul Wold, Tim Orling, Daiane Angolini

== notes ==
- 3.3 (hardknott) released!!
- 3.1.7 (dunfell) through QA, pending TSC approval
- YP TSC: 3 seats re-elected, 2 seats up for re-election
- master branch open for 3.4 (honister) and things are starting to merge
- new command proposed: bitbake-getvar
- AB issues: 59 (going up)

== general ==
RP: the re-election for OE TSC is coming up in August, but the re-election for
the YP TSC is in May. a call for candidates will be going out soon
TrevorW: do we want to align the voting with the conference?
RP: probably not


MichaelO: is there a 3.3 celebration?
RP: usually we do it at the conferences, but we’ll have to do it at the
virtual one this year
MichaelO: i didn’t see anything on lwn
RP: we don’t have a mechanism for this
MichaelO: there are usually release notes
RP: yocto-announce mailing list
TrevorW: release notes?
RP: yes, PaulE put together some notes
TrevorW: is someone putting a release note together?
MichaelO: okay, i’ll put it together and email internally first
RP: advocacy is less that it was, if people can think of places to
help/advertise that would be great. sometime i publish something in the LF
newsletter


RP: bitbake-getvar, instead of “bitbake -e | grep”. saves people some
keystrokes
RP: uses tinfoil, acts as a very good, very small example of how to write a
small tinfoil tool (e.g. c larson’s bb tool). maybe a way of expanding
this infrastructure to make it easier to add tools in the future, perhaps
expandable in layers itself
RP: also perhaps could be used for layer and config setup (e.g. kas,
combo-layer)
AlexB: sounds great! i often show students “bitbake -e | grep” and
they’re often surprised and happy to see it
ScottM: +1
RP: it’s in master-next. there are probably a lot of tutorials that will
need updating after this :-) and there are places in selftest where we do
“bitbake -e | grep” (it runs it once then builds a dictionary of the
results to avoid having to run it multiple times throughout the test run)
RossB: it’s similar to bbvars
RP: i’d like to keep it simple, single variable, i don’t want to get too
much scope creep which makes it more complicated. not meant to solve all
problems, just solve one elegantly. if we add something to take multiple
vars then we’d have to return JSON (?) or something else that would be
machine-parsable
RP: i think a separate command to do multiple vars would be best


PeterK: don't forget to move poky-conf back to master
RP: ah, thanks


Saul: CentOS 8 issues, grrr
RP: i haven’t looked into it
Saul: i think qemu is dying and qmp is trying to read the linux socket and
getting nothing. maybe i could take out the centos builder for a while
RP: sounds reasonable. if you want to pull one builder out to work on it, that
would be fine
Saul: i’ll talk to MichaelH about it


Saul: any cmake experts out there?
<crickets>
Saul: i have a nasty cmake + python issue wrt ceph: it doesn’t find the
core gcc libraries, sysroot being set to /not/exist. i think there’s an
environment passing issue between cmake and the python
RP: that /not/exist is something *we* hardcode into the compiler to make sure
sysroot gets set
Bruce: have a look at what we did in libvirt recently. we had a similar issue
with meson whereby it couldn’t find getent from libc. we had to create a
patch. meson+cmake couldn’t find getent from libc
RossB: i’ll take a look at your patch Bruce, meson acts strange in some
ways, but sometimes there’s a way to straighten it out


ScottM: Steve: 3.1.7 this week?
SteveS: up to TSC to approve it
RP: it’s through QA, QA didn’t flag any issues (there was one failure but
it succeeded on a subsequent build). the TSC meeting is later today, so if
they approve it’ll be out by tomorrow


Randy: latency monitoring. turned down from 10 to 6 seconds, tuned timeout
from 5 to 15 seconds. new column in AB console to link to this new data.
generates graphs of “time to dd 100 kb periodically” to hopefully help
correlate failures with load. we usually see 3-5 seconds but sometimes 50s
for unexplained reasons
RP: that’s very interesting. but we still don’t know what the system is
doing at those times when we see the 20. it’s one thing to know it’s
happening, it’s another to know why. i’ve noticed that webkit builds
add a lot of load, also compression adds a lot of load (xz)
Randy: behind on the rust things since i’ve been working on this


RP: speaking of languages, Go also worries me. Go has 2 issues: the fetcher
is messy and builds are not reproducible. are there any Go experts in our
community who can help?
TimO: Bruce and I have been struggling over a bunch of things, but it’s not
fun
Bruce: working on something; i’m currently up to 37 fetches, but it’s not
just fetching but also a layout issue. if you fetch something to “c/a”
but Go expects to find it at “a” then it won’t use it
Randy: someone wrote a cargo module for Rust to do something similar (i.e. a
translation between Rust and bitbake), would that pattern be useful here?
Bruce: probably, hard to know at what point we need to make deep changes vs
patches on the surface. the “make” infrastructure doesn’t help, too
many hard-coded paths and options in the Go  “make” files
RP: and that’s only ½ the problem (still have build reproducibility issues)
Bruce: Khem can bump the Go version, but then we need to chase after all these
fixes


Randy: suricata?
Armin: yes, those are in meta-security now, donated by ARM
Randy: did you use a cargo build
Armin: it was a couple things, had to start with one but then switch over
partway


TrevorW: is there any update on the “layout of where patches go” work?
RP: you mean “work directory” vs “source directory”?
RP: pretty invasive things, put it aside for now. a change like this will end
up causing lots of follow-on issues for weeks to come. the cleanup would
be nice, don’t know if the cost is worth it and would eat up my time for
a while. although i agree the time would be best now to do it (start of
new release). i think this is the second time i’ve tried


RP: parallel make job server (another such example of something I’ve looked
at and think would be nice, but have had to put aside for the time-being)
RP: the todo list isn’t too bad, but it’s something that fell off to the
side.
RP: i get the feeling that some of the things Randy is trying to track down
(load on AB servers) might end up being helped by having a parallel job
server, but we just don’t know
ScottM: is that branch still around. i’m interested in tinkering with it
RP: ignore the branch, just take the commit.
RP: i had hard-coded the fifo to one place (/tmp) on the machine, which means
every build on that machine is tied together. is that good or bad?
ScottM: is that something you could see being global for all bitbake on the
machine
RP: as long as all the builds are being run by the same user. probably need to
create a separate fifo, give it a relevant name, and place it somewhere
where each user can access it themselves. maybe i should try it on the AB
and see what blows up


Re: [meta-security][PATCH] packagegroup-core-security: exclude apparmor in mips64

Khem Raj
 

On 4/20/21 7:41 AM, Armin Kuster wrote:
Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 9ac0d2c..a6142a8 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -80,6 +80,9 @@ RDEPENDS_packagegroup-security-mac = " \
${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack", "",d)} \
"
+RDEPENDS_packagegroup-security-mac_remove_mips64 = "apparmor"
+RDEPENDS_packagegroup-security-mac_remove_mips64le = "apparmor"
+
this should be mips64el

RDEPENDS_packagegroup-meta-security-ptest-packages = "\
ptest-runner \
samhain-standalone-ptest \


Re: #yocto llvm support #yocto

Khem Raj
 

On 4/20/21 7:00 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
I noticed similar behavior…
I am running zeus 3.0.4, “devtool sdk-install llvm” will get llvm 8.0.1…
When I build meta-clang, and I set TOOLCHAIN?=”clang” in local.conf it appears to grab llvm-project-source-9.0.1-9.0.1…
this is intentional, when you use meta-clang, then llvm is preferred from LLVM since them we have consistent version of llvm for clang and others.

*From:*yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> *On Behalf Of *Anton Antonov
*Sent:* Tuesday, April 20, 2021 9:51 AM
*To:* yocto@lists.yoctoproject.org
*Subject:* Re: [yocto] #yocto llvm support
*_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.
Hi Steven,
  I used meta-clang in my recipes and I noticed that:
1. The current release of poky uses LLVM v11.1.0 by default (poky/meta/recipes-devtools/llvm/llvm_git.bb)
2. Meta-clang requires LLVM v12.0.0 (meta-clang/conf/layer.conf defines LLVMVERSION = "12.0.0")
As a result just including meta-clang into bblayers.conf will require bitbake to build a new version of LLVM and rebuild everything which uses it
Anton


Yocto Project Status WW16`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M1

Next Deadline: 7th June 2021 YP 3.4 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3 has been released. Thanks go to everyone who contributed to it!
  • YP 3.1.7 has come cleanly through QA and is pending TSC approval for release.
  • The YP TSC has now served for two years, thanks go to the outgoing TSC (Armin, Denys, Khem, Richard, Ross) who have been instrumental in a number of significant project developments over that time such as the LTS, definition of processes and resourcing the project. Some of the work isn’t immediately obvious but has shaped the project and should ensure a stable and positive future direction.
  • New TSC members are now being chosen for the next two years. Three of the TSC seats have now been (re-)elected by the YP members and those seats are being filled by Richard (chair), Khem and Ross. Two are elected by the OE community and there will be a call for candidates coming soon from the OE board to the OE membership.
  • The master branch has opened for 3.4 development and a number of patches queued during release of 3.3 have now merged.
  • There may be interest in a new command, “bitbake-getvar” being proposed on the bitbake mailing list and in master-next. This makes it easier to see the history of a single variable and also makes a neat example of using the tinfoil API. We are also considering other similar helper commands (maybe along the lines of the ‘bb’ tool) with a view to making things easier for new users.
  • Intermittent autobuilder issues continue to occur and are now at a record high level. You  can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.3 Milestone Dates:

  • YP 3.3 is released.

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 build date 2021/06/07
  • YP 3.4 M1 Release date 2021/06/18
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.7 is out of QA.
  • YP 3.2.4 build date 2021/05/3
  • YP 3.2.4 release date 2021/05/14
  • YP 3.1.8 build date 2021/05/17
  • YP 3.1.8 release date 2021/05/28
  • YP 3.3.1 build date 2021/05/24
  • YP 3.3.1 release date 2021/06/04
  • YP 3.1.9 build date 2021/06/21
  • YP 3.1.9 release date 2021/07/02
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.3.2 build date 2021/08/09
  • YP 3.3.2 release date 2021/08/20
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


[meta-security][PATCH] packagegroup-core-security: exclude apparmor in mips64

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 9ac0d2c..a6142a8 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -80,6 +80,9 @@ RDEPENDS_packagegroup-security-mac = " \
${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack", "",d)} \
"

+RDEPENDS_packagegroup-security-mac_remove_mips64 = "apparmor"
+RDEPENDS_packagegroup-security-mac_remove_mips64le = "apparmor"
+
RDEPENDS_packagegroup-meta-security-ptest-packages = "\
ptest-runner \
samhain-standalone-ptest \
--
2.17.1


Re: #yocto llvm support #yocto

Monsees, Steven C (US)
 

 

So, does anyone know proper usage here?

 

Is this a fully functional llvm drop under ../poky/meta/recipes-devtools ?

Is it compatible with meta-clang?, and can they be used together to build 3rd party extensions for my platform ?

 

Is it better to add supported components this way rather than building them in directly to EXT SDK ?

 

Also, any known issues with meta-clang under zeus 3.0.4 ?

 

Thanks,

Steve

 

From: Monsees, Steven C (US)
Sent: Tuesday, April 20, 2021 10:01 AM
To: 'Anton Antonov' <anton.antonov@...>; yocto@...
Subject: RE: [yocto] #yocto llvm support

 

 

I noticed similar behavior…

 

I am running zeus 3.0.4, “devtool sdk-install llvm” will get llvm 8.0.1…

 

When I build meta-clang, and I set TOOLCHAIN?=”clang” in local.conf it appears to grab llvm-project-source-9.0.1-9.0.1…

 

From: yocto@... <yocto@...> On Behalf Of Anton Antonov
Sent: Tuesday, April 20, 2021 9:51 AM
To: yocto@...
Subject: Re: [yocto] #yocto llvm support

 

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.


Hi Steven,

  I used meta-clang in my recipes and I noticed that:
1. The current release of poky uses LLVM v11.1.0 by default (poky/meta/recipes-devtools/llvm/llvm_git.bb)
2. Meta-clang requires LLVM v12.0.0 (meta-clang/conf/layer.conf defines LLVMVERSION = "12.0.0")

As a result just including meta-clang into bblayers.conf will require bitbake to build a new version of LLVM and rebuild everything which uses it

Anton


Re: #yocto llvm support #yocto

Monsees, Steven C (US)
 

 

I noticed similar behavior…

 

I am running zeus 3.0.4, “devtool sdk-install llvm” will get llvm 8.0.1…

 

When I build meta-clang, and I set TOOLCHAIN?=”clang” in local.conf it appears to grab llvm-project-source-9.0.1-9.0.1…

 

From: yocto@... <yocto@...> On Behalf Of Anton Antonov
Sent: Tuesday, April 20, 2021 9:51 AM
To: yocto@...
Subject: Re: [yocto] #yocto llvm support

 

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.


Hi Steven,

  I used meta-clang in my recipes and I noticed that:
1. The current release of poky uses LLVM v11.1.0 by default (poky/meta/recipes-devtools/llvm/llvm_git.bb)
2. Meta-clang requires LLVM v12.0.0 (meta-clang/conf/layer.conf defines LLVMVERSION = "12.0.0")

As a result just including meta-clang into bblayers.conf will require bitbake to build a new version of LLVM and rebuild everything which uses it

Anton


Re: #yocto llvm support #yocto

Anton Antonov
 

Hi Steven,

  I used meta-clang in my recipes and I noticed that:
1. The current release of poky uses LLVM v11.1.0 by default (poky/meta/recipes-devtools/llvm/llvm_git.bb)
2. Meta-clang requires LLVM v12.0.0 (meta-clang/conf/layer.conf defines LLVMVERSION = "12.0.0")

As a result just including meta-clang into bblayers.conf will require bitbake to build a new version of LLVM and rebuild everything which uses it

Anton


Re: #yocto #sdk SDK_EXTRA_TOOLS inclussion of python-native and devtool #yocto #sdk

Monsees, Steven C (US)
 

 

Any one seen this before… ?

 

SDK appears to be working okay without the inclusion of native python3 components, not sure how the inclusion breaks devtool…

 

From: Monsees, Steven C (US)
Sent: Wednesday, April 14, 2021 2:23 PM
To: 'yocto@...' <yocto@...>
Subject: #yocto #sdk SDK_EXTRA_TOOLS inclussion of python-native and devtool

 

 

Working with zeus 3.0.4, extended SDK…

 

Could someone explain what I overlooked, or why this issue pops up with python-native support inclusion ?

 

Thanks…

 

When I add in native-python3 support

 

#

# Additional SDK Setup variables

#

 

SDKIMAGE_FEATURES_append = " staticdev-pkgs"

 

SDK_EXTRA_TOOLS = "  \

     nativesdk-python3-pprint \

     nativesdk-python3-pickle \

     nativesdk-python3-shell \

     nativesdk-python3-modules \

     nativesdk-python3-distutils \

     nativesdk-python3-xml \

     nativesdk-python3-compile \

     nativesdk-python3-six \

     nativesdk-cmake \

     "

 

TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"

 

I see the following error with devtool:

 

13:07 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH

13:08 smonsees@yix490016 /disk0/scratch/smonsees>. /disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux

SDK environment now set up; additionally you may now run devtool to perform development tasks.

Run devtool --help for further details.

13:08 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help

/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3: /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real: /opt/limws/3.0.4/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

/disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3: line 5: /disk0/scratch/smonsees/aioxSDK_EXT_FULL/sysroots/x86_64-pokysdk-linux/usr/bin/python3.7.real: Success

 

If I remove the “native-python” components, the issue goes away:

 

SDK_EXTRA_TOOLS = "  \

    nativesdk-cmake \

    "

 

14:09 smonsees@yix490016 /disk0/scratch/smonsees> unset LD_LIBRARY_PATH

14:11 smonsees@yix490016 /disk0/scratch/smonsees>. /disk0/scratch/smonsees/aioxSDK_EXT_FULL/environment-setup-aarch64-poky-linux

SDK environment now set up; additionally you may now run devtool to perform development tasks.

Run devtool --help for further details.

14:11 smonsees@yix490016 /disk0/scratch/smonsees>devtool --help

NOTE: Starting bitbake server...

usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]

               [--color COLOR] [-h]

               <subcommand> ...

 

OpenEmbedded development tool

 

options:

  --basepath BASEPATH   Base directory of SDK / build directory

  --bbpath BBPATH       Explicitly specify the BBPATH, rather than getting it

                        from the metadata

  -d, --debug           Enable debug output

  -q, --quiet           Print only errors

  --color COLOR         Colorize output (where COLOR is auto, always, never)

  -h, --help            show this help message and exit

 

subcommands:

  Beginning work on a recipe:

    add                   Add a new recipe

    modify                Modify the source for an existing recipe

    upgrade               Upgrade an existing recipe

  Getting information:

    status                Show workspace status

    search                Search available recipes

    latest-version        Report the latest version of an existing recipe

    check-upgrade-status  Report upgradability for multiple (or all) recipes

  Working on a recipe in the workspace:

    build                 Build a recipe

    rename                Rename a recipe file in the workspace

    edit-recipe           Edit a recipe file

    find-recipe           Find a recipe file

    configure-help        Get help on configure script options

    update-recipe         Apply changes from external source tree to recipe

    reset                 Remove a recipe from your workspace

    finish                Finish working on a recipe in your workspace

  Testing changes on target:

    deploy-target         Deploy recipe output files to live target machine

    undeploy-target       Undeploy recipe output files in live target machine

    package               Build packages for a recipe

    build-image           Build image including workspace recipe packages

    runqemu               Run QEMU on the specified image

  Advanced:

    build-sdk             Build a derivative SDK of this one

    extract               Extract the source for an existing recipe

    sync                  Synchronize the source tree for an existing recipe

    export                Export workspace into a tar archive

    import                Import exported tar archive into workspace

    menuconfig            Alter build-time configuration for a recipe

  SDK maintenance:

    sdk-update            Update SDK components

    sdk-install           Install additional SDK components

Use devtool <subcommand> --help to get help on a specific command

14:11 smonsees@yix490016 /disk0/scratch/smonsees>

 

 


Re: [PATCH] linux-yocto/5.4: fix arm defconfig warnings

Bruce Ashfield
 

Obviously this is to the wrong list!

It escaped before I could stop it :D

I've already resent to oe-core.

Bruce

On Tue, Apr 20, 2021 at 8:31 AM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:


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

A recent fix to the kern-tools promoted some previously unseen
issues to warnings. This commit fixes them by tagging some BT
options as non-hardware so they won't generate warnings if they
don't appear in the final .config. These are sub BT options and
shouldn't warn when/if their controlling option is disabled by
a fragment.

d7fd0213b75 base: exclude some BT options as non-hardware

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_5.4.bb | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
index e52c9ebe0e..a802a570a1 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
@@ -12,7 +12,7 @@ python () {
}

SRCREV_machine ?= "324e77d816cf6434507ab29140beb24044009efa"
-SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255"
+SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642"

SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.4;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
index f07375c761..1edc632de7 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"

SRCREV_machine_qemuarm ?= "8463db325b93f0669446f68c19334cfe11ffb9c2"
SRCREV_machine ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a"
-SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255"
+SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642"

PV = "${LINUX_VERSION}+git${SRCPV}"

diff --git a/meta/recipes-kernel/linux/linux-yocto_5.4.bb b/meta/recipes-kernel/linux/linux-yocto_5.4.bb
index 4f056d6d82..3a9463af6a 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.4.bb
@@ -23,7 +23,7 @@ SRCREV_machine_qemux86 ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a"
SRCREV_machine_qemux86-64 ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a"
SRCREV_machine_qemumips64 ?= "996fe040c8d8d01a9af6be42dae3844d127471bf"
SRCREV_machine ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a"
-SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255"
+SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642"

# remap qemuarm to qemuarma15 for the 5.4 kernel
# KMACHINE_qemuarm ?= "qemuarma15"
--
2.19.1



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


#yocto llvm support #yocto

Monsees, Steven C (US)
 

 

Under ../poky/meta/recipes-devtools the is “llvm”…

 

Devtool search <component>

Devtool sdk-install <component>

 

Will add this component to my EXT SDK…

 

Is this a fully functional llvm drop ?,

(i.e. is it compatible with meta-clang?, and can I use them together to build 3rd party extensions for my platform ?)

 

Is it better to add supported components this way rather than building them in directly to EXT SDK ?

 

Thanks,

Steve


Re: what to include in a "hardware bringup image"?

Yoann Congal
 

Hello,

It might be a bit heavy but I usually install a text editor and python-periphery (https://github.com/vsergeev/python-periphery)
(It did not know c-periphery but this is the same author)

Before having full fledged linux drivers, it allows to check devices IDs, make simple requests like get a sensor value or enable a PMIC regulator.

I'm interested in the list of packages you'll end up with... Will you share it here ?

Regards,
--
Yoann Congal
Smile ECS - Expert technique


[PATCH] linux-yocto/5.4: fix arm defconfig warnings

Bruce Ashfield
 

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

A recent fix to the kern-tools promoted some previously unseen
issues to warnings. This commit fixes them by tagging some BT
options as non-hardware so they won't generate warnings if they
don't appear in the final .config. These are sub BT options and
shouldn't warn when/if their controlling option is disabled by
a fragment.

d7fd0213b75 base: exclude some BT options as non-hardware

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_5.4.bb | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
index e52c9ebe0e..a802a570a1 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
@@ -12,7 +12,7 @@ python () {
}

SRCREV_machine ?= "324e77d816cf6434507ab29140beb24044009efa"
-SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255"
+SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642"

SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.4;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
index f07375c761..1edc632de7 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"

SRCREV_machine_qemuarm ?= "8463db325b93f0669446f68c19334cfe11ffb9c2"
SRCREV_machine ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a"
-SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255"
+SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642"

PV = "${LINUX_VERSION}+git${SRCPV}"

diff --git a/meta/recipes-kernel/linux/linux-yocto_5.4.bb b/meta/recipes-kernel/linux/linux-yocto_5.4.bb
index 4f056d6d82..3a9463af6a 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.4.bb
@@ -23,7 +23,7 @@ SRCREV_machine_qemux86 ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a"
SRCREV_machine_qemux86-64 ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a"
SRCREV_machine_qemumips64 ?= "996fe040c8d8d01a9af6be42dae3844d127471bf"
SRCREV_machine ?= "5f54b437b6502d3febee553100b2cb2a9e0c5f8a"
-SRCREV_meta ?= "5017570a130f142365dfdcd043d84143fdd6e255"
+SRCREV_meta ?= "d7fd0213b75ce9b6206f63dbdd435ab326598642"

# remap qemuarm to qemuarma15 for the 5.4 kernel
# KMACHINE_qemuarm ?= "qemuarma15"
--
2.19.1


Re: what to include in a "hardware bringup image"?

Mike Looijmans
 

I tend to use a reasonably standard image, usually the one that will evolve into the product, and once the network (usb, ethernet or wifi) is up, use "opkg install" to grab whatever else I need from my build machine on demand.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail

On 15-04-2021 10:24, Robert P. J. Day via lists.yoctoproject.org wrote:
for a current project (and subsequent projects), i want to define a
hardware bringup image; that is, a really basic image chock-full of
low-level utilities for debugging initial board bringup. this means
precious little unnecessary userspace crud that has no value in that
context. (at the moment, the target is aarch64 but, naturally, the
ideal image would be maximally applicable no matter the target.)

i'm thinking of recipes that allow probing/configuration of memory
and busses and that sort of thing. off the top of my head:

* pciutils
* usbutils
* libgpiod
* phytool (or other MDIO probe/debug tools)
* devmem2
* spidev-test/spitools
* i2c-tools

the list can go on and on, and i just ran across this which i had
never seen before:

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/c-periphery/c-periphery_2.3.1.bb?h=master

suggestions? i suspect numerous folks on this list have already done
something like this.

rday

--
Mike Looijmans


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.7.rc1)

Sangeeta Jain
 

Hi All,

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

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

no new issue found

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Pokybuild User
Sent: Wednesday, 14 April, 2021 5:55 AM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.1.7.rc1)


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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.7.rc1


Build hash information:

bitbake: 017a39ed05d065bf28fd38f91bcde8a098300551
meta-arm: 1cf8b975e1c40bf8e8c0bf315db5d4cddcb01a7b
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 4bd62a7e154b8c9e8a114f452d3b062d8d058118
meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: a3de6239e98efafe3668396e69133ffee3d9b27f
poky: 13f4ddf50eccaeed96a40a5f1a1d4173e677e98a



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







Re: Yocto Dunfell: u-boot-fw-utils ERROR #imx6 #yocto #dunfell #swupdtae #libubootenv

Mikko Rapeli
 

Hi,

On Tue, Apr 20, 2021 at 03:24:25AM -0700, anthony.marchand@navocap.com wrote:
Hello,
I'm actually migrating a yocto project zeus version to dunfell LTS to build my imx6 Linux system on this LTS release.

Almost all works fine except the following message I try to understand when I try to compile the image:

---------------------------------------------------------------------------------------------------------------------------------------------------------
ERROR: Multiple .bb files are due to be built which each provide u-boot-fw-utils:                       | ETA:  0:00:01
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb
A list of tasks depending on these providers is shown and may help explain where the dependency comes from.
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique dependees:

Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique dependees:
Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_build
Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_package
Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_prepare_recipe_sysroot
It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful.
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique provides:

Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique rprovides:
u-boot-fw-utils-dev
u-boot-fw-utils-locale
u-boot-fw-utils-dbg
u-boot-fw-utils-staticdev
u-boot-fw-utils-doc
^u-boot-fw-utils-locale-.*
u-boot-fw-utils-src
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique provides:
libubootenv
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique rprovides:
libubootenv
libubootenv-src
libubootenv-bin
libubootenv-dbg
libubootenv-doc
^libubootenv-locale-.*
libubootenv-locale
libubootenv-dev
libubootenv-staticdev
---------------------------------------------------------------------------------------------------------------------------------------------------------
Does someone already meet this problem? Do you know what I should look in for to solve it?
Multiple ways to fix this. One is to switch to using dunfell branches for the
BSP SW stack, if they are available. Alternatively you can use the old
zeus based BSP SW stack but for that you need to copy the files which
BSP SW stack depends on poky side from zeus branch to the BSP SW meta layer.

Then things will work out with minor bug fixes or API changes.

For IMX*, I copied the old u-boot recipe files from poky zeus branch over to
the BSP so that meta-freescale* and meta-imx find them and prefer over
the newer u-boot version from poky dunfell branch.

Hope this helps,

-Mikko

Thanks by advance, best reguards.



Yocto Dunfell: u-boot-fw-utils ERROR #imx6 #yocto #dunfell #swupdtae #libubootenv

anthony.marchand@...
 

Hello,
I'm actually migrating a yocto project zeus version to dunfell LTS to build my imx6 Linux system on this LTS release.

Almost all works fine except the following message I try to understand when I try to compile the image:

---------------------------------------------------------------------------------------------------------------------------------------------------------
ERROR: Multiple .bb files are due to be built which each provide u-boot-fw-utils:                       | ETA:  0:00:01
  Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb
  Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb
A list of tasks depending on these providers is shown and may help explain where the dependency comes from.
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique dependees:
  
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique dependees:
  Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_build
  Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_package
  Dunfell/build/../meta-swupdate/recipes-support/swupdate/swupdate_2020.11.bb:do_prepare_recipe_sysroot
It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful.
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique provides:
  
Dunfell/build/../meta-mymeta/recipes-bsp/u-boot/u-boot-fw-utils_2018.09.bb has unique rprovides:
  u-boot-fw-utils-dev
  u-boot-fw-utils-locale
  u-boot-fw-utils-dbg
  u-boot-fw-utils-staticdev
  u-boot-fw-utils-doc
  ^u-boot-fw-utils-locale-.*
  u-boot-fw-utils-src
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique provides:
  libubootenv
Dunfell/build/../openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb has unique rprovides:
  libubootenv
  libubootenv-src
  libubootenv-bin
  libubootenv-dbg
  libubootenv-doc
  ^libubootenv-locale-.*
  libubootenv-locale
  libubootenv-dev
  libubootenv-staticdev
---------------------------------------------------------------------------------------------------------------------------------------------------------
Does someone already meet this problem? Do you know what I should look in for to solve it?

Thanks by advance, best reguards.


[PATCH] [yocto-autobuilder-helper 2/2] scripts/utils.py: Add reporting for yocto-check-layer

Yi Fan Yu
 

The default behavior is to look for a bitbake command,
which fails and produces a confusing output of [-1:].

[YOCTO #14208]

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

diff --git a/scripts/utils.py b/scripts/utils.py
index bf1d989..4c73f81 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -330,6 +330,9 @@ class ErrorReport(object):
elif 'oe-selftest' in command:
report['error_type'] = 'oe-selftest'
failure['task'] = command[command.find('oe-selftest'):]
+ elif 'yocto-check-layer' in command:
+ report['error_type'] = 'check-layer'
+ failure['task'] = command[command.find('yocto-check-layer'):]
else:
report['error_type'] = 'core'
failure['task'] = command[command.find('bitbake'):]
--
2.29.2


[PATCH] [yocto-autobuilder-helper 1/2] config.json: Add default MACHINE qemux86-64

Yi Fan Yu
 

This is the default oe-core MACHINE value.

Prevent error-reporting tool to report simply False.
It was seen in check-layer where the MACHINE wasn't specified.

[YOCTO #14208]

Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
---
config.json | 1 +
1 file changed, 1 insertion(+)

diff --git a/config.json b/config.json
index 962d8ae..2d1a698 100644
--- a/config.json
+++ b/config.json
@@ -26,6 +26,7 @@
"defaults" : {
"NEEDREPOS" : ["poky"],
"DISTRO" : "poky",
+ "MACHINE" : "qemux86-64",
"SDKMACHINE" : "i686",
"PACKAGE_CLASSES" : "package_rpm package_deb package_ipk",
"DLDIR" : "DL_DIR = '${BASE_SHAREDDIR}/current_sources'",
--
2.29.2

1 - 20 of 53165