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 build
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
>> oe-core/meta/classes/kern
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
>
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
| MbimProxyPr
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"
INITRAMFS_I
== 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 execute
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 c
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
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 ---
> .../0001-Make-CPU-family-warnings-fatal.
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, 201
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
> ---
> ...ompareMem-on-MokListNode.Type-instea.p
сб, 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
> > certific
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
>
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
---
...llow-enable-DRI-without
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 rathe
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 rathe
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 a/meta/recipes-sato/images/core-image-sato-sdk-ptest.
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.
Signed-of
== 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. S
* 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 h
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 arti
* 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 build).
* 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 IMAGE
* 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 us
* 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 introduced
* 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 b/meta/classes/ker
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 =>
> libxvmc
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 9537a7
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 ind
29 matches
Mail list logo