Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Martin Landa]

Hi Ivan,

2014-12-08 7:16 GMT+01:00 Ivan Minčík :
> I did small investigation why Ubuntu package of GRASS 7 is failing to build
> on Launchpad.

first of all, thanks for you time.

> The problem is caused by building single page documentation (make
> htmldocs-single). This make command is also failing on my computer. Building
> multi-page documentation (make htmldocs) is running without problem.

These commands build API documentation [1]. I guess it's not needed
for debian packaging, right? The user documentation [2] is build via
default make command. I wonder there is attempt to build API manual
for debian package. It doesn't make sense to me so much.

Martin

[1] http://grass.osgeo.org/programming7/
[2] http://grass.osgeo.org/grass70/manuals/

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Martin Landa]

Hi,

2014-12-08 7:16 GMT+01:00 Ivan Minčík :
> The problem is caused by building single page documentation (make
> htmldocs-single). This make command is also failing on my computer. Building

please tell us what exactly is failing. Thanks, Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Martin Landa]

Hi,

2014-12-08 10:01 GMT+01:00 Martin Landa :
> These commands build API documentation [1]. I guess it's not needed
> for debian packaging, right? The user documentation [2] is build via

or it should be part of `grass-dev` package? Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Ivan Minčík]

On Mon, Dec 8, 2014 at 10:01 AM, Martin Landa 
wrote:

> Hi Ivan,
>
> 2014-12-08 7:16 GMT+01:00 Ivan Minčík :
> > I did small investigation why Ubuntu package of GRASS 7 is failing to
> build
> > on Launchpad.
>
> first of all, thanks for you time.
>
> > The problem is caused by building single page documentation (make
> > htmldocs-single). This make command is also failing on my computer.
> Building
> > multi-page documentation (make htmldocs) is running without problem.
>
> These commands build API documentation [1]. I guess it's not needed
> for debian packaging, right? The user documentation [2] is build via
> default make command. I wonder there is attempt to build API manual
> for debian package. It doesn't make sense to me so much.
>

The same docs was build also in GRASS 6 packaging. It is a content of
'grass-dev-doc' package.
Removing it means loosing this package.

It is failing with meaningless error [1]:

*** [htmldocs-single] Error 2

The same error I get even if running by hand with 'make -d'

1 -
https://launchpadlibrarian.net/191285764/buildlog_ubuntu-precise-i386.grass70_7.0.0~ppa~2~revno-31311~ubuntu12.04.1_FAILEDTOBUILD.txt.gz

-- 
Ivan Minčík
ivan.min...@gmail.com  GPG: 0x79529A1E
http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.sk GPG: 0xD714B02C
http://imincik.github.io/0xD714B02C.key
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Martin Landa]

Hi,

2014-12-08 10:12 GMT+01:00 Ivan Minčík :
> The same docs was build also in GRASS 6 packaging. It is a content of
> 'grass-dev-doc' package.

OK, than it make sense to me.

> Removing it means loosing this package.
>
> It is failing with meaningless error [1]:
>
> *** [htmldocs-single] Error 2
>
> The same error I get even if running by hand with 'make -d'

also with `make -j1` ? Thanks, Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Martin Landa]

Hi,

2014-12-08 10:15 GMT+01:00 Martin Landa :
> Hi,
>
> 2014-12-08 10:12 GMT+01:00 Ivan Minčík :
>> The same docs was build also in GRASS 6 packaging. It is a content of
>> 'grass-dev-doc' package.
>
> OK, than it make sense to me.
>
>> Removing it means loosing this package.
>>
>> It is failing with meaningless error [1]:
>>
>> *** [htmldocs-single] Error 2

from attached log:

make[2]: Entering directory `/build/buildd/grass70-7.0.0~ppa~2~revno/lib'
make[2]: *** No rule to make target `htmldox-single'.  Stop.

I will take a look at it. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Martin Landa]

Hi Ivan,

