From: Changqing Li
use ?= to set following configs in order to allow user
to override the default settings:
PREFERRED_VERSION_llvm
PREFERRED_VERSION_llvm-native
PREFERRED_VERSION_nativesdk-llvm
Signed-off-by: Changqing Li
---
meta/conf/distro/include/tcmode-default.inc | 6 +++---
1 file
Hi,
I think this patch should be applied as it aligns oeqa .py and .text file
searches
across layers. Without this layers need to add "addpylib ${LAYERDIR}/lib oeqa"
in layer.conf which doesn't have any other uses and debugging this is really
hard.
There may be addition things wrong in bitbake
Hello Raj,
I will try to take a look on this today. Is the patch the same as here
https://git.yoctoproject.org/poky-contrib/commit/?h=yoe/mut=c0594edef0d2108860421d0cfd460993264e18c3
? Means, if I can take it from there.
Thanks,
Andy
On 17.01.2024 08:20, Khem Raj wrote:
On Tue, Jan 16,
>
> Hello,
>
> This doesn't apply on top of your previous patches. Can you send a proper
> series with what you want to be tested/applied?
>
> Thanks!
>
Hi Alexandre
I created a series patch here,
https://patchwork.yoctoproject.org/project/oe-core/list/?series=21444
Thanks-Jamin
> On
Currently, u-boot FIT image only support to load u-boot image.
To support optee-os and trusted-firmware-a, update ITS file generation
scripts, so users are able to use u-boot FIT image to load
u-boot, optee-os and treustred-firmware-a images
Add a variable "UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A" to
Add to check dtb file exist, then install it.
Signed-off-by: Jamin Lin
---
meta/classes-recipe/uboot-sign.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes-recipe/uboot-sign.bbclass
b/meta/classes-recipe/uboot-sign.bbclass
index abde0bc61c..4b462698f9
It does not verify the signed FIT image of kernel and uboot.
To catch the unexpected errors as far as possible at the build time,
add uboot-fit-check-sign tool which is provided by u-boot to
verify the signed FIT image.
Signed-off-by: Jamin Lin
---
meta/classes-recipe/uboot-config.bbclass | 3
According to the design of uboot-sign.bbclass and kernel-fitimage.bbclass,
both of them use an UBOOT_LOADADDRESS variable to set the load address of
kernel and u-boot image and use an UBOOT_ENTRYPOINT variable to set the entry
address of
kernel and u-boot image.
However, users may want to set
Upstream-Status: Backport from
https://github.com/linux-pam/linux-pam/commit/031bb5a5d0d950253b68138b498dc93be69a64cb
Signed-off-by: Hitendra Prajapati
---
.../pam/libpam/CVE-2024-22365.patch | 62 +++
meta/recipes-extended/pam/libpam_1.5.2.bb | 1 +
2 files
ping
On 12/26/23 12:44, Chen Qi via lists.openembedded.org wrote:
From: Chen Qi
The initial_revs["."] does not have an initial value, resulting
in the following error:
KeyError: '.'
The problem could be reproduced by running:
devtool modify -n systemd
Signed-off-by: Chen Qi
---
What's the status of this patch series?
Is there any issue or concern that I missed?
Regards,
Qi
On 12/27/23 12:20, Chen Qi via lists.openembedded.org wrote:
From: Chen Qi
1. Patch changes:
0004-Move-sysusers.d-sysctl.d-binfmt.d-modules-load.d-to-.patch
is removed because it has no real
I'm seeing build failures on Ubuntu 20.04.
GCC version: 9.4.0
1. error: parameter name omitted
The problem is that the active_sessions_count function's definition
lacks parameter. I did change like below:
-unsigned long active_sessions_count(const char *name, unsigned long unused)
+unsigned
From: Vijay Anusuri
CVE-2024-0553
A vulnerability was found in GnuTLS. The response times to malformed
ciphertexts in RSA-PSK ClientKeyExchange differ from response times of
ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote
attacker to perform a timing side-channel
From: Vijay Anusuri
Backport https://sqlite.org/src/info/0e4e7a05c4204b47
Signed-off-by: Vijay Anusuri
---
.../sqlite/files/CVE-2023-7104.patch | 46 +++
meta/recipes-support/sqlite/sqlite3_3.31.1.bb | 1 +
2 files changed, 47 insertions(+)
create mode 100644
On 2024-01-17 11:09 a.m., Steve Sakoman via lists.openembedded.org wrote:
On Wed, Jan 17, 2024 at 1:47 AM Hitendra Prajapati via
lists.openembedded.org
wrote:
Upstream-Status: Backport
fromhttps://github.com/openssl/openssl/commit/e09fc1d746a4fd15bb5c3d7bbbab950aadd005db
Signed-off-by:
Backport a typo fix RISCV_HAS_ZKND_ZKNE -> RISCV_HAS_ZKND_AND_ZKNE
Signed-off-by: Khem Raj
---
...x-mispelling-of-extension-test-macro.patch | 31 +++
.../openssl/openssl_3.2.0.bb | 1 +
2 files changed, 32 insertions(+)
create mode 100644
Hello,
This fails pkgman-non-rpm:
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/8412
On 18/01/2024 11:24:06+0100, Alexander Kanavin wrote:
> The tests rely on that, and so the discovery shouldn't simply
> fall through.
>
> Signed-off-by: Alexander Kanavin
> ---
>
On Thu, Jan 18, 2024 at 12:21 PM Randy MacLeod
wrote:
> Yogita,
> Pleae tell people if you will send a v2 or if you plan to fix the warning
> in a follow-up commit.
>
> I don't see your commit in Steve's kirkstone-nut repo so I think he's
> expecting a v2.
>
>
>
Yogita,
Pleae tell people if you will send a v2 or if you plan to fix the
warning in a follow-up commit.
I don't see your commit in Steve's kirkstone-nut repo so I think he's
expecting a v2.
https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut
../Randy
On 2024-01-18 5:57 a.m., yash.shi...@windriver.com wrote:
From: Yash Shinde
Enable rust oe-selftest for rust 1.74.1 version and
add target_cfg.patch to handle target configurations
for custom targets.
Hi Yashe,
Yay, getting the rust test suite working again great news!
We talked about this
From: Joe Slater
Consider a name based on mac address in addition to
those based on slot or path.
Note that as of this commit predictable naming is
suppressed by eudev, but can be enabled by removing
/etc/udev/rules.d/80-net-name-slot.rules from the
root filesystem.
Signed-off-by: Joe Slater
Sorry for the noise and back and forth on rng-tools removal.
I'll avoid hastily cleaning up things for a while! ;-)
On 2024-01-18 11:59 a.m., Randy MacLeod via lists.openembedded.org wrote:
From: Randy MacLeod
This reverts commit d2b445384da3f3e6dab8577b6c56648b5244a788.
Revert this commit
From: Timotheus Giuliani
Installing the linux-firmware-dev package fails because of the following
problem.
For each mediatek MT76x firmware a separate license package was declared.
In all these license packages the same file was referenced as the license file.
This meant that if several of
From: Randy MacLeod
This reverts commit d2b445384da3f3e6dab8577b6c56648b5244a788.
Revert this commit since:
- some systems using oe-core master may still be using kernels from
before 5.6 pulled in the rng-tools algorithm, and
- some hardware platforms may not have a hardware random
We occasionally see races over the lockfile used by externalsrc/devtool
when walking files for the source_date_epock calculation. Skip this file
if present to avoid the issues and fix a real issue where SDE could be
contaminated too.
[YOCTO #14921]
Signed-off-by: Richard Purdie
---
On Thu, 18 Jan 2024 at 15:51, Richard Purdie
wrote:
>
> On Thu, 2024-01-18 at 15:37 +0200, Dmitry Baryshkov wrote:
> > On Thu, 18 Jan 2024 at 11:59, Richard Purdie
> > wrote:
> > >
> > > On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> > > > On Thu, 11 Jan 2024 at 15:15, Alexander
This commit creates a dummy fitImage to feed to mkimage when adding the
public key to the U-Boot dtb. This instead of using the Linux fitImage.
The dependency on Linux fitImage availability from U-Boot recipes can
then be removed, breaking a dependecy loop created when trying to add
a boot script
When trying to sign a Linux fitImage including a U-Boot boot script we
end up in a dependency loop.
In this scenario adding the public key used to sign the fitImage to the
U-Boot dtb depends on the availability of the Linux fitImage. The
fitImage in turn can not be created before the boot script
On Thu, 18 Jan 2024, Alexander Kanavin wrote:
> On Thu, 18 Jan 2024 at 15:10, Robert P. J. Day wrote:
> > ah, got it. that's still fine since as the content is almost
> > exclusively binary (pre-built) content, redoing from scratch will take
> > no time at all. thanks for clarifying that.
>
>
On Thu, 18 Jan 2024 at 15:10, Robert P. J. Day wrote:
> ah, got it. that's still fine since as the content is almost
> exclusively binary (pre-built) content, redoing from scratch will take
> no time at all. thanks for clarifying that.
Pre-built content is ok on its own, but if those items are
On Thu, 18 Jan 2024, Alexander Kanavin wrote:
> On Thu, 18 Jan 2024 at 15:04, Robert P. J. Day wrote:
> > i just tested, and the recipe does *not* rebuild unless i change
> > something in the ("externalsrc") source directory, at which point,
> > yes, it rebuilds. which is exactly what i'm
This is reusing an existing build directory (Wanted 96 Local 96). You
need to make a new one first.
Alex
On Thu, 18 Jan 2024 at 15:06, Robert P. J. Day wrote:
>
> On Thu, 18 Jan 2024, Alexander Kanavin wrote:
>
> > Mono-repo seemed like a good idea at the time, I'm sure.
> >
> > I need to point
On Thu, 18 Jan 2024, Alexander Kanavin wrote:
> Mono-repo seemed like a good idea at the time, I'm sure.
>
> I need to point out that externalsrc disables sstate and always
> rebuilds from scratch. Is that okay?
just tested a bitbake on recipe after changing nothing:
Sstate summary: Wanted 96
On Thu, 18 Jan 2024 at 15:04, Robert P. J. Day wrote:
> i just tested, and the recipe does *not* rebuild unless i change
> something in the ("externalsrc") source directory, at which point,
> yes, it rebuilds. which is exactly what i'm after.
It only doesn't rebuild because you already have a
On Thu, 18 Jan 2024, Alexander Kanavin wrote:
> Mono-repo seemed like a good idea at the time, I'm sure.
>
> I need to point out that externalsrc disables sstate and always
> rebuilds from scratch. Is that okay?
i just tested, and the recipe does *not* rebuild unless i change
something in the
Hello,
This doesn't apply on top of your previous patches. Can you send a
proper series with what you want to be tested/applied?
Thanks!
On 17/01/2024 10:10:51+0800, Jamin Lin via lists.openembedded.org wrote:
> Currently, u-boot FIT image only support to load u-boot image.
> To support
On Thu, 2024-01-18 at 15:37 +0200, Dmitry Baryshkov wrote:
> On Thu, 18 Jan 2024 at 11:59, Richard Purdie
> wrote:
> >
> > On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> > > On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> > > wrote:
> > > >
> > > > shadow 4.14.x adds a number
On Thu, 18 Jan 2024 at 11:59, Richard Purdie
wrote:
>
> On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> > On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> > wrote:
> > >
> > > shadow 4.14.x adds a number of libraries it dynamically links with
> > > (md, bsd, attr). This causes
On Thu, 18 Jan 2024 at 12:13, Alexander Kanavin wrote:
>
> I'd like to clarify the 'randomly' part: does the failure disappear if
> you re-run bitbake on the same build directory, or is it random only
> between different builds?
It is random between different builds. Rerunning the build
Mono-repo seemed like a good idea at the time, I'm sure.
I need to point out that externalsrc disables sstate and always
rebuilds from scratch. Is that okay?
Alex
On Thu, 18 Jan 2024 at 13:58, Robert P. J. Day wrote:
>
>
> i'm pretty sure i know how to do this, just want to know if there's
i'm pretty sure i know how to do this, just want to know if there's
an even easier/more elegant way.
in current project, there is a *pile* of local content that is
identified by various recipes. so since that content is local, the
obvious starting point is for such recipes to "inherit
From: Kai Kang
Update xserver-xorg from 21.1.9 to 21.1.11.
Release Notes of 21.1.11 [1]:
This release contains fixes for the issues reported in today's security
advisory: https://lists.x.org/archives/xorg/2024-January/061525.html
* CVE-2023-6816
* CVE-2024-0229
* CVE-2024-21885
*
Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:
---
Testing patch
/home/patchtest/share/mboxes/kirkstone-1-1-tiff-fix-CVE-2023-6228.patch
FAIL: test CVE check ignore: CVE_CHECK_IGNORE is deprecated and should
From: Yash Shinde
Enable rust oe-selftest for rust 1.74.1 version and
add target_cfg.patch to handle target configurations
for custom targets.
The testing is done on arm32, arm64, mips64, x86 and x86_64 targets.
Signed-off-by: Yash Shinde
---
meta/lib/oeqa/selftest/cases/rust.py |
From: Yogita Urade
CVE-2023-6228:
An issue was found in the tiffcp utility distributed by the
libtiff package where a crafted TIFF file on processing may
cause a heap-based buffer overflow leads to an application
crash.
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-6228
Upstream has replaced autoconf with cmake, which necessitates a rewrite of the
recipe and available options, and a rebase to cmake of
0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch
Correct a mistake in 0001-Do-not-read-config-files-from-HOME.patch :
the patch was removing the
rpm 4.19 automatically generates provides and depends for user and
groups:
https://github.com/rpm-software-management/rpm/blob/rpm-4.19.x/docs/manual/users_and_groups.md#dependencies
This mechanism relies on sysusers.d for the 'provides'
part, and thus is systemd-only at best. So we need to
Per
https://github.com/rpm-software-management/rpm/commit/77d3529c31ca090a40b8d3959a0bcdd721a556d6
rpm 4.19.1+ will not consider actual filesystem permissions and ownership, and
will quietly default
to root if not expictly set otherwise in .spec file.
Signed-off-by: Alexander Kanavin
---
The tests rely on that, and so the discovery shouldn't simply
fall through.
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/runtime/cases/rpm.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/runtime/cases/rpm.py
b/meta/lib/oeqa/runtime/cases/rpm.py
I'd like to clarify the 'randomly' part: does the failure disappear if
you re-run bitbake on the same build directory, or is it random only
between different builds? If it's deterministic in the same build
directory, then you can narrow it down to the specific tar invocation
directly from command
On Wed, 2024-01-17 at 14:46 +0200, Dmitry Baryshkov wrote:
> On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> wrote:
> >
> > shadow 4.14.x adds a number of libraries it dynamically links with
> > (md, bsd, attr). This causes troubles in setscene tasks where
> > shadow executables are used
On Wed, 17 Jan 2024 at 14:46, Dmitry Baryshkov wrote:
>
> On Thu, 11 Jan 2024 at 15:15, Alexander Kanavin
> wrote:
> >
> > shadow 4.14.x adds a number of libraries it dynamically links with
> > (md, bsd, attr). This causes troubles in setscene tasks where
> > shadow executables are used (such
52 matches
Mail list logo
