Re: [OE-core] ✗ patchtest: failure for libgcrypt: fix CVE-2017-9526 (rev2)

On 13 July 2017 at 21:38, Patchwork wrote: > == Series Details == > > Series: libgcrypt: fix CVE-2017-9526 (rev2) > Revision: 2 > Not sure if this should be a patchwork bug or not? This patch is showing up as a revision 2 of the other patch when in reality they are patches for two separate branc

Re: [OE-core] [oe-core][PATCH 1/1] valgrind: allow version 3.12 to build under gcc7

On Thu, 2017-07-13 at 17:24:21 -0700, Joe Slater wrote: > Building for powerpc64 fails because of erroneous assertions > that register r2 is clobbered. This has probably been fixed > in version 3.13. Wouldn't it make more sense then to go ahead with the 3.13 update instead of adding another out-o

[OE-core] [PATCH v2] pkgconf: add recipe

Move pkgconf recipe to oe-core from meta-pkgconf: https://github.com/kergoth/meta-kergoth-wip/tree/master/meta-pkgconf Signed-off-by: Christopher Larson Signed-off-by: Maxin B. John --- Changes in v2: 1. Fix build errors with mingw --- meta/files/common-licenses/pkgconf | 1

Re: [OE-core] [PATCH 6/8] image_types_wic: set default WKS_FILE_DEPENDS

On Tue, Jul 11, 2017 at 10:29:20AM +0200, Patrick Ohly wrote: > On Thu, 2017-07-06 at 10:56 +0300, Ed Bartosh wrote: > > diff --git a/meta/classes/image_types_wic.bbclass > > b/meta/classes/image_types_wic.bbclass > > index 05ee68d..e9750b5 100644 > > --- a/meta/classes/image_types_wic.bbclass > >

[OE-core] [V2 PATCH] shadow.inc: remove pam.d/chpasswd and pam.d/newusers

* Problem: While pam is enabled: ... DISTRO_FEATURES_append = " pam" ... Fix below errors on target: ... root@qemux86:~# newusers newusers: PAM: Authentication failure root@qemux86:~# chpasswd chpasswd: PAM: Authentication failure ... * Analysis: The pam.d/chpasswd and pam.d/newusers were

Re: [OE-core] [PATCH 20/30] oeqa/selftest/cases: runqemu enable thraded runs

On Wed, 2017-07-12 at 10:01 -0500, Aníbal Limón wrote: > > Add also a wrapper for runqemu and we can get rid of "from > > oeqa.utils.commands import" completely. > > Yes we can after the refkit and other selftest are adapted. My proposal wasn't to remove oeqa.utils.commands, only the "import" sta

Re: [OE-core] [PATCH 01/30] oeqa/core/loader: Switch method definition for _make_failed_test

On Tue, 2017-07-11 at 15:23 -0500, Aníbal Limón wrote: > This was a mistake of me to define wrong what methods needs > to be defined by certain python version. > > See rev d8380d098a290510b442a7abd2dd5a50cabf5844. This will fix this error that we see in Refkit with current OE-core master, right?

[OE-core] two identically-named machine .conf files in two different layers?

just ran across someone else's OE work, where he pulled in a standard layer that defined a machine, call it "machine.conf", then added an internal layer with some tweaks but *also* contained a machine definition file named precisely "machine.conf", which was just the original file with some edit

[OE-core] [PATCH] selftest: Add vulkan-demos to checkpkg exceptions

vulkan-demos has not had any releases. Signed-off-by: Jussi Kukkonen --- This is only useful with the vulkan-demos patch. I've pushed this on top of the jku/vulkan branch in poky-contrib. The commit silences the selftest failure from the checkpkg test. The whole checkpkg exceptions system shou

[OE-core] [PATCH 0/4] Remove gnome-common

Patchset should preferably only be merged once "gnome-common: Add recipe (from oe-core)" (2017-07-06) patch has been merged in meta-oe. I can ping the thread once it happens. This set removes gnome-common, an obsolete collection of m4-macros that partially conflicts with autoconf-archive. The plan

[OE-core] [PATCH 3/4] gnome-desktop: Don't use gnome-common

Add a patch to no use gnome-common macros Signed-off-by: Jussi Kukkonen --- ...figure.ac-Remove-gnome-common-macro-calls.patch | 33 ++ .../gnome-desktop/gnome-desktop3_3.24.2.bb | 6 ++-- 2 files changed, 37 insertions(+), 2 deletions(-) create mode 100644 meta/re

[OE-core] [PATCH 4/4] gnome-common: Remove as deprecated

