On 1/22/25 00:41, Marko, Peter wrote:
This is not correct.
The patch CVE-2024-3596_00 does not fix any part of that CVE.
As the commit message says, it's a style commit so that real CVE patches apply
cleanly.
If it bothers you that it has CVE in filename but no CVE, maybe rename it
instead a
On Tue, Jan 21, 2025 at 8:52 PM ChenQi wrote:
>
> On 1/22/25 12:18, Khem Raj wrote:
> > On Tue, Jan 21, 2025 at 7:03 PM Chen Qi via lists.openembedded.org
> > wrote:
> >> ping
> >>
> >> Is there something I need to do for this patch? Or is this patch not
> >> suitable for oe-core?
> >>
> > if we
On 1/22/25 12:18, Khem Raj wrote:
On Tue, Jan 21, 2025 at 7:03 PM Chen Qi via lists.openembedded.org
wrote:
ping
Is there something I need to do for this patch? Or is this patch not
suitable for oe-core?
if we are enabling 64K pages then 32bit aarch32 apps should also be
compiled using 64k p
Add 2 cases to test multiconfig multlib nativesdk gcc
1. test_multiconfig_64bit_gcc_suport_32bit_multilib
Build 64bit x86_64 buildtools-tarball with package
nativesdk-multiconfig-multlib-toolchain-packager-x86.
The recipe nativesdk-multiconfig-multlib-toolchain-packager trigger a x86
multiconfig
While SPDX_INCLUDE_SOURCES = "1", do_create_spdx error happens for
these recipes inherit dos2unix
Refer [1] to fix the issue
[1]
https://git.openembedded.org/openembedded-core/commit/?id=2ceda7c90c0087f52693c54d5ccab143b27f4d21
Signed-off-by: Hongxu Jia
---
meta/lib/oe/spdx_common.py | 2 ++
seems ok to me.
On Tue, Jan 21, 2025 at 12:55 AM hongxu via lists.openembedded.org
wrote:
>
> We have patch 0016-handle-sysroot-support-for-nativesdk-gcc.patch to handle
> sysroot support for nativesdk-gcc, and add %r target_relocatable_prefix
> into spec file for nativesdk-gcc relocation. It was
On Tue, Jan 21, 2025 at 7:03 PM Chen Qi via lists.openembedded.org
wrote:
>
> ping
>
> Is there something I need to do for this patch? Or is this patch not
> suitable for oe-core?
>
if we are enabling 64K pages then 32bit aarch32 apps should also be
compiled using 64k pages. Usually this could me
From: Peter Marko
Cherry-pick commit
https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=2ff2da7ac374a790f8b2a0216bcb4e3126498225
Signed-off-by: Peter Marko
Signed-off-by: Steve Sakoman
---
.../ofono/ofono/CVE-2023-4232.patch | 31 +++
meta/recipes-conn
From: Chen Qi
The '-fdebug-prefix-map' options are used to map source files locations,
otherwise, DW_AT_comp_dir will contain buildpath.
The '-gno-record-gcc-switches' option is used to fix the buildpath introduced
by '-fintrinsic-modules-path' option, which is automatically added by fortran.
He
From: Esben Haabendal
Since pulseaudio v16.99.1, the library needed is webrtc-audio-processing-1.
This fixes
Run-time dependency webrtc-audio-processing-1 found: NO (tried pkgconfig and
cmake)
Looking for a fallback subproject for the dependency webrtc-audio-processing-1
../pulseaudio-17.0/mes
Please review this set of changes for scarthgap and have comments back by
end of day Thursday, January 23
Passed a-full on autobuilder:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/29/builds/856
The following changes since commit 92eea72a25e553c698bee9e3f551a5880bd4631c:
systemd:
From: Ross Burton
Using the package architecture to select the right qemu options to pass
to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH
to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are
not typically any options set for the machine name.
Solve this b
From: Peter Marko
Cherry-pick commit
https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=29ff6334b492504ace101be748b256e6953d2c2f
Signed-off-by: Peter Marko
Signed-off-by: Steve Sakoman
---
...024-7540_CVE-2024-7541_CVE-2024-7542.patch | 52 +++
meta/recipes-conn
From: Alexis Lothoré
The ssh target is currently well tailored to easily retrieve textual output
from a command run on a remote target. It could also be used to retrieve
raw data from a command run onto a remote target (for example, to feed this
data directly to another program), but it currently
From: Zhang Peng
CVE-2024-52616:
A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs
randomly only once at startup, incrementing them sequentially after that. This
predictable behavior facilitates DNS spoofing attacks, allowing attackers to
guess transaction IDs.
Refer
From: Peter Marko
Picked upstream commit
https://repo.or.cz/socat.git/commitdiff/4ee1f31cf80019c5907876576d6dfd49368d660f
Since this was the only commit in 1.8.0.2 it also contained release
changes which were dropped.
Signed-off-by: Peter Marko
Signed-off-by: Steve Sakoman
---
.../socat/file
From: Ross Burton
The nativesdk class overrides PACKAGE_ARCH and unsets TUNE_FEATURES, but
as recipes might want to look at TUNE_PKGARCH too (for example, when
setting QEMU_EXTRAOPTIONS) we should also override that variable.
Otherwise, a nativesdk recipe will have the TUNE_PKGARCH of the target
From: Catalin Popescu
This reverts commit 49391fdcf71b32c5fd3c7b134c1d1c45cc1db388 which
introduced a bluetooth regression on systems with read-only rootfs.
When configuration files are missing, bluez tries to generate them which
fails on a read-only rootfs. As a result bluetooth service fails t
From: Aleksandar Nikolic
Update to the 5.0.6 release of the 5.0 series for buildtools.
Signed-off-by: Aleksandar Nikolic
Signed-off-by: Steve Sakoman
---
scripts/install-buildtools | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/install-buildtools b/scripts/ins
From: Peter Marko
Cherry-pick commit
https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=02aa0f9bad3d9e47a152fc045d0f51874d901d7e
Signed-off-by: Peter Marko
Signed-off-by: Steve Sakoman
---
.../ofono/ofono/CVE-2023-4235.patch | 38 +++
meta/recipes-conn
From: Hitendra Prajapati
Backport fixes for:
* CVE-2024-7539 - Upstream-Status: Backport from
https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=389e2344f86319265fb72ae590b470716e038fdc
* CVE-2024-7543 - Upstream-Status: Backport from
https://git.kernel.org/pub/scm/network/ofono
From: Divya Chellam
Applications that use Wget to access a remote resource using
shorthand URLs and pass arbitrary user credentials in the URL
are vulnerable. In these cases attackers can enter crafted
credentials which will cause Wget to access an arbitrary host.
Reference:
https://nvd.nist.gov
ping
Is there something I need to do for this patch? Or is this patch not
suitable for oe-core?
Regards,
Qi
On 1/16/25 12:34, Chen Qi via lists.openembedded.org wrote:
Ping
Ross & Richard, is there anything else I need to do for this patch?
Regards,
Qi
-Original Message-
From: Che
On 1/21/25 6:06 AM, Ganesh Mahajan via lists.openembedded.org wrote:
when tried to build image using command bitbake -k wac-core-image below error
poped up.
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own ris
On Fri Jan 17, 2025 at 3:58 PM CST, a-christidis via lists.openembedded.org
wrote:
> From: Antonios Christidis
>
> This recipe provides the opecl-cts suite. This is a pre-release version
> v2024-08-08, which I have tested to work with opencl-headers version
> v2024.05.08
> . The pre-release ver
This issue has been raised to the upstream, who stated that in addition to
linux-gnueabi, there are many other types that need to be matched, so they have
included the modifications in the to-do list.
--
Best Regards
---
Wang Mingyu
FUJITSU NANJI
On 1/21/25 1:34 PM, Richard Purdie wrote:
On Sun, 2025-01-19 at 19:08 +0100, Marek Vasut wrote:
In case both UBOOT_SIGN_ENABLE and UBOOT_ENV are enabled and
kernel-fitimage.bbclass is in use to generate signed kernel
fitImage, there is a circular dependency between uboot-sign
and kernel-fitimage
In case both UBOOT_SIGN_ENABLE and UBOOT_ENV are enabled and
kernel-fitimage.bbclass is in use to generate signed kernel
fitImage, there is a circular dependency between uboot-sign
and kernel-fitimage bbclasses . The loop looks like this:
kernel-fitimage.bbclass:
- do_populate_sysroot depends on d
We have a patch to allow us to 'poison' system include directories,
which are warnings by default but we make them fatal in cross builds.
However, in the 13.1 upgrade[1] the patch to make the warnings fatal was
dropped in the compiler invocation, so it only took effect for pure
preprocessor calls.
The test code in poison was flawed: as long as one CPP/CC/CXX has fatal
poisoning enabled then the test passes. However, at the moment due to
a bad rebase only CPP has fatal poisoning and CC/CXX do not.
Rewrite the do_compile() task to more carefully check the output so the
test harness itself ju
This is not correct.
The patch CVE-2024-3596_00 does not fix any part of that CVE.
As the commit message says, it's a style commit so that real CVE patches apply
cleanly.
If it bothers you that it has CVE in filename but no CVE, maybe rename it
instead adding incorrect tag?
Peter
> -Origin
The recent changes in Yocto master with the unmodified recipe didn't help.
But npmsw://...;destsuffix=npm in the recipe did.
Thanks again!
2025. 01. 21. 12:27 keltezéssel, Zoltan Boszormenyi via lists.openembedded.org
írta:
That's it! ;destsuffix=npm helped with Yocto 5.1.
Thank you very much!
On Tue Jan 21, 2025 at 2:19 PM CET, Mathieu Dubois-Briand wrote:
> On Mon Jan 20, 2025 at 5:45 PM CET, Enrico Scholz via lists.openembedded.org
> wrote:
> > From: Enrico Scholz
> >
> > Although rust differs between compiling (--> 'rust-cc' wrapper) and
> > linking (--> 'rust-ccld' wrapper), some
hi
actually patch v1 used g++ and was compiling a "hello world" .cpp program but
on of the comments was to change to gcc and c program.
You can see a bit more about that here
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15712
What is your opinion ?
Regarding the rest of the comments , I wi
On 16 Jan 2025, at 00:19, wangmy via lists.openembedded.org
wrote:
>
> From: Wang Mingyu
>
> The setting of want_xterm_kbs is as following:
> case $host_os in
> (*linux-gnu|*cygwin|*mingw32|*msys)
>want_xterm_kbs=DEL
>;;
> (*)
>want_xterm_kbs=BS
>;;
> esac
>
> The host_os when
On Tue, 21 Jan 2025 at 16:31, Ross Burton via lists.openembedded.org
wrote:
> > The host_os when enable multilib is as folloing:
> > host_os of aarch64 : linux-gnu
> > host_os of aarch32 : linux-gnueabi
>
> Seems like the proper fix would be to change the glob to *linux-gnu* (and
> sent that upst
On 16 Jan 2025, at 13:48, Sadineni, Harish via lists.openembedded.org
wrote:
>
> From: Harish Sadineni
>
> The do_testsdk for lib32-core-image-sato aborts with below error:
> configure: error: Package requirements (gtk+-3.0) were not met:
> No package 'gtk+-3.0' found
> Consider adjusting the
On Mon, Jan 20, 2025 at 6:10 AM Denis OSTERLAND-HEIM via
lists.openembedded.org
wrote:
>
> LIC_FILES_CHKSUM supports begin-/endline for licenses included in
> for instance header files. This patch adds support for line numbers
> to NO_GENERIC_LICENSE, too.
>
> Signed-off-by: Denis Osterland-Heim
Hi,
Some more comments:
The shortlog says “C toolchain” but the test is for the C++ toolchain not C,
correct?
> +def check_c_toolchain(d):
> +try:
> +with NamedTemporaryFile(delete=False, suffix=".c") as c_file:
Why delete=False and then manual cleanup later? You can move the com
when tried to build image using command bitbake -k wac-core-image below error
poped up.
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see
sanity.conf).
Following is the list of potential p
When tried to generate image got below error.
Command used to generate image: bitbake -k wac-core-image
In dunfell we had no such configuration for TUNE_ARCH in /conf/machine but in
scarthgap below error was thrown.
Is it good practice to disable the checker?
E *RROR: OE-core's config sanity c
On Mon Jan 20, 2025 at 5:45 PM CET, Enrico Scholz via lists.openembedded.org
wrote:
> From: Enrico Scholz
>
> Although rust differs between compiling (--> 'rust-cc' wrapper) and
> linking (--> 'rust-ccld' wrapper), some core crates are using only the
> 'rust-cc' wrapper to check for available com
On Sun, 2025-01-19 at 19:08 +0100, Marek Vasut wrote:
> In case both UBOOT_SIGN_ENABLE and UBOOT_ENV are enabled and
> kernel-fitimage.bbclass is in use to generate signed kernel
> fitImage, there is a circular dependency between uboot-sign
> and kernel-fitimage bbclasses . The loop looks like this
Am 21.01.25 um 09:55 schrieb Richard Purdie:
On Tue, 2025-01-21 at 09:12 +0100, Jan Strater-Büddefeld via
lists.openembedded.org wrote:
Fixes [YOCTO #15579]
This commit removes the LD_LIBRARY_PATH wrapper around `cargo`.
Setting the LD_LIBRARY_PATH causes many problems.
Some build scripts will
That's it! ;destsuffix=npm helped with Yocto 5.1.
Thank you very much!
I will re-test with Yocto master and report back.
2025. 01. 21. 11:53 keltezéssel, Martin Jansa írta:
I believe it's the side effect of UNPACKDIR changes, I had to add
;destsuffix=npm in all npmsw:// entries (or ;destsuffix=
On Tue, 2025-01-21 at 02:54 -0800, Yash Shinde via lists.openembedded.org wrote:
> From: Yash Shinde
>
> - The SDK uses a cargo wrapper that sets LD_LIBRARY_PATH to point to SDK
> target library directory.
> This wrapper was added to resolve library path errors by including libdir
> and base_
From: Yash Shinde
- The SDK uses a cargo wrapper that sets LD_LIBRARY_PATH to point to SDK target
library directory.
This wrapper was added to resolve library path errors by including libdir and
base_dir paths
in LD_LIBRARY_PATH for tumbleweed-ty-3 distro.
(https://git.openembedded.org/o
I believe it's the side effect of UNPACKDIR changes, I had to add
;destsuffix=npm in all npmsw:// entries (or ;destsuffix=git where S is
set to WORKDIR/git) for dependencies in node_modules to be unpacked
where they used to be before.
On Tue, Jan 21, 2025 at 11:31 AM Zoltan Boszormenyi via
lists.o
Looks good. Thanks for the patch.
Slava
On 18.01.2025 19:49, Esben Haabendal via lists.openembedded.org wrote:
The RequiresMountsFor configuration option of systemd.unit (added in
systemd version 201) not only adds the Requires and After options for
the required mount unit, but it adds them for
There have been recent npm fetcher fixes in master, can you try that please?
Alex
On Tue, 21 Jan 2025 at 11:31, Zoltan Boszormenyi via
lists.openembedded.org
wrote:
>
> Hi,
>
> I have a minimalistic recipe for pm2 (https://www.npmjs.com/package/pm2):
> ==
> node-p
Hi,
I have a minimalistic recipe for pm2 (https://www.npmjs.com/package/pm2):
==
node-pm2_5.3.1.bb
==
SUMMARY = "Production process manager for Node.JS applications with a built-in load
balancer."
HOMEPAGE = "http://pm2.keymetrics.i
Support two mutliconfig build x86 and x86_64:
1. Trigger a x86 multiconfig build to generate 32bit x86 buildtools-tarball.
During package runtime installation, script postinst extracted 32bit x86
buildtools-tarball and installed it to 64bit x86_64 nativesdk sysroot.
2. Trigger a x86_64 multiconfi
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/8-9-Add-recipe-nativesdk-multiconfig-multlib-toolchain-packager.patch
FAIL: test shortlog format: Commit shortlog (
Otherwise 32bit i686 nativesdk-gcc compiled 64bit executable file
failed
$ cat << ENDOF > main.c
int main() {
return 0;
}
ENDOF
$ i686-pokysdk-linux-gcc -m64 main.c -o main
cc1: sorry, unimplemented: 64-bit mode not compiled in
[ YOCTO #15722 ]
Signed-off-by: Hongxu Jia
---
meta/conf/bitba
Due to the supported SDKMACHINE includes:
aarch64, i586, i686, loongarch64, ppc64, ppc64le, riscv64, x86_64
Only i586 and x86_64, i686 and x86_64 have multilib relationship,
so create multilib symlinks for i686,i586,x86_64 nativesdk. It will
have no regression when nativesdk-gcc disable multili
Support two mutliconfig build x86 and x86_64:
1. Trigger a x86 multiconfig build to generate 32bit x86 buildtools-tarball.
During package runtime installation, script postinst extracted 32bit x86
buildtools-tarball and installed it to 64bit x86_64 nativesdk sysroot.
2. Trigger a x86_64 multiconfi
While multiple dynamic loader existed, in order to make executable file is
interpreted by the expected dynamic loader, relocating interpreter only if
the new dynamic loader and executable file have the same arch
[ YOCTO #15722 ]
Signed-off-by: Hongxu Jia
---
scripts/relocate_sdk.py | 32 +++
Add 2 cases to test multiconfig multlib nativesdk gcc
1. test_multiconfig_64bit_gcc_suport_32bit_multilib
Build 64bit x86_64 buildtools-tarball with package
nativesdk-multiconfig-multlib-toolchain-packager-x86.
The recipe nativesdk-multiconfig-multlib-toolchain-packager trigger a x86
multiconfig
While set 'baselib = "lib64"' for nativesdk, perl do_install failed:
| rm: cannot remove 'tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/
5.40.0/image//usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/
usr/lib64/perl5/5.40.0/*/CORE/libperl.so': No such file or directory
R
We have patch 0016-handle-sysroot-support-for-nativesdk-gcc.patch to handle
sysroot support for nativesdk-gcc, and add %r target_relocatable_prefix
into spec file for nativesdk-gcc relocation. It was used for injected
paths SYSTEMLIBS_DIR
Due to the supported SDKMACHINE includes:
aarch64, i586,
The nativesdk multilib support required it to fix multilib headers
conflict
[ YOCTO #15722 ]
Signed-off-by: Hongxu Jia
---
meta/classes-recipe/multilib_header.bbclass | 5 -
1 file changed, 5 deletions(-)
diff --git a/meta/classes-recipe/multilib_header.bbclass
b/meta/classes-recipe/multi
While nativesdk support multilib, there are two dynamic loaders,
$OECORE_NATIVE_SYSROOT/lib64/ld-linux-x86-64.so.2
$OECORE_NATIVE_SYSROOT/lib/ld-linux.so.2
Search them with wildcard and call relocate_sdk.py separately
[ YOCTO #15722 ]
Signed-off-by: Hongxu Jia
---
meta/files/toolchain
On Tue, 2025-01-21 at 09:12 +0100, Jan Strater-Büddefeld via
lists.openembedded.org wrote:
> Fixes [YOCTO #15579]
>
> This commit removes the LD_LIBRARY_PATH wrapper around `cargo`.
> Setting the LD_LIBRARY_PATH causes many problems.
> Some build scripts will not run because the build scripts exe
Fixes [YOCTO #15579]
This commit removes the LD_LIBRARY_PATH wrapper around `cargo`.
Setting the LD_LIBRARY_PATH causes many problems.
Some build scripts will not run because the build scripts execute
binaries from the host system that are not compatible with the target
libraries.
Even a simple `c
64 matches
Mail list logo
