All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Barros Pena, Belen" <belen.barros.pena@intel.com>
Cc: "toaster@yoctoproject.org" <toaster@yoctoproject.org>
Subject: Re: [RFC] Task classification changes (was [noexec] = "1")
Date: Wed, 13 Nov 2013 14:45:00 +0000	[thread overview]
Message-ID: <1384353900.6460.90.camel@ted> (raw)
In-Reply-To: <CEA92B45.37433%belen.barros.pena@intel.com>

On Wed, 2013-11-13 at 13:57 +0000, Barros Pena, Belen wrote:
> On 13/11/2013 12:56, "Richard Purdie" <richard.purdie@linuxfoundation.org>
> wrote:
> 
> >On Wed, 2013-11-13 at 11:48 +0000, Barros Pena, Belen wrote:
> >> * prebuilt (these are what we now call 'existing' tasks, i.e, tasks for
> >> which a stamp file was found)
> >
> >Just for completeness, where you find a stamp file you can tell it if
> >was from sstate or not since in the sstate case, it will end with
> >_setscene. That may be useful information to reflect.
> 
> Didn't know that was the case. Thanks for bringing it up.
> 
> Design includes the ability to search for tasks in other builds with the
> same signature (i.e. the tasks that might have generated the stamp file).
> You can see the design here:
> 
> http://www.yoctoproject.org/toaster/task-details-prebuilt-existing.html
> 
> That list will effectively disclose if the stamp file was generated by a
> task that reused an sstate object. If we need to make this information
> more prominent, we can find ways to do so. But since the design changes
> suggested effectively conceal the existence of setscene tasks as stand
> alone tasks, there is probably no point.
> 
> >
> >FWIW your analysis looks good although I haven't spent time looking at
> >it in detail.
> >It does make sense to manipulate the data before
> >presenting it in the UI, the fact it doesn't map 1:1 with what Bitbake
> >does is probably a good thing.
> 
> It is a good thing as long as we present a coherent story. There is one
> coherence crack in our story I don't know how to solve though: the fact
> that warning messages generated by failed setscene tasks (which will be
> shown in Toaster) explicitly mention setscene tasks and their order
> number, while the information shown in Toaster does not mention setscene
> tasks (or their order number) anywhere.
> 
> Any suggestions on how to fix this glitch would be very welcome. For
> example, could we change the content of the BitBake warnings?

We can. I'd also note that setscene task failure should be an extremely
rare event. Rare enough that having a visible warning is good as they
shouldn't happen and if they do, something quite bad happened.

Cheers,

Richard



      reply	other threads:[~2013-11-13 14:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 17:54 [noexec] = "1" Barros Pena, Belen
2013-11-11 18:13 ` Richard Purdie
2013-11-12 10:25   ` Barros Pena, Belen
2013-11-13 11:48     ` [RFC] Task classification changes (was [noexec] = "1") Barros Pena, Belen
2013-11-13 12:56       ` Richard Purdie
2013-11-13 13:57         ` Barros Pena, Belen
2013-11-13 14:45           ` 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=1384353900.6460.90.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=belen.barros.pena@intel.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.