#28441 closed Cleanup/optimization (fixed)
GEOS version parsing fails if it has a trailing hash
| Reported by: | vonabarak | Owned by: | nobody |
|---|---|---|---|
| Component: | GIS | Version: | 1.11 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Importing some classes (e.g. from django.contrib.gis.db.backends.base.features import BaseSpatialFeatures) using libgeos.py causes GEOSException('Could not parse version info string "%s"' % ver) django.contrib.gis.geos.error.GEOSException: Could not parse version info string "3.6.2-CAPI-1.10.2 4d2925d6"
I have been investigated this problem a bit. The reason is probably wrong version_regex in line 182 of libgeos.py
Exactly part corresponding to parse commit id (or whatever means " 4d2925d6" in version_string)
Use django 1.11 on freebsd 11
Change History (15)
comment:1 by , 7 years ago
| Component: | Uncategorized → GIS |
|---|---|
| Has patch: | set |
| Summary: | Wrong parsing of GEOS library version string in "contrib/gis/geos/libgeos.py" → GEOS version parsing fails if it has a trailing hash |
| Triage Stage: | Unreviewed → Accepted |
| Type: | Uncategorized → Cleanup/optimization |
comment:3 by , 7 years ago
4d2925d6 is the commit for 3.6.2 tagged on:
https://github.com/OSGeo/geos/tree/4d2925d6e0c758742a178053132eef02cd8374d2
So it looks like the commit hash was added to the version string.
And it looks like this is the commit that changed the version:
https://github.com/OSGeo/geos/commit/cc5e205e5b4c7d4ee567bf39a548e65ecf51dd0e
More specifically:
https://github.com/OSGeo/geos/commit/cc5e205e5b4c7d4ee567bf39a548e65ecf51dd0e#diff-8dd96440c9832c59176dcaa7c346b982
Hope this helps.
comment:4 by , 7 years ago
I guess we should fix this on 1.11.x so we don't block the use of newer versions of GEOS there. PR for stable/1.11.x
comment:7 by , 7 years ago
Is this scheduled to be released soon?
If anyone has this issue on macOS and does not know how to solve it, this should do the trick:
brew switch geos 3.6.1
comment:9 by , 7 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
I met this kind of problem in Mac OS 10.12.6, django version 1.11.4.
My geos version is 3.6.2. I installed the plugins using brew.
comment:10 by , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This was fixed in 1.11.5 (which will be released this week).
comment:11 by , 7 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
Please also fix this in Django 1.8.
comment:12 by , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Rudolph, please take the time to read our backporting policy to understand why this wasn't backported to 1.8 before re-opening a closed ticket.
At this point, and when this ticket was reported as well, only security fixes and data loss bug qualify for a 1.8 backport.
follow-up: 15 comment:13 by , 5 years ago
I'm running into this problem in Django 1.11.25, Debian testing/bullseye:
File "/home/nik/src/d/blackrock/ve/lib/python3.7/site-packages/django/contrib/gis/geos/libgeos.py", line 196, in geos_version
_info
raise GEOSException('Could not parse version info string "%s"' % ver)
django.contrib.gis.geos.error.GEOSException: Could not parse version info string "3.8.0-CAPI-1.13.1 "
comment:14 by , 5 years ago
Nikolas, thanks for this report, however Django 1.11 doesn't receive bugfixes anymore (it is in extended support).
comment:15 by , 5 years ago
Replying to Nikolas Nyby:
Had same issue today. Resolved by downgrading geos to 3.7.2 and gdal to 3.0.1.
PR