Re: [geos-devel] 3.12.0beta1
> On Jun 8, 2023, at 8:42 AM, Greg Troxel wrote: > > Paul Ramsey writes: > >>> On Jun 7, 2023, at 5:26 PM, Greg Troxel wrote: >>> >>> If I install the 3.12.0beta1 package, then the tests pass. So there is >>> a bug, but it is that the tests appaprently refer to installed files, >>> rather than being controlled to use only files in the build tree. >> >> We had this out last release, it’s specific to a particular OS. Happy to >> look over a cmake patch. >> >> https://lists.osgeo.org/pipermail/geos-devel/2022-June/010723.html > > I didn't remember anything from the last release... > > Are you saying that on every other OS, including some other BSD, that if > one has installed to a prefix not in the default search paths, and has > the old version installed, and runs the tests after building the new > version, that they succeed? I did not absorb that from reading the > archives. This is what I’m saying, though I personally only sling MacOS and Linux regularly. You’re the only one I have heard complaints about our source tarballs from on this issue. > I am not particularly skilled at cmake, but I did find a note (that I > managed not to read this time) that the problem is misordering RPATH > args, so that the rpath passed in from a packaging system that says to > find any depending libs in $prefix/lib happens before the special test > rpath that says to get libs from something like builddir/lib. If that's > true, this isn't OS specific (and is a regression from the autotools > build). > > But I understand where you are coming from as ENOPATCH. Er, not sure what that means. If it means I think things are *mostly* fine, then yes. I’d like for you also to not have problems running build/check but I lack the visibility on the problem to attack it personally. P. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
done curl -I https://download.osgeo.org/geos/geos-3.12.0beta1.tar.bz2 HTTP/2 200 server: nginx/1.18.0 (Ubuntu) date: Thu, 08 Jun 2023 16:00:18 GMT content-type: application/octet-stream content-length: 6718651 last-modified: Wed, 07 Jun 2023 19:24:17 GMT etag: "6480d961-6684bb" accept-ranges: bytes front-end-https: on > On Jun 8, 2023, at 8:59 AM, Paul Ramsey wrote: > > If that's required I can do that now... > > On Thu, Jun 8, 2023 at 8:58 AM Sebastiaan Couwenberg > wrote: >> >> 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 50D1 6750 F10A E88D 4AF1 >> >> ___ >> geos-devel mailing list >> geos-devel@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/geos-devel ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
> On Jun 8, 2023, at 8:28 AM, Paul Ramsey wrote: > >> My only question then about 3.12.0beta1 is if the comings-and-goings >> diff of .h files is what the authors intend. > > Probably! I’ll look at that diff. Yep, all changes confirmed. We’re a header-happy project. P___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
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/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
> On Jun 7, 2023, at 5:26 PM, Greg Troxel wrote: > > If I install the 3.12.0beta1 package, then the tests pass. So there is > a bug, but it is that the tests appaprently refer to installed files, > rather than being controlled to use only files in the build tree. We had this out last release, it’s specific to a particular OS. Happy to look over a cmake patch. https://lists.osgeo.org/pipermail/geos-devel/2022-June/010723.html > This > requires alternate rpath processing, etc., and in the autoconf world is > usually handled by libtool relinking at install time. > > Therefore, I have no reason to think 3.12.0beta1 is more troubled than > any previous release -- this is likely not a regression. > > My only question then about 3.12.0beta1 is if the comings-and-goings > diff of .h files is what the authors intend. Probably! I’ll look at that diff. P > > I am kicking off a process to rebuild everything that depends on geos > (that I have installed, but that extends all the way to postis and > qgis). > ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
> On Jun 8, 2023, at 9:16 AM, Sebastiaan Couwenberg wrote: > > 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? Done. Just copy pasta. Thanks, P ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
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/build/doxygen 466: Test timeout computed to be: 1500 [...] 466: -- Doxygen issued 2476 warning(s), see /build/geos-3.12.0~beta1/build/doxygen/doxygen.log [...] 466: CMake Error at check_doxygen_errors.cmake:44 (message): 466: /build/geos-3.12.0~beta1/include/geos/coverage/CoverageRingEdges.h:76: 466: warning: found documented return type for 466: geos::coverage::CoverageRingEdges::CoverageRingEdges that does not return 466: anything 466: 466: [...] 464/466 Test #466: test_docs ..***Failed0.08 sec -- Doxygen issued 2476 warning(s), see /build/geos-3.12.0~beta1/build/doxygen/doxygen.log CMake Error at check_doxygen_errors.cmake:44 (message): /build/geos-3.12.0~beta1/include/geos/coverage/CoverageRingEdges.h:76: warning: found documented return type for geos::coverage::CoverageRingEdges::CoverageRingEdges that does not return anything [...] 99% tests passed, 1 tests failed out of 466 Total Test time (real) = 9.26 sec The following tests FAILED: 466 - test_docs (Failed) Errors while running CTest Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
Paul Ramsey writes: >> On Jun 7, 2023, at 5:26 PM, Greg Troxel wrote: >> >> If I install the 3.12.0beta1 package, then the tests pass. So there is >> a bug, but it is that the tests appaprently refer to installed files, >> rather than being controlled to use only files in the build tree. > > We had this out last release, it’s specific to a particular OS. Happy to look > over a cmake patch. > > https://lists.osgeo.org/pipermail/geos-devel/2022-June/010723.html I didn't remember anything from the last release... Are you saying that on every other OS, including some other BSD, that if one has installed to a prefix not in the default search paths, and has the old version installed, and runs the tests after building the new version, that they succeed? I did not absorb that from reading the archives. I am not particularly skilled at cmake, but I did find a note (that I managed not to read this time) that the problem is misordering RPATH args, so that the rpath passed in from a packaging system that says to find any depending libs in $prefix/lib happens before the special test rpath that says to get libs from something like builddir/lib. If that's true, this isn't OS specific (and is a regression from the autotools build). But I understand where you are coming from as ENOPATCH. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
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 50D1 6750 F10A E88D 4AF1 ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
If that's required I can do that now... On Thu, Jun 8, 2023 at 8:58 AM Sebastiaan Couwenberg wrote: > > 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 50D1 6750 F10A E88D 4AF1 > > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
> /build/geos-3.12.0~beta1/include/geos/coverage/CoverageRingEdges.h:76: > warning: found documented return type for > geos::coverage::CoverageRingEdges::CoverageRingEdges that does not > return > anything Should be good now. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
