Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

2019-08-16 Thread Khem Raj
I think it’s ok to have it in Glibc/localedef not all distros have this version of util Linux yet and perhaps we should start creating a buildtools tarballs which is a prerequisite for building OE and collect these dependencies in there instead Of sticking them in unusual places On Fri, Aug 16,

Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

2019-08-16 Thread Jason Wessel
On 8/16/19 4:50 PM, richard.pur...@linuxfoundation.org wrote: On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote: On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie wrote: This was discussed on IRC. We really really want to avoid that as a dependency if we care about build performance. Its really

Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

2019-08-16 Thread richard . purdie
On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote: > On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie > wrote: > > This was discussed on IRC. We really really want to avoid that as a > > dependency if we care about build performance. Its really easy to > > just > > add that in but the implications

Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

2019-08-16 Thread Mark Hatle
On 8/16/19 4:29 PM, Khem Raj wrote: > On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie > wrote: >> >> On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote: >>> On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel < >>> jason.wes...@windriver.com> wrote: The hard link resolver that is built into localedef

Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

2019-08-16 Thread Khem Raj
On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie wrote: > > On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote: > > On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel < > > jason.wes...@windriver.com> wrote: > > > The hard link resolver that is built into localedef cannot be run > > > in > > > parallel.

Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

