[GRASS5] Re: Windows grass binaries / GRASS branching

GRASS GRASS developer
1

Hi John,

On Fri, May 26, 2000 at 06:19:46AM -0600, John Huddleston wrote:

I have the
Grass build system on my M-W box so I will update the system
and rebuild on Monday. Here at the Th-F site I have a Solaris
box and it does not complain about the file name (upper/lower)

O.k., in case you find further naming conflicts, please
let me know.

-------
[hi all]

Well, concerning branches: I would like to start the
stable branch. What I am thinking of is to add a stable
tag to all stable modules. The rest may stay with unstable
tag.

The only problem is the
src/CMD/lists/GRASS which is parsed for compilation. Either
we have to hold two lists (stable/unstable) or the compile
mechanism needs to be modified to

1. ignore non-existing modules (as they might not have been checked
    out if the stable version was acquired)
2. ignore compile errors and proceed, maybe collecting the
    names of uncompiled modules in a log file.

Especially 2. would be of general interest, I think.
If 1. is there, we could modularize the GRASS in a first approach
into smaller, topic-oriented packages.

In fact the best solution would be that the compile script collects
the *existing modules* first, then we would get rid of the
src/CMD/lists/GRASS.

As the scripting mechanism is quite complex (for me!) I am
not shure, if I could manage to modify.

So, what I need:
- assistance for the points 1. and 2. (see above)
- hints how to apply the branch tags (I think afterwards)

Thanks in advance

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Hi Markus, (et al)

Tagging a tree allows us to manage a time slice of Grass.
If we are satisfied at any particular point, check out only
those files into your working copy that are appropriate for
that distribution, and tag them. For example

cvs tag Grass_50B

This allows us, as CVS grass developers, to always checkout
that "branch".

cvs co -r Grass_50B

This creates a "sticky tag" in our local directories and the
files cannot be committed. The user must type the
'cvs update -A' command to release the sticky tag.

Further, if Bernhard or yourself is going to give a copy to
someone without the CVS subdirectories, then use export

cvs export -r Grass_50B grass

Then tar up that grass directory as a snapshot without the
CVS directory and files. To bring all files up to a particular
revision with the CVS repository, you would type

cvs commit -r 5.0

Cat your local CVS/Entries files to see the current versions of
the files.

Branching uses the TAG concept and the CVS manages
this "branch" with the TAG within the file. Literally, there
are not two files. There is always one file. However, within
the repository the RCS file keeps the information required
for CVS to manage it. To the user, it is maintaining several
releases in parallel. See Chapter 5 on the cvs.ps user manual.
For example,

cvs tag -b Experimental_Grass5_0beta9

This splits off a branch based on the current versions in the
working copy. This creates the branch in the repository. This
does not automatically switch the working copy to be on this
branch. To do this, the user would type

cvs update -r Experimental_Grass5_0beta9

Once the user has the working copy tied to a particular branch,
it will stay there until switched to another branch or switched
back to the HEAD.

See 'man cvs' for details online. Read the manual.

John Huddleston

----- Original Message -----
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: John Huddleston <jhudd@itc.nrcs.usda.gov>
Cc: <grass5@geog.uni-hannover.de>
Sent: Friday, May 26, 2000 7:51 AM
Subject: Re: Windows grass binaries / GRASS branching
[snip]

[hi all]

Well, concerning branches: I would like to start the
stable branch. What I am thinking of is to add a stable
tag to all stable modules. The rest may stay with unstable
tag.

The only problem is the
src/CMD/lists/GRASS which is parsed for compilation. Either
we have to hold two lists (stable/unstable) or the compile
mechanism needs to be modified to

1. ignore non-existing modules (as they might not have been checked
    out if the stable version was acquired)
2. ignore compile errors and proceed, maybe collecting the
    names of uncompiled modules in a log file.

Especially 2. would be of general interest, I think.
If 1. is there, we could modularize the GRASS in a first approach
into smaller, topic-oriented packages.

In fact the best solution would be that the compile script collects
the *existing modules* first, then we would get rid of the
src/CMD/lists/GRASS.

As the scripting mechanism is quite complex (for me!) I am
not shure, if I could manage to modify.

So, what I need:
- assistance for the points 1. and 2. (see above)
- hints how to apply the branch tags (I think afterwards)

Thanks in advance

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

Hi again,

I have added futher vector modules to the repository
from NRCS section in GRASS 4.x:

