Hamish wrote: > > the main thing remaining IMO is to get the location wizard > > working correctly with proj 4.8.0. (the datum transform opts > > were getting reset to the new proj4 defaults regardless of > > what you selected) ... > > changes now ported to all branches.
MarkusN wrote: > Good - no break was reported in the past 7 days. but no idea if anyone else tested it, you often get a result, the question is if it's the one you expected. plea for testers now sent to the users ML. > So most issues should be addressed, right? yes, with the exception of from-georef file and from-WKT file not asking you for datum transform opts. (they are left undefined and proj4 decides what default to use (perhaps sometimes none?) depending on what version of PROJ.4 you have installed) > Am I right that r56172 still needs to be backported to > relbranch? It's already backported with the rest. wizard.py is identical in relbr64 and devbr6. in trunk there is the extra planetary ellipsoid support, so a little bit different (but otherwise includes all fixes AFAIK). > > #1428: still some missing some dlls > > ... I don't think that this one is critial since no > complaints came. if dependency walker says there is a missing DLL, it will most likely break the first time someone tries that module; we don't need a complaint to know it. I just tried on a day-old install of Windows7 (GRASS installed after a number of other 3rd party apps), dependency walker was happy for all the DLLs I looked at except for a missing IESHIMS.DLL which seems to be some sort of Vista IE specific thing and e.g. libgis works ok without it. As of a couple of weeks ago a Wingrass install on XP was reporting the following missing DLLs: libpq.dll req's msvcr80.dll tk85.dll req's msvcr90.dll geotiff.dll req's msvcp90.dll (most probably others too) Either there is different pathways depending on the Windows version, or the osgeo4w buildchain was fully updated to use msvcp100.dll and friends in the last days, it would need to be retested there. > > #1971: r.in.bin: fix LFS support in G_ftell() now in devbr6 for testing. > > #943: cairo rendering fixes > > --Preferences > rendering mode > cairo in grass 6.x doesn't > > work!! > > Opened 3 years ago, hence a "nice to have" fix which should > not block the release. in that case the option should be greyed out in relbr64. I think it's a pretty simple thing, probably with setting some GRASS_RENDER_IMMEDIATE or similar I think it could work. I feel we are very close with it, so don't want to give up trying just yet. The sibling bug is all the tmp and tmp.ppm files piling up in /tmp and %TEMP%, never deleted. > > cleanup/wish-to-dos: > > > > #1952: package 'more.exe' with msys (pager for g.list) > > (also +tac.exe +seq.exe +xml2.exe and maybe +wget.exe) > > --what controls what unix powertools are packaged > > in extrabin/? > > See also ticket #1275 (about zip.exe) ... > > #1936a: Move "Click here to show search module engine" > > to "Search module" tab, freeing up valuable screen real > > estate for the output text window & making the gui > > tab-to-be-in more logical. > > --discussion and wxGUI authors buy-in needed > > ... hence unrelated to the 6.4.3 release. It is not a blocker for 6.4.3, but I fear if it doesn't get discussion now it will stay like that forever. > > #854: building addons on Mac (active efforts) It seems we should also add discussion of wx2.9 + mac to this todo or not todo list, and get that into devbr6 ASAP for the trial and error. (then atomically backport something known to be working instead of experiemnting in the relbr) > I am afraid that we need an RC4 now due to the too many > changes after RC3. maybe so, but in that case RC4 could be short and near identical to final. I feel the release will be much stronger thanks to all the fixes over the last month (working loc'n wizard, PDF output on WinGrass, DLL startup problems finally history, ...) > > see also > >> all grass 6 bugs: https://trac.osgeo.org/grass/report/16 > >> all wingrass bugs: https://trac.osgeo.org/grass/report/14 > >> all wxgui bugs: https://trac.osgeo.org/grass/report/15 thanks, Hamish _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev