Actually, I think this was some kind of missed PR opportunity. Regular
distros, such as RHEL, Debian and everyone else, are constantly trotting
out their support windows as the reason to hand them the job of making
products, so we could counter that better perhaps.
Alex
On Fri, 14 Jan 2022 at
On Fri, 2022-01-14 at 00:25 +0200, Igor Opaniuk wrote:
> Since 938595d1dc("wic: Add 512 Byte alignment to --offset") wic
> parser supports "s"/"S" suffixes, that can be used to align partition
> on 512 byte boundary. Nevertheless, the minimum value of size is still
> 1Kb.
>
> Introduce support
On Tue, Dec 21, 2021 at 10:15 AM Matt Madison via
lists.openembedded.org
wrote:
>
> On Tue, Dec 21, 2021 at 6:07 AM Paul Barker wrote:
> >
> > On 20/12/2021 22:34, Richard Purdie wrote:
> > > On Mon, 2021-12-20 at 17:01 +, Paul Barker wrote:
> > >> On 17/12/2021 15:36, Matt Madison wrote:
>
Overall I think this is going in the right direction, I need to review
it a little deeper and check the actual output.
I am not sure that you tested this against master as you use the old _
override syntax vs using a :.
See note below.
Sau!
On 1/12/22 11:40, Andres Beltran wrote:
From: Bruce Ashfield
Richard,
Here's the latest round of configuration, CVE, warning and -stable
fixes against the active kernels.
I've also included the lttng-modules fix again, since it supports the
5.16 work that is underway.
Bruce
The following changes since commit
From: Bruce Ashfield
Integrating the following commit(s) to linux-yocto/5.10:
fd84b99a8ccb drm/amd/display: Don't allow partial copy_from_user
024f4ff63d55 drm/amdgpu: Fix even more out of bound writes from debugfs
Signed-off-by: Paul Gortmaker
Signed-off-by: Bruce Ashfield
---
From: Bruce Ashfield
Integrating the following commit(s) to linux-yocto/5.15:
02bf23d26bc4 arm64: defconfig: cleanup config options
05914e2c87e5 arm: defconfig: drop unused POWER_AVS option
Signed-off-by: Ross Burton
Signed-off-by: Bruce Ashfield
---
.../linux/linux-yocto-rt_5.15.bb
From: Bruce Ashfield
Bumping lttng-modules to 2.13.1, which fixes the build against 5.16+
kernels.
We drop two previously backported patches.
The following commits are part of this update:
8c0aec7e Version 2.13.1
533556cd fix: mm: move kvmalloc-related functions to slab.h (v5.16)
From: Bruce Ashfield
Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:
d114b082bef7 Linux 5.15.14
b8a1293e3850 drm/amd/pm: keep the BACO feature enabled for suspend
19070d812e13 Revert "drm/amdgpu: stop scheduler when calling hw_fini
From: Bruce Ashfield
Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:
df395c763ba0 Linux 5.10.91
674071c9eb26 Input: zinitix - make sure the IRQ is allocated before it gets
enabled
ef81f7d406c2 ARM: dts: gpio-ranges property is now
From: Bruce Ashfield
Integrating the following commit(s) to linux-yocto-rt/5.15:
799919ec2113 v5.15.5-rt22
4745560a36e7 v5.15.3-rt21
9b4d36e0fbeb v5.15.2-rt20
d156320aca54 net: sched: gred: dynamically allocate tc_gred_qopt_offload
d36603e0d213 v5.15.2-rt19
7ddf3a205fa3
In some configurations (such as 32-bit arm), using printf() causes
gcc errors. Backport a patch from upstream to fix this.
Signed-off-by: Ross Burton
---
...ing-tweak-for-sprintf-precision-para.patch | 45 +++
.../systemtap/systemtap_git.inc | 1 +
2 files
On Fri, 14 Jan 2022 at 12:41, Zoltan Boszormenyi via
lists.yoctoproject.org wrote:
> It would also help if recipes staying on the same version
> but adding patches for e.g. CVE fixes should increase their
> PR value so their rebuilt versions can be put into a package repo.
>
> Throwing away the
Signed-off-by: Sakib Sajal
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2021-3593.patch | 40 +++
2 files changed, 41 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch
diff --git
Signed-off-by: Sakib Sajal
---
meta/recipes-devtools/qemu/qemu.inc | 3 +
.../qemu/qemu/CVE-2021-3592_1.patch | 58 ++
.../qemu/qemu/CVE-2021-3592_2.patch | 165 ++
.../qemu/qemu/CVE-2021-3592_3.patch | 40 +
4 files changed,
Signed-off-by: Sakib Sajal
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2021-3594.patch | 40 +++
2 files changed, 41 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch
diff --git
Signed-off-by: Sakib Sajal
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2021-3748.patch | 127 ++
2 files changed, 128 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3748.patch
diff --git
Signed-off-by: Sakib Sajal
---
meta/recipes-devtools/qemu/qemu.inc | 2 +
.../qemu/qemu/CVE-2021-20196_1.patch | 54 +++
.../qemu/qemu/CVE-2021-20196_2.patch | 67 +++
3 files changed, 123 insertions(+)
create mode 100644
While we're here, recipes inheriting qemu class should do this too, but for
the target dependencies.
Alex
On Fri, 14 Jan 2022 at 18:50, Jacob Kroon wrote:
> On 1/14/22 18:12, Joshua Watt wrote:
> > Native task outputs are directly run on the target (host) system after
>
> "target" or "host" ?
Native task outputs are directly run on the target (host) system after
being built. Even if the output of a native recipe doesn't change, a
change in one of its dependencies may cause a change in the output it
generates (e.g. rpm output depends on the output of its dependent zstd
library).
This
On Wed, Jan 12, 2022 at 1:40 PM Andres Beltran
wrote:
>
> Currently, SPDX SBOMs are only created for images. Add support for
> SDKs. Fix json indent when outputting SBOMs for better readability.
Most of us just pipe the output through `jq` to view it (colors are
really helpful). These files are
There's no need to copy files to the target when stap can take the short
probe directly.
Add more has-package decorators for the kernel source and GCC symlinks.
Remove the test dependencies as it's not a hard dependency.
Change the probe to print a message with some minimal logic, and verify
On 1/14/22 18:12, Joshua Watt wrote:
> Native task outputs are directly run on the target (host) system after
"target" or "host" ? the latter i suppose
> being built. Even if the output of a native recipe doesn't change, a
> change in one of its dependencies may cause a change in the output it
>
Please disregard, sorry for the barrage of incomplete patch set.
On 2022-01-14 1:03 p.m., Sakib Sajal wrote:
Signed-off-by: Sakib Sajal
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2021-3594.patch | 40 +++
2 files changed, 41
Please disregard, sorry for the barrage of incomplete patch set.
On 2022-01-14 1:03 p.m., Sakib Sajal wrote:
Signed-off-by: Sakib Sajal
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2021-3593.patch | 40 +++
2 files changed, 41
On Fri, 2022-01-14 at 13:10 -0500, Sakib Sajal wrote:
> Please disregard, sorry for the barrage of incomplete patch set.
Do you also have a branch on contrib that I can pull these patches
from?
Thanks,
Anuj
> On 2022-01-14 1:03 p.m., Sakib Sajal wrote:
>
> > Signed-off-by: Sakib Sajal
> >
On Sat, Jan 15, 2022 at 02:53:09AM +, Mittal, Anuj wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On Sat, 2022-01-15 at 10:37 +0800, Kevin Hao wrote:
> > From: Jagadeesh Krishnanjanappa
> >
> > The cryptographic unit is optional for the Cortex-A72, but it was
> >
On Sat, 2022-01-15 at 10:37 +0800, Kevin Hao wrote:
> From: Jagadeesh Krishnanjanappa
>
> The cryptographic unit is optional for the Cortex-A72, but it was
> included by default previously. This breaks building systems that
> lack this functionality when using tune-cortexa72.inc.
>
> To
From: Jagadeesh Krishnanjanappa
The cryptographic unit is optional for the Cortex-A72, but it was
included by default previously. This breaks building systems that
lack this functionality when using tune-cortexa72.inc.
To correct this, add a crypto entry in the tune file. Since CRC is
Hi,
This patch series backport two patches from the master branch to fix the
crash issue on some cortexa72 boards due to the crypto intructions are
used.
Jagadeesh Krishnanjanappa (1):
tune-cortexa72: remove crypto for the default cortex-a72
Kevin Hao (1):
tune-cortexa72: Enable the crc
The crc extension is optional for the ARMv8.0 but is mandatory for the
cortexa72, so there is no reason not to enable it for the cortexa72
tune. With this change, the cortexa72-crc seems redundant. But we
had better to keep it to be compatible with the BSP which already used
that tune.
(From
Backport fixes for CVE-2021-22922, CVE-2021-22923, CVE-2021-22945,
CVE-2021-22946, and CVE-2021-22947.
* https://curl.se/docs/CVE-2021-22922.html
* https://curl.se/docs/CVE-2021-22923.html
* https://curl.se/docs/CVE-2021-22945.html
* https://curl.se/docs/CVE-2021-22946.html
*
This adds support for the armv8.5a architecture and the crypto
extension.
(From OE-Core rev: 0cb1a6d9cb4c32526d79dad93c8053b3793053f8)
Signed-off-by: Kevin Hao
Signed-off-by: Richard Purdie
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao
---
This adds the support for the Neoverse N2 core, even though the
Neoverse N2 core implements the Arm v9.0-A architecture, but the support
of it in GCC is based on the Arm v8.5-A architecture. Please see the
commit 50d9db203bc3 ("aarch64: Add support for Neoverse N2 CPU") in GCC
for more detail.
Hi,
The gcc patches for the Neoverse N2 core have been merged into hardknott
branch, this patch series backport two patches from the master branch to
add the corresponding tune files.
Kevin Hao (2):
arch-armv8-5a.inc: Add tune include for armv8.5a
armv9a/tune: Add the support for the
On 14/10/2021 21:26, Richard Purdie wrote:
In 2017 we added changes to pass the BUILD_CFLAGS into the kernel
via BUILD_CC. This isn't really correct and the upstream kernel now has
places to pass build cflags, ldflags and more. Update our kernel
make flags to correctly use the kernel's
Perhaps you could look at how this is handled in mozjs recipe in meta-oe, I
vaguely remember it forces panic strategy to something incompatible and I
patched it to match..
Alex
On Fri, 14 Jan 2022 at 15:21, Francesco Pham
wrote:
> Hi,
> the following error appears when trying to build a simple
From: Bruce Ashfield
The 5.16 kernel introduced mandatory schema checking on any dtb file
built through the kernel.
That funcionality is provided via python3-dt-schema.
The dependencies to enable that functionality is not small, and may
not always be desired (in particular on architectures
Hi,
the following error appears when trying to build a simple rust hello
world that uses panic set to abort mode.
> | DEBUG: Executing shell function do_compile
> | NOTE: cargo =
>
Funny you mention PR.
It would also help if recipes staying on the same version
but adding patches for e.g. CVE fixes should increase their
PR value so their rebuilt versions can be put into a package repo.
Throwing away the buildroot (as suggested any time some obscure
build error happens) and
On Fri, 2022-01-14 at 02:31 -0800, Matt Madison wrote:
> On Tue, Dec 21, 2021 at 10:15 AM Matt Madison via
> lists.openembedded.org
> wrote:
> >
> > On Tue, Dec 21, 2021 at 6:07 AM Paul Barker
> > wrote:
> > >
> > > On 20/12/2021 22:34, Richard Purdie wrote:
> > > > On Mon, 2021-12-20 at
On Fri, 2022-01-14 at 07:14 +, Matthias Klein wrote:
> Hello together,
>
> I would like to add a question to the topic:
>
> Why was the LTS period for dunfell extended?
> Can we expect the same for kirstone?
The project members agreed to fun an extension to the lifetime of dunfell from 2
From: Bruce Ashfield
The 5.16 kernel introduced mandatory schema checking on any dtb file
built through the kernel.
That funcionality is provided via python3-dt-schema.
The dependencies to enable that functionality is not small, and may
not always be desired (in particular on architectures
43 matches
Mail list logo
