This is a suggestion for improving the clarity of how builds are named, and how those names correspond to log files. The name for a build (as reported in the BuildStarted event) and the corresponding log file location (as retrieved via the BB_CONSOLELOG bitbake variable at the time when BuildStarted occurs) are based on the same timestamp. For example, for two consecutive builds, I got the following name/path pairs: build name (from BuildStarted event) | log file (BB_CONSOLELOG when BuildStarted was fired) 20150928123720 | /home/ell/toaster-run/build/tmp/log/cooker/qemux86/20150928123720.log 20150928123726 | /home/ell/toaster-run/build/tmp/log/cooker/qemux86/20150928123726.log However, the real log locations for those two builds had the following paths: /home/ell/toaster-run/build/tmp/log/cooker/qemux86/20150928123716.log /home/ell/toaster-run/build/tmp/log/cooker/qemux86/20150928123720.log (Note that the second path actually corresponds to the path which I expected the first build to write to. This makes the situation especially confusing.) While this may be expected behaviour, it makes it difficult to marry up a build with its log file (e.g. when developing tooling) and is also misleading, as log files appear to correspond to incorrect build names. I have also been unable to figure out the real log file path (e.g. from bitbake variables or events fired during a build) to remedy this. To see the log files and how they correspond to build names: 1. Add a line to bitbake/lib/bb/cooker.py, just before line 1397: logger.info('******* Build name: %s' % self.data.getVar("BUILDNAME", True)) 2. Run a build, e.g. "bitbake zlib". 3. During the build, the output on the command line will show the build name. 4. Once the build is finished, look in the build/tmp/log/cooker/qemux86 directory (or the equivalent directory which contains the log file for the build). The log file for the build should be there. Note that this file will also contain the line printed by the log.info() call added in step (1). I intuitively expected the log file path to have the build name's timestamp + ".log" as its base name; but the log file path has a different base name, corresponding to a different timestamp (earlier than the build timestamp) + ".log".
The trouble is that bitbake.conf defines BB_CONSOLELOG as containing ${DATETIME} and this can get expanded to a different value each time the variable is read. The system does lock down DATE and TIME but only at BuildStarted time which is long after the UI comes up. One possible way of dealing with this may be to change the ?= definition of BB_CONSOLELOG as := however this means any user defined value won't work. Another may be for the UI to forcibly expand the value when it starts to use it, i.e. run a setVariable with the getVariable value. This is slightly more invasive with code changes but likely the correct thing to do. I would take a 2.0 patch to get this fixed properly rather than some of the workarounds being proposed.
I think this is now resolved in master. I will close bug 8373 once this is closed.
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=5b19b712526729e19c787fa68e0e5d8191988609
Hello, Used latest master: 839fb1893546ad58a1f5475a9e852b81afb056d6 on an Ubuntu 15.04 with latest updates. I reproduced steps from comment#1 and found some issues: Case 1) Using bitbake from command line to launch a target build (used same target zlib as on initial comment) Steps performed: a) add the line logger.info('******* Build name: %s' % self.data.getVar("BUILDNAME", True)) after line no. 1414. of bitbake/lib/bb/cooker.py b) Source the env. and build zlib: ~/poky$ source oe-init-build-env ~/poky/build$ bitbake zlib ---> NOTE: ******* Build name: 20160119152958 c) resulting logfile: ~/poky/build/tmp/log/cooker/genericx86/20160119152951.log looks fine until now. Case 2) Using toaster Steps performed: a) start toaster: ~/poky/build$ . ../bitbake/bin/toaster ... Successful start. b) Fire zlib build from ui (before that a "$ bitbake zlib -c cleansstate) c) resulting logfile: ~/poky/build/tmp/log/cooker/genericx86/build_20160119_174224.446.log Inside this log file the added logger.info(...) returned 20160119154223 my system time is: $ date Tue Jan 19 17:47:32 EET 2016 meaning "BUILDNAME" takes GMT time as value: $ TZ=GMT date Tue Jan 19 15:46:05 GMT 2016 d) run a new build in command line: $ bitbake zlib e) consult resulting log file: This time two log files resulted: ~/poky/build/tmp/log/cooker/genericx86$ ls -ltr total 96 ... -rw-rw-r-- 1 autobuilder autobuilder 24366 Jan 19 17:49 20160119154218.log -rw-rw-r-- 1 autobuilder autobuilder 22965 Jan 19 17:49 build_20160119_174854.653.log and though the BUILDNAME is the same value inside: 20160119154854 the file names differ badly. I'm not sure if i'm missing something, but i see no reason for two log files and two different naming for the same build (the difference between building in command line log naming and via toaster ui log naming) Attached are all log files following steps presented above.
Created attachment 2935 [details] files inside preserve date of creation log files. files inside preserve date of creation
The additional logfile build_20160119_174224.446.log is for use by Toaster and (I think) it is irrelevant to the bug. Note that the log files are not identical: bitbake doesn't produce a per-build log file, which is what was needed for Toaster; so our work-around was to add our own separate log file. This is why you don't get a "build_*" log file for builds initiated without toaster. There may be a case for renaming our log file "toaster_build*" to make it clearer why it's there, however.
Hi Elliot, I noticed the existence of a separate log file for Toaster. What i wanted to point out is that when a build is done from command line, two log files are created: one the usual way, ${DATETIME}.log and the other one for Toaster, build_%y%m%d_%H%M%S.%miliseconds.log I noticed a 6 minutes difference in their naming between these two logs and the base time being different (one is GMT and the other one is my time), though they are the result of the same bitbake run.
(In reply to comment #7) > I noticed the existence of a separate log file for Toaster. > What i wanted to point out is that when a build is done from command line, > two log files are created: one the usual way, ${DATETIME}.log and the other > one for Toaster, build_%y%m%d_%H%M%S.%miliseconds.log > I noticed a 6 minutes difference in their naming between these two logs and > the base time being different (one is GMT and the other one is my time), > though they are the result of the same bitbake run. I don't think there is any expectation that these stamps should match. The time toaster triggers the build is not going to be the same time that the cooker/server log is created. I therefore don't think there is an issue here and we're ok with the code as it stands.
Hello, As per comment#8, marking this as verified.