2014-12-08 10:26 GMT+01:00 Ivan Minčík :
> The same unusable error message with make -j1:
>
> HTML reference in directory ./html/index.html
> make[1]: Leaving directory `/home/pkg-grass'
> for dir in lib gui/wxpython ; do \
>   make -C $dir htmldox-single ; \
> done
> make[1]: Entering directory `/home/pkg-grass/lib'
> make[1]: *** No rule to make target `htmldox-single'.  Stop.
> make[1]: Leaving directory `/home/pkg-grass/lib'
> make[1]: Entering directory `/home/pkg-grass/gui/wxpython'
> make[1]: *** No rule to make target `htmldox-single'.  Stop.
> make[1]: Leaving directory `/home/pkg-grass/gui/wxpython'
> make: *** [htmldocs-single] Error 2

should be fixed in r63433. Please could you try to compile trunk?
After some testing I will backport it to relbr70. Thanks, Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:104 neteler]:
 > Should we vote on this topic? We really need to converge asap since
 beta4 is overdue.

 I fully agree, we need to somehow decide this issue...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:102 wenzeslaus]:

 > For example, there will be no need to change `grass.script.raster3d`
 (which would end up as `grass.script._3draster` in the other case). From
 this point of view `raster_3d` is also not good because underscore should
 not be in the name of a Python module if possible and moreover I don't
 like `raster_3d` in general. Shortening possibilities are not as important
 to me as name without underscore.

 I would agree with that.

 @glynn: please could you review your opinion on already attached patch. I
 understand that you prefer some generic solution. On the other hand we
 need to decide somehow (to find a compromise) since we would like to see
 GRASS7 released in reasonable time.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Ivan Mincik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 08.12.2014 10:57, Martin Landa wrote:
> Hi Ivan,
> 
> 2014-12-08 10:26 GMT+01:00 Ivan Minčík :
>> The same unusable error message with make -j1:
>> 
>> HTML reference in directory ./html/index.html make[1]: Leaving
>> directory `/home/pkg-grass' for dir in lib gui/wxpython ; do \ 
>> make -C $dir htmldox-single ; \ done make[1]: Entering directory
>> `/home/pkg-grass/lib' make[1]: *** No rule to make target
>> `htmldox-single'.  Stop. make[1]: Leaving directory
>> `/home/pkg-grass/lib' make[1]: Entering directory
>> `/home/pkg-grass/gui/wxpython' make[1]: *** No rule to make
>> target `htmldox-single'.  Stop. make[1]: Leaving directory
>> `/home/pkg-grass/gui/wxpython' make: *** [htmldocs-single] Error
>> 2
> 
> should be fixed in r63433. Please could you try to compile trunk? 
> After some testing I will backport it to relbr70. Thanks, Martin

Currently I have no time to try it in latest trunk, but I have applied
your fix in to the version I am testing (which is latest failed
version from Launchpad - grass70_7.0.0~ppa~2~revno-31311) and it seems OK.


- -- 
Ivan Minčík
ivan.min...@gmail.com  GPG: 0x79529A1E
http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.sk GPG: 0xD714B02C
http://imincik.github.io/0xD714B02C.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUhX6XAAoJEPfdLsR5UpoeGj0H/0KwPNt6/2F14P4GS9Sv6MP3
+FwLK7mz9/T9JfsExwTSER39dSKLaK9fW1vm104Cs0Nb691qiJpdDh7OfScL/D/w
vVUQTpp0U/UAJGQ12z0JDiPZV0WDWw05YIEug63HtRCma6L++RGxno0j9ZNeaWi/
RfAm97iR8XFcuGC2YrPWLAECeW+8l3uGpAro3N8r82Dolu3b5OyBz8xyg09E9Ov8
JIvWb6q0YjYXoo0Yc+royr3tApUyGCJBFsuv0eSAnUxNOMcJFgtVngAG0RVcGU4r
5Wg+JtZxkACpX40RW1YVSRsO+J1q8fCSmm+gmw4r7iPMmNJ7xXIFg5pifYU/t0Q=
=Pdu8
-END PGP SIGNATURE-
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Martin Landa]

Hi Ivan,

