Hi,
On Wed, Nov 11, 2020 at 08:06:44AM +, Diego Santa Cruz via
lists.openembedded.org wrote:
> Hi all,
>
> It was brought to my attention that FreeType < 2.10.4 is affected by a buffer
> overflow with PNG bitmaps as per
> https://sourceforge.net/projects/freetype/files/freetype2/2.10.4/,
On Wed, 11 Nov 2020 at 08:06, Diego Santa Cruz via
lists.openembedded.org
wrote:
> Also, how should one report problems in the NVD database?
Email cpe_dictionary and explain the
situation, matching the CPE vendor/product to existing freetype CVEs
and including the version information.
Ross
> -Original Message-
> From: mikko.rap...@bmw.de
> Sent: 11 November 2020 10:06
> To: Diego Santa Cruz
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] FreeType CVE-2020-15999
>
> Hi,
>
> On Wed, Nov 11, 2020 at 08:06:44AM +, Diego Santa Cruz via
>
> -Original Message-
> From: Ross Burton
> Sent: 11 November 2020 11:46
> To: Diego Santa Cruz
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] FreeType CVE-2020-15999
>
> On Wed, 11 Nov 2020 at 08:06, Diego Santa Cruz via
> lists.openembedded.org
> wrote:
> >
powerpc 32bit Linux Kernel widely uses .stabs pseudo-op to
produce debugging information in stabs format. Faced an issue
that during Linux Kernel build with Yocto build system for 32bit
powerpc platform resulting vmlinux contains absolute path in
.stabstr section that cannot be remapped with
Hi all,
It was brought to my attention that FreeType < 2.10.4 is affected by a buffer
overflow with PNG bitmaps as per
https://sourceforge.net/projects/freetype/files/freetype2/2.10.4/,
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15999
This does not appear in the CVE metrics which
On Mon, 2020-11-02 at 19:18 +, luca.bocca...@gmail.com wrote:
> From: Luca Boccassi
>
> Certain config files and units are shared between dbus-daemon and
> dbus-broker (available in meta-openembedded), so split them out to
> allow installing dbus-broker without pulling in dbus-daemon and its
Please remember to build more than just a single recipe when testing,
in particular dependents. This upgrade broke libical and webkitgtk,
which resulted in three iterations though the autobuilder and me
finding/backporting fixes as appropriate.
Ross
On Mon, 9 Nov 2020 at 03:39, zangrc wrote:
>
On 11/10/20 10:10 PM, Saul Wold wrote:
This adds support for the Qemu Machine Protocol [0] extending
the current dump process for Host and Target. The commands are
added in the testimage.bbclass.
Currently, we setup qemu to stall until qmp gets connected and
sends the initialization and
On 11/10/20 10:10 PM, Saul Wold wrote:
This adds support for the Qemu Machine Protocol [0] extending
the current dump process for Host and Target. The commands are
added in the testimage.bbclass.
Currently, we setup qemu to stall until qmp gets connected and
sends the initialization and
Signed-off-by: Diego Santa Cruz
---
...-sfnt-Fix-heap-buffer-overflow-59308.patch | 51 +++
.../freetype/freetype_2.10.1.bb | 1 +
2 files changed, 52 insertions(+)
create mode 100644
Signed-off-by: Diego Santa Cruz
---
...-sfnt-Fix-heap-buffer-overflow-59308.patch | 51 +++
.../freetype/freetype_2.10.2.bb | 1 +
2 files changed, 52 insertions(+)
create mode 100644
This reverts commit 44010756b0ae91e0ac7715b7840285d59f991141.
With the packported patch from rt-tests
(67da9d8af7d8a0e1a0822e6ee99d68fa3d5a46d2)
that allows build for all archs this patch can be reverted. An error is dumped
in
run-time is frc() is not present.
Signed-off-by: Peter Bergin
---
As rt-tests has added frc() to oslat and frc() function is not present
on all architectures the rt-tests recipe was recently updated in commit
44010756b0ae91e0ac7715b7840285d59f991141 to avoid those.
rt-tests repo has a commit that makes another workaround for the issue.
With that commit the build
Upstream rt-tests has applied a patch that allow builds for all archs.
The problem is that oslat using frc() that is not present for all archs.
With this backported patch oslat is building but in run-time an error
message is dumped if frc() is not present.
Signed-off-by: Peter Bergin
---
Sorry, we will improve in the future, but we don’t know how to determine which
recipes need to be tested during the upgrade. Is there any way you can provide
us?
Zang Ruochen
> -Original Message-
> From: Ross Burton
> Sent: Wednesday, November 11, 2020 6:49 PM
> To: Zang, Ruochen/臧 若尘
On Wed, Nov 11, 2020 at 10:02 PM Changqing Li
wrote:
>
> fix error:
> | framework/lib/ppc/libframework.a(device.cpp.o): in function
> `std::__atomic_base::load(std::memory_order) const':
> | /usr/include/c++/10.2.0/bits/atomic_base.h:426: undefined reference to
> `__atomic_load_8'
>
>
On 11/11/20 6:45 PM, zangrc wrote:
> Sorry, we will improve in the future, but we don’t know how to determine
> which recipes need to be tested during the upgrade. Is there any way you can
> provide us?
>
one way would be to do bitbake -k world,
> Zang Ruochen
>
>> -Original
Please merge these changes in gatesgarth.
Thanks,
Anuj
The following changes since commit b1eb390bbcb995c0da70478e17f9170721c75341:
scripts/buildhistory_analysis: Avoid tracebacks from file comparision code
(2020-10-30 12:37:53 +)
are available in the Git repository at:
fix error:
| framework/lib/ppc/libframework.a(device.cpp.o): in function
`std::__atomic_base::load(std::memory_order) const':
| /usr/include/c++/10.2.0/bits/atomic_base.h:426: undefined reference to
`__atomic_load_8'
Signed-off-by: Changqing Li
---
Current code hardcodes archiver to be 'ar' from build host
Signed-off-by: Khem Raj
---
...mpilation-using-autoconf-detected-AR.patch | 36 +++
meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb | 1 +
2 files changed, 37 insertions(+)
create mode 100644
Hi all,
We've been upgrading our work to Dunfell and have encountered an issue with
python3-native.
One of our python3-native scripts uses pydoc and that in turn eventually
pulls in python's sysconfig. However, this is failing to import with the
following stack trace:
```
import pydoc
On Wed, Nov 11, 2020 at 2:15 PM Peter Bergin wrote:
>
> As rt-tests has added frc() to oslat and frc() function is not present
> on all architectures the rt-tests recipe was recently updated in commit
> 44010756b0ae91e0ac7715b7840285d59f991141 to avoid those.
> rt-tests repo has a commit that
Signed-off-by: Khem Raj
---
.../0001-Use-cross-AR-during-compile.patch| 35 +++
meta/recipes-extended/gawk/gawk_5.1.0.bb | 1 +
2 files changed, 36 insertions(+)
create mode 100644
meta/recipes-extended/gawk/gawk/0001-Use-cross-AR-during-compile.patch
diff --git
Bump... I just noticed this patch was never applied. I have been
carrying it locally all year and it still applies cleanly. Any issues
preventing it from being applied?
Excerpts from Dan Callaghan's message of 2020-01-21 11:24:12 +10:00:
> Similar to elfutils, when xz support is built into gdb
Hi Khem,
On 2020-11-12 02:33, Khem Raj wrote:
this seems to improve the situation but its not clear if arches
without frc() will now fail miserably at runtime or will it only fail
a subset of tests and rt-tests will still be largely useful for such
arches. In the latter case, I am fine with
26 matches
Mail list logo
