> Can you confirm that the filehandle issue has been fixed in the mean time?
Sorry, I don't use mapserver/mapscript for anything anymore, and the
server setup where this bug manifested has been taken down years
ago. I do suspect that the bug has been fixed, too; I guess the bug
could be closed.
Package: liblas-bin
Version: 1.2.1-1
Severity: wishlist
Binaries in package miss manpages:
las2las
las2ogr
las2txt
lasinfo
lasmerge
txt2las
Best Wishes,
Harri K.
-- System Information:
Debian Release: 6.0
APT prefers stable
APT policy: (900, 'stable')
Architecture: i386 (i686)
Kernel: Lin
Package: grass
Version: 6.4.0~rc6+42329-1+b1
Severity: normal
To replicate:
Open a workspace file under wxpython. Change a map layer name on the "map
layers for each display" and include a non-ascii letter, like 'รค'. Exit gui.
When
asked to save changes to workspace, answer 'Yes'. result:
---
Package: grass
Version: 6.4.0~rc6+42329-1+b1
Severity: normal
Hi!
I just noticed, that trying to update the attribute table data using non-ascii
letters using the Query vector map (edit mode) in the
map display does not work; in fact, it hangs indefinitively until the
db.execute running in the
Package: grass
Version: 6.4.0~rc5-2+b2
Severity: important
When selecting selecting a vector for digitizing in the wxpython gui map
display, these error
messages appear:
Traceback (most recent call last):
File "/usr/lib/grass64/etc/wxpython/gui_modules/toolbars.py", line 1071, in
OnSelectMa
Francesco P. Lovergine wrote:
> On Thu, Mar 13, 2008 at 02:50:04PM +0100, Paolo Cavallini wrote:
>> Harri Kiiskinen ha scritto:
>>> Package: qgis-plugin-grass
>>> Version: 0.8.1-2+b1
>>> Severity: important
>>>
>>> When trying to open a GRASS v
Package: qgis-plugin-grass
Version: 0.8.1-2+b1
Severity: important
When trying to open a GRASS vector which for some reason is not ok, i.e.
faulty, instead of gracefully telling the user, that the vector is not
ok, the whole QGis crashes. This is *irritating*, this kind of exception
should be hand
Actually, a closer look at the handles left open gives more info:
Each map produced leaves:
One handle per "coor" file of the vector
One handle per "hist" file of the vector
Two handles to "/usr/lib/grass/etc/ellipse.table" per each layer in the
GRASS vector - not per layer as defined in the ma
Package: libgdal1-1.4.0
Version: 1.4.4-1
Severity: normal
*** Please type your report below this line ***
I'm running a map application, that serves data from GRASS vector maps
with PHP5 and Mapserver. The
connection type is OGR, and the maps work perfectly. However, each map
produced leaves fi
Package: php5-mapscript
Version: 5.0.0-3
Severity: normal
I'm running a map application, that serves data from GRASS vector maps
with PHP5 and Mapserver. Each map
produced leaves five (5) more file handles open:
one to:
/grass/location/mapset/vector/vectormap/coor
one to:
/grass/location/mapset/v
about? The current version of the package
> build-depends on libgdal1-1.3.2-dev.
Considering the high general quality of Debian, the mistake must have
been on my side; an apt-src remove grass with apt-src install grass did
the trick, and suddenly
Subject: grass: Outdated build-deps for testing
Source: grass
Severity: serious
Justification: no longer builds from source
*** Please type your report below this line ***
The grass source package from testing (6.0.2-6) has impossible build
dependencies for testing, and the current grass binary i
12 matches
Mail list logo