Re: [linux-yocto] Non-deterministic SHA commit hash when applying patches to kernel git repository

2022-02-25 Thread Jimmy Assarsson 

On 2022-02-24 16:41, Bruce Ashfield wrote:

On Tue, Feb 22, 2022 at 3:42 AM Jimmy Assarsson
 wrote:

On 2022-02-21 05:13, Bruce Ashfield wrote:

on 19/02/2022 Jimmy Assarsson wrote:

On 2022-02-19 20:42, Bruce Ashfield wrote:

On Sat, Feb 19, 2022 at 5:28 AM Jimmy Assarsson
 wrote:


When patching a kernel git repository, in a recipe inheriting 
kernel-yocto.bbclass,
the resulting commit hash will become different every time the source is 
unpacked and patched.

This is a problem that causes non-reproducible builds, when the commit hash is 
built
into the kernel (CONFIG_LOCALVERSION_AUTO=y).


Currently it is not a problem in linux-yocto, since an empty .scmversion is
created in kernel_do_configure [1]. This is preventing the kernel build from
generating its own .scmversion.

If removing this commit, setting CONFIG_LOCALVERSION_AUTO=y and applying any
patch in the linux-yocto recipe, this will result in a non-reproducible build.


...


diff --git a/tools/kgit-s2q b/tools/kgit-s2q
index 706783e..b46a138 100755
--- a/tools/kgit-s2q
+++ b/tools/kgit-s2q
@@ -558,7 +558,7 @@ do
echo "($APPLIED/$COUNT) `basename $i`"
fi

-   git am --keep-non-patch $DIR/$i > /dev/null 2>&1
+   git am --keep-non-patch --committer-date-is-author-date $DIR/$i > /dev/null 
2>&1
if [ $? != 0 ];then
git am --abort > /dev/null 2>&1
echo "[INFO]: check of $DIR/$i with \"git am\" did not pass, 
trying reduced context."



I'm not sure if this is a proper solution to fix the problem or what side 
effects it may introduce?


There's nothing fundamentally wrong with that solution, but there are
modes for the kernel builds where we absolutely do not want the
reproducible build (and older dates) to be in effect (see my comments
on the OE core mailing list when the ability to disable reproducible
builds was almost removed).


Thanks, now I've looked it up.


We could add an option to the patch queue management that was enabled
when reproducible builds are in play, so git am could operate like
that.

Alternatively, you could bbappend the other kernel's do_configure and
do the same .scmversion trick to make sure that everything is
consistent.


I don't follow, can you be more specific?
We encountered this problem when building linux-imx (from meta-freescale).
Preferably the .scmversion workaround in [1] should be dropped, so that
there is no need to reinvent/mimic the output of
linux/scripts/setlocalversion, in a bitbake recipe.


I see no compelling reason to drop the .scmversion in the main kernel.bbclass
(at least not in the short term). It has been there for a significant amount
of time, and removing it now would very likely cause some ripple effects
througout the ecosystem (it is there for a few different issues).  While not
elegant, it is an available and workable solution to the problem it is
solving.


I agree. And obviously this is not a big issue for others.
There have been at least two failed attempts on removing this [4][5][6].


I was suggesting that anyone can bbappend any kernel recipe to do the similar
.scmversion set (assuming they aren't using the core kernel bbclass
configure()).

But from your next statement, that isn't going to work as the sole solution,
since yes, that will only restore where we keep the git rev out of the
localversion.



To be clear, we want the result of CONFIG_LOCALVERSION_AUTO=y, but
with a reproducible output.


And that's actually part of the reason the .scmversion is set, the
setlocalversion script was appending values in some configurations and
combinations of patching, etc, such that issues were popping up with version
matching.

Part of getting that to work, definitely could be to apply patches with the
author date, but that has to be triggered on reproducible builds being
enabled (which is of course the default) and also preserving the use of the
.scmversion for the baseline / basic kernel configuration routines.

.. so one config to say "don't set scmversion" and another to say "apply
patches with author date" (this one toggling based on reproducible builds).
And then both scenarios can be supported.


Currently I'm only interested in fixing the "apply patches with
author date", to get reproducible builds.

So we will end up with a new config in kernel-yocto.bbclass, since this
is the only location where kgit-s2q is used.
And we will get a new option in kgit-s2q, that will result in
"git am --committer-date-is-author-date" being used.

Any name suggestions for the config and option?
KERNEL_PATCH_WITH_AUTHOR_DATE
KERNEL_PATCH_REPRODUCIBLE_HASH
KERNEL_PATCH_REPRODUCIBLE_COMMIT


It is better to abstract it behind the reproducible feature
description, since there are other kernel reproducibility components
that exist, or may appear in the future.


Sure.


If you want, I can have a go at the patch, which will allow me to run
my local tests and put it in my next consolidated pull request.


That would be

Re: [linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-soc & v5.10/standard/preempt-rt/nxp-sdk-5.10/nxp-soc][PATCH 1/1] Revert "scripts: Makefile: Enable creation of _symbols_ DT node for overl

