[PATCH] release tarball make targets

[PATCH] release tarball make targets

[Mark Allen]

This patch is to support automating RPM and spec file generation.

Cheers,

--Mark

Signed-off-by: Mark Allen <mrallen1@yahoo.com>

Index: Makefile
===================================================================
--- aa6233be6d1b8bf42797c409a7c23b50593afc99/Makefile  (mode:100644
sha1:6ae0afa0208a8f755d383281a6d049a4ef90fe63)
+++ uncommitted/Makefile  (mode:100644 sha1:181aa6d6c34fb771671a7ee8038f9cf18972713a)
@@ -55,6 +55,10 @@
 
 VERSION= VERSION
 
+DIRS=mozilla-sha1 contrib ppc
+
+DOCS=README README.reference
+
 LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
 	 tag.o date.o
 LIB_FILE=libgit.a
@@ -136,3 +140,11 @@
 
 backup: clean
 	cd .. ; tar czvf dircache.tar.gz dir-cache
+
+release-tar-gzip: clean
+	tar czf $(shell cat $(VERSION)).tar.gz *.c *.h git.spec Makefile $(DOCS) $(DIRS)
$(SCRIPTS) $(SCRIPT) 
+
+release-tar-bzip2: clean
+	tar cjf $(shell cat $(VERSION)).tar.bz2 *.c *.h git.spec Makefile $(DOCS) $(DIRS)
$(SCRIPTS) $(SCRIPT) 
+
+release-tarballs: release-tar-gzip release-tar-bzip2

[PATCH 0/3] cogito spec file updates

[Chris Wright]

Hi Pasky,

Here's the outstanding updates for the spec file, up to 0.8-2 which is
the latest on kernel.org.

	http://www.kernel.org/pub/software/scm/cogito/RPMS/

thanks,
-chris

[PATCH 1/3] cogito spec file 0.7-1

[Chris Wright]

Update spec file to 0.7

Signed-off-by: Chris Wright <chrisw@osdl.org>

--- cogito/git.spec~0.6.3-1	2005-05-03 11:01:52.000000000 -0700
+++ cogito/git.spec	2005-05-03 11:10:32.000000000 -0700
@@ -1,5 +1,5 @@
 Name: 		git
-Version: 	0.6.3
+Version: 	0.7
 Release: 	1
 Vendor: 	Petr Baudis <pasky@ucw.cz>
 Summary:  	Git core and tools
@@ -39,5 +39,8 @@ rm -rf $RPM_BUILD_ROOT
 #%{_mandir}/*/*
 
 %changelog
+* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.7-1
+- Update to 0.7
+
 * Thu Apr 21 2005 Chris Wright <chrisw@osdl.org> 0.6.3-1
 - Initial rpm build

[PATCH 2/3] cogito spec file 0.8-1

[Chris Wright]

Update spec file to cogito 0.8.  Obsolete the git package, add some
more build and install prereqs, move to /usr/bin, update URLs.

Signed-off-by: Chris Wright <chrisw@osdl.org>

--- cogito/git.spec~0.7-1	2005-05-03 11:02:15.000000000 -0700
+++ cogito/git.spec	2005-05-03 11:10:32.000000000 -0700
@@ -1,16 +1,17 @@
-Name: 		git
-Version: 	0.7
+Name: 		cogito
+Version: 	0.8
 Release: 	1
 Vendor: 	Petr Baudis <pasky@ucw.cz>
 Summary:  	Git core and tools
 License: 	GPL
 Group: 		Development/Tools
-URL: 		http://pasky.or.cz/~pasky/dev/git/
-Source: 	http://pasky.or.cz/~pasky/dev/git/%{name}-pasky-%{version}.tar.bz2
-Provides: 	git = %{version}
-BuildRequires:	zlib-devel openssl-devel
+URL: 		http://kernel.org/pub/software/scm/cogito/
+Source: 	http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.bz2
+Provides: 	cogito = %{version}
+Obsoletes:	git
+BuildRequires:	zlib-devel, openssl-devel, curl-devel
 BuildRoot:	%{_tmppath}/%{name}-%{version}-root
