From rkw@shrimp.dataplex.net  Sun Apr 19 00:27:55 1998
Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA08160
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 19 Apr 1998 00:27:54 GMT
          (envelope-from rkw@shrimp.dataplex.net)
Received: (from root@localhost)
	by shrimp.dataplex.net (8.8.8/8.8.5) id TAA28547;
	Sat, 18 Apr 1998 19:27:49 -0500 (CDT)
Message-Id: <199804190027.TAA28547@shrimp.dataplex.net>
Date: Sat, 18 Apr 1998 19:27:49 -0500 (CDT)
From: rkw@Dataplex.Net
Reply-To: rkw@Dataplex.Net
To: FreeBSD-gnats-submit@freebsd.org
Subject: Patch to HELP track source dates
X-Send-Pr-Version: 3.2

>Number:         6346
>Category:       conf
>Synopsis:       Kernel version strings need to relate to the source not the build
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    linimon
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr 18 17:30:01 PDT 1998
>Closed-Date:    Mon Sep 04 16:36:59 GMT 2006
>Last-Modified:  Mon Sep 04 16:36:59 GMT 2006
>Originator:     Richard Wackerbarth
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
The Digital Dataplex
>Environment:

Anyone building from stale sources

>Description:

When someone reports a problem, there is always confusion because the date
that they BUILD a kernel is not a reliable indicator of the version of the
source tree from which they built it.

>How-To-Repeat:

Extract the sources from the CVS tree using some past date. Build a kernel.
Note that the date in the version is the current date rather than the date
of the sources. The kernel is actually much closer to matching one from
many days ago rather than one produced from today's tree.

>Fix:

Place a file in the tree that represents the date of the source tree rather
than the current date.

Until this is done, each user can approximate that date by locally building
the file at the time that he updates their source.

For Example: (Assuming that the CVSup server is up-to-date)
shrimp: {66} cat ~library/bin/do-CVSUP
#!/bin/sh

/usr/local/sbin/cvsup supfile.cvsup

TODAY=`date +%C%y%m%d`

cat >/usr/src/.timestamp <<EOF
#define FreeBSD_Source_Timestamp $TODAY
EOF

PATCH to conf/newvers.sh to utilize this file:
shrimp: {67} diff ../../conf/newvers.sh.old ../../conf/newvers.sh
41c41
< SNAPDATE=""
---
> SNAPDATE="`sed "s/#define FreeBSD_Source_Timestamp //" </usr/src/.timestamp`"
43c43
<       RELEASE="${RELEASE}-${SNAPDATE}"
---
>       RELEASE="${REVISION}-${SNAPDATE}"
85c85
< v=`cat version` u=${USER-root} d=`pwd` h=`hostname` t=`date`
---
> v=`cat version` u=${USER-root} d=`pwd` h=`hostname` t=`date +%D`
93c93
<       \"${VERSION} #${v}: ${t}\\n    ${u}@${h}:${d}\\n\";" >>vers.c
---
>       \"$1 #${v}: ${t}\\n\";" >>vers.c




Please note that I intentionally use the #define construct so that it is
possible to #include the file in a "C" program. It is much easier to strip
off the unneeded portion in the shell script than it would be to attempt to
generate the #define version at compile time.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sat Jan 19 14:00:25 PST 2002 
State-Changed-Why:  

Can this be closed? Since there are so many ways of updating the 
source, I'm not sure that a `source date' in the version string is 
practical. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=6346 
State-Changed-From-To: feedback->open 
State-Changed-By: sheldonh 
State-Changed-When: Wed Jan 30 08:01:36 PST 2002 
State-Changed-Why:  
Let's see if Joe bites. :-) 


Responsible-Changed-From-To: freebsd-bugs->joe 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Wed Jan 30 08:01:36 PST 2002 
Responsible-Changed-Why:  
Joe, could you work something into the CVS scripts to manage this file? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=6346 