2019-08-16 Thread Richard Purdie
On Fri, 2019-08-16 at 14:22 -0700, Khem Raj wrote: > On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel < > jason.wes...@windriver.com> wrote: > > The hard link resolver that is built into localedef cannot be run > > in > > parallel. It will search sibling directories (which are be > > processed > > in

Re: [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

2019-08-16 Thread Khem Raj
On Fri, Aug 16, 2019 at 2:06 PM Jason Wessel wrote: > > The hard link resolver that is built into localedef cannot be run in > parallel. It will search sibling directories (which are be processed > in parallel) and perform a creation of a .tmp file and remove the > original and move the .tmp

[OE-core] [RFC PATCH 2/2] libc-package.bbclass: Split locale hard link processing into two parts

2019-08-16 Thread Jason Wessel
The locale-processing in cross-localedef was proven to be unsafe to run in parallel due to the way it tried to make hard links to files that could disappear before the link operation was completed. To avoid corruption of the pseudo database, and create a deterministically generated link tree, the

[OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

2019-08-16 Thread Jason Wessel
The hard link resolver that is built into localedef cannot be run in parallel. It will search sibling directories (which are be processed in parallel) and perform a creation of a .tmp file and remove the original and move the .tmp file in. The problem is that if a probe occurs a hard link can be

Re: [OE-core] [PATCH 6/6] xz: Remove GPLv3 license checksum

2019-08-16 Thread Khem Raj
On Fri, Aug 16, 2019 at 12:46 PM Wes Lindauer wrote: > > Although xz has some files that are GPLv3 licensed, none of them get > packaged up, and therefore none of it ends up in the final rootfs. Since > there is no GPLv3 code in the final image, we don't want to include it > when we collect

[OE-core] ✗ patchtest: failure for "iw: Fix license field to BSD-2..." and 5 more

2019-08-16 Thread Patchwork
== Series Details == Series: "iw: Fix license field to BSD-2..." and 5 more Revision: 1 URL : https://patchwork.openembedded.org/series/19323/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been

[OE-core] [PATCH 6/6] xz: Remove GPLv3 license checksum

2019-08-16 Thread Wes Lindauer
Although xz has some files that are GPLv3 licensed, none of them get packaged up, and therefore none of it ends up in the final rootfs. Since there is no GPLv3 code in the final image, we don't want to include it when we collect licenses, as that would give the incorrect impression that the image

[OE-core] [PATCH 3/6] shadow: Fix BSD license file checksum

2019-08-16 Thread Wes Lindauer
BSD license files must include the copyright notice. --- meta/recipes-extended/shadow/shadow.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-extended/shadow/shadow.inc b/meta/recipes-extended/shadow/shadow.inc index 7f82d20826..6d9e300739 100644 ---

[OE-core] [PATCH 5/6] libunwind: Fix MIT license file checksum

2019-08-16 Thread Wes Lindauer
MIT license files must include the copyright notice. --- meta/recipes-support/libunwind/libunwind.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/libunwind/libunwind.inc b/meta/recipes-support/libunwind/libunwind.inc index 36851d07ed..5726589661

[OE-core] [PATCH 4/6] sudo: Fix BSD license file checksum

2019-08-16 Thread Wes Lindauer
BSD license files must include the copyright notice. --- meta/recipes-extended/sudo/sudo.inc | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/meta/recipes-extended/sudo/sudo.inc b/meta/recipes-extended/sudo/sudo.inc index 90f2039bb8..15075bcefd 100644 ---

[OE-core] [PATCH 2/6] openssh: Update LICENSE field with missing values

2019-08-16 Thread Wes Lindauer
The LICENSE file states that some code is licensed under BSD, some under ISC, and some under MIT. The LICENSE field should reflect all of these. --- meta/recipes-connectivity/openssh/openssh_8.0p1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[OE-core] [PATCH 1/6] iw: Fix license field to BSD-2-Clause

2019-08-16 Thread Wes Lindauer
Using just "BSD" license implies BSD-3-Clause and this recipe appears to be closer to a BSD-2-Clause. --- meta/recipes-connectivity/iw/iw_5.0.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/iw/iw_5.0.1.bb

[OE-core] ✗ patchtest: failure for "gcc: Search in OE specific tar..." and 1 more

2019-08-16 Thread Patchwork
== Series Details == Series: "gcc: Search in OE specific tar..." and 1 more Revision: 1 URL : https://patchwork.openembedded.org/series/19322/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been

Re: [OE-core] [warrior][PATCH] bitbake.conf: add git-lfs to HOSTTOOLS_NONFATAL

2019-08-16 Thread Andre McCurdy
On Thu, Aug 15, 2019 at 8:45 PM akuster808 wrote: > On 8/15/19 2:31 PM, Andre McCurdy wrote: > > On Thu, Aug 15, 2019 at 2:09 PM Richard Purdie > > wrote: > >> On Thu, 2019-08-15 at 09:23 +0200, Martin Jansa wrote: > >>> NAK > >>> > >>> Yes, the first part was merged in warrior and is correct. >

Re: [OE-core] [PATCH 2/5] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively

2019-08-16 Thread Khem Raj
Thanks Martin to fix a bunch of QA issues in meta-openembedded surfaced after this change in core, there still are some left if someone wants to take a look at it https://errors.yoctoproject.org/Errors/Build/87032/ On Tue, Aug 13, 2019 at 11:24 AM Alexander Kanavin wrote: > > Recursive RDEPENDS

[OE-core] [PATCH V3 2/2] libffi: Upgrade to 3.3-rc0

2019-08-16 Thread Khem Raj
libffi 3.1 release has been a bit aged and new architectures, compilers have since been come on stage to compile it, we have been carrying patches, but its better to use the latest 3.3 rc0 which has lot of these issues handled and is in good shape. Use 3.2.1+3.3-rc0 for PV to keep room for

[OE-core] [PATCH 1/2] gcc: Search in OE specific target gcclibdir

2019-08-16 Thread Khem Raj
We put gcclibir to be /usr/lib//... and not default usr/lib/gcc/, therefore make the include search path also look into this directory, this should help in finding gcc headers like omp.h Signed-off-by: Khem Raj Cc: Martin Jansa --- .../0021-Ensure-target-gcc-headers-can-be-included.patch | 8

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

2019-08-16 Thread Patchwork
== Series Details == Series: YOCTO #12937 - Consistent naming scheme for deployed artifacts Revision: 1 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. Several

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-16 Thread Martin Jansa
On Fri, Aug 16, 2019 at 04:54:48PM +0100, richard.pur...@linuxfoundation.org wrote: > On Fri, 2019-08-16 at 17:00 +0200, Martin Jansa wrote: > > > Will try to bump BB_NUMBER_THREADS from 8 to 72. > > > > I've tried to remove icecc.bbclass inherit (because it does things > > while parsing and RP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [OE-core] [PATCH 3/3] qemuriscv64: Specify the firmware as a bios instead of kernel

2019-08-16 Thread Alistair Francis
On Thu, Aug 15, 2019 at 11:40 PM Jacob Kroon wrote: > > Hi, > > On 8/15/19 11:31 PM, Alistair Francis wrote: > > Signed-off-by: Alistair Francis > > --- > > meta/conf/machine/include/riscv/qemuriscv.inc | 2 +- > > meta/conf/machine/qemuriscv64.conf| 2 -- > > 2 files changed, 1

[OE-core] [PATCH 2/2] package: Fix race between do_package and do_packagedata

2019-08-16 Thread Richard Purdie
do_package has PKGDESTWORK as a cleandir and do_packagedata has it as an sstate-input dir. This means do_package wipes out the directory at both do_package and do_package_setscene. do_package_setscene and do_packagedata_setscene can run in parallel when installing from sstate which means they

[OE-core] [PATCH 1/2] yocto-check-layer: Ensure we use OEBasicHash as the signature handler

2019-08-16 Thread Richard Purdie
The layer checks are designed to work with OEBasicHash so ensure that handler is in use rather than the new hash equivalency one as an example. Signed-off-by: Richard Purdie --- scripts/lib/checklayer/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-16 Thread richard . purdie
On Fri, 2019-08-16 at 17:00 +0200, Martin Jansa wrote: > > Will try to bump BB_NUMBER_THREADS from 8 to 72. > > I've tried to remove icecc.bbclass inherit (because it does things > while parsing and RP probably doesn't have it inherited), but that > didn't save much time. > > All 3 tests were

Re: [OE-core] [PATCH V2] gcc-runtime: Move content from gcclibdir into libdir

2019-08-16 Thread Khem Raj
On Fri, Aug 16, 2019 at 5:00 AM Martin Jansa wrote: > > Hi, > > I have an app which includes omp.h from gomp, it used to find it without > adding any -I for that (with just -fopenmp to enable openmp). > > Now the header file is included in RSS: >

Re: [OE-core] [bitbake-devel] RFC: exposing information about the SRC_URI(s)/branch via buildhistory (or similar mechanism)

2019-08-16 Thread chris.laplante--- via Openembedded-core
> > I think this supports my point about being more interested in patches > > allowing people to extend/customise buildhistory than just adding X. > > > > Whilst we want to have good defaults, there are always going to be > > niche cases for people wanting to extend it... > > > Agreed. Then we

Re: [OE-core] [PATCH V2] libffi: Upgrade to 3.3-rc0

2019-08-16 Thread Khem Raj
On Fri, Aug 16, 2019 at 7:48 AM Richard Purdie wrote: > > On Wed, 2019-08-14 at 16:00 -0700, Khem Raj wrote: > > libffi 3.1 release has been a bit aged and new architectures, > > compilers > > have since been come on stage to compile it, we have been carrying > > patches, but its better to use

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-16 Thread Martin Jansa
> Will try to bump BB_NUMBER_THREADS from 8 to 72. I've tried to remove icecc.bbclass inherit (because it does things while parsing and RP probably doesn't have it inherited), but that didn't save much time. All 3 tests were with bitbake 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7 94m19.081s 8

Re: [OE-core] [PATCH V2] libffi: Upgrade to 3.3-rc0

2019-08-16 Thread Richard Purdie
On Wed, 2019-08-14 at 16:00 -0700, Khem Raj wrote: > libffi 3.1 release has been a bit aged and new architectures, > compilers > have since been come on stage to compile it, we have been carrying > patches, but its better to use the latest 3.3 rc0 which has lot of > these > issues handled and is

[OE-core] [PATCH] ofono: update to 1.30

2019-08-16 Thread Oleksandr Kravchuk
Removed upstreamed patches. Signed-off-by: Oleksandr Kravchuk --- ...-t-overwrite-src_ofonod_DEPENDENCIES.patch | 50 --- ...Add-check-for-explicit_bzero-support.patch | 27 -- .../0001-build-Fix-a-race-condition.patch | 28 ---

Re: [OE-core] [PATCH V2] gcc-runtime: Move content from gcclibdir into libdir

2019-08-16 Thread Martin Jansa
Hi, I have an app which includes omp.h from gomp, it used to find it without adding any -I for that (with just -fopenmp to enable openmp). Now the header file is included in RSS: lib32-recipe-sysroot/usr/lib/arm-oemllib32-linux-gnueabi/9.2.0/include/omp.h but no longer found in default search

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-16 Thread Martin Jansa
On Thu, Aug 15, 2019 at 05:05:48PM +0200, Martin Jansa wrote: > On Tue, Aug 13, 2019 at 10:04:08AM +0100, Richard Purdie wrote: > > On Mon, 2019-08-12 at 20:26 +, Peter Kjellerstedt wrote: > > > Comparing that build to a corresponding do-nothing build with Thud, > > > the time difference

[OE-core] ✗ patchtest: failure for dpkg: Use less as pager (rev3)

2019-08-16 Thread Patchwork
== Series Details == Series: dpkg: Use less as pager (rev3) Revision: 3 URL : https://patchwork.openembedded.org/series/18240/ 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

[OE-core] [warrior][PATCH] dpkg: Use less as pager

2019-08-16 Thread Richard Leitner
From: Ricardo Ribalda Delgado Debian traditionaly uses /usr/bin/pager as the system pager, which is a link to the user preferred pager. This is a Debianism. Without this patch: root@qt5122:~# dpkg -l sh: pager: command not found dpkg-query: error: showing package list on pager subprocess

[OE-core] [PATCH] base.bbclass: add dependency on pseudo from do_prepare_recipe_sysroot

2019-08-16 Thread Mattias Hansson
do_prepare_recipe_sysroot may perform groupadd, which requires pseudo. However, do_prepare_recipe_sysroot does not depend on pseudo explicitly, which sometimes causes a build error when building a recipe that adds groups. This issue only occurs when executing do_prepare_recipe_sysroot for a

[OE-core] [PATCH] screen: add /etc/screenrc as global config file

2019-08-16 Thread Yi Zhao
Signed-off-by: Yi Zhao --- meta/recipes-extended/screen/screen_4.6.2.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-extended/screen/screen_4.6.2.bb b/meta/recipes-extended/screen/screen_4.6.2.bb index 24ec751..21b476d 100644 ---

Re: [OE-core] LF Community Bridge Mentorship

2019-08-16 Thread Nicolas Dechesne
hi there. just a reminder! cheers On Tue, Jul 30, 2019 at 4:46 PM Nicolas Dechesne wrote: > > Dear all, > > The Community Bridge platform was launched earlier this year by the > Linux Foundation. It’s a set of services available to LF projects to > help them build stronger ecosystems, and foster

[OE-core] Bug report: util-linux: circular dependencies occurs when enable systemd in PACKAGECONFIG

2019-08-16 Thread Hongzhi, Song
Hi, Some DISTRO_FEATURES related to systemd have been enabled in local.conf     DISTRO_FEATURES_append = " systemd"     DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"     VIRTUAL-RUNTIME_init_manager = "systemd"     VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"    

Re: [OE-core] [PATCH] core-image-sato-sdk: test image with 512M memory

2019-08-16 Thread Kang Kai
On 2019/8/12 下午4:57, Kang Kai wrote: On 2019/7/27 下午4:42, Kang Kai wrote: On 2019/7/27 上午5:40, richard.pur...@linuxfoundation.org wrote: On Fri, 2019-07-26 at 05:23 -0400, kai.k...@windriver.com wrote: From: Kai Kang When run do_testimage for core-image-sato-sdk, it fails to pass test case:

Re: [OE-core] [PATCH 3/3] qemuriscv64: Specify the firmware as a bios instead of kernel

2019-08-16 Thread Jacob Kroon
Hi, On 8/15/19 11:31 PM, Alistair Francis wrote: > Signed-off-by: Alistair Francis > --- > meta/conf/machine/include/riscv/qemuriscv.inc | 2 +- > meta/conf/machine/qemuriscv64.conf| 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) > > diff --git