v.in.atlas - to talk to ATLAS GIS
v.out.atlas
v.out.mif
v.out.mapinfo (hi Rich! - needs to be updated to latest Mapinfo format)

The v.rmdup I have slightly updated, now it compiles.

You are welcome to improve the recently added modules.
Moste of them are not added to src/CMD/lists/GRASS as
they should be tested first.

For testing convenience I have added $(MAKEALL) to
src/mapdev/Gmakefile.
Just go there and run "gmake5" to run through the directory tree.

On my Linux box all vector modules compile.
Please write changes directly into the CVS.

Thanks!
  
Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

Hello Markus
On Fri, 26 May 2000, Markus Neteler wrote:

The only problem is the
src/CMD/lists/GRASS which is parsed for compilation. Either
we have to hold two lists (stable/unstable) or the compile
mechanism needs to be modified to

1. ignore non-existing modules (as they might not have been checked
    out if the stable version was acquired)
2. ignore compile errors and proceed, maybe collecting the
    names of uncompiled modules in a log file.

Especially 2. would be of general interest, I think.
If 1. is there, we could modularize the GRASS in a first approach
into smaller, topic-oriented packages.

In fact the best solution would be that the compile script collects
the *existing modules* first, then we would get rid of the
src/CMD/lists/GRASS.

I am not confident in shell programming, but I can easily write a perl
script that can detrmine all exisiting modules if there is a way to
determine if a directory is a module. Maybe the existance of an empty file
called "moduleDir" or something. I don't know if this will be useful or
not but I will volunteer to do it if someone can help with the
specifications for integrating this into the pre-install scripts

Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

5

On Mon, May 29, 2000 at 04:01:13PM +0700, Justin Hickey wrote:

On Fri, 26 May 2000, Markus Neteler wrote:
> The only problem is the
> src/CMD/lists/GRASS which is parsed for compilation. Either
> we have to hold two lists (stable/unstable) or the compile
> mechanism needs to be modified to
>
> 1. ignore non-existing modules (as they might not have been checked
> out if the stable version was acquired)
> 2. ignore compile errors and proceed, maybe collecting the
> names of uncompiled modules in a log file.
>
> Especially 2. would be of general interest, I think.
> If 1. is there, we could modularize the GRASS in a first approach
> into smaller, topic-oriented packages.
>
> In fact the best solution would be that the compile script collects
> the *existing modules* first, then we would get rid of the
> src/CMD/lists/GRASS.

I am not confident in shell programming, but I can easily write a perl
script that can detrmine all exisiting modules if there is a way to
determine if a directory is a module.

If perl is not a prerequisitive for building GRASS now, we should not
introduce it.
  Bernhard

6

On Mon, May 29, 2000 at 04:01:13PM +0700, Justin Hickey wrote:

Hello Markus
On Fri, 26 May 2000, Markus Neteler wrote:
> The only problem is the
> src/CMD/lists/GRASS which is parsed for compilation. Either
> we have to hold two lists (stable/unstable) or the compile
> mechanism needs to be modified to
>
> 1. ignore non-existing modules (as they might not have been checked
> out if the stable version was acquired)
> 2. ignore compile errors and proceed, maybe collecting the
> names of uncompiled modules in a log file.
>
> Especially 2. would be of general interest, I think.
> If 1. is there, we could modularize the GRASS in a first approach
> into smaller, topic-oriented packages.
>
> In fact the best solution would be that the compile script collects
> the *existing modules* first, then we would get rid of the
> src/CMD/lists/GRASS.

I am not confident in shell programming, but I can easily write a perl
script that can detrmine all exisiting modules if there is a way to
determine if a directory is a module. Maybe the existance of an empty file
called "moduleDir" or something.

Usually it should be enough to search for the top directory.
But we have structures like the "src.contrib" etc. Here either
we use your suggestion and add such a file or re-organize the
structure.
Further suggestion/opinions are welcome.

Best wishes

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

7

Hi all,

concerning GRASS branches I would like to

- keep the main tree as experimental (HEAD = default trunk as now,
   all modules have "exp" tag currently)
- create stable branch from this tree by branch tagging

Advantage:
- no changes for the developers as the tags keep unchanged
- easier to maintain: if module is stable, "stable tag" will
   be applied, else no changes (if unstable)

Results:
- trunk keeps as it is (no changes fro you)
- stable version can be checked out by tag specification

