All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Reyna, David" <david.reyna@windriver.com>
Cc: "toaster@yoctoproject.org" <toaster@yoctoproject.org>
Subject: Re: Design - Cancelling builds
Date: Thu, 03 Sep 2015 17:44:30 +0100	[thread overview]
Message-ID: <1441298670.24871.125.camel@linuxfoundation.org> (raw)
In-Reply-To: <5E53D14CE4667A45B9A06760DE5D13D0826580BA@ALA-MBA.corp.ad.wrs.com>

On Thu, 2015-09-03 at 16:11 +0000, Reyna, David wrote:
> The thing is that we have all done exactly that at one time or another
> to stop an errant build, however Bitbake explicitly advises against
> that. The reason is that it is possible that a given task could be
> broken at a state that cannot be recovered from in a subsequent
> build.  
>
> And while that failure state has never been encountered in my
> experience, it is always possible given how fancy bitbake is getting
> around parallel builds and state management, and the actions to
> recover from such a state would probably not be doable from Toaster
> and would require the intervention of the system manager.

Generally bitbake itself is comparatively safe however we have no
guarantees about the underlying build systems in the individual pieces
of software though.

One pathologically bad case is when we run out of disk space, that
usually breaks build directories to the point they're unusable,
depending on where/when it happens. The same thing could happen when
killing builds although the risk is smaller.

Cheers,

Richard




      reply	other threads:[~2015-09-03 16:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-01 12:47 Design - Cancelling builds Barros Pena, Belen
2015-09-02 14:31 ` Reyna, David
2015-09-02 14:37   ` Barros Pena, Belen
2015-09-03 11:23     ` Barros Pena, Belen
2015-09-03 13:14       ` sujith h
2015-09-03 16:11         ` Reyna, David
2015-09-03 16:44           ` 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=1441298670.24871.125.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=david.reyna@windriver.com \
    --cc=toaster@yoctoproject.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.