On Fri, Feb 28, 2020 at 11:16:09AM +0100, Roland Hieber wrote: > On Thu, Feb 27, 2020 at 03:44:48PM +0100, Alexander Dahl wrote: > > Signed-off-by: Alexander Dahl <[email protected]> > > --- > > rules/os-release.make | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/rules/os-release.make b/rules/os-release.make > > index 5156156a0..ba607aa38 100644 > > --- a/rules/os-release.make > > +++ b/rules/os-release.make > > @@ -56,7 +56,7 @@ $(STATEDIR)/os-release.targetinstall: > > $(PTXDIST_PTXCONFIG) $(PTXDIST_PLATFORMCON > > @PTXDIST_VERSION@, $(PTXDIST_VERSION_FULL)) > > > > @$(call install_replace, os-release, /usr/lib/os-release, \ > > - @DATE@, $(shell date +%FT%T%z)) > > + @DATE@, $(shell date --utc --date @$(SOURCE_DATE_EPOCH) > > '+%FT%T%z')) > > So I think we > should rather set the build date to the modification time of the newest > source file in the BSP. We could do that by defining a variable in > scripts/lib/ the same manner as PTXDIST_BSP_AUTOVERSION.
That isn't as easy as I thought, as file mtimes get updated when doing a VCS checkout. Also we would have to list all files in the BSP (and all base layers), which could potentially be a very I/O heavy operation, or need to deal with blacklists or whitelists of folders, but then needed to make sure nothing in that folders is included in a bash script / kconfig file / Makefile. Instead we could use the date of ./tarball-version (like PTXDIST_BSP_AUTOVERSION does too) or the current VCS commit; or if the BSP is not a VCS repo, or if the worktree has local changes, fall back to searching for the most recent file in the current BSP. Does this sound reasonable? - Roland -- Roland Hieber, Pengutronix e.K. | [email protected] | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ ptxdist mailing list [email protected]
