Date   

[meta-security][PATCH] apparmor: update to 3.0.4

Armin Kuster
 

drop to patches no longer needed
use setuptools

Signed-off-by: Armin Kuster <akuster808@...>
---
.../{apparmor_3.0.1.bb => apparmor_3.0.4.bb} | 6 +-
...Update-make-check-to-select-tools-ba.patch | 91 -------------------
recipes-mac/AppArmor/files/py3_10_fixup.patch | 35 -------
3 files changed, 2 insertions(+), 130 deletions(-)
rename recipes-mac/AppArmor/{apparmor_3.0.1.bb => apparmor_3.0.4.bb} (97%)
delete mode 100644 recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
delete mode 100644 recipes-mac/AppArmor/files/py3_10_fixup.patch

diff --git a/recipes-mac/AppArmor/apparmor_3.0.1.bb b/recipes-mac/AppArmor/apparmor_3.0.4.bb
similarity index 97%
rename from recipes-mac/AppArmor/apparmor_3.0.1.bb
rename to recipes-mac/AppArmor/apparmor_3.0.4.bb
index 818be15..8ad3c76 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.1.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.4.bb
@@ -18,20 +18,18 @@ SRC_URI = " \
file://run-ptest \
file://crosscompile_perl_bindings.patch \
file://0001-Makefile.am-suppress-perllocal.pod.patch \
- file://0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch \
file://0001-Makefile-fix-hardcoded-installation-directories.patch \
file://0001-rc.apparmor.debian-add-missing-functions.patch \
- file://py3_10_fixup.patch \
"

-SRCREV = "b23de501807b8b5793e9654da8688b5fd3281154"
+SRCREV = "9799fbde997820bb12a49e292356f7a6ce12e972"
S = "${WORKDIR}/git"

PARALLEL_MAKE = ""

COMPATIBLE_MACHINE:mips64 = "(!.*mips64).*"

-inherit pkgconfig autotools-brokensep update-rc.d python3native python3targetconfig perlnative cpan systemd features_check bash-completion
+inherit pkgconfig autotools-brokensep update-rc.d python3native python3targetconfig perlnative cpan systemd features_check bash-completion setuptools3

REQUIRED_DISTRO_FEATURES = "apparmor"

