[GRASS-dev] r.out.gdal segfault in XY location

Hi,

I just realize that r.out.gdal2 crashes with segmentation fault in XY
(unprojected) location. If there is no objections I will fix it in CVS
(see the patch).

Best, Martin

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

(attachments)

main.c.diff (999 Bytes)

Hi all,

BTW I have submitted the patch to Gforge [1] (just testing:-)

Martin

[1] http://wald.intevation.org/tracker/index.php?group_id=21&atid=183

PS: If I understand well -- patches should be submitted to Gforge in
the future and not sent as the attachment to the grass-dev list,
right?

2006/11/5, Martin Landa <landa.martin@gmail.com>:

Hi,

I just realize that r.out.gdal2 crashes with segmentation fault in XY
(unprojected) location. If there is no objections I will fix it in CVS
(see the patch).

Best, Martin

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

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

Martin Landa wrote:

BTW I have submitted the patch to Gforge [1] (just testing:-)

Oh, OK - ignore my email I sent you offlist just a while ago, then.

[1] http://wald.intevation.org/tracker/index.php?group_id=21&atid=183

PS: If I understand well -- patches should be submitted to Gforge in
the future and not sent as the attachment to the grass-dev list,
right?

That's how I imagine this. Is that OK for devs?

Maciek

Maciej Sieczka wrote:

> PS: If I understand well -- patches should be submitted to Gforge in
> the future and not sent as the attachment to the grass-dev list,
> right?

That's how I imagine this. Is that OK for devs?

probaby depends on the size of the patch. For a few lines it's probably
not worth the trouble of using the patch tracker. For larger patches and
module submission it is more appropriate than sending 50kb emails to the
entire list.

Say, could a tracker hold Wiki Add-ons scripts & modules? I always worry
that old scripts will be lost when people switch ISPs, jobs, graduate,
etc.

Hamish

Hamish wrote:

Maciej Sieczka wrote:

PS: If I understand well -- patches should be submitted to Gforge in
the future and not sent as the attachment to the grass-dev list,
right?

That's how I imagine this. Is that OK for devs?

probaby depends on the size of the patch. For a few lines it's probably
not worth the trouble of using the patch tracker. For larger patches and
module submission it is more appropriate than sending 50kb emails to the
entire list.

IMO, the main reason to use the tracker instead of sumbitting patches
just to the dev list is to keep the track of them :). So that we can
easilly access the patches that have been sent half a year ago, and
were ignored then, but now they could be usefull. For this, I believe,
any patch should be submitted by the user to the tracker, instead of
the list directly (the message will be forwarded to the list from the
tracker anyway). Once it is apllied (or used as a protype for another
patch), it's ticket should be closed.

Say, could a tracker hold Wiki Add-ons scripts & modules? I always worry
that old scripts will be lost when people switch ISPs, jobs, graduate,
etc.

We could have a separate tracker for this, or use the the GForge ftp
space (there is such thing).

Bernhard,

What is file size limit and the overall quota, in the tracker and the
ftp space? Better ideas?

Maciek

Hi,

2006/11/5, Martin Landa <landa.martin@gmail.com>:

I just realize that r.out.gdal2 crashes with segmentation fault in XY
(unprojected) location. If there is no objections I will fix it in CVS
(see the patch).

fixed in CVS.

Best, Martin

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

On Monday 06 November 2006 08:46, Maciej Sieczka wrote:

Hamish wrote:
> Maciej Sieczka wrote:
>>> PS: If I understand well -- patches should be submitted to Gforge in
>>> the future and not sent as the attachment to the grass-dev list,
>>> right?
>>
>> That's how I imagine this. Is that OK for devs?
>
> probaby depends on the size of the patch. For a few lines it's probably
> not worth the trouble of using the patch tracker. For larger patches and
> module submission it is more appropriate than sending 50kb emails to the
> entire list.

IMO, the main reason to use the tracker instead of sumbitting patches
just to the dev list is to keep the track of them :). So that we can
easilly access the patches that have been sent half a year ago, and
were ignored then, but now they could be usefull. For this, I believe,
any patch should be submitted by the user to the tracker, instead of
the list directly (the message will be forwarded to the list from the
tracker anyway). Once it is apllied (or used as a protype for another
patch), it's ticket should be closed.

I think it is good to track patches, even small ones.
Still there are situations where I would want to mail a patch to the list.
Especially when I am in a process of changing or discussing a change
or I know I will commit this tomorrow anyway.
Otherwise, at the end of a working session, it is good to publish something
and a tracker can help a lot to create a mini-discussion place
for a specific change.

> Say, could a tracker hold Wiki Add-ons scripts & modules? I always worry
> that old scripts will be lost when people switch ISPs, jobs, graduate,
> etc.

We could have a separate tracker for this, or use the the GForge ftp
space (there is such thing).

Bernhard,

What is file size limit and the overall quota, in the tracker and the
ftp space? Better ideas?

There is no specific quota (yet) as disc space is reasonable cheap (though
backspace is not). We might introduce a quota in the future.

I am not quite sure that I know what "Wiki Add-ons scripts & modules"
precisly are, but if this is useful for GRASS to track and reaonably
seperate from other things. By all means: Track it. :slight_smile:
You can use the documentation space or another svn module if
a tracker is not appropriate, so there are enough possibility to model
a solution.

Bernhard

--
Managing Director - Owner, www.intevation.net (Free Software Company)
Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software)
www.kolab-konsortium.com (Email/Groupware Solution, Professional Service)

HB:

> > Say, could a tracker hold Wiki Add-ons scripts & modules? I always
> > worry that old scripts will be lost when people switch ISPs, jobs,
> > graduate, etc.

MS:

> We could have a separate tracker for this, or use the the GForge ftp
> space (there is such thing).
>
> What is file size limit and the overall quota, in the tracker and
> the ftp space? Better ideas?

BR:

There is no specific quota (yet) as disc space is reasonable cheap
(though backspace is not). We might introduce a quota in the future.

usual FTP policy is anonomous upload to an incoming/ dir is allowed, but
the contents of that dir is only viewable by the site admin who then
moves the file to the public dir. incoming/ should be in its own
partition or be subject lots of space checks to avoid a general denial
of service attack.

there used to be such a ftp upload space @itc, don't know if that is
still active. I don't think anyone has needed to use it in a long while.

I am not quite sure that I know what "Wiki Add-ons scripts & modules"
precisly are, but if this is useful for GRASS to track and reaonably
seperate from other things. By all means: Track it. :slight_smile:

user contributions:
http://grass.gdf-hannover.de/wiki/GRASS_AddOns

You can use the documentation space or another svn module if
a tracker is not appropriate, so there are enough possibility to model
a solution.

thanks,
Hamish

Hamish wrote:

BR:

I am not quite sure that I know what "Wiki Add-ons scripts & modules"
precisly are, but if this is useful for GRASS to track and reaonably
seperate from other things. By all means: Track it. :slight_smile:

HB:

user contributions:
http://grass.gdf-hannover.de/wiki/GRASS_AddOns

You can use the documentation space or another svn module if
a tracker is not appropriate, so there are enough possibility to model
a solution.

The SVN might be too complicated for many submitters and the
documentation module lacks necessary features compared to tracker. I
think the tracker should be fine.

Bernhard,

How do I clone the bug tracker under some other name (I'd like to use
it as prototype for addons tracker).

Best,
Maciek

On Tuesday 07 November 2006 19:28, Maciej Sieczka wrote:

How do I clone the bug tracker under some other name (I'd like to use
it as prototype for addons tracker).

I am currently careful with the clone option of gforge,
as I am not sure what is cloned where right now.