From: Lee Chee Yang
Signed-off-by: Lee Chee Yang
---
v2: update qemu.inc, rebase on latest HEAD
(926eb08fe325e2ea13098f99d920840b9354ceb9)
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2020-24165.patch| 94 +++
2 files changed, 95
https://cryptography.io/en/latest/changelog/#v41-0-4
41.0.4 - 2023-09-19
Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3.
Signed-off-by: Tim Orling
---
All ptests pass on qemux86-64 core-image-ptest-python3-cryptography image
(with the caveat that on Ubuntu 22.04 I
On Thu, Sep 28, 2023 at 4:00 PM Tim Orling wrote:
>
>
>
> On Thu, Sep 28, 2023 at 3:55 PM Khem Raj wrote:
>>
>> On Thu, Sep 28, 2023 at 2:46 PM Tim Orling wrote:
>> >
>> >
>> >
>> > On Thu, Sep 28, 2023 at 1:34 PM Khem Raj wrote:
>> >>
>> >> Can you check if the machines where it fails has
llvm-17 support patch had redundant checks for llvm-17, Simplify them as
submitted in v3 upstream
Signed-off-by: Khem Raj
---
.../mesa/files/0001-gallium-Fix-build-with-llvm-17.patch | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
This issue is always there, it just shows up with newer LLVM since
symbol mismatches are being found otherwise it was happily linking with
host libLLVM.so silently.
Signed-off-by: Khem Raj
---
...e-cmake-dependency-detector-for-llvm.patch | 47 +++
On Thu, Sep 28, 2023 at 3:55 PM Khem Raj wrote:
> On Thu, Sep 28, 2023 at 2:46 PM Tim Orling wrote:
> >
> >
> >
> > On Thu, Sep 28, 2023 at 1:34 PM Khem Raj wrote:
> >>
> >> Can you check if the machines where it fails has llvm-14-dev package
> >> installed on host ?
> >>
> >
> > In my case,
On Thu, Sep 28, 2023 at 2:46 PM Tim Orling wrote:
>
>
>
> On Thu, Sep 28, 2023 at 1:34 PM Khem Raj wrote:
>>
>> Can you check if the machines where it fails has llvm-14-dev package
>> installed on host ?
>>
>
> In my case, yes. llvm-14-dev 1:14.0.0-1ubuntu1.1
yeah, this will expose the problem
Add a package QA check for when a package RRECOMMENDS another that won't
be built because it is empty and ALLOW_EMPTY is not set. This happens
usually when ${PN}-dev RRECOMMENDS ${PN} but ${PN} is empty. This is not
an error but might be something to look into.
Example of a generated warning:
This is the first step toward better handling of empty packages and bogus
dependencies (e.g. ${PN}-dev -> ${PN}, ${PN}, being empty).
See: https://lists.openembedded.org/g/openembedded-architecture/message/1701
> a) Add warnings for dependencies (RDEPENDS or RRECOMMENDS) on packages
> which don't
From: Fawzi KHABER
Remove superfluous DEV_PKG_DEPENDENCY = "" previously used to bypass
${PN}-dev package RDEPENDS on empty ${PN}. DEV_PKG_DEPENDENCY
applies RRECOMMENDS now, all workarounds are not needed anymore.
Related to [YOCTO #6839] and [YOCTO #8222]
Signed-off-by: Yoann CONGAL
On Thu, Sep 28, 2023 at 1:34 PM Khem Raj wrote:
> Can you check if the machines where it fails has llvm-14-dev package
> installed on host ?
>
>
In my case, yes. llvm-14-dev 1:14.0.0-1ubuntu1.1
> On Thu, Sep 28, 2023 at 9:55 AM Khem Raj wrote:
> >
> > its linking with
Can you check if the machines where it fails has llvm-14-dev package
installed on host ?
On Thu, Sep 28, 2023 at 9:55 AM Khem Raj wrote:
>
> its linking with /usr/lib/llvm-14/lib/libLLVM-14.so.1 which is not
> correct. Somehow its finding llvm library on your build host.
>
> On Thu, Sep 28,
As in other places, print a more helpful error if a SPDX document is not
found when assembling documents for the final SPDX archive.
Signed-off-by: Joshua Watt
---
meta/classes/create-spdx-2.2.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/create-spdx-2.2.bbclass
On Thu, 28 Sept 2023 at 18:49, Richard Purdie
wrote:
> I've wondered if we should split bitbake -S printdiff into a separate
> utility? It exists from a time before we had bitbake command APIs.
It can also be a simple shell wrapper.
I've separated -S lockedsigs into it's own option as well, so
its linking with /usr/lib/llvm-14/lib/libLLVM-14.so.1 which is not
correct. Somehow its finding llvm library on your build host.
On Thu, Sep 28, 2023 at 8:25 AM Richard Purdie
wrote:
>
> On Fri, 2023-09-22 at 09:37 -0700, Khem Raj wrote:
> > Signed-off-by: Khem Raj
> > ---
> >
On Thu, 2023-09-28 at 18:43 +0200, Alexander Kanavin wrote:
> On Fri, 22 Sept 2023 at 12:42, Richard Purdie
> wrote:
>
> > Things which used to be problematic:
> >
> > a) changes involving changes to gcc-source since it uses a shared
> > sources stamps which confused the tools (at least used
On Fri, 22 Sept 2023 at 12:42, Richard Purdie
wrote:
> Things which used to be problematic:
>
> a) changes involving changes to gcc-source since it uses a shared
> sources stamps which confused the tools (at least used to). That may
> have been before gcc-source became a recipe?
> b) changes to
On Fri, 2023-09-22 at 09:37 -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj
> ---
> .../0001-gallium-Fix-build-with-llvm-17.patch | 27 ---
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git
>
This seems like a good change (being able to easily run items built
with c/c++ tolchains in yocto SDKs is a problem no one has
satisfactorily resolved, and it's nice that rust got this right), but
can you expand the test in meta/lib/oeqa/sdk/cases/rust.py to cover
possible target options such as
Thanks, I suspect many of those were enabled to begin with when I
recently changed the packaging to include all the tests.
Alex
On Thu, 28 Sept 2023 at 03:57, Robert Joslyn via
lists.openembedded.org
wrote:
>
> From: Robert Joslyn
>
> Some tests can fail intermittently and upstream has marked
Avoid setting sdk-wide RUSTFLAGS as these flags only are valid when
building for target.
This will enable building for different targets with different
RUSTFLAGS.
Signed-off-by: Sean Nyekjaer
---
meta/recipes-devtools/rust/rust-cross-canadian.inc | 4 +++-
1 file changed, 3 insertions(+), 1
This will enable us to build and run rust programs on the sdk host.
% cargo run --target x86_64-oesdk-linux-gnu -vv
Fresh hello v0.1.0 (~/development/hello)
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running
22 matches
Mail list logo
