|
Re: looking to boot core-image-minimal on meta-riscv board
Khem Raj
On Sat, Feb 26, 2022 at 3:46 AM Robert P. J. Day < rpjday@...> wrote: On Fri, 25 Feb 2022, Khem Raj wrote:
> On Fri, Feb 25, 2022 at 8:36 AM Robert P. J. Day <rpjday@...> wrote:
> >
> >
> > a friend of mine is diving into trying to boot linux on a meta-riscv
> > linux starter kit -- he's not using YP, and this is what he's
> > targeting:
> >
> > https://www.aliexpress.com/item/1005003751298305.html
> >
> > since i've wanted to jump into meta-riscv for a while, i figured i'd
> > play along and ordered something more substantial:
> >
> > https://www.aliexpress.com/item/1005002796061251.html
> >
> > in any event, here's the story so far.
> >
> > as a first pass, i just fired up YP and built for qemuriscv64 to
> > establish a baseline, and that seems to work just fine, booting with
> > "runqemu nographic." and that at least gives me a bunch of config info
> > i can look at later.
> >
> > as for my actual target board, i know that the meta-riscv layer
> > defines support for two boards, neither of which is the one i will be
> > getting, but while i'm waiting for it, i can at least start
> > documenting all of the relevant settings and config values i'll want
> > to try.
> >
> > i know precious little about meta-riscv, so is there a sane way to
> > prepare for the eventual arrival of my board? my plan is to get
> > familiar with how the meta-riscv layer builds for the two supported
> > boards, so i'll have a handle on what i'll need to configure.
> >
> > any further advice would be most appreciated.
>
> We should add them to meta-riscv as reference BSPs. I have port of
> unmatched locally and have been trying to get the needed changes
> into meta-sifive which is still pending.
so you have working BSPs for both of those? very cool. warning that
i know effectively nothing about RISC-V but this is apparently my
weekend project to dig into it. i don't see a meta-riscv-specific
mailing list, so i assume if i want to start sending simple patches
for meta-riscv, they would go here?
Usually we use GitHub issues and pulls
already built and tested qemuriscv64, so i guess i'll work backwards
from there and examine the configuration and construction of the
components. opensbi, here we come ...
rday
|
|
|
Re: looking to boot core-image-minimal on meta-riscv board
On Fri, 25 Feb 2022, Khem Raj wrote: On Fri, Feb 25, 2022 at 8:36 AM Robert P. J. Day <rpjday@...> wrote:
a friend of mine is diving into trying to boot linux on a meta-riscv
linux starter kit -- he's not using YP, and this is what he's
targeting:
https://www.aliexpress.com/item/1005003751298305.html
since i've wanted to jump into meta-riscv for a while, i figured i'd
play along and ordered something more substantial:
https://www.aliexpress.com/item/1005002796061251.html
in any event, here's the story so far.
as a first pass, i just fired up YP and built for qemuriscv64 to
establish a baseline, and that seems to work just fine, booting with
"runqemu nographic." and that at least gives me a bunch of config info
i can look at later.
as for my actual target board, i know that the meta-riscv layer
defines support for two boards, neither of which is the one i will be
getting, but while i'm waiting for it, i can at least start
documenting all of the relevant settings and config values i'll want
to try.
i know precious little about meta-riscv, so is there a sane way to
prepare for the eventual arrival of my board? my plan is to get
familiar with how the meta-riscv layer builds for the two supported
boards, so i'll have a handle on what i'll need to configure.
any further advice would be most appreciated.
We should add them to meta-riscv as reference BSPs. I have port of
unmatched locally and have been trying to get the needed changes
into meta-sifive which is still pending. so you have working BSPs for both of those? very cool. warning that i know effectively nothing about RISC-V but this is apparently my weekend project to dig into it. i don't see a meta-riscv-specific mailing list, so i assume if i want to start sending simple patches for meta-riscv, they would go here? already built and tested qemuriscv64, so i guess i'll work backwards from there and examine the configuration and construction of the components. opensbi, here we come ... rday
|
|
|
Re: QA change - reduced number of reproducibility builds tests?
On Fri, 2022-02-25 at 22:00 +0100, Alexander Kanavin wrote: On Fri, 25 Feb 2022 at 21:55, Richard Purdie
<richard.purdie@...> wrote:
Yes, I'll leave the targets available, we'd just run them manually or re-enable
them but I'd take them off a-full for now. With this change, what are the remaining differences between a-full and a-quick? There is quite a bit of difference. oe-selftest on multiple distros vs a single one. It triggers several more minor builds (e.g. edrouter-alt, qemux86-world- alt, ltp targets), runs full ptests rather than ptest-fast, some of the other layers and has the toolchain testing too. Cheers, Richard
|
|
|
Re: looking to boot core-image-minimal on meta-riscv board
Khem Raj
On Fri, Feb 25, 2022 at 8:36 AM Robert P. J. Day <rpjday@...> wrote:
a friend of mine is diving into trying to boot linux on a meta-riscv
linux starter kit -- he's not using YP, and this is what he's
targeting:
https://www.aliexpress.com/item/1005003751298305.html
since i've wanted to jump into meta-riscv for a while, i figured i'd
play along and ordered something more substantial:
https://www.aliexpress.com/item/1005002796061251.html
in any event, here's the story so far.
as a first pass, i just fired up YP and built for qemuriscv64 to
establish a baseline, and that seems to work just fine, booting with
"runqemu nographic." and that at least gives me a bunch of config info
i can look at later.
as for my actual target board, i know that the meta-riscv layer
defines support for two boards, neither of which is the one i will be
getting, but while i'm waiting for it, i can at least start
documenting all of the relevant settings and config values i'll want
to try.
i know precious little about meta-riscv, so is there a sane way to
prepare for the eventual arrival of my board? my plan is to get
familiar with how the meta-riscv layer builds for the two supported
boards, so i'll have a handle on what i'll need to configure.
any further advice would be most appreciated.
We should add them to meta-riscv as reference BSPs. I have port of unmatched locally and have been trying to get the needed changes into meta-sifive which is still pending.
|
|
|
Re: QA change - reduced number of reproducibility builds tests?
Khem Raj
On Fri, Feb 25, 2022 at 10:10 AM Richard Purdie <richard.purdie@...> wrote:
Hi All,
As the project develops, some tests are valuable and some become less valuable
over time.
When we first started reproducible builds work, testing reproducibility heavily
across multiple distros highlighted some unusual bugs and let us improve things.
We therefore currently run a-full with the targets:
reproducibile-centos
reproducibile-debian
reproducibile-fedora
reproducibile-ubuntu
I've noticed we pretty much always see the same set of failures with these
targets now, i.e. if one fails, they all fail the same way.
Those targets are heavy builds which don't reuse sstate for one of the build
streams and hence load the autobuilder heavily.
I'm thinking they've served their purpose and that a-full should go back to just
the randomly selected reproduiclbe target.
Does anyone feel we shouldn't do that?
+1
Cheers,
Richard
|
|
|
Re: QA change - reduced number of reproducibility builds tests?
On Fri, 25 Feb 2022 at 21:55, Richard Purdie <richard.purdie@...> wrote: Yes, I'll leave the targets available, we'd just run them manually or re-enable
them but I'd take them off a-full for now. With this change, what are the remaining differences between a-full and a-quick? Alex
|
|
|
Re: QA change - reduced number of reproducibility builds tests?
On Fri, 2022-02-25 at 13:58 -0600, Joshua Watt wrote: On Fri, Feb 25, 2022 at 12:50 PM Steve Sakoman <steve@...> wrote:
On Fri, Feb 25, 2022 at 8:09 AM Richard Purdie
<richard.purdie@...> wrote:
Hi All,
As the project develops, some tests are valuable and some become less valuable
over time.
When we first started reproducible builds work, testing reproducibility heavily
across multiple distros highlighted some unusual bugs and let us improve things.
We therefore currently run a-full with the targets:
reproducibile-centos
reproducibile-debian
reproducibile-fedora
reproducibile-ubuntu
I've noticed we pretty much always see the same set of failures with these
targets now, i.e. if one fails, they all fail the same way.
Those targets are heavy builds which don't reuse sstate for one of the build
streams and hence load the autobuilder heavily.
I'm thinking they've served their purpose and that a-full should go back to just
the randomly selected reproduiclbe target.
Does anyone feel we shouldn't do that?
I support this. It has been quite some time since dunfell encountered
a distro specific reproducibility issue.
I agree. I assume the change is simple enough to make that we can
bring them back easily if we think it might be helpful is some
scenario? Yes, I'll leave the targets available, we'd just run them manually or re-enable them but I'd take them off a-full for now. Also, just to clarify, those workers will still contribute to the
initial sstate, so they will still help find cross-host reproducible
problems, they just might not find it themselves? Correct, yes. Cheers, Richard
|
|
|
Re: QA change - reduced number of reproducibility builds tests?
On Fri, Feb 25, 2022 at 12:50 PM Steve Sakoman <steve@...> wrote:
On Fri, Feb 25, 2022 at 8:09 AM Richard Purdie
<richard.purdie@...> wrote:
Hi All,
As the project develops, some tests are valuable and some become less valuable
over time.
When we first started reproducible builds work, testing reproducibility heavily
across multiple distros highlighted some unusual bugs and let us improve things.
We therefore currently run a-full with the targets:
reproducibile-centos
reproducibile-debian
reproducibile-fedora
reproducibile-ubuntu
I've noticed we pretty much always see the same set of failures with these
targets now, i.e. if one fails, they all fail the same way.
Those targets are heavy builds which don't reuse sstate for one of the build
streams and hence load the autobuilder heavily.
I'm thinking they've served their purpose and that a-full should go back to just
the randomly selected reproduiclbe target.
Does anyone feel we shouldn't do that?
I support this. It has been quite some time since dunfell encountered
a distro specific reproducibility issue.
I agree. I assume the change is simple enough to make that we can bring them back easily if we think it might be helpful is some scenario? Also, just to clarify, those workers will still contribute to the initial sstate, so they will still help find cross-host reproducible problems, they just might not find it themselves?
Steve
|
|
|
Re: QA change - reduced number of reproducibility builds tests?
On Fri, Feb 25, 2022 at 8:09 AM Richard Purdie <richard.purdie@...> wrote:
Hi All,
As the project develops, some tests are valuable and some become less valuable
over time.
When we first started reproducible builds work, testing reproducibility heavily
across multiple distros highlighted some unusual bugs and let us improve things.
We therefore currently run a-full with the targets:
reproducibile-centos
reproducibile-debian
reproducibile-fedora
reproducibile-ubuntu
I've noticed we pretty much always see the same set of failures with these
targets now, i.e. if one fails, they all fail the same way.
Those targets are heavy builds which don't reuse sstate for one of the build
streams and hence load the autobuilder heavily.
I'm thinking they've served their purpose and that a-full should go back to just
the randomly selected reproduiclbe target.
Does anyone feel we shouldn't do that?
I support this. It has been quite some time since dunfell encountered a distro specific reproducibility issue. Steve
|
|
|
QA change - reduced number of reproducibility builds tests?
Hi All,
As the project develops, some tests are valuable and some become less valuable
over time.
When we first started reproducible builds work, testing reproducibility heavily
across multiple distros highlighted some unusual bugs and let us improve things.
We therefore currently run a-full with the targets:
reproducibile-centos
reproducibile-debian
reproducibile-fedora
reproducibile-ubuntu
I've noticed we pretty much always see the same set of failures with these
targets now, i.e. if one fails, they all fail the same way.
Those targets are heavy builds which don't reuse sstate for one of the build
streams and hence load the autobuilder heavily.
I'm thinking they've served their purpose and that a-full should go back to just
the randomly selected reproduiclbe target.
Does anyone feel we shouldn't do that?
Cheers,
Richard
|
|
|
looking to boot core-image-minimal on meta-riscv board
a friend of mine is diving into trying to boot linux on a meta-riscv linux starter kit -- he's not using YP, and this is what he's targeting: https://www.aliexpress.com/item/1005003751298305.html since i've wanted to jump into meta-riscv for a while, i figured i'd play along and ordered something more substantial: https://www.aliexpress.com/item/1005002796061251.htmlin any event, here's the story so far. as a first pass, i just fired up YP and built for qemuriscv64 to establish a baseline, and that seems to work just fine, booting with "runqemu nographic." and that at least gives me a bunch of config info i can look at later. as for my actual target board, i know that the meta-riscv layer defines support for two boards, neither of which is the one i will be getting, but while i'm waiting for it, i can at least start documenting all of the relevant settings and config values i'll want to try. i know precious little about meta-riscv, so is there a sane way to prepare for the eventual arrival of my board? my plan is to get familiar with how the meta-riscv layer builds for the two supported boards, so i'll have a handle on what i'll need to configure. any further advice would be most appreciated.
|
|
|
[meta-security][PATCH 2/2] packagegroup-security-tpm: Fix QA Error
Armin Kuster
ERROR: packagegroup-security-tpm-1.0-r0 do_package_write_rpm: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (libtpm-dbg to libtpms-dbg) ERROR: packagegroup-security-tpm-1.0-r0 do_package_write_rpm: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (libtpm to libtpms0) ERROR: packagegroup-security-tpm-1.0-r0 do_package_write_rpm: An allarch packagegroup shouldn't depend on packages which are dynamically renamed (libtpm-dev to libtpms-dev) Signed-off-by: Armin Kuster <akuster808@...> --- meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm.bb b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm.bb index bfe6e3a..7ba5004 100644 --- a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm.bb +++ b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm.bb @@ -15,7 +15,6 @@ RDEPENDS:packagegroup-security-tpm = " \ tpm-quote-tools \ swtpm \ openssl-tpm-engine \ - libtpm \ ${X86_TPM_MODULES} \ " -- 2.25.1
|
|
|
[meta-security][PATCH 1/2] README.md: fix typo
Armin Kuster
Fix typo in parsec-tools to parsec-tool Signed-off-by: Armin Kuster <akuster808@...> --- meta-parsec/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-parsec/README.md b/meta-parsec/README.md index bb4c2b9..85e0d10 100644 --- a/meta-parsec/README.md +++ b/meta-parsec/README.md @@ -80,7 +80,7 @@ Manual testing with runqemu This layer also contains a recipe for pasec-tool which can be used for manual testing of the Parsec service: - IMAGE_INSTALL:append = " parsec-tools" + IMAGE_INSTALL:append = " parsec-tool" There are a series of Parsec Demo videos showing how to use parsec-tool to test the Parsec service base functionality: -- 2.25.1
|
|
|
Re: [meta-security][PATCH] Upgrade parsec-tool to 0.5.1
Armin Kuster
merged.
thanks
Armin
toggle quoted messageShow quoted text
On 2/23/22 06:02, Anton Antonov wrote: Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
meta-parsec/conf/layer.conf | 2 +-
...sec-tool_0.4.0.bb => parsec-tool_0.5.1.bb} | 0
...c-tool_0.4.0.inc => parsec-tool_0.5.1.inc} | 166 ++++++++----------
3 files changed, 74 insertions(+), 94 deletions(-)
rename meta-parsec/recipes-parsec/parsec-tool/{parsec-tool_0.4.0.bb => parsec-tool_0.5.1.bb} (100%)
rename meta-parsec/recipes-parsec/parsec-tool/{parsec-tool_0.4.0.inc => parsec-tool_0.5.1.inc} (55%)
diff --git a/meta-parsec/conf/layer.conf b/meta-parsec/conf/layer.conf
index 19900bb..544cc4e 100644
--- a/meta-parsec/conf/layer.conf
+++ b/meta-parsec/conf/layer.conf
@@ -10,5 +10,5 @@ BBFILE_PRIORITY_parsec-layer = "5"
LAYERSERIES_COMPAT_parsec-layer = "kirkstone"
-LAYERDEPENDS_parsec-layer = "core clang-layer tpm-layer"
+LAYERDEPENDS_parsec-layer = "core clang-layer"
BBLAYERS_LAYERINDEX_NAME_parsec-layer = "meta-parsec"
diff --git a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.4.0.bb b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.5.1.bb
similarity index 100%
rename from meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.4.0.bb
rename to meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.5.1.bb
diff --git a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.4.0.inc b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.5.1.inc
similarity index 55%
rename from meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.4.0.inc
rename to meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.5.1.inc
index e706112..567cc37 100644
--- a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.4.0.inc
+++ b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.5.1.inc
@@ -1,93 +1,83 @@
# This file is created from parsec-tool repository Cargo.lock using cargo-bitbake tool
SRC_URI += " \
- crate://crates.io/addr2line/0.15.2 \
- crate://crates.io/adler/1.0.2 \
crate://crates.io/aho-corasick/0.7.15 \
crate://crates.io/ansi_term/0.11.0 \
crate://crates.io/ansi_term/0.12.1 \
- crate://crates.io/anyhow/1.0.42 \
+ crate://crates.io/anyhow/1.0.44 \
crate://crates.io/arrayvec/0.5.2 \
crate://crates.io/atty/0.2.14 \
crate://crates.io/autocfg/1.0.1 \
- crate://crates.io/backtrace/0.3.59 \
crate://crates.io/base64/0.12.3 \
crate://crates.io/base64/0.13.0 \
crate://crates.io/bincode/1.3.3 \
crate://crates.io/bindgen/0.57.0 \
- crate://crates.io/bitflags/1.2.1 \
+ crate://crates.io/bitflags/1.3.2 \
crate://crates.io/bitvec/0.19.5 \
crate://crates.io/block-buffer/0.9.0 \
- crate://crates.io/boringssl-src/0.3.0+688fc5c \
- crate://crates.io/bumpalo/3.7.0 \
- crate://crates.io/bytes/0.5.6 \
- crate://crates.io/cc/1.0.69 \
+ crate://crates.io/bumpalo/3.7.1 \
+ crate://crates.io/bytes/1.1.0 \
+ crate://crates.io/cc/1.0.70 \
crate://crates.io/cexpr/0.4.0 \
crate://crates.io/cfg-if/1.0.0 \
crate://crates.io/chrono/0.4.19 \
- crate://crates.io/clang-sys/1.2.0 \
+ crate://crates.io/clang-sys/1.2.2 \
crate://crates.io/clap/2.33.3 \
- crate://crates.io/clap/3.0.0-beta.2 \
- crate://crates.io/clap_derive/3.0.0-beta.2 \
+ crate://crates.io/clap/3.0.0-beta.4 \
+ crate://crates.io/clap_derive/3.0.0-beta.4 \
crate://crates.io/cmake/0.1.45 \
- crate://crates.io/const-oid/0.6.0 \
- crate://crates.io/cpufeatures/0.1.5 \
+ crate://crates.io/const-oid/0.6.2 \
+ crate://crates.io/cpufeatures/0.2.1 \
crate://crates.io/data-encoding/2.3.2 \
crate://crates.io/der-oid-macro/0.4.0 \
crate://crates.io/der-parser/5.1.2 \
- crate://crates.io/der/0.4.0 \
+ crate://crates.io/der/0.4.5 \
crate://crates.io/derivative/2.2.0 \
crate://crates.io/digest/0.9.0 \
crate://crates.io/either/1.6.1 \
crate://crates.io/env_logger/0.8.4 \
- crate://crates.io/failure/0.1.8 \
- crate://crates.io/failure_derive/0.1.8 \
crate://crates.io/form_urlencoded/1.0.1 \
crate://crates.io/funty/1.1.0 \
- crate://crates.io/futures-channel/0.3.16 \
- crate://crates.io/futures-core/0.3.16 \
- crate://crates.io/futures-executor/0.3.16 \
- crate://crates.io/futures-io/0.3.16 \
- crate://crates.io/futures-macro/0.3.16 \
- crate://crates.io/futures-sink/0.3.16 \
- crate://crates.io/futures-task/0.3.16 \
- crate://crates.io/futures-util/0.3.16 \
- crate://crates.io/futures/0.3.16 \
+ crate://crates.io/futures-channel/0.3.17 \
+ crate://crates.io/futures-core/0.3.17 \
+ crate://crates.io/futures-executor/0.3.17 \
+ crate://crates.io/futures-io/0.3.17 \
+ crate://crates.io/futures-macro/0.3.17 \
+ crate://crates.io/futures-sink/0.3.17 \
+ crate://crates.io/futures-task/0.3.17 \
+ crate://crates.io/futures-util/0.3.17 \
+ crate://crates.io/futures/0.3.17 \
crate://crates.io/generic-array/0.14.4 \
- crate://crates.io/getrandom/0.2.3 \
- crate://crates.io/gimli/0.24.0 \
crate://crates.io/glob/0.3.0 \
- crate://crates.io/grpcio-compiler/0.7.0 \
- crate://crates.io/grpcio-sys/0.9.0+1.38.0 \
- crate://crates.io/grpcio/0.9.0 \
+ crate://crates.io/grpcio-sys/0.9.1+1.38.0 \
+ crate://crates.io/grpcio/0.9.1 \
crate://crates.io/hashbrown/0.11.2 \
crate://crates.io/heck/0.3.3 \
crate://crates.io/hermit-abi/0.1.19 \
crate://crates.io/humantime/2.1.0 \
crate://crates.io/idna/0.2.3 \
crate://crates.io/indexmap/1.7.0 \
- crate://crates.io/instant/0.1.10 \
- crate://crates.io/itertools/0.8.2 \
- crate://crates.io/itoa/0.4.7 \
- crate://crates.io/js-sys/0.3.52 \
+ crate://crates.io/instant/0.1.11 \
+ crate://crates.io/itertools/0.10.1 \
+ crate://crates.io/itoa/0.4.8 \
+ crate://crates.io/js-sys/0.3.55 \
crate://crates.io/jsonwebkey/0.3.2 \
crate://crates.io/jsonwebtoken/7.2.0 \
crate://crates.io/lazy_static/1.4.0 \
crate://crates.io/lazycell/1.3.0 \
crate://crates.io/lexical-core/0.7.6 \
- crate://crates.io/libc/0.2.102 \
+ crate://crates.io/libc/0.2.103 \
crate://crates.io/libloading/0.7.0 \
crate://crates.io/libz-sys/1.1.3 \
- crate://crates.io/lock_api/0.4.4 \
+ crate://crates.io/lock_api/0.4.5 \
crate://crates.io/log/0.4.14 \
- crate://crates.io/matches/0.1.8 \
+ crate://crates.io/matches/0.1.9 \
crate://crates.io/memchr/2.3.4 \
- crate://crates.io/miniz_oxide/0.4.4 \
crate://crates.io/nom/5.1.2 \
crate://crates.io/nom/6.2.1 \
crate://crates.io/num-bigint/0.2.6 \
- crate://crates.io/num-bigint/0.3.2 \
- crate://crates.io/num-bigint/0.4.0 \
+ crate://crates.io/num-bigint/0.3.3 \
+ crate://crates.io/num-bigint/0.4.2 \
crate://crates.io/num-complex/0.3.1 \
crate://crates.io/num-derive/0.3.3 \
crate://crates.io/num-integer/0.1.44 \
@@ -95,94 +85,84 @@ SRC_URI += " \
crate://crates.io/num-rational/0.3.2 \
crate://crates.io/num-traits/0.2.14 \
crate://crates.io/num/0.3.1 \
- crate://crates.io/object/0.24.0 \
crate://crates.io/oid-registry/0.1.5 \
crate://crates.io/oid/0.2.1 \
crate://crates.io/once_cell/1.8.0 \
crate://crates.io/opaque-debug/0.3.0 \
- crate://crates.io/os_str_bytes/2.4.0 \
- crate://crates.io/parking_lot/0.11.1 \
- crate://crates.io/parking_lot_core/0.8.3 \
- crate://crates.io/parsec-client/0.13.0 \
- crate://crates.io/parsec-interface/0.25.0 \
+ crate://crates.io/os_str_bytes/3.1.0 \
+ crate://crates.io/parking_lot/0.11.2 \
+ crate://crates.io/parking_lot_core/0.8.5 \
+ crate://crates.io/parsec-client/0.14.0 \
+ crate://crates.io/parsec-interface/0.26.0 \
crate://crates.io/peeking_take_while/0.1.2 \
crate://crates.io/pem/0.8.3 \
+ crate://crates.io/pem/1.0.1 \
crate://crates.io/percent-encoding/2.1.0 \
crate://crates.io/picky-asn1-der/0.2.5 \
crate://crates.io/picky-asn1-x509/0.6.1 \
crate://crates.io/picky-asn1/0.3.3 \
crate://crates.io/pin-project-lite/0.2.7 \
crate://crates.io/pin-utils/0.1.0 \
- crate://crates.io/pkcs8/0.7.5 \
- crate://crates.io/pkg-config/0.3.19 \
- crate://crates.io/ppv-lite86/0.2.10 \
+ crate://crates.io/pkcs8/0.7.6 \
+ crate://crates.io/pkg-config/0.3.20 \
crate://crates.io/proc-macro-error-attr/1.0.4 \
crate://crates.io/proc-macro-error/1.0.4 \
crate://crates.io/proc-macro-hack/0.5.19 \
crate://crates.io/proc-macro-nested/0.1.7 \
- crate://crates.io/proc-macro2/1.0.28 \
- crate://crates.io/prost-derive/0.6.1 \
- crate://crates.io/prost/0.6.1 \
- crate://crates.io/protobuf-codegen/2.24.1 \
- crate://crates.io/protobuf/2.24.1 \
- crate://crates.io/protoc-grpcio/3.0.0 \
- crate://crates.io/protoc/2.24.1 \
- crate://crates.io/psa-crypto-sys/0.9.0 \
- crate://crates.io/psa-crypto/0.9.0 \
+ crate://crates.io/proc-macro2/1.0.29 \
+ crate://crates.io/prost-derive/0.8.0 \
+ crate://crates.io/prost/0.8.0 \
+ crate://crates.io/protobuf/2.25.1 \
+ crate://crates.io/psa-crypto-sys/0.9.2 \
+ crate://crates.io/psa-crypto/0.9.1 \
crate://crates.io/quote/1.0.9 \
crate://crates.io/radium/0.5.3 \
- crate://crates.io/rand/0.8.4 \
- crate://crates.io/rand_chacha/0.3.1 \
- crate://crates.io/rand_core/0.6.3 \
- crate://crates.io/rand_hc/0.3.1 \
- crate://crates.io/redox_syscall/0.2.9 \
+ crate://crates.io/rcgen/0.8.14 \
+ crate://crates.io/redox_syscall/0.2.10 \
crate://crates.io/regex-syntax/0.6.25 \
crate://crates.io/regex/1.4.6 \
- crate://crates.io/remove_dir_all/0.5.3 \
crate://crates.io/ring/0.16.20 \
- crate://crates.io/rustc-demangle/0.1.20 \
crate://crates.io/rustc-hash/1.1.0 \
- crate://crates.io/rusticata-macros/3.1.0 \
+ crate://crates.io/rusticata-macros/3.2.0 \
crate://crates.io/rustversion/1.0.5 \
crate://crates.io/ryu/1.0.5 \
crate://crates.io/same-file/1.0.6 \
crate://crates.io/scopeguard/1.1.0 \
crate://crates.io/secrecy/0.7.0 \
- crate://crates.io/serde/1.0.127 \
+ crate://crates.io/serde/1.0.130 \
crate://crates.io/serde_bytes/0.11.5 \
- crate://crates.io/serde_derive/1.0.127 \
- crate://crates.io/serde_json/1.0.66 \
- crate://crates.io/sha2/0.9.5 \
+ crate://crates.io/serde_derive/1.0.130 \
+ crate://crates.io/serde_json/1.0.68 \
+ crate://crates.io/sha2/0.9.9 \
crate://crates.io/shlex/0.1.1 \
crate://crates.io/simple_asn1/0.4.1 \
crate://crates.io/simple_asn1/0.5.4 \
- crate://crates.io/slab/0.4.3 \
+ crate://crates.io/slab/0.4.4 \
crate://crates.io/smallvec/1.6.1 \
- crate://crates.io/spiffe/0.1.1 \
+ crate://crates.io/spiffe/0.2.0 \
crate://crates.io/spin/0.5.2 \
- crate://crates.io/spki/0.4.0 \
+ crate://crates.io/spki/0.4.1 \
crate://crates.io/static_assertions/1.1.0 \
crate://crates.io/strsim/0.10.0 \
crate://crates.io/strsim/0.8.0 \
- crate://crates.io/structopt-derive/0.4.15 \
- crate://crates.io/structopt/0.3.22 \
- crate://crates.io/syn/1.0.74 \
+ crate://crates.io/structopt-derive/0.4.16 \
+ crate://crates.io/structopt/0.3.23 \
+ crate://crates.io/syn/1.0.77 \
crate://crates.io/synstructure/0.12.5 \
crate://crates.io/tap/1.0.1 \
- crate://crates.io/tempfile/3.2.0 \
crate://crates.io/termcolor/1.1.2 \
crate://crates.io/textwrap/0.11.0 \
- crate://crates.io/textwrap/0.12.1 \
- crate://crates.io/thiserror-impl/1.0.26 \
- crate://crates.io/thiserror/1.0.26 \
+ crate://crates.io/textwrap/0.14.2 \
+ crate://crates.io/thiserror-impl/1.0.29 \
+ crate://crates.io/thiserror/1.0.29 \
crate://crates.io/time/0.1.44 \
- crate://crates.io/tinyvec/1.3.1 \
+ crate://crates.io/tinyvec/1.5.0 \
crate://crates.io/tinyvec_macros/0.1.0 \
- crate://crates.io/typenum/1.13.0 \
- crate://crates.io/unicode-bidi/0.3.5 \
+ crate://crates.io/typenum/1.14.0 \
+ crate://crates.io/unicode-bidi/0.3.6 \
crate://crates.io/unicode-normalization/0.1.19 \
crate://crates.io/unicode-segmentation/1.8.0 \
- crate://crates.io/unicode-width/0.1.8 \
+ crate://crates.io/unicode-width/0.1.9 \
crate://crates.io/unicode-xid/0.2.2 \
crate://crates.io/untrusted/0.7.1 \
crate://crates.io/url/2.2.2 \
@@ -193,13 +173,12 @@ SRC_URI += " \
crate://crates.io/version_check/0.9.3 \
crate://crates.io/walkdir/2.3.2 \
crate://crates.io/wasi/0.10.0+wasi-snapshot-preview1 \
- crate://crates.io/wasm-bindgen-backend/0.2.75 \
- crate://crates.io/wasm-bindgen-macro-support/0.2.75 \
- crate://crates.io/wasm-bindgen-macro/0.2.75 \
- crate://crates.io/wasm-bindgen-shared/0.2.75 \
- crate://crates.io/wasm-bindgen/0.2.75 \
- crate://crates.io/web-sys/0.3.52 \
- crate://crates.io/which/4.2.2 \
+ crate://crates.io/wasm-bindgen-backend/0.2.78 \
+ crate://crates.io/wasm-bindgen-macro-support/0.2.78 \
+ crate://crates.io/wasm-bindgen-macro/0.2.78 \
+ crate://crates.io/wasm-bindgen-shared/0.2.78 \
+ crate://crates.io/wasm-bindgen/0.2.78 \
+ crate://crates.io/web-sys/0.3.55 \
crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
crate://crates.io/winapi-util/0.1.5 \
crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
@@ -207,8 +186,9 @@ SRC_URI += " \
crate://crates.io/wyz/0.2.0 \
crate://crates.io/x509-parser/0.9.2 \
crate://crates.io/yasna/0.3.2 \
+ crate://crates.io/yasna/0.4.0 \
crate://crates.io/zeroize/1.3.0 \
- crate://crates.io/zeroize_derive/1.1.0 \
+ crate://crates.io/zeroize_derive/1.2.0 \
"
LIC_FILES_CHKSUM = " \
|
|
|
Creating Package Feed for An Application Using SDK build
#yocto
#sdk
Hi,
I came to know about the package feed feature, through which we can update the application in the target image by using apt-get commands. I just read about it on following link.
https://subscription.packtpub.com/book/virtualization-and-cloud/9781784395186/1/ch01lvl1sec21/setting-up-a-package-feed.
This link at high level ask user to set up a server for build/tmp/deploy/deb repo and updating /etc/apt/sources.list file at target with repo path.
I followed the steps and I am able to update the application on target using apt-get commands
For my work i use Yocto SDK for building the application software as a result i get application executable that i deploy in target using SCP command.
So my question is, Can I also setup a package feed for my target if I use Yocto SDK ? If yes, Can you please guide me how can I set it up and update the application easily on the target using apt-get commands.
|
|
|
Minutes: Yocto Project Weekly Triage Meeting 2/24/2022
Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage
Attendees: Armin, Bruce, Daiane, Joshua, Pavel, Randy,
Richard, Ross, Saul, Stephen, Steve, Tim, Trevor
ARs:
- Randy to write an email list to the Yocto mailing lists to
encourage users to check for existing bugs and add their input
to those before reporting new issues
Notes:
- ~43% of AB workers have been switched to SSDs. Failure rate
appears lower, but still TBD
Medium+ 3.5 Unassigned Enhancements/Bugs: 78 (Last week
78)
Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (Last
week 39)
AB Bugs: 75
(Last week 73)
|
|
|
So now after doing the last pull on meta -raspberrypi. The one to change the kernel version. I have a hdmi output but my boot process block at please wait : booting . Do you have an idea why it is doing that ?
Best regards,
Safouane.Maaloul
So now after doing the last pull on meta -raspberrypi. The one to change the kernel version. I have a hdmi output but my boot process block at please wait : booting . Do you have an idea why it is doing that ?
Best regards,
Safouane.Maaloul
Le mar. 22 févr. 2022 à 19:30, Khem Raj < raj.khem@...> a écrit : On Tue, Feb 22, 2022 at 6:39 AM safouane maaloul
<maaloulsafouane@...> wrote:
>
> I do am building image on a raspberry pi zero w. After flashing the image on the raspberry, i don get anything on the screen. I am doing this the honister branch. I had the gatesgarth branch and it was working perfectly. I tried many thing but i can't get to work. i have literally the same code on a raspberry pi zero w 2 and it works perfectly. I am only changing the name of the machine (raspberrypi0-wifi ) to get to work. Do you have an idea why ? I have the sensation that it is booting because the green led is flashing but i don't have anything on the screen.
is it possible to hook up serial console and see if you see additional
messages ?
also try with master and see if you have same problem as honister or not
>
>
--
|
|
|
Re: Regarding mail notification diseable
|
|
|
[meta-selinux][PATCH] Update compat to kirkstone
Jeremy Puhlman
Signed-off-by: Jeremy A. Puhlman <jpuhlman@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/layer.conf b/conf/layer.conf
index d7c80b8..d6f83c9 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -17,7 +17,7 @@ BBFILE_PRIORITY_selinux = "5"
# cause compatibility issues with other layers
LAYERVERSION_selinux = "1"
-LAYERSERIES_COMPAT_selinux = "honister"
+LAYERSERIES_COMPAT_selinux = "kirkstone"
LAYERDEPENDS_selinux = " \
core \
--
2.33.0
|
|
|
Apologies but I have to say no. Updating these three variables from a
bbappend is not a good idea and I strongly recommend that you do not
do it. If you need a different version of something, write a proper,
separate recipe for it.
Alex
toggle quoted messageShow quoted text
On Thu, 24 Feb 2022 at 08:27, <ksmanjunath681@...> wrote:
Hi Alexander,
I looked into the various options provided by devtool upgrade/devtool finish.
Unfortunately, it doesn't have the required options to update .bbappend files.
Below is a brief on my problem.
devtool upgrade doesn't consider updating .bbappend files of the recipe if they have overridden SRC related information.
For example, I have a .bbappend file in my custom layer that has overridden SRC_URI, SRCBRANCH & SRCREV information for a recipe in poky.
When I tried to update the recipe with latest SRCREV using below command:
devtool upgrade -S <latest_commit_revision> <recipename>
The devtool upgrade by default updates the original recipe (.bb) in poky but not the .bbappend file in my custom layer.
I briefly looked into the devtool upgrade sources to confirm this behavior as well.
Is this an expected behavior?
There could be cases where the .bbappend files might override the SRC related information and we expect the devtool to upgrade the respective .bbappend file?
Thanks.
|
|
|