From: Sheldon Hearn <sheldonh@starjuice.net>
To: Josef Karthauser <joe@tao.org.uk>
Cc: bug-followup@freebsd.org
Subject: Re: conf/6346: Kernel version strings need to relate to the source not the build 
Date: Thu, 31 Jan 2002 11:22:55 +0200

 On Wed, 30 Jan 2002 17:40:41 GMT, Josef Karthauser wrote:
 
 > Bite bite.
 
 Thanks. :-)
 
 > Technically we could use the date in the latest $FreeBSD$ tag of the
 > source code, and then put this into vers.c at kernel build time.
 
 This only solves the problem of the running kernel.  What would be great
 is a file in the repository itself that's automatically updated with
 every atomic commit.
 
 This file could certainly be used to provide the kernel with a serial
 number, but the advantage would be that folks could report the serial
 number of the source tree with which they're experiencing build problems
 as well.
 
 Is this feasible?
 
 Ciao,
 Sheldon.

From: Josef Karthauser <joe@tao.org.uk>
To: Sheldon Hearn <sheldonh@starjuice.net>
Cc: Josef Karthauser <joe@tao.org.uk>, bug-followup@freebsd.org
Subject: Re: conf/6346: Kernel version strings need to relate to the source not the build
Date: Thu, 31 Jan 2002 10:30:44 +0000

 --gKMricLos+KVdGMg
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, Jan 31, 2002 at 11:22:55AM +0200, Sheldon Hearn wrote:
 >=20
 > > Technically we could use the date in the latest $FreeBSD$ tag of the
 > > source code, and then put this into vers.c at kernel build time.
 >=20
 > This only solves the problem of the running kernel.  What would be great
 > is a file in the repository itself that's automatically updated with
 > every atomic commit.
 >=20
 > This file could certainly be used to provide the kernel with a serial
 > number, but the advantage would be that folks could report the serial
 > number of the source tree with which they're experiencing build problems
 > as well.
 >=20
 > Is this feasible?
 
 Yes, of course we could drop a file into the repo every commit, but
 does that really help?  Lots of us developers folk don't cvsup or
 use cvs at every build.  (i.e commit to a few files in the kernel
 with cvs -d blah).  Also the only place that it makes sense to put
 this file is in ncvs/CVSROOT, which most people don't sup.  Looking
 through the source for the latest revision date is the correct
 answer imo.  Perhaps it should be default, but switched off in
 /etc/make.conf?  (Bear in mind that vers.c only gets built once -
 if you do a buildkernel -DNOCLEAN it doesn't get rebuilt).
 
 Joe
 
 --gKMricLos+KVdGMg
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.6 (FreeBSD)
 Comment: For info see http://www.gnupg.org
 
 iEYEARECAAYFAjxZHNQACgkQXVIcjOaxUBZpigCeLkWBv7USAvf6r2sZR5guI2PU
 tSMAn38oKsO2TAZPyfpoK43m7iQ91w4n
 =aznn
 -----END PGP SIGNATURE-----
 
 --gKMricLos+KVdGMg--

From: Sheldon Hearn <sheldonh@starjuice.net>
To: Josef Karthauser <joe@tao.org.uk>
Cc: bug-followup@freebsd.org
Subject: Re: conf/6346: Kernel version strings need to relate to the source not the build 
Date: Thu, 31 Jan 2002 12:38:05 +0200

 On Thu, 31 Jan 2002 10:30:44 GMT, Josef Karthauser wrote:
 
 > Yes, of course we could drop a file into the repo every commit, but
 > does that really help?  Lots of us developers folk don't cvsup or
 > use cvs at every build.  (i.e commit to a few files in the kernel
 > with cvs -d blah). 
 
 Does it help developers like you, no.  Does it help end-users tracking
 -STABLE without local changes, yes!  We end up with a serial number in
 both the source tree and in the generated kernel (if they get that far)
 that pinpoints the snapshot they have of the source tree.
 
 > Also the only place that it makes sense to put this file is in
 > ncvs/CVSROOT, which most people don't sup.
 
 Why does it not make sense to put it somewhere like ncvs/src/SERIAL?
 
 Ciao,
 Sheldon.

From: Josef Karthauser <joe@tao.org.uk>
To: Sheldon Hearn <sheldonh@starjuice.net>
Cc: Josef Karthauser <joe@tao.org.uk>, bug-followup@freebsd.org
Subject: Re: conf/6346: Kernel version strings need to relate to the source not the build
Date: Thu, 31 Jan 2002 10:38:00 +0000

 --tqI+Z3u+9OQ7kwn0
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, Jan 31, 2002 at 12:38:05PM +0200, Sheldon Hearn wrote:
 
 > > Also the only place that it makes sense to put this file is in
 > > ncvs/CVSROOT, which most people don't sup.
 >=20
 > Why does it not make sense to put it somewhere like ncvs/src/SERIAL?
 >=20
 
 Ok.  I'll do the work if we can get a consensus agreement that this is a
 sane thing to do.  Would you mind polling -developers or -arch (and
 probably -cvs)?
 
 Joe
 
 --tqI+Z3u+9OQ7kwn0
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.6 (FreeBSD)
 Comment: For info see http://www.gnupg.org
 
 iEYEARECAAYFAjxZHocACgkQXVIcjOaxUBZwwgCfWg5fQK4i5l8cGT6cMZhBBJ5k
 eBAAmweTiB0pCeDt5TiMJOQPZYtPSIji
 =YBLC
 -----END PGP SIGNATURE-----
 
 --tqI+Z3u+9OQ7kwn0--

From: Josef Karthauser <joe@tao.org.uk>
To: Josef Karthauser <joe@tao.org.uk>
Cc: Sheldon Hearn <sheldonh@starjuice.net>, bug-followup@freebsd.org
Subject: Re: conf/6346: Kernel version strings need to relate to the source not the build
Date: Thu, 31 Jan 2002 10:39:23 +0000

 --NtwzykIc2mflq5ck
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, Jan 31, 2002 at 10:38:00AM +0000, Josef Karthauser wrote:
 > On Thu, Jan 31, 2002 at 12:38:05PM +0200, Sheldon Hearn wrote:
 >=20
 > > > Also the only place that it makes sense to put this file is in
 > > > ncvs/CVSROOT, which most people don't sup.
 > >=20
 > > Why does it not make sense to put it somewhere like ncvs/src/SERIAL?
 >=20
 > Ok.  I'll do the work if we can get a consensus agreement that this is a
 > sane thing to do.  Would you mind polling -developers or -arch (and
 > probably -cvs)?
 >=20
 
 That said if it's only benefitting non-developers whats a few seconds
 more of time pulling out the revision string from the kernel source
 if it means that we don't need to fudge the repository source?
 (A similar trick can be done for the general src tree if required).
 
 Joe
 
 --NtwzykIc2mflq5ck
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.6 (FreeBSD)
 Comment: For info see http://www.gnupg.org
 
 iEYEARECAAYFAjxZHtsACgkQXVIcjOaxUBYHWQCfS29NxN8cXIl4i4wkki/97DJ7
 FQMAn0967YimoNEwx1FFoV0roaNAWXt3
 =wuST
 -----END PGP SIGNATURE-----
 
 --NtwzykIc2mflq5ck--

From: Sheldon Hearn <sheldonh@starjuice.net>
To: Josef Karthauser <joe@tao.org.uk>
Cc: bug-followup@freebsd.org
Subject: Re: conf/6346: Kernel version strings need to relate to the source not the build 
Date: Thu, 31 Jan 2002 12:47:55 +0200

 On Thu, 31 Jan 2002 10:38:00 GMT, Josef Karthauser wrote:
 
 > Ok.  I'll do the work if we can get a consensus agreement that this is a
 > sane thing to do.  Would you mind polling -developers or -arch (and
 > probably -cvs)?
 
 You bastard. :-)
 
 Okay, I'll try -arch first.  Watch this space...
 
 Ciao,
 Sheldon.
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Mon Apr 17 19:40:24 UTC 2006 
State-Changed-Why:  
Did anything ever happen with this suggestion? 


Responsible-Changed-From-To: joe->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Apr 17 19:40:24 UTC 2006 
Responsible-Changed-Why:  
joe has returned his bit for safekeeping due to lack of time. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=6346 
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Mon Sep 4 16:34:12 UTC 2006 
State-Changed-Why:  
Feedback timeout.  In addition, ISTM that implementing this would be 
counter to the work that has been done to make FreeBSD Update work. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=6346 
>Unformatted:
