Re: [meta-freescale] [meta-freescale-layer][PATCH 00/67] QorIQ SDK 2.0 patches

On Mon, 2016-07-04 at 16:35 -0300, Otavio Salvador wrote: > Hello Ting, > > On Mon, Jul 4, 2016 at 7:41 AM, wrote: > > From: Ting Liu > > > > Changes since the below commit: > > bed4f7b libimxvpuapi: use libdir from cross environment > > Please put a

[meta-freescale] Removing builds of meta-fsl-* from the autobuilder

NXP has decided to lower its contributions to the support of the project and is no longer eligible for the level of automated testing we've been making of meta-fsl-ppc and meta-fsl-arm. As such we're going to disable those builds going forward. I don't like doing that but equally this does put a

[meta-freescale] meta-fsl-ppc breaking on the autobuilder again

Hi, The move from udev to eudev queued in master-next is going to break the meta-fsl-ppc layer, again: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc/builds/661 Sadly that failure causes: https://autobuilder.yoctoproject.org/main/builders/nightly/builds/740 which blocks

Re: [meta-freescale] [meta-fsl-ppc] [PATCH] classes/u-boot: Update getVar syntax

On Thu, 2016-02-18 at 05:00 +, Ting Liu wrote: > Hello Richard, > > > -Original Message- > > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > > Sent: Wednesday, February 17, 2016 4:32 PM > > To: meta-freescale <meta-freescale@yoctopr

Re: [meta-freescale] [meta-fsl-ppc] [PATCH] classes/u-boot: Update getVar syntax

