Opened 13 months ago

Closed 8 months ago

#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 (12)

comment:1 Changed 13 months ago by Tim Graham

Component: UncategorizedGIS
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: UnreviewedAccepted
Type: UncategorizedCleanup/optimization

comment:2 Changed 13 months ago by Hisham waleed karam

the same error here django 1.8.18

Last edited 13 months ago by Hisham waleed karam (previous) (diff)

comment:3 Changed 13 months ago by yardensachs

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.

Last edited 13 months ago by yardensachs (previous) (diff)

comment:4 Changed 13 months ago by Tim Graham

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:5 Changed 13 months ago by Tim Graham <timograham@…>

Resolution: fixed
Status: newclosed

In 78c155c:

Fixed #28441 -- Fixed GEOS version parsing with a commit hash at the end.

comment:6 Changed 13 months ago by Tim Graham <timograham@…>

In a49764dd:

[1.11.x] Fixed #28441 -- Fixed GEOS version parsing with a commit hash at the end.

A less invasive backport of 78c155cf2e5a27fd2db18c2d46953b1b0fdba829
from master

comment:7 Changed 13 months ago by Johannes Hoppe

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:8 Changed 13 months ago by Tim Graham

Bug fix releases happen monthly, usually on the first of the month.

comment:9 Changed 12 months ago by will

Resolution: fixed
Status: closednew

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 Changed 12 months ago by yardensachs

Resolution: fixed
Status: newclosed

This was fixed in 1.11.5 (which will be released this week).

Last edited 11 months ago by Tim Graham (previous) (diff)

comment:11 Changed 8 months ago by Rudolph Froger

Resolution: fixed
Status: closednew

Please also fix this in Django 1.8.

comment:12 Changed 8 months ago by Simon Charette

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top