Nothing in oe-core requires gnome-common and it is also deprecated upstream: Remove it. Signed-off-by: Jussi Kukkonen --- meta/recipes-gnome/gnome/gnome-common_3.18.0.bb | 20 1 file changed, 20 deletions(-) delete mode 100644 meta/recipes-gnome/gnome/gnome-common_3.18.0.bb

[OE-core] [PATCH 1/4] matchbox-desktop: Upgrade to 2.2

Only change is dropping dependency on gnome-common (which is deprecated upstream). Signed-off-by: Jussi Kukkonen --- .../{matchbox-desktop_2.1.bb => matchbox-desktop_2.2.bb}| 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-sato/matchbox-desktop/{matchbo

[OE-core] [PATCH 2/4] python3-pygobject: Don't use gnome-common

Patch out the one use of gnome-common macros: pygobject is moving to autoconf-archive in next release so this patch is temporary. Signed-off-by: Jussi Kukkonen --- ...onfigure.ac-Don-t-use-gnome-common-macros.patch | 33 ++ .../python/python3-pygobject_3.24.1.bb |

[OE-core] ✗ patchtest: failure for Remove gnome-common

== Series Details == Series: Remove gnome-common Revision: 1 URL : https://patchwork.openembedded.org/series/7744/ 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

[OE-core] [PATCHv2 3/4] gnome-desktop: Don't use gnome-common

Add a patch to no use gnome-common macros Signed-off-by: Jussi Kukkonen --- Changes since v1: * Fix Upstream-Status line Branch jku/gnome-common in poky-contrib has been updated. ...figure.ac-Remove-gnome-common-macro-calls.patch | 33 ++ .../gnome-desktop/gnome-desktop3_3

[OE-core] [PATCH v2 1/8] wic: get rid of using wic-tools

At the moment, when building images with IMAGE_FSTYPES=wic one ends up depending on wic-tools and thus syslinux and grub-efi even when not using those at all. Ideally, building an image with wic should only build the tools and components really needed. The problem is that "wic-tools" is needed als

[OE-core] [PATCH v2 0/8] #11552 - wic: avoid unnecessary dependencies

Hi, This patchset gets rid of building wic-tools for every image when IMAGE_FSTYPES contains 'wic'. Instead of using dependencies from wic-tools native sysroot wic expects image native sysroot to contain them. This should be done by setting WKS_FILE_DEPENDS variable in configuration files where WK

[OE-core] [PATCH v2 7/8] wic: isoimage-isohybrid: use grub-efi from deploy dir

isoimage-isohybrid plugin tries to build grub-efi in its working directory if it can't find efi binary. Wic should avoid doing anything in working directories of other recipes. It should use artifacts from the image deployment directory instead. Signed-off-by: Ed Bartosh --- .../lib/wic/plugins/

[OE-core] [PATCH v2 4/8] wic: isoimage-isohybrid: check result of glob()

isoimage-isohybrid plugin uses result of glob call to get path to initrd image. When glob returns empty list the plugin crashes with IndexError. Checking if result of glob call is not empty should fix the breakage. Signed-off-by: Ed Bartosh --- scripts/lib/wic/plugins/source/isoimage-isohybrid.

[OE-core] [PATCH v2 2/8] wic: isoimage: do not remove temp directory

Removed isodir subrdirectory instead of removing temporary working directory as working directory can contain copy of rootfs partition and shouldn't be removed by any plugin. Signed-off-by: Ed Bartosh --- scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 4 ++-- 1 file changed, 2 insertions

[OE-core] [PATCH v2 5/8] wic-tools: don't create wic-tools.env

wic-tools.env was uses only when wic is run from bitbake. As wic doesn't use wic-tools anymore in this mode there is no need for this file. Signed-off-by: Ed Bartosh --- meta/recipes-core/meta/wic-tools.bb | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/meta/recipes

[OE-core] [PATCH v2 3/8] wic: build wic-tools only if wic is run manually

When wic can't find native sysroot it tries to build wic-tools However, it's not possible when wic is run from bitbake. Moreover, it's not even feasible anymore as wic-tools should be used only when wic is run manually. Checked if wic is run manually before building wic-tools. Signed-off-by: Ed B

[OE-core] [PATCH v2 8/8] selftest: fixed 5 wic test cases

Added core-image-minimal -> syslinux dependency to ensure syslinux artifacts are available from core-image-minimal build. This should fix test_iso_image, test_bootloader_config and test_default_output_dir test cases. Used --native-sysroot in test_image_vars_dir_long and test_image_vars_dir_short t

[OE-core] [PATCH v2 6/8] image_types_wic: set default WKS_FILE_DEPENDS

The default set of dependencies used via wic-tools is not used anymore as wic images don't depend on wic-tools. Set of packages required to produce wic image depends on the content of the .wks file, so WKS_FILE_DEPENDS variable should be used to provide correct list of dependencies when WKS_FILE v

Re: [OE-core] ✗ patchtest: failure for libgcrypt: fix CVE-2017-9526 (rev2)

On 07/14/2017 02:57 AM, Jussi Kukkonen wrote: > On 13 July 2017 at 21:38, Patchwork > > wrote: > > == Series Details == > > Series: libgcrypt: fix CVE-2017-9526 (rev2) > Revision: 2 > > > Not sure if this should be a patchwork bug or not?

Re: [OE-core] [oe-core][PATCH] uftrace: Add recipe

On Thu, Jul 13, 2017 at 10:00 PM, Changhyeok Bae wrote: > - Add recipe for uftrace v0.7. > - Support x86_64, arm (v6 or later), and aarch64. > - Disable for armv4 and armv5 in arm architecture which is only > supported armv6 or later. > - Attached 2 patches is merged to upstream. > perhaps meta

[OE-core] [PATCH v2] python3: fix weakref spewing exceptions during interp finalization

When py3 applications are exiting we often see errors similar to the following: Exception ignored in: .remove at 0x7fcb56b09400> Traceback (most recent call last): File "/usr/lib64/python3.5/weakref.py", line 117, in remove TypeError: 'NoneType' object is not callable After a quick search th

Re: [OE-core] [oe-core][PATCH] uftrace: Add recipe

On 14 July 2017 at 14:35, Khem Raj wrote: > perhaps meta-oe is better place fot now. Will it support mips/ppc in future > Agreed. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailma

Re: [OE-core] two identically-named machine .conf files in two different layers?

On Fri, Jul 14, 2017 at 2:50 AM, Robert P. J. Day wrote: > > just ran across someone else's OE work, where he pulled in a > standard layer that defined a machine, call it "machine.conf", then > added an internal layer with some tweaks but *also* contained a > machine definition file named preci

[OE-core] [krogoth][PATCH] qemu: make UNDEF registers RAZ for ID_AA64*

when running qemu-system for aarch64 which does get built within the sdk from the krogoth branch it does give the following error (when run with -d unimp) "read access to unsupported AArch64 system register op0:3 op1:0 crn:0 crm:7 op2:2" This error results in an not bootable kernel on qemu

[OE-core] ✗ patchtest: failure for qemu: make UNDEF registers RAZ for ID_AA64*

== Series Details == Series: qemu: make UNDEF registers RAZ for ID_AA64* Revision: 1 URL : https://patchwork.openembedded.org/series/7748/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been exec

Re: [OE-core] [oe-core][PATCH] uftrace: Add recipe

Ok. Thanks for your comment. I'll send this patch to meta-oe. Thanks Changhyeok 2017-07-14 23:16 GMT+09:00 Burton, Ross : > > On 14 July 2017 at 14:35, Khem Raj wrote: > >> perhaps meta-oe is better place fot now. Will it support mips/ppc in >> future >> > > Agreed. > > Ross > > -- Thanks C

Re: [OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

On Tue, Jul 11, 2017 at 10:06 AM, Jussi Kukkonen wrote: > On 10 July 2017 at 17:47, Andrea Galbusera wrote: > >> During bisection the failing task changed from do_prepare_recipe_sysroot >> to do_compile with the log below. I have no idea if these things do relate >> themselves, but if not, I was

[OE-core] [krogoth][PATCH v2] qemu: make UNDEF registers RAZ for ID_AA64*

when running qemu-system for aarch64 which does get built within the sdk from the krogoth branch it does give the following error (when run with -d unimp) "read access to unsupported AArch64 system register op0:3 op1:0 crn:0 crm:7 op2:2" This error results in an not bootable kernel on qemu

Re: [OE-core] [PATCH 01/30] oeqa/core/loader: Switch method definition for _make_failed_test

On 07/14/2017 04:52 AM, Patrick Ohly wrote: > On Tue, 2017-07-11 at 15:23 -0500, Aníbal Limón wrote: >> This was a mistake of me to define wrong what methods needs >> to be defined by certain python version. >> >> See rev d8380d098a290510b442a7abd2dd5a50cabf5844. > > This will fix this error tha

Re: [OE-core] [PATCH 20/30] oeqa/selftest/cases: runqemu enable thraded runs

On 07/14/2017 04:35 AM, Patrick Ohly wrote: > On Wed, 2017-07-12 at 10:01 -0500, Aníbal Limón wrote: >>> Add also a wrapper for runqemu and we can get rid of "from >>> oeqa.utils.commands import" completely. >> >> Yes we can after the refkit and other selftest are adapted. > > My proposal wasn't

[OE-core] State of bitbake world, Failed tasks 2017-07-13

http://www.openembedded.org/wiki/Bitbake_World_Status == Number of issues - stats == {| class='wikitable' !|Date !!colspan='3'|Failed tasks !!|Signatures !!colspan='14'|QA !!Comment |- || ||qemuarm ||qemux86 ||qemux86_64

Re: [OE-core] State of bitbake world, Failed tasks 2017-07-13

Hi Martin On Fri, Jul 14, 2017 at 9:43 AM, Martin Jansa wrote: > http://www.openembedded.org/wiki/Bitbake_World_Status > The results looks good. I wanted to suggest to start building with hardening flags on if possible. I have ensured that there are no regressions with hardening flags. It would

Re: [OE-core] State of bitbake world, Failed tasks 2017-07-13

OK, I'll merge current batch of pending changes and before next build I'll include conf/distro/include/security_flags.inc Is that all I need to do? On Fri, Jul 14, 2017 at 6:49 PM, Khem Raj wrote: > Hi Martin > > On Fri, Jul 14, 2017 at 9:43 AM, Martin Jansa > wrote: > > http://www.openembedde

Re: [OE-core] State of bitbake world, Failed tasks 2017-07-13

On Fri, Jul 14, 2017 at 10:03 AM, Martin Jansa wrote: > OK, I'll merge current batch of pending changes and before next build I'll > include > conf/distro/include/security_flags.inc > > Is that all I need to do? > yep > On Fri, Jul 14, 2017 at 6:49 PM, Khem Raj wrote: >> >> Hi Martin >> >> On F

Re: [OE-core] [PATCH 1/1] initramfs-framework: include install module in recipe for installation

On Wed, Jul 12, 2017 at 8:01 PM, wrote: > From: "Ng, Wei Tee" > > Utilized the existing init-install-efi.sh script to manage the init-install-efi.sh could be renamed to install-efi.sh; also the package name should be install-efi as it does not support other types of installation. > installatio

Re: [OE-core] [PATCH] mesa: fix build race on src/intel/vulkan

On Wed, Jul 12, 2017 at 1:19 PM, Ross Burton wrote: > It's possible that src/intel/vulkcan can be written into by sed before it has > been created, so add the required mkdir calls. > > Signed-off-by: Ross Burton Has this been send to upstream? Upstream-Status? -- Otavio Salvador

Re: [OE-core] [PATCH] mesa: fix build race on src/intel/vulkan

The second sob is from the patch I sent upstream. The first two lines of the patch header are the OE ones: +++ b/meta/recipes-graphics/mesa/files/vulkan-mkdir.patch @@ -0,0 +1,37 @@ +Upstream-Status: Submitted +Signed-off-by: Ross Burton Ross On 14 July 2017 at 18:19, Otavio Salvador wrote:

[OE-core] [PATCH] valgrind: fix ptest compilation for PowerPC

Signed-off-by: Ross Burton --- .../valgrind/valgrind/ppc-headers.patch| 87 ++ meta/recipes-devtools/valgrind/valgrind_3.13.0.bb | 1 + 2 files changed, 88 insertions(+) create mode 100644 meta/recipes-devtools/valgrind/valgrind/ppc-headers.patch diff --git a/m

[OE-core] ✗ patchtest: failure for valgrind: fix ptest compilation for PowerPC

== Series Details == Series: valgrind: fix ptest compilation for PowerPC Revision: 1 URL : https://patchwork.openembedded.org/series/7752/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been exec

[OE-core] [oe-core][PATCH 1/1][V2] valgrind: allow version 3.12 to build under gcc7

Building for powerpc64 fails because of erroneous assertions that register r2 is clobbered. This has been fixed in version 3.13. Signed-off-by: Joe Slater --- .../valgrind/valgrind/wait-for-3.13.patch | 40 ++ meta/recipes-devtools/valgrind/valgrind_3.12.0.bb | 1

Re: [OE-core] [oe-core][PATCH 1/1][V2] valgrind: allow version 3.12 to build under gcc7

There's an outstanding patch for 3.13 upgrade which was failing to ptest build. I gave up waiting for the submitter to fix it and backported the fix myself earlier, it's currently queued for master. Ross On 14 July 2017 at 21:02, Joe Slater wrote: > Building for powerpc64 fails because of erron