Re: [OE-core] [PATCH] systemd: fix CVE-2019-6454
On Sat, 2019-02-23 at 16:08 -0800, akuster808 wrote: > George, > > On 2/22/19 9:22 AM, George McCollister wrote: > > I missed that some how. > > > > Thanks for correcting me. > > thanks for the patch. it should apply to Thud so it wont go to waste. I was thinking of applying it to master until we get the upgrade which helps with the backporting... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: fix CVE-2019-6454
George, On 2/22/19 9:22 AM, George McCollister wrote: > I missed that some how. > > Thanks for correcting me. thanks for the patch. it should apply to Thud so it wont go to waste. - armin > -George > > On Fri, Feb 22, 2019 at 11:18 AM Alexander Kanavin > wrote: >> On Fri, 22 Feb 2019 at 18:13, George McCollister >> wrote: >>> I believe this was discussed before and the recommendation was to wait >>> until 241 to be release. In any case I currently have no interest in >>> upgrading it. My main motivation is to patch this CVE in sumo but >>> maintainers seem to want it in master first (even though different >>> version of the patches are required). >> 241 has been released: >> https://github.com/systemd/systemd/releases >> >> It's fine if you don't want to do the upgrade, just wanted to correct >> that point. >> >> Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/12] virglrenderer: add a recipe
On Fri, Feb 22, 2019 at 08:11:27PM +0100, Alexander Kanavin wrote: > Probably this is the very first time virgl is built for mips :-) >... Builds fine in Debian: https://buildd.debian.org/status/package.php?p=virglrenderer > Alex cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/12] virglrenderer: add a recipe
On Sat, 2019-02-23 at 11:57 -0800, Khem Raj wrote: > On Sat, Feb 23, 2019 at 10:07 AM Richard Purdie > wrote: > > On Sat, 2019-02-23 at 09:56 -0800, Khem Raj wrote: > > > On Fri, Feb 22, 2019 at 11:11 AM Alexander Kanavin > > > wrote: > > > > Probably this is the very first time virgl is built for mips :- > > > > ) > > > > > > > > Note that it is useful only if you intend to run qemu on that > > > > platform, so I wonder if we could just blacklist it... > > > > > > > > > > I would have thought world build should have caught it on AB for > > > mips. > > > Which tells me it could be > > > musl+mips specific > > > > The AB does not run world builds for everything. It does them for > > musl+ > > qemux86, musl+qemux86-64, qemux86, qemux86-lsb and no-x11 if I > > recall > > correctly. > > Thats right, I meant to say mips/glibc world builds, I think they are > run regularly and should have caught it if it was mips specific and > musl builds should have caught it if it was musl specific, so its > probably a combination musl+mips which causes this My list above doesn't include mips world, I don't think we test that. We come close with some of our big images but I don't think we test world. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] arch-armv8a.inc: Add missing BASE_LIB tune overrides
For multilib to work correctly, BASE_LIB overrides must be provided for
each new tune added in this file.
Signed-off-by: Mike Crowe
---
meta/conf/machine/include/arm/arch-armv8a.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
b/meta/conf/machine/include/arm/arch-armv8a.inc
index 323d0d7f0f..22064559be 100644
--- a/meta/conf/machine/include/arm/arch-armv8a.inc
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -26,3 +26,7 @@ PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a
simd"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
+BASE_LIB_tune-armv8a = "lib64"
+BASE_LIB_tune-armv8a-crc = "lib64"
+BASE_LIB_tune-armv8a-crypto= "lib64"
+BASE_LIB_tune-armv8a-crc-crypto= "lib64"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] arch-armv8a.inc: add tune include for armv8
On Sat, Feb 23, 2019 at 11:37 AM Mike Crowe wrote:
>
> On Monday 04 February 2019 at 18:57:22 -0800, Khem Raj wrote:
> > From: ayaka
> >
> > There are some addtional instructions apart from bare armv8,
> > also there is armv8.1, armv8.2.
> >
> > Most the processor would support crc, except X-gene 1.
> >
> > Signed-off-by: Randy Li
> > Signed-off-by: Khem Raj
> > ---
> > meta/conf/machine/include/arm/arch-armv8.inc | 1 -
> > meta/conf/machine/include/arm/arch-armv8a.inc | 28 +++
> > 2 files changed, 28 insertions(+), 1 deletion(-)
> > delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc
> > create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
> >
> > diff --git a/meta/conf/machine/include/arm/arch-armv8.inc
> > b/meta/conf/machine/include/arm/arch-armv8.inc
> > deleted file mode 100644
> > index 5e832fae6d..00
> > --- a/meta/conf/machine/include/arm/arch-armv8.inc
> > +++ /dev/null
> > @@ -1 +0,0 @@
> > -require conf/machine/include/arm/arch-arm64.inc
> > diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
> > b/meta/conf/machine/include/arm/arch-armv8a.inc
> > new file mode 100644
> > index 00..323d0d7f0f
> > --- /dev/null
> > +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
> > @@ -0,0 +1,28 @@
> > +DEFAULTTUNE ?= "armv8a-crc"
> > +
> > +TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
> > +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', '
> > -march=armv8-a', '', d)}"
> > +TUNEVALID[simd] = "Enable instructions for ARMv8-a Advanced SIMD and
> > floating-point"
> > +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '',
> > d)}"
> > +TUNEVALID[crc] = "Enable instructions for ARMv8-a Cyclic Redundancy Check
> > (CRC)"
> > +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '+crc', '',
> > d)}"
> > +TUNEVALID[crypto] = "Enable instructions for ARMv8-a cryptographic"
> > +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto',
> > '', d)}"
> > +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8a',
> > 'armv8a:', '' ,d)}"
> > +
> > +require conf/machine/include/arm/arch-arm64.inc
> > +
> > +# Little Endian base configs
> > +AVAILTUNES += "armv8a armv8a-crc armv8a-crc-crypto armv8a-crypto"
> > +ARMPKGARCH_tune-armv8a?= "armv8a"
> > +ARMPKGARCH_tune-armv8a-crc?= "armv8a"
> > +ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
> > +ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"
> > +TUNE_FEATURES_tune-armv8a = "aarch64 armv8a simd"
> > +TUNE_FEATURES_tune-armv8a-crc = "${TUNE_FEATURES_tune-armv8a}
> > crc"
> > +TUNE_FEATURES_tune-armv8a-crypto = "${TUNE_FEATURES_tune-armv8a}
> > crypto"
> > +TUNE_FEATURES_tune-armv8a-crc-crypto =
> > "${TUNE_FEATURES_tune-armv8a-crc} crypto"
> > +PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
> > +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc=
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
> > +PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto =
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
> > +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto =
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
> > --
> > 2.20.1
>
> I believe that this change, along with
> 6719de403620dded075dc74f2976669d95bffd7a, may have broken multilib for
> AArch64. :(
>
> When I enable multilib in local.conf with:
>
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
>
> then both the primary target and lib32- packages end up installing stuff
> into /usr/lib (and would presumably conflict, if I got as far as installing
> them.)
>
> If I revert 6719de403620dded075dc74f2976669d95bffd7a and
> d1db78b0e284e1a1f370e71183ded0cbdc1475db then the primary target packages
> end up installing stuff in /usr/lib64 as would be expected.
>
> This appears to be because baselib = "lib" rather than "lib64". That in
> turn may be because BASE_LIB_tune-armv8a-crc does not exist.
>
> If I apply this patch:
>
> diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
> b/meta/conf/machine/include/arm/arch-armv8a.inc
> index 323d0d7f0f..649deca61b 100644
> --- a/meta/conf/machine/include/arm/arch-armv8a.inc
> +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
> @@ -26,3 +26,4 @@ PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64
> armv8a simd"
> PACKAGE_EXTRA_ARCHS_tune-armv8a-crc=
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
> PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
> PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
> +BASE_LIB_tune-armv8a-crc = "lib64"
>
> then multilib behaves as it did before. Is this the correct fix?
it is in right direction, while you are at it also add it for other armv8 tunes
BASE_LIB_tune-armv8a= "lib64"
BASE_LIB_tune-armv8a-crc
Re: [OE-core] [PATCH 01/12] virglrenderer: add a recipe
On Sat, Feb 23, 2019 at 10:07 AM Richard Purdie wrote: > > On Sat, 2019-02-23 at 09:56 -0800, Khem Raj wrote: > > On Fri, Feb 22, 2019 at 11:11 AM Alexander Kanavin > > wrote: > > > Probably this is the very first time virgl is built for mips :-) > > > > > > Note that it is useful only if you intend to run qemu on that > > > platform, so I wonder if we could just blacklist it... > > > > > > > I would have thought world build should have caught it on AB for > > mips. > > Which tells me it could be > > musl+mips specific > > The AB does not run world builds for everything. It does them for musl+ > qemux86, musl+qemux86-64, qemux86, qemux86-lsb and no-x11 if I recall > correctly. Thats right, I meant to say mips/glibc world builds, I think they are run regularly and should have caught it if it was mips specific and musl builds should have caught it if it was musl specific, so its probably a combination musl+mips which causes this > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] arch-armv8a.inc: add tune include for armv8
On Monday 04 February 2019 at 18:57:22 -0800, Khem Raj wrote:
> From: ayaka
>
> There are some addtional instructions apart from bare armv8,
> also there is armv8.1, armv8.2.
>
> Most the processor would support crc, except X-gene 1.
>
> Signed-off-by: Randy Li
> Signed-off-by: Khem Raj
> ---
> meta/conf/machine/include/arm/arch-armv8.inc | 1 -
> meta/conf/machine/include/arm/arch-armv8a.inc | 28 +++
> 2 files changed, 28 insertions(+), 1 deletion(-)
> delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc
> create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
>
> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc
> b/meta/conf/machine/include/arm/arch-armv8.inc
> deleted file mode 100644
> index 5e832fae6d..00
> --- a/meta/conf/machine/include/arm/arch-armv8.inc
> +++ /dev/null
> @@ -1 +0,0 @@
> -require conf/machine/include/arm/arch-arm64.inc
> diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
> b/meta/conf/machine/include/arm/arch-armv8a.inc
> new file mode 100644
> index 00..323d0d7f0f
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
> @@ -0,0 +1,28 @@
> +DEFAULTTUNE ?= "armv8a-crc"
> +
> +TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', '
> -march=armv8-a', '', d)}"
> +TUNEVALID[simd] = "Enable instructions for ARMv8-a Advanced SIMD and
> floating-point"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '',
> d)}"
> +TUNEVALID[crc] = "Enable instructions for ARMv8-a Cyclic Redundancy Check
> (CRC)"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '+crc', '', d)}"
> +TUNEVALID[crypto] = "Enable instructions for ARMv8-a cryptographic"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto',
> '', d)}"
> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8a',
> 'armv8a:', '' ,d)}"
> +
> +require conf/machine/include/arm/arch-arm64.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv8a armv8a-crc armv8a-crc-crypto armv8a-crypto"
> +ARMPKGARCH_tune-armv8a?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crc?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"
> +TUNE_FEATURES_tune-armv8a = "aarch64 armv8a simd"
> +TUNE_FEATURES_tune-armv8a-crc = "${TUNE_FEATURES_tune-armv8a}
> crc"
> +TUNE_FEATURES_tune-armv8a-crypto = "${TUNE_FEATURES_tune-armv8a}
> crypto"
> +TUNE_FEATURES_tune-armv8a-crc-crypto =
> "${TUNE_FEATURES_tune-armv8a-crc} crypto"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc=
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
> --
> 2.20.1
I believe that this change, along with
6719de403620dded075dc74f2976669d95bffd7a, may have broken multilib for
AArch64. :(
When I enable multilib in local.conf with:
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
then both the primary target and lib32- packages end up installing stuff
into /usr/lib (and would presumably conflict, if I got as far as installing
them.)
If I revert 6719de403620dded075dc74f2976669d95bffd7a and
d1db78b0e284e1a1f370e71183ded0cbdc1475db then the primary target packages
end up installing stuff in /usr/lib64 as would be expected.
This appears to be because baselib = "lib" rather than "lib64". That in
turn may be because BASE_LIB_tune-armv8a-crc does not exist.
If I apply this patch:
diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
b/meta/conf/machine/include/arm/arch-armv8a.inc
index 323d0d7f0f..649deca61b 100644
--- a/meta/conf/machine/include/arm/arch-armv8a.inc
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -26,3 +26,4 @@ PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a
simd"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
+BASE_LIB_tune-armv8a-crc = "lib64"
then multilib behaves as it did before. Is this the correct fix?
Thanks.
Mike.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/12] virglrenderer: add a recipe
On Sat, 2019-02-23 at 09:56 -0800, Khem Raj wrote: > On Fri, Feb 22, 2019 at 11:11 AM Alexander Kanavin > wrote: > > Probably this is the very first time virgl is built for mips :-) > > > > Note that it is useful only if you intend to run qemu on that > > platform, so I wonder if we could just blacklist it... > > > > I would have thought world build should have caught it on AB for > mips. > Which tells me it could be > musl+mips specific The AB does not run world builds for everything. It does them for musl+ qemux86, musl+qemux86-64, qemux86, qemux86-lsb and no-x11 if I recall correctly. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/12] virglrenderer: add a recipe
On Fri, Feb 22, 2019 at 11:11 AM Alexander Kanavin wrote: > > Probably this is the very first time virgl is built for mips :-) > > Note that it is useful only if you intend to run qemu on that > platform, so I wonder if we could just blacklist it... > I would have thought world build should have caught it on AB for mips. Which tells me it could be musl+mips specific > Alex > > On Fri, 22 Feb 2019 at 19:54, Khem Raj wrote: > > > > https://errors.yoctoproject.org/Errors/Details/229902/ > > > > mips/glibc > > > > On Fri, Feb 22, 2019 at 6:34 AM Alexander Kanavin > > wrote: > > > > > > This component enables hardware-accelerated GL inside QEMU guests. > > > For more information, see here: > > > > > > https://lwn.net/Articles/767970/ > > > https://www.collabora.com/news-and-blog/blog/2018/02/12/virtualizing-gpu-access/ > > > https://www.collabora.com/news-and-blog/blog/2018/05/09/gpu-virtualization-update/ > > > > > > Signed-off-by: Alexander Kanavin > > > --- > > > meta/conf/distro/include/maintainers.inc | 1 + > > > ...efile.am-explicitly-link-with-libdrm.patch | 31 +++ > > > .../0001-vtest-add-missing-includes.patch | 38 +++ > > > .../virglrenderer/virglrenderer_0.7.0.bb | 19 ++ > > > 4 files changed, 89 insertions(+) > > > create mode 100644 > > > meta/recipes-graphics/virglrenderer/virglrenderer/0001-Makefile.am-explicitly-link-with-libdrm.patch > > > create mode 100644 > > > meta/recipes-graphics/virglrenderer/virglrenderer/0001-vtest-add-missing-includes.patch > > > create mode 100644 > > > meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb > > > > > > diff --git a/meta/conf/distro/include/maintainers.inc > > > b/meta/conf/distro/include/maintainers.inc > > > index 4e3fc103afc..f5e6343904b 100644 > > > --- a/meta/conf/distro/include/maintainers.inc > > > +++ b/meta/conf/distro/include/maintainers.inc > > > @@ -700,6 +700,7 @@ RECIPE_MAINTAINER_pn-util-macros = "Armin Kuster > > > " > > > RECIPE_MAINTAINER_pn-v86d = "Alexander Kanavin " > > > RECIPE_MAINTAINER_pn-vala = "Alexander Kanavin " > > > RECIPE_MAINTAINER_pn-valgrind = "Alexander Kanavin > > > " > > > +RECIPE_MAINTAINER_pn-virglrenderer = "Alexander Kanavin > > > " > > > RECIPE_MAINTAINER_pn-volatile-binds = "Chen Qi " > > > RECIPE_MAINTAINER_pn-vte = "Anuj Mittal " > > > RECIPE_MAINTAINER_pn-vulkan = "Ross Burton " > > > diff --git > > > a/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Makefile.am-explicitly-link-with-libdrm.patch > > > > > > b/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Makefile.am-explicitly-link-with-libdrm.patch > > > new file mode 100644 > > > index 000..aa8d814845e > > > --- /dev/null > > > +++ > > > b/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Makefile.am-explicitly-link-with-libdrm.patch > > > @@ -0,0 +1,31 @@ > > > +From d61f7073b8ce159d21811b291c22b273b040c330 Mon Sep 17 00:00:00 2001 > > > +From: Alexander Kanavin > > > +Date: Tue, 12 Feb 2019 12:04:52 +0100 > > > +Subject: [PATCH] Makefile.am: explicitly link with libdrm > > > + > > > +Otherwise, a failure happens with gold linker: > > > + > > > +../src/.libs/libvirglrenderer.so: error: undefined reference to > > > 'drmPrimeHandleToFD' > > > + > > > +https://errors.yoctoproject.org/Errors/Details/222046/ > > > + > > > +Upstream-Status: Accepted > > > [https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/153] > > > +Signed-off-by: Alexander Kanavin > > > +--- > > > + src/Makefile.am | 1 + > > > + 1 file changed, 1 insertion(+) > > > + > > > +diff --git a/src/Makefile.am b/src/Makefile.am > > > +index 9a0a44e..9b668c8 100644 > > > +--- a/src/Makefile.am > > > b/src/Makefile.am > > > +@@ -1,5 +1,6 @@ > > > + SUBDIRS := gallium/auxiliary > > > + AM_LDFLAGS = -lm \ > > > ++ $(LIBDRM_LIBS) \ > > > + $(GBM_LIBS) \ > > > + $(EPOXY_LIBS) \ > > > + $(X11_LIBS) \ > > > +-- > > > +2.17.1 > > > + > > > diff --git > > > a/meta/recipes-graphics/virglrenderer/virglrenderer/0001-vtest-add-missing-includes.patch > > > > > > b/meta/recipes-graphics/virglrenderer/virglrenderer/0001-vtest-add-missing-includes.patch > > > new file mode 100644 > > > index 000..2b4ffa932de > > > --- /dev/null > > > +++ > > > b/meta/recipes-graphics/virglrenderer/virglrenderer/0001-vtest-add-missing-includes.patch > > > @@ -0,0 +1,38 @@ > > > +From 05c5c5f43fbffb3317bd9da27d414890d2ef493c Mon Sep 17 00:00:00 2001 > > > +From: Alexander Kanavin > > > +Date: Fri, 18 Jan 2019 13:47:23 +0100 > > > +Subject: [PATCH] vtest: add missing includes > > > + > > > +This fixes build failures with musl C library > > > + > > > +Upstream-Status: Accepted > > > [https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/125] > > > +Signed-off-by: Alexander Kanavin > > > +--- > > > + vtest/util.c | 1 + > > > + vtest/vtest_server.c | 1 + > > > + 2 files changed, 2 insertions(+) > > > + > > > +diff --git a/vtest/util.c
[OE-core] [PATCH] musl: Update to latest beyond 1.21
https://git.musl-libc.org/cgit/musl/log/?qt=range=1691b23955590d1eb66a11158fdd91c86337e886..ad795d56ba3fb9d69f524ee676e3b1e2355cceb7 Signed-off-by: Khem Raj --- meta/recipes-core/musl/musl_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb index 73906d0f3c..f84c17d295 100644 --- a/meta/recipes-core/musl/musl_git.bb +++ b/meta/recipes-core/musl/musl_git.bb @@ -4,7 +4,7 @@ require musl.inc inherit linuxloader -SRCREV = "1691b23955590d1eb66a11158fdd91c86337e886" +SRCREV = "ad795d56ba3fb9d69f524ee676e3b1e2355cceb7" BASEVER = "1.1.21" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] ltp: Update to 20190115
On Sat, Feb 23, 2019 at 8:12 AM Richard Purdie
wrote:
>
> On Wed, 2019-01-16 at 16:28 +0100, Petr Vorel wrote:
> > Hi Richard, Khem,
> >
> > > > Thanks for looking at this. Unfortunately it failed in testing on
> > > > most
> > > > targets:
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/181/steps/7/logs/step1b
> > > > (one failure given as an example).
> > > > Warnings as errors are good during development but sometimes less
> > > > useful during release due to the variety of end user
> > > > configurations.
> > > with glibc 2.29 in play
> > > http://errors.yoctoproject.org/Errors/Details/216829/
> >
> > Thanks for your reports.
> > Is there any way I could easily reproduce it?
> > Some config I can download?
> > I'm testing with default config.
> > I'm sorry for dummy question, I'm more experienced with Buildroot.
>
> Sorry for not replying sooner. We just hit this issue again:
>
> http://errors.yoctoproject.org/Errors/Latest/?filter=480efd388db578106a8a2129c0382b7e56a1ee36=commit=150
>
> This time I think I understand where the error is coming from though:
>
> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/security_flags.inc
>
> does:
>
> security_flags.inc:SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security
> -Werror=format-security"
> security_flags.inc:SECURITY_CFLAGS ?= "${SECURITY_STACK_PROTECTOR}
> ${SECURITY_PIE_CFLAGS} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
>
> so the reproducer should be to add "-Wformat -Wformat-security
> -Werror=format-security" to CFLAGS when building ltp.
>
I think this must be new, we are carrying patches to fix similar
issues in other parts of ltp. Probably something to consider for
upstreaming
e.g.
https://git.openembedded.org/openembedded-core/tree/meta/recipes-extended/ltp/ltp/0036-testcases-network-nfsv4-acl-acl1.c-Security-fix-on-s.patch
> Cheers,
>
> Richard
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] ltp: Update to 20190115
On Wed, 2019-01-16 at 16:28 +0100, Petr Vorel wrote:
> Hi Richard, Khem,
>
> > > Thanks for looking at this. Unfortunately it failed in testing on
> > > most
> > > targets:
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/46/builds/181/steps/7/logs/step1b
> > > (one failure given as an example).
> > > Warnings as errors are good during development but sometimes less
> > > useful during release due to the variety of end user
> > > configurations.
> > with glibc 2.29 in play
> > http://errors.yoctoproject.org/Errors/Details/216829/
>
> Thanks for your reports.
> Is there any way I could easily reproduce it?
> Some config I can download?
> I'm testing with default config.
> I'm sorry for dummy question, I'm more experienced with Buildroot.
Sorry for not replying sooner. We just hit this issue again:
http://errors.yoctoproject.org/Errors/Latest/?filter=480efd388db578106a8a2129c0382b7e56a1ee36=commit=150
This time I think I understand where the error is coming from though:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/security_flags.inc
does:
security_flags.inc:SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security
-Werror=format-security"
security_flags.inc:SECURITY_CFLAGS ?= "${SECURITY_STACK_PROTECTOR}
${SECURITY_PIE_CFLAGS} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
so the reproducer should be to add "-Wformat -Wformat-security
-Werror=format-security" to CFLAGS when building ltp.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ltp: Bump to 20190115
On Thu, 2019-02-21 at 12:21 -0600, Daniel Díaz wrote: > This patch has been refreshed: > * 0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch > > These patches have been dropped as they have been merged: > * 0001-netns_helper.sh-use-ping-6-when-ping6-is-not-avaliab.patch > * 0001-setrlimit05-Use-another-method-to-get-bad-address.patch > * 0001-sigwaitinfo01-recent-glibc-calls-syscall-directly.patch > * 0001-statx-fix-compile-errors.patch > * 0001-syscalls-fcntl-make-OFD-command-use-fcntl64-syscall-.patch > * 0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch > > This patch has been added: > * define-sigrtmin-and-sigrtmax-for-musl.patch > > Added these rdependencies: > * file: for ld01, file01 and logrotate > * quota: for quota_remount_test01 > > Signed-off-by: Daniel Díaz I think there was already a previous version of this upgrade which also didn't work: http://errors.yoctoproject.org/Errors/Latest/?filter=480efd388db578106a8a2129c0382b7e56a1ee36=commit=150 From the -Wformat-security -Werror=format-security security flags. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel: Ensure an initramdfs is added if configured
"initramdfs"? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel: Ensure an initramdfs is added if configured
If ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.cpio does not exist,
nor any of the compressed variants, nothing is copied to kernel build's
./usr directory.
The code does not fail, but silently proceeds without a bundled initramfs.
Change to fail and tell the user something is wrong.
Also, if an initramfs is found, contrary to the comments, it does not stop
at the first uncompressed/compressed cpio image found. Instead it keeps
processing all so the last is used. Fix this to behave as per the comments.
[YOCTO #12909]
(Patch by Leon Woestenberg)
Signed-off-by: Richard Purdie
---
meta/classes/kernel.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c0889bd3ee4..a5b1df1b0dc 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -224,9 +224,11 @@ copy_initramfs() {
break
;;
esac
+ break
fi
done
- echo "Finished copy of initramfs into ./usr"
+ # Verify that the above loop found a initramfs, fail otherwise
+ [ -f ${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio ] && echo "Finished copy of
initramfs into ./usr" || die "Could not find any
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.cpio{.gz|.lz4|.lzo|.lzma|.xz) for
bundling; INITRAMFS_IMAGE_NAME might be wrong."
}
do_bundle_initramfs () {
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel: Ensure an initramdfs is added if configured
If ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.cpio does not exist,
nor any of the compressed variants, nothing is copied to kernel build's
./usr directory.
The code does not fail, but silently proceeds without a bundled initramfs.
Change to fail and tell the user something is wrong.
[YOCTO #12909]
(Patch by Leon Woestenberg)
Signed-off-by: Richard Purdie
---
meta/classes/kernel.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c0889bd3ee4..a5b1df1b0dc 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -224,9 +224,11 @@ copy_initramfs() {
break
;;
esac
+ break
fi
done
- echo "Finished copy of initramfs into ./usr"
+ # Verify that the above loop found a initramfs, fail otherwise
+ [ -f ${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio ] && echo "Finished copy of
initramfs into ./usr" || die "Could not find any
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.cpio{.gz|.lz4|.lzo|.lzma|.xz) for
bundling; INITRAMFS_IMAGE_NAME might be wrong."
}
do_bundle_initramfs () {
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On Sat, 2019-02-23 at 14:43 +0100, Alexander Kanavin wrote: > On Sat, 23 Feb 2019 at 14:36, Richard Purdie > > I think the problem is in staging_populate_sysroot_dir(). It's > > confusing target and native package_archs since in the case we see > > this > > its x86_64 where the target and build archs match. > > > > Not entirely sure how we'll fix this but that is where I think the > > problem is. > > > > Not sure why we're suddenly seeing it now and whether the patches > > somehow trigger it or not... > > The reproducer does fail on master too, so the patches may only have > shifted the timings such that the race outcome is sometimes the > failing one. Agreed, I think we've just exposed a bug. I've sent a patch to fix the problem in the function since its clearly not doing what was intended. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] staging: Fix staging_populate_sysroot_dir native corruption
bitbake gdk-pixbuf gdk-pixbuf-native
bitbake build-sysroots -c build_target_sysroot
can lead to tracebacks as gdk-pixbuf-native is being installed into the
target sysroot. The issue is that the x86_64 (common BUILD_ARCH) sysroot
components directory can contain a mix of native and target artefacts.
Differentiate by the "-native" in the recipe names. Should also trim
down the size of the sysroot used in eSDK.
Signed-off-by: Richard Purdie
---
meta/classes/staging.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 84e13bab592..2ef45092235 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -198,6 +198,10 @@ def staging_populate_sysroot_dir(targetsysroot,
nativesysroot, native, d):
if manifest.endswith("-initial.populate_sysroot"):
# skip glibc-initial and libgcc-initial due to file overlap
continue
+if not native and manifest.endswith("-native.populate_sysroot"):
+continue
+if native and not manifest.endswith("-native.populate_sysroot"):
+continue
tmanifest = targetdir + "/" + os.path.basename(manifest)
if os.path.exists(tmanifest):
continue
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On Sat, 23 Feb 2019 at 14:36, Richard Purdie
wrote:
> > > I'm at the same time staring at this bit in pixbufcache.bbclass:
> > >
> > > gdkpixbuf_complete() {
> > > GDK_PIXBUF_FATAL_LOADER=1
> > > ${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
> > > --update-cache || exit 1
> > > }
> > >
> > > DEPENDS_append_class-native = " gdk-pixbuf-native"
> > > SYSROOT_PREPROCESS_FUNCS_append_class-native = "
> > > pixbufcache_sstate_postinst"
> > >
> > > # See base.bbclass for the other half of this
> > > pixbufcache_sstate_postinst() {
> > > mkdir -p ${SYSROOT_DESTDIR}${bindir}
> > > dest=${SYSROOT_DESTDIR}${bindir}/postinst-${PN}
> > > echo '#!/bin/sh' > $dest
> > > echo "${gdkpixbuf_complete}" >> $dest
> > > chmod 0755 $dest
> > > }
> > >
> > > It's all written for -native, yet the script that fails, resides in
> > > tmp/sysroots/qemux86-64/usr/bin/postinst-gdk-pixbuf-native (e.g.
> > > the
> > > target sysroot which is racing with the native one). Why is it even
> > > there?
> > > I haven't written this code :) and haven't really seen it before,
> > > but
> > > this might be a lead.
> >
> > I'm sure I've worked on the above before, my memory of why we need it
> > is fuzzy. I do now have a reproducer though:
> >
> > bitbake gdk-pixbuf gdk-pixbuf-native
> > then
> > bitbake build-sysroots -c build_target_sysroot
> >
> > If you bake build_native_sysroot first, the problem goes away.
>
> I think the problem is in staging_populate_sysroot_dir(). It's
> confusing target and native package_archs since in the case we see this
> its x86_64 where the target and build archs match.
>
> Not entirely sure how we'll fix this but that is where I think the
> problem is.
>
> Not sure why we're suddenly seeing it now and whether the patches
> somehow trigger it or not...
The reproducer does fail on master too, so the patches may only have
shifted the timings such that the race outcome is sometimes the
failing one.
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On Sat, 2019-02-23 at 13:25 +, Richard Purdie wrote:
> On Sat, 2019-02-23 at 13:51 +0100, Alexander Kanavin wrote:
> > I'm at the same time staring at this bit in pixbufcache.bbclass:
> >
> > gdkpixbuf_complete() {
> > GDK_PIXBUF_FATAL_LOADER=1
> > ${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
> > --update-cache || exit 1
> > }
> >
> > DEPENDS_append_class-native = " gdk-pixbuf-native"
> > SYSROOT_PREPROCESS_FUNCS_append_class-native = "
> > pixbufcache_sstate_postinst"
> >
> > # See base.bbclass for the other half of this
> > pixbufcache_sstate_postinst() {
> > mkdir -p ${SYSROOT_DESTDIR}${bindir}
> > dest=${SYSROOT_DESTDIR}${bindir}/postinst-${PN}
> > echo '#!/bin/sh' > $dest
> > echo "${gdkpixbuf_complete}" >> $dest
> > chmod 0755 $dest
> > }
> >
> > It's all written for -native, yet the script that fails, resides in
> > tmp/sysroots/qemux86-64/usr/bin/postinst-gdk-pixbuf-native (e.g.
> > the
> > target sysroot which is racing with the native one). Why is it even
> > there?
> > I haven't written this code :) and haven't really seen it before,
> > but
> > this might be a lead.
>
> I'm sure I've worked on the above before, my memory of why we need it
> is fuzzy. I do now have a reproducer though:
>
> bitbake gdk-pixbuf gdk-pixbuf-native
> then
> bitbake build-sysroots -c build_target_sysroot
>
> If you bake build_native_sysroot first, the problem goes away.
I think the problem is in staging_populate_sysroot_dir(). It's
confusing target and native package_archs since in the case we see this
its x86_64 where the target and build archs match.
Not entirely sure how we'll fix this but that is where I think the
problem is.
Not sure why we're suddenly seeing it now and whether the patches
somehow trigger it or not...
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On Sat, 2019-02-23 at 13:51 +0100, Alexander Kanavin wrote:
> On Sat, 23 Feb 2019 at 13:43, Richard Purdie
> wrote:
> > On Sat, 2019-02-23 at 12:29 +, Richard Purdie wrote:
> > > On Wed, 2019-02-20 at 21:10 +0100, Alexander Kanavin wrote:
> > > > Drop autotools-specific patches.
> > > >
> > > > Rework jku's thumbnailer patch into meson configuration.
> > > >
> > > > Signed-off-by: Alexander Kanavin
> > >
> > > We've seen it before but its happened again:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/326
> > >
> > > I went into the failed build directory and ran "bitbake core-
> > > image-
> > > sato -c testsdkext" and it succeeded so I'm not sure sure how
> > > we're
> > > going to debug this one...
> >
> > From staring at the log, I think do_build_target_sysroot in build-
> > sysroots.bb may need to depend on do_build_native_sysroot.
> >
> > They're both running at the same time and potentially racing?
>
> I'm at the same time staring at this bit in pixbufcache.bbclass:
>
> gdkpixbuf_complete() {
> GDK_PIXBUF_FATAL_LOADER=1
> ${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
> --update-cache || exit 1
> }
>
> DEPENDS_append_class-native = " gdk-pixbuf-native"
> SYSROOT_PREPROCESS_FUNCS_append_class-native = "
> pixbufcache_sstate_postinst"
>
> # See base.bbclass for the other half of this
> pixbufcache_sstate_postinst() {
> mkdir -p ${SYSROOT_DESTDIR}${bindir}
> dest=${SYSROOT_DESTDIR}${bindir}/postinst-${PN}
> echo '#!/bin/sh' > $dest
> echo "${gdkpixbuf_complete}" >> $dest
> chmod 0755 $dest
> }
>
> It's all written for -native, yet the script that fails, resides in
> tmp/sysroots/qemux86-64/usr/bin/postinst-gdk-pixbuf-native (e.g. the
> target sysroot which is racing with the native one). Why is it even
> there?
> I haven't written this code :) and haven't really seen it before, but
> this might be a lead.
I'm sure I've worked on the above before, my memory of why we need it
is fuzzy. I do now have a reproducer though:
bitbake gdk-pixbuf gdk-pixbuf-native
then
bitbake build-sysroots -c build_target_sysroot
If you bake build_native_sysroot first, the problem goes away.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On Sat, 23 Feb 2019 at 13:43, Richard Purdie
wrote:
>
> On Sat, 2019-02-23 at 12:29 +, Richard Purdie wrote:
> > On Wed, 2019-02-20 at 21:10 +0100, Alexander Kanavin wrote:
> > > Drop autotools-specific patches.
> > >
> > > Rework jku's thumbnailer patch into meson configuration.
> > >
> > > Signed-off-by: Alexander Kanavin
> >
> > We've seen it before but its happened again:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/326
> >
> > I went into the failed build directory and ran "bitbake core-image-
> > sato -c testsdkext" and it succeeded so I'm not sure sure how we're
> > going to debug this one...
>
> From staring at the log, I think do_build_target_sysroot in build-
> sysroots.bb may need to depend on do_build_native_sysroot.
>
> They're both running at the same time and potentially racing?
I'm at the same time staring at this bit in pixbufcache.bbclass:
gdkpixbuf_complete() {
GDK_PIXBUF_FATAL_LOADER=1
${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
--update-cache || exit 1
}
DEPENDS_append_class-native = " gdk-pixbuf-native"
SYSROOT_PREPROCESS_FUNCS_append_class-native = " pixbufcache_sstate_postinst"
# See base.bbclass for the other half of this
pixbufcache_sstate_postinst() {
mkdir -p ${SYSROOT_DESTDIR}${bindir}
dest=${SYSROOT_DESTDIR}${bindir}/postinst-${PN}
echo '#!/bin/sh' > $dest
echo "${gdkpixbuf_complete}" >> $dest
chmod 0755 $dest
}
It's all written for -native, yet the script that fails, resides in
tmp/sysroots/qemux86-64/usr/bin/postinst-gdk-pixbuf-native (e.g. the
target sysroot which is racing with the native one). Why is it even
there?
I haven't written this code :) and haven't really seen it before, but
this might be a lead.
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] glib-2.0: restore API docs generation
On Sat, 23 Feb 2019 at 13:05, Richard Purdie
wrote:
> > Signed-off-by: Alexander Kanavin
> > ---
> > meta/recipes-core/glib-2.0/glib.inc | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/meta/recipes-core/glib-2.0/glib.inc
> > b/meta/recipes-core/glib-2.0/glib.inc
> > index 4d7fdeebbbd..6305f553b4a 100644
> > --- a/meta/recipes-core/glib-2.0/glib.inc
> > +++ b/meta/recipes-core/glib-2.0/glib.inc
> > @@ -31,6 +31,12 @@ LEAD_SONAME = "libglib-2.0.*"
> >
> > inherit meson gettext gtk-doc pkgconfig ptest-gnome
> > upstream-version-is-even bash-completion gio-module-cache manpages
> > distro_features_check
> >
> > +GTKDOC_ENABLE_FLAG = "-Dgtk_doc=true"
> > +GTKDOC_DISABLE_FLAG = "-Dgtk_doc=false"
> > +
> > +EXTRA_OEMESON_append_class-target = "
> > ${@bb.utils.contains('GTKDOC_ENABLED', 'True', '${GTKDOC_ENABLE_FLAG}', \
> > +
> > '${GTKDOC_DISABLE_FLAG}', d)} "
> > +
> > # This avoids the need to depend on target python3, which in case of mingw
> > is not even possible.
> > # meson's python configuration pokes into python3 configuration, so this
> > provides the native config to it.
> > unset _PYTHON_SYSCONFIGDATA_NAME
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/326/steps/7/logs/step3b
This one I was able to reproduce - patch sent.
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gtk-doc.bbclass: unset LD_LIBRARY_PATH
meson has been found to set it erroneously.
Signed-off-by: Alexander Kanavin
---
meta/classes/gtk-doc.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes/gtk-doc.bbclass b/meta/classes/gtk-doc.bbclass
index bedb36ec8b7..707d74d1083 100644
--- a/meta/classes/gtk-doc.bbclass
+++ b/meta/classes/gtk-doc.bbclass
@@ -51,6 +51,9 @@ export GIO_MODULE_DIR=${STAGING_LIBDIR}/gio/modules-dummy
GIR_EXTRA_LIBS_PATH=\`find ${B} -name *.so -printf "%h\n"|sort|uniq| tr '\n'
':'\`\$GIR_EXTRA_LIBS_PATH
GIR_EXTRA_LIBS_PATH=\`find ${B} -name .libs| tr '\n' ':'\`\$GIR_EXTRA_LIBS_PATH
+# meson sets this wrongly (only to libs in build-dir), qemu-wrapper_cmdline()
and GIR_EXTRA_LIBS_PATH take care of it properly
+unset LD_LIBRARY_PATH
+
if [ -d ".libs" ]; then
$qemu_binary ".libs/\$@"
else
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On Sat, 2019-02-23 at 12:29 +, Richard Purdie wrote: > On Wed, 2019-02-20 at 21:10 +0100, Alexander Kanavin wrote: > > Drop autotools-specific patches. > > > > Rework jku's thumbnailer patch into meson configuration. > > > > Signed-off-by: Alexander Kanavin > > We've seen it before but its happened again: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/326 > > I went into the failed build directory and ran "bitbake core-image- > sato -c testsdkext" and it succeeded so I'm not sure sure how we're > going to debug this one... >From staring at the log, I think do_build_target_sysroot in build- sysroots.bb may need to depend on do_build_native_sysroot. They're both running at the same time and potentially racing? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On Sat, 23 Feb 2019 at 13:29, Richard Purdie wrote: > > Drop autotools-specific patches. > > > > Rework jku's thumbnailer patch into meson configuration. > > > > Signed-off-by: Alexander Kanavin > > We've seen it before but its happened again: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/326 > > I went into the failed build directory and ran "bitbake core-image-sato > -c testsdkext" and it succeeded so I'm not sure sure how we're going to > debug this one... :-( We can debug by making a tarball snapshot of the failed build dir, and statically inspecting it, I guess. It has to be some kind of race during SDK extraction. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson
On Wed, 2019-02-20 at 21:10 +0100, Alexander Kanavin wrote: > Drop autotools-specific patches. > > Rework jku's thumbnailer patch into meson configuration. > > Signed-off-by: Alexander Kanavin We've seen it before but its happened again: https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/326 I went into the failed build directory and ran "bitbake core-image-sato -c testsdkext" and it succeeded so I'm not sure sure how we're going to debug this one... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v6 13/13] util-linux: final cleanup
On Thu, 2019-02-21 at 21:08 +, Burton, Ross wrote: > Looks like the manpage cleanup didn't quite work: > > WARNING: util-linux-2.32.1-r0 do_configure: QA Issue: util-linux: > invalid PACKAGECONFIG: manpages [invalid-packageconfig] There is also: https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/319/steps/7/logs/warnings WARNING: lib32-util-linux-2.32.1-r0 do_package: QA Issue: lib32-util-linux package lib32-util-linux-blkid - suspicious values 'e2fsprogs-blkid' in RREPLACES [multilib] WARNING: lib32-util-linux-2.32.1-r0 do_package: QA Issue: lib32-util-linux package lib32-util-linux-blkid - suspicious values 'e2fsprogs-blkid' in RCONFLICTS [multilib] so something isn't quite right with the mutlilib variants of the recipe. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] glib-2.0: restore API docs generation
On Fri, 2019-02-22 at 15:16 +0100, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin
> ---
> meta/recipes-core/glib-2.0/glib.inc | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/meta/recipes-core/glib-2.0/glib.inc
> b/meta/recipes-core/glib-2.0/glib.inc
> index 4d7fdeebbbd..6305f553b4a 100644
> --- a/meta/recipes-core/glib-2.0/glib.inc
> +++ b/meta/recipes-core/glib-2.0/glib.inc
> @@ -31,6 +31,12 @@ LEAD_SONAME = "libglib-2.0.*"
>
> inherit meson gettext gtk-doc pkgconfig ptest-gnome upstream-version-is-even
> bash-completion gio-module-cache manpages distro_features_check
>
> +GTKDOC_ENABLE_FLAG = "-Dgtk_doc=true"
> +GTKDOC_DISABLE_FLAG = "-Dgtk_doc=false"
> +
> +EXTRA_OEMESON_append_class-target = " ${@bb.utils.contains('GTKDOC_ENABLED',
> 'True', '${GTKDOC_ENABLE_FLAG}', \
> +
> '${GTKDOC_DISABLE_FLAG}', d)} "
> +
> # This avoids the need to depend on target python3, which in case of mingw
> is not even possible.
> # meson's python configuration pokes into python3 configuration, so this
> provides the native config to it.
> unset _PYTHON_SYSCONFIGDATA_NAME
https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/326/steps/7/logs/step3b
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig
On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote: > > On Feb 21, 2019, at 18:51, Richard Purdie < > > richard.pur...@linuxfoundation.org> wrote: > > > > Multiconfig is meant to support this workflow. Unfortunately there > > are > > open bugs and people haven't the time to work on it so its stalled. > > That said, the key pieces are already there. > > > > A picture is worth a thousand words. I thought a demo might > > interest > > people and "prove" this can work. > > Thank you for the patches and PoC. We will test and are motivated to > see this work. Just to follow up, I've cleaned up the patches, they're now just fixes to bitbake and are done generically so we shouldn't have to patch the various BB_TASKDEPDATA users. They're on the bitbake-devel list and queued in master-next. This should mean multiconfig looks better in 2.7. I'm going to try and get a patch to add some tests/example too. Could anyone who's previously reported issues (Armin?) retest with these and confirm the issues seen have been fixed please? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] glib-networking: upgrade 2.54.1 -> 2.58.0
On Thu, 2019-02-21 at 23:46 +, Peter Kjellerstedt wrote: > This does not build any more if USE_NLS = "no" is used. Has anyone > looked at making this work together with meson? Otherwise I guess > there is trouble ahead now that more and more packages are being > converted to use meson, since the code in gettext.bbclass currently > only supports autotools. A quick look at meson's i18n.py module does > not indicate that there is any easy way to disable the gettext > support, corresponding to autotools' --disable-nls. Apparently it > was discussed in https://github.com/mesonbuild/meson/issues/821, but > it seems they only added detection of the gettext tools without > adding support for disabling gettext and then closed the issue. > > Looking at 1d6648102 (json-glib: fix native build), it seems Ross > encountered a similar problem for json-glib and opted to workaround > the problem by overriding USE_NLS. However, that does not seem like > a long term solution... Once, we did have people who had interests in these things *and* time to be able to go and work on them. The way things are at the moment, the people who would have once done this are no longer available. I agree this would be nice to have and we do rely on it for some parts of the build system but it will need someone to step up and work on it. I don't know how to attract more people to help with these kinds of things, I think over time things will improve but we are struggling a bit with it right now. It is worth opening a bug for so we can track it. If someone had time to talk to upstream meson, that would also be useful, see if we can convince them its a good idea. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
