On 6/20/23 18:18, Paul Ramsey wrote:
There’s a typo in the test, there should only be three closing parens at the
end. It is in fact invalid WKT.
Patch submitted in https://bugs.debian.org/1038733
No further autopkgtest failures with that patch applied.
Kind Regards,
Bas
--
GPG Key ID: 409
On 6/20/23 17:58, Paul Ramsey wrote:
On Jun 20, 2023, at 8:55 AM, Sebastiaan Couwenberg wrote:
On 6/20/23 00:04, Paul Ramsey wrote:
Please, test 3.12beta2 and let us know if you’re finding any issues, I am
planning to release 3.12 at the end of the week, if there are no reports of
issues
On 6/20/23 00:04, Paul Ramsey wrote:
Please, test 3.12beta2 and let us know if you’re finding any issues, I am
planning to release 3.12 at the end of the week, if there are no reports of
issues with the last beta release.
r-cran-rgeos 0.6-1 is failing its test suite with beta2:
https://qa.d
On 6/20/23 00:04, Paul Ramsey wrote:
Please, test 3.12beta2 and let us know if you’re finding any issues, I am
planning to release 3.12 at the end of the week, if there are no reports of
issues with the last beta release.
Going straight from beta to release without one or more RC in between?
test_docs fails:
test 466
Start 466: test_docs
466: Test command: /usr/bin/cmake "-D"
"DOXYGEN_LOGFILE="/build/geos-3.12.0~beta1/build/doxygen/doxygen.log""
"-P" "/build/geos-3.12.0~beta1/build/doxygen/check_doxygen_errors.cmake"
466: Working Directory: /build/geos-3.12.0~beta1/bu
On 6/8/23 18:00, Paul Ramsey wrote:
done
Thanks.
Can src/coverage/CoverageBoundarySegmentFinder.cpp be relicensed to
match the rest of GEOS instead of JTS? Or should we expect more EPL-2.0
or EDL-1.0 licensed files to get incorporated from JTS?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750
On 6/7/23 22:05, Paul Ramsey wrote:
First tagged release auto built and available at
https://github.com/libgeos/geos/releases/tag/3.12.0beta1
When can we expect the tarballs at:
https://download.osgeo.org/geos/
?
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146
On 6/29/22 01:27, Paul Ramsey wrote:
3.11.0beta2 has been out for a week, and no complaints. This is the vote on
final release of 3.11.0
Shouldn't there be an 3.11.0rc1 first?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D
On 11/2/21 21:17, Paul Ramsey wrote:
It’s neither tagged nor announced, I’m going to make a nee one, thanks.
Tagging or announcing is irrelevant, it's published in the regular
location on download.osgeo.org which is monitored for new releases by
the Debian package.
Don't put trials there, a
Wow, this is badly tested. Looking forward to 3.10.2.
If you're unsure about the changes, you should publish a pre-release first.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
___
On 10/26/21 16:39, Paul Ramsey wrote:
Anyone have a strong objection to this?
https://github.com/libgeos/geos/pull/491
Ordinarily I'd probably just accept, but .md seems like one of those things
that sometimes stirs deep feelings.
The current form of the PR doesn't really make use of the Mar
On 10/18/21 10:33 PM, Paul Ramsey wrote:
> Having gone through numerous beta and rc releases, and hearing no
> further screams of agony, I call the vote on releasing 3.10.0.
You should only release 3.10.0 if that only entails renaming rc2.
If not, you should first release rc3.
Kind Regards,
Bas
Just for the record, the increased CMake version requirement is not met
on Ubuntu bionic.
https://launchpad.net/ubuntu/+source/cmake
Only focal will be able to have geos backports via the UbuntuGIS PPA.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D
Has postgis already been updated for geos 3.10?
3.1.4 has some test failures with it:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/postgis/15944629/log.gz
https://ci.debian.net/data/autopkgtest/unstable/arm64/p/postgis/15944881/log.gz
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F
Just a small nitpick, GEOS_VERSION_NOPATCH is a bad variable name as it
does include the patch version, just not the patch word/pre-release.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
_
The lintian QA tool reported a spelling error for the Debian package build:
* nunber -> number
The attached patch fixes the issue.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Description: Fix spelling errors.
* nun
Another issue, this one cause by the switch to CMake.
The autotools build resulted in libgeos-X.Y.Z.so, which was also its
SONAME, and the libgeos.so symlink to it.
The cmake builds results in libgeos.so.X.Y.Zpre, which is also its
SONAME, and the libgeos.so symlink to it.
The pre-release word s
On 10/1/21 12:12 AM, Paul Ramsey wrote:
> http://download.osgeo.org/geos/geos-3.10.0beta1.tar.bz2
>
> Login to wiki is broken right now, so it's not on the web, but since this is
> testing time I guess that's not a big deal.
Since we cannot login to trac, reporting this issue here:
386/388 Test
On 2/10/21 9:28 AM, Regina Obe wrote:
>>> That last one is quite a nasty one, do take a look. The fact that we
>>> have a major correctness issue argues for quick release.
>>> https://github.com/libgeos/geos/issues/408
>>
>> With the soft freeze this Friday, it's too late to get this into the next
On 2/10/21 12:56 AM, Paul Ramsey wrote:
> I'd like to release 3.9.1 tomorrow. Some important fixes have piled up.
>
> - Bug fixes / improvements:
> - Windows memory management quirk in createPolygon CAPI (#1050, Paul Ramsey)
> - Allow build on Apple ARM64 (Taras Zakharko)
> - Fix buffer to u
On 1/11/21 2:37 AM, Daniel Baston wrote:
>>
>>> Have CMAKE_BUILD_TYPE=None define NDEBUG so that assert() is removed
from the code, thereby not storing the buildpath in the binaries helping
reproducible builds.
>>>
>>> If you don't specify CMAKE_BUILD_TYPE it defaults to Release, and
On 1/10/21 2:44 AM, Daniel Baston wrote:
>>
>> Make the CMake build adhere to CMAKE_INSTALL_LIBDIR so that multiarch
>> keeps working,
>
>
> I created a pull request for this at
> https://github.com/libgeos/geos/pull/380
>
> Have CMAKE_BUILD_TYPE=None define NDEBUG so that assert() is removed
>>
On 1/9/21 3:01 PM, Daniel Baston wrote:
>> buildflags, multiarch, etc. CMake requires more work to make such
>> features work, upstreams seldomly care about those where packagers do.
>
> Can you quantify "more work"? Is there anything that can be done by GEOS to
> reduce it?
Two examples:
Make
On 1/8/21 11:10 PM, Sandro Santilli wrote:
> I think binary packagers would have the most informed opinion on the
> matter as they are the ones that build on multiple-platforms, usually.
> We poor developers mostly build for our single development machines,
> so I'd listen carefully to what people
On 12/10/20 8:56 PM, Paul Ramsey wrote:
> http://download.osgeo.org/geos/geos-3.9.0rc1.tar.bz2
So the geos-3.9.0.tar.bz2 that was there yesterday was a mistake (it's
gone now)?
> Last chance to dance. Download, build, check. I release final tomorrow.
3.9.0 is already in Debian unstable using yes
On 12/3/20 12:17 AM, Paul Ramsey wrote:
> without any further ado, here's a beta2 release for your testing pleasure
testrunner fails on arm64, ppc64el, powerpc, ppc64, riscv64:
https://buildd.debian.org/status/fetch.php?pkg=geos&arch=arm64&ver=3.9.0%7Ebeta2-1%7Eexp1&stamp=1607020427&raw=0
ht
On 12/3/20 11:40 AM, rmrodrig...@carto.com wrote:
>> Thanks, I was about to mention this. Normally libgeos_c.so.1 is
> expected, not libgeos_c.so.0.
>
> +1 to this issue. This forces a recompilation of PostGIS (and I guess
> everything else) to test the new release, so unless the C API has
> chang
On 12/3/20 12:17 AM, Paul Ramsey wrote:
> without any further ado, here's a beta2 release for your testing pleasure
It decrements the SOVERSION from 1 to 0 for the C library, seemingly
caused by this change:
--- a/Version.txt
+++ b/Version.txt
@@ -5,7 +5,7 @@ GEOS_VERSION_MINOR=9
GEOS_VERSION_PA
On 11/25/20 10:36 PM, Mike Taves wrote:
> This keeps the SWIG interface for Ruby bindings, which is packed by
> (e.g.) Ubuntu; see https://packages.ubuntu.com/xenial/ruby/ruby-geos
Because the ruby bindings had practically no users, they were dropped in
geos (3.8.0-1) and are no longer available i
On 10/3/19 6:42 AM, Sebastiaan Couwenberg wrote:
> The release tarball contains some OSX cruft:
>
> geos-3.8.0rc1/src/noding/._NodingIntersectionFinder.cpp
> geos-3.8.0rc1/include/geos/noding/._NodingIntersectionFinder.h
> geos-3.8.0rc1/include/geos/io/._WKBWriter.h
>
The release tarball contains some OSX cruft:
geos-3.8.0rc1/src/noding/._NodingIntersectionFinder.cpp
geos-3.8.0rc1/include/geos/noding/._NodingIntersectionFinder.h
geos-3.8.0rc1/include/geos/io/._WKBWriter.h
geos-3.8.0rc1/capi/._geos_c.cpp
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE8
On 8/14/19 11:32 AM, Ivan Baidakou wrote:
> The bindings are done
> for C++ geos interface, and mostly maches 1 to 1, when it is possible to keep
> API "perlish",
> i.e. not to crash due to dangling reference.
Why not the stable C API?
The bindings are likely to break every time GEOS is updated
On 5/17/19 4:43 PM, Mateusz Loskot wrote:
> On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg
> wrote:
>> On 5/17/19 3:23 PM, Andrew Bell wrote:
>>> Frequent, breaking API changes seem a problem. ABI changes seem more like a
>>> small annoyance. I can understand
On 5/17/19 3:23 PM, Andrew Bell wrote:
> Frequent, breaking API changes seem a problem. ABI changes seem more like a
> small annoyance. I can understand how a stable ABI would be nice, but I
> personally don't think it's more important than a good interface for
> library users.
And that's the diff
end to
cause build failures for the projects that rely on the C++ API.
Everything that relies on the stable C API doesn't need to be rebuilt
for new GEOS releases.
> On Fri, May 17, 2019, 6:30 AM Sebastiaan Couwenberg
> wrote:
>
>> On 5/17/19 1:14 PM, Andrew Bell wrote:
>&g
be integrated
to work with the same version of GEOS.
> On Thu, May 16, 2019, 11:37 PM Sebastiaan Couwenberg
> wrote:
>
>> On 5/16/19 11:28 PM, Mateusz Loskot wrote:
>>> I'd like propose to effectively revert the RFC 6:
>>>
>>> https://trac.osgeo.or
On 5/16/19 11:28 PM, Mateusz Loskot wrote:
> I'd like propose to effectively revert the RFC 6:
>
> https://trac.osgeo.org/geos/wiki/RFC9
Please don't. We'll get more projects like OSSIM that break with new
GEOS releases, this causes significant delays before the new release can
be included in dis
On 5/2/19 5:54 PM, Paul Ramsey wrote:
> I’m about to push out a 3.7.1 patch release
GEOS 3.7.1 was released on 2018-11-29, I guess you mean 3.7.2?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
__
On 10/4/18 4:39 AM, Regina Obe wrote:
>> pkgsrc is using autoconf. I have had far more problems with cmake over
>> time than with autoconf.
>>
>
> But you do use CMake for some things right?
>
> I presume Debian and CentOS packagers already use CMake because they ship
> pgRouting and pgRouting
On 9/8/18 8:13 PM, Regina Obe wrote:
> Were these an issue in 3.6.3. Sorry if I missed the thread about that.
The tests/ticket/bug398.xml failure on arm64 was also present in 3.6.2,
the same goes for tests/general/TestCentroid.xml.
So those aren't a regression introduced in 3.7.0.
Kind Regards,
On 9/5/18 2:29 AM, Greg Troxel wrote:
> Has anyone run the geos tests on arm under Linux?
Yes.
arm64:
https://buildd.debian.org/status/fetch.php?pkg=geos&arch=arm64&ver=3.7.0%7Erc2-1%7Eexp1&stamp=1536042629&raw=0
armel:
https://buildd.debian.org/status/fetch.php?pkg=geos&arch=armel&ver=3.7
On 8/27/18 6:39 PM, Regina Obe wrote:
> Did we decide what to do here:
>
> https://trac.osgeo.org/geos/ticket/917
>
> Okay to go with Greg's change of being more greedy by dropping the ?.
> If it fixes NetBSD I'm all for it, as I don't think we'll ever be adding
> anything after that would be an
On 8/21/18 3:38 PM, Greg Troxel wrote:
>
> Sebastiaan Couwenberg writes:
>
>> On 8/21/18 3:04 PM, Regina Obe wrote:
>>> gdt said
>
>>>> The C++11 description is not entirely clear to me, and I think it
>>>> should be extra loud up front.
On 8/21/18 3:26 PM, Greg Troxel wrote:
>
> Sebastiaan Couwenberg writes:
>
>> On 8/21/18 1:25 AM, Greg Troxel wrote:
>>>
>>> is malformed. It's the .* production that the ? applies to (present or
>>> not).
>>>
>>> VERSION
On 8/21/18 3:04 PM, Regina Obe wrote:
>> A few comments about NEWS:
>>
>> I find the style of listing the alpha and rc separately confusing for
>> those who go from 3.6.2 to 3.7.0 (should be almost everyone). So
>> instead of having them separate, I would start a "3.7.0 (not released
>> ye
On 8/21/18 1:25 AM, Greg Troxel wrote:
>
> "Regina Obe" writes:
>
>> I asked Sebastian the same thing. He said it's needed in configure
>> script to escape the [] as I recall.
>
> Of course :-) I was looking back and forth in so many rules I forgot
> which it was.
>
> But, I figured out what
On 8/20/18 10:44 PM, Regina Obe wrote:
> I asked Sebastian the same thing. He said it's needed in configure script to
> escape the [] as I recall.
Yes, see:
https://trac.osgeo.org/geos/ticket/887
"The single blockquotes are stripped by m4(1), hence the need for
additional quotes."
> From: Gr
On 10/06/2017 10:28 AM, Robert Coup wrote:
> Hi Bas,
>
> On 5 October 2017 at 11:01, Bas Couwenberg wrote:
>
>> Yes, Debian distributions will only ever have a single gdal package,
>> Ubuntu by extension will too (because they just copy the packages from
>> Debian) although newer versions are av
On 10/05/2017 12:34 AM, Robert Coup wrote:
> Alternative is to work with on C++ APIs/ABIs and compatibility with the
> distros and make it clear that having 7 versions of GEOS installed is
> completely normal. And woe betide if there's a security problem with the
> WKB parser that affects them all.
On 10/03/2017 08:32 PM, Regina Obe wrote:
> Just curious how many projects that rely on GDAL use the C++ API are
> distributed by packages.
In Debian most packages use at least one GDAL C++ symbol:
dans-gdal-scripts C++
fiona C++
gazebo C++
gmtC
imp
On 10/03/2017 07:37 PM, Howard Butler wrote:
> What if we were to do the same thing with GDAL -- take away GDAL's C++ API
> which you were not supposed to use, but we put it out there anyway, because
> it was inconvenient for some of the open source packaging systems? Not
> possible because too
On 10/01/2017 10:05 PM, Mateusz Loskot wrote:
> On 1 October 2017 at 21:47, Sebastiaan Couwenberg wrote:
>> On 10/01/2017 09:33 PM, Mateusz Loskot wrote:
>>> Unless, Sandro, your aim is to eventually mark C++ API deprecated
>>> and stop installing C++ API libraries and
On 08/29/2017 05:56 PM, Mateusz Loskot wrote:
> Since .editorconfig now forces LF/CRLF per file type in the codebase,
> wouldn't it be a good idea to add .gitattributes with explicit
> eol= specification per file type too?
>
> This would ensure git checkout/commit does not re-convert line endings
On 04/05/2017 01:27 AM, Greg Troxel wrote:
> I am really unclear on the troubles with people getting osgeo accounts
> (have had one for years), but it seems that if that's a reason to use a
> proprietary hosting service then it's better to fix the problem.
You need to get a mantra (request a token
On 04/01/2017 06:44 PM, Sandro Santilli wrote:
> On Sat, Apr 01, 2017 at 06:25:09PM +0200, Mateusz Loskot wrote:
>> I'd rather wait for more votes than two.
>> If no more votes arrive, I'll mark the RFC 5 as referred or withdrawn.
>
> You might have noticed that PSC has not been very active, latel
On 12/24/2016 05:10 PM, Sandro Santilli wrote:
> Happy upgrades !
Dear Santa,
For Christmas this year I'd like a new OSSIM release which switches to
the GEOS C API, this removes the biggest blocker for upgrades to GEOS
3.6 and would spread much joy.
If your elves are not to busy, could you have
On 10/26/2016 11:28 AM, Sandro Santilli wrote:
> As per recent motion to move from SVN to GIT, I'd delete
> the "trunk" branch from SVN and continue under GIT for
> the upcoming 3.7.0 release.
>
> Older branches could keep in SVN for now.
>
> Do you see any problem with this approach ?
I don't s
On 10/25/2016 09:43 PM, Jeff McKenna wrote:
> On 2016-10-25 4:23 PM, Sebastiaan Couwenberg wrote:
>> On 10/25/2016 06:07 PM, Sandro Santilli wrote:
>>> - C++ API changes:
>>> - Automatic memory management for GeometryFactory objects
>>
>> This chang
On 10/25/2016 06:07 PM, Sandro Santilli wrote:
> - C++ API changes:
> - Automatic memory management for GeometryFactory objects
This change seems to cause the build failures for OSSIM, osmium &
osm2pgsql with GEOS 3.6.0. All three builds fail with these errors:
'geos::geom::GeometryFactory
On 08/30/16 11:12, Sandro Santilli wrote:
On Tue, Aug 30, 2016 at 10:41:06AM +0200, Sebastiaan Couwenberg wrote:
And most importantly, does php-geos 1.0.0rc1 support PHP 7?
Yes!
Thanks, we had to remove the php5-geos package because SWIG still lacks
support for PHP 7.
I've cr
On 08/30/16 10:09, Sandro Santilli wrote:
Version 1.0.0rc1 of php-geos is available for download and test
from https://git.osgeo.org/gogs/geos/php-geos/releases
This is the first standalone php binding for GEOS, it should
work against any GEOS version since 3.1.0 (for thread-safe API).
If no bu
61 matches
Mail list logo