This breaks several recipes in meta-openembedded. here is subset from
meta-oe layer
https://valkyrie.yoctoproject.org/#/builders/81/builds/276
On Wed, Jan 8, 2025 at 12:42 AM Alexander Kanavin via
lists.openembedded.org
wrote:
>
> From: Alexander Kanavin
>
> Backport a kea patch to address 1.87.
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 by using TUNE_PKGARCH
Yes, probably by accident, now top 8 commits are gone from oe-core.
>From git://git.openembedded.org/openembedded-core
+ 4e29551b15...599e0fbf7d master -> git.oe.org/master (forced update)
On Fri, Jan 10, 2025 at 7:10 PM Ross Burton wrote:
>
> On 10 Jan 2025, at 17:52, Martin Jansa wrote
On 10 Jan 2025, at 17:52, Martin Jansa wrote:
>
> Too late to easily ignore as it seems already in master, e.g.:
> https://git.openembedded.org/openembedded-core/commit/?id=5e14a1b26cc77b35c3e36869021afae9455bb1a8
> or do you mean some other changes?
Eek.
They’re not in poky/master so I wonder
Every other architecture has the QEMU_EXTRAOPTIONS assignments in the
tune files, so move the PPC ones too.
Signed-off-by: Ross Burton
---
meta/classes-recipe/qemu.bbclass | 9 -
meta/conf/machine/include/powerpc/arch-powerpc64.inc | 1 +
meta/conf/machine/include/pow
From: Bruce Ashfield
Updating linux-yocto/6.12 to the latest korg -stable release that comprises
the following commits:
5996393469d9 Linux 6.12.9
10a641cad465 mptcp: don't always assume copied data in mptcp_cleanup_rbuf()
8353226fe3ca mptcp: fix recvbuffer adjust on sleeping rcvmsg
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,
which leads to err
The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH},
but this doesn't follow the pattern of all of the other tune-specific
variables in the machine configuration which is VARIABLE:tune-[name].
Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to
QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} fo
Too late to easily ignore as it seems already in master, e.g.:
https://git.openembedded.org/openembedded-core/commit/?id=5e14a1b26cc77b35c3e36869021afae9455bb1a8
or do you mean some other changes?
On Fri, Jan 10, 2025 at 6:36 PM Ross Burton via lists.openembedded.org
wrote:
>
> This series breaks
This series breaks under nativesdk, please ignore for now.
Ross
> On 10 Jan 2025, at 13:01, Ross Burton via lists.openembedded.org
> wrote:
>
> 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
From: Peter Marko
These were fixed in previous commits.
Signed-off-by: Peter Marko
---
meta/recipes-multimedia/gstreamer/gstreamer1.0_1.20.7.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.20.7.bb
b/meta/recipes-multimedia/gstre
Adds a variable that allows the group given permissions to access FAT
mounted file systems to be specified, instead of being hardcoded to
'disk'.
As a note, the usage of 'disk' as the mount group is not a very secure
default, since the disk user usually has read/write access to all block
devices i
The complexity of overriding files from the bbclass made the behavior at
times hard to follow and predict. This change replaces the default file with a
heredoc equivalent that creates a default file if the user does not provide
their
own version of run-ptest in the SRC_URI.
Signed-off-by: Derek S
Hi Madhu,
This patch should be submitted and merged to the master branch before
I can take it for the stable branches.\
Thanks,
Steve
On Thu, Jan 9, 2025 at 2:21 AM Madhu Marri via lists.openembedded.org
wrote:
>
> - To avoid false positives such as CVE-2000-0006, add the CVE_PRODUCT
> value w
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 by using TUNE_PKGARCH
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 by using TUNE_PKGARCH
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 by using TUNE_PKGARCH
Every other architecture has the QEMU_EXTRAOPTIONS assignments in the
tune files, so move the PPC ones too.
Signed-off-by: Ross Burton
---
meta/classes-recipe/qemu.bbclass | 9 -
meta/conf/machine/include/powerpc/arch-powerpc64.inc | 1 +
meta/conf/machine/include/pow
Note this has been superseded by the series I just sent.
Ross
> On 9 Jan 2025, at 18:11, Ross Burton via lists.openembedded.org
> wrote:
>
> Every other architecture has the QEMU_EXTRAOPTIONS assignments in the
> tune files, so move the PPC ones too.
>
> Leave the MACHINE_ARCH workarounds pre
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 by using TUNE_PKGARCH
The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH},
but this doesn't follow the pattern of all of the other tune-specific
variables in the machine configuration which is VARIABLE:tune-[name].
Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to
QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} fo
Hi,
On Fri, Jan 10, 2025 at 12:14:05PM +, Jing Hui Tham via
lists.yoctoproject.org wrote:
> Hi,
>
> You may refer to the wiki page for tests on HW. :
> https://wiki.yoctoproject.org/wiki/BSP_Test_Plan
>
> For single testresults.json file, you can use below command to merge both
> testre
On Fri, 2025-01-10 at 12:18 +, Ross Burton wrote:
> On 10 Jan 2025, at 10:30, Richard Purdie
> wrote:
> >
> > On Wed, 2025-01-08 at 15:46 +, Ross Burton via
> > lists.openembedded.org wrote:
> > > The upstream Makefiles tell autoconf to write the generated
> > > script to
> > > configure.
From: Divya Chellam
REXML is an XML toolkit for Ruby. The REXML gem before 3.3.9 has a ReDoS
vulnerability when it parses an XML that has many digits between &# and x...;
in a hex numeric character reference (&#x This does not happen with
Ruby 3.2 or later. Ruby 3.1 is the only affected maint
On 10 Jan 2025, at 10:30, Richard Purdie
wrote:
>
> On Wed, 2025-01-08 at 15:46 +, Ross Burton via lists.openembedded.org
> wrote:
>> The upstream Makefiles tell autoconf to write the generated script to
>> configure.sh instead of the idiomatic configure. We now remove all of
>> the Makefi
Hi all,
Intel and WR YP QA is planning for QA execution for YP build yocto-4.024.rc1.
We are planning to execute following tests for this cycle:
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
Runtime auto test for following platforms:
1. MinnowBoard Turbot - 32bit
Hi,
You may refer to the wiki page for tests on HW. :
https://wiki.yoctoproject.org/wiki/BSP_Test_Plan
For single testresults.json file, you can use below command to merge both
testresults to single testresult file.
$ resulttool merge
Regards,
Jing Hui
> -Original Message-
The tests package has many dependencies which don't BBCLASSEXTEND to native
well. Remove these as we're not interested in the tests in the native case
anyway.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/python/python3-psutil_6.1.1.bb | 1 +
1 file changed, 1 insertion(+)
diff --git
On Wed, 2025-01-08 at 15:46 +, Ross Burton via lists.openembedded.org wrote:
> The upstream Makefiles tell autoconf to write the generated script to
> configure.sh instead of the idiomatic configure. We now remove all of
> the Makefile rules that refer to configure.sh (makefile-no-rebuild.patc
Looking at the reopened CVEs in meta-oe, I can't understand why are some
reported.
$ grep -rI CVE-2023-33460 ./
./meta-oe/recipes-devtools/yajl/yajl/CVE-2023-33460.patch:CVE: CVE-2023-33460
./meta-oe/recipes-devtools/yajl/yajl_2.1.0.bb:
file://CVE-2023-33460.patch \
$ grep -rI CVE-2020
Or should we rather rename all those patches which violate current code?
What is then the meaning of CVE: tag within the patch if it's not used but it's
enforced?
We should probably remove cve_payload_tag handling from test_cve_tag_format...
Peter
> -Original Message-
> From: openembedd
On Wed, 2025-01-08 at 18:38 +, Derek Straka via lists.openembedded.org
wrote:
> The complexity of overriding files from the bbclass made the behavior at
> times hard to follow and predict. This change replaces the default file with a
> heredoc equivalent that creates a default file if the user
Hello,
This patch has caused a regression in detecting cve patches.
Master jumped by 32 CVEs after merging this commit.
These are for sure patched but it's not detected anymore.
See https://valkyrie.yocto.io/pub/non-release/patchmetrics/
(master should be identical to scarthgap/styhead except for
33 matches
Mail list logo