2014-12-08 11:34 GMT+01:00 Ivan Mincik :
> Currently I have no time to try it in latest trunk, but I have applied
> your fix in to the version I am testing (which is latest failed

OK, I have backport it to relbr70 in r63434.

> version from Launchpad - grass70_7.0.0~ppa~2~revno-31311) and it seems OK.

BTW, revno-31311 means really r31311 [1], than it's bogus (7 years ago commit).

Thanks for your time, Martin

[1] http://trac.osgeo.org/grass/changeset/31311

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Ivan Mincik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08.12.2014 11:38, Martin Landa wrote:
> BTW, revno-31311 means really r31311 [1], than it's bogus (7 years
> ago commit).

Martin, sorry for confusing you. 31311 is bazaar import revision
number [1].


1 -https://code.launchpad.net/grass

- -- 
Ivan Min?ík
ivan.min...@gmail.com  GPG: 0x79529A1E
http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.sk GPG: 0xD714B02C
http://imincik.github.io/0xD714B02C.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUhYGsAAoJEPfdLsR5UpoeNjsH/27nyey73hq8mVkuyTiUQpDu
xg3KnC2+okSVOhFyosau9lKPyPaWLdXGLSaOu0pxwuFzm00klAyZ+DcUIk2aVAw9
44KT4h1XFKnizEM0AYtEbReHrI6il26ijHRLEtpsvq5k3mICc5qAb0ab5ronJuk0
iD4eNMyXDDMqSeGJ4trvEonCbxU8wOqk0ESiIzNMlMBBOZX2pE1E65ZYZrr0X+1X
od76InfGlr6LFC5+q/RY+AewJTYomLM05Yp9IK6Ohoilz76KqUJsxhgcaAeIkyK4
44MV357o4g2hUq+rMgJn3MG0G1FzmQnoKQel1iXsELesREgyZ1ILytXBnjlycA4=
=yjxL
-END PGP SIGNATURE-
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Addons builds and manuals

[Martin Landa]

Hi,

2014-12-07 19:26 GMT+01:00 Vaclav Petras :
> The logs about building addons are not updated. I'm also not sure about
> addons manual pages. I think that i.theilsen from yesterday should be
> visible but it is not. Is this related? I though that it is not. The logs
> are recent just the overall log is outdated.
> http://wingrass.fsv.cvut.cz/grass70/addons/grass-7.0.0svn/logs/
> http://grass.osgeo.org/grass70/manuals/addons/

should be fixed now. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Ivan Mincik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08.12.2014 11:38, Martin Landa wrote:
> OK, I have backport it to relbr70 in r63434.

I am waiting for Launchpad tu upload latest SVN version which is still
waiting for something [1] and than try to build new package.


1 - https://code.launchpad.net/~grass/grass/releasebranch_7_0


- -- 
Ivan Min?ík
ivan.min...@gmail.com  GPG: 0x79529A1E
http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.sk GPG: 0xD714B02C
http://imincik.github.io/0xD714B02C.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUhb15AAoJEPfdLsR5UpoeN88H/jVgtxgMaih8UWzRpybfs5Dv
RBzFzU4Q8sk+PCXwJAhQDBWzidY8UY20I5fVDEyLzxdx0edpQDI/p9IUioHhayoX
5g0BJxrLjb2e2/iMuXE/G2RbwclAAf6uMbKnsoCjzEuIWR226eDoETwsnHlKk3qL
pNOX84HX9F3njcIgCuaeN8YJajLTsiHhjZrHZK3Nguzz0li3viXU9C9SeFnPDyJf
+QpB3/8J3GMVhrdQsDCaeTcoiUINOAKLXwBXVSCdfQVcLT2eWFQu0U0hO9dos1Xd
16BhwYqWtCsg1cgJUOmtIioeZ32jcJBjWY0QqZspGreqDRqZvgFqpb7/VAYaHJ8=
=Dmcr
-END PGP SIGNATURE-
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2426: add r.surf.nnbathy to the core code of GRASS 7.1

[GRASS GIS]

