[GRASS-dev] [GRASS GIS] #1889: wxPy loc'n wiz: don't auto-launch into PERMANENT

Martin wrote:

good point, more over there were open four blockers in one
day by one person just when we claimed to release RC3 and then
final. We should really change policy in this sense.
Ideally should come two RC in shorter period (two or three
weeks) and then final.
Currently we have RC1 in October, RC2 in December. RC3 who
knows. Sometimes I have impression that there are people who
don't care about releases (which is acceptable) and
people who are in the result blocking (or making releasing
process painful).

I hope you would agree that the goal is to ship the best bug-free
release we can, and that devs reporting bugs pre-release is a much
better situation than users being hit by the same bugs post-release. I don't like the delay or super-long time between releases any more than you do, and understand the frustration, but knowing about important breakage is only a good thing! -- it is a good thing they are found & fixed weeks before release and not in the weeks after!

Those bug reports all came together because it was the first time I'd tried a new install of WinGrass in months, and I was keeping careful notes of the experience of doing it on a new machine as part of the upcoming release testing. I would hope that more people could do this.

Certainly binary release is out of the question until the license violation in the wingrass packages is resolved. The situation is untenable as-is, but pretty easy to fix with an extra page + [yes/no] + wget as a near-last page the nsi installer I think.

Please let's just focus our energy on fixing bugs and so getting the release out..

best,
Hamish

Hi,

2013/3/10 Hamish <hamish_b@yahoo.com>:

[...]

Certainly binary release is out of the question until the license violation in the wingrass packages is resolved. The situation is untenable as-is, but pretty easy to fix with an extra page + [yes/no] + wget as a near-last page the nsi installer I think.

please feel free to work on it. If nobody will fix it, we can release
GRASS without binaries for Windows :wink:

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Martin wrote:

If nobody will fix it, we can release GRASS without binaries for
Windows :wink:

If nobody fixes it, we will have to release GRASS without binaries for Windows :-/

best,
Hamish

#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
-----------------------------+----------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: wxGUI | Version: 6.4.3 RCs
Keywords: location wizard | Platform: Unspecified
      Cpu: x86-64 |
-----------------------------+----------------------------------------------

Comment(by marisn):

This is a wrong place where to discuss GRASS project issues.

Still, as it's too late, I'll drop in my rant:
The problem is that we have too big changes in 6.4.x. Most of blockers are
in features that were not existing in 6.4.0, 6.4.1. As fixing bugs
sometimes involves introducing new code and new features, finding new bugs
is unstoppable. Want an example? Take look at "identify" problems of
vectors. In 6.4.0 it was plain v.what with printing in console. Pretty?
No, but worked well. Now try to count how many blockers/critical bugs were
filled against the new identify tool. As long as we will continue to
introduce new features/change existing behaviour (i.e. import and launch
into PERMANENT) just 5 min. before release, we will have blockers just 1
minute before release. I'm sorry, I don't have any free time for GRASS
testing. I'm (and probably others too) reporting issues when I find them
during ordinary work or when my labs fail because of "new and cool
feature".

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1889#comment:20&gt;
GRASS GIS <http://grass.osgeo.org>

The situation is untenable as-is, but pretty easy to fix with an extra page

+ [yes/no] + wget as a

near-last page the nsi installer I think.

it seems not to be really obvious from the different reports which version
of the ms runtimes is needed?

see http://trac.osgeo.org/grass/ticket/1428#comment:8

in the last weeks there were reports about missing msvcp100.dll...

see also http://trac.osgeo.org/grass/ticket/1428#comment:38

"Unlike the Visual C++ 2005 and 2008 redistributable packages, there are
registry keys that can be used to detect the presence of the Visual C++ 2010
redistributable package."

any hints about needed versions, different runtime handling in different
windows versions (xp - yes still there, vista, 7, 8) are welcome...

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/GRASS-GIS-1889-wxPy-loc-n-wiz-don-t-auto-launch-into-PERMANENT-tp5035385p5039427.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
-----------------------------+----------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: wxGUI | Version: 6.4.3 RCs
Keywords: location wizard | Platform: Unspecified
      Cpu: x86-64 |
-----------------------------+----------------------------------------------

Comment(by cmbarton):

Replying to [comment:20 marisn]:
> This is a wrong place where to discuss GRASS project issues.
>
> Still, as it's too late, I'll drop in my rant:
> The problem is that we have too big changes in 6.4.x. Most of blockers
are in features that were not existing in 6.4.0, 6.4.1. As fixing bugs
sometimes involves introducing new code and new features, finding new bugs
is unstoppable. Want an example? Take look at "identify" problems of
vectors. In 6.4.0 it was plain v.what with printing in console. Pretty?
No, but worked well. Now try to count how many blockers/critical bugs were
filled against the new identify tool. As long as we will continue to
introduce new features/change existing behaviour (i.e. import and launch
into PERMANENT) just 5 min. before release, we will have blockers just 1
minute before release. I'm sorry, I don't have any free time for GRASS
testing. I'm (and probably others too) reporting issues when I find them
during ordinary work or when my labs fail because of "new and cool
feature".