On Sat, 2016-02-06 at 13:00 +, Richard Purdie wrote: > This runs: > > sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *` > > on the layer to update the getVar usages without an expand parameter, > This ensures the layer continues to work w

[meta-freescale] [meta-fsl-ppc] [PATCH] classes/u-boot: Update getVar syntax

expand=True. Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org> --- classes/qoriq_build_64bit_kernel.bbclass | 14 +++--- recipes-bsp/u-boot/u-boot-qoriq_2015.01.bb | 6 +++--- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/c

Re: [meta-freescale] meta-fsl-* breakage on the Yocto autobuilder

On Tue, 2016-01-05 at 17:23 +, Burton, Ross wrote: > meta-fsl-ppc is still breaking the Yocto autobuilder, see for example > the errors from my latest build last night: > > http://errors.yoctoproject.org/Errors/Search/?items=10=862d702f > bb99e484631315aa44b9e46f8fc567da > > There's two

Re: [meta-freescale] Heads up on gcc 5.X issues for meta-fsl-arm and meta-fsl-ppc

On Fri, 2015-08-07 at 09:40 -0400, Trevor Woerner wrote: On 07/27/15 17:38, Richard Purdie wrote: It appears that gcc 5.x is going to cause a few issues for meta-fsl-arm and meta-fsl-ppc. Many of the remaining issues are specific to these layers. http://errors.yoctoproject.org/Errors

[meta-freescale] Heads up on gcc 5.X issues for meta-fsl-arm and meta-fsl-ppc

It appears that gcc 5.x is going to cause a few issues for meta-fsl-arm and meta-fsl-ppc. Many of the remaining issues are specific to these layers. http://errors.yoctoproject.org/Errors/Search/?items=10query=00957782f4dec7f39b79211e6a2a2bea6f14d2a0limit=50 is a complete list for one of the last

Re: [meta-freescale] meta-fsl-arm build failures

On Mon, 2014-08-25 at 10:25 -0300, Otavio Salvador wrote: On Mon, Aug 25, 2014 at 5:01 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: There are a couple of build failures with meta-fsl-arm. One is a dangling bbappend, the other is from the packagegroup changes that have just

[meta-freescale] meta-fsl-arm build failures

Hi, There are a couple of build failures with meta-fsl-arm. One is a dangling bbappend, the other is from the packagegroup changes that have just been merged where an inherit in one of the recipes needs to be moved.

[meta-freescale] meta-fsl-ppc - layer.conf issues

Hi, I noticed that there is some distro policy creeping into meta-fsl-ppc's layer.conf file, specifically: BB_DANGLINGAPPENDS_WARNONLY ?= true and BB_ENV_EXTRAWHITE := KSRC USRC The former is bad as it forces the policy for all layers. If the user is expecting dangling appends to be errors,

Re: [meta-freescale] [OE-core] [PATCH RFC 1/3] insane: Split do_package_qa into a separate task (from do_package)

On Thu, 2014-07-10 at 23:43 -0300, Otavio Salvador wrote: On Wed, Jul 9, 2014 at 5:15 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: Its possible to run the package QA checks as a separate task rather than as part of the do_package task. This offers more parallelism

Re: [meta-freescale] [OE-core] [PATCH RFC 1/3] insane: Split do_package_qa into a separate task (from do_package)

On Fri, 2014-07-11 at 09:14 -0300, Otavio Salvador wrote: When I see a RFC serie I expect people to wait some days /for comments/. I learned today those are already merged and /no comment time/ has been given. The whole RFC was not merged. The previous RFC was and when that happened,

Re: [meta-freescale] [OE-core] [PATCH RFC 1/3] insane: Split do_package_qa into a separate task (from do_package)

On Fri, 2014-07-11 at 13:46 -0300, Otavio Salvador wrote: On Fri, Jul 11, 2014 at 10:22 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2014-07-11 at 09:14 -0300, Otavio Salvador wrote: ... I would not recommend setting variables in function prepends like this, its

Re: [meta-freescale] [OE-core] [PATCH RFC 1/3] insane: Split do_package_qa into a separate task (from do_package)

On Fri, 2014-07-11 at 20:37 +0100, Burton, Ross wrote: On 11 July 2014 14:22, Richard Purdie richard.pur...@linuxfoundation.org wrote: The anonymous python fragment should be fine, it sets the data at the right level, the global recipe level rather than burying it in some task. FWIW

[meta-freescale] meta-fsl-arm build failure

I've been running tests on the autobuilder for B != S and there are some issues in the meta-fsl-arm layer: http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm/builds/91 Specifically: nightly-fsl-arm/build/meta-fsl-arm/recipes-bsp/mxsldr/mxsldr_git.bb

Re: [meta-freescale] meta-fsl-arm build failure

On Mon, 2014-03-17 at 20:14 -0300, Otavio Salvador wrote: On Mon, Mar 17, 2014 at 6:30 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I've been running tests on the autobuilder for B != S and there are some issues in the meta-fsl-arm layer: http

[meta-freescale] Autobuilder failures for fsl-ppc

So, we've had failures on the autobuilder for weeks for fsl-ppc: http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-ppc-lsb?numbuilds=25 http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-ppc?numbuilds=25 The successes are danny builds, master has not built successfully for

Re: [meta-freescale] Autobuilder failures for fsl-ppc

On Thu, 2013-05-30 at 09:54 +, Luo Zhenhua-B19537 wrote: Hello Richard, We will investigation the build error soon and plan to post the fix patch early next week. We will also paying attention to the build status timely, sorry for the frustration. Thanks, I look forward to seeing

Re: [meta-freescale] Help with redundant RPATH /usr/lib

On Tue, 2013-04-23 at 12:10 +0100, Lewis, Nick wrote: If that isn't the reason, its likely you're doing something custom to the linking command in configure.ac or Makefile.am and breaking it. Richard I have added a patch to the recipe that appears to fix the problem. Is this a

Re: [meta-freescale] Help with redundant RPATH /usr/lib

On Mon, 2013-04-22 at 14:32 +0100, Lewis, Nick wrote: I have written a very basic recipe which inherits autotools but it is failing complaining of an rpath containing an unnecessary /usr/lib Is someone able to assist me please with any pointers as to what may be causing this rpath issue and

Re: [meta-freescale] [meta-fsl-ppc master] replace tab with space character to fix warnings

On Mon, 2013-03-04 at 17:45 +0800, Zhenhua Luo wrote: fix following warnings: WARNING: Variable clean_make contains tabs, please remove these ... WARNING: Variable remove_workdir contains tabs, please remove these ... WARNING: Variable clean_builddir contains tabs, please remove these ...

Re: [meta-freescale] No recipes for mesa-dri_9.0.1.bbappend

On Wed, 2013-02-13 at 20:14 -0200, Otavio Salvador wrote: On Wed, Feb 13, 2013 at 6:59 PM, Andrei Gherzan and...@gherzan.ro wrote: Needs just a renaming. I think we could get rid of it. We ought to enforce the use of gpu libraries as providers and stop playing with mesa-dri. I am checking