python3 fails to work with recent glibc versions on older hosts, giving
errors like:
Fatal Python error: getentropy() failed
Aborted
This breaks buildtools-tarball and hence eSDK. This patch backports the
changes to random.c from upstream that address the problem.
Signed-off-by: Richard Purdie
On Fri, 2017-01-20 at 16:15 -0600, Aníbal Limón wrote:
> Minor upgrade contains fixes from 2.7.0.
>
> Removed patches (already in upstream):
[...]
> diff --git a/meta/recipes-devtools/qemu/qemu_2.7.0.bb
> b/meta/recipes-devtools/qemu/qemu_2.7.1.bb
> similarity index 66%
> rename from meta/recipes
== Series Details ==
Series: python3: Add upstream random.c fixes for recent glibc
Revision: 1
URL : https://patchwork.openembedded.org/series/4891/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have
On Tue, Jan 17, 2017 at 2:47 PM, Burton, Ross wrote:
>
> On 12 January 2017 at 23:33, Saul Wold wrote:
>>
>> To enable glamor, we need to also enable both dri3 and xshmfence as
>> dependencies.
>
>
> Of course musl's lack of lazy loading bits xserver again:
>
> [ 8.655] (EE) Failed to load
>
1) Upgrade bash from 4.3.30 to 4.4
2) Delete 1 patche below, since they are integrated upstream.
fix-run-intl.patch
3) Modify 2 patches below to make it compatible with new version
fix-run-coproc-run-heredoc-run-execscript-run-test-f.patch
test-output.patch
4) Add 1 patche below to solve p
1) Upgrade busybox from 1.24.1 to 1.26.2
2) Delete 12 patches below, since they are integrated upstream.
busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch
busybox/0001-libiproute-handle-table-ids-larger-than-255.patch
busybox/0001-sed-fix-sed-n-flushes-pattern-spac
== Series Details ==
Series: bash: 4.3.30 -> 4.4
Revision: 1
URL : https://patchwork.openembedded.org/series/4892/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
ser
From: Yuanjie Huang
The multilib symbol links are created for gcc to locate libgcc files.
Its source path contains TARGET_SYS of multilib libgcc. However, a
multilib's TARGET_SYS is not generated correctly all the time now.
For example,
MACHINE = "qemumips64"
DEFAULTTUNE = "mips64-n32"
MUL
== Series Details ==
Series: libgcc-common.inc: Fix symbol link to mutilib directories
Revision: 1
URL : https://patchwork.openembedded.org/series/4894/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests
The multilib symbol links are created for gcc to locate libgcc files.
Its source path contains TARGET_SYS of multilib libgcc. However, a
multilib's TARGET_SYS is not generated correctly all the time now.
For example,
MACHINE = "qemumips64"
DEFAULTTUNE = "mips64-n32"
MULTILIBS = "multilib:lib
On Fri, 2017-01-20 at 15:12 +0100, Patrick Ohly wrote:
> The traditional usage of ovmf via the qemu bios parameter is no longer
> supported
I don't see dropping support for this option in this series. Is part of
another series? I just checked the poky repo and I still the the option
supported. Or
On Fri, 2017-01-20 at 15:12 +0100, Patrick Ohly wrote:
> There seems to be a consensus that supporting UEFI in OE-core for qemu
> would be valuable, and there have been some (stalled) attempts to add
> it. For reference, see:
>[OE-core] [PATCH V3 0/3] Add UEFI firmware for qemux86*
>[OE-cor
On Sun, 2017-01-22 at 23:23 -0800, Ricardo Neri wrote:
> On Fri, 2017-01-20 at 15:12 +0100, Patrick Ohly wrote:
> > The traditional usage of ovmf via the qemu bios parameter is no longer
> > supported
>
> I don't see dropping support for this option in this series.
>
> Is part of
> another series
13 matches
Mail list logo
