[GRASS-dev] [GRASS-SVN] r56622 - grass/branches/develbranch_6/mswindows

neteler · June 6, 2013, 7:58am

Hi,

let's backport to relbranch64 immediately. Otherwise it is hard to test
if if also works there. Please let us not delay things forever.

thanks.

Markus

On Thu, Jun 6, 2013 at 4:09 AM, <svn_grass@osgeo.org> wrote:

Author: hamish
Date: 2013-06-05 19:09:55 -0700 (Wed, 05 Jun 2013)
New Revision: 56622

Modified:
grass/branches/develbranch_6/mswindows/env.bat
Log:
default to explictly using GRASS's bundled python.exe to avoid startup breakage

Modified: grass/branches/develbranch_6/mswindows/env.bat

--- grass/branches/develbranch_6/mswindows/env.bat 2013-06-06 01:15:42 UTC (rev 56621)
+++ grass/branches/develbranch_6/mswindows/env.bat 2013-06-06 02:09:55 UTC (rev 56622)
@@ -1,7 +1,7 @@
rem Environmental variables for GRASS stand-alone installer

set GRASS_WISH=%GISBASE%\extrabin\wish.exe
-set GRASS_PYTHON=python
+set GRASS_PYTHON=%GISBASE%\extrabin\python.exe
set GRASS_PROJSHARE=%GISBASE%\proj
set GRASS_HTML_BROWSER=explorer
set GRASS_SH=%GISBASE%\msys\bin\sh.exe

_______________________________________________
grass-commit mailing list
grass-commit@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit

Hamish · June 6, 2013, 8:16am

> Author: hamish
> Date: 2013-06-05 19:09:55 -0700 (Wed, 05 Jun 2013)
> New Revision: 56622
> Modified: grass/branches/develbranch_6/mswindows/env.bat
> Log:
> default to explictly using GRASS's bundled python.exe
> to avoid startup breakage

Markus N wrote:

let's backport to relbranch64 immediately. Otherwise it is
hard to test if if also works there. Please let us not delay
things forever.

the change was checked in a couple hours before the nightly build
rolled around. The plan was to wait for that, try it, then
backport. Total turn around time <12 hours.

I don't believe in backporting something* to the stable branch
that I haven't already tried in situ. The closer to a deadline
the stricter I'd be about that. (* aka sign off on)

regards,
Hamish

neteler · June 6, 2013, 8:46am

On Thu, Jun 6, 2013 at 10:16 AM, Hamish <hamish_b@yahoo.com> wrote:

> Author: hamish
> Date: 2013-06-05 19:09:55 -0700 (Wed, 05 Jun 2013)
> New Revision: 56622
> Modified: grass/branches/develbranch_6/mswindows/env.bat
> Log:
> default to explictly using GRASS's bundled python.exe
> to avoid startup breakage

Markus N wrote:

let's backport to relbranch64 immediately. Otherwise it is
hard to test if if also works there. Please let us not delay
things forever.

the change was checked in a couple hours before the nightly build
rolled around. The plan was to wait for that, try it, then
backport. Total turn around time <12 hours.

I don't believe in backporting something* to the stable branch
that I haven't already tried in situ.

If it works for you, it does not necessarily work for others.
We need to widen up the tests and as observed, the devgrass6
branch isn't widely used.

The closer to a deadline the stricter I'd be about that. (* aka sign off on)

We are past the deadline. And we will have to create a RC4 due to
heavy changes done *after* RC3.
Please keep in mind that we will have 6.4.4, too.

regards,

Markus

hellik · June 6, 2013, 9:08am

Hamish:

the change was checked in a couple hours before the nightly build
rolled around. The plan was to wait for that, try it, then
backport. Total turn around time <12 hours.

I don't believe in backporting something* to the stable branch
that I haven't already tried in situ.

Markus N:

If it works for you, it does not necessarily work for others.
We need to widen up the tests and as observed, the devgrass6
branch isn't widely used.

I concur with Markus, normally I test/work with releasebranch and trunk,
nearly never with develbranch6. and after some screening the mailing lists
the users may do the same. IMHO a wider testing will only happen with
releasebranch...

And we will have to create a RC4 due to
heavy changes done *after* RC3.

grass6.4.3 should go out soon.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r56622-grass-branches-develbranch-6-mswindows-tp5058304p5058333.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

Hamish · June 6, 2013, 11:37am

Helmut:

grass6.4.3 should go out soon.

sure, the last major thing standing in the way of release IMO,
and the only thing I want to focus energy on, is just this:

https://trac.osgeo.org/grass/ticket/943

probably just some popen.?() pipe handling needed before the
popen.communicate(). Perhaps popen.poll() can help debug?

popen.communicate() will stall if one of the pipes fills up
(I don't think d.mon could output that much in normal operation,
maybe if a stream of X errors), or if the program hasn't
terminated yet.

--

any ideas on where/who controls this part of the wingrass
packaging:
?

> #1952: package 'more.exe' with msys (pager for g.list)
> (also +tac.exe +seq.exe +xml2.exe and
>> #1275 (about zip.exe)
> --what controls what unix powertools are packaged
> in extrabin/?

?

zip is there, but unzip (for r.in.srtm) is not.

xml2.exe makes a big difference for r.in.wms[.sh] which
*now works on wingrass* (!!) / except for the xml2

seq we could live without but it is nice.
same for tac, we work around it missing for Mac as well.

but if we figure out how to add one binary we could easily
add them all.

MarkusN:

> And we will have to create a RC4 due to
> heavy changes done *after* RC3.

the code base is now in much better shape on many fronts,
and the end result will be something we can all be quite proud
of and excited about. Frankly, RC3 on Wingrass was badly broken
in a number of ways and that needed to be fixed regardless of
the cost; now it basically is and we can move on.

thanks,
Hamish

martinl · June 6, 2013, 11:44am

Hi,

2013/6/6 Hamish <hamish_b@yahoo.com>:

any ideas on where/who controls this part of the wingrass
packaging:
?

> #1952: package 'more.exe' with msys (pager for g.list)
> (also +tac.exe +seq.exe +xml2.exe and
>> #1275 (about zip.exe)
> --what controls what unix powertools are packaged
> in extrabin/?

it's related to `msys` packages from OSGeo4W which I maintain [1]. I
am planning to upgrade this package, currently *no* time for that. We
can (probably Helmut) add these tools manually to the standalone
installer at this moment. It's not really a blocker. Even we can
provide updated standalone installer later after releasing GRASS (-2,
-3, etc).

Martin

[1] http://trac.osgeo.org/osgeo4w/wiki/pkg-msys