Disadvantage:
- might be unusual to have main trunk as experimental and
   stable as branch ? (I don't know)

Questions:
- If applying a branch "stable" tag, does such a tagged module
   disappear from the main (experimental) trunk?

You comments are welcome.

On Mon, May 29, 2000 at 01:54:20PM +0200, Bernhard Reiter wrote:

On Mon, May 29, 2000 at 04:01:13PM +0700, Justin Hickey wrote:
> On Fri, 26 May 2000, Markus Neteler wrote:
> > The only problem is the
> > src/CMD/lists/GRASS which is parsed for compilation. Either
> > we have to hold two lists (stable/unstable) or the compile
> > mechanism needs to be modified to
> >
> > 1. ignore non-existing modules (as they might not have been checked
> > out if the stable version was acquired)
> > 2. ignore compile errors and proceed, maybe collecting the
> > names of uncompiled modules in a log file.
> >
> > Especially 2. would be of general interest, I think.
> > If 1. is there, we could modularize the GRASS in a first approach
> > into smaller, topic-oriented packages.
> >
> > In fact the best solution would be that the compile script collects
> > the *existing modules* first, then we would get rid of the
> > src/CMD/lists/GRASS.
>
> I am not confident in shell programming, but I can easily write a perl
> script that can detrmine all exisiting modules if there is a way to
> determine if a directory is a module.

If perl is not a prerequisitive for building GRASS now, we should not
introduce it.
  Bernhard

I agree. Keep the number of prerequisitives as low as possible.

Best wishes

Markus Neteler

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

8

Hello again,

(sorry for so many mails)

On Mon, May 29, 2000 at 04:01:13PM +0700, Justin Hickey wrote:

Hello Markus
On Fri, 26 May 2000, Markus Neteler wrote:
> The only problem is the
> src/CMD/lists/GRASS which is parsed for compilation. Either
> we have to hold two lists (stable/unstable) or the compile
> mechanism needs to be modified to
>
> 1. ignore non-existing modules (as they might not have been checked
> out if the stable version was acquired)
> 2. ignore compile errors and proceed, maybe collecting the
> names of uncompiled modules in a log file.

Both I could manage easily by modifying
src/CMD/generic/GISGEN.sh

Now "error.log" is created locally, containing such messages:

Compilation error at STEP: src/raster/r.cost (ignored)
Compilation error at STEP: src/raster/r.sss (ignored)

(Note: the r.cost error is a fake, no need to become nervous)

This means we can keep the full
src/CMD/lists/GRASS
list. The user could compile even if having only a sub-set of
modules (in case GRASS will be shipped in packages).

So: Shall I apply this patch?

Best wishes

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

9

Markus, (and Grass CVS users)

Sorry to take so long to reply, had the day off yesterday!

----- Original Message -----
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: <grass5@geog.uni-hannover.de>
Sent: Monday, May 29, 2000 7:22 AM
Subject: [GRASS5] GRASS branching

Hi all,

concerning GRASS branches I would like to

- keep the main tree as experimental (HEAD = default trunk as now,
   all modules have "exp" tag currently)
- create stable branch from this tree by branch tagging

No branch tag, just a normal tag will suffice. The branch
tag is a spacial form of the tag that allows a merge at a later
time. Since in this case, we do not want to change the past,
put a TAG on the main (much like you did with xgrass).

Again, a branch tag is necessary when two programmers
are modifying the same code and one is changing the
"external" features of the code (changing the RETURN code
of 0 or 1, or the number or type of arguments, or changing the
name of the function, subroutine, method, or class.) In this
way the developer can continue to use versioning but it
will not impact other developers until a merge is executed.

Advantage:
- no changes for the developers as the tags keep unchanged
- easier to maintain: if module is stable, "stable tag" will
   be applied, else no changes (if unstable)

Results:
- trunk keeps as it is (no changes for you)
- stable version can be checked out by tag specification

Yes.

Disadvantage:
- might be unusual to have main trunk as experimental and
   stable as branch ? (I don't know)

Usually the HEAD is the experimental section. Users who want
a stable version can check out (or export) code with a tag.

Questions:
- If applying a branch "stable" tag, does such a tagged module
   disappear from the main (experimental) trunk?

No, all files that are tagged are still in the repository. Only
the cvs remove puts files into the Attic directory and the
disappear from the HEAD branch.

John Huddleston

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

10

Hi John,

thanks for your notes (and patience!).

To summarize below:

I just go ahead and start tagging selected modules
as stable (as I already tagged the earlier releases)?
Of course the entire libraries have to be tagged stable,
otherwise it won't compile.

Related question: I have modified the src/CMD/generic/GISGEN.sh
to ignore errors/missing modules. Then I would not have to
maintain two versions of src/CMD/lists/GRASS.
Shall I apply this? It might be of general interest as
the compilation won't stop any more in case of errors.
A file "error.log" is written containing the module's name
not compiled.

On Tue, May 30, 2000 at 07:56:32AM -0600, John Huddleston wrote:

> Hi all,
>
> concerning GRASS branches I would like to
>
> - keep the main tree as experimental (HEAD = default trunk as now,
> all modules have "exp" tag currently)
> - create stable branch from this tree by branch tagging

No branch tag, just a normal tag will suffice. The branch
tag is a spacial form of the tag that allows a merge at a later
time. Since in this case, we do not want to change the past,
put a TAG on the main (much like you did with xgrass).

Fine, this will simplify again the procedure.
In case a module is not stable although tagged stable, I guess
I can remove the tag (o.k., RTFM). I will update the stable
list and hope for your comments:

http://freegis.org/cgi-bin/cvsweb.cgi/~checkout~/grass/documents/list5_of_modules.txt

Again, a branch tag is necessary when two programmers
are modifying the same code and one is changing the
"external" features of the code (changing the RETURN code
of 0 or 1, or the number or type of arguments, or changing the
name of the function, subroutine, method, or class.) In this
way the developer can continue to use versioning but it
will not impact other developers until a merge is executed.

So developers may open their "private" branches and merge
later. Correct?

> Questions:
> - If applying a branch "stable" tag, does such a tagged module
> disappear from the main (experimental) trunk?
>

No, all files that are tagged are still in the repository. Only
the cvs remove puts files into the Attic directory and the
disappear from the HEAD branch.

Of course. I was regarding "no been checked out" as "dissappearing".
Means: If I tag a module as stable, do I get it as well when
checking out the experimental trunk?

Kind regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

11

On Tue, May 30, 2000 at 07:56:32AM -0600, John Huddleston wrote:

Markus, (and Grass CVS users)
Sorry to take so long to reply, had the day off yesterday!

No problem.

John is right, one question remains on my side:
I assume that we need to use branch tags, as some of the source
code fixed might get merged into the experimental version and some not.

Should we not create one stable branch and use one tag for it?

  Bernhard

> - keep the main tree as experimental (HEAD = default trunk as now,
> all modules have "exp" tag currently)
> - create stable branch from this tree by branch tagging

No branch tag, just a normal tag will suffice. The branch
tag is a spacial form of the tag that allows a merge at a later
time. Since in this case, we do not want to change the past,
put a TAG on the main (much like you did with xgrass).

Again, a branch tag is necessary when two programmers
are modifying the same code and one is changing the
"external" features of the code (changing the RETURN code
of 0 or 1, or the number or type of arguments, or changing the
name of the function, subroutine, method, or class.) In this
way the developer can continue to use versioning but it
will not impact other developers until a merge is executed.

>
> Advantage:
> - no changes for the developers as the tags keep unchanged
> - easier to maintain: if module is stable, "stable tag" will
> be applied, else no changes (if unstable)
>
> Results:
> - trunk keeps as it is (no changes for you)
> - stable version can be checked out by tag specification
>

Yes.

> Disadvantage:
> - might be unusual to have main trunk as experimental and
> stable as branch ? (I don't know)
>

Usually the HEAD is the experimental section. Users who want
a stable version can check out (or export) code with a tag.

> Questions:
> - If applying a branch "stable" tag, does such a tagged module
> disappear from the main (experimental) trunk?
>

No, all files that are tagged are still in the repository. Only
the cvs remove puts files into the Attic directory and the
disappear from the HEAD branch.

John Huddleston

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

12

John is right, one question remains on my side:
I assume that we need to use branch tags, as some of the source
code fixed might get merged into the experimental version and some not.

Should we not create one stable branch and use one tag for it?

Tagging a branch means that we can export it out for distribution
or check it out for building. Once the source is checked out with
a tag, we cannot commit any changes. In order to commit changes
to the HEAD we must first do a 'cvs update -A'. If we are working
on a branch, we can commit changes. For branches, remember the
steps are:

tag it as a branch
update your local copy to the branch
edit, compile, link, test
commit changes
merge branch onto the HEAD

John Huddleston

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

13

Dear developers,

as we are currently starting to clean the code: Shall
we keep the src.related section?

src.related > more README
Programs in this directory are NOT GRASS commands, but are public domain
capabilities that may be useful to those advanced GRASS sites.

gctp/
  General Cartographic Transformation Package. Product of USGS.
  (MIT modified for State Plane in north-west hemisphere projections.)

-> Limited to 0) Lat. Long. 1) UTM 2) State Plane

