Re: do_rootfs: Taskhash mismatch due to BUILDNAME containing automatic date

Konrad Weihmann <kweihmann@...>


according to my understanding BUILDNAME should not be used like that since f85f1ef24e59c0c058f96f0dfa82e50969fd580b in bitbake.

The variable should contain only references to other automatically determined variables (default = ds.setVar("BUILDNAME", "${DATE}${TIME}")

Judging from that if you would set 'BUILDNAME = "my_Image_0.0.1_${DATE}"' the warning likely will go away.

Please keep in mind that these inline functions (esp in early stages of the parsing process, like machine.conf) are not expanded.
Which explains the seen behavior.

On 17.12.21 11:35, Jesper.Ahman@... wrote:
In my machine config, I have set buildname using:
BUILDNAME = "my_Image_0.0.1_${@time.strftime('%Y%m%d',time.gmtime())}"
In order to get a timestamp (date) in each build name.
Although, this causes some error messages when building the rootfs:
/ERROR: When reparsing /home/buildserver/fsl/sources/meta-freescale-distro/recipes-fsl/images/, the basehash value changed from 6b1226a9fe10f08dd4f2fe634944a53cf03f7699a8553a9cc346c097027b24e to cbd5de79b73a1bc4dd02024bafd1e5c29d4baa8f43617c37eb8f5fc57ed738ed. The metadata is not deterministic and this needs to be fixed./
/ERROR: The following commands may help:/
/ERROR: $ bitbake fsl-image-multimedia-full -cdo_rootfs -Snone/
/ERROR: Then:/
/ERROR: $ bitbake fsl-image-multimedia-full -cdo_rootfs -Sprintdiff/
I ran the suggested commands and found the following:
/Task fsl-image-multimedia-full:do_rootfs couldn't be used from the cache because:/
/  We need hash 066153e1a8d8ad0e8025f6409dbac96c277e6300541356b077f1823f195ef19c, closest matching task was 040147cd35d17688668c7435633fd8ff25d8cf7425a93d35efdd7799a47bdc85/
/  basehash changed from cbd5de79b73a1bc4dd02024bafd1e5c29d4baa8f43617c37eb8f5fc57ed738ed to 61b1226a9fe10f08dd4f2fe634944a53cf03f7699a8553a9cc346c097027b24e/
/  Variable BUILDNAME value changed from 'my_Image_0.0.1_20211214' to 'my_Image_0.0.1_${@time.strftime('%Y%m%d',time.gmtime())}'
So when /${@time.strftime('%Y%m%d',time.gmtime())}' /is converted to the actual date, it messes with Yocto.
The build succeeds anyway, but it's quite annoying having a load of error messages on each build.
How can these errors be avoided?
I found in the Yocto FAQ:
/This is often something time-related e.g. a timestamp which is calculated every time an expression is expanded. The solution is to ensure the value is calculated once per build and then the expression expands to the same value for the duration of the build.
/Which sounds somewhat right, but the issue here is not that the value is changed due to recalculation (the date rarely changes during a build) but the expansion of the expression itself (from Pyhton code into its result).
Running Yocto Dunfell.

Join to automatically receive all group messages.