[GRASS-dev] GRASS 6.1.0 release preparation

GRASS GIS GRASS GIS developer
1

Hi developers,

I think that the current GRASS 6.1-CVS is in a good condition
to be released as GRASS 6.1.0. This will pave the way for
GRASS 6.2.0 (stable) which may follow shortly.

I would suggest to branch off a 6.1.0 branch in CVS to
not kill momentum in the HEAD. Important fixes can then
be merged if needed. From that branch we get out one or
two beta tarballs, then release candidates and finally
the 6.1.0 version.

If there are no objections, I'll branch right away.
Development continues in HEAD as before and we can
extract a first 6.1.0beta for packagers and testers.

Further discussion:
* The x11-less GRASS can be developed in HEAD, we should
  not wait for that. We can have 6.1.1 if desired in near
  future. The same applies to the georectifier.

* NVIZ/Mac issues we can port from HEAD if they get fixed.
  Apparently it's more related to openGL than GRASS.

* snprintf(): much discussion, no result. We can backport
  once it happens.

* other open issues which are *really* showstoppers for
  a 6.1.0 unstable release?

An announcement is drafted at
http://grass.itc.it/announces/announce_grass610.html
The list of changes should be almost up to date, please
review and add missing items. Also the wording of the
first part could be more press release like.

Markus

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I strongly support the proposal.
Current stable grass is quite old, and users must have access to all the
new and fancy new features.
All the best.
pc

Markus Neteler wrote:

Hi developers,

...
- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEqU3J/NedwLUzIr4RAsr0AKC6oovk33Oa2Pg4sGEriGoDAfcoKgCgtqW+
iDKk/oejoCugpG9/bukK+DU=
=yBos
-----END PGP SIGNATURE-----

3

An announcement is drafted at
http://grass.itc.it/announces/announce_grass610.html
The list of changes should be almost up to date, please
review and add missing items. Also the wording of the
first part could be more press release like.

I notice that the link at

   Selected Bugfixes (see ChangeLog for details)

    - Source code quality/libraries:
       - GRASS is now ANSI C compliant
       - Ported natively to MS-Windows (MinGW based)
                ^^^^^^^^^^^^^^^^^^^^^^

Actually points to a page (owned by Markus Neteler) that
points to a page for downloading QGIS.

nick

************************************************************
Opinions contained in this e-mail do not necessarily reflect
the opinions of the Queensland Department of Main Roads,
Queensland Transport or Maritime Safety Queensland, or
endorsed organisations utilising the same infrastructure.
If you have received this electronic mail message in error,
please immediately notify the sender and delete the message
from your computer.
************************************************************

4

Markus wrote:

Hi developers,

I think that the current GRASS 6.1-CVS is in a good condition
to be released as GRASS 6.1.0. This will pave the way for
GRASS 6.2.0 (stable) which may follow shortly.

horray!
(outstanding issues for me: fix ps.map vlegend patterns bug and finish
last i.vpoints details)

recycled comments:
Currently 6.0.2. is the most recent release (22 Feb 2006), but the last
release including new features was 6.0.0 (10 March 2005). But that had
a feature freeze since 1 Jan 2005(?). So as far as stable users are
concerned we haven't added a single new feature since late 2004. I am
sure you will agree that there have been some improvements since then!

we did a similar 5.7.0 development release:
http://grass.ibiblio.org/announces/announce_grass570.html

Besides it generally being a good idea; and too long since the last; it
is important to have a known delta to check against when reworking a
major library (eg display drivers); the Debian package freeze is fast
approaching and they will only package a point release.

Plus support for 64bit, TclTk 8.4, FFTW2, etc etc.. support which 6.0
doesn't have, but many new systems use. e.g. recent troubles as Fedora
Core 5 doesn't ship Tcl/Tk 8.3 anymore.

I would suggest to branch off a 6.1.0 branch in CVS to
not kill momentum in the HEAD. Important fixes can then
be merged if needed. From that branch we get out one or
two beta tarballs, then release candidates and finally
the 6.1.0 version.