rim/
  Product of UW, Seattle and Central Washington University
  Relational Information Management system. Freely distributable
  dbms married to GRASS through the programs v.db.rim and s.db.rim.
-> who is using it?
-> Sidenote: Perhaps s.db.rim could become s.db.reclass (hi Radim!)

xgen/
  Product of CERL, Purdue, and MIT. Provides shell script writers
  with the ability to generate graphical user interfaces via X-windows.
  Requires X and Motif to compile.
-> no need as XGRASS is deleted as well from standard trunk

Altogether around 5.3MB source code.

Please tell me, if I can remove it (it keeps available using the
beta7 tag).

Markus

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

14

On Tue, 30 May 2000, Markus Neteler wrote:

gctp/
  General Cartographic Transformation Package. Product of USGS.
  (MIT modified for State Plane in north-west hemisphere projections.)

-> Limited to 0) Lat. Long. 1) UTM 2) State Plane

Markus,

  I don't know anything about this package. But, if the capabilities are
available elsewhere within GRASS, then it could be dropped. If not, I vote
to keep it.

  Most of our work covers a small enough area that we work in the State
Plane Coordinate system; only rarely do we use Lambert Conformal Conic or
UTM.

rim/

  I'd rather standardize on postgres (for our stuff, anyway). Therefore, I
