poky: eaa5df34af42b6a37f6506847d0f3ef6ba0d298a meta-intel: e0d6134ed2e2687ff9f2ee77701666447842bf33 crownbay image: http://autobuilder03.jf.intel.com/pub/nightly-meta-intel/20130703-1/machines/crownbay-noemgd/core-image-sato-sdk-crownbay-noemgd.hddimg SUMMARY Usually the version (date) of the BSP is displayed in the /etc/version file. For this build, no version is displayed. Tested with crownbay-noemgd and fri2 core-image-sato-sdk images. STEPS TO REPRODUCE Install the image to the hardware device. boot it and check the version in /etc/version file. root@crownbay-noemgd:/# cat /etc/version root@crownbay-noemgd:/#
Reproduced with qemux86 as well. This would appear to be a core issue.
Just checked, this worked in dylan, so it's a regression in master. I suspect that it has something to do with the recent bitbake refactoring since bitbake is setting a value for BUILDNAME if none is set in the metadata. Interestingly, buildhistory includes ${BUILDNAME} in its commit messages and seems to be getting the value correctly, so I wonder if it's just an issue of the scoping of the datastore in which the value is being set.
Another data point, I added a bb.note in the anonymous python of rootfs_rpm to bring BUILDNAME and it is showing blank, but as you note it does work buildhistory, I am not sure how the scoping works.
Quick Observation: This Looks like a problem with the bitbake-worker split. We need to ensure that BUILDNAME gets set in the worker contexts. In _start_worker() in runqueue.py we probably need to transfer that variable
Fix merged to master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e63c5775732055a32b417c01fb68711f33ff4ac3 Note in case it is unclear, this was a regression in master; released versions are not affected.
tested with NUC.