Pass a timestamp to kbuild via an enviroment variable.
TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
This can be used when the kernel source is in a SCM and uname -v
is supposed to give the commit date and not the package build time.
Signed-off-by: Olaf Hering <[email protected]>
---
scripts/mkcompile_h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6/scripts/mkcompile_h
===================================================================
--- linux-2.6.orig/scripts/mkcompile_h
+++ linux-2.6/scripts/mkcompile_h
@@ -30,7 +30,12 @@ UTS_VERSION="#$VERSION"
CONFIG_FLAGS=""
if [ -n "$SMP" ] ; then CONFIG_FLAGS="SMP"; fi
if [ -n "$PREEMPT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"; fi
-UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS `LC_ALL=C LANG=C date`"
+if [ -n "$BUILD_TIMESTAMP" ]; then
+ TIMESTAMP="`LC_ALL=C LANG=C date -d "$BUILD_TIMESTAMP"`"
+else
+ TIMESTAMP="`LC_ALL=C LANG=C date`"
+fi
+UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS $TIMESTAMP"
# Truncate to maximum length
> From: Olaf Hering
> Newsgroups: gmane.linux.kernel
> Subject: [PATCH] override build timestamp
> Date: Fri, 16 Feb 2007 22:52:13 +0100
Hallo, Olaf.
> Pass a timestamp to kbuild via an enviroment variable.
>
> TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
>
> This can be used when the kernel source is in a SCM and uname -v
> is supposed to give the commit date and not the package build time.
While adding this functionality must be decided by kbuild developers,
could you make separate patch with exporting 'LANG=C' on the very
beginning and delete all other occurrences of it? It's a C header file
generation and afaik, it must be ASCII.
Thanks.
> Signed-off-by: Olaf Hering <[email protected]>
>
> ---
> scripts/mkcompile_h | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/scripts/mkcompile_h
>===================================================================
> --- linux-2.6.orig/scripts/mkcompile_h
> +++ linux-2.6/scripts/mkcompile_h
> @@ -30,7 +30,12 @@ UTS_VERSION="#$VERSION"
> CONFIG_FLAGS=""
> if [ -n "$SMP" ] ; then CONFIG_FLAGS="SMP"; fi
> if [ -n "$PREEMPT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"; fi
> -UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS `LC_ALL=C LANG=C date`"
> +if [ -n "$BUILD_TIMESTAMP" ]; then
> + TIMESTAMP="`LC_ALL=C LANG=C date -d "$BUILD_TIMESTAMP"`"
> +else
> + TIMESTAMP="`LC_ALL=C LANG=C date`"
> +fi
> +UTS_VERSION="$UTS_VERSION $CONFIG_FLAGS $TIMESTAMP"
>
> # Truncate to maximum length
>
On Sat, Feb 17, Oleg Verych wrote:
> While adding this functionality must be decided by kbuild developers,
> could you make separate patch with exporting 'LANG=C' on the very
> beginning and delete all other occurrences of it? It's a C header file
> generation and afaik, it must be ASCII.
That makes sense.
But we better build the whole kernel with LC_ALL=C LANG=C.
Olaf Hering <[email protected]> writes:
> But we better build the whole kernel with LC_ALL=C LANG=C.
If you have LC_ALL=C you don't need LANG=C.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Hi,
On Sat, 17 Feb 2007, Oleg Verych wrote:
> could you make separate patch with exporting 'LANG=C' on the very
> beginning and delete all other occurrences of it? It's a C header file
> generation and afaik, it must be ASCII.
Bad idea, most user output should be localized (even if it's only utf-8)
and some kconfig targets have explicit locale support.
bye, Roman
Hi,
On Fri, 16 Feb 2007, Olaf Hering wrote:
> Pass a timestamp to kbuild via an enviroment variable.
>
> TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
>
> This can be used when the kernel source is in a SCM and uname -v
> is supposed to give the commit date and not the package build time.
Is this really necessary? I don't really see the point of this.
bye, Roman
On Sun, Feb 18, 2007 at 02:57:26AM +0100, Roman Zippel wrote:
> Hi,
Hallo, Roman.
> On Sat, 17 Feb 2007, Oleg Verych wrote:
>
> > could you make separate patch with exporting 'LANG=C' on the very
> > beginning and delete all other occurrences of it? It's a C header file
> > generation and afaik, it must be ASCII.
>
> Bad idea, most user output should be localized (even if it's only utf-8)
> and some kconfig targets have explicit locale support.
Ok, then maybe this one
<http://marc.theaimsgroup.com/?l=linux-mm-commits&m=116720464804613&w=2>
can be fixed as well? I used same reasoning to comment on it (that
particular patch was dropped).
____
On Sun, Feb 18, Roman Zippel wrote:
> Hi,
>
> On Fri, 16 Feb 2007, Olaf Hering wrote:
>
> > Pass a timestamp to kbuild via an enviroment variable.
> >
> > TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
> >
> > This can be used when the kernel source is in a SCM and uname -v
> > is supposed to give the commit date and not the package build time.
>
> Is this really necessary? I don't really see the point of this.
The package/kernel buildtime does not mean much, but the commit date
gives you a way to restore the source state for a given binary.
Hi,
On Sun, 18 Feb 2007, Olaf Hering wrote:
> > On Fri, 16 Feb 2007, Olaf Hering wrote:
> >
> > > Pass a timestamp to kbuild via an enviroment variable.
> > >
> > > TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
> > >
> > > This can be used when the kernel source is in a SCM and uname -v
> > > is supposed to give the commit date and not the package build time.
> >
> > Is this really necessary? I don't really see the point of this.
>
> The package/kernel buildtime does not mean much, but the commit date
> gives you a way to restore the source state for a given binary.
This information could also be added to the version string like
CONFIG_LOCALVERSION_AUTO does. OTOH rather than abusing the build date
(which may not mean much, but it nevertheless has a meaning), I'd rather
add the possibility to add extra information.
bye, ROman
On Sun, Feb 18, Roman Zippel wrote:
> This information could also be added to the version string like
> CONFIG_LOCALVERSION_AUTO does. OTOH rather than abusing the build date
> (which may not mean much, but it nevertheless has a meaning), I'd rather
> add the possibility to add extra information.
What exactly do you have in mind, how to provide the extra info?