All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Lauren Post <Lauren.Post@freescale.com>
Cc: "openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: Multiple issues building from dizzy or master
Date: Thu, 09 Oct 2014 17:07:26 +0100	[thread overview]
Message-ID: <1412870846.871.12.camel@ted> (raw)
In-Reply-To: <dd407026864c45e6b6fa6f6071469a83@CY1PR0301MB0700.namprd03.prod.outlook.com>

On Thu, 2014-10-09 at 15:50 +0000, Lauren Post wrote:
> I've narrowed down that 1 or 2 updates on poky from 9/16 are causing my problems.     If I revert only these 2 commits my build problems are resolved.
> 
> In our build script on Jenkins we always build kernel, then uboot with a force deploy then our image then we build the image.  I see the errors when we build the  image.  I believe the force deploy might be part of the problem.  We do that so in case of dirty builds we always guarantee the kernel and uboot in the images directory (although I hit this with clean builds every time).  On local machine if I only build image I never see the problem, only when I build locally with our build script.
> 
> This gcc revision I believe is causing the db and gcc runtime issues.
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dizzy&id=14ace86d508a5bdbb8139ce6af09de4d89b44595 
> 
> I also think this poky revision might be causing the fetch/unpack
> issues.  In this issue we fetch works based on log output, unpack
> fails and when I look at downloads I see the <package>.lock in the
> downloads directory.  Happens randomly on many components.  I'm doing
> a build with only gcc patch above to confirm if the unpack failures
> come back without this commit below reverted.
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dizzy&id=7d80f8e9468253496a7097685aac8f468940a9c5

Do you have a link to the full error logs of the issue you're seeing? I
doubt this second commit would cause issues. It only affects the output
of bitbake -e when variable history tracking is enabled.

The first patch fixed several different problems but is is possible you
have a different race issue in your toolchain bootstrap process. Its
hard for me to comment without seeing the errors or knowning which
layers are involved.

Cheers,

Richard



      parent reply	other threads:[~2014-10-09 16:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07 15:24 Multiple issues building from dizzy or master Lauren Post
2014-10-07 16:21 ` Mark Hatle
2014-10-07 17:30 ` Martin Jansa
2014-10-08 12:51 ` Lauren Post
2014-10-09 15:50 ` Lauren Post
2014-10-09 15:57   ` Burton, Ross
2014-10-09 16:07   ` Richard Purdie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1412870846.871.12.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Lauren.Post@freescale.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.