On Thu, Dec 2, 2021 at 1:21 AM Alexander Kanavin wrote:
>
> From: Alexander Kanavin
>
> This adds a smoke check for whether the Go toolchain actually
> produces working executables across a range of architectures.
I'm getting a failure during autobuilder testing (qemuarm64-ptest):
DEBUG:
RPI4 based on BCM2711 soc which does not enable AES extentions
in hardware see [1] fixes [2]
[1] https://forums.raspberrypi.com/viewtopic.php?t=207888=25#p1642862
[2] https://github.com/agherzan/meta-raspberrypi/issues/964
[YOCTO #14641]
Signed-off-by: Khem Raj
---
> -Original Message-
> From: openembedded-core@lists.openembedded.org
> On Behalf Of Khem Raj
> Sent: den 2 december 2021 21:21
> To: openembedded-core@lists.openembedded.org
> Cc: Khem Raj
> Subject: [OE-core] [PATCH] tune-cortexa72.inc: Add tune for nocrypto case
>
> RPI4 based on
On Thu, Dec 2, 2021 at 1:32 PM Peter Kjellerstedt
wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org
> > On Behalf Of Khem Raj
> > Sent: den 2 december 2021 21:21
> > To: openembedded-core@lists.openembedded.org
> > Cc: Khem Raj
> > Subject: [OE-core]
changelog:
1f8c8b88 Revert port of GL_EXT_shader_realtime_clock to GL_EXT_spirv_intrinsics
Signed-off-by: Jose Quaresma
---
.../glslang/{glslang_11.7.0.bb => glslang_11.7.1.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename
Signed-off-by: Jose Quaresma
---
meta/classes/sstate.bbclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 5e404d7cd8..9efd334a59 100644
--- a/meta/classes/sstate.bbclass
+++
This improves the time needed to check the mirrors,
reducing it from 50s to 8s when building the core-image-minimal
using the yocto upstream sstate and hashequivlance servers
on a machine with 8 cpu cores.
Tested with:
SSTATE_MIRRORS = "file://.*
Reminder
There will be an OpenEmbedded Developer Virtual Meeting (OEDVM) held
tomorrow (Friday, 03 December 2021)
The scheduled time will match the YP Summit's start at 12 UTC/7AM
Eastern, and run until 20 UTC/3PM (or earlier if we run out of topics,
but then will most likely turn into a happy
I've not looked at that series yet (the Summit is eating time) but if
it does the same logic then yes.
Ross
On Thu, 2 Dec 2021 at 17:31, Konrad Weihmann wrote:
>
>
>
> On 02.12.21 18:17, Ross Burton wrote:
> > distutils3_do_install wants to sed out build directory references from
> > all
After some discussion with Richard on #yocto irc we've decided to drop the patch
status updates from this series.
The following changes since commit 44b1970c40e9d73f6e63fb10cdc55837a26f5921:
build-appliance-image: Update to dunfell head revision (2021-11-15 15:00:44
+)
are available in
On Wed, Dec 1, 2021 at 8:14 AM Quentin Schulz
wrote:
>
> In addition to not being an SPDX license, Unicode license also isn't
> available in any of the LICENSE_PATH available in openembedded, meaning
> the following warning is printed:
>
> python3-idna: No generic license file exists for: Unicode
On Wed, 2021-12-01 at 20:20 +, Mike Crowe via lists.openembedded.org wrote:
> On Wednesday 01 December 2021 at 14:18:19 -0500, Justin Bronder wrote:
> > On 01/12/21 16:43 +, Mike Crowe via lists.openembedded.org wrote:
> > > I'm building for a specific chip and therefore don't wish to
distutils3_do_install wants to sed out build directory references from
all binaries in ${bindir} and ${sbindir}. It tries to avoid touching
symlinks by doing 'test -f' on the files as it iterates, but test always
dereferences symlinks so this will touch both real files and symlinks to
real files.
On 12/2/21 12:09, Richard Purdie wrote:
> On Thu, 2021-12-02 at 12:03 +0100, Jacob Kroon wrote:
>> On 12/2/21 11:51, Richard Purdie wrote:
>>> On Thu, 2021-12-02 at 11:19 +0100, Jacob Kroon wrote:
On 12/2/21 00:11, Richard Purdie wrote:
> On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon
I think the Unicode should be clear, as the tool (in)directly uses
downloads from unicode, but kindly ignores the licensing part of that
operation.
Looking into the history of that lib I found
https://github.com/kjd/idna/commit/dd8841d50fd506a0b4986542c21fff32ba1779d1,
which explains the
1.6.0+ has rv64 supports now.
Signed-off-by: Khem Raj
---
meta/recipes-support/libunwind/libunwind_1.6.0.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-support/libunwind/libunwind_1.6.0.bb
b/meta/recipes-support/libunwind/libunwind_1.6.0.bb
index 81b364fc5ef..91189fdb71c
Hi Alex,
It's not a case of simply deleting the so files we don't need since the
mesa build system stuffs everything into a small number of files and then
hard links them together. For example, the current unmodified oe-core build
for qemux86-64 yields:
$ ls -l
On 02.12.21 18:17, Ross Burton wrote:
distutils3_do_install wants to sed out build directory references from
all binaries in ${bindir} and ${sbindir}. It tries to avoid touching
symlinks by doing 'test -f' on the files as it iterates, but test always
dereferences symlinks so this will touch
libunwind now supports risc64
Signed-off-by: Khem Raj
---
meta/recipes-kernel/perf/perf.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index f473272096f..7bbc1ad70c5 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++
On Thu, 2021-12-02 at 22:05 +, Jose Quaresma wrote:
> This improves the time needed to check the mirrors,
> reducing it from 50s to 8s when building the core-image-minimal
> using the yocto upstream sstate and hashequivlance servers
> on a machine with 8 cpu cores.
>
> Tested with:
>
>
See [1]
[1] https://github.com/YoeDistro/yoe-distro/issues/626
Signed-off-by: Khem Raj
Cc: Ross Burton
---
...ormat-Check-for-NEON-before-using-it.patch | 49 +++
meta/recipes-graphics/mesa/mesa.inc | 1 +
2 files changed, 50 insertions(+)
create mode 100644
If ar input params starts with @, it means to read options from file
$ ar -h
...
@ - read options from
...
It failed to call ar wrapper to read options from file:
$ path_to/oe-core/scripts/native-intercept/ar
@bazel-out/k8-opt/bin/external/llvm-project/llvm/libSupport.a-2.params
On 12/2/21 4:49 PM, Jacob Kroon wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On 12/2/21 09:37, Hongxu Jia wrote:
>> If ar input params starts with @, it means to read options from file
>> $ ar -h
>> ...
>>@ - read options from
>> ...
>>
>> It failed to call
On 12/2/21 09:37, Hongxu Jia wrote:
> If ar input params starts with @, it means to read options from file
> $ ar -h
> ...
> @ - read options from
> ...
>
> It failed to call ar wrapper to read options from file:
> $ path_to/oe-core/scripts/native-intercept/ar
>
From: Ranjitsinh Rathod
Add patch to fix CVE-2021-39537
Link:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/ncurses/patches/Attic/patch-ncurses_tinfo_captoinfo.c?rev=1.1=text/x-cvsweb-markup
Signed-off-by: Ranjitsinh Rathod
Signed-off-by: Ranjitsinh Rathod
---
From: Ranjitsinh Rathod
It seems like CVE-2021-33928, CVE-2021-33929, CVE-2021-33930 and
CVE-2021-33938 are pointing to same patch as CVE-2021-3200
So add CVE tag inside the patch file which is the remedy for
CVE-2021-33928, CVE-2021-33929, CVE-2021-33930 and CVE-2021-33938
Link:
On 12/2/21 00:11, Richard Purdie wrote:
> On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
>> Try to make sure that the RUNTIME dynamic entry size is the same for all
>> binaries produced with the native compiler. This is necessary in order to
>> produce identical binaries when using
From: Ranjitsinh Rathod
Add patch to fix CVE-2021-43618
Link: https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e
Signed-off-by: Ranjitsinh Rathod
Signed-off-by: Ranjitsinh Rathod
---
.../gmp/gmp/CVE-2021-43618.patch | 29 +++
meta/recipes-support/gmp/gmp_6.2.0.bb
On 12/2/21 11:51, Richard Purdie wrote:
> On Thu, 2021-12-02 at 11:19 +0100, Jacob Kroon wrote:
>> On 12/2/21 00:11, Richard Purdie wrote:
>>> On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
Try to make sure that the RUNTIME dynamic entry size is the same for all
binaries produced
On Thu, 2021-12-02 at 12:03 +0100, Jacob Kroon wrote:
> On 12/2/21 11:51, Richard Purdie wrote:
> > On Thu, 2021-12-02 at 11:19 +0100, Jacob Kroon wrote:
> > > On 12/2/21 00:11, Richard Purdie wrote:
> > > > On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
> > > > > Try to make sure that the
From: Alexander Kanavin
This adds a smoke check for whether the Go toolchain actually
produces working executables across a range of architectures.
(From OE-Core rev: 2819bb2cf22c6cfcaeaee79f0280097ec9cb9327)
Signed-off-by: Alexander Kanavin
Signed-off-by: Richard Purdie
---
On Thu, 2021-12-02 at 11:19 +0100, Jacob Kroon wrote:
> On 12/2/21 00:11, Richard Purdie wrote:
> > On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
> > > Try to make sure that the RUNTIME dynamic entry size is the same for all
> > > binaries produced with the native compiler. This is
On Thu, Dec 2, 2021 at 2:23 AM Kevin Hao wrote:
>
> On Wed, Dec 01, 2021 at 04:27:44PM -0500, Bruce Ashfield wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > On Wed, Dec 1, 2021 at 6:28 AM Richard Purdie
> > wrote:
> > >
> > > On Wed, 2021-12-01 at 12:39 +0800,
On Thu, Dec 02, 2021 at 07:31:52AM -0500, Bruce Ashfield wrote:
> > That would be great if you can do so.
>
> ok. Let's solve this with an explicit KBRANCH with your pinned SRCREVs
> for now, and I'll update -dev to use versioned branches for the current
> 5.16 cycle and all new versions that
Cc'ing licens...@lists.yoctoproject.org to hopefully get knowledgeable
people on the topic?
Thanks,
Quentin
On Wed, Dec 01, 2021 at 06:30:39PM +0100, Konrad Weihmann wrote:
>
>
> On 01.12.21 18:20, Quentin Schulz wrote:
> > Hi Konrad,
> >
> > On Wed, Dec 01, 2021 at 06:04:36PM +0100, Konrad
35 matches
Mail list logo