don't vote to keep it in.

xgen/

  Again, I won't use it, so it's OK to drop it as far as I'm concerned.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

15

Hi Markus, hi developers,

Markus Neteler wrote:

Dear developers,

as we are currently starting to clean the code: Shall
we keep the src.related section?

src.related > more README
Programs in this directory are NOT GRASS commands, but are public domain
capabilities that may be useful to those advanced GRASS sites.

gctp/
  General Cartographic Transformation Package. Product of USGS.
  (MIT modified for State Plane in north-west hemisphere projections.)

-> Limited to 0) Lat. Long. 1) UTM 2) State Plane

This package is IMHO no longer needed. The library was converted from
fortran to c and everything in that library is available within GRASS
(from proj lib and coorcnv lib). m.proj and m.datum.shift provide all
user functionality too.
Similar functionality is in NIMA geotrans, which is public domain. See
http://www.remotesensing.org. At this time NIMA geotrans does only
compile on Solaris and Windows, but there seems to be someone working on
a linux port.

rim/
  Product of UW, Seattle and Central Washington University
  Relational Information Management system. Freely distributable
  dbms married to GRASS through the programs v.db.rim and s.db.rim.
-> who is using it?
-> Sidenote: Perhaps s.db.rim could become s.db.reclass (hi Radim!)

I do not need it. Everyone ever used this with GRASS 5.0?

xgen/
  Product of CERL, Purdue, and MIT. Provides shell script writers
  with the ability to generate graphical user interfaces via X-windows.
  Requires X and Motif to compile.
-> no need as XGRASS is deleted as well from standard trunk

This does not compile under linux. Although it is a nice thing to write
shell scripts with graphical input/output, nowadays this can be achieved
much simpler with tcl/tk.
I don't think that this is related to xgrass. No need to keep it any
more.

I would suggest to remove s.in.gps and s.out.gps in the near future too.
Is anyone using this? I could not set this up and have no clue how it
works. If someone can give me a hint?

cu,

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de, A.C.Lange@GMX.net

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

16

Markus Neteler wrote:
> Dear developers,
>
> as we are currently starting to clean the code: Shall
> we keep the src.related section?
>

As the software stored in src.related is obviously not required
any more, I have cvs.removed the entire src.relates/ from the repository.

But, if desired, you can still access it using an old tag:
cvs -z3 co -r "release_grass5beta7_20_april_2000" grass/src.related

Best wishes

Markus Neteler

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'