From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 48ECDE00815; Wed, 11 Feb 2015 10:35:21 -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=-0.9 required=5.0 tests=BAYES_00,UC_GIBBERISH_OBFU autolearn=no version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.0 UC_GIBBERISH_OBFU Multiple instances of "word VERYLONGGIBBERISH * word" Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B7BAEE003D4 for ; Wed, 11 Feb 2015 10:35:16 -0800 (PST) Received: from [192.168.1.10] (c-73-194-208-34.hsd1.nj.comcast.net [73.194.208.34]) by smtp.webfaction.com (Postfix) with ESMTP id 262B720BD385; Wed, 11 Feb 2015 18:35:15 +0000 (UTC) Message-ID: <54DBA0E1.6020608@mindchasers.com> Date: Wed, 11 Feb 2015 13:35:13 -0500 From: Bob Cochran User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Barros Pena, Belen" , William Mills , "yocto@yoctoproject.org" References: <549EFEF1.1040604@ti.com> In-Reply-To: Subject: Re: My config got stuck in the toaster X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 18:35:21 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 01/05/2015 06:59 AM, Barros Pena, Belen wrote: > On 28/12/2014 00:18, "William Mills" wrote: > >> >> On 12/27/2014 10:40 AM, Mills, William wrote: >>> OK, you are not going to believe me but I swear this really happened ... > > We do believe you :) > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6935 Looks like this was patched & closed, but I'm seeing similar behavior working with poky master (commit: 870323cac1e40). I was modifying the MACHINEOVERRIDES settings in some of the conf files. I noticed that the values weren't picked up during a build until I stopped toaster (source toaster stop). However, bitbake did seem to pick up each prepend and append modification ( =. and .=) while toaster was running (but not the change in the variable's value). In summary: i) source toaster start ii) make changes to MACHINEOVERRIDES in meta-fsl-ppc layer conf files iii) bitbake init-ifupdown iv) changes aren't accurately reflected in the build v) source toaster stop vi) bitbake init-ifupdown # all is OK Bob > > > Hopefully to be fixed soon. > > Cheers > > Belén > >>> >>> I have been playing with YP 1.7 over the break. >>> I thought I would give toaster a try so I had it running in the >>> background as I tried various builds. >>> Somehow I got into a state where changes to my conf/local.conf file >>> were being ignored. >>> I fixed it by stopping toaster. >>> >>> Here is the sequence as I remember: >>> >>> I was doing builds for qemuarm. >>> At some point I started toaster "source toaster start" >>> It could have been from a clean build dir but probably I had done a >>> couple of test builds first. >>> For qemuarm I built: >>> core-image-minimal, meta-toolchain, core-image-sato, >>> core-image-sato-sdk, world >>> I definitely poked around the toaster UI at some of those builds. >>> Next in the same build dir (and the same screen session) I edited >>> conf/local.conf to >>> MACHINE = qemux86 >>> I then did core-image-sato again >>> It built for qemuarm >>> I double check conf/* and ENV settings. >>> I rm -rf cache >>> still builds for qemuarm >>> I stopped toaster with "source toaster stop" >>> I rm -rf cache again for safe keeping >>> I tried core-image-sato again and it started building for qemux86. >>> >>> I tried to reproduce this with a clean build dir and a trivial target >>> "bitbake -c clean ed" >>> With or without toaster running it always detects the config change and >>> rebuilds the cache. >>> In the process I have now learned that removing the cache dir does not >>> cause a reparse as I expected. >>> However a config change does. >>> >>> I thought I had a theory w/ persistent bitbake process and files being >>> kept open >>> but I can't connect the dots and I can't reproduce it. >>> >> >> Actually it is easy to reproduce. >> >> The first time I tried I don't think toaster was starting as port 8000 >> was busy. I thought I had stopped the other instance but I guess not. >> >> To reproduce this I did this: >> >> yocto$ $ . poky/oe-init-build-env toasted-build >> yocto/toasted-build$ source toaster start >> yocto/toasted-build$ bitbake -c clean ed >> runs with MACHINE = "qemux86" >> yocto/toasted-build$ mcedit conf/local.conf >> change to MACHINE ??= "qemuarm" >> yocto/toasted-build$ bitbake -c clean ed >> still runs for qemux86 >> yocto/toasted-build$ source toaster stop >> yocto/toasted-build$ bitbake -c clean ed >> runs for qemuarm >> >> Am I starting toaster in the wrong way to be just an observer? >> I learned how to start toaster this way from: >> https://www.yoctoproject.org/documentation/toaster-manual-17 -> >> First link is "How to install and run Toaster locally" -> >> https://wiki.yoctoproject.org/wiki/Setting_up_a_local_instance_of_Toaster >> >> The Yocto Project Dev guide say the same thing: >> https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#exami >> ning-builds-using-toaster >> >>> Any Ideas? >>> >>> BTW: Building "world" does not look nice in toaster. It list 100s of >>> build targets instead of just "world". >>> >>> Thanks, >>> Bill >>> >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >