From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id E5891E0182F for ; Wed, 13 Nov 2013 05:58:08 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 13 Nov 2013 05:54:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.93,692,1378882800"; d="scan'208";a="426903852" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 13 Nov 2013 05:58:07 -0800 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.197]) by IRSMSX101.ger.corp.intel.com ([163.33.3.153]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 13:58:04 +0000 From: "Barros Pena, Belen" To: "toaster@yoctoproject.org" Thread-Topic: [Toaster] [RFC] Task classification changes (was [noexec] = "1") Thread-Index: AQHO4GZRhemRF1FmYUq3LQdbF8icsZojHp6AgAAROQA= Date: Wed, 13 Nov 2013 13:57:54 +0000 Message-ID: In-Reply-To: <1384347363.6460.88.camel@ted> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.237.224.30] MIME-Version: 1.0 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 13:58:12 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <5EAB2C5DAA94914FBC15B92AE45486D4@intel.com> Content-Transfer-Encoding: quoted-printable 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? > >Cheers, > >Richard >