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


Jesper Åhman
 

Hello and thank you for your reply.

according to my understanding BUILDNAME should not be used like that since f85f1ef24e59c0c058f96f0dfa82e50969fd580b in bitbake.
That explains why the same approach works in an older Yocto project that I have for another machine.

Judging from that if you would set 'BUILDNAME = "my_Image_0.0.1_${DATE}"' the warning likely will go away.
Unfortunately, that did not make any difference. The same error is still there.

There must be some way of doing this, right?
Or are there some other approach available, to do about the same thing?
I mainly want to set /etc/version to something useful.

Best regards,


-----Ursprungligt meddelande-----
Från: Konrad Weihmann <kweihmann@...>
Skickat: den 17 december 2021 12:19
Till: Jesper Åhman <jesper.ahman@...>; yocto@...
Ämne: Re: [yocto] do_rootfs: Taskhash mismatch due to BUILDNAME containing automatic date

Hi,

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:
Hello,

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
/fsl-image-multimedia-full.bb:do_rootfs,
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 yocto@lists.yoctoproject.org to automatically receive all group messages.