On 01/05/2015 06:59 AM, Barros Pena, Belen wrote:
On 28/12/2014 00:18, "William Mills" <wmi...@ti.com> 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
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