2022-02-25 Thread Bruce Ashfield 
merged.

Bruce

In message: [linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-soc & 
v5.10/standard/preempt-rt/nxp-sdk-5.10/nxp-soc][PATCH 1/1] Revert "scripts: 
Makefile: Enable creation of _symbols_ DT node for overlays"
on 25/02/2022 Xiaolei Wang wrote:

> From: Jason Liu 
> 
> commit 3c02b480dc20f5f65afc7d51625b5fda40525672 from
> https://source.codeaurora.org/external/imx/linux-imx
> 
> This reverts commit 11db97cab885454945c4e36d86a27864e994bad3.
> 
> The blamed commit changes the common Makefile and force creation of
> __symbols__ node on the generated dtb files for all platforms.
> 
> This is not good and not acceptible under some cases due to this change
> will increase the final DTB size a lot and bring big impact for others
> who does not need creation of _symbols_ DT node for overlays.For
> example, on i.MX OP-TEE, the maxsize of DT is 1MB, this patch will break
> some of the i.MX6/i.MX7 boards to boot with OP-TEE enabled.
> 
> A similar patch was submitted and rejected by the community. The
> following post discusses this:
> 
> https://lore.kernel.org/patchwork/patch/821645/
> 
> LS1028A-QDS, which needs the "-@" build flag for device tree overlays,
> now sets the "DTC_FLAGS_fsl-ls1028a-qds" GNU Make variable in
> arch/arm64/boot/dts/freescale/Makefile, and the support for overlays is
> already built for it, so the reverted patch was not even necessary.
> 
> Signed-off-by: Jason Liu 
> Signed-off-by: Vladimir Oltean 
> Signed-off-by: Xiaolei Wang 
> ---
>  scripts/Makefile.lib | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index b904c6b07860..94133708889d 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -297,9 +297,6 @@ endif
>  
>  DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
>  
> -# Enable creation of _symbols_ node for DT overlays
> -DTC_FLAGS += -@
> -
>  # Generate an assembly file to wrap the output of the device tree compiler
>  quiet_cmd_dt_S_dtb= DTB $@
>  cmd_dt_S_dtb=\
> -- 
> 2.25.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10991): 
https://lists.yoctoproject.org/g/linux-yocto/message/10991
Mute This Topic: https://lists.yoctoproject.org/mt/89387286/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.10/standard/base][PATCH 0/4] Fix ramoops/ftrace

2022-02-25 Thread Bruce Ashfield 
In message: [linux-yocto][linux-yocto v5.10/standard/base][PATCH 0/4] Fix 
ramoops/ftrace
on 25/02/2022 He Zhe wrote:

> We experienced system hang when using ramoops/ftrace.
> 
> To avoid the deadlock causing the hang, rebase the patch in the following
> link onto v5.10 as 4/9. 1/9, 2/9 and 3/9 are minimum basic change
> backported from mainline.
> 
> Link: https://lkml.org/lkml/2021/6/10/868
> 
> The code path of ftrace function tracer and the other users of it stays
> unchanged.

This looks ok to me. I've merged it to v5.10/standard/base, and all
of the BSP branches.

I'll let it soak for a few days, and will send SRCREV bumps early next
week.

Bruce

> 
> This has been tested on arm64 and intel-x86-64 hardwares and qemu.
> 
> He Zhe (4):
>   ftrace: Move the recursion testing into global headers
>   ftrace: Add ftrace_test_recursion_trylock() helper function
>   pstore/ftrace: Add recursion protection to the ftrace callback
>   pstore/ftrace: Add and use ftrace_test_recursion_trylock_safe
> 
>  fs/pstore/ftrace.c  |  11 ++
>  include/linux/ftrace.h  |   1 +
>  include/linux/trace_recursion.h | 242 
>  kernel/trace/trace.h| 156 
>  4 files changed, 254 insertions(+), 156 deletions(-)
>  create mode 100644 include/linux/trace_recursion.h
> 
> -- 
> 2.25.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10990): 
https://lists.yoctoproject.org/g/linux-yocto/message/10990
Mute This Topic: https://lists.yoctoproject.org/mt/89382551/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA change - reduced number of reproducibility builds tests?

2022-02-25 Thread Richard Purdie 
On Fri, 2022-02-25 at 22:00 +0100, Alexander Kanavin wrote:
> On Fri, 25 Feb 2022 at 21:55, 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



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56291): https://lists.yoctoproject.org/g/yocto/message/56291
Mute This Topic: https://lists.yoctoproject.org/mt/89394327/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] looking to boot core-image-minimal on meta-riscv board

2022-02-25 Thread Khem Raj 
On Fri, Feb 25, 2022 at 8:36 AM Robert P. J. Day  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.

>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56290): https://lists.yoctoproject.org/g/yocto/message/56290
Mute This Topic: https://lists.yoctoproject.org/mt/89391983/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA change - reduced number of reproducibility builds tests?

2022-02-25 Thread Khem Raj 
On Fri, Feb 25, 2022 at 10:10 AM 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
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56289): https://lists.yoctoproject.org/g/yocto/message/56289
Mute This Topic: https://lists.yoctoproject.org/mt/89394327/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA change - reduced number of reproducibility builds tests?

2022-02-25 Thread Alexander Kanavin 
On Fri, 25 Feb 2022 at 21:55, 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56288): https://lists.yoctoproject.org/g/yocto/message/56288
Mute This Topic: https://lists.yoctoproject.org/mt/89394327/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA change - reduced number of reproducibility builds tests?

2022-02-25 Thread 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  wrote:
> > 
> > On Fri, Feb 25, 2022 at 8:09 AM 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



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56287): https://lists.yoctoproject.org/g/yocto/message/56287
Mute This Topic: https://lists.yoctoproject.org/mt/89394327/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA change - reduced number of reproducibility builds tests?

2022-02-25 Thread Joshua Watt 
On Fri, Feb 25, 2022 at 12:50 PM Steve Sakoman  wrote:
>
> On Fri, Feb 25, 2022 at 8:09 AM 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56286): https://lists.yoctoproject.org/g/yocto/message/56286
Mute This Topic: https://lists.yoctoproject.org/mt/89394327/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] QA change - reduced number of reproducibility builds tests?

2022-02-25 Thread Steve Sakoman 
On Fri, Feb 25, 2022 at 8:09 AM 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56285): https://lists.yoctoproject.org/g/yocto/message/56285
Mute This Topic: https://lists.yoctoproject.org/mt/89394327/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] QA change - reduced number of reproducibility builds tests?

2022-02-25 Thread 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




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56284): https://lists.yoctoproject.org/g/yocto/message/56284
Mute This Topic: https://lists.yoctoproject.org/mt/89394327/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] looking to boot core-image-minimal on meta-riscv board

2022-02-25 Thread 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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56283): https://lists.yoctoproject.org/g/yocto/message/56283
Mute This Topic: https://lists.yoctoproject.org/mt/89391983/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 2/2] packagegroup-security-tpm: Fix QA Error

2022-02-25 Thread 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 
---
 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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56282): https://lists.yoctoproject.org/g/yocto/message/56282
Mute This Topic: https://lists.yoctoproject.org/mt/89390792/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-security][PATCH 1/2] README.md: fix typo

2022-02-25 Thread Armin Kuster 
Fix typo in parsec-tools to parsec-tool

Signed-off-by: Armin Kuster 
---
 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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56281): https://lists.yoctoproject.org/g/yocto/message/56281
Mute This Topic: https://lists.yoctoproject.org/mt/89390791/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-security][PATCH] Upgrade parsec-tool to 0.5.1

2022-02-25 Thread Armin Kuster 

merged.

thanks
Armin

On 2/23/22 06:02, Anton Antonov wrote:

Signed-off-by: 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 \

[linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-soc & v5.10/standard/preempt-rt/nxp-sdk-5.10/nxp-soc][PATCH 1/1] Revert "scripts: Makefile: Enable creation of _symbols_ DT node for overlays"

2022-02-25 Thread Xiaolei Wang 
From: Jason Liu 

commit 3c02b480dc20f5f65afc7d51625b5fda40525672 from
https://source.codeaurora.org/external/imx/linux-imx

This reverts commit 11db97cab885454945c4e36d86a27864e994bad3.

The blamed commit changes the common Makefile and force creation of
__symbols__ node on the generated dtb files for all platforms.

This is not good and not acceptible under some cases due to this change
will increase the final DTB size a lot and bring big impact for others
who does not need creation of _symbols_ DT node for overlays.For
example, on i.MX OP-TEE, the maxsize of DT is 1MB, this patch will break
some of the i.MX6/i.MX7 boards to boot with OP-TEE enabled.

A similar patch was submitted and rejected by the community. The
following post discusses this:

https://lore.kernel.org/patchwork/patch/821645/

LS1028A-QDS, which needs the "-@" build flag for device tree overlays,
now sets the "DTC_FLAGS_fsl-ls1028a-qds" GNU Make variable in
arch/arm64/boot/dts/freescale/Makefile, and the support for overlays is
already built for it, so the reverted patch was not even necessary.

Signed-off-by: Jason Liu 
Signed-off-by: Vladimir Oltean 
Signed-off-by: Xiaolei Wang 
---
 scripts/Makefile.lib | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index b904c6b07860..94133708889d 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -297,9 +297,6 @@ endif
 
 DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
 
-# Enable creation of _symbols_ node for DT overlays
-DTC_FLAGS += -@
-
 # Generate an assembly file to wrap the output of the device tree compiler
 quiet_cmd_dt_S_dtb= DTB $@
 cmd_dt_S_dtb=  \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10988): 
https://lists.yoctoproject.org/g/linux-yocto/message/10988
Mute This Topic: https://lists.yoctoproject.org/mt/89387286/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-