is a full branch really needed? I don't think it is much to declare a
"freeze" for two weeks and just tag beta1 now, beta2 in 1 week, and
6.1.0 in two weeks. I guess my real question is do we want to provide
support the 6.1.0 line? If so, a branch is fine, if not I suggest we
freeze HEAD and use tags.

If there are no objections, I'll branch right away.
Development continues in HEAD as before and we can
extract a first 6.1.0beta for packagers and testers.

Further discussion:
* The x11-less GRASS can be developed in HEAD, we should
  not wait for that. We can have 6.1.1 if desired in near
  future. The same applies to the georectifier.

* NVIZ/Mac issues we can port from HEAD if they get fixed.
  Apparently it's more related to openGL than GRASS.

* snprintf(): much discussion, no result. We can backport
  once it happens.

all this is fine with me.

* other open issues which are *really* showstoppers for
  a 6.1.0 unstable release?

no major issues I know of. If any exist, they should be given a high
priority and thus be at the top of this list:

http://intevation.de/rt/webrt?q_sort=priority&q_reverse=1&q_queue=grass

An announcement is drafted at
http://grass.itc.it/announces/announce_grass610.html
The list of changes should be almost up to date, please
review and add missing items. Also the wording of the
first part could be more press release like.

re. the first part: (I'm no press release writer, but..)

"A feature release"
I have no idea what this means vs. a "new release". 5.7.0 was a
"development preview release" -- do you think that is too scary?

"is a Geographical Information System (GIS) used for data management,
image processing, graphics production, spatial modeling, and
visualization of raster, vector and sites data."

Using "data management" as first point is boring and not to the point of
GRASS. Rename "sites data"? (keep idea)

.. ok, reading on I see it needs work .. I'll try to put obvious fixes
in CVS rather than commenting here.

* is the updates section from cvs2cl.pl or from memory? (more eyes needed?)

* we should update roadmap.html before final 6.1.0 release.

Nicholas wrote:

  Selected Bugfixes (see ChangeLog for details)

   - Source code quality/libraries:
      - GRASS is now ANSI C compliant
      - Ported natively to MS-Windows (MinGW based)
               ^^^^^^^^^^^^^^^^^^^^^^

Actually points to a page (owned by Markus Neteler) that
points to a page for downloading QGIS.

      - GRASS is now ANSI C compliant

is this 100% true?

      - Ported natively to MS-Windows (MinGW based)

maybe change to "Raster and vector engines ported to native MS-Windows
(MinGW based). GUI access available using QGIS."
?

Hamish

5

On Jul 3, 2006, at 11:26 PM, Hamish wrote:

Markus wrote:

Hi developers,

I think that the current GRASS 6.1-CVS is in a good condition
to be released as GRASS 6.1.0. This will pave the way for
GRASS 6.2.0 (stable) which may follow shortly.

horray!
(outstanding issues for me: fix ps.map vlegend patterns bug and finish
last i.vpoints details)

recycled comments:
Currently 6.0.2. is the most recent release (22 Feb 2006), but the last
release including new features was 6.0.0 (10 March 2005). But that had
a feature freeze since 1 Jan 2005(?). So as far as stable users are
concerned we haven't added a single new feature since late 2004. I am
sure you will agree that there have been some improvements since then!

we did a similar 5.7.0 development release:
http://grass.ibiblio.org/announces/announce_grass570.html

Besides it generally being a good idea; and too long since the last; it
is important to have a known delta to check against when reworking a
major library (eg display drivers); the Debian package freeze is fast
approaching and they will only package a point release.

Plus support for 64bit, TclTk 8.4, FFTW2, etc etc.. support which 6.0
doesn't have, but many new systems use. e.g. recent troubles as Fedora
Core 5 doesn't ship Tcl/Tk 8.3 anymore.

I would suggest to branch off a 6.1.0 branch in CVS to
not kill momentum in the HEAD. Important fixes can then
be merged if needed. From that branch we get out one or
two beta tarballs, then release candidates and finally
the 6.1.0 version.

is a full branch really needed? I don't think it is much to declare a
"freeze" for two weeks and just tag beta1 now, beta2 in 1 week, and
6.1.0 in two weeks. I guess my real question is do we want to provide
support the 6.1.0 line? If so, a branch is fine, if not I suggest we
freeze HEAD and use tags.

If there are no objections, I'll branch right away.
Development continues in HEAD as before and we can
extract a first 6.1.0beta for packagers and testers.

Further discussion:
* The x11-less GRASS can be developed in HEAD, we should
  not wait for that. We can have 6.1.1 if desired in near
  future. The same applies to the georectifier.

* NVIZ/Mac issues we can port from HEAD if they get fixed.
  Apparently it's more related to openGL than GRASS.

* snprintf(): much discussion, no result. We can backport
  once it happens.

all this is fine with me.

* other open issues which are *really* showstoppers for
  a 6.1.0 unstable release?

v.in.ascii has a recently introduced bug that needs to be fixed before a release (#4769),
it does not read larger files anymore. For me and some other users it is a showstopper.
(Andy has provided a patch but it has some problem - so there is more work needed to get
this fixed.)

Some modules have problems running on 64bit (maybe that is also #4725? but it is for sure
#4546 and supposedly also r.sun - probably due to uninitialized variables).
I don't think that this should stop the release.
Also I believe that we should thoroughly test gis.m before release -
we were getting all kinds of error messages but I think that it all has been fixed by now.

Helena

no major issues I know of. If any exist, they should be given a high
priority and thus be at the top of this list:

http://intevation.de/rt/webrt?q_sort=priority&q_reverse=1&q_queue=grass

An announcement is drafted at
http://grass.itc.it/announces/announce_grass610.html
The list of changes should be almost up to date, please
review and add missing items. Also the wording of the
first part could be more press release like.

re. the first part: (I'm no press release writer, but..)

"A feature release"
I have no idea what this means vs. a "new release". 5.7.0 was a
"development preview release" -- do you think that is too scary?

"is a Geographical Information System (GIS) used for data management,
image processing, graphics production, spatial modeling, and
visualization of raster, vector and sites data."

Using "data management" as first point is boring and not to the point of
GRASS. Rename "sites data"? (keep idea)

.. ok, reading on I see it needs work .. I'll try to put obvious fixes
in CVS rather than commenting here.

* is the updates section from cvs2cl.pl or from memory? (more eyes needed?)

* we should update roadmap.html before final 6.1.0 release.

Nicholas wrote:

  Selected Bugfixes (see ChangeLog for details)

   - Source code quality/libraries:
      - GRASS is now ANSI C compliant
      - Ported natively to MS-Windows (MinGW based)
               ^^^^^^^^^^^^^^^^^^^^^^

Actually points to a page (owned by Markus Neteler) that
points to a page for downloading QGIS.

      - GRASS is now ANSI C compliant

is this 100% true?

      - Ported natively to MS-Windows (MinGW based)

maybe change to "Raster and vector engines ported to native MS-Windows
(MinGW based). GUI access available using QGIS."
?

Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

6

nicholas.g.lawrence@mainroads.qld.gov.au wrote on 07/04/2006 02:14 AM:

An announcement is drafted at
http://grass.itc.it/announces/announce_grass610.html
The list of changes should be almost up to date, please
review and add missing items. Also the wording of the
first part could be more press release like.
   
I notice that the link at

  Selected Bugfixes (see ChangeLog for details)

   - Source code quality/libraries:
      - GRASS is now ANSI C compliant
      - Ported natively to MS-Windows (MinGW based)
               ^^^^^^^^^^^^^^^^^^^^^^

Actually points to a page (owned by Markus Neteler) that
points to a page for downloading QGIS.

QGIS and GRASS are integrated there into a single package (for the ease
of installation):
qgis-grass-0.8.0-preview-win32-060605.zip.torrent
<http://gisalaska.com/torrents/qgis-grass-0.8.0-preview-win32-060605.zip.torrent&gt;
37Mb Windows 0.8 PreviewJune 5 2006 QGIS+GRASS

I hope to get assistance to build the package weekly on grass.itc.it or
to fetch it
weekly from someone else.

Markus

7

Are the any (detailed) instructions for how to build and package
a native QGIS + GRASS distribution from the regular GRASS CVS
repository?

I would love to add my archaeology modules and produce a version
of GRASS for my colleagues working on Win32 systems.
I am sure this could hit big in a science with low budget and
very specific GIS needs.

Best,

Benjamin

Markus Neteler wrote:

nicholas.g.lawrence@mainroads.qld.gov.au wrote on 07/04/2006 02:14 AM:

An announcement is drafted at
http://grass.itc.it/announces/announce_grass610.html
The list of changes should be almost up to date, please
review and add missing items. Also the wording of the
first part could be more press release like.
  
I notice that the link at

Selected Bugfixes (see ChangeLog for details)

  - Source code quality/libraries:
     - GRASS is now ANSI C compliant
     - Ported natively to MS-Windows (MinGW based)
              ^^^^^^^^^^^^^^^^^^^^^^

Actually points to a page (owned by Markus Neteler) that
points to a page for downloading QGIS.

QGIS and GRASS are integrated there into a single package (for the ease
of installation):
qgis-grass-0.8.0-preview-win32-060605.zip.torrent
<http://gisalaska.com/torrents/qgis-grass-0.8.0-preview-win32-060605.zip.torrent&gt;
37Mb Windows 0.8 PreviewJune 5 2006 QGIS+GRASS

I hope to get assistance to build the package weekly on grass.itc.it or
to fetch it
weekly from someone else.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

8

Benjamin Ducke wrote on 07/04/2006 09:41 AM:

Are the any (detailed) instructions for how to build and package
a native QGIS + GRASS distribution from the regular GRASS CVS
repository?

Yes. The document is here:
http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux

I have added the link to
http://mpa.itc.it/radim/wingrass/

I would love to add my archaeology modules and produce a version
of GRASS for my colleagues working on Win32 systems.
I am sure this could hit big in a science with low budget and
very specific GIS needs.

Definitely. But also to show that even in case of a high budget the
proposed solution is interesting for various reasons :slight_smile:

Markus

9

Hello Benjamin,

On Tue, 04 Jul 2006 09:41:18 +0200 Benjamin Ducke
<benjamin.ducke@ufg.uni-kiel.de> wrote:

Are the any (detailed) instructions for how to build and package
a native QGIS + GRASS distribution from the regular GRASS CVS
repository?

I would love to add my archaeology modules and produce a version
of GRASS for my colleagues working on Win32 systems.
I am sure this could hit big in a science with low budget and
very specific GIS needs.

lemmi jump in here and give you the link to Radims detailed description
how to build GRASS/QGIS on windows[1].

Best
  Stephan

[1] http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux

Markus Neteler wrote:
> nicholas.g.lawrence@mainroads.qld.gov.au wrote on 07/04/2006 02:14
> AM:
>
>
>>>An announcement is drafted at
>>>http://grass.itc.it/announces/announce_grass610.html
>>>The list of changes should be almost up to date, please
>>>review and add missing items. Also the wording of the
>>>first part could be more press release like.
>>>
>>>
>>
>>I notice that the link at
>>
>> Selected Bugfixes (see ChangeLog for details)
>>
>> - Source code quality/libraries:
>> - GRASS is now ANSI C compliant
>> - Ported natively to MS-Windows (MinGW based)
>> ^^^^^^^^^^^^^^^^^^^^^^
>>
>>Actually points to a page (owned by Markus Neteler) that
>>points to a page for downloading QGIS.
>>
>>
>
>
> QGIS and GRASS are integrated there into a single package (for the
> ease of installation):
> qgis-grass-0.8.0-preview-win32-060605.zip.torrent
> <http://gisalaska.com/torrents/qgis-grass-0.8.0-preview-win32-060605.zip.torrent&gt;
> 37Mb Windows 0.8 PreviewJune 5 2006 QGIS+GRASS
>
> I hope to get assistance to build the package weekly on
> grass.itc.it or to fetch it
> weekly from someone else.
>
> Markus
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>
>

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

10

On Tue, 2006-07-04 at 00:26 -0400, Helena Mitasova wrote:

v.in.ascii has a recently introduced bug that needs to be fixed
before a release (#4769),
it does not read larger files anymore. For me and some other users it
is a showstopper.
(Andy has provided a patch but it has some problem - so there is more
work needed to get this fixed.)

I've had this done for some time, but I forgot to commit it. Just
committed, but please test to make sure large files work again.

--
Brad Douglas <rez touchofmadness com> KB8UYR
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

11

Brad Douglas wrote on 07/04/2006 11:48 AM:

On Tue, 2006-07-04 at 00:26 -0400, Helena Mitasova wrote:

v.in.ascii has a recently introduced bug that needs to be fixed
before a release (#4769),
it does not read larger files anymore. For me and some other users it
is a showstopper.
(Andy has provided a patch but it has some problem - so there is more
work needed to get this fixed.)
   
I've had this done for some time, but I forgot to commit it. Just
committed, but please test to make sure large files work again.

Brad,
thanks for committing. Helena however meant *v*.in.ascii, a different
story. I hope
that Andrew finishes the bugfix he prepared:
http://intevation.de/rt/webrt?serial_num=4769&display=History

Ah, I just see that he submitted a new patch. I would need that as personal
email since RT isn't suitable to maintain/extract patches.

Markus

12

Markus,

The updated patch for v.in.ascii is attached.

-Andy

On Tue, 2006-07-04 at 12:03 +0200, Markus Neteler wrote:

Brad Douglas wrote on 07/04/2006 11:48 AM:

>On Tue, 2006-07-04 at 00:26 -0400, Helena Mitasova wrote:
>
>
>>v.in.ascii has a recently introduced bug that needs to be fixed
>>before a release (#4769),
>>it does not read larger files anymore. For me and some other users it
>>is a showstopper.
>>(Andy has provided a patch but it has some problem - so there is more
>>work needed to get this fixed.)
>>
>>
>
>I've had this done for some time, but I forgot to commit it. Just
>committed, but please test to make sure large files work again.
>
>

Brad,
thanks for committing. Helena however meant *v*.in.ascii, a different
story. I hope
that Andrew finishes the bugfix he prepared:
http://intevation.de/rt/webrt?serial_num=4769&display=History

Ah, I just see that he submitted a new patch. I would need that as personal
email since RT isn't suitable to maintain/extract patches.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

(attachments)

v_in_ascii_points_c.udiff-2.patch (2.13 KB)

13

On Tue, Jul 04, 2006 at 03:26:32PM +1200, Hamish wrote:

Markus wrote:

Hi developers,

I think that the current GRASS 6.1-CVS is in a good condition
to be released as GRASS 6.1.0. This will pave the way for
GRASS 6.2.0 (stable) which may follow shortly.

horray!
(outstanding issues for me: fix ps.map vlegend patterns bug and finish
last i.vpoints details)

Hamish: what's your time line for this?

[... some additions made to announcement from H's comments...]

I would suggest to branch off a 6.1.0 branch in CVS to
not kill momentum in the HEAD. Important fixes can then
be merged if needed. From that branch we get out one or
two beta tarballs, then release candidates and finally
the 6.1.0 version.

is a full branch really needed? I don't think it is much to declare a
"freeze" for two weeks and just tag beta1 now, beta2 in 1 week, and
6.1.0 in two weeks.

I don't like this idea too much for three reasons
- some developer will still commit
- we kill momentum since betas could be delayed
- backporting *important* issues isn't that hard (we did it successfully for 5.4 and 6.0)

Let's keep it decoupled. Keep in mind that it is 6.1.0, not 6.2.0!

I guess my real question is do we want to provide
support the 6.1.0 line? If so, a branch is fine, if not I suggest we
freeze HEAD and use tags.

IMHO, doing that on a tag can become pretty messy.

If there are no objections, I'll branch right away.
Development continues in HEAD as before and we can
extract a first 6.1.0beta for packagers and testers.

Further discussion:
* The x11-less GRASS can be developed in HEAD, we should
not wait for that. We can have 6.1.1 if desired in near
future. The same applies to the georectifier.

* NVIZ/Mac issues we can port from HEAD if they get fixed.
Apparently it's more related to openGL than GRASS.

* snprintf(): much discussion, no result. We can backport
once it happens.

all this is fine with me.

I have added G_snprintf() to lib/gis/ and changed all usages of
snprintf() to G_snprintf().
See related
https://intevation.de/rt/webrt?serial_num=1140&display=History

Paul is working on that now. G_snprintf() submitted to CVS.

Helena mentioned v.in.ascii as show-stopper:
Andrew fixed it, patch applied.

An announcement is drafted at
http://grass.itc.it/announces/announce_grass610.html
The list of changes should be almost up to date, please
review and add missing items. Also the wording of the
first part could be more press release like.

re. the first part: (I'm no press release writer, but..)

"A feature release"
I have no idea what this means vs. a "new release". 5.7.0 was a
"development preview release" -- do you think that is too scary?

Maybe too scary?

"is a Geographical Information System (GIS) used for data management,
image processing, graphics production, spatial modeling, and
visualization of raster, vector and sites data."

changed to
"used for spatial modeling, visualization of raster and vector data, data
management, image processing, and graphics production.
"

Using "data management" as first point is boring and not to the point of
GRASS. Rename "sites data"? (keep idea)

sites removed.

.. ok, reading on I see it needs work .. I'll try to put obvious fixes
in CVS rather than commenting here.

thanks

* is the updates section from cvs2cl.pl or from memory? (more eyes needed?)

I used cvs2cl.pl, then selected stuff manually (quite time consuming). Yes,
more eyes needed, but we should reflect only relevant changes which is not
always easy to decide.

* we should update roadmap.html before final 6.1.0 release.

Sounds good... but we would need to follow that roadmap then which rarely
happened in the past. :slight_smile:

     - GRASS is now ANSI C compliant

is this 100% true?

I dunno - but maybe we are already happy with 95% (rounding error).

     - Ported natively to MS-Windows (MinGW based)

maybe change to "Raster and vector engines ported to native MS-Windows
(MinGW based). GUI access available using QGIS."
?

You can also use much of winGRASS from "command.com". I didn't
try tcltk since I don't have a modifyable Windows version here.
winGRASS runs also without QGIS. But a bit more text is needed
in the announcement.

Markus

14

On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote:
...

Some modules have problems running on 64bit (maybe that is also
#4725?

The nviz volume bug was recently introduces, I think. As far
as I remember it worked some time ago on 64bit.

https://intevation.de/rt/webrt?serial_num=4725
"
  I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode()
  and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost.
"

?

but it is for sure #4546

https://intevation.de/rt/webrt?serial_num=4546
r.sim.water crashes in simlib/input.c line 403, function grad_check():

if (cchez[k][l] != 0.) {

   with k=700 and l=0

Not sure why.

and supposedly also r.sun - probably due to uninitialized
variables).

Right, It crashes in INPUT () at main.c:656
              if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == UNDEFZ)

Here a Spearfish test script:

ELEV=elevation.dem
TMP=$$
SLOPE=$TMP.slope
ASP=$TMP.aspect
r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o
r.mapcalc global_shadow.rad=0
DAY=055
r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \
      beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY

I don't think that this should stop the release.

I would appreciate if those two bugs would be fixed, but we
can backport the fixes later.

Also I believe that we should thoroughly test gis.m before release -
we were getting all kinds of error messages but I think that it all
has been fixed by now.

Yes, gis.m should get a consolidation cycle now.

Markus

15

Stephan Holl wrote:

> Are the any (detailed) instructions for how to build and package
> a native QGIS + GRASS distribution from the regular GRASS CVS
> repository?
>
> I would love to add my archaeology modules and produce a version
> of GRASS for my colleagues working on Win32 systems.
> I am sure this could hit big in a science with low budget and
> very specific GIS needs.

lemmi jump in here and give you the link to Radims detailed description
how to build GRASS/QGIS on windows[1].

It would be more useful to have a guide to building a native Windows
version on Windows, rather than having to cross-compile.

Also, it would be useful to offer pre-compiled Windows binaries of
essential libraries (proj, GDAL etc).

--
Glynn Clements <glynn@gclements.plus.com>

16

I have one request concerning the GRASS configure script:
would it be possible for configure to write a small one-line
ASCII file into GISBASE/etc after a successful configuration,
which contains all the options that the user passed to the
configure script?

Having such a file in a standard location would make it
much easier to compile external modules with exactly the
same external dependencies as the GRASS system installation.

Best,

Benjamin

Markus Neteler wrote:

On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote:
...

Some modules have problems running on 64bit (maybe that is also #4725?

The nviz volume bug was recently introduces, I think. As far
as I remember it worked some time ago on 64bit.

https://intevation.de/rt/webrt?serial_num=4725
" I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode()
  and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost.
"

?

but it is for sure #4546

https://intevation.de/rt/webrt?serial_num=4546
r.sim.water crashes in simlib/input.c line 403, function grad_check():

if (cchez[k][l] != 0.) {

   with k=700 and l=0

Not sure why.

and supposedly also r.sun - probably due to uninitialized variables).

Right, It crashes in INPUT () at main.c:656
              if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] == UNDEFZ)

Here a Spearfish test script:

ELEV=elevation.dem
TMP=$$
SLOPE=$TMP.slope
ASP=$TMP.aspect
r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o
r.mapcalc global_shadow.rad=0
DAY=055
r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \
      beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY

I don't think that this should stop the release.

I would appreciate if those two bugs would be fixed, but we
can backport the fixes later.

Also I believe that we should thoroughly test gis.m before release -
we were getting all kinds of error messages but I think that it all has been fixed by now.

Yes, gis.m should get a consolidation cycle now.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

17

Benjamin,

I don't think this would work for precompiled binaries. They may be
installed on a system that doesn't have some of the dependencies. For
example, you can compile with MySQL support and then put GRASS on a system
without MySQL.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
Date: Wed, 05 Jul 2006 10:20:56 +0200
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GRASS 6.1.0 release preparation

I have one request concerning the GRASS configure script:
would it be possible for configure to write a small one-line
ASCII file into GISBASE/etc after a successful configuration,
which contains all the options that the user passed to the
configure script?

Having such a file in a standard location would make it
much easier to compile external modules with exactly the
same external dependencies as the GRASS system installation.

Best,

Benjamin

Markus Neteler wrote:

On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote:
...

Some modules have problems running on 64bit (maybe that is also
#4725?

The nviz volume bug was recently introduces, I think. As far
as I remember it worked some time ago on 64bit.

https://intevation.de/rt/webrt?serial_num=4725
"
  I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode()
  and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost.
"

?

but it is for sure #4546

https://intevation.de/rt/webrt?serial_num=4546
r.sim.water crashes in simlib/input.c line 403, function grad_check():

if (cchez[k][l] != 0.) {

   with k=700 and l=0

Not sure why.

and supposedly also r.sun - probably due to uninitialized
variables).

Right, It crashes in INPUT () at main.c:656
              if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] ==
UNDEFZ)

Here a Spearfish test script:

ELEV=elevation.dem
TMP=$$
SLOPE=$TMP.slope
ASP=$TMP.aspect
r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o
r.mapcalc global_shadow.rad=0
DAY=055
r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope day=$DAY \
      beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY

I don't think that this should stop the release.

I would appreciate if those two bugs would be fixed, but we
can backport the fixes later.

Also I believe that we should thoroughly test gis.m before release -
we were getting all kinds of error messages but I think that it all
has been fixed by now.

Yes, gis.m should get a consolidation cycle now.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

18

Helena wrote:

Some modules have problems running on 64bit (maybe that is also #4725?

4725 (NVIZ segfaults with volumes) happens for me on a 32-bit P4 using
both TclTk 8.3 and 8.4.

https://intevation.de/rt/webrt?serial_num=4725

Hamish

19

On Wed, Jul 05, 2006 at 10:20:56AM +0200, Benjamin Ducke wrote:

I have one request concerning the GRASS configure script:
would it be possible for configure to write a small one-line
ASCII file into GISBASE/etc after a successful configuration,
which contains all the options that the user passed to the
configure script?

Hi,

not sure if such line would be portable. But you could fetch
it here:

head -7 config.status | tail -1

Markus

Having such a file in a standard location would make it
much easier to compile external modules with exactly the
same external dependencies as the GRASS system installation.

Best,

Benjamin

Markus Neteler wrote:
>On Tue, Jul 04, 2006 at 12:26:16AM -0400, Helena Mitasova wrote:
>...
>
>>Some modules have problems running on 64bit (maybe that is also
>>#4725?
>
>
>The nviz volume bug was recently introduces, I think. As far
>as I remember it worked some time ago on 64bit.
>
>https://intevation.de/rt/webrt?serial_num=4725
>"
> I followed "mode" into lib/ogsf/GVL2.c GVL_slice_get_drawmode()
> and then *gvl to gvl_get_vol() in lib/ogsf/gvl.c, but then I get lost.
>"
>
>?
>
>
>>but it is for sure #4546
>
>
>https://intevation.de/rt/webrt?serial_num=4546
>r.sim.water crashes in simlib/input.c line 403, function grad_check():
>
> if (cchez[k][l] != 0.) {
>
> with k=700 and l=0
>
>Not sure why.
>
>
>
>>and supposedly also r.sun - probably due to uninitialized
>>variables).
>
>
>Right, It crashes in INPUT () at main.c:656
> if (z[i][j] == UNDEFZ || o[i][j] == UNDEFZ || s[i][j] ==
> UNDEFZ)
>
>Here a Spearfish test script:
>
>ELEV=elevation.dem
>TMP=$$
>SLOPE=$TMP.slope
>ASP=$TMP.aspect
>r.slope.aspect elevation.dem as=$TMP.aspect sl=$TMP.slope --o
>r.mapcalc global_shadow.rad=0
>DAY=055
>r.sun -s elevin=elevation.dem aspin=$TMP.aspect slopein=$TMP.slope
>day=$DAY \
> beam_rad=bs_rad.$DAY diff_rad=ds_rad.$DAY refl_rad=rs_rad.$DAY
>
>
>
>
>>I don't think that this should stop the release.
>
>
>I would appreciate if those two bugs would be fixed, but we
>can backport the fixes later.
>
>
>>Also I believe that we should thoroughly test gis.m before release -
>>we were getting all kinds of error messages but I think that it all
>>has been fixed by now.
>
>
>Yes, gis.m should get a consolidation cycle now.
>
>Markus
>
>
>_______________________________________________
>grass-dev mailing list
>grass-dev@grass.itc.it
>http://grass.itc.it/mailman/listinfo/grass-dev
>
>

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

20

On Tue, Jul 04, 2006 at 08:53:43PM +0100, Glynn Clements wrote:

Stephan Holl wrote:

> > Are the any (detailed) instructions for how to build and package
> > a native QGIS + GRASS distribution from the regular GRASS CVS
> > repository?
> >
> > I would love to add my archaeology modules and produce a version
> > of GRASS for my colleagues working on Win32 systems.
> > I am sure this could hit big in a science with low budget and
> > very specific GIS needs.
>
> lemmi jump in here and give you the link to Radims detailed description
> how to build GRASS/QGIS on windows[1].

It would be more useful to have a guide to building a native Windows
version on Windows, rather than having to cross-compile.

Agreed. Do you have a suggestion for a free (freedom) compiler?
Maybe obvious, but I am not informed.

Also, it would be useful to offer pre-compiled Windows binaries of
essential libraries (proj, GDAL etc).

These could be published as by-product of GRASS, for now as
cross-compiled version. There is however an outstanding issue with
proj (nad2nad is not called within MinGW, so the NAD grid import fails
when cross-compiling).

Markus