Re: [OE-core] Failed to build zImage-initramfs

2019-10-12 Thread Khem Raj
On Sat, Oct 12, 2019 at 9:06 PM JH wrote: > > Hi Khem, > > On 10/13/19, Khem Raj wrote: > > On Sun, 2019-10-13 at 12:14 +1100, JH wrote: > >> Hi, > >> > >> Apologize if it is not right mailing list for helps, please advise > >> which mailing list I should go. > >> > >> I have been trying to

Re: [OE-core] Failed to build zImage-initramfs

2019-10-12 Thread JH
Hi Khem, On 10/13/19, Khem Raj wrote: > On Sun, 2019-10-13 at 12:14 +1100, JH wrote: >> Hi, >> >> Apologize if it is not right mailing list for helps, please advise >> which mailing list I should go. >> >> I have been trying to build zImage-initramfs, according to the >>

Re: [OE-core] Failed to build zImage-initramfs

2019-10-12 Thread Khem Raj
On Sun, 2019-10-13 at 12:14 +1100, JH wrote: > Hi, > > Apologize if it is not right mailing list for helps, please advise > which mailing list I should go. > > I have been trying to build zImage-initramfs, according to the > oe-core/meta/classes/kernel.bbclass, I defined following variables in >

Re: [OE-core] [PATCH 05/19] glib-2.0: upgrade to 2.62.1

2019-10-12 Thread Khem Raj
libmbim/qemuarm fails too with following error | ../../../libmbim-1.18.0/src/libmbim-glib/mbim-proxy.c: In function 'mbim_proxy_init': | ../../../libmbim-1.18.0/src/libmbim-glib/mbim-proxy.c:1446:13: error: G_ADD_PRIVATE [-Werror] | 1446 |

[OE-core] Failed to build zImage-initramfs

2019-10-12 Thread JH
Hi, Apologize if it is not right mailing list for helps, please advise which mailing list I should go. I have been trying to build zImage-initramfs, according to the oe-core/meta/classes/kernel.bbclass, I defined following variables in local.conf: INITRAMFS_IMAGE = "zImage-initramfs"

[OE-core] ✗ patchtest: failure for glib-2.0: Fix build with clang compiler

2019-10-12 Thread Patchwork
== Series Details == Series: glib-2.0: Fix build with clang compiler Revision: 1 URL : https://patchwork.openembedded.org/series/20448/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been

Re: [OE-core] [PATCH 05/19] glib-2.0: upgrade to 2.62.1

2019-10-12 Thread Khem Raj
On Fri, 2019-10-11 at 13:47 +0200, Alexander Kanavin wrote: > Drop backported 0001-meson-do-a-build-time-check-for-strlcpy-before- > attem.patch > and 0001-meson.build-do-not-hardcode-linux-as-the-host-system.patch > where > upstream has removed the problematic bit. > I have sent a patch to fix

[OE-core] [PATCH] glib-2.0: Fix build with clang compiler

2019-10-12 Thread Khem Raj
Signed-off-by: Khem Raj --- ...on-Run-atomics-test-on-clang-as-well.patch | 31 +++ meta/recipes-core/glib-2.0/glib-2.0_2.62.1.bb | 1 + 2 files changed, 32 insertions(+) create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/0001-meson-Run-atomics-test-on-clang-as-well.patch

Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0

2019-10-12 Thread Khem Raj
On Fri, 2019-10-11 at 13:47 +0200, Alexander Kanavin wrote: > Drop backported patches. > > Signed-off-by: Alexander Kanavin > --- > meta/recipes-devtools/meson/meson.inc | 7 +-- > ...efined-by-the-existance-of-a-cross-f.patch | 28 --- >

Re: [OE-core] [PATCH 05/19] glib-2.0: upgrade to 2.62.1

2019-10-12 Thread Khem Raj
some more aarch64/musl failures https://errors.yoctoproject.org/Errors/Details/273492/ https://errors.yoctoproject.org/Errors/Details/273494/ On Sat, Oct 12, 2019 at 1:59 PM Khem Raj wrote: > > Regresses, on riscv > > https://errors.yoctoproject.org/Errors/Details/273482/ > > On Fri, Oct 11,