diff --git a/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch b/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
deleted file mode 100644
index e7abd60..0000000
--- a/recipes-mac/AppArmor/files/0001-Revert-profiles-Update-make-check-to-select-tools-ba.patch
+++ /dev/null
@@ -1,91 +0,0 @@
-From 5ed21abbef4d4c2983e70bd2868fb817150e883e Mon Sep 17 00:00:00 2001
-From: Armin Kuster <akuster808@...>
-Date: Sat, 3 Oct 2020 11:26:46 -0700
-Subject: [PATCH] Revert "profiles: Update 'make check' to select tools based
- on USE_SYSTEM"
-
-This reverts commit 6016f931ebf7b61e1358f19453ef262d9d184a4e.
-
-Upstream-Status: Inappropriate [OE specific]
-These changes cause during packaging with perms changing.
-
-Signed-off-by: Armin Kuster <akuster808@...>
-
----
- profiles/Makefile | 50 ++++++++++-------------------------------------
- 1 file changed, 10 insertions(+), 40 deletions(-)
-
-diff --git a/profiles/Makefile b/profiles/Makefile
-index ba47fc16..5384cb05 100644
---- a/profiles/Makefile
-+++ b/profiles/Makefile
-@@ -35,49 +35,9 @@ EXTRAS_SOURCE=./apparmor/profiles/extras/
- SUBDIRS=$(shell find ${PROFILES_SOURCE} -type d -print)
- TOPLEVEL_PROFILES=$(filter-out ${SUBDIRS}, $(wildcard ${PROFILES_SOURCE}/*))
-
--ifdef USE_SYSTEM
-- PYTHONPATH=
-- PARSER?=apparmor_parser
-- LOGPROF?=aa-logprof
--else
-- # PYTHON_DIST_BUILD_PATH based on libapparmor/swig/python/test/Makefile.am
-- PYTHON_DIST_BUILD_PATH = ../libraries/libapparmor/swig/python/build/$$($(PYTHON) -c "import distutils.util; import platform; print(\"lib.%s-%s\" %(distutils.util.get_platform(), platform.python_version()[:3]))")
-- LIBAPPARMOR_PATH=../libraries/libapparmor/src/.libs/
-- LD_LIBRARY_PATH=$(LIBAPPARMOR_PATH):$(PYTHON_DIST_BUILD_PATH)
-- PYTHONPATH=../utils/:$(PYTHON_DIST_BUILD_PATH)
-- PARSER?=../parser/apparmor_parser
-- # use ../utils logprof
-- LOGPROF?=LD_LIBRARY_PATH=$(LD_LIBRARY_PATH) PYTHONPATH=$(PYTHONPATH) $(PYTHON) ../utils/aa-logprof
--endif
--
- # $(PWD) is wrong when using "make -C profiles" - explicitely set it here to get the right value
- PWD=$(shell pwd)
-
--.PHONY: test-dependencies
--test-dependencies: __parser __libapparmor
--
--
--.PHONY: __parser __libapparmor
--__parser:
--ifndef USE_SYSTEM
-- @if [ ! -f $(PARSER) ]; then \
-- echo "error: $(PARSER) is missing. Pick one of these possible solutions:" 1>&2; \
-- echo " 1) Test using the in-tree parser by building it first and then trying again. See the top-level README for help." 1>&2; \
-- echo " 2) Test using the system parser by adding USE_SYSTEM=1 to your make command." 1>&2; \
-- exit 1; \
-- fi
--endif
--
--__libapparmor:
--ifndef USE_SYSTEM
-- @if [ ! -f $(LIBAPPARMOR_PATH)libapparmor.so ]; then \
-- echo "error: $(LIBAPPARMOR_PATH)libapparmor.so is missing. Pick one of these possible solutions:" 1>&2; \
-- echo " 1) Build against the in-tree libapparmor by building it first and then trying again. See the top-level README for help." 1>&2; \
-- echo " 2) Build against the system libapparmor by adding USE_SYSTEM=1 to your make command." 1>&2; \
-- exit 1; \
-- fi
--endif
--
- local:
- for profile in ${TOPLEVEL_PROFILES}; do \
- fn=$$(basename $$profile); \
-@@ -109,6 +69,16 @@ else
- Q=
- endif
-
-+ifndef PARSER
-+# use system parser
-+PARSER=../parser/apparmor_parser
-+endif
-+
-+ifndef LOGPROF
-+# use ../utils logprof
-+LOGPROF=PYTHONPATH=../utils $(PYTHON) ../utils/aa-logprof
-+endif
-+
- .PHONY: docs
- # docs: should we have some here?
- docs:
---
-2.17.1
-
diff --git a/recipes-mac/AppArmor/files/py3_10_fixup.patch b/recipes-mac/AppArmor/files/py3_10_fixup.patch
deleted file mode 100644
index 05f8460..0000000
--- a/recipes-mac/AppArmor/files/py3_10_fixup.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-m4/ax_python_devel.m4: do not check for distutils
-
-With py 3.10 this prints a deprecation warning which is
-taken as an error. Upstream should rework the code to not
-use distuils.
-
-Upstream-Status: Inappropriate [needs a proper fix upstream]
-Signed-off-by: Armin Kuster <akuster808@...>
-
-Index: git/libraries/libapparmor/m4/ac_python_devel.m4
-===================================================================
---- git.orig/libraries/libapparmor/m4/ac_python_devel.m4
-+++ git/libraries/libapparmor/m4/ac_python_devel.m4
-@@ -66,21 +66,6 @@ variable to configure. See ``configure -
- fi
-
- #
-- # Check if you have distutils, else fail
-- #
-- AC_MSG_CHECKING([for the distutils Python package])
-- ac_distutils_result=`$PYTHON -c "import distutils" 2>&1`
-- if test -z "$ac_distutils_result"; then
-- AC_MSG_RESULT([yes])
-- else
-- AC_MSG_RESULT([no])
-- AC_MSG_ERROR([cannot import Python module "distutils".
--Please check your Python installation. The error was:
--$ac_distutils_result])
-- PYTHON_VERSION=""
-- fi
--
-- #
- # Check for Python include path
- #
- AC_MSG_CHECKING([for Python include path])
--
2.25.1


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

Robert P. J. Day
 

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?

Richard Purdie
 

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?

Alexander Kanavin
 

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?

Richard Purdie
 

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?

Joshua Watt
 

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?

Steve Sakoman
 

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?

Richard Purdie
 

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

Robert P. J. Day
 

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.


[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

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

Hariom@...
 

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

Trevor Gamblin
 

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)


Re: #yocto #raspberrypi0-wifi #honister #yocto #raspberrypi0-wifi #honister

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 jeu. 24 févr. 2022 à 15:17, safouane maaloul <maaloulsafouane@...> a écrit :
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

>
>


--
SAFOUANE MAALOUL


--
SAFOUANE MAALOUL


Re: Regarding mail notification diseable

Ross Burton <ross@...>
 

On Thu, 24 Feb 2022 at 06:06, NIKHIL PATIL <nikhilvp29@...> wrote:
hi ,
I dont want any mail notification from yocto forum , please disable it . i am not able to disable.
thanks .

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56272): https://lists.yoctoproject.org/g/yocto/message/56272
Mute This Topic: https://lists.yoctoproject.org/mt/89360278/1676615
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [ross@...]
You can unsub yourself by following the Unsubscribe link at the bottom
of this email.

Ross


[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

1161 - 1180 of 57408