I also am VERY supportive of getting releases out more rapidly. But I know
where Maris is coming from. I try to test any any new features as soon as
I can on the Mac. But the frustrating thing is when I discover (in the
process of doing work or teaching) things that USED to work, now don't due
to some upstream change. Especially when working with release candidates,
it is essential to test any changes thoroughly when committing or
backporting. It's hard enough to test and fix existing bugs and new
features, but having previously working code broken makes vetting a really
tough task. More testers always help too.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1889#comment:21&gt;
GRASS GIS <http://grass.osgeo.org>

On Sun, Mar 10, 2013 at 4:06 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
...

it seems not to be really obvious from the different reports which version
of the ms runtimes is needed?

...

in the last weeks there were reports about missing msvcp100.dll...

Just guessing around: what if we "wget" dump all these msvcpXYZ.dll
files into the lib/ directory? If it comes first in the DLL path, it may
not conflict with any system DLLs?

Markus

Just guessing around: what if we "wget" dump all these msvcpXYZ.dll
files into the lib/ directory? If it comes first in the DLL path, it may
not conflict with any system DLLs?

good point.

AFAIK the msvcrt runtimes are delivered as exe/msi by ms and should be
installed,

e.g. see http://www.microsoft.com/en-us/download/details.aspx?id=8328

so just dropping the dll may be not enough?

but have a look in http://download.osgeo.org/osgeo4w/release/msvcrt/

e.g. the content of msvcrt-1.0.1-7.tar.bz2 is

dllupdate.exe
log.txt
msvcp60.dll
msvcp70.dll
msvcp71.dll
msvcr71.dll
msvcrt.dll
o4w_env.bat
textreplace.exe
vcredist_2005_x86.exe
vcredist_2008_x86.exe
vcredist_2010_x86.exe
xxmklink.exe

if we know that installing vcredist_2010_x86.exe would be enough, it should
be doable by the nsis-wingrass-installer...

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/GRASS-GIS-1889-wxPy-loc-n-wiz-don-t-auto-launch-into-PERMANENT-tp5035385p5039447.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

On Sun, Mar 10, 2013 at 9:49 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
...

if we know that installing vcredist_2010_x86.exe would be enough, it should
be doable by the nsis-wingrass-installer...

We could try... then decide. If it is not too much mess?

BTW:
http://www.microsoft.com/en-us/download/details.aspx?id=30679
-> VSU1\vcredist_x86.exe for 2012

Markus

On 03/10/2013 10:02 PM, Markus Neteler wrote:

On Sun, Mar 10, 2013 at 9:49 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
...

if we know that installing vcredist_2010_x86.exe would be enough, it should
be doable by the nsis-wingrass-installer...

We could try... then decide. If it is not too much mess?

BTW:
http://www.microsoft.com/en-us/download/details.aspx?id=30679
-> VSU1\vcredist_x86.exe for 2012

Unfortunately, there is no such thing as a "DLL path"
on Windows. See the treatise on confused operating
system design here:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

(enjoy "Standard Search Order for Desktop Applications"!)

This whole drama might be resolved once there is a
complete build chain based on MSYS/MinGW-64 to replace
Visual C/C++. I am working on this:

http://gvsigce.sourceforge.net/wiki/index.php/Setting_up_the_GNU_Compiler_Collection

The above includes GRASS and all of its dependencies
except for WxWidgets. However, the latter also seems
to build OK with recent versions of MinGW-64:

http://wxwidgets.blogspot.de/2011/06/choosing-gcc-for-building-wxwidgets.html

Realistically speaking, it will take a few more
weeks for me to complete and test the build chain.
We plan to release the resulting binaries with
gvSIG CE 1.0 (which will ship with GRASS 6.4.3 as
a geoprocessing backend). From that point forward,
i.e. GRASS 6.4.4, it might be feasible to base GRASS
Windows releases on the gvSIG CE build chain:
no more pesky VC runtime DLLs!

Also, in case you are not using it yet:
"Dependency Walker" is really helpful for
locating DLL-related problems.

Best,

Ben

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

--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

   benducke@fastmail.fm

#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
-----------------------------+----------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: wxGUI | Version: 6.4.3 RCs
Keywords: location wizard | Platform: Unspecified
      Cpu: x86-64 |
-----------------------------+----------------------------------------------

Comment(by hellik):

Replying to [comment:13 hellik]:

>
> closing the ticket?
>

?

Helmut

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1889#comment:22&gt;
GRASS GIS <http://grass.osgeo.org>

#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: blocker | Milestone: 6.4.3
Component: wxGUI | Version: 6.4.3 RCs
Resolution: fixed | Keywords: location wizard
  Platform: Unspecified | Cpu: x86-64
--------------------------+-------------------------------------------------
Changes (by annakrat):

  * status: new => closed
  * resolution: => fixed

Comment:

Replying to [comment:22 hellik]:
> closing the ticket?

All changes applied also in 6.5 (r55314) and 7 (r55312). Closing the
ticket.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1889#comment:23&gt;
GRASS GIS <http://grass.osgeo.org>