Re: [OE-core] [PATCH v2 5/5] shim: add first-stage UEFI bootloader implementing MOK protocol

2019-10-12 Thread Khem Raj
fail on musl/clang/aarch64 https://errors.yoctoproject.org/Errors/Details/273493/ does it depend on gcc being system compiler ? On Sun, Sep 29, 2019 at 1:15 PM wrote: > > From: Dmitry Eremin-Solenikov > > Signed-off-by: Dmitry Eremin-Solenikov > --- >

Re: [OE-core] [warrior][PATCH] kernel.bbclass: fix installation of modules signing certificates

2019-10-12 Thread Dmitry Eremin-Solenikov
сб, 12 окт. 2019 г. в 19:57, akuster808 : > > > > On 10/11/19 1:16 AM, Nicolas Dechesne wrote: > > From: Dmitry Eremin-Solenikov > > > > If one has provided external key/certificate for modules signing, Kbuild > > will skip creating signing_key.pem and will write only signing_key.x509 > >

Re: [OE-core] [PATCH 05/19] glib-2.0: upgrade to 2.62.1

2019-10-12 Thread Khem Raj
Regresses, on riscv https://errors.yoctoproject.org/Errors/Details/273482/ On Fri, Oct 11, 2019 at 4:49 AM Alexander Kanavin wrote: > > Drop backported > 0001-meson-do-a-build-time-check-for-strlcpy-before-attem.patch > and 0001-meson.build-do-not-hardcode-linux-as-the-host-system.patch where

[OE-core] [PATCH] mesa: Upgrade to 19.2.1

2019-10-12 Thread Alistair Francis
Upgrade mesa and mesa-gl to 19.2.1. The license hash change was a trivial new line removal. The glx-tls option was removed as it isn't included in the meson.build file. The -Dasm=false was removed as it also is no longer included. Signed-off-by: Alistair Francis ---

Re: [OE-core] [thud][PATCH] kernel.bbclass: fix installation of modules signing certificates

2019-10-12 Thread akuster808
On 10/11/19 1:15 AM, Nicolas Dechesne wrote: > From: Dmitry Eremin-Solenikov > > If one has provided external key/certificate for modules signing, Kbuild > will skip creating signing_key.pem and will write only signing_key.x509 > certificate. Thus we have to check for .x509 file existence

Re: [OE-core] [warrior][PATCH] kernel.bbclass: fix installation of modules signing certificates

2019-10-12 Thread akuster808
On 10/11/19 1:16 AM, Nicolas Dechesne wrote: > From: Dmitry Eremin-Solenikov > > If one has provided external key/certificate for modules signing, Kbuild > will skip creating signing_key.pem and will write only signing_key.x509 > certificate. Thus we have to check for .x509 file existence

Re: [OE-core] [PATCH 1/2] core-image-sato-sdk-ptest: Remove valgrind ptests for riscv

2019-10-12 Thread Khem Raj
ping On Sat, 2019-09-28 at 16:16 -0700, Khem Raj wrote: > valgrind is not yet ported to riscv > > Signed-off-by: Khem Raj > --- > meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git

[OE-core] [PATCH] conf/image-uefi: fix building images for multilib case

2019-10-12 Thread dbaryshkov
From: Dmitry Eremin-Solenikov Building live images for lib32-core-minimal-image will fail because image target override won't match grub's override. Fix this by introducing anonymous python function. A proper fix should be to introduce multilib overrides, but it will be more intrusive.

[OE-core] ✗ patchtest: failure for YOCTO #12937 - Consistent naming scheme for deployed artifacts (rev3)

2019-10-12 Thread Patchwork
== Series Details == Series: YOCTO #12937 - Consistent naming scheme for deployed artifacts (rev3) Revision: 3 URL : https://patchwork.openembedded.org/series/19321/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response.

[OE-core] [PATCH][RESEND 0/6] YOCTO #12937 - Consistent naming scheme for deployed artifacts

2019-10-12 Thread Martin Jansa
Let me explain a bit what these changes do for us in LGE. We have jenkins jobs for CI as well for official releases. All built artifacts are moved from jenkins builder to fileserver after the build. Each jobs have some identifier which is then included in the filenames of all relevant build

