From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dan.rpsys.net (dan.rpsys.net [93.97.175.187]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 50EB5E01835 for ; Wed, 13 Nov 2013 06:45:20 -0800 (PST) Received: from localhost (dan.rpsys.net [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id rADEiHtP029308; Wed, 13 Nov 2013 14:45:06 GMT X-Virus-Scanned: Debian amavisd-new at dan.rpsys.net Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k9Q2h8nK6cxN; Wed, 13 Nov 2013 14:45:06 +0000 (GMT) Received: from [192.168.3.10] (rpvlan0 [192.168.3.10]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id rADEj3rQ029326 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 13 Nov 2013 14:45:05 GMT Message-ID: <1384353900.6460.90.camel@ted> From: Richard Purdie To: "Barros Pena, Belen" Date: Wed, 13 Nov 2013 14:45:00 +0000 In-Reply-To: References: X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Cc: "toaster@yoctoproject.org" Subject: Re: [RFC] Task classification changes (was [noexec] = "1") X-BeenThere: toaster@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Web based interface for BitBake List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:45:22 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2013-11-13 at 13:57 +0000, Barros Pena, Belen wrote: > On 13/11/2013 12:56, "Richard Purdie" > 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