#2426: add r.surf.nnbathy  to the core code of GRASS 7.1
-+--
 Reporter:  bhlevca  |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  major|   Milestone:  7.1.0
Component:  Addons   | Version:  unspecified  
 Keywords:  nnbathy  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by martinl):

 * cc: lazaa (added)
  * keywords:  => nnbathy


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2426: add r.surf.nnbathy to the core code of GRASS 7.1

[GRASS GIS]

#2426: add r.surf.nnbathy  to the core code of GRASS 7.1
-+--
 Reporter:  bhlevca  |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  major|   Milestone:  7.1.0
Component:  Addons   | Version:  unspecified  
 Keywords:  nnbathy  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [ticket:2426 bhlevca]:
 > I am not sure if there are licensing problems with nnbathy
 > (https://code.google.com/p/nn-c/) as it is a MIT license, but my
 understanding is that it should be possible.

 From https://code.google.com/p/nn-c/source/browse/nn/LICENSE it doesn't
 seems to me that it's MIT licence (?)

 > I recently copied manually the script from the Grass6 add on
 repositories into the scripts directory of the Grass7.1 installation
 directory. I also compiled nnbathy from the above sources.

 Please try out new modules which have been recently rewritten from Bash to
 Python by lazaa. You can install them via g.extension

 {{{
 g.extension m.surf.nnbathy
 }}}

 which installs two new addon modules: `r.surf.nnbathy` and
 `v.surf.nnbathy`.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2426: add r.surf.nnbathy to the core code of GRASS 7.1

[GRASS GIS]

#2426: add r.surf.nnbathy  to the core code of GRASS 7.1
-+--
 Reporter:  bhlevca  |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  major|   Milestone:  7.1.0
Component:  Addons   | Version:  unspecified  
 Keywords:  nnbathy  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:4 martinl]:
 > From https://code.google.com/p/nn-c/source/browse/nn/LICENSE it doesn't
 seems to me that it's MIT licence (?)

 sorry, it's MIT licence as visible from https://code.google.com/p/nn-c/

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Martin Landa]

Hi,

2014-12-08 11:47 GMT+01:00 Ivan Mincik :
>> BTW, revno-31311 means really r31311 [1], than it's bogus (7 years
>> ago commit).
>
> Martin, sorry for confusing you. 31311 is bazaar import revision
> number [1].
>
>
> 1 -https://code.launchpad.net/grass

thanks for explanation :-) Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2403: cairo driver fails to create surface

[GRASS GIS]

#2403: cairo driver fails to create surface
+---
 Reporter:  martinl |   Owner:  martinl
 Type:  defect  |  Status:  assigned   
 Priority:  major   |   Milestone:  7.0.0  
Component:  Display | Version:  unspecified
 Keywords:  cairo, resolution, surface  |Platform:  Linux  
  Cpu:  x86-64  |  
+---

