Hi all,
it is about time to get 6.4.3 out of the doors. It would be nice to have
a RC1 for the upcoming Geostat 2012 in Muenster (full day of GRASS
teaching).
Here is the current state of the art:
http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0
There are a few blockers which need action but should not be a
showstopper for RC1.
Markus
Markus wrote:
it is about time to get 6.4.3 out of the doors. It would be nice to have
a RC1 for the upcoming Geostat 2012 in Muenster (full day of GRASS
teaching).
when is that?
Here is the current state of the art:
http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0There are a few blockers which need action but should not be
a showstopper for RC1.
AFAIAC the few things I would like to fix & consider blockers for
6.4.3 are:
* finish audit of scripts for safe handling of eval `g.gisenv` in case
someone put something they shouldn't in here (like addon path). I already
agreed to look at that.
* related/ ensuring that the gui uses the environment variable for addon
path and not g.gisenv variable. (which besides breaking things is entirely
redundant AFAIK and confusing, just set it in one place, properly) I'm
not sure if that has been backported from devbr6 to releasebranch64 or
not; hopefully not from my POV.
* the ps.map gui composer in unreleased svn is currently using an eps
mode to draw north arrow decorations instead of the 'point' instruction
directly. the redundant eps north arrows should be removed before they
are used in an official release and the method is locked in for backwards
compatibility. Even if no one else cares about that, I do, so it is
probably up to me to fix & convert the better qgis north arrows to the
grass symbol format as needed.
anything non-gui-only which isn't strictly a bug fix only should be
identified in the changelog and have discussion about it. (e.g. style
changes to g.version stdout output, which user scripts might be [will be]
parsing; if we should backport new python functions like mapcalc_start()
which allow backgrounding jobs for python parallelization, or not)
thanks,
Hamish
Hi,
* the ps.map gui composer in unreleased svn is currently using an eps
mode to draw north arrow decorations instead of the 'point' instruction
directly. the redundant eps north arrows should be removed before they
are used in an official release and the method is locked in for backwards
compatibility. Even if no one else cares about that, I do, so it is
probably up to me to fix & convert the better qgis north arrows to the
grass symbol format as needed.
I can fix this in the composer, of course. Adding north arrow would
show a dialog for adding points (this dialog is used for adding
graphics like points, lines, rectangles) which would be slightly
modified for north arrows (like changing the dialog title and so).
Here, it would help me if the directory structure of the symbols is
changed so that the arrows would be located in separate directory
(basic, extra, ..., north_arrow). This way I can show the user only
the north arrow symbols. Other option is not very elegant - I would
have to find all symbols from all directories containing words arrow
or compass.
Regards,
Anna
On Fri, Aug 17, 2012 at 2:03 PM, Markus Neteler <neteler@osgeo.org> wrote:
Hi all,
it is about time to get 6.4.3 out of the doors. It would be nice to have
a RC1 for the upcoming Geostat 2012 in Muenster (full day of GRASS
teaching).Here is the current state of the art:
After the recent day's hyperactivity the list looks pretty good now:
http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0
We are getting close to RC1 to widen up the number of testers.
Markus
On Thu, Aug 23, 2012 at 9:58 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Fri, Aug 17, 2012 at 2:03 PM, Markus Neteler <neteler@osgeo.org> wrote:
Hi all,
it is about time to get 6.4.3 out of the doors. It would be nice to have
a RC1 for the upcoming Geostat 2012 in Muenster (full day of GRASS
teaching).Here is the current state of the art:
After the recent day's hyperactivity the list looks pretty good now:
http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0We are getting close to RC1 to widen up the number of testers.
I have backported various bugfixes from devbr6 related to buffer
overflow. Some bugfixes also needed to be forward ported to trunk. It
would make maintenance much easier if bugs were fixed in trunk first,
then in devbr6 and relbr64. The fixes for these buffer overflows are
simple enough, there is IMHO no reason to apply them in devbr6 and
then risk to forget about them.
Markus M
On Fri, Aug 17, 2012 at 2:03 PM, Markus Neteler <neteler@osgeo.org> wrote:
Hi all,
it is about time to get 6.4.3 out of the doors.
...
Here is the current state of the art:
http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0
The situation is pretty good now. Please revisit the list again.
Markus
I think it is still not possible to add volumes to GIS manager - I will file a bug report and include Michael's notes
(unless Michael does it before I get to it)
Helena
Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”
On Sep 6, 2012, at 6:20 PM, Markus Neteler wrote:
On Fri, Aug 17, 2012 at 2:03 PM, Markus Neteler <neteler@osgeo.org> wrote:
Hi all,
it is about time to get 6.4.3 out of the doors.
...
Here is the current state of the art:
http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0The situation is pretty good now. Please revisit the list again.
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
please check again:
Markus
Hi Markus,
2012/10/15 Markus Neteler <neteler@osgeo.org>:
last three blockers closed. I think we could go ahead towards RC1.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Tue, Oct 23, 2012 at 9:05 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi Markus,
2012/10/15 Markus Neteler <neteler@osgeo.org>:
last three blockers closed. I think we could go ahead towards RC1.
Yes, let's go! I can do that in ~ 2 hours from now.
Markus
Hi all,
we may slowly consider 6.4.3RC2 to be prepared.
Here the list of important open issues (as a gentle reminder):
or also with major issues:
http://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=type&order=priority&priority=blocker&priority=critical&priority=major&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0
Best
Markus
Hi again,
should the attached patches be submitted? Please review:
* histogram equalized color rules for raster takes inordinately long to display
http://trac.osgeo.org/grass/ticket/1071
* Profile tool always casts to integers (incl. csv output)
http://trac.osgeo.org/grass/ticket/1424
* error in r.walk help page
http://trac.osgeo.org/grass/ticket/1584
* OS X: Files are installed outside of --prefix
http://trac.osgeo.org/grass/ticket/1644
Unclear state:
* Add a "change language" option in GRASS GUI
http://trac.osgeo.org/grass/ticket/879
Markus
Hi,
2012/11/4 Markus Neteler <neteler@osgeo.org>:
we may slowly consider 6.4.3RC2 to be prepared.
+1 for RC2. Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
we may slowly consider 6.4.3RC2 to be prepared.
+1 for RC2. Martin
maybe it's worth to have a look at:
wingrass6.4.3svn: raster3d problems
http://trac.osgeo.org/grass/ticket/1784
-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/GRASS-6-4-3-release-planning-tp4995930p5015362.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
Hi,
we should get GRASS GIS 6.4.3RC3 out of the doors...
Here the current state of the art:
Please help to check the remaining tickets.
Markus
On Sat, Mar 9, 2013 at 7:25 PM, Markus Neteler <neteler@osgeo.org> wrote:
Hi,
we should get GRASS GIS 6.4.3RC3 out of the doors...
Here the current state of the art:
Please help to check the remaining tickets.
Glad to see that they get continuously less.
Power-Hint for Firefox users: if you want to open a set of tickets in one step
in different browser tabs, enjoy this Addon:
https://addons.mozilla.org/en-US/firefox/addon/multi-links/
To open multiple links, you simply right click and hold to drag a box around
the links to desire to take action on. When you release the right mouse
button, you will open those links.
cheers
Markus
On Sat, Mar 9, 2013 at 7:25 PM, Markus Neteler <neteler@osgeo.org> wrote:
we should get GRASS GIS 6.4.3RC3 out of the doors...
If there are no objections, I can try to prepare RC3 by tomorrow.
Here the current state of the art:
Please help to check the remaining tickets.
Markus
Markus N wrote:
If there are no objections, I can try to prepare RC3 by
tomorrow.
yes please. 
thanks,
Hamish
On Fri, Apr 12, 2013 at 2:50 AM, Hamish <hamish_b@yahoo.com> wrote:
Markus N wrote:
If there are no objections, I can try to prepare RC3 by
tomorrow.yes please.
... since Hamish currently backports more from dev6, I'll
postpone RC3 for some hours or whatever suitable.
Markus
Markus N wrote:
... since Hamish currently backports more from dev6, I'll
postpone RC3 for some hours or whatever suitable.
thanks, I'm done for now, but there's one outstanding difference
between relbr64 and devbr6 for r.watershed that MarkusM might
have a look at (see below). I mostly focused on display/ and
raster/ where most of my changes are. scripts/ and ps/ should
be ok. I tried to just focus on either bugs or simple changes
which were made long long ago so have had tons of testing
already.
Using kdiff3 I notice a few differences in the DB drivers, I
think some extra driver closings and debug experiments were
put into devbr6 for testing zombie dbf.exe errors in WinGrass.
It's probably still worth comparing the two builds on wingrass
to see if they actually help -- aka it will be good to know
what commit definitively fixes it as opposed to guessing that
it might be ok now.
A number or nviz diffs exist too, maybe should be looked at at
some point by the authors. (seems to be Tcl 8.6 api updates, +)
kompare/kdiff3/meld were all a bit annoying to set up with
regex filters to avoid $Date$, OBJ.*, .svn/, dist.*, etc.,
I should write down some notes in the wiki while it's still
fresh in my mind, but it's too late for today.
-->so I'm go for RC3 as soon as r.watershed gets looked at.
regards,
Hamish
---
https://trac.osgeo.org/grass/changeset/54765
https://trac.osgeo.org/grass/changeset/54766
a current diff on raster/r.watershed/ram/do_cum.c, the first
one just seems to be a speedup, the second changes behavior.
--- relbr_6_4/raster/r.watershed/ram/do_cum.c 2013-02-20 17:45:31.877625578 +1300
+++ grass65/raster/r.watershed/ram/do_cum.c 2013-04-12 17:52:36.990693417 +1200
@@ -26,8 +26,8 @@
aspect = asp[this_index];
seg_index_rc(alt_seg, this_index, &r, &c);
if (aspect > 0) {
- dr = r + asp_r[ABS(aspect)];
- dc = c + asp_c[ABS(aspect)];
+ dr = r + asp_r[aspect];
+ dc = c + asp_c[aspect];
}
else
dr = dc = -1;
@@ -149,9 +149,9 @@
seg_index_rc(alt_seg, this_index, &r, &c);
FLAG_SET(worked, r, c);
aspect = asp[this_index];
- if (aspect > 0) {
- dr = r + asp_r[aspect];
- dc = c + asp_c[aspect];
+ if (aspect) {
+ dr = r + asp_r[ABS(aspect)];
+ dc = c + asp_c[ABS(aspect)];
}
else
dr = dc = -1;