On Mon, Apr 20, 2020 at 7:31 PM akuster wrote:
>
>
> On 4/20/20 2:58 AM, Zhixiong Chi wrote:
>
> Backport the CVE patch from upstream:
> git://sourceware.org/git/glibc.git
> commit d93769405996dfc11d216ddbe415946617b5a494
>
>
> Is Dunfell or Master affected ?
>
It’s already in glibc 2.31 iirc
Hi all,
Anyone has any inputs or suggestions for this patch that enable selftest for
IMAGE_GEN_DEBUGFS?
Thank you very much for your attention and help!
Best regards,
Yeoh Ee Peng
-Original Message-
From: Yeoh, Ee Peng
Sent: Wednesday, April 1, 2020 1:38 PM
To: openembedded-core@lists
On 4/20/20 2:58 AM, Zhixiong Chi wrote:
> Backport the CVE patch from upstream:
> git://sourceware.org/git/glibc.git
> commit d93769405996dfc11d216ddbe415946617b5a494
Is Dunfell or Master affected ?
- armin
>
> Signed-off-by: Zhixiong Chi
> ---
> .../glibc/glibc/CVE-2020-1751.patch
Hi Richard,
I found that I had missed the DISTRO_FEATURES_remove = "x11" configuration
during previous development and testing, I had successfully reproduce the issue
after incorporate the DISTRO_FEATURES_remove = "x11". I had tested the v03
patch and submitted the patch.
Sorry for my mistake.
v02:
- add retry checking for wayland processes up to 5 times, as
it took different amount of time to initialize wayland
compositor inside qemu created by host machine
v03:
- previous patch missed the DISTRO_FEATURES_remove = "x11"
configuration in the building of core-image-weston, wh
Existing weston test available make sure that a process
for weston-desktop-shell exist when image boot up.
Enhance weston tests by:
- execute weston-info to make sure weston interface(s)
are initialized
- execute weston and make sure it can initialize a
new wayland compositor (retry checki
OpenEmbedded Technical Steering Committee (TSC) Meeting Minutes 2020-04-20
==
Meeting was held in #oe-tsc on Freenode; channel access public.
Present:
- Richard Purdie (RP)
- Joshua Watt (JPEW)
- Bruce Ashfield (zeddii)
- Pau
Yocto bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10130
Move logic checking that all packages licenses are only a subset of
recipe licenses from base.bbclass to the insane.bbclass so that it's
evaluated only once, during do_package_qa.
As explained in the linked bugzilla entry, if a pa
On Mon, 2020-04-20 at 15:15 +, chris.lapla...@agilent.com wrote:
> > There is a non-hypothetical i386 loader, it already exists.
> > Unfortunately the loader has to be downloaded and extracted in
> > place
> > before anything gets run so it all happens very early. Its done
> > centrally with
>
> There is a non-hypothetical i386 loader, it already exists.
> Unfortunately the loader has to be downloaded and extracted in place
> before anything gets run so it all happens very early. Its done centrally with
> one uninative, not two or per recipe.
>
> I think you might be able to do somethin
On Sun, Apr 19, 2020 at 11:15:55PM +0100, Richard Purdie wrote:
> On Sun, 2020-04-19 at 21:58 +, Chris Laplante via
> lists.openembedded.org wrote:
> > One possible work around which I'm using for some prebuilt native
> > binaries is to call them with hosts loader (e.g. /lib32/ld-linux.so.2
>
On Mon, 2020-04-20 at 13:56 +, chris.lapla...@agilent.com wrote:
> > I suspect uninative assumes all binaries are for the main system
> > architecture
> > so its probably trying to change the interpreter to a 64 bit one
> > which clearly
> > won't work in this case.
> >
> > It would be a quest
> > I suspect uninative assumes all binaries are for the main system
> > architecture so its probably trying to change the interpreter to a 64
> > bit one which clearly won't work in this case.
> >
> > It would be a question of stopping it for these binaries somehow...
>
> Maybe a matter of doing
> I suspect uninative assumes all binaries are for the main system architecture
> so its probably trying to change the interpreter to a 64 bit one which clearly
> won't work in this case.
>
> It would be a question of stopping it for these binaries somehow...
Maybe a matter of doing something lik
On Wed, 15 Apr 2020 at 17:40, Andreas Müller wrote:
> > There's an argument to be made for validating the OS name is in that
> > list before returning it from meson_operating_system.
> ^ I read this several times - but am not sure if understand it
> correctly: Do you mean it is not correct/expect
Backport the CVE patch from upstream:
git://sourceware.org/git/glibc.git
commit d93769405996dfc11d216ddbe415946617b5a494
Signed-off-by: Zhixiong Chi
---
.../glibc/glibc/CVE-2020-1751.patch | 70 +++
meta/recipes-core/glibc/glibc_2.30.bb | 1 +
2 files changed,
Signed-off-by: Zheng Ruoqin
---
.../liburcu/{liburcu_0.11.1.bb => liburcu_0.12.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/liburcu/{liburcu_0.11.1.bb => liburcu_0.12.0.bb}
(83%)
diff --git a/meta/recipes-support/liburcu/liburcu_0.11.1.bb
0001-xdr_float-do-not-include-bits-endian.h.patch
removed since it is included in 1.2.6
Signed-off-by: Zheng Ruoqin
---
...r_float-do-not-include-bits-endian.h.patch | 34 ---
.../{libtirpc_1.2.5.bb => libtirpc_1.2.6.bb} | 8 ++---
2 files changed, 3 insertions(+), 39 deletions
Signed-off-by: Zheng Ruoqin
---
meta/recipes-core/ell/{ell_0.30.bb => ell_0.31.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-core/ell/{ell_0.30.bb => ell_0.31.bb} (83%)
diff --git a/meta/recipes-core/ell/ell_0.30.bb
b/meta/recipes-core/ell/ell_0.31.bb
simila
19 matches
Mail list logo