-Prereq: 	sh-utils diffutils
+Prereq: 	sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
 
 %description
 GIT comes in two layers. The bottom layer is merely an extremely fast
@@ -20,7 +21,7 @@ enables human beings to work with the da
 similar to other SCM tools (like CVS, BitKeeper or Monotone).
 
 %prep
-%setup -q -n %{name}-pasky-%{version}
+%setup -q -n %{name}-%{version}
 
 %build
 
@@ -28,17 +29,19 @@ make
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT prefix=/usr/local install
+make DESTDIR=$RPM_BUILD_ROOT prefix=/usr/ install
 
 %clean
 rm -rf $RPM_BUILD_ROOT
 
 %files
 %defattr(-,root,root)
-/usr/local/bin/*
-#%{_mandir}/*/*
+/usr/bin/*
 
 %changelog
+* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.8-1
+- Update to cogito, rename package, move to /usr/bin, update prereqs
+
 * Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.7-1
 - Update to 0.7
 

[PATCH 3/3] cogito spec file 0.8-2

[Chris Wright]

Some small additions to the cogito spec file:

 o include some documentation
 o use %{_prefix} macro
 o drop -n from %setup macro

(chrisw: dropped spec file rename)

Signed-off-by: Terje Rosten <terje.rosten@ntnu.no>
Signed-off-by: Chris Wright <chrisw@osdl.org>

--- cogito/git.spec~0.8-1	2005-05-03 11:02:28.000000000 -0700
+++ cogito/git.spec	2005-05-03 11:10:32.000000000 -0700
@@ -1,6 +1,6 @@
 Name: 		cogito
 Version: 	0.8
-Release: 	1
+Release: 	2
 Vendor: 	Petr Baudis <pasky@ucw.cz>
 Summary:  	Git core and tools
 License: 	GPL
@@ -21,7 +21,7 @@ enables human beings to work with the da
 similar to other SCM tools (like CVS, BitKeeper or Monotone).
 
 %prep
-%setup -q -n %{name}-%{version}
+%setup -q
 
 %build
 
@@ -29,7 +29,7 @@ make
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT prefix=/usr/ install
+make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} install
 
 %clean
 rm -rf $RPM_BUILD_ROOT
@@ -37,8 +37,14 @@ rm -rf $RPM_BUILD_ROOT
 %files
 %defattr(-,root,root)
 /usr/bin/*
+%doc README README.reference COPYING Changelog
 
 %changelog
+* Wed Apr 27 2005 Terje Rosten <terje.rosten@ntnu.no> 0.8-2
+- Doc files
+- Use %%{_prefix} macro
+- Drop -n option to %%setup macro
+
 * Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.8-1
 - Update to cogito, rename package, move to /usr/bin, update prereqs
 

Re: [PATCH 0/3] cogito spec file updates

[Chris Wright]

* Chris Wright (chrisw@osdl.org) wrote:
> Here's the outstanding updates for the spec file, up to 0.8-2 which is
> the latest on kernel.org.
> 
> 	http://www.kernel.org/pub/software/scm/cogito/RPMS/

What's your method for creating a release tarball?  If it were formalized
(i.e. Makefile rule), then it'd be simple to use VERSION to drive the
spec file, and it'd only need updating for real content changes (similar
to what Kay did).

thanks,
-chris

Re: [PATCH 0/3] cogito spec file updates

[Petr Baudis]

Dear diary, on Tue, May 03, 2005 at 09:35:36PM CEST, I got a letter
where Chris Wright <chrisw@osdl.org> told me that...
> * Chris Wright (chrisw@osdl.org) wrote:
> > Here's the outstanding updates for the spec file, up to 0.8-2 which is
> > the latest on kernel.org.
> > 
> > 	http://www.kernel.org/pub/software/scm/cogito/RPMS/
> 
> What's your method for creating a release tarball?  If it were formalized
> (i.e. Makefile rule), then it'd be simple to use VERSION to drive the
> spec file, and it'd only need updating for real content changes (similar
> to what Kay did).

For now, I do it so seldom that I just manually do

	cg-log >Changelog
	cg-export ~/cogito-0.9
	cp Changelog ~/cogito-0.9
	cd ~
	tar cvvfz cogito-0.9.tar.gz cogito-0.9

OTOH, I'd like to change this all to just

	cg-export ~/cogito-0.9.tar.gz

when I get to merge the relevant patches; I'm not sure there is so much
of a value to bundle the Changelog; just get the git tree and do cg-log
on your own, or use the web interface.

I might however have some private mkrelease.sh script which would do

	echo "$1" >VERSION
	update-spec-file
	echo "$1" | cg-commit
	cg-tag "$1"

or something.


BTW, did you have a particular reason to split the .spec file updates to
three parts? I think it doesn't make much sense and it'd be probably
enough to update it at once, when we are not doing it at the right time
anyway.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [PATCH 0/3] cogito spec file updates

[Chris Wright]

* Petr Baudis (pasky@ucw.cz) wrote:
> Dear diary, on Tue, May 03, 2005 at 09:35:36PM CEST, I got a letter
> where Chris Wright <chrisw@osdl.org> told me that...
> > * Chris Wright (chrisw@osdl.org) wrote:
> > > Here's the outstanding updates for the spec file, up to 0.8-2 which is
> > > the latest on kernel.org.
> > > 
> > > 	http://www.kernel.org/pub/software/scm/cogito/RPMS/
> > 
> > What's your method for creating a release tarball?  If it were formalized
> > (i.e. Makefile rule), then it'd be simple to use VERSION to drive the
> > spec file, and it'd only need updating for real content changes (similar
> > to what Kay did).
> 
> For now, I do it so seldom that I just manually do
> 
> 	cg-log >Changelog
> 	cg-export ~/cogito-0.9
> 	cp Changelog ~/cogito-0.9
> 	cd ~
> 	tar cvvfz cogito-0.9.tar.gz cogito-0.9
> 
> OTOH, I'd like to change this all to just
> 
> 	cg-export ~/cogito-0.9.tar.gz
> 
> when I get to merge the relevant patches; I'm not sure there is so much
> of a value to bundle the Changelog; just get the git tree and do cg-log
> on your own, or use the web interface.
> 
> I might however have some private mkrelease.sh script which would do
> 
> 	echo "$1" >VERSION
> 	update-spec-file
> 	echo "$1" | cg-commit
> 	cg-tag "$1"
> 
> or something.

If you had a Makefile target like the one Mark Allen just posted, would
you use that?  I'd simply add a git.spec: rule, and have git.spec built
as a dependency for tarball.

> BTW, did you have a particular reason to split the .spec file updates to
> three parts? I think it doesn't make much sense and it'd be probably
> enough to update it at once, when we are not doing it at the right time
> anyway.

Just because that's how I had them locally, and it keeps the file
revision history intact (I don't mind how you prefer to pull them in).

thanks,
-chris

Re: [PATCH 0/3] cogito spec file updates

[Petr Baudis]

Dear diary, on Tue, May 03, 2005 at 11:32:16PM CEST, I got a letter
where Chris Wright <chrisw@osdl.org> told me that...
> * Petr Baudis (pasky@ucw.cz) wrote:
> > I might however have some private mkrelease.sh script which would do
> > 
> > 	echo "$1" >VERSION
> > 	update-spec-file
> > 	echo "$1" | cg-commit
> > 	cg-tag "$1"
> > 
> > or something.
> 
> If you had a Makefile target like the one Mark Allen just posted, would
> you use that?

No, I definitively won't use that:

(i)  The created tarball is Evil. It does not contain everything in a
subdirectory.

(ii) I don't want to have yet another place which I'm supposed to keep
up to date with regard to what should be packaged. That's one of the
things the SCM is for, and it already records precisely this
information, so I'd actually use it. cg-export foo.tar.gz is the perfect
tool for this.

> I'd simply add a git.spec: rule, and have git.spec built
> as a dependency for tarball.

I wouldn't accept this neither. If git.spec is already version
controlled, it should be up-to-date in the version control. Therefore,
you need to update it at the time of release, not at the time of
generating the tarball.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: [PATCH 0/3] cogito spec file updates

[Chris Wright]

* Petr Baudis (pasky@ucw.cz) wrote:
> I wouldn't accept this neither. If git.spec is already version
> controlled, it should be up-to-date in the version control. Therefore,
> you need to update it at the time of release, not at the time of
> generating the tarball.

*shrug*

Well, it's guaranteed to be one step out of sync, but I'll just keep
doing what I've been doing.  Build rpm after you release, and send
patch ex-post-facto.

thanks,
-chris

Re: [PATCH 0/3] cogito spec file updates

[H. Peter Anvin]

Petr Baudis wrote:
> 
> I wouldn't accept this neither. If git.spec is already version
> controlled, it should be up-to-date in the version control. Therefore,
> you need to update it at the time of release, not at the time of
> generating the tarball.
> 

What I usually do is to have a *.spec.in file, and have my release 
script generate the *.spec file.  I usually have a "version" file 
checked into the SCM from which all version information derives, 
including what to put in the *.spec file as well as what to name the 
subdirectory.

The release script then ends up being some variant on:

#!/bin/sh -xe
PACKAGE=pkgname
VERSION=`cat version`
scm-of-choice tag --force $PACKAGE-$VERSION
mkdir /var/tmp/$PACKAGE-$VERSION
cd /var/tmp/$PACKAGE-$VERSION
scm-of-choice export -r $PACKAGE-$VERSION
make release
cd ..
tar cvvfz $PACKAGE-$VERSION.tar.gz $PACKAGE-$VERSION
rm -rf $PACKAGE-$VERSION

... where "make release" creates the specfile and anything else that 
needs to be created (like autoconf files.)

	-hpa

Re: [PATCH 0/3] cogito spec file updates

[Horst von Brand]

"H. Peter Anvin" <hpa@zytor.com> said:
> Petr Baudis wrote:
> > I wouldn't accept this neither. If git.spec is already version
> > controlled, it should be up-to-date in the version control. Therefore,
> > you need to update it at the time of release, not at the time of
> > generating the tarball.

> What I usually do is to have a *.spec.in file, and have my release 
> script generate the *.spec file.  I usually have a "version" file 
> checked into the SCM from which all version information derives, 
> including what to put in the *.spec file as well as what to name the 
> subdirectory.

Right. Note that this is /not/ autoconfiguring .spec from .spec.in, you are
"just" automating the process I do by hand.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [PATCH 0/3] cogito spec file updates

[H. Peter Anvin]

Horst von Brand wrote:
> "H. Peter Anvin" <hpa@zytor.com> said:
> 
>>Petr Baudis wrote:
>>
>>>I wouldn't accept this neither. If git.spec is already version
>>>controlled, it should be up-to-date in the version control. Therefore,
>>>you need to update it at the time of release, not at the time of
>>>generating the tarball.
> 
> 
>>What I usually do is to have a *.spec.in file, and have my release 
>>script generate the *.spec file.  I usually have a "version" file 
>>checked into the SCM from which all version information derives, 
>>including what to put in the *.spec file as well as what to name the 
>>subdirectory.
> 
> Right. Note that this is /not/ autoconfiguring .spec from .spec.in, you are
> "just" automating the process I do by hand.

Right, the .spec.in here doesn't imply the use of autoconf.

(That being said, if you *are* using autoconf, the "make release" target 
is also a good place to produce the autoconf generated files, being just 
another class of autogenerated-but-should-be-in-the-tarball files.)

	-hpa

Re: [PATCH 0/3] cogito spec file updates

[Chris Wright]

* H. Peter Anvin (hpa@zytor.com) wrote:
> What I usually do is to have a *.spec.in file, and have my release 
> script generate the *.spec file.  I usually have a "version" file 
> checked into the SCM from which all version information derives, 
> including what to put in the *.spec file as well as what to name the 
> subdirectory.
> 
> The release script then ends up being some variant on:
> 
> #!/bin/sh -xe
> PACKAGE=pkgname
> VERSION=`cat version`
> scm-of-choice tag --force $PACKAGE-$VERSION
> mkdir /var/tmp/$PACKAGE-$VERSION
> cd /var/tmp/$PACKAGE-$VERSION
> scm-of-choice export -r $PACKAGE-$VERSION
> make release
> cd ..
> tar cvvfz $PACKAGE-$VERSION.tar.gz $PACKAGE-$VERSION
> rm -rf $PACKAGE-$VERSION
> 
> ... where "make release" creates the specfile and anything else that 
> needs to be created (like autoconf files.)

Yup, that's precisely what I was thinking.  I cobbled up an add-on to
Mark Allen's patch yesterday, but didn't send it since Pasky didn't seem
too interested in the idea.  Anyway, here it is to demonstrate the idea.
The current setup is definitely workable, just means each release tarball
will build a bogus package with rpmbuild -ta.  So I just fix up the spec
and then build...

thanks,
-chris
--



Autogen git.spec from git.spec.in.  Needs patch from Mark Allen.

Signed-off-by: Chris Wright <chrisw@osdl.org>

--- cogito/Makefile~orig	2005-05-03 14:41:50.000000000 -0700
+++ cogito/Makefile	2005-05-03 15:53:36.000000000 -0700
@@ -126,6 +126,8 @@
 	@chmod +x $@
 endif
 
+git.spec: git.spec.in $(VERSION) 
+	sed -e 's/@@VERSION@@/$(shell cat $(VERSION) | cut -d"-" -f2)/g' < $< > $@
 
 install: $(PROG) $(SCRIPTS) $(SCRIPT) $(GEN_SCRIPT)
 	install -m755 -d $(DESTDIR)$(bindir)
@@ -141,10 +143,10 @@
 backup: clean
 	cd .. ; tar czvf dircache.tar.gz dir-cache
 
-release-tar-gzip: clean
+release-tar-gzip: clean git.spec
 	tar czf $(shell cat $(VERSION)).tar.gz *.c *.h git.spec Makefile $(DOCS) $(DIRS) $(SCRIPTS) $(SCRIPT) 
 
-release-tar-bzip2: clean
+release-tar-bzip2: clean git.spec
 	tar cjf $(shell cat $(VERSION)).tar.bz2 *.c *.h git.spec Makefile $(DOCS) $(DIRS) $(SCRIPTS) $(SCRIPT) 
 
 release-tarballs: release-tar-gzip release-tar-bzip2
--- cogito/git.spec~orig	2005-05-03 14:41:59.000000000 -0700
+++ cogito/git.spec	2005-05-03 14:42:55.000000000 -0700
@@ -1,55 +0,0 @@
-Name: 		cogito
-Version: 	0.8
-Release: 	2
-Vendor: 	Petr Baudis <pasky@ucw.cz>
-Summary:  	Git core and tools
-License: 	GPL
-Group: 		Development/Tools
-URL: 		http://kernel.org/pub/software/scm/cogito/
-Source: 	http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.bz2
-Provides: 	cogito = %{version}
-Obsoletes:	git
-BuildRequires:	zlib-devel, openssl-devel, curl-devel
-BuildRoot:	%{_tmppath}/%{name}-%{version}-root
-Prereq: 	sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
-
-%description
-GIT comes in two layers. The bottom layer is merely an extremely fast
-and flexible filesystem-based database designed to store directory trees
-with regard to their history. The top layer is a SCM-like tool which
-enables human beings to work with the database in a manner to a degree
-similar to other SCM tools (like CVS, BitKeeper or Monotone).
-
-%prep
-%setup -q
-
-%build
-
-make
-
-%install
-rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} install
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-%files
-%defattr(-,root,root)
-/usr/bin/*
-%doc README README.reference COPYING Changelog
-
-%changelog
-* Wed Apr 27 2005 Terje Rosten <terje.rosten@ntnu.no> 0.8-2
-- Doc files
-- Use %%{_prefix} macro
-- Drop -n option to %%setup macro
-
-* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.8-1
-- Update to cogito, rename package, move to /usr/bin, update prereqs
-
-* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.7-1
-- Update to 0.7
-
-* Thu Apr 21 2005 Chris Wright <chrisw@osdl.org> 0.6.3-1
-- Initial rpm build
--- cogito/git.spec.in~orig	2005-05-03 14:42:20.000000000 -0700
+++ cogito/git.spec.in	2005-05-03 14:44:19.000000000 -0700
@@ -0,0 +1,58 @@
+Name: 		cogito
+Version: 	@@VERSION@@
+Release: 	1
+Vendor: 	Petr Baudis <pasky@ucw.cz>
+Summary:  	Git core and tools
+License: 	GPL
+Group: 		Development/Tools
+URL: 		http://kernel.org/pub/software/scm/cogito/
+Source: 	http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.bz2
+Provides: 	cogito = %{version}
+Obsoletes:	git
+BuildRequires:	zlib-devel, openssl-devel, curl-devel
+BuildRoot:	%{_tmppath}/%{name}-%{version}-root
+Prereq: 	sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
+
+%description
+GIT comes in two layers. The bottom layer is merely an extremely fast
+and flexible filesystem-based database designed to store directory trees
+with regard to their history. The top layer is a SCM-like tool which
+enables human beings to work with the database in a manner to a degree
+similar to other SCM tools (like CVS, BitKeeper or Monotone).
+
+%prep
+%setup -q
+
+%build
+
+make
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make DESTDIR=$RPM_BUILD_ROOT prefix=%{_prefix} install
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root)
+/usr/bin/*
+%doc README README.reference COPYING Changelog
+
+%changelog
+* Tue May 3 2005 Chris Wright <chrisw@osdl.org>
+- Auto build from git.spec.in
+
+* Wed Apr 27 2005 Terje Rosten <terje.rosten@ntnu.no> 0.8-2
+- Doc files
+- Use %%{_prefix} macro
+- Drop -n option to %%setup macro
+
+* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.8-1
+- Update to cogito, rename package, move to /usr/bin, update prereqs
+
+* Mon Apr 25 2005 Chris Wright <chrisw@osdl.org> 0.7-1
+- Update to 0.7
+
+* Thu Apr 21 2005 Chris Wright <chrisw@osdl.org> 0.6.3-1
+- Initial rpm build

Re: [PATCH 0/3] cogito spec file updates

[Horst von Brand]

Chris Wright <chrisw@osdl.org> said:
> * Chris Wright (chrisw@osdl.org) wrote:
> > Here's the outstanding updates for the spec file, up to 0.8-2 which is
> > the latest on kernel.org.
> > 
> > 	http://www.kernel.org/pub/software/scm/cogito/RPMS/
> 
> What's your method for creating a release tarball?  If it were formalized
> (i.e. Makefile rule), then it'd be simple to use VERSION to drive the
> spec file, and it'd only need updating for real content changes (similar
> to what Kay did).

In each case you should add a Changelog entry to the spec file. Said entry
will probably mention the version anyway. Updating the version by hand
while at it is no big deal, now is it? Probably even less hassle than doing
it automatically.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513