Add build date to image (was: error basehash value changed)

Tue Nov 19 03:02:12 AEDT 2019

On 11/17/19 7:52 PM, www wrote:
> Dear Joseph，
>
> Thank you for your reference and suggestions. "DATETIME" is not local 
> time，so I need add a new one.
> I added a new variable to get local time without reporting an error.
> The current problem is, how can I make this task compile every time 
> even without modification, and store the latest time?
> Do you have any suggestions?

I re-asked your question on the openembedded-core email list.  See 
replies to 
http://lists.openembedded.org/pipermail/openembedded-core/2019-November/289259.html

There were two answers:

1.
There's an image-buildinfo class that can inject build-specific 
information of your choosing into the image.

2.

I'd write the date into the file at image creation, via
ROOTFS_POSTPROCESS_COMMAND.

Having it in a recipe means that you either force the recipe to not be a
part of sstate cache, always rebuilding it and its dependencies (bad idea),
or accept that the date comes from a previously built cache object, which
means it will mismatch the actual image creation date.

A bit of context would help: why would you want that info in os-release?
Who would use that information and how?

For item 2, I also found:
In the Yocto Project Reference Manual, https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html
, "If you need the build date recorded in|/etc/issue*|  or anywhere else in your image...."

And use a recipe like:
  add_build_time_to_etc() {
         date >> ${IMAGE_ROOTFS}/etc/image-build-date
  }
  ROOTFS_POSTPROCESS_COMMAND += "add_build_time_to_etc; "

However, I have not tested this.

Also I don't fully understand this use case.  Maybe there is a better way to do what you need.  Why do you need the driver build date?  Is it to learn how old your driver is?  Most projects use driver versions for that purpose (which is in the driver's /etc/os-release file), and then your can look up that driver version on a list.  For OpenBMC, we use https://github.com/openbmc/docs/blob/master/release/release-notes.md

Please note that adding the build date to the driver image breaks reproducible builds.  Reproducible builds are desired to support the use case of digitally signing the firmware image.  Can you use an alternative date?  Instead of using your build host's current date, can you use the date of the most recent commit the source was build from?

- Joseph

>
> thanks，
> Byron
>
>
> At 2019-11-17 05:50:38, "Joseph Reynolds" <jrey at linux.ibm.com> wrote:
> >Byron,
> >
> >What modification did you put into the os-release recipe?  It would help 
> >us help you if you put that in your email.
> >
> >
> >Are you adding the build date to the generated os-release file?  If so, 
> >be aware that might cause the issues with the shared state cache you are 
> >experiencing.  Also be aware this practice wrecks reproducible builds.
> >
> >A better way to get the same effect might be to create a git tag with 
> >the information you want to appear in the generated os-release file.  
> >When you buld with this tag is then picked up by the OpenBMC 
> >meta-phosphor os-release.bbappend (via `git describe`) and included in 
> >the genersted os-release file as the BUILD_ID.  See:
> >https://github.com/ibm-openbmc/openbmc/blob/d1c59b7a36c10c18838c07af10b18080174cd61d/meta-phosphor/recipes-core/os-release/os-release.bbappend
> >(But I have not tried that.)
> >
> >A way to work around the hash change is to add a line to your recipe 
> >like: PR[vardepsxeclude]="DATETIME"
> >As suggested by: 
> >https://forums.openpli.org/topic/41447-how-to-get-rid-of-taskhash-mismatch/
> >
> >
> >My apologies for top posting -- my email reader was not quoting the 
> >message properly, so I cut/pasted it below.
> >
> >- Joseph
> >
> >
> >On 11/13/19 1:38 AM, www wrote:
> >
> >When I modify the os-release file in my yocto project, it appear some 
> >error, and how can I solve it ? Who can give me some help or advice? 
> >Thank you！
> >I execute the recommended command on the console and it didn't work.
> >
> >ERROR: os-release-1.0-r0 do_compile: Taskhash mismatch 
> >ce133f0458608e03aa55224df28156e523e54903115efbbcd62946f84a867201 versus 
> >7269881f0eb1759ed420a2db4c04fb477cd8c1288bc5f82df5c8161bb926ea1f 
> >for  /home/temp/xxx/wsp/obmc-source/entity_xxx/meta/recipes-core/os-release/os-release.bb.do_compile
> >ERROR: Taskhash mismatch 
> >ce133f0458608e03aa55224df28156e523e54903115efbbcd62946f84a867201 versus 
> >7269881f0eb1759ed420a2db4c04fb477cd8c1288bc5f82df5c8161bb926ea1f 
> >for /home/temp/xxx/wsp/obmc-source/entity_xxx/meta/recipes-core/os-release/os-release.bb.do_compile
> >ERROR: When reparsing 
> >/home/temp/xxx/wsp/obmc-source/entity_xxx/meta/recipes-core/os-release/os-release.bb.do_compile, the 
> >basehash value changed from 
> >99a42a1a3b1a151de604267b159558ecaf1031a3bec8917df132c81302e729a5 to 
> >4f3288a8763e2e1af78e4b3cdd9c0c0ccb3b0d5c78a3073c188b22200df2a9b0. The 
> >metadata is not deterministic and this needs to be fixed.
> >ERROR: The following commands may help:
> >ERROR: $ bitbake os-release -cdo_compile -Snone
> >ERROR: Then:
> >ERROR: $ bitbake os-release -cdo_compile -Sprintdiff
> >
> >ERROR: When 
> >reparsing /home/temp/xxx/wsp/obmc-source/entity_xxx/meta/recipes-core/os-release/os-release.bb.do_compile, the 
> >basehash value changed from 
> >99a42a1a3b1a151de604267b159558ecaf1031a3bec8917df132c81302e729a5 to 
> >47c30012daa6aa77be09a93fe21e66995361ef26b4487111005617db8cb4de59. The 
> >metadata is not deterministic and this needs to be fixed.
> >ERROR: The following commands may help:
> >ERROR: $ bitbake os-release -cdo_compile -Snone
> >ERROR: Then:
> >ERROR: $ bitbake os-release -cdo_compile -Sprintdiff
> >
> >thanks,
> >Byron
>
>