Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] override build timestamp

178 views
Skip to first unread message

Olaf Hering

unread,
Feb 16, 2007, 4:52:33 PM2/16/07
to Andrew Morton, Sam Ravnborg, linux-...@vger.kernel.org

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 <ol...@aepfle.de>

---
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Oleg Verych

unread,
Feb 16, 2007, 10:18:37 PM2/16/07
to Olaf Hering
> 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.

Olaf Hering

unread,
Feb 17, 2007, 6:51:36 AM2/17/07
to Oleg Verych
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.

Andreas Schwab

unread,
Feb 17, 2007, 7:16:42 AM2/17/07
to Olaf Hering
Olaf Hering <ol...@aepfle.de> 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, sch...@suse.de
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."

Roman Zippel

unread,
Feb 17, 2007, 8:58:17 PM2/17/07
to Oleg Verych
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

Roman Zippel

unread,
Feb 17, 2007, 9:05:14 PM2/17/07
to Olaf Hering
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

Oleg Verych

unread,
Feb 17, 2007, 10:49:24 PM2/17/07
to Roman Zippel
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).
____

Olaf Hering

unread,
Feb 18, 2007, 3:12:53 AM2/18/07
to Roman Zippel
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.

Roman Zippel

unread,
Feb 18, 2007, 11:25:13 AM2/18/07
to Olaf Hering
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

Olaf Hering

unread,
Feb 19, 2007, 8:14:17 AM2/19/07
to Roman Zippel
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?

0 new messages