Comment(by martinl):

 Replying to [comment:3 martinl]:
 > Replying to [comment:2 glynn]:
 > > It would be possible to change the cairo driver
 (lib/cairodriver/Raster.c) to render each row separately.
 >
 > for record https://bugs.freedesktop.org/show_bug.cgi?id=85561

 the problem is that cairo limits number of rows and cols to 32767 (1). Any
 idea how this bug could be resolved in GRASS?

 (1) http://cgit.freedesktop.org/cairo/tree/src/cairo-image-surface.c#n61

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:101 glynn]:

 > So e.g. if a module has "raster" and "raster_3d" options, "r", "rast"
 and "raster" would all be deemed to unambiguously refer to "raster", while
 any abbreviation intended to refer to "raster_3d" would have to include
 the "3" (e.g. "r3", "r3d", "rast3", "rast3d", ...) to ensure that it
 cannot also match "raster".

 I have prepared for testing a new patch based on your suggestion
 attachment:raster_3d.diff

 Then

 {{{
 g.list rast3d
 }}}

 will work. The patch contains modification of the parser to understand
 `rast`

 {{{
 g.list rast
 WARNING: Please update the usage of : option  has been
 renamed to 
 ...
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:102 wenzeslaus]:

 > For example, there will be no need to change `grass.script.raster3d`
 (which would end up as `grass.script._3draster` in the other case). From
 this point of view `raster_3d` is also not good because underscore should
 not be in the name of a Python module if possible and moreover I don't
 like `raster_3d` in general. Shortening possibilities are not as important
 to me as name without underscore.
 >
 > What about the module names? Are we changing that? Or is `raster3d` just
 `rast3d` in module names?

 Personally I would tend to rename just

  * element name `raster_3d` (or `raster3d`)
  * module options e.g. `d.legend raster_3d`

 I would not touch names of the modules, some of them already use shorten
 names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not
 touch python module names.

 Any opinion from other devs?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #969: move color structs to colors.h?

[GRASS GIS]

#969: move color structs to colors.h?
+---
 Reporter:  hamish  |   Owner:  grass-dev@… 
 
 Type:  task|  Status:  new 
 
 Priority:  blocker |   Milestone:  8.0.0   
 
Component:  Display | Version:  svn-trunk   
 
 Keywords:  needinfo, RGBA_Color, G_str_to_color()  |Platform:  All 
 
  Cpu:  All |  
+---
Changes (by martinl):

  * milestone:  7.0.0 => 8.0.0


Comment:

 Replying to [comment:9 martinl]:
 > Replying to [comment:5 mmetz]:
 > > > Should we also change `G_str_to_color()`? This would be a blocker
 too.
 > >
 > > IMHO no, because there is no bug reported for `G_str_to_color()`,
 using `unsigned char` instead of `int` means that a range check can no
 longer be done, and changing `G_str_to_color()` implies changing
 >
 > it sounds like something for G8 and not G7 (we are in beta stage)...

 I took liberty to change milestone of this ticket...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:106 martinl]:

 > @glynn: please could you review your opinion on already attached patch.
 I understand that you prefer some generic solution. On the other hand we
 need to decide somehow (to find a compromise) since we would like to see
 GRASS7 released in reasonable time.

 It's preferable to doing nothing (i.e. leaving modules using abbreviated
 forms), and is compatible with the result obtained by relaxing the
 ambiguity rules.

 Should we do something similar for option names? E.g. g.region, g.rename,
 g.copy have rast= and rast3d= options.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2500: r.surf.idw vs. r.surf.idw2

[GRASS GIS]

#2500: r.surf.idw vs. r.surf.idw2
-+--
 Reporter:  martinl  |   Owner:  grass-dev@…  
 Type:  task |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Any comments? Thanks.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2258: t.create creates DB always in the PERMANENT

[GRASS GIS]

#2258: t.create creates DB always in the PERMANENT
-+--
 Reporter:  martinl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  Temporal | Version:  svn-releasebranch70  
 Keywords:  t.register   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:18 martinl]:
 > what's the status of this ticket? anything missing?

 can we close this ticket?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:109 glynn]:

 > Should we do something similar for option names? E.g. g.region,
 g.rename, g.copy have rast= and rast3d= options.

 yes, enough would to register them in
 source:grass/trunk/lib/gis/renamed_options

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2150: Cannot call Python scripts from Python on MS Windows

[GRASS GIS]

#2150: Cannot call Python scripts from Python on MS Windows
---+
 Reporter:  wenzeslaus |   Owner:  grass-dev@…  

 Type:  defect |  Status:  new  

 Priority:  blocker|   Milestone:  7.0.0

Component:  Python | Version:  svn-releasebranch64  

 Keywords:  packaging, MAXREPEAT, scripts  |Platform:  MSWindows 7  

  Cpu:  Unspecified|  
---+

Comment(by martinl):

 Replying to [comment:28 martinl]:
 > Replying to [comment:27 glynn]:
 > > I note that G_set_program_name() removes any ".exe" suffix. On
 Windows, it should probably remove ".py" or also (on Unix, scripts are
 installed without the .py suffix). Or perhaps g.parser should do this. Or
 even forms.py for that matter.
 >
 > done in r62904 (trunk). Let's check the next build on Windows.

 that fixes the problem. Backported to relbr70 in r63446.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2403: cairo driver fails to create surface