[OE-core] [PATCH][RESEND 2/6] bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link

2019-10-12 Thread Martin Jansa
* just RFC, the part for images isn't finished yet and there is still some issue with DATETIME when kernel artifacts are used from sstate, this is just to validate the idea behind [YOCTO #12937] before finishing the implementation (it's already finished and used by various LGE builds, but

[OE-core] [PATCH][RESEND 3/6] kernel-artifact-names.bbclass: use PR instead of PKGR in KERNEL_ARTIFACT_NAME

2019-10-12 Thread Martin Jansa
* otherwise PKGR seen in do_install, do_deploy and do_deploy_links will have different value in each of them (PRSERV will return different value of EXTENDPRAUTO because TASKHASH is different for each of these tasks and also cause unnecessary multiple EXTENDPRAUTO increments for each

[OE-core] [PATCH][RESEND 6/6] *-artifact-names: include version only in the artifact links

2019-10-12 Thread Martin Jansa
* drop ${PKGE}-${PKGV}-${PR} from kernel artifacts names (this is the latest build) and add it only in hardlinks created in do_deploy_links so that we can use PKGR there again (because these links are generally used only by human operators and they don't have their own TASKHASH or the

[OE-core] [PATCH][RESEND 1/6] image-artifact-names: introduce new bbclass and move some variables into it

2019-10-12 Thread Martin Jansa
* similar to kernel-artifact-names for other recipes/bbclasses which need to use some deployed artifacts * bitbake.conf: move IMAGE_BASENAME, IMAGE_VERSION_SUFFIX, IMAGE_NAME, IMAGE_LINK_NAME variables * image_types.bbclass: move IMAGE_NAME_SUFFIX variable * currently IMAGE_NAME_SUFFIX is

[OE-core] [PATCH][RESEND 5/6] kernel.bbclass: drop unnecessary package_get_auto_pr for do_install

2019-10-12 Thread Martin Jansa
* do_install doesn't use whole "version" as do_deploy does, e.g. ${PKGE}-${PKGV}-${PKGR}-${MACHINE} it installs only the files with only ${KERNEL_VERSION} in filename or path, so it doesn't need expanded AUTOINC value in PKGV nor EXPANDPRAUTO in PKGR like do_deploy does * it was

[OE-core] [PATCH][RESEND 4/6] kernel.bbclass: imageType without {}

2019-10-12 Thread Martin Jansa
* just to make sure it looks like bash variable not bitbake variable in run.do_* scripts [YOCTO #12937] Signed-off-by: Martin Jansa --- meta/classes/kernel.bbclass | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/meta/classes/kernel.bbclass

Re: [OE-core] [PATCH] libxvmc:upgrade 1.0.11 -> 1.0.12

2019-10-12 Thread Richard Purdie
On Mon, 2019-10-07 at 14:00 +0800, Zang Ruochen wrote: > Signed-off-by: Zang Ruochen > --- > .../xorg-lib/{libxvmc_1.0.11.bb => > libxvmc_1.0.12.bb} | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > rename meta/recipes-graphics/xorg-lib/{libxvmc_1.0.11.bb => >

Re: [OE-core] [PATCH 10/19] gtk-doc: upgrade 1.31 -> 1.32

2019-10-12 Thread Adrian Bunk
On Fri, Oct 11, 2019 at 09:39:07PM +0200, Alexander Kanavin wrote: > On Fri, 11 Oct 2019 at 21:30, akuster808 wrote: > > > > --- a/meta/recipes-gnome/gtk-doc/files/pkg-config-native.patch > > > +++ b/meta/recipes-gnome/gtk-doc/files/pkg-config-native.patch > > > @@ -1,4 +1,4 @@ > > > -From

Re: [OE-core] [PATCH 00/23] Update BSD license

2019-10-12 Thread Richard Purdie
On Mon, 2019-10-07 at 13:08 +, Christophe PRIOUZEAU wrote: > Some recipes use BSD as license while SPDX license reference : BSD-0- > Clause, > BSD-1-Clause, BSD-2-Clause, BSD-3-Clause, BSD-4-Clause. > The goal of this request are to indicate the SPDX license euqivalent > for recipes > which