From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id EF3E3E00CC7; Wed, 6 Jan 2016 03:19:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KHOP_DYNAMIC autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 KHOP_DYNAMIC Relay looks like a dynamic address Received: from dan.rpsys.net (5751f4a1.skybroadband.com [87.81.244.161]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id ED523E00948 for ; Wed, 6 Jan 2016 03:19:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u06BJ1iP018864; Wed, 6 Jan 2016 11:19:01 GMT 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 D_y_54VQ4Q-I; Wed, 6 Jan 2016 11:19:01 +0000 (GMT) Received: from hex ([192.168.3.34]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u06BIwHk018860 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 6 Jan 2016 11:18:59 GMT Message-ID: <1452079138.7598.66.camel@linuxfoundation.org> From: Richard Purdie To: "Barros Pena, Belen" , "toaster@yoctoproject.org" Date: Wed, 06 Jan 2016 11:18:58 +0000 In-Reply-To: References: X-Mailer: Evolution 3.16.5-1ubuntu3.1 Mime-Version: 1.0 Subject: Re: weird task: covered with sstate attempt 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, 06 Jan 2016 11:19:07 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2016-01-06 at 10:51 +0000, Barros Pena, Belen wrote: > While poking at the build data (as I do from time to time) I came > across a > strange thing in the linux-yocto do_shared_workdir task. It is > reported by > Toaster as 'covered' (which means that its output is already provided > by > another task in the build, in this case do_package_qa and do_build), > but > also as attempting to use shared state. Toaster said it attempted to > find > the file > > /home/yocto/master/build/sstate-cache/7d/sstate:linux-yocto:qemux86 > -poky-li > nux:4.1.15+gitAUTOINC+46bb64d605_788dfc9859:r0:qemux86:3:7de3949f0c0b > b15e7c > 8f920de3354cd7_shared_workdir.tgz > > > But didn't. You can see how the task information looks like in > Toaster in > the attached file. > > This is quite unusual: I'd never seen a covered task that attempted > to > access a shared state artifact. If the output is already provided by > another task, why attempting to use shared state at all? > > Is this expected from this task? Or is this indeed strange and > something > we should look into? > > Thanks! At some point I would like to discuss "covered" as I still think that its a misleading way of showing things in the UI, and that more generally, what is being shown isn't entirely helpful to the user. I think what that screen is trying to show is that do_package_qa came from sstate which meant that do_shared_work wasn't needed for it, however there was something else (e.g. do_deploy) which probably meant it did need to run do_shared_workdir, which it went on to run. FWIW, do_shared_workdir isn't an sstate task so it would never have an sstate object that represents it. In case the above is hard to comprehend, for the kernel, the sstate tasks are: $ bitbake virtual/kernel -e | grep SSTATETASKS= SSTATETASKS="do_package_write_ipk do_package_write_deb do_populate_lic do_package_write_rpm do_package_qa do_populate_sysroot do_packagedata do_deploy do_package" and if package_qa was ok from sstate, the other do_package_* ones probably are too. Why they're not showing in the UI? I can only guess that image doesn't use any kernel packages? That is why I'd suspect do_deploy triggered the rebuild. I have to wonder why do_populate_lic didn't show up though as it probably should have. Cheers, Richard