[OE-core] [PATCH] bluez5: 5.47 -> 5.48

Upgrade bluez5 form 5.47 to 5.48 Signed-off-by: Huang Qiyu --- meta/recipes-connectivity/bluez5/{bluez5_5.47.bb => bluez5_5.48.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-connectivity/bluez5/{bluez5_5.47.bb => bluez5_5.48.bb}

[OE-core] [PATCH] cairo: 1.14.10 -> 1.14.12

Upgrade cairo form 1.14.10 to 1.14.12 Signed-off-by: Huang Qiyu --- meta/recipes-graphics/cairo/{cairo_1.14.10.bb => cairo_1.14.12.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/cairo/{cairo_1.14.10.bb =>

[OE-core] [PATCH] coreutils: fix u-a for link

From: Chunrong Guo * busybox installs link to base_bindir not bindir /bin/link -> busybox * so u-a for coreutils fails: update-alternatives: Error: cannot register alternative link to /usr/bin/link since it is already registered to /bin/link Signed-off-by: Chunrong Guo

Re: [OE-core] [PATCH 0/5] fix build when len(TMPDIR) == 410

Ping. // Robert On 11/30/2017 09:45 AM, Robert Yang wrote: The following changes since commit 33418ed064fe9cff5b4803f09135a81d9170c189: runqemu: Also specialcase resolution of '.' to the file's location (2017-11-21 17:58:36 +) are available in the git repository at:

Re: [OE-core] bash: add missing build dependencies for ptest

Somehow, below change was never sent or discussed on the list - can't seem to find it. Does this mean bash always requires glibc-locale built, even if I don't use ptest or enable locale? -- Denys commit 2820a2c530018f59895fb57770caa8511d31afd4 Author: Ross Burton

Re: [OE-core] [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux

On 01/04/2018 07:13 PM, Robert Yang wrote: Hi RP, Thanks for the reply. On 01/03/2018 10:19 PM, Richard Purdie wrote: On Wed, 2018-01-03 at 21:56 +0800, Robert Yang wrote: Also, there are some things which never make sense as a multilib, the kernel is one example and I'm starting to wonder

[OE-core] [PATCH] kernel.bbclass: remove bashism in kernel_do_install

possible bashism in run.do_install line 163 (should be 'b = a'): if [ "kernel" == "kernel" ]; then Fixes "[: kernel: unexpected operator" when not using bash by default, which causes the default kernel image link to not be created. Signed-off-by: Ricardo Salveti

[OE-core] [PATCH V2 1/1] coreutils: upgrade to 8.29

* ls.c license checksum is changed, but the license remains the same. * The backported patch 0001-doc-fix-Up-field-of-realpath-usage-examples.patch is dropped. * The new version provides native manual page support, there's no need to download extra manual page from gentoo site. *

[OE-core] [PATCH V2 0/1] coreutils: upgrade to 8.29

Changes in V2: * Drop the backported patch 0001-doc-fix-Up-field-of-realpath-usage-examples. This fixes do_compile failure on opensuse. The following changes since commit 205cfd702190026e64eed9cae27c05ff62d1637e: bitbake: fetch2/__init__: Disable pseudo in runfetchcmd() (2018-01-08 08:48:54

Re: [OE-core] [PATCH 1/1] coreutils: upgrade to 8.29

On 01/05/2018 07:08 AM, Richard Purdie wrote: On Thu, 2018-01-04 at 15:35 +0800, Chen Qi wrote: * ls.c license checksum is changed, but the license remains the same. * The new version provides native manual page support, there's no need to download extra manual page from gentoo site. *

[OE-core] Issues with meson in SDK with cross-file

[Jussi Pakkanen, Nirbheek Chauhan, I know you may not be on the list; I added you to get Yocto/OE and meson upstream all on the same thread to discuss integrating the two] Hi all, Recently, we got meson added to OE-core as part of Yocto (thanks Alexander Kanavin!). That said, it doesn't yet

Re: [OE-core] [PATCH] receipes-devtools: QEMU: Bump to version 2.11.0

On Sat, Jan 6, 2018 at 2:15 AM, Richard Purdie wrote: > On Fri, 2018-01-05 at 18:18 -0800, Alistair Francis wrote: >> On Fri, Jan 5, 2018 at 4:22 PM, Richard Purdie >> wrote: >> > > Do you have an easy way to reproduce this

Re: [OE-core] Yocto vrs K.O kernel, wireguard go Boom

On Mon, Jan 8, 2018 at 4:57 PM, akuster808 wrote: > > > On 01/08/2018 08:01 AM, Bruce Ashfield wrote: > > > > On Mon, Jan 8, 2018 at 10:08 AM, akuster808 wrote: > >> Hello, >> >> Wireguard in meta-networking is failing do to compat.h issues on newer

Re: [OE-core] Yocto vrs K.O kernel, wireguard go Boom

On 01/08/2018 08:01 AM, Bruce Ashfield wrote: > > > On Mon, Jan 8, 2018 at 10:08 AM, akuster808 > wrote: > > Hello, > > Wireguard in meta-networking is failing do to compat.h issues on > newer kernels. I have updated the package

Re: [OE-core] [PATCH 2/2] icu-dev: improve reproducibility

> Hardcoded /usr/lib? > https://autobuilder.yocto.io/builders/nightly-multilib/builds/703/steps/BuildImages_2/logs/stdio yes, exactly. Will replace /usr/lib -> ${libdir} and retest with a MULTILIB build . -- ___ Openembedded-core mailing list

Re: [OE-core] Yocto vrs K.O kernel, wireguard go Boom

On Mon, Jan 8, 2018 at 10:08 AM, akuster808 wrote: > Hello, > > Wireguard in meta-networking is failing do to compat.h issues on newer > kernels. I have updated the package and it fixed my problem on 4.14 K.O > kernel. Now I build it with the Yocko 4.12 and it fails. It

[OE-core] [PATCH 8/9] libcroco: enable nativesdk builds

Signed-off-by: Ross Burton --- meta/recipes-support/libcroco/libcroco_0.6.12.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/libcroco/libcroco_0.6.12.bb b/meta/recipes-support/libcroco/libcroco_0.6.12.bb index

[OE-core] [PATCH 9/9] gettext: rationalise optional dependencies

gettext has optional dependencies on libxml2, glib, libcroco and libunistring. If they're not available then gettext will use internal copies, but it can also use system libraries. For gettext-native continue to use the internal copies to get this building sooner rather than later, but for target

[OE-core] [PATCH 5/9] native/cross: remove redundant DEPENDS_GETTEXT assignment

DEPENDS_GETTEXT defaults to gettext-native, so there's no need to set it again in these classes. Signed-off-by: Ross Burton --- meta/classes/cross.bbclass | 2 -- meta/classes/native.bbclass | 2 -- 2 files changed, 4 deletions(-) diff --git a/meta/classes/cross.bbclass

[OE-core] [PATCH 7/9] avahi: remove explicit avahi-dev RDEPENDS

These were added to the avahi-dev package back in 2011 before avahi-ui existed at all. The problem of GTK+ being pulled in via avahi-dev was finally solved with the avahi-ui split, so these explicit (and by being manually maintained, incomplete) dependencies can be removed. This also results in

[OE-core] [PATCH 6/9] m4: merge two .inc files

Now that oe-core only has one copy of m4, there's no need to maintain two inc files. Signed-off-by: Ross Burton --- meta/recipes-devtools/m4/m4-1.4.18.inc | 31 +++ meta/recipes-devtools/m4/m4.inc| 10 -- 2 files changed, 19

[OE-core] [PATCH 4/9] pango: don't wipe EXTRA_AUTORECONF

This was added in 2007 to solve unspecified build errors, but the autotools support has improved a lot since then and nothing breaks with it removed. Signed-off-by: Ross Burton --- meta/recipes-graphics/pango/pango_1.40.12.bb | 2 -- 1 file changed, 2 deletions(-) diff

[OE-core] [PATCH 1/9] psmisc: improve autopoint-enabling

Instead of globally clearing EXTRA_AUTORECONF (which by default currently contains --exclude=autopoint) use _remove to selectively remove the piece we care about. Signed-off-by: Ross Burton --- meta/recipes-extended/psmisc/psmisc.inc | 4 ++-- 1 file changed, 2

[OE-core] [PATCH 3/9] bison: remove pointless gettext-minimal-native DEPENDS

In native builds USE_NLS is set to 'no' so the gettext class will handle adding gettext-minimal-native to DEPENDS. Signed-off-by: Ross Burton --- meta/recipes-devtools/bison/bison_3.0.4.bb | 2 -- 1 file changed, 2 deletions(-) diff --git

[OE-core] [PATCH 2/9] bison: remove obsolete patch

m4.patch was added before 2005 (history isn't in git, only BitKeeper) and doesn't appear to be needed anymore. Also add a comment to clarify why acpaths is required. Signed-off-by: Ross Burton --- meta/recipes-devtools/bison/bison/m4.patch | 414

[OE-core] Yocto Project Status WW02’18

Current Dev Position: YP 2.5 M2 development Next Deadline: YP 2.5 M2 cut off of 1/15/18 SWAT team rotation: Cal -> Joshua on Jan. 5, 2018. SWAT team rotation: Joshua -> Armin on Jan. 12, 2018. https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: ·

[OE-core] Yocto vrs K.O kernel, wireguard go Boom

Hello, Wireguard in meta-networking is failing do to compat.h issues on newer kernels. I have updated the package and it fixed  my problem on 4.14 K.O kernel. Now I build it with the Yocko 4.12 and it fails. It wont fail with a 4.12 K.O kernel. The is one commit that was backported from 4.13 K.O

[OE-core] [RFC PATCH 5/6] meta/lib/oe/package_manager.py: deprecate 'exit 1' as a way to defer to first boot

'exit 1' is not optimal for two reasons: 1) Code is hard to read; it is not obvious that it means 'defer what follows to first boot'. 2) Worse, this hides actual errors in the scriptlets; there is no difference between scriptlet failing because it's intended to be run on target and scriptlet

[OE-core] [RFC PATCH 4/6] package.bbclass: add support for pkg_postinst_ontarget()

This function is a convenient and more readable shortcut for situations when the postinst code always needs to run on target. All commands that cannot be executed during cross-install and can only be run on target should go into this function. They will only be executed on first boot (if package

[OE-core] [RFC PATCH 6/6] package_rpm.bbclass: run pre/post installation scriptlets using sh -e

This allows catching errors in the scriptlets which would otherwise go unnoticed, e.g. this sequence: bogus_command proper_command would work just fine. Note that this patch needs all of the preceding patches, as otherwise running failing scriptlets with -e would defer them to first

[OE-core] [RFC PATCH 0/6] Fix first boot deferral and postinst error reporting

This patchset is aiming to fix long-standing problems with package post-installation scriptlets: 1) The way to defer them to first boot is to issue 'exit 1'. On the other hand, 'exit 1' is also the way to indicate an error in the script. The patches decouple these two things. 2) Scriptlets

[OE-core] [RFC PATCH 3/6] meta/lib/oe/rootfs.py: do not execute defer_to_first_boot when processing postinst_intercept hooks

That hook is empty, and doesn't need to be executed; it merely indicates that packages that have used it are requesting to defer their postinst scripts to first boot unconditionally. Signed-off-by: Alexander Kanavin --- meta/lib/oe/rootfs.py | 4 1 file

[OE-core] [RFC PATCH 2/6] meta/lib/oe/rootfs.py: separate first boot deferral logic into a separate function

Signed-off-by: Alexander Kanavin --- meta/lib/oe/rootfs.py | 35 +++ 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py index 754ef563abe..d3ec8a56c48 100644 ---

[OE-core] [RFC PATCH 1/6] postinst_intercepts: add a delay_to_first_boot hook

This allows postinsts scripts to explicitly request a deferral to first boot (by calling 'postinst_intercept delay_to_first_boot') instead of 'exit 1' which should be used only to indicate actual script failures. Signed-off-by: Alexander Kanavin ---

Re: [OE-core] [PATCH 2/2] image-live.bbclass: remove MLPREFIX from syslinux

Hi RP, On 01/04/2018 07:13 PM, Robert Yang wrote: Hi RP, Thanks for the reply. On 01/03/2018 10:19 PM, Richard Purdie wrote: On Wed, 2018-01-03 at 21:56 +0800, Robert Yang wrote: Also, there are some things which never make sense as a multilib, the kernel is one example and I'm starting to

Re: [OE-core] [PATCH 2/2] package.bbclass: variable to influence link style

Hi Alex I did the tests manually. But of course you're right in regard to automated testing. I'll add a test to "insane.bbclass" and send a new patch. Regards Michael -Ursprüngliche Nachricht- Von: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] Gesendet: Montag, 8.

Re: [OE-core] [PATCH 2/2] package.bbclass: variable to influence link style

On 01/08/2018 09:42 AM, Michael Blättler wrote: This commit introduces a new variable PACKAGE_DEBUG_SPLIT_LINK_STYLE which specifies the link option between debug infos and binary. If build-id is uesed as link option, the id can be defined with the BUILD_ID variable. How did you test this?

Re: [OE-core] ✗ patchtest: failure for Fixes for multilib and eSDK (rev2)

Sorry, I added the SOB and updated in the repo. // Robert On 01/08/2018 06:04 PM, Patchwork wrote: == Series Details == Series: Fixes for multilib and eSDK (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/9702/ State : failure == Summary == Thank you for submitting this

[OE-core] ✗ patchtest: failure for Fixes for multilib and eSDK (rev2)

== Series Details == Series: Fixes for multilib and eSDK (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/9702/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on

[OE-core] [PATCH 07/12] package_manager.py: reverse archs correctly

It had reversed all the archs, which mixed multilib and common archs, e.g.: "all any noarch x86_64 core2-64 qemux86_64 x86 i586 core2-32" After reversed: "core2-32 i586 x86 qemux86_64 core2-64 x86_64 noarch any all" The core2-32 has a higher priority than core2-64 after reversed which is

[OE-core] [PATCH 10/12] toolchain-scripts.bbclass: only install all MULTILIB_VARIANTS for image

Install all MULTILIB_VARIANTS to sysroot and pack them only makes sense to image recipe, so limit it to image recipe only, and it can fix: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32" $ bitbake

[OE-core] [PATCH 11/12] multilib.bbclass: deltask populate_sdk and populate_sdk_ext

The "bitbake image -cpopulate_sdk/ext" generates SDK/eSDK for all multilib variants, so "bitbake lib32-image -cpopulate_sdk/ext" is not needed, and it doesn't work well, for example: MACHINE ?= "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32"

[OE-core] [PATCH 04/12] staging.bbclass: staging_populate_sysroot_dir(): fix for multilib

Fixed: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" $ bitbake core-image-sato lib32-core-image-sato $ bitbake build-sysroots All lib32 manifests which had been built should be installed, but only a few such as

[OE-core] [PATCH 06/12] staging.bbclass: extend_recipe_sysroot(): search multilib manifest

Fixed: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32" $ bitbake lib32-wrlinux-image-glibc-small WARNING: lib32-wrlinux-image-glibc-small-1.0-r1 do_rootfs: Manifest for lib32-qemuwrapper-cross not found, searched

[OE-core] [PATCH 05/12] staging.bbclass: print searched manifest when not found

The old warning was: WARNING: lib32-wrlinux-image-glibc-small-1.0-r1 do_prepare_recipe_sysroot: Manifest /path/to/tmp/sstate-control/manifest-allarch-lib32-qemuwrapper-cross.populate_sysroot not found? The message wasn't clear enough, it searched a few manifests, but only reported the last

[OE-core] [PATCH 12/12] populate_sdk_ext.bbclass: remove the try...finally

The "sdkbasepath + '/conf/local.conf.bak" doesn't exist when "oe.copy_buildsystem.check_sstate_task_list()" fails, then os.replace() would raise FileNotFoundError, which overcomes the real error. Keep the error status makes debug easier, so remove the try..finally. Signed-off-by: Robert Yang

[OE-core] [PATCH 09/12] multilib.bbclass: extend allarch recipes

This can fix do_rootfs and depends chaos when multilib, for example ca-certificates is an allarch recipe: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32" IMAGE_INSTALL_append = " ca-certificates" $ bitbake

[OE-core] [PATCH 08/12] multilib.bbclass: remove invalid PACKAGE_INSTALL

The PACKAGE_INSTALL is only used by image recipe, the previous code had handled it in "if bb.data.inherits_class('image', d)", handle it again doesn't make any sense (there is no PACKAGE_INSTALL for non-image recipe), so remove it. Signed-off-by: Robert Yang ---

[OE-core] [PATCH 02/12] populate_sdk_ext.bbclass: fix for multilib

Fixed: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" $ bitbake -cpopulate_sdk_ext $ bitbake -ctestsdkext [snip] Standard Output: /bin/sh: 1: i686-wrsmllib32-linux-gcc: not found [snip] It was failed because no lib32

[OE-core] [PATCH 03/12] sstate.bbclass: sstate_hardcode_path(): fix for multilib

It only substituted staging_target for target recipe which didn't work for multilib, for example, postinst-useradd-lib32-polkit: * No multilib: PATH=/path/to/tmp-glibc/work/core2-64-wrs-linux/polkit/0.113-r0/recipe-sysroot-native/bin

[OE-core] [PATCH 01/12] staging.bbclass: fix for multilib

Fixed: MACHINE = "qemux86-64" MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" $ bitbake -cpopulate_sdk_ext [snip] Exception: subprocess.CalledProcessError: Command 'sed -e [snip]' [snip] Subprocess output: [snip] sed: can't read

[OE-core] [PATCH 00/12 V2] Fixes for multilib and eSDK

* V2 + Drop already merged patches + Fix RP's comments: - deltask populate_sdk and populate_sdk_ext for multilib - Drop "image.bbclass: remove depmodwrapper-cross from DEPENDS" - sstate.bbclass: sstate_hardcode_path(): fix for multilib > fix the grep command * V1 -

Re: [OE-core] [PATCH 1/2] groff_1.22.3.bb: support SOURCE_DATE_EPOCH

On Sun, 2018-01-07 at 08:57 -0800, Juro Bystricky wrote: > Patch backported from Debian: > https://sources.debian.net/src/groff/1.22.3-9/debian/patches/source-d > ate-epoch.patch/ > > Various documents contain information such as: > > %%Creator:·groff·version·1.22.3 >

Re: [OE-core] [PATCH 2/2] icu-dev: improve reproducibility

On Sun, 2018-01-07 at 08:59 -0800, Juro Bystricky wrote: > Remove all build host references from several distributed files: > Makefile.inc, icu-config, pkgdata.inc > > Signed-off-by: Juro Bystricky > --- >  meta/recipes-support/icu/icu.inc | 8 >  1 file