Thanks for sharing the patches to set U_BOOT_DATE/U_BOOT_TIME/U_BOOT_TZ.

I happened to independently work on a similar patch in the last few

Index: u-boot/Makefile
--- u-boot.orig/Makefile
+++ u-boot/Makefile
@@ -1231,10 +1231,14 @@ define filechk_version.h
        echo \#define LD_VERSION_STRING \"$$($(LD) --version | head -n 1)\"; )
+ifeq ($(BUILD_DATE),)
+  BUILD_DATE = $(shell date)
 define filechk_timestamp.h
-       (LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
-       LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
-       LC_ALL=C date +'#define U_BOOT_TZ "%z"')
+       (LC_ALL=C date --utc --date "$(BUILD_DATE)" +'#define U_BOOT_DATE "%b 
%d %C%y"'; \
+       LC_ALL=C date --utc --date "$(BUILD_DATE)" +'#define U_BOOT_TIME "%T"'; 
+       LC_ALL=C date --utc --date "$(BUILD_DATE)" +'#define U_BOOT_TZ "%z"')
 $(version_h): include/config/uboot.release FORCE

This allows us to set a specific timestamp by passing BUILD_DATE (or
whatever standardized variable name is agreed upon) in debian/rules
taken from the debian/changelog entry.

I do see some value in there being a time-based string there, as it's
displayed to the user at boot and can be useful for troubleshooting what
build they're booting...

I'll likely include this patch or soemthing like it in the next u-boot
uploads to Debian; though it'd be great to get it merged upstream.

Interestingly, u-boot kind of flys under the reproducible builds radar
as the amd64 build doesn't include any binaries impacted by the
datestrings. I've been making mumblings on irc of setting up some armhf
nodes for testing reproducible builds on armhf to catch some of these

live well,

Attachment: signature.asc
Description: PGP signature

Reproducible-builds mailing list

Reply via email to