[GRASS GIS]

#2403: cairo driver fails to create surface
+---
 Reporter:  martinl |   Owner:  martinl
 Type:  defect  |  Status:  assigned   
 Priority:  major   |   Milestone:  7.0.0  
Component:  Display | Version:  unspecified
 Keywords:  cairo, resolution, surface  |Platform:  Linux  
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:4 martinl]:

 > the problem is that cairo limits number of rows and cols to 32767 (1).
 Any idea how this bug could be resolved in GRASS?

 One option is to require clients (d.rast, d.his, d.rgb) to limit the
 region resolution. Another is to modify the driver(s) to decimate the data
 if it exceeds certain limits. Yet another is to modify the cairo driver to
 down-sample the data itself (this avoids the issue that a source region of
 32767x32767 will require 4 GiB of memory to store the surface regardless
 of the output resolution).

 All of these have the advantage that the client won't waste time reading
 rows which will be discarded by the driver (when down-sampling, the driver
 reports the next row which will be used).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 Replying to [comment:108 martinl]:

 > Personally I would tend to rename just

   * element name `raster_3d` (or `raster3d`)
   * module options e.g. `d.legend raster_3d`

 > I would not touch names of the modules, some of them already use shorten
 names, eg. `d.rast.leg`, so I would keep `rast3d`. Similarly I would not
 touch python module names.
 >
 > Any opinion from other devs?

 I don't really like the underscore, I would go with raster3d, I think we
 can manage to type raster3d because 3D rasters are generally not used as
 often as rasters.

 I would keep the names of modules as they are now.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2500: r.surf.idw vs. r.surf.idw2

[GRASS GIS]

#2500: r.surf.idw vs. r.surf.idw2
-+--
 Reporter:  martinl  |   Owner:  grass-dev@…  
 Type:  task |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [ticket:2500 martinl]:
 > Do we need the both modules in G7?

   * could they be merged?
   * or one of them moved to addons

 Even if they could be merged, it would require some work and time. So
 based on the r.surf.idw manual page:


 {{{
 r.surf.idw will generally outperform r.surf.idw2 except when the input
 data layer
  contains few non-zero data, i.e. when the cost of the search exceeds
  the cost of the additional distance calculations performed by
 r.surf.idw2.
  The relative performance of these utilities will depend on the
 comparative
  speed of boolean, integer and floating point operations on a particular
 platform.
 }}}

 and r.surf.idw2 manual page:


 {{{
 Another surface generation program, named r.surf.idw,
  should be used with latitude/longitude data bases
 }}}

 I would move r.surf.idw2 to addons. But I don't think I was trying any of
 them.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Ivan Mincik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I confirm that GRASS 7 is now building successfully in my PPA [1].
Somebody from GRASS team should request for build in GRASS PPA.


1 - https://launchpad.net/~imincik/+archive/ubuntu/gis-dev/+packages


- -- 
Ivan Minčík
ivan.min...@gmail.com  GPG: 0x79529A1E
http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.sk GPG: 0xD714B02C
http://imincik.github.io/0xD714B02C.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUhhPlAAoJEPfdLsR5UpoesFMIALlY9uvnkJXoZ0LaqWVd0raU
/NGzUkJVA7bzILnmBAkGfdSCqKxhrztSBTSEM/A89WBoE4UIZJeUuyZHY45AXM+s
psAAkC04jV4oy8xgodKGSpl9+wis1mImRDnIuZHBWnQIwpadh+aJEIW8dliUIpjU
ReXrc2ZaHe27kfytnjxnh1YJ/dV/zMKyURaj7iEDhSC6t8Ycm+pmk1pseAmYrgHY
J13ydatYhIEffn+LX5iaqSdXy8PrsnU2r93uJUtInv1ADgZfg4PTjhRraPTnOFY5
OyAo5u3yTgiJNoPPBH2mWoUE3vpDJYXayA3mceZruIdZvMKFCIhe6n7w3eytMko=
=oxe3
-END PGP SIGNATURE-
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev